Cluster failover manager: Что нового в Windows Server 2016 Failover Clustering / Блог компании Microsoft / Хабр

Что нового в Windows Server 2016 Failover Clustering / Блог компании Microsoft / Хабр

Автор статьи – Роман Левченко (www.rlevchenko.com), MVP – Cloud and Datacenter Management

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

Миграция кластера в прошлых версиях Windows Server является причиной значительного простоя из-за недоступности исходного кластера и создания нового на базе обновленной ОС на узлах с последующей миграцией ролей между кластерами. Такой процесс несет повышенные требования к квалификации персонала, определенные риски и неконтролируемые трудозатраты. Данный факт особенно касается CSP или других заказчиков, которые имеют ограничения по времени недоступности сервисов в рамках SLA. Не стоит описывать, что для поставщика ресурсов означает значительное нарушение SLA )

Windows Server 2016 ситуацию исправляет через возможность совмещения Windows Server 2012 R2 и Windows Server 2016 на узлах в рамках одного кластера во время его апгрейда (Cluster OS Rolling Upgrade (далее CRU)).

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

Определим сначала список «плюшек», которые CRU предоставляет:

• Полное отсутствие простоя при апгрейде кластеров WS2012R2 Hyper-V/SOFS. Для других кластерных ролей (к примеру, SQL Server) возможна их недоступность (менее 5 минут), необходимая для отработки разового failover.
• Нет необходимости в дополнительном аппаратном обеспечении. Как правило, кластер строится из учета возможной недоступности одного или нескольких узлов. В случае с CRU, недоступность узлов будет планируемой и поэтапной. Таким образом, если кластер может безболезненно пережить временное отстутствие хотя бы 1 из узлов, то для достижения zero-downtime дополнительных узлов не требуется. Если планируется апгрейд сразу нескольких узлов (это поддерживается), то необходимо заранее спланировать распределение нагрузки между доступными узлами.
• Создание нового кластера не требуется. CRU использует текущий CNO.
• Процесс перехода обратим (до момента повышения уровня кластера).
• Поддержка In-Place Upgrade. Но, стоит отметить, что рекомендуемым вариантом обновления узлов кластера является полноценная установка WS2016 без сохранения данных (clean-os install). В случае с In-Place Upgrade обязательна проверка полной функциональности после обновления каждого из узлов (журналы событий и т.д.).
• CRU полностью поддерживается VMM 2016 и может быть автоматизирован дополнительно через PowerShell/WMI.

Процесс CRU на примере 2-х узлового кластера Hyper-V:

1. Рекомендуется предварительное резервное копирование кластера (БД) и выполняемых ресурсов. Кластер должен быть в работоспособном состоянии, узлы доступны. При необходимости следует исправить имеющиеся проблемы перед миграцией и приостановить задачи резервного копирования перед стартом перехода.

2. Обновить узлы кластера Windows Server 2012 R2, используя Cluster Aware Updating (CAU) или вручную через WU/WSUS.
3. При имеющемся настроенном CAU необходимо временное его отключение для предотвращения его возможного воздействия на размещение ролей и состояния узлов во время перехода.

4. CPU на узлах должны иметь поддержку SLAT для поддержки выполнения виртуальных машин в рамках WS2016. Данное условие является обязательным.
5. На одном из узлов выполняем перенос ролей (drain roles) и исключение из кластера (evict):

6. После исключения узла из кластера выполняем рекомендуемую полную установку WS2016 (clean OS install, Custom: Install Windows only (advanced))

7. После переустановки верните сетевые параметры обратно*, обновите узел и установите необходимые роли и компоненты. В моем случае требуется наличие роли Hyper-V и, конечно, Failover Clustering.

   New-NetLbfoTeam -Name HV -TeamMembers tNIC1,tNIC2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic

   Add-WindowsFeature Hyper-V, Failover-Clustering -IncludeManagementTools -Restart

   New-VMSwitch -InterfaceAlias HV -Name VM -MinimumBandwidthMode Weight -AllowManagementOS 0

   * использование Switch Embedded Teaming возможно только после полного завершения перехода на WS2016.

8. Добавьте узел в соответствующий домен.

   Add-Computer -ComputerName HV01 -DomainName domain.com -DomainCredential domain\rlevchenko

9. Возвращаем узел в кластер. Кластер начнет работать в смешанном режиме поддержки функциональности WS2012R2 без поддержки новых возможностей WS2016. Рекомендуется завершить обновление оставшихся узлов в течение 4 недель.

10. Перемещаем кластерные роли обратно на узел HV01 для перераспределения нагрузки.
11. Повторяем шаги (4-9) для оставшейся ноды (HV02).
12. После обновления узлов до WS2016 необходимо поднять функциональный уровень (Mixed Mode – 8.0, Full – 9.0) кластера для завершения миграции.

    PS C:\Windows\system32> Update-ClusterFunctionalLevel

    Updating the functional level for cluster hvcl.
    
    Warning: You cannot undo this operation. Do you want to continue?
    
    [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is Y): a

    Name
    
    — Hvcl

13. (опционально и с осторожностью) Обновление версии конфигурации ВМ для включения новых возможностей Hyper-V. Требуется выключение ВМ и желателен предварительный бекап. Версия ВМ в 2012R2 – 5.0, в 2016 RTM – 8.0.В примере показана команда для обновления всех ВМ в кластере:

    Get-ClusterGroup|? {$_.GroupType -EQ "VirtualMachine"}|Get-VM|Update-VMVersion

    
    Перечень версий ВМ, поддерживаемые 2016 RTM:

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

В Windows Server 2016 для обеспечения возможности построения DR на базе Windows Server и для других сценариев доступна новая модель кворумной конфигурации на базе Cloud Witness.

Cloud Witness использует ресурсы Microsoft Azure (Azure Blob Storage, через HTTPS, порты на узлах должны быть доступны) для чтения/записи служебной информации, которая изменяется при смене статуса кластерных узлов. Наименование blob-файла производится в соответствии с уникальным идентификатором кластера, — поэтому один Storage Account можно предоставлять нескольким кластерам сразу (1 blob-файл на кластер в рамках создаваемого автоматически контейнера msft-cloud-witness). Требования к размеру облачного хранилища минимальны для обеспечения работы witness и не требует больших затрат на его поддержку. Так же размещение в Azure избавляет от необходимости третьего сайта при конфигурации Stretched Cluster и решения по его аварийному восстановлению.

Cloud Witness может применяться в следующих сценариях:

• Для обеспечения DR кластера, размещенного в разных сайтах (multi-site).
• Кластеры без общего хранилища (Exchange DAG, SQL Always-On и другие).
• Гостевые кластеры, выполняющиеся как в Azure, так и в on-premises.
• Кластеры хранения данных с или без общего хранилища (SOFS).
• Кластеры в рамках рабочей группы или разных доменах (новая функциональность WS2016).

Процесс создания и добавления Cloud Witness достаточно прост:

1. Создайте новый Azure Storage Account (Locally-redundant storage) и в свойствах аккаунта скопируйте один из ключей доступа.

2. Запустите мастер настройки кворумной конфигурации и выберите Select the Quorum Witness – Configure a Cloud Witness.

3. Введите имя созданного storage account и вставьте ключ доступа.

4. После успешного завершения мастера конфигурации, Witness появится в Core Resources.

5. Blob-файл в контейнере:

   Для упрощения можно использовать PowerShell:

В Windows Server 2012 R2 и предыдущих версиях необходимо соблюдение глобального требования перед созданием кластера: узлы должны быть членами одного и того же домена. Active Directory Detached кластер, презентованный в 2012 R2, имеет подобное требование и не упрощает его существенным образом.

В Windows Server 2016 возможно создание кластера без привязки к AD в рамках рабочей группы или между узлами, являющиеся членами разных доменов. Процесс схож с созданием deattached -кластера в 2012 R2, но имеет некоторые особенности:

• Поддерживается только в рамках среды WS2016.
• Требуется роль Failover Clustering.

  Install-WindowsFeature Failover-Clustering -IncludeManagementTools

• На каждом из узлов требуется создать пользователя с членством в группе Administrators или использовать built-in уч. запись. Пароль и наименование пользователя должны быть идентичны.

  net localgroup administrators cluadm /add

  
  При появлении ошибки “Requested Registry access is not allowed” необходимо изменить значение политики LocalAccountTokenFilterPolicy.

  New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1

• Primary DNS -suffix на узлах должен быть определен.

• Создание кластера поддерживается как через PowerShell, так и через GUI.

  New-Cluster -Name WGCL -Node rtm-1,rtm-2 -AdministrativeAccessPoint DNS  -StaticAddress 10.0.0.100

• В качестве Witness возможно использование только Disk Witness или описанный ранее Cloud Witness. File Share Witness, к сожалению, не поддерживается.

Поддерживаемые сценарии использования:

Динамическая оптимизация, доступная в VMM, частично перекочевала в Windows Server 2016 и предоставляет базовое распределение нагрузки на узлах в автоматическом режиме. Для перемещения ресурсов используется Live Migration и эвристики, на базе которых кластер каждые 30 минут решает проводить балансировку или нет:

1. Текущий % использования памяти на узле.
2. Средняя загрузка по CPU в 5 минутном интервале.

Предельные допустимые значения загрузки определяются значением AutoBalancerLevel:

get-cluster| fl *autobalancer*
AutoBalancerMode  : 2
AutoBalancerLevel : 1

Параметры балансировщика можно определить и в GUI (cluadmin.msc). По умолчанию, используется Low уровень агрессивности и режим постоянной балансировки.

Для проверки я использую следующие параметры:

AutoBalancerLevel: 2

(Get-Cluster).AutoBalancerLevel = 2

AutoBalancerMode: 2

(Get-Cluster).AutoBalancerMode = 2

Имитируем нагрузку сначала по CPU (около 88%) и затем по RAM (77%). Т.к. определен средний уровень агрессивности при принятии решения о балансировке и наши значения по загрузке выше определенного значения (70%) виртуальные машины на загруженном узле должны переехать на свободный узел. Скрипт ожидает момент живой миграции и выводит затраченное время (от точки начала загрузки на узла до осуществления миграции ВМ).

В случае с большой нагрузкой по CPU балансировщик переместил более 1 ВМ, при нагрузке RAM – 1 ВМ была перемещена в рамках обозначенного 30 минутного интервала, в течение которого происходит проверка загрузки узлов и перенос ВМ на другие узлы для достижения <=70% использования ресурсов.

При использовании VMM встроенная балансировка на узлах автоматически отключается и заменяется на более рекомендуемый механизм балансировки на базе Dynamic Optimization, который позволяет расширенно настроить режим и интервал выполнения оптимизации.

Изменение логики старта ВМ в рамках кластера в 2012 R2 строится на понятии приоритетов (low,medium,high), задача которых обеспечивать включение и доступность более важных ВМ перед запуском остальных «зависимых» ВМ. Обычно это требуется для multi-tier сервисов, построенных, к примеру, на базе Active Directory, SQL Server, IIS.

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

Для примера используем следующий сценарий:

1 ВМ Clu-VM02 является приложением, зависимым от доступности Active Directory, выполняемой на вирт. машине Clu-VM01. А ВМ Clu-VM03, в свою очередь, зависит от доступности приложения, расположенного на ВМ Clu-VM02.

Создадим новый set, используя PowerShell:

ВМ с Active Directory:
PS C:\> New-ClusterGroupSet -Name AD -Group Clu-VM01

Name: AD

GroupNames: {Clu-VM01}

ProviderNames: {}

StartupDelayTrigger: Delay

StartupCount: 4294967295

IsGlobal: False

StartupDelay: 20

Приложение:
New-ClusterGroupSet -Name Application -Group Clu-VM02

Зависимый сервис от приложения:
New-ClusterGroupSet -Name SubApp -Group Clu-VM03

Добавляем зависимости между set’ами:
Add-ClusterGroupSetDependency -Name Application -Provider AD

Add-ClusterGroupSetDependency -Name SubApp -Provider Application

В случае необходимости можно изменить параметры set’а, используя Set-ClusterGroupSet. Пример:

Set-ClusterGroupSet Application -StartupDelayTrigger Delay -StartupDelay 30

StartupDelayTrigger определяет действие, которое необходимо произвести после старта группы:

• Delay – ожидать 20 секунд (по умолчанию). Используется совместно с StartupDelay.
• Online – ожидать состояния доступности группы в set.

StartupDelay – время задержки в секундах. 20 секунд по умолчанию.

isGlobal – определяет необходимость запуска set’а перед стартом других наборов кластерных групп (к примеру, set с группами ВМ Active Directory должен быть глобально доступен и, следовательно, стартовать раньше других коллекций).

Попробуем стартовать ВМ Clu-VM03:

Происходит ожидание доступности Active Directory на Clu-VM01 (StartupDelayTrigger – Delay, StartupDelay – 20 секунд)

После запуска Active Directory происходит запуск зависимого приложения на Clu-VM02 (StartupDelay применяется и на этом этапе).

И последним шагом является запуск самой ВМ Clu-VM03.

В Windows Server 2016 появились новые режимы работы узлов и ВМ для повышения степени их устойчивости в сценариях проблемного взаимодействия между кластерными узлами и для предотвращения полной недоступности ресурсов за счет реакции на «малые» проблемы перед возникновением более глобальных (проактивное действие).

Режим изоляции (Isolated)

На узле HV01 внезапно стала недоступна служба кластеризации, т.е. у узла появляются проблемы интра-кластерного взаимодействия. При таком сценарии узел помещается в состояние Isolated (ResiliencyLevel) и временно исключается из кластера.

Виртуальные машины на изолированном узле продолжают выполняться* и переходят в статус Unmonitored (т.е. служба кластера не «заботится» о данных ВМ).

*При выполнении ВМ на SMB: статус Online и корректное выполнение (SMB не требует «кластерного удостоверения» для доступа). В случае с блочным типом хранилища ВМ уходят статус Paused Critical из-за недоступности Cluster Shared Volumes для изолированного узла.

Если узел в течение ResiliencyDefaultPeriod (по умолчанию 240 секунд) не вернет службу кластеризации в строй (в нашем случае), то он переместит узел в статус Down.

Режим карантина (Quarantined)

Предположим, что узел HV01 успешно вернул в рабочее состояние службу кластеризации, вышел из Isolated режим, но в течение часа ситуация повторилась 3 или более раза (QuarantineThreshold). При таком сценарии WSFC поместит узел в режим карантина (Quarantined) на дефолтные 2 часа (QuarantineDuration) и переместит ВМ данного узла на заведомо «здоровый».

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

Важно отметить, что в карантине одновременно могут находиться не более 25% узлов кластера.

Для кастомизации используйте вышеупомянутые параметры и cmdlet Get-Cluster:

(Get-Cluster). QuarantineDuration = 1800

Storage Resiliency

В предыдущих версиях Windows Server отработка недоступности r/w операций для вирт. диска (потеря соединения с хранилищем) примитивная – ВМ выключаются и требуется cold boot на последующем старте. В Windows Server 2016 при возникновении подобных проблем ВМ переходит в статус Paused-Critical (AutomaticCriticalErrorAction), предварительно «заморозив» своё рабочее состояние (её недоступность сохранится, но неожиданного выключения не будет).

При восстановлении подключения в течение таймаута (AutomaticCriticalErrorActionTimeout, 30 минут по умолчанию), ВМ выходит из paused-critical и становится доступной с той «точки», когда проблема была идентифицирована (аналогия – pause/play).

Если таймаут будет достигнут раньше возвращения хранилища в строй, то произойдет выключение ВМ (действие turn off)

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

Ранее нам советовали сторонние решения (много $) для создания полноценных распределенных кластеров (обеспечение SAN-to-SAN репликации). С появлением Windows Server 2016 сократить бюджет в разы и повысить унификацию при построении подобных систем становится действительностью.

Storage Replica позволяет осуществлять синхронную (!) и асинхронную репликацию между любыми системами хранения (включая Storage Spaces Direct) и поддерживающая любые рабочие нагрузки, — лежит основе multi-site кластеров или полноценного DR -решения. SR доступна только в редакции Datacenter и может применяться в следующих сценариях:

Использование SR в рамках распределенного кластера особенно ещё наличием автоматической отработки по отказу и тесной работы с site-awareness, который был презентован так же в Windows Server 2016. Site-Awarieness позволяет определять группы узлов кластера и привязывать их к физическому месторасположению (site fault domain/сайт) для формирования кастомных политик отказа (failover), размещения данных Storage Spaces Direct и логики распределения VM. Кроме того, возможна привязка не только на уровне сайтов, но и на более низкие уровни (node, rack, chassis).

New-ClusterFaultDomain –Name Voronezh –Type Site –Description “Primary” –Location “Voronezh DC”
New-ClusterFaultDomain –Name Voronezh3 –Type Site –Description “Secondary” –Location “Voronezh DC2”
New-ClusterFaultDomain -Name Rack1 -Type Rack 
New-ClusterFaultDomain -Name Rack2 -Type Rack
New-ClusterFaultDomain -Name HPc7000 -type Chassis
New-ClusterFaultDomain -Name HPc3000 -type Chassis
Set-ClusterFaultDomain –Name HV01 –Parent Rack1
Set-ClusterFaultDomain –Name HV02 –Parent Rack2
Set-ClusterFaultDomain Rack1,HPc7000 -parent Voronezh
Set-ClusterFaultDomain Rack2,HPc3000 -parent Voronezh3

Такой подход в рамках мульти-сайт кластера несет следующие плюсы:

• Отработка Failover первоначально происходит между узлами в рамках Fault домена. Если все узлы в Fault Domain недоступны, то только тогда переезд на другой.
• Draining Roles (миграция ролей при режиме обслуживания и т.д.) проверяет возможность переезда сначала на узел в рамках локального сайта и только потом перемещает их на иной.
• Балансировка CSV (перераспределение кластерных дисков между узлами) так же будет стремиться отрабатывать в рамках родного fault-домена/сайта.
• ВМ будут стараться располагаться в том же сайте, где и их зависимые CSV. Если CSV мигрируют на другой сайт, то ВМ через 1 минуту начнут свою миграцию на тот же сайт.

Дополнительно, используя логику site-awareness, возможно определение «родительского» сайта для всех вновь создаваемых ВМ/ролей:

(Get-Cluster).PreferredSite = <наименование сайта>

Или настроить более гранулярно для каждой кластерной группы:

(Get-ClusterGroup -Name  ИмяВМ).PreferredSite = <имя предпочтительного сайта>

• Поддержка Storage Spaces Direct и Storage QoS.
• Изменение размера shared vhdx для гостевых кластеров без простоя, поддержка Hyper-V репликации и рез. копирования на уровне хоста.
• Улучшенная производительность и масштабирование CSV Cache с поддержкой tiered spaces, storage spaces direct и дедупликации (отдать десятки ГбБ RAM под кеш – без проблем).
• Изменения в формировании журналов кластера (информация о временном поясе и т.д.) + active memory dump (новая альтернатива для full memory dump) для упрощения диагностирования проблем.
• Кластер теперь может использовать несколько интерфейсов в рамках одной и той же подсети. Конфигурировать разные подсети на адаптерах не требуется для их идентификации кластером. Добавление происходит автоматически.

