Fellows, My Heartbeat set up is almost good to get into production. We just need to decide and implement a better solution for the STONITH procedure. We've been using the "dummy" solution so far.
I have a somewhat unusual set up, with two clusters running MySQL database servers: a "Replication Master Cluster" and a "Replication Slave Cluster", both consisting of two identical hosts. I call my solution unusual because every node in both clusters is located in a different data centre (I can not afford to stop my service because I lost of connectivity with a single data centre). That means that there's little or no possibility of getting serial access to the power console that controls the peer of a given host as it's physically impossible to pull the necessary cables (for several reasons). At this moment, I am working with mainly two alternatives: meatware or a custom driver for STONITH, that will make a single SSH call with a specially crafted key to trigger some action from the remote power console. As a solution, meatware is a proven, well-tested solution that is distributed as part of the heartbeat standard software. It also doesn't relies on the network, which is a good thing. On the down side, it requires a human operator, causing long delays for the service take over. It also will require more training for the operators, which is not desirable (they have a lot in their plate, already). On the other hand, the promise of fast and automatic service recovery without the intervention of a human operator, the lack of need for operator specific training and know-how may compensate for the fact that the solution depends on the Network and a custom driver, and it's not largely tested (as all good home-grown solutions). Given that, I would like to have your technical advice. What solution would you recommend me, given the aforementioned restrictions? Thanks a lot in advance. Regards. -- Luis Motta Campos is a software engineer, Perl Programmer, foodie and photographer. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
