Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Designing Disaster Tolerant HA Clusters Using Metrocluster and Continentalclusters: > Chapter 4 Building Disaster Tolerant Serviceguard Solutions Using Metrocluster with Continuous Access EVA

Preparing a Serviceguard Cluster for Metrocluster Continuous Access EVA

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

When the following procedures are completed, 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 configuring Metrocluster Continuous Access EVA, the EVA must be correctly cabled 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 EVA, including HSV controllers, disk arrays, SAN switches, and Management Server.

  3. Install and configure CV EVA and Storage Management Interface Specification (SMI-S) on the Management Server. For the installation and configuration process, refer to the HP StorageWorks Continuous Access EVA Installation Guide.

  4. Start CV EVA User Interface (CV EVA-UI). The interface is accessed by launching a web browser from a client and connect to the Command View EVA. Next select the “Command View EVA”, to access the Command View EVA for Configuration of virtual disks and DR groups shown in Figure 4-1 “Configuration of Virtual Disks and DR groups”.

    Figure 4-1 Configuration of Virtual Disks and DR groups

    Configuration of Virtual Disks and DR groups

    For more detailed information on setting up Command View EVA for configuring, managing and monitoring your HP StorageWorks Enterprise Virtual Array Storage System, refer to the HP StorageWorks Command View EVA Getting Started Guide (part number: AA-RQZBE-TE).

After 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. The destination volumes need to be presented to its local host.

NOTE: In the Metrocluster Continuous Access EVA environment, it is required that the destination volume access mode be set to read-only mode.

The destination Vdisk read-only mode can be changed by using the SSSU command for HP-UX. When executing the SSSU command, it needs to be executed against the storage cell that holds the source Vdisk of the DR group.

For users who are not familiar with the SSSU command, an input sample file is provided below and in the following location: /opt/cmcluster/toolkit/SGCAEVA/Samples/sssu_sample_input.

select mananager 15.13.244.182 user=administrator pass=administratorselect system DC-1set DR_GROUP “\Data Replication\DRG_DB1” accessmode=readonlyshow DR_GROUP “\Data Replication\DRG_DB1”
NOTE: For more detailed information on the sssu commands used in the sample input file, refer to the sssu ReadMe file found at /opt/cmcluster/toolkit/SGCAEVA/Samples/Readme.sssu_sample_\ input

Follow the steps below when copying and editing the sample file:

  1. Copy the sample file /opt/cmcluster/toolkit/SGCAEVA/Samples/sssu_sample_input to the /etc/dtsconf/ directory.

    # cp /opt/cmcluster/toolkit/SGCAEVA \
    /Samples/sssu_sample_input/etc/dtsconf/sssu_input

  2. Customize the file sssu_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 <input_file>”

  4. After changing the access mode of the destination Vdisk, it is necessary to run the ioscan command and the insf command on remote clustered nodes to create the special device file name for the destination Vdisk on remote EVA.

Cluster Configuration

For detailed information on Serviceguard cluster configuration, refer to the Managing Serviceguard user’s guide. The following information pertains to cluster configuration in a EVA Continuous Access environment. First create a Serviceguard cluster without specifying cluster-aware volume groups in the cluster configuration ASCII file. This is necessary because the LUNs in the EVA storage units are not read/write to all cluster nodes at configuration time. Only the LUNs configured as source volumes are read/write on one cluster site. The remote site can see those LUNs with read-only mode and therefore, the cmapplyconf command cannot succeed if volume groups are specified in the file. Volume groups are created and made cluster aware in separate steps, shown in the “Configuring Volume Groups” of this chapter.

NOTE: If your ASCII file contains volume group definitions derived from the LUNs visible on the source node, comment them out before running the cmapplyconf command.

Management Server/SMI-S and DR Groups Configuration

The Metrocluster Continuous Access EVA product provides two utility tools for users to provide Metrocluster Continuous Access EVA software the information about the SMI-S EVA service running on the Management Servers and DR groups that will be used in Metrocluster Continuous Access EVA environment.

