]r Doc TTSL

7/28/2019 ]r Doc TTSL

http://slidepdf.com/reader/full/r-doc-ttsl 1/10

Implémentation Document for SGeSAP for SRMCLUSTER.

Prepared by

HARISH R Hewlett Packard India Sales Pvt. Ltd.

Hyderabad

7/28/2019 ]r Doc TTSL


Implementation Document of SGeSAP for SRM Cluster

Monday, 15 August 2011 Monday, 15 August 2011

HP Toll free no : 1800 420 4994 email : [email protected]

Proprietary NoticeThis intended document is only for the use of the individual or to the addressed entity and may contain data that is privileged,

confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use,dissemination, distribution, or copying of this document is strictly prohibited.

The information contained in this document is subject to change without notice.This document contains proprietary information. This document is for HP and internal Customer use only.

1.0 Executive Summary

1.1 Introduction

Multi-Computer/ServiceGuard (MC/ServiceGuard or just ServiceGuard) is a specialized facility for protecting mission-critical applicationsfrom a wide variety of hardware and software failures. This document explains the various components forming the ServiceGuardimplementation.

With ServiceGuard, multiple nodes (systems) are organized into an entSRPrise cluster that delivers highly available application servicesto LAN attached clients. ServiceGuard monitors the health of each node and quickly responds to failures in a way that eliminates orminimizes application down time. ServiceGuard is able to automatically detect and respond to failures in the following components:

• System processors

• System memory

• LAN media and adapters

• System processes

• Application processes

Since high availability is a primary goal, ServiceGuard clusters created with no single point of failure; the data disks protected viamirroring or RAID technology, dual paths to data disks via redundant interfaces used whenever possible, and redundant networkinterfaces used.

With ServiceGuard, application services and all the resources needed to support the application are bundled into special entities calledapplication packages. These application packages are the basic units managed and moved within an entSRPrise cluster. Packagessimplify the creation and management of highly available services and provide flexibility for workload balancing.

The process of detecting the failure and restoring the application services completely automated; ideally, no operator interventionneeded.

Note: This intended document does not replace the “Managing MC/ServiceGuard” manual assuming the reader has a basicunderstanding of the various ServiceGuard principles. Information on starting and stopping ServiceGuard clusters, packages, andgeneral ServiceGuard administration are in this manual.

1.2 Objectives

The objective of implementing MC/ServiceGuard is to provide a high availability platform for the application. The objective of this reportis to document the configuration and testing strategies used during the implementation of the General Overview cluster.

1.3 Sources

Information for this documentation was provided by of Hewlett-Packard India, Hyderabad.

2.0 Operating System Configuration

Since the application software that is bundled into the MC/ServiceGuard packages is configured to be able to run on various nodes, careshould be taken with the operating system configurations across the nodes in the cluster. Different nodes in the cluster may certainly havedifferent functions, and may have different software bundles and patches installed, as well as different requirements for kernel parameters.Consideration must also be taken for the packages that are configured to use each node as an adoptive node.

Generally, the operating system configurations of the nodes in a cluster should be kept as similar as possible.

3.0Hardware

3.1 PowerAll power circuits to critical components should be protected by uninterruptible power sources (UPS). In addition, multiple UPS’s shouldbe used to further protect against a failure.

Loss of a single power circuit should not bring down the cluster. No more than half of the nodes in the cluster should be on a powersource. If a power source supplies exactly half of the nodes, it must not also supply the cluster lock disk or the cluster will be unable toreform after a failure.

Loss of a single power circuit should not bring down mirrored disks. The physical disks that hold mirrored copies of data should beconnected to different power sources, just as they should be connected to different I/O interfaces.

Loss of a single power circuit should not bring down a critical network segment. Redundant network components should be connected todifferent power sources.

While discussions were held, detailed analysis of the power circuits used for the components of the cluster was done as a part of thisengagement.

3.2 Support Communications Links

Hewlett-Packard recommends the provision of telephone lines to each system to facilitate remote support. HP will utilize these lines forplanned and reactive support as necessary with the approval of your systems administration staff. These lines can be connected to thesystems as needed.

7/28/2019 ]r Doc TTSL





3.3 Event Monitoring Service

Event Monitoring Service (EMS) is an application framework for monitoring system resources on HP-UX 11ix. This framework can beused by EMS hardware monitors and EMS High Availability monitors. MC/ServiceGuard can be configured with EMS to monitor thehealth of selected resources, such as disks. Based on the status of the resources, ServiceGuard can decide to fail packages over. UsingEMS with ServiceGuard adds to the set of failures or events that can be detected and handled appropriately.

