Always On Point Care Hovesatden Q413

Transcript

VMware® AlwaysOn Point of Care™ Solution Reference Implementation Case Study for European Healthcare Provider Including Architecture for 25,000 End Users in a Multi-Datacenter Implementation T E C H N I C A L W H I T E PA P E R VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Table of Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 About VMware Reference Implementation Case Studies. . . . . . . . . . . . . . . . . . . . . . . . . . 5 Executive Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Implementation Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Architecture Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 About VMware Horizon View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 VMware Horizon View Solution Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Region Hovedstaden Reference Implementation Overview. . . . . . . . . . . . . . . . . . . . . . . 11 Business Drivers, Business Case, and Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Business Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Business Case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Business Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 VMware Expertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Implementation Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Region Hovedstaden VDI Solution Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 VMware Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 VMware Horizon View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 End User Persona, Session and Device Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 External Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Application Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Business Continuity and Disaster Recovery (BCDR). . . . . . . . . . . . . . . . . . . . . . . . . 20 About the Authors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Additional Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 About VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 T E C H N I C A L W H I T E PA P E R / 2 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Appendix A (Architecture Design). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Horizon View Pod. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Horizon View Block 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Horizon View Management Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Logical Storage Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Storage Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Logical Network Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Standard vSwitch Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Distributed Virtual Switch Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Network Physical Design Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Network Optimization for PCoIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Load Balancing Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Business Continuity and Disaster Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Disaster Recovery (DR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 View Connection Server Architecture Redundancy. . . . . . . . . . . . . . . . . . . . . . . . . . 38 Datacenter Outage of LOCATION1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Floating Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Datacenter Outage of LOCATION2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Floating Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Recovery of a Datacenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Floating Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix B (Technical Design Specifications) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Horizon View Management Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 View Connection Server Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 View Connection Server Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Horizon View Desktop Pool Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Parent Desktop Virtual Machine Virtual Hardware Specifications. . . . . . . . . . . 42 Horizon View Desktop Operating System Specifications . . . . . . . . . . . . . . . . . . 42 Horizon View Desktop OS Optimizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Operating System Deployment Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Horizon View Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Active Directory Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Dedicated OU for Horizon View Desktop, Server, and User Accounts. . . . . . . 45 Group Policy Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Antivirus Scanning and Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 VMware ThinApp Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 VMware vSphere Clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 VMware vSphere High Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 VMware vSphere Distributed Resources Scheduler (DRS). . . . . . . . . . . . . . . . . 50 T E C H N I C A L W H I T E PA P E R / 3 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Resource Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Horizon View Pod. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Horizon View Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 View Composer Design Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 View Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 View Events Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 View Events Connection Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Sizing VMware ESXi Hosts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 CPU Sizing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Memory Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Sizing Shared Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Horizon View Desktop Disks and Datastores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Desktop Datastore Configuration Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Storage Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Virtual Desktop Storage Workload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 T E C H N I C A L W H I T E PA P E R / 4 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Introduction This document provides a reference implementation case study for VMware® Horizon View™ at a Danish healthcare customer. The case study represents a 25,000-user environment deployed across multiple physical locations, based on the VMware AlwaysOn Point of Care™ desktop solution. The intended audience for this document is the technical decision-maker who is considering deploying VMware Horizon View at scale. The Executive Summary and Business Drivers, Business Case, and Benefits sections of this document are also suitable for non-technical decision-makers. The purpose of this document is to illustrate how this technical solution can provide tangible business benefits. The document includes an overview of business benefits and cost savings (where possible), an architectural overview and its bill of materials, and key configurations used to deploy the solution. About VMware Reference Implementation Case Studies A reference implementation case study shows how specific customers in a variety of locations and industry verticals have deployed and benefited from VMware Horizon View. A reference implementation describes in detail the project approach, architecture, and business benefits at a real customer site, and provides lessons learned for that particular deployment. These implementations are often built on reference architectures validated by VMware. While a reference implementation is often built on best practices, sometimes tradeoffs are made to meet project requirements or constraints. When a reader references these implementations, it is critical to understand where the architecture has deviated from best practices, and where improvements can be made. This is easily achieved by comparing a reference implementation to reference architecture documentation provided by VMware. For further information regarding this and other technical reference architectures, visit VMware Horizon View 5.2 Design resources on the VMware Web site. This case study is intended to help customers—IT architects, consultants, and administrators—involved in the early phases of planning, design, and deployment of VMware Horizon View solutions. The purpose is to provide an example of a successful architecture that represents specific industry vertical challenges met, and the benefits gained from the solution. T E C H N I C A L W H I T E PA P E R / 5 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Executive Summary By the mid-2000s, the Danish government faced an extraordinary challenge. The legacy IT systems at many of its healthcare providers were negatively impacting patient care. Excessive login and access times to applications and data were causing doctors and nurses to spend less time in front of each patient. IT departments were spending their efforts on setting up and maintaining individual PCs for each clinical worker. The situation was so out of balance that the Danish government legislated their healthcare providers to improve it. For one healthcare region, Region Hovedstaden (Region H), administrators developed a bold plan to transform their point-of-care desktop system. Region H deployed a virtual desktop infrastructure (VDI) solution, which significantly reduces the person-hours that it takes for healthcare professionals to access applications and data. IT now deploys a common desktop to all healthcare workers with a universal PC configuration. This saves time in setting up and provisioning desktops, fixing them, and deploying applications. Two-year project 25,000 users with access to the solution 8,000 concurrent virtual desktops Figure 1: Implementation Highlights Implementation Overview Region H named the project Effective System Access (ESA). Region H tasked its IT department with implementing the ESA program for 25,000 healthcare workers, providing them with an effective, fast, and agile workspace, accessible from any device, anywhere. IT managers evaluated a number of possible solutions as the platform for ESA, and chose the VMware AlwaysOn Point of Care solution, based on VMware Horizon View. The IT organization at Region H viewed VMware technology as the cornerstone of its VDI solution. “We chose VMware for this project because of its product and engagement flexibility, which we saw in the pilot phase,” said Morten Møllegaard, lead technical project manager. “This has lived up to our expectations during the production implementation.” Project Overview When the Danish healthcare system tasked Region Hovedstaden with providing an effective, fast, and agile workspace for 25,000 clinical workers, the implementation team quickly identified several key drivers. There was a need to streamline application delivery across multiple desktop types, as well as provide secure remote access for doctors and healthcare workers. Even more important was the directive to drastically lower clinicians’ login and reconnect times, while allowing users to keep the same desktop between sessions. T E C H N I C A L W H I T E PA P E R / 6 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Region H launched the project in October 2009 with an initial assessment of three different solutions. After almost 12 months of financial and technical validation, in November 2010 the IT department chose VMware as the vendor for the solution. From December 2010 to December 2011, Region H implemented a pilot infrastructure, and a full production environment, including load testing, working closely with VMware. “Working with VMware has proven to be a great benefit for the project,” said Møllegaard. “This way we got quick and direct access to SMEs, and we got focus from VMware management. Further, we have had great use of our TAM (Technical Account Manager)—when a service request for some unknown reason got delayed, he could push it forward, and we always had a ‘VMware internal’ speaking for the customer.” Lessons Learned As is common with customers deploying new technology for the first time, Region H faced many challenges along the way. The key lessons learned were divided among Project, Technical, and Operations categories, as outlined in Figure 2. Project • Technical project management needed • Invest in educating users on the benefits of VDI and how to use it • Keep it simple – don’t add more to project scope than needed • Phased approach to deployment • In a large organizations, decisions take time • ESA has a lot of interfaces to other projects and operations in Region H • Work closely with vendors Technical • Ensure you understand the impact and benefits of upgrades and patches • Ensure your infrastructure adequately supports VDI, specifically networking and storage • Optimize OS image • Validate applications work as expected over a remote protocol or with redirected devices • Validate the SAN can provide the necessary IOPS for good user experience Operations • Operational staff need to have good knowledge of infrastructure and implementation and how to monitor it • Implementing VDI involves many different technical aspects from basic infrastructure to general usage of smarts cards in the organization • Changing the operations organization during implementation adds further complexity • Have a process in place to apply updates and patches Figure 2: Key Lessons Learned Architecture Overview Region Hovedstaden opted for a solution that implemented VMware Horizon View across two datacenters to allow for 24/7 operation of the platform. Horizon View is the software component that brokers client requests, and authenticates and allocates virtual desktops to users. The design follows the VMware best practice reference architecture approach of Horizon View blocks, which together make up a single 10,000-desktop pod. The IT organization duplicated the pod approach in a second datacenter to provide multisite failover and disaster recovery. T E C H N I C A L W H I T E PA P E R / 7 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Conclusion In less than two years since Region Hovedstaden launched the ESA project with its initial design and implementation, the healthcare system was able to bring all 25,000 users into the production environment, with support for up to 8,000 concurrent users. IT based the solution on 24/7 support requirements, as users must be able to access the platform at any time. With the ESA solution • End-users save substantial time on a daily basis, with logins shortened from 45 minutes to 3 to 5 minutes. • Users experience improved productivity, as they are now able to transfer an open work session among different terminals. • Region H has reduced support costs when using zero clients – IT is able to provision zero client endpoints at a time savings of one hour each. • Users have single sign-on and simplified access to the applications they need. T E C H N I C A L W H I T E PA P E R / 8 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider About VMware Horizon View VMware Horizon View is a desktop virtualization solution that simplifies IT manageability and control while delivering the highest fidelity end-user experience across devices and networks. The VMware Horizon View solution helps IT organizations automate desktop and application management, reduce costs, and increase data security by centralizing the desktop environment. This centralization results in greater end-user freedom and increased control for IT organizations. By encapsulating the operating systems, applications, and user data into isolated layers, IT organizations can deliver a modern desktop. IT organizations can then deliver dynamic, elastic desktop cloud services such as applications, unified communications, and 3D graphics for real-world productivity and greater business agility. Unlike other desktop virtualization products, VMware Horizon View is built on and tightly integrated with VMware vSphere®, the industry-leading virtualization platform, allowing customers to extend the value of VMware infrastructure and its enterprise-class features such as high availability, disaster recovery, and business continuity. VMware Horizon View delivers important features and enhancements that improve the performance, security, management, and flexibility of virtual desktops. Support for VMware vSphere 5 leverages the latest functionality of the leading cloud infrastructure platform for highly available, scalable, and reliable desktop services. For additional details and features available in VMware Horizon View, see the release notes. T E C H N I C A L W H I T E PA P E R / 9 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider VMware Horizon View Solution Components Typical VMware Horizon View deployments consist of several common components, shown in Figure 3, which represent a typical architecture. The solution includes VMware Horizon View components as well as other components commonly integrated with Horizon View. Private Cloud (vSphere) Na t Apive Th p i VirnApp tu Ap al Sho p r Th tcut V View Composer Parent Image VM Linked Clones iew OS VM VM VM VM Ag e Vir inAp to tua p l Ap p nt VM VM Hy VM pe r (E viso SX rs ) vCenter ThinApp Virtualized Application Repository Local Mode Only View Administrator (Browser) View Connection Server(s) View Transfer Server(s) MS Active Directory Local Mode Only For PCoIP Direct Connect Local Mode Only View Security Server(s) External Network Internal Network Local Connection Remote Connection Intermittent Network Connection Horizon View Clients Android Tablet iPad Zero Client Thin Client Windows Horizon View Client Macintosh Horizon View Client Windows Horizon View Client with Local Mode Figure 3: VMware Horizon View Solution Components T E C H N I C A L W H I T E PA P E R / 1 0 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Region Hovedstaden Reference Implementation Overview The Danish healthcare system tasked Region Hovedstaden with providing an effective workspace for 25,000 clinical workers in their region, with the overall business objective of implementing the ESA program. ESA would streamline application delivery across multiple desktop types, utilize single sign-on (SSO), and drastically lower the time that clinicians were spending on login and application launches. The IT organization at Region H implemented the VMware Horizon View solution over a two-year period, including testing and user education. They also designed for platinum service, which benefits users with 24/7 support, and a stable platform that takes into account business continuity and disaster recovery (BCDR). The following reference implementation study tells the story of how Region H successfully addressed each of the requirements of the program. It shows how Region H and its key partners were able to plan and implement a VDI solution that serves 25,000 total users and up to 8,000 concurrent desktops, efficiently and costeffectively, in just 24 months. It also describes key lessons learned along the way—valuable information and insights for other companies contemplating their move to VDI. Business Drivers, Business Case, and Benefits Region H set out to build ESA from a set of guidelines given them by the Danish Healthcare Institute, to lower user time spent on login, connect, and reconnects, and for users to be able to keep the same desktop between sessions. The overall project goal was aligned with the requirements of an effective, fast and agile platform— VMware Horizon View. Business Drivers • Healthcare workers waiting 45 minutes or more for desktop access throughout the day • Old and ineffective remote access for doctors • Slow access to applications and data Business Case Business Benefits • Users save time on login and when moving locations • Fast access to software, especially when zero clients are used • VDI meets Danish government requirements • Common desktop to manage • IT saves time on setup of client devices • Users unable to access desktops remotely • IT saves time on administering and fixing desktops • IT managing many different distributed PCs • VDI approach to ESA deemed best TCO/ROI • Ease of updating applications to the VDI desktop • Single sign-on (SSO) • Remote access to desktops outside RegionH network • Constant availability Figure 4: ESA Business Drivers, Business Case, and Business Benefits T E C H N I C A L W H I T E PA P E R / 1 1 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Business Drivers The key driver behind the move toward VDI came from a directive to lower the login and reconnect times experienced by health workers. Prior to ESA, Region H clinicians wasted an average of 45 minutes each day waiting to log in to a desktop. The issue was that workers shared PCs, and had to log in and log out each time they wanted to access their applications. The situation was compounded because they had to start up their applications each time. Large user profiles, and transferring data from the datacenter to a PC, also caused slow login times and further frustration. In addition, there was no secure remote access for doctors and healthcare workers who needed to access applications and data from outside the hospital. Maintaining and managing full PCs deployed across 13 hospitals, often with different configurations, was an administrative nightmare for the IT organization. Fixing PCs remotely, applying patches, and generally dealing with machines with different application sets, cost IT time and money. Business Case The business case for moving to VDI was clear for Region H, based on the projected time-savings users and the IT organization would gain with the new solution. Danish government legislation mandated the ESA system. Based on the evaluation of three different solutions, VMware was chosen based on its ability to meet requirements and the overall cost. It’s common for VDI to provide extensive OpEx savings for IT; but in this case the key benefit was that it reduced the huge number of man-hours wasted by healthcare professionals when accessing applications and data. From an IT perspective, time-savings were seen across the board, from client device setup and desktop provisioning, to fixing desktops and deploying applications. Application virtualization allowed IT to deploy a common desktop to all users, saving time by managing a common PC configuration. Business Benefits The benefits of the system were realized immediately. Doctors and nurses could complete a first-time login to their desktop within two minutes and a reconnect in only seven seconds, regardless of their location, saving huge amounts of time each day. By using single sign-on, the users had to authenticate only once to access their applications. Doctors were also given the ability to access their desktop sessions securely from outside the hospital. This functionality provides greater flexibility for the Region H workforce. The benefits of deploying small, easy-to-clean, “healthcare friendly” zero client devices with lower management overhead, freed the IT organization to focus on improving the centralized infrastructure. IT manages desktops in the datacenter by using VMware View Composer™ technology alongside application virtualization, with VMware ThinApp® to deploy stateless desktops. This allows IT to manage a single common desktop image from a central management console. VMware ThinApp also provides the ability to update and fix applications from a single central repository, without having to fix applications on individual PCs, saving time. T E C H N I C A L W H I T E PA P E R / 1 2 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Project Overview As with any project the size and scope of the Region Hovedstaden VDI implementation, multiple partners were involved in the overall solution deployment. In this case, the prime contractors were Dell, which provided computers, network infrastructure, and storage; NNIT, which provided services and a proof of concept; VMware, which delivered services and technical advice; Imprivata Software, which provided single sign-on (SSO); and other partners. Solution Assessment Proof of Concept Upgrade / Patch Pilot (User Acceptance) Tuning / Expansion Phased Rollout Load Testing Figure 5: Region Hovedstaden Project Phases “It has been a long road to the goal—but by being agile and faithful to the initial goal, we have managed to give our 25,000 users a good and stable solution,” said Morten Møllegaard, the lead project manager. “One of the most important things in a project like this is to make all major vendors work as one, due to the complexity and the many moving components that make up the solution. We have succeeded in this with the help of VMware as a key partner in their Lighthouse program,” said Møllegaard. VMware Expertise VMware Lighthouse and VMware Professional Services Organization (PSO) were engaged early in the project phase. “Working with VMware Lighthouse and PSO has proven to be a great benefit for the project, as we got quick and direct access to SMEs from VMware, as well as a clear focus from the VMware management level,” said Møllegaard. T E C H N I C A L W H I T E PA P E R / 1 3 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Implementation Timing Undertaking a project like ESA for Region H would by far be the largest healthcare VDI solution in Northern EMEA. It has set new standards for VDI-based computing in the region, and required detailed planning and a phased approach. In late November 2010, the IT organization chose VMware Horizon View as the platform that would fulfill the project requirements. After this decision, the assessment, design, and implementation phase began. In early 2011 the request for tender went out for both the hardware and software required for the solution, and not long after IT chose the infrastructure platform that VMware vSphere and Horizon View would be mounted on. As the design, implementation, and load testing began, shortcomings in the existing infrastructure were uncovered. While this led to small delays, it also served as a basis upon which the ESA project team found it could work more closely with the existing IT operations at Region Hovedstaden. Less than a year after the request for tender went out, the first users were able to access the ESA platform. This was a phased approach where user education was a big part of the success. Each hospital had its own onboarding process, where resources across the project helped make sure that the rollout was a success, and each user learned how to best leverage the ESA platform for their daily work. The user onboarding and education took 10–12 months. It has been an ongoing effort between all the vendors involved in the project, with support from VMware to help ensure that upgrades and changes to the platform follow VMware and vendor best practices. T E C H N I C A L W H I T E PA P E R / 1 4 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Lessons Learned Projects at this scale will almost always face challenges, and this was no exception at Region Hovedstaden. Agile project management was key to why these challenges can now be referenced as lessons learned rather than causes for failure. Project • Technical project management needed • Invest in educating users on the benefits of VDI and how to use it • Keep it simple – don’t add more to project scope than needed • Phased approach to deployment • In a large organizations, decisions take time • ESA has a lot of interfaces to other projects and operations in Region H • Work closely with vendors Technical • Ensure you understand the impact and benefits of upgrades and patches • Ensure your infrastructure adequately supports VDI, specifically networking and storage • Optimize OS image • Validate applications work as expected over a remote protocol or with redirected devices • Validate the SAN can provide the necessary IOPS for good user experience Operations • Operational staff need to have good knowledge of infrastructure and implementation and how to monitor it • Implementing VDI involves many different technical aspects from basic infrastructure to general usage of smarts cards in the organization • Changing the operations organization during implementation adds further complexity • Have a process in place to apply updates and patches Figure 6: Key Lessons Learned The overall solution was made up of technologies from several key vendors including Dell, Cisco, VMware, Teradici, Imprivata, F5, and Microsoft. Ensuring that all vendors were integrated into the project and working with the project team was critical, and this integration was a focus of the project management team from the beginning. A technical implementation of a VDI solution is only part of the challenge in such a large project. An even more critical component is integration and user adoption of the solution. Region H learned early on that user education, alignment with internal policies, and user onboarding go hand-in-hand. One of the challenges in every large organization is that organizational decisions take time to complete, as they can potentially have an impact on the daily work of thousands. The IT organization, therefore, made sure that the leadership at Region H was involved in decision-making, so they were able to plan ahead and keep everyone up to date with progress, changes, and challenges. A VDI project touches upon many components, from the end user to back-end systems, including everything from smart-card solutions to printers, network optimization, different endpoints, and so on. IT had a directive to keep the solution as simple as possible, to not overcomplicate an already complex project. T E C H N I C A L W H I T E PA P E R / 1 5 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider As the project progressed, it became apparent that any changes made to the environment would have to be treated as add-ons to the overall goals. This made for a more agile approach, where Region H kept a clear focus on the initial project plan, but was also able to evaluate and take on new requests and requirements as they came up. This also aligns well with the approach of managing the many small projects that make up a complete VDI project, as they are much more complex to handle than just one big project. Integration, user education, infrastructure changes, and unforeseen challenges made the project management team at Region H realize how complex a project like this can be. The integration aspect of the ESA project uncovered shortcomings or technical challenges in the existing infrastructure. This also had a positive impact, as the ESA project helped streamline and optimize the existing infrastructure already in place. T E C H N I C A L W H I T E PA P E R / 1 6 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Architecture Overview The VDI solution selected by Region Hovedstaden is a hosted model where desktops are virtualized and run on Type 1 hypervisors hosted in two datacenters. VMware Horizon View is tightly integrated into VMware vSphere 5.1, which provides ease of management and less complexity than comparable VDI solutions. Region H deployed the solution on Dell computers and EqualLogic storage technology. For this implementation, IT designed a building block–based desktop solution capable of supporting 1,800 virtual desktops. This ensures that the architecture is repeatable and scalable for future expansion. The solution includes the typical components necessary to integrate up to 10,000 users into a Horizon View pod, which can be managed as a single unit by leveraging a 1,800-user building block as the single replicated entity. Figure 7 details the architecture for the Horizon View pods. Two pods were deployed, with one in each datacenter used by Region H for BCDR scenarios. ~1,800 Users ~1,800 Users ~1,800 Users ~1,800 Users View Block View Block View Block View Block vSphere Cluster vSphere Cluster vSphere Cluster vSphere Cluster View Desktop Pools View Desktop Pools View Desktop Pools View Desktop Pools ESXi Hosts ESXi Hosts ESXi Hosts ESXi Hosts Shared Storage Shared Storage Shared Storage Shared Storage Switched Ethernet Network vCenter-Block 1 vCenter-Block 2 vCenter-Block 3 vCenter-Block 4 Composer Block 1 Composer Block 1 Composer Block 1 Composer Block 1 SSO vSphere Web Client SSO vSphere Web Client View Connection Server View Connection Server View Connection Server View Connection Server View Connection Server View Security Server View Security Server View Connection Server AD/DNS/DHCP MSSQL (Mirrored) Imprivata Appliance (Mirrored) Dell Management Server Workload vSphere Cluster Server Workload ESX Hosts Server Storage (Dedicated Arrays) VMware View Management Block View Pod Figure 7: Architecture Overview T E C H N I C A L W H I T E PA P E R / 1 7 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider The IT organization architected the VDI solution to accommodate View 5.1, a release that provides enhanced scalability and functionality over previous versions. View 5.1 includes the ability to use multiple tiers of storage to run virtual desktops, and great improvements in PCoIP performance. It also features better support for USB peripherals, which was a critical component in Region Hovedstaden’s use cases. The VDI desktops are hosted in two datacenters with duplicate infrastructures running on dedicated Dell hardware. The hardware runs the VDI desktops and View Connection brokers, while the VMware vCenter™ servers run within dedicated hardware separate from the desktop workloads. The load between datacenters is handled manually via DNS records (see Figure 6), as well as by a F5 BIG-IP solution that provides users with seamless external access to their data. Region Hovedstaden VDI Solution Elements • Zero clients – Users connect to their virtual desktop via hardware devices, or software clients installed on existing PCs. Depending on the configuration of the load balancers, they are directed to one of the two datacenters. • F5 BIG-IP – The LTM and APM perform the role of the load balancer, redirecting incoming external connections to the datacenter where the user has their desktop available. This logic is based on Active Directory group membership. • Connection brokers – Five connection brokers exist within each datacenter, and are hosted on the dedicated infrastructure hardware. They perform the initial authentication and desktop allocation as well as monitor the state of the desktop session. • Horizon View block – The underlying vSphere infrastructure is built on Dell and EqualLogic, and configured per Dell and VMware best practices. • Management block – The VDI vCenter servers (five per datacenter) are hosted within the dedicated management block hardware. • Infrastructure components – All infrastructure components are hosted local to the Horizon View solution— domain controllers, file servers, print servers, etc. are as close as possible to the actual desktop. VMware Infrastructure The VMware vSphere infrastructure is deployed on Dell technology. The Horizon View blocks are based on Dell PowerEdge M910 blades with 32 cores and 256GB RAM. The management block runs on Dell PowerEdge M610 servers containing 16 cores and 64GB RAM. Each datacenter is sized for up to 6,000–8,000 active desktop sessions, even though only 3,000 are running during normal operations. Sizing for 6,000–8,000 per datacenter accommodates the full load should an outage happen at one of the datacenters. Following VMware best practices, the Horizon View pod-and-block design introduces a vCenter for every 2,000 desktops—one for every Horizon View block. Note: The initial hardware sizing was for 1,500 users per block, with the potential to add additional hardware to allow up to 2,000 desktops. At the time of this writing, the maximum capacity is 1,800 users per block. T E C H N I C A L W H I T E PA P E R / 1 8 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Each Horizon View block has its own EqualLogic PS6000XVS series cluster connected via 10GbE. The storage solution is based upon tiers, where replica and linked clones are placed on separate iSCSI-based VMFS datastores. Both replicas and linked clones are served up from SSD disks to accommodate the load generated. TI E R P URP OS E SIZE DISK MAXIMU M LIMITS 1 Replica 100GB SSD • 15 replicas per datastore 2 Linked clones 225GB SSD • 100 linked clones per datastore 3 Profile data master image 250GB 250GB SSD/SAS SSD/SAS • N/A Table 1: Replicas and Linked Clones on Separate Datastores Each vSphere ESXi host is connected to both standard vSwitches and a distributed vSwitch. The first standard vSwitch is for management connectivity to top-of-rack 1Gbit equipment, and the second is for 10GbE iSCSI connectivity to the storage on dedicated 10GbE interfaces. The distributed vSwitch is used for desktop and VMware vSphere vMotion® traffic, and is connected to a redundant network backbone, to which the two standard vSwitches are also connected. The vMotion traffic carries a lower weight than desktop traffic to make sure vMotion does not interfere with critical desktop communications, such as PCoIP. VMware Horizon View The clinical personnel at Region Hovedstaden use a variety of different devices for accessing the Horizon View environment. Windows PCs, zero clients, thin clients, iPads, and Mac laptops are all part of the solution. The solution when accessed internally connects users directly to the View Connection Servers, which sit behind load balancers. Users are directed to a predefined datacenter, based on a DNS CNAME record for each datacenter. This means that all client devices owned and operated by Region H are preconfigured to point to each hospital’s designated datacenter. Following VMware best practices, each connection server is sized for 2,000 concurrent connections to allow for future growth, and for the potential 10,000 concurrent connections for a View pod. This requires four vCPUs and 10GB of memory in each View Connection Server. Each desktop is configured with two vCPUs and 2GB of memory. IT chose this approach to maintain only a single master image virtual machine configuration, as this configuration will span all users and their resource needs. The system utilizes VMware vSphere transparent page sharing (TPS) and zero pages, so that a user only using 1GB of memory will not waste resources on the underlying vSphere platform. End User Persona, Session and Device Design ESA is a dedicated solution that leverages existing user accounts; but IT management had no requirements to bring in existing user desktop experiences. With that in mind, IT built a custom solution around application delivery using only ThinApp applications, which would allow Region Hovedstaden to build out the desktop and applications upon login. With only a single master image and all applications present as ThinApps, it was possible to achieve this using custom tools, login scripts, and group policy objects (GPOs). Each user group had different requirements for session length, which initially proved to be problematic as these had to be defined on a per-desktop pool basis. IT made a decision to try to bring everyone to the same session timeout value of five hours, even though this would increase the number of running desktops. After forcing the use of TPS and load-testing the environment, IT proved that the impact of setting every desktop pool with the same session length could be accomplished without overutilizing the infrastructure where the desktops were running. T E C H N I C A L W H I T E PA P E R / 1 9 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Devices The main use case for the ESA project was that users should be able to access the solution internally from endpoints controlled and owned by Region Hovedstaden. The IT organization also had a requirement to reuse existing Windows-based desktops, which they achieved by locking down the desktops. Then they preconfigured the Windows software–based Horizon View Client so the transition to ESA was seamless to the user. Operationally, an overhead is associated with having to manage an underlying Windows OS even though it’s only used for Horizon View access. Zero clients had always been a big part of the overall vision for ESA, as they proved beneficial in ways beyond being easier to manage and update. The physical form factor of the zero client devices made them good candidates for clinical environments and surgeries, as they can be easily cleaned. External Access Later in the project cycle, it became clear that IT would be required to provide external access to the solution. How could Region Hovedstaden achieve a secure and auditable platform, while providing its users with the freedom to work from anywhere? IT designed the system with View Security Servers and an F5 BIG-IP APM solution, which together provide SSO capabilities and two-factor authentication. This allowed for a Bring Your Own Device (BYOD) policy, so users can securely access the environment when working outside the premises of Region H’s hospitals, with any Horizon View–supported endpoint device. Application Provisioning Application delivery was an initial aspect of the overall solution, and Region Hovedstaden understood the importance of finding a stable platform for application delivery. IT management chose VMware ThinApp to deliver applications to all 25,000 users. They built a custom entitlement tool to make the solution as flexible as possible, which fit perfectly with another requirement: having only a single master image to manage. Business Continuity and Disaster Recovery (BCDR) The Horizon View environment benefits from the inherent features of VMware vSphere High Availability (HA). IT created backup and restore procedures for the Horizon View environment, including critical infrastructure components. T E C H N I C A L W H I T E PA P E R / 2 0 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Region Hovedstaden implemented the Horizon View solution in two datacenters, which run active-active with hospitals pre-allocated to a specific datacenter. Figure 8 illustrates the high-level access architecture of the solution. Local Users (H/W or S/W) Client Sites (Hospitals) Local Users (H/W or S/W) Local Users (H/W or S/W) Client Sites (Hospitals) Client Sites (Hospitals) Site 1 Site 2 Load Balancer Load Balancer vCenter Servers vCenter Servers LAN LAN Virtual Desktops VM VM VM ESXi Hosts Horizon View Pod Virtual Desktops VM VM VM ESXi Hosts Horizon View Pod Figure 8: Solution Implemented in Two Datacenters Clients are allocated to datacenters (Horizon View pods) on a per-hospital basis. All clients at a given location are pointed to a DNS CNAME record, which can easily be changed in case of failure to point over to the other datacenter. This is a manual approach that has some operational overhead, but is easy to implement and comes at a low cost. T E C H N I C A L W H I T E PA P E R / 2 1 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Conclusion In less than two years, Region Hovedstaden has brought 25,000 clinical workers across a 13-hospital region into a 24/7 production environment. The Region H ESA solution supports up to 8,000 concurrent users, who can access the platform at any time, from any location. The ESA project delivered on the requirements defined by the Danish healthcare organization. According to Morten Møllegaard, Region H has realized a full spectrum of benefits from the VDI solution, as shown in Figure 9. Users Save Time on a Daily Basis A clinical worker now uses approximately 3 to 5 minutes on login and application starts compared to 45 minutes on the old platform. Improved End-User Productivity • All clinical personnel can now switch between terminals of different kinds and keep their session in between. • This greatly improves productivity, so time can be spend on patient care rather than operating IT. Reduced Support Costs When provisioning new zero client endpoints to users, Region H saves over one hour compared to regular physical desktops. SSO and Simplified Application Delivery Users are able to leverage SSO for the applications that support it, and application delivery is faster and easier with the use of ThinApp and custom delivery mechanisms. Figure 9: VDI Solution Benefits Region Hovedstaden is now at a point where the initial platform delivered lives up to the expectations of its users. Region H is looking into an upgrade project that would move ESA from Windows XP to Windows 7 in the near future. T E C H N I C A L W H I T E PA P E R / 2 2 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider About the Authors Matt Coppinger is a Group Product Manager at VMware End-User Computing. Rasmus Jensen is an EUC Architect at VMware End-User Computing. VMware would like to acknowledge the following individuals for their contributions to this paper and the project, as well as for providing information relating to the project approach, architecture, design, and implementation: VMware – John Dodge, Casper Larsen Region Hovedstaden – Morten Møllegaard NNIT – Gert Ejner Nielsen References VMware Horizon View VMware vSphere VMware Horizon View Technical Resources VMware Horizon View Documentation VMware vSphere Documentation Additional Resources For more information or to purchase VMware products, call 1-877-4VMWARE (outside North America dial +1-650-427-5000), or visit www.vmware.com/products, or search online for an authorized reseller. For detailed product specifications and system requirements, please refer to the VMware Horizon View documentation. About VMware VMware, the global leader in virtualization and cloud infrastructure, delivers customer-proven solutions that accelerate IT by reducing complexity and enabling more flexible, agile service delivery. VMware enables enterprises to adopt a cloud model that addresses their unique business challenges. VMware’s approach accelerates the transition to cloud computing while preserving existing investments and improving security and control. With more than 250,000 customers and 25,000 partners, VMware solutions help organizations of all sizes lower costs, increase business agility and ensure freedom of choice. T E C H N I C A L W H I T E PA P E R / 2 3 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Appendix A (Architecture Design) Horizon View Pod The Horizon View pod is the core of the logical VMware View Manager™ architecture design, as shown in Figure 10. The Horizon View pod is comprised of the following components: View Connection Servers – There are six View Connection Servers in one replicated cluster. These operate in a 4+2 configuration, four View Connection Servers actively brokering and possibly tunnelling connections, and two in failover mode. View Security Servers – There are two security servers in this design. Security servers are paired directly with a single View Connection Server. A View Connection Server may have more than one associated View Security Server. Horizon View blocks – There are eight Horizon View blocks in this architecture design. Details about the logical design for Horizon View blocks are in the next section. Each block is sized for 1,800 virtual machines with N+1 for host capacity. Every host is estimated to carry the same amount of virtual machines in the same configuration as outlined in this document. T E C H N I C A L W H I T E PA P E R / 2 4 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider ~1,800 Users ~1,800 Users ~1,800 Users ~1,800 Users View Block View Block View Block View Block vSphere Cluster vSphere Cluster vSphere Cluster vSphere Cluster View Desktop Pools View Desktop Pools View Desktop Pools View Desktop Pools ESXi Hosts ESXi Hosts ESXi Hosts ESXi Hosts Shared Storage Shared Storage Shared Storage Shared Storage Switched Ethernet Network vCenter-Block 1 vCenter-Block 2 vCenter-Block 3 vCenter-Block 4 Composer Block 1 Composer Block 1 Composer Block 1 Composer Block 1 SSO vSphere Web Client SSO vSphere Web Client View Connection Server View Connection Server View Connection Server View Connection Server View Connection Server View Security Server View Security Server View Connection Server AD/DNS/DHCP MSSQL (Mirrored) Imprivata Appliance (Mirrored) Dell Management Server Workload vSphere Cluster Server Workload ESX Hosts Server Storage (Dedicated Arrays) VMware View Management Block View Pod Figure 10: Horizon View Pod Logical Design Details T E C H N I C A L W H I T E PA P E R / 2 5 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Horizon View Blocks The Horizon View architecture design has eight Horizon View blocks, 1–8. Block 1 is shown in Figure 11. Eight blocks is the total for both sites, with four blocks per site. The naming standard describes where each block is physically placed. Each block corresponds to one vSphere cluster containing eight hosts. Seven hosts were chosen for each cluster to accommodate the underlying storage system. The storage system is sized for approximately 600 users per array, where each Horizon View block has access to three of those arrays—hence 1,800 users in a block. vCenter Horizon View Block 1 Cluster 1 ESX Cluster Server VM User Profile Server Windows 2008 R2 – CIFS PFR Floating Pool 600 Horizon View Desktops Floating Floating Pool 600 Horizon View Desktops Floating Floating Pool 600 Horizon View Desktops Floating 8 ESXi Hosts 1.86Ghz x 32 Logical Cores 256GB RAM 1 x 250GB LUN (User Profiles) VMDK VMFS – not RDM Server VM ThinApp Repository Server Windows 2008 R2 – CIFS TAP 1 x 250GB LUN (ThinApp Packages) VMDK VMFS – not RDM 20 x 225GB LUNs (Linked Clones) 4x 85GB LUNs (Replicas) Figure 11: View Block Logical Infrastructure Design T E C H N I C A L W H I T E PA P E R / 2 6 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Horizon View Block 1 Horizon View Block 1 consists of one cluster as described in Table 2. The View Management block design outlined in Figure 11 defines the design for the rest of the Horizon View blocks in Region Hovedstaden’s design. Containers and names follow Region H’s naming standard. O BJ E CT CO NTAI NER ATTR IB U TES Cluster 1 ESXi hosts TBC LUNs (8) 1.86Ghz, 32 logical cores 256GB RAM 20 x 225GB LUNs (linked clones) 4 x 85GB LUNs (contains replica) Pool(s) Clinicians 1 600 desktops Floating pool 8 virtual machines per core 100 virtual machines per LUN Pool(s) Clinicians 2 600 desktops Floating pool 8 virtual machines per core 100 virtual machines per LUN Pool(s) Clinicians 3 600 desktops Floating pool 8 virtual machines per core 100 virtual machines per LUN Table 2: Horizon View Block 1 T E C H N I C A L W H I T E PA P E R / 2 7 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Horizon View Management Block The Horizon View Management block design is illustrated in Figure 12. vCenter Horizon View Infrastructure Cluster ESX Cluster 8 ESXi Installable Host (4.1u1) 16 Logical Cores, 64GB RAM – Dell M610 Server Virtual Machines 6 Connection Servers Server Virtual Machine 4 vCenter Servers (w/Composer) 1 vCenter Server (for Management Block) Server Virtual Machines 2 Security Servers 4 iSCSI 500GB LUNs + 1 iSCSI 100GB LUN (SQL Log) Server Virtual Machine 2 SSO Appliances (Imprivata) Server Virtual Machine 2 Dell Management Appliances Server Virtual Machine 2 AD/DNS/DHCP VC Database 2 SQL Server with DB Mirroring (18 Databases) Figure 12: Horizon View Management Block T E C H N I C A L W H I T E PA P E R / 2 8 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Logical Storage Design Figure 13 shows the logical storage design on a per-block level. Note that the management VDI cluster and VDI cluster hardware (blades) are placed in the same physical enclosures. VDI Cluster AP P OS Management VDI Cluster VM VM AP P OS wa re E AP P OS SX i Dell PowerEdge M910 (Enclosed in M1000e) iSCSI Switch (10Gbe) VM VM VM wa re ES Xi Dell PowerEdge M610 (Enclosed in M1000e) iSCSI Switch (10Gbe) EqualLogic PS6010 16 x 100GB SSD 5 Arrays per Block 20 x 225GB Linked Clones EqualLogic PS6010XV 16 x 450GB 15K SAS MAN/SQL 2 x 2TB Management 2 x 1.4TB SQL 4 x 85GB Replica 2 x 250GB PFR/TAP Figure 13: Logical Storage Design Storage Design Overview Storage is utilized conservatively to optimize the end-user experience. Desktops, images, persistent disks, and templates are stored separately to allow tiering. The system follows Dell EqualLogic, which recommends CHAP as the security protocol for iSCSI so users can segment LUNs and present them to the correct hosts. T E C H N I C A L W H I T E PA P E R / 2 9 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Logical Network Design This section provides details on networking and network security configurations. Typically a vSphere implementation uses three different types of network connections: virtual machine, management network, and VMkernel. Each type connects to a virtual switch that has one or more physical adapters (two is regarded as the minimum required for resilience) to provide connectivity to existing physical networks. The Horizon View environment has a standard vSwitch for iSCSI traffic. It also has a distributed switch, which is used for vMotion and virtual machine data access managed through VMware vCenter. A separate vSwitch bound to a 1Gbit management network is used for ESXi management. Standard vSwitch Infrastructure Table 3 defines the vSwitches configured for iSCSI traffic for hosts within the Horizon View management cluster and Horizon View desktop cluster. VI RTUAL SWI TCH FUNC TION N U MB ER OF PORTS N U MB ER OF N ETWOR K A DA PT ERS vSwitchiSCSI iSCSI 16 2 x 10Gbe vSwitch0 ESXi management 16 2 x 1Gbit Table 3: Standard vSwitch Configuration Figure 14 and Figure 15 illustrate the vSwitch configuration for the Horizon View management and Horizon View desktop cluster hosts. ESXi Physical Switch Layer vSwitchiSCSI iSCSI01 (vmk) 10Gb Switch 10Gbe iSCSIHeartbeat (vmk) 10Gbe iSCSI02 (vmk) 10Gb Switch Figure 14: Standard vSwitch Configuration – vSwitch iSCSI Note: Names are fictional. T E C H N I C A L W H I T E PA P E R / 3 0 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider ESXi Physical Switch Layer vSwitch0 1Gbit Switch 1Gbit ESXi Management (vmk0) 1Gbit 1Gbit Switch Figure 15: Standard vSwitch Configuration – vSwitch0 Table 4 details the settings used for vSwitch iSCSI. P RO P E RTI E S DEFAU LT SETTIN G R EV ISED SET T IN G Security: promiscuous mode Reject - Security: MAC address changes Accept Reject Security: forged transmits Accept Reject Traffic Shaping: status Disabled - NIC Teaming: load balancing Route based on the originating virtual port ID - NIC Teaming: failover detection Caution Link status only - NIC Teaming: notify switches Yes - NIC Teaming: failback Yes No NIC Teaming: failover order All Active - MTU Size (Jumbo Frames) 1500 9000 Table 4: Standard vSwitch properties – vSwitch iSCSI The design uses the software iSCSI solution provided by VMware. All configuration of VMkernel interfaces for use with the Dell EqualLogic arrays are configured with the EqualLogic-supplied Multipathing Extension Module (MEM). Refer to the following Dell white paper in regard to installation and configuration of the MEM module: https://c368768.ssl.cf1.rackcdn.com/product_files/4795/original/Dell_EqualLogic_SAN_VMware_View_ Performance_Sizing_and_BestPractices4f9c44ac421789b301acec760f65b626.pdf T E C H N I C A L W H I T E PA P E R / 3 1 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider The storage policies shown in Table 5 are used based on the above configuration document. PATH P O LI CY STOR AGE AR R AY TYPE DELL_PSP_EQL_ROUTED VMW_SATP_EQL Table 5: Storage Policies The standard vSwitchiSCSI is only used for iSCSI traffic, and therefore carries only VMkernel port groups. The two VMkernel interfaces are attached to the ESXi iSCSI software initiator. VI RTUAL SWI TC H P O RT GRO U P NAM E V LAN ID V LAN DESCR IPTION ACTIV E N IC STAN DBY N IC vSwitchiSCSI iSCSI01 (vmk1) iSCSI Traffic vmnic4 - vSwitchiSCSI iSCSI02 (vmk2) iSCSI Traffic vmnic5 - vSwitchiSCSI iSCSIHeartbeat iSCSI Traffic vmnic4, vmnic5 - Table 6: Port Group Settings – vSwitch iSCSI Table 7 details the settings used for vSwitch0 for ESXi management. P RO P E RTI E S DEFAU LT SETTIN G R EV ISED SET T IN G Security: promiscuous mode Reject - Security: MAC address changes Accept Reject Security: forged transmits Accept Reject Traffic Shaping: status Disabled - NIC Teaming: load balancing Route based on the originating virtual port ID - NIC Teaming: failover detection Link status only - NIC Teaming: notify switches Yes - NIC Teaming: failback Yes No NIC Teaming: failover order All Active - MTU Size (Jumbo Frames) 1500 - Table 7: Standard vSwitch properties – vSwitch0 T E C H N I C A L W H I T E PA P E R / 3 2 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider As shown in Table 8, the standard vSwitch, vSwitch0, is used only for ESXi management traffic. VI RTUAL SWI TC H P O RT GRO U P NAM E vSwitch0 ESXi Management V LAN ID V LAN DESCR IPTION ESXi Management ACTIV E N IC STAN DBY N IC vmnic0 - vmnic1 - (vmk0) Table 8: Port Group Settings – vSwitch0 Distributed Virtual Switch Infrastructure A vNetwork distributed switch (dvSwitch) acts as a single vSwitch across all associated hosts on a datacenter. This allows virtual machines to maintain a consistent network configuration as they migrate across multiple hosts. The dvSwitch offers features that can benefit virtual machines, including the ability to preserve port state when a virtual machine is migrated to another ESXi server host. This facilitates the use of intrusion detection and prevention systems. Furthermore, the system supports PVLANs. For these reasons all virtual machine network and ESXi management connections (vMotion included) use a dvSwitch. Table 9, Figure 16, and Table 10 define the standard dvSwitch that is created and configured. VI RTUAL SWI TC H FU N CTION dvSwitch0 N U MB ER OF N ETWOR K ADAPTER S PER HOST All virtual machines 2 x 10GbE vMotion Table 9: dvSwitch Configuration ESXi Physical Switch Layer dvSwitch0 vMotion vian 110 vian 120 vian 130 10Gb Switch 10Gbe 10Gbe 10Gb Switch Figure 16: Distributed Switch Network Diagram per VMware vCenter Server (dvSwitch) Note: VLAN IDs are fictional. T E C H N I C A L W H I T E PA P E R / 3 3 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider P RO P E RTI E S DEFAU LT SETTIN G R EV ISED SETTING Security: promiscuous mode Reject - Security: MAC address changes Accept Reject Security: forged transmits Accept Reject Ingress Traffic Shaping: status Disabled Egress Traffic Shaping: status Disabled VLAN VLAN trunking Teaming and Failover: load balancing Route based on originating virtual port ID Teaming and Failover: failover detection Link status only Teaming and Failover: notify switches Yes Teaming and Failover: failback Yes Teaming and Failover: failover order All Active Route based on physical NIC load (LBT) Table 10: Distributed Switch Port Group Properties Table 11 specifies resource allocations for network resources in the dvSwitch described in the section above. NETWO RK RE S O URC E POOL H OST LIMIT (MB IT/S) PN IC SHAR ES SHAR ES FT Traffic Unlimited Normal 50 iSCSI Unlimited Normal 50 vMotion 8000Mbit/s Low 25 Management Unlimited Normal 50 NFS Unlimited Normal 50 Virtual machines Unlimited High 100 Table 11: Resource Allocations for Network Resources in the dvSwitch Similar to the configuration of a dvSwitch, a number of additional properties regarding security, traffic shaping, and NIC teaming can be defined on a port group. By default, a distributed virtual port group (distributed port group) will inherit settings for these properties from its parent dvSwitch. However, it is possible to override and customize these settings per port group. Table 11 lists these properties, their inherited value, and any changes to these values associated with this design. T E C H N I C A L W H I T E PA P E R / 3 4 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Network Physical Design Specifications This section expands on the Logical Network Design in the previous section by providing details on the physical NIC layout and physical network attributes. The VMNICs are all connected to Region Hovedstaden’s Cisco backbone infrastructure, using 10GbE connectivity. Region Hovedstaden must ensure a resilient solution. The network adapters assigned to the virtual switches must be connected to a minimum of two physical switches. For example, a vSwitch iSCSI in this case has two network adapters for connectivity to the physical network, and should be connected to different switches, so a single physical switch is not introduced as a single point of failure (SPOF). A total of 4 x 10GbE physical NICs are recommended for this host design. Network Optimization for PCoIP The IT organization recommends that the network equipment used for traffic from the virtual machine to the endpoint is configured to use RED/WRED, as opposed to Tail Drop. Tail Drop can have a negative impact on PCoIP. Refer to the network manufacturer’s guide on how to configure for RED/WRED, and to verify that Tail Drop is not currently being used. Table 12 contains a summary of PCoIP latency and bandwidth requirements. Note the above-average bandwidth and below-average latency numbers, attributable to Region H’s requirement to support dictaphone technology for doctors. V MWAR E V IEW 4. 6 Latency requirements Bandwidth requirements V MWAR E V IEW 5.1 Tolerate up to 50ms of latency before session degradation becomes noticeable. Tolerate up to 55ms of latency before session degradation becomes noticeable. Significant performance degradation for network conditions at 55ms. Significant performance degradation for network conditions at 60ms. Requires a minimum bandwidth of 220Kbps per desktop session. Requires a minimum bandwidth of 210Kbps per desktop session. Table 12: Latency and Bandwidth Requirements T E C H N I C A L W H I T E PA P E R / 3 5 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Load Balancing Architecture Figure 17 shows the load balancing architecture for the Region Hovedstaden Horizon View environment. Note that access to the View Security Servers is handled at the datacenter level, and is not part of the logical design. Local Users (H/W or S/W) Client Sites (Hospitals) Local Users (H/W or S/W) Local Users (H/W or S/W) Client Sites (Hospitals) Client Sites (Hospitals) Site 1 Site 2 Load Balancer Load Balancer vCenter Servers vCenter Servers LAN LAN Virtual Desktops VM VM VM ESXi Hosts Horizon View Pod Virtual Desktops VM VM VM ESXi Hosts Horizon View Pod Figure 17: Load Balancing Architecture Load balancing is an important component of Horizon View architecture. Its primary purpose is to optimize performance by evenly distributing desktop session load across all available View Manager servers. If one of the platforms fails, the replicated instances can continue to facilitate connections. VMware recommends that the customer engage Cisco for best-practice advice on configuring Cisco ACE for VMware View 5.x usage. Additionally, load-balancing technologies can maximize the scalability of a solution by automatically rebalancing connections when additional resources are added to the Horizon View environment. T E C H N I C A L W H I T E PA P E R / 3 6 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Support for a redundancy and failover mechanism at the network level prevents the load balancer from becoming a single point of failure. Region Hovedstaden’s current Cisco ACE technology adds redundancy and failover at the load-balancer level. If the main load balancer fails, another load balancer in the group automatically starts handling connections. To provide a degree of fault tolerance, a load-balancing solution must be able to remove failed Horizon View server nodes from the load-balanced group. In tunnelled mode, if a View Manager server fails or becomes unresponsive during an active session, users do not lose data and desktop states are preserved in the virtual desktop. However, the user is disconnected from their session. When users reconnect to a different View Manager server in the group, their desktop sessions continue exactly where they were when the failure occurred. In direct connect mode, failure of a View Manager server does not impact a user’s session. In order to provide load balancing to Horizon View, the ESA project uses Cisco ACE technology. The loadbalancing solution should support the requirements shown in Table 13. ATTRI BUTE Support virtual IP/DNS for Horizon View SPECIFICATION All View Manager servers VIP1: TBC Support session affinity Yes Session affinity method Cookie: JESSIONID or source IP (only if client IPs are not NAT type) Load balancing based on Least connections Ports to be monitored 80 (HTTP), 443 (HTTPS) Keepalive method HTTP: send string “GET /favicon.ico HTTP/1.0” HTTP: response string “^HTTP/1.[01] (200)” Timeout 30-second intervals, 91-second timeout Windows service to be monitored View Connection Server service Table 13: VMware View Load Balancing Requirements Business Continuity and Disaster Recovery This section outlines the disaster recovery components of the implementation. Disaster Recovery (DR) The DR solution for the Region Hovedstaden virtual desktop infrastructure project provides virtual desktops for 100 percent concurrency of production. In the event of a datacenter outage, the load balancers must redirect requests from the endpoints. Note: The DR pools must also be entitled in order for users to be able to access the virtual desktop. In the event of a site outage, this design depends on a manual process to switch over from the production environment to the DR one by the load balance appliances. The DR virtual desktop pools in the datacenter hosting them will have to be entitled for affected users. T E C H N I C A L W H I T E PA P E R / 3 7 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider View Connection Server Architecture Redundancy In each of the sites, a number of View Connection Servers are installed to provide scalability and availability. In the event of a datacenter outage, the View Connection Servers are capable of taking on extra loads. The DR solution in this design is active-active, where all datacenter sites are used concurrently to provide virtual desktops. Potential failure points and measures for redundancy are shown in Table 14. FAI LURE P O I NT R EDU N DAN CY VMware View Manager Connection Server At least two VMware View Manager Connection Servers are required for redundancy. These are load balanced using Cisco ACE. In the event of a failed Connection Server, users will not be disconnected from their session. Horizon View desktop If a desktop fails then the user must report the fault to Support. A new desktop can be provisioned if the current desktop cannot be fixed. Users might lose work in this scenario. VMware vCenter Server (vCenter Server) If vCenter Server fails, Horizon View will not be affected. Virtual desktops can still be connected; however, new desktops cannot be provisioned. Workloads will not be balanced across clustered hosts. Desktops cannot be powered on or off. IT recommends that VMware vCenter Server Heartbeat™ is used for making vCenter server roles redundant. VMware ESXi host If a virtual desktop host fails, then a user will lose connection to their desktop. The virtual desktop will be automatically migrated to another host in the cluster and started. Users will be able to connect to their desktop within minutes. Users might lose work in this scenario. In this case, the virtual desktops will be powered off and deltas will be lost. If a View Manager Server host fails, then the user’s session will be disconnected. A user can log back in and no work will be lost on their virtual desktop. IT recommends that all View Manager Servers in the same instance are not placed on a single host. Anti-affinity rules for two View Connection Servers are recommended. VMware management cluster failure If all hosts (hosting the VMware View Manager Servers) in a VMware cluster lose connectivity or fail, then availability will be lost. Users that are currently connected will not be disconnected; however, users trying to authenticate to the View Servers at time of failure will not succeed. Horizon View desktop cluster failure If all hosts in a Horizon View desktop cluster lose connectivity or fail, then users assigned to the desktop pools hosted on the affected cluster will be unable to access a virtual desktop until the cluster is restored. Table 14: Potential Failure Points and Redundancy Measures Note: View Manager servers do not automatically fail over in the event of a server failure. T E C H N I C A L W H I T E PA P E R / 3 8 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Datacenter Outage of LOCATION1 In the event of a datacenter outage at LOCATION1, and assuming that the load-balancing appliance is redirecting View Client traffic to LOCATION2, this design will have all DR virtual desktops pre-provisioned as per required specifications and powered-on on demand when required. Floating Desktops LOCATION1 has 1,800 concurrent users with floating desktops provisioned by View Composer linked clones. The DR desktop pools for LOCATION1 in LOCATION2 will be configured to have all DR virtual desktops for LOCATION1 pre-provisioned and powered off, with the exception of the first 10 percent powered on. The pool configuration will power on these virtual desktops on demand. Refer to Region Hovedstaden’s load-balancing design for DR and site failover. Datacenter Outage of LOCATION2 In the event of a datacenter outage at LOCATION2 and assuming that the load balancing appliance is redirecting View Client traffic to LOCATION1, this design will have all DR virtual desktops pre-provisioned as per required specification and powered-on when required. Floating Desktops LOCATION2 has 1,800 concurrent users with floating desktops provisioned by View Composer linked clones. The DR desktop pools for LOCATION2 in LOCATION1 will be configured to have all DR virtual desktops for LOCATION2 pre-provisioned and powered off, with the exception of the first 10 percent of virtual machines powered on. The pool configuration instructs Horizon View to power on these virtual desktops on demand, and also power off when not in use. Refer to Region Hovedstaden’s load-balancing design for DR and site failover. Recovery of a Datacenter When a datacenter is recovered from failure, the design requires action to resume normal operations of the virtual desktop environment. To minimize the impact on users, IT management recommends that this action is taken outside working hours. Prior to powering on the View Connection Servers, ensure that the following infrastructure components are confirmed ready to use in the production environment again: • Database servers for vSphere and Horizon View • vSphere servers • Active Directory and related components such as DHCP, DNS, etc. • vSphere storage • User storage • Print servers and printers • Application infrastructure (client and server based) • Network connectivity IT recommends that the failback process, to configure GTM (or Cisco ACE) to direct traffic back to the production environment that failed, is initiated manually only after the above infrastructure components are recovered. Floating Desktops When the GSS appliance directs a Horizon View client request back to the normal designated datacenter, users with existing connections to their DR datacenter will not be affected. However, users should be informed to save their work and log out. When they log back in, they will connect to their designated datacenter via the GSS. T E C H N I C A L W H I T E PA P E R / 3 9 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Appendix B (Technical Design Specifications) The technical design specifications are described in a different order than the logical design. The order of this section is: • Horizon View management block • Horizon View pod • Horizon View blocks This section follows the natural order of construction of the overall design. Horizon View Management Block This section describes the components of the management block. View Connection Server Specifications View Connection Servers run Windows 2008 R2 64-bit Server Standard Edition, provide user authentication, and redirect incoming remote desktop requests to the appropriate Horizon View desktop. View Connection Servers within the same pod are replicas of each other, and can be used for scaling and load-balancing purposes. View Connection Servers in the same pod share a single ADAM (Active Directory for Application Mode) database. In addition, each View Connection Server system runs the View Administrator that is the primary mechanism for Horizon View configuration and administration. The View Connection Servers must be part of the Active Directory forest. These systems are located behind the internal load-balancing solution. Users that access their virtual desktops from secure locations do not utilize the tunneling services provided by the View Connection Servers. These users are directly connected to their desktops after successful authentication by the View Connection Servers. The View Connection Server is a VMware virtual machine with four vCPUs, 10GB RAM, and a 40GB disk running Windows 2008 Server R2 64-bit Standard Edition. The full specification is given in Table 15. ATTRI BUTE SPECIFICATION Number of View Connection Servers 8 (4 per site) Number of View Connection Servers in Failover 4 (2 per site) View Connection Server hostnames TBC Physical or virtual machine Virtual machine: VMware Virtual Hardware 7 Number of processors 4 Processor type vCPU Memory 10GB Important: Memory must be configured before OS and application installation. Number of NICs/speed 1 x Gigabit Network(s) VLAN # T E C H N I C A L W H I T E PA P E R / 4 0 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider ATTRI BUTE SPECIFICATION Total storage 40GB Operating system Windows 2008 Server R2 64-bit Standard Edition Cluster TBC Datastore TBC View Connection Server View Connection Server 5.1 Other customizations (See Horizon View Desktop OS Optimizations.) Verify that Horizon View logs are excluded from antivirus scans. SSL certificate Each View Connection Server will require an SSL certificate for client devices to connect via SSL. Please refer to the View Manager Administration Guide for further information on creating and importing SSL certificates with Horizon View. Table 15: View Manager Server Specifications View Connection Server Availability If a View Connection Server fails or becomes non-responsive, while an active, established, and tunneled session exists, the desktop state is preserved in the virtual desktop instance. When the user reconnects to a different View Connection Server in the group, the desktop session continues where it left off when the failure occurred. In the case of direct connections, users are unaffected by any View Connection Server disruption, because their session is established directly with the Horizon View desktop. If the connection between the client device and the Horizon View desktop is broken, the desktop state is also preserved and the session continues when the client reconnects. Horizon View Desktop Pool Specifications Region H has a goal to use only one parent desktop (golden image), with the following specifications at the virtual hardware level and at the OS level, as a combination of settings in the parent desktop and GPOs. Region H deploys business applications as VMware ThinApp packages, but is aware that it can be necessary to install a few applications or part of the applications in the parent desktop, or in templates cloned from a golden image. T E C H N I C A L W H I T E PA P E R / 4 1 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Parent Desktop Virtual Machine Virtual Hardware Specifications The virtual hardware configuration of the parent desktop will vary based on the amount of computing resources required by the end user. Region H has a goal to use only one parent desktop, with the default specifications outlined in Table 16 at the virtual hardware level. ATTRI BUTE SPECIFICATION Hardware VMware virtual hardware version 7 vCPU 2 vMemory 2048MB vNICs (VMXNET 3) 1 Virtual Network Adapter 1 Template-designated VLAN Virtual SCSI Controller 0 LSI Logic Virtual Disk OS: VMDK 15GB Floppy, COM, and LPT Disabled in BIOS Virtual CD/DVD Drive 1 Removed View Agent VMware-viewagent-5.1.2-1040196 Logging Disabled Table 16: Parent Desktop Virtual Machine – Virtual Hardware Specifications The hardware specifications in Table 15 are the agreed-upon configuration for all parts of the Region Hovedstaden ESA design. Lacking sizing numbers to base the configurations on, IT management put a plan in place in the event the workload inside the virtual machine had an impact on the PCoIP or application performance. If performance was impacted, a second vCPU would be configured inside the virtual machine. This change would be made only if the original configuration was insufficient. Region H concluded that a two vCPU configuration per virtual machine gives the user a better experience and faster login times. Horizon View Desktop Operating System Specifications The operating system image deployed for the parent desktop is Microsoft Windows XP SP3 (fully patched). This image is considered the parent desktop, golden image, or master template. Region H uses a custom menu system where all applications are assigned to the user up front. Possible constraints applied by licensing are handled by the backend applications, or by using open-source programs. Therefore, Region H does not use the Horizon View capability of assigning applications to individual users or groups. To support the strategy of only one parent desktop, Region H uses—as far as possible—VMware ThinApp to deploy applications. ThinApp removes the requirement to install applications on the base image. Client Preferences is installed in Windows XP to support enhanced management in GPO of Computer and User settings. T E C H N I C A L W H I T E PA P E R / 4 2 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Horizon View Desktop OS Optimizations To achieve the best possible end-user experience, the Horizon View desktop OS is optimized for performance and streamlined to contain only those OS elements specifically required by Region H for business applications. Table 17 shows the critical modifications. C USTO M I ZATI O N STE P R EMAR KS Install latest service pack Service Pack 3 and security patches are applied. Install VMware Tools Provides performance enhancements through optimized drivers (including memory ballooning, etc.). Page file Set to a fixed size of 512MB. Install required applications (including antivirus) Golden image applications, Microsoft .Net Framework are installed after the View Agent. Install View Agent View 5.1 or above Agent installed. Set Windows screen saver to blank Imprivata Single Sign-On handles screen saver settings. Enable 16-bit color Windows XP selects between 16- and 32-bit color depth. 16-bit will be selected to start. Disable unused hardware Disable COM1, COM2, and LPT in BIOS. Turn off theme enhancements All theme enhancements are removed. Performance settings Visual Settings is set to Best Performance. Hardware acceleration enabled For best performance, hardware acceleration is turned on. Delete hidden uninstall folders Any hidden update uninstall folders are deleted (e.g., C:\WINDOWS\$NtUninstallKB893756$). Disable indexing services Reduces workload on the desktop. Disable indexing of C: drive Reduces workload on the desktop. Remove System Restore points Region H would like to remove System Restore points, but this is unsupported by an uninstallation of the View Agent. At present, Restore points are preserved. Power setting For high performance, the power scheme is set to Always on for all devices. Unwanted services are disabled All unwanted (unnecessary) services are disabled. T E C H N I C A L W H I T E PA P E R / 4 3 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider C USTO M I ZATI O N STE P R EMAR KS GPO will handle default user settings and not the default user profile GPOs with Client Preferences will handle all user settings. This solution is dynamic and supports the goal of only one parent desktop. Run Disk Cleanup Removes temporary and unnecessary files from the image. Run Disk Defrag Reduces fragmentation of the filesystem. Release IP address Run ipconfig /release to ensure there is no IP address allocated to the virtual machine. Flush DNS Run ipconfig /flushdns. Disable NetBIOS over TCP/IP For best performance and reduced load on computer resources, NetBIOS over TCP/IP, file and printer services, and QoS are removed. Automatic computer maintenance turned off Administrators using the View Composer recompose feature will manage updates to virtual desktops. Internet Explorer For the sake of backward compatibility, IE7 is installed in the golden image. As necessary, ThinApp editions of IE6 and IE8 are deployed. Disable indexing Reduces CPU and memory footprint on the desktop. Table 17: Critical Optimizations for Windows XP Operating System Deployment Methodology View Composer automatically creates Horizon View desktops, based on desktop pool parameters, from a snapshot of a parent virtual machine. As such, Horizon View desktops are not directly linked to the parent virtual machine; but a copy (replica) of the snapshot is deployed to each datastore. View Composer desktops with user data and ThinApp applications on network shares are referred to as stateless desktops, because such desktops are not impacted by user-specific actions. A View Composer parent virtual machine OS disk replica is referenced by many virtual machines, and therefore all desktop changes are written to the individual View Composer delta disk of each virtual machine. Operating system patches or updates can be propagated to View Composer desktops in two ways: 1. Manually recompose the Horizon View desktops when a patch or update must be applied. This is achieved by first modifying the parent virtual machine, creating a new snapshot of the parent virtual machine, and re-linking the desktop to this snapshot. Then users must recompose desktops using View Administrator for changes to come into effect. The recompose function deletes and recreates a new Active Directory computer account for each virtual machine being recomposed. 2. Alternatively, desktops can be recomposed each time a user logs out of a desktop (delete after first use). The benefit of this is that it reduces the growth of the View Composer delta disks. This is achieved by removing floating desktops when a user logs out, and recreating a new desktop for the pool. The new desktop is created from the newly updated parent virtual machine. This approach also deletes and recreates the Active Directory computer account. In this design each VLAN has a DHCP scope of 2,000 IP addresses. For each VLAN that a desktop pool is required to use, a View Composer parent virtual machine has to be created from the golden image using the relevant network connection. T E C H N I C A L W H I T E PA P E R / 4 4 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Horizon View Policies All pools are governed by a global policy, outlined in Table 18. This global policy is used to deny or allow access to certain features within View Manager. The features include USB device redirection, Multimedia Redirection (MMR), and remote mode. USB devices are allowed to connect to virtual desktop sessions. multimedia redirection is allowed to enhance video and audio playback in user sessions where possible. P O LI CY SETTIN G USB access Allow Multimedia redirection (MMR) Allow Remote mode Allow PCoIP hardware acceleration Allow at Medium priority Table 18: Pool Global Policy Settings By default, Horizon View allows all desktops to be used in local mode. However, in order for a user to check out their desktop, it must be published. The global policy can be overridden by a pool policy set at a pool level. Alternatively, it can be set at a user level. Active Directory Integration The design employs an organizational unit (OU) created specifically for Horizon View desktops. An OU is a subdivision in Active Directory that contains users, groups, computers, or other OUs. Dedicated OU for Horizon View Desktop, Server, and User Accounts The design enables Microsoft and Horizon View–specific policies to be applied via GPO to all machines created dynamically by View Manager during operation, without knowing the actual workstation account name. View Manager includes administrative templates for managing Horizon View virtual machines. Administrators can import these templates and apply them via a GPO to the respective OUs. This provides a straightforward and consistent way to manage policies specific to Horizon View virtual machines and users. T E C H N I C A L W H I T E PA P E R / 4 5 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Group Policy Objects GPOs can be applied to Horizon View components at a domain-wide level to provide granular control over the environment. In the case of the Region H infrastructure, the use of GPOs are categorized as one of two types: 1. The previously discussed, OUs were created with the specific intent of managing individual components of the overall Horizon View infrastructure using the common Microsoft and View Manager GPOs. 2. Table 19 identifies the GPO properties available with the use of the View Client GPO template (vdm_client.adm), the properties to use, and the values to apply. P RO P ERTY Scripting Definitions U PDATED R EMAR KS No Server URL Default value of the Log In as Current User checkbox Yes Disabled This setting does not allow current user credentials for authentication to Horizon View. You can override this setting at the command-line using the switch: –LogInAsCurrentUser false | true Alternatively, a registry entry (REG_DWORD) can be set: Key = \Software\Policies\VMware, Inc.\VMware VDM\Client\Security\ Name = LogInAsCurrentUser Value = 0 | 1 The entry can be set at the HKLM or HKCU registry level. RDP Settings (optional) Yes Desktop Background Disabled Enable Persistent Bitmap Caching Enabled Redirect Drives Disabled Redirect Printers Disabled Table 19: View Manager User Configuration GPO for View Client Table 20, Table 21, and Table 22, identify the GPO properties available with the use of the View Server GPO template (vdm_server.adm and vdm_common.adm), which properties to use, and the values to apply. P RO P ERTY Recursive enumeration of trusted domains UPDATED Yes R EMAR KS Enabled Table 20: View Manager Computer Configuration GPO for View Server T E C H N I C A L W H I T E PA P E R / 4 6 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider P RO P ERTY Log Configuration UPDATED R EMAR KS Yes Days to keep 7 days Maximum number 10 logs Maximum size 100MB Table 21: View Manager GPO for Common Components (for View Servers) P RO P ERTY UPDATED R EMAR KS Enforce removal of Remote Desktop Wallpaper Yes Set to Enable Limit maximum color depth Yes Fixed to 16-bit Remote Windows Security Item from Start Menu Yes Set to Enable Remove Disconnect option from shut down dialog Yes Set to Enable Table 22: Recommended Terminal Services Common GPOs for Virtual Desktops Table 23 identifies the GPO properties available with the use of the View Agent GPO template (vdm_client. adm), which properties to use, and the value to apply. P RO P ERTY Always wait for network at computer startup UPDATED Yes R EMAR KS Enabled Avoids inaccessible user profile/data during the login process Table 23: View Manager Computer Configuration GPO for Horizon View Desktops Table 24 identifies the GPO properties available with the use of the View Agent GPO template (vdm_agent. adm), which properties to use, and the values to apply. P RO P ERTY Recursive enumeration of trusted domains UPDATED Yes R EMAR KS Disabled Only directly trusted domains are enumerated and connection to remote domain controllers does not take place. Only internal domain is allowed. AllowDirectRDP Yes Disabled Does not allow users to RDP to desktop outside of Horizon View control. Table 24: View Manager Computer Configuration GPO for View Agent T E C H N I C A L W H I T E PA P E R / 47 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Table 25 identifies the GPO properties available with the use of the PCoIP GPO template (pcoip.adm), which properties to use, and the values to apply. P RO P ERTY UPDATED R EMAR KS Minimum image quality No 50 (default) Maximum initial image quality Yes Set to 70. Default is 90. Frame rate limit Yes Set to 12. Default is 30 frames per second. MTU size Yes Set this equal to or less than the lowest MTU size of the endpoints. (Default is 1400.) Maximum link rate No Setting not currently updated. Region H application requirements make it likely that future adjustments will be necessary later to increase the maximum link rate to a higher Mbit level. Table 25: View Manager Computer Configuration GPO for WAN Users with PCoIP Antivirus Scanning and Updates A key challenge in virtual desktop infrastructure is the deployment of antivirus updates and scheduled scans. In a physical deployment, PCs do not share CPU and disk resources, and therefore can accommodate updates and scans at the same time. In a shared infrastructure such as VDI, desktops share a common set of CPUs, NICs and HBAs. If an antivirus update or scan is initiated across all virtual desktops on a single ESXi host, the resources will be flooded with I/O requests. This event has the potential to bring the VDI environment to a standstill. The Region H ESA uses Trend Micro OfficeScan 10.5 with VDI extension and TCacheGen. The TCachegen. exe file creates a binary image—a stamp of the parent desktop—and therefore excludes the parent desktop from further scanning. While security updates in the Region H system are inevitable, the current plans for the security design are: • Follow recommendations for exclusions of files and folders as stated in white papers from VMware and Microsoft. • Avoid scheduled scans of desktops from floating desktop pools. • Deploy updates to OfficeScan and large antivirus updates in the parent desktop. • Avoid scans of ThinApp applications. • Avoid scans of read operations. • Avoid scans of text-based files as log files or other files, which are known to be harmless. To avoid a resource storm, VMware recommends scheduling antivirus updates in a staggered manner to make sure that no single ESXi host is overwhelmed. Similarly, scheduled antivirus scans are staggered by OfficeScan to avoid resource contention across the ESXi cluster. VMware recommends applying large antivirus updates (engine updates) to the parent virtual machine only. Signature updates can be applied to virtual desktops, but should be staggered in their schedule. Finally, Horizon View components actively log to the corresponding operating system. VMware recommends that antivirus software is configured to not scan Horizon View logs. VMware ThinApp Application To support the strategy of only one parent desktop, Region H uses—as far as possible—VMware ThinApp to deploy applications. ThinApp removes the requirement to install applications on the base image. T E C H N I C A L W H I T E PA P E R / 4 8 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Region H is aware that it can be necessary to install a few applications or part of the applications in the parent desktop or in templates cloned from the golden image. The applications are organized into two groups: one group where users must have the ability to save settings from session to session, and another group where IT management can discard the settings after each session. When the user must have the ability to save settings, the sandbox is saved at the default location %appdata% and Virtual Profiles handle the sandbox. When it is not necessary to save the settings in the application, the sandbox is saved at %usertemp% and discarded when the user leaves the session. Temporary files in %usertemp% in Horizon View are considered non-disposable files, which can be placed on a separate disk for performance and cost optimization. VMware vSphere Clusters Within a Region Hovedstaden datacenter, ESXi server hosts are typically grouped in clusters, to provide a platform for different groups of virtual machines requiring different network and storage requirements. Furthermore, grouping ESXi server hosts in clusters facilitates the use of such technologies as vMotion, vSphere HA, and VMware vSphere Distributed Resources Scheduler™ (DRS). Table 26 summarizes the management cluster(s) created for this design, and their purpose. C LUSTE R NAM E NUM B ER OF HOSTS HOST TYPE DESCR IPTION 8 Dell PowerEdge M610 Management Servers 8 Dell PowerEdge M610 Management Servers Table 26: Management Cluster Table 27 summarizes the Horizon View cluster(s) created for this design and their purpose. C LUSTE R NAM E Cluster #1-4 NUM B ER OF HOSTS 8 (per cluster) HOST TYPE Dell PowerEdge M910 Production cluster in the datacenter Dell PowerEdge M910 Production cluster in the datacenter 7+1 configuration Cluster #5-8 8 (per cluster) 7+1 configuration DESCR IPTION Table 27: Horizon View Desktop Cluster T E C H N I C A L W H I T E PA P E R / 4 9 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider VMware vSphere High Availability Region Hovedstaden configured vSphere HA on management server clusters and Horizon View desktop clusters, to provide recovery of virtual machines in the event of an ESXi server host failure. If an ESXi server host fails for any reason, the virtual machines running on that server will go down, but will be restarted on another host within a few minutes. While the service interruption is perceptible to users, the impact is minimized by the automatic restarting of these virtual machines on other ESXi server hosts. When configuring a cluster for vSphere HA, a number of additional properties must be defined. Table 28 shows the Region Hovedstaden configuration for HA. H A CLUSTE R S E TTI NG CON FIGU R ATION VALU E Host Monitoring Enabled Admission Control Prevent virtual machines from being powered on if they violate availability Admission Control Policy Host failures cluster tolerates: 1 Default Virtual Machine Restart Priority Medium Note: VMware vCenter virtual machines and management role virtual machines should be on high restart priority. Host Isolation Response Leave Powered On Virtual Machine Monitoring Enabled Virtual Machine Monitoring Sensitivity Default Table 28: HA Cluster Configuration Summary VMware vSphere Distributed Resources Scheduler (DRS) Region Hovedstaden configured DRS to help improve resource allocation and power consumption across all hosts and resource pools. DRS collects resource usage information for all hosts and virtual machines in the cluster, and gives recommendations (or migrates virtual machines) in one of two situations: 1. Initial placement – When the user first powers on a virtual machine in the cluster, DRS either places the virtual machine or makes a recommendation. 2. Load balancing – DRS tries to improve resource utilization across the cluster by performing automatic migrations of virtual machines (vMotion), or by providing a recommendation for virtual machine migrations. DRS is configured on all clusters to provide load balancing of virtual machine workloads across hosts in the cluster, as illustrated in Table 29. D RS C LUSTE R S E TTI NG CON FIGU R ATION VALU E Automation Level Fully Automated Migration Threshold Apply level 3 recommendations Virtual Machine Options Power Management Off Table 29: DRS Cluster Configuration Summary T E C H N I C A L W H I T E PA P E R / 5 0 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider VMware recommended that Region Hovedstaden use DRS to specify anti-affinity rules on management server virtual machines. The rules should be used to specify the relationship between groups of virtual machines, so they remain separated from each other. VMware recommends splitting View Connection Servers and other critical roles that hold redundancy at the application layers. This is to avoid service downtime should one vSphere host fail. Resource Pools Resource pools are configured for the management roles, such as vCenter, SQL, and management appliances, to guarantee the minimum memory and CPU availability for these critical roles. Due to issues that Region Hovedstaden experienced with locating the relationship between linked clones and the corresponding master image, IT created a resource pool for each desktop pool. These resource pools are also used as containers, when creating or running scripts that must be executed based on data in ADAM and the virtual machines in a given desktop pool. Region H has been advised that this solution can potentially introduce performance issues, as it is vulnerable to human error. If a limit is set on any of these pools, it will impact performance. Horizon View Pod View Manager is configured through the use of the Web-based View Administrator console. The console allows for configuration of each View Manager Server, including the connection mode (direct or tunneled), tags (for specifying pool types to be accessed), authentication methods, and View Manager database backup (ADAM backup, not SQL Server). These configuration details are provided in Table 30, and should be applied to each View Manager Server. ATTRI BUTE SPECIFICATION Web Administrator Console TBC External URL TBC Tags Blank Direct Connect Mode Unchecked Smartcard Authentication Unchecked RSA Authentication Unchecked View Manager Automatic Backup Backup frequency Every day Backup time 12 midnight Maximum number of backups 10 Folder Location C:\ProgramData\VMware\VDM\backups View Administrators AD Group for users with administrative rights to the View Administrator console. By default all local administrator users on the View Manager Server can log in to the View Administrator console. Table 30: View Manager Server Configuration T E C H N I C A L W H I T E PA P E R / 5 1 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider The Horizon View pod will host a single instance of View Manager, in that each View Manager server shares a common group configuration, also known as global settings. Global settings specifies connection, security, and local mode operation settings. Table 31 illustrates the global settings for this design. Local mode desktop was initially used as a proof of concept for 20 users. Session timeout specifies how long a user can remain connected to a desktop session. This provides security and session management if a user forgets to disconnect or log out of their session at the end of a work shift. SSL is used for client connections to provide secure authentication between the View Client and View Connection Server. Horizon View offers the ability to warn users if a forced logout is necessary. By setting this warning, administrators can ensure users are given enough time to log out of any current session. Message security mode can be set to provide additional security for the message bus system used between Horizon View components. This security provision was not deemed necessary in the Region H environment. ATTRI BUTE SPECIFICATION Session timeout 720 (12 hours) Require SSL for client connections and View Administrator No Reauthenticate secure VPN connections after network interruption No Message security mode Disabled Disable single sign-on for local mode operations No Auto Update Disabled Pre-login message No Display warning before forced logout Yes Table 31: View Manager Global Settings Configuration T E C H N I C A L W H I T E PA P E R / 5 2 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider View Connection Servers use the vCenter Server to provision and manage Horizon View desktops. Horizon View can use multiple vCenter servers to do this. Each vCenter server in the Horizon View pod should be configured in View Manager. Table 32 details the necessary configuration items. ATTRI BUTE SPECIFICATION Server address (FQDN) TBC Description N/A Connect using SSL Yes Port 443 Enable View Composer Yes Advanced Settings Maximum concurrent provisioning operations 32 Maximum concurrent power operations 32 Table 32: vCenter Server Configuration Horizon View Block The following section outlines the Horizon View Block design. View Composer Design Specifications The following design specifications were observed in designing the View Composer architecture: • Every Horizon View partition with View Composer desktops requires View Composer installed on that container’s vCenter Server system. • Maximum of eight ESXi hosts per View Composer cluster. • Maximum of 512 linked clones per parent virtual machine replica. This is a good practice for recompose and refresh operations. • Maximum of 128 linked clones per datastore. View Composer database required. View Composer must be installed on the same machine as the vCenter server. Additionally, View Composer requires a View Composer database, which must be created. T E C H N I C A L W H I T E PA P E R / 5 3 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Region H provided a managed database service on a Microsoft SQL Server 2008 platform. Table 33 summarizes the configuration requirements for the View Composer database. ATTRI BUTE SPECIFICATION Vendor and version Microsoft SQL Server 2008 Authentication method SQL Authentication Recovery method Full or Simple Database autogrowth Enabled in 1MB increments. Transaction log autogrowth In 10% increments. Restricted to 2GB maximum. Database size 5GB Table 33: View Composer Database Specifications for Microsoft SQL Server 2008 The SQL Server full recovery model uses database backups and transaction log backups to provide complete protection against failure. Along with the ability to restore a full or differential backup, users can recover the database to the point of failure or to a specific point in time. With this recovery model, it is important to recognize that the logs continue growing until the user performs a backup of the database and the transaction logs. If the user sets the recovery model to full, they must back up their database and transaction logs regularly, or the transaction logs continue to grow without limit. View Composer Database Connection Table 34 identifies the required databases, and provides details regarding the associated SQL and Active Directory accounts and database rights. DATABAS E NAM E ACCO UN T N AME DATA B ASE R I GHTS FU N CTI ON vCmpBlk1 Dbowner View Composer database View Block1 vCmpBlk2 Dbowner View Composer database View Block2 vCmpBlk3 Dbowner View Composer database View Block3 vCmpBlk4 Dbowner View Composer database View Block4 vCmpBlk5 Dbowner View Composer database View Block5 vCmpBlk6 Dbowner View Composer database View Block6 vCmpBlk7 Dbowner View Composer database View Block7 vCmpBlk8 Dbowner View Composer database View Block8 Table 34: vCenter Server and Update Manager Databases T E C H N I C A L W H I T E PA P E R / 5 4 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider To use the databases, the vCenter Server virtual machine must be configured with a number of appropriate 32-bit Open Database Connectivity (ODBC) System Database Source Names (DSN). Table 35 summarizes the required System DSNs and provides the configuration details. DATA S O URC E NAM E S E RVER TBC TBC ODB C DR IV ER AU THEN TICATION SQL Native Client 10.0 SQL ACCOU N T TBC Table 35: Management vCenter Server System DSN Configuration View Events The View Connection Server records usage events in an Events database. Configuration of an Events database is optional. If one is not present, Horizon View will record limited events in log files. View Events Database The managed database service resides on a Microsoft SQL Server 2008 platform. Table 36 summarizes the configuration requirements for the Horizon View Events database. ATTRI BUTE SPECIFICATION Vendor and version Microsoft SQL Server 2008 Authentication method SQL Authentication Recovery method Full or Simple Database autogrowth Enabled in 1MB increments. Transaction log autogrowth In 10% increments. Restricted to 2GB maximum. Database size 5GB Table 36: View Events Databases Specifications for Microsoft SQL Server 2008 The SQL Server full recovery model uses database backups and transaction log backups to provide complete protection against failure. Along with the ability to restore a full or differential backup, users can recover the database to the point of failure or to a specific point in time. With this recovery model, it is important to recognize that the logs continue growing until the user performs a backup of the database and the transaction logs. If the user sets the recovery model to full, they must back up their database and transaction logs regularly, or the transaction logs continue to grow without limit. T E C H N I C A L W H I T E PA P E R / 5 5 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider View Events Connection Details Table 37 lists the connection details to configure an Events database in View Manager. ATTRI BUTE SPECIFICATION Database server TBC Database type Microsoft SQL Server Port 1433 Database name TBC Username TBC Table prefix VE Table 37: View Events Database Specifications for Microsoft SQL Server 2008 Sizing VMware ESXi Hosts CPU Sizing Table 38 summarizes overall CPU requirements for the ESXi hosts to support the workloads of 6,000 desktop virtual machines. D E S KTO P P E RFO RM ANCE METR IC R ECOR DED VALU E Average number of CPUs per physical desktop system 1 Average CPU utilization per physical desktop system 400MHz (estimated) Total CPU for all desktop virtual machines based on average 2,400,000MHz Total CPU requirement, including additional 15% for virtualization considerations (Remote Desktop Protocol, VMware Tools, etc.) 2,760,000Mhz Table 38: ESXi Host CPU Requirements T E C H N I C A L W H I T E PA P E R / 5 6 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Table 39 shows the CPU attributes and specifications. ATTRI BUTE SPECIFICATION Number of CPUs (sockets) per host 4 Number of cores per CPU 8 GHz per CPU core 1.86 Total CPU GHz per CPU 14.88GHz Total CPU GHz per host 59.52GHz Proposed maximum host CPU utilization 65% (85% BCDR) Available CPU GHz per host 38.68GHz Table 39: CPU Attributes and Specifications Memory Sizing Table 40 summarizes the estimated number of hosts needed to support the workloads of the desktops as virtual machines. These numbers are estimates, and are not based on statistics from Region Hovedstaden. M ETRI C AMOU N T Total amount of RAM per host 262,144MB (256GB) Proposed maximum host memory utilization 80% Total memory usable per host 209,715MB (204.8GB) Total amount of RAM per virtual machine 1,024MB (1GB) Anticipated transparent memory sharing (TPS) benefit when virtualized 30% Memory overhead + video memory per virtual machine 137.81MB + 128MB Total RAM used by desktop virtual machines per host including memory overhead + TPS 193,092MB (188.5GB) Table 40: Estimated Number of Hosts T E C H N I C A L W H I T E PA P E R / 5 7 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Sizing Shared Storage Typically, a vSphere implementation will use shared storage for virtual machine data, enabling VMware features such as VMware HA, VMware DRS, and VMware vMotion. Shared storage should be presented to ESXi hosts via a redundant iSCSI SAN fabric encompassing redundant storage adapters (in the ESXi host), SAN switches, and Storage Array Processors. Virtual machine storage is presented to ESXi in the form of datastores, sized and configured optimally for the virtual machine workload expected. Horizon View Desktop Disks and Datastores The shared storage will provide a number of separate datastores for each specific Horizon View requirement (virtual machine data, user data, template data, and applications). The different disks and possible datastores break down as shown in Table 41. D I S K TY P E SPECIFICATION POSSIB LE LOCATION S Virtual Machine Disk for Full Clones (.vmdk) Full virtual machine disk that represents a unique desktop Usually shared. Limited to 32 virtual machines per datastore (on VMFS). OS Disk for Linked Clones (.vmdk) Delta file that stores changes to the desktop image when linked clones are deployed Usually shared. Limited to 128 virtual machines (VMFS). Replica Disk for Linked Clones (replica-GUID.vmdk) Read-only disk image of the parent virtual machine deployed to each datastore hosting OS disks or a single shared datastore Same as OS disk or a separate shared datastore. 1 replica per pool. 32 replicas per datastore (VMFS). Virtual Machine Swap File (.vswp) Equivalent to the amount of memory allocated to the virtual machine Same as OS Disk or Local ESXi storage. Persistent Data Disk Only used if the user profile is redirected using View Composer Same as OS disk or separate shared datastore. Disposable Data Disk (vdmdisposable-GUID.vmdk) Only used if pagefile and temporary files are redirected using View Composer Same as OS disk. Deleted when the desktop is powered off. Desktop Template Datastore Location of parent virtual machine desktop or template Shared ThinApp Datastore CIFS share used to provide streamed or locally installed ThinApp applications to Horizon View desktops Network share accessible by both View Connection Servers and Horizon View desktops. Transfer Repository Datastore The Transfer Server repository stores View Composer base images for linked-clone desktops that run in local mode Network share or local to the Transfer Server. Use network share if users are using multiple Transfer Servers. Table 41: Horizon View Desktop Disks and Datastores T E C H N I C A L W H I T E PA P E R / 5 8 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Desktop Datastore Configuration Specifications Table 42 provides an example of sizing linked clone desktop datastores for Horizon View. ATTRI BUTE S P ECIFICATION R ATION ALE OS disks per datastore 64–128 VMFS Based on best practices. 64 are considered conservative, while 128 are possible. OS disk datastore size At least 225GB for VMFS Size based on the following calculations: Master Replica size 20GB (Windows XP) Swap file size 512MB Pagefile 512MB Log file size (maximum) 10MB Maximum VMDK growth 1024MB (optimistic) Free space allocation 10% additional overhead Minimum allocated datastore size (VMFS) 225GB (100 virtual machines *(512 + 512 +10 + 1024) + 10% free space overhead) Total number of datastores (based on capacity) 1 per 100 virtual machines (VMFS) 19 required for 1,700 desktops on VMFS (iSCSI) Hosts per datastore All ESXi hosts in Horizon View desktop cluster All ESXi hosts in the Horizon View desktop cluster must mount all shared storage in that cluster to enable VMware DRS load balancing and HA failover. Table 42: Datastore Configuration Specifications per Building Block of 1,500 Virtual Machines Storage Performance Requirements In many cases, it is more important that this limit on the number of virtual machines per datastore is influenced by I/O requirements of the virtual machine and spindle types. When considering the number of virtual machines to place in a single datastore, some of the following factors should be considered in conjunction with any recommended virtual machines per datastore ratio: • Types of disks used • Typical virtual machine size (including configuration files, logs, swap files, snapshots) • Virtual machine workload and profile (in particular the amount of I/O) T E C H N I C A L W H I T E PA P E R / 5 9 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider Table 43 shows the differences in IOPS between two different types of disks. Depending on the choice of disk, this will affect the overall number of disks required per datastore. D I S K TYP E SIZE IOPS 15K RPM FC 450 ~150 SSD 100GB ~1.500+ Table 43: Disk Properties Calculations in this section are based on the EqualLogic XVS platform (SSD + SAS hybrid). Although the following section focuses on desktop datastore workloads, users should also follow this process to work out the storage sizing for the View Server workloads. Virtual Desktop Storage Workload VMware strongly recommends that consultants validate the disk I/O profile of a standard XP desktop during a working period. The figures used in the following calculations are estimates. If the actual figures do not match these estimates, the design will be invalid. When designing a storage solution, it is important to understand the I/O profile of the virtual machines that will be placed in the storage. An I/O profile is a description of an application and server I/O pattern. Some applications are heavy on reads, while others are heavy on writes. Some are heavy on sequential access, and others are heavy on random access. Recognizing this profile is essential for good storage design, as it will dictate the RAID type that should be used. Though the I/O profile can be assumed based on application type, it is best to measure I/O patterns before rolling out a production implementation. Table 44 shows the storage calculations for desktops per datastore for an example of a VMFS storage solution. ATTRI BUTE VALU E Virtual machines per datastore 100 Datastore size At least 225GB IOPS per virtual machine (normal user) 10 IOPS per virtual machine (heavy user) 20 Total IOPS (70% normal user, 30% heavy user) 90 * 10 IOPS + 38 * 20 IOPS = 900 IOPS + 760 IOPS = 1660 IOPS Average throughput per virtual machine (normal user) 200KBps (estimated) Average throughput per virtual machine (heavy user) 300KBps (estimated) Total throughput (70% normal user, 30% heavy user) 90 * 200KBps + 38 * 300KBps = 18,000 KBps + 11,400 KBps = 29,400 KB/s (28.71 MB/s) T E C H N I C A L W H I T E PA P E R / 6 0 VMware AlwaysOn Point of Care Solution Reference Implementation Case Study for European Healthcare Provider ATTRI BUTE VALU E RAID 5 penalty for writes 4 RAID 10 penalty for writes 2 Total IOPS required 1162 + 498 * 4 = 3154 IOPS (RAID 5) (70% reads, 30% writes) 1162 + 498 * 2 = 2158 IOPS (RAID 10) Total IOPS required 830 + 830 * 4 = 4150 IOPS (RAID 5) (50% reads, 50% writes) 830 + 830 * 2 = 2490 IOPS (RAID 10) Total IOPS required 498 + 1162 * 4 = 5146 IOPS (RAID 5) (30% reads, 70% writes) 498 + 1162 * 2 = 2822 IOPS (RAID 10) Table 44: Desktop Storage Calculations (VMFS) VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com Copyright © 2013 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. Item No: VMW-TWP-ALWAYSONPTOFCAREEUHEALTH-20131008-WEB