Sun Cluster Data Service for SWIFTAlliance Access Guide for Solaris OS

Previous: Preface

Installing and Configuring Sun Cluster HA for Alliance Access

This Chapter explains how to install and configure Sun Cluster HA for Alliance Access.

Note –

In the current version, SWIFTAlliance Access is renamed as Alliance Access. You can use the Sun Cluster HA for Alliance Access with both the product names.

This Chapter contains the following sections.

Overview of Installing and Configuring Sun Cluster HA for Alliance Access

Table 1 Lists the tasks for installing and configuring Sun Cluster HA for Alliance Access. Perform these tasks in the order that they are listed.

Table 1 Task Map: Installing and Configuring Sun Cluster HA for Alliance Access


Task	For Instructions, Go To
1. Plan the installation.	Planning the Sun Cluster HA for Alliance Access Installation and Configuration
2. Install Sun Cluster HA for Alliance Access Packages.	How to Install and Configure Alliance Access
3. Verify installation and configuration.	Verifying the Installation and Configuration of Alliance Access
4. Register and Configure Sun Cluster HA for Alliance Access.	Registering and Configuring Sun Cluster HA for Alliance Access
5. Verify Sun Cluster HA for Alliance Access Installation and Configuration.	Verifying the Sun Cluster HA for Alliance Access Installation and Configuration
6. Understand Sun Cluster HA for Alliance Access fault monitor.	Understanding the Sun Cluster HA for Alliance Access Fault Monitor
7. Debug Sun Cluster HA for Alliance Access.	Debugging Sun Cluster HA for Alliance Access

Sun Cluster HA for Alliance Access Overview

The HA agent is written to work with Alliance Access versions 5.5, 5.9, 6.0, 6.2 and 6.3. IBM DCE version 3.2 is not used anymore by Alliance Access 5.9 and later, and must only be installed for Alliance Access 5.5. Alliance Access^TMis a trademark of SWIFT.

The Sun Cluster HA for Alliance Access data service provides a mechanism for orderly startup, shutdown, fault monitoring, and automatic failover of the Sun Cluster service. The Sun Cluster components protected by the Sun Cluster HA for Alliance Access data service are the following.

Table 2 Protection of Components


Component	Protected by
DCE daemon	Sun Cluster HA for Alliance Access (version 5.5 only)
Alliance Access	Sun Cluster HA for Alliance Access

Note –

By default the HA agent provides a fault monitor for the DCE component only when using the Alliance Access 5.5. The fault monitoring for Alliance Access is switched off by default. If the Alliance Access application fails, the agent will not restart the Alliance Access application automatically. This behavior was explicitly requested by SWIFT. It will enable you to operate the application in a way that the probe does not interfere with the normal behavior of some Alliance Access features like:

operator manually triggering the Alliance Access restart function , for example, to run Alliance Access in housekeeping mode.
automatic or scheduled Alliance Access restart, for example, to run database backup and other maintenance or end-of-day processes.
any graceful Alliance Access restart or recovery, in case of a Alliance Access transient local error.

The HA agent provides the start, stop, takeover, and switchover functionality. This means that when a node fails, the other node will automatically start the Alliance Access application. The HA agent also provides an option to turn on fault monitoring for Alliance Access at registration time. However, this option is not recommended by SWIFT.

Planning the Sun Cluster HA for Alliance Access Installation and Configuration

This section contains the information you need to plan your Sun Cluster HA for Alliance Access installation and configuration.

Configuration Restrictions

This section provides a list of software and hardware configuration restrictions that apply to Sun Cluster HA for Alliance Access only.

Caution –

Your data service configuration might not be supported if you do not observe these restrictions.

You can configure the Sun Cluster HA for Alliance Access only as a HA agent and not as a scalable agent.
You can install the Alliance Access software on a global file system. Best practice is to use a failover file system. For Alliance Access 5.5, you must install the IBM DCE software on local storage.
Only one Alliance Access instance is supported by this agent.

For restrictions that apply to all data services, see the Sun Cluster Release Notes.

Configuration Requirements

These requirements apply to Sun Cluster HA for Alliance Access only. You must meet these requirements before you proceed with your Sun Cluster HA for Alliance Access installation and configuration. Follow the Alliance Access installation guide for the installation of the mandatory patch levels and the installation of the software.

