Ресурс кластера физический диск обнаружил ошибку при попытке завершить
В этой статье мы рассмотрим методы устранения неполадок отказоустойчивых кластеров Windows Server 2008 R2. Существует много способов диагностики кластеров, и каждый специалист может иметь свои особые приемы. Однако здесь я представлю наиболее общие подходы к решению проблем
Джон Марлин
. Вначале поговорим о файлах, с которыми обычно приходится иметь дело, и об их описаниях.
Первое, с чем предстоит работать – диспетчер отказоустойчивости кластеров. Этот новый инструмент управления кластером позволяет руководить группами и ресурсами и выполнять диагностику неполадок. Диспетчер отказоустойчивости кластеров открывается из пункта «Администрирование» в меню «Пуск».
Решение
Чтобы обойти это поведение, перенесите узел, который был отключен в автономном режиме, обратно в режиме онлайн. Переместите группу обратно в узел, который вы только что принесли в Интернете, а затем проверьте список возможных владельцев каждого ресурса, чтобы убедиться, что узел, на который группа не пришла в интернете, указан.
Если вы не можете привести узел в сеть из-за действительного сбойного узла, добавьте соответствующий узел в список возможных владельцев:
В администраторе кластера откройте общие свойства каждого ресурса и просмотрите список возможных владельцев.
После поиска ресурса с пустым списком возможных владельцев и кнопкой "Изменение" обратите внимание на имя этого ресурса.
Откройте командную подсказку и введите следующую команду. Имя ресурса — это имя ресурса, которое вы отметили в шаге 1:
имя повторного кластера ресурсов /listowners
Отображается список возможных владельцев ресурса. В этом списке указывается, что единственным возможным владельцем является узел, который находится в неуловимом списке.
Из командной подсказки запустите следующую команду, чтобы добавить другой узел в список возможных владельцев, где отсутствующий узел — это узел, который находится вниз:
кластер повторное имя ресурса /addowner: отсутствующий узел
В кластерном администраторе снова принесите группу, которая ранее была в автономном состоянии.
После выхода группы в сеть, если у вас возникли проблемы с просмотром ресурсов администратора кластера, увольняйся с администратора кластера и снова подключись к кластеру.
Проблема 4
CNO и VCO – учетные записи компьютера и, подобно учетным записям пользователей, они имеют пароли, генерируемые AD случайным образом. По умолчанию политика домена предусматривает сброс пароля учетной записи компьютера каждые 60 дней.
СNO используется для таких операций, как добавление новых узлов к кластеру, создание новых объектов в домене и выполнение динамической миграции виртуальных машин с узла на узел. Для выполнения этих операций пароль CNO в домене должен быть актуальным. Для верности служба кластера делает попытку сброса паролей этих объектов по истечении половины срока (через 30 дней). Если пароль не сброшен на 60-дневной отметке, имя кластера не видно в сети.
Для сброса пароля необходимо выполнить восстановление в диспетчере отказоустойчивости кластеров. Как показано на экране 6, щелкните правой кнопкой имя проблемного ресурса и выберите «Дополнительные действия» и «Восстановить».
Экран 6. Сброс пароля вручную в диспетчере отказоустойчивости кластеров |
При обращении к AD для сброса пароля диспетчер отказоустойчивости кластеров задействует учетную запись пользователя, под которой вы зарегистрировались в системе, поэтому вашей учетной записи должно быть предоставлено право на изменение пароля CNO; в противном случае восстановление не будет выполнено. Необходимо также убедиться, что включено разрешение на сброс пароля CNO и VCO, чтобы служба WSFC могла выполнять сброс при необходимости.
Статус
Такое поведение является особенностью данного продукта.
Диспетчер отказоустойчивости кластеров
Для упрощения анализа системные ошибки и предупреждения можно просматривать из окна диспетчера отказоустойчивости кластеров. На главной странице на центральной панели находится ссылка на последние события кластера Recent Cluster Events (экран 2). Эта ссылка позволяет вывести на экран все предупреждения и ошибки, связанные с отказоустойчивым кластером, за последние 24 часа. События, собранные со всех узлов, сосредоточены в одном месте, что избавляет от необходимости открывать несколько журналов событий на нескольких компьютерах.
Экран 2. Последние события кластера |
Для просмотра конкретных событий можно использовать элемент Query, доступ к которому открывается из элемента Cluster Events на левой панели главной страницы. В меню, которое мы открываем правым щелчком на Cluster Events, выберите пункт Query, либо укажите Query на панели Actions справа. На экране 3 показан фильтр событий кластера.
Экран 3. Фильтр событий кластера |
Диспетчер отказоустойчивости кластеров – удобный инструмент для отображения всех данных в одном месте. Предположим, что произошел отказ некоего ресурса диска. В окне диспетчера отказоустойчивости кластеров можно запросить все узлы, журнал системных событий System, а также указать уровень событий и конкретную дату. На главной странице можно будет увидеть, когда и на каких узлах случился отказ диска, и просмотреть все относящиеся к этому событию данные. Запросы можно сохранить для последующего использования.
Поиск событий определяют два параметра. События появления отказов можно искать по всем ресурсам, либо только по конкретному ресурсу. Для этого в меню Actions (экран 4) можно выбрать пункт Show the critical events for this application («Отображение критических событий для данного приложения») или Show the critical events for this resource («Отображение критических событий для данного ресурса»). Это позволяет формировать запрос всех событий из текущих журналов, создаваемых на всех узлах, либо ограничить список запрашиваемых событий рамками заданного периода времени или узла.
Экран 4. Пункт Actions в диспетчере отказоустойчивости кластеров |
Журнал диагностики включен и постоянно осуществляет запись. Если в меню, открываемом правым щелчком на FailoverClustering\Diagnostic, выбрать команду Disable log («Отключить журнал»), то можно просмотреть все записанные события. После отключения журнала система перестает записывать в него данные, и информация не сохраняется. Если журнал был отключен, то лучше всего сохранить данные в виде журнала событий или текстового файла и включить журнал снова. В журнале регистрируются три основных типа событий:
*событие 2049 – информационное;
*событие 2050 – предупреждение;
*событие 2051 – ошибка.
Эти события выводятся только из текущего журнала трассировки событий. ETL, в который осуществляется запись. Информация о событиях отображается так же, как в системном журнале и журнале приложения. Однако каждое событие занимает отдельную строку, поэтому просмотр всего журнала диагностики может оказаться делом довольно утомительным. Можно создать текстовый файл Cluster.Log с помощью команд, позволяющих свести воедино три журнала, что значительно облегчает восприятие информации.
Команда PowerShell Get-ClusterLog инициирует на всех узлах создание журнала Cluster.Log, который помещается в папку C:\Windows\Cluster\Reports. Меню Get-ClusterLog содержит пункты, которые могут оказаться полезными в определенных обстоятельствах. Например, для выяснения причин проблемы можно воспроизвести ее, а затем воспользоваться командой
Создаваемый журнал Cluster.Log – это моментальный снимок во времени, который фиксирует текущее состояние и уже не обновляется. Если при создании журнала в папке Reports уже есть Cluster.Log, то существующий файл удаляется и освобождается место для нового.
Каналы событий
Каждый, вероятно, знаком с журналом системных событий, в котором регистрируются критически важные события, ошибки и предупреждения. Однако это не единственное место, где фиксируются события. Начиная с Server 2008, существуют еще и каналы событий. На экране 1 показано, как найти каналы, имеющие отношение к отказоустойчивой кластеризации. Именно здесь следует искать все информационные и отладочные/диагностические события. На схеме мы видим следующие журналы и их каналы:
* Diagnostic (если выбран пункт Show Analytic and Debug Logs («отобразить журналы анализа и отладки»))
* Performance-CSV (если выбран пункт Show Analytic and Debug Logs)
* Diagnostic (если выбран пункт Show Analytic and Debug Logs)
* Diagnostic (если выбран пункт Show Analytic and Debug Logs)
* Diagnostic (если выбран пункт Show Analytic and Debug Logs).
Экран 1. Каналы, относящиеся к?отказоустойчивой кластеризации |
События запуска/остановки службы кластеров, перемещения групп, перевода групп в онлайн/автономный режим и т.д. регистрируются в журнале FailoverClustering\Operational. Например:
-Идентификатор события: 1061
-Описание: служба кластеров успешно настроила отказоустойчивый кластер JohnsCluster.
Неудачные попытки установления соединения с другими узлами при открытии диспетчера отказоустойчивости кластеров регистрируются в журнале FailoverClustering-Manager\Admin. Например:
-Идентификатор события: 4684
В журнале FailoverClustering-Manager\Diagnostic можно увидеть следующее:
-Идентификатор события: 4609
-Идентификатор события: 4612
Именно по этим событиям можно установить проблему подключения узла к серверу DNS и затем приступить к ее устранению. Не просматривая указанные журналы, о наличии неполадок можно будет судить по тому, что в диспетчере отказоустойчивости кластеров узел W2K8 R2-NODE2 будет отображен как неисправный. Еще один журнал в числе упомянутых выше, Failover-Clustering\Diagnostic, мы обсудим несколько позже.
Проблема 6
В листинге приведен сценарий Windows PowerShell, позволяющий выявить узел, утративший экземпляр Cluster WMI.
Установив проблемный узел, можно ввести команду
Наиболее распространенной причиной утраты Cluswmi.mof узлом является устаревший способ решения проблем WMI. Для устранения неполадок WMI администраторы обычно используют команду Mofcomp.exe *.mof, позволяющую скомпилировать все файлы Managed Object Format (MOF) в репозиторий WMI. Однако дело в том, что существует довольно много файлов удаления для различных ролей и компонентов Windows, включая Cluster WMI. Поэтому файл Cluswmi.mof, устанавливаемый с помощью этой команды, впоследствии удаляется. Правильный способ восстановления репозитория WMI – с использованием команды Winmgmt.exe.
Симптомы
На узле кластера, который работает Windows Server, физический дисковый ресурс может входить в состояние Failed при попытке перемещения группы, содержаной физический дисковый ресурс. Если перезапустить узел кластера, на который не пришел физический дисковый ресурс, проблема временно устранена.
При этой проблеме в журнал кластера для ресурса физического диска, вступив в состояние сбой, вошел следующий вход:
000020cc.000014d0:: Физический диск ERR:
DiskspCheckPath: GetFileAttrs (Q:) возвращенный статус 87.
000020cc.000014d0:: WARN Physical Disk:
DiskspCheckDriveLetter: Проверка имени диска (Q:) возвращает 87
Кроме того, в журнале system Event регистрируются следующие события:
Кроме того, на узле кластера Windows Server можно увидеть, как в журнале кластера регистрируются следующие записи:
00000db0.00000868:: WARN [RES] Физический диск: OnlineThread: не удалось получить guid тома для устройства \ ?\GLOBALROOT\Device\Harddisk15\Partition1. Ошибка 3
00000db0.00000868:: WARN [RES] Физический диск: OnlineThread: не удалось установить волгу?\Volume. ? Ошибка: 183.
00000db0.00000868:: INFO [RES] Физический диск: VolumeIsNtfs: Volume \ ?\GLOBALROOT\Device\Harddisk15\Partition1\ имеет тип FS NTFS
Проблема 3
Для формирования кластера необязательно быть администратором домена, но создание объектов в Active Directory (AD) требует наличия соответствующих прав. Как минимум, необходимо обладать правами на просмотр и создание объектов (Read and Create) в том подразделении (OU), где создается данный объект имени кластера (CNO). CNO – это объект-компьютер, связанный с ресурсом-кластером «Имя кластера». При создании кластера служба WSFC использует учетную запись, с которой вы регистрировались в системе, чтобы создать объект CNO в том же OU, которому принадлежат узлы. Если вы не обладаете достаточными правами в отношении данного OU, кластер не будет создан, и система выдаст ошибку, как показано на экране 3.
Экран 3. Ошибка процесса создания кластера |
В статье «Диагностика проблем отказоустойчивых кластеров Windows Server 2012» (№ 10 за 2013 г.) я рассказывал об использовании мастера проверки конфигурации в диспетчере отказоустойчивости кластеров для выявления причин возникающих проблем. Мастер позволяет выполнять различные тесты, включая проверку настроек Active Directory. В ответ на попытку запуска этого теста без достаточных прав в отношении данного OU будет выдана ошибка, как показано на экране 4. Соответствующая настройка прав позволит вам создать кластер.
Экран 4. Ошибка проверки настроек Active Directory |
Все другие ресурсы с сетевыми именами в кластере ассоциированы с объектами виртуальных компьютеров (VCO), создаваемыми в том же OU, что и CNO. Следовательно, при назначении ролей в кластере необходимо указать CNO с соответствующими правами (просмотр и создание) в отношении OU, поскольку CNO формирует все VCO в кластере. В противном случае новая роль будет находиться в состоянии сбоя. Тогда в журнале появится событие 1194 (см. экран 5).
Экран 5. Событие 1194 в журнале событий системы |
Есть и другие установки локального компьютера, способные вызвать ошибки (включая ошибки отказа в доступе) при создании VCO в AD.
1. В составе локальной группы «Пользователи» больше нет группы «Прошедшие проверку пользователи». Обычно она удаляется объектами групповой политики (GPO) или шаблонами безопасности.
2. В локальной политике безопасности разрешение Access this computer from the network («Доступ к этому компьютеру по сети») или Add workstations to the domain («Добавление рабочих станций к домену») больше не включает группу «Прошедшие проверку пользователи». Обычно она удаляется объектами групповой политики (GPO) или шаблонами безопасности.
3. Включены следующие права доступа:
- сетевой доступ (не разрешать перечисление учетных записей SAM анонимными пользователями);
- сетевой доступ (не разрешать перечисление учетных записей SAM и общих ресурсов анонимными пользователями).
4. Ресурс имени кластера в состоянии сбоя.
Дополнительная информация
Дополнительные сведения о утилите Handle.exe см. в этой.22.
В этой статье упомянуты программные продукты независимых производителей. Корпорация Майкрософт не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.
Я работаю в группе, которая занимается поддержкой отказоустойчивых кластеров, поэтому мне часто приходится выявлять и устранять неисправности. В этой статье будут описаны типичные проблемы, с которыми я сталкивался, с пояснением причин их возникновения и рекомендациями по их устранению
Симптомы
Произошла ошибка при попытке вывести группу "GroupName" в интернет:
Узел кластера не является владельцем ресурса.
ID ошибки: 5015 (00001397).
Произошла ошибка при попытке вывести ресурс ResourceName в интернет:
Ресурс кластера не может быть доставлен в Интернет. Узел владельца не может запустить этот ресурс.
ID ошибки: 5071 (000013df).
Для этого ресурса не указаны возможные владельцы. Это означает, что этот ресурс не может быть доставлен в интернет на любом узле кластера.
Проверка кластера
Последняя тема обсуждения – отчет о результатах проверки кластера Cluster Validate. Чтобы кластер был «кондиционным», все его компоненты должны быть перечислены в каталоге Windows Server, и необходимо, чтобы он прошел полную проверку. Многие запускают проверку кластера до или сразу после создания. Однако если проблемы возникают позже, то лишь немногие помнят об этой функции, которую также можно использовать как средство диагностики. Если возникают проблемы с диском, запустите тесты хранилища Storage Tests. При наличии проблем с сетевой передачей данных воспользуйтесь сетевыми тестами Network Tests. С помощью функции проверки кластера можно также получить данные о группах, ресурсах и параметрах текущего отказоустойчивого кластера для обращения к этим сведениям в дальнейшем.
Достоинством проверки кластера является возможность ее запуска без прерывания рабочего процесса. При выборе теста хранилища Storage Test выдается вопрос, следует ли переводить работающие группы в автономный режим (экран 5). Установка по умолчанию предполагает невмешательство в работу групп, находящихся в режиме онлайн, и рабочий процесс не затрагивается. Тесты хранилища предусматривают проверку дисков, которые:
— принадлежат группам в автономном режиме;
— принадлежат активной группе хранения;
— не являются частью кластера.
Экран 5. Проверка кластера |
При каждом запуске проверки кластера в каталоге C:\Windows\Cluster\Reports на каждом проверяемом узле создается файл с именем, часть которого составляют дата и время.
Добрый вечер. Собрали кластер из двух узлов, подключил диски и назначил диск свидетель - все заработало, но стали каждые 15 минут появляются
сначала предупреждение:
Служба кластеров обнаружила неполадку ресурса-свидетеля. Этот ресурс-свидетель будет перемещен на другой узел в кластере, чтобы попытаться повторно получить доступ к данным конфигурации кластера.
а затем ошибка:
Сбой ресурса кластера "Диск кластера 2" с типом "Physical Disk" в кластерной роли "Кластерная группа".
В зависимости от политик на случай сбоя ресурса и роли служба кластеров может попытаться подключить ресурс на этом узле или же переместить группу на другой узел кластера, а затем перезапустить ее. Проверьте состояние ресурса и группы с помощью диспетчера отказоустойчивости кластеров или командлета Get-ClusterResource оболочки Windows PowerShell."
Так же каждые 3 минуты присутствуют 2 предупреждения
Общий том кластера "Volume2" ("") определил наличие в стеке устройств одного или нескольких драйверов фильтра, которые могут препятствовать операциям с этим общим томом кластера. Ввод-вывод будет перенаправлен к устройству хранения по сети через другой узел кластера. Это может привести к снижению производительности. Обратитесь к поставщику драйвера фильтра, чтобы проверить возможность взаимодействия с общими томами кластера.
Найдено активных драйверов фильтра:
攀尀䠀愀爀搀搀椀猀欀嘀漀氀甀洀攀㈀ 㐀䤀䘀吀猀猀䘀氀爀
Общий том кластера "Volume1" ("") определил наличие в стеке устройств одного или нескольких драйверов фильтра, которые могут препятствовать операциям с этим общим томом кластера. Ввод-вывод будет перенаправлен к устройству хранения по сети через другой узел кластера. Это может привести к снижению производительности. Обратитесь к поставщику драйвера фильтра, чтобы проверить возможность взаимодействия с общими томами кластера.
Найдено активных драйверов фильтра:
攀尀䠀愀爀搀搀椀猀欀嘀漀氀甀洀攀㤀㔀䤀䘀吀猀猀䘀氀爀
Так же после нескольких дней стабильной работы с этими ошибками произошел первое отключение всех виртуальных машин с уведомлением о недоступности хранилища, но больше ошибка не повторялась.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 313882
Проблема 5
Чтобы узел был осведомлен о том, какие узлы являются активными участниками кластера (то есть о текущем членстве), применяется ряд периодических контрольных сигналов, передаваемых между узлами по сети. Эти пакеты сигналов представляют собой UDP-датаграммы, следующие через порт 3343.
Каждый пакет включает регистрационный номер, по которому отслеживается факт приема пакета. Это работает следующим образом: узел Node1, отправляющий регистрационный номер 1111, ожидает ответного пакета, включающего 1111. Эти действия совершаются между всеми узлами каждую секунду. Если узел Node1 не получает ответного пакета, он отправляет следующий по порядку регистрационный номер (1112), и т.д.
По умолчанию, если узел не получает пять контрольных сигналов в течение пяти секунд, WSFC устанавливает факт отказа узла. Активный узел в кластере отправляет пакет на узел, где установлен отказ, чтобы завершить работу службы кластера, и регистрирует событие 1135 в журнале событий системы (см. экран 7).
Экран 7. Событие 1135 в журнале событий системы |
Такое событие может быть вызвано несколькими причинами, многие из которых связаны с блокировкой связи через порт 3343:
1. Отказ сетевого оборудования.
2. Устаревший драйвер или устаревшая прошивка сетевого адаптера.
3. Сетевая задержка.
4. Протокол IPv6 разрешен на серверах, но параметры брандмауэра Windows выключают следующие разрешения для входящего и исходящего трафика:
- основы сетей – объявление поиска соседей;
- основы сетей – запрос поиска соседей.
5. Настройка коммутаторов, брандмауэров или маршрутизаторов не допускает прохождения трафика данных UDP-датаграмм.
6. Проблемы производительности (зависания, задержки и прочее).
7. Неправильно настроенные параметры буфера приема у драйвера сетевого адаптера.
Первым делом я всегда проверяю счетчик отброшенных принятых пакетов в составе объекта производительности сетевого интерфейса в окне системного монитора. Этот счетчик отслеживает число входящих пакетов, которые были отброшены, хотя и не было зафиксировано каких-либо ошибок, препятствующих их передаче протоколу верхнего уровня. Одна из возможных причин – необходимость освободить место в буфере.
Для добавления счетчика отброшенных принятых пакетов в окне системного монитора щелкните правой кнопкой на дисплее и выберите «Добавить счетчики». В открывшемся окне добавления счетчиков укажите нужный компьютер, выполните прокрутку и выберите счетчик «Отброшено принятых пакетов». В выпадающем списке «Экземпляры выбранного объекта» выберите нужный сетевой адаптер и нажмите «Добавить» (см. экран 8).
Добавив счетчик, проверьте его среднее, минимальное и максимальное значения. Если есть значения больше нуля, это указывает на необходимость настройки буфера приема для сетевого адаптера. Проконсультируйтесь с производителем сетевого адаптера по поводу рекомендуемых параметров. Может потребоваться перезагрузка.
В отказоустойчивом кластере Windows Server 2012 R2 можно воспользоваться мастером проверки конфигурации для выполнения проверки сетевого взаимодействия. Этот тест позволяет проверить возможность информационного обмена между узлами через порт 3343. Если есть проблемы связи, то будет выдана соответствующая ошибка с указанием возможной причины.
Причина
При использовании функции Move Group для ручного перемещения группы из одного узла в другой или при сбойе кластера для всей группы и для всех ресурсов группы будет создан список возможных владельцев. Поведение, описанное в разделе "Сводка" этой статьи, может возникать, если один из ресурсов в группе, которая не приходит в интернет, не имеет сетевого узла, перечисленного в списке Возможных владельцев.
Проблема 2
Вторую типичную проблему проще всего раскрыть с помощью сценариев. Опишем ее на примере двух различных конфигураций кластера: односайтовой и многосайтовой.
Односайтовый кластер. Предположим, что администратор решил изменить конфигурацию кластера, установив две сети между узлами Node1 и Node2. На узле Node1 он поменял IP-адреса и маски подсети сетевых адаптеров:
Кроме того, администратор поменял IP-адреса узла Node2 (192.168.0.2 и 10.10.10.2). При этом на узле Node1 в кластере он добавил группу файлового сервера, назначив ей IP-адрес 192.168.0.15.
Затем администратор протестировал кластер, чтобы убедиться в успешном переходе группы файлового сервера на узел Node2 при отработке отказа. Однако IP-адрес группы файлового сервера не виден в сети, то есть группа находится в автономном состоянии. В журнале событий системы регистрируется событие 1069, описание которого указывает на отказ ресурса с этим IP-адресом.
Причина отказа становится очевидной, если воспользоваться командой PowerShell Get-ClusterLog для вывода журнала кластера. Для этого достаточно ввести следующий набор символов:
Команда инициирует создание журнала кластера на каждом узле. Для построения журнала кластера только на одном узле можно добавить параметр -Node и указать имя узла. Можно также добавить параметр -TimeSpan для создания журнала только за последние x минут. Например, приведенная ниже команда предписывает построить журнал кластера на узле Node2 за последние 15 минут:
В результатах, представленных на экране 1, указано состояние «status 5035.».
Экран 1. Информация о состоянии 5035 в файле журнала кластера |
Создавая ресурс с IP-адресом, можно указать сеть, которая будет использоваться для него. Если эта сеть не будет существовать на узле, куда данный ресурс перейдет при отработке отказа, то WSFC не поменяет сеть, используемую ресурсом. В данном примере, при том IP-адресе, который указал администратор, и маске подсети, применяемой этим IP-адресом, группа файлового сервера сможет работать только по сети Cluster Network 1 (192.168.0.0/24).
Многосайтовый кластер. В случае многосайтового кластера каждый узел обычно имеет собственную сеть со своим IP-адресом. При первоначальном создании кластера и его ролей с помощью мастера создания ресурсов вам предлагается указать IP-адрес для сетей каждого из узлов, настроенных для клиентского доступа (см. экран 2).
Экран 2. Создание многосайтового кластера |
Мастер создания ресурсов, создавая IP-адреса и назначая имя сети, автоматически присваивает параметру зависимости этого имени сети значение «или». Это означает, что если один из IP-адресов в сети, имя также видно в сети. Создавая группы или ресурсы перед добавлением узлов из других сетей, необходимо вручную создавать эти вторичные IP-адреса и добавлять зависимость «или».
Дополнительная информация
Список возможных владельцев не полезен для кластера, который имеет менее трех узлов. Служба кластера создает список возможных владельцев для группы. Расположение группы, содержащей этот ресурс, зависит от изменения списка возможных владельцев для ресурса. Внутри страны сохраняется упорядоченный список для расположения, на котором расположена группа. Если вы удалите возможного владельца ресурса, удалите этот узел из списка возможных владельцев.
Эта статья помогает решить проблему, при которой физический дисковый ресурс не в сети на узле кластера.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 981475
Решение
Чтобы устранить эту проблему, выполните следующие действия:
Убедитесь, что эта проблема вызвана Symantec Endpoint Protection (SEP) 11.0 Обновление выпуска 5 (RU5). Для этого запустите Handle.exe сразу после возникновения проблемы на узле кластера, где физический дисковый ресурс не пришел в сеть.
В командной подсказке повышенного уровня введите следующую команду и нажмите КНОПКУ ВВОДА: Handle.exe -a -u drive_letter .
Местообладатель drive_letter — это обозначение диска для кластерного диска, который не пришел в сеть.
Например, предположим, что обозначение диска для кластерного диска, которое не было в сети, — это диск Q. Чтобы запустить Handle.exe в этом сценарии, введите следующую команду и нажмите кнопку ENTER: Handle.exe -a -u Q: .
Smc.exe pid: 856 NT AUTHORITY\SYSTEM 66C: Q:
Если проблема вызвана приложением Symantec, свяжитесь с Symantec, чтобы получить Symantec Endpoint Protection 11 Release Update 6 (RU6), который был выпущен для решения этой проблемы.
Ошибку легче предупредить
Как известно, предупредить ошибку легче, чем исправлять ее последствия. Поэтому в заключение повторю простое правило: регулярно актуализируйте состояние своих систем, применяя все обновления и исправления, касающиеся безопасности. Команда разработчиков отказоустойчивой кластеризации в Microsoft опубликовала материалы с перечнями исправлений, которые рекомендуется применить на всех кластерах. Каждой версии Windows посвящена отдельная публикация:
Материалы обновляются по мере необходимости, поэтому всегда актуальны. Замечу, что в них перечислены не все исправления, а лишь самые критичные для обеспечения стабильной работы и наиболее востребованные, исходя из числа обращений в службу поддержки Microsoft.
Листинг. Сценарий PowerShell для определения узлов с отсутствующим экземпляром Cluster WMI
Каналы событий
Каждый, вероятно, знаком с журналом системных событий, в котором регистрируются критически важные события, ошибки и предупреждения. Однако это не единственное место, где фиксируются события. Начиная с Server 2008, существуют еще и каналы событий. На экране 1 показано, как найти каналы, имеющие отношение к отказоустойчивой кластеризации. Именно здесь следует искать все информационные и отладочные/диагностические события. На схеме мы видим следующие журналы и их каналы:
* Diagnostic (если выбран пункт Show Analytic and Debug Logs («отобразить журналы анализа и отладки»))
* Performance-CSV (если выбран пункт Show Analytic and Debug Logs)
* Diagnostic (если выбран пункт Show Analytic and Debug Logs)
* Diagnostic (если выбран пункт Show Analytic and Debug Logs)
* Diagnostic (если выбран пункт Show Analytic and Debug Logs).
Экран 1. Каналы, относящиеся к?отказоустойчивой кластеризации |
События запуска/остановки службы кластеров, перемещения групп, перевода групп в онлайн/автономный режим и т.д. регистрируются в журнале FailoverClustering\Operational. Например:
-Идентификатор события: 1061
-Описание: служба кластеров успешно настроила отказоустойчивый кластер JohnsCluster.
Неудачные попытки установления соединения с другими узлами при открытии диспетчера отказоустойчивости кластеров регистрируются в журнале FailoverClustering-Manager\Admin. Например:
-Идентификатор события: 4684
В журнале FailoverClustering-Manager\Diagnostic можно увидеть следующее:
-Идентификатор события: 4609
-Идентификатор события: 4612
Именно по этим событиям можно установить проблему подключения узла к серверу DNS и затем приступить к ее устранению. Не просматривая указанные журналы, о наличии неполадок можно будет судить по тому, что в диспетчере отказоустойчивости кластеров узел W2K8 R2-NODE2 будет отображен как неисправный. Еще один журнал в числе упомянутых выше, Failover-Clustering\Diagnostic, мы обсудим несколько позже.
Проблема 1
Служба кластеров при запуске обнаруживает сети, в которые входит узел, и для каждой сети определяет сетевые адаптеры. Одна из типичных неполадок связана с тем, что отказоустойчивая кластеризация Windows Server (WSFC) допускает использование для одной сети только одного сетевого адаптера. Все прочие адаптеры этой сети игнорируются.
Предположим, что администратор настроил узел с двумя сетевыми адаптерами для одной сети:
Сетевой драйвер кластера (Netft.sys) для каждой сети будет использовать только один сетевой адаптер (или группу). Поэтому при данной конфигурации сеть кластера Cluster Network 1 (10.10.10.0/16) будет задействовать только сетевой адаптер Card1, тогда как сетевой адаптер Card2 будет игнорироваться, то есть не будет применяться для связи между узлами. Поскольку работает только одна сеть, при выходе Card1 из строя или утрате сетевого соединения узел не сможет взаимодействовать с другими узлами. Это единственная точка отказа. Чтобы избежать подобной ситуации, кластер следует настраивать так, чтобы между узлами существовало, как минимум, два сетевых пути. В этом случае при отказе одного из сетевых адаптеров связь между узлами будет осуществляться через другой сетевой адаптер.
Причина
Эта проблема, как известно, возникает при установке, обновлении или перенастройки антивирусного программного обеспечения, не известном кластеру. Например, эта проблема, как известно, возникает после установки или переноса в Symantec Endpoint Protection 11.0 Обновление выпуска 5 (RU5) на узлах кластера.
Система наблюдения за ресурсами
Теперь перейдем к системе наблюдения за ресурсами Resource Host System (RHS), одной из функций которой является отслеживание состояния всех ресурсов в кластере. Система выполняет серию проверок (базовых и полных). Если ресурс не реагирует на проверку, то RHS генерирует следующее системное событие:
-Идентификатор события: 1230
-Описание: ресурс кластера 'Cluster Disk 1' (resource type'', DLL 'clusres.dll') либо поврежден, либо заблокирован.
Если диск не отреагировал на проверку состояния, то кластер выводит данный ресурс из работы и перезапускает его для возврата в рабочий процесс. Если бы такие проверки не проводились, отказ ресурса мог бы привести к «зависанию» компьютера или невозможности подключения из клиентского приложения.
Проводя диагностику события RHS, необходимо проанализировать проблемный ресурс. Если диск заблокирован, следует проверить все содержимое стека диска. Возможно, причиной является медленный в/в диска, либо потерян путь к нему. Это должно быть ориентиром проводимой диагностики. На следующем этапе выполняется поиск относящихся к диску событий в системном журнале, анализ системного монитора, обновление драйверов и т.д. Если ресурсом является IP-адрес или сетевое имя, то в центре внимания должен быть сетевой стек и все его содержимое.
Читайте также: