对于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 就这么简单~~~
