The machines are in geographically separate locations. The reason for round-robin is both load balance and for fail-over. My guess is more folks than you think have crazy infrastructure. :) I've got servers in 4 geographically separate locations for example. On Fri, Oct 23, 2009 at 3:38 PM, J.H. <warthog9 at kernel.org> wrote: > Speaking as someone who has machines in a round-robin (for a number of > reasons) If the boxes are in the same place (same colo, etc) I would > suggest daisy chain syncing. > > msync -> box 1 -> box 2 > > it will mean that box2 will always lag, slightly, behind box 1 but it > means less load on the upstream and I would doubt if your users are > going to notice much. > > If you have disjoint machines (like I do), than having each one sync > independently is the only real answer, though I can't imagine there are > many mirrors who fall into my category of crazy infrastructure. > > What is the reason your doing round robin between the two? Have you > considered a shared storage solution if they are in the same place, I.E. > sync to a "master" backend and push the changes to the two frontends? > > I guess to make good suggestions, comments, etc (beyond the incredibly > generic things) we are going to need to know more about why you have > this setup and what your trying to do / accomplish with it. > > - John 'Warthog9' Hawley > Chief Kernel.org Administrator > > Nick Olsen wrote: > > Well whats the point of the round robin? To distribute load between the > > two boxes, and cover fail over? > > To save bandwidth from everyone's point of view I think it would be > > better to sync one from msync, and sync the other one from the first > > one. What does everyone else think? > > > > On 10/23/2009 3:22 PM, Bob Bownes wrote: > >> Dedup....indeed. > >> > >> So do I need to do anything special if I am going to have two machines > >> (in disparate locations) on a round robin DNS answering to > >> mirror.seiri.com <http://mirror.seiri.com> (and rsyncing from msync) > >> > >> I could sync one from the other, but that kinda defeats the round > >> robin point. > >> > >> iii > >> > >> > >> > >> > >> 2009/10/23 João Carlos Mendes Luís <jonny at jonny.eng.br > >> <mailto:jonny at jonny.eng.br>> > >> > >> That's why we really need block level deduplication, ASAP... ;-) > >> > >> Jeff Sheltren wrote: > >> > On Oct 23, 2009, at 10:22 AM, Nick Olsen wrote: > >> > > >> > > >> >> Never Thought of that.... > >> >> I guess your right. > >> >> Don't really see why ISO's shouldn't be carried though. > >> >> > >> > > >> > Disk space. > >> > > >> > Some people (I won't name names, *cough* warthog *cough*) might > >> argue > >> > that having ISO images is simply a replication of the packages > we're > >> > already carrying on the mirror and that there should be a better > way > >> > to handle stuff so that mirrors don't end up with multiple copies > of > >> > what is essentially the same data. > >> > > >> > -Jeff > >> > _______________________________________________ > >> > CentOS-mirror mailing list > >> > CentOS-mirror at centos.org <mailto:CentOS-mirror at centos.org> > >> > http://lists.centos.org/mailman/listinfo/centos-mirror > >> > > >> _______________________________________________ > >> CentOS-mirror mailing list > >> CentOS-mirror at centos.org <mailto:CentOS-mirror at centos.org> > >> http://lists.centos.org/mailman/listinfo/centos-mirror > >> > >> > >> > >> _______________________________________________ > >> CentOS-mirror mailing list > >> CentOS-mirror at centos.org > >> http://lists.centos.org/mailman/listinfo/centos-mirror > >> > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > CentOS-mirror mailing list > > CentOS-mirror at centos.org > > http://lists.centos.org/mailman/listinfo/centos-mirror > > _______________________________________________ > CentOS-mirror mailing list > CentOS-mirror at centos.org > http://lists.centos.org/mailman/listinfo/centos-mirror > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-mirror/attachments/20091023/2c769511/attachment-0006.html>