Synchrony 4 3 Cluster Configuration Guide All-OS ENU

11 May 2010

CLUSTER CONFIGURATION GUIDE

Synchrony Platform Version 4.3

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

Preface

P U R P O S E O F T H I S M A N U A L

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

W H O S H O U L D R E A D T H I S M A N U A L

This document is intended for users that have to install a Synchrony component or solution in a cluster architecture.

A S S U M E D K N O W L E D G E

In this guide, we assume that the reader has a working knowledge of UNIX and Windows.

R E L A T E D D O C U M E N T A T I O N

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 3

https://support.axway.com/


Contents

Contents

1 Cluster architecture 6

Standard cluster architecture 6 Global architecture and behavior 6 Software architecture and behavior 8

Advanced cluster architecture 9

2 Installation prerequisites 11

HACMP 11

Sun Cluster 11

HP Serviceguard 11

Red Hat Cluster Suite 12

Veritas Storage Foundation 12

MSCS 12

UNIX users 13

License keys 13 UNIX license keys 13 Windows license keys 14

3 Cluster installation 15

Cluster installation checklist 15

Installing the first node 16

Managing Synchrony scripts on UNIX 17 Script descriptions 17 Script installation 17

Testing a Synchrony Component on the first node 18 Testing on UNIX 18 Testing on Windows 19

Installing additional nodes 19

Installing scripts on the second node 20

Testing a Synchrony Component on the second node 20

4 Cluster configuration 21


Contents

Various component installations 21 Installing two Synchrony components in two different groups 21 Installing multiple components sequentially 21

Applying patches 22 Automator 22 Composer 22 Gateway 22 Integrator 23 InterPlay 23 Messaging 23 ProcessManager 23 Sentinel 24 Transfer CFT 24

5 Cluster management 25

Cluster administration guidelines 25 Administrative user 25 Differences between a production and test site 25

HACMP 25 HACMP Concepts 25 HACMP management basics 27

Sun Cluster 32 Sun Cluster concepts 32 Sun Cluster management basics 33

HP Serviceguard 36 HP Serviceguard concepts 36 HP Serviceguard management basics 37

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

Veritas Cluster Server for Linux 46 Related software 46 Veritas Storage Foundation Concepts 46 GUI procedure 47

MSCS 51 MSCS Concepts 51 MSCS: Management 52


6


1 Cluster architecture

uster architecture

1 Cluster architecture

I N T H I S C H A P T E R I N T H I S C H A P T E R

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.

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.

Network

Server +

Disk

Client

First case First case


Active application server

7

Active application server

In Figure 1, the server on the left is active and the client applications are connected using the IP address "ClusterIP". In Figure 1, the server on the left is active and the client applications are connected using the IP address "ClusterIP".

Figure 2: The first server is active Figure 2: The first server is active

Second case 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"). 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").

Cluster architectureuster architecture

Figure 3: The second server is active Figure 3: The second server is active

Local Disk

http://ClusterIP

Network Client

Passive application server

Local Disk

Shared Disk

New Active application server

Local Disk

Shared Disk

Network Client

http://ClusterIP

Local Disk

Previous Active application server This server is now

inactive



Software architecture and behavior

Different types of clusters The following types of cluster software are covered in this document:

Operating System Cluster name

AIX HACMP™ (High Availability Cluster Multi-Processing)

Solaris Sun Cluster™

HP/UX HP Serviceguard™

Windows MSCS™ (Microsoft Cluster Service)

Linux RedHat Cluster Suite™

Other UNIX 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 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:

o A planned action o 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.

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: Two groups running on different nodes

Figure 5: Two groups running on the same node




Installation prerequisites

2 Installation prerequisites

I N T H I S C H A P T E R

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 IBM’s 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 Sun’s documentation.

HP Serviceguard You can install a Synchrony Component into a pre-existing HP Serviceguard 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 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.


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.


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.



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 Number of license keys or specific behavior

Automator Only one key for the cluster

Composer One key per node

Gateway One key per node



Component Number of license keys or specific behavior

Integrator One key per node

Messaging One key per node

Process Manager One key per node

Sentinel Only one key for the cluster

Transfer CFT One key per node

InterPlay 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


Cluster installation

3 Cluster installation


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:

o Hostname of each node and the license keys (refer to section License keys) o 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).

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).

Installing the first node Installing the first node

Note: The installation on the first node must be performed in the advanced installation mode of the Synchrony Installer.

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 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: 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)

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)

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 If it is necessary, use the multi-key option


16

Cluster installationtion

Figure 6: Synopsis of the installation on the first node

Figure 6: Synopsis of the installation on the first node

Node 2 Node 1

Shared disk

Local Disk

Local Disk


Database

From the Synchrony Installer follow these steps to install the first node: From the Synchrony Installer follow these steps to install the first node:

1. In the Installation mode screen select Advanced. 1. In the Installation mode screen select Advanced.

