Aantal Terminal Servers

[Tsurany]

Bezig met een stage project waar we moeten kijken naar de mogelijkheid tot desktop virtualisatie (TS en VDI) icm (E)SSO en Thin Clients. Bedoeling is het opstellen van een business case voor de IT raad en globaal een budget aangeven.

Waar we nu tegenaan lopen is het aantal gebruikers dat we per TS kwijt kunnen. We zullen hoogstwaarschijnlijk geen 64bit server kunnen gebruiken door flink wat 'exotische' applicaties. Dat betekent dus dat er 32bit servers gebruikt worden. Het idee was servers te nemen met 4xquadcore cpu's. Dit is aanzienlijk goedkoper dan twee keer zoveel servers met 2xquadcore cpu's of servers met 2xquadcore processoren. Qua geheugen zal het 4GB per virtuele server worden (gezien 32bit).

Volgens Virtual Reality Check Phase II zit je met 4 virtuele machines met elk 4 cores per server goed aangezien je dan volgens hun tests net iets minder gebruikers kwijt kan dan op 8 virtuele machines met elk 2 cores maar zo wel maar een licentie kwijt ben (1x server 2008 en dan 4x server 2008 virtueel onder dezelfde licentie). Het is momenteel nog niet mogelijk het te gaan testen doordat er geen servers 'over' zijn en deze business case de basis is om te bepalen of desktop virtualisatie uberhaupt wel aantrekkelijk is.
Wel weten we ongeveer wat voor programma's gebruikt zullen worden. Het zal gaan om office programmas (2007 of 2010), internet gebruik (geen youtube en dergelijken) en programma's zoals SAP en DCC voor clientgegevens.

Na veel informatie zoeken komen we uit op aardig overeenkomende getallen.
Remote Desktop Session Host Capacity Planning in Windows Server 2008 R2 heeft het over zo'n 150 gebruikers met een 4 CPU dual core machine.
Achieving Business Value through Microsoft VDI Together with Session Virtualization heeft het over zo'n 25 gebruikers per core tegenover 4-7 met VDI.
Daarnaast worden op veel sites en fora gesproken over zo'n 20-40 gebruikers per core.

Wij denken dus dat we met 4xquadcore cpu servers zo'n 300 gebruikers kunnen faciliteren. Is dit een correcte schatting?


Daarnaast moeten we achterhalen hoeveel gebruikers er tegelijkertijd zijn ingelogd. We kunnen hiervoor niet bij systeembeheer of netwerkbeheer terecht, die kunnen het ons niet vertellen. Wel kunnen we kijken hoeveel gebruikers tegelijkertijd in SAP en DCC zitten maar dat zal natuurlijk niet iedereen zijn. Iemand een suggestie hoe we dit kunnen achterhalen? Mensen loggen in op hun eigen desktop pc (wel AD).

[Remco]

Je zou eens kunnen kijken op de Citrix website. Ik heb daar laatst een artikel gelezen over de vraag wel of niet te virtualiseren. Daarin stond een behoorlijk uitgebreide berekening over het aantal concurrent users die in kunnen loggen op een Terminal Server.

[serkoon]

Met 4GB geheugen per systeem zul je denk ik vrij weinig gebruikers aan kunnen.

Op 32-bits machines kun je gelukkig prima meer dan 4GB gebruiken (met PAE, Physical Address Extension), al is het alsnog vanwege performance slimmer om 64-bits machines te gebruiken.

[Bl@ckbird]

Wat Validated Design Guides die ik zo kon vinden...

VMWare View i.s.m. Cisco UCS en EMC Storage:
http://www.cisco.com/en/U..._Networking/vdiucswp.html
http://www.cisco.com/en/U...are/cisco_VMwareView.html

Citrix XenDesktop i.s.m. Cisco UCS en NetApp Storage:
http://www.cisco.com/en/U...ucs_xd_xenserver_ntap.pdf

Cisco UCS-Blades zijn standaard x86 hardware,
dus dan kan je het een beetje vergelijken met andere server hardware.
http://www.cisco.com/en/U...cts_data_sheets_list.html

[Tsurany]

Heel erg bedankt, die zal ik morgen goed doornemen!

[DukeBox]

Overigens draait de 32bits software vrijwel altijd op een 64bits os. Alleen met drivers voor exotische hardware (dongles e.d.) kan je een probleem hebben.

[Tsurany]

We zijn op dit moment een inventarisatie van alle software aan het uitvoeren, gaat om zeker 100 programma's waarvan een flink aantal zo specialistisch zijn dat er eigenlijk geen alternatieven voor zijn. Al die programma's moeten in een 64bit omgeving kunnen draaien.

64bit zou natuurlijk het mooist zijn, dan draai je gewoon bare metal en prop je het vol met geheugen tot gebruikers happy zijn.

[ Voor 19% gewijzigd door Tsurany op 22-09-2010 22:29 ]

[jvanhambelgium]

serkoon schreef op woensdag 22 september 2010 @ 15:46:
Met 4GB geheugen per systeem zul je denk ik vrij weinig gebruikers aan kunnen.

Op 32-bits machines kun je gelukkig prima meer dan 4GB gebruiken (met PAE, Physical Address Extension), al is het alsnog vanwege performance slimmer om 64-bits machines te gebruiken.

Limiet zit ook binnen de Windows Server omgeving. Indien je met een "32bit" windows effectief meer als 4GB wenst te gebruiken moet je 1 van volgende aanschaffen :

Windows Server 2003 Enterprise Edition (SP1) -> 16 GB with 4GT N/A
Windows Server 2003 R2 Enterprise Edition -> 64GB
Windows Server 2003 R2 Datacenter 128GB
Windows Server 2003 Datacenter Edition (SP1) 16 GB with 4GT
Windows Server 2008 Enterprise, Datacenter 64GB


...dus met een gewone "Windows 2003 Server Standard Edition" ga je er ni komen. En sommige van die licenties kosten een hoop centen...


Wij hanteren op 1 x QuadCore machine met 4GB RAM / Windows 2003 / oudere XenApp maximaal zo'n 30 gebruikers denk ik en onze statistieken wijzen uit dat voor de applicaties die de klant gebruikt die toch wel genoeg is.

Zijn nu bezig met de 64bit validatie om dan inderdaad beter te kunnen schalen (vb 32GB per machine)

[Tsurany]

We zaten de denken aan Windos Server 2008 Enterprise. Hoe werkt extra geheugen met PAE in de praktijk? Want je zit alsnog aan de 2GB kernel limiet, dus zorgt het daadwerkelijk voor meer gebruikerers? Ik kan me voorstellen dat we 8 of 16GB per VM toewijzen en dat we dan zo'n 80 gebruikers per VM faciliteren, kom je dan in de praktijk snel aan de 2GB kernel limiet?

[ Voor 29% gewijzigd door Tsurany op 23-09-2010 08:53 ]

[Verwijderd]

Zijn de 'exotische' applicaties desktopapplicaties of kunnen deze vanaf een cetrale plek draaien? Indien ze vanaf een centrale plek kunnen draaien zou je kunnen denken aan een 32bits VM op een 64bits host.

Persoonlijk zou ik toch echt zo veel mogelijk kijken naar een 64bits OS als Terminal server. Je loopt uiteindelijk toch tegen de 4GB geheugenlimiet aan van x86 en daar ben je al snel helemaal door heen. Geheugen is voor een TS omgeving (standaard kantooromgveing) vele malen belangrijker dan cpu capaciteit.

Ik heb het niet meegemaakt dat ik 4 quadcores nodig had om 4GB geheugen te verbruiken. De laatste TS farm die ik uitrolde had zelfs maar 1 quadcore met 16GB geheugen per server.

Overigens @jvanhambelgium: je gaat toch niet met droge ogen beweren dat je nu nog een 2003 TS omgeving gaat uitrollen? Enige optie lijkt me WS2008 (R2) met of zonder citrix sausje. Of als je de kennis in huis hebt een xenserver.

[ Voor 13% gewijzigd door Verwijderd op 23-09-2010 09:26 ]

[Jiriki]

Reken voor desktop virtualisatie ongeveer 3-4 gebruikers per core en 1-2 GB geheugen per gebruiker, iets minder eisen voor applicatie virtualisatie. Als je dan met 32 bit zou willen werken, virtualiseer dan de boel en werk zo, dat gaat een stuk beter.

Met Windows Datacenter edition kun je dan meerdere Windows servers op dezelfde machine draaien binnen een Windows licentie dus daar zitten de kosten dan niet.

Met 16 cores per machine gaat het dan om 45-60 gebruikers, 45-60 GB geheugen dus ook dus dan zou je ook weer 11-16 virtuele machines moeten kunnen draaien op de server, kan lastig zijn met de schijven maar heb je een SAN hiervoor?

Mijn advies zou toch zijn om 64 bit Windows te gaan gebruiken, dat maakt het beheer wel gemakkelijker. Of virtualiseer de desktops, dan heb je met Windows server een stuk minder te maken.

[jvanhambelgium]

Tsurany schreef op donderdag 23 september 2010 @ 08:44:
We zaten de denken aan Windos Server 2008 Enterprise. Hoe werkt extra geheugen met PAE in de praktijk? Want je zit alsnog aan de 2GB kernel limiet, dus zorgt het daadwerkelijk voor meer gebruikerers? Ik kan me voorstellen dat we 8 of 16GB per VM toewijzen en dat we dan zo'n 80 gebruikers per VM faciliteren, kom je dan in de praktijk snel aan de 2GB kernel limiet?

Je blijft inderdaad zitten met de 2GB kernel limiet (in deze kernel-space zitten ook page pool/non-paged pool/system-page-table-entries/system-cache)

Met de PAE kernel kan je op andere vlakken inderdaad meer geheugen alloceren.

