Migrating from ES40 to GS80

[Nate Klostermann]

My company is migrating from an ES40 to a GS80. Our ES40 currently has a local system disk that we boot from, and the rest of the disks are on a SAN. When we move to the GS80, we will have a local system disks and the rest of the drives will be on the SAN (we will use the drives on the SAN that the current ES40 uses). My question is, what is the best way to migrate the system disk from the ES40 to the GS80? The GS80 currently has OpenVMS 7.3-2 on it. Nothing else has been configured. Any hints/tips/lessons learned are greatly appreciated.

[Robert Gezelter · Accepted solution]

Nate,

I have done this on a few occasions. Generally, as a starting point, I use a copy of the existing system disk, presuming of course that it is compatible with the new hardware (you did not mention what version you are running on the ES40).

I then do any changes that I need to do on the copy of the system disk. This allows me to fallback to the ES40 if there are any problems. I also recommend using the hardware switch as an opporunity to re-visit the settings on systems and applications parameters, so as to have an efficient system.

If you are running an earlier release of OpenVMS, I would seriouslsy consider doing the upgrade to 7.3-2 on a copy of your existing system pack. This way, any difficulties caused by the upgrade are not commingled with the changes associated with the newly installed hardware.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Nate,

An amplification on my earlier posting.

After cloning the production pack, I would create an alternate system root (e.g., [SYS1...], presuming that the original system is using [SYS0...]). I would then make the GS80-specific changes to the SYS1 root (which will be pointed to by SYS$SPECIFIC, and keep the ES40-specific configuration items in the SYS0 root.

This means you have an easy fallback position at any point, without the need to maintain both sets of system packs.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Nate,

essentially I agree with Bob.

One extra point:
_IF_ you are now using Concealed Devices for every "data-collection" (read that as every application programms collection, every apllication data collection, every application temporary files collection, etc; take "application" to mean any more-or-less independantly used / usable functionality);
_THEN_ you just BACKUP-copy each concealed device to the SAN and re-define its concealed logical.

If you are NOT, then the above alone should indicate the usefullness of the concept, and maybe NOW is the time to start!

If you want help on how to do that, let us know!

From a historic perspective:
this way we moved our total cluster from AS2100's with HSZ-connected drives to ES'ses with SAN drives WITHOUT any downtime. Our total number of Concealed Devices is 800+.

hth,

Proost.

Have one on me.

Seasonal greetings to all!

Jan

[Robert Gezelter]

Jan,

Yes, as you may know, I am a very enthusiastic advocate of that type of approach. I have moved large clusters in a very short time by using concealed logicals for all of the data collections.

For a discussion of how much can be gained by that approach, I offer my OpenVMS Technical Journal paper, " Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters", available at http://www.rlgsc.com/publications/vmstechjournal/inheritance.html.

- Bob Gezelter, http://www.rlgsc.com

[Andy Bustamante]

HP has been very accommodating with providing temporary cluster licenses for hardware upgrades.

My suggestion would be to to create a temporary cluster. Add a new root to the ES-40 for your new system. Put the new system disk into the ES-40, boot from CD and create a backup/image to the new disk. Install and boot your new system. If you're going to run both nodes at the same time, you'll need to define sysuaf and should check for other logicals.

Out of curiousity, why not move the system disk to the SAN? I've upgraded several customers using 30 day cluster PAKs.

[Nate Klostermann]

I guess we could move the system disk to the SAN but I was under the impression that it would make the boot process a little more difficult.

I am running OpenVMS 7.3-2 on both systems. If I just copy the disk, how does that affect licensing? Will have I have to go back into the newly copied disk and make license modifications?

[Garry Fruth]

The following links may be of use to you for your licensing questions:

alpha license rating table http://licensing.hp.com/swl/view.slm?page=alpha

FAQ: Upgrading and Moving Software to Different Systems
http://licensing.hp.com/swl/faq.slm#upgrade

From the OpenVMS FAQ
http://www.compaq.com/products/software/info/

In your upgrade planning, you need to determine which device names are going to change. The SAN disk names are not likely to change. However, local disk names may change which may require changes to logicals, command procedures, programs.... Also, NIC names sometimes change, which may require you to make some changes in your network configuration. Tape drive names may change, which means you may need to modify your backup procedures. Some other obscure device name changes may (unlikely) have an effect; such as the device name for CD and floppy drives.

[Andy Bustamante]

You'll need to run wwidmgr at the console to configure the boot device. The manual for this is on the Alpha firmware CD, pop it into a PC and browse. This identifies the boot device and paths to connect and start the boot process. If memory serves you can have four devices defined. You should define all paths to the boot disk when you set boot_defdev. Your GS80 should come with it's own license PAKs and these will need to be enetered.

I've used VMS clustering to make migration to upgraded systems less disruptive. I even had one customer decide to keep their old 4100 active and purchase permant clustering PAKs after they saw how quickly our application switches between nodes.

[Tom O'Toole]

To second Andy's point - booting off the SAN is easy to configure, and gives you a lot of flexibility - with a cluster, the benefits of shared storage for the system disk are obvious, but even without a cluster, you could have another system ready to be a standby in the event of primary system failure. Since you already have a SAN in place, I'm assuming you have more than one server already using the storage...