none
Раз в сутки отваливается синхронизация времени на КД(2012) под Hyper-V RRS feed

  • Вопрос

  • Добрый день, у меня такая ситуация:

    1 - Контроллер домена на Windows 2012R2 установлен под Hyper-V. Синхронизация времени с хост-машиной отключена в настройках Hyper-V.

    2 - Служба времени настроена на синхронизацию с time.windows.com. Синхронизация проходит успешно. Время устанавливается верное.

    3 - Спустя некоторое время - примерно 3-10 часов синхронизация пропадает причём сразу с большим отклонением. Выглядит этот момент при просмотре w32tm /stripchart вот так:

    19:30:21 d:+00.1562053s o:-00.0060870s  [                           *                           ]
    19:30:23 d:+00.1562036s o:-00.0087478s  [                           *                           ]
    19:30:26 d:+00.1405838s o:-00.0028829s  [                           *                           ]
    19:30:28 d:+00.1562042s o:-00.0165053s  [                           *                           ]
    19:30:30 d:+00.1562047s o:+00.0011595s  [                           *                           ]
    19:30:32 d:+00.1405899s o:+00.0030170s  [                           *                           ]
    19:30:34 d:+00.1561969s o:-00.0131250s  [                           *                           ]
    19:30:36 d:+00.1405128s o:-00.0044379s  [                           *                           ]
    19:30:39 d:+00.1718294s o:-00.0064479s  [                           *                           ]
    19:30:41 d:+00.1561624s o:-00.0101792s  [                           *                           ]
    19:30:43 d:+00.1562029s o:-00.0058196s  [                           *                           ]
    19:30:45 d:+00.1405988s o:-00.0095212s  [                           *                           ]
    19:31:16 ошибка: 0x800705B4
    19:31:19 d:+00.1562099s o:+42.8240319s  [                           |                          @]
    19:31:21 d:+00.1405866s o:+42.8289400s  [                           |                          @]
    19:31:23 d:+00.1405062s o:+42.8209113s  [                           |                          @]
    19:31:25 d:+00.4685487s o:+42.9707821s  [                           |                          @]
    19:31:28 d:+00.1563300s o:+42.8241157s  [                           |                          @]
    19:31:30 d:+00.1561275s o:+42.8214140s  [                           |                          @]
    19:31:32 ошибка: 0x800705B4
    19:31:35 d:+00.1562050s o:+42.8275786s  [                           |                          @]
    19:31:37 d:+00.1563012s o:+42.8327392s  [                           |                          @]
    19:31:39 d:+00.1405906s o:+42.8254907s  [                           |                          @]
    19:31:42 d:+00.1561160s o:+42.8230155s  [                           |                          @]
    19:31:44 d:+00.1562584s o:+42.8194146s  [                           |                          @]
    19:31:46 d:+00.1561335s o:+42.8188219s  [                           |                          @]
    19:31:48 d:+00.1561395s o:+42.8203429s  [                           |                          @]

    При этом вывод w32tm /query /status сообщает о регулярной, успешной плановой синхронизации всегда, вне зависимости от того произошел сдвиг или нет:

    17:39
    Индикатор помех: 0(предупреждений нет)
    Страта: 3 (вторичная ссылка - синхронизирована с помощью (S)NTP)
    Точность: -6 (15.625ms за такт времени)
    Задержка корня: 0.2030642s
    Дисперсия корня: 0.0876632s
    Идентификатор опорного времени: 0x68299644 (IP-адрес источника:  104.41.150.68)
    Время последней успешной синхронизации: 17.12.2015 16:41:50
    Источник: time.windows.com,0x9 
    Интервал опроса: 8 (256s)

    Вручную с помощью w32tm /resync время всегда синхронизируется успешно и встаёт на место, но потом всё повторяется. В журнале ошибок нет, кроме ошибок Hyper-V с кодом 12 и 13 об отключении/включении сетевого адаптера в виртуальной машине.

    По логу видно, что каждый раз сбою предшествует ошибка:

    19:31:16 ошибка: 0x800705B4

    Она бывает часто и бывает, что и не ведёт к такому сбою времени, но когда он есть, она ему предшествует. Корреляция 100%. И так же в этот момент есть ошибки 12 и 13 от Hyper-V.

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

    Прошу помощи у сообщества!

    Обновление:

    Нашел информацию что возможно источником ошибок отключения/включения сетевого адаптера Hyper-V, который непосредственно предшествуют рассинхронизации (evenid 12 и 13) становится работа антивирусного ПО на хост-системе. Такое ПО действительно есть.

    В соответствии со статьёй https://support.microsoft.com/en-us/kb/961804 добавлены требуемые исключения.

    Буду наблюдать пока.

    • Изменено Eduard Gan 21 декабря 2015 г. 6:44
    21 декабря 2015 г. 6:08

