Building Disaster Recovery Serviceguard Solutions Using Metrocluster with Continuous Access EVA P6000 for Linux B

Transcription

1 Building Disaster Recovery Serviceguard Solutions Using Metrocluster with Continuous Access EVA P6000 for Linux B HP Part Number: Published: December 2012

2 Legal Notices Copyright Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use, or copying. Consistent with FAR and , Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor s standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Linux is a U.S. registered trademark of Linus Torvalds.

3 Contents 1 Introduction...5 Overview of P6000/EVA and HP P6000 Continuous Access Concepts...5 Copy sets...5 Data replication Groups (DR Groups)...5 Write modes...6 DR Group write history log...7 Failover...7 Failsafe mode...8 Failsafe on Link-down/Power-up...8 Overview of a Metrocluster with HP P6000 Continuous Access configuration...9 HP P6000 Continuous Access Management Software Configuring an application in a Metrocluster environment...11 Installing the necessary hardware and software...11 Setting up the storage hardware...11 Installing the necessary software...11 Creating the cluster...11 Site Aware Failover Configuration...11 Setting up the replication...12 Creating VDISKs and DR groups using HP P6000 command view...12 Using Storage System Scripting Utility (SSSU)...13 Creating the Metrocluster with Continuous Access EVA P6000 for Linux Map for the replicated storage...13 Defining Management Server and SMI-S information...14 Creating the Management Server list...14 Creating the Management Server Mapping file...14 Setting a default Management Server...15 Displaying the list of Management Servers...15 Adding or updating Management Server information...15 Deleting a Management Server...16 Defining HP P6000/EVA Storages cells and DR groups...16 Creating the Storage Map file...16 Displaying information about storage devices...17 Copying the Map file...17 Configuring volume groups...17 Identify the device special files for Vdisk in DR group...17 Identifying special device files...18 Configuring LVM volume group using Metrocluster with Continuous Access EVA P6000 for Linux...18 Creating LVM volume groups...18 Installing and configuring an application...19 Configuring a Metrocluster package...19 Setting up Disk Monitoring...21 Configuring a Metrocluster package using Serviceguard Manager Metrocluster features...25 Data replication storage failover preview...25 Rolling upgrade for Metrocluster...25 Live Application Detach Understanding failover/failback scenarios...27 Metrocluster package failover/failback scenarios...27 Contents 3

4 5 Administering Metrocluster...31 Adding a node to Metrocluster...31 Maintaining EVA P6000 Continuous Access replication in Metrocluster...31 HP P6000 Continuous Access Link failure scenarios...31 Planned maintenance...32 Node maintenance...32 Metrocluster package maintenance...32 Failback...32 Administering Metrocluster with Serviceguard Manager...32 Rolling upgrade...33 Upgrading Metrocluster replication software...33 Limitations of the rolling upgrade for Metrocluster...33 Upgrading replication management software...33 Upgrading the OpenPegasus WBEM Services for Metrocluster with Continuous Access EVA P6000 for Linux Troubleshooting...34 Troubleshooting Metrocluster...34 Metrocluster log...34 HP P6000/EVA storage system log...34 A Checklist and worksheet for configuring a Metrocluster with Continuous Access EVA P6000 for Linux...35 Disaster Recovery Checklist...35 Cluster Configuration Worksheet...35 Package Configuration Worksheet...36 P6000/EVA Configuration Checklist...37 B Package attributes for Metrocluster with Continuous Access EVA P6000 for Linux...38 C smiseva.conf file...40 D mceva.conf file...41 E Identifying the devices to be used with packages...43 Identifying the devices created in P6000/EVA...43 Glossary...44 Index Contents

5 1 Introduction This document describes how to configure data replication solutions using HP P6000/EVA disk Arrays to provide disaster recovery for Serviceguard clusters over long distances. It also gives an overview of the HP P6000 Continuous Access software and the additional files that integrate HP P6000/EVA disk Arrays with Metrocluster. Overview of P6000/EVA and HP P6000 Continuous Access Concepts Copy sets HP P6000 Continuous Access provides remote data replication from primary HP P6000/EVA storage systems to remote HP P6000/EVA storage systems. HP P6000 Continuous Access uses the remote-copy function of the Hierarchical Storage Virtualization (HSV) controller running the controller software (VCS or XCS) to achieve host-independent remote data replication. Remote replication is the continuous copying of data from selected virtual disks on a source (local) array to related virtual disks on a destination (remote) array. Virtual disks (Vdisks) are user defined storage allotments of virtual or logical data storage. Applications continue to run while data is replicated in the background. Remote replication requires a fabric connection between the source and destination arrays and a logical grouping between source virtual disks and destination virtual disks. This section describes some basic remote replication concepts. The topics discussed are: Copy Sets Data Replication Groups (DR Groups) Write modes DR group write history log Failover Failsafe mode Failsafe on Link-down/Power-up A pairing relationship can be created to automatically replicate a logical disk from the source array to another logical disk in the destination array. A pair of source and destination virtual disks that have replication relationship is called a copy set. A Vdisk does not have to be part of a copy set. Vdisks at any site can be set up for local storage and used for activities, such as testing and backup. Clones and snapclones are examples of Vdisks used in this manner.when a Vdisk is not part of a copy set, it is not disaster tolerant, but it can use various Vraid types for failure tolerance. Data replication Groups (DR Groups) A DR group is a logical group of virtual disks in a remote replication relationship between two arrays. DR groups operate in a paired relationship, with one DR group being a source and the other a destination. Hence a DR group can be thought of as a collection of copy sets. The terms source and destination are sometimes referred to as a DR mode or DR role. Hosts write data to the virtual disks in the source array, and the array copies the data to the virtual disks in the destination array. I/O ordering is maintained across the virtual disks in a DR group, ensuring I/O consistency on the destination array in the event of a failure of the source array. All virtual disks used for replication must belong to a DR group, and a DR group must contain at least one Vdisk. When a DR group is first created, a full copy normalization occurs to copy all the data in the DR group from the source array to the destination array, bringing the source and destination vdisks into synchronization. Normalizations copy data from the source array to the destination array in 128 KB blocks. Overview of P6000/EVA and HP P6000 Continuous Access Concepts 5

