HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Volume shadowing between FC Storage at different sites, and the allocation class

 

Volume shadowing between FC Storage at different sites, and the allocation class

Hi,

I have just connected to some Fibrechannel based storage from my VMS system. I see all the devices as $1$DGAxxx. Even thought the ALLOCLASS parameter is 6 for the system.

This system will be in a cluster with a system at a remote site also connected to FC storage, and I am sure I will also see the devices as $1$DGAxxx.

I want to use Volume Shadowing to mirror the two sites, but I am a bit concerned that because the allocation class is 1 for fibre channel storage at both sites this may cause confusion for the cluster software.

If anybody else has done this or has suggestions I would appreciate the feedback.

With regards
Andrew
10 REPLIES
Uwe Zessin
Honored Contributor

Re: Volume shadowing between FC Storage at different sites, and the allocation class

"$1$DGA" is hardcoded in the device driver for fibre channel disk devices as "$2$MGA" is hardcoded for fibre channel attached tape devices.

You only need to make sure that the unit numbers ($1$DGA5: = unit number 5) are unique. I usually use unit numers 100..199 for one site and 200..299 for the other, but you can mix this complete as you like - they only need to be unique.

It's been quite some time that the MSCP server can server disk devices with allocation classes differrent that the host allocation class (I think the last fixes were made in V7.2-1).
.
Martin Vorlaender
Honored Contributor

Re: Volume shadowing between FC Storage at different sites, and the allocation class

I'm no expert on FC but I think the alloclass 1 is provided by the FC storage system itself, i.e. even the SRM sees the disks as $1$DGAxxx.

This should be okay for the two sites as the alloclass' purpose is to provide machine independent identification of the disks. That is, independently of the path, all machines see one particular disk as $1$DGAxxx.

For HBVS you'd use two (or more) $1$DGA devices.
Uwe Zessin
Honored Contributor

Re: Volume shadowing between FC Storage at different sites, and the allocation class

Hello Martin,
there is no setup for allocation class on the EVA and MSA storage arrays. When you see a fibre channel attached disk on SRM console level with an allocation class prefix it is a pre-defined device for boot/dump support. All other device show up without allocation class and an arbitrary assigned unit number:
pga0.0.0.2.1
- Port: 5008-05f3-0004-e561
- dga9451.13.0.2.1 WWID:01000010:6008-05f3-0004-e560-0000-0000-551a-0002
- dga5983.13.0.2.1 WWID:01000010:6008-05f3-0004-e560-0000-0000-4735-0004
- dga413.13.0.2.1 WWID:01000010:6008-05f3-0004-e560-0000-0000-b46a-0005
- dga15387.13.0.2.1 WWID:01000010:6008-05f3-0004-e560-0000-0000-5569-0006
- dga11092.13.0.2.1 WWID:01000010:6008-05f3-0004-e560-0000-0000-9d8e-0007
- dga10546.13.0.2.1 WWID:01000010:6008-05f3-0004-e560-0000-0000-7a7b-0008
.
Ian Miller.
Honored Contributor

Re: Volume shadowing between FC Storage at different sites, and the allocation class

as has been said already $1$ is built in. Also ensure you set the site parameter for the shadow set memembers so VMS knows which is the local member for reads.
____________________
Purely Personal Opinion
Wim Van den Wyngaert
Honored Contributor

Re: Volume shadowing between FC Storage at different sites, and the allocation class

Andrew,

Check dismount/policy=minicopy=option. This for the disk that is on the node to be shut down.

When you shut down 1 site you should ask the remote site to keep a bitmap of changes (by hand or by e.g. using rsh). After the reboot, the shadow copy will be done within minutes instead of hours.

Wim
Wim
Lokesh_2
Esteemed Contributor

Re: Volume shadowing between FC Storage at different sites, and the allocation class

Hi,

Are you looking for disaster tolerant setup ? Then have a look at DTCS (Disaster tolerant cluster services) for OpenVMS.

Thanks & regards,
Lokesh Jain
What would you do with your life if you knew you could not fail?
Ian Miller.
Honored Contributor

Re: Volume shadowing between FC Storage at different sites, and the allocation class

see also Cockpit Manager for monitoring of multisite shadow sets

http://www.hp.be/CockpitMgr
____________________
Purely Personal Opinion
Uwe Zessin
Honored Contributor

Re: Volume shadowing between FC Storage at different sites, and the allocation class

The base message says that the remote system is also connected to FC storage. If the local and remote storage are connected to the same fabric(s), then all systems have access to all storage arrays and it is not necessary to deal with minicopy, because each system sees all storage as 'locally connected'.
.
Anton van Ruitenbeek
Trusted Contributor

Re: Volume shadowing between FC Storage at different sites, and the allocation class

Andrew,

Whe are using FC storage for our cluster etc. Whe have a two site cluster, multiple nodes on every site, multiple san etc. etc. All wired up twice, so quatro connected etc.
For SAN all the devices are $1$DGA (as posted before). Whe have made a deal/understanding: drives from 0 to 99 are location 1, 100 to 199 are site 2.
There is no other methode to make a difference, because there isn't any. So $1$DGA1 is location 1 (whe do also SET DEVICE/SITE) and $1$DGA120 is at location 2.

We shadow ofcourse etc. Whe have by default 3 drives in every shadow set. 1 at remote site (dark-site) and 2 at local site where the tapeunit is located. So we disconnect at the tapeunit site one of the two drives (option=minicopy) and backup always image of every drive.

As posted before about dismount/option=minicopy. Doesn't apply to FC drives, because they are served by every node in the cluster. If you're systemdisk is on SAN, the dumpdrive must be a local drive. This one may not be member of a shadowset.

If you need extra info, please notify.

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

Re: Volume shadowing between FC Storage at different sites, and the allocation class

I second Lokesh's recommendation for DTCS.

There's a lot of information about disaster tolerance at http://www2.openvms.org/kparris/