Ошибка компьютер присоединен к кластеру

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

.

Проблема 1

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

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

Card1
IP Address: 10.10.10.1
Subnet Mask: 255.0.0.0
Card2
IP Address: 10.10.10.2
Subnet Mask: 255.0.0.0

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

Проблема 2

Вторую типичную проблему проще всего раскрыть с помощью сценариев. Опишем ее на примере двух различных конфигураций кластера: односайтовой и многосайтовой.

Односайтовый кластер. Предположим, что администратор решил изменить конфигурацию кластера, установив две сети между узлами Node1 и Node2. На узле Node1 он поменял IP-адреса и маски подсети сетевых адаптеров:

Card1
IP Address: 192.168.0.1 (Cluster Network 1)
Subnet Mask: 255.255.255.0
Card2
IP Address: 10.10.10.1 (Cluster Network 2)
Subnet Mask: 255.0.0.0

Кроме того, администратор поменял IP-адреса узла Node2 (192.168.0.2 и 10.10.10.2). При этом на узле Node1 в кластере он добавил группу файлового сервера, назначив ей IP-адрес 192.168.0.15.

Затем администратор протестировал кластер, чтобы убедиться в успешном переходе группы файлового сервера на узел Node2 при отработке отказа. Однако IP-адрес группы файлового сервера не виден в сети, то есть группа находится в автономном состоянии. В журнале событий системы регистрируется событие 1069, описание которого указывает на отказ ресурса с этим IP-адресом.

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

Get-ClusterLog

Команда инициирует создание журнала кластера на каждом узле. Для построения журнала кластера только на одном узле можно добавить параметр -Node и указать имя узла. Можно также добавить параметр -TimeSpan для создания журнала только за последние x минут. Например, приведенная ниже команда предписывает построить журнал кластера на узле Node2 за последние 15 минут:

Get-ClusterLog –Node Node2 –TimeSpan 15

В результатах, представленных на экране 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. Включены следующие права доступа:

• сетевой доступ (не разрешать перечисление учетных записей SAM анонимными пользователями);
• сетевой доступ (не разрешать перечисление учетных записей SAM и общих ресурсов анонимными пользователями).

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.

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

Set-Location C:WindowsSystem32Wbem
Mofcomp.exe Cluswmi.mof

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

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

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

• «Рекомендуемые исправления и обновления для отказоустойчивых кластеров на базе Windows Server 2012 R2» (support.microsoft.com/kb/2920151/EN-US);
• «Рекомендуемые исправления и обновления для отказоустойчивых кластеров на базе Windows Server 2012» (support.microsoft.com/kb/2784261/EN-US);
• «Рекомендуемые исправления и обновления для отказоустойчивых кластеров на базе Windows Server 2008 R2» (support.microsoft.com/kb/980054/EN-US).

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

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

$NodeNames = Get-ClusterNode
ForEach ($ClusterName in $NodeNames)
{
Write-Host -NoNewline «Testing $ClusterName»
Try
{
$result = (Get-WmiObject -Class «MSCluster_CLUSTER» `
-namespace «rootMSCluster» `
-authentication PacketPrivacy `
-computername $ClusterName -erroraction stop).__SERVER
Write-host «: Successfully queried cluster node»
}
Catch
{
Write-host -NoNewline «: Failed to query cluster node»
Write-host -ForegroundColor Red -BackgroundColor Black `
$_.Exception.Message
}
}

Создаю кластер на 2 нодах с сетевым хранилищем для дисков.
сеть доступа 1G 192.168.0.0/24
Сеть для дисков 10G 172.10.10.0/24
Создан OU для кластера, сервера перенесены в OU. Создан вручную computer : EKAT-CL и отключен.
Пытаюсь создать от domain admin.
Проверка кластера проходит успешно (кроме обновления, там отличаются немного версии обнов)

При попытке создать выдает ошибку:

Начало настройки кластера EKAT-CL.
Произошла ошибка при создании кластера. Узлы будут очищены. Пожалуйста, подождите...
Произошла ошибка при создании кластера. Узлы будут очищены. Пожалуйста, подождите...
Произошла ошибка при очистке узлов кластера. Воспользуйтесь командой Clear-ClusterNode, чтобы очистить узлы вручную.
Произошла ошибка при очистке узлов кластера. Воспользуйтесь командой Clear-ClusterNode, чтобы очистить узлы вручную.
Произошла ошибка при создании кластера.
Возникла ошибка при создании кластера "EKAT-CL".

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

Не могу понят в чем трабл.

Создан кластер Hyper-V на базе Windows Server 2012 R2 с единственным узлом и диском-свидетелем. После этого пытаемся добавить в кластер новый узел. В результате появляется ошибка:

Если смотреть отчёт (View Report), то видно что узел проходит первичную валидацию, а потом операция безуспешно завершается с сообщением о каким-то таймауте ожидания:

Adding KOM-AD01-VM07.holding.com to the cluster.
Validating cluster state on node KOM-AD01-VM07.
Getting current node membership of cluster KOM-AD01-VMFC01.
Adding node KOM-AD01-VM07 to Cluster configuration data.
Validating installation of the Network FT Driver on node KOM-AD01-VM07.
Validating installation of the Cluster Disk Driver on node KOM-AD01-VM07.
Configuring Cluster Service on node KOM-AD01-VM07.
Waiting for notification that Cluster service on node KOM-AD01-VM07.holding.com has started.
Waiting for notification that node KOM-AD01-VM07 is a fully functional member of the cluster.
Cluster service on node KOM-AD01-VM07 did not reach the running state. The error code is 0x5b4. For more information check the cluster log and the system event log from node KOM-AD01-VM07. This operation returned because the timeout period expired.
Unable to successfully cleanup.
The server 'KOM-AD01-VM07.holding.com' could not be added to the cluster.
An error occurred while adding node 'KOM-AD01-VM07.holding.com' to cluster 'KOM-AD01-VMFC01'.
This operation returned because the timeout period expired

Чтобы понять корень проблемы требуется дополнительная отладочная информация, получить которую помогут рекомендации из статьи Failover Clustering and Network Load Balancing Team Blog — How to Troubleshoot Create Cluster failures in Windows Server 2012. В частности, для получения лога компоненты кластеризации выполним на обоих серверах (на действующем узле кластера и добавляемом в кластер сервере) Powershell командлет выгружающий в текстовый файл этот самый лог:

Get-ClusterLog -Destination C: –UseLocalTime

В результате, по указанному пути появиться лог-файл с именем вида KOM-AD01-VM04_cluster.log

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

00000ad8.00001dd4::2014/10/29-20:14:55.154 WARN  mscs::ListenerWorker::operator (): (5060)' because of '[FTI][Initiator] Discarding connection from 10.160.35.58:~3343~ to 10.160.35.57:~3343~ (node KOM-AD01-VM07) because it uses a disabled network.'

В итоге выяснилось, что выключенная в кластере подсеть, относящаяся к Live Migration и стала причиной возникновения проблемы.

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

Другие материалы, которые могу оказаться полезными при разборе ситуаций с невозможностью добавления нового узла в кластер:

• SQLServerScribbles.COM — windows cluster freezes at “waiting for notification that node ‘‘ is a fully functional member of the cluster”
• Microsoft GTSC Romania — Enterprise Platforms Support Blog —  The case of the server who couldn’t join a cluster – operation returned because the timeout period expired
• TechNet Forum — Can’t add Hyper-V 2012R2 Node

Почему при установке кластера ms sql, служба кластеров windows не проходит проверку?

Для тренировки и самообучения провожу установку кластера 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 установлен на всех узлах кластера.
Вот куски из логов с ошибками:

Решение найдено. Дело в том. что при установке компонента «Отказоустойчивая кластеизация» с использованием графического интерфейса, ставятся только основные пакеты.

Однако, при просмотре данного компонента с консоли:
get-windowsfeature -name *clustering*
мы увидим что у него есть еще 2 пакета, которые не ставятся по умолчанию.

Установить их можно только с консоли.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Настраиваем отказоустойчивый кластер Hyper-V на базе Windows Server 2012

Настраиваем отказоустойчивый кластер Hyper-V на базе Windows Server 2012

Уже на этапе планирования будущей виртуальной инфраструктуры следует задуматься об обеспечении высокой доступности ваших виртуальных машин. Если в обычной ситуации временная недоступность одного из серверов еще может быть приемлема, то в случае остановки хоста Hyper-V недоступной окажется значительная часть инфраструктуры. В связи с чем резко вырастает сложность администрирования — остановить или перезагрузить хост в рабочее время практически невозможно, а в случае отказа оборудования или программного сбоя получим ЧП уровня предприятия.

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

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

В данном материале мы будем рассматривать наиболее простую конфигурацию отказоустойчивого кластера, состоящего из двух узлов (нод) SRV12R2-NODE1 и SRV12R2-NODE2, каждый из которых работает под управлением Windows Server 2012 R2. Обязательным условием для этих серверов является применение процессоров одного производителя, только Intel или только AMD, в противном случае миграция виртуальных машин между узлами будет невозможна. Каждый узел должен быть подключен к двум сетям: сети предприятия LAN и сети хранения данных SAN.

Вторым обязательным условием для создания кластера является наличие развернутой Active Directory, в нашей схеме она представлена контроллером домена SRV12R2-DC1.

Хранилище выполнено по технологии iSCSI и может быть реализовано на любой подходящей платформе, в данном случае это еще один сервер на Windows Server 2012 R2 — SRV12R2-STOR. Сервер хранилища может быть подключен к сети предприятия и являться членом домена, но это необязательное условие. Пропускная способность сети хранения данных должна быть не ниже 1 Гбит/с.

Будем считать, что на оба узла уже установлена операционная система, они введены в домен и сетевые подключения настроены. Откроем Мастер добавления ролей и компонентов и добавим роль Hyper-V.

Следующим шагом добавим компоненту Отказоустойчивая кластеризация.

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

Миграцию виртуальных машин оставляем выключенной.

Остальные параметры оставляем без изменения. Установка роли Hyper-V потребует перезагрузку, после чего аналогичным образом настраиваем второй узел.

Затем перейдем к серверу хранилища, как настроить iSCSI-хранилище на базе Windows Server 2012 мы рассказывали в данной статье, но это непринципиально, вы можете использовать любой сервер цели iSCSI. Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин. Диск-свидетель — это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.

Создайте новую цель iSCSI и разрешите доступ к ней двум инициаторам, в качестве которых будут выступать узлы кластера.

И сопоставьте данной цели созданные виртуальные диски.

Настроив хранилище, вернемся на один из узлов и подключим диски из хранилища. Помните, что если сервер хранилища подключен также к локальной сети, то при подключении к цели iSCSI укажите для доступа сеть хранения данных.

Подключенные диски инициализируем и форматируем.

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

После чего откроем Диспетчер Hyper-V и перейдем к настройке виртуальных коммутаторов. Их название на обоих узлах должно полностью совпадать.

Теперь у нас все готово к созданию кластера. Запустим оснастку Диспетчер отказоустойчивых кластеров и выберем действие Проверить конфигурацию.

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

Проверки занимают ощутимое время, при возникновении каких-либо ошибок их необходимо исправить и повторить проверку.

Если существенных ошибок не обнаружено работа мастера завершится и он предложит вам создать на выбранных узлах кластер.

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

При создании кластера для него создается виртуальный объект, обладающий сетевым именем и адресом. Укажем их в открывшемся Мастере создания кластеров.

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

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

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

Затем щелкнем правой кнопкой мыши на объекте кластера в дереве слева и выберем Дополнительные действия — Настроить параметры кворума в кластере.

Далее последовательно выбираем: Выбрать свидетель кворума — Настроить диск-свидетель и указываем созданный для этих целей диск.

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

Для того, чтобы диск мог использоваться сразу несколькими участниками кластера на нем создается CSVFS — реализуемая поверх NTFS кластерная файловая система, впервые появившаяся в Windows Server 2008 R2 и позволяющая использовать такие функции как Динамическая (Живая) миграция, т.е. передачу виртуальной машины между узлами кластера без остановки ее работы.

Общие хранилища становятся доступны на всех узлах кластера в расположении C:ClusterStorageVolumeN. Обратите внимание, что это не просто папки на системном диске, а точки монтирования общих томов кластера.

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

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

Чтобы создать виртуальную машину перейдите в раздел Роли в меню правой кнопки мыши выберите Виртуальные машины — Создать виртуальную машину, это же можно сделать и через панель Действия справа.

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

После выбора узла откроется стандартный Мастер создания виртуальной машины, работа с ним не представляет сложности, поэтому остановимся только на значимых моментах. В качестве расположения виртуальной машины обязательно укажите один из общих томов кластера C:ClusterStorageVolumeN.

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

После создания виртуальной машины перейдите в ее Параметры и в пункте Процессоры — Совместимость установите флажок Выполнить перенос на физический компьютер с другой версией процессора, это позволит выполнять миграцию между узлами с разными моделями процессоров одного производителя. Миграция с Intel на AMD или наоборот невозможна.

Затем перейдите в Сетевой адаптер — Аппаратное ускорение и убедитесь, что выбранные опции поддерживаются сетевыми картами всех узлов кластера или отключите их.

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

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

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

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

На этом настройка виртуальной машины закончена, можем запускать и работать с ней.

Теперь самое время проверить миграцию, для этого щелкните на машине правой кнопкой мыши и выберите Переместить — Динамическая миграция — Выбрать узел. Виртуалка должна переместиться на выбранную ноду не завершая работы.

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

Завершение работы приостанавливается до тех пор, пока не будут переданы все виртуальные машины.

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

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

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

Кластер Hyper-V не обеспечивает отказоустойчивости виртуальным машинам, отказ узла приводит к отказу всех размещенных на нем машин, но он позволяет обеспечить вашим службам высокую доступность, автоматически восстанавливая их работу и обеспечивая минимально возможное время простоя. Также он позволяет значительно облегчить администрирование виртуальной инфраструктуры позволяя перемещать виртуальные машины между узлами без прерывания их работы.

Источник