У меня есть один NTP-сервер, который имеет неправильную настройку времени, которая составляет 7 часов в будущем (часовой пояс был изменен после отгрузки машины, но не время). Сам сервер не синхронизируется, а имеет только свои локальные часы. На этом сервере более 10 клиентов синхронизируют свои часы, что приводит к тому, что целая группа серверов показывает неправильное время.
Как я могу изменить время на NTP-сервере, когда коррекция выполняется, и все клиенты тоже будут исправлены? Сначала я тестировал только исправление с помощью "date MMDDhhmm", которое позволяло клиентам отключаться от сервера (звездочка перед именем сервера в ntpq исчезла).
Я не знаю, как все синхронизированные службы будут вести себя, когда я вручную изменю время на всех серверах, переведя часы на 7 часов назад, чтобы в системах были файлы из будущего. Могут быть сбои, и системы предоставляют услуги для потрясающего производства.
Когда вы говорите об изменении времени, вы обычно имеете в виду небольшие промежутки времени. Исправление выполняется с помощью вызова adjtime(), или, может быть, в Linux adjtimex().
На странице руководства ntpd:
-x Normally, the time is slewed if the offset is less than the step
threshold, which is 128 ms by default, and stepped if above the
threshold. This option sets the threshold to 600 s, which is
well within the accuracy window to set the clock manually.
Note: Since the slew rate of typical Unix kernels is limited to
0.5 ms/s, each second of adjustment requires an amortization
interval of 2000 s. Thus, an adjustment as much as 600 s will
take almost 14 days to complete. This option can be used with
the -g and -q options. Note: The kernel time discipline is dis‐
abled with this option.
Я сомневаюсь, что вы захотите дождаться 7-часовой коррекции на этой скорости. На это уйдет больше года. В linux adjtime в 32-битной системе эффективно ограничивается дельтой около 2000 секунд. В 64-битных системах это, вероятно, не проблема, но скорость при котором изменение вступит в силу, по-прежнему вызывает озабоченность.
Таким образом, есть порог в реализации Linux и, предположительно, в других реализациях, ниже которого вы получаете очень медленное «нарастание», но выше этого значения системные часы на главном сервере и клиентах будут ступенчатыми, что может происходить намного быстрее.
Также будет другой порог, при котором, если разница во времени между мастером и клиентом слишком велика, клиент примет ошибку и не обновит. На странице руководства ntpd:
-g Normally, ntpd exits with a message to the system log if the
offset exceeds the panic threshold, which is 1000 s by default.
This option allows the time to be set to any value without
restriction; however, this can happen only once. If the thresh‐
old is exceeded after that, ntpd will exit with a message to the
system log. This option can be used with the -q and -x options.
Обратите внимание, что -g опция почти наверняка не установлена для демона. Обычно он используется как ntpd -gq, запускать как разовое при запуске системы или вручную, что очень похоже на ntpdate. Однако порог паники предположительно настраивается во время компиляции, поэтому проверьте справочную страницу поставщика (-ов) вашей ОС.
Довольно просто написать программу, которая будет выполнять серию корректировок времени, используя любую частоту и размер корректировок, которые вы выберете. Вы можете сделать это на мастере ntp, и он будет обслуживать настроенное время для своих клиентов, но вам нужно знать, какое максимальное изменение размера будут принимать клиентские системы, и какой минимальный порог заставит их выполнять очень медленное нарастание. На всякий случай следует изучить реализации протокола ntp в клиентских системах.
Если вы обновляете системы с характеристиками, аналогичными ntpd по умолчанию в Linux, без -x вариант, то вы можете использовать такой режим, как корректировка на полсекунды каждые 5 секунд, и вы будете синхронизироваться в течение примерно 3 дней. Внесение корректировок в доли секунды, которые не пересекают вторую границу, может помочь избежать таких вещей, как запуск заданий cron дважды, но ожидайте, что вы, вероятно, обнаружите какие-то побочные эффекты.
Если вы окажетесь в ситуации, когда все ваши серверы больше не синхронизированы друг с другом, все станет еще хуже. Если возможно, я бы хотел отслеживать разницу во времени и автоматически прекращать автоматические периодические обновления, если некоторые серверы больше не следят за ними, и выдавать предупреждение.
Как вы знаете, клиенты останутся синхронизированными, если изменение часов происходит в пределах небольшого интервала. В некоторых системах это всего пять минут. Ваш может быть 10 минут. Вы можете переключать часы в пределах этого интервала, и клиенты будут поворачиваться, чтобы отслеживать.
Я вижу четыре варианта:
Ничего не делать и жить с неправильным временем бесконечно.
Установите часы на четыре минуты (или девять минут, если у вас интервал 600 секунд) и повторите до тошноты в течение года, что mc0e имеет расчет необходимо. Вы бы действительно хотели сделать это с помощью сценария. Допустим, что большую часть этого года пока неверно. Сделайте подробные записи о временном сдвиге, чтобы сопоставить его с производственными отчетами.
Отключите серверы на семь часов обслуживания (Рождество, кто-нибудь?) И исправьте все часы за один присест.
Прыгайте по часам и убедитесь, что все знают, что отчеты будут перекрываться в течение семи часов. Однако эти же люди уже должны знать, что время производства сокращается на семь часов, так что вы можете найти это приемлемым. (Очевидно, я не знаю, какое влияние это окажет на ваши производственные процессы.)
Ни одно из решений не является идеальным. Если важны сроки производственной отчетности, то вариант 2, вероятно, наихудший из плохих.