6 Write modes The replicating direction of a DR group is always from a source to a destination. In bidirectional replication, an array can have both source and destination virtual disks that will reside in separate DR groups. That is, one virtual disk cannot be both a source and destination simultaneously. Bidirectional replication enables you to use both arrays for primary storage while they provide disaster protection for another site. The remote copy feature is intended not only for disaster recovery, but also to replicate data from one storage system or physical site to another storage system or site. It also provides a method for performing a backup at either the source or destination site. HP P6000 Continuous Access has the ability to suspend and resume replication. Some versions of controller software support auto suspend when a full copy of the DR group is required. This feature can be used to protect the data at the destination site by delaying the full copy operation until a snapshot or snapclone of the data has been made. See the HP P6000 EVA Compatibility Reference available at > storage -> Storage Software -> Storage Replication Software -> HP P6000 Command View Software to determine if your array supports this feature. IMPORTANT: Metrocluster with Continuous Access EVA P6000 for Linux does not support enabling auto suspend on full copy feature. The remote replication write modes are as follows: Synchronous The array acknowledges I/O completion after the data is cached on both the local and destination arrays. Asynchronous The array acknowledges I/O completion before data is replicated on the destination array. Asynchronous write mode can be basic or enhanced, depending on the software version of the controller. Basic Asynchronous mode An I/O completion acknowledgement is sent to the host immediately after data is written to the cache at the source controller, but before the data is delivered to the cache on the destination controller. There is no requirement to wait for the I/O completion acknowledgement from the destination controller. Enhanced Asynchronous mode The host receives an I/O completion acknowledgement after the data is successfully written to the disk based log/journal, which is used to queue the writes, which occurs after the data is written to local cache. The asynchronous replication process reads the I/O from the journal and replicates it, using current methodologies, to destination P6000/EVA. You can specify the replication write mode when you create DR groups. The choice of write mode, which is a business decision, has implications for bandwidth requirements and RPO. Synchronous mode provides greater data currency because RPO will be zero. Asynchronous mode provides faster response to server I/O, but at the risk of losing data queued at the source side if a site disaster occurs. For complete information on which write modes are supported on each version of controller software, see HP P6000 EVA Compatibility Reference available at support/manuals >storage -> Storage Software -> Storage Replication Software -> HP P6000 Command View Software. IMPORTANT: This product supports only Synchronous replication mode and the Enhanced Asynchronous replication mode and does not support basic asynchronous replication mode. For more information on supported arrays, see the Disaster Tolerant Clusters Products Compatibility Feature Matrix available at: 6 Introduction

