EMC VSPEX PRIVATE CLOUD

Transcription

1 Proven Infrastructure EMC VSPEX PRIVATE CLOUD Microsoft Windows Server 2012 with Hyper-V for up to 100 Virtual Machines Enabled by EMC VNXe and EMC Next-Generation Backup EMC VSPEX Abstract This document describes the EMC VSPEX Proven Infrastructure solution for private cloud deployments with Microsoft Hyper-V and EMC VNXe for up to 100 virtual machines using iscsi Storage. March, 2013

2 Copyright 2013 EMC Corporation. All rights reserved. Published in the USA. Published March 2013 EMC believes the information in this publication is accurate of its publication date. The information is subject to change without notice. The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. EMC 2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners. For the most up-to-date regulatory document for your product line, go to the technical documentation and advisories section on the EMC online support website. Part Number H

3 Contents Chapter 1 Executive Summary 13 Introduction Target audience Document purpose Business needs Chapter 2 Solution Overview 17 Introduction Virtualization Compute Network Storage Chapter 3 Solution Technology Overview 21 Overview Summary of key components Virtualization Overview Microsoft Hyper-V Microsoft System Center Virtual Machine Manager (SCVMM) High Availability with Hyper-V Failover Clustering EMC Storage Integrator Compute Network Overview Storage Overview EMC VNXe series Backup and recovery

4 Contents EMC NetWorker EMC Avamar Other technologies EMC XtemSW Cache (Optional) Chapter 4 Solution Architecture Overview 33 Solution overview Solution architecture Overview Architecture for up to 50 virtual machines Architecture for up to 100 virtual machines Key components Hardware resources Software resources Server configuration guidelines Overview Hyper-V memory virtualization Memory configuration guidelines Network configuration guidelines Overview VLAN MC/S Storage configuration guidelines Overview Hyper-V storage virtualization for VSPEX Storage layout for 50 virtual machines Storage layout for 100 virtual machines High availability and failover Overview Virtualization layer Compute layer Network layer Storage layer Backup and recovery configuration guidelines Overview Backup characteristics Backup layout for virtual machines Sizing guidelines Reference workload Overview

5 Contents Defining the reference workload Applying the reference workload Overview Example 1: Custom-built application Example 2: Point of sale system Example 3: Web server Example 4: Decision-support database Summary of examples Implementing the reference architectures Overview Resource types CPU resources Memory resources Network resources Storage resources Implementation summary Quick assessment Overview CPU requirements Memory requirements Storage performance requirements I/O operations per second (IOPs) I/O size I/O latency Storage capacity requirements Determining equivalent Reference virtual machines Fine tuning hardware resources Chapter 5 VSPEX Configuration Guidelines 67 Overview Pre-deployment tasks Overview Deployment prerequisites Customer configuration data Prepare switches, connect network, and configure switches Overview Configure infrastructure network Configure VLANs Complete network cabling Prepare and configure storage array

6 Contents Overview VNXe configuration Provision storage for iscsi datastores Install and configure Hyper-V hosts Overview Install Hyper-V and configure failover clustering Configure Windows host networking Publish VNXe datastores to Hyper-V Connect Hyper-V datastores Plan virtual machine memory allocations Install and configure SQL server database Overview Create a virtual machine for Microsoft SQL server Install Microsoft Windows on the virtual machine Install SQL Server Configure SQL Server for SCVMM System Center Virtual Machine Manager server deployment Overview Create a SCVMM host virtual machine Install the SCVMM guest OS Install the SCVMM server Install the SCVMM Management Console Install the SCVMM agent locally on a host Add a Hyper-V cluster into SCVMM Create a virtual machine in SCVMM Create a template virtual machine Deploy virtual machines from the template virtual machine Summary Chapter 6 Validating the Solution 83 Overview Post-install checklist Deploy and test a single virtual server Verify the redundancy of the solution components Appendix A Bill of Materials 87 Bill of materials Appendix B Customer Configuration Data Sheet 91 Customer configuration data sheet

7 Contents Appendix C References 95 References EMC documentation Other documentation Appendix D About VSPEX 97 About VSPEX Appendix E Validation with Microsoft Hyper-V Fast Track v3 99 Overview Business case for validation Process requirements Step one: Core prerequisites Step two: Select the VSPEX Proven Infrastructure platform Step three: Define additional Microsoft Hyper-V Fast Track Program components101 Step four: Build a detailed Bill of Materials Step five: Test the environment Step six: Document and publish the solution Additional resources

8 Contents 8

9 Figures Figure 1. VSPEX private cloud components Figure 2. Compute layer flexibility Figure 3. Example of a highly available network design Figure 4. Logical architecture for 50 virtual machines Figure 5. Logical architecture for 100 virtual machines Figure 6. Hypervisor memory consumption Figure 7. Required networks Figure 8. Hyper-V virtual disk types Figure 9. Storage layout for 50 virtual machines Figure 10. Storage layout for 100 virtual machines Figure 11. High Availability at the virtualization layer Figure 12. Redundant power supplies Figure 13. Network layer High Availability Figure 14. VNXe series High Availability Figure 15. Resource pool flexibility Figure 16. Required resource from the Reference virtual machine pool Figure 17. Aggregate resource requirements from the Reference virtual machine pool Figure 18. Customizing server resources Figure 19. Sample Ethernet network architecture

10 Figures 10

11 Tables Table 1. VNXe customer benefits Table 2. Solution hardware Table 3. Solution software Table 4. Network hardware Table 5. Storage hardware Table 6. Backup profile characteristics Table 7. Virtual machine characteristics Table 8. Blank worksheet row Table 9. Reference virtual machine resources Table 10. Example worksheet row Table 11. Example applications Table 12. Server resource component totals Table 13. Blank customer worksheet Table 14. Deployment process overview Table 15. Tasks for pre-deployment Table 16. Deployment prerequisites checklist Table 17. Tasks for switch and network configuration Table 18. Tasks for storage configuration Table 19. Tasks for server installation Table 20. Tasks for SQL server database setup Table 21. Tasks for SCVMM configuration Table 22. Tasks for testing the installation Table 23. List of components used in the VSPEX solution Table 24. for 50 virtual machines List of components used in the VSPEX solution for 100 virtual machines Table 25. Common server information Table 26. Hyper-V server information Table 27. Array information Table 28. Network infrastructure information Table 29. VLAN information Table 30. Service accounts Table 31. Hyper-V Fast Track component classification

12 Tables 12

13 Chapter 1 Executive Summary This chapter presents the following topics: Introduction Target audience Document purpose Business needs

14 Executive Summary Introduction Target audience Document purpose VSPEX validated and modular architectures are built with proven best-of-breed technologies to create complete virtualization solutions on compute, networking, and storage layers. VSPEX helps to reduce virtualization planning and configuration burdens. When embarking on server virtualization, virtual desktop deployment, or IT consolidation, VSPEX accelerates your IT Transformation by enabling faster deployments, choice, greater efficiency, and lower risk. This document is a comprehensive guide to the technical aspects of this solution. Server capacity is provided in generic terms for required minimums of CPU, memory, and network interfaces; the customer can select the server and networking hardware that meet or exceed the stated minimums. The reader of this document should have the necessary training and background to install and configure Microsoft Hyper-V, EMC VNXe series storage systems, and associated infrastructure as required by this implementation. The document provides external references where applicable. The reader should be familiar with these documents. Readers should also be familiar with the infrastructure and database security policies of the customer installation. Users focusing on selling and sizing a Microsoft Hyper-V private cloud infrastructure should pay particular attention to the first four chapters of this document. After purchase, implementers of the solution can focus on the configuration guidelines in Chapter 5, the solution validation in Chapter 6, and the appropriate references and appendices. This document serves as an initial introduction to the VSPEX architecture, an explanation on how to modify the architecture for specific engagements and instructions on how to deploy the system effectively. The VSPEX private cloud architecture provides the customer with a modern system capable of hosting a large number of virtual machines at a consistent performance level. This solution runs on the Microsoft Hyper-V virtualization layer backed by the highly available VNX family storage. The compute and network components are customer-definable, and should be redundant and sufficiently powerful to handle the processing and data needs of the virtual machine environment. The 50 and 100 virtual machines environments are based on a defined reference workload. Because not every virtual machine has the same requirements, this document contains methods and guidance to adjust your system to be cost-effective when deployed. A private cloud architecture is a complex system offering. This document facilitates the setup by providing upfront software and hardware material lists, step-by-step 14