Ответы

  • Обновление:

    Нашел информацию что возможно источником ошибок отключения/включения сетевого адаптера Hyper-V, который непосредственно предшествуют рассинхронизации (evenid 12 и 13) становится работа антивирусного ПО на хост-системе. Такое ПО действительно есть.

    В соответствии со статьёй https://support.microsoft.com/en-us/kb/961804 добавлены требуемые исключения.

    Буду наблюдать пока.

    Помогло. Ошибка 12/13 не исчезла но время перестало сбиваться.

    Условно решено.

    • Помечено в качестве ответа Eduard Gan 6 января 2016 г. 18:34
    6 января 2016 г. 18:34

Все ответы

  • Похоже, что у вас служба синхронизации после таймаута (ошибка 0x800705B4) подхватывает совершенно другой сервер NTP с тем же именем - за именем time.windows.com скрывается много разных серверов, один из которых выбирает служба AKADNS - но с совершенно другой задержкой.

    Попробуйте каким-либо образом зафиксировать адрес IP, в который разрешается time.windows.com в момент сбоя. Надёжнее всего это делать на основе содержимого кэша имён DNS (командлетом Get-DNSClientCache time.windows.com), чтобы потом разбираться более предметно.


    Слава России!

    21 декабря 2015 г. 9:27
  • Более того, я бы порекомендовал в качестве источника времени выбрать что-то более надежное. Что-то типа http://www.pool.ntp.org/zone/ru .

    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    21 декабря 2015 г. 12:59
  • Я конечно могу выбрать другой NTP-сервер, и даже сделаю это завтра в порядке эксперимента, но мне почему-то кажется что причина не в этом. Проблемы начались сразу после миграции с физического сервера под 2003 на виртуальный 2012R2. На старом сервере использовались серверы времени Microsoft и за 8 лет его эксплуатации подобных проблем не было ни разу.
    22 декабря 2015 г. 5:21
  • Если такое смещение возможно при переходе с одного сервера на другой, то как-то получается что это сервера не совсем точного времени :) Хотя догадку проверю. Внесу в DNS сервер единственный адрес из этих серверов и попробую сослаться на него в настройках W32Time.
    22 декабря 2015 г. 5:23
  • Проблемы начались сразу после миграции с физического сервера под 2003 на виртуальный 2012R2. На старом сервере использовались серверы времени Microsoft и за 8 лет его эксплуатации подобных проблем не было ни разу.

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

    Кстати, чисто на всякий случай покажите вывод следующих команд:

    w32tm /query /source

    w32tm /query /peers


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    22 декабря 2015 г. 9:15
  • Да, точно уверен. Пожалуйста:

    Microsoft Windows [Version 6.3.9600]
    (c) Корпорация Майкрософт (Microsoft Corporation), 2013. Все права защищены.
    C:\Windows\system32>w32tm /query /source
    time.windows.com
    
    C:\Windows\system32>w32tm /query /peers
    #Узлы: 1
    
    Узел партнера: time.windows.com
    Состояние: Активный
    Осталось времени: 378.1277495s
    Режим: 1 (Симметричный активный)
    Страта: 3 (вторичная ссылка - синхронизирована с помощью (S)NTP)
    ОдноранговыйИнтервал опроса: 10 (1024s)
    УзелИнтервал опроса: 10 (1024s)
    
    C:\Windows\system32>

    http://funkyimg.com/i/25FXf.png

    22 декабря 2015 г. 11:05
  • Обновление:

    Нашел информацию что возможно источником ошибок отключения/включения сетевого адаптера Hyper-V, который непосредственно предшествуют рассинхронизации (evenid 12 и 13) становится работа антивирусного ПО на хост-системе. Такое ПО действительно есть.

    В соответствии со статьёй https://support.microsoft.com/en-us/kb/961804 добавлены требуемые исключения.

    Буду наблюдать пока.

    Помогло. Ошибка 12/13 не исчезла но время перестало сбиваться.

    Условно решено.

    • Помечено в качестве ответа Eduard Gan 6 января 2016 г. 18:34
    6 января 2016 г. 18:34