|
Below is the LVS-mini-HOWTO. It is designed for people new
to LVS to set up a few working LVSs without having to
wade through all the docs on the LVS webpage and without
having to really know what they're doing. If you've
setup a working LVS, then you will have already figured
this stuff out. This mini-HOWTO will be included in
the ipvs tarball and hopefully will be somewhere on
the webpage.
Wensong is defending his PhD on 30 Nov. If this goes
OK, he'll be entitled to all the rights and privileges
of a PhD (salary, title..).
I will be in Australia for all of Dec, bushwalking.
I won't be contactable by e-mail unfortunately.
I'm still working on the HOWTO, but you guys are providing
material faster than I can test it and put it in.
Ratz is helping, but there won't be a new version
till next year.
See you in the new year
Joe
--------------------------------------------------------------------
LVS-mini-HOWTO (C) Joseph Mack jmack@xxxxxxxx or via the mailing list
released under GPL
v1.0 Dec 2000
LVS website:
http://www.linuxvirtualserver.org
(code, docs, mailing list, mailing list archives)
Purpose of this document:
To show you how to install a Linux Virtual Server
(LVS) and to set up a few demonstration virtual servers.
No knowlege of the workings of LVS is needed or explained
here. You will need to be familiar with configuring linux.
Once you are satisfied that you can get an LVS to work,
you should read the docs and the HOWTO on the LVS website,
to setup the LVS you want and to understand how an LVS works.
For this you will then need to understand tcpip fairly well
(or be prepared to learn it).
The neccessity of this mini-HOWTO was pointed out by
ratz <ratz@xxxxxx> who made suggestions for content
and who proof-read the text. Other suggestions came
from John Cronin <jsc3@xxxxxxxxxxxxx>.
Location of this document:
Will be in the tarball of ipvs code starting with ipvs-1.0.2
and possibly on the website.
Mailing list:
The mailing list (on website) is available for further
questions. A single mailing list handles developers, new
users and old users and has about 10-20 postings a day.
No-one is expected to know/understand everything
in the docs but your questions will be better received
if you have setup the test configurations here, have
read the HOWTO and have looked at the mail archives.
There are many complexities to LVS and we don't expect
new people to understand any more about LVS that we
did when we started.
Please send e-mail with straight ascii (not html)
and turn line-wrap on (some mails come with each
paragraph on a single long line).
What an LVS does:
An LVS is a group of servers with a director that appear
to the outside world (a client on the internet) as one
server. The LVS can offer more services, or services of
higher capacity/throughput, or redundant services (where
individual servers can be brought down for maintenance)
than is available from a single server. A service is
defined here as a connection to a single port, eg telnet,
http, https, nntp, ntp, nfs, ntp, ssh. Multiport services
(eg ftp for VS-NAT) are also handled as a special case.
In the computer bestiary, and LVS is a layer-4 switch.
Standard client-server semantics are preserved. Each
client thinks that it has connected directly with
the real-server. Each real-server thinks that it
has connected directly to the client. Neither the
client nor the real-servers have any way of telling
that a director has intervened in the connection.
An LVS is not a beowulf - a beowulf is a group of machines
each of which is cooperatively calculating a small part
of a larger problem. It is not a cluster - a cluster
of machines is a set of machines which cooperatively
distribute processing. The real-servers in an LVS do
not cooperate - they have no knowlege of any other
real-servers in the LVS. All a real-server knows
about is that it gets connections from a client.
For this mini-HOWTO, the LVS will demonstrate with the
services of telnet and http.
You'll need:
Hardware (see ascii art below)
Client:
a machine that has a telnet client and an http client.
(eg netscape, lynx, IE). This machine can have
any operating system (I used a Mac for my first LVS).
Director:
Linux box running a kernel patched with ipvs (see software
section). For a test, this doesn't need to be powerful -
any 486 machine on 10Mpbs ethernet is fine. In real life
a 75MHz Pentium I is capable of delivering 50Mbps of packets
using 100Mbps ethernet. In this case the network layer
(33MHz bus) is the bottleneck and the CPU is doing little
work. Compare this throughput to the capacity of a
T-1 connection (1.5Mbps) and you can see that for low
capacity networks, the redundancy of the LVS is the
most useful feature. It's not till the network layer
is 1Gbps that CPU resources become limiting on 300MHz
PII's.
Real-servers:
These are the machines offering the service of interest
(here telnet and http). In production environments these
can have any operating system, but for convenience I
will discuss the case where they are linux machines
with kernel >=2.2.14. For the VS-DR example you must
use kernel >=2.2.14 or read the full HOWTO.
Network:
Must be ethernet, can be coax or twisted pair with a hub
or switch. Only 10Mbps ethernet is needed for a demonstration.
(For ATM see mail archives, and the next version of the HOWTO).
In a test setup with all machines in the same room, a router
(in diagram below) will not be present.
You will need 4 machines, 3 of them linux boxes. The
director connects to all boxes. It is convenient if
you have one keyboard and monitor, to set everything
up from the director.
________
| |
| client | (local or on internet)
|________|
|
(router)
|
-- |
L Virtual IP
i ____|_____
n | | (director can have 1 or 2 NICs)
u | director |
x |__________|
|
V |
i |
r -----------------+----------------
t | | |
u | | |
a | | |
l _____________ _____________ _____________
| | | | | |
S | real-server | | real-server | | real-server |
e |_____________| |_____________| |_____________|
r
v
e
r
---
Software:
configure script - It's currently on the website in the documentation
under "Manuals and internal documents", and will be in the contrib
directory of the ipvs tarball starting with ipvs-1.0.1-2.2.17. The
script is perl and requires perl modules not used in the
demonstrations here. However the script will not run without them
so check that you have the required modules by running
$perl -w configure.pl
Fetch the extra modules from the perl website (http://www.perl.com)
or download them directly with the perl cpan module.
The version of the configure script in the tarball has been
tested with kernel versions up to 2.2.16 and 2.4.0-test?. It
will issue warnings if you run it with 2.2.17. These can be ignored
as the output is valid (ipvs is hasn't changed configuration
method).
The configure script is designed for quick testing of LVS's with
only one director. Information on LVSs with redundant directors
is on the website.
The output of the configure script is an rc.lvs file which is
run first on the director and then the real-servers (the rc.lvs
script knows which machine is is running on and acts appropriately).
The rc.lvs script is verbose and reports on its progress.
Watch for any errors. You can run the script as many
times as you like on the same machine - it's idempotent.
I have the conf files on the director in an lvs/conf
directory which I nfs export to the same directory on
the real-servers. In a production system, you can umount
the directories on the real-servers after setup.
The rc.lvs script uses fping to test connections.
fping is available from
ftp://ftp.kernel.org/pub/software/admin/mon
The newer versions of ping have the functionality of fping
and the next version of the configure script will test
for this functionality. If you don't want to download
fping, you can use this script instead (put it in /usr/local/bin
and make it executable).
#!/bin/sh
#fping replacement
ping -c 1 $1
#-----fping-------------
The conf file and the configure script can use IPs or hostnames
and can use port numbers (eg 23) or service names (eg telnet).
Since all machines are local, you can add entries to /etc/hosts
on the director and real-servers and the names of services
to /etc/services.
Documentation on the configure script is in perldoc format
$perldoc configure.pl
kernel/patches -
either
1. get a fresh kernel from ftp.kernel.org and the matching
ipvs code from the LVS website (on the software page).
(In Dec 2000, the 2.2.x series patches are production level and
the 2.4.x kernel patches are experimental. For your sanity, use
the production grade patches and the matching kernel).
Apply the kernel patch 2.2.x using the instructions in the ipvs tarball.
You'll do something like
director:/usr/src/linux# patch -p1 <../ipvs-0.9.8-2.2.14/ipvs-0.9.8-2.2.14.patch
The actual kernel compile instructions will vary with
kernel patch number. Here's what I used for ipvs-0.9.9 on
kernel 2.2.15pre9 in the Networking options. The relevant
options are marked. Some of the options are not explicitely
required for LVS to work, but you'll need them anyhow - e.g.
ip aliasing if you need to constuct a director with only
one NIC, or tunneling if you are going to run VS-Tun. Until
you know what you're doing activate all of the options with
an '*' at the start of the line.
You need to turn on "Prompt for development code... "
in the "Code Maturity" section.
In the "Networking" section, you have to turn on
IP: masquerading, Network firewalls and IP: firewalling
before you get the ipvs options.
[*] Kernel/User netlink socket
[*] Routing messages
< > Netlink device emulation
* [*] Network firewalls
[*] Socket Filtering
<*> Unix domain sockets
* [*] TCP/IP networking
[*] IP: multicasting
[*] IP: advanced router
[ ] IP: policy routing
[ ] IP: equal cost multipath
[ ] IP: use TOS value as routing key
[ ] IP: verbose route monitoring
[ ] IP: large routing tables
[ ] IP: kernel level autoconfiguration
* [*] IP: firewalling
[ ] IP: firewall packet netlink device
* [*] IP: transparent proxy support
* [*] IP: masquerading
--- Protocol-specific masquerading support will be built as modules.
* [*] IP: ICMP masquerading
--- Protocol-specific masquerading support will be built as modules.
* [*] IP: masquerading special modules support
* <M> IP: ipautofw masq support (EXPERIMENTAL)
* <M> IP: ipportfw masq support (EXPERIMENTAL)
* <M> IP: ip fwmark masq-forwarding support (EXPERIMENTAL)
* [*] IP: masquerading virtual server support (EXPERIMENTAL)
* (12) IP masquerading VS table size (the Nth power of 2)
* <M> IPVS: round-robin scheduling
* <M> IPVS: weighted round-robin scheduling
* <M> IPVS: least-connection scheduling
* <M> IPVS: weighted least-connection scheduling
* [*] IP: optimize as router not host
* <M> IP: tunneling
<M> IP: GRE tunnels over IP
[*] IP: broadcast GRE over IP
[*] IP: multicast routing
[*] IP: PIM-SM version 1 support
[*] IP: PIM-SM version 2 support
* [*] IP: aliasing support
[ ] IP: ARP daemon support (EXPERIMENTAL)
* [*] IP: TCP syncookie support (not enabled per default)
--- (it is safe to leave these untouched)
< > IP: Reverse ARP
[*] IP: Allow large windows (not recommended if <16Mb of memory)
< > The IPv6 protocol (EXPERIMENTAL)
Do all the other kernel stuff - make modules, copy the new
kernel into / or /boot (giving it a different name to your
working kernel eg bzImage-0.9.14-2.2.16), edit lilo.conf and re-run lilo.
Make sure you leave the old kernel info in lilo.conf, so you can
recover if all does not go well. Reboot to the new kernel.
ipvsadm:
ipvsadm is the user interface to LVS.
Do a make install for ipvsadm (part of the ipvs tarball).
Make sure the ipvsadm you are using is from the
same ipvs tarball as the kernel patches. (This is a
common problem, if you just make and forget to install
you'll have the old ipvsadm with the new ipvs code -
I've done it. Since you can't compile/run ipvsadm till
the you've got the new kernel, sometimes you forget
to do the make install on ipvsadm after rebooting).
You can optionally compile ipvsadm with popt libraries,
which allows ipvsadm to handle more complicated arguments
on the command line. If your libpopt library is too old,
your ipvsadm will segv. The default compile uses static popt
libraries. I'm compiling with dynamic libraries which works
quite nicely. (I don't think the configure scripts here
need the popt libraries, but I haven't tested this.).
Check software:
With a bit of skill and luck you will have loaded all the
software without any errors.
Check that ipvsadm detects the kernel patches by running
$ipvsadm
success will look something like
director:/usr/src# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
If you aren't running a kernel with ipvs patches, you'll get
error messages about missing ipvs modules.
OR
2. Using a prepatched or precompiled kernel.
Some distributions have kernels prepatched with ipvs. RedHat was doing
this in late 1999. SuSE plans to do this (Dec 2000). If you have one
of these distributions, follow the instructions provided with the
distribution for getting a working LVS director. Since an average
of 2 ipvs versions come out for every kernel version, you will likely
have an older ipvs version if you choose this route. This is not
a problem - ipvs was production quality when first released, however
versions more than 6-12months old are not supported on the mailing list.
You'll be told to upgrade and come back again.
If you don't know if you have a kernel prepatched with ipvs, either
ask your Linux Vendor or look in your kernel source tree for
ipvs files (names like /usr/src/linux/net/ipv4/ip_vs_*.c).
If you are not sure, then setup with a fresh kernel from ftp.kernel.org
(instructions above). You can always return to your patched distribution
later.
If you try to patch a kernel that already has ipvs patches applied,
you will get patch errors e.g.
> Hunk #1 succeeded at 121 with fuzz 2 (offset 18 lines).
> Hunk #2 FAILED at 153.
> Hunk #3 FAILED at 163.
> Hunk #4 FAILED at 177.
> 3 out of 4 hunks FAILED -- saving rejects to include/linux/ip_masq.h.rej
>
> patching file `include/net/ip_masq.h'
> Reversed (or previously applied) patch detected! Assume -R? [n]
People who compile the kernel after a failed second layer of
patches wind up on the mailing list with errors that are impossible
to fathom. One of the major sources of questions on the mailing
list is from people running RedHat who find that their install
fails when following the instructions in the LVS HOWTO. They
aren't starting with standard kernel and the instructions from RedHat
haven't told them what's going on.
Here's advice from Lars lmb@xxxxxxxx, who is about to release
a kernel prepatched with ipvs code.
"Hey, if you are getting an error message like this, or if your
distribution already includes LVS, don't try applying the patch on top
of it.
First, try checking with your Linux vendor whether an updated kernel
package with full support is already available.
If you think this revision of the LVS patches provides significant
improvement over the previous ones, or fixes a critical bug for you,
and the vendor doesn't yet provide an updated kernel, please ask them
to do so.
If you need a newer revision than what your distribution supplies,
please grab a clean kernel tree from kernel.org and start from that.
Make sure to apply all other patches you need!"
Setup LVS using VS-NAT forwarding:
VS-NAT forwarding was the first method used to setup an LVS. It
gives lower throughput at high load compared to VS-DR or VS-Tun,
but still is useful in some circumstances.
Setup an LVS with these IPs (and no other IPs anywhere) using machines
with a single NIC. The IPs on ethernet aliases (eg eth0:110) are
setup by the configure script.
________
| |
| client |
|________|
192.168.2.254
|
|
__________ |
| | | 192.168.2.110 (eth0:110)
| director |---|
|__________| | 192.168.1.1 (eth0)
|
|
-----------------------------------
| |
| |
192.168.1.2 (eth0) 192.168.1.3(eth0)
_____________ _____________
| | | |
| real-server | | real-server |
|_____________| |_____________|
VS-NAT for the service telnet:
Next setup a conf file for the configure script
#----------lvs_nat.conf------------------------------------
LVS_TYPE=VS_NAT
INITIAL_STATE=on
VIP=eth0:110 192.168.2.110 255.255.255.0 192.168.2.255
DIRECTOR_INSIDEIP=eth0 192.168.1.1 192.168.1.0 255.255.255.0 192.168.1.255
DIRECTOR_DEFAULT_GW=192.168.2.254
SERVICE=t telnet rr 192.168.1.2:telnet 192.168.1.3:telnet
SERVER_NET_DEVICE=eth0
SERVER_DEFAULT_GW=192.168.1.1
#----------end lvs_nat.conf------------------------------------
then run the configure script
$./configure lvs_nat.conf
this will produce (among other things) a file rc.lvs_nat
Run this rc.lvs_nat file first on the director and then on the two
real-servers (the file knows whether it's running on a director or
real-server and acts appropriately). One of the big traps in
setting up a VS-NAT LVS is that you have to make the director
the default route for the real-servers (the script does this
for you) - it won't work if you don't do this.
Then on the director run the command
$ipvsadm
The output should be something like
director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.2.110:telnet rr
-> 192.168.1.2:telnet Masq 1 0 0
-> 192.168.1.3:telnet Masq 1 0 0
Now telnet from the client to 192.168.2.110. You will get the
login prompt from one of the real-servers (note which one). Then
on the director re-run ipvsadm
director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.2.110:telnet rr
-> 192.168.1.2:telnet Masq 1 1 0
-> 192.168.1.3:telnet Masq 1 0 0
Note the ActiveConn counter has incremented.
Open another window on the client and telnet to 192.168.2.110.
You should get the login prompt for the other real-server.
Re-run ipvsadm.
director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.2.110:telnet rr
-> 192.168.1.2:telnet Masq 1 1 0
-> 192.168.1.3:telnet Masq 1 1 0
There are now 2 connections active.
You are now connected to the real-servers by a telnet session.
Congratulations - you have set up a VS-NAT LVS for the service telnet.
VS-NAT for the service http:
Change the conf file by adding an http line and commenting out the
telnet line.
#----------lvs_nat.conf------------------------------------
LVS_TYPE=VS_NAT
INITIAL_STATE=on
VIP=eth0:110 192.168.2.110 255.255.255.0 192.168.2.255
DIRECTOR_INSIDEIP=eth0 192.168.1.1 192.168.1.0 255.255.255.0 192.168.1.255
DIRECTOR_DEFAULT_GW=192.168.2.254
#SERVICE=t telnet rr 192.168.1.2:telnet 192.168.1.3:telnet
SERVICE=t http rr 192.168.1.2:http 192.168.1.3:http
SERVER_NET_DEVICE=eth0
SERVER_DEFAULT_GW=192.168.1.1
#----------end lvs_nat.conf------------------------------------
Make sure the real-servers are serving http with each real-server
listening to port 80 on its own IP (eg 192.168.1.2, 192.168.1.3)
i.e. a different IP for each real-server. Make the 2 webpages a
little different so that you can tell which machine you have connected to.
Rerun the configure script on the new conf file, rerun the rc.lvs files
on the director and then the real-servers. If you get no errors
then run ipvsadm
director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.2.110:www rr
-> 192.168.1.2:www Masq 1 0 0
-> 192.168.1.3:www Masq 1 0 0
Connect your http client to 192.168.2.110. If you get the expected
webpage, shift-reload a few times (for netscape), watching the
webpages alternate between real-servers. In some circumstances,
presumably due to http persistance, the connection will persist on
one real-server. In this case use lynx, curl or telnet to 192.168.2.110 80
and at the blank prompt type
GET /
to use lynx do
$ lynx -dump http://192.168.2.110/
Re-run ipvsadm (on the director)
director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.2.110:www rr
-> 192.168.1.2:www Masq 1 0 13
-> 192.168.1.3:www Masq 1 0 12
Unlike telnet there are no ActiveConn seen even though you have
a webpage displayed on the client. The http protocol disconnects
after 15secs changing the connections to InActConn. These expire
in about 2 mins (re-run ipvsadm after 2mins and see that
InActConn drops to 0).
The template timeout can be seen by invoking ipchains -L -M -n
Setup LVS using VS-DR forwarding:
VS-DR has higher packet throughput than VS-NAT and is the
preferred forwarding method for http and ftp servers.
Setup an LVS with these IPs using machines with a single
NIC. The IPs on ethernet aliases (eg eth0:110, lo:0) are
setup by the configure script.
________
| |
| client |
|________|
192.168.1.254
|
|
__________ |
| | | 192.168.1.110 (eth0:110)
| director |---|
|__________| | 192.168.1.1 (eth0)
|
|
-----------------------------------
| |
| |
192.168.1.2 (eth0) 192.168.1.3(eth0)
192.168.1.110 (lo:0) 192.168.1.110 (lo:0)
_____________ _____________
| | | |
| real-server | | real-server |
|_____________| |_____________|
VS-DR for the service telnet:
Next setup a conf file for the configure script
#----------lvs_dr.conf------------------------------------
LVS_TYPE=VS_DR
INITIAL_STATE=on
VIP=eth0:110 192.168.1.110 255.255.255.0 192.168.1.255
DIRECTOR_INSIDEIP=eth0 192.168.1.1 192.168.1.0 255.255.255.0 192.168.1.255
DIRECTOR_DEFAULT_GW=192.168.1.254
SERVICE=t telnet rr 192.168.1.2:telnet 192.168.1.3:telnet
SERVER_NET_DEVICE=eth0
SERVER_DEFAULT_GW=192.168.1.254
#----------end lvs_dr.conf------------------------------------
then
$./configure lvs_dr.conf
this will produce (among other things) a file rc.lvs_dr
Run this rc.lvs_dr file first on the director and then on the two
real-servers (the file knows whether it's running on a director or
real-server and acts appropriately).
The on the director run the command
$ipvsadm
The output should be something like
director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.110:telnet rr
-> 192.168.1.2:telnet Route 1 0 0
-> 192.168.1.3:telnet Route 1 0 0
Note that the forwarding method has changed from Masq to Route.
Now telnet from the client to 192.168.1.110. You will get the
login prompt from one of the real-servers (note which one). Then
re-run ipvsadm
director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.110:telnet rr
-> 192.168.1.2:telnet Route 1 1 0
-> 192.168.1.3:telnet Route 1 0 0
If you have tcpwrappers running around telnet on the real-servers,
the login will be delayed by an interval between 7secs(Slackware)
and 3mins(RedHat). You can fix this by changing the line in inetd.conf
from
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
to
telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd
and re-HUPing inetd. If you have a pam-ified telnetd and login, you
may never be able to fix this delay (RedHat 6.2 man pages tell you to
change entries in /etc/pam.conf, a file that doesn't exist).
After logging in, the telnet session behaves normally. This delay
is only a minor nuisance, but it is difficult to differentiate
from a hung connection due to an LVS misconfiguration (which
hopefully would have been picked up when running the configure
script). This delay doesn't occur with VS-NAT (see the section on
identd in the HOWTO for an explanation).
Open another window on the client and telnet again to 192.168.1.110.
You should get the login prompt for the other real-server.
Re-run ipvsadm.
director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.110:telnet rr
-> 192.168.1.2:telnet Route 1 1 0
-> 192.168.1.3:telnet Route 1 1 0
There are now 2 connections active.
You are now connected to the real-servers be a normal telnet session.
Congratulations - you have set up a VS-DR LVS for the service telnet.
VS-DR for the service http:
Change the conf file by adding an http line and commenting out the
telnet line.
#----------lvs_dr.conf------------------------------------
LVS_TYPE=VS_DR
INITIAL_STATE=on
VIP=eth0:110 192.168.1.110 255.255.255.0 192.168.1.255
DIRECTOR_INSIDEIP=eth0 192.168.1.1 192.168.1.0 255.255.255.0 192.168.1.255
DIRECTOR_DEFAULT_GW=192.168.1.254
#SERVICE=t telnet rr 192.168.1.2:telnet 192.168.1.3:telnet
SERVICE=t http rr 192.168.1.2:http 192.168.1.3:http
SERVER_NET_DEVICE=eth0
SERVER_DEFAULT_GW=192.168.1.1
#----------end lvs_dr.conf------------------------------------
IMPORTANT:
Make sure the real-servers are listening to port 80 on 192.168.1.110
AND NOT to its own IP (eg 192.168.1.2, 192.168.1.3), i.e both real-servers
are listening to the same IP. Make the 2 webpages a little different so that
you can tell which real-server you have connected to.
Rerun the configure script on the conf file, rerun the rc.lvs files
on the director and then the real-servers. If you get no errors
then run ipvsadm
director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.110:www rr
-> 192.168.1.2:www Route 1 0 0
-> 192.168.1.3:www Route 1 0 0
Connect your http client to 192.168.1.110. If you get the expected
webpage, shift-reload a few times, watching the webpages alternate
between real-servers. In some circumstances, presumably due to
http persistance, the connection will persist on one real-server.
In this case use lynx or telnet to 192.168.1.110 80 and at
the blank prompt type
GET /
to use lynx do
$ lynx -dump http://192.168.2.110/
Re-run ipvsadm (on the director)
director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.110:www rr
-> 192.168.1.2:www Route 1 0 5
-> 192.168.1.3:www Route 1 0 4
Unlike telnet there are no ActiveConn seen even though you have
a webpage displayed on the client. The http protocol disconnects
after 15secs (max). The connections change to InActConn and expire
in about 2 mins. If you then re-run ipvsadm the InActConn will drop
to 0.
Congratulations, you're done. Go have fun. For more information
look at the HOWTO and docs on the LVS website and scan the
mail archives. If you have any questions, join the
mailing list.
#----------------LVS-mini-HOWTO----------------------------------
--
Joseph Mack mack@xxxxxxxxxxx
|
