synfinitycluster installation/administration guide for ... · pdf filesynfinitycluster...

J2S1-1401-01EN

SynfinityCluster

Installation/Administration Guide

for Cluster System Add-on Packages V2.0

Preface

This document provides a functional overview of the agent products and application programs for the SynfinityCluster system.

The SynfinityCluster system uses a Cluster management view that allow the user to perform operations from installation to operation all from one terminal.

The cluster management view is operated from the WWW browser screen.

For information on the operation flow from installation to operation management of the SynfinityCluster system, refer to "SynfinityCluster Installation/Administration Guide."

Target Readers

This document is intended for all users who plan to install products related to the SynfinityCluster system and programmers who plan to install the SynfinityCluster system.

Configuration of This Document

This document consists of three parts and a glossary. The contents of each part are described below. Part 1 Products That Support SynfinityCluster

Target readers: System administrators who plan to build a SynfinityCluster system. Contents: Part 1 provides a functional overview of SynfinityCluster agent products that support the SynfinityCluster system.

Part 2 SynfinityCluster-Related Products Target readers: System administrators who plan to build a SynfinityCluster system. Contents: Part 2 provides a functional overview of products that are related to SynfinityCluster.

Part 3 Examples of SynfinityCluster Product Installation Target readers: System administrators who operate and administrate a SynfinityCluster system.

Contents: Part 3 describes specific examples of SynfinityCluster installation. This part introduces examples of SymfoWARE and SynfinityFile/Global.

Manual Series

Manual Printing

To print this manual, use the PDF file found in the CD-ROM for the SynfinityCluster product.

You will need Adobe Acrobat Reader to read and print the PDF file. Use Adobe Acrobat Reader Version 4.0 or higher.

Online Manuals

To allow users to view the online manuals, use the Cluster management server to register each user name to one of the user groups (wvroot, clroot, cladmin, or clmon).

For instructions on user group registrations and a description of each user group, refer to the "SynfinityCluster Installation/Administration Guide."

Notational Conventions

This document uses the following notational conventions: · Characters to be entered by the user are indicated in bold. · The title of a lookup destination is enclosed in " ". · Tool bar names, menu names, command names, and icon names are enclosed in brackets ([ ]).

i

· Instructions to select the [yy] command from the [xx] menu in the menu bar are indicated as "Select [xx]-[yy]." · Button names are enclosed in angle brackets (< >).

· Important point

· Cautionary note

· Example

· Remark

· Reference

· Summary of a chapter or subchapter · When referring to Solaris manuals, replace the "Solaris X" section in manual titles with "Solaris 2.6" if you are

using the Solaris 2.6 system, with "Solaris 7" if you are using the Solaris 7 system or with "Solaris 8" if you are using the Solaris 8 system

Availability of Bound Manual Printing Service

Fujitsu provides a bound manual printing service for users who prefer to use a hard copy of this document. If you require a paper-based bound manual, you can purchase one by specifying the following manual code:

Manual code: J2S1-1401

April 2001

Trademarks

Solaris, NFS, Sun Microsystems, JumpStart, AnswerBook, and AnswerBook2 are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Sun's logo mark and Solaris are registered trademarks of Sun Microsystems, Inc.

Netscape and Netscape Navigator are trademarks of Netscape Communications Corporation in the United States and other countries.

Microsoft, Windows, and Windows NT are registered trademarks of Microsoft Corporation in the United States and other countries.

Java and all Java-related products and logs are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

BEA is a trademark of BEA Systems, Inc.

TUXEDO is a registered trademark in the United States and other countries.

ORACLE and Oracle Applications are trademarks or registered trademarks of Oracle Corporation.

Sun Internet Mail Serve and Sun WebServer are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Sybase and the Sybase logo are registered trademarks of Sybase, Inc.

NetWorker is a registered trademark of Legato Systems, Inc.

Copyright (c) 1986-1997 Sun Microsystems,Inc.

Copyright (c) 1983-1989 Portions may be derived from Berkeley BSD system, licensed from the U. of CA.

(C)1990-2000 Legato Systems, Inc. All Rights Reserved.

Requests · If you come across any difficult-to-understand items or errors in this document, please report the items in the

manual comment sheet found at the end of the document and submit the sheet to a Fujitsu SE or sales person.

· No part of this document may be reproduced or copied without permission of FUJITSU LIMITED.

ii

· The contents of this document may be revised without prior notice. All Rights Reserved, Copyright (c) FUJITSU LIMITED 2001

iii

Part 1 Products Supporting the SynfinityClusterSystem

The products that support the SynfinityCluster system are shown below.

1

Chapter 1 Table of support format

A table of support format for each product is shown below.

A round mark indicates that a product is supported while a cross mark indicates a product that is not supported. ( ) indicates the supported version. If no version number is indicated, all the versions are supported.

For standby class

[Table of application products]

(*1) SynfinityLink

For details on the environment settings for which node name takeover is required, refer to SynfinityLink Guide V2.0.

3

[Table of cluster agent products]

For scalable class

4

Chapter 2 SynfinityCluster/HA for File Server

2.1 NFS

In the following description, readers are assumed to have a general knowledge of NFS.

See "Managing NFS in AnswerBook2.System Administrator Collection" for a general introduction to NFS.

When an NFS server fails, an NFS client cannot use the file system in which NFS is mounted and operation will be interrupted.

To prevent this from occurring, use an NFS server in standby operation. To have another node takeover the NFS services from the failed node enables an NFS client to use without interruption the file system in which NFS is mounted.

The SynfinityCluster system enables an NFS server to be used as a standby server.

To use an NFS server as a standby server, store the file systems to be shared by NFSs and NFS file system management information on a switched disk.

Conditions to use an NFS server as a standby server are as follows:

[NFS server in standby operation]

standby(1:1), NFS server in standby operation, standby(N:1), mutual standby(N) Applicable cluster

topology (Scalable operation topology is not supported.)

Required hardware Switched disks

File systems For a shared file system, use UFS or SynfinityFile.

Notes

If an application locks a file, certain cautions must be taken. First, in a node that uses NFS as a standby server, access the file systems shared by NFSs from the remote system only. In addition, confirm that NFSs are exclusive to servers. Next, an NFS client who mounts the file system is required to support the re-request function of file lock. Some NFS clients running on a PC do not support the re-request function of file lock.

For a general introduction on standby operation and details on applicable cluster topology, refer to the "SynfinityCluster Guide."

2.2 NIS

In the following description, readers are assumed to have a general knowledge of NIS.

For a general introduction on NIS, see "AnswerBook2.System Administrator Collection. Managing Solaris Naming. Managing NIS".

If an NIS server fails, jobs are affected as described below.

When a master server fails

The information managed by NIS cannot be added or changed.

If user IDs are managed by NIS, and a password expires and a master server fails simultaneously, the user password cannot be changed, thereby rendering it difficult for the user to log in.

To prevent this, use an NIS master server as a standby server.

5

If a slave server fails, the NIS client using the server can switch to another server without affecting subsequent jobs though there will be a time lag required for switching.

While the SynfinityCluster system is being switched, NIS cannot be referenced. Therefore it is recommended that multiple slave servers be available.

The SynfinityCluster system enables an NIS master server to be used as a standby server.

To use an NIS server as a standby server, store the NIS information on a switched disk and store the NIS database in the "/var/yp" directory of each node. When switching nodes, reconstruct the NIS database in the "/var/yp" directory from the NIS information on the switched disk.

Conditions for using an NIS master server as a standby server are as follows:

[NIS master server in standby operation]

standby (1:1), standby(N:1), mutual standby Note 1 Applicable cluster topology (Scalable operation topology is not supported.)

Required hardware Switched disks

Notes When a NIS master server is used as a standby server on a node, other NIS servers cannot be used.

Note 1

A SynfinityCluster system having a mutual standby configuration can be used as one of the multiple standby operations implementing a mutual standby operation.

For a general introduction on standby operation and details on applicable cluster topology, refer to the "SynfinityCluster Guide."

6

Chapter 3 SynfinityCluster/HA for Netcompo

3.1 Function Outline

Netcompo series software products provide communication services and a gateway function through a LAN/WAN connection with mainframes via protocols such as FNA/SNA in Solaris systems.

3.1.1 Application to a cluster system

In cluster operation using the Netcompo series, communication will be suspended temporarily if a system failure occurs due to the failure of an active node during communication. However, communication can be re-established by switching the lines and LAN to standby node and setting up the connection from the terminal again. Netcompo supports standby and mutual standby as the cluster types.

By unifying the Netcompo series communication functions into clusters, you can build a system that is highly reliable and always available.

3.1.2 Support format

See "Table of support format.".

3.2 Standby class

The following are the standby class: 1:1 standby, N:1 standby, and two-node mutual standby.

3.2.1 System Configurations

[Example of 1:1 standby configuration]

7

[Example of N:1 standby configuration]

[Example of two-node mutual standby configuration]

3.2.2 Design and Development

If an error occurs in the active node during cluster operation, connection with the host is lost and communication stops temporarily during Netcompo cluster operation. Thus, applications performing communication by using API with which Netcompo can restart communication by reconnecting the session with the host after switching.

3.2.3 Environment Setup

The cluster environment setup procedure for Netcompo can be roughly divided into the following steps:

Environment settings made in the same way as with a single system

All the Netcompo products are set up. The settings that are specified will depend on the products or notes that are available.

8

Environment settings depend on the cluster system

Environment settings that are particular to the cluster are made for the following products: · Netcompo WAN SUPPORT · Netcompo FNA-LAN · Netcompo FNA-BASE

Setting and registering resources of the state transition procedure

State transition procedures are available for switching the network resources for the following products. These state transition procedures must be registered with the cluster system and set for the cluster service for operation: · Netcompo WAN SUPPORT · Netcompo FNA-LAN · Netcompo FNA-BASE · Netcompo NMC Server For details, see "SynfinityCluster Installation/Administration Guide for Netcompo."

3.2.3.1 Prerequisites

Before you can perform Netcompo environment setup, you must set up the following takeover networks:

Line switching unit settings

To use Netcompo WAN SUPPORT, you must first set up the line switching unit.

MAC address settings

To use Netcompo FNA-LAN, you must set up MAC address takeover.

Logical IP settings

To use TCP/IP, set up logical IP takeover.

This setting must be made for the following: · When the FNAonTCP/IP procedure is to be used for Netcompo FNA-BASE · When TCP/IP is to be used for the client connection with the Netcompo NMC Server · When the Netcompo TN Gateway Service is to be used For instructions on how to set up each network, refer to the "SynfinityCluster Installation/Administration Guide."

Resource registration procedure

To register resources, use the setup command provided by SynfinityCluster/HA for Netcompo. For details, see "SynfinityCluster Installation/Administration Guide for Netcompo."

3.2.4 Operations

In cluster system operation, the registered state transition procedure is executed if the status of the resource used by the cluster service changes or if the operator requests state transition. The procedure handles the activation and deactivation of the network resources controlled by Netcompo.

3.2.5 Operation at start-up

On an active node, the network resources are activated and cluster services are started to enable operation. On a standby node, the network resources are deactivated in preparation for any errors (system failure) that may occur in active nodes. Cluster services are stopped and enter the standby state.

3.2.6 Termination Operation

On an active node, network resources are deactivated and cluster services are stopped. On a standby node, no operation is performed.

3.2.7 Switching Operation

The occurrence of an error (such as a system-down) in an active node triggers the activation of the network resources on the standby node or the start-up of a cluster service, such that a remote system can be connected again. These actions enable the standby node to take over a job that was being executed on the active node.

9

10

3.2.8 Operation for Node Extension

To expand a node, delete the resources defined with Netcompo, and then set all the resources including those to be defined additionally after node extension.

3.2.9 Performance

Switching by the Netcompo series takes several minutes. To estimate the switching time for the entire job, you must also consider issues such as the system startup time.

Chapter 4 SynfinityCluster/HA for NetWorker

4.1 Overview of Functions

4.1.1 Overview of Functions

Using automatic NetWorker server error detection and automatic node switching, SynfinityCluster/HA for NetWorker enhances the availability of the backup operation system with NetWorker.

If a system failure occurs in a node during backup or failover, a backup job can be executed by clustering NetWorker servers even when a standby node is executing a job.

Since backup data is managed centrally in a cluster system, recover can be performed from any node.

4.1.1.1 Takeover of backup service

The state transition procedure for NetWorker provided by SynfinityCluster/HA for NetWorker takes over the backup service in cooperation with SynfinityCluster.

If an operation node cannot continue a backup job, the operation node is automatically switched to a standby node. The standby node restarts a backup service by automatically starting a NetWorker server.

The standby node can restart the backup job without changing the NetWorker settings, and can recover it using the backup data saved by the operation node.

4.1.1.2 Automatic detection and repair of NetWorker errors

The monitoring monitor for NetWorker provided by SynfinityCluster/HA for NetWorker automatically detects and repairs NetWorker errors.

The function for enabling automatic NetWorker error detection or repair enables you to shorten the time required for the backup service to stop.

Overview of monitoring monitor

The monitoring monitor checks, repairs, starts, and monitors NetWorker.

The monitoring monitor terminates the operation if an error is detected on the NetWorker server. The monitoring monitor process is monitored by SynfinityCluster. If the monitoring monitor terminates, it is restarted with SynfinityCluster. The restarted monitoring monitor checks, repairs, starts, and monitors NetWorker again. Therefore, the retry count or retry interval of the monitoring monitor is linked with the retry count or retry interval of NetWorker.

The retry count or retry interval of the monitoring monitor can be set with the claddntw command. Also, the interval at

11

which the monitoring monitor starts NetWorker can be also set up by using the clntwparam command.

The monitoring monitor can automatically detect and repair the following errors: · NetWorker server process errors · NetWorker index errors Details of the errors and repairs are shown below:

NetWorker server process error

The monitoring monitor constantly monitors the NetWorker server process. If an error is detected, the NetWorker server included within the local node is restarted and the node is switched.

NetWorker server process monitoring Yes/No (monitoring mode) can be selected. Also, the NetWorker server (monitoring monitor) restart count, restart interval, and the interval at which the monitoring monitor starts NetWorker can be set.

For details on the monitoring modes and the setting of the interval at which NetWorker is started, refer to "clntwparam - Operational environment settings".

For details on the NetWorker server (monitoring monitor) restart count and restart interval, refer to "claddntw - NetWorker Resource Registration".

NetWorker index error

When NetWorker starts, the monitoring monitor checks the index by using the NetWorker command, and if it is found that repairing the index is necessary, use the NetWorker command to repair the target client. The occurrence of an error in the NetWorker server process during backup or failover due to power-off of the active node during backup is an example of such an error.

Index repairing Yes/No (recovery mode) can be selected.

For details on the recovery mode setting, refer to "clntwparam - Operational environment settings".

For details on how to manually repair an index error, refer t.o "Representative troubleshooting"

12

4.1.2 Operating Environment

4.1.2.1 System configuration

A cluster consists of an operation node and a standby node, each of which can act as a server, as well as a shared disk.

If a tape drive is connected, both an operation node and a standby node are required. However, a tape drive can be shared via a SCSI multi-initiate connection.

4.1.2.2 Operable SynfinityCluster cluster topology

SynfinityCluster/HA for NetWorker can be operated only in a 1: 1 cluster topology.

To use SynfinityCluster/HA for NetWorker, IP address takeover and node name takeover are required.

For details, see "Table of support format."

4.1.2.3 NetWorker operating environment

The table below lists the NetWorker components where SynfinityCluster/HA for NetWorker runs.

SynfinityCluster/HA for NetWorker supports the standby operation of NetWorker servers.

SynfinityCluster/HA for NetWorker cannot run on the NetWorker client or NetWorker storage node.

13

4.2 Setup and Installation

4.2.1 Environment Settings

4.2.1.1 Environment setup procedure

This section explains two procedures for setting up the environment: one procedure securely sets up the environment while confirming operation (Procedure 1), while the other sets up the environment in a shorter period of time by omitting the confirmation of operation (Procedure 2).

Procedure 1 requires more time to set the environment, but if a setting error is detected, the setting error can be easily identified.

Procedure 2 can set up the environment in a short period of time, but if a setting error is detected, the setting error cannot be easily identified.

Fujitsu recommends that system engineers or system administrators who have a lot of experience using SynfinityCluster/HA for NetWorker use Procedure 2.

Procedure 1 (to securely set up the environment while confirming operation)

14

Procedure 2 (to set up the environment in a short period of time)

The following sections explain the above items in detail.

· To use NetWorker in a cluster environment, a license registration that differs from the normal registration is

necessary. For details, refer to "NetWorker License Registration". · When a tape device is to be shared by an active node and a standby node, a setting that differs from the

normal setting is required. For details on how to make this setting, refer to "Notes on Building the Tape Device Shared System".

· By using node_setup of SynfinityCluster, batch installation is also possible. In this case, the only difference in the procedure from those above is that SynfinityCluster/HA for NetWorker is installed at the same time as SynfinityCluster. The other procedures are all the same. In the case of procedure 1, #20 is unnecessary, and in case of procedure 2, #8 and #14 are unnecessary.

4.2.1.2 SynfinityCluster environment settings

Follow the procedure below to set up the SynfinityCluster environment.

SynfinityCluster installation to setup of SynfinityCluster system initial configuration

After installing SynfinityCluster, start the cluster management view, register SynfinityCluster, set up the hardware, and set up the SynfinityCluster system initial configuration.

For information on SynfinityCluster installation and the above settings, refer to the "SynfinityCluster Installation and Administration Guide."

SynfinityCluster/HA for NetWorker, which is a product using the SynfinityCluster agent, can be installed or registered after setting up the initial configuration of the SynfinityCluster system by following the same procedure as explained in "SynfinityCluster system initial setup" in the "SynfinityCluster Installation and Administration Guide." However, to clarify the confirmation procedure, this manual explains the SynfinityCluster/HA for NetWorker environment setup procedure to be done after setting up the NetWorker environment. · Making shared disk device settings

Make the settings for the shared disk device. To specify the type of shared disk device to be shared, select [Switched Disk]. For the setup method, see "SynfinityCluster system initial setup" and "Shared disk device settings" in the "SynfinityCluster Installation and Administration Guide."

· Making the network settings

15

Make the network settings. For the takeover network, the settings for IP address takeover and node name takeover must be made during the setup of the NetWorker cluster environment. For information on the network settings, see "SynfinityCluster system initial setup" and "Network settings" in the "SynfinityCluster Installation and Administration Guide."

· Resource addition, cluster service creation, and operation confirmation Create a cluster service to which the shared disk, IP address takeover, and node name takeover resources are added. Select [Standby] as the cluster topology. Run the created cluster service, and confirm that SynfinityCluster is running normally. For information on resource addition, cluster service creation, and confirmation of SynfinityCluster operation, refer to the "SynfinityCluster Installation and Administration Guide." The NetWorker environment setup procedure, which is explained below, must be performed while this cluster service is running.

4.2.1.3 NetWorker environment settings

Follow the procedures below to set up the NetWorker environment: · NetWorker installation · NetWorker environment definitions The following sections explain the above procedures in detail.

NetWorker installation

Observe the notes below when installing NetWorker. For an explanation of the NetWorker installation procedure, refer to the NetWorker manual. · Installation node

NetWorker must be installed on each node. LGTOclnt (NetWorker client) and LGTOserv (NetWorker server) packages must be installed.

· Installation file Install the NetWorker binary file, which is created at installation, on the local disk of each node, and allocate the NetWorker management file (client and server information) on the shared disk to share them between the nodes.

· Specifying the NetWorker management file storage directory If NetWorker is being installed on the operation node, create the NetWorker management file on the shared disk. Specify the same directory as the directory specified when installing the NetWorker on the standby node. While installing NetWorker, specify the directory on the shared disk in response to the following input request: "Directory to use client and server information []?"

