Properly sizing a network pool is critical to prevent future issues in the environment due to insufficient IP addresses. Care must be taken when defining the subnets for a network pool as the subnet cannot be changed after it is deployed. The scope of IP addresses used from the defined subnet can be limited by the definition of one or more inclusion ranges. Thus, it is recommended that you begin with defining a larger subnet than what is initially required and utilize the inclusion ranges to limit use. This will provide you the capability to grow with demand as needed.

You begin sizing a network pool by determining the number of hosts that you will have in each vSphere cluster. A VI workload domain must contain a minimum of one vSphere cluster, with a minimum number of three hosts. The exception to this rule is the management workload domain, which requires a minimum of four hosts. This allows for an additional level of availability for the critical infrastructure components. A vSphere cluster can be expanded to the maximum number of hosts supported by vCenter, which is currently 64 hosts.

Allocate a minimum of one IP address per host plus enough additional IP addresses to account for growth and expansion of the environment. Ensure that the subnet defined provides enough unused IP addresses and that appropriate inclusion ranges are defined. Note that some of the IP addresses within the subnet will be used for other purposes, such as defining the gateway address, firewalls, or other entities. Use care not to conflict with these addresses.

Here are some important considerations for determining the size of your network pool:
  • Type of network architecture
  • Physical switch details
    • Are they managed or non-managed?

      Do they support layer-3? (this may require a license)

      Number of ports

  • Where the network switches are placed (at the top of the rack or at the end of a row)
  • Where the default gateway is created
  • Number of hosts that can be placed in each rack or layer-2 network domain
  • Number of hosts required in a vSphere cluster
  • Whether the network switches will be shared with non-VMware Cloud Foundation hosts
  • Number of workload domains you plan on creating