A- A A+

Citrix, virtualiseren of niet

Regelmatig word ik bestookt met de vraag of je Citrix XenApp nu bare-metal of Virtueel moet implementeren. Een hele valide vraag in een tijd waar groen een deel uit maakt van het datacenter concept.

Persoonlijk gevoel

Virtualisatie heeft voor- en nadelen en persoonlijk ga ik liever voor een hardware gebaseerde Citrix omgeving. Echter wel wel bepaald door een aantal zaken waaronder:

  • Voldoende fysieke hosts. Niks ergers dat bij een hard- of software storing gelijk 50% van je gebruikers niet meer kan werken;
  • Gebrek aan shared storage;
  • De financiën om in snelle local storage te investeren;
  • Wel- of geen noodzaak tot site recovery op basis van VMware SRM of Hyper-V replicatie.

In theorie en afhankelijk van het applicatie profiel kan je met XenApp 6 en Roll-up Pack 2 op een Dual Socket 8 core (4 core's per socket) + hyperthreading en 32GB geheugen zonder problemen 80-120 users per host kwijt kunnen. In een omgeving met 4 hosts maximaal 480 users (afhankelijk van applicatie profiel). Wanneer 1 host door welke reden dan ook niet beschikbaar is, dan is er voldoende ruimte om op 3 hosts verder te draaien. Maar wel met 25%  minder performance.

Een andere probleem is dat bij bare-metal de load evaluator(s) dermate slim moeten zijn dat gebruikers verdeeld worden op basis van load en niet op basis van het aantal users. Bij grotere omgevingen loop je het risico dat de verhouding van users per host scheef gaan lopen. En dit schept een ander probleem, waardoor Virtualisatie helemaal zo gek nog niet is.

Het probleem met bare metal is dat je om risico te spreiden het aantal fysieke hosts moet vergroten om te voorkomen dat te veel gebruikers bij een storing hun sessie verliezen. 100 gebruikers in 1 keer weg is een nachtmerrie voor de helpdesk. Natuurlijk kun je dat voorkomen door hardware redundant uit te voeren met disk mirroring, maar zoals we allemaal weten, pagefile op een RAID 1 of RAID 5 is not done voor de performance. Maar een single disk is weer een risico. En is SSD een oplossing, zolang niet alle hardware raid-controllers TRIM ondersteunen, nog niet echt.

Wanneer je dus het risico gaat spreiden, dan kom je uit op getallen van 20-40 gebruikers per host, en dan zit je al snel bij 400 gebruikers op 10 fysieke hosts met 1 socket (4 core's + HT) en 24 GB geheugen. Een niet echt goed scenario.

In de praktijk

In de praktijk blijken de meeste problemen te ontstaan door software fouten, of processen (zoals IE8 en Java) welke een CPU-core opvreten. Daarnaast wil je het aantal gebruikers per XenApp server zo laag mogelijk houden. Citrix adviseert op ESX momenteel per 20 gebruikers 12GB geheugen met 4 sore's. Wat aangeeft dat je voor 400 gebruikers 20 virtuele machines nodig hebt en je bij 1.000 gebruikers op 50 machines uitkomt. Met deze kengetallen kom je uit op 200 sore's en 600GB geheugen.

Dus waarom geen Virtualisatie…….

Hiervoor is geen enkele reden. Virtualisatie maakt het allemaal eenvoudiger. Hardware uitval valt te voorkomen, software is een ander verhaal, daarom is met kleine machines de impact een stuk lager ook al bestaat de onderlaag uit grote machines. In het geval van 1.000 users kom je dan ook makkelijk weg met 15 hosts voorzien van voldoende geheugen en voldoende sore's. En het past allemaal in een mooi Blade enclosure.

Het enige waarmee je rekening moet houden is storage aan de achterkant. Waarbij een SAN met deduplicatie aanzienlijke besparingen kan opleveren.

Performance

De huidige stand van de technologie is totaal geen beperking meer, de hypervisors zijn dermate goed dat je XenApp zonder problemen en weinig overhead onder ESX en Hyper-V kan gebruiken. Je fysieke hosts hebben geen lokale disks nodig, een simpel SD-kaartje om je Hypervisor van te starten is voldoende en eventueel start je die ook vanaf het SAN (FC). De storage kan worden aangeboden via FC, iSCSI, NFS of SMB3 en is eveneens geen beperking meer. Het is een kwestie van slim bouwen met voldoende netwerk aansluitingen en een SAN/Netwerk infrastructuur welke is berekend op lage latency en hoge doorvoer.

En de voordelen binnen XenApp zelf. Deze zijn legio. Door virtualisatie ben je in staat om te werken met technologieën zoals HA en DRS. Valt een fysieke host uit, dan is je VM in no-time weer beschikbaar. Vraagt een VM veel processor resources, dan zal technologie zoals DRS er voor zorgen dat een VM meer ruimte krijgt door laag belaste VM's naar andere hosts te migreren zonder dat gebruikers er iets van merken.

Andere voordelen

Niets is eenvoudiger dan een nieuwe XenApp server uit te rollen vanuit een template, desnoods in combinatie met een product als Altiris, RES Automation Manager, BMC of Citrix Provisioning Server. 1 gouden image of installatie project bijhouden en je hebt in no-time een nieuwe farm staan. Handig voor site recovery of gewoon regulier patchen of de farm opschonen.

Wanneer je technologie gebruikt zoals ESX en Hyper-V kan je zonder noemenswaardige performance problemen je omgeving patchen. Je kan zelfs aan site recovery denken met producten zoals VMware SRM of Hyper-V replicatie.

Tips

Voor een succesvolle implementatie zijn hier een aantal handige tips:

  • Size je VM's op 20-25 gebruikers, 4 VCPU's en 12GB geheugen. Wanneer je een tool gebruikt zoals Edgesight, dan zie je dat dit meer dan voldoende is;
  • Stel DRS onder VMware niet te agressief in;
  • Deel nooit meer VCPU's uit per host, dus 2 sockets met 4 sore's + HT per socket is 16 VCPU's is 4 Virtuele machines per host.
  • Houdt rekening met NUMA op je host. Dus verdeel het geheugen gelijk over 2 sockets en zorg dat er ten minste 3 volledige VM's per NUMA node passen, dat komt neer op 36GB per socket. 72GB per host. Hierdoor is er voldoende speling voor de hypervisor;
  • Zorg ervoor dat je storage (in geval van NFS/iSCSI) niet over de zelfde interfaces loopt als je VM netwerkkaarten;
  • Splits OS. applicatie en pagefile disks in je VM. En zorg er voor dat je Pagefile disk niet op zelfde SAN volume staat als de andere disks.
  • Maak gebruik van Mandatory profiles in combinatie met bijvoorbeeld RES Workspace Manager Zero Profiling;
  • Gebruik geen local storage op je hypervisor alleen voor de hypervisor zelf;
  • Gebruik 2 data collectors en biedt hier geen sessies op aan, laat ze gewoon datacollector, metrisch server, xmlservice zijn;
  • Gebruik separate WI's en laat deze wijzen naar de 2 datacollectors.

Je data collectors kunnen kleine VM's zijn, 2 VCPU's en 4GB is voldoende. In een 1.000 user scenario zal je dan een 16 host cluster nodig hebben, waardoor je bij maintenance of hardware uitval voldoende speling hebt om zonder performanceverlies je farm live te houden.