Citrix XenDesktop 7.6 on Citrix XenServer 6.5 with FlexPod Express. Solution Design

Transcription

1 Citrix XenDesktop 7.6 on Citrix XenServer 6.5 with FlexPod Express Solution Design Citrix Validated Solutions March 25 th 2015 Prepared by: Citrix APAC Solutions

2 TABLE OF CONTENTS Section 1: Executive Summary... 5 Project Overview... 6 Reference Architecture... 6 Purpose... 6 Audience... 6 Architecture Overview... 7 Citrix Virtual Desktop Types... 7 The Pod Concept... 7 Justification and Validation... 8 Citrix Validated Solution Overview... 9 Solution at a Glance Citrix Layered Architecture Design Recommendations Logical Architecture Overview Scale Out Guidance for HSD Scale Out Guidance for HVD Section 2: Design User Layer Design User Topology Endpoints Access Layer Design StoreFront Configuration Desktop Layer Design User Personalisation Applications Master Image Control Layer Design Infrastructure Delivery Controllers (XenDesktop) Access Controllers (StoreFront) Hypervisor XenServer Overview XenServer Host HSD

3 XenServer Host HVD XenServer Hardware Details XenServer General Details XenServer Network Details XenServer Guest Virtual Machine Details Storage Technology Overview NetApp FAS Technology Overview Clustered Data ONTAP Multiprotocol Unified Architecture Logical Interface (LIF) Overview Flash Pool Overview Storage Design NetApp FAS2552 Hybrid Storage Array Architecture Aggregate Design Storage Virtual Machine Design Flexible Volume (FlexVol) Design Namespace Design Logical Interface (LIF) Design IP Fast Path Gigabit Ethernet Network Overview Network Components VLAN Information DHCP Hardware Layer Design Physical Architecture Overview Physical Component Overview Server Hardware Storage Hardware Bill of Materials - Hosted Shared Desktops Bill of Materials - Hosted Virtual Desktops Bill of Materials - Storage Section 3: Appendices Appendix A. Further Decision Points

4 Appendix B. Server Inventory HSD Servers (Support up to 1,000 x User Desktop Sessions) HVD Servers (Support up to 1,000 x Win 7 Virtual Desktops) Appendix C. Windows Server 2012 R2 HSD Overview Pod of 700 Windows 2012 R2 HSD Users Server Inventory HSD Servers (Support up to 700 x User Desktop Sessions) Appendix D. Windows 8.1 Hosted Virtual Desktops Overview Pod of 600 Windows 8.1 HVD Users Server Inventory Appendix E. Network Switch Requirements Switch Requirements Network Port Densities Appendix F. IP Addressing XenServer Hosts: NetApp FAS2552: Control Layer Guest VMS: Sample HSD DHCP Scope: Sample HVD DHCP Scopes: Appendix G. Service Accounts & Groups Role Groups Service Accounts Appendix H. XenDesktop Policies Test Environment Policy Settings Appendix I. Cisco C240 M3 SFF Server BIOS Settings Processor Memory Appendix J. Storage Calculations NetApp Sizing Guidance XenServer Infrastructure SR XenServer vdi SR HVD - Persistent Desktops File Sharing and User Data

5 Appendix K. Test Results Validation Appendix L. References Citrix Cisco NetApp Revision History

6 SECTION 1: EXECUTIVE SUMMARY 5

7 Project Overview Reference Architecture In order to facilitate rapid and successful deployment of the Citrix XenDesktop FlexCast models, Citrix Consulting APAC have built and tested a solution using the components described in this document. The Citrix Validated Solution ( CVS ) provides prescriptive guidance for these components including design, configuration and deployment settings thereby allowing customers to quickly deploy a desktop virtualization solution using Citrix XenDesktop. Validation was performed through extensive testing using Login VSI to simulate real-world workloads and determine optimal configuration for the integration of components that make up the overall solution. Purpose The purpose of this document is to provide design information that describes the architecture for this Citrix Validated Solution which is based on Citrix Hosted Shared Desktop (HSD) and Citrix Hosted Virtual Desktop (HVD) FlexCast models. The solution is built on FlexPod Express which is a converged infrastructure featuring Cisco C240 M3 High-Density Rack servers and a NetApp FAS2552 Hybrid Storage Array. Citrix XenServer 6.5 is the hypervisor utilised to support the virtualised environment. Audience This reference architecture document is created as part of a Citrix Validated Solution and is intended to describe the detailed architecture and configuration of the components contained within. Readers of this document should be familiar with Citrix XenDesktop, its related technologies and the foundational components, Cisco C240 M3 High-Density Rack servers, NetApp FAS2552 Hybrid Storage Array, networking components and Citrix XenServer

8 Architecture Overview This Citrix Validated Solution and its components were designed, built and validated to support two distinct Citrix virtual desktop types. The architecture for each desktop type is described to support a definitive number of user desktop sessions or a single pod: Hosted Shared Desktops. Shared user sessions running XenDesktop Hosted Shared Desktops on Windows Server 2008 R2 or Server 2012 R2 Remote Desktop Session Hosts Hosted Virtual Desktops. Individual user sessions running XenDesktop Hosted Virtual Desktops on Windows 7 Enterprise x64 or Windows 8.1 x 64 Enterprise Each of these desktop types is described in the Citrix FlexCast model operating as virtual machine instances on Citrix XenServer 6.5. This architecture is a single, self-supporting modular component identified as a Pod, described to support up to a specific number of user desktop sessions allowing customers to consistently build and deploy scalable environments. Additional pods may be deployed thus scaling out the proposed architecture beyond the maximum number of desktops supported by a single pod. Citrix Virtual Desktop Types This Citrix Validated Solution document references Citrix Hosted Shared Desktops and Citrix Hosted Virtual Desktops. Both types of virtual desktops are discussed below for reference. For more information, refer to Citrix FlexCast delivery methods Hosted Shared Desktop (HSD). A Windows Remote Desktop Session (RDS) Host using Citrix XenDesktop to deliver Hosted Shared Desktops in a locked down, streamlined and standardised manner with a core set of applications. Using a published desktop on to the Remote Desktop Session Host, users are presented a desktop interface similar to a standard Windows desktop operating system look and feel. Each user runs in a separate session on the RDS server. Hosted Virtual Desktop (HVD) aka Hosted VDI. A Windows desktop operating system, instance running as a virtual machine where a single user connects to the machine remotely. Consider this as 1:1 relationship of one user to one desktop. There are differing types of the hosted virtual desktop model (existing, installed, pooled, dedicated and streamed). This document refers to both pooled and dedicated (persistent) types of HVD. This document will discuss the delivery of persistent and non-persistent (state-less) desktop types. Hosted Shared Desktops and Hosted Virtual Desktops. Throughout this document nomenclature may reference the FlexCast model as; <FlexCast model> which should be substituted for either HSD or HVD as appropriate to the design under consideration. The Pod Concept The term pod is referenced throughout this solution design. In the context of the architecture described in this document a pod is a known entity, an architecture that has been pre-tested and validated. A pod consists of the hardware and software components required to deliver each of the following workload maximums (As defined and validated by the Login VSI Medium Workload): 1,000 virtual desktops running Windows 7 (refer to the Appendices for further details on this pod size) 1,000 virtual desktop sessions running on Server 2008 R2 RDS server For clarity this document does not attempt to describe combining both FlexCast models, it specifically discusses each type as a single entity. This document will primarily reference only Windows 7 and Server 2008 R2 workloads. For Windows 8.1 and Server 2012 R2 please refer to the Appendices. 7

9 Justification and Validation The construct of this Citrix Validated Solution is based on many decisions that were made during validation testing. Testing was carried out using the Login VSI virtual Session Indexer (VSI), an industry standard tool for user / session benchmarking. Login VSI allows comparisons of platforms and technologies under the same repeatable load. The Medium VSI workload is expected to approximate the average office worker during normal activities and was the workload used throughout testing. The Logon storm was used to measure the maximum session densities that are described in this document. The Duration of the logon storm was set to 1 hour for all tests after the logon storm event e.g. steady state; the system under test is noted to be at a moderate load only. Note. All workloads were tested using the XenDesktop Template Policy High Server Scalability therefore the Bill of Materials described for each FlexCast model within this document are based on the density of users with these policy settings in place. Using these Citrix Policies allows the greatest host density for each FlexCast model. 8

10 Citrix Validated Solution Overview The Illustration below depicts the layers of the Citrix XenDesktop Hosted Shared Desktop technology stack utilised in the solution. Figure 1. Citrix Validated Solution Stack depicting HSD Workloads The Illustration below depicts the layers of the Citrix XenDesktop Hosted Virtual Desktop technology stack utilised in the solution. Figure 2. Citrix Validated Solution Stack depicting HVD Workloads 9

11 The Illustration below depicts the combined physical and logical view of the scale out architecture for the HSD platform using the Cisco C240 M3 SFF servers. Figure 3. Logical View of the HSD Solution describing Server 2008 R2 workloads The Illustration below depicts the combined physical and logical view of the scale out architecture for the Windows 7 HVD platform using the Cisco C240 M3 SFF servers. Figure 4. Logical View of the HVD Solution describing Windows 7 workloads 10

