RFC 1178 – Choosing a name for your computer (1990)
tools.ietf.org
tools.ietf.org
With a pet, you obsess over the name and meaning of the name. With cattle, as long as names don't collide or cause problems, you couldn't care less about the name.
If I know the hostname I or my team will be tempted to make one-off changes, breaking the whole "cattle" idea.
Inevitably, some bug will occur, and in my experience, it usually happens to occur on a machine (rather than all of them at once; I'm not saying this machine is special — the bug could have happened on any of them, and likely exists on all of them because they're all running the same code, but this particular machine ended up being the lucky one to serve that slightly unusual request).
Getting in and debugging the state of that machine, pulling logs, directing a coworker to look at CPU detail "frobnozz", etc. is all easier if I can easily speak or type out the machine's name. "3.dev.microservice" is much easier to type/speak than say, an IP address, an EC2 instance ID, etc.
(I fully agree on not making one-off changes, and not treating machines as pets. But I think that even after that, decent naming has a place.)
And even with cattle, the other way, I still think it's useful for the name to provide some information. I.e., 3.prod.microservice being the third or fourth instance of the production setup of "microservice" is better than say, some random entry from the periodic table of elements.
${project}-${dev/staging/web}-${web/db}
(which so far has covered my bases, I'm sure you can come up with any logical extensions if you are running load-balancers or other types of servers, add a number if you are running multiple frontends or clustered DBs, etc)
Even as someone who manages pets, I can't tell you how much time this has saved me from having to look up server names. I have done the generic "assign everything to a single machine## sequence" and it sucks ass. Was your production web server for this app machine32 or machine 54? What about the staging server? Can't even imagine the hassle of uuids as server names.
(of course so far I have done the pets thing in my internal network... but I can tell you that my father with a 40y career in managing servers for major corporations uses names like vmhost01/fsrv01/tvpc at home... which tells you what he thinks of that.)
But, hey we don't name infrastructure sites "Site 1" and "Site 2". They're "Milwaukee" and "Austin" and "DR". So if we do that, why name them "EMC-SAN-1" and "EMC-SAN-2"? We're going to retire that name eventually and there won't be a SAN 1 anymore. And what happens after "EMC-SAN-9"? So, instead why not "EMC-SAN-ARTEMIS" and "EMC-SAN-APOLLO" and "EMC-SAN-HADES"?
There's a distinction between physical names and logical names, too. What kind of long term nomenclature planning should we have? Look at hurricane names. The NWS does that so people remember which is which.
Though with all the milking machines hooked up the dairy cows probably look more like them visually speaking..
And these days servers might be more metaphorically close, increasingly, to just the beef itself. Decentralised, to somewhat stretch the analogy.
If they are any servers that cannot be auto created / destroyed without human oversight - or if their downtime breaks other resources along the chain (eg non-clustered DB server) then I'd argue those servers are a little more like dairy cattle.
He was tasty.
Most of the general purpose computers (and certainly the vast majority of devices with an IP) I deal with have real world interfaces, SDI ports and/or analog/digital audio connections. I'm not going to give my encoder in Nairobi a name that doesn't say "Nairobi Encoder" (PTR returns NRB-ENC001-obe, forward lookup for NRB-ENC001), same with encoder 2 at New Scotland Yard, and the same with the ntop/monitoring box I have in the New York office. I can't self heal equipment when a lorry drives into it, but I need to know that it's the Old Bailey monitoring box that's broken.
Thank you for implying that I didn't know exactly what I was responding to, and that I didn't read it carefully. The grandparent to my comment mentioned the cattle-pet distinction. The parent comment took that as some kind of statement of how common each situation is. I replied in a similarly loosely-connected manner, trying to reinforce the grandparent comment's point.
I fully understand that "cattle-owners" are less common, and that that's part of what the parent comment was saying. Reread the comment that they replied to, and reinterpret my comment as a reiteration of the grandparent comment, phrased in a different way.
But then I did realize a couple of things, that improve with meaningful names:
1) Alerts impact and scope. It's easy to know what are you seeing in your phone, if balancers, rds clusters, and instances have meaningful names.
2) Metrics visualization. Maybe the graph is the same, but a meaningful legend sometimes helps.
3) SSH connection. I like to auto-complete SSH, not to copy/paste ssh and write down extra parameters like different .pem files.
4) (Inter) team communication. The same that with graph legends, for humans, it's easier with names than with ids.
5) Custom commands parametrization. The same than ssh, I prefer to be able to write down the parameter (host name, service name) of my command, without getting out of the terminal, copy the ID or IP, get back, paste, verify...
6) Costs/Reports visualization.
7) Backup management. Let's say S3 parent for the backups of a instance/service. Backup reports too.
At the end, I think that I can have cattle mentality regarding Configuration Management, System patching, Version change, etc... BUT I still can get benefits from thinking a little bit element and service names.
At the beginning (of the cloud concept), I did read pet Vs cattle, and I did think IDs were the thing. Now I think that to scale to many customers or many environments, it's better with previous thinking. Being the little string of the alert in the phone, the biggest winer.
You never want to have to manually pick a name, or even stop to think about it, but using pure IDs for anything with a life longer than a day can get annoying.
But all servers are named as cattle.
But these days they may not even be cattle named as they are spun up and down so frequently in cloud environments that names makes no sense.
Pets -> Cattle -> Population?
That is also how I feel about Microservices these days. I may still name the service with a "pet" like symbolic name, but I treat them as cattle.
They can be split, repurposed, deleted, rewritten any day without much remorse or delay. No personal attachment.
Mostly because for automation it's easier to know what a system does by looking at the hostname. When you manage about 30 systems all over the place, that's the only reasonable solution (I do see people trying to give pet names to their production systems but it gets out of hand and they usually just maintain a directory of what system does what somewhere)
sql01 is good if you only use sql abstraction layers, otherwise you probably even want postgres01 and mysql01. Or even postgres-olap01 and postgres-oltp01, if that's what you do.
If had a pure mysql server I'd call it mysql01
I never get why there's such a huge gap between admins and programmers on this. Programmers have sane, intelligent naming conventions beaten into them, and yet when I ask a sysadmin what server the Wiki is running on, half the time the answer is something like "legolas". That name would never make it through my code review.
Agreed. Nothing confuses me more than finding a network with a bunch of machines named for roles that they don't fulfill.
Even more infuriating is when you have a network like that, but the new machines have names that refer to the old ones -- so for example, the webserver may be "webserver," but the new replacement may be "real-webserver" and then the replacement of that may be "real-webserver-replacement."
I tack on "-linux", "-windows", "-android" and so on when appropriate.
Even when they did descriptive names, it was all backwards like <instanceID>-<env>-<role>-<project> yielding things like 2-dev-db-something. Trying to explain how that made sorting machines by name impossible was alien speak to them.
I think the reason programmers are better with names is that we get to name many, many more things. Variables, functions, parameters, namespaces, endpoints, the list just goes on both in the small and the large.
I don't think there's such a big gap there, either. It's not uncommon for developers to give large, general-purpose applications nondescriptive code names. This actually tends to be useful when trying to distinguish the names that marketing gives a product (which can change) with the names of the applications that back it (which shouldn't).
I think it also often depends on how many machines your sysadmins have to manage, and how many they had to manage prior to this naming scheme. Once you've experienced the pain of too many odd names, and trying to figure out how to map them to roles, you don't generally want to go back, in my experience.
which is precisely why the 'www.<domain>.<tld>' convention is so widespread..
You get some cool names, but there is a fairly critical downside in that a lot of people struggle with spelling the names. Most people probably can't spell Odysseus correctly on the first attempt, and it's even harder to spell Jormungandr correctly.
I think that cutesy names like this are fine for personal use, but for commercial use you're better of using a more standardised schema for naming.
Another place where companies seem to love cutesy names is meeting rooms. Maybe it's because management wants to sound interesting, or maybe they just like painting bike sheds, but often they like to give non-standard names to meeting rooms, like names of native birds or something else that doesn't describe the room at all. It just makes it hard to remember which room is which. How am I meant to know which room is the Tui room, and which is the Moa room?
Either name them by location (e.g. Second Floor, NW), or by distinguishing feature, at one job we had a meeting room with no windows, so we called it the bunker.
Triangle: It was triangular.
Rainier: View (or maybe painting?) of Mt. Rainier.
Elvis: Blue Suede Chairs.
My current office uses normal floor and room numbers for conference room reservations but one of them has an "OUTATIME" CA plate taped to the window and a flux capacitor poster on the wall. We refer to it as "DeLorean".
The thing to keep in mind when doing this, too, is that DNS is a hierarchy. Use that.
Many companies have a naming scheme something like EX-AP-NY-FS-1 for Example Corp's Appliance Division's New York Office's File Server number 1. Try fs1.ny.ap.example.com instead. It's much cleaner, and then the New York office can have ny.ap.example.com as a search domain and refer to it as just fs1 even if there is some other fs1 in the San Francisco office. People in SF can still access the New York server and vice versa by using the fully qualified name.
It also puts administrative boundaries in the right place, so the appliance division has authority over its own names but not the names belonging to some other division.
(I ended up setting different terminal prompts depending on which domain the current machine was under.)
Two decades ago when I only had a handful of servers it seemed a great idea to name them after Greek Gods (on the Zeus family line). I actually stole the concept from the DEC VAXcluster I was working with at the time. Fast forward to present day and everything being virtualised, it's trivial to boot up a new server from a template, and naming each new one has become a massive pain. As I apply a no-reuse rule, I find myself delving deeper and deeper into Greek mythology. I also try to match the name with the purpose, so the God of Messaging (Hermes) is my Mail Server, Zeus is the Hyper-V host for all his offspring etc.
It all made sense at conception, but now I've got ~40 servers doing various things, and half the time I can't remember which is which. :(
However...
In a professional environment[1] I have lost SO many hours in pointless 'naming convention' arguments. Everyone has a different view as to how it should be done. My view is to pick the defining characteristics of the servers; Is location important? Are they single role servers? Are they lab or production? Do they belong to specific part of the business?
For example: 'LDNTCADSP001' breaks down into {location}{datacentre}{role}{lab/prod}{unit-number}
* Don't use wasted character like dashes as depending on your systems you've only got X characters to play with.
* Sysadmins should always be able to identify at a glance what the server does, and where it is without having to fire up a CMDB.
--
[1] I've held senior roles in several major global Banks, where my teams managed several hundred servers on average. So this is a real-world viewpoint.
It's untypable on a command line since you have to shoot all over the keyboard, and it probably won't auto-complete until you get to the last number.
There's other subtle problems to: its not sparse enough for the same reason. You're putting a lot of stock in an operator always seeing the right sequence of numbers, especially if your fleet grows and you now have a LDNTCADSP101 and LDNTCADSP110 for example.
They're also unpronounceable - you can't communicate them to other people verbally quickly or reliably.
The best thing we've currently done at my work is assign single-use mnemonic names to all the servers (and, I'm pushing for it to be everything) - so we have "subsidy", "until", "wedding", "opulent" as server names. Easy to remember when you're debugging, easy to say, and a sparse namespace - you're exceedingly unlikely to mistake one for the other, and they'll autocomplete easily. It plays right into the human associative memory too.
This is my recent life as I started a (hopefully temporary) phone support role and the place I work has desktops with names like that but also, inexplicably, using all the hard letters in to hear well over the phone.
Ex: HPDHHPDEDPD-TS
Thanks goodness the folks I'm talking to can use a semblance of the phonetic alphabet.
Again, in my view (based on several years as a support monkey at the beginning of my career), desktops/laptops should be named based on their asset tags, LT891334 or DT993115 etc. That way, when you ask the user 'what's the machine name' and they have no idea, you can say 'read me the number that's on that big white sticker on the lid'.
I wasn't disagreeing with you at all and I really like your solution. I was trying to provide an example of desktops I deal with now that are sometimes impossible to distinguish on the phone without going full NATO alphabet.
So when an alert came in at 3am that "mulhouse" is down, you had to know that Mulhouse is a French city AND France denotes database machines. And the city names were often fairly obscure, of the 100 names, I had only heard of a handful of them. "Is that name Icelandic or Finnish?"
That director of IT didn't last long.
Monday, July 1, 1996 - We got hits from: polio.yahoo.com, pilsner.yahoo.com, mead.yahoo.com, scabies.yahoo.com, ratbastard.yahoo.com, lambic.yahoo.com, stout.yahoo.com, scorpio.yahoo.com, and srinija.yahoo.com. The Wired article had already come out at that point so I must have just remembered Srinija Srinivasan's name from the article.
Later in 1996 and in early '97 we got hits from: suppository.yahoo.com, boils.yahoo.com, tuberculosis.yahoo.com, and lobo.yahoo.com.
So, I see an alcoholic beverage theme and a disease theme. Yay!
Recent incarnations have been: StarshipEnterprise CaptainKirk MysteryMachine
Two words seems expedient, and a coupling of 2 + 2 or 2 + 1 syllables (loosely speaking) seems to leech into memory pretty well.
Personally, I've always been fond of pagan deities.
I can't wait until I need to use t-j-houshmandzadeh.
My cloud hosting account uses players on the active roster; my little hobby home servers use players from the practice squad.
https://en.wikipedia.org/wiki/2003_Cincinnati_Bengals_season...
Also iirc there was a set of servers named after arcade games, zaxxon.cs is still resolving at least.
Eventually it becomes really annoying, don’t do this.
Think I'd rather have the periodic table.
(Yes, I assume you meant ancient greek)
High School teaches tons of crap. I spent 5 years doing French, and while I remember "J'ai joue le foot" (which was a lie), that's about it, I could pick up more French in 3 months worth of weekly evening classes.
Even the French I know doesn't help - I went to a kiosk at Gare du Nord, having just got off the train from Brussels. "Je Voudrai une cafe sil-vou-plait". "Three-fifty" comes the response. Bloody French.
High School languages in the UK (and other English speaking contries) would be far better giving a smörgåsbord of the basics of French, German, Spanish, Italian, Russian, Arabic, Mandarin, and Portugese. Being able to say "Hello, good to meet you", "Thank you", "Excuse me, where are the toilets", "Could I have the bill please", understand a few phrases (tickets please etc), and have a fighting chance at reading and ordering from a menu, etc, in most countries of the world would be very beneficial. 4 years, 2 languages per year. Perhaps more important than the language specifics are the customs, even things like composting train tickets,
(Of course with translate apps, map apps, etc the menu/map problem is going away, but the customs and some language overview would go a long way - when train tickets neet composting, when tipping is required (USA), not required (most countries), and actually an insult (many far east places). Being able to recognize which toilet to go in - W or F - is helpful).
Wider cultural education would be a massive benefit to Americans in general, who on the whole don't get the chance to travel that say Brits do.
I wonder if you start to do chemistry on the names if you need to track multiple subnets? 192.168.11.17 might be sodium-chloride (NaCl).
Metropolis chose the name MANIAC in the hope of stopping the rash of silly acronyms for machine names,[2] although von Neumann may have suggested the name to him.
One thing to keep in mind here is that naming should be done with a lifetime matching the thing being named. If a given machine might have many roles in its lifetime, asset names ought be separate from role names. So calling a machine db2 might not be a good idea unless you have 100% confidence it will only ever be a database machine.
So a62848 could be asset 62848, which then can have all kinds of exciting metadata and services pointing to it that may change over the asset's lifetime without needing to update the host name.
Baking metadata into a name is usually going to lead to sadness when later attempting to rename.
(While I'm the product manager for Google's datacenter software team I'm not speaking for Google here.)
One of the nice side effects of using the cloud is production systems don't normally change name anymore.
I can name a machine db2, and if I don't need it anymore, it's quick to destroy it, and create a new machine of the same size named appserver15.
https://www.mnxsolutions.com/devops/a-proper-server-naming-s...
Home network is all character names from LOTR, home office is Expanse, etc.
It's fun to try pick suitable names from the movie, for the device, eg my HTPC is Gimli, because it's a small case but carries more than its weight. Gaming PC is Gandalf because it's entirely white.
Sub-categories of characters is good for sub-categories of devices, so all our phones/tablets are named after the Elves.
The main problem with this method is the HOURS you spend angsting over the correct names because it's actually fun.
For instance, my old server was called TheQ (i.e. 'Q' from James Bond) and the new one is named Judy, because Judy Dench plays 'M' in the most recent films. It's convoluted, but it's neat to have what is effectively your own mythology.
Ah, it was fun at any rate. I miss you, Lanfear!
Carbon, Hydrogen, Nitrogen, Neon, Tungsten, Helium, Sodium, etc
Wifi names are after noble gases.
PC hardware are all stable metals.
iPhone/iPad accessories are all non-metals.
and finally, random IOT devices are radioactive elements.
Scheme-compliant _and_ metaphorically apt. Love it.
- Helium - my Surface 3, because it's light
- Lead - my heavy Linux laptop
- Lithium - the Mac Mini I bought to keep from going crazy using a decade old Macbook Pro for iOS development
- Caesium - my Dell "workstation" Windows laptop, because I bought it to save time (compared to running Windows + Visual Studio in a VM)
- Uranium and Thorium - the beefy Xeon workstations that run a bunch of VMs and things - named because they put out so much heat that they might be radioactive
If only the RFC knew what we know now.
On the plus side, if I ever get one of those "you have a virus" scam calls, I can probably string the caller out for a while trying to get them to spell out the name of the computer that supposedly has the virus...
johnnyfive marvin katya gerty kryten robbie
Doing our best to avoid dipping into Star Wars laziness. (And HAL is verboten too.)
quiddity quilt quasar quantum quack quiz...
It's funny how a silly naming rule like that winds up sticking for a couple decades.
Our main constraint is that it has to be a robot that my wife, a devout sci-fi sceptic, has heard of. Probably it would make more sense for her machines to be named after obscure British Jacobeans and mine to be robots but since I've paid for all of them, I get to choose.
All of my machines are named after islands:
Mauritius Sable Padre Nauru Jarvis etc.
his face lights up and says "yeah! like planet01, planet02, planet03.."
* Prisons (statesville, graterford, etc.): Macs
* Astronauts (resnik, white, aldrin): DECstations
* Disasters (flood, famine, humanity?): More aged DECstations
* Climates (tundra, steppe, island): SPARCstation 5s
* Characters of Sir Arthur Conan Doyle's
* Wood (elm, pine, smoke): Printersany insight there?
IIRC I recall hearing something about this due to NeXT (and now apple's) use of CMU Mach.. but universities are big places :b
You'll never guess what the third one was called...
This was applied to both VM hosts and VMs, so you had to remember that "livigno" ran VMs x,y,z, and was actually in the backup DC.
A later company had a better scheme:
Hosts: <service>-<role><number>-<data center>-r<rack ID>-u<rack U location>
e.g.: nova-compute0042-uswest-rF20-u23L
VMs: <service>-<role><number>-<region>-az<availability zone>
e.g. designate-mdns009-uswest-az3
This really does help debuging issues at a glance (e.g. you can see that all VMs in uswest az1 are down at a glance), or directing people to a failed node (replace disk 5 in nova-compute0042-uswest-rF20-u23L is very clear what machine needs maintenance - in the us west DC go to rack f20, and the left hand blade in u23 needs disk 5 swapped).
For the price of actually using my asset DB, my alerts can be sliced and diced exactly by the datacentre/rack/whatever because I'm properly tagging everything.
Whereas for all the times I've heard "oh we won't move servers and if we do we'll re-image them..." just last month (and still ongoing) people have been dragging racks between floors, plugging them in and that's it - so fixed names like that get stuck.
If you are in the habit of moving racks, then I would agree keeping it only in an inventory system makes sense, but that also requires the asset system to be updated when a rack moves - at which point changing a hostname (which can be autogenerated by dhcp based on that system) an easy step to add.
Nowadays, we prefer to name them after something more meaningful, like Archibald [Captain Haddock's first name, fitting for an Arch machine], Winry, or Delphine (Windows and Debian, respectively). This makes easy to identify the machine and its operating system, which I like including in the host name.
Overall, I find that having a clear theme helps (to know we are talking about a computer's name), and clear rules for the naming scheme also help, both for picking the name, and guessing its function/characteristics from the name.
I would definitely go with some DNS-based convention like the one @zrm mentioned when having to manage bigger clusters or geographically disparate pieces of equipment, though.
I would also disagree with something in this RFC: I don't mind tying a hostname to the host function, as I usually reimage/reinstall the operating system when changing it, making it easy to rename it. This also helps with keeping everything modular enough that it can be quickly installed on a new machine, and prevents "ossification" of the various configuration files. This includes giving a replacement computer the same name as the one being replaced.
Finally, when managing a truly dynamic cluster (computers that boot a PXE image with little to no local storage, and take their jobs from a control server), I don't even bother naming them, and will choose something semi-random like the MAC address (even a link-local/DHCP address, or the md5 of one of these). As those are temporary identifiers, they are managed dynamically, and do not need to be remembered.
The current version of the cluster is named rice/wheat/oat plus a number. It lets us combine some originality in with automatic naming.
We’re already thinking about what to do for the next generation. And when we move all of the administrative systems (like the job schedulers) into VMs, we’re thinking of calling the underlying physical hardware quadrotriticale.
This is 1990, amazing awareness of what computers are capable of already.
i.e. the thing least likely to change. Which is almost always the physical location. eg. usa-sf-23
Of course then you do have to make sure to rename it if it gets moved.
What naming conventions do people use for storage devices? I recently created a zfs pool and ended up reusing the computer name, but it becomes a bit awkward to say you're opening foo on foo.
enterprise, voyager, relativity, defiant etc
Quite amusing except my internal dictionary of well-known pizza names had to be replaced by a linear lookup.
At that point the names become memorials and it's nice to ssh into them. The only glitch so far is it's difficult to decommission the roles.
This'll probably be changing soon...
1) not a real person, but a real family name paired with a common first name
https://en.wikipedia.org/wiki/List_of_named_minor_planets:_A
1,479 just in the letter A.
Laptop=sheila. Desktop=tex. Server=lopez. Names are recycled when the machine is replaced.
"useful" :)
Cirocco - from John Varley's Gaean trilogy
Lorelei - from the Styx song