Tintri Deployment and Best Practices Guide for VMware vcenter Site Recovery Manager 5.8

Transcription

1 TECHNICAL WHITE PAPER Tintri Deployment and Best Practices Guide for VMware vcenter Site Recovery Manager 5.8 v1.0 Nov

2 Contents Intended Audience... 4 Executive Summary... 4 Assumptions... 4 VMware vcenter Site Recovery Manager with Tintri VMstore Overview... 4 Consolidated List of Practices... 6 Prerequisites... 6 Licensing... 6 vsphere... 6 vcenter Server... 6 Site Recovery Manager... 7 Microsoft Windows and Microsoft SQL Server... 7 Tintri VMstore... 8 Site Recovery Manager System Requirements... 8 Site Recovery Manager Network Ports... 9 Operational Limits of Site Recovery Manager... 9 Requirements for Using Microsoft SQL Server with Site Recovery Manager... 9 Requirements for Using Oracle Server with Site Recovery Manager...10 Requirements for Tintri VMstore Configuration...11 Create an ODBC System DSN for SRM in the host you chose for the SRM Server Prerequisites Procedure Site Recovery Manager Server Installation Pre-installation Checklist Install Site Recovery Manager Server Install Tintri SRA Connect the Site Recovery Manager Server Instances on the Protected and Recovery Sites Install the Site Recovery Manager License Key Configure Inventory Mappings Create resource mappings Create folder mappings Create network mappings Configure Placeholder Datastore Configure the Tintri VMstores

3 VMstore in the Recovery Site Add Array Manager and Enable Array Pair Create a Protection Group Create Recovery Plan Testing Test Recovery Plan Running a Recovery Plan Reprotect Conclusion References Tintri VMware Microsoft

4 Intended Audience This Best Practices Guide for running VMware vcenter Site Recovery Manager (SRM) on Tintri VMstore systems is intended to assist Data Protection and Disaster Recovery Administrators, IT Administrators and Architects who are responsible for deploying and managing a Disaster Recovery (DR) strategy within their virtual infrastructures powered by Tintri VMstore storage appliances. This guide focuses specifically on SRM 5.8 and therefore all instructions and screenshots focus on the vsphere Web Client although the Tintri Storage Replication Adapter (SRA) supports version SRM 5.5 as well. If you are not already versed in VMware SRM, we recommend you follow the content within this guide to create one or more SRM Recovery Plans in a test environment to gain familiarity with the technologies prior to deploying and configuring SRM a production deployment for use with Tintri VMstore systems. Executive Summary VMware vcenter Site Recovery Manager is disaster recovery solution that provides automated orchestration and non-disruptive testing of centralized recovery plans for all virtualized applications - see more at: Site Recovery Manager 5.8 brings additional enhancements for managing DR workflows. The most visible change is that SRM 5.8 is fully integrated as a plug-in with the vsphere Web Client. In addition to not having to use two different interfaces to manage virtual environments, improvements were also made to a few workflows making it easier and simpler to map arrays, networks, folders, etc. by having SRM handle the reciprocal instead of having to do it manually. This guide will walk you through the process of setting up VMware vcenter Site Recovery Manager 5.8 on Tintri VMstore 3.1 and provide best practice guidelines to implement a Disaster Recovery solution that is as unobtrusive as possible in day to day (normal) operations, but still provides you with the RPO (Recovery Point Objective) and RTO (Recovery Time Objective) you need for your business. Assumptions This document assumes you are working with a fully configured virtual infrastructure. It also assumes that, in case you are leveraging Microsoft Active Directory (AD) for authentication and policy management and enforcement, that there already is a non-srm-based AD disaster recovery plan in place (e.g. leveraging AD Native Replication) as per Microsoft Best Practices. AD should not be replicated using storage replication technology, as it could potentially cause a USN rollback scenario. Refer to the Microsoft articles listed on page 40 for more information on this. VMware vcenter Site Recovery Manager with Tintri VMstore Overview Legacy disaster recovery strategies that depend on manual procedures and complex run books to execute require highly specialized staff, large investments and complex coordination from several teams responsible for different layers of the data center infrastructure. VMware Site Recovery Manager, combined with Tintri VMstore, shields users from having to manage many of the steps required for traditional recovery. Tintri ReplicateVM provides the ability to configure replication at the virtual machine level. Setting up a recovery plan can be done in a matter of minutes, instead of weeks. Ongoing disaster recovery provisioning to new virtual machines can be driven through predefined policies. Actual execution of testing, recovery and migration workflows is fully automated to eliminate operational complexity. 4

