Windows Azure上的时钟同步质量?

时间:2011-05-26 13:05:35

标签: synchronization azure clock

我正在寻找Windows Azure上虚拟机之间时钟偏移的定量估算 - 假设所有虚拟机都托管在同一个数据中心。我猜测一个VM与另一个VM之间的平均时钟偏移低于10秒,但我甚至不确定它是Azure云的保证属性。

有没有人对此事进行定量测量?

6 个答案:

答案 0 :(得分:27)

我最终决定自己做一些实验。

关于实验方案的一些事实:

  • 我只是检查 Azure VM Azure存储之间的时钟差异,而不是查找参考时钟的偏移量即可。
  • 使用下面粘贴的HTTP hack检索Azure存储的时钟时间。
  • 已在Azure的北欧数据中心内进行了测量,其中包含250个小型虚拟机。
  • 对于简约的未经身份验证的请求,使用Stopwatch测量的存储和VM之间的延迟始终低于1毫秒(基本上HTTP请求返回400个错误,但仍然在HTTP标头中提供Date:

<强>结果:

  • 大约50%的虚拟机的存储时钟偏移大于1秒。
  • 大约5%的虚拟机的存储时钟偏移大于2秒。
  • 时钟偏移的观测结果不到1%接近3s。
  • 手足差距接近4s。
  • 单个VM与存储之间的时钟偏移量通常从一个请求到下一个请求的变化范围为+ 1 / -1。

从技术上讲,我们距离2s容差目标并不太远,但对于数据中心内同步,您不必将实验推向远近观察接近4s 偏移。如果我们假设时钟偏移的正常(又称高斯)分布,那么我会说依赖于低于6s的任何时钟阈值必然会导致调度问题。

/// <summary>
/// Substitute for proper NTP (Network Time Protocol) 
/// when UDP is not available, as on Windows Azure.
/// </summary>
public class HttpTimeChecker
{
    public static DateTime GetUtcNetworkTime(string server)
    {
        // HACK: we can't use WebClient here, because we get a faulty HTTP response
        // We don't care about HTTP error, the only thing that matter is the presence
        // of the 'Date:' HTTP header
        var tc = new TcpClient();
        tc.Connect(server, 80);

        string response;
        using (var ns = tc.GetStream())
        {
            var sw = new StreamWriter(ns);
            var sr = new StreamReader(ns);

            string req = "";
            req += "GET / HTTP/1.0\n";
            req += "Host: " + server + "\n";
            req += "\n";

            sw.Write(req);
            sw.Flush();

            response = sr.ReadToEnd();
        }

        foreach(var line in response.Split(new[] { '\r', '\n' }, StringSplitOptions.RemoveEmptyEntries))
        {
            if(line.StartsWith("Date: "))
            {
                return DateTime.Parse(line.Substring(6)).ToUniversalTime();
            }
        }

        throw new ArgumentException("No date to be retrieved among HTTP headers.", "server");
    }
}

答案 1 :(得分:8)

我最近与Azure产品团队的某个人就时钟同步进行了对话,更多的是出于对其他任何事情的兴趣。我收到的最新回复是:

  

虚拟机和服务直接从底层获取时间   Hyper-V平台在启动时从那一点开始计时   由服务维护。为了实现真正的时间同步   分布式系统,您需要在应用程序层执行此操作   和/或引用单个时间服务器的服务。

答案 2 :(得分:3)

根据我的经验,我不会依赖Azure VM的系统时钟来处理任何关键问题。我偶尔会看到差异达到几分钟,但面对你期望的情况,这种差异确实存在。

答案 3 :(得分:3)

这是分布式系统和虚拟机的典型问题 - 时钟偏差。

一种可能的解决方案是使用Azure调度程序ping您的每个VM上的端点,这将重置您的时钟 - 或者至少告诉您差异将是什么。这样,你的偏斜就不会增长,你甚至可以计算通信延迟的偏移量。这样,你就可以在几毫秒而不是几秒内完成。

当然,您也可以采用其他方式,并通过ping到某个时间服务器,在VM上定期管理时钟。我不确定虚拟机管理程序是否会让你弄乱它的时钟,但你真正需要的只是你的应用程序消耗的偏移量。

总体而言......从不信任VM上的时钟,当然也不会信任分布式系统上的时钟。请注意,这个时钟问题是许多大学积极研究的一部分。即。 https://scholar.google.com/scholar?hl=en&q=distributed+system+clock&btnG=&as_sdt=1%2C48&as_sdtp=

答案 4 :(得分:1)

我试图寻找这个具体问题的答案 - 但是没有成功!

我发现了一些关于&#34; Windows时间服务&#34; - W32Time - 引用Windows服务的设计目标是 2秒的容差 - 例如

在Azure网络中的实践中,我希望实现的同步应该比这更好 - 但是我的搜索在此没有引用保证。

答案 5 :(得分:0)

如果要构建分布式系统,则永远不能信任时钟同步,除非在Google Spanner中使用特殊的硬件措施。即使有一种特殊的算法用于解决可能的时钟偏差冲突。 但是,有许多算法可以解决分布式系统中的这个问题:逻辑时钟,矢量时钟,Lamport时间戳等等。参见Andrew Tanenbaum的经典着作“分布式系统:原理和范例”。