hp matrix oe 7.1

HP Matrix Operating Environment 7.1Recovery Management User Guide

AbstractThe HP Matrix Operating Environment 7.1 Recovery Management User Guide contains information on installation, configuration,testing, and troubleshooting HP Matrix Operating Environment recovery management (Matrix recovery management).

HP Part Number: 5900-2276Published: September 2012Edition: 4

© Copyright 2012 Hewlett-Packard Development Company, L.P.

Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, CommercialComputer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government undervendor's standard commercial license.

Warranty

The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the expresswarranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shallnot be liable for technical or editorial errors or omissions contained herein.

Acknowledgments

Microsoft®, Windows®, and Windows Server® are U.S. registered trademarks of Microsoft Corporation.

VMware,

VMware Server, GSX Server, ESX Server, and VMotion are trademarks of VMware, Inc.

Adobe and Acrobat are trademarks of Adobe Systems Incorporated.

Revision history

For supported operating systems, see the HP Insight Management 7.1 Support Matrix available at http://www.hp.com/go/matrixoe/docs.

Table 1

Publication dateDocumentation editionSoftware versionDocument part number

September 201247.1.05900–2276

August 201237.1.05900–2276

July 201227.1.05900–2276

June 201217.1.05900–2276

February 201217.0.05900-2035

http://www.hp.com/go/matrixoe/docs

Contents1 Matrix recovery management Overview........................................................52 Installing and configuring Matrix recovery management..................................8

Installation and configuration overview........................................................................................8Installation and configuration prerequisites...................................................................................8Installing and licensing Matrix recovery management....................................................................8

Uninstalling Matrix recovery management...............................................................................9Setting up Networking..............................................................................................................9Setting up Storage..................................................................................................................10

General storage setup notes................................................................................................11HP P6000 storage setup notes.............................................................................................11HP P9000 storage setup notes.............................................................................................12HP 3PAR storage setup notes...............................................................................................12Creating and installing a User Defined storage adapter..........................................................13

Setting up Local Site logical servers...........................................................................................16Setting up Remote Site logical servers........................................................................................16Configuring Matrix recovery management.................................................................................17

Matrix recovery management GUI overview..........................................................................17Matrix recovery management configuration steps...................................................................18Matrix recovery management export and import operations....................................................20

DR protection for IO services....................................................................................................22DR Protection of IO services configuration overview................................................................22Configure IO properties......................................................................................................23Configure OO workflow for optional email notification...........................................................24Network configuration........................................................................................................25

3 Testing and failover operations...................................................................26Testing Recovery Groups..........................................................................................................26Failover operations.................................................................................................................27

Planned failover.................................................................................................................27Unplanned failover............................................................................................................28

Target selection and parallelism during an activation operation....................................................304 Dynamic workload movement with CloudSystem Matrix.................................31

Capabilities and limitations......................................................................................................32Supported platforms...........................................................................................................35

Overview of physical to virtual cross-technology configuration.......................................................35Configuring logical servers for movement between physical and virtual targets...........................35Configuring logical servers for movement between dissimilar physical servers............................38

Configuring and managing portable OS images........................................................................38Portable Images Storage Assistant (PISA)...............................................................................38Portable Images Network Tool (PINT)....................................................................................39

Configuring and managing cross-technology logical servers.........................................................39Portability groups...............................................................................................................39Defining cross-technology logical servers...............................................................................41

Placing a logical server into a portability group................................................................41Storage definition..........................................................................................................43

Moving between technologies.............................................................................................44Target attributes.................................................................................................................45Moving between blade types..............................................................................................46

Managing DR Protected cross-technology logical servers in a Matrix recovery managementconfiguration..........................................................................................................................46

Setting a failover target type preference................................................................................46

Contents 3

5 Issues, limitations, and suggested actions.....................................................48Limitations.............................................................................................................................48

Hyper-V support limitation for bidirectional configuration.........................................................48No automatic synchronization of configuration between sites...................................................48Matrix recovery management job information is not preserved in certain scenarios.....................48

Minor issues..........................................................................................................................48Firefox browser cannot be used for site export operations........................................................48ESX configuration setting required for VMFS datastores of Matrix recovery management managedlogical servers to be visible at Remote Site............................................................................49Activation or deactivation job hangs.....................................................................................49Identical configuration of logical servers between sites............................................................49One RAID Manager instance per HP P9000 Storage Management Server and One RAID Managerinstance per HP P9000 device group...................................................................................50CLX/HP P9000 software must be installed on a separate Windows system................................50One active Matrix recovery management configuration operation at any point in time................50Site delete operation in Matrix recovery management does not remove HP SIM tools..................50

6 Troubleshooting........................................................................................51Configuration troubleshooting..................................................................................................51Configuration error messages...................................................................................................53Warning messages.................................................................................................................56Matrix recovery management Job troubleshooting.......................................................................57Failover error messages...........................................................................................................60Matrix recovery management log files.......................................................................................61DR Protected IO serivces troubleshooting...................................................................................61

DR Protected IO services configuration troubleshooting...........................................................62DR Protected IO services failover troubleshooting...................................................................64

7 Support and other resources .....................................................................65Information to collect before contacting HP.................................................................................65How to contact HP..................................................................................................................65Registering for software technical support and update service.......................................................65

How to use your software technical support and update service...............................................65Warranty information.........................................................................................................66

HP authorized resellers............................................................................................................66Documentation feedback.........................................................................................................66Related information.................................................................................................................66

Matrix recovery management documentation.........................................................................66Glossary....................................................................................................68

4 Contents

1 Matrix recovery management OverviewMatrix recovery management is a component of the HP Matrix Operating Environment that providesdisaster recovery protection for logical servers and for Matrix infrastructure orchestration services.Logical servers and Matrix infrastructure orchestration services (IO services) that are included in aMatrix recovery management configuration are referred to as DR Protected logical servers and IOservices. A DR Protected logical server can run on a physical machine (c-Class blade) or on avirtual machine hosted by a hypervisor. When a DR Protected logical server is running on a c-Classblade equipped with HP Virtual Connect, it is referred to as a VC hosted logical server. When aDR Protected logical server is running on a virtual machine under the control of a hypervisor, it isreferred to as a VM hosted logical server. DR Protected IO services can run on VM hosted logicalservers only.A Matrix recovery management configuration consists of two sites, each managed by the HP MatrixOperating Environment. The site where the Central Management Server (CMS) you are loggedinto is located is referred to as the Local Site, and the other site in the Matrix recovery managementconfiguration is referred to as the Remote Site. Matrix recovery management pairs symmetricallyconfigured logical servers or IO services across the two sites. One logical server or IO service inthe pair is activated at one site, while the other (peer logical server or IO service) is deactivatedat the other site. The boot images of these DR Protected logical servers and IO services, includingapplications code and data, reside on disk array volumes. The source volumes at the site whereone of the logical servers or IO services in the pair is activated are replicated at the other sitewhere its peer logical server or IO service is deactivated. These volumes are part of a StorageReplication Group that uses storage array supported replication. One or more logical servers orIO services can be associated with a single Storage Replication Group – this is referred to as aRecovery Group.In a Matrix recovery management configuration each Recovery Group has a Preferred Site whereyou prefer it to be activated, and a Secondary Site where you prefer it to be deactivated. ARecovery Group can only be activated on one site at any time. A set of Recovery Groups that sharethe same Preferred and Secondary Sites is referred to as a Recovery Group Set—see Figure 1 (page6). Recovery Group Sets can be selected for activation or deactivation at the Local Site.Recovery Group Sets can be failed over from one site to the other site in a Matrix recoverymanagement configuration. For example, if a disaster occurs at the Local Site, the administratorat the Remote site can trigger a failover for all of the Recovery Groups that were activated at theLocal Site by activating them at the Remote site. This prepares the storage associated with thedeactivated DR Protected logical servers and IO services at the Remote site for read-write access,and activates those logical servers and IO services.

5

Figure 1 Recovery Group Sets

Features and benefits of Matrix 7.1 recovery management

• Provides an automated failover mechanism for DR Protected logical servers, DR Protected IOservices, and associated storage.

• Provides a disaster recovery solution for logical servers and IO services managed by the HPMatrix Operating Environment.

NOTE: Supports DR Protection of IO services with virtual server groups only. DR Protectionof IO services associated with physical server groups is not supported at this time.

• Extends the HP Matrix Operating Environment value of a common management interface tothe realm of disaster recovery for logical servers running on physical or virtual machines andfor IO services running on virtual machines.

• Supports hypervisor hosted virtual machines.

• Supports standalone Hyper-V.

• Supports Microsoft Windows Server 2008 with Hyper-V R2 in a clustered configuration withCSV.

• Supports flexible cross-technology logical servers. VC hosted logical servers can fail over tobecome VM hosted logical servers, and VM hosted logical servers can fail over to VC hosts.

• Supports multiple logical servers and IO services in a Recovery Group.

• Supports bidirectional failover of Recovery Group Sets between two sites, allowing bothactivated and deactivated Recovery Groups to exist at the same site.

• Supports HP P6000 Continuous Access Software storage replication in synchronous andasynchronous modes.

• Supports HP P9000 Continuous Access Software storage replication in synchronous,asynchronous, and asynchronous journal modes.

• Supports HP 3PAR synchronous and asynchronous data replication.

• Supports integration with the remote failover features of installed storage replication products,other than HP P6000, HP P9000, or HP 3PAR. These storage replication products are referredto as User Defined storage in Matrix recovery management.

6 Matrix recovery management Overview

• Includes Recovery Group startup order settings that let you determine which Recovery Groupsare recovered first during a site failover.

• Includes a Copy feature that makes it easy to create multiple Storage Replication Groups withthe same configuration parameters.

By reading this HP Matrix Operating Environment 7.1 Recovery Management User Guide, youwill gain a better understanding of Matrix recovery management concepts and configurationtesting. The Matrix recovery management graphical user interface (GUI), online help, and tooltipsprovide task-specific guidance.

7

2 Installing and configuring Matrix recovery managementThis chapter contains sections on Matrix recovery management installation prerequisites, networkingsetup, storage setup, logical server setup, Matrix recovery management configuration, export andimport operations, and DR Protection for IO services.

IMPORTANT: If you intend to create DR Protected IO services, see “DR protection for IO services”(page 22) before starting the Matrix recovery management installation and configuration process.

Installation and configuration overviewThe following Matrix recovery management installation and configuration overview includes linksto information on each step in the process.1. Confirm that all Matrix recovery management installation and configuration prerequisites have

been met—See “Installation and configuration prerequisites” (page 8).2. Install and license Matrix recovery management—See “Installing and licensing Matrix recovery

management” (page 8).3. Confirm that you have a supported networking configuration—See “Setting up Networking”

(page 9).4. Configure storage—See “Setting up Storage” (page 10).5. Configure for DR Protection—See “Setting up Local Site logical servers” (page 16).6. Configure logical servers at the Remote Site—See “ Setting up Remote Site logical servers”

(page 16).7. Configure Matrix recovery management—See “Configuring Matrix recovery management”

(page 17).8. Configure DR Protection for IO services—See “DR protection for IO services” (page 22)

Installation and configuration prerequisitesMatrix recovery management is the HP Matrix Operating Environment component that providesthe recovery management capability. The HP Matrix Operating Environment and dependentsoftware must be installed on the Central Management Server at the Local Site and the RemoteSite before Matrix recovery management can be installed. For more information, see the HP InsightManagement 7.1 Installation and Configuration Guide available at http://www.hp.com/go/matrixoe/docs.Confirm that both the Local Site and the Remote Site meet the support requirements specified forMatrix recovery management in the HP Insight Management 7.1 Support Matrix, including supportedservers, storage, browsers, operating systems, databases, and hypervisors. The HP InsightManagement 7.1 Support Matrix is available at http://www.hp.com/go/matrixoe/docs.

NOTE: It is assumed that networking and storage replication links are present between the LocalSite and the Remote Site.

Installing and licensing Matrix recovery management1. Install the HP Matrix Operating Environment and dependent software on the Central

Management Server (CMS) at the Local Site and the Remote Site.2. Discover the managed infrastructure at each site from HP Systems Insight Manager.3. Apply the license for Matrix recovery management using the Insight managed system setup

wizard.For more information, refer to the HP Matrix Operating Environment 7.1 Getting Started Guideand the HP Insight Managed System Setup Wizard 7.1 Getting Started Guide available at http://www.hp.com/go/matrixoe/docs.

8 Installing and configuring Matrix recovery management






Uninstalling Matrix recovery managementUse the Windows Add/Remove Programs feature as follows:1. Select recovery management, then click Remove.2. Wait until the Matrix recovery management product no longer appears in the list.

Setting up NetworkingIt is assumed that networking links are present between the Local Site and the Remote Site. Youcan use Matrix recovery management in a variety of networking configurations, but it is importantthat you take note of the following Matrix recovery management networking configurationparameters:• In a Matrix recovery management configuration, workloads can be running on DR Protected

logical servers at both sites. A Recovery Group can only be activated (workloads running) onone site at any time, but it can be activated at either site such that workloads associated withdifferent Recovery Groups can be running at both sites simultaneously. For this reason, networkservices such as DNS, DHCP, WINS, and AD must be available locally at both sites. If onesite becomes inoperative due to a disaster, network services continue to be available at theother site based on the native disaster recovery capability in these services. This ensures thatworkloads can be failed over from the failed site to the other site in the Matrix recoverymanagement configuration. Matrix recovery management must not be used to failover networkservices.

NOTE: The Matrix recovery management “startup order” feature is intended to start upcritical applications first, not to ensure that startup dependencies are met between applicationsand infrastructure services such as networking.

• Matrix recovery management does not perform DNS updates or update the IP configurationof recovered logical servers during a failover operation. Your Network Administrator isresponsible for making the necessary modifications to ensure that network services are availableif you configure a logical server to use a different IP or subnet at each site in the Matrix recoverymanagement configuration.

• When running on physical targets (VC hosted) or non VMware ESX virtual targets (VM hosted),Matrix recovery management does not ensure that logical servers use the same MAC addressesat both sites. When running on VMware ESX hosted virtual targets, Matrix recoverymanagement does ensure that logical servers use the same MAC address at both sites. YourNetwork Administrator needs to plan for this in the networking configuration for DR Protectedlogical servers, if you are using DHCP.

NOTE: For MAC address details for cross-technology logical servers (logical servers thatare capable of running on both VC hosts and VM hosts), see Dynamic workload movementwith CloudSystem Matrix.

• When running on HP Virtual Connect hosted physical targets, the Portable Images NetworkTool (PINT) must be used to prepare the server image to execute on targets with differentnetwork interface configurations and MAC addresses. To use PINT, the Local and RemoteSites must be on the same network, and the OS image must be a Linux version that is supportedby Matrix recovery management. PINT ensures that the static network configuration from thesource server is successfully transferred to the destination server network interfaces, despitethe different environment. The executables and README are in the <SMP>/PI/PINT folder,where <SMP> is the folder where HP Insight Control server migration is installed. Copy theexecutable cp011231.exe to the physical server where the image is currently running. Runcp011231.exe to install PINT and start the PINT service.For information on supported Linux versions and HP Insight Control server migration, see theHP Insight Management 7.1 Support Matrix at http://www.hp.com/go/matrixoe/docs.

Setting up Networking 9


For information on PINT, see the Portable Images Network Tool (PINT) Linux readme version1.0.0 available at http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01726723/c01726723.pdf?jumpid=reg_R1002_USEN.

• If the Local Site and corresponding Remote Site managed servers share a common subnet,you must ensure that there is no conflict between MAC addresses assigned by HP VirtualConnect Enterprise Manager (VCEM). For example, if the default address range provided byVCEM is used at both sites, conflict can be avoided by using the VCEM “exclusion ranges”feature. For example, on the Local Site CMS, exclude addresses from 00-21-5A-9B-00-00 to00-21-5A-9B-FF-FF, and on the Remote Site CMS, exclude addresses from 00-21-5A-9C-00-00to 00-21-5A-9C-FF-FF.

• For DR protected logical servers and IO services, ESX port group names and Hyper-V virtualnetwork names must be identical at the Local Site and the Remote Site.

Setting up StorageMatrix recovery management depends on storage array replication to enable failover of logicalservers. It is assumed that storage replication links are present between the Local Site and theRemote Site. HP P6000 Continuous Access Software Disaster Recovery Groups are a good exampleof this concept.To set up Matrix recovery management Storage Replication Groups:1. Boot and data LUNs for VC or VM hosted logical servers that are to be DR Protected must be

replicated using supported storage replication methods, for example, HP P6000 ContinuousAccess, HP P9000 Continuous Access, HP 3PAR, or a User Defined storage replication method.User Defined storage replication is supported when you create and install a storage adapterin your Matrix recovery management configuration for a storage type other than HP P6000,P9000, or HP 3PAR. For example, if you create and install a storage adapter named EMC,the Storage server type drop-down menu for configuring a Storage Management Serverincludes EMC as a storage server type. For more information see “Creating and installing aUser Defined storage adapter” (page 13).• If a DR Protected logical server at the Local Site is VC hosted, the replicated boot and

data LUNs on the array at the Remote Site must be presented to the corresponding recoverylogical server.

• If a DR Protected logical server at the Local Site is VM hosted, the replicated boot anddata LUNs on the array at the Remote Site must be presented to the VM host (for example,ESX) at the Remote Site that is targeted to run the recovery logical server (for example,ESX guest).

NOTE:• Each Recovery Group has a single Storage Replication Group that is used by the logical

servers in that Recovery Group only. All boot and data LUNs used by these logical serversmust be included in the same Storage Replication Group.

• A Storage Replication Group is a set of storage LUNs on a particular disk array that arereplicated with write order preserved. This corresponds to the HP P6000 ContinuousAccess DR Group concept as well as the HP P9000 Continuous Access consistency groupconcept.

2. Create one Storage Replication Group for each set of logical servers that will be included ina Recovery Group.

3. Record the following details about the Storage Replication Group configuration. This informationis required when you configure Matrix recovery management for replicated storage:• Local and Remote Site storage identifiers, for example, an HP P6000 storage array WWN

or an HP P9000 array serial number


http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01726723/c01726723.pdf?jumpid=reg_R1002_USEN

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01726723/c01726723.pdf?jumpid=reg_R1002_USEN

NOTE: In the same way that conflict in the configuration of MAC addresses at the Localand Remote Sites is avoided in “Setting up Networking” (page 9), conflict must also beavoided in the configuration of WWNs, if the WWNs are not private to the respectivesites. The same technique using VCEM exclusion ranges is available for array WWNconfiguration.

• Storage Management Server FQDN names and credentials for the Local and RemoteSites, for example, HP P6000 Command View server name and credentials to access theCommand View server

• Storage Replication Group name given for the boot and data LUNs of the logical serversthat will be part of the same Recovery Group, for example, the HP P6000 DR Groupname

NOTE:

◦ HP P6000, HP P9000, and User Defined Storage Replication Groups must use thesame Storage Replication Group name at the Local Site and the Remote Site.

◦ HP 3PAR remote copy Storage Replication Groups will have different names at theLocal Site and the Remote Site.

• Storage port WWN and LUN for the replicated LUN, in the case of raw LUNs used byDR Protected logical servers

General storage setup notes• For information on storage setup of cross-technology logical servers (logical servers capable

of being VC hosted or VM hosted), see: Dynamic workload movement with CloudSystemMatrix.

• For a list of supported storage, see the HP Insight Management 7.1 Support Matrix at http://www.hp.com/go/matrixoe/docs.

• Hyper-V virtual machines in clustered environments must be stored on cluster shared volumes.

HP P6000 storage setup notes• With HP P6000 Continuous Access Software storage replication, when an asynchronous

replication group is used in a Recovery Group and an unplanned Recovery Group failoveroccurs, a full copy of the new source vDisks is automatically duplicated on the new destinationvDisks when the failed site recovers. If a failure occurs in the middle of this full copy operation,the data on the new destination vDisks could be corrupted. To protect the new destinationvDisks, you must enable the HP P6000 Command View auto-suspend setting to prevent anautomatic full copy operation from occurring. To protect the new destination vDisks, you mustback up the data on them before you manually run a full copy operation.To prevent a full copy of the new source vDisks to the new destination vDisks after the failoverof asynchronous Storage Replication Groups, Matrix recovery management automatically setsthe mode of all asynchronous Replication Groups to synchronous prior to storage failover andthen resets the mode to asynchronous after the storage failover is completed. The storage linkmust be up and both the Local Site and Remote Site arrays must be managed by the sameCommand View server for Matrix recovery management to perform this operation.For the failover of asynchronous Storage Replication Groups to succeed, both the Local Siteand Remote Site arrays must be managed by the same Command View server.Under rare failure conditions, the mode of a Storage Replication Group can be left insynchronous mode requiring a manual intervention to reset the mode to asynchronous.

Setting up Storage 11



For more information, see the following:

◦ HP P6000 Continuous Access Software documentation available at http://h20000.www2.hp.com. Cick Manuals, then go to Storage→Storage Software→StorageReplication Software→HP P6000 Continuous Access Software.

◦ HP P6000 Command View Software documentation available at http://h20000.www2.hp.com. ClickManuals, then go to Storage→Storage Software→StorageDevice Management Software→HP P6000 Command View Software.

• If the password for a Storage Management Server is changed, take the following actions torefresh the Storage Management Server password on the CMS and in the Matrix recoverymanagement configuration:1. Discover the Storage Management Server with the changed password.2. Go to the Matrix recovery management user interface Storage Management Servers tab.3. Select the Storage Management Server that has the changed password, and click on

Edit.4. Select the Refresh SIM Password box and click Save.

HP P9000 storage setup notes• When HP P9000 Continuous Access Software storage replication is used, Matrix recovery

management depends on the HP P9000 Cluster Extension Software command-line interface(CLI) to manage storage replication. The HP P9000 Cluster Extension Software CLI must beinstalled on a standalone Windows system. HP P9000 Cluster Extension Software dependson HP P9000 RAID Manager Software to manage P9000 storage replication. HP P9000RAID Manager Software instances and configuration files must be configured to managevarious device groups that are configured in Matrix recovery management. For moreinformation, see the following:

◦ HP P9000 Cluster Extension Software documentation available at http://h20000.www2.hp.com. ClickManuals, then go to Storage→Storage Software→StorageReplication Software→HP Cluster Extension Software.

◦ HP P9000 RAID Manager Software documentation available at http://h20000.www2.hp.com. ClickManuals, then go to Storage→Storage Software→StorageDevice Management Software→HP P9000 RAID Manager Software.

• If the password for a Storage Management Server is changed, take the following actions torefresh the Storage Management Server password on the CMS and in the Matrix recoverymanagement configuration:1. Discover the Storage Management Server with the changed password.2. Go to the Matrix recovery management user interface Storage Management Servers tab.3. Select the Storage Management Server that has the changed password, and click Edit.4. Select the Refresh SIM Password box and click Save.

HP 3PAR storage setup notes• When HP 3PAR remote copy replication is used, Matrix recovery management depends on

the HP 3PAR Cluster Extension Software command-line interface (CLI) to manage storagereplication. The HP 3PAR Cluster Extension CLI in turn depends on the HP 3PAR InForm


http://h20000.www2.hp.com








Command Line Software. Both must be installed on the Central Management Server whereMatrix recovery management is installed. For more information, see the following:

◦ HP 3PAR Cluster Extension Software documentation available at http://h20000.www2.hp.com. ClickManuals, then go to Storage→Storage Software→StorageReplication Software→HP Cluster Extension Software.

◦ HP 3PAR InForm Command Line Software documentation available at http://h20000.www2.hp.com. ClickManuals, then go to Storage→Storage Software→Storage3PAR Device Management Software→HP 3PAR InForm Software.

• You need an encrypted password file to manage storage replication on an HP 3PAR storagesystem. An encrypted password file can be created by running HP 3PAR InForm CommandLine Software commands. For more information, see the setpassword command in the HP3PAR InForm Command Line Reference. The encrypted password file must be present in theSTORAGE\3PAR\conf directory where Matrix recovery management is installed. The encryptedpassword file replaces the need for a user name, domain name, and password required withother types of storage management servers.

• The encrypted password file for both the Local Site and Remote Site Inserv storage serversmust be available on the CMS at each site, and the name of the password file must be thesame on the CMS at each site.

• If you upgrade the HP 3PAR InForm Command Line Software on the CMS with a softwareversion that is supported by Matrix OE and HP 3PAR Cluster Extension Software, you mustmodify a property in the Matrix recovery management properties file. Change theINFORM_CLI_VERSION property in conf\hp_ir.properties where Matrix recoverymanagement is installed on the CMS. The default value of the property is set to 3.1.1.

NOTE: After you install and configure Matrix recovery management at the Local Site, you mustmanually failover 3PAR remote copy groups to the Remote Site before attempting to configureinstall and configure Matrix recovery management at the Remote Site.For 3PAR periodic (asynchronous) remote copy, the manual failover action will not synchronizethe data in the remote copy group volumes. To prevent data loss, synchronize the remote copygroups before performing stop and failover operations on the remote copy groups.

Creating and installing a User Defined storage adapterMatrix recovery management provides a User Defined storage adapter interface specification toenable one-step Matrix recovery management failover capability for storage types that are supportedby Matrix OE but not yet integrated with Matrix recovery management.OverviewMatrix recovery management can be configured to invoke storage replication managementcommands for nonintegrated storage when various storage configuration or failover operationsare invoked. The User Defined storage adapter specification for nonintegrated storage definescommands to:• Validate Storage Management Server information when Storage Management Servers for

nonintegrated storage are configured using the Matrix recovery management GUI.• Validate Storage Replication Group information when Storage Replication Groups that use

nonintegrated storage are configured using the Matrix recovery management GUI.• Failover Storage Replication Groups when logical servers that use nonintegrated storage are

failed over using the Matrix recovery management Activate operation.






Managing nonintegrated storage with Matrix recovery managementIf your DR Protected logical servers use a nonintegrated storage system that is supported by MatrixOE, and you want Matrix recovery management to automatically invoke storage failover for thenonintegrated storage using the Matrix recovery management Activate operation, you must:1. Implement and thoroughly test the three commands defined in the “User Defined storage

adapter interface specification”, then perform testing at the Local Site and at the Remote Site.2. Create a new subdirectory under the STORAGE directory where Matrix recovery management

is installed. Give the subdirectory a name that identifies the storage type being managed.This name will appear in drop-down menus in the Matrix recovery management GUI. Performthis step at the Local Site and at the Remote Site.

NOTE: The name of the subdirectory must be exactly the same at the Local Site and at theRemote Site.

3. Place your implementation of the User Defined storage adapter commands in the subdirectorycreated for the storage type. Perform this step at the Local Site and at the Remote Site.

4. Define local and remote Storage Management Servers for the nonintegrated storage byselecting the storage type from the drop-down menu in the Storage Management Servers tabin the Matrix recovery management GUI. The storage type in the drop-down menu has thesame name as the subdirectory created in step 2.

5. Using management tools for the nonintegrated storage system, create a Storage ReplicationGroup for the storage used by the logical servers that will be DR Protected.

6. Create a Storage Replication Group for the nonintegrated storage by using the Matrix recoverymanagement GUI. The storage type in the drop-down menu has the same name as thesubdirectory created in step 2.

7. Create a Recovery Group by using the Matrix recovery management GUI, and associate thatRecovery Group with the Storage Replication Group for the nonintegrated storage.

8. Perform a Matrix recovery management Export operation at the Local Site to generate anexportconfig file, then perform an Import operation to import that exportconfig file atthe Remote Site.

User Defined storage adapter interface specificationThe following commands are defined in the User Defined storage adapter interface specification:• validatesms.cmd—Validates a Storage Management Server during configuration

• validatesrg.cmd—Validates a Storage Replication Group during configuration

• failoversrg.cmd—Fails over a Storage Replication Group while Recovery Group activationoccurs

Command-line arguments

• For validatesms.cmd:sms_name=<name of a Storage Management Server>

sms_username=<login name for a Storage Management Server>

• For validatesrg.cmd:sms_name=<name of the Storage Management Server at the Local Site>

sms_username=<login name for the Storage Management Server at theLocal Site>

srg_name=<name of the Storage Replication Group to be validated>

local_storage_id=<unique identifier of the storage system at theLocal Site>


remote_storage_id=<unique identifier of the storage system at theRemote Site>

NOTE: Volumes in the Storage Replication Group (identified by srg_name) are replicatedbetween the local storage system (identified by local_storage_id) and the remote storagesystem (identified by remote_storage_id).

• For failoversrg.cmd:local_sms_name=<name of the Storage Management Server at the LocalSite>

local_sms_username=<user name for the Storage Management Server atthe Local Site>

local_storage_id=<unique identifier of the storage system at theLocal Site>

remote_sms_name=<name of the Storage Management Server at the RemoteSite>

remote_sms_username=<user name for the Storage Management Server atthe Remote Site>

remote_storage_id=<unique identifier of the storage system at theRemote Site>

srg_name=<name of the Storage Replication Group to be failed over>

use_non_current_data=<yes or no>

NOTE: A value of yes requires the Storage Replication Group to be failed over even incases where the data at the destination site may not be current. A value of no requires storagefailover to fail if the data at the destination is not current.

Example invocations of Matrix recovery management User Defined adapter implementation

• During Storage Management Server configuration in Matrix recovery management:<Matrix recovery management installed directory>/STORAGE/EMC/validatesms.cmd sms_name=EMC_SMS1 sms_username=admin

• During Storage Replication Group configuration in Matrix recovery management:<Matrix recovery management installed directory>/STORAGE/EMC/validatesrg.cmd sms_name=EMCSE1 sms_username=admin local_storage_id=emc_id1 remote_storage_id=emc_id2 srg_name=SRG1

• During an Activate operation in Matrix recovery management:<Matrix recovery management installed directory>/STORAGE/EMC/failoversrg.cmd local_sms_name=EMC_SMS1 local_sms_username=admin local_storage_id=emc_id1 remote_sms_name=EMC_SMS2 remote_user_name=admin remote_storage_id=emc_id2 srg_name=SRG1 use_non_current_data=yes

Command return codeCommands must return 0 on successful completion, and a nonzero error code indicates failure.Multiple User Defined storage adaptersMatrix recovery management supports multiple User Defined storage adapters to co-exist in aMatrix recovery management configuration. For each User Defined storage adapter type, you cancreate a new subdirectory and place your implementation of the three commands for that storagetype. For example, to add a storage adapter named EMC, create an EMC subdirectory under


<Matrix recovery management installed directory>/STORAGE and copy all threecommands to the newly created directory:• <Matrix recovery management installed

directory>/STORAGE/EMC/validatesms.cmd

• <Matrix recovery management installeddirectory>/STORAGE/EMC/validatesrg.cmd

• <Matrix recovery management installeddirectory>/STORAGE/EMC/failoversrg.cmd

If your implementation of the storage adapter commands requires passwords to manage storagereplication, the storage adapter command implementation must handle passwords securely. It isyour responsibility to encrypt/decrypt passwords while saving and retrieving them.

Setting up Local Site logical serversThe following conditions must be met before you can configure a logical server for DR protection.1. You must ensure that the logical server is associated with SAN based storage.2. A logical server must have been activated at least once.3. An operating system and applications must be installed on a logical server.Logical servers that meet these conditions appear in the Available LS(s) list in the Local Site Matrixrecovery management configuration GUI, even if they are deactivated after they have been activatedfor the first time.For sites with a large number of logical servers, partitioning logical servers into portability groupscan reduce activation time during failover. HP recommends that the portability group associatedwith logical servers on both the Local Site and the Remote Site be limited to a subset of virtualmachine hosts and virtual connect blades that are capable of hosting these logical servers. Foradditional information on configuring portability groups, see Logical servers→Menus &screens→Manage portability groups in the HP Matrix OE Visualization and Logical Servers onlinehelp.

NOTE: You cannot change the datastore of a VM hosted logical server while it is being managedby Matrix recovery management. To change the datastore, first remove the VM hosted logicalserver from the Matrix recovery management configuration, then use the Logical Servers Activateoperation in the Tools menu of the Visualization tab to change the datastore. After the datastorehas been changed, follow the steps in “Setting up Storage” (page 10), “Setting up Networking”(page 9), and “ Setting up Remote Site logical servers” (page 16) to re-add the logical server tothe Matrix recovery management configuration.

Setting up Remote Site logical servers1. Deactivate and gracefully shut down the logical servers in the Recovery Groups at the Local

Site using Matrix OE visualization.2. Using the appropriate storage management tools (for example, HP P6000 Continuous Access

Software), fail over the storage associated with the Recovery Groups to the Remote Site.3. If there are VM hosted logical servers that will be DR Protected:

a. Rescan storage using VM host management tools, for example, VMware Virtual Centeror Microsoft Hyper-V Management Console, to ensure that the VM host recognizes thefailed over storage.• The replicated disk on the Remote Site Hyper-V host must be configured with the

same drive letter that is assigned to the Local Site disk it is replicated from.In the case of a cluster shared volume, the replicated disk on the Remote Site Hyper-Vhost must be configured with the same volume path that is assigned to the Local Sitedisk it is replicated from.


In the case of a cluster shared volume or shared cluster disks, the replicated disk onthe Remote Site Hyper-V host must be configured with the same cluster resource namethat is assigned to the Local Site disk it is replicated from.

• When creating recovery logical servers, you must specify the datastore name for thelogical server. The datastore name selected must be the same as the datastore namefor the Local Site logical server.

• The names of recovery logical server storage entries must be the same as the namesof the logical server storage entries on the Local Site.

• The names of recovery logical server storage pool entries must be the same as thenames of the logical server storage pool entries on the Local Site.

