Tôi có thể có phiên cố định với HAProxy và socket.io có xác thực không?

Question

Tôi có một số trường hợp socket.io với xác thực đang chạy dưới HAProxy và tôi cần phải buộc rằng yêu cầu xác thực và kết nối ổ cắm đi đến cùng một cá thể. Tôi đã thiết lập HAProxy dựa trên this answer to a SO question với một số sửa đổi như vậy:

global 
    maxconn  4096 # Total Max Connections. This is dependent on ulimit 
    nbproc  2 

defaults 
    mode  http 

frontend all 0.0.0.0:80 
    timeout client 86400000 
    default_backend www_backend 
    acl is_websocket hdr(Upgrade) -i WebSocket 
    acl is_websocket hdr_beg(Host) -i ws 

    use_backend socket_backend if is_websocket 

backend www_backend 
    balance url_param sessionId 
    option forwardfor # This sets X-Forwarded-For 
    timeout server 30000 
    timeout connect 4000 
    server server1 localhost:8081 weight 1 maxconn 1024 check 
    server server2 localhost:8082 weight 1 maxconn 1024 check 
    server server3 localhost:8083 weight 1 maxconn 1024 check 

backend socket_backend 
    balance url_param sessionId 
    option forwardfor # This sets X-Forwarded-For 
    timeout queue 5000 
    timeout server 86400000 
    timeout connect 86400000 
    server server1 localhost:8081 weight 1 maxconn 1024 check 
    server server2 localhost:8082 weight 1 maxconn 1024 check 
    server server3 localhost:8083 weight 1 maxconn 1024 check 

Tôi đã thử url_param (nơi sessionId là một tham số chuỗi truy vấn thông qua trong cả hai cuộc gọi xác thực và kết nối WebSocket) và nguồn như sự cân bằng tùy chọn nhưng có vẻ như HAProxy chỉ cho phép các tùy chọn này cho các kết nối HTTP và do đó bỏ qua chúng cho kết nối websocket thực tế. Kết quả là đôi khi yêu cầu xác thực và kết nối socket kết thúc trong các máy chủ khác nhau, điều này không thể chấp nhận được đối với ứng dụng của chúng tôi.

Có cách nào để có hành vi mong muốn này không?

Answer 1

Đối với số dư kết nối websocket sử dụng roundrobin. Kể từ khi một ổ cắm hai chiều (trên TCP) dính được duy trì theo mặc định. Đối với các phương tiện vận chuyển khác sử dụng thuật toán cân bằng source là đặt cược tốt nhất. (Bạn có thể sử dụng cookie dựa bền bỉ nhưng socket.io không gửi một JSESSIONID hoặc tương tự lại đến máy chủ proxy Bạn có thể thử sockjs nếu bạn muốn Cookie dựa bền bỉ..)

Ví dụ:

#do the same for other transports. [Note in 0.6.x resource was mounted at path: /socket.io/[transport] 
acl is_JSONPolling path_beg /socket.io/1/jsonp-polling 
use_backend non_websocket if is_JSONPolling 


backend non_websocket 
    balance source 
    #rest same as the one for websocket backend 

Answer 2

Để cân bằng kết nối TCP, bạn có thể có một số thành công với bảng dính bằng cách sử dụng các lệnh stick_match hoặc stick on và đặt rõ ràng chế độ tcp.

Dưới đây là một ví dụ:

# forward SMTP users to the same server they just used for POP in the 
# last 30 minutes 
backend pop 
    mode tcp 
    balance roundrobin 
    stick store-request src 
    stick-table type ip size 200k expire 30m 
    server s1 192.168.1.1:110 
    server s2 192.168.1.1:110 

backend smtp 
    mode tcp 
    balance roundrobin 
    stick match src table pop 
    server s1 192.168.1.1:25 
    server s2 192.168.1.1:25 

Full tài liệu có sẵn here.

Answer 3

tôi sử dụng cookie sẽ cân bằng dựa theo cách này:

backend socketio 
    mode http 
    cookie SIO insert 
    server sock1 127.0.0.1:8001 cookie 001 
    server sock2 127.0.0.1:8002 cookie 002 

Answer 4

Bạn đang sử dụng HTTP để chèn một cookie cho persistence - đó là chắc chắn con đường tốt nhất. Điều đó sẽ dính nó vào máy chủ đầu tiên họ đã đi đến trừ khi nó xuống.

Bạn cũng có thể định cấu hình xem có nên định lại lại nó nếu nó không hoạt động, vv ..