Windows Azure의 클럭 동기화 품질?

Windows Azure의 클럭 동기화 품질?

모든 VM이 동일한 데이터 센터에서 호스팅된다고 가정하여 윈도우즈 Azure의 VM 간 클럭 오프셋에 대한 정량적인 추정치를 찾고 있습니다.VM 간의 평균 클럭 오프셋이 10초 미만일 것으로 예상되지만, Azure 클라우드의 보장된 속성인지도 잘 모르겠습니다.

그 문제에 대해 정량적인 측정을 한 사람이 있습니까?

저는 마침내 혼자서 몇 가지 실험을 하기로 결정했습니다.

실험 프로토콜에 관한 몇 가지 사실:

• 참조 클럭에 대한 오프셋을 찾는 대신 Azure VM과 Azure 스토리지 간의 클럭 차이를 확인했습니다.
• Azure 저장소의 클럭 시간은 아래에 붙여넣은 HTTP 해킹을 사용하여 검색되었습니다.
• 250개의 소규모 VM이 있는 Azure의 북유럽 데이터 센터 내에서 측정이 수행되었습니다.
• 스토리지와 VM 간의 지연 시간을 사용하여 측정Stopwatch미니멀리즘적인 인증되지 않은 요청의 경우 항상 1ms 미만이었습니다(기본적으로 HTTP 요청은 400개의 오류와 함께 반환되지만 여전히Date:HTTP 헤더에서 사용 가능).

결과:

• VM의 약 50%가 스토리지에 대한 클럭 오프셋이 1초보다 큽니다.
• VM의 약 5%가 스토리지에 대한 클럭 오프셋이 2초보다 큽니다.
• 클럭 오프셋에 대한 관측치가 1% 미만이면 3초가 닫힙니다.
• 소수의 특이치가 4s에 가깝습니다.
• 단일 VM과 스토리지 간의 클럭 오프셋은 일반적으로 요청마다 +1/-1초씩 다릅니다.

따라서 2초 공차 목표에서 크게 벗어나지는 않았지만 데이터 센터 내 동기화의 경우 4초 오프셋에 가까운 값을 관찰하기 위해 실험을 멀리할 필요는 없습니다.클럭 오프셋에 대한 정규 분포(일명 가우스)를 가정하면 6초 미만의 클럭 임계값에 의존하면 스케줄링 문제가 발생할 수 있습니다.

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

저는 최근에 Azure 제품 팀의 누군가와 클럭 동기화에 대해 이야기를 나누었는데, 무엇보다 관심이 많았습니다.가장 최근에 받은 답변은 다음과 같습니다.

VM 및 서비스는 부팅 시 기본 Hyper-V 플랫폼에서 직접 시간을 소요하며, 그 이후로는 서비스를 통해 클럭을 유지합니다.분산 시스템 전체에서 실제 시간 동기화를 수행하려면 애플리케이션 계층 및/또는 단일 시간 서버를 참조하는 서비스에서 이 작업을 수행해야 합니다.

제 경험에 비추어 볼 때, 저는 Azure VM의 시스템 클럭에 의존하지 않을 것입니다.저는 때때로 몇 분까지 차이가 나는 것을 보았는데, 이것은 여러분이 기대하는 것과는 반대되는 것입니다.

이는 분산 시스템과 가상 시스템 모두에서 발생하는 고전적인 문제인 클럭 스큐입니다.

가능한 한 가지 해결책은 Azure 스케줄러를 사용하여 클럭을 재설정할 각 VM의 끝점에 ping을 수행하거나 최소한 어떤 차이가 있는지 알려주는 것입니다.이렇게 하면 스큐가 증가하지 않고 통신 지연에 대한 오프셋을 계산할 수도 있습니다.이렇게 하면 몇 초가 아니라 몇 초 안에 도달할 수 있습니다.

물론 반대로 VM에서 일부 타임 서버에 ping을 실행하여 주기적으로 클럭을 관리하는 서비스를 사용할 수도 있습니다.하이퍼바이저가 사용자가 시간을 낭비할 수 있도록 할지는 모르겠지만, 실제로 필요한 것은 애플리케이션이 소비할 오프셋만 있으면 됩니다.

전체적으로...VM의 클럭을 신뢰하지 않으며, 분산 시스템에서도 신뢰하지 않습니다.이 시계 문제는 많은 대학에서 활발한 연구의 일부입니다.i. https://scholar.google.com/scholar?hl=en&q=distributed+system+clock&btnG=&as_sdt=1%2C48&as_sdtp=

저는 이 특정 질문에 대한 답을 찾으려고 했지만 성공하지 못했습니다!

"Windows Time Service"(Windows Time Service)에 대해 찾은 몇 가지 참조(W32Time)는 Windows 서비스의 설계가 2초의 허용 오차를 목표로 한다는 것을 나타냅니다.

• http://www.windowsitpro.com/article/time-synchronization/windows-time-synchronization-service
• http://support.microsoft.com/kb/939322

실제로 Azure 네트워크 내에서 달성한 동기화가 이보다 훨씬 더 나을 것으로 예상하지만, 검색 결과 이에 대한 참조 보증은 없었습니다.

분산 시스템을 구축하는 경우 Google Spanner와 같이 특별한 하드웨어 조치를 사용하지 않는 한 클럭 동기화를 신뢰할 수 없습니다.이 경우에도 발생할 수 있는 클럭 스큐 충돌을 해결하기 위해 특수 알고리즘이 사용됩니다.그러나 분산 시스템에서 이 문제를 해결할 수 있는 많은 알고리즘이 있습니다. 논리 클럭, 벡터 클럭, Lamport 타임스탬프 등이 있습니다.Andrew Tanenbaum의 고전적인 책 "분산 시스템: 원리와 패러다임"을 참조하십시오.

언급URL : https://stackoverflow.com/questions/6138955/clock-synchronization-quality-on-windows-azure