ESX Cluster + SAN + mirroring performed zwaar ondermaats.

[Da_maniaC]

Hallo,

Binnen de organisatie waar ik werk is sinds een poos een volledig nieuwe omgeving opgezet welke volledig redundant is (maw er zijn meerdere vestigingen landelijk maar 2 hebben een datacenter waarbij de omgeving realtime wordt gemirrored dmv een dedicated synchronisatie lijn).

Nu weet ik zelf niet alle fijne details, daar ik een proces engineer / applicatie beheerder ben en geen systeembeheerder maar ik zal proberen om de situatie zo goed mogelijk te schetsen:
Beide datacenters bestaan uit een ESX cluster met ongeveer 8 x HP DL380 G6's (ik denk 2 hexa-cores en rond de 100GB RAM per machine) en een recent geplaatste IBM Storwize V7000 SAN met (als ik mij niet vergis) oa. een 10 of 12 SSD diskset voor hot data caching welke goed zou zijn voor rond de 180.000 IOPS of iets dergelijks.

Bottom line waar ik een beetje naar toe wil, is dat de performance echt zwaar ondermaats lijkt te zijn.
Op het actieve cluster draaien naar schatting zo'n 400 VM's waarvan ongeveer 350 Windows werkplekken zijn. De rest applicatie servers en een database server.

In het dagelijks gebruik merkt eigenlijk iedereen (en opvallend genoeg, met name de mirror vestiging) dat de prestaties van de Windows werkplekken werkelijk waar ruk is.
Het voelt een beetje aan als een remote desktop sessie naar een oud P4tje met een versleten HDD en zo voor iedere gebruiker. Responsiviteit is ver te zoeken en multitasken gaat zeer moeizaam.

Aangezien hetgeen mij allemaal wel interesseert (voorheen heb ik ook hardware engineering / systeembeheer gedaan maar op wat kleinere schaal) ben ik dus eigenlijk dit topic gestart.

Onze IT diensverlening heeft na lang onderzoeken eigenlijk uit kunnen sluiten dat de performance niet slecht is vanwege het feit dat de werkplekken zich off-site bevinden (maw dat er een internetverbinding tussen zit). De kwaliteit/bandbreedte van deze lijn zou ruimschoots voldoende zijn.

Dit doet mij dus een aantal dingen denken:
- Zou het SAN uberhaupt enige vorm van prioritisering kennen vwb de disk workload (I/O usage)?
De impact op het hele cluster is bijvoorbeeld gruwelijk wanneer de database server (VM) onder zware load komt te staan.
- Zou de inrichting dan wel hoge prioritisering van de synchronisatie verbinding tussen beide SANs ervoor kunnen zorgen dat de performance enkel op de gemirrorde site altijd slecht is?
(Het zou hier gaan om een aparte mirroring line tov het overige dataverkeer, wat zou vermoeden dat het wederom de SAN is welke staat te zweten/klapperen of niet optimaal werkt?).
- Bij aanhoudende slechte performance van virtuele machines...is dit op enige manier objectief te meten/benchmarken? Ik heb zelf sterk het gevoel dat de snelheid van de werkplekken te wijten is aan de performance van het gehele SAN+Cluster in plaats van dat de ontvangende zijde hier een rol in speelt.

Wellicht geef ik veel te weinig informatie... ik weet het niet.
Maar alle aangeschafte hardware zou zijn geïnventariseerd op 100% headroom (in verband met toekomstige groei van de organisatie) en toch is de performance zwaar ondermaats.

Ik vraag me dus gewoon heel erg af of hier mensen zijn die gelijkwaardige ervaringen hebben gehad en/of weten waar vaak de oorzaak ligt dan wel, waar constructief te beginnen met zoeken?

[Paul]

...en weer een VDI-implementatie die faalt op de IOPs van de werkplekken

