Thought I'd share my HA success with pound...most of this is FreeVRRP
specific but I figured people here may try this route at some point as
well...
The setup of FreeVRRPd on FreeBSD 4.9 was trivial, there is a port present
for 0.8.7. One problem I ran into was that if pound is running on the backup
machine already when FreeVRRPd fails over to the backup, traffic will not
pass to the VRRP addresses. I am guessing it is because pound was started
with ListenHTTP directives that refer to IP addresses that were not present
on the machine at the time pound was started. This seemed to be the case as
merely stopping and restarting pound on the backup after the failover
allowed the traffic to pass correctly.
My method around this was to use the 'masterscript' and 'backupscript'
directives in FreeVRRPd to stop and start pound when a failover occurs.
However this brought about the second problem I encountered. Apparently the
masterscript and backupscript directives will only take a reference to a
single file, not a file with options. Hence:
masterscript = "/usr/local/etc/pound.sh start"
backupscript = "/usr/local/etc/pound.sh stop" (or backupscript =
"/usr/bin/killall pound")
will not work. But creating a separate script for startup and shutdown like
so:
masterscript = "/usr/local/sbin/pound" (calling program directly, no options
possible!, or just create a single script with the options)
backupscript = "/usr/local/bin/killpound" (a script that just does a
'killall pound')
does work. I'm guessing the FreeVRRP software checks to see if the script
referenced is a simple file (exists), and fails if you try to put a space in
there to pass an option.
Lastly, FreeVRRPd replaces the MAC address on the interface, which will not
only affect the VRRP ip addresses, but also the 'real' ip address of the
machine. The docs (in broken english I cant quite understand) mention
something about not being able to have multiple MAC addresses on a single
interface on FreeBSD (if I'm understanding it right). This isn't a problem
for the VRRP ip addresses, but WILL cause the same ARP timeout issue with
the pix I've mentioned before on this list for just the real ip address.
While kludgy to me, this isn't a big problem. We won't be directing traffic
to the real ip address anyway, only the VRRP ones.
In addition, I would prefer to have a real (non-VRRP) ip address on the
pound machine on the inside interface, and NO ip addresses on the external
interface where the VRRP ip addresses go. However, FreeVRRPd complains
bitterly about this - it apparently won't put VRRP ip's on an interface
which doesn't already have SOME ip address on it. Not a huge deal though.
So in the final analysis, FreeVRRP works well for us in a testbed
environment to make pound truely HA. If this changes when we go into
production with it, I'll let folks know! I'll put my config files at the
bottom of this email in case folks want a reference. Time it takes for a
failover to occur - less than 3 seconds.
Regards,
Jay West
------master pound server-----
freevrrpd.conf:
[VRID]
serverid = 1
interface = xl0
priority = 255
addr = 172.16.110.10/32, 172.16.110.11/32, 172.16.110.12/32,
172.16.110.13/32, 172.16.110.14/32
password = notsillyenoughtoputminehere
masterscript = "/usr/local/sbin/pound"
backupscript = "/usr/local/sbin/killallpound" (note, not a typo - no space,
this is a script I wrote to do "killall pound")
backup pound server freevrrpd.conf is identical, with one exception,
priority = 254
pound.cfg:
ListenHTTP 172.16.110.10,80
ListenHTTPS 172.16.110.10,443
/usr/local/etc/certs/www.homedecorators.com.pem
ListenHTTP 172.16.110.11,80
ListenHTTPS 172.16.110.11,443
/usr/local/etc/certs/www.homedecoratorsoutlet.com.pem
ListenHTTP 172.16.110.12,80
ListenHTTPS 172.16.110.12,443
/usr/local/etc/certs/www.softsurroundings.com.pem
ListenHTTP 172.16.110.13,80
ListenHTTPS 172.16.110.13,443
/usr/local/etc/certs/www.softsurroundingsoutlet.com.pem
ListenHTTP 172.16.110.14,80
User root
Group wheel
LogLevel 3
Alive 10
Server 15
Client 10
UrlGroup ".*"
HeadRequire Host ".*hdc.dev.kwcorp.com.*"
BackEnd 172.16.13.10,80,1
BackEnd 172.16.13.30,80,1
EndGroup
(more similar stuff follows)
---
[This E-mail scanned for viruses by Declude Virus]
|
