RETHINK THE ECONOMICS OF DATA

BEX Cluster Support Guide

Release 3.4

bexcdz111810cs

 Syncsort Incorporated, 2011 All rights reserved. This document contains proprietary and confidential material, and is only for use by licensees of the BEX proprietary software system. This publication may not be reproduced in whole or in part, in any form, except with written permission from Syncsort Incorporated. Backup Express, BEX, and BEX Instant Virtualization are trademarks of Syncsort Incorporated. All other company and product names used herein may be the trademarks of their respective companies.

Table of Contents
Chapter 1. Introduction to Cluster Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Clustering Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 BEX Cluster Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Windows Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Introduction to Windows Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Physical Representation of a Windows Cluster . . . . . . . . . . . . . . . . . . . . . 2.1 Logical Representation of a Windows Cluster in BEX . . . . . . . . . . . . . . . 2.1 Setting Up a Windows Cluster to Use BEX . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Configuring BEX for Windows Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 MS SQL Server and MS Exchange Support in Clusters . . . . . . . . . . . . . . . . . 2.6 Considerations for SQL Server Restores in a Cluster . . . . . . . . . . . . . . . . 2.6 MS Exchange Folder Level Setup in a Cluster . . . . . . . . . . . . . . . . . . . . . 2.6 BEX Windows Cluster Support in a SAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Backup and Restore for Windows Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 Manual Setup Procedure for Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9 NetWare 6.x Clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Introduction to NetWare 6.x Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 A NetWare 6.x Cluster Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Physical Representation of a NetWare 6.x Cluster . . . . . . . . . . . . . . . . . . 3.1 Logical Representation of a NetWare 6.x Cluster in BEX . . . . . . . . . . . . 3.2 Setup and Configuration of NetWare 6.x Clusters . . . . . . . . . . . . . . . . . . . . . 3.3 Before Starting Cluster Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Installation for NetWare Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Configuration of BEX for NetWare Clusters . . . . . . . . . . . . . . . . . . . . . . . 3.4 Post-Setup Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 BEX NetWare Cluster Support in a SAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Backup and Restore for NetWare Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Novell OES Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Introduction to Novell Open Enterprise Server (OES) Clusters . . . . . . . . . . 4.1 A Novell OES Cluster Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Physical Representation of a Mixed OES Cluster . . . . . . . . . . . . . . . . . . . 4.1 Logical Representation of a Mixed OES Cluster in BEX . . . . . . . . . . . . . 4.2 Setup and Configuration of OES Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Before BEX Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 BEX Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Configuration of BEX for OES Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Post-Setup Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 BEX Cluster Support in a SAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Backup and Restore for Open Enterprise Server (OES) Clusters . . . . . . . . . 4.7

Chapter 2.

Chapter 3.

Chapter 4.

BEX 3.4 Cluster Support Syncsort Incorporated 2010

ii

BEX 3.4 Cluster Support Syncsort Incorporated 2010

Chapter 1. Introduction to Cluster Support

Clustering Overview
Clustering is the use of multiple computers and redundant interconnections to form what appears to be a single, highly available system. Clustering ensures that when a computer unexpectedly fails or is intentionally taken down, the processes and services it is running fail over to another machine in the cluster without interruption or the need for immediate user intervention. When a cluster is set up, shared resources can be seen from all computers, or nodes, in the cluster. Each node instantly senses if another node in the cluster has failed, and processes running on the failed node continue to run on an operational one. To the user, this failover is usually transparent. Note: Cluster Support is an optional, separately licensable BEX feature. For licensing information, contact your BEX Sales representative.

BEX Cluster Support

BEX supports File mode backups and restores of clusters, including shared resources, for Windows, NetWare, and Novell Open Enterprise Server (OES). BEX also supports clusters for MS Exchange and MS SQL Server on Windows. For File mode backups, if a failover occurs during backup of a shared resource, the backup task first fails, then BEX retries the task through an available node. Because the resource runs on an available node, the task completes successfully. In addition, BEX supports Advanced Recovery mode backups and restores of clusters for Windows 2003, including Exchange 2003 and SQL Server 2000/2005. However, failover during Advanced Recovery backups and restores is not supported. BEX fully supports client nodes in clusters. BEX supports device servers in a clustered environment when devices are accessed via a SAN or when all or some nodes have locallyattached devices. A combination of local and SAN devices is not supported. The following chapters describe BEX cluster support: Chapter 2. Windows Clusters Chapter 3. NetWare 6.x Clusters Chapter 4. Novell OES Clusters

For current information about operating system, file system, and hardware compatibility, see: http://www.syncsort.com/pdf/bex_compatibility_guide.pdf.

BEX 3.4 Cluster Support Syncsort Incorporated 2010

1.1

Chapter 1.

1.2

BEX 3.4 Cluster Support Syncsort Incorporated 2010

Chapter 2. Windows Clusters

