Я ищу количественные оценки смещения часов между виртуальными машинами в Windows Azure - при условии, что все виртуальные машины размещены в одном и том же центре данных. Я полагаю, что среднее смещение часов между одной виртуальной машиной и другой составляет менее 10 секунд, но я даже не уверен, что это гарантированное свойство облака Azure.
Есть ли какие-то количественные измерения в этом отношении?
Я, наконец, решил провести некоторые эксперименты самостоятельно.
Несколько фактов, касающихся протокола эксперимента:
Stopwatch, всегда была ниже 1 мс для минималистических неавторизованных запросов (в основном запросы HTTP возвращались с 400 ошибками, но все еще с Date:, доступными в заголовках HTTP).Результаты:
Таким образом, технически мы не слишком далеки от цели толерантности 2s, хотя для синхронизации внутри данных и центра вам не нужно сильно экспериментировать, чтобы наблюдать за смещением 4 с. Если мы предположим, что для смещений часов нормальное (aka гауссово) распределение, то я бы сказал, что полагаться на любой порог часов ниже 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 о синхронизации часов, больше из интереса, чем что-либо еще. Самый последний ответ, который я получил:
Виртуальные машины и службы берут свое время непосредственно из основного Платформа Hyper-V при загрузке и с этой точки вперед обслуживаемых службой. Чтобы иметь истинную синхронизацию по времени распределенной системе вам нужно будет сделать это на уровне приложения и/или со службой, ссылающейся на сервер с особым временем.
Основываясь на моем опыте, я бы не стал полагаться на системные часы Azure VM для чего-то критического. Я иногда видел разницу до нескольких минут, что действительно ложится перед лицом того, что вы ожидаете.
Это классическая проблема как распределенных систем, так и виртуальных машин - перекос часов.
Одним из возможных решений было бы использовать планировщик Azure для ping конечной точки на каждой вашей виртуальной машине, которая будет reset ваши часы, или, по крайней мере, рассказать вам, что такое diff. Таким образом, ваш перекос не будет расти, и вы даже сможете вычислить смещение за задержку связи. Таким образом, вы получите в течение миллисекунд, а не секунд.
Конечно, вы также можете пойти другим путем и иметь службу на виртуальной машине, которая периодически управляет часами, вызывая на некоторое время сервер. Я не уверен, что гипервизор позволит вам возиться с этим часами, но все, что вам действительно нужно, - это смещение, которое ваши приложения будут потреблять.
В целом... никогда не доверяйте часам на виртуальной машине и, конечно же, не по распределенной системе. Обратите внимание, что эта часовая проблема является частью активных исследований во многих университетах. то есть. https://scholar.google.com/scholar?hl=en&q=distributed+system+clock&btnG=&as_sdt=1%2C48&as_sdtp=
Я попытался найти ответ на этот конкретный вопрос - но не удалось!
Некоторые ссылки, которые я нашел о "службе времени Windows" - W32Time, ссылаются на то, что дизайн для службы Windows нацелен на допуск в течение 2 секунд - например,
На практике в Azure-сети я ожидаю, что достигнутая синхронизация будет намного лучше, чем это, но мой поиск не предоставил никаких гарантий по этому поводу.
Вы никогда не сможете доверять синхронизации часов, если вы создаете распределенную систему, если не используются специальные аппаратные меры, например, в Google Spanner. Даже там специальный алгоритм используется для разрешения возможных конфликтов косой чаши. Однако есть много алгоритмов, которые позволяют решить эту проблему в распределенных системах: логические часы, векторные часы, временные метки Lamport, чтобы назвать несколько. См. Классическую книгу "Распределенные системы: принципы и парадигмы" Эндрю Таненбаума.