The importance of NTP server clock synchronization in distributed systems Because distributed systems use distributed algorithms, its synchronization mechanism is more complex than centralized systems. What can be done in a centralized system is that it can collect all the information of the system in a certain position, and then some processes detect this information and then make synchronization decisions, which is often not possible in distributed systems. Do it. Distributed algorithms generally have the following characteristics:
1) The relevant information is distributed on multiple machines.
2) The process makes decisions based only on locally available information.
3) Should avoid stand-alone failure in the system.
4) There is no common clock or other accurate global time source.
The first three points are all that can not collect all the information of the system at a single point in the process. For example, when doing a resource allocation (allocating I/O devices without deadlocks), you should not normally send all UO requests to a management process. The management process checks all I/O requests based on their device The information in the table decides to satisfy or reject the request. In large systems, sending all requests to a single management process can overload the process. And failure of a single machine like this makes the entire system unreliable. Ideally, distributed systems should be more reliable than stand-alone systems. If a machine in a distributed system stops working, the remaining machines should be able to continue performing system functions. The last thing you want to see is that the failure of one machine (such as a resource distributor) causes many other machines (such as its customers) to stop working. In order to achieve synchronization without centralized control, it needs to take a different approach than the traditional operating system.
The fourth point listed above is also very important. In a centralized system, the time is very clear. Each process needs to know the current time. As long as a system call is executed, the operating system kernel will return the current system time to the process. If process A queries the system time and later process B also queries the system time, the time obtained by process B will be after the time value obtained by process A (which may also be equal), certainly not before. In a distributed system, it is not a simple matter to achieve this time consistency.
As a simple example, consider the lack of globally consistent time for the make program in UNIX. In UNIX, large programs are usually split into multiple source files so that when you modify a file, you compile the file instead of compiling all the files. If the program has one hundred files, it is not necessary to recompile all the files because one file has undergone major changes, which greatly speeds up the work of the programmer.
In general, the make program works very simply. The programmer starts nla~e after modifying the source file. The Make program checks the last modified time of the source file and its corresponding target file. If the source file is input. C's last modification time is 2151, and the corresponding target process minput. o last modified time is 2150, make program can determine the creation of input. o, modify the source file input. C, so recompile the source file input. C. Instead, if output. The last modification time of c is 2144, and the final change time of output, o is 2145, so there is no need to recompile output c. Make program traverses all source files, finds files that need to be recompiled, and invokes the compiler to compile these files.
Now, imagine executing a make program in a global, time-independent distributed system. Assume ouput. The last modified time of o is still 2144, then the source file output is modified. c, but due to edit output. The clock of the c machine is slow, so the modified output. The last time c was specified as 2143, as shown in Figure 11-1. At this time, the make program will not recompile the output.c result. The generated executable file includes the target file generated by the old source file and the target file generated by the new source file. In this way, there will be problems in the operation of the program, and it is also a big headache for the programmer to find the source of the problem in the code.
As we have seen above, time is the basis for people to think about problems. The lack of synchronization between clocks can produce dramatic results. Therefore, it is more appropriate to start researching synchronization with a simple problem such as "is it possible to synchronize all clocks in a distributed system?"
1) The relevant information is distributed on multiple machines.
2) The process makes decisions based only on locally available information.
3) Should avoid stand-alone failure in the system.
4) There is no common clock or other accurate global time source.
The first three points are all that can not collect all the information of the system at a single point in the process. For example, when doing a resource allocation (allocating I/O devices without deadlocks), you should not normally send all UO requests to a management process. The management process checks all I/O requests based on their device The information in the table decides to satisfy or reject the request. In large systems, sending all requests to a single management process can overload the process. And failure of a single machine like this makes the entire system unreliable. Ideally, distributed systems should be more reliable than stand-alone systems. If a machine in a distributed system stops working, the remaining machines should be able to continue performing system functions. The last thing you want to see is that the failure of one machine (such as a resource distributor) causes many other machines (such as its customers) to stop working. In order to achieve synchronization without centralized control, it needs to take a different approach than the traditional operating system.
The fourth point listed above is also very important. In a centralized system, the time is very clear. Each process needs to know the current time. As long as a system call is executed, the operating system kernel will return the current system time to the process. If process A queries the system time and later process B also queries the system time, the time obtained by process B will be after the time value obtained by process A (which may also be equal), certainly not before. In a distributed system, it is not a simple matter to achieve this time consistency.
As a simple example, consider the lack of globally consistent time for the make program in UNIX. In UNIX, large programs are usually split into multiple source files so that when you modify a file, you compile the file instead of compiling all the files. If the program has one hundred files, it is not necessary to recompile all the files because one file has undergone major changes, which greatly speeds up the work of the programmer.
In general, the make program works very simply. The programmer starts nla~e after modifying the source file. The Make program checks the last modified time of the source file and its corresponding target file. If the source file is input. C's last modification time is 2151, and the corresponding target process minput. o last modified time is 2150, make program can determine the creation of input. o, modify the source file input. C, so recompile the source file input. C. Instead, if output. The last modification time of c is 2144, and the final change time of output, o is 2145, so there is no need to recompile output c. Make program traverses all source files, finds files that need to be recompiled, and invokes the compiler to compile these files.
Now, imagine executing a make program in a global, time-independent distributed system. Assume ouput. The last modified time of o is still 2144, then the source file output is modified. c, but due to edit output. The clock of the c machine is slow, so the modified output. The last time c was specified as 2143, as shown in Figure 11-1. At this time, the make program will not recompile the output.c result. The generated executable file includes the target file generated by the old source file and the target file generated by the new source file. In this way, there will be problems in the operation of the program, and it is also a big headache for the programmer to find the source of the problem in the code.
As we have seen above, time is the basis for people to think about problems. The lack of synchronization between clocks can produce dramatic results. Therefore, it is more appropriate to start researching synchronization with a simple problem such as "is it possible to synchronize all clocks in a distributed system?"