Naming nodes in the network
I want to raise a question that, in my opinion, no one has considered systemically before. The question is:
To begin with 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 (we’ll add some more virtual ones to the real ones), if your router has several hundred real or virtual (in wilanah) 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 about what to call them. It is better to sit down to think before you started calling than after.
First, consider the simple solutions that come to mind first.
')
For example, according to the elements of the periodic table (who made the trace to Yandex, I saw it). Enough for a hundred and a few names. 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 unequivocal. Similarly, you can select, for example, countries. Or cities. Or some other set with names.
The disadvantage of this is quite clear: looking at the name of the server 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 spare vpn gateway ... Maybe it's better by IP immediately?
mail.domain, gateway.domain, vpn.domain, radius.domain, databases.domain, printer.domain, etc. The plus is an accurate understanding of what each server does. Minus - some confusion with mixed functionality (why do you have a router connected to the radius of the mail.domain server? Oh, do you have a radius server there? And why the name “mail”?)
Then there is the need for numbering, and the obvious desire to shorten the name, because typing webserver23 every time will quickly get tired.
An even greater problem will be the division by departments, floors, buildings, cities, firms, etc. It’s hard to figure out that webserver12 is a server with presides for workstations in the administration building in Perm, and webserver22 is an intreweb server with a corporate CMS at the head office. Yes, and print these names too hard.
There is nothing more distinctive and unambiguous than OU = MSK, OU = "Main Branch", OU = labs, CN = "intranet web server" ... Especially if it is hand typed every time. Plus, it is not very compatible with DNS. Unless you print "intranet-web-server.labs.mainbranch.msk.our_domain" every time.
We now turn to the consideration of the problem in general.
General requirements:
Specific requirements:
It is clear that the specific requirements can be first expanded (for example, in the case of complex administrative network organization, the coding of administrative subordination itself can be very, very complex, for example, if we are talking about ... a “group of companies”, with units in each relative autonomy, it is similarly possible to speak about other fields - geographical, functional ...)
It is also clear that, depending on the type of organization, some of the fields may not be needed. For example, geographical or administrative part.
However, in general, we can stop at the above list.
Now the following two questions: how big each part should 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 the 'db', and the terminal server in the 'ts', then encode in two letters, for example, 'backup' is already a bit difficult, you get an arbitrary uncommon abbreviation that can be superimposed on other abbreviations. The same applies to geographical names. Suppose you have branches on each of the lines of Vasilyevsky Island. Suppose you encode them in two letters. l4 - the fourth line, l8 - the eighth line ... And 17 line how? And tomorrow you will have branches at the Moskovskie Vorota, Moskovskaya metro stations, another branch simply “at Moskovsky” and another branch in Moscow. To drive yourself into the Procrustean bed of a hard length name, IMHO, is not reasonable.
Further, what should be the name? Obviously: the smallest possible, but in a “natural” contraction. Even if you do not have other branches on the "m", abbreviate Moscow to "m" (instead of msk) is to reduce the mnemonicity and readability of the name.
In principle, it is quite simple here, because the art of abbreviations for geographical names has long been mastered and publicly known. Two-letter state codes in the United States, three-letter city names in Russia (from geographic domains), two-letter country codes (from ISO) ... Street names can be abbreviated in the same way, although here you will have to show some intelligence (see the example of Vasilyevsky Island above).
The issue of administrative subordination is a bit more complicated. The full department / branch name may be either unreadable or unfamiliar. It is possible that no one thought about this problem. The bank may have branches, and the branches will have numbers. But how do you call the server in the intermediate server, which is not a “bank branch” at all?
Probably the most painful question: whether to use translit or translation? Let everyone decide for himself (although I can not stand translit).
Another important "but" is that the disclosure of the administrative identity of the server to unauthorized people can be the most painful of all that says the name of the computer to outsiders. msk-yukos-acc-12 - obviously not the name that you want to show others.
Never lay down on "no one will see this outside." You do not know where and who will see the fragment of the letter (with the headers about the transfer), the server's message that it cannot communicate with SQL or some other stupid bit of information that would be useless if there were not so detailed server names ...
Further, on the functional role. It seems to me that it would be wrong to write here the name of the protocol of the main service, although such a temptation does arise. It would be more correct to speak about the role (at the same time, at this moment, you can think about whether there is too much in the company tied to one server).
Examples: instead of a www-server, we can make a 'pa' (public access) or 'ea' (external access) server (where an FTP server will also look great). Instead of proxy, we can call it ag (application gateway), where, by the way, the intermediate mail relay is quite logical. At the same time, for servers that, according to the best practices, should not be assigned other roles, you can probably be called by the name of the main and only function: DC for the domain controller, EX for the exchange, and SL for the dedicated syslog server.
Separately, about routers. What is the main role of the router? Routing, route, route! Although, in fact, if you take a good look, the roles of routers are usually even more prominent than those of servers. For example, practically in any network there is a gateway (gw) usually there is a core level (cl or cr - core router), in any large network there is a dl (distribution level) and al (access level). Most likely (in terms of branch offices) there are vpn routers (which are network to network) - vpn so they ask for the name. But for those who terminate point to network connections, it is better to give the name not 'vpn' (since it’s not really full-fledged networks), but, for example, ra (remote access). Additionally, the -GW suffix suggests using RFC 952.
From myself, I note that the names should be given not only to smart pieces of iron, but also to blunt ones (if you still have those on your network) - sometimes you need to ask to restart / turn off / turn on “this switch”, and which one is the “one”? The presence of msk-al-12 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 reverse name. There is another choice: either we put meaning in this number, or we number them in a row. Separately, it is probably worth allocating external interfaces (on border routers), internal and bridge interfaces (br) in the case of long links (own 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 really laughed when I received a letter in response to a resume with the name of the workstation (according to PTR) tupayasuka.domain.ru, the workstation itself believed what is called komputer). What do you need on behalf of the workstation? Unlike the server, it does not need many heads and a functional role, so the number is quite enough. If there are different types of stations (thin clients, Windows, linux), then perhaps it is a mention of this. Well, the geographical position, of course.
Separately, you need to take into account the presence of employees' laptops, on which they are “admins themselves” - the variety in the names there will be rare ...
Do I need a separator in the name? Let's compare:
I think the answer is obvious. About the symbol. We do not have many options:
There is only one character that is easy to type, which is familiar to the eye, compatible with DNS - this is a hyphen. Perhaps its disadvantages are the inconvenience of typing on the undercards on the screens of smartphones and some incompatibility with programming languages ​​that have a minus sign in the main lexeme space (although I don’t think this will be a significant problem; not a minus).
Now how many separators? Suppose that we have a very large company with a lot of IT hardware.
The approximate composition of the name:
nsk (Novosibirsk), hd (from head), mf (from manufacture, production premises), st (storage, storage), 11 (eleventh server of the same type), second interface (out of three, two go to switches for redundancy, one for headbeats in a cluster).
Options:
Personally, I like the penultimate. It is nevertheless covered by the size of each part, plus, it has divided geography (nsk + hd - a place in the geographical sense, mf + st - the exact place (within the office) and an approximate role).
The moments that should be considered: the probability of geographical migration (it’s foolish to call the server msk -... if it wanders between Amsterdam and Helsinki); the presence of links to the infrastructure (for example, to the channel segment in the presence of some L2 applications (vlans, pppoe, arp proxy)).
In principle, I (for myself) stopped using the letter 'h' (host system) for hosts and 'v' for gves (virtual machines). For example, v-mf11, migrating between nskhd-hx1 nskhd-hx15 (guess yourself what it works on).
One more 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 strain with the DNS (which may be at the same time entirely in someone else's administrative control), it is possible that the hosts file will turn out to be very relevant (yes, this file was created not only for vkontakte / odnoclassniki). For example, if there is a server storage, a couple of controllers and a report server, then why not (within our group) call them stor, ctl1, ctl2, rep? Of course, these are names only for “internal” use, they should not be announced outside or used for configurations in which the servers used can change.
Summarizing:
how to call nodes and interfaces of nodes in a network?
To begin with 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 (we’ll add some more virtual ones to the real ones), if your router has several hundred real or virtual (in wilanah) 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 about what to call them. It is better to sit down to think before you started calling than after.
Simple ways
First, consider the simple solutions that come to mind first.
')
Call them by their proper names
For example, according to the elements of the periodic table (who made the trace to Yandex, I saw it). Enough for a hundred and a few names. 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 unequivocal. Similarly, you can select, for example, countries. Or cities. Or some other set with names.
The disadvantage of this is quite clear: looking at the name of the server 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 spare vpn gateway ... Maybe it's better by IP immediately?
Call 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. Minus - some confusion with mixed functionality (why do you have a router connected to the radius of the mail.domain server? Oh, do you have a radius server there? And why the name “mail”?)
Then there is the need for numbering, and the obvious desire to shorten the name, because typing webserver23 every time will quickly get tired.
An even greater problem will be the division by departments, floors, buildings, cities, firms, etc. It’s hard to figure out that webserver12 is a server with presides for workstations in the administration building in Perm, and webserver22 is an intreweb server with a corporate CMS at the head office. Yes, and print these names too 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 hand typed every time. Plus, it is not very compatible with DNS. Unless you print "intranet-web-server.labs.mainbranch.msk.our_domain" every time.
General task construction
We now turn to the consideration of the problem in general.
General requirements:
- Keeping the name size reasonable
- Mnemonic name
- Data storage in hostname, without a domain component. This is necessary in order to be at the console of the host, to see his name entirely, without having to look at the DNS suffixes.
Specific requirements:
- Geographical position
- Administrative submission
- Functional role
- Type (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 features (for example, rack or not)
It is clear that the specific requirements can be first expanded (for example, in the case of complex administrative network organization, the coding of administrative subordination itself can be very, very complex, for example, if we are talking about ... a “group of companies”, with units in each relative autonomy, it is similarly possible to speak about other fields - geographical, functional ...)
It is also clear that, depending on the type of organization, some of the fields may not be needed. For example, geographical or administrative part.
However, in general, we can stop at the above list.
Now the following two questions: how big each part should 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 the 'db', and the terminal server in the 'ts', then encode in two letters, for example, 'backup' is already a bit difficult, you get an arbitrary uncommon abbreviation that can be superimposed on other abbreviations. The same applies to geographical names. Suppose you have branches on each of the lines of Vasilyevsky Island. Suppose you encode them in two letters. l4 - the fourth line, l8 - the eighth line ... And 17 line how? And tomorrow you will have branches at the Moskovskie Vorota, Moskovskaya metro stations, another branch simply “at Moskovsky” and another branch in Moscow. To drive yourself into the Procrustean bed of a hard length name, IMHO, is not reasonable.
Further, what should be the name? Obviously: the smallest possible, but in a “natural” contraction. Even if you do not have other branches on the "m", abbreviate Moscow to "m" (instead of msk) is to reduce the mnemonicity and readability of the name.
Geographical part
In principle, it is quite simple here, because the art of abbreviations for geographical names has long been mastered and publicly known. Two-letter state codes in the United States, three-letter city names in Russia (from geographic domains), two-letter country codes (from ISO) ... Street names can be abbreviated in the same way, although here you will have to show some intelligence (see the example of Vasilyevsky Island above).
Administrative Submission
The issue of administrative subordination is a bit more complicated. The full department / branch name may be either unreadable or unfamiliar. It is possible that no one thought about this problem. The bank may have branches, and the branches will have numbers. But how do you call the server in the intermediate server, which is not a “bank branch” at all?
Probably the most painful question: whether to use translit or translation? Let everyone decide for himself (although I can not stand translit).
Another important "but" is that the disclosure of the administrative identity of the server to unauthorized people can be the most painful of all that says the name of the computer to outsiders. msk-yukos-acc-12 - obviously not the name that you want to show others.
Never lay down on "no one will see this outside." You do not know where and who will see the fragment of the letter (with the headers about the transfer), the server's message that it cannot communicate with SQL or some other stupid bit of information that would be useless if there were not so detailed server names ...
Functional part
Further, on the functional role. It seems to me that it would be wrong to write here the name of the protocol of the main service, although such a temptation does arise. It would be more correct to speak about the role (at the same time, at this moment, you can think about whether there is too much in the company tied to one server).
Examples: instead of a www-server, we can make a 'pa' (public access) or 'ea' (external access) server (where an FTP server will also look great). Instead of proxy, we can call it ag (application gateway), where, by the way, the intermediate mail relay is quite logical. At the same time, for servers that, according to the best practices, should not be assigned other roles, you can probably be called by the name of the main and only function: DC for the domain controller, EX for the exchange, and SL for the dedicated syslog server.
Separately, about routers. What is the main role of the router? Routing, route, route! Although, in fact, if you take a good look, the roles of routers are usually even more prominent than those of servers. For example, practically in any network there is a gateway (gw) usually there is a core level (cl or cr - core router), in any large network there is a dl (distribution level) and al (access level). Most likely (in terms of branch offices) there are vpn routers (which are network to network) - vpn so they ask for the name. But for those who terminate point to network connections, it is better to give the name not 'vpn' (since it’s not really full-fledged networks), but, for example, ra (remote access). Additionally, the -GW suffix suggests using RFC 952.
From myself, I note that the names should be given not only to smart pieces of iron, but also to blunt ones (if you still have those on your network) - sometimes you need to ask to restart / turn off / turn on “this switch”, and which one is the “one”? The presence of msk-al-12 on it will greatly increase the accuracy of the request.
Many heads
If the router has 30 different networks, 30 different IP addresses, then each of them must have its reverse name. There is another choice: either we put meaning in this number, or we number them in a row. Separately, it is probably worth allocating external interfaces (on border routers), internal and bridge interfaces (br) in the case of long links (own 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 really laughed when I received a letter in response to a resume with the name of the workstation (according to PTR) tupayasuka.domain.ru, the workstation itself believed what is called komputer). What do you need on behalf of the workstation? Unlike the server, it does not need many heads and a functional role, so the number is quite enough. If there are different types of stations (thin clients, Windows, linux), then perhaps it is a mention of this. Well, the geographical position, of course.
Separately, you need to take into account the presence of employees' laptops, on which they are “admins themselves” - the variety in the names there will be rare ...
Separation of names
Do I need a separator in the 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, when printing, you need to press shift
- colon - unusual, incompatible with DNS
There is only one character that is easy to type, which is familiar to the eye, compatible with DNS - this is a hyphen. Perhaps its disadvantages are the inconvenience of typing on the undercards on the screens of smartphones and some incompatibility with programming languages ​​that have a minus sign in the main lexeme space (although I don’t think this will be a significant problem; not a minus).
Now how many separators? Suppose that we have a very large company with a lot of IT hardware.
The approximate composition of the name:
nsk (Novosibirsk), hd (from head), mf (from manufacture, production premises), st (storage, storage), 11 (eleventh server of the same type), second interface (out of three, two go to switches for redundancy, 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. It is nevertheless covered by the size of each part, plus, it has divided geography (nsk + hd - a place in the geographical sense, mf + st - the exact place (within the office) and an approximate role).
Virtuality
The moments that should be considered: the probability of geographical migration (it’s foolish to call the server msk -... if it wanders between Amsterdam and Helsinki); the presence of links to the infrastructure (for example, to the channel segment in the presence of some L2 applications (vlans, pppoe, arp proxy)).
In principle, I (for myself) stopped using the letter 'h' (host system) for hosts and 'v' for gves (virtual machines). For example, v-mf11, migrating between nskhd-hx1 nskhd-hx15 (guess yourself what it works on).
Local Pseudonyms
One more 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 strain with the DNS (which may be at the same time entirely in someone else's administrative control), it is possible that the hosts file will turn out to be very relevant (yes, this file was created not only for vkontakte / odnoclassniki). For example, if there is a server storage, a couple of controllers and a report server, then why not (within our group) call them stor, ctl1, ctl2, rep? Of course, these are names only for “internal” use, 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 size of the numbering. Maybe it will cost s1-s5 for servers and a couple of devices r1-r2
- Write down all the existing names and abbreviations, try to think them out at least half a year into the future and imagine the appearance of the same, but in a different building.
- Decide whether you can rename the device? The router can be renamed, renaming the mail server is already hard, renaming a domain controller can be a problem, and renaming a file server to which everyone has links to specific files is a disaster [Hint: Windows has DFS, Linux has CNAME in DNS]
- Make a couple of dozen titles, see if they are readable (i.e. it’s clear “what it is”), try typing it
- Check whether there is confidential information (it is better to check with the authorities what is “confidential” - the name of the company, city, address, branch number)
Source: https://habr.com/ru/post/93423/
All Articles