搜索
❏ 站外平台:

复盘京东金融 2017 年元旦闰秒处置方案

作者: 京东金融运维部

| 2017-01-20 08:49   评论: 4    

丙申年,庚子月,戊子日。

西元二〇一七年元日,帝都霾,不禁杀。

从立秋到冬至,乃决大辟罪之季。

柴市牌楼前,人头涌动,听说今日要处决一重犯,大家都拿着瓜子端着茶壶出来看热闹。

十字路口上,面向南方跪着一位蓬头垢面的犯人,身披三械,背后斜插着一支亡命牌。身边一名刽子手,袒胸露乳,一身腱子肉闪着黝黑的光亮,双手端着一把鬼头刀,寒光凌厉。在重犯身后五丈远的地方,放置着一具长案,案上台布一片腥红,桌上还放着一筒火签,旁边有一个香炉,里头插着一根三寸长的檀香。桌后四仰八叉慵懒闲散躺着一位监斩官,不停用嘴吹着檀香,好快点燃完。

太阳像一张没有烙熟的鸡蛋煎饼,无力地透过厚厚的雾层,耷拉在圭表上。石柱的影子虚弱地投在坑坑洼洼的石板上,实在难以辨认现在是几时几刻。

檀香还剩一寸的时候,监斩官已经失去耐心,猛地翻起身来,从签筒里胡乱抽出一支火签令,扔到桌前面的地上:『吉时已到,行刑』。

刽子手双手举刀过头,口中碎碎念叨,全身肌肉绷得紧紧地,拧腰沉肘,一道青霜。

突然犯人仰头长笑几声:『哈哈哈哈』,惊得牌楼上循着血腥味来觅食的几只乌鸦扑棱棱飞起。刽子手也愣了一下,没料到他会在这生死关头突然发笑,手中的刀自然也就没有再落下来。

监斩官眯着眼睛道:『你不知死到临头,为甚做这鬼叫声!』

犯人若有所思道:『看来专家说得没错,每天笑一笑,可以延长寿命五秒钟。』

监斩官道:『弱爆了,专家的话你也信!你难道不知,你今日已经多活了一秒!』

犯人蒙逼道:『此话怎讲?』

监斩官鄙夷道:『闰秒!』

历史和闰秒问题的提出

最初,秒是依据地球绕着轴自转和绕太阳的公转,以平均太阳日的 1/86400 来定义(太阳时)。到了 20 世纪中叶,很明显的,地球自转没有提供足够一致的标准,于是在 1956 年改以绕太阳轨道公转一年的时间重新定义秒。在 1967 年,秒又被以物理学的属性再一次重新定义:以铯 133 的振荡频率来定义秒,并可以用原子钟来测量。地球自转变慢的主要因素由于潮汐加速,其他因素主要是地球质量的分布不均匀变化,包括冰河反弹,2004 年的印度洋地震使其缩短 2.68 毫秒等。

图 1 展示了国际地球自转和参考系服务(IERS)观测到的地球自转数据。

图 1A 地球自转数据(3D)

图 1B 地球自转数据(2D)

闰秒Leap Second是在协调世界时(UTC)中增加或减少一秒,从而使之与平太阳时贴近所做的调整。

闰秒由国际地球自转和参考系服务发布,图 2 是本次闰秒的公告:

图 2 本次闰秒的公告

在 2016 年 12 月 31 日,http://www.time.gov 展现了这次闰秒(图 3):

图 3 http://www.time.gov 展现了这次闰秒

而 2015 年 6 月 30 日的闰秒事件,影响了纽约股票交易所、多种互联网路由器、Twitter、Instagram、Netflix、Amazon、Altea 航空订票系统等。

闰秒事件的同步实现方式和限制

闰秒在 Linux 系统上的实现方式

目前在 Linux 上多使用 NTP 协议同步时间,在 NTP 的数据包中包含闰秒标志位。在 NTP 时间同步部署正确的情况下,闰秒标志位被传递至最终的客户端,并设置在内核中,闰秒发生时,在系统中将出现 23:59:60 这样的时间,并且由内核控制时间将进行跳跃 1 秒,此时时间将不连续(图 4)。在 CentOS 中由于历史原因和系统的复杂性,闰秒问题变得更为复杂,并且在特定的系统版本中会引起系统挂起高系统负载等内核 BUG 等现象。

图 4 内核控制时间跳跃 1 秒,此时时间将不连续

ntpd 提供了 Slew 模式(-x 参数),但是在存在闰秒标志位的情况下,仅对足够新的 ntpd 版本才有效果。在 Slew 模式正常工作的情况下,系统时间的变化仍然不均匀,并可能引起多节点的不一致(图 5)。