3.4 Disk Configuration

3.4.1 ServiceGuard Requirements

Data protection must be provided for all essential data. This is even more important than protecting the system’s root disks. If aroot disk fails and is not protected, that node will fail and MC/ServiceGuard will move the packaged applications to another availablenode. If a data disk fails and is not protected, no node in the cluster will be able to run any applications that depend on the data onthe failed disk. Two methods for providing this protection are disk mirroring and RAID.

Disk mirroring is provided by MirrorUX (LVM Based Software Mirroring). If one disk should fail, the MirrorUX software willautomatically keep the data available by accessing the other mirror. To protect against an interface or bus failure, each copy of thedata should be accessed through a different interface and bus.

Data redundancy with RAID levels 1 or 5 will protect against a disk failure. To also protect against an interface or bus failure,redundant interfaces must be configured using Logical Volume Manager’s PV Links (alternate links) feature, providing multiple pathsto the data.

3.4.2 System Root Disks

It is highly recommended that you use mirrored root volumes on all cluster nodes. You should mirror all logical volumes in the rootvolume group, including all swap areas. Mirroring root logical volumes goes beyond simply protecting critical data. In the event of adisk failure, if all logical volumes are mirrored the node will continue to operate. Although MC/ServiceGuard is designed to migrateapplications from a failed node to an available alternate, the act of migrating the application almost always causes some disruption toservice. While ServiceGuard helps minimize this disruption, every possible step should be taken to maintain operation of theapplication package on the original node whenever possible.

The mirror copy of the boot drive should also be configured as bootable, and the boot string that is written into the LIF area shouldallow the volume group to be activated with one failed disk, which might result in a quorum of disks not being available.

Another consideration in the configuration of system root disks is swap space. When determining the required swap space for eachnode, you must consider that in the event of a failover situation, additional applications may be running on each node. Therequirements of all packages that can possibly run on a node must be factored into the swap space calculation.

3.4.3 ServiceGuard Package Disks

Any data relating to a ServiceGuard packaged application must reside within a shared volume group, accessible from each system. If individual applications must be able to move independently between the systems then the respective data must be isolated intoseparate volume groups. On the other hand, if it is desired or mandatory that two applications always coexist on the one system

then a volume group may be shared. Generally, this is to be discouraged as this creates significant rework if it is later decided toseparate the applications.

Executable code, or application binaries, either may be shared (one copy moves between the systems) or duplicated (a copy of theexecutable code contained in non-shared volume groups on each system).

Duplicated binaries provide the opportunity to perform rolling upgrades to new software releases by temporarily moving data toanother system. However, this requires rigorous administration to ensure the copies of the application are correctly maintained andsynchronized.

A single shared executable will remove the possibility of “out of sync” copies but also eliminate the possibility of rolling upgrades.

3.5 Networks

3.5.1 Network Configuration

An MC/ServiceGuard cluster should always have at least two subnets, and each node in the cluster should have at least one networkinterface card connected to each subnet. At least one subnet will be required for data communications within the cluster and outsidethe cluster. It is strongly recommended that there be one (or more) dedicated subnets to carry the heartbeat messages among thecluster nodes. Each node sends these heartbeat messages to the node that has been designated as the cluster coordinator. If the

cluster coordinator does not receive a heartbeat message from another node within a predetermined time, it will attempt to reformthe cluster. It is because the transmission and reception of these heartbeat messages is critical to the operation of the cluster thatthe recommendation for a dedicated subnet is made. It is also recommended that redundant heartbeat messages be transmitted onat least one other subnet.

3.5.2 Local Network Switching

At regular intervals, MC/ServiceGuard polls the entire network interface cards specified in the cluster configuration file. If this pollingis unsuccessful to an interface for a predetermined amount of time, the interface is considered to be down. If another networkinterface is connected to the same subnet, and if that interface does not have any IP addresses configured, it will be used as abackup to the failed network card, and traffic on that subnet will be rerouted through the backup card. During this time, IP packetswill be lost, but TCP will retransmit all lost packets, so all TCP/IP messages will be received intact. When the primary networkinterface card is available, traffic will automatically be transferred back to the primary.

