Come si adattano i sistemi di bilanciamento del carico a un data center con un throughput molto più elevato di quello che possono gestire?

10

Hai un data center standardizzato su connessioni 10GE. Con, diciamo, Nexus 7000s nel core, Nexus 5000s nell'aggregazione e alcuni estensori di fabric per il limite ai server (uso Cisco gear come esempi perché questo è ciò che è nel mio laboratorio specifico). Esistono alcuni bilanciatori di carico ACE 4710 sospesi sul Nexus 5000s, ma questi hanno solo interfacce 1GE. Tutte le connessioni degli switch sono 10GE, necessarie per il massiccio traffico da est a ovest (da VM a VM) nei moderni data center virtualizzati.

I bilanciatori del carico non diventano un collo di bottiglia in determinate condizioni di traffico? Posso vedere come un po 'di traffico est-ovest locale non abbia nemmeno bisogno di raggiungere il bilanciamento del carico, ma ci sono altre situazioni in cui è necessario attraversare il core, e forse anche un'interconnessione del data center.

Fondamentalmente, so che i sistemi di bilanciamento del carico sono utilizzati nel traffico client-server (nord-sud) e cose come HTTP GET non hanno bisogno di 10GE, ma ci sono situazioni in cui il tuo bilanciamento del carico 1GE può intralciare un altrimenti tutto- Percorso del traffico 10GE e causare problemi per cose come vMotion (ad esempio)?

load-balancer

— sentinella
fonte

1

ACE 4710 è EOL / EOS dal 2010. Sei legato a questo bilanciamento del carico o sei aperto all'utilizzo di un moderno bilanciamento del carico in grado di scalare molto più in alto? (Molti produttori li realizzano.) Non vi è alcun motivo di porre artificialmente limiti al rendimento nel modo descritto. Bene, nessun motivo al di fuori dei costi, ma in realtà se hai acquistato l'infrastruttura che descrivi, probabilmente avresti denaro in contanti per una configurazione del bilanciamento del carico reale.

— Brett Lykins,

Questo non è in realtà un ambiente di produzione, ma un vero scenario "lab" che contiene questi particolari dispositivi. In senso più generale, la mia domanda è, dato il carico di traffico di un tipico data center, come si fa a garantire che il bilanciamento del carico non diventi un collo di bottiglia nella progettazione? Questo si adatta al tuo progetto, come ad esempio se il tuo data center è a più livelli, a quale livello fai il bilanciamento del carico, ecc. Nel mio esempio particolare, che non posso cambiare dal momento che non è il mio design, ha senso avere questi Dispositivi ACE con un solo braccio dei Nexus 5000 che sono molto più potenti.

— sentinella il

6

I bilanciatori del carico non diventano un collo di bottiglia in determinate condizioni di traffico?

Certamente, ma questo non è generalmente il caso di una rete ben progettata.

Dovresti essere in grado di progettare la tua rete in modo tale da consentire la maggior parte del traffico interno da server a server ("est-ovest", come dici), anche se deve attraversare il tuo core o tra i data center.

Mentre spesso il bilanciamento del carico è il gateway predefinito per i server dietro di esso, ho visto configurazioni in cui viene eseguito un protocollo di routing (ovvero OSPF o RIP) per consentire al traffico "est-ovest" di aggirare il bilanciamento del carico o in distribuzioni più piccole dove sono stati utilizzati percorsi statici.

Se i sistemi di bilanciamento del carico saranno un collo di bottiglia anche con un buon design (ovvero il volume del traffico è così alto), allora ci sono modi di bilanciamento del carico anche su più sistemi di bilanciamento del carico.

— YImparare
fonte

4

Infatti. Se c'è un LB nel tuo percorso vMotion, hai fallito come ingegnere.

— Ricky Beam,

"... ci sono modi per bilanciare il carico anche su più bilanciatori di carico" - come selezionare il bilanciamento del carico di rete dal DNS?

— Andrei Rînea,

2

Questo è davvero un collo di bottiglia e limiterà il tuo throughput al "anello più debole della catena" che è il tuo LB. Tuttavia, puoi aggirarlo. Se si utilizza qualcosa noto come "switchback" o "ritorno diretto al server" è possibile eseguire flussi di traffico asincroni. Il modo in cui funziona è questo:

a) il client invia una richiesta http a 2.2.2.2

b) LB risponde alla 2.2.2.2 e passa la richiesta in arrivo a un server - poiché LB e il server si trovano sulla stessa LAN, ciò avviene al livello 2.

c) Il server accetta questa connessione in entrata in quanto IP 2.2.2.2 si trova su un'interfaccia di loopback con alias (altrimenti eliminerebbe un pacchetto che non corrispondeva a un'interfaccia).

d) Il server risponde direttamente al client.

La richiesta è di pochi byte. Il contenuto offerto può essere di qualsiasi dimensione. Il traffico in uscita non passa attraverso l'LB, quindi puoi gestire MODO più traffico.

Saluti,

--tc

— Thomas Cannon
fonte

1

Tieni presente che farlo è appropriato solo per i cluster L4. Per i cluster L7, questa operazione interromperà le riscritture delle intestazioni, l'inserimento dei cookie (persistenza), la terminazione SSL, qualsiasi tipo di corrispondenza URL e qualsiasi altra funzionalità più avanzata di molti bilanci di carico.

— YLearn