Wij hebben ook een SVC / v7000 en voor ons VMware (server) cluster performt het uitstekend (en dan hebben we niet eens SSD's), maar VDI's trekken een bak IOPs waar je bang van wordt

Hoe is het ingericht? Je noemt mirroring, is het een vdisk mirror op je v7000? Metro mirror (sync)? Global mirror (async)? Spreken je hosts op de remote locatie ook daadwerkelijk het SAN op de remote locatie aan of staat de preferred node / active path in VMware naar de verkeerde node (in geval van een Split I/O-group, al dacht ik dat v7000s dat nog niet konden en je daarvoor een SVC nodig hebt) ?

Worden de VM's zelf ook gemirrord (FT?) of worden die dmv HA opnieuw gestart 'aan de overkant' als er iets mis gaat?

[Bor]

Ik lees veel "ik denk", "als ik mij niet vergis en "of iets dergelijks. Zonder daadwerkelijk kloppende input kan niemand hier echt iets zinvols over zeggen.

Maar alle aangeschafte hardware zou zijn geïnventariseerd op 100% headroom

Maar wat is de huidige stand van zaken? Je hebt het o.a. over DL380 G6 machines. Gen8 is de huidige generatie. De G6 werd al in maart 2009 aangekondigd. Dit doet denken dat het ontwerp en de inrichting ook al van rond die tijd zal stammen.

[ Voor 51% gewijzigd door Bor op 27-03-2014 13:23 ]

[Question Mark]

Hoe worden die vm's uitgerold/provisioned?

Is dat dmv een parent disk, met child-disks gelinked? Zo ja, probeer ervoor te zorgen dat de parent-disk permanent vanaf je ssd's komt.

Maar start allereerst met meten... Probeer de daadwerkelijke bottleneck te achterhalen.

[Bor]

Question Mark schreef op donderdag 27 maart 2014 @ 13:34:

Maar start allereerst met meten... Probeer de daadwerkelijke bottleneck te achterhalen.

Of schakel systeembeheer in; het is immers hun job. Je zult zelf als applicatiebeheerder niet overal bij kunnen neem ik aan.

[Da_maniaC]

Iedereen bedankt voor de reacties voor zover.
Ja zoals ik al vermelde heb ik niet alle exacte details.

Paul schreef op donderdag 27 maart 2014 @ 13:12:
Worden de VM's zelf ook gemirrord (FT?) of worden die dmv HA opnieuw gestart 'aan de overkant' als er iets mis gaat?

De VM's kunnen bij een lange outage op het tweede datacenter herstart worden inderdaad (gelukkig nog nooit voorgekomen).

Het exacte type synchronisatie weet ik niet.

Question Mark schreef op donderdag 27 maart 2014 @ 13:34:
Maar start allereerst met meten... Probeer de daadwerkelijke bottleneck te achterhalen.

Op wat voor manier zou er gemeten kunnen worden? Alle gebruikte meetmethodes binnen ESX laten bij normaal in bedrijf zijn, geen vreemde latencies ed. zien.

Bor de Wollef schreef op donderdag 27 maart 2014 @ 13:38:
Of schakel systeembeheer in; het is immers hun job. Je zult zelf als applicatiebeheerder niet overal bij kunnen neem ik aan.

Je slaat een beetje de spijker op zijn kop. Er wordt door een deel van het management nogal getwijfeld aan de adequaatheid van onze dienstverlener/systeembeheerders om dit goed/snel op te lossen (het probleem sleept namelijk al wat langer).
Nu gaan we hier al de nodige stappen voor nemen, maar wilde ik kijken of ik hier wellicht wat zinnigs te weten kon komen (met mijn geringe kennis over deze technologie), waarbij we in ieder geval wel de IT dienstverlener een harde schop in de goeie richting konden geven.
Als iemand een derde partij weet, welke dit soort problemen zeer snel/consequent kan analyseren en oplossen sta ik hier ook zeker voor open...

[ Voor 5% gewijzigd door Da_maniaC op 27-03-2014 14:10 ]

[Paul]

Kunnen jullie überhaupt op de v7000 inloggen? Op https://v7000/gui#monitor-perf zie je ook een aantal counters, totaal of per node. Met name de read- en write latencies van de volumes kunnen daar een indicatie geven. Het verschil tussen de volumes en mdisks is de invloed van je cache.

Je kunt er ook zien of je CPU swamped is en of je misschien je fibers vol hebt zitten.

[Question Mark]

Da_maniaC schreef op donderdag 27 maart 2014 @ 14:08:
Op wat voor manier zou er gemeten kunnen worden? Alle gebruikte meetmethodes binnen ESX laten bij normaal in bedrijf zijn, geen vreemde latencies ed. zien.

Pak de performance-monitor eens binnen de Windows VM's. Als je vermoed dat je performance-problemen op je storage-niveau vermoed is met de name de disk-queue een mooie counter om te controleren.

Voor de rest heb je natuurlijk de standaard waarden zoals: memory-gebruik, page-file usage, cpu-usage en dergelijke.

Op ESX niveau is de cpu-ready counter altijd wel intressant. Deze laat zien hoelang de VM op cpu-time moet wachten van de cpu-scheduler van VSphere. Bij hosts die erg overcommit zijn op cpu-gebied is dit altijd een erg intressante counter.

[Equator]

Zitten er naast de 10-12 SSD's ook nog andere disken in die V7000? Weet je hoe de Mdiskpool is ingericht?
Het Easytiering (zoals IBM dat noemt) werkt alleen goed als de Mdisk met SSD's in de Mdiskpool is meegenomen. En helaas maar waar, dat wordt wel eens vergeten.

Weet je verdere specs van de V7000 te noemen? Aantal disken, aantal disken per Mdisk, hoe ziet de Mdiskpool eruit? En hoeveel cache zit er op de controllers? Wordt er met thin provisioning gewerkt op de V7000 of niet?

Als je het niet begrijpt, huur dan een IBM specialist in. Je kan een SVC / V7000 niet vergelijken met een EVA of iets anders.

[Question Mark]

Equator schreef op vrijdag 28 maart 2014 @ 15:34:
Als je het niet begrijpt, huur dan een IBM specialist in.

Eens hoor, maar dan wel in een iets later stadium. TS moet eerst onderzoeken of het probleem daadwerkelijk ook storage-gerelateerd is.

Die kans is redelijk aanwezig hoor, maar ik heb ook al heel raar gedrag gezien bij een omgeving waarvan achteraf bleek dat de hosts qua memory overcommit waren..

[Equator]

True, natuurlijk alleen als je zeker weet dat het storage gerelateerd is

[CAPSLOCK2000]

Da_maniaC schreef op donderdag 27 maart 2014 @ 12:55:
- Zou de inrichting dan wel hoge prioritisering van de synchronisatie verbinding tussen beide SANs ervoor kunnen zorgen dat de performance enkel op de gemirrorde site altijd slecht is?
(Het zou hier gaan om een aparte mirroring line tov het overige dataverkeer, wat zou vermoeden dat het wederom de SAN is welke staat te zweten/klapperen of niet optimaal werkt?).

Je kan zo'n systeem configureren dat transacties pas klaar zijn als de replicatie gedaan is. Daarmee limiteer je de snelheid van het systeem effectief tot de snelheid en de latency van de lijn tussen de twee systemen. Als 750 systemen tegelijk via hetzelfde lijntje proberen te werken zal dat niet erg snel zijn. (Niet dat al die 750 systemen tegelijk actief zullen zijn, maar je snapt het punt wel).

- Bij aanhoudende slechte performance van virtuele machines...is dit op enige manier objectief te meten/benchmarken? Ik heb zelf sterk het gevoel dat de snelheid van de werkplekken te wijten is aan de performance van het gehele SAN+Cluster in plaats van dat de ontvangende zijde hier een rol in speelt.

IOPS en Latency wil je weten. Hoe je dat precies meet hangt af van wat er in je VMs zit.

[eddie4nl]

Zitten je VMs niet enorm te swappen?

Swappen kan zowel op VM als ESX niveau en genereren een hoop onnodige IOPS. ESX maakt ook vmem files aan zeker wanneer VMs langer draaien gaat ESX geheugen opruimen en naar vmem schrijven. Als er voldoende geheugen is kan je "reserve all guest memory" aanzetten.

[tomtom901]

Oef! En daarmee lekker in je HA slot sizes zitten rommelen? Als er geen noodzaak is voor reservations dan zou ik dat ook zeker, zeker weten proberen te vermijden waar mogelijk. Zeker als je de default admission control policy in een HA enabled cluster gebruikt - Host failures the cluster tolerates - die dus op basis van HA slot sizes werkt.

Een slot is een logische representatie van CPU en Memory resources en per default voor memory de hoogste reservation van een VM aangetroffen in het cluster + VM overhead.

[Da_maniaC]

Pagefile/Swapping van de VM's, disk queue's en cpu-ready/performance gegevens zien er over het algemeen goed uit.
Met tijd en wijlen loopt echter de write latency op het storwize SAN enorm op.

Na wat zoekwerk blijkt dat er momenteel gebruik wordt gemaakt van een Metro replicatie.
Ik ben zelf niet zo thuis in replicatie methodes op de schaal, maar er wordt gesproken over het feit dat Global mirroring wellicht een betere oplossing zou zijn.
Iemand enig idee of de huidige replicatie een i/o impact kan hebben als hetgeen we ervaren?
Veranderd dit tevens iets aan de callback van SAN 2 naar SAN 1?

[ Voor 18% gewijzigd door Da_maniaC op 08-04-2014 10:42 ]

[Question Mark]

Zoek eerst uit waadoor die write-latency veroorzaakt wordt...

Voor hetzelfde geld loopt er ergens op dat moment een grote maintenance job op één systeem die dit veroorzaakt. Dan kun je wellicht beter daar op focussen...

Je hebt nu nog steeds de echte oorzaak niet achterhaald.

[Paul]

Het verschil tussen Metro en Global is het verschil tussen synchrone replicatie en asynchroon.

Hoeveel bandbreedte is er beschikbaar tussen de locaties voor het replicatieverkeer? Wordt deze bandbreedte gedeeld met andere verkeersstromen?

Met Metro Mirroring wordt een write pas acknowledged naar je server (op A) wanneer het de v7000 (op A) de bevestiging heeft dat de v7000 (op B ) de write heeft veiliggesteld (of dat in cache of echt op disk is zou ik na moeten kijken, ik meen in cache). Als de latency op de lijn oploopt omdat die vol zit dan duurt het logischerwijs ook langer voordat deze ack terugkomt.

Met Global Mirroring wordt de write op A acknowledged naar de server op A wanneer de v7000 op A deze veilig heeft gesteld, daarna wordt pas de synchronisatie naar B gedaan. Afhankelijk van manier waarop (cycling) loopt B langer of korter achter. Met Cycling None loopt B over het algemeen (zegt men...) minder dan een seconde achter. Als je writes opspaart omdat je bijvoorbeeld alleen 's avonds voldoende capaciteit hebt om te mirroren dan is het natuurlijk afhankelijk van je schedule

[Da_maniaC]

@ Question Mark:
Bericht gehad van de leverancier. Kennelijk ontstaat de latency zodra er op SAN B een disk initialisatie wordt gedaan. Dit gepaard met de gebruikte replicatie methode (mirroring) zorgt voor hinder op de VM's.

@ Paul:
Dank voor de uitleg. Momenteel is er een 100 mbit full duplex lijn welke dedicated is voor de mirroring.
Global replicatie klinkt goed, ik zal hier mee volgen of men er binnenkort mee wil gaan testen.

[Question Mark]

Nou ken ik het IBM platform totaal niet hoor, maar waarom zou er op SAN B een disk initialisatie moeten plaatsvinden?

En 100 Mbit voor mirroring lijkt me niet veel... Dat betekend dat je max doorvoorsnelheid met synchrone replicatie hierdoor wel sterk beperkt wordt.

[Paul]

Maximaal met 100 mbit (na cache) schrijven naar een systeem dat tussen de 16 en 64 GBit FC heeft schiet niet echt op inderdaad Dan kun je beter asynchroon mirroren, dan kun je in ieder geval bursten.

Waarom de v7000 dagelijks aan het initialiseren is, dat is me inderdaad ook een raadsel. In de aanloopfase gaan er wat meer schijven stuk maar nog steeds niet iedere dag eentje... Daarnaast zou het een background task moeten zijn. Daar bovenop komt nog eens dat 12 MB per seconde natuurlijk een lachertje is voor zo'n systeem...