VMware vCenter Site Recovery Manager - 4.1 Administrator’s Guide
Site Recovery Manager Administration
Guide
vCenter Site Recovery Manager 4.1
This document supports the version of each product listed and
supports all subsequent versions until the document is replaced
by a new edition. To check for more recent editions of this
document, see http://www.vmware.com/support/pubs.
EN-000357-00
Site Recovery Manager Administration Guide
You can find the most up-to-date technical documentation on the VMware Web site at:
http://www.vmware.com/support/
The VMware Web site also provides the latest product updates.
If you have comments about this documentation, submit your feedback to:
docfeedback@vmware.com
Copyright © 2008–2010 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and
intellectual property laws. VMware products are covered by one or more patents listed at
http://www.vmware.com/go/patents.
VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks
and names mentioned herein may be trademarks of their respective companies.
VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com
2 VMware, Inc.
Contents
About This Book 5
Administering VMware vCenter Site Recovery Manager 7
1
Protected Sites and Recovery Sites
Array-Based Replication 8
About Protection Groups and Recovery Plans 10
Understanding Recovery and Test Recovery
Operational Limits of Site Recovery Manager 12
About Failback 12
SRM and vCenter 13
About the Site Recovery Manager Database 14
SRM Licensing 14
SRM Authentication 15
How SRM Uses Network Ports 16
Site Recovery Manager Roles and Permissions 17
7
11
Installing and Updating Site Recovery Manager 19
2
Configuring the SRM Database 19
Microsoft SQL Server Configuration 20
Oracle Server Configuration 20
DB2 Server Configuration 21
Install the SRM Server 21
Install the Storage Replication Adapters 23
Update the SRM Server 24
Install the SRM Client Plug-In 25
Revert to a Previous Release 25
Repair a Site Recovery Manager Server Installation 26
Configuring the Protected and Recovery Sites 29
3
Create a Site Pair 29
Disconnect From a Protected or Recovery Site 30
Install the SRM License Key 30
Configure Array Managers 31
Configure Recovery Site Array Managers When the Protected Site Is Inaccessible 32
Rescan Arrays to Detect Configuration Changes 33
Configure Inventory Mappings 33
Apply Inventory Mappings to All Members of a Protection Group 34
Configure Resource Mappings for a Virtual Machine 35
Create Protection Groups 35
Edit a Protection Group 36
Adding and Removing Members of a Protection Group 37
VMware, Inc. 3
Site Recovery Manager Administration Guide
Limitations on Recovery of Snapshots and Linked Clones 37
Create a Recovery Plan 37
Edit a Recovery Plan 38
Remove a Recovery Plan
39
Test Recovery, Recovery, and Failback 41
4
Test a Recovery Plan 41
Pause, Resume, or Cancel a Test 42
Run a Recovery Plan 42
Configuring and Executing Failback 43
Review and Execute Post-Failover Cleanup Tasks 44
Reconfigure Replication 44
Reconfigure SRM to Enable Failback to the Protected Site 45
Restore the Original Configuration 45
Customizing Site Recovery Manager 47
5
Assign Roles and Permissions 47
Customizing a Recovery Plan 48
Recovery Plan Steps 48
Customize Recovery Plan Steps 51
Customize the Recovery of an Individual Virtual Machine 53
Report IP Address Mappings for a Protection Group 54
Customize IP Properties for a Group of Virtual Machines 54
Configure Protection for a Virtual Machine or Template 57
Repair Placeholder Virtual Machines After a Failed Test Recovery 58
Configure SRM Alarms 59
Working with Advanced Settings 59
Guest Customization Settings 60
Change Recovery Site Settings 60
Change SAN Provider Settings 60
Change Local Site Settings 61
Change Remote Site Settings 62
Avoiding Replication of Paging Files and Other Transient Data 62
Specify a Nonreplicated Datastore for Swapfiles 62
Create a Nonreplicated Virtual Disk for Paging File Storage 63
Troubleshooting SRM 65
6
No Replicated Datastores Listed 65
Inconsistent Mount Points Warning When Configuring NFS Arrays 66
Array Script Files Not Found 66
Expected Virtual Machine File Path Cannot Be Found 66
Recovery Plan Time-Out During the Change Network Settings Step 67
Collecting SRM Log Files 68
Collect SRM Server Log Files 68
Collect an SRM Client Log Bundle 68
Index 69
4 VMware, Inc.
About This Book
VMware® vCenter Site Recovery Manager (SRM) is an extension to VMware vCenter that enables integration
with array-based replication, discovery and management of replicated datastores, and automated migration
of inventory from one vCenter to another.
SRM servers
that, as virtual machines at one site (the protected site) are shut down, virtual machines at the other site (the
recovery site) start up and, using the data replicated from the protected site, assume responsibility for
providing the same services. Migration of protected inventory and services from one site to the other is
controlled by a recovery plan that specifies the order in which virtual machines are shut down and started up,
the compute resources they are allocated, and the networks they can access. SRM enables you to test a recovery
plan, using a temporary copy of the replicated data, in a way that does not disrupt ongoing operations at either
site.
coordinate the operations of the replicated storage arrays and vCenter servers at the two sites so
Intended Audience
This book is intended for Site Recovery Manager administrators who are familiar with vSphere and its
replicated datastores, and who want to configure protection for vSphere inventory. It may also be appropriate
for other users who need to add virtual machines to protected inventory or verify that existing inventory is
properly configured for use with SRM.
VMware Technical Publications Glossary
VMware Technical Publications provides a glossary of terms that might be unfamiliar to you. For definitions
of terms as they are used in VMware technical documentation, go to
http://www.vmware.com/support/pubs.
Document Feedback
VMware welcomes your suggestions for improving our documentation. If you have comments, send your
feedback to docfeedback@vmware.com.
VMware, Inc. 5
Site Recovery Manager Administration Guide
Technical Support and Education Resources
following
The
other books, go to http://www.vmware.com/support/pubs.
Online and Telephone
Support
Support Offerings
VMware Professional
Services
technical
support resources are available to you. To access the current version of this book and
To use online support to submit technical support requests, view your product
and contract information, and register your products, go to
http://www.vmware.com/support.
Customers with appropriate support contracts should use telephone support
for the fastest response on priority 1 issues. Go to
http://www.vmware.com/support/phone_support.html.
To find out how VMware support offerings can help meet your business needs,
go to http://www.vmware.com/support/services.
VMware Education Services courses offer extensive hands-on labs, case study
examples, and course materials designed to be used as on-the-job reference
tools. Courses are
pilot programs and implementation best practices, VMware Consulting
Services provides offerings to help you assess, plan, build, and manage your
virtual environment. To access information about education classes,
certification programs, and consulting services, go to
http://www.vmware.com/services.
available onsite, in the classroom, and live online. For onsite
6 VMware, Inc.
Administering VMware vCenter Site
Recovery Manager 1
VMware vCenter Site Recovery
plan, test, and execute a scheduled migration or emergency failover of vCenter inventory from one site to
another.
This chapter includes the following topics:
n
“Protected Sites and Recovery Sites,” on page 7
n
“SRM and vCenter,” on page 13
Manager is a business continuity and disaster recovery solution that helps you
Protected Sites and Recovery Sites
In a typical SRM installation, the protected site provides business-critical datacenter services. The recovery site
is an alternate facility to which these services can be migrated.
The protected site can be any site where vCenter supports a critical business need. The recovery site can be
located thousands of miles away or in the same room. The recovery site is usually located in a facility that is
unlikely to be affected by environmental, infrastructure, or other disturbances that affect the protected site.
SRM has the following requirements for the VMware vSphere® configurations at each site:
n
Each site must have at least one datacenter.
n
The recovery site must support array-based replication with the protected site.
n
The recovery site must have hardware, network, and storage resources that can support the same virtual
machines and workloads as the protected site.
n
At least one virtual machine must be located on a replicated datastore at the protected site. This datastore
must be supported by a storage array that is compatible with SRM.
n
The sites should be connected by a reliable IP network (storage arrays might have additional network
requirements).
n
The recovery site should have access to the same networks (public and private) as the protected site,
although not necessarily the same range of network addresses.
VMware, Inc. 7
Site Recovery Manager Administration Guide
Site Pairing
The protected and recovery sites must be paired before you can use SRM. Site pairing includes three main
steps:
1 Exchange of authentication information between the two sites.
2 Discovery
the recovery site.
3 Discovery of the replicated devices supported by the arrays, and mapping of these devices to datastores
that support virtual machines.
SRM includes a wizard that guides you through the site-pairing process.
Site pairing requires vSphere administrative privileges at both sites. To initiate the site-pairing process, you
must know the username and password of a vSphere administrator at each site.
of the replicated storage arrays that support the protected site, and discovery of peer arrays at
Array-Based Replication
In array-based replication, one or more storage arrays at the protected site replicate data to peer arrays at the
recovery site. Storage replication adapter (SRAs) enable integration of SRM with a wide variety of replicated
arrays.
You can configure array-based replication between ESX hosts whether or not you use SRM. In fact, it is a good
idea to set up this replication before you install and configure SRM, so that you can be certain it is working
correctly before you install SRM and the necessary SRAs.
Storage Replication Adapters
Storage replication adapters are not part of an SRM release. They are developed and supported by your array
vendor. You can download storage replication adapters and their documentation from
http://www.vmware.com/download/srm/. Storage replication adapters downloaded from other sites are not
supported by VMware. You must install an SRA specific to each array that you use with SRM on the SRM
server host.
Replicated Storage Devices, Datastores, and Datastore Groups
When you use array-based replication, each storage array supports a set of replicated devices. On Storage Area
Network (SAN) arrays that use connection protocols such as Fibre Channel and iSCSI, these devices are called
LUNs (logical storage units comprising one or more physical devices). On NFS arrays, they are typically
referred to as volumes. In every pair of replicated storage devices, one device is the replication source and the
other is the replication target. Data written to the source device is replicated to the target device on a schedule
controlled by the arrays' replication software. When you configure SRM to work with an SRA, the protected
site is the replication source and the recovery site is the replication target.
A VMFS datastore provides storage for virtual machine files. By hiding the details of physical storage devices,
datastores simplify the allocation of storage capacity and provide a uniform model for meeting the storage
needs of virtual machines. Because any datastore can span multiple devices, SRM must ensure that all devices
in a datastore are replicated before it can protect the virtual machines that use that datastore. When necessary,
SRM aggregates datastores into datastore groups to accommodate virtual machines that span multiple
datastores. The set of virtual machines that use a replicated datastore or datastore group is called a protection
group. Any datastore that supports a protection group is considered a protected datastore.
About Bidirectional Operation
Any pair of sites can be configured to operate bidirectionally, so that each acts as a recovery site for the other.
To support bidirectional operation, you must have arrays at each site that are configured as replication targets
of the other site. This type of configuration is the only way to provide SRM services for both members of a site
pair.
8 VMware, Inc.
Chapter 1 Administering VMware vCenter Site Recovery Manager
You cannot designate a third site as a recovery site for one that is already paired with another site. If you want
to use SRM
to provide business continuity and disaster recovery services at a recovery site, you must configure
that site as a protected site that uses its own array managers to replicate data to the other member of the site
pair. After site pairing is complete, configuring bidirectional operation requires you to follow the same site
configuration procedures that are required for unidirectional operation, but you must do so for each site in
each capacity. At recovery site that has not been configured for bidirectional operation, items that must be
configured at a protected site remain unconfigured:
n
Array Managers and Inventory Mappings are always listed as Not Configured.
n
Protection Groups are listed as No Groups Created.
How Changes to Virtual Machine Storage Affect Protection
When you edit the properties of a virtual machine to add or change storage devices (such as hard disks or DVD
drives) you can affect the protection of that machine if you connect it to a device that has storage on a datastore
that is not replicated, or that is protected by a different protection group.
n
If the new device is created on a replicated datastore that is not protected (not part of any protection group),
the datastore is added to the virtual machine's protected datastore group and the virtual machine's
protection is unaffected.
n
If the new device is created on a replicated datastore that is protected by a different protection group, the
virtual machine's protection is invalidated. If the new device is created on a nonreplicated datastore, the
virtual machine's protection is invalidated.
If you use Storage VMotion to move a virtual machine to a nonreplicated datastore, or to a replicated datastore
on an array that SRM has not been configured to manage (through an SRA), the virtual machine's protection
is invalidated.
How Site Recovery Manager Computes Datastore Groups
The composition of a datastore group is determined by the set of virtual machines that have files on the
datastores in the group, and by the devices on which those files are stored.
Virtual machine files are located on one or more vSphere datastores. Each datastore consists of one or more
extents. Each extent corresponds to a single partition of a device on a storage array. Array replication is
configured on a per-device basis; most arrays include some devices that are not replicated. SRM must ensure
that all devices containing protected virtual machine files are replicated. During a recovery or test, SRM must
failover all such devices together.
To solve this problem, SRM aggregates datastores into datastore groups. A datastore group consists of the
minimal set of devices required to ensure that if any of a virtual machine's files is stored on a device in the
group, all of the virtual machine's files are stored on devices that are part of the same group. For example, if a
virtual machine has disks on two different datastores, then both datastores must be combined into a datastore
group. Conditions that can cause datastores to be combined into a datastore group include:
n
A virtual machine has files on two different datastores.
n
Two virtual machines share an RDM device on a SAN array.
n
Two datastores span extents corresponding to different partitions of the same device.
n
A single datastore spans two extents corresponding to partitions of two different devices.
n
Multiple devices belong to a consistency group defined on the storage array.
SRM computes datastore groups when you first configure your array managers. After that, the computation
executes every time that a virtual machine is added to or removed from a datastore that is part of a group.
VMware, Inc. 9
Site Recovery Manager Administration Guide
About Protection Groups and Recovery Plans
A protection group
datastore group. A recovery plan specifies how the virtual machines in a protection group are recovered.
When the replicated devices that support a datastore group failover, that operation affects all of the virtual
machines and templates that use the datastores in the group. Because of this, SRM considers all of those virtual
machines and templates members of a single protection group. When you create a protection group, it initially
contains only those members that store all of their files on the selected datastore group. You can add members
to the protection group by creating them on that datastore, or by using Storage VMotion to move their storage
onto it. You can remove a member from a protection group by moving it to another datastore.
is a collection of virtual machines and templates that use the same replicated datastore or
Recovery Plans and Replicated Datastores
A recovery plan is like an automated runbook. It controls every step of the recovery process, including the
order in which virtual machines are powered off or powered on, the network addresses that recovered virtual
machines use, and so on. Recovery plans are flexible and easy to customize.
A recovery plan applies to one or more protection groups. A protection group can be specified in more than
one recovery plan. For example, you could create one recovery plan to handle a planned migration of services
from the protected site to the recovery site, and another to handle an unplanned event such as a power failure
or natural disaster.
A protection group can be recovered by only one recovery plan at a time. If multiple recovery plans that specify
the same protection group are tested or run simultaneously, only one recovery plan will actually be able to
failover the protection group. Other running recovery plans that specify the same protection group report
errors for that protection group and the virtual machines it contains. Other protection groups covered by those
recovery plans are not affected by the errors.
Configuring and Maintaining the Protection of a Virtual Machine
Every virtual machine in a protection group must be configured in such a way that it can be added to vCenter
inventory at the recovery site. At a minimum, each machine needs to be assigned to a resource pool, folder,
and network that exist at the recovery site. An SRM administrator can specify defaults for these assignments.
These defaults, called inventory mappings, are applied when the protection group is created, and can be
reapplied as needed (for example, whenever you add a new virtual machine to the protected datastore). If you
do not specify inventory mappings, you must configure them individually for each member of the protection
group. Virtual machines that are on a protected datastore but improperly configured are not protected.
About Placeholder Virtual Machines and Inventory Mapping
For each virtual machine that you add to a protection group, SRM creates a placeholder at the recovery site.
These placeholders are added to, and can be managed as part of, the protected site's inventory.
When you add a virtual machine or template to a protection group, SRM reserves a place for it in the recovery
site's inventory by creating a subset of virtual machine files at the recovery site and then using that subset as
a placeholder to register the virtual machine with the recovery site vCenter. The presence of these placeholders
in recovery site inventory provides a visual indication to SRM administrators that the virtual machines are
protected, and to vCenter administrators that the virtual machines can be powered on and start consuming
local resources when SRM tests or runs a recovery plan.
No member of a protection group is protected until its placeholder has been created. Placeholders are not
created until valid inventory mappings have been established by either applying the site’s inventory mappings
to all members of a protection group or configuring mappings for individual members. If inventory mappings
have been established for a site, you cannot override them by configuring the protection of individual virtual
10 VMware, Inc.
Chapter 1 Administering VMware vCenter Site Recovery Manager
machines. If you need to override inventory mappings for a few members of a protection group, use the vSphere
Client to connect to the recovery site and edit the network settings of the placeholders or move them to a
different folder or resource pool. If a member of a protection group loses its protection, its placeholder is
removed from the recovery site until the protection has been restored.
Placeholders can be treated like any other members of the recovery site vCenter inventory, although they
cannot be powered
on. When a placeholder is created, its folder, network, and compute resource assignments
are derived from inventory mappings established at the protected site. Its permissions are inherited from the
protected virtual machine that it represents. A recovery site vCenter administrator can modify these
assignments and permissions as necessary. Changes made to the placeholder override settings established by
inventory mapping, and are preserved in the recovery site SRM database.
When a protected virtual machine is recovered by testing or running a recovery plan, its placeholder is
unregistered, and the recovered virtual machine is registered in its place and powered on as directed by the
recovery plan. After a recovery plan test completes, the placeholders are restored as part of the cleanup process.
Understanding Recovery and Test Recovery
A test recovery exercises nearly every aspect of a recovery plan, though several concessions are made to avoid
disrupting ongoing operations. While a test recovery has no lasting effects on either site, a recovery has
significant effects on both sites.
You can (and should) run test recoveries as often as needed. A test recovery does not affect replication or the
ongoing operations of either site (though it might temporarily suspend selected local virtual machines at the
recovery site). You can pause, resume, or cancel a recovery plan test at any time.
A recovery stops replication (after a final synchronization of the source to the target) and makes changes at
both sites that require significant time and effort to reverse. Because of this, the privilege to test a recovery plan
and the privilege to run a recovery plan must be separately assigned. A running recovery plan cannot be paused
or canceled.
Table 1-1 lists the differences between testing and running a recovery plan.
Table 1-1. Differences Between Testing and Running a Recovery Plan
Test a Recovery Plan Run a Recovery Plan
Required privileges Site Recovery Manager > Recovery
Plan > Test
Effect on virtual machines at
protected site
Effect on virtual machines at
recovery site
Effect on replication Temporary snapshots of replicated
Network Recovered virtual machines are
Interruption Can be paused or canceled. Must run to completion.
none Virtual machines are shut down in reverse
Local virtual machines are suspended
if required by the plan. Suspended
virtual machines are restarted after
the test is complete.
storage are created at the recovery site
and the arrays are rescanned to
discover them.
connected to a test network.
Site Recovery Manager > Recovery Plan >
Run
priority order.
Local virtual machines are suspended if
required by the plan.
All replicated datastores are synchronized,
then replication is stopped, and the target
devices at the recovery site are made
writable.
Recovered virtual machines are connected
to a datacenter network.
VMware, Inc. 11
Site Recovery Manager Administration Guide
How SRM Interacts with DPM and DRS During Recovery
Distributed
Power
Management
(DPM) is a VMware facility that manages power consumption by ESX hosts.
Distributed Resource Scheduler (DRS) is a VMware facility that manages the assignment of virtual machines
to ESX hosts. When DPM and DRS are enabled on a recovery site cluster, SRM temporarily disables DPM for
the cluster and ensures that all hosts in it are powered on before recovery begins. After the recovery hosts have
been powered on, SRM relies on DRS to manage the assignment of virtual machines to hosts in the cluster.
After the recovery or test is complete, SRM re-enables DPM for the cluster, but the hosts in it are left in the
running state so that DPM can power them down as needed.
Test Bubble Networks and Datacenter Networks
To facilitate testing, SRM can create a "test bubble" network to which recovered virtual machine are connected
during a test. This network is managed by its own virtual switch, and in most cases recovered virtual machines
can use it without having to change network properties such as IP address, gateway, and so on. A datacenter
network, in contrast, is one that typically supports existing virtual machines at the recovery site. To use it,
recovered virtual machines must conform to its network address availability rules (they must use a network
address that can be served and routed by the network's switch, must be configured to use the correct gateway
and DNS host, and so on). Recovered virtual machines that use DHCP can connect to this network without
additional customization. Others require IP property customization and recovery plan steps that apply it.
Operational Limits of Site Recovery Manager
Each SRM server can support a maximum number of virtual machines, protection groups, and datastore
groups.
Table 1-2 lists the limits for a single SRM server. When you create a protection group, SRM prevents you from
exceeding the limits for protected virtual machines and protection groups. If a configuration created in an
earlier version of SRM exceeds these limits, SRM displays a warning, but allows the configuration to operate.
You should modify these configurations to bring them within the supported limits as soon as possible.
The limits for replicated datastore groups and running recovery plans are suggested and not enforced.
Table 1-2. SRM Protection Limits
Item
Protected virtual machines in total 1000
Protected virtual machines in a single protection group 500
Protection groups 150
Datastore groups 150
Simultaneously running recovery plans 3
Maximum
About Failback
A failback restores the original configuration of the protected and recovery sites after a failover. You can
configure and execute a failback procedure when you are ready to restore services to the protected site.
Failback is a
of the protected and recovery sites after a failover. The specific procedures required depend on the nature of
the preceding failover: a planned failover that leaves the protected site intact requires a different set of failback
steps than an unplanned failover initiated before (or after) an event that compromises the protected site
temporarily or permanently.
catch-all term for a collection of procedures that you can use to restore the original configuration
12 VMware, Inc.
A typical failback has two phases. In the first phase, the protected and recovery sites switch roles, and the
virtual machines are
In the second phase, the relationship of the protected and recovery sites is restored, so that future failovers
migrate the protected virtual machines from the protected site to the recovery site. Alternately, the recovery
site can be promoted to a protected site, and the protected site becomes the recovery site.
Configuring and executing a failback is a time-consuming task that requires downtime at the recovery site and
changes to storage replication. After the failback is complete, restoring the protected site to its original role and
enabling failover to the recovery site requires additional downtime and changes to storage replication.
migrated from the recovery site to the protected site under the control of a recovery plan.
SRM and vCenter
The SRM server operates as an extension to the vCenter server at a site. Because the SRM server depends on
vCenter for a number of services, you must install and configure vCenter at a site before you install SRM.
SRM takes advantage of vCenter services, such as storage management, authentication, authorization, and
guest customization. SRM also uses the standard set of vSphere administrative tools to manage these services.
How Changes to vCenter Inventory Affect SRM
Because SRM protection groups apply to a subset of vCenter inventory, changes to the protected inventory
made by vCenter administrators and users can affect the integrity of SRM protection and recovery.
Chapter 1 Administering VMware vCenter Site Recovery Manager
SRM depends on the availability of certain objects, such as virtual machines, folders, resource pools, and
networks, in the vCenter inventory at the protected and recovery sites. Deletion of resources such as folders
or networks that are referenced by recovery plans can invalidate the plan. Renaming or relocating objects in the
vCenter inventory does not affect SRM, unless it causes resources to become inaccessible during test or
recovery.
SRM can tolerate the following changes at the protected site without disruption:
n
Modifying a protected virtual machine configuration, including adding, modifying, or removing devices.
Changing a virtual machine’s memory size on the protected site is not reflected on the recovery site if the
virtual machine is already in a protection group.
n
Relocating virtual machines.
n
Deleting protected virtual machines.
n
Deleting an object for which an inventory mapping exists.
SRM can tolerate the following changes at the recovery site without disruption:
n
Deleting placeholder virtual machines.
n
Moving placeholder virtual machines to a different folder, resource pool, or network.
n
Deleting an object for which an inventory mapping exists.
SRM and the vCenter Database
If you update the vCenter installation that SRM extends, you must not overwrite the vCenter database during
the update. Overwriting removes information that SRM has stored in that database and invalidates the current
SRM installation.
VMware, Inc. 13
Site Recovery Manager Administration Guide
About the Site Recovery Manager Database
The SRM server requires its own database, which it uses to store recovery plans, inventory information, and
similar data.
The SRM database is a critical part of any SRM installation. The database must be initialized and a database
connection created before you can install SRM. If you are updating SRM to a new release, you can use the
existing database connection, but
to the previous release of SRM.
The SRM database at each site holds information about virtual machine configurations, protection groups, and
recovery plans. SRM cannot use the vCenter database because it has different database schema requirements,
though you can use the vCenter database server to create and support the SRM database. Each SRM site requires
its own instance of the SRM database. The database must exist before SRM can be installed. If the SRM database
at either site becomes corrupted, the SRM servers at both sites shut down.
When you install SRM, you specify the following information about how SRM connects to the database:
you must back up the database first, otherwise, you will not be able to revert
Connection Count
Max Connections
The initial connection pool size. If all connections are in use and a new one is
needed, a connection is created as long as it does not exceed the maximum
number of connections allowed. It is faster for SRM to use a connection from
the pool than to create a new one.
The maximum number of connections to open to the database at one time. If
the database administrator has restricted the number of connections that the
database can have open, this value cannot exceed that number.
SRM Licensing
The SRM server requires a license key to operate. Each SRM server installs with an evaluation license that is
valid for 60 days and supports an unlimited number of protected virtual machines.
SRM uses the vSphere licensing infrastructure to ensure that all protected virtual machines have appropriate
licensing. Valid vSphere licensing includes Standard, Advanced, Enterprise, or Enterprise Plus licenses.
After the evaluation license expires, existing protection groups remain protected and can be recovered, but
you cannot create new protection groups or modify existing ones until you obtain and assign a valid SRM
license key. VMware recommends that you obtain and assign SRM license keys as soon as possible after
installing SRM. You can obtain a license key from your VMware sales representative.
How License Keys Apply to Protected and Recovery Sites
SRM requires a license key that specifies the maximum number of protected virtual machines at a site. Multiple
keys are often needed when protecting large numbers of virtual machines.
n
Install one or more of these keys at the protected site to enable failover.
n
Install keys at both sites to enable bidirectional operation.
If your SRM Servers are connected with linked vCenter Servers, the SRM servers can share the same license
key.
To obtain your license keys, go to the VMware Product Licensing Center
(http://www.vmware.com/support/licensing/index.html).
SRM licensing checks for a valid license whenever you add a virtual machine to or remove a virtual machine
from a protection group. If licenses are not in compliance, vSphere triggers a licensing alarm. VMware
recommends that you configure alerts for triggered licensing events so that licensing administrators are
notified by email.
14 VMware, Inc.
Chapter 1 Administering VMware vCenter Site Recovery Manager
SRM Authentication
All communications between SRM and vCenter servers take place over an SSL connection and are
authenticated by public key certificates or stored credentials.
When you install an SRM server, you must choose either credential-based authentication or certificate-based
authentication. You cannot mix authentication methods. The authentication method you choose when
installing the SRM server is used to authenticate connections between the SRM servers at the protected and
recovery sites, and between SRM and vCenter.
Certificate-Based Authentication
If you have or can acquire a PKCS#12 certificate signed by a trusted authority, use certificate-based
authentication. Public key certificates signed by a trusted authority streamline many SRM operations and
provide the highest
When Using Public Key Certificates,” on page 16.
Credential-Based Authentication
If you are using credential-based authentication, SRM stores a user name and password that you specify during
installation, and then uses those credentials when connecting to vCenter or another SRM server. SRM also
creates a special-purpose certificate for its own use. This certificate includes additional information that you
supply during installation. That information, an Organization name and Organization Unit name, must be
identical for both members of an SRM server pair.
level of security. Certificates used by SRM have special requirements. See “Requirements
NOTE Even though SRM creates and uses this special-purpose certificate when you choose credential-based
authentication, credential-based authentication is not equivalent to certificate-based authentication in either
security or operational simplicity.
Certificate Warnings
If
are
you
certificate warning because the trust relationship asserted by the special-purpose certificates created by SRM
and vCenter cannot be verified by SSL. The warning dialog allows you to specify a disposition for the current
instance of the problem, for all instances of the problem when making connection to a specific host, or for all
instances of the problem for all hosts. To avoid these warnings, use certificate-based authentication and obtain
your certificate from a trusted certificate authority.
using credential-based authentication, attempts by the SRM server to connect to vCenter produce a
VMware, Inc. 15
Site Recovery Manager Administration Guide
Requirements When Using Public Key Certificates
If you have installed SSL certificates issued by a trusted certificate authority (CA) on the vCenter server that
supports SRM, the certificates you create for use by SRM must meet certain specific criteria.
While SRM uses standard PKCS#12 certificate for authentication, it places a few specific requirements on the
contents
of an SRM server pair (the protected site and the recovery site).
n
n
certain
of
field of those certificates. These requirements apply to the certificates used by both members
The certificates must have a Subject Name value constructed from:
n
A Common Name (CN) attribute, whose value must be the same for both members of the pair. A
string such as "SRM" is appropriate here.
n
An Organization (O) attribute, whose value must be the same as the value of this attribute in the
supporting vCenter server's certificate.
n
An Organizational Unit (OU) attribute, whose value must be the same as the value of this attribute
in the supporting vCenter server's certificate.
The certificate used by each member of an SRM server pair must include a Subject Alternative Name
attribute whose value is the fully-qualified domain name of the SRM server host. (This value will be
different for each member of the SRM server pair.) Because this name is subject to a case-sensitive
comparison, it is a good idea to always use lower-case letters when specifying the name during SRM
installation.
n
If you are using an openssl CA, modify the openssl configuration file to include a line like the
following if the SRM server host's fully-qualified domain name is srm1.example.com:
subjectAltName = DNS: srm1.example.com
n
If you are using a Microsoft CA, refer to http://support.microsoft.com/kb/931351 for information on
how to set the Subject Alternative Name.
n
The certificate used by each member of an SRM server pair must include an "extendedKeyUsage" or
"enhancedKeyUsage" attribute whose value is "serverAuth, clientAuth". If you are using an openssl CA,
modify the openssl configuration file to include a line like the following:
extendedKeyUsage = serverAuth, clientAuth
How SRM Uses Network Ports
SRM servers use several network ports to communicate with each other, with client plug-ins, and with
vCenter. If any of these ports are in use by other applications or are blocked on your network, you must
reconfigure SRM to use different ones.
Table 1-3 lists the default network ports the SRM uses for intrasite (between hosts at a single site) and intersite
(between hosts at the protected and recovery sites) communications. You can change these defaults when you
install SRM.
Table 1-3. How SRM Uses Network Ports
Default Port
8095 SOAP SRM server and vCenter server
8096 HTTP vCenter server (for plug-in download)
9007 SOAP API clients
Protocol Endpoints
(intrasite only)
16 VMware, Inc.
Chapter 1 Administering VMware vCenter Site Recovery Manager
Site Recovery Manager Roles and Permissions
SRM uses vCenter roles and permissions but includes additional ones that allow fine-grained control over
SRM-specific tasks and operations.
SRM and vCenter
use the same authorization model. The set of permissions applied to or inherited by an object
determine the operations that are allowed on the object and the list of roles that can perform those operations.
To manage roles and permissions, you must log in to vCenter as an administrator.
NOTE To configure SRM, you must have vCenter permissions and SRM permissions. SRM-specific roles do
not include vCenter privileges. Without vCenter privileges, you do not have adequate permissions to perform
all SRM operations. In addition,vCenter roles do not provide any SRM privileges. Ensure that SRM users have
vCenter and SRM specific roles as appropriate.
For more information about vCenter roles and
permissions, see Managing Users, Groups, Roles, and Permissions
in the vSphere Client Help.
Site Recovery Manager Roles
SRM adds the following roles to the ones already defined on the vCenter Server:
n
Protection Groups Administrator—Set up and modify protection groups.
n
Protection SRM Administrator—Pair the protected and recovery sites, and configure inventory mappings.
n
Protection Virtual Machine Administrator—Set up and modify the protection characteristics of a protected
virtual machine.
n
Recovery Datacenter Administrator—View available datastores and customize recovered virtual
machines.
n
Recovery Host Administrator—Configure virtual machine components during recovery. If the recovery
host is a cluster, this permission must be assigned for the cluster object itself and for every host in the
cluster.
n
Recovery Inventory Administrator—View customization specifications for the recovery site.
n
Recovery Plans Administrator—Reconfigure protected and recovered virtual machines. Also grants the
ability to set up and run recovery.
n
Recovery SRM Administrator—Configure arrays and create protection profiles.
n
Recovery Virtual Machine Administrator—Create virtual at the recovery site machines and add them to
the resource pool. Also grants the ability to reconfigure and customize the recovery virtual machines when
a recovery plan is run.
SRM Administrative Tasks and Required Privileges
Some SRM administrative tasks are performed at the protected site, some at the recovery site, and some at both
sites. Specific privileges are required at each site. To perform all SRM administrative tasks at the protected and
recovery sites, you must be a vSphere administrator or have specific permissions.
You do not need to propagate the permissions to child objects, unless specified.
You must have the following permissions at the protected site:
n
Read-only at the vCenter root.
n
Read-only at the datacenter inventory object.
n
Protection Virtual Machine Administrator role at the virtual machine level (propagate).
VMware, Inc. 17
Site Recovery Manager Administration Guide
n
Protection SRM Administrator role at the SRM site recovery root level (propagate).
n
Protection Groups Administrator role at the SRM protection groups level (propagate).
You must have the following permissions at the recovery site:
n
Recovery Inventory Administrator role at the vCenter root.
n
Recovery Datacenter Administrator role at the datacenter level (propagate).
n
Recovery Host Administrator
role at the host level (If the recovery host is a cluster, this permission must
be assigned for the cluster object itself and for every host in the cluster.)
n
Recovery Virtual Machine Administrator at the resource pool and folder levels (propagate).
n
Recovery SRM Administrator at the SRM root level (propagate).
n
Recovery Plans Administrator at the SRM recovery plans level (propagate).
You can grant selected roles or individuals the minimum set of privileges required to perform specific
operations. You can grant these privileges in addition to the default permissions for a role rather than giving
many users broad administrative powers.
Table 1-4 summarizes the permissions required for common SRM administrative tasks and the sites at which
those permissions must be granted.
Table 1-4. Site Recovery Manager Administrative Tasks and Minimum Required Privileges
Task
Add new user and role Both Permissions > Modify Role
Assign access permission Both Permissions > Modify Permission
Change access permission Both Permissions > Modify Permission
Remove access permission Both Administrator
Connect (pair) sites Both Site Recovery Manager > Protection
Modify advanced settings Protected Site Recovery Manager > Protection
Modify advanced settings Recovery Site Recovery Manager > Recovery
Configure or repair array managers Both Site Recovery Manager > Array
Configure inventory preferences Both Site Recovery Manager > Inventory
Create protection groups Protected Site Recovery Manager > Protection
Create or modify a recovery plan Recovery Site Recovery Manager > Recovery
Edit a recovery plan Recovery Site Recovery Manager > Recovery
Test a recovery plan Recovery Site Recovery Manager > Recovery
Run or remove a recovery plan Recovery Site Recovery Manager > Recovery
Site Minimum Required Privilege
SRM Administrator
SRM Administrator
SRM Administrator
Manager > Configure
Preferences > Create Mapping
Group > Create
Plan > Create
Plan > Modify
Plan > Test
Plan > Run
18 VMware, Inc.
Installing and Updating Site Recovery
Manager 2
You must install an SRM server at the protected site and also at the recovery site. After the SRM servers are
installed, you can
plug-in to configure and manage SRM at each site.
Prerequisites
SRM requires the support of a vCenter server at each site. The SRM installer must be able to connect with this
server during installation. If you cannot install SRM on a dedicated server host, you can install it on the same
host where vCenter Server is installed.
The SRM server host must meet the following hardware requirements:
n
Processor – 2.0GHz or higher Intel or AMD x86 processor
n
Memory – 2GB minimum
n
Disk Storage – 2GB minimum
n
Networking – Gigabit recommended
For up-to-date information about supported platforms and databases, see the Site Recovery Manager
Compatibility Matrixes, at http://www.vmware.com/support/pubs/srm_pubs.html.
download the client plug-in from either server to any vSphere Client. You use the SRM client
This chapter includes the following topics:
n
“Configuring the SRM Database,” on page 19
n
“Install the SRM Server,” on page 21
n
“Install the Storage Replication Adapters,” on page 23
n
“Update the SRM Server,” on page 24
n
“Install the SRM Client Plug-In,” on page 25
n
“Revert to a Previous Release,” on page 25
n
“Repair a Site Recovery Manager Server Installation,” on page 26
Configuring the SRM Database
The SRM server requires its own database to store recovery plans, inventory information, and similar data.
Before installing the SRM server, you must configure and initialize the SRM database.
If you are updating SRM to a new release, you can use the existing database. Back up the database first in case
you need to revert after the upgrade.
VMware, Inc. 19
Site Recovery Manager Administration Guide
The SRM database at each site holds information about virtual machine configurations, protection groups, and
recovery plans. SRM
cannot use the vCenter database because it has different database schema requirements,
though you can use the vCenter database server to create and support the SRM database. Each SRM site requires
its own instance of the SRM database. The database must exist before SRM can be installed. If the SRM database
at either site becomes corrupted, the SRM servers at both sites shut down.
NOTE If you reinitialize the database after you install SRM, you must run the SRM installer in repair mode
and specify a new database connection.
Microsoft SQL Server Configuration
A Microsoft SQL Server configuration must meet specific requirements to support SRM.
Microsoft SQL Server has the following configuration requirements when used as the SRM database:
n
There are three requirements for the database schema:
n
It must be owned by the SRM database user (the database user name you supply when configuring
the SRM database connection).
n
It must have the same name as the SRM database user.
n
It must be the default schema for the SRM database user.
n
The SRM database user must have database administrator privileges.
n
The SRM database user must be granted the following permissions:
n
bulk insert
n
connect
n
create table
n
create view
n
If you are
n
If the SRM server and database server run on different hosts, you must use mixed mode authentication.
n
If SQL Server is installed locally, you might need to disable the Shared Memory network setting on the
using Windows authentication, the SRM server and database server must run on the same host.
database server.
Oracle Server Configuration
An Oracle Server configuration must meet specific requirements to support SRM.
Oracle Server has the following configuration requirements when used as the SRM database:
n
The SRM database user (the database user name you supply when configuring the SRM database
connection) must be granted the following permissions:
n
connect
n
resource
n
create session
n
create view
20 VMware, Inc.
DB2 Server Configuration
A DB2 Server configuration must meet specific requirements to support SRM.
DB2 Server has the following configuration requirements when used as the SRM database:
n
When creating the database instance, specify utf-8 encoding.
n
Because DB2 uses Windows authentication, you must specify the database owner as a domain account.
Install the SRM Server
Chapter 2 Installing and Updating Site Recovery Manager
You must install
an SRM server at the protected site and the recovery site as an extension to the site’s vCenter
Server.
Prerequisites
You must supply the following information during the installation:
n
The hostname or IP address of the site’s vCenter Server. The server must be running and accessible during
SRM installation, and it must be in the same Windows domain as the SRM server host.
n
The user name and password of the vCenter administrator.
n
A user name and password for the SRM database. See “Configuring the SRM Database,” on page 19.
n
If you are using certificate-based authentication, the pathname to an appropriate certificate file. See “SRM
Authentication,” on page 15.
Procedure
1 Log in to the server host on which you are installing SRM.
Log in as a local administrator.
2 Download the SRM installation file to a folder on the host, or open a folder on the network that contains
this file.
3 Double-click the SRM installer icon to begin installation.
If the installer detects an existing installation, verify that you want to update the existing installation, and
then follow the procedure at “Update the SRM Server,” on page 24.
4 Click Next on the Welcome to the installation wizard screen.
5 On the License Agreement page, select I accept the terms in the license agreement and then click Next.
6 On the Destination Folder page, select the folder in which you want to install SRM and click Next.
The default installation folder for a new installation of SRM is C:\Program Files\VMware\VMware vCenter
Site Recovery Manager. If you use a different folder, the pathname cannot be longer than 240 characters
and cannot include non-ASCII characters.
VMware, Inc. 21
Loading...