Aggregazione dei collegamenti di FreeBSD non più veloce del collegamento singolo

Abbiamo messo una NIC Intel I340-T4 a 4 porte in un server FreeBSD 9.3 ¹ e l'abbiamo configurata per l' aggregazione dei collegamenti in modalità LACP nel tentativo di ridurre il tempo necessario per il mirroring da 8 a 16 TiB di dati da un file server master a 2- 4 cloni in parallelo. Ci aspettavamo di ottenere una larghezza di banda aggregata fino a 4 Gbit / sec, ma non importa cosa abbiamo provato, non esce mai più veloce di 1 Gbit / sec aggregato. ²

Lo stiamo usando iperf3per testarlo su una LAN quiescente. ³ La prima istanza raggiunge quasi un gigabit, come previsto, ma quando ne iniziamo una seconda in parallelo, i due client diminuiscono a circa ½ Gbit / sec. L'aggiunta di un terzo client riduce la velocità di tutti e tre i client a ~ ⅓ Gbit / sec e così via.

Ci siamo occupati di impostare i iperf3test che indicano che il traffico proveniente da tutti e quattro i client di test arriva allo switch centrale su porte diverse:

Abbiamo verificato che ogni macchina di prova ha un percorso indipendente di ritorno allo switch rack e che il file server, la sua scheda NIC e lo switch dispongono tutti della larghezza di banda per eseguire questa operazione suddividendo il lagg0gruppo e assegnando un indirizzo IP separato a ciascuno delle quattro interfacce su questa scheda di rete Intel. In quella configurazione, abbiamo raggiunto una larghezza di banda aggregata di ~ 4 Gbit / sec.

Quando abbiamo iniziato questo percorso, lo stavamo facendo con un vecchio switch gestito SMC8024L2 . (Foglio dati PDF, 1.3 MB.) Non è stato l'interruttore di fascia più alta della sua giornata, ma dovrebbe essere in grado di farlo. Abbiamo pensato che l'interruttore potrebbe essere in errore, a causa della sua età, ma l'aggiornamento a un HP 2530-24G molto più capace non ha modificato il sintomo.

Lo switch HP 2530-24G afferma che le quattro porte in questione sono effettivamente configurate come trunk LACP dinamico:

# show trunks
Load Balancing Method:  L3-based (default)

  Port | Name                             Type      | Group Type    
  ---- + -------------------------------- --------- + ----- --------
  1    | Bart trunk 1                     100/1000T | Dyn1  LACP    
  3    | Bart trunk 2                     100/1000T | Dyn1  LACP    
  5    | Bart trunk 3                     100/1000T | Dyn1  LACP    
  7    | Bart trunk 4                     100/1000T | Dyn1  LACP    

Abbiamo provato LACP sia passivo che attivo.

Abbiamo verificato che tutte e quattro le porte NIC stanno ricevendo traffico sul lato FreeBSD con:

$ sudo tshark -n -i igb$n

Stranamente, tsharkmostra che nel caso di un solo client, lo switch divide il flusso da 1 Gbit / sec su due porte, apparentemente facendo ping-pong tra di loro. (Entrambi gli switch SMC e HP hanno mostrato questo comportamento.)

Poiché la larghezza di banda aggregata dei client si riunisce solo in un unico punto - allo switch nel rack del server - solo quello switch è configurato per LACP.

Non importa da quale cliente iniziamo per primi, o in quale ordine li avviamo.

ifconfig lagg0 sul lato FreeBSD dice:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
    ether 90:e2:ba:7b:0b:38
    inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fe80::92e2:baff:fe7b:b38%lagg0 prefixlen 64 scopeid 0xa 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    laggproto lacp lagghash l2,l3,l4
    laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

Abbiamo applicato tutti i consigli nella guida alla messa a punto della rete di FreeBSD che hanno senso per la nostra situazione. (Gran parte di esso è irrilevante, come le cose sull'aumento dei valori massimi di FD.)

Abbiamo provato a disattivare l'offload della segmentazione TCP , senza cambiare i risultati.

Non disponiamo di una seconda scheda NIC per server a 4 porte per impostare un secondo test. A causa dell'esito positivo del test con 4 interfacce separate, si suppone che nessuno dell'hardware sia danneggiato. ³

Vediamo questi percorsi in avanti, nessuno dei quali allettante:

1. Acquista uno switch più grande e più cattivo, sperando che l'implementazione LACP di SMC faccia schifo e che il nuovo switch sarà migliore. (L'aggiornamento a un HP 2530-24G non ha aiutato.)

2. Guarda ancora la laggconfigurazione di FreeBSD , sperando di aver perso qualcosa. ⁴

3. Dimentica l'aggregazione dei collegamenti e utilizza invece il DNS round robin per effettuare il bilanciamento del carico.

4. Sostituisci la scheda di rete del server e passa nuovamente, questa volta con roba da 10 GigE , a circa 4 volte il costo dell'hardware di questo esperimento LACP.

Le note

1. Perché non passare a FreeBSD 10, chiedi? Poiché FreeBSD 10.0-RELEASE utilizza ancora il pool ZFS versione 28 e questo server è stato aggiornato al pool ZFS 5000, una nuova funzionalità di FreeBSD 9.3. La linea 10. x non lo otterrà fino a quando FreeBSD 10.1 non verrà spedito circa un mese dopo . E no, la ricostruzione dalla sorgente per accedere al bleeding edge 10.0-STABLE non è un'opzione, poiché si tratta di un server di produzione.

2. Per favore, non saltare alle conclusioni. I nostri risultati dei test più avanti nella domanda ti dicono perché questo non è un duplicato di questa domanda .

3. iperf3è un test di rete puro. Mentre l'obiettivo finale è provare a riempire quel tubo aggregato da 4 Gbit / sec dal disco, non stiamo ancora coinvolgendo il sottosistema del disco.

4. Buggy o mal progettato, forse, ma non più rotto rispetto a quando ha lasciato la fabbrica.

5. Sono già stato strabico dal farlo.

Qual è l'algoritmo di bilanciamento del carico in uso sia sul sistema che sullo switch?

Tutta la mia esperienza con questo è su Linux e Cisco, non su FreeBSD e SMC, ma la stessa teoria è ancora valida.

La modalità di bilanciamento del carico predefinita sulla modalità LACP del driver di bonding Linux e su switch Cisco meno recenti come il 2950, ​​deve essere bilanciata solo in base all'indirizzo MAC.

Ciò significa che se tutto il tuo traffico passa da un sistema (file server) a un altro MAC (un gateway predefinito o un'interfaccia virtuale commutata sullo switch), il MAC di origine e di destinazione sarà lo stesso, quindi solo uno slave potrà mai essere utilizzato.

Dal tuo diagramma non sembra che tu stia inviando traffico a un gateway predefinito, ma non sono sicuro se i server di test siano in 10.0.0.0/24 o se i sistemi di test si trovino in altre sottoreti e vengano instradati tramite un'interfaccia di livello 3 sullo switch.

Se stai instradando sullo switch, c'è la tua risposta.

La soluzione a questo è utilizzare un diverso algoritmo di bilanciamento del carico.

Ancora una volta non ho esperienza con BSD o SMC, ma Linux e Cisco possono bilanciare sulla base delle informazioni L3 (indirizzo IP) o L4 (numero di porta).

Poiché ciascuno dei sistemi di test deve avere un IP diverso, provare a eseguire il bilanciamento in base alle informazioni L3. Se il problema persiste, cambia alcuni IP e verifica se modifichi il modello di bilanciamento del carico.