Introduction: Creating a stable and reliable computer network service is an important task for system administrators. Here I will analyze the concept of service in computer network. Welcome to read it!
Abstract: The main difference between a structured computer environment managed by a system administrator and a computer environment consisting of only one or several isolated computers is service. This paper expounds the concept of service in computer network.
Keywords: computer; Network; Service.
The main difference between a structured computer environment managed by a system administrator and a computer environment consisting of only one or a few isolated computers is the service. The typical environment with only a few isolated computers is home and those small non-technical offices, while the typical structured computer environment is that technicians operate a large number of computers and are connected with each other through convenient communication, optimized resources and other services. When a home computer is connected to the Internet through the Internet or an ISP, it can only enter the network by using the services provided by the ISP or others.
Providing services is more than simply adding up hardware and software. It includes service reliability, service standardization, service monitoring, maintenance and technical support. Only the service that meets these requirements is the real service.
1 Basic problems of service.
Creating a stable and reliable service is an important task for system administrators. In this work, the system administrator must consider many basic elements, the most important of which is to consider the needs of users at all stages of design and development. We need to communicate with users to understand their service requirements and expectations, and then make a list of other requirements, such as management requirements, which can only be seen by the system administrator team.
Services should be built on server-level machines, and the machines should be placed in a suitable environment. As a server, the machine should have appropriate reliability. You should monitor the service and the machines on which the service depends, and give an alarm or generate a list of fault records when there is a fault.
As part of the service, machines and software should rely on those hosts and software based on the same or higher standards. The reliability of a service is equivalent to the reliability of the weakest link in the service chain on which it depends. A service should not rely on a host that does not belong to the service for no reason. Once the service is built and tested, it will gradually turn to the user's point of view for further testing and debugging.
1. 1 user requirements.
Building a new service should start from the needs of users, and users are the fundamental reason for you to build a service. If the established service cannot meet the needs of users, it is a waste of energy.
Collecting users' needs should include the following contents: how they want to use these new services, what functions they need, what functions they like, how important these services are to them, and what level of availability and technical support they need. If possible, let users try the trial version of the service. Don't let users use those troublesome or unsuccessful systems and projects. Try to find out how big the user base is, what kind of performance is needed, and what kind of performance is expected, so as to calculate correctly.
1.2 operation requirements.
For system administrators, some requirements of new services are not directly visible to users. For example, the system administrator should consider the management interface of the new service, whether it can cooperate with the existing service, and whether the new service can be integrated with core services such as authentication service and directory service.
From the user's expected reliability level and the system administrator's expectation for the future reliability of the system, the system administrator can establish a list of functions expected by the user, including cluster, slave devices, backup servers or high-availability hardware and operating systems.
1.3 open architecture.
Sometimes manufacturers use private agreements only to reach a clear license agreement with other manufacturers, but there will be obvious delay between the new version used by one manufacturer and the compatible version used by another manufacturer, there will be interruption between the versions used by the two manufacturers, and there will be no interface between the two products. This situation is a nightmare for those who rely on its interface to use two products at the same time.
A good solution is to choose protocols based on open standards, so that both parties can choose their own software. This separates the choice of client application from the choice of server platform. Users can freely choose the software that best meets their own needs, preferences and even platforms, and system administrators can choose their own server solutions according to their own requirements of reliability, scalability and manageability. System administrators can choose from some competitive server products, not limited to server software and platforms suitable for some client applications.
In many cases, if software vendors support multiple hardware platforms, system administrators can even choose server hardware and software independently.
We call it the ability to separate user selection from server selection. Open agreements provide a level playing field and stimulate competition among suppliers, which will ultimately benefit us.
Open protocols and file formats are quite stable, will not be changed frequently (even if they are changed, they are upward compatible), and also have extensive support, which can give you the greatest product independence and the greatest opportunity to obtain reliable and compatible products.
2. Other issues that need to be considered.
In addition to reliability, monitoring, easy maintenance and support, and meeting all our basic requirements and users' requirements, the establishment of services should also consider some special things. If possible, you should let each service use a special machine, which will make the service easier to support and maintain, and reduce the chance of forgetting some small services on the server machine. In some large companies, the use of special machines is the basic principle, but in small companies, due to cost problems, this requirement is generally not met.
Another idea is to make services completely redundant when building them. No matter how big the company is, some important services need to be completely redundant. With the expansion of the company, your goal should be to make all services completely redundant.
2. 1 Use special machines.
Ideally, services should be built on specialized machines.
Large websites should be able to adjust to this structure according to service requirements, while small websites are difficult to do. Each service has a special machine, which will make the service more reliable, easy to debug when there is a problem with reliability, smaller fault range, easy to upgrade and plan capacity.
Large websites that grow up from small companies generally have a centralized management machine as the core of all important services, providing name services, authentication services, printing services, mail services and so on. Finally, due to the increased load, machines have to be separated and services extended to other servers. Often before this, system administrators have obtained funds to buy more management machines, but they feel too much trouble, because there are too many services that rely on this machine, and it is too difficult to separate them. When separating services from machines, the dependence on IP addresses is the most difficult to handle. The IP addresses of some services, such as name service, have been firmly remembered by users, and some IP addresses are used by security systems such as routers and firewalls.
It is difficult to decompose a central host into many different hosts. The longer it takes to build, the more services there are, and the more difficult it is to decompose. It helps to use service-based names, but the whole company must use standardized, unified and consistent names.
2.2 Sufficient redundancy.
Sufficient redundancy means having one or a series of replicated servers, which can take over the main failed equipment in case of failure. Redundant systems should be able to run continuously as backup servers, and can automatically connect when the main server fails, or take over the failed system that provides services with little manual intervention.
The redundancy you choose depends on the service. Some services, such as web servers and computing areas, can run well on cloned machines. Other services, such as large databases, will not work. They need a more powerful crash recovery system. The service software you are using may tell you that redundancy exists in the form of an effective, passive and slave server, and the redundant system will only respond when the master server fails and makes a request. In any case, the redundancy mechanism must ensure data synchronization and maintain data integrity.
If the redundant server and the main server run continuously and synchronously, the redundant server can be used to share the normal operation load and improve the performance. If you use this method, you must be careful not to let the load exceed the unacceptable performance critical point to prevent the server from failing. Before reaching the critical point, more parallel servers should be added to the existing system.
Another advantage of redundancy is that it is easy to upgrade. You can upgrade by rolling. Disconnect, upgrade, test and restart one host at a time. The failure of a single host will not stop the whole service, although it may affect performance. If you really screwed up an upgrade, turn off the power and wait until you calm down to fix it.
References:
[1] Mo Weidong. Computer network technology and application [M]. Beijing: Machinery Industry Press, April, 2009.
[2] Wu Yi. Computer network configuration, management and application [M]. Beijing: Higher Education Press, 2009, 1.
;