On Fri, Oct 23, 2009 at 3:38 PM, J.H.
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@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@centos.org <mailto:CentOS-mirror@centos.org>
>> CentOS-mirror@centos.org <mailto:CentOS-mirror@centos.org>