Horizon DaaS Platform 7.0 Service Provider Administration

Transcription

1 Horizon DaaS Platform 7.0 Service Provider Administration March 2017

2 2017 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 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. VMware, Inc Hillview Ave. Palo Alto, CA ii

3 Contents 1 Upgrading to Horizon DaaS Platform IMPORTANT: Snapshot Required Prior to Upgrade Pre-Upgrade Tasks Confirm that System is Ready for Upgrade Verify Port Availability Create Snapshot of All Service Provider Appliances Increase CPU Count and RAM Size for Service Provider Appliances Obtain the Upgrade Files Upgrade Appliances to DaaS Platform Upgrade Primary Service Provider Appliance Upgrade Org1000 Appliances Upgrade All Other Appliances Check Desktop Functionality Update DaaS Agent Snapshots and Rollback Rescheduling the Snapshot Deletion Snapshot 7 2 System Blueprint Introduction Intended Audience Organization of this Section Terms Platform Overview Key Components of the Horizon DaaS Platform Horizon DaaS Management Appliances Management Appliance High Availablity Network Services Agent Compatibility Compute Resources Hardware Requirements for Horizon DaaS Management Hosts Horizon DaaS Appliance Sizing Requirements Sizing a Management Host for a Specific Number of Tenants Hardware Requirements for Virtual Desktop Hosts Sizing a Desktop Host for a Specific Number of Desktops Host Sizing Calculations CPU Speed Considerations Network Resources Virtual LANs in the Horizon DaaS Platform Distributed Virtual Networking Layer 2 segregation using VLANs Layer 3 segregation using VRFs Networking Resources Switches Routers Load Balancing Gateways Cross Data Center HA Managing External IPs and global DNS entries Wiring the Data Center Storage Resources Storage Options SAN Storage NFS Storage Tenant Data Storage 23 iii

4 2.6 Networking between Data Centers Traffic between Data Centers Sample Deployment Horizon DaaS Management Appliances Required for Tenant A Horizon DaaS Management Appliances Required for Tenant B Desktop Host Requirements for Tenant A and Tenant B Additional Data Centers and Tenant C Storage: Three Tenants in Two Data Centers Planning a Production Environment Data Protection Horizon DaaS Appliance Backup Desktop Backup User Data Backup / Replication Security Platform Security Appliance Services DaaS Agent Services Security Best Practices Unique DNS Record for Each Portal Role Separation and Administration Service Center Administration console Desktop Portal NetApp Information Best Practices Configuring Your vfiler Desktop DR Deployment Strategies Cisco Virtualized Multi-Tenant Data Center (VMDC) VMDC 2.2 Solution Components Suggested components for trial and POC environments 35 Platform Install Checklist Install Using vcenter 36 Service Provider Installation Worksheet 37 Tenant 1 Installation Worksheet 39 Tenant 2 Installation Worksheet 40 3 Tenant Installation vcenter Overview Tenant Installation Prerequisites Discovery and Assignment (Optional) Configure NetApp VSC Plug-in Enterprise Network Connectivity Tenant Network Configuration DNS Configuration Allocate Tenant IP Addresses Define or install DHCP service for the tenant Active Directory Configuration SSL Certificate About File Shares Tenant Installation Overview Create Tenant Appliances Add Desktop Compute Resources (Optional) Configuring the Netapp VSC Plug-in Assign Resources to Tenant Assign Networks to Desktop Manager(s) Configure Datastores Assign Desktop Model Quotas Assign Protocol Quotas 48 iv

5 Set Up Desktop Connection Via Access Point Enter the Tenant s AD Information Apply Tenant Certificates to Tenant Appliances Generate Tenant Certificates Apply Tenant Certificates Extending a Tenant Across Datacenters Adding a Network Component Adding Appliances Creating a Windows 7 Gold Template 54 Tenant Installation Worksheet 56 4 Service Provider Installation vcenter Overview Service Provider Prerequisites Required Files Bootstrap Primary Service Provider (SP1) Appliance Prepare Storage Configuration on Both Management Hosts Deploy the DaaS OVA File Run the Bootstrap Script to Configure Network on SP1 Appliance Copy the DaaS Software to the Service Provider Appliance Run bootstrap Script to Install the DaaS Software Configure Service Center Start the Service Center Register the Service Provider Domain Discover the DaaS Management Server (Optional) Rename Resource Manager (Optional) Turn off Local Disk Provisioning (Optional) Configuring the Netapp VSC Plugin Create the Remaining Service Provider Appliances Create HA Service Provider (SP2) Appliance Apply Service Provider Certificate Files to Service Provider Appliances Add Tenant Resource Manager Create a Tenant Resource Manager Appliance (Optional) Give the Tenant Resource Manager a Friendly Name (Optional) Configuring Netapp VSC plugin for Tenants Define Desktop Models Installing Multiple DaaS Datacenters Prepare Storage Configuration on Both Management Hosts Deploy OVA File Run the Bootstrap Script Rerun the Bootstrap Script Start the Service Center and Discover Management Host Complete the Datacenter Build Out 75 5 Access Point Setup Overview High-Level Architecture Basic Functionality Access Point vs. dtram Performance Set Up Access Point Example of Load Balancer Configuration 81 6 HTML Access (Blast) Setup Overview About Desktop Protocols About HTML Access (Blast) 84 v

6 6.1.3 System Requirements HTML Access (Blast) Support for RDSH Applications Setup Procedure Install Correct Browser Prepare Desktops to Support Protocol Install DaaS Agent Install Horizon Agent Install on Desktop (Windows 7, Windows 8, Windows 8.1) Install on Windows Server 2008 R2 or 2012 R2 as Personal Desktop (Non-RDSH) Install on Windows Server 2008R2/2012 as RDSH Role Add the HTML Access (Blast) Group Policy Settings to the Local Computer Policy Environment Automate SSL Installation Import Certificate and Record Certificate Thumbprint Create Post Sysprep Script/Batch File on Gold Pattern Image and Copy Certificate Windows 7 and Later Windows XP Convert Image to Gold Pattern or Reseal Troubleshoot Connection Problems Known Limitations and Workarounds 91 7 Tenant Customization Custom Branding Configure NetApp Storage Summary Hardware and Software Requirements NFS Exports Local Mount Point Structure Permissions and Security Add a New NetApp Service Account Super Tenant Overview Super Tenant Prerequisites Networking Requirements Tenant Active Directory and DNS Configuration Tenant DHCP Configuration Gold Pattern and DaaS Agent Gold Pattern DaaS Agent Tenant Infrastructure Overview Diagram Service Center Create a Super Tenant Enable an Existing Tenant as a Super Tenant Add Networks for a Super Tenant Disabling the Super Tenant Option Billing Reports Billing Summary Reports Overview Override Report Intervals Description of Record Layout System Maintenance Backing Up and Restoring Databases Back Up a Database Restore a Database 104 vi

7 9.2 Changing Passwords Change PSQL Password Change Appliance Password Slony Reinitialization Database Failover Overview Enable Write Operations on the Secondary Database Promote the Secondary Appliance to Primary Appliance Datacenters Failover Master Failback a Datacenter Rename a Datacenter Overview Edit final_config.txt Rerun bootstrap.sh Decommision a Datacenter Execute Initial Shutdown Steps Perform Initial Tenant Maintenance Promote the Primary Service Provider and Tenant to be the Primary Across Datacenters Perform Initial Service Provider Maintenance on Remaining Datacenter Clean Up Proxychains Configuration Clean Up FDB Re-initialize Slony on Affected Nodes Bring the System Up Final Tasks Monitoring Introduction Critical Nodes Basic System Functions Web Application Monitoring Port Response Monitoring CIM Classes CIM Providers on DaaS Management Nodes Operating Environment CIM Providers for DaaS Nodes Linux_OperatingSystem Linux_EthernetPort Linux_ComputerSystem CIM_FileSystem Application-Specific CIM Providers for DaaS Management Appliances Service Provider Appliances Resource Manager Appliances Tenant Appliances Desktop Manager Appliances Description of DaaS CIM Providers Desktone_ActiveDirectoryStatus Desktone_ApplicationServer Desktone_ApplicationServerStatistics Desktone_CommonDatabase Desktone_DatabaseService Desktone_DatabaseReplicationService Desktone_HypervisorManagerStatus Desktone_InstalledProduct Desktone_NTPService Desktone_XMPService WBEM and CIM Connecting to the WBEM/CIM Server of a DaaS Management Appliance Using WBEM/CIM to Monitor ESX Hosts 126 vii

8 Appendix A Connection Matrix 129 Appendix B Guest OS Support 136 viii

9 Upgrading to Horizon DaaS Platform Upgrading to Horizon DaaS Platform IMPORTANT: Snapshot Required Prior to Upgrade Before you begin the upgrade procedure, you must take a snapshot of all service provider appliances. This is required to protect system data in case you encounter issues during upgrade. See Create Snapshot of All Service Provider Appliances below for more information. 1.1 Pre-Upgrade Tasks Confirm that System is Ready for Upgrade All appliances across all datacenters must be at version To verify the version of your appliances, log in to the Service Center and select appliances > browse appliances. The version number is displayed in the Version column of the table. All appliances across all datacenters must be up and running. The Virtual Center server must have proper valid certificates. CN of the certificate must match with the hostname. SSL certificate must have Virtual Center IP addresses in the DNS entry (if it is being accessed by IP address). All appliances across datacenters must be synchronized with the NTP server. There should not be any time differences between appliances. Administrator group should not be part of any Organization Unit in the domain. All appliances should be recognized by FQDN. All appliances across datacenters should be accessible over ssh (as desktone and as root) without password from primary Service Provider appliance of that Datacenter. If this is not true, contact VMware support for the workaround/resolution. Note: DO NOT use the floating IP address when executing SSH commands. Instead, go directly to the SP1 appliance. The Service Provider appliance password must not have been changed after the bootstrap process. The SHA2 certificates generation process during the upgrade will not work if the password has been changed post-bootstrap. Contact VMware support for the workaround/resolution in such case. 1

10 Upgrading to Horizon DaaS Platform All active reservations must have been completed successfully. To verify whether there is any reservation with 'unknown' state in the reservation section of Service Center portal, execute the following sql statements on the master service provider appliance fdb database only. update reservation set life_state = 'completed' where life_state = 'started' ; Before executing the upgrade, query for reservations and confirm that the reservations are not valid ones. Confirm that there are no scheduled or active reservations before starting the upgrade process Verify Port Availability All appliances now use port 8443 to communicate with each other, and the DaaS Agent also uses port 8443 to communicate with the appliances. You must confirm that port 8443 is open, and may also need to open an additional firewall port to allow traffic using port In addition to port 8443, confirm that the following ports are open. Appliance(s) Inbound/Outbound Port Description Tenant Inbound TCP 3443 Tenant Inbound TCP 4001 Listens on localhost only for messages from Desktop Managers. Tenant Inbound TCP 6443 Tenant Outbound AD servers: TCP 3268/3269 Global catalog port on AD servers for LDAP/LDAPS (respectively). Tenant Outbound AD servers: TCP 88 Kerberos (for new, more secure LDAP communication & password change functionality) Tenant Outbound TCP 6443 Desktop Manager Desktop Manager Desktop Manager Desktop Manager Desktop Manager Desktop Manager Resource Manager Inbound TCP 3443 Inbound TCP 4002 Handles connections from agents. When agents startup they connect to the message bus on this port on one of the Desktop Managers so that they can receive messages from them. Inbound TCP 4101 Used for router clustering. JMS routers on HA pairs connect to each other on this port so that they can route messages between Desktop Managers and ensure messages reach the agent, regardless of which Desktop Manager the agent is connected to. Inbound TCP 6443 Outbound TCP 4101 Used for router clustering. JMS routers on HA pairs connect to each other on this port so that they can route messages between Desktop Managers and ensure messages reach the agent, regardless of which Desktop Manager the agent is connected to. Outbound TCP 6443 Inbound TCP

11 Upgrading to Horizon DaaS Platform Refer the following lists of commands to open inbound and outbound ports. Commands to execute in tenant and desktop manager appliances across datacenters: iptables -A INPUT -p tcp --dport j ACCEPT iptables -A INPUT -p tcp --dport j ACCEPT iptables -A INPUT -p tcp --dport j ACCEPT iptables -A INPUT -p tcp --dport j ACCEPT iptables -A OUTPUT -p tcp --dport j ACCEPT Commands to execute in resource manager appliances across datacenters: iptables -A INPUT -p tcp --dport j ACCEPT iptables -A OUTPUT -p tcp --dport j ACCEPT Create Snapshot of All Service Provider Appliances During upgrade, the DaaS platform automatically creates a snapshot of all existing Tenants and Resource Managers, but does not create snapshots of Service Providers. Before starting the upgrade, you must create manual snapshots of all Service Provider appliances. Procedure 1. Shut down all Service Provider appliances, making sure you shut down the primary Service Provider appliance last. 2. Using the VMware vsphere Client, create a snapshot of all Service Provider appliances. 3. Beginning with the primary Service Provider appliance, power up all Service Provider appliances. 4. Wait until all appliances are online before proceeding with the upgrade. To check the status in the Service Center, select appliances > browse appliances. The appliance is online if the status line contains the green arrow icon Increase CPU Count and RAM Size for Service Provider Appliances To increase CPU count and RAM size, perform the following steps for each Service Provider appliance. Procedure 1. In the vcenter interface, right-click the Service Provider VM. 2. Select Edit Settings. 3. Increase the CPUs count to Increase the RAM (Memory) to 4096 MB. 5. Click OK to save the settings Obtain the Upgrade Files Procedure 1. Log in to the primary Service Provider appliance and run all commands as root: sudo i 2. Verify that the upgrade directory exists and is empty: rm rf /usr/local/desktone/upgrade mkdir /usr/local/desktone/upgrade 3

12 Upgrading to Horizon DaaS Platform Verify that the /data/tmp directory exists and is empty: rm rf /data/tmp mkdir /data/tmp 4. Copy the upgrade package (upgrade7.0.0.tgz) to the /data/tmp directory on the primary Service Provider appliance. 5. Verify the package s integrity by computing sha256sum and comparing it with the expected value of 7ae1781a40c6f1e5bc89694a ea7076faa125b219141ee0158dfe": sha256sum /data/tmp/upgrade7.0.0.tgz The output should appear exactly as below: 7ae1781a40c6f1e5bc89694a ea7076faa125b219141ee0158dfe upgrade7.0.0.tgz 6. Untar the upgrade package in the /data/tmp directory: cd /data/tmp tar --no-same-owner xzvf./upgrade7.0.0.tgz 7. On SP1 of the primary datacenter only, run./preupgradetask sh with no argument. This script run permanently changes the APT repo cache directory to /data/apt and also fixes a bug to allow any debian package to be downloaded from the APT repo and provides other fixes. Note: This script run attempts to restart dtservice on all non-local SP appliances across DCs. If for some environmental reason it fails to stop dtservice, please manually stop dtservice and rerun this script. Note: This script is idempotent so it can be run multiple times if necessary. Important: You must wait up to three minutes for the changes introduced by the preupgradetask to complete before proceeding to the next steps. 8. On SP1 of each datacenter, run the following: preupgradetask sh checkspace This will check that the necessary space is available on each appliance and inform you if it is not. The install requires approximately 1.4 GB in /usr and 150 MB in /var. 9. Download the following debian files to the /data/tmp directory on the primary Service Provider appliance. dt-platform-7_0_0.deb dt-aux-7_0_0.deb To avoid errors due to space limitations, download the debian files only after running the preupgradetask script. 10. Move the debian files to /data/repo/ : mv /data/tmp/*.deb /data/repo/ 11. Delete the upgrade tarball and move the rest of the files to /usr/local/desktone/upgrade rm f /data/tmp/*.tgz mv /data/tmp/* /usr/local/desktone/upgrade The /usr/local/desktone/upgrade directory size must not exceed 2 MB. To verify directory size, execute the following command. du -sh /usr/local/desktone/upgrade 4

13 Upgrading to Horizon DaaS Platform If the directory size exceed 2 MB, delete the unwanted files before proceeding to the next step. 12. Wait for approximately five minutes to allow file replication to complete. 13. Verify that the right packages are on all of the Service Provider appliances of each Datacenter: /usr/local/desktone/upgrade/checkpackages.sh The expected output of this command is similar to the following: Found 167 out of 167 packages at xxx.xx.xxx.xx. Found 167 out of 167 packages at xxx.xx.xxx.xx. All packages found on specified IPs. Please confirm all SP Nodes are listed and proceed with upgrade. Note: If any SP Node entry in the list is missing, do not proceed with the upgrade. 1.2 Upgrade Appliances to DaaS Platform Upgrade Primary Service Provider Appliance Upgrade primary SP1 to DaaS platform using the following procedure. Procedure 1. Ensure that all commands are run as root (required only if not already root): sudo i 2. Execute the upgrade file, specifying the full path is required: /usr/local/desktone/upgrade/runupgrade.sh Note: If the upgrade fails and you see a debian package update/install error in /var/log/desktone/upgrade.log, then perform the following steps: a. Run apt-get command to install/update the package in question. b. Run commands: mv /usr/local/pgsql.old /usr/local/pgsql mv /data/db.old /data/db service postgres start c. Run /usr/local/desktone/upgrade/runupgrade.sh again. The system prompts you to accept the End-User License Agreement (EULA). 3. If you accept the terms, enter Yes. Upon successful completion, the Primary SP appliance reboots. Upon a failed completion, the dtservice and CIM service stop and information regarding the failure is contained in this file: /var/log/desktone/upgrade.log 4. Once reboot completes and the dtservice has started, navigate to the Service Center using the Primary Service Providers IP address: 5. Review the Appliances page (appliances > browse appliances) and verify that the Primary Service Provider appliance is at version

14 Upgrading to Horizon DaaS Platform Upgrade Org1000 Appliances Note: Before upgrading appliances for an organization, navigate to the Reservations page in the Service Center (appliances > reservations) and reschedule any pending reservations until after the upgrade. Procedure 1. In the Service Center, select appliances > maintenance. 2. Under Upgrade Operation, select organization ID of 1000 and click Invoke Upgrade. 3. All appliances for organization 1000 are updated. Allow a minimum of minutes for each data center to upgrade. Services on affected appliances are stopped and started automatically. Watch desktone.log for progress (located in the /var/log/desktone directory on the Primary Service Provider). While the upgrade is in progress, the status of running will be displayed on the table under the Upgrade Operation section. When it completes, the status of successful or failed is shown. You may need to refresh the page to get the latest status. 4. Stay logged in to service provider if you are upgrading other appliances Upgrade All Other Appliances Note: Before upgrading appliances for an organization, navigate to the Reservations page in the Service Center (appliances > reservations) and reschedule any pending reservations until after the upgrade. 1. In the Service Center, select tenants > browse tenants to find the organization IDs for each Tenant. 2. Select appliances > maintenance. 3. Under Upgrade Operation, select the organization ID of your choice and click Invoke Upgrade. 4. Tenant appliances for the organization are updated. Allow a minimum of minutes for each data center to upgrade. Services on affected appliances are stopped and started automatically. Watch desktone.log for progress (located in the /var/log/desktone directory on the Primary Service Provider). While the upgrade is in progress, the status of running will be displayed on the table under the Upgrade Operation section. When it completes, the status of successful or failed would be shown. You may need to refresh the page to get the latest status. 5. In the Service Center, select appliances > browse appliances to verify that all tenant appliances are at version If some appliances are not at version 7.0.0, you did not update all of the organization IDs shown on the Tenants screen. 6. Stay logged in to service provider if you are upgrading other organization and repeat this section as needed Check Desktop Functionality When you have finished the upgrade, perform the steps below to check that desktops are running on each of the desktop managers. Procedure 1. In the Service Center, open the Service Grid page and click on Desktop Managers. 2. In the tree in the left window, select each desktop manager that had one or more desktops running before the upgrade and confirm that the desktops are still running. 6

15 Upgrading to Horizon DaaS Platform If any of the desktop managers that had VMs online before the upgrade now show zero VMs online, initiate a full inventory by performing the following steps. a. Display the policy settings for the tenant in question in the Service Center under Tenants -> Policy b. Note the current setting for the element.monitor.element.fullinventory.interval policy (default value is milliseconds). c. Change the setting to a number less than 100 and save changes. d. Change the setting back to the previous value. e. This will cause the full inventory to run and the desktops will reappear within minutes. 1.3 Update DaaS Agent When the Tenant appliances have been upgraded, update the DaaS Agent using a domain controller with a GPO policy. 1.4 Snapshots and Rollback During upgrade, the DaaS platform automatically creates snapshots of Tenant appliances and resource managers (and creates a reservation task to remove snapshots from the previous upgrade). Use these and the Service Provider snapshots you created previously if you need to roll back to the previous version after completing the upgrade. Note: If you roll back to DaaS platform 6.1.x, any changes made to the environment after the DaaS platform upgrade will be lost, for example changes to pools and mappings Rescheduling the Snapshot Deletion A reservation exists to delete Tenant and Resource Manager snapshots. Once the snapshots are deleted, you cannot roll back. To change the reservation and keep the snapshots for a longer time period: 1. In the Service Center, select appliances > reservations. 2. Locate the reservation named Delete snapshots for <X > - < Y>, where X is org ID and Y is the datacenter, and click the Reschedule link for this reservation Snapshot You can see the list of current snapshots using the vsphere client. For example, if you are upgrading from to 7.0.0, the snapshot name and description in vsphere will look like this: Name: Automated Snapshot at Description: AUTO <Timestamp> 7

16 System Blueprint 2 System Blueprint NOTE: THIS SECTION IS IN DRAFT STATUS, AND SOME INFORMATION MAY NOT BE UP-TO- DATE FOR THE CURRENT RELEASE. FOR MORE INFORMATION REGARDING THE TOPICS DISCUSSED BELOW, CONTACT YOUR VMWARE REPRESENTATIVE. 2.1 Introduction This section provides an overview of the data center infrastructure requirements of the Horizon DaaS Platform. The view presented here is from the service provider (SP) perspective: that is, data center infrastructure primarily refers to the organization of resources within the SP site. Topics such as tenant user storage requirements are not addressed in detail in this section. The examples in this section are hypothetical and are presented to introduce the methods of estimation only. The equipment needed in any installation is specific to a data center, tenants, and network. For example, the typical storage requirements for a tenant are difficult to generalize since virtual machine (VM) image sizes can vary from as low as 8 or 10 GB in a student environment to more than 50 GB in a business environment. Estimates in this section are based on past experience and cannot accurately reflect every environment. VMware strongly recommends performing an analysis to determine the requirements of your specific environment. Contact VMware Technical Support for assistance with this analysis Intended Audience This section assumes that you are familiar with: Basic networking concepts such as layer 2 separation Microsoft Active Directory Virtualization software, such as from VMware vsphere Storage concepts such as I/O, protocols like NFS and iscsi, and replication Linux and Windows operating systems Data center operations Organization of this Section Platform Overview introduces the individual components of a Horizon DaaS installation, describing each appliance s function and its place in the system. Compute Resources describes how to size the servers needed to host the Horizon DaaS Platform. 8

17 System Blueprint Network Resources describes the build-out of more tenants within a data center. The emphasis in this section is on the core networking in the Horizon DaaS environment between the SP and tenants, particularly on maintaining clear and secure separation between tenants. Storage Resources focuses on the storage resource requirements for a data center. Networking between Data Centers demonstrates the basic architecture of a multiple data center SP that includes multiple tenants across multiple geographic locations. Role Separation and Administration describes the three browser-based graphical user interface portals provided by the Horizon DaaS Platform: the Service Center (for SPs), Administration console (for Tenant Administrators), and the Desktop Portal (for end-users) Terms The table below lists some common terms that are specific to the Horizon DaaS Platform. Other terms are defined as necessary within the text. Table 2 1 Common Terms Term Appliance Data Center Hypervisor Hypervisor Manager Tenant Virtual Desktop Virtual Machine Pool Definition An appliance is a virtual machine (VM) combined with a functional unit of software in the Horizon DaaS Platform. The term node is used interchangeably with appliance. Data center is a label used to logically group lower-level virtualization resources. Data center corresponds to a physical location managed by an SP. A hypervisor allows multiple operating systems to run concurrently on a host computer (hardware virtualization). A hypervisor manager refers to the management layer that communicates directly with the hypervisor. vcenter is an external hypervisor management layer that aggregates multiple hypervisors.. A customer that is consuming hosted virtual desktops from a Service Provider. A virtual desktop is a virtual machine that is running remotely (relative to the end user) usually on a virtual desktop host. The virtual desktop has input devices (keyboard and mouse) and a display device (monitor) to view the desktop display. A pool is a named and managed collection of virtual desktops. There are two types of pools, static and dynamic. A typical data center will have a mix of static and dynamic pools. A static pool consists of virtual desktops that are assigned to individuals. The first time a persistent user logs in, they are allocated an available VM from the pool. After that time, that VM is now assigned to that user and not available to other users. The number of VMs in the pool should equal the number of users assigned to the pool if all users have 1:1 mappings. A dynamic pool consists of virtual desktops that are assigned on an as-needed basis. An end user receives any appropriate virtual desktop from the pool. The state of the virtual desktop in a dynamic pool can be recycled to a predefined state between sessions. The non-persistent pool defines the number of users that can be connected concurrently. Therefore, the number of 9

18 System Blueprint users assigned to the pool can exceed the number of VMs in the pool. 2.2 Platform Overview Your DaaS environment can be broken down into four key elements, compute, storage, network, and the Horizon DaaS Platform. Through our patented assembly of these resources managed by the Horizon DaaS Platform, your DaaS solution can scale to hundreds of thousands of virtual desktops across hundreds of tenants in multiple data centers around the globe Key Components of the Horizon DaaS Platform Horizon DaaS Management Hosts an HA pair of physical machines that run a hypervisor and host multiple Horizon DaaS management virtual appliances for the service provider and tenants. Virtual Desktop Hosts - physical machines that run a hypervisor and host tenant desktop VMs. The Horizon DaaS Platform allows for sharing of a Virtual Desktop Host between multiple tenants; however, Microsoft licensing for desktop operating systems prohibits this configuration. If tenants are running a Linux OS or using Windows Server (for which there is SPLA licensing available) then sharing of the Virtual Desktop Host across tenants is permitted. Storage System- A dedicated storage system supporting block or file based storage access for persistence of the virtual machine s virtual disk. Networking The network must support VLAN tagging or alternatively distributed virtual networking (also referred to as DVS) can be used in conjunction with VMware vcenter. A unique network should be defined for the management network (containing the hosts and storage systems), the Service Provider network (literally, an extension of the Service Providers network into the VMware datacenter), the Horizon DaaS management network (referred to as the backbone link local network), and 1 or more isolated networks for each tenant. Horizon DaaS Appliances Virtual servers that live on the Horizon DaaS Management Hosts and support the Horizon DaaS solution. 10

