Part 1: Complement your VDI environment with NSX.
Part 2: Complement your VDI environment with NSX: dFW.
Part 3: Complement your VDI environment with NSX: IDFW.
Part 4: Complement your VDI environment with NSX: Introspection Services.
Part 5: Complement your VDI environment with NSX: IDS/IPS.
Part 6: Complement your VDI environment with NSX: Advanced Load Balancer
Thanks to Siegfried Huijgen I ended up receiving a lot of attention on the 5 part series, which spun off into a request for a part 6 on Avi Networks Load Balancing. While the other posts have focused on security, it makes perfect sense to include the NSX Advanced Load Balancer (Avi Networks) into the mix of complementary services for VDI’s.
For the remainder of the post please note that “NSX Advanced Load Balancer” will be referred to as ALB.
Also note I have assumed the VDI solution is Horizon View, seeing that this is a VMware centric post.
Does VDI need Load Balancing?
No, it doesn’t really need Load Balancing, but like so many other solutions. it really does help deliver a highly available solution.
There are numerous Load Balancers that can deliver a VDI centric solution, but none are as tightly coupled with NSX as the ALB. Avi Networks was tightly integrated with vSphere and NSX before the acquisition and as you can imagine it is now even more so, becoming the NSX Load Balancer of choice.
Load Balancing and even Global Load Balancing allows a VDI solution to dynamically fail between UAG’s (Unified Access Gateways) and CS’s (Connection Servers). Even at a high level, we can see the implementation of Load Balancing in VDI solutions can help.
Architecture Types.
I’ll lightly discuss each Architecture type for VDI deployments, but for a more in-depth review of each design and the reasons behind the designs, I would suggest you check out the Avi Networks article:
https://avinetworks.com/docs/20.1/avi-horizon-reference-architecture-guide/
There are three (3) main types of Architectures for Load Balancing Horizon solutions:
- Single VIP with multiple Virtual Services.
- Single-layer 4 VIP Virtual Service.
- (n+1) VIP.
The Single VIP with multiple Virtual Services will provide the high availability design with traffic being balanced between the UAG instances. This, in turn, using source IP affinity will push all secondary traffic (blast and PCoIP) towards the same UAG instance.
The single-layer 4 VIP Virtual Service is similar to the above example except the forwarding is done at layer 4 rather than at layer 7. This does provide some advantages and some disadvantages. Check the Avi Networks article linked above for further details or the table below.
The n+1 model load balances the HTTPS traffic to the CS instances and then blast and PCoIP traffic is forwarded directly to the UAG’s rather than proxying via the Load Balancer.
The pro’s and con’s of each solution are really interesting and Avi do a great job of displaying the difference between each of the possible solutions.
Remembering while deciding the above, you can bypass the UAG instances and hit the CS instances directly for internal clients.
Sizing Guide.
Sizing is both one of my favourite and least favourite discussions simultaneously. Size conversations can be easy with plans put in place if you and/or the customer knows the relevant information (number of users, bandwidth averages per user, etc). If the information is unknown, as the Architect you need to work with the information you receive, make some well-educated assumptions and finally, always scale for decay and growth.
The Avi Networks article above does a great job of providing examples with a clear framework for users and architects to follow. That said, one of my favourite things about ALB is the auto-scaling of the SE’s (Service Engines).
I had previously done a blog series on Avi Networks, now ALB which talks about auto-scaling and the different components:
- https://vmusketeers.com/2020/05/09/avi-networks-the-advanced-nsx-load-balancer/
- https://vmusketeers.com/2020/05/24/avi-networks-base-configuration/
- https://vmusketeers.com/2020/06/19/avi-network-base-configuration-via-api/
In a design such as a Horizon one, I would be keen to implement a horizontal scaling group for the SE’s using BGP, rather than native routing. I understand that sentence might be confusing, but the articles above should help if you are lost. Virtual scaling with BGP is as automated as it’s going to get with ALB. In short, ALB will spin up more SE’s as the load becomes high and spin them down as the load becomes low. BGP can be used to advertise the new SE’s to the upstream elements and ECMP logic will be used. This means we can design an load balancing infrastructure that grows when you need it the most and shrinks during quiet times.
Configuration.
There is a terrific low-level configuration document provided by Avi Networks:
https://avinetworks.com/docs/20.1/configure-avi-vantage-for-vmware-horizon/
I’d like to run through the configuration at a high level to ensure we know what we are creating and why we are creating it.
IP Groups – The idea of creating IP groups is to simplify the pool configuration. Multiple UAG IP addresses can be placed into an IP Group and then that group is referenced.
Custom health monitors can be created for any service. A recommended one for Horizon environments is the GET /favicon.ico HTTP/1.0 request. This custom health monitor would be used on your pool members or IP group members.
Pool’s are pretty self-explanatory. The pool of resources that your Virtual Service will forward traffic towards.
Virtual Services can differ as either Layer 4 and Layer 7 services. Layer 4 services are typically considered performance or faster load balancing services because they require fewer CPU cycles to forward the traffic and are a tiny bit quicker than their layer 7 counterparts. Layer 7 services on the other hand require more CPU cycles and are considered slower at forwarding traffic, however they do collect much more in-depth analytics, especially when using the ALB.
Putting all these elements together provides you with a robust load balancing solution that can dynamically update the forwarding paths for users based on outages, latency etc.
While the concepts above have all been focused on the UAG’s. The same logic can be used for the CS elements as depicted in the first diagram.
Automation
If you’ve been reading any of my blogs, you will know I’m a huge Terraform fan. Lucky for me/us there is a Terraform Avi provider and some really nice blogs. Rather than rehash David’s code, I’d like to link you to his blog on setting up Avi Networks using Terraform. It’s terrific!
https://davidwzhang.com/category/terraform/
I’ll end the VDI/NSX series with this post (unless other requests come in). I want to thank everyone who read the posts and I hope people have and will find them useful now and in the future.
Leave a Reply