Synchrony 4 3 Cluster Configuration Guide All-OS ENU

CLUSTER CONFIGURATION GUIDE
Synchrony Platform
Version 4.3
11 May 2010
Copyright Axway Software, 2010 All rights reserved. This documentation describes the following Axway software: Synchrony. No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of the copyright owner, Axway Software. This document, provided for informational purposes only, may be subject to significant modification. The descriptions and information in this document may not necessarily accurately represent or reflect the current or planned functionalities of this product. Axway Software may change this publication, the product described herein, or both. These changes will be incorporated in new versions of this document. Axway Software does not warrant that this document is error free. Axway Software recognizes the rights of the holders of all trademarks used in its publications.
Preface
PURPOSE OF THIS MANUAL
The purpose of this document is to help you with the installation and management of Synchrony components in a cluster environment. It does not replace the Synchrony Installation and Prerequisites Guide, but it gives you more information on: Cluster architecture Planning an installation of Synchrony on a cluster Management basics of HACMP, Sun Clusters, HP Serviceguard, Veritas Storage Foundation, High Availability, Red Hat Linux Cluster Suite and Windows MSCS
WHO SHOULD READ THIS MANUAL
This document is intended for users that have to install a Synchrony component or solution in a cluster architecture.
ASSUMED KNOWLEDGE
In this guide, we assume that the reader has a working knowledge of UNIX and Windows.
RELATED DOCUMENTATION
Synchrony Cluster is accompanied by: Synchrony Installation and Prerequisites Guide (HTML) All Synchrony Cluster documentation is available from the Axway Support website: https://support.axway.com.
Cluster Configuration Guide
Preface
Contents
Cluster architecture Standard cluster architecture

Global architecture and behavior Software architecture and behavior
6 6
6 8
Advanced cluster architecture 2 Installation prerequisites HACMP Sun Cluster HP Serviceguard Red Hat Cluster Suite Veritas Storage Foundation MSCS 12 UNIX users License keys
UNIX license keys Windows license keys
9 11 11 11 11 12 12
13 13
13 14
Cluster installation Cluster installation checklist Installing the first node Managing Synchrony scripts on UNIX
Script descriptions Script installation
15 15 16 17
17 17
Testing a Synchrony Component on the first node

Testing on UNIX Testing on Windows
18
18 19
Installing additional nodes Installing scripts on the second node Testing a Synchrony Component on the second node 4 Cluster configuration
19 20 20 21
Contents
Various component installations

Installing two Synchrony components in two different groups Installing multiple components sequentially
21
21 21
Applying patches
Automator Composer Gateway Integrator InterPlay Messaging ProcessManager Sentinel Transfer CFT
22
22 22 22 23 23 23 23 24 24
Cluster management Cluster administration guidelines

Administrative user Differences between a production and test site
25 25
25 25
HACMP
HACMP Concepts HACMP management basics
25
25 27
Sun Cluster
Sun Cluster concepts Sun Cluster management basics
32
32 33
HP Serviceguard
HP Serviceguard concepts HP Serviceguard management basics
36
36 37
Linux Cluster Suite

Related software Linux Cluster Suite Concepts Linux Cluster Suite management basics GUI procedure Command line procedure Managing the Linux Cluster
39
39 39 40 40 42 44
Veritas Cluster Server for Linux

Related software Veritas Storage Foundation Concepts GUI procedure
46
46 46 47
MSCS 51
MSCS Concepts MSCS: Management 51 52
Contents
1 Cluster architecture
IN THIS CHAPTER
This chapter describes the basics of cluster architecture. It includes a description of both standard and advanced cluster architecture.
Standard cluster architecture

Global architecture and behavior
This is a standard configuration: the disk is linked to the server. If there is a failure on the server the application must be stopped.
Network
Client
Server + Disk
Figure 1: Standard architecture with one server
In a classic cluster environment, two servers are used. They share a disk and the same address. Each server has a local disk from where it boots and where the applications can store static files (binary, jar, configuration files, etc.). The data is stored on the shared disk. When one server is active: it keeps the IP address, mounts the shared disk, and starts the applications. The other server is passive but it checks the status of the active server (i.e. the communication between the two nodes) using a heartbeat. If there is an error or if the first node does not respond, the second node becomes active. It takes the IP address, mounts the shared disk and starts the applications. Before doing this step, it verifies that the other node has really stopped. This operation is called "failover." For the client application, the scenario is exactly the same as if the application had been stopped and immediately restarted.
Cluster architecture uster
First case
In Figure 1, the server on the left is active and the client applications are connected using the IP address "ClusterIP". http://ClusterIP
Client
Network
Active application server
Passive application server
Local Disk
Local Disk
Shared Disk
Figure 2: The first server is active
Second case
In Figure 2, a failover is done and the server on the right becomes active. The client application can open a new connection using the same IP address ("ClusterIP").
http://ClusterIP
Client
Network
Previous Active application server This server is now inactive
New Active application server
Local Disk
Local Disk
Shared Disk
Figure 3: The second server is active
Cluster architecture uster
Software architecture and behavior

Different types of clusters
The following types of cluster software are covered in this document:
Operating System AIX Solaris HP/UX Windows Linux Other UNIX Cluster name HACMP (High Availability Cluster Multi-Processing) Sun Cluster HP Serviceguard MSCS (Microsoft Cluster Service) RedHat Cluster Suite Veritas Storage Foundation
These environments are not standardized and consequently the commands are different on each type of cluster.
Resources and groups

All types of clusters have the same type of architecture: each object is defined as a resource which is embedded in groups. The different types of resources are: Disk (usually one per group) TCP/IP address (one per group) Application (one or more per group(s)) Network name (only used on Windows) or hostname On some clusters, the disk and the IP network is not conceptually identified as a resource but directly defined in the group. The Cluster Manager activates these groups between the different CPUs. The goal of a group is to: Start each resource Monitor each resource In case of an error with a resource, it tries to restart it. If that fails (and depending on the failover policy attached to the resource, to stop all the resources of the group) it restarts it on the other node. The application resource needs three main parameters: The name of the script to be run to start the application. The name of the script to be run to stop the application. The method to be used to monitor the application. The cluster Manager can monitor the applications in different ways. For example, with HACMP the method used is the name of a script that must send back a return code that describes the state of the application (running or not). With Sun Cluster the method is a feature that can monitor the activity of the IP port used by the application server. Note: On HP Serviceguard the term package is used instead of group but the behavior and the functionality are identical.
Cluster architecture
Cluster behavior
In this section, we assume that the two nodes of the cluster are stopped. Follow these steps to start the cluster environment: The first node is started. It boots and starts its environment. The Cluster Manager detects that it is alone. So it decides to start the group. This group contains a disk, an IP address and an application. The disk is attached to the CPU and the shared directory is mounted. Then, the application is started. After a few seconds the Cluster Manager, which has been set up in the resource definition, begins to monitor the application periodically. When the first IP connection with the address attached to the group arrives, the node accepts it. Then, the second node is started. It boots and starts the Cluster Manager. It joins the cluster and sees that the other node is running and active. It goes into passive mode. A failover can occur for different reasons: A planned action A non recoverable error in a group o A hardware problem In all of these cases, the first node becomes inactive. The second node detects the failure and starts its own processes. It attaches the disk, sends a request to the IP router to clean its routing table and starts the application.
o o
When the first IP connection with the address attached to the group arrives, the new active node accepts it.
Advanced cluster architecture

In the configuration described below, two groups are defined in the Cluster Manager. Each of these groups can run on different nodes (Figure 4). In this case, the load is balanced between the two systems. If one of the two nodes fails, the group previously attached to this node is restarted on the other node (Figure 5).
Figure 4:
nodes
Two groups running on different
Figure 5: Two groups running on the same node
10
2 Installation prerequisites
IN THIS CHAPTER
The installation prerequisites described in this chapter are provided in addition to the standard Synchrony components installation prerequisites.
HACMP
You can install a Synchrony Component into a pre-existing HACMP cluster configuration that already contains groups and resources. Alternatively, you can create a new cluster with a group dedicated to the Synchrony component you plan to install. The group that you select as the destination group for your installation must have the following minimum set of resources: an IP Address a hard drive For more information, refer to the section in chapter 5 on HACMP concepts. The creation of HACMP clusters and groups is beyond the scope of this documentation. For detailed information, refer to IBMs documentation.
Sun Cluster
You can install a Synchrony Component into a pre-existing Sun Cluster configuration that already contains groups and resources. Alternatively, you can create a new cluster with a group dedicated to the Synchrony component you plan to install. The group that you select as the destination group for your installation must have the following minimum set of resources: an IP Address a hard drive For more information, refer to the section in chapter 5 on Sun concepts. The creation of Sun clusters and groups is beyond the scope of this documentation. For detailed information, refer to Suns documentation.
HP Serviceguard
You can install a Synchrony Component into a pre-existing HP Serviceguard configuration if the package is already installed.
Installation prerequisites
11
The package that you select as the destination group for your installation must have the following minimum set of resources: an IP Address a hard drive For more information, refer to the section in chapter 5 on HP Serviceguard concepts. The creation of an HP Serviceguard package is beyond the scope of this documentation. For detailed information, refer to your HP documentation.
Red Hat Cluster Suite

