Replicating VMware with RecoverPoint · EMC® RecoverPoint fully supports data replication and...

EMC® RecoverPoint fully supports data replication and disaster recovery of VMware ESX 3 and 4.

This document presents technical notes and recommended best practices for replicating VMware ESX 3 and 4 and virtual machines with EMC® RecoverPoint. It includes the following topics:

◆ VMware Overview............................................................................... 4◆ VMware Concepts ................................................................................ 5◆ Supported VMware features............................................................... 7◆ ESX Server replication topologies .................................................... 13◆ Installation and configuration .......................................................... 19◆ Configuring RecoverPoint for VMware.......................................... 20◆ Configuring VMware for RecoverPoint .......................................... 30◆ Management tasks and procedures ................................................. 37◆ Limitations, known issues, and fixed issues .................................. 46◆ Additional support information....................................................... 48◆ Additional documentation................................................................ 49

EMC® RecoverPointReplicating VMware

Technical NotesP/N 300-004-302

Rev A14

June 15, 2011

1

2

Revision history

Revision historyTable 1 on page 2 shows the revision history for this document.

Table 1 Revision history

Revision Date Description

A14 Jun 2011 • Updated VAAI support for Symmetrix splitter• Updated VMware features for Symmetrix splitter

A13 Jun 2011 • Updated VAAI support for SANTap and CLARiiON.

• Removed RDM/V support.• Updated Number of Exposed LUNs to

Number of VMware ITLs

A12 Feb 2011 • Updated VAAI support

A11 Nov 2010 • Corrected error in VAAI support table

A10 Nov 2010 • Added vSphere 4.1 and VAAI information

A09 July 2010 • Numerous important corrections and clarifications in the procedure for physical-to-virtual replication.

EMC RecoverPoint Replicating VMware

Revision history

A08 July 2010 • Table of VMware features supported by RecoverPoint expanded to include many more features.

• Fault Tolerance added to the description of new features.

• Calculation of number of SCSI targets exposed to RPA and to ESX corrected.

• Corrections made in the procedure for replicating physical raw device mappings.using host-based splitter.

• Added Replicating a Raw Device Map in the Microsoft Cluster environment.

• Corrections in procedure for enabling resignature on ESX 3.x.

• Added note about commit i ng open memory transactions before failing over or accessing image.

• Added procedure for recovering a LUN that was managed by an ESX cluster on the production side.

• Added limitation: SAN monitoring software may cause reservation conflict.

• Added limitation: After disabling image access, accessed image still appears in ESX Storage Management Console.

Table 1 Revision history

Revision Date Description

3EMC RecoverPoint Replicating VMware

4

VMware Overview

VMware OverviewVMware virtualization lets one computer do the job of multiple computers, by sharing the resources of one computer across multiple environments. VMware ESX Server is a virtualization layer that runs on physical servers. It abstracts processor, memory, storage, and networking resources to provision multiple virtual machines. VMware ESX server allows you to host multiple virtual machines and multiple applications on a single physical computer.

A virtual machine is a representation in software of a physical machine. It is a tightly isolated software container that can run its own operating systems and applications as if it were a physical computer. A virtual machine behaves exactly like a physical computer and its own software-based CPU, RAM, hard disk, and network interface.


VMware Concepts

VMware ConceptsESX: a virtualization layer that runs on physical servers. It abstracts processor, memory, storage, and networking resources to provision multiple virtual machines. VMware ESX server allows you to host multiple virtual machines and multiple applications on a single physical computer.

virtual machine (VM): a complete virtualized computer with processors, memory, networking, storage, BIOS, and others.

guest operating system (Guest): the operating system running on a virtual machine. Each virtual machine can run operating systems such as Windows, Linux, Solaris, or Netware. Applications run on the virtual machine unmodified.

VM file system (VMFS): is a cluster file system that stores ESX server virtual machines. Since the file system is clustered, several instances of ESX server can write to the same shared storage. On-disk locking ensures that a virtual machine is not accessed by more than one ESX server at a time. The cluster file system allows virtual machines to be restarted on another physical ESX server in case one fails.

raw device map (RDM): is a file in a VM file system that acts as a proxy for the physical disk. The raw device map contains metadata used to manage and redirect disk accesses to the physical device. This allows the virtual machine to directly access the storage LUN, instead of a virtualized storage in a VM file system.

vCenter Server: displays the status of all vCenter components. This allows you to quickly identify and correct failures.


6

VMware Concepts

Figure 1 Schematic of Raw Device Mapping

raw device map/physical mode (RDM/P): provides minimum SCSI virtualization of the mapped device. VMware passes all SCSI commands directly to the LUN, thereby exposing all the physical characteristics of the underlying hardware.

datastore: provides a simple model to allocate storage space to virtual machines. Each virtual machine is stored as a set of files in a directory in the datastore.

SCSI target: receives input from a SCSI initiator and performs write operations on behalf of specific LUNs.

splitter: a module that splits writes so that they are not only sent to the designated storage target, but a simultaneous out-of-band copy is also sent to the RecoverPoint appliance. The splitter may be located on the virtual machine, on a fabric switch, or on a VNX/CLARiiON array.

Host

VM

Data

Storage Group

LUN

Mappingfile

Read/write

File open

VMFS volume


Supported VMware features

Supported VMware featuresTable 2 on page 7 shows the VMware features supported by RecoverPoint.

VAAI support vSphere 4.1 introduces vStorage API for Array Integration (VAAI). VAAI commands are designed to speed up certain functions when an ESX server writes to a storage array by offloading specific functions to array-based hardware.

The new commands are:

Full copy. Can significantly speed up the process of deploying virtual machines. Implemented via xcopy SCSI command.

Block zero. May speed up bulk zeroing of a disk. Also called copy same.

Hardware-assisted locking. Implements a LUN locking mechanism that is more efficient in the clustered host environment. Also called Atomic Test and Set. Implemented using the Compare and Swap SCSI command.

Table 2 VMware features supported by RecoverPoint, according to splitter type

feature / splitter

Windows host–based in virtual machine Brocade SANTap

VNX/ CLARiiON Symmetrix

VM file system not supported supported supported supported supported

Raw Device Mapping in physical mode supported supported supported supported supported

High Availability (HA) not available supported supported supported supported

Distributed Resource Scheduler (DRS) not available supported supported supported supported

VMotion not available supported supported supported supported

Site Recovery Manager not supported supported supported supported supported

iSCSI not supported not supported not supported supported not supported

NFS volumes not supported not supported not supported supported not supported

Fault tolerance (FT) not available supported supported supported supported

Storage VMotion supported supported supported supported supported

vStorage thin provisioning supported supported supported supported supported


8


RecoverPoint splitters support each VAAI command at one of the following levels:

Unsupported. If the RecoverPoint splitter does not support a particular VAAI command, it must be disabled on all ESX servers.

Notice: Failure to disable an unsupported VAAI command may lead to data corruption, production data being unavailable to ESX hosts, degraded performance, or switch reboot.

Rejected. When RecoverPoint rejects the use of a VAAI command, VMware automatically immediately reverts to legacy behavior, with no risk to data or performance.

Supported. RecoverPoint supports the VAAI command and its functionality.

Table on page 10 shows the vStorage API for Array Integration (VAAI) commands supported by RecoverPoint. By default, all VAAI commands are enabled when upgrading to or installing ESX/ESXi 4.1. If the RecoverPoint splitter does not support or reject a particular VAAI command, this VAAI command must be disabled on all ESX servers in the vSphere cluster before presenting datastores to ESX hosts.

