In een nieuw opgezette, op Citrix Provisioning gebaseerde Citrix XenApp omgeving ontdekte ons team een probleem waardoor deze nieuwe omgeving niet goed presteerde. Alles leek net iets vertraagd terwijl de meeste best practices ten aanzien van Citrix XenApp toch echt waren toegepast. Wanneer de load op de omgeving hoger werd ontstonden flinke performance problemen wat weer resulteerde in andere vervelende randverschijnselen.
De setup van deze omgeving
Kijkende naar de setup, bleek dat de storage werd aangeboden als RAID 5. Dit type storage inrichting is geoptimaliseerd voor Read acties. Aangezien we te maken hebben met Citrix XenApp workers, welke vanwege Citrix Provisioning juist Write intensief zijn, is dit niet de meest voor de hand liggende setup zijn ten aanzien van deze omgeving. Helaas hadden we niet de luxe dit om te zetten naar een juist voor Writes geoptimaliseerde configuratie. Maar ook voor een RAID 5 configuratie vonden we de performance tegenvallen! Deze conclusie baseerden we op het vergelijken van resultaten uit diverse omgevingen.
Gelukkig werd als WriteCache methode de optie “Cache in Device RAM with overflow to hard disk” gebruikt waardoor de meeste Writes plaats zouden vinden in het memory van de VM op de host zelf. Dit vangt normaliter de meeste Writes af, waardoor je minder afhankelijk zou zijn van de Write performance van de aangeboden disks. Echter daarbij wordt vaak vergeten dat we ook nog te maken hebben met een Pagefile!
De Pagefile wordt door de Citrix Provisioning client na het booten automatisch verplaatst naar de D: schijf van de target device. Dit is nodig omdat Target Devices geen eigen C: schijf hebben waar normaal de Writes zouden plaatsvinden. Wanneer applicaties in gebruik worden genomen wordt op multi-user omgevingen de pagefile aanzienlijk zwaarder gebruikt door applicaties en het OS. Dat betekent dat veel Write acties niet in het geheugen terechtkomen, maar juist op D: waar de Pagefile zich bevindt!
“Sneak preview” van de oorzaak
Na enig speurwerk bleek dat de aangeboden SSD storage door VMWare niet gedetecteerd werd als SSD storage, maar als traditionele HDD!
Een bezoek aan de VMware forums en support sites gaf aan dat dit gedrag zich vaker voor bleek te doen binnen VMware omgevingen:
https://kb.vmware.com/s/article/2013188
https://kb.vmware.com/s/article/2008938?CoveoV2.CoveoLightningApex.getInitializationData=1&r=3&ui-communities-components-aura-components-forceCommunity-seoAssistant.SeoAssistant.getSeoData=1&other.KM_Utility.getArticleDetails=1&other.KM_Utility.getArticleMetadata=2&other.KM_Utility.getUrl=1&other.KM_Utility.getUser=1&other.KM_Utility.getAllTranslatedLanguages=2&ui-comm-runtime-components-aura-components-siteforce-qb.Quarterback.validateRoute=1
Ook diverse blog sites omschrijven hetzelfde probleem. Helaas vonden we op geen van de sites een oplossing voor ons probleem.
Na allerlei op forums benoemde mogelijke oplossingen te hebben geprobeerd zonder het gewenste resultaat te behalen, kwamen we er achter dat het omzetten van de storage detectie van HDD naar SSD de performance van de disks ook echt aanzienlijk verbeterde!
Performance Tests om de snelheidswinst aan te tonen
We besloten performance tests uit te voeren vanaf een Citrix XenApp machine door gebruik te maken van de volgende tool:
- IOMeter
Iometer is een tool die iets ingewikkelder is. Om deze goed te kunnen gebruiken heb ik de instellingen gebruikt zoals omschreven in onderstaand artikel:
https://www.hiveio.com/how-to-use-iometer-to-simulate-a-desktop-workload/
Meten middels de IOMeter tool leverde de volgende performance resultaten op:
Kijkende naar bovenstaande resultaten vielen de volgende zaken op:
- Waarom is de Write Latency en CPU belasting beide zo hoog?
- Waarom Is het aantal maximale I/Os per Seconden zo laag?
- Waarom Is het de max hoeveelheid MBs per Seconde zo laag?
Deze resultaten leken op waardes die normaal gemeten worden op omgevingen waar geen SSD’s worden ingezet! Om bovenstaande meting te toetsen hebben we deze vanuit dezelfde VM nogmaals getest onder andere omstandigheden zoals:
- vanaf VMware host met een Lokaal geconfigureerd SSD Raid 5 volume i.p.v. de HP MSA LUN
- op een avond moment zonder gebruikers waardoor de Storage volumes of VMware laag mogelijk belast zou worden
Uiteraard hebben we de metingen meerdere malen herhaald om te valideren of alle getallen om en nabij hetzelfde bleven. In alle gevallen bleven de waarden om en nabij hetzelfde.
Wat waren de resultaten na het omzetten van de disk van HDD naar SSD (Flash)?
Om te forceren dat de aangeboden storage als SSD (Flash) zou worden gebruikt hebben we de stappen in het volgende artikel gevolg waarmee de instellingen manueel omgezet kunnen worden:
https://kb.vmware.com/s/article/2013188
Na het uitvoeren van de nodige stappen en het herstarten van de VMware host gaf inderdaad VMWare nu aan dat het nu een SSD (Flash) gebaseerd volume betrof:
Na de aanpassing deden we de IOMeter meting opnieuw:
Wat ons opviel aan de nieuwe meting:
- Een ruim verdubbelde hoeveelheid I/Os per seconde
- Een ruim verdubbelde hoeveelheid MB’s per seconde
- Een gehalveerde Latency
- Met hogere load werd zelfs nog maar een kwart van de CPU belasting gebruikt t.o.v. vorige meting!
Kortom, een waanzinnige verbetering!
Bovenstaande aanpassing hebben we zowel op een Local RAID 5 SSD volume als op een Fibre aangesloten MSA 2040 getest, beiden gaven dezelfde verbetering!
Hoe kan dit?
Wanneer we zowel de Microsoft als de VMWare forums afspeuren vinden we niet erg veel informatie over dit onderwerp. Wel vonden wij, verstopt in een aantal verschillende artikelen de volgende vermeldingen waardoor dit gedrag zou kunnen worden verklaard:
https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.storage.doc_50%2FGUID-E461B938-0C74-4F9A-8862-05CFB43407A2.html
In dit artikel wordt het volgende vermeld:
Dit impliceert, dat het OS vanuit VMware krijgt aangedragen dat de aangeboden disk een HDD betreft en geen SSD. Hierdoor wordt vanuit het OS de schijf aangestuurd als HDD, waardoor de performance lager uit zal pakken.
Conclusie
Ondanks het feit dat de nieuwe Citrix Provisioning optie de “Cache to device RAM with overflow to disk” beschikbaar stelt waardoor het geheugen veel “Writes” afvangt, is het niet minder belangrijk om alsnog te kiezen voor een snelle disk configuratie waarop de WriteCache disks worden aangemaakt. Daarnaast is het erg belangrijk om te controleren dat gebruikte SSD’s ook daadwerkelijk gezien worden als SSD omdat anders de disks niet worden gebruikt als SSD, maar juist als HDD met alle daarbij behorende nadelen!
Wij hopen dat deze bevinding iemand verder zal helpen bij de al zo ingewikkelde performance optimalisatie wereld!