· Installation state Installation must be performed while the cluster service runs. After installation on the operation node is completed, confirm that NetWorker is operating normally. After the confirmation, terminate NetWorker and exchange the cluster service. After the cluster service is exchanged and access from the standby node to the shared disk is enabled, install NetWorker on the standby node. After installation on the standby node is completed, start NetWorker, confirm NetWorker operation, terminate NetWorker, and exchange the cluster service.

After NetWorker is installed, it is started automatically at system startup. The cluster service must be exchanged after stopping NetWorker to ensure that multiple instances of NetWorker do not start on the nodes simultaneously.

NetWorker environment definitions

Define the NetWorker environment, noting the following points. For an explanation of the NetWorker environment definition procedure, refer to the NetWorker manual. · NetWorker server name

The NetWorker server name becomes the takeover node name specified for node name takeover. · NetWorker settings

Different settings, such as the NetWorker client definition, must be defined on the operation node side, not on the standby node side. After the environment definition is completed, exchange the cluster service, and confirm that the settings defined on the operation node are also valid on the standby node. After the confirmation, exchange the cluster service again.

16

4.2.1.4 SynfinityCluster/HA for NetWorker environment settings

Follow the procedure below to set the environment for SynfinityCluster/HA for NetWorker: · SynfinityCluster/HA for NetWorker installation · License registration · State transition procedure resource registration · Cluster Service settings The following sections explain the above procedures in detail.

SynfinityCluster/HA for NetWorker installation

SynfinityCluster/HA for NetWorker must be installed on each node.

For the installation method, refer to the "SynfinityCluster/HA for NetWorker Installation Guide."

License registration

Register the license for SynfinityCluster/HA for NetWorker. For the license registration method, see "SynfinityCluster system license registration" in the "SynfinityCluster Installation and Administration Guide."

State transition procedure resource registration

To register the state transition procedure resource for switching the NetWorker server in SynfinityCluster, execute the following claddntw command, provided by SynfinityCluster/HA for NetWorker:

"# /etc/opt/FJSVclntw/bin/claddntw"

The resource name is "NW_server." The resource of the state transition procedure must be registered in each node.

Since the NetWorker start-stop operation must be controlled by SynfinityCluster under the cluster environment, executing the claddntw command provided by NetWorker automatically renames the following start-stop procedure:

/etc/rc2.d/S95networker

/etc/rc0.d/K05networker

The start-stop procedure is renamed as follows:

/etc/rc2.d/FJSVclntw.S95networker

/etc/rc0.d/FJSVclntw.K05networker

Cluster Service settings

Follow the procedure below to add the resource registered by the claddntw command to the cluster service created in "SynfinityCluster environment settings " · Stop the cluster service created in "SynfinityCluster environment setup." · In [Config] , [Change] and [Configuration] of the cluster service, add the resource registered by the

claddntw command. For information on the cluster service configuration change, see "Setup change" or "Cluster service configuration change" in the "SynfinityCluster Installation and Administration Guide." After changing the cluster service configuration, set up other applications or SynfinityCluster as necessary.

When the initial value of the environment of SynfinityCluster/HA for NetWorker is to be changed with the clntwparam command, the change must be made by the time at which the cluster service is started after the installation of SynfinityCluster/HA for NetWorker.

4.2.1.5 Operation check

After all nodes are restarted, operation is started. After the cluster service is started, the following log file is created:

/var/opt/FJSVclntw/logs/FJSVclntw.log

After a few lines of trace information are output to the log file, "Beginning of process watch." or "Process pause start" is logged. If no error information is detected, operation is assumed to have started normally.

17

The monitoring monitor starts even in a mode in which process monitoring is not performed.

After the message "0100: The processing of the NetWorker watch monitor begins." is output at startup, processes such as NetWorker startup are performed.

4.2.2 NetWorker License Registration

Enter and apply the NetWorker enabler code and authorization code by means of the following procedure.

Operation Procedure: 1. Confirm on the active node that the NetWorker server is normally started up.

Enter the license number of NetWorker in the state that the NetWorker server is started in the active node after the installation of SynfinityCluster, NetWorker, and SynfinityCluster/HA for NetWorker.

2. Log in to the active node as the superuser. 3. Start up the administration program (nwadmin) by executing the command shown below:

# nwadmin & 4. After specifying [Server] on the menu bar, open the [Registration] window. 5. Click [Create]. 6. Enter an enabler code in [Enabler code]. 7. After specifying "Server setting*" from the "Server" menu bar, open the [Server] window. Then, enter a name,

address, telephone number, and e-mail information. 8. Create the following file:

/nsr/res/hostids 9. Describe hostid for the active and standby nodes in the /nsr/res/hostids file created in procedure 8 in the

following format: - Description format

Active node hostid: Standby node hostid - Specification example

When the hostid of each node is the following: Hostid of active node: 12345678 Hostid of standby node: 87654321 Describe the following: 12345678: 87654321 The hostid of each node can be found by executing the hostid command on each node.

10. Change the [Server] window to tabular format and output the contents of the [Server] resource. 11. The subsequent procedure is the same as that for normal NetWorker license application.

Referring to procedure 10, output results, fill in the necessary items in the license password application form and send it in to the password center. When the password center issues your "authorization code", enter the authorization code into the "Authorization Code" field of the [Registration] window. Once the authorization code is entered, permanent use of NetWorker is enabled.

For details on the enabler and authorization codes, refer to the NetWorker manual.

The above operation is performed only from an active node. There is no need to for it to be performed in standby node.

4.2.3 Notes on Building the Tape Device Shared System

Operational environment settings

When a tape device is to be shared by active and standby nodes, it is necessary to specify the device path name of the tape device to be shared in the environment setting.

Use the clntwparam command to set up the environment.

For details on the clntwparam command, refer to "clntwparam - Operational environment settings".

[Use example]

"# /etc/opt/FJSVclntw/bin/clntwparam Devices /dev/rmt/0cbn"

When the environment setting is to be changed, change it by the time the cluster service starts after

18

the installation of SynfinityCluster/HA for NetWorker. In the case of Procedure 1 in "Environment setup procedure", change the environment before #24 and, in the case of Procedure 2, change it before #12 and #19. When the cluster service is started up without specifying the device path name of the tape device to be shared, a phenomena such as a tape not being able to be mounted in the jukebox may occur.

st driver setting

To share the tape device between an active node and a standby node, the SCSI multi-initiate must be connected.

To connect the SCSI multi-initiate, the st driver must be set so that the device is not reserved.

To change the st driver setting, modify /kernel/drv/st.conf by using the vi editor or similar.

Taking DLT7000 as an example, the procedure for setting the st driver is explained below:

Operation Procedure: 1. Add (or validate) the description of the device to be used for tape-config-list of /kernel/drv/st.conf, as follows: - Specification example

tape-config-list = "QUANTUM DLT7000", "Quantum DLT7000", "DLT7k-data"; DLT7k-data = 1,0x38,0,0x1D639,4,0x82,0x83,0x84,0x85,2;

2. Add the option shown below to the added (or validated) device description: ST_NO_RESERVE_RELEASE 0x20000

- Specification example tape-config-list = "QUANTUM DLT7000", "Quantum DLT7000", "DLT7k-data"; DLT7k-data = 1,0x38,0,0x3D639,4,0x82,0x83,0x84,0x85,2;

The st driver must be set for each node.

Restart the OS after modifying st.conf to validate the setting.

If the ST_NO_RESERVE_RELEASE option is not validated, backup with a new active node fails due to an access authority error when failover occurs during backup.

4.3 Operation

4.3.1 Changing the Environment

4.3.1.1 Changing the Environment of the Monitoring Monitor and state Transition Procedure

To change the environment of the monitoring monitor or state transition procedure, use the clntwparam command that is provided by SynfinityCluster/HA for NetWorker.

You can change the following parameters: · Device path name used to issue a SCSI reset (must be set up for sharing a tape device) · NetWorker startup interval · System log collection mode · Monitoring mode · Recovery mode · Log size · NetWorker startup language Changes are validated when the next cluster service is started after execution of the command.

The command must be executed for all nodes constituting the cluster service.

For details on the clntwparam command, refer to "clntwparam - Operational Environment Setting".

4.3.1.2 NetWorker resource operational environment changes

The following parameters can be changed for the NetWorker resources: · Retry count of the monitoring monitor · Retry interval of the monitoring monitor Changes can be made using either of the following two methods: · Using the SynfinityCluster command · Using the SynfinityCluster/HA for NetWorker command

19

Each method is explained below:

Using the SynfinityCluster command

The monitoring monitor process is monitored with SynfinityCluster.

Therefore, the retry information specified with the claddntw command can be changed when the NetWorker resources are added by using the SynfinityCluster command.

Changes can be made by using the clsetprocrsc command provided by SynfinityCluster.

Enter the command in the following format:

"# /etc/opt/FJSVcluster/bin/clsetprocrsc -n rsc_name -t time -u count"

Specify a resource name for rsc_name. The resource name of the NetWorker resource is NW_server when the resource is registered.

Specify a retry count for time.

Specify a retry count for count.

The settings of the other node can be changed by using the "-s nodename" option.

For details on the clsetprocrsc command, refer to the "SynfinityCluster Installation/Administration Guide."

Using the SynfinityCluster/HA for NetWorker command

Changes can be made by using the claddntw command provided by SynfinityCluster/HA for NetWorker.

Operation Procedure: 1. Stop the cluster service that includes the NetWorker resource. 2. Delete the resource from the cluster service for cluster service configuration change. 3. Delete the NetWorker resource by using the cldelntw command. 4. Use the claddntw command to add the NetWorker resources.

At this time, specify a value to be changed for the parameter of the claddntw command. 5. By changing the cluster service configuration, add resources to the cluster service. 6. Start up the cluster service. Steps 3. and 4. must be executed for each node.

4.3.1.3 Deleting NetWorker resource

To delete a NetWorker resource, execute the cldelntw command provided by SynfinityCluster/HA for NetWorker:

"# /etc/opt/FJSVclntw/bin/cldelntw"

If a cluster service contains a NetWorker resource to be deleted, the resource cannot be deleted. To delete the resource, first, delete the cluster service, or delete the resource from the cluster service when changing the cluster service configuration. Next, execute the cldelntw command on both of the operation node and the standby node.

By executing the cldelntw command, the NetWorker start-stop procedure renamed when the cldelntw command was executed is automatically restored to its original name.

To uninstall SynfinityCluster/HA for NetWorker, the NetWorker resource must be deleted beforehand.

4.3.2 Autorestart of a Backup Job

By using the Autorestart function of NetWorker, an automatic backup job can be re-executed automatically on a new active node if a failover occurs during backup due to an error occurring in the NetWorker server or active node.

Re-execution of a backup job using the Autorestart function is explained below.

4.3.2.1 Autorestart function

The Autorestart function of NetWorker is used to re-execute backup automatically when the NetWorker server is next started if backup did not terminate normally due to power-off of the node or for some other reason. Describe EOF on the tape that has been partially written, and then perform back up from the beginning of the set whose saving was interrupted.

For details on this function, refer to the NetWorker manual.

By validating the Autorestart function, automatic backup can be re-executed on the new active node if a failover occurred during backup.

20

4.3.2.2 Autorestart setting procedure

Validate the Autorestart function by means of the following procedure.

Operation Procedure: 1. Confirm that the NetWorker server has started normally on the active node. 2. Log on to the active node as the super user. 3. Start the administration program (nwadmin) by executing the following command:

# nwadmin & 4. After specifying "Customize" on the menu bar, open the [Group] window. 5. After specifying the [Group] window, click [View]->[Details]. 6. Change "Autorestart" to "Enabled." To validate the Autorestart function, "Autostart" must be set to "Enabled." If "Manual restart" of "Options" is selected, Autorestart is not performed.

Be careful to ensure that "Manual restart" of "Options" is selected automatically if backup is interrupted halfway.

4.3.2.3 Notes on using the Autorestart function

A NetWorker error may occur before Autorestart depending on the timing of failover, such that backup may not be re-executed automatically.

If a phenomena like this occurs, again perform backup manually after removing the cause of the NetWorker error.

For details on representative NetWorker errors and actions, refer to Section 7.3.4, "Troubleshooting."

4.3.3 Notes on Operation

· Node where the NetWorker server is operated During operation, the NetWorker server is started by the operation node, which cannot be started by the standby node. Therefore, backup cannot be executed on the standby node side.

· Backup and recovery of the server local disk The backup and recovery of the server local disk is performed only for the operation node that is being operated. Using node name takeover, NetWorker recognizes the local disk on the operation node side to be identical with the local disk on the standby node side. Therefore, when performing a backup and recovery of the server local disk, an individual backup for different nodes or recovery to different nodes must not be performed.

· file.xxxx file If the monitor is not normally terminated by a node error, a work file named file.xxxx (xxxx is an optional numeric value) may remain in /var/opt/FJSVclntw/logs. This file may be used to check for an error.

· Tape device common operation When the tape drive is shared via a SCSI multi-initiate connection, the system recognizes that the tape has become full if the standby node shuts down during backup. Do not restart the standby node while backup or recovery is being performed.

4.3.4 Troubleshooting

4.3.4.1 Actions to be applied if a problem occurs

Log information for SynfinityCluster/HA for NetWorker is written to the following file:

/var/opt/FJSVclntw/logs/FJSVclntw.log

To correct an error, refer to this information and the SynfinityCluster and NetWorker log information.

For information on the SynfinityCluster and NetWorker log information, refer to the related manuals.

4.3.4.2 Collecting problem information

If a problem occurs, collect information for investigation by using the clntwlog command. Then, call your Fujitsu systems engineer (SE) and provide him or her with the collected information, details of the problem, and an explanation of the processing being performed when the problem occurred.

For details on the clntwlog command, refer to "clntwlog - Collecting Maintenancne-Information".

4.3.4.3 Representative troubleshooting

Representative problems and countermeasures are explained below.

21

Access authority error

Problem contents

After the occurrence of failover in an environment in which a tape device is shared between an active and a standby node, an error with the message, "Cannot open for read only. Access denied", occurs and mount/unmount cannot be executed.

Examples of the NetWorker messages are shown below:

-------------------------------------------------------------------------------------

Device:

/dev/rmt/0cbn (J) dlt7000 not mounted, cannot open for read only, access denied.

Messages:

Mon: 10: 00: 00 (hour/minute/second) index notice: 1 client check completed. [E0285-U03A]

Mon: 10: 00: 30 (hour/minute/second) media warning: /dev/rmt/0cbn open processing: Access denied.

[E0284-E0263]

Mon: 10: 01: 15 (hour/minute/second) /dev/rmt/0cbn Cannot open for read only. Access denied.

[270GH]

-------------------------------------------------------------------------------------

Response

The st driver setting may be incorrect.

If the setting of the st driver is incorrect, the above phenomena will occur if a failover occurs due to power-off of the node during back up operation (tape recording).

Confirm whether the st driver setting is correct.

Set up the st driver by means of the following procedure: 1. Add (validate) the device description to be used for tape-config-list of /kernel/drv/st.conf:

Specification example: tape-config-list = "QUANTUM DLT7000", "Quantum DLT7000", "DLT7k-data"; DLT7k-data = 1,0x38,0,0x1D639,4,0x82,0x83,0x84,0x85,2;

2. Add the option shown below to the description of the device that was added (validated): Add the following option to the added (validated) device description: ST_NO_RESERVE_RELEASE 0x20000 Specification example: tape-config-list = "QUANTUM DLT7000", "Quantum DLT7000", "DLT7k-data"; DLT7k-data = 1,0x38,0,0x3D639,4,0x82,0x83,0x84,0x85,2;

The st driver must be set up for each node.

Restart the OS after modifying /kernel/drv/st.conf to validate the setting.

Erroneous inventory

Problem contents

An error, "Cannot open for read only. Input-output error", has occurred and mount/unmount cannot be executed normally.

Examples of the NetWorker messages are shown below:

-------------------------------------------------------------------------------------

Device:

/dev/rmt/0cbn (J) dlt7000 not mounted, cannot open for read only, input-output error.

22

Messages:

Mon 10: 00: 00 (hour/minute/second) index notice: 1 client check completed [E0285-U03A]

Mon 10: 01: 34 (hour/minute/second) media warning: /dev/rmt/0cbn open processing: input-output error [E0284-E0263]

Mon 10: 01: 34 (hour/minute/second) /dev/rmt/0cbn cannot open for read only, input-output error [270GH]

-------------------------------------------------------------------------------------

Response

The status of the tape device may not be being recognized correctly by NetWorker.

If the tape device is being operated manually, the above phenomena may occur when a failover occurs due to power-off in the node during the operation of Autochanger or when a standby node is restarted during the operation of Autochanger.

Perform inventory again for the following procedure: 1. Execute the command shown below to reset the consistency:

# nsrjb -H 2. Execute the following command for the inventory again:

# nsrjb -I For details on the nsrjb command, refer to the NetWorker manual.

Erroneous index

Problem contents

"index notice: client cat (invlid database header) check failed" error message occurs and backup is disabled.

Examples of the messages are shown below:

-------------------------------------------------------------------------------------

Device:

/dev/rmt/0cbn (J) dlt7000 cat.001 Mounting completed dlt7000 tape cat.001

Messages:

Mon 10: 00: 00 (hour/minute/second) index notice: client cat (invalid database header) check failed [E0285-V02B-U036]

Mon 10: 00: 00 (hour/minute/second) index notice: 1 client check completed [E0285-U03A]

Mon 10: 00: 39 (hour/minute/second) media info: dlt7000 tape cat.001 was written before crashing. [E0286-2702V]

Mon 10: 01: 00 (hour/minute/second) media info: read 354 record items, EOF mark after file3 [E0286-27033]

Mon 10: 01: 05 (hour/minute/second) /dev/rmt/0cbn mounting completed dlt7000 tape cat.001 [E0WK]

-------------------------------------------------------------------------------------

Response

The NetWorker index file may have been destroyed.

The above phenomena may occur if a failover occurs due to power-off of the node during backup.

Modify the NetWorker index by means of the following procedure: 1. Check the index.

# nsrck 2. Repair the index.

# nsrck -F client name For details on the nsrck command, refer to the NetWorker manual.

I/O error

Problem contents

An input-output error occurs in an environment in which a tape device is shared and tape mount/unmount cannot be executed.

23

Response

A device path name may not be set up.

If a device path name is not set up in an environment in which a tape device is shared, restart the cluster service after setting it up with the clntwparam command.

4.4 Command

4.4.1 claddntw - NetWorker Resource Registration

Executing user:

Superuser

Format:

/etc/opt/FJSVclntw/bin/claddntw [-u retry count] [-t retry interval]

Explanation of the function of this command:

This command registers a NetWorker resource, or registers the state transition procedure. The resource class of the resource to be registered is Application.

parameter

Retry information on the process monitoring for the NW_server resource can be set up by specifying [-u retry count] and [-t retry interval].

The target of the process monitoring is the monitoring monitor.

If this specification is omitted, it is assumed that you have specified 3.

(Use example)

# /etc/opt/FJSVclntw/bin/claddntw -u 5 -t 10

Retry count is 5

Retry interval is 10

#

Termination status:

0: Normal termination Value other than the above: Abnormal termination

Notes:

To execute this command, the SynfinityCluster or NetWorker package must be installed. If the same resource has already been registered, an error is assumed. By executing the claddntw command, the start-stop procedures provided by the following NetWorker are automatically renamed:

/etc/rc2.d/S95networker /etc/rc0.d/K05networker

The start-stop procedures are renamed as follows:

/etc/rc2.d/FJSVclntw.S95networker /etc/rc0.d/FJSVclntw.K05networker

4.4.2 cldelntw - NetWorker Resource Deletion

Executing user:

Superuser

Format:

/etc/opt/FJSVclntw/bin/cldelntw

24


This command deletes a NetWorker resource, or deletes the state transition procedure.

parameters:

None

Termination status:


Notes:

If a cluster service contains a NetWorker resource to be deleted, the resource cannot be deleted. Delete the cluster service, or delete the resource from the cluster service when changing the cluster service configuration.

By executing the cldelntw command, the NetWorker start-stop procedure renamed when the claddntw command was executed is automatically restored to its original name.

4.4.3 clntwparam - Operational environment settings

Executing user:

Superuser

Format:

/etc/opt/FJSVclntw/bin/clntwparam [parameter name setup value]

/etc/opt/FJSVclntw/bin/clntwparam -p [parameter name]


Set up and display the environment of the monitoring monitor and state transition procedure.

A value cannot be set up for multiple parameters at the same time.

parameters:

The environment can be set up by specifying the "parameter name setup value."

The environment can be set up by specifying the "-p parameter name."

If the specification of "parameter name" is omitted, the contents of all the parameters that are currently set are displayed.

The following can be set for "parameter name setup value." Devices device path name:

Specify the device path name of the tape device to be used in "device path name." If this specification is available, issue a SCSI reset to the specified device before NetWorker starts. This specification is essential when a tape device is to be shared with a SCSI multi-initiate connection. If two or more tape devices are available, delimit the "device path name" with blanks to specify two or more tape devices at the same time. (Use example) /etc/opt/FJSVclntw/bin/clntwparam Devices /dev/rmt/0cbn /dev/rmt/1cbn

Start-Interval interval(s): Specifies the interval at which the monitoring monitor executes /etc/init.d/networker start. The initial value is 60(s). The specifiable range is 0 to 3600. (Use example) /etc/opt/FJSVclntw/bin/clntwparam Start-Interval 60

Syslog facility priority: Specifies to the mode that the monitoring monitor collects the system log. Specifiable values for the facility are daemon, local0, local1, local2, local3, local4, local5, local6, local7, and user. Specifiable values for the priority are notice, err, warning, info, and debug. The initial value is daemon.err. (Use example) /etc/opt/FJSVclntw/bin/clntwparam Syslog local1.err

Monitor-Mode mode: Specifies the monitoring mode of the monitoring monitor.

25

0 Performs process monitoring for nsrd. 1 Does not perform process monitoring for nsrd. The specifiable values are 0 and 1 only. The initial value is 0. (Use example) /etc/opt/FJSVclntw/bin/clntwparam Monitor-Mode 1

Recovery-Mode mode: Specifies the recovery mode when the monitoring monitor starts up. 0 Does not perform index recovery. 1 Performs only index recovery. The specifiable values are 0 and 1. Initial value is 1. (Use example) /etc/opt/FJSVclntw/bin/clntwparam Recovery-Mode 0

Log-Size log size (KB) : If this size is exceeded, change the name to "*.old" and create a new file. The specifiable range is 10 to 4096. The initial value is 512. (Use example) /etc/opt/FJSVclntw/bin/clntwparam Log-Size 1024

NetWorker-Lang Language when NetWorker starts up : The monitoring monitor sets this value in LANG of the environment variable when NetWorker starts. The specifiable values are either "C" or "ja." The initial value is "C." If "C" is specified, NetWorker starts up in English mode and, if "ja" is specified, it starts up in Japanese mode. (Use example) /etc/opt/FJSVclntw/bin/clntwparam NetWorker-Lang ja

Termination status:


4.4.4 clntwlog - Collecting Maintenance-Information

Executing user:

Superuser

Format:

/etc/opt/FJSVclntw/bin/clntwlog [-d output destination directory path]


Collects diagnostic data if an error occurs.

The output destination file name is clntwtrace.tar.Z.

Parameters:

The output destination directory can be specified by specifying "-d output destination directory path." This directory is also used as the work directory. The default is /var/tmp.

(Use example)

# /etc/opt/FJSVclntw/bin/clntwlog -d /tmp

Getting NetWorker log.

*** Internal log collection completion ***

*** NetWorker log collection completion ***

*** System log collection completion ***

Getting system information.

*** Process ***

*** Package ***

*** Network ***

*** Resource tree ***

*** tar + compress ***

complete

26

#

Termination status:


Notes:

If this command is executed while the cluster service is "stopped", the current log of NetWorker cannot be collected. Collect the materials either after mounting shared disks only with the /usr/sbin/mount command or after starting a cluster service after removing the NW_server resources from the cluster service.

Note that this command does not confirm the amount of empty disk space.

4.5 Message List

This appendix explains the error messages output during installation or operation of SynfinityCluster/HA for NetWorker.

4.5.1 Error Messages at Installation of SynfinityCluster/HA for NetWorker

The following lists the content, explanation, and required operator response of error messages output during installation of SynfinityCluster/HA for NetWorker.

Cannot install this package under "$OS".

Content:

This product cannot be installed under "$OS."

Corrective action:

Install this product under an operating system where it can be operated.

Cannot install this package. This package needs Solaris 2.6 SPARC later.

Content:

This product must be installed under Solaris 2.6 or later.

Corrective action:


Cannot install this package. This package needs Solaris for SPARC.

Content:

This product must be installed under SPARC Solaris.

Corrective action:


4.5.2 Command Error Messages

The following lists the content, explanation, and required operator response of error messages output during execution of the commands.

The SynfinityCluster messages may be output in cases other than below. For details on the SynfinityCluster messages, refer to the manual provided with SynfinityCluster.

27

A message is output in the format, "package name: message level: message number: message text." "FJSVclntw" is output to the "package name." The format in which the package name is excluded is explained in the following.

4.5.2.1 Messages common to all commands

ERROR: 4001: No system administrator authority.

Content:

The operator is not a system administrator.

Corrective action:

Re-execute the command with system administrator authority.

ERROR: 4002: The clchkcond command failed.

Content:

The clchkcond command cannot be executed. The SynfinityCluster environment is not established.

Corrective action:

Review the SynfinityCluster environment, and re-execute the command.

ERROR: 4003: The clgetnode command failed.

Content:

The clgetnode command cannot be executed. The SynfinityCluster environment is not established.

Corrective action:


ERROR: 4004: The clgetrid command failed.

Content:

The clgetrid command cannot be executed. The SynfinityCluster environment is not established.

Corrective action:


4.5.2.2 claddntw-specific messages

ERROR: 4008: LGTOserv package not found.

Content:

NetWorker server is not installed.

Corrective action:

Install NetWorker server, and re-execute the command.

28

ERROR: 4009: NetWorker resource $KEY is exist.

Content:

NetWorker resource exists. NetWorker resources have been registered.

Corrective action:

None

ERROR: 4005: The claddprocrsc command failed.

Content:

The claddprocrsc command cannot be executed. SynfinityCluster environment is not established.

Corrective action:


4.5.2.3 cldelntw-specific messages

ERROR: 4010: NetWorker resource $KEY is not found.

Content:

NetWorker resource does not exist. NetWorker resources have been deleted.

Corrective action:

None

ERROR: 4011: Can't delete the NetWorker resource because the NetWorker resource is registered in the cluster service.

Content:

NetWorker resources have been registered in the cluster service.

Corrective action:

Delete the cluster service, or delete the resource from the cluster service when changing the cluster service configuration. Then, re-execute the command.

ERROR: 4006: The clgetrsc command failed.

Content:

The clgetrsc command cannot be executed. The SynfinityCluster environment is not established.

Corrective action:


29

ERROR: 4007: The cldelprocrsc command failed.

Content:

The cldelprocrsc command cannot be executed. The SynfinityCluster environment is not established.

Corrective action:


4.5.2.4 clntwparam-specific messages

ERROR: 4201: The specified parameter ($PARAM) is invalid.

Content:

The specified parameter does not exist.

Corrective action:

Check the parameter name, and re-execute the command.

ERROR: 4202: $RANGE is the range of values that can be set for parameter ($PARAM).

Content:

The permissible range is exceeded for the value to be set up for the parameter.

Corrective action:

Specify a value within the permissible range and re-execute.

ERROR: 4203: The command terminated abnormally. Detail: X,X

Content:

An internal error occurred.

Corrective action:

Call your Fujitsu systems engineer.

4.5.2.5 clntwlog-specific messages

ERROR: 4021: The $PATH directory does not exist.

Content:

The directory specified with the -d option does not exist.

Corrective action:

Specify the directory that is included within the -d option.

30

ERROR: 4022: Abnormal end. Detail: X,X

Content:

An internal error occurred.

Corrective action:

Call your Fujitsu systems engineer.

ERROR: 4023: The "$CMD" command terminated abnormally. Processing is ended. Detail: X

Content:

"$CMD" terminated abnormally. Either /usr/bin/cp or /usr/bin/tar or /usr/bin/compress is entered for "$CMD." An example of an error that occurs as a result of there being too little free space on the disk is shown below:

(Error example)

Getting NetWorker log.

*** Internal log collection completion ***

tar: write error: EOF error has been detected.

ERROR: 4023: The /usr/bin/tar command terminated abnormally. Processing is ended. Detail:2

Corrective action:

Check the amount of disk space in the directory specified with /var/tmp or the -d option. Change the output destination directory and then re-execute.

WARNING: 2002: It was judged that the mountpoint of /nsr was /. Confirm the mountpoint of /nsr. Do you continue? (default: n) [y,n,?]

Content:

This is a warning message prompting you to input the mount point of the NetWorker administration information directory (/nsr)and to wait for a user response.

This message is displayed if you perform execution while the cluster service is stopped or in a node on the standby instance side.

Corrective action:

To continue after confirming the /nsr mounting point of the directory, enter "y" to continue and "n" to stop.

31

Chapter 5 SynfinityCluster/HA for Oracle


SynfinityCluster/HA for Oracle is a software product for enabling standby operation of Oracle instances on a cluster system configured with SynfinityCluster.


SynfinityCluster/HA for Oracle facilitates standby operation of Oracle on a cluster system by providing definition files and state transition procedures for configuring Oracle on a cluster system.


See the "Table of support format"for details.

5.2 Standby class

5.2.1 1:1 standby configuration, N:1 standby configuration, two-node mutual standby configuration


33

[Example of N:1 standby configuration]

[Example of two-node mutual standby configuration]

5.2.2 Outline

In cluster operation using SynfinityCluster/HA for Oracle, database access will be suspended temporarily if a system failure occurs due to the failure of an active node during access to a database server (hereafter, described as database). However, access to the database can be restarted by switching the database environment to the standby node and connecting from the client again. 1:1 standby of two nodes, mutual standby of two nodes, and N:1 standby of multiple nodes are supported as cluster configuration patterns.

5.2.3 Procedure for environment setup

An Oracle cluster environment can be set up by the following procedures: · SynfinityCluster environment setting:

Using the Web-Based Admin View to set up the takeover network. · Oracle server environment setting:

34

Installing Oracle and setting up its environment. Methods for specifying specific parameters and notes to regard are here also.

· SynfinityCluster/HA for Oracle environment setting: Setting up the environment of SynfinityCluster/HA for Oracle. Environment settings depend on the cluster.

· Resource registration and cluster service setting of state transition procedure: Registering the state transition procedure for switching resources used by Oracle. The state transition procedure must be registered in the cluster system as a resource, and this resource must be specified by the cluster service before it can be used.

The following describes the detail procedures of the above:

Setting up the SynfinityCluster environment:

Setting up the Shared Disk Device

Set up the shared disk device to be used to create an Oracle database. Refer to the "SynfinityCluster Installation/Administration Guide" for details.

Setting up the takeover network

Use the Web-Based Admin View to set up the takeover network. Refer to the "SynfinityCluster Installation/Administration Guide" for details.

Hereafter, the target IP address for takeover is described as logical IP address.

Registering the cluster service

Use the Web-Based Admin View to register the resource of the above-mentioned shared disk device and the cluster service that includes the resource of the takeover network. For details, see "SynfinityCluster Installation/Administration Guide.". · Select [Standby] as the cluster topology. · Select the resources of the takeover IP address (logical IP address), and the resources of the shared disk

device as the resources that make up the cluster service. · Select [Switched Disk] as the usage type of the shared disk device.

SynfinityCluster operation confirmation

Start up the registered cluster service and confirm its operation. · Confirm that the shared disk device can be accessed from the node in the active instance. · Confirm that the node in the active instance can be accessed from the client machine by using the logical IP

address. · Switch the cluster service and perform the same confirmation for the node in the standby instance.

35

Setting up the Oracle environment:

[Definition files and setup matrix]

Installation of Oracle (for Oracle 8.0.x)

Install Oracle following the instructions on the installation screens as described below. (Example of using Oracle 8.0.5 to create a database on a file system.)

If you plan to install Oracle8.0.6, refer to the "Oracle Installation Guide (For Oracle8.0.6)". · Installation Type (selection of installation type)

Select [Custom Install]. · Installation Options (selection of installation options)

Select [Install New Product - Create DB Objects]. In case of installing Oracle to a standby node in standby configuration, select [Install New Product - Do Not Create DB Objects]. In this case, the following operations are required to start Oracle in the standby node.

- Create the following directories: $ORACLE_BASE/admin/$ORACLE_SID $ORACLE_BASE/admin/$ORACLE_SID/bdump $ORACLE_BASE/admin/$ORACLE_SID/cdump $ORACLE_BASE/admin/$ORACLE_SID/udump $ORACLE_BASE/admin/$ORACLE_SID/pfile

- Copy the following file from the active node: $ORACLE_BASE/admin/$ORACLE_SID/pfile/init$ORACLE_SID.ora $ORACLE_BASE/admin/$ORACLE_SID/pfile/config$ORACLE_SID.ora