5 Tintri ReplicateVM provides extremely WAN-efficient array based replication between Tintri VMstores. Tintri s Storage Replication Adapter (SRA) leverages the easy management and WAN-efficient replication capabilities of Tintri OS to provide SRM integrated DR workflows, resulting in an extraordinarily simple and quick setup, followed by minimal replication traffic between VMstores, saving bandwidth and time and therefore lowering TCO. The performance impact on each VMstore is also minimal, ultimately resulting in enabling an unobtrusive DR strategy with incredibly low TCO. Figure 1 SRM with Array-Based Replication (ABR) 5

6 Consolidated List of Practices The list below includes the recommended practices in this document. Click the text on any of the recommendations to jump to the section that corresponds to each recommendation for additional information. DO: Use a Microsoft SQL Server database when deploying SRM rather than embedded PostgreSQL database. DO: Install the same version of Site Recovery Manager Server and vcenter Server on both sites (protected and recovery). DON T: Use a Tintri VMstore as a Placeholder Datastore. Use either local hard drives or non-tintri shared storage. DO: Make sure you have a ReplicateVM license for your Tintri VMstores. DO: We recommend trying VM-consistent first in a test environment, with copies of the production applications and testing if the impact is acceptable or not. DO: Create a Service Group for each SRM Array Manager Pair i.e. pair between Protected and Recovery VMstores that you plan on creating in SRM. There is a 1:1 mapping between Tintri Service Groups and SRM Array Manager Pairs. DON T: Try and Add a pair of array managers before you create the corresponding Service Group in the Primary s VMstore. The array manager pair creation in SRM will fail if there isn t a corresponding Service Group already created via the Tintri GUI. DON T Run a Recovery Plan for testing; use the Test Recovery Plan feature for testing. Prerequisites Licensing vsphere Site Recovery Manager is supported with any edition of vsphere, except for vsphere Essentials. vsphere licenses are required for all servers on which vsphere is installed, whether that host is at a protected site or a recovery site and whether a server is running or powered down at the recovery site. Site Recovery Manager requires at least one licensed vsphere server at both the protected site and the recovery site. vcenter Server Site Recovery Manager is supported with vcenter Server for Essentials, vcenter Server Foundation and vcenter Server Standard. Site Recovery Manager requires two active and licensed vcenter Server instances, one at each site (protected and recovery). NOTE: The shared recovery sites feature in Site Recovery Manager enables multiple protected sites with multiple vcenter Server instances to be recovered at a site with a single vcenter Server instance. (i.e., the multiple instances of Site Recovery Manager running at the shared recovery site are registered with the same single instance of vcenter Server at the shared recovery site, so you do not need multiple vcenter Server instances at the shared recovery site.). 6

7 Site Recovery Manager The latest version of Site Recovery Manager can be purchased either as a standalone product or as part of VMware vcloud Suite Enterprise Edition. As a standalone product, Site Recovery Manager is available in two editions, Standard and Enterprise, which can only be purchased on per virtual machine licensing model. Site Recovery Manager Enterprise edition can also be purchased as part of vcloud Suite Enterprise edition. In this case, Site Recovery Manager is purchased on a per processor licensing model. Site Recovery Manager Enterprise provides enterprise-level protection to all virtualized applications with no licensing restriction on the number of virtual machines that can be protected. Site Recovery Manager Standard is designed for smaller environments and is limited to 75 protected virtual machines per physical site and per Site Recovery Manager instance. Only virtual machines that are protected by Site Recovery Manager require Site Recovery Manager licensing. There are two scenarios to consider: Uni-directional protection: Site Recovery Manager is configured only to fail over virtual machines from site A to the site B. In this case, licenses are required only for the protected virtual machines at protected site A. Bi-directional protection: Site Recovery Manager is configured to fail over virtual machines from site A to site B at the same time that it is configured to fail over a different set of virtual machines from site B to site A. In this case, Site Recovery Manager licenses must be purchased for the protected virtual machines at both sites. Licenses are required for all protected virtual machines, even if they are powered off. To fail back from site B to site A (after failover from site A to site B), Site Recovery Manager licenses are required for the re-protected virtual machines at Site B. The per virtual machine licenses originally used at site A can be used at site B for this purpose, as long as the licenses are no longer in use at site A. If Site Recovery Manager is being licensed per processor through the vcloud Suite Enterprise at site A and virtual machines are failed over to a site B that originally licensed with vsphere only, the vcloud Suite licenses can be transferred to site B in order to re-protect and fail back the virtual machines. Refer to VMware vcenter SRM 5.8 FAQ for more information. Microsoft Windows and Microsoft SQL Server You must install a Site Recovery Manager Server instance at the protected site and also at the recovery site. Furthermore, it is recommended that you use (and license) a Microsoft SQL Server database rather than the embedded PostgreSQL database. SRM 5.8 supports SQL Server 2005, 2008, 2012 and 2014 in almost all its incarnations (including Express, Standard and Enterprise, 32-bit and 64-bit). Check for details. DO: Use a Microsoft SQL Server database when deploying SRM rather than embedded PostgreSQL database. SRM Server can run on the same Windows host operating systems as vcenter Server that, as of SRM Server 5.8 and vcenter Server 5.5 U2, includes Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2. 7

