Horizon View over WAN link

[nasdude]

We hebben 19 locaties over heel europa met ongeveer 80 werkplekken per locatie.

Centraal is er een datacenter, (AD, E-mail, ERP systeem etc draait daar) we zijn begonnen met VDI desktops aan te bieden naar de locatie maar dit blijkt uiteindelijk niet te werken omdat de WAN link van de locaties ook gebruikt worden door o.a. laptop gebruikers die de WAN link dicht duwen, daarnaast is op sommige locaties max 4mbit beschikbaar dan worden 60VDI werkplekken wel erg krap.

Er is besloten decentraal (op iedere locatie) servers neer te zetten welke VDI aanbieden aan de medewerkers, zodat ze in iedergeval lokaal goede performance krijgen.

In het kader van kosten besparing en ease of management hebben we besloten de meeste servers in het datacenter neer te zetten zodat we niet 19 vcenters en 38 view servers hebben draaien om te onderhouden, updaten etc.
De huidige setup is dan ook:
In het centrale DC
- SSO Server
- VCenter server
- View Servers (4 stuks), waarvan op 1 server de composer service draait.

op de locaties staan 1 of meedere servers (meerdere servers = shared storage via FC).

Vandaag deploy ik een pool van 80 vdi guests (linked clones) en het viel me op dat ik de WAN link van die locatie volledig dicht drukte, het proces vmware-ufad.exe stuurt data naar de hosts gedurende het provisioning proces.

Zijn er hier personen die dit soort setups vaker hebben gedaan, heeft het nu om bv op iedere locatie een composer server neer te zetten? Tips zijn welkom

ps. We kunnen de WAN link niet sneller maken op de locaties 4/4mbit of 8/8mbit is de max. (ik zou het graag anders zien), iedere locatie heeft wel een WAN compression unit

[ Voor 4% gewijzigd door nasdude op 18-11-2014 21:16 ]

[Bl@ckbird]

Zorg dat QoS op de WAN link configureerd zodat VDI verkeer voorang heeft op ander verkeer. Als de WAN-link ook gebruikt wordt voor internet verkeer, kan je er voor kiezen om internetverkeer via een goedkoop consumergrade lijntje lokaal te offloaden.

Wat die WAN compression unit doet weet ik niet, maar compressie is niet genoeg als je de effecten van latency op TCP verkeer wil ondervangen. WAN verkeer kan je optimaliseren met bijvoorbeeld Cisco WAAS en Riverbed Steelheads. Deze laaste heeft specifieke engine om VDI verkeer te optimaliseren.

Voor grotere lokaties kan je extra servers neerzetten voor om virtual desktops lokaal te draaien.
Als al Cisco routers hebt staan, kan je hier x86 server blades in plaatsen waar je lokaal virtual desktops op draait. Je kan nieuwe en bestaande routers ook voorzien van de juiste software en licenties zodat ze iWAN doen. Dit is een verzameling van technieken om verkeer zo efficient mogelijk te transporteren. ( Performance routing op basis van latency, jitter en bandbreedte. Bulk verkeer offloaden via goedkope, consumergrade internet lijntjes. Caching technieken zoals Cisco WAAS en Akamai, etc.)

Zowel Cisco als Riverbed doen proof of concepts, zodat je dit in een kleine omgeving kan testen.
( Bijvoorbeeld een WAN verbinding tussen het DC en één nevenvestiging.)

Bottomline is dat jij je WAN lijnen veel verder kan finetunen dan wat je nu denkt wat mogelijk is.

[nasdude]

Bl@ckbird schreef op woensdag 19 november 2014 @ 12:32:
Zorg dat QoS op de WAN link configureerd zodat VDI verkeer voorang heeft op ander verkeer. Als de WAN-link ook gebruikt wordt voor internet verkeer, kan je er voor kiezen om internetverkeer via een goedkoop consumergrade lijntje lokaal te offloaden.

Flexible QOS is in place, internet verkeer loopt al via adsl lijnen naar de at&t proxy servers

Wat die WAN compression unit doet weet ik niet, maar compressie is niet genoeg als je de effecten van latency op TCP verkeer wil ondervangen. WAN verkeer kan je optimaliseren met bijvoorbeeld Cisco WAAS en Riverbed Steelheads. Deze laaste heeft specifieke engine om VDI verkeer te optimaliseren.

Elke locatie heeft een riverbed voor compression&caching, ingericht door consultants van riverbed zelf

Voor grotere lokaties kan je extra servers neerzetten voor om virtual desktops lokaal te draaien.
Als al Cisco routers hebt staan, kan je hier x86 server blades in plaatsen waar je lokaal virtual desktops op draait.

Dat kan in de riverbeds ook, single servers/hardware/router op de locatie = SPOF, niet een optie die wij ambiëren, dan liever servers op locatie

Je kan nieuwe en bestaande routers ook voorzien van de juiste software en licenties zodat ze iWAN doen. Dit is een verzameling van technieken om verkeer zo efficient mogelijk te transporteren. ( Performance routing op basis van latency, jitter en bandbreedte. Bulk verkeer offloaden via goedkope, consumergrade internet lijntjes. Caching technieken zoals Cisco WAAS en Akamai, etc.)

Zowel Cisco als Riverbed doen proof of concepts, zodat je dit in een kleine omgeving kan testen.
( Bijvoorbeeld een WAN verbinding tussen het DC en één nevenvestiging.)

Bottomline is dat jij je WAN lijnen veel verder kan finetunen dan wat je nu denkt wat mogelijk is.

die conclusie is iets wat kort door de bocht, als je met 60 users, waarvan 40 vdi, 15 laptops en 5 engineers een 4mbit lijn moet delen is dat gewoon te krap om alles remote te doen. zodoende mijn vraag

[Equator]

Maar heb je dan ook daadwerkelijk gemeten of je wan verbinding volloopt? En hoe heb je die conclusie betrokken?

Aan de andere kant, 40 vdi clients op basis van het ica protocol past ongeveer precies in 4Mbps. PCoIP is echter minder goed over smalbandige verbindingen.

[mistercash]

Je zou een 2de wan kunnen toevoegen voor enkel mgt trafiek.
Hiermee wordt mgt van prod gescheiden.