11

We have a central repository of files in say server-1 at /srv/www. Then we have N number of servers as well. We want server-1 to be able to deploy its files in /srv/www to all servers as quickly and efficiently as possible.

Is there something like rsync, but instead of specifying a single target, specifying a cluster (N servers) of targets?

I was thinking git may work, but can we specify multiple remotes to push too?

What is the best solution, assuming N servers may eventually reach hundreds.

3

4 Answers 4

14

Well, both Twitter and Facebook have started using bittorrent in their clusters to distribute new code revs. Doing this, they're able to push code to tens of thousands of servers in a very short amount of time compared to old-school centralized deployment methods.

It doesn't sound like you're at that scale yet, but there's no harm in designing your deployment system such that it will not prove to be a bottleneck anytime soon.

4
  • 1
    How are they using bittorrent ?
    – Dragos
    Commented Feb 16, 2012 at 12:22
  • 3
    See the articles I linked to.
    – EEAA
    Commented Feb 16, 2012 at 13:35
  • @EEAA twitter link is broken
    – gprasant
    Commented Jan 14, 2015 at 19:57
  • @gprasant fixed.
    – EEAA
    Commented Jan 14, 2015 at 19:59
7

I don't recommend git for the scales you're talking to. It can work, but I personally see some deficits with using that model for fetching.

There are a couple of things that determine how best to go about this:

  1. How big of a repo needs to be shared out.
  2. How fast it needs to converge.

For perfect convergence, and maximum speed you'll have to go with a network file system, such as NFSv4. The clustered filesystems I know about don't scale to 'multiple hundreds' of nodes, so it has to be a network filesystem. This presents its own challenges, but it means that you'll reach convergence the moment the files are updated on the NFS head.

For rapid convergence, you can use some rsync trickery. If the rsync daemon ends up being CPU bound, you can certainly put a couple-three rsync servers behind a loadbalancer like haproxy. Couple that with cron jobs to pull data (or some other method of triggering code updates) and you can hit convergence pretty quickly.

For both of the above, it'll probably be a good idea to put the central repository on 10GbE links for maximum throughput.

An alternate is a push-rsync, where it's run from the central repo to push updates to your servers. It won't converge as fast as either of the above, but will be more friendly to your internal bandwidth. Use multiple hosts pushing to divided ranges for better speed.

1

rdist may work for you.

1
  • 1
    Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. Commented Jul 12, 2012 at 22:18
-1

[affiliated] Using Kwatee (http://www.kwatee.net) you can deploy on as many servers as you want. Deployments are incremental (only modified files are transmitted) and can be parallelized so its very quick. You can also configure Kwatee to be load-balancer aware so that servers are removed from the LB during updates and then re-inserted. There's a graphical interface to configure the deployment parameters and then deployments can be either manual triggered via GUI or automated using python commands.

3
  • care to explain the down vote?
    – mac
    Commented Feb 13, 2012 at 13:56
  • 1
    Joining the site just to pimp one's own product often garners downvotes around here.
    – ceejayoz
    Commented Feb 16, 2012 at 18:58
  • Regardless, so much for honest and transparent answers
    – mac
    Commented Feb 16, 2012 at 22:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .