Pages

Friday, November 25, 2011

HAProxy for Exchange 2010–Part 2 (Redundancy)

After I wrote the blog for using HAProxy (http://haproxy.1wt.eu/) for Exchange 2010 in order to reduce a few thousand dollars from your budget of purchasing a load balancer. Now though that blog would have helped people in doing a Proof of Concept, there is some thing that is missing from it. REDUNDANCY!!!
Yes, the whole idea of load balancing is to remove the single point of failure, but what if the Load balancer is the new single point of failure ? yes, that’s why we need two of them
For the people who are reading this first, please read the http://3-4-5-6.blogspot.com/2011/03/ha-proxy-for-exchange-2010-deployment.html
Now, once you have read through it, you should know that this is a working load balancer example and Steve has also created a VMWare solution for it.
Now, this is brilliant if the load balancer stays up, but we have to plan for the worse. Though, I haven’t seen the HAProxy crash “Knock on wood”, we still need a redundant solution.
This blog will explain only the differences as to what you need to do to get a redundant solution. In terms of implementation, you will need to do this before you follow the HA Proxy deployment guide (link mentioned earlier). Just for the sake of completeness, I will document the complete solution here.
Design
image

The above shows the diagram shows the single arm configuration of the load balancer.  The Single arm configuration concept is explained here. In the blog post, I have used f5 LTM as an example, but it is the same concept in all the load balancers.
So, we can start now
We will need 2 components for this to work, again, I am going to use Ubuntu. Once you have installed Ubuntu, we are going to have to install the following components
  • keepalived
  • haproxy
After installing these components, we will configure the HA Proxy and the Exchange server.
Before Starting:
Please note, we will be needing the following IP addresses, I have mentioned the IP’s I am going to use for this example in brackets
1. Management IP of Load Balancer 1  (10.10.10.9/24)
2. Management IP of Load Balancer 2  (10.10.10.10/24)
3. Floating IP  (10.10.10.11/24)
4. IP address of CAS 1 : (10.10.10.20/24)
5. IP address of CAS 2 : (10.10.10.21/24)
Once the installation is done, set the management IP to the load balancer, here we will configure the Primary system
On Active System
Set up IP address on eth0

Edit the file /etc/network/interfaces using vi or your preferred editor 

Add the following

auto eth0
iface eth0 inet static
           address 10.10.10.9
           netmask 255.255.255.0
           network 10.10.10.0
           broadcast 10.10.10.255
           gateway 10.10.10.1

This will set the management IP on the Active box, lets continue

Backup box

Set the management IP address of the backup box

Step 1: Install KeepAlived
apt-get install keepalived

Once you execute this command, now the Keep Alive daemon is installed on the Ubuntu system

Step 2: Install HAProxy
apt-get install haproxy

This command will install the HA Proxy on the box.

Step 3: Allow HAProxy to use non local IP

In order to do this, edit the file “/etc/sysctl.conf” and ensure this is added
net.ipv4.ip_nonlocal_bind=1

As you see, this will mention the HAProxy to allow to bind to an IP which may not be assigned to it. after you have added it

run the command

sysctl -p



The idea is there will be a floating IP and that IP will be assigned to the active box and if the active box dies or the HA proxy dies, the standby will take over.

Step 4: Configure the KeepAliveD

Configuring the keep alive d is very simple, you will need the floating IP. As an option you can send yourself an e-mail if the primary fails so that you can preemptively know.

Edit the file “/etc/keepalived/keepalived.conf”
global_defs {
    notification_email {
        yourusername@example.com
    }
    notification_email_from keepalived@loadbalancer01.example.com
    smtp_server 192.168.1.200
    smtp_connect_timeout 30
}
 
vrrp_script chk_haproxy { 
    script "killall -0 haproxy" # this will check if the haproxy is up
    interval 5 # check every 5 seconds
    weight 2 # add 2 points of priority if OK
}
 
vrrp_instance VI_1 {
    interface eth0
    state MASTER # or "BACKUP" on backup
    priority 101 # 101 on master, 100 on backup
    virtual_router_id 51
 
    smtp_alert # Activate SMTP notifications, you can remove this if you dont want alerts
 
    authentication {
        auth_type PASS
        auth_pass somepassword
    }
 
    virtual_ipaddress {
        10.10.10.11
    }

    track_script {
        chk_haproxy
    }
}



This will actually have the 10.10.10.11 as a floating IP and it will be assigned to only to the active box.

The same configuration works on the Backup box , just change the priority to 100 and state to backup

After this just follow the older blog from here, Please follow it from the title “Configuration of Exchange Server”

You don’t need to follow other networking steps mentioned before the title. Once you complete that on both the load balancers, you officially have a redundant pair.

You can now check on netstat –la to check the listening ports, you will see the active box is listening on the floating ip.



Enjoy !!!

4 comments:

  1. Thunder Emperor,

    Thanks for taking time to write Part 2 continuation of HA Proxy for Exchange.

    Again, very clear and concise article. I hope to see more of your great blog entries. I am Windows Admin for 15+ years, learning Linux on my own time for last 3+ years.

    Happy Holidays to You, Your Family and Your Friends.

    Regards,

    Bruce C.

    ReplyDelete
  2. Hey Bruce,

    Not a problem, I am just glad I could be of assistance, Happy holidays and very happy new year 2012

    ReplyDelete
  3. Hi,

    Thanks for the article it helped me workout some problems I was having. My only question is when external users go to OWA and are passing through NAT twice does the affinity still work? e.g. firewall NAt's first to HAproxy then HAproxy NAT again but as all external users come from the same IP as far as HAproxy is concerned will it still know to stick each connection to the same server?

    ReplyDelete
  4. The persistence works no doubt, but the problem is that only one server will be used in that case. Since HAProxy doesnt have a source Hash persistence, this will work, but one server will be more loaded than the others, in this case, you can do 2 nats to two differnt ip addresses for example

    0.0.0.0 - 127.255.255.255 - First source IP
    128.0.0.0 - 255.255.255.255 - Second source IP

    In any event, this is a work around, once the Source hash method of persistance is introduced in Haproxy, you can use this.

    Hope this answers your question

    ReplyDelete