Perché open-iscsi ha una scrittura due volte più lenta di Samba tramite Ethernet 10G?

Sul mio file server locale ho raid-6 su unità HDD 7x.

dd if=/dev/zero of=tempfile bs=1M count=2048 conv=fdatasync

Il test di velocità locale mi dà 349 MB / s di velocità di scrittura.

Le scritture remote su Samba da SSD (> 2 Gb / s di velocità di lettura) mi danno 259 MB / s di scritture. Ma le scritture remote sull'unità iSCSI (sull'iniziatore iSCSI Win10) mi danno solo 151 Mb / s di scrittura.

raid6 config - dimensione del blocco 128K, stripe_cache_size = 8191. La bitmap dell'intenzione di scrittura è su SSD (Samsung 860 PRO, blocco bitmap 4096K).

Matrice montata con opzioni: rw,noatime,nobarrier,commit=999,stripe=128,data=writeback

open-iscsi setup: target si basa su un file da 4Tb.

Qualche suggerimento sul perché iSCSI è più lento di Samba nelle scritture? Qualche suggerimento su come migliorare la velocità di scrittura iSCSI?

Presumo che abbia a che fare con il desiderio di open-iscsi di scaricare le scritture su disco dopo ogni operazione, il che aumenta l'amplificazione della scrittura su raid6 a causa di eccessive riscritture di parità. Ma non sono sicuro di come risolverlo. Accelerare più importante della sicurezza dei dati attualmente scritti in caso di interruzione di corrente.

Come nota a margine, il target iSCSI ietd più vecchio aveva la capacità di abilitare la modalità write-back (usando IOMode=wb) e la velocità di scrittura sostenuta era molto più veloce. Sfortunatamente sembra attualmente non mantenuto.

Prima di tutto, il RAID-6 è il problema a causa del calcolo della doppia parità. In secondo luogo, è possibile connettere due volte la destinazione iSCSI nell'iniziatore iSCSI MS, abilitare RR o la profondità minima della coda (purtroppo Win10 non supporta il multipath, quindi è possibile testarlo con Windows Server).

In effetti, l'accesso a livello di blocco deve essere più veloce dell'accesso a livello di file. Che tipo di strumento di benchmarking stai usando dal sito di Windows? Consiglierei di usare diskspd o FIO. Inoltre, puoi usare qualcosa come Starwind come destinazione iSCSI molto più veloce.

https://www.starwindsoftware.com/starwind-virtual-san#Hyper-V

iSCSI dovrebbe essere usato a livello di blocco, la descrizione della tua installazione sembra che tu stia usando un file system, posizionando un file su di esso e quindi eseguendo questo file come livello di blocco iSCSI.

Questo è ben lungi dall'essere l'ideale e sicuramente non è una configurazione per confrontare le velocità. Prova a usare lvm in cima a raid6 per segmentare lo spazio e rimanere sul layer blocchi per iSCSI, oppure usa raid6 direttamente come dispositivo iSCSI.

Nella configurazione corrente, i dati vengono trasferiti attraverso la rete, colpendo un file nel filesystem, che (molto probabilmente) non è ottimizzato per questo tipo di carico di lavoro e condiviso anche con altri processi. È possibile eseguire tale configurazione con iSCSI, ma deve essere considerata una soluzione di fallback non ottimizzata.

Si noti che ddè un benchmark molto semplice ed è MOLTO soggetto a distorsioni. Ad esempio, ddstai scrivendo zero - se qualcosa ha un caso speciale per dati pieni di zero (ad esempio perché può fare la compressione) vedrai prestazioni fantastiche ma passerai a scrivere "dati reali" diversi da zero e all'improvviso tali prestazioni potrebbero scomparire. ..

Per rispondere alla tua domanda (come in tutti i benchmark) devi davvero isolare i pezzi per identificare il bit che introduce il problema. Ad esempio, scrivere direttamente sul filesystem di Windows (e non su iSCSI) è anche estremamente veloce? Se prendi la stessa configurazione hardware ed esegui Linux invece di Windows, è altrettanto veloce o rallenta? Cosa succede se si passa all'uso di uno strumento di riferimento come fio ?

Purtroppo ci sono troppe possibilità per poter rispondere a una domanda come questa ...