Узел кластера ошибка при установке sql

Для тренировки и самообучения провожу установку кластера ms sql 2008 r2 на кластер windows 2012 r2 (все это на виртуальных машинах).
Имеется следующее:
— 2 виртуальные машины на hyper-v;
— iscsi хранилища (кворум-диск, диск для базы данных, диск для службы распределенных транзакций). iscsi настроен на хост сервере;
— контроллер домена на хост машине;
— служба отказоусточивого кластера поднята на виртуалках и на хост-машине. Виртуалки объединены в кластер.
Проверка кластера, в дистпетчере отказоустойчивого кластера, проходит замечательно и не выдает никаких замечаний и ошибок.
При установке кластера ms sql на виртуалку, установщик запускает свои проверки, и находит следующие ошибки:
1. Cluster_IsOnline не пройдено (Службы кластера отработки отказа SQL Server находятся вне сети, или не удается получить доступ к кластеру с одного из его узлов)
2. Cluster_SharedDiskFacet не пройдено (Для кластера на этом компьютере не доступен ни один общий диск)
3. Cluster_VerifyForErrors не пройдено (Кластер не проверялся, либо в отчете проверки присутствуют сообщения об ошибках или сбоях)

На все сервера установлены последние обновления. Перезагружался много раз. Framework установлен на всех узлах кластера.
Вот куски из логов с ошибками:

2015-12-15 14:24:00 Slp: Initializing rule      : Проверка службы кластеров
2015-12-15 14:24:00 Slp: Rule applied features  : ALL
2015-12-15 14:24:00 Slp: Rule is will be executed  : True
2015-12-15 14:24:00 Slp: Init rule target object: Microsoft.SqlServer.Configuration.Cluster.Rules.ClusterServiceFacet
2015-12-15 14:24:00 Slp: Данный ключ отсутствует в словаре.
2015-12-15 14:24:00 Slp:    в Microsoft.SqlServer.Chainer.Infrastructure.ServiceContainer.GetService(Type serviceType)
   в Microsoft.SqlServer.Chainer.Infrastructure.ServiceContainer.GetService[T]()
   в Microsoft.SqlServer.Chainer.Infrastructure.ServiceContainer.get_Cluster()
   в Microsoft.SqlServer.Configuration.Cluster.Rules.ClusterServiceFacet.Microsoft.SqlServer.Configuration.RulesEngineExtension.IRuleInitialize.Init(String ruleId)
   в Microsoft.SqlServer.Configuration.RulesEngineExtension.RulesEngine.Execute(Boolean stopOnFailure)
2015-12-15 14:24:00 Slp: Rule initialization failed - hence the rule result is assigned as Failed

2015-12-15 14:24:01 Slp: Evaluating rule        : Cluster_SharedDiskFacet
2015-12-15 14:24:01 Slp: Rule running on machine: DELO-DB1
2015-12-15 14:24:01 Slp: Rule evaluation done   : Failed
2015-12-15 14:24:01 Slp: Rule evaluation message: Для кластера на этом компьютере не доступен ни один общий диск. Чтобы продолжить, необходимо сделать доступным по крайней мере один общий диск.

Как развернуть отказоустойчивый кластер MS SQL Server 2012 на Windows Server 2012R2 для новичков

Данный топик будет интересен новичкам. Бывалые гуру и все, кто уже знаком с этим вопросом, вряд ли найдут что-то новое и полезное. Всех остальных милости прошу под кат.

Задача, которая стоит перед нами, – обеспечить бесперебойную работу и высокую доступность базы данных в клиент-серверном варианте развертывания.
Тип конфигурации — active/passive.

P.S. Вопросы резервирования узлов не относящихся к MSSQL не рассмотрены.

Этап 1 — Подготовка

Технически можно обойтись 3 серверами совместив все необходимые роли на домен контроллере, но в полевых условиях так поступать не рекомендуется.

Вначале вводим в домен сервера WS2012R2C1 и WS2012R2C2; на каждом из них устанавливаем роль «Отказоустойчивая кластеризация».
После установки роли, запускаем оснастку «Диспетчер отказоустойчивости кластеров» и переходим в Мастер создания кластеров, где конфигурируем наш отказоустойчивый кластер: создаем Quorum (общий ресурс) и MSDTC(iSCSI).

