I named all of our computers after characters on the Simpson's cartoon. It
seems we had one person to pretty much fit every role - from Homer, to the
Comic Book Guy, to Edna the sexy teacher.
Of course most users don't really know what or why their machine names are -
but it's very easy for me to keep track.
Now when a person leaves - I have changed the machine name to "fit" that
person a bit better. It makes it fun for me - or is it that I have too much
time on my hands? hmmm Maybe.
Now our servers are named after institutions on the show -
springfield_nuclear, moes_tavern ect.... so allot of times I'll see Homer @
moes_tavern... See it works out!?!
computers = fun ............ right?
Chris
----- Original Message -----
From: "Jay West" <jwest(a)classiccmp.org>
To: <cctalk(a)classiccmp.org>
Sent: Tuesday, October 22, 2002 11:32 AM
Subject: OT Re: Naming Computers (strategy, and WHY)
I personally don't name machines by "what
they are", for very good reason.
Plus, no one but the admin group uses the "real" machine names, also for
very good reason. Here's some illustrative examples...
If you call an HP K370 "k370.somedomain.com", and then upgrade it to a
K570
by just adding a few more cpu cards, do you really
want to still call it
K370.somedomain.com? If not, you have to retrain your user community and
this is a pain, and kinda defeats the whole idea of using meaningful names
so people don't need to know IP addresses. As a result, machine names
generally indicate what they are used for... so a machine that processes
orders might be "orders.somedomain.com". However, this can cause issues
unless the second point below is heeded...
If you give machines names that indicate "what they do" rather than "what
they are", you can then run into problems if you do clustering, or if a
machine goes down for a while (hardware issues), or more commonly, if for
load reasons you need to move an application to a different machine.
Thus -
(IMHO), machines should have a "real" name
that has nothing to do with
what
it is or what it does. These real hostnames are
typically what admin
people
will use. Then, define CNAME's for the
applications that the machine
serves
up...this is what "users" use.
Here's a realworld example. A particular webserver is named "joe" (at this
place, the naming scheme is baseball related, so machines get names like
hank, cy, willie, mark, sandy, ozzie, etc.). It serves up images via the
web
for bulk email that is sent out to subscribers that
has links in it back
to
images on "joe". However, users inside the
company who put up these images
via sftp go to the cname for the machine which is "image". The benefit of
this is, if joe ever gets too heavily loaded, or goes down or whatever, I
can easily change the "image" cname to point to a different webserver here
and move the content to it (in the case of a web server cluster, the
content
is already there). Thus, the admin group knows
"joe" is down, it doesn't
respond at "joe". But the emails sent out reference
http://image.somedomain.com, and that is what the users inside the company
sftp to, so to them, everything still works as it did before while some
other machine is doing that task.
The big benefit is admins know the machines by their real name, as their
job
focus is machine-centric. However, we can shuffle
applications and
services
around to other machines whilly-nilly, and we
don't have to tell the users
anything because they still use the other name that is "service" specific.
After all, admins should be spending their time watching system resources
generally. If one machine starts getting sluggish, they need to be able to
move one or a few of the services that machine provides to a less loaded
machine - and they should be able to do this virtually instantaneously,
without the users having to do anything different or know a different
machine name. Heck, most users have the "machine name" stored in their
terminal emulation software, and dont even know what it's called". And
half
of them don't know how to change it themselves.
This becomes especially important (and required) when you do clustering.
The
most common example is web farms, but it applies
equally to any service.
If
you have 30 machines that ALL serve up content for the
single URL
http://www.bigcorp.com you certainly can't name them all the same name.
And
if one of the machines in the cluster dies, you also
can't have a 1/30th
"hole" in your services. The above paradigm addresses this nicely.
To take it one step further, we use "wackamole" - a free unix program that
assures certain IP addresses are always available. It will shuffle the
group
of addresses amongst multiple machines on the fly. If
a machine goes down,
it moves it's ip addresses equally among the remaining machines in the
cluster. Most people accomplish "clustering" with round robin DNS, which
is
great, but you run into the problem of if one machine
in the round robin
list dies, anyone who gets the address of the down machine resolved gets
nothing. wackamole solves this problem very nicely. And as you might
guess,
doing things like this doesn't work well if you
are using machine names
unique to each machine.
Jay West
---
[This E-mail scanned for viruses by Declude Virus]