I was fortunate enough to attend Ray Heffers session on Horizon 6, which had some interesting topics of discussion and some key takeaways for attendees that were looking to implement Horizon 6 within their environments.
The first element was a recommended design methodology. As any EUC/Workspace architect or consultant is aware it is crucial that you work to a proven methodology and where possible you don’t miss steps. One of those most important steps is the first… THE ASSESSMENT! The assessment provides you with the ins and outs of what your users are doing on their existing workstation(s) from CPU, Network, Disk IO, app usage, usb periphery usage, are they mobile or not? Is there issues on the existing end points? Memory leaks, paging issues etc etc… all of this information can be used with the correct tools and products to build your environment logically and intelligently so you are not under sizing or over scoping. Rays design methodology followed a very similar methodology that most projects should follow:
- Assessment – liquidware labd, lakeside systrack, centrix workspace IQ, there are a few out there to choose from, but my favorite is Lakeside Systrack. That may be due to using this tool for so long.
- Discovery – workshops, building of use cases, POC, requirements capture
- Plan & Design – HLD, logical designs, physical designs, requirement capture mapping
- Build & Test – validated design, load testing, updated design
- Optimise – tuning, best practice implementations
- Review – iterative process, analyse areas of improvement, review your roadmap
Another key point on this methodology is the “Review” section and specifically the review your roadmap. When looking to implement a Horizon environment or even any change in workspace practice it is best to treat it as if it is a single product. This means you can plan that in release phase 1 you will meet X requirements, in release phase 2 you will add these benefits, etc and if you communicate this to your organization/users they are then actively waiting and knowing more improvements are coming.
Horizon Pod & Block Architecture
The next element I thought was worth noting from Rays session was the overview of the Horizon Pod and Block Architecture, but more crucially the limits and maximums for this architecture. Firstly it is best to outline what the Pod and Block architecture actually is and this is easily identifiable on the pictures below:
As you can see from the pictures a block consists of physical servers, a vSphere infrastructure, View servers, shared storage, and virtual machine desktops for end users. You can include up to five blocks in a View pod. A pod is a unit of organization determined by View scalability limits and the best practice/chosen design.
As you now know the basic of what the Pod and Block architecture looks like, the picture below outlines some VMware guides for sizing a cloud pod:
At a high level each vCenter server should be designed handle no more than 2000 sessions, a single pod shouldn’t have more than 10,000 sessions, maximum connection servers per Horizon environment is 7 connection servers, and you should NEVER stretch connection servers. You shouldn’t stretch the connection servers due to messaging services, as latency could provide errors about session active states. For example; a session maybe available on one connection server but not on the other due to the latency and the handshake not being completed, therefore providing connectivity issues for users. VMware state that connection servers should be on the same LAN, and a LAN is outlined as any network with latency above 1-2ms. If VMware support believe you are breaking the LAN vs WAN rules and stretching your connection servers they will not support it!
UPDATE: One thing to note is VMware do support up to 10,000 VM’s with Horizon 6 on a single vCenter, it’s just not recommended. In fact with 32 host clusters which are supported, it might be acceptable to bump up to 4,000 per vCenter. Monitoring and testing of this is to be completed. Previously the 2,000 desktops per block (vCenter) came about because there were 5 blocks with a max of 10,000 desktops in a pod.
What is this? Why should people look at utilizing this?… well global entitlement is a way for multiple Horizon Pods to be connected together over a global data layer. This is not GSLB, but allows you to provide a desktop or application from multiple data centres. For example: you have an on-premise pod and a cloud pod. You could link the two together with global entitlement and provide instant growth of your Horizon environment.
From the session Ray outlined that it is probably best that you enable and configure this anyway on a single block, as you could then create multiple pools with a single entitlement and could also assist with managing larger pools and recompose times!
Horizon Configuration Maximums
Below are a couple of pictures from the session on the key maximums. These can also be found online.
The key takeaway here was DO NOT size to the maximums as in some circumstances this wouldn’t be beneficial. For example; recomposing a single pool of 2000 desktops would take a while. Instead you could use global entitlement and split your pool up into smaller chunks for quicker recompose times. On the note of composer, View composer supports 2000 tasks per composer, but this would need monitoring and additional servers with lower tasks may provide you with better performance in your environment. Monitor this!
Also vSphere supports 64hosts within a cluster, but Horizon only supports 32. This is only due to what has been tested and seen working at scale within an environment.
- Load balancing
- Various ways this can be achieved but utilizing a load balancer that supports probes and persistency is advised.
- Access point
- Look to utilize this instead of security server moving forward where possible, lots of reasons why, but one key one is to remove the static mapping between security server and connection server. (Another post on this coming soon!)
- Virtual Center HA is always something to think about
- Discuss RTO/RPO SLAs, no official stance from VMware for VC HA preference but plenty of options: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1024051
Thanks for reading this blog, another one to follow in the next few days.