12 Architecture Components Citrix XenDesktop. Two virtualised Delivery Controller servers will be deployed to support the XenDesktop Site. A single XenDesktop Site will be utilised to manage the initial desktop pod. Virtual Desktops. This solution will focus on the delivery of the two discrete virtual desktops types: o o Hosted Virtual Desktops (HVD). Describing the delivery of a single pod of Pooled or Persistent Windows 7 or 8 virtual desktops powered by Citrix XenDesktop 7.6. Hosted Shared Desktops (HSD). Describing the delivery of a single pod of Shared virtual desktops based on Microsoft Windows Server 2008 R2 or Server 2012 R2 Remote Desktop Session host workloads powered by Citrix XenDesktop 7.6. Citrix XenServer (XenServer). The hypervisor selected to host the virtualised desktop and server instances for this solution is Citrix XenServer 6.5. XenServer will be deployed onto the Cisco C240 M3 SFF servers. Virtual Desktop Provisioning. This document describes the use of Citrix Machine Creation Services ( MCS ) for the provisioning of HSD and HVD guest workloads using a predefined master image containing the optimised operating system and Tier-1 application set. Applications. Tier-2 1 applications which may include line of business or customer specific applications that are not embedded as part of the master disk image may be delivered using Citrix XenDesktop/XenApp or Microsoft App-V 2. Citrix StoreFront. Virtualised StoreFront servers will be deployed to provide application and desktop resource enumeration. Citrix Performance Management. Citrix Director and Citrix EdgeSight will provide monitoring capabilities into the virtual desktops and user sessions. FlexPod Express Converged Infrastructure Platform. FlexPod Express provides a pretested, low-cost converged infrastructure solution that is integrated and delivered by an ecosystem of joint channel partners. The converged solution includes the following components: o o o Cisco UCS C-Series Rack Servers. High density compute platform based on rack server form factor. To provide VM and Infrastructure redundancy, a minimum of two Cisco servers running XenServer 6.5 are required to instantiate the environment. Three servers are required to enable XenServer Pool HA for specific VMs 3. Cisco Nexus Switches. As per the test environment, a pair of Cisco Nexus 3048TP 1GbE Top of Rack (ToR) switches has been used however existing 1GbE network switch infrastructure can be leveraged to minimise hardware acquisition cost. NetApp Storage. A NetApp FAS2552 Hybrid Storage Array will be utilised with dual controllers to present NFS version 3 over TCP (NFSv3) storage to the XenServer hosts. The NetApp FAS2552 Hybrid Storage Array will also provide CIFS file shares for the User Profile solution and XenServer ISO Storage 1 The solution design for Tier-2 applications delivered by Citrix XenDesktop or Citrix XenApp is out of scope for this document. 2 The solution design of Microsoft App-V components is out of scope for this document. 3 All Infrastructure VMS are deployed as n+1 for redundancy therefore HA is not mandatory. 11

13 Repository. The NetApp FAS2552 Hybrid Storage Array will contain a combination of SSD and SAS disks for dynamic workload acceleration. Supporting Infrastructure. The following components are assumed to exist within the customer environment and are required infrastructure components: o o o o Microsoft Active Directory Domain Services. A suitable Microsoft SQL database platform to support the solution database requirements 4. Licensing servers to provide Microsoft licenses are assumed to exist. DHCP Services with sufficient IP addresses to support the proposed virtual desktop workloads. This can be provisioned as part of the solution using the Windows Server 2012 R2 DHCP Role. This design document will focus on the desktop virtualisation components which include the desktop workload, desktop delivery mechanism, hypervisor, hardware, network and storage platforms. 4 This document provides sample sizing guidelines and the licensing requirements for the databases used in this Citrix Validated Solution; however it does not attempt to provide design guidelines for Microsoft SQL Server. The design and implementation for a highly available Microsoft SQL Server platform is required although considered out of scope for this design document. 12

14 Solution at a Glance This section defines the key decisions points and options offered by this Citrix Validated Solution. The subsequent sections within this document provide the detailed configuration of each element. Category Key Solution Requirements Design Decision Resilient infrastructure to deliver HSD and HVD desktops (pooled and Persistent) Low cost entry point platform utilising Cisco and NetApp hardware components suitable up to the maximum number of seats described within the applicable pod Scalable solution that can be scaled out to n number of pod(s) Minimum Infrastructure Requirement 1 x NetApp FAS2552 Hybrid Storage Array 2 x Cisco C240 M3 servers running XenServer 6.5 1GbE network Scalability Minimum, 1 x NetApp FAS2552 Hybrid Storage Array for a maximum number of desktops as applicable to the pod XenDesktop XenDesktop 7.6 Platinum Minimum number of nodes is two (2) Cisco C240 M3 servers as applicable to the pod o o Note to benefit from the XenServer Storage Read Caching feature and achieve the maximum workload size of each pod, XenDesktop Platinum or XenServer Enterprise is required. Please review the following License FAQs for XenServer: Machine Creation Services workload delivery Highly scalable and redundant Delivery Controller servers Vertical scalability by increasing CPU/RAM resources or horizontal scalability by adding Delivery Controllers Desktop Types Hosted Shared Desktops (HSD) on Windows Sever 2008 R2 (Enterprise Edition) or Windows Server 2012 R2 (Standard edition): Hypervisor Citrix XenServer 6.5 o o o 8 vcpus, 18GB RAM, 100GB disk, 1 vnic Horizontal scalability by deploying more VMs onto available hosts Redundancy by overprovisioning desktop capacity Hosted Virtual Desktops on Windows 7 Enterprise SP1 x64 or Windows 8.1 Enterprise x64 (Pooled or Persistent) o o o o 2 vcpus, 2.5GB RAM, 100GB disk, 1 vnic Horizontal scalability by deploying more VMs onto available hosts Redundancy by overprovisioning desktop capacity VM High Availability for persistent desktops Single XenServer Resource Pool per pod Vertical scalability by increasing CPU/RAM resources or Horizontal scalability by deploying additional server nodes Compute and Hardware Cisco C240 M3 SFF server nodes Dual socket Intel 10-core CPUs 128GB RAM for HSD 256GB-320GB RAM for HVD 13

15 Category Design Decision 300GB volume for XenServer / OS Redundant network interfaces for Host Management, VM Guest and storage networks Storage NetApp FAS2552 Hybrid Storage Array Clustered Data ONTAP storage operating system Dual Controller two-node switchless cluster in a single 2U chassis 4 x 200GB SSD 20 x 600GB 10K SAS Configured with 1GbE network interfaces NFSv3 storage presented to XenServer by a single Storage Virtual Machine (SVM) Networking and Related Hardware DNS round robin will be utilised to load balance the StoreFront servers Customer can leverage existing load balancer hardware investment or alternatively deploy a pair of Citrix NetScaler in High Availability to provide both load balancing and remote-access capability (Recommended) Customer can leverage existing 1GbE network switches to integrate the physical host servers and NetApp FAS2552 Hybrid Storage Array into their environment. Alternatively, a pair of Cisco Nexus 3048 or Catalyst switches can be procured. Refer to the Appendix for Network Requirements File Services CIFS/SMB services are presented by a separate Storage Virtual Machine hosted on the NetApp FAS2552 Hybrid Storage Array for User Profile data only, XenServer ISO SR and Media repositories Up to 1.0GB per user for maximum of 1,000 users Additional storage requirements such as user home directories and group share drives will require additional shared storage which is not covered as part of the solution. The NetApp FAS2552 Hybrid Storage Array used in this solution could be expanded to cater for the additional requirements. See the Storage section for more information Applications Baseline applications installed as per the SOE (Tier-1) Integration and deployment of Line of Business (LoB) or customerspecific applications (Tier-2) would need to be catered for. Additional services and infrastructure may be required Access Redundant StoreFront servers with DNS round robin for simplicity and low cost. Recommendation to leverage Citrix NetScaler HA appliances as the environment is scaled-out. Additional load balancing capability can be used via Citrix NetScaler appliances Vertical scalability to StoreFront servers by increasing CPU/RAM resources Remote Access solution, i.e. in the form of Citrix NetScaler or other is out of scope and would need to be factored in, if required. Availability/Redundancy Assumes single data centre (single physical location) only Delivery Controllers redundant servers (N+1 VMs placed on different hosts) XenServer hosts configured as a single resource pool per pod. HA may be enabled for specific VMs with greater than 3 XenServer hosts in the pool XenServer NICs NIC Bonding, LACP, Active/Active or Active/Passive refer to the Network section for Switch options VM data Highly available NFSv3 services presented by the redundant 14

16 Category Design Decision NetApp FAS2552 Hybrid Storage Array controllers. StoreFront servers redundant servers (N+1 VMs placed on different hosts). DNS round-robin configured which can be further improved by integrating Citrix NetScaler SQL 2012 DB Servers redundant servers (N+1 VMs placed on different hosts) XenDesktop Databases database mirroring in active/passive setup CIFS/SMB File Services provided by the NetApp FAS2552 Hybrid Storage Array in a dual controller HA configuration Windows DHCP Services redundant servers (N+1 VMs placed on different hosts) Citrix License Server stand-alone, built in 30-day grace period Local Storage RAID-1 (Mirror) for the XenServer Boot volume Table 1. Solution at a glance 15

17 Citrix Layered Architecture The Citrix Validated Solution architecture breaks the design into a number of distinct layers, discussed below: User Layer 5. This layer details the user segments defined during the projects assess phase. Users are grouped based on their network connectivity to the data centre, recommended end point devices, security requirements, data storage needs and virtual workforce needs. Access Layer. This layer describes how the user layer will connect to their desktop, which is hosted in the desktop layer of the architecture. Local users will connect directly to StoreFront while remote users connect via a set of firewalls that protect the internal environment. To bridge the firewalls, remote users may connect with an SSL-VPN device (Citrix Access Gateway). Desktop Layer. This layer contains the user s virtual desktop, broken down into FlexCast models. It is subdivided into three components, Within each sub-layer, specifics are documented detailing the operating system, assigned policies, profile design and application requirements: o o o User Personalisation Applications Master Image Control Layer. This layer is responsible for managing and maintaining all other layers. It provides details on the controller requirements to support the entire solution. The Control layer is broken down into the following sub sections: o o o Infrastructure. The infrastructure section is responsible for providing the underlying resources to support each component. These resources include Active Directory, database requirements and license servers. Desktop Controllers. The Desktop Controllers section provides details on the components required to support the desktop layer, which include XenDesktop. Access Controllers. The Access Controllers section focuses on the required versions and virtualisation resources. o Hypervisor. The section described the configuration for Citrix XenServer 6.5. XenServer is a Type 1 hypervisor that runs directly on the hardware resources described in the Hardware Layer. o o Storage. The storage layer describes the logical and physical entities as relates to the proposed NetApp storage architecture. Network. This section defines the physical network switching and logical connectivity requirements to support the solution. Hardware Layer. This layer is responsible for the physical devices required to support the entire solution. It includes servers, processors, memory and storage devices. This layer is broken down into the physical and logical components and provides the Bill of Materials (BoM) to deploy the entire solution. 5 User assessment in context of this document is for reference only. User definition and segmentation for VDI desktop types is out of scope for this document. 16

