在早期版本的 NTP 服务部署中，直接使用 NTPD 单源提供 NTP 服务，且 NTP 客户端侧直接使用 crontab 定时执行 ntpdate 命令同步时间，这样既简单又能满足所有机器时间一致性的需求。
但是，这种方式有很大的隐患，如果这个 NTP 服务器或他的上游发生机器时钟跳变，会直接将整个错误时钟传播到所有环境的机器，因为 ntpdate 的同步方式是突变性和强制性的，无论 NTP 服务器提供的时间和本地时间相差多少，都会无条件同步到本地，这样的结果，影响重大，且非常危险。并且单源部署方式也没有任何高可用性，NTP 服务器有一点风吹草动，立马影响整个环境的机器。
这样的 NTP 架构，胜在简单的满足一致性，但同步方式会引起严重事故，进而造成巨大经济损失，因此，NTP 服务架构的优化以及运维管理刻不容缓。
新 NTP 服务架构，应运而生。
新 NTP 服务架构
架构图
模块介绍
NTP-OSS | 管控服务。处理前端配置管理，服务管理，操作记录管理等相关请求，把请求拆解为多个可执行的有序子任务记录到 DB 中，worker 会并发去获取任务并有序执行。操作流任务是通过 ZooKeeper 节点订阅的方式下发到 NTP 服务器中。 |
|---|---|
NTP-Agent | 部署在软件源的机器上的 Agent。主要有两方面的任务：采集 NTP 服务相关监控数据并上报到 监听平台；订阅 ZooKeeper 节点实时获取下发的命令并执行。 |
NTP-Server | TCE 内部环境部署的 NTP 软件源。每个可用区部署三台，同一个可用区的其他机器上的 NTP 客户端同时配置本可用区的三台 NTP 服务器作为上级源，这样即使其中一台 NTP 服务器异常了，仍然能从另外两台选出正确参考源。具备高可用性，NTP 软件源的上游是由客户提供的三个 NTP 硬件源。 |
Zookeeper | 作为 NTP-OSS 和 NTP-Agent 之间通信的桥梁。每台 NTP 服务器上的 NTP-Agent 监听Zookeeper上属于自己的节点，在对应节点收到变更后，对应 NTP-Agent会收到通知。 |
硬件 NTP 源 | 内部软件 NTP 源的上游，一般由客户提供。 |
技术亮点
Zookeeper 节点设计
- 每个 NTP 服务器在 Zookeeper 中有以自己 IP 命名的节点，子节点中包含表示可用区信息（available_zone），命令执行（command），配置信息（config）的节点。每个 NTP 服务器上的 NTP_Agent 监听自己节点下的 service_state 节点和 config 节点。config 的值 0，1，2 分别代表配置修改失败，成功，进行中。service_state 的值 0，1，2 分别代表服务重启失败，成功，进行中。
- 配置修改的逻辑：比如对 10.10.0.3 进行配置修改操作时，NTP_OSS 把新配置写入 upstream 节点，并且设置 config 的值为 2 表示配置修改进行中，同时监听 config 等待执行结果。10.10.0.3 上的 NTP_Agent 监听到 config 被更改为 2，会获取子节点 upstream 的值得到新配置，然后进行连通性等校验并更新到本地的 NTP 配置中，校验并且更新成功，会设置 config 节点为 1 表示修改已完成，否则设置为 0 表示修改失败并把错误原因写到 config 下的 message 节点。
- 服务重启的逻辑：比如对 10.10.0.3 进行服务重启操作时，NTP_OSS 把服务重启命令写入 command 节点，并且设置 service_state 的值为 2 表示命令执行中，同时监听 service_state 等待执行结果。10.10.0.3 上的 NTP_Agent 监听到 service_state 被更改为 2，会获取子节点 command 的值得到待执行命令，然后进行白名单等校验并执行，校验并执行成功，会设置 service_state 节点为 1 表示已执行完成，否则设置为 0 表示失败并把失败原因写到 service_state 下的 message 节点。
NTP部署架构设计
- 每个可用区部署三台软件 NTP Server 作为 TCE 中的统一时钟源。
- 统一软件 NTP Server 的上游时钟源，上游源数量大于三可以提高时钟服务可靠性。
- underlay cvm 和所有物理机使用 NTPD 同步方式，上游为本可用区的三个NTP Server。
- vpcgw 将overlay的时钟同步请求转发到三台软件NTP Server。
在此种部署方式下，NTP 服务拥有很高的可用性以及容错性：
三台软件NTP Server能容忍偶然的机器时钟跳变异常，并且不会造成错误时钟的扩散。因为 NTP 客户端处使用 NTPD 同步方式，在使用了 NTPD 方式的客户端，在某个上游发现明显的跳变异常，会从其他的上游中重新选择参考源。并且异常的NTP Server也会从硬件 NTP 上游重新同步正确的时间，有故障自愈的能力。
技术优势
和原NTP逻辑相比，优势如下：
开箱即用 | 监控数据一览，内置告警阈值，开箱即用。 |
|---|---|
操作便捷 | 为修改配置，重启服务等管理操作提供人性化的交互界面，开放对配置项上游 server 的 IP 修改，简单易懂。 |
易运维 | 在管理界面提供修改配置以及重启服务等运维功能，提供 NTP 服务器监控数据以及告警，使用门槛低。 |
稳定可靠 | 修改配置会对提交的配置进行校验，确保准确后才会真正写到配置中。并且在服务重启时，是对 NTP 服务器的服务进行滚动重启的，防止把错误的配置扩散到所有 NTP 服务器。 |
高负载高可用架构 | 每个可用区部署三台 CVM 作为 NTP 服务器，可灵活调整配置支持高并发的 NTP 同步负载。互为 peer，互为参考，具备高可用性。 |
NTP 管理系统服务于环境中的所有云产品机器，已部署到 30 多个客户环境中。作为环境中全部机器的时钟保证，稳固地保证着环境中所有机器的时钟一致性。并且接入了 NTP 管理系统的环境，都未在出现由于 NTP 异常导致的云产品异常问题。
NTP 作为专有云平台的时钟守护者，肩负全体云产品时钟一致性保证的重担。未来也将持续为各个云产品保驾护航。
-END-