This section discusses the smispasswd and evadiscovery tools, including the description of the tools, the tool operations, and the input file templates.The first utility, called smispasswd, is a Command Line Interface (CLI) that provides functions for defining Management Server list and SMI-S username and password pair. The second utility, called evadiscovery, is also a CLI that provides functions for defining EVA storage cells and DR group information.

When Metrocluster Continuous Access EVA program requests a storage state, it sends a request message to a local Management Server. For preparing the message, several data items need to be available so that the Metrocluster Continuous Access EVA program knows which Management Server it will communicate with. These data items include Management Server's hostname/IP address, and SMI-S username/password. Before configuring and bringing up any Metrocluster package, this is the first information that needs to be configured.

Metrocluster software communicates with the SMI-S service running on the Management Server, which communicates with the EVA controller. When querying EVA storage states through the SMI-S, the code first needs to find the internal device IDs by querying and searching for a list of devices information. These processes take time and are not necessary since the IDs are static in the EVA system. To improve the query performance, the software will cache these IDs in the clustered nodes.

To cache the object IDs in the clustered nodes, it is required to run the evadiscovery tool after the EVA and Continuous Access EVA are configured, and the storage is accessible from the hosts. The tool will query the active Management Server for the needed information and save it in a mapping file. It is necessary to distribute the mapping file to all the clustered nodes.

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, use the following steps:

  1. Create a configuration input file (A template of this file can be found in /opt/cmcluster/toolkit/SGCAEVA/smiseva.conf).

  2. Copy the template file /opt/cmcluster/toolkit/SGCAEVA/smiseva.conf to the /etc/dtsconf/ directory.

    # cp /opt/cmcluster/toolkit/SGCAEVA/smiseva.conf \ /etc/dtsconf/smiseva.conf

  3. For each Management Server in your configuration (both local and remote sites), enter the Management Server’s hostname or IP address, the SMA administrator login name, type of connection (secure or non-secure), and SMI-S name space configured in the SMI-S service property file.

An example of the smiseva.conf file is as follows:

##############################################################
# #
# smiseva.conf CONFIGURATION FILE (template) #
# for use with the smispasswd utility #
# in the Metrocluster Continuous Access #
# EVA Environment #
# Note: This file MUST be edited before it can be used. #
# For complete details about Management Server/SMI-S # # configuration #
# for use with Metrocluster Continuous Access EVA, consult the manual #
# “Designing Disaster Tolerant High Availability Clusters.”#
# #
##############################################################
#
# This file provides input to the smispasswd utility, which you
# use to set up secure access paths between cluster nodes and
# SMI-S services.
#
# Edit this file to include the appropriate information about
# the SMI-S services that will be used in your Metrocluster Continuous Access
# EVA environment.
#
# After entering all the desired information, run the # smispasswd
# command to generate the security configuration that allows
# cluster nodes to communicate with the SMI-S services.
#
# Below is an example configuration. The data is commented out.
#
# Hostname/IP_Address User_login_name Secure     Namespace
# IP_Address                         Connection
# ------------------- --------------- ---------- --------
# 15.13.244.182 administrator y         root/EVA
# 15.13.244.183 administrator    y         root/EVA
# 15.13.244.192 admin12309       y         root/EVA
# SANMA04       admin            y         root/EVA
#
# The example shows a list of 4 Management Server/SMI-S data in # the Metrocluster
# Continuous Access EVA environment. Each line represents a different SMI-S’s # data;
# fields on each line should be separated either by space(s)
# or tab(s). The order of fields is significant. The first # field
# must be a hostname or IP address, the second field must be
# a user login name on the host. The third field must be ‘y’ or
# ‘n’ to use SSL connect. The last field must be the namespace
# of the SMI-S service.For details of each field data, refer to
# the smispasswd man page, ‘man smispasswd’.
#
#
# Note:
# Lines beginning with the pound sign (#) are comments. You # cannot
# use the ‘#’ character in your data entries.
#
# Enter your SMI-S services data under the dashed lines:
#
# Hostname/IP_Address User_login_name Secure       Namespace
# IP_Address                            Connection
# ------------------- --------------- ----------   --------
15.13.172.11 administrator    n           root/EVA
15.13.172.12 administrator     n            root/EVA