b. Refresh Virtual Machine resources using the Logical Servers Refresh operation in the Toolsmenu of the Visualization tab in Matrix OE visualization.

4. Use Matrix OE visualization to create recovery logical servers. Specify the replicated LUNsinformation as part of logical server creation. When entering storage information during VMhosted logical server creation, select the datastore name of the datastore where the VM hostedlogical servers were created.

NOTE:• Do not activate the recovery logical servers at this time. During the Matrix recovery management

configuration process, the recovery logical servers will be further configured in the configurationimport process at the Remote Site and there will be an opportunity to activate and deactivatethe recovery logical servers at that time.

• To avoid confusion, HP recommends adopting a best practice of using the same logical servername at the Remote Site as the one that was used for the associated logical server at the LocalSite.

• For information on cross-technology logical servers (logical servers capable of being VC hostedor VM hosted), see Dynamic workload movement with CloudSystem Matrix.

• For sites with a large number of logical servers, partitioning logical servers into portabilitygroups can reduce activation time during failover. HP recommends that the portability groupassociated with logical servers on both the Local Site and the Remote Site be limited to asubset of virtual machine hosts and virtual connect blades that are capable of hosting theselogical servers. For additional information on configuring portability groups, see Logicalservers→Menus & screens→Manage portability groups in the HP Matrix OE Visualization andLogical Servers online help.

Configuring Matrix recovery managementAfter you install Matrix recovery management, you can launch the Matrix recovery managementGUI from the HP Matrix Operating Environment home page by selecting Tools and then selectingMatrix recovery management... from the drop-down menu.Use the Matrix recovery management GUI to configure Matrix recovery management, manage DRProtected logical servers and DR Protected IO services, and test failover capability.

Matrix recovery management GUI overviewThe home screen for the Matrix recovery management user interface includes tabs for configurationand administration tasks—see Figure 2 (page 18).

Configuring Matrix recovery management 17

Figure 2 Matrix recovery management home screen

Matrix recovery management user interface tabs

• HomeInformation on the most recent Matrix recovery management Job is displayed at the top of theMatrix recovery management Home screen, including the Latest Job status:, the Job Id:, theStart Time: (if the job is in progress), or the End Time: (if the job has completed). This is followedby a list of the other Matrix recovery management configuration tabs with Configured or Notconfigured icons to indicate if the configuration tasks for each tab have been completed.

• SitesConfigure Preferred and Secondary Sites. Activate or Deactivate Recovery Groups. Edit ordelete existing Site configurations. Export or import Site configurations.

• Storage Management ServersDefine new Storage Management Servers. View, edit, or delete Storage Management Servers.

• Storage Replication GroupsCreate new Storage Replication Groups. View configuration details for Storage ReplicationGroups. Copy, edit, or delete Storage Replication Groups.

• Recovery GroupsCreate new Recovery Groups. View configuration details for Recovery Groups. Import, editor delete Recovery Groups. Enable or Disable Maintenance Mode on Recovery Groups.

• JobsMonitor Job progress and view Job details. Cancel Jobs in progress. Restart failed Jobs. Viewlogs for Jobs and Sub Jobs. Delete Job information.

The Matrix recovery management online help and tooltips provide answers to questions you mayhave while using the GUI.

Matrix recovery management configuration stepsFigure 3 (page 19) illustrates the six-step Matrix recovery management configuration process. Afterthe Matrix recovery management configuration process is completed at the Local Site, Matrixrecovery management must be configured at the Remote Site. To simplify the Remote Site


configuration process and to help ensure that the two sites have synchronized configurations, youcan export the Matrix recovery management configuration information to a file at the Local Site,move that file to the Remote Site, and then import the Matrix recovery management configurationinformation at the Remote Site.

Figure 3 Configuration steps

NOTE: Make sure all of the steps in “ Setting up Remote Site logical servers” (page 16) havebeen completed, before you attempt the following Matrix recovery management configurationsteps at the Local Site.

1. From the Sites tab, configure the Local Site.2. From the Storage Management Servers tab, configure Storage Management Servers at the

Local Site.3. From the Storage Replication Groups tab, configure Storage Replication Groups at the Local

Site.4. From the Recovery Groups tab, configure Recovery Groups at the Local Site.

NOTE: Matrix recovery management allows failover of the logical servers or the IO servicesin a Recovery Group, independent of the associated Storage Replication Groups. This capabilityis referred to as Storage Decoupling.

5. From the Sites tab, create an export file at the Local Site. For information on export and importparameters, see “Matrix recovery management export and import operations” (page 20).

6. From the Sites tab at the Remote Site, import the Local Site Matrix recovery managementconfiguration. For more information, see “Matrix recovery management export and importoperations” (page 20).

7. Test the recovery logical servers. All imported Recovery Groups are in maintenance mode,allowing activation of the recovery logical servers. For more information, see “Testing RecoveryGroups” (page 26).


8. Deactivate the recovery logical servers and disable Maintenance mode at the Remote Site —for more information see “Testing Recovery Groups” (page 26)

9. Fail back the Storage Replication Groups to the Local Site, then activate the Local Site logicalservers. If there are VM hosted logical servers, use the VMware Virtual Center or the MicrosoftHyper-V Management Console to rescan and refresh virtual machine resources.

Matrix recovery management export and import operationsThis section lists key points about Matrix recovery management export and import behavior.Export

• The Matrix recovery management configuration at the exporting site is included in theexportconfig file generated at the exporting site. The Matrix recovery managementconfiguration export file is named exportconfig by default. The exportconfig file issaved to a default location specified by the browser on the Administrator's system. You havethe option to change the default export configuration file name, for example, if you want tosave multiple Matrix recovery management configuration export files. You can also changethe location that the export configuration file is saved to, before completing the save operation.

• All of the Recovery Groups that you want to export from the Local Site and import to the RemoteSite must be activated at the Local Site. Recovery Groups that are deactivated when the exportoperation is performed at the Local Site are not imported at the Remote Site. If there are noactivated Recovery Groups at the exporting site, the generated exportconfig file cannotbe used at the importing site.

• DR Protected IO services belonging to Recovery Groups are exported, and they can be importedat a Remote Site, however, a replica IO service cannot be exported or imported.

Import

• Only Recovery Groups that are activated at the exporting site are imported.

• The Matrix recovery management import operation automatically creates a replica IO servicefor each IO service belonging to each IO services Recovery Group being imported.

NOTE: A replica IO service from a Remote Site cannot be imported using a Matrix recoverymanagement import operation.

• If the importing site is not configured for Matrix recovery management, Matrix recoverymanagement Site information is not imported.

• If the importing site is configured for Matrix recovery management, the site name and CMSat the importing site must match the site name and CMS in the exportconfig file.

• Storage Management Server information is imported if Storage Management Servers are notconfigured at the importing site. If the importing site already contains Storage ManagementServer information:

◦ The site locality of each Storage Management Server configured at the importing sitemust match the site locality of a Storage Management Server in the exportconfig file.

◦ The type of Storage Management Server must match if the name matches.

◦ For HP P6000, the user name and port number fields must match.

◦ For HP P9000, the user name and RAID instance number must match.

◦ For HP 3PAR storage system, the password file name must match.

If any one of the above items is not matched between the exporting site and the importingsite, the import operation fails.


NOTE: To manage HP 3PAR remote copy, the encrypted password file for both the LocalSite and Remote Site Inserv storage servers must be available on the CMS at each site, andthe name of the password file must be the same on the CMS at each site.

• Storage Replication Group information associated with activated Recovery Groups in theexportconfig file is imported if the importing site has no Storage Replication Groupconfiguration.

• If the importing site already contains Storage Replication Group information:

If the Storage Replication Group is included in another Recovery Group that belongs tothe same Recovery Group Set, the import is allowed.

◦

◦ If the Storage Replication Group is included in another Recovery Group that belongs toa different Recovery Group Set, the import fails. It does not matter whether this RecoveryGroup is activated or deactivated at the importing site.

• All entities referenced by imported Recovery Groups are imported, including Sites, StorageManagement Servers, and Storage Replication Groups. At the end of an import, only theimported Recovery Groups and their associated entities remain. Storage not attached to theactivated Recovery Groups being imported is deleted.

• If a Recovery Group in the exportconfig file has the same name as a Recovery Group atthe importing site, but it belongs to a different Recovery Group Set, the import fails.

• Storage Management Servers and Storage Replication Groups that are not referenced by theimported Recovery Groups are not imported.

• If the Recovery Groups in the exportconfig file already exist at the importing site (RecoveryGroups with the same name are at the importing site), they are deleted and replaced with theimported Recovery Groups. The Storage Replication Groups referenced by Recovery Groupsthat are deleted are also deleted.

Single Recovery Group importIf you add or modify (edit) a Recovery Group at a Matrix recovery management site, there is asingle Recovery Group import feature that saves time by propagating those changes to the othersite without performing a site import operation.For example, if you add or modify (edit) a Recovery Group at the Local Site, you can import thenew or modified Recovery Group to establish its peer Recovery Group at the Remote Site withoutimporting the entire Local Site configuration. The procedure at the Local Site is the same as the siteexport procedure. From the Sites tab at the Local Site you export the Matrix recovery managementconfiguration to an exportconfig file and move that file to the Remote Site. From the RecoveryGroups tab at the Remote Site, click import...→Select import file.... The Import Wizard windowappears allowing you to select a Recovery Group to import from the exportconfig file. See theMatrix recovery management online help for more information on the import procedure for singleRecovery Groups.


NOTE:• Recovery Groups can be imported one at a time only. You must repeat the import...→Select

import file... procedure for each Recovery Group that you import.• If a Recovery Group in the exportconfig file has the same name as a Recovery Group at

the importing site, it is not imported. If you are importing a Recovery Group that already existsin the Matrix recovery management configuration but has been modified, you will need todelete the Recovery Group of the same name at the importing site, before you can import themodified version of that Recovery Group.

• If a Recovery Group in the exportconfig file references a Storage Replication Group thatis being used by another Recovery Group at the importing site, the import fails.

DR protection for IO servicesMatrix infrastructure orchestration (IO) provides rapid provisioning and re-purposing of infrastructureservices from shared resource pools using a self-service portal. IO delivers advanced template-drivendesign, provisioning, and ongoing operations for multi-node, multi-tier infrastructure services.Beginning with Matrix Operating Environment 7.1, IO is integrated with Matrix recoverymanagement to provide DR Protection for IO services. IO services are capable of DR Protection ina Matrix recovery management configuration when they are:• Deployed on virtual machines from an IO template

• Associated with storage that is supported by Matrix recovery management (this includes UserDefined storage—for more information see “Creating and installing a User Defined storageadapter” (page 13))

IO services that are capable of being DR Protected in a Matrix recovery management configurationare referred to as recoverable IO services.Recoverable IO services can be selected from a drop-down menu in Matrix recovery managementwhen you configure IO services Recovery Groups. After IO services Recovery Groups are configured,the IO services they contain will be DR Protected. OO workflows provide system administratorswith automatic email notification when IO operations (for example, create service, delete service,add disk, add server, change lease) are performed on DR Protected IO services that requireconfiguration changes in Matrix recovery management.When Matrix recovery management and IO are installed on the same CMS and recoverable IOservices have been configured, you can create DR Protected IO services Recovery Groups as partof the initial Matrix recovery management configuration process, or you can add DR Protected IOservices Recovery Groups to an existing Matrix recovery management configuration. Theconfiguration procedure is similar.

DR Protection of IO services configuration overview1. Configure IO properties on Local Site and Remote Site CMS. For more information, see

“Configure IO properties” (page 23).2. Configure the OO workflows. For more information, see “Configure OO workflow for optional

email notification” (page 24).3. Configure network for DR Protected IO services. For more information, see “Network

configuration” (page 25).4. Create recoverable IO services templates. For more information, see the HP Matrix Operating

Environment 7.1 Infrastructure Orchestration User Guide available at http://www.hp.com/go/matrixoe/docs.

5. Configure recoverable IO services using IO. For more information, see the HP Matrix OperatingEnvironment 7.1 Infrastructure Orchestration User Guide available at http://www.hp.com/go/matrixoe/docs.






NOTE:• When you use Matrix recovery management to DR protect VMware ESX based IO services

that have been deployed from an IO template using an ICVirt template or a VM templateon the vCenter server at the Local Site, an ICVirt or VM template with same name mustbe available at the Remote Site before you perform a Matrix recovery management importoperation to import the site configuration. If an ICVirt or VM template with the same nameis not available at the Remote Site, DR protected IO services will not be imported.

• When you use Matrix recovery management to DR protect Microsoft Hyper-V based IOservices that have been deployed from an IO template using an ICVirt template on theCMS at the Local Site, an ICVirt template with same name must be available at the RemoteSite before you perform a Matrix recovery management import operation to import thesite configuration. If an ICVirt template with the same name is not available at the RemoteSite, DR protected IO services will not be imported.

6. Add IO services to Matrix recovery management Recovery Groups. Recoverable IO servicescan be selected from a drop-down menu when you configure IO services Recovery Groups.For more information, see the Recovery Groups tab in the Matrix recovery management GUI.

7. Export site configuration at Local Site. For more information, see “Matrix recovery managementexport and import operations” (page 20).

8. Import site configuration at Remote Site. For more information, see “Matrix recoverymanagement export and import operations” (page 20).

Configure IO propertiesTo enable DR Protection for IO services, edit the following hpio.properties anddr.properties files located in C:\Program Files\HP\Matrix infrastructureorchestration\conf directory:hpio.properties

• Enable DR Protection for IO services: enable.dr.protection = true

• Specify the datastore used for provisioning DR Protected IO services:

At the Local Site, specify the volumes to use for DR Protected IO services, for example:volume.dr.list =/vmfs/volumes/ds_1;C:\\ClusterStorage\\Volume3;C:\\ClusterStorage\\Volume4

◦

◦ At the Remote Site, specify the volumes to use for replica IO services, for example:volume.dr.replica.list =/vmfs/volumes/ds_1;C:\\ClusterStorage\\Volume3;C:\\ClusterStorage\\Volume4

NOTE: If one datastore is specified in volume.dr.list, the DR Protected IO services areprovisioned on the datastore specified.If multiple datastores are specified in volume.dr.list, the DR Protected IO services areprovisioned on the datastore in volume.dr.list that is both available for that server pooland also has the most free disk space.If multiple datastores are specified in volume.dr.list, and the IO template specifies oneof the datastores in volume.dr.list, the DR Protected IO services are provisioned on thedatastore specified in the IO template.

• Set the static.ip.replica.list property to reserve static IP addresses for replica IOservices at the Remote Site. For example if the networks configured in IO at the Remote Siteare subnetX and subnetY, one or more IP addresses can be reserved for replica services:static.ip.replica.list =subnetX:192.16.0.10;subnetX:192.16.0.15-192.16.0.20;subnetY:192.16.0.30-192.16.0.40

DR protection for IO services 23

dr.properties

• On the Local Site and Remote Site CMS specify a name identifying the associated site whereIO is running in the dr.properties file, for example: local.site = siteA at the LocalSite, and local.site = siteB at the Remote Site. The name in the dr.properties filecan be different than the site name configured in Matrix recovery management.

• If the service owner domain name and username on the Local Site and Remote Site are notthe same, set the owner.username.<site_a>.<owner_domain_a\\username_a> =owner.username.<site_b>.<owner_domain_b\\username_b> property to specifythe service owner domain and username mapping. For example, if the service owner domainname and username configured for IO on the Local and Remote Sites are domainA\userAand domainB\userB: owner.username.siteA.domainA\\userA =owner.username.siteB.domainB\\userB

• If the domain names on the Local Site and Remote Site are not the same, set theowner.domain.<site_a>.<owner_domain_a> =owner.domain.<site_b>.<owner_domain_b> property to specify the domain namemapping. For example, if the domain name configured for IO on the Local and Remote Sitesis domainA and domainB: owner.domain.siteA.domainA =owner.domain.siteB.domainB

For more information, see the HP Matrix Operating Environment 7.1 Infrastructure OrchestrationUser Guide available at http://www.hp.com/go/matrixoe/docs.

Configure OO workflow for optional email notificationYou have the option to configure OO workflows to provide system administrators with automaticemail notification when IO operations are performed on DR Protected IO services that requireconfiguration changes in Matrix recovery management (for example, create service, delete service,add disk, add server, change lease).IR delivers the IRWorkflow.zip and Send DR Config Email.xsl files to enable automaticemail notification. These two files can be found in the C:\Program Files\HP\InsightRecovery\conf\OO\repo folder on the CMS. The IRWorkflow.zip file is the OO repositoryexport zip file containing the IR workflow and the new OO system property namedHpioDrServiceActionRecipients. The Send DR Config Email.xsl file is used by theIR workflow to build the body of the DR email notification.1. On the Local and Remote Site CMS, import the workflow packaged in the IRWorkflow.zip

