☰

Каковы ограничения при запуске NTP-серверов на виртуальных машинах? (2010)

tag-icon • tag-icon virtualization ntp
Каковы ограничения при запуске NTP-серверов на виртуальных машинах? (2010)

Я хочу настроить несколько серверов времени Stratum 2 в своей локальной сети. Виртуальные машины, безусловно, будут более дешевым способом сделать это, чем покупка трех серверов 1U. Какие ограничения это наложит? То есть, в какой степени это отрицательно повлияет на точность?

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

Редактировать Я должен сказать, что под «виртуальными машинами» я не имел в видуконкретноиметь в видуVMware. Скорее, я имел в виду общую концепцию виртуализированных экземпляров.

решение1

Сейчас 2023 год, ивсе предыдущие ответы на этот вопрос теперь неверны(и были такими по крайней мере с конца 2016 года), по крайней мере, в отношении виртуальных машин Linux. [Совет ниже может не применяться к виртуальным машинам Windows.]

Если вы читаете это в 2023 году или позже, пожалуйста, не верьте утверждениям в ответах от 2013 года или ранее о максимальной точности 20-100 мс. Синхронизация времени в современных виртуальных машинах может достигать точности менее 1 миллисекунды в локальной сети и приближаться к 1 миллисекунде через интернет-соединение потребительского уровня.

Следующие вопросы ServerFault содержат более актуальное обсуждение:

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

  1. Виртуальная машина, работающая ntpdв частном облаке OpenStack под гипервизором KVM (на каком-то процессоре Intel Xeon) в конце 2016 года: смещение-kvm
  2. Виртуальная машина, работающая ntpdна автономном хосте KVM (на Intel Celeron 1037U) в середине 2020 года: смещение-kvm-celeron
  3. Количество t3a.microэкземпляров AWS (AMD), работающих chronydв конце 2021 года: смещение-aws-t3a
  4. Количество t4g.microэкземпляров AWS (ARM), работающих chronydв конце 2021 года: смещение-aws-t4g
  5. Количество Standard_B1sэкземпляров Azure (Intel), работающих chronydв начале 2022 года: смещение-лазурь-b1s
  6. Количество контейнеров, работающих chronydв AWS ECS/Fargate (Intel) в конце 2022 года: смещение-fargate

решение2

Простой факт заключается в том, что в 2010 году точность часов в виртуальной машине все еще очень плохая. Это происходит из-за нескольких моментов, но самое убийственное то, что дрейф времени не постоянен; фактор дрейфа меняется от момента к моменту. NTP — это протокол, в котором встроена компенсация часов, но он был разработан со встроенным статическим фактором дрейфа. Например, если физическая машина теряет 12 секунд каждые 30 дней, NTP может компенсировать это и делает это очень хорошо. Но если эта машина может терять от 4 до 70 секунд каждые 30 дней, NTP не так хорош в отслеживании такого уровня изменений.

Что действительно затрудняет NTP поддерживать работу в среде VM, так это то, что локальные часы, которые он видит, могут менять свой фактор дрейфа в течение минуты. В зависимости от частоты, с которой он проверяет свои родительские источники времени, он может вызывать значительные изменения фактора дрейфа и приводить к гораздо более частой рассинхронизации. Рассинхронизация времени каскадно распространяется по всей вашей организации.

NTP для локальной сети — это относительно малозатратный протокол с очень небольшим объемом памяти, который может с легкостью вписаться в другие серверы сетевой инфраструктуры, такие как DNS и DHCP-серверы. Некоторые маршрутизаторы также могут предоставлять функциональность NTP, поэтому вам стоит обратить на это внимание.

В идеале вам нужны два отдельных сервера в разных местах, каждый из которых синхронизируется с другим набором серверов более высокого уровня. Также было бы очень хорошей идеей, чтобы оба сервера времени были настроены на использование другого сервера в качестве «однорангового», что сведет к минимуму влияние на службу времени, если один из источников времени вышестоящего уровня выйдет из строя; произойдет смена уровня, но, по крайней мере, он не сообщит о рассинхронизации. И, наконец, будьте любезны с вашими поставщиками времени вышестоящего уровня и настройте свои серверы так, чтобы они проходили очень долгое время между опросами, как только время будет хорошо установлено. Это параметр «maxpoll» в строке «server», и он представляет собой степень двойки в секундах между попытками синхронизации.

Если бы вам непременно пришлось использовать виртуальные машины для этого, я бы настроил не менее трех таких серверов NTP. Каждый из них должен быть на отдельном хосте и, если возможно, в другом центре обработки данных. Как я только что предложил, им нужны разные источники времени, и они должны быть пиринговыми друг с другом. Затем настройте все ваши клиенты NTP на использование всех трех в качестве родительских источников. Убедитесь, что ваши значения maxpoll достаточно низки, чтобы интервал между пакетами синхронизации вне сети не превышал полутора часов, а в сети — 30 минут. Велики шансы, что хотя бы один из трех будет синхронизирован в любой момент времени. Клиентам, которые могут общаться только с одним хостом времени, придется просто смириться с периодическими событиями рассинхронизации. В целом, качество времени в этом сценарии не будет таким точным, как с физическими серверами.

Если бы мне пришлось делать приблизительные оценки, я бы сказал, что ваше время консенсуса в среде чистой виртуальной машины, вероятно, будет в пределах, ну, от 30 до 100 мс от истины. В чисто физической среде ваше время консенсуса, вероятно, будет в пределах 10 мс, как только серверы времени будут работать достаточно долго, чтобы время стабилизировалось.

решение3

Посмотрите хронометраж vmwareдокумент. Запуск демона NTP на виртуальной машине, вероятно, не очень хорошая идея, особенно если вам нужно надежное время.

решение4

Запустив NTP в виртуализированной среде, вам повезет, если вы достигнете точности в 20 мс (именно этого мы добились с помощью VMware). Виртуализированный перекос часов плох, особенно в виртуализированной среде с конкуренцией за ресурсы.

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

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

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