2 X ESX Server Voor Terminal Server 2008R2

[Peter F]

Hallo.

Wij willen het serverpark gaan uitbreiden met 2 ESX hosten die dedicated Terminal Server gaan draaien.
De huidige omgeving 3 X Dell Servers worden op dit moment al aardig belast en hier zal binnenkort nog een ECD pakket op komen te draaien waardoor het voor de 7 Terminal servers waarschijnlijk te krap gaat worden. High availibility zal dan sowieso niet meer gaan werken.


Het moet aan de volgende wensen voldoen

Voor users tot 140 gebruikers (deze 140 zal waarschijnlijk nooit gehaald worden)
Standaard wordt er alleen gebruik gemaakt van Office, internet, impromptu (moet rapporten genereren wordt af en toe gebruikt door enkele users en anti virus)

Ik wil de volgende configuratie op gaan bouwen

Per Server

4 Terminal servers 6 GB geheugen (1 web applicatie is niet echt zuinig met geheugen gebruik mede door Java)

Ik zat aan de volgende configuratie te denken.


2 X

HP DL360 G8 : Intel E5-2620 6C 2.00GHz (standaard 8gb)
Extra proc DL360pR8 6C 2.00GHz 8GB
16 extra Geheugen
extra voeding
quad network card.
Sd kaart om van vmware te booten.

Storage wordt overigens aangestuurd via een Equallogic 4000 serie met 15K Schijven.

Software

VS5-ESSL-BUN-C
2 X Server 2012 Standaard (per server)

Zou dit afdoende zijn of te krap.

Ik hoor graag jullie feedback.

[CMD-Snake]

In mijn ervaring is bij een terminal server het geheugen vaak de bottleneck voor goede prestaties. Reken dat je bij 6Gb toewijzen aan Windows 2Gb daarvan verbruikt zal worden door Windows processen, naarmate er meer gebruikers inloggen zal Windows nog meer processen dubbel moeten draaien voor elke user. Tel daar dan een applicatie bij op die geheugen op slokt en je 6Gb zit dan heel snel vol.

Ik zou meer geheugen bestellen in je nieuwe servers. Ergens zou ik zeggen doe maar rustig 32Gb per host. Misschien nog wel meer als je het budget hebt. Dan heb je ook nog ruimte over om te groeien.

[Razwer]

Met 2x cpu in elke server kan je idd prima naar 32gb gaan per server. Ik zou alleen niet virtualiseren en lekker fysiek draaien.
Je storage is niet om over naar huis te schrijven (2x gbe per controller), ik zou lekker local storage doen desnoods met nearline schijven. Wel met BBWC module op de array controller overigens. In een ver verleden heb ik nog eens met zo'n kist gespeeld en het performde vele malen minder dan local storage.
Waarom wil je zo graag virtualiseren?

Als je overigens je connection broker load HA wilt hebben, houd er wel rekening mee dat je ergens een SQL instance moet gebruiken. Dit raad ik je overigens wel aan (er vanuit gaande dat je 2012 gebruikt, in je topic titel zeg je 2008R2, in je text zeg je 2012, verwarrend).

(mijn) vuistregels voor virtuele TS-en:
max 30 users, max 16gb (default 8gb) en 4x virtual cpu.

voor physicals kun je gaan tot max 50 users (wanneer er 8 cores en 32gb aan boord is of meer bij zwaardere apps) en physicals performen over het algemeen stukken beter dan virtuals, helemaal wanneer je SAN storage gebruikt...

BBWC op de array controller maakt overigens groot (lees:gigantisch) verschil wanneer je local storage aanroept.

[ Voor 73% gewijzigd door Razwer op 23-02-2014 13:23 ]

[Peter F]

Bedankt voor jullie reacite

Ik begrijp van jullie dus 8 GB per VM is een vereiste. Op het totaal plaatje kan dit wel ipv 24. Er zal dan wel 4 X 8 bij komen + de 8 die er al in zit kom ik op 40 GB

Wat betreft de san, . 2 GB per controller, klopt, maar wat zou een gebruiker verbruiken op terminal server. een docu openen of word / excel openen. DE storage zou met de huidige config tussen de 3000 en 4000 iops moeten kunnen genereren (8 x 900 GB 15 K), Lijkt me ruim zat aangezien de iops nu tussen de 1500 en 2000 zitten.

De verwarring met Server 2012 is genoemd vanwege de licentie. Server 2008r2 enterprise is niet meer te koop (geldig voor 4 vms ) dus moet je naar 2012 Standaard (per 2 proc en 2 vms).

Overigens fysiek wordt lastig. 50 users per server, dan kom ik uit op totaal 100 gebruikers.
Nu heb ik gemiddeld over 8 terminal servers 17,5 users op volledig gebruik en bij uitval van een 20 gebruikers.

Ik weet iig genoeg en kan hier verder mee aan de slag.

dank

