В статье «Диагностика проблем кластеров Windows Server 2008 R2», опубликованной в Windows IT Pro/RE № 10 за 2012 год, говорилось об устранении неполадок кластеров с обходом отказов. В частности, приводились рекомендации по извлечению информации, необходимой для диагностики проблем. На этот раз я хочу рассказать о расширенных средствах поиска и устранения неисправностей кластеров с обходом отказов в Windows Server 2012 и об их наиболее эффективном применении.
Знакомство с новыми каналами событий
В диагностике проблем кластеров с обходом отказов могут помочь новые каналы событий. На экране 1 показаны все существующие ка-налы. Заметим, что все события относятся к текущему узлу.
.jpg) |
| Экран 1. Каналы событий кластеров с?обходом отказов в?Server 2012 |
Чтобы быстрее находить ошибки и выяснять причину проблемы, необходимо знать назначение каждого канала событий.
* FailoverClustering
— Diagnostic. Это главный журнал, генерируемый всякий раз при запуске службы кластеров. Если функция ведения журнала выклю-чена, события могут выводиться в окно программы просмотра со-бытий Event Viewer. Данные журнала можно преобразовать в тек-стовый файл.
— Operational. Здесь регистрируются все информационные события в кластере, такие как перемещение групп, подключение к сети или переход в автономный режим.
— Performance-CSV. Этот канал используется для сбора информа-ции, касающейся функционирования общих томов кластера (CSV).
* FailoverClustering-Client
— Diagnostic. Этот канал используется для сбора данных журнала трассировки API Cluster. Данные журнала могут быть полезны для выявления причин ошибок при выполнении действий по созданию кластера (Create Cluster) и добавления узла в кластер (Add Node Cluster).
* FailoverClustering-CsvFlt (новый канал в Server 2012)
— Diagnostic. По этому каналу осуществляется сбор данных жур-нала трассировки драйвера фильтра CSV (CsvFlt.sys), установ-ленного только на узле координатора для CSV. Данные журнала позволяют выявить причины сбоев операций с метаданными и пе-ренаправленных операций ввода/вывода.
* FailoverClustering-CsvFs (новый канал в Server 2012)
— Diagnostic. Этот канал используется для сбора данных журнала трассировки драйвера файловой системы CSV (CsvFs.sys), ус-тановленного на всех узлах кластера. Данные журнала позволяют диагностировать проблемы прямых операций ввода/вывода.
* FailoverClustering-Manager
— Admin. На этом канале регистрируются ошибки, связанные с диалоговыми окнами и всплывающими предупреждениями, отобра-жаемыми в окне диспетчера кластеров.
* FailoverClustering-WMIProvider
— Admin. Этот канал используется для регистрации событий, связанных с поставщиком WMI кластеров с обходом отказов.
— Diagnostic. Журнал трассировки, связанный с поставщиком WMI кластера, который можно использовать для диагностики ошибок сценариев инструментария управления Windows (WMI) или прило-жений Microsoft System Center.
Использование канала FailoverClustering-Client/Diagnostic
При создании кластеров и присоединении узлов к кластеру нередко возникают проблемы, поэтому важно знать, как применять журнал FailoverClustering-Client/Diagnostic. По умолчанию этот канал выключен, и данные не регистрируются. Для включения канала щелкните на нем правой кнопкой и выберите Enable Log. После этого начинается сбор информации, относящейся к операциям присоединения и создания.
Предположим, что при включенном канале Diagnostic возникла проблема при создании кластера. Для просмотра собранных данных щелкните на канале правой кнопкой и выберите Disable Log. В журнале FailoverClustering-Client/Diagnostic можно увидеть следующее:
Event ID: 2 Level: Error Description: CreateCluster (1883): Create cluster failed with exception. Error = 8202, msg: Failed to create cluster name CLUSTER on DC \\DC.CONTOSO.COM. Error 8202. Event ID: 2 Level: Error Description: CreateClusterNameCOIfNotExists (6879): Failed to create computer object CLUSTER on DC \\DC.CONTOSO.COM with OU ou=Clusters,dc=contoso,dc=com. Error 8202.
Для просмотра значения кода состояния ошибки (8202) восполь-зуемся командой Net.exe:
NET HELPMSG 8202
Команда возвращает сообщение The specified directory service attribute or value does not exist («Указанное значение или атрибут службы каталогов не существует»). Новые возможности кластеров с обходом отказов Server 2012 предполагают, что кластер создается в том же подразделении (OU), что и узлы. Для создания имени кластера активный пользователь должен иметь, как минимум, разрешения Read и Create Computer Objects. Если пользователь не обладает такими правами, имя кластера не соз-дается, и выдается ошибка такого типа.
Теперь предположим, что ошибка возникает при добавлении узла в существующий кластер. При просмотре журнала FailoverClustering-Client/Diagnostic видим следующее:
Event ID: 56 Level: Warning Description: AsyncNotificationCallback (1463): ApiGetNotify on hNotify=0x0000000021EBCDC0 returns 1 with rpc_error 0 Event ID: 2 Level: Error Description: SCMStateNotify (837): Repost of NotifyServiceStatusChange failed for node 'NodeX': status = 1168
Описание первого события указывает на ошибку вызова удаленной процедуры (RPC). В описании второго события содержится код состояния 1168. Чтобы узнать значение кода, снова воспользуемся командой Net.exe:
NET HELPMSG 1168
На этот раз команда возвращает сообщение Element not found («Элемент не найден»). При попытке присоединения узла кластеру необходимо установить соединение RPC с присоединяемым узлом. В данном случае кластер не находит узел.
Из полученной информации можно заключить, что рабочий узел кластера не может установить RPC-соединение с добавляемым узлом, поскольку не находит его. После дальнейшего анализа выясняется, что на сервере DNS у добавляемого узла некорректный IP-адрес. После исправления IP-адреса узел успешно присоединяется к кла-стеру.
Новые тесты мастера проверки настроек
Полезным инструментом диагностики ошибок является мастер про-верки настроек Validate a Configuration Wizard, который в Server 2012 дополнен новыми тестами кластеризации. В приведенном ниже списке новые тесты выделены жирным шрифтом.
* Hyper-V (только если установлена роль Hyper-V):
— List Hyper-V Virtual Machine Information;
— List Information About Servers Running Hyper-V;
— Validate Compatibility of Virtual Fibre Channel SANs for Hyper-V;
— Validate Firewall Rules for Hyper-V Replica Are Enabled;
— Validate Hyper-V Integration Services Version;
— Validate Hyper-V Memory Resource Pool Compatibility;
— Validate Hyper-V Network Resource Pool and Virtual Switch Compatibility;
— Validate Hyper-V Processor Pool Compatibility;
— Validate Hyper-V Role Installed;
— Validate Hyper-V Storage Resource Pool Compatibility;
— Validate Hyper-V Virtual Machine Network Configuration;
— Validate Hyper-V Virtual Machine Storage Configuration;
— Validate Matching Processor Manufacturers;
— Validate Network Listeners Are Running;
— Validate Replica Server Settings.
* Cluster Configuration (только для рабочего кластера):
— List Cluster Core Groups;
— List Cluster Network Information;
— List Cluster Resources;
— List Cluster Volumes;
— List Clustered Roles;
— Validate Quorum Configuration;
— Validate Resource Status;
— Validate Service Principal Name;
— Validate Volume Consistency;
* Inventory:
— Storage
--List Fibre Channel Host Bus Adapters
--List iSCSI Host Bus Adapters
--List SAS Host Bus Adapters
— System
--List BIOS Information
--List Environment Variables
--List Memory Information
--List Operating System Information
--List Plug and Play Devices
--List Running Processes
--List Services Information
--List Software Updates
--List System Drivers
--List System Information
--List Unsigned Drivers
* Network:
— List Network Binding Order;
— Validate Cluster Network Configuration;
— Validate IP Configuration;
— Validate Network Communications;
— Validate Windows Firewall Configuration.
* Storage:
— List Disks
— List Potential Cluster Disks
— Validate CSV Network Bindings
— Validate CSV Settings
— Validate Disk Access Latency
— Validate Disk Arbitration
— Validate Disk Failover
— Validate File System
— Validate Microsoft MPIO-Based Disks
— Validate Multiple Arbitration
— Validate SCSI device Vital Product Data (VPD)
— Validate SCSI-3 Persistent Reservation
— Validate Simultaneous Failover
— Validate Storage Spaces Persistent Reservation
* System Configuration:
— Validate Active Directory Configuration
— Validate All Drivers Signed
— Validate Memory Dump Settings
— Validate Operating System Edition
— Validate Operating System Installation Option
— Validate Operating System Version
— Validate Required Services
— Validate Same Processor Architecture
— Validate Service Pack Levels
— Validate Software Update Levels
Кроме тестов хранилища, все тесты можно запускать в любой мо-мент, так как они не нарушают работу кластера.
Использование мастера проверки настроек
Рассмотрим применение мастера проверки настроек Validate a Configuration Wizard. Для предыдущего примера с проблемой при добавлении узла предположим, что IP-адрес на DNS правильный, и соединение между узлами за пределами кластера может быть установлено. В этом случае можно запустить мастер проверки настроек.
При работе мастера возникает ошибка выполнения теста Net-work/Validate Windows Firewall Configuration. В ходе этого теста при анализе параметров брандмауэра Windows выясняется, что порт 3343, используемый кластером, не включен. Если порт отключен, вся идущая через него связь блокируется, и канал Diagnostic выдает ошибки.
Новый параметр команды Get-ClusterLog
Команда Get-ClusterLog из инструментария PowerShell позволяет преобразовать регистрируемые в журнале (например, Failover-Clustering/Diagnostics) события в текстовый файл. Текстовый файл именуется Cluster.log и помещается в папку C:\Windows\Cluster\Reports. По умолчанию, при выполнении команды для каждого узла создается свой файл Cluster.log. Изменить это можно с помощью перечисленных ниже параметров, например, UseLocalTime.
- -Cluster – имя кластера, к которому применяется команда. Этот параметр позволяет указать удаленный кластер. Если параметр опущен, то команда применяется к текущему кластеру.
- -Node – имя узла, к которому применяется команда. Эта команда используется, если файл Cluster.log генерируется только для конкретного узла.
- * -Destination – папка, в которую копируются файлы Cluster.log. При использовании этого параметра PowerShell не только создает файл Cluster.log в папке C:\Windows\Cluster\Reports для каждого узла, но и копирует все файлы журнала в заданную папку. Имя узла составляет часть имени файла, копируемого в целевую папку (например, Node1_Cluster.log, Node2_Cluster.log), что позволяет легко идентифицировать журналы.
- -TimeSpan. Этот параметр используется для создания журнала за заданный интервал времени в минутах (например, 5), что по-зволяет значительно уменьшить анализируемый файл. Этот параметр можно использовать при воспроизведении ошибки, то есть воспроизвести предполагаемую ошибку и сгенерировать журнал за последние 5 минут, чтобы проверить предположение.
- -UseLocalTime. Как уже говорилось, это новый параметр в Server 2012. Вся информация в кластере регистрируется во вре-менной зоне GMT. Например, в часовом поясе GMT-5, когда местное время составит 13:00 (1:00 p.m.), в журнале Cluster.log по умолчанию будет указано время 18:00 (6:00 p.m.). Это облегчает сопоставление времени, возвращаемого командой Get-ClusterLog, со временем в журнале Event Log.
Освоив создание журналов Cluster.log, следует научиться из-влекать из них нужную информацию.
Анализ файлов Cluster.log
Анализ файлов Cluster.log может отнимать много времени из-за большого объема информации. Ниже приведены рекомендации, которые помогут правильно приступить к делу.
Прежде всего, следует знать строение файла Cluster.log. Каждая запись имеет свою основную структуру. В частности, запись о подключении ресурса с данным IP-адресом, выглядит следующим образом:
00000bb8.000001d4::2013/05/15-01:13:24.852 INFO [RES] IP Address: Online: Opened object handle for netinterface 353c85ee-7ea7-4b2a-927d-1538dffcdecd
Разобьем запись на отдельные фрагменты и поясним их смысл.
00000bb8 – шестнадцатеричное представление идентификатора процесса. Обычно процессом является Resource Host System (RHS). Сортируя или применяя поиск строк, включающих этот ID, можно узнать, какие ресурсы использует процесс. Это удобно в случае отладки дампа RHS при наличии нескольких файлов. Каждый дамп идентифицируется по ID, поэтому знание идентификатора гарантирует работу именно с нужным дампом процесса. Если есть полный дамп памяти, то в нем представлены несколько процессов RHS, каждый из которых идентифицируется по ID.
000001d4 – идентификатор цепочки в шестнадцатеричном пред-ставлении. Сортируя или применяя поиск строк, включающих этот ID, можно отследить действия цепочки. Используя этот ID для поиска, можно перейти прямо к нужной цепочке – например, при отладке процесса RHS, имеющего 100 цепочек.
2013/05/15-01:13:24.852 – дата и время в зоне GMT (если журнал генерируется без использования параметра UseLocalTime). В часовом поясе GMT-5 данное время соответствует местному времени 14 мая 2013 г., 8:13 p.m. Время детализируется с точностью до миллисекунд.
INFO – уровень записи: INFO (информация), WARN (предупреждение), ERR (ошибка) или DBG (отладка). Есть и другие, но в большинстве случаев используются именно эти уровни. Строка с ERR обычно означает проблему с ресурсом. Открыв файл Cluster.log, можно выполнить поиск по конкретному уровню, чтобы быстрее локализовать проблемный участок.
[RES] IP Address – тип ресурса. В журнале каждый ресурс иден-тифицируется по типу. Располагая этой информацией, можно быстро отследить проблемный подключающийся ресурс, если в одно и то же время подключаются ресурсы разных типов.
Online: Opened object handle for netinterface 353c85ee-7ea7-4b2a-927d-1538dffcdecd – описание того, что происходит с ре-сурсом. В данном случае ресурс открывает дескриптор доступа к драйверу сетевого адаптера для привязки к нему IP-адреса. Если здесь возникает сбой, то это может указывать на проблему с драйвером сетевого адаптера, либо на неисправность самого се-тевого адаптера. Следующим шагом будет анализ записей в журнале системных событий и поиск событий, относящихся к сети (сбой сети или сетевого адаптера). Выявить причину проблемы помогают описания. Особенно полезны описания последних действий перед наступлением отказа.
Поиск в файлах Cluster.log
Анализируя файлы Cluster.log, стоит задействовать поиск по ключевым словам. В таблице приведен список ключевых слов, ко-торые я использую для поиска ресурсов.
.jpg) |
Ключевые слова следует вводить в точности так, как они ото-бражены, то есть с двумя дефисами и знаком «больше» (-->) и без пробелов.
Ключевые слова также позволяют быстро определить, сколько времени требуется ресурсу для отключения или подключения. Предположим, например, что подключение некоторой группы занимает больше времени, чем обычно. В этом случае сначала можно применить поиск по -->OfflinePending, а затем по -->Offline для всех ресурсов группы. Другой вариант: сначала поиск по -->OnlinePending, а затем по -->Online. Для каждого ресурса суммируем значения времени, чтобы узнать, сколько времени ему требуется на подключение. Проделав это для каждого ресурса, сравним суммарные значения, чтобы узнать, какому ресурсу тре-буется наибольшее время. Затем можно проанализировать записи в журнале Cluster.log, чтобы определить причину. Например, если подключение группы занимает в целом 30 секунд на одном узле и три минуты на другом, то следует сгенерировать файлы Cluster.log для обоих узлов и сравнить их.
Для групп можно использовать те же ключевые слова, но за сим-волом «больше» должен следовать пробел. Например, при анализе отключения сначала используется --> OfflinePending, а затем --> Offline. Различается еще лишь запись при анализе отказа: для группы используется --> Failed, а для отказа -->ProcessingFailure.
Сведение информации воедино
Сведение представленной информации воедино мы рассмотрим на примере кластера, состоящего из двух узлов, обслуживаемых не-сколькими файловыми серверами, использующих разные сети и сеть хранения данных SAN с подключением по Fibre Channel. Для сетей используются следующие установки:
- Cluster Network 1 = IP scheme 192.168.0.0/24
- Cluster Network 2 = IP scheme 1.0.0.0/8
- Cluster Network 3 = IP scheme 172.168.0.0/16
В сетевых подключениях узлов сетевые адаптеры идентифицируются следующим образом:
- CORPNET = IP scheme 192.168.0.0/24
- MGMT = IP scheme 1.0.0.0/8
- BACKUP = IP scheme 172.168.0.0/16
Сервер FILESERVER1 использует сеть Cluster Network 1, функ-ционирующую на узле NODE1, а сервер FILESERVER2 – сеть Cluster Network 2 на узле NODE2.
Предположим, ночью произошел сбой, и группа файлового сервера FILESERVER2 переместилась с узла NODE2 на узел NODE1. Требуется выяснить причину отказа.
В диспетчере кластеров щелкаем правой кнопкой на группе FI-LESERVER2 и выбираем Show Critical Events («Показать критические события»). На экран выдаются следующие события:
Event ID: 1069
Description: Cluster Resource 'IP Address 1.1.1.1' of
type 'IP Address' in Clustered Role 'FILESERVER' failed.
Event ID: 1205
Description: The Cluster service failed to bring clustered
service or application 'FILESERVER2' completely online or
offline. One or more resources may be in a failed state.
Первое событие указывает на сбой ресурса с IP-адресом 1.1.1.1. Щелкаем правой кнопкой на этом ресурсе в диспетчере кластеров и выбираем Show Critical Events («Показать критические события»). На экран выдаются следующие события:
Event ID: 1077
Description: Health check for IP Interface
'IP Address 1.1.1.1' (address 1.1.1.1) failed (status is
1168). Run the Validate a Configuration wizard to ensure
that the network adapter is functioning properly.
Event ID: 1069
Description: Cluster Resource 'IP Address 1.1.1.1' of
type 'IP Address' in Clustered Role 'FILESERVER' failed.
На основании описания первого события (1077) воспользуемся мастером проверки настроек Validate a Configuration Wizard. Запускаем только тест Network/Validate Network Communication для проверки всех адаптеров и сетевых путей между узлами.
После выполнения теста Network/Validate Network Communication анализируем отчет. В отчете нет ни ошибок, ни предупреждений, поэтому откладываем его в сторону.
Есть каналы событий, которые можно проанализировать, поэтому обращаемся к каналу FailoverClustering/Operational, где имеется следующее событие:
Event ID: 1153
Description: The Cluster service is attempting to failover
the clustered service or application 'FILESERVER2' from
node 'NODE2' to node 'NODE1'
На основании этого описания переходим к каналу FailoverClus-tering/Diagnostics, где имеются следующие события:
Event ID: 2051
Description: [RCM] rcm::RcmResource::HandleFailure:
(IP Address 1.1.1.1)
Event ID: 2051
Description: [RES] IP Address:
Failed to query properties of adapter id
F3EDD1C8-6984-82BC-498806B841CA, status 87.
Генерируем файл Cluster.log для этого узла, в журнале выполняем поиск >ProcessingFailure и находим следующие записи:
[RES] IP Address: IP Interface
3600A8C0 failed LooksAlive check, status 1168.
[RES] IP Address: IP Interface
3600A8C0 failed IsAlive check, status 1168.
[RHS] Resource IP Address 1.1.1.1 has indicated failure.
[RCM] Res IP Address 1.1.1.1: Online -> ProcessingFailure
( State Unknown )
[RCM] TransitionToState( IP Address 1.1.1.1)
Online-->ProcessingFailure.
Далее в Cluster.log находим записи, в которых говорится о том, что группа была перемещена. Это указывает на то, что записи, найденные в результате поиска -->ProcessingFailure, имеют отношение к проблеме, обусловившей перемещение группы. По ошибкам, обозначенным в этих записях, мы точно знаем, что произошел сбой ресурса с данным IP-адресом. Чтобы выяснить значение кода статуса ошибки, воспользуемся командой Net.exe:
NET HELPMSG 1168
Команда возвращает сообщение Element not found («Элемент не найден»). После более тщательного изучения записей видим, что проблема может быть связана с сетевым адаптером. Несколько аппаратных тестов применительно к адаптерам выявляют неисправный адаптер, который даже не виден в Windows. Проблему решает замена неисправного адаптера.
Однако остается вопрос, почему в результатах теста Net-work/Validate Network Communication отсутствуют ошибки. Этот тест предусматривает проверку всех сетевых адаптеров, от одного узла к другому, независимо от их местонахождения (в одной или в разных сетях). Переходы между узлами осуществляются по всевозможным известным маршрутам. Поэтому существуют ожидаемые отказы, обусловленные особенностями организации кабельных соединений в сетях между узлами или разбиения сетей на сегменты.
При более тщательном изучении результатов теста обращаем вни-мание на информацию, представленную на экране 2.
.jpg) |
| Экран 2. Результаты теста Network/Validate Network Communication |
Мы видим, что узел NODE1 не имеет сетевого адаптера, опреде-ляемого как MGMT. По сути, это означает то же, что и события, то есть что у NODE1 – две сети, а у NODE2 – три. Следовательно, недостаточно просто просматривать ошибки и предупреждения в верхней части отчета. Необходимо также изучать результаты теста.
Существуют разные способы диагностики неполадок кластера и множество путей анализа информации, позволяющей проникнуть в суть проблемы. Здесь представлен лишь один из способов выявления причин проблем, возникающих в кластерах. Дополнительную информацию можно найти в блогах Ask the Core Team (blogs.technet.com/b/askcore) и Clustering and High Availability (blogs.msdn.com/b/clustering).
Таблица. Ключевые слова, используемые для поиска ресурсов
Ключевое слово Описание
-->OnlinePending Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Ожидание подключения» (Online Pending) для ресурса. Именно здесь должен начинаться поиск, если требуется отследить подключение ресурса
-->OfflinePending Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Ожидание отключения» (Offline Pending) для ресурса. Именно здесь должен начинаться поиск, если требуется отследить отключение ресурса
-->Offline Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Автономная работа» (Offline) для ресурса. Если отслеживается ресурс, то смотреть дальше необходимости нет. Если этот ресурс зависит от другого ресурса, то тот другой ресурс мог начать процесс отключения первым
-->Online Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «В сети» (Online) для ресурса. Если отслеживается ресурс, то смотреть дальше нет необходимости. Если от этого ресурса зависит другой ресурс, то тот другой ресурс не начнет свой процесс подключения к сети, пока не завершен этот процесс
-->ProcessingFailure Это ключевое слово появляется в журнале при отказе ресурса. При наличии такой строки необходимо про-смотреть предыдущие записи, чтобы узнать, что инициировало отказ. В просмотре записей после этого события необходимости нет. При отказе ресурса всегда следует попытаться пройти через нормальный процесс отключения, даже если, скорее всего, будет выдана ошибка, поскольку ресурс недоступен.