IBM SmartCloud Desktop Infrastructure with VMware View Reference architecture. 12 December 2012

Transcription

1 IBM SmartCloud Desktop Infrastructure with ware View 12 December 2012 Copyright IBM Corporation, 2012

2 Table of contents Introduction...1 Architectural overview...1 Component model...2 ware View provisioning... 4 Storage model... 4 Operational model...4 Compute servers... 4 Management servers... 6 Systems management... 7 Networking... 7 Shared storage... 8 Operational model component summary Deployment diagram Resources...13 Trademarks and special notices...14

3 Introduction This document describes the reference architecture for using ware View 5 on the ESXi 5 hypervisor. It should be read in conjunction with the IBM SmartCloud Desktop Infrastructure (SDI) reference architecture document available at ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure. The business problem, business value, and requirements are described in the IBM SmartCloud Desktop Infrastructure reference architecture and are not repeated here for brevity. This document gives an architecture overview and component model of the ware View and then describes the deployment model of ware View using different number of users. Architectural overview Figure 1 shows all of the main features of the IBM SmartCloud Desktop (SDI) reference architecture with ware View 5.x. Active Directory, DNS SQL Database Server Internet Clients FIREWALL View Connection Security Server or 3 rd party VPN FIREWALL View Connection Server Stateless Desktops Dedicated Desktops ESXi Hypervisor ESXi Hypervisor vcenter Pools Shared Storage vcenter Server Internal Clients Figure 1: SDI reference architecture with ware View 5 This reference architecture also does not address the issues of remote access and authorization, data traffic reduction, traffic monitoring, and general issues of multi-site deployment and network management. This document limits the discussion to the components inside the customer s intranet. 1

4 Component model Figure 2 is a layered view of the IBM SmartCloud Desktop (SDI) infrastructure mapped to the ware View virtualization infrastructure and using the ware ESXi hypervisor. View Administrator vcenter Operations for View Client Client View Client Devices Client Client Administrator GUIs for Support Services HTTP/HTTPS RDP and PCoIP View Connection Server vcenter Server View Composer Management Protocols Dedicated s Stateless s Local SSDs Support Service Protocols Directory DNS DHCP OS Licensing Management Services ESXi ESXi NFS and CIFS View Event Database Repository Linked Clones Shared Storage User Profiles User Data Files SmartCloud Desktop Infrastructure - ware View 5 Support Services Figure 2: Component model for SDI with ware View The main components for ware View using ware ESXi hypervisor are described as follows. The IBM SmartCloud Desktop Infrastructure reference architecture document available at ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure can be used as a guide. ViewAdministrator This web-based application allows administrators to configure ViewConnection Server, deploy and manage View desktops, control user authentication and troubleshoot end-user issues. It is installed during the installation of ViewConnection Server instances and is not required to be installed on local (administrator) devices. vcenter Operations for View This tool provides end-to-end visibility into the health, performance and efficiency of the VDI configuration. It enables administrators to proactively ensure the best end-user experience possible, avert incidents and eliminate bottlenecks, before they become larger issues. 2

5 View Connection Server The ware View Connection Broker, View Connection Server, is the point of contact for client devices requesting virtual machines (s) or desktops. View Connection Server authenticates users and directs the request to the appropriate or desktop, ensuring only valid users are allowed access. After the authentication is complete, users are directed to their assigned or desktop. In case a virtual desktop is not available, the connection broker works with the management and the provisioning layer to have the ready and available. vcenter Server vcenter Server is the managing and provisioning component for View and ESXi. Using a single console, it provides centralized management of the virtualized infrastructure and virtual desktop image management and delivery to the s. Redundancy for vcenter Server is achieved through ware vsphere High Availability (HA). vcenter server also contains a licensing server for ware products, and therefore no separate licensing server is required. ViewComposer In a vcenter server instance, View Composer is installed. View Composer is required, when creating linked clones from a parent. vcenter SQL Server vcenter requires a SQL database. The vcenter SQL server could be Microsoft SQL Server Desktop Engine (MSDE), Oracle, or SQL Server. Because the vcenter SQL server is a critical component, redundant servers must be available to provide fault tolerance. Existing customer SQL databases (including respective redundancy) can be used. ViewEvent database ware View can be configured to records events and their details into a Microsoft SQL Server or Oracle database. Business intelligence (BI) reporting engines can be used to analyze this database. Clients Users can access their virtual desktop from any device supported by the respective desktop virtualization solution; this includes company laptops, home PC, thin -client devices or tablets. IBM does not prescribe any particular approach for clients. Customers can repurpose existing desktops (which is typical for many deployments) or greenfield with thin- or zero -client devices. RDP, PCoIP The virtual desktop image is streamed to the end user access device using the display protocol. Depending on the solution, the choice of protocols available are Remote Desktop Protocol (RDP) and PC over IP (PCoIP). ESXi ESXi is a bare-metal hypervisor running on the compute servers and upon which the s are running. Shared storage In order to minimize cost and complexity, the SDI reference architecture will focus on Network File System (NFS)-attached storage whenever shared storage is required. See Storage model for more details. 3