file using OO Studio. The workflow is imported as DR Global Service End Actionunder the Library/Hewlett-Packard/Infrastructure orchestration/ServiceActions/DR folder in the OO repository.

2. Copy the Send DR Config Email.xsl file to the C:\Program Files\HP\Matrixinfrastructure orchestration\conf\OO directory on the CMS.

3. Configure OO to set up email notification. For information on setting up email notification seethe HP Matrix Operating Environment 7.1 Infrastructure Orchestration User Guide availableat http://www.hp.com/go/matrixoe/docs.

4. Edit the HpioDrServiceActionRecipientsOO system property to specify email recipientsfor notification of changes to DR Protected services.

5. Modify the following property in the C:\Program Files\HP\Matrix infrastructureorchestration\conf\hpio.properties file to point to the IR workflow:oo.global.service.end.action.path = Service Actions/DR/DR GlobalService End Action

6. Restart Matrix infrastructure orchestration.




Network configurationTo allow the same IP addresses for primary and replica IO services, when the subnet is spannedbetween the Local and Remote Site:

• The Local Site and the Remote Site must define the same static IP range and it must containthe IP range of the primary IO service. At the site with the replica IO service, the IOadministrator must specify a list or a range of IPs (IP exclusion list) in the hpio.propertiesfile to avoid IP address conflicts. These IP addresses will be reserved for replica IO servicesonly and cannot be used by any other IO services.

If the subnet is not spanned between the Local and Remote site, the primary and replica IO servicescan be assigned IP addresses specific to each site.

NOTE: Matrix recovery management does not perform DNS updates or update the IP configurationof logical servers associated with IO services during a failover operation. Your NetworkAdministrator is responsible for making the necessary modifications to ensure that network servicesare available if you configure a logical server to use a different IP address or subnet at each sitein the Matrix recovery management configuration.

DR protection for IO services 25

3 Testing and failover operationsThis chapter describes Recovery Group testing, planned failovers, and unplanned failovers usingthe Matrix recovery management Activate and Deactivate operations.

Testing Recovery GroupsThere are two ways to test Recovery Groups:• Using Maintenance Mode to test individual Recovery Groups.

• Performing a planned failover to test all Recovery Groups. See “Planned failover” (page 27)for more information.

This section focuses on using Maintenance Mode to test individual Recovery Groups.For testing purposes, you can manually place a Recovery Group into Maintenance Mode and thenactivate the deactivated logical servers or inactive services belonging to that Recovery Group usingthe HP Matrix Operating Environment.Maintenance Mode temporarily stops Matrix recovery management from managing DR Protectedlogical servers or DR Protected IO services. One use of Maintenance Mode is to perform a failoverrehearsal. By setting Maintenance Mode on a Recovery Group, all of the logical servers and IOservices in that Recovery Group can be activated or deactivated from the Matrix infrastructureservice user interface. Once you are satisfied with the failover rehearsal, a Recovery Group andits corresponding logical servers or IO services can be brought back under the control of Matrixrecovery management by disabling Maintenance Mode on that Recovery Group.At the Remote Site, the logical servers being managed by Matrix recovery management are knownas recovery logical servers. Normally, a recovery logical server cannot be activated except byinvoking an Activate operation from the Matrix recovery management user interface at the RemoteSite.To use Maintenance Mode to test a Recovery Group:1. At the Local Site, use the Logical Servers Deactivate operation in the Tools menu of the

Visualization tab in the HP Matrix Operating Environment to gracefully shut down the logicalservers in the Recovery Group. For IO services, use the Deactivate Servers IO service operationin the Matrix infrastructure service to shut down the IO services in the Recovery Group.

NOTE: If the Matrix recovery management configuration includes Hyper-V logical serversor IO services, bring the cluster disk resource used for logical server or IO service storageoffline.

2. At the Remote Site, use the appropriate storage management tools, (for example, HP P6000Continuous Access Software), to fail over the storage corresponding to the Recovery Groupto the Remote Site.

3. If there are logical servers or IO services in the Storage Replication Group that will be activatedon VM hosts during the test:a. Rescan storage using VM host management tools, for example, VMware Virtual Center,

to ensure that the VM host recognizes the failed over storage.b. Refresh Virtual Machine resources using the Logical Servers Refresh operation in the Tools

menu of the Visualization tab in Matrix OE visualization.4. Place the Recovery Group into Maintenance Mode at the Remote Site using the Enable

Maintenance Mode button in the Matrix recovery management Recovery Groups tab.For logical servers, use the Logical Servers Activate operation in the Tools menu of theVisualization tab in Matrix OE visualization to activate the logical servers in the RecoveryGroup at the Remote Site. Depending on the type of logical server, the activation may be onVC blades, VM hosts, or both. For IO services, select the Activate Servers service operation

26 Testing and failover operations

in the Matrix infrastructure service to activate the IO services in the Recovery group. Whenthe test is complete, gracefully shut down the operating systems, then deactivate the logicalservers or IO services.


5. At the Remote Site, take the Recovery Group out of Maintenance Mode by using the DisableMaintenance Mode button in the Matrix recovery management Recovery Groups tab.

6. At the Local Site, repeat the storage failover, rescan and refresh (if needed) sequences, thenactivate the logical servers in the Recovery Group using Matrix OE visualization.

When you import a Matrix recovery management configuration at the Remote Site, all RecoveryGroups that are imported have Maintenance Mode enabled by default, so they can be tested.Similarly, a Recovery Group created at the Remote Site has Maintenance Mode enabled by default.After testing is completed for all imported Recovery Groups at the Remote Site, deactivate therecovery logical servers or replica IO services belonging to each Recovery Group , then disableMaintenance Mode on each Recovery Group. Recovery Groups that have Maintenance Modeenabled are not included in an Activate operation. HP recommends that you carefully test RecoveryGroup failover at the Remote Site prior to disabling Maintenance Mode on imported RecoveryGroups.

Failover operationsThis section explains the difference between planned and unplanned failovers, and provides theprocedure to follow in either case.

Planned failoverA planned failover typically involves an expected outage. For example, a planned failover mightbe necessary to perform scheduled maintenance, or to react to a severe weather forecast. Thefollowing section describes the steps necessary to perform a planned failover using Matrix recoverymanagement. A planned failover includes a series of steps performed at both the Local site andthe Remote site.A planned failover includes a series of steps performed first at the site you plan to shut down, andthen at the other site in the Matrix recovery management configuration.At the site you want to shut down:1. Shut down the applications and operating system on each Matrix recovery management DR

Protected logical server and each server associated with DR Protected IO services.2. Click on the Deactivate... button and the Deactivate Recovery Groups at the Local Site window

will appear.For more information about the Recovery Groups contained in a Recovery Group Set, selectthe Recovery Group Set and click View Recovery Group. A window will appear displayingthe following parameters for each Recovery Group in the Recovery Group Set:• Name

• Status

• Type

• Preferred Site

• Secondary Site

• Storage Replication Group Name

Failover operations 27

• Start Order

• Power-Up Delay

3. Click the check-box on the left side of the banner of the Deactivate Recovery Groups at theLocal Site window to select all of the Recovery Group Sets at the Local Site for deactivation.

4. Click Deactivate Recovery Groups to start the deactivation operation. A window will appearasking if it is OK to proceed. Click OK and you will be directed to the Jobs tab where youcan monitor the progress of the deactivation Job.


At the site you want to fail over to:1. Ensure that enough resources are available to run the logical servers that will be activated at

this site.2. Click on the Activate... button and the Activate Recovery Groups at the Local Site window will

appear.For more information about the Recovery Groups contained in a Recovery Group Set, selectthe Recovery Group Set and click View Recovery Group. A window will appear displayingthe following parameters for each Recovery Group in the Recovery Group Set:• Name

• Status

• Type

• Preferred Site

• Secondary Site


• Start Order

• Power-Up Delay

3. Select each Recovery Group Set that you want to activate or click the check-box on the leftside of the banner of the Activate Recovery Groups at the Local Site window to select all ofthe Recovery Group Sets for activation.

4. Click Activate Recovery Groups to start the activation operation. A window will appear askingif it is OK to proceed. Click OK and you will be directed to the Jobs tab where you can monitorthe progress of the activation Job.

NOTE: A successful Activate or Deactivate operation ensures that all of the Recovery Groupswithin a Recovery Group Set are in the same state (activated or deactivated). However, certainoperations (for example, a Recovery Group edit to change site preference) may result in someRecovery Groups within a Recovery Group Set being activated and others being deactivated. Youmust run an Activate or Deactivate operation on a Recovery Group Set to ensure that all of theRecovery Groups in that Recovery Group Set are in the same state ( all activated or all deactivated).

Unplanned failoverAn unplanned failover typically involves the occurrence of a site-wide event, without prior warning.This event may be a regional disaster (earthquake, massive flood), or a local problem (power lossor water main leak in the data center).An unplanned failover includes a series of steps performed at both sites in the Matrix recoverymanagement configuration. The following procedure assumes that the CMS and managed resourcesrunning DR Protected logical servers survived an unplanned local event (for example, a power


loss). If the event is more severe, resulting in the permanent loss of the CMS or managed resources,reconstruction of the site may be necessary.At the site where the site-wide event occurred:1. Ensure that the DR Protected logical servers are no longer running in order to prevent a

split-brain situation. As long as the DR Protected logical servers have stopped running, Matrixrecovery management will prevent them from automatically powering up when power isrestored.Matrix recovery management is able to prevent split-brain from occurring during an unplannedfailover by regulating the auto-power configuration of managed nodes (whether virtual orphysical) that are assigned to DR Protected logical servers so they do not automatically power-upafter an outage. If, for example, a site loses power and site failover is invoked, the site wherethe power outage occurred will not resume running the DR Protected logical servers whenpower is restored. The managed nodes (whether VC blades or virtual machines) assigned toDR Protected logical servers stay powered down (and resources remain unassigned) until anActivate operation is invoked.

At the failover destination (recovery) site:1. Ensure that enough resources are available to run the recovery logical servers.2. From the Matrix recovery management Sites tab, click the Activate... button and the Activate

Recovery Groups at the Local Site window will appear.For more information about the Recovery Groups contained in a Recovery Group Set, selectthe Recovery Group Set and click View Recovery Group. A window will appear displayingthe following parameters for each Recovery Group in the Recovery Group Set including:• Name

• Status

• Type

• Preferred Site

• Secondary Site


• Start Order

• Power-Up Delay

3. Select each Recovery Group Set that you want to activate at the recovery site. The objectiveis for all Recovery Group Sets that were previously activated at the site where the site-wideevent occurred to be activated at the recovery site.

4. Click Activate Recovery Groups to start the activation operation. A window will appear askingif it is OK to proceed. Click OK and you will be directed to the Jobs tab where you can monitorthe progress of the activation Job.

Failover operations 29

NOTE:• If the Matrix recovery management configuration has been changed since the failover occurred

(for example, a new Recovery Group was created), the sites must be brought into sync bymaking appropriate configuration changes. The Matrix recovery management Site configurationexport and import operations can be used for this purpose.

• A successful Activate or Deactivate operation ensures that all of the Recovery Groups withina Recovery Group Set are in the same state (enabled or disabled). However, certain operations(for example, a Recovery Group edit to change site preference) may result in some RecoveryGroups within a Recovery Group Set being enabled and others being disabled. You must runan Activate or Deactivate operation on a Recovery Group Set to ensure that all RecoveryGroups in that Recovery Group Set are in the same state (enabled or disabled).

Target selection and parallelism during an activation operationThe HP Matrix OE logical server management (logical server management) component in the HPMatrix Operating Environment supports the concept of targets that are most suitable for activatinga logical server based on various criteria, for example, an application may need to run on VChosted logical servers only, to meet a performance requirement.DR Protected logical servers that can run on both physical and virtual targets (cross technologylogical servers) will be placed on the target type specified as preferred in the site configuration (Pfor physical or V for virtual), based on availability. If the preferred target type is not available,Matrix recovery management will ignore the target type preference and place cross technologylogical servers on available supported targets.Matrix OE logical server management allows logical servers to be activated in parallel, exploitingparallelism that is available in the managed infrastructure. Matrix recovery management exploitsthe parallelism of activation available from logical server management when performing an Activateoperation, to reduce failover time. Two user accessible settings are available to influence Matrixrecovery management behavior in this area:• Use Recovery Group Start Order values to determine the workloads that will be brought up

first during the failover process.If there are workloads that you want to bring up first during the failover process, the RecoveryGroup Start Order values for the associated Recovery Groups can be set lower than the valuesyou set for workloads that can be brought up later in the failover process. Matrix recoverymanagement ensures that logical servers in a Recovery Group with a lower Recovery GroupStart Order value are activated before logical servers in a Recovery Group with a higherRecovery Group Start Order value are activated.

• Use the Recovery Group Power-Up Delay parameter to ensure that the logical servers in aRecovery Group boot in a staggered fashion during the failover process. The Recovery GroupPower-Up Delay parameter sets a minimum delay between the time when one logical serverin the Recovery Group begins its boot process and the time when the next logical server inthe Recovery Group begins its boot process.


4 Dynamic workload movement with CloudSystem MatrixThis chapter explains how you can configure cross-technology logical servers that can be managedwith Matrix recovery management.The HP Matrix Operating Environment facilitates the fluid movement of workloads between dissimilarservers within a site and across sites. Workloads can be moved between physical servers andvirtual machines and between dissimilar physical servers.A major trend today in IT data center management is the push toward greater efficiency in the useof computing, network, and storage resources in the datacenter by treating them as a shared poolfrom which the resource requirements of various applications, departments, and organizations aremet. Central to this concept of a converged infrastructure is the ability to rapidly and automaticallycreate, move, and remove workloads on demand.In a typical converged infrastructure implementation, a customer may use HP CloudSystem Matrixto run the workloads and the HP Matrix Operating Environment running on a Central ManagementServer (CMS) to create, move, and remove the workloads as needed. The workload, which includesthe operating system (OS) that the user application runs on, can run directly on a blade or it canrun in a virtual machine managed by a hypervisor running on the blade, for example, VMwareESX. The blades may also have different hardware configurations or contain different versions ofhardware and firmware.The capabilities of the HP Matrix Operating Environment discussed in this chapter allow fluidmovement of workloads in this type of heterogeneous environment. These capabilities include:• Tools that allow the workload OS to be prepared as a portable system image that can run in

different server environments.• Fine-grained user control over the set of specific physical servers and virtual machine hosts

that the HP Matrix Operating Environment can run the workload on.The fluid, two-way movement of workloads across dissimilar servers described in this chapter isdifferent from the movement enabled by traditional migration tools. Those tools are oriented towardsenabling a one-way, permanent or semi-permanent migration, between physical and virtual orbetween dissimilar physical servers. The movement typically requires manual intervention and arelatively long period of time to complete.The importance of the ability to fluidly move a workload from a physical server to a virtual machineand back can be understood from the following examples:• You want to move your online workload running on a physical server during daily off-peak

hours to a virtual machine host, to free up the physical server to run a batch workload. Whenthe off-peak period is over, the batch workload is retired and the online workload is movedback to its original execution environment.During the time the online workload is “parked” on a virtual machine host, it has minimalresource requirements; hence it has minimal impact on other workloads that may be runningon that host. Because this pattern repeats daily, the physical to virtual and virtual to physicalmoves must be achieved quickly (in minutes, rather than hours) and automatically.

• You have two data centers located at two different sites. The production workloads run onphysical servers at one site and are configured to be failed over to the other (recovery) site,in case of a disaster. The recovery site is equipped with a set of servers configured as virtualmachine hosts. In this use case, planned or unplanned failovers require physical to virtual andvirtual to physical moves across sites.The configuration of the recovery site as a set of virtual machine hosts may be driven by theneeds of test and development activities that are carried out at that site. Or, it may be drivenby a need to reduce the cost of disaster recovery by running the workloads on virtual machineshosted by a smaller set of servers. Recovery time objectives require that the moves be achievedquickly and automatically, as in the previous example.

31

Capabilities and limitationsUsing the tools and procedures described in this chapter you can:• Configure and manage a logical server that can perform physical to virtual cross-technology

movements within the datacenter.• Configure and manage a DR Protected logical server that can be failed over across data

centers in a cross-technology movement.The following limitations should be noted:• Configuration of a cross-technology logical server requires additional steps (however, no

additional steps are required at the time of the move, within or across sites).• Virtual machines must be configured to emulate either the LSI Logic Parallel or LSI Logic SAS

storage type if using Windows 2008, or the LSI Logic Parallel storage type if using Windows2003.

• Because DR Protection for IO services is supported for VM based IO services only,cross-technology movement of IO services workloads across data centers does not apply.

• VMware ESX guest tools are not automatically installed.

• There is no explicit support NPIV.

• Preparation of the portable system image so it can run on both physical and virtual servers isdone from an OS installed on a physical server. You cannot prepare the portable systemimage from an OS installed on a virtual machine.

