The most common Symmetrix configuration used with MetroCluster/SRDF
is a 1 by 1 configuration in which there is a single Symmetrix frame
at each Data Center. This section describes how to set up this configuration
using SymCLI and HP-UX commands. It is assumed that you have already
set up the Symmetrix CLI database on each node as described in the
previous section, "Preparing a Cluster for MetroCluster/SRDF."
A basic 1 by 1 configuration is shown in Figure 4-17 “Mapping HP-UX Device File Names to
Symmetrix Units”,
which is a graphical view of the data in Table 4-6 “Symmetrix Device and HP-UX Device Correlation”.
Creating Symmetrix Device Groups |
 |
A
single Symmetrix device group must be defined
for each package on each node that is connected to the Symmetrix.
The following procedure must be done on each node that may potentially
run the package:
|
| |
|
 | NOTE: The sample scripts mk3symgrps.nodename can be modified to automate these steps. |
|
| |
|
Use the symdg command, or modify the mk3symgrps.nodename script to define an R1 and an R2 device group for
each package:
# symdg create -type RDF1 devgroupname1
Issue this command on nodes attached to the R1 side.
# symdg create -type RDF2 devgroupname2
Issue this command on nodes attached to the R2 side.
The group name must be the same on each node on the R1 side.
A different group name is used on each node on the R2 side. These group
names are later placed in the shell script variables PKGR1SYMGRP and PKGR2SYMGRP.
Use the symld command to add all LUNs that comprise the Volume Group
for that package on that host. The HP-UX device file names for all
Volume Groups that belong to the package must be
defined in one Symmetrix device group on the R1 side and one Symmetrix
device group on the R2 side. All devices belonging to Volume Groups
that are owned by an application package must be added to a single Symmetrix
device group
# symld -g devgroupname1 add dev devnumber1
# symld -g devgroupname1 add dev devnumber2
This is where Table 4-6 “Symmetrix Device and HP-UX Device Correlation” is helpful. Although
the name of the device group must be the same on each node, the
HP-UX device file names specified may be different on each node.
When creating the Symmetrix device groups, you may specify
only one HP-UX path to a particular Symmetrix device. Do not specify alternate
paths (PVLinks). The SymCLI uses the HP-UX path only to determine
to which Symmetrix device you are referring. The Symmetrix device
may be added to the device group only once.
|
| |
|
| NOTE: Symmetrix
Logical Device names must be the default names
of the form DEVnnn (e.g., DEV001). Do not use the option for creating your own
device names. |
|
| |
|
The script must be customized for each system including:
particular HP-UX device file names
Symmetrix device group name (arbitrary, but unique
name may be chosen for each group that defines all of the volume
groups (VGs) belonging to a particular MC/ServiceGuard package).
Configuring Gatekeeper Devices |
|
|
| |
|
| NOTE: The sample scripts mk4gatekpr.nodename can be modified to automate these steps. |
|
| |
|
Gatekeeper devices must be
unique per MC/ServiceGuard package to prevent contention in the
Symmetrix when commands are issued, such as two or more packages
starting up at the same time. Gatekeeper devices are unique to a
Symmetrix unit. They are not replicated across the SRDF link. Gatekeeper
devices are marked GK in the syminq output, and are usually 2880 KB in size.
Define at least two gatekeepers per
package per node (assuming PV links are used). They will only be
available for use by that node. Each gatekeeper device is configured
on different physical links:
# symgate -sid sidnumber1 define dev devnumber1
# symgate -sid sidnumber2 define dev devnumber2
Associate the gatekeeper devices with the Symmetrix
device group for that package:
# symgate -sid sidnumber1 -g devgroupname1 \
associate dev devnumber1
# symgate -sid sidnumber2 -g devgroupname1 \
associate dev devnumber2
Define a pool of four or more additional gatekeeper
devices that are not associated with any particular node. The SymCLI
will switch to an alternate gatekeeper device if the path to the
primary gatekeeper device fails. Certain software requires the existence
of gatekeepers: OSM graphical interface and SymCLI. These gatekeeper
devices are seen from all of the nodes.
Verifying the EMC Symmetrix Configuration |
|
When you are finished
with all these steps, use the symrdf list command to get a listing of all devices and their states.
You may want to back up the SymCLI database on each node so
that you do not have to do these configuration steps again if a
failure corrupts the database. The SymCLI database is a binary file
in the directory /var/symapi/db.
Creating and Exporting Volume Groups |
|
Use the following procedure to create volume groups and export
them for access by other nodes. The sample script mk1VGs in the Samples directory can be modified to automate these steps.
Define the appropriate Volume Groups
on each node that might run the application package. Use the commands:
# mkdir /dev/vgxx
# mknod /dev/vgxx/group c 64 0xnn0000
where the name /dev/vgxx and the number nn are unique within the cluster.
Create volume groups only on the primary system.
Use the vgcreate and the vgextend command, specifying the appropriate HP-UX device file
names.
Use the vgexport command with the -p option to export the VGs on the primary system without
removing the HP-UX device files:
# vgchange -a n vgname
# vgexport -v -s -p -m mapfilename 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. You need only enter the password
interactively.
Importing Volume Groups on Other Nodes |
|
Use the following procedure to import volume groups. The sample
script mk2imports can be modified to automate these steps.
Import the VGs on all of the other
systems that might run the MC/ServiceGuard package and backup the
LVM configuration. Make sure that you split the logical
SRDF links before importing the VGs, especially if you are importing
the VGs on the R2 side. Use the commands:
# symrdf -g symdevgrpname split -v
# vgimport -v -s -m mapfilename vgname
Back up the configuration. Use the following commands:
# vgchange -a y vgname
# vgcfgbackup vgname
# vgchange -a n vgname
# symrdf -g symdevgrpname establish -v
See the sample script Samples/mk2imports.
|
| |
|
| NOTE: Exclusive activation must be used
for all volume groups associated with packages that use the EMC.
The design of MetroCluster/SRDF assumes that only one system in
the cluster will have a VG activated at a time. |
|
| |
|
Configuring PV Links |
|
The examples in the previous sections show the use of the
vgimport and vgexport commands with the -s option. Also, the mk1VGs script uses a -s in the vgexport command, and the mk2imports script uses a -s in the vgimport command. You may wish to remove this option from both commands
if you are using PV links. The -s option to the vgexport command saves the volume group id (VGID) in the map file,
but it does not preserve the order of PV links. To specify the exact
order of PV links, do not use the -s option with vgexport, and in the vgimport command, enter the individual links in the desired order,
as in the following example:
# vgimport -v -m mapfilename vgname linkname1 linkname2
Printable version
