Howtos - Clustering with LVS

Overview

This is a howto for creating a high-available gateway/firewall with ClarkConnect and the Linux Virtual Server (LVS) solution. In our example, two ClarkConnect systems will be installed: one master server and one slave server.

• The master and slave run in parallel
• Only one of the systems is "live"
• If the master fails, the slave will automatically take over
• If the slave fails, well... the master is still doing its job

We (Point Clark Networks) have already implemented this system for our own purposes. In our data centers, we use LVS not only for high-availability, but also load balancing. We have put the proverbial pen to paper and tell you how to do it!

Installation

After installing your ClarkConnect system, you will need to install the keepalive software. As of version 3.1, you can install the software with the following commands:

apt-get update
apt-get install keepalived

Configuration

The first step is to create a configuration file. Keepalive will look for keepalived.conf in the /etc/keepalived directory. There are slight differences between MASTER and BACKUP configurations. Below is an annotated configuration example:

This is a common global definition block. The lvs_id keyword should be set to a unique name per LVS host. The remainder of the global_defs block contains optional SMTP/email settings. This is used to send email alerts when an LVS host transitions from one state to another.

! Comments begin with a bang '!'

global_defs {

   lvs_id lvs1

   notification_email {
       admin@yourdomain.com
   }

   notification_email_from noreply@yourdomain.com

   smtp_server 127.0.0.1
   smtp_connect_timeout 30

}

The next section defines a vrrp_sync_group. This is basically a group of interfaces that Keepalive will manage. The group can also define a script to be called during state transitions (ex: from MASTER to BACKUP). This is done by adding an appropriate notify_<state> keyword, where <state> is one of: master, backup, or fault. A fault state means that there was a fatal error when LVS attempted to transition between master to backup or vise versa. The vrrp_sync_group is given the name VG1 in this example but can be anything you choose.

vrrp_sync_group VG1 {

   group {
       EXTIF
       INTIF
   }

   ! Optional notification scripts
   notify_master "/etc/keepalived/notify_master.sh"
   notify_backup "/etc/keepalived/notify_backup.sh"
   notify_fault "/etc/keepalived/notify_fault.sh"

}

Next we define vrrp_instance blocks for each interface defined in the above vrrp_sync_group. In our example, we have defined an external (EXTIF) and internal (INTIF) interface. For each of those, we need to configure certain properties such as the physical interface name, ex: eth0. Note the state and priority keywords. Their values depend on which LVS host we are writing a configuration for. The state keyword can be set to MASTER or BACKUP. The priority keyword is used to sort out which LVS host will be promoted to MASTER first. If the current MASTER LVS host were to fail, the next host with the highest priority will be promoted to take over. The virtual_router_id keyword must contain an unique number per vrrp_instance. The interface keyword would be set to the physical interface name that corresponds to the name given to the vrrp_instance block (ex: EXTIF = external interface). Keepalive will broadcast vrrp packets so that all other LVS hosts can keep in sync with each other. The lvs_sync_daemon_interface is used to tell keepalived which interface it should send these broadcasts on. Generally, it's a good idea to keep these broadcasts within your network - on a local LAN segment. In the example, we are using eth1 which is internal. The advert_int keyword is set to the number of seconds between each "advertisement" broadcast. If one of the LVS hosts were to fail, the remaining hosts would be notified within this amount of time. The authentication block defines the password/key used to encrypt vrrp broadcast packets. It is recommended to stick with the AH auth_type as it is encrypted and more secure. The virtual_ipaddress block would contain the IP address for this interface. The MASTER LVS host will assign this IP address as a virtual address to the configured interface. Optionaly, as with the vrrp_sync_group block, you can define an external program to be run when an LVS host transitions between one state to another.

vrrp_instance EXTIF {

   state MASTER
   priority 150
   virtual_router_id 1

   interface eth0
   lvs_sync_daemon_inteface eth1

   advert_int 5

   authentication {
       auth_type AH
       auth_pass cb7a9e8df183f71d
   }

   virtual_ipaddress {
       216.138.224.74
   }

   notify_master "/etc/keepalived/notify_master.sh"
   notify_backup "/etc/keepalived/notify_backup.sh"
   notify_fault "/etc/keepalived/notify_fault.sh"

}

The INTIF vrrp_instance follows next (which is mostly the same as above):

vrrp_instance INTIF {

   state MASTER
   priority 150
   virtual_router_id 2

   interface eth1
   lvs_sync_daemon_inteface eth1

   advert_int 1

   authentication {
           auth_type AH
           auth_pass aa8317630e7e0afc
   }

   virtual_ipaddress {
       192.168.1.1
   }

}

Mirroring Configuration Files

You will also want to keep the configuration files on both systems synchronized. You can do this with secure copy or rsync. The following files should be copied:

• /etc/dansguardian/*conf
• /etc/dansguardian/*list
• /etc/dhcpd.conf
• /etc/dnsmasq.conf
• /etc/firewall
• /etc/hosts
• /etc/ipsec.managed
• /etc/rc.d/rc.firewall.local
• /etc/snort.conf
• /etc/snortsam.conf
• /etc/squid.conf
• /etc/ppp/options.pptpd

	Warning!

The PPTP VPN server requires user accounts. For now, PPTP users should be added to both the master and slave servers.

Links

• LVS - Linux Virtual Server