WHITE PAPER Using Marathon everrun MX 6.1 with XenDesktop 5 Service Pack 1

Transcription

1 WHITE PAPER Using Marathon everrun MX 6.1 with XenDesktop 5 Service Pack 1

2 Contents Introduction... 2 Executive Overview... 2 Marathon everrun MX 6.1 (description by Marathon Technologies)... 2 Test Environment Overview (details in a later section)... 3 Initial tests user test... 3 Introduction... 3 DAL Stress Test tool... 4 High Availability events... 4 Observations... 5 Test Environment Detail... 5 Environment... 5 XenServer Pools and Hosts... 5 Virtual Machines by XenServer Pool... 6 Other environment... 6 Installing Marathon everrun MX on the Marathon-A pool... 6 Marathon everrun Availability Center console Accessing the console, and configuring marathon everrun MX Protecting the SQL Server VM May 2011 Page 1 of 9

3 Introduction XenDesktop 5 relies on the use of an SQL database to store state information : which Virtual Desktop groups are available, which Virtual Desktop Appliances are in use, and which users are using them. Because of the real-time nature of this state information, it is not appropriate for updates to be lost or delayed in the event that the SQL database becomes unavailable. For this reason, some users may feel that they need a highly available SQL database to support their business needs, and HA (High Availability) can be an important requirement for these deployments. This document explores the possibility of using Citrix XenServer and Marathon everrun MX 6.1 to support a highly available Microsoft SQL Server. Executive Overview A number of tests were performed to see whether Marathon everrun MX 6.1 could support a highly available Microsoft SQL Server for use by XenDesktop 5 Service Pack 1. These tests included setting up a constant stream of SQL traffic between a XenDesktop 5 Service Pack 1 broker, and the SQL Server. High Availability events such as loss of a host or loss of network connectivity were then induced to see if the SQL traffic could be interrupted. The result of the tests showed that Marathon everrun MX was able to handle the High Availability events, and was able to keep the SQL Server running without service interruptions, loss of data, or loss of in-flight transactions that might have caused problems with XenDesktop 5 Service Pack 1. Performance tests were not appropriate with the available hardware. Marathon everrun MX 6.1 (description by Marathon Technologies) Marathon s everrun MX is a software product that provides zero-downtime fault tolerant protection for Windows application operating in a XenServer pool. With everrun installed, the administrator uses a wizard-based GUI to simply select and protect a VM. Once protected, everrun provides continuous, uninterrupted application availability. Unlike traditional failover technologies there is no downtime or restart of the VM required. In the event of a failure, the application automatically continues without loss of data or interruption of network sessions and all in-flight transactions are completed. everrun protects any Microsoft application without requiring scripting, modification or specialized administrative skills. In addition, everrun s disk mirroring technology permits use of local disk storage without the requirement for costly and complex shared storage devices. everrun operates by running redundant VM s operating across 2 XenServer hosts. Marathon s Lockstep technology synchronizes the redundant VM s so they execute identically. In the event of a failure, the surviving VM simply continues to operate without interruption. When a failed component is repaired, redundancy is transparently and automatically re-established. For full details of Marathon everrun MX see 23 May 2011 Page 2 of 9

4 Test Environment Overview (details in a later section) Microsoft SQL Server 2008 R2 was installed on a Windows Server 2008 R2 VM running in a highly available XenServer / Marathon everrun MX pool. XenDesktop 5 Service Pack 1 Broker was installed on a Windows Server 2008 R2 VM running in a standard XenServer pool. XenDesktop 5 Service Pack 1 Broker and SQL stress tool were installed on a Windows Server 2008 R2 VM running in a standard XenServer pool. Three XenDesktop 5 Service Pack 1 Virtual Desktop Appliances (VDAs), running on Windows 7 32-bit, were provisioned by the XenDesktop 5 Service Pack 1 Broker. Initial tests The purpose of these tests was restricted to confirming that Marathon everrun MX was working correctly and that XenDesktop 5 Service Pack 1 was able to see and use the SQL Server. The first test was a simple ping test from a XenDesktop 5 Service Pack 1 Broker, to the SQL Server. A cmd window was opened on the XenDesktop 5 Service Pack 1 Broker and a constant ping command to the SQL Server was started (ping t marathonsql). The XenServer/Marathon Pool Master host was shutdown, causing the SQL Server VM to be continued on the second XenServer/Marathon host. Monitoring the output from the ping command(above), the only indication that a High Availability event had occurred was that an occasional ping round-trip took 2 to 10 milliseconds instead of the normal less than 1 millisecond. This second test run used a single XenDesktop 5 Service Pack 1 Broker, and the three XenDesktop 5 Service Pack 1 VDAs. TestUser1 logged into the Web Interface on the XenDesktop Broker, and launched a XenDesktop session. TestUser1 disconnected from the XenDesktop session without logging out. The XenServer/Marathon Pool Master host was shutdown, causing the SQL Server VM to be continued on the second XenServer/Marathon host. TestUser1 reconnected to their pre-existing XenDesktop session. Because TestUser1 was able to reconnect to their pre-existing XenDesktop session, it can be assumed that state information was retained across the HA event. Because it was unlikely that a small number of testers would be able to induce traffic that might coincide with further HA events, no additional tests were done with this XenDesktop farm user test Introduction The purpose of this test was to establish a constant stream of SQL traffic between a XenDesktop 5 Service Pack 1 broker, and the SQL Server. High Availability events were then induced to see if the SQL traffic could be interrupted. 23 May 2011 Page 3 of 9

