In this article, we will cover the following topics:
Time synchronization plays an important role in cloud computing:
Each of your network of servers has its own clock. Computer clocks are notorious for drifting. They are typically based on inexpensive oscillator circuits or battery backed quartz crystals that can easily drift seconds and minutes per day, accumulating significant errors over time. That is why most enterprise networks today rely on network time servers that acquire time from the Global Navigation Satellite System (GNSS) and distribute it to clients over a network through the Network Time Protocol (NTP).
ntpdate can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time.
This is useful in some cases to set the clock initially before starting the NTP daemon ntpd. It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited.
# /usr/sbin/ntpdate -u 10.252.148.42
14 May 09:57:05 ntpdate[2890]: step time server 10.252.148.42 offset 30.442100 sec
Depending on your Linux systems, for example, below commands are used to update NTP server configuration file and restart ntpd in a local Oracle Linux system.
$ sudo bash
Password:
bash-3.2# vi /etc/ntp.conf
bash-3.2# /etc/init.d/ntpd restart
Shutting down ntpd: [ OK ]
ntpd: Synchronizing with time server: [ OK ]
Starting ntpd: [ OK ]
There are multiple ways of verifying the results of NTP time synchronization:
bash-3.2# ntpstat
unsynchronised
time server re-starting
polling server every 64 s
bash-3.2# ntpstat
synchronised to NTP server (10.252.148.42) at stratum 4
time correct to within 31 ms
polling server every 64 s
- Importance of time synchronization
- Needs for NTP time synchronization
- How to synchronize time
- How to verify synchronized time
Importance of Time Synchronization
Time synchronization plays an important role in cloud computing:
As single systems have been replaced by multiple, loosely-coupled systems, this need has evolved into a requirement for both accurate and consistent clocks among these systems. The need for millisecond or microsecond timestamp accuracy derives from the need to execute transactions in a correct sequence, particularly if many transactions occur almost simultaneously.You can read [1] for more details.
Needs for NTP Time Synchronization
Each of your network of servers has its own clock. Computer clocks are notorious for drifting. They are typically based on inexpensive oscillator circuits or battery backed quartz crystals that can easily drift seconds and minutes per day, accumulating significant errors over time. That is why most enterprise networks today rely on network time servers that acquire time from the Global Navigation Satellite System (GNSS) and distribute it to clients over a network through the Network Time Protocol (NTP).
Timing accuracy from NTP servers depends upon the accuracy of the source and the precision with which all operations and applications are synchronized.
NTP Time Synchronization via utpupdate
ntpdate can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time.
This is useful in some cases to set the clock initially before starting the NTP daemon ntpd. It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited.
# /usr/sbin/ntpdate -u 10.252.148.42
14 May 09:57:05 ntpdate[2890]: step time server 10.252.148.42 offset 30.442100 sec
NTP Time Synchronization via NTP Daemon
Depending on your Linux systems, for example, below commands are used to update NTP server configuration file and restart ntpd in a local Oracle Linux system.
$ sudo bash
Password:
bash-3.2# vi /etc/ntp.conf
bash-3.2# /etc/init.d/ntpd restart
Shutting down ntpd: [ OK ]
ntpd: Synchronizing with time server: [ OK ]
Starting ntpd: [ OK ]
Verification of Synchronized Time
There are multiple ways of verifying the results of NTP time synchronization:
- ntpstat
- ntpstat will report the synchronisation state of the NTP daemon running on the local machine.
- If the local system is found to be synchronised to a reference time source, ntpstat will report the approximate time accuracy.
- date -R
- -R, --rfc-2822
- output date and time in RFC 2822 format
- /usr/sbin/ntpq -p
- The ntpq utility program is used to monitor NTP daemon ntpd operations and determine performance.
- -p
- Print a list of the peers known to the server as well as a summary of their state. This is equivalent to the peers interactive command.
ntpstat
unsynchronised
time server re-starting
polling server every 64 s
bash-3.2# ntpstat
synchronised to NTP server (10.252.148.42) at stratum 4
time correct to within 31 ms
polling server every 64 s
date
bash-4.1# date -R
Mon, 14 May 2018 08:17:33 -0700
/usr/sbin/ntpq -p
bash-4.1# /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*ucf-c2z3-opc-di 10.68.0.42 3 u 20 64 377 0.971 0.105 0.057
LOCAL(0) .LOCL. 10 l - 64 0 0.000 0.000 0.000
remote refid st t when poll reach delay offset jitter
==============================================================================
*ucf-c2z3-opc-di 10.68.0.42 3 u 20 64 377 0.971 0.105 0.057
LOCAL(0) .LOCL. 10 l - 64 0 0.000 0.000 0.000
| Variable | Description |
| remote | host name or IP number of peer |
| refid | association ID or kiss code |
| st | peer status word |
| t | u: unicast, b: broadcast, l: local |
| when | sec/min/hr since last received packet |
| poll | poll interval (log2 s) |
| reach | reach shift register (octal) |
| delay | roundtrip delay |
| offset | offset |
| jitter | jitter |
No comments:
Post a Comment