If a VAAI command is rejected by RecoverPoint, it is not necessary to disable it. As soon as RecoverPoint rejects the command, VMware reverts to legacy behavior without risk to data or performance.

To disable VAAI commands, refer to “Configuring VAAI commands to work with RecoverPoint.” on page 35.

Table 3 VAAI commands supported by RecoverPoint, according to splitter type

VAAI command Configuration Support

Windows host-base splitter in virtual machine

Hardware- assisted locking

• All Unsupported

Block Zeroing • All Unsupported

Full Copy • All Unsupported



SANTap splitter


• Storage Services Image 5.0(4j) and later• Storage Services Image 4.2(3k) and later in

4.2 series • Storage Services Interface image earlier

than 4.2(3k).

RejectedRejected

Unsupported

Block Zeroing • Storage Services Image 5.0(4j) and later• Storage Services Image 4.2(3k) and later in

4.2 series • Storage Services Interface image earlier

than 4.2(3k).

RejectedRejected

Unsupported

Full Copy • Storage Services Image 5.0(4j) and later

• Storage Services Image 4.2(3k) and later in SSI 4.2(#x) series

• Storage Services Interface image earlier than 4.2(3k).

Rejected and does not cause switch failureRejected and does not cause switch failureUnsupported and causes switch failures in all MSMs and in switches earlier than 9222i

Brocade splitter


• RecoverPoint 3.4 and later• Prior to RecoverPoint 3.4

RejectedUnsupported

Block Zeroing • RecoverPoint 3.4 and later• Prior to RecoverPoint 3.4

RejectedUnsupported

Full Copy • RecoverPoint 3.4 and later• Prior to RecoverPoint 3.4

RejectedUnsupported

VNX/CLARiiON splitter


• VNX splitter 3.4 with Flare 31• CLARiiON splitter 3.3.1 with Flare 30

SupportedSupported

Block Zeroing • VNX splitter 3.4 with Flare 31;

• CLARiiON splitter 3.3.1, with Flare 30

Supported

Rejected



10


New VMware features in RecoverPoint 3.2

The following new features in RecoverPoint enhance the support of replicated VMware volumes.

vCenter Server view vCenter Server view displays data from the VMware vCenter Server in the RecoverPoint GUI. In addition to displaying ESX servers and all their virtual machines, datastores, and RDM drives, the RecoverPoint VMware view also displays the replication status of each volume. The RecoverPoint vCenter Servers view is for monitoring only (read-only).

New features in VMware ESX 4

This section describes VMware features relevant to replication with RecoverPoint that were introduced or significantly improved in ESX 4.

Fault tolerance VMware ESX 4 adds support for fault-tolerant virtual machines. This new feature allows virtual machines to be up with zero downtime in the event that an ESX server fails.

Improved disksignature

VMware ESX 4 automatically recognizes volumes replicated by RecoverPoint. It is no longer necessary to enable disk resignature as in ESX 3.X (“Enabling resignature on ESX 3.X” on page 30). In addition, the new ESX 4 disk signature algorithm provides on-disk file locking, which prevents more than one server accessing a virtual machine at the same time.

Full Copy • VNX splitter 3.4 with Flare 31;

• CLARiiON splitter 3.3.1 with Flare 30

Supported, but without performance enhancement

Rejected

Symmetrix splitter


• VMAXe arrays Supported

Block Zeroing • VMAXe arrays Rejected

Full Copy • VMAXe arrays Rejected




VMFS volume grow VMware ESX 4 adds new and improved options to increase the capacity of a running VMFS datastore while the virtual machine remains powered up. ESX 4 supports two methods of expanding the capacity of a VMFS volume:

Add Extents. Add Extents, an option available on the ESX Host, Advanced settings, VMware Storage tab, creates a new partition that is dependent on the first one. If the first partition fails, the virtual machines will lose access to the entire volume.

This feature was introduced in ESX 3. and improved to allow non-disruptive expansion of the datastore while the virtual machines remain powered up. For procedures and best practices refer to “Extending VMFS volumes” on page 41.

Grow volume. Growing a volume is a new feature in ESX 4 that relies on the storage array’s ability to expand LUNs. Metadevices, such as metaLUN (VNX/CLARiiON) and hyper (Symmetrix) are the best suited for coordinating dynamic datastore growth of VMFS. The Grow volume option provides a single extent volume, which is fully available to virtual machines. For procedures and best practices refer to “Extending VMFS volumes” on page 41.

vStorage thinprovisioning

Starting with VMware ESX 4, VMware supports creating thin thinly provisioned virtual disks when deploying or migrating (converting) virtual machines. Thinly provisioned virtual disks use storage space more efficiently by only using the exact amount of resources needed for the virtual disk. When first created, the virtual disk will be allocated 1 MB of space in the datastore. As the space fills up, additional 1 MB chunks can be allocated, so that the amount of storage resources used grows as the disk size grows.

Thin provisioning is only available for VMFS-3 and later. Older VMFS versions cannot create thinly provisioned volumes.

Thinly provisioned disks can be deployed in the following use cases:

◆ when creating a virtual machine

◆ when cloning a virtual machine to a template

◆ when cloning a virtual machine using VMotion

◆ when using Storage VMotion to migrate virtual machine storage to another location

For procedures and best practices, refer to “Thin provisioning of virtual disks with RecoverPoint” on page 43.


12


ESX Server support forthird-party multipath

drivers

ESX 4 introduces support for third-party multipathing drivers. Currently, the EMC PowerPath driver with full multipathing features is the only currently available third-party multipathing driver.

The PowerPath driver for VMware ESX 4 is available for download at EMC Powerlink (powerlink.emc.com). The driver is labeled as PowerPath driver for VMware.

Improved StorageVMotion

VMware Storage VMotion provides a tool for relocating virtual machine disk files from one storage location (site) to another with continuous service availability and zero downtime. See also “Recovering from disaster using Storage VMotion” on page 45.

Storage VMotion no longer requires double RAM to be available at the destination host.

VMotion supports both migrating from thin disk to thick disk and from thick disk to thin disk.


http://powerlink.emc.com

http://powerlink.emc.com

ESX Server replication topologies

ESX Server replication topologiesRecoverPoint can replicate VMware application data either as part of a VMware File System (VMFS), or as a Raw Device Mapping (RDM) in physical mode (RDM/P). Virtual Raw Device Mappings (RDM/V) disks are not supported, because they allow the use of VMware snapshots. When using VMware snapshots, the writes are not sent to the RDM LUN, but to a snapshot area on a separate LUN. RecoverPoint (or any other block-based replication technology) is not aware of these writes; and can, therefore, not guarantee consistency of the replica.

In all cases, RecoverPoint replicates only entire LUNs.

When replicating application data with RDM/V volumes, do not use VMware snapshots. VMware snapshots prevent recovery of the entire virtual machine including the application data.

In the following cases, application data must be replicated to a Raw Device Mapping in physical mode:

◆ the splitter is on the virtual machine

◆ a physical host is replicated to a virtual machine

◆ a virtual machine is replicated to a physical host

◆ the application requires SAN-awareness (rare)

◆ the application vendor recommends RDM

◆ when running ESX servers on Microsoft Cluster Server shared disk

In all other cases, either VMware file systems or Raw Device Mappings may be replicated.

Boot volumes Boot volumes of virtual machines can be replicated. You can boot from a replicated boot volume only if the production machine and the replica are both VMFS.

When using host-based splitters on virtual machines, if you wish to replicate the boot volume, it must be configured as a boot-from-SAN volume in RecoverPoint.


14


◆ When adding the volume to the splitter, select Select boot-from-SAN peer for other site’s host. For details, refer to the EMC RecoverPoint Administrator’s Guide for your version of RecoverPoint.

When the splitter does not reside on the guest OS (virtual machine), boot volumes of ESX servers can both be replicated and used to boot up the virtual machines. When the splitter resides on the guest OS, it is possible to migrate the boot volume using the VMware Converter. For details, refer to “Migrating the physical boot volume to a virtual boot volume” on page 25.

Topologies for replicating VMware ESX Servers

When using a fabric-based (SANTap or Brocade) or array-based (VNX/CLARiiON) splitter, the entire VMware File System (VMFS), comprising both virtual machine boot volumes and application data can be replicated.

Figure 2 on page 15 shows an example of RecoverPoint replicating VMware File Systems. The entire VMware file system is replicated: not only the application data, but also the boot volumes of the virtual machines. Upon failover, the virtual machines are available at the remote site in the exact state that they were on the production side. The figure also shows that multiple ESX servers, for example, can fail over to a single server on the remote side; and that one virtual machine may write to more than one data volume.



Figure 2 Typical RecoverPoint deployment with VMware and a fabric-based or array-based splitters.

Figure 3 on page 16 shows an example of RecoverPoint replicating using Raw Device Mapping in physical mode.

CISCOSYSTEMS

Fabric switch RPA cluster

ESX Server 1

VM1

VM3 VM4

VM2

ESX Server 2

VM5 VM6

CISCOSYSTEMS

Fabric switchRPA cluster

ESX Server 1

VM1

VM3 VM4

VM2

WAN

VM5 VM6

Fibre Channel SAN

LUN

Datastore 1 Datastore 2

LUN

VMI bootvolume

VM3 bootvolume

VM4 bootvolume

VM2 bootvolume

Data1

Data3 Data4

Data2

VMFS volume

VM5 bootvolume

VM6 bootvolume

Data5a

Data5b Data6b

Data6a

VMFS volume

LUN

Fibre Channel SAN

LUN

Datastore 1 Datastore 2

LUN

VMI bootvolume

VM3 bootvolume

VM4 bootvolume

VM2 bootvolume

Data1

Data3 Data4

Data2

VMFS volume

VM5 bootvolume

VM6 bootvolume

Data5a

Data5b Data6b

Data6a

VMFS volume

LUN

LUNLUN


16


Figure 3 Typical RecoverPoint deployment with VMware replicating Raw Device Mappings in physical mode.

The figure shows an example of using Raw Device Mapping to replicate only the data volumes (VM1 and VM2); and an example of replicating both the boot and data volumes. When failing over configuration groups that do not include the boot volume (VM1 and VM2), virtual machines must be brought up manually on the remote

Fibre Channel SAN

RPA cluster

ESX Server 1

VM1

VM2

ESX Server 2

VM3

VM4

CISCOSYSTEMS

Fabric switchRPA cluster

ESX Server 1

VM4

VM3

WAN

Datastore 1

VMFS volume

Datastore 2

VMFS volume

VM5

Production Remote

Map file1App

data

Map file3bootand app

data

CISCOSYSTEMS

Fabric switch


data

VM6

Fibre Channel SAN

LUN

LUN

LUN

LUN

VM 1VM 2

read/write

Map file2App

dataVM 3VM 4

read/write

Datastore 1

VMFS volume

Datastore 2

VMFS volume

Map file1App

data


data


data

LUN

LUN

LUN

LUN

VM 5VM 6

read/write

Map file2App

dataVM 3VM 4

read/write



side (VM5 and VM6) before failing over. The virtual machines brought up on the remote site must be mapped to the corresponding physical LUN.

When the boot volume is also replicated, virtual machines are available on the remote side, in the exact state they were on the production side.

When replicating Raw Device Mappings, the datastore contains only the mapping file. The mapping makes the LUN appear to the virtual machine as a file in the VMware file system. The mapping file (not the raw LUN) is referenced in the virtual machine configuration. When a LUN is opened for access, the VMware file system resolves the raw device map file to the correct physical device. Thereafter, reads and writes go directly to the raw LUN rather than going through the mapping file.

The figures show raw device mappings and VM file system replication separately, but it is possible to have both in the system consistency group or in the same environment.

If replicating only application data, virtual machines on the remote site do not necessarily need to correspond one-to-one to virtual machines on the production site. For instance, if there are two or more virtual machines on the production site, it might be sufficient to have one on the remote site. It is also possible to have less virtual machines on the production site and more on the remote site.

Replicating physical to virtual environment

Many organizations choose to replicate the output of their production servers to virtual servers (P2V) at the disaster recovery site. RecoverPoint supports only block replication of data volumes to VMware physical Raw Device Maps (RDM/P). Physical boot volumes cannot be replicated this way, but they can be converted from physical to virtual by using the VMware ESX 4 migration tool.

For best practices, please refer to “Physical-to-virtual replication” on page 24.

VMwarephysical-to-virtual

migration

VMware ESX 4 provides a migration tool, vCenter Converter (known in ESX 3 as Converter Enterprise), which enables single or recurring migration (conversion) of physical servers to virtual servers. This is especially useful for converting physical boot volumes to virtual boot volumes. For additional technical information and product features,


18


refer to http://www.vmware.com/converter. For procedures and best practices, refer to “Migrating the physical boot volume to a virtual boot volume” on page 25.

Replicating virtual to virtual environment

Organizations may choose to implement VMware virtual servers both at the production site and at the disaster recovery site. RecoverPoint can fully protect virtual servers and their application data using virtual-to-virtual replication to either a local site (CDP), a remote site (CRR), or both (CLR). RecoverPoint provides point-in-time access to replicated volumes for both testing and disaster recovery. RecoverPoint can fully protect both virtual machine file systems (VMFS) and physical raw device mappings (RDM/P).

For best practices, please refer to “Virtual-to-virtual replication” on page 29.


http://www.vmware.com/converter

Installation and configuration

Installation and configurationThis section covers installation and configuration required to use RecoverPoint to replicate VMware ESX servers. This section contains the following topics:

◆ Storage configuration......................................................................... 19◆ Configuring RecoverPoint for VMware .......................................... 20

• Configuring and installing intelligent fabric-based and VNX/CLARiiON -based splitters ............................................. 21

• Configuring host-based splitter environment on VMware guest operating system ............................................................... 21

• Physical-to-virtual replication.................................................... 24

• Virtual-to-virtual replication ...................................................... 29

◆ Configuring VMware for RecoverPoint .......................................... 30• Enabling resignature on ESX 3.X ............................................... 30

• Multipath policy........................................................................... 31

• VMware temp and swap files .................................................... 32

Storage configuration

As indicated in VMware documentation, storage arrays may need to be configured to work with ESX. For the configuration required for your SAN storage device to work with ESX server, refer to “Setting Up SAN Storage Devices with ESX Server” in the VMware ESX Server SAN Configuration Guide for your version of VMware.

To use VMware ESX 4 VMFS Volume Grow (refer to “VMFS volume grow” on page 11), verify that your storage array supports LUN expansion. Metadevices, such as VNX/CLARiiON’s metaLUN, Symmetrix’s hypervolumes, and third-party arrays supporting online LUN expansion are best suited for VMFS datastore growth.

When using EMC Symmetrix DMX storage arrays with VMware ESX Server, ensure that the SPC-2 bit is enabled on the Symmetrix arrays. Refer to Primus solutions emc71378 and emc206829, and VMware documentation for more information.


20

Configuring RecoverPoint for VMware

Configuring RecoverPoint for VMwareEach VM file system and all of its LUNs must be in a single consistency group or in a single group set. If it becomes necessary to recover data from a previous point in time of a RecoverPoint replica, it will be necessary to roll back all LUNs and all the virtual machines in the consistency group. You may wish to create multiple VM file system volumes and place them in separate consistency groups, so that you can distribute virtual machines in separate VM file systems and manage the VM file systems independently of each other. This allows you finer-grained recovery of virtual machines.

The following steps must be performed to configure RecoverPoint to replicate VMware File Systems (VMFSs) or Raw Device Maps (RDMs). Normally, you perform these procedures while creating the consistency groups for the LUNs to be used by VMware.

1. Verify that reservation support is enabled.

At the RecoverPoint Management Application, in the Navigation pane, select the consistency group. In the Components pane, locate the Advanced section. Verify that Reservations support is checked.

2. In the Advanced section of the Components pane, set Host OS. Select the appropriate value from Table 4 on page 20.

Table 4 Value to set for Host OS when replicating VMware virtual machines

Version of RecoverPoint Guest OS splitter location Host OS setting

3.0 Windows fabric or CLARiiON VMware ESX

3.0 Windows virtual machine Windows

3.0 not Windows fabric or CLARiiON VMware ESX

3.0 not Windows virtual machine not supported in this version

3.0 SP1 and later Windows fabric or VNX/CLARiiON

VMware ESX Windows

3.0 SP1 and later Windows virtual machine Windows

3.0 SP1 and later not Windows fabric or VNX/CLARiiON

VMware ESX

3.0 SP1 and later not Windows virtual machine not supported in this version



Configuring and installing intelligent fabric-based and VNX/CLARiiON -based splitters

There are no special issues in installing and configuring intelligent-fabric–based or VNX/CLARiiON-based splitters in an ESX environment. The procedures are the same as documented in the EMC RecoverPoint Installation Guide or EMC Deployment Manager Product Guide for your version of RecoverPoint.

Configuring host-based splitter environment on VMware guest operating system

Host-based splitters are supported on VMware virtual machines, but only for the Windows guest operating systems. Refer to the EMC Support Matrix for the exact Windows guest operating systems that are supported.

Replicating Raw Device Mappings allows a virtual machine to have direct access to a LUN on the physical storage array. When a virtual machine has direct access to a LUN, only that one virtual machine may access the LUN.

Each path from an ESX to the RPA is represented by one SCSI target on the ESX. Each SCSI target contains the number of LUNs defined by the Number of VMware ITLs (in releases of RecoverPoint earlier than 3.4 SP1, Number of exposed LUNs) parameter specified on the RPA. On each ESX that might run virtual machines with a host-based splitter, verify that it sees all paths to RPAs.

Each virtual machine must be mapped with Raw Device Mapping to one LUN from every SCSI target that represents an RecoverPoint appliance (RPA) path.

When an ESX host is zoned with an RPA cluster without adding a splitter, the LUN will always be shown as 937.94 GB, the default size for the RPA (fake) LUN exposed to the ESX host from an RPA. Figure 4 on page 22 shows four virtual SCSI targets (two RPA targets, each one visible through two ESX HBAs (vmhab0 and vmhab1). This is RecoverPoint’s normal behavior.

The example that follows shows how to calculate that available of VMware ITLs (LUNS per ESX host).

The number of SCSI targets that the RPA exposes is:

# of RPAs * # of SCSI ports per RPA

In consequence, the number of VMware ITLs (LUNs that are exposed to the ESX) is:

# of SCSI targets * # of VM LUNs to replicate


22


Example 1 If you expose 1 LUN from 2 RPAs and each RPA has 2 paths to the ESX server, each ESX will see 4 SCSI targets with one LUN per SCSI target.

In this example, you will be able to replicate only one virtual machine LUN. All LUNs need to be assigned to the required virtual machines as virtual disks (RDM physical).

Figure 4 SCSI targets in Virtual Interface

Example 2 If you expose 11 LUNs from 8 RPAs and each RPA has two paths, each ESX will see 16 SCSI targets with 11 LUNs per SCSI target.

In this example, you will be able to replicate up to eleven virtual machine.

In order to replicate ESX RDM/P using the RecoverPoint host-based splitter, do the following:



1. Indicate the number of VMware ITLs (LUNs that you want to be exposed to each ESX). Refer to examples in “Configuring host-based splitter environment on VMware guest operating system” on page 21. For the maximum Number of VMware ITLs (in releases of RecoverPoint earlier than 3.4 SP1, Number of Exposed LUNs), refer to the release notes of your version of RecoverPoint.

2. Specify the number of VMware ITLs (LUNs to expose):

• In RecoverPoint 3.1 and later:At the GUI Installer, set the Number of exposed LUNs (In RecoverPoint 3.4 SP1 and later, Number of VMware ITLs). Refer to the EMC RecoverPoint Installation Guide or EMC RecoverPoint Deployment Manager Product Guide for instructions.

• In all versions of RecoverPoint 3.0:At the RecoverPoint Installation Manager, from the main menu select Setup > Modify > Site n details > Number of exposed LUNs.

3. If you have ESX servers at both sites, be sure to configure RecoverPoint consistency group policy for both sites. Refer to Table 4 on page 20.

4. For each virtual machine, do the following:

a. For each fake LUN that appears in the ESX storage pane, add an RDM/P virtual disk in the settings of the virtual machine (add every SCSI target whose capacity is listed as 937.94 GB).

For example, if you have two RPAs with two paths each, map 4 LUNs to each virtual machine, one LUN from each SCSI target.

b. In the settings of the virtual machine, add volumes to be replicated as additional RDM/P virtual disks.

5. Install the host-based splitter on each virtual machine as follows.

a. Extract the RecoverPoint driver package into a temporary folder.

b. From the temporary folder, execute SETUP.exe. Choose Typical installation.

SANdiagnostics will run automatically.


24


c. If there are SAN diagnostics errors, you must fix them and run the SAN diagnostics again.

d. If there are no SAN diagnostics errors, press Finish.

e. When prompted, allow the RecoverPoint system to restart automatically.

f. At the RecoverPoint Management Application, click the Splitters tab. Add the newly installed host-based splitters.

g. If the LUNs are not attached automatically, attach the relevant LUNs to the host-based splitter driver.

Physical-to-virtual replication

When replicating application volumes from physical servers to virtual servers using RecoverPoint, the following tasks must be performed to avoid network contention and application inconsistency:

1. Preparation before replication

2. Setting up replication

3. Migrating the physical boot volume to a virtual boot volume

4. Adding the replicated application volume to the migrated virtual machine

5. Testing migrated virtual machine

The following sections contain the procedures for each of these tasks.

Preparation before replication1. Create a back-up of the entire physical server including the boot

volume and all application volumes.

2. Record the drive mapping (in the Windows operating system) of the (application) data volume that you plan to replicate with RecoverPoint, computer network settings, and the computer name.

3. Verify that the boot volume contains only files that are necessary for the operating system. Place all files that need to be replicated, but are not essential to the operating system, in data volumes. This practice will ensure point-in-time protection for frequently modified files.



Setting up replication1. Specify RecoverPoint replication policies. Refer to “Configuring

replication policies” in the EMC RecoverPoint Administrator’s Guide.

2. Make sure to specify the correct value for the Host OS. For details, refer to the Administrator’s Guide for your version of RecoverPoint.

Migrating the physical boot volume to a virtual boot volumeFigure 5 on page 25 and Figure 6 on page 26 show possible configurations for the migration of the boot volume (and other non-replicated drives, if they exist) from a physical production server to an ESX server at the replica site.

Regardless of the method selected for converting the boot volume, the physical server at the production site must contain a LUN for the data volume; and the ESX server at the replica site must contain a raw device mapped LUN for the replica of the data volume.

Use the following procedure to migrate the physical boot volume at the production site to the virtual boot volume at the disaster recovery site.

Figure 5 Boot volume copied to ESX server at replica site

Production Site Remote/DR Site

Physical ServerVMware ESX Server

RDM/P

App Volume

Boot Volume

App Replica

VMFS

Converted Boot Volume

VMware Converter convertion

RecoverPoint CRR replication


26


Figure 6 Boot volume copied to ESX server at production site

1. From Table 5 on page 26, select the desired configuration for converting the boot volume from a physical to a virtual volume. Use the VMware Converter migrate only the boot volume and other non-replicated drives.

Production Site Remote/DR Site

Physical Server

RDM/P

App Volume

Boot Volume

App Replica

VMFS

VM Boot ReplicaVMware Converter

convertion

RecoverPoint CRR replication

VMware ESX Server

VMFS

Converted Boot Volume

VMware ESX Server

RecoverPoint CRR

replication

Table 5 Two scenarios for physical to virtual conversion of boot volume (page 1 of 2)

Boot volume copied to ESX server at replica

Boot volume copied to ESX server at production

• Refer to Figure 5 on page 25. • Refer to Figure 6 on page 26.

• Physical server boot volume is copied to ESX server at replica site

• Converter can reside on either site

• Physical server boot volume is copied to ESX server at production site

• Converter must reside only on production site

• Converted boot volume is replicated as a VMFS volume to replica site.

• Requires ESX server at replica site configured with mapped SAN LUN as VMFS for converted boot volume

• Requires extra ESX server on production site.

• Requires ESX server at replica site configured with mapped SAN LUN as VMFS for converted boot volume



2. Verify that the migration of the boot volume (and other non-replicated volumes, if relevant) is completed while virtual machines on the replica side are still powered down.

3. The migration (conversion) process also creates the virtual machine for the migrated boot volume. Verify that the virtual machine was created successfully and that the virtual machine settings show the newly migrated (converted) virtual disk.

Adding the replicated application volume to the migrated virtual machineAt the remote site, expose the replicated application LUN to the migrated virtual machine. Use the following procedure:

1. Check that the replicated application LUN is exposed to the remote-site ESX host that contains the migrated virtual machine.

2. In the RecoverPoint Management Application, check that a splitter is attached to the replicated application LUN.

3. In RecoverPoint, enable image access.

4. On the ESX host, rescan disks and add the new replicated application LUN as a physical Raw Device Map (RDM/P).

5. On the migrated virtual machine’s settings menu, add a virtual disk, and select the new replicated application LUN as a physical Raw Device Map (RDM/P).

6. Connect the migrated virtual machine to a virtual network that is isolated from the network of the physical server on the production site (to avoid contention).

7. Power up the migrated virtual machine and do the following:

a. Verify that the Windows drive letter of the new replicated application LUN is the same as the driver letter of the physical application LUN on the production server.

• Low-cost solution, as only one ESX server is required.

• Conversion is slow, as entire boot volume must be transferred over link to replica site.

• Conversion on local site and replication to remote site is faster solution.

Table 5 Two scenarios for physical to virtual conversion of boot volume (page 2 of 2)

Boot volume copied to ESX server at replica

Boot volume copied to ESX server at production


28


b. Verify that the network settings of the virtual network interface are identical to those of the physical network that you recorded in step 2 on page 24.

c. For driver compatibility and best performance, if the VMware tools were not installed as part of the physical-to-virtual migration, install them now.

d. When required by post-migration tasks, reboot the migrated virtual machine.

Testing the migrated virtual machine1. To avoid domain contention and application inconsistency when

testing replica images with a migrated virtual machine, isolate the migrated virtual machine on a dedicated virtual network as follows. If this is not done, the production server should be taken down before accessing replica images. It is strongly recommended to use the following procedure to isolate the domain controllers instead of taking down the production servers.

2. Use the VMware Converter to migrate (convert) a Microsoft Domain Controller from the physical production network to reside on the same domain as the migrated virtual machine.

3. Verify that the migrated domain controller’s virtual machine is available on the same host ESX as the application’s migrated virtual machine.

4. Create an isolated virtual network containing both the migrated domain controller’s virtual machine and the application’s virtual machine.

5. Bring up the migrated domain controller’s virtual machine, and make sure that all roles from the production network were copied to the migrated domain controller.

6. Bring up the application’s migrated virtual machine. Since the Microsoft domain infrastructure is available, the services should come up correctly and be fully functional.

7. On the remote ESX host, power down the migrated domain controller and application virtual machines.

8. When finished testing, in RecoverPoint, disable Image Access.



Virtual-to-virtual replication

The following sections describe recommended and required best practices for virtual-to-virtual environment replication. For descriptions of the possible VMware replication topologies, refer to “ESX Server replication topologies” on page 13.

Replicating VMFSvolumes

A single VMFS volume can be used to contain both the boot volume and the data volume; or one VMFS may be used for the boot volume and another one for the data volume. To replicate VMFS volumes, use the following procedure:

1. Place both the boot volume and the data volume VMFS in one consistency group.

2. Configure RecoverPoint for replication as needed. Make sure to set the correct Host OS type. Refer to “Configuring RecoverPoint for VMware” on page 20 for details.

Replicating RDMvolumes

In the following use cases, a Raw Device Mapping disk type must be used instead of a VMFS disk type:

◆ If the volume size exceeds the size limitation for a virtual machine file system

◆ If SAN awareness is needed, for instance when using SAN tools, such as SAN Snapshot, Direct Backup, performance monitoring, or SAN management

◆ If the guest OS (virtual machine) is running a Microsoft Cluster Server

◆ If the virtual machine is using a host-based splitter

Replicating an RDM inthe Microsoft Cluster

environment

When the replicated LUN functions as a clustered shared volume (quorum disk), the virtual machines that act as the cluster nodes must have SCSI controller sharing enabled; otherwise, only a single virtual machine will be able to lock this LUN. The other virtual machines will not have access to the locked LUN.


30

Configuring VMware for RecoverPoint

Configuring VMware for RecoverPointThis section contains procedures that should be performed to prepare VMware objects for replication with RecoverPoint.

Enabling resignature on ESX 3.X

The following must be performed on each ESX 3.X host (both production and replica hosts) that is mapped to the LUNs being replicated by RecoverPoint. In ESX 4.X, this procedure is automatic, and does not need to be performed.

1. In the VMware Infrastructure client, in the Inventory panel, select the ESX.

2. Click the Configuration tab and click Advanced Settings. Click OK.

3. To preserve the names and signatures of replica datastores:

a. The production ESX servers must reside on a SAN that is completely isolated from the replica servers.

b. Set LVM.EnableResignature = 0.

When setting LVM.EnableResignature = 0, the ESX server will not check signatures. This may cause data corruption if more than one ESX server can see the same storage LUN.

4. If production and replica ESX servers reside on the same SAN:

Select LVM. Set LVM.EnableResignature = 1.

Setting LVM.EnableResignature = 1 forces the ESX server to resignature the replicated datastore, preventing data corruption.

5. Rescan the volume.

6. Best practice: each time before accessing an image in a replica, verify that these steps were performed.

If EnableResignature is enabled, cloned volume paths in /vmfs/volumes/<old UUID> will be changed to /vmfs/volumes/<new UUID> and the datastore name for the VMFS volume with the new signature is changed from <label> to snap-<system-generated number>-<label>.



Since the datastore has been identified as a snapshot rather than a production original, when you import an existing virtual machine from the cloned (replicated) volume, you will be prompted to select one of the virtual machine options in Table 6 on page 31.

For additional information and troubleshooting of disk signature problems, refer to KB Articles 1003964, 1009565, 9453805, and 1002896 available at kb.vmware.com.

Multipath policy The ESX multipath driver can maintain alternative storage connectivity in case of hardware failure. To take advantage of this feature, choose the appropriate policy from the options in Table 7.

To avoid bugs and limitations in the ESX 3.5 multipath driver, always apply the latest patches. For details, refer to the following VMware KB articles: 1008130 and 1008088 at kb.vmware.com. See also “Setting the Preferred Path” in VMware Infrastructure Online Library, ESX Server Edition at www.vmware.com.

Table 6 Virtual machine options

Option Use

Create To create a new UUID. Use for testing, image access, and permanent failover to this site.

Keep To retain the current UUID. Use only for temporary failover and repairing production storage. When you fail back, the virtual machine at production will recognize this volume as belonging to it.

Always create Do not use.

Always keep Do not use.

Cancel

Table 7 Multipath policy

Storage configuration Multipath policy

Active-active Fixed (preferred path)

Active-passive MRU (Most Recently Used)


kb.vmware.com

kb.vmware.com

kb.vmware.com

kb.vmware.com

www.vmware.com

32


For ESX 4.X, refer to “ESX Server support for third-party multipath drivers” on page 12.

VMware temp and swap files

VMware uses the temporary files listed in Table 8:

Note: Before failing over a LUN with RecoverPoint or accessing an image on the replica side with RecoverPoint, ensure that a replicated virtual machine commits its open memory transactions to the replicated LUN. To ensure such consistency, shut down the virtual machine, so that RecoverPoint will bookmark a consistent snapshot.

When shutting down the virtual machine is not possible (for instance, when an unexpected disaster occurs at the production site), the recovery will be similar to recovering from an unexpected disaster, such as a power outage, of a physical server,

Best practices relatedto temporary and

swap files

The best practices listed here are described in the following sections:

1. Best practices according to virtual machine swap file location (in ESX Configuration)

a. Replicating by storing the swap file in the same directory as the virtual machine

b. Replicating by storing the swap file in a dedicated datastore

Table 8 VMware temporary files

Temporary file Location…

ESX (host) swap file for running virtual machines

Normally, in the virtual machine’s folder and datastore. Location can be modified to be placed in a different dedicated datastore. To modify, refer to Figure 7 on page 34.

virtual machine (guest) operating system swap file

Inside the virtual machine’s VMDK.

virtual machine (guest) application temporary file

Inside the virtual machine’s VMDK; named according to the application, for example: MS SQL Tempdb



2. Choosing single or multiple datastores across virtual machines in Distributed Resource Scheduling clusters

3. Configuring virtual machine (guest) application temporary files

Best practices according to virtual machine swap file location (in ESX Configuration)

The following guidelines are recommended for best performance and least chance of errors when replicating virtual machines with swap files a) in the default location; b) in a non-default location.

A. Best practice when replicating by storing the swap file in the same directory as the virtual machine1. Verify that the total physical memory resources of the ESX (host)

are greater than the total of all RAM configured for each virtual machine (configured through the virtual machine settings) running on the host.

2. Verify that all virtual machines are operating within their configured resource limits (both for memory and for CPU). This will avoid overcommitting ESX memory.

3. Verify that each virtual machine resides in its own datastore. This practice is strongly recommended, as it will greatly improve the Recovery Point Objective; granularity of recovery per virtual machine; and performance per virtual machine.

4. Verify that the WAN line dedicated to replication has enough bandwidth to cope with total maximum I/O rate for all replicated virtual machine datastores.

5. Verify that the number or virtual machines running on one ESX does not exceed the physical resources of the ESX.

6. If you notice heavy use of the swap file in the VMware Service Console, consider increasing the amount of RAM assigned to the ESX Server. Refer to KB article 1003501 at kb.vmware.com.


kb.vmware.com

kb.vmware.com

kb.vmware.com

34


Figure 7 Changing the default settings for virtual machine swap file location in the ESX host configuration

B. Best practice when replicating by storing the swap file in a dedicated datastore1. Assign the swap file to a datastore that is not replicated.

2. Provision a single datastore per ESX to avoid performance degradation when sharing datastores among multiple ESXs.

