В смешанной среде, где машины могут работать под Windows (большинство), Linux (немного), иногда Android ... как лучше всего иметь синхронизацию времени с точностью, близкой к миллисекундам?
Мы разрабатываем решение на основе микросервисов, в котором сервисы разбросаны по нескольким машинам в наших настройках. Во многих ситуациях для объединения информации между ними (журналы, мониторинг и т. Д.) Требуется общая временная база.
Использование NTP под Windows, похоже, имеет определенные ограничения. Любое решение с открытым исходным кодом, которое можно было бы запустить в этой операционной системе? Мы не можем гарантировать, что в наших настройках всегда будет Linux-машина.
[РЕДАКТИРОВАТЬ] Существенное переписывание со ссылками, поскольку я только что записал старый ответ по памяти.
Короткий ответ: нет. Сегодня невозможно получить точность с точностью до миллисекунды от обычной операционной системы на платформе x86 / x64.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ Это ответ непрофессионала, поскольку я обычный системный администратор с обычным взглядом системного администратора на компьютеры. Профессиональный уровень знаний в области хронометража, вероятно, есть у некоторых разработчиков ядра и архитекторов оборудования.
Длинный ответ:
С чего-то надо начинать. Я буду делать это сверху вниз, начиная с приложений, движущихся вниз к осцилляторам.
Первая проблема заключается не в том, чтобы вести хронометраж на одном компьютере, а в том, чтобы заставить среду в целом согласовать то, что у вас есть. Какой хронометраж? Оказывается, есть несколько способов сохранить время в современном компьютере. Больше всего мы видим системное время (отображаемое в одном из углов экрана). Давайте начнем с того, что притворимся, что это так просто, и усложним все на пару абзацев ниже.
Мы хотим, чтобы системное время было правильным, и мы хотим, чтобы оно было единообразным на всех наших компьютерах. Нам нужен способ сообщить об этом из надежного источника на таком детальном уровне, чтобы удовлетворить наши требования, какими бы они ни были.
Давайте сделаем наше требование допустимым на уровне 1 мс, то есть наше время может отклоняться на 1 мс в нашей среде, или мы пропустим критическую цель. Давайте конкретизируем и посмотрим, что Microsoft может для нас сделать.
За исключением устаревших, таких как NT, собственная версия Windows работает с хронометражем на основе упрощенного ntp (компьютеры, присоединенные к домену, начиная с XP / 2003) или упрощенного sntp (компьютеры, не присоединенные к домену, начиная с Win2k) - спасибо @Ryan за придирчивость этой детали . Microsoft поставила две цели при реализации хронометража, ни один из которых не включает желаемый уровень точности:
«Мы не гарантируем и не поддерживаем точность службы W32Time между узлами в сети. Служба W32Time не является полнофункциональным решением NTP, которое удовлетворяет потребности приложений, чувствительных ко времени. Служба W32Time в первую очередь предназначена для выполнения следующий:
Служба W32Time не может надежно поддерживать время синхронизации в диапазоне от одной до двух секунд. Такие допуски выходят за рамки проектной спецификации службы W32Time ".
ХОРОШО. Предполагая, что мы запускаем ваш стек сервисов на нескольких компьютерах и имеем уровень допуска хронометража, приближающийся к 1 мс для корреляции событий, это довольно разочарование. Если в стек служб входят два компьютера, мы вообще не сможем использовать собственное хронометраж Windows. Но пока мы это делаем, давайте подчеркнем пару ключевых моментов, касающихся собственного хронометража Windows, и включим некоторую подробную документацию:
Если у вас есть AD, обратите внимание, что время в данном домене будет синхронизироваться с ролью эмулятора PDC, в зависимости от того, какой DC он имеет. Таким образом, ввод правильного времени в домен должен осуществляться через контроллер домена, выполняющий роль эмулятора PDC. Если в многодоменном лесу это преобразуется в эмулятор PDC корневого домена леса. Оттуда время распределяется в основном между эмуляторами PDC поддоменов и каждому члену домена в виде разветвления (с некоторыми оговорками). Этот процесс задокументировано здесь. Еще более подробная информация Вот
ХОРОШО. Что мы можем сделать?
Для начала нам понадобится один или Другой более точный способ синхронизации времени в окружающей среде. Предполагая, что мы не можем запустить Linux ntpd или ntpd для Windows вы можете взглянуть на условно-бесплатный клиент под названием ТАРДИС, но, вероятно, есть гораздо больше, чтобы попробовать.
Мы запускали Tardis на сервере Win2k3, работающем как эмулятор PDC, у которого были часы CMOS с действительно большим перекосом, по необъяснимым историческим причинам у нас не было другого выбора, кроме как синхронизировать с ним всю сеть. Теперь его, к большой радости, заменили на специальный Linux ntpd, который извлекает время из атомных часов снаружи, но Тардис прекрасно спас нас тогда и там. Однако я не знаю, может ли это помочь вам добиться большей точности, чем у Windows.
Но давайте предположим, что с этого момента мы (мы) выяснили, как реализовать идеальную замену сетевой синхронизации времени. Благодаря присущей ему хитрости он может выдерживать уровни менее одной миллисекунды. Мы внедрили его, чтобы определить, как наша AD ожидает, что время будет распространяться по сети.
Означает ли это, что мы можем получать точную диагностику операционных систем и микросервисов с точностью до миллисекунд?
Давайте посмотрим, как операционные системы на архитектуре x86 / x64 распределяют время процессора.
Они используют прерывания, которые многогранные звери, богатые археологическим материалом. Однако не только операционная система стремится к прерыванию. Оборудование тоже хочет прервать, и у него есть средства для этого! (Привет, клавиатура) И операционные системы подыгрывают.
Здесь все усложняется, и я решу это путем упрощения. Вопросы? Я пригибаюсь, прикрываю и указываю на абсолютно отличный трактат на эту тему. (Если вы ищете миллисекунды на платформе Windows, вам действительно стоит это прочитать ..) Обновленная версия для Win8.1 / Win2012r2 - как сообщается, в работе но дата релиза еще не появилась.
Хорошо, перебивает. Всякий раз, когда что-то должно произойти в ОС, прерывание запускает последующее действие. Действие представляет собой набор инструкций, извлеченных из ядра, которые могут быть выполнены в целая партия из разные манеры. Суть в том, что, несмотря на то, что прерывание происходит в то время, которое может быть определено с большей или меньшей точностью в зависимости от аппаратной архитектуры и обработки прерывания ядра, точное время, в которое последующие части выполнения обычно происходят, невозможно. Конкретный набор инструкций может быть выполнен на ранней стадии после прерывания или позже, он может быть выполнен в предсказуемой последовательности или нет, он может быть жертвой неисправного оборудования или плохо написанных драйверов, влияющих на задержки, которые трудно даже распознать. В большинстве случаев человек просто не знает. Отметка времени на уровне миллисекунд, которая отображается в следующем файле журнала - это очень точно, но точно ли это относительно того, когда произошло событие?
Давайте ненадолго остановимся на прерывании хронометража. Прерывание имеет уровень приоритета, на самом низком уровне пользовательские приложения (например, стандартная служба) получают свое процессорное время. Другие (более высокие) уровни зарезервированы для оборудования и работы ядра. Если поступает прерывание на уровне выше самого низкого, система будет делать вид, что прерывания с более низким приоритетом, также находящиеся в очереди, не существуют (до тех пор, пока не будут обработаны прерывания с более высоким приоритетом). Таким образом, обычные приложения и службы будут работать последними по времени процессора. Напротив, прерыванию часов отдается почти высший приоритет. Обновление времени почти всегда происходит в системе. Это почти преступное упрощение того, как все это работает, но оно служит цели этого ответа.
Время обновления фактически состоит из двух задач:
Обновление системного времени / AKA настенные часы / AKA то, что я говорю, когда кто-то спрашивает меня, который час / AKA вещь, которую ntp играет немного взад и вперед относительно соседних систем.
Обновление счетчика тиков, используемого, например, при измерении продолжительности выполнения кода.
Но если это время стены или счетчик тиков, откуда система берет время? Это сильно зависит от архитектуры оборудования. Где-то в оборудовании тикают один или несколько осцилляторов, и это тиканье передается через один из несколько возможно пути в интерфейс для связи с ядром, поскольку оно с большей или меньшей точностью обновляет время своей стены и количество тактов.
Существует несколько моделей размещения осцилляторов в многоядерной системе, основное отличие заключается в синхронном и асинхронном размещении. Они вместе с их соответствующими проблемами точного хронометража описаны. Вот например.
Короче говоря, синхронное хронометрирование имеет один эталонный тактовый генератор на многоядерник, который распределяет свой сигнал по всем ядрам. Асинхронный хронометраж имеет по одному генератору на ядро. Стоит отметить, что в последних многоядерных процессорах Intel (Haswell) используется некоторая форма синхронной конструкции с использованием последовательной шины, называемой «QuickPath Interconnect» с «Forwarded Clocking», исх. техническая спецификация. Перенаправленная синхронизация описывается таким образом, чтобы непрофессионал (я) мог быстро получить поверхностное представление о ней. Вот.
Итак, со всем этим задротом (который продемонстрировал, что хронометрирование - сложная практическая задача с большой живой историей), давайте еще ближе рассмотрим обработку прерываний.
Операционные системы обрабатывали прерывания, используя одну из двух различных стратегий: с тиканием или без тика. В ваших системах используется один или другой, но что означают эти термины?
Отметить ядра отправлять прерывания через фиксированные интервалы. ОС не может измерять время с более высоким разрешением, чем тиковый интервал. Даже в этом случае фактическая обработка, связанная с выполнением одного или нескольких действий, может содержать задержку, превышающую тактовый интервал. Рассмотрим, например, распределенные системы (такие как микросервисы), в которых задержки, присущие межсервисным вызовам, могут занять относительно много времени. Тем не менее, каждый набор инструкций будет связан с одним или несколькими прерываниями, измеренными ОС с разрешением, не меньшим, чем время отсчета ядра. Время тика имеет базовое значение, но, по крайней мере, в Windows может быть уменьшено по запросу отдельным приложением. Это действие связано не только с выгодами, но и с затратами, и несет совсем немного мелкого шрифта с этим.
Так называемый бестиковые ядра (которые имеют очень неописательное название) - относительно новое изобретение. Ядро без тиков устанавливает время тика через переменные интервалы (как можно дольше в будущем). Причина в том, что ОС динамически позволяет ядрам процессора как можно дольше переходить в различные уровни сна с простой целью экономии энергии. «Различные уровни» включают инструкции по обработке на полной скорости, обработку с уменьшенной скоростью (то есть более медленную скорость процессора) или отсутствие обработки вообще. Разным ядрам разрешено работать с разной скоростью, и ядро без тиков пытается позволить процессорам быть как можно более неактивными, даже в случаях, включая создание очереди инструкций для их запуска в пакетах прерываний. Короче говоря, разные ядра в многопроцессорной системе могут дрейфовать во времени относительно друг друга. Это, конечно, наносит ущерб хорошему хранению времени и до сих пор является нерешенной проблемой с новыми архитектурами энергосберегающих процессоров и ядрами без тиков, которые позволяют им эффективно экономить энергию. Сравните это с тикающим ядром (статический интервал тиков), которое постоянно пробуждает все ядра процессора, независимо от того, получают ли они фактическую работу или нет, и где хронометраж имеет некоторую неточность, но в относительно надежной степени по сравнению с ядрами без тиков.
Стандарт Время тика Windows - то есть разрешение системы - составляет 15,6 мс. вплоть до Windows 8/2012, где поведение по умолчанию не имеет галочки (но может быть возвращено к галочному ядру). Я считаю, что время тика Linux по умолчанию зависит от компиляции ядра, но эта ниша является хорошо вне моего опыта (и вот этот тоже), так что вы можете дважды проверить, зависите ли вы от него. Я считаю, что ядра Linux скомпилированы без тиков начиная с версии 2.6.21 и могут быть скомпилированы с различными флагами, оптимизирующими поведение без тиков (из которых я помню только несколько вариантов no_hz).
Так обстоит дело с системами без покрытия. В виртуальных системах ситуация ухудшается, поскольку конкуренция между виртуальными машинами и гипервизорами по-разному сильно затрудняет точное хронометраж. Вот это обзор для VMware и вот один для RHEL KVM. То же самое верно и для распределенных систем. Облачные системы еще сложнее поскольку мы даже близко не подошли к тому, чтобы увидеть настоящие гипервизоры и оборудование.
В заключение, получение точного времени из системы - многослойная проблема. Двигаясь теперь снизу вверх с точки зрения высокого уровня, мы должны решить: внутреннюю синхронизацию времени между оборудованием и ядром, обработку прерываний и задержки выполнения инструкций, время которых мы желаем, если в виртуальной среде неточности за счет инкапсуляции второго уровня ОС - синхронизация времени между распределенными системами.
Поэтому на данном этапе истории вычислений мы не сможем добиться точности миллисекундного уровня от архитектуры x86 / x64, по крайней мере, не используя какие-либо обычные операционные системы.
Но как близко мы можем подойти? Я не знаю, и это должно сильно отличаться в разных системах. Справиться с неточностями в собственных конкретных системах - непростая задача. Стоит только взглянуть на как Intel предлагает проводить сравнительный анализ кода чтобы увидеть, что обычные системы, такие как те, которые я администрирую, очень сильно вышли из-под контроля с этой точки зрения.
Я даже не думаю о том, чтобы «Все функции оптимизации энергопотребления, технологии Intel Hyper-Threading, масштабирования частоты и турбо-режима были отключены» в критических системах гораздо меньше возиться с оболочками кода на C и проводить долгосрочные тесты для получения последующих ответов. Я просто стараюсь поддерживать их жизнь и узнавать о них как можно больше, не беспокоя их слишком сильно. Спасибо, отметка времени, я знаю, что не могу полностью вам доверять, но я знаю, что у вас не так много секунд. Когда важна фактическая точность в миллисекундах, одного измерения недостаточно, но требуется большее количество измерений для проверки шаблона. Что еще мы можем сделать?
Напоследок интересно посмотреть на как операторы реального времени думают о задержке прерывания. Также есть очень захватывающая альтернатива синхронизации времени в работах, где довольно много интересного статистика, методология и белые бумаги обнародованы. Добавьте к этому будущую аппаратную архитектуру и разработки ядра, и через несколько лет точность хронометража перестанет быть такой проблемой. Можно надеяться.
Изначально time.windows.com используется операционными системами Microsoft. Если вам нужно что-то более конкретное, я бы посоветовал использовать Сервер времени в Интернете NIST. Они даже запускают аутентифицированный NTP, если вас беспокоит взлом. Если и этого недостаточно, вы всегда можете запустить свой собственный. Есть ряд поставщиков, которые продают серверы NTP уровня 1 или 2, которые вы можете просто подключить к своей сети. Stratum относится к различным методам, используемым для проверки времени. Уровень 1 будет использовать только один метод (NTP, CDMA, GPS), тогда как уровень 2 будет использовать два метода.