VMworld has once again landed in Barcelona for its annual European conference and gathering of the geeks. I’ve been a tad quiet these past few weeks as I dove into the vast amounts of content provided by VMware on their upcoming vSphere 6.5 release. In this post, I pick apart the new information being passed by the VMware Technical Marketing team. And, wow, I think you’ll be happy with all of the superb work they are doing!

After talking with the team and seeing what’s going down, I have formed the opinion that the Windows deployment of vCenter Server is definitely a dead man walking. This has largely been lip service paid by VMware in the past because they weren’t actually solving real world problems with the VCSA – it was mostly just something I used for labs. With the VCSA 6.5 release, however, I don’t really see any reason to continue using a Windows deployment of vCenter Server.

At a high level, the VCSA can now be clustered for High Availability, includes VMware Update Manager (VUM), has a ton of new improvements on the VAMI side, and supports native backups and restores.

Let’s dig into these improvments – and many others – in this post.

Deploying and Configuring

The process to install and configure the appliance has also received a major forklift update. The process entails two steps: deploying the OVA (virtual appliance) and then laying down a configuration. New to this version, the deployment process can be done on Windows, Mac, or Linux. The menu has been simplified into Install, Upgrade, Migrate, or Restore.

I think the menu options and support helper language is simple and clean. In the past, VMware has made this sort of process clunky and overly technical, so I gave this a round of kudos to the VCSA team.

It also means that you can use VMware snapshots to provide a rollback for improper configurations – which is a major hallmark of the feature for VMware administrators – in addition to creating templates for automated deployments.

Migration into the VCSA

Migration is supported on the Windows vCenter Server versions 5.5 and 6.0. This makes sense, since they are the only supported versions of vCenter currently available today. The 5.0 and 5.1 releases went into Technical Guidance back in August of 2016. This means that both embedded and external database topologies can be migrated from Windows to the VCSA – including VMware Update Manager (VUM) – and will assume the identity of the previous vCenter Server instance. This includes the UUID, IP address, name, certificates, and so forth.

There’s even options to determine how much data is migrated: just the configuration; configuration, events, and tasks; or configuration, events, tasks, and performance metrics (consumes much more data). If you don’t want performance data, as an example, you can drop this moving forward. It might be wise to do this for use cases in which you’re heading into a hardware and host refresh.

Management and Monitoring

The management interface of the VCSA has received a fresh coat of paint. This means that it is much less of a black box, which was my major pet peve, and offers an administrator a ton of information on network, CPU, memory, and database operations. Below is an example image showcasing the vPostgres Database. In past experiences, solutions were always to “throw more resources” at the VCSA due to lack of understanding of what was going on. I think the monitoring pane will help alleviate this.

Note that the appliance menu also gives configuration options for a remote syslog server. If the appliance finds itself reaching a high water mark it will gracefully shut down to avoid silent corruption. A new watchdog, named vMon, is a service watching all of the vCenter Server Appliance services in order of criticality. It is considered the “source of truth” for VMware’s new High Availability feature for the VCSA.

The team also shared how you’re expected to manage vCenter across a number of different interfaces. Sadly, the Web Client remains based on Adobe Flex and thus requires Flash. Apparently more performance improvements have been made, with the primary goal being to move to the Clarity UI Standard made popular by the HTML5-fueled vSphere Client fling.

I’m glad to hear that the vSphere Client will be integrated into vCenter 6.5 and supports Enhanced Linked Mode. It is also nice to see that 4 out of 5 interfaces for management are using HTML5 and a much cleaner, simpler user experience.

Backup and Restore

Another much needed feature for vCenter is the ability to do application level backups and restores. In the Windows vCenter world, this meant having a full server image of the Windows Server plus a copy of the database. This is because so many files and configuration objects live somewhere within the file system in addition to the database.

With VCSA 6.5, a native option now exists to perform backups over HTTP/S, FTP/S, or SCP. This configuration is abstracted from the server appliance itself, making the VM largely just a shell that contains a configuration. A new OVA can be deployed and an administrator can use the Restore feature to bring back the VCSA to its former configuration state (including the database). This is supported in both embedded and external deployments for both vCenter and the PSC (Platform Services Controller) appliances.

VCSA High Availability Configuration

After the death of vCenter Heartbeat, many of my customers and colleagues were asking how to make vCenter Server highly available. And the answer was – you couldn’t. Not really. And for those who need vCenter to always be available, such as cloud providers, this answer wasn’t all that great. Plus, prior clustering technologies were a real pain to make operational.

With the VCSA 6.5 release, VMware has re-introduced appliance level high availability for vCenter services using what will probably look like a familiar active/passive clustering topology.

To be clear, this feature is not available for the Windows vCenter server.

The most noticeable change in an HA configuration is that each VCSA node will now have two NICs: eth0 for public traffic and eth1 for private traffic. This makes updating the VCSA to support HA relatively simple and non-invasive. VMware asks that eth0 and eth1 use different subnets from one another, but does not require layer 2 adjacency between nodes. You could, for example, use different layer 3 networks for the private network to support multiple data center designs.

How is this done? The VCSA uses synchronous database replication via native vPostgres SQL mechanisms to keep the databases in step. File based replication is also used for replicating changes to specific files within the appliance done asynchronously. Setup is handled by a wizard that was designed from scratch to be incredibly simple for the administrator. The wizard handles most of the work on your behalf.

VMware Update Manager (VUM)

For many, VUM was the last checkbox item on our list to completely migrate away from using Windows Servers for vCenter. Because of this requirement, I often just stood up a small number of Windows Servers for VUM and pointed each one to its respective vCenter Server. With the 6.5 release, the VCSA has finally integrated VUM by default. This includes the use of High Availability – cool!

Based on the comparison above, there doesn’t seem to be any advantages to keeping VUM on a Windows Server any longer.

Thoughts

The VCSA team has really done an outstanding job at taking lots of user feedback and turning the product into something I’m actually excited to use. The Wahl Network lab will be migrating from 6.0 Windows to 6.5 VCSA when the code goes GA! 🙂