3. When using VMware Site Recovery Manager, VMware highly recommends to place the virtual machine swap file on non-replicated LUNs. For details, refer to the Site Recovery Manager Release Notes.

4. To configure a non-default location for a virtual machine swap file, refer to the VMware KB Articles 1004082 and 1006942 at kb.vmware.com.

5. To configure VMotion and a non-default location for a virtual machine swap file, refer to the VMware KB Articles 1007650 and 1004906 at kb.vmware.com.

Since RecoverPoint replicates on the block level rather than on the file level, the entire datastore (physically, an entire storage LUN) is replicated, regardless of the file content. When deciding whether to replicate datastores represented a single virtual machine or multiple virtual machines, the following should be taken into consideration:


kb.vmware.com

kb.vmware.com

kb.vmware.com

kb.vmware.com

kb.vmware.com

kb.vmware.com


ESX swap file locationin a Distributed

Resource Schedulercluster

When the ESX is part of a VMware Distributed Resource Scheduler cluster, the locations of the ESX (host) swap files is determined by the policy settings of the cluster, which affect all virtual machines managed by the cluster.

The order of precedence of swap file settings is:

1. virtual machine (overrides all other settings)

2. cluster policies

3. ESX (hosts)

Virtual machineapplication data

swap files

Applications use temporary files (such as SQL Server’s Tempdb file) in much the same way that virtual machines use swap files. As long as these application temporary files are not needed to recover the application, the most efficient practice is to exclude these files from replication.

