Сервер времени для синхронизации локальной сети

Необходимость синхронизации времени в закрытых локальных сетях

В закрытых сетях крупных, а иногда и не очень, предприятий существует достаточно острая проблема привязки сетевого оборудования к единой временной шкале. Эта проблема обусловлена неидеальностью внутрисистемных часов каждого отдельно взятого устройства. Иными словами, без единого источника синхронизации даже при одновременной настройке всех узлов сети на одно и тоже время, почти сразу появляется рассогласование в миллисекундах, которое, позже, может дорасти до десятков секунд и даже минут. При этом у всех устройств погрешность будет отличаться, и вариатли, даже в большой инфраструктуре, будут присутствовать 2 узла с одинаковым (хотябы до сотен микросекунд) временем.

Если у предприятия нет какой либо значимой деятельности в области информационных технологий, то это не несёт опастности, и устройства будут вполне сосуществовать, вне зависимости от внутреннего системного времени. Но если компания осуществляет деятельность по мониторингу технических процессов, или использует в своей работе тикеты, у которых должна быть обеспечена привязка к локальному времени, то необходимо присутствие внешнего синхронизирующего устройства, которое будет мастером для всех клиентов локальной сети предприятия. Данная проблема актуальна для крупных областей промышленности: для банковской сферы (биржевые операции, синхронизация баз данных, синхронизация транзакций и т.д. ), для нефтегазовой отрасли (синхронизация объёктов SCADA, и иных объектов мониторинга и управления), для авиационных компаний (синхронизация баз данных, систем мониторинга), для военных структур и структур безопасности (синхронизация систем управления и связи). При отсутствии подобного узла, в сети предприятия может накапливаться временная ошибка рассогласования между узлами, которая в конечном итоге может выльиться в крупные финансовые убытки, например, проскакивания биржевых котировок для банков, или неотработка вовремя какого либо механизма защиты для нефтегазовой области.

Проще дела обстоят, если у предприятия открытая сетевая структура (т.е. сетевые устройства имеют свободный или настраиваемый выход в сеть Internet). В таком случае, есть возможность воспользоваться любым общедоступным сервером синхронизации, или одним из самых больших пулов NTP серверов – pool.ntp.org, количество хостов в котором, на момент написания статьи, перевалило за 4100 шт. Однако, проблем с сетевой безопасностью данное решение точно не убавит, а скорее наоборот – прибавит, и даже большое количество бесплатных серверов не гарантирует необходимую точность синхронизации. Для вышеописанных областей крупной промышленности, такое решение является абсолютно недопустимым.

Подытожив видение проблемы, можно с уверенностью сказать, что присутствует необходимость в узле синхронизации, который будет обеспечивать единым временем все узлы сети. В качестве подобных критически важных узлов принято использовать локальные сервера точного времени или устройства синхронизации времени.

Сервер точного времени – узко специализированное устройство, которое обеспечивает клиентов точной привязкой к временной шкале UTC/UTC (SU).

Сервера точного времени могу т осуществлять выдачу временного кода в различных форматах:

• протокол NTP – Network Time Protocol
• протокол SNTP – Simple Network Time Protocol
• протокол PTP – Precision Time Protocol
• протокол IRIG-B – Inter-range instrumentation group time codes
• протокол Time Protocol – RFC 868
• протокол DayTime Protocol – RFC 867
• протокол NMEA 0183 – National Marine Electronics Association
• и др.

Разные протоколы могут располагаться на разных уровнях сетевой модели OSI, и даже иметь различные физические принцыпы передачи информации.

Принимать сигналы точного времени устройства синхронизации могут также из разных источников:

• со спутниковых навигационных систем GPS/GLONASS
• с радиосигналов точного времени DCF77, RBU, RTZ и др.
• с аналогичных устройств синхронизации (являясь клиентом)
• с локального высокоточного генератора.

Из всех описанных вариантов самым предпочтительным является синхронизация со спутниковых систем GPS/GLONASS, т.к. зана поктытия составляет почти весь земной шар. При этом, многие устройства синхронизации имеют на борту прецизионные генераторы (вплоть до атомных), которые в случае с перебоям сигнала способны взять задачу формирования прецизионной метки времени на себя.

