Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

vms and EVA5000 cluster, additional questions

SOLVED
Go to solution
WilliamSmith11
Super Advisor

vms and EVA5000 cluster, additional questions

Ok Jan and Mike and to someone who may add more information.

I have some other question about the O.S

1-The allocation class in the EVA is 1 and cannot be changed , am I OK?

2-At first we are only to install the new EVA5000 to the system and we are going to pass the data progressively.

Would be a good idea to make the backup of the data with a backup image and after download the backup to the new LUN in the EVA?

3-If the new EVA came with the version 3.01 won't be necessary request for the basic license by the web as was necessary in the oldest versions?

4-Is necessary to configure something else in the operating System for that there is not any conflict with the scsi adapters that are controlling the old storage.
I mean something else like allocation class or something else?
Jan , Mike when you installed the EVA you only configure the LUNs and presented it to the system , that was all?

well I will appreciate all the experiences with your installations ,

Is my first time with a VMS cluster system.
I have worked with VMS system but in single systems not clusters.

Tru64 have been my daily jobs,













rperez
15 REPLIES
Uwe Zessin
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

Ralph,

1) No, at least not in the sense you asked the question. The allocation class is hard-coded in the OpenVMS device driver. HSG- and MSA-attached LUNs will have the same allocation class.

2) Sure. Take some time to make yourself familiar with the system if this is new to you. If you have OpenVMS V7.3-2, you could also migrate your data with host-based volume shadowing as it allows disks with different sizes to be shadowed - you just round up the virtual disk on the EVA to the next multiple GigaByte.

3) Correct, I guess you haven't even received a transaction key. I have upgraded several EVA-3000 from VCS V2.006 firmware to V3.010 before initialization and without a base license.

4) No. Fibre Channel disks are named $1$DGAunit - it is highly unlikely that your current system uses such a device name already if it is not using fibre channel. What you MUST take care about is the OpenVMS unit number - do not assign the same number to different virtual disks and present them to the same server.

All this has nothing to do whether the system is clustered or not. OpenVMS does not make any reservations to the disks like Trucluster or MSCS.

> Tru64 have been my daily jobs,

That's OK. It is never too late to learn new things ;-)

Please keep us updated on your project's progress.
.
Jan van den Ende
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

Ralph,

Uwe covered about everything at least as good as I could have done.

One thing about the data migration:
If you do use shadowing (and I really hope you do!), then migrating-by shadowcopy IS the most easy way. You MUST have enabled dissimilar-device shadowing for it to function though, and that's a real new function. If you haven't got it yet THIS is the time to start using it.
For this, INITialise your new disks with /SIZE=... (best use max, 1Tb).
But now, if you move your data, do'nt forget /NOINIT in your backup command.
You MAY make an /IMAGE backup, and roll that back onto your SAN disk.
$ BACKUP saveset-spec newdisk:/NOINIT
It will be a good point in time for a backup save.
But if you do not specifically need the image backup, you can also make a direct disk-to-disk backup:
$ BACKUP olddisk:[*...] newdisk:[*...]/owner=original
add /truncate if you also changed the disk clustersize.
And if you are looking for a revision of your directory spread over the disks, this is the time to do it!
$ BACKUP olddisk:[dirname...] newdisk:[*...]/own=original [ /trunc ]


Success!

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Uwe Zessin
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

Jan,
thank you - nice compliment.

I like migration with BACKUP/IMAGE because it retains creation and revision dates of the directories.

It's been some time that I migrated directory trees, but in earlier versions of OpenVMS the BACKUP utility did not properly copy the characteristics of the top-level directory (e.g. ACLs of [000000]user1.DIR;1) when I used
$ BACKUP disk:[*...]

has that changed somehow?

This version, if I recall correctly will not copy any files in the MFD as well. One could use [000000...], but when I tried that one, it did not transfer directory trees when the top-level directories' name started with '$'. (I beleive this is documented somewhere - it has to do with the logic to protect against endless recursion when it hits 000000.DIR)

Oh, well - it looks like one cannot always win.
.
H_Bachner
Regular Advisor
Solution

Re: vms and EVA5000 cluster, additional questions