You can install a Synchrony Component into a pre-existing Red Hat Cluster Suite configuration if the package is already installed. The package that you select as the destination group for your installation must have the following minimum set of resources: an IP Address a hard drive For more information, refer to the Red Hat Cluster Suite concepts section in chapter 5. The creation of a Red Hat Cluster Suite package is beyond the scope of this documentation. For detailed information, refer to your Red Hat documentation.
Veritas Storage Foundation

You can install a Synchrony Component into a pre-existing Veritas Storage Foundation configuration if the package is already installed. The package that you select as the destination group for your installation must have the following minimum set of resources: an IP Address a hard drive For more information, refer to the section in chapter 5 on Veritas Storage Foundation concepts. The creation of a Veritas Storage Foundation package is beyond the scope of this documentation. For detailed information, refer to your documentation.
MSCS
You can install a Synchrony component into a pre-existing Windows cluster configuration if the MSCS cluster already contains groups and resources. Alternatively, you can create a new cluster with a group dedicated to the Synchrony component you plan to install.
12
The cluster that you select as the destination cluster for your installation must have the following minimum set of resources: an IP Address a Network Name a hard drive For more information, refer to the section in chapter 5 on MSCS concepts. The creation of MSCS clusters is beyond the scope of this documentation. For detailed information, refer to the MSCS documentation on the Microsoft website.
UNIX users
In UNIX, users can be classified in two main categories: root user: a user with special administration permissions standard user: a standard user without special permissions The first category puts a root user together with, for example, the DBA (Database Administrator) or MQSeries Administrator. The second category includes the application users who only have read permissions for the use of objects or files managed by the administrators. They work mainly from their home directories. A standard user is required to install Synchrony components. The only exception to this rule is the installation of the component Automator, which requires a root user. A standard user is required for installations on a cluster, but a root user is required to configure the Cluster Manager (HACMP). There are steps which are done by a standard user dedicated to the installation of Synchrony and other steps which are done by a root user. The type of user required is indicated in the introduction paragraph of each section. The terms used are: root user for the first category (cluster administrator) standard user for the second category
License keys
UNIX license keys
Synchrony components need two license keys to be installed on a cluster, one per node. For Windows, a third key may be needed and this case is described in the next section. The table below lists the license key information for each Component:
Component Automator Composer Gateway Number of license keys or specific behavior Only one key for the cluster One key per node One key per node
13
Component Integrator Messaging Process Manager Sentinel Transfer CFT InterPlay
Number of license keys or specific behavior One key per node One key per node One key per node Only one key for the cluster One key per node One key per node
Windows license keys

License key management is the same for Windows and UNIX, but MSCS can behave differently. There is a resource called "Network Name" that replaces the hostname of the current node. When an application is activated in a MSCS group and if this group contains a resource of this type, the hostname retrieved is the value entered into the field "name" in the general tab of this resource. This works only if the option "Use Network Name for Computer name" is selected at the installation of the MSCS application. In this case, it is necessary to manage a third key which depends on this new hostname. The two other keys match the hostnames of the nodes that are used during the test when the application is launched outside the cluster management. For more information refer to: MSCS: Network Name resource MSCS: Creating a Generic Service Application MSCS: Creating a Generic Application Resource
14
3 Cluster installation
IN THIS CHAPTER
This chapter describes how to install Synchrony components in a cluster environment. Before starting the installation, the following information is necessary (in addition to the standard installation information): The hostname of each node The shared directory of the group where the Component will be embedded The IP address of the group where the Component will be embedded The installation of a Synchrony Component on a cluster configuration is done directly by the Synchrony Installer. The following is performed: Installation on the first node Installation on the second or additional nodes To complete these steps, the Installer needs to be able to reach the shared disk. Consequently, the group of the cluster where this disk is embedded must be active on the nodes where the steps are executed.
Cluster installation checklist

Follow these steps for a thorough cluster installation: 1. Check the prerequisites of the configuration and retrieve (in addition to the parameters needed for a standard configuration) the following information: Hostname of each node and the license keys (refer to section License keys) IP Address of the group where the Component will be embedded o Local and shared disks o Access to a root and standard users (refer to section UNIX users). 2. Move or activate the group on the first node (refer to chapter 5 Cluster management).
o o
3. Install the Component on the first node (refer to section Installing the first node). 4. Install the scripts and test the Component (refer to sections Managing Synchrony scripts on UNIX and Testing a Synchrony Component on the first node). 5. Move the group to the second node (refer to chapter 5 Cluster management). 6. Install the component on the second node (refer to section Installing additional nodes). 7. Test the Component on the second node (same test as step 3). 8. Configure the Cluster Manager (refer to chapter 5 Cluster management). 9. Test for failover (refer to chapter 5 Cluster management).
Cluster installation
15
Installing the first node

Note: The installation on the first node must be performed in the advanced installation mode of the Synchrony Installer. The Synchrony Installer gathers all the parameters it needs from the user or from an input file and performs the Installation. It puts all static files on the local disk and all data on the shared disk. If an installed Component uses a database, the Installer initializes it. The cluster installation is similar to the standard installation with these differences: There are two installation directories (one on the local disk and one on the shared disk) During the cluster installation you are asked for the IP address of the cluster (do not use the default IP address of the node, it is different than the IP address of the cluster) If it is necessary, use the multi-key option
Node 1
Node 2
Installation on the first node
Database
Local Disk Shared disk
Local Disk
Figure 6: Synopsis of the installation on the first node
From the Synchrony Installer follow these steps to install the first node: 1. In the Installation mode screen select Advanced. 2. In the Architecture type screen select Cluster. 3. In the Cluster installation screen select First node. 4. In the Synchrony directories screen select the path to your local Installation directory and type the path to your Shared directory.
Cluster installation tion
16
Managing Synchrony scripts on UNIX

Script descriptions
The Cluster Manager uses scripts to communicate with the components. These scripts include: Start Stop Start And Wait Status Restart Suspend Note: On Red Hat Cluster, these scripts are replaced by a UNIX script that receives the name of the command to execute from the cluster monitor. The scripts for each component are delivered on the Synchrony Installation DVD in the corresponding component directories. Copy the script to a local directory of each node. The name of the local directory depends on your configuration. The architecture is the following: One Common directory One directory for each Component In each directory dedicated to the Component there is a set of scripts with the following syntax (these scripts are created by the installation step described in the next paragraph): <function>_<component>_cluster Where: <function>: Start o Stop o Startandwait o Status o Restart o Suspend <component>:
o o
The short name of the component without a version number (integrator, messaging, etc.)
Example: The script to start Synchrony Integrator is named start_integrator_cluster. Note: For Red Hat Linux, there is only one script with the syntax: component>_cluster
Script installation
These scripts are provided as a kit built with two sub-directories: common and Component. As the name indicates, the common directory can be shared by all Synchrony components.
17
The Component directory contains two mains scripts: Install_<component> Env_<component> To install the kit: 1. Locate the directory where the cluster scripts must be installed. This information is provided by the configuration manager. 2. If the component is going to be installed first, copy the two directories into the sub-directory. 3. If a Synchrony component has already been installed, copy only the Component directory. 1. In the directory of the component, run the script Install_<component>. After these steps, the Component directory contains the management scripts described in the previous section. Each directory dedicated to a component includes a script that contains all of the parameters used by the other scripts. This script works as a .profile file on UNIX. It initializes the environment variables used by the component. It contains two main variables used to switch to the UNIX installation user and to locate the shared directory of the cluster. It can also contain some variables used by the component itself. It has the following syntax: Env_<component> You must update this file with the following parameters:
Parameter LOCUSR DIR Value The UNIX user used to install the component The local installation directory
Testing a Synchrony Component on the first node