Configuring VAAIcommands to workwith RecoverPoint.

vSphere 4.1 introduces vStorage API for Array Integration (VAAI). By default, VAAI commands are enabled upon installation. If your release of the RecoverPoint splitter does not support a VAAI command, that command must be disabled in all ESX servers. Failure to disable an unsupported VAAI command can cause data corruption, production data being unavailable to ESX hosts, degraded performance, and switch reboots.

For RecoverPoint support of VAAI commands, refer to Table on page 10. Use the following procedure to disable VAAI commands that are not supported by your configuration.

To disable VAAI commands:

1. In the vSphere client inventory panel, select the host.

2. Click the Configuration tab and from the Software menu, select Advanced Settings.

3. To disable Hardware-Assisted Locking, click VMFS3, and set the value of VMFS3.HardwareAcceleratedLocking to 0.

4. To disable Full Copy, click DataMover, and set the value of DataMover.AcceleratedMove to 0.

5. To disable BlockZeroing, click DataMover, and set the value of DataMover.AcceleratedInit to 0.

6. To save the changes, click OK.


36


7. Make sure every unsupported command on every replicated ESX Server is disabled.


Management tasks and procedures

Management tasks and proceduresThis section describes how to perform common VMware and RecoverPoint procedures when replicating VMware with RecoverPoint.

