=;The OpenVMS Frequently Asked Questions (FAQ)D

The OpenVMS Frequently Asked Questions (FAQ)



 r \ ^  
PreviousContentsIndex

K

15.6.7 How can I split up an OpenVMS Cluster?



?Review the VMScluster documentation, and the System Management Hdocumentation. The following are the key points, but are likely not the $only things you will need to change.

BOpenVMS Cluster support is directly integrated into the operating Csystem, and there is no way to remove it. You can, however, remote @site-specific tailoring that was added for a particular cluster configuration.

EFirst: Create restorable image BACKUPs of each of the current system Edisks. If something gets messed up, you want a way to recover, right?

FCreate standalone BACKUP kits for the OpenVMS VAX systems, and create >or acquire bootable BACKUP kits for the OpenVMS Alpha systems.

FUse CLUSTER_CONFIG or CLUSTER_CONFIG_LAN to remove the various system <roots and to shut off boot services and VMScluster settings.

CCreate as many architecture-specific copies of the system disks as Brequired. Realize that the new systems will all likely be booting Gthrough root SYS0---if you have any system-specific files in any other roots, save them.

HRelocate the copies of the VMScluster common files onto each of the new system disks.

HReset the console parameters and boot flags on each system for use on a standalone node.

GReset the VAXCLUSTER and NISCS_LOAD_PEA0 parameters to 0 in SYSGEN and in MODPARAMS.DAT.

:Clobber the VMScluster group ID and password using SYSMAN.

7Reboot the systems seperately, and run AUTOGEN on each.

@Shut off MOP services via NCP or LANCP on the boot server nodes.

HPermanent seperation also requires the duplication of shared files. For la list of the files commonly shared, please see Section 15.6.6.

BAlso see the topics on "cluster divorce" in the Ask The Wizard area.



HFor additional information on the OpenVMS Ask The Wizard (ATW) area and Bfor a pointer to the available ATW Wizard.zip archive, please see 0Section 3.8.

bInformation on changing node names is included in Section 5.7.B

15.6.8 Details on Volume Shadowing?



EThis section contains information on host-based volume shadowing; on 9the disk mirroring capabilities available within OpenVMS.c

15.6.8.1 Does volume shadowing require a non-zero allocation classes?



BYes, use of host-based Volume Shadowing requires that the disk(s) 6involved be configured in a non-zero allocation class.

<Edit SYS$SYSTEM:MODPARAMS.DAT to include a declaration of anHnon-zero allocation class, such as setting the host allocation class to the value 7:

 

"
ALLOCLASS = 7 




$Then AUTOGEN the system, and reboot.

HYou should now be able to form the shadow set via a command such as the following:

 

"
=$ MOUNT dsa1007: /SHADOW=($7$dkb300:,$7$dkb500:) volumelabel 




CWhen operating in an OpenVMS Cluster, this sequence will typically @change the disk names from the SCSNODE prefix (scsnode$dkann) toI the allocation-class prefix ($7$dkannn). This may provide you with the H opportunity to move to a device-independent scheme using logical name H constructs such as the DISK$volumelabel logical names in your startup D and application environments; an opportunity to weed out physical  device references.

FAllocation class one is used by Fibre Channel devices; it can be best Fto use another non-zero allocation class even if Fibre Channel is not /currently configured and not currently planned.




 ^ \  
IndexContents