Hướng dẫn sử dụng nginx làm HTTP load balancer
Load balancer - cân bằng tải là một kỹ thuật được ứng dụng để tối ưu hóa việc sử dụng tài nguyên, tối đa hóa lưu lượng truyền tải, giảm độ trễ và tăng khả năng chịu lỗi.
Có thể sử dụng nginx như một HTTP load balancer để giải quyết hiệu quả các vấn đề về phân phối lưu lượng truy cập đến một số máy chủ ứng dụng và cải thiện hiệu suất, khả năng mở rộng, độ tin cậy của các ứng dụng web sử dụng nginx. Sau đây, Bizfly Cloud sẽ hướng dẫn cách sử dụng nginx làm HTTP load balancer.
Các phương pháp cân bằng tải
Các cơ chế cân bằng tải (hoặc phương pháp) sau đây được hỗ trợ trong nginx:
round-robin - yêu cầu gửi đến các application server được phân phối theo vòng tròn,
least-connected - yêu cầu tiếp theo gửi đến máy chủ có số lượng kết nối đang hoạt động ít nhất,
ip-hash - một hàm băm được sử dụng để xác định máy chủ nào sẽ được chọn cho yêu cầu tiếp theo (dựa trên địa chỉ IP của máy khách).
Cấu hình cân bằng tải mặc định
Cấu hình đơn giản nhất để cân bằng tải với nginx có thể có dạng như sau:
http {
upstream myapp1 {
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
server {
listen 80;
location / {
proxy_pass http://myapp1;
}
}
}
Trong ví dụ trên, một ứng dụng đang chạy trên cả 3 server srv1-srv3. Khi không cấu hình cụ thể phương pháp cân bằng tải, nó sẽ mặc định chạy round-robin. Tất cả các yêu cầu đều được ủy quyền cho nhóm máy chủ myapp1 và nginx áp dụng cân bằng tải HTTP để phân phối các yêu cầu.
Triển khai reverse proxy trong nginx bao gồm cân bằng tải cho HTTP, HTTPS, FastCGI, uwsgi, SCGI, memcached và gRPC.
Để cấu hình cân bằng tải cho HTTPS thay vì HTTP, chỉ cần sử dụng "https" làm giao thức.
Khi thiết lập cân bằng tải cho các lệnh FastCGI, uwsgi, SCGI, memcached hoặc gRPC, hãy sử dụng lệnh fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass và grpc_pass.
Least-connected load balancing
Một kỹ thuật cân bằng tải khác là least-connected. Kết nối tối thiểu cho phép kiểm soát tải giữa các ứng dụng được cân bằng hơn khi xảy ra tình huống có các request nhiều thời gian để hoàn thành hơn các request khác.
Với least-connected, nginx sẽ cố gắng không gây quá tải các máy chủ ứng dụng đang hoạt động ở công suất cao, thay vào đó phân phối các yêu cầu mới đến một máy chủ ít hoạt động hơn.
Cân bằng tải least-connected trong nginx được kích hoạt khi chỉ thị less_conn được sử dụng như một phần của cấu hình nhóm máy chủ:
upstream myapp1 {
least_conn;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
Session persistence – Phiên hoạt động
Cần lưu ý rằng với round-robin và least-connected, mỗi request tiếp theo có thể sẽ được phân phối đến một máy chủ khác nhau. Không có gì đảm bảo rằng cùng một client sẽ luôn được chuyển đến cùng một máy chủ.
Nếu có nhu cầu ràng buộc client với một máy chủ cụ thể - nói cách khác, hãy tạo phiên của client đó làm sao để luôn kết nối tới hoặc liên tục kết nối tới một máy chủ cụ thể - cơ chế cân bằng tải ip_hash lúc này có thể sử dụng.
Với ip-hash, địa chỉ IP của client được sử dụng như khóa của hàm băm để xác định máy chủ nào trong nhóm máy chủ sẽ được chọn xử lý các request của client. Phương pháp này đảm bảo rằng các yêu cầu từ cùng một client sẽ luôn được chuyển đến cùng một máy chủ trừ khi máy chủ này không khả dụng.
Để định cấu hình cân bằng tải ip-hash, chỉ cần thêm chỉ thị ip_hash vào cấu hình nhóm máy chủ:
upstream myapp1 {
ip_hash;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
Với cấu hình này, cứ 5 yêu cầu mới sẽ được phân phối trên các ứng dụng như sau: 3 yêu cầu sẽ được chuyển đến srv1, một yêu cầu sẽ chuyển đến srv2 và một yêu cầu khác đến srv3.
Tương tự như vậy có thể sử dụng các trọng số với cân bằng tải ip-hash và least-connected trong các phiên bản gần đây của nginx.
Health checks
Reverse proxy trong nginx bao gồm in-band (hoặc passive) health check. Nếu phản hồi từ một máy chủ cụ thể không thực hiện được do lỗi, nginx sẽ đánh dấu máy chủ này là không khả dụng và sẽ cố gắng tránh chọn máy chủ này cho các yêu cầu gửi tiếp theo trong một thời gian.
Lệnh max_fails đặt số lần thử liên tiếp không thành công để liên lạc với máy chủ trong fail_timeout. Theo mặc định, max_fails được đặt bằng 1. Khi đặt bằng 0, health checks cho máy chủ này sẽ bị vô hiệu hóa. Tham số fail_timeout cũng xác định thời gian máy chủ được đánh dấu là không đủ điều kiện. Sau khoảng thời gian fail_timeout do sự cố máy chủ, nginx sẽ bắt đầu kiểm tra máy chủ cẩn thận với các yêu cầu khách hàng trực tiếp. Nếu các kiểm tra thành công, máy chủ sẽ được đánh dấu trạng thái là hoạt động.
Nguồn: Bizfly Cloud chia sẻ
>> Có thể bạn quan tâm: Hướng dẫn cài đặt Nginx trên Ubuntu Server 14.04 và 16.04