Этап 2 – Установка MS SQL Server

Важно: все действия необходимо выполнять от имени пользователя с правом заведения новых машин в домен. (Спасибоminamoto за дополнение)
Для установки нам понадобится установочный дистрибутив MS SQL Server. Запусткаем мастер установки и выбераем вариант установки нового экземпляра кластера:

Далее вводим данные вашего лицензионного ключа:

Внимательно читаем и принимаем лицензионное соглашение:

Получаем доступные обновления:

Проходим проверку конфигурации (Warning MSCS пропускаем):

Выбираем вариант целевого назначения установки:

Выбираем компоненты, которые нам необходимы (для поставленной задачи достаточно основных):

Еще одна проверка установочной конфигурации:

Далее — важный этап, выбор сетевого имени для кластера MSSQL (instance ID – оставляем):

Проверка доступного пространства:

После чего — список доступных хранилищ, данных (сконфигурировано на этапе подготовки):

Выбираем диск для расположения баз данных кластера:

Конфигурацию сетевого интерфейса кластера рекомендуется указать адрес вручную:

Указываем данные администратора (можно завести отдельного пользователя для MSSQL):

Еще один важный этап – выбор порядка сортировки (Collation). После инсталляции изменить крайне проблематично:

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

Выбор директорий хранения общих файлов кластера (в версиях MS SQL Server 2012 и старше TempDB можно хранить на каждой ноде и не выносить в общее хранилище):

Наконец приступаем к установке (процесс может занять длительное время):

Настройка и установка базовой ноды закончена, о чем нам сообщает «зеленый» рапорт

Этап 3 – добавление второй ноды в кластер MSSQL

Дальше необходимо добавить в кластер вторую ноду, т.к. без нее об отказоустойчивости говорить не приходится.
Настройка и установка намного проще. На втором сервере (ВМ) запускаем мастер установки MS SQL Server:

Выбираем: в какой кластер добавлять ноду:

Просматриваем и принимаем сетевые настройки экземпляра кластера:

Указываем пользователя и пароль (те же, что и на первом этапе):

Снова тесты и процесс установки:

По завершению мы должны получить следующую картину:

Поздравляю, установка закончена.

Этап 4 – проверка работоспособности

Удостоверимся, что все работает как надо. Для этого перейдем в оснастку «Диспетчер отказоустойчивого кластера»:

На данный момент у нас используется вторая нода(WS2012R2C2) в случае сбоя произойдет переключение на первую ноду(WS2012R2C1).
Попробуем подключиться непосредственно к кластеру сервера MSSQL, для этого нам понадобится любой компьютер в доменной сети с установленной Management Studio MSSQL. При запуске указываем имя нашего кластера и пользователя (либо оставляем доменную авторизацию).

После подключения видим базы которые крутятся в кластере (на скриншоте присутствует отдельно добавленная база, после инсталляции присутствуют только системные).

Данный экземпляр отказоустойчивого кластера полностью готов к использованию с любыми базами данных, например, 1С(для нас ставилась задача развернуть такую конфигурацию для работы именно 1С-ки). Работа с ним ничем не отличается от обычной, но основная особенность — в надежности такого решения.

В тестовых целях рекомендую поиграть с отключением нод и посмотреть как происходит миграция базы между ними; проконтролировать важные для вас параметры, например, сколько по времени будет длиться переключение.
У нас при отказе одной из нод – происходит разрыв соединения с базой и переключение на вторую (время восстановления работоспособности: до минуты).
В полевых условиях для обеспечения надежности всей инфраструктуры необходимо обработать точки отказа: СХД, AD и DNS.

Источник

Локальный компьютер не входит в отказоустойчивый кластер windows

Есть отказоустойчивый кластер на двух нодах. Win 2012 R2.

В него добавлен коврум и два диска.

Тестирование кластера проходит без ошибок.

При перезагрузки любой из ноды все ресурсы успешно переезжают на рабочую ноду.

Но периодически одна из нод вываливается, именна та, на которой кворум подключен, и ресурсы автоматом не перезжают на рабочую ноду.

Более того, кластер перестаёт отвечать.

Естественно, получаю кучу ошибок (ниже все выложу).

Вопрос собственно в том, почему ресурсы автоматом не переезжают на рабочую ноду в случае выхода из стороя ноды с кворумом?

Что кроме тестирования кластера ещё можно попробовать?

Узел «хх2» лишен членства в активном отказоустойчивом кластере. Возможно, служба кластеров на этом узле была остановлена. Это также могло произойти из-за потери связи между данным узлом и другими активными узлами в отказоустойчивом кластере. Чтобы проверить параметры сети, запустите мастер проверки конфигурации. Если это не поможет, проверьте оборудование или программное обеспечение на наличие ошибок, связанных с сетевыми адаптерами на данном узле. Также проверьте работу других сетевых устройств, к которым подключен этот узел, таких как концентраторы, коммутаторы и мосты.

Этот узел неожиданно потерял владение диском кластера disk1. Для проверки конфигурации хранилища запустите мастер проверки конфигурации.

Сбой ресурса кластера «disk1» с типом «Physical Disk» в кластерной роли «ed».

В зависимости от политик на случай сбоя ресурса и роли служба кластеров может попытаться подключить ресурс на этом узле или же переместить группу на другой узел кластера, а затем перезапустить ее. Проверьте состояние ресурса и группы с помощью диспетчера отказоустойчивости кластеров или командлета Get-ClusterResource оболочки Windows PowerShell.

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

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

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

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

Источник

Диагностика отказоустойчивого кластера

Этот подраздел содержит следующие сведения:

основные шаги диагностики;

восстановление по журналу после сбоя отказоустойчивого кластера;

разрешение наиболее частых проблем отказоустойчивой кластеризации;

использование расширенных хранимых процедур и объектов COM.

Основные шаги диагностики

Первым шагом диагностики является проверка нового кластера. Дополнительные сведения о проверке см. в разделе Создание отказоустойчивого кластера: проверка конфигурации. Эту процедуру можно выполнить без нарушения работы службы, поскольку она не влияет на ресурсы кластера в сети. Проверку можно провести в любое время после установки функции отказоустойчивой кластеризации, включая момент перед развертыванием кластера, во время создания кластера и во время его работы. На самом деле дополнительные тесты выполняются после перевода кластера в рабочий режим и проверяют соблюдение рекомендаций для рабочих нагрузок с высоким уровнем доступности. Из множества тестов лишь немногие повлияют на функционирование рабочих нагрузок кластера. Все они входят в категорию хранилища, поэтому, пропустив эту категорию, можно легко отказаться от тестов с негативными последствиями.
Отказоустойчивая кластеризация располагает встроенными мерами защиты для предотвращения случайного времени простоев при выполнении тестов хранилища во время проверки. Если при инициации проверки в кластере имеются сетевые группы и выбраны тесты хранилища, будет выведен запрос на подтверждение необходимости запуска всех тестов (и возникновения простоя) или пропуска тестирования дисков сетевых групп, чтобы избежать простоя. Если из тестирования была исключена вся категория хранилища, этот запрос не отображается. Проверка кластера будет выполнена без простоев.

Повторная проверка кластера

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

Установка обновлений

Установка обновлений является важной частью предотвращения проблем в системе. Полезные ссылки

Восстановление по журналу после сбоя отказоустойчивого кластера

Обычно сбой отказоустойчивого кластера возникает в следующих случаях.

Сбой оборудования в одном из узлов двухузлового кластера. Такой сбой оборудования может быть вызван сбоем SCSI-контроллера или ОС.

Ошибка операционной системы. В этом случае данный узел отключен, но не является окончательно неисправным.

Для восстановления после сбоя ОС восстановите данный узел и проверьте отработку отказа. Если данный экземпляр SQL Server не переключается на другой ресурс должным образом, необходимо программой установки SQL Server удалить SQL Server из отказоустойчивого кластера, произвести необходимые восстановительные процедуры, восстановить резервную копию и снова добавить восстановленный узел к экземпляру отказоустойчивого кластера.

Восстановление по журналу после сбоя ОС может занять значительное время. Если восстановить ОС после сбоя можно более простым способом, не прибегайте к этому методу.

Разрешение общих проблем

В следующем списке приведено описание общих проблем и даны объяснения по их устранению.

Проблема. Неверное использование синтаксиса командной строки при установке SQL Server