15 Executive Summary Business needs sizing guidance and worksheets, and verified deployment steps. When the last component is installed, there are validation tests to ensure that your system is up and running properly. Following this document ensures an efficient and painless journey to the cloud. Customers require a scalable, tiered, and highly available infrastructure on which to deploy their business and mission-critical applications. Several new technologies are available to assist customers in consolidating and virtualizing their server infrastructure, but customers need to know how to use these technologies to maximize the investment, support service-level agreements, and reduce the total cost of ownership (TCO). This solution addresses the following challenges: Availability: Stand-alone servers incur downtime for maintenance or unexpected failures. Clusters of redundant stand-alone nodes are inefficient in the use of CPU, disk, and memory resources. Server management and maintenance: Individually maintained servers require significant repetitive activities for monitoring, problem resolution, patching, and other common activities. Therefore, the maintenance is labor intensive, costly, error-prone, and inefficient. Security, downtime, and outage risks are elevated. Ease of solution deployment: While small and medium businesses (SMB) must address the same IT challenges as larger enterprises, the staffing levels, experience, and training are generally more limited. IT generalists are often responsible for managing the entire IT infrastructure, and reliance is placed on third-party sources for maintenance or other tasks. The perceived complexity of the IT function raises fear of risk and may block the adoption of new technology. Therefore, the simplicity of deployment and management are highly valued. Storage efficiency: Storage that is added locally to physical servers or provisioned directly from a shared resource or array often leads to overprovisioning and waste. Backup: Traditional backup approaches are slow and frequently unreliable. There tends to be inflection points (or plateaus) in the virtualization adoption curve when the number of virtual machines increases from a few to 100 or more. With a few virtual machines, the situation can be manageable and most organizations can get by with existing tools and processes. However, when the virtual environment grows, the backup and recovery processes often become the limiting factors in the deployment. 15

16 Executive Summary 16

17 Chapter 2 Solution Overview This chapter presents the following topics: Introduction Virtualization Compute Network Storage

18 Solution Overview Introduction The EMC VSPEX private cloud for Microsoft Hyper-V solution provides complete system architecture capable of supporting up to 100 virtual machines with a redundant server/network topology and highly available storage. The core components that make up this particular solution are virtualization, storage, server, compute, and networking. Virtualization Microsoft Hyper-V is a leading virtualization platform in the industry. For years, Hyper- V provides flexibility and cost savings to end users by consolidating large, inefficient server farms into nimble, reliable cloud infrastructures. Features like Live Migration which enables a virtual machine to move between different servers with no disruption to the guest operating system, and Dynamic Optimization which performs Live Migration automatically to balance loads, make Hyper-V a solid business choice. With the release of Windows Server 2012, a Microsoft virtualized environment can host virtual machines with up to 64 virtual CPUs and 1 TB of virtual RAM. Compute VSPEX provides the flexibility to design and implement your choice of server components. The infrastructure must conform to the following attributes: Sufficient processor cores and memory to support the required number and types of virtual machines Sufficient network connections to enable redundant connectivity to the system switches Excess capacity to withstand a server failure and failover in the environment Network VSPEX provides the flexibility to design and implement your choice of network components. The infrastructure must conform to the following attributes: Redundant network links for the hosts, switches, and storage. Support for Multiple Connections per Session. Traffic isolation based on industry-accepted best practices. 18

19 Solution Overview Storage The EMC VNX storage family is the leading shared storage platform in the industry. VNX provides both file and block access with a broad feature set which makes it an ideal choice for any private cloud implementation. The following VNXe storage components are sized for the stated reference architecture workload: Host adapter ports Provide host connectivity via fabric into the array. Storage Processors The compute components of the storage array, which are used for all aspects of data moving into, out of, and between arrays along with protocol support. Disk drives Disk spindles that contain the host/application data and their enclosures. The 50 and 100 virtual machine Hyper-V private cloud solutions discussed in this document are based on the VNXe3150 and VNXe3300 storage arrays respectively. VNXe3150 can support a maximum of 100 drives and VNXe3300 can host up to 150 drives. The EMC VNXe series supports a wide range of business class features ideal for the private cloud environment, including: Thin Provisioning Replication Snapshots File Deduplication and Compression Quota Management 19

20 Solution Overview 20

21 Chapter 3 Solution Technology Overview This chapter presents the following topics: Overview Summary of key components Virtualization Compute Network Storage Backup and recovery Other technologies

22 Solution Technology Overview Overview This solution uses the EMC VNXe series and Microsoft Hyper-V to provide storage and server hardware consolidation in a private cloud. The new virtualized infrastructure is centrally managed to provide efficient deployment and management of a scalable number of virtual machines and associated shared storage. Figure 1 depicts the general solution components. Figure 1. VSPEX private cloud components 22

23 Solution Technology Overview Summary of key components This section briefly describes the key components of this solution. Virtualization The virtualization layer enables the physical implementation of resources to be decoupled from the applications that use them. In other words, the application view of the available resources is no longer directly tied to the hardware. This enables many key features in the private cloud concept. Compute The compute layer provides memory and processing resources for the virtualization layer software, and for the needs of the applications running within the private cloud. The VSPEX program defines the minimum amount of compute layer resources required, and enables the customer to implement the requirements using any server hardware that meets these requirements. Network The network layer connects the users of the private cloud to the resources in the cloud, and the storage layer to the compute layer. The VSPEX program defines the minimum number of network ports required for the solution, provides general guidance on network architecture, and allows the customer to implement the requirements using any network hardware that meets these requirements. Storage The storage layer is critical for the implementation of the private cloud. With multiple hosts to access shared data, many of the use cases defined in the private cloud concept can be implemented. The EMC VNXe storage family used in this solution provides high-performance data storage while maintaining high availability. Backup and recovery The optional backup and recovery components of the solution provide data protection when the data in the primary system is deleted, damaged, or otherwise unusable. The Solution architecture section provides details on all the components that make up the reference architecture. 23

24 Solution Technology Overview Virtualization Overview Microsoft Hyper-V Virtualization enables greater flexibility in the application layer by potentially eliminating hardware downtime for maintenance, and enabling the physical capability of the system to change without affecting the hosted applications. In a server virtualization or private cloud use case, it enables multiple independent virtual machines to share the same physical hardware, rather than being directly implemented on dedicated hardware. Microsoft Hyper-V, a Windows Server role that was introduced in Windows Server 2008, transforms or virtualizes computer hardware resources, including CPU, memory, storage and network. This transformation creates fully functional virtual machines that run their own operating systems and applications just like physical computers. Hyper-V and Failover Clustering provide a high-availability virtualized infrastructure along with Cluster Shared Volumes (CSVs). Live Migration and Live Storage Migration enable seamless migration of virtual machines from one Hyper-V server to another and stored files from one storage system to another, with minimal performance impact. Microsoft System Center Virtual Machine Manager (SCVMM) High Availability with Hyper-V Failover Clustering SCVMM is a centralized management platform for the virtualized datacenter. With SCVMM, administrators can configure and manage the virtualization host, networking, and storage resources in order to create and deploy virtual machines and services to private clouds. When deployed, SCVMM greatly simplifies provisioning, management and monitoring of the Hyper-V environment. Hyper-V achieves high availability by using the Windows Server 2012 Failover Clustering feature. High availability is impacted by both planned and unplanned downtime, and Failover Clustering can significantly increase the availability of virtual machines in both situations. Windows Server 2012 Failover Clustering is configured on the Hyper-V host so that virtual machines can be monitored for health and moved between nodes of the cluster. This configuration has the following key advantages: If the physical host server that Hyper-V and the virtual machines are running on must be updated, changed, or rebooted, the virtual machines can be moved to other nodes of the cluster. You can move the virtual machines back after the original physical host server is back to service. If the physical host server that Hyper-V and the virtual machines are running on fails or is significantly degraded, the other members of the Windows Failover Cluster take over the ownership of the virtual machines and bring them online automatically. If the virtual machine fails, it can be restarted on the same host server or moved to another host server. Since Windows 2012 Server Failover Cluster detects this failure, it automatically takes recovery steps based on the settings in the resource properties of the virtual machine. Downtime is minimized because of the detection and recovery automation. 24

25 Solution Technology Overview EMC Storage Integrator EMC Storage Integrator (ESI) is an agent-less, no-charge plug-in that enables application-aware storage provisioning for Microsoft Windows server applications, Hyper-V, VMware, and Xen Server environments. Administrators can easily provision block and file storage for Microsoft Windows or for Microsoft SharePoint sites by using wizards in ESI. ESI supports the following functions: Provisioning, formatting, and presenting drives to Windows servers Provisioning new cluster disks and adding them to the cluster automatically Provisioning shared CIFS storage and mounting it to Windows servers Provisioning SharePoint storage, sites, and databases in a single wizard Compute The choice of a server platform for an EMC VSPEX infrastructure is not only based on the technical requirements of the environment, but on the supportability of the platform, existing relationships with the server provider, advanced performance and management features, and many other factors. For this reason, EMC VSPEX solutions are designed to run on a wide variety of server platforms. Instead of requiring a given number of servers with a specific set of requirements, VSPEX documents a number of processor cores and an amount of RAM that must be achieved. This can be implemented with 2 or 20 servers and still be considered the same VSPEX solution. In the example shown in Figure 2, assume that the compute layer requirements for a given implementation are 25 processor cores, and 200 GB of RAM. One customer might want to implement this solution using white-box servers containing 16 processor cores and 64 GB of RAM, while a second customer chooses a higher-end server with 20 processor cores and 144 GB of RAM. The first customer needs four of the servers they chose, while the second customer needs two. 25

26 Solution Technology Overview Figure 2. Compute layer flexibility Note To enable high availability at the compute layer, each customer needs one additional server to ensure that the system can maintain business operations if a server fails. The following best practices apply to the compute layer: Use a number of identical or at least compatible servers. VSPEX implements hypervisor level high-availability technologies that may require similar instruction sets on the underlying physical hardware. By implementing VSPEX on identical server units, you can minimize compatibility problems in this area. When implementing high availability on the hypervisor layer, the largest virtual machine you can create is constrained by the smallest physical server in the environment. 26

27 Solution Technology Overview Implement the available high availability features in the virtualization layer, and ensure that the compute layer has sufficient resources to accommodate at least single-server failures. This enables the implementation of minimaldowntime upgrades and tolerance for single-unit failures. Within the boundaries of these recommendations and best practices, the compute layer for EMC VSPEX can be flexible to meet your specific needs. The key constraint is that you provide sufficient processor cores and RAM per core to meet the needs of the target environment. Network Overview The infrastructure network requires redundant network links for each Hyper-V host, the storage array, the switch interconnect ports, and the switch uplink ports. This configuration provides both redundancy and additional network bandwidth. This configuration is required regardless of whether the network infrastructure for the solution already exists, or is being deployed alongside other components of the solution. Figure 3 shows an example of the highly available network topology. Figure 3. Example of a highly available network design 27

28 Solution Technology Overview Storage This validated solution uses virtual local area networks (VLANs) to segregate network traffic of various types to improve throughput, manageability, application separation, high availability, and security. MC/S (Multiple Connections per Session) is a feature of the iscsi protocol, which enables combining several connections inside a single session for performance and failover purposes. EMC VNXe series supports MC/S. In this solution, MC/S is configured to provide redundancy and load balancing. Overview EMC VNXe series The storage layer is also a key component of any Cloud Infrastructure solution that stores and serves data generated by application and operating systems within the datacenter. A centralized storage platform often increases storage efficiency, management flexibility, and reduces total cost of ownership. In this VSPEX solution, EMC VNXe Series is used for providing virtualization at the storage layer. EMC VNX family is optimized for virtual applications delivering industry-leading innovation and enterprise capabilities for file and block storage in a scalable, easyto-use solution. This next-generation storage platform combines powerful and flexible hardware with advanced efficiency, management, and protection software to meet the demanding needs of today s enterprises. The VNXe series is powered by the Intel Xeon processors, for intelligent storage that automatically and efficiently scales in performance, while ensuring data integrity and security. The VNXe series is built for IT managers in smaller environments and the VNX series is designed to meet the high-performance, high-scalability requirements of midsize and large enterprises. Table 1. Feature VNXe customer benefits Next-generation unified storage, optimized for virtualized applications Capacity optimization features including compression, deduplication, thin provisioning, and application-centric copies High availability, designed to deliver five 9s availability Simplified management with EMC Unisphere for a single management interface for all network-attached storage (NAS), storage area network (SAN), and replication needs Software Suites Local Protection Suite Increases productivity with snapshots of production data. 28

29 Solution Technology Overview Remote Protection Suite Protects data against localized failures, outages, and disasters. Application Protection Suite Automates application copies and provides replica management. Security and Compliance Suite Keeps data safe from changes, deletions, and malicious activity. Software Packs Backup and recovery VNXe Total Value Pack Includes the Remote Protection, Application Protection and Security and Compliance Suite. EMC NetWorker EMC s NetWorker coupled with Data Domain deduplication storage systems seamlessly integrate into virtual environments, providing rapid backup and restoration capabilities. Data Domain deduplication results in vastly less data traversing the network by leveraging the Data Domain Boost technology, which greatly reduces the amount of data being backed up and stored, translating into storage, bandwidth, and operational savings. The following are two of the most common recovery requests made to backup administrators: File-level recovery: Object-level recoveries account for the vast majority of user support requests. Common actions requiring file-level recovery are individual users deleting files, applications requiring recoveries, and batch process-related erasures. System recovery: Although complete system recovery requests are less frequent in number than those for file-level recovery, this bare metal restore capability is vital to the enterprise. Some common root causes for full system recovery requests are viral infestation, registry corruption, or unidentifiable unrecoverable issues. The NetWorker System State protection functionality adds backup and recovery capabilities in both of these scenarios. EMC Avamar EMC s Avamar data deduplication technology seamlessly integrates into virtual environments, providing rapid backup and restoration capabilities. Avamar s deduplication results in less data travelling across the network, reduced quantities of data being backed up and stored, and savings in storage, bandwidth, and operational costs. Other technologies In addition to the required technical components for EMC VSPEX solutions, other technologies may provide additional value depending on the specific use case. 29

