Volume Shadowing in a non-clustered environment.

[Larry Dillon]

I'm new to Volume Shadowing so I apologize in advance if my questions are naive.

I'm wanting to shadow the data disks across two rx2620's in a non-clustered environment. I've been told by our sales guy that it can be done.

Each rx2620 has a system disk and a single data disk. Only one system is "live", the other being only a backup. The rx2620's are on the same Ethernet LAN but it would be possible to put them in a private copper gigabit Ethernet LAN. We're trying to keep costs down, so no fiber SAN.

I've successfully set up volume shadowing on one machine with two data disks as practice.

I've read all of the documentation I can find and can't figure out how to address the non-local data disk to create the shadow set.

Everything I read shows Volume Shadowing in a cluster with shared physical disks or else withing a single machine.

I understand that in a non-clustered environment (without the distributed lock manager) one cannot change data on the backup system.

Any advice (including if this is even the right approach) would be appreciated.

[Andy Bustamante]

If you're not on a SAN, I'm going to make the assumption that the data disks are SCSI drives.

The first step is to document the risk in having two systems access the same storage at the same time without coordination. Your business requirements will drive whether or not the potential for lost data and downtime is acceptable. Whoever makes the funding decisions needs to know the trade offs.

See section 3.6 of HP OpenVMS Cluster Systems
http://h71000.www7.hp.com/doc/84final/4477/4477pro_005.html

Shared SCSI storage in an OpenVMS Integrity server Cluster system is subject to the following restrictions:

Maximum of two OpenVMS Integrity server systems connected to a single SCSI bus.

Maximum of four shared-SCSI buses connected to each system.

rx1600 and rx2600 family systems are supported.

A7173A HBA is the only supported HBA.

MSA30-MI storage enclosure is the only supported SCSI storage type.

Ultra320 SCSI disk family is the only supported disk family.

Did you touch all the bases here?

You should be able to set up the storage such that both nodes see all the disks, however if both nodes mount a disk, expect to test your backup and disk recovery procedure.

A better option may be to have the external storage array connected to only one rx2620 at time, and switching the scsi cables to present the storage to the appropriate node.

>>>I understand that in a non-clustered environment (without the distributed lock manager) one cannot change data on the backup system.

One should not mount the disk(s) on more than one system. Potentially with static data and disabling cache you might be able to mount a disk read only (/nowrite) on multiple volumes. This would be an unsupported configuration.

You're removing the blade guards and promising that you'll only pass your fingers between the prop blades while the engine is stopped. This may be acceptable, but be aware of who else might have a set of keys.

[John Gillings]

Larry,

If the sales guy says it can be done, ask him how! I don't believe it's possible.

As you say, you need a way to address the remote disk. If you're not on a SAN or clustered, there's no "standard" mechanism to do that.

There may be 3rd party products, but nothing standard inside the OS.

Presumably you're trying to set up a DR site? If so, I'd recommend you engage the services of someone who's done it before. This stuff IS rocket science. It's not something you can do without a deep understanding of the many pitfalls.

By its nature, you don't find your mistakes until you're trying to activate it - the worst possible time, as you're under pressure, and, by definition, can't go back and fix anything.

Andy's assumed you're talking shared SCSI. If ever there was a solution in search of a problem... Some fairly severe length limitations, weirdo expensive components, and, as Andy has noted, some fairly nasty flying blades to avoid.

Effectively you're spending a LOT of cash to guard against a very limited set of unlikely failures, with a complex and error prone recovery path, whilst exposing yourself to quite a few LIKELY failures (like data corruption).

[Bob Blunt]

Larry, in a nutshell this is an unsupported configuration. Sharing disks across non-clustered nodes is risky at best and while some organizations have managed this type environment it has required special considerations from OpenVMS engineering as well as customized agreements about how the devices are to be handled. Neither a SAN nor any form of SCSI (or in the special environment SDI disks) address the handling of I/O coordination or locking to make this a safe practice. If you mount one "side" R/W and the other Read only you're somewhat "safer" but only by virtue of controlling any write access on one node. Since shadowing would require write on both sides then I'd say this isn't a viable or safe solution.

It does, however, beg the question: Why would you NOT cluster if you really need this sort of setup?

bob

[Jan van den Ende]

Larry,

though not exactly cheap, by far the CHEAPEST solution here is ... clustering.
Think about it as trying to re-do most of the work that Engineering did to realise clustering, without sharing the cost over many customers.
And as others have already told you about the risks of non-clustered dual access, I can only stress that more, much more.

But perhaps your salesdrone was thinking CA (Continuous Access). Not exactly cheap, way inferior, and much more complex compared to clustering.

If you go cluster: success!
If you go the alternate, I can only wish you (a lot of) good luck.

Proost.

Have one on me.

jpe

[Robert Gezelter]

Larry,

I concur with Andy, John, Bob, and Jan: Host based Volume Shadowing (known as HBVS) requires the existence of a cluster to operate in a multi-node environment).

With all due respect to your "sales guy", there may very well be an incorrect reading of the specifications around. Volume Shadowing for OpenVMS (see http://h71000.www7.hp.com/openvms/products/volume-shadowing/index.html) does indeed support operation in both standalone and clustered environments. However, operation in a non-clustered environment is limited to within a node. Underlying Shadowing for OpenVMS is the OpenVMS Lock Manager; of the, if not the most critical component of OpenVMS cluster support is the ability of the Lock Manager to manage locks across the OpenVMS cluster.

There have been some products from third party suppliers that supported shadowing configurations beyond those supported by Shadowing for OpenVMS. Before selecting one of these products, I would suggest a careful technical review to ensure that your needs are actually fulfilled.

I second the suggestion that someone who thoroughly understands these environments be consulted on the choices here [Disclosure: We provide such services, as do several other active participants in this forum.] It is deceptively simple to create a configuration with severe shortcomings; shortcomings that often only become manifest when the side effects become obvious.

- Bob Gezelter, http://www.rlgsc.com

[abrsvc]

One more vote added to the list here.

Clustering is the only supported way to accomplish your goal and is easy to build. I have a 2 node cluster set up at a client in a similar fashion as you wish. One node exists only to serve a set of drives for the 3rd shadow member disks. The system is set up to boot off of 2 separate roots with the system disk of cluster node 2 being an image copy of the main system disk. All drives are 3 member shadow sets (including the sytem disk). This gives me a complete copy of all drives in the disaster location should I need them.

If you factor the risk as well as maintenance costs to create the "non-cluster" option, you will soon find that it is more expensive and risky than the cluster.

Hope this helps,
Dan

Since Bob states it so well, I'll quote him here: "[Disclosure: I provide such services, as do several other active participants in this forum.] "

[Robert Brooks_1]

I've been told by our sales guy that it can be done.

--

Who is the "sales guy"? I work for HP, and would like to talk to him about his suggestion.

you email me at rab (at) hp.com

-- Rob

[Larry Dillon]

Thank you all for your thoughtful replies! I have forwarded this thread to my manager for consideration.

The final decision, of course, lies with the customer.