8 You must install the same version of Site Recovery Manager Server and vcenter Server on both sites. You cannot mix Site Recovery Manager or vcenter Server versions across sites. DO: Install the same version of Site Recovery Manager Server and vcenter Server on both sites (protected and recovery). For environments with a small number of virtual machines, you can run Site Recovery Manager Server and vcenter Server on the same system. For environments that approach the maximum limits of Site Recovery Manager (as per and vcenter Server, install Site Recovery Manager Server on a system that is different from the system on which vcenter Server is installed. If Site Recovery Manager Server and vcenter Server are installed on the same system, administrative tasks might become more difficult to perform in large environments. If you are using the vcenter Appliance, you will need to install your SRM Servers in a different system than vcenter. Therefore, at a minimum you will need two Windows 2008/2012 server licenses (one for each site, each running SRM Server and SQL Server and potentially vcenter if no appliance is being used and the environment is small enough), but you may need as many as six if you install vcenter, SRM and SQL in separate servers in each site. Tintri VMstore SRM support is included with the ReplicateVM license. VMstore systems deployed at both the protected site and at the recovery site must be licensed for ReplicateVM. Site Recovery Manager System Requirements The system on which you install vcenter Site Recovery Manager must meet specific (virtual) hardware requirements. Site Recovery Manager System Requirements Component Processor Memory Disk Storage Networking Requirement 2.0GHz or higher Intel or AMD x86 processor 2 GB minimum. You might require more memory if you use the embedded database, as the content of the database grows. 5 GB minimum. If you install Site Recovery Manager on a different drive than the C: drive, the Site Recovery Manager installer still requires at least 1 GB of free space on the C: drive. This space is required for extracting and caching the installation package. You might require more disk storage if you use the embedded database, as the content of the database grows. 1 Gigabit recommended for communication between Site Recovery Manager sites. Use a trusted network for the management of ESXi hosts. For information about supported platforms and databases, see the Compatibility Matrixes for vcenter Site Recovery Manager 5.8 at Compatibility Matrixes for vcenter Site Recovery Manager

9 Site Recovery Manager Network Ports Site Recovery Manager Server instances use several network ports to communicate with each other, with client plug-ins, and with vcenter Server. If any of these ports are in use by other applications or are blocked on your network, you must reconfigure Site Recovery Manager to use different ports. Site Recovery Manager uses default network ports for intra-site communication between hosts at a single site and inter-site communication between hosts at the protected and recovery sites. You can change these defaults when you install Site Recovery Manager. Beyond these standard ports, you must also (continue to) meet the VMstore s network requirements. You can change the network ports from the defaults when you first install Site Recovery Manager. You cannot change the network ports after you have installed Site Recovery Manager. For a list of all the ports that must be open for Site Recovery Manager, see For a refresher on the list of all the ports that must be open for the Tintri VMstore, please consult the Tintri VMstore System Administration Manual. For the list of default ports that all VMware products use, see Operational Limits of Site Recovery Manager Each Site Recovery Manager server can support a certain number of protected virtual machines, protection groups, datastore groups, recovery plans, and concurrent recoveries. For details about the operational limits of Site Recovery Manager 5.8 see Requirements for Using Microsoft SQL Server with Site Recovery Manager For reliability, performance and scalability, we highly recommend that a Microsoft SQL Server (2005/2008/2012/2014) database is used instead of the built-in PostgreSQL database. When you create a Microsoft SQL Server database, you must configure it correctly to support Site Recovery Manager. This section provides the requirements for a SQL Server database for use with Site Recovery Manager. Consult the SQL Server documentation for specific instructions on creating a SQL Server databases. Database user account: o If you use Integrated Windows Authentication to connect to SQL Server and SQL Server runs on the same machine as Site Recovery Manager Server, use the local service account (that has administrative privileges on the Site Recovery Manager Server machine). Use the same account when you install Site Recovery Manager Server. When the Site Recovery Manager installer detects an SQL Server data source name (DSN) that uses Integrated Windows Authentication, it configures Site Recovery Manager Server to run under the same account as you use for the installer, to guarantee that Site Recovery Manager can connect to the database. o If you use Integrated Windows Authentication to connect to SQL Server and SQL Server runs on a different machine from Site Recovery Manager Server, use a domain account 9

10 with administrative privileges on the Site Recovery Manager Server machine. Use the same account or an account with the same privileges when you install Site Recovery Manager Server. When the Site Recovery Manager installer detects an SQL Server data source name (DSN) that uses Integrated Windows Authentication, it configures Site Recovery Manager Server to run under the same account as you use for the installer, to guarantee that Site Recovery Manager can connect to the database. NOTE: this doesn't always work flawlessly due to problems in the SRM Installer. If it fails, it will do so late in the install with a "retry / fail and back out" error message. If it does so, you can work around the issue by going to the SRM service configuration, change it to be the correct user (it will incorrectly have set it to local service), and then start the service and hit retry. It will then succeed. o If you use SQL authentication, you can run the Site Recovery Manager service under the Windows Local System account, even if SQL Server is running on a different machine to Site Recovery Manager Server. The Site Recovery Manager installer configures the Site Recovery Manager service to run under the Windows Local System account by default. o Make sure that the Site Recovery Manager database user account has the ADMINISTER BULK OPERATIONS, CONNECT, and CREATE TABLE permissions. Database schema: o The Site Recovery Manager database schema must have the same name as the database user account. o The Site Recovery Manager database user must be the owner of the Site Recovery Manager database schema. o The Site Recovery Manager database schema must be the default schema for the Site Recovery Manager database user. The Site Recovery Manager database must be the default database for all SQL connections that Site Recovery Manager makes. You can set the default database either in the user account configuration in SQL Server or in the DSN. Map the database user account to the database login. Requirements for Using Oracle Server with Site Recovery Manager SRM can also support Oracle Server instead of Microsoft SQL Server. Specifically, Oracle 11g Release 2 and 12C are supported. Note however that we did not test Oracle during the writing of this Best Practices Guide (we tested SQL Server). When you create an Oracle Server database, you must configure it correctly to support Site Recovery Manager. You create and configure an Oracle Server database for Site Recovery Manager by using the tools that Oracle Server provides. This information provides the general steps that you must perform to configure an Oracle Server database for Site Recovery Manager. For instructions about how to perform the relevant steps, see the Oracle documentation. When creating the database instance, specify UTF-8 encoding. Grant the Site Recovery Manager database user account the connect, resource, create session privileges and permissions. 10

11 Requirements for Tintri VMstore For a typical VMware SRM + Tintri VMstore deployment, you will need two Tintri VMstores one in the Protected Site and the other in the Recovery site. The requirements for these VMstores are: - Both VMstores must to be running Tintri OS 3.1 or later - Each VMstore needs to have a ReplicateVM license installed - Each VMstore needs to have their respective/local (Protected or Recovery) vcenter Server configured as a Hypervisor manager (in Settings Hypervisor managers). Configuration This section provides information on configuring VMware SRM and the Tintri VMstore. It is assumed that you ve met the prerequisites from the previous section, including: 1. Have vsphere servers in both sites with the necessary licenses. 2. Have fully configured vcenter Servers in both sites managing all applicable vsphere servers, with the necessary licenses (OS and application). a. The 5.8 release of Site Recovery Manager requires the vsphere Web Client. For information about compatibility between vcenter Server and Site Recovery Manager versions, see vcenter Server Requirements in the Compatibility Matrixes for vcenter Site Recovery Manager 5.8 at 3. Have fully licensed SQL Server database servers up and running in both sites (if you followed the recommendation of not using the embedded PostgreSQL database). 4. Each site can access any necessary Active Directory servers, not protected by SRM even in case one of the sites goes down in case of disaster (e.g. by leveraging AD Native Replication). 5. Have the necessary SRM licenses (permanent or evaluation) and Tintri ReplicateVM licenses. Create an ODBC System DSN for SRM in the host you chose for the SRM Server You must provide Site Recovery Manager with a system database source name (DSN) for a 64-bit open database connectivity (ODBC) connector in the Windows host you chose to install SRM Server on. The ODBC connector allows Site Recovery Manager to connect to the Site Recovery Manager database. You can create the ODBC system DSN before you run the Site Recovery Manager installer by running Odbcad32.exe, the 64-bit Windows ODBC Administrator tool. Alternatively, you can create an ODBC system DSN by running the Windows ODBC Administrator tool during the Site Recovery Manager installation process. Note: If you use the embedded Site Recovery Manager database, the Site Recovery Manager installer creates the ODBC system DSN according to the information that you provide during installation. If you uninstall the embedded database, the uninstaller does not remove the DSN for the embedded database. The DSN remains available for use with a future reinstallation of the embedded database. 11

12 Prerequisites You created the database instance to connect from Site Recovery Manager. Procedure 1. Double-click the Odbcad32.exe file at C:\Windows\System32 to open the 64-bit ODBC Administrator tool. Important Do not confuse the 64-bit Windows ODBC Administrator tool with the 32-bit ODBC Administrator tool located in C:\Windows\SysWoW64. Do not use the 32-bit ODBC Administrator tool. 2. Click the System DSN tab and click Add. 3. Select the appropriate ODBC driver for your database software and click Finish. o SQL Server: Select SQL Server Native Client 10.0, SQL Server Native Client 11.0, or ODBC Driver 11 for SQL Server. NOTE: You may need to install the SQL Server Native Client from the SQL Server distribution ISO in case it s not already installed in the Windows Host. o Create an SQL Server data source for the database. Oracle Server: Select Microsoft ODBC for Oracle. Create an Oracle Server data source for the database. 4. Click Test Data Source to test the connection and click OK if the test succeeds. If the test does not succeed, check the configuration information and try again. 5. Click OK to exit the Windows ODBC Administrator tool. The ODBC driver for your database is ready to use. Site Recovery Manager Server Installation Pre-installation Checklist Download the Site Recovery Manager installation file to a folder on the machine on which to install Site Recovery Manager. Verify that no reboot is pending on the Windows machine on which to install Site Recovery Manager Server. Verify that no other installation is running, including the silent installation of Windows updates. Pending reboots or running installations can cause the installation of Site Recovery Manager Server or the embedded Site Recovery Manager database to fail. The user account that you use to install and run Site Recovery Manager must be a member of the local Administrators group. You can configure the Site Recovery Manager service to run under a specified user account. This account can be a local user or a domain user that is a member of the Administrators group on the machine on which you are installing Site Recovery Manager. If you are using certificate-based authentication, you must obtain appropriate certificate file. You must use the same type of authentication on both sites. See Site Recovery Manager Authentication and Requirements When Using Trusted SSL Certificates with Site Recovery Manager. If you are using certificate-based authentication, provide the certificate for the remote site to the vsphere Web Client service on each site. 12

13 Verify that you have the following information: o The fully qualified domain name (FQDN) or IP address of the site s vcenter Server instance. The server must be running and accessible during Site Recovery Manager installation. You must use the address format that you use to connect Site Recovery Manager to vcenter Server when you later pair the Site Recovery Manager sites. Using FQDNs is preferred, but if that is not universally possible, use IP addresses for all cases. o The user name and password of the vcenter Server administrator account. o A user name and password for the Site Recovery Manager database, if you are not using the embedded database. If you use an SQL Server database with Integrated Windows Authentication as the Site Recovery Manager database, you must use the same user account or an account with the same privileges when you install Site Recovery Manager Server as you used when you created the Integrated Windows Authentication data source name (DSN) for SQL Server. Install Site Recovery Manager Server The steps to Install SRM Server are outlined here: CA8CB680A.html Install Tintri SRA After installing each SRM Server (in each site), you will need to also install the Tintri SRA in each site. The Tintri SRA for VMware SRM can be downloaded from The installation instructions for the SRA are also available from the same site, in the corresponding release notes. Connect the Site Recovery Manager Server Instances on the Protected and Recovery Sites Before you can use Site Recovery Manager, you must connect the Site Recovery Manager Server instances on the protected and recovery sites. The sites must authenticate with each other. This is known as site pairing. Steps are outlined here: BDD0-49B35D html 13

14 After that is completed, this is what you should see in the vsphere Web Client: Figure 2 - Summary tab after SRM Site Pairing Install the Site Recovery Manager License Key Site Recovery Manager Server requires a license key to operate. Install a Site Recovery Manager license key as soon as possible after you install Site Recovery Manager. Follow the steps outlined in A38A-D0342CCC21CA.html Configure Inventory Mappings The next step is to Configure Inventory Mappings. You must create inventory mappings so that Site Recovery Manager can create placeholder virtual machines. Inventory mappings provide a convenient way to specify how Site Recovery Manager maps virtual machine resources at the protected site to resources at the recovery site. Site Recovery Manager applies these mappings to all members of a protection group when you create the group. You can reapply mappings whenever necessary, for example when you add new members to a group. 14

15 This is done in 3 steps: Create resource mappings, Create folder mappings and Create network mappings. Each step can be accessed by clicking the respective link in the Guide to Configuring SRM as shown in Figure 2 and Figure 3 (accessible by going to Site Recovery Sites <Protected Site> Summary in the vsphere Web Client). Figure 3 - Accessing the Configure inventory mappings Wizard 15

16 Create resource mappings Figure 4 - Creating the Resource Mapping In this step, you simply select the resources (e.g. a vsphere server) you want to map in the Protected Site (in the left pane), and then the equivalent resource in the Recovery site (e.g. a different vsphere server, located in the Recovery site). Create folder mappings Figure 5 - Creating the Folder Mapping 16

17 Create network mappings This step allows you to map the virtual networks in the Protected Site to their equivalents in the Recovery Site. Figure 6 - Creating the Network Mapping Configure Placeholder Datastore The next step is to set Placeholder Datastores for each site. Note that these Datastores do not need to be shared or replicated. They are used to keep the.vmx files (not the.vmdk files) on the site that is inactive (Recovery site when everything is OK, Protected site after a failure). In our case, we selected a local hard drive in each site. DON T: Use a Tintri VMstore as a Placeholder Datastore. Use either local hard drives or non-tintri shared storage. 17

18 Figure 7 - Configure Placeholder Datastore Configure the Tintri VMstores Now it s time to for the configuration steps that involve the pair of VMstores you are going to be using. 1. Each VMstore needs to be configured and mounted in each respective vsphere/vcenter as a datastore one datastore for each group of VMs to be protected (there will be a mapping between SRM Protection Groups and datastores/mount points on the VMstores. o For SRM, you cannot use the VMstore s default /tintri folder. You will need to create folders under /tintri (e.g. /tintri/srm-protect-base) and mount those as additional datastores. Create one folder for each Protection Group you intend to create Use the datastore browser or a standard NFS client to create the extra folders. Mount each folder as a different datastore in the vsphere server: 18

19 Move the VMs you want to protect into the respective datastore (again each datastore will mean a specific SRM Protection Group). 2. Go to the web GUI of the Tintri VMstore at the Protected site and create a Replication Path to the VMstore in the Recovery site by going to Settings Replication: DO: Make sure you have a ReplicateVM license for your Tintri VMstores. If the Replication option is not visible in your Tintri GUI, it is likely that you don t have a ReplicateVM license installed. If that is the case, please obtain a ReplicateVM license from Tintri, and follow the steps under the Configuring Licenses section of the Tintri VMstore System Administration Manual. 19

20 Don t forget to click Test Paths before you click Save: 3. Also in the Tintri GUI, create a Service group by going to Virtual Machines Service Groups: Give it a name and select which datastore / mount point you want to protect / replicate. NOTE: If the datastore / mount point you just created and moved VMs to doesn t show up in the drop down, that means the VMstore hasn t seen it yet; it can take up to 10 minutes for it to show up. 20

21 Select the right replication path: You can leave the destination folder as the default ( srm ) or change it if you intend to have multiple service groups go into the same VMstore. NOTE: You do not need to create the destination folder yourself; it will be created for you automatically. Furthermore, even if the folder already exists, VMstore will also automatically create a unique name (e.g. srm.1) but still show it as you have input it in this page (e.g. srm). It s time to configure the RPO (i.e., how frequently replication occurs, which results in the max age of a recovered VM); with Tintri OS 3.1 the shortest possible RPO is 15 minutes, which can be obtained by selecting a custom interval, then Hourly and then clicking the minutes past the hour box: 21

22 Configure whether the replicas need to be Crash-consistent or VM-consistent : Default setting is Crash-consistent, which means that when the VMs come up in the Recovery site, they will do so as if the power plug had been pulled out meaning they will cold boot and check the file system, etc. You can however select "VM-consistent", which means that before taking a Tintri snapshot for replication, the VM will be quiesced by leveraging VMware Tools and VSS.. The disadvantage of using VM-consistent snapshots in any VMware environment, irrespective of whether a VMstore is being used, is that if the VMs perform heavy I/O, VMware's quiescing process can take minutes and negatively impact the performance of the VM. This may be OK if the RPO is long and the snapshots are taken during low-i/o periods, but an RPO of 15 minutes may generate frequent snapshots during high-i/o periods resulting in unacceptable performance. DO: We recommend trying VM-consistent first in a test environment, with copies of the production applications and testing if the impact is acceptable or not. After pressing Create, you will see your newly created Service Group show up in the GUI, as shown above. Note the number of VMs shown and keep an eye on the RPO this will be updated as replication is performed. DO: Create a Service Group for each SRM Array Manager Pair i.e. pair between Protected and Recovery VMstores that you plan on creating in SRM. There is a 1:1 mapping between Tintri Service Groups and SRM Array Manager Pairs. 22

23 VMstore in the Recovery Site The VMstore in the Recovery Site will automatically be updated with the other side of the Service Group. In our example, this is what you re going to see on the Recovery VMstore: Add Array Manager and Enable Array Pair Now it s time to go back to the vsphere Web Client and continue the steps to configuring SRM. The next step is Add array manager and enable array pair. DON T: Try and Add a pair of array managers before you create the corresponding Service Group in the Primary s VMstore. The array manager pair creation in SRM will fail if there isn t a corresponding Service Group already created via the Tintri GUI. First we are asked if it s really adding a pair, or only one; at this stage, it is the former: 23

24 By pressing Next we are taken to the Location dialog, which, given we ve already paired the two vsphere Servers (sites), should be pre-populated with the right info: Next comes selecting the SRA, which, if you installed the SRA in the SRM servers as mentioned earlier, should also be correctly pre-populated: 24

25 After that you will be asked for the information of the VMstore in the Protected site: NOTE: if you forgot to create a Protection Group in the VMstore you input in the Configure array manager screen, you will get an error after you click Next and will not be able to proceed. If that happens, please go back to Configure the Tintri VMstores in page 18. If the Protected site s array manager configuration is successful, it is then time to input the information for the VMstore in the Recovery site: 25

26 The next screen is also auto-populated with the newly discovered Array Pair: If you re wondering, the array pair that is not selected and says No peer array pair shows a replication path that was configured to a different VMstore (i.e. that is not the one in the Recovery site). Even though that other replication path does show up, because the additional VMstore is not configured in SRM (as it shouldn t there s no Protection Group associated with it), SRM doesn t see it as an array pair and it can t be selected. That was the last step in Array Manager creation: 26

27 This is a good point for a quick sanity check. Go to Site Recovery Array Based Replication and select the VMstore in the Protected site. Then select the Manage tab and look under Array Pairs. Then select the Array Pair you just created you should see, below, no errors, and a table that has: Local Device the name of the Service Group you created in the Tintri GUI Status Outgoing Replication Remote Device also the name of the Service Group you created in the Tintri GUI Datastore the name of the Datastore you re replicating / protecting in the protected site. If all looks correct, time to proceed to create a Protection Group. Create a Protection Group Give it a name: 27

28 The type should be already correctly selected by default: You ll need to correctly select the Datastore in the next screen (make sure you select the one which is already being replicated by the VMstore): 28

29 The Virtual Machines residing in that datastore will be automatically selected. There is no way to unselect (unprotect) certain VMs here, that s why we had to create a dedicated datastore for them (so that only the ones we want to protect get replicated and protected). Next comes an optional description and that s it! SRM will be working on the VMs for a few minutes to protect them. This is what you ll see in the Web Client: Once that s finished, the status changes to this: 29

30 Create Recovery Plan Now it s time to create the recovery plan the last configuration step, right before we can actually test SRM. First, give it a name: Then, a recovery site (default should be correct): Next, the Protection Group (you just created): 30

31 Test networks are next, for what to do during a test failover. By default, SRM will place each virtual machine in an isolated "bubble" network for a test, and not connect the machines to an actual physical uplink. Then there s an optional description and that s it: Recovery plans are ready immediately after creation: 31

32 Testing Previous sections showed the entire configuration that was needed. Now it s time to do a Test Recovery Plan. As explained earlier, a Recovery Plan doesn t actually fail over the VMs to the Recovery site; what it does do is synchronize the replica VMs and then enable (power up) the VMs in the Recovery Site, in a test (isolated) network. That shows the replica VMs are OK and working. What it doesn t do is disable the VMs in the Protected site and yield full control to the VMs in the Recovery Site. Yielding full control would mean that the Recovery Site VMs would now be the Primaries, be connected to the production network and be the authoritative copy. In a Test run the Protected Site still has the authoritative copy of the VMs, and when the test ends and SRM cleans up, it simply shuts down the Recovery VMs and overwrites them with a new replica from the Protected site. In an actual failover/failback scenario (as we ll see), the VMs in the Recovery site have to be replicated back to the Protected site before they are brought up. Test Recovery Plan Here s how a typical Test Recovery Plan process looks like: 32

33 The Monitor tab will show you what s going on as it happens: Here s the screen after a successful test; note how blazingly fast the replication happens; these are 67 live VMs that get replicated in about a minute by the VMstore. This is made possible because the VMstore replicates only changed blocks after deduplication and compression. 33

34 This chart from the Tintri GUI also shows how little impact the replication process has on the Protected VMstore, even if it s set to replicate every 15 minutes and there are 67 extremely active VMs: After a test, don t forget to press the Cleanup button Otherwise a Disaster Recovery won t work correctly. A cleanup, amongst other things, removes the test network from the Recovery Site. 34

35 Running a Recovery Plan A Recovery Plan should only be actually run if there s some kind of event at the Primary (Protected) Site that mandates it. A Recover Plan should not be run for testing purposes; for that there s the Test feature described in the previous section. DON T Run a Recovery Plan for testing; use the Test Recovery Plan feature for testing. If you do Run a Recovery Plan, the Recovery site will completely take over and the VMs in the Protected Site will be taken down. Even if there s an actual Disaster Recovery situation (the Protected site goes down hard), you will still need to run the Recovery Plan as soon as you get the chance. This is because the Run Recovery Plan process does a lot of housekeeping items that don t necessarily get performed automatically if the Protected site goes down. The only difference is that when you run the Recovery Plan in a Disaster Recovery situation (rather than a planned migration) you select a different option when you trigger it: 35

36 SRM needs confirmation before proceeding: Disaster Recovery and Planned Migrations were tested in writing this document. In the DR case, the Recovery Site was running Recovered VMs in less than 2 minutes after the plug was pulled on the protected site. The whole Recovery Plan process (including housekeeping) took about 4 minutes in both cases: 36

37 Reprotect After a Recovery Plan has completed (successfully), the Failback to the Protected site is performed by clicking the Reprotect button: 37

38 With SRM and Tintri, pressing the button will perform the reversal fully automatically; the replication will automatically be reversed, as shown in the vsphere Web Client: as well as the Tintri GUI; here s what the Recovery Site VMstore looks like (note the State = Failover Primary ): and the Protected Site VMstore, showing FailoverFormerPrimaryExpectingReverse : 38

39 Conclusion Tintri VMstore was designed from the ground up for virtualization and cloud workloads, and purposebuilt to take full advantage of flash technology. Tintri s legendary ease of use and low TCO now extends to VMware SRM too: you can have your SRMbased Disaster Recovery environment up and running in mere minutes, with low maintenance and an unbeatable low TCO. Thank you for choosing Tintri. We hope the options and guidance presented in this guide enable you to leverage this new technology. For additional information about Tintri VMstores and other technical whitepapers and resources, visit

40 References Tintri Tintri SRA for VMware SRM 1.0 Release Notes Tintri VMstore System Administration Manual VMware vcenter Site Recovery Manager Features vcenter Site Recovery Manager Resources SRM 5.8 Datasheet SRM 5.8 Release Notes SRM 5.8 Documentation Center Microsoft Things to consider when you host Active Directory domain controllers in virtual hosting environments Running Domain Controllers in Hyper-V (NOTE: also applies to VMware vsphere) AD DS Backup and Recovery Step-by-Step Guide 40

41 Tintri, Tintri VMstore, the Tintri Logo and FlashFirst are trademarks or registered trademarks of Tintri, Inc. All other trademarks or service marks are the property of their respective holders and are hereby acknowledged Tintri, Inc. All rights reserved T Ravendale Dr., Mt. View CA