Als je meer RAM wilt gebruiken, zal de system-page-table-entry allocatie groeien, en dan hou je ook minder over voor de paged-pool/non-paged-pool en system-cache.

De kans bestaat dat je zeer zeker meer gebruikers zal kunnen hebben, doch je licentie van het OS zal een stuk duurder zijn ! Voor terminal-servers gebruikt men dikwijls gewoon een "Standard Edition" versietje.
De vraag is maar op welk moment je zult bottlenecken met je kernel-mem-allocatie !
Ook is het allemaal iets meer tweaken & tunen en sommige omgevingen gebruiken liever redelijk standard configs.

...ook opletten met drivers natuurlijk aangezien die niet altijd goed kunnen omgaan met de > 4GB adres-space.Sommige spreken dit direct aan.

[Tsurany]

Verwijderd schreef op donderdag 23 september 2010 @ 09:21:
Zijn de 'exotische' applicaties desktopapplicaties of kunnen deze vanaf een cetrale plek draaien? Indien ze vanaf een centrale plek kunnen draaien zou je kunnen denken aan een 32bits VM op een 64bits host.

Zijn desktopapplicaties met een centrale database.

Persoonlijk zou ik toch echt zo veel mogelijk kijken naar een 64bits OS als Terminal server. Je loopt uiteindelijk toch tegen de 4GB geheugenlimiet aan van x86 en daar ben je al snel helemaal door heen. Geheugen is voor een TS omgeving (standaard kantooromgveing) vele malen belangrijker dan cpu capaciteit.

En dat zullen we ook zeker gaan doen, daar gaat de voorkeur ook zeker naar uit. Echter mocht blijken dat niet alle applicaties met 64bit overweg kunnen en we geen alternatieve applicaties hebben dan zullen we toch moeten uitwijken naar 32bit en daar moet wel een scenario voor klaar liggen.

Ik heb het niet meegemaakt dat ik 4 quadcores nodig had om 4GB geheugen te verbruiken. De laatste TS farm die ik uitrolde had zelfs maar 1 quadcore met 16GB geheugen per server.

Ik zat te denken aan meer VM's te plaatsen dan, dan 8VM's met 2 cores, echter ben je dan wel het dubbele kwijt aan licenties.

Jiriki schreef op donderdag 23 september 2010 @ 09:30:
Reken voor desktop virtualisatie ongeveer 3-4 gebruikers per core en 1-2 GB geheugen per gebruiker, iets minder eisen voor applicatie virtualisatie. Als je dan met 32 bit zou willen werken, virtualiseer dan de boel en werk zo, dat gaat een stuk beter.

Dat gaat op voor VDI, dan is het OS wel 32bit maar draai je meerdere VM's van elk zo'n 1,5GB geheugen.

Met Windows Datacenter edition kun je dan meerdere Windows servers op dezelfde machine draaien binnen een Windows licentie dus daar zitten de kosten dan niet.

Echter volgens mij gaat de datacenter edition per CPU? Dan kom je op een hoger bedrag uit dan wanneer je met twee enterprise editions zou werken, dan heb je 8 VM's per server, dus 8VM's met 2 cores en 4GB ram.

Met 16 cores per machine gaat het dan om 45-60 gebruikers, 45-60 GB geheugen dus ook dus dan zou je ook weer 11-16 virtuele machines moeten kunnen draaien op de server, kan lastig zijn met de schijven maar heb je een SAN hiervoor?

Elke VM heeft slechts 1,5GB geheugen, dat het totaal 45-60GB geheugen gebruikt is dan toch geen probleem? Met VDI zal er sowieso een SAN komen lijkt me, daar is geen ontkomen aan. Zeker als je failover wilt en load balancing.

Mijn advies zou toch zijn om 64 bit Windows te gaan gebruiken, dat maakt het beheer wel gemakkelijker. Of virtualiseer de desktops, dan heb je met Windows server een stuk minder te maken.

Dat zou mijn advies ook zijn en als het in de praktijk haalbaar is dan is dat perfect. Echter mocht 64bit niet haalbaar zijn dan moet er dus wel een alternatief scenario liggen. En de keuze tussen VDI en TS zal niet door ons gemaakt worden, wij beschrijven beide scenario's en doen een aanbeveling op basis van kosten en beheersgemak.

jvanhambelgium schreef op donderdag 23 september 2010 @ 09:32:
[...]
Je blijft inderdaad zitten met de 2GB kernel limiet (in deze kernel-space zitten ook page pool/non-paged pool/system-page-table-entries/system-cache)

Met de PAE kernel kan je op andere vlakken inderdaad meer geheugen alloceren.

Als je meer RAM wilt gebruiken, zal de system-page-table-entry allocatie groeien, en dan hou je ook minder over voor de paged-pool/non-paged-pool en system-cache.

De kans bestaat dat je zeer zeker meer gebruikers zal kunnen hebben,

Enig idee aan hoeveel meer gebruikers ik zou moeten denken? Een alternatief is namelijk meer VM's op zetten als dat prijstechnisch voordeliger is.