Making changes in VMware

Because RecoverPoint replicates entire LUNs, any changes you make inside VMware will be replicated, regardless of the nature of the change, as long as all LUNs involved are replicated by RecoverPoint. For instance, changing a guest operating system configuration, moving VMs across datastores, adding or extending a datastore, or adding or removing a VM will be replicated correctly.

Single or multiple virtual machines per datastore

Since RecoverPoint replicates on the block level rather than on the file level, the entire datastore, which corresponds to a physical storage LUN, is replicated regardless of file contents. The following factors need to be considered when deciding whether to replicate a single virtual machine or multiple virtual machines per datastore:

◆ When each datastore hosts only a single virtual machine, RecoverPoint can provide point-in-time recovery for the virtual machine. This is the method of choice when recovery per virtual machine is required.

◆ When a datastore hosts multiple virtual machines, RecoverPoint can provide point-in-time recovery only for all virtual machines together. This is the method of choice when a group of virtual machines must be recovered as a set.

SCSI reservationconflicts with multiplevirtual machines per

datastore

Where multiple virtual machines reside on a single replicated datastore, a SCSI reservation conflict might occur. A SCSI reservation conflict is more likely if one of the following is true:

◆ LUN size is very large (TB or more)

◆ Large number of virtual machines distributed over a small number of LUNs

