Re: GFS over AOE without fencing?

[Jayson Vantuyl <jvantuyl@xxxxxxxxxxxxxx>]

It is supposedly possible to script using the mask command to block servers on individual MAC address to the AoE storage.  While this is often offered by Coraid support as an option, I've not seen anyone implement it.  To be sure, I have my doubts about it anyways, give that the utility that you automate (cec) does not exactly provide an API (you actually are writing directly into the unit's console!).

On Apr 17, 2007, at 8:05 AM, Kadlecsik Jozsi wrote:

Hi Bryn,

On Tue, 17 Apr 2007, Bryn M. Reeves wrote:

Assuming a dedicated VLAN which servers only AOE and GFS traffic among 

the Coraid boxes and the GFS hosts, is there any need for fencing at all?

What are the hidden traps behind such setups?

Best regards,

Jozsef

If you are using GFS on shared storage then you need fencing. Period.

The only way you can guarantee data integrity in this scenario is by

completely cutting a failed or misbehaving node off from the storage;

either by power cycling it or having the storage reject its access.

Otherwise, imagine a situation where a node hangs for some reason and is

ejected from the cluster. At this point none of its locks for the shared

data are valid anymore. Some time later, the node recovers from the hang

and begins flushing writes to the storage -> corruption.

I see - the sentences above make much more clearer why fencing is needed.

Thank you the explanation - and the hint for the possibility to reject 

the access at the storage itself!

Best regards,

Jozsef

--

E-mail : kadlec@xxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxxxx

PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt

Address: KFKI Research Institute for Particle and Nuclear Physics

         H-1525 Budapest 114, POB. 49, Hungary

--

Linux-cluster mailing list

Linux-cluster@xxxxxxxxxx

https://www.redhat.com/mailman/listinfo/linux-cluster

-- 

Jayson Vantuyl

Systems Architect

Engine Yard

jvantuyl@xxxxxxxxxxxxxx

--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster