Our company's current customer-facing site & intranet site is currently built on Classic ASP running on IIS 6. The current site only contains about 10 customer-facing pages, and an internal site that manages HR records, scheduling, etc.

Management has decided that we will use this rewrite project to finally develop our online retail store. They want us to use a geographically separate facility (also on a completely different ISP) to provide a failover in case the WAN link at our primary facility goes down.

We have chosen Python for the rewrite as we want to be able to move to a Linux-based platform, and we currently use Python in other in-house development projects.

We have looked at the various Python web development frameworks, and CherryPy seems like a good fit for what we need, which is a minimal environment for serving Python-generated content. However, I am having trouble finding information on using CherryPy with load-balancing and failover technologies.

It would appear that we will be forced to host CherryPy on Apache in order to leverage a failover/load-balancing cluster that supports sticky sessions. Is this correct, or this there a way to do it using CherryPy's internal server or a different HTTP server altogether?

Also, are there services that provide a way to direct the traffic in the cluster so that we do not have to host it ourselves? We need to be able to distribute our traffic between the 2 data centers, but if the WAN link goes down at either, it can't affect the ability for the cluster to direct traffic to the cluster that is still available.


There's two main parts to this,
- load balancing and failover across multiple datacenters
- load balancing and failover across multiple servers within a datacenter

There are three main ways to do multi-datacenter: BGP/"anycast", GSLB/DNS, or using an origin-failover mechanism within a CDN. none are simple, easy, or cheap.

Once the users' traffic arrives at a particular datacenter from there you want a loadbalancer component. There are tons of options here that can be broadly categorized as appliance-vs-software and layer4-vs-layer7. Judging from the details you did give I'm gonna bet your needs are pretty simple and your budget pretty small so lets just skip straight to nginx for this part. Within nginx you can configure it to serve your static content and to loadbalance your dynamic content across as many backend servers as you like running your python application.

Good luck, its a long road you've started down.

  • Which load balancing appliances, prey tell, do not use software? – womble Jan 8 '10 at 22:50

There are quite a few sub-questions in your question that really should be their own entries - but let's tackle them anyway...

CherryPy's "server" shouldn't be used at all in production, it's great for development but you really should use Nginx and a Fastcgi setup in front of your CherryPy app. This will give you better control over the load of the server and how many instances of the CherryPy app you need to run to manage that load.

Your concern about load balancing across ISP's makes me think your more worried about redundency than load balancing because you will need to worry about keeping the data involved sync'd between the different data centers, which is a bigger worry than how to load balance across them.

Depending on how much budget pain you can handle is what will drive the decision to either use a hardware load balancer or a software solution. If you are looking for redundancy you can have the server setup mirrored at another site and then change your DNS records to point to that site in case of failure. Anything else will require hardware solutions that involve the alphabet soup of acronyms like cagenut mentioned above.


We use ZXTM to load-balance multiple instances of the same CherryPy nodes. Works great.

Recent versions of CherryPy (3.0.4 and 3.2, for example) include a fix to the WSGI server to make this more robust. Previous versions would accept new connections and hang on to them even if the incoming request queue wass full (that is, if all worker threads were busy). Now, you can set server.accepted_queue_timeout to 0 if you'd rather have them be rejected right away. Closing those connections immediately allows ZXTM to try to pass the connection on to another node right away.


Are you sure this is what you need? Ask your management a figure on acceptable downtime, they may very well lower the bar to realistic levels. Two completely independent sites puts you in the big boys category, with matching pricing on the solutions.

Perhaps you can find a custom solution with a reliable internet partner? Find someone willing to offer you colo in different racks (on different power feeds), on two access switches to two core routers to two very different uplinks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.