Ridimensiona HAProxy per più di 64k websocket

8

Stiamo cercando di progettare un'architettura che sarà in grado di gestire più di 64k websocket.

Abbiamo provato per la prima volta con Amazon ELB, ma il suo design non consente picchi imprevisti di traffico né di websocket. (Timeout della modalità TCP inaspettatamente i websocket)

Con HAProxy, questi limiti non si applicano, ma saremo limitati a ~ 64k websocket gestiti tra HA e i server back-end.

Molteplici soluzioni che mi sono venute in mente:

Istanze multiple HAProxy, bilanciamento del carico con DNS (Route53 ha un'opzione ponderata)
Due istanze HAProxy con Keepalived, più indirizzi IP interni (non sono sicuro che sia fattibile)

C'è un modo migliore per farlo?

— Bastien974
fonte

1

Perché limite 64k? È una cosa porta sorgente? In tal caso, puoi semplicemente aggiungere più "server" al back-end associati a porte diverse ...

— Kyle Brandt,

@ Bastien974, il modo più semplice, è usare diversi sorgenti IP per back-end, per ridimensionare a 130K connessioni, ho usato due ips e tw_reuse sysctl opzione

— c4f4t0r

7

Se il tuo limite di 64k è dovuto alle porte di origine, puoi fare qualcosa di simile al seguente (un po 'confuso, ma al momento lo stiamo facendo a SE per i websocket (abbiamo qualcosa come 0,5 milioni in concomitanza con 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

Inoltre è possibile eseguire più istanze con keepalived. Fai semplicemente qualcosa come il round robin DNS su più IP. Assicurati solo che gli IP vengano sempre rilevati dai bilanciatori di carico attivi poiché il DNS stesso non ti darà il bilanciamento del carico (ci sono anche più opzioni qui, questa è solo semplice).

— Kyle Brandt
fonte

1

Se ho capito bene, poiché una connessione TCP è definita da srcIP: srcPORT / destIP: destPORT, se sono in grado di ascoltare i server back-end su più porte, ciò significherebbe tra HAProxy e server back-end sarei in grado avere più connessioni dalla stessa 127.0.0.1:12345 -> 10.0.0.1:8081, 127.0.0.1:12345 -> 10.0.0.1:8082, ecc? Funziona davvero?

— Bastien974,

@ Bastien974: hai capito bene - funziona.

— Kyle Brandt,

@ Bastien974: è possibile utilizzare source 0.0.0.0 usesrc clientnella configurazione backend di haproxy per la trasparenza dell'origine tproxy. In questo modo srcIP: srcPORT sarà l'IP / le porte client effettive (non gli IP interni della macchina del proxy) - anche per la registrazione.

— wqw,

0

È possibile configurare più sistemi HAproxy che condividono gli stessi IP utilizzando Anycast e BGP o altri protocolli di routing dei confini. In questo modo tutti i sistemi HAproxy sono attivi; se uno di questi si interrompe, interrompi la pubblicità del percorso BGP su quel sistema e in circa 30 secondi smetterà di ricevere traffico; che sarà ridistribuito ad altri sistemi disponibili che pubblicizzano lo stesso intervallo.

Ad esempio, controlla questo URL su come impostare tale layout

— Hrvoje Špoljar
fonte

Non sono del tutto sicuro che funzionerebbe all'interno di un'infrastruttura VPC AWS in quanto ho bisogno di utilizzare Elastic IP associato a ciascuna istanza. La tua soluzione sarebbe molto simile a quella DNS, poiché Amazon Route53 offre la possibilità di aggiungere un controllo dello stato. La mia preoccupazione è che anche con un TTL basso, non possiamo permetterci di aspettare la propagazione in altri paesi (abbiamo clienti in tutto il mondo) per interrompere l'invio di traffico a un'istanza HA "morta".

— Bastien974,