Introduction to Windows Clusters
BEX supports File mode backups and restores of clusters for Windows 2000/2003. BEX supports Advanced Recovery for SnapVault backups and restores of clusters for Windows 2003. BEX supports Advanced Recovery for Open Storage backups and restores of clusters for Windows 2003. BEX also supports both MS SQL Server and MS Exchange in a Windows cluster. For Windows, BEX is a cluster aware application, ensuring that data on a shared disk is not backed up twice (from two different nodes in a cluster). Tip: Windows Server 2003 users that have cluster configurations are urged to apply Windows Server 2003 Service Pack 1 (SP1) or higher.

Physical Representation of a Windows Cluster

A simple cluster is illustrated below. Each of two physical computers (Node X and Node Y) contains two local disks (C: and D: in each case). Also, the two computers share two disks (G: and H:) via a single shared connection. Though not shown in the illustration, each of the computers is instantly able to sense if the other has failed or is down.

C:

Node X G: Shared Connection H:

D:

C:

Node Y

D:

Logical Representation of a Windows Cluster in BEX

In BEX, you define nodes and node groups. For a Windows cluster, you define physical nodes for the client machines and a single virtual node for the shared resources. All the nodes

BEX 3.4 Cluster Support Syncsort Incorporated 2010

2.1

Chapter 2. (physical and virtual) must be members of the same node group. A node group for a cluster must contain all the nodes for that cluster and no other nodes. The following illustration shows a logical representation for the cluster depicted in the topic above. You define two physical nodes (Node X and Node Y) and one virtual node (BexClus). The virtual node contains all the shared resources (G: and H:). Logically then, the cluster node group simply contains three nodes: Node X, Node Y, and BexClus. Each of the three nodes contains two disks.

Backup Express Node Group G:

BexClus

H:

C:

Node X

D:

C:

Node Y

D:

All shared resources (for example, files on shared disks, MS Exchange, MS SQL Server) are viewed by BEX as local resources of the virtual node. This concept is illustrated by the following extract from a BEX File Backup window. In this depiction, WIN2003CLUST2 and WIN2003CLUST3 are physical nodes and BEX_W2K3CLUST is the virtual cluster node. Q:, SQL$SQL2K5SRV:, X:, Y:, and Z: are shared resources. W2K3CLUST is the node group.

2.2

BEX 3.4 Cluster Support Syncsort Incorporated 2010

With this structure, BEX ensures that backups of the shared resources are performed through the virtual node and backups of local resources are performed through the physical nodes. For File mode backups, if a failover occurs during backup of a shared resource, the backup task first fails, then BEX retries the task through an available node. Because the resource runs on an available node, the task completes successfully. For Advanced Recovery for SnapVault backups, failover during backup results in an unsuccessful backup job. The user must rerun the job or wait until the next scheduled instance of that job.

Setting Up a Windows Cluster to Use BEX

Your Windows cluster is automatically set up to work with BEX during installation of BEX client software. The cluster must already be created by using Microsoft Cluster Administrator. For client installation on a cluster node, follow the steps in Installing on Windows on page 2.2 of the BEX Installation Guide. The following are additional considerations for setting up the cluster to work with BEX: Install BEX client software in the same folder and same partition on all physical nodes in the cluster. For example: c:\Program Files\BEX BEX must not be installed on a shared disk.

BEX 3.4 Cluster Support Syncsort Incorporated 2010

2.3

Chapter 2. If you add a new node to a cluster later on, when installing BEX on that node, select Yes in response to the question Is this the last node in the cluster to install BEX?.

Note: BEX offers a standalone cluster setup utility, WinClusterConfigurator, which is documented in javautil.txt in the BEX document library.

Configuring BEX for Windows Clusters

The following procedure is automatically performed by BEX. However, if you need to manually configure the cluster for your BEX Enterprise, do the following from the BEX management console: 1. Open the Configure Enterprise window. 2. Add a dedicated node group for the cluster. See Adding a Node Group on page 2.11 in the BEX Configuration Guide. 3. Add one of the physical nodes in the cluster to the node group. See Adding a Node on page 2.14 in the BEX Configuration Guide. BEX scans the node. After scanning, the Unconfigured Cluster Nodes dialog box appears. 4. Select all of the unconfigured nodes. 5. Select the desired options. 6. Click OK. All of the nodes are added to the node group and are displayed as illustrated below.

2.4

BEX 3.4 Cluster Support Syncsort Incorporated 2010

BEX 3.4 Cluster Support Syncsort Incorporated 2010

2.5

Chapter 2.

MS SQL Server and MS Exchange Support in Clusters

BEX supports active-active and active-passive cluster configurations for MS SQL Server and MS Exchange. The following table indicates the supported versions:

File Mode Backup and Restore SQL Server Versions MS Exchange Versions SQL Server 7.0, 2000 on Windows 2000/ 2003 MS Exchange 5.5, 2000, 2003, 2007 on Windows 2000/2003

Advanced Recovery for SnapVault Backup and Restore SQL Server 2000/2005 on Windows 2003 MS Exchange 2003/ 2007 on Windows 2003

Advanced Recovery for Open Storage Backup and Restore SQL Server 2000/2005 on Windows 2003 MS Exchange 2003/ 2007 on Windows 2003

For a discussion of the BEX naming conventions for SQL Server and Exchange disks, see Chapter 8. SQL Server Interface and Chapter 9. Microsoft Exchange Interface in the BEX Interface Guide. For additional Advanced Recovery considerations and restrictions, see Chapter 5. Considerations for Clusters and Applications in the BEX Disk-to-Disk Guide.

Considerations for SQL Server Restores in a Cluster

On a cluster, you cannot run a SQL Server restore to a non-shared drive. To restore a SQL Server database to a new disk, the target disk must be added as a dependency to the SQL Server resource in the cluster administrator. To add a disk as a dependency to the SQL Server, the shared cluster disk must reside in the same group in the Cluster Administrator as the SQL Server resources.

MS Exchange Folder Level Setup in a Cluster

The procedures required to enable folder level backup and restore of Exchange 5.5, Exchange 2000, or Exchange 2003 servers are provided in Chapter 9. Microsoft Exchange Interface in the BEX Interface Guide. In a cluster that contains Exchange server(s), those procedures must be run on each physical cluster node in accordance with the following rules: 1. For each Exchange server in the cluster, run the MS Exchange Folder Level Setup procedures once on each cluster node. That is, if you have a four-node cluster with two Exchange servers, run the procedure twice on each node, for a total of eight times (4x2=8). This requires you to create the same two profiles on each server. 2. All of the Exchange servers in a given cluster must run under the same Administrator ID and password. Note: The MS Exchange Folder Level Setup procedures are documented in Chapter 9. Microsoft Exchange Interface in the BEX Interface Guide. Running the MS Exchange Folder Level Setup procedures is required only for folder-level operations. For cluster users BEX 3.4 Cluster Support Syncsort Incorporated 2010

2.6

interested in using BEX to manage Exchange servers at the database level only, there is no need to run these procedures. Note: If you are upgrading from a previous release of BEX and your BEX enterprise is already set up for folder level Exchange support, you should not need to execute these procedures. However, if all Exchange servers on a given cluster do not have identical profiles or the profiles do not have identical passwords, you must do the following: 1. Copy your EXMAPI_PROFILE registry entry, and modify the copied entry to include a _SERVERNAME extension, where SERVERNAME is a unique Exchange server name in a given cluster. 2. In the new EXMAPI_PROFILE_SERVERNAME and EXMAPI_PASSWORD_SERVERNAME registry entries, specify a common profile value and common password value for the various Exchange Servers on each cluster.

BEX Windows Cluster Support in a SAN

In a SAN configuration, you can back up shared cluster resources to shared SAN devices, and failover to alternate paths when the primary path fails is supported. You should define SAN device paths for all physical nodes in a cluster; but not for the virtual node. The following rules apply to cluster support in a SAN: All physical cluster nodes must have the same set of SAN devices defined for BEX. The BEX Device ID for any given SAN device must be identical on all cluster nodes.

To verify that the device paths are properly configured, use the BEX detect utility. Run detect from each physical cluster node. You must confirm that the same set of SAN devices are defined on each cluster node, and that the Device ID identifying each SAN device is the same for each node. To use the detect utility, go to the desired node and run the following from a command prompt: detect -q For example, if you had a cluster with two physical nodes that is part of a two tape drive SAN, run detect -q first on Node 1, then again on Node 2. The output might appear as follows: Detect Output for Node 1:

BEX 3.4 Cluster Support Syncsort Incorporated 2010

2.7

Chapter 2.
SCSI Devices found: -----------------Device Adapter File ID ------------ ------\\.\Tape0 2 \\.\Tape1 2 \\.\sync_sa0 2 \\.\Tape2 2

BUS --0 0 0 0

Target ID -----0 0 0 0

LUN --2 5 3 1

STATUS -----0 0 0 0

Device Type -----------------------Sequential Access Device Sequential Access Device Medium Changer Device Sequential Access Device

String --------------------SONY SDX-500C SONY SDX-500C BHTi 216 QUANTUM DLT8000 BEX Auto ---Yes Yes Yes Yes

Device File ------------------------\\.\Tape0 \\.\Tape1 \\.\sync_sa0 \\.\Tape2

Serial / Unique Number / Id -----------------------0000902585 0000911832 216B10 PXB34P3669

World Wide Name ------------------------20 0 0 50 13 b0 78 94 20 0 0 50 13 b0 78 94 20 0 0 50 13 b0 78 94

Detect Output for Node 2:

