Простой факт заключается в том, что точность часов в виртуальной машине все еще очень плохая. Это происходит из нескольких мест, но самое страшное в том, что временной сдвиг не является постоянным; коэффициент дрейфа меняется от момента к моменту. NTP - это протокол, в котором встроена тактовая компенсация, но он был разработан со встроенным коэффициентом статического смещения. Например, если физическая машина теряет 12 секунд каждые 30 дней, NTP может это компенсировать и делает это очень хорошо. Но если эта машина может терять от 4 до 70 секунд каждые 30 дней, NTP не так хорошо отслеживает этот уровень изменений.
Что делает NTP действительно трудным для поддержания в среде виртуальной машины, так это то, что локальные часы, которые он видит, могут изменить свой коэффициент смещения в течение минуты. В зависимости от частоты, с которой он проверяет свои родительские источники времени, это может привести к значительным изменениям дрейф-фактора и привести к гораздо более частой рассинхронизации. Несинхронизированные каскады времени в вашей организации.
NTP для локальной сети - это протокол с относительно низким уровнем воздействия с очень небольшим объемом памяти, который может успешно использоваться на других серверах сетевой инфраструктуры, таких как DNS-серверы и DHCP-серверы. Некоторые маршрутизаторы также могут обеспечивать функциональность NTP, поэтому вы можете захотеть изучить это.
В идеале вам нужны два отдельных сервера в разных местах, каждый из которых синхронизируется с различным набором серверов более высокого уровня. Также было бы очень хорошей идеей, чтобы оба сервера времени были настроены на использование другого сервера в качестве «равноправного», что сведет к минимуму влияние на обслуживание времени, если один из вышестоящих источников времени выйдет из строя; произойдет изменение слоя, но, по крайней мере, оно не будет синхронизировано. И, наконец, будьте добры к вашим поставщикам времени в восходящем направлении и настройте свои серверы так, чтобы они проходили очень долго между опросами, как только время установится. Это параметр 'maxpoll' в строке 'server', и это степень двойки в секундах между попытками синхронизации.
Если бы для этого вам абсолютно необходимо было использовать виртуальные машины, я бы настроил не менее трех таких NTP-серверов. Каждый из них должен быть на другом хосте и, если возможно, в другом дата-центре. Как и в том, что я только что предложил, им нужны разные источники времени и они должны быть равны друг другу. Затем настройте все ваши клиенты NTP для использования всех трех в качестве родительских источников. Убедитесь, что значения maxpoll достаточно низкие, чтобы никогда не проходить более полутора часов между синхронизирующими пакетами вне сети и 30 минутами внутри сети. Скорее всего, по крайней мере один из трех будет синхронизирован в любой момент времени. Клиентам, которые могут общаться только с одним временным хостом, им просто придется мириться с случайным несинхронизированным событием. В целом, качество времени в этом сценарии будет не таким точным, как с физическими серверами.
Если бы мне пришлось смириться, я бы сказал, что ваше время достижения консенсуса в среде чисто виртуальных машин, вероятно, будет в пределах 30-100 мс от истинного. В чисто физической среде ваше согласованное время, вероятно, будет в пределах 10 мсек, если время работы серверов достаточно велико, чтобы время успокоилось.