18 The illustration below describes the conceptual architecture: Figure 5. Architecture Conceptual View 17

19 The illustration below describes the distinct layers of the architecture: Figure 6. Architecture Layered View Design Recommendations Assumptions: The following assumptions have been made: Required Citrix and Microsoft licenses and agreements are available. Required power, cooling, rack and data centre space is available. No network constraints that would prevent the successful deployment of this design. Microsoft Windows Active Directory Domain services are available. Microsoft SQL Database platform is available. Certificate and/or PKI services are assumed to exist or external services may be used. A current and supported version of Citrix Receiver must be deployed to ensure all features and components of the solution are at a supported level, refer to the following link for the latest Citrix Receiver Downloads. The User layer in the context of this document is for reference only. User analysis, definition and segmentation for the use of VDI desktop types is out of scope for this document. 18

20 Logical Architecture Overview This section discusses the logical architecture and concepts for the remainder of this document. From an architectural perspective XenServer will be deployed onto the aforementioned hardware (Hardware Layer). The infrastructure servers (Control layer) and virtual desktops (Desktop Layer) are deployed as XenServer virtual machine instances that reside on NFSv3 storage over TCP hosted on the NetApp FAS2552 Hybrid Storage Array. Storage is presented to the XenServer Resource Pool hosts via an isolated non-routable VLAN ensuring NFSv3 traffic utilises the specified network. From a physical hardware perspective each server node will be configured identically as per the recommended Cisco C240 Bill of Materials 6. The NetApp FAS2552 Hybrid Storage Array dictates the actual pod size as defined by its physical capabilities (additional pods can be deployed). From a logical perspective the hosts for each desktop type can be defined as follows: A minimum of two sever nodes and the NetApp FAS2552 Hybrid Storage Array is required to establish the foundation of a Citrix XenDesktop environment complete with the necessary infrastructure servers, guest VMs deployed in a redundant fashion. The first two servers, Node1 and Node 2 will be referred to as Shared Infrastructure & Desktop Nodes as they will host both Infrastructure Server VMs and Desktop VM workloads. The platform can be scaled-out to support additional capacity by simply adding subsequent physical servers or nodes up to the maximum as defined by the NetApp FAS2552 Hybrid Storage Array for each workload and referred to as Desktop nodes. Each Desktop node will only support guest HSD or HVD workloads. The following illustrations describe the architecture as relates to the pod definitions. 6 Infrastructure and desktop host Memory requirements may differ to maintain cost efficiencies. 19

21 Pod of 1,000 Server 2008 R2 HSD Users The logical and physical components that make up the platform to deliver a 1,000 user Hosted Shared Desktop solution running on Server 2008 R2 RDS are described below: Figure 7. VM Allocation for Server 2008 R2 HSD Component Qty # of Citrix XenDesktop Enterprise Users Up to 1,000 # of XenDesktop Sites 1 # of XenDesktop Delivery Controllers 2 # of StoreFront Servers 2 # of Citrix/Microsoft License Server 7 1 # of Management Server (Director, Studio, NetApp, XenCenter) 1 # of SQL 2012 Standard Servers (DB Mirror in Active/Passive) 8 2 # of Cisco C240 Server Nodes running Citrix XenServer # of NetApp FAS2552 Storage 1 # of XenApp RDS (HSD) Windows Server VMs 40 Table 2. 1,000 User Server 2008 R2 HSD Pod Detail 7 Optional. License services can be deployed onto existing servers to conserve resources. 8 Optional. Existing SQL environment can also be leveraged to provide database capability to conserve resources. 20

22 Pod of 1,000 Windows 7 HVD Users The logical and physical components that make up the platform to deliver a 700 user Hosted Virtual Desktop solution running on Windows 7 are described below: Figure Desktops running Windows 7 HVD Pod Detail Component Qty # of Citrix XenDesktop Enterprise Users Up to 1,000 # of XenDesktop Sites 1 # of XenDesktop Delivery Controllers 2 # of StoreFront Servers 2 # of Citrix/Microsoft License Server 9 1 # of Management Server (Director, Studio, NetApp, XenCenter) 1 # of SQL 2012 Standard Servers (DB Mirror in Active/Passive) 10 2 # of Cisco C240 Server Nodes running Citrix XenServer # of NetApp FAS2552 Storage 1 # of Windows 7 Enterprise HVD (virtual desktops) 1,000 Table User HVD on Windows 7 Pod Detail 9 Optional. License services can be deployed onto existing servers to conserve resources. 10 Optional. Existing SQL environment can also be leveraged to provide database capability to conserve resources. 21

23 Scale Out Guidance for HSD This section outlines the sizing metrics applicable to the NetApp FAS2552 Hybrid Storage Array, Cisco C240 server nodes, network switch ports, XenServer hosts, Infrastructure server VMs and the required Citrix and Microsoft licenses 11 to stand up the HSD solution based on Server 2008 R2 (Server 2012 R2 Not Shown) and the suggested scale-out increment. The solution can be scaled out incrementally by adding additional single server nodes, however in this section the scenarios depicts the addition of two server nodes for demonstration purposes. Notes on Microsoft Licensing used as per the below samples 12. # of MS SQL Server 2012 Standard Server 13. Assumes SQL Server is licensed as a 2 VCPU (v-cores) virtual machine with MS Software Assurance. SQL Server license requires minimum of 4 core licenses. Active-Passive SQL Server deployment means no additional licenses are required for secondary passive SQL Server. Refer to In the context of this document the full or maximum scale out load is described while running the HSD desktop types under test load to their maximum densities that are: ~1,000 Server 2008 R2 RDS hosted shared desktops or ~700 Server 2012 R2 RDS hosted shared desktops At this point the NetApp FAS2552 Hybrid Storage Array is stated to be at full load during the logon storm test of the desktop type. Note: The logon storm is one of the most aggressive components of the testing in the consumption of resources. 11 Each customer will have different Citrix and Microsoft license agreements and as such should be factored into the final configuration. 12 Actual customer licensing requirements may differ based on their situation, agreements or other factors. 13 Optional. Existing SQL environment can also be leveraged to provide database capability to conserve resources. 22

24 Scenario: 2 x Nodes Hardware Components Qty Infrastructure Components Qty # of Cisco C240 nodes 2 # of XenServer hosts 2 # of RU (Cisco server nodes) 4 # of XenDesktop Sites 1 # of 1GbE Ports (XenServer) 8 # of Server 2008 R2 HSD users 280 # of 1GbE Ports (NetApp) 6 # of HSD Windows Server VMs 10 Total # of 1GbE Ports 14 Management VM 14 1 # of FAS2552 Appliances (Storage) 1 # of ToR 1GbE 48-port Switch 2 Table 4. Hardware Component Breakdown - 2 x Nodes Citrix/Microsoft License Components Qty # of Citrix XenDesktop Platinum User/Device 280 # of MS Remote Desktop Services CALs 280 # of MS Window Server 2012 Standard 9 # of MS SQL Server 2012 Standard Server 1 Table 5. Component Breakdown - 2 x Nodes Figure 9. Rack Layout 2 x Nodes 14 Optionally the Management Server can also be deployed on existing Windows Server VMs to minimise VM resources used and Windows Server license consumption. 23

25 Scenario: 4 x Nodes Hardware Components Qty Infrastructure Components Qty # of Cisco C240 nodes 4 # of XenServer hosts 4 # of RU (Cisco server nodes) 8 # of XenDesktop Sites 1 # of 1GbE Ports (XenServer) 16 # of HSD users 620 # of 1GbE Ports (NetApp) 6 # of HSD Windows Server VMs 22 Total # of 1GbE Ports 22 Management VM 15 1 # of FAS2552 Hybrid Storage Array 1 # of ToR 1GbE 48-port Switch 2 Table 6. Hardware Component Breakdown - 4 x Nodes Citrix/Microsoft License Components Qty # of Citrix XenDesktop Platinum User/Device 620 # of MS Remote Desktop Services CALs 620 # of MS Window Server 2012 Standard 15 # of MS SQL Server 2012 Standard Server 1 Table 7. Component Breakdown - 4 x Nodes Figure 10. Rack Layout 4 x Nodes 15 Optionally the Management Server can also be deployed on existing Windows Server VMs to minimise VM resources used and Windows Server license consumption. 24

26 Scenario: 6 x Nodes Hardware Components Qty Infrastructure Components Qty # of Cisco C240 nodes 6 # of XenServer Hosts 6 # of RU (Cisco server nodes) 12 # of XenDesktop Sites 1 # of 1GbE Ports (XenServer) 24 # of HSD users 960 # of 1GbE Ports (NetApp) 6 # of HSD Windows Server VMs 34 Total # of 1GbE Ports 30 Management VM 16 1 # of FAS2552 Hybrid Storage Array 1 # of ToR 1GbE 48-port Switch 2 Table 8. Hardware Component Breakdown - 6 x Nodes Citrix/Microsoft License Components Qty # of Citrix XenDesktop Platinum User/Device 960 # of MS Remote Desktop Services CALs 960 # of MS Window Server 2012 Standard 21 # of MS SQL Server 2012 Standard Server 1 Table 9. Component Breakdown - 6 x Nodes Figure 11. Rack Layout 6 x Nodes 16 The Management Server can also be deployed on existing Windows Server VMs to minimise VM resources used and Windows Server license consumption. 25

27 Scenario: 7 x Nodes Hardware Components Qty Infrastructure Components Qty # of Cisco C240 nodes 7 # of XenServer Hosts 7 # of RU (Cisco server nodes) 14 # of XenDesktop Sites 1 # of 1GbE Ports (XenServer) 28 # of HSD users 1,000 # of 1GbE Ports (NetApp) 6 # of HSD Windows Server VMs 40 Total # of 1GbE Ports 34 Management VM 17 1 # of FAS2552 Hybrid Storage Array 1 # of ToR 1GbE 48-port Switch 2 Table 10. Hardware Component Breakdown - 7 x Nodes Citrix/Microsoft License Components Qty # of Citrix XenDesktop Platinum User/Device 1,000 # of MS Remote Desktop Services CALs 1,000 # of MS Window Server 2012 Standard 24 # of MS SQL Server 2012 Standard Server 1 Table 11. Component Breakdown - 7 x Nodes Figure 12. Rack Layout 7 x Nodes 17 The Management Server can also be deployed on existing Windows Server VMs to minimise VM resources used and Windows Server license consumption. 26

