ORACLE EXADATA X8 时间同步服务避坑
⒈ 背景
某Exadata客户X8M-2上多台主机的时间与时钟源的时间不一致。为了解决这个问题，结果掉进坑里，导致存储节点的CELLSRV服务自动重启。
本文主要描述Exadata上的chrony时钟同步服务存在哪些坑，以及如何避免。
2. 入坑及出坑过程
1、驻场的同事发现Exadata X8M-2上有多台主机的时间不一致，检查结果如下所示。
| # dcli -g all_group -l root date
dm02dbadm01: Wed Apr 6 08:25:29 CST 2022 dm02dbadm02: Wed Apr 6 08:25:29 CST 2022 dm02dbadm03: Wed Apr 6 08:21:08 CST 2022 dm02dbadm04: Wed Apr 6 08:20:56 CST 2022 dm02dbadm05: Wed Apr 6 08:25:29 CST 2022 dm02dbadm06: Wed Apr 6 08:25:29 CST 2022 dm02dbadm07: Wed Apr 6 08:25:29 CST 2022 dm02dbadm08: Wed Apr 6 08:25:29 CST 2022 dm02celadm01: Wed Apr 6 08:25:29 CST 2022 dm02celadm02: Wed Apr 6 08:25:29 CST 2022 dm02celadm03: Wed Apr 6 08:25:29 CST 2022 dm02celadm04: Wed Apr 6 08:25:29 CST 2022 dm02celadm05: Wed Apr 6 08:25:29 CST 2022 dm02celadm06: Wed Apr 6 08:17:05 CST 2022 dm02celadm07: Wed Apr 6 08:25:29 CST 2022 dm02celadm08: Wed Apr 6 08:25:29 CST 2022 |
从检查的命令输出可以看出，dm02dbadm03、dm02dbadm04、dm02celadm06这三台主机的时间与其他主机不一致。
2、检查主机的时钟同步服务。我们需要知道，从X8开始，主机的时钟同步服务从以前的NTP变成了现在的chrony。驻场同事查看了这几台主机的chrony服务状态。
可以看出，时间异常的主机chrony服务正常运行。
3、进一步检查时间异常的主机chrony服务的相关信息。
| [root@dm02dbadm03 ~]# chronyc tracking
Reference ID : 00000000 () Stratum : 0 Ref time (UTC) : Thu Jan 01 00:00:00 1970 System time : 0.000001235 seconds fast of NTP time Last offset : -0.010072445 seconds RMS offset : 0.184971273 seconds Frequency : 634.236 ppm fast Residual freq : +0.000 ppm Skew : 0.000 ppm Root delay : 1.000000000 seconds Root dispersion : 1.000000000 seconds Update interval : 16.1 seconds Leap status : Not synchronised [root@dm02dbadm03 ~]# chronyc sources -v 210 Number of sources = 2 .– Source mode ‘^’ = server, ‘=’ = peer, ‘#’ = local clock. / .- Source state ‘*’ = current synced, ‘+’ = combined , ‘-‘ = not combined, | ‘?’ = unreachable, ‘x’ = time may be in error, ‘~’ = time too variable. || .- x [ yyyy ] +/- zzzz || Reachability register (octal) -. | x = adjusted offset, || Log2(Polling interval) –. | | yyyy = measured offset, || \ | | zzzz = estimated error. || | | \ MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^x 时钟服务器1 2 4 377 4 -282.6s[-282.6s] +/- 30ms ^x 时钟服务器2 2 4 377 5 -281.9s[-281.9s] +/- 82ms |
可以看出，虽然chrony服务处于running状态，但是同步状态为Not synchronised，说明了时钟同步过程中出现了问题。该主机的时间与时钟源的时间相差280多秒。
4、为了进行对比，同样使用了chronyc tracking命令检查时间正常的主机，结果发现即使时间正常的主机，chrony服务同步状态也是Not synchronised。这个意外的发现，说明了Exadata上主机的chrony服务不是个别主机存在问题，而是所有主机都存在问题。
5、搜索MOS案例，找到了《OL chronyc tracking shows Leap status Not synchronised when configured with two NTP servers (Doc ID 2814754.1)》这篇文章。意思是：在主机的chrony服务中配置了两个时钟服务器作为时钟源时，则主机的chrony服务同步不会正常工作，如果只配置一个时钟源，或者四个以上的时钟源，则可以正常工作。
如下为文章的部分摘要：
| If more than one NTP server is required, four NTP servers is the recommended minimum. Four servers protect against one incorrect timesource, or “falseticker”.
So if only two servers are set and if the selection state(2nd column) one of them would be having “falseticker” (x) and other having variability (~) , then it might fail to synchronize with them. |
这是chrony服务的第一个坑。那么，如果就是想配置两个时钟源，有没有办法避免出现这个坑呢，在该文章中也给出了一种解决方案。
如果需要配置两台时钟源进行冗余，则可以在/etc/chrony.conf配置文件中，将某个时钟源设置为trust 选项，也即将该时钟源假定为truechimer。例如：
|
server 172.xx.y.33 prefer iburst minpoll 4 maxpoll 4 xleave trust server 172.xx.y.35 iburst minpoll 4 maxpoll 4 xleave |
更改完配置文件后，重新启动chronyd服务生效。
6、驻场同事针对dm02celadm06这台存储节点进行操作，修改完chrony服务的配置文件，重启了chronyd服务，再次检查主机时间，发现此时主机时间与时钟源的时间已经一致，同时，使用chronyc tracking命令检查同步状态为：Normal，这说明chronyd服务已经正常工作。
过了几分钟，更大的问题出现了。同事发现dm02celadm06这台存储节点的CELLSRV服务竟然自动重启了。CELLSRV服务是存储节点的核心服务，CELLSRV服务的重启，意味着该存储节点在这个时间段之间无法对外提供服务。这其实是chrony服务的第二个坑，后面会慢慢道来。
CELLSRV服务自动重启完毕后，同事赶紧查看存储节点的alerthistory日志。命令如下：
|
[root@dm02celadm06 trace]# cellcli -e list alerthistory 1 2022-04-06T14:34:09+08:00 critical “ORA-00600: internal error code, arguments: [ossmisc:ossmisc_time_jumped_forward], [], [], [], [], [], [], [], [], [], [], []” [root@dm02celadm06 trace]# |
可以看出，CELLSRV服务自动重启的时间段，该存储节点同时出现了致命的ORA-00600错误，也许正是这个错误导致了CELLSRV服务重启。
为了获取更多的信息，继续查看alert日志。日志内容如下所示：
|
2022-04-06T14:34:09.495312+08:00 Time went forwards. Real Old Time: 04-06-2022 14:25:17.582. Real New Time: 04-06-2022 14:34:09.494. Monotonic time elapsed: 5 ms. Cellsrv will have to be restarted, since forward drift in time was more than 2000 milliseconds and time_jump_forward_assert is enabled. Errors in file opt/oracle/cell/log/diag/asm/cell/dm02celadm06/trace/svtrc_704_main.trc (incident=17): ORA-00600: internal error code, arguments: [ossmisc:ossmisc_time_jumped_forward], [], [], [], [], [], [], [], [], [], [], [] Incident details in: opt/oracle/cell/log/diag/asm/cell/dm02celadm06/incident/incdir_17/svtrc_704_main_i17.trc 2022-04-06T14:34:09.512389+08:00 [RS] Monitoring process opt/oracle/cell/cellsrv/bin/cellrsomt (pid: 698, srvc_pid: 704) returned with error: 128 CELLSRV error – ORA-600 internal error |
从存储软件的日志可以看出，时间发生了跳动，从14:25:17直接跳到了14:34:09，因为时钟的跳动超过了2秒，所以CELLSRV服务必须重启，接着就出现了这个ORA-00600错误。这个ORA-00600错误不是问题的关键，它只是时钟跳动这个问题的表现。
此时，问题分析的重点在于为什么重启chronyd服务后，主机的时间会直接追平时钟源，而不是慢慢追平？
我们知道，使用NTP服务时，NTP服务每次都只会进行微调，慢慢地追平时钟源，不会出现时间跳动非常大的情况。如果主机与时钟源的时间相差比较大，而且想立即追平时钟源，则需要手动执行ntpdate命令。
此时的chronyd服务，重启后竟然立即追平了时钟源，这说明chronyd服务在配置方面发生了变化。查看chronyd服务的配置文件，发现如下默认配置。
|
# Allow the system clock to be stepped in the first three updates # if its offset is larger than 1 second. makestep 1.0 3 |
默认情况下，chronyd通过减慢或加快时钟速度来逐渐调整时钟。如果主机的时钟与时钟源的时间偏差太大，则需要很长时间才能纠正错误。此时，步进时钟（也即时间跳变）可以快速修正偏差较大的时间误差。
正是由于这个默认配置参数，导致了chronyd服务重启后，主机时间发生了跳变。搜索MOS案例，也能找到相应的文章《Can users modify the chrony setting on Exadata environment (Doc ID 2598297.1)》。该文章中直接注释掉了makestep参数，而改用其他参数。具体如下：
|
/etc/chrony.conf
— modify following — #makestep 1.0 3 ** Comment out makestep leapsecmode slew maxslewrate 1000 smoothtime 50000 0.01 leaponly — |
3. 建议
如果你目前正在使用的Exadata平台， 是X8及更高版本，强烈建议你好好检查一下chrony时钟同步服务，这些坑就不要再踩了。
1、如果配置了两个时钟源，则给其中的某个时钟源加上trust选项；
2、务必注释掉makestep参数，改用其他参数。
