3 Server solution

#
# Ldirectord will periodically connect to each real server
# and request a known URL. If the data returned by the server
# does not contain the the expected response then the
# test fails and the real server will be taken out of the available
# pool. The real server will be added back into the pool once the
# test succeeds. If all real servers are removed from the pool then
# localhost is added to the pool as a fallback measure.
#
# Based on the sample ldirectord.cf provided with ldirectord
#
# Prepared: February 2005
#

# Global Directives
checktimeout=10
checkinterval=2
#fallback=127.0.0.1:80
autoreload=no
#logfile="/var/log/ldirectord.log"
logfile="local0"
quiescent=yes

# Virtual Server for HTTP
virtual=xx.xxx.xxx.47:80
        fallback=127.0.0.1:80
        real=xx.xxx.xxx.43:80 masq
        real=xx.xxx.xxx.44:80 masq
        service=http
        request="index.cfm"
        receive="Motor Addicts"
        scheduler=rr
        persistent=600
        protocol=tcp
	checktype=negotiate

# Virtual Service for HTTPS
virtual=xx.xxx.xxx.47:80
        fallback=127.0.0.1:80
        real=xx.xxx.xxx.43:80 masq
        real=xx.xxx.xxx.44:80 masq
        service=https
        request="index.cfm"
        receive="Motor Addicts"
        scheduler=rr
        persistent=600
        protocol=tcp
	checktype=negotiate

# Virtual Service for FTP
# Note that peresistancy needs to be turned on for FTP when
# used with LVS-TUN (ipip) or LVS-DR (gate), but not with LVS-NAT (masq).
#virtual=192.168.6.240:21
#        fallback=127.0.0.1:21
#        real=192.168.7.4:21 masq
#        real=192.168.7.5:21 masq
#        service=ftp
#        request="welcome.msg"
#        receive="Welcome"
# 	login="anonymous"
#        passwd="[email protected]"
#        scheduler=rr
#        #persistent=600
#        protocol=tcp
#	checktype=negotiate

## Virtual Service for IMAP
#virtual=192.168.6.240:143
#        fallback=127.0.0.1:143
#        real=192.168.7.4:143 masq
#        real=192.168.7.5:143 masq
#        service=imap
# 	#login="test"
#        #passwd="test"
#        scheduler=rr
#        #persistent=600
#        protocol=tcp
#        checktype=negotiate
#
## Virtual Service for POP
#virtual=192.168.6.240:110
#        fallback=127.0.0.1:110
#        real=192.168.7.4:110 masq
#        real=192.168.7.5:110 masq
#        service=pop
# 	#login="test"
#        #passwd="test"
#        scheduler=rr
#        #persistent=600
#        protocol=tcp
#
## Virtual Service for SMTP
#virtual=192.168.6.240:25
#        fallback=127.0.0.1:25
#        real=192.168.7.4:25 masq
#        real=192.168.7.5:25 masq
#        service=smtp
#        scheduler=rr
#        #persistent=600
#        protocol=tcp
#
## Virtual Service for LDAP
#virtual=192.168.6.240:389
#        fallback=127.0.0.1:389
#        real=192.168.7.4:389 masq
#        real=192.168.7.5:389 masq
#        service=ldap
#        scheduler=rr
#        #persistent=600
#        protocol=tcp
#

#Sample configuration for an nntp virtual service.
#Fallback setting overides global
#virtual=192.168.6.240:119
#	real=192.168.7.4:119 masq
#	real=192.168.7.5:119 masq
#	fallback=127.0.0.1:119
#	service=nntp
#	scheduler=wlc
#	#persistent=600
#	#netmask=255.255.255.255
#	protocol=tcp

#Sample configuration for a UDP DNS virtual service.
#Fallback setting overides global
#virtual=192.168.6.240:53
#	real=192.168.7.4:53 masq
#	real=192.168.7.5:53 masq
#	fallback=127.0.0.1:53
#	request="some.domain.com.au"
#	recieve="127.0.0.1"
#	service=dns
#	scheduler=wlc
#	#persistent=600
#	#netmask=255.255.255.255
#	protocol=udp

