在早期版本的 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-