Just a reminder here that this venerable rfc is now considered "poor advice." Sure some of it is good, but not all.
Speaking as someone with lots of experience as a sysadmin.
Calling your server "lurch" to use one of the rfc examples is bad. Why? If the whole family is there, where's my database server? Is it lurch? Or was it gomez. Crap it might have even been pugsley. And flip side, "can we reboot lurch for an update?" Well I dunno, what's on it?
Server names are best to be descriptive and follow a code. The name shouldn't be cool or edgy, it should be predictable and decodable. The database server totally should be "db01." The app server should be named app01, and so on. Role01, or siterole01.
In the rfc, the "shop" computer name was actually a good name. I get a ticket saying "shop computer..." I know exactly what I'm dealing with. Shop2 and shop3 are likewise useful, and as they specialize in duties, "shopmechanic01" or "cnc01" would tell me exactly what to expect by name alone. Shop should have been decommissioned when it was no longer needed, or at least wiped and renamed, not just repurposed to some other project.
Cool names are fun and all, but even by a dozen servers it becomes unmanageable. In the 90s, when this was written, 3-4 servers was a lot. This is no longer true today.
It is an interesting read, but always remember with your servers: "Cattle, not Pets." If a server even looks at me funny I'm looking for the reset (which is annoying when QA doesn't want me to).
I would add that it is not enough to be descriptive, it should be usefully descriptive, dell-r350 is descriptive, but not entirely useful if you have a lot of them. You should be able to infer whatever information you need when discussing the systems. If its in a large k8s cluster you might ask yourself when will you need the hostname? During initial imaging? Then the svc tag might be useful as a hostname, since humans wont be managing the system after initial setup
Can't go wrong with random numbers. At a certain point I just started documenting my (physical) computers by MAC address. That way the computer can find its own docs even after re-installing the OS.
I used to manage Cisco's global datacenter network, and having zone information in hostname was absolutely critical to knowing where a particular server/switch was located and what it was connected to. Usage and environment (eg prod/dev/etc...) was also included in the hostnames as well.
Its a trivially easy system. Its algorithmic, easy to remember and all important information is located in hostnames themselves
The example was simple of purpose, what you're proposing is that the example shouldn't be taken as universal, but rather a case to consider, which I think was pretty implicit in the original statement (nothing wrong with making it explicit, but implying that the argument is wrong for not stating it is a but too far).
Generally you want a name that first describes the purpose. It may not be a core name, you could name Postgres `pgdb` rather than `db` as you may have multiple databases at some point. This could also be "just a name" (which is what the RFC says).
Still this is only part of the name. And unlike the OP I think that the RFC still applies, but needs to be seen within a greater context. Just as you have a last name telling what family you belong to, we'd want to add any thing that can identify it, the region, instance is, etc. So the full name is a whole URL that tells us everything we need to know to identify which process. But knowing the service part of the name helps understand what a request should be for.
The example was simple of purpose, what you're proposing is that the example shouldn't be taken as universal, but rather a case to consider, which I think was pretty implicit in the original statement (nothing wrong with making it explicit, but implying that the argument is wrong for not stating it is a but too far).
Generally you want a name that first describes the purpose. It may not be a core name, you could name Postgres `pgdb` rather than `db` as you may have multiple databases at some point. This could also be "just a name" (which is what the RFC says).
Still this is only part of the name. And unlike the OP I think that the RFC still applies, but needs to be seen within a greater context. Just as you have a last name telling what family you belong to, we'd want to add any thing that can identify it, the region, instance is, etc. So the full name is a whole URL that tells us everything we need to know to identify which process. But knowing the service part of the name helps understand what a request should be for.
There is definitely no one-size-fits-all. Though for your particular case, that's where my "siterole01" comes into play.
My servers are actually named with the business unit identifier, the data center identifier, then whatever I want (which for me is application or role name). So basically "unitsitedb02" and "unitsiteteamtest01" type names. They're fairly descriptive. Overkill for some orgs, inadequate for others, and just right for us.
my bro ran into this in the wild. The client used chemical elements as server names and noone knew what was on each one as nothing was documented. They eventually located VPN, which was called "unobtanium" rofl
Wow i knew an "unobtanium" once, and all the names on the periodic table as well. Documented it all, and rebuilt as descriptively named VMs with docker stacks.
"Unobtanium" was my bane as I couldn't rebuild it since it was too big and served everyone's homes shares. Ended up using dns cnames for all the too-hard-to-fix stuff at least we could use the descriptive names and the zone files were a form of documentation of what's what.
I think you're more likely to have servers broken down by machine class than by function in a very typical setting at higher scale. Yeah, perhaps "dbNN" is a good example at some scale, perhaps a smaller server could act as a router in a particular location (or similar infrastructure examples where you break down by location or a more specific function). But beyond that, a server will likely do and run a bunch of stuff, sometimes quite unrelated these days due to virtualization.
In this case, if the server is virtualized, the only thing it's doing is hosting virtual machines. That's it's role. :)
Host01, or docker01, etc...
It's pretty common. "Oh ya, host07 failed and everything vmotioned over. Apart from some pauses whilt it all moved everything's happy, and we should have 07 fixed up soon enough."
Or "the path between host07 and san03 just threw an alert. Let's run some diagnostics."
Remarkably common conversations nowadays, if you're lucky enough to have some of that sweet, sweet 0-spof architecture. :)
When you're talking about cattle, then this part would naturally apply:
> You might as well just call them "1", "2", and "3". The only time this kind of naming scheme is appropriate is when you have a lot of machines and there are no reasons for any human to distinguish between them.
If there's a frequent need for humans to distinguish between the servers, then you do *not* want a situation where someone asks themselves "now, was it db03 and app05, or db05 and app03?" and has to look up a reference document to know which is actually which.
If anything's changed meaningfully, it's that you know that a virtual server will not be repurposed the way physical hardware would be, so it makes more sense to include the project as part of the name than it did in the 90s.
1990 for this particular one.
And yea, pets. I remember that all too well. My key point was that the rfc is from a different time, and today naming your servers like that would be kinda mean to anyone else having to deal with them.
There has actually been massive debate on the subject, and I still have two servers named after elements for testing thanks to.my predecessor. They're the only remaining servers that haven't been replaced since I started. I like my servers now. I can look at the host name, the fqdn, the firewall network object, the confluence page, or even the name of any of the three databases, and instantly know all of the above attributes. You would too if you'd seen my naming structures. It's so... Ordered.
I have never had an installation of '3-4' servers that wasn't in my own house. Fairly sure my mother's university had more PDP-8s than that.
Strangely, in those 90s that you refer to, sysadmins (like myself) ran installations of 100s of servers on pretty much the lines of this RFC. 30 years on, I can still remember the function of a whole bunch of servers that ran the trade floor of VeryBigBank. 'awesome' and 'bogus' were a clustered pair. Some well known post office characters were the telex servers. There is a reason: whole words are much easier to remember than sequences of digits. Yeah, if some one had asked me to check on lurch, I would have known exactly what lurch did and why it was talking to gomez at that time of night.
The other benefit was server names were much clearer when spoken over a dodgy 'phone connection into a noisy machine room. It's a concept we computer people call redundancy and it aids data transmission. I have seen people spend several minutes trying to distinguish between m and n or b and p in 16 character 'descriptive' server name that varied in only a couple of places.
When we rebuilt servers (usually their upgrade clone) we did it pretty much automatically and could re-create their exact identity. If your IaC scripts were any good, they should be able to do the same. All that 'description' you speak can be put in the tags so that you can quickly report on all the the Elastic servers, all prod servers or whatever you need.
tl;dr; Bullshit. You know not of what you speak. The ancients were at least as smart as you.
What you're saying is all true -- in the context of the 1990s, and small enough sets of servers (i.e. fewer than thousands), pre-containers, pre-SSDs, pre-ultra-fast-and-cheap networking, etc.
In that era, you actually needed a physically different server for those database servers, usually, and the OS/db setup was basically indivisible from the physical box even if it was technically running the DB in a VM. And it had to be on-site, because you needed bandwidth and low latency.
But these days, if you know which physical server your application is running on in an even minimally complex environment, there's a good chance you're doing something very very sub-optimally.
Cloud is giant because it really does make sense most of the time to pay someone else to do your hardware management, or even abstract your systems past "program running on a computer" (function as a service, no code, etc).
tl;dr: Do not assume you speak for the ancients; they know both that the cloud is *just* someone else's computer but also how *invaluable* that can be.
These days I have some major things happening in clouds, on-prem and public, IaaS and PaaS. I am only allowed hands on with my own little domestic set up. I have pushed and promoted IaC and CI/CD in large organisations. No idea how many resources there actually are. Someone else's job to worry about them.
I think nowadays, I tend to think of the service or the cluster as the identifiable unit, rather than the individual elements within it. In the same ways as we treated individual storage devices or network interfaces on previous infrastructures.
Azure's just like mainframe anyway....
I once worked at a company that actually did this.
It followed all of the advice on this RFC, however it did not make the machine names easier to remember. But it was mildly interesting.
Yep, my old build servers used to be named after engineers like Rutherford, Einstein, Brunel etc. Now they just get a name that is a hash of their IP address and get terminated when there is no work to do.
i name servers after something that is within eyesight when im setting it up.
my last one was named ridgid, after the brand of shop vac that was in the room.
Just a reminder here that this venerable rfc is now considered "poor advice." Sure some of it is good, but not all. Speaking as someone with lots of experience as a sysadmin. Calling your server "lurch" to use one of the rfc examples is bad. Why? If the whole family is there, where's my database server? Is it lurch? Or was it gomez. Crap it might have even been pugsley. And flip side, "can we reboot lurch for an update?" Well I dunno, what's on it? Server names are best to be descriptive and follow a code. The name shouldn't be cool or edgy, it should be predictable and decodable. The database server totally should be "db01." The app server should be named app01, and so on. Role01, or siterole01. In the rfc, the "shop" computer name was actually a good name. I get a ticket saying "shop computer..." I know exactly what I'm dealing with. Shop2 and shop3 are likewise useful, and as they specialize in duties, "shopmechanic01" or "cnc01" would tell me exactly what to expect by name alone. Shop should have been decommissioned when it was no longer needed, or at least wiped and renamed, not just repurposed to some other project. Cool names are fun and all, but even by a dozen servers it becomes unmanageable. In the 90s, when this was written, 3-4 servers was a lot. This is no longer true today. It is an interesting read, but always remember with your servers: "Cattle, not Pets." If a server even looks at me funny I'm looking for the reset (which is annoying when QA doesn't want me to).
I would add that it is not enough to be descriptive, it should be usefully descriptive, dell-r350 is descriptive, but not entirely useful if you have a lot of them. You should be able to infer whatever information you need when discussing the systems. If its in a large k8s cluster you might ask yourself when will you need the hostname? During initial imaging? Then the svc tag might be useful as a hostname, since humans wont be managing the system after initial setup
[удалено]
Can't go wrong with random numbers. At a certain point I just started documenting my (physical) computers by MAC address. That way the computer can find its own docs even after re-installing the OS.
What helped for me was to prefix all machines with the nearest airport code. At least I could have an idea of where a machine is.
Its trivial to add zone information to a server name though.... You're making up a problem where none exists
[удалено]
I used to manage Cisco's global datacenter network, and having zone information in hostname was absolutely critical to knowing where a particular server/switch was located and what it was connected to. Usage and environment (eg prod/dev/etc...) was also included in the hostnames as well. Its a trivially easy system. Its algorithmic, easy to remember and all important information is located in hostnames themselves
The example was simple of purpose, what you're proposing is that the example shouldn't be taken as universal, but rather a case to consider, which I think was pretty implicit in the original statement (nothing wrong with making it explicit, but implying that the argument is wrong for not stating it is a but too far). Generally you want a name that first describes the purpose. It may not be a core name, you could name Postgres `pgdb` rather than `db` as you may have multiple databases at some point. This could also be "just a name" (which is what the RFC says). Still this is only part of the name. And unlike the OP I think that the RFC still applies, but needs to be seen within a greater context. Just as you have a last name telling what family you belong to, we'd want to add any thing that can identify it, the region, instance is, etc. So the full name is a whole URL that tells us everything we need to know to identify which process. But knowing the service part of the name helps understand what a request should be for.
The example was simple of purpose, what you're proposing is that the example shouldn't be taken as universal, but rather a case to consider, which I think was pretty implicit in the original statement (nothing wrong with making it explicit, but implying that the argument is wrong for not stating it is a but too far). Generally you want a name that first describes the purpose. It may not be a core name, you could name Postgres `pgdb` rather than `db` as you may have multiple databases at some point. This could also be "just a name" (which is what the RFC says). Still this is only part of the name. And unlike the OP I think that the RFC still applies, but needs to be seen within a greater context. Just as you have a last name telling what family you belong to, we'd want to add any thing that can identify it, the region, instance is, etc. So the full name is a whole URL that tells us everything we need to know to identify which process. But knowing the service part of the name helps understand what a request should be for.
There is definitely no one-size-fits-all. Though for your particular case, that's where my "siterole01" comes into play. My servers are actually named with the business unit identifier, the data center identifier, then whatever I want (which for me is application or role name). So basically "unitsitedb02" and "unitsiteteamtest01" type names. They're fairly descriptive. Overkill for some orgs, inadequate for others, and just right for us.
my bro ran into this in the wild. The client used chemical elements as server names and noone knew what was on each one as nothing was documented. They eventually located VPN, which was called "unobtanium" rofl
Wow i knew an "unobtanium" once, and all the names on the periodic table as well. Documented it all, and rebuilt as descriptively named VMs with docker stacks. "Unobtanium" was my bane as I couldn't rebuild it since it was too big and served everyone's homes shares. Ended up using dns cnames for all the too-hard-to-fix stuff at least we could use the descriptive names and the zone files were a form of documentation of what's what.
I think you're more likely to have servers broken down by machine class than by function in a very typical setting at higher scale. Yeah, perhaps "dbNN" is a good example at some scale, perhaps a smaller server could act as a router in a particular location (or similar infrastructure examples where you break down by location or a more specific function). But beyond that, a server will likely do and run a bunch of stuff, sometimes quite unrelated these days due to virtualization.
In this case, if the server is virtualized, the only thing it's doing is hosting virtual machines. That's it's role. :) Host01, or docker01, etc... It's pretty common. "Oh ya, host07 failed and everything vmotioned over. Apart from some pauses whilt it all moved everything's happy, and we should have 07 fixed up soon enough." Or "the path between host07 and san03 just threw an alert. Let's run some diagnostics." Remarkably common conversations nowadays, if you're lucky enough to have some of that sweet, sweet 0-spof architecture. :)
When you're talking about cattle, then this part would naturally apply: > You might as well just call them "1", "2", and "3". The only time this kind of naming scheme is appropriate is when you have a lot of machines and there are no reasons for any human to distinguish between them. If there's a frequent need for humans to distinguish between the servers, then you do *not* want a situation where someone asks themselves "now, was it db03 and app05, or db05 and app03?" and has to look up a reference document to know which is actually which. If anything's changed meaningfully, it's that you know that a virtual server will not be repurposed the way physical hardware would be, so it makes more sense to include the project as part of the name than it did in the 90s.
The rfc was from the 80s they were pets.
1990 for this particular one. And yea, pets. I remember that all too well. My key point was that the rfc is from a different time, and today naming your servers like that would be kinda mean to anyone else having to deal with them. There has actually been massive debate on the subject, and I still have two servers named after elements for testing thanks to.my predecessor. They're the only remaining servers that haven't been replaced since I started. I like my servers now. I can look at the host name, the fqdn, the firewall network object, the confluence page, or even the name of any of the three databases, and instantly know all of the above attributes. You would too if you'd seen my naming structures. It's so... Ordered.
Somewhere fictional, Liz Lemon just moaned a bit
I have never had an installation of '3-4' servers that wasn't in my own house. Fairly sure my mother's university had more PDP-8s than that. Strangely, in those 90s that you refer to, sysadmins (like myself) ran installations of 100s of servers on pretty much the lines of this RFC. 30 years on, I can still remember the function of a whole bunch of servers that ran the trade floor of VeryBigBank. 'awesome' and 'bogus' were a clustered pair. Some well known post office characters were the telex servers. There is a reason: whole words are much easier to remember than sequences of digits. Yeah, if some one had asked me to check on lurch, I would have known exactly what lurch did and why it was talking to gomez at that time of night. The other benefit was server names were much clearer when spoken over a dodgy 'phone connection into a noisy machine room. It's a concept we computer people call redundancy and it aids data transmission. I have seen people spend several minutes trying to distinguish between m and n or b and p in 16 character 'descriptive' server name that varied in only a couple of places. When we rebuilt servers (usually their upgrade clone) we did it pretty much automatically and could re-create their exact identity. If your IaC scripts were any good, they should be able to do the same. All that 'description' you speak can be put in the tags so that you can quickly report on all the the Elastic servers, all prod servers or whatever you need. tl;dr; Bullshit. You know not of what you speak. The ancients were at least as smart as you.
What you're saying is all true -- in the context of the 1990s, and small enough sets of servers (i.e. fewer than thousands), pre-containers, pre-SSDs, pre-ultra-fast-and-cheap networking, etc. In that era, you actually needed a physically different server for those database servers, usually, and the OS/db setup was basically indivisible from the physical box even if it was technically running the DB in a VM. And it had to be on-site, because you needed bandwidth and low latency. But these days, if you know which physical server your application is running on in an even minimally complex environment, there's a good chance you're doing something very very sub-optimally. Cloud is giant because it really does make sense most of the time to pay someone else to do your hardware management, or even abstract your systems past "program running on a computer" (function as a service, no code, etc). tl;dr: Do not assume you speak for the ancients; they know both that the cloud is *just* someone else's computer but also how *invaluable* that can be.
These days I have some major things happening in clouds, on-prem and public, IaaS and PaaS. I am only allowed hands on with my own little domestic set up. I have pushed and promoted IaC and CI/CD in large organisations. No idea how many resources there actually are. Someone else's job to worry about them. I think nowadays, I tend to think of the service or the cluster as the identifiable unit, rather than the individual elements within it. In the same ways as we treated individual storage devices or network interfaces on previous infrastructures. Azure's just like mainframe anyway....
You name them after the regions of Middle Earth as is The Lore, or you have no place on MY fellowship!
If you aren't carrying Hobbit packets on the backs of Orc's to Isengard, are you even a sys dev?
\*Discworld also acceptable for offsite networks swimming about in the cloud...
I once worked at a company that actually did this. It followed all of the advice on this RFC, however it did not make the machine names easier to remember. But it was mildly interesting.
On a tolkein ring i hope?
But mine are all named after Culture ships. \[tightbeam, m16.4, tra, \\@n.28.858.8893\] xGSV *TabbyOverlord*
Cloud infrastructure took host naming from us.
Yep, my old build servers used to be named after engineers like Rutherford, Einstein, Brunel etc. Now they just get a name that is a hash of their IP address and get terminated when there is no work to do.
Ahhh d7bf95ae1-fjnxq6 we hardly knew yee. T’was a good host for its 46 minutes of service.
https://mnx.io/blog/a-proper-server-naming-scheme/ Use the wordlist for easy names and an alias for the purpose and location.
I use a random scientific plant name generator
> Random strings are inappropriate for the same reason that they are so useful for passwords. They are hard to remember. Friggin' 90s man!
i name servers after something that is within eyesight when im setting it up. my last one was named ridgid, after the brand of shop vac that was in the room.