7 DR Group write history log Failover The DR group write history log is a virtual disk that stores a DR group's host write data. The log is created when you create the DR group. Once the log is created, it cannot be moved. In synchronous mode or basic asynchronous mode, the DR group write history log stores data when replication to the destination DR group is stopped because the destination DR group is unavailable or suspended. This process is called logging. When replication resumes, the contents of the log are sent to the destination virtual disks in the DR group. This process of sending I/Os contained in the write history log to the destination array is called merging. Because the data is written to the destination in the order that it was written to the log, merging maintains an I/O-consistent copy of the DR group's data at the destination. When using synchronous mode or basic asynchronous mode, if logging occurs because replication has been suspended or the replication links have failed, the size of the log file expands in proportion to the amount of writes. The size of the log file can increase only up to the user-specified maximum value or to the controller's software default maximum value. You can set the maximum size for the DR group write history log while in synchronous mode. The size of the log can't be changed while in basic asynchronous mode. You must change the write mode to synchronous, change the log file size, and then return to basic asynchronous mode. In synchronous mode and basic asynchronous mode, the log grows as needed when the DR group is logging and it shrinks as entries in the log are merged to the remote array. The controller considers the log disk full when one of the following occurs: No free space remains in the disk group that contains the log disk. The log disk reaches 2 TB of Vraid1 space. The log reaches the default or user-specified maximum log disk size. In enhanced asynchronous mode, the DR group write history log acts as a buffer and stores the data until it can be replicated. The consumption of the additional capacity required for the log should not be viewed as missing capacity it is capacity used to create the log. The DR group write history log file size is set when you transition the DR group to enhanced asynchronous mode. The space for the DR group write history log must be available on both the source and destination arrays before the DR group is transitioned to enhanced asynchronous mode. Once set, the space is reserved for the DR group write history log and cannot be reduced in size. If necessary, you can reclaim allocated log disk space from a DR group in enhanced asynchronous mode. You must first change the write mode to synchronous and then use the log control feature to reduce the log size. When the log content has been drained, you can return the DR group to enhanced asynchronous mode. Until the DR group is returned to enhanced asynchronous mode, the DR group operates in synchronous mode, which may impact performance. Allocated log file space is not decreased when DR group members are removed. Log space usage will increase when members are being added to an existing DR group unless the size of the log disk has reached the maximum of 2 TB or has been fixed to a user-defined value. For details on maximum and default log sizes for different replication modes, see the HP P6000 EVA Compatibility Reference available at > storage -> Storage Software -> Storage Replication Software -> HP P6000 Command View Software. When a write history log overflows, the controller invalidates the log contents and marks the DR group for normalization to bring the source and destination arrays back into synchronization. NOTE: When the replication mode is manually changed from asynchronous to synchronous mode, the state is displayed as Run Down. In HP P6000 Continuous Access replication, failover reverses replication direction for a DR group. The destination array assumes the role of the source, and the source array assumes the role of the destination. The process can be planned or unplanned. A planned failover allows an orderly Overview of P6000/EVA and HP P6000 Continuous Access Concepts 7

8 shutdown of the system before the redundant system takes over. An unplanned failover occurs when a failure or outage occurs that may not allow an orderly transition of roles. NOTE: Failsafe mode Failover can take other forms: Controller failover The process that occurs when one controller in a pair assumes the workload of a failed or redirected controller in the same array. Fabric or path failover I/O operations transfer from one fabric or path to another. Failsafe mode is only available when a DR group is being replicated in synchronous mode and specifies how host I/O is handled if data cannot be replicated between the source and destination array. The failsafe mode can be one of the following: Failsafe enabled All host I/O to the DR group is stopped if data cannot be replicated between the source array and destination array. This ensures that both arrays will always contain the same data (RPO of zero). A failsafe-enabled DR group can be in one of two states: Locked (failsafe-locked) Host I/O and remote replication have stopped because data cannot be replicated between the source and destination array. Unlocked (failsafe-unlocked) Host I/O and remote replication have resumed once replication between the arrays is re-established. Failsafe disabled If replication of data between the source and destination array is interrupted, the host continues writes to the source array, but all remote replication to the destination array stops and I/Os are put into the DR group write history log until remote replication is re-established. NOTE: Failsafe mode is available only in synchronous write mode. Host I/O can be recovered by changing affected DR groups from failsafe-enabled mode to failsafe-disabled mode. This action will begin logging of all incoming writes to the source member of the Data Replication group. Metrocluster with Continuous Access EVA P6000 for Linux does not support enabling Failsafe Mode. Failsafe on Link-down/Power-up Failsafe on Link-down/Power-up is a setting that specifies whether or not virtual disks in a DR group are automatically presented to hosts after a power-up (reboot) of the source array when the links to the destination array are down and the DR group is not suspended. This prevents a situation where the virtual disks in a DR group are presented to servers on the destination array following a failover and then the virtual disks on the source array are also presented when it reboots. Values for Failsafe on Link-down/Power-up are as follows: Enabled Virtual disks in a source DR group are not automatically presented to hosts. This is the default value assigned to a DR group when it is created. This behavior is called presentation blocking and provides data protection under several circumstances. Host presentation remains blocked until the destination array becomes available (and can communicate with the source array) or until the DR group is suspended. Disabled Virtual disks a source DR group are automatically presented to hosts after a controller reboot. NOTE: Metrocluster with Continuous Access EVA P6000 for Linux does not support enabling Failsafe on Link-down/Power-up. 8 Introduction

9 For more information on remote data replication concepts and planning a remote replication solution, see HP P6000 Continuous Access Implementation Guide available at support/manual >storage -> Storage Software -> Storage Replication Software -> HP P6000 Continuous Access Software. Overview of a Metrocluster with HP P6000 Continuous Access configuration A Metrocluster is configured with the nodes at Site A and Site B. When Site A and Site B form a Metrocluster, a third location is required where Quorum Server or arbitrator nodes must be configured. There is a HP P6000/EVA storage at each site and they are connected to each other through Continuous Access links. An application is deployed in a Metrocluster by configuring it at both the sites. The sites are referred either as DC1 or DC2 for an application, based on their role. Typically, the application runs on DC1 site which is the primary site. If there is a disaster in DC1 site, the application automatically fails over to the recovery site referred as DC2 site. NOTE: DC1 and DC2 are application-specific roles of a site. For each application, either synchronous or enhanced asynchronous mode replication is configured to replicate data between the two sites using DR group. In a typical configuration, more than one application is configured to run in a Metrocluster. Depending on the application distribution in a Metrocluster environment, some applications can have Site A as its DC1 while some other applications can have Site B as its DC1. Overview of a Metrocluster with HP P6000 Continuous Access configuration 9