Caution –

Your data service configuration might not be supported if you do not adhere to these requirements.

Sun Cluster components and their dependencies

Configure the Sun Cluster HA for Alliance Access data service to protect a Sun Cluster instance and its respective components. These components, and their dependencies, are briefly described next.

Component	Description
DCE daemon	-> SUNW.LogicalHost resource
Alliance Access	-> SUNW.LogicalHostresource -> SUNW.HAStoragePlus resource The SUNW.HAStoragePlus resource manages the Alliance Access System Mount points and ensures that Sun Cluster is not started until these are mounted. -> DCE daemon (version 5.5 only)

Component

Description

DCE daemon

-> SUNW.LogicalHost resource

Alliance Access

-> SUNW.LogicalHostresource

-> SUNW.HAStoragePlus resource

The SUNW.HAStoragePlus resource manages the Alliance Access System Mount points and ensures that Sun Cluster is not started until these are mounted.

-> DCE daemon (version 5.5 only)

The Sun Cluster component has two configuration and registration files in the /opt/SUNWscsaa/util directory. These files enable you to register the Sun Cluster component with Sun Cluster.

Within these files, the appropriate dependencies have already been defined. You must update the saa_config file before you run the saa_register script.

Installing and Configuring Alliance Access

This section describes the procedure to install and configure Alliance Access.

References will be made to some user-accessible directories for Alliance Access throughout the following sections.

Note –

Sun Cluster HA for Alliance Access can be configured to run in a whole root or a sparse root non-global zone for Alliance Access version 6.0, 6.2, and 6.3 if required.

How to Install and Configure Alliance Access

Use this procedure to install and configure Alliance Access.

Note –

IBM DCE client software is a prerequisite for Alliance Access version 5.5. The client software must be installed and configured before the Alliance Access application.

Create the resources for Alliance Access.
- Create a resource group for Alliance Access.
  # clresourcegroup create [-n node-zone-list] swift-rg
  -n node-zone-list
  
  Specifies a comma-separated, ordered list of zones that can master the resource group. The format of each entry in the list is node. In this format, node specifies the node name and zone specifies the name of a non-global Solaris zone. To specify the global zone, or to specify a node without non-global zones, specify only node. This list is optional. If you omit this list, the global zone of each cluster node can master the resource group.
- Create a logical host.
  
  Add the hostname and IP address in the /etc/inet/hosts file on all cluster nodes or zones that can master the resource group. Register the logical host and add it to the resource group.
  # clreslogicalhostname create -g swift-rg -l swift-lh swift-saa-lh-rs
- Create the device group and file system.
  
  See Sun Cluster Data Services Installation and Configuration Guide for instructions on how to create global file systems.
- Create an HAstoragePlus resource.
  
  It is recommended to create a HAStoragePlus failover resource to contain the Alliance Access application and configuration data instead of using the global file system.
  # clresource create -g swift-rg \ -t SUNW.HAStoragePlus \ -x FilesystemMountPoints=/global/saadg/alliance swift-ds
- Bring the resource group online.
  # clresouregroup online -M swift-rg
- Create the configuration directory.
  
  This directory contains Alliance Access information and creates a link from the /usr
  # cd /global/saadg/alliance
  # mkdir swa
  # ln -s /global/saadg/alliance/swa /usr/swa
  Note –
  For Solaris 10 only: If you install Alliance Access in a sparse root zone, that is if the /usr directory is inherited in read-only mode through a loopback mount, the link needs to be created within the global zone.

Install IBM DCE client software on all cluster nodes or zones that can master the resource group.

Caution –
This step is valid only for Alliance Access versions prior to 5.9 and should only be installed when needed.

Skip this step if you are using Alliance Access version 5.9 or later.
- Install IBM DCE client software on all cluster nodes or zones that can master the resource group. Use local disks to install this application. The software is shipped in Sun package format (IDCEclnt). Because the installed files will reside at various locations on your system, it is not practical to have this installed on global file systems. Install this application on both cluster nodes.
  # pkgadd -d ./IDCEclnt.pkg
- Configure DCE client RPC.
  # /opt/dcelocal/tcl/config.dce —cell_name swift —dce_hostname swift-lh RPC
