[SAN] read performance onder de maat

[Ethirty]

Ik zit een beetje met een vraag waar ik het antwoord wel op denk te weten, maar wat me niet logisch overkomt gezien de context. Wellicht hebben jullie nog wat input voor me?

Situatie:
Nieuw opgeleverde VMware omgeving met 1x DL380 G7 (er komt nog een 2e voor HA) en een HP P2000 iSCSI SAN, voorzien van 4x 10k SAS disks (R5, 1 LUN, 1 VMFS datastore). De host is met 2x Broadcom NIC's (ingesteld als iSCSI HBA) aangesloten op 2x HP 2910al switches en ingesteld voor multipathing. De beide controllers van de P2000 zitten elk op hun eigen switch, zo is het pad van host naar storage volledig redundant. Alles is ingesteld volgens best practices van HP en VMware.

Nu merk ik al direct bij de eerste installatie van de eerste server dat, bij bijvoorbeeld het openen van iets simpels als de DNS console (Windows), de read delay omhoog schiet naar zo'n 500ms. Ook bij iets als een shutdown schiet de read delay omhoog richting de 500ms. Gek genoeg krijg ik de write delay met allerhande kopieeracties niet boven de 10ms, dat zal het effect zijn van de 2GB aan cache die elke controller heeft.

Mijn eerste redenatie: de 4 disks leveren niet genoeg read IOPS.

Maar nu komt mijn twijfel om de hoek:
Bij een andere klant staat een vergelijkbare 4 disk opstelling als local storage in een vergelijkbare server en levert niet zulke vertragingen. Deze lokale controller heeft notabene ook nog eens minder cache.
Bij weer een andere klant staat ook zo'n P2000, maar dan een 6Gb shared SAS versie (ipv iSCSI). Hierin zitten 6x 15k schijven in R5, maar daarop draaien wel 6-8 servers en die schommelt ook rond maxima van 10ms delay.

Dus nu twijfel ik toch of ik het niet moet zoeken in het iSCSI stuk, dus ofwel finetunen van ESXi ofwel iets in de switches (flow control staat al aan). Heb al zitten kijken naar het finetunen van instellingen mbt Round Robin, maar met maar 1 LUN op 1 actieve controller vraag ik me af wat dat moet verbeteren.

[Question Mark]

Kijk even naar je prefered path, bij mijn weten doet een P2000 geen active/active over zijn controllers en is dus maar 1 actief. Zorg dan dat dat path prefered word.

Test verder ook even met de software iscsi initiator, waarschijnlijk gebruik je nu Broadcom 5709's en daar heb ik wel meer vreemde zaken mee beleefd.

[Voor 31% gewijzigd door Question Mark op 10-06-2011 13:30]

[WhizzCat]

Ha, dat hebben wij ook! Bijna dezelfde issues, maar dan met een Fiber SAN. Je zou even kunnen zien naar een firmware update van de NICs in je blade. Dat heeft bij ons al enorm geholpen Daar zat namelijk sowieso al een bug in.

Je moet je round robin voor loadbalancing met de hand ergens in een Advanced setting ook aanpassen overigens. Dat heeft iets te maken met het opzetten van data stromen. Normaal gaan er geloof ik iets van 1000 sessies over heen voordat het volgende pad gepakt wordt. Dit moet op 1 staan voor een stuk betere performance. Iig voor Fiber SAN, maar ik denk dat dit truukje ook wel toepasbaar is op iSCSI SAN.

[Ethirty]

De NC382 NIC's zijn zo te zien inderdaad gebaseerd op de Broadcom 5709. Ik zal binnenkort eens gaan testen met de software iSCSI initiator. Firmware is zover ik weet helemaal bij, is altijd het eerste dat ik check als zo'n ding uit de doos komt. Even booten met een recente firmware DVD is tenslotte zo gedaan.

Het prefered path is al het pad naar de owner van de LUN. Het klopt dat de P2000 geen echt active/active controllers zijn. Hij geeft gewoon binnenkomende requests op controller B intern aan controller A die vervolgens de disks aanspreekt. Vandaar dat tweaken aan round robin nog niet zo veel zin heeft, zeker zolang ik maar 1 lun heb.

Misschien in VMware ook eens kijken naar een failover instelling ipv round robin. Het structureel aanspreken van controller A via controller B geeft een onnodige performance impact. Ik had overigens ook over die truc gelezen, maar daar werd 3 ipv 1000 geadviseerd. Op 1 zetten had teveel CPU-overhead voor de extra winst tov 3.

Edit: Deze link lijkt het verhaal van Question Mark inderdaad te bevestigen: software iSCSI is sneller dan iSCSI offloading

