f. OpenVMS FAQ -&- page 28)b @5z

HP OpenVMS Systems Documentation

 q> $"b,
Content starts here"D

The OpenVMS Frequently Asked Questions (FAQ)


 l n  
PreviousContentsIndex

K

15.6.7 How can I split up an OpenVMS Cluster?



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

AOpenVMS Cluster support is directly integrated into the operatingBsystem, and there is no way to remove it. You can, however, remote?site-specific tailoring that was added for a particular clusterconfiguration.

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

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

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

BCreate as many architecture-specific copies of the system disks asArequired. Realize that the new systems will all likely be bootingFthrough root SYS0---if you have any system-specific files in any otherroots, save them.

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

GReset the console parameters and boot flags on each system for use on astandalone node.

FReset the VAXCLUSTER and NISCS_LOAD_PEA0 parameters to 0 in SYSGEN andin 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.

GPermanent seperation also requires the duplication of shared files. For|a list of the files commonly shared, please see Section 15.6.6.

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



GFor additional information on the OpenVMS Ask The Wizard (ATW) area andAfor a pointer to the available ATW Wizard.zip archive, please see@Section 3.8.

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

15.6.8 Details on Volume Shadowing?



DThis section contains information on host-based volume shadowing; on9the disk mirroring capabilities available within OpenVMS.c

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



AYes, 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 anGnon-zero allocation class, such as setting the host allocation class to the value 7:

 

"
ALLOCLASS = 7




$Then AUTOGEN the system, and reboot.

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

 

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




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

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




 n l  
IndexContents

 

#6