Windows Server 2008 R2: Сценарии устранения неполадок отказоустойчивых кластеров

Посетителей: 5547 | Просмотров: 8227 (сегодня 0) Шрифт:

В прошлом месяце я рассмотрел некоторые наиболее популярные сложности с отказоустойчивыми кластерами в Windows Server 2008 R2 и рассказал о способах корректного устранения этих неполадок.

Вспомните, что текущая политика поддержки предполагает, что решение отказоустойчивой кластеризации в Windows Server 2008 и Windows Server 2008 R2 может считаться официально поддерживаемым службой поддержки потребителей Microsoft (Customer Support Services, CSS), только если удовлетворяет следующим критериям:

• Все компоненты, включая оборудование и программное обеспечение, должны удовлетворять требованиям для получения логотипа «Certified for Windows Server 2008 R2».
• Окончательно настроенное решение должно пройти проверочный тест в оснастке «Failover Cluster Management» (Управление отказоустойчивыми кластерами).

Есть несколько сценариев устранения неполадок. Они представляют самые популярные неполадки отказоустойчивых кластеров Windows Server 2008 R2 и шаги по их устранению.

Сценарий 1. В процессе ежемесячной очистки объектов Active Directory по неосторожности был удален Cluster Name Object. Вновь созданный объект не переходит в интерактивный режим.

Объект CNO (Cluster Name Object) это общий идентификатор кластера, и поэтому он очень важен. Он создается автоматически мастером создания кластера (Create cluster) и носит то же имя, что и кластер. По мере настройки новых служб и приложений в этой учетной записи, CNO создает другие виртуальные объекты. При удалении CNO или его разрешений он не может создавать другие необходимые кластеру объекты до тех пор, пока не будет восстановлен или ему не будут назначены соответствующие разрешения.

Как и в случае с другими объектами Active Directory, у CNO есть связанный идентификатор objectGUID. По нему отказоустойчивый кластер узнает, что имеет дело с правильным объектом. Если просто создать новый объект, то у него будет новый objectGUID. Нужно восстановить правильный объект, чтобы отказоустойчивый кластер мог продолжить нормальную работу.

При устранении этой неполадки нужно найти две вещи, относящиеся к ресурсу кластера. В Windows PowerShell выполните команду:

Get-ClusterResource «Cluster Name» | Get-ClusterParameterCreatingDC,objectGUID

Эта команда сообщает необходимые значения. Первый параметр — CreatingDC. Когда отказоустойчивый кластер создает CNO, отмечается контроллер домена, в котором он был создан. При любой выполняемой с кластером операции (создание виртуального объекта, перевод в интерактивное состояние и т.п.) к этому контроллеру обращаются за объектом CNO и информацией безопасности. Если контроллер домена найти не удается или он недоступен, тогда уже выполняется поиск любого другого ответственного контроллера.

Второй параметр – objectGUID – отвечает за то, чтобы можно было быть уверенным, что получен правильный объект. В нашем случае имя кластера —CLUSTER1, контроллер, на котором он был создан, — DC1, а значение objectGUID — 1a3cf049cf79614ebd94670560da6f04:

Object Name Value
—— —- ——
Cluster Name CreatingDC \\DC1.domain.com
Cluster Name ObjectGUID1a3cf049cf79614ebd94670560da6f04

Надо войти в систему DC1 и открыть консоль Active Directory Users and Computers (Active Directory — пользователи и компьютеры). Если в ней есть текущий объект CLUSTER1, можно проверить наличие в нем правильных атрибутов. Редактор атрибутов Active Directory не показывает GUID, поскольку он не отражается в шестнадцатеричном формате.

В противном случае мы увидели бы такое значение 49f03c1a-79cf-4e61-bd94-670560da6f04. Шестнадцатеричный формат преобразуется и работает в парах, что немного смущает. Если взять первые восемь пар и выполнить преобразование, то 49f03c1a станет 1a3cf049. В следующих двух парах 79cf станет cf79, а 4e61 — 614e. Оставшиеся пары останутся такими же.

Чтобы увидеть в шестнадцатеричном формате то, что видит отказоустойчивый кластер, свойства объекта objectGUID нужно передать в редактор атрибутов. Поскольку это неправильный объект, сначала надо удалить объект, чтобы было возможно восстановить правильный объект.

Восстановить объект можно несколькими способами. Можно воспользоваться Active Directory Restore, утилитой, подобной ADRESTORE, или новой корзиной Active Directory (если это контроллер домена Windows 2008 R2 с обновленной схемой). Новая корзина значительно упрощает процесс и делает его самым удобным для восстановления объектов Active Directory.

С помощью корзины Active Directory можно найти объект восстановления, выполнив команду Windows PowerShell:

Эта команда выполняет поиск всех удаленных объектов с именем CLUSTER1 в корзине Active Directory. В результате получаем имя учетной записи и objectGUID. Если найдены несколько элементов, все они будут показаны. При просмотре нужного элемента мы увидим:

Теперь его надо восстановить. После удаления неправильного объекта для восстановления следует использовать такую команду Windows PowerShell:

Restore-ADObject –identity 49f03c1a-79cf-4e61-bd94-670560da6f04

В результате объект будет восстановлен в том же месте (подразделении) с теми же разрешениями и паролем, известным Active Directory.

Это одно из преимуществ корзины Active Directory по сравнению с аналогами утилиты ADRESTORE. При восстановлении эти утилиты сбрасывают пароль, перемещают объект в соответствующий контейнер, восстанавливают объект в отказоустойчивом кластере и т.д.

Используя корзину, мы просто переводим ресурс в интерактивный режим. Это более удачный вариант, чем восстановление Active Directory, особенно если позже были созданы новые объекты пользователя или компьютера, удалены старые объекты и т. п.

Сценарий 2. В оснастке «Управление отказоустойчивым кластером» общие тома кластера отмечены как Redirected Access (перенаправленный доступ). Как исправить ситуацию?

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

Надо позаботиться, чтобы в параметрах всех сетевых адаптеров, обеспечивающих связь кластеров, были установлены компоненты Client for Microsoft Networks (Клиент для сетей Microsoft) и File and Printer Sharing for Microsoft Networks (Общий доступ к файлам и принтерам в сетях Microsoft), для поддержки протокола SMB (Server Message Block). Это необходимо для общего тома. Сервер работает под управлением Windows Server 2008 R2, что автоматически обеспечивает версию SMB, необходимую для общего тома, а именно SMB2.Используется только одна предпочтительная коммуникационная сеть для общего тома, но включение этих параметров во множестве сетей поможет кластеру противостоять отказам.

Перенаправление доступа подразумевает, что все операции ввода-вывода «перенаправляются» по сети на другой узел, имеющий доступ к диску. Могут быть три причины для перехода в режим перенаправления доступа:

1. Режим настроен вручную.
2. Идет процесс резервного копирования.
3. Имеются неполадки с оборудованием, и узел не может напрямую получить доступ к диску.

В нашем сценарии мы исключили первые два варианта. Остается третий. Если заглянуть в журнал системных событий System Event Log, можно увидеть событие отказоустойчивой кластеризации «Event ID: 5121».

Определение этой записи журнала: Общий том кластера CSV «Cluster Disk x» более не доступен напрямую с этого узла кластера. Ввод-вывод будет перенаправлен на устройство хранения по сети через узел-владелец, которому принадлежит этот том. Это может привести к снижению производительности. Если перенаправление доступа к этому тому включено, отключите его. Если перенаправление доступа отключено, устраните неполадки связи этого узла с устройством хранения; после восстановления связи с устройством хранения работоспособность ввода-вывода будет также восстановлена.

В такой ситуации надо тщательно изучить все предшествующие этому события, связанные с оборудованием. Это значит, что надо искать такие события, как 9, 11, 15, которые указывают на неполадки оборудования или связи. Стоит провести физическую проверку диску в панели Disk Management (Управление диском). В большинстве случаев так удается обнаружить другие ошибки. Решив проблему, можно вывести диск из этого режима.

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

Сценарий 3. Я только что создал новый отказоустойчивый кластер Windows 2008 R2 для виртуальных машин с высоким уровнем доступности. Диски настроены для работы с общим томом, но при попытке доступа к ним с помощью проводника или панели «Управление диском» происходит зависание. Я не могу скопировать на том файлы виртуального диска.

Существует только один «истинный» владелец диска и он называется узел-координатор (Coordinator Node). Запись любого типа метаданных выполняется только этим узлом.

Проводник или панель управления диском открывает диск с возможностью записи любых метаданных (если такое предполагается). По этой причине любой диск, не находящийся в собственности, перенаправляется по сети на узел-координатор. Это не совсем то же, что «перенаправление доступа».

В процессе устранения этой неполадки в оснастке «Управление отказоустойчивым кластером» можно увидеть, что диск находится в интерактивном режиме. Поэтому сначала надо изучить события в журнале. В журнале системных событий можно увидеть события отказоустойчивой кластеризации:

Событие ID: 5120

Общий том кластера «Cluster Disk x» больше не доступен на этом узле из-за «STATUS_BAD_NETWORK_PATH(c00000be)». Все операции ввода-вывода будут временно поставлены в очередь, пока путь к тому не будет восстановлен. (Cluster Shared Volume ‘Cluster Disk x’ is no longer available on this node because of ‘STATUS_BAD_NETWORK_PATH(c00000be).’ All I/O will temporarily be queued until a path to the volume is reestablished.)

Событие ID: 5142

С данного узла кластера больше нельзя получить доступ к общему тому кластера ‘Cluster Disk x’ из-за ошибки ‘ERROR_TIMEOUT(1460)’. Проверьте подключение данного узла к устройству хранения и сети.

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

Далее надо проверить возможность связь узлов по сети. Первым делом нужно проверить сеть, по которой передается трафик общего тома. В отказоустойчивом кластере сеть для общего тома выбирается, исходя из максимального значения метрики. Это отличается от того, как Windows идентифицирует сети.