28 Scale Out Guidance for HVD This section outlines the sizing metrics applicable to the NetApp FAS2552 Hybrid Storage Array, Cisco C240 server nodes, network switch ports, XenServer hosts, Infrastructure server VMs and the required Citrix and Microsoft licenses 18 to stand up the HVD solution based on Windows 7 (Windows 8.1 not shown) and the suggested scale-out increment. The solution can be scaled out incrementally by adding additional single server nodes, however in this section the scenarios depicts the addition of two server nodes for demonstration purposes. Notes on Microsoft Licensing used as per the below samples 19. # of MS SQL Server 2012 Standard Server 20. Assumes SQL Server is licensed as a 2 VCPU (v-cores) virtual machine with MS Software Assurance. SQL Server license requires minimum of 4 core licenses. Active-Passive SQL Server deployment means no additional licenses are required for secondary passive SQL Server. Refer to In the context of this document full or maximum load is described while running the HVD desktop types under test load to the maximum densities that are: ~1,000 Windows 7 virtual desktops or ~600 Windows 8.1 virtual desktops. At this point the NetApp FAS2552 Hybrid Storage Array is stated to be at full load during the logon storm test of each desktop type. Note: The logon storm is one of the most aggressive components of the testing in the consumption of resources. 18 Each customer will have different Citrix and Microsoft license agreements and as such should be factored into the final configuration. 19 Actual customer licensing requirements may differ based on their situation, agreements or other factors. 20 Optional. Existing SQL environment can also be leveraged to provide database capability to conserve resources. 27

29 Scenario: 2 x Nodes Hardware Components Qty Infrastructure Components Qty # of Cisco C240 nodes 2 # of XenServer hosts 2 # of RU (Cisco server nodes) 4 # of XenDesktop Sites 1 # of 1GbE Ports (XenServer) 8 # of Windows 7 HVD users 180 # of 1GbE Ports (NetApp) 6 # of VDIs 180 Total # of 1GbE Ports 14 Management VM 21 1 # of FAS2552 Hybrid Storage Array 1 # of ToR 1GbE 48-port Switch 2 Table 12. Hardware Component Breakdown - 2 x Nodes Citrix/Microsoft License Components Qty # of Citrix XenDesktop Platinum User/Device 180 # of MS Virtual Desktop Access 180 # of MS Window Server 2012 Standard 4 # of MS SQL Server 2012 Standard Server 1 Table 13. Component Breakdown - 2 x Nodes Figure 13. Rack Layout 2 x Nodes 21 Optionally the Management Server can also be deployed on existing Windows Server VMs to minimise VM resources used and Windows Server license consumption. 28

30 Scenario: 4 x Nodes Hardware Components Qty Infrastructure Components Qty # of Cisco C240 nodes 4 # of XenServer hosts 4 # of RU (Cisco server nodes) 8 # of XenDesktop Sites 1 # of 1GbE Ports (XenServer) 16 # of Windows 7 HVD users 460 # of 1GbE Ports (NetApp) 6 # of VDIs 460 Total # of 1GbE Ports 22 Management VM 22 1 # of FAS2552 Hybrid Storage Array 1 # of ToR 1GbE 48-port Switch 2 Table 14. Hardware Component Breakdown - 4 x Nodes Citrix/Microsoft License Components Qty # of Citrix XenDesktop Platinum User/Device 460 # of MS Virtual Desktop Access 460 # of MS Window Server 2012 Standard 4 # of MS SQL Server 2012 Standard Server 1 Table 15. Component Breakdown - 4 x Nodes Figure 14. Rack Layout 4 x Nodes 22 Optionally the Management Server can also be deployed on existing Windows Server VMs to minimise VM resources used and Windows Server license consumption. 29

31 Scenario: 6 x Nodes Hardware Components Qty Infrastructure Components Qty # of Cisco C240 nodes 6 # of XenServer hosts 6 # of RU (Cisco server nodes) 12 # of XenDesktop Sites 1 # of 1GbE Ports (XenServer) 24 # of Windows 7 HVD users 740 # of 1GbE Ports (NetApp) 6 # of VDIs 740 Total # of 1GbE Ports 30 Management VM 23 1 # of FAS2552 Hybrid Storage Array 1 # of ToR 1GbE 48-port Switch 2 Table 16. Hardware Component Breakdown - 6 x Nodes Citrix/Microsoft License Components Qty # of Citrix XenDesktop Platinum User/Device 740 # of MS Virtual Desktop Access 740 # of MS Window Server 2012 Standard 4 # of MS SQL Server 2012 Standard Server 1 Table 17. Component Breakdown - 6 x Nodes Figure 15. Rack Layout 6 x Nodes 23 Optionally the Management Server can also be deployed on existing Windows Server VMs to minimise VM resources used and Windows Server license consumption. 30

32 Scenario: 8 x Nodes Hardware Components Qty Infrastructure Components Qty # of Cisco C240 nodes 8 # of XenServer hosts 8 # of RU (Cisco server nodes) 16 # of XenDesktop Sites 1 # of 1GbE Ports (XenServer) 32 # of Windows 7 HVD users 1,000 # of 1GbE Ports (NetApp) 6 # of VDIs 1,000 Total # of 1GbE Ports 38 Management VM 24 1 # of FAS2552 Hybrid Storage Array 1 # of ToR 1GbE 48-port Switch 2 Table 18. Hardware Component Breakdown - 8 x Nodes Citrix/Microsoft License Components Qty # of Citrix XenDesktop Platinum User/Device 1,000 # of MS Virtual Desktop Access 1,000 # of MS Window Server 2012 Standard 4 # of MS SQL Server 2012 Standard Server 1 Table 19. Component Breakdown - 8 x Nodes Figure 16. Rack Layout 8 x Nodes 24 Optionally the Management Server can also be deployed on existing Windows Server VMs to minimise VM resources used and Windows Server license consumption. 31

33 SECTION 2: DESIGN 32

34 User Layer Design User Topology This design is focused on the delivery of virtual desktops using Citrix XenDesktop as discussed in the section, Citrix Virtual Desktops Types. There are a number of classifications that can be used to define a user s role within an organisation and determine the most appropriate virtual desktop type that is best suited for a customer s environment and circumstances 25. Figure 17. User and Endpoint examples The table below provides some example User Type classifications and alignment of FlexCast models, this Citrix Validation Solution is focused: Example: User Type Example: Description Example: Location / Remote LAN / WAN Example: Desktop Types (Flex Cast) Kiosk Worker Public non trusted user LAN / WAN Hosted Shared Task Workers Call Centre LAN Hosted Shared Knowledge Workers Finance department Remote / LAN / WAN Hosted Shared or Hosted Virtual (Pooled) Developer/Power User Engineering All Hosted Virtual (Persistent) Endpoints Table 20: Example User Role Classifications A current and supported version of Citrix Receiver must be deployed to ensure all Citrix XenDesktop features and components of this Citrix Validated Solution are at a supported level, refer to the following link for the latest Citrix Receiver Downloads. 25 A Desktop Transformation Assessment to determine the best fit of a user Role to desktop type is out of scope for this document. 33

35 Access Layer Design The Access Layer explains how a user group will connect to their assigned virtual desktop. User location, connectivity and security requirements play a critical role in defining how users authenticate. Citrix Storefront provides a unified application and desktop aggregation point. Users can access their desktop through a standard Web browser using Citrix Receiver. Figure 18. Access Layer Design Components StoreFront Configuration The key design decisions for the Access Layer are as follows: Decision Point Version, Edition StoreFront Version 2.6 Description / Decision Authentication Point Security Active Directory A server certificate will be installed to secure authentication traffic: https will be required for all web sites, ensuring that user s credentials are encrypted as they traverse the network. Table 21: Citrix StoreFront Configuration StoreFront Configuration. A single store will be created to provide the required access and enumeration of the HSD or HVD desktops. The StoreFront servers will be added into a single server group, providing additional capacity and increasing availability. A server Group provides a unified configuration and synchronisation of user settings. 34

36 Desktop Layer Design The desktop layer focuses on the design considerations for the user s desktop, which must provide them with the right set of applications, capabilities and resources based on their needs. Each of the virtual desktops within the Citrix Validated Solution represent true-to-production configuration consisting of a core set of applications that are pre-installed as part of the virtual desktop master image. Each of the virtual desktops, Windows 7, Windows 8.1 or Windows Server 2008 R2 Windows, Server 2012 R2 RDS workloads will be deployed using Citrix Machine Creation Services. Figure 19. Desktop Layer Design Components User Personalisation Providing the right level of personalisation requires an understanding of the needs for the user group. Personalisation decisions must be weighed against user location, data centre connectivity and security requirements. Utilising technologies like profiles and policies a user group can receive a desktop where userlevel personalisation changes are persisted between logins of the pooled desktops types that are described within this document. Citrix Profile Management will be leveraged and enabled through a Windows service that provides a mechanism for capturing and managing user personalisation settings within the virtual desktop environment. Citrix Profile Management is installed by default during the installation of the Virtual Desktop agent. 35

37 The key design decisions for Citrix Profile Management are as follows: Decision Point Description / Decision Version, Edition Citrix User Profile Management version 5.2 Storage Allocation Profile Storage Location 1 GB per User for Profile related data only Refer to the storage section for further details. Hosted Shared Desktop: User Profile Data: \\svm2\profiledata\hsd-upm Hosted Virtual Desktop: User Profile Data: \\svm2\profiledata\hvd-upm Refer to the Appendix for further information: DECISION POINT Folder redirection Storage Location Refer to the storage section for further details. Applied using Group Policy: (minimum requirements): Application Data Hosted Shared Desktop: User Data: \\svm2\profiledata\hsd-userdata Hosted Virtual Desktop: User Data: \\svm2\profiledata\hvd-userdata Refer to the Appendix for further information: DECISION POINT Table 22: Citrix Profile Management Key Decisions Citrix Profile Management together with standard Microsoft Windows Folder Redirection that leverages Active Directory GPOs will be deployed to support the user personalisation configuration requirements. Storage is presented by the NetApp FAS2552 Hybrid Storage Array using an SMB file share that provides the repository for user profile/personalisation data. Please refer to the Storage section for full details in regards to SMB version(s). 36