6 ware View provisioning ware View supports both stateless as well as dedicated models. Provisioning for ware View is a function of vcenter server and View Composer for linked clones. vcenter Server allows for manually created pools as well as automatic pools. Further it allows for provisioning full clones as well as linked clones of a parent image, for both dedicated as well as stateless s. Linked clones are created from a snapshot taken from a golden master image. The golden master image should reside on shared storage area network (SAN) storage, as should the replica. The replica is used to create a copy of the golden image before deploying the linked clones. One pool can contain up to 1000 linked clones. This document covers the use of automated pools, with linked clones, both for dedicated and stateless virtual desktops. Storage model This section describes the different types of shared data stored for stateless and dedicated s. Dedicated s do not use local storage and require the following shared storage items: NFS is used to store all s associated data, like master image and replica for the linked clone. Block I/O can be used but only for full clones. The ware View Composer persistent disk for each user that contains the user profile and user file data that is stored using NFS. Stateless s require the following shared storage items: NFS is used to store all virtual images for linked clones. The linked clones themselves are stored on local solid state drive (SSD) storage. User profiles (from MSRP) are stored using Common Internet File System (CIFS). As an alternative, View Persona Management can be used. User data files are stored using CIFS. Both stateless and dedicated s have these common shared storage items: The vswap (paging file) is transient data that is stored using NFS. Operational model Two separate main operational models are considered here, to cover both stateless and dedicated image models. In some customer environments, both stateless and dedicated image models might be required, thus a mixed operational model is needed. In order to illustrate the operational model for different sized customer environments, four different models are provided for supporting 600, 1500, 4500, and users. Note that the operational model for users is essentially 7 times larger than the model for 1500 users and therefore, user between 1500 and can be extrapolated, by using different multiples of the 1500 user model. Compute servers Compute servers are servers that run the ware ESXi hypervisor and host ware View user s. This reference architecture assumes a memory size of 1.5GB. IBM testing has shown that 125 users per 4

7 server with 256 GB of memory is a good baseline and has on average 75% utilization of the processors in the server. If a server goes down, then users on that server need to be transferred to the remaining servers. For this degraded failover case, IBM testing showed that 150 user per server have on average 90% utilization. It is important to keep this 25% headroom on servers to cope with possible failover scenarios. Other than the limit imposed by the processor power, the number of compute servers required for a given number of users is in direct proportion to the memory size required for the and the number of users. Figure 3 shows the number of users that can be supported given the size (on the horizontal axis) and the amount of memory in the server given a limit of 150 users per compute server. In this reference architecture and in most cases, IBM recommends that the compute server has 256 GB of main memory. If the average size is less than 1.25 GB of memory, then 192 GB of memory is sufficient, as additional memory would be unused. Servers requiring only 128 GB are unlikely because the cut-off point for eliminating wasted memory is <0.75GB per. 160 Memory Available on Server (GB): Number of s Size (GB) 4 Figure 3: Number of users supported by main memory and size The compute servers can be either IBM x240 Flex System nodes or IBM System x 3550 rack servers. The detailed specification is as follows: Processor: 2 x E C 2.9GHz 20 MB Cache 1600 MHz 130 W Memory: 256 GB as 16 x 16 GB DIMMs (2Rx4, 1.5 V PC CL11 ECC DDR3 LP RDIMM) Network interface card (NIC): Emulex Dual Port 10 GbE SFP+ Embedded Virtual Fabric Adapter USB for ware ESXi hypervisor For servers with stateless images, the following components also need to be added: IBM ServeRAID M5115 SAS/SATA Controller 2 x IBM 200 GB SATA emlc SSD (1.8 in. for x240 Flex node or 2.5 in. for x3550 rack server) Table 1 shows the number of compute servers needed for each user size (assuming a size of 1.5 GB): 5

