Change the HW from 4100 with local Discs to DS25 Cluster with EVA3000 SAN

[Vallentin, Manfred]

Hello,
i plan to change my HW-Plattform from Alpha 4100 with differents local Discs to a DS25 Cluster who is connected to a EVA3000 SAN.
My OS is OVMS 7.3.2. I will keep at the new System the same Discnames and Servernames.
What is better,
when i restore the Backup Image from the Old System to the new System an make follwing Parameterchanges for the new HW
or i install the new System complete fresh
(1. OVMS, 2. Application, 3. User...)

Thanks for your hints

[Wim Van den Wyngaert]

The restore is simplier and faster. And you have exactly the same features/config. Of course you may need to reconfig decnet/ip/... .

If you re-install, you must search for all changes that were done and you will certainly forget some.

Wim

[Jan van den Ende]

Manfred,

we even went one step further along maintaining the old config:

first _ADD_ the new hardware to the cluster
then move the data to the SAN disks (can now be done gradually! Just adjust the logical name for each concealed device after moving it)
finally remove the old hardware.

Sounds simple, in practice it proved rather simple, but it _WAS_ a lot of work, and it needs to be done with good discipline.

Succes

Jan

[Bojan Nemec]

Hi,

It also depends on third party software which is installed on this system. If it has HW dependencies can be dificult to simply restore the image backup.

If you have not such software, you can go for the Backup Image. Dont forget to properly setup the network connections (probably the network card will have a different name).

When done do a @sys$update:autogen to recompute the system parameters.


Bojan

[Wim Van den Wyngaert]

Which software is hardware dependent ?
I know that Sybase doesn't support moving of files between disks (according to my dba) but I know that it works.

Wim

[Bojan Nemec]

Wim,

I had some problems with a third party software which writes the physical names in its command procedures at instalation time. Yes, I know this is wery bad programming, but there are programers which does not know what logical names are.

By the way last time I install Oracle on VMS (I think it was 8i) translates all my logical names to phisical names.


Bojan

[Wim Van den Wyngaert]

But you can tell Oracle (Sybase too) that the file has changed place after the restore.
And then it works fine.

Wim

[Martin P.J. Zinser]

Hi Manfred,

actually you do have two migrations in place here. One is moving storage from DAS to SAN and one is moving from the 4100 to the DS25.

If possible, separate them. This obviously does require FC adapters for the 4100, but would allow for a much more gradual migration. As mentioned before, you could just move one disk volume after another to the new storage, making any potential roll back much easier.

As for the server, if you have limited time and test resources, cloning the disk and chaning HW parameters afterwards will be the quickest solution. On the other hand and in my opinion there is also some value in setting up the new server from scratch as "stuff" tends to accumulate on a computer and starting from scratch is a good opportunity to separate the required from the trash. As mentioned this does require more time and more testing to make sure you are not getting rid of anything important together with the old stuff, but afterwards you will have a "clean" system.

Greetings, Martin

[DICTU OpenVMS]

About HW depended software, Gembase uses the MAC-address for calculating the license and Xuis Enterprise Scheduler uses the CPU serial and system type.

Also, don't forget your other licenses.

[Vallentin, Manfred]

on the System is only the following Application installed:

OVMS 7.3.1
OVMS PASCAL Compiler (for developing Application)
ADABAS Ver 4.1.1.1
IBM MQSeries Ver 5.1
UC4 Executor Ver 2.63
and
TSM for managing the installed Terminalservers (ca. 100) But here we look for a alternativ Product that we can managing in the future the Terminalserver in a Batchmode over TCPIP.

[Chris Davis_9]

Hi Manfred.

I migrated an Alpha 4100 + 2100 cluster to 2 x ES40 cluster a couple of years back. the disks were being moved from DSSI to Fibre channel via HSG60 controllers.

Once the disks were configured by our reseller, I used our standard Disaster Recovery procedures to build the new system.

We also run Adabas v4.1.1 and this is usually quite happy. You only need to make changes if the disk names where the container files are located have changed - quite possible if you're moving to an EVA, but dependent upon you're old config and whether you've used logical names.

I try to configure the system from the start so that any changes are limited to SYSTARTUP_VMS .COM, if possible, although our latest software acquisition, Attunity Connect, does store physical device names in several places, not just in its startup files.

If you have no DR procedures, I'd suggest using this exercise to develop a set of instructions. If time allows, you could use the opportunity to work out a full set of procedures.

As already mentioned, it is rarely easier to reinstall everything from scratch - too much happens over the years that you or previous managers haven't noted down. It is far easier to restore your existing system and change any parameters/device names as necessary.

I wish you success!

[John Gillings]

Manfred,

Since you're at V7.3-2, why not migrate the system with (almost) no downtime? Start with a minimal installation, temporary system disk for the DS25. Use clustering to add the new node, and make the SAN disks available to the old nodes, then use dissimilar device shadowing to move the data without interrupting processing. Once that's done, shutdown everything and boot the DS25 from the migrated system disk, AUTOGEN and reboot!

Obviously you'll need to do some detailed planning, and you will need to modify your MOUNT commands, but everything is now present in OpenVMS 7.3-2 to perform transparent physical migrations of entire data centres. With your system disk on Fibre Channel, you don't even need to have the reboot as your new node can boot from a new root on the existing system disk.

Design your clusters carefully and you'll be able to upgrade nodes, storage and sites with zero downtime!