HP clustering white paper - what do YOU think of the way VMS is pictured?

[Jan van den Ende]

http://h71028.www7.hp.com/ERC/downloads/4AA0-6737ENW.pdf

how about:
- high risk of split-brain cluster
- recovery? manual

As I read this, it would be hard to use this whitepaper as an argument in favor of VMS.

Has anyone in Engebeering proof-read this?

Is this the way MP brings out the message about VMS releiability?

Or maybe my reading of English texts needs improvement?

Proost.

Have one on me.

jpe

[Paul Jerrom]

Hhmm...from a VMS perspective, very poorly written. An independant person basing an opinion on this brichure only would be hard pressed to justify going with a vms solution.

What a shame that the speed of light only affects VMS clusters!!

[labadie_1]

It is a shame to see such documents, when you know excellent material is available on Keith Parris site (and Keith is an HP employee), see

- Comparing Vms Clusters and Tru64 Clusters (Ok, Tru64 is dead)
http://www.geocities.com/keithparris/decus_presentations/f2000_vmsclusters_cf_truclusters.ppt

- Using Openvms Cluster for Disaster Tolerance
http://www.openvms.compaq.com/openvms/journal/index.html

and many others excellents documents.

[Uwe Zessin]

It doesn't look so bad to me - I think you want to see it as negative.

The two-site split-brain problem is real and the paper clearly mentions a quorum site or a quorum disk at one site.

The manual 'recovery process' correctly describes local clusters or a local cluster with data replication to a second site at which a second 'failover cluster' resides.

> What a shame that the speed of light only affects VMS clusters!!

The other clusters don't use shared volumes with a distributed lock manager which needs fast response times. Some other solutions use asynchronous replication technologies coupled with failover mechanisms.

[Jan van den Ende]

Did I really write Engebeering? What would a shrink make of that? Of course it should be Engeneering !!!!

Uwe,

although maybe technically not completely incorrect if you are dealing with 2 different, replicated clusters (anyone know of such construct in production?), I really thought that a correct setup of the VOTES-EXPECTED_VOTES values prevented the split-brain. It is also the reason why a QUORUM disk should NEVER be replicated!

Then again, _IF_ you should replicate from one node to another, what is the relevance of the speed of light in that config?

And although it IS possible to use replication (one master, one copied dataset), in a VMS environment with full clustering HBVS is much more common, and very superior.


It is the entire "feel" of the way VMS clustering is portrayed.
My feeling on this is along the lines of Paul and Gerard: this whitepaper does not exactly highlight the virtues of VMS. I very much doubt if the text would have come out as it is, had Keith Parris done or supervised the proof-reading!

Proost.

Have one on me.

jpe

[Uwe Zessin]

No, the second 'cluster' is supposed to pick up the replicated storage after the primary failed - this is not a stretched cluster (described later).

And, like I wrote, the document _is_ talking about a quorum disk/node later on:
""To avoid the headaches that this syndrome may cause, a quorum site or establishment of a quorum disk at one site is highly recommended.""

Of course you can replicate the quorum disk! It will just not be presented to the hosts (like all other disks) at the destination site until a failover is made.

The speed of light is relevant if you use synchronous replication, because the host only gets a response after the destination storage confirmed that it received the data.

[Bart Zorn_1]

During one of the training seminars given by Keith Parris at the CETS 2000 conference in LA I had the hounour to assist Keith in trying to create a partitioned cluster. It took us many attempts and several hours to accomplish that! And once we got it, it appears that disks do not get corrupted easily as a whole, but individual files may!

But on the other hand, is it even possible to have a partitioned cluster with brain-dead share-nothing clusters? If not, the risk with VMS is significantly higher!

Bart Zorn

[Robert Gezelter]

Jan,

I took a cursory read through the HP whitepaper over the weekend, I will reserve my full comments until I have had the chance to review it in an unhurried fashion.

However, I suspect the problem is along the lines of not giving a clear impression of the power and flexibility of the OpenVMS cluster. In general, the other clustering (and I do not like calling them "clusters") designs do not give the flexibility that one has with OpenVMS.

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

[Andreas Vollmer]

Hello Jan,
The document is not so bad!
It is a fact, the speed of light is the measure of all. Nothing is faster...
Every hop caused by a switch or router will delay the signal.
I agree with Uwe's statement, as longer the distance as less the chances for a synchronous data transfer (price / performance ratio).
It is the design of the application that enables a disaster tolerant setup and how.

One thing in the document should be improved:
The setup respectively the management of the "Basic OpenVMS high availibilty", page 8.
The recovery is theoretically full manually but for sure every system & IT manager will test the recovery and will partly automatizing the recovery process.
This should be mentioned in the document. So on one hand it is a fully manual recover process on the other hand this can be optimised and partly automized.

Also the mentioned distance of 60'000 miles,
this sounds a little bit strange.
60'000 miles are approx. 96'000 km. The earth circumfence is approx 24'800 miles (40'000km). Do they (HP) have a cluster in space or is it only a typo error?

Andreas