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

[Andrew Rycroft]

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

[Uwe Zessin]

"$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]

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]

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.]

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.

[Wim Van den Wyngaert]

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

[Lokesh_2]

Hi,

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

Thanks & regards,
Lokesh Jain

[Ian Miller.]

see also Cockpit Manager for monitoring of multisite shadow sets

http://www.hp.be/CockpitMgr

[Uwe Zessin]

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]

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

[Keith Parris]

I second Lokesh's recommendation for DTCS.

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