Basse prestazioni sia iSCSI che AoE

Siamo alla ricerca di una velocità di archiviazione risonabile. A causa del budget limitato, abbiamo deciso di utilizzare i target software iSCSI o AoE. Prima di cambiare la nostra infrastruttura di produzione, stiamo facendo alcuni test per scegliere la migliore tecnologia.

Per i test utilizziamo:

• Fujitsu Siemens RX200 S4 come target
• Fujitsu Siemens RX200 S4 come iniziatore
• Switch da 1 GBit gestito da NetGear
• schede di rete integrate (Broadcom con TOE), schede di rete EdiMax, schede di rete Broadcom con TOE - tutte da 1 GB
• il server di destinazione utilizza un controller QLogic con 6 unità WD Blue SATA da 2 TB.
• entrambi i sistemi operativi di destinazione e iniziatore sono Ubuntu 16.04 LTS con tutti gli aggiornamenti. Switch è dedicato allo scopo di archiviazione. Testiamo obbligazioni e multipathing.

Il nostro problema è la bassa velocità di lettura. Per i test utilizziamo ddun file da 40-100 GB.

• lettura e scrittura locali su un server di destinazione è superiore a 300 MB / s.
• la scrittura sul server tramite iSCSI o AoE è superiore a 200 MB / s, il che ci soddisfa.
• la lettura dal server è sempre di 95-99 MB / s.

Abbiamo provato ietd, aoetools, LIO. Abbiamo usato legami di 2 NIC: balance-rr e LACP, multipathing con rr. Telai normali e jumbo usati. Finalmente abbiamo persino diretto la connessione ethernet tra target e host (senza switch).

