Dedicated Terminal Server (RDS) Cluster op VMware

[BlakHawk]

We zijn bezig een apart ESXi 5.0 cluster in te richten voor onze TS / RDS omgeving.
Nu zijn de best practices bekend en moet je geen CPU overcommitment willen. Dat is perfect en gaan we dus ook niet doen.

Maar kunnen we hyper threading meerekenen?
Een ESX host heeft 2x een 10core CPU aan boord.

Logischerwijs betekent dit maximaal 10 terminal servers welke 2 cores hebben per host.

Maar door hyper threading heb je 40 cores beschikbaar... In hoeverre mag ik deze meerekenen?

[Equator]

Citrix zegt:


Volgens best practices uit het veld mag je het aantal cores x 1,3 doen wanneer je HTT gebruikt.
20 fysieke cores (40 logisch vanwege HTT) == max (20*1,3=) 26 vCPU's

Verdere best practices wijzen aan dat je met een virtuele TS het best 4 vCPU's toe kunt wijzen. Maar dat ligt toch vooral aan je gebruikte software. Dat houdt in dat je 26/4=6 virtuele servers kunt plaatsen op een fysieke host.

Ik zal nog even kijken of ik een linkje over die overcomitting kan vinden. Nope, kan het even niet zo snel vinden.

Dit is overigens ook een leuk topic, wel erg Citrix based overigens..
Voordelen Citrix XenApp (2k8 Session Host) virtualisatie?

[ Voor 34% gewijzigd door Equator op 28-08-2013 13:48 ]

[BlakHawk]

Equator schreef op woensdag 28 augustus 2013 @ 13:33:
Citrix zegt:
[afbeelding]

Volgens best practices uit het veld mag je het aantal cores x 1,3 doen wanneer je HTT gebruikt.
20 fysieke cores (40 logisch vanwege HTT) == max (20*1,3=) 26 vCPU's

Verdere best practices wijzen aan dat je met een virtuele TS het best 4 vCPU's toe kunt wijzen. Maar dat ligt toch vooral aan je gebruikte software. Dat houdt in dat je 26/4=6 virtuele servers kunt plaatsen op een fysieke host.

Ik zal nog even kijken of ik een linkje over die overcomitting kan vinden. Nope, kan het even niet zo snel vinden.

Dit is overigens ook een leuk topic, wel erg Citrix based overigens..
Voordelen Citrix XenApp (2k8 Session Host) virtualisatie?

Heb je daar bronnen voor?

[Equator]

Die was ik aan het zoeken

[Wim-Bart]

Ik reken heel simpel. Aantal cores = 4 aantal cpu's = 2, hyperthreading. Dan is het gewoon 4 Citrix VM's met 4 cores. Maar dat komt alleen uit meten=weten. Er zijn situaties waar dit niet goed werkt.

Wat in de praktijk ook zo is dat met 2 cores per VM er af en toe een "stall" optreed bij Internet Explorer applicaties welke veel Java hebben.

Maar uiteindelijk is het aantal cores in je ESX farm gelijk aan wat je uit deelt. Dus stel, je hebt 10 servers in je farm, 2 sockets per server, 4 cores+ht per socket dan heb je 16 cores per server x 10 = 160 cores. Met 12 GB per VM (meer dan zat) dan zit je op 160/4 = 40 VM's. Als er 1 host uit valt dan ben je wel overcommited op cores, maar merk je er weinig van. Alleen wel DRS niet te aggressief instellen. Daarnaast met 12 GB per VM en 4 VM's per server moet je denken aan 48 GB per ESX host + geheugen voor ESX zelf. In de praktijk moet je dat verdelen over 2 NUMA nodes en dan kom je op 26GB per socket. Daarnaast moet je rekening houden met dual/tripple/quad channel per CPU, met dual ga je dan voor 4x16GB, voor tripple ga je voor 12 x 8 GB en bij quad voor 8 x 8 GB. Dan zit je meestal wel save maar meer geheugen is altijd wel prettig.

[ Voor 71% gewijzigd door Wim-Bart op 03-09-2013 21:57 ]

[Question Mark]

Tja... uiteindelijk is het zwaar afhankelijk van het applicatiegebruik van de eindgebruikers.