Fill in the Management Server information for each Management Server in your cluster configuration and make sure to place the active Management Server information first on the list.

NOTE: If the secure connection field is set to ‘Y’, SMI-S service must also be configured to use SLL via the SMS-S service property file. For more detailed information, see the SMI-S configuration guide.

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, there will be a password prompt displayed. A username and password are required because of the security protocol for EVA and is created by your system administrator when the Management Server is configured. Input the password associated with the username of the SMI-S. Then, re-enter it (as prompted) to verify that it is correct. Example:

# smispasswd -f /etc/dtsconf/smiseva.conf

NOTE: The username and password stored in the mapping file are the same as the username and password used with the SSSU tool.
Enter password of 15.13.172.11: **********
Re-enter password of 15.13.172.11: **********
Enter password of 15.13.172.12: **********
Re-enter password of 15.13.172.12: **********
All the Management Server information has been successfully generated.

When all the passwords have been entered, the configuration is written to the map file /etc/dtsconf/caeva.map.

Setting a Default Management Server

Use the smispasswd command to set the active Management Server that is to be used by EVA discovery tool, which will be discussed later in the section. Example:

# smispasswd -d 15.13.172.12

The MA 15.13.172.11 has been 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 appliances that are accessible by the cluster software. Example:

# smispasswd -l

MC/CAEVA Server list:
HOST                   USERNAME       USE_SSL     NAMESPACE
------------------------------------------------------------
15.13.172.11           administrator     N        root/EVA
15.13.172.12           administrator     N        root/EVA

Adding or Updating Management Server Information

To add or update individual Management Server information, use the following command options shown in Table 4-2 “Individual Management Server Information”:

smispasswd -h <hostname/ip_address> -n <namespace> -u <user_name> -s <y|n>

Table 4-2 Individual Management Server Information

Command OptionsDescription
-h <hostname/ip_address>This is either a DNS resolvable hostname or IP address of the Management Server
-n <namespace>This is the name space configured for the SMI-S CIMOM. Detail information on how to configure the name space for SMI-S CIMOM can be found in the SMI-S Installation Instructions document. the default namespace is root/EVA.
-u <user_name>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.
s <y|n>

This option specifies the type of connection needed to be established between Metrocluster software and the SMI-S CIMOM.

“y”

This option means a secure connection is required. Choosing this option means the user had configured the SMI-S CIMOM to accept secure connection request using Secure Socket Layer (SSL) protocol. Detail information on how to configure SSL on the SMI-S CIMOM can be found in the SMI-S user guide.

“n”

This option means a secure connection is not required.

 

When you issue the command with these options, the “Enter password:” will prompt you to input the password associated with the username. After inputting a password and issuing the command, the “Re-enter password:” request will prompt you to re-enter the same password again for verification.

Subsequently, this command will either add new or update the existing Management Server information to the map file. In addition, this command will add a new record if it does not find the <hostname/ip_address> in the mapping file. Otherwise it only updates the record.

Examples:

% smispasswd  -h 15.13.244.202 -u administrator -n root/EVA -s yEnter password: **********Re-enter password: ********A new information has been successfully created%% smispasswd  -h 15.13.244.203 -u administrator -n root/EVA -s nEnter password: **********Re-enter password: ********A new information has been successfully created%% smispasswd  -h 15.13.244.202 -s nEnter password: **********Re-enter password: ********The information has been successfully updated%

Deleting a Management Server

To delete a Management Server from the group used by the cluster, use the smispasswd command with the -r option. Example:

# smispasswd -r 15.13.172.12

