Các loại Cân bằng tải (Load Balancer) trên nền tảng đám mây
Bài viết này Bizfly Cloud sẽ giúp bạn tìm hiểu về các loại cân bằng tải khác nhau trên nền tảng đám mây.
Cho đến hiện tại, cân bằng tải cũng tồn tại khá lâu đời kể từ khi Internet xuất hiện. Từ lớp mạng tới TCP tới HTTP, các gói, các kết nối và yêu cầu đến đều được phân phối thường xuyên trên các tài nguyên để đảm bảo hiệu suất và tính khả dụng của ứng dụng.
Những thành phần kể trên khá quan trọng vì chúng có tác động trực tiếp lên các kiểu triển khai mà bạn có thể thực thi. Và tóm lại, nếu không có sự hiển thị trong HTTP, bạn sẽ không thể thực hiện các mẫu nâng cao hơn dựa trên những thứ như URI hoặc loại nội dung.
Tất cả cân bằng tải đòi hỏi chúng ta phải đưa ra quyết định chuyển tiếp gói/yêu cầu ở đâu. Đây là nơi mà sự khác biệt giữa mạng, kết nối và cân bằng tải ứng dụng trở nên quan trọng. Mỗi quyết định dựa trên các đặc điểm cụ thể có thể cho phép hoặc cản trở khả năng của bạn trong việc thực thi các kiểu triển khai nhất định.
Cân bằng tải sử dụng network
Loại cân bằng tải này dựa trên thông tin lớp mạng thích hợp. Nguồn và đích IP cùng với cổng TCP (trong một số trường hợp) tạo nên cơ sở cho các quyết định.
Khi dịch vụ Cân bằng tải sử dụng network nhận được một request, nó thường băm IP nguồn và đích (và cổng TCP) và sau đó chọn một tài nguyên đích. Sau đó, request được gửi đến tài nguyên.
Cân bằng tải sử dụng network có lợi thế là nhà sản xuất quyết định nhanh nhất trong tất cả các thuật toán cân bằng tải. Nó có nhược điểm là không cân bằng lưu lượng truy cập. Điều này có nghĩa là NLB (Network Load Balancing) thường định tuyến lưu lượng truy cập hơn là việc cân bằng trên các nguồn tài nguyên. NBL đã cố gắng, nhưng có những tình huống mà nó đã thất bại vì nó mắc phải vấn đề "mega-proxy".
>> Tìm hiểu thêm về Load Balancer tại đây!
Vấn đề mega-proxy xảy ra khi lượng lưu lượng truy cập đáng kể bắt nguồn từ cùng một dải địa chỉ mạng. Điều này dẫn đến tất cả lưu lượng truy cập được gửi đến cùng một tài nguyên, bởi vì không có đủ sự khác biệt trong các biến băm để phân phối trên nhiều tài nguyên. Các nhà phát triển có kinh nghiệm sẽ nhận ra điều này là một vụ va chạm, một vấn đề thường gặp với các thuật toán trên nền băm. Vấn đề với các va chạm càng trầm trọng hơn bởi thực tế là hiệu suất bị ảnh hưởng bởi tải trọng trên tài nguyên đích. Khi tải tăng (trên bất kỳ hệ thống nào), thì hiệu suất sẽ giảm..
Vì vậy, nếu bạn dự định sử dụng một Cân bằng tải sử dụng network cho tiêu thụ doanh nghiệp, bạn có thể gặp phải sự phân phối kém và do đó hiệu suất kém là chuyện xảy ra thường xuyên. Đó là bởi vì hầu hết lưu lượng truy cập của công ty đều đến từ cùng một phạm vi địa chỉ IP. Tuy nhiên, đối với người tiêu dùng, điều này không phải là vấn đề.
Bạn cũng không thể hướng lưu lượng truy cập dựa trên phiên bản ứng dụng (hoặc API) hoặc sử dụng nó để phân phối lưu lượng API trên nhiều dịch vụ, bởi vì nó không có khả năng ước tính được các biến trên nền HTTP, như URI hoặc cookie.
Plain old load balancing (POLB)
POLB là hình thức cân bằng tải gốc trong đó các thuật toán cân bằng tải thực tế mà bạn quen thuộc được đưa vào hoạt động. Round Robin. Least Connections. Fastest Response. Đây là các quy mô thuật toán đáng tin cậy vẫn được sử dụng ngày nay.
POLB dựa trên giao thức và hỗ trợ UDP (truyền trực tuyến) và TCP (hướng kết nối). Các quyết định của POLB dựa trên thuật toán được lựa chọn.
POLB nhận được một yêu cầu và lựa chọn từ một "pool" (đôi khi được gọi là một "farm" hoặc một "cluster") các tài nguyên dựa trên thuật toán. Sau đó, nó chuyển tiếp yêu cầu và dừng hoạt động.
Lợi ích của loại cân bằng tải này là nó tương đối nhanh và có nhiều tùy chọn thuật toán để lựa chọn. Nếu với bạn hiệu suất là tối cao nhất, hãy chọn Fastest Response. Nếu bạn chỉ muốn mở rộng nhanh chóng và dễ dàng, hãy chọn Round Robin.
Nhược điểm của POLB là bạn chỉ có thể thực thi các mẫu triển khai nếu quyết định được dựa trên một số thứ trong HTTP header (như cookie hoặc URI). Tùy thuộc vào dịch vụ cân bằng tải, bạn có thể triển khai các mẫu như thử nghiệm A/B sử dụng các biến như thời gian hoặc bộ đếm để xác định tài nguyên nào cần lựa chọn. Không nhất thiết phải sử dụng cân bằng tải HTTP và bạn vẫn có thể đạt được cùng một loại kết quả.
Plain Old Load Balancing có thể có hoặc không trong suốt, tùy thuộc vào cấu hình. Với NLB, bạn được đảm bảo rằng địa chỉ IP của client (người dùng, thiết bị) mà ứng dụng của bạn nhận được là địa chỉ IP thực của các client. Với một số cấu hình của POLB, địa chỉ IP nhận được bởi ứng dụng của bạn thực sự là địa chỉ IP của proxy cung cấp dịch vụ cân bằng tải. Điều này tương đương với việc có một ít lượng công việc trong ứng dụng của bạn được dùng để loại bỏ địa chỉ IP của client thực. Vì vậy, nếu bạn cần thông tin đó, bạn sẽ buộc phải khai thác trong các tiêu đề HTTP để tìm nó.
Cân bằng tải HTTP
Cân bằng tải HTTP gần như cũng tồn tại từ lâu chẳng kém gì so với POLB. Hình thức đầu của cân bằng tải HTTP đã được đưa trở lại vào khoảng thời gian chuyển giao giữa hai thế kỷ và kể từ lúc đó nó tiếp tục mở rộng khả năng. Ngày nay, bạn có thể quyết định cân bằng tải dựa trên bất kỳ thứ gì đi kèm với request HTTP - từ tiêu đề đến tải trọng, cân bằng tải HTTP cung cấp cho bạn sự linh hoạt lớn nhất trong ba loại cân bằng tải.
Cân bằng tải HTTP đòi hỏi một request HTTP và trong hầu hết các triển khai đưa ra hai quyết định khác nhau. Quyết định đầu tiên dựa trên một biến HTTP và quyết định thứ hai được dựa trên một thuật toán.
Cân bằng tải HTTP là sự kết hợp giữa định tuyến và chuyển tiếp. Nghĩa là, đầu tiên cân bằng tải sẽ định tuyến một request và sau đó chuyển tiếp request dựa trên lựa chọn thuật toán của một tài nguyên. Đây là việc làm cho phép các mẫu triển khai như Canary và Blue/Green Deployments và thử nghiệm A/B mạnh mẽ hơn.
Vấn đề với loại cân bằng tải này là nó thêm độ trễ vào phương trình. Càng đi sâu vào các request HTTP thì độ trễ càng tăng. Một số cân bằng tải có chế độ "fast" chỉ cho phép cân bằng tải dựa trên tiêu đề HTTP để khắc phục sự cố này, nhưng hãy lưu ý rằng nếu bạn đang cố đưa ra quyết định dựa trên một số biến POST ẩn sâu trong HTTP payload thì sẽ phải mất thêm nhiều thời gian hơn.
Một vấn đề chung khác giống với POLB - đó là độ trong suốt. Bạn có thể có hoặc có thể không nhận được địa chỉ IP thực của client với mỗi yêu cầu, vì vậy hãy chắc chắn kiểm tra xem bạn có cần thông tin đó trong ứng dụng của mình hay không.
Như vậy, lời khuyên của chúng tôi là hãy chọn các loại cân bằng tải để phù hợp với cả kiến trúc ứng dụng và mục tiêu cụ thể về quy mô cũng như là tốc độ. Chọn cân bằng tải và thuật toán sai có thể có tác động đáng kể đến khả năng đáp ứng các mục tiêu của bạn.
Theo Bizfly Cloud chia sẻ