19 System Blueprint Figure 2 1 Relationship between Horizon DaaS Management Hosts and Horizon DaaS Appliances (Multi-Tenant) Figure 2 2 Horizon DaaS Logical View (One Tenant) Horizon DaaS Management Appliances The following Horizon DaaS Management Appliances are virtual machines that are used to control and run the Horizon DaaS Platform: Service Provider Appliance Provides two types of access to the system: (a) via the Service Center web based UI; (b) as a transit point for enabling ssh access to all the management appliances in the data 11

20 System Blueprint center. The Service Provider Appliance is the first appliance installed in a data center and, once bootstrapped, provides the foundation to install the remainder of the Horizon DaaS Platform. Resource Manager Appliance A Resource Manager appliance integrates with the physical and virtual infrastructure in a given data center. A single Resource Manager appliance can be shared across multiple tenants. The Resource Manager abstracts all specifics of the infrastructure from the tenant appliances. Tenant Appliance Provides the tenant with both end user and administrative access to their virtual desktops. End users can access and manage their individual virtual desktops via the Desktop Portal. Administrators have the ability to create and manage their virtual desktops via the Administration Console. Desktop Manager Appliances A desktop manager appliance is a tenant appliance that does not include the components providing brokering and user access (end user or admin). Desktop manager appliances serve 2 key purposes: Desktop capacity scale out: The initial tenant appliance is designed to provide capacity of up to 5,000 desktops per data center. When an individual tenant needs to scale beyond 5,000 desktops in a particular data center, additional desktop manager appliances can be added to provide this capacity. Additional desktop manager appliance pairs can support up to another 5,000 desktops each. Compute resource optimization: A desktop manager is designed to treat the individually assigned compute equally. If there is a requirement for a specialized desktop workload, that workload can be optimized by creating a new desktop manager pair with only the compute for that workload assigned to it. A few examples of specialized workloads consist of delivering standard VDI, VDI with GPU, and RDS. In these cases the compute for these workloads would be separate and disctinct from each other. All management appliances are connected to the Backbone and either the SP network (Service Provider Appliance and Resource Manager Appliance) or the Tenants own network as shown in the figure above. Horizon DaaS requires that all management appliances be installed as HA pairs. To ensure physical hardware high availability, all Horizon DaaS Management appliance pairs are automatically distributed across separate physical Horizon DaaS Management Hosts. The Horizon DaaS Management Appliances allow monitoring via the standard CIM (common information model) WBEM (web-based enterprise management) interface. You can use any monitoring tool capable of understanding the CIM data model (for example, Tivoli). Information related to the types of CIM classes and recommended thresholds are available in the Horizon DaaS Platform Monitoring technote in the Partner Portal Management Appliance High Availablity High availability of management appliances is inherently built-in to the platform itself. How high availability is accomplished varies depending on the appliance type. In all cases management appliances are deployed in pairs to protect against the failure of any single appliance. Appliances are placed on separate physical management servers to protect against hardware failure. In some cases, paired appliances could end up on the same host. This would normally happen when vcenter clustering is used with DRS. DRS could vmotion an appliance to a host where the appliance pair already exists. It is possible to ensure that DRS doesn t move a VM, but it has been a conscious decision to let DRS appropriately balance the environment and determine where a VM should run. If a host were to fail that has both paired appliances the appliances would automatically and immediately be started on another host in the cluster resulting in very minimal downtime. There are several technologies used to enable high availability that require different handling when an appliance goes down. They are: Database Replication: All management appliances that contain a database utilize a master/slave replication scheme. That means at any point in time there is only a single master database for a pair of appliances. The master database is the only database that can be written to. The master database will always be on the appliance that is marked as primary in the appliances screen in the service center. If 12

21 System Blueprint an appliance that is not the primary appliance (i.e is running a slave database instance) goes down there is no effect to the environment. If an appliance that is the primary appliance and therefore contains the master database instance of a database cluster goes down there are 2 courses of action depending on the type of appliance: 1) Manual Failover: In general it s not desired to promote a slave instance in a database cluster to be the new master if it s not required. When failover occurs, the old master database has been evicted from the cluster. When the failed appliance comes back online, the database cluster must be reinitialized so that the new instance can be added. This requires a small amount of downtime. In many cases it s not required to automatically promote a slave instance in the database cluster to be the new master. This is possible because critical activities can still be accomplished without writing to the database. So, the approach here is to not automatically fail a master database instance but rather wait for the master to come back online. If the primary appliance has truly failed, a manual promotion of a slave instance should be performed. 2) Automatic Failover: There are cases where it s not possible for the system to perform critical functions when the primary appliance has gone down. In these cases automatic action is taken to promote a slave instance to be the new master of the database cluster which evicts the old master instance from the cluster. There is care taken when doing this though. If a primary appliance were to reboot or go down for a short period of time it would not be desirable to evict it from the database cluster because manual cluster reinitialization would be required which implies downtime. So a grace period is allowed before action is taken. By default, this grace period is 5 minutes and can be alternately configured. Floating IP Address: For any appliances that have services accessed by a user (end user or admin), a floating IP address is used to ensure all traffic is routed to an active appliance. This includes SP and tenant appliances. When creating SP and tenant appliances, individual static IP addresses are requested as well as a 3rd shared address called a floating IP address. The appliance pair will share a floating IP address. The floating IP address is designed to move between the pair of appliances and always be bound to an appliance that is online. The technology used to handle failover of the floating IP address exchanges heartbeats between the paired appliances and when an appliance that was the owner of the floating IP address goes down it will be moved to the active appliance thus taking ownership of any traffic destined for the floating IP address. This process is near instantaneous as the heartbeats occur at a very frequent intervals and an arp request is sent to the switch ensuring network routing tables are immediately updated. In order to ensure consistent user access, any DNS resolution should be configured to point at the floating IP address and not an individual appliance address. In general all appliances are considered disposable except for the database. It is highly recommended to back up the databases on all primary appliances on a nightly basis. Please see System Maintenance for further information on how to configure backup. Scripts are provided in order to do proper database backup and restore. It is not required to back up the appliances themselves as they can very easily be recreated by using the appliance restore feature available in the Service Center. In fact appliance restore is almost always faster than manually restoring a VM from backup. Please refer to the online help on appliance restore in the Service Center. There are specific limitations to understand especially when restoring a pair of appliances at the same time. Given the approaches to HA as described above, the HA characteristics of the individual management appliances are as follows: Service Provider Appliances: SP appliances contain a replicated database and employ a manual failover approach. In a multi-dc install the primary appliance in the primary DC has the master DB instance and all other appliances run a slave instance. This even includes the primary SP appliance in a secondary DC. So, for example, in a 2 DC install there would be 2 pairs of appliances deployed (1 pair per DC) but 1 master DB instance and 3 slave instances. Resource Manager Appliance: Resource Manager appliances are completely stateless and therefore there are no special HA considerations for these appliances. Tenant Appliances: Tenant appliances contain 2 databases that make up separate database clusters. Inside a tenant appliance are 2 core services, referred to as the Access Manager and the Desktop Manager. Each of the core services manages a separate database cluster and employs a different approach to replication. The Access Manager employs a manual failover approach. This approach is 13

22 System Blueprint taken because users can still establish connections to the desktops and applications even when the master database instance is down. Operations such as provisioning are not available when the primary tenant appliance is down. It s possible to manually promote a secondary tenant appliance if provisioning or other Access Manager operations are required. In a multi-dc tenant install there is only a single Access Manager master database just as there was for the SP appliances. The Desktop Manager service is used to manage the desktops themselves and employs an automatic failover approach because it must write to the database in order to perform basic operations such as desktop allocation. Automatic failover occurs as it has been described above. Desktop Manager Appliances: Desktop manager appliances run the Desktop Manager service as described previously in the Tenant Appliances section Network Services DNS, DHCP, NTP and Active Directory are necessary components as part of a Horizon DaaS installation. There are two ways to implement these services. They can be implemented locally within the data center in the Tenant Network, or the Tenant Network can be extended via a site to site connection (VPN or MPLS) to the Tenant s own data center. The site to site connection back to the customer s network works well for DNS, DHCP, and Active Directory as long as: The latency back to the customer s network is less than 200ms. The customer s data center has the bandwidth required for this connectivity. If the site to site connection is being used for only the AD, DNS, and DHCP traffic, then there will be minimal bandwidth requirements (1Mbps or less). If the customer is using the site to site connection back to their network for other applications, then it is necessary to determine the bandwidth requirements of those applications. For example, if users will be accessing network file shares frequently using the CIFS protocol, then the latency needs to be kept to a minimum as CIFS has very poor performance once there is any latency or packet loss. If the bandwidth requirements are too high, or the latency is not within a reasonable range, then it is possible to have a local copy of the AD running in the data center as a replicated AD Agent Compatibility It is recommended that the Horizon Agent and DaaS Agent components be updated in all gold patterns and virtual desktops with each new release of the Horizon DaaS Platform. The DaaS Agent is backwards compatible to one minor version of the Horizon DaaS Platform. However, to take advantage of new functionality in the Horizon DaaS Platform, the DaaS Agent would need to be upgraded. Please refer to the product support notices section of the release notes for each Horizon DaaS Platform release for specifics on the functionality that affects the these components. 2.3 Compute Resources Compute resources refers to the physical servers necessary to support the Horizon DaaS Platform and the software required on those hosts. Horizon DaaS Management Appliances and desktop virtual machines cannot reside on the same physical server. Separate servers must be used for the following: Horizon DaaS Management Host (service provider) Virtual Desktop Host (tenant) Although both types of hosts support virtualized servers or desktops, the optimization of each of these hosts is slightly different. As such the process for sizing each server is defined separately below. 14

23 System Blueprint Hardware Requirements for Horizon DaaS Management Hosts The Management hosts are a pair of physical machines that contain the Horizon DaaS Management Appliances (both service provide and tenant appliances). Several sample profiles are defined below; once a server is full you can simply add additional Management hosts to the platform Horizon DaaS Appliance Sizing Requirements The following are the prescribed sizing requirements for Horizon DaaS appliances. Table 2 2 Horizon DaaS Appliance Sizing Requirements Appliance Template (Memory/Disk Space) Sizing Service Provider Appliance Standard (3GB/20GB) 1 pair / dc Resource Manager Appliance Standard (3GB/20GB) 1 pair / dc / 20,000 VMs Tenant Appliance Standard (3GB/20GB) 1 pair / dc / tenant / 5,000 users The smallest environment begins with two management hosts, each with one service provider appliance, one resource manager and one tenant appliance. From there, additional tenants are added to the datacenter by adding an additional tenant appliance to each management host. The size of the management host is generally referred to by the number of tenants it can support Sizing a Management Host for a Specific Number of Tenants There are three variables to consider when determining the hardware configuration for a Horizon DaaS Management Host: CPU Each core supports 10 tenants. For example, four cores are required to support 40 tenants. Memory Each tenant requires 3 GB of RAM on each Horizon DaaS management host. For example, 120 GB of RAM on each host is required to support 40 tenants. Storage Each Tenant requires 40 GB of storage, 20 GB allocated to each Horizon DaaS management host. For example, a pair of management hosts that can scale to 50 tenants requires 1000 GB (1 TB) of storage each (2 TB total). 1 The table below defines the server hardware used for two sample Horizon DaaS Management hosts. Table 2 3 Sample Hardware Requirements for each Horizon DaaS management host Component Trial Environment Production Recommendation CPU 1 CPU 1 CPU CPU Architecture 4 Cores 8 Cores Minimum RAM 48 GB 128 GB Data disk configuration GB 1 TB of Storage Supported Tenants If you are using external storage that has deduplication for the Horizon DaaS appliances, the storage capacity requirements would be less. 15

24 System Blueprint Hardware Requirements for Virtual Desktop Hosts Virtual desktop hosts are sized based on the number of CPU cores and amount of memory installed in the server. All tenant virtual desktops reside on shared storage. As such, Desktop Hosts only require a pair of small disks for the hypervisor O/S installation Sizing a Desktop Host for a Specific Number of Desktops The guidelines for sizing the Memory and CPU for a desktop host are: CPU VMware recommends allocating about 300 MHz CPU for a stand 1vCPU desktop. Based on the total speed of the CPU you can determine the virtual to physical ratio. For example, a 3.0 GHz CPU core will support 10 standard desktops, or a 10:1 virtual to physical ratio. Virtual to physical CPU ratios will vary based on use case and type of processor. Please refer to CPU Speed Considerations below for further information. Memory VMware recommends setting a 30% over commit ratio for memory; that is 32GB of physical memory yields approximately 40GB of virtual memory allocated for desktops. Memory over commit ratios can vary based on the workload on a host. The more similar the workload the higher the memory over commit ratio can be. For example, if a host has all Windows 7 SP1 VMs then page sharing will be optimal and therefore the memory over commit can be high Host Sizing Calculations Two formulas are helpful when sizing your hosts. There are four variables for each formula, you can solve for any of the four variables, so long as you know three. The variables are the number of VMs on the host, the amount of memory or CPU cores assigned to each virtual desktop, the amount of physical memory or CPU cores installed in the host, and the over commit ratios for either the memory or CPU cores. Memory: [Number of VMs] x [Virtual memory per VM] <= [Physical memory] x [Memory over commit ratio] CPU: [Number of VMs] x [Virtual CPUs per VM] <= [Number of physical cores] x [CPU over commit ratio] The table below defines the server hardware used for the sample Virtual Desktop hosts. The table assumes a virtual desktop that consists of 2 GB of RAM and one virtual CPU. This example uses a 10 x CPU over commit ratio and a 1.5 x memory over commit ratio. Table 2 4 Minimum Hardware Requirements for Virtual Desktop Host Number of Desktops Cores Required RAM Required (GB) CPU Speed Considerations As the diversity of server processors continues to expand, a simple core ratio is not appropriate in most situations particularly in the case of very fast or very slow processors. It has become standard practice to use MHz based sizing. To size desktops to a server using MHz based sizing simply multiply the clock 16

25 System Blueprint speed of the processor by the number of cores then divide by a per user allocation. VMware recommends allocating 300 MHz per virtual CPU. As with host sizing equations above, the equation has four variables, you can solve for any of the four variables, so long as you know three. [Number of VMs] x [MHz allocated per desktop] <= [Number of physical cores] x [CPU clock speed] Example how many desktops can I host with a single 1.9Ghz six core CPU? Number of VMs = 6 x 1900 / 250 = ~ Network Resources Note: IPv6 connectivity is required for all appliance installations over the Link Local Backbone network. There are two key components to the network to assure tenant separation when assembling the Horizon DaaS Platform, VLAN tagging and VRF support. In the Horizon DaaS environment, a tenant network is not a subnet within the SP network; each tenant network is a logical extension of the tenant network existing in the SP data center. The figure below shows the distinct networks within the data center: The Link Local Backbone network is fully controlled by the SP. This network is a link local nonroutable subnet ( /16) that is logically separated from all tenant networks. The backbone network connects all Horizon DaaS Management Appliances. For example, the Tenant A Appliance connects to the SP Resource Manager via the link local backbone network. The Management Network is used to segregate all the physical hosts and storage systems. The SP network is an extension of the Service Provider s network into the data center. The Service Center is accessed through the Service Provider appliances on the Service Provider network. The SP VLAN must have access to the management VLAN for access to Virtual Desktop hosts and the storage systems. The Tenant networks are fully controlled by the tenants, again as a discrete VLAN that is separate from the SP and other tenant networks. The tenant network connects the tenant appliances to a tenant's virtual desktops. The tenant VLAN is not accessible to the SP. The figure below emphasizes the clean separation of SP and tenant networks. The area labeled Horizon DaaS service grid provides the core of the Horizon DaaS Platform. The portion of the diagram directly connected to a Tenant network represents the components of the system that are duplicated for multiple tenants. Note the following network architecture: The Tenant networks are not a subnet of the SP network. It is a logical extension of the Tenant A or Tenant B network existing in the SP data center. High availability indicates redundant pairs to ensure failover integrity. Most of the computing components are pairs of virtual machines (shown in light blue). The number of physical servers in a tenant network largely depends on the size and number of virtual desktops the tenant is hosting. 17

26 System Blueprint Figure 2 3 Horizon DaaS Logical View (Additional Tenant) Virtual LANs in the Horizon DaaS Platform A VLAN is an emulation of a standard LAN that allows data transfer to take place without the traditional physical restraints placed on a network. An understanding of the use of VLANs is important to planning and implementing the Horizon DaaS Platform due to their role in ensuring separation of tenants and SP, optimizing the performance of data and management information flows, and in increasing the scalability of the Horizon DaaS Platform Distributed Virtual Networking An alternate network configuration option is available by using distributed virtual networking as opposed to using the local vswitch with VLANs. Distributed virtual networking allows the network configuration to be done in a software appliance based controller rather than in the physical hardware device (i.e. the router). There are two distributed virtual networking options available with the Horizon DaaS Platform. They are VMware vsphere Distributed Switch (VDS) and Cisco Nexus 1000V. Please refer to the product documentation for further information Layer 2 segregation using VLANs VLANs provide segregation of traffic at layer 2 to prevent two tenants from seeing each other s traffic while still sharing the same physical network path. However, in order to reach the end-user, this traffic must pass 18

27 System Blueprint through a router. Without additional segregation at layer 3, customers would be able to route to each other, or could have a non-resolvable conflict of IP addresses. Figure 2 4 Layer 2 Segregation Using VLANs The figure above illustrates layer 2 segregation with two tenants. In a typical environment, a multilayer switch is required. Note that while four physical switches and two routers are shown in the figure above, only one of each might be needed; virtual switches and routers can be used. The VLANs are trunked. In addition, each of the Virtual Desktop Hosts and the Horizon DaaS management host support multiple virtual machines Layer 3 segregation using VRFs Virtual Routing and Forwarding (VRF) allows multiple instances of a routing table to co-exist within the same router at the same time. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other. VLANs in a Horizon DaaS installation are aggregated into VRFs. Once aggregated into a VRF, segregation is handled at layer 3 and the VLAN IDs are effectively discarded. This means that VLANs require uniqueness only under one VRF, and the same VLAN IDs can be reused under multiple VRFs within a single data center Networking Resources Switches, routers, load balancers and gateways play a role in any Horizon DaaS installation. This section lists the characteristics required of each of these components. Horizon DaaS is hardware agnostic, only requiring that equipment supports the characteristics listed in this section. 19

28 System Blueprint For example, any layer 3 network devices including firewalls or routers installed between the customer site and the customer s virtual desktops at the SP s data center must meet one of the following requirements, in order of preference: Support multiple independent routing tables (VRFs) Be dedicated to the customer and support out-of-band management Be dedicated to the customer and managed in-band from the customer s network Not meeting at least one of these requirements can result in IP address conflicts between the SP and the tenant Switches Switches must support trunking of VLANs. Here are some guidelines regarding the connectivity requirements for the switches: Connectivity between the desktops hosts and the storage should be a 10 GB Ethernet network. For additional bandwidth, you could aggregate the two links to achieve 20 GB. Connectivity for tenant/protocol traffic can be 1 GB connections Routers Tenant networks are VLAN tagged; for uniformity of management, SP networks are also VLAN tagged. Routers must support VRFs. If there will be customers with VPN access back into their corporate network for access to network services like DNS/AD/DHCP, or for access to other applications, then the router must have the ability to tie that VPN tunnel to the VRF for a tenant Load Balancing Load balancing is only required in front of the tenant appliances for a tenant with 25,000 or more desktops in a single data center Gateways Gateways must support VRFs Cross Data Center HA If you configure a tenant in two data centers, there should be a plan for failover to a backup data center in the event of a failure of one data center. The simplest solution is to redirect users to the backup data center by changing the DNS record for the portals. There are more advanced solutions available, such as configuring the F5 BIG-IP Global Traffic Manager to perform the failover automatically. The requirements for HA have to be determined before choosing the best solution Managing External IPs and global DNS entries In order for a customer to access their cloud hosted desktops from anywhere, the service provider must allocate external IP addresses to each tenant. The edge router must be able to direct traffic destined for the tenant portals to the tenant appliance shared IP. Depending on the desired DNS name, a global DNS entry should be created for the portal IP on the Service Provider s DNS (such as tenant.svcprosdesktops.com) or in the tenant s global DNS (such as desktops.tenant.com). The domain where the name is hosted matters because this also defines who is responsible for supplying the SSL certificates for the tenant. 20

29 System Blueprint Many routers support port based NATing. If your router is capable of redirecting traffic based on the incoming port, you can condense the number of external IPs needed to one per tenant. In such a configuration, configure traffic destined for port 80 or 443 to redirect to the Tenant Appliance Shared IP Wiring the Data Center Your management hosts will need to have the default tenant VLANs available since the tenant appliances reside there. Your desktop hosts need to have only the specific tenant VLAN that is assigned to that host. These need to be configured manually on the ESXi hosts before you add the host to the Horizon DaaS Platform. Figure 2 5 Sample ESX Network configuration for both tenant and management host. 2.5 Storage Resources Storage and storage planning are critical parts of any virtualization environment. There are two types of storage you must plan for, local storage on the host and networked storage. All hosts (both the Horizon DaaS management hosts and the Virtual Desktop Hosts) require local storage or SAN storage for the installation of the hypervisor; this is typically accomplished with a relatively small pair of RAID 1 disks installed in the host or a boot LUN from the SAN. Horizon DaaS management hosts require additional local storage or shared storage for all of the Horizon DaaS Management Appliances. For a Horizon DaaS management host, as described above, one could install four additional 600 GB high-speed SAS drives in a RAID 5 configuration to support the management appliances for 50 tenants. Alternatively, a 1.4 TB datastore could be used on each management host. Horizon DaaS uses shared storage to store the virtual desktops. The shared storage options available depend on how the hypervisors are being discovered by the Horizon DaaS Platform. More information regarding the storage options follow Storage Options SAN Storage Fibre channel and iscsi storage can be used because local storage is not an option for storing desktop VMs. All storage configuration changes are made outside of the Horizon DaaS Platform. Typically this would be done using the vsphere client connected to vcenter. One or more LUNs must be mapped to all ESXi hosts assigned to a Desktop Manager. The datastore(s) associated to the LUN(s) must be created on all hosts for that Desktop Manager and have the same exact name (case sensitive). The Horizon DaaS Platform will clone desktop VMs to the same datastore that the gold pattern resides on using the native vcenter cloning 21

30 System Blueprint API. Please refer to VMware documentation for further information regarding the use of shared storage across ESXi hosts NFS Storage NFS is an option when using vcenter. The NFS share where the desktops are stored is mounted to each of the tenant s Virtual Desktop Hosts in a given data center as an NFS datastore. Because the virtual desktops are on shared storage, it is possible to move a virtual desktop from one tenant host to another. Make sure your NFS datastore has sufficient I/O capacity. For planning purposes, assume an average of IOPs per virtual desktop for standard knowledge worker workloads. The figure below presents an overview of the Horizon DaaS storage architecture. Figure 2 6 Horizon DaaS Storage Architecture for NFS based configurations Notable characteristics of this architecture are: NFS shares presented and mounted on corresponding host servers Isolation is accomplished by presentation of NFS shares to specific hosts Failover and VM restart done at the Tenant Appliance layer De-duplication done at NFS storage layer with up to 95% space saving NAS is used for storage of virtual desktops and virtual desktop patterns. This shared location allows starting a desktop on any of the tenant hosts. NAS hardware is capable of fast cloning, thin provisioning, and de-duplication. VMware recommends clustered storage for redundancy. In addition, each NFS storage head should connect to a resilient switching layer with bonded Ethernet between each NFS storage head and switch. This increases the available bandwidth and resiliency. Some of the reasons for choosing NAS over SAN are: Each NAS mount point can be shared to the entire data center. 22

31 System Blueprint There is no built-in limit to the number of hosts that can mount a single NAS mount point. Capacity management can be done at data center granularity. Failure of any individual head can be handled automatically by software. No manual intervention is required. Single NAS head can host multiple tenants, using NFS export controls to provide firm tenant separation. Certain NAS heads can also be configured into virtual NAS heads to further improve tenant separation. The four primary goals of any storage solution for VDI space are: Rapid manufacturing of virtual desktops Data de-duplication to reduce overall storage footprint Increased IOPS capacity Reduced cost Tenant Data Storage VMware recommends that user s do not store data inside of the virtual desktop. Instead user data directories, such as the My Documents folder, should be redirected to a separate storage location. There are several reasons for this: The storage used for desktop images is highly optimized for performance: high speed FC or SAS disk is required; other optimizations are potentially in place to improve I/O. The storage requirements and performance profile for user data is significantly different from the desktop images and thus a different class of storage can be used. Protecting data that is stored inside of a virtual desktop requires that each of the virtual desktops is backed up individually. If user data is redirected to a CIFS share, the external storage can be better protected and maintained independently to the desktop image. There are several options for tenant data storage. A tenant s user data can be: Collocated with the Desktops in the Service Provider s Data Center the service provider can offer an add-on service that provides storage space for user data. Typically this would be CIFS storage as a service where the service provider offers secure tenant specific user data containers based on CIFS shares with integration into the tenant s own Active Directory. In the Tenant s Own Data Center Access to file shares and other data from the Virtual Desktops would be over the site-to-site VPN or MPLS connection between the tenant and service provider data centers. This connection is often referred to as the backhaul connection. Performance of the backhaul connection depends on the latency between the tenant and service provider data centers. In certain cases, the backhaul connection can be optimized with a WAN accelerator. In the Cloud the tenant can use a cloud storage service for storing user data. 2.6 Networking between Data Centers As noted above, a tenant network can be separated into functional pools rather than only into geographic locations. For example, Tenant C in the example can be divided into Sales, Manufacturing and Finance through the creation of pools since a pool is a logical unit that can span multiple geographic locations. Virtual desktops within a pool have no awareness of where their VM is located; end users should only be concerned with their user experience. Alternatively, pools could be aligned to a specific SLA or use case (i.e. stateless pool versus stateful pool). 23

32 System Blueprint The figure below shows a segment of the example network in which Tenant C is divided into organizational functions by pools rather than geographic locations. Finance and Development each have staff located in both New York and London. Figure 2 7 Multiple Data Centers Traffic between Data Centers SPs that maintain multiple data centers require network connectivity between the data centers for data sync operations and application traffic. The SP nodes in each data center need to be able to communicate with each other using their IP addresses (NAT will not work). This can be accomplished via a VPN tunnel. The traffic between data centers tends to be bursty in nature. But experience suggests that a T1 connection between data centers is sufficient to handle all cases without a disruption of service. Note that the Horizon DaaS management resource overhead scales independently of the number of tenant virtual desktops. Increasing the number of virtual desktops reduces the percentage of the cost of an installation that is required by Horizon DaaS management alone. The Horizon DaaS management overhead is an increasingly smaller portion of the cost of operation as data centers are scaled out with the addition of virtual desktops. It is important to realize that the example used in this section is a set of calculation methods based on a hypothetical case in order to demonstrate the methods. Optimization of tenant virtual desktops could reduce the number of required desktops resulting in decreases in the number of physical servers. 2.7 Sample Deployment In order to practice the concepts in this section we have a created a hypothetical Horizon DaaS network to accommodate 30,000 virtual desktops. Examples of calculations concerning resources are based on the architecture of this network (see figure below). The sample network consists of two SP data centers located in New York and London. There are three tenants: Tenant A is located in New York and consists of 5,000 virtual desktops. Tenant B is also located in New York and consists of 5,000 virtual desktops. Tenant C has two geographical locations and consists of a total of 20,000 virtual desktops: 5,000 in New York 15,000 in London 24

