Members

Note: You can use your Sitellite.org account here and vice versa.

Username

Password

Remember Login

Forgot your password?

Not a member? Click here to register

Load Balancing With Unison

Home Page | All Pages | Recently Revised | Authors | Feeds |

This page will show you how to set up Unison to solve the file synchronization issues associated with
load-balancing a website.

Unison (http://www.cis.upenn.edu/~bcpierce/unison/) is a two-way file synchronization utility. Read up on
it more at the Unison website. This page will stick to the basics of that subject.

Installing Unison

To install Unison, download the appropriate binary release to both servers (we'll call them Server A and Server B
from now on):

wget http://www.cis.....

Then unpack it:

bunzip2 unison-#.#.bz2

Now copy it somewhere in your path and make it executable:

mv unison-#.# /usr/bin/unison
chmod 755 /usr/bin/unison

To verify it's working, type this:

unison -version

You should see the version information displayed. Make sure you've done this on both servers now.

Connecting the Servers

To get the two servers talking to each other through Unison, we're going to tunnel it through SSH, but since
this is going to be run every few minutes via Cron, we'll need to set up public/private keys in SSH so this
can be done without having to enter a password each time. Here are the steps for that.

On Server B run the following command:

ssh-keygen -t dsa

Just hit enter when it asks you for a passphrase. If you enter one, this won't work. Now make sure to note the name and location of the indentification and public key just generated. The public key file ends in .pub, fyi :)

Next, you'll have to make sure the identification file is saved to one of the places listed under IdentityFile under /etc/ssh/ssh_config. If unsure, try saving it to ~/.ssh/identity

Now for the public key, copy it over to Server A:

scp public_key_file.pub user@ServerA:~/.ssh/authorized_keys

Note that this file on Server A may already exist. In that case, don't overwrite it like this, but instead paste the entire contents of the public key file at the end of this file on Server A.

Now you should be able to SSH into Server A from Server B without having to enter a password:

ssh user@ServerA

Bringing Unison Into the Mix

Now it's time to add Unison to the equation, which we do by simply calling Unison like this:

/usr/bin/unison /path/to/sitellite/pix/ ssh://user@ServerA//path/to/sitellite/pix/

That's all there is to running Unison. You may be prompted by Unison the first time with the actions you'd like to take. Simply hit 'g' to go with the recommended action or press Return, depending on the action.

To run this in Cron, we're going to add some options to this command:

/usr/bin/unison -batch -silent /path/to/sitellite/pix/ ssh://user@ServerA//path/to/sitellite/pix/

These tell Unison to do what it's told and not bother you about it. Very nice. :)

Bringing Cron Into the Mix

You should be able to just type crontab -e to edit your Cron tab. If not, and you're doing this as root, you may have to add your entries to /etc/crontab. There's one change to the Cron entries I'll mention below in that case.

To run this command every 2 minutes via Cron, you would use the following entry:

*/2 * * * * /usr/bin/unison -batch -silent /path/to/sitellite/pix/ ssh://user@ServerA//path/to/sitellite/pix/

The exception for /etc/crontab would be to add 'root' as follows:

*/2 * * * * root /usr/bin/unison -batch -silent /path/to/sitellite/pix/ ssh://user@ServerA//path/to/sitellite/pix/

Now you'll need to determine which folders need to be synchronized and add a line for each of these. Some suggested folders would be:

  • /pix/ - Stores all images.
  • /inc/data/ - Stores web files.
  • /inc/app/cms/data/ - Stores versions of web files.
  • /inc/conf/ - Stores configuration options, including roles and teams.
  • /inc/html/ - Your template sets, which you may change using SiteTemplate, are stored here.
  • /inc/app/cms/conf/ - Stores collections and workflow definitions.
  • /inc/app/*/data/ - Some apps use their /data/ folder (and some even use /pix/ too) for app-specific data. You may want to check which apps you're using and see if they fall into this category.

So an example crontab might be:

*/2 * * * * /usr/bin/unison -batch -silent /path/to/sitellite/pix/ ssh://user@ServerA//path/to/sitellite/pix/
*/2 * * * * /usr/bin/unison -batch -silent /path/to/sitellite/inc/data/ ssh://user@ServerA//path/to/sitellite/inc/data/
*/2 * * * * /usr/bin/unison -batch -silent /path/to/sitellite/inc/conf/ ssh://user@ServerA//path/to/sitellite/inc/conf/
*/2 * * * * /usr/bin/unison -batch -silent /path/to/sitellite/inc/app/cms/data/ ssh://user@ServerA//path/to/sitellite/inc/app/cms/data/

That should be all there is to synchronizing filesystems between load-balanced Sitellite sites. Note that there are still other issues involved in load-balancing, such as session management, centralizing databases, etc. These are the types of large-scale website issues solved in Sitellite Enterprise Edition.

Revised on November 20, 2007 4:07 PM by anonymous

Back in time (818 more) | Linked from: Administration