8 Size 1.5 GB 600 users 1500 users 4500 users users Compute users Compute users (failover) Failover ratio 4:1 5:1 5:1 7:1 vcenter clusters (8 servers/cluster) Table 1: ware View compute servers needed Power users require larger s but also need more processor power and therefore it is not usually worth considering servers with more memory than 256 GB. If the s are larger than 1.5 GB, fewer users can be accommodated per server, thus the number of servers needs to be increased appropriately, and memory should be sufficient again on a per -server basis. If the s are smaller than 1.5 GB, then compute servers with less memory can be used because too many users would overwhelm the processor power of the servers. Management servers Management servers have the same hardware specification as compute servers, so you could use them interchangeably in a worst -case scenario. The management servers also use ESXi as the hypervisor, but have management s instead of user s. Table 2 summarizes the requirements and performance characteristics of each management service. Management service Virtual processors Memory Storage Windows OS HA needed Performance characteristic vcenter Server 4 4 GB 15 GB 2008 R2 Yes Up to 2000 s. vcenter SQL Server View Connection Server Table 2: Characteristics of Management Services 4 4 GB 15 GB 2008 R2 Yes Double the virtual processors and memory for more than 2500 users GB 40 GB 2008 R2 Yes Up to 2000 connections. Table 3 lists the number of management s for each size of users following the high-availability and performance characteristics listed Table 2. Note that the number of vcenter servers is half of the number of vcenter clusters shown in Table 2. This is because each vcenter server can handle two clusters of up to 1000s, and each cluster exists on two vcenter servers. type 600 users 1500 users 4500 users users vcenter Servers 2 (3 + 1) 2 (1 + 1) 4 (3 + 1) 14 (10 + 4) vcenter SQL Server 2 (1 + 1) 2 (1 + 1) 2 (1 + 1) 2 (1 + 1) 6

9 View Connection Server 2 (1 + 1) 2 (1 + 1) 4 (3 + 1) 7 (5 + 2) Table 3: ware View management s needed Note that it is assumed that common services such as Microsoft Active Directory, DHCP and DNS servers already exist in the customer environment. Based on the number and type of s, Table 4 lists the recommended number of management servers. In all cases, there is redundancy in both the management servers and the management s. Management servers 600 users 1500 users 4500 users users Stateless model Dedicated model Table 4: Management servers needed As documented earlier, each management requires a certain amount of virtual processors, memory and disk. Note that there is plenty of capacity in the management servers for all of these s. Table 5 has an example mapping of the management s to the 4 physical management servers for 4500 users. type for 4500 stateless users Management server 1 Management server 2 Management server 3 Management server 4 vcenter Server (4) vcenter SQL Server (2) 1 1 View Connection Server (4) Table 5: Management server mapping (4500 users) Systems management Assuming the use of IBM Flex System compute servers, it is recommended to have one or more IBM Flex System Manager nodes in case of the larger configurations, to provide additional systems management capability. Networking As described in the IBM SmartCloud Desktop reference architecture available at ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure there are 3 virtual LANs (VLANs) that each share part of the bandwidth in a 10 Gb Ethernet (GbE) network. All of the compute servers, management servers, and shared storage are connected to the 10 GbE network using a 10 GbE switch. The IBM RackSwitch G8124E and G8264R switches are recommended as they support VLANs using IBM Virtual Fabric. Note that although the IBM PureFlex chassis supports internal 10 GbE switches, these are not used because a separate switch is needed for the external shared storage. The IBM Flex System Fabric EN4091 Pass-thru Module is used to pass the 10 GbE connections to the external switch. For 4500 users or fewer, the IBM G8124E 24-port switch can be used. Above 4500 users, multiple IBM G8264R 48-port switches should be used instead as these switches provide more ports. For redundancy an additional or spare switch should be available. Table 6 summarizes the number of 10 GbE switches for each user size: 7

