Load balancer là thiết bị hoặc phần mềm đứng trước nhiều máy chủ, nhận yêu cầu từ người dùng rồi chia về các máy phía sau. Bài này phân loại chúng theo ba cách thường dùng, và nói rõ chọn loại nào cho việc gì.

1. Load balancer giải quyết bài toán gì

Một máy chủ có giới hạn. Khi lượng truy cập vượt giới hạn đó, có hai hướng xử lý:

• Nâng máy lên mạnh hơn. Đơn giản, nhưng có trần, và lúc nâng thì phải dừng dịch vụ.
• Thêm máy chạy song song. Không có trần, nhưng cần một thứ đứng trước để chia việc. Thứ đó là load balancer.

Ngoài chia tải, nó còn mang lại hai thứ mà nhiều người mới để ý sau:

Với nhiều hệ thống, hai lợi ích này còn quan trọng hơn chuyện chia tải.

2. Phân theo tầng: Layer 4 và Layer 7

Đây là cách phân loại quan trọng nhất, vì nó quyết định load balancer hiểu được gì về yêu cầu đang đi qua.

Layer 4, tầng vận chuyển

Làm việc với địa chỉ IP và cổng. Nó không mở gói tin ra đọc nội dung bên trong.

Layer 7, tầng ứng dụng

Đọc hiểu nội dung yêu cầu, với web là đọc được HTTP.

Khác biệt dễ thấy nhất: Layer 7 làm được việc này, Layer 4 thì không:

/api/*     -> nhom may API
/anh/*     -> nhom may chua tep tinh
/*         -> nhom may web

Chia theo đường dẫn cần đọc được đường dẫn, mà đọc được đường dẫn thì phải ở tầng ứng dụng.

3. Phân theo cách triển khai

Thiết bị phần cứng chuyên dụng

Một máy riêng do nhà sản xuất làm sẵn, đặt trong trung tâm dữ liệu.

• Chịu tải rất lớn, độ trễ thấp, ổn định.
• Chi phí đầu tư cao, và mở rộng thì phải mua thêm thiết bị.
• Thường gặp ở nhà cung cấp hạ tầng và doanh nghiệp lớn.

Phần mềm cài trên máy chủ thường

Chạy trên máy chủ ảo hoặc máy chủ vật lý bình thường. Những phần mềm phổ biến:

• Linh hoạt, chi phí thấp, sửa cấu hình là xong.
• Quý Khách hàng tự chịu trách nhiệm vận hành và nâng cấp.
• Bản thân máy chạy load balancer trở thành một điểm cần bảo vệ, xem mục 7.

Dịch vụ do nhà cung cấp vận hành

Nhà cung cấp hạ tầng lo phần thiết bị và vận hành, quý Khách hàng chỉ khai nhóm máy phía sau.

• Không phải tự dựng, không phải tự lo dự phòng.
• Ít tuỳ biến hơn so với tự cài phần mềm.

4. Thuật toán chia yêu cầu

Chia cho máy nào là một quyết định, và các thuật toán khác nhau ở cách ra quyết định đó.

Với phần lớn hệ thống web, ít kết nối nhất cho kết quả đều hơn luân phiên, vì nó tự tránh những máy đang mắc kẹt với một yêu cầu nặng.

5. Kiểm tra sức khoẻ: phần quyết định

Đây là phần đáng đầu tư thời gian nhất, và cũng là phần hay bị cấu hình qua loa nhất.

Load balancer phải biết máy nào còn tốt để ngừng gửi yêu cầu về máy hỏng. Nó biết bằng cách gửi một yêu cầu kiểm tra theo chu kỳ.

Kiểm tra hời hợt: chỉ xem cổng có mở không. Vấn đề là một máy chủ web có thể vẫn mở cổng trong khi ứng dụng bên trong đã chết, hoặc cơ sở dữ liệu đã mất kết nối. Load balancer tưởng máy còn tốt và vẫn gửi người dùng vào đó.

Kiểm tra đúng: gọi một đường dẫn do chính ứng dụng trả lời, và đường dẫn đó tự kiểm những thứ nó phụ thuộc.

GET /trang-thai

Trả về mã 200 khi ứng dụng kết nối được cơ sở dữ liệu và các dịch vụ nó cần; trả về mã khác khi không.

Ba con số nên cân nhắc khi đặt:

6. Giữ phiên: vấn đề thật của ứng dụng cũ

Nếu ứng dụng lưu thông tin đăng nhập hoặc giỏ hàng trong bộ nhớ của chính máy chủ, thì người dùng bị chuyển sang máy khác sẽ mất phiên, tức là bị đăng xuất giữa chừng.

Ba cách xử lý, xếp từ tạm bợ tới đúng đắn:

a. Buộc một người luôn về một máy. Dùng cookie hoặc địa chỉ nguồn. Chạy ngay nhưng có hai nhược điểm: chia tải không đều, và máy đó hỏng thì toàn bộ người đang gắn với nó mất phiên.

b. Chia sẻ phiên giữa các máy. Lưu phiên vào một kho dùng chung, ví dụ Redis hoặc cơ sở dữ liệu. Mọi máy đọc được, nên người dùng vào máy nào cũng được.

c. Không giữ trạng thái trên máy chủ. Phiên nằm trong một thẻ đã ký mà trình duyệt giữ. Đây là cách hợp nhất với hệ thống có nhiều máy.

Cách (a) là cách nên dùng khi chưa kịp làm (b) hoặc (c), không phải đích đến.

7. Bốn chỗ hay sai

Chính load balancer thành điểm chết duy nhất. Dựng nhiều máy chủ để chịu lỗi, rồi đặt trước chúng đúng một load balancer. Máy đó hỏng là sập hết. Cần ít nhất hai, chạy kèm một cơ chế chuyển địa chỉ sang máy còn sống.

Mất địa chỉ thật của người dùng. Từ phía máy chủ nhìn ra, mọi yêu cầu đều đến từ load balancer. Nhật ký mất ý nghĩa, và các quy tắc chặn theo địa chỉ trở nên vô dụng. Khắc phục bằng cách cho load balancer gửi kèm header mang địa chỉ gốc, rồi cấu hình máy chủ web đọc header đó.

Kiểm tra sức khoẻ chỉ xem cổng mở. Xem mục 5.

Các máy phía sau không giống nhau. Chúng phải chạy cùng phiên bản mã nguồn và cùng cấu hình. Lệch nhau thì sinh ra loại lỗi khó chịu nhất: lúc được lúc không, tuỳ người dùng rơi vào máy nào.

8. Chọn loại nào

9. Tại Cloudzone

Quý Khách hàng có thể tự dựng load balancer bằng phần mềm trên máy chủ ảo tại Cloudzone, hoặc trao đổi với đội ngũ kỹ thuật về phương án phù hợp với hệ thống của mình.

Phương án cụ thể phụ thuộc vào lượng truy cập, loại dịch vụ và yêu cầu về thời gian gián đoạn chấp nhận được, nên đây là phần nên trao đổi trực tiếp. Quý Khách hàng liên hệ đội ngũ kinh doanh Cloudzone hoặc nhắn qua ô chat trên trang chủ.

10. Câu hỏi thường gặp

Hai máy chủ đã cần load balancer chưa? Nếu mục tiêu là không gián đoạn khi một máy hỏng thì có, ngay từ hai máy. Nếu chỉ vì tải thì thường chưa, nâng cấu hình một máy đơn giản hơn nhiều.

Load balancer có chống được tấn công từ chối dịch vụ không? Nó giúp phân tán tải nên chịu được một phần, nhưng không thay thế được lớp chống tấn công chuyên dụng. Lưu lượng tấn công lớn vẫn làm nghẽn đường truyền trước khi tới được nó.

Kết nối mã hoá nên kết thúc ở đâu? Kết thúc tại load balancer thì các máy phía sau nhẹ hơn và chứng chỉ quản ở một chỗ. Nếu yêu cầu bảo mật đòi dữ liệu phải mã hoá suốt chặng thì mã hoá lại ở đoạn từ load balancer về máy chủ.

Thêm một máy vào nhóm có phải dừng dịch vụ không? Không. Khai máy mới vào cấu hình, load balancer kiểm tra sức khoẻ, đạt thì bắt đầu gửi yêu cầu về đó.