The Management Server 15.13.172.11 has been successfully removed from the file

Defining EVA Storage Cells and DR Groups

On the same node, which the management server list was created, define the EVA storage cells and DR Groups information to be used in the Metrocluster Continuous Access EVA environment, and use the evadiscovery tool with the following steps:

  1. Create a configuration input file. This file will contain the names of storage pairs and DR groups. (A template of this file can be found in /opt/cmcluster/toolkit/SGCAEVA/mceva.conf)

  2. Copy the template file /opt/cmcluster/toolkit/SGCA EVA/mceva.conf) to the /etc/dtsconf directory:

    # cp /opt/cmcluster/toolkit/SGCAEVA/mceva.conf \ /etc/dtsconf/mceva.conf

  3. For each pair of storage units, enter the WorldWideName (WWN) of the first and second storage units. The WWN can be found on the front of the panel of the EVA controller.

  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.

The following is an example of the mceva.conf file.

Fill in the file as in the following example:

###############################################################           mceva.conf CONFIGURATION FILE (template)          #
# for use with the evadiscovery utility #
# in the Metrocluster Continuous Access EVA Environment. #
# #
# Version: A.01.00   #
# #
# Note: This file MUST be edited before it can be used. #
# For complete details about EVA configuration for use #
# with Metrocluster Continuous Access EVA, consult the manual #
# “Designing Disaster Tolerant High Availability Clusters” #
# #
##############################################################
#
# This file provides input to the evadiscovery utility, which
# you use to generate the /etc/dtsconf/caeva.map file. During
# Metrocluster Continuous Access EVA configuration, this file is copied to
# all cluster nodes.
#
# Edit the file to include the appropriate data about the EVA
# storage systems and DR groups that will be used in your
# Metrocluster Continuous Access EVA environment.
#
# After entering all the desired information, run the # evadiscovery
# command to generate the mapping data and save it in a map # file.
#
# Note: Before running evadiscovery, you need to use the
# smispasswd command to create a SMI-S services configuration.
#
# Enter the data for storage device pairs and DR groups after
# the <storage_pair_info> and <dr_group_info> tags. The
# <storage_pair_info> tag represents the starting definition
# of a storage pair and its DR groups. Under a # <storage_pair_info>
# tag, you must provide two storage Node World Wide Name (WWN)
# which both contain the DR groups defined under the # <dr_group_info>
# tag. You can define as many DR groups as you need, but each # DR
# group must belong to only one of the storage pairs. A storage
# pair can have a maximum of 64 DR groups.
#
# Note that you can find storage Node World Wide Names form the
# front panel of your EVA controllers or from the ‘Initialized
# Storage Properties’ page of command view EVA through your Web
# browser.
#
# Below is an example of a configuration with two storage pairs
#(4 storage units). The first storage pair contains 2 DR groups
# and the second pair contains 1 DR group.
#
#
# <storage_pair_info>
# “5000-1FE1-5000-4280” Enter first storage WWN in double # quotes.
# “5000-1FE1-5000-4180” Enter second storage WWN in double # quotes.
# <dr_group_info>
# “DR Group - Package1” Enter a DR group name in double # quotes.
# “DR Group - OracleDB1” Enter a DR group name in double # quotes.
#
# <storage_pair_info>
# “5000-1FE1-5000-4081” Enter first storage WWN in double # quotes.
# “5000-1FE1-5000-4084” Enter second storage WWN in double # quotes.
# <dr_group_info>
# ”DR Group - Package2” Enter a DR group name in double quotes.
#
# Note:Since ‘#’ meant a start of a comment, you cannot include
# the ‘#’ in any <storage_pair_info>, <dr_group_info>, storage
# name and DR group name.
#
# Note: All the storage and DR Group names should be enclosed
# in double quotes (““), otherwise the evadiscovery command
# will not detect them.
#
# Enter your MC EVA Storage pairs and DR Groups under the # dashed lines:
# --------------------------------------------------------------
<storage_pair_info>
#
“5000-1FE1-5000-00DF”
“5000-1FE1-5000-00DE”
#
<dr_group_info>
#
“DR Group 1”
“DR Group 2”
“DR Group 3”
“DR Group 4”

