Re: Managing disperse servers
Hi, Mario, others --
On 16 Jun 2008, at 18:22, Mario Spinthiras wrote:
What I wanted to let you know about is that it would only be
reasonable to take geographical location into consideration while
managing servers. One good reason would be the repositories each
machine has for its updates. You wouldn't have US repositories if
you had a machine in Japan would you. My 2p.
This is a subject that has always interested me because I have often
been in a role where it has been my job to grow organizational
capacity (and therefore server infrastructures) from a handful of
servers to racks and racks of servers. Each time I did this I tended
to put something different in, because the system basically has to
cope with the culture of the organisation and skills inside tech teams.
Since this is an isp list ;-) you should be able to build intelligence
into your network that coped with the challenges you describe. e.g.
if you have clusters across the world, then deploying anycast segments
in every one of your POPs that hosted a local apt-cache, or dns
resolver that pointed an identical hostname for sources.list to the
country specific debian repository, then this should go a long way
towards promoting homogeny in your packaging configuration.
PS If you do find something of a more to a "turnkey" solution on
managing servers in a centralized manner , please share its
capabilities since this would be something very interesting.
I have always found it worked best to work with Debian, when building
site-specific additions for Debian. The sanest way to manage
configuration is to package up your config files into .deb packages
and put them into a central repository. e.g. use split config-files
wherever possible (e.g. Exim, Apache), and roll out your config
additions via packages that create new files inside the conf.ds for
each application.
Hope that makes some sense. Comments appreciated.
Andy
--
Best wishes, Andy Davidson
Tech Director, NetSumo Ltd., www.netsumo.com
Expert ISP and Network Engineering Consultancy.
Reply to: