Nội dung chính
1. Giới thiệu
Cân Bằng Tải là việc phân bố đồng đều lưu lượng truy cập giữa hai hay nhiều các máy chủ có cùng chức năng trong cùng một hệ thống. Bằng cách đó, sẽ giúp cho hệ thống giảm thiểu tối đa tình trạng của máy chủ, thậm chí là datacenter. Nó là 1 phần cực kì quan trọng trong việc quản lý truy cập.
Có một số tính năng rất thú vị về LB
- Là 1 trong những thành phần quan trọng nhất để monitor hệ thống
- Là vị trí duy nhất giúp người quản trị nhìn được các service phía sau chúng
Có 2 open souce phổ biến Load Balancer đó là : HAProxy và nginx. Bây giờ chúng ta hãy cùng so sánh chúng với nhưng tính năng đã nói ở phía trên.
2. Enable monitoring trên load balancer
Như nhan đề cũng đã rõ, nếu triển khai trên production thì công việc thứ tự sẽ như sau :
- Cài đặt
- Enable trạng thái và theo dõi stuff
- Enable log
Enabling nginx status page
Sửa /etc/nginx/nginx.conf:
server {
listen 0.0.0.0:6644;
access_log off;
allow 127.0.0.0/8;
allow 10.0.0.0/8;
deny all;
location / {
stub_status on;
}
}
Enabling HAProxy stats page
Sửa /etc/haproxy/haproxy.cfg:
listen stats 0.0.0.0:6427
mode http
maxconn 10
no log
acl network_allowed src 127.0.0.0/8
acl network_allowed src 10.0.0.0/8
tcp-request connection reject if !network_allowed
stats enable
stats uri /
3. Tổng hợp thông tin từ Load Balancer :
Có 1 vài giải pháp monitor tiêu chuẩn như : datadog, signalfx, prometheus, graphite…
Những công cụ này thu thập số liệu từ các ứng dụng, máy chủ và cơ sở hạ tầng. Sau đó chúng vẽ đồ thị từ dữ liệu thu thập được và gửi thông báo.
Việc tích hợp Load Balancer vào trong hệ thống monitor là rất quan trọng. Chúng tôi cần biết về số active client, request/s, tỷ lệ lỗi, vv …
Không cần phải nói, hệ thống monitor sẽ bị giới hạn bởi những thông tin được đo và cung cấp bởi các cân bằng tải.
Những dữ liệu từ nginx
nginx cung cấp 7 loại số liệu :
- Active connections
- Accepts
- handled
- requests
- Reading
- Writing
- Waiting
Nginx chỉ cung cấp tổng trên tất cả các site. Nó không thể lấy được bất kỳ số liệu cho mỗi trang web cũng như cho mỗi ứng dụng.
Active connections: The current number of active client connections
including Waiting connections.
accepts: The total number of accepted client connections.
handled: The total number of handled connections. Generally, the
parameter value is the same as accepts unless some resource
limits have been reached (for example, the worker_connections limit).
requests: The total number of client requests.
Reading: The current number of connections where nginx is reading the
request header.
Writing: The current number of connections where nginx is writing the
response back to the client.
Waiting: The current number of idle client connections waiting for a request.
Nguồn : https://nginx.org/en/docs/http/ngx_http_stub_status_module.html
Những dữ liệu từ HAProxy
HAProxy cung cấp 61 số liệu.
Các số liệu được đưa ra trên mỗi frontend và mỗi backend. Tất cả đều có sẵn trên 1 trang web hoặc trên file CSV.
0. pxname [LFBS]: proxy name
1. svname [LFBS]: service name (FRONTEND for frontend, BACKEND for backend,
any name for server/listener)
2. qcur [..BS]: current queued requests. For the backend this reports the
number queued without a server assigned.
3. qmax [..BS]: max value of qcur
4. scur [LFBS]: current sessions
5. smax [LFBS]: max sessions
6. slim [LFBS]: configured session limit
7. stot [LFBS]: cumulative number of connections
8. bin [LFBS]: bytes in
9. bout [LFBS]: bytes out
[...]
32. type [LFBS]: (0=frontend, 1=backend, 2=server, 3=socket/listener)
33. rate [.FBS]: number of sessions per second over last elapsed second
34. rate_lim [.F..]: configured limit on new sessions per second
35. rate_max [.FBS]: max number of new sessions per second
36. check_status [...S]: status of last health check, one of:
37. check_code [...S]: layer5-7 code, if available
38. check_duration [...S]: time in ms took to finish last health check
39. hrsp_1xx [.FBS]: http responses with 1xx code
40. hrsp_2xx [.FBS]: http responses with 2xx code
41. hrsp_3xx [.FBS]: http responses with 3xx code
42. hrsp_4xx [.FBS]: http responses with 4xx code
43. hrsp_5xx [.FBS]: http responses with 5xx code
44. hrsp_other [.FBS]: http responses with other codes (protocol error)
[...]
Nguồn : http://www.haproxy.org/download/1.5/doc/configuration.txt
4. Giám sát hoạt động của load balancer
Đầu tiên, chúng ta sẽ cùng xem dữ liệu được hiện thị bởi các load balancer có trực quan hay không. Sau đó chúng ta sẽ đi sâu vào các giải pháp giám sát của bên thứ ba.
Nginx
Vào địa chỉ đã cấu hình ở trên
Thật sự nhìn không hề trực quan 1 chút nào, không hiển thị được ứng dụng trên LB, không hiện thị được server nào đang online.
HAProxy
Để so sánh, hãy cùng nhìn HAProxy monitor
Ở đây chúng ta có thể nhìn thấy server up hay down, băng thông, số lượng client đã kết nối,… Đó chính là những thông số cụ thể giúp ích được cho người quản trị. Nhưng có lẽ chừng đó vẫn là chưa đủ, thử nghĩ nếu bây giờ nếu trang web quản trị gặp sự cố. Đầu tiên, mở trang http://mywebsite.com để xem nó đang như thế nào. Tiếp theo, tôi sẽ mở HAProxy stats để tìm hiểu xem vấn đề gì đang xảy ra. Như thế thì quá mất thời gian, theo tôi là vậy. Bởi vì bản thân HAProxy không phải là công cụ monitor nên nó cũng sẽ có hạn chế, cũng không có cảnh báo. Chính vì vậy chúng ta cần đến phần mềm của bên thứ 3.
5. Tích hợp với hệ thống monitor
Nginx
Tất cả những gì chúng ta có đó là 7 số liệu, trong đó có request/s là đáng chú ý. Nginx không cung cấp API để lấy được những con số cho từng trang web. Cách duy nhất là lấy những dữ liệu text. Bản thân tôi cũng đã sử dụng Zabbix để monitor nginx (tất nhiên là bạn phải tự viết lấy 1 template) nhưng tất cả đều không được như sự mong đợi, hơn nữa nó lại thiếu đi sự ổn định.
HAProxy
Mục tiêu đó là không chỉ để người quản trị có thể hiểu mà còn là những người không có kinh nghiệm monitor cũng có thể xem và hiểu. Khá hay đó là HAProxy có sẵn định dạng CSV, Dưới đây là 1 ví dụ về 1 dashboard của HAProxy được cung cấp bởi Datadog :
Nguồn : http://docs.datadoghq.com/integrations/haproxy/
Các số liệu được vẽ lên đồ thị, đồ thị có thể sắp xếp thành các biểu đồ, hơn thế nữa là có thể cấu hình cảnh báo tự động. Các trang thống kê sẽ show trang thái hiện tại, tuy nhiên cũng hỗ trợ xem lại lịch sử nếu bạn muốn thu thập thông tin từ trước đó.
6. Tại sao nginx không có monitoring ?
Tất cả những tính năng monitor còn thiếu trên nginx chỉ có 1 mục đích đó là lợi nhuận. Cũng chính vì thế không bao giờ tính năng đó được cung cấp miễn phí. Nếu bạn cần monitor trên nginx và cần tích hợp JSON API, bạn sẽ phải trả tiền cho Nginx Plus. Giá khởi điểm là 1900 “MỸ KIM” cho mỗi server 1 năm =)).
Tham khảo thêm : https://www.nginx.com/products/pricing/
7. Kết luận
Nếu vấn đề của bạn là chi phí nên bỏ qua Nginx, tất nhiên còn nhiều yếu tố để đánh giá ví dụ như hiệu năng và độ ổn định. Nhưng một điều rất quan trọng đó là theo dõi được service cũng như hạ tầng của bạn hoạt động như thế nào. Nginx đã bỏ qua rất nhiều tính năng chỉ vì lợi nhuận. Theo tôi với Load Balancer nên sử dụng HAProxy .
Nguồn: https://viblo.asia/p/haproxy-vs-nginx-lua-chon-load-balancer-cho-production-XWkKAvyNzjy