vms and EVA5000 cluster

[WilliamSmith11]

I have a cluster with VMS 7.3 .The systems are two Alphaserver 8400.The cluster is sharing a SW800 rack with controllers HSZ52 , we are planning to install a new EVA5000, the customer want to past all the data to the new storarage (eva5000).We also are going to by the bussiness copy license.
The question is :
1-Can I use the bussiness copy license to copy the data fron the all storage to the new one?
2-There is some guide documentation about cluster connection and configuration using EVA5000?

I think that only I have to present the LUNs to both system with the allocation class that the custumer wants and that is all .

I appreciatte your comments.

Thank you

Ralph

[Mike Naime · Accepted solution]

1.) NO! Buisness copy only works on data within the EVA. you will have to manually copy the HSZ data to the EVA LUNS.

2.) Welcome to the world of SAN. Is the customer wanting to boot from the SAN? If so, you will have to SET MODE DIAG before you can access the WWIDMGR utility on the 8400.

Interesting note: I just scrapped 2 8400's at work today. We turned them off and pulled the power plugs. They were replaced by 2 ES40's.

Allocation class of Fibre channel drives is 1! you cannot change that.

All fibre channel drives show up as $1$DGAxxxx. you can set the xxxx.

[Martin P.J. Zinser]

Hello Ralph,

if possible at all try to have the two arrays in parallel for a transition period. First put not so important stuff on the new array and then gradually move the rest of the data.

I second Mikes notion, if you do have the 8400s under service ES40s or ES45s would be a good upgrade path. They can be had relatively cheap today on the used market and will be much lighter on the service budget.

Greetings, Martin

[Jan van den Ende]

Ralph,
I second Martin.

We had our data also on HSZ (40's, but no different). After the SAN was in place, we moved our data, one concealed device at a time, at a time that THAT data could be kept quiet, from HSZ to SAN. Just a lot of work. The only real issue there are the 'system permanently open files'. You CAN make a backup/ignore=interlock for SYSUAF and RIGHTSLIST, but before using them, CHECK that they came over intact! IF a modification IS in process during backup, you end up with inconsistent data. ANAL/RMS is your tool. After they check out OK, change the logical names.
It should be quite easy to temporarily abstain from making authorisation changes, but password changes are something different, and certainly last-login & login-failures registration MIGHT make you do the Backup again.
More or less the same for QMAN$MASTER. STOP and CLOSE as many queus as you possibly can, backup /ign=inter your open files, set the logical on the other node to the new location, and have your que manager failover.
Things like AUDITSERVER,SECURUTYSERVER,OPCOM etc, simply define the new logical name and switch to a new file ( HELP for exact syntaxes, they are not intuitive, and each has its own different way).

Will you report here how it went?

Jan

[Uwe Zessin]

Ralph,

1) As Mike has already said you cannot use 'business copy' to transfer data from one storage array to another. BC-EVA can only do snapshots and snapclones within one EVA. (Strictly speaking, BC-EVA is two products, but let's try to get the migration done, first.)

2) Take a look at the folowing manuals:
- OpenVMS Kit V3.0B for Enterprise Virtual Array Installation and Configuration Guide (AA-RUGUB-TE)
and
- OpenVMS Kit V3.0B for Enterprise Virtual Array Release Notes (AV-RUGXB-TE)

The first one is included in the OpenVMS platform kit, which you should grab from here anyway, because it includes the SSSU:
http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?pnameOID=315132&locale=en_US&taskId=135&prodSeriesId=315127&prodTypeId=12169&swEnvOID=1094

The release notes are here:
http://h20000.www2.hp.com/bizsupport/CoreRedirect.jsp?targetPage=http%3A%2F%2Fh200001.www2.hp.com%2Fbc%2Fdocs%2Fsupport%2FUCR%2FSupportManual%2FTPM_av-rugxb-te%281%29%2FTPM_av-rugxb-te%281%29.pdf


-----
Make sure you understand the section: 'Console LUN ID and OS Unit ID', else you might not be able to see your devices on OpenVMS even if you have presented the virtual disks to your hosts.

[Keith Parris]

You might consider shadowing the HSZ disk units onto units on the EVA; that could allow a transition without application downtime, and you don't have to worry about things like open files.

But there is one significant complication: Because the size of EVA units cannot be set to an exact number of blocks like a partition on the HSZ or HSG or HSJ could, the size of the unit on the EVA will have to be the next-larger increment. That means you'd need Dissimilar Device [size] Shadowing, or DDS, which was first introduced in 7.3-2, so you'd need to upgrade from 7.3 to 7.3-2 first.

The other alternative (if you can't upgrade to 7.3-2) is to create disk units on the EVA, then use BACKUP to move the data across. People who feel more comfortable shadowing for a period of time between the older (and slower, but well-proven, burned in, tried-and-true) hardware and the newer storage hardware, to lower the overall risk during the transition, will sometimes create new slightly-smaller units on the EVA, then use BACKUP to move the data across, then create partitions on the HSZs of equal size to the new EVA units (slightly smaller than the original units on the HSZs) which they can then shadow with the new EVA units. But that implies some downtime for access to the data while the BACKUP is being done for a given unit.

There's a lot of useful information about using Fibre Channel storage with OpenVMS at http://h71000.www7.hp.com/openvms/fibre/index.html and much useful information has also been integrated into the latest versions of the various manuals, at http://h71000.www7.hp.com/doc/