5.5 Compute Host Sizing – Scale-Up Compared with Scale-Out
When it comes to sizing hosts to meet the service provider’s requirements for CPU, memory, and network throughput, there are two basic strategies:
• The “scale-up” approach (fewer hosts, but larger in capacity)
• The “scale-out” approach (greater in number, but lower in capacity)
The scalability of the hypervisor platform will determine the level of consolidation that can be achieved, as well as the underlying design of the compute layer. When examining host hardware choices, there are several key characteristics that influence the design:
• The number of physical CPUs (cores) and the virtual CPU-to-physical CPU ratio, which will impact the number of tenant virtual machine workloads.
• The amount of supported memory.
• The expandability, including the number and type of I/O cards for network and storage connectivity—the key factor in the amount of bandwidth available to a host.
• The number and size of storage devices and storage controllers, particularly relevant in a hyper-converged or vSAN architecture.
• The virtual machine consolidation ratio will be the definitive limit for host scaling.
A design strategy on the scale-out or scale-up approach will be made based on weighing the advantages and drawbacks of each option against the service provider’s design requirements. Each strategy has its pros and cons as described in the following table.
Table 2. Scale-Up Compared with Scale-Out
Scale-Up Strategy | Scale-Out Strategy |
• Uses a fewer number of servers, but each server has greater capacity (more cores more RAM, and so on) • Because of the greater capacity, each server will typically run more virtual machines • Typically means a higher virtual machine-to-core ratio • Also might mean more virtual machines will be affected by an issue with a single host • Typically uses rackmount servers • Might provide benefits in power/cooling density • Can also provide additional expandability | • Uses a greater number of servers, but each server is smaller in capacity • Due to fewer resources per server, the number of virtual machines on each server is usually fewer • The result is often lower virtual machine-to-core ratios • Fewer virtual machines are affected by an issue involving a single host • Can involve blade or rackmount servers. Blade servers can help in situations with limited physical space which might also potentially offer manageability benefits |
Typically, this hardware choice is transparent to the consumers. From the perspective of the tenant’s virtual machines, the host must provide enough virtual CPUs and virtual memory to facilitate the virtualization of the guest operating system and running applications.
If the design includes the use of the Sphere HA mechanism (which will almost certainly be the case, particularly for upper tier offerings), be sure to weigh the hosts’ capabilities against the clusters’ capabilities. For instance, because a limitation of 64 hosts per cluster exists in vSphere 6, the amount of resources available will be capped, although as discussed further in the cluster design section of this document, this is not a factor that will typically limit any design. The reason for this is that it is considered a good practice that standard compute configurations for the host design include the same blade or rackmount server type within each cluster. If possible, set up each cluster to span across chassis’ or server cabinets to maximize availability. Therefore, very large clusters might not offer the levels of availability that a more determined building block approach to cluster design will achieve.