Решение 1. Используйте параметр /qb вместо /qn. При использовании параметра /qb на каждом шаге отображается интерфейс пользователя, в том числе сообщения об ошибках.

Проблема. Серверу SQL Server не удается подключиться к сети после его перемещения на другой узел.

Причина 1. Учетные записи службы SQL Server не могут связаться с контроллером домена.

Решение 1. Проверьте журналы событий на наличие записей о проблемах сети, например о сбоях адаптеров или проблемах с DNS. Проверьте контроллер домена командой ping.

Причина 2. Пароли к учетным записям службы SQL Server отличаются на разных узлах кластера, или узел не перезапускает службу SQL Server, которая была перенесена с неисправного узла.

Решение 2. Измените пароли учетной записи службы SQL Server с помощью диспетчера конфигурации SQL Server. Если это не было сделано, а пароли учетной записи службы SQL Server изменены на одном узле, необходимо также изменить их на всех остальных узлах. SQL Server выполняет это автоматически.

Проблема. SQL Server не может получить доступ к дискам кластера.

Причина 1. Встроенное ПО или драйверы обновлены не на всех узлах.

Решение 1. Проверьте, установлены ли на всех узлах правильное встроенное ПО и одинаковые версии драйверов.

Причина 2. Узел не может восстановить диски кластера, перенесенные с неисправного узла на общий диск кластера с другой буквой диска.

Проблема. Сбой службы SQL Server вызывает отработку отказа.

Решение. Чтобы сбой определенных служб не вызывал перехода группы SQL Server на другой ресурс, настройте эти службы при помощи программы администрирования кластеров Windows следующим образом.

Проблема. SQL Server не запускается автоматически.

Проблема. Сетевой ресурс, к которому выполняется обращение по имени, находится не в сети, и нельзя подключиться к SQL Server по протоколу TCP/IP.

Причина 1. Сбой службы DNS, в то время как для ресурсов кластера настроено использование DNS.

Решение 1. Устраните проблемы с DNS.

Причина 2. Повторяющееся имя в сети.

Решение 2. С помощью программы NBSTAT найдите повторяющееся имя и устраните проблему.

Причина 3. Не удается соединиться с SQL Server с помощью именованных каналов.

Решение 3. Для подключения через именованные каналы создайте псевдоним с помощью диспетчера конфигурации SQL Server, чтобы подключиться к нужному компьютеру. Например, при использовании кластера с двумя узлами (Узел A и Узел B) и экземпляра отказоустойчивого кластера (Virtsql) с экземпляром по умолчанию подключиться к серверу, ресурс сетевого имени которого находится вне сети, можно, выполнив следующие шаги.

Запустите службу SQL Server на этом компьютере с помощью команды net start. Дополнительные сведения об использовании команды net start см. в разделе Запуск SQL Server вручную.

Запустите диспетчер конфигурации SQL Server на Узле A. Просмотрите именованный канал, по которому прослушивает этот сервер. Название будет иметь вид \.$$VIRTSQLpipesqlquery.

На клиентском компьютере запустите диспетчер конфигурации SQL Server.

Создайте псевдоним SQLTEST1 для соединения с этим каналом по протоколу именованных каналов. Для этого введите Узел A в качестве имени сервера и измените имя канала на \.pipe$$VIRTSQLsqlquery.

Подключитесь к экземпляру сервера с использованием псевдонима SQLTEST1 в качестве имени сервера.

Проблема. Программа установки SQL Server в кластере завершилась с кодом ошибки 11001.

Проблема. Потерян раздел реестра в ветке [HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSSQL.XCluster].

Решение. Убедитесь в том, что куст реестра MSSQL.X в настоящее время не используется, и удалите этот ключ кластера.

Проблема. Ошибка при установке кластера: «У установщика недостаточно привилегий для доступа к данному каталогу: Microsoft SQL Server. Невозможно продолжить установку. Войдите в систему как администратор или обратитесь к системному администратору»

Проблема. Эта ошибка произошла из-за неправильного разбиения на разделы общего диска SCSI.

Решение. Создайте повторно один раздел на этом общем диске, выполнив указанные ниже действия.

Удалите данный дисковый ресурс из кластера.

Удалите на этом диске все разделы.

