<!DOCTYPE ARTICLE PUBLIC "-//Davenport//DTD DocBook V3.0//EN" []>
<article id="index">
  <artheader>
<title>LVS Cluster Configuration HOWTO
</title>
    <author>
      <firstname>Wayne</firstname>
      <surname>Sherrill (sherrill@redhat.com)</surname>
      <affiliation>
        <address><email> </email></address>
      </affiliation>
    </author>
    <copyright>
       <year>1999</year>
       <holder>Red Hat, Inc.</holder>
    </copyright>
    <legalnotice>
       <para>
        This document and its contents are copyright protected.
        Redistribution of this document is permitted as long as the
        content remains completely intact and unchanged.  In other
        words, you may reformat and reprint or redistribute only.
      </para>
    </legalnotice>

<abstract>
      <para>
This document explains how to set up and administer a Linux Virtual Server
(LVS) cluster that provides highly available Web and FTP services.
</para>
</abstract>
  </artheader>


<sect1>
<title>Introduction</title>
<para>
A Linux Virtual Server (LVS) cluster is a collection of servers that have been
specially configured to provide highly available Web and FTP services. The 
diagram below illustrates how an LVS cluster works. Service requests arriving
at an LVS cluster are addressed to a <firstterm>virtual server</firstterm>: a
publicly advertised, fully-qualified domain name that is associated with a
floating IP address, and which can be migrated to a different host.
</para>
    <figure>
      <title>LVS Cluster Interactions</title>
<screen>  
                             _/\__/\_ 
                            |        | 
                           / Internet \ 
                           \_  _  _  _/ 
                             \/ \/ \/
                                 |
                                 |
                       Virtual Server IP/FQDN
             |------------------------------------------|
             |eth0                                      |eth0
       ------|-----                              -------|-----
       | Primary  |                              |   Backup  |
       |  Node    |                              |    Node   |    LVS
       |          |                              |           |  routers
       ------|-----                              -------|-----
             |eth1                                      |eth1
             |-------|------------|-----------------|---|
                     |            |                 | 
                     |            |                 |
                     |            |                 |
                |----|----|  |----|----|       |----|----|
                | Web/FTP |  | Web/FTP |       | Web/FTP |        real
                |  Node#1 |  |  Node#2 |  ...  |  Node#n |       servers
                |_________|  |_________|       |_________|

</screen>
    </figure>
<para>
An LVS cluster consists of one or two router nodes (top of figure) and a
variable number of Web/FTP servers (bottom). We will refer to the LVS router
nodes as <firstterm>LVS routers</firstterm>, and to the pool of Web/FTP servers
as <firstterm>real servers</firstterm>. The real servers are connected via a
private network. The LVS routers are connected to this private network and also
to the public network. The adapters connecting the LVS routers to the
public and private networks (eth0 and eth1 in the figure) may be any device but
must be the same on each router. 
</para>
<para>
Only one LVS router is active at a time. The role of the
<firstterm>active router</firstterm> is to redirect service requests from
the virtual server address to the real servers. The redirection is based on
one of the four supported load-balancing algorithms (described in <xref
linkend="load-balancing">). The active router dynamically monitors the
health of the real servers, and the workload on each, via one of three
supported methods (described in <xref linkend="node-prereqs">). If a real server
becomes disabled, the active router stops sending jobs to the server until it
returns to normal operation. 
</para>
<para>
Periodically, the LVS routers exchange "I'm alive" heartbeat messages over
their public connection. Should the backup node fail to receive a heartbeat
message within an expected interval, it initiates
<firstterm>failover</firstterm> in order to assume the role of the active
router. During failover, the backup router takes over the failed router's
floating IP addresses (as indicated in the cluster configuration file), and uses
the technique known as <firstterm>ARP spoofing</firstterm>: starts announcing
itself as the destination for IP packets addressed to the failed node. When the
failed node returns to service, it assumes the <firstterm>hot backup</firstterm>
role.    
</para>
<para>
Currently, the LVS cluster supports one routing method, Network Address
Translation (NAT). (In the future, tunneling and direct routing will be
added.) The diagram below illustrates how a NAT virtual server works.
</para>
    <figure>
      <title>An LVS Cluster Implemented with NAT Routing</title>      
<screen>


                             _/\__/\_ 
                            |        | 
                           / Internet \ 
                           \_  _  _  _/ 
                             \/ \/ \/
                                 |
                                 |
             |------------------------------------------| public
                                 |                        network
                            eth0 | virtual server IP address
                       --------------------         
                       |   active router  |
                       |                  |
                       --------------------
                            eth1 | NAT router IP address
                                 |
             |-------|-------------------------|--------| private
                     |                         |          network
                     |                         |
                     |                         |
                |----|----------|  |-----------|---|
                | real server#1 |  | real server#2 |
                |               |  |               |  ...
                |_______________|  |_______________|


</screen>
    </figure>
<para>
Client requests for service arrive at a virtual server IP address. This is a
publicly-advertised address that an administrator at the site will have
associated with a fully-qualified domain name (for example, lvs.ajax.com). The
illustration shows only one virtual server address, but there may be many. A
unique virtual server address is a triplet comprising a protocol (TCP or UDP),
IP address, and port number. 
</para>
<para>
The IP components of virtual server addresses are floating addresses. They may
be aliased to the device (for example, eth0:1) that connects the LVS routers
to the public network, or each could be associated with a separate device.
The NAT router IP address, also a floating IP address, is the default route used
by each real server on the private network to communicate with the active router.
As with virtual server addresses, the NAT router IP address may be aliased to
the device (for example, eth1:1) connecting the virtual server to the network of
real servers, or it could be associated with a separate device. 
</para>
<para>
Virtual server and NAT addresses are enabled only on the active router. Thus,
should the active router fail, the backup router enables the virtual server and
NAT addresses during take-over of the floating IP addresses. In the topology
shown in Figure 2, virtual server addresses are enabled on device eth0 and the
NAT router address on eth1. 
</para>
<para>
The <firstterm>IPVS table</firstterm> in the kernel maps requests
from the virtual server address to a real server on the private network. For
example, a TCP request addressed to port 80 on virtual server 1.2.3.1
might be routed to port 80 on real server 192.168.1.2. The actual mapping in the
IPVS table of jobs to real servers is based on which load-balancing
algorithm is in use. <xref linkend="load-balancing"> describes the supported
load-balancing methods. 
</para>
    <table id="load-balancing">
      <title>Load-balancing Methods</title>
      <tgroup cols="2">
        <thead>
          <row>
            <entry>Name</entry>
            <entry>Description</entry>
          </row>
        </thead>
        <tbody>
          <row>
            <entry>Round robin</entry>
            <entry>Distribute jobs equally among the real servers.</entry>
          </row>
          <row>
            <entry>Least-connections</entry>
            <entry>Distribute more jobs to real servers with fewer active
            connections. (The IPVS table stores active connections.)</entry>
          </row>
          <row>
            <entry>Weighted round robin</entry>
            <entry>Distribute more jobs to servers with greater
            capacity. Capacity is indicated by the user-assigned weight, which
            is adjusted upward or downward by dynamic load information.</entry>
          </row>
          <row>
            <entry>Weighted least-connections</entry>
            <entry>Distribute more jobs to servers with fewer active connections
            relative to their capacity. Capacity is indicated by the user-assigned
            weight, which is adjusted upward or downward by dynamic load
            information. </entry> 
          </row>
        </tbody>
      </tgroup>
    </table>