30 Solution Technology Overview EMC XtemSW Cache (Optional) EMC XtemSW Cache TM is a server Flash caching solution that reduces latency and increases throughput to improve application performance by using intelligent caching software and PCIe Flash technology. Server-side Flash caching for maximum speed XtemSW Cache performs the following functions to improve system performance: Caches the most frequently referenced data on the server-based PCIe card to put the data closer to the application. Automatically adapts to changing workloads by determining which data is most frequently referenced and promoting it to the server Flash card. This means that the hottest data (most active data) automatically resides on the PCIe card in the server for faster access. Offloads the read traffic from the storage array, which allocates greater processing power to other applications. While one application is accelerated with XtemSW Cache, the array performance for other applications is maintained or slightly enhanced. Write-through caching to the array for total protection XtemSW Cache accelerates reads and protects data by using a write-through cache to the storage to deliver persistent high availability, integrity, and disaster recovery supportability. Application agnostic XtemSW Cache is transparent to applications, so no rewriting, retesting, or recertification is required to deploy XtemSW Cache in the environment. Minimum impact on system resources Unlike other caching solutions on the market, XtemSW Cache does not require a significant amount of memory or CPU cycles, as all Flash and wear-leveling management is done on the PCIe card without using server resources. Unlike other PCIe solutions, there is no significant overhead from using XtemSW Cache on server resources. XtemSW Cache creates the most efficient and intelligent I/O path from the application to the datastore, which results in an infrastructure that is dynamically optimized for performance, intelligence, and protection for both physical and virtual environments. XtemSW Cache active/passive clustering support XtemSW Cache clustering scripts configuration ensures that stale data is never retrieved. The scripts use cluster management events to trigger a mechanism that purges the cache. The XtemSW Cache-enabled active/passive cluster ensures data integrity, and accelerates application performance. XtemSW Cache performance considerations The following are the XtemSW Cache performance considerations: On a write request, XtemSW Cache first writes to the array, then to the cache, and then completes the application I/O. 30

31 Solution Technology Overview Note On a read request, XtemSW Cache satisfies the request with cached data, or, when the data is not present, retrieves the data from the array, writes it to the cache, and then returns it to the application. The trip to the array can be in the order of milliseconds, therefore the array limits how fast the cache can work. As the number of writes increases, XtemSW Cache performance decreases. XtemSW Cache is most effective for workloads with a 70 percent, or more, read/write ratio, with small, random I/O (8 K is ideal). I/O greater than 128 K will not be cached in XtemSW Cache v1.5. For more information, refer to the XtemSW Cache Installation and Administration Guide v

32 Solution Technology Overview 32

33 Chapter 4 Solution Architecture Overview This chapter presents the following topics: Solution overview Solution architecture Server configuration guidelines Network configuration guidelines Storage configuration guidelines High availability and failover Backup and recovery configuration guidelines Sizing guidelines Reference workload Applying the reference workload Implementing the reference architectures Quick assessment

34 Solution Architecture Overview Solution overview Solution architecture VSPEX Proven Infrastructure solutions are built with proven best-of-breed technologies to create a complete virtualization solution that enables you to make an informed decision when choosing and sizing the hypervisor, compute, networking, and storage layers. VSPEX eliminates virtualization planning and configuration burdens by leveraging extensive interoperability, functional, and performance testing by EMC. VSPEX accelerates your IT Transformation to cloud-based computing by enabling faster deployment, more choice, higher efficiency, and lower risk. This section is intended to be a comprehensive guide to the major aspects of this solution. Server capacity is specified in generic terms for required minimums of CPU, memory, and network interfaces; the customer is free to select the server and networking hardware that meet or exceed the stated minimums. The specified storage architecture, along with a system meeting the server and network requirements outlined, is validated by EMC to provide high levels of performance while delivering a highly available architecture for your private cloud deployment. Each VSPEX Proven Infrastructure balances the storage, network, and compute resources needed for a set number of virtual machines, which have been validated by EMC. In practice, each virtual machine has its own set of requirements that rarely fit a predefined idea of what a virtual machine should be. In any discussion about virtual infrastructures, it is important to first define a reference workload. Not all servers perform the same tasks, and it is impractical to build a reference that takes into account every possible combination of workload characteristics. Overview The VSPEX Proven Infrastructure for Microsoft Hyper-V private clouds with EMC VNXe is validated at two different points of scale; one with up to 50 virtual machines, and the other with up to 100 virtual machines. The defined configurations form the basis of creating a custom solution. Note VSPEX uses the concept of a Reference Workload to describe and define a virtual machine. Therefore, one physical or virtual server in an existing environment may not be equal to one virtual machine in a VSPEX solution. Evaluate your workload in terms of the reference to achieve an appropriate point of scale. 34

35 Solution Architecture Overview Architecture for up to 50 virtual machines Figure 4 characterizes the validated infrastructure for up to 50 virtual machines. Figure 4. Logical architecture for 50 virtual machines Architecture for up to 100 virtual machines Figure 5 characterizes the validated infrastructure for up to 100 virtual machines. Figure 5. Logical architecture for 100 virtual machines Note The networking components of either solution can be implemented using 1 Gb or 10 Gb IP networks, if sufficient bandwidth and redundancy meet the listed requirements. 35

36 Solution Architecture Overview Key components The architecture includes the following key components: Microsoft Hyper-V Provides a common virtualization layer to host a server environment. The specifics of the validated environment are listed in Table 2. Hyper-V provides a highly available infrastructure through features such as: Live Migration Provides live migration of virtual machines within a virtual infrastructure cluster, with no virtual machine downtime or service disruption. Live Storage Migration Provides live migration of virtual machine disk files within and across storage arrays with no virtual machine downtime or service disruption. Failover Clustering High Availability (HA) Detects and provides rapid recovery for a failed virtual machine in a cluster. Dynamic Optimization (DO) Provides load balancing of computing capacity in a cluster with support of SCVMM. Microsoft System Center Virtual Machine Manager (SCVMM) SCVMM is not required for this solution. However, if deployed, it (or its corresponding function in Microsoft System Center Essentials) simplifies provisioning, management, and monitoring of the Hyper-V environment. Microsoft SQL Server 2012 SCVMM, if used, requires a SQL Server database instance to store configuration and monitoring details. DNS Server DNS services are required for the various solution components to perform name resolution. The Microsoft DNS service running on a Windows Server 2012 is used. Active Directory Server Active Directory services are required for the various solution components to function properly. The Microsoft Active Directory Service running on a Windows Server 2012 is used. IP Network All network traffic is carried by standard Ethernet network with redundant cabling and switching. Users and management traffic are carried over a shared network while storage traffic is carried over a private, non-routable subnet. EMC VNXe 3150 array Provides storage by presenting Internet Small Computer System Interface (iscsi) datastores to Hyper-V hosts for up to 50 virtual machines. EMC VNXe3300 array Provides storage by presenting Internet Small Computer System Interface (iscsi) datastores to Hyper-V hosts for up to 100 virtual machines. These datastores for both deployment sizes are created by using application-aware wizards included in the EMC Unisphere interface. VNXe series storage arrays include the following components: Storage Processors (SPs) support block and file data with UltraFlex TM I/O technology that supports iscsi, CIFS, and NFS protocols The SPs provide access for all external hosts and for the file side of the VNXe array. Battery backup units are battery units within each storage processor and provide enough power to each storage processor to ensure that any data in 36

37 Solution Architecture Overview flight is destaged to the vault area in the event of a power failure. This ensures that no writes are lost. Upon restart of the array, the pending writes are reconciled and persisted. Disk-array Enclosures (DAE) house the drives used in the array. Hardware resources Table 2 lists the hardware used in this solution. Table 2. Solution hardware Hardware Configuration Notes Hyper-V servers Memory: 2 GB RAM per virtual machine 100 GB RAM across all servers for the 50- virtual-machine configuration 200 GB RAM across all servers for the 100- virtual-machine configuration 2 GB RAM reservation per host for hypervisor Configured as a single Hyper-V cluster. CPU: One vcpu per virtual machine One to four vcpus per physical core Network infrastructure Network: Two 10 GbE NIC ports per server Note To implement Microsoft Hyper-V High Availability (HA) functionality and to meet the listed minimums, the infrastructure should have one additional server. Minimum switching capacity: Two physical switches Two 10 GbE ports per Hyper-V server One 1 GbE port per storage processor for management Two 10 GbE ports per storage processor for data Redundant LAN configuration 37