2. In the Architecture type screen select Cluster. 2. In the Architecture type screen select Cluster.

3. In the Cluster installation screen select First node. 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.




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>:

o Start o Stop o Startandwait o Status o Restart o Suspend

<component>:

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.



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 Value

LOCUSR The UNIX user used to install the component

DIR 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).



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.

Node 2 Node 1

Shared disk

Local Disk


Local Disk

Figure 7: Synopsis of the installation on the second node

Figure 7: Synopsis of the installation on the second node

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. 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: The installation is launched on the second or an additional node using the following options:

1. In the Installation mode screen select Advanced. 1. In the Installation mode screen select Advanced.

2. In the Architecture type screen select Cluster. 2. In the Architecture type screen select Cluster.

3. In the Cluster installation screen select Additional node. 3. In the Cluster installation screen select Additional node.



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.

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 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. 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 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.

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.


20

Cluster installationtion


Cluster configuration

4 Cluster configuration


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: /usr/Axway/local/disk1

The shared directory is: /disk1/Axway/shared

Integrator is installed in the local directory: /usr/Axway/local/disk2

The shared directory is: /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.



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:

o 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.

4. Restart Automator:

o In HACMP & HP Serviceguard use the restart script. o In Sun Cluster use the enable command. o In MSCS use the start command.

Composer To apply a patch to Composer:


2. Stop Composer:


3. Apply the patch.

4. Restart Composer:


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).



3. Switch nodes (failover).

4. Apply the patch to node A, which is now passive.

Integrator To apply a patch to Integrator:





InterPlay To apply a patch to InterPlay, you must follow these steps:





Messaging To apply a patch to Messaging:





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:





If the patch cannot be applied while the ProcessManager is in use:


2. Stop ProcessManager.


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.



4. Apply the patch to B, the passive node.

5. Restart ProcessManager.


Sentinel To apply a patch to Sentinel:


2. Stop Sentinel.


3. Apply the patch.

4. Restart Sentinel.


Transfer CFT To apply a patch to Transfer CFT, you must follow these steps:






Cluster management

5 Cluster management


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

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

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 F2=Refresh F3=Cancel F8=Image F9=Shell F10=Exit Enter=Do

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

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 Value

Server name The name of the component. For example: Integrator

Start script The name of the script that starts the Synchrony component (refer to section Managing Synchrony scripts on UNIX) X

Stop script 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] Server Name Integrator New Server Name [Integrator] Start Script [/hascripts/Integrator/start_Integrator_Cluster] Stop Script [/hascripts/Integrator/stop_Integrator_Cluster] F1=Help F2=Refresh F3=Cancel F4=List F5=Reset F6=Command F7=Edit F8=Image F9=Shell F10=Exit Enter=Do

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 sub-menus 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

Field Value

Monitor name Generally, the same name as the component to be monitored. For example Integrator.

Application Server(s) to monitor

The name of the component to be monitored. For example; Integrator.

Monitor mode Keep Long-running-monitoring

Monitoring method The name of the script to be used to monitor the Synchrony component (refer to Managing Synchrony scripts on UNIX).

Monitor interval Enter 30

Hung monitor signal Enter 9

Stabilization interval Enter 30

Restart count Enter 3

Restart interval Enter 198

Action on application failure

Enter failover

Notify method Leave blank

Cleanup method Leave blank

Restart method 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 F2=Refresh F3=Cancel F4=List F5=Reset F6=Command F7=Edit F8=Image F9=Shell F10=Exit Enter=Do

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

2. In the HACMP Resource Groups screen, select: 2. In the HACMP Resource Groups screen, select:

o Change/Show resources for a resource group (standard) o Change/Show resources for a resource group (standard) o Do not select: Change/Show a resource group o 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. 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 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] Resource Group Name Rg_Http Participating Nodes (Default Node Priority) jack joe Startup Policy Online On First Available Node Fallover Policy Fallover To Next Priority Node In The List Fallback Policy 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 F2=Refresh F3=Cancel F4=List F5=Reset F6=Command F7=Edit F8=Image F9=Shell F10=Exit Enter=Do

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 F2=Refresh F3=Cancel F6=Command

Prompt of the confirmation of the command

F8=Image F9=Shell F10=Exit /=Find n=Find Next

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


30

Cluster managementCluster management

The following screen should display: The following screen should display:

COMMAND STATUS COMMAND STATUS Command: OK stdout: yes stderr: no


31


Before command completion, additional instructions may appear below. [TOP] Verification to be performed on the following:

Prompt of the confirmation of the command

Cluster Topology Cluster Resources Retreiving data from available cluster nodes. This could take a few minutes.... Verifying Cluster Topology... ----------- follow-up to the verify command ------------------ [MORE...53] F1=Help F2=Refresh F3=Cancel F6=Command F8=Image F9=Shell F10=Exit /=Find n=Find Next

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 F2=Refresh F3=Cancel F8=Image F9=Shell F10=Exit Enter=Do

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.