<para>
As a real server processes a request, it returns packets to the
active router, where the address of the real server in the packets is replaced
by the virtual server address. In this manner, the private network of real
servers is masqueraded from requesting clients. 
</para>
</sect1>
<sect1>
    <title>Components of an LVS Cluster</title>
<para>
The components of an LVS cluster are described below.
</para>
<sect2>
<title>pulse</title>
<para>
This is the controlling process that starts the other daemons as needed. It is
started on the LVS routers by the <filename>/etc/rc.d/init.d/pulse</filename>
script, normally at boot time . Through <command>pulse</command>, which
implements a simple heartbeat, the inactive LVS router determines the health of
the active router and whether to initiate failover.   
</para>
</sect2>
<sect2>
<title>lvs</title>
<para>
The <command>lvs</command> daemon runs on the LVS routers. It reads the
configuration file and calls <command>ipvsadm</command> to build and maintain
the IPVS routing table. 
</para>
</sect2>
<sect2>
<title>nanny</title>
<para>
The <command>nanny</command> monitoring daemon runs on the active LVS
router. Through this daemon, the active router determines the health of each
real server and gets its workload. A separate process runs for each real server
used by each virtual server. 
</para>
</sect2>
<sect2>
<title>/etc/lvs.cf</title>
<para>
This is the LVS cluster configuration file. Directly or indirectly, all daemons
get their configuration information from this file.
</para>
</sect2>
<sect2>
<title>piranha</title>
<para>
The GUI tool for monitoring, configuring, and administering an LVS cluster.
Normally this is the tool you will use to maintain
<filename>/etc/lvs.cf</filename>, restart the running daemons, and monitor 
an LVS cluster.  
</para>
</sect2>
<sect2>
<title>ipvsadm</title>
<para>
This tool updates the IPVS routing table in the kernel. The
<command>lvs</command> daemon sets up and administers an LVS cluster by calling
<command>ipvsadm</command> to add, change or delete entries in the IPVS routing
table.
</para>
</sect2>
</sect1>
<sect1>
    <title>Background of the LVS Cluster</title>
