Я хочу установить несколько серверов времени Stratum 2 в своей локальной сети. Виртуальные машины, безусловно, были бы более дешевым способом сделать это, чем покупка трех серверов 1U. Какие ограничения это наложит? То есть в какой степени это повлияет на точность?
Кроме того, я считаю, что эти локальные серверы времени должны находиться на разных физических машинах, чтобы устранить любые сбои в работе оборудования. Верна ли эта интуиция?
редактировать Я должен сказать, что с помощью «виртуальных машин» я не конкретно значит VMware. Скорее, я имел в виду общую концепцию виртуализированных экземпляров.
Простой факт заключается в том, что точность часов в виртуальной машине по-прежнему очень низка. Это происходит из нескольких точек, но убийственно то, что временной сдвиг непостоянен; коэффициент дрейфа меняется от момента к моменту. NTP - это протокол, в котором встроена тактовая компенсация, но он был разработан со встроенным статическим коэффициентом дрейфа. Например, если физическая машина теряет 12 секунд каждые 30 дней, NTP может это компенсировать и делает это очень хорошо. Но если эта машина может терять от 4 до 70 секунд каждые 30 дней, NTP не так хорош в отслеживании такого уровня изменений.
Что действительно затрудняет поддержку NTP в среде виртуальной машины, так это то, что локальные часы, которые он видит, могут изменять свой коэффициент дрейфа в течение минуты. В зависимости от частоты, с которой он проверяет свои родительские источники времени, это может вызвать серьезные изменения коэффициента дрейфа и привести к тому, что он будет гораздо чаще выходить из синхронизации. Несинхронизированное время каскадирует по всей вашей организации.
NTP для локальной сети - это протокол с относительно малым воздействием и очень малым объемом памяти, который может успешно использоваться на других серверах сетевой инфраструктуры, таких как DNS и DHCP. Некоторые маршрутизаторы также могут предоставлять функции NTP, поэтому вы можете изучить это.
В идеале вам нужны два отдельных сервера в разных местах, каждый из которых синхронизируется с другим набором серверов более высокого уровня. Также было бы очень хорошей идеей, чтобы оба сервера времени были сконфигурированы для использования другого сервера в качестве «однорангового», что минимизирует влияние на службу времени, если один из вышестоящих источников времени выйдет из строя; будет изменение страты, но по крайней мере он не будет сообщать о рассинхронизации. И, наконец, будьте вежливы с поставщиками времени в восходящем направлении и настройте свои серверы на очень долгое время между опросами, как только время будет установлено. Это параметр «maxpoll» в строке «server», равный степени двойки в секундах между попытками синхронизации.
Если бы вам абсолютно необходимо было использовать для этого виртуальные машины, я бы установил не менее трех таких серверов NTP. Каждый из них должен быть на другом хосте и, если возможно, в другом центре обработки данных. Как и в случае с тем, что я только что предложил, им нужны разные источники времени, и они должны взаимодействовать друг с другом. Затем настройте все ваши клиенты NTP на использование всех трех в качестве родительских источников. Убедитесь, что ваши значения maxpoll достаточно низки, чтобы никогда не проходить более полутора часов между пакетами синхронизации вне сети и 30 минутами в сети. Скорее всего, хотя бы один из трех будет синхронизирован в любой момент времени. Для клиентов, которые могут разговаривать только с одним временным хостом, им просто придется мириться со случайными событиями рассинхронизации. В целом качество времени в этом сценарии не будет таким точным, как для физических серверов.
Если бы мне пришлось остановиться, я бы сказал, что ваше время консенсуса в среде чистой виртуальной машины, вероятно, было бы в пределах от 30 до 100 мс от истины. В чисто физической среде ваше время консенсуса, вероятно, будет в пределах 10 мс, если серверы времени проработают достаточно долго, чтобы успеть.
Посмотреть хронометраж vmware документ. Запуск демона NTP на виртуальной машине, вероятно, не лучшая идея, особенно если вам нужно точное время.
К сожалению, протокол NTP и виртуализация не очень хорошо сочетаются друг с другом. клиенты в большинстве случаев в порядке, однако сервер ntp (esp str2 и выше) обычно не будет надежно работать на виртуальном сервере.
Я комментирую с точки зрения xen и xen enterprise, но я считаю, что vmware / kvm будет таким же.
Что касается разных серверов, да, вы правы, в идеале они также должны быть в разных средах, чтобы температура / влажность тоже не влияли на точность, но, по крайней мере, я не беспокоюсь об этом. также не забывайте, что что бы вы ни делали, они все равно будут не такими точными, как правильные атомные часы, поэтому просто примите это (очень небольшое) отклонение.
Запустив NTP в виртуализированной среде, вам повезет с точностью до 20 мс (это то, что мы сделали с помощью VMware). Виртуализированный сдвиг часов - это плохо, особенно в виртуализированной среде с конкуренцией за ресурсы.
Это зависит от того, насколько точным вы должны быть. Если вы заботитесь только о втором (например, для веб-серверов), вы, скорее всего, будете в порядке, если у вас нет конкуренции за ресурсы. Если вам нужна миллисекундная точность (например, загруженная база данных, сервер журналов, исследовательский проект), забудьте о виртуализированных серверах времени.
Серверы NTP всегда должны находиться на физических хостах. У вас должно быть не менее трех пиринговых серверов в пуле (чтобы пул отклонил один мошеннический сервер); и, если возможно, получайте их время от GPS или другого местного источника уровня 0, а не через Интернет.