Come funziona esattamente e specificamente l'hash dell'indirizzo di destinazione LACP di livello 3?

Sulla base di una domanda precedente più di un anno fa ( Multiplexed 1 Gbps Ethernet? ), Sono andato fuori e ho installato un nuovo rack con un nuovo ISP con collegamenti LACP ovunque. Ne abbiamo bisogno perché abbiamo singoli server (una applicazione, un IP) che servono migliaia di computer client su Internet in eccesso di 1 Gbps cumulativi.

Questa idea di LACP dovrebbe consentirci di rompere la barriera da 1 Gbps senza spendere una fortuna in switch e schede di rete 10GoE. Sfortunatamente, ho riscontrato alcuni problemi con la distribuzione del traffico in uscita. (Questo nonostante l'avvertimento di Kevin Kuphal nella domanda sopra collegata.)

Il router dell'ISP è un Cisco di qualche tipo. (L'ho dedotto dall'indirizzo MAC.) Il mio switch è un HP ProCurve 2510G-24. E i server sono HP DL 380 G5 con Debian Lenny. Un server è un hot standby. La nostra applicazione non può essere raggruppata. Ecco un diagramma di rete semplificato che include tutti i nodi di rete rilevanti con IP, MAC e interfacce.

Sebbene abbia tutti i dettagli, è un po 'difficile lavorare con e descrivere il mio problema. Quindi, per semplicità, ecco un diagramma di rete ridotto ai nodi e ai collegamenti fisici.

Quindi sono andato via e ho installato il mio kit sul nuovo rack e ho collegato i cavi del mio ISP dal loro router. Entrambi i server hanno un collegamento LACP al mio switch e lo switch ha un collegamento LACP al router ISP. Fin dall'inizio mi sono reso conto che la mia configurazione LACP non era corretta: i test hanno mostrato che tutto il traffico da e verso ciascun server stava attraversando un collegamento GoE fisico esclusivamente tra server-switch e switch-router.

Con alcune ricerche su Google e un sacco di tempo RTMF per quanto riguarda il legame NIC Linux, ho scoperto che avrei potuto controllare il legame NIC modificando /etc/modules

# /etc/modules: kernel modules to load at boot time.
# mode=4 is for lacp
# xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2 
bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1

loop

In questo modo il traffico ha lasciato il mio server su entrambe le schede NIC come previsto. Ma il traffico si stava spostando dallo switch al router su un solo collegamento fisico, comunque .

Abbiamo bisogno che il traffico attraversi entrambi i collegamenti fisici. Dopo aver letto e riletto la Guida alla gestione e alla configurazione del 2510G-24 , trovo:

[LACP utilizza] coppie di indirizzi di origine-destinazione (SA / DA) per distribuire il traffico in uscita su collegamenti trunked. SA / DA (indirizzo di origine / indirizzo di destinazione) fa sì che lo switch distribuisca il traffico in uscita ai collegamenti all'interno del gruppo di trunk sulla base delle coppie di indirizzi di origine / destinazione. Cioè, lo switch invia il traffico dallo stesso indirizzo di origine allo stesso indirizzo di destinazione attraverso lo stesso collegamento trunked e invia il traffico dallo stesso indirizzo di origine a un indirizzo di destinazione diverso attraverso un collegamento diverso, a seconda della rotazione delle assegnazioni di percorso tra collegamenti nel bagagliaio.

Sembra che un collegamento collegato presenti un solo indirizzo MAC, e quindi il mio percorso da server a router sarà sempre su un percorso dallo switch al router perché lo switch vede solo un MAC (e non due - uno da ogni porta) per entrambi i collegamenti LACP.

Fatto. Ma questo è quello che voglio:

Uno switch HP ProCurve più costoso è che il 2910al utilizza indirizzi di origine e destinazione di livello 3 nel suo hash. Dalla sezione "Distribuzione del traffico in uscita attraverso i collegamenti trunked" della Guida alla gestione e alla configurazione di ProCurve 2910al :

La distribuzione effettiva del traffico attraverso un trunk dipende da un calcolo che utilizza i bit dell'indirizzo di origine e dell'indirizzo di destinazione. Quando è disponibile un indirizzo IP, il calcolo include gli ultimi cinque bit dell'indirizzo di origine IP e dell'indirizzo di destinazione IP, altrimenti vengono utilizzati gli indirizzi MAC.

OK. Quindi, affinché funzioni nel modo in cui lo voglio, l'indirizzo di destinazione è la chiave poiché il mio indirizzo di origine è fisso. Questo porta alla mia domanda:

Come funziona esattamente e specificamente l'hash LACP di livello 3?

Devo sapere quale indirizzo di destinazione viene utilizzato:

• l'IP del cliente , la destinazione finale?
• O l'IP del router , la prossima destinazione di trasmissione del collegamento fisico.

Non siamo ancora andati a comprare un interruttore sostitutivo. Aiutami a capire esattamente se l'hash dell'indirizzo di destinazione LACP di livello 3 è o non è quello di cui ho bisogno. L'acquisto di un altro interruttore inutile non è un'opzione.

Quello che stai cercando è comunemente chiamato "trasmetti hash policy" o "trasmetti algoritmo hash". Controlla la selezione di una porta da un gruppo di porte aggregate con cui trasmettere un frame.

Mettere le mani sullo standard 802.3ad si è rivelato difficile perché non sono disposto a spendere soldi per questo. Detto questo, sono stato in grado di ottenere alcune informazioni da una fonte semi-ufficiale che fa luce su ciò che stai cercando. In base a questa presentazione del gruppo di studio ad alta velocità Ottawa, ON, CA IEEE del 2007, conforme allo standard 802.3ad, non sono richiesti algoritmi particolari per il "distributore di frame":

Questo standard non impone particolari algoritmi di distribuzione; tuttavia, qualsiasi algoritmo di distribuzione deve garantire che, quando i frame vengono ricevuti da un Frame Collector come specificato in 43.2.3, l'algoritmo non deve causare a) l'ordinamento errato dei frame che fanno parte di una determinata conversazione, oppure b) la duplicazione dei frame . Il requisito di cui sopra per mantenere l'ordine dei frame è soddisfatto assicurando che tutti i frame che compongono una determinata conversazione siano trasmessi su un singolo collegamento nell'ordine in cui sono generati dal client MAC; pertanto, questo requisito non comporta l'aggiunta (o la modifica) di alcuna informazione al frame MAC, né alcun buffering o elaborazione da parte del Frame Collector corrispondente al fine di riordinare i frame.

