2.1. Thuật toán ngẫu nhiên (random):
Trong thuật toán random, tải sẽ được phân một cách ngẫu nhiên vào trong các web-server. Web server được chọn dựa trên một hàm chọn số ngẫu nhiên, sau đó yêu cầu hiện tại từ phía người dùng sẽ được chuyển vào server này.
Thuật toán này có thể thực hiện như sau:
arrayServer[] == list_of_server(); int n = number_of_active_server; int i = get_random_number(n); proxy ->server = arrayServe[i];
Thuật toán này hầu như không dùng đến trong các bộ cân bằng tải mặc dù nó thường được cài đặt sẵn, nó chỉ thường thấy trong các gói phần mềm lớn mà trong đó cân bằng tải chỉ được đưa ra như một chức năng.
2.2. Thuật toán Round Robin (RR):
RR là thuật toán được dùng thường xuyên nhất trong các hệ thống vừa và nhỏ, có ít đòi hỏi về khả năng mở rộng. Một kết nối mới sẽ được gửi đến server kế tiếp trong cụm server, và cứ quay vòng như vậy. RR làm việc tốt trong mọi cấu hình, nhưng sẽ tốt hơn nếu như các trang thiết bị đang được cân bằng tải khác nhau về tốc độ xử lý, tốt độ kết nối hoặc bộ nhớ.
Một cách để thực thi thuật toán này là sử dụng một server_map. Bộ cân bằng tải sẽ được khai báo như một con trỏ proxy, nó sẽ có biến server_map là một mảng các server và biến srv_rr_idx để chỉ định server tiếp theo trong chu kỳ round robin.
Sample code:
/* Kiểm tra xem có server nào sẵn có không bằng cách kiểm tra kích thước server_map */
if(srv_map_size = 0) return NULL;
if (srv_rr_idx > proxy->srv_map_size)
/* Nếu đến cuối mảng srv_map, update lại giá trị srv_rr_idx */ srv_rr_idx = 0;
int newidx = px->srv_rr_idx; do {
srv = proxy ->srv_map[newidx++]; /* Trả về server và update lại giá trị srv_rr_idx */ return srv;
proxy->srv_rr_idx = newidx;
} while (newidx != px->srv_rr_idx) /* Thực hiện cho đến khi lấy được server tiếp theo */
RR hoạt động tốt khi các server có khả năng xử lý (cấu hình) tương tự nhau, tuy nhiên sẽ có hiện tượng mất cân bằng khi các server có cấu hình khác nhau, hoặc sau một thời gian, số kết nối đang hoạt động ở một server đang nhiều hơn hẳn một server khác, nhưng lượng kết nối tiếp theo mà các server này nhận được vẫn bằng nhau. Do đó một số server sẽ phải xử lý nhiều hơn hẳn các server khác. Tuy vậy, vì tính đơn giản của nó, nên nó hoạt động rất hiệu quả (không phải mất thêm thời gian tính toán các thông số khác nên việc phân tải diễn ra rất nhanh). Nếu các server hoạt động bình thường và không xảy ra sự cố thì sử dụng RR rất tốt.
Điểm yếu của RR là 2 yêu cầu liên tục từ phía một người dùng có thể sẽ được gửi vào 2 server khác nhau. Điều này không tốt vì khi người dùng đang được kết nối vào một server, thông tin mà họ cần đang ở server đó, nếu kết nối tiếp theo vẫn được server đó xử lý thì sẽ góp phần tăng tốc độ đáp ứng cho người dùng. Do đó thuật toán RR thường được cài đặt cùng với các phương pháp duy trì session như sử dụng cookie.
2.3. Thuật toán Weighted Round Robin (Ratio)
Nguyên lý hoạt động của thuật toán WRR cũng giống như thuật toán RR, yêu cầu từ phía người dùng sẽ được bộ cân bằng tải chuyển đến các server theo thứ tự xoay vòng. Sự khác biệt duy nhất ở đây là thuật toán WRR còn quan tâm đến khả năng xử lý (cấu hình) của các server. Trong cùng một chu kỳ, 1 server có khả năng xử lý gấp đôi server khác sẽ nhận được gấp đôi số yêu cầu từ phía bộ cân bằng tải.
Giả sử chúng ta có 4 server A, B, C, D có cấu hình khác nhau, A và B có cấu hình giống nhau, C và D có cấu hình mạnh gấp đôi A. Vậy chúng ta có thể đánh
trọng số cho A và B là 1, C và D là 2. Khi đó theo thuật toán WRR, thứ tự server nhận yêu cầu từ phía bộ cân bằng tải sẽ là ABCDCD
Thuật toán này có thể được thực thi như sau: Giả sử chúng ta một hàng đợi để chứa các server sẽ nhận request. Nếu như 1 server trọng số n, trong hàng đợi sẽ có n chỉ mục (entry) của cùng 1 server này, chẳng hạn như ở ví dụ trên, mỗi server A, B sẽ có 1 chỉ mục, mỗi server C, D sẽ có 2 chỉ mục. Với cách lưu chỉ mục như vậy trong hàng đợi, các server trong WRR sẽ được lấy ra theo thứ tự hoàn toàn giống như RR.
Thuật toán WRR hoạt động tốt hơn RR khi các server trong cluster có cấu hình khác nhau. Tuy nhiên sử dụng thuật toán này có thể dẫn tới sự mất cân bằng tải động nếu như tải của các yêu liên tục thay đổi trong một khoảng rộng (ví dụ như các yêu cầu xem video hoặc tải các file có dung lượng lớn xen kẽ với các yêu cầu đọc thông tin...). Trong một khoảng thời gian ngắn, hoàn toàn có khả năng phần lớn các yêu cầu có tải cao sẽ được chuyển hướng đến cùng một server.
2.4. Thuật toán Dynamic Round Robin - DRR (Dynamic Ratio)
Thuật toán DRR hoạt động gần giống với WRR, điểm khác biệt là trọng số ở đây dựa trên sự kiểm tra server một cách liên tục, do đó trọng số liên tục thay đổi. Đây là một thuật toán động (khác với các thuật toán đã trình bày ở trên đều là thuật toán tĩnh), việc chọn server sẽ dựa trên rất nhiều khía cạnh trong việc phân tích hiệu năng của server dựa trên thời gian thực, chẳng hạn như số kết nối hiện tại đang có trên các server hoặc server trả lời nhanh nhất. Thuật toán này thường không thấy trong các bộ cân bằng tải đơn giản, nó được sử dụng trong các sản phẩm cân bằng tải của F5 Network.
2.5. Thuật toán Fastest
Thuật toán fastest chọn server dựa trên thời gian đáp ứng của mỗi server (response time), thuật toán sẽ chọn server nào có thời gian đáp ứng nhanh nhất. Thời gian đáp ứng được xác định bởi khoảng thời gian giữa thời điểm gửi một gói tin đến server và thời điểm nhận gói tin trả lời. Việc gửi nhận này sẽ được bộ cân bằng tải đảm nhiệm, dựa trên thời gian đáp ứng, bộ cân bằng tải sẽ biết chuyển yêu cầu tiếp theo đến server nào.
Thuật toán fastest thường được dùng khi mà các server được cài đặt dọc theo các mạng logic khác nhau, nghĩa là server được đặt ở nhiều nơi khác nhau. Như vậy người dùng ở gần server nào, thì thời gian đáp ứng đến server đó chắc chắn sẽ nhanh nhất, và server đó sẽ được chọn để phục vụ. Thuật toán này cũng giống như chuyển hướng yêu cầu dựa trên địa chỉ IP. Chẳng hạn như khi người dùng truy cập vào site youtube.com, nếu IP của người dùng đến từ Việt Nam, yêu cầu sẽ được chuyển vào server ở Việt Nam xử lý, điều này sẽ giúp cho tiết kiệm băng thông quốc tế và cải thiện tốc độ đường truyền.
2.6. Thuật toán Least Connections (LC) (adsbygoogle = window.adsbygoogle || []).push({});
Trong thuật toán LC, yêu cầu từ phía người dùng sẽ được chuyển vào server có ít kết nối nhất trong hệ thống tại thời điểm đó. Thuật toán này được coi như thuật toán động, vì nó cần phải đếm số kết nối "đang hoạt động" của các server. Với một hệ thống có các server gần giống nhau về cấu hình, LC có khả năng hoạt động tốt ngay cả khi tải của các kết nối biến thiên trong một khoảng lớn. Do đó sử dụng LC sẽ khắc phục được nhược điểm của RR.
Giả sử chúng ta có n server Si, i = 1, 2,...n. Số lượng connections đang hoạt động là Ci với i = (1, 2,...,n). ALL_CONNECTIONS là tổng Ci.
Yêu cầu tiếp theo sẽ được chuyển đến server j, trong đó:
Cj/ALL_CONNECTIONS = min {Ci/ALL_CONNECTIONS }, i = (1, 2,...,n).
Vì giá trị ALL_CONNECTIONS là không đổi tại thời điểm tính nên chúng ta có thể chọn server Cj theo công thức:
Cj = min {Ci}, i = (1, 2,...,n).
Nhìn bên ngoài có vẻ như LC cũng có khả năng hoạt động tốt khi các server có cấu hình biến thiên khác nhau, trên thực tế điều đó là không đúng. Vậy thì nguyên nhân ở đâu? Đó chính là do trạng thái TIME_WAIT của TCP. TIME_WAIT này thường được đặt là 2 phút, trong 2 phút đó một website "bận rộn" có thể nhận tới hàng chục ngàn kết nối liên tục, giả sử như server A có khả năng xử lý gấp đôi server B, server A đang xử lý hàng ngàn yêu cầu và giữ những yêu cầu này trong trạng thái TIME_WAIT của TCP, trong khi đó server cũng phải xử lý hàng ngàn yêu cầu như server A, nhưng vì cấu hình server B yếu hơn nên sẽ chậm
chạp hơn rất nhiều. Như vậy, thuật toán LC hoạt động không tốt khi các server có cấu hình khác nhau.
2.7. Thuật toán Observed
Observed là sự kết hợp giữa Least Connections và Fastest Response, nó chỉ tồn tại trong các giải pháp của F5-Network. Ở đây người phát triển hệ thống sẽ phải cân bằng giữa 2 yếu tố: số kết nối đến một server và thời gian đáp ứng giữa chúng. Nghĩa là, cũng giống như đánh trọng số cho các server, 2 yếu tố này sẽ có những trọng số nhất định giữa trên nhận định của người phát triển hệ thống hoặc nhà quản trị. Một phép toán số học dựa trên số kết nối của một server, thời gian đáp ứng và các trọng số sẽ đưa ra cho mỗi server một giá trị. Dựa trên giá trị đó, bộ cân bằng tải sẽ chọn được server phù hợp.
Nếu như được thiết kế tốt, Observed sẽ khắc phục được nhược điểm của cả Least Connections và Fastest Response. Thuật toán Least Connections không chú trọng vào “không gian” nghĩa là một người dùng truy cập ở Hà Nội có thể được kết nối vào server ở T.P Hồ Chí Minh, vì số kết nối ở đó đang ít nhất. Như vậy là không cần thiết, vì nếu chuyển kết nối người dùng này vào server Hà Nội thì thời gian phục vụ sẽ giảm xuống và sẽ tiết kiệm được rất nhiều băng thông. Trong khi đó Fastest Response sẽ đưa người dùng vào server có thời gian đáp ứng tốt nhất bất kể số kết nối tại đó nhiều hay ít, nếu như máy chủ đó sắp quá tải, có thể sẽ dẫn đến bị treo nếu như quá nhiều người ở địa điểm đó truy cập vào. Sự cân bằng giữa số kết nối và thời gian đáp ứng sẽ giúp cho bộ cân bằng tải chọn được server phù hợp nhất.
Observed được đưa ra bởi F5-Network, và hầu như không tồn tại trong các phần mềm cân bằng tải mã nguồn mở hay các phần mềm nhỏ.
2.8. Thuật toán Predictive
Là sự phát triển tiếp theo của Observed, nhưng trong thuật toán Predictive, hệ thống sẽ phân tích trạng thái của các server theo thời gian, xác định xem thời điểm nào thì hiệu năng của server đang tăng lên, thời điểm nào đang giảm xuống. Như vậy, giả sử như 2 server theo đánh giá của thuật toán Observed là tương đương nhau, server nào có hiệu năng biến đổi theo chiều hướng tốt hơn sẽ được chọn.
CHƢƠNG III
CÀI ĐẶT BỘ CÂN BẰNG TẢI HAPROXY
Có nhiều phương pháp từ đơn giản đến phức tạp để cài đặt một bộ cân bằng tải vào hệ thống website, ứ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, em 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, em xin trình bày sơ qua về các tính năng của Haproxy.