33 System Blueprint Figure 2 8 Sample Network used in this Section Horizon DaaS Management Appliances Required for Tenant A The following appliances are necessary for the initial Tenant A deployment. We will require the minimum two physical servers to provide physical server level HA. The table below describes how the Horizon DaaS appliances are allocated on the two Horizon DaaS management hosts. Table 2 5 : Sample Appliance Estimate (Single Tenant) Number of Horizon DaaS Appliances Required Horizon DaaS Management Appliance Mgmt Host A Mgmt Host B SP Service Provider Appliance 1 1 SP Resource Manager Appliance 1 1 Tenant A Tenant Appliance 1 1 Remember that virtual desktops cannot be deployed on the Horizon DaaS management hosts Horizon DaaS Management Appliances Required for Tenant B To add Tenant B to the New York data center we simply need to add the additional tenant appliances required to support Tenant B. Additional appliances are indicated in bold font in the table below. Table 2 6 : Sample Appliance Estimate (Two Tenants) Number of Horizon DaaS Appliances Required Horizon DaaS Management Appliance Mgmt Host A Mgmt Host B SP Service Provider Appliance 1 1 SP Resource Manager Appliance 1 1 Tenant A Tenant Appliance 1 1 B Tenant Appliance

34 System Blueprint After adding Tenant B we now have four Horizon DaaS Management Appliances running on each Horizon DaaS management host Desktop Host Requirements for Tenant A and Tenant B Considering the size of these tenants, we have the advantage of being able to use very large servers. For this example we will use the largest servers specified in this section, although in reality we may use this opportunity to explore even higher density compute options. Desktops per server Cores RAM (GB) Using this server, each tenant will require 42 servers to reach 5000 desktops Additional Data Centers and Tenant C When adding an additional data center, it is necessary to localize some of the SP appliances which results in some additional overhead cost. However, we also gain efficiencies with the ability to provide data center level HA. For instance, the example includes Tenant C headquartered in London - with 5,000 desktops in New York and 15,000 desktops hosted at a new data center in London. (The additional appliances are indicated in bold font in the table below.) Table 2 7 Additional Data Center Appliance Estimates Horizon DaaS Management Appliance Mgt Host A (NY) Number of Horizon DaaS Appliances Required Mgt Host B (NY) Mgt Host C (London) SP Service Provider Appliance SP Resource Manager Appliance Tenant A Tenant Appliance 1 1 B Tenant Appliance 1 1 C Tenant Appliance Mgt Host D (London) After adding Tenant C there are a total of five management appliances on each Horizon DaaS management host in NY and five management appliances on each Horizon DaaS management host in London Storage: Three Tenants in Two Data Centers Published figures for de-duplication suggest a conservative 75% reduction in storage required. Note that since most virtual desktops can consist largely of duplicated operating system components, the deduplication savings are typically larger. For the two data centers described above, the storage requirements under these assumptions are summarized in the table below. Table 2 8 Sample Storage Estimate (Two Data Centers) Data Center NY London Total Desktop VM disk TB TB Total Desktop VM disk assuming 75% de-duplication factor TB TB 26

35 System Blueprint Note the significant savings realized by current de-duplication technology using the fairly conservative estimate of 75%. To meet these targets, de-duplication functionality must exist on the primary storage system. 2.8 Planning a Production Environment Through VMware s own experiences operating the Horizon DaaS Cloud service, we developed a successful sales model that we offer as part of the Horizon DaaS Blueprint. The process makes use of several dedicated environments to allow prospective customers to experience how simple and productive a DaaS option can be. When initially deploying your production environment we will deploy four tenants. Each of these has a specific purpose in the sales cycle. The initial tenant we typically configure is the Demo environment. This will become your showcase environment to enable your sales team to show off what DaaS has to offer. The goal is to configure this tenant with static and dynamic pools consisting of Windows 7, Windows server desktops, Windows XP and Ubuntu desktops. This tenant also affords the install team the best opportunity to test the environment infrastructure. Typically the next tenant we deploy is an internal tenant for use by the service provider. The purpose of this environment is to enable your sales and technical teams to begin using hosted desktops themselves. How better to evangelize the service than if your teams are using the service themselves and are better able to understand customer concerns and the many additional opportunities that come from hosted Desktops. The final two tenants are directly tied to sales enablement i.e. let customers see firsthand how simple DaaS can be. The Free Trial environment allows potential customers access to a non-persistent Windows server desktop after a quick enrollment process. This is a key sales lead driver and introduces customers to your service offering. Once your sales team has qualified a lead, you can provide a full static Windows 7 POC desktop for the customer to trial for a short period of time. The goal of the POC environment is to quickly engage prospective customers so they can see how quick and easy DaaS can be and so they can test their own applications in the cloud on their own. Figure 2 9 Sample Data Center Wiring Diagram 2.9 Data Protection Horizon DaaS Appliance Backup With the exception of the database embedded in the Horizon DaaS appliance, the appliance is disposable: it is not required that an entire appliance be backed up. VMware provides backup and restore scripts for the embedded databases with the platform. The backup scripts should be executed daily. The most recent 27

36 System Blueprint backups should be kept on site for fast retrieval access. Additionally, a rotation should be identified to send backups offsite. If the Horizon DaaS appliances reside on external storage that is snapshot and replication capable, that could be considered as an alternate backup strategy Desktop Backup If user data is properly redirected to external file shares, backup of individual desktops should not be required because the desktop can easily be recreated. However, the gold images used to create the desktops should be backed up on a regular basis. Because a gold image is a powered off virtual machine, the backup should be performed by the service provider. The service provider could use snapshots and replication from the storage system as a strategy to protect the gold image(s). This has the benefit of being able to restore quickly and the ability to provide disaster recovery. A more traditional backup scheme could also be implemented if desired User Data Backup / Replication The user data redirected from the desktop should be backed up on a regular basis. Using storage system snapshots and replication can be an effective strategy with the ability to restore individual files to a specific point in time. A traditional backup could also be used to provide a similar backup capability. If user data is stored either at the service provider or tenant data center, file shares should be replicated if high availability and/or disaster recovery is desired. If user data is stored in the cloud, coordination will need to take place with the cloud storage provider in order to understand how to implement HA Security Platform Security Appliance Services The service provider, resource manager, tenant and desktop manager appliances act as both clients and servers of several internal platform services. SSL is employed to ensure communication for these services is secure. This involves encrypting the communication channel, and verifying that a certificate identifying the appliance running the service exists and is valid for that appliance. Every Horizon DaaS deployment generates its own unique Certificate Authority (CA) key pair and certificate during the bootstrap phase of the primary service provider appliance in the first data center. This CA is then used to sign the certificates for the appliances, including the primary service provider itself. The certificate for an appliance is created during its installation step. A key pair and Certificate Signing Request (CSR) are generated initially. The CSR is then copied to the primary service provider appliance for signing, and the signed certificate copied back to the appliance being installed. At no time is the private key for any appliance ever transmitted. The CA certificate is also copied to the appliance and is installed in a trusted certificate store. This process is repeated whenever an appliance is restored, and will generate a new certificate each time. Unlike other appliances, the primary service provider containing the CA cannot be restored. It is important to maintain the appropriate backups for it, and to follow the procedures for promoting another service provider appliance to be the primary in the event of an unrecoverable appliance failure. When an appliance makes a request to a service (i.e., is acting as a client), it establishes an SSL connection to port 8443 of the appliance running the service (i.e., the server). The server responds with its certificate and the client verifies that it trusts the server by checking that its trusted certificate store contains a certificate for the CA that signed the server certificate. It also validates the properties of the certificate, including the expiration date, and whether the IP address in the certificate matches the IP address it used to make the request. 28

37 System Blueprint DaaS Agent Services The DaaS agent acts as a client of services running on the tenant and desktop manager appliances. SSL is employed to ensure communication for these services is secure. This involves encrypting the communication channel, and verifying that a certificate identifying the appliance running the service exists and is valid for that appliance. The DaaS agent must be provided with the CA certificate generated by the Horizon DaaS platform. The CA certificate is used to verify that the tenant and desktop manager appliances are trusted. Otherwise, it will refuse to connect to the appliances. When configuring a new gold pattern, the certificate file should be copied to the certificate folder in the DaaS agent installation folder before the gold pattern is sealed. When the DaaS agent makes a request to a service (i.e., is acting as a client), it establishes an SSL connection to port 8443 of the appliance running the service (i.e., the server). The server responds with its certificate and the DaaS agent verifies that it trusts the server by checking that its certificate folder contains a certificate for the CA that signed the server certificate. It also validates the properties of the certificate, including the expiration date, and whether the IP address in the certificate matches the IP address it used to make the request Security Best Practices Unique DNS Record for Each Portal It is recommended that you create a separate DNS record for each of the three system portals: Desktop Portal (user portal) Administration console (admin portal) REST API portal They may all point to the IP of the tenant appliance. When distributing links to users, make sure to provide the appropriate hostname Role Separation and Administration The Horizon DaaS Platform presents three browser-based graphical user interface portals: Service Center Administration console Desktop Portal Service Center The Service Center is used by the Service Provider administrators to manage the data center resources, such as hosts, storage and the Horizon DaaS Management Appliances. The service center also enables the management of tenant contracts defining tenant models and quotas as well as the configuration of tenant appliances and networks. The Service Center supports creating and assigning additional roles and permissions among the Service provider administrators to securely distribute management tasks among larger organizations. 29

38 System Blueprint Administration console The Administration Console is used by the enterprise administrators (Tenant Administrators) to manage their virtual infrastructure. Enterprise administrators can provision both static and dynamic pools (or assignments ) of desktops based on templates (or images ) that they have customized or new templates that they might upload. Enterprise administrators can also add additional domains and map groups or individuals to either specific virtual desktops or pools. The Administration Console supports creating and assigning additional roles and permissions among the Service provider administrators to securely distribute management tasks among larger organizations Desktop Portal The Desktop Portal enables individual users to connect to their virtual desktops. Every tenant has their own customizable portal. Users login to the portal and have the option of being directly connected to a desktop they have defined as their default, or presented with a list of available desktops and enabled to choose which virtual desktop to connect to. Users can also set default protocols per VM and additional protocol customizations. Users can connect to the Desktop Portal from a variety of clients including thin clients (both WTOS based WYSE clients and any thin clients running Windows Embedded), thick clients (such as PCs running Windows, Mac OS or Linux) as well as ios and Android based mobile devices. The Desktop Portal facilitates connections using a wide variety of remoting protocols. RDP (Microsoft) Microsoft s Remote Desktop Protocol is a very strong protocol with broad support. The protocol supports a good multi-media experience when less than 20ms of latency, and good user experience when using office productivity apps when latency is under 50ms. Note: The RDP protocol is not supported in Horizon DaaS Platform for new pools. However, the existing pools which were created prior to upgrade will continue to work with the RDP protocol. PCoIP (VMware) The PCoIP experience provides a very good multi-media user experience in situations with both high latency and constrained bandwidth. RGS (HP) Remote Graphics Software developed by HP primarily for WAN deployments provides good multimedia support with latency as high as 100ms when provided ample bandwidth. RGS is particularly popular for graphics-intense use cases like CAD. HTML5 (Ericom) This client allows you to access your desktop via any HTML5-compatible web browser. It does not require any additional plug-ins, add-ons or installation of any kind on the end user device which makes this suitable for devices such as Chrome OS Netbooks. NX (Linux) Enables access to Linux Desktop 30

39 System Blueprint 2.12 NetApp Information This section lists Horizon DaaS Platform information specific to the NetApp environment. Supported Hardware NFS Permissions Access Credentials Data ONTAP NetApp FAS Series, NetApp V-Series, and IBM N-Series NFS permissions must be manually configured such that the required hypervisors have root access to the appropriate NFS exports. In order for the Horizon DaaS Resource Manager to properly access the NetApp API, a service account must be created. This account must have special privileges in order to make the API calls. The specific privileges required are included in a tech note in the Customer Knowledge Base. The Horizon DaaS Platform is qualified to work with the following versions of Data ONTAP: Data ONTAP 7-mode V7 (7.3.1 or greater) V8 (8.0.x, 8.1.x, 8.2.x) Clustered Data ONTAP (supported with vcenter using VSC) V8 (8.1.x, 8.2.x) Virtual Storage Console The NetApp Virtual Storage Console (VSC) is a plugin for VMware vcenter leveraged by the Horizon DaaS Platform for rapid cloning of virtual machines. The following versions of VSC are supported: 4.1-P1, Licenses FlexClone FlexClone provides the ability for the Horizon DaaS Platform to clone gold images in the matter of seconds (optional for Horizon DaaS but recommended) FlexScale FlexScale is the tuneable software component to Flash Cache. FlexScale allows different caching modes to be used based on the type of workload (optional for Horizon DaaS but recommended) Multistore Provides the ability to use vfiler for added tenant security and data mobility (optional for Horizon DaaS but recommended) NFS This is the base license required to use the NetApp filer for NFS (required by Horizon DaaS) A-SIS ASIS is the deduplication engine in ONTAP (optional for Horizon DaaS but recommended) NearStore A NearStore license is required when using ASIS deduplication (optional for Horizon DaaS but recommended) SnapMirror A SnapMirror license is required for thin replication (optional for Horizon DaaS but recommended if requiring site HA/DR) NetApp & Horizon DaaS Best Practices See the document Guidelines for Virtual Desktop Storage Profiling and Sizing on the NetApp website. 31

40 System Blueprint Best Practices VMware recommends the following best practices in the NetApp environment: File System Alignment - File system misalignment is a known issue in virtual environments and can cause performance issues for virtual machines (VMs) and therefore could impact the performance of a Horizon DaaS virtual desktop deployment. It is therefore critically important that the NetApp file system alignment practices are followed as per the NetApp document Best Practices for File System Alignment in Virtual Environments. Note that this issue is not unique to NetApp storage arrays and can occur with any storage array from any vendor. Separate Aggregate for Management It is recommended to create a separate aggregate at a smaller size to support Horizon DaaS management functions where they are hosted on shared NFS storage. The reason for this is to separate the management I/O load from the virtual desktop I/O load. Maximize Aggregate Size for Desktops It is recommended to create an aggregate at the maximum size supported for the particular model of NetApp filer. The reason for this is to include as many spindles as possible to spread data across to have optimum I/O performance. Minimize the number of Volumes It is recommended to minimize the number of volumes that are deployed to host virtual desktops. The reason for this is that data deduplication is done within the context of a volume. So, the more data in a single volume the greater chance of data blocks being deduplicated. Separate Volume and NFS Shares per Tenant For maintainability, separation, protection and portability purposes, it is recommended that a separate volume hosting NFS shares is created for each tenant s virtual desktops. For smaller tenant deployments, it might not be appropriate to follow the separate volume rule due to reduced efficiencies. vfiler It is recommended for an extra layer of security that each tenant have a Multistore vfiler instance created to host the virtual desktops. A vfiler container could also be used to secure and segregate tenant user data if hosted at the SP. vfiler functionality creates logical access separation within the same NetApp filer and would allow integration into the tenant s own Active Directory. Separate Volume to host swap, temp and winpage files This is required to separate redundant data from the volumes hosting the base desktop image. This approach reduces the redundant data that would otherwise be locked into snapshots and also replicated for DR. These volumes should have ASIS (de-duplication) disabled. Enable Deduplication It is recommended to enable ASIS deduplication for the virtual desktop and any user data host volumes. Note that this needs to be enabled on a per volume basis (disabled by default). Important: when setting up deduplication on the Storage Efficiency tab for a volume, make sure you check the "Scheduled" radio-button, not On-demand or "Automated". Use NetApp FlexClone It is highly recommended that NetApp FlexClone be utilized for desktop provisioning operations. The ability to provision with FlexClone is built into the Horizon DaaS Platform. FlexClone technology is hardware-assisted rapid creation of space-efficient, writable, point in time images of individual files. FlexClone provides the ability to clone hundreds and possibly thousands of desktop images from a base desktop image providing significant cost, space and time savings. Use SecureAdmin The Horizon DaaS Platform supports SSL and non-ssl access to the NetApp filer. By default, the Horizon DaaS Resource Manager will attempt to communicate with the NetApp filer via SSL. There is a configuration parameter to use non-ssl communication. Please refer to Horizon DaaS documentation regarding the specific setting. In order to use SSL to communicate with the NetApp filer, SecureAdmin must be installed and configured. Use FlashCache It is highly recommended that FlashCache be used to provide a large front end read cache. This helps lighten the I/O load on the disks and thus helps deal with high read I/O load such as boot storms. The size of the FlashCache varies depending on the FAS model. With a clustered NetApp, each filer head should have its own FlashCache card. 32

41 System Blueprint Use Snapshots Snapshots can provide an almost instantaneous way to protect and recover appliance, user data, and gold images. Snapshots do not affect performance and provide the ability for very fast restores. SnapMirror for DR SnapMirror can be used to replicate desktop and/or user data offsite in the case of a site failure. SnapMirror complements NetApp FlexClone and deduplication providing a thin replication capability where the data reduction persists during the replication process Configuring Your vfiler To enable the Horizon DaaS Platform to see your NetApp vfiler you need to enable httpd and create an account. Use the following commands as an example, these need to be run in the context of the appropriate vfiler (not on the root vfiler) options httpd.admin.enable on useradmin role add desktone_role -c "Role for Desktone API Support" -a login-httpadmin,api-license-list-info,api-system-get-info,api-system-get-version,api-system-getontapi-version,api-nfs-status,api-nfs-exportfs-list-rules-2,api-nfs-exportfs-modifyrule-2,api-clone-start,api-clone-stop,api-clone-list-status,api-vfiler-list-info useradmin group add desktone_group -c "Group for Desktone" -r desktone_role useradmin user add desktone -c "Service account for Desktone" -n "Desktone SA" -g desktone_group Desktop DR Deployment Strategies Multiple Data Center Desktop Images: SnapMirror can be used to replicate VM images between multiple data centers. Should a user s primary data center become inaccessible, replicated images would be available in an alternate data center to provide that user s primary desktop. Multiple Data Center User Data: SnapMirror can be used to replicate data between multiple data centers. Should any data center become inaccessible, replicated user data would be available in an alternate data center. Backup: Snapshot and SnapRestore can be used to backup and restore VM images and user data Cisco Virtualized Multi-Tenant Data Center (VMDC) The Cisco Virtualized Multi-Tenant Data Center (VMDC) architecture is a set of specifications and guidelines for creating and deploying a scalable, secure, and resilient infrastructure that addresses the needs of cloud computing. To develop a trusted approach to cloud computing, Cisco VMDC combines the latest routing and switching technologies, advancements in cloud security and automation, and leading edge offerings from cloud ecosystem partners. Cisco VMDC enables service providers (SPs) to build secure public clouds and enterprises to build private clouds with the following benefits: Reduced time to deployment - Provides a fully tested and validated architecture that enables technology adoption and rapid deployment. Reduced risk - Enables enterprises and service providers to deploy new architectures and technologies with confidence. Increased flexibility - Enables rapid, on-demand workload deployment in a multi-tenant environment using a comprehensive automation framework with portal-based resource provisioning and management capabilities. 33

42 System Blueprint Improved operational efficiency - Integrates automation with multi-tenant resource pools (compute, network, and storage) to improve asset use, reduce operational overhead, and mitigate operational configuration errors. For more information about the Cisco VMDC Framework go to VMDC 2.2 Solution Components Please consider the following defines the versions tested. Please contact your Cisco representative for the latest version of the VMDC architecture. Features Components Network Cisco Nexus 7010, 7018, NXOS Data center services node Cisco Catalyst 6509-E Switch (with Virtual Switching System [VSS]), IOS 12.2(33)SXJ Cisco ASR 9000, XR Cisco ASR 1006, XE (3)S Services Compute Cisco Virtual Security Gateway, 4.2(1)SV1(2) Cisco Virtual Network Management Center: 1.2(1b) Cisco Adaptive Security Appliance X, Cisco ACE30 Application Control Engine Module, A Cisco Unified Computing System (UCS ), 1.4(2b) Cisco UCS 5108 Blade Server Chassis Cisco UCS 6248 Fabric Interconnect Cisco UCS B230 M2 Blade Server Cisco UCS M71KR-E Emulex Converged Network Adapter (CNA) Cisco UCS M81KR Virtual Interface Card (VIC) 34

43 System Blueprint Virtualization VMware vspheretm 4.1 U1 VMware ESXi 4.1U1 Hypervisor Nexus N1010-x Storage NetApp FAS3170 and NetApp FAS6080 with ONTAP Suggested components for trial and POC environments When deploying an initial trial or Proof of Concept environment you might need to augment your environment in order to test key aspects of the Horizon DaaS Multi-Tenant platform. A basic environment can be constructed using the following Cisco components: Component ASR 1001 ASA 5505 Catalyst Switch UCS NetApp Use Routing, VRF and VLAN tagging VPN termination and firewall VLAN Compute Storage 35

44 System Blueprint Platform Install Checklist Install Using vcenter Before you can install the Horizon DaaS Platform, you first need to complete the tasks listed in the System Blueprint section of this document. Contact your VMware customer service representative for help with any of these prerequisites. A Service Provider Installation Worksheet and two Tenant Installation worksheets are included after this section to help organize and collect all the information needed to start the install. 1. Build the network infrastructure required to support multi-tenancy, typically accomplished with VLAN tagging for network separation at layer 2 and VRFs to isolate tenants and allow for a separate routing table for each tenant. See Network Resources in the System Blueprint for more detail. Confirm the management network is reachable from the service provider network. 2. Install and configure your storage system. See Storage Resources in the System Blueprint for more details. 3. Install three appropriately sized ESX Hosts with ESXi 5.0 or 5.1. Version 4.x is not supported with a vcenter installation and, as of this writing (Feb 7, 2014) ESXi 5.5 is not supported yet. Two hosts will be used for management with the third host for the Test Tenant. See Compute Resources in the System Blueprint for more sizing details. ESX hosts must be configured with a minimum of an ESXi Standard license (do not use the free version; the free license will not work). On each of the management hosts add all five of the required networks. Sample configuration can be found in the System Blueprint. Management Network For ESXi / vcenter Service Provider Network For the Desktone SP Appliances Link Local Network Not Routed For all the Desktone Appliances Tenant 1 Network For the 1st Tenant Appliances and Desktops Tenant 2 Network For the 2nd Tenant Appliances and Desktops On each of the management hosts add the Service Provider mount/lun to the ESXi hosts. On each tenant host add just the Management, Link Local, and Tenant networks. 4. Install and configure required network services. The Service Provider requires NTP, Active Directory and DNS services. The Test and POC Tenants will require their own Active Directory, DNS and DHCP services. 5. Assign IPs to Service Provider Nodes from the Service Provider network. 6. Service Provider AD Setup (Confirm settings with ADExplorer) 7. Assign IPs to Tenant Appliances from the Test Tenant network and POC Tenant network. 36

45 System Blueprint Service Provider Installation Worksheet Appliance SP1 Network Bootstrap Addition to Multi-DC Setup? Datacenter name Linklocal backbone VLAN ID Linklocal backbone IP for eth1 dt linklocal backbone mask in CIDR Format (0-32) SP VLAN ID SP1 Host IP for eth0 Are you building a new environment or joining an existing one. Usually the answer is No for a new environment. Unique to each physical site VLAN ID number or DVS Port Profile Name (as seen in vcenter) x.x Host IP for appliance SP1 ALL linklocal IPs start from this one IP 16 (recommended for production) or 24 (ok to use in poc environments) VLAN ID number or DVS Port Profile Name (as seen in vcenter) x.x.x.x Actual Host IP for SP1 appliance (not the floating) SP Network mask in CIDR Format (0-32) SP Network Gateway Hostname of SP1 appliance DNS Server IP NTP server (one per line) Is this an HA Setup? SP Floating IP Address psql Database Password Password for user desktone Will be used for all appliances GW of SP Network FQDN Needed ex: name.domain.suffix IP of DNS Server Just one IP of NTP Servers more than one if needed Usually Yes even if only one management host is currently available Floating IP of SP Pair only needed in HA setup (do not have to write it on sheet but please have one in mind for the install) (do not have to write it on sheet but please have one in mind for the install) SP Domain Bootstrap NETBIOS name Domain Suffix AD Protocol Name of Domain what you put before the \ when you log in VMWARE (for example) vmware.com ldap or ldaps AD Protocol Port 389 or 636 Primary DNS Server IP Context Domain Bind Account* Domain Bind Account Pwd Super Admin (SC Access) Usually same as table above DC=VMWARE,DC=COM CN=Joe Smith,CN=Users password for above account Distinguished Name w/out Context - Admin Group for SP Appliance GUI Access (Service Center). For example, CN=serviceadmins,CN=groups * To find domain bind acct, go to server manager, then View -> Advanced Features to turn on the Attribute Editor tab. Find the user, then user properties, then go to Attribute Editor and find the distinguishedname field. That is the account name needed, minus the end DC sections that make up the domain suffix. 37

46 System Blueprint Management Hosts Host Name or IP Management Account / Pswd Memory Over- Allocation Ratio CPU Over-Allocation Ratio vcenter IP or FQDN Login/Pwd of user that appliances use to connect to vcenter NA NA MgtHost1 Name as seen in vc MgtHost2 Name as seen in vc Service Provider NetApp NFS Storage with VSC (Only needed if storage is a NetApp and is using the VSC vcenter plugin) Use NetApp Name or IP * Account / Password Service Provider Tenant 1 Tenant 2 Tenant etc IP or FQDN IP or FQDN IP or FQDN IP or FQDN * Important: When adding a storage system to the Desktone Platform, the Address field must match how the VSC plugin was discovered for vcenter. If the plug-in was discovered as an IP address you must enter the IP address in the Address field. If it was discovered as a FQDN, then you must enter the complete domain name in the Address field. Service Provider Appliance Information Node Use VM / Appliance Hostname Service Provider IP Service Provider 2 Name of VM SP Host IP NOT LL IP NOT FQDN Tenant Resource Manager 1 Name of VM SP Host IP NOT LL IP NOT FQDN Tenant Resource Manager 2 Name of VM SP Host IP NOT LL IP NOT FQDN 38

