Mar 9 2010

More Raid tidbits – Monitoring all raid events and changing default email template

A geek really knows the importance of his or her data and backups that just avoids pulling the hair off! When one of my hard drives on a server just died after having a well served 6000+ hours of life span, I found myself really lucky as other array component of RAID1 came to the rescue. Reason was a perhaps a short circuit which could have cost me the biggest loss of my data ever, I had in my life, so a blazing smile was well deserved. Electric power is one of the infinite things that doesn’t work here like it always (oh, its a long story – I should tell some of it sometime later)!

I got an email from mdmonitor telling me about DegradedArray event. So, when I was rebuilding the array, I noticed I got no alerts about rebuild process or  array status updates which I really wanted to investigate. Till that time, I wasn’t event knowing that ‘mdadm –monitor’ only sends you the critical updates. So, I pulled up man pages and saw these are critical events:

  • DeviceDisappeared
  • Fail
  • FailSpare
  • DegradedArray

Rest of the events are not reported at all! Also, that RHEL5’s mdadm package has pre-compiled template of email that mdadm sends upon occurrence of a critical event which I wanted to change from as well cause it looks pretty immature:

This is an automatically generated mail message from mdadm running on HOSTNAME
A DegradedArray event had been detected on md device /dev/md1.
Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:
bla bla bla

Seriously, it says “faithfully”… wth? Lol. We know that all machines are faithful to a human unless they’re not broken or gay! :D It definitely needed to be changed. Checking /etc/init.d/mdmonitor at least gave an idea that its not something changeable but it uses default template when MAILADDR is specified while it doesn’t when PROGRAM parameter is used in /etc/mdadm.conf by passing on RAID array as arguments to the script which is used, instead.

I did this then.


# mdadm --detail --scan >> /etc/mdadm.conf

# echo "PROGRAM /etc/raidalerter" >> /etc/mdadm.conf
# sed -e '1i\DEVICE partitions' -i  /etc/mdadm.conf
# cat /etc/raidalerter    (create this file with below script)

#!/bin/bash
echo -e "Likely an unfavourable or a bad thing just happened to your RAID. Even if its recovering, it was a bad thing which caused this! \n\n\n" $(cat -A /proc/mdstat | sed 's/\$/\\n/g') | mail -s "$1 on $2 $3 at $HOSTNAME" some-mail-address@example.com

# chmod +x /etc/raidalerter
# service mdmonitor restart

Provided that you’ve an MTA working fine, mails would be delivered upon any of RAID incidents to the maximum verbosity possible. I don’t think that any of the hardware raids does so?!
I then tested it on a small array to make sure that alerts are deliverable.


# mdadm /dev/md0 -f /dev/sdb1 -r /dev/sdb1
mdadm: set /dev/sdb1 faulty in /dev/md0
mdadm: hot removed /dev/sdb1
# mdadm /dev/md0 -a /dev/sdb1
mdadm: re-added /dev/sdb1

Preview:

Subject: RebuildFinished on /dev/md0 at ToughGuy
Likely an unfavorable or a bad thing just happened to your RAID. Even if its recovering, it was a bad thing which caused this! Personalities :

[raid1]
md1 : active
raid1 sdb3[1] sda3[0]
724555520 blocks [2/2] [UU]
md0 : active
raid1 sdb1[1] sda1[0]
4008064 blocks [2/2] [UU]
unused devices: <none>


Jan 6 2010

HA LB Cluster on CentOS5 – Without actual heartbeat :P

Last month I wrote a howto for highly available load balanced Piranha cluster using Red Hat’s cluster suite. Until then it was quite not obvious why one should use the Debian styled network load balanced cluster in the production environment when actual “heartbeat” package and service creates a lot of havoc on Red Hat machines. But my reckoning of doing classic things more manually kept me interrogative and I found the flexible way of doing load balanced clustering without needing the actual heartbeat service. Reasons why I’m so much against of having it are numerous:
- Running heartbeat snatches the independence of managing virtual IP addresses on load balancer by hand.
- Thus restricting expansion of the pools!
- Ldirector’s daemon must be managed by heartbeat when its running.
- Waste of resources in utilization; such with a sheer restart of heartbeat service and it just sits on waiting and waiting,…
- And above all, I don’t need a “second” load balancer for a failover. All that glitters is one load balancer running ldirectord in a simple environment and as for the job, it does most of heartbeat’s when acting as a divider and a monitor for distributing requests between web servers.

Environment

Requirements: At least three systems, each with a minimum of one IP (CentOS in my case). Packages ‘heartbeat’, ‘heartbeat-ldirector’ for load balancing and ‘ipvsadm’ for Linux IP Virtual Server. I know you’re thinking that why the ‘heartbeat’ when actually we’re not going to run it. In fact, we’re not going to run it; its just for a dependency resolution, rather a service startup requirement – I should say (/etc/ha.d/shellfuncs is the file needed)! And I swear we won’t run it ;) ! So these are the packages which shape into a project Ultramonkey when combined and it describes the different topologies of a functional HA LB cluster but that’s not our concern, anyway :D (perhaps yours if you think you’ve a bit of free time)

Virtual IP: 12.12.12.60
Load Balancer: 12.12.12.61 aka VM1.
Cluster Nodes/Real Servers:
Web Server1: 12.12.12.62 aka VM2
Web Server2: 12.12.12.63 aka VM3.

And we’ll be using LVS-DR (direct routing) approach for clustering; its most widely used and has lesser downsides.
Lets start by configuring the web servers first.

Cluster Nodes  Configurations

1. On both web servers VM2 and VM3, apache should be running having a common serving file (for purpose of get checked by ldirectord).

# yum install httpd -y
# echo foo > /var/www/html/test.html
# service httpd start
# chkconfig httpd on

And to distinguish both of the web servers during test loading, create at least a one unique file on each of web servers.

[root@VM2 ~]# echo "This is VM2" > /var/www/html/index.html
[root@VM3 ~]# echo "This is VM3" > /var/www/html/index.html

2. Virtual IP needs to be terminated on both web servers so we’ll create a second network interface on each of it. Because eventually all three NICs on all three servers would have to have the same VIP so this would cause a problem with ARP as it resolves MACs against IPs. There are different solutions to this problem. Some may refer to use iptables or arptables_jf. Many would recommend changing default gateway route or hiding the network interface (by the way don’t use iptables or change default gateway for this; Red Hat discourages both of these methods as they cause a lot of overhead). But the most flexible approach I’ve found is:

a. create a loopback interface so it doesn’t communicate with your network gateway/router directly.
b. instruct Linux kernel to announce ARP requests with preference to be taken from local address when matching for communication instead preference from the destination address.
c. instruct Linux kernel to send ARP responses only to the requests originating from same sender address to same local addresses’ subnet. Details here, if you’re really curious about it.

# vi /etc/sysconfig/network-scripts/ifcfg-lo:0
DEVICE=lo:0
IPADDR=12.12.12.60
NETMASK=255.255.255.255
ONBOOT=yes
NAME=loopback
#
# vi /etc/sysctl.conf
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.eth0.arp_announce = 2
# sysctl -p
# ifup lo:0

Load Balancer Configuration

We’ll be going through:

a. installing required packages
b. enabling IP forwarding,

# yum install heartbeat heartbeat-ldirector ipvsadm -y
# chkconfig --add ldirectord
# chkconfig --del heartbeat
# sed -i 's/net.ipv4.ip_forward = 1/net.ipv4.ip_forward = 0' /etc/sysctl.conf

# sysctl -p

c. configure secondary eth0 for VIP as its going to be exposed to outside world or your local gateway and

# vi /etc/sysconfig/network-scripts/ifcfg-eth0:0
DEVICE=eth0:0
BOOTPROTO=none
ONBOOT=yes
HWADDR=3a:5d:71:ad:67:47
NETMASK=255.255.255.0
IPADDR=12.12.12.60
GATEWAY=12.12.12.1
TYPE=Ethernet

d. then creating ldirector.cf, the configuration file of our load balancer, respectively!!

# vi /etc/ha.d/ldirectord.cf
checktimeout=10
checkinterval=2
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=no
virtual=12.12.12.60:80
 real=12.12.12.62:80 gate
 real= 12.12.12.63:80 gate
 service=http
 request="test.html"
 receive="foo"
 scheduler=wrr
 protocol=tcp
 checktype=negotiate

# service ldirectord start

Option ‘quiescent’ just removes the real server from ipvs table whom ldirectord doesn’t recieve any response from, when querying for test.html within ten seconds, marking that real server as dead; until its available again. Note that the “gate” switch in ‘real’ server’s parameter value which testifies the usage of LVS Direct Routing method. The rest of the two methods are masq and ipip the details of which along with the other options available, particularly the scheduler parameters, for this configuration file can be found in ‘man ldirectord’.

Testing

Use ‘ipvsadm’ to list down current statistics of ldirectord. Make sure that both real servers IPs are listed there and have non-zero value in weight (since we’ve this default setup, it should be 1). If not, then try checking the log file, tcpdump on ldirector and apache logs on real servers.
If everything works good, you’ll see changing content when browsing to http://12.12.12.60/ multiple times (from another system outside these cluster nodes). Then stop httpd on one web server, browse to the URL again and all requests should now be served from the other web server.

[root@VM1 ~]# ipvsadm -l
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  12.12.12.60:http wrr
-> 12.12.12.63:http             Route   1      0          0
-> 12.12.12.62:http             Route   1      0          0

For a more meaningful testing

$ for i in $(seq 6); do curl http://12.12.12.60/index.html; done
 This is VM3
 This is VM2
 This is VM3
 This is VM2
 This is VM3
 This is VM2

I’ll be posting a couple of optimizations techniques soon when I’ll be getting some more free time. Stay tuned and take care :D

checktimeout=10
checkinterval=2
autoreload=no
logfile=”/var/log/ldirectord.log”
quiescent=yes
virtual=12.12.12.60:80
real=12.12.12.62:80 gate
real= 12.12.12.63:80 gate
service=http
request=”index.html”
receive=”hi”
scheduler=wlc
protocol=tcp
checktype=negotiate

Dec 20 2009

ASCII Art in Linux

I’m fond of two ascii art tools in Linux.

- linux_logo
- figlet

Both of these are available in RPMForge/Dag’s repository. Second one, figlet draws the ascii art for any text that is input. It has a lot of font options available (see man for figlet and figlist).


Dec 19 2009

Installing HPLIP 3.9.10 on CentOS 5.4 for newer printers (HP LaserJet M1120 MFP)

CentOS 5’s base repository has an older version of HPLIP, something about ‘1.6.7′ or so which of course is not adequate to get newer HP printers specially the LaserJet series, to get to work. Now the natural way to have this installed, you may think is to compile it from source – if you’re thinking that then no, that won’t help out! Even after fulfilling all of the required dependencies. I got about almost 14 errors when running hp-check utility after compiling, got’em reduced to 10 but no far lesser than that if you know what I mean.

error: NOT FOUND! This is a REQUIRED/RUNTIME ONLY dependency. Please make sure that this dependency is installed before installing or running HPLIP.
error: NOT FOUND! This is a REQUIRED/RUNTIME ONLY dependency. Please make sure that this dependency is installed before installing or running HPLIP.
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.
error: NOT FOUND! This is a REQUIRED/COMPILE TIME ONLY dependency. Please make sure that this dependency is installed before installing or running HPLIP.
error: Could not access file: No such file or directory
error: 10 errors and/or warnings.
-----------
| SUMMARY |
-----------
Please refer to the installation instructions at:

http://hplip.sourceforge.net/install/index.html

