4 ms·

Cute hostnames are pretty obnoxious. My preferred method of building out datacenters is more self-documenting, and I've done it on 4 rack colo buildouts and 100

Cute hostnames are pretty obnoxious. My preferred method of building out datacenters is more self-documenting, and I've done it on 4 rack colo buildouts and 100 rack colo build-outs. I just use a naming format of Loc-Cabinet-Rackspace. In my Seattle datacenter I know that sea-c01-s1 is a server thats in my seattle datacenter, cabinet 1, slot 1. I know it's PDUs are plugged into port 1 of PDU-LEFT and PDU-RIGHT in that cabint. I know it's two ethernet ports are plugged into Port 1 sea-c01-sw-left and sea-c02-sw-right. I know it's LOM cable is plugged into port 1 of sea-c01-sw-mgmt. (I handle multi-U spaces by naming the server based on the bottom most rackspace it uses, and I stay consistent. If Sea-c01-s1 takes 10 rackspaces, then the server above it is sea-c01-s11. Beyond that, my configuration management tools tag spare resources when needed, and release them when unneeded. Cute hostnames are of no use to me, or anybody building out a datacenter that they'd like somebody else to be able to manage without months of knowledge dump.

chime 16y ago
What happens when you have to move a server for some reason? Has that never happened?
- spc476 16y ago
  My guess: logical names (like www or db or ns) are CNAMES, so that when the server moves and gets a new named based on location, the CNAME is adjusted as well.
  - andrewtj 16y ago
    Yep — exactly. To use software parlance, if using this convention would halt or inconvenience your production, it's a smell and a likely indication you've got a spaghetti setup on your hands.
  - gaius 16y ago
    You shouldn't need to rename a server when you move it, esp. since you might not know where its hostname is used (e.g. at least one major database vendor at software installation time embeds the hostname in various generated config files). Machines should have sequential names, services should be VIPs (or CNAMEs if you must) and everything else should be in a configuration management database.
- dnsworks 16y ago
  At least the way I like to build infrastructure, physical servers don't really matter. If for whatever reason servers had to get moved, their mac address would be updated to reflect it's location. I wrote some code a while back which grabs all the mac addresses from a switch and use that to map their physical location. It's quite simple, it looks at a port to see if it has multiple mac addresses behind it, if it does, it ignores it, if not, it maps that port out and labels it appropriately. There's also a little bit of logic to figure out what kind of a device a port is (whether it's another switch, a server, a pdu, etc), which also helps with my own personal continuing de-emphasis on the physicality of computing.

chime 16y ago

What happens when you have to move a server for some reason? Has that never happened?

spc476 16y ago
My guess: logical names (like www or db or ns) are CNAMES, so that when the server moves and gets a new named based on location, the CNAME is adjusted as well.
- andrewtj 16y ago
  Yep — exactly. To use software parlance, if using this convention would halt or inconvenience your production, it's a smell and a likely indication you've got a spaghetti setup on your hands.
- gaius 16y ago
  You shouldn't need to rename a server when you move it, esp. since you might not know where its hostname is used (e.g. at least one major database vendor at software installation time embeds the hostname in various generated config files). Machines should have sequential names, services should be VIPs (or CNAMEs if you must) and everything else should be in a configuration management database.
dnsworks 16y ago
At least the way I like to build infrastructure, physical servers don't really matter. If for whatever reason servers had to get moved, their mac address would be updated to reflect it's location. I wrote some code a while back which grabs all the mac addresses from a switch and use that to map their physical location. It's quite simple, it looks at a port to see if it has multiple mac addresses behind it, if it does, it ignores it, if not, it maps that port out and labels it appropriately. There's also a little bit of logic to figure out what kind of a device a port is (whether it's another switch, a server, a pdu, etc), which also helps with my own personal continuing de-emphasis on the physicality of computing.