Hướng dẫn sử dụng Load balacer trên Nginx

Nginx Load Balancer là gì? Cách vận hành ra sao? Hãy cùng tìm câu trả lời trong bài viết dưới đây nhé!

Nginx Load Balancer là gì?

Cân bằng tải (Load balancing) là một kỹ thuật thường dùng để tối ưu hóa việc sử dụng tài nguyên, tối đa hóa thông lượng, giảm độ trễ về đảm bảo tính chịu lỗi. Chúng ta cũng có thể sử dụng nginx như là một bộ cân bằng tải (Load balancer) để phân phối lưu lượng truy cập đến các máy chủ web nhằm mục đích cải thiện hiệu năng, khả năng mở rộng và độ tin cậy của các ứng dụng web.

Có rất nhiều thuật toán được xây dựng cho việc cân bằng tải, mỗi thuật toán đều có những ưu nhược điểm khác nhau, trong mỗi trường hợp sẽ có được tác dụng riêng, chúng ta cũng có thể kết hợp các thuật toán với nhau để giúp cho hệ thống hoạt động được tốt hơn. Tùy vào cơ sở hạ tầng và mục đích sử dụng mà sẽ lựa chọn thuật toán phù hợp với hệ thống.

2. Mô hình Nginx Load Balancer

Mô hình Lab

Nginx Load Balancer: kết nối với End User bên ngoài và 172.16.0.11 – Kết nối tới các Web Server 01, 02 bên trong để điều phối Request.
Ví dụ Web Server 01: web1 – có ip 172.16.0.21
Ví dụ Web Server 02: web2 – có ip 172.16.0.2

3. Xây dựng demo:

3.1. Tạo cấu trúc thư mục và file để chạy demo như sau:

3.2.Tạo docker-compose.yml với nội dung:

version: ‘3’

services:

loadbalancing_nginx:

image: nginx:alpine

ports:

– “8081:80”

volumes:

– ./nginx.conf:/etc/nginx/nginx.conf

– ./index.html:/usr/share/nginx/html/index.html

depends_on:

– web1

– web2

web1:

build: ./web/server1

container_name: web1

web2:

build: ./web/server2

container_name: web2

Trong đó:

loadbalancing_nginx là tên của container Nginx để chia tải cho hai container web1 và web2.
image: nginx:alpine là image sẽ được sử dụng để tạo container Nginx.
ports: – “8081:80” là cổng mà container Nginx sẽ lắng nghe các yêu cầu HTTP.
volumes: – ./nginx.conf:/etc/nginx/nginx.conf là thư mục chia sẻ giữa host và container Nginx, chứa tệp cấu hình Nginx để chia tải cho hai container web1 và web2.
depends_on: – web1 – web2 là chỉ định rằng container Nginx phải chờ đợi container web1 và web2 khởi chạy trước khi nó được khởi chạy.

Các container web1 và web2 có thể được cấu hình tương tự như container Nginx, với các image và cấu hình tùy chọn phù hợp với ứng dụng của bạn.

3.3. Tạo file nginx.conf:

events {

worker_connections 1024;

}