Pretty insane though, many of these dependencies were already installed. I would assume that this would be the reason why hplip is not under active development for CentOS and why its not current under CentOS as I saw quite a few HP’s devs and techs saying a big “no” to this community based distribution when people complained on their Launchpad about these compilation errors. Plus, the relative hplip installation issues I found on CentOS’ forum.

After being in disappointed (oops wth) situation, I tried running the RHEL5’s rpm (can be downloaded from hplip’s site) on it after removing the source installed version, but it too gave the dependency errors which I hoped I would resolve and I did later on.

Installing……

# rpm -ivh /Raid/hplip-3.9.10_rhel-5.0.i386.rpm
Preparing...                ########################################### [100%]
 file /usr/bin/hpijs from install of hplipfull-3.9.10-0.i386 conflicts with file from package hpijs-1.6.7-4.1.el5.4.i386
 file /usr/lib/libhpip.so.0.0.1 from install of hplipfull-3.9.10-0.i386 conflicts with file from package hpijs-1.6.7-4.1.el5.4.i386
 file /usr/lib/sane/libsane-hpaio.so.1.0.0 from install of hplipfull-3.9.10-0.i386 conflicts with file from package libsane-hpaio-1.6.7-4.1.el5.4.i386

So, I decided to remove problematic hpijs


 Package                 Arch       Version          Repository        Size

Removing:
 hpijs                   i386       1:1.6.7-4.1.el5.4  installed         588 k
Removing for dependencies:
 libsane-hpaio           i386       1.6.7-4.1.el5.4  installed          94 k
 sane-backends           i386       1.0.18-5.el5     installed         3.1 M
 sane-backends-devel     i386       1.0.18-5.el5     installed          27 k
 sane-backends-libs      i386       1.0.18-5.el5     installed         5.2 M
 xsane                   i386       0.991-5.el5      installed         4.5 M

Transaction Summary
Install      0 Package(s)
Update       0 Package(s)
Remove       6 Package(s)

But realised soon that it also removed libsane sub-dependency as well.

# rpm -ivh /Raid/hplip-3.9.10_rhel-5.0.i386.rpm
error: Failed dependencies:
 libsane.so.1 is needed by hplipfull-3.9.10-0.i386
 

Because installing sane would also install hpijs and other conflicting stuff as well so the solution here was to remove problematic packages without ‘removing’ any dependencies needed.

[root@ToughGuy ~]# rpm -ivh /Raid/hplip-3.9.10_rhel-5.0.i386.rpm
Preparing...                ########################################### [100%]
 file /usr/bin/hpijs from install of hplipfull-3.9.10-0.i386 conflicts with file from package hpijs-1.6.7-4.1.el5.4.i386
 file /usr/lib/libhpip.so.0.0.1 from install of hplipfull-3.9.10-0.i386 conflicts with file from package hpijs-1.6.7-4.1.el5.4.i386
 file /usr/lib/sane/libsane-hpaio.so.1.0.0 from install of hplipfull-3.9.10-0.i386 conflicts with file from package libsane-hpaio-1.6.7-4.1.el5.4.i386
#
# rpm -ev --nodeps libsane-hpaio
# rpm -ivh /Raid/hplip-3.9.10_rhel-5.0.i386.rpm
Preparing...                ########################################### [100%]
 file /usr/bin/hpijs from install of hplipfull-3.9.10-0.i386 conflicts with file from package hpijs-1.6.7-4.1.el5.4.i386
 file /usr/lib/libhpip.so.0.0.1 from install of hplipfull-3.9.10-0.i386 conflicts with file from package hpijs-1.6.7-4.1.el5.4.i386
#
# rpm -ev --nodeps hpijs
#
# rpm -ivh /Raid/hplip-3.9.10_rhel-5.0.i386.rpm
Preparing...                ########################################### [100%]
 1:hplipfull              ########################################### [100%]
#

Concluding the overall steps:

# yum install cups cups-devel ghostscript* PyQt xsane -y
# Download and install hplip-3.9.10_rhel-5.0.i386.rpm from http://hplipopensource.com/hplip-web/install_wizard/index.html choosing RHEL5.
# rpm -ev --nodeps libsane-hpaio
# rpm -ev --nodeps hpijs
# rpm -ivh hplip-3.9.10_rhel-5.0.i386.rpm
# Reboot the system if you're lucky enough, you'll see no errors
# reboot
# system-config-printer

And configure the printer now as usual. Just out of curiosity, this was my XenServer where I installed it (yea I know it would sound funny) and I got scanner (LaserJet M1120 is dual scanner and printer) working fine as well with xsane. Check it out :D

Scan Test HP LaserJet M1120 MFP

NOTE: If this post helped you out or provided you with ways of troubleshooting, feel free to say a little thanks ;)


Dec 14 2009

Mail from root, root and root! :>

I’m sometimes pretty sick of getting emails from ‘root’ reporting crons, updates, errors and rest of things I would usually use daily in any Linux machine. My eyes just get sore when I see email from root in all of my email clients specially Gmail. Perhaps that’s because I’m fed up of seeing root everywhere and that’s why I’ve an alias for root to forward all these rootish emails to one of my email addresses. But that’s just not enough as I actually want to see a humane human name as a sender just instead of root :>

To add to it, this just becomes more anguish when common, rather I would say major, Linux applications suck in changing the default sender address off from ‘root’ (although some apps like ‘exim -f’ and mutt having SET FROM defined in ~/.muttrc allow you to change sending address while emailing from command line but this isn’t what I needed). And so called mighty default MTA, sendmail just brings more panic to it when trying to change it during an in-mail transport (btw, I already dislike sendmail mainly cause of its sluggishness during startup and restart)! As I really had to do something about it and I already knew that Exim’s address rewriting can be helpful here so after installing it and changing default MTA with ‘alternative –config mta’ I added a quick rewrite at transport.

$ grep -A 5 remote_smtp /etc/exim/exim.conf | tail -5

driver = smtp
headers_rewrite = root@*  some-email-address@example.com fsr

This worked but didn’t change the FROM field’s name as expected. I tried combinations of different settings including the rewrite tag ‘F’ but the FROM envelop address kept showing the original sender root. I was searching till I stumbled upon http://www.exim.org/exim-html-2.00/doc/html/spec_32.html#SEC671 where it states the FULL ‘from’ envelop address is changed with ‘w’ tag and allows to have a new sender name (RFC 822) to be configured. So I added.

$ grep -A 5 remote_smtp /etc/exim/exim.conf | tail -5

driver = smtp
# Adding to rewrite the stupid root@ FROM field which I hate
headers_rewrite = root@* "Abbas <some-email-address@example.com>" fsrw
return_path = some-email-address@example.com

And boo you naughty (!) root  ;)

screenshot3


Dec 14 2009

Redundant customized XenServer

I just finished setting my home XenServer making it fully redundant, mirrored and backup’ed. Thought, I would share what’s on it :)

- Raid1 setup on boot, grub as well as VM storage repository. If one of the hard goes down, it’ll boot from other one.
- Samba installed to have a share setup in a raid array of 700GB
- Raild alerts are configured to email me whenever there’s any issue
- Smartmontools are running to make sure that hard disks are healthy and have emails alerts configured as well.
- Auto on-the-fly backup of all virtual machines without shutting them off, every night at 1am keeping the two most recent backups of VMs all the time.


Dec 12 2009

Enabling Guest share in Samba (Windows accessible)

One of the easiest way to do so is by changing ’security=user’ to ’security=share’ in global configurations of Samba in /etc/samba/smb.conf. But this raises security concern in case if many shares could have restricted access. Samba maps Windows ‘guest’ account to Linux’s ‘nobody’ account so this is how I enabled it.

Added nobody’s account but seemed it was already there!