[Voor 9% gewijzigd door Ethirty op 10-06-2011 14:13]

[Question Mark]

Als ik het me nog goed herinner ondersteunt de 5709 geen jumbo frames als deze voor iscsi offloading gebruikt wordt. Verder is het geen dedicated iscsi HBA maar zoals VMWare het noemt: "dependend hardware iscsi", waarbij slechts een gedeelte van de taken ge-offload worden.

Performance viel ons destijds ook flink tegen, vandaar dat we ook de software iscsi initator getest hebben. De performance verbeterde flink, terwijl de (in theorie) hogere cpu-usage nauwelijks merkbaar was (was te zien in esxtop). We hebben er toen maar voor gekozen om de 5709 te gebruiken in combinatie met de software initiator.

[Voor 38% gewijzigd door Question Mark op 10-06-2011 19:15]

[MoBi]

Je zal even moeten testen met jumbo frames (wel of niet), hba voor iscsi ofloading en software iscsi. Bij ons geval was de software iscsi zonder jumbo frames het snelst in combinatie met round robin.

[hans_lenze]

Hier een grafiekje van iemand die het verschil tussen Broadcom HBA tegenover software initiator + jumbo frames heeft getest:

Link

[Ethirty]

Je plaatje is offine, maar die link had ik zelf ook al aangehaald

Vooral het verschil in latency en queue depth zijn voor mij genoeg redenen om het met de software initiator te gaan proberen. Vrijdag ben ik op locatie en zal ik eens kijken of ik eea tussen de overige werkzaamheden omgezet krijg.

[Ethirty]

Heb vandaag de omgeving omgebouwd naar software iscsi, met én zonder jumbo frames. Maar dat lijkt haast nog slechter

Dit zijn de resultaten met jumbo ingeschakeld


Bijbehorende momentopname (piek) van esxtop:

 6:54:54pm up 11:28, 220 worlds; CPU load average: 0.00, 0.00, 0.00

   PORT-ID           USED-BY  TEAM-PNIC DNAME              PKTTX/s  MbTX/s
  16777217        Management        n/a vSwitch0              0.00    0.00
  16777218            vmnic0          - vSwitch0              0.40    0.00
  16777219            vmnic2          - vSwitch0              0.00    0.00
  16777220              vmk0     vmnic0 vSwitch0              0.40    0.00
  16777228        122472:SBS     vmnic2 vSwitch0              0.00    0.00
  33554433        Management        n/a vSwitch1              0.00    0.00
  33554434            vmnic1          - vSwitch1           2172.83    1.48
  33554435            vmnic3          - vSwitch1              0.00    0.00
  33554438              vmk1     vmnic1 vSwitch1           2172.83    1.48
  33554439              vmk2     vmnic3 vSwitch1              0.00    0.00