47 System Blueprint Tenant 1 Installation Worksheet The following table lists the fields you will need to specify in the Service Center when installing a tenant. Field Values Sample Value / Notes Tenant VLAN ID or DVS Name 115 or Tenant-1-Net Tenant Gateway Tenant DNS Name (AD server) Tenant Subnet mask Primary Tenant Appliance /VM Name Primary Tenant Appliance IP Address Secondary Tenant Appliance/VM Name Secondary Tenant Appliance IP Address TenantA-Node TenantA-Node Floating IP Address Tenant vcenter Tenant vcenter User name Tenant vcenter Password DNS name or IP of host HostMgtAcct hostpsswd Tenant Management Hosts (vcenter info is only needed if an additional Tenant vcenter is used) Host Name or IP Management Account / Pswd Memory Over- Allocation Ratio CPU Over-Allocation Ratio Tenant vcenter IP or FQDN Login/Pwd of user that Horizon DaaS Appliances use to connect to vcenter NA NA MgtHost1 Name as seen in vc MgtHost2 Name as seen in vc Optionally, if you are configuring the Tenant Active Directory, you also need the following tenant info. Field NETBIOS Name DNS Domain Name Protocol Bind Username Bind Password Port Domain Controller IP Context Description Active Directory domain name Fully qualified Active Directory domain name LDAP or LDAPS, depending on your Active Directory setup Domain administrator Domain administrator password The defaults for this field are: LDAP -> 389 and LDAPS -> 636. You should not need to modify this field unless you are using a non-standard port. (Optional) Specify a single preferred domain controller IP address if you want AD traffic to hit a specific domain controller. This field is auto-populated based on the DNS Domain Name information provided earlier. 39

48 System Blueprint Tenant 2 Installation Worksheet The following table lists the fields you will need to specify in the Service Center when installing a second tenant. Field Values Sample Value / Notes Tenant VLAN ID or DVS Name 115 or Tenant-2-Net Tenant Gateway Tenant DNS Name (AD server) Tenant Subnet mask Primary Tenant Appliance /VM Name TenantB-Node1 Primary Tenant Appliance IP Address Secondary Tenant Appliance/VM Name TenantB-Node2 Secondary Tenant Appliance IP Address Floating IP Address Tenant vcenter Tenant vcenter User name Tenant vcenter Password DNS name or IP of host HostMgtAcct hostpsswd Tenant Management Hosts (vcenter info is only needed if an additional Tenant vcenter is used) Host Name or IP Management Account / Pswd Memory Over- Allocation Ratio CPU Over-Allocation Ratio Tenant vcenter IP or FQDN Login/Pwd of user that Horizon DaaS Appliances use to connect to vcenter NA NA MgtHost1 Name as seen in vc MgtHost2 Name as seen in vc Optionally, if you are configuring the Tenant Active Directory, you also need the following tenant info. Field NETBIOS Name DNS Domain Name Protocol Bind Username Bind Password Port Domain Controller IP Context Description Active Directory domain name Fully qualified Active Directory domain name LDAP or LDAPS, depending on your Active Directory setup Domain administrator Domain administrator password The defaults for this field are: LDAP -> 389 and LDAPS -> 636. You should not need to modify this field unless you are using a non-standard port. (Optional) Specify a single preferred domain controller IP address if you want AD traffic to hit a specific domain controller. This field is auto-populated based on the DNS Domain Name information provided earlier. 40

49 Tenant Installation vcenter 3 Tenant Installation vcenter 3.1 Overview The DaaS platform software allows you to manage your tenant desktops using VMware vcenter hypervisor management software. This guide provides you with information that is specific to installing and configuring a Tenant appliance in a datacenter using vcenter after you have installed or upgraded and configured the Service Provider appliance and Resource Manager. A Tenant Installation Worksheet is included at the end of this document to help you collect and organize all the information needed to complete the install. Please consider that the installation process explained in this section is dedicated to standing up a tenant in the DaaS platform. However, a successful tenant launch also needs to take into consideration items such as VDA licensing and image requirements and preparation. Please contact VMware support for further guidance with developing your own tenant on-boarding processes. 41

50 Tenant Installation vcenter 3.2 Tenant Installation Prerequisites The prerequisites are slightly different, depending on whether the tenant will have VPN backhaul to the customer network for services or applications. The supported combinations for managing your tenant desktops with vcenter are the following: Table 3 1 vcenter used as Hypervisor Manager Supported (Y) and Non-supported (N) Configurations ESXi 4.0 ESXi 4.1 ESXi 5.0 ESXi 5.1 ESXi 5.5 ESXi 6.0 vcenter v 6.0 U3 N N N N Y Y vcenter v 6.0 U2 N N Y Y Y Y vcenter v 5.5 U3* Y Y Y Y Y N vcenter v 5.5 U2 Y Y Y Y Y** N *Recommended: upgrade to ESX 5.5 Update 3b **Strongly recommended: upgrade to vcenter 5.5 U3 to manage ESXi 5.5 U3 hosts Discovery and Assignment Configure an account in the vcenter for the DaaS platform to manage the virtual resources via the vsphere API. Discover one or more vcenter servers for Tenant desktops. Assign one of these vcenters to the Tenant Desktop Manager via the Service Center Service Grid. There is a limit of 1 vcenter per Desktop Manager. Note: You can use the same vcenter for both your management appliances and tenant desktops or you can use separate vcenters for each. If you are using the same vcenter, all the hosts required for management appliances and tenant desktops must be in the same vcenter DataCenter. Important: The datastores configured on each vsphere ESXi or cluster within a vcenter Datacenter must be the same. Shared storage is required for desktop VMs. In order for this to work properly, datastores must be created and mapped to the same LUNs on all the desktop hosts for a particular tenant with the same datastore name (case sensitive) (Optional) Configure NetApp VSC Plug-in If you are using the NetApp VSC plugin for vsphere, it must be installed on the same machine as the vcenter server. Supported versions of the NetApp VSC plugin are 4.1.P1 and When registering the VSC plugin with vcenter, use the vcenter administrator account credentials, which will also be used to discover the desktop hypervisor later in this section of the document. For further information please refer to the NetApp VSC installation and configuration guide Enterprise Network Connectivity VPN/MPLS. If the tenant requires backhaul then configure VPN access (IPSEC Tunnel, MPLS Circuit) from the tenant network back to the customers network that houses, for example, their AD, DNS, and DHCP as well as any other applications required by the virtual desktop users. 42

51 Tenant Installation vcenter Tenant Network Configuration Define the tenant network. If the tenant has backhaul, work with the tenant to identify an internal subnet that is not in use in their infrastructure to be used for the virtual desktops. Otherwise assign an appropriate subnet to the tenant network. Add VLAN(s), VXLAN(s), or a Distributed Virtual Port Group (DVPG) to the tenant. At least one of these must be the Tenant Network. Assign at least one of the added network(s) to the Desktop Manager via the Service Grid in the Service Center. These networks will be used to ensure desktop isolation and may be shared across multiple Desktop Managers. Important: DVPG must be configured to use ephemeral port binding DNS Configuration Define or install a DNS server for the tenant. There must be a DNS server available from the tenant network which can be used to resolve the name of the domain so that the tenant can authenticate Allocate Tenant IP Addresses A minimum of 3 IP addresses should be allocated on the tenant network. Additional IPs will need to be allocated for scenarios where multiple Desktop Managers are required. 2 IPs for the Management Appliances themselves 1 IP to be shared between the Appliances (Optional) 1 IP if the tenant has backhaul to a DHCP server. This will be used for the DHCP relay service Define or install DHCP service for the tenant. A DHCP helper/relay is required to deliver the DHCP requests over the VPN tunnel to the tenant network. This can be done directly on the switches to which the hosts are attached or if not possible, a small Linux appliance can be configured in the tenant to perform this function. Configure the DHCP scope for the desktop subnet, starting at x.x.x.30. Configure DHCP option code 74 (IRC Chat) to point to the two IPs allocated for the tenant appliances. For example, if you are using a Windows server to provide DHCP service: a. Open the DHCP configuration client from Control Panel > Administrative Tools. b. Right-click Server Options and select Configure Options from the pop-up menu c. If you have defined limited address scopes, you can confine the options configuration to a particular scope. Click on the scope and right-click on Scope Options to configure the 074 option code for that scope only. Configuration is the same as for the whole DHCP server. d. Scroll down to the 074 option for Internet Relay Chat (IRC) and check the box. e. Add IP addresses for tenant appliances 43

52 Tenant Installation vcenter Active Directory Configuration Define or install tenant Active Directory. The tenant must configure their Active Directory as shown below and have the information ready to be used during the installation. It is highly recommended that you confirm the values using an AD tool such as AD Explorer: Table 3 2 Network Information for DaaS Management Host Field NETBIOS Name DNS Domain Name Protocol Bind Username Bind Password Port Domain Controller IP Context Description Active Directory domain name Fully qualified Active Directory domain name LDAP or LDAPS, depending on your Active Directory setup Domain administrator Domain administrator password The defaults for this field are: LDAP -> 389 and LDAPS -> 636. You should not need to modify this field unless you are using a non-standard port. (Optional) Specify a single preferred domain controller IP address if you want AD traffic to hit a specific domain controller. This field is auto-populated based on the DNS Domain Name information provided earlier SSL Certificate If the tenant requires a certificate, the customer must provide the service provider with the necessary certificate files in Apache SSL format. For more details, see Apply Tenant Certificates to Tenant Appliances About File Shares File shares are used to allow the import of AppStacks and customization information. There are two types of file shares: Application file shares can be used to import AppStacks. AppStacks are created using AppCapture. A Customizations file share contains the configuration files for a user's custom experience (for example, mounting a network drive). Some things to note: File shares can be in the same domain as the Active Directory that is added to Horizon DaaS Platform. They can also be part of a CIFS share. Horizon DaaS Platformmust have read permissions on your file shares. AppStacks which are already present in the file share are imported automatically when the file share is added. For more information, see the Administration console help. Note: Once you create a file share, you cannot remove it. If you entered the wrong file path, just edit the file share from the Administrator console and import it again. 44

53 Tenant Installation vcenter 3.3 Tenant Installation Overview To install the tenant, you complete the following tasks: 1. Create tenant appliances. 2. Add desktop host(s). 3. Assign tenant appliances to resource managers. 4. Assign quota. 5. (Optional) Enter the Tenant s Active Directory information Create Tenant Appliances 1. In Service Center, select tenants > register a tenant. The Register a tenant page displays. 2. On the General Info tab, the only required fields are the Tenant Name, Administrator Name, and Database Password. Enter this information and any of the non-required field data you want to maintain. 3. On the Networks tab, next to the data center drop-down, click Add and enter values for the fields listed in the table below (for both primary and secondary). The default networking option is to use VLANs mapped to virtual networks on each of the vsphere hosts. When using vcenter there is an option of using distributed virtual switches (DVS). This is an install time decision and cannot be changed after the tenant has been installed. Table 3 3 Data Centers Field Sample Value Notes Network ID 115 VLAN ID, VXLAN ID, or DVPG Name Network ID Type VLAN VLAN, VXLAN, or DVS Network Label My Network Free Form Text Field Gateway DNS Name Directory Name server Subnet mask On the Custom Fields tab, enter any site-specific information you want to maintain. These are freeform text fields with no data validation; the content is entirely up to you. 5. After entering your information on the General Info, Networks, and Custom Fields tabs, select Save and Create Appliances. 6. On the Tenant Install page, enter values for the fields listed in the table below (primary and secondary). 45

54 Tenant Installation vcenter Table 3 4 Schedule Tenant Creation Field Sample Value Notes Primary Name TenantNode1 User-friendly name Primary IP Secondary Name TenantNode2 User-friendly name Secondary IP Floating IP Address Start Date/Time 7. Wait for the system to spawn your tenant appliances (time will vary depending on infrastructure). If you want to check the status of a reservation, select appliances > reservations. 8. Verify that the appliances were created Add Desktop Compute Resources Note: If you are using the same vcenter to host your management appliances and tenant desktops, you do not need to complete this section. This is because you have already discovered the vcenter when setting up your management appliances. Instead, continue to Assign Resources to Tenant below. If you are using separate vcenters for management appliances and desktop hosts, you must complete this section to add a physical desktop host for the tenant desktops. This host will be used for: Importing your initial starter desktop Hosting your pools 1. In Service Center, select service grid > resources to display the Resources screen. The left side of the screen displays three panels: Resource Managers, Desktop Managers, and Compute Resources. 2. Select the Compute Resources panel. The page redisplays with the Add Host Manager tab next to the General tab. 3. Click the Add Host Manager tab and enter values for the fields listed in the table below. Table 3 5 HA Server Field IP Address/Hostname User name Password Resource Manager Sample Value Enter the DNS name or IP address of the Desktop vcenter. Administrator vcenterpsswd Select the tenant resource manager from the drop-down 4. Click the Add button. The system prompts you to accept the certificate for the vcenter. 5. Click Accept. 6. If you have multiple vcenter Datacenters configured, select the one that will be used for the desktop hosts. If you have only one vcenter Datacenter, you will not be prompted to select it. 7. When prompted, accept the certificate. 46

55 Tenant Installation vcenter Note: The assignment of individual ESXi or Cluster resources within this vcenter Datacenter to a particular Desktop Manager will be made after this step (Optional) Configuring the Netapp VSC Plug-in If you are not using the Netapp VSC plugin for storage then skip this section and proceed to the next section entitled Create the Remaining Service Provider Appliances to continue the vcenter install. There is no need to define storage when managing with vcenter in the DaaS platform as this is already configured through the vcenter client. If you are using the Netapp VSC plugin for storage perform the following steps: 1. Service Center, select service grid > resources. 2. Select the Service Provider RMGR in the pane on the left, then Storage Systems in the pane on the right. 3. On the Storage Systems tab, select the Add Storage System link. 4. Enter values for the fields below. Important: When adding a storage system to the DaaS platform, the Address field must match how the VSC plug-in was discovered for vcenter. If the plug-in was discovered as an IP address you must enter the IP address in the Address field. If it was discovered as a FQDN, then you must enter the complete domain name in the Address field. Table 3 6 Storage System Field Sample Value Address storage.desktone.com or Username Password root storagepswd 5. Click the Add Storage System button. The system adds the name of the storage system to the Storage Systems tab Assign Resources to Tenant 1. In Service Center, select service grid > resources. 2. Select the Desktop Managers pane. 3. Select the appropriate Desktop manager listed in the Desktop Managers panel by clicking on the name in the tree. Note: You may need to click refresh if the expected Desktop Manager is not present. 4. Click on the Compute Resources tab, and click assign on the vcenter you have setup for the Tenant Desktops 5. A list of both clusters and ESXi hosts will be displayed. Select one or more of the desired compute to be assigned to the Desktop Manager. Click OK when done. 6. For each selected compute resource, a capacity popup will be displayed. Review the overallocation settings and click Save if satisfactory. Note: If the server capacity is not enough to meet the current usage base on overallocation, you will need to increase overallocation or decrease the amount of VMs on the compute. 47