38 Applications The Citrix Validated Solution was tested utilising application sets representative of enterprise-level Standard Operating Environment ( SOE ) applications. These applications are pre-installed or embedded as part of the master image. Note a number of pre-requisite applications we re required to drive the Login VSI scalability testing. The following table represents the application set that formed the desktop workload profile: Hosted Shared Desktop Application Set Application HSD Operating System Citrix Applications Description / Decision Microsoft Windows Server 2008 R2 Standard Edition with SPK1 or Microsoft Windows Server 2012 R2 Standard Edition XenServer Virtual Machine Tools Citrix Virtual Delivery Agent Citrix Profile Management v5.2 Citrix ShareFile Desktop Widget v Citrix Receiver v Productivity Applications Microsoft Excel Professional 2010 x86 Microsoft Outlook Professional 2010 x86 Microsoft PowerPoint Professional 2010 x86 Microsoft Word Professional 2010 x86 Baseline Applications Adobe Acrobat Reader v Adobe Flash Player v Adobe Shockwave Player v Adobe AIR v Apple QuickTime v Doro PDF Printer v Cisco WebEx Connect v Google Chrome v Java 7 Update 13 v Mozilla Firefox v Microsoft.NET Microsoft Internet Explorer 9 Microsoft Silverlight v Microsoft Windows Media Player v12.x Skype v WinZip v Table 23: HSD Application Set 26 Application required and deployed by Login VSI for scalability testing. 27 Application required and deployed by Login VSI for scalability testing. 28 Application required and deployed by Login VSI for scalability testing. 29 Application required and deployed by Login VSI for scalability testing. 37

39 Hosted Virtual Desktop Application Set Application HVD Operating System Citrix Applications Description / Decision Microsoft Windows 7 Enterprise Service Pack 1 x64 or Microsoft Windows 8.1 Enterprise XenServer Virtual Machine Tools Citrix Virtual Delivery Agent Citrix Profile Management v5.2 Citrix ShareFile Desktop Widget v Citrix Receiver v Productivity Applications Microsoft Excel Professional 2010 x86 Microsoft Outlook Professional 2010 x86 Microsoft PowerPoint Professional 2010 x86 Microsoft Word Professional 2010 x86 Baseline Applications Adobe Acrobat Reader v Adobe Flash Player v Adobe Shockwave Player v Adobe AIR v Apple QuickTime v Doro PDF Printer v Cisco WebEx Connect v Google Chrome v Java 7 Update 13 v Mozilla Firefox v Microsoft.NET Microsoft Internet Explorer 9 Microsoft Silverlight v Microsoft Windows Media Player v12.x Skype v WinZip v Table 24: HVD Application Set 30 Application required and deployed by Login VSI for scalability testing. 31 Application required and deployed by Login VSI for scalability testing. 32 Application required and deployed by Login VSI for scalability testing. 33 Application required and deployed by Login VSI for scalability testing. 38

40 Master Image The master image is defined by an operating system, image size and a set of applications that are installed into that image that is representative of an ideal desktop workload. Configuration settings will be applied directly to the master image including Active Directory Group Policies where appropriate, ensuring consistent deployment and optimisation. Antivirus should be included with specific configurations as documented within this article 34 : Hosted Shared Desktop Workload Figure 20. HSD Workload Configuration Based on the system testing carried out, the following table describes the most optimal configuration for user/session density using; HSD on Windows Server 2008 R2 RDS workloads. Server Node User # of VMs per Node 35 RAM vcpu Sessions per VM Total # of Users per Node Shared Infrastructure & Desktop Node 5 18 GB 8 ~ Desktop Node 6 18 GB 8 ~ Table 25: Server 2008 R2 HSD Virtual Machine Specification and Sizing Estimates 34 Expect at least ~7% reduction in maximum host density numbers when including Antivirus in the workload image. The minimum overhead incurred by Microsoft System Center EndPoint Protection Anti-Virus during testing phases has consistently reduced density numbers by ~ 7%. 35 Expect per server maximum density numbers to reduce by 10% when running under full load. When the components of the solution e.g. Storage and 1GbE Network are under or close to full load this has a negative impact on the host server maximum density numbers. 39

41 Based on the system testing carried out, the following table describes the most optimal configuration for user/session density using; HSD on Windows Server 2012 R2 RDS workloads. Server Node User # of VMs per Node 36 RAM vcpu Sessions per VM Total # of Users per Node Shared Infrastructure & Desktop Node 5 18 GB 8 ~ Desktop Node 6 18 GB 8 ~ Table 26: Server 2012 R2 HSD Virtual Machine Specification and Sizing Estimates Virtual Machine Specifications Storage Pagefile Network Interface Memory Description / Decision System Drive: (Difference Disk) C:\ = 100GB Fixed 18GB (1 x Assigned Memory) Single - NIC for production traffic 18GB Dynamic Memory Range (DMR) not required vcpu 8 Operating System Microsoft Windows Server 2008 R2 Standard Edition with Service Pack 1, or Microsoft Windows Server 2012 R2 Standard Edition Table 27: HSD-Windows Server 2008 R2 & 2012 R2 RDS Virtual Machine Specification The table below describes the per user/desktop IO profile of the workloads as measured from the actual virtual machine: 37 Virtual Machine Operating System Microsoft Windows Server 2008 R2 Microsoft Windows Server 2012 R2 Logon Logoff Steady State 30 reads /10 writes 10 reads /30 writes 1 read / 2 writes 50 reads/ 25 writes 10 reads /30 writes 1 read / 2 writes Table 28: HSD-Windows Server 2008 R2 & 2012 R2 RDS VM I/0 Profile 36 Expect per server maximum density numbers to reduce by 10% when running under full load. When the components of the solution e.g. Storage and 1GbE Network are under or close to full load this has a negative impact on the host server maximum density numbers 37 The IO profile is described as seen from each virtual machine. These are instantaneous values, highly variable and do not necessarily reflect the true IO of the system. 40

42 Hosted Virtual Desktop Workload (Pooled) Figure 21. Hosted Virtual Desktop Workload Configuration (Pooled) Based on the system testing carried out, the following table describes the most optimal configuration for the Windows 7 workload for user/vm density: Server Node Shared Infrastructure & Desktop Node # of VMs per Node 38 RAM vcpu Total # of Users per Node GB 2 90 Desktop Node GB Table 29: Windows 7 HVD Virtual Machine Specification and Sizing Estimates Based on the system testing carried out, the following table describes the most optimal configuration for the Windows 8.1 workload for user/vm density: Server Node Shared Infrastructure & Desktop Node # of VMs per Node 39 RAM vcpu Total # of Users per Node GB 2 60 Desktop Node GB Table 30: Windows 8.1 HVD Virtual Machine Specification and Sizing Estimates 38 Expect per server maximum density numbers to reduce by 10% when running under full load. When the components of the solution e.g. Storage and 1GbE Network are under or close to full load this has a negative impact on the host server maximum density numbers 39 Expect per server maximum density numbers to reduce by 10% when running under full load. When the components of the solution e.g. Storage and 1GbE Network are under or close to full load this has a negative impact on the host server maximum density numbers 41

43 Virtual Machine Specifications Storage Pagefile Network Interface Memory Description / Decision System Drive: (Difference Disk) C:\ = 100GB 4GB (~1.5 x Assigned Memory) Single - NIC for production traffic 2.5GB Dynamic Memory Range enabled. Minimum Memory 2GB Maximum Memory 2.5GB Please refer to Guest VM details for further details vcpu 2 Operating System Microsoft Windows 7 Enterprise Service Pack 1 x64 Microsoft Windows 8.1 Enterprise x64 Table 31: HVD-Windows 7 and Windows 8.1 Virtual Machine Specification The table below describes the per user/desktop IO profile of the workload based on the actual virtual machine: 40 Virtual Machine Operating System Logon Logoff Steady State Microsoft Windows reads / 16 writes 65 reads / 40 writes 2 read / 3 writes Microsoft Windows reads / 20 writes 80 reads / 25 writes 2 read / 3 writes Table 32: HVD-Windows 7 & 8.1 VM I/0 Profile 40 The IO profile is described as seen from each virtual machine. These are instantaneous values, highly variable and do not necessarily reflect the true IO of the system. 42

44 Virtual Desktop Workloads The virtual workloads are deployed using Citrix Machine Creation Services (MCS). MCS utilises the hypervisor APIs to deploy, stop start and delete virtual machines. A master image must first be deployed that contains the virtual machine resource requirements such as vcpu and memory. Applications and agents are installed in the master image that is required for the virtual machine SOE deployment. Finally a snapshot is created within the hypervisor that will be used for the Catalogs base image deployment by MCS. A XenDesktop Catalog is deployed based on this master image snapshot, for each virtual machine created within this Catalog MCS will create the following virtual disks: Identity disk. An Identity disk which is used to provide each VM with a unique identity. Difference disk. A Difference disk which is used by each VM to store writes that are typically made to the system. Pooled stateless (non-persistent) desktops using MCS are unique in that the differencing disk is deleted and recreated at each boot cycle ensuring that the VM is set back to a clean state after each reboot, effectively deleting any newly written or modified data. In this scenario, certain processes are no longer efficient and optimisation of this image is required. Please refer to the section workload optimisations for further details. Boot Storm expectations and validation results During single server validation testing it was noted that a single Windows 7 HVD XenServer host was successfully able to boot ~15 VMs per minute with all VMs registered within XenDesktop after ~15 minutes. For system wide tests up to the maximum numbers of 1,000 for HVD all VMs were booted and registered within XenDesktop within ~25 minutes. Hosted Virtual Desktop Workload (Persistent) Figure 22. Hosted Virtual Desktop Workload Configuration (Persistent) Persistent state-full desktops using MCS by default retain their original differencing disk and the link to the original master image, changes made to this workload are retained after each reboot. Once the persistent desktop is deployed it must be managed by the customers existing Electronic Distribution Tools sets (ERD) such as SCCM, Altiris etc. Similarly the desktop also needs to be individually managed from that point onwards as a standalone entity unlike a pooled desktop described below. For the context of scalability numbers and I/O profile that is related to this CVS a persistent desktop will be considered the same as a pooled desktop type, with the exception that the storage footprint will grow over time. For further details on the persistent desktop storage allocation please refer to the Storage Design section. The virtual machine specifications below are for initial guidelines only. It is expected that customers requiring persistent desktop types are likely to require significant tailoring of the virtual desktop machine specifications. 43

