The solution described in this document requires a set of hardware to be available for the CPU, memory, network, and storage needs of the system. These are general requirements that are independent of any particular implementation except that the requirements grow linearly with the target level of scale. This section describes some considerations for implementing the requirements.
The solution defines the hardware requirements in terms of four basic types of resources:
CPU resources Memory resources Network resources Storage resources
This section describes the resource types, their use in the solution, and key implementation considerations in a customer environment.
The solution defines the number of CPU cores required, but not a specific type or configuration. New deployments should use recent revisions of common processor technologies. It is assumed that these perform as well as, or better than, the systems used to validate the solution.
In any running system, monitor the utilization of resources and adapt as needed. The reference virtual machine and required hardware resources in the solution assume that there are four virtual CPUs for each physical processor core (4:1 ratio). Usually, this provides an appropriate level of resources for the hosted virtual machines; however, this ratio may not be appropriate in all use cases. Monitor the CPU utilization at the hypervisor layer to determine if more resources are required. Each virtual server in the solution must have 2 GB of memory. Because of budget constraints, in a virtual environment, it is common to provision virtual machines with more memory than is installed on the physical hypervisor server. The memory over- commitment technique takes advantage of the fact that each virtual machine does not use all allocated memory. To oversubscribe the memory usage to some degree makes business sense. The administrator has the responsibility to proactively monitor the oversubscription rate so that it does not shift the bottleneck away from the server and become a burden to the storage subsystem.
Overview
Resource types
CPU resources
96 EMC VSPEX Private Cloud: VMware vSphere 5.5 for up to 1,000 Virtual Machines Enabled by Mircosoft Windows Server 2012 R2, EMc VNX Series, and EMc Powered Backup-Proven Infrastructure Guide
If VMware ESXi runs out of memory for the guest operating systems, paging takes place and results in extra I/O activity going to the vswap files. If the storage
subsystem is sized correctly, occasional spikes due to vswap activity may not cause performance issues as transient bursts of load can be absorbed. However, if the memory oversubscription rate is so high that the storage subsystem is severely impacted by a continuing overload of vswap activity, add more disks for increased performance. The administrator must decide if it is more cost effective to add more physical memory to the server, or to increase the amount of storage. With memory modules being a commodity, it is likely less expensive to choose the former option. This solution is validated with statically assigned memory and no over-commitment of memory resources. If a real-world environment uses memory over-commit, monitor the system memory utilization and associated page file I/O activity consistently to ensure that a memory shortfall does not cause unexpected results.
The solution outlines the minimum needs of the system. If additional bandwidth is needed, add capability to both the storage array and the hypervisor host to meet the requirements. The options for network connectivity on the server depend on the type of server. The storage arrays have a number of included network ports, and can add ports using EMC UltraFlex I/O modules.
For reference purposes in the validated environment, each virtual machine generates 25 IOPS per second with an average size of 8 KB. This means that each virtual
machine generates at least 200 KB/s of traffic on the storage network. For an environment rated for 100 virtual machines, this is calculated as a minimum of approximately 20 MB/sec. This is well within the bounds of modern networks.
However, this does not consider other operations. For example, additional bandwidth is needed for:
User network traffic Virtual machine migration
Administrative and management operations
The requirements for each network depend on how it will be used. It is not practical to provide precise numbers in this context. However, the network described in the reference architecture for each solution must be sufficient to handle average workloads for the previously described use cases.
Regardless of the network traffic requirements, always have at least two physical network connections shared for a logical network so that a single link failure does not affect the availability of the system. Design the network so that the aggregate
bandwidth in the event of a failure is sufficient to accommodate the full workload. The storage building blocks described in this solution contain layouts for the disks used in the validation of the system. Each layout balances the available storage capacity with the performance capability of the drives. Consider a few factors when examining storage sizing. Specifically, the array has a collection of disks assigned to a storage pool. From that storage pool, provision datastores to the VMware vSphere cluster. Each layer has a specific configuration defined for the solution and
documented in the deployment section of this guide in Chapter 5. Network resources
97 EMC VSPEX Private Cloud: VMware vSphere 5.5 for up to 1,000 Virtual Machines Enabled by Mircosoft Windows Server 2012 R2, EMc VNX Series, and EMc Powered Backup-Proven Infrastructure Guide It is acceptable to:
Replace drives with larger capacity drives of the same type and performance characteristics, or with higher performance drives of the same type and capacity.
Change the placement of drives in the drive shelves to comply with updated or new drive shelf arrangements.
Increase the scale using the building blocks with a larger number of drives up to the limit defined in the VSPEX private cloud validated maximums section. Observe the following best practices:
Use the latest best practices guidance from EMC regarding drive placement within the shelf. Refer to Applied Best Practices Guide: EMC VNX Unified Best Practice for Performance.
When expanding the capability of a storage pool using the building blocks described in this document use the same type and size of drive in the pool. Create a new pool for different to use different drive types and sizes. This prevents uneven performance across the pool.
Configure at least one hot spare for every type and size of drive on the system. Configure at least one hot spare for every 30 drives of a given type.
In other cases where there is a need to deviate from the proposed number and type of drives specified, or from the specified pool and datastore layouts, ensure that the target layout delivers the same or greater resources to the system and conforms to EMC published best practices.
The requirements in the reference architecture are what EMC considers the minimum set of resources to handle the workloads required based on the stated definition of a reference virtual server. In any customer implementation, the load of a system varies over time as users interact with the system. Add resources to a system if the virtual machines differ significantly from the reference definition, and vary in the same resource group.
Implementation summary
98 EMC VSPEX Private Cloud: VMware vSphere 5.5 for up to 1,000 Virtual Machines Enabled by Mircosoft Windows Server 2012 R2, EMc VNX Series, and EMc Powered Backup-Proven Infrastructure Guide