◆ Large number of ESX servers in the environment

SCSI conflicts may show up as any of the following in the RecoverPoint environment:

◆ Unexpected consistency group resynchronization


38


◆ “Splitter write may have failed” error messages at the RecoverPoint Management Application. These errors can degrade the Recovery Point Objective and the consistency of replicated volumes. For details, refer to EMC Primus case 204967.

To troubleshoot problems related to SCSI reservations in replicated volumes, refer to KB Articles 1002293, 1003955, and 1005009 at kb.vmware.com.

Best practices relatingto virtual machines inreplicated datastores

◆ Assign each datastore containing virtual machines to its own RecoverPoint consistency group. If virtual machines in different consistency groups need to recovered to the same point-in-time, use the RecoverPoint group set feature to bookmark consistent recovery points across the consistency groups.

◆ As much as possible, aim to have the same number of virtual machine in each datastore.

◆ For best performance, keep LUNs as small as practical.

Image access, testing, and failover

When accessing an image of a virtual machine, the datastore appears in the ESX datastore list. Before failing over, perform the procedure in “Multipath policy” on page 31. In RecoverPoint, the procedures for accessing images, testing, failing over, or failing back are identical for VMware consistency groups and any other consistency group. Follow the procedures in the RecoverPoint Administrator’s Guide.

Recovering a LUN thatwas managed by a

standalone ESXproduction server

Manually add the desired virtual machine datastore to the ESX inventory: in the ESX Server Management Console, select Configuration > Datastores > Add Storage. See Figure 8 on page 39.


kb.vmware.com

kb.vmware.com


Figure 8 Adding a replicated datastore to an ESX server

Recovering a LUN thatwas managed by an

ESX cluster withstandalone ESX server

When recovering a virtual machine that was managed by an ESX cluster on the production side, with a standalone ESX server on the replica side, extra steps are required in the Add Storage wizard.

To add the replicated virtual machine datastore to the ESX inventory, follow the procedure in “Recovering a LUN that was managed by a standalone ESX production server” on page 38. An extra screen (“Extra configuration screen when adding replicated ESX clustered datastore” on page 40) appears in the Add Storage wizard. When this screen appears, select the Keep the existing signature option.


40


Figure 9 Extra configuration screen when adding replicated ESX clustered datastore

The replicated disks are identical to the disks on the production side (at the selected point-in-time). You need to ensure that environmental settings outside of the scope of the RecoverPoint replication, such as IP address, DNS server location, and DHCP settings are appropriate for the remote environment.

Adding a physical volume

To add a physical volume:

1. Add the volume to the ESX inventory (mask volume to ESX server and rescan for new volumes).

2. The procedure for adding a physical volume in RecoverPoint is identical for VMware consistency groups and any other consistency group: add it to a RecoverPoint replication set, following the procedures in the RecoverPoint Administrator’s Guide.



Extending VMFS volumes

There are two options available for extending VMFS volumes: Add Extents and Grow Volumes. The use cases and procedures for each one are described in the following sections.

Use cases for usingAdd Extents

Use the Add Extents feature in the following use cases:

◆ Storage array does not support dynamic LUN expansion

◆ Maximizing efficient use of storage is more important than storage performance (can select RAID type for best use of storage space)

For procedures, refer to “Procedure for replicating with Add Extents feature” on page 41.

Use cases for usingAdd Extents

Use the Grow volume feature in the following use cases:

◆ Storage array supports dynamic LUN expansion’

◆ Performance (RAID type) must be preserved after expansion

For procedures, refer to “Procedure for replicating with Grow Volumes feature” on page 42.

Procedure forreplicating with Add

Extents feature

To Add Extents, use the following procedure and best practices:

On the storage array:1. If running ESX 3.5, bring down all virtual machine that reside on

the VMFS to be enlarged. In ESX 4, virtual machines can remain powered up while extending the datastore.

2. Determine how much the replicated volume needs to be enlarged.

3. Provision the production extent LUN and the replica of the extent LUN. They should both be exactly the same size.

4. Present the extent volume to both the production ESX server and the production site RPAs.

5. Present the replica extent volume to both the ESX server and the RPAs on the disaster recovery site.

On the production ESX server:1. On the ESX host, Advanced Settings, Storage menu, select

Rescan.

2. Select the extended datastore and right-click. Select Properties.

3. In ESX 4, select Increase; in ESX 3.5, select Add Extent. The Extent Device screen appears.


42


4. On the Extent Device screen, select the LUN to which you wish to add an extent. Answer the question that appear in the on-screen wizard (how much storage capacity do you wish to add to the LUN?).

5. Verify that the updated volume shows the added extent and the increased storage capacity.

At the RecoverPoint Management Application:RecoverPoint can replicate the new extended volume in one of two ways:

◆ By adding an additional consistency group containing only the new extent. This procedure does not disrupt replication.

a. Create a new consistency group containing the new extent volume only.

b. Create a group set containing the original consistency group and the new consistency group.

◆ By deleting the current replication set and replacing it with a new replication set containing the newly extended volume. This procedure disrupts replication and requires resynchronization:

a. Locate and disable the consistency group containing the LUN to be expanded.

b. Click Replication Set tag. Remove the replication set containing the LUN to be expanded.

Procedure forreplicating with Grow

Volumes feature

The following best practices should be observed when using the Grow Volumes feature (available only in ESX 4 and later).

On the storage array:1. Determine how much the replicated volume needs to be enlarged.

2. Grow both the production LUN and the replica LUN. They should both be exactly the same size. In storage arrays that support metadevices, the storage array will create the new metaLUN with the expanded size; it will inherit the original LUN’s LUN masking.

At the RecoverPoint Management Application:1. Locate and disable the consistency group containing the LUN to

be expanded.

2. Click Replication Set tag. Remove the replication set containing the LUN to be expanded.



3. Click Add Replication Set button. Rescan volumes.

4. Add a new replication which contains the expanded LUN and the expanded replica of the LUN. Both must show the new, larger size.

5. Verify that the consistency group’s journals are added and active: In the RecoverPoint Management Application, in the Navigation pane, select the consistency group. In the Components pane, click the Journals tab and verify that both the production journals and the replica journals are listed.