38 Solution Architecture Overview Hardware Configuration Notes Storage Common: Two Storage Processors (active/active) Two 10GbE interfaces per storage processor for data Include the initial disk pack on the VNXe. For 50 Virtual Machines EMC VNXe3150 Forty-five 300 GB 15k RPM 3.5-inch SAS disks (9 * 300 GB 4+1 R5 Performance Drive Packs) Two 300 GB 15k RPM 3.5-inch SAS disks as hot spares For 100 Virtual Machines EMC VNXe3300 Seventy-seven 300 GB 15k RPM 3.5-inch SAS disks (11 * 300 GB 6+1 R5 Performance Drive Packs) Three 300 GB 15k RPM 3.5-inch SAS disks as hot spares Shared infrastructure EMC Next- Generation Backup In most cases, a customer environment will already have configured the infrastructure services such as Active Directory, DNS, and other services. The setup of these services is beyond the scope of this document. If this configuration is being implemented with non-existing infrastructure, a minimum number of additional servers is required: Two physical servers 16 GB RAM per server Four processor cores per server Two 10 GbE ports per server For 50 virtual machines Three DD160 Factory For 100 virtual machines One Avamar Business Edition These servers and the roles they fulfill may already exist in the customer environment; however, they must exist before VSPEX is deployed. 38

39 Solution Architecture Overview Software resources Table 3 lists the software used in this solution. Table 3. Software Microsoft Hyper-V Solution software Operating system for Hyper-V hosts System Center Virtual Machine Manager Microsoft SQL Server Configuration Windows 2012 Datacenter Edition (Datacenter Edition is necessary to support the number of virtual machines in this solution) Version 2012 SP1 Version 2012 Enterprise Edition VNXe Software version Next-Generation Backup NetWorker Avamar Data Domain OS 8.0 SP1 for 50 virtual machines 6.1 SP1 for 100 virtual machines 5.2 for 50 virtual machines Server configuration guidelines Overview When designing and ordering the compute/server layer of the VSPEX solution, several factors may alter the final purchase. From a virtualization perspective, if a system workload is well estimated, features like Dynamic Memory and Smart Paging can reduce the aggregate memory requirement. If the virtual machine pool does not have a high level of peak or concurrent usage, the number of vcpus may be reduced. Conversely, if the applications being deployed are highly computational in nature, the number of CPUs and memory to be purchased may need to increase. Hyper-V memory virtualization Microsoft Hyper-V has a number of advanced features that help to maximize performance and overall resource utilization. The most important of these are in the area of memory management. This section describes some of these features and the items to consider in the environment. In general, you can consider virtual machines on a single hypervisor consuming memory as a pool of resources. Figure 6 is an example. 39

40 Solution Architecture Overview Figure 6. Hypervisor memory consumption This basic concept is enhanced by understanding the technologies presented in this section. Dynamic Memory Dynamic Memory, which was introduced in Windows Server 2008 R2 SP1, increases physical memory efficiency by treating memory as shared resources and allocating it to the virtual machines dynamically. Actual used memory of each virtual machine is adjusted on demand. Dynamic Memory enables more virtual machines to run by reclaiming unused memory from idle virtual machines. In Windows Server 2012, Dynamic Memory enables the dynamic increase of the maximum memory available to virtual machines. 40

41 Smart Paging Solution Architecture Overview Even with Dynamic Memory, Hyper-V allows more virtual machines than physical available memory. There is most likely a memory gap between minimum memory and startup memory. Smart Paging is a memory management technique that leverages disk resources as temporary memory replacement. It swaps out less-used memory to disk storage and swap in when needed, which may cause performance to degrade as a drawback. Hyper-V continues to leverage the guest paging when the host memory is oversubscribed, as it is more efficient than Smart Paging. Non-Uniform Memory Access Non-Uniform Memory Access (NUMA) is a multi-node computer technology that enables a CPU to access remote-node memory. This type of memory access is costly in terms of performance, so Windows Server 2012 employs a process known as processor affinity, which strives to keep threads pinned to a particular CPU to avoid remote-node memory access. In previous versions of Windows, this feature is only available to the host. Windows Server 2012 extends this functionality into the virtual machines, which can now realize improved performance in SMP environments. Memory configuration guidelines This section provides guidelines to configure server memory for this solution. The guidelines take into account Hyper-V memory overhead and the virtual machine memory settings. Hyper-V memory overhead Virtualized memory has some associated overhead, which includes the memory consumed by Hyper-V, the parent partition, and additional overhead for each virtual machine. Leave at least 2 GB memory for Hyper-V parent partition for this solution. Virtual machine memory In this solution, each virtual machine gets 2 GB memory in fixed mode. 41

42 Solution Architecture Overview Network configuration guidelines Overview This section provides guidelines to set up a redundant, highly available network configuration for this VSPEX solution. The guidelines take into account VLANs and Multiple Connections per Session (MC/S). For detailed network resource requirements, refer to Table 4. Table 4. Network hardware Hardware Configuration Notes Network infrastructure Minimum switching capacity: Two physical switches Two 10 GbE ports per Hyper-V server One 1GbE port per storage processor for management Two 10-GbE ports per storage processor for data Redundant LAN configuration VLAN It is a best practice to isolate network traffic so that the traffic between hosts and storage, hosts and clients, and management traffic all move over isolated networks. In some cases physical isolation may be required for regulatory or policy compliance reasons; but in many cases logical isolation using VLANs is sufficient. This solution calls for a minimum of three VLANs for the following usage: Client access Storage Management/Live Migration 42

43 Solution Architecture Overview Figure 7 depicts these VLANs. Figure 7. Required networks Note Figure 7 demonstrates the network connectivity requirements for a VNXe3300 using 10 GbE network connections (1 GbE for the Management Network). A similar topology should be created when using the VNXe3150 array. The client access network is for users of the system, or clients, to communicate with the infrastructure. The Storage Network is used for communication between the compute layer and the storage layer. The Management network is used for administrators to have a dedicated way to access the management connections on the storage array, network switches, and hosts. Note Some best practices call for additional network isolation for cluster traffic, virtualization layer communication, and other features. These additional networks can be implemented if necessary, but they are not required. MC/S Multiple Connections per Session (MC/S) is configured on each Hyper-V host so that each host network interface has one iscsi session to each VNXe storage processor (SP) interface. In this solution, four iscsi sessions are configured between each host and each VNXe SP (each VNXe iscsi server). 43

44 Solution Architecture Overview Storage configuration guidelines Overview Hyper-V allows more than one method of utilizing storage when hosting virtual machines. The solutions are tested utilizing iscsi and the storage layout described adheres to all current best practices. The customer or architect with required knowledge can make modifications based on the systems usage and load if necessary. Table 5 lists the required hardware for the storage configuration. Table 5. Storage hardware Hardware Configuration Notes Storage Common: Two storage processors (active/active) Two 10 GbE interfaces per storage processor Include the initial disk pack on the VNXe. For 50 virtual machines EMC VNXe3150 Forty-five 300 GB 15k RPM 3.5-inch SAS disks (9 * 300 GB 4+1 R5 Performance Drive Packs) Two 300 GB 15k RPM 3.5-inch SAS disks as hot spares For 100 virtual machines EMC VNXe3300 Seventy-seven 300 GB 15k RPM 3.5-inch SAS disks (11 * 300 GB 6+1 R5 Performance Drive Packs) Three 300 GB 15k RPM 3.5-inch SAS disks as hot spares Hyper-V storage virtualization for VSPEX This section provides guidelines to set up the storage layer of the solution to provide high availability and the expected level of performance. Windows Server 2012 Hyper-V and Failover Clustering leverage Cluster Shared Volumes v2 and new Virtual Hard Disk Format (VHDX) features to virtualize storage presented from external shared storage system to host virtual machines. 44