45 Virtual Machine Specifications Storage Pagefile Network Interface Memory Description / Decision System Drive: (Difference Disk) C:\ = 100GB 4GB (~1.5 x Assigned Memory) Single - Synthetic NIC for production traffic 2.5GB Dynamic Memory Range. Minimum Memory 2GB Maximum Memory 2.5GB Please refer to Guest VM details for further details vcpu 2 Operating System Microsoft Windows 7 Enterprise Service Pack 1 x64 or Microsoft Windows 8.1 Enterprise x64 Table 33: HVD Persistent Virtual Machine Specification Workload Optimisations Optimisations and configurations can be applied at several levels: Workload Configuration master image. Changes are made directly to the master image. These changes are considered inappropriate to be applied using GPOs or are required settings prior to MCS generalising the image. The master image is then shut down and a snapshot taken by the hypervisor. MCS is then used to deploy the master image (from the snapshot) either to create a new or update an existing XenDesktop Catalog. Workload Configuration GPO. These changes are applied via Active Directory GPO and are considered baseline configurations required in almost all instances. Typical use cases for this GPO are Event log redirection, Citrix Profile Management configuration and target device optimisations. In addition this GPO may have Loopback processing enabled allowing user based settings to be applied at the virtual desktop Organisation Unit level. User Optimisations GPO. This Active Directory GPO contains optimisations for the user within the virtual desktop environment. User optimisations cannot typically be deployed as part of the master image and are considered independent. Typical use cases for this GPO are folder redirection and user specific optimisations. For details pertaining to the above optimisations please refer to the following links for further guidance: %20Windows%207%20Optimization%20Guide.pdf 44

46 Control Layer Design The control layer provides the design decisions for the underlying infrastructure supporting the virtual desktop layer. The Control Layer design is unique per data centre and subdivided into the following components: Infrastructure Desktop Delivery Controllers (XenDesktop) Image Controllers (Machine Creation Services) Access Controllers (StoreFront) Hypervisor Storage Network Figure 23. Control Layer Logical View 45

47 Infrastructure The infrastructure for this Citrix Validated Solution provides a set of common components, namely a database, license server, Active Directory and network components. File Services are covered in a separate section. Database Citrix XenDesktop requires databases to store configuration metadata and statistical information. A highly available database platform utilising Microsoft SQL Server is required as the database platform. The database platform must be designed in such a way as to provide adequate resources and availability to support the environment. SQL Version Redundancy Category Design Decision Microsoft SQL Server 2012 Standard Edition SP1 (used at the time of testing) Please refer to the following article for a list of Citrix supported database platforms: /Database%20Chart.pdf XenDesktop: Site database - Mirrored Logging database - Mirrored Monitoring database - Mirrored Please refer to the following article for database fault tolerance: Number of Servers 2 41 Server O/S CPU Allocation RAM Allocation Microsoft Windows Server 2012 R2 Standard Edition 2 vcpu (Example) 8GB (Example) Storage Allocation C:\ 100 D:\ 150 (Databases) (Example) Table 34: Database Summary This document provides sample sizing guidelines and the licensing requirements for the actual databases used in this Citrix Validated Solution, however does not attempt to provide design guidelines for Microsoft SQL Server. The design and implementation for a highly available Microsoft SQL Server platform is required although considered out of scope for this design document. 41 Assumes SQL Server is licensed as a 2 VCPU (v-cores) virtual machine with MS Software Assurance. SQL Server license requires minimum of 4 core licenses. Active-Passive SQL Server deployment means no additional licenses are required for secondary passive SQL Server. Refer to 46

48 Licensing The licensing component (Microsoft and Citrix) grants each user access to the environment, as long as enough licenses are available. In addition, the type of license can also grant/deny different levels of functionality. The key design decisions for the license server are as follows: Category Citrix Microsoft License Server Version DECISION POINT Redundancy Built in Grace period and Hypervisor DECISION POINT Number of Servers 1 DECISION POINT Server Name(s) DECISION POINT DECISION POINT Server O/S Microsoft Windows Server 2012 R2 Standard Edition DECISION POINT CPU Allocation 2 DECISION POINT RAM Allocation 4GB DECISION POINT Storage Allocation C:\ 100GB DECISION POINT License Type DECISION POINT DECISION POINT Table 35: Licensing Summary Redundancy. Redundancy is built into the Citrix License service via the built-in 30 day grace period. Service redundancy can be further facilitated by the underlying hypervisor; therefore a single server is recommended. Active Directory Integration. The License server computer object will be logical located in a dedicated Organisational Unit (OU) with specific Group Policy Objects applied as appropriate to the role please refer to the Active Directory Section for more details. 47

49 Active Directory This Citrix Validated Solution has a requirement to use Microsoft Active Directory Domain Services and as such, it is an assumption that such an environment already exists within the customer s environment. The decisions discussed below describe requirements from the existing Active Directory in the form of Organisational Units and Group Policy Objects. Supplementary requirements must also be met, to ensure sufficient capacity from authenticating Domain Controllers can handle any additional requirements or load placed on the system by adding further Users, Groups, machine Objects and policy processing load. DECISION POINT A CIFS server or machine object in Active Directory is necessary to provide SMB clients with access to the Storage Virtual Machine (SVM) hosted on the NetApp FAS2552 Hybrid Storage Array. The computer object(s) created during the setup procedure will reside in the File Servers OU A server or machine object in Active Directory is necessary to provide Active Directory user s role based management access to XenServer. Once added to Active directory the host servers should be added to an appropriate OU. Active Directory Users can then be assigned appropriate roles from within XenCenter. Category Group Policy Application Recommended: 42 Decision / Description Each infrastructure server role will have a minimum security baseline applied (MSB) via GPO All RDS workloads will have a minimum security baseline applied (MSB) via GPO Windows desktop workloads will have a minimum security baseline applied (MSB) via GPO RDS workloads will have a Machine GPO applied specific to their application delivery requirements. This GPO may have Loopback mode enabled to apply user based settings at the RDS workload OU level Windows desktop workloads will have a Machine GPO applied specific to their application delivery requirements. This GPO may have Loopback mode enabled to apply user based settings at the machine workload OU level User based policies may be applied at the user or machine level using the loopback mode Infrastructure servers such as web servers will be deployed in relevant OUs and MSBs applied appropriate to their role. Table 36: Active Directory Requirements 42 Reference to Minimum Security Baselines in the form of GPOs will be the customer s responsibility. GPOs described in this document in all cases will be integrated into the customer Active Directory environment. 48

50 The recommended Group Policy and Organisational Unit strategy applied to this Citrix Validated Solution is based on deploying Group Policy Objects in a functional approach, e.g. settings are applied based on service, security or other functional role criteria. This ensures that security settings targeted for specific role services such as IIS, SQL etc. receive only their relevant configurations. It is anticipated that the final design will be customer dependant and based on other factors such as role based administration and other typical elements outside the scope of this document. Refer to the Appendix: DECISION POINT Figure 24. Sample Active Directory OU Structure and GPO Linking 49

51 Delivery Controllers (XenDesktop) Delivery Controllers, also known as XenDesktop controllers (Image Controllers), are responsible for enumerating, allocating, assigning and maintaining virtualised desktops and applications. Delivery Controllers within a single data centre are grouped together into a XenDesktop site, which functions as a single administrative entity. This Citrix Validated Solution specifically defines the Hosted Virtual Desktop and Hosted Shared Desktop FlexCast delivery models. From a XenDesktop perspective each desktop type will belong to a Catalog configured specifically for that FlexCast delivery type and associated with storage; presented to the XenServer Resource Pool from the NetApp Hybrid storage array. The Illustration below identifies the components of the XenDesktop Site describing three XenDesktop Catalogs: Hosted Shared, Hosted Virtual (Pooled) and Hosted Virtual (Persistent). Figure 25. XenDesktop Site Component and Layer view 50

52 XenDesktop Site Based on the validation testing and resiliency requirements of this Citrix Validated Solution the following table describes the XenDesktop site design parameters. Category Design Decision Version, Edition Citrix XenDesktop 7.6 Sites per Data Centre Site Name(s) Server O/S Controllers per Site XenDesktop Administrators Site Database Configuration Database Monitoring Database Catalogs Delivery Groups Citrix Policies The Citrix Validated Solution is designed as a single Site for a single data centre DECISION POINT Microsoft Windows Server 2012 R2 Standard Edition 2 for redundancy (Single Site Deployment) Each Delivery Controller also functions as an MCS Image Controller DECISION POINT Refer to the Section Databases Refer to the Section Databases Refer to the Section Databases Catalog(s) will be created for each Desktop type and aligned with the NetApp FAS2552 Hybrid Storage Array FlexVol and Network VLANs presented by the XenServer Resource Pool For 1,000 HSD shared desktops: Example (Minimum requirement) Or: 2 Catalogs are required: o o o Catalog desktops and a single FAS2552 FlexVol Catalog desktops and a single FAS2552 FlexVol Associated Networks For 1,000 HVD Windows 7 desktops: Example (Minimum requirement) 2 Catalogs are required: o o o Catalog desktops and a single FAS2552 FlexVol Catalog desktops and a single FAS2552 FlexVol Associated Networks Example (Minimum requirement): A single Delivery Group will be created for each virtual desktop type. The Delivery Group can host desktops from multiple Catalogs of the same type Refer to the Appendix for further details Table 37: XenDesktop Site Summary 51