На этом наш обзорный тур по новым функциям WSFC в рамках Windows Server 2016 завершен. Надеюсь, что материал получился полезным. Спасибо за чтение и комментарии.

Отличного всем дня!

Windows Server 2012: строим отказоустойчивый кластер с двумя узлами | Windows IT Pro/RE

В Windows Server 2012 появилось так много новшеств, что за всеми уследить трудно. Часть наиболее важных строительных блоков новой ИТ-инфраструктуры связана с улучшениями в отказоустойчивой кластеризации. Отказоустойчивая кластеризация зародилась как технология для защиты важнейших приложений, необходимых для производственной деятельности, таких как Microsoft SQL Server и Microsoft Exchange. Но впоследствии отказоустойчивая кластеризация превратилась в платформу высокой доступности для ряда служб и приложений Windows. Отказоустойчивая кластеризация — часть фундамента Dynamic Datacenter и таких технологий, как динамическая миграция. Благодаря Server 2012 и усовершенствованиям нового протокола Server Message Block (SMB) 3.0 область действия отказоустойчивой кластеризации стала увеличиваться, обеспечивая непрерывно доступные файловые ресурсы с общим доступом. Обзор функциональности отказоустойчивой кластеризации в Server 2012 приведен в опубликованной в этом же номере журнала статье «Новые возможности отказоустойчивой кластеризации Windows Server 2012».

.

Обязательные условия отказоустойчивой кластеризации

Для построения двухузлового отказоустойчивого кластера Server 2012 необходимы два компьютера, работающие с версиями Server 2012 Datacenter или Standard. Это могут быть физические компьютеры или виртуальные машины. Кластеры с виртуальными узлами можно построить с помощью Microsoft Hyper-V или VMware vSphere. В данной статье используются два физических сервера, но этапы настройки кластера для физических и виртуальных узлов одни и те же. Ключевая особенность заключается в том, что узлы должны быть настроены одинаково, чтобы резервный узел мог выполнять рабочие нагрузки в случае аварийного переключения или динамической миграции. Компоненты, использованные в тестовом отказоустойчивом кластере Server 2012 представлены на рисунке.

Для отказоустойчивого кластера Server 2012 необходимо общее хранилище данных типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В нашем примере используется iSCSI SAN. Следует помнить о следующих особенностях хранилищ этого типа.