Creating the Storage Map File

After completing the EVA Storage Cells and DR Groups configuration file, use the EVA discovery utility to create or modify the storage map file stored on the configuration node.

# evadiscovery -f /etc/dtsconf/mceva.conf

% Verifying the storage systems and DR Groups .........
Generating the mapping data ............
Adding the mapping data to the file /etc/dtsconf/caeva.map .........
The mapping data is successfully generated.

The command generates the mapping data and stores it in /etc/dtsconf/caeva.map

The mapping file /etc/dtsconf/caeva.map contains information of the Management Server’s as well as information of the EVA Storage Cells and DR Groups.

Copying the Storage Map File

After running the smispasswd and evadiscovery commands to generate the /etc/dtsconf/caeva.map file, copy this file to all cluster nodes so that they can be used by Metrocluster Continuous Access EVA to communicate with the EVA units. Be sure to use the same full pathname.

Displaying Information about Storage Devices

Use the evadiscovery command to display information about the storage systems and DR groups in your configuration. Example:

# evadiscovery -l

% MC EVA Storage Systems and DR Groups map list:
Storage WWN: 5000-1FE1-5000-4280
DR Group Name: DR Group - PkgA
DR Group Name: DR Group - PkgB

Storage WWN: 5000-1FE5-5000-4288
DR Group Name: DR Group - PkgA
DR Group Name: DR Group - PkgB
NOTE: Before running the evadiscovery command, the SMA configuration must be completed using the smispasswd. Otherwise, the evadiscovery command, will fail.Run the discovery tool after all 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 EVA system. Update the external configuration file if any name of storage systems or DR groups is changed, run the evadiscovery utility, and redistribute the map file /etc/dtsconf/caeva.map to all Metrocluster clustered nodes.

Verifying the EVA Configuration

Use the following checklist to verify the configuration.

Figure 4-2  EVA Configuration Checklist

EVA Configuration Checklist

Configuring Volume Groups

This section describes the required steps to create a volume group for use in a Metrocluster Continuous Access EVA environment.

Identifying Special Device File Name for Vdisk in DR Group using Secure Path V3.0D or V3.0E

For each Vdisk in a DR group use CV EVA to retrieve its own unique World Wide Name (WWN) identifier. To identify the special device file name for the matching WWN identifier in a single clustered node use:
# spmgr display

Below is a sample output after running the spmgr command:

TGT/LUN      Device    WWLUN_ID       H/W_Path                      #_Paths
0/ 3         c12t0d3   6000-1FE1-0016-6C30-0009-2030-2549-000A      4
                                             255/0.0.3
Controller   Path_Instance            HBA                           Preferred?
Path_Status
      ZG20302549                                                    no
             c4t0d4                   td1                           no Active
             c10t0d4                  td3                           no Available
Controller   Path_Instance            HBA                           Preferred?
Path_Status
      ZG20400420                                                    no
             c6t0d4                   td1                           no Standby
             c8t0d4                   td3                           no Standby

0/ 4         c12t0d4   6000-1FE1-0016-6C30-0009-2030-2549-000E      4
                                             255/0.0.4
Controller   Path_Instance            HBA                           Preferred?
Path_Status
      ZG20302549                                                    no
             c4t0d3                   td1                           no Active
             c10t0d3                  td3                           no Available
Controller   Path_Instance            HBA                           Preferred?
Path_Status
      ZG20400420                                                    no
             c6t6d3                   td1                           no Standby
             c8t6d3                   td3                           no Standby

