5 ms·

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 perso

by staunch 13y ago

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: <customer> (joeinc, hn) <app> (cms, api) <role> (web, db, dns) <instance> (number of this type) <location> (lax1, nrt2) <environment> (prod, dev, qa, corp)

caw 13y ago
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.
- staunch 13y ago
  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.

by staunch 13y ago

caw 13y ago

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.

staunch 13y ago
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.