• Virtual machines must be configured to use RDM Fibre Channel SAN storage presented to theVM host for boot and data. This is the same storage that a logical server uses when runningon a physical server.

• Each boot and data LUN must use the same LUN number across the physical and virtual targetsfor a logical server as illustrated in Figure 4 (page 33).

32 Dynamic workload movement with CloudSystem Matrix

Figure 4 Same LUN number across physical and virtual targets

• The target WWN values used to present the Logical Unit must be the same across virtual andphysical targets.

NOTE: The recovery logical server that provides DR protection at the Remote Site has itsown set of target WWN/LUN values that differ from the target WWN/LUN values for thelogical server at the Local Site.

• The network name used by an ESX Host must match the network name used in the VirtualConnect Enterprise Manager configuration, as displayed in Figure 5 (page 34) andFigure 6 (page 34).

Capabilities and limitations 33

Figure 5 ESX host network name

Figure 6 Virtual Connect Enterprise Manager network name

• When moving a logical server between physical and virtual servers within a site, the followingserver IDs are not preserved:

◦ Network MAC addresses

◦ Server/Initiator WWNs (On a virtual machine, the storage adapter is a virtual SCSIcontroller.)

◦ Logical Serial Number

◦ Logical UUID

• In a DR configuration, the site that you configure first must have both physical servers andvirtual machine hosts available so a logical server can be configured to run and be tested on


both types of servers. The recovery site can have a physical/virtual combination also, or haveonly virtual machine hosts.

Supported platformsThe procedures for enabling movement between physical and virtual servers described in thischapter apply to physical servers, hypervisors, and workload operating systems supported byMatrix recovery management. For more information, see the HP Insight Management 7.1 SupportMatrix at http://www.hp.com/go/matrixoe/docs.

• For supported hypervisors, see VMware Hypervisor versions specified as supported on managedsystems by the Matrix Operating Environment.

• For supported workload operating systems, see Windows 2008 versions specified as supportedon managed systems by the HP Matrix Operating Environment.

The procedures for enabling movement between physical and virtual servers are not supported onIntegrity managed nodes.The procedures for enabling movement across different physical servers documented in this chapterare supported for managed systems specified as supported by the HP Matrix Operating Environment,with the following restriction:• Matrix recovery management, the component of the HP Matrix Operating Environment that

provides disaster recovery across sites, does not support Integrity managed nodes.A physical server target configured for cross-technology movements must be an HP c-Class bladewith HP Virtual Connect.

Overview of physical to virtual cross-technology configurationThis section provides an outline of the steps involved in configuring cross-technology logical serversfor movement between physical and virtual targets, and for movement between dissimilar physicalservers.

Configuring logical servers for movement between physical and virtual targets1. Prepare a logical server with a portable image.

Start with a logical server configured to run on a physical server, and prepare its system imagefor movement between physical and virtual servers.a. Storage configuration

The Portable Images Storage Assistant (PISA) tool prepares the storage configuration ofthe server image so it can be booted in both physical and virtual environments. PISA ispart of the HP Insight Control server migration product on the HP Insight ManagementDVD. The executable and README are in the <SMP>\PI\PISA folder, where <SMP> isthe directory where Insight Control server migration is installed (the default install directoryis C:\Program Files\HP\Insight Control server migration).i. Copy the executable hppisa.exe (under PI\PISA) to the physical server where

the image is currently running.ii. In the command-line window, type: > hppisa –eFor more information, see “Portable Images Storage Assistant (PISA)” (page 38).

b. Network configurationPortable Images Network Tool (PINT) prepares the image to execute on targets withdifferent network interface configurations and MAC addresses. It ensures that the staticnetwork configuration from the source server is successfully transferred to destinationserver network interfaces despite the differing environment. The executables and READMEare in the folder <SMP>\PI\PINT.

Overview of physical to virtual cross-technology configuration 35


i. Copy the executable cp011231.exe to the physical server where the image iscurrently running.

ii. Run cp011231.exe to install PINT and start the PINT service.For more information, see “Configuring and managing portable OS images” (page 38).

2. Create a portability group that includes all potential physical and VM host targets.This step sets up the portability group that defines the list of potential targets for the logicalserver. The group should include both physical servers and VM hosts as targets. SeeFigure 7 (page 36).

Figure 7 Creating a portability group

For more information, see “Portability groups” (page 39).3. Configure the logical server for activation on both physical and VM host targets.

Modify the logical server configuration as follows:• In the Create logical server: identity screen, set the portability group of the logical server

to the portability group created in Step 2.• In the Create logical server: storage screen, select a VM datastore (this datastore will be

used to store VM configuration information).For more information, see “Defining cross-technology logical servers” (page 41).

• Present the boot/data storage to the VM hosts in the portability group using the sameLUN and WWN values. For more information, see “Storage definition” (page 43).

4. Perform physical to virtual and virtual to physical movements to verify OS configuration.Move the logical server from physical to virtual and back again. After each move, ensure thatthe logical server has booted successfully and the static network configurations have beenapplied as expected to the network interfaces present in the new environment. For moreinformation, see “Moving between technologies” (page 44).


NOTE: When the logical server is first moved to a virtual machine, you may want to addadditional tools to the server, for example, VMware tools. In the HP Matrix OperatingEnvironment, the VM configuration created does not include a virtual CD/DVD drive. You canuse the VM management console to modify the VM configuration to include a virtual CD/DVDdrive.

5. Configure inter-site movement between physical and virtual targets (disaster recovery usecase).In this step, Matrix recovery management capabilities are used to set up inter-site movementbetween physical and virtual targets.a. At the Local Site, create an array replication group containing the LUNs used by the

logical server for boot/data and the LUN containing the VM datastore as illustrated inFigure 8 (page 37). The VM datastore should be used exclusively to store the VMconfiguration of the logical server.

Figure 8 Creating an array replication group

b. At the Local Site, create a Recovery Group containing the logical server. Export the Matrixrecovery management configuration to a file.

c. Deactivate the logical server at the Local Site and failover the array Replication Groupto the Remote Site.

d. Perform VM host rescan and Matrix OE visualization refresh procedures to ensure thatthe VM configuration datastore is accessible to the logical server configuration.

e. Create a portability group at the Local Site. The portability group can contain physicalservers, VMs, or a combination of both.

f. Create the recovery logical server with the same configuration values used at the LocalSite, but adjusted to point to the remote storage LUN/WWN values. Do not activate thelogical server at this time.

g. Using the exported configuration from the Local Site, import the Recovery Group that wascreated at the Local Site to contain the recovery logical server.

h. The Recovery Group is in Maintenance Mode. Activate the logical server on a VM host.If one or more physical servers are available in the portability group, perform virtual tophysical and physical to virtual movements. At each stage, check for successful boot andconfirm correct network configuration, as in step 4. Deactivate the logical server andclear Maintenance Mode. Fail the array replication group back to the Local Site.

i. At the Local Site, perform rescan and refresh procedures, and activate the logical server.

Overview of physical to virtual cross-technology configuration 37

NOTE: The Matrix recovery management Site configuration can be set up to preferentiallyactivate the logical server on a physical server at one site and a VM host at the other site. Formore information, see “Setting a failover target type preference” (page 46).

Configuring logical servers for movement between dissimilar physical serversThe HP Matrix Operating Environment provides the ability to fine tune the list of failover targetsthat are considered most suitable for a DR Protected logical server to be activated on. The abilityto modify target attributes is useful to ensure a successful failover. Target attributes are included inthe data transferred by the Matrix recovery management export/import sequence. An expansionin the target list at the exporting site is reflected at the importing site. For more information, see“Target attributes” (page 45).

Configuring and managing portable OS imagesMobility of server workloads is hampered by the fact that most operating systems are configuredat install time for the specific platform they are installed on. Examples include:• Only the device drivers necessary for the target platform are installed and configured;

attempting to boot the same OS instance on a different server may result in device errors orsystem failures.

• Configuration settings, such as IP addresses or storage identifiers, may be bound to specificdevices whose names may change. For example, the same subnet may be attached to thefirst NIC port on one server, while it is attached to the third NIC port on another.

The HP Matrix Operating Environment supports mechanisms to prepare a server image (logicalserver) so it continues to work when moved to a different physical or virtual server. The followingareas are key to achieving this objective:• Driver installation

• HBA configuration

• NIC configurationThe tools developed for this purpose are as follows:• Portable Images Storage Assistant (PISA)

• Portable Images Network Tool (PINT)

Portable Images Storage Assistant (PISA)When Windows is installed on a SAN LUN attached to a server, it installs a driver that is specificto the HBA controller on that server. If that LUN is subsequently reassigned to a virtual machineon a server running VMware ESX, ESX presents only SCSI direct-attached devices to the virtualmachine. Because Windows is still configured to use the HBA controller for the original server itis unable to start up. PISA enables the appropriate Windows drivers so Windows can start in thevirtual machine.PISA requires that the virtual machine is configured to use the Raw Device Mapping feature in ESXto configure a LUN on a SAN as a disk drive available to the virtual machine. The virtual machinemust also be configured to emulate either the LSI Logic Parallel or LSI Logic SAS storage type withWindows 2008, or the LSI Logic Parallel storage type with Windows 2003.In all versions of Windows 2008, the driver needed to properly operate the virtual version of theLSI controller is installed, but disabled. In Windows 2003, the necessary driver must be installedand enabled.PISA is used to enable LSI support in the Windows image. PISA operates differently on Windows2008 than it does on Windows 2003.


PISA is a simple command-line tool that accepts only a few command-line options. It needs to beexecuted only once after Windows has been installed on a physical server. The changes it makesare persistent and do not need to be repeated or reversed. However, repeatedly running PISA hasno negative impact. PISA can also be used to disable the driver used by the virtual machine.The command-line interface for PISA is described below. The options are mutually exclusive.PISA runs on supported versions of Windows only, and it requires that the user be a member ofthe Administrator user group.Usage: hppisa -h, -?, -help Show this information-e, -enable Enable the LSI driver-d, -disable Disable the LSI driver

After these changes are made, the OS image can be moved back and forth between physicalservers and virtual machines.

Portable Images Network Tool (PINT)PINT is used to resolve networking issues when you move an OS image from one physical serverto another, or from a physical server to a VMware ESX virtual machine.PINT maintains a network configuration file where it gathers information on each network interfaceand its configuration on a server. PINT remains in a suspended state, running only when it receivesone of the following events:• IP configuration change event

PINT considers any changes made while the server is up and running to be intentional changesmade by the user. PINT records the changes and updates its configuration file.

• Stop eventIf the user stops the PINT service PINT receives an event that lets it know to shutdown.

• User command eventIf a user makes any changes through the PINT command-line PINT is notified and actsaccordingly.

NOTE: If a NIC in the destination server requires a different set of drivers than those on the sourceserver, you must install the new drivers before using PINT on the destination server.

For more information on PINT, including installation and operating instructions, see the PortableImages Network Tool (PINT) Windows readme available in the PINT directory on the HP InsightControl DVD at C:\Program Files\HP\Insight Control server migration\PI\PINT.

Configuring and managing cross-technology logical serversThis section explains configuration tasks and management of cross-technology logical servers inan HP Matrix Operating Environment.

Portability groupsWhen you create a logical server, you must specify the portability of the logical server. You dothis by selecting a portability group from within the identity page of the logical server configurationwizard. After a logical server is associated with a particular portability group, it can be moved toany target system (HP Virtual Connect physical server or virtual machine hypervisor) within thatportability group. Logical server resource constraints, such as CPU/memory requirements andnetwork/SAN connectivity, are evaluated solely within the context of the portability group that thelogical server is associated with. Portability groups come in two classes: Default and User Defined.

Configuring and managing cross-technology logical servers 39

The HP Matrix Operating Environment provides default portability groups depending on theresources found within your data center. The Default portability groups include:• ESX—All ESX Hypervisors

• HYPERV—All Hyper-V Hypervisors

• Each Virtual Connect Domain Group—Each VCDG has its own Default portability group.You can also create User Defined portability groups that extend the portability of a logical serverto unlike technologies. For example, moving logical servers between a Virtual Connect physicalserver and a VMware ESX virtual machine host.User Defined portability groups are defined by selecting Modify→Logical Server Portability Groupsin Matrix OE visualization as illustrated in Figure 9 (page 40).

Figure 9 Modifying logical server portability groups

If you have selected one or more targets in Matrix OE visualization, they are presented as potentialtargets. Otherwise, all resources are presented. Figure 10 (page 41) provides an example of theModify Portability Group screen.


Figure 10 Selecting group members and targets

Provide a name and optional description for the portability group. The name will be used fordefining logical servers. The set of Group Types is selected automatically based on the targetsinserted into the portability group. Valid combinations of targets include:• A single Virtual Connect Domain Group (VCDG)

• A set of ESX Hypervisors

• A set of Hyper-V Hypervisors

• A set consisting of a single VCDG plus a set of ESX Hypervisors.

Defining cross-technology logical serversTo define a cross-technology logical server, you must place a logical server into a portability group,and then define the storage for that logical server.

Placing a logical server into a portability groupPlacing a logical server into a portability group is accomplished on the logical server identity page.This can be done during the creation of the logical server or in a subsequent logical servermodification. Select from the Portability Group list as shown in Figure 11 (page 42). This listincludes both the Default portability groups as well as any User Defined portability groups.


Figure 11 Selecting a portability group

To view the portability group for any logical server, click the View movable logical server detailsicon in Matrix OE visualization as illustrated in Figure 12 (page 42).

Figure 12 View movable logical server details icon

The details for this logical server are displayed as illustrated in Figure 13 (page 42).

Figure 13 View logical server details


Logical servers can be made portable through techniques described in “Portability groups” (page39).

NOTE: You must determine whether the provisioned operating system within a logical serverperforms as desired on a variety of platforms. If a logical server has never been active on a platformtype, the HP Matrix Operating Environment shows a warning for each target of that type in theTarget Selection page during moves and activations. You must determine whether the target isvalid.

Storage definitionStorage can be defined through Storage Pool Entries or Storage Entries tied directly to a logicalserver. The storage for cross-technology logical servers must be SAN-based. This approach usesthe normal SAN-boot approach within Virtual Connect and leverages ESX RDM technology whichpresents boot and data LUNs directly to the virtual machine. For examples, see Figure 14 (page43) and Figure 15 (page 43).

Figure 14 Storage Pool Entries

Figure 15 Storage Entries


When defining storage for a portable logical server, you must select SAN Storage Entry. Forflexibility and movement between underlying technology types, storage must be presented to theWWNs tied to the Virtual Connect server profile, and storage must also be presented to any ESXVM hosts that are potential targets for the logical server. Storage Pool Entries must be createdwithin the same portability group associated with the logical servers that will use the storage asillustrated in Figure 16 (page 44).

Figure 16 Managing Storage Pools

Moving between technologiesActivation and movement of cross-technology logical servers is accomplished in the same way aswith standard logical servers. However, the Unlike Move operation is used for cross-technologylogical servers when an Activate or Move operation is about to be performed on a server with adifferent underlying technology from its previous target host. An Unlike Move operation is illustratedin Figure 17 (page 44).

Figure 17 Assigning logical servers to target hosts


Targets for a logical server are selected from that logical server's portability group. The portabilitygroup members are then further filtered based on resource availability, including CPU and memoryresources as well as network and SAN connectivity.

NOTE: Networks in Virtual Connect must be named identically to their corresponding networks(port groups) on ESX Hypervisors. Differences in names prevent the Unlike Move operation fromidentifying networks with similar connectivity.

Target attributesYou can track where a logical server has been successfully activated or moved by using logicalserver target attributes. Target attributes provide a greater number of “most suitable” targets whereyou can activate or move a logical server. To view or modify target attributes on a logical server,select the logical server and then click Modify→Logical Server Target Attributes→Manage asillustrated in Figure 18 (page 45).

Figure 18 Modifying logical server target attributes

Types of targets can be selected and added or removed from the logical server's target attributes.Selecting a server from the list below and clicking Add adds that type of server with associatedresources to the list of “most suitable” targets for the logical server. Selecting a type of server fromthe Target Attributes Available to Remove list and clicking Remove causes the type of server specifiedto no longer be listed as “most suitable.” Figure 19 (page 45) illustrates the screen where you canmanage logical server target attributes.

Figure 19 Managing logical server target attributes


Moving between blade typesFor logical servers with target attributes, the logical server management software can identify morepossible targets when moving or activating a server. As with all cross-technology logical servers,you must ensure that the logical server can function appropriately on various platforms. If a particulartarget is proven to be unsuitable, it is easy to remove that type of target to more accurately describethe logical server's portability.

Managing DR Protected cross-technology logical servers in a Matrixrecovery management configuration

This section explains how to specify failover target type preferences for DR Protected cross-technologylogical servers in a Matrix recovery management configuration.

