对于CDN来说,时间是个非常重要的概念,squid的缓存刷新控制,全都是以服务器时间为基准。在我博客的前不知道几篇的某文中,就提到过因为时间的原因引起的刷新事故。而最新的一次,是公司在日志流量统计时,因为相差太大导致截取失败——这可都是钱呢。
实际工作中,大多会搭建一个NTP服务器,给应用服务器提供时间同步服务。但虚拟机在这方面有个问题。虚拟机的时间是读取的宿主机的硬件时钟,随便你date
-s 1234怎么改,下一次date查看,都会恢复成原样。
这样看起来是个好事,因为这样可以省略掉大批机器的NTP服务器同步时间的压力。但糟糕的事情在后头:一大批重要客户的虚拟机,在运行上半年以上时间后,date都比真实时间超前了(偶然我也看到过一次滞后的)。或许是几分钟,或许是几小时!!
这一度让我很无奈,因为即使我重启虚拟机,这个诡异的date也依然倔强的按照它自己的时钟前进。看起来办法只有一个:把虚拟平台整个的重启——好在这种试验的结果是有效的,不然真不知道怎么办了。
从这个无奈的办法中,也应该可以推测出一个结论,虚拟机的时钟,应该是另有文件存储在虚拟平台的某个临时文件里。所以关闭虚拟机,该文件还存在并继续计时;重启动虚拟平台,该文件才会重计。至于这个文件叫什么,存放在哪里,一时半会我就找不到了,或许这个问题不算什么特别大的问题,至少我在linuxsir.org的《xen初学指南》中,没有找到关于时钟的配置说明。
不过再小的问题也顶不住人的研究。于是我找到了另一篇很对口的文章:《虚拟机中GUEST OS时钟(TIMEKEEP)问题的探讨》。
文章告诉我们:虚拟机的时钟,与真实机的时钟区别,其一在于其处理不是抢占中断而是延迟处理;其二在于其中断模拟软件可能因资源占用问题被推迟。
这两点区别,导致的结果却是一个,就是一旦服务器负载变高,时钟中断就被排到后头去了……
文章也提出了解决办法,一个是编程,让系统补上中断的时间,这个俺就不说了;一个是修改内核,让系统不断修正date;
进一步问题:不管哪个办法,第一,加重了虚拟机负载;第二,这又依赖与系统去更新date的进程的精准度,而这个进程的中断时钟如果有偏差的话,……
再进一步方法……有兴趣的还是自己点文章看吧。
看起来这个问题就要永远终结在此了。
不过变通的主意及时的出现了——既然虚拟机跟虚拟平台之间的异步时钟同步没法解决,我们就干脆不要虚拟机跟虚拟平台同步了。这样虽然对NTP的压力大了,但毕竟保证了CDN的正常。而且从上头的原理可以知道,能够导致date偏差到这个程度的原因,大概也是因为虚拟机的负载压力太大。事实上,我们为了保证冗余,也是尽量避免这种压力出现的。那么date偏差的服务器,其实也就是少数了。
顺着这个思路一查,原来办法其实很简单——修改虚拟机的independent_wallclock值即可:
echo 1 > /proc/sys/xen/independent_wallclock
或sysctl xen.independent_wallclock=1
启用虚拟机独立系统时间;
/etc/init.d/ntpd stop
ntpdate 192.168.0.1
就能完成NTP时间同步了;
再date看看,时间果然就更正了~~
/proc下的文件都是进程使用中的文件,如果要让虚拟机开机自动读取配置,把这个修改写进/etc/sysctl.conf才行哦:
echo “xen.independent_wallclock = 1” » /etc/sysctl.conf
就这么简单~~~