iSCSI performance - slechte performance

[PiOn]

Ha,

ik stel de vraag hier, in Netwerken, omdat ik niet specifiek weet waar het issue zit, en het uiteindelijk om network throughput gaat.

Situatie:

Ik probeer een iSCSI target (targetCli, CentOS7.4) te koppelen, via een Cisco 2960x switch (laatste IOS), naar 2 ESXi 6.5U1 hosts.

Details:
- Op ESXi: enkelvoudige, dedicated nic en vmkernel voor iSCSI
- CentOS: enkelvoudige, dedicated interface op CentOS, Dell PERC H700 RAID controller met BBU, laatste firmware, RAID set 1: 4x SATA2 2TB disks (WD RED)/RAID5, set 2: 4x SAS2 600GB 10K (Toshiba/HP)/RAID10. Builtin drivers

Allen dual port Intel PRO/1000 PT NICs, waarvan dus 1 port 1 gebruik, builtin drivers

Ik kom alleen niet boven de 120MB/s (write) en 260MB/s (read) uit, terwijl ik met vergelijkbare situaties in het verleden voor beide minimaal een factor 3 hoger heb gehaald.

ik heb inmiddels al zoveel geprobeerd, en gezocht op Internet/Google, maar ik kom letterlijk geen MB verder.

Wat heb ik al gedaan (na elkaar):
- switchen tussen beide RAID sets
- inzet van jumbo frames op de gehele keten (MTU 9000 ipv MTU 1500)
- settings op controller (WB/WT, direct/cached, (Adaptive)ReadAhead)
- iSCSI parameters op zowel TargetCli als ESX (bv FirstBurstLength, MaxBurstLength, MaxOutstandingR2T, etc)
- Ombouwen CentOS interface naar bonded LACP interface (Jumbo) op beide Intel NICs
- Uitschakelen TSO op NICs
- Aanpassen CentOS parameters (bv scheduler, blockdev, nr_request, vfs_cache)
- Aanpassen ESXi HWTransferSize

Met HDparm haal ik op de CentOS box ~1700MB/s (cached) en ~300MB/s (buffered).
Perf test is gedaan met een VM met builtin perf test (Cisco ISE, command show tech | begin "disk IO perf")

Zoals gezegd: geen enkele waarde wijzigt iets substantieels, ik krijg er bijna letterlijk geen MB bij (of af).

Heeft iemand een idee waar ik het moet zoeken?

[ Voor 4% gewijzigd door PiOn op 21-04-2018 04:41 . Reden: taalfouten en opmaak ]

[Equator]

Even een alias gemaakt in PNS

[Bastiaan V]

260 MB/sec over 1 gigabit link?

Ik ben bang dat je iets mist in het verhaal ;-)

[RedShift]

120MB/s (write)

Dat ligt zeer dicht bij de theoretische maximale doorvoersnelheid van gigabit ethernet (125 MB/s). Prima dus.

260MB/s (read)

Dat je sneller leest dan gigabit ethernet zal het gevolg zijn van caching. Indien je in het verleden ook hogere schrijfsnelheden haalde, dan zal dat ook het gevolg van caching geweest zijn.

Niets mis dus.

[bigfoot1942]

read caching kan, maar niet aan de kant van de ESXi server. Een eventuele read cache staat op de storage controller. ESXi doet daar niks mee. Dit is dus geen verklaring voor de rare meting.

[RedShift]

bigfoot1942 schreef op zaterdag 21 april 2018 @ 15:32:
read caching kan, maar niet aan de kant van de ESXi server. Een eventuele read cache staat op de storage controller. ESXi doet daar niks mee. Dit is dus geen verklaring voor de rare meting.

De meting is vanuit een virtuele machine gebeurd:

Perf test is gedaan met een VM met builtin perf test (Cisco ISE, command show tech | begin "disk IO perf")

En daar wordt er wel degelijk aan read caching gedaan. 260 MB/s read kan dus perfect als een deel van de te lezen blocks al gecached zijn. We weten ook niet precies wat de achterliggende benchmark methodiek is, dus alles vanaf dit punt is gissen.

[bigfoot1942]

Heerlijk, een kant en klare disk IO test welke automagisch aan read caching doet binnen de VM en dat zelf niet uitschakelt. Cisco en software...

@Verwijderd
Kan je de tests opnieuw doen en een screenshot maken van het netwerkverkeer op de host? Ik verwacht dat netwerkverkeer voor zowel lezen als schijven op 1000Mbit (Rx danwel Tx) zit...

Met iSCSI zou je met MPIO en gebruik van 2 nics gelijktijdig richting 200MB/s moeten kunnen komen, mits dit op zowel host als storage is doorgevoerd.

[RedShift]

bigfoot1942 schreef op zaterdag 21 april 2018 @ 17:05:
Heerlijk, een kant en klare disk IO test welke automagisch aan read caching doet binnen de VM en dat zelf niet uitschakelt. Cisco en software...

Het is niet de Cisco specifieke software dat dat doet. ISE draait op linux, en het is de linux kernel die read caching doet.

[Bierkameel]

Bastiaan V schreef op zaterdag 21 april 2018 @ 09:00:
260 MB/sec over 1 gigabit link?

Ik ben bang dat je iets mist in het verhaal ;-)

Hij gebruikt LACP oftwel teaming van de NIC's.
Dit geeft idd een hogere snelheid maar daar moet het OS wel goed mee om kunnen gaan, want je moet meerdere sessies gebruiken.

[Brahiewahiewa]

Bierkameel schreef op zaterdag 21 april 2018 @ 19:16:
[...]

Hij gebruikt LACP oftwel teaming van de NIC's.
Dit geeft idd een hogere snelheid maar daar moet het OS wel goed mee om kunnen gaan, want je moet meerdere sessies gebruiken.

Dan nog is een verwachting van 3 x 260 MBps erg optimistisch
We halen toch niet bits en Bytes doorelkaar?

[Bastiaan V]

Bierkameel schreef op zaterdag 21 april 2018 @ 19:16:
[...]

Hij gebruikt LACP oftwel teaming van de NIC's.
Dit geeft idd een hogere snelheid maar daar moet het OS wel goed mee om kunnen gaan, want je moet meerdere sessies gebruiken.

Dan hebben we het niet meer over een "enkelvoudige, dedicated interface". aan de centos kant :-)
Ook bij bonding van 2 1Gig interfaces is 260M niet haalbaar. Zelfs wanneer we uitgaan van 0 overhead is de max dan 250MBps.

[Question Mark]

Bierkameel schreef op zaterdag 21 april 2018 @ 19:16:
[...]

Hij gebruikt LACP oftwel teaming van de NIC's.

PiOn schreef op zaterdag 21 april 2018 @ 04:35:
- Op ESXi: enkelvoudige, dedicated nic en vmkernel voor iSCSI

Allen dual port Intel PRO/1000 PT NICs, waarvan dus 1 port 1 gebruik, builtin drivers

Zoals ik het lees heeft hij één port van zijn dualport nic in gebruik op zijn host. Dat het storage backend wel gebruik maakt van LACP levert voor de bandbreedte naar één host niks op. Dat blijft 1 Gbit.