10 Figure 1 Sample Configuration of Metrocluster with Continuous Access EVA P6000 for Linux Quorum Server A B Node 1 Node 2 Node 3 Node 4 Site A Metrocluster Site B Router Router Synchronous / Enhanced Asynchronous EVA Disk Array DC1 for App A DC2 for App B EVA Disk Array DC1 for App B DC2 for App A Figure 1 depicts an example of two applications distributed in a Metrocluster with Continuous Access EVA P6000 for Linux environment balancing the server and replication load. In this example, Site A is the primary site or DC1 for application A, and recovery site or DC2 for application B. Site B is the primary site or DC1 for application B, and recovery site or DC2 for application A. HP P6000 Continuous Access Management Software Metrocluster with Continuous Access EVA P6000 for Linux requires the following two software components to be installed in the Management Server: HP P6000 Command View (earlier known as HP StorageWorks HP P6000 Command View). This software component allows you to configure and manage the storage and DR group via a web browser interface. The SMI-S (Storage Management Interface Specification) EVA software provides the interface for the management of P6000/EVA. Metrocluster with Continuous Access EVA P6000 for Linux software uses OpenPegasus WBEM API to communicate with SMI-S to automatically manage the DR Groups that are used in the application packages. 10 Introduction

11 2 Configuring an application in a Metrocluster environment Installing the necessary hardware and software When the following procedures are complete, an adoptive node will be able to access the data belonging to a package after it fails over. Setting up the storage hardware 1. Before you configure this product, you must correctly cable the P6000/EVA with redundant paths to each node in the cluster that will run packages accessing data on the array. 2. Install and configure the hardware components of the P6000/ EVA, including HSV controllers, disk arrays, SAN switches, and Management Server. 3. Install and configure HP P6000 Command View and SMI-S EVA on the Management Server. For the installation and configuration process, see the HP P6000 Command View Installation Guide. Installing the necessary software Before you configure a Metrocluster, make sure the following software is installed on all nodes: Serviceguard for Linux A or later Metrocluster with Continuous Access EVA P6000 for Linux See the Release Notes and Compatibility and Feature Matrix available at go/linux-serviceguard-docs for the latest patches available for the above mentioned software. Creating the cluster NOTE: The file /etc/cmcluster.conf contains the mappings that resolve symbolic references to $SGCONF, $SGROOT, $SGLBIN, etc. used in the pathnames in the following subsections. If the Serviceguard variables are not defined on your system, then include the file /etc/ cmcluster.conf in your login profile for the root user. For more information on these parameters, see Understanding the Location of Serviceguard Files and Enabling Serviceguard Command Access in Managing HP Serviceguard A for Linux available at linux-serviceguard-docs. Create a Serviceguard cluster with components on multiple sites according to the process described in the Managing HP Serviceguard A for Linux available at linux-serviceguard-docs. NOTE: A configuration with a Lock Lun is not supported in a Metrocluster environment. Site Aware Failover Configuration Serviceguard cluster allows sites to be configured in a Metrocluster environment. The Serviceguard cluster configuration file includes the following attributes shown in Table 1 (page 11) to define sites. This enables to use the package failover policiessite_preferred_manual or site_preferred for Metrocluster package. Table 1 Site Aware Failover Configuration Attributes SITE_NAME SITE Description To define a unique name for a site in the cluster. SITE keyword under the node's NODE_NAME definition. Installing the necessary hardware and software 11

12 The following is a sample of the site definition in a Serviceguard cluster configuration file: SITE_NAME san_francisco SITE_NAME san_jose NODE_NAME SFO_1 SITE san_francisco... NODE_NAME SFO_2 SITE san_francisco... NODE_NAME SJC_1 SITE san_jose... NODE_NAME SJC_2 SITE san_jose... Use cmviewcl command to view the list of sites that are configured in the cluster and their associated nodes. The following is a sample of the command, and the output: # cmviewcl -l node SITE_NAME san_francisco NODE STATUS STATE SFO_1 up running SFO_2 up running... SITE_NAME san_jose NODE STATUS STATE SJC_1 up running SJC_2 up running You can configure either of these failover policies for Metrocluster failover packages. To use these policies, you must specify site_preferred or site_preferred_manual for the failover_policy attribute in the Metrocluster package configuration file. NOTE: For a Metrocluster package, HP recommends that you set the failover_policy parameter to site_preferred. Setting up the replication Creating VDISKs and DR groups using HP P6000 command view The P6000 Command View is a web-based tool to configure, manage, and monitor virtual disks and DR groups as shown in Figure 2 (page 12). Figure 2 P6000/EVA Management Console using HP P6000 Command View For more information on setting up HP P6000 Command View for configuring, managing, and monitoring HP P6000/EVA Storage System, see HP P6000 Command View User Guide available 12 Configuring an application in a Metrocluster environment