45 Solution Architecture Overview Figure 8. Hyper-V virtual disk types Cluster Shared Volumes v2 Cluster Shared Volumes (CSV) was introduced in Windows Server 2008 R2. They enable all cluster nodes to have simultaneous access to the shared storage for hosting virtual machines. Windows Server 2012 introduces a number of new capabilities with CSV v2, which includes flexible application, file storage, integration with other Windows Server 2012 features, single name space, and improved backup and restore. New Virtual Hard Disk format Hyper-V in Windows Server 2012 contains an update to the VHD format called VHDX, which has much larger capacity and built-in resiliency. The main new features of VHDX format are: Support for virtual hard disk storage with the capacity of up to 64 TB Additional protection against data corruption during power failures by logging updates to the VHDX metadata structures Optimal structure alignment of the virtual hard disk format to suit large sector disks The VHDX format also has the following features: Larger block sizes for dynamic and differential disks, which enables the disks to meet the needs of the workload The 4 KB logical sector virtual disk that enables increased performance when used by applications and workloads that are designed for 4-KB sectors The ability to store custom metadata about the files that the user might want to record, such as the operating system version or applied updates Space reclamation features that can result in smaller file size and enables the underlying physical storage device to reclaim unused space (Trim for example requires direct-attached storage or SCSI disks and Trim-compatible hardware.) 45

46 Solution Architecture Overview Storage layout for 50 virtual machines Figure 9 shows the overall storage layout of the 50 virtual machine solution. Figure 9. Storage layout for 50 virtual machines Storage layout overview The architecture for up to 50 virtual machines uses the following configuration: Forty-five 300 GB SAS disks allocated to a single storage pool as nine 4+1 RAID 5 groups (sold as nine packs of five disks). At least one hot spare allocated for every 30 disks of a given type. At least four iscsi LUNs allocated to the Hyper-V cluster from the single storage pool to serve as datastores for the virtual servers. 46

47 Solution Architecture Overview Storage layout for 100 virtual machines Figure 10 shows the overall storage layout of the 100 virtual machine solution. Figure 10. Storage layout for 100 virtual machines Storage layout overview The architecture for up to 100 virtual machines uses the following configuration: Seventy-seven 300 GB SAS disks allocated to a single storage pool as eleven 6+1 RAID 5 groups (sold as 11 packs of seven disks). At least one hot spare disk allocated for every 30 disks of a given type. At least 10 iscsi LUNs allocated to the Hyper-V cluster from the single storage pool to serve as datastores for the virtual servers. Note If more capacity is required in either configuration, larger drives may be substituted. To meet the load recommendations, the drives all must be 15k RPM and the same size. If different sizes are utilized, storage layout algorithms may give sub-optimal results. 47

48 Solution Architecture Overview High availability and failover Overview Virtualization layer This VSPEX solution provides a highly available virtualized server, network and storage infrastructure. By implementing the solution in this guide, single-unit failures can survive with minimal or no impact to business operations. Configure high availability in the virtualization layer, and configure the hypervisor to automatically restart failed virtual machines. Figure 11 illustrates the hypervisor layer responding to a failure in the compute layer. Figure 11. High Availability at the virtualization layer By implementing high availability at the virtualization layer, even in a hardware failure, the infrastructure attempts to keep as many services running as possible. Compute layer Use enterprise class servers designed for the datacenter to implement the compute layer when possible. This type of server has redundant power supplies, which should be connected to separate Power Distribution units (PDUs) in accordance with your server vendor s best practices. Figure 12. Redundant power supplies Configure high availability in the virtualization layer. The compute layer must be configured with enough resources so that the total number of available resources meets the needs of the environment, even with a server failure, as demonstrated in Figure

49 Solution Architecture Overview Network layer The advanced networking features of the VNX family provide protection against network connection failures at the array. Each Hyper-V host has multiple connections to user and storage Ethernet networks to guard against link failures. These connections should be spread across multiple Ethernet switches to guard against component failure in the network. Figure 13. Network layer High Availability Note Figure 13 demonstrates a highly available network topology based on VNXe3300. A similar topology should be constructed if using the VNXe3150. By ensuring that there are no single points of failure in the network layer, the compute layer is able to access storage, and communicate with users even if a component fails. 49

50 Solution Architecture Overview Storage layer The VNX family is designed for five 9s availability by using redundant components throughout the array. All of the array components are capable of continued operation in case of hardware failure. The RAID disk configuration on the array provides protection against data loss caused by individual disk failures, and the available hot spare drives can be dynamically allocated to replace a failing disk, as shown in Figure 14. Figure 14. VNXe series High Availability EMC Storage arrays are designed to be highly available by default. Configure the storage arrays according to the installation guides to ensure that no single unit failures cause data loss or unavailability. 50

51 Solution Architecture Overview Backup and recovery configuration guidelines Overview This section provides guideline to set up a backup and recovery environment for this VSPEX solution. It describes how to characterize and design the backup environment. Backup characteristics This VSPEX solution was sized with the application environment profile shown in Table 6. Table 6. Backup profile characteristics Profile characteristic Number of users Number of virtual machines Exchange data SharePoint data SQL server User data Value 500 for 50 virtual machines 1,000 for 100 virtual machines 50 for 50 virtual machines 100 for 100 virtual machines Note 20% DB, 80% Unstructured 0.5 TB for 50 virtual machines 1 TB for 100 virtual machines Note 1 GB mail box per user 0.25 TB for 50 virtual machines 0.5 TB for 100 virtual machines 0.25 TB for 50 virtual machines 0.5 TB for 100 virtual machines 2.5 TB for 50 virtual machines 5 TB for 100 virtual machines (5.0 GB per user) Daily change rate for the applications Exchange data 10% SharePoint data 2% SQL server 5% User data 2% Retention per data types All DB data User data 14 Dailies 30 Dailies, 4 Weeklies, 1 Monthly 51

52 Solution Architecture Overview Backup layout for virtual machines For 50 virtual machines, EMC NetWorker Fast Start provides various deployment options depending on the specific use case and the recovery requirements. In this case, the solution is deployed with both NetWorker Fast Start and Data Domain managed as a single solution. This enables the unstructured user data to be backed up directly to the Data Domain system for simple file level recovery. The database is managed by the NetWorker Fast Start software, but is directed to the Data Domain system with the embedded Boost client library. This backup solution unifies the backup process and achieves dramatically increased performance and efficiency. Sizing guidelines Reference workload For 100 virtual machines, EMC Avamar is used instead of Networker. The following sections describe definitions of the reference workload used to size and implement the VSPEX architectures, guidance on how to correlate those reference workloads to actual customer workloads, and how that may change the end delivery from the server and network perspective. You can modify the storage definition by adding drives for greater capacity and performance. The disk layouts are created to provide support for the appropriate number of virtual machines at the defined performance level along with typical operations such as snapshots. Decreasing the number of recommended drives or stepping down to a lower performing array type can result in lower IOPS per virtual machine and a reduced user experience due to higher response times. Overview When considering an existing server to move into a virtual infrastructure, you have the opportunity to 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 that have been validated by EMC. In practice, each virtual machine has its own set of requirements that rarely fit a predefined idea of what a virtual machine should be. In any discussion about virtual infrastructures, it is important to first define a reference workload. Not all servers perform the same tasks, and it is impractical to build a reference model that takes into account every possible combination of workload characteristics. 52

53 Solution Architecture Overview Defining the reference workload To simplify the discussion, we have defined a representative customer reference workload. By comparing your actual customer usage to this reference workload, you can extrapolate which reference architecture to choose. For the VSPEX solutions, the reference workload is defined as a single virtual machine. Table 7 lists the characteristics of this virtual machine: Table 7. Virtual machine characteristics Characteristic Value Virtual machine operating system Microsoft Windows Server 2012 Datacenter Edition Virtual processors per virtual machine 1 RAM per virtual machine Available storage capacity per virtual machine I/O operations per second (IOPS) per virtual machine I/O pattern 2 GB 100 GB 25 Random I/O read/write ratio 2:1 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. Applying the reference workload Overview Example 1: Custom-built application The reference architectures create a pool of resources that are sufficient to host a target number of Reference virtual machines with the characteristics shown in Table 7. The customer virtual machines may not exactly match the specifications. In that case, define a single specific customer virtual machine as the equivalent of a number of Reference virtual machines, and assume the virtual machines are in use in the pool. Continue to provision virtual machines from the resource pool until no resources remain. A small custom-built application server needs to move into this infrastructure. The physical hardware that supports the application is not fully utilized. A careful analysis of the existing application reveals that the application can use one processor, and needs 3 GB of memory to run normally. The I/O workload ranges from 4 IOPS at idle time to a peak of 15 IOPS when busy. The entire application consumes about 30 GB of local hard drive storage. Based on the numbers, the following resources are required from the resource pool: CPU resources for one virtual machine 53