<para>
The Red Hat LVS cluster is based either directly on contributions from the
Linux community, or on components that were inspired or enriched by Linux
community projects. 
</para>
<para>
The primary source of the LVS cluster is Wensong Zhang's Linux Virtual Server
(LVS) kernel routing algorithm (see
<ulink url="http://www.linuxvirtualserver.org" type="http">
http://www.linuxvirtualserver.org</ulink>). The
capabilities of the LVS project that the Red Hat LVS cluster currently supports
are:   
</para>
<itemizedlist mark="bullet">
  <listitem>
   <para>
Building virtual servers: floating IP addresses where requests for service
arrive from the public internet.
  </para>
  </listitem>

  <listitem>
   <para>
Routing service requests from virtual servers to a pool of real servers.  
  </para>
  </listitem>

  <listitem>
   <para>
Load-balancing (see <xref linkend="load-balancing">).
  </para>
  </listitem>

  <listitem>
   <para>
Packet-forwarding Network Address Translation (NAT). 
  </para>
  </listitem>

 </itemizedlist>
<para>
The LVS innovations supported by the Red Hat LVS cluster are based on a number
of technologies including Network Address Translation (NAT), IP Masquerading,
and Port Forwarding. For a good general discussion and index of the relevant
HOWTOs on these and related topics, see
<ulink url="http://www.linas.org/linux/load.html"
type="html">http://www.linas.org/linux/load.html</ulink>. 
</para>
</sect1>
<sect1>
<title>Hardware/Network Requirements</title>
<para>
An LVS cluster consists of one or two LVS routers and a collection of real
servers providing Web and FTP services. The connection and hardware
requirements are described below. 
</para>
<sect2>
<title>LVS Routers</title>
<para>
A Linux server that will be the primary LVS router is required. This machine needs
two network adapters, one connecting it to the public network and the other to a
private network of real servers. 
</para>
<para>
If you want failover capability, a second Linux server that will be the backup LVS
router is required. This machine also needs two network adapters connecting it
to the public network and to the private network of real servers. The adapter
devices must match on the two LVS routers. Thus, if devices eth0 and eth1 on the
primary LVS router connect it to public and private network, respectively, then
these same devices on the backup LVS router must connect it to the public and
private network. Note that the backup LVS router is a purely <firstterm>hot
standby</firstterm> machine. 
</para>
</sect2>
<sect2>
<title>Real Servers</title>
<para>
The private network to which the LVS routers are connected includes a variable
number of Web/FTP server hosts. Jobs addressed to virtual servers are redirected
to these real servers, which may be any kind of computing platform running any
operating system or Web server. 
</para>
<para>
During configuration, you assign a <firstterm>weight</firstterm> to each real
server. This is an integer reflecting each server's processing capacity
(based on memory, processor speed, number of processors, etc.) relative to that
of the others. It is the ratio (2/1, 20/10, 200/100) that is significant. For
example, a weight of 2000 assigned to a server indicates that it has twice the
computing power of a server assigned a weight of 1000. The assigned weight,
which may be dynamically adjusted based on load information, is used by two
available job scheduling algorithms (described in <xref
linkend="load-balancing">). You should be prepared to assign accurate weights.   
</para>
    </sect2>
</sect1>
<sect1>
<title>LVS Router Prerequisites</title>
<para>
The LVS routers require Red Hat Linux 6.1 or greater. Also, packet forwarding,
packet defragmenting, and IP masquerading must be enabled on the LVS routers. 
</para>
<para>
To enable packet forwarding and defragmenting, make sure the following two lines
are present in <filename>/etc/sysconf/network</filename>:
<literallayout>
    FORWARD_IPV4=yes
    DEFRAG_IPV4=yes
</literallayout>
</para>
<para>
These lines cause <filename>/etc/rc.d/rc.sysinit</filename> to execute these two
commands whenever the routers boot:
<literallayout>
    echo 1 > /proc/sys/net/ipv4/ip_forward
    echo 1 > /proc/sys/net/ipv4/ip_always_defrag
</literallayout>
</para>
<para>
To enable IP masquerading, issue this command:
<literallayout>
    ipchains -A forward -j MASQ -s n.n.n.n/type -d 0.0.0.0/0
</literallayout>
</para>
<para>
where:
</para>
<itemizedlist mark="bullet">
<listitem>
<para>  
n.n.n.n is the address of the private subnet to which the real servers are
connected.
  </para>
  </listitem>

  <listitem>
   <para>
type is 8, 16, 24, or 32 indicating the address type and mask:
<screen>
     netmask         | type | Subnet
     ~~~~~~~~~~~~~~~~|~~~~~~|~~~~~~~~~~~~~~~
     255.0.0.0       | 8    | Class A
     255.255.0.0     | 16   | Class B
     255.255.255.0   | 24   | Class C
     255.255.255.255 | 32   | Point-to-point
</screen>
</para>
        </listitem>
      </itemizedlist>
<para>
You will probably want to put the <command>ipchains</command> command in an init
script (e.g., <filename>/etc/rc.d/rc.local</filename>), so that masquerading is
configured on the LVS routers at system startup. 
</para>
<para>
<command>ipchains</command> is the tool used to create and manage firewalling
rules set in the kernel's TCP stack. Masquerading is a small subset of these
rules that allows machines making use of private IP networks to communicate with
the outside world. Using <command>ipchains</command> can have an impact on system 
security. If you have security concerns, read the <command>ipchains</command>
HOWTO (<ulink url="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html" type="html">http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html</ulink>).
</para>
</sect1>
  <sect1>
    <title>Cluster Node Interconnection Prerequisites</title>
<para>
During configuration, you select the tool family (<command>rsh</command> or
<command>ssh</command>) that will be used to synchronize the
<filename>/etc/lvs.cf</filename> configuration files on the LVS routers. The
selected tool must be enabled on the LVS routers, such that
<literal>root</literal> on each router can log in to the other router without
administrator intervention.  
</para>
<para>
Also during configuration, you select the tool (<command>uptime</command>,
<command>ruptime</command>, or <command>rup</command>) that the active router
will use to monitor the workload on the real servers. Enable the selected
tool on the real servers. If this cannot be done (for example, one of your real
servers is a Windows/NT Web server), the cluster will still provide highly
available services. However, the Weighted round robin and Weighted
least-connections algorithms (described in <xref linkend="load-balancing"> will
be affected. Namely, since load information will not be available, the
user-assigned weights will be applied statically rather than dynamically adjusted
based on server workload.   
</para>
<para>
<xref linkend="node-prereqs"> describes in general terms what you do to enable
these tools on the source and destination hosts. For more detailed information,
see the man pages. Note that, with <command>rsh</command> and
<command>ssh</command>, <literal>root</literal> must be able to log in over the
network. To enable remote root login to a Red Hat Linux system, remove the
following line from the file <filename>/etc/pam.d/login</filename>:
<literallayout>

auth      required     /lib/security/pam_security.so

</literallayout>  
This is a security hole, albeit small. Make sure you have the LVS nodes properly
firewalled so that logins are allowed only from trusted sources.
</para>
    <table id="node-prereqs">
      <title>Enabling Synchronization and Monitoring Tools</title>
     <tgroup cols="2">
      <thead>
        <row>         
          <entry>Tool</entry>
          <entry>Do This</entry>
        </row>
      </thead>
      <tbody>
        <row>
          <entry>rsh</entry>
          <entry>Create a <filename>.rhosts</filename> file with permission 600
          in the root on the destination host naming the source host and user
          (for example, foo.host1.com root).</entry>  
        </row>
         <row>
          <entry>ssh</entry>
          <entry>Obtain/install the tool, which for legal reasons is not released
          with international Linux distributions. On source and destination
          hosts, disable remote login via all other methods, set up RSA-based
          authentication using <filename>.ssh/authorized_keys</filename>, and start
          <command>sshd</command>.  </entry> 
        </row> 
        <row>
          <entry>uptime</entry>
            <entry>On each real server, enable either <command>rsh</command> or
            <command>ssh</command> as described above.</entry>
        </row>
        <row>
          <entry>ruptime</entry>
          <entry>Set up each LVS router and real server to start
          <command>rwhod</command> whenever it boots. </entry>
        </row>
        <row>
          <entry>rup</entry>
          <entry>Set up each real server to start <command>rpc.rstatd</command>
          whenever it boots. </entry>
        </row>
      </tbody>
      </tgroup>
    </table>
  </sect1>
<sect1 id="install">
<title>Installing the Software</title>
<para>
The LVS cluster software is released in three RPM packages:
<literallayout>

piranha (programs)
piranha-gui (graphical configuration tool)
piranha-docs (documentation)

</literallayout>
You can install these packages from the 6.1 CD-ROM with this command:
</para>
    <screen>   #rpm -Uvh /mnt/cdrom/RedHat/RPMS/piranha*.rpm</screen>
<para>
To obtain possible updates of these (or other) packages for your hardware
platform, visit
 <ulink url=
"http://www.redhat.com/corp/support/errata/rh61-errata-updates.html" type="http">http://www.redhat.com/corp/support/errata/rh61-errata-updates.html</ulink>
on the Red Hat website.
</para>
</sect1>
<sect1>
<title>Configuring an LVS Cluster</title>
<para>
You set up and maintain an LVS cluster from the LVS routers, by editing the
configuration file and starting or restarting the <command>pulse</command>
daemon. Specifically, the steps are:
<orderedlist>
        <listitem>
          <para>
          On the primary router, edit the configuration file
          <filename>/etc/lvs.cf</filename>.
         </para>
        </listitem>
        <listitem>
          <para>
          Copy the edited configuration file to the backup router.
          </para>
        </listitem>
        <listitem>
          <para>
          Start (or restart) the <command>pulse</command>
          daemon first on the primary router, then on the backup router.
          </para>
        </listitem>
      </orderedlist>
</para>
<para>
You can perform these steps from the shell, by editing the configuration file
with the editor of your choice. The shell commands for starting, restarting, and
stopping the <command>pulse</command> daemon are:
<literallayout>
    /etc/rc.d/init.d/pulse start
    /etc/rc.d/init.d/pulse restart
    /etc/rc.d/init.d/pulse stop
</literallayout>
The <command>pulse</command> daemon starts or restarts the other LVS cluster
daemons as needed, which obtain their configuration information, directly or
indirectly, from the current configuration file. 
</para>
<para>
If you stop <command>pulse</command> (in order to shut down the cluster), stop
it on the backup router first. This will prevent the backup router from possibly
taking over the active role.
</para>
<para>
Alternatively, you can use <command>piranha</command> to set up, monitor, and
administer your LVS cluster. The entry fields on its windows set or change lines
in <filename>/etc/lvs.cf</filename>, and there are buttons to start, stop, and
restart the cluster. Use of <command>piranha</command> requires that the X
Window System be configured on the LVS routers. An advantage of using
<command>piranha</command> is that it synchronizes the configuration file on the
primary and backup routers,  and you perform all administrative tasks from 
the active router.  
</para>
<para>
The next section describes the LVS cluster configuration file. Read this section
if you want to edit this file manually. If you chose to use
<command>piranha</command>, read <xref linkend="use-piranha">.
</para>
    <sect2 id="edit-cf">
      <title>Editing the Configuration File</title>
<para>
The <filename>/etc/lvs.cf</filename> file has three sections. The global section,
described in <xref linkend="global-cf">, sets up the LVS routers and specifies
networking and heartbeat parameters. There is one set of parameters for the
cluster. The per-virtual-server section, described in <xref linkend="per-vs-cf">,
defines virtual server addresses, sets up the associations between virtual
servers and real servers, and specifies job-scheduling parameters. There is a
separate set of parameters for each defined virtual server. The per-real-server
section, described in <xref linkend="per-rs-cf">, defines the real servers routed
to from each virtual server. There is one set of these parameters for each
virtual server.  
</para>
      <table id="global-cf">
        <title>Setting Global Parameters</title>
     <tgroup cols="2">
      <thead>
        <row>         
          <entry>Parameter</entry>
          <entry>Description</entry>
        </row>
      </thead>
      <tbody>
            <row>
              <entry>primary =</entry>
              <entry>Enter the IP address of the adapter connecting the primary
              LVS router to the public network.</entry>
            </row>     
            <row>
              <entry>backup =</entry>
              <entry>Enter the IP address of the adapter connecting the backup
              backup LVS router to the public network.</entry>
            </row>     
            <row>
              <entry>heartbeat_port = </entry>
              <entry>Enter the port number used for the heartbeat on the primary
              and backup LVS routers.</entry>
            </row>     
            <row>
              <entry>keepalive =</entry>
              <entry>Enter the number of seconds between heartbeats.</entry>
            </row>     
            <row>
              <entry>deadtime =</entry>
              <entry>Enter the number of seconds to wait before declaring a
              non-responding router dead and initiating failover.</entry>
            </row>     
            <row>
              <entry>rsh_command = [rsh|ssh]</entry>
              <entry>Enter the command family to use for synchronizing the
              configuration files on the primary and backup routers. Important:
              as described in <xref linkend="node-prereqs">, you must enable the
              selected command on the primary and backup routers.</entry>
            </row>     
            <row>
              <entry>network = [nat|direct|tunnel]</entry>
              <entry>Currently, only Network Address Translation (nat) is
              supported. </entry>
            </row>     
            <row>
              <entry>nat_router = </entry>
              <entry>Enter the floating IP address and device of the NAT
              router. This IP address must be the default route used by each
              real server to communicate with the active LVS router. The IP
              address is aliased to the device (for example, eth1:1) connecting
              the LVS routers to the private network of real servers. The device
              must be the same (i.e., eth1) on both LVS routers. </entry>
            </row>     
      </tbody>
        </tgroup>
      </table>
      <table id="per-vs-cf">
        <title>Setting Per-Virtual-Server Parameters</title>
     <tgroup cols="2">
      <thead>
        <row>         
          <entry>Parameter</entry>
          <entry>Description</entry>
        </row>
      </thead>
      <tbody>
            <row>
              <entry>name</entry>
              <entry>Enter a unique identifier for the virtual server.</entry>
            </row>           
            <row>
              <entry>address =</entry>
              <entry>Enter the virtual server's IP address: a floating IP
              address that has been associated with a fully-qualified domain
              name. </entry>
            </row>     
            <row>
              <entry>active = [0|1]</entry>
              <entry>Enable (1) or disable (0) this address.</entry>
            </row>     
            <row>
              <entry>load_monitor = [uptime|ruptime|rup]</entry>
              <entry>Select the tool (default uptime) that will be used by the
              active router to monitor the workload of real servers. Important:
              as described in <xref linkend="node-prereqs">, unless you enable the
              selected command on the real servers, the scheduling algorithms
              that use dynamic load information will apply the assigned weight
              statically rather than adjust the weight from load information. If
              you select the default (uptime), the tool you specified for
              "rsh_command" is used to log in to the real servers. This tool
              must be enabled on the real servers.</entry>
            </row>     
            <row>
              <entry>timeout =</entry>
              <entry>Enter the number of seconds (default 10) that must lapse
              before a real server determined to be dead is removed from the
              routing table.</entry> 
            </row>     
            <row>
              <entry>reentry =</entry>
              <entry>Enter the number of seconds (default 180) that a restored
              real server must remain alive before being re-added to the routing
              table.</entry>
            </row>     
            <row>
              <entry>port = [http/80|ftp/21]</entry>
              <entry>Enter the listening port on this virtual server:  http for
              80 (the default) or ftp for 21. Or you can enter the numbers.</entry>
            </row>     
            <row>
              <entry>scheduler = [wlc|lc|wrr|rr]</entry>
              <entry>Select the scheduling algorithm (default wlc) for
              distributing jobs from this virtual server to the real
              servers. The choices are described in <xref
              linkend="load-balancing">.  
             </entry>
            </row>     
      </tbody>
        </tgroup>
      </table>
      <table id="per-rs-cf">
        <title>Setting Per-Real-Server Parameters</title>
     <tgroup cols="2">
      <thead>
        <row>         
          <entry>Parameter</entry>
          <entry>Description</entry>
        </row>
      </thead>
      <tbody>
            <row>
              <entry>name</entry>
              <entry>Enter a unique name for the real server.</entry>
            </row>           
            <row>
              <entry>address = </entry>
              <entry>Enter the IP address of the real server on the private
              network. </entry>
            </row>     
            <row>
              <entry>active = [0|1]</entry>
              <entry>Enable (1) or disable (0) the real server.</entry>
            </row>     
            <row>
              <entry>weight =</entry>
              <entry>Enter an integer (default is 1) specifying this server's
              processing capacity relative to that of other real servers. For
              example, a server assigned 2000 has twice the capacity of a server
              assigned 1000. The weighted scheduling algorithms adjust this
              number dynamically based on workload.</entry>
            </row>     
      </tbody>
        </tgroup>
      </table>
    </sect2>
    <sect2 id="use-piranha">
      <title>Using the Piranha Configuration Tool</title>
<para>
To start <command>piranha</command>, become root and type <command>piranha
&</command>. When you do, its main window opens. The window has four tabs:
</para>
<para>
<guilabel>
Controls/Monitoring
</guilabel> --
    The initial tab. Used to start/stop/restart the cluster daemons and monitor
the runtime status. See <xref linkend="control-tab">.  
</para>
<para>
<guilabel>
Global Settings
</guilabel> --
    Use to set the IP address of the primary LVS router and NAT router. See <xref
          linkend="global-tab">. 
</para>
<para>
<guilabel>
Redundancy
</guilabel> --
    Use to set the address of the backup LVS router and set the heartbeating
    parameters. See <xref linkend="redundancy-tab">.
</para>
<para>
<guilabel>
Virtual Servers
</guilabel> --
    Use to set service addresses and set up routing between service
    addresses and real Web/FTP server hosts. See <xref linkend="vs-tab">.
</para>
<para>
Piranha windows have one or more of these buttons along the bottom:
</para>
<para>
<guilabel>
	OK 
</guilabel> --
 Apply changes and exit from the window.
</para>
<para>
<guilabel>
	Apply
</guilabel> --
 Apply changes without exiting the window.
</para>
<para>
<guilabel>
	Close
</guilabel> -- 
 Exit from the window without applying changes.
</para>
<sect3 id="control-tab">
<title>Controls/Monitoring Tab</title>
  <informaltable>
    <tgroup cols="2">
      <thead>
        <row>         
          <entry>Field/Button</entry>
          <entry>Description</entry>
        </row>
      </thead>
      <tbody>
        <row>
          <entry>Start/Stop</entry>
          <entry>When cluster daemons are not running, this button is labeled
          Start: click it to start the cluster. When the daemons are running,
          the button is labeled Stop: click it to stop the cluster daemons.</entry>
        </row>
        <row>
          <entry>Add pulse daemon to this runlevel</entry>
          <entry>Select to start pulse at system boot at this runlevel.</entry>
        </row>
        <row>
          <entry>Update information now</entry>
          <entry>Click to display current information in the kernel routing
          table. </entry>
        </row>
        <row>
          <entry>Auto-update</entry>
          <entry>Select to display kernel table routing information
          automatically at the specified interval. </entry>
        </row>
      </tbody>
    </tgroup>
  </informaltable>
</sect3>
<sect3 id="global-tab">
<title>Global Settings Tab</title>
  <informaltable>
    <tgroup cols="2">
      <thead>
        <row>         
          <entry>Field/Button</entry>
          <entry>Description</entry>
        </row>
      </thead>
      <tbody>
        <row>
          <entry>Primary LVS server IP</entry>
          <entry>Contains the public IP address of the primary LVS router. </entry>
        </row>
        <row>
          <entry>NAT Router IP</entry>
          <entry>Contains the floating IP address associated with the network
          adapter connecting the virtual server with the network of real
          servers. This address is the gateway used by the real servers to
          communicate with the virtual server. If this node fails, this address
          migrates to the backup LVS node.  </entry>
        </row>
        <row>
          <entry>NAT Router Device</entry>
          <entry>Names the device with which the NAT router IP address is
          associated. This is done via address aliasing. For example, the NAT
          router IP may be aliased to physical device eth1 as eth1:1. </entry>
        </row>
        <row>
          <entry>Sync tool</entry>
          <entry>Select the tool (rsh or ssh) for synchronizing files on the
          primary and backup LVS routers. The tool you select must be enabled,
          such that the LVS routers can log in to one another without needing
          to enter a password. For general procedures, see 
          <xref linkend="node-prereqs">. </entry>
        </row>
      </tbody>
    </tgroup>
  </informaltable>
</sect3>
<sect3 id="redundancy-tab">
<title>Redundancy Tab</title>
  <informaltable>
    <tgroup cols="2">
      <thead>
        <row>         
          <entry>Field/Button</entry>
          <entry>Description</entry>
        </row>
      </thead>
      <tbody>
        <row>
          <entry>Enable redundant server</entry>
          <entry>Select to enable failover.</entry>
        </row>
        <row>
          <entry>Redundant LVS server IP</entry>
          <entry>Contains the public IP address of the backup LVS node.</entry>
        </row>
        <row>
          <entry>Heartbeat interval (seconds)</entry>
          <entry>Contains the number of seconds between heartbeats: the interval
          at which the backup LVS node checks to see if the primary LVS node is
          alive. </entry>
        </row>
        <row>
          <entry>Assume dead after (seconds)</entry>
          <entry>If this number of seconds lapses without a response from the
          primary LVS node, the backup router initiates failover. During failover,
          the backup router claims all virtual server IPs being processed by the
          primary LVS router, and broadcasts gratuitous ARPs advertising its MAC
          address as the destination of packets addressed to the primary
          router.</entry> 
        </row>
        <row>
          <entry>Heartbeat port</entry>
          <entry>Enter the port used for the heartbeat on the primary and backup
          LVS routers.</entry>
        </row>
      </tbody>
    </tgroup>
  </informaltable>
</sect3>
<sect3 id="vs-tab">
<title>Virtual Servers</title>
<para>
This screen displays a row of information for each currently defined virtual
server. Click a row to select it. The buttons on the right side of the
screen apply to the currently selected virtual server. Click Delete to remove
the selected virtual server.
</para>
  <informaltable>
    <tgroup cols="2">
      <thead>
        <row>         
          <entry>Field/Button</entry>
          <entry>Description</entry>
        </row>
      </thead>
      <tbody>
        <row>
          <entry>Status</entry>
          <entry>Displays Active or Down. Click Disable to take down a selected
          active virtual server; click Activate to enable a selected down
          virtual server. After changing the status, you must restart the pulse
          daemon to make the change take affect. To do this, go to the
          Controls/Monitoring tab, click the Stop button (its name changes to
          Start), then click Start.  </entry>
        </row>
        <row>
          <entry>Name</entry>
          <entry>Contains a unique identifier for the virtual server.</entry>
        </row>
        <row>
          <entry>Port</entry>
          <entry>Contains the number of the listen port for incoming requests
          for service. </entry>
        </row>
        <row>
          <entry>Protocol</entry>
          <entry>Currently, only TCP is supported. </entry>
        </row>
      </tbody>
    </tgroup>
  </informaltable>
<sect4 id="vs-edit-tab">
<title>Add/Edit a Virtual Server</title>
<para>
Click the Add button to create a new, undefined virtual server. Click the
Edit button (or double-click the row) to define or modify a virtual
server. Click the Real Servers tab to view or modify the real servers
associated with the selected virtual server. 
</para>
  <informaltable>
    <tgroup cols="2">
      <thead>
        <row>         
          <entry>Field/Button</entry>
          <entry>Description</entry>
        </row>
      </thead>
      <tbody>
        <row>
          <entry>Name</entry>
          <entry>Enter a unique identifier for this virtual server.</entry>
        </row>
        <row>
          <entry>Application</entry>
          <entry>Click to select HTTP or FTP.</entry>
        </row>
        <row>
          <entry>Port</entry>
          <entry>Enter the number of the listen port for incoming requests
          for service. </entry>
        </row>
        <row>
          <entry>Address</entry>
          <entry>Enter the floating IP address where requests for service
          arrive. This address will have been associated with the
          fully-qualified domain name to which requests for service are
          addressed. </entry>
        </row>
        <row>
          <entry>Device</entry>
          <entry>Name the adapter device connecting the LVS routers to the
          public network, with which the floating IP address is associciated
          via IP aliasing (For example, eth0:1). If the active router fails, the
          virtual server address and port are failed-over to this device on the
          backup router, which becomes the active router. </entry>
        </row>
        <row>
          <entry>Re-entry Time</entry>
          <entry>Enter the number of seconds (default is 180) that a failed real
          server associated with this virtual server must remain alive before
          it will be re-added to the cluster. </entry>
        </row>
        <row>
          <entry>Service timeout</entry>
          <entry>Enter the number of seconds (default is 10) within which a real
          server must respond to a redirected request. If a host takes longer
          than this, it is declared dead and removed from the cluster.</entry>
        </row>
        <row>
          <entry> </entry>
          <entry>Every two seconds the <command>nanny</command> process on the
          active router sends a heartbeat (essentially a <command>ping</command>)
          to each real server. If this succeeds, then a service connect
          (essentially a <command>telnet</command> conection) is sent
          out on the specified service port. If <command>nanny</command> gets
          back any response from a real server, it and the service are assumed
          to be alive. If "Service timeout" seconds lapse without a response,
          then the real server is presumed to be dead and is dropped from the
          routing table. But <command>nanny</command> continues to monitor the
          server/service by sending out heartbeats every two seconds. If, after
          a successful <command>ping</command>, a dropped server remains alive
          for "Re-entry Time" number of seconds, the server is re-added to the
          kernel routing table.
         </entry>
        </row>
        <row>
          <entry>Load monitoring tool</entry>
          <entry>Select the tool to use (<command>uptime</command>,
          <command>rup</command>, or <command>ruptime</command>) for 
          determining the workload on the real servers. The general procedures
          for enabling these tools are described in the table in
          <xref linkend="node-prereqs">.  </entry> 
        </row>
        <row>
          <entry>Scheduling</entry>
          <entry>Select the algorithm for routing requests from this virtual
          server to the real servers. The choices are described in <xref
          linkend="load-balancing">. 
          </entry>   
        </row>
      </tbody>
    </tgroup>
  </informaltable>
</sect4>
</sect3>
<sect3 id="rs-tab">
<title>Real Servers</title>
<para>
This screen displays a row of information for each currently defined real
server. Click a row to select it. The buttons on the right side of the
screen apply to the currently selected row. Click Delete to remove the
selected real server.
</para>
  <informaltable>
    <tgroup cols="2">
      <thead>
        <row>         
          <entry>Field/Button</entry>
          <entry>Description</entry>
        </row>
      </thead>
      <tbody>
        <row>
          <entry>Status</entry>
          <entry>Displays Active or Down. Click Disable to take down a selected
          active virtual server; click Activate to enable a selected down
          virtual server. After changing the status, you must restart the pulse
          daemon to make the change take affect. To do this, go to the
          Controls/Monitoring tab, click the Stop button (its name changes to
          Start), then click Start. </entry>
        </row>
        <row>
          <entry>Name</entry>
          <entry>Displays the server's name in the cluster.</entry>
        </row>
        <row>
          <entry>Address</entry>
          <entry>Displays the server's IP address. </entry>
        </row>
      </tbody>
    </tgroup>
  </informaltable>
<sect4 id="rs-edit-tab">
<title>Add/Edit a Real Server</title>
<para>
Click the Add button to create a new, undefined real server. Click the Edit
button (or double-click the row) to define or change the selected real server.
</para>
  <informaltable>
    <tgroup cols="2">
      <thead>
        <row>         
          <entry>Field/Button</entry>
          <entry>Description</entry>
        </row>
      </thead>
      <tbody>
        <row>
          <entry>Name</entry>
          <entry>Enter a descriptive name. </entry>
        </row>
        <row>
          <entry>Address</entry>
          <entry>Enter the IP address of the real server on the private network.
          </entry>
        </row>
        <row>
          <entry>Weight</entry>
          <entry>Assign an integer to indicate this host's processing capacity
          relative to that of other hosts in the pool. </entry>
        </row>
      </tbody>
    </tgroup>
  </informaltable>
</sect4>
</sect3>
</sect2>
</sect1>
  <sect1 id="example-layout">
    <title>Example -- Setting Up a Five-node Cluster</title>
    <para>This section describes step by step how to create a
cluster of two LVS routers and three Web/FTP servers. First, collect
information and set up the five systems as explained in the next section. Then,
implement the example either from a shell
(explained in <xref linkend="example-edit-cf">) or by starting the GUI
configuration tool (explained in <xref linkend="example-piranha">). </para>
    <para><xref linkend="network-topology"> shows the network that will exist
    after you've set up the LVS routers and real servers. All network addresses
    shown are for purposes of illustration only. </para>
    <figure id="network-topology">
      <title>Layout of the Example Network</title>
<screen>
|-------|------------------------------------------|---------| Public network
        |eth0=1.2.3.2                              |eth0=1.2.3.3
        |eth0:1=1.2.3.1 (vs1)                      |
  ------|-----                              -------|-----
  |  active  |                              |   backup  |
  |  router  |                              |   router  |  
  |          |                              |           | 
  ------|-----                              -------|-----
        |eth1=192.168.1.1                          |eth1=192.168.1.2
        |eth1:1=192.168.1.254 (NAT router)         |
|-------|-|------------------|-----------------|---|----------| Private network
          |eth0=192.168.1.3  |eth0=192.168.1.4 |eth0=192.168.1.5 
          |                  |                 |
          |---------|        |---------|       |---------|
          |   rs1   |        |   rs2   |       |   rs3   |  
          |_________|        |_________|       |_________|

</screen>
    </figure>
    <sect2 id="example-setup">
      <title>Preliminary Setup</title>
    <orderedlist>
      <listitem id="vs-addr">
        <para>
>From the webmaster, obtain a virtual server IP address. In our example this
will be 1.2.3.1. Requests for service at the LVS cluster will be
addressed to a fully-qualified domain name associated with this address.
       </para>      
      </listitem>
      <listitem>
        <para>
Locate 5 servers and designate their roles: 1 primary LVS router, 1 backup LVS
router, 3 real servers. The LVS routers must be Linux boxes running Red Hat 6.1
or later. The real servers may be any platform running any operating system and
Web server.</para>
        <para>
Steps <xref linkend="router-addrs">-<xref linkend="verify-software"> set up the
LVS routers.</para> 
      </listitem>
      <listitem id="router-addrs">
        <para>
On each LVS router, install two ethernet adapter cards, eth0 and eth1.
Create a public IP interface on eth0 and a private IP interface on eth1. The
public interface device (eth0) is the heartbeat device. The virtual server address
is aliased to this device.</para>
        <informaltable>
         <tgroup cols="2">
          <thead>
          <row>         
           <entry> </entry>
          <entry>Primary node</entry>
          <entry>Backup node</entry>
        </row>
      </thead>
            <tbody>
              <row>
                <entry>eth0</entry>
                <entry>1.2.3.2</entry>
                <entry>1.2.3.3</entry>
              </row>
              <row>
                <entry>eth1</entry>
                <entry>192.168.1.1</entry>
                <entry>192.168.1.2</entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>
      </listitem>
      <listitem id="NAT-addr">
        <para>
Designate an IP address (192.168.1.254) for the router device (eth1) connecting
the active LVS router to the private network. This floating IP address will be
aliased to the router device as eth1:1, and will be the gateway to the private
network and the default route used by each real server to communicate with the
active router.</para> 
      </listitem>
      <listitem>
        <para>
On each LVS router:</para>
        <orderedlist numeration="loweralpha">
          <listitem id="ip-forward">
            <para>
Enable packet forwarding. To do this at system boot, make sure the file
<filename>/etc/sysconf/network</filename> contains the line
<literal>FORWARD_IPV4=yes</literal>. To enable packet forwarding without
rebooting, as root issue this command:
<literallayout>

    <command>echo "1" > /proc/sys/net/ipv4/ip_forward</command>
</literallayout>
</para>
          </listitem>
          <listitem id="ip-defrag">
            <para>
Enable packet defragmenting. To do this at system boot, make sure the file
<filename>/etc/sysconf/network</filename> contains the line
<literal>DEFRAG_IPV4=yes</literal>. To enable packet defragmenting without
rebooting, as root issue this command:
<literallayout>

    <command>echo "1" > /proc/sys/net/ipv4/ip_always_defrag</command>
</literallayout>
</para>
          </listitem>
          <listitem id="ip-masquerade">
            <para>
Masquerade the private network. Issue this command and put it in
<filename>/etc/rc.d/rc.local</filename>:
<literallayout>

    <command>ipchains -A forward -j MASQ -s 192.168.1.0/24 -d 0.0.0.0</command>

</literallayout>
</para>
          </listitem>
        </orderedlist>
      </listitem>
      <listitem id="sync-tool">
        <para>
Decide whether to use the <command>rsh</command> or <command>ssh</command>
families for synchronizing LVS cluster files.
Verify that your choice is installed such that the LVS routers can log in
to one another as root without administrator intervention (see <xref
linkend="node-prereqs">). In this example, we will choose
<command>rsh</command>. </para> 
      </listitem>
      <listitem id="verify-software">
        <para>
On each LVS router, verify that the LVS cluster software is installed (see <xref
linkend="install">.</para> 
        <para>
Steps <xref linkend="rs-addrs">-<xref linkend="web-server"> set up real
servers.</para> 
      </listitem>
      <listitem id="rs-addrs">
        <para>
On each real server, install an ethernet network card, eth0, create
an IP address on the same private subnet as in Step <xref
linkend="router-addrs">, and assign a weight to each server indicating its
processing capacity relative to that of the others. In this example, rs1 has
twice the capacity (two processors) of rs2 and rs3.</para> 
        <informaltable>
          <tgroup cols="4">
            <thead>
              <row>
                <entry> </entry>
                <entry>rs1</entry>
                <entry>rs2</entry>
                <entry>rs3</entry>
              </row>
            </thead>
            <tbody>
              <row>
                <entry>eth0</entry>
                <entry>192.168.1.3</entry>
                <entry>192.168.1.4</entry>
                <entry>192.168.1.5</entry>
              </row>
              <row>
                <entry>weight</entry>
                <entry>2000</entry>
                <entry>1000</entry>
                <entry>1000</entry>
              </row>
            </tbody>
          </tgroup>
          </informaltable>
      </listitem>
      <listitem id="default-route">
        <para>
On each real server, verify that the address named in Step <xref
linkend="NAT-addr"> (192.168.1.254) is its default route for communicating with
the active LVS router.</para> 
      </listitem>
      <listitem id="loadmonitor-tool">
        <para>
Decide which program (<command>uptime</command>, <command>ruptime</command>,
<command>rup</command>) will be used by the active router to monitor the
workload on the real servers. If you choose <command>uptime</command>, each 
LVS router must be able to connect with each real server without
administrator intervention, using the tool family you selected in Step <xref
linkend="sync-tool">. See <xref linkend="node-prereqs"> for general enablement
instructions. If the selected tool cannot be enabled (for example, one of the real
servers is an NT box), the scheduling algorithms that use dynamic load
information will still work but the user-assigned weights will be statically
applied rather than dynamically adjusted based on load.</para> 
      </listitem>
      <listitem id="web-server">
        <para>
Verify that each real server runs an installed and configured httpd server. Note
that the real servers must listen on the same port (80 in the example) as the
corresponding virtual server. 
</para>
      </listitem>
        <listitem>
          <para>Verify (for example, using <command>telnet</command> or
          <command>ping</command>) that each real server can reach hosts on the
          public LAN. If a real server on the private network cannot
          reach a host on your LAN, this probably indicates a communication
          failure between the server and the active router. See Steps <xref
          linkend="rs-addrs"> and <xref linkend="default-route">.</para>  
        </listitem>
        <listitem id="runtime-params">
          <para>Determine the runtime parameters. For some of these, you may
          need to experiment over time to obtain optimal values. In this
          example, we will use the values listed.</para>
          <informaltable>
           <tgroup cols="2">
            <thead>
              <row>         
                 <entry>Value</entry>
                 <entry>Parameter Description</entry>
               </row>
             </thead>
              <tbody>
                <row>
                  <entry>1050</entry>
                  <entry>Number of the heartbeat listening port on the primary
                  and backup routers.</entry>
                </row>
                <row>
                  <entry>2</entry>
                  <entry>Number of seconds between heartbeats.</entry>
                </row>
                <row>
                  <entry>10</entry>
                  <entry>Number of seconds to wait for a non-responding router
                  to respond before initiating failover.</entry>
                </row>
                <row>
                  <entry>10</entry>
                  <entry>Number of seconds to wait for a non-responding real
                  server to respond before removing it from the routing
                  table.</entry> 
                </row>
                <row>
                  <entry>180</entry>
                  <entry>When a real server that has been removed from the
                  routing table starts responding again, wait this number of
                  seconds before re-adding the server to the routing
                  table.</entry> 
                </row>
                <row>
                  <entry>wlc</entry>
                  <entry>Use the Weighted least-connections load-balancing
                  algorithm (assign more jobs to servers that are least busy
                  relative to their load-adjusted weight). See <xref
                  linkend="load-balancing"> for a description of the choices.</entry>
                </row>
                <row>
                  <entry>http</entry>
                  <entry>Application. The alternative is ftp.</entry>
                </row>
                <row>
                  <entry>80</entry>
                  <entry>Virtual server port number. The listening port selected
                  for the virtual server is used on the real servers as
                  well.</entry> 
                </row>
              </tbody>
            </tgroup>
          </informaltable>

        </listitem>
      </orderedlist>
      <para>Now we are ready to implement the example. You can do this from a
      shell as explained in the next section. Or you can use the GUI
      configuration tool as explained in <xref
      linkend="example-piranha">.</para> 
    </sect2>
    <sect2 id="example-edit-cf">
      <title>Implementing the Example from the Shell</title>
      <orderedlist>
        <listitem>
          <para>With your favorite editor, open <filename>/etc/lvs.cf</filename>
          and set the values shown below. The number on the right is a link
          to the step in <xref linkend="example-setup"> that discusses
          this setting.
        <literallayout>
# Global section
primary = 1.2.3.2                    <xref linkend="router-addrs">
backup =  1.2.3.3                    <xref linkend="router-addrs">
keepalive = 2                        <xref linkend="runtime-params">
deadtime = 10                        <xref linkend="runtime-params">
heartbeat_port = 1050                <xref linkend="runtime-params">
rsh_command = rsh                    <xref linkend="sync-tool">
network = nat
nat_router = 192.168.1.254 eth1:1    <xref linkend="NAT-addr">
# Per-virtual-server section
virtual server vs1 {                 <xref linkend="rs-addrs">      
 address = 1.2.3.1                   <xref linkend="vs-addr">
 active = 1
 load_monitor = ruptime              <xref linkend="loadmonitor-tool">
 timeout = 10                        <xref linkend="runtime-params">
 reentry = 180                       <xref linkend="runtime-params">
 port = 80                           <xref linkend="runtime-params">
 scheduler = wlc                     <xref linkend="runtime-params">
# Per-real-server section
 server rs1 {                        <xref linkend="rs-addrs">
  address = 192.168.1.3              <xref linkend="rs-addrs">
  active = 1
  weight = 2000                      <xref linkend="rs-addrs">
 }
 server rs2 {                        <xref linkend="rs-addrs">
  address = 192.168.1.4              <xref linkend="rs-addrs">
  active = 1
  weight = 1000                      <xref linkend="rs-addrs">
 }
 server rs3 {                        <xref linkend="rs-addrs">
  address = 192.168.1.5              <xref linkend="rs-addrs">
  active = 1
  weight = 1000                      <xref linkend="rs-addrs">
 }
}
        </literallayout>
        </para>
        </listitem>
       <listitem>
          <para>
          Copy the edited configuration file to the backup router.
          </para>
        </listitem>
        <listitem>
          <para>
          On the primary router, start the <command>pulse</command>
          daemon with this command:</para>
          <literallayout>
              /etc/rc.d/init.d/pulse start                
          </literallayout>
        </listitem>
        <listitem>
          <para>
          Start <command>pulse</command> on the backup router.
          </para>
        </listitem>
      </orderedlist>
    </sect2>
    <sect2 id="example-piranha">
      <title>Implementing the Example with Piranha</title>
      <orderedlist>
      <listitem>
        <para>
On the primary LVS router, as root, type <command>piranha &</command> to start
the GUI configuration tool. 
</para>
      </listitem>
          <listitem>
            <para>
Click the Global Settings tab and enter the values shown:</para>
        <informaltable>
          <tgroup cols="3">
            <thead>
              <row>
                <entry>Field</entry>
                <entry>Enter:</entry>
                <entry>See Step:</entry>
              </row>
             </thead>
                <tbody>
                  <row>
                    <entry>Primary LVS server IP</entry>
                    <entry>1.2.3.2</entry>
                    <entry><xref linkend="router-addrs"></entry>
                  </row>
                  <row>
                    <entry>NAT Router IP</entry>
                    <entry>192.168.1.254</entry>
                    <entry><xref linkend="NAT-addr"></entry>
                  </row>
                  <row>
                    <entry>NAT Router Device</entry>
                    <entry>eth1:1</entry>
                    <entry><xref linkend="NAT-addr"></entry>
                  </row>
                  <row>
                    <entry>Sync tool</entry>
                    <entry>rsh</entry>
                    <entry><xref linkend="sync-tool"></entry>
                  </row>
                </tbody>
              </tgroup>
            </informaltable>
          </listitem>
          <listitem>
            <para>
Click the Redundancy tab and enter the values shown:</para>
        <informaltable>
          <tgroup cols="3">
            <thead>
              <row>
                <entry>Field</entry>
                <entry>Enter:</entry>
                <entry>See Step:</entry>
              </row>
             </thead>
                <tbody>
                  <row>
                    <entry>Enable Redundant server</entry>
                    <entry>(select)</entry>
                    <entry> </entry>
                  </row>
                  <row>
                    <entry>Redundant LVS server IP</entry>
                    <entry>1.2.3.3</entry>
                    <entry><xref linkend="router-addrs"></entry>
                  </row>
                  <row>
                    <entry>Heartbeat interval</entry>
                    <entry>2</entry>
                    <entry><xref linkend="runtime-params"></entry>
                  </row>
                  <row>
                    <entry>Assume dead after</entry>
                    <entry>10</entry>
                    <entry><xref linkend="runtime-params"></entry>
                  </row>
                <row>
                  <entry>Heartbeat port</entry>
                  <entry>1050</entry>
                  <entry><xref linkend="runtime-params"></entry>
                </row>
                </tbody>
              </tgroup>
            </informaltable>
          </listitem>
          <listitem>
            <para>
Click the Virtual Servers tab. On the tab, click Add, then Edit, and
enter the values shown:</para>
        <informaltable>
          <tgroup cols="3">
            <thead>
              <row>
                <entry>Field</entry>
                <entry>Enter:</entry>
                <entry>See Step:</entry>
              </row>
             </thead>
                <tbody>
                  <row>
                    <entry>Name</entry>
                    <entry>vs1</entry>
                    <entry> </entry>
                  </row>
                  <row>
                    <entry>Application</entry>
                    <entry>http</entry>
                    <entry><xref linkend="runtime-params"></entry>
                  </row>
                  <row>
                    <entry>Port</entry>
                    <entry>80</entry>
                    <entry><xref linkend="runtime-params"></entry>
                  </row>
                  <row>
                    <entry>Address</entry>
                    <entry>1.2.3.1</entry>
                    <entry><xref linkend="vs-addr"></entry>
                  </row>
                  <row>
                    <entry>Device</entry>
                    <entry>eth0:1</entry>
                    <entry><xref linkend="router-addrs"></entry>
                  </row>
                  <row>
                    <entry>Re-entry time</entry>
                    <entry>180</entry>
                    <entry><xref linkend="runtime-params"></entry>
                  </row>
                  <row>
                    <entry>Service timeout</entry>
                    <entry>10</entry>
                    <entry><xref linkend="runtime-params"></entry>
                  </row>
                  <row>
                    <entry>Load monitoring tool</entry>
                    <entry>ruptime</entry>
                    <entry><xref linkend="loadmonitor-tool"></entry>
                  </row>
                  <row>
                    <entry>Scheduling</entry>
                    <entry>weighted least-connections</entry>
                    <entry><xref linkend="runtime-params"></entry>
                  </row>
                </tbody>
              </tgroup>
            </informaltable>
          </listitem>
          <listitem id="rs-config">
            <para>
Click the Real Servers tab. On the tab, click Add, then Edit, and enter the values
shown:</para>
        <informaltable>
          <tgroup cols="3">
            <thead>
              <row>
                <entry>Field</entry>
                <entry>Enter:</entry>
                <entry>See Step:</entry>
              </row>
             </thead>
                <tbody>
                  <row>
                    <entry>Name</entry>
                    <entry>rs1</entry>
                    <entry><xref linkend="rs-addrs"></entry>
                  </row>
                  <row>
                    <entry>Address</entry>
                    <entry>192.168.1.3</entry>
                    <entry><xref linkend="rs-addrs"></entry>
                  </row>
                  <row>
                    <entry>Weight</entry>
                    <entry>2000</entry>
                    <entry><xref linkend="rs-addrs"></entry>
                  </row>
                </tbody>
              </tgroup>
            </informaltable>
          </listitem>
          <listitem>
            <para>
Repeat Step <xref linkend="rs-config"> for rs2 (192.168.1.4) and rs3
(192.168.1.5). For them, enter a weight of 1000, which will indicate that rs1
has twice the computing capacity of rs2 and rs3.</para> 
          </listitem>
          <listitem>
            <para>
Click Close to return to the Real Servers tab. There, select each real
server and click Activate to activate it.</para>
          </listitem>
          <listitem>
            <para>
Click Close to return to the Virtual Servers tab. There, select the vs1
virtual server and click Activate to activate it.</para>
          </listitem>
      <listitem>
        <para>
Click the Controls/Monitoring tab and:</para>
        <orderedlist numeration="loweralpha">
          <listitem>
            <para>
Click the Start button (name changes to Stop).</para>
          </listitem>
          <listitem>
            <para>
If you check "Add pulse daemon to this runlevel" the cluster will be
started at boot time and, on startup of piranha, the button above will
usually be labeled Stop.</para>
          </listitem>
        </orderedlist>
      </listitem>
        <listitem>
          <para>Log in to the backup router and start <command>pulse</command>
          with this command:
          <literallayout>

              /etc/rc.d/init.d/pulse start
          </literallayout></para>
        </listitem>
     </orderedlist>
        <para>
If you enter the values exactly as shown above, piranha generates at the end of
the configuration file the structures shown below for this virtual server and
its real servers.</para> 
        <literallayout>
network = nat
nat_router = 192.168.1.254 eth1:1

virtual vs1 {
        address = 1.2.3.1 eth0:1
        active = 1
        scheduler = wlc
        load_monitor = ruptime
        timeout = 5

        server rs1 {
                address = 192.168.1.3
                active = 1
                weight = 2000
        }
        server rs2 {
                address = 192.168.1.4
                active = 1
                weight = 1000
        }
        server rs3 {
                address = 192.168.1.5
                active = 1
                weight = 1000
        }
}
</literallayout>
    </sect2>
  </sect1>

</article>