- Create a link as follows: ln -s $ORACLE_BASE/admin/$ORACLE_SID/pfile/*.ora $ORACLE_HOME/dbs/

· Software Asset Manager (selection of product list) The following products are requisite: Oracle8 Enterprise (RDBMS) PL/SQL Net8

· Create DB Objects(F/S): Control File Distribution Select [No]. On the next screen, specify the mounting point on the shared disk.

36

· SYSTEM Password ( Password registration screen for SYSTEM users) Enter "manager". If specifying a password other than "manager", set the password file according to the "Password file of Oracle failure monitoring monitor".

· dba Password Select [No].

· TNS Listener Password (Listener Password input screen) Enter "network"(recommended). Though this password will be specified, it will not be enabled.

· Default Database Select [Yes].

Installation of Oracle (Oracle8.0.6)

Install Oracle(8.0.6) following the instructions on the installation screens as described below in addition to the instructions of "Installation of Oracle (for Oracle 8.0.x)". · Configure MTS and start SQL*Net listener ?

Select [Yes]. If you select [No], Oracle8.0.6. will not automatically create the following files. $ORACLE_HOME/network/admin/listener.ora $ORACLE_HOME/network/admin/tnsnames.ora

Installation of Oracle (Oracle8i)

Install Oracle8i by following instructions on the installation screen. (Example of using Oracle 8.1.5 to create a database on a file system) · Available Products (Selecting a product to be installed)

Select [Oracle8i Enterprise Edition]. · Installation Types (Selecting an installation type)

Select [Custom]. · Available Product Components (Selecting a product component)

The following products are requisite: Oracle8i Server Net8 Client Net8 Server

· Create Database (Selecting database creation) Select [Yes]. However, if you are installing an Oracle product on a standby node in standby configuration, select [No]. In this case, the following procedure need to be executed after completing installation to start the installed Oracle product on the standby node:

- Create the following directories: $ORACLE_BASE/admin/$ORACLE_SID $ORACLE_BASE/admin/$ORACLE_SID/bdump $ORACLE_BASE/admin/$ORACLE_SID/cdump $ORACLE_BASE/admin/$ORACLE_SID/udump $ORACLE_BASE/admin/$ORACLE_SID/pfile

- Copy the following file from the active node: $ORACLE_BASE/admin/$ORACLE_SID/pfile/init$ORACLE_SID.ora $ORACLE_HOME/dbs/orapw$ORACLE_SID

- Create a link as follows: ln -s $ORACLE_BASE/admin/$ORACLE_SID/pfile/*.ora $ORACLE_HOME/dbs/

- The permissions for the directories and files created above must be identical to those on the active node.

· Database File Location (For storing the database file) Specify the location of the database file on the shared disk.

· Net8 Configuration Assistant: Listener Configuration, TCP Client Type Select [Net8 Clients].

· Net8 Configuration Assistant: Naming Methods Configuration Select [No].

Definition of the Oracle environment · environment definition file/var/opt/oracle/oratab

In the SynfinityCluster/HA for Oracle, the oratab file is disabled because the database is started or stopped independently.

· /etc/system To use SynfinityCluster/HA for Oracle, the system resource values used by Oracle itself must be specified in addition to the values calculated in the "SynfinityCluster System Design Worksheet".Refer to the Oracle manual for the values required by Oracle itself; refer to the "SynfinityCluster Installation/Administration Guide" for the "SynfinityCluster System Design Worksheet". The values are affected by the amount of the physical memory of each node. For parameters that affect to

37

Oracle (especially shmmax), it is recommended to set up the same values for each node. This restriction should not be applied if the amount of the physical memory is different for each node of the cluster, in which case the system switching time(performance) will be affected.

Before installing the Oracle, be sure to change the /etc/system setting and reboot the node. Setup example: set shmsys:shminfo_shmmax=0x10000000

set shmsys:shminfo_shmmin=1

set shmsys:shminfo_shmmni=100

set shmsys:shminfo_shmseg=12

set semsys:seminfo_semmns=400

set semsys:seminfo_semmni=512

set semsys:seminfo_semmsl=200

set semsys:seminfo_semmnu=200

set semsys:seminfo_semopm=100

set semsys:seminfo_semume=100 · /etc/services

Set port numbers according to the number of required listeners. For 1:1 standby, at least one listener is required. For N:1 standby, at least N listener is required. For mutual standby, at least two listeners are required.

- Example in case of a single listener listener 1521/tcp oracle

- Example in case of two listener lsnr1 1521/tcp oracle lsnr2 1522/tcp oracle

· $ORACLE_HOME/dbs/init$ORACLE_SID.ora There are no special remarks to be noted with respect to a cluster system. However, the following parameters concerned with shared memory must be specified carefully. For details, refer to the Oracle manual. db_block_buffer

log_buffer

sort_area_size etc. · $ORACLE_HOME/network/admin/listener.ora

SynfinityCluster/HA for Oracle automatically starts and stops the listeners. If only one listener is required, such as in 1:1 standby, make settings according to the example for a single listener, as follows. If a listener is set up for each instance, as in N:1 standby or mutual standby, at least two listeners are required, so set up the system according to the example for two listeners. If there are more than two listeners, add the settings to the example for two listeners for the required number of listeners. (For multiple listeners, Host value and Port value must be specified individually for each listener.)

- Example of setting when there is a single listener (in 1:1 standby configuration) LISTENER=

(ADDRESS_LIST=

(ADDRESS=(PROTOCOL= IPC)(KEY=<instance name>))

(ADDRESS=(PROTOCOL= TCP)(Host=<logical IP address>)(Port=1521))

)

SID_LIST_LISTENER=

(SID_LIST=

(SID_DESC=

(GLOBAL_DBNAME=<optional name>)

(ORACLE_HOME=/opt/app/oracle/product/8.0.5)

(SID_NAME=<instance name>)

)

38

) - Example of setting when there are two listeners (in 2:1 standby configuration and mutual standby

configuration, and "1snr1" and "1snr2" are specified as the listener names) lsnr1=

(ADDRESS_LIST=

(ADDRESS=(PROTOCOL=IPC)(KEY=<instance name 1>))

(ADDRESS=(PROTOCOL=TCP)(Host=<logical IP address 1>)(Port=1521))

)

lsnr2 =

(ADDRESS_LIST=

(ADDRESS=(PROTOCOL= IPC)(KEY=<instance name 2>))

(ADDRESS=(PROTOCOL=TCP)(Host=<logical IP address 2>)(Port=1522))

)

SID_LIST_lsnr1=

(SID_LIST=

(SID_DESC=

(GLOBAL_DBNAME=<optional name 1>)

(ORACLE_HOME=/opt/app/oracle/product/8.0.5)

(SID_NAME=<instance name 2>)

)

)

SID_LIST_lsnr2 =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME= <optional name 2>)

(ORACLE_HOME= /opt/app/oracle/product/8.0.5)

(SID_NAME = <instance name 2>)

)

) · $ORACLE_HOME/network/admin/tnsnames.ora

Define aliases for connecting the failure monitor to Oracle for all Oracle instances to be used. If two listeners are required for N:1 standby or mutual standby, use different values for Host and Port. Aliases must be identical to the Oracle connection character string in the environment setting file.

- Example for a single listener (for 1:1 standby) <Alias definition> =

(DESCRIPTION =

(ADDRESS = (PROTOCOL= TCP)(Host= <logical IP address>)(Port= 1521))

(CONNECT_DATA = (SID = <instance name>))

)

- Example for two listeners (for 2:1 standby or mutual standby) <Alias definition 1>=

(DESCRIPTION =

(ADDRESS = (PROTOCOL= TCP)(Host= <logical IP address 1>)(Port= 1521))

39

(CONNECT_DATA = (SID = <instance name 1>))

)

<Alias definition 2> =

(DESCRIPTION =

(ADDRESS = (PROTOCOL= TCP)(Host= <logical IP address 2>)(Port= 1522))

(CONNECT_DATA = (SID = <instance name 2>))

)

Oracle data

The following Oracle resources must be located on a shared disk at the time of database creation. In addition, it is necessary that each node use shared data. · Oracle SYSTEM-Tablespace · Oracle REDO log file · Oracle CONTROL file · Oracle RollBackSegment-Tablespace · Oracle Temporary-Tablespace · Oracle user DATAFILE-Tablespace The following Oracle resources must be located in the local disk of each node. · $ORACLE_HOME/dbs/init$ORACLE_SID.ora : Oracle initialization parameter · $ORACLE_HOME : Oracle binary

Note 1: The Oracle resources above must be located in the local disk to improve the availability of maintenance and operation in case of a system failure. Note 2: For ORACLE HOME, setting must be done at the same time when the Oracle product is installed in each node. The setuid information will not be copied when a command such as "cp" is used to copy ORACLE HOME. If ORACLE HOME must be set up by copying such as with a "cp" command, execute "root.sh" after copying is completed for each node.

The Oracle resources that can be placed either in a shared disk or a local disk are as follows: · $ORACLE_HOME/network/admin/listener.ora,tnsnames.ora

Note: If the resources are located in a local disk, it is requisite that the same values are set for each node. · $ORACLE_HOME/precomp/demo/proc/makefile: Application compilation definition file · User data application in the server

Oracle operation confirmation

After completing the setup of the Oracle environment, start up the cluster service created in "SynfinityCluster operation confirmation." Then, start Oracle manually to confirm its operation. Confirm its operation on both active and standby nodes, separately.

Setting up the SynfinityCluster/HA for Oracle environment

Environment definition file of the Oracle failure monitoring monitor

The environment definition file of the Oracle failure monitoring monitor is /etc/opt/FJSVclora/FJSVclorafm.conf. Modify it using an editor (such as vi) if required.

The contents of the environment definition file must be the same on all nodes. If the contents of the environment definition file is modified on one node, the modification must be applied to the file on all nodes immediately.

Contents of the Environment definition file

The environment definition required to enable operation of Oracle failure monitoring monitor is as follows:

The following table is an example of settings when Oracle 8.0.5 is used.

40

· ORACLE_SID

Specify the Oracle instance that will be monitored (requisite).. · ORACLE connection character string

Specify the connection character string used when network connecting to the instance that will be monitored. Specify for this character string, the alias defined in the "tnsnames.ora" files. Since this character string is linked to ORACLE SID, it must be unique within the monitored database. Note: When a hyphen "-" is specified, Oracle instances are connected locally, not via a network. Note, however, that for the SynfinityCluster/HA for Oracle 1.0 series, local connection can be used only when the target Oracle instance is either Oracle 8.0.5 or Oracle 8.1.5.

· Monitoring interval Set up the monitoring interval in units of seconds. The default value is 60 seconds. If a hyphen "-" is specified here, the default value will be available.

· Restart count/initialization time Specify the number of times to execute restart when the monitor detects an error for which restarting of Oracle is required. The default value is three. Also, after you have restarted the system one or more times, specify the time that must elapse prior to the restart count being initialized in units of seconds (the default is "not initialized"). If you specify a hyphen "-", the default value is assumed. Specify a restart count and initialization time in "restart count/initialization" format. You can specify "Restart count/-", "-/initialization time", "-/-" and others. Also, if you specify only "restart count", actions without an initialization time are performed. Note that you cannot specify either "initialization time" or "/initialization time". Note: Failover will occur when the error cannot be avoided by restart execution for the specified times.

· Oracle user name Specify an Oracle user name (requisite).

· Node identifier in the active instance and ORACLE HOME Specify both the node identifier in the active instance and ORACLE HOME in the format "node-identifier: ORACLE HOME" (requisite).

· Node identifier in the standby instance and ORACLE HOME Specify both the node identifier in the standby instance and ORACLE HOME in the format "node-identifier: ORACLE HOME" (requisite).

· Listener name Specify the listener name corresponding to the ORACLE SID. The listener name can be omitted when there is only a single listener (in case it should be omitted, do not specify anything).

- A listener name must be specified for mutual standby operation or for N:1 standby operation. - When a listener name is specified, the specified listener will be started in each Oracle instance. - The user can specify multiple listener name. However, note that the listener that the failure monitoring

monitor uses to connect is the only first one. Although subsequent listeners are used to start/stop, the failure monitoring monitor does not access these listeners.

Timeout

SynfinityCluster/HA for Oracle does not execute timeout procedure while operating with Oracle instances.

Reason:

The failure monitoring monitor must be operated as one of the application of Oracle, so it must be avoided that the monitor handles signals which are prohibited by Oracle(handling signals causes much trouble). However, because the failure monitoring monitor uses Net8 of Oracle to enable connection to Oracle, the parameters related to timeout of Oracle itself will be available.

Example: TIMEOUT which will be available in the listener configuration file SQLNET_EXPIRE_TIME which is available in the initialization parameter

41

Example of the file format

Setting example 1 (when the listener name is omitted for 1:1 standby.)

orac FJSVclorafm.orac - - oracle node0:/opt/app/oracle/product/8.0.5 node2:/ora8/app/oracle/product/8.0.5

Setting example 2 (for 2:1 standby.)

orac FJSVclorafm.orac - - oracle node0:/opt/app/oracle/product/8.0.5 node2:/ora8/app/oracle/product/8.0.5 lsnr1

ora8 FJSVclorafm.ora8 - - oracle node1:/opt/app/oracle/product/8.0.5 node2:/ora8/app/oracle/product/8.0.5 lsnr2

Setting example 3 (for mutual standby.)

orac FJSVclorafm.orac - - oracle node0:/opt/app/oracle/product/8.0.5 node1:/ora8/app/oracle/product/8.0.5 lsnr1

ora8 FJSVclorafm.ora8 - - oracle node1:/opt/app/oracle/product/8.0.5 node0:/ora8/app/oracle/product/8.0.5 lsnr2

Setting example 4 (when the initialization time of restart count is 86400 seconds (24 hours) in 1:1 standby)

orac FJSVclorafm.orac - -/86400 oracle node0:/opt/app/oracle/product/8.0.5 node1:/ora8/app/oracle/product/8.0.5 lsnr1

Notes: 1. Use spaces or tabs to separate the fields.

Notes: 2. Insert a hyphen "-" in areas where values are omitted (except for the listener name).

Notes: 3. Enter carriage return at the end of line.

Registration and modification of environment definition files

If the environment definition file is modified, the following procedure for re-registering must be taken on each node: · Stop services, then delete the services on each node. · Delete the state transition procedures, then re-register them. · Redefine and restart the services. Password file of the Oracle failure monitoring monitor

The Oracle failure monitoring monitor uses the system user to connect to Oracle. By default the password of the system user is "manager", but it can be changed. When changing the password, use the editor (such as vi) to edit the "/etc/opt/FJSVclora/FJSVclorafm.pwd" file as follows: (When the default value is to be used as is for operation, you do not have to make these settings.) · Format

<Oracle-instance-name>:system/<password> · An example (An Oracle instance name: "orac", password of the system user: "admin")

orac:system/admin

Setting up cluster services and registering resources of the state transition procedure

Registering resources of the state transition procedure

Register the state transition procedure for switching Oracle instances using the "claddora" command provided by SynfinityCluster/HA for Oracle. · After editing "/etc/opt/FJSVclora/FJSVclorafm.conf" using an editor (such as vi) on one node, register the

resources of the state transition procedures for switching Oracle instances by "claddora" command. # /etc/opt/FJSVcluster/bin/claddora [ ORACLE_SID ] No argument specified: Register the resources so that all contents of the environment setting file (FJSVclorafm.conf) are used. Argument specified: Register the resources that correspond to ORACLE SID in the environment setting file (FJSVclorafm.conf). On the Web-Based Admin View, confirm that the procedure has been registered correctly.

· When the "claddora" command has been executed, the registered resource name will be displayed like "add <ORACLE_SID> resource." If the resource name is not displayed, check if the environment setting file is correct.

· If no resource is registered, the following message will be displayed: "No state transition procedure is registered" The node identifier in the environment setting file may be incorrect. Check the environment setting file.

· If a registration error is detected, delete all the state transition procedure for switching Oracle instances, then register procedures again. For details on deleting the procedure, see "Deleting state transition procedure resources".

· Copy /etc/opt/FJSVclora/FJSVclorafm.conf to the other node using a command such as ftp. · On the other node, register the resources of the state transition procedures by claddora command.

42

Setting up cluster services

Set up cluster services using the Web-Based Admin. For details, see "SynfinityCluster Installation/Administration Guide." · Select [Standby] as the cluster topology. · Select the resources of the state transition procedure defined above, the resources of the takeover IP address

(logical IP address), and the resources of the shared disk device as the resources that make up the cluster service.

· Select [Switched Disk] as the usage type of the shared disk device. · In standby, because only one cluster service can be defined, set all resources of the state transition procedure

for Oracle and resources of the shared disk device, resources of the takeover network (takeover IP) in one cluster service.

· In mutual standby, because two cluster services can be defined, make two groups including the resources of the state transition procedure for the Oracle instances, resources of the shared disk device, and resources of the takeover network (takeover IP), then set them in each cluster service.

· In N:1 standby, because multiple (three or more) cluster services can be defined, make multiple groups including the resources of the state transition procedure for the Oracle instances, resources of the shared disk device, and resources of the takeover network (takeover IP), then set them in each cluster service.

License registration

Register the license of SynfinityCluster/HA for Oracle before setting up the cluster service. For details about setting up the license, refer to "SynfinityCluster Installation/Administration Guide".

Deleting state transition procedure resources

After stopping or deleting a cluster service that includes resources of state transition procedures that will be deleted, execute the SynfinityCluster/HA for Oracle "cldelora" command on both the active and standby nodes.

# /etc/opt/FJSVcluster/bin/cldelora [ ORACLE_SID ]

No argument specified: All state transition procedure resources corresponding to the Oracle instance are deleted.

Argument specified: Only those state transition procedure resources corresponding to the argument are deleted.

If a SynfinityCluster/HA for Oracle package will be deleted with "pkgrm(1M)", the state transition procedure resources corresponding to the Oracle instance need to be deleted before the command is executed.

5.2.4 Operation

Special operations are not required in the operation of the cluster system. However, the instance functions distributed by Oracle cannot be used in standby node. SynfinityCluster/HA for Oracle supports standby, mutual standby, and N:1 standby systems as cluster topologies. · Standby and N:1 standby:

A standby or N:1 standby topology has one or more sets of an active node and a standby node. The Oracle client accesses Oracle in the active node. If a problem occurs in the active node, operation is switched to the standby node.

43

· Mutual standby:

Mutual standby topology is a node structure with two or more sets of an active instance and a standby instance. If a problem occurs in one of the nodes, processing is continued using the other node for which the problem has not occurred.

5.2.5 Operation at starting

On the active node, the Oracle resources are activated and cluster services are started to enable the operation. On the standby node, the Oracle is set to non-active state as standby to prepare for error occurrence (such as system failure) of the active node.

5.2.6 Operation at stopping

On the active node, the Oracle resources are deactivated and cluster services are stopped. On the standby node, no operation is performed.

5.2.7 Operation at switching

An error on the active node (such as a system failure) triggers activation of the Oracle resources on the standby node or starting the related cluster services, while the standby node goes into a state in which reconnection from the client system is enabled. These actions let the standby node take over the job that was being executed on the active node.

5.2.8 Performance

The tentative Oracle switching time for the minimum configuration is approximately at least one minute. Estimate the switching time by taking into account the database size, number of instances, usage, and time for database recovery after switching. For estimating the switching time for an entire job, take also issues such as the system startup time into consideration.

The SynfinityCluster environment may have to be changed depending on the estimated switching time. For the time interval to wait for completion of the state transition procedure and the time interval to wait for a state transition

44

request, specify values that exceed the estimations. Refer to "SynfinityCluster Installation/Administration Guide".

5.2.9 Stopping Oracle during cluster operation

If Oracle stops during SynfinityCluster operation, the system assumes the occurrence of an error and switches operation to the standby node. SynfinityCluster/HA for Oracle monitors all Oracle errors. When maintenance such as Oracle cold backup is to be performed, execute it after interruping Oracle error monitoring as explained below. For details on the commands to be used in each phase, refer to the sample scripts. · Determining the resource ID of the active Oracle resource.

Using Web-Based View or the clgettree command, a SynfinityCluster control command, or other similar command, determine the resource ID of the Oracle resource that controls the operation of the Oracle to be stopped.

· Stop process monitoring for the resource ID. Using the clmonproc command, a control command of SynfinityCluster, stop the process monitoring for the above resource ID.

· Stop Oracle. · Perform maintenance.

Perform maintenance such as Oracle cold backup. · Start Oracle.

Restart Oracle. · Restart the process monitoring for the resource ID.

Use clmonproc, a SynfinityCluster control command, to restart process monitoring.

Restart of monitoring

After you have completed the necessary maintenance, you must start Oracle to restart Oracle error monitoring.

State transition while maintenance is being performed

While Oracle error monitoring is stopped, state transition does not occur even if an error occurs in Oracle. However, care is required because a state transition may occur due to a factor that is not related to Oracle, such as a disk error.

State of cluster service while maintenance is being performed

When this procedure is taken to stop Oracle, the active state of the cluster service cannot be changed on the Web-Based Admin View of SynfinityCluster.

Sample script

#!/bin/sh

# Set up ORACLE_HOME and ORACLE_SID.

ORACLE_HOME=/opt/app/oracle/product/8.0.5

ORACLE_SID=ora805

export ORACLE_HOME ORACLE_SID

# Acquire the resource ID of the active Oracle resource.

RID=`/etc/opt/FJSVcluster/bin/clgettree -s | grep $ORACLE_SID | grep -v INACTIVE | cut -f2 -d' '`

# Stop process monitoring.

/etc/opt/FJSVcluster/bin/clmonproc -k -e -r $RID

# Stop Oracle.

# Reference:

# FJSVclorafm.dbshut placed under /opt/FJSVclora/sys/

# indicates a script to stop with abort. Refer to it as required.

# Startup option specified an Oracle user name.

45

# (Execution user name is oracle.)

# # FJSVclorafm.dbshut oracle

#

# (Do not change FJSVclorafm.dbshut directly.)

# Backup work and others

# Oracle startup (Execution user name is oracle.)

/opt/FJSVclora/sys/FJSVclorafm.dbstart oracle > /dev/null

# Process monitoring start

/etc/opt/FJSVcluster/bin/clmonproc -s -r $RID -a "/opt/FJSVclora/sys/FJSVclorafm -l $RID"

5.3 Troubleshooting:

5.3.1 Solving a problem that occurs upon switching

Errors detected by SynfinityCluster/HA for Oracle and the treatment methods of the errors are described in "/var/opt/FJSVclora/FJSVclorafm $ORACLE_SID.log". To solve problems, refer to this error log information and history outputs by Oracle. (The $ORACLE_SID must be replaced by the value specified in ORACLE_SID.)

5.3.2 Troubleshooting

Cannot register resources with the claddora command. · Confirm that the format of the environment definition file (FJSVclorafm.conf) does not contain any errors. Refer

to "Example of the file format" in "SynfinityCluster/HA for Oracle Environment Setting." · Confirm that the node identifier of the environment definition file (FJSVclorafm.conf) is the same as that set up

in SynfinityCluster.

Cluster service cannot be started normally. · Confirm whether the cluster service includes resources of the shared disk device, resources of takeover Ips, or

resources of SynfinityCluster/HA for Oracle. · Confirm whether the shared disk device can be accessed. · Confirm that the format of the environment definition file (FJSVclorafm.conf) contains no errors. Refer to

"Example of the file format" in "SynfinityCluster/HA for Oracle Environment Setting." · Confirm that ORACLE_SID, Oracle user name, and ORACLE_HOME of the environment definition file

(FJSVclorafm.conf) contain no errors. · Confirm that the connection character string of the environment definition file (FJSVclorafm.conf) is identical to

the definition of the tnsnames.ora file. · Confirm that the listener name of the environment definition file (FJSVclorafm.conf) is identical to the definition

of the listener.ora file. · Start the cluster service from which the resources of SynfinityCluster/HA for Oracle have been removed to

confirm whether Oracle can be started manually.

The cluster service does not operate normally in the standby instance. · Refer to "Setting up the Oracle environment" in "Procedure in environment setup" and confirm that the settings

have been made correctly for the standby node instance. · Confirm that all database resources are included in the shared disk device. · Confirm that the user name and user ID for which Oracle is installed are identical with the active node. · Confirm that the settings of tnsnames.ora and listener.ora are identical to those of the active node. · Start the cluster service from the resources of SynfinityCluster/HA for Oracle and confirm whether Oracle can

be started manually.

Cannot connect from the client. · Confirm that the listener has started up on the service instance. · Confirm that a logical ID address is being used for the listener.ora file of the server and the tnsnames.ora file

of the client system.

The config$ORACLE_SID.ora file does not exist. · The $ORACLE_BASE/admin/$ORACLE_SID/pfile/config$ORACLE_SID.ora file is created when a database is

created with Oracle installer. Note that the config$ORACLE_SID.ora file is not needed when the init$ORACLE_SID.ora file is created manually.

46

Error monitoring monitor causes a memory leak. · Open the $ORACLE_HOME/network/admin/tnsnames.ora file with vi editor and add a line feed code to the

last column. A tnsnames.ora file that is created at installation may not terminate with a line feed code because Solaris or Oracle loops infinitely.

5.3.3 Collecting Troubleshooting Information

If a problems cannot be solved for some reason, collect the following information and contact your Fujitsu systems engineer (SE). · Setup file

/etc/opt/FJSVclora/* $ORACLE_HOME/network/admin/*.ora $ORACLE_HOME/dbs/*.ora $ORACLE_HOME/../../admin/$ORACLE_SID/pfile/*.ora

· Log file /var/opt/FJSVclora/FJSVclora_$ORACLE_SID.log $ORACLE_HOME/rdbms/log/alert_$ORACLE_SID.log $ORACLE_HOME/../../admin/$ORACLE_SID/bdump/alert_$ORACLE_SID.log $ORACLE_HOME/network/log/<listener>.log

· Cluster information Information collected with the SynfinityCluster investigative material collection command. For details on the SynfinityCluster investigation material collection command, refer to the "SynfinityCluster Installation/Administration Guide" and related material.

5.4 (Reference) Action definition file

The Oracle error number, error contents, and the treatment methods of the errors are included in the action definition file. · Action definition file name and directory name

/etc/opt/FJSVclora/FJSVclorafm.actionlist · Changing the action definition file

The action definition file need not to be corrected. Operation is unpredictable if the action definition file is modified.

· File format The format of the action definition file is described in the following order: Oracle error number, monitor status, action definition, error description 18 Cn Fo "maximum number of sessions exceeded" (CR) 20 Cn Np "maximum number of processes (%s) exceeded" (CR) -- 9950 All Fo "Unable to get server operating system privileges" (CR) (end-of-file)

· Monitor status (operating status)

· Actions

NOP error

Even when the action to be taken for an error is NOP, terminate the error monitoring monitor with the error monitoring monitor because subsequent processing cannot be continued if FETCH or UPDATE of the SQL command is detected.

47

5.5 Notes

This section provides notes to SynfinityCluster/HA for Oracle.

Restrictions

· Restrictions for using ORACLE_SID as a resource key are as follows: Duplicate resource keys (same ORACLE_SID) cannot be specified in a single node. It must be described with only ASCII capital characters, non-capital characters, numeric characters, hyphen "-", underline "_", period ".", slash "/", and colon ":". The initial character must be an ASCII capital character, non-capital character, or a numeric character.

· The Oracle database must be arranged on a shared disk. Oracle V8 or later are supported. Other versions or levels or mixture of them are not supported.For details of the names and model numbers of supported products, refer to the "Installation Guide."

· The user name and user ID used to install Oracle must be the same for each node. · If the environment definition file (FJSVclorafm.conf) is modified, copy it to all nodes immediately. Operation will

not be predictable if different environment definition files are set up for each node. · Host name and IP address restrictions

Oracle uses the following files to set up the Network environment definitions. However, to use these files under a SynfinityCluster/HA for Oracle environment, all items related to the host names and IP addresses must be specified as corresponding to the logical IP address(example: 11.222.33.44) that is taken over or the logical IP address defined in "/etc/hosts". Server environment "*.ora" files under the "$ORACLE_HOME/network/admin" cman.ora, snmp_ro.ora, sqlnet.ora listener.ora, snmp_rw.ora, tnsnames.ora client environment tnsnames.ora

If a physical address or host name corresponding to them are specified, a connection error will occur at the time of node switching.

Notes:

· The SQL execution target area on which the failure monitoring monitor detects errors, uses the default table area of the SYSTEM user on the database.

· SynfinityCluster/HA for Oracle stops the Oracle instance with a shutdown abort. By stopping with a shutdown abort, Oracle performs automatic recovery when Oracle is next restarted.

· Listener monitoring is actualized by reconnecting to Oracle. Specify a connection character string in the environment definition file FJSVclorafm.conf to connect Oracle via Net8. Listener monitoring is not done with the "monitoring interval" specified in the environment definition file FJSVclorafm.conf but is instead performed once a day after Oracle is reconnected.

· Output destination of the ORACLE archive log file Although resources related to Oracle are assumed to be located on a shared disk device, it is possible to locate the archive log file used in recovery procedure (application of the REDO file) after failures (such as an Oracle crash) on a local disk considering the file size. In such cases, if recovery of Oracle occurs due to a crash, it is expected that the Oracle archive files on the nodes of both systems will be joined and recovery started.

48

Part 2 SynfinityCluster-related Products

49

Chapter 6 Oracle Parallel Server for SynfinityCluster


Oracle database systems implement efficient, highly reliable and safe data administration for online transaction processing (OLTP), as well as inquiry-intensive data warehousing applications. They also satisfy the rigorous availability and scalability conditions demanded by today's mission-critical applications.

6.1.1 Application to a Cluster System

Oracle Parallel Server for SynfinityCluster is offered as an option for Oracle 8i Enterprise Edition. This product improves the availability and expandability, and offers performance at a more advanced level in cluster systems by enabling the execution of multiple Oracle instances in each node of a cluster while enabling access to the same database.

Oracle hot standby operation is supported by combining the Oracle8i 8.1.6 Primary/Secondary instance function with a cluster service. Standby class operation enables swift switching to the standby node when an error occurs in the hardware or software so that a database job can be continued.

By distributing jobs to multiple servers or by parallel processing when the number of users increases or the business scale expands, a major improvement in scalable processing performance, which is not possible with a single server, can be guranteed. Operation in a scalable class actualizes an improvement in performance through database parallel processing as well as through high availability by job continuation with existing nodes upon the occurrence of an error.


Set up a standby class for hot standby operation and a scalable class for parallel operation. For details, refer to "Table of support format".

6.2 Standby classes

The following explains the standby class:1:1 standby, N:1 standby, and two-node mutual standby.

6.2.1 System Configuration


51


Identical to a single instance environment in terms of its functions and can be used transparently as a single database system. Other than changing the client connection character string, the applications need not be changed.

For hot standby operation, use the Oracle Parallel Server Primary/Secondary instance function. The primary instance starts up for the active nodes, while the Secondary instance starts up for the standby nodes. User connection is performed only with the Primary instance, while the Secondary instance accepts a connection only when an error occurs in the operation node.

Even when the Primary/Secondary instance function is effective, the database administrator can perform connection to the Secondary instance. This enables the activation of the standby node Oracle instance.

If an error occurs in the active node, the secondary instance that has already started detects an error and performs recovery transparently so that database system can be switched to swift operation mode without any database system interruption. Client applications can continue their jobs by connecting again.

By using Oracle's transparent application failover (TAF) function, the client application automatically connects to the secondary instance again so that the database job can continue. For details on transparent application failover, refer to "Oracle8i Parallel Server Overview" and "Oracle8i Net8 Administrator Guide."


You are required to register the database resource of Oracle Parallel Server for SynfinityCluster in the cluster system as a resource and set up the cluster service to be operated. The prequisites for environment setting and the procedure for resource registration are explained below:

6.2.3.1 Prequisites

Logical IP setup

Set up the takeover network on the cluster management view. For details on the Logical IP takeover settings, refer to "SynfinityCluster Installation/Administration Guide."

Raw Device Creation

Create the raw devices to be used for the Oracle database data files, REDO log files, and control files on the shared disk device.

Oracle installation and database creation

Install Oracle and Oracle Parallel Server for SynfinityCluster and then create the Oracle database. For details on the installation and database creation, refer to the Oracle manuals.

Oracle initialization file setting

Assign Oracle initialization file (init$ORACLE_SID.ora) to $ORACLE_HOME/dbs. As the fixed setting for the cluster service, describe the following parameters in the initialization file of each node:

active_instance_count=1

local_listener=service_listener

service_names=<Service name (specify with database name.domain name) >

instance_name=<instance name>

Oracle network setting on the server side

Oracle Listener is available in two types, that is, the Primary Listener for which a logical IP is used and the Secondary Listener for which a host name (physical IP) is used. Add the following description to the listener.ora and the tnsnames.ora files that can be found under the $ORACLE_HOME/network/admin of each node. Be careful not to duplicate the Port number with other settings.

listener.ora file

primary =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS_LIST =

52

(ADDRESS = (PROTOCOL = TCP) (HOST = <Logical IP address>) (PORT = 1526) )

)

)

)

secondary =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = <Local host name>) (PORT = 1527) )

)

)

)

SID_LIST_secondary =

(SID_LIST =

(SID_DESC =

(ORACLE_HOME = <ORACLE_HOME>)

(SID_NAME = <ORACLE_SID>)

)

)

tnsnames.ora file

service_listener =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = <Logical IP address>) (PORT = 1526) )


)

)

Oracle network setting on the client side

Specify a connection character string so that the client can connect to the primary instance. Add descriptions to the tnsnames.ora file under $ORACLE_HOME/network/admin of each client, referring to the following setting examples:

tnsnames.ora file example 1 (used by the Primary Listener only, and not by TAF)


(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = <logical IP address>) (PORT = 1526) )

)

(CONNECT_DATA =

(SERVICE_NAME = <Service name>)

)

)

tnsnames.ora file example 2 (used by the Secondary Listener only, and not by TAF)


53

(DESCRIPTION =

(ADDRESS_LIST =

(LOAD_BALANCE=off)

(ADDRESS = (PROTOCOL = TCP) (HOST = <Host name of the active node>) (PORT = 1527) )

(ADDRESS = (PROTOCOL = TCP) (HOST = <Host name of the standby node>) (PORT = 1527) )

)

(CONNECT_DATA =


)

)

tnsnames.ora file example 3 (used by TAF)


(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = <logical IP address>) (PORT = 1526) )

)

(CONNECT_DATA =


(FAILOVER_MODE = (BACKUP = <Alias definition for backup>)

(TYPE = session) (METHOD = basic) (RETRIES = 180) (DELAY = 5) )

)

)

<Alias definition for backup> =

(DESCRIPTION =

(ADDRESS_LIST =


(ADDRESS = (PROTOCOL = TCP) (HOST = <Host name of the active node>) (PORT = 1527) )

)

(CONNECT_DATA =


(FAILOVER_MODE = (BACKUP = <Alias definition 3>)

(TYPE = session) (METHOD = basic) (RETRIES = 180) (DELAY = 5) )

)

)

When the database administration is to make the network connection to the Secondary instance, specify the following connection character strings. Add descriptions to the tnsnames.ora file under $ORACLE_HOME/network/admin of each client, referring to the following setting examples:

tnsnames.ora file example 4 (connected to the Secondary instance)

<Alias definition > =

(DESCRIPTION =

(ADDRESS_LIST =


)

54

(CONNECT_DATA =

(SERVICE_NAME = <ORACLE_SID of the standby node>)

)

)

6.2.3.2 Resource registration procedure

Registering the state transition procedure resource

Register the state transition procedure resources that are relevant to the Oracle instance and Oracle Listener by using the clorasvr command and the cloralsnr command, provided by Oracle Parallel Server for SynfinityCluster.

Each command is placed under $ORACLE_HOME/bin and can be executed only by the system administrator. The usage of the commands is as follows:

# clorasvr -a <database name> [ -n <Node name> ] -o <owner of Oracle>

-s <ORACLE_SID> -h <ORACLE_HOME>

# cloralsnr -a <Listener name> [ -n <Node name> ] -o <owner of Oracle>

-h <ORACLE_HOME> [ -p ]

Explanation of the arguments: · database name

Used to specify an Oracle database. · Listener name

Used to specify an Oracle Listener as defined with the Listener.ora file. · Node name

Used to specify a node name that creates a resource. If this item is omitted, a resource is created on the node on which commands are executed.

· Oracle owner Used to specify an Oracle owner. In general, the UNIX user name used for Oracle installation is used as the Oracle user.

· ORACLE_SID Used to specify the Oracle identifier (ORACLE_SID) of the Oracle instance.

· ORACLE_HOME Used to specify ORACLE_HOME in which Oracle instance and Oracle Listener are installed.

· Primary specification (only for Oracle Listener) If the logical IP is used for the Oracle Listener network setting, specify the "-p" option.

Example of settings for the state transition procedure resource

Information on the resource to be registered

database name:ops

Oracle ownner name: oracle

Active node (node0) setting:

Oracle instance (ORACLE_SID=ops1, ORACLE_HOME=/opt/app/oracle/product/8.1.6)

Oracle Listener (Primary Listener name:primary, Secondary Listener name:secondary)

Standby node (node1) setting:


Oracle Listener (Primary Listener name:primary, Secondary Listener name:secondary)

Oracle instance and Oracle Listener registration

# clorasvr -a ops -n node0 -o oracle -s ops1 -h /opt/app/oracle/product/8.1.6


# cloralsnr -a primary -n node0 -o oracle -h /opt/app/oracle/product/8.1.6 -p

# cloralsnr -a primary -n node1 -o oracle -h /opt/app/oracle/product/8.1.6 -p

# cloralsnr -a secondary -n node0 -o oracle -h /opt/app/oracle/product/8.1.6

# cloralsnr -a secondary -n node1 -o oracle -h /opt/app/oracle/product/8.1.6

55

Changing the state transition procedure resource

If you make any changes to the registered information, delete the state transition procedure resource, and then register it again.

After stopping and deleting the cluster service that includes the state transition procedure resource to be deleted, execute the clorasvr or cloralsnr command with the "-d" option specified. The usage of the command is shown below. For an explanation of the arguments, see "Registering the state transition procedure resource":

# clorasvr -d <database name> [ -n <Node name> ]

# cloralsnr -d <Listener name> [ -n <Node name> ]

Confirming the state transition procedure resource

To confirm the registered state transition procedure resource, execute the clorasvr or cloralsnr command with the "-l" option specified. The usage of the command is shown below. For an explanation of the arguments, see "Registering the state transition procedure resource":

# clorasvr -l [ <database name> ]

# cloralsnr -l [ <Listener name> ]


Use the cluster management view to register cluster services. For details, see the "SynfinityCluster Installation/Administration Guide." · Select [Standby] as the cluster topology. · As the resources constituting the cluster service, select the logical IP address resource, the resource of the

shared disk device to be used as the Oracle database, Oracle instance resource, Primary Listener resource, and Secondary Listener resource.

· If the cluster service consists of multiple disks, group setting is required. Specify the resources of the shared disk device to be set up as one group.

· Select "Shared disk for simultaneous access" as the device type of the shared disk device. Do not check "Failover at error occurrence in the disk."

6.2.4 Operation

In cluster system operation, the registered state transition procedure is executed if the status of the resource used by the cluster service changes or if the operator requests state transition. The procedure handles the activation and deactivation of the Oracle database resources.

The Oracle instance and the Oracle Listener state transition procedure are registered when Oracle Parallel Server for SafeCLUSTER is installed and starts up automatically at cluster service startup or at state transition.


On the active node, Oracle instances, Primary Listener and Secondary Listener are activated and jobs are started as the primary instance. On the standby node, Oracle instances start as secondary instances to prepare for possible errors on the active node. Secondary Listener also starts on a standby node to provide an administrator's connection to the secondary instance and for TAF failover.


On the active node, the Oracle instances, Primary Listener and Secondary Listener are stopped, as are all jobs. On the standby node, the Oracle instances and Secondary Listener are stopped.

6.2.7 Operation at Switchover

An error on an active node (such as a system failure) triggers switching of the Oracle instance property from Secondary instance to Primary instance and activates Primary Listener. By means of this processing, jobs executed in the active node are taken over.

6.2.8 Actions for Node Extension

For a configuration exceeding two nodes, scalable operation is required. After deleting a defined standby service and the resources defined with Oracle Parallel Server for SynfinityCluster, set up the scalable service.

6.2.9 Performance

Since hot standby status can be maintained on the standby server, switching can be performed in only a few seconds

56

with the minimum configuration. To estimate the switching time for an entire job, you should also consider issues such as database recovery time at switching.

6.2.10 Notes

· Database start/stop is performed without using the cluster service /var/opt/oracle/oratab setting. · Connection to the secondary instance can be established with a local connection by logging on to the server.

To connect to the secondary instance from the client, you must change the Oracle network configuration. For details on the connection to the secondary instance, see the "Oracle8i Parallel Server Setup and Configuration Guide."

· Connection to a secondary instance is limited to the purposes of administrator tasks and report creation by the database administrator. To perform other database jobs, consider installing scalable operation.

· Some restrictions are imposed on transparent application failover (TAF). For details on these restrictions, refer to the "Oracle8i Parallel Server Overview."

6.3 Scalable classes

Scalable class provides scalable operation in multiple nodes.


[Example system configuration for a single hierarchic scalable]


To access the same data from multiple nodes, overhead due to competition between nodes occurs more often compared with access from a single server. With appropriate application and data divisions at data system design, a parallel database can be used effectively.

If an error occurs in a node, the Oracle instance existing on other nodes is used for error detection and transparent error recovery, such that degeneration can be performed without database system interruption. Client applications can continue by performing reconnection.


You must register the database resources of Oracle Parallel Server for SynfinityCluster to the cluster systems as resources in order to set up the cluster service. Prerequisites for environment setting and the procedure for resources registration are described below:

57

6.3.3.1 Prerequisites

Raw Device Creation

Create the Oracle database data file, REDO log file, and raw device to be used as the control file on a shared disk.

Oracle installation and database creation

Install Oracle and Oracle Parallel Server for SynfinityCluster and create an Oracle database. For details on the installation and database creation, refer to the Oracle manuals.

Oracle initialization file setting

Assign the Oracle initialization file (init$ORACLE_SID.ora) to $ORACLE_HOME/dbs. As the fixed setting for the cluster service, describe the following parameters in the initialization file of each node:

local_listener=service_listener

service_names=<Service name (specify with database name.domain name) >

instance_name=<instance name>

Oracle network setting on the server side

Oracle Listener prepares only the Listener for which a host name (physical IP) is used. Add the following description to listener.ora and the tnsnames.ora file that are located under $ORACLE_HOME/network/admin on each node. Be careful to ensure that the Listener name and Port number do not duplicate any other settings.

listener.ora file

listener =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS_LIST =


)

)

)

tnsnames.ora file

service_listener =

(DESCRIPTION =

(ADDRESS_LIST =


)

)

Oracle network setting on the client side

Specify the connection character string so that the client can connect to the instance. Add descriptions to the tnsnames.ora file placed under $ORACLE_HOME/network/admin of each client, referring to the following setting examples:

tnsnames.ora file example (using the load balance function)


(DESCRIPTION =

(ADDRESS_LIST =

(LOAD_BALANCE=on)

(ADDRESS = (PROTOCOL = TCP) (HOST = <Host name of node 0>) (PORT = 1527) )

58

(ADDRESS = (PROTOCOL = TCP) (HOST = <Host name of node 1>) (PORT = 1527) )

)

(CONNECT_DATA =


)

)

6.3.3.2 Resource registration procedure

Registering the state transition procedure resource

Register the state transition procedure resources that are relevant to the Oracle instance and Oracle Listener by using the clorasvr command the the cloralsnr command of Oracle Parallel Server for SynfinityCluster.

Each command is placed under $ORACLE_HOME/bin and can be executed only by the super user. The usage of the commands is shown below:

# clorasvr -a <database name> [ -n <Node name> ] -o <Oracle owner>

-s <ORACLE_SID> -h <ORACLE_HOME>

# cloralsnr -a <Listener name> [ -n <Node name> ] -o <Oracle owner>

-h <ORACLE_HOME>

Explanation of the argument: · database name

Used to specify a Oracle database name. · Listener name

Used to specify an Oracle Listener defined with the Listener.ora file. · Node name

Used to specify a node name that creates a resource. If omitted, a resource is created on the node on which commands are executed.

· Oracle owner Used to specify an Oracle owner. In general, a UNIX user name used for Oracle installation is used as the Oracle user.

· ORACLE_SID Used to specify the Oracle identifier (ORACLE_SID) of the Oracle instance.

· ORACLE_HOME Used to specify ORACLE_HOME where Oracle instance and Oracle Listener are installed.

Example of setting the state transition procedure resource

Information on the resource to be registered

Database name:ops

Oracle ownner name: oracle



Oracle Listener (Listener name:listener)


Oracle interface (ORACLE_SID=ops2, ORACLE_HOME=/opt/app/oracle/product/8.1.6)

Oracle Listener (Listener name:listener)

Oracle instance and Oracle Listener registration



# cloralsnr -a listener -n node0 -o oracle -h /opt/app/oracle/product/8.1.6

# cloralsnr -a listener -n node1 -o oracle -h /opt/app/oracle/product/8.1.6

59

Changing the state transition procedure resource

If a change is made to the registered information, delete the state transition procedure resource and then register it again.

After stopping and deleting the cluster service that includes the state transition procedure resource to be deleted, execute the clorasvr or cloralsnr command with the "-d" option specified. How to use the command is shown below. For an explanation of the arguments, refer to "Registering the state transition procedure resource":

# clorasvr -d <Database name> [ -n <Node name> ]

# cloralsnr -d <Listener name> [ -n <Node name> ]

Confirming the state transition procedure resource

To confirm the registered state transition procedure resource, execute the clorasvr or cloralsnr command with the "-l" option specified. How to use the command is shown below. For an explanation of the arguments, refer to "Registering the state transition procedure resource":

# clorasvr -l [ <Database name> ]

# cloralsnr -l [ <Listener name> ]


Use the cluster management view to register cluster services. For details, see the "SynfinityCluster Installation/Administration Guide." · Select [Scalable] as the cluster topology. · As the resources constituting the cluster service, select the resource of the shared disk device to be used as

the Oracle database, Oracle instance resource, and Oracle Listener resource. · If the cluster service consists of multiple disks, group setting is required. Specify the resources of the shared

disk device to be set up as one group. Do not check "Failover at error occurrence in the disk."

6.3.4 Operation

In cluster system operation, the registered state transition procedure is executed if the status of the resource used by the cluster service changes, or if the operator requests state transition. The procedure handles the activation and deactivation of the Oracle database resources.

The Oracle instance and the Oracle Listener state transition procedure are registered when Oracle Parallel Server for SafeCLUSTER is installed and start automatically at cluster service startup or at state transition.


Oracle instances and Oracle listeners are activated and jobs are started.


Oracle instances and Oracle listeners are stopped and the jobs are stopped.

6.3.7 Degenerate Operation

When an error occurs on an active node (such as a system failure), Oracle Parallel Server is reconfigured with available active nodes, and job takeover is performed.

During this degenerated operation, jobs that should be performed with nodes that have failed are assigned to the available nodes. This requires careful estimation of the resource requirements.

6.3.8 Actions for Node Extension

Make the environment settings for Oracle Parallel Server for SynfinityCluster using extended nodes to add them to the service configuration and to set up resources.

6.3.9 Performance

To perform job takeover for other available active nodes, switching performance that is identical to hot standby can be realized. To estimatethe switching time for an entire job, also consider issues such as the database recovery time at switching.

With parallel database processing, an improvement in performance can be expected in proportion to the increase in the number of servers added.

60

6.3.10 Notes

The setting made for /var/opt/oracle/oratab cannot be used because database start/stop is performed with the cluster service.

61

Chapter 7 SymfoWARE Server Hot Standby Option


SymfoWARE is a database system that features high performance query and loading, efficient maintenance and safety of large masses of data, and highly reliable operation and can be applied even to mission-critical operation fields. SymfoWARE uses open system platforms to realize mainframe-level high performance and high throughput. The system features full support of network computing technologies that allow information linking by multiple servers and system use from various types of clients. It can also flexibly accommodate future operation expansions.


The SymfoWARE Server Hot Standby Option provides a hot standby function for the SymfoWARE Server relational database. This option ensures quick recovery from a system stoppage caused by exceptional events in hardware and software. If a failure occurs in a server, this option, which operates on a cluster system, switches to another server at high speed to continue operation. The client can continue the job by reconnecting, thereby minimizing lost job time.

SymfoWARE supports both standby and mutual standby systems.


For details, see "Table of support format."

7.2 Standby class

The following are the standby class:1:1 standby, N:1 standby, and two-node mutual standby.

7.2.1 System Configurations

Standby system configuration

The standby system configuration is as follows.

Mutual Standby Nodes

The mutual standby system configuration is as follows.

63


To achieve a highly reliable, highly available hot standby system, the system design should be based on the following points:

File Replication

To avoid shutdowns of application programs or both-system failure caused by a hardware failure, use a disk array unit to duplicate the files on the shared disk device or use SynfinityDisk to mirror the files.

Concept of failover

Pre-open the database for the fixed jobs having a fixed database environment where the resources are neither changed nor deleted. Because the database is not opened after failover if it is pre-opened, the failover time can be shortened.

However, in a non-fixed database environment, the definition is changed during jobs by changing and deleting DSI, deleting the database containing DSI, or deleting the database space specified for the allocation destination of expanded area of automatic expansion of DSI. In this environment, the database cannot be pre-opened. Instead, after the standby instance is switched to active mode, the database is automatically opened.

64


The system administrator must register the RDB system as a cluster system resource and specify the RDB system resource in the cluster service that performs the operation.

For more information, refer to the "SynfinityCluster Installation/Administration Guide" or "SymfoWARE Server Hot Standby Option Handbook".

7.2.4 Operations

In cluster system operation, the registered state transition procedure is executed if the status of the interfaces used by the cluster service changes or if the operator instructs state transition. The procedure handles the activation and deactivation of the SymfoWARE database resources.

The state transition procedure for SymfoWARE is registered automatically when the software is installed, and the procedure starts automatically when a cluster service is started or a state transition occurs.


On the active node, SymfoWARE/RDB and SymfoWARE/RDA-SV are activated and jobs are started. In the standby node, SymfoWARE/RDB is started in standby mode and is prepared in case an error (for example, system failure) occurs in the active node.


On the active node, SymfoWARE/RDB and SymfoWARE/RDA-SV are stopped and the jobs are stopped. In the standby node, SymfoWARE/RDB is stopped.

7.2.7 Operation at Switching

An error on the active node (such as a system failure) triggers switching the SymfoWARE/RDB property from standby mode to active mode and activating SymfoWARE/RDA-SV. These actions enable the standby node to take over the job that was being executed on the active node.

7.2.8 Performance

On the standby server, the SymfoWARE relational database can be placed in active state, and it is possible to switch the server in several minutes.

65

Chapter 8 SynfinityFile/Global


The SynfinityFile/Global software creates file systems on storage within a storage area network (SAN) environment and provides functions for accessing the file systems directly and concurrently from multiple UNIX systems.

SynfinityFile/Global has API compatibility with the standard UNIX file systems UFS and SynfinityFile, and it also automatically maintains data consistency when there are concurrent data references/updates from multiple UNIX systems. This feature enables SynfinityFile/Global to transfer data to and from applications that use older APIs in an environment containing distributed applications on multiple UNIX systems. This product also realizes high-speed access because it accesses the storage directly for reading/writing file data instead of going through a LAN.

In addition, SynfinityFile/Global provides high operability through a function that consolidates multiple volumes into one file system, an area expansion function that can be used when a storage area is depleted, and GUI-based file system operations.

SynfinityFile/Global is the optimal file system for a SAN environment because it combines advanced, simultaneous and direct sharing and high operability.

8.1.1 Application to a Cluster System

SynfinityFile/Global is intended for scalable operation.

SynfinityFile/Global can create a file system on shared disks in a cluster environment, support scalable operation, and allow concurrent accesses to the file system from multiple servers.

Even if one server is down, SynfinityFile/Global realizes a high-availability system that allows accesses from other servers to continue.

8.1.2 Support Formats

For details, see "Table of support format"

8.2 Scalable classes


SynfinityFile/Global operates with scalable classes. The system configuration for scalable operation is shown below.

[System Configuration]


A SynfinityFile/Global file system must be registered as a resource to the cluster system and specified in the cluster services that perform operations on it.

67

68

For details, see "Examples of Scalable Operation Installations (SynfinityFile/Global)" or the "SynfinityFile/Global Guide."

8.2.3 Operations

In cluster system operation, mounting and unmounting of the SynfinityFile/Global file system are performed according to state changes in the interfaces that make up the cluster services, operator-initiated state transition events and the registered state transition procedure.

The state transition procedure of SynfinityFile/Global is registered automatically when the product is installed. Mounting and unmounting are started automatically when the cluster services are started or when state transition occurs.

8.2.4 Degenerate Operation

This product guarantees access to the file system from all nodes except the active node in which the failure occurred.

8.2.5 Performance

SynfinityFile/Global realizes high-speed data access because multiple servers access the shared disks directly instead of through a network.

SynfinityFile/Global also reduces the network load of the overall system because file accesses are performed directly to the disk instead of through a network.

Part 3 Example of Installing SynfinityCluster Products

This section explains the operations needed to start up a SynfinityCluster system, taking SymfoWARE and SynfinityFile/Global as examples.

69

Chapter 9 Installation Example1:1 Standby(SymfoWARE)

Taking SymfoWARE as an example, this chapter explains the environment creation and operation preparation that are necessary for hot standby for SymfoWARE. · Environment Setup Procedure for Hot standby system · Preparations Before Environment Setup · SymfoWARE Environment Setup · Cluster System Environment

9.1 Environment Setting Procedures for Hot Standby Operation

Shown below is a setup procedure for hot standby system

During hot standby system, the status transition procedure automatically executes operations such as RDB startup.

[Procedures of SymfoWARE]

"Raw device creation," "RDB configuration parameter file editing," "Parameter file editing," "Operation environment file editing," "Environment variable setup," "RDB environment creation," and "Hot standby declaration" (items enclosed in bold lines in the SymfoWARE environment setup procedure) are explained in "Environment setting for SymfoWARE".

"RDB resource registration," "RDB cluster service registration," and "Starting a cluster service" (items enclosed in bold lines in the environement setting of the cluster system) are explained in detail i.n "Environment setting for the cluster system"

All other operations are performed in the same way as when hot standby system is not executed.

· For details on kernel editing, refer to the "SymfoWARE Server RDB Operations Guide." · For details on other operations, refer to the "SymfoWARE Server Start Guide: Server" and other manuals.

71

9.2 Preparatory procedures before environment setting

Before setting up the SymfoWARE environment, perform all operations from SynfinityCluster installation to cluster initial configuration setup.

For details on the operations from SynfinityCluster installation to cluster initial configuration setup, refer to the "SynfinityCluster Installation/Administration Guide."

9.3 Environment setting for SymfoWARE

This section explains the SymfoWARE environment setup.

9.3.1 Creating raw devices

Create the raw device to be used by SymfoWARE/RDB in a shared disk.

For instructions on setting the disk partition when a shared disk is used as the raw device, refer to the "SynfinityCluster Installation/Administration Guide."

9.3.2 Editing RDB configuration parameter files

Specify the following setting in the RDB configuration parameter file for the active and standby instances. · Adding RDBDIRSPACE · Adding or changing RDBLOGMANAGE To define the RDB configuration parameter file created by copying RDBSYS.cfg in /opt/FSUNrdb2b/etc, an addition or a change must be made. For text file creation, RDBSYS.cfg is assumed to be the copy source and RDB system name.cfg is assumed to be the copy destination.

Operations without the RDB system name are defined in text file rdbsysconfig, which is included in /opt/FSUNrdb2b/etc. · RDBDIRSPACE

This parameter defines information on the RDB directory file. The syntax is as follows:

- RDBDIRSPACE=raw_device_name_of_shared_disk_unit raw_device_name_of_shared_disk_unit Specify the absolute path name of the raw device where the RDB directory file is to be located. Delete RDBDIRSPACE1 and RDBDIRSPACE2 from the RDB configuration parameter file. Specify the same value for both the active instance and the standby instance. In the raw device of the shared disk device specified here, both the RDB directory file for a database and an RDB directory file for the RDB dictionary are created.

· RDBLOGMANAGE

This parameter defines information on the log management file. The syntax is as follows:

- RDBLOGMANAGE=raw_device_name_of_shared_disk_unit raw_device_name_of_shared_disk_unit Specify the absolute path name of the raw device where the log management file is to be placed. Specify the same value for both the active instance and the standby instance.

72

9.3.3 Editing environment setting files

Specify the following setting in the operation environment files for the active and standby instances.

WORK_PATH

This parameter specifies the acquisition destination directory for the sort work area and work table areas used by the server. Since the sort work area is placed on the local disk, if switching to the standby instance occurs due to an error event in the operating instance, the sort work area that was being used by the old active instance remains in a UNIX file. As an measure to ensure proper operation, use the rm command to remove the sort work area (SYMFORDB*) before starting the standby instance. To facilitate deletion of the sort work area, you should prepare a special volume for work areas and specify this parameter to indicate the location of the sort work area. Before using the sort work area, prepare a different directory for each SymfoWARE/RDB operation environment.

The sort work area can be deleted easily if a subprocedure has been registered.

· For information on specifying this parameter, refer to the "SymfoWARE Server RDB Operations Guide" and the

"FUJITSU SymfoWARE Server RDB User's Guide: Application Program Development." · For information on registering a subprocedure, refer to the "SymfoWARE Server Hot Standby Option

Handbook."

9.3.4 Setting environment variables

Set up the following environment variable with the active and standby instances shown below: · Add environment variable LD_LIBRARY_PATH to /etc/opt/FJSVcluster/lib. · Specify the RDB system name in environment variable RDBNAME. Note, however, that this setting is not

needed for standby operation without an RDB system name. · Add environment variable MANPATH to /opt/FJSVrdbpc/man:/opt/FSUNrdbhs/man.

· Specify environment variable MANPATH in the sequence shown above. Note that the man command may not

display information correctly if the specification sequence is different. · Set the same value for environment variable LANG for both the active and standby instances. An error will

occur if you attempt to include both EUC code and shift JIS code.

9.3.5 Creating RDB environment

The environments shown below must be created during RDB environment creation.

Create each file in a raw device. When a raw device is to be specified with these operations, specify a shared disk device. · Log management file · Temporary log file · Archive log file · RDB dictionary Log management file

Create a log management file in the raw device that is specified with RDBLOGMANAGE of the RDB configuration parameter file. Create a log management file with the I option of the rdblog command.

Creating Log Management Files

rdblog -I

Temporary Log File, Archive Log File, and RDB Dictionary

Create these files according to the procedures used when hot standby system is not executed.

For details, refer to the "SymfoWARE Server RDB Operations Guide."

73

9.3.6 Enouncement of hot standby

After creating the RDB environment, declare hot standby in the active instance. Use the mon option of the rdbhsuty command to declare hot standby.

Example: Declaring hot standby

rdbhsuty -mon

Use the man command to see details on specifying the rdbhsuty command.

9.4 Environment setting for the cluster system

This section explains how to set up the cluster system environment.

9.4.1 Registering RDB resources

Register the RDB systems that are SymfoWARE/RDB operation units as resources that compose the cluster system.

To register the resources, specify the a option in the rdbhsrsc command.

To register the resources to another node, specify the node identification name of the registration-target node in the n option of the rdbhsrsc command.

If SymfoWARE/RDA-SV is also being used, specify the RDASV option to ON.

Use the man command to see details on specifying the rdbhsrsc command.

The rdbhsrsc command can be executed only by the super user.

When RDB resources are to be registered for Node0

The registered RDB resource names are as follows:

Operation with an RDB system name

Resource name RDB system name

Operation without an RDB system name

74

Resource name RDBII

9.4.2 Registering RDB cluster services

Register a cluster service for each job unit on the cluster management view. A single cluster service consists of the RDB system, applications, disks, and others.

Register the cluster services according to the procedure described below.

9.4.2.1 Starting the cluster management view

Start up the browser and specify a URL in the format of http://host name:port number. Login using the user login screen.

[Login screen]

The top menu of the Cluster operation management view appears.

[The top menu of the cluster management view]

Select [SynfinityCluster] from the top menu of the cluster management view.

The SynfinityCluster operation menu appears.

9.4.2.2 Starting the cluster management view

Select the [Cluster operation setting] with the SynfinityCluster operation menu.

75

[SynfinityCluster operation menu]

The cluster operation setting screen appears.

[Cluster operation setting menu]

Select "Cluster service setting" and select [Next]. The Cluster Service Name and Operation Format Setup screen appears.

9.4.2.3 Setting the cluster service name

Set up the cluster service name and cluster service topology on the cluster service name and operation topology

76

setup screen.

[Setting of cluster service name and cluster topology]

After specifying "Cluster service name" - "Cluster topology," click [Next]. The "node setting (standby class)" screen appears. Cluster service name

Specify the name of the cluster service to be registered. You can specify any name as the cluster service name.

Cluster topology Select Standby.

9.4.2.4 Setting up nodes

Set up the nodes to be used as the active and standby nodes.

77

[Node Setting (Standby class)]

Select "Cluster topology", "Standby node" and select [Next].

Active node

Select the node to which the active instance is to be registered.

Standby node

Select the node to which the standby instance is to be registered.

9.4.2.5 Setting up resources for use by the cluster service

The cljoinrsc command sets up the resource to be used by a cluster service.

78

[Resource setting]

From the [Settable resource] list, select the RDB system and resources (such as the disk) for which a database is to be created and then add them to the [Setting resource] list.

Select [Next].

9.4.2.6 Setting up application dependency

If a cluster service consists of multiple applications, the "application launch/stop priority setting" screen appears.

79

[Setting of application launch/stop priority]

To change the launch priority, change the startup sequence of the applications on the "application launch/stop priority setting" screen, and then click [Next].

The "Setting the type of shared disk device" screen appears.

9.4.2.7 Setting the type of shared disk devices

Set up the shared disk device type (shared disk/switched disk) to be used for SymfoWARE on the "Setting the type of shared disk device" screen.

80

[Setting the type of shared disk device]

You must select "Shared disk for simultaneous access" as the disk to which RDB resources such as the RDB dictionary, RDB directory file, and database space are assigned.

After the settings have been made, press the [Next] button. Checking and registration of the cluster service screen appears.

For details on file allocation, refer to the "SymfoWARE Hot Standby Option Guide."

9.4.2.8 Registering the cluster service

In the "Checking and registration of the cluster service" view, check the specified items.

81

[Checking and registration of the cluster service]

If the specified items are correct, select <Registration> to register the items.

9.4.3 Registering the cluster domain operation topology

When performing operations in a system that has anN:1-standby configuration, specify and register the cluster domain operation topology. Set up and register the cluster domain topology using the following procedure:

9.4.3.1 Setting the cluster domain operation topology

At the "Cluster operation setting menu" screen, select "Cluster domain operation topology setting".

82


At the "Cluster domain operation topology setting menu" screen, select <N:1 cluster service standby mode setting>.

[Cluster domain operation topology setting menu]

At the "N:1 Cluster Service Standby Mode Setting" screen, select <Single standby>.

83

[N:1 cluster service standby mode setting]

9.4.3.2 Registering the cluster domain operation topology

At the "Checking and registration of the N:1 cluster service standby mode" screen, check the settings for the cluster domain operation mode. If the specified items are correct, select <Registration> to register the items.

[Checking and registration of the N:1 cluster service standby mode]

84

9.4.4 Starting up the cluster services

Start the cluster service for hot standby operation.

To start a cluster service, select <Cluster operation management> from the SynfinityCluster operation menu, select the cluster service to be started at the Cluster Service View screen of the navigation area, and then select [Operation]-[Start] from the menu.

Confirm that the cluster service was started normally by checking the SymfoWARE startup message that is displayed on the console of each node.

[Cluster service start screen]

9.4.5 Checking operation

You can execute hot standby operations as soon as cluster service startup processing is completed.

Although you can begin load sharing operations immediately, Fujitsu recommends that you first check the system operation by executing failover and standby restoration to verify that the environment was set up correctly.

85

Chapter 10 Examples of Layered Scalable Operation Installations(SymfoWARE)

This chapter explains creating the operation environment and preparations for operating the operation environment necessary for load sharing implementation. · Environment Setup Procedure for Load Sharing · Preparations Before Environment Setup · SymfoWARE Environment Setup · Cluster System Environment

10.1 Environment Setup Procedure for Load Sharing

The setup procedure for load sharing is shown below with a layered scalable operation as an example.

During load sharing, the status transition procedure automatically executes operations such as RDB startup.

[SymfoWARE Procedure]

"Raw device creation," "RDB configuration parameter file editing," "Load sharing configuration parameter file editing," "Operation environment file editing," "Environment variable setup," "RDB environment creation," and "Hot standby declaration" (items enclosed in bold lines in the SymfoWARE environment setup procedure) are explained in"SymfoWARE Environment Setup"

Details on "RDB resource registration" and "RDB cluster service registration" (items enclosed in bold lines in the cluster system environment setup) are explained in "Cluster System Environment"

"Scalable-class cluster service startup" (item enclosed in bold lines in operation check) is explained in "Cluster Services Startup""Operation check" is explained in "Operation Check"

All other operations are performed in the same way as when load sharing is not executed.

87

· For details on kernel editing, refer to the "SymfoWARE Server RDB Operations Guide." · For details on other operations, refer to the "SymfoWARE Server Start Guide: Server" and other manuals. The operations ranging from raw device creation to resource registration are executed separately for each RDB system.

10.2 Preparations Before Environment Setup

Before setting up the SymfoWARE environment, perform all operations from SynfinityCluster installation to cluster initial configuration setup.

For details on the operations from SynfinityCluster installation to cluster initial configuration setup, refer to the "SynfinityCluster Installation/Administration Guide."

10.3 SymfoWARE Environment Setup

This section explains the SymfoWARE environment setup.

10.3.1 Raw Device Creation

Create the raw device to be used by SymfoWARE/RDB in a shared disk.

For instructions on setting the disk partition when a shared disk is used as the raw device, refer to the "SynfinityCluster Installation/Administration Guide."

10.3.2 RDB Configuration Parameter File Editing

Edit the RDB configuration parameter files for the active instance and the standby instance.

Assign names to the individual RDB systems that make up the scalable class. The RDB system names must be unique in the scalable class.

A template for the RDB configuration parameter file has been prepared in the /opt/FSUNrdb2b/etc directory (file name: RDBSYS.cfg). Copy the template file to "RDB_system_name.cfg" and edit the parameters.

To implement load sharing, add the following parameters to the RDB configuration parameter file to declare load

88

sharing. For information on the other parameters, refer to the "SymfoWARE Server RDB Operations Guide." · RDBLOADSHARE

This parameter declares the SymfoWARE/RDB operation environment as a load sharing system. The syntax is as follows: RDBLOADSHARE={ CAPITAL | SATELLITE } CAPITAL Declares the load sharing system as the capital system (administration system). SATELLITE Declares the load sharing system as a satellite system (general system).

· RDBDIRSPACE This parameter defines information on the RDB directory file. Description format is shown below: RDBDIRSPACE=raw_device_name_of_shared_disk_unit raw_device_name_of_shared_disk_unit Specify the absolute path name of the raw device where the RDB directory file is to be located. Delete RDBDIRSPACE1 and RDBDIRSPACE2 from the RDB configuration parameter file. Specify the same value for both the active instance and the standby instance. If the raw device specified here for the shared disk unit is a capital system, both an RDB directory file for the database and an RDB directory file for the RDB dictionary are created. If the raw device is a satellite system, an RDB directory file for the database is created.

· RDBLOGMANAGE This parameter defines information on the log management file. The syntax is as follows: RDBLOGMANAGE=raw_device_name_of_shared_disk_unit raw_device_name_of_shared_disk_unit Specify the absolute path name of the raw device where the log management file is to be placed. Specify the same value for both the active instance and the standby instance.

10.3.3 Load Sharing Configuration Parameter File Editing

To define the load sharing environment, create a load sharing configuration parameter file in both the active and standby instances. The load sharing configuration parameter file is an environment definition file that has a position equivalent to that of the RDB configuration parameter file. The prototype is installed in /opt/FJSVrdbpc/etc. Immediately after installation, the file name will be "RDBSYS.net." Copy the template file to "RDB_system_name.cfg" and edit the parameters.

Shown below are the parameters to be specified in the load sharing configuration parameter file. · RDBCOOPNUM

This parameter specifies the number of environments to be stored for remote accesses from application programs operating in other nodes. When an application program executes a remote access, one environment is used. If an environment shortage occurs, another environment is created automatically. As a guideline, specify the total number of application programs that are to be executed in other nodes. The syntax is as follows: RDBCOOPNUM=number_of_remote_accesses number_of_remote_accesses Specify an integer from 0 to 32767. If this specification is omitted, the default value for number of remote accesses is 0. Specification example Shown below is a specification example of the load sharing configuration parameter file. # # Creation date :1999.06.14 RDBCOOPNUM=300

10.3.4 Operation Environment File Editing

Specify the following setting in the operation environment files for the active and standby instances.

WORK_PATH

This parameter specifies the acquisition destination directory for the sort work area and work table areas used by the server. Since the sort work area is placed on the local disk, if switching to the standby instance occurs due to an error event in the operating instance, the sort work area that was being used by the old active instance remains in a UNIX file. As an measure to ensure proper operation, use the rm command to remove the sort work area (SYMFORDB*_RDB_system_name) before starting the standby instance. To facilitate deletion of the sort work area, you should prepare a special volume for work areas and specify this parameter to indicate the location of the sort work area. Before using the sort work area, prepare a different directory for each SymfoWARE/RDB operation environment.

The sort work area can be deleted easily if a subprocedure has been registered.

89

· For information on specifying this parameter, refer to the "SymfoWARE Server RDB Operations Guide" and the

"FUJITSU SymfoWARE Server RDB User's Guide: Application Program Development." · For information on registering a subprocedure, refer to the "SymfoWARE Server Parallel Cluster Option

Guide."

10.3.5 Environment Variable Setup

To define the environment for load sharing, you must set the following environment variables in the active and standby instances: · Add environment variable LD_LIBRARY_PATH to /etc/opt/FJSVcluster/lib. · Specify the RDB system name to environment variable RDBNAME. · Add environment variable MANPATH to /opt/FJSVrdbpc/man:/opt/FSUNrdbhs/man:/opt/FSUNrdb2b/man.

· Specify environment variable MANPATH in the sequence shown above. Note that the man command may not

display information correctly if the specification sequence is different. · Set the same value to environment variable LANG for both the active and standby instances. An error will

occur if you attempt to combine EUS code and JIS code.

10.3.6 RDB Environment Creation

The environments shown below must be created during RDB environment creation.

Create these files in the raw device. Specify a shared disk device as the raw device. · Log management file · Temporary log file · Archive log file · In-doubt log file · RDB dictionary · RDB directory files Log Management Files and Archive Log Files

Create these files according to the procedures used when load sharing is not executed.

For details, refer to the "SymfoWARE Server RDB Operations Guide."

Temporary Log File, Archive Log File, and RDB Dictionary

The temporary log file must be created before RDB system operation is started. This file stores log information that is required for down recovery.

If a node in the cluster system goes down, use the flash treatment recovery function to shorten the time until operation of that node is restarted. To use the flash treatment recovery function, specify the w option when creating the temporary log file.

Use the rdblog command to create the temporary log file. The specification example shown below creates a BI log area of 60 M, an AI log area of 60 M, 200 transaction entries, and a log index area in /dev/FJSVmphd/rdsk/mphd2048s1.

rdblog -G -t -w /dev/FJSVmphd/rdsk/mphd2048s1 -in -in 60M 60M 200

For the BI log area, the AI log area, and the transaction entry count, specify values that are about twice as large as those specified when the flash treatment recovery function is not used.

Creating the In-doubt Log File

If a transaction executes remote access and the local node or remote system goes down after the transaction reaches the commit-ready stage in the remote system, the translation cannot be completed. In this case, the in-doubt log file stores information that allows the transaction to be completed.

90

Use the rdblog command to create the in-doubt log file.

Example: Creating the in-doubt log file in /dev/FJSVmphd/rdsk/mphd2048s3

rdblog -G -i /dev/FJSVmphd/rdsk/mphd2048s3 30M

Use the man command to see details on specifying the rdblog command.

Creating the RDB Dictionary and RDB Directory Files

In load sharing, the procedures for creating the RDB dictionary and the RDB directory files are different for the capital system and for a satellite system.

Use the rdbcrdic command to create the RDB dictionary and RDB directory files. · Capital system

In the capital system, an RDB dictionary and RDB directory files (for the dictionary and for the user database) are created. Shown below is an example in which the RDB dictionary is created in the raw device of the shared disk unit in the capital system. The RDB directory files are created concurrently with the RDB dictionary in the raw device of the shared disk unit that was specified in the RDB configuration parameter file. Example: Creating an RDB dictionary in /dev/FJSVmphd/rdsk/mphd2048s4 rdbcrdic -r /dev/FJSVmphd/rdsk/mphd2048s4

· Satellite system In a satellite system, only an RDB directory file for the user database is created. Shown below is an examples in which the RDB directory file for the user database is created in a satellite system. The RDB directory file is created in the raw device of the shared disk unit that was specified in the RDB configuration parameter file. Example: Creating an RDB directory file rdbcrdic -du 1M -eu 1M

Use the man command to see details on specifying the rdbcrdic command.

10.3.7 Hot Standby Declaration

After creating the RDB environment, declare hot standby in the active instance. Use the mon option of the rdbhsuty command to declare hot standby.

Example: Declaring hot standby

rdbhsuty -mon

Use the man command to see details on specifying the rdbhsuty command.

10.4 Cluster System Environment

This section explains how to set up the cluster system environment.

10.4.1 RDB Resource Registration

Register the RDB systems that are SymfoWARE/RDB operation units as resources that compose the cluster system.

To register the resources, specify the a option in the rdbpcrsc command.

To register the resources to another node, specify the node identification name of the registration-target node in the n option of the rdbpcrsc command.

If SymfoWARE/RDA-SV is also being used, specify the RDASV option to ON.

Use the man command to see details on specifying the rdbpcrsc command.

91

The rdbpcrsc command can be executed only by users with the root authority.

RDB Resource Registration in N-active:1-Standby Layered Scalable Operation

The registered RDB resource names become RDB system names.

10.4.2 RDB Cluster Service Registration

Use the cluster management view to register cluster services. In layered scalable operation, register multiple cluster services of the standby class and the cluster services of the scalable class that these cluster services belong to.

Register the cluster services according to the procedure described below. · Registering Cluster Services of the Standby Class · Register cluster services of the scalable class

10.4.2.1 Registering Cluster Services of the Standby Class

Register all standby-class cluster services that compose the scalable class.

For instructions on how to register standby-class cluster services, refer to "Registering RDB cluster services"

10.4.2.2 Specifying Cluster Service Names of the Scalable Class

At the "Cluster operation setting menu" screen, select "Cluster Service setting."

92


From the "Setting of cluster service name and cluster topology" screen, specify the cluster service name and service class of the scalable class cluster service.

[Cluster Service Name and Operation Format Setup]

Cluster service name

Specify the name of the cluster service to be registered. Any name can be specified as the cluster service

93

name. Cluster topology

Select "Layered Scalable."

A convenient way to create a layered scalable cluster service is to attached "Lay" at the beginning of the cluster service name to identify the cluster service from cluster services of other formats.

10.4.2.3 Specifying Cluster Services that Compose the Scalable Class

At the "Cluster service selection" screen, select the cluster services that compose the scalable class.

[Cluster Service selection screen]

Select the clusters services that compose the scalable class from [Settable cluster service] and add them to [Setting Cluster Service].

10.4.2.4 Registering Cluster Services

In the "Checking and registration of the cluster service" view, check the specified items.

94

[Checking and registration of the service]

If the specified items are correct, select <Registration> to register the items.

10.4.3 Cluster Domain Operation Topology Registration

When performing operations on a system that features layered scalable operation and which has an N-operating:1-standby configuration, specify and register the cluster domain operation topology. The procedure for specifying and registering the cluster domain operation topology is described below.

10.4.3.1 Specifying the Cluster Domain Operation Topology

At the "Cluster operation setting menu" screen, select "Cluster domain operation topology setting".

95


At the "Cluster domain operation topology setting menu" screen, select <N:1 cluster service standby mode setting>.

[Cluster domain operation topology setting menu]

At the "N:1 Cluster Service Standby Mode Setting" screen, select <Single standby>.

96

[N:1 cluster service standby mode setting]

10.4.3.2 Registering the Cluster Domain Operation Format

At the "Checking and registration of the N:1 cluster service standby mode" screen, check the settings for the cluster domain operation mode. If the specified items are correct, select <Registration> to register the items.

[Checking and registration of the N:1 cluster service standby mode]

97

10.4.4 Cluster Services Startup

This section explains the procedure for starting a scalable class cluster service.

To start a cluster service, select <Cluster operation management> from the SynfinityCluster operation menu, select the cluster service to be started at the Cluster Service View screen of the navigation area, and then select [Operation]-[Start] from the menu.

Confirm that the cluster service was started normally by checking the SymfoWARE startup message that is displayed on the console of each node.

[Cluster Service Startup Screen]

10.4.5 Operation Check

You can execute load sharing operations as soon as cluster service startup processing is completed.

Although you can begin load sharing operations immediately, Fujitsu recommends that you first check the system operation by executing failover and standby restoration to verify that the environment was set up correctly.

98

Chapter 11 Examples of Scalable Operation Installations (SynfinityFile/Global)

This chapter explains how to create a running environment for SynfinityFile/Global and prepare it for operation.

11.1 SynfinityFile/Global Operation Procedure

The SynfinityFile/Global operation procedure is shown below.

[SynfinityFile/Global Operation Procedure]

The shared disk settings are specified with the cluster management view.

The SynfinityFile/Global management view allows you to use a wizard to perform operations ranging from file system creation to cluster service registration.

The command operations allow you to perform operations such as file system creation, resource registration, cluster service registration, and cluster service start.

The cluster management view allows you to perform operations such as registering and starting cluster services.

11.2 Scalable class

This section explains the scalable class operation procedure for SynfinityFile/Global SynfinityCluster.

11.2.1 Shared Disk Setup

Each SynfinityFile/Global file system is created on a shared disk.

Specify "simultaneous access shared disk" as the usage type of a shared disk which is to be used by SynfinityFile/Global. If automatic shared disk setup was selected during initial cluster configuration, no changes are necessary because the setup procedure specifies this type.

99

For instructions on setting up a shared disk, refer to the "SynfinityCluster Installation/Administration Guide."

11.2.2 Creating a SynfinityFile/Global File System

This section describes two methods of creating a SynfinityFile/Global file system.

11.2.2.1 GUI-Based File System Creation

In GUI-based file system creation, the SynfinityFile/Global management view is used to create the file system.

For instructions on creating a file system using a GUI, refer to the "SynfinityFile/Global Guide."

11.2.2.2 Command-Based File System Creation

In command-based file system creation, the sfcnewfs(1M) and mkfs_sfcfs(1M) commands are used to create the file system.

For instructions on creating a file system using commands, refer to the "SynfinityFile/Global Guide."

11.2.3 Registering SynfinityFile/Global Resources

Register the SynfinityFile/Global resources as part of the cluster system.

Information on registering SynfinityFile/Global resources is explained below.

11.2.3.1 For GUI-Based File System Creation

When a file system is created with the SynfinityFile/Global management view, SynfinityFile/Global resources are registered during file system creation. The resources do not need to be re-registered.

To check the resource names of the resources that were created with the SynfinityFile/Global management view, use the SynfinityFile/Global management view.

For instructions on checking the resource names of resources registered by the SynfinityFile/Global management view, refer to the "SynfinityFile/Global Guide."

11.2.3.2 Command-Based File System Creation

If you created a file system with the sfcnewfs(1M) and mkfs_sfcfs(1M) commands, the sfcaddrsc(1M) command must be used to register the corresponding resources.

For details on sfcaddrsc(1M), refer to the "SynfinityFile/Global Guide."

The following is an example of file system resource registration for a file system that uses /dev/FJSVgdhd/rdsk/gdhd0s1 as its Representative partition The resource names and shared node names are output as the execution result.

100

11.2.4 Registering SynfinityFile/Global Cluster Service

This section explains information on registering SynfinityFile/Global cluster services.

11.2.4.1 For GUI-Based File System Creation

When a file system is created with the SynfinityFile/Global management view, cluster service registration can be executed during file system creation. In this case, the cluster service does not have to be re-registered.

If cluster service registration is not executed during file system creation, the cluster management view must be used to register the cluster services.

For instructions on using the SynfinityFile/Global management view to register the cluster service of a file system, refer to the "SynfinityFile/Global Guide."

11.2.4.2 For Command-Based Cluster Service Registration

Command-based cluster service registration is executed with the sfcaddsvc(1M) command.

During cluster service registration, specify the mount point of the SynfinityFile/Global file system. After the cluster service is started, the file system is mounted on the specified mount point.

For details on sfcaddsvc(1M), see the "SynfinityFile/Global Guide" for more information.

Shown below is an example of registering a cluster service using the file system that has /dev/FJSVgdhd/rdsk/gdhd0s1 as its Representative partition , with /sfcfs1 specified as the file system mount point. The cluster service name that is assigned as the result of execution is as shown below:

To specify the cluster service name when registering a cluster service, specify the -s option of the sfcaddsvc(1M) command. The specified cluster service name must not be a name that is already being used. Shown below is an example of registering a cluster service by specifying the cluster service name. This example registers a file system that has /dev/FJSVgdhd/rdsk/gdhd0s1 as its representative partition, with safeglobal01 as the cluster service name and /GLOBAL01 as the mount point.

11.2.4.3 Cluster Service Registration with the Cluster Operation Management View

This section explains cluster service registration with the cluster management view.

Register the cluster services according to the procedure described below.

Operation: 1. From the "Cluster operation setting menu" screen, select <Cluster Services setting>.

101

2. From the "Setting of cluster service name and cluster topology" screen, specify the cluster service name and

service class of the scalable class cluster service.

Cluster service name

Specify the name of the cluster service to be registered. Any name can be specified as the cluster service name.

Cluster topology Select "Scalable."

102

When creating a SynfinityFile/Global cluster service, you should add "SynfinityGlobal" to the cluster service name so that it can be distinguished from other service types.

3. In the "Node setting (scalable class)" view, specify the nodes that make up the cluster service.

Select shared nodes of the SynfinityFile/Global system from [Settable node], and add them to [Setting node].

4. In the "Resource setting" view, select the resources that make up the cluster service.

103

Select the SynfinityFile/Global resources and the shared disk resources for file system creation from [Settable resource], and add them to [Setting Resource].

5. In the "Checking and registration of the cluster service" view, check the specified items. If the specified items are correct, select <Registration> to register the items.

6. After registering the cluster service, specify the mount point of the SynfinityFile/Global file system.

After the cluster service is started, the file system will be mounted to the specified mount point. To specify the mount point, use the sfcaddsvc(1M) command.

For details on sfcaddsvc(1M), refer to the "SynfinityFile/Global Guide."

Shown below is an example of registering a cluster service using the file system that has /dev/FJSVgdhd/rdsk/gdhd0s1 as its Representative partition, with /sfcfs1 specified as the file system mount point.

11.2.4.4 Cluster Service Startup

This section explains the procedure for starting a scalable class cluster service.

11.2.4.4.1 Command-Based Cluster Service Start

To start the Cluster service of a SynfinityFile/Global file system with a command, use the clstartsvc command.

For details on the clstartsvc command, refer to the "SynfinityCluster Installation/Administration Guide."

The following example shows the cluster service start procedure for cluster service sfcfs_svc15, which includes a SynfinityFile/Global file system.

11.2.4.4.2 Cluster Service Start Using the Cluster Management View

To start the cluster service, first select <Cluster Management> from the SynfinityCluster menu. Next, select the cluster

104

service to be started from the Service View within the navigation area, and then select [Operation]-[Start].

[Service Startup Screen]

11.2.5 Operation Check

You can use the SynfinityFile/Global file system as soon as cluster service start processing has completed.

Although you can begin using the file system immediately, Fujitsu recommends that you first check degenerate operation and standby restoration to verify that the environment was set up correctly.

105

Glossary

1:1 standby

One of the SynfinityCluster system cluster topologies. One standby class operates in the system of two nodes, and an active instance and a standby instance operate on separate nodes when the classes are started. This cluster topology is generically called standby operation together with N:1 standby and mutual standby.

AP-Net

High-speed interconnecting device developed by Fujitsu. This device has a one-way bandwidth of 240 MB/s. There are two types of AP-Net cabinets: a small AP-Net cabinet and a normal AP-Net cabinet. Eight nodes can be connected to a small AP-Net cabinet, and 64 nodes can be connected to a normal AP-Net cabinet. The network topology is a two-dimensional mesh for the small AP-Net cabinet and a two-dimensional torus for the normal AP-Net cabinet.

cookie

Information stored on the disk drive of the client when a client uses a browser to access the server. The cookie is used when the server identifies the accessed client.

FDU/FU

Disk file device that collectively installs single disks into the same cabinet.

GDHD

General-purpose disk driver that manages shared disks that can be used as cluster services. SynfinityCluster uses GDHD to manage shared disks and treats shared disk as resources so that it can use disk switching control to handle shared disks that are connected with a single path.

HA

Abbreviation for high availability. See the explanation of "High availability."

HBA

See the explanation of "Host bus adapter."

MAC address

MAC address. Address that identifies the office or node that is used by the MAC sublayer of a local area network (LAN).

107

MAC sublayer

One of the sublayers of the data link layer in the Open Systems Interconnection (OSI) model. This sublayer defines.

MPHD

Abbreviation for Multi Path Hard Disk driver. High availability is provided by switching between two paths (the path that is currently operating is called the active path while the path that is in the standby state is called the standby path). MPHD is equivalent to the standard functional portion of Multipath Disk Control 2.0.

See the explanations of "Multipath Disk Control" and "MPLB."

MPLB

Abbreviation for Multi Path Load Balance disk driver. The load balance function of a multipath disk is newly introduced from Multipath Disk Control 2.0. Conventional multipath disk control used only one of multiple paths and its availability was guaranteed by switching the path when a failure occurred. MPLB is available for load balancing by using all of the multiple paths. MPLB is equivalent to the optional function of Multipath Disk Control 2.0 with which load balance is achieved by using two to eight paths. Note, however, that up to two paths can be used to configure the MPLB in a SynfinityCluster environment.

See the explanations of "Multipath Disk Control," "MPLB" and "Load balance."

N:1 standby

One of the SynfinityCluster system cluster topologies. N standby instances operate in the system of N+ 1 nodes, one active instance operates on N nodes, and N standby instances operate on a single node. This cluster topology is generically called standby operation together with 1: 1st and by and mutual standby. Single-service standby mode that causes cut off to other services when fail over occurs in one service or multiple service standby modes that permit fail over of multiple services is selected for operation.

OS loop

See the explanation of "System loop."

SynfinityCluster

Software that Fujitsu provides for cluster configuration.

SynfinityCluster system

Cluster system built using SynfinityCluster, which is distributed by Fujitsu.

108

SynfinityCluster system initial setup tool

This tool is used to set the environment in which the software products required to control the cluster system are collected and automatically installed in each node.

Use the custom JumpStart installation and network installation, which are tools used to install Solaris and any software products required to SynfinityCluster system.

SynfinityCluster operation menu

The SynfinityCluster operation menu consists of three menus: cluster initial configuration setting, cluster operation setting, and cluster operation management.

SCF/RCI

One of the hardware devices installed in the PRIMEPOWER. The SCF or RCI includes the bus used to monitor the state of the node in the cluster system and to control the power to remote nodes as a hardware feature.

UPS

Uninterruptible power supply

Web-Based Admin View

Common base provided by a variety of management products beginning with the cluster management view of SynfinityCluster. Web-Based Admin View is also bundled with this software.

For details, refer to the "Web-Based Admin View Operation Guide V20."

Adapter

See the explanation of "Host bus adapter."

Application class

The application class is suitable for starting or stopping the ISV software or user applications from the state transition procedure.

Instance

Logical element making up a service. The change of instance status causes state transition of a cluster service.

Instance active state

An instance in this state is processing a cluster service to which the instance belongs.

109

Current operation qualifications of the instances

Operation qualifications that instances can assume when the cluster service is started.

Active refers to that state in which the instance is running in active mode or has a qualification to run in active mode when the cluster service starts.

Standby refers to the state in which an instance is running in standby mode or is qualified to run in standby mode when a cluster service starts.

Instance state

A state that an instance can enter. There are four instance states: active, standby, stopped, and transition from one state to another state).

Instance operation qualifications defined for initial setup

Operation qualification of the instance defined at cluster service setup.

Active refers to the qualification set up as the active operation qualification.

Standby refers to the qualification set up as the standby operation qualification.

Instance standby state

An instance in this state is on standby to inherit the service that the active instance is processing.

Instance stopped state

An instance in this state cannot continue processing of the cluster service to which it belongs.

Instance operation qualifications

Qualifications that instances can take.

Active and standby qualifications are available.

Installation server

System having a Solaris CD image on the disk or CD-ROM drive to distribute the Solaris CD image to other systems over the network.

Warm standby

Topology that restarts when a failover occurs automatically upon the occurrence of a failure in the application of a standby instance if the cluster service is of standby class.

110

Active instance

An active instance is an instance in active state.

Standby

The application on the operation side executes a job. The application on the standby side inherits the job only when a failure occurs in the application on the operation side. In active and standby mode, these applications are operating on different nodes.

Active node

Node on which an active node in the standby class operates

Line switching unit

This device connects external lines to more than one node and switches the connected nodes by the RCI.

Single node state

State in which an active instance is processing the cluster service without the standby instance when a fail over or cut off has occurred.

Availability

Degree of system "available state." Availability can be improved when the device has a multiple-system configuration and the system is switched at failure.

Diagnosis at start

A type of monitoring method that checks whether failures have occurred only when the SynfinityCluster system is started. As an example, the shared disk connection check function belongs to this type. Other monitoring method types include immediate diagnosis and periodic diagnosis.

Launch/stop priority

Value that specifies the order of applications to be started and stopped. The application having the lowest start and stop priority number is started first, and the application having the highest start and stop priority number is stopped first.

The start and stop priority is mainly classified into four classes: 1. System state 2 class 2. System state 3 class 3. Subsystem application class

111

4. User application class

Subsystem application class

This class is used to register basic middleware applications or package products by jobs when a user application such as DBMS is operated.

Job

Regular work executed by user applications or middleware products running on the cluster system. See the explanation of "Cluster service."

Public LAN

LAN used by applications. The public LAN is installed separately from the private LAN that the cluster control program uses.

Shared device

Device connected to more than one node in the cluster system. A shared device includes the shared disk drive and the line switching device.

Shared disk

One of the utilization modes of the shared disk drive. The shared disk drive can be accessed concurrently by nodes under the responsibilities of applications on each node. (Note that "shared disk" has a different meaning from "shared disk drive." To distinguish them, the "shared disk" may be referred to as the "shared disk to be accessed concurrently.")

Shared disk drive

Disk drive connected to more than one node. The shared disk drive in SynfinityCluster includes the FDU or FU and the disk array device. The shared disk drive is classified into two types: shared disk and switched disk, according to the utilization mode in which the disk is accessed concurrently from nodes. (Note that "shared disk drive" has a different meaning from "shared disk.")

Shared resource

Resource of the device shared between nodes

Failover

In a standby class cluster service, if an error occurs in the active instance or a failover request is issued, the active instance changes its state from active to stopped. The standby instance changes its state from standby to active.

112

Switched disk

One of the utilization modes of the shared disk drive. In switched disk mode, the cluster control retains exclusive control so that the disk can only be accessed by one node.

Cut off

If an error occurs in the standby instance or a stop request is issued, the standby instance is stopped.

Failback

The service state is changed to two different states in transition: switching and standby restoration.

Standby restoration

A stopped instance changes its state to a state in which it can be used by the cluster service. As a result of standby restoration, the stopped instance becomes a standby instance for standby or layered standby operation and an active instance for scalable operation.

Standby restoration mode

Mechanism for permitting standby restoration and addition. To permit standby restoration, the standby restoration mode must be set to "standby restoration enabled."

Cluster management view

Software running on Web-Based Admin View that is provided for the Synfinity series cluster management view, such as SynvinityCluster and SynfinityDisk.

Cluster management server

The cluster management server installs an http server. It receives operation requests or state display requests from the client and sends operation requests or state display requests to cluster servers.

Cluster service

Concept on the cluster system that corresponds to a job operated in the domain. A cluster service consists of more than one instance. See the explanation of "Job."

113

Cluster service class

General term for cluster service types. The cluster service classes include standby class and scalable class.

Cluster service tree

The relationship between the instance making up the cluster service and the resource is represented as a tree structure. This tree structure is called the cluster service tree.

Cluster service active state

One of the states that a cluster service can enter. In this state, the cluster service is operating normally.

Cluster service status

State that the cluster service can enter. There are four service statuses: stopping, active, FAILOVER, and changing (switching process from one state to another state.)

Cluster service state transition

The cluster service state is changed to another state. A cluster service state transition occurs when the state of an instance making up the cluster service is changed. There are three types of state transitions due to three service states. Depending on a class that the cluster service belongs to and a type of state transition of the instance making up the cluster service, cluster service state transitions are classified into seven types; startup, stop, fail over, cut off, degenerate, standby restoration, and addition. Failback, which is a state transition (from fail over to standby restoration), is also handled as one normal state transition type. Therefore, there are eight types of cluster service state transitions.

Cluster service stopped state

One of the states that a cluster service can enter. In this state, all instances related to the service are stopped.

Cluster service failover state

One of the states that a cluster service can enter. In this state, one of the instances related to the cluster service has stopped.

Cluster system

System with high availability and high performance. In the cluster system, nodes are connected through dedicated networks. High availability has been implemented by switching to another node and taking over the job at node failure. High performance has been implemented by processing the database in parallel on multiple servers. Also, node addition gives the cluster system excellent expandability.

114

Cluster system name

Operational name given to the entire cluster system

The cluster system name is displayed as the name of the SynfinityCluster system on the cluster management view.

Cluster control facility

The cluster control facility is a component of SynfinityCluster. It detects various errors and changes the state.

Cluster domain

Node group required for operating a job. The domain also indicates a node group concurrently monitored by the cluster system control program.

Cluster domain name

Operational name given to the domain

The domain name is displayed as the name of the cluster domain on the cluster management view.

Group

A resource in which multiple resources are united so that it can run with a specific attribute.

Global MAC address

MAC address that is managed by IEEE, which was commissioned by ISO, and manufacturers of local area network (LAN) products. A global MAC address is guaranteed uniqueness throughout the world.

High availability

High system availability. High availability is implemented when the device has a multiple-system configuration and the system is switched at failure.

Cold standby system

The standby instance application is started when the service is in a standby class and a switching occurs.

Controller

Control section of the device. The controller is connected to a host bus adapter.

See the explanation of "Channel adapter."

115

System console

The PRIMEPOWER System Management Console(SMC), which is connected to PRIMEPOWER 800, 1000 and 2000, is called the "system console."

System state 2 class

This class is suitable when package products and the ISV software that support the cluster control start the state transition procedure with a priority equivalent to /etc/rc2.d.

System state 3 class

This class is suitable when package products and the ISV software that support the cluster control start the state transition procedure with a priority equivalent to /etc/rc3.d.

System loop

In this status, the operating system or high-priority real-time process works incorrectly and the regular application cannot be operated.

Degeneration

The term "degenerate" used for a scalable class operation means cluster service state transition from active to fail over. This term used for layered scalable operation means that degenerate occurs in the scalable class that makes up the scalable class or that fail over or cut off occurs in the standby class.

If this term is used for Multipath Disk Control, part of disk path cannot be used.

Degenerate operation (for Multipath Disk Control)

To enhance failure-resistance, Multipath Disk Control features more than one disk path. To ensure redundancy, SynfinityDisk features more than one disk drive. In a degenerate operation, original redundancy has been degraded due to a failure or user instruction.

State transition procedure

The state transition procedure receives a state transition instruction from the cluster control and controls activation and deactivation of the resource (start and stop of the application).

Redundancy

Redundancy indicates a multiple-system configuration of a device to prevent the system from stopping due to a device failure.

116

Single node

Node that does not have the cluster system configuration.

Reliability

Degree of system failure-resistance. To enhance reliability, select hardware that features a high degree of failure-resistance

Scalable operation

One of the SynfinityCluster system cluster topologies. This cluster topology consists of one scalable class.

Scalable class

One of the class service types (service class). Initially, this class consists only of multiple active instances. Even if an active instance is stopped, the job can be continued if there is another active instance remaining.

Referred to as scalable type in V2.0 or later.

Standby operation

Three types of cluster topology in the SynfinityCluster system: 1:1 standby, N:1 standby, and mutual standby.

Standby class

One of the cluster service types (service class). Initially, this class consists of an active instance and a standby instance. When the active instance is stopped, the standby instance operates as the new active instance.

Referred to as standby type in V2.0 or later.

Mutual standby

One of the SynfinityCluster cluster topologies. Multiple standby classes operate in the same system, and an active instance and a standby instance of a different service exist together on one node when the classes are started. Though this topology can consist of multiple nodes, often consists of just two nodes (this case is called 2-node standby). This cluster topology is generically called standby operation together with 1:1 standby and N:1 standby.

Immediate diagnosis

Immediate diagnosis is a type of monitoring method and features immediate detection of the occurrence of an error. As an example, the asynchronous monitoring in a node monitoring facility is included in this type. Other types of monitoring methods include periodic diagnosis and diagnosis at start.

117

Standby instance

A standby instance is an instance in standby state.

Standby node

Node that is operating as the standby instance of the standby class.

Representative partition

A SynfinityFile/Global file system partition that consists of a meta data area, an update log area, and a file data area (data area). The partition sometimes consists only of a meta data area and a file data area (data area).

Startup

State transition of a cluster service from stopped to active.

Single cluster service standby mode

One of the N:1 standby operation modes. If a fail over occurs, other standby instances are cut off. Because a fail over for only one of N cluster services is permitted, estimation of the performance on the standby node is relatively easy. However, if a fail over occurs, other cluster services enter the single instance operation. Quick recovery should be done for the entire system. The other N:1 standby operation mode is single cluster service standby mode.

Addition

When the term "addition" is used for a scalable class, it means state transition of a service from FAILOVER to active.

Periodic diagnosis

A type of monitoring method for monitoring whether an error occurs continuously at fixed intervals. As an example, the heartbeat of node monitoring facility is included in this category. The feature of the periodic diagnosis is that the time an error is detected depends on the diagnosis interval. In many cases, this diagnosis interval can be specified. Other types of monitoring methods include immediate diagnosis and diagnosis at start.

Stop

When the user stops an instance, cluster service, or node or the cluster control detects an error, the cluster service changes its state to stopped.

Stopped instance

An instance in the stopped state.

118

Disk switching

See the explanation of "Switched disk."

Synchronized power control

See the explanation of "SCF/RCI."

Shared disk for simultaneous access

One of the states in which the shared disk drive is used. The state in which the shared disk drive can be accessed simultaneously by users (also simply called shared disk).

Network interface card

See the explanation of "Network adapter."

Network adapter

LAN adapter

Node

A single computer (on which a single operating system operates)

Node identifier

Unique name given to a node in the SynfinityCluster system

Normally, a node identifier can be the same as the node name of the corresponding nodes. If the standby node takes over the node name in the hot standby system, the correspondence between the physical name and the node name is temporarily changed. The node identifier, which is a physical name, can be used to support this change.

The node identifier is displayed as the name of the node on the cluster management view.

119

Node name

Name indicated by uname -n. This name is recognized by the communication network. See the explanation of "uname (1)" for details.

Panic

When system operation cannot be continued because the operating system detects an error or a self-processing conflict, the contents of the memory are saved to the disk and the system is stopped. When a panic occurs, the system is automatically rebooted.

Hub

Star-type wiring device used for LAN or fibre channels.

Unshared resource

Resource that is not shared among multiple nodes.

Fibre channel

One of the interfaces that use optical fiber cables as transmission media. In the cluster system, the fiber channel is used to connect the RAID.

Combined operation

One of the SynfinityCluster system cluster topologies. The independent scalable class and standby class exist together in the same system without having a hierarchical relationship.

Multiple cluster service standby mode

One of the N:1 standby operation modes. If a fail over occurs, other standby instances are not cut off. Because a fail over is permitted for all N services, it is important to estimate the performance of the standby node if a fail over occurs more than once. Another N:1 standby operation mode is single service standby mode.

Power recovery mode

If the power has been turned off due to a power failure or the like while the system is running, the operation performed when the power subsequently recovers is set up as power recovery mode.

Physical IP address

The IP address directly allocated to the interface (i.e., hme0) of the network interface card. A related term is the logical IP address. For information about the logical interface, see the explanation of logical interface in ifconfig(1M).

120

Private LAN

LAN used by the cluster control. The private LAN is used for regular node monitoring or communication inside the cluster control program. The private LAN is installed separately from the application LAN.

Free node

Node in which SynfinityCluster is installed but is not incorporated into a SynfinityCluster system.

Scalable topology

A generic name for a scalable operation and a layered scalable operation, which are SynfinityCluster system topologies.

Hot standby system

When the cluster service is a standby class and a switching occurs in the standby instance application, the started standby instance application is in standby. Hot standby can reduce the switching time compared with cold standby.

Host bus adapter

I-O control card inserted into the node bus slot.

Multicast

Technology that implements 1-to-many communication in an IP network. More precisely, this technology is called IP multicast.

Multicast address

IP address for implementing multicast.

Multi-domain

In multi-domain mode, the cluster system is divided depending on the job to operate multiple jobs.

Multipath disk control

Software required to connect a single node to the disk array device (RAID) through more than one disk path. The disk paths are seen as one virtual disk path. Operation can be continued even when a failure occurs in one of the disk paths.

121

See the explanations of "MPHD," "MPLB" and "Load balance."

User group

The user group limits the operation range including the environment setting and operation management provided by the Cluster Management View. There are four types of user groups: wvroot, clroot, cladmin, and clmon. Each user ID is registered in an appropriate user group by the operation system administrator of the management server.

Resource

The hardware and software of cluster system that are managed by the cluster control facility

Resource ID

Number allocated to identify resources

Resource group

Hardware or software resources that compose a cluster system. The resources can be categorized into two main types: resources under a node and resources shared among nodes.

Resource group tree

Resources create groups or take a hierarchical structure as required.

The tree structure representing the resource hierarchical structure is referred to as the resource group tree.

Remote console(RCCU)

Device used to operate input-output data from the node console from a remote PC through a LAN.

User application class

This class is used to register applications created by the user when the applications are started or stopped from the state transition procedure.

Layered scalable operation

One of the SynfinityCluster system cluster topologies. Multiple standby classes exist under one scalable class to provide both a high degree of availability and expandability. Currently, the product for which this cluster topology is available is limited to some SynfinityCluster-related products.

122

Local MAC address

MAC address that the system administrator of a local area network (LAN) system guarantees to be unique within that system.

Load balance

Also referred to as the load distribution method. The method with which scalability and failure-proof can be enhanced. With this method, the multipath disk load balance (MPLB) option actualizes input-output load balance by using multiplexed paths.

Rolling update

Update method used for fix application or maintenance in the cluster system. Fix application is enabled by applying fixes to each node sequentially without stopping jobs.

Logical IP address

See the explanation of the logical interface in "ifconfig (1M)" for details.

Logical unit

A logical unit (LU) is a logical disk unit in a disk array unit. For details, see the explanation for "Disk array unit."

123

synfinitycluster installation/administration guide for ... · pdf filesynfinitycluster...

Documents