SCSI Devices found: -----------------Device Adapter Target Device File ID BUS ID LUN STATUS Type String ------------ ------- --- ------ --- ------ ------------------------ --------------------\\.\Tape0 2 0 0 2 0 Sequential Access Device SONY SDX-500C \\.\Tape1 2 0 0 5 0 Sequential Access Device SONY SDX-500C \\.\sync_sa0 2 0 0 3 0 Medium Changer Device BHTi 216 Device Serial / Unique BEX File Number / Id World Wide Name Auto ------------------------- ------------------------ ------------------------- ---\\.\Tape0 0000902585 20 0 0 50 13 b0 78 94 Yes \\.\Tape1 0000911832 20 0 0 50 13 b0 78 94 Yes \\.\sync_sa0 216B10 Yes

Confirm that both SAN Devices (Sony SDX-500C) are on both nodes. Use the Serial Number field to assure they are the same. Then confirm that the Device ID for each of the two SAN Devices is identical on Node 1 and Node 2. The Device ID is in the Device File field. In this example, \\.\Tape0 is the Device ID for the drive whose serial number is 0000902585; and \\.\Tape1 is the Device ID for the drive whose serial number is 0000911832. This is true for both nodes, so you have a valid SAN setup for the cluster. ( \\.\Tape2 is a locally attached drive for Node 1. \\.\sync_sa0 is the robotic arm.) Note: Using a cluster node to control the robotic arm is not recommended. If detect shows that your SAN/cluster setup is not valid, reconfigure the paths between cluster nodes and SAN devices as needed.

Backup and Restore for Windows Clusters

Define backup jobs as described in Chapter 2. Backup in the BEX Operations Guide. If the cluster has been properly configured, BEX ensures that local disks are backed up through physical nodes and shared disks through virtual nodes.

2.8

BEX 3.4 Cluster Support Syncsort Incorporated 2010

When restoring, if the cluster resource is intact, restore data as you normally would. If the cluster is not intact, restore to a new location. The following considerations apply to Windows Cluster backup and restore: For Advanced Recovery for SnapVault backups and restores through virtual nodes, failover during the BEX job is not supported. When backing up Windows virtual nodes, the following two job options should be increased from a value of 1 (the default) to a value of 5: Down Node Retries (increase from 1 retry to 5 retries). Task Retry Intervals (increase from 1 minute to 5 minutes).

For more information about these job options, see Job Source Options for File Backup on page C.2 of the BEX Operations Guide.

Manual Setup Procedure for Clusters

The following manual setup procedure is included for troubleshooting purposes only. Because all the steps described are performed automatically during installation of BEX client software on your physical cluster nodes, you should not need to execute this procedure. Note that the procedure might vary slightly, depending on your network and cluster implementation. 1. Install BEX client software in the same folder and same partition on all physical nodes in the cluster. For example: c:\Program Files\BEX BEX must not be installed on a shared disk. 2. In the bin directory of BEX, execute the command shutcm.exe. This stops the communication agent service so that its properties can be modified. 3. BEX installation installs cmagent and creates the Windows registry entry for each physical node. Check to ensure that it was correctly installed by reviewing the services under Administrative Tools > Services and reviewing the data in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Syncsort\BackupExpress\hostname\0. If the key was incorrectly installed, you can install the service by doing the following: a. If necessary, create the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Syncsort\BackupExpress\hostname\0. b. Run the following command from the tools folder of BEX: bexsvc.exe --ins --name CMAGENTservicehostname0 --args --SSICMENV BackupExpress\hostname\0 --acc MyDomain\MyAdministrator --pass

BEX 3.4 Cluster Support Syncsort Incorporated 2010

2.9

Chapter 2. MyPassword --path c:\Program Files\BEX\bin\cmagent.exe --mode auto This command inserts CMAGENTservicehostname0 in the list of services on the node. Remember to repeat this step on every physical node in the cluster. For usage notes, execute bexsvc.exe --help. The SSICMAPI variable is in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Syncsort\BackupExpress\hostname\0. The following is an example of a registry entry: Name SSICMAPI Data -sbs 65535 -tnd -hn 71.100.200.10

4. Install an additional communication agent service on each physical node in the cluster. This becomes the communication agent for the virtual node. To install the service, create the registry entry: HKEY_LOCAL_MACHINE\SOFTWARE\Syncsort\BackupExpress\virtual_node_name \0 and run the following command from the tools folder of BEX on each physical node in the cluster: bexsvc.exe --ins --name CMAGENTservicevirtual_node_name0 --args -SSICMENV BackupExpress\virtual_node_name\0 --acc MyDomain\MyAdministrator --pass MyPassword --path c:\Program Files\BEX\bin\cmagent.exe --mode man This command inserts CMAGENTservicevirtual_node_name0 in the list of services on the node. Remember to repeat this step on every physical node in the cluster. For usage notes, execute bexsvc.exe --help. The following guidelines apply for installation of the communication agent for the virtual node: The naming convention for this additional communication agent service is CMAGENTservicevirtual_node_name0. For the environmental variable, the convention is SSICMAPI. CMAGENTservicevirtual_node_name0 and SSICMAPI must be replicated exactly on every physical node in the cluster.

