So my weekend involved taking the kids to soccer and leaving the field 1.5 hours later like a block of ice. Another winters day in Wellington to remind me how great Sydney weather was. Why is it that the only people who seem to not feel the cold are kids and old people. My theory is that if you go to the beach and you only see these variants in the water its safe to assume “its cold”. End of story – I’m not going in there.
Thus when I arrived home I decided to lock myself in the garage with the heater and spin up my lab servers and build up a Horizon View 6 environment and put in place the Cloud Pod Architecture.
So the lab consisted of 2 vCenter Servers, 2 connection servers and some floating pools. A basic configuration at this stage to test the concepts.
The setup of View 6 is nearly identical to View 5.x. The GUI only has some slight changes for Application Pools, and RDSH hosts. I started by getting the basics stood up on each Connection Server and vCenter and confirmed that I could get a desktop from each Connection Server which was via separate DNS namespaces. All good so far.
Next step I wanted to test out the Application Remoting feature. Really liked this and was very simple to stand up. Getting the apps published though to the Horizon View Client was a breeze, and launching them from the client makes like so much easier. That is a great feature which I am sure end users will like.
Moving on to the Cloud Pod Architecture setup. Was pretty straight forward again, albeit all via command line, so I hope in a point release this is changed to the GUI. Once the configuration was complete I had 2 bogus data centre configurations with the Cloud Pod layered over the top, so 2 sites logically joined as 1, changing the DNS so now all a single name space.
Once the Global Entitlements was complete I could log into Site1 with User1 and get a floating Desktop. I could log into Site 2 with User 2 and get a floating desktop. I could fail the Connection Servers in Site1 and then login and get a desktop for User1 at Site 2. Works a treat.
Some things to note:
Persistent desktops will not bounce you to the other site in the event of a failure, the users entitlement at the other site will need to be a floating desktop.
Currently Persona does not support RDSH in View 6.0, its coming and hopefully the wait isn’t long.
Once the Pod Architecture is in place, there really is no way to tell that its in place when looking at the View Admin Portal and may confuse View Administrators not aware of the setup. You can see “Remote Pods” but that’s about it. Mind you we are still at the first release of this new version.
So what do I think about View 6?
Great for active/active designs, or disaster recovery scenarios, saves the cost of having to purchase session aware load balancers.
However, for highly available 24×7 no single point of failure designs I am still sold on having clustered application delivery controllers to control the traffic flows between sites. I have implemented Riverbed SteelApp (Stingrays) for View 5.x and the solution works great and has granular control on where to send users for primary pools, failure pools and pools of last resort.
So the next challenge I have is to rebuild my lab as 2 stand alone Horizon View 6 pods without the Cloud Pod Architecture and get the Riverbed SteelApp working.
Musings from a past life 