Over the past couple of weeks I got to work with a client who generally would have not used PSO for a vCenter upgrade but because of the new features, such as SSO, introduced in 5.1 they brought me in.
The customer, like many, didn’t really understand SSO and the different options to deploy it. Many customers I talk to initially want SSO in HA, not understanding that this requires a load balancer in front of the SSO servers. While this option is perfectly viable there are a couple caveats to it. Since the admin role is only installed on the first SSO server when this server is down services that are registered to SSO, like vCenter, the Inventory Service, and the Web Client, will not be able to start. They will keep running with the admin service down but if a restart of the server or service takes place they will not be able to start. Another caveat is no administration of SSO or registering of additional services can take place. So really in this first release of SSO the only thing that is HA in HA mode is authentication.
Once this conversation takes place customers ask how to protect it. The easiest is to just use HA that’s built into vSphere. This is a good option if you’re only worried about host failures, or BSod’s (when enabled HA can recover crashed guests). If you also want to protect against outages due to OS issues vCenter HeartBeat provides this in addition to doing maintenance and rebooting VM’s with only taking a small outage to move the service to the secondary node.
I am, and have been for years, a big fan of vCenter Heartbeat. When a customer has the requirement to keep vCenter and related services available such as when other components like vCD, View, SRM, etc. are in the environment or they just wish to always have vCenter available I recommend they implement vCenter HeartBeat.
We were also deploying SRM the week after the vCenter upgrade, which meant we needed a 2nd vCenter as they had been running a single vCenter to manage both sites.
The customer also requires all certificates to be issued from their CA and to not use any self-signed certificates. As I’ll detail in the following posts, this lead to some interesting discoveries that I haven’t seen documented elsewhere.
The diagram below is how I recommended this customer implement vSphere 5.1 and is the direction we went. In it you’ll see in each site the following servers:
- SQL Server protected by vCenter Heartbeat
- Single Sign On (SSO), configured in Multisite mode, protected by vCenter Heartbeat
- vCenter and the Inventory Service protected by vCenter Heartbeat
- vSphere Web Client protected by vCenter Heartbeat
- Update Manager protected by vCenter Heartbeat (this server also hosts storage plug-ins such as NetApp’s VSC)
