Laying the foundation for a vCenter deployment
VMware vCenter can be deployed as a Linux-based appliance or it can be installed on a machine running a supported version of Microsoft Windows. There are no real capacity or performance differentiators between both the deployment types. However, the Linux-based vCenter appliance does not support the use of an external Microsoft SQL database, owing to the fact that there are no supported Microsoft SQL drivers for Linux yet.
There is always a reason behind why an architect would choose either of the two deployment methods. Here, we will try to visit some of those aspects first before we delve deeper into the possible deployment models.
vCenter Appliance versus vCenter on Windows
We have categorized the design decisions into the following five categories:
- Ease of deployment
- Server management
- Choice of database
- Backup and recovery
- Cost of licensing
Ease of deployment
The vCenter Server Appliance (VCSA) comes packaged with all the services required for the vCenter to run. The Platform Services Controller is also embedded into the appliance. Hence the deployment is only a matter of a few clicks and your vCenter virtual machine will be up and running. The deployment of VCSA is quicker than the Windows-based installation, since all the services are already installed and ready to be configured. The Linux-based version of vCenter comes only in the form of an appliance and therefore cannot be installed on a physical machine:
vCenter for Windows has to be installed on a machine (VM or physical) running a supported version of Microsoft Windows. In most environments, this requires identifying a supported hardware (if physical) and then installing a supported version on Windows. If the vCenter was intended to be running on a virtual machine, then you will need to create a new virtual machine and install a supported version of Windows on it. Once you have the machine (VM or physical) ready, you will then have to go through the process of running the Windows-based installer to finish the installation:
The Windows-based install is expectedly time consuming when compared to a VCSA deployment because every required service will be have to be installed and configured for the installation to complete.
Server management
Like with any asset hosting a service in a modern day data center, the vCenter machine will also have to be managed and monitored for stability and optimal performance. Ease of server management is a debatable topic and is very dependent on the type of environment and the technical staff managing the environment. For instance, a data center with most of its services hosted on Windows would prefer vCenter installed on Windows. Likewise, a data center with a predominant Linux footprint would prefer deployment of the Linux-based appliance. Therefore, the decision to choose between the VCSA and a Windows-based installation can only be an outcome of a discussion with the stakeholders.
Backup and recovery
Like with any other business application, the vCenter server and its data should be backed up.
The Windows version of vCenter will require you to backup the database separately. If vCenter is running in a VM then it can also be backed up like any other virtual machine in the environment.
The backup of VCSA will depend on factors such as the PSC deployment mode, use of embedded vPostgres, or an External Oracle database. If you have deployed VCSA with an embedded database and embedded PSC, then either full VM backup will help. If you are using an external PSC then they should be backed up separately.
You can also backup and restore the embedded vPostgres database. The VMware knowledge base article 2091961 covers the backup and restore of the vPostgres database. Here is the URL: https://kb.vmware.com/kb/2091961.
The vCenter appliance also has built-in integration with VMware vStorage APIs for Data Protection (VADP). So you could even use vSphere Data Protection (VDP) or any other backup product that uses VADP to backup and restore VCSA.
The choice of database
The choice of database will again depend on the current organizational standards and the size of the environment. If the design were to be for a smaller environment you could choose to use the default embedded vPostgres database which is limited to 1000 ESXi hosts and 10000 virtual machines. Larger environments would require the use of an external Oracle or Microsoft SQL database.
If an organization uses Oracle to host databases for all their applications, then they may choose not to spend on licenses for a Microsoft SQL server. The Oracle database can be used with either the VCSA or vCenter's Windows version.
However, if the organization uses Microsoft SQL for all its applications then they could decide not to spend on the license required to host an Oracle database, hence leaving them with no choice other than the use of vCenter for Windows. VCSA does not support the use of Microsoft SQL server for hosting its database, hence it cannot be used in such an environment.
Cost of licensing
The main cost advantage of using VCSA is that it does not require operating system licensing. All Windows machines hosting VMware products or solutions need to be licensed. The cost of licensing would still be debatable and the choices can vary. For instance, in a large enterprise, the cost of Windows server licensing may not be significant since Windows Server Datacenter licensing may be used for the hosts.
Deploying vCenter and its components
Once a design decision regarding the type of vCenter to be used in the environment has been made, it is important to plan how vCenter and its components are laid out for better management and performance. Some design decisions play a major role in how flexible or scalable the resultant infrastructure can be. In this section, we will try to understand the possible deployment methods and the rationale behind the choice of a particular method.
With vSphere 5.1 and 5.5, the Single Sign-On component played a major role in design decisions. With vSphere 6.0, it is still the SSO, but since it is now embedded into the Platform Services Controller, the PSC now dictates the deployment methods and optimal and recommended limits.
vCenter 6.0 can now be deployed in two modes:
- vCenter with an embedded PSC, wherein both the vCenter server software and the PSC are installed on the same machine. This mode is possible with both vCenter for Windows and the VCSA:
- While in, embedded mode, the PSC can still be joined to existing the PSC domain.
- vCenter with an external PSC, wherein the Platform Services Controller is installed onto a separate machine. Again, this is possible with both vCenter for Windows and VCSA:
The PSC can become a single point of failure if it is not protected. If a PSC becomes unavailable, then the vCenter or the components which were using the PSC would not be able to allow new connections or user sessions. Already active connections or sessions would continue to remain active. The same applies to the vCenter service as well. If for any reason the vCenter service is stopped then you would not be able to restart it without the PSC being available.
You can have more than one PSC deployed for a set of vCenters, they sync data between them, but high availability is not built into them. This means that, if one of the PSCs fail for any reason, the existing ones would not take over the role of the failed PSC. To achieve high availability, you will need to put the PSC nodes behind a network load balancer. The PSC VMs should be in an HA-enabled cluster for increased resiliency:
Note
Keep in mind though, that when you pair the PSCs for high availability, it should be of the same type: VCSA-based or Windows-based.
Here is a list of some of the configuration maximums:
Understanding the hardware and software requirements
The hardware requirement for both vCenter-Windows or the vCenter appliance will change based on the deployment type. The following table shows the CPU and memory requirements per deployment type:
The vCenter or the Platform Services Controller can be installed on a machine running 64-bit Windows 2008 R2 or later.
Here is a list of supported Windows operating systems:
- Microsoft Windows Server 2008 Service Pack 1 64-bit
- Microsoft Windows Server 2008 R2 64-bit
- Microsoft Windows Server 2008 R2 - Service Pack 1 64-bit
- Microsoft Windows Server 2012 64-bit
- Microsoft Windows Server 2012 R2 64-bit
The Linux-based appliance does not require OS level life cycle management by the customer. VMware manages all the updates and compatibility. So, every time VMware makes a Linux appliance, it will certainly be running a supported and compatible version of Linux. The appliance is based on SUSE Linux Enterprise 11.