У второго варианта – радиосигналов точного времени, зона покрытия значительно меньше и составляет от 1000 до 2000 км от источника сигнала, например зона покрытия радиостанции DCF77:

У различных модификаций серверов точного времени, опционально могут встречаться и другие источники получения высокоточной секундной UTC метки. В топовых образцах для нужд большой промышленности может быть предусмотрено также резервирование каналов приёма и передачи информации.

Одной из таких систем синхронизации является станция синхронизации частоты и времени Sinhron от компании KRAFTTERA, которая обеспечивает, двухкратное резервирование каналов приёма (достигнутое присутствием 2-х полностью независимых GPS/GLONASS приёмников и антенных каналов), многократное резервирование каналов выдачи (достигнутое наличием до 8ми Ethernet адаптеров и поддержкой функионала агрегирования каналов), двухкратное резервирование по питанию (достигнутое наличием независимых блоков питания). Сочетание данных факторов, а также инновационного програмного обеспечения, делают данный продукт одним из самых надёжных предложений на рынке на сегодняшний день.

Сервера обновления времени windows

Жаропонижающие средства для детей назначаются педиатром. Но бывают ситуации неотложной помощи при лихорадке, когда ребенку нужно дать лекарство немедленно. Тогда родители берут на себя ответственность и применяют жаропонижающие препараты. Что разрешено давать детям грудного возраста? Чем можно сбить температуру у детей постарше? Какие лекарства самые безопасные?

В конце прошлого века перед владельцами корпоративных локальных сетей встала проблема синхронизации времени внутри сети с эталонным временем. Производители систем синхронизации и единого времени предложили для решения этой задачи целый класс устройств синхронизации локальных сетей, именуемых часовыми серверами (или серверами времени – time server ). На том этапе развития сетевых решений была необходимость в локальном устройстве синхронизации, получающем сигналы точного времени от эталонного источника и синхронизирующем отдельно взятую локальную сеть. Стоимость таких устройств составляла от 2000 до 5000 евро. Проектировщики функциональных зданий (аэровокзалов, гостиниц, банков, …) закладывали эти устройства в проекты, как единственное возможное решение задачи синхронизации времени сети с эталонным временем.

К сегодняшнему дню стоимость часовых серверов , как устройств, не изменилась. Но во «всемирной паутине» появились такие общедоступные ресурсы как серверы времени . Таким образом, на момент реализации проектов, в которые заложены часовые серверы как устройства, владельцы локальных сетей встали перед дилеммой: синхронизировать локальную сеть с помощью дорого устройства или бесплатного сетевого ресурса .

Устройство или сетевой ресурс

Очевидно, что часовой сервер в виде устройства необходим там, где нет доступа к Интернету. Если требуется точность синхронизации с эталонным временем выше 100 миллисекунд, нужно использовать часовой сервер в виде устройства. Примером такого устройства может служить предлагаемый предприятием «Хронотрон» DCF-NTP конвертер , предназначенный для синхронизации систем единого времени и компьютеров в локальной сети предприятий.

При наличии особых требований к надежности (навигационная система, управление технологическими процессами, управление движением, …) предпочтительно использовать часовой сервер в виде устройства, не забывая при этом, что устройство может само выйти из строя.

Во всех остальных случаях (банки, гостиницы, бизнес-центры, …) сервер времени как сетевой ресурс полностью подходит для решения задачи синхронизации.

Как синхронизироваться через Интернет

Операционная система WINDOWS XP имеет в стандартных настройках даты и времени вкладку под названием «Время Интернета», позволяющую пользователю периодически выполнять синхронизацию своего ПК с сервером времени в Интернете. По умолчанию вам предлагают на выбор, например, два сервера времени: time.windows.com или time.nist.gov. Но в Интернете есть масса других серверов времени, в том числе и отечественные, и вы без труда можете добавить их к уже имеющимся и синхронизироваться по любым из них. Стандартная программа синхронизации WINDOWS XP работает не всегда корректно, и расхождение системного времени с эталоном может достигать 2х-3х секунд.