MC/ServiceGuard also supports the use of automatic port aggregation (APA). APA is a networking technology that aggregatesmultiple physical ports into a single logical link. It also provides load balancing among physical links, automatic fault detection, andrecovery.

3.5.3 Stationary and Relocatable IP Addresses

Each node should have a unique IP address for each active network interface. This address, known as a stationary IP address, is nottransferable to another node, but can be transferred to a standby network interface card. The stationary IP address is not associatedwith packages.

Normally one or more unique IP addresses are assigned to each package. These package (or relocatable) IP addresses are assignedto the appropriate active network interface when the package is started. These relocatable IP addresses are transferred to nodes in

7/28/2019 ]r Doc TTSL





the cluster with the packages. Network access to package services should always be via the relocatable IP addresses. In that way,the services will continue to be reached after the package is transferred to another node.

4.0ServiceGuard Configuration

4.1 ClustersAn MC/ServiceGuard cluster is a networked grouping of HP 9000 series or Integrity servers having sufficient redundancy of software andhardware that a single point of failure will not significantly disrupt service. Application services are grouped together in packages; in theevent of a single service, node, network, or other resource failure, MC/ServiceGuard can automatically transfer control of the package toanother node within the cluster, allowing services to remain available with minimal interruption.

Redundancy of components is typically designed into a ServiceGuard configuration using disk mirroring or RAID, alternate I/O paths todisks, alternate I/O paths to sub networks, and redundant network components. This redundancy allows some failures to be dealt withwithout any disruption to the application services.

An MC/ServiceGuard cluster can also be configured to allow rolling software upgrades. Using this technique, patches can be applied, theHP-UX operating system and other software can be upgraded, and hardware maintenance can be performed on one node at a timewithout bringing down the cluster or causing an extended outage of application services.

4.2 Cluster Configuration

4.2.1 Cluster Configuration File

The cluster configuration file is an ASCII file, either created using SAM or the cmquerycl command that contains the cluster manager

parameters. This file identifies all of the nodes in the cluster and their network connections, as well as the device file for the clusterlock disk if one is used. Other cluster-wide parameters, such as heartbeat interval, node timeout, maximum configured packages,and others are also defined in the cluster configuration file.

4.2.2 Cluster Event Logging

Cluster event logging is written to the system log file. The default location of the log file is /var/adm/syslog/syslog.log. This logprovides information on:

• Cluster commands executed and their outcome.

• Major cluster events, which may, or may not, be errors.

• Cluster status information.

4.2.3 Cluster Lock Disk

In order for a cluster to reform after a node failure, a strict majority (more than 50%) of the nodes previously running must attemptto join the new cluster. Exactly 50% of the previously running nodes may reform as a new cluster if the other 50% do not alsoreform as a new cluster. This will most often happen when a cluster contains two nodes, and heartbeat communications between thetwo nodes are interrupted. Each node will assume that the other has failed, and will attempt to form a cluster by itself. Since only

one cluster can be allowed to reform, a tiebreaker is needed. One of the disks that are physically connected to all nodes in thecluster is designated as the cluster lock disk, which acts as the tiebreaker.

The cluster lock is actually a disk area outside the normal data area. When two sub-clusters of equal size attempt to form, each sub-cluster will attempt to acquire the cluster lock. The sub-cluster that gets the cluster lock will form the new cluster, while the othersub-cluster will be prevented from forming.

A cluster lock disk is required for a two-node cluster, and is recommended for a three- or four-node cluster. If the cluster has morethan four nodes, a cluster lock disk is not allowed.

4.3 Package

Application services, which need to be highly available, must be grouped into packages. As stated above, in the event of a singleservice, node, network, or other resource failure, MC/ServiceGuard can automatically transfer control of the package to another nodewithin the cluster, allowing services to remain available with minimal interruption. Since a package is transferred as a unit, alldependent services should be grouped within the same package. Unrelated or independent services should typically be grouped intoseparate packages.

4.4 Package Configuration

4.4.1 Package Configuration FileThe package configuration file is an ASCII file, either created using SAM or the cmmakepkg command that contains the packagemanager parameters. This file identifies which nodes in the cluster are eligible to run the package, as well as which node is theprimary node for this package. Other package-specific parameters, such as control script pathname, services to be run with thepackage, subnets or resources to be monitored, and others are also defined in the package configuration file.

4.4.2 Package Event Logging

Package event logging is written to the system log file. This log provides information on:

• Package commands executed and their outcome.

• Major package events, which may, or may not, be errors.