Ik heb aardig wat RDS implementaties gedaan, en zonder inzage te hebben in hetgeen de eindgebruikers doen durf ik geen uitspraken te doen over de hardware die nodig is. Vaak stuur ik aan op het bouwen van een POC-omgeving en daar loadtesten op uit te voeren.

[KillerAce_NL]

RDS is de onderlaag van Citrix, dus wat dat betreft kun je hun best practices wel volgen.
Ik zou wel meteen met ESXI 5.1 beginnen, zit toch veel verbetering in.

Als je gaat opbouwen, begin dan met 1 op 1 cores toewijzen. Dit kun je door testen en door user-feedback dan later nog tunen naar iets meer overcommitment. Absoluut geen memory overcommit doen.

[Question Mark]

KillerAce_NL schreef op woensdag 04 september 2013 @ 08:45:
RDS is de onderlaag van Citrix, dus wat dat betreft kun je hun best practices wel volgen.

Qua cpu-(over)commitment wel, qua totale sizing zegt de tabel niet zoveel. Die blijft sterk afhankelijk van aantal users x userload per type gebruiker (bv. kiosk user vs knowledge user).

En verder zal nog rekening gehouden moeten worden met wat minder technische aspecten. Veel users op 1 fysieke host (hogere userdensity) is relatief goedkoper, maar de impact wanneer 1 host uitvalt is dan ook veel hoger. Ook dat zijn zaken die eigenlijk meegenomen moeten worden in een design.

[KillerAce_NL]

Yep, maar dat zijn meestal factoren die de organisatie beslist. Hoeveel verminderde capaciteit mag er zijn bij échte uitval.

[Question Mark]

Een hoge userdensity heeft niet alleen betrekking bij capaciteitvermindering tijdens uitval, (daar is gewoon rekening mee te houden in een design door het meenemen van overcapaciteit), maar meer over de impact.

Er zit gewoon een hoop verschil tussen een lage userdensity per systeem waarbij "slechts" 40 medewerkers uit hun sessie gegooid worden en hun nog niet opgeslagen werk allemaal kwijt zijn, of dat het om 300 medewerkers gaat.

Het gaat wat offtopic, maar het maken van een goed RDS-design heeft ook zeer veel te maken met verwachtingsmanagement.

[Wim-Bart]

Het gaat wat offtopic, maar het maken van een goed RDS-design heeft ook zeer veel te maken met verwachtingsmanagement.

En daarom is het "better safe then sorry". Maar hoewel je op een grote host zonder VMware, XenServer, Hyper-V lekker veel users kan hosten is virttualisatie toch beter. Wanneer een server plat gaat (een VM) is het beter dat 20 users werk kwijt zijn dan 100 users. In mijn ervaring is het meestal de Software welke het probleem is en niet de hardware.

[Question Mark]

Wim-Bart schreef op woensdag 04 september 2013 @ 15:48:
[...]
Maar hoewel je op een grote host zonder VMware, XenServer, Hyper-V lekker veel users kan hosten is virttualisatie toch beter.

Juist bij zwaar uitgevoerde fysieke systemen kan door gebruik van virtualisatie de userdensity verhoogd worden. RDS schaalt immers niet echt lineair op cpu-gebruik, waardoor het soms beter is om meerdere vm's in te zetten vanaf een host, in plaats van "bare metal" RDS aan te bieden.

Het zou juist mijn voorkeur zijn om RDS servers alleen om die reden al virtueel uit te voeren.

De TS zal alleen een overweging moeten maken hoeveel fysieke systemen ingezet moeten gaan worden. Al hoe klein de kans ook is, een fysiek probleem kan altijd gebeuren. En da's met 300 users vanaf 1 server aardig pijnlijker dan 50 users vanaf dat systeem (al dan niet gevirtualiseerd).

Meerdere kleinere fysieke systemen zijn vaak duurder in aanschaf en operationele kosten dan een handjevol zwaardere systemen, maar hebben toch wel degelijk voordelen op het gebied van userimpact bij uitval en loadverdeling. Dat zijn zaken die ik wel altijd heel duidelijk bespreek met een opdrachtgever, da's wat ik enkel even aan wilde geven.