Trong bài viết này mình sẽ giới thiệu với các bạn thiết lập cân bằng tải trong hệ thống máy chủ Nginx .Ở bài viết này hbsprogram.com sẽ cùng các bạn đi tìm hiểu các vấn đề sau :
- Lý do sử dụng nginx load balancing ?
- Sử dụng NGINX làm load balancer
- Các thuật toán dùng nginx load balancing
- Cơ chế tránh lỗi server khi 1 server bị down
1 Lý do sử dụng nginx load balancing
Nếu website bạn phục vụ lượng người online 1 lúc từ 30 nghìn người online trở lên thì bạn cần làm ngay 1 việc đó là tối ưu hóa sử dụng tài nguyên, băng thông, giảm độ trễ, và tăng cường khả năng chịu lỗi .Có rất nhiều phương pháp để xử lý những vấn đề trên như
- Phương pháp 1 : Tăng gói hợp đồng với nhà cung cấp vps như tăng ram ,tăng cpu ,tăng băng thông
- Phương pháp 2 : Sử dụng nginx load balancing
Phương án 1 khi sử dụng sẽ rất mất nhiều công sức và không tối ưu vì cpu bạn có thể tăng đến 20 cpu, ram có thể đến 60 GB ram băng thông max nhất là 1 Gbs với 1 cái giá cắt cổ .
Phương án 2 sẽ đáp ứng tốt hơn vì khi cần mở rộng bạn chỉ cần mua thêm vps với băng thông sẽ được san sẻ ra các vps con làm giảm truy vấn đến server chính rất nhiều ,việc mở rộng thì cực kì dễ dàng
Dưới đây là hình ảnh mô tả cơ chế làm việc của nginx load balance
2 Sử dụng NGINX làm load balancer
Lý do sử dụng nginx vì server nginx có cơ chế phục vụ tốt hơn so với apache ở nhiều điểm
Mô hình dưới đây mình sử dụng 3 server
- Master: Đóng vai trò là Load balancer
- Backend1: Webserver 1
- Backend2: Webserver 2
Cơ chế đây phục vụ sẽ tốt phần hiển thị code ở bài tiếp theo mình sẽ hướng dẫn các bạn làm đa server database
Cấu hình Upstream trên Master
Để bắt đầu sử dụng NGINX với một nhóm các máy chủ web, đầu tiên, bạn cần khai báo upstream group. Directive này được đặt trong http block.
http {
upstream backend {
server backend1_or_ip1;
server backend2_or_ip2;
}
}
Để truyền các request từ người dùng vào một group các server, tên của group được truyền vào với directive proxy_pass (hoặc fastcgi_pass, memcached_pass, uwsgi_pass, scgi_pass tùy thuộc vào giao thức). Trong bài viết này, virtual server chạy trên NGINX sẽ truyền tất cả các request tới backend upstream server:
server {
location / {
proxy_pass http://backend;
}
}
Dưới đây là file nginx của master
upstream backend {
server 103.53.198.171;
server 103.200.6.24;
server 104.199.133.13;
}
server {
server_name www.lb.hbsprogram.com;
rewrite ^(.*) http://lb.hbsprogram.com$1 permanent;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
access_log off;
# access_log /home/lb.hbsprogram.com/logs/access_log;
error_log off;
# error_log /home/lb.hbsprogram.com/logs/error.log;
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
root /home/lb.hbsprogram.com/public_html;
include /etc/nginx/conf/ddos2.conf;
index index.php index.html index.htm;
server_name lb.hbsprogram.com;
#///////////////////////////////////////////////////////
# Ban chi co the chon 1 trong 4 rule AAA, BBB, CCC hoac DDD
# Ban nen comment cac rule khong su dung thay vi xoa chung vi neu ban su dung wordpress blog
# Cac dong nay can thiet cho cac chuc nang trong WordPress Blog Tools cua VPSSIM
# Thuat ngu:
# Comment - Them dau # vao truoc
# Uncomment - Bo dau # o truoc cau.
#///////////////////////////////////////////////////////
#Chay tat ca cac website (WordPress, Xenforo, Joomla, Phpbb .... ). neu ban su dung rule cua ban,comment dong duoi (them dau # vao truoc) (AAA)
#include /etc/nginx/conf/all.conf;
#Neu ban su dung rule cua minh, comment rule o tren. Sau do uncoment (bo dau # ba dong duoi) sau do them rule vao giua. (BBB)
#location / {
#Uncomment 3 dong nay, sau do cho rule cua ban vao day!
#}
# Rule cho wordpress + Plugin wp super cache. Neu ban su dung wordpress va wp super cache, uncomment dong duoi va comment dong AAA phia tren. (CCC)
#include /etc/nginx/conf/supercache.conf;
# Rule cho wordpress + Plugin W3 Total Cache. Neu ban su dung wordpress va W3 Total, uncomment dong duoi va comment dong AAA phia tren. (DDD)
#include /etc/nginx/conf/w3totalcache.conf;
# Confif Cache Static Files
include /etc/nginx/conf/staticfiles.conf;
#Tang bao mat security, chong sql injection ....(uncoment neu ban muon su dung). Boi vi mot so code website khong su dung duoc voi rule nay, nen mac dinh VPSSIM de tat.
#Khong duoc xoa dong duoi, neu xoa VPSSIM se khong hoat dong !
#include /etc/nginx/conf/block.conf;
# Error Page
#error_page 403 /errorpage_html/403.html;
#error_page 404 /errorpage_html/404.html;
#error_page 405 /errorpage_html/405.html;
#error_page 502 /errorpage_html/502.html;
#error_page 503 /errorpage_html/503.html;
#error_page 504 /errorpage_html/504.html;
#location ^~ /errorpage_html/ {
# internal;
# root /home/lb.hbsprogram.com;
# access_log off;
#}
#include /etc/nginx/conf/phpstatus.conf;
include /etc/nginx/conf/drop.conf;
}
3 Các thuật toán dùng nginx load balancing
Các thuật toán cân bằng tải
Thuật toán Round Robin:
Đây gọi là thuật toán luân chuyển vòng, các máy chủ sẽ được xem ngang hàng và sắp xếp theo một vòng quay. Các truy vấn dịch vụ sẽ lần lượt được gửi tới các máy chủ theo thứ tự sắp xếp.
Ví dụ:
Cấu hình một cụm Cluster bao gồm 03 máy chủ: A, B, C.
Yêu cầu dịch vụ thứ nhất sẽ được gửi đến máy chủ A.
Yêu cầu dịch vụ thứ hai sẽ được gửi đến máy chủ B.
Yêu cầu dịch vụ thứ ba sẽ được gửi đến máy chủ C.
Yêu cầu dịch vụ thứ tư sẽ lại được gửi cho máy chủ A….
Mặc định nginx sử dụng thuật toán round robin
Thuật toán Weighted Round Robin
Thuật toán này giống thuật toán round robin khác nhau ở trọng số phân chia request .Khi nào dùng thuật toán này khi mà bạn có nhiều server với các thông số khác nhau thì nên sử dụng thuật toán này
Cấu hình nginx :
upstream backend {
#ip_hash;
server 103.200.6.24 weight = 1;
server 104.199.133.13 weight =2;
}
Ở đây trọng số chúng ta phân chia các request đến 2 server với các trọng số 1:2 có nghĩa là khi có 3 request đến thì server sẽ phân tải 1 cho server 103.200.6.24 và 2 cho server 104.199.133.13
Thuật toán Weights Least Connection
Chia các request đến các server ít bận rộn hơn
Cấu hình nginx
upstream backend {
least_conn;
server 103.200.6.24;
server 104.199.133.13;
}
Thuật toán IP Hash
IP Hash cho phép các máy chủ đáp ứng cho client theo địa chị IP của client, tức là nếu client 1 gửi request tới và được server A xử lý thì lần sau request sẽ vẫn là server A xử lý trừ khi server A bị down. Để đánh dấu một server down, chỉ cần thêm config down là xong, khi đó tất cả IP đã gửi tới server A trước đó sẽ được chuyển hướng tới một server khác.
Cấu hình nginx
upstream backend {
ip_hash;
server 103.200.6.24;
server 104.199.133.13;
}
4 Cơ chế tránh lỗi nginx Health checks
Giống như việc bạn có 1 nhóm các bạn đang làm việc vào 1 ngày xấu trời có 1,2 bạn nghỉ nếu như bạn không biết những ai nghỉ mà vẫn phân công công việc đến họ sẽ làm cho những công việc đó bị ngưng trệ .Giống như vậy nếu 1 list các server của bạn có 1,2 server bị down việc cần làm sẽ là tìm xem server nào down và chuyển những công việc cho các server còn lại .Nginx đã có cơ chế giúp chúng ta xử lý vấn đề đó với việc nó sẽ thực hiện liên tục việc kiểm tra các server trên upstream được khai báo trong config của bạn để tránh việc điều hướng các request của người dùng vào các server không hoạt động. Tóm lại là việc này nhằm đảm bảo người dùng không nhìn thấy các page thông báo lỗi khi chúng ta tắt đi 1 server nào đó, hoặc server nào đó đột xuất bị lỗi không hoạt động.
Cấu hình nginx
upstream backend {
#ip_hash;
server 103.200.6.24 max_fails=3 fail_timeout=15s;;
server 104.199.133.13 max_fails=5 fail_timeout=15s;;
}
Ở đây số request lỗi được định nghĩa cho server 1 là 3 và server 2 là 5 trong khoảng thời gian fail request là 15s
Demo :http://lb.hbsprogram.com/
Bonus
Cấu hình monitor quản trị của nginx (hàng củ chuối vl)
server {
listen 0.0.0.0:6644;
access_log off;
allow all;
location / {
stub_status on;
}
}
Restart lại nginx với lệnh
service nginx restart
Sau đó bạn vào http://ip:6644 để xem status server nginx
Tài liệu tham khảo
https://viblo.asia/p/su-dung-nginx-lam-load-balancer-cho-nhieu-backend-server-gDVK2aJ25Lj
https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-load-balancing
