Hi, On Wed, Feb 23, 2011 at 09:55:00AM +0000, Stallmann, Andreas wrote: > Hello! > > I'm currently looking for a suitable stonith solution for our environment: > > 1. We have three cluster nodes running OpenSuSE 10.3 with corosync and > pacemaker. > 2. The nodes reside on two VMware ESXi-Servers ( v. 4.1.0) in two locations, > where one VMware Server hosts two, the other hosts one node of our cluster. > 3. We will finally have a shared storage, which might or might not be under > our governance (this depends on the respective customer). > > I examined some stonith methods, with the following results (and I'd like to > have your opinion to my conclusions): > > - (2) rules out any stonith-method, that relies on a power switch or a UPS, > as the nodes are in no way physically connected to a power circuit. > - (3) rules out sbd, as this method requires access to a physical device, > that offers the shared storage. Am I right? The manual explicitly says, that > sbd may even not be used on a DRBD-Partition. Question: Is there a way to > insert the sbd-Header on a mounted drive instead of a physical partition? Are > there any other methods of ressource fencing besides sbd?
The only requirement for sbd is to have a dedicated disk on shared storage. That disk (or partition, if you will) doesn't need to be big (1MB is enough). I don't see how (3) then is an obstacle. > - (2) is not compatible with the vmware-stonith method, as it requires the > vmware-host to be reachable via one single IP-Adress. This isn't the case in > our szenario, the ESXi is not clustered. Question: Has anyone of you modified > the vmware-stonith script to fit to a set up similar to ours? > - the ssh-method is said to be not the wisest idea, as it requires the host > to respond to ssh-requests. If the SSH-Daemon hangs or the cluster runs into > a split-brain, this might not be the case anymore. Any other opinions? > > This, finally, leaves only one method: The suicide. Again, the SuSE > HAE-manual claims that this method is not suitable for production > environments because "This requires action by the node's operating system and > can fail under certain circumstances. Therefore avoid using this device > whenever possible." > > Well, as far as I'm concerned, letting a node shut itself down does not seem > that a bad idea. How's your experience with this method? No way telling if the suicide succeeded or not. > Final Question: Have I missed any suitable method? Are there any other > concepts of fencing / stonith, which I should give a closer look? There's also external/libvirt which hasn't been in any release yet, but seems to be of very good quality. You can get it here: http://hg.linux-ha.org/glue/file/tip/lib/plugins/stonith/external/libvirt and just put it into /usr/lib64/stonith/plugins/external > Thanks in advance for all your answer (and I can well live with a "RTFM", as > long as you point me to the fine manual), There's a document on fencing at http://clusterlabs.org Thanks, Dejan > > Andreas > > > > > ------------------------ > CONET Solutions GmbH, Theodor-Heuss-Allee 19, 53773 Hennef. > Registergericht/Registration Court: Amtsgericht Siegburg (HRB Nr. 9136) > Gesch?ftsf?hrer/Managing Directors: J?rgen Zender (Sprecher/Chairman), Anke > H?fer > Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Hans > J?rgen Niemeier > > CONET Technologies AG, Theodor-Heuss-Allee 19, 53773 Hennef. > Registergericht/Registration Court: Amtsgericht Siegburg (HRB Nr. 10328 ) > Vorstand/Member of the Managementboard: R?diger Zeyen (Sprecher/Chairman), > Wilfried P?tz > Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Gerd > Jakob > _______________________________________________ > Linux-HA mailing list > Linux-HA@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
