5 ms·

Sounds fun if you do it for your home network, but profesionally you'll quickly appreciate embracing a more dull pattern of calling database machines db01, db02

by wulczer 16y ago

Sounds fun if you do it for your home network, but profesionally you'll quickly appreciate embracing a more dull pattern of calling database machines db01, db02, etc, preproduction machines preprod01, preprod02, etc. And the sysadmin that will come after you will appreciate it even more.

davidu 16y ago
Yep, you are basically making a new requirement that hires have to be Starcraft experts; and if not, then your naming scheme is totally unintuitive and overly verbose. I'm a big fan of the function###.IATA (or ICAO) code. So like db1.pao, web3.sfo, m22.sin... I don't do the 01 02 thing because that falls down at 99. :-)
- wulczer 16y ago
  Yeah, now that I think of it I can't remember why I'm doing the 01 thing. Must be residual from my previous job where we used this pattern. I remember reading through the Bind file and seeing # >10k machines? NEVER! streamer0001.xxx...
  - barrkel 16y ago
    The primary reason for using 01 vs 1 etc. is because it sorts better without having to use fiddly sort options.
elliottcarlson 16y ago
We (correction, I) keep dual names on all our machines. First the descriptive name lb01, websrv01, db01, etc. The second is the informal name all based on constellations and other space based entities like earth, star, taurus, corvus, leo, etc. Via Puppet[1], the MOTD of each server is generated with figlet[2] and other information so that the machine can be identified using all of it's names. Most likely it's overkill - but I do like my pretty names as well. [1] http://www.puppetlabs.com/ http://www.puppetlabs.com/ [2] http://www.figlet.org/ http://www.figlet.org/
tesseract 16y ago
That's nice if you never repurpose a machine - so it makes plenty of sense for naming VMs. I've found it better to use arbitrary names for physical machines, though. Thanks to the prevalence of pop-culture fandoms on the internet it's pretty easy to find a list of names related to just about any theme you might desire, then when you get a machine you can just pop the next name from the list.
jarin 16y ago
I'm sure CloudFlare uses "boring" names internally, but I was kind of nicely surprised that their DNS nameservers are named amy.cloudflare.com, paul.cloudflare.com, etc. For some reason it just gave me a little tiny bit of excitement to get started on their service that wouldn't have been there if they were named the standard ns1., ns2., etc., and when you're just choosing from a random pool of DNS servers it doesn't really matter what the names are from an organization standpoint.
- eastdakota 16y ago
  Glad you like the non-boring names for nameservers. There's actually method to why we use them and not boring names. There are 101 of names (50 women, 51 men) all between 2 - 4 letters long (Ed, Sara, John, etc.). They actually map to globally distributed clusters of servers, so each name doesn't correspond to a physical server in a single location. Instead of mapping to a physical server, we use the unique names to help verify you are the true owner of a domain you sign up in a way that is similar to how Google Apps uses a TXT record you add to your DNS to show you own a domain. When you sign up for CloudFlare we provide you two unique nameservers when you sign up as part of the verification process. We can tell you are the owner of the domain you're registering if you change the nameservers to the two we provide you. In that way, it adds a layer of security in case two people register the exact same domain at the same time and we can't tell who should be authoritative. We figured that it was easier to remember and not typo two names rather than two random numbers (ns23 & ns67). We commissioned an artist to draw 101 ninjas to represent CloudFlare's "Ninja nameservers." You can read more about them on the CloudFlare blog, including links to the Facebook page with all 101 illustrations: http://blog.cloudflare.com/introducing-igor-alex-phil-isla-and-vera-five http://blog.cloudflare.com/introducing-igor-alex-phil-isla-a...
  - jarin 16y ago
    Ah, that is brilliant. Definitely way easier to work with than random numbers and/or TXT records.
bdb 16y ago
Which falls over when db01 ain't a database machine anymore. When I ran a large network, machines didn't physically move very much (at least, far less often than their logical functions changed); we had a naming scheme based on datacenter code, rack ID and rack position: sjc02-X0501-19 would be the machine in sjc02, rack X05.01, unit 19. Far more important than the actual scheme you use is consistency. Pick one scheme and stick with it. Easier when you pick the right scheme the first time. :)
- jswanson 16y ago
  That's great for SA's who are working in the racks. Not so great for SA's that are administering the boxes remotely, devs trying to figure out what machine they are on, or teams trying to troubleshoot an issue. If a box is no longer a db machine, just rename it to something descriptive.
