Chia tỷ lệ HAProxy cho hơn 64k websockets

8

Chúng tôi đang cố gắng thiết kế một kiến trúc có thể xử lý hơn 64k websockets.

Lần đầu tiên chúng tôi đã thử với Amazon ELB, nhưng thiết kế của nó không cho phép lưu lượng truy cập tăng đột biến cũng như websocket. (Chế độ TCP hết thời gian chờ websockets)

Với HAProxy, những giới hạn đó không được áp dụng, nhưng chúng tôi sẽ giới hạn ở ~ 64k websockets được duy trì giữa HA và các máy chủ phụ trợ.

Nhiều giải pháp xuất hiện trong tâm trí:

Nhiều phiên bản HAProxy, cân bằng tải với DNS (Route53 có tùy chọn có trọng số)
Hai trường hợp HAProxy với Keepaliving, nhiều địa chỉ IP nội bộ (không chắc là có thể thực hiện được không)

Có cách nào tốt hơn để làm điều này ?

— Bastien974
nguồn

1

Tại sao giới hạn 64k? Nó có phải là một cổng nguồn? Nếu đó là trường hợp bạn chỉ có thể thêm nhiều 'máy chủ' vào phần phụ trợ bị ràng buộc với các cổng khác nhau ...

— Kyle Brandt

@ Bastien974, cách dễ nhất, là sử dụng ip nguồn khác nhau cho các phụ trợ, để mở rộng tới 130K kết nối, tôi đã sử dụng hai tùy chọn sysctl ips và tw numuse

— c4f4t0r

7

Nếu giới hạn 64k của bạn là do các cổng nguồn, bạn có thể thực hiện một số thao tác như sau (một chút hack, nhưng hiện tại chúng tôi đã làm tại SE cho websockets (chúng tôi có khoảng 0,5 triệu đồng thời với HAProxy):

server ny-web01-1 10.0.0.1:8081 check
server ny-web01-2 10.0.0.1:8082 check
server ny-web01-3 10.0.0.1:8083 check

Ngoài ra nhiều trường hợp có thể thực hiện được với keepaliving. Chỉ cần làm một cái gì đó như vòng tròn DNS qua nhiều IP. Chỉ cần đảm bảo rằng các IP luôn được chọn bởi các bộ cân bằng tải hoạt động vì chính DNS sẽ không cung cấp cho bạn sự cân bằng tải (cũng có nhiều tùy chọn hơn ở đây, điều này chỉ đơn giản).

— Kyle Brandt
nguồn

1

Nếu tôi hiểu chính xác, vì kết nối TCP được xác định bởi srcIP: srcPORT / DestIP: DestPORT, nếu tôi có thể nghe trong các máy chủ back-end trên nhiều cổng, điều đó có nghĩa là giữa HAProxy và máy chủ back-end để có nhiều kết nối từ cùng 127.0.0.1:12345 -> 10.0.0.1:8081, 127.0.0.1:12345 -> 10.0.0.1:8082, v.v? Điều này thực sự hoạt động?

— Bastien974

@ Bastien974: Bạn hiểu chính xác - nó hoạt động.

— Kyle Brandt

@ Bastien974: Bạn có thể sử dụng source 0.0.0.0 usesrc clienttrong cấu hình phụ trợ của haproxy để minh bạch nguồn tproxy. Theo cách này srcIP: srcPORT sẽ là IP / cổng máy khách thực tế (không phải IP bên trong của máy haproxy) - gọn gàng để đăng nhập.

— wqw

0

Bạn có thể thiết lập nhiều hệ thống HAproxy chia sẻ cùng một IP bằng Anycast và BGP hoặc một số giao thức định tuyến biên khác. Bằng cách này, tất cả các hệ thống HAproxy đang hoạt động; nếu bất kỳ lỗi nào xảy ra, bạn dừng quảng cáo tuyến đường BGP trên hệ thống đó và nó sẽ dừng trong ~ 30 giây khi dừng lưu lượng; sẽ được phân phối lại cho các hệ thống có sẵn khác quảng cáo cùng phạm vi.

Chẳng hạn, hãy kiểm tra url này về cách thiết lập bố cục như vậy

— Hrvoje Špoljar
nguồn

Tôi không chắc chắn điều này sẽ hoạt động trong cơ sở hạ tầng AWS VPC vì tôi cần sử dụng IP đàn hồi liên quan đến từng trường hợp. Giải pháp của bạn sẽ rất gần với DNS, vì Amazon Route53 cung cấp tùy chọn để thêm kiểm tra sức khỏe. Mối quan tâm của tôi là ngay cả với chỉ số TTL thấp, chúng tôi không thể chờ đợi việc truyền bá sang các quốc gia khác (chúng tôi có khách hàng trên toàn thế giới) để ngừng gửi lưu lượng truy cập đến một trường hợp HA "chết".

— Bastien974