1. Lý thuyết xây dựng bộ cân bằng tải cho web-servers
1.4. Cân bằng tải sử dụng phần cứng và cân bằng tải phần mềm:
1.4.1. Cân bằng tải sử dụng phần cứng:
Bộ cân bằng tải bằng phần cứng sẽ thể hiện một địa chỉ IP ảo đối với mạng bên ngoài, địa chỉ này bản đồ hóa đến các địa chỉ của mỗi máy trong một cluster. Chính vì vậy toàn bộ các máy tính trong cluster sẽ chỉ được xem như là một máy duy nhất đối với thế giới bên ngoài. Bộ cân bằng tải sử dụng phần cứng thường hoạt động ở tầng mạng và hoạt động dựa trên sự định tuyến, sử dụng một trong các phương pháp: Định tuyến trực tiếp (direct routing), tunnelling, IP address translation (NAT)
Khi một request đến bộ cân bằng tải, nó sẽ ghi lại header của request để trỏ đến các máy khác trong cluster. Nếu một máy nào đó bị gỡ bỏ từ cluster thì request sẽ không chạy một cách rủi ro việc “hit” vào máy server đã chết này, vì tất cả các máy server khác trong cluster xuất hiện đều có cùng địa chỉ IP. Địa chỉ này duy trì giống nhau thậm chí nếu một nút nào đó trong cluster bị hỏng. Khi một đáp trả được trả về, client sẽ xem đáp trả đang đến từ bộ cân bằng tải phần cứng. Hay nói theo cách khác thì người dùng sẽ xử lý với một máy tính đó là bộ cân bằng tải sử dụng phần cứng.
H.2.1-18 Cân bằng tải sử dụng phần cứng
Ưu điểm của phương pháp này là:
- Mối quan hệ giữa các máy chủ. Bộ cân bằng tải phần cứng đọc cookie hoặc các URL đang được đọc trên mỗi một request bởi máy khách. Dựa trên các thông tin này, nó có thể ghi lại các thông tin header và gửi request đến nút thích hợp trong cluster, nơi session của nó được duy trì.
Các bộ cân bằng tải này có thể cung cấp mối quan hệ giữa các máy server trong truyền thông HTTP, nhưng không thông qua kênh an toàn như HTTPS. Trong kênh an toàn, các thông báo được mã hóa SSL và có thể tránh bộ cân bằng tải đọc các thông tin session.
- Khả năng có sẵn cao thông qua hệ thống tự động chuyển đổi dự phòng. Việc chuyển đổi dự phòng xảy ra khi một nút trong cluster không thể xử lý một request và chuyển hướng nó đến một nút khác. Có hai kiểu tự động chuyển đổi dự phòng:
Yêu cầu mức chuyển đổi dự phòng. Khi một nút trong cluster không thể xử
lý một request (thường là vì bị hỏng) thì nó sẽ chuyển request này sang một nút khác.
Chuyển đổi dự phòng session một cách trong suốt. Khi một lời triệu gọi thất bại, nó sẽ được định tuyến một cách trong suốt đến một nút khác trong cluster để hoàn tất công việc.
Bộ cân bằng kiểu này cung cấp chuyển đổi dự phòng mức request; tức là khi nó phát hiện có một nút nào đó bị sự cố thì bộ cân bằng này sẽ chuyển hướng tất cả các request theo sau được gửi đến nút này sang một nút tích cực khác trong cluster. Mặc dù vậy, bất kỳ một thông tin session nào trên nút chết sẽ bị mất khi các request được chuyển hướng đến một nút mới.
Chuyển đổi dự phòng session trong suốt yêu cầu một số kiến thức về sự thực thi cho một quá trình trong một nút, vì bộ cân bằng tải phần cứng chỉ có thể phát hiện các vấn đề mức mạng, không có lỗi. Để thực thi một cách trong suốt về vấn đề chuyển đổi dự phòng, các nút trong cluster phải kết hợp với các nút khác và có vùng bộ nhớ chia sẻ hoặc cơ sở dữ liệu chung để lưu tất cả các dữ liệu session. Cũng chính vì vậy nếu một nút trong cluster có vấn đề thì một session có thể tiếp tục trong một nút khác.
• Metrics. Vì tất cả các yêu cầu tới một ứng dụng web đều phải qua hệ thống
cân bằng tải, hệ thống có thể quyết định số lượng session hoạt động, số lượng session hoạt động được kết nối trong các trường hợp khác nhau, các khoảng thời gian đáp ứng, thời gian tối đa điện áp, số lượng session trong suốt khoảng tối đa điện áp, số lượng session trong suốt khoảng tối thiểu điện áp… Tất cả các thông tin kiểm định này được sử dụng để tinh chỉnh toàn bộ hệ thống nhằm tối ưu hiệu suất.
1.4.2. Cân bằng tải sử dụng phần mềm:
Một bộ cân bằng tải bằng phần cứng giải quyết được vấn đề lost session, nhờ vào cơ chế chuyển đổi dự phòng của nó. Tuy nhiên chi phí rất cao. Điều này là không thể đối với các hệ thống vừa và nhỏ, chính vì vậy mà sự lựa chọn tối ưu hơn ở đây là sử dụng một phần mềm load balancing với giá vừa phải, hay sử dụng các phần mềm load balancing mã nguồn mở. Có rất nhiều phần mềm như vậy trên thị trường, chằng hạn như HAProxy, Squid…. Giải pháp phần mềm thường sử dụng hai thuật toán chính đó là thuật toán cân bằng tải tĩnh (Static LB - DNS Round Robin) và thuật toán cân bằng tải động (Dynamic LB).
2. Các thuật toán cân bằng tải:
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)
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