5. Assign a new, unused IP address to the virtual node. This must be an available public network address that will be bound to the public network NIC. To do this, in the Windows registry of each physical node, append the hostname flag -hn virtual_IP_address to the SSICMAPI variable that you associated with CMAGENTservicevirtual_node_name0. This variable is in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Syncsort\BackupExpress\virtual_node_name \0. The following is a registry entry example for this step: Name SSICMAPI Data -sbs 65535 -tnd -hn 71.100.200.11

2.10

BEX 3.4 Cluster Support Syncsort Incorporated 2010

The data value for SSICMAPI should be identical except for the IP address. 6. Set up BEX as part of a Microsoft managed (Windows) cluster by using the Microsoft Cluster Administrator. In this step, you organize BEX as a separate group called BEX, and you add BEX IP Address, BEX Network Name, and BEX Cmagent resources to that group. You can do this from the Cluster Management console or from the command line on any of the physical cluster nodes. Each of these options is described below. Option 1. Cluster Management Console From the Cluster Management Console, do the following: a. Organize the virtual nodes in the cluster as a separate group called BEX. Make sure this group is owned by all physical nodes. b. Add the BEX IP Address to the group BEX as an IP Address resource type. Make sure you use the same IP Address that you specified for SSICMAPI. c. Add the BEX Network Name to the group BEX as a Network Name resource type. The BEX Network Name resolves the IP address you have given to the virtual node. d. Add the BEX Cmagent for the virtual nodes to the group BEX as a Generic Service resource type. Use the service name CMAGENTservicevirtual_node_name0. Note: In the steps above, you must not change names that are in bold typeface. Bring the BEX group online. Option 2. Command Line From the command line of any physical cluster node, enter a series of cluster commands. Follow the example below. The example makes the following assumptions: NodeX and NodeY are the names of the physical nodes in the cluster. BexClus is the name of the virtual node. 71.100.100.113 is the IP address of the virtual node.

BEX 3.4 Cluster Support Syncsort Incorporated 2010

2.11

Chapter 2.

Example of Commands for Setting Up a Windows Cluster with BEX

Enter the following from any physical cluster node (NodeX or NodeY in this example):
cluster group BEX/create cluster group BEX/prop description= Syncsorts BEX cluster group BEX/setowners:NodeX,NodeY cluster resource BEX IP Address/create/group:BEX /type:IP Address cluster resource BEX IP Address/priv Address=71.100.100.113 cluster resource BEX IP Address/priv SubnetMask=255.255.255.0 cluster resource BEX IP Address/priv NetWork=PUB cluster resource BEX Network Name/create/group:BEX /type:Network Name cluster resource BEX Network Name/priv Name=BexClus cluster resource BEX Network Name/adddep:"BEX IP Address cluster resource BEX Cmagent/create/group:"BEX /type:"Generic Service cluster resource BEX Cmagent/adddep:BEX Network Name cluster resource BEX Cmagent/privproperties ServiceName= CMAGENTBexClus0 cluster group BEX/online

The last command brings the BEX group online.

2.12

BEX 3.4 Cluster Support Syncsort Incorporated 2010

Chapter 3. NetWare 6.x Clusters

Introduction to NetWare 6.x Clusters
For NetWare 6.x, BEX is a cluster aware application, ensuring that data on a shared storage pool is not backed up twice (from two different nodes in a cluster). During backup of a NetWare 6.x shared storage pool, if the node owning the resource fails over to another node in the cluster, BEX retries the task and completes the backup job. BEX fully supports NetWare client nodes in clusters. BEX supports NetWare device servers in a clustered environment when devices are accessed via a SAN or when all or some nodes have locally-attached devices. A combination of local and SAN devices is not supported.

A NetWare 6.x Cluster Example

Physical Representation of a NetWare 6.x Cluster
A simple NetWare cluster is illustrated below. Each of two physical computers (Node X and Node Y) contains a local disk (SYS: in each case). Also, the two computers, or client machines, share two NetWare storage pools (P1 and P2) via a single shared connection. Note that P2 is a partitioned storage pool, consisting of two volumes. Though not shown in the illustration, each of the two client machines is instantly able to sense if the other has failed or is down.

NetWare

SYS:
Node X
71.10.10.11

VOL1: P1
Shared Connection

VOL2: VOL3: P2

NetWare

SYS:
Node Y
71.10.10.12

BEX 3.4 Cluster Support Syncsort Incorporated 2010

3.1

Chapter 3.

Logical Representation of a NetWare 6.x Cluster in BEX

