Operating System - OpenVMS
1748275 Members
4021 Online
108761 Solutions
New Discussion юеВ

Re: 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 15
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? ;-)
.