doch je licentie van het OS zal een stuk duurder zijn ! Voor terminal-servers gebruikt men dikwijls gewoon een "Standard Edition" versietje.

Waarom geen enterprise edition? We zullen met 32bit sowieso meerdere VM's op moeten zetten dus dan is een enterprise edition toch voordeliger omdat je dan gelijk voor 4 VM's licenties hebt?

De vraag is maar op welk moment je zult bottlenecken met je kernel-mem-allocatie !
Ook is het allemaal iets meer tweaken & tunen en sommige omgevingen gebruiken liever redelijk standard configs.

Is er een mogelijkheid dit te beredeneren of kan je hier enkel achter komen door middel van testen?

...ook opletten met drivers natuurlijk aangezien die niet altijd goed kunnen omgaan met de > 4GB adres-space.Sommige spreken dit direct aan.

Het zal dan uitgebreid getest moeten gaan worden, maar een test traject zal er sowieso komen natuurlijk.


Wat natuurlijk ook zeker een mogelijkheid blijft is een 64bit terminal server waar we zoveel mogelijk gebruikers op kwijt kunnen, vooral administratie en dergelijken. De rest van het personneel zal dan gebruik maken van een VDI omgeving. Een goede connection broker zorgt dat iedereen toch op zijn plek terecht komt.

[ Voor 4% gewijzigd door Tsurany op 23-09-2010 10:00 ]

[Vicarious]

Je kan toch gewoon een 64-bits server kopen en daar virtueel 32-bits OS-en als guest machines op zetten? Dan kun je er zoveel geheugen in proppen als je wilt, maar moet je het alleen opsplitsen in meerdere virtuele terminal servers.

[Tsurany]

Dat is idd ook de bedoeling in het geval van VDI en met TS kan dat ook, alleen je kan niet oneindig TS's opzetten zonder dat het veel meer licentie gelden gaat kosten.

[Question Mark]

Tsurany schreef op woensdag 22 september 2010 @ 14:58:
We zullen hoogstwaarschijnlijk geen 64bit server kunnen gebruiken door flink wat 'exotische' applicaties.

Ik denk dat het voor je sizing en dus voor je businesscase van belang is om dit zeker te weten. Hier valt of staat nl. je hele case mee.

Waarom maak je geen design voor een 64 bits farm, en laat je applicaties die hier niet mee overweg kunnen vanaf een 32 bits silo komen? Dat is zo'n beetje de standaard oplossing voor deze problematiek.

[Tsurany]

Question Mark schreef op donderdag 23 september 2010 @ 10:36:
[...]
Ik denk dat het voor je sizing en dus voor je businesscase van belang is om dit zeker te weten. Hier valt of staat nl. je hele case mee.

Dat weet ik, we zijn nu met de meest critische applicaties bezig te ondervragen bij de verschillende applicatiebeheerders of de leveranciers met welke besturingssystemen ze overweg kunnen en of ze met 64bit systemen overweg kunnen.

Waarom maak je geen design voor een 64 bits farm, en laat je applicaties die hier niet mee overweg kunnen vanaf een 32 bits silo komen? Dat is zo'n beetje de standaard oplossing voor deze problematiek.

Ik ben even aan het kijken naar hoe dit precies in elkaar steekt, App-V en XenApp leken ook wel handig om dit voor elkaar te krijgen.

[Bl@ckbird]

Tsurany schreef op donderdag 23 september 2010 @ 10:26:
Dat is idd ook de bedoeling in het geval van VDI en met TS kan dat ook, alleen je kan niet oneindig TS's opzetten zonder dat het veel meer licentie gelden gaat kosten.

Cisco heeft blade servers en Rack mounted server met Memory Extention.
Een C460 kan 4 Xeon 7500 CPU's aan, waardoor je max 32 Cores per systeem hebt.
Maximale memory is 512 GB per systeem.

Een C250 kan 2 Xeon 5600 CPU's aan, waardoor je max 12 Cores per systeem hebt.
Maximale memory is 384 GB per systeem.

Omdat je veel DIMM sloten heb, kan je veel repen goedkoop geheugen gebruiken, of
je kan gewoon veel memory plaatsen voor VDI-achtige zaken.

De C250 heeft maar 2 fysieke processoren, wat scheelt in je software licenties.
( Die vaak per CPU worden afgesloten en niet per Core. )

[Question Mark]

Wat je dan eigenlijk doet is gebruikers laten werken vanaf een 64 bits omgeving (64 bits is veel memory en een hoge userdensity). De paar rottige applicatie installeer je op 32 bits systemen en "publish" je naar je gebruikers toe.

Let even op dat App-v en Xenapp verschillende zaken zijn. Xenapp is Citrix's aanvulling op Microsoft Terminal Services met enkele voordelen. App-v is een applicatievirtualisatietechniek (waarvan Xenapp overigens vergelijkbare functionaltiteit aanbied). App-v is tegenwoordig onderdeel van de RDS-call (dus gratis voor terminal server gebruikers), voor de VDI-werkplekken moet je deze volgens mij nog wel los aanschaffen (onderdeel van MDOP).

