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 cluster. A workload domain must contain a minimum of one cluster. As each cluster leverages vSAN for storage, the minimum number of hosts within a cluster is three. The exception to this rule is the management workload domain. It is recommended that the management workload domain contain a minimum of four hosts. This allows for an additional level of availability for the critical infrastructure components. A 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 L3 (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 L2 domain
  • Number of hosts required in a cluster
  • Whether the network switches will be shared with non-Cloud Foundation hosts
  • Number of workload domains you plan on creating