 |
OpenVMS Cluster Systems
9.4.1 Booting from a Single LAN Adapter
To boot a satellite, enter the following command:
>>> BOOT LAN-adapter-device-name
|
In the example, the LAN-adapter-device-name could be any valid
LAN adapter name, for example EZA0 or XQB0.
If you need to perform a conversational boot, use the command shown in
the following table.
| IF the system is... |
THEN... |
|
An Alpha system
|
At the Alpha system console prompt (>>>), enter:
>>> b -flags 0,1 eza0
In this example, -flags stands for the flags command line
qualifier, which takes two values:
- System root number
The "0" tells the console to boot from the system root
[SYS0]. This is ignored when booting satellite nodes because the system
root comes from the network database of the boot node.
- Conversational boot flag
The "1" indicates that the boot should be conversational.
The argument eza0 is the LAN adapter to be used for booting.
Finally, notice that a load file is not specified in this boot command
line. For satellite booting, the load file is part of the node
description in the DECnet or LANCP database.
|
|
A VAX system
|
At the VAX system console prompt (>>>), specify the full
device name in the boot command:
>>>B/R5=1 XQB0
The exact syntax will vary depending on system type. Please refer
to the hardware user's guide for your system.
|
If the boot fails:
- If the configuration permits and the network database is properly
set up, reenter the boot command using another LAN adapter (see
Section 9.4.4).
- See Section C.3.5 for information about troubleshooting satellite
booting problems.
9.4.2 Changing the Default Boot Adapter
To change the default boot adapter, you need the physical address of
the alternate LAN adapter. You use the address to update the
satellite's node definition in the DECnet or LANCP database on the MOP
servers so that they recognize the satellite (described in
Section 9.4.4).
| IF the system is... |
THEN... |
|
An Alpha system
|
Use the SHOW CONFIG console command to find the LAN address of
additional adapters.
|
|
A VAX system
|
Use the following method to find the LAN address of additional adapters:
- Enter the console command SHOW ETHERNET.
- Boot the READ_ADDR program using the following commands:
>>>B/100 XQB0
Bootfile:READ_ADDR
|
9.4.3 Booting from Multiple LAN Adapters (Alpha Only)
On Alpha systems, availability can be increased by using multiple LAN
adapters for booting because access to the MOP server and disk server
can occur via different LAN adapters. To use multiple adapter booting,
perform the steps in the following table.
| Step |
Task |
|
1
|
Obtain the physical addresses of the additional LAN adapters.
|
|
2
|
Use these addresses to update the node definition in the DECnet or
LANCP database on some of the MOP servers so that they recognize the
satellite (described in Section 9.4.4).
|
|
3
|
If the satellite is already defined in the DECnet database, skip to
step 4. If the satellite is not defined in the DECnet database, specify
the SYS$SYSTEM:APB.EXE downline load file in the Alpha network database
(see Example 10-2).
|
|
4
|
Specify multiple LAN adapters on the boot command line. (Use the SHOW
DEVICE or SHOW CONFIG console command to obtain the names of adapters.)
|
The following command line is the same as that used for booting from a
single LAN adapter on an Alpha system (see Section 9.4.2) except that
it lists two LAN adapters, eza0 and ezb0, as the devices from which to
boot:
>>> b -flags 0,1 eza0, ezb0
|
In this command line:
| Stage |
What Happens |
|
1
|
MOP booting is attempted from the first device (eza0). If that fails,
MOP booting is attempted from the next device (ezb0). When booting from
network devices, if the MOP boot attempt fails from all devices, then
the console starts again from the first device.
|
|
2
|
Once the MOP load has completed, the boot driver starts the NISCA
protocol on all of the LAN adapters. The NISCA protocol is used to
access the system disk server and finish loading the operating system
(see Appendix F).
|
9.4.4 Enabling Satellites to Use Alternate LAN Adapters for Booting
OpenVMS supports only one hardware address attribute per remote node
definition in either a DECnet or LANCP database. To enable a satellite
with multiple LAN adapters to use any LAN adapter to boot into the
cluster, two different methods are available:
- Define a pseudonode for each additional LAN adapter.
- Create and maintain different node databases for different boot
nodes.
Defining Pseudonodes for Additional LAN Adapters
When defining a pseudonode with a different DECnet or LANCP address:
- Make sure the address points to the same cluster satellite root
directory as the existing node definition (to associate the pseudonode
with the satellite).
- Specify the hardware address of the alternate LAN adapter in the
pseudonode definition.
For DECnet, follow the procedure shown in Table 9-4. For LANCP,
follow the procedure shown in Table 9-5.
Table 9-4 Procedure for Defining a Pseudonode Using DECnet MOP Services
| Step |
Procedure |
Comments |
|
1
|
Display the node's existing definition using the following NCP command:
$ RUN SYS$SYSTEM:NCP
NCP> SHOW NODE
node-name CHARACTERISTICS
|
This command displays a list of the satellite's characteristics, such
as its hardware address, load assist agent, load assist parameter, and
more.
|
|
2
|
Create a pseudonode by defining a unique DECnet address and node name
at the NCP command prompt, as follows:
++DEFINE NODE
pseudo-area.pseudo-number -
NAME
pseudo-node-name -
LOAD FILE APB.EXE -
LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE -
LOAD ASSIST PARAMETER
disk$sys:[<
root.>] -
HARDWARE ADDRESS
xx-xx-xx-xx-xx-xx
|
This example is specific to an Alpha node. For a VAX node, replace the
command LOAD FILE APB.EXE, with TERTIARY LOADER
SYS$SYSTEM:TERTIARY_VMB.EXE.
|
++Alpha specific
Table 9-5 Procedure for Defining a Pseudonode Using LANCP MOP Services
| Step |
Procedure |
Comments |
|
1
|
Display the node's existing definition using the following LANCP
command:
$ RUN SYS$SYSTEM:LANCP
LANCP> SHOW NODE
node-name
|
This command displays a list of the satellite's characteristics, such
as its hardware address and root directory address.
|
|
2
|
Create a pseudonode by defining a unique LANCP address and node name at
the LANCP command prompt, as follows:
++DEFINE NODE
pseudo-node-name -
/FILE= APB.EXE -
/ROOT=
disk$sys:[<
root.>] -
/ADDRESS=
xx-xx-xx-xx-xx-xx
|
This example is specific to an Alpha node. For a VAX node, replace the
qualifier FILE=APB.EXE with FILE=NISCS_LOAD.EXE.
|
++Alpha specific
Creating Different Node Databases for Different Boot Nodes
When creating different DECnet or LANCP databases on different boot
nodes:
- Set up the databases so that a system booting from one LAN adapter
receives responses from a subset of the MOP servers. The same system
booting from a different LAN adapter receives responses from a
different subset of the MOP servers.
- In each database, list a different LAN address for the same node
definition.
The procedures are similar for DECnet and LANCP, but the database file
names, utilities, and commands differ. For the DECnet procedure, see
Table 9-6. For the LANCP procedure, see Table 9-7.
Table 9-6 Procedure for Creating Different DECnet Node Databases
| Step |
Procedure |
Comments |
|
1
|
Define the logical name NETNODE_REMOTE to different values on different
nodes so that it points to different files.
|
The logical NETNODE_REMOTE points to the working copy of the remote
node file you are creating.
|
|
2
|
Locate NETNODE_REMOTE.DAT files in the system-specific area for each
node.
On each of the various boot servers, ensure that the hardware
address is defined as a unique address that matches one of the adapters
on the satellite. Enter the following commands at the NCP command
prompt:
++DEFINE NODE
area.number -
NAME
node-name -
LOAD FILE APB.EXE -
LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE -
LOAD ASSIST PARAMETER
disk$sys:[<
root.>] -
HARDWARE ADDRESS
xx-xx-xx-xx-xx-xx
|
A NETNODE_REMOTE.DAT file located in [SYS0.SYSEXE] overrides one
located in [SYS0.SYSCOMMON.SYSEXE] for a system booting from system
root 0.
If the NETNODE_REMOTE.DAT files are copies of each other, the node
name, tertiary loader (for VAX) or LOAD FILE (for Alpha), load assist
agent, and load assist parameter are already set up. You need only
specify the new hardware address.
Because the default hardware address is stored in NETUPDATE.COM,
you must also edit this file on the second boot server.
|
++Alpha specific
Table 9-7 Procedure for Creating Different LANCP Node Databases
| Step |
Procedure |
Comments |
|
1
|
Define the logical name LAN$NODE_DATABASE to different values on
different nodes so that it points to different files.
|
The logical LAN$NODE_DATABASE points to the working copy of the remote
node file you are creating.
|
|
2
|
Locate LAN$NODE_DATABASE.DAT files in the system-specific area for each
node.
On each of the various boot servers, ensure that the hardware
address is defined as a unique address that matches one of the adapters
on the satellite. Enter the following commands at the LANCP command
prompt:
++DEFINE NODE
node-name -
/FILE= APB.EXE -
/ROOT=
disk$sys:[<
root.>] -
/ADDRESS=
xx-xx-xx-xx-xx-xx
|
If the LAN$NODE_DATABASE.DAT files are copies of each other, the node
name and the FILE and ROOT qualifier values are already set up. You
need only specify the new address.
|
++Alpha specific
Once the satellite receives the MOP downline load from the MOP server,
the satellite uses the booting LAN adapter to connect to any node
serving the system disk. The satellite continues to use the LAN
adapters on the boot command line exclusively until after the run-time
drivers are loaded. The satellite then switches to using the run-time
drivers and starts the local area OpenVMS Cluster protocol on all of
the LAN adapters.
For additional information about the NCP command syntax, refer to
DECnet for OpenVMS Network Management Utilities.
For DECnet--Plus: On an OpenVMS Cluster running
DECnet--Plus, you do not need to take the same actions in order to
support a satellite with more than one LAN adapter. The DECnet--Plus
support to downline load a satellite allows for an entry in the
database that contains a list of LAN adapter addresses. See the
DECnet--Plus documentation for complete information.
9.4.5 Configuring MOP Service
On a boot node, CLUSTER_CONFIG.COM enables the DECnet MOP downline load
service on the first circuit that is found in the DECnet database.
On systems running DECnet for OpenVMS, display the circuit state and
the service (MOP downline load service) state using the following
command:
$ MCR NCP SHOW CHAR KNOWN CIRCUITS
|
.
.
.
Circuit = SVA-0
State = on
Service = enabled
.
.
.
|
This example shows that circuit SVA-0 is in the ON state with the MOP
downline service enabled. This is the correct state to support MOP
downline loading for satellites.
Enabling MOP service on additional LAN adapters (circuits) must be
performed manually. For example, enter the following NCP commands to
enable service for the circuit QNA-1:
$ MCR NCP SET CIRCUIT QNA-1 STATE OFF
$ MCR NCP SET CIRCUIT QNA-1 SERVICE ENABLED STATE ON
$ MCR NCP DEFINE CIRCUIT QNA-1 SERVICE ENABLED
|
Reference: For more details, refer to DECnet-Plus
for OpenVMS Network Management.
9.4.6 Controlling Satellite Booting
You can control the satellite boot process in a number of ways.
Table 9-8 shows examples specific to DECnet for OpenVMS. Refer to
the DECnet--Plus documentation for equivalent information.
Table 9-8 Controlling Satellite Booting
| Method |
Comments |
| Use DECbootsync |
To control the number of workstations starting up simulataneously, use
DECbootsync, which is available through the NSIS Reusable Software
library:
http://eadc.aeo.dec.com/
. DECbootsync uses the distributed lock manager to control the number
of satellites allowed to continue their startup command procedures at
the same time.
|
DECbootsync does not control booting of the OpenVMS operating system,
but controls the execution of startup command procedures and
installation of layered products on satellites.
|
| Disable MOP service on MOP servers temporarily |
Until the MOP server can complete its own startup operations, boot
requests can be temporarily disabled by setting the DECnet Ethernet
circuit to a "Service Disabled" state as shown:
|
1
|
To disable MOP service during startup of a MOP server, enter the
following commands:
$ MCR NCP DEFINE CIRCUIT MNA-1 -
_$ SERVICE DISABLED
$ @SYS$MANAGER:STARTNET
$ MCR NCP DEFINE CIRCUIT MNA-1 -
_$ SERVICE ENABLED
|
|
2
|
To reenable MOP service later, enter the following commands in a
command procedure so that they execute quickly and so that DECnet
service to the users is not disrupted:
$ MCR NCP
NCP> SET CIRCUIT MNA-1 STATE OFF
NCP> SET CIRCUIT MNA-1 SERVICE ENABLED
NCP> SET CIRCUIT MNA-1 STATE ON
|
|
|
This method prevents the MOP server from servicing the satellites; it
does not prevent the satellites from requesting a boot from other MOP
servers.
If a satellite that is requesting a boot receives no response, it
will make fewer boot requests over time. Thus, booting the satellite
may take longer than normal once MOP service is reenabled.
- MNA-1 represents the MOP service circuit.
After entering these commands, service will be disabled in the
volatile database. Do not disable service permanently.
- Reenable service as shown.
|
Disable MOP service for individual satellites |
You can disable requests temporarily on a per-node basis in order to
clear a node's information from the DECnet database. Clear a node's
information from DECnet database on the MOP server using NCP, then
reenable nodes as desired to control booting:
|
1
|
To disable MOP service for a given node, enter the following command:
$ MCR NCP
NCP> CLEAR NODE
satellite HARDWARE ADDRESS
|
|
2
|
To reenable MOP service for that node, enter the following command:
$ MCR NCP
NCP> SET NODE
satellite ALL
|
|
This method does not prevent satellites from requesting boot service
from another MOP server.
- After entering the commands, service will be disabled in the
volatile database. Do not disable service permanently.
- Reenable service as shown.
|
Bring satellites to console prompt on shutdown |
Use any of the following methods to halt a satellite so that it halts
(rather than reboots) upon restoration of power.
|
1
|
Use the VAXcluster Console System (VCS).
|
|
2
|
Stop in console mode upon Halt or powerup:
For Alpha computers:
>>> (SET AUTO_ACTION HALT)
For VAX 3100 or VAX 4000 series computers:
>>> (SET HALT 3)
For VAX 2000 series computers:
>>> TEST 53
2 ? >>> 3
|
|
3
|
Set up a satellite so that it will stop in console mode when a HALT
instruction is executed according to the instructions in the following
list.
- Enter the following NCP commands so that a reboot will load an
image that does a HALT instruction:
$ MCR NCP
NCP> CLEAR NODE
node LOAD ASSIST PARAMETER
NCP> CLEAR NODE
node LOAD ASSIST AGENT
NCP> SET NODE
node LOAD FILE -
_ MOM$LOAD:READ_ADDR.SYS
- Shut down the satellite, and specify an immediate reboot using the
following SYSMAN command:
$ MCR SYSMAN
SYSMAN> SET ENVIRONMENT/NODE=
satellite
SYSMAN> DO @SYS$UPDATE:AUTOGEN REBOOT
- When you want to allow the satellite to boot normally, enter the
following NCP commands so that OpenVMS will be loaded later:
$ MCR NCP
NCP> SET NODE
satellite ALL
|
|
If you plan to use the DECnet Trigger operation, it is important to use
a program to perform a HALT instruction that causes the satellite to
enter console mode. This is because systems that support remote
triggering only support it while the system is in console mode.
- Some, but not all, satellites can be set up so they halt upon
restoration of power or execution of a HALT instruction rather than
automatically rebooting.
Note: You need to enter the SET commands only once on
each system because the settings are saved in nonvolatile RAM.
- The READ_ADDR.SYS program, which is normally used to find out the
Ethernet address of a satellite node, also executes a HALT instruction
upon its completion.
|
Boot satellites remotely with Trigger |
The console firmware in some satellites, such as the VAX 3100 and VAX
4000, allow you to boot them remotely using the DECnet Trigger
operation. You must turn on this capability at the console prompt
before you enter the NCP command TRIGGER, as shown:
|
1
|
To boot VAX satellites using the DECnet Trigger facility, enter these
commands at the console prompt:
>>> SET MOP 1
>>> SET TRIGGER 1
>>> SET PSWD
|
|
2
|
Trigger a satellite boot remotely by entering the following commands at
the NCP prompt, as follows:
$ MCR NCP
NCP> TRIGGER NODE
satellite -
_ VIA MNA-1 SERVICE PASSWORD
password
|
|
Optionally, you can set up the MOP server to run a command procedure
and trigger 5 or 10 satellites at a time to stagger the boot-time work
load. You can boot satellites in a priority order, for example, first
boot your satellite, then high-priority satellites, and so on.
- The SET TRIGGER 1 command enables the DECnet MOP listener, and the
SET PSWD command enables remote triggering. The SET PSWD command
prompts you twice for a 16-digit hexadecimal password string that is
used to validate a remote trigger request.
Note: You need to enter the SET commands only once on
each system, because the settings are saved in nonvolatile RAM.
- MNA-1 represents the MOP service circuit, and
password is the hexadecimal number that you specified in step
1 with the SET PSWD command.
|
Important: When the SET HALT command is set up as
described in Table 9-8, a power failure will cause the satellite to
stop at the console prompt instead of automatically rebooting when
power is restored. This is appropriate for a mass power failure, but if
someone trips over the power cord for a single satellite it can result
in unnecessary unavailability.
You can provide a way to scan and trigger a reboot of satellites that
go down this way by simply running a batch job periodically that
performs the following tasks:
- Uses the DCL lexical function F$GETSYI to check each node that
should be in the cluster.
- Checks the CLUSTER_MEMBER lexical item.
- Issues an NCP TRIGGER command for any satellite that is not
currently a member of the cluster.
|
