Trong phần này, NVLV xin trình bày một số phương pháp cài đặt bộ cân bằng tải vào hệ thống website. Có nhiều phương pháp từ đơn giản đến phức tạp, ứng dụng trong nhiều trường hợp khác nhau. Với một số website nhỏ, chỉ có một vài server đặt trong cùng mạng LAN, chúng ta có thể sử dụng phương pháp cài đặt đơn giản với một bộ cân bằng tải cài đặt trước các server, kết hợp với kỹ thuật cookie-insert. Trong một hệ thống lớn hơn, để tránh quá tải cho bộ cân bằng tải, chúng ta có thể cài đặt 2 bộ cân bằng tải hoạt động theo cơ chế active-backup, nhằm đảm bảo nếu như một trong 2 bộ cân bằng tải bị “chết”, vẫn còn một bộ dự phòng, để chắc chắn rằng hệ thống luôn hoạt động. Kết với với các phương pháp này là một số hình thức cài đặt cookie và sử dụng các luật ngữ cảnh (content rules) theo yêu cầu của từng website khác nhau.
Để thấy được mô hình cài đặt một cách tốt nhất, NVLV sẽ dùng một bộ cân bằng tải mã nguồn mở có sẵn để làm mô hình. Bộ cân bằng tải có tên là Haproxy có đầy đủ chức năng của một bộ cân bằng tải đơn giản. Trước khi đi vào chi tiết cài đặt bộ cân bằng tải, NVLV xin trình bày sơ qua về các tính năng của Haproxy.
1.1 Bộ cân bằng tải Haproxy
Haproxy là một giải pháp cân bằng tải với khả năng mở rộng cao, được cài đặt cho những website chạy các ứng dụng dựa trên TCP và HTTP. Haproxy là một giải pháp mã nguồn mở được phát triển trên hệ điều hành Linux. Trong phiên bản mới nhất, Haproxy hỗ trợ chuyển mạch ngữ cảnh (content switching) cho phép người quản trị website có thể thiết đặt các luật của chuyển mạch trong file cấu hình.
Bên cạnh đó, Haproxy còn có số lượng thuật toán phân tải phong phú, khả năng ngăn chặn các cổng không cần thiết theo nhu cầu của người quản trị, hỗ trợ các phương pháp cài đặt cookie và khả năng hoạt động “trong suốt” giúp tăng tốc độ truyền dẫn dữ liệu. Có thể kể ra rất nhiều website sử dụng Haproxy như redwall Firewall tại địa chỉ http://www.redwall-firewall.com/, Exceliance’s ALOHA appliance tại địa chỉ http://www.exceliance.fr/en/index.htm, http://www.loadbalancer.org/, Amazon EC2 tại địa chỉ http://aws.amazon.com/ec2/, hay website Việt Nam như www.tamtay.vn.
Haproxy là một ứng dụng chạy độc lập, tất cả những gì người dùng phải làm là cài đặt Haproxy lờn một mỏy server và thiết lập file cấu hỡnh, trong đú chỉ rừ địa chỉ cài đặt Haproxy và địa chỉ các máy server. Mỗi server sẽ được đặt các thông số khác nhau về địa chỉ server, cookie, trọng số…File cấu hình này cũng sẽ thiết lập các thông số về timeout của session, số lượng kết nối lớn nhất, cookie, thuật toán
cân bằng tải, các luật chuyển mạch ngữ cảnh. Một ví dụ đơn giản về file cấu hình như sau:
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice #log loghost local0 info maxconn 4096
#debug #quiet
user haproxy group haproxy defaults
log global mode http option httplog option dontlognull retries 3
redispatch
maxconn 2000 # Number of max connections contimeout 5000 # Connection timeout
clitimeout 50000 # Client timeout srvtimeout 50000 # Server timeout listen webfarm 192.168.1.99:80 # Haproxy address mode http
stats enable # for statistics
stats auth someuser:somepassword # password stats balance roundrobin # Balance in round-robin mode cookie JSESSIONID prefix # Cookie rewrite
option httpclose option forwardfor
option httpchk HEAD /check.txt HTTP/1.0
server webA 192.168.1.102:80 cookie A check #Server A server webB 192.168.1.103:80 cookie B check #Server B
Các thông số được giải thích như trong phần chú thích (sau dấu ‘#’). Trong đó có một vài thông số đáng lưu ý như:
”listen webfarm 192.168.1.99:80 # Haproxy address”
Server cài đặt Haproxy ở địa chỉ 192.168.1.99, listen trên cổng 80, người dùng sẽ truy cập vào website theo địa chỉ này và với họ đây là web-server duy nhất của website. Thông số quan trọng tiếp theo là thuật toán cân bằng tải:
”Balance roundrobin # Balance in round-robin mode”
Bộ cân bằng tải được cài đặt theo thuật toán phân tải round-robin. Haproxy phiên bản mới nhất hỗ trợ các thuật toán phân tải đa dạng như: round-robin, least connections, uri check, url check và source hash. Các website khác nhau sẽ có thể chọn thuật toán phù hợp với yêu cầu của người dùng hoặc tại thời điểm cụ thể.
Thông số quan trọng thứ ba là địa chỉ các server thực chứa website.
server webA 192.168.1.102:80 cookie A check #Server A server webB 192.168.1.103:80 cookie B check #Server B Hai server này được cài ở 2 máy trong cùng mạng LAN với bộ cân bằng tải, đều phục vụ trên cổng 80 và đều chứa cookie. Các thông số còn lại của file cấu hình có thể tìm hiểu thêm ở phần phụ lục của đồ án này.
Tuy hoạt động khá hiệu quả nhưng tính tùy biến và khả năng hỗ trợ người phát triển của Haproxy rất kém, phần mềm được viết bằng ngôn ngữ lập trình C trên hệ điều hành GNU/Linux, biên dịch bằng bộ thư viện mã nguồn mở GNU. Trong khuôn khổ đồ án này, NVLV sẽ phát triển Haproxy trên hệ điều hành CentOS
1.2 Cài đặt đơn giản với phương pháp cookie-insert
Phương án đơn giản nhất để cài đặt HAProxy vào hệ thống là cài đặt 1 nó như trong hình 3.1-1. Haproxy được cài đặt ở giữa người dùng và cụm webs-server, tại địa chỉ 192.168.1.1, 4 web-servers và một database server được cài đặt tại các máy trong cùng mạng LAN với HAProxy. Trong mô hình này, HAProxy được cài đặt theo chế độ HTTP (mode HTTP), sử dụng thuật toán cân bằng tải weighted round-robin (trong một số trường hợp khác, người quản trị hệ thống có thể chọn thuật toán least connections). HAProxy sử dụng chèn cookie với lựa chọn kiểm tra header của dữ liệu vào ra.
Bốn web-servers được cài đặt tại các địa chỉ từ 192.168.1.11 đến 192.168.1.14, để đơn giản, chúng ta giả sử 4 server này có cấu hình tương đương nhau và do đó trọng số của chúng là giống nhau. Với giả sử mỗi server có số lượng kết nối lớn nhất là 4096, và mỗi server có cookie là tên của chúng.
H 3.1-1 Mô hình cân bằng tải đơn giản với một bộ cân bằng tải
Trong file cấu hỡnh của haproxy phải chỉ rừ địa chỉ nhận yờu cầu từ phớa người dựng (haproxy), địa chỉ cỏc web-server và chỉ định rừ phương phỏp dựng cookie. Các thông số đó được mô tả như sau:
#...
listen webfarm 192.168.1.1:80 mode http
balance roundrobin
cookie SERVERID insert indirect
option httpchk HEAD /index.html HTTP/1.0
server webA 192.168.1.11:80 maxconn 4096 cookie A check server webB 192.168.1.12:80 maxconn 4096 cookie B check server webC 192.168.1.13:80 maxconn 4096 cookie C check server webD 192.168.1.14:80 maxconn 4096 cookie D check
#...
Luồng dữ liệu của chương trình:
- Bộ cân bằng tải nhận yêu cầu từ phía người dùng.
- Nếu yêu cầu không chứa cookie, nó sẽ được chuyển đến server nào đó theo thuật toán cân bằng tải của bộ cân bằng tải.
- Dữ liệu trả về cho người dùng sẽ được chèn thêm cookie “SERVERID” với giá trị là tên của server, chẳng hạn “A”.
- Khi người dùng trở lại với yêu cầu có chứa cookie SERVERID=A, bộ cân bằng tải sẽ chuyển yêu cầu này vào server A.
- Nếu server A bị “chết”, bộ cân bằng tải sẽ gửi yêu cầu đến một server khác và dữ liệu trả về sẽ chèn thêm cookie của server này.
Hình 3.1-2 mô tả luồng dữ liệu của chương trình:
H 3.1-2 Luồng dữ liệu trong mô hình đơn giản
Nhược điểm của phương pháp này là bộ cân bằng tải không thể xác định được server cần chuyển yêu cầu nếu như nó gặp một cookie lạ. Khi mà trình duyệt của người dùng được đặt chế độ keep-alive (HTTP/1.1), sau khi dữ liệu được trả về lần đầu tiên, trình duyệt của người dùng sẽ đọc cookie từ phía server và lưu nó vào trong ổ đĩa cứng, các lần truy cập sau bộ cân bằng tải sẽ không cần chèn cookie trong trả về nữa vì người dùng đã có sẵn. Nếu như vì một lý do nào đó mà cookie ở trình duyệt của người dùng bị chỉnh sửa đi, những lần truy cập sau của người dùng sẽ gửi đến bộ cân bằng tải 1 cookie mà nó không hiểu. Khi đó bộ cân bằng tải sẽ không biết phải chuyển yêu cầu này vào server nào, và do đó yêu cầu này sẽ không được phục vụ.
Chẳng hạn như có 4 server có mã cookie là A, B, C, D như trong file cấu hình ở trên. Nhưng bộ cân bằng tải lại đọc được một yêu cầu từ phía người dùng là
“SERVERID=E”, nú sẽ khụng xử lý yờu cầu này vỡ rừ ràng là cú cookie nờn khụng thể chuyển nó theo chế độ cân bằng tải, nhưng đọc cookie lại không nhận biết được server nào. Chúng ta có thể khắc phục nhược điểm này bằng cách tắt chế độ keep- alive ở trình duyệt người dùng. Trong file cấu hình của hệ thống, chúng ta thêm vào lựa chọn: “option httpclose”. Như vậy trình duyệt từ phía người dùng sẽ có thế đọc được nhiều cookie được gửi về từ server.
Nhược điểm thứ 2 là bộ cân bằng tải lúc này trở thành một SPOF, nếu nó ngừng hoạt động, toàn bộ hệ thống sẽ chết. Để khắc phục điều đó, chúng ta phải chuyển qua một thiết kế phức tạp hơn mà trong đó sẽ có nhiều hơn một bộ cân bằng tải. Thiết kế này sẽ giúp khắc phục những nhược điểm của thiết kế đơn giản và có khả năng chống lỗi tốt hơn.
1.3 Cài đặt với khả năng mở rộng cao
Phương pháp này được mô tả trong hình 3.1-3. Sẽ có 2 bộ cân bằng tải được cài đặt tại các máy ở địa chỉ 192.168.1.3 và 192.168.1.4. Bốn web-servers và DB server được cài đặt ở các máy trong cùng mạng LAN như hình vẽ. Lúc này, 2 bộ cân bằng tải sẽ chia sẻ cùng một địa chỉ IP ảo là 192.168.1.1, người dùng sẽ truy cập website ở địa chỉ IP ảo này và họ chỉ cần biết đến nó. Vậy thì làm cách nào để cho 2 bộ cân bằng tải có thể cùng chia sẻ một địa chỉ IP ảo này? Chúng ta sẽ sử dụng một ứng dụng gọi là keepalived.
H3.1-3 Mô hình phức tạp với 2 bộ cân bằng tải chia sẻ 1 địa chỉ IP ảo
Keepalived là một ứng dụng cho phép 2 bộ cân bằng tải cài đặt cùng với nó hoạt động theo cơ chế active/backup, nếu bộ cân bằng tải master bị “chết”, bộ cân bằng tải còn lại sẽ thực hiện nhiệm vụ cân bằng. Được thiết kế dành riêng cho các dự án Linux Virtual Server ( www.linux-vs.org/ ), keepalived có khả năng kiểm tra các server trong cụm, nhận biết các server không hoạt động và loại bỏ chúng ra khỏi cụm server. Trong mô hình của chúng ta, keepalived sẽ có nhiệm vụ kiểm tra 2 bộ cân bằng tải. Thông tin chi tiết hơn về keepalived có thể tìm trên website www.keepalived.org/.
Quay trở lại với mô hình chúng ta đang cài đặt. Với keepalived, 2 bộ cân bằng tải sẽ hoạt động theo cơ chế active-backup, người dùng sẽ truy cập vào địa chỉ IP ảo 192.168.1.2,và sẽ được chuyển hướng và bộ cân bằng tải đang hoạt động ở chế độ active là 192.168.1.3. Từ đó yêu cầu sẽ được cân bằng tải vào một trong các server. Nếu bộ cân bằng tải bị down, keepalived sẽ chuyển bộ cân bằng tải ở địa chỉ 192.168.1.4 thành active, như vậy sẽ tránh được tình trạng bộ cân bằng tải trở thành một SPOF như trong mô hình đơn giản.
Trong mô hình này, chúng ta sẽ chỉ dùng một cookie duy nhất. Ứng dụng sẽ tạo ra một cookie cú tờn là “JSESSIONID” dựng để theo dừi session. Trong dữ liệu trả về cho người dùng, haproxy sẽ chèn thêm tên server vào cookie này. Phương pháp này được gọi là chèn cookie prefix. Như vậy, cấu hình cho 2 bộ cân bằng tải cần phải chỉ rừ địa chỉ nhận yờu cầu là địa chỉ IP ảo, địa chỉ này cũng được chỉ định trong file cấu hình của keepalived. Thêm nữa, cấu hình cho 2 bộ cân bằng tải là hoàn toàn giống nhau vì chúng hoạt động theo chế độ active-backup. Vì bộ cân bằng tải cần phải sửa tất cả các cookie được gửi bởi server và client, vì vậy nó phải được quyền truy xuất tất cả các cookie này, vì vậy cần phải thêm vào tùy chọn option httpclose để disable tùy chọn keep-alive (HTTP/1.1)
#...
listen webfarm 192.168.1.1:80 mode http
balance roundrobin
cookie JSESSIONID prefix option httpclose
option forwardfor
option httpchk HEAD /index.html HTTP/1.0 server webA 192.168.1.11:80 cookie A check server webB 192.168.1.12:80 cookie B check server webC 192.168.1.13:80 cookie C check server webD 192.168.1.14:80 cookie D check
#...
Trong file cấu hỡnh của keepalived cũng phải chỉ rừ địa chỉ listen là 192.168.1.1. Vì keepalived được cài đặt trên cả 2 máy chứa Haproxy nên khi người dùng truy cập vào địa chỉ IP ảo này, keepalived sẽ chuyển hướng yêu cầu đến Haproxy. File cấu hình cho keepalived trên cả 2 máy chứa haproxy được viết như sau:
vrrp_script chk_haproxy {# Requires keepalived-1.1.13 script "killall -0 haproxy" # cheaper than pidof interval 2 # check every 2 seconds weight 2 # add 2 points of prio if OK }
vrrp_instance VI_1 { interface eth0 state MASTER
virtual_router_id 51
priority 101 # 101 on master, 100 on backup virtual_ipaddress {
192.168.1.1 }
track_script { chk_haproxy }
}
Luồng dữ liệu của chương trình được mô tả như trong hình 3.1-4
H3.1-4 Luồng dữ liệu trong mô hình 2 bộ cân bằng tải với keepalived
- Trong cấu hình của keepalived, haproxy cài đặt trên máy 192.168.1.3 (priority = 101) là active, bộ cân bằng tải còn lại là backup (priority = 100), nếu bộ cân bằng tải active không hoạt động, bộ cân bằng tải backup sẽ được thiết đặt priority = 101, và trở thành active.
- Người dùng sẽ truy cập vào website tại địa chỉ 192.168.1.1:80, keepalived sẽ chuyển yêu cầu này đến cho haproxy.
- Cả 2 bộ cân bằng tải gửi các tín hiệu kiểm tra của chúng từ IP gốc.
- Nếu yêu cầu không chứa cookie, nó sẽ được chuyển đến server phù hợp.
- Trong dữ liệu trả về, nếu có cookie JSESSIONID, haproxy sẽ chèn thêm tên server vào cookie này, chẳng hạn như với cookie “JSESSIONID=123”, trả về từ server A haproxy sẽ chèn thêm thành “JSESSIONID=A~123”.
- Nếu người dùng sử dụng truy cập lại với cookie “JSESSIONID=A~123”, haproxy sẽ biết phải chuyển yêu cầu tới server A, và tên server A sẽ bị loại ra khỏi cookie trước khi nó được chuyển đến server.
- Nếu server web A bị “chết”, bộ cân bằng tải sẽ chuyển yêu cầu đến một server khác và cookie sẽ được chèn lại theo tên của server này.