Bl@ckbird schreef op donderdag 23 september 2010 @ 13:13:
[...]
Cisco heeft blade servers en Rack mounted server met Memory Extention.

Intressant, maar weet je ook welke impact dit heeft op je geheugensnelheid. Juist met VDI-achtige zaken heb je veel voordeel van snelle IO.

[ Voor 19% gewijzigd door Question Mark op 23-09-2010 13:17 ]

[Tsurany]

Bl@ckbird schreef op donderdag 23 september 2010 @ 13:13:
[...]
Cisco heeft blade servers en Rack mounted server met Memory Extention.
Een C460 kan 4 Xeon 7500 CPU's aan, waardoor je max 32 Cores per systeem hebt.
Maximale memory is 512 GB per systeem.

Een C250 kan 2 Xeon 5600 CPU's aan, waardoor je max 12 Cores per systeem hebt.
Maximale memory is 384 GB per systeem.

Omdat je veel DIMM sloten heb, kan je veel repen goedkoop geheugen gebruiken, of
je kan gewoon veel memory plaatsen voor VDI-achtige zaken.

De C250 heeft maar 2 fysieke processoren, wat scheelt in je software licenties.
( Die vaak per CPU worden afgesloten en niet per Core. )

Dat zijn leuke servers ja, echter 384GB per 12 cores komt uit op 32GB per core. Ik heb nog nergens gezien dat er meer dan 10VM's per core kunnen draaien dus dan komen we uit op 3,2GB per core, is wel behoorlijk wat meer dan nodig is, meer dan 1.5GB lijkt niet nodig.

Question Mark schreef op donderdag 23 september 2010 @ 13:15:
Wat je dan eigenlijk doet is gebruikers laten werken vanaf een 64 bits omgeving (64 bits is veel memory en een hoge userdensity). De paar rottige applicatie installeer je op 32 bits systemen en "publish" je naar je gebruikers toe.

Heb al aardig wat doorgenomen over application publishing en ik zal daar nog even verder naar kijken.

Let even op dat App-v en Xenapp verschillende zaken zijn. Xenapp is Citrix's aanvulling op Microsoft Terminal Services met enkele voordelen. App-v is een applicatievirtualisatietechniek (waarvan Xenapp overigens vergelijkbare functionaltiteit aanbied). App-v is tegenwoordig onderdeel van de RDS-call (dus gratis voor terminal server gebruikers), voor de VDI-werkplekken moet je deze volgens mij nog wel los aanschaffen (onderdeel van MDOP).

Xenapp noemde ik idd omdat het, voor zover ik zag, dezelfde functionaliteiten bied als App-v ja. Maar ik ga nog verder zoeken, kijken wat er allemaal te krijgen is. Heb je nog tips waar ik naar kan kijken?
Leer echt constant bij en ben nu tot de conclusie gekomen dat dit toch wel het werk is wat ik later wil gaan doen, dus veel leeswerk en uitzoekwerk is geen enkel probleem

[Bl@ckbird]

Question Mark schreef op donderdag 23 september 2010 @ 13:15:

[...]
Intressant, maar weet je ook welke impact dit heeft op je geheugensnelheid. Juist met VDI-achtige zaken heb je veel voordeel van snelle IO.

Via dit artikel kwam ik op dit artikel over Memory Extention.
Samenvatting: 48 DIMM slots op 1066MHz.

Tsurany schreef op donderdag 23 september 2010 @ 13:35:
[...]

Dat zijn leuke servers ja, echter 384GB per 12 cores komt uit op 32GB per core. Ik heb nog nergens gezien dat er meer dan 10VM's per core kunnen draaien dus dan komen we uit op 3,2GB per core, is wel behoorlijk wat meer dan nodig is, meer dan 1.5GB lijkt niet nodig.

In mijn eerdere linkjes zijn ook test resultaten opgenomen.
( Zoals VMWare View met 128 en 160 desktops per server. )

Het eerder genoemde linkje over Citrix XenDesktop test men met 110 desktops.
( Pagina 107 van de PDF. )

Bovenstaande validated designs zijn tot stand gekomen door Cisco, VMware, Citrix, EMC en NetApp die samen deze zaken getest hebben en vormen een voorbeeld (in performance en configuratie) voor toekomstige implementaties. Cisco en anderen hebben dus redelijk wat tijd gestoken in het testen van deze validated designs.

[Tsurany]

Ik zal het nog eens doornemen. Ik hoor namelijk nergens meer dan 10VM's per core, overal dat je op 4-6 moet rekenen. Maar ik zal het morgen rustig doornemen en even allemaal bekijken.

[Zwelgje]

http://community.citrix.c...pervisors+in+VMs+per+core

Xen doet 'gewoon' 16vm's per core

[Tsurany]

Jammer dat ik dat in een paar uur zoekwerk nog niet ben tegen gekomen, maar wel zeer interessant. Zo wordt VDI wel steeds interessanter.