Для синхронизации с точностью до 100 миллисекунд следует использовать программные продукты фирм, профессионально занимающихся системами единого времени и синхронизации. Одна из таких фирм «Symmetricom», выпускающая массу профессионального оборудования для синхронизации (в том числе и часовые серверы), разработала свободно распространяемый программный продукт под названием «SymmTime™» . Данная программа позволяет синхронизировать ПК по любому серверу времени из списка или нескольким серверам сразу по мере доступности. Синхронизация осуществляется периодически или однократно при запуске программы. Можно посмотреть статус синхронизации и величину расхождения с эталоном. Программа имеет развитый пользовательский интерфейс, позволяющий настраивать часовые пояса, вид и количество часов, отображаемых на панели программы. Точность синхронизации с помощью данной программы не хуже сотен миллисекунд и практически не уступает точности синхронизации с помощью часового сервера, поскольку методологически алгоритм синхронизации с удалённым сервером и сервером, находящимся в вашей локальной сети один и тот же.

Адрес фирмы «Symmetricom», где можно скачать вышеупомянутую программу: www.symmetricom.com

Подключение к NTP серверу доступно всем желающим, не требует установки дополнительного программного обеспечения и полностью бесплатно. Адрес сервера для использования в настройках операционных систем или оборудования:

Синхронизация работает по протоколу UDP порт 123. Для получения времени с NTP сервера проверьте, что файрвол не блокирует этот трафик.

При настройке оборудования для синхронизации времени с бесплатным NTP сервером лучшим решением будет использование имени сервера, а не его IP адреса. Если расположение сервера изменится, то синхронизация по имени продолжит работать без необходимости изменения настроек. Если оборудование поддерживает возможность настройки синхронизации только по IP адресу, то в случае изменения адреса сервера запросить у него точное время станет невозможно и придётся изменить настройки. Узнать актуальный IP адрес сервера можно при помощи команды nslookup сайт

Пожалуйста, не настраивайте синхронизацию времени через Планировщик заданий или Крон! Такая настройка приводит к пиковым нагрузкам на сервер в начале каждой минуты, часа или суток.

Настройка синхронизации через определённый интервал времени (например, раз в 5 минут) не имеет смысла, поскольку в таком интервале точность хода часов даже самых простых устройств достаточна для поддержания точного времени. И в Windows, и в Linux есть специально предназначенные для синхронизации времени службы. Встроенные алгоритмы операционных систем самостоятельно оценивают точность хода часов и запрашивают синхронизацию только если она действительно необходима.

На протяжении всего времени работы бесплатного NTP сервера Mobatime, периодически, некоторые клиенты присылают на сервер неразумно большое количество запросов в секунду. В данный момент несколько клиентов запрашивает синхронизацию с интенсивностью до 500 запросов в секунду каждый. Мы вынуждены при помощи специально разработанного программного обеспечения автоматически обнаруживать и закрывать доступ к серверу времени таким клиентам .

Это же программное обеспечение обнаруживает клиентов, настроивших синхронизацию по Планировщику или Крону и помещает их IP адреса на несколько суток в список необслуживаемых клиентов. Если ваша система перестала получать время с NTP сервера, то убедитесь в отсутствии ошибок в настройках и проверьте частоту запросов на синхронизацию. Сделать это можно при помощи сниффера, настроив его на сбор трафика между вашей системой и NTP сервером по протоколу UDP на порт 123. Если используется ipfw, то количество запросов можно быстро оценить, просмотрев вывод команды ipfw -a list Для правила, разрешающего трафик до NTP сервера, счётчик должен увеличиваться незначительно.

Если Вы поддерживаете работу большой локальной сети, то настройте синхронизацию на любом сервере с NTP сервером Mobatime и установите на нём свой NTP сервер. Он будет работать во втором стратуме и обеспечивать точным временем всю локальную сеть. Пропускать запросы времени ото всех клиентов большой локальной сети (сотни рабочих мест) через NAT на сервер NTP — плохая идея. Скорее всего, через непродолжительное время сервер откажется обслуживать такое количество запросов с одного IP адреса. Если сеть построена на программном обеспечении Microsoft и использует доменную структуру, то для получения всеми пользователями точного времени достаточно настроить синхронизацию с NTP сервером только контроллеров домена. Все клиенты получат точное время с них автоматически.