- Test DCE.
  
  Run the tests on all cluster nodes or zones that can master the resource group.
  # /opt/dcelocal/tcl/start.dce
  Verify that the dced daemon is running.
  # /opt/dcelocal/tcl/stop.dce

Install Alliance Access software.

Perform the following steps on all cluster nodes or zones that can master the resource group. The steps vary between different versions of Alliance Access. You must perform the steps corresponding to the version of Alliance Access you are using.
- For Alliance Access 6.0 and earlier only: Create the users all_adm, all_usr and the group alliance on all cluster nodes or zones that can master the resource group with the same user ID and group ID.
  # groupadd -g groupid alliance
  # useradd -m -g alliance -d /export/home/all_adm -s /usr/bin/ksh all_adm
  # useradd -m -g alliance -d /export/home/all_usr -s /usr/bin/ksh all_usr
  On Solaris 10: Create a project called swift and assign the users all_adm and all_usr to it.
  # projadd -U all_adm,all_usr swift
- For Alliance Access 6.2 and 6.3: Create the user all_adm and the groups alliance and sagnlg on all cluster nodes or zones that can master the resource group with the same user ID and group ID. Also, create a project called swift and assign the users all_adm to it.
  # groupadd -g groupid alliance
  # groupadd -g groupid sagsnlg
  # useradd -m -g alliance -G sagsnlg -d /export/home/all_adm -s \ /usr/bin/ksh all_adm
  # projadd -U all_adm swift
- On Solaris 10: Set the values of the resource controls for the project swift.
  
  For Alliance Access 6.0 and earlier versions only:
  # projmod -s -K "project.max-sem-ids=(privileged,128,deny)" swift
  # projmod -s -K "process.max-sem-nsems=(privileged,512,deny)" swift
  # projmod -s -K "process.max-sem-ops=(privileged,512,deny)" swift
  # projmod -s -K "project.max-shm-memory=(privileged,4294967295,deny)" swift
  # projmod -s -K "project.max-shm-ids=(privileged,128,deny)" swift
  # projmod -s -K "process.max-msg-qbytes=(privileged,4194304,deny)" swift
  # projmod -s -K "project.max-msg-ids=(privileged,500,deny)" swift
  # projmod -s -K "process.max-sem-messages=(privileged,8192,deny)" swift
  For Alliance Access 6.2 and 6.3 only:
  # projmod -s -K "project.max-sem-ids=(privileged,1320,deny)" swift
  # projmod -s -K "project.max-shm-ids=(privileged,1500,deny)" swift
  # projmod -s -K "project.max-shm-memory=(privileged,4294967295,deny)" swift
  # projmod -s -K "project.max-msg-ids=(privileged,800,deny)" swift
  # projmod -s -K "process.max-sem-nsems=(privileged,512,deny)" swift
  # projmod -s -K "process.max-sem-ops=(privileged,512,deny)" swift
  # projmod -s -K "process.max-msg-qbytess=(privileged,10485760,deny)" swift
  # projmod -s -K "process.max-msg-messages=(privileged,8192,deny)" swift
  # projmod -s -K "process.max-stack-size=(basic,33554432,deny)" swift
  # projmod -s -K "process.max-data-size=(basic,8.0EB,deny)" swift
  # projmod -s -K "process.max-file-descriptor=(basic,1000,deny)" swift
  The previous values are examples. For more accurate values, refer to the latest SWIFT documentation release notes of the corresponding version.
- On Solaris 10:
  
  For Alliance Access 6.0 and earlier versions only:
  
  Assign the project swift as the default project for all_adm and all_usr by editing the file /etc/user_attr and typing the following two lines at the end of the file.
  all_adm::::project=swift
  all_usr::::project=swift
  For Alliance Access 6.2 and 6.3 only:
  
  Assign the project swift as the default project for all_adm by editing the file /etc/user_attr and typing the following line at the end of the file.
  all_adm::::project=swift
- For versions prior to Solaris 10, refer to the latest SWIFT documentation and release notes to determine the necessary setup for /etc/system.
  
  Use the shared storage configured in Step 1 for the installation of this application. The installation procedure will modify system files and might reboot the system. After rebooting, you must continue with the installation on the same node or zone. Ensure that the resource group is online on this node or zone.
  
  For Alliance Access 6.0 and earlier versions only:
  
  Repeat the installation of the software on the other node or zone that can master the resource group, but you must end the installation before the Alliance Access software licensing step.

