There are several ways to load balance Seaside images, one common way is to use
mod_proxy_balancer that comes with Apache. Compared to other solutions it is relatively easy to set up, does not modify the response and thus has no performance impact. It requires to only load one small additional package to load into Seaside. Additionally
mod_proxy_balancer provides some advanced features like a manager application, pluggable scheduler algorithms and configurable load factors.
When load balancing multiple Seaside images care must be taken that all requests that require a particular session are processed by the same image, because unless GemStone is used session do not travel between images. This has to work with and without session cookies. This is referred to as sticky sessions because a session sticks to its unique image.
mod_proxy_balancer does this by associating each image with an route name. Seaside has to append this route to the session id.
mod_proxy_balancer reads the route from the request and proxies to the appropriate image. This has the advantage that
mod_proxy_balancer does not have to keep track of all the sessions and does not have to modify the response. Additionally the mapping is defined statically in the the Apache configuration and is not affected by server restarts.
First we need to define our cluster of images. In this example we use two images, the first one on port 8881 with the route name "first" the second on port 8882 with route name "second". We can of course choose other ports and route names as long as they are unique:
<Proxy balancer://mycluster> BalancerMember http://127.0.0.1:8881 route=first BalancerMember http://127.0.0.1:8882 route=second </Proxy>
Next we need to define the actual proxy configuration, which is similar to what we do with a single Seaside image behind an Apache:
ProxyPass / balancer://mycluster/ stickysession=_s|_s nofailover=On ProxyPassReverse / http://127.0.0.1:8881/ ProxyPassReverse / http://127.0.0.1:8882/
Note that we configure
_s to be the session id for the URL and the cookie.
Finally, we can optionally add the balancer manager application:
ProxyPass /balancer-manager ! <Location /balancer-manager> SetHandler balancer-manager </Location>
As well as an optional application displaying the server status:
ProxyPass /server-status ! <Location /server-status> SetHandler server-status </Location>
Putting all the parts together this gives an apache configuration like the following:
<VirtualHost *> ProxyRequests Off ProxyStatus On ProxyPreserveHost On ProxyPass /balancer-manager ! ProxyPass /server-status ! ProxyPass / balancer://mycluster/ STICKYSESSION=_s|_s ProxyPassReverse / http://127.0.0.1:8881/ ProxyPassReverse / http://127.0.0.1:8882/ <Proxy balancer://mycluster> BalancerMember http://127.0.0.1:8881 route=first BalancerMember http://127.0.0.1:8882 route=second </Proxy> <Location /balancer-manager> SetHandler balancer-manager </Location> <Location /server-status> SetHandler server-status </Location> </VirtualHost>
The rest can be configured from within Seaside. First we need to load the package
Seaside-Cluster from http://www.squeaksource.com/ajp/. Then we need to configure each image individually with the correct route name. It is important that this matches the Apache configuration from above. The easiest way to do this is evaluate the expression:
WAAdmin makeAllClusteredWith: 'first'
in the image on port 8881 and
WAAdmin makeAllClusteredWith: 'second'
in the image on port 8882.
This is it, the cluster is ready to go. If enabled the server manager can be found at http://localhost/balancer-manager, see Figure 152, and the server status can be queried on http://localhost/server-status. Note that before going to production these two admin applications need to be properly protected from unauthorized access.