Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, Digimer wrote, > I understand the rationale and disagree with it, strongly. The build > order should be; > > 1. Initial node config > 2. Stonith > 3. everything else > > Stonith is not a feature, it is a requirement of any sane setup, full stop. > > Quoting the fine documentation: > > > > "stonith-enable=false tells the cluster to simply pretend that failed > > nodes are safely powered off". > > You can drive your car without seatbelts, too. You can pull the fuse on > your airbag system. You car still moves. > > I have yet to see a use-case where disabling stonith is a valid setup. We are using DRBD on our management system (monitoring, backup, update of the other cluster systems) for non-important data. Icinga status file, intermediate backup files, ... To avoid split-brain we use pingd, which helps for simple network problems. If the data is lost, we can simple rebuild the DRBD, as our important data is either in a master-master ldap or master-master mysql database. It is not always possible to setup STONITH if you don't get access to the underlying ESXi hosts or hardware. So I think we have a valid use-case for DRBD+Pacemaker without STONITH+Fencing. best regards Waldemar