Yes, I normally want one server handling the full load to maximize the cache hits. But the other one should be up and running.
So, active/standby. Easier config. Squid won't even be aware that heartbeat is running; just keep it running on both servers all the time.
See my install notes at bottom.
And, because this is already in production as a mid-level cache working behind a loadbalancer, I would like to be able to keep answering on the M or N addresses, gradually reconfiguring the web servers in the farm to use address O instead of the loadbalancer VIP address.
Go for it. It'll work fine. You could get fancy and switch primary interface from M to O, and make M the VIP. Depends if you can accept the ~30 seconds of downtime and your tolerance for risk.
I got the impression from some of the docs/tutorials that it was a bad idea to access the M/N addresses directly.
In your case, it's only "bad" if M/N go down.
Or does that only apply to services where it is important to only have one instance alive at a time or where you are replicating data?
Depends on the service and replication setup. If you had master/slave MySQL and connected to the slave, you'd see amnesia on the master. (That setup wouldn't allow for fail-back though, so, probably wouldn't see it.) Things like drbd protect you from concurrent mounting.
Even after converting all of the farm to use the new address, I'll still want to be able to monitor the backup server to be sure it is still healthy.
Yup. And you'll want to monitor the active node and force-failover if the service fails. My config below doesn't take this into consideration; maybe other list lurkers can correct it to be better. The quick and dirty fix is to for each node to check if it is active, and if it is, if squid is not active, to then run 'service heartbeat restart' to failover to the other node. (I.e. once-a-minute cron job.) Not as pretty as it should be.
best, Jeff
Replace 1.2.3.4 with your VIP ip address, and a.example.com and b.example.com with your FQDN hostnames.
server A ("a.example.com"): yum -y install heartbeat chkconfig --add heartbeat chkconfig --level 345 heartbeat on
echo 'a.example.com IPaddr::1.2.3.4' > /etc/ha.d/haresources echo "node a.example.com" > /etc/ha.d/ha.cf echo "node b.example.com" >> /etc/ha.d/ha.cf echo "udpport 9000" >> /etc/ha.d/ha.cf echo "bcast bond0" >> /etc/ha.d/ha.cf echo "auto_failback off" >> /etc/ha.d/ha.cf echo "logfile /var/log/ha-log" >> /etc/ha.d/ha.cf echo "logfacility local0" >> /etc/ha.d/ha.cf echo "auth 1" > /etc/ha.d/authkeys echo "1 crc" >> /etc/ha.d/authkeys chmod go-rwx /etc/ha.d/authkeys
server B ("b.example.com"): yum -y install heartbeat chkconfig --add heartbeat chkconfig --level 345 heartbeat on
echo 'a.example.com IPaddr::1.2.3.4' > /etc/ha.d/haresources # yes, "a" again - that's the default host to run the service echo "node a.example.com" > /etc/ha.d/ha.cf echo "node b.example.com" >> /etc/ha.d/ha.cf echo "udpport 9000" >> /etc/ha.d/ha.cf echo "bcast bond0" >> /etc/ha.d/ha.cf echo "auto_failback off" >> /etc/ha.d/ha.cf echo "logfile /var/log/ha-log" >> /etc/ha.d/ha.cf echo "logfacility local0" >> /etc/ha.d/ha.cf echo "auth 1" > /etc/ha.d/authkeys echo "1 crc" >> /etc/ha.d/authkeys chmod go-rwx /etc/ha.d/authkeys
# This assumes: # 1) your network is bond0, not eth0 # 2) you are on a private network where you don't care about security, otherwise see http://www.linux-ha.org/authkeys # Make sure udpport isn't in use by any other instances; or, use mcast.
On server A: service heartbeat start # Then, check your log files (/var/log/ha-log and /var/log/messages). # Ping the virtual IP. On server B: service heartbeat start # check your log files
On server A: service heartbeat restart
On server B: ifconfig -a # Check if the interface is now runing on server B.
You can monitor current active node with arp -- the mac address will switch to match the physical interface that the VIP is running on.