From the output file, look for the special device file name that corresponds to the WWN identifier of the Vdisk in the DR group. Use the special device file while creating the volume group, which is described in section, “Creating Volume Groups using Source Volumes for Secure Path v3.0D, v3.0E, and v3.0F”. The EVA Command View for the WWN Identifier of the Vdisk is shown in Figure 4-3 “EVA Command View for the WWN Identifier”.

Figure 4-3 EVA Command View for the WWN Identifier

EVA Command View for the WWN Identifier

For more detailed information on setting up Command View EVA for configuring, managing, and monitoring your HP StorageWorks Enterprise Virtual Array Storage System, refer to the HP StorageWorks Command View EVA Getting Started Guide (part number: AA-RQZBE-TE).

Identifying Special Device Files using Secure Path v3.0F

As described in the previous section, for each Vdisk in a DR group, use CV EVA to retrieve its own unique World Wide Name (WWN) identifier. When Secure Path v3.0F is used for path failover capabilities all the paths to the vdisk are visible. To identify the special device file names for the matching WWN identifier.

# autopath display

Below is a sample output after running the autopath command:

==================================================================

HPswsp Version : A.3.0F.00F.00F

==================================================================
Array WWN : 5000-1FE1-5000-2EE0

==================================================================
Lun WWN : 6005-08B4-0010-0E01-0001-B000-0287-0000
Load Balancing Policy : No Load Balancing
==================================================================
Device Path Status
==================================================================
/dev/dsk/c3t0d1 Active
/dev/dsk/c9t0d1 Active
/dev/dsk/c15t0d1 Active
/dev/dsk/c21t0d1 Active
/dev/dsk/c4t0d1 Active
/dev/dsk/c10t0d1 Active
/dev/dsk/c16t0d1 Active
/dev/dsk/c22t0d1 Active

==================================================================
Lun WWN : 6005-08B4-0010-0E01-0001-B000-028E-0000
Load Balancing Policy : No Load Balancing
==================================================================
Device Path Status
==================================================================
/dev/dsk/c3t0d2 Active
/dev/dsk/c9t0d2 Active
/dev/dsk/c15t0d2 Active
/dev/dsk/c21t0d2 Active
/dev/dsk/c4t0d2 Active
/dev/dsk/c10t0d2 Active
/dev/dsk/c16t0d2 Active
/dev/dsk/c22t0d2 Active

From the output display identify the device file listing that corresponds with the WWN of the vdisk in the DR group.

In the above sample listing there are eight device files that correspond to different paths of the same vdisk. Use any one of the device file names while creating a volume group, which is described in section, “Creating Volume Groups using Source Volumes for Secure Path v3.0D, v3.0E, and v3.0F”. The EVA CV display can be used to identify the WWN for a vdisk.

Identifying Special Device Files for PVLinks Configuration

LVM PVlink feature can be used to handle path failovers to a storage device. The following describes how to identify device files for a Vdisk while setting up volume group using PVlinks. Use the RSM HV Mapper Tool to display the special device files that correspond to the WWN of the vdisk in the DR group with the following command:

# RSM_HV Mapper.pl

Collecting Host Volume info might take time. Please wait.Collecting Host Volume info from mc-node1.cup.hp.com.Collecting Host Volume info from mc-node2.cup.hp.com.Collecting Host Volume info from mc-node3.cup.hp.com.Collecting Host Volume info from mc-node4.cup.hp.com.Collecting Host Volume data done.

See HostVolTable.txt for results.

The HostVolTable.txt output file provides a mapping of the devices file to vdisks for all the hosts that are RSM enabled. In addition, the tool displays the WWID of the vdisk and the storage system to which the vdisk belongs.

In the following sample listing there are eight device files that correspond to different paths to the same vdisk. Use all the device files identified while creating a volume group which is described in section, “Configuring Volume Groups using PVLinks”.