13 at -> storage-> Storage Software-> Storage Device Management Software-> HP StorageWorks HP P6000 Command View Software. Using the Command View (CV) web user interface create VDISKS, create DR GROUP using the VDISKS and present those VDISKS to the connected host. After a DR group is created set the destination host access field as Read only using Command View GUI. NOTE: In the Metrocluster environment, it is required that the destination volume access mode of the DR group be set to Read only mode. In some earlier Command View software versions, when a DR group is created, only the source volume (primary volume) is visible and accessible with Read/Write mode. The destination volume (secondary volume) by default is not visible and accessible to its local hosts. The destination volume access mode needs to be changed to Read only mode before the DR group can be used and the destination volumes need to be presented to its local hosts. Using Storage System Scripting Utility (SSSU) HP Storage System Scripting Utility (SSSU) is a utility to manage and monitor HP P6000/EVA storage array. Using SSSU you can create VDISKS and DR groups to use with Metrocluster packages. For more information about SSSU commands, see the sample input file available at: $SGCONF/mccaeva/Samples/sssu_sample_input The contents of sample input file are listed below. In the following sample file, DC-1 is the name of the source array. select manager user=administrator pass=administrator select system DC-1 set DR_GROUP \Data Replication\DRG_DB1 accessmode=readonly ls DR_GROUP \Data Replication\DRG_DB1 After you create the VDISKS and DR groups, run the following steps when copying and editing the sample input file: 1. Copy the sample file sssu_sample_input to the desired location. # cp $SGCONF/mccaeva/Samples/sssu_sample_input <desired location> 2. Customize the file sssu_sample_input. 3. After you customize the sssu_input file, run the SSSU command as follows to set the destination Vdisk to read-only mode. # /sbin/sssu FILE <sssu_input_file> 4. To create the special device file name for the Vdisk on P6000/EVA, after changing the access mode of the destination Vdisk, run the /usr/bin/rescan-scsi-bus.sh command to detect and activate the disks, and then run lsscsi command to display the configured disks. NOTE: The lsscsi command is available in lssci package available in the respective OS repository. Creating the Metrocluster with Continuous Access EVA P6000 for Linux Map for the replicated storage The mapping file caeva.map is required to be present in all the cluster nodes for the Metrocluster with Continuous Access EVA P6000 for Linux product to function. The mapping file caeva.map contains information of the Management Servers as well as the information of the HP P6000/EVA Storages and DR Groups used in the Metrocluster environment. The Metrocluster with Continuous Access EVA P6000 for Linux product provides two utility tools, smispasswd and evadiscovery, for users to provide information about the SMI-S servers running Setting up the replication 13

14 on the Management Servers and DR groups that will be used in Metrocluster environment. These tools must be used to create or modify the map file caeva.map. This product provides two utility tools for users to provide information about the SMI-S service running on the Management Servers and DR groups that will be used in Metrocluster environment. smispasswd Metrocluster retrieves storage information from the SMIS-Server for its startup or failover operations. To contact the SMIS-server, it requires SMIS Server's hostname/ip address, username/password, and port number. This information must be available in caeva.map file before you configure any Metrocluster packages. The smispasswd utility, packaged along with Metrocluster must be used to create or edit this map file with the above SMI-S server login information. evadiscovery When querying HP P6000/EVA storage states through the SMI-S, Metrocluster first needs to find the internal device IDs. This process takes time. However, this process need not be repeated because the IDs are static in the P6000/EVA system. This information is cached in the caeva.map file to improve package startup time. To cache the internal device IDs, run the evadiscovery tool after the P6000/EVA and HP P6000 Continuous Access are configured, and the storage is accessible from the hosts. The tool queries the active Management Server for the needed information, and then saves it in caeva.map. Once the map file is created, it is necessary to distribute it to all the cluster nodes to communicate with the HP P6000/EVA units. Defining Management Server and SMI-S information To define Management Server and SMI-S information use the smispasswd tool. The following steps describe the options for defining Management Server and SMI-S information: Creating the Management Server list On a host that resides on the same data center as the active management server, create the Management Server list using an input file. To create use the following steps: 1. Create a configuration input file. A template of this file is available at the following location for Red Hat and SUSE. For an example of the smiseva.conf file, see smiseva.conf file (page 40). The smiseva.conf is available at: $SGCONF/mccaeva/smiseva.conf 2. Copy the template file smiseva.conf to the desired location. # cp $SGCONF/cmcaeva/smiseva.conf <desired location> 3. For each Management Server in your configuration (both local and remote sites), enter the Management Server s hostname or IP address, the administrator login name, type of connection (secure or non-secure), SMI-S name space and SMI-S port. Creating the Management Server Mapping file Use the smispasswd command to create or modify the Management Server information stored in the mapping file. For each Management Server listed in the file, a password prompt is displayed. A username and password is created by your system administrator when the Management Server is configured because of the security protocol for P6000/EVA. Enter the password associated with the username of the SMI-S, and then re-enter it (as prompted) to verify that it is correct. # smispasswd -f <desired location>/smiseva.conf Enter password of <hostname1/ip_address1>: ********** Re-enter password of <hostname1/ip_address1>: ********** Enter password of <hostname2/ip_address2>: ********** 14 Configuring an application in a Metrocluster environment

