Có gợi ý nào về việc khi nào tôi nên sử dụng roundrobin& khi nào nên sử dụng leastconn?
Tôi roundrobinhiện đang sử dụng và quan sát việc tải các dịch vụ back-end của tôi không được phân phối đều. Tất nhiên có thể có vấn đề khác, nhưng chúng tôi muốn leastconnthử, nhưng vì đây là một máy chủ quan trọng, tôi muốn tham khảo kinh nghiệm khác trước khi thực hiện các thay đổi.
Bất cứ ý tưởng để chia sẻ?
Câu trả lời:
Tôi chưa thử nghiệm với lessconn, nhưng sự hiểu biết của tôi là trường hợp sử dụng điển hình cho lessconn là khi bạn đang cân bằng tải một cái gì đó có thể có kết nối lâu dài. Lý do cho điều này là vì ít kết nối nhất tập trung vào việc đảm bảo đồng thời cân bằng trong khi việc cướp đường sẽ mang lại tỷ lệ đến cân bằng hơn . Nếu sự khác biệt này không rõ ràng, hãy xem câu trả lời của tôi về sự khác biệt .
Khi bạn nói tải không được phân phối đều, có thể giúp xác định "tải" tốt hơn một chút. Nếu bạn có nghĩa là tài nguyên máy chủ, tôi khuyên bạn nên xác định chính xác điều gì gây ra tải tăng (tức là một số loại kết nối nhất định) và hoạt động ngược từ đó.
Nó phụ thuộc vào giao thức và trường hợp sử dụng để cân bằng. Đối với bất cứ điều gì mà số lượng kết nối tương quan với tải / sử dụng, tốt hơn là sử dụng leastconn. Do cách thức hoạt động của các mạng và ứng dụng, nó luôn luôn đúng và bạn nên sử dụng leastconntheo mặc định.
Ví dụ, một công ty có một nhóm máy tính để bàn từ xa mà nhân viên kết nối. Bạn muốn nhân viên được phân phối phần nào trên các máy tính để bàn.
Số lượng kết nối hoạt động trong trường hợp sử dụng đó là khoảng "có bao nhiêu nhân viên đang sử dụng máy tính để bàn đó ngay bây giờ". Máy chủ có ít kết nối nhất có ít nhân viên sử dụng và có lẽ nó được tải ít nhất. Sử dụng "lessconn" trong những trường hợp này, nó trải đều tải với lượng người dùng.
Một bộ cân bằng tải lý tưởng nên nhận thức được tải máy tính để bàn từ xa. Có bao nhiêu người dùng? Có bao nhiêu ứng dụng? Bao nhiêu bộ nhớ và CPU tiêu thụ? Có những giải pháp thương mại dành riêng cho máy tính để bàn từ xa (Microsoft / Citrix / etc ...), họ thường đo lường các số liệu này để sử dụng rất tốt. HAProxy là một bộ cân bằng tải mạng đơn giản và nó không thể làm tốt hơn việc đếm các kết nối với leastconn.
Với HTTP, kết nối hoạt động có nghĩa là máy chủ đang bận xử lý yêu cầu. Các kết nối tỷ lệ thuận với tải. Bạn muốn chọn máy chủ có số lượng kết nối hoạt động ít nhất (yêu cầu đang diễn ra). Sử dụng leastconncho lưu lượng HTTP (S).
Hãy tưởng tượng một kịch bản có hai máy chủ HTTP, trong đó một máy chủ xử lý các yêu cầu chậm hơn (có thể nó bị quá tải, có thể nó có phần cứng cũ hơn).
roundrobinsẽ phân phối một nửa yêu cầu giữa hai máy chủ. Nó rất không hiệu quả, máy chủ nhanh hơn sẽ mất nhiều hơn. Tệ hơn nữa, máy chủ chậm hơn có thể bị quá tải, nó sẽ còn chậm hơn khi có nhiều yêu cầu đến và có thể bắt đầu bỏ yêu cầu bất cứ lúc nào. Bạn không muốn điều đó.
leastconnsẽ phát hiện ra rằng các máy chủ không đồng đều. Máy chủ chậm giữ kết nối lâu hơn, nó có số lượng kết nối cao hơn. leastconntài khoản cho điều đó và thích các máy chủ khác.
Theo kinh nghiệm của tôi, bao gồm các vai trò mà tôi độc quyền thực hiện kiểm tra hiệu suất cho các trang web vừa và lớn. leastconncó thể hiệu quả 300% như roundrobinđối với HTTP (S). roundrobinkhông phân phối kết nối một cách công bằng và nó sẽ gây ra sự mất ổn định khi tải cao.
(Hãy bỏ qua rằng HAProxy không hỗ trợ UDP và UDP ít kết nối hơn).
Một ví dụ cuối cùng. DNS là một giao thức đơn giản. Các máy khách gửi một tin nhắn UDP duy nhất để yêu cầu một miền và máy chủ DNS trả lời trong một tin nhắn.
Trong trường hợp này, thực sự không có kết nối. Ngay cả nếu có, nó sẽ bị đóng ngay lập tức (về mặt lý thuyết).
Sẽ không có ý nghĩa khi đếm các kết nối trong những trường hợp này, nó không tối ưu cho leastconn. Một đơn giản roundrobincó thể phân phối tin nhắn.
Mọi người đôi khi tin rằng họ không nên sử dụng leastconncho các kết nối ngắn (tương tự như ví dụ cuối cùng). Ngay cả tài liệu HAProxy cũng gây hiểu nhầm về điều đó.
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
Trong thế giới thực, short connectionskhông phải là một điều.
Các ứng dụng được xây dựng dựa trên TCP. Tin nhắn được gửi và thường được xử lý theo thứ tự. Khi một máy chủ bị chậm hoặc quá tải, các kết nối "ngắn" sẽ dài hơn. Nếu có (nhiều) kết nối, có thể có một số (nhiều) công việc đang được thực hiện. Số lượng kết nối và thời lượng kết nối khác nhau và có ý nghĩa.
Hãy nghĩ về một máy chủ HTTP cơ bản. Một số tài sản mất vài mili giây, một số lệnh gọi API mất vài giây, một trang có thể mất bất kỳ thời gian nào để tải với bất kỳ số lượng yêu cầu nào trong đó, v.v. leastconnhiểu hoạt động đang diễn ra và điều chỉnh phân phối, đó chính xác là những gì bạn muốn từ một bộ cân bằng tải.