56 Tenant Installation vcenter Assign Networks to Desktop Manager(s) 1. In Service Center, select service grid > resources to display the Resources screen and select the Desktop Managers tab 2. In the tab, you will find the desktop managers listed as <tenant name>_<desktop manager name>. Click on the Desktop Manager in question and select the Networks tab. Note: This tab will only be displayed once Compute Resources have been assigned and will only display networks that are available across all assigned compute resources. If you do not see a network that you expect, validate that the network is available and labelled correctly across all compute resources. 3. Click assign on at least 1 network. The assigned networks effect what VMs will be detected as belonging to the Desktop Manager Configure Datastores The Datastores tab is used to specify datastores for your system to use. Procedure 1. In the Service Center, select service grid > resources to display the Resources screen and select the Desktop Managers tab 2. In the tab, you will find the desktop managers listed as <tenant name>_<desktop manager name>. Select a desktop manager and then select the Datastores tab. 3. Double-click in the appropriate field (Desktop Storage, Appstack Regex, Writable Regex). 4. Enter a regular expression for the name(s) of the datastore(s). Note: In order for a datastore to be added, it must first be configured on a Compute Resource Assign Desktop Model Quotas 1. In Service Center, select tenants > browse tenants. 2. In the table, click Edit for the tenant which you wish to alter, the Editing Tenant page displays. 3. Select the Quotas tab. This panel displays all of the controlling Quotas which regulate what a Tenant is allowed to use at provisioning and desktop connection time. Included are the Protocol Quotas, Gold Pattern Quotas, RDS Session Quotas, and Desktop Model Quotas. Desktop Model Quotas are assigned by Desktop Manager and will be calculated based on assigned compute and its associated population density (# of VMs). 4. Select the Datacenter & Desktop Manager from the drop downs which you wish to assign Quota to. Add the amount desired to the VM Quota Column. Click Update and a status window will appear after Quota assignment. Note: You must enter a number that is at least as large as the In Use amount Assign Protocol Quotas 1. In Service Center, select tenants > browse tenants. 2. In the table, click Edit for the tenant for which you are applying the tenant model. The Editing Tenant page appears. 48

57 Tenant Installation vcenter 3. Select the Quotas tab. The Quotas tab displays a table listing all the protocol quotas available. 4. If there are more than one datacenter for this Tenant, select the Data Center to which you wish to assign Quota from the drop-down. 5. Under the Protocol Quota section, enter a value in the Quota column or select the Unlimited checkbox. This Quota will be applied across the Tenant in a given Datacenter. 6. Click Update and a status window will appear after Quota assignment Set Up Desktop Connection Via Access Point Note: You cannot deploy an Access Point VM from a vsphere Windows client. You must deploy it from the vsphere web client. 1. Download the latest version of the Access Point OVA file. 2. Determine the IP addresses (DNS/Netmask/Gateway) for the required networks, as described below. Configuration Networks 3 NIC Internet Any network with internet access Management Backend This can be your 169 network. Since this does not have its own DNS or Gateway, you can enter any numbers for DNS and set the netmask to Network that the Tenant uses for desktops 2 NIC Internet Network the Tenant is on Management This can be your 169 network. Since this does not have its own DNS or Gateway, you can enter any numbers for DNS and set the netmask to NIC Internet Network that the Tenant is on 3. In the vsphere web client, follow the normal method for deploying a template. On the Properties page, enter information as shown below. Field Root Password Admin Password Locale Value Enter initial password for root user. Password must be at least eight characters long and must contain: At least one upper case letter At least one lower case letter At least one number At least one special character #, etc.) Enter password to be used for REST API Admin user en_us 49

58 Tenant Installation vcenter Settings JSON View Destination URL View Destination URL Thumbprints View Proxy Pattern DNS Internet IP Address Management Network IP Address Backend Network IP Address Leave blank Leave blank Leave blank Leave blank Enter DNS of Internet network Enter Internet Network IP address from the previous step If configuration is 3 NIC or 2 NIC, enter Management Network IP from the previous step. If configuration is 1 NIC, this item does not display. If configuration is 3 NIC, enter Management Network IP from the previous step. If configuration is 1 NIC or 2 NIC, this item does not display. 4. Power on the VM and wait for the login screen to appear on the console. 5. On the tenant appliance, run the following command: sudo /usr/local/desktone/scripts/apsetup.sh 6. Enter the requested information for the Access Point appliance. The response status returned will indicate whether the configuration was successful. Response status Result 200 Configuration successful 400 Invalid input 401 Password incorrect. Confirm that password matches admin password configured during OVA deployment 000 Network connection failure. Confirm that IP address matches management IP address configured during OVA deployment 7. Configure NAT and firewall rules to allow access to the Access Point appliance through Internet network. Note: When using an edge gateway load balancer the NAT for ports 80 and 443 are not required. These ports are forwarded automatically. Port 4172/tcp, 4172/udp 8443/tcp 443/tcp Usage PCoIP desktop access protocol HTML desktop access protocol Secure web portal access 80/tcp Insecure web portal access (will be redirected to 443) 50

59 Tenant Installation vcenter Enter the Tenant s AD Information Omit this step if the tenant will be entering their own AD information. Tenant AD information is entered in the administration console. For more information see the tenant setup and administration documentation. If you do not use a domain admin account for the Service Account then you must set the tenant policy fabric.ad.validatesysprepuserprivs to false Apply Tenant Certificates to Tenant Appliances The DaaS platform allows you to upload custom SSL certificates for each tenant. If the tenant does not already have a certificate, you may generate it following the instructions in section below. If it already has a certificate, proceed directly to section Generate Tenant Certificates You can generate the tenant s CSR file (certificate signing request) either on the Service Provider appliance or the tenant nodes. If generating on the Service Provider appliance, please be sure to create in a tenant specific directory so files are not confused among tenants. Always name the file using the domain for which the cert is being generated. Procedure 1. Collect the following information for the tenant: Country Code State and Locality Full Legal Company Name Organizational Unit 2. At the command line run openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr where server is the domain you want to create a cert for - such as desktops.tenant.com This will generate two files: the Private-Key file for the decryption of your SSL Certificate, and a certificate signing request (CSR) file (used to apply for your SSL Certificate) with apache openssl. 3. When you are prompted for the Common Name (domain name), enter the fully qualified domain name for the site you are securing. If you are generating an Apache CSR for a Wildcard SSL Certificate your common name should start with an asterisk (such as *.example.com). 4. Once the.key and.csr files are created, zip them up and send them to the customer so they can request a cert from a certificate authority. 5. Copy the files to /usr/local/desktone/cert on the tenant node so they are backed up by the automated backup process. 51

60 Tenant Installation vcenter Apply Tenant Certificates The DaaS platform allows you to upload custom SSL certificates for each tenant. To enable a custom certificate, you upload three certificate files in Apache format: SSL Certificate, SSL Key, and CA Certificate. The tenant might provide you with all three files. Or, to ensure the files are generated properly, you can generate the public and private keys yourself, forward these keys to the tenant, and then the tenant can request the signed certificate from the signing authority. Note: To upload the three certificate files, you navigate to the Certificates tab under tenants (this is a different Certificates tab than the one used for service providers). Procedure 1. In the Service Center, select tenants > browse tenants. 2. On the Tenants screen, click Edit for the tenant. 3. Click the Certificates tab. 4. On the Certificates tab browse for and select the following three files: CA Certificate: The public certificate from a certificate authority that was used to sign the tenant certificate. This file will have a.pem or.crt extension. SSL Certificate: The tenant s public certificate, which was signed by the CA. This file has a.crt extension, which indicates that it is a certificate file. SSL Key: The private key used to decrypt the tenant s SSL certificate. This is needed in order to be able to respond to certificate requests. This file has a.key file extension. 5. Click Submit to upload the files. You can upload the files before or after installing appliances: Before: The certificate is automatically installed on all the tenant appliances when you click the Submit button. After: Click the link on the Certificates tab to install the certificate on the tenant appliances. Note: If the IP address or URL for the tenant s desktop portal does not resolve to the tenants CN in their certificate, the tenant administrator may wish to include in their certificate a Subject Alternative Name so that the desktop portal s URL accessed by web clients can be matched to the uploaded tenant certificate. For more details on how to add a Subject Alternative Name to the certificate, contact the certificate authority. Backing Up: Copy the files to /usr/local/desktone/cert/temp on the primary Tenant appliance so they are backed up by the automated backup process. Upgrading: If you are upgrading to the latest release of the DaaS platform, your existing certificates are not automatically imported. Make sure you have a backup copy of the three files so that you can upload them again Extending a Tenant Across Datacenters Note: You must have already created another Datacenter before you can extend a tenant to that Datacenter. See Installing Multiple DaaS Datacenters for instructions on creating a second datacenter Adding a Network Component 1. In Service Center, go to the Tenants page and click the Edit button for the Tenant to be extended. 2. On the Networks tab, select the required datacenter in the Data Center dropdown. 52

61 Tenant Installation vcenter 3. Click the Add Network Component link. 4. Enter values for the fields listed in the table below. Note: The extended tenant must be placed on a different network than the tenant in the first datacenter. Table 3 7 Network Component Field Sample Value Notes Network ID Type VLAN VLAN, VXLAN, or DVS Network ID 118 VLAN ID, VXLAN ID, or DVPG Name Network Label My Network Free Form Text Field Gateway Subnet mask DNS Name Directory Name server (Usually the same as the DC1 tenant) 5. After entering your information, select Add Network Component Adding Appliances 1. On the Appliances tab, select the Add Appliances link. 2. Select the required datacenter in the Data Center dropdown. 3. Enter values for the fields listed in the table below. Table 3 8 Tenant Install Field Sample Value Notes Primary Name TenantNode1 User-friendly name Primary IP Address Secondary Name TenantNode2 User-friendly name Secondary IP Address Floating IP Address Start Date/Time 4. Wait for the system to spawn your tenant appliances (time will vary depending on infrastructure). If you want to check the status of a reservation, select appliances > reservations. 5. Verify that the appliances were created. 6. Return to Add Desktop Compute Resources above and follow the steps to complete the extended tenant setup. 53

62 Tenant Installation vcenter 3.4 Creating a Windows 7 Gold Template Before defining a VM as your gold template you need to create your template. We strongly recommend against using a P2V (physical-to-virtual) conversion tool. Instead a new OS install should be customized to VDI best practices. There are numerous online publications on Windows 7 VDI best practices, such as The following steps must be part of the VM preparation 1. Install VMWare tools and verify NIC settings: a. From vcenter UI, right click the VM. b. Select Guest > Install/Upgrade VMWare tools. c. Select Edit Settings > Network Adapter. d. Confirm adapter type is VMXNET3. 2. Enable Administrator account & confirm RDP access: a. Right click Computer and select Manage. b. Select Local Users and Groups. c. Select Users. d. Right click the Administrator user and select Properties. e. On the General tab, uncheck account is disabled. f. On the Member Of tab, confirm Administrator is a member of Remote Desktop Users g. Set Administrator Password 3. Install DaaS Agent by copying the DaaS Agent msi onto your VM and running the install. The DaaS Agent must be configured to point at the tenant appliances. This can be done 1 of 2 ways: DaaS Agent Discovery: The tenant appliance addresses can be automatically discovered by the DaaS Agent via DHCP by utilizing option code 74. The configuration of this option is described in section 2.7. Update of DaaS Agent configuration file: The tenant appliance addresses can be manually updated in the DaaS Agent configuration file. Open the file C:\Program Files (x86)\daas Agent\service\MonitorAgent.ini with a text editor like notepad (note: on 32-bit systems the path will be exclude the (x86) ). Remove the semi-colon on the line containing the parameter standby_address and provide a comma separated list of the tenant appliance IP addresses. A restart of the DaaS Agent Windows service is required after making this change. 4. Install the PCoIP protocol a. Install VMware Horizon Agent (see Install Horizon Agent above). b. Apply PCoIP GPO (.adm file) and configure protocol settings as appropriate 5. Join VM to domain and add the appropriate domain groups to Remote Desktop Users group. 6. Set power options for the VM to HIGH Performance: a. Select Control Panel > System and Security > Power Options. b. Select High Performance. 54

63 Tenant Installation vcenter 7. Confirm Windows firewall is disabled, or at least the necessary ports are configured. 8. Confirm Windows Updates are current. 9. Optional: Log in as Administrator and remove all other accounts on the VM. 10. (Optional if users connect through other browsers): Confirm Remote settings are not using NLA NLA may interfere with IE users trying to connect to their desktops: a. Right click Computer and select Properties. b. Select Remote Settings. c. Select Allow connections from computers running any version of Remote Desktop 11. Optional: Disable Ctrl-Alt-Del Secure logon. Some protocols (and users) struggle with entering CTRL- ALT-DEL to log into their VM. To disable this: a. Run netplwiz b. Select Advanced Tab c. Uncheck Require Users to press CTRL-ALT-DEL 12. Install the appropriate protocol drivers if you choose additional protocols beyond RDP. Once your VM is configured as you wish with the appropriate software you can begin the conversion process note: VM must exist on the same host, storage and VLAN mapped to the tenant. Confirm the VM has been imported into the Administration console. 55

64 Tenant Installation vcenter Tenant Installation Worksheet The following table lists the fields you will need to specify in the Service Center when installing a tenant. The fields are listed in the order they must be provided during the installation. Tenant Installation Fields in Service Center Field Values Sample Value / Notes Tenant VLAN/VXLAN ID 115 Tenant Gateway Tenant DNS Name (AD server) Tenant Subnet mask Primary Tenant Appliance Name Primary Tenant Appliance IP Address Secondary Tenant Appliance Name Secondary Tenant Appliance IP Address TenantA-Node TenantA-Node Floating IP Address Tenant Host/Server IP Address Tenant Host/Server User name Tenant Host/Server Password Tenant Storage System Address Tenant Storage System Username Tenant Storage System Password Name of Tenant Directory to Mount Tenant Remote Mount Point DNS name or IP of host HostMgtAcct hostpsswd storage.sp.com rootaccessact storagepsswd tenantanfs /vol/tenanta Optionally, if you are configuring the Tenant Active Directory, you will also need to collect the following: Tenant Installation Fields in Service Center Field Values Sample Value / Notes Active Directory (AD) Name Domain AD Protocol TENANT tenant.com ldaps AD Port 636 Nameserver Context Service Account Password dc=tenant,dc=com CN=Administrator,CN=Users TenantAPsswd 56

65 Tenant Installation vcenter Admin Group User Group Admin User Password cn=enterprisecenteradmin,ou=groups cn=portalusers,ou=groups Administrator AdminPsswd Primary DNS

66 Service Provider Installation vcenter 4 Service Provider Installation vcenter 4.1 Overview This guide provides you with information on how to install and configure the DaaS platform Service Provider appliances using vcenter discovery of the management compute resources. In this installation, you complete the following: 1. Install the first Service Provider appliance 2 in the first datacenter. 2. Bootstrap the Service Provider appliance. Once bootstrapped, the Service Provider Appliance provides the foundation to install the remainder of the DaaS application. 3. Start the Service Center on the DaaS Management Appliance and configure the Service Provider environment. Create a second Service Provider appliance for high availability (HA). The Service Center provides a web-based UI for managing data center resources (hosts, storage, and the DaaS management appliances). You also use the Service Center to manage tenant contracts, configure tenant appliances and networks, and create and assign roles and permissions. 4.2 Service Provider Prerequisites Before you can install the DaaS platform, you first need to complete the tasks listed in this section. Contact your customer service representative for help with any of these prerequisites. You will also need the Service Provider Installation Worksheet and Platform Install Checklist found in the System Blueprint to help organize and collect all the information needed to complete the install. 2 A DaaS appliance is a virtual machine combined with a functional unit of software in the DaaS platform. The Service provider appliance provides two types of access to the system: via the Service Center web based UI; as a transit point for enabling ssh access to all the management appliances in the data center. 58

67 Service Provider Installation vcenter The supported combinations for managing your management appliances and tenant desktops using VMware vcenter hypervisor management software are the following: Table 4 1 vcenter used as Hypervisor Manager Supported (Y) and Non-supported (N) Configurations ESXi 4.0 ESXi 4.1 ESXi 5.0 ESXi 5.1 ESXi 5.5 ESXi 6.0 vcenter v 6.0 U3 N N N N Y Y vcenter v 6.0 U2 N N Y Y Y Y vcenter v 5.5 U3* Y Y Y Y Y N vcenter v 5.5 U2 Y Y Y Y Y** N *Recommended: upgrade to ESX 5.5 Update 3b **Strongly recommended: upgrade to vcenter 5.5 U3 to manage ESXi 5.5 U3 hosts. Build the network infrastructure required to support multi-tenancy, typically accomplished with: VLAN tagging for network separation at layer 2. VRFs to isolate tenants and allow for a separate routing table per tenant. The configured VLANs must be the same across all management hosts. In vcenter, there is an additional option of using distributed virtual switches (DVS). By integrating either the VMware vsphere Distributed Switch or the Cisco Nexus 1000V with vcenter, separation can be accomplished using distributed switch port groups. The port group must be configured to use ephemeral port binding. See System Blueprint for more details. 4. Allocate at least two ESXi hosts or at least one cluster for DaaS management appliances. Install a vcenter management server meeting the version requirements. The ESXi hosts or cluster allocated for DaaS management appliances should be in the same vcenter Datacenter. All ESXi hosts should have the compute (RAM, CPU, local disk) required to meet expected Tenant Appliance density. Please reference the DaaS Blueprint for more details. Note: Single and Multiple vcenter(s) may be used to satisfy both desktop and appliance needs. If you are using the same vcenter, all the compute resources required for management appliances and tenant desktops must be in the same vcenter Datacenter. 5. Provide an account to access the hypervisor manager API. On the vcenter, configure an account which can be used for the DaaS platform to manage the virtual resources via the vsphere API. This account must have appropriate privileges. 6. Assign one subnet to the service provider network. This subnet also needs to have access to the API of the hypervisors. 7. Assign service provider network. Assign a VLAN, a VXLAN, or a Distributed Virtual Port Group (DVPG) to the service provider network. This VLAN or DVPG must map to a virtual network assigned to all management hosts. 8. Assign a network to be used for DaaS platform management traffic. Assign one VLAN (non-routable subnet), one VXLAN, or one Distributed Virtual Port Group (DVPG) as the Link Local Network. 9. Allocate link-local addresses. For a typical data center, it is recommended that you use a /22 network (for example, /22). However, a demo environment or small data center can use a /24 network. You should not use anything smaller than /24. 59

68 Service Provider Installation vcenter Note: If you have more than one data center, the link-local address space must be unique (nonoverlapping) across data centers. A link-local address is an IP address used only for communications within a link (segment of a local network) or a point-to-point connection to which a host is connected. Routers do not forward packets with link-local addresses. The address block through is reserved for linklocal addressing in Internet Protocol Version 4. You cannot choose addresses outside this range. Refer to Internet Engineering Task Force (IETF) RFC 3927 for more information. 10. Allocate storage for management appliances. By default, the DaaS platform will clone out management appliances on local disk (via a local datastore). This is considered a best practice. However, if desired, it is possible to use shared storage for management appliances. If using shared storage for management appliances on vcenter there are a few guidelines: Any shared storage (NFS, iscsi, or FC) can be used. Ensure that the appropriate configuration has been done (e.g. LUN masking, zoning, etc.) to allow one or more LUNs to be mapped to all of the management hosts. The DaaS platform will use the native vcenter cloning APIs to provision management appliances using FC or iscsi. In order for this to work properly, datastore(s) must be created and mapped to the same LUN(s) on all the management hosts with the same exact name (case sensitive). Datastores must be manually created on each of the management hosts. The datastore name must be identical (case sensitive) on each management host. NFS Storage Requirements If you are using NetApp, Isilon, or Nexenta storage for DaaS management appliances, create an account on the storage system for access to the storage system APIs. If you are using the NetApp VSC plugin for vsphere, it must be installed on the same machine as the vcenter server. Supported versions of the NetApp VSC plugin are 4.1.P1 and When registering the VSC plug-in with vcenter, use the vcenter administrator account credentials, which will also be used to discover the management hypervisor later in this document. For further information please refer to the NetApp VSC installation and configuration guide. 11. DNS Configuration There must be a DNS server available from the Service Provider (SP) network which can be used to resolve the name of the domain so that the Service Center can authenticate. Confirm all vsphere servers are defined in the DNS and that the hosts and storage systems are configured locally with the matching DNS name as well. 12. IP Address Allocation Allocate five IP addresses in the SP network: two for the Service Provider appliances plus one for the shared floating IP and two for the Resource Manager appliances. If the Service Provider wants to access the Service Center using a hostname instead of an IP address, setup a DNS record to point to the floating IP address of the Service Provider appliance pair. 13. NTP Configuration There must be at least one NTP server available from the SP network to allow for time synchronization. 14. Active Directory Configuration There must be an Active Directory accessible on the SP network for authentication. Have available the information listed in the table below to configure the domain for the Service Provider. It is highly recommended that you confirm the values using an AD tool such as AD Explorer. You can download AD Explorer with the following link: 60

69 Service Provider Installation vcenter Table 4 2 Network Information for DaaS Management Host Configuration NETBIOS Domain Suffix Protocol Example SP sp.desktone.com Ldap Port 389 Context Primary DNS Server IP and name Service Account Used to parse your AD structure through a standard LDAP query - may be read only Service Account Password Super Admin (Service Center Access) Admin Level1 (Optional) Admin Level2 (Optional) 15. SSL Certificate dc=sp,dc=desktone,dc=com (You only need to specify one Domain Name Server the rest should be automatically identified) CN= Administrator,CN=Users (UserMustChangePassword = false, Password Never Expires) (Do not include the context in the service account name) ADPasswd cn=serviceprovideradmin,ou=groups (do not include the context) cn=admin-1,cn=admins,ou=groups cn=admin-2,cn=admins,ou=groups Provide an SSL Certificate in Apache2 format to install for a valid certificate. For more details, see Apply Service Provider Certificate Files to Service Provider Appliances Required Files Make sure you have all the files listed in the table below before you begin the installation. Contact your support representative for the necessary files. Table 4 3 Required Files File Contents Appliance Template Debians* DaaS Agent Access Point File(s) CopperTemplate7_0_0_ ova dt-platform-7_0_0.deb cloud-connector-client_1.2.0.deb av-manager dornfc.deb dt-keybox_ deb dt-aux-7_0_0.deb xmp dornfc.deb wem-service-rbac deb VMware-DaaS-Agent msi Latest version of.ova file * Three of the.deb files listed cloud-connector-client, av-manager, and wem-service-rbac are associated with products not supported in the current release of Horizon DaaS Platform. The system requires that these files be installed for other reasons, not to support the corresponding features. 61

70 Service Provider Installation vcenter 4.3 Bootstrap Primary Service Provider (SP1) Appliance Important: If you have already installed your first Datacenter and now need to install an additional Datacenter, see Installing Multiple DaaS Datacenters Prepare Storage Configuration on Both Management Hosts On both management hosts, add the Service Provider datastore. Be sure to use the same name on each host. Warning: The name you use in vsphere for the storage needs to be exactly the same on each host and will be entered into the platform as part of Section Deploy the DaaS OVA File On a DaaS Management Host, using the vsphere client, deploy two copies of the DaaS ova file. The first copy becomes the primary Service Provider (SP1) appliance upon completion of the bootstrap process. The second copy becomes the template for all subsequent DaaS management appliances. Note: Make sure that you have downloaded the DaaS ova file (Appliance Template) specified in section 2.1. You need to locate the file on a Windows drive accessible by the vsphere client in order to deploy it from the vsphere client. vsphere cannot natively mount a Linux partition or connect to an NFS share. 1. Start the vsphere client. 2. Select File > Deploy OVF Template to deploy the first copy of the ova file, which becomes the first Service Provider appliance. The vsphere client launches the Deploy OVF Template wizard. The wizard has six steps. After completing each section, click Next. a. Source: Browse for the.ova file you downloaded. b. OVF Template Details: Click Next to skip this step. c. Name and Location: Rename the VM with the name of the Service Provider Appliance you defined in the Service Provider Installation Worksheet, for example DatacenterName-sp1. d. Storage: Deploy the SP1 Appliance to local/shared storage on one of the two management hosts. e. Disk Format: Click Next to skip this step. f. Network Mapping: The first column lists the two Source Networks. For each, select a Destination Network. The first network (VM Network) should point to the Service Provider Network. The second network (Dev Network) should point to the Link Local Backbone Network. g. Ready to Complete: Click Finish. A dialog indicates the status of the deployment. 3. Select File > Deploy OVF Template again to deploy the second copy of the ova file, which becomes the template for all subsequent DaaS management appliances. In the wizard, specify the source of the ova file (the same as in Step 2a), a name that distinguishes the file as the DaaS management appliance template, the service provider local/nfs storage, and the destination network (as defined in the previous step). We recommend you preface the name of your data center to the beginning of the appliance template name, for example DatacenterName-template. The name of the template must be unique across all datacenters. Also make sure that the password you enter in the wizard is that same as the one you entered for the first copy of the file. 62

71 Service Provider Installation vcenter Run the Bootstrap Script to Configure Network on SP1 Appliance Run the bootstrap script to configure the network on the Service Provider appliance. 1. From the vsphere client, power on the SP1 appliance and open the console window. 2. Login using User: desktone Password: Desktone1 (default template password) Note: For greater security, you should specify a custom appliance password when prompted by the bootstrap script. Each datacenter can have its own unique appliance password. 3. Begin the bootstrap process by executing the following command: sudo /usr/local/desktone/scripts/bootstrap.sh 4. The bootstrap script prompts you to enter network information for the fields listed in the table below. The values shown are sample values only; enter the values you noted in the Service Provider Installation Worksheet and Platform Install Checklist found in the System Blueprint. After you finish entering the network information, the host reboots. It might take five minutes for the appliance to start after reboot. Because the node is not configured until the reboot completes, disregard any error messages displayed on the console. 5. After the host reboots, you can login via putty or any other ssh terminal you choose. Table 4 4 Installing the First Datacenter: Network Information for DaaS Management Host Field Sample Value Notes Accept EULA agreement? Existing multidatacenter setup Datacenter name yes no CityOfFirstDC If the EULA agreement is not accepted the bootstrap script will exit. This is asking are you building a new environment or joining an existing one. Select no to install the first datacenter. IP for eth1 (backbone) Netmask CIDR format (0-32) For the Backbone network (must be a link-local address) 22 For the Backbone network IP for eth0 (SP) For the SP network Netmask CIDR format (0-32) 24 For the SP network Gateway For the SP network Hostname (appliance FQDN) SP1.DESKTONE.COM Match the name used for the IP on the SP datacenter. Name server NTP server Enter a value only if you have a time server. Is this an HA Service Provider appliance setup? yes Floating IP Address

72 Service Provider Installation vcenter Field Sample Value Notes psql password dtpasswd Must have at least eight characters and contain at least one each of upper case letter, lower case letter, number, and special character. This alters the psql passwords for admin, master, slave and slony user. The password is not displayed on the screen. Appliance password Does this configuration look correct? mypasswd yes or no. Must have at least eight characters and contain at least one each of upper case letter, lower case letter, number, and special character. The user-defined password for Service Provider appliances in this datacenter. Any Service Provider appliance accessible by ssh requires this custom password. The information echoed back includes two internal values, Data Center UID and VMGR UID, which you can ignore Copy the DaaS Software to the Service Provider Appliance 1. Log into the SP1 appliance via putty (or equivalent), using the following credentials: User: desktone Password: the appliance password you set previously 2. Copy the following files to the /tmp directory on the SP1 appliance. (Do not copy the files to /data/repo at this time.) dt-platform-7_0_0.deb cloud-connector-client_1.2.0.deb av-manager dornfc.deb dt-keybox_ deb dt-aux-7_0_0.deb xmp dornfc.deb wem-service-rbac deb 3. At the appliance command prompt, move the files into the /data/repo directory on the appliance by running the following for each debian file: sudo mv /tmp/<name of debian file> /data/repo Note: You can confirm that you have copied the correct files by doing the following: a. Navigate to repo directory: sudo -i cd /data/www/repo b. Run the following for each debian file: reprepro -A amd64 list precise <debian package name> reprepro -A amd64 list precise dt-platform precise main amd64: dt-platform reprepro -A amd64 list precise dt-aux precise main amd64: dt-aux

73 Service Provider Installation vcenter Run bootstrap Script to Install the DaaS Software 1. Run the bootstrap shell script a second time to install the DaaS software: sudo /usr/local/desktone/scripts/bootstrap.sh System reboots. 2. SSH into the system again and wait for the log file to appear and watch desktone.log file: tail f /var/log/desktone/desktone.log The system is up when you see a message similar to this in the log: Appliance deployed flag set to started 3. Open a browser and log into or whatever IP you supplied for IP for eth0 (SP) above. Note: It might take five minutes for the appliance to start after reboot. Because the node is not configured until the reboot cycle completes, you can disregard any error messages displayed on the console. 4.4 Configure Service Center Start the Service Center 1. Start the Service Center by entering the URL or IP address in a browser. For example: for eth0 (SP)>/service Replace <IP for eth0 (SP)> with the IP address that you specified above. 2. You can safely ignore the warning about the website s security certificate and proceed to the Service Center page Register the Service Provider Domain The first time you access the DaaS Service Center, the Register a domain page displays so that you can provide Microsoft Active Directory domain information. You enter the information on two tabs: Domain Bind and Group Info. This information is required to access Microsoft Active Directory and to authenticate users. Make sure you have the DN information available to register the domains. Important: You must enter all information on both tabs (Domain Bind and Group Info) without letting your browser session expire. If you need to enter the information on the second tab (Group Info) at a later date, make note of the URL of the first tab (Domain Bind) so that you can navigate back to the Register a Domain page 1. On the Register a Domain page, Domain Bind tab, enter values for the fields listed in the table below. Table 4 5 Domain Registration, Domain Bind Tab Field Name Domain Suffix Protocol Directory Server Name Sample Value SP sp.desktone.com Ldap MicrosoftAD (leave this default, you do not need to select a Directory Server Name) 65

74 Service Provider Installation vcenter Port 389 Domain Controller IPs (DNS Server) Context Domain Bind Account DN Password Password Verify dc=sp,dc=desktone,dc=com CN=Administrator,CN=Users (do not include the context) ADPasswd ADPasswd 2. Click Save. 3. On the Register a Domain page, Group Info tab, start typing a value for Admin Groups. The system will offer suggestions for auto-complete. For example, cn=serviceadmins,ou=groups. 4. Click Save. The Service Center login page is displayed. 5. Enter your username, password, and domain then click Login Discover the DaaS Management Server The Discover Management Server page is displayed. Use this page to discover the vcenter Server which holds the DaaS Management Appliance Template (.ova file) you imported. The template is used for creating DaaS management appliances. 1. Enter values for the fields listed in the table below. Enter the IP address or FQDN of the vcenter Server that is hosting the SP1 appliance. Table 4 6 vcenter Management Discovery Field IP Address/Hostname Username Password Sample Value mgvc1.domain.desktone.com root vcenterpasswd 2. Click Discover Server. The system prompts you to accept the certificate for the vcenter. 3. Click Accept. The system indicates it is discovering host and calculating capacity. 4. If prompted, select the vcenter Datacenter that contains the compute resources for DaaS. This vdc should also contain the DaaS Appliance Template (.ova file) that you imported. Note: If you only have 1 vdc, it will be automatically selected and a prompt will not appear. 5. Select the Compute Resource(s) (ESXi hosts or Cluster) you have set assign for DaaS Appliances. These will be used to provision Appliances. Note: A minimum of 2 ESXi hosts is required for high availability (HA). A cluster is considered to be HA on its own. For each selected Compute, a dialog appears. If the server is too small to accommodate the ratios, you may be prompted to re-configure them. 66

75 Service Provider Installation vcenter 6. Make any desired changes to the ratios and/or the Usage setting (Service, Tenant, or Network), and click Save to save the values. 7. After setting the ratios, a VM list will be displayed containing all the VMs from the compute selected as part of step 5. Select the DaaS appliance template from this list. Note: This should NOT be the Service Provider appliance itself, but should be the Appliance.ova that was deployed earlier. Once the system has discovered the appliance template, the Browse Tenants screen is displayed (Optional) Rename Resource Manager 1. In the Service Center, Select service grid > resources. 2. In the Resource Managers panel on the left, click on the IP address of the resource manager. 3. On the General tab, in the Name field, double-click on the IP address of the resource manager. A text box opens in which you can change the name. 4. Change the name to the user friendly name, for example Service Provider RMGR and click OK (Optional) Turn off Local Disk Provisioning If you are installing the DaaS management appliances on shared storage and you intend to deploy and run your management appliances from the shared storage instead of local storage, then you must first change the default behavior of the application: 1. Select tenants > policy to display the Policy Configuration screen. 2. Select Service Provider from the dropdown. 3. Scroll through the list of policies and double click the value to set the vmgr.appliance.local.disk policy to false. 4.5 (Optional) Configuring the Netapp VSC Plugin If you are not using the Netapp VSC plugin for storage then skip this section and proceed to the next section entitled Create the Remaining Service Provider Appliances to continue the vcenter install. There is no need to define storage when managing with vcenter in the DaaS platform as this is already configured through the vcenter client. If you are using the Netapp VSC plugin for storage perform the following steps: 1. Service Center, select service grid > resources. 2. Select the Service Provider RMGR in the pane on the left, then Storage Systems in the pane on the right. 3. On the Storage Systems tab, select the Add Storage System link. 4. Enter values for the fields listed in the table below. Important: When adding a storage system to the DaaS platform, the Address field must match how the VSC plug-in was discovered for vcenter. If the plug-in was discovered as an IP address you must enter the IP address in the Address field. If it was discovered as a FQDN, then you must enter the complete domain name in the Address field. 67

76 Service Provider Installation vcenter Table 4 7 Storage System Field Address Username Password Sample Value storage.desktone.com or root storagepswd 5. Click the Add Storage System button. The system adds the name of the storage system to the Storage Systems tab. 4.6 Create the Remaining Service Provider Appliances DaaS requires that Service Provider management appliances be installed as High Availability (HA) pairs. To ensure physical hardware high availability, HA DaaS Management appliance pairs are distributed across two physical DaaS Management Hosts. With vcenter, the appliances are automatically distributed to the management hosts you selected in Section Create HA Service Provider (SP2) Appliance 1. Select service grid > data centers. 2. Click the Edit button (at end of line for new data center). The system displays the Edit Data Center popup. 3. Verify the displayed information and click Add Appliances. The Appliance Install screen displays. 4. Select Service Provider Appliance from the Appliance Type drop-down and enter values for the fields listed in the table below. Table 4 8 Secondary Server Field Sample Value Notes Name SP2 Do not use fully qualified domain name. IP Address Enter values for the New Reservation fields listed in the table below. Table 4 9 New Reservation Field Sample Value Notes Friendly Name Create SP2 Start Date Start Time Select Today from the drop-down or enter the month, day, and year. Enter 00:00 to indicate now, or the actual time in UT format. 6. Click Create Appliance. If you want to check the status of a reservation, select appliances > reservations. 68

77 Service Provider Installation vcenter Apply Service Provider Certificate Files to Service Provider Appliances The DaaS platform allows you to upload custom SSL certificates for each service provider appliance. To enable a custom certificate, you upload three certificate files in Apache format: SSL Certificate, SSL Key, and CA Certificate. Note: To upload the three certificate files, you navigate to the Certificates tab under configuration (this is a different Certificates tab than the one used for tenants). Procedure 1. In Service Center, select configuration > general. 2. Select the Click here link. 3. Click the Certificates tab. 4. On the Certificates tab, browse for and select the following three files: CA Certificate: The public certificate from a certificate authority that was used to sign the service provider certificate. This file will have a.pem or.crt extension. SSL Certificate: The service provider s public certificate, which was signed by the CA. This file has a.crt extension, which indicates that it is a certificate file. SSL Key: The private key used to decrypt the service provider s SSL certificate. This is needed in order to be able to respond to certificate requests. This file has a.key file extension. 5. Click Submit to upload the files. 6. Select the Click here link to install the certificate on the service provider appliances. To get the SSL Certificate file the service provider administrator should submit a certificate sign request to their certificate authority. Their certificate authority will provide the administrator with a certificate file (.crt) which can be provided to the DaaS service provider to be uploaded. For more information on how to get a signed certificate, contact the certificate authority. Note: If the IP address or URL for the Service Center does not resolve to the service provider CN in their certificate, the service provider administrator may wish to include in their certificate a Subject Alternative Name so that the desktop portal s URL accessed by web clients can be matched to the uploaded service provider certificate. For more details on how to add a Subject Alternative Name to the certificate, contact the certificate authority. 4.7 Add Tenant Resource Manager Create a Tenant Resource Manager Appliance 1. In the Service Center, select service grid > data centers. The Data Centers page appears. The page contains a table of the available data centers. 2. Find the line for your data center and click Edit. The Edit Data Center popup appears. 3. Click Add Appliances. The Appliance Install page appears. 4. In the Appliance Type drop-down, select Resource Manager. The page displays the data entry fields for the Primary and Secondary resource managers. 69

78 Service Provider Installation vcenter 5. Enter values for the fields listed in the table below. The IPs belong in the Service Provider network (not the link-local network) Table 4 10 Resource Manager Field Primary Name Sample Value RMGR1 Primary IP Secondary Name RMGR2 Secondary IP Enter values for the New Reservation fields listed in the table below. Table 4 11 New Reservation Field Sample Value Notes Friendly Name Create RSMGR Start Date Start Time Select Today from the drop-down or enter the month, day, and year. Enter 00:00 to indicate now, or the actual time in UT format. 7. Click Create Appliance. If you want to check the status of a reservation, select appliances > reservations. 8. Select service grid > resources to see the tenant resource manager once it is up and running (Optional) Give the Tenant Resource Manager a Friendly Name 1. In the Resource Managers panel on the left side of the page, click on the IP address of the new resource manager. 2. On the General tab, in the Name field, double-click on the IP address of the resource manager. A text box opens in which you can change the name. 3. Change the name to the user friendly name, for example Tenant RMGR and click OK (Optional) Configuring Netapp VSC plugin for Tenants If you are not using the Netapp VSC plugin for storage then skip this section and proceed to the next section entitled Define Tenant Models to continue the vcenter install. There is no need to define storage when managing with vcenter in the DaaS platform as this is already configured through the vcenter client. See Service Provider Prerequisites for more details on allocating storage for management appliances. If you using the Netapp VSC plugin for storage perform the steps below: 1. In the Service Center, select service grid > resources. 2. Select the Tenant RMGR in the pane on the left, then Storage Systems in the pane on the right. 3. On the Storage Systems tab, select the Add Storage System link. 4. Enter values for the fields listed in the table below. 70

79 Service Provider Installation vcenter Important: When adding a storage system to the DaaS platform, the Address field must match how the VSC plug-in was discovered for vcenter. If the plug-in was discovered as an IP address you must enter the IP address in the Address field. If it was discovered as a FQDN, then you must enter the complete domain name in the Address field. Table 4 12 Storage System Field Address Username Password Sample Value storage.desktone.com or root storagepswd 5. Click the Add Storage System button. The system adds the name of the storage system to the Storage Systems tab. 4.8 Define Desktop Models 1. In the Service Center, on the main menu, select configuration > desktop models. The Desktop Models page appears. 2. Click the Add desktop model link. 3. Enter values for the fields listed below. Table 4 13 Add Desktop Model Field Name Session Based Reference ID Desktop Type Memory Number of CPUs GPU Video Memory Explanation Use a generic name that describes the hardware and that you can reuse between tenants. The name you enter appears in the Administration console Desktop Models page. Choose Yes to provision remote desktop connections using Microsoft RDSH (Remote Desktop Services). Selecting Yes automatically sets the Desktop Type to dynamic. An optional text field that can be used for a customer specific tracking ID. Choose one of the types from the dropdown: Selectable, Static, or Dynamic. Enter the memory allocated to each virtual desktop, specified in megabytes. For a session-based model (RDSH), the memory the Administrator allocates to each desktop is typically higher because each desktop is supporting many sessions. Enter the number of virtual CPUs allocated to each virtual desktop. Enter the amount of GPU video memory to be allocated to each virtual desktop. Important: Carefully review your model settings, models cannot be deleted once created. 4. Click Add desktop model. A summary line for the new desktop model appears in the table. 71

80 Service Provider Installation vcenter 4.9 Installing Multiple DaaS Datacenters This section walks you through setting up an additional datacenter (DC2) after you have successfully installed your first datacenter (DC1). You need to have completed the DC1 Service Provider Prerequisites for DC2. Note: Each DaaS Datacenter must be in it s own vcenter. Therefore DC2 will require a separate vcenter from the one hosting DC1. Within that DC2 vcenter, you can host both your management appliances and tenant desktops or you can use separate vcenters for each. If you are using the same vcenter, all the hosts required for management appliances and tenant desktops must be in the same vcenter Datacenter Prepare Storage Configuration on Both Management Hosts On both DC2 management hosts, add the Service Provider datastore. Be sure to use the same name on each host Deploy OVA File On the DaaS Management Host for DC2, using the vsphere client, deploy two copies of the DaaS Management Appliance Template OVA file. The first copy becomes the SP1 appliance for DC2 upon completion of the bootstrap process. The second copy becomes the template for all subsequent DaaS management appliances in DC2. Prerequisite: Make sure that you have downloaded the DaaS ova file (appliance template), as outlined in Service Provider Prerequisites on page 2. You need to locate the DaaS ova file on a Windows drive accessible by the vsphere client in order to deploy it from vsphere (vsphere cannot natively mount a Linux partition or connect to the NFS share). 1. In the vsphere client, select Deploy OVF Template to deploy the first copy of the ova file, which becomes the first Service Provider appliance in the new datacenter. 2. In the vsphere client, select Deploy OVF Template again to deploy the second copy of the ova file, which becomes the template for all subsequent DaaS management appliances in this new datacenter. We recommend you preface the name of your data center to the beginning of the appliance template name. The name of the template must be unique across all datacenters Run the Bootstrap Script Run the bootstrap script to configure the network on the Service Provider appliance. You run the bootstrap script twice: once to configure the network on the appliance, and then a second time to complete the bootstrap process. 1. From the vsphere client, power on the primary Service Provider appliance in DC2 and open the console window. 2. Log in using the following credentials: User: desktone Password: Desktone1 Note: For greater security, you should specify a custom appliance password when prompted by the bootstrap script. Each datacenter can have its own unique appliance password. 3. Begin the bootstrap process by executing the following command: sudo /usr/local/desktone/scripts/bootstrap.sh 72

81 Service Provider Installation vcenter 4. The bootstrap script prompts you to enter network information for the new Datacenter needed by the DaaS Management Host. The network information requested by the script is listed in the table below. The values shown are sample values only; the values you enter are the values you collected in the Service Provider Installation Worksheet and Platform Install Checklist found in the System Blueprint. Installing Subsequent Datacenter: Network Information for DaaS Management Host Field Sample Value Notes Accept EULA agreement? Yes If the EULA agreement is not accepted the bootstrap script will exit. Existing multi-datacenter setup? Yes Because this is not the first datacenter but is instead an additional datacenter, answer yes. Is this the master datacenter? No The master datacenter is always the first datacenter Master Datacenter Information Enter the eth0 IP address of any SP appliance in the other Datacenter Local Datacenter Information Datacenter name CityofSecondDC IP for eth1 (backbone) For the DC2 Backbone network (must be a link-local address Netmask CIDR format (0-32) 22 For the DC2 Backbone network IP for eth0 (SP) For the DC2 SP network Netmask CIDR format (0-32) 24 For the DC2 SP network Gateway For the DC2 SP network Hostname (appliance FQDN) SP1.DESKTONE.COM Match the name used for the IP on the SP data center. Name server NTP server Enter a value only if you have a time server. Is this an HA Service Provider appliance setup? yes Floating IP Address desktone@<ip address> s password mypasswd <IP address> is the IP address for primary Service Provider of primary data center Appliance password mypasswd The user-defined password for Service Provider appliances in this datacenter. Any Service Provider appliance accessible by ssh require this custom password. Does this configuration look correct? yes or no. The information echoed back includes two internal values, Data Center UID and VMGR UID, which you can ignore. 73

82 Service Provider Installation vcenter 5. After the host reboots, you can login to the SP1 appliance via putty or any other ssh terminal you choose using the following credentials: User: desktone Password: the appliance password you established during bootstrap for DC Rerun the Bootstrap Script You run the bootstrap script a second time to install the DaaS software. Note that you do not need to copy the software to the primary Service Provider appliance in DC2. It will be automatically downloaded from the first data center. In the new Datacenter, rerun the bootstrap shell script: sudo /usr/local/desktone/scripts/bootstrap.sh Note: During the second bootstrap you will asked to provide the root appliance password for the primary service provider in the primary DC. Note: It might take five minutes for the appliance to start after reboot. Because the node is not configured until the reboot cycle completes, you can disregard any error messages displayed on the console Start the Service Center and Discover Management Host 1. Open a browser window and start the Service Center on the new Service Provider Appliance you just bootstrapped. For example: for eth0 (SP)>/service Replace <IP for eth0 (SP)> with the IP address that you specified in the table above. 2. You can safely ignore the warning about the website s security certificate and proceed to the Service Center page. 3. Enter your username, password, and domain then click Login. The Discover Management Server page is displayed. Use this page to discover the vcenter Server which holds the virtual machine template (.ova file) you imported as a prerequisite to this installation. The template is used for creating DaaS management appliances. Enter values for the fields listed in the table below, including the IP address/fully qualified domain name of the vcenter Server that is hosting the SP1 Service Provider appliance of DC2. vcenter Management Discovery Field IP Address/Hostname Username Password Sample Value mgvc2.domain.desktone.com root vcenterpasswd Note: Each DaaS Datacenter must be in its own vcenter. Therefore DC2 will require a separate vcenter from the one hosting DC1. 4. Click Discover Server. The system prompts you to accept the certificate for the vcenter. 5. Click Accept. 74

83 Service Provider Installation vcenter The system indicates it is discovering host and calculating capacity. 6. If prompted, select the vcenter Datacenter that contains the compute resources for DaaS. This vdc should also contain the DaaS Appliance Template (.ova file) that you imported. Note: If you only have 1 vdc, it will be automatically selected and a prompt will not appear 7. Select the Compute Resource(s) (ESXi hosts or Cluster) you have set assign for DaaS Appliances. These will be used to provision Appliances. Note: A minimum of 2 ESXi hosts is required for high availability (HA). A cluster is considered to be HA on its own. For each selected Compute, a dialog appears. If the server is too small to accommodate the ratios, you may be prompted to re-configure them. 8. Make any desired changes to the ratios and/or the Usage setting (Service, Tenant, or Network), and click Save to save the values. 9. After you set the ratios, a VM list will be displayed containing all the VMs from the compute selected as part of step 5. Select the DaaS appliance template from this list. Note: This should NOT be the Service Provider appliance itself, but should be the Appliance.ova that was deployed earlier. Once the system has discovered the appliance template, the Browse Tenants screen is displayed Complete the Datacenter Build Out The remainder of the process for the additional Datacenter is the same as for the first Datacenter, beginning in Section 4.4. You need to complete the following tasks: (Optional) Rename Resource Manager (Optional) Turn off Local Disk Provisioning (Optional) Add Storage for Service Provider Appliances Create the Remaining Service Provider Appliances Add Tenant Resource Manager Define Tenant Models 75

84 Access Point Setup 5 Access Point Setup 5.1 Overview This section describes the process for setting up Access Point, which has replaced Remote Access Manager (dtram) in DaaS deployments. Access Point is a VMware developed End-User Computing (EUC) appliance that acts as a specialized gateway (or reverse proxy) that manages access to enterprise EUC products deployed in a private or public cloud. It consolidates functionality that was previously implemented in various enterprise EUC products, and simplifies deployments for customers who use multiple EUC products within their environments. The following are advantages of migrating to Access Point: Customers who migrate to Access Point can reduce their firewall open ports to 443, 4172 and Access Point properly handles SSL certificates for HTML Access (Blast) so that a certificate will no longer be required on the virtual desktop. Note: For internal access not via Access Point, desktops will still need to have SSL certificates High-Level Architecture The diagram below shows the high-level architecture of Access Point configured in a DaaS deployment. 76

85 Access Point Setup Basic Functionality The basic functionality of Access Point is as follows. The client makes a connection to the reverse proxy, and when the response comes back, the client intercepts it. The connection can be established by either a browser or the Horizon client. Once a virtual desktop session is established, the PCoIP SG, Blast SG, or View Tunnel may be used for the virtual desktop traffic, depending on what protocol the user has selected. The tunnel is used for the RDP protocol as well as USB connections. Access Point used in a Horizon DaaS deployment has the following characteristics: There will be no authentication (at least for the first release). This responsibility will remain within the Tenant Appliance. All communication will be proxied through Access Point if the end-user is accessing the solution from outside of the corporate network. This includes: All View specific protocol handling (XMLAPI, PCoIP, etc) Any Tenant Appliance communication Access Point vs. dtram The main differences between dtram and Access Point are outlined in the table below. dtram (no longer supported) Tenant appliance sits in front of the dtram and controls its operations Does not make use of a PSG (or BSG or Tunnel) gateway that is installed Needs to use a wide range of ports for PCoIP etc. from the client and requires customers to open all of these ports to allow access BSD-based and uses "pf" to forward traffic Supports HA clustering Supports geographically dispersed datacenters Has security weaknesses because it can only validate traffic based on source IP address Access Point Access Point appliance sits in front of the tenant appliance so that the tenant does not know it exists. The tenant requires software changes to accommodate this new architectural shift. Makes use of a PSG (or BSG or Tunnel) gateway that is installed All PCoIP traffic can come in on the standard port (4172). Other single ports are used for BSG and Tunnel. Linux appliance with built-in proxying capabilities HA clustering is possible if you choose to configure load balancers Does not support geographically dispersed datacenters in the first release Uses deep protocol inspection techniques to ensure that traffic from the client is properly validated before it is passed on to the virtual desktops 77

86 Access Point Setup Performance The following are some considerations regarding Access Point performance. Capacity Access Point has been tested with as many as 2,000 concurrent sessions, but the number of sessions your system can handle depends on the amount of data being sent and received (for example, video content). Monitoring Access Point does not currently have an internal monitoring tool, but you are able to obtain usage information using vcloud Director monitoring of the tenant appliance. Rebooting Performing a reboot operation for Access Point disconnects all active users. The user's desktop session remains active, but the user will need to reestablish the connection to regain access to the desktop. If Access Points are deployed in a load balanced configuration with multiple Access Points, then any active or new users will be able to immediately reconnect via the load balancer and the connection will be handled by another Access Point while one is rebooting. High Availability / Failover HA clustering is possible if you choose to configure load balancers 5.2 Set Up Access Point For more information about Access Point configuration, see VMware Access Point Documentation. Note: You cannot deploy an Access Point VM from a vsphere Windows client. You must deploy it from the vsphere web client. Note: Default tenant appliance certificates should not be used for configuring Access Point 2.5 or above. Custom certificates for Tenant should be uploaded from the Service Center user interface and those certificates should be used for configuring Access Point. 1. Download the latest version of the Access Point OVA file. 2. Determine the IP addresses (DNS/Netmask/Gateway) for the required networks, as described below. Configuration 3 NIC (Recommended configuration) Networks Internet (NIC 1) Management (NIC 2) Backend (NIC 3) Any network with internet access This can be your 169 network. Since this does not have its own DNS or Gateway, you can enter any numbers for DNS and set the netmask to Network that the Tenant uses for desktops 2 NIC Internet (NIC 1) Management (NIC 2) 1 NIC Internet (NIC 1) Network the Tenant is on This can be your 169 network. Since this does not have its own DNS or Gateway, you can enter any numbers for DNS and set the netmask to Network that the Tenant is on 78

87 Access Point Setup Note: If NIC 2 is present, then the administration server (port 9443) that provides the REST APIs will only listen on that NIC. This server is accessed by the "apsetup.sh" script used in Step 5 below. If NIC 2 is not present, then that administration server listens on all of the interfaces. 1. In the vsphere web client, follow the normal method for deploying a template. In the Customize template step, enter information as shown below. Note: The fields below may not all appear, depending on your configuration, and may also appear in a different order than that shown below. Heading Field Value Networking Properties Password Options System Properties External IP Address DNS server addresses Management network IP Address Backend network IP Address Password for the root user of this VM Password for the admin user, which enables REST API access Locale to use for localized messages Enter the physical IP address of NIC 1. Note: If user access is via a NAT address, do not enter that address here. Enter IP of the DNS that the Access Point will use to resolve Hostnames. If configuration is 3 NIC or 2 NIC, enter Management Network IP from the previous step. If configuration is 3 NIC, enter Backend Network IP from the previous step. Enter initial password for root user. This must be a valid Linux password. Enter password to be used for REST API Admin user. Password must be at least eight characters long and must contain: At least one upper case letter At least one lower case letter At least one number At least one special character #, etc.) en_us Syslog server URL Leave blank Horizon Properties Horizon server URL Horizon server thumbprints Leave blank Leave blank 2. When you have finished the deployment process, power on the VM and wait for the login screen to appear on the console. 3. On the tenant appliance, run the following command: sudo /usr/local/desktone/scripts/apsetup.sh 4. Enter yes or no to the initial two prompts, as described below. 79

88 Access Point Setup Prompt Do you want to setup this access point for internal access... : Do you want to allow Horizon Air Helpdesk Console access... : Value Default value is no. If you enter anything other than y or yes, it will default to no and the access point will be configured for external connections in the DMZ network. In most cases you will use the external configuration. Enter yes to make this an internal access point so that the PCoIP traffic goes directly to the desktops, bypassing the access point. Enter yes to allow Horizon Air Helpdesk Console access though the access point, or no to not allow access. Horizon Air Helpdesk Console is a console access tool that allows you to run health scans, provide remote assistance, and view history and audit information for each VM in your system. Note: This is a beta feature and is not supported at this time. It is available only for vcloud deployments, not for vcenter deployments. For more information about trying this tool, please contact your deployment representative. The system now proceeds to the Access Point Configuration prompts. 5. Enter the requested information for the Access Point appliance: Prompt Value Admin Password: Management IP: Password for the admin user of the Access Point. This is the same address you entered above for Management network IP Address. External IP: The IP address for NIC 1 or the NAT IP address of NIC 1. External Hostname [xx.xx.xx.xx]: External PCoIP Port [4172]: External HTML Access Port [8443]: External Tunnel Port [443]: [Default hostname in brackets] Default PCoIP Port shown in brackets: [4172] Default HTML Access Port in brackets: [8443] Default Tunnel Port in brackets: [443] 6. The response status returned will indicate whether the configuration was successful. Response status Result 200 Configuration successful 400 Invalid input 401 Password incorrect. Confirm that password matches admin password configured during OVA deployment. 000 One of the following: Network connection failure. Confirm that IP address matches management IP address configured during OVA deployment. 80

89 Access Point Setup Response status Result REST API password does not meet password criteria. 7. If dtram was in use on this environment previously, set the element.allocator.ram.use policy to false and remove the associated NAT and firewall rules. 8. Configure NAT and firewall rules to allow access to the Access Point appliance through Internet network. Note: When using an edge gateway load balancer the NAT for ports 80 and 443 are not required. These ports are forwarded automatically. Port 4172/tcp, 4172/udp 8443/tcp 443/tcp Usage PCoIP desktop access protocol HTML desktop access protocol Secure web portal access 80/tcp Insecure web portal access (will be redirected to 443) 5.3 Example of Load Balancer Configuration Note: The following is an example of the process for configuring a load balancer. The settings you use will be different. 1. Choose an external IP to use for NAT (for example, ). 2. Choose three external ports per Access Point for NAT (for example, [41721, 8443, 4431], [41722, 8444, 4432]). 3. Log in to the vcloud Director interface as an Organization Administrator. 4. Navigate to Edge Gateway Services: a. Click Administration in the top menu. b. Click Virtual Datacenters in the Administration pane to the left. c. Click the Virtual Datacenter name in the pane on the right. d. The pane on the right has a row of tabs along the top. Click the Edge Gateways tab. e. In the list of Edge Gateways, click one to select it. f. Right-click the Edge Gateway and click Edge Gateway Services. 5. Configure DNAT: a. On the Edge Gateway Services page, click the NAT tab. b. Configure as shown below. Applied On Type Original IP Original Port Translated IP Translated Port Protocol external DNAT TCP & UDP external DNAT TCP external DNAT TCP 81

90 Access Point Setup external DNAT TCP & UDP external DNAT TCP external DNAT TCP 6. Configure Firewall: a. On the Edge Gateway Services page, click the Firewall tab. b. Configure as shown below. Name Source Destination Protocol Action ap1-pcoip any:any :41721 TCP & UDP Allow ap1-blast any:any :8443 TCP Allow ap1-tunnel any:any :4431 TCP Allow ap2-pcoip any:any :41722 TCP & UDP Allow ap2-blast any:any :8444 TCP Allow ap2-tunnel any:any :4432 TCP Allow 7. Configure load balancer pool servers: a. On the Load Balancer tab, click Pool Servers and click Add. b. On the Name & Description tab, type a name and optionally a description for the pool server. c. Click Next. d. On the Configure Service tab: Click Enable for HTTP and HTTPS services. Select IP Hash for the balancing method for both services. For default ports, enter the following: HTTP Port 80 HTTPS Port 443 e. Click Next. f. On the Configure Health-Check tab: For HTTP and HTTPS, enter Monitor Ports. For HTTPS, change Mode to TCP. In the URI for HTTP service field, enter /favicon.ico g. Click Next. h. On the Manage Members tab, add each Access point as a member, described below. 1) Click Add. 82

91 Access Point Setup 2) In the Add Member dialog: Enter the IP address of the Internet AP interface, as defined when you deployed the OVA. For both HTTP and HTTPS, enter 80 for Port and 443 for Monitor Port. 3) Click OK. 8. Configure load balancer virtual server: a. On the Load Balancer tab, click Virtual Servers and click Add. b. Enter a name and description for the virtual server. c. Select an external network from the Applied on drop-down menu. d. Enter the external IP address of the virtual server. e. From the drop-down menu, select the pool you created earlier. f. In Services, select Enable for HTTP and HTTPS. g. For Persistence Method, enter No persistence for HTTP and HTTPS. h. Click Enabled to enable the virtual server. i. Click OK. 83

