The third installment of this blog series is based on the vSphere Storage Appliance (VSA) 5.1 and the support of remote office/branch office (ROBO) use case. With the release of VSA 5.1 VMware introduced the support and capability for the vSphere Storage Appliance (VSA) to centrally manage implementation across Remote Office/Brach Office (ROBO). This a compelling solution for customers that are required to manage, operate, and maintain ROBO type of environments. Some of the core benefits provided by the VSA are based around the most essential requirements for any business:
Reduce management efforts
Centralized management
Provide, maintain or increase application and infrastructure availability
Cost Reduction
The new features and capabilities introduced with the vSphere Storage Appliance (VSA) 5.1 greatly enhances it’s usability and the scenarios in which it can be deployed. Scenarios where each remote locations has dedicated hardware and the personnel to manage and support the infrastructures individually such as the scenario illustrated below.
VSA Scenario – Multiple Remote Locations with Decentralized Management
The multiple remote location with decentralized management designs are much simpler to deploy. ROBO scenarios where the centralization of management and support for multiple locations requires a different approach as there are more components to be considered in order to successfully deploy the solution.
VSA Scenario – Multiple Remote Locations with Centralized Management
Multisite VSA deployments with centralized management requirements are different from individually localized VSA scenarios as illustrated by the VSA Scenario – Multiple Remote Locations with Decentralized Management diagram above. When the two illustrated designs are compared there are a couple noticeable difference between them:
Number of vCenter Servers
Number of hosts per cluster
VSA Cluster Service (VSACS)
The new VSA 5.1 provides the ability to manage multiple remote or local VSA Clusters from a single vCenter Server. This solution by design is a bit more complex than a single site design because of its requirements.
Remote Site Connectivity – A secure multisite connectivity solution (dedicated, partial, VPN, etc) must be in place for the deployment and management of the VSA Service, VSA Manager, and vSphere required ports. The VSACS ports were covered in part 1 of this blog series.
VSA Cluster Service(VSACS) – The VSA Cluster Service is normally installed as part of the VSA Manager installation and it runs on the vCenter Server but, ROBO scenarios VSA Clusters deployments can be based on a two or three node VSA Cluster configuration. The two node cluster deployments require the use of the VSA Cluster Service. The VSACS has to be deployed on to separate virtual or physical machine and it cannot be hosted on a VSA Cluster member nor it cant be stored on shared storage provided by the VSA Cluster. This is necessary in order to avoid the introduction of a single point of failure to the VSA Clustering architecture as the loss of two voting members of the cluster will render the VSA Cluster unusable. For more detailed information about the VSA Cluster service read part 1 of this blog series.
vCenter Server Storage Placement – In the previous version of VSA VMware did not support the use of any of the resources provided by the VSA Cluster (ESXi Hosts, and NFS datastores) for hosting or storing a vCenter Server virtual machine. In VSA 5.1 those restrictions have been changed. With VSA 5.1 any one host that is a member of a VSA Cluster can be use to provide the compute resources for a vCenter Server virtual machine. From a storage perspective, a single hosts local storage capacity can be use to store the vCenter Server virtual machine.
Recommendations
For two node VSA Cluster deployments consider using a low cost dedicated hardware appliance (low cost PC) or possibly an existing available system for the installation of the VSACS when the requirements to installing the service in a virtual machine can’t be satisfied. The VSACS is only needed for two node VSA Cluster deployments. The VSACS has to reside in the same subnet as the rest of members of the cluster (ESXi Hosts not vCenter Server).
If the VSACS is installed and deployed as a virtual machine (out side of the VSA cluster) make sure to reserve the required amount of resources covered in part 1 of this blog series in order to avoid a service outage due to resource contention.
When using local storage from one of the members of the VSA cluster for the deployment of the vCenter Server virtual machine take into consideration it’s growth capability over time. Make sure to leave enough capacity to accommodate the growth. The storage capacity can now be dynamically increased from the VSA Manager. Depending on management design and the number of remotely managed cites, it maybe a good idea to have vCenter Server in its own dedicated system with dedicated resources outside of the VSA Cluster altogether.
