☰

NTP-сервер, который синхронизируется с другими NTP-серверами, но предоставляет измененное UTC

tag-icon • tag-icon ntp time-synchronization utc
NTP-сервер, который синхронизируется с другими NTP-серверами, но предоставляет измененное UTC

Вопрос

Нам необходимо создать NTP-сервер, который синхронизируется с другими NTP-серверами, но предоставляет своим клиентам измененное UTC.

Например, он получит время 17:17 по Гринвичу, а его клиенты получат время 19:17 по Гринвичу.

Текущая ситуация/проблема

Я опишу текущую ситуацию, чтобы вы поняли причину этой потребности. Некоторые термины, которые я буду использовать, из мира мэйнфреймов, поэтому я попытаюсь их объяснить.

У нас есть несколько LPARS (похожих на гостевую виртуальную машину) на одной физической машине. LPARS сгруппированы в несколько Sysplexes (похожих на кластер). LPARS в каждом Sysplex синхронизируются с помощью ETS, который подключен к машине и напрямую изменяет часы каждого LPAR.

Несколько лет назад кто-то подумал, что будет отличной идеей установить часы ETS на местное время (сайт не находится в UTC±00:00). LPAR получают UTC из часов ETS. Мы не можем изменить часы ETS на реальное UTC, не затронув всю машину. Сначала мы хотим протестировать изменение в тестовых средах. Мы можем изменить метод синхронизации на STP (протокол времени сисплекса), который управляет каждым сисплексом отдельно. Этот метод использует внешний сервер ntp.

Итак, сначала мы хотим изменить один сисплекс для использования STP, который получает ложное UTC, и выполнить тестирование, если мы правильно установили STP. А затем изменить utc и выполнить тестирование, что система может работать с реальным utc.

Спасибо, Вольф.

решение1

Во-первых, троекратное ура тебе, WolfThreeFeet, за то, что ты объяснил, что пытаешься сделать; без этого вопрос и вправду пустая трата времени.

Если я правильно понимаю, вы хотите подтвердить, что при изменении часов сисплекса с местного времени на UTC не все LPAR-разделы выходят из строя и не выходят из строя, и вы хотите протестировать это в dev-сисплексе, прежде чем распространять на всю машину.

Я не думаю, что возможно сделать то, что вы описываете.в том смысле, как вы это описываете, но я думаю, что вы можете сделать что-то эквивалентное. Настройте тестовую машину, чьей единственной задачей будет быть NTP-сервером с неправильными часами; вполне возможно указать NTP-серверу считать свои собственные часы материнской платы авторитетными и разрешить NTP-клиентам привязываться к ним и распространять это время. Затем синхронизируйте рассматриваемый сисплекс через STP (который, как вы говорите, является NTP) с этим сервером с неправильными часами.

решение2

Первое предостережение (не волнуйтесь, у меня есть три предложения):

Я не уверен насчет:

Нам необходимо создать NTP-сервер, который синхронизируется с другими NTP-серверами, но предоставляет своим клиентам измененное UTC.

Зачем вам синхронизация с внешними часами? Вам нужно обслуживать фальшивое время и следить за тем, чтобы время не сбивалось/не дрейфовало?

Я думаю/знаю три способа. Первый самый простой и может справиться с дрейфом/блужданием, если вы подключите источник PPS.

  • Эталонная реализация ntpd с недисциплинированными локальными часами (рекомендуется/самая простая):

    Если вы хотите, чтобы сервер ntp обслуживал фальшивое время, это довольно просто. Установите аппаратные/ядерные часы на любое необходимое вам фальшивое время. Затем настройте ntpd на использование драйвера недисциплинированных локальных часов (127.127.1.x) и никаких внешних часов. Сервер ntp будет с радостью работать и обслуживать локальные часы. Единственная проблема заключается в том, что поскольку вы используете драйвер локальных часов, время не будет стабильным и будет дрейфовать на миллисекунды в ту или иную сторону, потому что этот кварцевый кристалл не является рубидиевым эталоном. Если вам нужны фальшивое время и стабильность, вам нужно использовать ULC и добавить источник PPS. После добавления источника PPS вам нужно будет добавить ключевое слово preference для записи ULC в ntp.conf.

  • Реализация эталонного ntpd с внешней дисциплиной синхронизации и локальным драйвером синхронизации (сложная):

    Это все еще решение, которое опирается на использование эталонной реализации ntpd, но я не очень хорошо с ней знаком. Все, что я могу сделать, это дать вам ссылку на более подробную информацию: http://www.eecis.udel.edu/~mills/ntp/html/extern.html

  • Jans — сторонний инструмент тестирования NTP

    У меня нет опыта работы с этим продуктом, но я знаю о нем из списка рассылки ntp. Он позволит вам использовать поддельное время сервера, но не делает никакой дисциплины часов, как эталонная реализация. Дополнительная информация:http://www.vanheusden.com/time/jans/

Связанный контент