#Sample configuration for a MySQL virtual service.
#virtual = 192.168.6.240:3306
#	real=192.168.7.4:3306 masq
#	real=192.168.7.5:3306 masq
#	fallback=127.0.0.1:3306 masq
#	checktype = negotiate
#	login = "readuser"
#	passwd = "genericpassword"
#	database = "portal"
#	request = "SELECT * FROM link"
#	scheduler = wrr

#Sample configuration for an unsuported protocol
#The real servers will just be brought up without checking for availability
#Fallback setting overides global
#virtual=192.168.6.240:23
#	real=192.168.7.4:23 masq 
#	real=192.168.7.5:23 masq
#	fallback=127.0.0.1:21
#	service=none
#	scheduler=wlc
#	request="welcome.msg"
#	receive="test"         
#	persistent=600
#	#netmask=255.255.255.255
#	protocol=tcp

#
#        /etc/ha.d/haresources
# 
#        haresources to configure heartbeat with a master host b1.
#        Heartbeat will take over one IP address.
#
#        Based on sample haresources file shipped with heartbeat
#
#        Prepared: July 2005
#

#
#	This is a list of resources that move from machine to machine as
#	nodes go down and come up in the cluster.  Do not include
#	"administrative" or fixed IP addresses in this file.
#
# <VERY IMPORTANT NOTE>
#	The haresources files MUST BE IDENTICAL on all nodes of the cluster.
#
#	The node names listed in front of the resource group information
#	is the name of the preferred node to run the service.  It is
#	not necessarily the name of the current machine.  If you are running
#	auto_failback ON (or legacy), then these services will be started
#	up on the preferred nodes - any time they're up.
#
#	If you are running with auto_failback OFF, then the node information
#	will be used in the case of a simultaneous start-up, or when using
#	the hb_standby {foreign,local} command.
#
#	BUT FOR ALL OF THESE CASES, the haresources files MUST BE IDENTICAL.
#	If your files are different then almost certainly something
#	won't work right.
# </VERY IMPORTANT NOTE>
#
#	
#	We refer to this file when we're coming up, and when a machine is being
#	taken over after going down.
#
#	You need to make this right for your installation, then install it in
#	/etc/ha.d
#
#	Each logical line in the file constitutes a "resource group".
#	A resource group is a list of resources which move together from
#	one node to another - in the order listed.  It is assumed that there
#	is no relationship between different resource groups.  These
#	resource in a resource group are started left-to-right, and stopped
#	right-to-left.  Long lists of resources can be continued from line
#	to line by ending the lines with backslashes ("\").
#
#	These resources in this file are either IP addresses, or the name
#	of scripts to run to "start" or "stop" the given resource.
#
#	The format is like this:
#
#node-name resource1 resource2 ... resourceN
#
#
#	If the resource name contains an :: in the middle of it, the
#	part after the :: is passed to the resource script as an argument.
#       Multiple arguments are separated by the :: delimeter
#
#	In the case of IP addresses, the resource script name IPaddr is
#	implied.
#
#	For example, the IP address 135.9.8.7 could also be represented
#	as IPaddr::135.9.8.7
#
#	THIS IS IMPORTANT!!     vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
#
#	The given IP address is directed to an interface which has a route
#	to the given address.  This means you have to have a net route
#	set up outside of the High-Availability structure.  We don't set it
#	up here -- we key off of it.
#
#	The broadcast address for the IP alias that is created to support
#	an IP address defaults to the highest address on the subnet.
#
#	The netmask for the IP alias that is created defaults to the same
#	netmask as the route that it selected in in the step above.
#
#	The base interface for the IPalias that is created defaults to the
#	same netmask as the route that it selected in in the step above.
#
#	If you want to specify that this IP address is to be brought up
#	on a subnet with a netmask of 255.255.255.0, you would specify
#	this as IPaddr::135.9.8.7/24 .  
#
#	If you wished to tell it that the broadcast address for this subnet
#	was 135.9.8.210, then you would specify that this way:
#		IPaddr::135.9.8.7/24/135.9.8.210
#
#	If you wished to tell it that the interface to add the address to
#	is eth0, then you would need to specify it this way:
#		IPaddr::135.9.8.7/24/eth0
#
#       And this way to specify both the broadcast address and the
#       interface:
#		IPaddr::135.9.8.7/24/eth0/135.9.8.210
#
#	The IP addresses you list in this file are called "service" addresses,
#	since they're they're the publicly advertised addresses that clients
#	use to get at highly available services.
#
#	For a hot/standby (non load-sharing) 2-node system with only
#	a single service address, 
#	you will probably only put one system name and one IP address in here.
#	The name you give the address to is the name of the default "hot"
#	system.
#
#	Where the nodename is the name of the node which "normally" owns the
#	resource.  If this machine is up, it will always have the resource
#	it is shown as owning.
#
#	The string you put in for nodename must match the uname -n name
#	of your machine.  Depending on how you have it administered, it could
#	be a short name or a FQDN.
#
#-------------------------------------------------------------------
#
#	Simple case: One service address, default subnet and netmask
#		No servers that go up and down with the IP address
#
#just.linux-ha.org	135.9.216.110
#
#-------------------------------------------------------------------
#
#	Assuming the adminstrative addresses are on the same subnet...
#	A little more complex case: One service address, default subnet
#	and netmask, and you want to start and stop http when you get
#	the IP address...
#
#just.linux-ha.org	135.9.216.110 http
#-------------------------------------------------------------------
#
#	A little more complex case: Three service addresses, default subnet
#	and netmask, and you want to start and stop http when you get
#	the IP address...
#
#just.linux-ha.org	135.9.216.110 135.9.215.111 135.9.216.112 httpd
#-------------------------------------------------------------------
#
#	One service address, with the subnet, interface and bcast addr
#       explicitly defined.
#
#just.linux-ha.org	135.9.216.3/28/eth0/135.9.216.12 httpd
#
#-------------------------------------------------------------------
#
#       An example where a shared filesystem is to be used.
#       Note that multiple aguments are passed to this script using
#       the delimiter '::' to separate each argument.
#
#node1  10.0.0.170 Filesystem::/dev/sda1::/data1::ext2
#
#	Regarding the node-names in this file:
#
#	They must match the names of the nodes listed in ha.cf, which in turn
#	must match the `uname -n` of some node in the cluster.  So they aren't
#	virtual in any sense of the word.
#
lb01-s15 \
	LVSSyncDaemonSwap::master \
	ldirectord::ldirectord.cf \
	IPaddr2::xx.xxx.xx.47/25/eth0