Relevant information has been given already - just let me add two points:

- the (hardcoded) allocation class for EVA devices is 1 for disks and 2 for tapes

- regarding data migration, if you don't go the volume shadowing route, you should use BACKUP /IMAGE instead of the suggested BACKUP disk:[000000...] command. BACKUP /IMAGE also works from disk to disk, no need for an intermediate saveset as long as both disks can be seen on the same system.

Other than BACKUP [000000...], an image backup correctly handles files with multiple directory entries. While these are rarely used on data disks, it's the only way to create a functional copy of a system disk. For a clean system disk copy, be sure to boot from CD-ROM or from a minimum system created on a different disk created with SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM (which allows for faster booting). In addition, image backups are usually faster than file based backups, even if all files on a disk are selected.

Hope this helps,
Hans
Uwe Zessin
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

Hans,
I like BACKUP/IMAGE, too, but I don't understand you point that:
"BACKUP /IMAGE also works from disk to disk, no need for an intermediate saveset as long as both disks can be seen on the same system."

'BACKUP disk1:[000000...]* disk2:[00000...]' does not need an intermediate save-set either. It might be needed when one wants to consolidate directory trees from different disks.


And while we're talking about system disks:
there is not much new for you to learn, Ralph. The mechanism with WWIDMGR is the same. The BOOT_OSFLAGS variable needs different values:
http://h18002.www1.hp.com/alphaserver/docs/userguide/WebHelp/boot_osflags.htm
.
Jan van den Ende
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

Uwe,

thanks for pointing out my forgotten point.

Yes Ralph, before moving over a directory tree you will need a separate
$ Backup olddisk:[000000]topdir.DIR newdisk:[000000]/own=orig
-- to me that always looked like a bug, but with an easy workaround. Quite easy to forget though, as I just proved yesterday :-(


Jan
Don't rust yours pelled jacker to fine doll missed aches.
Jan van den Ende
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

Ralph,

another extra available:

It applies if you somehow decide that you might change the disk cluster size. (many of us have grown into big or HUGE cluster sizes in the "pre-vms-V7.2, ever bigger disks"- period.
Since V7.2 you can use smaller cluster sizes on bigger disks, and many want to return to those smaller disk clusters.
If you do your data migration via one of the BACKUP methods, you can add /TRUNCATE. This will bring the allocated size of sequential files down to the lowest cluster size for the used part of the files. (remember, if using /IMAGE backup, then also use /NOINIT, or your carefully designed new clustersize will be overwritten by the old values held in the saveset).

Jan
Don't rust yours pelled jacker to fine doll missed aches.
H_Bachner
Regular Advisor

Re: vms and EVA5000 cluster, additional questions

Uwe,

>..., but I don't understand you point that:
> "BACKUP /IMAGE also works from disk to disk, no need for an
> intermediate saveset as long as both disks can be seen on the same
> system."
>
> 'BACKUP disk1:[000000...]* disk2:[00000...]' does not need an intermediate
> save-set either. It might be needed when one wants to consolidate directory
> trees from different disks.

With respect to consolidation, this is completely true, of course. My reply was referring to a previous post:

> You MAY make an /IMAGE backup, and roll that back onto your SAN disk.

which might be read as "image backup and restore require an intermediate saveset". So I just wanted to put things straight. Let aside the speed aspects, there's also no need for /OWNER=ORIGINAL with BACKUP /IMAGE, but you certainly want to use this qualifier in the file-by-file copy operation (as has been mentioned already).

Best regards,
Ha
Uwe Zessin
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

OK, understood.

By the way: has nobody of you noticed that since VAX/VMS V5.0 the /OWNER qualifier has been replaced with /BY_OWNER? ;-)
.
Jan van den Ende
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

Yes, Uwe.

But true to the VMS tradition, /OWNER just goes on working fine. Maybe functionality will diverge some day (I haven'd found it on /OWNER for any command yet, or have I just been lucky?)

Even older, but along the same line:
F$LOGICAL has been replaced by F$TRNLNM.
Many (including several VMS layered products!) continue using F$LOGICAL however.

But, functionality HAS diverged in this case!
Try it for logicals that are INCLUDED in (or via) LNM$FILE_DEV, but NOT in the pre-V4 Process-Job-Group-System search list.
(and there are some really nice advantages in using extensions of LNM$FILE_DEV!!!)


So, for now /OWNER is no issue, but don't expect any future enhancements of /BY_OWN to function on /OWN as well!

fwiw

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Uwe Zessin
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

Well, you know I sometimes like to play devil's advocate...

The help for OpenVMS V7.3-2 says:

The /OWNER_UIC qualifier has been superseded by /BY_OWNER. HP recommends that you substitute /BY_OWNER for /OWNER_UIC in command procedures and operator instructions. See the description of /BY_OWNER for more information.


On the other hand - here is the output from V6.2-1H3:

The /OWNER_UIC qualifier has been superseded by /BY_OWNER. Digital recommends that you substitute /BY_OWNER for /OWNER_UIC in command procedures and operator instructions. See the description of /BY_OWNER for more information.
.
Anton van Ruitenbeek
Trusted Contributor

Re: vms and EVA5000 cluster, additional questions

Ralph,

As mentioned somewhere in this forum is that you must change by WWIDMGR to access the systendisk directly. If you are in a cluster using shadow-disks this can be a problem. The major question is 'How do I know the disk I want to boot from is a member of the current systemdisk ?'. It can be possible that the disk you are trying to boot from is dismounted (for some reason) !! and then you got a big problem ! Whe at our site are nowadays always MOP booting. The serving system knows which disk(s) are currently mounted and when de DGA driver is in place it automaticly swich over to direct attach (of course using the first stage of booting it is MSCP !). So know all the nodes are MOP enabled for booting any cluster member ! If one of the systemdisks is dismounted (by error, upgrade or other) I alway boot from the correct member(s) of the systemdisk.

AvR
NL: Meten is weten, maar je moet weten hoe te meten! - UK: Measuremets is knowledge, but you need to know how to measure !
Uwe Zessin
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

That's a cool trick, Anton. I have used something similar in an FDDI-based cluster and dual HS211 storage servers many years ago, but we had problems during shutdown when the boot node was already absent.

Have you tried if you can cleanly shutdown and write crashdumps that way? The ability to switch from an MSCP-path to a local SCSI/FC-path is rather new (V7.3-1, if I recall correctly).
.
Anton van Ruitenbeek
Trusted Contributor

Re: vms and EVA5000 cluster, additional questions

Uwe,

The dump drive is an internal driver (ofcourse, knowing the specs.) .
Yes we tested several times the shutdown procedure.
And yes, we do for the last 7 years already rolling upgrades and no not for the whole 7 years on SAN. We did an rolling upgrade from applications from DAS to SAN.

During rolling upgrade for VMS you need to change the volume label and shadow member for the systemdrive ! This is crusial ! One type during this process you're cluster can hang, crash or other fine things can happen !

AvR
NL: Meten is weten, maar je moet weten hoe te meten! - UK: Measuremets is knowledge, but you need to know how to measure !
Jan van den Ende
Honored Contributor

Re: vms and EVA5000 cluster, additional questions

Yes Uwe,

we DO remember the 'fun' with cross-boot from SD on shared-SCSI bus. If the served path was via one node, and that node went down (crash or shutdown) than the failover failed, and you hang. If planned, you SHOULD be able to SET PREFERED_PATH, but we never succeeded.
It has been out idea from the onset of the cluster.
First it was explicitly NOT supported, and I remember DECUS Paris 1998, we had some lively discussions with several people from Engeneering and Storage, that took shelter behind each other's arguments. Until we confronted all parties, and neither could give good reasons NOT to support it. After some contact with Nashua & some quick testing there, they told us it worked, and would be supported shortly.
Only served-path failover of the SystemDisk did NOT work.
Upon moving to 7.3-1 the docs implied it would now work, we tried again, and Hallelujah.
We have been lucky though to skip 7.2-2. The docs for for imply the same as 7.3(-x), but according to Keith Parris it does NOT funtion good.

Jan
Don't rust yours pelled jacker to fine doll missed aches.