• Package status information.

Additionally, there is typically a log file written by the package control script. The default location of this log file is /var/adm/cmcluster/log/<PACKAGE NAME>.log. This log documents all package run and halt activities, usually in more detail thancan be found in the system log file. Also unlike the system log file, this file is not refreshed when the system is booted. While thismeans that more historical data on package starts and stops may be available in this file, it also means that the size of this file must

be monitored and it should be trimmed from time to time.

5.0Test Procedures

It is important that various tests be performed after any changes are made to the environment, to assure that an emergency failover will notbe prevented by some misconfiguration of the cluster nodes. It is also important to perform tests at scheduled intervals, even when no

7/28/2019 ]r Doc TTSL





changes are thought to have been made to the environment. These tests prevent some small change that is not expected to have any effecton the operation of MC/ServiceGuard from causing an emergency failover to fail.

5.1 System Tests

Logical volumes that are mirrored should be checked to verify that both mirrored copies are online and being kept current. Alternate I/O

paths to disks should be verified either by removing the primary connections or by reversing the primary and alternate paths. Mirroredboot areas should be tested to verify that they still function correctly.

5.2 Cluster Tests

The cluster should be verified with the cmcheckconf command, to assure that the basic cluster configuration files and package controlscripts pass the tests built into cmcheckconf. The command cmapplyconf should be used to verify that the binary configuration file canbe distributed to all nodes in the cluster. The cmruncl command should be used to verify that the cluster successfully forms with allconfigured nodes present.

5.3 Network Tests

Standby network links should be tested by removing the primary link and verifying that network traffic is successfully diverted to thestandby. The traffic should be automatically moved back to the primary link when it becomes available. This operation can bemonitored in the system log file.

5.4 Package Tests

The packages should be tested by moving them from their primary node to their adoptive node and back again. Enough applicationstesting should be included to assure that the package is functional on the adoptive node.

6.0 Configuration Overview

6.1 Cluster nodes

The MC/ServiceGuard cluster for ECC consists of 2 nodes:

Node name (ECCSRP) Description

tchsrmd1 Primary Node

tchsrmc1 Secondary Node

6.2 Volume Groups & Physical VolumesFollowing volume groups have been configured for the use of MC/ServiceGuard (cluster aware). They can only be activated in exclusive

mode (vgchange -a e)

FOR dbSRP

VG Name LV Name Mount Point Size PackageName

vg_tchsrmd1 srp /oracle/SRP 10GB dbSRP

vg_tchsrmd1 10x_64 /oracle/client/10x_64 3GB dbSRP

vg_tchsrmd1 stage_102_64 /oracle/stage/102_64 10GB dbSRP

vg_tchsrmd1 102_64 /oracle/SRP/102_64 20GB dbSRP

vg_tchsrmd1 origlogA /oracle/SRP/ origlogA 2GB dbSRP

vg_tchsrmd1 origlogB /oracle/SRP/ origlogB 2GB dbSRP

vg_tchsrmd1 mirrlogA /oracle/SRP/mirrlogA 2GB dbSRP

vg_tchsrmd1 mirrlogB /oracle/SRP/mirrlogB 2GB dbSRP

vg_tchsrmd1 sapreorg /oracle/SRP/sapreorg 3GB dbSRP

vg_tchsrmd1 sapdata1 /oracle/SRP/sapdata1 30GB dbSRP




vg_tchsrmd1 oraarch /oracle/SRP/oraarch 70GB dbSRP

vg_tchsrmd1 112_64 /oracle/SRP/112_64 20GB dbSRP

FOR ciSRP

VG Name LV Name Mount PointSize Package

Name

vgdveb lvdveb /usr/sap/SRP/DVEBMGS00 10GB ciSRP

FOR ascsSRP


Name

7/28/2019 ]r Doc TTSL






Name

vgascs lvascs /usr/sap/SRP/ASCS01 10GB ascsSRP

FOR vSRPnfs


Name

vgnfs lvol1 /export/sapmnt/SRP 8GB srmnfs

In addition to the above mentioned mount points two NFS will be mounted in both the servers using the srmnfs hostname. The details are :

HostnameMount Point

srmnfs /sapmnt/SRP

6.3 Log and configuration files

FOR ECCSRP CLUSTER Filename Description

/etc/cmcluster/SRP/dbSRP.conf.sap DB Package Configuration file.

/etc/cmcluster/SRP/ciSRP.conf.sap DVEBMGS00 Package Configuration file