Setting a failover target type preferenceDuring a site failover, for every logical server that has been configured with disaster protection,Matrix recovery management activates a similarly configured peer logical server at the recoverysite. For this purpose, Matrix recovery management interacts with the Matrix OE logical servermanagement capability to determine a list of appropriate available targets and chooses the mostsuitable target to activate the logical server.For a cross-technology logical server, the appropriate list of available targets may include bothphysical servers and VM hosts. Matrix recovery management includes a Target type preferredsetting in the Sites configuration tab, where you can specify the type of target preferred for eachsite, as illustrated in Figure 20 (page 46).

Figure 20 Matrix recovery management Sites configuration screen


You must specify the target type preferred for all sites on the CMS at each site:• If you specify Virtual as the target type preferred for a site, all cross-technology logical servers

whose Recovery Groups prefer that site are activated on VM hosts during an Activate operationat that site. A physical server is chosen only if no VM hosts are available.

• If you specify Physical as the target type preferred for a site, all cross-technology logical serverswhose Recovery Groups prefer that site are activated on physical servers during an Activateoperation at that site. A VM host is chosen only if no physical servers are available.

By specifying appropriate target preferences for sites, you can set up a configuration where DRProtected cross-technology logical servers run on physical servers at one site and on VM hosts atthe other site. For example, you might choose to have DR Protected cross-technology logical serversrun on physical servers at the preferred site, but run on VM hosts when they failover to the secondarysite.

Managing DR Protected cross-technology logical servers in a Matrix recovery management configuration 47

5 Issues, limitations, and suggested actionsThis chapter lists issues and limitations for this release, categorized as follows:Limitations Limitations of the implemented functions and features of this releaseMajor issues Issues that may significantly affect functionality and usability in this releaseMinor issues Issues that may be noticeable but do not have a significant impact on

functionality or usability

Limitations• Only IO services that include virtual servers and on-premise (not cloud) resources are supported.

• A Recovery Group can contain logical servers only, or IO services only, but not a mix oflogical servers and IO services.

• Replica IO services cannot be flexed (add disk, add server, remove server).

• Replica IO services cannot be imported to create primary services in a Matrix recoverymanagement configuration.

Hyper-V support limitation for bidirectional configurationFor bidirectional failover configurations, the logical servers and IO services configured in RecoveryGroups with the Local Site as the Preferred Site are required to have read-write access to theassociated storage on the Local Site. The logical servers and IO services configured in RecoveryGroups with the Remote Site as the Preferred Site may have read-only access to the associatedstorage on the Local Site. Microsoft requires that all of the storage (cluster shared volume disks orcluster disks) in the clusters where the logical servers will be activated must have read-write access.Suggested actionMicrosoft has provided a hotfix. See the Microsoft Knowledge Base article and download thehotfix at http://support.microsoft.com/?id=2720218.

No automatic synchronization of configuration between sitesThe configuration of Matrix recovery management at two separate sites is not automaticallysynchronized, but Matrix recovery management provides configuration export and import featuresthat simplify this task.Suggested actionsThe Matrix recovery management online help guides you through the export and import operations.

Matrix recovery management job information is not preserved in certain scenariosInformation about previously executed Matrix recovery management Jobs is not preserved whenthe Matrix recovery management configuration is restored using the HP Insight mxsync utility.

Minor issues

Firefox browser cannot be used for site export operationsFirefox browser cannot be used to perform Matrix recovery management site configuration exportoperations, due to a bug in Adobe Flash Player 10.3. For more information, see Bug 2980517on the Adobe web site.Suggested actionsUse Internet Explorer 8 or later to perform Matrix recovery management site configuration exportoperations.

48 Issues, limitations, and suggested actions

http://support.microsoft.com/?id=2720218

ESX configuration setting required for VMFS datastores of Matrix recoverymanagement managed logical servers to be visible at Remote Site

Under the following conditions, Matrix recovery management requires a specific ESX configurationsetting to retain the signature of a VMFS datastore so it will be visible at the Remote Site:• You have asymmetric HP P6000 Continuous Access Software array models at the Local and

Remote Site.• You are using HP P9000 Continuous Access Software storage arrays at the Local and Remote

Site.• You are using HP 3PAR storage systems.Suggested actions

• For ESX3.X hosts, set Lvm.DisallowSnapshotLun to 0 using VirtualCenter→Configuration→Advanced Settings.

• For ESX4.X hosts, to mount the Local Site datastore with an existing signature, see “Mount aVMFS Datastore with an Existing Signature” in the ESX Configuration Guide Update 1, ESX4.0, vCenter Server 4.0 available at http://www.vmware.com/pdf/vsphere4/r40_u1/vsp_40_u1_esx_server_config.pdf. For additional information, see the VMware KnowledgeBase at http://kb.vmware.com/kb/1015986.

Activation or deactivation job hangsIf Matrix OE logical server management is not able to complete a task initiated by a Matrix recoverymanagement Acitvate or Deactivate operation due to underlying stack issues, the Matrix recoverymanagement operation hangs.Suggested actions:Restart the HP Logical Server Automation service from the CMS (Windows AdministrativeTools→Services and Applications→Services) and perform the Matrix recovery management operationagain.

Identical configuration of logical servers between sitesLocal and recovery logical servers must be configured with identical parameters (except for thelogical server name) using Matrix OE visualization. There is a potential for discrepancies, betweenthe Local Site and the Remote Site, in the values of attributes that are not included in the Matrixrecovery management user interface configuration screens. For example:• MAC address—For VC hosted logical servers, the MAC address is assigned from Virtual

Connect or Virtual Connect Enterprise Manager. Because disjointed address ranges must beused at the Local and Remote Sites, the MAC address for a Local Site logical server and it’scorresponding Recovery Site logical server are different.

• HBA WWN—For a VC hosted logical server, the HBA WWN address is assigned by VirtualConnect or Virtual Connect Enterprise Manager. Because disjointed address ranges must beused at the Local and Remote Sites, the HBA WWN address for a Local Site logical serverand it’s corresponding Recovery Site logical server are different.

• BIOS UUID—There is no supported mechanism to preserve the UUID for a VC hosted logicalserver as it moves across sites (as there is when it moves within a site).

• BIOS serial number—There is no supported mechanism to preserve the serial number of a VChosted logical server as it moves across sites (as there is when it moves within a site).

• Array LUNs—On a VC hosted logical server, the Windows or Linux OS must map presentedLUNs to the volumes and file systems configured for the OS. For a VM hosted logical server,the ESX OS on the host must map the presented LUNs to the VMFS used by the VM hostedlogical server. Although the operating systems have built-in mechanisms to do this, HP

Minor issues 49

http://www.vmware.com/pdf/vsphere4/r40_u1/vsp_40_u1_esx_server_config.pdf

http://www.vmware.com/pdf/vsphere4/r40_u1/vsp_40_u1_esx_server_config.pdf

http://kb.vmware.com/kb/1015986

recommends as a best practice that you keep LUN numbers the same for corresponding disksacross sites.

Suggested actionsAssess the impact of these discrepancies on any licensing arrangements in use for the operatingsystem and applications running on DR Protected logical servers.

One RAID Manager instance per HP P9000 Storage Management Server and OneRAID Manager instance per HP P9000 device group

Each HP P9000 Continuous Access Software Storage Management Server configured in Matrixrecovery management has only one HP P9000 RAID Manager Software instance managing theHP P9000 device groups. Each HP P9000 Continuous Access Software Storage Replication Groupconfigured in Matrix recovery management is managed by only one HP P9000 RAID ManagerSoftware instance at each site.Suggested actions:There is no workaround for this issue.

CLX/HP P9000 software must be installed on a separate Windows systemA separate Windows system other than the Central Management Server must be configured withCLX/HP P9000 and compatible HP P9000 RAID Manager Software to manage the various HPP9000 device groups included in a Matrix recovery management configuration.Suggested actionsThere is no workaround for this issue.

One active Matrix recovery management configuration operation at any point intime

If multiple users attempt to run configuration operations in Matrix recovery management, only oneoperation succeeds. All other configuration operations receive an error message indicating thatsome other configuration operation is in progress.Suggested actionsThere is no workaround for this issue.

Site delete operation in Matrix recovery management does not remove HP SIM toolsIf HP P9000 Continuous Access Storage Management Servers are configured and if a site deleteoperation is performed, the HP SIM tools used to manage HP P9000 storage replication on thelocal Storage Management Server are not deleted.Suggested actionsThe mxtool command can be run manually to remove the HP SIM tools. The names of the toolsare Insight Recovery_Failover and Insight Recovery_Group validation. Forexample, if the name of the Storage Management Server is stgmgmtA.cup.hp.com, the namesof the tools are STGMGMTA_CUP_HP_COM_Insight Recovery_Failover andSTGMGMTA_CUP_HP_COM_Insight Recovery_Group validation.

50 Issues, limitations, and suggested actions

6 TroubleshootingThis chapter provides troubleshooting information in the following categories:• “Configuration troubleshooting” (page 51)

• “Configuration error messages” (page 53)

• “Warning messages” (page 56)

• “Matrix recovery management Job troubleshooting” (page 57)

• “Failover error messages” (page 60)

• “Matrix recovery management log files” (page 61)

• “DR Protected IO serivces troubleshooting” (page 61)

Configuration troubleshootingTo troubleshoot Matrix recovery management configuration operations, take note of any errormessages that appear, then review this section for relevant information. You can also view themxdomainmgr log files for additional information.The following troubleshooting issues are addressed in this section:• Unable to add or edit Site information

Possible causes include:

◦ The local or remote CMS name provided is not valid (not a fully qualified domain nameor locatable in the DNS).

◦ The local or remote CMS name does not include a fully qualified name associated withthe local host.

• Unable to add or edit Storage Management Server informationPossible causes include:

◦ The Storage Management Server is not discovered in the HP Matrix Operating Environmentuser interface.

◦ The credentials associated with the Storage Management Server in the HP MatrixOperating Environment user interface do not include the user name provided as part ofa Storage Management Server configuration that has been added or edited.

◦ The HP Matrix Operating Environment user interface is unable to communicate with theStorage Management Server.

Communication Failure with Storage Management Servers may result if Open SSH is not beinginstalled or configured on the target system.

• Unable to add or modify HP P6000 Storage Management ServerPossible causes include:

◦ The CIMOM Server is not running on the Storage Management Server.

◦ The CIMOM server is configured to use a different port than the one specified for addor edit operations.

◦ The specified user does not have valid login credentials on the Storage ManagementServer with appropriate privileges.

Configuration troubleshooting 51

• Unable to add or edit HP P6000 Storage Replication GroupPossible causes include:

◦ Matrix recovery management is unable to obtain Storage Replication Group informationfrom Command View servers to validate the Storage Replication Group informationprovided by the user.

• Unable to add or edit HP P9000 Storage Replication GroupPossible causes include:

◦ The Storage Replication Group is not configured to be managed by the RAID managerinstances.

◦ The RAID manager service is not running on the local Storage Management Server.

◦ The parameters entered for the Storage Replication Group (local array, remote array,serial number, and replication mode) do not match the Storage Replication Groupinformation on the disk array.

• Unable to add or modify HP 3PAR Storage Management ServerPossible causes include:

◦ The password file for the HP 3PAR storage system is missing from the /storage/3par/conf directory where Matrix recovery management is installed.

◦ The password for the HP 3PAR storage system has been changed since the password filewas created.

• Unable to add or edit HP 3PAR Storage Replication GroupPossible causes include:

◦ The Storage Replication Group is not configured to be managed by HP 3PAR remotecopy.

◦ The following information entered for the Storage Replication Group cannot be validatedwith the HP 3PAR storage system configuration:– Volume group name on the local HP 3PAR storage system

– Volume group name on the remote HP 3PAR storage system

– Local array remote copy group name

– Remote array remote copy group name

– Local HP 3PAR storage system serial number

– Remote HP 3PAR storage system serial number

– Replication mode

• Matrix recovery management logical server configuration is inconsistent with Matrix OElogical server management logical server configurationPossible causes include:

◦ The HP Logical Server Automation service was not running when Recovery Groups wereconfigured in Matrix recovery management.

◦ The logical server was being actively managed when the Matrix recovery managementconfiguration was invoked (logical server modification, logical server activation, or logicalserver deactivation was in progress).

52 Troubleshooting

• No configuration operation can be runPossible causes include:

◦ An Activate, Deactivate, or Import operation is in progress.

◦ Another configuration operation may be in progress

• Unable to import Storage Management Servers as part of an import operationPossible causes include:

◦ The Storage Management Server was not discovered in the HP Matrix OperatingEnvironment user interface.

◦ The credentials associated with the Storage Management Server do not include the username specified in the Matrix recovery management configuration at the Local Site.

◦ The HP Matrix Operating Environment user interface is unable to communicate with theStorage Management Server specified in the Matrix recovery management configurationat the Local Site.

• Import operation failedPossible causes include:

◦ The import file is not valid.

◦ The HP Logical Server Automation service is not running.

◦ There were recovery logical servers in an active state at the time of the import.

Configuration error messagesThis section lists Matrix recovery management configuration error messages.

Error: Matrix recovery management is being quiesced. Currently runningoperations will be allowed to complete. No configuration changes areallowed at this time.

Error message

The user attempts to change the configuration of Matrix recovery management when the system isbeing quiesced.

Cause

Wait for Matrix recovery management to be unquiesced and retry the configuration change.Action

Error: Matrix recovery management is quiesced. No configuration changesare allowed at this time.

Error message

The user attempts to change the configuration of Matrix recovery management when the systemhas been quiesced.

Cause

Wait for Matrix recovery management to be unquieced and retry the configuration change.Action

You are not authorized to access this page.Error message

The user is not authorized to use Matrix recovery management , or the local CMS hostname cannotbe resolved by the DNS.

Cause

Check the HP SIM and Matrix recovery management log files for details, then contact the networkadministrator to add the local CMS hostname to the DNS.

Action

Configuration error messages 53

Cannot verify the host name specified.Error message

The hostname specified for the CMS for either the Local Site or the Remote Site is not locatablein the DNS.

Cause

Verify that a valid DNS entry with a fully qualified domain name exists for each CMS.Action

Cannot create/edit the site information.Error message

The hostname specified for the CMS does not include a fully qualified domain name associatedwith the local CMS.

Cause

Ensure that the CMS for the Local Site has the fully qualified domain of the local host.Action

Storage Management Server not discovered by CMS. Discover server andretry.

Error message

Each Storage Management Server to be configured in Matrix recovery management must bediscovered in the HP Matrix Operating Environment user interface with appropriate credentialsspecified.

Cause

Ensure that the Storage Management Server is discovered in the HP Matrix Operating Environmentuser interface. If not, discover the server by using Options→Discovery in the HP Matrix OperatingEnvironment user interface.

Action

Error: Invalid storage manager username and/or domain name.Error message

The login credentials for the server stored in the HP Matrix Operating Environment user interfacedo not include the user name specified as part of the Storage Management Server configurationoperation in Matrix recovery management.

Cause

For the server specified, ensure that the login credentials stored in the HP Matrix OperatingEnvironment user interface include the credentials for the user name specified.

Action

Error: Failed to add/modify EVA Storage Management Server. Credentialfor Storage Management Server does not exist. Check input and retry.

Error message

The hostname, port number, and user name specified cannot be validated.Cause

Ensure that the server identified by the hostname is an HP P6000 Command view server. Ensurethat CIMOM on the Command View server is configured to use the port number specified and thatthe user name specified is a valid user on that server.

Action

Unable to add/edit Storage Management ServerError message

The server is not properly configured to be managed by the HP Matrix Operating Environment userinterface.

Cause

Ensure that Open SSH is installed and configured on the server, and ensure that the managed nodesand CMS are trusted. This can be achieved by running Configure→Configure or Repair Agents inthe HP Matrix Operating Environment user interface.

Action

Unable to add/edit EVA Storage Replication GroupError message

Unable to obtain information about the Storage Replication Group from the HP P6000 CommandView Server.

Cause

Confirm that the Storage Replication Group exists on the arrays that were listed when the HP P6000Storage Replication Group configuration was added or edited in Matrix recovery management.Ensure that the HP P6000 arrays are managed by HP P6000 Command View servers.

Action

1. Confirm that the SIM-S component of HP P6000 Command View has been installed on the HPP6000 Command View server. For information on installing SMI-S, see the HP P6000 CommandView Software Installation Guide available at http://h20000.www2.hp.com. Click onManuals,

54 Troubleshooting


then go to Storage→Storage Software→Storage Device Management Software→HP P6000Command View Software.

2. Confirm that the port number specified during Storage Management Server configuration inMatrix recovery management is the same as the WBEM port number configured on the HPP6000 Command View server (for example, 5989). For more information, see the “CIMOM”server configuration section in the HP P6000 Command View Software Installation Guide.

3. Refresh the HP P6000 Command View server CIM database by running the refresh command.For details on the Discover command, see the “Configuring HP SMI-S EVA to Discover HPCommand View EVA Arrays” section in the HP P6000 Command View Software InstallationGuide.