In BEX, you define nodes and node groups. For a NetWare 6.x cluster, you define physical nodes for the local storage and a single virtual node for the shared storage. The following rules apply to defining NetWare 6.x cluster nodes in BEX: For each client machine, one physical node must be defined to represent all local volumes on that machine. Thus, for the example above, you define two physical nodes. One virtual node must be defined for the cluster. All shared storage resources are backed up through this virtual node. For NetWare 6.x, each shared storage pool is considered to be a shared resource. All the nodes (physical and virtual) for a cluster must be members of the same BEX node group.

The following illustration shows a logical representation for the NetWare 6.x cluster represented in the section above:

BEX Node Group

NetWare

SYS:
Node X
71.10.10.11

P1 VOL1:

VOL2:
Node V1
71.10.10.21

VOL3: P2

NetWare

SYS:
Node Y1
71.10.10.12

The BEX Node Group contains two physical nodes (Node X and Node Y) and one virtual nodes (Node V1). The virtual node contains the shared resources (P1 and P2). Logically then, the cluster group simply contains three nodes: Node X, Node Y, and Node V1. Each of the three nodes contains one or more storage pools or disks. All shared resources are viewed by BEX as local resources of the virtual node. With this structure, BEX ensures that backups of the shared resources are performed through the virtual node and backups of local resources are performed through the physical nodes.

3.2

BEX 3.4 Cluster Support Syncsort Incorporated 2010

If a physical cluster node fails over to another node in the cluster during backup of a shared resource, BEX continues to execute the backup by retrying the task through the failover node.

Setup and Configuration of NetWare 6.x Clusters

Before Starting Cluster Setup
The sections below outline the procedure for setting up a NetWare cluster to work with BEX. Before starting, the cluster must be generated (by using NetWare Clustering Services) with a unique IP address for each physical node. Before installing BEX client software on the cluster nodes, do the following: 1. Ensure that Open File Manager and Norton AntiVirus are loading in the proper order. 2. In the autoexec.ncf file, confirm that LDNCS.NCF appears before SMSSTART.NET. 3. Confirm adequate NetWare licensing for each machine in the cluster by using iManager or ConsoleOne with the right snap-in module. 4. Ensure that the SYS:ETC/HOSTS file contains entries for all virtual resource IP addresses. 5. Identify the location of the clusters master server IP address using the Cluster Resources utility. 6. Run the NetWare utility SBCON and confirm that you can connect to all TSAs using the same ID and password used during BEX node configuration. For NetWare 6.x nodes, the following rules apply: TSA600 must be running on each physical cluster node in order to support File System backup. /cluster off should not be set. SLPDA must be properly configured in the Enterprise and needs to advertise cluster SMDRS.

Installation for NetWare Clusters

On each physical node in the cluster, install BEX client software in the same location. For example: SYS:BACKEX Note: BEX must not be installed on a shared disk.

BEX 3.4 Cluster Support Syncsort Incorporated 2010

3.3

Chapter 3. To perform the installation, run the NetWare Installation Services (NIS) program from your BEX CD-ROM as follows: 1. On the server console, make sure that CDROM.NLM is loaded. If not, load it from the prompt. 2. Insert the BEX CD-ROM. Switch to the X GUI screen and click on the Novell button on the taskbar. Select Install. A screen displaying all the installed products on the server appears. 3. Click on Add. A screen appears asking where you want to install the software (default is SYS:BACKEX). Accept the default, type in a different path, or click on the browse button to navigate down the directory tree to select a different location. 4. Accept the license agreement and continue through other screens. A progress bar appears indicating the progress of files being copied to your volume. 5. Read the README file. When installation is completed on all physical cluster nodes, bring the shared resource offline, then online. During installation, the following tasks are accomplished. You do NOT need to manually execute these three tasks. 1. The host address of the each physical node is registered. The environmental variable SSICMAPI is appended with the hostname flag -hn local_IP_address. 2. In AUTOEXEC.NCF, a BEX specific module, BEXNW.NCF, is loaded. BEXNW.NCF includes load statements for the modules iflibd.nlm, bexbeat.nlm and cmagent.nlm. This sets up the communication agent. Also, the module SHUTBEX.NCF is created. Usage of SHUTBEX.NCF is described later in this chapter. 3. The IP address of the cluster master IP resource is assigned to the virtual node. The virtual node is mapped to each physical node in the cluster. 4. The cluster is configured for BEX. Each physical node and a single virtual node are added to a BEX node group.

Configuration of BEX for NetWare Clusters

If you need to manually configure the cluster for BEX, do the following from the BEX management console: 1. Open the Configure Enterprise window. 2. Add a dedicated node group for the cluster. See Adding a Node Group on page 2.11 in the BEX Configuration Guide. 3. Add one of the physical nodes in the cluster to the node group. See Adding a Node on page 2.14 in the BEX Configuration Guide.