Не забывайте о том, что Kerberos перестаёт работать при расхождении времени клиента и сервера более чем на 5 минут. Так же необходимо помнить об обязательной настройке синхронизации времени между гостевыми системами и хостом или сервером времени при использовании виртуализации.

Мы опубликовали небольшую статью о том, как работает синхронизация по протоколу NTP , и почему при синхронизации времени через интернет удалённость клиента от NTP сервера не имеет значения.

Если работа Вашей системы требует постоянного наличия максимально точного времени и Вы не хотите зависеть от стабильности каналов передачи данных, то наши специалисты готовы проконсультировать Вас и помочь выбрать NTP сервер для установки в Вашем датацентре или серверной. Наши контакты можно найти на сайте . Мы выполняем весь комплекс работ на территории Европы, России и Индии, включая монтаж и последующее сервисное обслуживание систем времени, часов с символикой Вашей компании, установленных в помещениях или на улице, информационных табло и так далее. Широкий ассортимент продукции и накопленный опыт позволяют нам строить системы для обслуживания аэропортов, метрополитенов, бизнес-центров и создавать системы часофикации целых городов. Часы на улицах такого города всегда показывают точное синхронизированное время и работают даже в самые сильные морозы.

К сервису синхронизации времени по протоколу NTP все уже привыкли — оно включено по умолчанию или легко включается для большинства популярных операционных систем. Однако какая точность при этом достигается? Какие бывают сервера точного времени, и с какими можно работать простым смертным? Какие есть подводные камни, и как выбрать «правильные» сервера времени?

Типы серверов

Stratum 1 — получают точное время непосредственно от источника точного времени: атомных часов (например time-a.nist.gov, точность — трилионные доли секунды) или GPS приемника (ntpx.imvp.ru точность — миллиардные доли секунды). Есть сервера получающие точное время через сотовую сеть CDMA (миллионные доли секунды). При работе с ntpd узнать тип сервера можно командой ntpq -np: «PPS» значит GPS, «ACTS» значит прямое соединение с атомными часами (там же и другая ценная статистика — пинг, «дрожжание» пинга(jitter), ранг сервера(1,2. )).

«Простым» смертным обращаться к Stratum-1 серверам строго запрещено, т.к. нагрузка на них и так очень большая (а на многие Stratum-1 сервера вообще нет публичного доступа). Считается что вы можете подключаться к Stratum-1 серверам или просить доступ к ним, если вы держите NTP сервер, обслуживающий не менее 100 клиентов. Полный список серверов можно увидеть тут: support.ntp.org/bin/view/Servers/StratumOneTimeServers . Естественно, желательно подключатся к серверам в своей стране.

