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.

Improve this question
3

4 Answers 4

Reset to default
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.

Improve this answer
4
  • 1
    How are they using bittorrent ?
    – Dragos
    Feb 16, 2012 at 12:22
  • 3
    See the articles I linked to.
    – EEAA
    Feb 16, 2012 at 13:35
  • @EEAA twitter link is broken
    – gprasant
    Jan 14, 2015 at 19:57
  • @gprasant fixed.
    – EEAA
    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.

Improve this answer
1

rdist may work for you.

Improve this answer
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.
    – Mark Henderson
    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.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.