VCSA – The default choice. Always.

I’ve been a big proponent of the VMware vCenter Appliance for a long time, I even did a talk called VCS to VCSA Converter or How a Fling Can Be Good for You! on migrating to the VCSA at the Nordic VMUG last year.

The VCSA has gone through a few iterations and versions by now, coinciding with the vSphere releases.

History

vCenter Server Appliance 5.0 August 2011
vCenter Server Appliance 5.1September 2012
vCenter Server Appliance 5.5 September 2013
vCenter Server Appliance 6.0 March 2015
vCenter Server Appliance 6.5 TBA

Since v6.0 scaling has been on par with it’s Windows based counterpart, supporting the same number of  hosts and VMs.

When it comes to features, VCSA 6.5 surpasses the Windows version. New tools like the Migration Tool, vCenter High Availability, Backup / Restore and the new Management Interface are all exclusively available on the VCSA.

In my opinion, the most noteworthy of these are vCenter High Availability and the Backup / Restore options.

vCenter High Availability adresses one of the main concerns with vCenter in general since the discontinuation of vCenter Server Heartbeat in June 2014. This new HA setup enables you to have a passive VCSA ready if your active one should fail, with the added protection of a witness that keeps track of it all. This is a native feature of the VCSA, and not available in it’s Windows counterpart (or little brother as it is now…)

The Backup / Restore feature is very nice as well. One of the (few) arguments I’ve heard surrounding running the VCSA vs the Windows vCenter is surrounding backup. Thankfully the myth regarding image level backups of it was debunked in v6, but the new backup / restore functionality takes that a step further. Native backup is now available in the VCSA, either via the management interface or via a public API. The backup files (HTTP(s), FTP(s), and SCP transfer protocols are supported) make up the entire VCSA configuration, and you can restore those directly from the VCSA 6.5 ISO image in case of an emergency. This means that you can image level backups of the VCSA as usual, and script the backup file generation as added protection.

Also worth noting is that in v6.5, VMware Update Manager has been included in the VCSA, and runs natively on the appliance. The last argument for keeping your Windows vCenter has just disappeared.

With the upcoming vSphere 6.5 release it’s clear that the VCSA should be the default deployment model for a new vCenter. There is really no question about it anymore. #migrate2vcsa you should.

#vDM30in30 progress:

 

Veeam vCenter Migration Utility

Way back in 2013, I published Preserve your Veeam B&R Backups Jobs when Moving vCenter, outlining how to “cheat” (by using a CNAME alias) to preserve your Veeam Backup & Replication jobs if you replace your VMware vCenter.

Naturally, when there is a new vCenter instance, all the Virtual Machine Managed Object Reference’s (MoRef) change, which makes Veeam Backup & Replication start a new backup/replication chain, since all VMs are treated as new ones. Not ideal by any means, but at least you wouldn’t have to recreate all your jobs.

Veeam has now made a tool available that can map old MoRef’s to new MoRef’s in your backup jobs, in order to keep your incremental chains intact even after replacing your vCenter.  

Check out vCenter Migration Utility!

vCenter Server Appliance Backups

For some time now I’ve been advocating the usage of VCSA instead of the traditional Microsoft Windows based vCenter. It has feature parity with the Windows version now, it’s easier to deploy, gets right-sized out of the box and eliminates the need for an external Microsoft SQL server.

One of the questions I often face when talking about the appliance, is how do we handle backups?  Most customers are comfortable with backup up Windows servers and Microsoft SQL, but quite a few have reservations when it comes to the integrated vPostgres database that the VCSA employs. One common misconception is that a VCSA backup is only crash-consistent. Thankfully vPostgres takes care of this on it’s own, by using what it calls Continuous Archiving and Point-in-Time Recovery (PITR).

I essence, vPostgres writes everything to a log file, in case of a system crash. Since this is done continuously, every transaction that should hit the DB is recorded and can be replayed if required. From the Postgres documentation:

“We do not need a perfectly consistent file system backup as the starting point. Any internal inconsistency in the backup will be corrected by log replay (this is not significantly different from what happens during crash recovery). So we do not need a file system snapshot capability, just tar or a similar archiving tool.”

With regards to the VCSA, this means that your image level backups  will be consistent, and there isn’t really a need to dump and export the vPostgres DB and then archive that. Yet another reason to switch to the appliance today!

Myth busted!