Stratum 2 — получают точное время от Stratum-1 серверов. При правильной настройке и выборе серверов-источников точного времени имеют погрешность менее 1мс. Подключатся обычно можно всем, но многие сервера регулярно умирают от нагрузки (например time.windows.com). www.pool.ntp.org поддерживает round-robin списки публичных Stratum-2 NTP серверов. Таким образом обеспечивается балансировка нагрузки, и они практически всегда доступны. Подключиться к этим серверам можно по адресам 0.ru.pool.ntp.org 1.ru.pool.ntp.org 2.ru.pool.ntp.org и 3.ru.pool.ntp.org (это для России, выбираются случайно из списка

Stratum 3 — получают время от Stratum-2 серверов, и т.д.

Практическая точность

Stratum-1
Это график разницы системного времени с временем полученным со Stratum-1 серверов (canonical.com — Stratum-2 сервер, для сравнения).
*.nist.gov — расположены в США, из-за «большого» пинга иногда случаются жуткие «выбросы». Ошибка с Российских Stratum-1 серверов обычно укладыватся в +- 1 мс.

Stratum-2
Это — разница с Stratum-2 серверами: 4 из Российского пулла, 1 из европейского, дефолтный сервер времени убунты (europium.canonical.com), и те же *.nist.gov:

Сразу бросаются в глаза сервера, имеющие постоянную ошибку до 20 мс.

Резюме

PS. Кстати, по умолчанию в Ubuntu синхронизация времени происходит один раз при загрузке системы. Если аптайм под полгода — время может сильно уехать. Устанавливаете ntpd — он корректирует время постоянно и «плавно» (без резких рывков, «размазывая» замедление/ускорение времени). В Windows синхронизация происходит раз в сутки неделю одним «скачком», что может вызвать сложности при обработке логов, если набежала большая разница.

Синхронизация времени на серверах

Перед настройкой NTP рекомендуется установить текущую системную дату на значение, максимально приближенное к реальному времени. Для этого можно воспользоваться утилитой для ручной синхронизации времени – ntpdate.

Команда date без параметров выводит текущее системное время.

Установка и настройка NTP

1. Установка NTP происходит при первичной установке пакета ecss-node, в ходе которого будет задано несколько вопросов:
   • Спрашивается, хотите ли включить tos orphan режим? — режим для кластера, сам регулирует кто с кем синхро низируется (да/нет).
   • Точность времени кластера по Startum
   • Спрашиваются внешние сервера — типа ntp.ubuntu.com. Они указываются для нод, которые должны регулировать время и синхронизировать с внешним источником (указываются адреса через пробел).
   • Предлагается использовать настройки синхронизации с локальных серверов.
   • Спрашиваются локальные хосты, с которыми должна происходить синхронизация (указываются адреса через пробел).
   • Указываются сети, которые могут иметь доступ до ноды, чтобы другие ноды могли синхронизироваться (указываются сети вида адрес_сети|маска_сети через пробел).
   • Спрашивается какой точность по Startum выставить серверу ntp на данной машине.
2. Ручная настройка сервиса

В случае если требуется переконфигурировать текущие настройки NTP, то следует отредактировать файл /etc/ecss/ecss-ntp.conf.

Для этого необходимо привести файл /etc/ecss/ecss-ntp.conf к следующему виду:

Пример 1. В примере используется схема с резервированием. Система ECSS-10 развернута на двух серверах, которые синхронизируются между собой и NTP-сервером.

В режиме Orphan сервера в кластере синхронизируются друг от друга, сами договариваются кто из них мастер и следят, чтобы в рамках кластера часы шли синхронно.
Если появляется мастер сервер NTP со стратумом меньше заданного для кластера, то кластер автоматически перенастраивается на синхронизацию от него.

Таким образом, выполняется постоянное наличие единственной точки синхронизации времени.

Все зависимые устройства должны синхронизироваться от серверов кластера.

Пример 2. В примере используется схема без резервирования. Orphan mode не используется.

Для применения обновленной конфигурации нужно перезапустить сервис NTP:

Для просмотра информации о состоянии синхронизации используется команда ntpq –p. Если использовать дополнительный ключ –n, вместо имени сервера будет указан IP-адрес:

Пример 1. Схема с резервированием.

Пример 2. Схема без резервирования.

• remote – имя удаленного NTP-сервера;
• refid – IP-адрес сервера, с которым производит синхронизацию удаленный сервер NTP;
• st – stratum (уровень), число от 1 до 16, указывающее точность сервера;
• t — тип удаленного сервера:
  • u — unicast,
  • l — local,
  • m — multicast,
  • b — broadcst;

  Символ (*) возле IP-адреса сервера указывает на то, что сервер является активным и система синхронизирована с данным сервером.

  После старта сервиса может потребоваться около 10 минут для установления синхронизации времени с базовым NTP-сервером.

  unboxIT

  Если информация была полезной для вас, вы можете поблагодарить за труды Яндекс деньгами: 41001164449086 или пластиковой картой:

  Правильная настройка сервера времени NTP на Linux

  В интернете можно найти целое море мануалов по настройке сервера времени — ntpd, но ирония состоит в том, что 95% из них либо не совсем верны, и авторы этого даже не замечают, либо не дают необходимой информации. Далее я расскажу как организовать NTP сервер под Linux в локальной сети, который будет синхронизировать своё время с серверами в Интернете, а устройства в локальной сети будут уже синхронизировать время с ним.

  Немного пред истории. Как и положено, всё началось неожиданно, сервер который я настраивал на кануне ночью, при следующей загрузки завис. «Шикарно» подумал я и полез в логи. В результате в том что сервер вис был повинен ntpd сервис, который из-за неправильной настройки сети не мог связаться внешним сервером для синхронизации. Посмотрев скрипт запуска, я наткнулся на интересную запись:

  А теперь внимание на строку с номером 8. Это начало цикла, в котором целых 7-мь раз будет предпринята попытка начальной, грубой синхронизации времени. Всё бы хорошо, но если у вас неправильно настроена сеть, или DNS, то вызовет подвисание сервера, на 7*( 1 + время проверки доступности DNS, порядка 5 сек ) секунд. В общем ждать минуту меня явно не устраивало, итак приступим.

  Настройка начальной, грубой синхронизации

  В замечательном файле /etc/ntp/step-tickers, хранятся имена серверов с которыми производиться начальная, грубая (сотни милесекунд) корректировка. Если вы уверены что у вас всегда будет доступ к Internet, можете перечислить в нём имена серверов, например:

  Но если у вас в момент начальной загрузки сервера связь с интернетом будет отсутствовать, то при определённых условиях, это вызовет подвисание консоли на довольно продолжительное время. Именно по этому я стёр все записи от туда. В конце концов я могу и в ручную сделать грубую корректировку времени. Есть ещё вариант поиграться с опциями и подправить скрипт запуска, но это не мой путь. По этому переходим непосредственно к настройки полноценного NTP сервера, который будет синхронизировать свое время с публичными серверами в Интернете, и предоставлять его участникам локальной сети в случае необходимости.

  Задача: Организовать NTP сервер в локальной сети, который будет синхронизировать своё время с Интернетом, а устройства в локальной сети будут уже синхронизировать время с ним.
  Дистрибутив: Mandriva 2010.2 free Версия ntpd: 4.2.4p8

  Мир Linux действительно великолепен, все настройки в нём сводятся к простому редактированию файлов конфигураций. ntpd в этом плане не исключение. Итак если у вас ещё не стоит ntpd сервер установим его:

  Желающие могут скомпилировать из исходников, или установить его другим способом, в мои же платны входит показать как настроить это чудо, по скольку в интернете можно найти целое море мануалов по настройке ntpd, но ирония состоит в том, что 95% из них либо не совсем верны (и авторы этого даже не замечают при вызове статусов) либо не дают необходимой информации. Итак файл с настройками храниться в /etc/ntp.conf, минимальные настройки примерно такие:

  Каждая строчка указывает на сервер (списки серверов можно найти здесь http://www.pool.ntp.org), с которым будет происходить синхронизация. Четыре строчки с server, соответственно четыре сервера. Хотя на самом деле в данном примере это не совсем так. Каждая запись указывает на пул (группу) серверов. При обращении скажем по адресу 2.ru.pool.ntp.org будет выбран 1 IP адрес сервера, с которым будет происходить синхронизация. Соответствия обновляются 1 раз в час. Теперь на более простом примере. Всего у нас имеется 4 коробки с часами. Мы берём и наугад достаём из каждой коробки 1 часы, всего у нас получается 4 часов, с которыми мы будем сверять наше время. В течении часа, каждый раз когда мы будем сверять время, мы будем брать одни и те же часы. Через час если мы опять обратимся к этим коробкам, то вытащим уже другие часы. Таким образом наше время будет сверяться постоянно с разными часами, и если какие-то из них окажутся не рабочими, то ничего страшного не случиться, ведь за 1 час, наши локальные часы не слишком сильно рассинхронизируются. Ну да мы отвлеклись, продолжим. Прежде чем запускать сервер ntpd, необходимо произвести начальную, грубую установку времени. Можно просто выставить время руками, а можно выполнить команду (разумеется если у нас корректно работает связь с интернетом):

  После того как время грубо синхронизировано можно запускать основной сервис (на всякий случае перезапустим его):

  После чего выполним команду:

  В результате должны увидеть что-то на подобии:

  Небольшие пояснения что есть что. remote — FQDN или IP-адрес сервера; refid — IP-адрес сервера с которым в настоящий момент выполняется синхронизация сервера из столбца remote; st — stratum сервера; t — режим работы сервера: ‘u’ — unicast, ‘m’ — multicast, ‘b’ — broadcast, ‘-‘ — manycast; when — время, прошедшее с момента последнего ответа сервера в секундах или ‘-‘, если сервер еще ни разу не ответил (скорее всего, «умер», и сведения о нем пора удалить из файла конфигурации); poll — интервал опроса сервера в секундах (после запуска имеет небольшое значение, чтобы синхронизация происходила быстрее, с течением времени значение увеличивается); reach — состояние восьми последних попыток запроса времени у сервера в восьмеричном представлении (в случае успешной попытки устанавливается соответствующий бит); delay — задержка ответа сервера в секундах; offset — самое важное значение — различие локального времени и времени на сервере (с течением времени значение уменьшается, т.к. время становится более точным); jitter — дисперсия, дрожание фазы (более низкие значения обеспечивают более точную синхронизацию). Ждём 10 минут. Повторяем, команду и видем:

  Ага, вот оно появились всякие дополнительные символы и вот что они означают: ‘*’ — сервер, с которым в настоящий момент выполняется синхронизация, ‘#’ — сервер отобран для синхронизации, но дистанция до него превышает максимально возможную, ‘?’ — сервер отобран для синхронизации и использует сигнал PPS, ‘+’ — сервер добавлен в список серверов, отобранных для синхронизации, ‘x’ — сервер использует некорректный алгоритм, ‘.’ — сервер выбран из конца списка серверов, отобранных для синхронизации, ‘-‘ — сервер отвергнут группирующим алгоритмом, пробел — сервер имеет слишком высокий stratum и/или не может быть проверен; Теперь по простому, если видем ‘+’, ‘-‘, ‘*’ синхронизация пошла. offset — отклонение нашего времени и времени удалённого сервера, если значение скажем больше 100, то синхронизация реально не произошла. На некоторых ресурсах можно увидеть следующую картину:

  Видим что половина серверов (2, 3, 4) вообще не работает и реально происходит работа с локальным сервером и с 172.22.128.8. Смотрим значение offset которое говорит что никакой синхронизации нет и в помине! Из листинга можно сделать только один вывод, что сервер засинхронизирован сам с собой, и его время имеет мало общего с действительным. Будьте внимательны, не давайте вас нае. обмануть 🙂 На этом бы можно и остановиться но теперь как говориться усложняем задачу. Нам надо чтоб наш сервер являлся источником времени для локальной сети, но при этом никто не смог сделать ничего плохого с вашим сервером. В чём проблема? В том что для нормальной синхронизации, даже если вы не планируете кому то давать синхронизировать время с вами, У ВАС ДОЛЖЕН быть открытым порт udp 123. После прочтения множества мануалов и дня потерянного времени вот что в /etc/ntp.conf получилось у меня:

  Вникаем внимательно. Наш сервер засинхронизирован с 6-тью внешними пулами серверов, строки с 02 по 07. Строка 10, мы запрещаем кому либо чтобы-то не было делать с нашим сервером. Теперь нам надо внести исключение для серверов с которыми наш сервер будет синхронизироваться, строки с 13 по 18. При этом параметры nomodify notrap, говорят о том что запрещено изменять состояние НАШЕГО сервера и отправлять сообщения об исключениях ВНЕШНИМИ серверами, т. е. чтоб никто из этих серверов ничего не натворил. Строка 22, мы разрешаем участникам локальной сети синхронизировать время с нашим сервером, но при этом тоже вводим ограничение. Теперь самая важная строка — 25, будем считать что это локальная петля. Без неё работать не будет. В итоге, наш сервер синхронизируется с внешними серверами, при этом сам является сервером но только для нашей локальной сети, всем остальным доступ запрещён. Ещё раз перезапустим сервис:

  Пойдём покурим, выпьем чаю, кофе (нужное подчеркнуть), после чего выполним команду:

  Видим, наш сервер засинхронизирован, отклонение не превышают и 50мс. Настройка NTPD практически одинакова для всех Xnix систем, и отличается по сути только способом запуска. Всем советую ознакомиться также со статьёй где расписан вариант настройки для FreeBSD. http://www.sergeysl.ru/freebsd-ntpd/ Вот собственно и всё.

  Добавить комментарий

  Если информация была полезной для вас, вы можете поблагодарить за труды Яндекс деньгами: 41001164449086 или пластиковой картой:

  голоса

  Рейтинг статьи