3.4

BEX 3.4 Cluster Support Syncsort Incorporated 2010

The Input logic node name for physical_node_name dialog box appears. 4. Enter a logical name for the node or leave the logical name the same as the physical. 5. Click OK. The Input Authentication Information dialog box appears. 6. Enter the name and password for the TSA. 7. Click TEST. The test confirmation box appears. 8. Click OK. BEX scans the node. After scanning, the Unconfigured Cluster Nodes dialog box appears. 9. Select all of the unconfigured nodes. 10. Select desired options. 11. Click OK. The Input Authentication Information dialog box appears. 12. Enter the name and password for the TSA. 13. Click TEST. The test confirmation box appears. 14. Click OK. 15. Repeat steps 9 through 14 until all physical nodes are installed. All of the nodes are added to the node group and are displayed as illustrated below.

BEX 3.4 Cluster Support Syncsort Incorporated 2010

3.5

Chapter 3.

Post-Setup Procedures
Run the BEX utility VerifyNetWareSMDRs to verify your BEX NetWare node configuration. For information about this utility, see NetWare Node Configuration Verification on page 2.21 in the BEX Configuration Guide.

BEX NetWare Cluster Support in a SAN

In a SAN configuration, you can back up shared cluster resources to shared SAN devices, and failover to alternate paths when the primary path fails is supported. You should define SAN device paths for all physical nodes in a cluster. That is, all physical nodes in the cluster must have the same set of SAN devices defined for BEX.

Backup and Restore for NetWare Clusters

Define backup jobs in the usual way (see Chapter 2. Backup in the BEX Operations Guide). If the cluster has been properly configured, for NetWare 6.x clusters, BEX ensures that local disks are backed up through physical nodes and shared disks through the virtual node. For NetWare 6.x nodes, the following rules apply: TSA600 must be running on each physical cluster node in order to support File System backup. /cluster off should not be set. SLPDA must be running on one physical cluster node. TSANDS must be running on one physical cluster node in order to view or back up your NDS tree. DOSFAT.NSS should be loaded if the DOS partition needs to be backed up. The DOS partition will appear as a NetWare volume. GWTSA should be running on any physical nodes that have the GroupWise application. Note that GroupWise is not a cluster aware application.

When restoring, if the cluster is intact, restore data as you normally would. If the cluster is not intact, restore to a new location.

3.6

BEX 3.4 Cluster Support Syncsort Incorporated 2010

Chapter 4. Novell OES Clusters

Introduction to Novell Open Enterprise Server (OES) Clusters
BEX supports clusters for Novell OES. The physical cluster nodes can be any combination of OES NetWare nodes and OES Linux nodes. A cluster that contains both OES NetWare and OES Linux nodes is referred to as a mixed OES cluster. For OES, BEX is a cluster aware application, ensuring that data on a shared storage pool is not backed up twice (from two different nodes in a cluster). If a failover occurs while a BEX job is running, BEX automatically retries any failed tasks, and the job successfully completes. Note: In this chapter, all references to OES also apply to OES2, both 32-bit and 64-bit.

A Novell OES Cluster Example

Physical Representation of a Mixed OES Cluster
A simple mixed OES cluster is illustrated below.

Each of three physical computers (Node X, Node Y, and Node Z) contains a local disk. Node X is an OES NetWare node, Node Y is an OES Linux node with NSS file system, Node Z is an OES Linux node with a traditional Linux file system. In addition, the three computers, or client machines, share two storage resources (VOL1 and VOL2) via a single shared connection. (A shared resource can be a storage pool or storage volume.) Though not shown in the illustration, each of the three client machines is instantly able to sense if another has failed or is down.

BEX 3.4 Cluster Support Syncsort Incorporated 2010

4.1

Chapter 4.

Logical Representation of a Mixed OES Cluster in BEX

In BEX, you define nodes and node groups. For a mixed OES cluster, you define physical nodes for the local storage resources and a single virtual node for the shared storage resources. The following rules apply to defining OES cluster nodes in BEX: For each client machine, one physical node must be defined to represent all local volumes on that machine. Thus, for the example above, you define three physical nodes, one for each client machine. One virtual node must be defined for the cluster. All shared storage resources are backed up through this virtual node. All the nodes (physical and virtual) for a cluster must be members of the same BEX node group.

The following illustration shows a logical representation for the mixed OES cluster represented in the example above:

The BEX Node Group contains three physical nodes (Node X, Node Y, and Node Z) and one virtual nodes (Node V1). The virtual node contains the shared resources (VOL1 and VOL2). Logically then, the cluster group simply contains four nodes: Node X, Node Y, Node Z, and Node V1. Each of the four nodes contains one or more storage pools or disks.

4.2

BEX 3.4 Cluster Support Syncsort Incorporated 2010

