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 _at_
moes_tavern... See it works out!?!
computers = fun ............ right?
Chris
----- Original Message -----
From: "Jay West" <jwest_at_classiccmp.org>
To: <cctalk_at_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]
>
>
>
Received on Tue Oct 22 2002 - 10:53:01 BST