Kwan Lowe wrote:
> On Tue, 2004-05-18 at 11:24, Chad Perrin wrote:
>
>
>>As of Saturday, the "best" Linux box I'm running is Debian Woody on a
>>Cyrix II 233MHz that has some bizarre onboard video chipset that won't
>>allow me to run X. You're lucky to be able to store the stuff in your
>>garage rather than having to use it. What I have in storage is, alas,
>>my Athlon 1600+ and my P4 2.4GHz, 3K miles away in CA.
>
>
> I've recently added two more machines: an Athlon 2500 XP (Barton) and a
> 900MhZ refurb ($100). These two bring to fourteen the number of physical
> machines on the network. Add another dozen or so VMWare installations
> for various customer projects and it's more than a hobby to maintain
> them. It's at the point now where it's getting physically and
> logistically difficult to patch this mix of Linux (Mandrake, Debian,
> RedHat8/9, Fedora) Solaris (8/9 on Sparc/Intel), Windows2K. I'm
> interested in what solutions you (and others) use to manage multiple
> architectures.
Uniformity is the simplest method of maintaining a farm of machines.
Every new architecture or platform multiplies the effort needed to keep
your farm in sync.
When building the farm of non-uniform machines at Intermedia, I built a
NFS tree per architure and built packages to run in that NFS tree
dependant on the libraries in the same tree. In this way, all of may
Linux boxes were able to run the same set of packages regardless of
distribution (in a way, I was maintaining a distribution of my own). You
get good at autoconf and the various PREFIX arguments neccesary to set
your build tree to the NFS shared path.
That, however, does not patch/update/synchronize the systems themselves.
Eventually, James Neal came along and opened my eyes to centralized
systems management with a tool called cfengine. The cryptic syntax was a
bit painful though, and we did find a bug that overwrote the /etc
directory in 50 machines in the farm before we caught it (cfengine is
much better now :)
The terse syntax of cfengine, and its design mindset of "make everything
this way" never really appealed to me. It does work well, though.
I really like using make. If you have a uniform set of machines, not
directly connected, all based off of the same distribution, keeping them
in sync is simply a matter of rsyncing around a directory tree of
"metapackages" with Makefiles that bring a box "up to date".
Running your own custom distribution is really the only way of ensuring
a stable environment for a large number of servers. Today, I use a
custom apt repository of hand-built packages that bring a system up to
date. Very few changes are made to a system itself (hostname, network
interfaces, not much else). Metapackages glue together various packages,
and have postinstall scripts that make the changes we want to make to
like purposed boxes. All package configurations are rsynced from a
central management box.
When you manage more than a couple of dozen boxes in a farm, you learn
to embrace self-made infrastructures. There are numerous tools for the
job, it's how you implement them and keep them in sync that is important.
A good place to start would be the infrastructures list:
http://www.infrastructures.org
There are a few senior admins in town that are really into this kind of
thing (myself included).
-- - Ian C. Blenke - Director of Service Delivery <icblenke@nks.net> (This message bound by the following: http://www.nks.net/email_disclaimer.html) ----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:43:25 EDT