Showing posts with label Load Balancing. Show all posts
Showing posts with label Load Balancing. Show all posts

Sunday, 19 August 2012

Installing and using Pen Load balancing software in RHEL/CentOS 6.x

Last week I was asked to provide alternatives to NLB as we seem to be having problems getting delivery of a couple of switches for our test environment, or something like that. At any rate, NLB does not work too well with ESXi in our environment for various reasons, so I remembered about PEN, as I had used in a development environment ages ago.

You can compile from source, if you want to, but there is an already compiled rpm, which can be downloaded from here (This is the EPEL repository for CentOS 5).

Installing it's a simple case of using yum:
yum install -y pen
At this point you can start load balancing with pen like this:

 /usr/bin/pen -l pen8080.log 8080 10.168.20.82:8080 10.168.20.83:8080

This will distribute traffic arriving at this server on port 8080 to port 8080 on .82 and .83 with sticky sessions. If you want round robin stick an -r in, like this:

/usr/bin/pen -l pen8080.log -r 8080 10.168.20.82:8080 10.168.20.83:8080

The only downside of using pen like this is that if the box goes down for any reason so does Pen, which means that we need a start up script. I named the file /etc/init.d/penlb8080. The file name should match the servicename variable in the script:
#!/bin/bash
# Pen Starting Script
# chkconfig: 345 93 92
#Source function library
. /etc/init.d/functions

pen="/usr/bin/pen"
lockfile="/var/lock/subsys/pen"
servicename="penlb8080"
RETURNVALUE=0

PIDFILE=/var/run/pen.pid-8080
LOGFILE=/var/log/pen8080.log
CONTROLPORT=18080
LISTENPORT=8080
SERVERS=2
SERVER1=10.168.20.82:80
SERVER2=10.168.20.83:80

start() {
echo -n $"Starting $servicename: "
daemon $pen -S $SERVERS -p $PIDFILE -l $LOGFILE -C $CONTROLPORT $LISTENPORT $SERVER1 $SERVER2
RETURNVALUE=$?
echo
[ $RETURNVALUE = 0 ] && touch $lockfile
return $RETURNVALUE
}
stop() {
echo -n $"Stopping $servicename: "
kill -9 `cat $PIDFILE`
rm $PIDFILE
RETURNVALUE=$?
echo
[ $RETURNVALUE = 0 ] && rm -f $lockfile
return $RETURNVALUE
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
status)
status $pen
;;
*)
echo "Usage: $servicename {start|stop|restart|status}"
exit 1
esac

exit $?
Make the script executable:
chmod +x /etc/init.d/penlb8080
Add to list of services controlled by chkconfig:
chkconfig --add penlb8080
Start this pen load balancer instance with:
service penlb8080 start
If you also wanted to run a second pen instance you could use the same script as above but with certain modifications. Say you wanted to run a second load balancer on port 80 as well, all you need to change are the following values, as well as the script name (penlb80):

servicename="penlb80"
PIDFILE=/var/run/pen.pid-80
LOGFILE=/var/log/pen80.log
CONTROLPORT=10080
LISTENPORT=80

Friday, 29 July 2011

Load Balancing in MS Dynamics CRM

In its infinite wisdom Microsoft decided to make my life harder by making it MS Dynamics CRM not work out of the box with a load balancer and I'm not talking about Microsoft software based network load balancing although it would apply too, if memory servers right, but a proper hardware based solution, which if again, memory serves me right, it's a Cisco 11506, but that is by the by.

In a normal load balancing situation, you would want a DNS entry for your load balancer's VIP and you would direct your clients to that VIP, so far so good. The problem is that there is a few pesky rows in the DeploymentProperties table in the MSCRM_CONFIG database
ADSdkRootDomain
ADWebApplicationRootDomain
The NvarCharColumn for these rows is, by default, set to the first server in a deployment, which is all well and good if you have a single server in your deployment, but the minute you add another server you are creating a single point of failure, because if the first server goes down, down goes your application. In actual fact it won't come down until the app pool gets recycled if I remember correctly. It will also refuse to start if the first server is down.

In the three+ years since we encountered this problem, it seems that this is all now clearly documented, I should've done a search in google before I wrote all this, oh well.

Note that some people have reported that this setting also needs changing, I guess it depends on whether or not you are using asynchronous plugins, which we don't.
AsyncSdkRootDomain