5 DAL Stress Test tool Citrix has written the DAL Stress Test tool that uses standard XenDesktop 5 Service Pack 1 Broker code, to generate multiple SQL updates. The SQL updates are consistent with those that would be generated by multiple users connecting to, and disconnecting from their desktops. The DAL Stress Test tool was run for 24 hours with the following parameters:- Simulated Brokers 2 Simulated Private VDAs 1000 Minimum session length 3 seconds Average session length 123 seconds Steady state: Launch rate 8.1 sessions per second Launch interval 123 milliseconds Limited at: Launch rate 9.6 sessions per second Launch interval 104 milliseconds High Availability events While the DAL Stress Test tool was running, the following HA events were induced. The XenServer/Marathon Pool Master host (Host-A1) was shutdown. o This caused the SQL Server VM to be continued on the second XenServer/Marathon host (Host-A2). o The Host-A2 became the Pool Master. Host-A1 was restarted. o The Marathon detected that Host-A1 had become available. o High Availability status was restored. Host-A2 was shutdown. o This caused the SQL Server VM to be continued on Host-A1. o Host-A1 became the Pool Master. Host-A2 was restarted. o The Marathon detected that the host had become available. o High Availability status was restored Availability Link cable between Host-A1 and Host-A2 was removed Availability Link cable between Host-A1 and Host-A2 was restored o High Availability status was restored Availability Link 2 cable between Host-A1 and Host-A2 was removed Availability Link 2 cable between Host-A1 and Host-A2 was restored o High Availability status was restored 23 May 2011 Page 4 of 9

6 Primary network cable to Host-A1 was removed Primary network cable to Host-A1 was restored o High Availability status was restored In addition to the above physical interventions, everrun Availability Center was used to simulate various failures in host, disk and network objects. Observations everrun operated as designed providing continuous operation of the SQL service; the SQL service ran without interruption for the full duration of the test, and neither the DAL Stress Test tool, nor the SQL Server seemed to be aware of the underlying High Availability events. XenServer s design requires reconnection of management interfaces after the failure of the pool master. As a result, when a master host failed it was necessary for the administrator to reconnect the XenCenter and everrun management interfaces. It is worth noting that this was expected behaviour, and during this period, no SQL Transactions were lost, and the HA event was not perceivable to the VDI end user (during connects, disconnects or re-connects). everrun provides a web-based management GUI specifically designed to manage the availability of protected VMs. When choosing to protect a VM with Marathon everrun MX, the following observations were made related to XenCenter s treatment of protected VMs: o everrun supports snapshots of a protected VM. However, any snapshots taken of a VM prior to being protected by everrun will become disconnected from the VM within XenCenter. o Network information such as MAC address and IP address is no longer visible in the XenCenter network tab for the protected VM. Test Environment Detail Environment The tests were run in a test lab in Citrix s Chalfont office in the UK, and generally used existing hardware and network infrastructure. The 1 Gigabyte network infrastructure is based on small business unmanaged network switches, and cross-over cables were used to provide the Availability links between the hosts in the XenServer pool Marathon A pool. XenServer Pools and Hosts The primary hardware used for these tests existed in 2 XenServer pools. XenServer Pool Marathon-A No shared storage. XenServer Host-A1 - Dell R610, 96 Gigabytes memory, four 4 core 2.26 GHz Intel Xeon (L5520), two dual port Gb NIC, 500 Gigabyte SATA disk XenServer Service Pack 2 (Build 39265x) Marathon everrun MX Version 6.1 (Beta 2) XenServer Host-A2 - Dell R610, 96 Gigabytes memory, four 4 core 2.26 GHz Intel Xeon (L5520), two dual port Gb NIC, 500 Gigabyte SATA disk 23 May 2011 Page 5 of 9

