在Windows Azure上的时钟同步质量？ [英] Clock synchronization quality on Windows Azure?

问题描述

我要寻找关于时钟偏移虚拟机之间的在Windows Azure上定量估计 - 假设所有的虚拟机都在同一数据中心托管。我的 guesstimating 的是普通时钟一台虚拟机之间的偏移，另一种是低于10秒，但我甚至不能确定它的的保证的Azure云的属性。

I am looking for quantitative estimates on clock offsets between VMs on Windows Azure - assuming that all VMs are hosted in the same datacenter. I am guesstimating that average clock offset between one VM and another is below 10 seconds, but I am not even sure it's guaranteed property of the Azure cloud.

有没有人对这个问题的一些定量测量？

Has anybody some quantitative measurements on that matter?

推荐答案

我终于尘埃落定做我自己的一些实验。

I have finally settled to do some experiments on my own.

有关实验方案的一些事实：

A few facts concerning the experiment protocol:

• 而不是寻找偏移到的的参考时钟的，我只是签的时钟差异的的Azure虚拟机和 Azure存储之间


• 的Azure存储的时钟时间已经使用下面粘贴的HTTP检索破解


• 测量已Azure中的北欧数据中心与250小的虚拟机内完成的。


• 与秒表测量存储和虚拟机之间的延迟总是低于1ms，以适合简约的未经授权的请求（基本上是HTTP请求中回来400错误，但仍与日期：中的HTTP头可用）

• Instead of looking for offset to an reference clock, I have simply checked clock differences between Azure VMs and the Azure Storage.
• Clock time of the Azure Storage has been retrieved using the HTTP hack pasted below.
• Measurements have been done within the North Europe datacenter of Azure with 250 small VMs.
• Latency between storage and VMs measured with Stopwatch was always lower than 1ms for minimalistic unauthenticated requests (basically HTTP requests were coming back with 400 errors, but still with Date: available in the HTTP headers).

结果：

• 虚拟机的大约50％的时钟偏移存储大于1s。


• 虚拟机的大约5％的时钟偏移，存储量比较大2S


• 小于1％的观测时钟偏移近3秒。


• 接近4S - 答handfew异常值。


• 时钟单个VM和存储之间的偏移通常是从一个请求到下一​​个变化的+ 1 / -1s。

所以从技术上说，我们不是从2S宽容目标太远，虽然对于内部数据中心同步，你不必远推实验观察到的接近4S 的偏移量。如果我们假设时钟偏移正常（又名高斯）分布，那么我会说，依靠任何时钟比门槛低6S必然导致调度问题。

So technically, we are not too far from the 2s tolerance target, although for intra-data-center sync, you don't have to push the experiment far to observe close to 4s offset. If we assume a normal (aka Gaussian) distribution for the clock offsets, then I would say that relying on any clock threshold lower than 6s is bound to lead to scheduling issues.

/// <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");
    }
}

这篇关于在Windows Azure上的时钟同步质量？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！