Technical documentation: server and network.
Coming to a new job, every system administrator would like to receive a package of comprehensive technical documentation. And the first in importance in this package are documents about the device network and servers.
About networks and servers.
If we talk about technical documentation for use within the company, the first thing that comes to mind is a description of networks and servers. As a rule, the principle of "one company - one server" is already practiced in few places. Parks of user machines are increasing, and with them the number of used servers is growing. No one is surprised by the need to separate mail and web servers located on the external network and a file server that does not have access to the outside.
In the same way as the server parks of organizations grow and become more complex, the size of networks also increases. There is a large number of active and passive network equipment that needs some care and attention from the system administrator. At the edge of the connections appear specialized devices routers and firewalls. The structure of a local network can become quite confusing if the system and order are not brought into it in time.
Network architecture
The first thing that interests every system administrator coming to a new job is the architecture of the network, which he will have to deal with. And not always he can get comprehensive information. Very often we hear something like “here we have hubs / switches, there are sockets, and there are wires”. This, of course, is extremely far from really useful information.
')
Therefore, when creating documentation on the network, you should approach it as if you want to re-learn what you own. Below, I will list those points that in my opinion would be most interesting to me, as a new employee of the company:
• matching sockets to the ports of patch panels;
• compliance with the connection of patch panel ports to network equipment ports;
• connection description on user switches;
• description of the connection on the server switches and connections between the switches;
• a description of the routing between network equipment;
• table of ip addresses used by workstations;
• graphic network diagram.
Of course, to describe the compliance of sockets with patch panels is possible only in cases where the latter is. I want to believe that they have been successfully used for a long time in your company.
The description of the connection of the ports of the patch panels and switches must be kept in the form of a working log, which is supplemented and updated as they switch. This is necessary for complete clarity of what is connected and how it interacts.
The description of the connection of users on the switches means your scheme of distributing workstations by network equipment. Suppose you have a department of designers in your company who use a separate file server in their work. (Separate, because the sizes of graphic files are very large and it is desirable to separate them from ordinary users so that the latter do not complain about permanent “brakes” in the server response.) In addition to using a file server to store their work, designers often exchange large files between by myself. It would be logical to connect them to a separate switch.
In addition to the intended designers themselves, it is necessary to connect the server with their file on the same switch so that the number of intermediate connections is minimal. This can be very critical for the network. (By the way, if the fantasy on the designers is over, then we can assume developers using a dedicated database server.) Knowing which switch the servers are connected to is useful for analyzing an unstable and / or slow network.
If you use "intelligent" network equipment and routing is configured in a special way, it is also worth describing. In the future, this may be useful for analyzing network performance. Or, for example, when moving a company to a new office. By the way, it is often quickly and correctly (effectively) to reconnect all the equipment in a new place without clear documentation. Consequently, there are additional downtime in the company and the general discomfort from the "wrong" working network.
A sign in the form of "User - IP address" (as an option, you can add more and the name of the workstation) also does not seem superfluous when the number of company employees exceeds 10-20 people. Issuing the IP address of a new workstation should not become a headache for you, but all that is required is to maintain a correspondence table. Of course, the task can be solved through a dhcp server, issuing clients to ip mac-addresses. But if the user is assigned several addresses, or for some reason the dynamic output of addresses is not used - the sign will be very useful. (Yes, and the rest of it will not be superfluous for a more visual presentation.)
Visually understand the structure is always easier. Therefore, the last thing I would like to mention is a graphical network diagram. The most reasonable thing to do is on the office plan. Here you can specify how the cables are laid, where the cross-connection cabinet is located, where sockets are installed in the rooms and how many of them (and it’s not superfluous to indicate not only the sockets of the local network, but also the power ones). On the same plan you can put a lot of other equally useful information.
Of course, you can not be limited to the listed points and add your own. But the above is enough for a detailed acquaintance with your network.
Internet access scheme.
Having finished the description of the local network, add a document with the description of the scheme of access to the global network. Describe the settings of your gateway and firewall (for example, if port forwarding is done to internal addresses). If you use the system for switching to the backup channel in case of the main fall, tell us about that too.
Information about servers.
What happens on the servers and how they work is the second question that interests any system administrator. The list of information that should be indicated is quite logical:
• hardware;
• installed software;
• services provided;
• network connections.
The hardware is useful to know for planning the increase in resources of existing servers. And when justifying proposals for the procurement of new equipment is best to rely on what is available and why the available is not enough to meet the needs of the company.
The need to know the installed software, I think, no one will raise questions. You need to clearly know what works on your servers and how it is used. This is necessary for many reasons, one of which is the tracking of announcements of detection of vulnerabilities, patch releases, and so on. The more you know about your “farm”, the more effectively you can manage and use it in your work. Probably, every system administrator “found” on one (or even several) server “forgotten” services.
A logical continuation of the description of the software will be the description of the services provided. In other words, a clear statement of what role this or that server plays in the work of the network, whom it serves and for which it is responsible. Maybe at the time of drawing up such a structure, you will understand that this or that service would be a good idea to transfer to another server.
By network connection is meant the IP address of the server, and if it is in the external network, then the services open to the external world. If you urgently need to restrict network activity on certain ports, then according to the document you have drawn up, you will clearly know what to do. Of course, every system administrator will say that he knows exactly where all the services are. Believe it, at times all knowledge tends to be replaced by more new and fresh information. Therefore, it is better to record it in the documentation, especially since it will not take much time.
Description of services and their configuration files.
After you have described the server as a whole, it’s time to describe the services used in more detail. I do not urge you to tell you the work of your domain forest on dozens of pages. However, anyone who has ever set up (for example) a mail system on a Linux operating system knows how many options there can be. Starting from the choice of MTA, ending with script bindings, authorization settings, schemes of used databases and so on.
Therefore, it would not be superfluous to describe for the beginning the configuration of key services in a separate document. I would recommend using a system like NPJ for this (read about it in the journal “System Administrator” No. 11 for 2005). There are several reasons for this and they all boil down to one thing - convenience.
Figure 1. “Working” documentation structure of one of the companies.
If you start to keep documentation on the network, then sooner or later you may want to supplement it with descriptions of what you set up. For example, it may be a description of your mail system settings. Let's list what this description might include.
• MTA settings;
• IMAP and POP3 settings;
• authorization system;
• description of the anti-spam system;
• description of the antivirus;
• description of the auto-answer system (missing users);
• description of mailing lists.
These are the items that immediately came to my mind, it was worth thinking about our postal system. Why is this useful? Let's assume that you have no copies of your configuration files left, and the server means (for example) a hard drive crash is no longer functioning. Of course, sooner or later you will remember all the settings that you once did on it, or configure an alternative configuration. But how much time will it take?
Figure 2. Table of contents description of the server group.
Or another version of the possible development of events. You changed jobs and it became necessary to build a postal system. Why reinvent the wheel when you can open the once made description and literally almost “step by step” to repeat. Conveniently? I think yes.
Antivirus and update centers.
Describing the server do not forget to mention the antivirus used. These can be separate client programs on each computer or corporate versions of programs. Where the server application is engaged in downloading updates and distributing them among client machines. Convenient, fast and economical.
Or maybe you use update centers not only of antiviruses. They should also be described. At least, to remember about their existence and not to forget to follow them. (I say “remember”, because I myself often forgot about them immediately after installation and configuration.)
Backup system
When you have finished describing your company's servers, it's time to describe the backup system used. Specify which computer is responsible for this, which software and hardware it uses for this. It is also worth documenting your backup storage scheme.
Total.
Of course, not all the points considered are the minimum necessary when creating the first technical documents in your company. However, documentation on the network and the server only looks cumbersome and difficult to implement the task. In fact, as the existing gaps are filled, you will understand how useful and convenient this is for you. There is nothing more enjoyable than working with a network about which you know everything and at any time can answer any question. The main thing is not to stop there, and also not to forget to follow the relevance of the compiled documents.
(c) akeeper Korshunov Alexey.
Originally published in the journal "System Administrator"
About networks and servers.
If we talk about technical documentation for use within the company, the first thing that comes to mind is a description of networks and servers. As a rule, the principle of "one company - one server" is already practiced in few places. Parks of user machines are increasing, and with them the number of used servers is growing. No one is surprised by the need to separate mail and web servers located on the external network and a file server that does not have access to the outside.
In the same way as the server parks of organizations grow and become more complex, the size of networks also increases. There is a large number of active and passive network equipment that needs some care and attention from the system administrator. At the edge of the connections appear specialized devices routers and firewalls. The structure of a local network can become quite confusing if the system and order are not brought into it in time.
Network architecture
The first thing that interests every system administrator coming to a new job is the architecture of the network, which he will have to deal with. And not always he can get comprehensive information. Very often we hear something like “here we have hubs / switches, there are sockets, and there are wires”. This, of course, is extremely far from really useful information.
')
Therefore, when creating documentation on the network, you should approach it as if you want to re-learn what you own. Below, I will list those points that in my opinion would be most interesting to me, as a new employee of the company:
• matching sockets to the ports of patch panels;
• compliance with the connection of patch panel ports to network equipment ports;
• connection description on user switches;
• description of the connection on the server switches and connections between the switches;
• a description of the routing between network equipment;
• table of ip addresses used by workstations;
• graphic network diagram.
Of course, to describe the compliance of sockets with patch panels is possible only in cases where the latter is. I want to believe that they have been successfully used for a long time in your company.
The description of the connection of the ports of the patch panels and switches must be kept in the form of a working log, which is supplemented and updated as they switch. This is necessary for complete clarity of what is connected and how it interacts.
The description of the connection of users on the switches means your scheme of distributing workstations by network equipment. Suppose you have a department of designers in your company who use a separate file server in their work. (Separate, because the sizes of graphic files are very large and it is desirable to separate them from ordinary users so that the latter do not complain about permanent “brakes” in the server response.) In addition to using a file server to store their work, designers often exchange large files between by myself. It would be logical to connect them to a separate switch.
In addition to the intended designers themselves, it is necessary to connect the server with their file on the same switch so that the number of intermediate connections is minimal. This can be very critical for the network. (By the way, if the fantasy on the designers is over, then we can assume developers using a dedicated database server.) Knowing which switch the servers are connected to is useful for analyzing an unstable and / or slow network.
If you use "intelligent" network equipment and routing is configured in a special way, it is also worth describing. In the future, this may be useful for analyzing network performance. Or, for example, when moving a company to a new office. By the way, it is often quickly and correctly (effectively) to reconnect all the equipment in a new place without clear documentation. Consequently, there are additional downtime in the company and the general discomfort from the "wrong" working network.
A sign in the form of "User - IP address" (as an option, you can add more and the name of the workstation) also does not seem superfluous when the number of company employees exceeds 10-20 people. Issuing the IP address of a new workstation should not become a headache for you, but all that is required is to maintain a correspondence table. Of course, the task can be solved through a dhcp server, issuing clients to ip mac-addresses. But if the user is assigned several addresses, or for some reason the dynamic output of addresses is not used - the sign will be very useful. (Yes, and the rest of it will not be superfluous for a more visual presentation.)
Visually understand the structure is always easier. Therefore, the last thing I would like to mention is a graphical network diagram. The most reasonable thing to do is on the office plan. Here you can specify how the cables are laid, where the cross-connection cabinet is located, where sockets are installed in the rooms and how many of them (and it’s not superfluous to indicate not only the sockets of the local network, but also the power ones). On the same plan you can put a lot of other equally useful information.
Of course, you can not be limited to the listed points and add your own. But the above is enough for a detailed acquaintance with your network.
Internet access scheme.
Having finished the description of the local network, add a document with the description of the scheme of access to the global network. Describe the settings of your gateway and firewall (for example, if port forwarding is done to internal addresses). If you use the system for switching to the backup channel in case of the main fall, tell us about that too.
Information about servers.
What happens on the servers and how they work is the second question that interests any system administrator. The list of information that should be indicated is quite logical:
• hardware;
• installed software;
• services provided;
• network connections.
The hardware is useful to know for planning the increase in resources of existing servers. And when justifying proposals for the procurement of new equipment is best to rely on what is available and why the available is not enough to meet the needs of the company.
The need to know the installed software, I think, no one will raise questions. You need to clearly know what works on your servers and how it is used. This is necessary for many reasons, one of which is the tracking of announcements of detection of vulnerabilities, patch releases, and so on. The more you know about your “farm”, the more effectively you can manage and use it in your work. Probably, every system administrator “found” on one (or even several) server “forgotten” services.
A logical continuation of the description of the software will be the description of the services provided. In other words, a clear statement of what role this or that server plays in the work of the network, whom it serves and for which it is responsible. Maybe at the time of drawing up such a structure, you will understand that this or that service would be a good idea to transfer to another server.
By network connection is meant the IP address of the server, and if it is in the external network, then the services open to the external world. If you urgently need to restrict network activity on certain ports, then according to the document you have drawn up, you will clearly know what to do. Of course, every system administrator will say that he knows exactly where all the services are. Believe it, at times all knowledge tends to be replaced by more new and fresh information. Therefore, it is better to record it in the documentation, especially since it will not take much time.
Description of services and their configuration files.
After you have described the server as a whole, it’s time to describe the services used in more detail. I do not urge you to tell you the work of your domain forest on dozens of pages. However, anyone who has ever set up (for example) a mail system on a Linux operating system knows how many options there can be. Starting from the choice of MTA, ending with script bindings, authorization settings, schemes of used databases and so on.
Therefore, it would not be superfluous to describe for the beginning the configuration of key services in a separate document. I would recommend using a system like NPJ for this (read about it in the journal “System Administrator” No. 11 for 2005). There are several reasons for this and they all boil down to one thing - convenience.
Figure 1. “Working” documentation structure of one of the companies.
If you start to keep documentation on the network, then sooner or later you may want to supplement it with descriptions of what you set up. For example, it may be a description of your mail system settings. Let's list what this description might include.
• MTA settings;
• IMAP and POP3 settings;
• authorization system;
• description of the anti-spam system;
• description of the antivirus;
• description of the auto-answer system (missing users);
• description of mailing lists.
These are the items that immediately came to my mind, it was worth thinking about our postal system. Why is this useful? Let's assume that you have no copies of your configuration files left, and the server means (for example) a hard drive crash is no longer functioning. Of course, sooner or later you will remember all the settings that you once did on it, or configure an alternative configuration. But how much time will it take?
Figure 2. Table of contents description of the server group.
Or another version of the possible development of events. You changed jobs and it became necessary to build a postal system. Why reinvent the wheel when you can open the once made description and literally almost “step by step” to repeat. Conveniently? I think yes.
Antivirus and update centers.
Describing the server do not forget to mention the antivirus used. These can be separate client programs on each computer or corporate versions of programs. Where the server application is engaged in downloading updates and distributing them among client machines. Convenient, fast and economical.
Or maybe you use update centers not only of antiviruses. They should also be described. At least, to remember about their existence and not to forget to follow them. (I say “remember”, because I myself often forgot about them immediately after installation and configuration.)
Backup system
When you have finished describing your company's servers, it's time to describe the backup system used. Specify which computer is responsible for this, which software and hardware it uses for this. It is also worth documenting your backup storage scheme.
Total.
Of course, not all the points considered are the minimum necessary when creating the first technical documents in your company. However, documentation on the network and the server only looks cumbersome and difficult to implement the task. In fact, as the existing gaps are filled, you will understand how useful and convenient this is for you. There is nothing more enjoyable than working with a network about which you know everything and at any time can answer any question. The main thing is not to stop there, and also not to forget to follow the relevance of the compiled documents.
(c) akeeper Korshunov Alexey.
Originally published in the journal "System Administrator"
Source: https://habr.com/ru/post/5546/
All Articles