[3DDude]

gewoon kijken naar Xen Desktop, let er wel op dat je voldoende IOPS moet hebben met het aanbieden van dergelijke oplossingen voor veel IOPS -> denk SSD bijv. of grote arrays van het snellere sas spul

Xen Desktop is leuk om inderdaad eens naar te kijken (heb het op mijn werk gedraait)
Wij deden een gepubliceerde windows 7 draaien op een windows embedded standard thinclient, vervolgens op deze client werd dmv usb redirection een powerpoint presentatie geopent ^_^ wat gewoon soepel werkte, evenals het afspelen van HD youtube content ging wel goed ^_^.
Overigens 4 tot 6 core's
dit kunnen ook virtuele cores zijn natuurlijk
dus denk aan een nehalem quad core = 8 virtuele cores door HT
8 x 6 = toch 48 mensen op 1 fysieke quadcore (die processors zijn tegenwoordig zo sterk, daar hoef je je niet zo druk meer om te maken.)

[ Voor 19% gewijzigd door 3DDude op 23-09-2010 22:20 ]

[jvanhambelgium]

Verwijderd schreef op donderdag 23 september 2010 @ 09:21:
Overigens @jvanhambelgium: je gaat toch niet met droge ogen beweren dat je nu nog een 2003 TS omgeving gaat uitrollen? Enige optie lijkt me WS2008 (R2) met of zonder citrix sausje. Of als je de kennis in huis hebt een xenserver.

Wij hebben klanten die zelfs een nieuwe omgeving bij ons overwegen op 2003 x32 gewoon vanwege bepaalde applicaties. (eigen fabricaat, niet de standard office paketten etc). Overigens zorgen we gewoon voor een "scale out" ipv "scale up" en stellen we een onderliggend virtualisatie platform voor. De klant zal dus citrix farm met meer members hebben.
Trouwens is ook beter voor risico spreiding. Héél mooi zo'n x64 met 32GB waar 100 man (of meer) op zit te werken tot die node wegvalt voor welke reden dan ook. Zijn er gelijk 100 gebruikers geimpacteerd..Anders 3x zo weinig. Is mischien geen "key" reden maar toch mooi meegenomen.

Er is geen eenduidige oplossing.

Ook zijn er klanten waarvoor we uiteraard 2008R2 opteren met XenApp 6.x

[Stampertje]

Jiriki schreef op donderdag 23 september 2010 @ 09:30:


Met Windows Datacenter edition kun je dan meerdere Windows servers op dezelfde machine draaien binnen een Windows licentie dus daar zitten de kosten dan niet.

Met 16 cores per machine gaat het dan om 45-60 gebruikers, 45-60 GB geheugen dus ook dus dan zou je ook weer 11-16 virtuele machines moeten kunnen draaien op de server, kan lastig zijn met de schijven maar heb je een SAN hiervoor?

Houdt er wel rekening mee dat je Windows Datacenter Edition per processor dient aan te kopen. In deze casus dus 4 maal Datacenter Edition per fysieke machine. Daarnaast zal je ook nog eens je virtuele OS dienen te licenseren middels VDA (Virtual Desktop Access). Mocht je Software Assurance op je desktop OS hebben, dan heb je deze niet nodig aangezien het een SA-benifit is.

En denk ook aan de Remote desktop Services CAL (De oude TS Cal) heb je ook nodig voor ieder device/user die connectie maakt.

[ Voor 6% gewijzigd door Stampertje op 24-09-2010 09:26 ]

[Tsurany]

3DDude schreef op donderdag 23 september 2010 @ 22:18:
gewoon kijken naar Xen Desktop, let er wel op dat je voldoende IOPS moet hebben met het aanbieden van dergelijke oplossingen voor veel IOPS -> denk SSD bijv. of grote arrays van het snellere sas spul

Xen Desktop is leuk om inderdaad eens naar te kijken (heb het op mijn werk gedraait)
Wij deden een gepubliceerde windows 7 draaien op een windows embedded standard thinclient, vervolgens op deze client werd dmv usb redirection een powerpoint presentatie geopent ^_^ wat gewoon soepel werkte, evenals het afspelen van HD youtube content ging wel goed ^_^.
Overigens 4 tot 6 core's
dit kunnen ook virtuele cores zijn natuurlijk
dus denk aan een nehalem quad core = 8 virtuele cores door HT
8 x 6 = toch 48 mensen op 1 fysieke quadcore (die processors zijn tegenwoordig zo sterk, daar hoef je je niet zo druk meer om te maken.)

Ik verwacht niet dat HT hetzelfde effect op performance zal hebben als een fysieke core extra maar het zal wel positief effect hebben.

Voor VDI opslag zal er een SAN gebruikt worden, of dit de huidige SAN is of een nieuwe SAN is nog niet bekend.