All shared resources are viewed by BEX as local resources of the virtual node. With this structure, BEX ensures that backups of the shared resources are performed through the virtual node and backups of local resources are performed through the physical nodes. This concept is illustrated by the following extract from a BEX Backup File window.

In this depiction: OES-CLUSTER is the node group cluster is the virtual cluster node V1: is a shared resource oes-lx-c1, oes-lx-c2, and OES-NWA are physical nodes.

If a physical cluster node fails during backup of a shared resource, BEX continues to execute the backup by retrying the task through the failover node.

BEX 3.4 Cluster Support Syncsort Incorporated 2010

4.3

Chapter 4.

Setup and Configuration of OES Clusters

Before BEX Installation
Before installing BEX client software on the cluster nodes, do the following: Create the cluster by using Novell Clustering Services (NCS) with a unique IP address for each physical node. Be sure to follow the guidelines and recommendations from Novell. To create a mixed OES cluster, it is a Novell requirement that OES Linux nodes must be added to an already established, fully configured OES NetWare cluster. For details, refer to Novell's documentation and online resources at www.novell.com. Note: Use of default NCS settings are generally suitable for BEX purposes, but System Administrators are advised to use their expertise for performance tuning in accordance with Novell guidelines. Tip: For further details, see Setup and Configuration of NetWare 6.x Clusters on page 3.3.

BEX Installation
On each physical node in the cluster, install BEX client software in the default location. BEX client software must not be installed on a shared disk. To perform installation: Use the BEX Installation CD-ROM. Follow the instructions in Chapter 2. Local Installation in the BEX Installation Guide.

During installation, the IP address of the Cluster Master IP Address resource is assigned to the virtual node. The virtual node is mapped to each physical node in the cluster. At the conclusion of installation, each physical node and the single virtual node must be added to a BEX node group. See Configuration of BEX for OES Clusters on page 4.4.

Configuration of BEX for OES Clusters

If you need to manually configure the cluster for your BEX Enterprise, do the following from the BEX management console: 1. Open the Configure Enterprise window. 2. Add a dedicated node group for the cluster. See Adding a Node Group on page 2.11 in the BEX Configuration Guide. 3. Add the clusters virtual node to the node group in the usual way for adding a node. See Adding a Node on page 2.14 in the BEX Configuration Guide.

4.4

BEX 3.4 Cluster Support Syncsort Incorporated 2010

Youll need to enter a logical name and an IP address for the virtual node. For the IP address, use the Cluster Master IP Address which was created automatically during Cluster Services installation. You can identify the Cluster Master IP Address by using Novell Clustering Services (NCS). Note: The clusters virtual node must be added before the physical nodes. 4. On the Add Node dialog, click ADD. The Input Authentication Information dialog box appears. 5. Enter the user name and password required to log in to the Novell eDirectory tree. For OES Linux nodes, the root password is also requested. 6. Click OK. BEX scans the node. After scanning, the Unconfigured Cluster Nodes dialog box appears, listing all unconfigured cluster nodes. 7. Select all unconfigured cluster nodes by using CTRL-click to select multiple nodes or SHIFT-click to select a range of nodes. 8. Select desired options. 9. Click OK. For each node, the Input Authentication Information dialog box appears. a. Enter the user name and password required to log in to the OES node. For OES Linux nodes, the root password is also requested. b. Click TEST. A test confirmation box appears. c. Click OK. All of the nodes are added to the node group and are displayed as illustrated below.

BEX 3.4 Cluster Support Syncsort Incorporated 2010

4.5

Chapter 4.

Post-Setup Procedures
Run the BEX utility VerifyNetWareSMDRs to verify your BEX OES node configuration. For information about this utility, see NetWare Node Configuration Verification on page 2.21 in the BEX Configuration Guide.

BEX Cluster Support in a SAN

In a SAN configuration, you can back up shared cluster resources to shared SAN devices, and failover to alternate paths when the primary path fails is supported. You should define SAN device paths for all physical nodes in a cluster. That is, all physical nodes in the cluster must have the same set of SAN devices defined for BEX. BEX 3.4 Cluster Support Syncsort Incorporated 2010

4.6

Backup and Restore for Open Enterprise Server (OES) Clusters

Define backup jobs in the usual way (see Chapter 2. Backup in the BEX Operations Guide). If the cluster has been properly configured, for OES clusters, BEX ensures that local disks are backed up through physical nodes and shared disks through the virtual node. Note: For clustered nodes, the appropriate TSA(s) and SMDR must be running. When restoring, if the cluster is intact, restore data as you normally would. If the cluster is not intact, restore to a new location. Tip: For further details, see Backup and Restore for NetWare Clusters on page 3.6.

BEX 3.4 Cluster Support Syncsort Incorporated 2010

4.7

Chapter 4.

4.8

BEX 3.4 Cluster Support Syncsort Incorporated 2010