• Каждый сервер должен располагать по крайней мере тремя сетевыми адаптерами: одним для подключения хранилища iSCSI, одним для связи с узлом кластера и одним для связи с внешней сетью. Если предполагается задействовать кластер для динамической миграции, то полезно иметь четвертый сетевой адаптер. Однако динамическую миграцию можно выполнить и через внешнее сетевое соединение — она просто будет выполняться медленнее. Если серверы используются для виртуализации на основе Hyper-V и консолидации серверов, то нужны дополнительные сетевые адаптеры для передачи сетевого трафика виртуальных машин.
• В быстрых сетях работать всегда лучше, поэтому быстродействие канала связи iSCSI должно быть не менее 1 ГГц.
• Цель iSCSI должна соответствовать спецификации iSCSI-3, в частности обеспечивать постоянное резервирование. Это обязательное требование динамической миграции. Оборудование почти всех поставщиков систем хранения данных соответствует стандарту iSCSI 3. Если нужно организовать кластер в лабораторной среде с небольшими затратами, обязательно убедитесь, что программное обеспечение цели iSCSI соответствует iSCSI 3 и требованиям постоянного резервирования. Старые версии Openfiler не поддерживают этот стандарт, в отличие от новой версии Openfiler с модулем Advanced iSCSI Target Plugin (http://www.openfiler.com/products/advanced-iscsi-plugin). Кроме того, бесплатная версия StarWind iSCSI SAN Free Edition компании StarWind Software (http://www.starwindsoftware.com/starwind-free) полностью совместима с Hyper-V и динамической миграцией. Некоторые версии Microsoft Windows Server также могут функционировать в качестве цели iSCSI, совместимой со стандартами iSCSI 3. В состав Server 2012 входит цель iSCSI. Windows Storage Server 2008 R2 поддерживает программное обеспечение цели iSCSI. Кроме того, можно загрузить программу Microsoft iSCSI Software Target 3.3 (http://www.microsoft.com/en-us/download/details.aspx?id=19867), которая работает с Windows Server 2008 R2.

Дополнительные сведения о настройке хранилища iSCSI для отказоустойчивого кластера приведены во врезке «Пример настройки хранилища iSCSI». Более подробно о требованиях к отказоустойчивой кластеризации рассказано в статье «Failover Clustering Hardware Requirements and Storage Options» (http://technet.microsoft.com/en-us/library/jj612869.aspx).

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

Первый шаг к созданию двухузлового отказоустойчивого кластера Server 2012 — добавление компонента отказоустойчивого кластера с использованием диспетчера сервера. Диспетчер сервера автоматически открывается при регистрации в Server 2012. Чтобы добавить компонент отказоустойчивого кластера, выберите Local Server («Локальный сервер») и прокрутите список вниз до раздела ROLES AND FEATURES. Из раскрывающегося списка TASKS выберите Add Roles and Features, как показано на экране 1. В результате будет запущен мастер добавления ролей и компонентов.

Первой после запуска мастера откроется страница приветствия Before you begin. Нажмите кнопку Next для перехода к странице выбора типа установки, на которой задается вопрос, нужно ли установить компонент на локальном компьютере или в службе Remote Desktop. Для данного примера выберите вариант Role-based or feature-based installation и нажмите кнопку Next.

На странице Select destination server выберите сервер, на котором следует установить функции отказоустойчивого кластера. В моем случае это локальный сервер с именем WS2012-N1. Выбрав локальный сервер, нажмите кнопку Next, чтобы перейти к странице Select server roles. В данном примере роль сервера не устанавливается, поэтому нажмите кнопку Next. Или можно щелкнуть ссылку Features в левом меню.

На странице Select features прокрутите список компонентов до пункта Failover Clustering. Щелкните в поле перед Failover Clustering и увидите диалоговое окно со списком различных компонентов, которые будут установлены как части этого компонента. Как показано на экране 2, по умолчанию мастер установит средства управления отказоустойчивыми кластерами и модуль отказоустойчивого кластера для Windows PowerShell. Нажмите кнопку Add Features, чтобы вернуться на страницу выбора компонентов. Щелкните Next.

На странице Confirm installation selections будет показана функция отказоустойчивого кластера наряду с инструментами управления и модулем PowerShell. С этой страницы можно вернуться и внести любые изменения. При нажатии кнопки Install начнется собственно установка компонентов. После завершения установки работа мастера будет завершена и функция отказоустойчивого кластера появится в разделе ROLES AND FEATURES диспетчера сервера. Этот процесс необходимо выполнить на обоих узлах.

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

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

Чтобы открыть диспетчер отказоустойчивого кластера, выберите параметр Failover Cluster Manager в меню Tools в диспетчере сервера. В области Management щелкните ссылку Validate Configuration, как показано на экране 3, чтобы запустить мастер проверки настроек.

Сначала выводится страница приветствия мастера. Нажмите кнопку Next, чтобы перейти к выбору серверов или странице Cluster. На этой странице введите имена узлов кластера, который необходимо проверить. Я указал WS2012-N1 и WS2012-N2. Нажмите кнопку Next, чтобы показать страницу Testing Options, на которой можно выбрать конкретные наборы тестов или запустить все тесты. По крайней мере в первый раз я рекомендую запустить все тесты. Нажмите кнопку Next, чтобы перейти на страницу подтверждения, на которой показаны выполняемые тесты. Нажмите кнопку Next, чтобы начать процесс тестирования кластера. В ходе тестирования проверяется версия операционной системы, настройки сети и хранилища всех узлов кластера. Сводка результатов отображается после завершения теста.

Если тесты проверки выполнены успешно, можно создать кластер. На экране 4 показан экран сводки для успешно проверенного кластера. Если при проверке обнаружены ошибки, то отчет будет отмечен желтым треугольником (предупреждения) или красным значком «X» в случае серьезных ошибок. С предупреждениями следует ознакомиться, но их можно игнорировать. Серьезные ошибки необходимо исправить перед созданием кластера.

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

На данном этапе можно создать кластер, начиная с любого узла кластера. Я организовал кластер, начав на первом узле (WS2012-N1).

Чтобы создать новый кластер, выберите ссылку Create Cluster на панели Management или панели Actions, как показано на экране 5.

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

На странице Access Point for Administering the Cluster следует указать имя и IP-адрес кластера, которые должны быть уникальными в сети. На экране 7 видно, что имя моего кластера WS2012-CL01, а IP-адрес — 192.168.100.200. При использовании Server 2012 IP-адрес кластера может быть назначен через DHCP, но я предпочитаю для своих серверов статически назначаемый IP-адрес.

После ввода имени и IP-адреса нажмите кнопку Next, чтобы увидеть страницу подтверждения (экран 8). На этой странице можно проверить настройки, сделанные при создании кластера. При необходимости можно вернуться и внести изменения.

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

Мастер создания кластера автоматически выбирает хранилище для кворума, но часто он выбирает не тот диск кворума, который хотелось бы администратору. Чтобы проверить, какой диск используется для кворума, откройте диспетчер отказоустойчивого кластера и разверните кластер. Затем откройте узел Storage и щелкните узел Disks. Диски, доступные в кластере, будут показаны на панели Disks. Диск, выбранный мастером для кворума кластера, будет указан в разделе Disk Witness in Quorum.

В данном примере для кворума был использован Cluster Disk 4. Его размер 520 Мбайт, чуть больше минимального значения для кворума 512 Мбайт. Если нужно использовать другой диск для кворума кластера, можно изменить настройки кластера, щелкнув правой кнопкой мыши имя кластера в диспетчере отказоустойчивого кластера, выбрав пункт More Actions и Configure Cluster Quorum Settings. В результате появится мастер выбора конфигурации кворума, с помощью которого можно изменить параметры кворума кластера.

Настройка общих томов кластера и роли виртуальных машин

Оба узла в моем кластере имеют роль Hyper-V, так как кластер предназначен для виртуальных машин с высокой доступностью, обеспечивающих динамическую миграцию. Чтобы упростить динамическую миграцию, далее требуется настроить общие тома кластера Cluster Shared Volumes (CSV). В отличие от Server 2008 R2, в Server 2012 общие тома кластера включены по умолчанию. Однако все же требуется указать, какое хранилище следует использовать для общих томов кластера. Чтобы включить CSV на доступном диске, разверните узел Storage и выберите узел Disks. Затем выберите диск кластера, который нужно использовать как CSV, и щелкните ссылку Add to Cluster Shared Volumes на панели Actions диспетчера отказоустойчивого кластера (экран 9). Поле Assigned To этого диска кластера изменится с Available Storage на Cluster Shared Volume (общий том кластера), как показано на экране 9.

В это время диспетчер отказоустойчивого кластера настраивает хранилище диска кластера для CSV, в частности добавляет точку подключения в системном диске. В данном примере общие тома кластера включаются как на Cluster Disk 1, так и на Cluster Disk 3 с добавлением следующих точек подключения:

* C:ClusterStorageVolume1
* C:ClusterStorageVolume2

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

Чтобы добавить новую роль, выберите имя кластера на панели навигации диспетчера отказоустойчивого кластера и щелкните ссылку Configure Roles на панели Actions, чтобы запустить мастер высокой готовности. Нажмите кнопку Next на странице приветствия, чтобы перейти на страницу выбора роли. Прокрутите список ролей, пока не увидите роль виртуальной машины, как показано на экране 10. Выберите роль и нажмите кнопку Next.

На странице выбора виртуальной машины будут перечислены все VM на всех узлах кластера, как показано на экране 11. Прокрутите список и выберите виртуальные машины, которым необходимо обеспечить высокую готовность. Нажмите кнопку Next. Подтвердив свой выбор, нажмите Next, чтобы добавить роли виртуальной машины в диспетчер отказоустойчивого кластера.

Пример настройки хранилища iSCSI

Для отказоустойчивого кластера Windows Server 2012 требуется общее хранилище, которое может быть типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В данном отказоустойчивом кластере используется Channel SAN.

Сначала в сети iSCSI SAN были созданы три логических устройства LUN. Один LUN был создан для диска кворума кластера (520 Мбайт). Другой LUN предназначен для 10 виртуальных машин и имеет размер 375 Гбайт. Третий LUN выделен для небольшой тестовой виртуальной машины. Все три LUN представлены в формате NTFS.

После того, как были созданы LUN, была выполнена настройка iSCSI Initiator на обоих узлах Server 2012. Чтобы добавить цели iSCSI, был выбран iSCSI Initiator в меню Tools в диспетчере сервера. На вкладке Discovery я нажал кнопку Discover Portal. В результате появилось диалоговое окно Discover Portal, куда были введены IP-адрес (192.168.0.1) и порт iSCSI (3260) сети SAN.

Затем я перешел на вкладку Targets и нажал кнопку Connect. В диалоговом окне Connect To Target («Подключение к целевому серверу») я ввел целевое имя iSCSI SAN. Оно было получено из свойств SAN. Имя зависит от поставщика SAN, имени домена и имен созданных LUN. Помимо целевого имени я установил режим Add this connection to the list of Favorite Targets.

По завершении настройки iSCSI эти LUN появились на вкладке Targets iSCSI Initiator. Чтобы автоматически подключать LUN при запуске Server 2012, я убедился, что они перечислены на вкладке Favorite Targets, как показано на экране A.

Наконец, были назначены буквенные обозначения устройствам LUN с помощью оснастки Disk Management консоли управления Microsoft (MMC). Я выбрал Q для диска кворума и W для диска, используемого для виртуальных машин и общих томов кластера (CSV). При назначении буквенных обозначений необходимо сначала назначить их на одном узле. Затем нужно перевести диски в автономный режим и сделать аналогичные назначения на втором узле. Результаты назначения букв дискам для одного узла приведены на экране B. При создании кластера диски будут показаны как доступное хранилище.

Windows Server 2012: строим отказоустойчивый кластер с двумя узлами

Поделитесь материалом с коллегами и друзьями

Решения для построения кластеров от Microsoft и Oracle — «Хакер»

Содержание статьи

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

Виды кластеров

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

• Кластеры высокой готовности или отказоустойчивые кластеры (high-availability clusters или failover clusters) используют избыточные узлы для обеспечения работы в случае отказа одного из узлов.
• Кластеры балансировки нагрузки (load-balancing clusters) служат для распределения запросов от клиентов по нескольким серверам, образующим кластер.
• Вычислительные кластеры (compute clusters), как следует из названия, используются в вычислительных целях, когда задачу можно разделить на несколько подзадач, каждая из которых может выполняться на отдельном узле. Отдельно выделяют высокопроизводительные кластеры (HPC — high performance computing clusters), которые составляют около 82% систем в рейтинге суперкомпьютеров Top500.

Системы распределенных вычислений (gird) иногда относят к отдельному типу кластеров, который может состоять из территориально разнесенных серверов с отличающимися операционными системами и аппаратной конфигурацией. В случае грид-вычислений взаимодействия между узлами происходят значительно реже, чем в вычислительных кластерах. В грид-системах могут быть объединены HPC-кластеры, обычные рабочие станции и другие устройства.

Такую систему можно рассматривать как обобщение понятия «кластер». ластеры могут быть сконфигурированы в режиме работы active/active, в этом случае все узлы обрабатывают запросы пользователей и ни один из них не простаивает в режиме ожидания, как это происходит в варианте active/passive.

Oracle RAC и Network Load Balancing являются примерами active/ active кластера. Failover Cluster в Windows Server служит примером active/passive кластера. Для организации active/active кластера требуются более изощренные механизмы, которые позволяют нескольким узлам обращаться к одному ресурсу и синхронизовать изменения между всеми узлами. Для организации кластера требуется, чтобы узлы были объединены в сеть, для чего наиболее часто используется либо традиционный Ethernet, либо InfiniBand.

Программные решения могут быть довольно чувствительны к задержкам — так, например, для Oracle RAC задержки не должны превышать 15 мс. В качестве технологий хранения могут выступать Fibre Channel, iSCSI или NFS файловые сервера. Однако оставим аппаратные технологии за рамками статьи и перейдем к рассмотрению решений на уровне операционной системы (на примере Windows Server 2008 R2) и технологиям, которые позволяют организовать кластер для конкретной базы данных (OracleDatabase 11g), но на любой поддерживаемой ОС.

Windows Clustering

У Microsoft существуют решения для реализации каждого из трех типов кластеров. В состав Windows Server 2008 R2 входят две технологии: Network Load Balancing (NLB) Cluster и Failover Cluster. Существует отдельная редакция Windows Server 2008 HPC Edition для организации высокопроизводительных вычислительных сред. Эта редакция лицензируется только для запуска HPC-приложений, то есть на таком сервере нельзя запускать базы данных, web- или почтовые сервера.

NLB-кластер используется для фильтрации и распределения TCP/IPтрафика между узлами. Такой тип кластера предназначен для работы с сетевыми приложениями — например, IIS, VPN или межсетевым экраном.

Могут возникать сложности с приложениями, которые полага ются на сессионные данные, при перенаправлении клиента на другой узел, на котором этих данных нет. В NLB-кластер можно включать до тридцати двух узлов на x64-редакциях, и до шестнадцати — на x86.

Failoverclustering — это кластеризации с переходом по отказу, хотя довольно часто термин переводят как «отказоустойчивые кластеры».

Узлы кластера объединены программно и физически с помощью LAN- или WAN-сети, для multi-site кластера в Windows Server 2008 убрано требование к общей задержке 500 мс, и добавлена возможность гибко настраивать heartbeat. В случае сбоя или планового отключения сервера кластеризованные ресурсы переносятся на другой узел. В Enterprise edition в кластер можно объединять до шестнадцати узлов, при этом пятнадцать из них будут простаивать до тех пор, пока не произойдет сбой. Приложения без поддержки кластеров (cluster-unaware) не взаимодействуют со службами кластера и могут быть переключены на другой узел только в случае аппаратного сбоя.

Приложения с поддержкой кластеров (cluster-aware), разработанные с использованием ClusterAPI, могут быть защищены от программных и аппаратных сбоев.

Развертывание failover-кластера

Процедуру установки кластера можно разделить на четыре этапа. На первом этапе необходимо сконфигурировать аппаратную часть, которая должна соответствовать The Microsoft Support Policy for Windows Server 2008 Failover Clusters. Все узлы кластера должны состоять из одинаковых или сходных компонентов. Все узлы кластера должны иметь доступ к хранилищу, созданному с использованием FibreChannel, iSCSI или Serial Attached SCSI. От хранилищ, работающих с Windows Server 2008, требуется поддержка persistent reservations.

На втором этапе на каждый узел требуется добавить компонент Failover Clustering — например, через Server Manager. Эту задачу можно выполнять с использованием учетной записи, обладающей административными правами на каждом узле. Серверы должны принадлежать к одному домену. Желательно, чтобы все узлы кластера были с одинаковой ролью, причем лучше использовать роль member server, так как роль domain controller чревата возможными проблемами с DNS и Exchange.

Третий не обязательный, но желательный этап заключается в проверке конфигурации. Проверка запускается через оснастку Failover Cluster Management. Если для проверки конфигурации указан только один узел, то часть проверок будет пропущена.

На четвертом этапе создается кластер. Для этого из Failover Cluster Management запускается мастер Create Cluster, в котором указываются серверы, включаемые в кластер, имя кластера и дополнительные настройки IP-адреса. Если серверы подключены к сетям, которые не будут использоваться для общения в рамках кластера (например, подключение только для обмена данными с хранилищем), то в свойствах этой сети в Failover Cluster Management необходимо установить параметр «Do not allow the cluster to use this network».

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

Для этого необходимо запустить High Availability Wizard, который можно найти в Services and Applications оснастки Failover Cluster Management.

Cluster Shared Volumes

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

Еще одна проблема, возникающая из-за того, что LUN является минимальной единицей обхода отказа, заключается в том, что при сбое одного приложения, находящегося на LUN, приходится переключать все приложения, которые хранятся на этом LUN, на другой сервер. Во всех приложениях (включая Hyper-V до второго релиза Server 2008) это удавалось обходить за счет многочисленных LUN, на каждом из которых хранились данные только одного приложения. В Server 2008 R2 появилось решение для этих проблем, но предназначенное для работы только с Hyper-V и CSV (Cluster Shared Volumes).

CSV позволяет размещать на общем хранилище виртуальные машины, запускаемые на разных узлах кластера — тем самым разбивается зависимость между ресурсами приложения (в данном случае виртуальными машинами) и дисковыми ресурсами. В качестве файловой системы CSV использует обычную NTFS. Для включения CSV необходимо в Failover Cluster Manage выполнить команду Enable Cluster Shared Volumes. Отключить поддержку CSV можно только через консоль:

Get-Cluster | %{$_.EnableSharedVolumes = "Disabled"}

Для использования этой команды должен быть загружен Failover Clusters, модуль PowerShell. Использование CSV совместно с live migration позволяет перемещать виртуальные машины между физическими серверами в считанные миллисекунды, без обрыва сетевых соединений и совершенно прозрачно для пользователей. Стоит отметить, что копировать любые данные (например, готовые виртуальные машины) на общие диски, использующие CSV, следует через узел-координатор.

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

Oracle RAC

Oracle Real Application Clusters (RAC) — это дополнительная опция Oracle Database, которая впервые появилась в Oracle Database 9i под названием OPS (Oracle Parallel Server). Опция предоставляет возможность нескольким экземплярам совместно обращаться к одной базе данных. Базой данных в Oracle Database называет ся совокупность файлов данных, журнальных файлов, файлов параметров и некоторых других типов файлов. Для того, чтобы пользовательские процессы могли получить доступ к этим данным, должен быть запущен экземпляр. Экземпляр (instance) в свою очередь состоит из структур памяти (SGA) и фоновых процессов. В отсутствии RAC получить доступ к базе данных может строго один экземпляр.

Опция RAC не поставляется с Enterprise Edition и приобретается отдельно. Стоит отметить, что при этом RAC идет в составе Standard Edition, но данная редакция обладает большим количеством ограничений по сравнению с Enterprise Edition, что ставит под сомнение целесообразность ее использования.

Oracle Grid Infrastructure

Для работы Oracle RAC требуется Oracle Clusterware (или стороннее ПО) для объединения серверов в кластер. Для более гибкого управления ресурсами узлы такого кластера могут быть организованы в пулы (с версии 11g R2 поддерживается два варианта управления — на основании политик для пулов или, в случае их отсутствия, администратором).

Во втором релизе 11g Oracle Clusterware был объединен с ASM под общим названием Oracle Grid Infrastructure, хотя оба компонента и продолжают устанавливаться по различным путям.

Automatic Storage Management (ASM) — менеджер томов и файловая система, которые могут работать как в кластере, так и с singleinstance базой данных. ASM разбивает файлы на ASM Allocation Unit.

Размер Allocation Unit определяется параметром AU_SIZE, который задается на уровне дисковой группы и составляет 1, 2, 4, 8, 16, 32 или 64 MB. Далее Allocation Units распределяются по ASM-дискам для балансировки нагрузки или зеркалирования. Избыточность может быть реализована, как средствами ASM, так и аппаратно.

ASM-диски могут быть объединены в Failure Group (то есть группу дисков, которые могут выйти из строя одновременно — например, диски, подсоединенные к одному контролеру), при этом зеркалирование осуществляется на диски, принадлежащие разным Failure Group. При добавлении или удалении дисков ASM автоматически осуществляет разбалансировку, скорость которой задается администратором.

На ASM могут помещаться только файлы, относящиеся к базе данных Oracle, такие как управляющие и журнальные файлы, файлы данных или резервные копии RMAN. Экземпляр базы данных не может взаимодействовать напрямую с файлами, которые размещены на ASM. Для обеспечения доступа к данным дисковая группа должна быть предварительно смонтирована локальным ASM-экземпляром.

Oracle рекомендует использовать ASM в качестве решения для управления хранением данных вместо традиционных менеджеров томов, файловых систем или RAW-устройств.

Развертывание Oracle RAC

Рассмотрим этапы установки различных компонентов, необходимых для функционирования Oracle RAC в режиме active/active кластера с двумя узлами. В качестве дистрибутива будем рассматривать последнюю на момент написания статьи версию Oracle Database 11g Release 2. В качестве операционной системы возьмем Oracle Enterprise Linux 5. Oracle Enterprise Linux — операционная система, базирующаяся на RedHat Enterprise Linux. Ее основные отличия — цена лицензии, техническая поддержка от Oracle и дополнительные пакеты, которые могут использоваться приложениями Oracle.

Подготовка ОС к установке Oracle стандартна и заключается в создании пользователей и групп, задании переменных окружения и параметров ядра. Параметры для конкретной версии ОС и БД можно найти в Installation Guide, который поставляется вместе с дистрибутивом.

На узлах должен быть настроен доступ к внешним общим дискам, на которых будут храниться файлы базы данных и файлы Oracle Clusterware. К последним относятся votingdisk (файл, определяющий участников кластера) и Oracle Cluster Registry (содержит конфигурационную информацию — например, какие экземпляры и сервисы запущены на конкретном узле). Рекомендуется создавать нечетное количество votingdisk. Для создания и настройки ASMдисков желательно использовать ASMLib, которую надо установить на всех узлах:

# rpm -Uvh oracleasm-support-2.1.3-1.el4.x86_64.rpm

Кроме интерфейса для взаимодействия с хранилищем на узлах желательно настроить три сети — Interconnect, External и Backup.
Необходимо настроить IP-адресацию (вручную или с использованием Oracl e GNS) и DNS для разрешения всех имен (или только GNS).

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

В конце нужно выполнить с правами root скрипты orainstRoot.sh и root.sh. Первым на всех узлах выполняется скрипт orainstRoot.sh, причем запуск на следующем узле осуществляется только после завершения работы скрипта на предыдущем. После выполнения orainstRoot.sh последовательно на каждом узле выполняется root.sh. Проверить успешность установки можно с помощью команды:

/u01/grid/bin/crsctl check cluster –all

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

Кроме active/active-кластера в версии 11g R2 существуют две возможности для создания active/passive-кластера. Одна из них — Oracle RACOneNode. Другой вариант не требует лицензии для RAC и реализуется средствами Oracle Clusterware. В этом случае вначале создается общее хранилище; затем устанавливается Grid Infrastructure, с использованием ASM_CRS и SCAN; а после этого на узлы устанавливается база данных в варианте Standalone. Далее создаются ресурсы и скрипты, которые позволяют запускать экземпляр на другом узле в случае недоступности первого.

Заключение

Oracle RAC совместно с Oracle Grid Infrastructure позволяют реализовать разнообразные сценарии построения кластеров. Гибкость настройки и широта возможностей компенсируются ценой такого решения.

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

Ссылки по теме

Поднимаем кластер на базе Windows Server 2008 R2

Прочитано:
2 173

Сейчас я подробно разберу все моменты по разворачиванию тестового кластера в системе Virtualbox с использование операционной системы WindowsServer 2008 R2 Enterprise, системы FreeNAS, которая будет выступать хранилищем с поднятым сервисом по предоставлению iSCSI сервиса столь необходимого по развёртыванию кластера.

Системные требования:

• Два сервера Windows Server 2008 R2 Enterprise введённые в домен
• Домен polygon.local
• Доменная учётная запись с правами Администратора
• Пять выделенных IP адрес
• Система FreeNAS установленная в VirtualBox

Произведённые работы

• Отключён энергосберегающий режим
• Часовой пояс GMT + 4
• Установлены все обновления через WSUS

Четыре сетевые карточки по две на каждую систему.

Login: ekzorchik (Учётная запись состоит в группе — Domain Admins)

Pass: Aa1234567

Cluster 1:

Eth0: 10.0.2.19 – внешняя сеть для домена polygon.local

Subnet Mask: 255.255.255.0

GateWay – 10.0.3.15

DNS: 10.0.2.15

Eth2: 192.168.117.2 – внутренняя сеть, т.е. cluster 1 смотрит на cluster 2 и никуда более.

Subnet Mask: 255.255.255.0  (255.255.255.252 на два адреса)

Шлюза и DNS нет.

Cluster 2:

Eth0: 10.0.2.21 — внешняя сеть для домена polygon.local

Subnet Mask: 255.255.255.0

GateWay – 10.0.3.15

DNS: 10.0.2.15

Eth2: 192.168.117.3 — внутренняя сеть, т.е. cluster 2 смотрит на cluster 1 и никуда более

Subnet Mask: 255.255.255.0

Шлюза и DNS нет.

Подготовим хосты Cluster1 и Cluster2 установив, в них компонент «FailoverClustering».

Настройки на хосте Cluster1

Запускаем оснастку для добавления компонента «Средство отказоустойчивости кластеров»

«Start» – «Control Panel» – «Administrative Tools» – «Server Manager» – «Features» и добавляем

Компонент «Failover Clustering»

Проходим через Next и Install и ожидаем, пока компонент установится.

Настройки на хосте Cluster2

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

Чтобы заработал кластер нам нужен общий диск подключённый к нашим системам Cluster1 и Cluster2 для этого задействуем встроенную оснастку «iSCSIInitiator». Как настроить подключение я уже расписывал, делаем согласно инструкции.

После переходим на систему Cluster1, далее открываем оснастку «Start» – «ControlPanel» – «AdministrativeTools» – «Server Manager» – «Storage» – «Disk Management» (Управление дисковой системой)

И обращаем внимание, что у нас появился подключённый через оснастку «iSCSIInitiator» диск:

Сейчас нужно его перевести в «Online» режим:

Создаём том (New Simple Volume…):

Нажимаем Next,

указываем размер тома в мегабайтах (я оставлю по умолчанию 2045), и присвоим букву для логического диска, к примеру «Q», укажем файловую систему (NTFS) и метку тома (к примеру «Quorum»).

Далее нужно зайти на второй узел Cluster2, также открыть оснастку «Start» – «Control Panel» – «Administrative Tools» – «Server Manager» – «Storage» – «Disk Management» (Управление дисковой системой) и по такому же принципу, как выше активируем диск, размечаем, но после переводим в состояние «Offline».

Подготовительная часть закончена.

Теперь можно перейти к объединению узлов Cluster1 и Cluster2 в кластер.

Данную процедуру выполняем только единожды

Для этого зайдём на первый хост Cluster1 и открываем оснастку «Failover Cluster Manager» для конфигурирования.

«Start» – «Control Panels» – «Administrative Tools» – «Failover Cluster Manager».

В появившейся оснастки следует запустить мастер проверки конфигурации – «Validatea Configuration…»

Сейчас, когда на обоих хостах установлен компонент, можно перейти к созданию кластера.

Нажимаем Next.

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

Вводим имя сервера, в моём случае Сluster1 и нажимаем Add (Добавить).

Нажимаем снова Next и на следующем шаге отмечаем пункт – «Run All Tests (recommended)» (Провести все тесты).

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

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

В моём случае все хорошо, проблем нет.

Обзываем кластер именем: service.polygon.local и IP адресом 10.0.2.39

Нажимаем

, указываем узлы из которых строим кластер, это Cluster1 & Cluster2, Указываем имя для него service.polygon.local, и адресом 10.0.2.39, см. скриншот ниже, что у Вас должно получиться:

Нажимаем Next

На этом все подготовительные шаги завершены, нажимаем Next, собственно и происходит установка. По окончании развернув оснастку «Failover Cluster Manager» видим имя кластера, ноды из которых он состоит и общий диск.

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

известных проблем: отказоустойчивая кластеризация Windows Server 2012 — статьи TechNet — США (английский)

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

) в Windows Server 2012.

.

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

1. Новое имя сервера отказоустойчивого кластера или роль высокой доступности не сразу появляется в диспетчере сервера при нажатии
   File and Storage Services , а затем щелкните Servers .Если вы щелкните правой кнопкой мыши один из узлов кластера, а затем щелкните
   Добавьте другие серверы из кластера в пул серверов , ничего не происходит.
2. Если затем щелкнуть Все серверы в диспетчере серверов, отобразится новое имя сервера кластера или роль высокой доступности. Тем не менее
   В столбце Управляемость отображается состояние Ошибка разрешения имени цели .
   

Причина:
Такое поведение наблюдается из-за задержек, связанных с репликацией системы доменных имен (DNS).Чтобы новый объект появился на странице «Серверы» в файловых службах и службах хранения, диспетчер сервера должен успешно завершить инвентаризацию. Для этого Сервер
Менеджер должен дождаться регистрации нового имени сервера и его разрешения в DNS. В зависимости от размера вашей среды это может занять некоторое время.

Разрешение:
Дождитесь завершения репликации DNS и состояния в столбце Управляемость на
Все серверы страница меняется на Онлайн .Когда диспетчер сервера может успешно разрешить имя сервера, имя кластера или роли высокой доступности автоматически появится на странице «Серверы» в службах файлов и хранилищ.

Совет Server Manager выполняет инвентаризацию каждые 10 минут. Если вы можете успешно пропинговать DNS-имя кластера или роль высокой доступности, вы можете нажать
Обновите , чтобы произвести немедленную инвентаризацию.

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

Причина:
Эта проблема возникает, если узел, переведенный в режим обслуживания, владеет IP-адресом кластера. Операция отмены не работает, когда кластер переносит IP-адрес кластера с одного узла на другой.

Временное решение:
Попробуйте снова выполнить операцию отмены. IP-адрес кластера отключен только в течение короткого периода времени.

Выпуск:
.
Когда обновление с учетом кластера (CAU) включено, функция CAU создает два ресурса (ресурс распределенного сетевого имени и ресурс ClusterAwareUpdatingResource).

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

• Remove-ClusterResource
• Remove-ClusterResourceType «ClusterAwareUpdatingResource»

Например, если вы запускаете командлеты Remove-CauClusterRole или
Add-CauClusterRole , появляется сообщение об ошибке:

Не удалось получить состояние ресурса «»: (Win32Exception) Ресурс кластера не найден.

Причина:
Удаление типа ресурса кластера CAU или экземпляра ресурса с помощью командлетов кластеризации не поддерживается. Поскольку ресурсы и тип ресурса удалены,
Командлеты Remove-CauClusterRole и Add-CauClusterRole не могут удалить или добавить роль кластера CAU, поскольку эти командлеты продолжают поиск удаленных ресурсов.

Разрешение:
Если вы случайно удалили ресурс CAU или тип ресурса для кластерной роли CAU с помощью командлетов кластеризации, выполните следующие действия, чтобы удалить все ссылки, чтобы можно было удалить или добавить роль CAU:

1. Запустите Windows PowerShell (от имени администратора).Проверьте параметры кластера с именами
   CauResourceName и CauVCOName . Для этого выполните следующую команду:

   Get-Cluster <имя кластера> | Get-ClusterParameter

   Если значения параметров существуют, запишите их.

2. Удалите объект виртуального компьютера (VCO) из доменных служб Active Directory. Имя VCO — это значение
   CauVCOName параметр, который вы определили на шаге 1.По умолчанию VCO находится в
   Computers контейнер в Active Directory — пользователи и компьютеры.
3. С помощью Windows PowerShell (от имени администратора) удалите параметры кластера с именами
   CauResourceName и CAUVCOName . Для этого выполните следующие команды:

Get-Cluster <имя кластера> | Set-ClusterParameter «CauResourceName» -Delete
Get-Cluster <Имя кластера> | Set-ClusterParameter «CauVCOName» -Delete

Совет Для удаления ресурса кластера CAU рекомендуется использовать командлет Remove-CauClusterRole.

Выпуск:
При попытке удалить кластерную роль обновления с учетом кластера (CAU) с помощью
Remove-CauClusterRole или мастер настройки параметров самообновления, удаление может завершиться неудачно с сообщением об ошибке, аналогичным следующему:

Не удалось удалить «имя объекта» учетной записи компьютера (также известной как объект виртуального компьютера или VCO) из домена .

Причина:
Эта проблема может возникнуть, если пользователь, удаляющий кластерную роль CAU, не имеет разрешения на удаление объекта виртуального компьютера (VCO).Это может включать администратора домена.

Временное решение:
В Active Directory — пользователи и компьютеры администратор домена должен вручную удалить VCO. Если вы не можете удалить VCO от имени администратора домена, убедитесь, что
Запретить запись управления доступом (ACE) не установлена ​​для группы, членом которой является администратор домена.

Совет Если вы не использовали предварительно подготовленный VCO при добавлении кластерной роли CAU, вы можете проверить имя VCO, выполнив команду Windows PowerShell.
Get-Cluster <имя кластера> | Get-ClusterParameter от имени администратора.В выводе проверьте значение
CauVCOName параметр.

Для просмотра разрешений для VCO в Active Directory Users and Computers на
Откройте меню , щелкните Расширенные функции . Когда вы просматриваете свойства VCO, щелкните
Безопасность таб. (По умолчанию VCO создается в контейнере Computers .)

Выпуск:
Если вы переименуете отказоустойчивый кластер, который настроен с кластерной ролью Cluster-Aware Updating (CAU), а затем попытаетесь использовать мастер настройки параметров самообновления для настройки параметров режима самообновления, вы можете получить сообщение об ошибке, подобное
на следующее:

[] Не удалось подключиться к удаленному серверу со следующим сообщением об ошибке: WinRM не может обработать запрос.При использовании проверки подлинности Kerberos произошла следующая ошибка: не удается найти компьютер <имя_кластера>. Подтвердите это
компьютер существует в сети и указанное имя написано правильно. Для получения дополнительной информации см. Раздел справки about_Remote_Troubleshooting.

Временное решение:
Чтобы обойти эту проблему, сделайте следующее:

1. Переименуйте объект Active Directory для кластера (учетную запись имени виртуальной сети отказоустойчивого кластера) со старого имени на новое с помощью командлета Windows PowerShell Rename-ADObject.Например, для отказоустойчивого кластера, переименованного из CLUSTEROLD
   в CLUSTERNEW выполните следующую команду от имени администратора, имеющего разрешения на изменение объектов Active Directory:

   Rename-ADObject -Identity «CN = CLUSTEROLD, CN = Computers, DC = Contoso, DC = com» –NewName «CLUSTERNEW»

2. Измените значение атрибута dnsHostName для объекта Active Directory на новое имя. Для этого в Active Directory — пользователи и компьютеры щелкните
   Просмотрите и убедитесь, что выбрано Расширенные функции .Найдите и щелкните правой кнопкой мыши недавно переименованный объект Active Directory, а затем щелкните
   Недвижимость . На вкладке редактора атрибутов найдите
   dnsHostName , а затем измените значение на новое имя отказоустойчивого кластера.
3. Перезапустите узлы кластера. Это гарантирует, что отказоустойчивый кластер и Active Directory синхронизируются, и обновляет значения для имени участника-службы в объекте Active Directory.

.

Как управлять отказоустойчивыми кластерами

Как управлять отказоустойчивыми кластерами?

Настройка ролей / функций на узлах для обеспечения высокой доступности

1. Диспетчер серверов → Добавить роли и функции.
2. На странице выбора типа установки выберите установку на основе ролей.
3. Выберите целевой сервер для этой роли.
4. В отображаемом списке ролей выберите Hyper-v. Отображается «Добавить функции, необходимые для окна Hyper-V».В этом окне отображаются зависимости, которые будут установлены. Щелкните Добавить функции.

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

6. Затем отображается окно Hyper-V.

7. Откроется окно «Создание виртуальных коммутаторов».В «Сетевые адаптеры» выберите сеть, которую виртуальная машина должна использовать для кластера. Если здесь указано несколько сетевых адаптеров, выберите подходящие.

8. Откроется окно миграции виртуальных машин. Выберите «Разрешить этому серверу отправлять» и «Получать живые миграции виртуальных машин». Это позволяет виртуальной машине при необходимости перемещаться между вашими узлами.

9. Отображается окно «Магазины по умолчанию». Не меняйте магазины по умолчанию.

10. Подтвердите выбор установки и нажмите «Установить».

Подключение к сетевым дискам iSCI

1. Запустите инициатор iSCI и подключитесь к двум вашим дискам SAN:
   • Нажмите Пуск → Инструменты администрирования Windows → Инициатор iSCI.
   • Убедитесь, что диски настроены на одновременное подключение. Это настроено на вашем SAN. Убедитесь, что вы предоставили доступ к двум серверам кластера.
2. Подключение к дискам SAN:
   • Откройте инициатор iSCI → вкладка Targets → введите IP-адрес для SAN.

   • Щелкните Quick Connect. Отображаются ваши диски.
   • Выделите диск, затем щелкните «Подключиться», чтобы подключиться к каждому диску.
   • Когда диск подключен, нажмите Готово.
   • Щелкните вкладку Тома и устройства.

   • Щелкните Автоматическая настройка → ОК. Когда вы подключитесь к первому компьютеру, нажмите Пуск → Инструменты администрирования WIndows → Управление компьютером → Управление дисками.

3. Вывести диски онлайн
   • Щелкните номер диска правой кнопкой мыши.
   • Выберите Online.
4. Повторите вышеуказанный шаг для второго привода.
5. Инициализируйте диски:
   • Щелкните правой кнопкой мыши номер диска рядом с одним из новых дисков.
   • Выберите «Инициализировать диск».
   • Убедитесь, что в появившемся поле рядом с обоими новыми дисками стоит галочка.
   • Установить как MBR.
   • Нажмите ОК.
6. Настройте новый привод:
   • Щелкните правой кнопкой мыши первый диск.

   • Выберите «Создать новый простой том».
   • Оставьте значения по умолчанию.
   • Выберите букву диска для назначения.
   • Обозначьте свои диски:
     • Диск емкостью 5 ГБ — обозначьте диск как Quorum

     .

     • 150 ГБ (диск большего размера) — обозначьте его как ClusterStorage
7. Повторите вышеуказанные шаги для второго привода.

Создать отказоустойчивый кластер

В ОС любого из узлов, созданных на вышеуказанных шагах, сделайте следующее:

1. Нажмите Пуск → Инструменты администрирования Windows → Диспетчер отказоустойчивого кластера, чтобы запустить диспетчер отказоустойчивого кластера. Нажмите «создать кластер». Нажмите Далее в окне «Перед тем, как начать».

2. В следующем окне введите имена серверов, которые вы хотите добавить в кластер. Кроме того, вы можете найти их через Обзор.Щелкните Добавить → далее.

3. Отображается окно с предупреждением о проверке. Выберите «Да», чтобы «разрешить проверку служб кластера».

4. При нажатии кнопки «Далее» отображается мастер проверки конфигурации. Продолжите, нажав Далее.
5. В окне параметров тестирования выберите «Запустить все тесты» (рекомендуется). В следующем окне вы сможете подтвердить список тестов, которые будут запускаться Windows.

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

7. Отображается окно «Точка доступа для администрирования кластера» в мастере создания кластера. В поле «Имя кластера» введите имя для своего кластера. В доступной сети укажите IP-адрес кластера.

8. После нажатия кнопки «Далее» отображается окно подтверждения. В этом окне перечислены настройки, которые будут применены к вашему новому кластеру.
   • Установите флажок «Добавить все подходящее хранилище в кластер». Теперь система попытается назначить любое хранилище, которое сможет найти. Система пытается создать новый кластер в вашем домене.
   • Это может занять некоторое время, так как во время настройки системы выполняется несколько проверок и тестов.
   • Когда процесс будет завершен, отобразится окно сводки, в котором будет указано, что мастер кластеров завершился успешно.

9. Убедитесь, что кластер настроен правильно
   • В диспетчере отказоустойчивого кластера перейдите к узлам.

   • Убедитесь, что все узлы в кластере находятся в сети. Если это не так, перейдите к серверу, который отключен, и переведите систему в оперативный режим, чтобы присоединиться к кластеру.
10. Перейдите в Хранилище → Диски.
    • а. Система обнаруживает диски SCSI и отображает их здесь.Если бы вы настраивали это только с двумя узлами, то кластер кворума 5 ГБ был бы назначен как диск-свидетель в кворуме. Настроенное пространство хранения назначается доступному хранилищу.

11. Настройте это хранилище как часть кластера.
    • Щелкните правой кнопкой мыши диск, назначенный доступному хранилищу; затем выберите «Добавить в общие тома кластера». Кластер теперь назначен на общий том кластера.

12. Проверьте папку Cluster Events на предмет проблем с кластером.Если проблем нет, вы можете настроить свою виртуальную машину в кластерной среде.

Изучите возможности аудита и отчетности Active Directory с помощью ADAudit Plus.

Аудит управления счетами

Аудит Active Directory

Аудит Windows Server

.

Hyper-V: развертывание отказоустойчивого кластера с помощью PowerShell — статьи TechNet — США (английский)

В этой статье мы обсудим, как развернуть отказоустойчивый кластер Hyper-V с нуля. В этой статье также рассматривается развертывание сервера iSCSI. Мы будем использовать PowerShell для всего развертывания.

1. Один контроллер домена с ролью DNS-сервера (IP: 192.168.1.2):
   Этот сервер является контроллером домена и DNS-сервером для дочерней структуры домена.com. Все остальные серверы входят в домен subhro.com.
2. Узел 1 Hyper V (IP: 192.168.1.3): Этот сервер действует как узел 1 кластера Hyper-V
3. Узел 2 Hyper V (IP: 192.168.1.4): Этот сервер действует как узел 2 кластера Hyper-V
4. Целевой сервер iSCI (IP: 192.168.1.10): Этот сервер действует как цель iSCSI для узла 1 и узла 2. Мы предоставим два LUN (диск-свидетель и общий том кластера) через эту цель iSCSI.

Обратите внимание

1. Все эти четыре сервера связаны через общую сеть.
2. Операционная система этих четырех серверов — Windows Server 2012 R2 datacenter Edition.
3. Имя кластера: HVCluster1.subhro.com
4. IP-адрес кластера: 192.168.1.12

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

Разделы с 1 по 6 посвящены созданию отказоустойчивого кластера Hyper-V, и мы будем использовать PowerShell для всей конфигурации.

Раздел 7 посвящен созданию виртуальной машины, и мы сделаем это в графическом режиме для простоты понимания.

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

Раздел 1. Установка ролей отказоустойчивого кластера и Hyper-V в узле 1 и узле 2.

Раздел 2: Установите роль iSCSI на сервере iSCSI и настройте ее как цель iSCSI.

Раздел 3: Создание виртуального коммутатора в Hyper-V.

Раздел 5: Создание нового кластера.

Раздел 6: Создание общего тома кластера (CSV).

Раздел 7. Создание высокодоступной виртуальной машины.

Раздел 8: Тестовое переключение виртуальной машины между двумя узлами.

Шаг 1. Установите роль отказоустойчивого кластера в узле 1 и узле 2

• Откройте PowerShell.
• Введите команду:

Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools

Роль отказоустойчивой кластеризации будет установлена ​​на узле 1.

Теперь выполните ту же команду на узле 2.

Шаг 2. Установите роль Hyper-V в узле 1 и узле 2

• Откройте PowerShell.
• Введите команду:

Install-WindowsFeature –Name Hyper-V -IncludeManagementTools –Restart

Итак, на данном этапе роли отказоустойчивого кластера и Hyper-V установлены в узле 1 и узле 2.

Шаг 1. Установка роли iSCSI

• Откройте PowerShell.
• Введите команду:

Add-WindowsFeature FS-iSCSITarget-Server

Шаг 2: Создайте LUN ​​(виртуальный диск), выполнив следующую команду в PowerShell

Новый-IscsiVirtualDisk c: \ Storage \ LUN1.VHDX — размер 1 ГБ

Шаг 3. Укажите инициаторам iSCSI, которым будет разрешено подключаться к этой цели iSCSI.

В этом случае нам нужно указать идентификаторы инициатора Node 1 и Node 2.

a) Войдите в узел 1 и откройте PowerShell.