=======================   mc-node1.cup.hp.com    =======================Virtual Disk Name..: \\XL-1\Vdisk001-DRGSynDCNDisk...............: /dev/dsk/c16t0d1Disk...............: /dev/dsk/c17t0d1Disk...............: /dev/dsk/c18t0d1Disk...............: /dev/dsk/c20t0d1Disk...............: /dev/dsk/c12t0d1Disk...............: /dev/dsk/c13t0d1Disk...............: /dev/dsk/c14t0d1Disk...............: /dev/dsk/c15t0d1World Wide Lun ID..: 6005-08b4-0010-203d-0000-6000-0017-0000Virtual Disk Name..: \\XL-1\Vdisk002-DRGSynDCSDisk...............: /dev/dsk/c16t0d5Disk...............: /dev/dsk/c17t0d5Disk...............: /dev/dsk/c18t0d5Disk...............: /dev/dsk/c20t0d5Disk...............: /dev/dsk/c12t0d5Disk...............: /dev/dsk/c13t0d5Disk...............: /dev/dsk/c14t0d5Disk...............: /dev/dsk/c15t0d5World Wide Lun ID..: 6005-08b4-0010-299b-0000-a000-002f-0000                               ................

For more detailed configuration and installation information for the RSM and RSM_HV_Mapper tool, see your HP representative.

Creating Volume Groups using Source Volumes for Secure Path v3.0D, v3.0E, and v3.0F

Use the following procedure to create volume groups for source volumes and export them for access by other nodes.

NOTE: Create volume groups only for source storage on a locally connected EVA unit. To create volume groups for source volumes on EVA unit located at the remote site, it is necessary to log onto a node located at that site before configuring the volume groups.

The sample script mk1VGs in the /opt/cmcluster/toolkit/SGCAEVA/Samples directory can be modified to automate these steps.

  1. Define the appropriate Volume Groups on each node that might run the application package. Use the following commands:

    # mkdir /dev/vgname

    # mknod /dev/vgxx/group c 64 0xnn0000

    where the name /dev/vgxx and the number nn are unique within the cluster.

  2. Create the Volume Groups on source volume. Use the following commands:

    # pvcreate -f /dev/dsk/cxtydz

    # vgcreate /dev/vgname /dev/dsk/cxtydz

  3. Create the logical volume(s) for the volume group.

  4. De-activate the Volume Groups.

    # vgchange -a n /dev/vgname

  5. Start the cluster and clusterize the Volume Groups.

    # cmruncl (if cluster is not already up and running)

    # vgchange -c y /dev/vgname

  6. Test activating the Volume Groups with exclusive option.

    # vgchange -a e /dev/vgname

  7. Create a back-up config file that will contain the cluster ID, having already an ID on disks/luns.

    # vgcfgbackup /dev/vgname

  8. Use the vgexport command with the -p option to export the Volume Groups on the primary system without removing the HP-UX device files.

    # vgexport -s -p -m mapfile /dev/vgname

    Make sure that you copy the map files to all of the nodes. The sample script Samples/ftpit shows a semi-automated way (using ftp) to copy the files. It is necessary to only enter the password interactively.

  9. De-activate the volume group.

    # vgchange -a n /dev/vgname

Configuring Volume Groups using PVLinks

Use the following steps to create volume groups for source volumes using PVLinks and export them for access by other nodes.