/etc/cmcluster/SRP/ascsSRP.conf.sap ASCS01 Package Configuration file

/etc/cmcluster/SRP/srmnfs.conf HA NFS Package configuration file

/var/adm/cmcluster/log/dbSRP.log Startup and shutdown log for dbSRP package

/var/adm/cmcluster/log/ascsSRP.log Startup and shutdown log for ascsSRP package

/var/adm/cmcluster/log/ciSRP.log Startup and shutdown log for ciSRP package

/var/adm/cmcluster/log/srmnfs.log Startup and shutdown log for vSRPnfs package

7.0 Status and Startup

7.1 Viewing cluster and package status

# cmviewcl –v | more

This will describe the status of the cluster, nodes, packages and services.

7.2 Starting the cluster

# cmruncl

This command will cause all configured nodes to form a cluster and start all enabled packages.

7.3 Halting the cluster

# cmhaltcl

This command will halt ServiceGuard operations on all nodes currently running in the cluster. If any packages are running, the cluster will not behalted. Either use cmhaltpkg first or use

# cmhaltcl –f

This will force the packages to halt before the cluster is halted.

7.4 Starting a node

# cmrunnode <node_name>

This command will cause the specified node to join an already running cluster. Packages that were enabled but previously unable to run may bestarted automatically by this command.

7.5 Halting a node

# cmhaltnode <node_name>

This command will halt ServiceGuard operations on the specified node. If any packages are running on that node, the node will not be halted.Either use cmhaltpkg first or use

# cmhaltnode –f <node_name>

With this command, if a package is running on the specified node that can be switched to an adoptive node, the switch takes place and thepackage starts on the adoptive node.

7.6 Running a package

# cmrunpkg [-n <node_name>] <package_name>

This will run the package on the current node or on the node specified, writing output in the package control script log file, typically /etc/cmcluster/<package_name>/<control_script>.log.

7/28/2019 ]r Doc TTSL





Note: Once a package has been halted it is also possible to run a package again by modifying its package switching status to enabled, i.e.

# cmmodpkg –e <package_name>

7.7 Halting a package

# cmhaltpkg <package_name>

This will halt the package, writing output in the package control script log file, typically /etc/cmcluster/<package_name>/<control_script>.log.

7.8 Enabling a package for switching/failing overAfter a package has been halted its global switching flag is disabled. This means the package will not be moved to an adoptive nodeautomatically if a failure occurs.

# cmmodpkg -e <package_name>

This will enable global switching.

7.9 Disabling a package from switching/failing over

# cmmodpkg -d <package_name>

This will disable global switching.

7.10 Enabling a package to run on a particular node

After a package has failed on one node, that node is disabled. This means the package will not be able to run on that node.

# cmmodpkg -e -n <node_name> <package_name>

This will enable the package to run on the specified node.

7.11 Disabling a package from running on a particular node

# cmmodpkg -d -n <node_name> <package_name>

This will disable the package to run on the specified node.

7.12 Common MC/ServiceGuard Operations

The following operations are frequently performed in the operation of an MC/ServiceGuard cluster. Additional information regarding thecommands listed below can be found in the “Managing MC/ServiceGuard” manual, or in the appropriate man () pages.

7.12.1 Checking the status of the cluster

From any active node in the cluster:

Logon as root

cmviewcl -v

Expected output with the important items to note: (See the diagram in this document)

Ensure all nodes are part of the cluster by checking the “Node Status” area.

Ensure the PKG_SWITCH is enabled for each package to allow it to switch to the adoptive node in the cluster if the primary node fails.

Ensure the “Node Switching Parameters” indicate that each package is running on the appropriate node for your situation.

Ensure that SWITCHING is enabled for all nodes.

7.12.2 Starting the cluster with all cluster nodes available

From any node which will be part of the cluster:

Logon as root

cmruncl -v

Note: If the nodes in the cluster are configured for automatic cluster startup, they will try to join a cluster at boot time. If there is not an

existing cluster to join, an attempt to form a new cluster will be made. This will be successful only if all defined nodes attempt to join the clusterwithin the time-out period of 10 minutes.

Expected output:

Starting the cluster creates messages that are logged to the “/var/adm/syslog/syslog.log” file. Use the “tail -f /var/adm/syslog/syslog.log” command to view messages as the cluster is starting.

7.12.3 Starting the cluster with a limited number of cluster nodes available

From any available node, this is normally, part of the cluster:

Logon as root

cmruncl -v -n <node_name>

Expected output:

A warning message will appear on the display when starting the cluster in this manner. Ensure the cluster is not already running on anothernode prior to selecting “y” to continue with cluster start-up.

Starting the cluster creates messages that are logged to the “/var/adm/syslog/syslog.log” file. Use the “tail -f /var/adm/syslog/syslog.log” command to view messages as the cluster is starting.

7.12.4 Stopping the cluster


7/28/2019 ]r Doc TTSL





Logon as root

cmhaltcl [-f] -v

Expected output:

The “-f” option, if used, forces the halt of any running packages.

Stopping the cluster creates messages that are logged to the “/var/adm/syslog/syslog.log” file. Use the “tail -f /var/adm/syslog/syslog.log” command to view messages as the cluster is stopping.

7.12.5 Joining an active cluster

From the node which will join the active cluster:

Logon as root

cmrunnode -v

Expected output:

Joining the cluster creates messages that are logged to the “/var/adm/syslog/syslog.log” file. Use the “tail -f /var/adm/syslog/syslog.log” command to view messages as the node is joining the cluster.

7.12.6 Halting cluster activities on a node in an active cluster


Logon as root

cmhaltnode [-f] -v node_name

Expected output:

The “-f” option, if used, forces the halt of any packages running on this node.

Halting a node in the cluster creates messages that are logged to the “/var/adm/syslog/syslog.log” file. Use the “tail -f /var/adm/syslog/syslog.log” command to view messages as the node halts cluster activities.

7.12.7 Running a package


Logon as root

Check the status of the node as described above in Checking the Status of the Cluster. Determine if the node is an active member of the cluster.

If the node is not an active member of the cluster, start or join the cluster as appropriate as described above.

cmrunpkg -v -n <node_name> <package_name>

Note: If the package was previously shutdown using the “cmhaltpkg” command, package switching will be disabled between nodes within thecluster. If desired, enable package switching as described below. If the package is running with switching disabled, the packages will not failoverin the event of a failure on the current node.

Expected output:

Running the package creates messages that are logged in the “/etc/cmcluster/<package_name>/<control_script>.log” file. To view the file, usethe “tail -f /etc/cmcluster/<package_name>/<control_script>.log” command while the package is starting.

7.12.8 Enabling package switching


Logon as root

cmmodpkg -v -e <package_name>

Note: If the package is not currently running, the cmmodpkg command will enable the package for switching and will start the package. If thepackage is currently running, the cmmodpkg command will enable the package for switching. To ensure package switching has been properlyenabled, use the “cmviewcl -v” command.

Expected output

The cluster daemon will provide a response to the command through the standard output.

7.12.9 Halting a package


Logon as root

cmhaltpkg -v <package_name>

Expected output:

Halting the package creates messages that are logged in the “/var/adm/cmcluster/log/<PACKAGE NAME>.log” log file. Use “tail -f /var/adm/cmcluster/log/<PACKAGE NAME>.log” command to view messages while the package is halting.

7.12.10 Moving a package from one node to another


Logon as root

Check the status of the adoptive node as described above in Checking the Status of the Cluster. Determine if the node is an active member of the cluster.

If the node is not an active member of the cluster, start or join the cluster as appropriate as described above.

cmhaltpkg -v <package_name>

7/28/2019 ]r Doc TTSL





cmrunpkg -v -n <node_name> <package_name>

cmviewcl -v

Note: Since the package was shutdown using the “cmhaltpkg” command, package switching will be disabled between nodes within the cluster. If desired, enable package switching as described above. If the package is running with switching disabled, the packages will not failover in the

event of a failure on the current node.Expected output:

Halting or running the package creates messages that are logged in the /var/adm/cmcluster/log/<PACKAGE NAME>.log” file. To view the file,use the “/var/adm/cmcluster/log/<PACKAGE NAME>.log” command while the package is stopping or starting.

7.12.11 Performing an HP-UX shutdown on an active cluster node

The necessary procedure is dependent upon the state of the cluster and the action you wish to occur.

If the node is not an active member of the cluster:

Follow standard shutdown procedures for the node (i.e. “/etc/shutdown”).

If no packages are currently running on the node:


If any packages are running on the node, to shutdown this node and have, the packages run on an adoptive node:

Move the packages from this node to another node as described above.


If any packages are running on the node, to shutdown this node and not have, the packages run on an adoptive node:

Halt the package as described above.


7.12.12 Adding a non-shared volume group to a cluster node

Since it is possible for more than one system to access a volume group using MC/ServiceGuard (though not concurrently), the LVM start-upshould be modified so that the cluster nodes do not automatically try to activate all volume groups they have access to. The package start-upactivates shared volume groups.

However, /dev/vg00 is always automatically activated. If another non-shared volume group is added to either system, that volume group mustbe specified in the /etc/lvmrc file.

To add a new, non-shared volume group to a cluster node, modify the /etc/lvmrc file on the particular node as specified in the on-linedocumentation within that file to automatically activate the new volume group on bootup.

7.12.13 Modifying a shared volume group in a clusterIf you are adding or removing either a logical volume or a physical volume, you must export the volume group after you make the modifications,and you must import the volume group on each node that may run the package that will activate the volume group. You can perform the exportand the import while the cluster and package are running. The following commands are examples of how to perform this operation withoutdisturbing the cluster or package:

On the node that currently has the volume group activated (package is running) –

(make the logical or physical volume changes as required)

vgexport –p –s -v –m /tmp/<vgname>.map /dev/<vgname>

Note: This command will give you an informational message that the volume group is still activated. This is to be expected, andwill cause no problems. The map file will still be written, and that is all that you want this command to do.

(transfer /tmp/<vgname>.map to all other nodes in the cluster that can activate the VG)

On the other nodes that currently have the volume group deactivated (package is not running)

vgexport –v /dev/<vgname>

vgimport –s -N –v –m /tmp/<vgname>.map /dev/<vgname>

Note: If pvlinks are being used for this volume group, it is possible that after the vgimport the primary and alternate links will bereversed. To restore the correct primary and alternate links, you must first activate the volume group, which means you shouldmove the package to the node you wish to change. Then use the vgreduce command to remove the link that is listed as theprimary. This will automatically make the alternate link into the primary. Then use the vgextend command to add the link thatyou just removed back in. This link will then be listed as the alternate.

7.12.14 Modifying a package on a running cluster

Changes to a package that do not affect the package configuration file can be made at any time. Remember to copy any modified files to allnodes in the cluster that can run the package. Changes to a package should be verified immediately by stopping and starting the package.

Changes to a package that affect the package configuration file require the package to be stopped. After stopping the package with thecmhaltpkg command, make the necessary changes to the package configuration file. This file should be copied to all appropriate nodes. Verifythe changes with the cmcheckconf command, then apply the changes and distribute them to all nodes with the cmapplyconf command. Thesechanges may be made while the cluster and other packages are running.

cmhaltpkg –v <package_name>

(make appropriate changes to package control file and copy to other nodes)

cmcheckconf –v –P /etc/cmcluster/dbciHPR/<package_control_file>cmapplyconf –v –P /etc/cmcluster/dbciHPR/<package_control_file>

7/28/2019 ]r Doc TTSL




7.12.15 Adding a package to a running cluster

Provided that the cluster parameter MAX_CONFIGURED_PACKAGES allows for another package, a new package can be added to a running clusterwith no effect on other running packages. The new package configuration and control files are created and copied to all appropriate nodes asalways. When verifying and applying the configuration the cluster configuration file must not be used. Only the new package configuration file isused on the cmcheckconf and cmapplyconf commands.

cmcheckconf –v –P /etc/cmcluster/DBCIHPR/<package_control_file>

cmapplyconf –v –P /etc/cmcluster/DBCIHPR/<package_control_file>

7.12.16 Deleting a package from a running cluster

An existing package can be deleted from a running cluster with no effect on other running packages. The package must first be halted. Thedirectory /etc/cmcluster/<package_name> are not deleted.

cmhaltpkg <package_name>

cmdeleteconf –p <package_name>

A.1 HOSTNAMES AND IP ADDRESSES

System / PackageName

Link Description Link IP Address

tchsrmd1 lan0 (P) &

lan2 (S)

Physical

Hostname

172.17.52.107

tchsrmc1 lan0 (P)& lan2 (S)

PhysicalHostname

172.17.52.104

dbSRP Virtual DBhostname

172.17.52.108

ascsSRP VirtualASCS01hostname

172.17.52.105

ciSRP VirtualDVEBMGS00hostname

172.17.52.106

srmnfs Virtual NFSpackagehostname

172.17.52.120

Documents

]r Doc TTSL