b) Запустите службу «Microsoft iSCSI Initiator».

c) ​​Подать команду:

(Get-InitiatorPort) .NodeAddress

г) Вы получите идентификатор инициатора. Скопируйте и вставьте его в Блокнот для использования в будущем.

e) Теперь выполните шаги a-d на узле 2 и сохраните идентификатор инициатора в Блокноте.

ID инициатора узла 1: iqn.1991-05.com.microsoft:node1.subhro.com

ИД инициатора узла 2: iqn.1991-05.com.microsoft:node2.subhro.com

• После получения идентификатора инициатора войдите на сервер iSCSI и введите следующие команды в PowerShell:

New-IscsiServerTarget iSCSI-Subhro –InitiatorIds «IQN: iqn.1991-05.com.microsoft: node1.subhro.com», «IQN: iqn.1991-05.com.microsoft: node2.subhro. com «

Шаг 4. Назначьте вновь созданный LUN (файл VHD) цели iSCSI, чтобы он был доступен в цели.

Add-IscsiVirtualDiskTargetMapping iSCSI-Subhro c: \ Storage \ Lun1.VHDX

Итак, мы настроили цель iSCSI, связали LUN и разрешили узлу 1 и узлу 2 подключиться к цели iSCSI.

Шаг 5: войдите в систему на узле 1 и узле 2 и установите соединение.

