NimbostratusAsymmetric Hardware Requiring Asymmetric View Pool Entitlements
Hi Guys!
Need some thoughts on a View farm design. Givens: Horizon 7 Advanced Licensing F5 BigIP x2 - Full alphabet soup license NVIDIA GRID Profiles on page 4 of vGPU User Guide
Pod A
- 5x Cisco UCS B200
- 2.0Ghz, 2 sockets, 28 cores, 56 threads
- 512GB RAM
- NetApp SAS backed
- 1x NVIDIA GRID M6 in vSGA Mode
Pod B
- 5x Cisco UCS C240
- 2.6Ghz, 2 sockets, 24 cores, 48 threads
- 512GB RAM
- Micron PCIe Backed
- 2x NVIDIA GRID M10 in vGPU Mode 1GB per VM
Pod C
- 5x Cisco UCS C240
- 2.1Ghz, 2 sockets, 36 cores, 72 threads
- 512GB RAM
- Micron PCIe Backed
- 2x NVIDIA GRID M10 in vGPU Mode 1GB per VM
Pod D
- 5x Cisco UCS C240
- 2.1Ghz, 2 sockets, 36 cores, 72 threads
- 512GB RAM
- Micron PCIe Backed
- 2x NVIDIA GRID M10 in vGPU Mode 1GB per VM
Pod X
- 1x Cisco UCS B200
- 2.0Ghz, 2 sockets, 28 cores, 56 threads
- 512GB RAM
- NetApp SAS backed
- 1x NVIDIA GRID M6 in vSGA Mode
- 1x Cisco UCS C240
- 1Ghz, 2 sockets, 36 cores, 72 threads
- 512GB RAM
- Micron PCIe Backed
- 2x NVIDIA GRID M10 in vGPU Mode 1GB per VM
Use Scenario:
We have 3 types of users.
General Purpose Students and Staff
Need some GPU to make Win10 experience better
Windows 10 Creator vGPU Backed @ 512MB
Power User Students and Staff
Using apps that require GPU - Adobe Apps, Games, Autocad, Etc.
Windows 10 Creator vGPU Backed @ 1GB
Generic Accounts
These accounts are used for:
Kinder -> Second Grade
Library Search Kiosks
Academic Testing Kiosks (for SBA and MAP computer based testing)
School Board Meeting Kiosks
Probably fine using vSGA mode graphics
Problem:
We have a bottleneck with vSphere and View Composer where it takes an inordinate amount of time to prep pools during login/logout storms or events that cause the environment to go sideways.
Our thought is to break up into pods to mitigate having all 4 pods go down due to view component parts at the same time. This would also provide the side benefit of only impacting 25% of the environment at a time when going to do upgrades and even make it possible depending on the calendar to do the maintenance of the environment during the production day.
Snag:
Pod A is composed of vastly asymmetric hardware than what Pod’s B, C and D are composed of. Pod X is set aside so that we have a test bed for image development, upgrade testing and firmware testing with UCS. Hosts from Pod X could be added to Pod A or B if needed to help with increasing capacity.
The idea would be to put users that have less need for GPU onto Pod A and run the NVIDIA M6 GRID Cards in vSGA mode to make Windows 10 more bearable due to the limitation of 16 VMs with a 512MB frame buffer if in vGPU mode.
Then users who need vGPU would be routed to the C240 pods (Pod B, C and D) and could have a mixture of 512MB and 1GB profiles on the same host provided that like profiles map to the same card giving a theoretical max load of 64x 512MB VMs and 32x 1GB VMs per host and around 5GB RAM per VM if evenly distributed also understanding that in a running configuration that doesn’t allow for enough CPU threads per desktop.
So at the end of this is what is the best method to use for having a user login to an entitled pool that doesn’t exist on all 5 pods that are deployed. Do you solve this with a Big-IP config, Cloud Pod Architecture or something else less complex (ie. Load balance Pod B, C and D. Have a separate DNS for Pods A and X.)?
