Mailing List Archive

[mod_backhand-users] Success with IPVS, heartbeat, ldirectord and mod_backhand
I just want to report on my progress to get an inexpensive HA cluster
working with mod_backhand.

I've successfully installed these packages to provide enough reliability
and scaling to suit my needs. Theo, you won't need to develop
half-proxying for mod_backhand :)

A quick question for Theo though: the patch you show on your site for
forcing keep-alive for pipelined backhand proxy requests, is it
available for apache 1.3.17? I haven't been able to apply it to my
install, and I'd really like to minimize the number of spawned
connections. I guess I can still go manually through the code...

These packages were installed, and patches applied to kernel 2.4.2:

- IPVS Netfilter module for kernel 2.4
(http://www.LinuxVirtualServer.org/software/kernel-2.4/ipvs-0.2.5.tar.gz)
- Heartbeat (http://linux-ha.org/download/heartbeat-0.4.8-1.i386.rpm)


What I did to install:

- Install the heartbeat RPM
- Install ldirectord 1.25 from the IPVS distribution (replaces
ldirectord 1.11 from heartbeat)
- Install ipvsadm from the IPVS distribution
- Install the "hidden" ARP patch to kernel 2.4 (included in IPVS
distribution)
- Install the loadable module patch for IPVS to kernel 2.4 (the static
compilation method would cause my machines to not reboot)
- Compile the IPVS modules (I put them in the /etc/ha.d tree)
- Rebuild kernel and reboot
- Configure heartbeat and ldirectord (configuration examples at
ultramonkey, see below)

This is the topology I have implemented:

http://ultramonkey.sourceforge.net/ultramonkey-1.0.2beta0/topologies/example-ha-lb-5.html

Except that I have three machines, and my director machines (2) are also
servicing requests. For it to work, one hack I had to do to hearbeat. An
aliased loopback interface is required for the machines to service
requests on the virtual ip (VIP) and return directly to the clients (in
Direct Routing mode). You don't need this with masquerade.

If a loopback interface is present on a director, heartbeat will always
assume that someone else has the VIP and not try to be master. So no one
becomes master. To correct this, I applied changes (kludges, really) to
the /etc/ha.d/resource.d/IPaddr utility (which is used to detect if we
have the VIP) to ensure that:

1) when the loopback interface is present, that it is not used in the
heartbeat decision-making process
2) That the loopback interface is brought down when we acquire the VIP
address
3) That if we relinquish the VIP, that the loopback interface is brought
back up.

(see at bottom what the patch looks like (VIP 1.1.1.1 and lo:0 as
examples)

I have configured ldirectord to distribute requests with wrr (weighted
round-robin), to optimize performance and give a measure of control over
where the requests go. I use Direct Routing (a.k.a Direct Return a.k.a
half-proxy) to allow the machines to respond directly to clients.

I leave all load decisions to mod_backhand.

Now, if a director fails, the other director takes over the VIP. If an
apache server is stopped, it is taken out of the available pool.
Vice-versa. My kind of setup :)

I've found the following documentation to be very, very useful:

http://ultramonkey.sourceforge.net/
http://www.linuxvirtualserver.org/
http://linux-ha.org/

If anyone has ideas on how to maximize performance with mod_backhand,
and minimize the number of connections, I'll be happy to see them. I'm
still topping out at about 500 requests/second, whatever the number of
nodes, and I'd like to scale!

Hope it helps someone,

Dejan

------------------------------------
IPaddr patch example for proper handling of the aliases loopback
interface (VIP 1.1.1.1 and lo:0):

MAKE SURE "HIDDEN" ATTRIBUTE IS SET FOR LOOPBACK (see hidden patch for
kernel 2.4 in IPVS distrbution)

*** IPaddr.orig Wed Mar 7 00:06:35 2001
--- /etc/ha.d/resource.d/IPaddr Wed Mar 7 00:09:17 2001
***************
*** 80,83 ****
--- 80,86 ----
$IFCONFIG $IF down
ha_log "info: IP Address $BASEIP released"
+
+ # MODIFIED BY DEJ
+ /sbin/ifconfig lo:0 1.1.1.1 broadcast 1.1.1.0 netmask
255.255.255.255
}