[redfoxert]

Vergis je niet te snel in het aantal IOps ... Een 15K disk haalt ongeveer 150 IOps, maal 8 dan zit je al dik aan de max met je 1500-2000 die je nu haalt.

[Dennism]

Houd je wel rekening met vMotion (als je het gaat gebruiken) en de Windows licenties, uit eerdere projecten weet ik dat daar wat nare haken en ogen aan kunnen zitten (volgens mij dubbele licenties per node, of afkopen met datacenter licenties).

If you want to use HA (clustering), Live Migration/vMotion, DRS/Dynamic Optimization/PRO, then you need sufficient virtualisation rights on each host to support the maximum number of VMs that is possible on that host, even for 1 second.

[Peter F]

Dennism schreef op zondag 23 februari 2014 @ 18:00:
Houd je wel rekening met vMotion (als je het gaat gebruiken) en de Windows licenties, uit eerdere projecten weet ik dat daar wat nare haken en ogen aan kunnen zitten (volgens mij dubbele licenties per node, of afkopen met datacenter licenties).


[...]

Daarom doe ik licentie technisch het volgende

per server 2 X 2012 Server Standard

En voor vmware pak ik gewoon de goedkoopste. Ik hoef geen gebruik te maken van vmotion op deze servers.
Mocht er een kapot gaan kan ik de vms toch niet op de andere kwijt (licentie technisch en qua geheugen) Ik kan hoogstens een of twee vms tijdelijk op de andere omgeving starten, even mounten met de hand of standby laten staan. .(3 x esx met vcenter en datacenter voor de MS licenties) dat is ook het voordeel als je de vms op een san hebt staan.

[Verwijderd]

Peter F schreef op zondag 23 februari 2014 @ 17:40:
Overigens fysiek wordt lastig. 50 users per server, dan kom ik uit op totaal 100 gebruikers.
Nu heb ik gemiddeld over 8 terminal servers 17,5 users op volledig gebruik en bij uitval van een 20 gebruikers.

Denk je dat je met virtualiseren meer power uit dezelfde server kan persen? Lijkt mij van niet. Lekker fysiek draaien die servers en local storage gebruiken. Spaart je nog eens licentie kosten uit ook.

[Question Mark]

Verwijderd schreef op zondag 23 februari 2014 @ 23:59:
[...]

Denk je dat je met virtualiseren meer power uit dezelfde server kan persen? Lijkt mij van niet. Lekker fysiek draaien die servers en local storage gebruiken.

Hou wel rekening met de (CPU)-schaalbaarheid van RDS. van 1 naar 2 CPU's levert een enorme performance winst op, van 2 naar 4 al veel minder, en van 4 naar 8 minimaal.

