kudu Clock considered unsynchronized 问题解决

公司使用ambari开源组件开发大数据管理平台，在集成kudu组件时，经常会遇到kudu不能启动的问题，通过查询kudu日志，报错信息如下：

F0924 20:24:36.336809 14550 hybrid_clock.cc:191 Couldn't get the current time: Clock unsynchronized. Status: Service unavailable: Error reading clock. Clock considered unsynchronized.

通过查询大量资料得知，kudu组件对各个节点的时间一致性要求非常高，只允许秒级别延迟。kudu会使用ntptime命令来确定时钟的正确性，如果该命令result code为0，则kudu可以正常启动，否则会启动失败。下面是本人的一些解决问题的方案记录：

1. 必须开启本机的ntpd服务

2. 必须在高版本的ntp配置文件中加上这行记录：

 server 127.127.1.0 iburst
  fudge 127.127.1.0 stratum 8

否则使用ntpp -q命令会报如下错误：

ntpq -p
No association ID's returned

3. 新版本的ntp必须在ntp.conf文件中加入enable mode7配置项，才能解决ntpdc -c loopinfo报错的问题．安装了kudu服务的机器，本身一定要把ntpd服务启动起来的，因为它会使用ntpq -p 和 ntpdc命令，不启动起来会报错．

4. 查看ntptime命令返回结果，该命令在机器重启或者使用命令ntpdate -u xxxx同步时间后，可能会出现result code error的问题，只能等待几分钟让其自行恢复.

Kudu ntp官方文档介绍

Kudu如果使用系统时间源，则必须使用网络时间协议（NTP）来同步运行Kudu主服务器或平板电脑服务器的计算机的本地时钟。 时间源由--time_source标志控制，默认情况下设置为system。

Kudu要求NTP同步时钟的最大时钟错误（不要与估计的错误相混淆）低于可配置的阈值。 默认阈值为10秒，可以使用--max_clock_sync_error_usec标志对其进行自定义。

使用系统时间源运行时，如果报告本地时钟未同步，则Kudu将不会启动，并且会发出如下消息：

F0924 20:24:36.336809 14550 hybrid_clock.cc:191 Couldn't get the current time: Clock unsynchronized. Status: Service unavailable: Error reading clock. Clock considered unsynchronized.

如果机器的时钟已同步，但是最大时钟错误太大，则用户将看到以下消息：

13:09.873 PM FATAL hybrid_clock.cc:196 Couldn't get the current time: Clock synchronized, but error: 11130000, is past the maximum allowable error: 10000000

or

Sep 17, 8:32:31.135 PM FATAL tablet_server_main.cc:38 Check failed: _s.ok() Bad status: Service unavailable: Cannot initialize clock: Cannot initialize HybridClock. Clock synchronized but error was too high (11711000 us).

在此和以下与NTP相关的段落中，当谈论使用NTP与真实时间进行“同步”时，我们指的是两件事：-驱动机器本地时钟的NTP服务器的同步状态-同步 内核NTP规范报告的本地计算机时钟本身的状态

如果使用ntpd（它们包含在ntp软件包中），则可以使用ntpstat，ntpq和ntpdc实用程序进行检索；如果使用chronyd（这是chrony软件包的一部分），则可以使用chronyc实用程序进行检索。 可以使用ntptime实用程序（ntptime实用程序也是ntp软件包的一部分）或chronyc实用程序（如果使用chronyd）来检索后者。 有关更多信息，请参见上述实用程序的手册页和以下段落。

确保ntpdate在计算机启动时正在运行的服务列表中：ntpdate应该在启动ntpd之前运行，以避免计算机本地时钟与真实时间的长时间同步延迟。 本地计算机时钟与真实时间之间的偏移量越小，NTP服务器同步时钟的速度就越快。

运行ntpdate时，请确保该工具报告成功：检查其退出状态和输出。 如果连接到NTP服务器出现问题，请确保防火墙未阻止NTP流量（默认情况下NTP在端口123上生成UDP流量）或其他网络连接问题。

有时，即使ntpstat工具报告NTP守护程序已与参考NTP服务器之一同步，将计算机的本地时钟与真实时间同步也花费了太长时间。 这表现为以下内容：报告NTP守护程序的同步状态的工具声称一切正常，但是ntptime声称本地时钟的状态未同步，并且Kudu tablet server 和 master 拒绝启动，并输出诸如以下错误 上述之一。 如果ntpd与-x选项一起运行，通常会发生这种情况。 根据ntpd的手册页，-x标志将NTP服务器配置为仅转换时钟。 如果不使用-x，则NTP服务器将改为进行逐步调整：

