Изменения в логировании работы и валидации кластера (Improved logging and validation tests)


Продолжаем рассмотрение нового функционала кластера https://blogs.technet.microsoft.com/wfcruteam/2017/04/03/new-features-windows-failover-cluster-2016.

Сегодня мы рассмотрим улучшения сделанные в логировании ошибок и валидации кластера.

В более ранних версиях для подробной диагностики работы кластера использовалась выгрузка ETW трассировки кластера в текстовый файл, выполняемая командой Get-ClusterLog. В новой версии структура этого файла претерпела изменения, показанные ниже. В файле теперь вместе с диагностической появилась и часть конфигурационной информации удобной для отыскания проблем.

Конфигурационная информация помещена в файл в CSV-формате (с разделением столбцов через запятую) и может быть экспортирована как в реляционную базу, так и в MS Excel.

Ниже показан список разделов файла и их краткое описание.

Раздел [=== Cluster ===] содержит информацию о версии ОС, времени сбора, PaxosTag и пр.
Раздел [=== Resources ===] содержит информацию о ресурсах (GUID, тип, название и пр.)
Раздел [=== Groups ===] содержит информацию о ресурсных группах.
Раздел [=== Resource Types ===] содержит информацию о типах ресурсов, зарегистрированных на кластере.
Раздел [=== Nodes ===] информацию о узлах кластера.
Раздел [=== Networks ===] содержит информацию о кластерных сетях.
Раздел [=== Network Interfaces ===] содержит информацию о сетевых интерфейсах
Раздел [=== Volumes ===] & [=== Volume Logs ===] содержит информацию о томах и дисках.

… и пр.

Далее могут следовать дополнительные разделы, зависящие от конфигурации кластера.

После информации о конфигурации присутствует выгрузка из основных кластерных логов (каналов)

[=== System ===]
[=== Microsoft-Windows-FailoverClustering/Operational logs ===]
[=== Microsoft-Windows-ClusterAwareUpdating-Management/Admin logs ===]
[=== Microsoft-Windows-ClusterAwareUpdating/Admin logs ===]

… и пр.

В файл также выгружается информация с кластерной трассировки на 3-ем уровне логирования, как это было ив более ранних версиях кластера.

[=== Cluster Logs ===]

В новой версии кластера трассировочную информацию о работе кластера можно посмотреть не только в текстовом формате (после выгрузки через команду Get-ClusterLog), но и в виде стандартного лога ОС (FailoverClustering/Diagnostic). Кроме того, (дополнительно) производится логирование работы кластера на 5-ом (самом высоком) уровне в файл (FailoverClustering/DiagnosticVerbose). Размер этого файла составляет 37,5 МБ, что не так много и поэтому его перезапись осуществляется чаще.

Обратите также внимание на новые логи, появившиеся для кластера (См. рис. ниже).

5-1

Для сбора основной конфигурационной и диагностической информации по кластеру и ее дальнейшей передачи инженерам службы технической поддержки вы можете использовать новый PowerShell cmdlet Get-ClusterDiagnosticInfo. Файлы, собираемые этой командой, размещаются в архиве C:\Users\<username>\<clustername>-yyyymmdd-hhmm.zip. Также система автоматически производит их обработку с целью поиска общих ошибок и формирования точек начала поиска проблем.

Ниже показан результат обработки части данных полученных из логов командой Get-ClusterDiagnosticInfo.

5-2

Кроме всего прочего, в новой версии кластера улучшена диагностика проблем, связанных с сетевыми именами (Network Name) кластерных ресурсов. Кластерная служба автоматически производит логирование ошибок, когда:

  • DNS не принимает динамическое обновление записи (Dynamic Updates).
  • Настройки безопасности DNS не позволяют производить обновление записей.
  • Возникают timeout-ы при работе с DNS

Часть дейтсвий кластерный сервис выполняет автоматически, помогая администратору, а именно:

  • Проверка доступности контроллеров домена.
  • Синхронизация паролей CNO.
  • Проверка установлен ли CNO в состояние Enable.
  • Проверка созданы ли CNO и VCO (не удалены ли они)

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

  • Проверка что длина имени CNO и VCO на превышает 15 символов.
  • Проверка имеет ли CNO разрешение Create Computer Object в OU, в которое он помещен.
  • Проверка того, что локальная группа Users включает учетные записи CLIUSR и NT AUTHORITY\Authenticated Users.

Все вышеперечисленное должно дать возможности инженерам технической поддержки как заказчика, так и Microsoft, быстрее решать проблемы возникающие при работе с кластером Windows 2016.

В следующей статье мы продолжим разговор о новом функционале кластера как и было анонсировано в  https://blogs.technet.microsoft.com/wfcruteam/2017/04/03/new-features-win…ver-cluster-2016/

 

Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia)

Comments (0)

Skip to main content