[root@ToughGuy ~]# useradd -s /sbin/nologin nobody
useradd: user nobody exists
[root@ToughGuy ~]# grep nobody /etc/passwd
nobody:*:99:99:Nobody:/:/sbin/nologin
nfsnobody:!!:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin

Assured that sweet Windows’ “guests” have access to my share ;)

[root@ToughGuy ~]# chown -R root:nobody /Raid/
[root@ToughGuy ~]# chmod -R 775 /Raid/

Mapped guest user to login without a need of having a password prompt in smb.conf’s global settings!

[root@ToughGuy ~]# grep 'map to guest' /etc/samba/smb.conf
	map to guest = Bad Password

Btw, here’s my share:

[root@ToughGuy ~]# grep -A 5 Raid /etc/samba/smb.conf
	path=/Raid
	browseable=yes
	writeable=yes
	guest ok=yes
	public=yes

Restarted the service and look :D

smb_guest_ok


Nov 29 2009

Piranha | High Availability Server in Red Hat

Clustering is by no means having any similarity usually. I read somewhere that if you’ll ask ten persons the definition of clustering, you’re likely to get at least nine unique answers – which is what I’ve found true! There are many different kinds of clustering and a lot of ways to do it specially when it comes to Linux. As for as what I’ve learnt in Windows, there are two main categories of purposes where clustering is usually used for. i.e. Static content and non-static content. Network load balancing (NLB) is what used to fulfill the first one and clustering within any shared media for the later. Red Hat does it using the same LVS kernel modules, the one used in Debian but with different set of tools bundled in Piranha rpm (if you’ll Google it out you’ll only find how its done in Debian and that’s the reason why I am writing this tutorial) where its done with heartbeat and ldirectord both of which are available on Red Hat distributions as well but I’ve not been able to fully deploy the same solution on CentOS with LVS, heartbeat and ldirector no more further to a stable point with a mechanism of direct routing of LVS and without no errors. So I went ahead and tried configuring Piranha with an LVS-DR approach where load balanced requests are sent back to end users directly from real (web) servers.

The beauty of Piranha is that it comes with a web based administration panel to configure load balancer configuration which I prefer to configure my first load balancer and then simply copy over the configuration file under /etc/sysconfig/ha/lvs.cf to any further backup load balancer, though there does exist a few documentation files under /usr/share/doc/piranha-*/docs/ if you would like to check over built in sample configs. In this example we would be having these IPs for the machines.

Load Balancer:   12.12.12.40
Real or Web Servers:
VM1:   12.12.12.41
VM2:   12.12.12.41
Virtual IP (VIP):   12.12.12.50  (this is the IP where a FQDN should point to)

Lets move a head and follow the steps below.

1. Downloading and installing the packages

yum install piranha ipvsadm -y


2. Configuration

touch /etc/sysconfig/ipvsadm
sed -i 's/net.ipv4.ip_forward = 0/net.ipv4.ip_forward = 1/' /etc/sysctl.conf
sysctl -p
piranha-passwd
service piranha-gui start

You’ll then browse to http://12.12.12.40:3636/ or http://localhost:3636/ and will be presented a login screen.

Screenshot-Piranha (WEB based Cluster configuration) - Mozilla Firefox

Log on in and adjust the settings as below.
A. Configure the main load balancer settings
B. Create a Virtual Server
C. Create two Real Servers within it
D. Leave monitoring segment to its default

Screenshot-Piranha (Global Settings) - Mozilla Firefox

Screenshot-Piranha (Virtual Servers - Editing virtual server) - Mozilla Firefox

Screenshot-Piranha (Virtual servers - Editing virtual server - Editing real server) - Mozilla Firefox

Screenshot-Piranha (Virtual Servers) - Mozilla Firefox

Screenshot-Piranha (Virtual servers - Editing virtual server - Editing real server) - Mozilla Firefox

About VIP’s settings, of course you can customize; like that of scheduling alogrithims etc.

3. Configuration on Real Servers
Since we configured the webservers to cluster with direct routing, there’s need to configure real servers to prevent reverse ARP havoc. On both of real servers, run:

#Make sure that apache is running on both real servers
service httpd restart && chkconfig httpd on

#Install arptables
yum install arptables_jf -y
chkconfig arptables_jf on
arptables -I IN -d 12.1.2.12.50 -j REJECT
arptables -A OUT -d 12.12.12.50 -j mangle --mangle-ip-s <real-server-ip>
service arptables_jf save && service arptables_jf restart

#Add an alias of VIP on both real servers
ip addr add 12.12.12.50 eth0
echo "ip addr add 12.12.12.50 eth0" >> /etc/rc.local

This can be done with iptables as well but Red Hat recommends using arptables as iptables could be aggressive in ARP filtering. About network alias  some people will tell you to create a secondary loopback alias, either way works so it totally depends upon you!

4. Starting the service on load balancer

After configuring from web panel this is how a fully configured LVS config file looks like:


# cat /etc/sysconfig/ha/lvs.cf
serial_no = 34
primary = 12.12.12.40
service = lvs
backup_active = 0
backup = 0.0.0.0
heartbeat = 1
heartbeat_port = 539
keepalive = 3
deadtime = 25
network = direct
debug_level = NONE
virtual HTTP {
 active = 1
 address = 12.12.12.50 eth0:1
 vip_nmask = 255.255.255.0
 port = 80
 send = "GET / HTTP/1.1\r\n\r\n"
 expect = "HTTP"
 use_regex = 0
 load_monitor = /etc/sysconfig/ha/ruptime-piranha
 scheduler = rr
 protocol = tcp
 timeout = 4
 reentry = 4
 quiesce_server = 1
 server VM1 {
 address = 12.12.12.41
 active = 1
 weight = 1
 }
 server VM2 {
 address = 12.12.12.42
 active = 1
 weight = 1
 }
}

Make sure to click on ‘ACCEPT’ and ‘ACTIVATE/DEACTIVATE’ to make the VIP and Real Servers’ status “up” in the configuration panel – this would save the configuration and now its time to restart pulse service which would use the lvs.cf config file, configure the VIP and start nanny, lvsadm daemons.

chkconfig pulse on
service pulse start

After that it’ll take a few seconds to a minute, start up pulse and logs activity which can be seen from /var/log/messages.

5. Time to test out

Add some different content in both web servers’ virtual host document root. Go to http://12.12.12.50 on any other machine in your network and try reloading the page a couple of times. And you’ll see it’ll be loaded from both of web servers depending upon scheduling algorithm. Watch the output of ipvsadm on load balancer, stop apache on one of web servers and all of requests would get start serving from the other web server with a  noticable change on weight in ipvsadm output falling back to zero for a dead apache server.


 # ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
 -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  12.12.12.50:80 rr
 -> 12.12.12.42:80               Route   1      0          0
 -> 12.12.12.41:80               Route   1      0          0

Troubleshooting / Issues:

1. When using weighted scheduling algorithms with nanny’s load monitor, behaviour of load balancer can change than to what is expected.

2. Even load_monitor w/ nanny seems buggy itself as I got a lot of errors like these, after trying a fix found on Piranha’s mailing list which was to use to a customized ruptime in a bash script with rhowd turned on, on all of cluster nodes. The only workaround as for now is to disable load_monitor.

"Nov 29 14:57:03 Methane nanny[7719]: The following exited abnormally:
Nov 29 14:57:03 Methane nanny[7719]: failed to read remote load" 

3. And if you get an error like this one; that means you’re having SELinux on. Use ’sestatus’ to check and /etc/selinux/config to disable it or you better should how to change security context if you don’t want to!

# service piranha-gui start

Starting piranha-gui: (13)Permission denied: make_sock: could not bind to address [::]:3636

no listening sockets available, shutting down

Unable to open logs

[FAILED]