Определение того, возникает ли в системе Avamar проблема синхронизации времени (NTP).

Если узлы в системе Avamar не синхронизированы по времени, можно ожидать следующих типов поведения:

• Не удается запустить сервер Avamar
• Узлы отключались
• Сбой HFScheckс MSG_ERR_CGSAN_FAILED
• Сбой HFScheck с MSG_ERR_HFSCHECKERRORS
• Сбой контрольных точек
• Сбой сбора «мусора»
• Проблемы с согласованием данных (если время изменяется во время сбора мусора)

Примеры сообщений об ошибках, которые обычно сообщаются в результате потери синхронизации времени:

• samconn::checkallsucceed request failed DPNTIMECHECK=230 
• НЕУСТРАНИМАЯ ОШИБКА: <Несоответствие времени 0001> dpn: синхронизация часов и повтор
• ERROR: <0001> dpncheckmanager::verifyStartup cgsan неожиданно завершается.  
• недостаточно допустимых ответов, полученных во время

Эта статья помогает читателю определить, возникла ли в системе Avamar проблема синхронизации времени. Решение этой проблемы выходит за рамки данной статьи.

Существует множество веб-сайтов, на которых выполняется поиск и устранение неисправностей NTP, и читателю рекомендуется изучить их. Полезные веб-URL-адреса, доступные на момент написания, перечислены в разделе «Внешние ссылки».

Для продолжения выполните:
1. Войдите на сервер Avamar с правами администратора в соответствии с статьей базы знаний Avamar: Вход на сервер Avamar и загрузка различных ключей.

2. Чтобы определить, синхронизированы ли узлы Avamar, проверьте текущее время и дату каждого узла в системе Avamar. Пример выходных данных см . в приложении А.

mapall --all --parallel '/bin/date'

Если все узлы сообщают об одной и той же дате и времени, это означает, что время полностью синхронизируется между всеми узлами в этой системе.

3. Для синхронизации времени на узлах Avamar использует протокол NTP. Команда Linux «ntpq -pn» возвращает состояние синхронизации времени. Пример выходных данных см. в приложении B .

mapall --all --noerror '/usr/sbin/ntpq -p'

4. Общие наблюдения сервера Avamar:

• Все узлы предпочитают 128.xxx.xxx.xx в качестве основного источника времени.
• Вторичным источником времени для всех узлов является локальные часы BIOS на «avmtest1» (узел 0.s).
• Для источника третьего времени установлено значение avmtest2 (узел 0.0), который сам ссылается на avmtest1.
• Все узлы синхронизются с avmtest1. Сервер времени, помеченный звездочкой (*), — это сервер, с которым в данный момент выполняется синхронизация узла.
• В этом случае файл 128.xxx.xxx.xx расположен удаленно. Оно имеет значение «reach» в 0 (в настоящее время недоступно). Это не рекомендуется использовать в качестве источника времени.
• avmtest1 и avmtest2 имеют регистр доступа с октетом 377. Это самый высокий показатель. Таким образом, все узлы синхронизются со вторичным источником.

5. Анализ выходных данных ntpq для узла 0.2.

(0.2) ssh  -x  admin@10.64.18.164 '/usr/sbin/ntpq -p'

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================
 128.xxx.xxx.xx  .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
*avmtest1.emcvmw LOCAL(0)         9 u   54  256  377    0.085   -0.116   0.002
+avmtest2.emcvmw xx.xx.xx.xxx    10 u   56  256  377    0.090    0.073   0.012

• Узел 0.2 опрашивает avmtest1 каждые 256 секунд
• Узел 0.2 в настоящее время синхронизируется с avmtest1
• avmtest1 находится на стратах 9, подразумевая, что узел 0.2 находится в stratum 10.
• Узел 0.2 опрашивает avmtest1 раз в 256 секунд.
• Регистр reachability для avmtest1 имеет октет 376.
• Время на avmtest1 составляет 0,116 мс (или 116 микросекуd) за часами на avmtest1.
• Задержка циклической передачи до avmtest1 составляет 85 мс.
• Измерение задержки в сети (дрожание) между узлом 0.2 и avmtest1 составляет 2 мс.

Конфигурация NTP (/etc/ntp.conf):
при просмотре файла /etc/ntp.conf на узле 0.2 он соответствует вышеуказанной выходной информации ntpq .

#Customer premises / external time servers.

#
server xxx.xxx.xxx.xx     <--  Primary time source (this is an external server located remote to the Avamar grid)
# - - - - -
# DPN time servers here and in the other module(s).
#
server xx.xx.xx.xxx   <--  Secondary time source (this is the utility node)
server xx.xx.xx.xxx   <--  Tertiary time source (this is node 0.0)

Ведение журнала:
Ведение журнала NTP направляется в файл /var/log/messages .
Чтобы просмотреть журнал, связанный с NTP, grep содержимое /var/log/messages* для «ntp»

Если внешний сервер времени ненадежен ,как в приведенном выше примере, допускается использование внутреннего сервера времени. Внутреннее время может медленно отойти от UTC, но самое важное — узлы данных синхронизются друг с другом.

Утилиту Avamar asktime Tool можно использовать для выбора новых предпочтительных источников времени для NTP.
См. Avamar: Настройка NTP на сервере Avamar с помощью функции «asktime» 

Дополнительная информация:
http://support.microsoft.com/kb/939322. Контроллеры домена Windows не следует использовать для своевременного хранения.