On Thu, 2006-09-07 at 13:49 -0500, Johnny Hughes wrote:
> Yes ... but you didn't understand. let me try again.
>
> mirror.centos.org is something that we own. There are 10 total servers.
> We pass out 1 address (because rrdns does not work correctly with
> python) ...
OK - so that's the real problem. I have always wondered why people
liked python... Is this something that could be fixed? Can we
shame them by pointing out that even IE does something fairly
intelligent when handed multiple IP addresses some of which don't
work?
> that address is based on your IP and geoip relevant.
> So ... you get 1 (and only 1 ) address to connect to.
And that's the application's fault, not a technical requirement.
> If in the middle of you 100 packages, you have a glitch and loose your
> ability to connect to the server (it is overloaded, a router 3 hops down
> dies, etc. ... whatever) then that download fails and you drop out of
> yum.
Application problem again, but still not particularly fatal as long
as none of the packages from the run have been installed. Just run
it again later.
> If you are using a mirrorlist, there are 9 other urls to try if that
> happens.
I mostly get 'metadata out of sync' errors when that happens. It
hasn't been as pretty as you suggest. And it often takes a 'yum
clean' to fix, which is even worse than just picking up where you
left off when your internet is working again.
> NEXT REASON:
>
> 10 internal servers can not serve all the updates required ... 127
> mirrors can. Those 127 mirrors are not named the same thing, nor are
> the paths the same. We can't pass them out as mirror.centos.org ... the
> mirror operators have chosen different paths that work for them, etc.
You could pass out any IP's you want as mirror.centos.org. It
might be inconvenient for the sites to map a standard URL into their
server layout so there might be some issues. Anyone running apache
with named vhosts could do it if they wanted.
> What we have done it built a system that will test them, pass to you 10
> active, close and geoip relevant IPs in real time. If a mirror is out
> of date, it goes away.
That would also be fine if it always gave the same list in the same
order when asked through the same proxy - if the client walks the list
in order. Or if the URL to get this list was always the same and
it is marked cachable for some time. There would be the possibility
of a bad, stale copy but somewhat offset by having several alternatives.
> For your situation, you can pick one mirror, use it in all your config
> files, then it will work perfectly for you in your cache.
People behind the proxies don't coordinate their choices of
distributions or repositories, let alone which mirror to use
of each repository. Besides, didn't you point out the problem
of just using one IP already? How can you suggest that as a
solution now?
> Unless 127 people want to donate machines to CentOS.org to put under our
> control, then we can name them all mirror.centos.org and control their
> paths.
You don't have to control a machine to give out it's IP in a DNS
response. You only have to arrange for it accept the name as a vhost
and map the document root to the top of your mirror tree. That still
may be a lot to ask but it is a very different question.
> Have you ever tried to develop a mirror system that can provide updates
> to 1.5 million clients?
No, I deal with a few hundred machines spewing perhaps a hundred Mbs
to the internet and my servers are all on the same continent but even
at that scale the last thing I'd want to do is defeat anyone's local
caching scheme and I go out of my way to give multiple IPs for the
same URL for site redundancy instead of letting clients see different
URLs.
The nature of your product is such that the odds are good that vast
numbers of those boxes are located in some small number of places that
would only pull one copy of an update if you didn't go out of your way
to force each machine to get its own.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
