Ajitabh Pandey's Soul & Syntax

Exploring systems, souls, and stories – one post at a time

Author: Ajitabh

  • Highly Available Apache with mod_jk load balanced Tomcat

    This how-to describes the procedure for setting up a highly available setup in which a pair of apache servers are load balancing a pair of tomcat servers. I have tested this configuration with Red Hat Enterprise 4, Fedora Core 5, Debian GNU/Linux 3.1 and CentOS 4. Technically this should work on any Unix capable of running apache+mod_jk, tomcat and heartbeat.

    Pre-requisites

    A pair of linux machine with Apache web server running with the default configuration.

    Assumptions

    Hostnames – webhst01, webhst02 Domain – Unixclinic.net IP addresses – 192.168.1.1, 192.168.1.2

    This is described in another post – Setting Up Tomcat and Apache

    Setting up highly available Apache

    We need to install “heartbeat” on both the machines for making apache as highly available. Except for Red Hat Enterprise linux, heartbeat is in the package set of Fedora, Debian and CentOS. CentOS packages work on Red Hat enterprise linux.

    On Fedora and CentOS

    yum install heartbeat

    On Debian

    apt-get install heartbeat

    Configuring heartbeat

    With a high availability set-up, its recommended that the heartbeat travels over a separate link. But in my setup, the servers were geographically separate location (in two different data centres) and hence I had to send the heartbeat over standard ethernet link. But this does not make any difference to the working of the servers.

    Heartbeat can be configured for active -standby mode or active-active mode. Active-Standby mode – One host remains active for all the HA services (known as primary host) and the other remains standby. Active-Active mode – Service-1 is primary at one node and service-2 primary at second node, so both nodes are active at the same time but offering different services. In case any one of these nodes fails, heartbeat transfer the services to the other host.

    /etc/hosts file

    In a highly available environment all nodes should be able to see each other irrespective of whether the DNS server is available or not. The /etc/hosts file is typically used in this case. Add the following two lines in the /etc/hosts file in both the hosts.

    192.168.1.1 webhst01.unixclinic.net webhst01
    192.168.1.2 webhst02.unixclinic.net webhst02

    You should be able to ping both servers i.e. both servers should be able to see each other.

    /etc/ha.d/ha.cf file

    This is the heartbeat configuration file and has to be configured identically on all the nodes of the set-up. Its quite possible that you do not want to exceed more than two nodes in the highly available set-up. If you are sure about that then there is not need to use multicast for heartbeat and unicast can be used. If unicast is used then the only difference between this file in the two nodes is the IP address of the host to unicast to.

    # File          - ha.cf
    # Purpose       - Heartbeat configuration file
    #       ATTENTION: As the configuration file is read line by line,
    #               THE ORDER OF DIRECTIVE MATTERS!
    # Author        - Ajitabh Pandey
    # History       -
    #       ver 0.1 -  Created the file on 31st Oct 2006 - AP
    #
    debugfile /var/log/ha-debug # Debug messages are logged here
    logfile /var/log/ha-log     # all heart-beat log messages are stored here
    logfacility     local0      # This is the syslog log facility
    keepalive 2                 # no of secs between two heartbeats
    deadtime 30                 # no of secs after which a host is considered dead if not responding
    warntime 10                 # no of secs after which late heartbeat warning will be issued
    initdead 120                # After starting up heartbeat no of secs to wait for other
                                # host to respond to heartbeat before considering it dead
    udpport 695                 # This is the UDP port for the bcast/ucast communication
    bcast   bond0               # this is the interface to broadcast
    auto_failback on            # resources are automatically failback to its primary node
    node webhst01               # first node in the setup
    node webhst02               # second node in the setup

    /etc/ha.d/haresources

    This file contains a list of all resources being managed by heartbeat and their primary nodes.

    I will discuss Active-standby in this post:

    Here webhst01 will host the IP address 192.168.1.5 and the httpd and hence any services under this IP address will also be hosted on this. In case this host fails this IP address will be taken over by webhst02.

    webhst01.bds.tv 192.168.1.3 httpd

    /etc/ha.d/authkeys

    This file must be owned, readable and writeable by root only, otherwise heartbeat will refuse to start. Also this file must be same on all the nodes.

    auth 1
    1 crc

    Configuring Apache

    httpd.conf

    Depending on distribution being used, this file can be present at different locations. Red Hat, Fedora and CentOS will have this file as /etc/httpd/conf/httpd.conf and Debian and derivatives will have this as /etc/apache2/apache2.conf.

    We will make apache listen only on the service IP address.

    Listen 192.168.1.3:80

    I normally use name based virtual hosts, even if there is a single website to be hosted. So I will create a virtual host

    <VirtualHost NameVirtualHost *:80>
        ServerName   webhst.unixclinic.net
        ServerAlias  webhst
        ServerAdmin  webmaster@unixclinic.net
        DocumentRoot /var/www/webhst.unixclinic.net
    </VirtualHost>
    
    Now since this IP address can be taken over by any machine in the cluster, we have to make sure that apache webserver does not start up automatically on this system.
    
    On Red Hat and derivatives its easy:
    
    chkconfig httpd remove

    On Debian and derivatives:

    update-rc.d -f apache2 remove && update-rc.d apache2 stop 45 S .

    Start heartbeat and do fail-over testing

    On Red Hat and derivatives

    service heartbeat start

    On Debian and derivatives

    invoke-rc.d heartbeat start

    The activities can be seen in /var/log/ha-log file on both the nodes. Fail-over testing can be done as below:

    1. Shutdown primary node, while keeping the secondary running. Secondary should take over the services when primary goes down.
    2. Bring primary node up while the secondary is running the services, the services should automatically be fallback to primary.
  • Configuring ALSA On Debian Sarge

    I needed to configure ALSA on Sarge because I wanted to use Ekiga Softphone and although it supports OSS but the support is not good. It was fairly straight forward process to do that:

    ajitabhp@fimbles:~$ sudo apt-get install libesd-alsa0 \ 
    gstreamer0.8-alsa esound-clients alsa-base alsa-oss
    ajitabhp@fimbles:~$ sudo alsaconf

    In the alsaconf screens I answered all the defaults. And once I was done, under the menu item

    Applications→Desktop Preferences→Advanced→Multimedia Systems Selector

    I changed the default sink and default source to ALSA and Pipeline to alsasink and alsasrc respectively.

  • Backporting Ekiga Softphone

    Since I use apt-pinning it was quite easy for me to install Ekiga from the backports. The first thing which I needed to do was to configure ALSA on sarge.

    Next I just installed Ekiga as:

    ajitabhp@fimbles:~$ sudo apt-get install ekiga
    ajitabhp@fimbles:~$ sudo apt-get install libpt-plugins-alsa

    Next when I ran Ekiga I got an error saying “No usable audio plugin detected”. This was really annoying specially as I have all the required dependencies. Googling around helped me here and I found that the libpt-plugins-alsa needs to be installed from the backports repository and according to my pinning preferences it was installed from the sarge repository. So I had to do:

    ajitabhp@fimbles:~$ sudo apt-get -t sarge-backports install \
    libpt-plugins-alsa
    ajitabhp@fimbles:~$ sudo apt-get -t sarge-backports install \
    libpt-plugins-v4l2

    This uninstalled the installed libpt-plugins-alsa and install it from the sarge-backports repository.

  • Filesystem in User Space

    Setting up sshfs

    In order to setup sshfs on a debian system, I needed to install the sshfs packages:

    sudo apt-get install sshfs fuse-source module-assistant kernel-headers-2.6
    sudo module-assistant build fuse
    sudo module-assistant install fuse

    While building the fuse module I was asked whether I need a seperate group to be able to use the fusermount command and whether I want this group to be removed when the package is removed and so on. I answered all the defaults. Finally I put myself in the group which I created while building the fuse module.

    That’s it, then logout and log back in so that the group permissions can take effect. Or use the newgrp command.

    To mount the remote filesystem I first created a main directory to hold all my remote mount-points.

    mkdir remote_dirs
    cd remote_dirs
    mkdir server_1 server_2
    sshfs user01@server_1:. server_1/
    sshfs user01@server_2:. server_2/

    If ssh keys are already setup for a password less login then you wont be asked a password otherwise a password prompt will be displayed where you need to enter the remote servers password.

  • Apt Pinning

    I normally stick with Debian Stable on my laptop. But atleast there was one package which I needed out of testing or unstable, git. So I thought of using the Debian backports repository. I followed the instructions to use the backports repository and came through this very good APT Pinning document. This is how I installed git on my laptop.

    I added the following line to my /etc/apt/source.list file

    # Debian backports
    deb http://www.backports.org/debian/ sarge-backports main contrib non-free

    and the following to my /etc/apt/preferences file. I needed to create this file as I was not using multiple repositories before, so I had to make all the entries. However, only the middle entry which pins the priority of the sarge-backports repository is required. If most of the time stable is preferred then the priority of stable has to be higher than that of sarge-backports. The last pinning which specifies the priority of -10 to other Debian releases is just a proactive measure to make sure that if I add a new Debian repository to the /etc/apt/sources.list file then I need to specify a pinning preference explicitly in this file, else it will have the priority of -10 which is lowest or no priority at all.

    # Debian stable has a higher priority than the
    # backports repository
    Package: *
    Pin: release o=Debian,a=stable
    Pin-Priority: 900
    Package: *
    Pin: release a=sarge-backports
    Pin-Priority: 200
    Package: *
    Pin: release o=Debian
    Pin-Priority: -10