June 21, 2010 at 05:02Network Naming
I want to raise a question that, it seems to me, no one has previously considered systematically. The question is:
To begin, I will outline the essence of the problem: when you have 2-3-5-10 servers, then their names, addresses, etc. you quickly remember, and they do not cause much confusion. But if you have several thousand servers (let's add virtual ones to the real ones), if your router has several hundred real or virtual (in vilanas) interfaces, each of which needs to be given a name (at least for PTR / A records in DNS), when you have interfaces for configuring switches, print servers, network printers ... In these conditions, you really need to sit down and think what to call them. It’s better to sit down to think before they start calling, than after.
First, consider the simple solutions that come to mind first.
For example, by the elements of the periodic table (who did the trail to Yandex, saw). Enough for a hundred with a small name. Then it will be interesting to read in the logs that Helium reject mail from potassium. Plus, there is a ready-made set of abbreviations for short aliases, and it is unique. Similarly, you can select, for example, countries. Or cities. Or some other set with names.
The downside of this is understandable: looking at the server name it is impossible to understand what it is doing. Plus - the names are clear, memorable, distinguishable. It is clear that we will never confuse calcium with potassium. Never.
For example, fsbk3333, fsbk32232 ... Quite a name. If the servers are homogeneous. And if not? Remember that “333” is the mail server, and 5622 is the out-of-band interface of the backup vpn gateway ... Maybe it is better over IP right away?
mail.domain, gateway.domain, vpn.domain, radius.domain, databases.domain, printer.domain, etc. The plus is an accurate understanding of what each server does. The downside is some confusion with a mixed functional (why does your router connect to the radius of the mail.domain server? Ah, do you have a radius server there? And why the name "mail"?)
Next, there is a need for numbering, and an explicit desire to shorten the name , because webserver23 will get tired of typing every time.
An even bigger problem will be the division into departments, floors, buildings, cities, firms, etc. To find out that webserver12 is a server with presides for workstations in the administration building in Perm, and webserver22 is an intraweb server with corporate CMS in the head office. Yes, and print such names is also hard.
There is nothing more distinctive and unambiguous than OU = MSK, OU = "Main Branch", OU = labs, CN = "intranet web server" ... Especially if it is printed by hand every time. Plus, it is not very compatible with DNS. Unless you print "intranet-web-server.labs.mainbranch.msk.our_domain" each time.
We now turn to the consideration of the problem in a general way.
General requirements:
Specific Requirements:
It is clear that specific requirements can be expanded in the first place (for example, in the case of complex administrative organization of the network, the coding of administrative subordination itself can be very, very difficult, for example, when it comes to ... a “group of companies”, with units in relative autonomy; similarly, we can talk about other fields - geographical, functional ...)
It is also clear that, depending on the type of organization, some fields may not be in demand. For example, a geographical or administrative part.
However, in the general case, we can dwell on the above list.
Now the following two questions: what size should each part be; How should these parts be separated? And the third question: can the parts of the name have different lengths or should they be strictly fixed?
Let's start with the length: the database fits into 'db', and the terminal server into 'ts', then encoding in two letters, for example, 'backup', is already a little complicated, you get an arbitrary uncommon abbreviation that may overlap with other abbreviations. The same applies to geographical names. Suppose you have branches on each of the lines of Vasilievsky Island. Suppose you encode them in two letters. l4 is the fourth line, l8 is the eighth line ... And how is the 17th line? And tomorrow you will have branches at the Moscow Gate, Moskovskaya metro stations, another branch just at Moskovsky and another branch in Moscow. To drive oneself into a Procrustean bed of a rigid length of a name, IMHO, is not reasonable.
Next, what should the names be? Obviously: the smallest possible, but in the "natural" reduction. Even if you do not have other branches on “m”, to reduce Moscow to “m” (instead of msk) is to reduce the mnemonics and readability of the name.
In principle, it is quite simple, because the art of abbreviations for geographical names has long been mastered and is publicly known. Two-letter state codes in the USA, three-letter city names in Russia (from geographic domains), two-letter country codes (from ISO) ... Street names may also be abbreviated, although you will have to show some ingenuity here (see the example above about the lines of Vasilyevsky Island).
The issue of administrative subordination is a little more complicated. The full name of the department / branch may be either unreadable or unfamiliar. It is possible that no one was thinking about this problem. A bank may have branches, and branches will have numbers. But what do you call a server in an intermediate server room, which is not a “bank branch” at all?
Perhaps the most painful question is: should transliteration or translation be used? Let everyone decide for himself (though I hate translating).
Another important “but” is that revealing the server’s administrative ownership to unauthorized persons may be the most painful of all that says the computer name to unauthorized persons. msk-yukos-acc-12 is clearly not the name you want to show others.
Never lay on "nobody will see it from the outside." You do not know where and who will see a fragment of the letter (with headers about forwarding), a message from the server stating that it cannot communicate with SQL or some other stupid piece of information that would be useless if there weren’t such detailed ones server names ...
Further, on the functional role. It seems to me that it would be wrong to write the name of the protocol of the main service, although such a temptation still arises. It would be more correct to speak specifically about the role (at the same time, at this moment, you might think about whether there is too much in the company tied to one server).
Examples: instead of the www server, we can make a 'pa' (public access) or 'ea' (external access) server (where the FTP server will look great too). Instead of a proxy, we can call it ag (application gateway), which, incidentally, is also very logical for the intermediate mail relay. At the same time, for servers that should not be assigned other roles according to best practices, you can probably be allowed to be named after the main and only function: DC for a domain controller, EX for exchange, SL for a dedicated syslog server.
Separately about routers. What is the main role of the router? Route, Route, Route! Although, in fact, if you look closely, the roles of routers are usually even more convex than those of servers. For example, in almost any network there is a gateway (gw), usually there is a core level (cl or cr - core router), in any large network dl (distribution level) and al (access level). Most likely (in the conditions of branches) there are vpn routers (which are network to network) - vpn is asked for in the name. But for those who terminate point to network connections, it is better to give the name not 'vpn' (since full-fledged networks are not really here), but, for example, ra (remote access). Additionally, the -GW suffix suggests the use of RFC 952.
From myself I note that the names should be given not only to smart pieces of iron, but also stupid (if there are any in your network yet) - sometimes you need to ask to reboot / turn off / turn on “this switch”, and which one is “the one”? The presence of msk-al-12 tags on it will greatly increase the accuracy of the request.
If the router has 30 different networks, 30 different IP addresses, then each of them must have its own reverse name. Here is another choice: either we put meaning into this number, or we number them in a row. Separately, it is probably worth highlighting external interfaces (on border routers), internal and bridge interfaces (br) in the case of long links (native optics, virtual interfaces in a VPN, just links between buildings).
Do not underestimate the importance of naming workstations. These names are visible in the SMTP headers (I somehow laughed a lot when I received a letter in response to the resume with the name of the workstation (by PTR) tupayasuka.domain.ru, the workstation itself considered what was called komputer). What is needed on behalf of the workstation? Unlike the server, it does not need versatility and a functional role, so the number is enough. If there are different types of stations (thin clients, Windows, linux) - then, perhaps, a mention of this. Well, the geographical location, of course.
Separately, you need to consider the presence of employees' laptops on which they are "their own admins" - the variety in names there will be rare ...
Does a separator need a name? Let's compare:
I think the answer is obvious. About the symbol. We do not have many options:
There remains one character that is easy to print, which is familiar to the eye, compatible with DNS - this is a hyphen. Perhaps its disadvantages are the inconvenience of typing on sub-keyboards on smartphone screens and some incompatibility with programming languages that have a minus sign in the main space of tokens (although I do not think that this will be a significant problem; in a regular shell, a hyphen is a hyphen, not minus).
Now about how many separators? Let's say that we have a very large company, in which there is a lot of IT iron.
The approximate composition of the name:
nsk (Novosibirsk), hd (from head), mf (from manufacture, production facilities), st (storage, storage), 11 (the eleventh server of the same type), the second interface (out of three, two go to the switches for reservation , one for headbeats in a cluster).
Options:
Personally, I like the penultimate one. Nevertheless, it is covered by the size of each part, plus, it has a separate geography (nsk + hd - place in a geographical sense, mf + st - exact place (within the office) and approximate role).
Points to consider: the likelihood of geographical migration (it’s stupid to call the server msk -... if it will wander between Amsterdam and Helsinki); the presence of bindings to the infrastructure (for example, to the channel segment with some L2 applications (vlan'y, pppoe, arp proxy)).
In principle, I (for myself) settled on using the letter 'h' (host system) for hosts and 'v' for quests (virtual machines). For example, v-mf11, migrating between nskhd-hx1 nskhd-hx15 (guess for yourself what it works on).
Another interesting thing in the work can be local aliases. If some servers (equipment) are closed (for example, a group of servers that solves a local problem), then it makes sense to give them short names. In order not to bother with DNS (which can be completely alien to the administration), the hosts file might be very out of place (yes, this file was created not only for vkontakte / odnoclassniki). For example, if there is a storage server, a pair of controllers and a report server, then why shouldn't they be called stor, ctl1, ctl2, rep? Of course, these names are for "internal" use only, they should not be announced outside or used for configurations in which the servers used can change.
Summarizing:
What are the nodes and interfaces of nodes in the network?
To begin, I will outline the essence of the problem: when you have 2-3-5-10 servers, then their names, addresses, etc. you quickly remember, and they do not cause much confusion. But if you have several thousand servers (let's add virtual ones to the real ones), if your router has several hundred real or virtual (in vilanas) interfaces, each of which needs to be given a name (at least for PTR / A records in DNS), when you have interfaces for configuring switches, print servers, network printers ... In these conditions, you really need to sit down and think what to call them. It’s better to sit down to think before they start calling, than after.
Simple ways
First, consider the simple solutions that come to mind first.
Call them by their proper names
For example, by the elements of the periodic table (who did the trail to Yandex, saw). Enough for a hundred with a small name. Then it will be interesting to read in the logs that Helium reject mail from potassium. Plus, there is a ready-made set of abbreviations for short aliases, and it is unique. Similarly, you can select, for example, countries. Or cities. Or some other set with names.
The downside of this is understandable: looking at the server name it is impossible to understand what it is doing. Plus - the names are clear, memorable, distinguishable. It is clear that we will never confuse calcium with potassium. Never.
Call them by numbers
For example, fsbk3333, fsbk32232 ... Quite a name. If the servers are homogeneous. And if not? Remember that “333” is the mail server, and 5622 is the out-of-band interface of the backup vpn gateway ... Maybe it is better over IP right away?
Name them by roles
mail.domain, gateway.domain, vpn.domain, radius.domain, databases.domain, printer.domain, etc. The plus is an accurate understanding of what each server does. The downside is some confusion with a mixed functional (why does your router connect to the radius of the mail.domain server? Ah, do you have a radius server there? And why the name "mail"?)
Next, there is a need for numbering, and an explicit desire to shorten the name , because webserver23 will get tired of typing every time.
An even bigger problem will be the division into departments, floors, buildings, cities, firms, etc. To find out that webserver12 is a server with presides for workstations in the administration building in Perm, and webserver22 is an intraweb server with corporate CMS in the head office. Yes, and print such names is also hard.
LDAP shall rule!
There is nothing more distinctive and unambiguous than OU = MSK, OU = "Main Branch", OU = labs, CN = "intranet web server" ... Especially if it is printed by hand every time. Plus, it is not very compatible with DNS. Unless you print "intranet-web-server.labs.mainbranch.msk.our_domain" each time.
General construction of the problem
We now turn to the consideration of the problem in a general way.
General requirements:
- Keeping a reasonable name size
- Mnemonicity of the name
- Data storage in hostname, without taking into account the domain component. This is necessary in order to be able to see the entire host name behind the host’s console, without looking at DNS suffixes.
Specific Requirements:
- Geographical position
- Administrative submission
- Functional role
- Type (the host can be a computer, or it can be a specialized piece of hardware)
- Number, in the case of a group of identical hosts
- indication of virtualization or other special marks (for example, rack-mount iron or not)
It is clear that specific requirements can be expanded in the first place (for example, in the case of complex administrative organization of the network, the coding of administrative subordination itself can be very, very difficult, for example, when it comes to ... a “group of companies”, with units in relative autonomy; similarly, we can talk about other fields - geographical, functional ...)
It is also clear that, depending on the type of organization, some fields may not be in demand. For example, a geographical or administrative part.
However, in the general case, we can dwell on the above list.
Now the following two questions: what size should each part be; How should these parts be separated? And the third question: can the parts of the name have different lengths or should they be strictly fixed?
Let's start with the length: the database fits into 'db', and the terminal server into 'ts', then encoding in two letters, for example, 'backup', is already a little complicated, you get an arbitrary uncommon abbreviation that may overlap with other abbreviations. The same applies to geographical names. Suppose you have branches on each of the lines of Vasilievsky Island. Suppose you encode them in two letters. l4 is the fourth line, l8 is the eighth line ... And how is the 17th line? And tomorrow you will have branches at the Moscow Gate, Moskovskaya metro stations, another branch just at Moskovsky and another branch in Moscow. To drive oneself into a Procrustean bed of a rigid length of a name, IMHO, is not reasonable.
Next, what should the names be? Obviously: the smallest possible, but in the "natural" reduction. Even if you do not have other branches on “m”, to reduce Moscow to “m” (instead of msk) is to reduce the mnemonics and readability of the name.
Geographical part
In principle, it is quite simple, because the art of abbreviations for geographical names has long been mastered and is publicly known. Two-letter state codes in the USA, three-letter city names in Russia (from geographic domains), two-letter country codes (from ISO) ... Street names may also be abbreviated, although you will have to show some ingenuity here (see the example above about the lines of Vasilyevsky Island).
Administrative submission
The issue of administrative subordination is a little more complicated. The full name of the department / branch may be either unreadable or unfamiliar. It is possible that no one was thinking about this problem. A bank may have branches, and branches will have numbers. But what do you call a server in an intermediate server room, which is not a “bank branch” at all?
Perhaps the most painful question is: should transliteration or translation be used? Let everyone decide for himself (though I hate translating).
Another important “but” is that revealing the server’s administrative ownership to unauthorized persons may be the most painful of all that says the computer name to unauthorized persons. msk-yukos-acc-12 is clearly not the name you want to show others.
Never lay on "nobody will see it from the outside." You do not know where and who will see a fragment of the letter (with headers about forwarding), a message from the server stating that it cannot communicate with SQL or some other stupid piece of information that would be useless if there weren’t such detailed ones server names ...
Functional part
Further, on the functional role. It seems to me that it would be wrong to write the name of the protocol of the main service, although such a temptation still arises. It would be more correct to speak specifically about the role (at the same time, at this moment, you might think about whether there is too much in the company tied to one server).
Examples: instead of the www server, we can make a 'pa' (public access) or 'ea' (external access) server (where the FTP server will look great too). Instead of a proxy, we can call it ag (application gateway), which, incidentally, is also very logical for the intermediate mail relay. At the same time, for servers that should not be assigned other roles according to best practices, you can probably be allowed to be named after the main and only function: DC for a domain controller, EX for exchange, SL for a dedicated syslog server.
Separately about routers. What is the main role of the router? Route, Route, Route! Although, in fact, if you look closely, the roles of routers are usually even more convex than those of servers. For example, in almost any network there is a gateway (gw), usually there is a core level (cl or cr - core router), in any large network dl (distribution level) and al (access level). Most likely (in the conditions of branches) there are vpn routers (which are network to network) - vpn is asked for in the name. But for those who terminate point to network connections, it is better to give the name not 'vpn' (since full-fledged networks are not really here), but, for example, ra (remote access). Additionally, the -GW suffix suggests the use of RFC 952.
From myself I note that the names should be given not only to smart pieces of iron, but also stupid (if there are any in your network yet) - sometimes you need to ask to reboot / turn off / turn on “this switch”, and which one is “the one”? The presence of msk-al-12 tags on it will greatly increase the accuracy of the request.
Multihead
If the router has 30 different networks, 30 different IP addresses, then each of them must have its own reverse name. Here is another choice: either we put meaning into this number, or we number them in a row. Separately, it is probably worth highlighting external interfaces (on border routers), internal and bridge interfaces (br) in the case of long links (native optics, virtual interfaces in a VPN, just links between buildings).
Workstations and peripheral trash
Do not underestimate the importance of naming workstations. These names are visible in the SMTP headers (I somehow laughed a lot when I received a letter in response to the resume with the name of the workstation (by PTR) tupayasuka.domain.ru, the workstation itself considered what was called komputer). What is needed on behalf of the workstation? Unlike the server, it does not need versatility and a functional role, so the number is enough. If there are different types of stations (thin clients, Windows, linux) - then, perhaps, a mention of this. Well, the geographical location, of course.
Separately, you need to consider the presence of employees' laptops on which they are "their own admins" - the variety in names there will be rare ...
Separation of names
Does a separator need a name? Let's compare:
- mskmainac012
- spbnpcl-02
- msk-main-ac-012
- spb-np-cl-02
I think the answer is obvious. About the symbol. We do not have many options:
- dot - reserved for DNS
- underscore - not fully compatible with DNS, press to shift when printing
- colon - unusual, incompatible with DNS
There remains one character that is easy to print, which is familiar to the eye, compatible with DNS - this is a hyphen. Perhaps its disadvantages are the inconvenience of typing on sub-keyboards on smartphone screens and some incompatibility with programming languages that have a minus sign in the main space of tokens (although I do not think that this will be a significant problem; in a regular shell, a hyphen is a hyphen, not minus).
Now about how many separators? Let's say that we have a very large company, in which there is a lot of IT iron.
The approximate composition of the name:
nsk (Novosibirsk), hd (from head), mf (from manufacture, production facilities), st (storage, storage), 11 (the eleventh server of the same type), the second interface (out of three, two go to the switches for reservation , one for headbeats in a cluster).
Options:
- nsk-hd-mf-st-11-2
- nskhd-mfst-11-2
- nsk-hdmfst-11-2
- nskhd-mfst11-2
- nskhdmfst11-2
Personally, I like the penultimate one. Nevertheless, it is covered by the size of each part, plus, it has a separate geography (nsk + hd - place in a geographical sense, mf + st - exact place (within the office) and approximate role).
Virtuality
Points to consider: the likelihood of geographical migration (it’s stupid to call the server msk -... if it will wander between Amsterdam and Helsinki); the presence of bindings to the infrastructure (for example, to the channel segment with some L2 applications (vlan'y, pppoe, arp proxy)).
In principle, I (for myself) settled on using the letter 'h' (host system) for hosts and 'v' for quests (virtual machines). For example, v-mf11, migrating between nskhd-hx1 nskhd-hx15 (guess for yourself what it works on).
Local aliases
Another interesting thing in the work can be local aliases. If some servers (equipment) are closed (for example, a group of servers that solves a local problem), then it makes sense to give them short names. In order not to bother with DNS (which can be completely alien to the administration), the hosts file might be very out of place (yes, this file was created not only for vkontakte / odnoclassniki). For example, if there is a storage server, a pair of controllers and a report server, then why shouldn't they be called stor, ctl1, ctl2, rep? Of course, these names are for "internal" use only, they should not be announced outside or used for configurations in which the servers used can change.
How to plan a name?
Summarizing:
- Decide on the numbering size. Perhaps everything will cost s1-s5 for servers and a couple of devices r1-r2
- Write down all existing names and abbreviations, try to think through them for at least half a year into the future and imagine the appearance of the same, but in a different building.
- Decide if you can rename devices? You can rename a router, renaming a mail server is already difficult, renaming a domain controller can be a problem, and renaming a file server to which all links to specific files are a disaster [Hint: in Windows there are DFS, in Linux - CNAME in DNS]
- Make a couple of dozen titles, see if they are readable (that is, it’s clear “what is it”), try to print it
- Check if there is any confidential information (it is better to check with the authorities that there is "confidential" - company name, city, address, branch number)