Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
2  
I assume a network filesystem isn't possible? –  cjc Feb 11 '12 at 2:14
    
stackoverflow.com/questions/849308/… for a git trick to pushing to multiple remotes. Not sure about hundreds, though. –  cjc Feb 11 '12 at 2:21
    
possible duplicate of Copy large files to multiple machines on a LAN –  mfinni Feb 16 '12 at 19:14

4 Answers 4

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.

share|improve this answer
1  
How are they using bittorrent ? –  Dragos Feb 16 '12 at 12:22
3  
See the articles I linked to. –  EEAA Feb 16 '12 at 13:35

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.

share|improve this answer

rdist may work for you.

share|improve this answer
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 '12 at 22:18

[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.

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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