Проверьте в свойствах диска, что он является основным.

Создайте на этом общем диске один раздел, отформатируйте диск и присвойте ему букву.

Добавьте этот диск к кластеру с помощью администратора кластеров (cluadmin).

Проблема. Приложениям не удается включить ресурсы SQL Server в список в распределенной транзакции.

Причина. Поскольку координатор распределенных транзакций Microsoft (MS DTC) настроен в Windows не полностью, то приложениям, возможно, не удастся прикрепить ресурсы SQL Server к распределенной транзакции. Эта проблема касается связанных серверов, распределенных запросов и удаленных хранимых процедур, использующих распределенные транзакции. Дополнительные сведения о настройке MS DTC см. в разделе Before Installing Failover Clustering.

Решение. Для предотвращения этой проблемы необходимо полностью включить службы MS DTC на серверах, на которых установлен SQL Server и настроен MS DTC.

Для полного включения служб MS DTC выполните следующие шаги.

На панели управления откройте Администрирование, затем Управление компьютером.

В левой панели окна «Управление компьютером» раскройте Службы и приложения и щелкните Службы.

В правой панели окна «Управление компьютером» щелкните правой кнопкой мыши Координатор распределенных транзакций и выберите Свойства.

В окне Координатор распределенных транзакций перейдите на вкладку Вход в систему и выберите в качестве учетной записи входа NT AUTHORITYNetworkService.

Использование расширенных хранимых процедур и объектов COM

При использовании расширенных хранимых процедур в конфигурациях с отказоустойчивой кластеризацией все такие процедуры должны быть установлены на диск кластера под управлением SQL Server. Это обеспечивает возможность использования расширенных хранимых процедур после перехода узла на другой ресурс.

Если эти расширенные хранимые процедуры используют компоненты COM, администратор должен зарегистрировать эти компоненты на каждом узле кластера. Чтобы компоненты COM можно было создать, сведения для их загрузки и выполнения должны содержаться в реестре активного узла. Иначе эти сведения содержатся в реестре компьютера, на котором эти компоненты COM были зарегистрированы в первый раз.

Источник

Шесть типичных проблем отказоустойчивых кластеров

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

Проблема 1

Служба кластеров при запуске обнаруживает сети, в которые входит узел, и для каждой сети определяет сетевые адаптеры. Одна из типичных неполадок связана с тем, что отказоустойчивая кластеризация Windows Server (WSFC) допускает использование для одной сети только одного сетевого адаптера. Все прочие адаптеры этой сети игнорируются.

Предположим, что администратор настроил узел с двумя сетевыми адаптерами для одной сети:

Сетевой драйвер кластера (Netft.sys) для каждой сети будет использовать только один сетевой адаптер (или группу). Поэтому при данной конфигурации сеть кластера Cluster Network 1 (10.10.10.0/16) будет задействовать только сетевой адаптер Card1, тогда как сетевой адаптер Card2 будет игнорироваться, то есть не будет применяться для связи между узлами. Поскольку работает только одна сеть, при выходе Card1 из строя или утрате сетевого соединения узел не сможет взаимодействовать с другими узлами. Это единственная точка отказа. Чтобы избежать подобной ситуации, кластер следует настраивать так, чтобы между узлами существовало, как минимум, два сетевых пути. В этом случае при отказе одного из сетевых адаптеров связь между узлами будет осуществляться через другой сетевой адаптер.

Проблема 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 для вывода журнала кластера. Для этого достаточно ввести следующий набор символов:

В результатах, представленных на экране 1, указано состояние «status 5035.».

Экран 1. Информация о состоянии 5035 в файле журнала кластера

Это сообщение об ошибке указывает на неработоспособное состояние сети кластера. Если администратор перейдет в диспетчер отказоустойчивости кластеров, то в разделе «Сети» он увидит, что сеть 192.168.0.0/24 содержит только один сетевой адаптер для узла Node1. Однако имеется новая сеть 192.0.0.0/8, обслуживаемая сетевым адаптером узла Node2. Администратор, поменяв IP-адрес сетевого адаптера на узле Node2, не поменял маску подсети. Таким образом, ошибка 5035 возникла из-за неверной настройки сетевого адаптера.

