If you have questions about the deployment of or migration to the VCSA no matter what version, Emad and Adam are probably the guys you want to have a conversation with and the session called ‘The vCenter server and Platform Services Controller Guide to the Galaxy’ should be the first session you should check out at VMworld Barcelona.
The right question to ask yourself here is: why would you want to stay with the Windows Server hosted vCenter server? Because you are used to it and everyone in your department can support it? Because the database administrators know perfectly well how to support Oracle or MSSQL databases but no Postgres? Because the Windows vCenter server historically has supported more features and has supported more infrastructure than the VCSA?
Well have Adam and Emad have news for you!
- The VCSA has more features than the Windows vCenter server in the vCenter 6.5 release! More about this in a bit!
- The VCSA is easier and faster to deploy than the Windows based vCenter server.
- OS and database patching can be done from the VAMI!
- No OS or database licensing costs!
- Minimal database maintenance: The VCSA 6.5 has an optimized Postgres database with a maintenance plan builtin. The VCSA 6.5 supports the same amount of infrastructure than the Windows based vCenter server.
- The VCSA comes with VUM builtin.
- The VCSA comes with a native backup and restore option.
- Native High Availability!
See here : What is new in vSphere 6.5
Let’s take a closer look at Native High Availability and why this is truly the bee’s knees:
If your vCenter server goes down, you would like it to come up again as soon as possible of course. When your vcenter server is down, you cannot create new port or port groups on your dVS, some solution users might be impacted, etc..Bringing a vCenter server back from a database backup can be a real pain so waht if you could prevent all this?
Look no further, vCenter Native HA will take care of this. A pair of vCenter servers (one active the other one standby) and a witness object make up the components of vcenter Native HA. The witness object actually is a clone of the vCenter server which if deployed with the basic workflow has the same size as the original vCenter server but has only 1 vCPU and 1 GB of RAM.
So what happens when your vCenter server goes down? When a failure happens, a screen pops up saying a failover is in progress. Meanwhile in the background the management network switches from eth0 on the original vC to the eth0 on the secondary vC which then becomes the primary VC.
FYI, failover only happens should critical services not be available anymore such as VPXD. The whole failover should take about 5 minutes.
If you wonder what Eth1 is being used for, it is used to replicate the Postgres DB between both vCenter servers and is used as the vCenter HA network.
One gotcha which you should keep in mind while designing your vCenter/PSC deployment: vCenters cannot failover to PSC’s in another SSO site! Keep in mind that this is related to the SSO site and not to the network. If you use something like OTV it will still not work.
Fantastic, not? As fantastic is that vSphere 6.5 will allow you to have 25 PSC and 25 VCs per SSO domain! I can tell you this solves my problem of creating a single SSO domain over 14 different vCenter servers for NSX. There are still other problems, but the number count will be solved in 6.5 it seems.
So now we know we can protect our vCenter servers using a form of HA. For the PSC’s the only redundant availability solution still is to use load-balancers (F5, Netscalers…) although the recommendation is to not do this as it is complex. The good news is that u vSphere 6.5 does allow SSL pass-thru (vSphere 6 did not) and doesn’t need a separate certificate on the load-balancer. However, PSC’s still do not support an active-active type of load-balancing. Some solution users such as SRM have a problem with that.
Migrating to vCenter 6.5
The new migration tool to the VCSA 6.5 supports direct upgrades from vCenter 5.5 and vCenter 6.0 U2. When you execute the upgrade, a precheck will run to see if your upgrade prerequistes are supported and the database content ( MSSQL or Oracle) will migrate to the new Postgres database on the VCSA server. Sounds simple, not? You shut the old VCSA down and the new one can be started without any issues. As far as the VM’s and solution users is concerned, this is exactly the same vCenter server as before the migration.
Oh and if you have a VUM installation installed next to your vCenter server 6.0, the migration tool will migrate the VUM database within the new vCenter server 6.5!
There is more to tell of course, so go out there and attend this wonderful session!