Triển khai cân bằng tải

Load balancing

• Thành phần quan trọng của cơ sở hạ tầng, hoạt động như một
reverse proxy để phân phối lưu lượng truy cập mạng hoặc ứng dụng
trên một số máy chủ
• Triển khai trước máy chủ và định tuyến các yêu cầu đến tất cả các
máy chủ có khả năng đáp ứng theo cách tối đa hóa tốc độ và dung
lượng, đảm bảo rằng không có một máy chủ nào làm việc quá mức
• Nếu một máy chủ duy nhất gặp sự cố, bộ cân bằng tải sẽ chuyển
hướng lưu lượng truy cập đến các máy chủ trực tuyến còn lại
• Khi một máy chủ mới được thêm vào nhóm máy chủ, bộ cân bằng tải
sẽ tự động gửi yêu cầu đến nó.

2
Load balancing (tiếp)

• Chức năng
• Phân phối các truy vấn của máy khách một cách hiệu quả trên nhiều máy chủ
• Đảm bảo tính khả dụng và độ tin cậy cao bằng cách chỉ gửi yêu cầu đến các
máy chủ trực tuyến
• Cung cấp sự linh hoạt để thêm hoặc bớt các máy chủ

3
Load balancing (tiếp)

• So sánh với Reverse Proxy

• Hoạt động một cổng mà lưu lượng web phải đi qua
• Bảo mật: Không có thông tin nào về máy chủ hiển thị bên ngoài mạng nội bộ, kiểm soát
truy cập
• Tăng tốc web: Cung cấp các tính năng như bộ nhớ đệm, mã hóa SSL
• Tính linh hoạt: Thoải mái thay đổi cấu hình phía sau proxy
• Reverse proxy phù hợp cả với một máy chủ trong hệ thống
• Không có yêu cầu về bộ cân bằng tải nhưng reverse proxy vẫn có thể hữu ích khi cung
cấp tính bảo mật, tính linh hoạt và tăng tốc web

4
Load balancing (tiếp)

• Phân loại
• Layer 4 load balancer xử lý dữ liệu trong các giao thức tầng mạng và giao vận
(IP, TCP, FTP, UDP).
• Layer 7 load balancer phân phối yêu cầu dựa trên dữ liệu tìm thấy trong tầng
ứng dụng, lớp giao thức như HTTP.

5
Load balancing (tiếp)

• Các loại giao thức

• HTTP - HTTP balancing chỉ đạo yêu cầu dựa trên cơ chế HTTP chuẩn. Load
Balancer đặt X-Forwarded-For, X-Forwarded-Proto, và tiêu đề X-Forwarded-
Port để cung cấp cho các thông tin backends về các yêu cầu ban đầu
• HTTPS - HTTPS balancing với các chức năng tương tự như HTTP balancing,
với sự bổ sung của mã hóa
• TCP - Đối với các ứng dụng không sử dụng HTTP hoặc HTTPS, lưu lượng TCP
cũng có thể được cân bằng. Ví dụ, lượng truy cập vào một cụm cơ sở dữ liệu
có thể được lan truyền trên tất cả các máy chủ.
• UDP - Một số load balancer đã thêm hỗ trợ cho cân bằng tải giao thức
internet như DNS và syslogd sử dụng UDP.

6
Load balancing với Nginx

• Round Robin
• Phương pháp này phân phối tải trọng trên các máy chủ có sẵn một
cách ngẫu nhên, chọn một máy chủ thông qua thế hệ số ngẫu
nhiên và gửi kết nối hiện thời cho nó
• Chỉ tốt khi các kết nối tương đương nhau!
• 1s đầu tiên :
• Request 1 ==> server_1 : 3s xử lý
• Request 2 ==> server_2 : 1s xử lý
• s thứ 2 :
• Request 3 ==> server_1 : 3s xử lý
• Request 4 ==> server_2 : 1s xử lý
• s thứ 3 :
• Request 3 ==> server_1 : 3s xử lý
• Request 4 ==> server_2 : 1s xử lý
• Server_1 đang phải xử lý 3 request trong cùng 1 lúc