didip 16y ago
For Xen instances I like dull and boring names because they are destroyable (easily). For physical hardware, fancy names sounds pretty good, examples: * group of mountains -> db servers * group of bridges -> web services * group of cities -> app servers (Kinda fun to say "Portland is down!")

by wulczer 16y ago

davidu 16y ago

Yep, you are basically making a new requirement that hires have to be Starcraft experts; and if not, then your naming scheme is totally unintuitive and overly verbose. I'm a big fan of the function###.IATA (or ICAO) code. So like db1.pao, web3.sfo, m22.sin... I don't do the 01 02 thing because that falls down at 99. :-)

wulczer 16y ago
Yeah, now that I think of it I can't remember why I'm doing the 01 thing. Must be residual from my previous job where we used this pattern. I remember reading through the Bind file and seeing # >10k machines? NEVER! streamer0001.xxx...
- barrkel 16y ago
  The primary reason for using 01 vs 1 etc. is because it sorts better without having to use fiddly sort options.

elliottcarlson 16y ago

We (correction, I) keep dual names on all our machines. First the descriptive name lb01, websrv01, db01, etc. The second is the informal name all based on constellations and other space based entities like earth, star, taurus, corvus, leo, etc. Via Puppet[1], the MOTD of each server is generated with figlet[2] and other information so that the machine can be identified using all of it's names. Most likely it's overkill - but I do like my pretty names as well. [1] http://www.puppetlabs.com/ http://www.puppetlabs.com/ [2] http://www.figlet.org/ http://www.figlet.org/

tesseract 16y ago

That's nice if you never repurpose a machine - so it makes plenty of sense for naming VMs. I've found it better to use arbitrary names for physical machines, though. Thanks to the prevalence of pop-culture fandoms on the internet it's pretty easy to find a list of names related to just about any theme you might desire, then when you get a machine you can just pop the next name from the list.

jarin 16y ago

I'm sure CloudFlare uses "boring" names internally, but I was kind of nicely surprised that their DNS nameservers are named amy.cloudflare.com, paul.cloudflare.com, etc. For some reason it just gave me a little tiny bit of excitement to get started on their service that wouldn't have been there if they were named the standard ns1., ns2., etc., and when you're just choosing from a random pool of DNS servers it doesn't really matter what the names are from an organization standpoint.

eastdakota 16y ago
Glad you like the non-boring names for nameservers. There's actually method to why we use them and not boring names. There are 101 of names (50 women, 51 men) all between 2 - 4 letters long (Ed, Sara, John, etc.). They actually map to globally distributed clusters of servers, so each name doesn't correspond to a physical server in a single location. Instead of mapping to a physical server, we use the unique names to help verify you are the true owner of a domain you sign up in a way that is similar to how Google Apps uses a TXT record you add to your DNS to show you own a domain. When you sign up for CloudFlare we provide you two unique nameservers when you sign up as part of the verification process. We can tell you are the owner of the domain you're registering if you change the nameservers to the two we provide you. In that way, it adds a layer of security in case two people register the exact same domain at the same time and we can't tell who should be authoritative. We figured that it was easier to remember and not typo two names rather than two random numbers (ns23 & ns67). We commissioned an artist to draw 101 ninjas to represent CloudFlare's "Ninja nameservers." You can read more about them on the CloudFlare blog, including links to the Facebook page with all 101 illustrations: http://blog.cloudflare.com/introducing-igor-alex-phil-isla-and-vera-five http://blog.cloudflare.com/introducing-igor-alex-phil-isla-a...
- jarin 16y ago
  Ah, that is brilliant. Definitely way easier to work with than random numbers and/or TXT records.

bdb 16y ago

Which falls over when db01 ain't a database machine anymore. When I ran a large network, machines didn't physically move very much (at least, far less often than their logical functions changed); we had a naming scheme based on datacenter code, rack ID and rack position: sjc02-X0501-19 would be the machine in sjc02, rack X05.01, unit 19. Far more important than the actual scheme you use is consistency. Pick one scheme and stick with it. Easier when you pick the right scheme the first time. :)

jswanson 16y ago
That's great for SA's who are working in the racks. Not so great for SA's that are administering the boxes remotely, devs trying to figure out what machine they are on, or teams trying to troubleshoot an issue. If a box is no longer a db machine, just rename it to something descriptive.

didip 16y ago

For Xen instances I like dull and boring names because they are destroyable (easily). For physical hardware, fancy names sounds pretty good, examples: * group of mountains -> db servers * group of bridges -> web services * group of cities -> app servers (Kinda fun to say "Portland is down!")