For Alliance Access 6.0 and earlier versions only: Continue configuring Alliance Access application.

To enable clients to connect to the failover IP address, create a file named .alliance_ip_name (interfaces.rpc in versions 5.9 and 6.0) on the data subdirectory of the Alliance Access software.

If you are using the same file system as shown in the examples, this directory will be /global/saadg/alliance/data. This file must contain the IP address of the logical host as configured within the Alliance Access resource group.
# cd /global/saadg/alliance/data
# chown all_adm:alliance interfaces.rpc
If Alliance Messenger is licensed, create a file called interfaces.mas and add the cluster logical IP address used to communicate with SAM.
# cd /global/saadg/alliance/data
# chown all_adm:alliance interfaces.mas

Add a symbolic link and entries.
- Add the symbolic link /usr/swa on all cluster nodes or zones that can master the resource group, see Step 1 last bullet.
- Entries in /etc/services have to be added on all cluster nodes or zones that can master the resource group. This can be done as root by running the /usr/swa/apply_alliance_ports script.
- For Alliance Access 6.0 and earlier versions only:
  
  The rc.alliance and rc.swa_boot scripts (swa_rpcd in Alliance Access versions prior to 5.9) in /etc/init.d must remain in place. Any references to these files in /etc/rc?.d need to be removed and the access rights must be as follows:
  # cd /etc/init.d
  # chmod 750 rc.alliance rc.swa_boot
  # chown root:sys rc.alliance rc.swa_boot
  If the Alliance Access Installer displays “Start this SWIFTAlliance at Boottime”, choose No.
  
  You must copy the rc.alliance and rc.swa_boot scripts to all other cluster nodes or zones that can master the resource group:
  # scp rc.alliance rc.swa_boot node2:/etc/init.d
Note –
You must not configure to automatically start at boot time through the saa_configbootstrap command for Alliance Access 6.2 and 6.3.

Install Alliance Access Remote API (RA).
- Install RA after Alliance Access on shared storage using the following options:
  
  Instance RA1 (default), user all_adm
- Alliance Access 6.0 and earlier versions only:
  
  Copy the files in the home directory of the all_adm and all_usr user to all cluster nodes or zones that can master the resource group.
- Alliance Access 6.2 and 6.3 only:
  
  Copy the files in the home directory of the all_adm user to all cluster nodes or zones that can master the resource group. Copy the root/InstallShield directory to all cluster nodes or zones that can master the resource group.

Verifying the Installation and Configuration of Alliance Access

This section contains the procedure you need to verify the installation and configuration.

How to Verify the Installation and Configuration of Alliance Access

This procedure does not verify that your application is highly available because you have not yet installed your data service.

Start the Alliance Access application.

For Alliance Access versions other than Alliance Access version 5.5, type:
# su - all_adm
For Alliance Access version 5.5, choose Alliance —> Start SWIFTAlliance Servers.

Note –
If DCE does not start, choose GUI: OS Configuration —> DCE RPC.

Test the application.
1. Start the Alliance Access application.
2. Choose Alliance —> Start User Interface.

Stop the Alliance Access application.
1. Start the GUI.
  # su - all_adm
2. Choose Alliance —> Stop SWIFTAlliance Servers.

Installing the Sun Cluster HA for Alliance Access Packages

If you did not install the Sun Cluster HA for Alliance Access packages during your initial Sun Cluster installation, perform this procedure to install the packages. To install the packages, use the Sun Java^TM Enterprise System Installation Wizard.

Note –

You need to install the Sun Cluster HA for Alliance Access packages in the global cluster and not in the zone cluster.

How to Install the Sun Cluster HA for Alliance Access Packages

Perform this procedure on each cluster node where you are installing the Sun Cluster HA for Alliance Access packages.

You can run the Sun Java Enterprise System Installation Wizard with a command-line interface (CLI) or with a graphical user interface (GUI). The content and sequence of instructions in the CLI and the GUI are similar.

Note –

Even if you plan to configure this data service to run in non-global zones, install the packages for this data service in the global zone. The packages are propagated to any existing non-global zones and to any non-global zones that are created after you install the packages.