Je userdensity bij RDS omgevingen is dan ook vaak hoger bij meerdere kleinere virtuele servers (met 2 cpu's) op één fysiek systeem, dan installatie op één grote fysieke server.

[webspider0]

Mocht je gebruik gaan maken van virtualisatie maak geen gebruik van vmotion op een terminal server omgeving. Servers gaan de hele dag staan migreren omdat een gebruiker even een applicatie opend en dus wat meer vracht van de machine. Dit komt je preformance niet ten goeden.

Klinkt leuk voor loadbalnacing maar op een TS omgeving zeker niet gebruiken.

[Dennism]

webspider0 schreef op dinsdag 04 maart 2014 @ 20:42:
Mocht je gebruik gaan maken van virtualisatie maak geen gebruik van vmotion op een terminal server omgeving. Servers gaan de hele dag staan migreren omdat een gebruiker even een applicatie opend en dus wat meer vracht van de machine. Dit komt je preformance niet ten goeden.

Klinkt leuk voor loadbalnacing maar op een TS omgeving zeker niet gebruiken.

Bedoel je hier niet DRS i.c.m. Vmotion?
Met enkel Vmotion heb ik nog nooit een server uit zichzelf zien migreren tenzij er een probleem was op de node waar de server op draaide ten tijde van het probleem.

[Question Mark]

Ligt ook puur aan je instellingen. Voor DRS zijn binnen VSphere tresholds in te stellen die bepalen hoe "snel" een VM mag gaan migreren naar een andere host.

Verder is het natuurlijk altijd aan te raden om je loadbalancing voor Terminal Server "resource based" te gaan doen. Daarmee zorgt je loadbalancing algoritme dat de load per Terminal Server zoveel mogelijk gelijk is.

[webspider0]

Dennism schreef op woensdag 05 maart 2014 @ 09:05:
[...]


Bedoel je hier niet DRS i.c.m. Vmotion?
Met enkel Vmotion heb ik nog nooit een server uit zichzelf zien migreren tenzij er een probleem was op de node waar de server op draaide ten tijde van het probleem.

Excuses je hebt helemaal gelijk.

Daarnaast ben ik het niet eens met Mark. Het geef meer problemen dat profijt. Klinkt als het goude ei om je resources goed te verdelen maar absoluut geen best practice.

[Question Mark]

webspider0 schreef op woensdag 05 maart 2014 @ 12:33:
[...]
Het geef meer problemen dat profijt. Klinkt als het goude ei om je resources goed te verdelen maar absoluut geen best practice.

Ik zeg ook nergens dat je het wel of niet moet doen, het enige wat ik aangeef is dat de mate waarin VMotion optreed beinvloedbaar is. Voor een cluster met systemen waarvan bekend is dat er veel korte performance-pieken ontstaan zet ik de DRS rules altijd behoorlijk conservatief. Ik herken de problemen die jij schetst dan ook eigenlijk niet. Op het moment dat DRS continue ingrijpt gaat er iets niet goed, dat zijn we wel roerend eens. De oplossing die ik dan altijd gebruik is om DRS wat conservatiever in te stellen, en deze niet compleet te disablen.

Overigens, volgens VMWare is het wel degelijk een best practice. Maar ja, wij van wc-eend...

Citrix XenApp on VMware Best Practices Guide

Using vMotion, XenApp virtual machines can be migrated from a heavily loaded server to one that islightly loaded. Migrations using vMotion can be initiated on demand, or automated using DRS.VMware DRS takes the VMware vMotion capability a step further by adding an intelligent resource scheduler. DRS enables you to set resource assignment policies that reflect business needs. VMware DRS does the calculations and automatically handles the details of physical resource assignments. Itdynamically monitors the workload of the running virtual machines and the resource utilization of the physical servers within a cluster. When workloads become unbalanced DRS can migrate virtual machines to hosts with additional capacity using vMotion

[Paul]

Geen vMotion nodig / mogelijk? Dan kun je aan je eisen te zien ook vooruit met vShpere Hypervisor (gratis). Het enige wat je met de Essentials-kit koopt is de mogelijkheid te scripten (writable) en integratie met vCenter, geen features!

Verder zou ik inderdaad per TS 8 of 12 GB ram inzetten, RAM is cheap, veel goedkopere snelheidsupgrades zijn er niet. 4x12 GB en een beetje voor de hypervisor, oftewel 64 GB ram er in.

Met deze processoren zou je inderdaad 4 vCPU's kunnen nemen, maar met goedkopere E5-1609's heb je meer MHZ ten koste van 2 cores. Als je dan 2 vCPU's instelt ben je nog niet overcommitted (al is dat voor CPU totaal niet erg, zolang je, in geval van multi-processor VM's, je CPUREADY maar in de gaten houdt) en opschalen naar 4 kan altijd nog.

Zonder vMotion kun je ook met local storage vooruit voor de VM's zelf, het zijn terminal servers, dus hoe groot zijn die? 50 GB? 80 GB? Een paar 739888-B21 (300 GB SSD) kost je samen 1600 euro list price (dus eerder 1000 bij je leverancier) maar offload wel je SAN. Op een PS4000XV (Google geeft een list price van 39k) kost 300 GB ook 1.7k (als ik RAID 6 neem, met RAID 10 is dat 2x zo duur) en dan heb ik het nog niet over IOPS gehad.

[webspider0]

Question Mark schreef op woensdag 05 maart 2014 @ 12:59:
[...]
Overigens, volgens VMWare is het wel degelijk een best practice. Maar ja, wij van wc-eend...

Citrix XenApp on VMware Best Practices Guide

[...]

Klopt maar ik heb nu meerdere consultants uit het veld over de vloer gehad die allemaal het zelfde melden. Daarbij raden ze ook vooral lokaal storage aan. Dus is meteen je vMotion onmogelijk dus is het geheel al weer niet relevant.

We hebben dan ook 2 esx clusters. 1 cluster voor alleen de citrix farm waar alle HA en DRS op uitgeschakkeld is. Lokaal storage om zo het SAN niet te hoeven belasten. En vmware standaard geinstalleerd omdat meer niet nodig is.
En een 2de cluster dat alle toeters en bellen aan heeft staan. HP lefthands er aan als storage en vmware enterprice.

[Question Mark]

De enige toevoeging die ik nog heb is dat het per klant verschillend kan zijn. Technische oplossingen zijn afhankelijk van gestelde requirements en de aanwezige infrastructuur, en ik moet de eerste twee klanten nog tegenkomen waarbij dat gelijk is...

En verder zijn het absoluut terechte punten die je aanhaald hoor.

[webspider0]

Question Mark schreef op woensdag 05 maart 2014 @ 13:40:
De enige toevoeging die ik nog heb is dat het een per klant verschillend kan zijn. Technische oplossingen zijn afhankelijk van gestelde requirements en de aanwezige infrastructuur, en ik moet de eerste twee klanten nog tegenkomen waarbij dat gelijk is...
[...]

Daar heb je ook zeker een goed punt