54 Solution Architecture Overview Memory resources for two virtual machines Storage capacity for one virtual machine I/Os for one virtual machine In this example, a single virtual machine uses the resources for two of the Reference virtual machines. If the original pool has the resources to provide 100 Reference virtual machines, the resources for 98 Reference virtual machines remain. Example 2: Point of sale system The database server for a customer s point of scale system needs to move into this virtual infrastructure. It is currently running on a physical system with four CPUs and 16 GB of memory. It uses 200 GB of storage and generates 200 IOPS during an average busy cycle. The following resources are required to virtualize this application: CPUs of four Reference virtual machines Memory of eight Reference virtual machines Storage of two Reference virtual machines I/Os of eight Reference virtual machines In this case, the one virtual machine uses the resources of eight Reference virtual machines. To implement this one machine on a pool for 100 Reference virtual machines, the resources of eight Reference virtual machines are consumed and resources for 92 Reference virtual machines remain. Example 3: Web server The web server of the customer needs to move into this virtual infrastructure. It is currently running on a physical system with 2 CPUs and 8 GB of memory. It uses 25 GB of storage and generates 50 IOPS during an average busy cycle. The following resources are required to virtualize this application: CPUs of two Reference virtual machines Memory of four Reference virtual machines Storage of one Reference virtual machines I/Os of two Reference virtual machines In this case, the one virtual machine would use the resources of four Reference virtual machines. If the configuration is implemented on a resource pool for 100 Reference virtual machines, resources for 96 Reference virtual machines remain. Example 4: Decision-support database The database server for a customer s decision-support system needs to move into this virtual infrastructure. It is currently running on a physical system with 10 CPUs and 64 GB of memory. It uses 5 TB of storage and generates 700 IOPS during an average busy cycle. The following resources are required to virtualize this application: CPUs of 10 Reference virtual machines 54

55 Solution Architecture Overview Memory of 32 Reference virtual machines Storage of 52 Reference virtual machines I/Os of 28 Reference virtual machines In this case, the one virtual machine uses the resources of 52 Reference virtual machines. If this configuration is implemented on a resource pool for 100 Reference virtual machines, resources for 48 Reference virtual machines remain. Summary of examples The four examples illustrate the flexibility of the resource pool model. In all four cases, the workloads simply reduce the amount of available resources in the pool. All four examples can be implemented on the same virtual infrastructure with an initial capacity for 100 Reference virtual machines, and resources for 34 Reference virtual machines remain in the resource pool, as shown in Figure 15. Figure 15. Resource pool flexibility In more advanced cases, there may be tradeoffs between memory and I/O or other relationships where increasing the amount of one resource decreases the need for another. In these cases, the interactions between resource allocations become highly complex, and are outside the scope of the document. Once the change in resource balance has been examined and the new level of requirements is known, these virtual machines can be added to the infrastructure using the method described in the examples. Implementing the reference architectures Overview The reference architectures require a set of hardware to be available for the CPU, memory, network, and storage needs of the system. In this VPSEX solution, these are presented as general requirements that are independent of any particular implementation. This section describes some considerations for implementing the requirements. 55

56 Solution Architecture Overview Resource types The reference architectures define the hardware requirements for this VSPEX solution in terms of the following basic types of resources: CPU resources Memory resources Network resources Storage resources This section describes the resource types, how to use them in the reference architectures, and key considerations for implementing them in a customer environment. CPU resources The architectures define the number of required CPU cores instead of a specific type or configuration. It is intended that new deployments use recent revisions of common processor technologies. It is assumed that they perform as well as, or better than the systems used to validate the solution. In any running system, it is important to monitor the utilization of resources and adapt as needed. The Reference virtual machine and required hardware resources in the reference architectures assume that there are no more than four virtual CPUs for each physical processor core (4:1 ratio). In most cases, 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. Memory resources Each virtual server in the reference architectures is defined to have 2 GB of memory. In a virtual environment, it is common to provision virtual machines with more memory than the hypervisor physically has, due to budget constraints. The memory over commitment technique takes advantage of the fact that each virtual machine may not fully utilize the amount of memory allocated to it. Therefore, it makes business sense to oversubscribe the memory usage to some degree. The administrator has the responsibility to monitor the oversubscription rate such that it does not shift the bottleneck away from the server and become a burden to the storage subsystem via swapping. This solution is validated with statically assigned memory and no over commitment of memory resources. If memory over commit is used in a real-world environment, regularly monitor the system memory utilization, and associated page file I/O activity to ensure that a memory shortfall does not cause unexpected results. Network resources The reference architecture outlines the minimum needs of the system. If additional bandwidth is needed, it is important to add capability at 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 have the option to add ports using EMC FLEX I/O modules. For reference purposes in the validated environment, EMC assumes that each virtual machine generates 25 IOs per second with an average size of 8 KB. This means that 56

57 Solution Architecture Overview each virtual machine is generating at least 200 KB/s of traffic on the storage network. For an environment rated for 100 virtual machines, this comes out to 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 the following operations: User network traffic Virtual machine migration Administrative and management operations The requirements for each of these vary depending on how the environment is being used, so it is not practical to provide concrete numbers in this context. However, the network described in the reference architecture for each solution should be sufficient to handle average workloads for the preceding use cases. Regardless of the network traffic requirements, always have at least two physical network connections that are shared for a logical network so that a single link failure does not affect the availability of the system. Design the network to ensure that the aggregate bandwidth in a failure is sufficient to accommodate the full workload. Storage resources The reference architectures 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. There are a few layers to consider when examining storage sizing. Specifically, the array has a collection of disks that are assigned to a storage pool. From that storage pool, you can provision datastores to the Microsoft Hyper-V cluster. Each layer has a specific configuration that is defined for the solution and documented in the deployment guide. It is generally acceptable to replace drive types with a type that has more capacity with the same performance characteristics or with ones that have higher performance characteristics and the same capacity. Similarly, it is acceptable to change the placement of drives in the drive shelves in order to comply with updated or new drive shelf arrangements. In other cases where there is a need to deviate from the proposed number and type of drives specified, or the specified pool and datastore layouts, ensure that the target layout delivers the same or greater resources to the system. Implementation summary The requirements that are stated in the reference architectures 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. However, if the customer virtual machines differ significantly from the reference definition, the system may require additional resources. 57

