Alan Robertson wrote:
> Andrew Beekhof wrote:
>> On 8/8/07, NAKAHIRA Kazutomo <[EMAIL PROTECTED]> wrote:
>>> Hello, all.
>>>
>>> We wrote a Shared Disk File EXclusiveness Control Program, called
>>> "SF-EX" for short, could prevent a destruction of data on
>>> shared disk file system due to Split-Brain.
>>>
>>> This program consists of CUI commands written in the C and RA,
>>> the former is used for managing and monitoring shared disk status
>>> and the latter is the same as other common RAs.
>>>
>>> Your suggestions on how to improve are really appreciated.
>> Oddly enough i was just thinking about this and wondering why no-one
>> had written one yet.
>>
>> I understand the logic for making it into a quorum plugin, but I would
>> really love to see it useable in both ways. To me, you just can't
>> beat the simplicity and flexibility of making it an RA (whereas I am
>> somewhat cautious about involving the CCM, especially in it's
>> currently unmaintained state).
>
> We just put a set of bug fixes in the CCM, and have another set planned.
> How does that translate into "unmaintained". Few bugs filed against it
> would be better translated as "stable", not "unmaintained".
>
> If you have some CCM misbehaviors which you think need fixing, by all
> means create bugzillas for them, please. [I saw some mentioned in
> another thread].
Let me start off by agreeing with Andrew:
I see no technical reason not to provide the capability both ways,
provided that you are willing to create and maintain two interfaces to it.
If you are going to provide and support it only one way, I would suggest
that the quorum module would be the more useful of the two - for reasons
given below.
If one implements quorum as a resource, then everything which needs
quorum needs to depend on the quorum resource. Unfortunately, a quorum
resource in this case is not integrated with fencing. So, integrating
it as a quorum plugin has definite advantages which can't be easily
duplicated using a chain of dependencies.
I would suspect the description of it as a "simple" solution is a matter
of subjective opinion which I wouldn't find myself agreeing with. If I
were to look at which component to involve, I would look at the level of
integration into the total solution, introduction of new single points
of failure, probability of user misconfiguration, etc. Creating the set
of dependencies to make every resource in the cluster depend on this
resource is not complex, but it is tedious, error prone, and the kind of
thing which would be likely to be botched in some future update of the
CIB by a new administrator (i.e., the configuration would be "fragile").
It also makes this resource a single point of failure for the entire
cluster.
On the other hand, if you wanted to create a dedicated disk partition
for every resource group, then one could create a "resource driven
cluster" (similar to SteelEye's LifeKeeper). This would provide a
certain degree of flexibility, and would eliminate the single point of
failure aspect against all resources - while further increasing the
complexity of the solution. [It would remain an SPOF for each resource
group involved, but not for the cluster-as-a-whole].
I suspect there are some special cases where the resource model is a
clear winner, but my guess is that they are relatively rare.
Of course, if that happens to be your situation, then you'll likely be a
little happier if that capability is provided.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