Before You Begin

Ensure that you have the Sun Java Availability Suite DVD-ROM.

If you intend to run the Sun Java Enterprise System Installation Wizard with a GUI, ensure that your DISPLAY environment variable is set.

On the cluster node where you are installing the data service packages, become superuser.

Load the Sun Java Availability Suite DVD-ROM into the DVD-ROM drive.

If the Volume Management daemon vold(1M) is running and configured to manage DVD-ROM devices, the daemon automatically mounts the DVD-ROM on the /cdrom directory.

Change to the Sun Java Enterprise System Installation Wizard directory of the DVD-ROM.
- If you are installing the data service packages on the SPARC® platform, type the following command:
  # cd /cdrom/cdrom0/Solaris_sparc
- If you are installing the data service packages on the x86 platform, type the following command:
  # cd /cdrom/cdrom0/Solaris_x86

Start the Sun Java Enterprise System Installation Wizard.
# ./installer

When you are prompted, accept the license agreement.

If any Sun Java Enterprise System components are installed, you are prompted to select whether to upgrade the components or install new software.

From the list of Sun Cluster agents under Availability Services, select the data service for Alliance Access.

If you require support for languages other than English, select the option to install multilingual packages.

English language support is always installed.

When prompted whether to configure the data service now or later, choose Configure Later.

Choose Configure Later to perform the configuration after the installation.

Follow the instructions on the screen to install the data service packages on the node.

The Sun Java Enterprise System Installation Wizard displays the status of the installation. When the installation is complete, the wizard displays an installation summary and the installation logs.

(GUI only) If you do not want to register the product and receive product updates, deselect the Product Registration option.

The Product Registration option is not available with the CLI. If you are running the Sun Java Enterprise System Installation Wizard with the CLI, omit this step.

Exit the Sun Java Enterprise System Installation Wizard.

Unload the Sun Java Availability Suite DVD-ROM from the DVD-ROM drive.
1. To ensure that the DVD-ROM is not being used, change to a directory that does not reside on the DVD-ROM.
2. Eject the DVD-ROM.
  # eject cdrom

Next Steps

Go to Registering and Configuring Sun Cluster HA for Alliance Access

Registering and Configuring Sun Cluster HA for Alliance Access

This section contains the procedures you need to configure Sun Cluster HA for Alliance Access.

How to Register and Configure Sun Cluster HA for Alliance Access as a Failover Service

This procedure assumes that you installed the data service packages during your initial Sun Cluster installation.

Steps 1 to 6 will normally already be done in order to prepare for the installation of the IBM DCE and Alliance Access software. See How to Install and Configure Alliance Access. Typically, you should go directly to step 7.

Become superuser on one of the nodes in the cluster that will host Sun Cluster.

# clresourcetype register SUNW.HAStoragePlus

Create a failover resource group.
# clresourcegroup create [-n node-zone-list] swift-rg
-n node-zone-list

Specifies a comma-separated, ordered list of zones that can master the resource group. The format of each entry in the list is node. In this format, node specifies the node name and zone specifies the name of a non-global Solaris zone. To specify the global zone, or to specify a node without non-global zones, specify only node. This list is optional. If you omit this list, the global zone of each cluster node can master the resource group.

Create a resource for the Sun Cluster Disk Storage.

# clresource create -g swift-rg  \
-t SUNW.HAStoragePlus  \
-x FilesystemMountPoints=/global/saadg/alliance swift-ds

Create a resource for the Sun Cluster Logical Hostname.

# clreslogicalhostname create  -g swift-rg\
  -h swift-lh swift-lh-rs

Enable the failover resource group that now includes the Sun Cluster Disk Storage and Logical Hostname resources.
# clresourcegroup online -M swift-rg

Create a resource for Alliance Access.
1. Before running this script, check that the names of the resources match what is configured in /opt/SUNWscsaa/util/saa_config.
  # /opt/SUNWscsaa/util/saa_register
2. Run the registration script provided as part of the Alliance Access HA agent.

Start the Alliance Access instance manually.

su - all_adm
The GUI will open up. From within the GUI, select the menu
Alliance - Start Alliance Servers

Stop the Alliance Access manually.

su - all_adm
 The GUI will come up. Stop the application from within the GUI.

Enable each Sun Cluster resource.

# clresource status -g swift-rg
# clresource enable swift-saa-rs

Verifying the Sun Cluster HA for Alliance Access Installation and Configuration

This section describes the procedure to verify that you have installed and configured your data service correctly.

How to Verify the Sun Cluster HA for Alliance Access Installation and Configuration

Become superuser on one of the nodes in the cluster that will host Sun Cluster.

Ensure all the Sun Cluster resources are online with cluster status.
# cluster status
For each Sun Cluster resource that is not online, use the clresource command as follows.
# clresource enable resource-name

Run the clresourcegroup command to switch the Sun Cluster resource group to another cluster node, such as node2.
# clresourcegroup switch swift-rg -h node2

Check that Alliance Access is stopped on the first node and that the application is restarted on the second node.

When using a failover file system, this should disappear on the first node and will be mounted on the second node.

Understanding the Sun Cluster HA for Alliance Access Fault Monitor

This section describes the Sun Cluster HA for Alliance Access fault monitor's probing algorithm or functionality, and states the conditions, messages, and recovery actions associated with unsuccessful probing.

For conceptual information on fault monitors, see the Sun Cluster Concepts Guide.

Resource Properties

The Sun Cluster HA for Alliance Access fault monitor uses the same resource properties as resource type SUNW.gds, refer to the SUNW.gds(5) man page for a complete list of resource properties used.

Probing Algorithm and Functionality

By default, the HA agent provides a fault monitor for the DCE component only when using Alliance Access 5.5. The fault monitoring for Alliance Access is switched off by default. If the Alliance Access application fails, the agent will not restart the Alliance Access application automatically. This behavior was explicitly requested by SWIFT. It will enable you to operate the application in a way that the probe does not interfere with the normal behavior of some Alliance Access features like:

operator manually triggering the Alliance Access restart function , for example, to run Alliance Access in housekeeping mode.
automatic or scheduled Alliance Access restart, for example, to run database backup and other maintenance or end-of-day processes.
any graceful Alliance Access restart or recovery, in case of a Alliance Access transient local error.

The HA agent will update the resource status message to output Degraded - SAA Instance offline.

If an automatic failover occurs with default setting, it is most likely that there was a DCE problem. The Alliance Access application will cause a failover only when it does not start on the current node.

The HA agent provides an option to turn on fault monitoring for Alliance Access at registration time. However, this option is not recommended by SWIFT. The optional probing checks for the existence of the Alliance Access instance by calling the alliance command that is part of the application and by evaluating its return code. If the Alliance Access instance is not running, return code 100 is sent to SUNW.gds, which in turn will perform an automatic restart depending on the configuration of the resource properties.

Debugging Sun Cluster HA for Alliance Access

How to turn on debugging for Sun Cluster HA for Alliance Access

Each Sun Cluster component has a DEBUG file in /opt/SUNWscsaa/etc directory, where saa is a three-character abbreviation for the respective Sun Cluster component.

These files enable you to turn on debugging for all Sun Cluster instances or for a specific Sun Cluster instance on a particular node with Sun Cluster. If you require debugging to be turned on for Sun Cluster HA for Alliance Access across the entire Sun Cluster installation, repeat this step on all nodes or zones that can master the resource group.

Edit the /etc/syslog.conf file.

Change daemon.notice to daemon.debug.

# grep daemon /etc/syslog.conf
*.err;kern.debug;daemon.notice;mail.crit        /var/adm/messages
*.alert;kern.err;daemon.err                     operator
#

Change the daemon.notice to daemon.debug and restart syslogd. The following output, from the command grep daemon /etc/syslog.conf, shows that daemon.debug has been set.

# grep daemon /etc/syslog.conf
*.err;kern.debug;daemon.debug;mail.crit        /var/adm/messages
*.alert;kern.err;daemon.err                    operator
#
# pkill -1 syslogd
#

Edit the /opt/SUNWscsaa/etc/config file.

Change DEBUG= to DEBUG=ALL or DEBUG=resource

# cat /opt/SUNWscsaa/etc/config
#
# Copyright 2003 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# Usage:
#       DEBUG=<RESOURCE_NAME> or ALL
#
DEBUG=ALL
#

Note –

To turn off debugging, reverse the previous steps.

Previous: Preface