图 5 系统时间的变化仍然不均匀,并可能引起多节点的不一致

业界公司对闰秒的处理

为了使这 1 秒的同步连续且均匀,GoogleAmazon 对闰秒问题提供了不同的解决方案。

Google 的解决方法是修改内部的 Stratum 2 时间服务器软件以进行“闰秒融合”,在闰秒事件发生后均匀的增加(或减少)时间:

其中 ω 为这次融合需要经历的时间。

Amazon 的解决方法是均匀的时间调整。在闰秒事件发生前 12 小时,以每秒 1/86400 秒的步调,最终比 UTC 时间快 0.5 秒;闰秒后比 UTC 时间慢 0.5 秒,在闰秒后 12 个小时再以每秒 1/86400 秒的步调追赶 UTC 时间。 这两种方法都可以使时间连续变化,并且使客户端不会因时间同步服务的突然变化而丢失同步,或者选择其他的时间源,而使集群时间不一致。

我们的问题

在 2015 年的闰秒事件中,我们经历了由闰秒带来的各种系统和软件问题。 在我们的生产环境中,管理着超过 30K 个节点,位于不同地理位置的 IDC,它们使用内部的 Stratum 2 时间源同步。这些节点配置有 ntpd 作为时间同步客户端。使用的操纵系统版本包括 CentOS 6.2 - 6.5 版本。大部分 ntpd 客户端版本为 ntp-4.2.6p5-1.el6, minpoll 和 maxpoll 参数使用默认的配置,即时间稳定后 1024 秒同步一次,时间变化频率不超过 500PPM。 由于操作系统环境的多样性,闰秒标志位若下发则不可避免的触发操作系统和软件的 BUG;节点数量巨大,因此对大批量节点的操作会有不可测的风险;同时考虑到运行服务的性质,因为是在跨年时间调整,提前调整时间可能会对业务逻辑产生影响。我们决定不下发闰秒标志位,在闰秒事件发生后,采用事件发生后缓慢调整的方式进行。

时间融合集群架构和实现

架构和硬件

我们的 Stratum 2 时间同步服务器分布在 3 个 IDC,有 8 台独立的物理机,他们使用互联网上的 4 个相互独立的 Stratum 1 时间源和内部的两台铷原子钟授时时间服务器作为时间同步标准。 位于多个 IDC 的环境,外部独立的时间源,内部低延迟的时间源,使 Stratum 2 时间服务器可以稳定运行。

软件

目前在 CentOS 系列操作系统上可以选择的时间同步软件有 ntpd、chronyd、PTP4L、PHC2SYS。PTP4L、PHC2SYS 需要特定的硬件结构进行同步,而 ntpd 在 slew 模式下无法均匀同步时间。chronyd 作为 CentOS 7 中替换 ntpd 的方案,在 CentOS 7.2 和 6.8 中的 chrony 2.1 版本提供了时间平滑变化的方法。 chronyd 的时间平滑算法分为3个阶段。第一阶段频率(frequency)以固定比率(wander)变化至最大值(max_freq);第二阶段频率维持在最大变化频率(max_freq)足够的时间;第三阶段频率由再以固定比率(wander)变化至 0。假设这个变化从时刻 0 开始,时刻 a 完成第一阶段变化,时刻 b 完成第二阶段变化,时刻 b+a 完成第三阶段变化:

以此方式变化,则时间偏移为:

由于我们的客户端使用 NTP 同步,它的最大允许频率变化为 500PPM(PPM = Part Per Million,10-6 秒),而 500PPM 的变化反映在 1 天的区间,将会达到 43 秒。因此在时间调整过程中,我们不会达到像 500PPM 这样的数量级。因此,以上公式变为:

测试

测试集群包括 1 个节点作为时间调整源(Stratum 1,时间手动调整),3 台时间融合节点(Stratum 2,chronyd),连接至时间融合节点的 Stratum 3 节点(ntpd)和连接到以上节点的 Stratum 4 节点(ntpd)。

以下验证了参数 wander 对时间同步效果的影响

Wander=0.001ppm(图 6,图 7):

图 6

图 7

wander=0.002ppm(图 8、图 9):

图 8

图 9

wander=0.004ppm(图 10、图 11)

图 10

图 11

总结测试数据如下

参数(wander, ppm)

完成同步所需时间 (小时)

客户节点时间偏移幅度

4 级时间是否连续

0.001

17.57

<100ms

0.002

12.42

<100ms

0.004

8.78

>100ms

因为闰秒事件于北京时间早晨 8 点开始,并且需要当天 0 点之前完成同步,因此我们选择使用参数 wander=0.002ppm 进行时间融合。而 max_freq=400ppm。

实施

时间融合节点的选用