92 HTML Access (Blast) Setup 6 HTML Access (Blast) Setup 6.1 Overview About Desktop Protocols The Horizon Agent has a very small footprint (90Kb) and supports the full Horizon Client capabilities: PCoIP, RDP, HTTPS, SSL, SSO, USB Redirection, printer support, and session management About HTML Access (Blast) HTML Access (Blast) enables access to a desktop via any HTML5 compliant web browser. To use HTML Access: Each virtual desktop must be running the latest Horizon Agent. Each virtual desktop must be running the latest Horizon DaaS Agent. SSL certificate install automation must be configured as described under Automate SSL Installation below System Requirements Browser on client system: Chrome 41, 42, and 43 Internet Explorer 10 and 11 Safari 7 and 8 (Mobile Safari is not supported for this release.) Firefox 36, 37, and 38 Client operating systems: Windows 7 SP1 (32- or 64-bit) Windows 8.x desktop (32- or 64-bit) Windows 10 desktop (32- or 64-bit) Mac OS X Mavericks (10.9) Mac OS X Yosemite (10.10) Chrome OS 28.x or later 84

93 HTML Access (Blast) Setup HTML Access (Blast) Support for RDSH Applications Launching RDSH applications is supported in HTML Access Setup Procedure Install Correct Browser See list of supported browsers in System Requirements Prepare Desktops to Support Protocol Before installing the software required to connect to desktops, complete the following pre-installation steps. 1. Uninstall all software components related to all other protocols. Important: You must uninstall all software components related to all other protocols (e.g. HDX, RGS). If you do not uninstall these other protocol components, your template will be corrupted and you will no longer successfully boot into Windows. This warning does not apply to RDP; the presence of RDP components does not cause problems. 2. Update VMware Tools. 3. Make sure that port 443 is not being used by any other software. 4. Enable the Windows Firewall if not already enabled. 5. Make sure that the following ports are open to TCP and/or UDP traffic as indicated: Port(s) Source Destination TCP UDP 4172 Access Point VM 443 Tenant Appliance VM Access Point VM Install DaaS Agent 1. Copy the most recent DaaS Agent executable file (VMware-DaaS-Agent-x.x.x.msi) to each VM. 2. Run the DaaS Agent executable file Install Horizon Agent There are three possible scenarios when installing the Horizon Agent: Install on desktop (Windows 7, Windows 8, Windows 8.1) Install on server (Windows Server 2008 R2, Windows Server 2012 R2) as Personal Desktop (Non- RDSH) Install on server (Windows Server 2008 R2, Windows Server 2012 R2) as RDSH Role For more information on the standard installation procedure, see Install Horizon Agent on a Virtual Machine. For information on silent installation procedure, see Install Horizon Agent Silently. Note that if 85

94 HTML Access (Blast) Setup you use the silent installation procedure, you still need to select/de-select custom options as detailed in the steps below. Note: If you have not installed the most recent version of the Horizon Agent, this can cause problems with creating RDS pools. In this case, when you create a new RDS pool, the system can allow you to select HTML Access (Blast) as a protocol, but this selection will not be applied to the pool even though it appears to have been applied successfully Install on Desktop (Windows 7, Windows 8, Windows 8.1) Procedure 1. Download the latest Horizon Agent from VMware s website ( Note that there are separate downloads for 32-bit and 64-bit operating systems. 1. Double-click the Horizon Agent installation file (file name is: VMware-viewagent-x86_64-x.y.znnnnnnn.exe for the 64-bit installer). 2. Select custom setup. De-select the option to install the View Composer component. Accept other default settings. 3. Restart the virtual machine when prompted Install on Windows Server 2008 R2 or 2012 R2 as Personal Desktop (Non-RDSH) Procedure 1. Download the latest Horizon Agent from VMware s website ( 2. Double-click the Horizon Agent installation file (file name is: VMware-viewagent-x86_64-x.y.znnnnnnn.exe for the 64-bit installer). 3. Select custom setup. Select the option to install the Agent in desktop mode. De-select the option to install the View Composer component. Accept other default settings. 4. Restart the virtual machine when prompted Install on Windows Server 2008R2/2012 as RDSH Role Note: To install the Horizon Agent in this scenario, you MUST run the command line install and cannot use the default double click GUI. Procedure 1. Download the latest Horizon Agent from VMware s website ( 2. Run the following on the command line as an administrator user: VMware-viewagent-x86_64-x.y.z-nnnnnnn.exe /v "VDM_SKIP_BROKER_REGISTRATION=1" 3. Select custom setup. De-select the option to install the View Composer component. 86

95 HTML Access (Blast) Setup Accept other default settings. 4. Restart the virtual machine when prompted Add the HTML Access (Blast) Group Policy Settings to the Local Computer Policy Environment 1. Download the View GPO Bundle.zip file from the VMware Horizon 6 download site at: The file is named VMware-Horizon-View-Extras-Bundle-x.x.x-yyyyyyy.zip, where x.x.x is the version and yyyyyyy is the build number. All ADM and ADMX files that provide group policy settings for View are available in this file. 2. Copy the file to your Active Directory server and unzip the file. The HTML Access GPOs are included in the Blast-enUS.adm ADM Template file. 3. On the Active Directory server, edit the GPO. Option Windows 2008 or 2012 Description a) Select Start > Administrative Tools > Group Policy Management. b) Expand your domain, right-click the GPO that you created for the group policy settings, and select Edit. Windows 2003 a) Select Start > All Programs > Administrative Tools > Active Directory Users and Computers. b) Right-click the OU that contains your View desktops and select Properties. c) On the Group Policy tab, click Open to open the Group Policy Management plug-in. d) In the right pane, right-click the GPO that you created for the group policy settings and select Edit. The Group Policy Object Editor window appears. 4. In the Group Policy Object Editor, right-click Administrative Templates under Computer Configuration and then select Add/Remove Templates. 5. Click Add, browse to the Blast-enUS.adm file, and click Open. 6. Click Close to apply the policy settings in the ADM Template file to the GPO. The VMware Blast folder appears in the left pane under Administrative Templates > Classic Administrative Templates. 7. Configure the HTML Access group policy settings. 8. Make sure your policy settings are applied to the remote desktops. 9. Run the gpupdate.exe command on the desktops. 10. Restart the desktops. 87

96 HTML Access (Blast) Setup Automate SSL Installation The process described in this section is needed to facilitate internal access that is not via Access Point. If you do not have users requiring this type of access, you do not need to perform this procedure. Note the following: You must follow this process on the gold pattern before converting the VM as a gold pattern or reseal. You must repeat this process each time you open and re-seal a gold pattern. You can install the certificate using post sysprep script execution in order to avoid sysprep issues and duplicate certificate problems. You can also use your own own standard practice as well (for example, Active Directory GPO and scripts). Please read the Horizon View feature pack documentation for SSL certificate requirements. Follow the steps below to configure post sysprep commands/scripts in the Horizon DaaS environment. Import certificate on test machine and note certificate thumbprint. Create post sysprep script/batch file on gold pattern image and copy certificate. Convert image to gold pattern or reseal Import Certificate and Record Certificate Thumbprint Procedure 1. Add the certificate snap-in to MMC by performing the steps below. In order to add certificates to the Windows certificate store, you must first add the certificate snap-in to the Microsoft Management Console (MMC). Before you begin, verify that the MMC and certificate snap-in are available on the Windows guest operating system. a. On the desktop, click Start and type mmc.exe b. In the MMC window, select File > Add/Remove Snap-in. c. In the Add or Remove Snap-ins window, select Certificates and click Add. d. In the Certificates snap-in window, select Computer account, click Next, select local computer, and click Finish. e. In the Add or Remove snap-in window, click OK. 2. Import a certificate for the HTML Access Agent into the Windows Certificate Store by performing the steps below. To replace a default HTML Access Agent certificate with a CA-signed certificate, you must import the CA-signed certificate into the Windows local computer certificate store. Before you begin, verify that the HTML Access Agent is installed, the CA-signed certificate was copied to the desktop, and the certificate snap-in was added to MMC (see Step 1 above). a. In the MMC window, expand the Certificates (Local Computer) node and select the Personal folder. b. In the Actions pane, select More Actions > All Tasks > Import. c. In the Certificate Import wizard, click Next and browse to the location where the certificate is stored. d. Select the certificate file and click Open. 88

