丙申年，庚子月，戊子日。
西元二〇一七年元日，帝都霾，不禁杀。
从立秋到冬至，乃决大辟罪之季。
柴市牌楼前，人头涌动，听说今日要处决一重犯，大家都拿着瓜子端着茶壶出来看热闹。
十字路口上，面向南方跪着一位蓬头垢面的犯人，身披三械，背后斜插着一支亡命牌。身边一名刽子手，袒胸露乳，一身腱子肉闪着黝黑的光亮，双手端着一把鬼头刀，寒光凌厉。在重犯身后五丈远的地方，放置着一具长案，案上台布一片腥红，桌上还放着一筒火签，旁边有一个香炉，里头插着一根三寸长的檀香。桌后四仰八叉慵懒闲散躺着一位监斩官，不停用嘴吹着檀香，好快点燃完。
太阳像一张没有烙熟的鸡蛋煎饼，无力地透过厚厚的雾层，耷拉在圭表上。石柱的影子虚弱地投在坑坑洼洼的石板上，实在难以辨认现在是几时几刻。
檀香还剩一寸的时候，监斩官已经失去耐心，猛地翻起身来，从签筒里胡乱抽出一支火签令，扔到桌前面的地上：『吉时已到，行刑』。
刽子手双手举刀过头，口中碎碎念叨，全身肌肉绷得紧紧地，拧腰沉肘，一道青霜。
突然犯人仰头长笑几声：『哈哈哈哈』，惊得牌楼上循着血腥味来觅食的几只乌鸦扑棱棱飞起。刽子手也愣了一下，没料到他会在这生死关头突然发笑，手中的刀自然也就没有再落下来。
监斩官眯着眼睛道：『你不知死到临头，为甚做这鬼叫声！』
犯人若有所思道：『看来专家说得没错，每天笑一笑，可以延长寿命五秒钟。』
监斩官道：『弱爆了，专家的话你也信！你难道不知，你今日已经多活了一秒！』
犯人蒙逼道：『此话怎讲？』
监斩官鄙夷道：『闰秒！』
历史和闰秒问题的提出
最初，秒是依据地球绕着轴自转和绕太阳的公转，以平均太阳日的 1/86400 来定义（太阳时）。到了 20 世纪中叶，很明显的，地球自转没有提供足够一致的标准，于是在 1956 年改以绕太阳轨道公转一年的时间重新定义秒。在 1967 年，秒又被以物理学的属性再一次重新定义：以铯 133 的振荡频率来定义秒，并可以用原子钟来测量。地球自转变慢的主要因素由于潮汐加速，其他因素主要是地球质量的分布不均匀变化，包括冰河反弹，2004 年的印度洋地震使其缩短 2.68 毫秒等。
图 1 展示了国际地球自转和参考系服务（IERS）观测到的地球自转数据。
图 1A 地球自转数据（3D）
图 1B 地球自转数据（2D）
闰秒是在协调世界时（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 秒的同步连续且均匀，Google 和 Amazon 对闰秒问题提供了不同的解决方案。
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 个节点作为冗余。
实施过程和时间点
时间点 |
操作 |
结果 |
闰秒发生前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 网络传输对时间同步带来的影响。
原文发布时间为：2017-01-20
本文来自云栖社区合作伙伴“Linux中国”
