The large companies I worked with typically use a combination of one or more of the following on the server names:
- abbreviated physical location (city/state/data center,availability zone/country)
- abbreviated environment (demo/test/dev/prod),
- server role (db/app/web)
- sequential number/letter
Examples:
ATLWEB301 (Atlanta Web 301)
DEMOVA050 (Demo Virginia 050)
NYCDB015 (New York City Database 015)
The standards vary significantly, specially depending if you are talking about internal / public servers. The length also varies but most people try to stay below 15 a-z characters. I personally like to give servers more generic names and not have to worry too much about it. Ex: ATLDEMO001, DENPROD014...
If the servers are public (I mean accessible via internet) most companies refrain from using any information on the server name that could facilitate a potential attack. For example: putting DB on the name of a database server.
Small companies, on the other hand, have a lot more variety. I have worked on servers named after Lord of the Rings and Simpson characters, Greek mythology gods, etc... I had a frodo mysql server that gave me a lot of trouble.
For servers:
3 letter abbreviation for location, first number indicating the iteration of the datacenter in that area, Second number is the floor of the building the system is at, hyphen, row number of the cabinet the system is in, Iteration of the cabinet in the row, hyphen, lowest rack unit the server is located in.
eg: chi18-018-23
chicago datacenter 1, floor 8, row 0, cabinet 18, rack unit 23
For switches, simply:
as018-1.chi18 for an aggregation switch, int018-1.chi18 for an internal network switch, ipmi018-1.chi18 for an IPMI switch, And if you have more than switch for a purpose in that cabinet, then the name is 'as018-2.chi18'
The systems are almost always connected to a switch that's in the same cabinet. Though, we keep every system documented in our inventory system, with it's specs, IP addresses, switch ports, and power outlets. System also provides bandwidth graphs from every switch, and if a server as well as ipmi are ever inaccessible, we can remotely control the PDU & Outlet as well. Though, we always have employees onsite at each datacenter to check the console & hardware.
1] If you can visit a local telco wire office, go do so; especially with all these questions in mind. Telcos have dealt with this problem way before most of us were born.
2] Use DNS's hierarchical nature to your advantage, e.g.
3] Your network design perspective will impact how you approach naming, so be careful you don't cement with names something where the design will change, and then your names no longer make sense.
We use stuff from the kids TV show Knightmare. So our app servers are called treguard, merlin, mogdred, hordriss, database server is called knapsack, etc.
I had that once, but it was a compute cluster. They used scientific terms for all the other servers. All the better if it matched up with the service, like diffusion and effusion for the firewall failover pair.
Despite the heated arguments people have about this it really doesn't matter that much. There are pros and cons to any choice, and it's mostly a matter of personal preference.
If you're going to have < 50 servers you can very easily use cute names and it will probably never bite you. In fact, it's somewhat easier. Humans are pretty good with people-like names. Servers named with friendly names take on special characteristics in your head.
If you're going to have 1000+ servers then it's just not practical to come up with names manually. But you'll also probably just have large numbers of the same kind of server. You could have servers named gary1 - gary434 and a standard that says "gary servers run XYZ service(s)".
But, generally people encode some info in the hostname. Things like xweb23prodlax2 could be "external web server 23 in Los Angeles datacenter 2", so that's <role><instance><environment><datacenter>. If you're going to run multiple different app stacks you might also use an <app>. So hnxweb23prodlax2 might be "Hacker News' 23rd web server in LA" I don't recommend zero padding numbers (01 vs 1), since it looks bad when you break the padding's length.
You may want to separate components by hyphens (which are fine in hostnames). Don't worry about keeping them under 8 chars or anything, nothing modern breaks on reasonably long hostnames. You can also use sub-domains for parts that make sense.
hn-web-23-prod-lax2 isn't bad, and it's easy to parse reliably.
hn-web-23.prod.lax2.yourdomain.tld works as well (but makes your short hostname not globally unique, which probably doesn't matter).
Naming locations based on the nearest and largest airport code tends to work well. Including a number in the location is a good idea, since you may end up with more than one datacenter in a location.
I don't like putting actual software names in hostnames. So I'd never name a server mysql5lax2. I'd use "db" not "mysql". You might swap it out for Postgres or something, so the role is what's important.
I highly recommend not using IPs for hostnames (the way EC2 does). It might work for EC2 where they're committed to never changing things, but you're probably going to have at least one server change IPs at some point, the hostname shouldn't change when that happens. Same thing with putting rack #s in or other things that are likely to change (unless you absolutely know they won't).
You should use DNS (via CNAME records) to get pretty names. For example git.yourdomain.tld might be a CNAME for repo-1-corp-lax2.yourdomain.tld.
An incomplete list of things you might encode in the hostname:
I work at a site with >1k hosts right now, and globally there's >>1k hosts.
One thing that wasn't mentioned was the site code. For multi site installation it helps to know whether your host is in site 1 or site 2 without referring to the fully qualified domain name. At the last 2 jobs I worked for we also encoded VM status into it (generally add an extra V or VM into the name).
> I don't recommend zero padding numbers (01 vs 1), since it looks bad when you break the padding's length.
We totally zero pad, though our zero padding has a buffer. Otherwise, you break string sort, which is more important to us. So if you will never have more than 99 cron machines, use the 01. If you're going to have more than 100 but less than 999, use 001. So on and so forth.
We also reuse numbers after hosts end of life, though it's not immediate reuse (that would be confusing as heck). When you buy servers by the rack it doesn't matter what your numbering scheme is, you'll end up going through all the possible values.
So how do you track all these hosts when there's minimal information encoded? By database. Our host database tracks physical location, owners, after hour contacts, roles (e.g. the mysql vs postgres part), OS install images, etc.
You need some kind of server database no matter what your naming scheme. This is why I say hostnames really aren't as important as people pretend they are.
Sorting hostnames as strings tends to not be as useful/common as it seems, in my experience. In your DB you can sort based on the parsed numeric version. I've just come to dislike varying padding (01 vs 001 on some servers) or breaking the padding (001 becoming 1234). But, as I said, it's all mostly personal preference.
Examples: ATLWEB301 (Atlanta Web 301) DEMOVA050 (Demo Virginia 050) NYCDB015 (New York City Database 015)
The standards vary significantly, specially depending if you are talking about internal / public servers. The length also varies but most people try to stay below 15 a-z characters. I personally like to give servers more generic names and not have to worry too much about it. Ex: ATLDEMO001, DENPROD014...
If the servers are public (I mean accessible via internet) most companies refrain from using any information on the server name that could facilitate a potential attack. For example: putting DB on the name of a database server.
Small companies, on the other hand, have a lot more variety. I have worked on servers named after Lord of the Rings and Simpson characters, Greek mythology gods, etc... I had a frodo mysql server that gave me a lot of trouble.