OK, questo è stato chiesto un po 'di tempo fa e sono in ritardo alla festa. Tuttavia, c'è qualcosa da aggiungere qui.
Jackie, l'hai praticamente inchiodato. La tua illustrazione mostra come viene gestito il bilanciamento del carico sulla maggior parte delle installazioni di piccole e medie dimensioni.
Dovresti leggere l' introduzione di bilanciamento del carico di Willy Tarreau a cui Nakedible era collegato. È ancora valido ed è una buona introduzione.
Devi considerare come si adattano alle tue esigenze:
- Bilanciatori di carico a livello TCP / IP (Linux Virtual Server et al). Il sovraccarico per connessione più basso, la velocità massima, non possono "vedere" HTTP.
- Bilanciatori di carico a livello HTTP (HAProxy, nginx, Apache 2.2, Pound, Microsoft ARR e altro). Un overhead più elevato, può vedere HTTP, può gzip HTTP, può fare SSL, può fare il bilanciamento del carico di sessione appiccicoso.
- Proxy inversi HTTP (Apache Traffic Server, Varnish, Squid). Può memorizzare oggetti in grado di memorizzare nella cache (alcune pagine Web, CSS, JS, immagini) nella RAM e inoltrarli ai client successivi senza coinvolgere il server Web back-end. Spesso può fare alcune delle stesse cose che fanno i bilanciatori di carico HTTP L7.
c'è un secondo bilanciatore poiché sono sicuro che ad un certo punto anche il bilanciatore avrebbe bisogno di aiuto.
Beh, certo. Ma il bilanciamento del carico è semplice e spesso un singolo bilanciamento del carico può andare veloce . Collego a questo articolo, che ha colpito un nervo nel web, come solo un esempio di quale performance ballpark può fornire un singolo server moderno . Non utilizzare più LB prima che sia necessario. Quando è necessario un approccio comune è il bilanciamento del carico a livello IP nella parte anteriore (o DNS Round Robin), passare ai bilanciatori del carico a livello HTTP, andare ai proxy e ai server webapp.
aiuto su come dovrebbero essere i "bilanciatori / i" e le migliori pratiche su come configurarli.
Il punto problematico è la gestione dello stato della sessione e, in una certa misura, il comportamento dello stato di errore. L'impostazione degli stessi bilanciatori di carico è relativamente semplice.
Se stai usando solo 2-4 server webapp back-end, l'hash statico basato sull'indirizzo IP di origine può essere praticabile. Questo evita la necessità di uno stato di sessione condiviso tra i server webapp. Ogni nodo di webapp vede 1 / N del traffico complessivo e il mapping da cliente a server è statico durante il normale funzionamento. Tuttavia, non è adatto per installazioni più grandi.
I due migliori algoritmi di bilanciamento del carico, nel senso che hanno un comportamento benigno sotto carico elevato e persino distribuzione del carico, sono round robin e vero bilanciamento del carico casuale. Entrambi richiedono che lo stato della sessione globale sia disponibile sui nodi di webapp. Come ciò dipende dallo stack tecnologico di webapp; ma ci sono generalmente soluzioni standard disponibili per questo.
Se né l'hash statico, né lo stato della sessione condivisa sono adatti per te, la scelta è generalmente il bilanciamento del carico ' sessione appiccicosa ' e lo stato della sessione per server. Nella maggior parte dei casi funziona bene ed è una scelta pienamente praticabile.
il / i bilanciatore / i vedrebbe quante connessioni ci sono su ciascuna istanza di apache (tramite un elenco di configurazione di IP interni o IP eterni) e distribuisce le connessioni equamente
Sì, alcuni siti lo usano. Esistono molti nomi per i diversi algoritmi di bilanciamento del carico esistenti. Se puoi scegliere round robin o random (o round robin ponderato, ponderato random), ti consiglio di farlo, per i motivi sopra indicati.
Ultima cosa: non dimenticare che molti fornitori (F5, Cisco e altri su tecnologie di fascia alta, fx Coyote Point e Kemp a prezzi più ragionevoli) offrono apparecchi di bilanciamento del carico maturi .
