A few days ago I posted vCenter 5 - To Appliance or Not? talking about using the virtual appliance. I'm glad that article has been popular because it's a very important decision to make as you move forward with vSphere 5. As I move forward with my choice of using the original Windows installer, here are some design considerations to keep in mind.
During my beta testing for vSphere 5, i stuck the vCenter ISO into my existing vCenter and started going install crazy. I upgraded vCenter to version 5, installed auto-deploy, log collector, web services, update manager, and the whole shabang. It wasn't until one day when I had to reboot my vCenter VM that everything became clear. Upon reboot, my vCenter service failed to start.
I took a gander at the logs thinking it would be a DB miscommunication and there was an entry with something along the lines of failure to lock a socket. It makes perfect sense. vCenter services depend on port 80 and I installed vCenter Web Services which also defaults to port 80. Since vCenter Web Services was already in use of port 80, the service wouldn't start. I stopped all the IIS services and restarted the vCenter service and all was well again. Therefore, I started to think of what the best design practice should be for vCenter components.
vCenter has become one of the most critical components of vSphere. Issues with vCenter can cause panic attacks because you feel that your VMs are at a risk, but be not afraid, plenty of barriers are built in. If you didn't know already, HA doesn't depend on vCenter once the hosts have been configured, heartbeats are sent and vCenter failing won't leave VMs unprotected. vMotion, DRS, and DPM on the other hand all do rely on vCenter. The focus of this blog article is to discuss installation strategies for all the VMware vCenter required components:
- VMware vCenter
- VMware Update Manager
- VMware ESXi Dump Collector
- VMware Syslog Collector
- vSphere Web Client (Server)
- Auto-Deploy
- VMware vSphere Authentication Proxy
- vCenter Orchestrator (?)
The goal of this exercise is to distribute the components of vCenter evenly across the board so each server isn't being hit to hard, at the same time reduce the number of guests needed.
option 1 (more consolidated):
Server 1 - The database:
Microsoft SQL
Server 2 - The core:
VMware vCenter
vCenter Orchastrator
VMware ESXi Dump Collector
Server 3 - The addons
VMware Syslog Collector
vSphere Web Client (server)
VMware Update Manager
Auto-Deploy
vSphere Authentication Proxy
Option 2 (more separated):
Server 1 - The database:
Microsoft SQL
Server 2 - The core:
VMware vCenter
vCenter Orchastrator
VMware ESXi Dump Collector
Server 3 - The addons
VMware Syslog Collector
VMware Update Manager
Auto-Deploy
vSphere Authentication Proxy
Server 4 (maybe DMZ):
vSphere Web Client (server)