Re: Fwd: Fwd: Extended Volume Manager API

[Circuitsoft Development]

On 5/8/06, Lars Marowsky-Bree <lmb@xxxxxxx> wrote:
> On 2006-05-08T16:17:07, Circuitsoft Development <circuitsoft.devel@xxxxxxxxx> wrote:
>
> > I'm not. They also need to get permission from the network before they
> > write to the disk, and they're not going to get permission without
> > hearing back from everybody. Besides, since the same network is used
> > to connect to the disks as is used to connect the computers to each
> > other, how would it be able to access the disks without being able to
> > access other computers which also connect to the disks?
>
> You really should read up about split-brain scenarios

I don't see how they'll happen if the heartbeat/management runs over
the same network that is used to connect to the disk.

> quorum

I'm aware of the idea. I think that a static quorum would be best, and
that it should be configured by the cluster administrator. See
http://lists.osdl.org/pipermail/osdlcluster/2004-January/000071.html
for a description of the problem with dynamic quorum.

> IO fencing

The primary target storage protocol is ATA-over-Ethernet, second is
iSCSI. As far as I know, it should be relatively simple, in both
circumstances, to tell the storage blade to cut off a computer until
it correctly re-registers itself with the cluster. Otherwise, a CISCO
managed switch should also be able to cut off a computer if it stops
responding to the cluster.

> cluster membership algorithms

Having trouble finding too many details on these. I'll keep looking,
but some pointers could be helpful.

> and the amazing variety of different types of crashes.

I figured that IO Fencing combined with STONITH (Shoot The Other Node
In The Head) could solve the problems caused by most crashes.

> Sincerely,
>     Lars Marowsky-Brée
>
> --
> High Availability & Clustering
> SUSE Labs, Research and Development
> SUSE LINUX Products GmbH - A Novell Business     -- Charles Darwin
> "Ignorance more frequently begets confidence than does knowledge"

These thoughts are based on my best understanding of how-stuff-works
so far. Any further comments would be greatly appreciated.


- Alex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/