Booting a node based on a console variable/symbol

[roose]

Hi folks,

We currently have a 2-node OpenVMS 7.3-2 ES80 cluster running from a SAN boot disk. One node is in our DC and the other one is in our DR site and is being used as our test/dev environment (application is not cluster aware). FC is being used for our cluster interconnect. There is also 1 SAN storage array in both DC and DR sites, with the DR disks being replicated from the DC SAN.

Our current strategy for DR for this cluster is that once DC is no longer available, we will be booting our DR node as our main node using the DC node's nodename. During boot-up, we will be using the DR SAN disks. For now, our strategy to do this is that we will boot our DR node in minimal mode, rename our already prepared startup procedures that are set to use the DR SAN disks, i.e. sylogicals.com, systartup.com, etc., and do a reboot for a normal startup. However, based on our normal startup timings, this will take us more than 30 minutes to complete.

We are looking at another strategy now wherein during DR, we will just have to set a variable in the console or a SYSGEN parameter in an interactive boot, and we'll use that variable in our startup scripts, maybe systartup_vms.com, to use either our normal procedures, or our DR procedures which will use the DR SAN disks. This way, we only need to boot the DR node once. At any rate, human intervention will be there during our DR with our current setup.

My question now is: is there a console variable, or SYSGEN parameter that I can use for this strategy?

We are not interested yet at this time on a third party software or hardware that will give us a better DR procedure, so we will just need to do this with our current setup. Also, network connectivity will be handled by our network team.

[Karl Rohwedder · Accepted solution]

There are the USER* sysgen variables (2 static and 2 dynamic), which you may use to select startup mode.
Later in SYSTARTUP check their value using F$GETSYI("USERD1") e.g.

regards Kalle

[Jan van den Ende]

roose,

I would set up BOTH the DC and DR boot configs in different roots ([SYSx...] and [SYSy...]) on the DC system disk (this is replicated to the DR site, right?).

Now for 'normal' operation, set BOOTDEF_DEV (or is it BOOTDEV_DEF, I can never remember) at DC to boot from SYSx, at DR site to SYSy.

All you need to do at DR time now is a manual
>>> B -fl 0,x

(or

>>> SET BOOTDEF_DEV x
>>> b

if you think the DR situaltion will last "longer")

hth.

Proost.

Have one on me.

jpe

[Jan van den Ende]

Roose,

whether you choose for Kalle's or for my suggestion, or even for your original setup, please realise that you WILL need to be VERY carefull in configuring periferal devices! If you somehow use your DC config & bootstrap in your DR system, make sure ALL periferals, including eg network devices and (disk-, tape-) drives are all similar, and named correctly. ANY exception needs to be coded (in your DC setup) to distinguish the difference and handle that appropriately.

Success!

Proost.

Have one on me.

jpe

[Willem Grooters]

Referencing a SYSGEN parameter is a requirement. Reading console variables from within OpenVMS is limited. You have two that can be used: USER_P3 and UER_P4, both, IIRC, dynamic, so you can prepare a syste.

The disadvantage is that you'll have to change it any time you boot the machine. The advantage is that auto-restart (if applicable) is cared for, since it will be stored.

On the other hand, using a differnt system root, or even a separet system disk, has it's advantages. The biggest of them being separation of development/testing and production.

If you use a common system disk for both nodes, I would opt for a seapare root for DC and DR, and have console-variable BOOT_FLAGS set accordingly to boot the intended way. If the DC node would be booted as DR, just supply the right system root.

If you boot each system from their own system disk, it's even more separated.

However, both require a console variable be set properly to be sure that if a system starts automaticly, it boots from the right root (set BOOT_OSFLAGS) or disk (set BOOT_DEVDEF).

[roose]

Thanks for the replies! I think for now, we will opt for the sysgen parameters USER3 as it is non-dynamic and would serve our current intent.

Thanks for the other suggestions as well.