Pertanto, qualunque algoritmo utilizzato da un driver switch / NIC per distribuire i frame trasmessi deve rispettare i requisiti indicati in quella presentazione (che, presumibilmente, faceva riferimento allo standard). Non è stato specificato alcun algoritmo specifico, è stato definito solo un comportamento conforme.

Anche se non è stato specificato alcun algoritmo, possiamo esaminare un'implementazione particolare per avere un'idea di come un tale algoritmo potrebbe funzionare. Il driver "bonding" del kernel Linux, ad esempio, ha una politica di hash di trasmissione conforme allo standard 802.3ad che applica la funzione (vedere bonding.txt nella directory Documentation \ networking del sorgente del kernel):

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

Ciò fa sì che sia gli indirizzi IP di origine e di destinazione, sia gli indirizzi MAC di origine e di destinazione, influenzino la selezione della porta.

L'indirizzo IP di destinazione utilizzato in questo tipo di hashing sarebbe l'indirizzo presente nel frame. Prenditi un secondo per pensarci. L'indirizzo IP del router, in un'intestazione di frame Ethernet lontano dal tuo server a Internet, non è incapsulato da nessuna parte in tale frame. L' indirizzo MAC del router è presente nell'intestazione di tale frame, ma l'indirizzo IP del router non lo è. L'indirizzo IP di destinazione incapsulato nel payload del frame sarà l'indirizzo del client Internet che effettua la richiesta al server.

Una politica di hash di trasmissione che tenga conto degli indirizzi IP di origine e di destinazione, supponendo che tu abbia un pool di client molto vario, dovrebbe fare abbastanza bene per te. In generale, indirizzi IP di origine e / o destinazione più diversificati nel traffico che fluisce attraverso tale infrastruttura aggregata comporteranno un'aggregazione più efficiente quando viene utilizzata una politica di hash di trasmissione basata su layer 3.

I tuoi diagrammi mostrano le richieste che arrivano direttamente ai server da Internet, ma vale la pena sottolineare cosa potrebbe fare un proxy alla situazione. Se stai inoltrando richieste client ai tuoi server, allora, come dice chris nella sua risposta, potresti causare colli di bottiglia. Se quel proxy sta effettuando la richiesta dal proprio indirizzo IP di origine, anziché dall'indirizzo IP del client Internet, avrai meno "flussi" possibili in una politica di hash di trasmissione basata su 3 livelli rigorosamente.

Una politica di hash di trasmissione potrebbe anche tenere conto delle informazioni di livello 4 (numeri di porta TCP / UDP), purché rispettasse i requisiti dello standard 802.3ad. Tale algoritmo si trova nel kernel di Linux, come riferimento nella tua domanda. Ricorda che la documentazione per quell'algoritmo avverte che, a causa della frammentazione, il traffico potrebbe non necessariamente fluire lungo lo stesso percorso e, in quanto tale, l'algoritmo non è strettamente conforme allo standard 802.3ad.

