2.6.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. Webserver được lựa 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 được mô tả như sau:
arrayServer [] == list_of_server (); int n = number_of_active_server; int i = get_random_number (n);
proxy ->server = arrayServer [i];
1) Khi nhận được yêu cầu từ phía người dùng hệ thống sẽ kiểm tra trạng thái các server để xem chúng có đang hoạt động hay đang gặp phải sự cố.
2) Lập danh sách các server đang hoạt động để đáp ứng các yêu cầu từ phía client. 3) Sử dụng hàm số chọn ngẫu nhiên random trong danh sách các server hoạt động. 4) Gửi request tới server được chọn, server này sẽ trả về kết quả cho người dùng.
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 và 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.6.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 rất 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ốc độ kết nối hoặc bộ nhớ.
Thuật toán thực hiện theo các bước sau:
1) Đầu tiên, khi nhận được request từ phía người dùng hệ thống sẽ kiểm tra trạng thái các server để xem chúng có đang hoạt động hay đang gặp phải sự cố. 2) Lập danh sách các server đang hoạt động để đáp ứng yêu cầu và đánh số các
server theo thứ tự.
3) Các yêu cầu lần lượt sẽ được phân vào các server theo thứ tự: - Yêu cầu thứ nhất sẽ được gửi đến server thứ nhất
- Yêu cầu thứ hai sẽ được gửi đến server thứ hai. - …..
- Yêu cầu thứ n sẽ được gửi đến server thứ n.
4) Khi nhận được các request gửi đến thì server sẽ gửi lại kết quả trả về cho người dùng.
5) Nếu như số server cuối cùng thứ n đã thực hiện xong việc đáp ứng yêu cầu thì thứ tự lại tiếp tục được quay vòng lại. Tức là yêu cầu tiếp theo thứ n+1 sẽ được gửi đến server thứ 1 và tiếp tục theo thứ tự danh sách của các server. 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 server sẽ phải xử lý nhiều hơn hẳn các server khác. RR có tính đơn giả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 như 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à hai 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 hai 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. Một kỹ thuật cân bằng tải điển hình trong thuật toán này là RRDNS (Round Robin DNS). Với giải pháp này, nếu như có một server trong nhóm bị lỗi thì RRDNS vẫn sẽ tiếp tục gửi các yêu cầu đến server đó cho đến khi phát hiện ra lỗi và tách server này ra khỏi danh sách địa chỉ DNS. Điều này sẽ gây ra sự đứt quãng dịch vụ.
2.6.3 Thuật toán Weighted Round Robin (Ratio)
Nguyên lý hoạt động của thuật toán Weighted Round Robin (WRR) này 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ỳ, một server có khả năng xử lý gấp đôi server khác sẽ nhận được gấp đôi yêu cầu từ phía bộ cân bằng tải.
Thuật toán thực hiện theo các bước sau:
1) Đầu tiên, khi nhận được yêu cầu từ phía người dùng hệ thống sẽ kiểm tra trạng thái các server để xem chúng có đang hoạt động hay không.
2) Từ các server đang hoạt động, bộ cân bằng tải tiếp tục thực hiện việc kiểm tra cấu hình (khả năng xử lý, đáp ứng yêu cầu) của các server đó.
3) Lập danh sách các server đáp ứng yêu cầu và đánh trọng số các server theo cấu hình của mỗi server.
Giả sử có 3 server A,B,C có cấu hình khác nhau, Avà B có cấu hình giống nhau, C 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 là 2. Khi đó thứ tự server nhận yêu cầu từ phía bộ cân bằng tải sẽ là ABCC.
4) Các yêu cầu lần lượt sẽ được phân vào các server theo thứ tự đã định: - Yêu cầu thứ nhất sẽ được gửi đến server A
- Yêu cầu thứ hai sẽ được gửi đến server B - Yêu cầu thứ ba sẽ được gửi đến server C - Yêu cầu thứ tư sẽ được gửi đến server C - Yêu cầu thứ năm sẽ được gửi đến server A
- …
5) Khi nhận được các yêu cầu gửi đến thì server sẽ gửi lại kết quả trả về cho người dùng.
6) Khi server cuối cùng C đã thực hiện xong việc đáp ứng yêu cầu thì thứ tự lại tiếp tục được quay vòng lại. Tức là yêu cầu tiếp theo sẽ được gửi đến server A và tiếp tục theo trọng số của các server.
Trong thuật toán này có thể được thực thi như sau: giả sử có một hàng đợi để chứa các server sẽ nhận request. Nếu như một server trọng số n, trong hàng đợi sẽ có n chỉ mục (entry) của cùng một server này, chẳng hạn như ở ví dụ trên, mỗi server A,B sẽ có một 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ư trong thuật toán 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 cầ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.
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 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. Không thể sử dụng WRR và xây dựng lại hàng đợi dựa trên trọng số thay đổi của các server, có thể dùng một con trỏ cấu trúc để lưu lại các server, mỗi lần tạo một kết nối mới cho server nào đó sẽ phải tính toán lại vị trí của nó trong struct.
Thuật toán thực hiện theo các bước sau:
1) Đầu tiên, khi nhận được yêu cầu từ phía người dùng hệ thống sẽ kiểm tra trạng thái các server để xem chúng có đang hoạt động hay không.
2) Từ các server đang hoạt động, bộ cân bằng tải tiếp tục thực hiện việc kiểm tra cấu hình (khả năng xử lý, đáp ứng yêu cầu) của các server đó, đồng thời thực hiện phân tích hiệu năng của server dựa trên thời gian thực như số kết nối hiện tại hay thời gian đáp ứng nhanh nhất.
3) Lập danh sách các server đáp ứng yêu cầu, đánh trọng số các server theo cấu hình và hiệu năng của mỗi server.
Giả sử có 3 server A,B,C trong đó: B có cấu hình mạnh gấp đôi A, nhưng A lại có thời gian đáp ứng nhanh nhất. Vậy trọng số cho các server như sau: C là 1, A và B là 2. Khi đó thứ tự server nhận yêu cầu từ phía bộ cân bằng tải sẽ là ABABC.
4) Các yêu cầu lần lượt sẽ được phân vào các server theo thứ tự đã định: - Yêu cầu thứ nhất sẽ được gửi đến server A
- Yêu cầu thứ hai sẽ được gửi đến server B - Yêu cầu thứ ba sẽ được gửi đến server A - Yêu cầu thứ tư sẽ được gửi đến server B - Yêu cầu thứ năm sẽ được gửi đến server C
5) Các server nhận được yêu cầu sẽ gửi lại kết quả trả về cho người dùng.
6) Khi server cuối cùng C đã thực hiện xong việc đáp ứng yêu cầu thì thứ tự lại tiếp tục được quay vòng lại. Tức là yêu cầu tiếp theo sẽ được gửi đến server A và tiếp tục theo trọng số của các server.
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 thực hiện theo các bước sau:
1) Khi nhận được yêu cầu từ phía người dùng hệ thống sẽ kiểm tra trạng thái các server để xem chúng có đang hoạt động hay không.
2) Tiếp tục thực hiện việc kiểm tra thời gian đáp ứng của các server đượ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 .
3) Dựa trên thời gian đáp ứng của các server, server nào có thời gian đáp ứng nhanh nhất thì sẽ được chọn để gửi yêu cầu đến.
4) Khi nhận được yêu cầu, server sẽ thực hiện gửi kết quả trả về cho người dùng. 5) Với yêu cầu tiếp theo, bộ cân bằng tải lại tiếp tục thực hiện kiểm tra thời gian
đáp nhanh nhất của các server (quay lại bước 1).
Thuật toán Fastest thường được dùng khi 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ụ yêu cầu từ người dùng. 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 website youtube.com, nếu IP của người dùng đến từ Việt Nam thì yêu cầu sẽ được chuyển đến server tại 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.6 Thuật toán Least Connections (LC)
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 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.
Thuật toán thực hiện theo các bước sau:
1) Khi nhận được yêu cầu từ phía người dùng hệ thống sẽ kiểm tra trạng thái các server để xem chúng có đang hoạt động hay đang gặp phải sự cố.
2) Thực hiện việc kiểm tra số kết nối của các server tại cùng một thời điểm. 3) Dựa trên số kết nối đó, server nào có số kết nối đang hoạt động là ít nhất thì
sẽ được chọn để gửi yêu cầu.
4) Khi nhận được yêu cầu, server sẽ thực hiện gửi kết quả trả về cho người dùng. 5) Với yêu cầu tiếp theo, bộ cân bằng tải lại tiếp tục thực hiện kiểm tra số kết nối
của các server (quay lại bước 1).
Nhìn bề 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, nhưng trên thực tế điều đó là không đúng. Nguyên nhân 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 nghìn kết nối liên tục. Giả sử như server có khả năng xử lý gấp đôi server B, server A đang xử lý hàng nghìn yêu cầu và giữ lại 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 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.6.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 hai 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, hai 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.
1) Khi nhận được yêu cầu từ phía người dùng hệ thống sẽ kiểm tra trạng thái các server để xem chúng có đang hoạt động hay đang gặp phải sự cố.
2) Từ các server đang hoạt động, thực hiện việc kiểm tra đồng thời cả về thời gian đáp ứng và về số kết nối của các server tại cùng một thời điểm.
3) Dựa trên các yếu tố đó, server nào có thời gian đáp ứng nhanh nhất mà số kết nối đang hoạt động là ít nhất thì sẽ được chọn để gửi yêu cầu.
4) Khi nhận được yêu cầu, server sẽ thực hiện gửi kết quả trả về cho người dùng. 5) Với yêu cầu tiếp theo, bộ cân bằng tải lại tiếp tục thực hiện kiểm tra số kết nối
của các server (quay lại bước 1).
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 ở Thành phố 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 Respnose 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 đó là nhiều hay ít. Nếu máy chủ đó sắp quá tải, có thể sẽ dẫn đến bị treo khi có quá