7
Load balancing với Nginx (tiếp)

• Round Robin
• Có 3 phiên bản của cùng một
ứng dụng đang chạy trên srv1, srv2, srv3
• Khi phương pháp cân bằng tải không được cấu
hình cụ thể, nó sẽ mặc định là quay vòng
• 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.
• Reverse proxy trong nginx bao gồm cân
bằng tải cho HTTP, HTTPS, FastCGI, uwsgi, SCGI, memcached và gRPC

8
Load balancing với Nginx (tiếp)

• Least Connections
• Hệ thống chuyển một kết nối mới tới máy chủ mà có ít nhất số
lượng kết nối nhất hiện tại
• Phương pháp làm việc tốt nhất trong môi trường các máy chủ áp
dụng cân bằng tải có khả năng tương tự nhau
• Phương pháp cân bằng tải động, dựa trên các khía cạnh khác nhau
của máy chủ, như số kết nối mỗi nút hoặc thời gian phản ứng
nhanh nhất của nút ở thời điểm hiện tại.

9
Load balancing với Nginx (tiếp)

• Least Connections
• Công bằng hơn trong tình huống khi một số yêu cầu mất nhiều
thời gian hơn để hoàn thành.
• Cấu hình cân bằng tải least connections được kích hoạt chỉ
thị least_conn:

10
Load balancing với Nginx (tiếp)

• Hash
• Hỗ trợ cân bằng tải qua param, header hay cookies thay vì server
hay traffic
• Cách thức hoạt động :
• Cung cấp 1 key cho nginx, key này có thể là text cũng có thể là argument ,
header hay cookie... của request truyền lên
• Nginx sử dụng key này để mã hóa và check xem key này đã được gắn với
server nào (trong cache)
• Nếu chưa gắn với server nào thì nginx sẽ random server (Theo thuật
toán Round robin ) và cache lại
• Nếu đã gắn với server thì chọn server đó

11
Load balancing với Nginx (tiếp)

• Hash
• Cú pháp:
hash `key` [consistent]
• key:
• Header : $http_session_id ==> Lấy Header có name là : session_id
• Argument : $arg_mobile ==> Lấy Argument có name là : mobile
• Ip address : $remote_addr

12
Load balancing với Nginx (tiếp)

• IP-hash
• Cân bằng tải với roud-robin hoặc least-connected , mỗi yêu cầu của khách sẽ
đến 1 server khác nhau, không có gì đảm bảo rằng cùng 1 máy khách sẽ luôn
được chuyển đến cùng 1 máy chủ
• Với ip-hash, địa chỉ IP của máy khách được sử dụng làm khóa băm để xác
định máy chủ nào trong nhóm máy chủ sẽ được chọn cho các yêu cầu của
máy khách
• Đảm bảo rằng các yêu cầu từ cùng một máy khách 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.

13
Load balancing với Nginx (tiếp)

• Least Response Time (chỉ dùng cho bản trả phí)

• Chọn máy chủ có ít số lượng kết nối hoạt động nhất và thời gian phản hồi
trung bình ít nhất
• Tuy nhiên việc tính độ trễ này phụ thuộc vào tham số đầu vào least_time. Cụ
thể như sau :
• Connect: Thời gian connect đến upstream server
• first_byte: Thời gian nhận về những byte dữ liệu đầu tiên
• last_byte: Thời gian nhận hết toàn bộ dữ liệu

14
Load balancing với Nginx (tiếp)

• Random
• Nginx chọn ra 2 server thỏa mạn thuật toán đi kèm (Trong ví dụ bên trên
là least_conn) sau đó random 1 trong 2 server . Các thuật toán support cho
param two :
• least_conn
• least_time=connect (NGINX Plus)
• least_time=first_byte (NGINX Plus)
• least_time=last_byte (NGINX Plus)

