Ethan Jucovy
2010-09-04 21:02:48 UTC
The latest releases of fassembler, opencore-fassembler_boot,
opencore-fassembler_projects, and libopencore (geez) provide experimental
support for multiple Zope instances behind a naive load-balancer if you are
so inclined. I'll write this up in a more concise form on the wiki when I
have a chance, but for now I just want to capture what's involved.
Be warned that I haven't tested this extensively, or benchmarked anything,
and I'm not running it on CoActivate.org or any other production sites.
== Installing extra zopes ==
Fassembler now provides a project "fassembler:extrazope" which will install
an additional Zope instance into your build, connecting to the same ZEO.
You can run it in an existing build by
$ cd fassembler/src/fassembler
$ svn up
$ ../../bin/python setup.py develop
$ cd ../../..
$ ./fassembler/bin/fassembler extrazope
By default it will install the new instance into ./opencore/zope-1 and it
will be configured to run on localhost:10011 if your base_port is 10000. To
install more than one extra Zope you can run fassembler with a `zope_num`
setting -- e.g. ``./fassembler/bin/fassembler extrazope zope_num=2`` will
install the new instance into ./opencore/zope-2 which will run on
localhost:10021.
There may still be some subtle hitches involving collisions in shared var
directories, for PID files and the like. I'm not running this on
CoActivate.org yet so consider it pretty experimental.
Each Zope has its own zope.conf, checked into your etc_svn repository, so
you can tweak the settings per-instance. By default, all Zopes are created
with the same configuration, except that only your primary Zope will be
configured to run the clockserver jobs.
== Load-balancing ==
Now you've got an extra Zope or two, but the frontend is still just proxying
to your original Zope instance. Well, libopencore's frontend now lets you
proxy to multiple backends. (You should be using libopencore's frontend
instead of DeliveranceVHoster. See my previous message to this list.)
$ cd frontend/src/libopencore
$ ../../python setup.py develop
$ cd ../../..
In etc/frontend/frontend.ini you'll see something like this:
[app:opencore]
use =
egg:libopencore#proxy
remote_uri = http://localhost:10001
That ``remote_uri`` setting can now be a space-separated list of URLs to
proxy to, so if you've built three extrazopes you might change it to:
[app:opencore]
use =
egg:libopencore#proxy
remote_uri = http://localhost:10001 http://localhost:10011
http://localhost:10021 http://localhost:10031
When you restart the frontend process, the libopencore#proxy component will
now randomly select one of those backends on every request.
Note that you could also do this in the [app:tasktracker] or [app:wordpress]
sections, if for some reason you wanted to run multiple pylons or apache
processes behind a load-balancer too.
== The easy way ==
If you're rebuilding a site with opencore-fassembler_boot's
``rebuild_opencore_site``, all of this configuration and installation can be
automated. First, ``easy_install -U opencore-fassembler_boot`` to pick up
the latest release. Then just add a line like this to opencore.conf in your
site's base directory:
extra_zopes = 2
When you next run ``rebuild-opencore-site`` it will tell Fassembler to build
those extra zopes after everything else has been fassembled.
--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/09/1283634193954
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-***@public.gmane.org Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+***@public.gmane.org for questions.
opencore-fassembler_projects, and libopencore (geez) provide experimental
support for multiple Zope instances behind a naive load-balancer if you are
so inclined. I'll write this up in a more concise form on the wiki when I
have a chance, but for now I just want to capture what's involved.
Be warned that I haven't tested this extensively, or benchmarked anything,
and I'm not running it on CoActivate.org or any other production sites.
== Installing extra zopes ==
Fassembler now provides a project "fassembler:extrazope" which will install
an additional Zope instance into your build, connecting to the same ZEO.
You can run it in an existing build by
$ cd fassembler/src/fassembler
$ svn up
$ ../../bin/python setup.py develop
$ cd ../../..
$ ./fassembler/bin/fassembler extrazope
By default it will install the new instance into ./opencore/zope-1 and it
will be configured to run on localhost:10011 if your base_port is 10000. To
install more than one extra Zope you can run fassembler with a `zope_num`
setting -- e.g. ``./fassembler/bin/fassembler extrazope zope_num=2`` will
install the new instance into ./opencore/zope-2 which will run on
localhost:10021.
There may still be some subtle hitches involving collisions in shared var
directories, for PID files and the like. I'm not running this on
CoActivate.org yet so consider it pretty experimental.
Each Zope has its own zope.conf, checked into your etc_svn repository, so
you can tweak the settings per-instance. By default, all Zopes are created
with the same configuration, except that only your primary Zope will be
configured to run the clockserver jobs.
== Load-balancing ==
Now you've got an extra Zope or two, but the frontend is still just proxying
to your original Zope instance. Well, libopencore's frontend now lets you
proxy to multiple backends. (You should be using libopencore's frontend
instead of DeliveranceVHoster. See my previous message to this list.)
$ cd frontend/src/libopencore
$ ../../python setup.py develop
$ cd ../../..
In etc/frontend/frontend.ini you'll see something like this:
[app:opencore]
use =
egg:libopencore#proxy
remote_uri = http://localhost:10001
That ``remote_uri`` setting can now be a space-separated list of URLs to
proxy to, so if you've built three extrazopes you might change it to:
[app:opencore]
use =
egg:libopencore#proxy
remote_uri = http://localhost:10001 http://localhost:10011
http://localhost:10021 http://localhost:10031
When you restart the frontend process, the libopencore#proxy component will
now randomly select one of those backends on every request.
Note that you could also do this in the [app:tasktracker] or [app:wordpress]
sections, if for some reason you wanted to run multiple pylons or apache
processes behind a load-balancer too.
== The easy way ==
If you're rebuilding a site with opencore-fassembler_boot's
``rebuild_opencore_site``, all of this configuration and installation can be
automated. First, ``easy_install -U opencore-fassembler_boot`` to pick up
the latest release. Then just add a line like this to opencore.conf in your
site's base directory:
extra_zopes = 2
When you next run ``rebuild-opencore-site`` it will tell Fassembler to build
those extra zopes after everything else has been fassembled.
--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/09/1283634193954
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-***@public.gmane.org Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+***@public.gmane.org for questions.