时间融合节为改造过的 Stratum 2 节点,使用 x86 服务器。X86 服务器电子振荡器(石英晶振)作为授时元件,它们受外界环境因素影响,主要是温度。而我们的 Stratum 2 时间服务器的授时质量也并不一致。图 12 展示了一周的时间周期内 Stratum 2 时间服务器 Frequency error 的变化。

图 12  Frequency error 的变化

图 12 我们选择其中 4 个变化幅度较小的节点作为时间融合节点,如此 NTP 客户端可以选择其中 3 个节点进行时间同步计算,并且有 1 个节点作为冗余

实施过程和时间点
Table 1. 实施过程和时间点

时间点

操作

结果

闰秒发生前1周

切断外部时间源,使用内部铷钟守时。扫描内部节点,清除闰秒标志位。

使内部节点不受闰秒标志所引起的各种bug影响。

闰秒发生前48小时

时间融合集群上线,使用内部铷钟同步。

使时间融合集群通过铷钟校正稳定。

闰秒发生前8个小时

切断时间同步节点,完全使用时间融合集群守时和同步。

使时间来源一致。

2017年1月1日08:00 UTC+8 闰秒发生

铷钟按照预设算法从GPS获得时间修正并跃迁1秒,时间融合集群开始修正时间。 闰秒发生后12.41小时 无 时间融合结束,时间融合集群重新和内部铷钟同步,客户端时间随之由时间修正转变为稳定性修正。

闰秒发生后24小时

Stratum 2时间同步节点修正时间后上线,并与铷钟和外部时间源同步。

Stratum 2时间同步节点开始同步,在他们稳定之前客户端仍然和时间融合集群同步。

闰秒发生后36小时

Stratum 2时间同步节点与时间源同步,被客户端选择参与时间同步运算。

闰秒发生后48小时

添加外部时间源至时间融合集群节点,时间融合集群作为Stratum 2时间同步节点运作。

闰秒相关变更完成。

时间融合期间的观测数据

时间融合期间,我们在位于 3 个 IDC 与时间融合集群同步的服务器上观测了铷原子钟、时间融合集群、客户端相对与铷原子钟的偏移(图 13、图 14)。观测点同步与铷原子钟。还有时间融合集群 3 个节点间的差距(图 15)。

图 13 相对与铷原子钟的偏移

图 14 相对与铷原子钟的偏移

图 15 时间融合集群 3 个节点间的差距

性能分析

在 12.41 小时的时间融合之后,仍需 1.39 小时使集群与原子钟重新同步,而连接时间融合集群的客户端需要更长的时间进行同步,时间融合集群各节点间差距小于 2ms,生产服务器依照时间融合集群步调融合时间,生产服务器集群和时间融合集群、以及生产服务器之间的时间差距不超过 100ms。

监控和测量方法

监控使用 Collectd 收集数据,Graphite 作为数据存储,Grafana 作为数据展示,数据收集的精度为每 10 秒一次。监测机同步至内部的铷原子钟以获得稳定的参考基线。

结论和后续工作

CentOS 6.8 和 7.2 版本中加入的 Chrony 版本 2.1 提供了一种对时间变化控制的方法,而不需再定制 Stratum 2 节点软件。

通过建立时间融合集群,同步复杂部署环境下超过 30k 个节点的时间变化,将其步调一致的变慢 1 秒。避免了时间变化的不连续和由于闰秒机制带来的潜在 BUG。

在实施过程中也发现了若干问题,在时间融合期间,时间融合服务器的时间变化性能受服务器个体、外界环境温度等因素影响;时间同步受传输过程中经过的长路径设施、防火墙等网络设备时,传输延迟摆动带来的时间不均匀变化也不容忽视。

后续考虑在 Stratum 2 和时间融合节点引入更精确的时间参考标准,比如 PTP、PPS 信号等方式,使时间变化过程控制更加均匀,时间融合节点间的误差更低;在传输设备上部署 PTP,以抵长距离和跨 IDC 网络传输对时间同步带来的影响。

订阅“Linux 中国”官方小程序来查看


最新评论

[1]
next_ [Chrome 55.0|Windows 7] 发表于 2017-01-21 18:24 的评论:
一个超级准的钟,如何证明自己很准呢,和什么参照
来自美国的 Chrome 55.0|GNU/Linux 用户 2017-01-23 03:11 回复
光速。是一个唯一不受参考系影响的物理量。所以校正过程应该会用到光速不变原理。
测试 [Firefox 53.0|Windows 10] 2017-01-20 22:30 回复
前面那段武侠风可以,我很喜欢。
来自河南郑州的 Firefox 49.0|Ubuntu 用户 2017-01-20 09:44 回复
来看看

返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。