Tutti i test danno più o meno gli stessi risultati (ovviamente l'uso di NIC comuni senza TOE e iSCSI ha dato risultati peggiori del 20-30%).

La rete di test con iperf ha mostrato trasferimenti di circa 200 MB / s (2 GBit). Osservare l'utilizzo delle schede di rete su target con bmon ha mostrato un uguale utilizzo di entrambi i dispositivi (ciascuno circa 50 MB / s per la lettura, circa 100 MB / s per la scrittura).

Dato che non abbiamo avuto fortuna, abbiamo deciso di utilizzare una terza scheda di rete (entrambe le parti ovviamente). I risultati furono strani:

• 2 schede di rete - 50 MB / s ciascuna
• 3 schede di rete - 33 MB / s ciascuna

Esiste un limite al software di destinazione che disabilita l'output superiore a 1 GBit / s?

Cosa facciamo di sbagliato?

Per ottenere le massime prestazioni dall'archiviazione connessa iSCSI, è necessario utilizzare Jumbo Frames e MPIO (non LACP). RDMA / iSER è raccomandato se è possibile farlo.

AOE (ATA over Ethernet) è vecchio ed è merda. Ci siamo già sbarazzati di Coraid anni fa. Stiamo usando StarWind https://www.starwindsoftware.com/ come target iSCSI già da un po 'di tempo e StarWind ci ha chiesto di migrare da Coraid a qualsiasi spazio di archiviazione che potessimo fare.

Quindi, al momento, siamo molto bravi con iSCSI fornito da StarWind e utilizzando Windows, ESX e SCST http://scst.sourceforge.net/ su Linux come iniziatori. Con RDMA / iSER fa fino a 10 Gbit, molto felice finora.

Le tue aspettative su come funziona l'aggregazione dei collegamenti Ethernet non sono corrette.

Tutti i metodi di aggregazione diversi da balance-rr (ovvero: tutti i metodi la cui modalità> 0) non offrono un throughput a connessione singola maggiore; piuttosto, aumentano la larghezza di banda disponibile totale quando vengono stabilite connessioni multiple da / verso gli host interessati. In altre parole, LAG / LACP non offre alcun vantaggio per questo scenario a connessione singola.

L'unico metodo di aggregazione che può darti un throughput a singola sessione maggiore di quello che puoi normalmente avere su una singola interfaccia è balance-rr , che distribuisce i pacchetti in modo round robin. Si doveva impostare equilibrio-rr sulla sia l'iniziatore e il bersaglio. Tuttavia, un grosso problema è che questo è in gran parte dipendente dallo switch.

Ad ogni modo, se imposti sia target che iniziatore su balance-rr, collegare direttamente le due macchine dovrebbe darti prestazioni migliori. In caso contrario, è possibile pubblicare un iperfcon balance-rr ed entrambe le macchine connesse direttamente (nessun interruttore)? Inoltre, inserisci il ddcomando esatto che hai utilizzato per il benchmarking.

Nota: sto parlando solo di iSCSI qui. Non ho esperienza con AoE oltre a leggerlo e non lo implementerei in nessuna nuova infrastruttura (è praticamente defunto).

Non usare balance-rr per qualcosa di diverso da alcuni protocolli punto-punto molto specifici. Ha prestazioni orribili quando è sotto quasi ogni tipo di carico del mondo reale e causa una serie di problemi di rete (come MOLTO jitter). Sicuramente non usarlo con un interruttore.

Utilizzare MPIO senza alcun legame sul lato dell'iniziatore per ottenere il bilanciamento del carico e la tolleranza agli errori. Per garantire che i percorsi non vengano "confusi" inviando tutto il traffico in un unico percorso, collocare percorsi individuali (NIC gigabit tra destinazione e iniziatore, nel tuo caso) su sottoreti separate.

Sentiti libero di legare il lato target con LACP per percorso (come in due legami per due percorsi per un totale di quattro schede di rete, ad esempio una configurazione della porta di destinazione). Funziona alla grande e può bilanciare più connessioni di iniziatore che usano gli stessi percorsi. Se possibile, usa anche i frame jumbo e iSER. L'uso di LACP sull'obiettivo bilancerà le connessioni a ciascun percorso tra più schede di rete.

L'uso di LACP sull'iniziatore sarà efficace solo se sta effettuando molte connessioni al portale di destinazione con uso simultaneo (non comune per quasi tutti i carichi di lavoro). Anche se dovessi implementare in modo efficace LACP per percorso sull'iniziatore, diventerebbe rapidamente un incubo di cablaggio per utilizzare (ad esempio) quattro tessuti aggiuntivi per ogni scatola. Se è necessario un throughput superiore a ~ 2Gib / s a ​​un singolo iniziatore, prendere in considerazione Ethernet 10GiB / s.

La maggior parte delle risposte su AoE sono totalmente errate, controfattuali e mostrano una mancanza di conoscenza ed esperienza AoE. Prima di tutto, non è defunto. CORAID è il fornitore dietro AoE e hanno riavviato come "SouthSuite" mantenendo il marchio CORAID. Sono anche gli stessi sviluppatori. Stanno realizzando nuovi prodotti e supportando la maggior parte di quelli vecchi. Stanno spingendo avanti anche lo sviluppo di AoE, come mostrano chiaramente le loro mailing list tecniche aperte. Controlla il sito Web, è tutto aggiornato e racconta l'intera storia sulla loro pagina di storia.

Qualcuno ha detto che AoE non trarrà beneficio dai frame jumbo ed è stato anche sbagliato. È stato supportato dopo il rilascio della versione 13 di "vbladed". Devi ottimizzare il tuo MTU per supportare la nuova dimensione del frame, ma per il resto funziona alla grande.

iSCSI viene eseguito nel layer 5 del modello OSI. Il suo solito trasporto è TCP. Questo ti dà una correzione degli errori (a causa di checksum in TCP) e ti consente di instradare il traffico su IP a livello 3. Ecco dove finiscono i vantaggi di iSCSI. Le sue prestazioni nel mondo reale sono davvero terribili quando le confronti in modo equo con qualcosa come FCP, AoE o FCoE. Ti inviterei a google "confronto prestazioni iscsi" per lo spettacolo horror.

Il problema relativo alla velocità di lettura potrebbe essere stato causato da un'errata configurazione della rete, disattivare il controllo del flusso e assicurarsi di utilizzare un buffer socket sufficientemente grande. Non hai nemmeno menzionato se il tuo filesystem sottostante fosse stato ottimizzato per il prefetching o meno. In base al tuo scenario, ciò potrebbe aiutarti molto, ma fai attenzione a non usarlo con alcuni database che richiedono la memorizzazione nella cache.

L'aggregazione 802.3ad non aumenterà molto il throughput del singolo flusso, anche in uno scenario round robin. Inoltre complicherà la configurazione della tua rete e ti darà un paio di nuove opportunità per spararti ai piedi non corrispondendo agli intervalli PDU o configurando erroneamente il tuo collegamento Cisco VPC per supportare lo stato attivo-attivo. Non usare LACP con AoE, lascia che gestisca il proprio multipathing e multiplexing. Le versioni successive di AoE lo gestiscono magnificamente e, nella maggior parte dei casi, con più grazia persino di FCP, poiché è tutto automatico. Le porte Ethernet aggiuntive offrono maggiore larghezza di banda e maggiore resilienza. Se si distribuiscono le porte Ethernet host e iniziatore su più switch, ciò può fornire ancora più ridondanza. Non è necessario configurare una modalità di incollaggio. Inoltre, non eseguire IP sulle stesse interfacce utilizzate per AoE.

In breve, non ascoltate gli oppositori di AoE, sembrano non avere molta esperienza e stanno solo cavalcando onde cerebrali alla moda. Evita il branco. Vai a configurare un backing store con prefetching ottimizzato a mano e probabilmente vedrai il tuo throughput di lettura salire di molto. Elimina l'uso dei protocolli di aggregazione ed esegui urlando da iSCSI. Un'ultima cosa, smettere di usare 'dd' non è un ottimo test ed è soggetto a cattivi effetti di memorizzazione nella cache. Utilizzare uno strumento di benchmark reale come 'fio', 'iozone' o 'dbench'. Questi danno risultati molto più affidabili.

So che LACP è per connessioni multiple. Testarlo è stato un atto di disperazione :)

