Livello 4 vs Livello 7 Bilanciamento del carico

Sto cercando di decidere se utilizzare una soluzione di bilanciamento del carico di livello 4 per il mio datacenter o una soluzione di livello 7. Sfortunatamente (per la mia sanità mentale, cioè), il mio caso d'uso è abbastanza semplice che entrambe le soluzioni funzionerebbero bene, evitando la maggior parte dei punti deboli e non sfruttando realmente i punti di forza dell'altro. Qualunque sia la soluzione che usiamo, deve avere un'alta disponibilità e un alto rendimento. Ma stiamo pianificando di usarlo solo per caricare il bilanciamento su un cluster di server Web, nessuno dei quali ha requisiti per la gestione "appiccicosa" della sessione (cookie o IP), regole di riscrittura complesse o, in ogni caso, qualsiasi regola di riscrittura su tutti.

I bilanciatori del carico saranno collegati a due switch, entrambi con una connessione indipendente fino al livello di aggregazione del datacenter e uniti insieme tramite Rapid Spanning Tree e qualsiasi protocollo proprietario che gli switch utilizzano per la virtualizzazione. I bilanciatori del carico saranno inoltre collegati tra loro tramite un cavo incrociato. Tutti i server nel cluster sono collegati ad entrambi gli switch. Tutto quello che i bilanciatori di carico devono fare è puntare il traffico su di essi.

Dato che è solo HTTP, posso usare una soluzione di bilanciamento del carico di livello 7 come HAProxy o nginx. Ma potrei anche usare il progetto LVS con ldirectord o keepalived o altro.

Ho provato a scomporre i pro e i contro come li vedo, ma finisce in un attimo. Cosa consiglieresti e perché? Mi sto perdendo qualcosa?

Un utile vantaggio di "L7" come haproxy è la possibilità di utilizzare i cookie per mantenere lo stesso browser colpendo lo stesso server back-end. Questo rende molto più facile il hit dei client di debug.

Il bilanciamento L4 può far rimbalzare un singolo utente su più server back-end. (che in alcuni casi può essere vantaggioso, ma in un senso di debug / profiling, l'uso di "L7" è molto più prezioso.)

EDIT: c'è anche un potenziale vantaggio di velocità nell'utilizzo del bilanciamento HTTP. Con keep-alives i client possono stabilire una singola sessione TCP al proprio bilanciamento e quindi inviare molti HIT senza dover ristabilire nuove sessioni TCP (handshake a 3 vie). Allo stesso modo molti LB mantengono sessioni keep-alive ai sistemi di back-end eliminando la necessità di fare la stessa stretta di mano sul back-end.

Il rigoroso bilanciamento del carico TCP potrebbe non riuscire a raggiungere entrambi facilmente.

/ * FWIW: Non direi "L7" o "L4", direi HTTP o TCP. Ma sono un pignolo per evitare di usare l'OSI per descrivere cose che non corrispondono bene. * /

Penso fondamentalmente se non sei sicuro di cosa distribuire, vai con ciò che ti sembra semplice e naturale. Provalo (usa la panca apache?) E assicurati che funzioni per le tue esigenze. Per me HTTP LB è più naturale.

Data la mancanza di vantaggi per te dal fare il bilanciamento L7, mi accontenterei invece del bilanciamento L4. Sono un grande fan di mantenerlo il più semplice possibile, senza sacrificare troppo.

L7 richiede ai bilanciatori di ispezionare le intestazioni http nei pacchetti che le stanno attraversando per il routing appropriato, aggiungendo un sovraccarico aggiuntivo e un aumento marginale della latenza per l'utente finale. Mi sembra inutile se non ne guadagni nulla.

Alcuni provider DNS dispongono di semplici funzionalità di failover. Hai menzionato quali sono i tuoi requisiti e non quelli che sono, ma se tutto ciò di cui hai bisogno è il round robin con failover se qualcosa non funziona, allora puoi usare ad esempio Failover di zoneedit.com . A seconda delle esigenze di HA che possono essere abbastanza buone e puoi saltare un intero livello nella tua architettura.