By having a structured methodology for your scaling operations, you can scale your VMware Validated Design environment with predictable performance and manageability.

Building Block Concept

When scaling, the goal is to deploy infrastructure in a predictable manner so that the impact on the existing management and compute infrastructure is minimized.

With the building blocks method, you increase capacity in fixed increments that have a known performance profile. These building blocks become blueprints for responding to different scaling requirements. They are designed to integrate into the environment with minimal impact on other building blocks or the overall management of the system.

Figure 1. Using Building Blocks for Scaling Your SDDC

You develop building block architectures according to the requirements and preferred scaling methods of your organization. You can also implement several tiers of building blocks as required. For instance, you might have one building block strategy when deploying a new region, a second building block strategy when expanding a region, and a third building block strategy when expanding a workload domain.

Extending the Management Domain

To keep the performance of the management domain at expected levels, you might need to add physical hosts to the management cluster as you deploy building blocks and their associated management virtual machine infrastructure

Monitor the usage levels of the management domain and increase the number of hosts in the management cluster as required.

Network Traffic Per Building Block

When designing your building block, consider the location of the NSX Edge devices for handling the traffic for the additional workloads. Edge devices are responsible for the north-south traffic into and out of the software-defined network (SDN) or between clusters that are in different transport zones.

As you develop the network traffic aspect of your building block design, consider whether:

  • Your building block will involve the deployment of a new workload domain or cluster, or the expansion of an existing cluster.

  • The existing edges and the infrastructure those edges are running on are capable of handling the extra traffic.

  • Your building-block will include a new set of edges to handle traffic for the new workloads.

  • Deploying edges directly onto the new infrastructure itself is more desirable from a separation or performance perspective.

  • The existing infrastructure can continuously scale without negatively impacting existing workloads.

  • Moving workloads horizontally between workload domain clusters without the need to change the IP address of the workloads is required.

See Single Shared Edge Compute Cluster Model, Multiple Shared Edge Compute Cluster Model (Distributed Edges), and Dedicated Edge Cluster Model.

Operations and Cloud Management Per Building Block

As you add building blocks and deploy new workloads to those building blocks, you reach certain scale points where you must scale the management components responsible for collecting the data required for operational and cloud management of the workloads. While designing your building blocks, consider whether scaling the management components needs to be part of the building block design.

When designing the VMware vRealize® Operations Manager™, VMware vRealize® Log Insight™, and VMware vRealize® Business™ aspects of your building block, consider whether:

  • The data collection model supports one of these approaches:

    • Collect data directly using the existing components that reside in the management domain

    • Use a hub-spoke model where dedicated data collection components perform the initial collection and forward that data to the aggregation clusters in the management domain.

  • In a hub-spoke model, you want to place the spoke components in a central location or distribute them across newly created endpoints.

  • You can centralize spoke components without causing contention for resources in the existing management infrastructure.

  • The scope of your building block determines your direction. Different scopes might determine different topologies.

See Scaling Operations and Cloud Management.

Host Technology and Scope Per Building Block

As you continue to scale your environment, you need to determine the unit of scale. That unit can be adding hosts to an existing cluster, adding clusters, adding workload domains and the associated VMware vCenter Server® instance, or even adding new regions. Because you might decide to use several approaches in an environment, having a known plan for how and when each of the scenarios will be triggered will lead to predictable scaling.

When deciding on the scope of your building block, consider whether:

  • The time period between deployments of building blocks will be longer or shorter.

  • The availability of new hardware with the same specification as existing hardware determines if you can consider adding hosts to a cluster.

  • You have a multi-vendor strategy, or are likely change vendors on a regular basis.

  • You have different types of workloads that require dedicated clusters or dedicated workloads domains to operate efficiently.

See Adding Hosts to a Workload Domain Cluster, Adding Clusters to Workload Domains, Adding Additional Workload Domains, and Adding Additional Regions.

Fault Domains Per Building Block

When deciding on the scope of your building block and the number of fault domains present, consider whether:

  • The building block design alters the ratio of workloads to fault domains as you scale.

    Maintaining that ratio perfectly is not practical because it would require that you deploy a new data center location each time you deployed a building block. However, consider factors such as power, cooling, physical network uplinks, vCenter Server count, traffic flow, and logging so as to keep your fault domain to workload ratio at an acceptable level.

  • The number of workloads that are affected by a failure should be as linear as possible as you scale up your environment.

Over-Subscription Per Building Block

The level of compute over-subscription in a building block must be acceptable and understood. According to VMware Validated Design, the over-subscription ratio for the management and edge components must be equal to or below 2:1 in terms of CPU and memory. For workload domains, maintain a ratio equal to or below 8:1 according to the requirements of the tenants of your organization.

When designing over-subscription into your building block, consider whether:

  • You have a known and understood over-subscription ratio for both your management and workload domains.

  • You actively monitor that subscription ratio. How close the system is to that ratio should be a key metric in determining when an extra building block of capacity needs to be deployed.

  • Your building block design supports easy rebalancing of workloads, when you exceed that over-subscription ratio and you want to redistribute workloads across building blocks.