Подключение к новой цели iSCSI — это двухэтапный процесс.

• Сначала создается целевой портал iSCSI с помощью командлета New-iSCSITargetPortal
• Затем устанавливается соединение с помощью командлета Connect-iSCSITarget .

Узел 1:

• New-iSCSITargetPortal –TargetPortalAddress iSCSI.subhro.com
• Get-iSCSITarget | fl
• Connect-iSCSITarget –NodeAddress iqn.1991-05.com.microsoft:iscsi-iscsi-subhro-target

После установления соединения между инициатором iSCSI (узел 1) и целью iSCSI, цель представит 1 ГБ LUN узлу 1. На узле 1 он появится как диск размером 1 ГБ в консоли управления дисками.

Мы должны перевести диск в оперативный режим, отформатировать диск и присвоить ему букву. В данном случае мы отформатировали диск и присвоили ему букву E.

На узле 2:

Теперь нам нужно создать виртуальный коммутатор Hyper-V как на узле 1, так и на узле 2. Этот виртуальный коммутатор предоставит высокодоступной виртуальной машине доступ к физической сети.

Приведенная ниже команда создаст виртуальный коммутатор с именем «VMExternalSwitch» в каждом узле и свяжет этот виртуальный коммутатор с адаптером Ethernet с именем «Public».