***************
*** 89,92 ****
--- 92,97 ----
#
find_free_interface() {
+ # MODIFIED BY DEJ
+ /sbin/ifconfig lo:0 down
ipaddr=$1;
if
***************
*** 134,139 ****
# Do we already service this IP address?
#
if
! $IFCONFIG | grep "inet addr:$1 " >/dev/null 2>&1
then
exit 0 # We already own this IP address
--- 139,145 ----
# Do we already service this IP address?
#
+ # MODIFIED BY DEJ
if
! $IFCONFIG | grep "inet addr:$1 Bcast" >/dev/null 2>&1
then
exit 0 # We already own this IP address
***************
*** 182,188 ****

ip_status() {
BASEIP=`echo $1 | sed s'%/.*%%'`
if
! $IFCONFIG | grep "inet addr:$BASEIP " >/dev/null 2>&1
then
echo "running"
--- 188,195 ----

ip_status() {
+ # MODIFIED BY DEJ
BASEIP=`echo $1 | sed s'%/.*%%'`
if
! $IFCONFIG | grep "inet addr:$BASEIP Bcast" >/dev/null 2>&1
then
echo "running"
[mod_backhand-users] Success with IPVS, heartbeat, ldirectord and mod_backhand [ In reply to ]
It looks like it should patch cleanly all the way through 1.3.19. The lines
in question have not changed. If it doesn't, the manual patch should only
take a minute.

I just applied it to 1.3.19 and it succeeded.

[ I untar the apache_1.3.xx.tar.gz distribution. ]
# tar xvfz apache_1.3.xx.tar.gz
# cd apache_1.3.xx/src/main
[ download the patch here.]
# patch < apache-mod_backhand-keepalive.patch
patching file `http_protocol.c'
Hunk #1 succeeded at 455 (offset 152 lines).

Dejan Macesic wrote:
> A quick question for Theo though: the patch you show on your site for
> forcing keep-alive for pipelined backhand proxy requests, is it
> available for apache 1.3.17? I haven't been able to apply it to my
> install, and I'd really like to minimize the number of spawned
> connections. I guess I can still go manually through the code...

--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
[mod_backhand-users] Success with IPVS, heartbeat, ldirectord and mod_backhand [ In reply to ]
Cool. I'll try it. I'll take the opportunity to upgrade my apache before
going into production. Should I use the new mod_backhand.c and
stolenstatics.c in the CVS tree?

Dejan


"Theo E. Schlossnagle" wrote:
>
> It looks like it should patch cleanly all the way through 1.3.19. The lines
> in question have not changed. If it doesn't, the manual patch should only
> take a minute.
>
> I just applied it to 1.3.19 and it succeeded.
>
> [ I untar the apache_1.3.xx.tar.gz distribution. ]
> # tar xvfz apache_1.3.xx.tar.gz
> # cd apache_1.3.xx/src/main
> [ download the patch here.]
> # patch < apache-mod_backhand-keepalive.patch
> patching file `http_protocol.c'
> Hunk #1 succeeded at 455 (offset 152 lines).
>
> Dejan Macesic wrote:
> > A quick question for Theo though: the patch you show on your site for
> > forcing keep-alive for pipelined backhand proxy requests, is it
> > available for apache 1.3.17? I haven't been able to apply it to my
> > install, and I'd really like to minimize the number of spawned
> > connections. I guess I can still go manually through the code...
>
> --
> Theo Schlossnagle
> 1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
> 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
[mod_backhand-users] Success with IPVS, heartbeat, ldirectord and mod_backhand [ In reply to ]
Almost forgot, any way to compile mod_backhand as purely static? It is
my only loadable module for the frontends, and I would like to have it
all static.

Dejan


Dejan Macesic wrote:
>
> Cool. I'll try it. I'll take the opportunity to upgrade my apache before
> going into production. Should I use the new mod_backhand.c and
> stolenstatics.c in the CVS tree?
>
> Dejan
>
> "Theo E. Schlossnagle" wrote:
> >
> > It looks like it should patch cleanly all the way through 1.3.19. The lines
> > in question have not changed. If it doesn't, the manual patch should only
> > take a minute.
> >
> > I just applied it to 1.3.19 and it succeeded.
> >
> > [ I untar the apache_1.3.xx.tar.gz distribution. ]
> > # tar xvfz apache_1.3.xx.tar.gz
> > # cd apache_1.3.xx/src/main
> > [ download the patch here.]
> > # patch < apache-mod_backhand-keepalive.patch
> > patching file `http_protocol.c'
> > Hunk #1 succeeded at 455 (offset 152 lines).
> >
> > Dejan Macesic wrote:
> > > A quick question for Theo though: the patch you show on your site for
> > > forcing keep-alive for pipelined backhand proxy requests, is it
> > > available for apache 1.3.17? I haven't been able to apply it to my
> > > install, and I'd really like to minimize the number of spawned
> > > connections. I guess I can still go manually through the code...
> >
> > --
> > Theo Schlossnagle
> > 1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
> > 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
[mod_backhand-users] Success with IPVS, heartbeat, ldirectord and mod_backhand [ In reply to ]
Yes, probably. There are a few bugs in 1.1.1pre3 that have been fixed in CVS.

Dejan Macesic wrote:
> Cool. I'll try it. I'll take the opportunity to upgrade my apache before
> going into production. Should I use the new mod_backhand.c and
> stolenstatics.c in the CVS tree?

--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
[mod_backhand-users] Success with IPVS, heartbeat, ldirectord and mod_backhand [ In reply to ]
Yes, but there is one caveat that was brought up on the list. mod_backhand
uses features only compiled in when mod_so is enabled.

So after running precompile, add --enable-module=so --enable-modules=backhand

See:
http://lists.backhand.org/pipermail/backhand-users/2001-February/000173.html

Dejan Macesic wrote:
> Almost forgot, any way to compile mod_backhand as purely static? It is
> my only loadable module for the frontends, and I would like to have it
> all static.

--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
[mod_backhand-users] Success with IPVS, heartbeat, ldirectord and mod_backhand [ In reply to ]
Dejan Macesic wrote:
> If anyone has ideas on how to maximize performance with mod_backhand,
> and minimize the number of connections, I'll be happy to see them. I'm
> still topping out at about 500 requests/second, whatever the number of
> nodes, and I'd like to scale!

(1) Are you sure it isn't you client topping out?

(2) What are the candidacy functions you are using? And what what content?
Baiscally, what <Directory,Location,Files> directives do you have and what
Backhand statements are in each? It may be that the system is correctly
accounting for the overhead of proxying the connection. This is what the
"bias" is for in byLoad.

--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
[mod_backhand-users] Success with IPVS, heartbeat, ldirectord and mod_backhand [ In reply to ]
(1) I ran ab simultaneously from two different machines (outside the
cluster) with LAN access, with up to 1000 concurrent connections each.
If I ran only 1 ab at a time, I get around 500 requests per sec, if I
run both, the total of the two is around 500. Might have something to do
with the maximum number of available sockets on the target machines. The
idle goes to 0%, but that may be because some processes are waiting for
available sockets. I'll look into kernel parameters.

(2)
<Directory /home/httpd/www>
Backhand byAge
Backhand byRandom
Backhand addSelf
Backhand byLoad
</Directory>

If there are only three machines, does it make sense to use byLogWindow?
And I didn't put a bias in because the connections are distributed to
the servers by IPVS. Should I give the receiving server more bias (like
-1000) so that it serves the request until it is topped out?

Dejan

"Theo E. Schlossnagle" wrote:
>
> Dejan Macesic wrote:
> > If anyone has ideas on how to maximize performance with mod_backhand,
> > and minimize the number of connections, I'll be happy to see them. I'm
> > still topping out at about 500 requests/second, whatever the number of
> > nodes, and I'd like to scale!
>
> (1) Are you sure it isn't you client topping out?
>
> (2) What are the candidacy functions you are using? And what what content?
> Baiscally, what <Directory,Location,Files> directives do you have and what
> Backhand statements are in each? It may be that the system is correctly
> accounting for the overhead of proxying the connection. This is what the
> "bias" is for in byLoad.
>
> --
> Theo Schlossnagle
> 1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
> 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
[mod_backhand-users] Success with IPVS, heartbeat, ldirectord and mod_backhand [ In reply to ]
Dejan Macesic wrote:
> (2)
> <Directory /home/httpd/www>
> Backhand byAge
> Backhand byRandom
> Backhand addSelf
> Backhand byLoad
> </Directory>
>
> If there are only three machines, does it make sense to use byLogWindow?
> And I didn't put a bias in because the connections are distributed to
> the servers by IPVS. Should I give the receiving server more bias (like
> -1000) so that it serves the request until it is topped out?

If there are three machines, it doesn't really make sense to use byLogWindow.
However, the above code effectively just does:
Backhand byAge
Backhand byLoad

Randomizing is only useful for choosing a random server or set of servers.
Since you are not using byLogWindow, you are randomizing and then ordering by
load which is effectively the same as just ordering by load in the first
place.

The addSelf is only useful if you may have eliminated yourself (byRandom,
byLogWindow).

The bias should be a relatively small positive number (1-5). In the code,
when it sorts based on normalized load, it will add this number to everone but
itself during the sort. So effectively, a machine will look a tad less loaded
than its peers -- attempting to provide a "I am not going to redirect to the
server unless he is substanitally less loaded than I" sort of semantic. You
want to do this because the overhead of proxying the connection (which is
substantial) is not accounted for anywhere else.

I am working on a better candidacy function that byLoad that tries to compare
the actual length of the run queue on each machine instead of the load (which
has horrible granularty). It should be in CVS soon and will be in the next
release.

Also, given the cost of proxying and the effeciency of Apache, it may not make
sense to proxy images and other static content unless the situation is VERY
VERY bad. So, for static content you may want to "Backhand off" or "Backhand
byLoad 40".

--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
[mod_backhand-users] Success with IPVS, heartbeat, ldirectord and mod_backhand [ In reply to ]
Duh. I just took a good look at my tests... 500 requests yes, but
throughput is 11520.45 kb/s. around 1.4 Mbps. I was making requests to a
heavy index file. With a smaller file, like the default apache page, it
is around 2777 requests per second on a PIII 700.

I'm also doing tests with khttpd for the static content. Initial results
show a 50% performance improvement. I'll keep you posted.

"Theo E. Schlossnagle" wrote:
>
> Dejan Macesic wrote:
> > If anyone has ideas on how to maximize performance with mod_backhand,
> > and minimize the number of connections, I'll be happy to see them. I'm
> > still topping out at about 500 requests/second, whatever the number of
> > nodes, and I'd like to scale!
>
> (1) Are you sure it isn't you client topping out?
>
> (2) What are the candidacy functions you are using? And what what content?
> Baiscally, what <Directory,Location,Files> directives do you have and what
> Backhand statements are in each? It may be that the system is correctly
> accounting for the overhead of proxying the connection. This is what the
> "bias" is for in byLoad.
>
> --
> Theo Schlossnagle
> 1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
> 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7