Каковы ограничения на работу серверов NTP на виртуальных машинах?

Я хочу настроить несколько серверов времени 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). Виртуализированное искажение тактовой частоты является плохим, особенно в виртуализированной среде с конфликтом ресурсов.

Это зависит от того, насколько точно вы должны быть. Если вы заботитесь только о втором (EG для веб-серверов), вы, вероятно, будете в порядке, если у вас нет конфликта ресурсов. Если вам нужна точность в миллисекундах (например, занятая база данных, сервер журналов, исследовательский проект), тогда забудьте о виртуализированных серверах времени.

Серверы NTP всегда должны быть на физических хостах. Вы должны иметь по крайней мере 3 из них, пирингующих в пуле (так, чтобы один мошеннический сервер был отклонен пулом); и, если возможно, получайте свое время от GPS или другого локального источника уровня 0, а не через Интернет.