Stampertje schreef op vrijdag 24 september 2010 @ 09:23:
[...]
Houdt er wel rekening mee dat je Windows Datacenter Edition per processor dient aan te kopen. In deze casus dus 4 maal Datacenter Edition per fysieke machine. Daarnaast zal je ook nog eens je virtuele OS dienen te licenseren middels VDA (Virtual Desktop Access). Mocht je Software Assurance op je desktop OS hebben, dan heb je deze niet nodig aangezien het een SA-benifit is.

Daarom lijkt de Enterprise Edition ook een stuk voordeliger. De licenties voor VDA en SA hebben wel al uitgezocht, tevens de licenties voor RDS/TS.

En denk ook aan de Remote desktop Services CAL (De oude TS Cal) heb je ook nodig voor ieder device/user die connectie maakt.

Deze heb je enkel nodig in het geval van RDS/TS correct? En daarnaast is er ook nog een Server CAL nodig voor iedere gebruiker.
Wij kwamen uit op de volgende licenties indien we enkel Microsoft software zouden gebruiken:

[ Voor 96% gewijzigd door Tsurany op 24-09-2010 09:49 ]

[Question Mark]

Kijk even goed naar het type hypervisor die je wilt gaan gebruiken. Er wil (afhankelijk van het soort load en de gebruikte hardware) nog wel wat performanceverschil tussen de verschillende smaken zitten.

Zeker als je Xendesktop overweegt, zou ik persoonlijk eerder neigen naar Xenserver. Hyper-V en ESX werkt ook wel, maar "native Citrix" implementeerd toch iets makkelijker. Licenties voor Xenserver zijn "gratis" bij Xendesktop en Xenapp (platinum).

[Tsurany]

Dat is nog een punt waar we naar moeten kijken, ik ben wel al wat documenten tegengekomen met vergelijkingen tussen de verschillende hypervisors.
We moeten ook nog kijken naar het integreren van de huidige oplossing binnen VMware omdat die momenteel gebruikt wordt binnen het serverpark. Dan is het de vraag wat het meest interessant is, aparte fysieke servers of het binnen VMware integreren.

Voor 64bit Terminal Server al het toch baremetal worden gezien dat het snelst blijkt, maar met 32bit zal je toch virtueel moeten werken en met VDI natuurlijk ook.

[Stampertje]

Tsurany schreef op vrijdag 24 september 2010 @ 09:42:
[...]


[...]

Daarom lijkt de Enterprise Edition ook een stuk voordeliger. De licenties voor VDA en SA hebben wel al uitgezocht, tevens de licenties voor RDS/TS.

[...]

Deze heb je enkel nodig in het geval van RDS/TS correct? En daarnaast is er ook nog een Server CAL nodig voor iedere gebruiker.
Wij kwamen uit op de volgende licenties indien we enkel Microsoft software zouden gebruiken:
[afbeelding]

Let er wel op dat als je Windows Server Enterprise gaat virtualiseren, en gebruik gaan maken van zaken als vMotion etc. dat dit gevolgen heeft voor de licentiepositie. Licenties ken je namelijk toe aan een fysieke host en niet aan een virtuele sessie. Je moet iedere host dus voldoende licenseren met Enterprise editie. Als een fysieke host dus maximaal 12 virtuele sessie kan hosten, dan moet je dus 3 keer enterprise editie hebben voor die host.

Mocht je het voordeligste senario uitgerekend willen hebben, mag je me wel even een DM sturen, ik heb dan namelijk wat aanvullende gegevens nodig.

[Zwelgje]

Question Mark schreef op vrijdag 24 september 2010 @ 11:16:
Kijk even goed naar het type hypervisor die je wilt gaan gebruiken. Er wil (afhankelijk van het soort load en de gebruikte hardware) nog wel wat performanceverschil tussen de verschillende smaken zitten.

Zeker als je Xendesktop overweegt, zou ik persoonlijk eerder neigen naar Xenserver. Hyper-V en ESX werkt ook wel, maar "native Citrix" implementeerd toch iets makkelijker. Licenties voor Xenserver zijn "gratis" bij Xendesktop en Xenapp (platinum).

http://community.citrix.c...e.action?pageId=131334785

hyper-v icm Windows 7 desktops is het snelst, ook volgens citrix

en die gratis XenServer mag alleen worden gebruikt voor VDI niet voor andere typen servers (exchange,sql,etc,etc)

native citrix,mja als je scvmm plugin gebruikt voor xendesktop werkt hyper-v net zo makkelijk als XenServer

[Question Mark]

Het document wat je aanhaalt is nog gebasseerd op Xenserver 5.5, versie 5.6 is echter al een tijd uit. Verder plaatsen ze zelf als opmerking dat de testen niet gerepliceerd zijn naar verschillende hardwareplatforms.

Ondanks die disclaimers kan inderdaad wel afgeleid worden dat Hyper-V gewoon goed performed.

[Tsurany]

