Selecting an appropriate vCenter Server topology and the kind of vCenter Server installation (Windows-based or Appliance-based) is not always an obvious choice. The design considerations below should help you weigh the various design factors that may affect your own design and implementation.
You may face operational constraints inherited from the organization structure such as separate teams managing the environment based on geographical or other boundaries (think region, country, state, but also line of business, subsidiaries…). A corollary to this may be the security policy and existing trust relationships between these entities. When joining vCenter servers in Linked mode all security groups on each server will be added to the other servers as well. Make plans for proper RBAC (Role-Based Access Control) with vCenter Server permissions as necessary. Certain industries (such as finance) may be subject to strict legislation or regulations. You may encounter constraints to deploy management islands for offshore locations or specific markets. Single-Sign-On (SSO, out of scope in this document) has also to be factored into your design.
Corporate policies may significantly impact your design. You may be constrained to a specific OS choice, which will impact not only the flavor and version of vCenter Server you may want to deploy, but also the features that are available to you. In some cases you will be bound to a specific database vendor which will have a cascading impact not only on the kind of vCenter Server you will deploy, but also other requirements such as vCenter Server High Availability at the application and database levels. If Microsoft SQL Server is the only allowed database system, then you will have to review any plans to use the vCSA (vCenter Server Appliance). If you are using vCenter Server 5.5 you may configure it to use Microsoft SQL Clustering Service as it is officially supported. Similarly, you may use Oracle RAC to provide high availability to your vCSA database, but you will have to pay attention to the Oracle RAC version. On the other hand, the vCSA combined with the embedded database reduce complexity when implementing backup, disaster recovery and high availability since you need to take care only of one virtual machine which hosts the application and database side by side. This of course provided that you fit within the hosts/virtual machines limits (they were extended to 100 hosts and 3000 VMs in the vCSA 5.5).
Operational requirements such as the IT team skills and established procedures are another factor to consider. Junior IT specialists may have the habit of working with specific plug-ins for a variety of tasks (such as disk provisioning plug-ins) and may not have the required knowledge of advanced disk array management tools. In such case you should consider which vCenter flavor to use, as vCSA does not support some plug-ins. If storage provisioning is performed by another team then there is no reason to deploy vCenter on Windows of vCenter if vCSA fits all your requirements.
You may also be bound by vCenter Server limits. If your target number of hosts or VMs exceeds vCenter Server limits, you will have to consider if a Linked mode topology isn’t the way to go. If for any reason you planned to use the vCSA you will have to review your plans, as the vCSA does not supports Linked mode.
Infrastructure Management Best Practices
You may have a policy in place or a best practice that states how management services must be deployed. Some organizations will prefer to virtualize vCenter Server within a dedicated resource pool for Infrastructure VMs.
Other organizations may want to run these Infrastructure VMs on a separate, dedicated virtual infrastructure, or even on physical server. In each case, you will have to take in consideration what options are available to you to guarantee that the requirements (and SLAs) will not be violated. vCenter Server placement will also have an impact on the backup and recovery solution you will implement and on its licensing.
High availability plays also its own role in deploying vCenter Server. If deploying on a virtual environment we can forget about VMware Fault Tolerance since vCenter Server requires 2 vCPUs and VMware FT supports only 1 vCPU. It might work but it is not a supported solution, therefore you should not deploy this in production. VMware announced some time ago that they were able to implement FT in a multiprocessor environment, therefore this might change in the future. If your budget is tight you may want to rely on VMware HA and a backup/recovery solution. If you’re not constrained by budget you consider the VMware vCenter Server Heartbeat product. vCenter Server Heartbeat allows you to provide high availability in a variety of scenarios (including P2V, V2V and P2P) but the flipside of the coin is that it does not supports vCSA as it is a Windows-based service. Take also in consideration that a P2P deployment of vCenter Server Heartbeat will require a dedicated backup solution, which may incur additional costs if you previously relied only on a virtual infrastructure backup solution.
Some VMware products may have incompatibilities with a specific flavor or version of vCenter Server. Although the latest releases have been adding more and more features, you may find yourself forced to use the Windows installation to satisfy a specific requirement. Examples are VUM (vCenter Update Manager), which is compatible with vCSA but does not comes bundled within the vCSA. You will need a separate Microsoft Windows Server and a dedicated SQL database to run VUM, which can then be linked to the vCSA. Other incompatibility examples can be running the latest VMware View version on an older version of vCenter Server.
Finally let’s not forget the financial constraints. Providing high availability with vCenter Server Heartbeat may not be affordable for all organizations. Some organizations will prefer to use a single vCenter Server to cut licensing costs vs a Linked mode design. Global organizations may have a virtual team spread across the globe to manage their global infrastructure in a “follow-the-sun” model where Linked mode single-pane-of-glass approach will fit their requirements.
Once you have gathered all the constraints and requirements, be sure to check the VMware Product Interoperability Matrix to avoid any hidden incompatibility in your design.
Appendix 1 – Simplified Feature Compatibility Matrix