Note: The Component is tested as if the Cluster Manager is running it. The Cluster Manager has to be run by a root user. After the installation on the first node, it is necessary to do some testing to ensure that the configuration is correct. The goal of these tests is to: Verify that the Component can be managed by a root user with the scripts previously installed Verify that the Component is able to manage the IP address of the group
Testing on UNIX
The following tests must be run: 1. Run the status script to verify that the parameters in the script are correct and that the return code of the script is 1 (Not on Sun Cluster). 2. Run the start script. 3. Verify that the component is running. 4. Run the status script to verify that the script detects the activity of the component, i.e. that the return code is 0 (Not on Sun Cluster).
18
5. Run the stop script. 6. Verify that the component is correctly stopped. 7. Restart the component using the restart script. 8. Verify that the component is running. 9. Do some smoke tests with the component. For these tests, use the IP address of the group of the cluster.
Testing on Windows
The following tests must be run: 1. If the component can be started in the command mode, start and stop it to validate the installation. 2. If the component has been installed in service mode, start the service. 3. Do some smoke tests with the component. For the test, use the IP address of the cluster group.
Installing additional nodes

Note: The installation of the second or an additional node must be performed in the advanced installation mode of the Synchrony Installer. During the second step, the installation of the first node is cloned to the second or additional node. To complete this step, the Installer requires information about the local and shared directories from the user or from an input file. With this information, the Installer retrieves the parameters used during the first step and creates the environment locally. On the local disk it creates the same environment as the first local disk and, on Windows, it creates the services. It does not update the shared disk or the database. The installation is launched on the second or an additional node using the same options as the installation on the first node.
19
Node 1
Node 2
Installation on the first node
Local Disk Shared disk
Local Disk
Figure 7: second node
Synopsis of the installation on the
During the second step, the Installer retrieves information from the configuration file stored on the shared disk. The Installer clones the local disk of the additional node. The installation is launched on the second or an additional node using the following options: 1. In the Installation mode screen select Advanced. 2. In the Architecture type screen select Cluster. 3. In the Cluster installation screen select Additional node. 4. In the Synchrony directories screen select the path to your local Installation directory and type the path to your Shared directory. After this step, the Installer retrieves the parameters used during the installation of the first node. Depending on the Synchrony Component, it may display these parameters. It performs the installation on the local disk, but it does not update the shared disk or the database.
Installing scripts on the second node

Copy the scripts installed on the first node to the second node on the local disk and in the same directory. For details, refer to managing Synchrony scripts on UNIX.
Testing a Synchrony Component on the second node

The tests to you must run on the second node are identical to those run on the first node. Refer to the section in chapter 3 Testing a Synchrony Component on the first node.
Cluster installation tion
20
4 Cluster configuration
IN THIS CHAPTER
This chapter describes how to install Synchrony components in different situations as well as how to apply patches to the components in a cluster environment.
Various component installations

Installing two Synchrony components in two different groups
If you are installing several components in several groups, for example, Integrator in one group and Sentinel in another, the shared directory attached to each group is different (refer to the Advanced cluster architecture). In this case, it is necessary to make two distinct installations and it is mandatory to use two different local directories. Example: For a configuration where the shared disks are mounted on the directories /disk1 and /disk2 and the local directory is /usr/Axway/local the installation can be done with the following architecture: Sentinel is installed in the local directory: The shared directory is: Integrator is installed in the local directory: The shared directory is: /usr/Axway/local/disk1 /disk1/Axway/shared /usr/Axway/local/disk2 /disk2/Axway/shared
Installing multiple components sequentially