4. Ensure that the HP P6000 Command View Software service and CIMOM service are running.Start or restart these services if necessary.

Unable to add/edit XP Storage Replication GroupError message

Matrix recovery management is unable to obtain information about the Storage Replication Groupfrom the RAID manager, or the information obtained does not match the information provided when

Cause

the HP P9000 Storage Replication Group configuration was added or edited in Matrix recoverymanagement.

Ensure that the RAID manager instance on the local Storage Management Server is running. Fromthe install directory of the RAID Manager, run pairdisplay –g <group name> (where <group

Action

name> is the name of the Storage Replication Group being added or edited) to see if the StorageReplication Group is configured and the local array serial number, remote array serial number,and storage replication type matches the data provided when the HP P9000 Storage ReplicationGroup configuration was added or edited in Matrix recovery management.

Unable to add CLX credentials for this HP 3PAR storage system.Error message

The encrypted password file for the corresponding HP 3PAR storage system is incorrect or thepassword for the storage system has been changed and cannot be authenticated using the existingpassword file.

Cause

Ensure the correct password file is present in the /storage/3par/conf directory where Matrixrecovery management is installed for both the local and remote HP 3PAR storage systems. Ifnecessary, regenerate the password files. Retry the Storage Management Server Add operation.

Action

Error: Unable to locate CLX/3PAR install path. Check if CLX/3PAR isinstalled on the system.

Error message

The required software HP 3PAR Cluster Extension Software is not installed, or the CLI version doesnot match the one in the hp_ir.properties file.

Cause

Install only the CLI component of the HP 3PAR Cluster Extension Software by using the custom installoption, or update the INFORM_CLI_VERSION property in conf\hp_ir.properties whereMatrix recovery management is installed on the CMS.

Action

Unable to validate this 3PAR Storage Replication Group.Error message

The parameters entered cannot be validated against those configured on the HP 3PAR storagesystem.

Cause

Verify and correct the parameters (including volume group name on the local HP 3PAR storagesystem, volume group name on the remote HP 3PAR storage system, local array remote copy group

Action

name, remote array remote copy group name, local and remote HP 3PAR storage system serialnumbers, and replication mode) and retry the operation.

Configuration error messages 55

Unable to run Matrix recovery management operations because Matrixrecovery management Job is in progress or another Matrix recoverymanagement configuration operation is in progress.

Error message

If an Activate or Deactivate operation is in progress, no configuration operation is allowed, becausethe Job is in progress. If a Matrix recovery management configuration operation is in progress, noother Matrix recovery management configuration operations are allowed.

Cause

Ensure that the failover process is not taking longer than usual and that the backend job processhp_lsdt_automation.exe is running. Wait for the Activate or Deactivate operation to finish.

Action

Unable to import Storage Management Servers.Error message

A Storage Management Server is not properly configured in the HP Matrix Operating Environmentuser interface.

Cause

Ensure that the Storage Management Server is discovered in the HP Matrix Operating Environmentuser interface. Ensure that Open SSH is installed and configured on the Storage Management

Action

Server. If not, run Configure→Configure or Repair Agents from the HP Matrix Operating Environmentuser interface. Ensure that the credentials for the user are also the login credentials for the serverin the HP Matrix Operating Environment user interface.

Import Failed.Error message

Possible causes include an invalid import file, HP Logical Server Automation service is not running,or one or more recovery logical servers are in an active state.

Cause

Ensure that a valid file exported from the Local Site is used to import the Matrix recovery managementconfiguration at the Remote Site. Confirm that the HP Logical Server Automation service is running

Action

on the CMS. Ensure that all recovery logical servers to be managed by Matrix recovery managementare in a deactivated state at the time of the Matrix recovery management configuration import.

Import succeeded but not all storage managers have been fully configured.Check Matrix recovery management log files for details.

Error message

Credentials were not configured for one or more remote Storage Management Servers.Cause

Action 1. Look at the mxdomainmgr.*.log file to find the remote Storage Management Servers withcredentials that were not configured.

2. Make sure that the Storage Management Servers are up and healthy.3. Discover the Storage Management Servers on the CMS.4. Click on the Matrix recovery management user interface Storage Management Servers tab.5. Select the Storage Management Server that you want to configure, and click Edit.6. Select the Refresh SIM Password box and click Save.

Warning messagesThis section lists Matrix recovery management warning messages.

Warning: Matrix recovery management is being quiesced. Currently runningoperations will be allowed to complete. No new operations can be started.

Warningmessage

Matrix recovery management is being quiesced. All configuration buttons (Create, Edit, Delete,etc…) are disabled.

Cause

Wait for Matrix recovery management to be unquiesced.Action

56 Troubleshooting

Warning: Matrix recovery management is quiesced. No new operations willbe allowed.

Warningmessage

Matrix recovery management has been quiesced. All configuration buttons (Create, Edit, Delete,etc…) are disabled.

Cause

Wait for Matrix recovery management to be unquiesced.Action

Warning: Unable to remove CLX credentials for <storage_management_server_name> (these server credentials may not exist in CLX). Matrix

Warningmessage

recovery management will continue to delete <storage_management_server_name>. HP recommends that you check and manually remove the CLXcredentials.

Failure to clean a CLX credential after successfully deleting a Storage Management Server.Cause

To check and clean a CLX credential, open a command prompt window on the CMS:Action• Change to the CLX bin directory. For example, cd c:\Program

Files\Hewlett-Packard\Cluster Extension 3PAR\bin

• Execute CLX3PARCONFIG array /remove name=<storage_management_server_name>

• Check the command output message.

Matrix recovery management Job troubleshootingFailure of a Matrix recovery management Activate, Deactivate, Recovery Group import or Siteimport Job, may intermittently occur due to a transient error condition between the softwarecomponents.By default, Matrix recovery management automatically retries failed activation and deactivationoperations on logical servers. If a Recovery Group import or site import Job fails, there is noautomatic retry, and the restart option is not available.The details of each failed Job are logged to the lsdt.log file under the Matrix recovery managementinstalled directory, for example, C:\Program Files\HP\Insight Recovery\logs. If thelsdt.log indicates that a site import Job failed due to one or more Recovery Groups that werenot successfully imported, you can attempt to complete the site import by importing the individualRecovery Groups that were not successfully imported in the site import operation. Individual RecoveryGroups can be imported from the Recovery Groups tab. If the cause of the site import Job failureis more extensive, you will need to return to the Sites tab and redo the entire site import. If youchoose to disable automatic retry, you can edit the MAX_RETRY_ATTEMPTS property in thehp_ir.properties file in the conf directory where Matrix recovery management is installed.To disable automatic retry, set the MAX_RETRY_ATTEMPTS property to 0. To re-enable the automaticretry of failed operations by Matrix recovery management, set the MAX_RETRY_ATTEMPTS propertyto 1.

NOTE:• Failed activate and deactivate Jobs will be retried only after the operation has been attempted

on all of the logical servers in the configuration.• Job states for logical server and Recovery Group Jobs will not be marked failed when a retry

of the operation is pending.

To identify the subsystem where the failure occurred, review the remainder of this section forinformation on which log files you need to look at and what action you need to take. For additionalinformation, you can view the lsdt.log file in the logs directory where Matrix recoverymanagement is installed on the system.A Job in Matrix recovery management is an automated, multistep process that activates ordeactivates selected Recovery Group Sets on a site, imports a specific Recovery Group, or importsa Site configuration. For example, the Job with a Job Id of 3288 shown in Figure 21 (page 58) is

Matrix recovery management Job troubleshooting 57

an Activate Job. It has an Entity of type site and an Operation of type activate. You will also noticethe Failed icon in the Status column indicating that Job 3288 has failed.

Figure 21 Jobs screen

For a failed Job, click the check box next to the Job Id to get detailed information about theassociated Sub Jobs.A site Job contains a Sub Job for each Recovery Group. Similarly, each Recovery Group has SubJobs for its Storage Replication Group and logical server, respectively.To troubleshoot a site Job and identify the source of the error, drill down to each of the associatedfailed Sub Jobs to determine what operation failed and the reason for the failure, as shown inFigure 22 (page 58).

Figure 22 Expanded Jobs screeen

For additional information on troubleshooting, see the HP Matrix Operating Environment 7.1Logical Server Management User Guide and the HP Matrix Operating Environment 7.1 InfrastructureOrchestration User Guide available at http://www.hp.com/go/matrixoe/docs.After the problem has been corrected, from the Jobs screen you can restart the Job by clickingrestart in the Status column for the failed Job, as illustrated in Figure 23 (page 59).

58 Troubleshooting


Figure 23 Restarting a failed job

NOTE: Restarting the Job retries only Sub Jobs that previously failed; servers associated withcompleted Jobs or Sub Jobs are not impacted.

IMPORTANT: If correcting the problem that caused the Job to fail included reconfiguration oflogical servers, before you restart the Job, go to the Recovery Groups tab and delete the RecoveryGroups that contain the reconfigured logical servers. Recovery Groups that have been deleted dueto the reconfiguration of logical servers can be recreated with the reconfigured logical servers afterthe Job is successfully completed.

The following troubleshooting issues are addressed in this section:• Failover job failed because storage failover failed.

Possible causes include:

◦ Storage Management Servers were not available at the time of the failover.

• Failover job succeeded but recovery logical servers are not activated.Possible causes include:

◦ Recovery Groups that contain logical servers that are in Maintenance Mode at the RemoteSite.

• Failover job failed because there are no sufficient licensed physical servers or virtual machinesto host the logical servers.Possible causes include:

◦ Physical servers are running other workloads.

◦ Hypervisor management software (for example, VMware vCenter Server) is not runningon the Remote Site.

Matrix recovery management Job troubleshooting 59

• Matrix recovery management job failed because of unlocatable logical server in Matrix OElogical server management.Possible causes include:

◦ A logical server managed by Matrix recovery management was removed from MatrixOE logical server management before it was unmanaged in Matrix recovery management.

• Matrix recovery management job failed because an operation failed in Matrix OE logicalserver management for the logical server.Possible causes include:

◦ Power on of the logical server may have failed.

Failover error messagesThis section contains Matrix recovery management failover error messages.

Failover job fails because storage failover of Storage Replication Groupsfailed

Error message

Possible causes include: The Storage Management Server was not being accessible during the timeof failover, or the status of the Storage Replication Groups does not permit a storage failover.

Cause

Ensure that at least the local Storage Management Server is accessible and actively managing oneof the arrays. To further triage the problem:

Action

• If you are using HP P6000 disk arrays, view the clxevarun.log in STORAGE/EVA/loglocated where Matrix recovery management is installed on the CMS.

• If you are using HP P9000 disk arrays, view clxrun.log in the logs directory where CLX forHP P9000 is installed on the local Storage Management Server.

• If you are using HP 3PAR storage systems, view clx3parrun.log in the logs directory whereHP 3PAR Cluster Extension Software is installed on the CMS.

Failover job fails because of unlocatable logical server in LSMError message

A logical server may have been deleted using Matrix OE visualization without removing the RecoveryGroup containing the logical server from Matrix recovery management.

Cause

Remove the logical server from the Recovery Group in Matrix recovery management and rerun thefailover job. Also look at the lsdt.log file located in the logs directory where Matrix recoverymanagement is installed.

Action

Failover job succeeds but certain logical servers are not activatedError message

Recovery Groups containing those logical servers may be in Maintenance Mode.Cause

Disable Maintenance Mode on the Recovery Groups and rerun the failover operation. Also lookat the lsdt.log file located in the logs directory where Matrix recovery management is installed.

Action

Failover job fails because of insufficient serversError message

There may not be enough licensed physical resources capable of hosting the logical servers.Cause

Ensure that there are enough physical servers licensed for the HP Matrix Operating Environmentavailable to host the logical servers managed by Matrix recovery management. Also look at thelsdt.log file located in the logs directory where Matrix recovery management is installed.

Action

60 Troubleshooting

Matrix recovery management log filesThere are several log files available with detailed information that you can view to help identifythe sources of Matrix recovery management failover or failback problems:• For errors that occur during the initial Matrix recovery management configuration steps, view

the mxdomainmgr(0).log file located in the logs directory where HP Systems InsightManager is installed on the system.

• For errors that occur during a failover, check the lsdt.log file in the logs directory whereMatrix recovery management is installed for details on the specific operation that failed.

• HP P6000 Storage failover related errors are written to the clxevarun.log file in theSTORAGE/EVA/log directory located where Matrix recovery management is installed on thesystem.For a list of log files to use for troubleshooting HP P9000 storage failover issues, see the HPP9000 Cluster Extension Software Administrator Guide.

• HP P9000 Storage failover related errors are written to the clxrun.log file located in theCluster Extension XP\log directory of the storage management server accessed byMatrix recovery management to perform the storage failover operation.Additional information on logical server activation and deactivation issues initially reportedin the Matrix recovery management Jobs screen can be found in the Matrix OE visualizationLogical Server Job Status screen. Select a logical server job based on its Job Title and viewits Job Details.

• For a list of log files to use for troubleshooting HP 3PAR storage failover issues, see the HP3PAR Cluster Extension Software Administrator Guide available at http://h20000.www2.hp.com. Click Manuals, then go to Storage→Storage Software→StorageReplication Software→HP Cluster Extension Software.

DR Protected IO serivces troubleshootingFor failures that occur during Matrix recovery management operations on IO services RecoveryGroups, the following general troubleshooting steps apply:1. Check the lsdt.log file in the logs directory where Matrix recovery management is installed

for details on the specific operation that failed.2. Check the status of the IO services in the Matrix IO Services page to see if the IO services are

in the correct state for the specific operation that failed.3. Check the hpio.properties files and the dr.properties files on the Local and Remote

Site CMS to make sure they are set correctly. For more information see “DR protection for IOservices” (page 22).

4. If an activate, deactivate, or import operation failed, go to the Matrix recovery managementJobs screen and review the Job details.

5. If necessary, go to the IO Requests screen to view the requests on the IO services involved inthe failed Matrix recovery management operation.

6. If necessary, check the hpio-controller.log file in the logs directory where IO is installedfor details on the specific IO operation that failed.

7. For additional information on troubleshooting issues related to IO services, see theTroubleshooting section in the HP Matrix Operating Environment 7.1 Infrastructure OrchestrationUser Guide available at http://www.hp.com/go/matrixoe/docs.

Matrix recovery management log files 61




DR Protected IO services configuration troubleshootingIn addition to the configuration issues addressed in this User Guide that are common to both logicalservers and IO services, the following configuration issues apply to IO services only:• Failed to get a list of IO services that can be included in a recovery group

Possible Causes:

◦ Matrix infrastructure orchestration Windows service is not running.

◦ There are no IO services that are DR protection enabled.

◦ All DR protection enabled IO services are already configured in IO services RecoveryGroups.

◦ Communication failure with IO.

• Failed to import an IO servicePossible causes:

◦ The import file is invalid.

◦ The replica service to be created already exists and is running locally.

◦ A primary service with the same name already exists.

◦ The values of the properties in the hpio.properties and dr.properties files arenot correctly set.– DR protection is not enabled (enable.dr.protection = false).

– The datastores specified in volume.dr.replica.list do not match the datastoresfor the IO service at the Remote Site.

– User name and domain name mapping is not specified.

◦ Resources (network and storage) are not available.

◦ The Matrix infrastructure orchestration Windows service is not running.

◦ There is a communication failure with IO.

• One or more Recovery Groups in the Matrix recovery management configuration areinconsistent with the Matrix OE logical server management or IO configurationPossible causes include:

◦ The Matrix OE logical server management service, the Matrix infrastructure orchestrationWindows service, or both of these services were not running when Recovery Groupswere configured in Matrix recovery management.

◦ The logical sever or IO service was being actively managed when the Matrix recoverymanagement configuration was invoked (modification, activation, or deactivation wasin progress).

62 Troubleshooting

IO services configuration error messages

Unable to get the IO service.Error message

The IO service does not exist or Matrix recovery management failed to get the IO service informationfrom the Matrix infrastructure.

Cause

Check the Matrix recovery management and IO log files for more information on the failure. If theIO service does not exist in IO, it is possible that the IO service was removed. If the IO serviceexists, restart IO and retry the operation.

Action

Error: HP Matrix infrastructure orchestration is down, causing eitheran empty list of services, or an unfiltered list of available logical

Error message

servers (which includes the ones managed by Matrix IO services). RestartHP Matrix infrastructure orchestration and retry.

When an IO services Recovery Group was created or modified using the Matrix recoverymanagement GUI, Matrix recovery management was not able to communicate with IO to obtaina list of available IO services to be included in the Recovery Group.

Cause

Restart the Matrix infrastructure orchestration Windows service and retry the operation.Action

Error: Failed to filter out logical servers managed by Matrix IOservices. Restart Matrix IO and retry.

Error message

When an IO services Recovery Group was created or modified using the Matrix recoverymanagement GUI, Matrix recovery management was not able to communicate with IO to obtain

Cause

