Cân bằng tải dựa trên cookie cho WebSockets?

Question

Tình huống của tôi là chúng tôi hiện đang viết một ứng dụng trực tuyến sử dụng Node.js ở phía máy chủ với trình nghe WebSocket. Chúng tôi có hai phần khác nhau: một trang phục vụ các trang và sử dụng node.js và express + ejs, một ứng dụng khác hoàn toàn khác chỉ bao gồm thư viện socket.io cho websockets. Vì vậy, ở đây chúng tôi đi đến vấn đề này của khả năng mở rộng của một phần websockets.

Một giải pháp mà chúng tôi tìm thấy là sử dụng redis và chia sẻ thông tin ổ cắm giữa các máy chủ, nhưng do kiến ​​trúc, nó sẽ yêu cầu chia sẻ nhiều thông tin khác.

Sau phần giới thiệu này, câu hỏi của tôi là - liệu có thể sử dụng cân bằng tải dựa trên cookie cho websockets không? Vì vậy, cho phép nói rằng mọi kết nối từ người dùng với máy chủ cookie = server1 sẽ luôn được chuyển tiếp đến máy chủ1 và mọi kết nối với máy chủ cookie = server2 sẽ được gửi đến máy chủ2 và kết nối không có cookie đó sẽ được chuyển sang máy chủ bận rộn nhất.

CẬP NHẬT: Là một 'câu trả lời' cho biết - có, tôi biết điều này tồn tại. Chỉ cần không nhớ rằng tên là phiên dính. Nhưng câu hỏi là - điều đó có hiệu quả với websockets không? Có bất kỳ biến chứng nào có thể xảy ra không?

Answer 1

Chúng tôi gặp sự cố tương tự hiển thị trong ngăn xếp sản xuất Node.js của chúng tôi. Chúng tôi có hai máy chủ sử dụng WebSockets hoạt động cho các trường hợp sử dụng bình thường, nhưng đôi khi trình cân bằng tải sẽ trả lại kết nối này giữa hai máy chủ sẽ gây ra sự cố. (Chúng tôi có mã phiên tại chỗ trên chương trình phụ trợ nên đã sửa nó, nhưng không xử lý đúng cách.)

Chúng tôi đã thử bật Phiên làm việc trên bộ cân bằng tải Barracuda ở phía trước các máy chủ này nhưng thấy rằng nó sẽ chặn WebSocket lưu lượng truy cập do hoạt động của nó. Tôi đã không nghiên cứu chính xác tại sao, vì ít thông tin có sẵn trực tuyến, nhưng có vẻ như điều này là do cách trình cân bằng tách khỏi tiêu đề cho yêu cầu HTTP, lấy cookie và chuyển tiếp yêu cầu đến máy chủ phụ trợ chính xác. Kể từ khi WebSockets bắt đầu như HTTP nhưng sau đó nâng cấp, cân bằng tải đã không nhận thấy sự khác biệt trong kết nối và sẽ cố gắng để làm cùng một xử lý HTTP. Điều này sẽ khiến kết nối WebSocket thất bại, ngắt kết nối người dùng.

Sau đây là những gì chúng tôi hiện có tại chỗ đang hoạt động rất tốt. Chúng tôi vẫn sử dụng cân bằng tải Barracuda ở phía trước máy chủ phụ trợ của chúng tôi, nhưng chúng tôi không có Phiên cố định được bật trên bộ cân bằng tải. Trên các máy chủ phụ trợ của chúng tôi, ở phía trước máy chủ ứng dụng của chúng tôi là HAProxy có hỗ trợ WebSockets đúng cách và có thể cung cấp Phiên cố định theo cách 'bùng binh'.

---

Danh sách yêu cầu luồng

1. yêu cầu khách hàng Incoming lượt truy cập chính Barracuda cân bằng tải
2. cân bằng tải chuyển tiếp cho một trong các máy chủ backend hoạt động
3. HAProxy nhận được yêu cầu và kiểm tra cho mới 'sticky cookie'
4. Dựa trên cookie, HAProxy chuyển tiếp đến máy chủ ứng dụng phụ trợ chính xác

---

Yêu cầu luồng Diagram

WebSocket Request /--> Barracuda 1 -->\ /--> Host 1 -->\ /--> App 1 
------------------->      -->    --> 
        \--> Barracuda 2 -->/ \--> Host 2 -->/ \--> App 1 

Khi các mũi tên quay trở lại một yêu cầu, có nghĩa là yêu cầu có thể chảy vào một trong hai điểm trong dòng chảy.

---

HAProxy Cấu hình chi tiết

backend app_1 
    cookie ha_app_1 insert 
    server host1 10.0.0.101:80011 weight 1 maxconn 1024 cookie host_1 check 
    server host2 10.0.0.102:80011 weight 1 maxconn 1024 cookie host_2 check 

Trong cấu hình trên:

• cookie ha_app_1 insert là tên cookie thực tế sử dụng
• cookie host_1 check hay cookie host_2 check đặt giá trị cookie