For components that are installed in two steps in the same environment, it is necessary to make the two installations start from the same first node. For example, Sentinel is installed first and then Integrator is installed later using the same shared disk. Example: If Sentinel and Integrator are installed sequentially on the same shared disk, the following workflow must be respected: Install the first node of Sentinel on NODE-A Install the second node of Sentinel on NODE-B Install the first node of Integrator on NODE-A Note: The Installer will refuse to start the installation of the first node of Integrator from NODE-B.
Cluster configuration
21
Applying patches
Note: Applying patches must be performed in the advanced installation mode of the Synchrony Installer. Applying patches to a cluster environment is different than a standard environment. Some Synchrony components support "Hot Patching", which means that you can apply a patch to the passive node while the Component is in use on the other node. This section describes how to apply patches to each Component that supports clustering. In each component example below A is the active node and B is the passive node.
Automator
To apply a patch to Automator (Note: This method is valid for the Production and the Domain Sever (The Modeling Server cannot be installed on a cluster): 1. Make sure A is the active node. 2. Stop Automator: In HACMP & HP Serviceguard use the suspend script. In Sun Cluster use the disable command (need to be a root user). o In MSCS use the stop command. 3. Apply the patch.
o o
4. Restart Automator:
o o o
In HACMP & HP Serviceguard use the restart script. In Sun Cluster use the enable command. In MSCS use the start command.
Composer
To apply a patch to Composer: 1. Make sure A is the active node. 2. Stop Composer: In HACMP & HP Serviceguard use the suspend script. In Sun Cluster use the disable command (need to be a root user). o In MSCS use the stop command. 3. Apply the patch.
o o
4. Restart Composer:
o o o
Gateway
To apply a patch to Gateway: 1. Make sure that A is the active node. 2. Apply the patch to node B (the passive node).
22
3. Switch nodes (failover). 4. Apply the patch to node A, which is now passive.
Integrator
To apply a patch to Integrator: 1. Make sure that A is the active node. 2. Apply the patch to node B (the passive node). 3. Switch nodes (failover). 4. Apply the patch to node A, which is now passive.
InterPlay
To apply a patch to InterPlay, you must follow these steps: 1. Make sure that A is the active node. 2. Apply the patch to node B (the passive node). 3. Switch nodes (failover). 4. Apply the patch to node A, which is now passive.
Messaging
To apply a patch to Messaging: 1. Make sure that A is the active node. 2. Apply the patch to node B (the passive node). 3. Switch nodes (failover). 4. Apply the patch to node A, which is now passive.
ProcessManager
To apply a patch to ProcessManager, you must follow one of these sets of steps depending on if the patch can be applied while the component is in use. If the patch can be applied while the Process Manager is in use: 1. Make sure that A is the active node. 2. Apply the patch to node B (the passive node). 3. Switch nodes (failover). 4. Apply the patch to node A, which is now passive. If the patch cannot be applied while the ProcessManager is in use: 1. Make sure A is the active node. 2. Stop ProcessManager. In HACMP & HP Serviceguard use the suspend script. o In Sun Cluster use the disable command (need to be a root user). o In MSCS use the stop command. 3. While ProcessManager is stopped, apply the patch to A, the active node. During this step, the patch asks if it must run an update to the database, answer YES.
o
23
4. Apply the patch to B, the passive node. 5. Restart ProcessManager.

o o o
Sentinel
To apply a patch to Sentinel: 1. Make sure A is the active node. 2. Stop Sentinel. In HACMP & HP Serviceguard use the suspend script. o In Sun Cluster use the disable command (need to be a root user). o In MSCS use the stop command. 3. Apply the patch.
o
4. Restart Sentinel.
o o o
Transfer CFT
To apply a patch to Transfer CFT, you must follow these steps: 1. Make sure that A is the active node. 2. Apply the patch to node B (the passive node). 3. Switch nodes (failover). 4. Apply the patch to node A, which is now passive.
24
5 Cluster management
IN THIS CHAPTER
This chapter includes basic cluster management guidelines for Cluster Administrators.
Cluster administration guidelines

Administrative user
You must have root permission to manage and configure a cluster. It is mandatory that you open a telnet or SSH session on the server as a root user (refer to UNIX users). In general, these operations can be done from any node. To commit these updates, it is necessary that the Cluster Manager is active on all the nodes in the configuration. The session opened by a root user must be reserved for the administration of the cluster and does not have to be used to install the Synchrony components. Even if the commands are different, the clusters (HACMP, Sun Cluster or HP Serviceguard) behave the same.
Differences between a production and test site

At a production site, when a node is started, the Cluster Manager starts automatically. The Cluster Manager, depending on the configuration and the environment, decides whether to start the groups or not. At a test site, these operations can be done manually. The mains commands are: Launch the Cluster Manager Launch the activity on the two nodes Manage the activity of a group Manage the activity of a resource
HACMP
HACMP Concepts
This section describes selected HACMP concepts that are useful for installing Synchrony components in AIX cluster configuration.
Clusters
In HACMP, a cluster is a configuration of multiple nodes. The HACMP software supports from two to thirty-two nodes in a cluster.
Cluster management
25
Nodes
Nodes form the core of an HACMP cluster. A node in the Synchrony HACMP environment is a processor that runs: AIX HACMP software One or more Synchrony component applications In an HACMP cluster, each node is identified by a unique hostname. A node may own a set of resources: disks, volume groups, file systems, networks, network addresses, and applications. Typically, a node runs a Synchrony component server application that accesses data on the shared external disks. Each node has access to one or more shared external disk devices. A shared external disk device is a disk physically connected to multiple nodes. The shared disk stores mission-critical data typically mirrored or RAID-configured for data redundancy. A node in an HACMP cluster must also have internal disks that store the operating system and the application binaries. These disks are not shared.
Resource groups
Resource groups are a set of cluster resources handled as one unit by HACMP. Resource groups are configured by the user. You can configure startup, failover and fallback policies, customizing the resource group behavior to your needs. An HACMP resource group contains a set of different resources. Synchrony components are viewed in HACMP as Application resources.
Resources
A resource in HACMP terminology is a cluster entity, such as a disk, file system, network interface, application monitor or Synchrony component server that is made highly available.
Application resources
Applications are managed by defining the application in HACMP as an application resource. The application server includes application start and stop scripts. HACMP uses these scripts when the application needs to be brought online or offline on a particular node, to keep the application highly available. This object must be associated with a resource group.
Custom application monitor resources

The Custom Application Monitor resource contains the configuration parameters that enable HACMP to check for process failure or other application failures. When a failure occurs, HACMP automatically takes action to restart the application. The values of Custom Application Monitor parameters include the names of the start and stop scripts and the restart conditions.
Cluster management
26
HACMP management basics

User to be used for these operations
All commands must be run by a root user (refer to UNIX users).
HACMP: Planning the installation of a Synchrony component

To install a new application or a resource in HACMP, follow these steps: 1. Verify the pre-requisites. 2. Verify that both nodes of the cluster are running. 3. Create an Application Server. 4. Create a Custom Application Monitor linked with the Application Server. 5. Link the Application Server to the Group. 6. Verify the update and synchronize the two.
HACMP: Management HACMP: Starting the user interface

From the UNIX prompt, enter: >smitty hacmp The following screen is displayed:
HACMP for AIX Move cursor to desired item and press Enter. Initialization and Standard Configuration Extended Configuration System Management (C-SPOC) Problem Determination Tools
F1=Help F9=Shell
F2=Refresh F10=Exit
F3=Cancel Enter=Do
F8=Image
Figure 8: HACMP main menu
HACMP: Managing services

In some configurations (usually at a test site) the HACMP services are not started during boot. It is mandatory to have the nodes of the cluster configuration active for both synchronization and failover. To start cluster services: 1. From the Manage HACMP services menu, select Start Cluster Services. 2. Then press Enter to start the services. Once the services have started, Show Cluster Services should display a screen that displays the Subsytem, Group, PID and Status information. If the services are started the status is displayed as active. If the screen shows a status of inoperative, you must start the services.
Cluster management
27
HACMP: Create the Application Server

Warning: In this step, HACMP does not verify if the scripts exist or if they are executable. The verification is done in the step, Verify and synchronize. 1. From the main panel (refer to Figure 8 ), navigate through the different sub-menus using the following path: Initialization and standard configuration/Configure resources to make highly available/Configure application servers/Add an application server The Add Application screen is displayed. 2. In the fields, enter the following values:
Field Server name Start script Stop script Value The name of the component. For example: Integrator The name of the script that starts the Synchrony component (refer to section Managing Synchrony scripts on UNIX)
X
The name of the script that stops the Synchrony component (refer to section Managing Synchrony scripts on UNIX)
X
3. Using Integrator as an example, the screen displays:

Add Application Server Type or select values in entry fields. Press Enter AFTER making all desired changes. [Entry Fields] Integrator [Integrator] [/hascripts/Integrator/start_Integrator_Cluster] [/hascripts/Integrator/stop_Integrator_Cluster]
Server Name New Server Name Start Script Stop Script
F1=Help F5=Reset F9=Shell
F2=Refresh F6=Command F10=Exit
F3=Cancel F7=Edit Enter=Do
F4=List F8=Image
Figure 9: HACMP :Typical Application Server screen
HACMP: Create the Custom Application Monitor

Warning: In this step, HACMP does not verify if the scripts exist or if they are executable. That is done in the Verify and synchronize screen. From the main screen (refer to Figure 8), navigate through the different submenus using the following path: Extended configuration/Extended resource configuration/HACMP extended resources configuration/Configure HAMCP application monitoring/Configure custom application monitors/Add a custom application monitor The Add Custom Application Monitor screen is displayed. This table provides the basic values to be used for the standard installation. The parameters can be modified.
Cluster management
28
Field Monitor name Application Server(s) to monitor Monitor mode Monitoring method Monitor interval Hung monitor signal Stabilization interval Restart count Restart interval Action on application failure Notify method Cleanup method Restart method
Value Generally, the same name as the component to be monitored. For example Integrator. The name of the component to be monitored. For example; Integrator. Keep Long-running-monitoring The name of the script to be used to monitor the Synchrony component (refer to Managing Synchrony scripts on UNIX). Enter 30 Enter 9 Enter 30 Enter 3 Enter 198 Enter failover Leave blank Leave blank The name of the script to be used to restart the Synchrony component (refer to Managing Synchrony scripts on UNIX).
An example for Integrator:

Add Custom Application Monitor Type or select values in entry fields. Press Enter AFTER making all desired changes. [Entry Fields] * Monitor Name Integrator Application Server(s) to Monitor Integrator + * Monitor Mode [Long-running monitoring] + * Monitor Method [/hascripts/Synchrony/status_Integrator_Cluster] Monitor Interval [30] # Hung Monitor Signal [9] # * Stabilization Interval [30] # Restart Count [3] # Restart Interval [198] # * Action on Application Failure [fallover] + Notify Method [] Cleanup Method [] Restart Method [/hascripts/Integrator/start_Integrator_Cluster] F1=Help F5=Reset F9=Shell F2=Refresh F6=Command F10=Exit F3=Cancel F7=Edit Enter=Do F4=List F8=Image
Figure 10: Typical Custom Application Monitor
HACMP: Link the Application Server to the group

The Application Server must be embedded in a group. The following paragraph describes this step. 1. From the main screen (refer to Figure 8), navigate through the different sub-menus using the following path: Initialization and standard configuration /Configure HACMP resource groups
Cluster management
29
2. In the HACMP Resource Groups screen, select:

o o
Change/Show resources for a resource group (standard) Do not select: Change/Show a resource group
3. From the list of available cluster groups, select a group. The following screen displays Rg_Http as an example.
Change/Show All Resources and Attributes for a Resource Group Type or select values in entry fields. Press Enter AFTER making all desired changes. [Entry Fields] Rg_Http jack joe
Resource Group Name Participating Nodes (Default Node Priority) Startup Policy Fallover Policy Fallback Policy
Online On First Available Node Fallover To Next Priority Node In The List Never Fallback + + + + +
Service IP Labels/Addresses [william] Application Servers [test] Volume Groups [san] Use forced varyon of volume groups, if necessary true Filesystems (empty is ALL for VGs specified) [/intranet]
F1=Help F5=Reset F9=Shell
F2=Refresh F6=Command F10=Exit
F3=Cancel F7=Edit Enter=Do
F4=List F8=Image
In this example, one application named test is managed by HACMP. It is possible to have a set of applications managed in the same group. In the example used in this document, the list of applications made are with the resources Test and Integrator. 4. Make your changes and validate the updates with the enter key. The following screen is displayed:
COMMAND STATUS Command: OK stdout: no stderr: no
Before command completion, additional instructions may appear below.
F1=Help F8=Image n=Find Next
F2=Refresh F9=Shell
Prompt of the confirmation of the command

F3=Cancel F10=Exit
F6=Command /=Find
HACMP: Verify and synchronize the two nodes

All updates must be broadcast to the other node. From the main screen (refer to Figure 8), navigate through the different sub-menus using the following path: Initialization and standard configuration /Verify and synchronize HACMP configuration
Cluster management
30
The following screen should display:

COMMAND STATUS Command: OK stdout: yes stderr: no
Before command completion, additional instructions may appear below. [TOP]
Verification to be performed on the following: Cluster Topology Cluster Resources Retreiving data from available cluster nodes. Verifying Cluster Topology...
Prompt of the confirmation of the command
This could take a few minutes....
----------- follow-up to the verify command -----------------[MORE...53] F1=Help F8=Image n=Find Next F2=Refresh F9=Shell F3=Cancel F10=Exit F6=Command /=Find
HACMP: Managing a group

HACMP Resource Group and Application Management menu From the main panel (refer to Figure 8), navigate through the different sub-menus using the following path: System Management (C-SPOC) /HACMP Resource Group and Application Management The following menu is displayed:
HACMP Resource Group and Application Management Move cursor to desired item and press Enter. Bring a Resource Group Online Bring a Resource Group Offline Move a Resource Group to Another Node Suspend/Resume Application Monitoring Application Availability Analysis
F1=Help F9=Shell
F2=Refresh F10=Exit
F3=Cancel Enter=Do
F8=Image
Figure 11: HACMP Resource Group and Application Management menu
HACMP: Starting the group

1. From the management menu (refer to Figure 11), select: Bring a Resource Group Online The management application displays the list of groups available in the cluster. 2. Select the target node and press Enter.
Cluster management
31
3. When the target node is selected, the Manager starts the group and displays the following screen:
COMMAND STATUS Command: running stdout: yes stderr: no
Before command completion, additional instructions may appear below. Attempting to bring group Rg_Http until this indicator Wait offline on node joe.
switches to OK Waiting for cluster to process the resource group movement request....
Waiting for the cluster to stabilize...
HACMP: Stopping the group

From the management panel (refer to Figure 11), select: Bring a Resource Group Offline The rest of the dialogue is the same as the start operation.
HACMP: Moving a Group from one node to the other

From the management panel (refer to Figure 11), select: Move a Resource Group to Another Node The rest of the dialogue is the same as the start operation.
Sun Cluster
Sun Cluster concepts
This topic describes selected Sun cluster concepts that are useful for installing Synchrony components in a Sun cluster configuration. This topic includes the following sections: Clusters Nodes Groups Applications
Clusters
At Sun, a cluster is a configuration of multiple nodes. The Sun cluster software supports from two to thirty-two nodes in a cluster.
Nodes
Nodes form the core of a Sun cluster. A node in the Synchrony Sun cluster environment is a processor that runs: Solaris Sun cluster software One or more Synchrony component applications
Cluster management
32
In a Sun cluster, each node is identified by a unique hostname. A node may own a set of resources: disks, volume groups, file systems, networks, network addresses, and applications. Typically, a node runs a Synchrony component server application that accesses data on the shared external disks. Each node has access to one or more shared external disk devices. A shared external disk device is a disk physically connected to multiple nodes. The shared disk stores mission-critical data typically mirrored or RAID-configured for data redundancy. A node in a Sun cluster must also have internal disks that store the operating system and application binaries. These disks are not shared.
Groups
Groups are a set of cluster applications handled as one unit by Sun Cluster. Groups are configurable by the user. You can configure startup, failover and fallback policies, customizing the group behavior to your needs. A Sun Cluster group contains a set of different applications.
Resources
Synchrony components are managed by Sun Cluster after being defined as a resource. The resource includes application start and stop scripts. Sun Cluster uses these scripts when the application needs to be brought online or offline on a particular node, to keep the application in high availability mode. This object must be associated with a group.
Sun Cluster management basics

In this section you find a list of the basics commands used to configure a Sun cluster to manage a Synchrony Component.
User to be used for these operations

All these commands must be done by root user (refer to section UNIX users).
Sun Cluster: Planning the installation of a Synchrony Component

To install a new application or a resource in Sun Cluster, follow these steps: 1. Verify the pre-requisites. 2. Create a Resource. 3. Switch the resource in the enable state.
Sun Cluster: Management

The Sun Cluster can be managed using a command line interface or a graphical user interface (GUI). Unfortunately, the GUI is not always available at all sites. Consequently, this section describes the command line interface.
Cluster management
33
Sun Cluster: Create a resource

To create a resource, use the command: Node1# scrgadm -a -j <Ressource_Name> -g <Group_Name> -t SUNW.gds -x Start_command=<Start_Script> \ -x Stop_command=<Stop_Script> \ -x Network_aware=True \ -y Port_list=<Port_To_Be_Checked> \ -y Start_timeout=60 Where:
Field Resource Name Group_Name Start Script Stop Script Port_To_Be_Checked Value The name of the Resource. For example : Integrator The name of Group where is Resource is embedded The name of the script that starts the Synchrony Component (refer to section Managing Synchrony scripts on UNIX) The name of the script that stops the Synchrony Component (refer to section Managing Synchrony scripts on UNIX) The list of the IP ports to be checked by the Sun Cluster. The syntax is for one "port 1234/tcp" for a list of ports, each port separate by a coma (",")."1234/tcp,1235/tcp" The quotation marks are mandatory and part of the syntax
Sun Cluster: Delete a resource

To delete a resource, use the command: Node1# scrgadm -r -j <Ressource_Name> Where:
Field Resource Name Value The name of the Resource to be deleted
Sun Cluster: View the configuration

To display the configuration of the cluster, use the command: Node1# clresource show
Resource_project_name: Enabled{node1}: Enabled{node2}: Monitored{node1}: Monitored{node2}: Resource: Type: Type_version: Group: R_description: Resource_project_name: Enabled{node1}: Enabled{node2}: Monitored{node1}: Monitored{node2}: Resource: default True True True True res-nfs-splus SunW.HAStoragePlus:4 4 RGnfs default True True True True res-nfs-hanfs
Cluster management
34
Type: Type_version: Group: R_description: Resource_project_name: Enabled{node1}: Enabled{node2}: Monitored{node1}: Monitored{node2}: Resource: Type: Type_version: Group: R_description: Resource_project_name: Enabled{node1}: Enabled{node2}: Monitored{node1}: Monitored{node2}:
SunW.nfs:3.2 3.2 RGnfs default True True True True Synchrony_Integrator SunW.gds:6 6 RGnfs default True True True True
It is important to check these statuses
Sun Cluster: Verifying the status of the cluster

To display the status of the cluster and the resources: node1# clresource status The following screen is shown:
=== Cluster Resources === Resource Name ------------res-nfs-lname Node Name --------node1 node2 node1 node2 node1 node2 node1 node2 State ----Offline Online Offline Online Offline Online Offline Online Status Message -------------Offline - LogicalHostname offline. Online - LogicalHostname online. Offline Online Offline - Completed successfully. Online - Service is online. Offline Online - Service is online.
res-nfs-splus
res-nfs-hanfs
Synchrony_Integrator
You can refer to that all the resources are running on node2.
Sun Cluster: Disable a resource

The disable command stops the resource without interfering with the other resources in the group. The resource stays in this state and it is not restarted until the enable or the start group command is run. 1. To disable a resource, use the command: node1# clresource disable Synchrony_Integrator 2. After running the command, run clresource show, it displays:
Resource: Type: Type_version: Group: R_description: Resource_project_name: Enabled{node1}: Enabled{node2}: Monitored{node1}: Monitored{node2}: Synchrony_Integrator SunW.gds:6 6 RGnfs default False False True True
Enabled resource is False
Cluster management
35
Sun Cluster: Enable a resource

The enable command starts the resource if the cluster group is active or enables it to restart when the group is restarted. 1. To enable a resource, use the command: node1# clresource enable Synchrony_Integrator 2. After running the command, run clresource show, it displays:
Resource: Type: Type_version: Group: R_description: Resource_project_name: Enabled{node1}: Enabled{node2}: True Monitored{node2}: Synchrony_Integrator SunW.gds:6 6 RGnfs
Enabled resource is True
default True Trus Monitored{node1}: True
Sun Cluster: Starting a group

The command to start the group on the first available node without enabling the resources and fault monitors is: node1# scswitch z g groups To enable the resources and fault monitors: node1# scswitch Z g groups The command to start the group on a dedicated node without enabling the resources and fault monitors is: node1# scswitch z g groups h node To enable the resources and fault monitors: node1# scswitch Z g groups h node
Sun Cluster: Stopping a group

The command to stop a group is: node1# scswitch Q -g goups
Sun Cluster: Stopping a cluster

The command to stop a cluster is: node1# scswitch Q
HP Serviceguard
HP Serviceguard concepts
Clusters
At HP, a cluster is a configuration of multiple nodes. The HP Serviceguard cluster software supports from two to thirty-two nodes in a cluster.
Cluster management
36
Nodes
Nodes form the core of a HP cluster. A node in the Synchrony HP Serviceguard environment is a processor that runs: HP-UX HP Serviceguard software One or more Synchrony component applications
In an HP Serviceguard, each node is identified by a unique hostname. A node may own a set of resources: disks, volume groups, file systems, networks, network addresses, and applications. Typically, a node runs a Synchrony component server application that accesses data on the shared external disks. Each node has access to one or more shared external disk devices. A shared external disk device is a disk physically connected to multiple nodes. The shared disk stores mission-critical data typically mirrored, or RAID-configured for data redundancy. A node in an HP Serviceguard must also have internal disks that store the operating system and application binaries. These disks are not shared.
Package
Packages are a set of cluster applications handled as one unit by HP Serviceguard. Packages are configurable by the user. You can configure startup, failover and fallback policies, customizing the group behavior to your needs. The applications handled by the package are called Services.
Service
Synchrony components are managed by HP Serviceguard after being defined as a service. The service includes application start scripts. HP Serviceguard uses these scripts when the application needs to be brought online on a particular node, to keep the application in high availability mode. When this script stops, HP Serviceguard takes it into consideration and enters the failover process.
HP Serviceguard management basics

In this section there is a list of basic commands used to configure an HP Serviceguard to manage a Synchrony component.
User to perform these operations

All these commands must be done by the root user.
HP Serviceguard: Management
HP Serviceguard can be managed using a command line interface or a graphical user interface (GUI). The GUI is not always available at some sites, therefore this section describes the command line interface.
Cluster management
37
HP Serviceguard: Adding a service

A service or an application can be added to a Serviceguard package by editing the *.conf and *.cntl files of the package. For example, if the package name is ptac11 the files are named ptac11.cntl (control file) and ptac11.conf (configuration file). The following example describes how to add three components named Component1, Component2 and Component3. 1. In the *.cntl file (control file), locate the section named SERVICE NAMES AND COMMANDS and add the following lines:
SERVICE_NAME[0]="Component1" SERVICE_CMD[0]="<INSTALLATIONDIRECTORY>/Scripts/Component1/startandwait_Component1_cluster" SERVICE_RESTART[0]="-r 2" SERVICE_NAME[1]="Component2" SERVICE_CMD[1]="<INSTALLATIONDIRECTORY>/Scripts/Component2/startandwait_Component2_cluster" SERVICE_RESTART[1]="-r 2" SERVICE_NAME[2]="Component3" SERVICE_CMD[2]="<INSTALLATIONDIRECTORY>/Scripts/Component3/startandwait_Component3_cluster" SERVICE_RESTART[2]="-r 2"
1. In the control file, locate the procedure customer_defined_run_cmds and add the components stop scripts:
# START OF CUSTOMER DEFINED FUNCTIONS # This function is a place holder for customer define functions. # You should define all actions you want to happen here, before the service is # started. You can create as many functions as you need. function customer_defined_run_cmds { # ADD customer defined run commands. : # do nothing instruction, because a function must contain some command. <INSTALLATION-DIRECTORY>/Scripts/Component1/stop_Component1_cluster <INSTALLATION-DIRECTORY>/Scripts/Component2/stop_Component2_cluster <INSTALLATION-DIRECTORY>/Scripts/Component3/stop_Component3_cluster test_return 51 }
2. In the *.conf file (configuration file), locate the section where the services are defined and add the following lines:
SERVICE_NAME Component1 SERVICE_FAIL_FAST_ENABLED no SERVICE_HALT_TIMEOUT 300 SERVICE_NAME Component2 SERVICE_FAIL_FAST_ENABLED no SERVICE_HALT_TIMEOUT 300 SERVICE_NAME component3 SERVICE_FAIL_FAST_ENABLED no SERVICE_HALT_TIMEOUT 300
3. Synchronize the two nodes using the rcp command: rcp -r `pwd` OTHER_NODE:` 4. Check the syntax of the *.conf file: cmcheckconf -p <configuration file>
Cluster management
38
5. Apply the configuration: capplyconf -p <configuration file>
HP Serviceguard: Verifying the status of the configuration

The command to display the configuration of the cluster: node01# cmviewcl
HP Serviceguard: Starting a node

The command to start a node is: node01# cmrunnode node
HP Serviceguard: Stopping a node

The command to stop a node is: node01# cmhaltnode -f node
HP Serviceguard: Starting a package

The command to start a package is: node01# cmrunpkg -n node package
HP Serviceguard: Stopping a package

The command to stop a cluster is: node01# cmhaltpkg package
Linux Cluster Suite

Related software
The Red Hat Cluster Suite includes software to create a high availability and load balancing cluster, it currently does not contain functionality for distributed computing.
Linux Cluster Suite Concepts

This topic describes select Linux Cluster Suite concepts that are useful for installing Synchrony components in a Linux Cluster Suite configuration. This topic includes the following sections: Clusters Nodes Resources Services
Clusters
A cluster is a configuration of multiple nodes.
Cluster management
39
Nodes
Nodes form the core of a Linux Cluster Suite. A node in the Synchrony Linux Cluster Suite environment is a processor that runs: Red Hat Cluster Suite for Red Hat Enterprise Linux 5 One or more Synchrony component applications
In a Linux Cluster Suite, each node is identified by a unique hostname. A node has a set of resources: file systems (GFS/NFS), networks, network addresses, and applications. Typically, a node runs a Synchrony component server application that accesses data on the shared external disks. Each node has access to one or more shared external disk devices. A shared external disk device is a disk physically connected to multiple nodes. The shared disk stores mission-critical data typically mirrored or RAID-configured for data redundancy. A node in a Linux Cluster Suite must also have internal disks that store the operating system and application binaries. These disks are not shared.
Resources
Synchrony components are managed by Linux Cluster Suite after being defined as a resource. The resource includes application start and stop scripts. Linux Cluster Suite uses these scripts when the application needs to be brought online or offline on a particular node, to keep the application in high availability mode. This object must be associated with a service.
Services
Services are a set of cluster applications handled as one unit by Linux Cluster Suite. Services are configurable by the user. You can configure startup and failover policies, customizing the service behavior to your needs. A Linux Cluster Suite services contains a set of different resources.
Linux Cluster Suite management basics

The next section lists the basic commands to use to configure a Linux Cluster Suite to manage a Synchrony component. There are two ways to update the configuration: Use the graphical interface Edit the cluster.conf file
This section gives an overview of these two methods, but we strongly advise you to read the Red Hat documentation. The first method is strongly recommended by Red Hat. If the workstation used does not support an X Windows environment, the second method can be used. All the commands must be done by the root user (refer to section UNIX users.).
GUI procedure
Open an X Windows environment and enter the command: system-config-cluster Refer to next page.
Cluster management
40
The following screen is displayed, follow the instructions:
Typically, the Synchrony component scripts are defined in the Resources property:
Cluster management
41
The link between the resource and the cluster is defined in the Service property.
Command line procedure

This paragraph describes how to manage the cluster.conf configuration file.
The cluster.conf file

The configuration of the cluster is stored in the cluster.conf file in the /etc/cluster directory. The best method to update the cluster configuration is: 1. Make a copy of the cluster.conf file and add the version number as the suffix. For example: cluster.conf.10 2. Update the header of the file. 3. Update the configuration. 4. Commit the update. Refer to the next section for detailed information on the above steps.
Management of the configuration file

The configuration file must be copied the first time, as described in the previous paragraph. The best method is to add the version number to the end of the name.
Cluster management
42
Example: If the header of the cluster.conf file contains the following line <cluster config_version="9" name="name_of_the_cluster"> It must be copied into a new file named cluster.conf.10. The config_version tag must be incremented. Example: <cluster config_version="10" name="name_of_the_cluster"> In order for the updates to be committed, this step is mandatory. Then, the file can be updated. It is possible to validate the configuration with the command: rg_test_test <file_name> Then, commit the update by entering the command: ccs_tool update <file_name> This command commits the new configuration and synchronizes the other nodes of the cluster.
Adding a new component (step 4)

Open the cluster.conf XML file and add a line for each script file associated with the component in the resource section. Example: <resources> <script file="/etc/init.d/synchrony-messaging" name="synchrony-messaging"/> <script file="/etc/init.d/synchrony-process-manager" name="synchrony-process-manager"/> <script file="/etc/init.d/synchrony-integrator" name="synchrony-integrator"/> <script file="/etc/init.d/synchrony-event-router" name="synchrony-event-router"/> <ip ref=123.123.1.123/> <fs ref=Name_of_the_disk/> </resources> If there is a dependency between the different resources, these definitions must be embedded. Example: The service is named synchrony. It contains an IP address, a shared disk named shared and a set of Synchrony components. The installed components are Sentinel Event Router, Messaging, Process Manager and Integrator. The last three components are started after the Event Router, so they are embedded in its definition. <service autostart="1" name="synchrony"> <ip ref="192.168.0.200"> <fs ref="shared"> <script ref="synchrony-event-router"> <script ref="synchrony-messaging"/> <script ref="synchrony-process-manager"/> <script ref="synchrony-integrator"/> </script>
Cluster management
43
</fs> </ip> </service>
Managing the Linux Cluster

This section gives a brief overview of some Linux Cluster commands. For more information, it is strongly advised to read the Red Hat documentation.
Display the status of the cluster

It is possible to check the status of the cluster with the command clustat. Basically, without parameters, this command displays the status of the entire cluster. Example: [root@userid~]# clustat Member Status: Quorate Member Name ------ ---node10.example.com node11.example.com Service Name ------- ---synchrony Status -----Online, Local, rgmanager Online, rgmanager Owner (Last) ----- -----node10.example.com State ----started
With the parameter -i <delay> it displays cluster status and refresh the status every <delay> seconds. With the parameter -s <service> it displays the status of the specified service. Example: The command clustat i 10 s synchrony displays the following status: Service Name Owner (Last) State ------- -------- ---------synchrony node10.example.com started The screen is refreshed every 10 seconds.
Managing the service

The command clusvcadm is used to manage a group and: Stop, or disable, the service Start, or enable, the service Move, or relocate, the service from one node to the other.
Function Disable a service Enable a service on the local node Enable a service according to failover domain rules Enable a service on a specific node Relocate a service Relocate a service on a specific node Command to be used cluscvadm d <service> cluscvadm e <service> cluscvadm e <service> -F cluscvadm e <service> -m <node> cluscvadm r <service> cluscvadm r <service> -m <node>
Cluster management
44
Example of a complete cluster.conf file: This example comes from a test bed used for this documentation. <?xml version="1.0"?> <cluster config_version="18" name="jstd-aaclus01"> <fence_daemon post_fail_delay="0" post_join_delay="3"/> <clusternodes> <clusternode name="cluster-10.example.com" nodeid="1" votes="1"> <fence> <method name="1"> <device domain="system1" name="cluster-10-fence"/> </method> </fence> </clusternode> <clusternode name="cluster-11.example.com" nodeid="2" votes="1"> <fence> <method name="1"> <device domain="system2" name="cluster-11-fence"/> </method> </fence> </clusternode> </clusternodes> <cman expected_votes="1" two_node="1"/> <fencedevices> <fencedevice agent="fence_xvm" name="cluster-10-fence"/> <fencedevice agent="fence_xvm" name="cluster-11-fence"/> </fencedevices> <rm> <failoverdomains/> <resources> <script file="/etc/init.d/synchrony-messaging" name="synchronymessaging"/> <script file="/etc/init.d/synchrony-process-manager" name="synchrony-process-manager"/> <script file="/etc/init.d/synchrony-integrator" name="synchrony-integrator"/> <script file="/etc/init.d/synchrony-event-router" name="synchrony-event-router"/> <ip address="192.168.0.200" monitor_link="1"/> <fs device="/dev/sda" force_fsck="1" force_unmount="1" fsid="64480" fstype="ext3" mountpoint="/opt/shared" name="shared" options="" self_fence="0"/> </resources> <service autostart="1" name="synchrony"> <ip ref="192.168.0.200"> <fs ref="shared"> <script ref="synchrony-event-router"> <script ref="synchrony-messaging"/> <script ref="synchrony-process-manager"/> <script ref="synchrony-integrator"/> </script> </fs> </ip> </service> </rm> </cluster>
Cluster management
45
Veritas Cluster Server for Linux

Related software
The Veritas Cluster Server for Linux is included in Veritas Storage Foundation. This software creates a high availability and load balancing cluster. Currently, it does not contain functionality for distributed computing.
Veritas Storage Foundation Concepts

This topic describes select Veritas Storage Foundation concepts that are useful for installing Synchrony components in a Veritas Storage Foundation configuration. This topic includes the following sections: Clusters Nodes Services Group Resources
Clusters
A cluster is a configuration of multiple nodes.
Nodes
Nodes form the core of a Veritas Storage Foundation. A node in the Veritas Storage Foundation environment is a processor that runs: Veritas Storage Foundation One or more Synchrony component applications In a Veritas Storage Foundation, each node is identified by a unique hostname. A node has a set of Services Group which contains resources as the definition of shared file system, the shared IP address and the application (Synchrony). Typically, a node runs a Synchrony component server application that accesses data on shared external disks. Each node has access to one or more shared external disk devices. A shared external disk device is a disk physically connected to multiple nodes. The shared disk stores mission-critical data typically mirrored or RAID-configured for data redundancy. A node in a Veritas Storage Foundation must also have internal disks that store the operating system and application binaries. These disks are not shared.
Groups
Groups are a set of Resources which have to run together on the same node.
Resources
Resources are a set of cluster applications handled as one unit by Veritas Storage Foundation. Resources are configurable by the user. You can configure startup and failover policies, customizing the services to your own needs. A Veritas Storage Foundation service contains a set of different resources.
Cluster management
46
Type of Resource Application IP LVLMLogicalValue LVMVolumeGroup Mount
Description Contains the description of the application itself Contains the definition of the shared IP address These 3 resources define the shared disk The name of the mounted disk can be found in the Mount definition
GUI procedure
The Veritas Cluster Manager must be installed on the PC. Start it and connect to one of the configuration nodes. The following screen is displayed, follow the instructions:
Each branch can be deployed to give the following views.
Cluster management
47
This view gives the description of a resource type application.
This view gives the description of a resource type IP address (the shared IP address).
Cluster management
48
This view gives a description of the shared disk.
Typically, the Synchrony component is defined as a resource type application which is include in a Service Group. Creation of a resource application To create a resource application: 1. Right-click on the target group and select Add Ressource.
Cluster management
49
2. Enter a Resource name and select the resource type as Application.
3. Enter the full pathname to the start, stop, status and clean scripts.
For example:
Cluster management
50
MSCS
MSCS Concepts
This section describes some selected MSCS concepts that are useful for installing Synchrony components in Windows cluster configurations. Clusters and nodes Groups and resources Virtual servers Failover: Moving groups
MSCS Clusters and nodes

In MSCS, a cluster is a configuration of two nodes. An MSCS cluster cannot have more than two nodes. Nodes perform the processing work of the application. Each node is an independent computer system. The cluster appears to network clients as a single server. For MSCS, both nodes must be running on Windows 2003 Server. Nodes in a cluster communicate using their Cluster services. The Cluster service keeps track of the current state of the nodes within a cluster and determines when a group and its resources should failover to the alternate node.
MSCS Groups and resources

A Microsoft Cluster Server (MSCS) configuration is based on the creation of groups. Groups are virtual servers, which can be executed on either node of the cluster. Each cluster has strictly two nodes.
Resources
A group has different types of resources. A resource is any entity that can provide a service to a client, can be taken offline and brought online by the MSCS clustering software. The network applications, data files and other tools you install on cluster nodes are cluster resources. A resource is hosted on only one node. You configure the resource to failover from one node to the other in response to a failure. MSCS organizes resources by type.
Resource groups
A resource group consists of dependent or related resources. Dependent resources require other resources in order to operate successfully. Because all resources in a group move between nodes as a unit, dependent or related resources never span a single group boundary (resources cannot be dependent on resources in other groups). A group can run on only one node at a time.
Cluster management
51
Resource groups for Synchrony component clusters

Synchrony component server installations require resource groups comprising of the following resources: IP Address The Group resource IP address is the network address attached to the cluster. Regardless of the physical node on which the group runs, the IP address is always the same. In the example given in this document, the DNS for this group is set to wtcluster00a. The network name is associated with the IP address 172.16.4.43 Network Name The Group Resource network name corresponds to the HostName of the virtual server. As for the IP address, this name is always the same regardless of the physical node on which the group runs. Disk resource There are one or more local disks for each node. Each shared storage bus attaches one or more disks which hold data used either by server applications running on the cluster or by applications for managing the cluster. MSCS currently supports only SCSI shared storage buses. At a given time, each disk on the shared SCSI bus is owned by only one node of the cluster. The ownership of a disk moves from one node to another when the disk group failsover (or when you manually move it) to the other node. The shared disk always has the same drive name for a given cluster. For the examples in this document the disk resource name is N.
Virtual servers
MSCS groups that contain an IP Address resource and a Network Name resource (along with other resources) are published to clients on the network under a unique server name. Because these groups appear as individual servers to clients, they are called virtual servers. Users access applications or services on a virtual server in the same way they would access an application or service were it on a physical server. End users do not need any special training to use clustered resources and do not even need to know that the system is clustered.
MSCS: Management
This section briefly describes procedures you can use to view and manage cluster installations with the MSCS Cluster Administrator and includes the following sections: Opening the MSCS Cluster Administrator About MSCS group resources Viewing cluster resource properties Viewing and modifying MSCS resource groups Displaying active groups Manually moving a group from one node to another Verifying the status of individual nodes
Cluster management
52
MSCS: Opening the Cluster Administrator

To manage all MSCS objects, such as resources and groups, you use the MSCS Cluster Administrator. The Cluster Administrator gives you information about the groups and resources on all of your clusters and specific information about the clusters themselves. It provides you with tools for creating new groups and modifying existing groups. To open the Cluster Administrator: Select Programs > Administrative Tools > Cluster Administration from the Windows Start menu.
MSCS: Viewing cluster resource properties

You can use the MSCS Cluster Manager to view the properties of the resources that you can assign to groups in a given cluster installation. This is useful to determine if the group can support a Synchrony component installation. Similarly, after setting up your cluster, you may need to change the configuration of some resources and groups. To view or make changes to a selected group or resource: 1. Select the group or resource in the left pane. 2. Then from the Cluster Manager File menu, click Properties. MSCS opens the Group properties window.
MSCS: IP Address Resource

In the Properties window you can view or modify an IP address name and IP address for the cluster that will support your Synchrony component. In this example, the General tab shows the name of the group IP address as wtcluster00a and in the Parameters tab the IP address is 172.16.4.43.
MSCS: Network Name resource

In the Properties window you can view or modify a name for the resource and a Network Name for the cluster that represents your Synchrony component. In this example, in the General tab the group Network Name for the cluster is WTCLUSTER00a. The Possible Owners are WTCLUSTER01 and WTCLUSTER02. You can change the Network Name in the Parameters tab.
MSCS: Viewing and modifying Resource Groups

In the Cluster Administrator you can view and modify the resources that constitute the various groups of a cluster.
Example 1: Group before the Synchrony component installation

The following illustration shows an example of a MSCS Resource group that has the appropriate resources for a Synchrony component installation: IP Address resource: wtcluster00a Network Name resource: wtcluster00a Disk resource
Cluster management
53
Example 2: Group after a Sentinel and Synchrony Integrator Server installation
MSCS: Creating a Generic Service Application

Start in the Cluster Administration application and follow these steps: 1. Open a New Resource window: click File>New>Resource. 2. The Name and Description fields are available. As an example, type Synchrony component in the Name field and Synchrony component generic service in the Description field. 3. Leave the Resource type as Generic service and the Group as Group 1. 4. Click Next. 5. In the Possible owners window select the nodes where the application can run (normally the two nodes of the configuration). 6. Click Next.
Cluster management
54
7. In the Dependencies window select the resources. Generally, resources are the disk, the IP address and the Network Name (resources must be online before the application). 8. Click Next. 9. In the Generic service parameters window type the name of the service created during the installation of the Component. 10. Select Use network name for computer name. This changes the hostname retrieved by the application with the Network Name of the group. 11. Click Next. 12. In the Registry replication window, do not add anything (leave it blank). 13. Click Finish to save the changes.
MSCS: Creating a Generic Application Resource

Start in the Cluster Administration application and follow these steps: 1. Open a New Resource window: click File>New>Resource. 2. The Name and Description fields are available. As an example, type Synchrony component in the Name field and Synchrony component generic service in the Description field. 3. Leave the Resource type as Generic application and the Group as Group 1. 4. Click Next. 5. In the Possible owners window select the nodes where the application can run (normally the two nodes of the configuration). 6. Click Next. 7. In the Dependencies window select the resources. Generally, resources are the disk, the IP address and the Network Name (resources must be online before the application). 8. Click Next. 9. In the Generic application parameters window in the Command line field type the full path name to the script. 10. In the Current directory field type the full path to the directory that contains the script. 11. Select Use network name for computer name. This changes the hostname retrieved by the application with the Network Name of the group. 12. Click Next. 13. In the Registry replication window, do not add anything (leave it blank). 14. Click Finish to save the changes.
MSCS: Displaying active groups

To display the active groups on a given node: 1. In the left pane of the Cluster Administrator window, select the cluster node for which you want to display the active groups. 2. Select the Active Groups node. 3. The right pane displays all groups running on the selected cluster.
Cluster management
55
MSCS: Manually moving a group from one node to another

During the installation procedure for Synchrony components in cluster configurations, you need to manually move the installation target group from one cluster node to the other. To move the group to another node: 1. In the left pane of the Cluster Administrator window, select the group you want to move. 2. Drag-and-drop the selected group to another cluster node (for example from WTCLUSTER01 to WTCLUSTER02). 3. A warning pops up and asks you if you are sure you want to move, click Yes. 4. To view the results, select the Groups node in the root cluster node (WTCLUSTER00). The right pane displays the groups and the nodes on which they are running. You should refer to that Group 2 was successfully moved and is now running on WTCLUSTER02.
MSCS: Verifying the status of individual nodes

To verify the status of an individual node, select the Active groups folder of any node in the left pane. The right pane displays the groups running on the selected node (WTCLUSTER01).
Cluster management
56

Synchrony 4 3 Cluster Configuration Guide All-OS ENU

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Synchrony 4 3 Cluster Configuration Guide All-OS ENU

Uploaded by

Copyright:

Available Formats

CLUSTER CONFIGURATION GUIDE

PURPOSE OF THIS MANUAL

WHO SHOULD READ THIS MANUAL

Cluster Configuration Guide

Cluster architecture Standard cluster architecture

Testing a Synchrony Component on the first node

Cluster Configuration Guide

Various component installations

Cluster management Cluster administration guidelines

Linux Cluster Suite

Veritas Cluster Server for Linux

Cluster Configuration Guide

Standard cluster architecture

Cluster Configuration Guide

Cluster architecture uster

Active application server

Passive application server

Figure 2: The first server is active

Previous Active application server This server is now inactive

New Active application server

Figure 3: The second server is active

Cluster Configuration Guide

Cluster architecture uster

Software architecture and behavior

Resources and groups

Cluster Configuration Guide

Advanced cluster architecture

Cluster Configuration Guide

Two groups running on different

Figure 5: Two groups running on the same node

Cluster Configuration Guide

Cluster Configuration Guide

Red Hat Cluster Suite

Veritas Storage Foundation

Cluster Configuration Guide

Cluster Configuration Guide

Component Integrator Messaging Process Manager Sentinel Transfer CFT InterPlay

Windows license keys

Cluster Configuration Guide

Cluster installation checklist

Cluster Configuration Guide

Installing the first node

Installation on the first node

Local Disk Shared disk

Figure 6: Synopsis of the installation on the first node

Cluster Configuration Guide

Cluster installation tion

Managing Synchrony scripts on UNIX

Cluster Configuration Guide

Testing a Synchrony Component on the first node

Cluster Configuration Guide

Installing additional nodes

Cluster Configuration Guide

Installation on the first node

Local Disk Shared disk

Figure 7: second node

Synopsis of the installation on the

Installing scripts on the second node

Testing a Synchrony Component on the second node

Cluster Configuration Guide

Cluster installation tion

Various component installations

Installing multiple components sequentially