Configuring vSphere Replication
- 1 Originating Author
- 2 Video Content [TBA]
- 3 Configuring vSphere Replication (Optional)
- 4 How vSphere Replication Works
- 5 vSphere Replication Limitations
- 6 Installing vSphere Replication
- 7 Enabling and Monitoring vSphere Replication
- 8 Summary
Video Content [TBA]
Configuring vSphere Replication (Optional)
Version: vCenter SRM 5.0
In this release of SRM VMware added a feature called vSphere Replication (VR). Although it is branded with the name of “vSphere” it’s actually a feature that is only available to customers who purchase the SRM product and is not a core feature of the vSphere platform. VR allows the replication of individual VMs on any datastore (local, FC, iSCSI, or NFS) to any other datastore at the Recovery Site. It’s a technology that is attractive to customers on many levels. SMBs will be tempted by it because it removes the requirement for matching storage arrays at both sites. Enterprise organizations might be attracted to it because it is sometimes difficult to resolve array firmware compatibility requirements and satisfy the demands of a storage team. Finally, solution providers who offer DR as a service might like the fact that VR enables them to offer SRM to customers without them having to worry about the customers’ storage array system. Essentially, VMware has done for replication what it achieved in the previous decade with the virtual machine: It has virtualized replication and in one stroke removed some of the hardware and firmware compatibility snags that have often dogged storage-array-based implementations of SRM. At the very least, VR offers folks who are new to SRM a chance to set up proofs of concept and home labs, without the heavy lifting that array-based replication sometimes requires.
How vSphere Replication Works
It’s important to say that the setup and configuration of VR is not mandatory, which is why I added the word Optional to the chapter title. VR allows an organization to enable replication of VMs from one site to another without the need for native array-based replication. It’s not a mandatory requirement to configure VR, but nonetheless you may find it very useful whether you’re a large or small business. The main advantage of VR is that it is storage protocol neutral and storage vendor neutral, so as long as you’re using storage that is support by VMware’s general HCL you will be fine. What VMware has done for virtual machines, it is doing for replication; if you like, call it virtualized replication. With VR it’s possible, for instance, to replicate data held on a Fibre Channel protocol to NFS. This is because the core engine of VR sits above this layer in the architecture. All that VR “sees” are the files that make up a VM, and the fact that they reside on a datastore visible to the ESX host. VR is asynchronous replication of the VMs using ESXi as the main engine for moving data around. The VMs themselves need not be stored on replicated datastores; you could be using local storage, and the replication itself could be between two datastores that are not even from a common storage array vendor. VR should be attractive to the SMB/ SME market which historically has balked at the cost of buying secondary storage merely for DR purposes. It may also be attractive to organizations that choose to partner with one another for DR purposes, but find they do not share a common storage array to get the replication going. Finally, even large enterprises might be attracted to VR; it may allow VMware admins more control over the replication process, making them less dependent on the approval of their storage teams. Additionally, it might provide a workaround in situations where a common storage platform is not in place, such as a recent acquisition of another business that needs either DR protection or the ability to move into a corporate datacenter for consolidation purposes. Another use of VR could be to accelerate early proofs of concept of SRM, because the storage requirements are taken care of by VMware, without seeking approval or action from the storage team. A final use case is of providing an IT team with a DR offering for workloads that did not fit or warrant inclusion (possibly due to cost) in the existing replicated SAN DR architecture. For example, Tier 1/Tier 2 workloads could be on SAN replication with SRM and charged back appropriately, whereas Tier 3 and Tier 4 workloads are protected with VR integrated with SRM 5.0.
The feel of VR is quite different from that of array-based replication. VR is enabled on the properties of the VM or by multiple selections of VMs held in a VM folder. This allows you to be much more selective about which VMs are targeted for protection by SRM, than with array-based replication, where currently the smallest unit is the LUN or volume, and every VM in that LUN or volume can be enrolled in a Recovery Plan. Personally, I like this form of very granular control, as it might help customers who have been less than circumspect on the storage placement of their VMs. This per-VM granularity empowers the administrator in a number of ways. It’s possible for the administrator to opt to only replicate some and not all of the VMs’ virtual disks, and select a per-VM recovery point objective (RPO). If the VMs you are replicating are large in size it’s possible to supply an “initial copy” of the VM to save bandwidth, as VR only copies the deltas or the changes between the source and destination.
Now, to understand the core benefits of VR let’s look at the structure of the technology (see Figure 8.1).
Figure 8.1 A management server (VRMS) is mandatory at both locations, but the VR appliance (VRS) that receives updates from ESXi is only required at the Recovery Site.
Source: Used by permission of VMware.
As you can see in Figure 8.1, there is a vSphere Replication Management Server (VRMS) at the Protected Site. This server has a database back end that is used to store your VRMS configuration, including such metadata as which VMs are protected by VR and their RPO configuration. Sitting inside the ESX host is a vSphere Replication agent (VRA). This is used to intercept the changes that are taking place inside the VMs, and it is responsible for moving those deltas to the Recovery Site. Those changes taking place inside the VM are actually detected by an agent that is inside the ESXi host. At the destination side, the vSphere Replication server (VRS) is a virtual appliance that is used as the destination for shipping any deltas from the Protected Site. This virtual appliance then pushes those changes to the ESXi hosts in the Recovery Site, and updates the volumes where the VMs reside. A VRMS is required on both sides to handle the process; there is a pairing process that is very similar to the storage array manager’s configuration that we will discuss in the next chapter.
vSphere Replication Limitations
This is the first implementation of VR, and it is important that you understand some of the limitations in this release. As always, you need to match your business needs and objectives against the functionality of the technology. There are a number of limitations, so let’s begin with a checklist first and then delve a little deeper into the implications.
• Powered-off VMs are not replicated by VR (but can be protected).
• There is no automated failback of VMs protected by VR (manual failback is supported).
• ISOs and physical RDMs cannot be replicated.
• FT-protected VM templates and linked clones are not supported.
• The snapshot hierarchy is not replicated.
Once you understand the architecture of VR the first limitation becomes obvious: Powered-off VMs are not replicated. This is not so much a limitation, but a “feature” of the way the technology has been designed. Logically, then, if the VM is not powered on, the ESXi agent cannot detect any changes. The fact that a powered-off VM cannot make any changes in the file system perhaps makes this limitation less troublesome.
It is my understanding that currently, there is no automated failback of VMs protected by VR. I think this may be regarded by some as a limitation, especially given that one of the main new features of array-based protection is the automated failback and reprotect process. I think it’s worthwhile remembering that this was the situation in both SRM 1.0 and SRM 4.0 for array-based replication, and it wasn’t seen as a showstopper for those technologies. It does mean the failback process of VMs protected by VR will involve a few more manual steps, and these will be very similar to the process in previous releases of SRM. So, SRM has always been able to carry out failback; it’s just an issue of under-standing the process and working through it. Don’t worry; you won’t be on your own. I will be covering that process in this book, as I have always done.
Finally, there are a range of vSphere components that cannot be protected with VR, such as ISOs, physical RDMs, FT-protected VMs, VM templates, linked clones, and snapshots. I think it’s fair to say that some of these components would be unlikely to be protected by SRM even with array-based replication—for example, .iso images. Similarly, the lack of support for FT-protected VMs persists even with array-based replication. While SRM has always been able to offer recovery for the primary FT-protected VM, when it is recovered it becomes just another VM that is powered on in the plan. It’s up to the SRM administrator to decide whether the environment in the Recovery Site meets the requirements for FT to be enabled. Remember, those requirements are quite stringent. So I wouldn’t overstate these limitations too much, but you must be aware of them. It’s my hope that in future releases of SRM automated failback will be ported to VR.
Installing vSphere Replication
The setup of VR involves a number of steps carried out in a specific order. As you complete each step at both the Protected and Recovery Sites, the Getting Started tab (as shown in Figure 8.2) for VR will update accordingly, and you should see a green checkmark appear next to each step.
Setting the vCenter Managed IP Address
Before you begin to deploy the VRMS, you will need to fulfill one prerequisite on both the Protected and Recovery Sites: ensuring that the vCenter Managed IP Address is correctly configured. By default, this value in vCenter is normally blank after a clean installation. Nonetheless, even if you have carried out an upgrade of vCenter from a previous release it is well worth confirming this address is correctly set. VR uses it to automate the registration process of the various appliances.
Figure 8.2 In this case, the Getting Started tab does a good job of outlining the steps required in the initial configuration of VR.
1. Log in to the vSphere client and the Protected Site vCenter.
2. In the menu that opens, select the Administration and vCenter Server settings.
3. In the vCenter Server Settings dialog box, select the Runtime Settings category.
4. In the Managed IP Address field, enter the IP address of your vCenter server (see Figure 8.3).
Configuring a Database for the VRMS
Before you begin the deployment process, you should set up a database for the VRMS. This database holds your configuration for the VMs protected by VR. Unlike the new vCenter virtual appliance, the VRMS does not support a database that is local to it. Instead, you will need to configure a database for the VRMS on an existing database server. Currently, the VRMS supports Microsoft SQL Server, Oracle, and IBM DB2. The following instructions assume you’re configuring a database on Microsoft SQL Server 2008, which is the database platform I use throughout this book.
1. Log in to your Microsoft SQL Server and run the SQL Server Management Studio management console.
2. Right-click the +Database node and select the New Database option in the menu.
3. Enter a friendly database name and select the location to store the database files (see Figure 8.4). Click OK to create the database.
4. Create a user account to access the database. Expand the +Security node, and right-click +Logins and select New Login from the menu.
Figure 8.3 Make sure the Managed IP Address setting is correct.
Figure 8.4 The VRMS requires a database to hold the VR’s configuration, including which VMs are protected and what their RTO settings are.
5. Enter a login name for the database, such as “vrmsdbuser-nyc” (see Figure 8.5). Select “SQL server authentication” as the authentication type, and remove the tick next to “Enforce password policy.” Finally, select the database you recently created as the default, and click OK.
Figure 8.5 Creation of a Microsoft SQL Server user account for the VR database
We need to change the “ownership” of the database we recently created to give this new login account access rights. By default, the database will be owned by the account used to create it—in my case, the domain administrator account.
6. To change the ownership privileges, right-click the VRMS database and choose Properties. Select the Files page, and select the Browse button next to the current owner. This will allow you to change the owner to be the user account you recently created (see Figure 8.6).
Deploying the VRMS
The first step in configuring VR is to download and configure the management server. In the vSphere Replication tab, you should see in the Summary page a Deploy VRM Server link under the Commands pane. If this is not present, it is because the UI extensions were not installed during the main installation of SRM. That is something I would always recommend, even if you think in the short term that you will not use the VRS. To import the appliance manually you can use the Deploy OVF Template menu option under the File menu in the vSphere client. The appliance is located by default on the vCenter server at the following location:
C:\Program Files (x86)\VMware\VMware vCenter Site Recovery Manager\www\VRMS.ovf
Figure 8.6 Selecting a SQL user account requires navigating through dialog boxes until you can select the account that should own the database.
Alternatively, if you did install the UI extensions, proceed as follows.
1. Log in to the Protected Site vCenter.
2. Select Home and connect to your SRM service.
3. Select the vSphere Replication tab and then click the Deploy VRM Server link in the Commands pane.
4. Acknowledge the welcome message by clicking OK.
5. Click Next to accept the default path for the location of the .ovf file.
6. Accept the default OVF Template Details information.
7. Enter a friendly name for your VRMS, and set a location in the inventory (see Figure 8.7).
8. Select a VMware cluster and resource pool location for the appliance (see Figure 8.8).
9. Select a datastore location to hold the appliance. Do not select one of your replicated datastores. This is an “infrastructure” component that is local to the site within which it is located. The VRMS is approximately 11GB in size and consists of two virtual disks: one 1GB thinly provisioned disk and one 10GB thick provisioned disk.
10. Select a network port group for the appliance; this should be the network you selected when creating the IP pool for the datacenter. In my case, this was the Virtual Storage Appliances port group. Whatever network port group you select, the appliance must be able to communicate with the vCenter server (see Figure 8.9).
Figure 8.7 As with virtual machines, all virtual appliances need to be placed into an appropriate container in the vCenter inventory.
Figure 8.8 Resource pools are not mandatory. The virtual appliance could reside directly on a VMware cluster.
Figure 8.9 I placed my virtual appliances on my port group dedicated to this traffic.
11. Set a fixed IP address for the virtual appliance, and set a password for the root account (see Figure 8.10).
12. Accept the default for the service bindings; the .ovf file knows the correct path for this because of the configuration of the Managed IP Address value that was set previously in the Runtime Settings (see Figure 8.11).
13. While the appliance is downloading and then powering on, repeat this configuration at the Recovery Site.
Figure 8.10 Setting static IP addresses and the password on the appliance
Figure 8.11 The VRMS registers itself with vCenter.
Configuring the VRMS
The next stage in the setup process is to configure the VRMS. The VRMS will need to be configured for its database, vCenter, and optionally, certificate settings. This is carried out via a Web page administration tool. If you haven’t installed the GUI elements of the VRS during the setup of SRM you can log in to this configuration management page at:
https:/<IP address of VRMS host>:8080
Alternatively, if you did install the UI extensions, proceed as follows.
1. In the vSphere client, and in the SRM application, select the vSphere Replication tab and then click the Configure VRM Server link in the Commands pane. This should open a Web page to the virtual appliance. You may need to wait for the appliance to completely boot and VMware Tools to start successfully before clicking this link.
2. Log in to the appliance as root and with your password, and then select the Configuration page.
3. Configure the settings for the connection to the database (see Figure 8.12).
4. The VRMS host settings should show the IP address of the VRMS, together with a friendly default name of VRMS Site Name. I accepted the default settings here. It is possible to change this value after the setup of VRMS if you wish.
Figure 8.12 Provide the appropriate variables to complete a connection using Microsoft SQL Server.
5. Scroll down the Web page to locate your vCenter address settings and supply valid user account details to register the appliance with vCenter (see Figure 8.13). The email field is not mandatory.
6. Select the Save and Restart Service button. At this point, you should be prompted to accept or reject the built-in certificate from the vCenter server. This confirms that the appliance is connecting to a valid vCenter. Click the Accept button, and then wait for the “Successfully saved the start-up configuration” message in green to appear under the Startup Configuration heading.
Once the appliance is correctly configured, you may wish to confirm your time zone settings in the System tab, and configure them relative to the geographical locations of the VRMS.
If you have the vSphere client open, the VRMS will cause a certificate acceptance dialog box to open for you to confirm identity. Once this has been accepted, you will see that the icon for the VRMS appliance in the inventory has been modified (see Figure 8.14).
This process also extends the main vSphere client UI, adding a vSphere Replication icon to the end of the right-click menu option on the properties of an individual VM (see Figure 8.15).
7. Repeat this configuration at the Recovery Site.
Figure 8.13 In the same page, you will also need to provide credentials for the vCenter server.
Figure 8.14 Once the initial startup settings have been made, the icon for the VRMS virtual appliance changes
Figure 8.15 The right-click context-sensitive menus are enabled for VR, and new tabs are available on the VMs’ properties.
Configuring the VRMS Connection
The next step of the configuration is to “pair” the VRMS systems together. This is similar to the pairing processes we saw between the sites and the array managers. 1. Select the vSphere Replication tab, and then click the “Configure VRMS connection” link in the Commands pane.
2. In the dialog box that opens, click Yes to continue with the pairing process. If necessary, enter the username and password to connect to the Recovery Site vCenter.
3. Click OK to any certificate warnings.
4. The wizard should discover the other VRMS in the Recovery Site and pair the two management systems together (see Figure 8.16).
In the VRMS status page you should see that the server has been successfully paired (see Figure 8.17). As with the pairing of sites in SRM there is a “Break VRMS connection” option in the Command pane should you need to change the relationship at a later stage.
Figure 8.16 Once the VRMS systems in the Protected Site and Recovery Site are configured it is possible to pair them together.
Figure 8.17 The VRMS should report that it is connected to the VRMS in the other site.
Deploying the VRS
The next stage is to deploy the VRS. If you remember, the VRS virtual appliance is a recipient of the changes taking place inside the VMs that have been protected by the VRMS. As a consequence, you need at least one at the Recovery Site for replication to work. It is possible to have more than one VRS to scale out the solution. For two-way replication to take place you would need at least one VRS at the Recovery Site and one at the Protected Site. Additionally, if you want to failback a VRS-protected VM, you would need a VRS at the Protected Site in order to synchronize any changes back to the Protected Site during the time you were running the VM at the Recovery Site; otherwise, data loss could occur. In my case, I decided to deploy a VRS appliance for both sites so that later on, when we come to carry out failover and failback tasks, everything will be in place for that to happen.
To import the appliance manually you can use the Deploy OVF Template menu option under the File menu in the vSphere client. The appliance is located by default on the vCenter server at the following location on the SRM server:
C:\Program Files (x86)\VMware\VMware vCenter Site Recovery Manager\www\VRS.ova
Alternatively, if you did install the UI extensions, select the vSphere Replication tab and then click the Deploy VRS Server link in the Commands pane.
The import process is almost exactly the same as the deployment of the VRMS that we covered earlier. The total disk size of the VRS is 9GB in the first instance constructed from two virtual disks (1GB thin and 8GB thick). The only difference with the VRS is that you are not prompted to set a password for the root account.
Registering the VRS
Once the VRS has been deployed and powered on you can register it with vCenter.
1. Select the vSphere Replication tab and click the Register VR Server link in the Commands pane.
2. In the Register VR Server dialog box (see Figure 8.18), navigate to the vCenter inventory and select the VRS that was imported in the previous steps.
3. After clicking OK, click Yes to confirm that you wish to register the VRS.
4. Click OK to confirm the certificate of the VRS.
5. Once the VRS has successfully registered, click OK to confirm the prompt. At this point, you should have the VRS registered at both sites (see Figure 8.19).
Now that this deploy and configure process has been completed the Getting Started pages should indicate that all the setups have been successfully configured (see Figure 8.20).
Figure 8.18 The VRS must be located in a folder or datacenter, and cannot reside in a vApp for the registration process to work.
Figure 8.19 Once the VRMS and VRS are running, the vSphere client will update adding their site names to the list.
Figure 8.20 The Getting Started Wizard steers you through the configuration process, acknowledging the completion of each stage.
Enabling and Monitoring vSphere Replication
Now that you have installed and configured the VR components it’s time to enable replication for your virtual machines. To test the new VR functionality I created an NFS datastore at the Protected Site that was driven by one of my NetApp filers, and I created an iSCSI volume at the Recovery Site driven by one of my Dell EqualLogic arrays. This will be sufficient to demonstrate that VR works across two entirely different storage protocols and vendors. I decided against using local storage in my tests, as local storage does not fulfill the requirements for vSphere features such as vMotion, HR, DRS, or DPM. To enable VR on a VM, follow these steps.
1. Ensure that the selected VM is powered on; then right-click VM and select Site Recovery Manager vSphere Replication. If you want to protect multiple VMs, switch to the VMs and Templates view, select a folder, and then select
the Virtual Machines tab. Select multiple VMs using either Ctrl-Click or Shift-Click; once your selection is complete, right-click and select the option to enable VR. 2. In the Configure Replication dialog box in the Replication Settings page move the slider bar to your desired RPO.
3. Optionally, you can set the file system of the VM to be quiesced during the replication process. If your VM is Windows-based and supports Microsoft Volume Shadow Copy Service (VSS), this can improve the consistency of your VM when it’s recovered in a DR event.
4. Using the Browse button select the datastore which will act as the destination or target for your replication. In this case, you are setting the location for the replication of the .vmx file. Notice how in the dialog box shown in Figure 8.21 the volume names indicate that the source is using NFS and the target is using iSCSI.
5. For each virtual disk that comprises the target VM, select a target location and, if you want, set what format the virtual disk should be in when it has been copied to the target (see Figure 8.22). This allows you to have a virtual disk set as “thick” in the Protected Site, but stored in the “thin” format at the Recovery Site.
Figure 8.21 In the Replication Settings dialog box you can configure the replication schedule and destination for the replication event.
6. Assign a VRS as the target for updates. As I stated before, it’s possible to have more than one VRS for scale-out capabilities; using auto-assign enables the system to pick the least loaded VRS hosts as the target (see Figure 8.23). Alternatively, you can manually assign the VRS for this VM. This would allow you to manually optimize your VR environment to make sure no single VRS is overloaded with updates.
Figure 8.22 Setting a target location and format
Figure 8.23 You can have the system choose the VRS, or you can choose one yourself.
Moving, Pausing, Resuming, Removing, and Forcing Synchronization
Once VR is in place, there are buttons to control the process. These options appear at the target or Recovery Site VRS (see Figure 8.24), and they are quite easy to understand. The “Move to” option allows you to move the VM from one VRS to another. You might start with a simple environment, but as your needs grow, so does your requirement for additional VRS. This option allows you to redistribute the load among your new VRS hosts. The Pause Replication and Resume Replication options allow you to temporarily stop and start replication between the two VRS at the Protected and Recovery Sites. You would do this if you were expecting some temporary network outage between the two sites, or if you were carrying out a major reconfiguration of your VR environment. The Remove Replication option removes and disables replication for a given VM, and removes it from the scope of the VRMS. You would carry out this task if a VM no longer needed protection, or at the end of the proof-of-concept phase. Finally, the Synchronize Now option is used to force an update between the two VRS hosts. You would use this if you had experienced an outage or a loss of network connectivity between the two VRS.
Enabling Replication for Physical Couriering
Sometimes, due to lack of bandwidth and a large virtual disk size, carrying out an initial synchronization becomes unfeasible. For this reason, it is possible to download the virtual disks that make up a VM to removable media, and then have the data securely couriered to the target Recovery Site. In this scenario, all that is required are the differences that have accrued during the physical shipping and uploading of the virtual disks. This is sometimes referred to as the sneakernet approach.
The process begins by taking a maintenance window on the VM, and powering it down. Then you can use vSphere’s datastore browser to download the virtual disk to a location that facilitates transfer to some type of removable media (see Figure 8.25).
Figure 8.24 The controls for the replication process. Currently there are no controls to limit the bandwidth allocated to the replication process.
Figure 8.25 By using the vSphere client’s download and upload buttons, it is possible to copy the VM to another location.
At the Recovery Site, you can browse the target datastore and create a folder with the same name as the VM—in my case, this is fs02. You can use the same datastore browser at the Recovery Site to upload the .vmdk file into this folder. When you run through the VR wizard the system will detect that there is already a .vmdk file there and will ask if you want to use it as the basis for an initial copy (see Figure 8.26).
Configuring Datastore Mappings
In my example, I only have one datastore at both locations utilized by the VRS. In more advanced configurations, you may have many datastores with many VMs on them protected by VR. Of course, it would be a chore for each VM, possibly with many disks, to have to specify the target location for every VM you protect. For this reason, VR has its own datastore mappings feature that allows you to configure the relationship between the relevant datastores. This should reduce the number of steps required to configure a VM for VR. Those steps include the following.
Figure 8.26 VR recognizes an existing image has been manually copied to the Recovery Site, and will use it as the source for the initial sync.
1. Select the vSphere Replication tab, and then select the Protected Site inventory.
2. Select the Datastore Mappings tab, and select the datastore which holds your vSphere-protected VMs (see Figure 8.27). In my case, this is the VRS-NFS datastore.
3. Select the Configure Mapping link, and in the corresponding dialog box select the target datastore in the list. In my case, this is the esx3_local volume (see Figure 8.28).
Figure 8.27 It is possible, although not required, to map datastores in a Protected Site to datastores in a Recovery Site.
Figure 8.28 The mapping of one local store to another held at the Recovery Site
As you can see, the setup of VR is relatively straightforward, but it does require that you go through each step methodically and in the correct order. Once the actual virtual appliances are correctly configured, the features are relatively easy to set up and use. Remember, you only need one management system per vCenter install (the VRMS), but you may require more than one replication server (the VRS) depending on the number of changes you expect to see in the file systems of your virtual machines. The next stage in the process is to create a Protection Group for the vSphere-replicated VMs, and then configuring a Recovery Plan for them as well.
The process for creating Protection Groups for VMs that are being replicated by either the storage vendor or VR is the same. The only difference is that a radio button indicating which type of replication you are using is shown in the Protection Group dialog box, as you can see in Figure 8.29.
Figure 8.29 The configuration SRM differs only slightly once you are creating Protection Groups and Recovery Plans.