Сетевой отказоустойчивый адаптер для отказоустойчивого кластера (Failover Cluster Network Fault Tolerance, NETFT) имеет свою собственную внутреннюю систему метрик. Все выявленные им сети имеют шлюз по умолчанию и получают метрики 10000, 10100 и т. д. Метрики всех сетей без шлюза по умолчанию начинаются с 1000, 1100 и т. д. Чтобы узнать, как адаптер NETFT определил их, можно использовать команду Windows PowerShell:

Вы увидите примерно следующее:

Name Metric
——————-
Management 10100
CSV Traffic 1000
LAN-WAN 10000
Private 1100

Среди этих сетей сеть, которую я определил как сеть общего тома, — CSV Traffic. Для узла Node1 я использовал IP-адрес 1.1.1.1 и 1.1.1.2 для узла Node2, поэтому я проверяю сетевое соединение с помощью команды PING.

Следующим шагом будет попытка соединения по протоколу SMB к указанным IP-адресам. Это то, что делает служба кластеризации. Чтобы получить ответ, достаточно выполнить простую команду:

В ответ будет получен или список общих ресурсов или сообщение «There are no entries in the list» (то есть список пуст).

Это указывает на то, что можно было бы создать соединение с этим общим ресурсом. Однако сообщение «System error 53 has occurred. The network path was not found» (Ошибка 53. Сетевой путь не найден) указывает на проблему в настройке TCP/IP сетевой карты.

Для работы с общим томом необходимы компоненты «Client for Microsoft Networks» и «File and Printer Sharing for Microsoft Networks». Если они отсутствуют, то возникает проблема с зависанием Проводника.

В Windows 2003 Server Cluster и ниже рекомендовалось отключать эти компоненты. Сейчас в этом нет необходимости.

Другие факторы

Есть несколько факторов, которые следует принять во внимание. Если узлы кластера вызывают отказ подсистемы размещения ресурсов (Resource Host Subsystem, RHS), первым делом нужно вспомнить о природе RHS и ее функциях. RHS — это компонент отказоустойчивого кластера, выполняющий проверку работоспособности множества ресурсов для обеспечения работоспособности. Что касается IP-адресов, то этот компонент проверяет, находится ли адрес в сетевом стеке и реагирует ли на запросы. Проверяя диски, он пытается соединиться и выполнить команду DIR.

Если сбоит RHS, проверьте журнал системных событий на наличие записей с идентификаторами 1230 и 1146. В событии 1230 фактически указывается ресурс и используемые библиотеки DLL. Если произошел сбой, это означает, что ресурс не отвечает должным образом и возможна взаимная блокировка. Если сбой произошел на дисковом ресурсе, следует просмотреть наличие ошибок, связанных с диском или слишком большим временем отклика диска. Неплохо начать с использования монитора производительности (Performance Monitor). Также приветствуется обновление драйверов и микропрограммы карт или компонентов сети.

Помимо этого следует сделать некоторые наблюдения. Служба кластеризации проводит проверку работоспособности пользовательских процессов из режима ядра, чтобы выявить, когда пользовательский режим перестает отвечать или происходит зависание. Для вывода из этого состояния служба кластеризации проводит проверку ошибкой. Если это происходит, будет получена ошибка Stop 0x0000009E. Чтобы устранить неполадку, надо изучить файл дампа, созданный для поиска причин зависания. Также можно запустить монитор производительности и посмотреть, будут ли возникать зависания, утечки памяти и т. п.

Служба кластеризации зависит от инструментария управления Windows (Windows Management Instrumentation, WMI). Если возникают проблемы с WMI, это ведет к проблемам с кластеризацией (с созданием и добавлением узлов, миграцией и т. п.). Проверьте WMI, например, WBEMTEST.EXE или даже удаленные сценарии WMI.

Один сценарий можно попытаться выполнить в консоли Windows PowerShell (здесь NODE1 — имя узла):

get-wmiobjectmscluster_resourcegroup -computer NODE1 -namespace «ROOT\MSCluster»

Он создает соединение WMI с кластером и предоставляет информацию о группах.

Неудачное завершение сценария указывает на проблемы с WMI. Перезапустите службу WMI, если она остановлена. Может быть повреждена база данных WMI (для проверки целостности воспользуйтесь командой Windows PowerShell: winmgmt /salvagerepository) и т. д.

Помните о ряде правил устранения неполадок:

• Проверяйте, проверяйте и еще раз проверяйте. При устранении неполадок используйте тесты для проверки кластера. Используйте их при изменении системы.
• Все больше систем переводятся на Windows PowerShell, поэтому начните изучать эту технологию, если вы ее еще не освоили.
• Если вы зависите от объектов Active Directory, защитите их. Разрешите использование корзины Active Directory и защитите объекты от случайного удаления.
• При устранении неполадок общего тома не забывайте, что проблема может быть не только в неполадках оборудования.
• При устранении неполадки сделайте шаг назад и внимательно проанализируйте все, на что она может оказывать влияние, и постепенно сужайте поле поиска.

Служба отказоустойчивой кластеризации создана для выявления, восстановления и предоставления отчетов об ошибках. Когда кластер «говорит», что есть или была неполадка, это не значит, что он вызвал ее. Как говорится, «не убивайте гонца, принесшего дурную весть».