10 10 GbE network switch 600 users 1500 users 4500 users users G8124E 24 -port switch G8264R 48 -port switch Table 6: 10 GbE network switches needed Separate 1 GbE switches are used for the IT administration network. Again it is recommended that a spare switch should be available in case of failure. Table 7 summarizes the number of 1 GbE switches for each user size: 1 GbE network switch 600 users 1500 users 4500 users users G port switch 2 (1+1) 2 (1+1) 2 (1+1) 3 (2+1) Table 7: 1 GbE network switches needed Shared storage VDI workloads such as virtual desktop provisioning, loading across the network, and access to user profiles and data files place huge demands on network shared storage. This reference architecture first describes the performance requirements of both stateless and dedicated virtual desktops and then shows the storage configuration that meets those requirements. Experimentation with VDI infrastructures shows that the input/output operation (IOP) performance takes precedence over storage capacity. This means that more of the slower speed drives are needed to get the required performance than higher speed drives. Even with the fastest drives available today (15k RPM), there is still can be excess capacity in the storage system. The large rate of IOPs and therefore large number of drives needed for dedicated virtual desktops can be ameliorated to some extent by caching read data in flash memory (flash cache feature of some N series controllers). However there is a limit to how much flash memory is useful because of the relatively low percentage of read operations. In terms of the IBM N series range of storage systems, the largest 15k RPM SAS drive is 600 GB. These disks require a larger expansion cabinet with 24 disks in a 4U enclosure. The same number of slower speed 10K SAS drives in a small form factor (SFF) 2.5 can be put in a 2U enclosure. In this case superior performance wins over the cost of rack density and the storage configurations all use 600GB 15k RPM SAS drives. The storage configurations are based on the peak performance requirement, which usually occurs during a so-called logon storm. This is when all workers at a company arrive at the same time in the morning and try to start their virtual desktops, all at the same time. The storage configurations also have conservative assumptions about the size, changes to the, and user data sizes to ensure that the configurations can cope with the most demanding user scenarios. As mentioned above the storage configurations tend to have more storage that is strictly required in order to meet the performance objectives for IOPs. In the IBM experience this extra storage is more than sufficient for the other types of data needed for VDI such as SQL databases and transaction logs. Note that the storage configurations do not include facilities for data replication, data compression, or data deduplication. These are all value-added features that may or may not be required. These features may 8

11 also have an effect on the storage configuration. The storage configurations, where possible, do include flash memory as a means to cache frequently used data. Stateless virtual desktops Stateless virtual desktops using ware View use SDDs for the linked clones and the AppData folder. Table 8 summarizes the peak IOPs and disk space requirements for stateless virtual desktops on a per user basis. ware stateless virtual desktops Protocol Size IOPs Write % User data files CIFS/NFS 5 GB 1 75% User profile (through MSRP) CIFS 100 MB % Table 8: Stateless shared storage performance requirements Table 9 summarizes the storage configuration needed for each user size. In this case, the flash cache does not help at all so a lower end controller with failover is used. It is also assumed that 100% of the users at peak load times require concurrent access to user data files and profiles. Stateless storage 600 users 1500 users 4500 users users Controller and model number N3240 A24 N3240 A24 N3240 A24 N3240 A24 10 GbE mezzanine cards Flash cache N/A N/A N/A N/A 600 GB 15K rpm drives Spare drives EXN3000 expansion units Table 9: Stateless shared storage configuration Dedicated virtual desktops Table 10 summarizes the peak IOPs and disk space requirements for dedicated virtual desktops on a per user basis. The last two rows are the same as used for stateless desktops. Note that it is a best practice to keep the AppData folder with the linked clones. ware dedicated virtual desktops Protocol Size IOPs Write % Master image Block/NFS 30 GB Linked clones Block/NFS 10 GB 18 85% User AppData folder User files CIFS/NFS 5 GB 1 75% User profile (through MSRP) CIFS 100 MB % Table 10: Dedicated shared storage performance requirements Table 11 summarizes the storage configuration needed for each user size. A mid-range controller with 512 MB of flash cache is used for less than 2000 users as it supports up to only 600 drives. A high-end 9

