Ci sono suggerimenti su quando dovrei usare roundrobine quando dovrei usare leastconn?
roundrobinAttualmente sto usando e ho osservato che il caricamento dei miei server back-end non è distribuito uniformemente. Naturalmente potrebbero esserci altri problemi, ma vogliamo leastconnprovare, ma poiché si tratta di un server mission-critical, voglio consultare altre esperienze prima di apportare le modifiche.
Qualche idea da condividere?
Risposte:
Non ho ancora sperimentato con leastconn, ma la mia comprensione è che il tipico caso d'uso di leastconn è quando si esegue il bilanciamento del carico in qualcosa che può avere connessioni di lunga durata. La ragione di ciò è che il focus minimo si concentra sull'assicurare una concorrenza equilibrata laddove il robin della strada fornirà un tasso di arrivo più equilibrato . Se questa distinzione non è chiara, vedere la mia risposta sulla differenza .
Quando si dice che il carico non è distribuito uniformemente, potrebbe essere utile definire un po 'meglio "carico". Se intendi risorse del server, allora suggerisco di identificare cosa sta causando esattamente il carico aumentato (cioè alcuni tipi di connessioni) e di lavorare all'indietro da lì.
Dipende dal protocollo e dal caso d'uso da bilanciare. Per qualsiasi cosa in cui la quantità di connessioni è correlata al carico / utilizzo, è meglio usare leastconn. A causa del modo in cui funzionano le reti e le applicazioni, è praticamente sempre vero e stai meglio usando leastconndi default.
Ad esempio, un'azienda ha un pool di desktop remoti a cui i dipendenti si connettono. Vorresti che i dipendenti fossero distribuiti in qualche modo uniforme sui desktop.
Il numero di connessioni attive in quel caso d'uso è approssimativamente "quanti impiegati stanno usando quel desktop in questo momento". L'host con il minor numero di connessioni ha meno dipendenti che lo utilizzano ed è probabilmente il meno caricato. Usa "leastconn" in queste circostanze, distribuisce il carico in modo uniforme con la quantità di utenti.
Un bilanciamento del carico ideale dovrebbe essere consapevole del carico del desktop remoto. Quanti utenti? Quante applicazioni? Quanta memoria e CPU consumano? Esistono soluzioni commerciali dedicate ai desktop remoti (Microsoft / Citrix / ecc ...), in genere misurano queste metriche per diffondere molto bene l'utilizzo. HAProxy è un semplice bilanciamento del carico di rete e non può fare di meglio che contare le connessioni leastconn.
Con HTTP, una connessione attiva significa che il server è occupato nell'elaborazione di una richiesta. Le connessioni sono direttamente proporzionali al carico. Si desidera selezionare il server con il minor numero di connessioni attive (richieste in corso). Utilizzare leastconnper il traffico HTTP (S).
Immagina uno scenario con due server HTTP, in cui un server è più lento nell'elaborare le richieste (forse è sovraccarico, forse ha hardware meno recente).
roundrobindistribuirà la metà delle richieste tra i due server. È molto inefficiente, il server più veloce dovrebbe richiedere di più. Peggio ancora, il server più lento potrebbe essere sovraccarico, diventerà ancora più lento con l'arrivo di più richieste e potrebbe iniziare a far cadere le richieste in qualsiasi momento. Non lo vuoi.
leastconnrileverà che i server sono irregolari. Il server più lento mantiene le connessioni più a lungo, ha un conteggio delle connessioni più elevato. leastconntiene conto di ciò e preferisce l'altro server.
Nella mia esperienza, compresi i ruoli in cui stavo eseguendo esclusivamente test delle prestazioni per siti Web di dimensioni medio-grandi. leastconnpuò essere efficiente del 300% rispetto roundrobina HTTP (S). roundrobinnon distribuisce correttamente la connessione e causerà instabilità a carico elevato.
(Ignoriamo che HAProxy non supporta UDP e UDP è meno connessione).
Un ultimo esempio. DNS è un protocollo semplice. I client inviano un singolo messaggio UDP per richiedere un dominio e il server DNS risponde in un singolo messaggio.
In questo caso, non esiste davvero una connessione. Anche se ci fosse, sarebbe immediatamente chiuso (teoricamente).
Non avrebbe senso contare le connessioni in queste circostanze, non è ottimale per leastconn. Un semplice roundrobinpuò distribuire messaggi.
Le persone a volte credono che non dovrebbero usare leastconnper connessioni di breve durata (simile all'ultimo esempio). Anche la documentazione di HAProxy è fuorviante al riguardo.
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
Nel mondo reale, short connectionsnon è una cosa.
Le applicazioni sono basate su TCP. I messaggi vengono recapitati e spesso elaborati in ordine. Quando un server è lento o sovraccarico, le connessioni "brevi" diventano più lunghe. Se ci sono (più) connessioni, probabilmente c'è qualche (più) lavoro in corso. Il conteggio e la durata della connessione variano e hanno significato.
Pensa a un server HTTP di base. Alcune risorse richiedono alcuni millisecondi, alcune chiamate API impiegano alcuni secondi, il caricamento di una pagina potrebbe richiedere del tempo con qualsiasi quantità di richieste al suo interno, ecc. Le richieste non hanno vita breve, la loro durata segue ciò che viene elaborato su quale server. leastconncomprende l'attività in corso e regola la distribuzione, che è esattamente ciò che si desidera da un bilanciamento del carico.