3. When the target node is selected, the Manager starts the group and displays the following screen:

3. When the target node is selected, the Manager starts the group and displays the following screen:

COMMAND STATUS COMMAND STATUS Command: running stdout: yes stderr: no Before command completion, additional instructions may appear below. Attempting to bring group Rg_Http offline on node joe. Waiting for cluster to process the resource group movement request....

Wait until this indicator switches to OK

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


32



Cluster management

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.



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

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 Value

Resource Name The name of the Resource. For example : “Integrator”

Group_Name The name of Group where is Resource is embedded

Start Script The name of the script that starts the Synchrony Component (refer to section Managing Synchrony scripts on UNIX)

Stop Script The name of the script that stops the Synchrony Component (refer to section Managing Synchrony scripts on UNIX)

Port_To_Be_Checked 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 Value

Resource Name 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: default Enabled{node1}: True Enabled{node2}: True Monitored{node1}: True Monitored{node2}: True Resource: res-nfs-splus Type: SunW.HAStoragePlus:4 Type_version: 4 Group: RGnfs R_description: Resource_project_name: default Enabled{node1}: True Enabled{node2}: True Monitored{node1}: True Monitored{node2}: True Resource: res-nfs-hanfs

Type: SunW.nfs:3.2 Type_version: 3.2 Group: RGnfs R_description: Resource_project_name: default Enabled{node1}: True Enabled{node2}: True Monitored{node1}: True Monitored{node2}: True Resource: Synchrony_Integrator Type: SunW.gds:6 Type_version: 6


Cluster management

Group: RGnfs R_description: Resource_project_name: default Enabled{node1}: True Enabled{node2}: True Monitored{node1}: True

It is important to check these statuses

Monitored{node2}: True

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 Node Name State Status Message ------------- --------- ----- -------------- res-nfs-lname node1 Offline Offline - LogicalHostname offline. node2 Online Online - LogicalHostname online. res-nfs-splus node1 Offline Offline node2 Online Online res-nfs-hanfs node1 Offline Offline - Completed successfully. node2 Online Online - Service is online. Synchrony_Integrator node1 Offline Offline node2 Online Online - Service is online.

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: Synchrony_Integrator Type: SunW.gds:6 Type_version: 6 Group: RGnfs R_description: Resource_project_name: default Enabled{node1}: False Enabled{node2}: False Monitored{node1}: True Monitored{node2}: True

“Enabled” resource is False

Sun Cluster: Enable a resource 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:


36


Resource: Synchrony_Integrator Type: SunW.gds:6 Type_version: 6 Group: RGnfs R_description: Resource_project_name: default Enabled{node1}: True Enabled{node2}: Trus Monitored{node1}: True Monitored{node2}: 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

“Enabled” resource is True

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

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


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.


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

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]="<INSTALLATION-DIRECTORY>/Scripts/Component1/startandwait_Component1_cluster" SERVICE_RESTART[0]="-r 2" SERVICE_NAME[1]="Component2" SERVICE_CMD[1]="<INSTALLATION-DIRECTORY>/Scripts/Component2/startandwait_Component2_cluster" SERVICE_RESTART[1]="-r 2" SERVICE_NAME[2]="Component3" SERVICE_CMD[2]="<INSTALLATION-DIRECTORY>/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

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.


Clusters

Nodes

Resources

Services

Clusters A cluster is a configuration of multiple nodes.

http://en.wikipedia.org/wiki/High-availability_cluster

http://en.wikipedia.org/wiki/Load_balancing_(computing)


Cluster management

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


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.



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.

The following screen is displayed, follow the instructions:

Typically, the Synchrony component scripts are defined in the Resources property:


Cluster management

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


Cluster management

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

</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 Status ------ ---- ------ node10.example.com Online, Local, rgmanager node11.example.com Online, rgmanager Service Name Owner (Last) State ------- ---- ----- ------ ----- synchrony node10.example.com 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 Command to be used

Disable a service cluscvadm –d <service>

Enable a service on the local node cluscvadm –e <service>

Enable a service according to failover domain rules

cluscvadm –e <service> -F

Enable a service on a specific node cluscvadm –e <service> -m <node>

Relocate a service cluscvadm –r <service>

Relocate a service on a specific node cluscvadm –r <service> -m <node>


Cluster management

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="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 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

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.


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.


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.

Type of Resource Description

Application Contains the description of the application itself

IP Contains the definition of the shared IP address

LVLMLogicalValue LVMVolumeGroup Mount

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

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

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

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


Cluster management

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

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

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

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


Cluster management

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

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).

Synchrony 4 3 Cluster Configuration Guide All-OS ENU

Documents

f2refresh

f3cancel f7edit

f2refresh

f5reset f9shell

f4list f8image

f3cancel enter

veritas storage

registry replication