12 controller is used for more than 2000 users because it has a larger flash cache capability, more 10 GbE ports, and can support up to 1440 drives. It is also assumed that 100% of the users at peak load times require concurrent access to user data files and profiles. Dedicated storage 600 users 1500 users 4500 users users Controller and model number N6240 E21 N6240 E21 N7950T E22 N7950T E22 10 GbE cards Flash cache 512 MB 512 MB 1 GB 1 GB 600 GB 15K rpm drives Spare drives EXN3000 expansion unit Table 11: Dedicated shared storage configuration Operational model component summary Table 12 summarizes the items needed for stateless virtual desktops for each user size: Stateless virtual desktop 600 users 1500 users 4500 users users Compute servers Management servers GbE network switches 2 x G8124E 2 x G8124E 3 x G8124E 3 x G8264R 1 GbE network switches 2 x G x G x G x G8052 PureFlex Flex System Manager nodes (when needed) Flex chassis with EN4091 pass-thru module (when needed) Storage servers N3240 A24 N3240 A24 N3240 A24 N3240 A24 Storage extensions N/A N/A EXN3000 x 2 EXN3000 x 6 Total height (Flex System servers) 18U 18U 47U 107U Total height (x3550 rack servers) 15U 22U 57U 125U Number of racks Table 12: Operational model summary for stateless virtual desktops Table 13 summarizes the items needed for dedicated virtual desktops for each user size: Dedicated virtual desktop 600 users 1500 users 4500 users users Compute servers Management servers

13 10 GbE network switches 2 x G8124E 2 x G8124E 3 x G8124E 3 x G8264R 1 GbE network switches 2 x G x G x G x G8052 PureFlex Flex System Manager nodes (when needed) Flex chassis with EN4091 pass-thru module (when needed) Storage servers N6240 E21 N6240 E21 N7950T E22 N7950T E22 Storage extensions EXN3000 x 2 EXN3000 x 6 EXN3000 x 16 EXN3000 x 28 Total height (Flex System servers) 28U 44U 111U 203U Total height (x3550 rack servers) 25U 48U 121U 221U Number of racks Table 13: Operational model summary for dedicated virtual desktops Deployment diagram Figure 4 shows the deployment diagram for an IBM Flex System-based system that supports 4500 stateless users. The first rack contains the compute and management servers and the second rack contains the storage servers and disks. 11

14 Cxx M1 s vcenter Server Connection Server M2 s vcenter Server Connection Server vcenter SQL Server Each compute server has 125 user s M4 s vcenter Server Connection Server M3 s vcenter Server Connection Server vcenter SQL Server Flex Chassis 1 Flex Chassis 2 Flex Chassis 3 C1 C3 C5 C7 C9 C11 M4 C13 C19 C21 C23 FSM 1 GbE Switch 1 GbE Switch 10 GbE Switch 10 GbE Switch C15 C17 C25 C27 C29 C31 C33 C35 FSM EN4091 Pass-thru EN4091 Pass-thru EN4091 Pass-thru C2 C4 C6 C8 C10 C12 M1 C14 C16 C18 C20 C22 C24 M2 C26 C28 C30 C32 C34 C36 M3 10 GbE Switch IBM N3220 A24 DS4243 Extension (24 x 600GB 15k RPM) DS4243 Extension (24 x 600GB 15k RPM) DS4243 Extension (24 x 600GB 15k RPM) Rack 1 Rack 2 Figure 4: Deployment diagram for 4500 stateless users 12

15 Resources IBM SmartCloud Desktop Infrastructure reference architecture ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure ware View 5 vmware.com/products/viewl ware vsphere vmware.com/products/datacenter-virtualization/vsphere 13

16 Trademarks and special notices Copyright IBM Corporation References in this document to IBM products or services do not imply that IBM intends to make them available in every country. IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. Information is provided "AS IS" without warranty of any kind. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Information concerning non-ibm products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-ibm list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-ibm products. Questions on the capability of non-ibm products should be addressed to the supplier of those products. All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction. Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here. Photographs shown are of engineering prototypes. Changes may be incorporated in production models. Any references in this information to non-ibm websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk. 14