Recently, VMware has been investing an enormous amount of effort into bringing vCenter Server Appliance (VCSA) up to the same functionality as its Windows counterpart. vSphere 6.5 not only achieves that goal but also goes beyond it. In this article, I will explain what’s new in VCSA and why its time now to exclusively deploy VCSA and migrate existing Windows-based vCenters to VCSA too.
You probably remember the reliance of VCSA deployment on the Client Integration Plugin, which didn’t allow it to be run from a Linux or Mac machine. The first thing to mention is that, due to the new deployment process, that restriction is now gone and you can deploy VCSA from Windows, Mac or Linux.
Also, the deployment process has been greatly enhanced. There are four menu options
The install process is essentially a two-stage process:
- Stage 1: Deploy OVF
- Stage 2: Configuration
Stage 1 is pretty self-explanatory but Stage 2 has been enhanced a fair bit. You may recognise a few features from vRealize Automation 7. For example, there are improved validation and checks done in the background, before moving to the next step. Also, having it in two-stages, gives the installer an opportunity to take a snapshot before moving forward. If something goes wrong, one doesn’t have to start right from the deployment of OVA again. One other benefit is that you can now create a template for further deployments.
Now a bit about the two new options:
As the name suggests, it’s all about migrating the Windows-based vCenters to VCSA appliances. Of course, this feature was released recently as a fling but is now a fully-supported part of vCenter. The great thing about it is that it supports migration from both vCenter 5.5 and 6.0 and migrates the whole personality and configuration of the current vCenter. More specifically, it migrates the UUID, IP, FQDN, Update Manager (even if it’s external) and even certificates! That makes for a smooth transition to appliance-based vCenter management and other integrated solutions see nothing different. Not only that but one can optionally migrate configuration, events/tasks and performance metrics too – individually selectable.
How many times have we seen the vCenter machine OS not booting and that’s even worse when it’s the appliance. With the “Restore” feature, you can boot directly from an ISO and restore the backup on top of the new appliance. Doing so, gives it the same identity and configuration and you’re up and running in a few minutes. How cool is that? More on that later in the post.
There are certain features that will only be available to VCSA going forward. Here they are:
- Native High Availability
- VMware Update Manager
- Improved Appliance Management
- Native Backup/Restore
Native High Availability
High availability of vCenter has always been a difficult conversation for VMware….. remember Heartbeat anyone? Solution based on Microsoft Failover Clustering isn’t great either and fairly complex to implement and maintain. Now, VMware is introducing its new fail-over clustering mechanism, as shown below:
It’s an active/passive configuration with a passive witness. There isn’t much deviation from the normal appliance configuration. Just an additional eth1 interface is added to both appliances in question and a private network is created for them to talk on. That also means no requirement of any layer-2 adjacency or stretch cluster requirements and therefore, the other node can even be in another datacenter, as long as bandwidth/latency requirements are met.
There is synchronous replication between the two nodes, using the native Postgres mechanisms. There is some stateful information that lives outside the database which is file-based. That is also replicated but the process wait for the file to be written first. So, asynchronous really but given the speed at which it happens, it’s almost equivalent to synchronous and probably not going to be an issue.
There are two configuration options:
- Basic – which means it’s a simple deployment of two nodes within the same vCenter deployment
- Advanced – used with other scenarios e.g. the passive node is deployed in some other vCenter deployment/site so requirements might be different
Another good thing is that if DRS is available, the mechanism can make use of it and create rules to keep the node separate.
The aim was to keep it simple and quick to deploy and I think, VMware has succeeded in doing that here.
VMware Update Manager
Since many deployments have moved or are trying to move to a VCSA-based model, the one major thorn in their side was having to install and manage a Windows server just for Update Manager. That’s not only extra effort but also loss of a Windows license. Great news is that it’s no longer required. It’s all now part of the same appliance!
When a Windows-based vCenter server is migrated to become VCSA, Upgrade Manager for that environment (regardless if it’s internal or external) gets imported into the appliance too. All configuration is kept so no further configuration is required.
This is a feature which everyone was really waiting for and thankfully, it has arrived.
Improved Appliance Management
VAMI (Virtual Appliance Management Interface) is the main interface for all management functions for the appliance. In previous versions, one couldn’t do much apart from setting a few options from it but now, it’s responsible for not only configuration options but vCenter can be actively monitored through that interface too.
For example, one can see CPU, Memory statistics. Also, now that Update Manager is also being integrated into the same appliance, database monitoring is pretty important. One can monitor those important charts and metrics, straight from the VAMI itself.
As you can see in the screenshot, there are different metrics and charts that one can view from the VAMI itself and take appropriate action. Because these functions are handled by the appliance now, it can take some actions on its own. For example, you get a warning once the disk space hits 80% utilisation and the server shuts itself down when it goes up to 95%. This is pretty handy for saving the server from database corruption, resulting because of lack of disk space.
vMon is a new enhanced watchdog service being introduced, which keeps a close eye on running services. It takes remedial action on any misbehaving services and is especially important to the new HA capabilities being introduced with this version as it decides which one is Primary and which one is Secondary.
Backup and restore of VCSA and PSO appliances is also handled directly on the appliance now. It’s all internal to the appliance (and hence “native”) and no third-party solution is required to make it work. Typically, effectiveness of third-party software relies on how well they knows inner workings of a product. One would expect VMware to know that better than anyone else and therefore, it can only be a good thing. Backups will be checked for consistency so that they’re good for restore, whenever required.
The process is supported for both internal and external VCSA/PSC deployments. For transfer protocol, HTTP/S, FTP/S and SCP are supported. Plus, there are encryption options too. The best feature, in my view, is that you can ask the restore process to deploy a new OVF and restore the backup on top of that, thereby recovering the vCenter appliance with exactly the same personality and configuration as the original one. That massively simplifies and accelerates the restore process, should the appliance runs into an unrecoverable issue.
I hope that this article has shown that VMware is indeed putting the hours into improving the VCSA experience and with this version, it has even gone beyond feature-parity. The shortcomings of the appliance have disappeared and given the simplicity of its deployment but also now the recovery options, I think there’s no compelling reason to deploy the Windows variant anymore.
Disclaimer: As of writing (October 17, 2016), this information is correct and while it’s hard to imagine these features to change between now and release, there is always a possibility.