97 HTML Access (Blast) Setup To display your certificate file type, you can select its file format from the File name drop-down menu. e. Type the password for the private key that is included in the certificate file. f. Select Mark this key as exportable. g. Select Include all extendable properties. h. Click Next and click Finish. The new certificate appears in the Certificates (Local Computer) > Personal > Certificates folder. i. Verify that the new certificate contains a private key. 1) In the Certificates (Local Computer) > Personal > Certificates folder, double-click the new certificate. 2) In the General tab of the Certificate Information dialog box, verify that the following statement appears: You have a private key that corresponds to this certificate. 3. Import root and intermediate certificates for the HTML Access Agent If the root certificate and intermediate certificates in the certificate chain are not imported with the SSL certificate that you imported for the HTML Access Agent, you must import these certificates into the Windows local computer certificate store. a. In the MMC console, expand the Certificates (Local Computer) node and go to the Trusted Root Certification Authorities > Certificates folder. If your root certificate is in this folder, and there are no intermediate certificates in your certificate chain, skip this procedure. If your root certificate is not in this folder, proceed to step b. b. Right-click the Trusted Root Certification Authorities > Certificates folder and click All Tasks > Import. c. In the Certificate Import wizard, click Next and browse to the location where the root CA certificate is stored. d. Select the root CA certificate file and click Open. e. Click Next, click Next, and click Finish. f. If your server certificate was signed by an intermediate CA, import all intermediate certificates in the certificate chain into the Windows local computer certificate store. 1) Go to the Certificates (Local Computer) > Intermediate Certification Authorities > Certificates folder. 2) Repeat steps c through f for each intermediate certificate that must be imported. 4. In the certificate MMC window, navigate to the Certificates (Local Computer) > Personal > Certificates folder. 5. Double-click the CA-signed certificate that you imported into the Windows certificate store. 6. In the Certificates dialog box, click the Details tab, scroll down, and select the Thumbprint icon. 7. Copy the selected thumbprint to a text file. For example: 31 2a a 0b 34 b a8 0a 5e f7 43 6e a9 2c 3e 89

98 HTML Access (Blast) Setup Note: When you copy the thumbprint, do not to include the leading space. If you inadvertently paste the leading space with the thumbprint into the registry key (in Step 7), the certificate might not be configured successfully. This problem can occur even though the leading space is not displayed in the registry value text box Create Post Sysprep Script/Batch File on Gold Pattern Image and Copy Certificate Windows 7 and Later Use post build configuration script SetupComplete.cmd to import the SSL certificate and configure the VMware HTML Access registry. For example: Copy the SSL certificate file under C: drive. For this example, the C:\desktone_ca_cert file. Create a file SetupComplete.cmd under "%WINDIR%\Setup\Scripts\" folder. Create Scripts folder if it does not exist. Add following commands in SetupComplete.cmd file. The thumbprint value is what you copied in Step 1. Note that if you have root certificate and intermediate certificates in the certificate chain, then you need to add appropriate CertUtil commands in batch file. CertUtil -importpfx -f -p "<password>" "C:\desktone_ca_cert.pfx" reg add "HKLM\SOFTWARE\VMware, Inc.\VMware Blast\Config" /f /v "SslHash" /t REG_SZ /d "31 2a a 0b 34 b a8 0a 5e f7 43 6e a9 2c 3e" del /F /Q "C:\desktone_ca_cert.pfx" del /F /Q "%systemroot%\setup\scripts\setupcomplete.cmd" Save the SetupComplete.cmd file. You can test the SetupComplete.cmd file on test machine Windows XP Follow the Desktone post sysprep command execution approach to import the SSL certificate and configure the VMware HTML Access registry. Install the Administration Tools Pack for Windows XP as the CertUtil tool is not available with the OS install. For example: Copy the SSL certificate file under C: drive. For this example, the C:\desktone_ca_cert.pfx file. Create a folder path C:\Sysprep\i386\$OEM$\ Now create postprep-extra.bat file under C:\Sysprep\i386\$OEM$\ and add the following commands in the batch file. The thumbprint value is the one you recorded above after importing the certificate. Note that if you have root certificate and intermediate certificates in the certificate chain, then you need to add appropriate CertUtil commands in the vbatch file. 90

99 HTML Access (Blast) Setup CertUtil -importpfx -f -p "<password>" "C:\desktone_ca_cert.pfx" del /F /Q "C:\desktone_ca_cert.pfx.pfx" reg add "HKLM\SOFTWARE\VMware, Inc.\VMware Blast\Config" /f /v "SslHash" /t REG_SZ /d "31 2a a 0b 34 b a8 0a 5e f7 43 6e a9 2c 3e" Save the postprep-extra.bat file. You do not need a command to delete the batch postprepextra.bat file as sysprep deletes the C:\Sysprep folder after successful deployment. You can test the SetupComplete.cmd file on the test machine Convert Image to Gold Pattern or Reseal Procedure 1. Convert the image as a gold pattern or reseal, and create a pool. 2. Verify the HTML Access connection for the certificate, or check certificates and HTML Access registry on desktops. Note: If the HTML Access (Blast) service generates the self-signed certificate even after you set the valid CA certificate as described above, then you can troubleshoot this issue by looking at the logs located here: %ProgramData%\VMWare\Vmware Blast\Blast-worker.txt 6.3 Troubleshoot Connection Problems There are several configuration/setup problems that can result in an inability to launch a HTML Access (Blast) connection successfully: Browser is not HTML5 compliant. Check that the browser version is one cited in the requirements. Pop-up blocker enabled. The browser s pop-up blocker could prevent opening the new window for a HTML Access connection. Make sure that the user disables the pop-up blocker for the Desktop Portal. Windows firewall disabled. Make sure that the Windows Firewall is installed and running on the user s desktop. A disabled Windows Firewall will result in errors reported in the HTML Access logs. Certificate errors. If you receive an error that indicates a missing or non-matching certificate, review the instructions above under Import Certificate and Record Certificate Thumbprint and confirm that you have performed the necessary steps. Note: You must repeat this process each time you open and re-seal a gold pattern. 6.4 Known Limitations and Workarounds An SSL certificate warning will be displayed upon connecting to the desktop. This is because the SSL certificate process was not performed correctly on a tenant gold pattern. Changing resolution to 2560x1920 ends the HTML Access session. This happens due to lack of vram allocation. For more information see Estimating Memory Requirements for Virtual Desktops in the View documentation. If your client system uses a super high resolution monitor (such as 2560 x 1600), HTML Access fails to display the desktop. Workaround: Lower the resolution on your monitor and connect. The resolution on the client monitor must be less than 2560 x 1600 if the remote desktop resolution is 1920 x

100 HTML Access (Blast) Setup Sound playback quality is best on browsers that have Web Audio API support, such as Chrome, Safari, and Firefox 25. Browsers that do not have this support include Internet Explorer (up to and including Internet Explorer 11) and Firefox 24 and earlier. Black artifacts appear on the screen on ESXi 5.1 or 5.0 hosts. This is a known HTML Access issue when the desktop HW version is 9 (ESX 5.0/5.1) with 3D disabled and the Windows 7 basic theme is used. This is not an issue when Aero is turned on or when the VM uses HW version 10 (ESX 5.5). Horizon Agent session timeout may occur before the Desktop Portal session timeout, resulting in Authentication error connecting to the desktop via HTML Access. The workaround for this this is to log out of Desktop Portal and log in again. For additional known limitations, see Known Issues in the HTML Access Release Notes. 92

101 Tenant Customization 7 Tenant Customization 7.1 Custom Branding If you have a custom branding scheme for Desktop Portal, you will need to check whether everything appears as expected after upgrading a tenant. There are a few areas to which you should pay particular attention due to VMware branding changes. Login page: CSS selector: #productnameinner You may need to adjust the margin-left property and/or decrease the font-size, for example : font-size: 14px; Other pages: You will likely need to make the same changes as for the login page. Additionally, you may need to adjust the background-position of the #banner selector: background-position: 0px 0px; 7.2 Configure NetApp Storage Summary This section describes the configuration for NetApp storage with the DaaS platform Hardware and Software Requirements VMware recommends NetApp storage with FlexClone for the VM image storage to take advantage of deduplication. For the other storage volumes, generic NFS will suffice. NetApp hardware and software: FAS3140C e/w 3 shelves of 1TB drives (42) PAM card NFS NearStore A-SIS FlexVol FlexScale NFS Exports VMware recommends NetApp storage with FlexClone for the VM image storage (/vol/vol_tenanta and /vol/vol_tenantb in this example) to take advantage of deduplication. For the other storage volumes, generic NFS will suffice. 93

