This chapter presents the following topics:
Overview ... 33 Reference workload... 33 Scalability ... 34 VSPEX building blocks ... 34 Configuration guidelines ... 37
Overview
This chapter provides definitions of the reference workload used to size and implement the VSPEX architectures. Sizing the environment includes designing the nodes that will be used for the ScaleIO environment and specifying the number of those nodes. This section provides findings from the EMC Solutions group on how variations in node size and number impact the maximum number of supported servers. The virtual machines used in this section correspond to the VSPEX definitions of those workloads.
Reference workload
When you move an existing server to a virtual infrastructure, you can gain efficiency by right-sizing the virtual hardware resources assigned to that system.
Each VSPEX Proven Infrastructure balances the storage, network, and compute resources needed for a set number of virtual machines, as validated by EMC. In practice, each virtual machine has its own requirements that rarely fit a predefined idea of a virtual machine. In any discussion about virtual infrastructures, you need to first define a reference workload. Not all servers perform the same tasks, and it is impractical to build a reference that considers every possible combination of workload characteristics.
To simplify sizing the solution, this section presents a representative customer reference workload. By comparing the actual customer usage to this reference workload, you can determine how to size the solution.
VSPEX Private Cloud solutions define a reference virtual machine (RVM) workload, which represents a common point of comparison. This workload is described in Table 3.
Table 3. VSPEX Private Cloud workload
Parameter Value
Virtual machine OS Windows Server 2012 R2
Virtual CPUs 1
Virtual CPUs per physical core (maximum) 4
Memory per virtual machine 2 GB
IOPS per virtual machine 25
I/O Pattern Fully random skew = 0.5
I/O read percentage 67%
Virtual machine storage capacity 100 GB
This specification for a virtual machine is not intended to represent any specific application. Rather, it represents a single common point of reference against which other virtual machines can be measured.
Scalability
ScaleIO is designed to scale from three to a large number of nodes. Unlike most traditional storage systems, as the number of servers grow, so does capacity, throughputs, and IOPS. The scalability of performance is linear for the growth of the deployment. Whenever additional storage and compute resources (such as servers and drives) are needed, you can add them modularly. Storage and compute resources grow together so that the balance between them is maintained.
VSPEX building blocks
Sizing the system to meet the virtual server application requirement is a complicated process. When applications generate I/O, server components, such as server CPU, server DRAM cache, and disks, will serve that I/O. Customers must consider various factors when planning and scaling their storage system to balance capacity,
performance, and cost for their applications.
VSPEX uses a building block approach to reduce complexity. A building block is one specific server node that can support a certain number of virtual servers in the VSPEX architecture. Each building block combines several local disk spindles to contribute a shared ScaleIO volume that supports the needs of the private cloud environment.
Both SDS and SDC are installed on each building block node to contribute the server local disk to a ScaleIO storage pool and then expose ScaleIO shared block volumes to run the virtual machines.
The configuration of a reference building block includes the physical CPU core number, memory size, and disk spindle number for a server.
Table 4 shows one specific validated node that provides a flexible solution for VSPEX sizing.
Table 4. Building block node configuration Node parameter Target value Notes
CPU 6 cores The Customize the building block section provides more information on how to create building block configurations.
Memory 64 GB According to VSPEX configuration guidelines, this configuration can support up to a maximum of 30 virtual machines.
Disks 6 x 600 GB
10 k RPM SAS
Disk capacity, rather than performance, limits the configuration for a VSPEX Private Cloud.
This configuration contains six SAS disks per node. The validated solution modeled these drives at 600 GB each. For the private cloud workload definition, we were limited more by drive capacity than by drive IOPS. With this configuration, up to 12 virtual machines can be supported by one building block.
Building blocks approach
Validated building blocks
Reference building blocks are a starting point to plan a virtual infrastructure. In this section, we will discuss customizing building block nodes to meet specific customer needs.
The node configuration shown in Table 6 defines the CPU, memory, and disk
configuration for one server. However, ScaleIO is infrastructure-agnostic and can run on any server. This solution also provides more options for the building block node configuration. You can redefine a building block with different configurations, but after the building block configuration is redefined, the virtual machine number that the building block can support is also changed.
To calculate the virtual machine that the new building block can support, we must consider the following components:
CPU capability
For VSPEX systems, we recommend a maximum of 4 vCPUs for each physical core in a virtual machine environment. For example, a server node with 16 physical cores can support up to 64 virtual machines.
Memory capability
When sizing the memory for a server node, the ScaleIO virtual machine and hypervisor must be considered. We tested a ScaleIO virtual machine that consumes 3 GB of RAM, and reserves 2 GB RAM for the hypervisor. We do not recommend using memory overcommit in this environment.
Note: ScaleIO 1.3 introduces a new RAM cache feature by using the SDS server RAM.
By default, the RAM size of the ScaleIO virtual machine is set to 3 GB and 128 MB of the RAM uses the SDS server RAM cache. Add the RAM size to the 3 GB of the ScaleIO virtual machine if more RAM cache is used.
Disk capacity
ScaleIO uses a RAIN topology to ensure data availability. In general, the capacity available is a function of the capacity per node (formatted capacity) and the number of nodes available.
Assuming N nodes and C TB of capacity per server, the storage available, S, is:
𝑆 =(𝑁 − 1) ∗ 𝐶 2
This formula accounts for two copies of data and the ability to survive a single node failure. The values in Table 5 assume sufficient CPU and memory resources for each node.
Customize the building block
Table 5. Maximum number of virtual machines per node in three-node cluster environment, limited by disk capacity
Disk capacity (GB)
Disks per node
3 4 5 6 7 8 9 10
600 6 8 10 12 14 16 18 20
900 9 12 15 18 21 24 27 30
1200 12 16 20 24 28 32 36 40
1500 15 20 25 30 35 40 45 50
IOPS
The primary method for adding IOPS capability to a node without considering cache technologies is to increase the number of disk units or increase the speed of those units. Table 6 shows the number of virtual machines supported with 4, 6, 8, or 10 SAS drives per node, limited by disk performance.
Table 6. Maximum number of virtual machines per node, limited by disk performance 10 K SAS drives Number of virtual machines
4 20
6 30
8 40
10 50
Note: The values in Table 6 assume that the CPU and memory resource of each node are sufficient.
Determine the maximum number of virtual machines on the building block node With the entire configuration defined for the building block node, we calculate the number of virtual machines that each component can support to find out the number of virtual machines that the building block node can support.
For example, consider the redefined building block configuration in Table 7.
Table 7. Redefined building block node configuration example
Physical CPU cores Memory (GB) 10 K SAS drive capacity
16 128 10 * 1500 GB
As a result, the calculations in Table 8 are applied, giving a new supported virtual machine count for this node.
Table 8. Node sizing example
The final number that this building block node can support is 24 virtual machines, which is the minimum number for the CPU, memory, and disks according to the calculation results.
Figure 15 shows how to determine the maximum number of virtual machines that a customer redefined building block configuration can support.
50 virtual machines support CPU
RAM
IOPS
64 virtual machines supported by CPU 61 virtual machines supported by memory 50 virtual machines supported by disk IOPS
Capacity 50 virtual machines supported by disk Capacity
Figure 15. Determine the maximum number of virtual machines that a building block configuration can support
Configuration guidelines
To choose the appropriate reference architecture for a customer environment, determine the resource requirements of the environment and then translate these requirements to an equivalent number of reference virtual machines that have the characteristics defined in Table 4. This section describes how to use the worksheet to simplify the sizing calculations and additional factors you should take into
consideration when deciding which architecture to deploy.
The Customer configuration worksheet helps you to assess the customer environment and calculate the sizing requirements of the environment.
Table 9 shows a completed worksheet for a sample customer environment. Appendix B provides a blank worksheet that you can print and use to help size the solution.
Physical attribute VMs supported Calculation
CPU cores: 16 64 16 cores * 4 VMs per core = 64 VMs
Table 9. Customer configuration worksheet example
Server resources Storage resources
Application CPU
Total equivalent reference virtual machines 14
To complete the worksheet:
1. Identify the application planned for migration into the VSPEX private cloud environment.
2. For each application, determine the compute resource requirements for vCPUs, memory (GB), storage performance (IOPS), and storage capacity.
3. For each resource type, determine the equivalent reference virtual machines requirements—that is, the number of reference virtual machines required to meet the specified resource requirements.
4. Determine the total number of reference virtual machines needed from the resource pool for the customer environment.
Determine the resource requirements
Consider the following when you determine resource requirements:
CPU
The reference virtual machine outlined in Table 3 assumes that most virtual machine applications are optimized for a single CPU. If one application requires a virtual machine with multiple vCPUs, modify the proposed virtual machine count to account for the additional resources.
Memory
Memory plays a key role in ensuring application functionality and performance. Each group of virtual machines will have different targets for the available memory that is considered acceptable. As with the CPU calculation, if one application requires additional memory resources, adjust the number of planned virtual machines to accommodate the additional resource requirements.
For example, if there are 30 virtual machines, but each one needs 4 GB of memory instead of the 2 GB that the reference virtual machine provides, plan for 60 reference virtual machines.
IOPS
The storage performance requirements for virtual machines are usually the least understood aspect of performance. The reference virtual machine uses a workload generated by an industry-recognized tool to run a wide variety of office productivity applications that should be representative of the majority of virtual machine implementations.
Storage capacity
The storage capacity requirement for a virtual machine can vary widely depending on the type of provisioning, the types of applications in use, and specific customer policies.
Determine the equivalent reference virtual machines
With all of the resources defined, determine the number of equivalent reference virtual machines by using the relationships listed in Table 10. Round all values to the closest whole number.
Table 10. Reference virtual machine resources
Resource Value for reference virtual machine
Relationship between requirements and equivalent reference virtual machines
CPU 1 Equivalent reference virtual machines =
Resource requirements
Memory 2 Equivalent reference virtual machines =
Resource requirements/2
IOPS 25 Equivalent reference virtual machines =
Resource requirements/25
Capacity 100 Equivalent reference virtual machines = Resource requirements/100
For instance, Example 2 in Table 9 requires 4 CPUs, 16 GB of memory, 200 IOPS, and 200 GB of storage. This translates to four reference virtual machines for CPU, eight reference virtual machines for memory, eight reference virtual machines for IOPS, and two reference virtual machines for capacity, as shown in Table 11.
Table 11. Example worksheet row
Use the highest value in the row to complete the Equivalent reference virtual
machines column. As shown in Figure 16, the example requires eight reference virtual machines (RVMs).
Figure 16. Required resource from the reference virtual machine pool
The number of reference virtual machines required for each application type equals the maximum number required for an individual resource. For example, the number of equivalent reference virtual machines for the application in 0 is eight, as this number will meet all of the resource requirements for IOPS, vCPU, and memory.
Determining the total number of reference virtual machines
After the worksheet is completed for each application, the total number of reference virtual machines required in the resource pool is the sum of the total reference virtual machines for all application types. In the example in Table 9, there are a total of 14 reference virtual machines.
The VSPEX ScaleIO private cloud building block defines specific server node sizes. For example, a node defined in Table 4 supports 12 reference virtual machines. The total reference virtual machines value from the completed worksheet indicates which reference architecture would be adequate for the customer’s requirements. For example, as shown Table 4, if the customer requires 50 virtual machines of capability, six building blocks (5+1, reserve 1 building block for high availability) provide sufficient resources for current needs and room for growth.
Calculating the building block requirement
Table 12 shows the example of scaling for the baseline building block node configurations (as defined in Table 4) and redefined building block node configurations (as defined in Table 7).
Table 12. Node scaling example Node
number
Maximum number of virtual
desktops on baseline building block
Maximum number of virtual desktops on redefined building block
2+1 24 100
In most cases, the Customer configuration worksheet recommends a reference architecture that is adequate for the customer’s needs. In other cases, you might want to further customize the hardware resources. A complete description of the system architecture is beyond the scope of this guide.
Storage resources
In some applications, there is a need to separate some storage workloads from other workloads. The node configuration for the reference architectures places all of the virtual machines in a single resource pool. To achieve workload separation, deploy additional disk drives for each group that needs workload isolation and add them to a dedicated pool.
Do not reduce the number of disks in the node to support isolation or to reduce the capability of the pool without additional guidance beyond this guide. We designed the node configuration for the solution to balance many different factors, including high availability, performance, and data protection. Changing the components of the node can have significant and unpredictable impacts on other areas of the system.
Server resources
For the server resources in this solution, it is possible to customize the hardware resources more effectively. To do this, first summarize the resource requirements for the server components, as shown in Table 13. In the Server resource component totals line at the bottom of the worksheet, add up the server resource requirements from the applications in the table.
Note: When customizing resources in this way, confirm that storage sizing is still appropriate. The Storage component totals line at the bottom of Table 13 shows the required amount of storage.
Fine-tune hardware resources
Table 13. Server resource component totals
Server resources Storage resources
Application CPU
Total equivalent reference virtual machines 66
Server resource component
totals 17 155
Note: Calculate the sum of the resource requirements row for each application, and not the equivalent reference virtual machines, to calculate the server and storage component totals.
In this example, the target architecture requires 17 virtual CPUs and 155 GB of memory. If four virtual machines per physical processor core are used, and memory over-provisioning is not necessary, the architecture requires five physical processor cores and 155 GB of memory. With these numbers, the solution can be effectively implemented with fewer server and storage resources.
Note: Consider high-availability requirements when customizing the resource pool hardware.
The requirements stated in the solution are what EMC considers the minimum set of resources to handle the workloads 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. If the customer virtual servers differ significantly from the reference definition and vary in the same resource group, you may need to add more of that resource to the system.
Summary