Load Balancing Magento Enterprise with HAProxy – Part Two
- 26 August 2014
- 0 Comments
After looking through the available options, I chose HAProxy. Their documentation was complex, yet easy to read, and they handled SSL traffic exactly the way we wanted. Other load balancers reviewed seemed to either handle the traffic in a confusing way or they required a certificate on every server. HAProxy’s method just made sense at first glance. I also liked the way the configuration file was set up and the apparently rampant number of tutorials on the web on how to set it up, including one written by MyHosting themselves. To top it off, their statistics page built into the program seemed very handy. Sold (for free).
Load balancer decided, I now needed some more servers to play with. Looking at our server situation, I decided that we needed an additional two servers at minimum, so I had the client purchase two additional servers from MyHosting.com with the same specs as the other three. They were ready for use 10 minutes later. Boom! I love VPS. This is going to go so well!
Trouble rears its ugly multi-headed head
As with most things complex, I knew we needed a rock-solid deployment plan next. This was not a fly-by-the-seat-of-your-pants project. This was going to be difficult and complex. So I did what any enterprising young man would do. I took to Google to flesh out the deployment plan by reading through all of those great HAProxy tutorials I had found when trying to decide what load balancer to use.
Ugh, the first problem reared its ugly head: I was unable to find a full-on tutorial! All of the articles, blog posts, tutorials, and forum posts dealt with installing HAProxy, but not configuring it. And it was especially difficult to find anyone that was putting it into a “real” production environment to handle hundreds of thousands or millions of requests a day. Most seemed like they were quickly typed up and then abandoned. Some had hundreds of comments with no real responses.
Giving up wasn’t really an option, so I narrowed my search by searching just for the specific sections of what I needed to do next. Like “install haproxy centos 6” or “configure haproxy centos 6” and so on. By Friday evening, I had pieced together what seemed to be a workable set of instructions for installing and configuring HAProxy. I still had lots of questions to answer as I went along, though.
Because of the struggle I went through to get the info gathered up, I kept detailed notes so that I could come back and write it up in blog form later.
I’m going to be as detailed as I can in this article, and I hope it will help you get all the way to launch with a single walkthrough.
Still optimistic on Friday evening, I turned to the actual writing of the deployment plan.
Building the Deployment Plan
When setting up our document, I split it into three areas: Goals, Assets, and Deployment Steps
Section 1: Goals
We had two main goals. They were:
1) To not have any downtime when switching from the old server to the new load balancer deployment.
2) To distribute traffic across multiple servers to ensure fast page load and lower individual server bandwidth.
We had some sub-goals that I was to try and make happen if I could. Namely:
1) Don’t change the IP address when the traffic goes between servers.
2) Keep all traffic in https at all times.
3) Figure out a way that the client only has to upload a single image that then gets distributed to all web servers instead of requiring the admin to upload it to every server every time he/she needs to add a product image or file to the site.
You might have different goals, and this is where you will put them if so.
Section 2: Assets
I decided that the servers would fall into the following roles:
- Database Server
- Load Balancer Server (this needs to be whatever is currently your live production server)
- Web Server 1 (I made this one be our old dev server)
- Web Server 2
- Web Server 3 (with Dev Server)
So in this section, I listed the IP address, the name that we would use to describe the server (Web Server 1, Database Server, Web Server 2, etc.), the QuickFTP info, and also the root passwords of each server so that we could view them in one window while typing it into Putty (we use Putty for SSH) in the other window. It looked something like this:
Server 1 – Database Server
- Dedicated IP Address: 18.104.22.168
- Quick FTP: ftpRootUser:TheRootPassword@22.214.171.124:22 (Note: the bit before the colon will open up the site if you throw it into the Host field of any major FTP program and click connect. We use Filezilla for FTP. The :22 at the end is to make sure that SFTP is used).
- Root Password: TheRootPassword
Server 2 – Load Balancer Server
- Dedicated IP Address: 126.96.36.199
- Quick FTP: ftpRootUser:ftpRootPassword@188.8.131.52:22
- Root Password: TheOtherRootPassword
… and so on until all of the details are typed out.
Note: To set up the dedicated IP address for Plesk Parallels on MyHosting, you click into the VPS Management tab and then click IP addresses and click the Assign IP address button to add the 2nd IP address to the server under Plesk. Then you can log into the Plesk Control Panel and go into the Server tab and click IP Addresses and change the 2nd IP address to be a dedicated IP address.
That way you have a dedicated IP address and a shared IP address for each server. Every hosting company has their own method of applying dedicated IP addresses to a server instance. Take the time now to go through each server instance and set up your dedicated IP Addresses and enter that info into this section under the corresponding heading.
After you’ve done that, go back through and double-check that it’s right for every server before proceeding.