Forgot your password?
New user?
Document Actions
3.
Reference Architecture (by Lupi)
Up one level
This chapter describes a reference architecture that fulfills the requirements set forth in the previous part of this document. It is not the most performing architecture, instead horizontal scalability and ease of management and deployment have been preferred.
Front-end web server
An Apache web server or another similar system will be used to server static content, it will forward requests to the back-end servers.
The load-balancing component will not be present until more than one back-end server is used.
Configuration files or a database will map the user organizations[1] to the right back-end server. Initially, Apache rewrite rules and proxy capabilities will suffice; eventually, an Apache module that looks up organizations-to-host mapping in a database can be created.
Back-end server
We will have as many back-end servers as needed. When one’s capacity is saturated, a new one will be deployed and new organizations will be added on the new server. It is a good idea to create a “template” installation image that can be deployed on a new server by just copying it over the hard disk.
Due to the way Python works, the Zope application server doesn’t scale so well when run across multiple CPU cores. For this reason, each back-end server will host one Zope application server for each CPU core.
Each organization will have its own instance of Partecs software, they will be created as objects inside one of the Zope application servers. These instances should be self contained: users, content, groups and settings should all be stored inside these objects and their children.[2] In that way, it’s possible to use Zope’s built-in import/export mechanism to move organizations between Zope application servers or even back-end machines.
Scaling guidelines
It is impossible to forecast perfectly what will be the main bottleneck of this architecture until the software is developed. However, there are two possible scenarios.
The number of concurrent requests that a Zope server can fulfill is limited. If this becomes the bottleneck, then organizations should be shuffled around between Zope application servers - even on the same back-end machine - so that organizations with lot of concurrent users will get their own app servers. This will prevent very active organizations to starve less active organizations.
On the other hand, if CPU, memory or disk bandwidth become the bottleneck, then the organizations should be shuffled across back-end servers. Each machine should host a mixture of high-load and low-load organizations, in order to make sure that each system is used effectively.
In both cases, if an organization becomes too big to handle on a single server, it will be moved to a dedicated ZEO cluster. ZEO is Zope solution to connect multiple zope instances to a single database.