On 08/21/2012 12:22 PM, Dimitri Maziuk wrote: >> 1. We monitor the Apache services on these two hosts with a service >> monitoring app that can't be told "only one of these two must be running". > > I monitor apache on cluster ip and separately monitor heartbeat on the > nodes (via net-snmp's "proc" extension).
Interesting strategy, but as I said in #2, we have plans to use these servers independent of the cluster, so I do (or at least will) care about more than just the cluster IP and Heartbeat on the nodes. If we can't make this work, we will have to abandon those future plans and I will most likely change my service monitoring strategy to mirror yours. Thanks for the idea! >> 3. For some reason, it takes a good 5-10 seconds for Apache to start >> after a failover occurs. The IPAddr2 and MailTo resources start within 2 >> seconds, but Apache takes longer. > > I'd repost with "apache takes 5-10s to failover" subject line. I get <5 > sec failovers with drbd and mysql and tomcat in addition to apache, so I > think you do have an issue there. (But I run my active/passive clusters > on heartbeat-R1, so can't help with your setup.) Yes, I could do that, but that would only satisfy my reason #3... #1 and #2 require Apache to be running (or at least make a best effort to have it running) on both nodes all the time, so that doesn't really get me very far. To the others on the list: I can think of plenty of cases where it would be helpful to have the option to have a single "always hot" resource-- surely it's possible, don't you think? I admit to a little ignorance on this, but I'm imagining that the LSB functionality is hardcoded into Heartbeat (with parameters passed through obviously), but if I switched to the OCF version, couldn't I hack the resource script to skip the actual stop command on resource "stop"? -- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- https://console.mxlogic.com/redir/?5OWbP5PhOOrppjvKesjdw0y2Ii769kJTEdCXYyMCY-ehojd79KVI-k6MYKjQKgGT2TQ1hYGjFNYEdxVsDL00jrWdTzqbb3XUVBB4QsCT3hOr1vF6y0QJxmk6MYK5N0QKCy0a_FDPh08broDVEwyT24E4jh1m1Ew8lCjd46SD8PVEwS21EwmSB96vd44aEvgArDUvf5zZB0SyrhdIIFLT78ECTdQTOwYWP8dL _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
