Skip to content. | Skip to navigation

Four Digits | Willemsplein 44, 6811 KD Arnhem, The Netherlands | info@fourdigits.nl
 
Martijn is one of the four CEO's of Four Digits and is developing on the Zope platform since the early days. Developing custom Plone applications is what he does now, and he is also responsible for the Zope and Plone hosting platform which Four Digits is using for his customers.
 

A HA cluster setup for Plone and Zope (Part I)

by Martijn Jacobs Jul 11, 2008

Nowadays there are a lot of options how to setup your server configuration and a lot of choices which software to use. Virtual machines, data duplication, HA clusters, OS choice, what kind of servers : what is the best choice for a Plone and Zope hosting provider like us? After a week of investigation and testing we have found a setup which satisfies our needs.

Our requirements

Our goal was to build a HA (High Availability) server setup. In our case : If one physical machine fails, another should take over its tasks automatically. However, it's a waste if you have one machine doing nothing but waiting to take over, so it would be nice to have a combination of HA and load balancing, and a way to extend this setup with extra capacity if necessary.

Ganeti

Our first thought went to Ganeti, a tool developed by Google to manage virtual machines in a cluster with one or more physical machines. It doesn't support automatic failover yet, and the technology is very new so it would be risky to use this software for our setup. It's pretty neat software though,check out this PDF file for more information about Ganeti.

Traditional HA

A traditional setup is perfectly described here by the guys of Goldmund, Wyldebeast & Wunderliebe which is a HA setup which has proven to work. However, we wanted to extend this setup a little more, as we really liked the idea and flexibility using virtual machines as Ganeti does. It's easier to migrate this setup to a new machine, and you can move or copy virtual machines to another physical machine if necessary. You can also manage and configure the resources more easily, having the ZEO client VM having more memory and CPU power then the other VM's.

Our setup

The basis of our setup is almost the same as the HA cluster howto on plone.org : A master and a slave node. We added DRBD for data synchronization and Xen to have a virtual system for each layer in the setup. On each serverĀ  we have three (Debian) virtual machines : One for the Apache frontend (and caching if you want to), one for running the ZEO clients and one for the ZEO backend (and MySQL in our case). We mount a NFS disk for the actual data storage, but to keep it simple for now we assume the ZEO backend virtual machine stores the data. See the following image :

Our server setup

How it works

In a normal condition (when both nodes are active) the Apache VM and ZEO backend VM are running on the master node. The Apache VM has the public IP address (or floating address as mentioned in the HA cluster howto) to access the plone websites. The ZEO backend VM and the Apache VM are installed on a DRBD partition. This means these VM's are always being synchronized with the slave node. On both nodes there is a ZEO client VM which runs the ZEO clients. These are not installed on a DRBD partition (and not automatically synced) as they both need a different IP address (for the load balancer), and you may want to start a ZEO client in debug mode (for testing purposes for example). You can add new physical machines which run a ZEO client VM as well so you can extend capacity easily this way.

The main idea is actually the same : Heartbeat is configured on the slave node to monitor the master node. If the master server goes down it will start the Apache VM and the ZEO server VM on the second node. As these VM's are installed on DRBD partitions they are identical to the VM's of the first node. The Apache VM on the second node has the same IP address so it will take over all requests and the ZEO clients will reconnect to the 'same' ZEOserver, which is now active on the second node.

In Part II we will describe in more detail how we configured this setup, including our used configuration.

References

 

sticky sessions

Posted by Anonymous User at Jul 11, 2008 07:19 PM

Nice blog! We've never used virtualization, but it sounds like a good idea. How does the whole system perform? Can you give details on the hardware specs?

And what about sticky sessions? Do you use them? We experienced some issues without sticky sessions: suddenly being logged out after the load balancer switched the user from one client to the other. We now use apache to set the sticky cookies, which is a little different to how it's described on the plone howto.

Cheers, Huub Bouma

 

Re: sticky sessions

Posted by Anonymous User at Jul 12, 2008 02:27 PM

I'm surprised you are seeing logouts without sticky sessions - by default all state is stored in cookies rather than server side sessions. Having said that for authenticated users I do use sticky sessions for better cache coherency. With pound it is as simple as:

Session Type Cookie ID "__ac" TTL 300 End

 

load balancing

Posted by Anonymous User at Jul 12, 2008 07:43 PM

Aha, so you are using pound as a load balancer. We had a serious issue with pound, although I can't remember what it was :-) I think it was an issue with pound not detecting the slave machine going down, or coming back up again.

So your setup looks like this: pound -> apache -> zope? Or is squid or varnish in the picture as well? But I guess this is what you will describe in part 2.. I'd be interested to see what kind of hardware you are using, and how it performs (cpu / memory) with the virtualization stuff. Huub

 
martijn

Re: load balancing

Posted by martijn at Jul 14, 2008 12:15 AM
We are using the mod_proxy_balancer as you do. Thee sticky session you described above is also new for us (no problem so far), so we have to check that out. About the hardware : Performance wise we didn't found a significant difference using the virtual images vs. a native installation. We tested this on two machines with a single Xeon dual core each. Soon we are going to test it on two dual Xeon quad core machines, so we can test the setup running the virtual machines on dedicated cores. The result are coming soon :)
 
Anonymous User

Part II

Posted by Anonymous User at Jun 14, 2010 06:03 PM
Congratulations on this post. It is very informative. I'm looking forward to Part II. I wanted to implement a distributed plone solution and this is the best explanation I found on the web.
 
Made by Four Digits based on Plone.
Made by Four Digits based on Plone.