53 Category Hypervisor integration Host Connections Design Decision Directly to the XenServer Pool Master with connection HA enabled on other Hosts Example (Minimum requirement): A single Host Connection will be created to the XenServer Resource Pool Type: Citrix XenServer Name: <Based on Pool name storage and associated networks> Address: <FQDN of the XenServer Pool master> Table 38: XenDesktop Site Summary For XenDesktop Catalogs hosting server operating systems (also known as XenApp), users are load balanced based on resource availability at user logon. Load management includes Load Throttling, which ensures that a new server brought into service does not initially receive a disproportional number of connections. This Citrix Validated Solution recommends implementing a Custom load evaluator with the following minimum parameters: Load Evaluator Parameter Setting Applied To CPU Utilization 85% Full, 10% No load Custom Memory Usage 80% Full, 10% No load All servers Server User Load 30 Full Table 39: XenApp Load Evaluator Details XenDesktop Site. The XenDesktop site will consist of two virtualised Desktop Delivery Controllers. Each Delivery Controller virtual machine will always be separated on one of the two shared infrastructure/virtual desktop hypervisor hosts by defining a Home server. This will ensure resiliency of the environment. A host connection will be defined that establishes a connection to the XenServer Pool master and XenServer Resource Pool. Catalogs. For each virtual desktop type that is being deployed at least one Catalog will be created defining the Catalog Base image for the associated XenServer NFSv3 SR. The Catalog(s) may then be aggregated into a single unified Delivery Group for the presentation to users via StoreFront. The configuration limits for Citrix XenServer are a maximum of 600 VDIs per SR please refer to the configuration limits documentation: To maintain the desktops as described within a pod a minimum of two Catalogs will be deployed, maintaining the number of desktops associated with each XenServer SR within configuration limits. For maximum density of desktops and higher performance of the NetApp FAS2552 Hybrid Storage Array at least 2 Catalogs should be created for each pod with VMs distributed between them, each Catalog will be associated with a separate FlexVol and associated XenServer NFSv3 SR Within the host connection, a storage connection and network related resource will be specified for each Catalog e.g.: XenServer Pool name Storage (NFS Export associated with the FlexVol) HVD-VLAN_1 and HVD-VLAN_2 52

54 The illustration below describes an example Catalog distribution across the host connection Figure 26. XenDesktop Conceptual Catalog Host Connection Desktop Presentation. From the corporate LAN/WAN, StoreFront will be utilised for the presentation of desktops to end users. Desktop Director and EdgeSight. Citrix EdgeSight is now integrated into a single console within Desktop Director, with its feature set enabled based on Citrix Licensing. The monitoring database used by EdgeSight will be separated from the site and logging database to allow appropriate management and scalability of the databases. Historical data retention is available for 90 days by default with platinum licensing. Administrators can select specific views delegating permissions concisely for helpdesk staff, allowing easy troubleshooting and faster resolution of problems. Citrix EdgeSight will provide the following key components: Performance Management. EdgeSight provides the historical retention with reporting capabilities. Real Time. Director provides the real time views for support staff to further investigate reported problems. Active Directory Integration. Each computer object will be logical located in a dedicated Organisational Unit with specific Group Policy Objects applied as appropriate to the role please refer to the Active Directory Section for more details. 53

55 Image Controllers (Machine Creation Services) Image Controllers are responsible for providing the actual desktop image for Pooled desktops. Pooled desktop images are created with the built-in Citrix Machine Creation Services (MCS) functionality on each Desktop Controller. MCS is a collection of services that work together to create virtual servers and desktops from a master image on demand, optimising storage utilisation and providing a pristine virtual machine to users of pooled or shared desktop types every time they log on. Machine Creation Services is fully integrated and administered in Citrix Studio not requiring additional servers. There are virtually no moving parts within MCS, as all operations are executed directly from the Citrix Delivery Controllers. Each pooled desktop has one difference disk and one identity disk. The difference disk is used to capture any changes made to the master image while the identity disk stores machine identification information. The key design decisions for the Image (Desktop Delivery) controllers are as follows: Category Preferred Imaging Solution Machine Creation Services Description MCS Storage Type Server Names Server O/S CPU Allocation RAM Allocation Storage Allocation NFSv3 File based Storage, provided by the NetApp FAS2552 Hybrid Storage Array Desktop Delivery Controllers DECISION POINT Microsoft Windows Server 2012 R2 Standard Edition 2 vcpu 8GB C:\ 100GB Table 40: Image Controllers Key Decisions 54

56 Access Controllers (StoreFront) Access Controllers are responsible for user authentication and connectivity to the environment. They provide the framework allowing users to access the environment from any device and any location. All users, regardless of being internal or external will need to gain access to a list of their virtualised resources via StoreFront. The key design decisions for StoreFront controllers are as follows: Server O/S Category Design Decision Microsoft Windows Server 2012 R2 Standard Edition Servers per Site 2 Server Name(s) CPU Allocation RAM Allocation Storage Allocation Access Method Load Balancing DECISION POINT 2 vcpu 4 GB C:\ 100GB Internal DNS Round Robin (Recommendation: Citrix NetScaler) Table 41: StoreFront Site Summary Two virtualised StoreFront servers will be deployed. Each StoreFront virtual machine will always be separated on one of the two shared infrastructure/virtual desktop hypervisor hosts by defining a Home server. This will ensure resiliency of the environment. The Citrix StoreFront servers may be load balanced using DNS round-robin. Optionally, Citrix StoreFront servers may be load balanced using Citrix NetScaler appliances configured in high availability mode (HA). Citrix specific service monitors can then be utilised to monitor the health of the StoreFront services to ensure intelligent load balancing decisions are performed increasing service availability. Active Directory Integration. Each Machine object will be logical located in a dedicated Organisational Unit with specific Group Policy Objects applied as appropriate to the role please refer to the Active Directory Section for more details. 55

57 Hypervisor Citrix XenServer 6.5 will be deployed to each Cisco C240 M3 SFF server. All servers will be configured into a single XenServer Resource Pool. XenServer will provide the hypervisor hosting platform to the virtualised desktop and infrastructure server instances. Citrix XenCenter will be deployed to a management server providing the management interface to the XenServer hosts. Storage Repositories (SRs) will be configured at the Resource Pool level for NFSv3 over TCP and SMB protocols for file services presented form the NetApp FAS2552 Hybrid Storage array. XenServer Overview The Illustration below depicts the physical components logically connected between a single Cisco C240 M3 SFF Server, the hypervisor, storage and associated switching infrastructure: Network. 4 x 1 Gbps On-board Ethernet Adapter. Management. 1 x 1 Gbps On-board Management Adapter for CIMC (Cisco Integrated Management Controller). Network Bonding. 2 x Network Bonds each consisting of 2 x Physical Network adapters (Interface). o Bond 0+1. Management and VM Data traffic (Interface 0 + Interface 1). o Bond 2+3. Dedicated to storage traffic (Interface 2 + Interface 3). XenServer Host HSD Figure 27. HSD XenServer Host Logical View 56

58 XenServer Host HVD XenServer Hardware Details Figure 28. HVD XenServer Host Logical View Hardware Category Decision / Description Refer to the section: Cisco C240 M3 SFF Rack Mounted Server(s) Table 42: XenServer Hardware Details 57

59 XenServer General Details Resource Pool. A single XenServer Resource Pool will be deployed and shared for both the infrastructure VMs and the desktop VMs. A XenServer Home server can be defined to ensure the redundant infrastructure VMs do not reside on the same hosts. XenServer In-Memory Storage Read Caching. XenServer Storage Read Caching (Read Caching) is enabled by default with the appropriate XenServer license offering significant advantages in performance by reducing read storage IO and storage network traffic. Reading data from the Read Cache has a much lower latency than reading directly from the disk bound NFS SR. Read Caching uses a host s free memory to perform the read caching functions. Read Caching is only available with the following XenServer licensed editions: XenServer Enterprise XenDesktop Platinum Read Caching provides benefits that are typically seen with XenDesktop Machine Creation Services (VM workload provisioning), where a single master image is used to deploy many instances (clones). In this scenario Read Caching will cache data read from the master image onto the XenServer host s memory. As each virtual machine requests data from the master image it can be read from the Read Cache provided it s been cached, rather than requesting it directly from the shared storage. For full details of XenServer Storage Read Caching please refer to the references in the Appendices. Control Domain. XenServer now uses a 64-bit Control Domain (dom0) allowing large memory values to be specified increasing the Read Caching capabilities. Dom0 memory should be monitored when multiple master images are being used by MCS. Increasing the default memory size for dom0 from 4 GB to 8 GB will allow multiple images to be cached by the XenServer Read Cache feature. If dom0 free memory is low Read Caching could be reduced increasing storage read operations. Please refer to the following documents for further reference: System Administrators guide: o A maximum of 500 desktops will be configured on any single XenServer SR, o Refer to the XenDesktop section for further details. Increasing dom0 memory: o Category Decision / Description XenServer 2 x 300 GB Drives configured as a RAID 1 for XenServer installation Version XenServer 6.5 o Enterprise Edition 43 or XenDesktop Platinum Edition Patches (At the time of writing): o XS65E001 & XS65E002 Resource Pool High Availability, not configured (optionally this can be enabled with 3 or 43 During the testing, XenDesktop Platinum was used to enable XenServer Read Caching feature. Citrix XenServer Enterprise License or XenDesktop Platinum License is required. 58

60 more hosts in the pool) Workload Balancing, not configured 44 Host Configuration Bios Storage Settings Recommendation: Increase dom0 memory to 8 GB, this will allow additional images to be cached by the storage Read Caching feature of XenServer 6.5 Example: /opt/xensource/libexec/xen-cmdline --set-xen dom0_mem=8192m,max:8192m For full details of the host BIOS settings please refer to the following: Appendix I NFSv3 over TCP presented from the NetApp FAS2552 Hybrid Storage Array Name, Description and Path: FAS2552-NFS-vdi01 SR used for VM data up to 500 desktops <IPAddress:/vdi01> Name, Description and Path: FAS2552-NFS-vdi02 SR used for VM data up to 500 desktops <IPAddress:/vdi02> Name, Description and Path: FAS2552-NFS-infra-01 SR used for Infrastructure VM data <IPAddress:/infra01> CIFS/SMB presented from the NetApp FAS2552 Hybrid Storage Array Name, Description and Path: CIFS ISO Library SR used as the ISO repository \\<svm-name.fqdn>\media Table 43: XenServer General Details 44 Citrix Workload Balancing was out of scope and not tested during the validation phases. 59

61 XenServer Network Details Network. XenServer will be configured with two Network Bonds to aggregate the 4 physical network adapters presented to each host server. Each network Bond will have 2 physical network adapters, each connected to separate physical network switches (Switch Stack). Each Bond will be configured as an LACP 45 channel to support redundancy and where appropriate aggregation of the traffic types. Each Bond will be configured as follows: Bond 0+1. This Bond will be used for VM Data traffic and hypervisor management. o o o o XenServer Management IP addressing will be configured directly on this Bond interface. XenServer networks used for VM traffic will be created with the vlan ID specified and associated with this Bond The switch port configuration will be trunked defining the VM networks with the native VLAN set to the management VLAN and an appropriate IP address defined. This network Bond will be configured as LACP with load balancing based on source MAC address. This configuration will not load balance management traffic however will distribute VM data across both the physical adapters based on source MAC address. Bond 2+3. This Bond will be used for NFSv3 storage traffic only: o o o The switch port configuration can be configured as an access port or alternatively trunked with the native vlan defined as the storage vlan. This network Bond will be configured as LACP with load balancing based on IP and Port. A separate IP Address is required for the storage network, however these networks will not require a default gateway and will remain non-routable. These interfaces will have Jumbo frames enabled increasing the payload of Ethernet frames for storage traffic. Category Physical Network Adaptors (interface) Network Settings Networks Cisco UCS C240 M3 SFF Server: Decision / Description 4 x 1 Gb Adapters (interface 0 + interface 1 + interface 2 + interface 3) 1 x 1 Gb (CIMC) Adapter (Lights out management) Network Bond 0+1: (vswitch): VM Networks (Trunked VLANs) Management Network (Native VLAN) Bond type (Used in testing LACP with load balancing based on source MAC address) Network Bond 2+3: Storage Network (Native VLAN, Layer 2 only) Bond type (Used in testing LACP with load balancing based on IP Port of source and destination with Jumbo Frames enabled) Bond 0+1: Management (<IPAddress>) 45 LACP was the Bonding mode used during validation testing, however other modes of Bonding, Active/Active or Active/Passive can also be utilised with the appropriate switch configurations. 60

62 Category Decision / Description Vlan-<VDI01> vlanid <xxx> Vlan-<VDI02> vlanid <xxx> Vlan-<VDI-n> vlanid <xxx> Vlan-<Infrastructure> vlanid <xxx> Bond 2+3 Storage 1 (<IPAddress>) Table 44: XenServer Network Details Class of Services (CoS) and Quality of Service (QoS) switch recommendations. It is a recommendation that CoS and QoS are configured for the differing traffic types at the switch layer to ensure each network has sufficient bandwidth and correct priorities for the traffic types under heavy load conditions. XenServer Guest Virtual Machine Details Category XenServer Tools Version (at the time of writing): Decision / Description Dynamic Memory Range (DMR): Configured on each VM Guest type where indicated throughout the design: Minimum Memory: Value should be indicative of the expected working load of the guest to avoid excessive paging Dynamic Memory Control & Dynamic Memory Range Maximum Memory: Maximum as defined for the guest workload Note: Based on the parameters in this document DMR will only require minimal memory reclamation at full load. If DMR is heavily utilised the boot storm of the workloads will likely be increased due to Dynamic Memory Control (DMC) reclaiming memory from the running VMs defined allocation ranges. (XenServer defines the maximum amount of Memory to a VM if it is available at boot time by the host and must reclaim this memory during the boot phase) XenServer Supported Minimum Memory DMR for the workloads If VM memory is configured differently for the workloads as defined in this document please refer to the following document for supported configurations: /XenServer-6.5.0_VM%20User%EF%BF%BDs%20Guide.pdf Table 45: Virtual Machine Guest Details 61

63 Storage Technology Overview This section provides an overview of the NetApp technology, storage design, the aggregate and volume layout and the Storage Virtual Machine design. NetApp FAS Technology Overview NetApp FAS systems are enterprise-class storage systems which deliver the availability, scalability, performance, and flexibility to drive the most demanding SAN and NAS workloads. The FAS family combined with the NetApp clustered Data ONTAP 8 operating system eliminates disruptions to client operations. The feature-rich platform follows a common set of guiding principles; Nondisruptive Operations: Storage maintenance, hardware lifecycle operations, and software upgrades can be performed without interruption. Planned and unplanned downtime can be eliminated for continuous business availability. Proven Efficiency: Allows consolidation and sharing of the same infrastructure for workloads or tenants with different performance, capacity, and security requirements saves time and money. Seamless Scalability: Capacity, performance, and operations can be scaled without compromise, encompassing multiple media types, unifying SAN and NAS protocols. Clustered Data ONTAP A key differentiator in a clustered Data ONTAP environment is that High-availability (HA) pairs of storage controllers are combined into a cluster to form a shared pool of physical resources that are available to applications, SAN hosts, and NAS clients. The shared pool appears as a single system image for management purposes. This means that there is a single common point of management, whether through the graphical user interface (GUI) or command-line interface tools, for the entire storage cluster. Figure 29. Clustered Data ONTAP product overview Clustered Data ONTAP allows for the transparent movement of data and network connections anywhere within the storage cluster. The capability to move individual data volumes or LUNs, 62

64 known as NetApp DataMotion allows the redistribution across a cluster at any time and for any reason. DataMotion is transparent and non-disruptive to NAS and SAN hosts, and it enables the storage infrastructure to continue to serve data throughout these changes. To improve data access in NAS applications, NetApp virtualizes storage at the file-system level. This enables all client nodes to mount a single file system, access all stored data, and automatically accommodate physical storage changes that are fully transparent to the clients. Each client or server can access a huge pool of data residing across the clustered Data ONTAP system through a single mount point. With clustered Data ONTAP, each storage controller is referred to as a cluster node. Nodes are allowed to be different FAS models and sizes. Disks are grouped into aggregates, which are groups of disks of a particular type that are composed of one or more RAID groups protected by using NetApp RAID DP technology. Multiprotocol Unified Architecture A multiprotocol unified architecture provides the capability to support several data access protocols concurrently in the same overall storage system over a whole range of controller and disk storage types. Clustered Data ONTAP supports a full range of data access protocols concurrently. The supported protocols include: SMB 1.0, 2.0, 2.1 SMB 3.0 including support for non-disruptive failover in Microsoft Hyper-V environments (clustered Data ONTAP 8.2) and Microsoft SQL Server (clustered Data ONTAP 8.2.1) NFSv3, NFS v4, and NFSv4.1 including pnfs iscsi Fibre Channel FCoE Data replication and storage efficiency features are seamlessly supported across all protocols in clustered Data ONTAP. Figure 30. Multiprotocol Unified Architecture Overview 63

65 SAN Data Services With the supported SAN protocols (that is, Fibre Channel, FCoE, and iscsi), clustered Data ONTAP provides LUN services. This is the capability to create LUNs and make them available to attached hosts. Because the cluster consists of numerous controllers, there are several logical paths to any individual LUN. A best practice is to configure at least one path per node in the cluster. Asymmetric Logical Unit Access is used on the hosts so that the optimized path to a LUN is selected and made active for data transfer. Support for multipath I/O is also available from leading OS and third-party driver vendors. NAS Data Services Clustered Data ONTAP can provide a single namespace with the supported NAS protocols such as SMB (CIFS) and NFS (NAS clients can access a very large data container by using a single NFS mount point or CIFS share). Each client, therefore, needs only to mount a single NFS file system mount point or access a single CIFS share, requiring only the standard NFS and CIFS client code for each operating system. The namespace of clustered Data ONTAP is composed of potentially thousands of volumes joined together by the cluster administrator. To the NAS clients, each volume appears as a folder or subdirectory, nested off the root of the NFS file system mount point or CIFS share. Volumes can be added at any time and are immediately available to the clients, with no remount required for visibility to the new storage. The clients have no awareness that they are crossing volume boundaries as they move about in the file system, because the underlying structure is completely transparent. Data ONTAP can be architected to provide a single namespace, yet it also supports the concept of several securely partitioned namespaces, called Storage Virtual Machines or SVMs. This accommodates the requirement for multi-tenancy or isolation of particular sets of clients or applications. The illustration below shows a single SVM in a two-node cluster providing data services to SAN hosts and NAS clients. Figure 31. SVM Overview By virtualizing physical resources into the SVM construct, clustered Data ONTAP implements multi-tenancy and scale-out, allowing the cluster to host isolated independent workloads and applications. 64

66 Logical Interface (LIF) Overview A LIF (logical interface) is an IP address with associated characteristics, such as a role, a home port, a home node, a routing group, a list of ports to fail over to, and a firewall policy. You can configure LIFs on ports over which the cluster sends and receives communications over the network. LIFs can be hosted on the following ports: Physical ports that are not part of interface groups Interface groups VLANs Physical ports or interface groups that host VLANs LIF failover refers to the automatic migration of a LIF in response to a link failure on the LIF's current network port. When such a failure is detected, the LIF is migrated to a different physical port. A failover group contains a set of network ports (physical, VLANs, and interface groups) on one or more nodes. A LIF can subscribe to a failover group. The network ports that are present in the failover group define the failover targets for the LIF. Figure 32. Clustered Data ONTAP Networking Logical Architecture Flash Pool Overview Flash Pool enables faster workloads for both reads and writes by shifting operations to SSD from traditional HDD. Shared storage infrastructures experience dynamic changes in workload as they respond to the demands of multiple hosted applications. Flash Pool reacts in real time to these urgent changes, unlike traditional automated tiering solutions that wait for subsequent data movement windows. Flash Pool enables faster workloads for both reads and writes by shifting operations to SSD from traditional HDD. 65

67 Figure 33. Flash Pool Technology Overview 66