58 Solution Architecture Overview Quick assessment Overview An assessment of the customer environment helps ensure that you implement the correct VSPEX solution. This section provides an easy-to-use worksheet to simplify the sizing calculations, and help assess the customer environment. Summarize the applications that are planned for migration into the VSPEX private cloud. For each application, determine the number of virtual CPUs, the amount of memory, the required storage performance, the required storage capacity and the number of Reference virtual machines required from the resource pool. Applying the reference workload provides examples of this process. Fill out a row in the worksheet for each application, as shown in Table 8. Table 8. Blank worksheet row Application CPU (virtual CPUs) Memory (GB) IOPS Capacity (GB) Equivalent Reference virtual machines Example application Resource requirements Equivalent Reference virtual machines Fill out the resource requirements for the application. The row requires inputs on four different resources: CPU, Memory, IOPS and Capacity. CPU requirements Optimizing CPU utilization is a significant goal for almost any virtualization project. A simple view of the virtualization operation suggests a one-to-one mapping between physical CPU cores and virtual CPU cores regardless of the physical CPU utilization. In reality, consider whether the target application can effectively use all of the presented CPUs. Use a performance-monitoring tool, such as Microsoft perfmon to examine the CPU Utilization counter for each CPU. If they are equivalent, implement that number of virtual CPUs when moving into the virtual infrastructure. However, if some CPUs are used and some are not, consider decreasing the number of required virtual CPUs. In any operation involving performance monitoring, it is a best practice to collect data samples for a period of time that includes all of the operational use cases of the system. Use either the maximum or 95 th percentile value of the resource requirements for planning purposes. Memory requirements Server memory plays a key role in ensuring application functionality and performance. Therefore, each server process has different targets for the acceptable amount of available memory. When moving an application into a virtual environment, consider the current memory available to the system, and monitor the free memory by 58

59 Solution Architecture Overview using a performance-monitoring tool like perfmon, to determine if it is being used efficiently. Storage performance requirements The storage performance requirements for an application are usually the least understood aspect of performance. Three components become important when discussing the I/O performance of a system. The number of requests coming in, or IOPS The size of the request, or I/O size -- a request for 4 KB of data is significantly easier and faster to process than a request for 4 MB of data The average I/O response time or latency I/O operations per second (IOPs) The Reference virtual machine calls for 25 I/O operations per second. To monitor this on an existing system use a performance-monitoring tool like perfmon, which provides several counters that can help here. Logical Disk\Disk Transfer/sec Logical Disk\Disk Reads/sec Logical Disk\Disk Writes/sec The Reference virtual machine assumes a 2:1 read: write ratio. Use these counters to determine the total number of IOPS, and the approximate ratio of reads to writes for the customer application. I/O size The I/O size is important because smaller I/O requests are faster and easier to process than large I/O requests. The Reference virtual machine assumes an average I/O request size of 8 KB, which is appropriate for a large range of applications. Use perfmon or another appropriate tool to monitor the Logical Disk\Avg. Disk Bytes/Transfer counter to see the average I/O size. Most applications use I/O sizes that are even powers of 2 KB (i.e. 4 KB, 8 KB, 16 KB, and 32 KB, and so on) are common. The performance counter does a simple average, so it is common to see 11 KB or 15 KB instead of the common I/O sizes. The Reference virtual machine assumes an 8 KB I/O size. If the average customer I/O size is less than 8 KB, use the observed IOPS number. However, if the average I/O size is significantly higher, apply a scaling factor to account for the large I/O size. A safe estimate is to divide the I/O size by 8 KB and use that factor. For example, if the application is using mostly 32 KB I/O requests, use a factor of four (32 KB / 8 KB = 4). If that application is doing 100 IOPS at 32 KB, the factor indicates to plan for 400 IOPS since the Reference virtual machine assumed 8 KB I/O sizes. I/O latency The average I/O response time, or I/O latency, is a measurement of how quickly I/O requests are processed by the storage system. The VSPEX solutions are designed to meet a target average I/O latency of 20 ms. The recommendations in the Sizing guidelines section should allow the system to continue to meet that target, however it is worthwhile to monitor the system and re-evaluate the resource pool utilization if needed. To monitor I/O latency, use the Logical Disk\Avg. Disk sec/transfer counter in perfmon. If the I/O latency is continuously over the target, re-evaluate the virtual 59

60 Solution Architecture Overview machines in the environment to ensure that they are not using more resources than intended. Storage capacity requirements Determining equivalent Reference virtual machines The storage capacity requirement for a running application is usually the easiest resource to quantify. Determine how much space on disk the system is using, and add an appropriate factor to accommodate growth. For example, to virtualize a server that is currently using 40 GB of a 200 GB internal drive with anticipated growth of approximately 20% over the next year, 48 GB are required. EMC also recommends reserving space for regular maintenance patches and swapping files. In addition, some file systems, like Microsoft NTFS, degrade in performance if they become too full. With all of the resources defined, determine an appropriate value for the equivalent Reference virtual machines line by using the relationships in Table 9. Round all values up to the closest whole number. Table 9. 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 60

61 Solution Architecture Overview For example, the point of scale system used in Example 2: Point of sale system earlier in the paper requires 4 CPUs, 16 GB of memory, 200 IOPS and 200 GB of storage. This translates to four Reference virtual machines of CPU, eight Reference virtual machines of memory, eight Reference virtual machines of IOPS, and two Reference virtual machines of capacity. Table 10 demonstrates how that machine fits into the worksheet row. Use the maximum value of the row to fill in the column for equivalent Reference virtual machines. Eight Reference virtual machines are required in this example. Table 10. Application Example application Example worksheet row Resource requirements CPU (virtual CPUs) Memory (GB) IOPS Capacity (GB) Equivalent Reference virtual machines Equivalent Reference virtual machines Figure 16. Required resource from the Reference virtual machine pool 61

62 Solution Architecture Overview Once the worksheet has been filled out for each application that the customer wants to migrate into the virtual infrastructure, compute the sum of the equivalent Reference virtual machines column on the right side of the worksheet as shown in Table 11, to calculate the total number of Reference virtual machines that are required in the pool. In the example, the result of the calculation from Table 9 is shown for clarity, along with the value, rounded up to the nearest whole number, to use. Table 11. Application Example application #1: Custom-built application Example applications Resource requirements Equivalent Reference virtual machines Server resources CPU (virtual CPUs) Memory (GB) Storage resources IOPS Capacity (GB) Reference virtual machines Example application #2: Point of sale system Example application #3: Web server Example application #4: Decision support database Resource requirements Equivalent Reference virtual machines Resource requirements Equivalent Reference virtual machines Resource requirements Equivalent Reference virtual machines (5TB) Total equivalent Reference virtual machines 66 62

63 Solution Architecture Overview The VSPEX private cloud solutions define discrete resource pool sizes. Figure 17 shows 34 Reference virtual machines available after applying all four examples in 100 virtual machine solutions. Figure 17. Aggregate resource requirements from the Reference virtual machine pool In the case of Table 11, the customer requires 66 virtual machines of capability from the pool. Therefore, the 100 virtual machine resource pool provides sufficient resources for the current needs as well as room for growth. Fine tuning hardware resources In most cases, the recommended hardware for servers and storage is sized appropriately based on the process described. However, in some cases there may be a requirement to further customize the hardware resources that are available to the system. While a complete description of system architecture is beyond the scope of this document, additional customization can be done at this point. Storage resources In some applications, there is a need to separate application data from other workloads. The storage layouts in the VSPEX architectures put all of the virtual machines in a single resource pool. In order to achieve workload separation, purchase additional disk drives for the application workload and add them to a dedicated pool. It is not appropriate to reduce the size of the main resource pool in order to support application isolation, or to reduce the capability of the pool. The storage layouts presented in the 50 and 100 virtual machine solutions are designed to balance many different factors in terms of high availability, performance, and data protection. Changing the components of the pool can have significant and difficult-to-predict impacts on other areas of the system. 63

64 Solution Architecture Overview Server resources For the server resources in the VSPEX private cloud solution, it is possible to customize the hardware resources for varying workloads. Figure 18 is an example. Figure 18. Customizing server resources To achieve this customization, total the resource requirements for the server components, as shown in Table 12. In the Server Component Totals row, add up the server resource requirements from the applications in the table. Table 12. Application Example application #1: Custom-built application Server resource component totals Resource requirements Equivalent Reference virtual machines Server resources CPU (virtual CPUs) Memory (GB) Storage resources IOPS Capacity (GB) Reference virtual machines Example application #2: Point of sale system Example application #3: Web server Example application #4: Resource requirements Equivalent Reference virtual machines Resource requirements Equivalent Reference virtual machines Resource requirements (5TB) 64