molto sorprendentemente, alcuni giorni fa i nostri test hanno dimostrato che xmit_hash_policy = layer3 + 4 non avrà alcun effetto tra due server Linux collegati direttamente, tutto il traffico utilizzerà una porta. entrambi eseguono xen con 1 bridge che ha il dispositivo di legame come membro. la maggior parte ovviamente, il bridge potrebbe causare il problema, solo che non ha assolutamente senso considerando che sarebbe usato l'hash basato su porta ip +.

So che alcune persone riescono effettivamente a spingere 180 MB + su collegamenti collegati (cioè utenti di ceph), quindi funziona in generale. Possibili cose da guardare: - Abbiamo usato il vecchio CentOS 5.4 - L'esempio di OP significherebbe che il secondo LACP "indebolisce" le connessioni - ha senso, mai?

Cosa mi ha mostrato questo thread, la lettura della documentazione, ecc.

• Generalmente tutti ne sanno molto, sono bravi a recitare la teoria dal bonding howto o persino dagli standard IEEE, mentre l'esperienza pratica non è quasi nulla.
• La documentazione RHEL è nella migliore delle ipotesi incompleta.
• La documentazione relativa al legame è del 2001 e non è abbastanza attuale
• la modalità layer2 + 3 apparentemente non è in CentOS (non viene mostrata in modinfo e nel nostro test ha lasciato cadere tutto il traffico quando abilitato)
• Non aiuta che SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) e RedHat (BONDING_OPTS) abbiano tutti modi diversi di specificare le impostazioni della modalità per-bond
• Il modulo del kernel CentOS / RHEL5 è "SMP sicuro" ma non "capace di SMP" (vedi discorso ad alte prestazioni di Facebook) - NON scala sopra una CPU, quindi con un clock di CPU superiore più elevato> molti core

Se qualcuno finisce una buona configurazione di bonding ad alte prestazioni, o sa davvero di cosa sta parlando, sarebbe fantastico se impiegassero mezz'ora a scrivere un nuovo piccolo howto che documenta UN esempio di funzionamento usando LACP, niente cose strane e larghezza di banda > un collegamento

Se il tuo switch vede la vera destinazione L3, può farlo con l'hash. Fondamentalmente se hai 2 collegamenti, pensa che il collegamento 1 sia per destinazioni dispari, il collegamento 2 sia per destinazioni pari. Non credo che utilizzino mai l'IP dell'hop successivo a meno che non siano configurati per farlo, ma è praticamente lo stesso che usare l'indirizzo MAC della destinazione.

Il problema che incontrerai è che, a seconda del tuo traffico, la destinazione sarà sempre l'indirizzo IP singolo del singolo server, quindi non userai mai quell'altro link. Se la destinazione è il sistema remoto su Internet, otterrai una distribuzione uniforme, ma se è qualcosa di simile a un server Web, in cui il tuo sistema è l'indirizzo di destinazione, lo switch invierà sempre il traffico solo su uno dei collegamenti disponibili.

Sarai ancora peggio se c'è un bilanciamento del carico da qualche parte lì dentro, perché l'IP "remoto" sarà sempre o l'IP o il server del bilanciamento del carico. Potresti aggirare un po 'questo usando molti indirizzi IP sul bilanciamento del carico e sul server, ma questo è un trucco.

Potresti voler espandere un po 'il tuo orizzonte dei fornitori. Altri fornitori, come le reti estreme, possono eseguire l'hash su cose come:

Algoritmo L3_L4: livello 3 e livello 4, indirizzi IP di origine e destinazione combinati e numeri di porta TCP e UDP di origine e destinazione. Disponibile sugli switch SummitStack e Summit X250e, X450a, X450e e X650.

Quindi sostanzialmente finché la porta di origine del client (che in genere cambia molto) cambia, distribuirai uniformemente il traffico. Sono sicuro che altri fornitori hanno caratteristiche simili.

Anche l'hashing su IP di origine e di destinazione sarebbe sufficiente per evitare hot-spot, purché non ci sia un bilanciamento del carico nel mix.

Immagino che sia fuori dall'IP client, non dal router. Gli IP di origine e destinazione reali avranno un offset fisso nel pacchetto, e sarà veloce fare hash. L'hash dell'IP del router richiederebbe una ricerca basata sul MAC, giusto?

Da quando sono appena tornato qui, alcune cose che ho imparato ormai: per evitare i capelli grigi, hai bisogno di un interruttore decente che supporti una politica layer3 + 4, e lo stesso anche in Linux.

In parecchi casi la fiamma ossidrica pervertente chiamata ALB / SLB (mode6) potrebbe funzionare meglio. Operativamente fa schifo però.

Io stesso provo a usare 3 + 4 ove possibile, poiché spesso desidero quella larghezza di banda tra due sistemi adiacenti.

Ho anche provato con OpenVSwitch e una volta ho avuto un'istanza in cui quel flusso di traffico interrotto (ogni primo pacchetto perso ... non ne ho idea)