Коммутатор «AllowManagementOS 1» позволит управляющей ОС получить доступ к виртуальному коммутатору.

Узел 1

• Новый-VMSwitch «VMExternalSwitch» –NetAdapterName «Public» -AllowManagementOS 1

Узел 2

• Новый-VMSwitch «VMExternalSwitch» –NetAdapterName «Public» -AllowManagementOS 1

Как только вы закончите вышеуказанные шаги. Вы должны увидеть новый виртуальный коммутатор в консоли Hyper-V на обоих узлах.

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

Запустите эту команду с любого из узлов:

Тестовый кластер Node1, Node2

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

Шаг 1. Создайте кластер из узла 1

a) Войдите в систему на узле 1

б) Выполните следующую команду:

New-Cluster -Name HVCluster1 -Node node1 -StaticAddress 192.168.1.12 –IgnoreNetwork 172.16.1.0/16

Итак, кластер «HVCluster1» был создан, и в настоящее время Node1 является единственным узлом этого кластера.

Шаг 2: Добавьте узел 2 в кластер.

С узла 1 выполните следующую команду:

Add-ClusterNode -Name Node2

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

Шаг 3. Добавьте диск кворума (свидетеля) в кластер и измените модель кворума на «Большинство узлов и дисков».

После выполнения этих шагов настройка кластера завершена.