a list of IO services to filter out the VM logical servers that are not already part of an IO servicethat has DR Protection enabled.

Restart the Matrix infrastructure orchestration Windows service and retry the operation.Action

Error: Failed to import Matrix IO service. A primary service with thesame name already exists.

Error message

During import, a primary IO service with the same name as the imported replica IO service existsin IO.

Cause

Either delete the primary IO service at the Local Site or recreate the primary IO service with adifferent name.

Action

Error: One or more Recovery Groups in the Matrix recovery managementconfiguration were found to be inconsistent with the LSM or Matrix

Error message

infrastructure orchestration configuration. Please delete them. Checkthe Matrix recovery management log files to identify the inconsistencythat caused the error.

Matrix recovery management was not able to communicate with Matrix Operating Environment orIO to confirm that a logical server or IO service is being managed by Matrix recovery management.

Cause

Delete the Recovery Group containing the logical server or IO service from Matrix recoverymanagement. Confirm that the Matrix OE logical server management service and the IO service

Action

are running. Ensure that the logical server and IO service are not being actively modified by anotheruser. Retry adding the Recovery Group in Matrix recovery management.

DR Protected IO serivces troubleshooting 63

DR Protected IO services failover troubleshootingIn addition to the failover issues addressed in this User Guide that are common to both logicalservers and IO services, the following failover issues apply to IO services only:• Failed to activate IO service in a Recovery Group

Possible Causes:

◦ Storage resources are not available.

◦ The IO service is in an invalid state for activation.

◦ The IO service does not exist.



• Failed to deactivate IO service in a Recovery GroupPossible Causes:


◦ The IO service does not exist.

◦ The IO service is in an invalid state for deactivation.


Matrix recovery management error messages specific to IO services

Failed to get the IO service.Error message

Matrix recovery management was not able to get the IO service information from IO.Cause

Check the Matrix recovery management and IO log files for more details on the failure. Restart theMatrix infrastructure orchestration Windows service and retry the operation.

Action

Service activation/deactivation cannot be performed at this time sincethe service is in IN_PROGRESS state.

Error message

The IO service was being operated on when the Matrix recovery management activation ordeactivation operation was performed (modification, activation, or deactivation was in progress).

Cause

Wait for the IO service to exit the IN_PROGRESS state and retry the activation or deactivationoperation.

Action

64 Troubleshooting

7 Support and other resourcesInformation to collect before contacting HP

Be sure to have the following information available before you contact HP:

• Software product name

• Hardware product model number

• Operating system type and version

• Applicable error message

• Third-party hardware or software

• Technical support registration number (if applicable)

How to contact HPUse the following methods to contact HP technical support:

• See the Contact HP Worldwide website: http://www.hp.com/go/assistance

• Use the Contact hp link on the HP Support Center website: http://www.hp.com/go/hpsc

• In the United States, call 1-800-334–5144 to contact HP by telephone. This service is available24 hours a day, 7 days a week. For continuous quality improvement, conversations might berecorded or monitored.

Registering for software technical support and update serviceHP Insight Management components and software products include one year of 24 x 7 HP SoftwareTechnical Support and Update Service. This service provides access to HP technical resources forassistance in resolving software implementation or operations problems.The service also provides access to software updates and reference manuals, either in electronicform or on physical media, as they are made available from HP. Customers who purchase anelectronic license are eligible for electronic updates only.With this service, Insight Management customers benefit from expedited problem resolution aswell as proactive notification and delivery of software updates. For more information about thisservice, see the following website: http://www.hp.com/services/insight.There are two methods for registering:• If you received a license entitlement certificate, automated registration for this service takes

place upon online redemption of the license certificate/key.• If the license information you received for your product instructs you to register for Software

Technical Support and Update Service, you must follow the instructions in order to be eligiblefor telephone support and product updates.

How to use your software technical support and update serviceAs HP releases updates to software, the latest versions of the software and documentation aremade available to you. The Software Updates and Licensing portal gives you access to software,documentation, and license updates for products on your HP software support agreement.You can access this portal from the HP Support Center:http://www.hp.com/go/hpscAfter creating your profile and linking your support agreements to your profile, see the SoftwareUpdates and Licensing portal at http://www.hp.com/go/hpsoftwareupdatesupport to obtainsoftware, documentation, and license updates.

Information to collect before contacting HP 65

http://www.hp.com/go/assistance

http://www.hp.com/go/hpsc

http://www.hp.com/services/insight

http://www.hp.com/go/hpsc

http://www.hp.com/go/hpsoftwareupdatesupport

Warranty informationHP will replace defective delivery media for a period of 90 days from the date of purchase. Thiswarranty applies to all HP Insight Management products.

HP authorized resellersFor the name of the nearest HP authorized reseller, see the following sources:• In the United States, see the HP U.S. service locator website:

http://www.hp.com/service_locator

• In other locations, see the Contact HP worldwide website:http://welcome.hp.com/country/us/en/wwcontact.html

Documentation feedbackHP welcomes your feedback. To make comments and suggestions about product documentation,send a message to:[email protected] the document title and manufacturing part number in your message. All submissions becomethe property of HP.

Related informationFor support, software updates, and additional information on Matrix recovery management andother products used with Matrix recovery management, see the following websites:• Matrix recovery management website at http://www.hp.com/go/insightrecovery.

• HP Insight Orchestration website at http://www.hp.com/go/insightorchestration.

• HP Matrix Operating Environment website at http://www.hp.com/go/matrixoe.

• HP Insight Control website at http://www.hp.com/go/insightcontrol.

• HP Insight Control virtual machine management website at http://www.hp.com/go/vmmanage.

• HP Insight Control server deployment website at http://www.hp.com/go/rdp.

• VMware Documentation at http://www.vmware.com/support/pubs.

Matrix recovery management documentationFor more information on Matrix recovery management, see the following sources:

• HP Insight Management 7.1 Support MatrixProvides Matrix recovery management support information along with other HP Insighthardware, software, and firmware support information. Available at http://www.hp.com/go/matrixoe/docs.

• HP Matrix Operating Environment 7.1 Release NotesProvides information on what's new with this release, features, and change notifications forMatrix recovery management and other HP Matrix Operating Environment components.Available at http://www.hp.com/go/matrixoe/docs.

• HP Matrix Operating Environment 7.1 Getting Started GuideProvides installation information for Matrix recovery management and other HP MatrixOperating Environment components. Available at http://www.hp.com/go/matrixoe/docs.

66 Support and other resources

http://www.hp.com/service_locator

http://welcome.hp.com/country/us/en/wwcontact.html

mailto:[email protected]

http://www.hp.com/go/insightrecovery

http://www.hp.com/go/insightorchestration

http://www.hp.com/go/matrixoe

http://www.hp.com/go/ice

http://www.hp.com/go/vmmanage

http://www.hp.com/go/rdp

http://www.vmware.com/support/pubs





• HP Matrix Operating Environment 7.1 Recovery Management User GuideProvides information on Matrix recovery management installation, configuration, testing, andtroubleshooting. Available at http://www.hp.com/go/matrixoe/docs.

• Matrix recovery management white papersMatrix recovery management white papers are available at http://www.hp.com/go/matrixoe/docs.

• Matrix recovery management online helpThe Matrix recovery management online help provides information on operations that areperformed from the Matrix recovery management user interface. It is accessible from the Matrixrecovery management user interface and from the Help menu on the HP Matrix OperatingEnvironment home page.

Related information 67




Glossarybidirectionalfailover

A Matrix recovery management feature that allows Recovery Group Sets to be activated ordeactivated at either the Local Site or the Remote Site. At any point in time there can be activatedand deactivated Recovery Group Sets at both sites. In the event of a disaster, or to accommodatesite maintenance, all of the Recovery Group Sets in the Matrix recovery management configurationcan be deactivated at one site, and activated at the other site.

CMS HP Systems Insight Manager (HP SIM) Central Management Server—A system in the managementdomain that executes the HP SIM software. All central operations within HP SIM are initiatedfrom this system.

consistency group Consistency groups are an important property of asynchronous mode volumes. A consistencygroup is a group of LUNs that need to be treated the same from the perspective of data consistency(I/O ordering). A consistency group is equal to a device group in the Raid Manager configurationfile.

cross-technologylogical servers

Logical servers that can be moved back and forth between being VC hosted (hosted by a physicalserver) or VM hosted (hosted by a virtual machine). See VC hosted logical server and VM hostedlogical server for more information.

CSV Cluster shared volumes.discovery A feature within a management application that finds and identifies network objects. In HP

management applications, discovery finds and identifies all the HP systems within a specifiednetwork range.

DR Group (Disaster Recovery Group) The HP P6000 Continuous Access Software term for a StorageReplication Group.

DR Protected Logical servers and Matrix infrastructure orchestration services that are managed by Matrixrecovery management are referred to as DR Protected (disaster recovery protected) logical serversand IO services.

HP Matrix OElogical servermanagement

A component of the HP Matrix Operating Environment software that manages and automatesoperations associated with logical servers, including resource provisioning, startup, and shutdown.

HP SIM HP Systems Insight ManagerIO services HP Matrix Operating Environment infrastructure orchestration services.IO services logicalserver

A logical server that is associated with IO services.

Job An automated, multistep process associated with:

• A Matrix recovery management Activate or Deactivate operation.

• A Matrix recovery management Site import operation.

• A Matrix recovery management Recovery Group import operation.

Local Site In a Matrix recovery management configuration, this is the set of managed nodes andcorresponding CMS that your browser is interacting with.

logical server A logical server is a management abstraction that simplifies and optimizes the provisioning,management, and movement of a server, whether it is a physical server or a virtual machine. Alogical server is the complete software image of a server, including operating system, applications,configuration data, and metadata that you create and assign to operate on a physical server orvirtual machine. Logical servers are managed by HP Matrix OE visualization.

MaintenanceMode Maintenance Mode is used to test Recovery Groups to ensure they will function properly whenan Activate operation is performed. Maintenance mode temporarily stops Matrix recoverymanagement from managing a DR Protected logical server or IO service. One use of maintenancemode is to perform failover rehearsal. By setting Maintenance Mode on a Recovery Group, allof the logical servers and Matrix infrastructure orchestration services in that Recovery Group canbe activated through the Matrix Operating Environment. Once you are satisfied with the failover

68 Glossary

rehearsal, the Recovery Group and its corresponding logical servers and IO services can bebrought back under the control of Matrix recovery management.

Matrixinfrastructureorchestrationservices

Matrix infrastructure orchestration services (IO services) quickly provision infrastructure toautomatically activate physical and virtual servers, storage, and networking from pools of sharedresources. More information on Matrix infrastructure orchestration is available at http://www.hp.com/go/insightorchestration.

Matrix recoverymanagementconfigurationprocess

The following table lists the six steps in the Matrix recovery management configuration process.

Table 2 The Matrix recovery management configuration process

Stepnumber

Description

Local and Remote Sites are defined in this step, including naming the sites, designatingCentral Management Servers, and designating preferred target types (physical servers orvirtual machines).

1

Local and remote Storage Management Servers are configured in this step. These serversmanage the Storage Replication groups at the Local and Remote Site respectively.

2

Storage Replication Group information is configured in this step. In Matrix recoverymanagement, a Storage Replication Group is a generic term for what is referred to as a DR

3

Group in HP P6000 Continuous Access terminology, or a Device Group in HP P9000terminology.

Recovery Groups are configured in this step. A Recovery Group is a Matrix recoverymanagement concept that pairs one or more logical servers or IO services with a single

4

Storage Replication Group. Recovery Group Sets can be failed over between Local andRemote Sites. A Recovery Group Set includes all Recovery Groups that share the samePreferred and Secondary Sites.

Export the Matrix recovery management configuration to a file at the Local Site .5

Import the Matrix recovery management configuration file at a Remote Site.6

NPIV N_Port ID Virtualizationplanned failover A failover of all Recovery Group Sets from one site to another site, initiated in anticipation of an

imminent disaster or for planned downtime.portability group A portability group is a group of virtual machines or c-Class blades equipped with HP Virtual

Connect (or a combination virtual machines and c-Class blades) that a logical server can bemoved between.

Power-Up Delay A Recovery Group configuration setting that determines the minimum time delay (in minutes)between the power-up of any two logical servers in a Recovery Group. The actual time delaymay be more than the minimum time delay specified.

Preferred Site The Preferred Site is the site where you prefer the Recovery Group to be activated unlesscircumstances require activation of the Recovery Group at the Secondary Site.

primary IO service A primary IO service is the first instance of an IO service that you select for DR Protection in aMatrix recovery management configuration. A replica IO service is a service Matrix recoverymanagement creates during an import operation at a recovery site based on the primary IOservice definition in the Matrix recovery management export file.

private A subnet that is not routed outside the data center and typically contains addresses only in the192.x.x.x or 10.x.x.x address ranges. A subnet that is accessible to the Internet and cannotcontain IP addresses in the 192.x.x.x or 10.x.x.x address ranges.

RDM Raw Disk Mappingrecoverable IOservices

Matrix infrastructure orchestration services that have been configured so they can be included ina DR Protected Matrix recovery management IO services Recovery Group.

Recovery Group A pairing of one or more logical servers and a single Storage Replication Group. A RecoveryGroup has a Recovery Group Start Order number associated with it. During a site failover,Recovery Groups are failed over from one site to another site in the order specified.

69



Recovery GroupSet

A set of Recovery Groups that share the same Preferred and Secondary sites. Recovery Groupscannot be activated or deactivated individually. Instead, all Recovery Groups that share the samePreferred and Secondary site must be activated or deactivated as a set. Recovery Group Setscan be selected for activation or deactivation at the Local site.

Recovery GroupStart Order

An optional number that specifies the order in which a Recovery Group is to be started during asite failover. Recovery Groups without a start order number are started after all Recovery Groupsthat have an associated start order number.

recovery logicalservers

Logical servers at the Remote Site that are included in a Recovery Group. They are associatedwith logical servers at the Local Site that are included in the same Recovery Group. Normallythey are deactivated and disabled. They are enabled and activated upon site failover.

redundant SAN The duplication of components to prevent failure of the SAN solution.Remote Site A site in a Matrix recovery management configuration that is not the Local Site.replica IO service A replica IO service is a service Matrix recovery management creates during an import operation

at a recovery site based on the exported IO service definition in the Matrix recovery managementexport file.

replica IO servicelogical servers

Logical servers that are associated with replica IO services.

SAN A Storage Area Network (or subnetwork) that connects data storage devices with associateddata servers. A SAN is typically part of an overall network of computing resources.

Secondary Site The Secondary Site is the site where you prefer the Recovery Group to be on “standby” (in adeactivated state), unless circumstances require activation of the Recovery Group at the SecondarySite.

split-brain Split brain occurs when two or more instances of the same application are active simultaneously,which might lead to data corruption.

StorageDecoupling

A Matrix recovery management feature that allows failover of the logical servers or IO servicesin a Recovery Group without failing over the Storage Replication Groups that are associated withthose logical servers or IO services.

StorageManagementServer

As part of the Matrix recovery management configuration process, servers that manage HPP6000, HP P9000, HP 3PAR, or User Defined storage devices must be defined. These serversare referred to as Storage Management Servers.

Storage ReplicationGroup

A set of LUNs across which storage replication preserves write-order at the replication targetstorage array. In HP P6000 Continuous Access Software terminology, this is known as a DRGroup. In HP P9000 Continuous Access Software terminology this is known as a consistencygroup.

Sub Job A Sub Job is component of a Matrix recovery management activate, deactivate, Recovery Groupimport or Site import Job. For example, a Site activate Job would include a Recovery Groupactivate Sub Job for each Recovery Group that is activated on that site, and each Recovery Groupactivate Sub Job would include a logical server activate Sub Job for each logical server in thatRecovery Group.

unplanned failover A failover of all Recovery Group Sets from one site to another site, initiated in response to anunforeseen event that caused an outage at the site where the Recovery Group Sets where activated.

User Definedstorage

Matrix recovery management provides a User Defined storage adapter interface specification toenable one-step Matrix recovery management failover capability for storage types that aresupported by Matrix OE, but not yet integrated with Matrix recovery management.

User DefinedStorageManagementServers

When you install a storage adaptor in your Matrix recovery management configuration for astorage type other than HP 3PAR, HP P6000, or HP P9000, you can define (and edit) StorageManagement Servers based on that storage adaptor. These are referred to as User DefinedStorage Management Servers in a Matrix recovery management configuration. For example, ifyou create and install a storage adaptor named EMC, the Storage server type drop-down menufor configuring a Storage Management Server will allow you to select EMC as the storage servertype. For more information, see the HP Matrix Operating Environment 7.1 Getting Started Guideavailable at http://www.hp.com/go/matrixoe/docs.

VC hosted logicalserver

A logical server running on a c-Class blade equipped with HP Virtual Connect.

70 Glossary


VM hosted logicalserver

A logical server running on a virtual machine under the control of a hypervisor.

71

hp matrix oe 7.1

Documents