De eerste pieken in de latency zijn bij het opstarten van SBS2011 en lopen op tot dik 2 seconde terwijl de pieken in throughput zijn van een 15-tal Windows updates (waarbij de latency met zo'n 200ms in verhouding enorm meevalt). Vervolgens jumbo uitgeschakeld, maar ook dan zit ik al snel op 1,5 sec latency. Opstarten van een server duurt richting de 10 minuten en nog een minuut of wat om te stabiliseren Opstarten van iets als de Exchange console is ondoenlijk

En dat terwijl ik een paar weken geleden nog trots was op mijn SAS-based P2000 die in krap 30 sec klaar was met het rebooten van Windows

Ik heb ook nog gespeeld met de instellingen VMW_PSP_RR, VMW_PSP_MRU en VMW_PSP_FIXED_AP, maar dat lijkt 0,0 verschil te maken.

Ik snap er geen %$%@ van en begin me eerlijk gezegd een beetje zorgen te maken. Eea zal een keer in productie genomen moeten worden en die datum komt rap dichterbij. Er is geen nieuwere firmware voor de P2000 en ik kan niks vinden over dit verschijnsel waarbij de read latency zoveel hoger is dan de write latency.

[Dysmael]

Waarom geen tweede LUN maken en die direct in ESX koppelen als schijf?

Edit: Raw Device mapping heet dat in vSphere. Combineer je dat met een software iSCSI initiator dan moet er al aardig wat snelheidswinst geboekt worden lijkt mij.

Edit2:


Bij openen van DNS console op 2008 R2 guest waarvan het System / Boot volume via VMFS wordt aangesproken (dus geen RAW mapping in dit geval)

[Voor 110% gewijzigd door Dysmael op 17-06-2011 23:20]

[Ethirty]

Oa omdat je voor een RDM of 2e LUN eerst weer meer disks nodig hebt. En je hebt zo weinig aan 1 RDM als je 4 servers wil virtualiseren Het gaat erom dat het systeem op 4 10k disks genoeg IO zou moeten kunnen leveren voor een kleine omgeving, althans dat was wat ik veronderstelde.

Vandaag een hoop graaf en testwerk gedaan. Ben ook even terug gedoken in de docu van HP. Blijkt volgens de specs van HP dat de max read performance van de iSCSI versie ongeveer een derde is van de SAS versie. En dat terwijl de controllers, voor zover ik weet, identiek zijn op de interface na

P2000 RAID 5 Performance Results	P2000 G3 SAS	P2000 G3 1GbE iSCSI
Sequential Reads MB/s	1.572	520
Sequential Writes MB/s	1.172	510
Random Mix IOPs 60/40 read/write	12.835	7.900

Aangezien de max specs van de iSCSI versie qua random IOPS voor R1+0 (14.900) ongeveer gelijk is aan de SAS versie voor R5 (12.835) heb ik vandaag alle data verhuisd naar een NAS en de vdisk opnieuw aangemaakt met R1+0. En zowaar, bij het opstarten van de SBS server zie ik nu maximale piek van 160ms, terwijl dit gister nog een stevige 2300ms was. De interface van Windows reageert ook een stuk vlotter.

Dus dat ziet er al positief uit. Nu nog kijken hoe ik meer ruimte krijg, want ik ben nu van 900GB naar 600GB netto gegaan. Misschien voor de grootste disk maar thin provisioning inzetten, want die is op de groei aangemaakt.

Edit: nu breekt mijn klomp. Ik start voor de grap de SBS server nog eens op vanaf de NAS (4x SATA R5) en daar komt de read latency niet hoger dan 43ms

[Voor 4% gewijzigd door Ethirty op 19-06-2011 10:53]

[bigfoot1942]

Tip: test met een Intel nic.
Broadcom heeft hele series onboard nics gehad die onbetrouwbaar waren, en ook die offloading (en iSCSI features) kan je niet altijd helemaal uitschakelen.
(ben vergelijkbare problemen zelfs tegengekomen met 10G broadcom kaarten, en onbetrouwbaarheid van broadcom voor met name iSCSI speelt al een paar jaar...)

maar aan je verhaal je lezen is de oorzaak al gevonden?

[Ethirty]

Ik heb nog weinig ervaring met iscsi, maar dat lijkt inderdaad de oorsprong te zijn. En dat is het vreemde, aangezien het een heel gebruikelijk protocol is voor VMware. Daarnaast is de DL380 een van de meest gebruikte rackservers en er zijn talloze howto's voor VMware op een DL380 icm iscsi.

Even testen met een Intel nic gaat niet zomaar. Maar op basis van jou statement dat er vanalles mis is met de Broadcom's kan ik wel eens gaan zoeken naar info daarover.

[PcDealer]

Ethirty schreef op zaterdag 18 juni 2011 @ 23:45:
Ik heb nog weinig ervaring met iscsi, maar dat lijkt inderdaad de oorsprong te zijn. En dat is het vreemde, aangezien het een heel gebruikelijk protocol is voor VMware. Daarnaast is de DL380 een van de meest gebruikte rackservers en er zijn talloze howto's voor VMware op een DL380 icm iscsi.

Apart, wij zetten 90% DL380 G7 in. Ik heb die problemen nooit gehoord. We gebruiken volgens mij ook niet de offloading licentie. Er is wel een maar. We gebruiken meestal Intel 10Gb kaarten. Ik zal volgende week eens informeren.

[Ethirty]

Heb nu met aanpassingen in zowel ESXi als de switch de latency weten terug te brengen naar zo'n 30-50ms. Al een wereld van verschil met hoe het was, maar ik wil toch echt onder de 20 uitkomen.

Vmkping geeft me tijden van 0.3-0.5ms, dus dat lijken me prima waardes. Heeft iemand nog suggesties?

[bigfoot1942]

staar je niet dood op ping-tijden, de tijden in ESX(i) zijn afhankelijk van de packet size.
Meestal heeft men het over de latency met IO-sizes tot max 8K.
Dus in real-life; juist met grote IO-sizes (wat zeker positief is voor je throughput) zal je ping de lucht in schieten.

Welke tweaks heb je verder toegepast?

[Ethirty]

Ik wil toch nog even een kleine update geven.

Uiteindelijk bleek het een combinatie te zijn van een aantal kleine instellingen, met name op het gebied van de vlan's in de switch icm een firmware update die ten tijde van mijn eerste onderzoek nog niet uit was. Zie nu vooral sub 20ms tijden, zoals het hoort dus