On 5/8/06, Lars Marowsky-Bree <[email protected]> wrote:
On 2006-05-08T16:17:07, Circuitsoft Development <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