15
Load balancing với Nginx (tiếp)

• Health checks
• Nginx (free) kiểm tra 1 cách thụ động. Nếu 1 server báo ra 1 số lỗi nhất định
nó sẽ bị nginx xóa khỏi danh sách các server được phân phối các request
• Mặc định thì nếu 1 request tới 1 upstream server lỗi hoặc timeout thì server
đó sẽ bị remove 10s .
• Bản chất thì với version FREE, nginx không tự động check health của 1 server
mà chỉ kiểm tra trong lifecycle của 1 incoming request
• Response trả về của server cho dù là lỗi 500 hay 404 thì nginx vẫn tự động
hiểu server đó vẫn tốt

16
Load balancing với Nginx (tiếp)

• Health checks
• Trong ví dụ có đặt 1 cái BẪY bằng directive proxy_next_upstream nếu
response là 404 thì sẽ bị đánh dấu là ko tốt và chuyển qua server khác

• Noài ra chính ta có thể sử dụng 1 số directive để tinh chỉnh lại cách mà server
được đánh dấu là unavaiable
• Max Fails
• Fail Timeout

17
Load balancing với Nginx (tiếp)

• Max Fails
• Directive này sẽ định nghĩa max số lần unhealthy của 1 server trong 1 thời
gian cố định sẽ được config bẳng fail_timeout directive . Nếu con số này bị
vượt quá thì server sẽ bị đánh dấu là unavaiable .
• Directive này sẽ không hoạt động nếu directive fail_timeout có giá trị là 0
• Giá trị mặc định là 1
• Điều kiện để count số lần fail được định nghĩa bằng các directive sau:
• proxy_next_upstream
• fastcgi_next_upstream
• memcached_next_upstream
• grpc_next_upstream

18
Load balancing với Nginx (tiếp)

• Fail timeout
• Config: nếu trong 3s mà server upstream có 2 lần bị đánh dấu là unhealthy
thì server đó sẽ bị remove khỏi danh sách server active để phân phối traffic.
• Tóm lại, directive này có ý nghĩa:
• Khoảng thời gian đặt BẪY để balancer tính toán max_fails
• Khoảng thời gian 1 server (đã bị xem xét là unavailable) bị loại bỏ ra list các server active
• Mặc định thì có giá trị là 10 (tương đương 10s )

19
Load balancing với Nginx (tiếp)

• Down Server
• Ngoài ra để đánh dấu server là không khỏe mạnh, ta cũng có thể cấu hình lại
file config bằng cách thêm hậu tố down vào sau server address trong
upstream directive.
• Trong ví dụ bên trên server_1 sẽ bị down vĩnh viễn (cho đến khi cấu hình lại
server)
• Khi xóa hay comment vào thì các hashes của server đó sẽ bị xóa đi, down sẽ
đảm bảo tính toàn vẹn

20
Load balancing với Nginx (tiếp)

• Backup Server
• Khi bạn đánh dấu 1 server là backup (trong ví dụ nêu trên là server_3 ) thì
trong các server này sẽ ko được phân phối traffic cho đến khi các server
active bị đánh dấu là unavailable
• Mỗi 1 server unavailable thì 1 server backup sẽ được mở ra và thế vào chỗ
của server không tốt đó
• Backup server không được khả dụng khi chúng ta sử dung các thuật toán cân
bằng tải là hash, ip_hash hay là random

21
Load balancing với Nginx (tiếp)

• Weight Server
• Đây là chỉ số thay đổi lưu lượng traffic tới server cụ thể trong một upstream
• Nó cực kì hữu ích nếu có 1 server có hardware vượt trội hơn so với server
khác. Hoặc nếu có 1 server yếu hơn và muốn request ít hơn thì cũng có thể
sử dụng param này.
• Trong ví dụ trên , lượng traffic vào server_1 sẽ gắp đôi lượng traffic
của server_2 . Mặc định thì trọng số này sẽ là 1.

22