Good morning,
I'm looking for potential options/ideas on creating a fail-over between connections servers. Currently we're using BLAST over a Secure tunnel, if a connection server goes down for whatever reason anyone connected losses their connection until the server is back up. Is there anyway to fail over these connections to another connection server? I've read some articles mentioning a load-balancer can be used for faster re-connections, but doesn't stop the disconnection. Is there anyway to accomplish complete fail-over? or is load balancing the best option for minimizing impact? Any info/suggestions are appreciated.
No, you can only load balance, there currently is not a way to have a fault tolerant connection. You could use a unified access gateway and have that point to the connection servers, those can hold the secure gateway instead of the connection server, but if one of those fails, users get disconnected but then can log back in again as those are generally load-balanced as well.
I dont believe Horizon View offers any fault tolerance, just High Availability of the Connection Servers. If you have capacity and the VMs are a suitable spec, you could potentially look into using vSphere Fault Tolerance in addition to load balancing your connection servers
This thread: Rebooting UAGs mentions using Quiesce Mode. From VMware's documentation, it doesn't look like it does anything more then set the UAG in an 'unavailable' state so new users cannot connect to it. It doesn't mention what happens to existing connections, i'm assuming they'll get disconnected.
That is correct, queise mode changes the favicon to generate a 503 error I think, and you configure the load balancer to see this so if it happens it restricts new connections that uag. This allows you to do maintenance only when users are off, but it does not protect you if one fails. The reason I suggest the uag is they don't have normal updates like a windows server would have, I have my connections servers auto patched, and since my users are all using unified access gateways(internal and external) they don't get disconnected because of the reboot. UAGs outside of the initial setup if anything breaks or you need to update you generally just replace them. I was hoping the new high availability feature added to the uags recently would do you want, but that too would disconnect a session on failure, that feature only is a replacement for the need for a load balancer if you didn't have one you could use.
Yes, unfortunately user connection will be lost if your connection server goes offline. Assuming they're load balanced they should be able to just reconnect to your other connection server though, not ideal but its a limitation of the connection server
I question if that would be supported, every document I ever read never suggested that as a possibility, which if it was viable I would think they would have.
What’s the reason you’re using the Blast tunnel? It’s common to disable that altogether for internal users on the Connection Servers to avoid the exact scenario you’ve described. This prevents disconnects during reboots / maintenance.
Furthermore, if you wish to withstand a CS failure, you should have your Connection Servers load balanced and your clients should be pointing to the VIP instead of the Connection Servers themselves.
To provide load-balancing there is some way to do that, but I don't think a specific failover technology for the connection server is highly necessary. Suppose that if you lose the View Connection Server temporarily, the existing connections are still stablished and no need to reconnect them at that moment. For the other new connection requests, if it's critical you can install the View Direct Agent in the template VM for deploying new desktops and grant access to the users if there is no connection server! (not exactly maintain availability, but is a simple and useful method). However, don't forget the connection server is just a Broker and can be re-deploy this service very fast (if you don't lose the LDAP database VDMDS) and also there are many other reasons that I think there is no need for that.