Шаг 1. Войдите на сервер iSCSI и выполните следующие операции

a) a) Создайте новый LUN с именем LUN 2 размером 10 ГБ.

b) b) Добавить LUN 2 в iSCSI Target

Шаг 2: Войдите в систему на узле 1 и узле 2 и убедитесь, что вновь созданный LUN виден с обоих узлов как диск 10 ГБ.

Шаг 3: Отформатируйте диск с узла 1 и укажите метку тома как «CSV1» (вы можете указать любую метку тома).

Шаг 4: Теперь выполните команду ниже из оболочки питания (узел 1)

• Get-ClusterAvailableDisk | Add-ClusterDisk
• Add-ClusterSharedVolume –Name «Cluster Disk 2»

Теперь отказоустойчивый кластер Hyper-V готов с общим томом кластера (CSV).Теперь создадим виртуальную машину, установим ОС и протестируем плановую и незапланированную отработку отказа.

Шаг 1. Запустите мастер создания новой виртуальной машины

1. В диспетчере отказоустойчивого кластера выберите или укажите нужный кластер. Убедитесь, что дерево консоли под кластером развернуто.
2. Щелкните «Роли».
3. На панели Действия щелкните Виртуальные машины , а затем щелкните
   Новая виртуальная машина . Появится мастер создания новой виртуальной машины.Нажмите
   След. .

Шаг 2: Укажите, какой узел будет владеть новой виртуальной машиной.

Шаг 3. Укажите имя и расположение новой виртуальной машины

Обратите внимание: файл VHDX виртуальной машины должен храниться в CSV, чтобы поддерживать переключение при отказе.

Шаг 4. Выберите создание виртуальной машины

Шаг 5: Назначить память

Шаг 6: Настройка сети

Шаг 7: Подключите виртуальный диск

Шаг 8: Выберите вариант установки и нажмите Готово.

После успешного выполнения всех вышеупомянутых шагов будет создана новая виртуальная машина.

Шаг 9: Установите гостевую ОС

Теперь отказоустойчивый кластер Hyper-V готов, и у нас есть тестовая виртуальная машина для проверки отказоустойчивости. Здесь мы выполним два типа аварийного переключения: плановое аварийное переключение и незапланированное аварийное переключение.

A. Планируемое восстановление после отказа

Чтобы протестировать запланированное аварийное переключение, мы переместим Test Vm на другой узел.В настоящее время TestVM принадлежит узлу 2, поэтому мы переместим его на узел 1.

Шаг 1. Войдите в систему на узле 1 или узле 2 с помощью открытого PowerShell

Шаг 2: Выполните следующую команду

Move-ClusterVirtualMachineRole -Name «TestVM» –Node Node1

Итак, виртуальная машина TestVM была успешно перемещена на узел 1.

Вы также можете выполнить то же самое графически, выполнив следующие шаги:

1.Откройте диспетчер отказоустойчивого кластера с узла 1 или узла 2.

2. Выберите «Роли»> «Выбрать виртуальную машину» и щелкните правой кнопкой мыши> «Переместить»> «Живая миграция».

3. Перенесите виртуальную машину на лучший из возможных узлов или любой конкретный узел.

B. Незапланированная отработка отказа

Чтобы проверить незапланированный отказ, остановите службу кластера на активном узле (где в настоящее время размещена тестовая виртуальная машина) и проверьте, будет ли TestVM мигрировать на другой узел.

1. Остановите службу кластеров на активном узле, на котором сейчас размещается тестовая виртуальная машина. В данном случае это Узел 1

Stop-ClusterNode –Name Node 1

.

Просмотр событий и журналов для отказоустойчивого кластера

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

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

Членство в локальной группе администраторов или аналогичной является минимумом, необходимым для выполнения этой процедуры.Подробные сведения об использовании соответствующих учетных записей и членстве в группах см. На странице https://go.microsoft.com/fwlink/?LinkId=83477.

1. В оснастке «Диспетчер отказоустойчивого кластера», если кластер не отображается, в дереве консоли справа- щелкните Failover Cluster Manager , щелкните Manage a Cluster , а затем выберите или укажите нужный кластер.

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

3. В дереве консоли щелкните правой кнопкой мыши Cluster Events , а затем щелкните Query .

4. В диалоговом окне Cluster Events Filter выберите критерии для событий, которые вы хотите отобразить.

   Чтобы вернуться к критериям по умолчанию, нажмите кнопку Сбросить .

5. Щелкните ОК .

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

7. Чтобы просмотреть конкретное событие, щелкните событие и просмотрите подробности на панели «Сведения о событии» .

Дополнительные соображения

• Чтобы открыть оснастку отказоустойчивого кластера, щелкните Пуск , щелкните Администрирование , а затем щелкните Диспетчер отказоустойчивого кластера .Если появится диалоговое окно Контроль учетных записей пользователей , убедитесь, что отображаемое действие соответствует вашему желанию, а затем щелкните Да .
• Вы также можете использовать средство просмотра событий, чтобы открыть журнал, связанный с отказоустойчивой кластеризацией. Чтобы найти журнал, в средстве просмотра событий разверните Журналы приложений и служб , разверните Microsoft , разверните Windows , а затем разверните FailoverClustering . Файл журнала хранится в каталоге systemroot \ system32 \ winevt \ Logs.

Дополнительные ссылки

.