15 Re-enter password of <hostname2/ip_address2>: ********** All the Management Server information has been successfully generated. NOTE: The desired location is where the modified smiseva.conf file is located. For more information on configuring the username and password for SMI-S on the management server, see the HP P6000 Command View Installation Guide. After the passwords are entered, the configuration is written to the caeva.map map file located at: $SGCONF/mccaeva Setting a default Management Server Use the smispasswd command to set the active Management Server that will be used by evadiscovery tool. For Example: # smispasswd -d <hostname/ip_address> The Management Server <hostname/ip_address> is set as the default active SMI-S. Displaying the list of Management Servers Use the smispasswd command to display the current list of storage management servers that are accessible by the cluster software. Example: # smispasswd -l MC/CAEVA Server list: HOST USERNAME USE_SSL NAMESPACE Host1:Port administrator N root/eva Host2:Port administrator N root/eva Adding or updating Management Server information To add or update individual Management Server login information to the map file, use the following command options shown in Table 2: smispasswd -h <hostname/ip_address> -n <namespace> -p <port> -u <user_name> -s <y n> Table 2 Individual Management Server information Command Options -h <hostname/ip_address> -n <namespace> -p <port> -u <user_name> -s <y n> y n Description This is either a DNS resolvable hostname or IP address of the Management Server This is the name space configured for the SMI-S CIMOM 1. The default namespace is root/eva. This is the port on which the SMI-S server listens. This attribute is optional and is used when SMI-S server does not listen on the default ports. This is the user name used to connect to SMI-S. The user name and password is the same as those used with the sssu tool. This option specifies the type of connection needed to be established between Metrocluster software and the SMI-S CIMOM. This option allows secure connection to Management Server using the HTTPS protocol (HTTP using Secure Socket Layer encryption). This option means a secure connection is not required. Setting up the replication 15

16 1 CIMOM - Common Information Model Object Manager, a key component that routes information between providers and clients. This command adds a new record if it does not find the <hostname/ip_address> in the mapping file. Otherwise, it only updates the record. For Example: # smispasswd -h <hostname/ip_address> -u administrator -n root/eva -s y Enter password: ********** Re-enter password: ******** A new information has been successfully created Deleting a Management Server To delete a Management Server from the group used by the cluster, use the smispasswd command with -r option. Example: # smispasswd -r <hostname/ip_address> The Management Server <hostname/ip_address> has been successfully removed from the file Defining HP P6000/EVA Storages cells and DR groups On the node where access to SMI-S server is configured, define the HP P6000/EVA Storages and DR Groups information to be used in the Metrocluster environment. The Metrocluster software requires the internal device IDs to query the HP P6000/EVA storage states. The evadiscovery tool is a Command Line Interface (CLI) that provides functions for defining P6000/EVA storage cells and DR group information. The tool caches the internal device IDs in the caeva.map file by querying and searching for a list of devices information. This type of caching improves the performance when querying HP P6000/EVA storage states through the SMI-S whenever required. To use the evadiscovery tool: 1. Create a configuration input file. This file will contain the names of storage pairs and DR groups. A template of configuration input file is available at the following location for Red Hat and SUSE. $SGCONF/mccaeva/mceva.conf 2. Copy the template file to the desired location. $SGCONF/mccaeva/mceva.conf <desired location> 3. For each pair of storage units, enter the WorldWideName (WWN). The WWN is available on the front panel of the P6000/EVA controller or from the HP P6000 Command View user interface. 4. For each pair of storage units, enter the names of all DR groups that are managed by that storage pair. 5. Save the file. Creating the Storage Map file After completing the HP P600/EVA Storages and DR Groups configuration file, use the evadiscovery utility to create or modify the storage map file. # evadiscovery -f <desired location>/mceva.conf Verifying the storage systems and DR Groups... Generating the mapping data... Adding the mapping data to the file /opt/cmcluster/conf/mccaeva/caeva.map... The mapping data is successfully generated. 16 Configuring an application in a Metrocluster environment

17 NOTE: The desired location is where you have placed the modified mceva.conf file. The command generates the mapping data and stores it in caeva.map file. The mapping file caeva.map contains information of the Management Servers and information of the HP P6000/EVA storage cells and DR Groups. Displaying information about storage devices Use the evadiscovery command to display information about the storage systems and DR groups in your configuration. For example: # evadiscovery -l MC EVA Storage System and DR Groups map list: Storage WWN: 50001FE15007DBA0 DR Group Name: \Data Replication\drg_cc DR Group Name: \Data Replication\drg_1 Storage WWN: 50001FE15007DBD0 DR Group Name: \Data Replication\drg_cc DR Group Name: \Data Replication\drg_1 NOTE: Run the evadiscovery tool after all the storage DR Groups are configured or when there is any change to the storage device. For example, the user removes and recreates a DR group that is used by an application package. In this case the DR Group's internal IDs are regenerated by the P6000/EVA system. If any name of storage systems or DR groups is changed, update the external configuration file, run the evadiscovery utility, and redistribute the map file caeva.map to all Metrocluster clustered nodes. Before running the evadiscovery command, the management server configuration must be completed using the smispasswd command, else the evadiscovery command fails. Copying the Map file After running the smispasswd and evadiscovery commands to generate the caeva.map file, copy this file in the same location to all cluster nodes so that the map file can be used by this product to communicate with the storage arrays. Copy the caeva.map file to all nodes in the cluster. # scp $SGCONF/mccaeva/caeva.map node:$sgconf/mccaeva/caeva.map Similarly, whenever new Management Servers are added or the existing Server credentials are changed, generate and redistribute the map file to all Metrocluster clustered nodes. Configuring volume groups This section describes the required steps to create a volume group for use in a Metrocluster environment. To configure volume groups, you must first identify the device special files for the source and target VDisks in the DR Group. After that, create volume groups for source volumes, export them for access by other nodes and import them on all other cluster nodes. Identify the device special files for Vdisk in DR group To configure volume groups, you must get the device special files for the DR Group's source and target VDisks on nodes in both the sites. See the Identifying the devices to be used with packages (page 43) for identifying device filenames for Vdisks. Configuring volume groups 17