6. In the Navigation pane, right-click on the configuration group, and select Enable group.

7. In the Navigation pane, click on Splitters. In the Components pane, double-click on the individual splitters, and verify that the relevant splitter is attached to the new expanded LUNs.

On the production ESX server:1. From the Storage menu, select Rescan.

2. Select the extended datastore and right-click. Select Properties.

3. Select Increase.

The Extent Device screen will appear.

4. On the Extent Device screen, select the LUN with Expandable = Yes.

This LUN has free space that can be used by VMware to increase the capacity of the VMFS.

5. Click Next. Verify that the free space is listed on the Current Disk Layout screen.

6. Click Next. In the Volume Properties screen, specify the amount of free space to allocate to the expanded LUN.

7. Click Next. Complete the process by verifying that the LUN now shows the new, enlarged size.

Thin provisioning of virtual disks with RecoverPoint

Thinly provisioned disks are part of the physical LUN. When a thinly provisioned disk is converted or migrated to a thickly provisioned disk, intense write activity is generated. These writes will appear as increased replication traffic through the RecoverPoint appliances.


44


To convert a thinly provisioned disk to a thickly provisioned one, in the Datastore Browser, select the directory containing the thin disk, select the thin disk’s VMDK, right-click, and choose Inflate.

Recovering from disaster

RecoverPoint replicates LUNs, both data LUNs and datastores that contain virtual machines. In case of a disaster, both the application data (in the data LUNs) and the hosts to access that data (in the datastores) are available for disaster recovery.

Recovering fromdisaster usingRecoverPoint

Even if virtual machines from the production site are not available, RecoverPoint can successfully be used for complete disaster recovery from the replicated LUNs at the replica site. Use the following procedure to use RecoverPoint to recover virtual machines from disaster:

1. If the disaster site and the production site are on the same network segment, shut down the source virtual machine to avoid contention when bringing up the virtual machine at the disaster recovery site.

2. Document the following source virtual machine settings:

a. Virtual Device Machine settings, including the VMware SCSI address.

b. RDM Compatibility mode (physical)

c. RDM drive mapping (Window drive letter or UNIX/Linux mount point)

3. In the RecoverPoint Management Application, enable Image Access for the replicated virtual machine.

4. In the VMware vCenter Server, import the virtual machine from the replicated datastore. Use the following procedure:

a. Right-click the VMware LUN and enable Datastore Browsing.

b. Locate the virtual machine’s configuration file (.vmx extension).

c. Import the replicated virtual machine by right-clicking on its configuration file and select Add to Inventory.

d. Select the name of the imported virtual machine, right-click, and choose Edit Settings.



e. Locate the RDM volume by the Virtual Node Disk you recorded in step 2 on page 44. The Provisioned Size field should = 0.

f. Select the RDM volume and choose Remove.

g. Click Add and select the same RDM volume again.

h. Verify that you have a valid RDM volume that corresponds to the volume recorded in step 2 on page 44.

i. Complete the import wizard process by entering the VM name and Resource Pool.

Recovering fromdisaster using Storage

VMotion

Refer to VMware Storage VMotion documentation for instructions on using VMotion to automatically migrate virtual machines that are protected by VMware High-Availability Configuration.

RecoverPoint with VMware Site Recovery Manager

RecoverPoint supports VMware Site Recovery Manager to streamline the flow of operations required to failover multiple virtual machines. Site Recovery Manager allows you to test and failover consistency groups more easily and efficiently. It also allows you to manage all virtual machines from a single VMware user interface.

Site Recovery Manager can be used only with CRR, not with CDP or CLR. Site Recovery Manager supports only disaster recovery from the latest image, not any-point-in-time recovery. It also cannot be used with host-based splitters.

For more details, refer to EMC RecoverPoint Adapter for VMware Site Recovery Manager Release Notes.


46

Limitations, known issues, and fixed issues

Limitations, known issues, and fixed issuesTable 9 on page 46 shows the limitations and known issues for replicating VMware with RecoverPoint.

Table 9 Limitations and known issues

Issue DescriptionFixed in version

SAN monitoring software (Akorri, sysload, HP Insight Manager, System Insight Manager) may cause reservation conflicts.

Refer to Primus articles emc204967,emc232079, emc231383 and VMWARE KB #1004771. For instance, SCSI reservation conflicts are caused by the Fibre Channel agent (cmafcad) and the cmahost agent of HP Insight Manager for ESX.

After disabling image access, the accessed image still appears as a datastore in the ESX Storage Management Console.

This is normal behavior of ESX in the RecoverPoint environment. The datastore will disappear from the ESX Storage Management Console the next time that the ESX is rebooted.

VMware times out when rescanning HBAs in system using RecoverPoint 3.0 and intelligent fabric switches

RecoverPoint blocks LUNs to the ESX server, so that the ESX server can see the LUNs but not take over the reservation. The system will retry repeatedly to take over reservation. When this fails, RecoverPoint may time out. The ESX server log will show the error message “Failing I/O due to too many reservation conflicts.” This issue is documented in Primus case emc183371. A workaround exists, but it requires the intervention EMC technical support. If you need help with this issue, contact EMC Customer Support and report the Primus case ID for this issue.

3.0 SP1

ESX fails I/O due to multiple reservation conflicts in system using RecoverPoint 3.0 or 3.0 SP1 and CLARiiON splitter.

If communication between a CLARiiON-based splitter and RecoverPoint appliances fails for any reason, it may cause a SCSI timeout in the ESX server. The following message will appear in the vmkernel log in the RPA log collection: “Failing I/O due to too many reservation conflicts.” In addition, the following SCSI warning may appear: “Failing I/O due to too many reservation conflicts.” This issue is documented in Primus case emc189737. A workaround exists, but it requires the intervention EMC technical support. If you need help with this issue, contact EMC Customer Support and report the Primus case ID for this issue.

3.1


Limitations, known issues, and fixed issues

Splitter write may have failed (while group was transferring data) error message

A “pending” incomplete write means that when the host sends a write to the storage, the write is split and acknowledged by RecoverPoint, but the storage either fails to acknowledge the I/O within a timeout period (10 seconds) or sends a response other than “OK” to the I/O. After this occurs, a timer is initiated allowing the host to resend the writes without the need for corrective action from the RPA (since the RPA still holds this write). If the host re-issues this write and receives a successful acknowledgement from the storage that the I/O was completed, then no corrective action is needed. If the timer runs out before the I/O is acknowledged successfully by the storage, then RecoverPoint takes corrective action to ensure data consistency, since the RPA has a write that was not committed to the source storage - the “incomplete write” event is a notification of this occurring. In small amounts, these messages are simply indicators that this occurred and the system was able to adjust to this occurrence. In larger amounts, this may indicate that the RPA splitter timeout needs to be adjusted for large-scale VMware ESX deployment to avoid incomplete writes.

Refer to Primus case emc 204967

Table 9 Limitations and known issues

Issue DescriptionFixed in version


48

Additional support information

Additional support informationFor additional support information, refer to the EMC Support Matrix.


Additional documentation

Additional documentationEMC RecoverPoint Administrator’s Guide

EMC RecoverPoint Installation Guide

EMC RecoverPoint Adapter for VMware Site Recovery Manager Release Notes

VMware ESX Server SAN Configuration Guide.

Copyright © 2011 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.All other trademarks used herein are the property of their respective owners.


Date post:	22-Jul-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

Replicating VMware with RecoverPoint · EMC® RecoverPoint fully supports data replication and...

Documents