1. Bộ cân bằng tải sử dụng mã nguồn mở Haproxy:
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 dưới đây. 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.
H.3.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.
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 }
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 dưới đây:
H.3.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.