18 NOTE: While using Cluster Device Special Files (cdsf) feature, the device special file name is same on all nodes for a source and target VDisk. Identifying special device files The following is the sample output of the evainfo command on Linux environment. Table 3 evainfo command output # evainfo d /dev/sdj Devicefile Array WWNN Capacity Controller/Port/Mode /dev/sdj FE DBA B F MB Ctl-B/FP 4/NonOptimized For more information on using the evainfo tool, see HP P6000 Evainfo Release Notes. Use HP P6000 Command View to identify the WWN for a Vdisk. The HP P6000 Command View for the WWN Identifier of the Vdisk is shown in Figure 3. Figure 3 P6000 Command View for the WWN identifier Configuring LVM volume group using Metrocluster with Continuous Access EVA P6000 for Linux LVM storage can be used in Metrocluster. The following section show how to set up LVM volume group. Before you create volume groups, you can create parttions on the disks and must enable activation protection for logicalvolume groups, preventing the volume group from being activated by more than one node at the same time. For more information on creating partitions and enabling activation protection for logical volume groups, see Managing HP Serviceguard A for Linux available at Creating LVM volume groups To create volume groups: 1. Create LVM physical volumes on each LUN. # pvcreate -f /dev/sda1 2. Create the volume group on the source volume. # vgcreate --addtag $(uname -n) /dev/<vgname> /dev/sda1 3. Create the logical volume. (XXXX indicates size in MB). # lvcreate -L XXXX /dev/<vgname> 4. Create a file system on the logical volume. # mke2fs -j /dev/<vgname>/rlvol1 18 Configuring an application in a Metrocluster environment

19 5. If required, deactivate the Volume Groups on the primary system and remove the tag. # vgchange -a n <vgname> # vgchange --deltag $(uname -n) <vgname> NOTE: Use the vgchange --deltag command only if you are implementing volume-group activation protection. Remember that volume-group activation protection if implemented, must be done on every node. 6. Run the vgscan command on all the nodes to make the LVM configuration visible, and to create the LVM database. # vgscan 7. On the source disk site, run the following commands on all the other systems that might run the Serviceguard package. If required, take a back up of a LVM configuration. # vgchange --addtag $(uname -n) <vgname> # vgchange -a y <vgname> # vgcfgbackup <vgname> # vgchange -a n <vgname> # vgchange --deltag $(uname -n) <vgname> 8. To verify the Volume Group configuration on the target disk site. To failover the DR group: a. Select the remote storage system from the HP P6000 Command View. b. Select the desired destination disaster Recovery group, and then click Fail Over. This makes the destination VDisk as SOURCE. 9. On the target disk site, run the following commands on all the systems that might run the Serviceguard package. If required, take a back up of a LVM configuration. # vgchange --addtag $(uname -n) <vgname> # vgchange -a y <vgname> # vgcfgbackup <vgname> # vgchange -a n <vgname> # vgchange --deltag $(uname -n) <vgname> 10. To failover the DR group: a. Select the local storage system from the HP P6000 Command View. b. Select the desired destination disaster Recovery group, and then click Fail Over. This makes the destination VDisk as SOURCE. Installing and configuring an application You must replicate only the disks which contain application data and not the disks which contain application binaries and configuration files. The following section describes how to configure a package for the application. Configuring a Metrocluster package To create a Metrocluster modular packages do the following: 1. Run the following command to create a Metrocluster modular package configuration file: # cmmakepkg m dts/mccaeva temp.config If the Metrocluster package uses Oracle Toolkit, then add the corresponding toolkit module. For example, for a Metrocluster Oracle toolkit modular package, run the following command: Installing and configuring an application 19