7 XenServer Service Pack 2 (Build 39265x) Marathon everrun MX Version 6.1 (Beta 2) Note - At the time of writing, Marathon everrun MX 6.1 had not been finally released. For this reason, and because each release of Marathon everrun MX, is tightly coupled to a specific build of XenServer, late beta versions of both products were used in this XenServer pool. XenServer Pool XenDesktop-B iscsi based shared storage. XenServer Host-B1 Dell T7500, 48 Gigabytes memory, 6 core 2.4 Ghz Intel Xeon, three Gb NIC, 500 Gigabyte SATA disk. XenServer 5.6 Service Pack 2 XenServer Host-B2 Dell T7500, 48 Gigabytes memory, 6 core 2.4 Ghz Intel Xeon, three Gb NIC, 500 Gigabyte SATA disk. XenServer 5.6 Service Pack 2 Virtual Machines by XenServer Pool Marathon-A VMs MarathonSQL Windows Server 2008 R2 2 CPU, 2 Gigabytes memory Microsoft SQL Server 2008 R2 XenDesktop-B VMs MarathonDDC1 Windows Server 2008 R2 2 Gigabytes memory DDC - XenDesktop 5 Service Pack 1. Web Interface - XenDesktop 5 Service Pack 1 MarathonDDC2 Windows Server 2008 R2 2 Gigabytes memory XenDesktop 5 Service Pack 1 Broker XenDesktop 5 Service Pack 1 SQL Stress tool. Three VDA Windows 7 64-bit 1 CPU, 1 Gigabyte memory XenDesktop 5 Service Pack 1 VDA Other environment Domain Controller - Windows 2008 Installing Marathon everrun MX on the Marathon-A pool Each host was connected to the corporate LAN through its first NIC. In an enterprise environment it is likely that this connection to the corporate LAN would be a Bonded Network with two NICs on each host. The second NICs on each host were interconnected through a crossover cable to establish an Availability Link. 23 May 2011 Page 6 of 9

8 The third NICs on each host were also interconnected through a crossover cable to establish a backup Availability Link 2. XenServer 5.6 Service Pack 2 was installed on each host. Marathon everrun MX 6.1 was installed on the XenServer Pool Master. The process of installing everrun MX was simple and had a similar look and feel to that of installing XenServer itself. We chose to install it from a physical console connected to the XenServer hosts. In essence to process is:- o Insert the everrun MX CD in a XenServer host o Use the XenServer console to mount the everrun MX CD o Use the XenServer console to start the everrun MX install wizard. Accept EULA Identify local Storage Repository that will be used to hold EverRun MX components. Note. Marathon everrun MX 6.1 will only install if there is some local disk storage of type LVM (the default) on each host. It will not install on shared disk storage, or local disk storage of type EXT3. o o End Wizard Reboot host. Marathon everrun MX 6.1 was installed on the second XenServer host. This process is almost identical to installing everrun MX on the Pool Master. Marathon everrun Availability Center console. Accessing the console, and configuring marathon everrun MX. Point a browser at port 8080 of the XenServer Pool Master ( e.g. We used Internet Explorer 8 with the Shockwave Flash extension enabled. Login with the XenServer host credentials. Typically the username is root. The everrun MX Availability Center console is displayed. Configure an Isolation IP Address for the Pool (see help for details of how to do this). The Isolation IP Address is the IP address of a reliable independent device on the network. By pinging this device, the Marathon everrun MX agent can monitor the integrity of its network connections. (In our tests we chose a fileserver as the Isolation IP device) Protecting the SQL Server VM Confirm that the SQL Server VM is visible to everrun MX, and is a candidate for Protection at level 3. o In the top right panel of the Availability Center, select the Virtual Machine Status tab o Confirm that the SQL Server VM is visible o The Candidacy column should indicate the VM is a candidate for Protection at level 3 Protect the SQL Server VM ( the SQL Server VM will be rebooted during this process). o In the top right panel of the Availability Center, select the Virtual Machine Status tab. o Right click on the SQL Server VM Choose Protect Choose Level 3 protection 23 May 2011 Page 7 of 9

9 o o o Marathon everrun MX will make the necessary changes to the SQL Server VM. You will notice that there are now two copies of the SQL Server VM. One on each XenServer host. The primary copy has a name suffixed with CI1, and the secondary copy has a name suffixed with CI2. Start the primary CI1 copy of the VM, and login as an administrative user. You will notice that Marathon replaces certain XenServer drivers with those of its own. You may be asked to confirm that this is OK. Once these drivers have been replaced, a further reboot may be required. Once this reboot is complete, the VM is protected. Full details of how to install and use Marathon products can be found in appropriate Marathon documentation. 23 May 2011 Page 8 of 9