How to best setup View Connection Server and Composer to limit single point of failure?

[JPM300]

Hello all,

Just had a few quick questions:

1.)  How is everyone limiting the View Connectoin Server to a single point of failure.  All the reading I've done it looks like everyone sets up two connectoin servers and either does DNS round robbin on it, or puts both connection servers behind a load balancer

2.)  What happens if the View Connection server goes offline while users are logged in and actively using desktops?

3.)  How do you protect View Composer from single point of failure.  It looks like most people are installing this on there vCenter server and just leaving it to VMware HA.

4.)  What happens if View Composer goes down and you have active desktop sessions being used by users that are linked clones

5.)  What does the View Connection Server Replication Partner used for?  Is this a new feature of View 6 that creats some form of Cluster for the connection server?

Let me know,

Thanks

[lbourque · Accepted solution]

1. Yes. Need a load balancer. Something better than a DNS round robin since those go based on ping (host response) and not necessarily whether the service is up (port 80/443 responding with 404)

2. User gets disconnected. When reconnect they can continue where they left off.

3. pretty much it. Also ensure regular backups are done by the connection server. Remember that if you need to restore, restore both the AD LDS and Composer SQL backup.

4. Should be fine. The only issue is during provisioning, deleting a linked clone or creating one. Then could be a problem. Refresh should be ok

5. Replication partner? Do you mean the Replica Server? It's just an identifier during install as to whether, when installing the Connection server, you are creating a new View instance or expanding an existing one. It ends up as a peer to other connection servers within the same instance (POD).

[JPM300]

Ahh okay, thanks for all the awnsers, that clears it all up nicely

So the composer is just like VC which if its down you just can't make any changes until its back online but everything continues on as it should.  In which case I could see why this is a good fit/role to install on the VC server as well.

Thanks again!

[lbourque]

JPM300 wrote:

Ahh okay, thanks for all the awnsers, that clears it all up nicely

So the composer is just like VC which if its down you just can't make any changes until its back online but everything continues on as it should.  In which case I could see why this is a good fit/role to install on the VC server as well.

Thanks again!

Well.. that's an "it depends.." kind of thought. You need to consider how busy your vCenter is. Composer can generate it's own load and if the vCenter is already swamped, this won't help. For a small environment, I'd say ya, sure. Have them on the same Windows VM (obviously cannot do this with the appliance since Composer is Windows-only). But larger environments performance testing may be needed to determine if they should be together or separate.

[JPM300]

Yeah this is just for a quick proof of concept at the moment.  However if it goes live or scales out, it will get its own server.

Thanks again!

[cpernet]

Hi lbourque.

I was looking for some details about what happens when Composer becomes offline. your number 4 confirms what I thought. Thank you for this.

About the number 2, isn't this true only when tunneling is enabled ? When it's not, the View (or Horizon) Client only needs the Connection Server for authentication, but when the virtual desktop has been given to the user, then the session goes directly from the Client to the View Agent, right ?

[JHT_Seattle]

You're right, to an extent.  If your connection servers are only acting as brokers and not proxies, then one of them going down will not affect any users logged into VMs.  If they're acting as a proxy, however, the user will be disconnected.  Assuming you've set up load balancing correctly, when the user tries to reconnect they'll be routed through one of the other connection servers to the VM.

This is really more of an issue with users accessing your VDI environment from the internet, as they will be routed through a security server which, in turn, is linked to a connection server that requires a proxied connection.  It's hard to do any sort of maintenance on those pairs of servers (assuming you have, at minimum, 4 for redundancy) without causing a service interruption.  I've requested a feature to put proxied servers into a maintenance mode so that sessions can either be migrated to another server via a drain/stop method, or something even more wishful that I call "vSession" wherein the user session would be transferred from one proxying security/connection server to another.  All I want is a way to keep an always-on service always on, and to do maintenance without affecting users!

[JHT_Seattle]

Also, something to consider beyond POC is using Cloud Pod Architecture, even within the same datacenter.  That can give you Composer redundancy and allow you to present a single pool to the user that is really made up of two separate pools created by two separate composers, running on the same, or different, ESXi hosts.