Khi sử dụng cân bằng tải TCP với HAProxy, tất cả lưu lượng truy cập đi qua LB?


19

Tôi đang thiết lập một ứng dụng được lưu trữ bằng VM (có thể là amazon, nhưng không được cài đặt sẵn) sẽ yêu cầu cả cân bằng tải HTTP và cân bằng tải một số lượng lớn (50k hoặc hơn nếu có thể) các kết nối TCP liên tục. Lượng dữ liệu không quá cao, nhưng cập nhật thường xuyên.

Ngay bây giờ tôi đang đánh giá các bộ cân bằng tải và hơi bối rối về kiến ​​trúc của HAProxy. Nếu tôi sử dụng HAProxy để cân bằng các kết nối TCP, liệu tất cả lưu lượng truy cập kết quả có phải chảy qua bộ cân bằng tải không? Nếu vậy, liệu một giải pháp khác (như LVS hoặc thậm chí nginx_tcp_proxy_module) sẽ phù hợp hơn?

Câu trả lời:


33

HAProxy (giống như nhiều bộ cân bằng tải) thường duy trì hai cuộc hội thoại. Proxy có phiên (tcp trong trường hợp này) với máy khách và phiên khác với máy chủ. Do đó, với proxy bạn sẽ thấy gấp đôi kết nối trên bộ cân bằng tải. Do đó tất cả lưu lượng truy cập thông qua cân bằng tải.

Khi nói đến việc nhân rộng trên nhiều bộ cân bằng tải, tôi không nghĩ bạn cần phải làm vậy. Nhưng một cách thực tế và khá dễ dàng để làm điều này là sử dụng một cái gì đó như được giữ lại với hai IP nổi và DNS tròn giữa hai IP đó. Với chế độ giữ nguyên, nếu một trong các bộ cân bằng tải đi xuống thì cái kia sẽ giữ cả hai IP, do đó bạn có tính sẵn sàng cao theo cách này. Điều đó đang được nói, tôi nghĩ rằng bạn sẽ ổn với một ví dụ haproxy hoạt động với tải của bạn.

HAProxy cân rất tốt. Một ví dụ, mạng Stack Exchange sử dụng các ổ cắm web duy trì các kết nối TCP mở. Trong khi tôi đăng bài này, chúng tôi có 143.000 socket TCP được thiết lập trên máy ảo VMware mà không gặp vấn đề gì. Việc sử dụng CPU trên VM là khoảng 7%.

Với kiểu thiết lập này với HAProxy, đảm bảo bạn đặt maxconnđủ cao. Dưới đây là một số ví dụ cấu hình HAProxy để giúp bạn bắt đầu:

frontend fe_websockets
        bind 123.123.123.123:80
        mode tcp
        log global
        option tcplog
        timeout client 3600s
        backlog 4096
        maxconn 50000
        default_backend be_nywebsockets

backend be_nywebsockets
        mode  tcp
        option log-health-checks
        option redispatch
        option tcplog
        balance roundrobin
        server web1 10.0.0.1:1234
        server web2 10.0.0.2:1234
        timeout connect 1s
        timeout queue 5s
        timeout server 3600s

143.000 - vẫn còn nói về các ổ cắm web? hoặc đó là những thứ khác quá?
Marc Gravell

@MarcGravell: Hầu như tất cả các socket web. Hãy nhớ rằng đây là gấp đôi mặc dù như tôi đã nói trong phần giới thiệu của mình, vì vậy các máy chủ của web socket sẽ thấy tổng cộng ~ 70k
Kyle Brandt

@Kyle - Bất kỳ lý do tại sao bạn cần ổ cắm web và kết nối TCP liên tục? Trang web này dường như không có bất kỳ tính năng thời gian thực nào sẽ yêu cầu điều đó.
Tiếp tục

@ Nội dung: Có rất nhiều tính năng thời gian thực bao gồm thông báo Hộp thư đến, phiếu bầu, chỉnh sửa, nhận xét / câu trả lời / câu hỏi mới. Không chắc chắn nếu chúng chỉ được bật cho người dùng có giới hạn đại diện nhất định, nếu bạn không thấy họ, bạn có thể hỏi về meta.stackoverflow.com
Kyle Brandt

1
@KyleBrandt cũng hoạt động ở chế độ TCP phải không?
elslooo

2

Có, tất cả lưu lượng thường phải đi qua bộ cân bằng tải. Các yêu cầu được nhận bởi bộ cân bằng tải và các phản hồi được gửi lại cho bộ cân bằng tải sẽ gửi lại cho khách hàng.

Để chọn đúng công cụ, tôi không có nhiều kinh nghiệm về các tùy chọn khác. Tôi đang sử dụng haproxy và nó thực sự tốt và ổn định và có thể xử lý một lượng lớn lưu lượng. Ngoài ra, khả năng ACL của nó là rất tốt.


2

Có khả năng sử dụng và định cấu hình DSR (Direct Server Return) nhưng điều này không liên quan gì đến Loadbalancer nhưng được cấu hình trong tcp-stack (bảng định tuyến). Chúng tôi đã sử dụng điều này cho một cổng thông tin hợp lý video lớn. Mặc dù nó hoạt động nhưng nó sẽ khiến bạn đau đầu đáng kể về sự phức tạp của việc định tuyến cần thiết.

Vì vậy, tôi không khuyên bạn nên sử dụng kỹ thuật này mà không xem xét sử dụng và nhược điểm rất kỹ lưỡng.

Có thể có một số gợi ý để bắt đầu ở đó:

Chúc vui vẻ!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.