NOTE: Create volume groups only for source storage on a locally connected EVA unit. To create volume groups for source volumes on EVA unit located at the remote site, it is necessary to log onto a node located at that site before configuring the volume groups.
  1. Define the appropriate Volume Groups on each node that run the application package with the following commands:

    # mkdir /dev/vgname

    # mknod /dev/vgxx/group c 64 0xnn0000

    where the name /dev/vgxx and the number nn are unique within the cluster.

  2. Create the Volume Groups on the source volume, which uses PVLink for path failover. All the special device files names associated for the vdisk as identified in the section “Identifying Special Device Files for PVLinks Configuration”.
    The following commands are an example of how VG using Pvlink is created for the vdisk identified by WWN 6005-08b4-0010-203d-0000-6000-0017-0000:

    # pvcreate -f /dev/dsk/c16t0d1
    # vgcreate /dev/vgname /dev/dsk/c16t0d1
    # vgextend /dev/vgname /dev/dsk/c17t0d1
    # vgextend /dev/vgname /dev/dsk/c18t0d1
    # vgextend /dev/vgname /dev/dsk/c20t0d1
    # vgextend /dev/vgname /dev/dsk/c12t0d1
    # vgextend /dev/vgname /dev/dsk/c13t0d1
    # vgextend /dev/vgname /dev/dsk/c14t0d1
    # vgextend /dev/vgname /dev/dsk/c15t0d1
  3. De-activate the Volume Groups.

    # vgchange -a n /dev/vgname

  4. Start the cluster and configure the Volume Groups.

    # cmruncl (if cluster is not already up and running)

    # vgchange -c y /dev/vgname

  5. Test the Volume Groups activation with exclusive option.

    # vgchange -a e/dev/vgname

  6. Create a back-up conf file that will contain the cluster ID, already having an ID on disks/luns.

    # vgcfgbackup /dev/vgname

  7. Use the vgexport command with the -p option to export the Volume Groups on the primary system without removing the HP-UX device files.

    # vgexport -s -p -m mapfile /dev/vgname

    Make sure to copy the map files to all of the nodes. The sample script Samples/ftpit shows a semi-automated way (using ftp) to copy the files. Only enter the password interactively.

  8. De-activate the volume group.

    # vgchange -a n /dev/vgname

Importing Volume Groups on Nodes at the Same Site

Use the following procedure to import volume groups on cluster nodes located at the same site as the EVA on which you are doing the Logical Volume Manager configuration. The sample script mk2imports can be modified to automate these steps.

NOTE: Before running vgimport, it is necessary to create the directory under the /dev directory and create the group file.
  1. Define the Volume Groups on all nodes at the same site that will run the Serviceguard package.

    # mkdir /dev/vgname

    # mknod /dev/vgname/group c 64 0xnn0000

  2. Import the Volume Groups on all nodes at the same site that will run the Serviceguard packages.

    # vgimport -vs -m mapfile /dev/vgname

  3. Activate the Volume Groups and back up the configuration.

    # vgchange -a e /dev/vgname

    # vgcfgbackup /dev/vgname

    See the sample script Samples/mk2imports.

  4. De-activate the Volume Groups.

    # vgchange -a n /dev/vgname

NOTE: Exclusive activation must be used for all volume groups associated with packages that use EVA. The design of Metrocluster Continuous Access EVA assumes that only one node in the cluster will have a Volume Group activated at a time.

Importing Volume Groups on Nodes at the Remote Site

Use the following procedure to import volume groups on all cluster nodes located at the site of the remote EVA. The sample script mk2imports can be modified to automate these steps.

  1. Define the Volume Groups on all nodes at the same site that will run the Serviceguard package.

    # mkdir /dev/vgname

    # mknod /dev/vgname/group c 64 0xnn0000

  2. Import the Volume Groups on all nodes at the same site that will run the Serviceguard packages.

    # vgimport -vs -m mapfile /dev/vgname

  3. Verify the Volume Group configuration with the following procedures:

    • From the command view EVA, shown in Figure 4-4 “EVA Command View DR Group Properties” failover the DR group to make it the source on the REMOTE site instead of the destination by following the steps described below:

      1. Select the destination site storage system from the command view EVA.

      2. Next select the desired Disaster Recovery group and click on “Fail Over”.

  4. Activate the Volume Groups and back up the configuration.

    # vgchange -a e /dev/vgname

    # vgcfgbackup /dev/vgname

    See the sample script Samples/mk2imports.

  5. De-activate the Volume Groups.

    # vgchange -a n /dev/vgname

  6. From the command view EVA, failback the SOURCE to its original site.

Figure 4-4 EVA Command View DR Group Properties

EVA Command View DR Group Properties
Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© Hewlett-Packard Development Company, L.P.