#
# /etc/ha.d/authkeys
# 
# Sample authkeys file. You should change the key and set the mode 
# to 600
#
# Based on sample ha.cf shipped with heartbeat
#
# Prepared: February 2005
#


#
#	Authentication file.  Must be mode 600
#
#
#	Must have exactly one auth directive at the front.
#	auth	send authentication using this method-id
#
#	Then, list the method and key that go with that method-id
#
#	Available methods: crc sha1, md5.  Crc doesn't need/want a key.
#
#	You normally only have one authentication method-id listed in this file
#
#	Put more than one to make a smooth transition when changing auth
#	methods and/or keys.
#
#
#	sha1 is believed to be the "best", md5 next best.
#
#	crc adds no security, except from packet corruption.
#		Use only on physically secure networks.
#
auth 2
#1 crc
2 sha1 testingthis
#3 md5 Hello!

#
# /etc/ha.d/ha.cf
# 
# ha.cf file to configure two nodes connected by ethernet (eth0 and eth1)
#
# Based on sample ha.cf shipped with heartbeat
#
# Prepared: February 2005
#

#
#	There are lots of options in this file.  All you have to have is a set
#	of nodes listed {"node ...} one of {serial, bcast, mcast, or ucast},
#	and a value for "auto_failback".
#
#	ATTENTION: As the configuration file is read line by line,
#		   THE ORDER OF DIRECTIVE MATTERS!
#
#	In particular, make sure that the udpport, serial baud rate
#	etc. are set before the heartbeat media are defined!
#	debug and log file directives go into effect when they
#	are encountered.
#
#	All will be fine if you keep them ordered as in this example.
#
#
#       Note on logging:
#       If any of debugfile, logfile and logfacility are defined then they
#       will be used. If debugfile and/or logfile are not defined and
#       logfacility is defined then the respective logging and debug
#       messages will be loged to syslog. If logfacility is not defined
#       then debugfile and logfile will be used to log messges. If
#       logfacility is not defined and debugfile and/or logfile are not
#       defined then defaults will be used for debugfile and logfile as
#       required and messages will be sent there.
#
#	File to write debug messages to
debugfile /var/log/ha-debug
#
#
# 	File to write other messages to
#
logfile	/var/log/ha-log
#
#
#	Facility to use for syslog()/logger 
#
logfacility	local0
#
#
#	A note on specifying "how long" times below...
#
#	The default time unit is seconds
#		10 means ten seconds
#
#	You can also specify them in milliseconds
#		1500ms means 1.5 seconds
#
#
#	keepalive: how long between heartbeats?
#
keepalive 2
#
#	deadtime: how long-to-declare-host-dead?
#
#		If you set this too low you will get the problematic
#		split-brain (or cluster partition) problem.
#		See the FAQ for how to use warntime to tune deadtime.
#
deadtime 30
#
#	warntime: how long before issuing "late heartbeat" warning?
#	See the FAQ for how to use warntime to tune deadtime.
#
warntime 10
#
#
#	Very first dead time (initdead)
#
#	On some machines/OSes, etc. the network takes a while to come up
#	and start working right after you've been rebooted.  As a result
#	we have a separate dead time for when things first come up.
#	It should be at least twice the normal dead time.
#
initdead 120
#
#
#	What UDP port to use for bcast/ucast communication?
#
#udpport	694
#
#	Baud rate for serial ports...
#
#baud	19200
#	
#	serial	serialportname ...
#serial	/dev/ttyS0	# Linux
#serial	/dev/cuaa0	# FreeBSD
#serial	/dev/cua/a	# Solaris
#
#
#	What interfaces to broadcast heartbeats over?
#
#bcast	eth0		# Linux
#bcast	eth1 eth2	# Linux
#bcast	le0		# Solaris
#bcast	le1 le2		# Solaris
#
#	Set up a multicast heartbeat medium
#	mcast [dev] [mcast group] [port] [ttl] [loop]
#
#	[dev]		device to send/rcv heartbeats on
#	[mcast group]	multicast group to join (class D multicast address
#			224.0.0.0 - 239.255.255.255)
#	[port]		udp port to sendto/rcvfrom (set this value to the
#			same value as "udpport" above)
#	[ttl]		the ttl value for outbound heartbeats.  this effects
#			how far the multicast packet will propagate.  (0-255)
#			Must be greater than zero.
#	[loop]		toggles loopback for outbound multicast heartbeats.
#			if enabled, an outbound packet will be looped back and
#			received by the interface it was sent on. (0 or 1)
#			Set this value to zero.
#		
#
mcast eth0 225.0.0.1 694 1 0
#mcast eth1 225.0.0.1 694 1 0
#
#	Set up a unicast / udp heartbeat medium
#	ucast [dev] [peer-ip-addr]
#
#	[dev]		device to send/rcv heartbeats on
#	[peer-ip-addr]	IP address of peer to send packets to
#
#ucast eth0 172.17.60.200
#
#
#	About boolean values...
#
#	Any of the following case-insensitive values will work for true:
#		true, on, yes, y, 1
#	Any of the following case-insensitive values will work for false:
#		false, off, no, n, 0
#
#
#
#	auto_failback:  determines whether a resource will
#	automatically fail back to its "primary" node, or remain
#	on whatever node is serving it until that node fails, or
#	an administrator intervenes.
#
#	The possible values for auto_failback are:
#		on	- enable automatic failbacks
#		off	- disable automatic failbacks
#		legacy	- enable automatic failbacks in systems
#			where all nodes do not yet support
#			the auto_failback option.
#
#	auto_failback "on" and "off" are backwards compatible with the old
#		"nice_failback on" setting.
#
#	See the FAQ for information on how to convert
#		from "legacy" to "on" without a flash cut.
#		(i.e., using a "rolling upgrade" process)
#
#	The default value for auto_failback is "legacy", which
#	will issue a warning at startup.  So, make sure you put
#	an auto_failback directive in your ha.cf file.
#	(note: auto_failback can be any boolean or "legacy")
#
auto_failback on
#
#
#       Basic STONITH support
#       Using this directive assumes that there is one stonith 
#       device in the cluster.  Parameters to this device are 
#       read from a configuration file. The format of this line is:
#
#         stonith <stonith_type> <configfile>
#
#       NOTE: it is up to you to maintain this file on each node in the
#       cluster!
#
#stonith baytech /etc/ha.d/conf/stonith.baytech
#
#       STONITH support
#       You can configure multiple stonith devices using this directive.
#       The format of the line is:
#         stonith_host <hostfrom> <stonith_type> <params...>
#         <hostfrom> is the machine the stonith device is attached
#              to or * to mean it is accessible from any host. 
#         <stonith_type> is the type of stonith device (a list of
#              supported drives is in /usr/lib/stonith.)
#         <params...> are driver specific parameters.  To see the
#              format for a particular device, run:
#           stonith -l -t <stonith_type> 
#
#
#	Note that if you put your stonith device access information in
#	here, and you make this file publically readable, you're asking
#	for a denial of service attack ;-)
#
#	To get a list of supported stonith devices, run
#		stonith -L
#	For detailed information on which stonith devices are supported
#	and their detailed configuration options, run this command:
#		stonith -h
#
#stonith_host *     baytech 10.0.0.3 mylogin mysecretpassword
#stonith_host ken3  rps10 /dev/ttyS1 kathy 0 
#stonith_host kathy rps10 /dev/ttyS1 ken3 0 
#
#	Watchdog is the watchdog timer.  If our own heart doesn't beat for
#	a minute, then our machine will reboot.
#	NOTE: If you are using the software watchdog, you very likely
#	wish to load the module with the parameter "nowayout=0" or
#	compile it without CONFIG_WATCHDOG_NOWAYOUT set. Otherwise even
#	an orderly shutdown of heartbeat will trigger a reboot, which is
#	very likely NOT what you want.
#
#watchdog /dev/watchdog
#       
#	Tell what machines are in the cluster
#	node	nodename ...	-- must match uname -n
node	lb01-s15
node	lb01-s16
#
#	Less common options...
#
#	Treats 192.168.6.254 as a psuedo-cluster-member
#	Used together with ipfail below...
#
ping xx.xxx.xxx.45
ping xx.xxx.xxx.44
#
#	Treats 10.10.10.254 and 10.10.10.253 as a psuedo-cluster-member
#       called group1. If either 10.10.10.254 or 10.10.10.253 are up
#       then group1 is up
#	Used together with ipfail below...
#
#ping_group group1 10.10.10.254 10.10.10.253
#
#	Processes started and stopped with heartbeat.  Restarted unless
#		they exit with rc=100
#
#respawn userid /path/name/to/run
respawn hacluster /usr/lib/heartbeat/ipfail

###########################
#
#	Unusual options.
#
###########################
#
#	hopfudge maximum hop count minus number of nodes in config
#hopfudge 1
#
#	deadping - dead time for ping nodes
#deadping 30
#
#	hbgenmethod - Heartbeat generation number creation method
#		Normally these are stored on disk and incremented as needed.
#hbgenmethod time
#
#	realtime - enable/disable realtime execution (high priority, etc.)
#		defaults to on
#realtime off
#
#	debug - set debug level
#		defaults to zero
#debug 1
#
#	API Authentication - replaces the fifo-permissions-based system of the past
#
#
#	You can put a uid list and/or a gid list.
#	If you put both, then a process is authorized if it qualifies under either
#	the uid list, or under the gid list.
#
#	The groupname "default" has special meaning.  If it is specified, then
#	this will be used for authorizing groupless clients, and any client groups
#	not otherwise specified.
#
apiauth ipfail gid=haclient uid=hacluster
#apiauth ccm uid=hacluster
#apiauth ipfail gid=haclient uid=alanr,root
#apiauth default gid=haclient

# message format in the wire, it can be classic or netstring, default is classic
#msgfmt  netstring