Tutti i test sono stati eseguiti con balance-rr e due schede di rete.

Scrittura su target iSCSI:
dd se = / dev / zero di = / mnt / zero.bin bs = 1M count = 2000
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 byte (2,1 GB, 2,0 GiB) copiato , 10,193 s, 207 MB / s

Lettura dal target iSCSI:
dd if = / mnt / zero.bin di = / dev / null bs = 1M
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 byte (2,1 GB , 2,0 GiB) copiato, 16.1684 s, 130 MB / s

Velocità di rete:
iperf -c 172.16.10.80
------------------------ ------------------------------------
Client che si collega a 172.16.10.80, porta
TCP 5001 Dimensione finestra TCP: 325 KByte (impostazione predefinita)
--------------------------------------------- ---------------
[3] 172.16.10.70 porta locale 37024 collegata con 172.16.10.80 porta 5001
[ID] Larghezza di banda di trasferimento intervallo
[3] 0.0-10.0 sec 2.30 GBytes 1.98 Gbit / sec I

test con frame iperf e jumbo hanno dato gli stessi risultati.

Ho guadagnato un po 'di velocità di lettura eseguendo l'iniziatore:
hdparm -a 2048 / dev / dm-1
Precedentemente era 256 e la velocità di lettura era 96 ​​MB / s Il
mio obiettivo è raggiungere una velocità di lettura di circa 200 MB / s.

EDIT:
1. Non usiamo LACP - era una volta test.
2. I test con balance-rr e MPIO danno esattamente gli stessi risultati. Il multipath è stato testato con schede di rete in diverse sottoreti.
3. L'aggiunta di più schede di rete non aumenta la velocità di lettura, ma riduce solo l'utilizzo di ciascuna scheda di rete.
4. Pensiamo che il problema sia una limitazione (driver, modulo?) Che non consente di leggere più velocemente. Ma non sono sicuro, se si tratta del bersaglio o dell'iniziatore.


EDIT 2: Ho appena fatto qualche test aggiuntivo: configurato lo stesso host come target e iniziatore per eliminare i problemi hardware di rete. Sono rimasto scioccato: esattamente la stessa velocità di lettura! 130 MB / s! La scrittura è di 227 MB / s.

come hai configurato i tuoi nic sono tutti i buffer impostati correttamente, hai allocato abbastanza RAM ai buffer di rete. inoltre non utilizzare il legame qui è possibile utilizzare 2 canali iscsi e multipath sull'iniziatore, lo stesso con ATAoE l'iniziatore multipath tramite shelf e ID lun su qualsiasi percorso.