B.4 Novell SAN Management Interface

The Novell SAN Management Interface (NSMI) is used by the BCC to communicate with and control the attached SAN device. This happens during a BCC failover when the LUNs must be promoted from Secondary to Primary in order to online the cluster resource. An example of LUN promotion is masking the LUN to make it visible to the cluster that is the failover target.

This section covers the following topics:

In order for a SAN manufacturer to be NSMI compliant, it must support a management interface that can be executed from one of the cluster nodes (for example, in a NetWare environment). Perl or Java interfaces or an NLM that implements a command line interface (CLI) for the SAN vendor are examples of compliant interfaces.

Generally, the only interfaces needed by the BCC are to mask or unmask LUNs and to break or create mirrors. One script is needed for each BCC resource on each SAN. As an example, an NSMI script could be written that performs the following tasks for a single BCC resource. This script would be executed by the NSMI when the BCC fails over the BCC resource from the primary cluster to the secondary cluster.

However, the actual NSMI script you write depends upon the BCC functionality you actually require for your cluster environment. It is recommended that you consult the professional services organization of your SAN vendor for further details.

B.4.1 NSMI Scripting

The NSMI is a scripting environment. You create a script for each BCC resource and the BCC uses the NSMI to execute that script during a BCC failover of that resource. Comments are added to the script by preceding them with the pound (#) sign. Furthermore, the NSMI supports script tokens that are replaced with actual values at runtime right before the script is executed.

IMPORTANT:Be careful when using these tokens because they may not always return the proper data. This can occur when NSS has never seen the LUN before (that is, on the secondary cluster). In this case, NSS has never seen the LUN and therefore does not know about the pools and volumes. This leads to missing data for some of the tokens. For example, the %pool% token would return an empty string.

This section contains the following topics:

NSMI Scripting Tokens

The following table lists the valid tokens:

Token Name

Description

%pool%

The token for the current NSS pool name.

%target%

Returns the target associated with the pool. If there are multiple targets, returns the first target.

%lun%

Returns the LUN associated with the pool. If there are multiple LUNs, returns the first LUN.

%deviceCount%

Returns the number of devices associated with the pool.

%targetList%

Returns a comma-separated list of targets (e.g. 1, 2, 5, 9) associated with this pool.

%lunList%

Returns a comma-separated list of LUNs (e.g. 1, 2, 5, 9) associated with this pool.

%paramFile%

Returns the name of the parameter file. All parameters are also saved to this file as XML.

%signalFile%

The name of the signal file the NSMI will wait for.

%version%

The version of the NSMI. In the form of major.minor.build (for example, 1.0.20040301).

NSMI Script Interpreter

If the first line of the script contains #!, the rest of the line specifies the script interpreter. For example, "#!perl -w" uses Perl as the script interpreter and passes the "-w" switch directly to the perl interpreter. If the #! line is missing, the script is assumed to be a NetWare NCF file.

NSMI Scripting Parameters

If the first or second line contains #@, then the rest of the line specifies parameters for the NSMI. The following table list valid NSMI parameters:

Parameter

Description

-wnnn

Delay for nnn seconds before completing execution of the NSMI script.

-s0

Do not wait for a signal file specifying completion of the NSMI script. If a delay is specified via the -w parameter, then the NSMI will delay for the given number of seconds.

-s1

Wait for a signal file specifying completion of the NSMI script. The signal file is given via the token %signalFile%. The NSMI will continue when the signal file is created regardless of any delay specified with the -w parameter.

-1

Forces the NSMI to execute scripts synchronously. Normally, the NSMI executes scripts asynchronously, meaning that several scripts can run at the same time. This switch turns off that behavior.

Perl Script Control Sample

The following psuedo code example shows how to control a generic SAN. Note the following about the script:

  • This script will not compile and is meant only as an example. An appropriate script (not necessarily Perl) will need to be used to control the SAN. Consult your SAN vendor for further information.

  • The Perl script identification is designated in the first line (#!perl -w --noscreen).

  • The NSMI parameters -s1 -w120 -1 are passed in on the second line (#@ -s1 -w120 -1). These parameters tell the NSMI to delay for a maximum of 120 seconds, wait for the signal file to notify of completion, and to run the script synchronously.

  • The Perl END section is used to create the signal file which notifies the NSMI of script completion.

 #!perl -w --noscreen
 #@ -s1 -w120 -1
 #
 # This is a psuedo code Perl script example that shows how to use
 # the NSMI scripting interface to control a SAN via the Novell
 # Business Continuity Cluster (BCC). The functionality in this
 # script will need to be replaced with the correct calls to control
 # the SAN. Furthermore, errors are not properly handled in this
 # script.
 #
 # THIS SCRIPT WILL NOT COMPILE AND IS MEANT ONLY AS AN EXAMPLE.
 
 package Novell_Psuedo_Code_Script;
 use lib ".";
 use MySANVendorLibrary;
 use strict;
 use warnings;
 use IO::Handle;
 
 # Old Disk Configuration
 my $OLD_SAN = 1; # SAN ID
 my $OLD_WORKSET = 0; # Workset number
 my $OLD_VBLOCK = 0; # VBlock number
 my @OLD_WORKPORT = (38, 46); # Workport list
 my $OLD_VDISK = 3; # iFolder1
 my $OLD_LUN = 3; # The LUN number I wish to have
 my $OLD_VLINK = 21; # The source link to the new SAN
 my $OLD_TARGET_VDISK = 11; # The target vlink on this SAN
 
 # New Disk Configuration
 my $NEW_SAN = 2; # SAN ID
 my $NEW_WORKSET = 0; # Workset number
 my $NEW_VBLOCK = 0; # VBlock number
 my @NEW_WORKPORT = (0, 2); # Workport list
 my $NEW_VDISK = 3; # iFolder1
 my $NEW_LUN = 3; # The LUN number I wish to have
 my $NEW_VLINK = 21; # The source vlink to the old SAN
 my $NEW_TARGET_VDISK = 11; # The target vlink on this SAN
 
 ####################################################################
 # Unmask the old disk
 
 print "Managing SAN $OLD_SAN\n";
 
 Manage_San($OLD_SAN);
 Manage_WorkSet($OLD_WORKSET);
 Manage_VBlock($OLD_VBLOCK);
 Reserve_San($OLD_SAN);
 Manage_DiskGroup(0);
 Break_Mirror($OLD_VLINK);
 foreach my $workport (@OLD_WORKPORT)
 {
 Unmask_VDisk($workport, $OLD_VDISK);
 }
 
 Unreserve_San();
 
 ####################################################################
 # Mask the new disk
 
 print "Managing SAN $NEW_SAN\n";
 
 Manage_San($NEW_SAN);
 Manage_WorkSet($NEW_WORKSET);
 Manage_VBlock($NEW_VBLOCK);
 Reserve_San($NEW_SAN);
 Manage_DiskGroup(0);
 Break_Mirror($NEW_VDISK);
 
 foreach my $workport (@NEW_WORKPORT)
 {
 Mask_VDisk($workport, $NEW_LUN, $NEW_VDISK);
 }
 
 Mirror_VDisk($NEW_VDISK, $NEW_VLINK);
 Unreserve_San();
 
 ####################################################################
 # Refresh the old data on the old SAN
 ####################################################################
 
 Manage_San($OLD_SAN);
 Manage_WorkSet($OLD_WORKSET);
 Manage_VBlok($OLD_VBLOCK);
 Reserve_San($OLD_SAN);
 Manage_DiskGroup(0);
 Mirror_VDisk($OLD_TARGET_VDISK, $OLD_VDISK);
 Unreserve_San();
 
 ####################################################################
 # Tell BCC the script is done
 ####################################################################
 
 END
 {
 my $fh;
 open $fh, ">", "%signalFile%";
 }