102 Tenant Customization Local Mount Point Structure On the transit server node, create a directory structure identical to the NFS exports that you will be mounting. While this is not strictly required, it assists in solving mount related issues, and to remember what is mounted where. For example, for the exports defined above, create the following directory structure on the local management node: /vol -- db -- vol_sp -- vol_tenanta -- vol_tenantb -- vol_dbbackup `-- vol_upload Permissions and Security All mounted file systems should have the following export options set: Read-write access: Set for all hosts (you can choose to limit to specific hosts if desired, but you should check this as you add management nodes). Root access: Specify a range of host addresses which should have root access (using CIDR notation). This range must include all the management nodes. Security: Select Unix style security for the exports. When you view the export options for the NFS exports, it should look like this: Read-Write Access (All Hosts) Root Access ( /24) Security (sys) Add a New NetApp Service Account From your NetApp system, you need to add a new role, group, and user: Add a New Role netapp2> useradmin role add desktone_role -c "Role for Desktone API Support" -a login-http-admin,api-license-list-info,api-system-get-info,api-system-get- version,api-system-get-ontapi-version,api-nfs-status,api-nfs-exportfs-list-rules- 2,api-nfs-exportfs-modify-rule-2,api-clone-start,api-clone-stop,api-clone-liststatus,api-vfiler-list-info Wed Nov 25 19:34:57 GMT [useradmin.added.deleted:info]: The role 'desktone_role' has been added. Role added. Add a New Group netapp2> useradmin group add desktone_group -c "Group for Desktone" -r desktone_role Wed Nov 25 19:41:35 GMT [useradmin.added.deleted:info]: The group 'desktone_group' has been added. Group added. Add a New User netapp2> useradmin user add desktone -c "Service account for Desktone" -n "Desktone SA" -g desktone_group New password: Retype new password: User added. netapp2> Wed Nov 25 19:57:50 GMT [useradmin.added.deleted:info]: The user 'desktone' has been added. 94

103 Tenant Customization 7.3 Super Tenant Overview DaaS service providers and Managed service providers (MSPs) are increasingly targeting the SMB market. Creating a separate tenant for each customer will consume significantly more resources than might be necessary for customers who typically need no more than 20 desktops or sessions. MSPs prefer a shared tenant where they can provision each customer into its own pool, but maintain logical separation between the pools. This type of shared tenant will be referred to in this context as a Super Tenant. It is assumed that the MSP will manage Administration Console, Active Directory, and user/group mappings to the pool on behalf of the individual customers. Some MSPs will also need to separate customers across hosts either for security reasons or for Microsoft licensing compliance. Note: Please refer to the regular tenant install guide for further details Super Tenant Prerequisites Networking Requirements A Super Tenant must have a perimeter network (e.g. DMZ in figure above) where DaaS tenant appliances and other external facing components like Access Point are behind a firewall. The tenant administrator must create subnets for each customer to isolate. Each subnet must be labeled (typically with a customer id or name) to easily identify customers on hypervisors and the DaaS platform. The administrator must configure these subnets so that traffic is allowed between the DMZ and customer subnets (e.g. N1C1 and N2C2 in diagram 2.5) and vice versa. The Administrator can use either DVS (Distributed Virtual Switch) or standard vswitch networks within vcenter. It may be advantageous to use distributed virtual networking since the number of VLANs per datacenter is limited according network specifications (4096 VLANs or less) Tenant Active Directory and DNS Configuration The tenant administrator can use a single Active Directory to serve all customers by creating customer specific security groups. The domain controllers and DNS server must be in the DMZ network so that all customer assigned subnets can connect. Please check Microsoft recommended best practices for use of domain controllers across subnets. The administrator should create security groups for each customer to ease the user management and configuration in the DaaS platform such as user mapping. Customers can be separated by creating Organizational Units with security groups under the OUs in Active Directory. Example: The figure below shows that the tenant administrator has created an OU named DesktoneSuperTenant in Active Directory, and created security groups for each customer such as Customer1_Grp, FordDesktopUsers, etc. The tenant administrator must then add each security group to the User Groups field on the Group Info tab of the Domain configuration. 95

104 Tenant Customization Sample Active Directory Structure Tenant DHCP Configuration The tenant administrator should configure DHCP considering the network topology of subnets. A single DHCP server can be used to serve all subnet desktop clients by utilizing BOOTP-relay agent capability of a network router, or having another computer that can function as a relay agent on each subnet. Each DHCP scope should be verified to ensure the correct domain controller and DNS configuration for each network subnet. Please refer to Microsoft recommendations and best practices to configure the DHCP server: Gold Pattern and DaaS Agent Gold Pattern The tenant admin should create a gold pattern and customize it per the customer s requirement. The admin can create individual gold patterns for each customer if required. Important: Using a Windows client operating system image, such as Windows 7, in a Super Tenant may not be advisable due to Microsoft licensing restrictions. Specifically, the license associated with Windows 7 (also Windows XP and Window 8) requires that virtual instances run on isolated hardware per customer (e.g. Windows 7 instances for customer A and customer B cannot be on the same server or blade). A popular approach due to the licensing restrictions is to use individual Windows Server instances skinned as Windows 7. This approach gives the end user a familiar desktop look and feel and also allows sharing of infrastructure with SPLA licensing. For further information please refer to Microsoft Windows licensing for virtualization at microsoft.com. 96

105 Tenant Customization DaaS Agent The recommended way to deploy the DaaS Agent is to use tenant appliance auto discovery where a specific DHCP option code is used so that the DaaS Agent can automatically discover the IP addresses of the tenant appliances. This process is detailed in the DaaS platform tenant installation guide. In our testing we ve found that auto discovery does not always work on subnets other than the subnet where DHCP resides. As an alternative the standby address can be manually set in the MonitorAgent.ini file Tenant Infrastructure Overview Diagram The figure below represents an overview of the Super Tenant network infrastructure. DaaS platform communication between the tenant appliances and service provider appliances is done via backbone connectivity. This is standard for a non-super Tenant as well. The Super Tenant has separate subnets (e.g. N1C1 and N2C2) for each customer. The subnet networks are isolated so that N1C1 network cannot access N2C2 network resources directly, but they can still connect to the DMZ network for communication with the tenant appliances and other tenant infrastructure components such as the domain controllers and DNS. Tenant Infrastructure Overview Service Center This section describes the actions to be performed by the service provider admin in order to enable the Super Tenant Create a Super Tenant The service provider administrator should follow the steps below to enable Super Tenant capabilities at the time of tenant registration. Please make sure that you have prepared the required infrastructure for the Super Tenant as described above. To enable the Super Tenant during initial registration, perform the steps below. 97

106 Tenant Customization Procedure 1. Log in to the Service Center and click on the Tenants tab. 2. Click on the Register a tenant link and select the Super Tenant checkbox as shown in the figure below. 3. Follow the normal tenant registration steps. Enabling a Super Tenant during Registration Enable an Existing Tenant as a Super Tenant A service provider administrator can also enable super tenant capabilities for an existing tenant. To enable the Super Tenant after initial registration, perform the steps below. Procedure 1. Log in to the Service Center and click on the Tenants tab. 2. Click the Edit button for the tenant which you want to promote. 3. On the General tab, select the Super Tenant checkbox and click Update as shown in the figure below. 98

107 Tenant Customization Promoting an Existing Tenant to Super Tenant Add Networks for a Super Tenant A service provider administrator must add networks to be used for Super Tenant customers in the DaaS platform. To add networks, follow the procedure below. Procedure 1. Log in to the Service Center and click on the Tenants tab. 2. Click the Edit button for the appropriate tenant. 3. Select the Networks tab and then click the Add Network Component link. 4. Enter the network details and click Add Network Component as shown in the figure below. Note: Fill in the Network Label field on the Networks tab with a user-friendly name associated with the tenant network. This field appears at pool creation time to allow you to associate a pool with a network. 99

108 Tenant Customization Adding Super Tenant Networks Disabling the Super Tenant Option A service provider admin cannot disable the Super Tenant option for a tenant. This is by design Billing The DtReportingManager now has an additional method SuperTenantBillingReports and returns a collection of DtSuperTenantBillingReport records as described. Please refer to the DaaS platform SDK for further information. DtReportingManager Name Description Method Relationship SuperTenantBillingReports Retrieves a list of super tenant billing reports based on the given DtBillingReportFilter POST association DtSuperTenantBillingReport Collects billing data for super tenants by their customer ids. Links There are no links in this object. 100

109 Tenant Customization Properties Name Description Data Type customerid desktopcount Sub-tenant customer ID pertaining to this record List of desktop model to the in-use count of those desktop models by this customer in a super tenant. Count for each desktop model is wrapped within DtDesktopCountWrapper instances. String Collection of DtDesktopCountWrapper organizationid Organization ID of the super tenant Long sessioncount Count of the number of sessions allocated to this customer Long Sample Script output: SUPER TENANT BILLING SUMMARY ORG CUSTOMER TYPE COUNT DESKTOPMODELID Audi001 SESSION Audi001 DESKTOP 2 1cb3f348-f a33c-742ef30d356b 1001 Ford001 SESSION BMW001 SESSION BMW001 DESKTOP 1 1cb3f348-f a33c-742ef30d356b 101

110 Reports 8 Reports 8.1 Billing Summary Reports Overview DaaS captures Quota information along with usage for each tenant. This data is sorted by Datacenter, and is intended to be used by the service provider for billing information. All billing information retrieval must be done via REST APIs. The retrieval of billing information via scripts is not supported. Note: By default the Billing Summary Report will contain information about disabled and enabled tenants, but there is a policy ( billing.summary.skip.disabled.tenants ) that can alter this functionality to only collect information for enabled tenants. To activate this option, set the policy value to true Override Report Intervals By default, the platform captures billing summary information daily just after midnight (UTC) and purges previous summaries older than 180 days. To override these default intervals, follow the procedure below. Procedure 1. In the Service Center, select tenants > policy. 2. On the Policy Configuration page, set the following policies: billing.summary.collection.interval The interval between billing collections in milliseconds (ms). The default is ms (24 hours). billing.summary.purge.interval policies The number of days to retain billing summary records in the database. The default is 180 days. Records older than the interval are purged from the database. Set to 0 to retain all billing history in the database. 102

111 Reports Description of Record Layout The table below describes the values returned in each column. Column Name Sample Value Description snapshot Date and Time of record (format: yyyymmddhhmm) org_id 1001 The unique ID of the Organization/Tenant org_name Tenant A The name for the tenant identified by org_id datacenter_id 5925d361-4c1c-490e c5041d067b8e A unique ID that identifies the Datacenter location status enabled The status of the tenant: Enabled, Disabled, Error type_id 1cb3f348-f a33c- 742ef30d356b Unique Id for given Type: template for Template quota desktop if there are no quotas (all 0) and no in_use_count numbers. In this case, quota and in_use_count are set to -1 to indicate nothing was found for the tenant. desktop_model_name Pro This value is blank for a Template.Quota model_protocols 31 If the type is PROTOCOL, this column indicates the bitmask value for that protocol. RDP = bit 0 RGS = bit 1 HDX = bit 2 VNC = bit 3 NX = bit 4 PCoIP = bit 5 quota 17 Error Value of -1 For example, the bitmask 31 means RDP, RGS, HDX, VNC, and NX are available and the bitmask 1 means only RDP. If the type is DESKTOPMODEL, this column is ignored and contains 0. in_use_count 17 When Session Type= Number of sessions provisioned for; otherwise -1 indicates an error while the summary was being taken or that the system could not communicate with the tenant. The in_use_count can be higher than the quota only if the VMs exist on the hypervisor or are created outside the DaaS environment. This occurs only for Imported or Utility Desktop Model Quota mapped to the Imported, Recycle and Utility pools. date_updated :56: The last time this row was modified type PROTOCOL Indicates the type of quota (DESKTOPMODEL, SESSION, PROTOCOL, TEMPLATE) ANT: Whatever you put on the following lines will automatically propagate into the header and footer. (You don t need to open the head 103

112 System Maintenance 9 System Maintenance 9.1 Backing Up and Restoring Databases Back Up a Database Procedure Run the following command in the appliance: /usr/local/desktone/scripts/backup_db.sh P '<postgres_db_password>' This command extracts a PostgreSQL database into an archive file, creating a backup file of the form <hostname>.<timestamp>.tar.gz in the /usr/local/desktone/backup folder. Optional Commands backup_db.sh accepts the following optional command line arguments. Argument Description -P password Password for database user admin -V true Enable verbose mode -U username PostgreSQL username (default is postgres) Restore a Database The procedure below restores one database. Note the following: You must perform all restores on the primary appliance, and then re-initialize slony to populate the database to the secondary appliance. If you need to restore a tenant appliance, you might need to restore both the edb and fdb databases. Procedure 1. Run sudo bash and authenticate. 2. Stop dtservice for both service provider appliances or for both tenant appliances: service dtservice stop 3. Stop slony: service dtservice stop killall slon 4. On the primary appliance, complete these steps. a. Copy the backup file to a directory in /tmp (the file has the form <hostname>.<timestamp>.tar.gz): mkdir /tmp/backup_working cp /usr/local/desktone/backup/<filename> /tmp/backup_working 104

113 System Maintenance b. Extract the backup file: cd /tmp/backup_working tar zxvf <filename> c. Move to the directory where the.bak file exists and perform the restore. For example: cd usr/local/desktone/backup env PGPASSWORD=<pswd> /usr/local/pgsql/bin/pg_restore -i -w -U admin -d <type> -v --clean <filename> where: <pswd> is the postgres database password <type> is the file type (either edb, fdb, or avdb) <filenname > is the name of the extracted backup file 5. On both appliances, re-initialize slony. For instructions, see Slony Reinitialization below. 9.2 Changing Passwords Procedures below are specific to Service Provider appliance and the FDB database Change PSQL Password 1. Stop dtservice and slon on both SP appliances: service dtservice stop sudo killall slon 2. Run script to get new encrypted password: /usr/local/desktone/scripts/d.pl -e <new password> 3. DB Updates (run on both SP1 and SP2): alter user master with password '<cleartext password>' alter user slave with password '<cleartext password>' alter user slony with password '<cleartext password>' alter user admin with password '<cleartext password>' update organization set psql_password='<encrypted password>' where id=1000; 4. Alter files on file system (for both appliances): a. Edit /usr/local/desktone/release/active/conf/fdb.properties. Update the password with the new encrypted password: password=<encrypted password> b. Edit /usr/local/desktone/release/static/conf/slon_fdb.conf. Set password to new cleartext password. 5. Restart dtservice on SP1 and reinitialize slony on SP1 and SP Change Appliance Password 1. Stop dtservice and slony on both appliances: service dtservice stop sudo killall slon 105

114 System Maintenance 2. Change Linux password using the passwd command on each appliance. 3. Get encrypted version of new password: /usr/localdesktone/scripts/d.pl -e <new password> 4. Get data center id from the following file: /usr/local/desktone/.datacenter_id 5. Update datacenter table in the database: update datacenter set appliance_pass='<encrypted password>' where id=<datacenter id>; 6. Change the keystore: /usr/local/java/jdk/jre/bin/keytool -keytool -storepasswd -new '<cleartext appliance password>' -storepass <original appliance password> -keystore /usr/local/java/jdk/jre/lib/security/cacerts 7. Restart dtservice on SP1 and reinitialize slony. 9.3 Slony Reinitialization On each appliance in an Organization run these commands as root. Procedure 1. Stop dtservice on all nodes: service dtservice stop 2. Stop slon daemons (kill daemons on target nodes): killall slon 3. Run this command on the target db (FDB or EDB): drop schema _slony cascade; Note: Drop the schema only for the affected database pair. 4. If you stopped dtservice on the Primary service provider node for re-initialization of the FDB on the service provider appliances, then start the service again on the primary service provider node: service dtservice start 5. Start slon daemons as follows. For the service provider org, start the daemon for the FDB: /usr/local/desktone/scripts/start_slon_fdb.sh For the tenant org, start the daemons for both the FDB and the EDB: /usr/local/desktone/scripts/start_slon_fdb.sh /usr/local/desktone/scripts/start_slon_edb.sh 106

115 System Maintenance 6. In the Service Center, select appliances > maintenance. 7. In the Slony Operations section of the page, enter the following information: Organization id: Org ID of the appliance to which the init slony would be performed. DB instance name: Name of database instance for init slony. Element ID: ID of the Desktop Manager to list New Master IP for init slony operation. This option is visible when DB instance name is 'edb'. 8. Click Init Slony. 9.4 Database Failover Overview When the primary appliance fails, the secondary database is read-only. There are two procedures outlined below to address this situation: Enabling write operations on the secondary database Permanently promoting the secondary appliance to become the primary appliance Enable Write Operations on the Secondary Database The goal of this procedure is to switch the master database to the secondary appliance (tenant or service provider) in the event that the primary appliance is not available. The goal is to enable write operations so that the secondary appliance s database is the master datasource. Procedure 1. Stop the dtservice on both the primary (if accessible) and the secondary appliance: sudo service dtservice stop 2. Stop all slony daemons on both the primary (if accessible) and the secondary appliances: sudo killall slon 3. In the secondary appliance, connect to the fdb database and execute the following SQL command: fdb=# drop schema _slony cascade; 4. Repeat step 3 for the EDB if the appliance belongs to a tenant organization. 5. If the database on the primary appliance is still accessible, then backup the database, copy the database files and restore the database into the secondary appliance (for procedures, see Backing Up and Restoring Databases). 6. Open the file /usr/local/desktone/release/active/conf/fdb.properties for edit and remove the IP address of the primary appliance. 107

116 System Maintenance 7. Repeat step 6 for /usr/local/desktone/release/active/edb.properties if the appliance belongs to a tenant organization. 8. Start dtservice in the secondary appliance Promote the Secondary Appliance to Primary Appliance To permanently promote the secondary appliance to be the primary appliance, you need to reinitialize slony as described in the Slony Reinitialization section of this document. 9.5 Datacenters Failover Master Note: Wait for all appliances to come online before beginning this procedure. To failover a failed data center's primary node to a healthy data center's primary node, follow the procedure below. Procedure 1. In the Service Center, select appliances > maintenance. 2. In the Fail Over section of the page, enter the following information. Field Description Organization id Data Center name DB instance name Element ID: New master IP 3. Click the FailOverMaster button. 4. Restart the service provider appliances. Org ID of the appliance to which the failover will be done. Name of the Data Center where the appliance is residing to which the failover will be done. Name of database instance for failover. ID of the Desktop Manager to list New Master IP for failover. This option is visible when DB instance name is 'edb'. eth0 IP of the appliance to which the failover will be done. 108

117 System Maintenance Failback a Datacenter Note: The Service Center Portal may be unavailable for some steps during this process, make sure that you schedule the work at an appropriate time. To failback to a restored data center's primary node from a failover, follow the procedure below. Procedure 1. Stop the dtservice on all appliances that belong to the organization, across all data centers: service dtservice stop 2. Back up the fabric database from the current master node: /usr/local/desktone/scripts/backupdb.sh P < database password > This creates a file called <hostname>.<timestamp>.tar.gz in the /usr/local/desktone/backup folder. 3. SCP the backup file to the original master/primary node. 4. Extract the backup file: tar zxvf <hostname>.<timestamp>.tar.gz 5. Restore the backup on this original master node. Note: do this once for each database type. This means you will do this twice for tenant appliances, the first time should be for the fdb, and the second time should be for the edb. env PGPASSWORD=<pswd> /usr/local/pgsql/bin/pg_restore i w U admin d <ft> -v -- clean <fn> where: <pswd> = database password <ft> = EDB or FDB (done for each for tenant appliances, or just once for service provider appliances) <fn> = the path to the extracted file with respect to the <ft> parameter 6. Open a psql session to the fabric database on all service provider appliances: psql U admin fdb 7. Purge the _slony schema for all databases (master and slave): drop schema _slony cascade; 8. Exit from the psql session: \q 9. If you are restoring service provider appliances, start the dtservice on the original master database appliance (do not do this for tenant appliances): service dtservice start 10. In the Service Center, select appliances > maintenance. 11. In the Slony Operations section of the page, enter the following information: 109

118 System Maintenance Organization id: Org ID of the appliance to which the init slony would be performed. DB instance name: Name of database instance for init slony. Element ID: ID of the Desktop Manager to list New Master IP for init slony operation. This option is visible when DB instance name is 'edb'. 12. Click Init Slony. 13. Start dtservice on all remaining appliances (including the master for a tenant restore): service dtservice start Rename a Datacenter Overview When you bootstrap the primary service provider appliance, the bootstrap script (bootstrap.sh) prompts you to enter the name of the datacenter that hosts the service provider appliance. If you subsequently add an additional datacenter, do not enter the name of the first datacenter when bootstrapping the primary service provider appliance for the new datacenter. If you do inadvertently enter the wrong datacenter name, you will receive a FATAL message with a stack trace when the second stage of bootstrap.sh is run on the primary service provider appliance in the new datacenter. If this occurs, use the procedure described in this section to correct the datacenter name Edit final_config.txt The bootstrap script saves the values you enter to a file named final_config.txt in the /usr/local/desktone/scripts directory. To correct a misnamed Datacenter, you need to edit /usr/local/desktone/scripts/final_config.txt on the new primary service provider appliance, using an editor such as nano or vi. Here is an example of final_config.txt, with the DataCenter Name line highlighted: DataCenter Name: JAPAN Backbone VLAN ID: 3127 Hostname: bob-dc2-sp1 Eth1 IP: Eth1 Netmask: Backbone IP Block: /24 SP VLAN ID: 2109 Eth0 IP: Eth0 Netmask: Eth0 CIDR: 24 Gateway: HA Transit Server IP: Floating IP: DataCenter UID: 60cb3d08-ddc5-4a5a-9102-d35a7fbf6f73 PSQL pass: Nameserver: DataCenter Master: False Multi-DataCenter: True NTP Server 1: ntp.ubuntu.com Other Service Provider IP: To change the name from JAPAN to India: DataCenter Name: INDIA 110

119 System Maintenance Rerun bootstrap.sh After updating the datacenter name and saving final_config.txt, rerun stage 2 of bootstrap.sh and continue with the rest of the installation Decommision a Datacenter Note: All commands should be run with root credentials Execute Initial Shutdown Steps Procedure 1. Take snapshots of all service provider and resource manager appliances. 2. Take snapshots of all tenant appliances for any Multi-DC system. 3. Shut down service provider, resource manager and tenant appliances in DC2 (target datacenter to be decommissioned) Perform Initial Tenant Maintenance Complete the following steps on the remaining datacenter for all affected tenants. Procedure 1. Stop dtservice on all tenant appliances: service dtservice stop 2. Delete this file on all tenant appliances: /usr/local/desktone/release/active/conf/proxy.conf 3. Terminate Slony Daemon Process on all tenant appliances: killall slon 4. Remove Slony Schema on all tenant appliances (both FDB and EDB): drop schema _slony cascade; 5. Remove DC2 IP addresses from this file, on the line starting host= : /usr/local/desktone/release/active/conf/fdb.properties Promote the Primary Service Provider and Tenant to be the Primary Across Datacenters Procedure 1. Go to the psql prompt 2. Execute the following commands: update appliance set capabilities = 199 where name= <primarysp> update appliance set capabilities = 240 where name= <primarytenant> 111

120 System Maintenance Perform Initial Service Provider Maintenance on Remaining Datacenter Perform the following steps on the remaining datacenter. Procedure 1. Stop dtservice on all service provider appliances: service dtservice stop 2. Stop dtservice on all resource manager appliances: service dtservice stop 3. Delete this file on all resource manager appliances if it exists: /usr/local/desktone/release/active/conf/proxy.conf 4. Terminate Slony Daemon Process on all service provider appliances: killall slon 5. Remove Slony Schema on all service provider appliances (both FDB): drop schema _slony cascade; 6. Remove DC2 IP addresses from this file found on the service provider appliances, on the line starting host= : /usr/local/desktone/release/active/conf/fdb.properties Clean Up Proxychains Configuration Procedure Replace /etc/proxychains.conf with the clean version on all service provider, resource manager, and Multi-DC tenant appliances Clean Up FDB All commands should be run on the primary node. Procedure 1. On the service provider appliance: select * from datacenter; 2. From the previous query results, select the ID associated with the datacenter to be decommissioned and run the following commands on service provider FDB: delete from billing_summary where datacenter_id='<prev_query_id>'; delete from datacenter where id='<prev_query_id>'; 3. Run the same query from step 2 on the tenant FDB that is being decommissioned. 112

121 System Maintenance Re-initialize Slony on Affected Nodes Procedure 1. Start slony daemons on service provider appliances: /usr/local/desktone/scripts/start_slon_fdb.sh 2. Start slony daemons on all affected tenant appliances: /usr/local/desktone/scripts/start_slon_fdb.sh /usr/local/desktone/scripts/start_slon_edb.sh 3. Restart memcached on service provider appliance: service memcached restart 4. Start dtservice on Primary service provider node: service dtservice start 5. Initialize FDB for service providers: initslonyfororg(1000,<blank>,"fabric") 6. Initialize FDB for all affected tenants: initslonyfororg(orgid,<blank>,"fabric") 7. Initialize EDB for all affected tenants: initslonyfororg(orgid,remainingdcid,"element") 8. Confirm slony table replication set is limited to 2 nodes on both tenant and service provider appliances (query should return 2 rows): select * from _slony.sl_node; Slony should now be initialized correctly and the socks proxy configurations should be removed Bring the System Up Procedure 1. Restart memcached on other service provider appliance (not primary): service memcached restart 2. Start dtservice on other service provider appliance (not primary): service dtservice start 3. Reboot the resource manager appliances: reboot now 4. Start dtservice on tenant appliances: service dtservice start 5. Confirm that customers can access their desktops on the affected tenant. 6. [optional] Attempt to expand a pool on the affected tenant. 7. Review Quota and Hypervisor Host Assignment on affected tenant. 113

122 System Maintenance Final Tasks Once all systems appear to be functioning correctly: Delete the decommissioned datacenter s appliances. Delete the existing datacenter s appliance snapshots. 9.6 Monitoring Introduction This section describes basic monitoring of the DaaS environment. It also provides links to more detailed information about DaaS CIM providers and information about connectivity and ports. The intent of this section is to provide information on the major items that should be monitored in the DaaS environment. At this time VMware does not have preference for the monitoring tool to be used, and the choice is left to the provider. Therefore the methods of implementation will depend upon the monitoring tool selected Critical Nodes There are several nodes that are critical to proper functioning in a DaaS environment. In many cases the DaaS software is able to "self-heal". However, any impairment to these nodes should still be noted and potential action taken regardless of the DaaS software capability to "self-heal". Providing feedback on these occurrences is also important to improving the quality of the DaaS software. The nodes (whether iron or virtual) that should be actively monitored are listed below. Some of these are DaaS appliances and some are not. More details of the items that can be monitored are outlined later in this section. Service provider nodes: Active Directory ESX hosts Load balancer NFS server Network routers Time server DaaS nodes: Service Provider Tenant Resource Manager 114

123 System Maintenance Basic System Functions For each of the nodes listed under "Critical Nodes", these basic functions should be monitored: File system space CPU usage Memory usage The method of monitoring this information will vary depending upon the OS being monitored and the monitoring software itself. Please consult your monitoring software documentation for details Web Application Monitoring Basic verification of a DaaS installation includes connecting to the following web pages (both through a load balancer, if applicable, and directly to each node): Desktop Portal Administration console Service Center Port Response In addition to using ping, monitoring software can check response of specific ports - that is, if they respond to an "open socket" request. DNS and DHCP are exceptions which use UDP, and may require more intelligent monitoring Monitoring CIM Classes DaaS management nodes run a variety of CIM classes that provide information about system operation. See CIM Providers on DaaS Management Nodes below for more details CIM Providers on DaaS Management Nodes This chapter describes the CIM providers that monitor a DaaS installation. Key properties for monitoring are highlighted in the descriptions below Operating Environment CIM Providers for DaaS Nodes These CIM providers report on the operating environment for DaaS management nodes. They should be monitored on all DaaS nodes: Linux_OperatingSystem Linux_EthernetPort Linux_ComputerSystem CIM_FileSystem 115

124 System Maintenance Linux_OperatingSystem Description There will only be a single instance of this class per appliance. Properties FreePhysicalMemory: If this reaches 0 that is a critical fault and needs to be resolved immediately (see the calculation below). FreeVirtualMemory: If this reaches 0 0 that is a critical fault and needs to be resolved immediately (see the calculation below). HealthState: Anything but a value of 5 indicates a problem. OperationalStatus: Anything but a value of 2 (OK) indicates a problem. However, an occasional value of 4 (stressed) may appear. If repeated samplings indicate a value other than 2, you should raise an alert. TotalVirtualMemorySize: The total amount of swap space available to the system. Calculations PercentSwapUsed: 100 * ( TotalSwapSpaceSize FreeSpaceInPagingFiles ) / TotalSwapSpaceSize It is useful to monitor for swap space usage. Once the system begins using swap space, performance will degrade. The free memory alert should be triggered prior to the system using swap space so the use of swap should be considered a serious problem. Mitigation Recommendation is to warn if PercentSwapUsed > 5% and alert if PercentSwapUsed > 20%. If the memory used reaches high levels, you should check to see if there are any memory-intensive processes that need to be restarted using top and shift-m on the node in question: $ top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6816 root m 389m 13m S :36.97 java 6634 root m 84m 9.8m S :21.70 java... If no single application appears to be the culprit, restart the node Linux_EthernetPort Description There will typically be two instances of this class, one for the eth0 interface (tenant or service-provider network) and one for the eth1 (management backbone) interface. Properties EnabledState: Anything but the value 2 is a problem. Status: Anything but OK is a problem. Mitigation If the eth0 status is not OK, then use ifconfig to check that the interfaces are up and have an IP address. You should also be able to ping the IPv4 gateway for each node. 116

125 System Maintenance If the eth1 status is not OK, then try to connect to that appliance via ssh from the transit server. If this works, then the eth1 interface is OK Linux_ComputerSystem Description There will only be a single instance of this class per appliance. Properties EnabledState: Anything but a value of 2 indicates an issue. Mitigation If EnabledState is anything but 2, attempt to ping the node, ssh to the node, and check the status of the dtservice (service dtservice status) on the node CIM_FileSystem Description There are several subclasses of this. (You can also check the CIM_LocalFileSystem class if you don't want to view remote file systems.) The most important to focus on are all the Linux_Ext4FleSystem instances. In addition to the root file system, there may be others that are important to check that they are not in ReadOnly mode. Currently you should check these file systems: /(root) /boot /data /tmp /usr/local /var Additionally on the resource manager nodes and the DB nodes there will be some number of Linux_NFS instances. These are remotely mounted file systems. You can choose to monitor these mounts via our appliances or an alternate mechanism based on the storage system. Properties EnabledState: Any value other than 2 (enabled) on a remotely mounted NFS file system is cause for alarm. However, local file systems in management nodes may show up with an EnabledState of 3. ReadOnly: This value should be FALSE. A value of TRUE is cause for alarm. If the CIM_FileSystem class does not respond for a particular file system, the file system may be read-only and you should restart the node. Contact DaaS support if the restart fails. Status: Any value other than OK is cause for alarm. Go to the node and use mount to check that the file system is mounted. If the file system is mounted, try to create a file. PercentageSpaceUsed: Displays percent of available disk space that is used. Recommendation is to warn at 70% and then increase the alert priority in 10% increments (that is, 70, 80, 90). Mitigation If any of the file systems report high usage, please contact DaaS support for corrective action. 117

126 System Maintenance Application-Specific CIM Providers for DaaS Management Appliances Note: For non-daas-specific CIM provider classes, see Operating Environment CIM Providers for DaaS Nodes Service Provider Appliances The CIM providers for service provider appliances are as follows: Desktone_ApplicationServer Desktone_ApplicationServerStatistics Desktone_InstalledProduct Desktone_CommonDatabase Desktone_DatabaseService Desktone_DatabaseReplicationService Desktone_ActiveDirectoryStatus Desktone_HypervisorManagerStatus Desktone_NTPService Resource Manager Appliances The CIM providers for DaaS resource manager nodes are as follows: Desktone_ApplicationServer Desktone_ApplicationServerStatistics Desktone_InstalledProduct Desktone_NTPService Tenant Appliances The CIM providers for tenant appliances are as follows: Desktone_ApplicationServer Desktone_ApplicationServerStatistics Desktone_InstalledProduct Desktone_CommonDatabase Desktone_DatabaseService Desktone_DatabaseReplicationService Desktone_RemoteAccessManagerStatistics Desktone_ActiveDirectoryStatus Desktone_NTPService Desktone_XMPService 118

127 System Maintenance Desktop Manager Appliances The CIM providers for Desktop Manager appliances are as follows: Desktone_ApplicationServer Desktone_ApplicationServerStatistics Desktone_InstalledProduct Desktone_CommonDatabase Desktone_DatabaseService Desktone_DatabaseReplicationService Desktone_NTPService Description of DaaS CIM Providers Desktone_ActiveDirectoryStatus Description ActiveDirectoryStatus provider is derived from CIM_LogicalElement, and it provides information and status of domain controllers which are added in DaaS platform. This provider runs on service provider and tenant appliances. Properties CSCreationClassName [key]: Name of the class used to create the database instance. SystemName [key]: Name of the system on which the provider instance is running. Set to host name in our case. CreationClassName [key]: Name of the class used to create the provider instance. DcAddress [key]: describes the unique domain controller address. DomainName: describes the domain name associated with domain controller. LdapUri: describes the LDAP Url of current domain controller ResponseTime: describes the response time in milliseconds for LDAP query from DaaS appliance. The administrator should monitor this property and alert as required if it is preferred domain controller. Example: 0-15 seconds response time is OK, seconds is WARN, and >30 seconds is CRITICAL. LastUpdated: describes the last updated time for this controller IsPreferred: Indicates whether the domain controller is preferred domain controller or not in DaaS platform CommunicationStatus [derived]: indicates the ability of the DaaS platform to communicate with domain controller. 2 OK, 4 Lost Communication OperationalStatus [derived]: indicates the status of domain controller in DaaS platform. 2-OK, 13 Lost communication. Status [derived, deprecated]: indicates the current state of domain controller in DaaS platform (OK, Lost Comm) 119

128 System Maintenance Mitigation Make sure that preferred domain controllers are up and running, and verify the latency between appliance and domain controller if response time is high. Check the required communication ports are open between domain controller and DaaS appliances Desktone_ApplicationServer Description Provides information about the application server used by the DaaS software. Properties Name: Name by which the application server is identified. Set to "Jboss" for Element manager and Resource manager. SoftwareElementID: Identifier for software element to be used in conjunction with other keys to uniquely identify the element. Set to host name on which the application server is running. Version: Version of the application server. SoftwareElementState: This property defines the various states of software element's life cycle. For example: Running, Executable, Deployable etc. A SoftwareElementState of 3 indicates that the application server is running. Mitigation If the application server is not running, go to the node in question and check the status: $ service dtservice status Desktone Service is running under PID 6761 If the Desktone Service is not running, start it (and watch the log file): $ service dtservice start TargetOperatingSystem: Specifies the node's operating system environment. Set to 36 (LINUX) Desktone_ApplicationServerStatistics Description There will be a single instance of this class for all of the application appliances (that is, this will not be present in DB appliances). Properties These properties report on operations of the JVM (Java virtual machine) used for the DaaS application. InstanceID: Key to uniquely identify the instance of this class. Set to DesktonehostName_Jboss. ThreadCount: Total number of threads running during the monitoring sample. ThreadGroupCount: Total number of thread groups that exist during the sample time. HeapSize: Current size of heap memory MaxHeapSize: Maximum heap memory allowed on the application server. Uptime: The length of time the application server has been running in milliseconds. 120

129 System Maintenance Calculations Heap size used: 100*HeapSize/MaxHeapSize. Recommendation is to warn at 85% and then increase the alert priority in 5% increments (that is, 90, 95, 100). Mitigation At 85%, schedule a restart of the dtservice. At 90% or higher, restart the dtservice immediately: $ service dtservice restart If the heap memory used increases to high levels often (more than once per week), you should analyze your environment in concert with DaaS support Desktone_CommonDatabase Description Describes the PostgreSQL server running on database nodes. Properties InstanceID: Key to uniquely identify the instance of this class. Set to Desktone_hostName_postgreSQL. HomeDirectory: Home directory of the PostgreSQL service. DataDirectory: Data directory of the PostgreSQL service. DatabaseVersion: Version number of the database. MaxConnections: Maximum number of connections that the PostgreSQL server can manage concurrently. The value is extracted from the PostgreSQL configuration file from the parameter "max_connections". Status: Indicates the current status of the PostgreSQL server. OK indicates PostgreSQL is running. STOPPED indicates that the database is stopped. If the database is down (status STOPPED), any other data provided should be ignored. ListenAddress: The port and ip address on which postmaster process is listening for new connections. Calculations Percent maximum connections used: You should total up the ActiveConnections used by each database instance on the server (see Desktone_DatabaseService provider) and divide by the MaxConnections from this class to determine the load on the database server. That is: 100*(Sum(ActiveConnections)/MaxConnections). Mitigation If the database is stopped, check the database server: $ service postgresql status If PostgreSQL is not running, start the service, then run the status command again: $ service postgresql start $ service postgresql status If the database will not start, examine the PostgreSQL logs and contact DaaS support. The recommendation is to warn at 80%, critical at 90% of Percent maximum connections used. If the percent maximum connections reaches the critical level, you should examine the database server to determine which cache node or nodes is consuming a large number of connections (5-10 connections is the normal range for a cache node): $ netstat -an grep

130 System Maintenance Desktone_DatabaseService Description Specifies the details of database instances running on DaaS appliances. In the DaaS platform, appliances have one or more database instances running, as follows: Service provider appliances Fabric Database (FDB) only Tenant appliances - Fabric Database (FDB) and Element Database (EDB) Desktop manager appliances - Element Database (EDB) only Properties Name: Unique identification of the service. Set to hostname_dbinstancename. For rollback purposes, upgrades will create a db name_version instance. You do not need to monitor the database instances that have the version appended. ActiveConnections: Specifies the number of active connections to this database instance at the time of sampling/monitoring. See the calculation for Desktone_CommonDatabase using this number totaled across all database instances on a server compared to the maximum connections permitted on a single database server Desktone_DatabaseReplicationService Description Provides information about database instances that are replicated. This provider runs on all Fabric database servers. In the DaaS platform, appliances have one or more database instances running, as follows: Service provider appliances Fabric Database (FDB) only Tenant appliances - Fabric Database (FDB) and Element Database (EDB) Desktop manager appliances - Element Database (EDB) only Properties SystemCreationClassName: Name of the class used to create the database instance. SystemName: Name of the system on which the database instance is running. Set to host name in our case. CreationClassName: Name of the class used to create the database instance. Name: Unique identification of the service. Set to hostname_databaseinstancename. NodeID: Represents the UID of the node in the context of the replication system. Role: Indication of whether the database instance is master or slave instance. SyncStatus: Synchronization status applies to the slave instance only. This property does not have any significance in case of master instance. For a slave instance, the SyncStatus value will be the number of milliseconds since the last synchronization. For example, SyncStatus = 1200 means that the last successful sync was 1.2 seconds before. Warn if the SyncStatus is more than 40 seconds old. Critical if SyncStatus is more than 2 minutes old. Status: Indicates the current status of the replication service. OK indicates the replication service is running. STOPPED indicates that the replication service is stopped. The replication service should be running for all database instances in use. 122

131 System Maintenance Mitigation If replication is stopped (or if the SyncStatus is out of date), you should check that the replication daemon (slony) is running properly on the database server: $ ps -ef grep db.conf root Sep17? 00:00:00 /usr/local/pgsql/bin/slon -f /usr/local/desktone/release/static/conf/slon_edb.conf root Sep17? 00:00:00 /usr/local/pgsql/bin/slon -f /usr/local/desktone/release/static/conf/slon_fdb.conf root Sep17? 00:07:39 /usr/local/pgsql/bin/slon -f /usr/local/desktone/release/static/conf/slon_edb.conf root Sep17? 00:06:01 /usr/local/pgsql/bin/slon -f /usr/local/desktone/release/static/conf/slon_fdb.conf There should be 2 processes for each database instance. If replication is not running properly for any of the instances, you can restart replication: $ nohup /usr/local/pgsql/bin/slon -f /usr/local/desktone/release/static/conf/slon_fdb.conf >/dev/null 2>&1 & $ nohup /usr/local/pgsql/bin/slon -f /usr/local/desktone/release/static/conf/slon_edb.conf >/dev/null 2>&1 & Desktone_HypervisorManagerStatus Description HypervisorManagerStatus provider is derived from CIM_LogicalElement, and it provides information and status of Hypervisor Managers in DaaS platform. The Hypervisor Manager is a DaaS entity which manages the hypervisor hosts. This provider runs on service provider appliances only. Properties CSCreationClassName [key]: Name of the class used to create the database instance. SystemName [key]: Name of the system on which the provider instance is running. Set to host name in our case. CreationClassName [key]: Name of the class used to create the provider instance. HostAddress [key]: describes the hypervisor manager host address and version. It is an address of vcenter, ESX, or vcloud host. Type: describes the type of hypervisor manager whether it is vcenter/esx/ vcloud and its product version. Ex: "ESX, 5.1.0" CommunicationStatus [derived]: indicates the ability of the DaaS Hypervisor Manager to communicate with Hypervisor Host. 2 OK, 4 Lost Communication OperationalStatus [derived]: indicates the current status of the DaaS Hypervisor Manager in DaaS platform. 2- OK, 13 Lost communication, Status [derived, deprecated]: indicates the current status of DaaS Hypervisor Manager in DaaS platform (OK, Lost Comm) Mitigation Make sure that discovered host is assigned to resource manager. Make sure that Hypervisor host is running and reachable from service provider appliance. Please verify if there any API compatibility errors in service provider or resource manager desktone logs. Check the required communication ports are open between DaaS appliances and hypervisor hosts. 123

132 System Maintenance Desktone_InstalledProduct Description Provides information about the DaaS software, including the version and build number. Properties ProductIdentifyingNumber: Product identification. This property contains build information. ProductName: Product's commonly used name. Set to "Virtual-D." ProductVendor: Vendor's name: Desktone. ProductVersion: Product version information SystemID: Host name where the product is installed Desktone_NTPService Description NTPService provider is derived from CIM_Service, and it provides information about NTP daemon which runs on DaaS appliance. It also reports time synchronization status. Properties CSCreationClassName [key, derived]: Name of the class used to create the database instance. SystemName [key, derived]: Name of the system on which the NTP daemon is running. Set to host name in our case. CreationClassName [key, derived]: Name of the class used to create the provider instance. name [key, derived]: describes the name of the service. It is NTPD in our case. Started[derived]: Started is a Boolean that indicates whether the NTP Service has been started (TRUE), or stopped (FALSE). ServerAddresses: describes the NTP server addresses configured in /etc/ntp.conf. It is a comma separated string of addresses. PrimarySource: describes the current NTP source in use for time synchronization. SyncState: indicates NTP synchronization status. TRUE, if NTP is in sync with time source, otherwise FALSE. The SyncState depends on jitter, condition of peer and reach status. Jitter: describes the jitter value in milliseconds of selected time source. If there is any problem to get the jitter or no primary source is selected by NTP, it returns milliseconds in order to alert. Providers marks SyncState property to FALSE if jitter is higher than 1000 milliseconds. OperationalStatus[derived]: indicates the current status of NTP daemon and time synchronization. OperationalStatus=2 (OK) -> NTP time is in sync (SyncState =TRUE) and all time sources configured are reachable. OperationalStatus=5 (Predictive Failure) indicates NTP time is in sync, but one or more configured time servers are not reachable or rejected. OperationalStatus=6 (ERROR) time source is not in sync or NTP service is down StatusDescriptions [derived]: describes the OperationalStatus in detail which helps administrator troubleshoot NTP time synchronization. 124

133 System Maintenance Desktone_XMPService Mitigation Make sure that NTP daemon is running. Troubleshoot NTP for time synchronization. Make sure that there is connectivity between the service provider nodes and the NTP source. Description Desktone_XMPService provides information about the XMP service. Properties PrimaryStatus: 0 indicates XMP service status Unknown; 1 indicates XMP service status is OK WBEM and CIM The DaaS management appliances allow monitoring via the standard WBEM (web-based enterprise management) CIM (common information model) interface. You can use any monitoring tool capable of understanding the CIM data model (for example, Tivoli) Connecting to the WBEM/CIM Server of a DaaS Management Appliance To log in to the WBEM/CIM interface of one of the DaaS management appliances, you need the following information: Host name: The DNS name or IP address of the management appliance Port number: 5989 Namespace: /root/cimv2 For example, CIMSurfer is a basic browser for CIM information. In practice, you would use a different tool, such as Tivoli, that automatically monitors a number of management appliances and provide alerts based on conditions in the CIM classes of interest. This example also accesses the CIM server without a certificate. CIM Server Login The following figure shows the type of information available from the Linux_OperatingSystem class. Using the properties, you can determine the amount or percentage of free memory that is still available. 125

134 System Maintenance CIM Classes Using WBEM/CIM to Monitor ESX Hosts Since the ESX hosts also expose a WBEM/CIM interface, you can also monitor the ESX hosts. Logging in to the ESX is the same as logging into a management appliance, except that user credentials are required. The login credentials should be the same ones you use to access the host using the VI client: Logging in to the ESX 126

135 System Maintenance The following figure illustrates how the ESX hosts will expose different classes than the DaaS management appliances. We recommend that you consult VMware to determine which classes are important to monitor. Classes Exposed by ESX Host + 127