Daar halen ze echter behoorlijk weinig gebruikers per core vergeleken met eerdere tests. Blijf het vreemd vinden, enorm veel tests die constant andere antwoorden geven mbt het aantal gebruikers dat je op een server kwijt kunt. Erg lastig om het aantal geschatte gebruikers te beredeneren. Natuurlijk moet je het altijd in de praktijk testen maar als de verhouding tussen TS en VDI tegen de 1:4 ligt dan wordt dat in de begroting toch een flink bedrag.

[Question Mark]

Meestal wordt het ook een hybride oplossing, een mix van Terminal Servers en VDI.

Ben nu net bezig met een groot migratietraject. We mikken erop om zoveel mogelijk gebruikers op Xenapp kwijt te kunnen. De "powerusers" krijgen als enige een VDI.

VDI is een ontzettend mooie techniek, maar gaat in vergelijk met TS enorm inefficient om met resources.

[Tsurany]

Dat is ook ons idee, TS tenzij... maar we moeten wel de kosten objectief weergeven en als alle bronnen tussen de 4 en de 16 gebruikers zitten dan is dat niet zo leuk als je kosten ed moet gaan uitrekenen. Je hebt al snel het viervoudige aan servers nodig afhankelijk van de praktijksituatie.

Waar we ons op focussen is kijken welke applicatis goed met TS en 64bit omgaan, daarna welke applicaties dat niet kunnen en dan kijken hoe we dat oplossen (application virtualization, application publishing,...) en als dat ook niet lukt kijken of het met VDI opgelost kan worden.

Wel blijven er nog aardig wat desktops over die direct op de specialistische apperatuur zijn aangesloten, daar is veel rekenkracht voor nodig (zware 3d berekeningen bijvoorbeeld) en dat gaan we niet virtualiseren.

[Question Mark]

Tsurany schreef op vrijdag 24 september 2010 @ 14:41:
Wel blijven er nog aardig wat desktops over die direct op de specialistische apperatuur zijn aangesloten, daar is veel rekenkracht voor nodig (zware 3d berekeningen bijvoorbeeld) en dat gaan we niet virtualiseren.

Hiervoor kun je altijd nog de VDI agent op een fysiek systeem installeren (bv. een blade-pc in je datacenter). Deze doet dan gewoon mee in je VDI-omgeving, maar je hebt als voordeel dat je de performance-penalty van virtualisatie kwijt bent. Beeldscherminfo en input wordt dan (in het geval van Xendesktop) via ICA verstuurd. Vanuit gebruikersoogpunt maakt het dan niets uit of ze werken via een virtuele of fysieke pc. (de gebruiker blijft in beide gevallen met een thin client werken).

Let wel even op dat voor 3d accelleratie binnen Xendesktop minimaal de Enterprise versie vereist is.

Moet verder ook nog even kwijt dat je er zeker voor een stage-opdracht goed mee bezig bent. Het is niet de meest makkelijke materie, maar je bijt je er aardig in vast en denkt goed na over zaken, complimenten!

[Tsurany]

Question Mark schreef op vrijdag 24 september 2010 @ 14:54:
[...]
Hiervoor kun je altijd nog de VDI agent op een fysiek systeem installeren (bv. een blade-pc in je datacenter). Deze doet dan gewoon mee in je VDI-omgeving, maar je hebt als voordeel dat je de performance-penalty van virtualisatie kwijt bent. Beeldscherminfo en input wordt dan (in het geval van Xendesktop) via ICA verstuurd. Vanuit gebruikersoogpunt maakt het dan niets uit of ze werken via een virtuele of fysieke pc. (de gebruiker blijft in beide gevallen met een thin client werken).

Dat is zeer interessant als het goed werkt, echter zit je dan niet met het probleem dat beeldscherminfo doorsturen alsnog niet gelijk is aan daadwerkelijk op een pc werken? Het zou voor de paar photoshop/autocad gebruikers goed werken, dat is zeker iets wat aan te raden zou zijn om te testen. Het zou hun werkplek wel een stuk flexibeler maken.
Voor een deel van de pc's zal het alsnog geen oplossing zijn omdat ze direct met specialistische hardware communiceren en enige vertraging absoluut onacceptabel is maar voor een aantal pc's zou dat alsnog een oplossing kunnen zijn. We zijn ook nog bezig met een analyse welke gebruikersgroepen welke applicaties gebruiken, daar wachten we ook nog op. Die krijgen we begin volgende week, dan kunnen we daar mee aan de slag.

Let wel even op dat voor 3d accelleratie binnen Xendesktop minimaal de Enterprise versie vereist is.

Ja ik was nog opzoek naar licenties en prijzen, licenties zijn wel te vinden, prijzen wat lastiger. Gaan even kijken of we de vaste leverancier om prijzen kunnen vragen.

Moet verder ook nog even kwijt dat je er zeker voor een stage-opdracht goed mee bezig bent. Het is niet de meest makkelijke materie, maar je bijt je er aardig in vast en denkt goed na over zaken, complimenten!

Bedankt Vind het ook zeer leuk om zulke zaken uit te zoeken, lijkt mij ook werk waarvan ik zeg dat wil ik later gaan doen, dan is de motivatie een stuk hoger.