← Back to team overview

getdeb-collaboration team mailing list archive

Re: Mirror selection/distribution strategy re-evaluation

 

DNS round robin has the following additional issues:
- It requires all mirrors to have a common structure (the archive path must
be the same)
- managing DNS entries requires manual intervention (unless we use our own
NS, which we don't)
- DNS propagation can take days, removing the ability to keep failed servers
out of the pool

On Sat, Jul 10, 2010 at 5:39 PM, Emilio López <buhitoescolar@xxxxxxxxx>wrote:

> There's a third way to do this: DNS Round-Robin, and a "deb
> http://mirrorpool.getdeb.net/whatever";
>
> Advantages:
> * No single point failure
> * Basic load distribution
> * No overload on the master server
> * Easy manual setup
>
> Disadvantages:
> * No way to track package downloads
> * One-time mirror configuration to accept our hostname
>
> 2010/7/10 Joao Pinto <joao.pinto@xxxxxxxxxx>:
> > Hello,
> > after this long time of unavailability an also based on our current
> > limitation it's time to reevaluate the mirror selection strategy.
> >
> > The current setup is:
> > On the client side:
> > Clients are configured to use: deb http://archive.getdeb.net/ubuntu
> > lucid-getdeb apps games
> > On the server side
> > http://archive.getdeb.net/ubuntu/dists/... contains the repository
> package
> > list and is always retrieved from the real server (archive.getdeb.net)
> > http://archive.getdeb.net/ubuntu/pool/... which contains the .deb files
> is
> > handled by a PHP script which uses the mirror list and check if the file
> is
> > available at some mirror. Once a valid mirror is found the client is
> > redirected to it using a regular HTTP redirect.
> >
> > Advantages:
> > - real time detection of failed servers and redirection
> > - ability to centrally track package downloads
> >
> > Disadvantages:
> > - overhead of the extra http request / real time validation on a per
> request
> > basis
> > - single point of failure, no redirection with the master server is down
> >
> > A possible alternative is to use the APT mirror: method, it will require
> > client's to be configure with a line like:
> > Add a source entry like:
> > deb mirror://host/path/to/mirror-list/// dist component
> > Add a configuration file for apt with:
> > Acquire::Mirror::RefreshInterval "0" <- this is required to force the
> target
> > mirror url to be obtained for each "apt-get update"
> >
> > With this approach the master server is only queried once per "apt-get
> > update", all the subsequent transactions use the same mirror url. The
> > obtained mirror is cached on a local file, if the master server is
> > unavailable the last obtained mirror will be used.
> >
> > Advantages:
> > - no single point of failure (except for when the master server is down
> and
> > the user did not perform any apt-get update yet)
> > - no overhead/overload of the master server on a per file basis
> >
> > Disadvantages:
> > - a different method must be implemented to identify stale or unavailable
> > mirrors
> > - inability to track per file downloads
> > - more complex manual configuration (unusual source line and APT conf
> item).
> >
> > Giving our present issues I think we really should try to move the the
> > mirror: method at this time, any comments, other ideas ?
> >
> > Thanks
> >
> > --
> > João Luís Marques Pinto
> > GetDeb Team Leader
> > http://www.getdeb.net
> > http://blog.getdeb.net
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~getdeb-collaboration<https://launchpad.net/%7Egetdeb-collaboration>
> > Post to     : getdeb-collaboration@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~getdeb-collaboration<https://launchpad.net/%7Egetdeb-collaboration>
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
>



-- 
João Luís Marques Pinto
GetDeb Team Leader
http://www.getdeb.net
http://blog.getdeb.net

References