20 # cmmakepkg -m dts/mccaeva -m tkit/oracle/oracle temp.config NOTE: Metrocluster is usually used with applications such as Oracle. So, the application toolkit module must also be included when Metrocluster is used in conjunction with an application. You must make sure to specify the Metocluster module before specifying the toolkit module. 2. Edit the following attributes in the temp.config file: Table 4 Temp.config file Attributes Attributes dts_pkg_dir DT_APPLICATION_STARTUP_POLICY DR_GROUP_NAME DC1_STORAGE_WORLD_WIDE_NAME DC1_SMIS_LIST DC1_HOST_LIST DC2_STORAGE_WORLD_WIDE_NAME DC2_SMIS_LIST DC2_HOST_LIST Description This is the package directory for this Metrocluster modular package. The Metrocluster Environment file is generated for this package in this directory. This value must be unique for all packages. This is a parameter used to define a policy for starting an application. It can be set to Availability_Preferred or Data_Currency_Preferred policy. This is the name of the DR group used by the package. This is the World Wide Name of the HP P6000/EVA storage system that resides in Data Center 1. This is a list of management servers that reside in Data Center 1. This is a parameter used to specify a list of clustered nodes that reside in Data Center 1. This is the World Wide Name of the P6000/EVA storage system that resides in Data Center 2. This is a list of management servers that reside in Data Center 2. This is a parameter used to specify a list of clustered nodes that reside in Data Center 2. NOTE: The host name specified in DC1/DC2 parameter must match the output of the hostname command. If hostname command displays a fully qualified name, then you must specify the fully qualified name in DC1/DC2 host parameter list. For Example: # hostname host1.domain1.com If hostname command displays only host name, then you must specify the host name in DC1/DC2 parameter list. For Example: # hostname host1 There are additional Metrocluster parameters available in the package configuration file. HP recommends that you retain the default values of these variables unless there is a specific business requirement to change them. For more information on the Metrocluster parameters, see Appendix B (page 38). For the failover_policy parameter, Metrocluster failover packages can be configured to use any of the Serviceguard defined failover policies. The site_preferred and site_preferred_manual failover policies are introduced in Serviceguard specifically for Metrocluster configurations. 20 Configuring an application in a Metrocluster environment

21 The site_preferred value implies that when a Metrocluster package needs to fail over, it fails over to a node in the same site as the node it last ran. If there is no other configured node available within the same site, the package fails over to a node on another site. The site_preferred_manual failover policy provides automatic failover of packages within a site and manual failover across sites. Configure a cluster with sites to use either of these policies. For information on configuring the failover policy to site_preferred or site_preferred_manual, see Site Aware Failover Configuration (page 11). 3. Validate the package configuration file. # cmcheckconf -P temp.config 4. Apply the package configuration file. # cmapplyconf -P temp.config NOTE: If external_pre_script is specified in a Metrocluster package configuration, the external_pre_script is executed after the execution of Metrocluster module scripts in package startup. Metrocluster module scripts are always executed first during package startup. 5. Run the package on a node in the Serviceguard cluster. # cmrunpkg -n <node_name> <package_name> 6. Enable global switching for the package. # cmmodpkg -e <package_name> After the package is created, if the value of any Metrocluster parameter needs to be changed, edit this package configuration file and re-apply it. Setting up Disk Monitoring HP Serviceguard for Linux includes a Disk Monitor which you can use to detect problems in disk connectivity. This lets you fail a package over from one node to another in the event of a disk connectivity failure. For instructions on configuring disk monitoring, see Creating a Disk Monitor Configuration section in Managing HP Serviceguard A for Linux available at linux-serviceguard-docs. Configuring a Metrocluster package using Serviceguard Manager To configure a Metrocluster package using Serviceguard Manager: 1. Access one of the node s System Management Home Page at Log in using the root user s credentials of the node. 2. Click Tools, if Serviceguard is installed, one of the widgets will have Serviceguard as an option. Click Serviceguard Manager link within the widget. 3. On the Cluster s Home Page, click the Configuration Tab, and then select Create A Modular Package. Installing and configuring an application 21

22 Figure 4 Creating modular package 4. If the product Metrocluster with Continuous Access EVA P6000 for Linux Toolkit is installed, you will be prompted to configure a Metrocluster package. Select the dts/mccaeva module, and then click Next. Figure 5 Selecting Metrocluster module 5. You will be prompted next to include any other toolkit modules. In case, application being configured has a Serviceguard toolkit, select the appropriate toolkit; otherwise, move to the next screen. 6. Enter the package name. Metrocluster packages can be configured only as failover packages. Make sure that this option is selected as shown in Figure 6 (page 22) and then click Next. Figure 6 Configuring package name 22 Configuring an application in a Metrocluster environment

23 7. Select additional modules if required by the application. For example, if the application uses LVM volumegroups or VxVM diskgroups, select the volume_group module. Click Next. Figure 7 Selecting additional modules for the package 8. Review the node order in which the package will start, and modify other attributes, if needed. Click Next. Figure 8 Configuring generic failover attributes 9. Configure the attributes for a Metrocluster package. All the mandatory attributes (marked with *) must be accurately filled. a. Select Application start up policy from the list. b. Specify the DR Group name, and then enter values for Wait Time and Query Timeout, if required. c. Select hosts for Data Center 1 and Data Center 2. Enter DC1/DC2 Storage World Wide Names. d. Specify the list of management servers for DC1 and DC2. Installing and configuring an application 23

24 Figure 9 Specifying the list of management servers for DC1 and DC Enter the values for other modules selected in step After you enter the values for all the modules, review all the inputs given to the various attributes in the final screen. If you want to validate the package configuration click on Check Configuration, else click on Apply Configuration. Figure 10 Configuring Metrocluster P6000/EVA parameters 24 Configuring an application in a Metrocluster environment