http {

upstream backend{

server 172.16.0.21:80 weight=1;

server 172.16.0.22:80 weight=2;

}

server {

listen 80;

server_name localhost:8081;

location / {

proxy_pass http://backend;

}

Trong đó:

events là khai báo số lượng kết nối tối đa mà một worker process có thể xử lý. Trong ví dụ này, ta thiết lập là 1024.
http khai báo các mục cấu hình của Nginx cho giao thức HTTP.
upstream backend là khai báo danh sách các web server được load balancing. Trong ví dụ này, web1 và web2 đều lắng nghe trên cổng 80.
server là khai báo cho Nginx lắng nghe các yêu cầu đến trên cổng 80 với tên miền example.com.
location / là khai báo cấu hình định tuyến cho tất cả các yêu cầu đến địa chỉ http://backend, nghĩa là các yêu cầu sẽ được chuyển tiếp đến các server đang lắng nghe trên cổng 80 của web1 và web2.
proxy_set_header là khai báo các tiêu đề HTTP để chuyển tiếp cho các yêu cầu.

3.4. Tạo file Dockerfile trong thư mục server1 và server2:

FROM nginx:alpine

COPY index.html /usr/share/nginx/html

3.5. Tạo file index.html trong thư mục server1 và server2:

<h1>Hello Load balancing from Server 1</h1>

3.6. Chạy docker-compose

Cd đến thư mục load-balacing-demo: docker-compose up

Ra trình duyệt chạy: http://localhost:8081/

Mỗi lần f5 sẽ cho ra 1 nội dung tương ứng server 1 và 2:

Hello Load balancing from Server 1

Hello Load balancing from Server 2

4. Các thuật toán sử dụng trong Nginx Load Balancer

4.1. Cấu hình Load Balancing theo thuật toán Round Robin

Mở file /etc/nginx/nginx.conf:

upstream backends {

server 172.16.0.21:80;

server 172.16.0.22:80;

}

Cấu hình trên sẽ Forward đều số lượng Request nhận được vào 2 Web server (trọng số 1:1).

Round Robin là thuật toán mặc định của nginx.
Đặc điểm của thuật toán này là các request sẽ được luân chuyển liên tục giữa các server 1:1 , điều này sẽ làm giải tải cho các hệ thống có lượng request lớn và mức chịu tải của các Server là như nhau.

4.2. Cấu hình Load Balancing theo thuật toán Weighted

Mở file /etc/nginx/nginx.conf:

upstream backends {

server 172.16.0.21:80 weight=3;

server 172.16.0.22:80 weight=2;

}

Cấu hình trên có nghĩa là cứ 5 request gửi tới server sẽ có 3 request vào web server 1 và 2 request vào web server 2.

Đây là một thuật toán quan trọng trong load balancing, khi sử dụng thuật toán này sẽ giúp chúng ta giải quyết đươc bài toán phân chia các server xử lý. Với mặc định của nginx sử dụng thuật toán round-robin thì các request sẽ được chuyển luân phiên đến các server để xử lý, tuy nhiên đối với Weighted load balancing thì chúng ta sẽ phân ra được khối lượng xử lý giữa các server.
Ví dụ chúng ta có 2 server dùng để load balancing muốn cứ 5 request đến thì 4 dành cho server 1, 1 dành cho server 2 hay các trường hợp tương tự thì weighted load balancing là sự lựa chọn hợp lý.

4.3. Cấu hình Load Balancing theo thuật toán Least connection

Mở file /etc/nginx/nginx.conf:

upstream backends {

least_conn;

server 172.16.0.21:80;

server 172.16.0.22:80;

}

Cấu hình trên sẽ chuyển request đến cho server đang xử lý ít hơn làm việc.

Đây là thuật toán nâng cấp của round robin và weighted load balancing, thuật toán này sẽ giúp tối ưu hóa cân bằng tải cho hệ thống.
Đặc điểm của thuật toán này là sẽ chuyển request đến cho server đang xử lý ít hơn làm việc, thích hợp đối với các hệ thống mà có các session duy trì trong thời gian dài, tránh được trường hợp các session duy trì quá lâu mà các request được chuyển luân phiên theo quy tắc định sẵn, dễ bị down 1 server nào đó do xử lý qúa khả năng của nó.

4.4. Cấu hình Load Balancing theo thuật toán Health Check

Để mang lại hiệu quả cân bằng tải tốt nhất ta có thể cấu hình thêm nhiều Option cho từng Server.

Mở file /etc/nginx/nginx.conf:

upstream backends {

least_conn;

server 172.16.0.21:80 max_fails=1 fail_timeout=10s;

server 172.16.0.22:80 max_fails=1 fail_timeout=10s;

}

Cấu hình trên sẽ chuyển request đến cho server đang xử lý ít hơn làm việc. Trong đó:

max_fails=1 Số lần tối đa thử kết nối đến Server Backend.
fail_timeout=10s khoảng thời gian mà load balancer sẽ chờ Server Backend trả lời.

Sau khoảng thời gian này, Server sẽ bị Khởi động lại Nginx: systemctl restart nginx.service

Khi này, nếu 2 web server vẫn hoạt động bình thường thì Nginx vẫn Forward vào server có ít request hơn.

Nhưng khi một trong 2 server bị Shutdown, Stop Service hoặc mất kết nối thì Nginx sẽ nhận ra và chuyển toàn bộ request vào server còn lại.

Để mang lại hiệu quả cân bằng tải tốt nhất ta có thể cấu hình thêm nhiều Option cho từng Server.

Mở file /etc/nginx/nginx.conf:

upstream backends {

ip_hash;

server 172.16.0.21:80 max_fails=1 fail_timeout=10s;

server 172.16.0.22:80 max_fails=1 fail_timeout=10s;

}

Thuật toán hash sẽ dựa trên 3 octer đầu tiên trên IP của client để quyết định xem client này sẽ được map cố định với server nào. Thích hợp với những ứng dụng cần giữ lại session của người dùng. Khi ta thêm hoặc bớt một server trong pool thì các giá trị hash này sẽ được phân bố lại (mất session). Ta có thể dùng thêm một tham số bổ trợ là consistent để giảm thiểu ảnh hưởng của khi phân phối lại các giá trị hash.

Một số chỉ thị về load balance trong file config của nginx

Module	Công dụng
ip_hash	Chỉ thị này khai báo với Nginx sử dụng thuật toán ip_hash. Forward request đến các các upstream (backend) server bằng cách hash 3 octet đầu tiên của IP client.
least_conn	Chỉ thị này khai báo với Nginx sử dụng thuật toán Least connection. Ưu tiên Forward request đến upstream (backend) server nào có ít kết nối đang hoạt động nhất.
server	Mỗi chỉ thị server tương ứng với 1 upstream server/socket. Một số Option có thể cấu hình đi kèm gồm: weight: trọng số ưu tiên của server. max_fails: Số lần tối đa mà load balancer không liên lạc được với server này (trong khoảng fail_timeout) trước khi server này bị coi là down. fail_timeout: khoảng thời gian mà một server phải trả lời load balancer, nếu không trả lời thì server này sẽ bị coi là down. Đây cũng là thời gian downtime của server này. backup: những server nào có thông số này sẽ chỉ nhận request từ load balancer một khi tất cả các server khác đều bị down. down: chỉ thị này cho biết server này hiện không thể xử lý các request được gởi tới. Load balancer vẫn lưu server này trong danh sách nhưng sẽ không phân tải cho server này cho đến khi chỉ thị này được gỡ bỏ.