Architecture pattern for single site vCenter Server deployment topologies

Single-site vCenter Server deployment

Single-site deployment is the most common use case and network deployment pattern. This pattern uses a single VCF for Classic - Automated instance. It is also highly scalable and easier to manage and expand.

The following diagram shows an example of a customer deployment by using the standard topology. You can add more hosts or new clusters to scale the solution.

1. The vCenter Server automation deploys an initial vSphere cluster, which includes a vCenter, three NSX managers, and an Active Directory deployment. They run either on a single IBM Cloud Classic Virtual Server Instance or two VMware VMs in an HA deployment. The initial vSphere cluster is deployed on the initial IBM Cloud data center location. This vSphere cluster also hosts NSX edge transport node VMs for services and workload NSX edge clusters. The workload NSX edge cluster is purpose for your workloads, while the services NSX edge cluster is used by optional add-on services. You can expand the capacity of this vSphere cluster by ordering new hosts through IBM Cloud for VMware Solutions portal.
2. If you select an optional gateway cluster, the vCenter Server automates two ESXi hosts by using IBM Cloud bare metal server and forms a new vSphere cluster in your deployment. These ESXi hosts can be used to host, for example, Juniper vSRX virtual router and firewall appliances. This cluster hosts also behave such as IBM Cloud gateway appliance, which allows you to assign and route VLANs through the router or firewall that is hosted on the cluster.
3. You can add new vSphere clusters to increase the compute capacity for your workloads. You can add vSphere clusters with different host specifications, and define how to functionally position these clusters and what workloads are run on each cluster.
4. You can add NFS based IBM Cloud File Storage for Classic to your clusters. You can add one or more file shares and configure them individually by selecting the performance (IOPS) and size (GB) for each.
5. You can also use vSAN™ with your vSphere clusters. When you are using vSAN, due to the nature of dedicated local storage, you must select the vSAN option when you order the cluster.
6. The hosts in the specific data center or POD are attached to VLANs and subnets that are local to that IBM Cloud data center or POD. These VLANs and subnets cannot be extended or moved to other IBM Cloud data centers. However, these subnets can communicate with subnets that are provisioned to another IBM Cloud center over IBM Cloud private network.

Extending a single-site vCenter Server deployment to another data center

Single-site deployment can be expanded to another IBM Cloud data center by provisioning new clusters on a different IBM Cloud data center location.

The following diagram shows an example of a customer deployment by using this deployment topology.

1. The vCenter Server automation deploys an initial vSphere cluster, which includes a vCenter, three NSX managers, and an Active Directory deployment. They run either on a single IBM Cloud Classic Virtual Server Instance or two VMware VMs in an HA deployment. The initial vSphere cluster is deployed on the initial IBM Cloud data center location. These management workloads are not moved from their original location.
2. You can add new vSphere clusters to increase the compute capacity for your workloads in a different IBM Cloud data center location. By default, your workloads can communicate by using NSX overlay segments and you can connect them to the physical network through the initial location. If you want to use the physical connectivity through the new location to access IBM Cloud private or public networks, you must manually customize the NSX topology.
3. If you select an optional gateway cluster on this new location, the vCenter Server automates two ESXi hosts by using IBM Cloud bare metal server and forms a new vSphere cluster in your deployment. These ESXi hosts can be used to host, for example, Juniper vSRX and they also behave such as IBM Cloud gateway appliance.
4. You can add more vSphere clusters on this secondary location. You can add vSphere clusters with different host specifications, and define how to functionally position these clusters and what workloads are run on each cluster.
5. You can add NFS based IBM Cloud File Storage for Classic to your clusters in the new data center location. These NFS shares are local to the data center, and they cannot be accessed from the initial data center.
6. You can also use vSAN with your vSphere clusters in the new data center location. When you are using vSAN, due to the nature of dedicated local storage, you must select the vSAN option when you order the cluster. This deployment pattern does not offer stretched vSAN clusters.
7. The hosts in the new data center (or POD) are attached to VLANs and subnets that are local to that IBM Cloud data center or POD. These VLANs and subnets cannot be extended or moved to other IBM Cloud data centers. However, these subnets can communicate with subnets that are provisioned to another IBM Cloud data center over IBM Cloud private network.

If you deploy clusters or hosts in another POD of the same IBM Cloud data center, you must use the same backend NFS storage. The storage is assigned for each cluster separately.

Considerations for single site vCenter Server deployment topologies

When you are designing or deploying this architecture pattern, take the following information into consideration:

• You have several options to expand the capacity for the deployment, for example by provisioning new hosts on the initial cluster or by adding new clusters.
• This pattern provides a few examples of how to expand and customize the initial deployment for a few use cases to fit your needs, but note that these are just examples.
• Note any VMware limitations.

To customize the NSX overlay topologies, see the architecture pattern for single site NSX topologies.

Related links

• vCenter Server overview
• Architecture pattern for single site NSX topologies