安装ntp软件包后，您可以通过运行ntptime监视计算机时钟的同步状态。 例如，具有本地时钟已同步的系统可能会报告：

ntp_gettime() returns code 0 (OK)
  time de24c0cf.8d5da274  Tue, Feb  6 2018 16:03:27.552, (.552210980),
  maximum error 224455 us, estimated error 383 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 1279.543 us, frequency 2.500 ppm, interval 1 s,
  maximum error 224455 us, estimated error 383 us,
  status 0x2001 (PLL,NANO),
  time constant 10, precision 0.001 us, tolerance 500 ppm,

请注意以下最重要的输出：

最大错误22455 us：此值远低于Kudu要求的10秒最大错误。

状态0x2001（PLL，NANO）：这表明本地时钟与真实时间同步，直至达到上面的最大误差

相反，具有本地时钟不同步的系统将报告如下内容：

ntp_gettime() returns code 5 (ERROR)
  time de24c240.0c006000  Tue, Feb  6 2018 16:09:36.046, (.046881),
  maximum error 16000000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 2.500 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 16000000 us,
  status 0x40 (UNSYNC),
  time constant 10, precision 1.000 us, tolerance 500 ppm,

UNSYNC状态表示本地时钟未与真实时间同步。 因此，报告的最大错误不会传达对实际错误的任何有意义的估算。

ntpstat实用程序报告有关NTP守护程序本身的同步状态的摘要。 例如，运行ntpd并与其参考服务器之一同步的系统可能会报告：

$ ntpstat
synchronised to NTP server (172.18.7.3) at stratum 4
   time correct to within 160 ms
   polling server every 1024 s

请记住，NTP守护程序本身的同步状态并不反映本地时钟的同步状态。 NTP守护程序驱动本地时钟的方式受到许多约束，并且NTP守护程序本身已锁存到参考服务器之一后，可能需要花费一些时间来同步本地时钟。

如果需要有关NTP服务器同步状态的更多详细信息（而不是本地时钟的同步状态），则可以使用ntpq或ntpdc工具来获取有关当前哪个NTP服务器作为服务器源的详细信息。 真实时间并且被认为是候选对象（可行与否）：
 

NTP配置最佳实践

为了提供稳定的时间同步且最大错误率较低，请遵循以下最佳NTP配置最佳实践。

在运行NTP服务器之前，请运行ntpdate（或ntpd -q或chronyd -q，如果是chrony，请运行chronyd -q）。如果本地时钟的偏移量与实际时间相差太远，则即使允许进行步进调整，NTP服务器也可能需要很长时间才能同步本地时钟。因此，在配置ntpd或chronyd之后，请首先使用同一组NTP服务器运行ntpdate工具，或者运行ntpd -q / chronyd -q。假设运行ntpdate / ntpd -q / chronyd -q时NTP服务器未运行。在RHEL / CentOS上，如果使用ntp套件，请启用ntpdate服务。如果使用chrony套件，请启用chrony-wait服务。

在某些公共云环境中，请使用可通过链接本地IP地址访问的高可用性NTP服务器或作为服务提供的其他专用NTP服务器。如果您的群集在公共云环境中运行，请查阅云提供商的文档以获取建议的NTP设置。 AWS和GCE云均提供专用的高可用性NTP服务器，可通过链接本地IP地址从云实例内部访问它们。

除非使用通过链接本地地址可访问的高可用性NTP参考服务器，否则请始终在本地计算机上为NTP服务器配置至少四个时间源。除了在时间源之一不可用的情况下提供冗余之外，这还可以使配置更健壮，因为NTP旨在通过具有更高往返时间和抖动的网络中的各种源来提高其准确性。

使用iburst选项可在启动时更快地进行同步。 iburst选项指示NTP服务器（ntpd和chronyd）在启动时发送初始的“突发”时间查询。这将导致ntpd / chronyd在启动时与其参考服务器更快地同步。

如果最大时钟错误超出Kudu设置的默认阈值（10秒），请考虑在ntp.conf / chrony.conf中为每个NTP服务器的maxpoll选项设置较低的值。例如，考虑将maxpoll设置为7，这将导致NTP守护程序至少每128秒向相应的NTP服务器发出请求。 ntpd和chronyd的默认最大轮询间隔为10（1024秒）。