Создавая ресурс с IP-адресом, можно указать сеть, которая будет использоваться для него. Если эта сеть не будет существовать на узле, куда данный ресурс перейдет при отработке отказа, то WSFC не поменяет сеть, используемую ресурсом. В данном примере, при том IP-адресе, который указал администратор, и маске подсети, применяемой этим IP-адресом, группа файлового сервера сможет работать только по сети Cluster Network 1 (192.168.0.0/24).

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

Экран 2. Создание многосайтового кластера

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

Проблема 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. Включены следующие права доступа:

4. Ресурс имени кластера в состоянии сбоя.

Проблема 4

CNO и VCO – учетные записи компьютера и, подобно учетным записям пользователей, они имеют пароли, генерируемые AD случайным образом. По умолчанию политика домена предусматривает сброс пароля учетной записи компьютера каждые 60 дней.

СNO используется для таких операций, как добавление новых узлов к кластеру, создание новых объектов в домене и выполнение динамической миграции виртуальных машин с узла на узел. Для выполнения этих операций пароль CNO в домене должен быть актуальным. Для верности служба кластера делает попытку сброса паролей этих объектов по истечении половины срока (через 30 дней). Если пароль не сброшен на 60-дневной отметке, имя кластера не видно в сети.

Для сброса пароля необходимо выполнить восстановление в диспетчере отказоустойчивости кластеров. Как показано на экране 6, щелкните правой кнопкой имя проблемного ресурса и выберите «Дополнительные действия» и «Восстановить».

Экран 6. Сброс пароля вручную в диспетчере отказоустойчивости кластеров

При обращении к AD для сброса пароля диспетчер отказоустойчивости кластеров задействует учетную запись пользователя, под которой вы зарегистрировались в системе, поэтому вашей учетной записи должно быть предоставлено право на изменение пароля CNO; в противном случае восстановление не будет выполнено. Необходимо также убедиться, что включено разрешение на сброс пароля CNO и VCO, чтобы служба WSFC могла выполнять сброс при необходимости.

Проблема 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).

Экран 8. Добавление счетчика отброшенных принятых пакетов в системный монитор

Добавив счетчик, проверьте его среднее, минимальное и максимальное значения. Если есть значения больше нуля, это указывает на необходимость настройки буфера приема для сетевого адаптера. Проконсультируйтесь с производителем сетевого адаптера по поводу рекомендуемых параметров. Может потребоваться перезагрузка.

В отказоустойчивом кластере Windows Server 2012 R2 можно воспользоваться мастером проверки конфигурации для выполнения проверки сетевого взаимодействия. Этот тест позволяет проверить возможность информационного обмена между узлами через порт 3343. Если есть проблемы связи, то будет выдана соответствующая ошибка с указанием возможной причины.

Проблема 6

Иногда диспетчер отказоустойчивости кластеров не открывается, выдавая сообщение об ошибке (см. экран 9). В процессе открытия диспетчер отказоустойчивости кластеров устанавливает WMI-соединение с каждым узлом кластера. Сообщение об ошибке, приведенное на экране 9, указывает на то, что один из узлов имеет недопустимое пространство имен, то есть с узла был удален экземпляр Cluster WMI (Cluswmi.mof). Остается выяснить, на котором из узлов он удален, поскольку в сообщении об ошибке эта информация отсутствует.

Экран 9. Сообщение о недопустимом пространстве имен

В листинге приведен сценарий Windows PowerShell, позволяющий выявить узел, утративший экземпляр Cluster WMI.

Установив проблемный узел, можно ввести команду

Наиболее распространенной причиной утраты Cluswmi.mof узлом является устаревший способ решения проблем WMI. Для устранения неполадок WMI администраторы обычно используют команду Mofcomp.exe *.mof, позволяющую скомпилировать все файлы Managed Object Format (MOF) в репозиторий WMI. Однако дело в том, что существует довольно много файлов удаления для различных ролей и компонентов Windows, включая Cluster WMI. Поэтому файл Cluswmi.mof, устанавливаемый с помощью этой команды, впоследствии удаляется. Правильный способ восстановления репозитория WMI – с использованием команды Winmgmt.exe.

Ошибку легче предупредить

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

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

Листинг. Сценарий PowerShell для определения узлов с отсутствующим экземпляром Cluster WMI

Источник