Windows

Windows server 2019 failover clustering: 404 — Содержимое не найдено

29.07.2003

Содержание

netberg | Главная

В данной статье речь пойдет о подготовке и конфигурации отказоустойчивого кластера (Failover Cluster) на базе сервера Netberg Demos R420 M2. Программно-аппаратный комплекс Netberg Demos R420 M2 специально сконструирован для построения решений класса «кластер-в-коробке» (Cluster-in-a-box) на основе Microsoft Windows Server 2012.

Аналогичную процедуру можно применять и к кластерам с внешними устройствами хранения. Например для дисковых полок Aeon J424 M3 и Aeon J470 M3, используемых совместно со стандартными серверами.

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

Каждый узел сервера имеет доступ к общему дисковому хранилищу, которое позволяет разместить до 12 дисков. Для установки операционной системы используются внутренние посадочные места для 2.5” SATA/SSD дисков.

Диски в сервере подключены одновреммено к двум узлам системы с использованием дублированной системы ввода/вывода Multipath I/O, таким образом, в диспетчере устройств будет отображаться удвоенное

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

Рис. 1. Диспетчер устройств без настроенного MPIO

Для настройки Multipath I/O запустите мастер установки ролей и компонентов и установите компоненту Multipath I/O.

 

Рис. 2. Добавление компоненты MPIO

На рабочем столе откройте ярлык MPIO. На вкладке Discover Multi-Paths установите галку Add support for SAS devices и нажмите Add. Перезагрузите сервер.

Рис. 3. Свойства MPIO

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

Рис. 4. Диспетчер устройств с настроенным MPIO

Данную процедуру необходимо выполнить на двух узлах.

Инициализация дисков

После этого необходимо сделать сброс каждого диска (Reset Disk) для того чтобы удалить все данные и метаинформацию, которые могут там содержаться. Сделать инициализацию (Initialize) дисков и после этого перевести диски в Offline. Инициализацию достаточно сделать на одном из узлов сервера. Данные операции доступны в оснастке Server Manager — File and Storage Services — Volumes — Disks.

Рис. 5. Управление дисками в консоли Server Manager

Подготовка сетевых интерфейсов

В настройках интерфейса для подключения к локальной сети рекомендуется задать статические IP-адреса. Информация об IP-адресах и именах узлов кластера обязательно должна содержаться в прямой и обратной зоне DNS сервера. Убедитесь в работоспособности прямого и обратного разрешения имен. Для настройки сети между узлами кластера в Netberg Demos R420 M2 используется внутренний сетевой интерфейс Intel® I350 Gigabit

Backplane Connection, в настройках которого вы можете выставить свою конфигурацию протокола TCP/IPv4. Неиспользуемые сетевые адаптеры рекомендуется поставить в состояние Disabled.

Рис. 6. Network Connections

Установка и настройка компоненты Failover Cluster

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

Рис. 7. Добавление компоненты Failover Cluster

Проверка конфигурации узлов кластера

Прежде чем приступить к настройке кластера необходимо выполнить проверку конфигурации узлов кластера. Для этого в Failover Cluster Manager запустим мастер проверки конфигурации (Validate a Configuration Wizard).

Рис. 8. Запуск мастера проверки конфигурации

Для корректной работы кластера важно успешное прохождение всех тестов.

На шаге Select Servers or a Cluster укажите имена узлов кластера, которые, как было сказано выше, должны являться членами домена Active Directory.

Рис. 9. Select Servers or a Cluster

На шаге Testing Options выберем прохождение всех тестов(Run all tests).

Рис. 10. Testing Options

По завершении работы Validate a Configuration Wizard откроется окно с результатами проверки. Нажав View Report можно ознакомиться с детальной информацией о пройденных тестах.

Note

Не переходите к следующим шагам, пока в мастере проверки кластера не будут пройдены АБСОЛЮТНО все тесты.

Рис. 11. Summary

Установка кластера

Теперь можно приступить к установке кластера. Для этого в Failover Cluster Manager запустим Create Cluster Wizard.

На шаге Select Servers укажите имена узлов кластера.

Рис. 12. Select Servers

На следующем шаге введите имя кластера и его IP- адрес.

Рис. 13. Access Point for Administering the Cluster

На шаге Confirmation снимем галку Add all eligible storage to the cluster. Диски настроим позже с использованием новой компоненты Storage Spaces, которая стала доступна в Windows 2012.

Рис. 14. Confirmation

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

Рис. 15. Summary

В результате работы мастера будет создан объект Active Directory с именем CLUSTER1. Объект будет располагаться в том же контейнере, где и узлы кластера, в нашем случае в контейнере Experiment.

Рис. 16. Контейнер Active Directory

Далее необходимо дать разрешение на создание объектов в контейнере Experiment для компьютера CLUSTER1. Это будет необходимо для успешного добавления роли кластера.

Рис. 17. Свойства контейнера Experiment

Настройка дисков для кластера

Приступим к настройке общего дискового ресурса для узлов кластера с использованием компоненты Storage Spaces. Подробно о настройке Storage Spaces.

Как видно следующем на рисунке, было добавлено 2 виртуальных диска quorum и file-storage.

Рис. 18. Storage Pols в консоли Server Manager

Диск quorum настроим в качестве диска кворума для кластера, диск file-storage – для хранения данных.

Добавим вновь созданные диски в кластер. Для этого в Failover Cluster Manager в правой панели правой кнопкой мыши выберите Disks и нажмите Add Disk.

Рис. 19. Добавление диска в кластер

Для настройки диска кворума в Failover Cluster Manager нажмите правой кнопкой на имени кластера и выберете меню More Actions – Configure Cluster Quorum Settings.

Рис. 20. Установка диска кворума в консоли Failover Cluster Manager

Далее запуститься мастер настройки диска кворума.

На шаге Select Quorum Configuration Option используем рекомендуемые параметры.

Рис. 21. Quorum Configuration Option

На шаге Confirmation подтверждаем конфигурацию.

Рис. 22. Confirmation

На последнем шаге можно ознакомиться с детальным отчетом.

Рис. 23. Summary

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

Добавим роль файлового сервера для кластера. В Failover Cluster Manager нажмите правой кнопкой на имени кластера и выберите пункт Configure Role.

На шаге Select Role выберем File Server.

Рис. 24. Select Role

На следующем шаге предлагается выбрать тип файлового сервера. Выберем File Server for general use.

Рис. 25. File Server Type

На шаге Client Access Point необходимо ввести имя и IP-адрес для доступа клиентов к файловому серверу.

Рис. 26. Client Access Point Type

Далее выберем диск для данных файлового сервера. В нашем случае доступен Cluster Disk 2.

Рис. 27. Select Storage Point Type

Подтверждаем конфигурацию.

Рис. 28. Confirmation

На последнем шаге можно ознакомиться с детальным отчетом.

Рис. 29. Summary

В результате работы мастера будет создан объект Active Directory с именем FILESTORAGE. Объект будет располагаться в том же контейнере, где и узлы кластера, а также созданный ранее объект CLUSTER1. Как было описано выше, объект CLUSTER1 должен иметь права на создание объектов в контейнере, иначе объект FILESTORAGE создан не будет.

Рис. 30. Контейнер Active Directory

В консоли Failover Cluster Manager можно убедиться, что роль успешно добавлена и функционирует.

Рис. 31. Консоль Failover Cluster Manager

Что нового в Windows Server 2016 Failover Clustering / Хабр

Автор статьи – Роман Левченко (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, к сожалению, не поддерживается.

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


Роль Статус поддержки Комментарий
SQL Server Поддерживается Рекомендуется использовать встроенную аутентификацию SQL Server
File Server Поддерживается, но не рекомендуется Отсутствие Kerberos аутентификации, являющейся основной для SMB
Hyper-V Поддерживается, но не рекомендуется Доступна только Quick Migration. Live Migration не поддерживается
Message Queuing (MSMQ) Не поддерживается MSMQ требуется ADDS

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

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

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

AutoBalancerLevel

:

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

AutoBalancerLevel Агрессивность балансировки Комментарий
1 (по умолчанию) Low Осуществлять балансировку при загрузке узла более 80% по одной из эвристик
2 Medium При загрузке более 70%
3 High При загрузке более 60%

Параметры балансировщика можно определить и в 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 завершен. Надеюсь, что материал получился полезным. Спасибо за чтение и комментарии.

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

Отказоустойчивый кластер Hyper-V Server 2019 — ITsberg.ru

Сегодня опишу процесс построения отказоустойчивого кластера из двух серверов на основе Microsoft Hyper-V Server 2019 и с общим блочным хранилищем.

Упрощённое описание инфраструктуры кластера:

У каждого сервера по четыре сетевых интерфейса. Два сетевых интерфейса гигабитные — будут объединены в агрегированный канал, на котором будет создан виртуальный коммутатор Hyper-V, и через него же будет осуществляться доступ к кластеру.
Два других сетевых интерфейса (10 GB каждый) так же будут объединены агрегированный канал. Здесь будут построены виртуальные сети для доступа к общим блочным хранилищам, сеть Live Migration и Cluster Shared Volume. Доступ к этим сетям будет только у кластера.
Интерфейсы подключены к разным коммутаторам для обеспечения отказоустойчивости, сети изолированы друг от друга.

Почему именно Microsoft Hyper-V Server 2019? Эта ОС бесплатна, её функционала достаточно для обеспечения отказоустойчивого выполнения виртуальных машин, а что касается вопроса, какой гипервизор лучше — на эту тему в интернете навалом статей и нет однозначного ответа. Мне нравится работать с Hyper-V и его возможностей хватает для задач подавляющего большинство компаний.

После установки ОС на хост-сервер всплывает интересный нюанс: к Hyper-V Server 2019 не удастся подключиться по RDP, т.к. данный функционал Microsoft убрали из этой версии ОС. Для настройки у нас остаются четыре метода:
Прямой доступ к серверу.
Powershell Remoting (WinRM)
Приложение «Диспетчер серверов» от Microsoft
Windows Admin Center, тоже от Microsoft.
Так же есть несколько сторонних утилит, к примеру PsTools от Sysinternals.

Sconfig выглядит так, доступен на локальной консоли:

Конфигурирование серверов буду производить в Windows Admin Center.

Подготовка хостов

Итак, что входит в предварительную настройку хоста при подготовке его к включению в кластер:
Настройка сетевых интерфейсов
Введение сервера в домен
Установка необходимых ролей и компонентов
Подключение сетевого хранилища (в нашем случае — iSCSI-диски)
Установка обновлений ОС

Все операции выполняются от имени учётной записи пользователя домена (Domain User), имеющей права администратора на обоих серверах.
Так же у этой учётной записи должны быть права Create Computer в том OU или контейнере, в котором находятся серверы, из которых будем собирать кластер.
Чаще всего данные операции выполняются пользователем с правами Domain Admin.

С самого начала необходимо настроить доступ к сети чтобы присоединить сервер к домену. Как собрать кластер без доменной инфраструктуры — описано в этой статье.

Т.к. sconfig, предлагаемый нам при логине, не имеет функционала для настройки агрегирования каналов, выходим из него в командную строку и запускаем powershell (последний пункт меню в sconfig — Exit to Command line). Powershell запускается из командной строки командой powershell. Даже скриншоты делать не буду чтобы описать запуск PS подробнее.

Получаем список сетевых адаптеров:

Get-NetAdapter |Format-Table -Autosize

В данный момент поднято три интерфейса. Интерфейсы QLogic (ifIndex 3 и 9) — одногигабитные, их и будем объединять в «сеть доступа». Третий поднятый интерфейс — по нему я в данный момент подключен к серверу. После настройки сети доступа будет необходимо переключиться на управление через неё и тогда можно будет настраивать сеть кластера на интерфейсах Intel, по 10Gb каждый.

Первым делом объединяем интерфейсы QLogic в агрегированный канал, тип объединения будет LACP.

New-NetLbfoTeam -Name "LACP_LAN" -TeamMembers "Ethernet 2", "Ethernet 4" -TeamingMode LACP -LoadBalancingAlgorithm Dynamic

Теперь, если снова написать Get-NetAdapter, увидим новый сетевой интерфейс с именем LACP_LAN

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

New-VMSwitch -Name "HV_LAN" -AllowManagementOS $True -NetAdapterName "LACP_LAN"

Созданный VMSwitch появился в списке сетевых адаптеров — значит всё сделано правильно. Если у вас применяется разделение на виртуальные сети — указываем VLAN ID на созданном интерфейсе:

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "HV_LAN" -Access -VlanId 10

И задаём IP адрес и прочие настройки сети (тут важно не перепутать и указать правильный ifIndex, в нашем случае — 22)

New-NetIPAddress -InterfaceIndex 24 -IPAddress 192.168.1.224 -PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceIndex 24 -ServerAddress 192.168.1.220

Всё, можно переключаться на сеть доступа и работать уже через неё.
Вводим сервер в домен и переименовываем как нам необходим (если ещё не переименовали). Удобнее всего это делать через sconfig, там всё предельно просто. Из powershell sconfig вызывается командой «sconfig».
sconfig sconfig sconfig

Список сетевых интерфейсов теперь такой:

Интерфейсы 10Gb от Intel подключены в разные коммутаторы, на случай, если один из коммутаторов откажет. На их основе настроим агрегированный канал с несколькими виртуальными сетями для доступа к блочному дисковому хранилищу по протоколу iSCSI и для работы кластера.

New-NetLbfoTeam -Name "LACP_CL" -TeamMembers "Ethernet", "Ethernet 3" -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic

В данной ситуации необходимо применить режим объединения SwitchIndependent, т.к. физические интерфейсы подключены к разным коммутаторам и управлять агрегированием будет операционная система, а не коммутатор. Но мы создали один виртуальный интерфейс, а нам необходимо минимум две раздельные сети для стабильного функционирования кластера (всё по заветам MS) и хотя-бы одна сеть для iSCSI. Не рекомендуется смешивать iSCSI и сеть доступа.
Разделять сети будем посредством VLAN. Т.е. нам необходимо взять виртуальный интерфейсLACP_CL, собранный на прошлом шаге, и собрать на нём ещё три виртуальных интерфейса, каждый в своём VLAN’е.

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

Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Jumbo Packet" -DisplayValue "4088" -PassThru

Set-NetAdapterAdvancedProperty -Name "Ethernet 3" -DisplayName "Jumbo Packet" -DisplayValue "4088" -PassThru

Создаём виртуальные интерфейсы с VLAN’ами.

Add-NetLbfoTeamNic -Team "LACP_CL" -Name "LACP_CL_CSV" -VlanID 11

Этой командой мы добавили виртуальный сетевой интерфейс с именем «LACP_CL_CSV» с VLAN’ом 11 к интерфейсу «LACP_CL». Делаем то же самое для для остальных VLAN’ов:

Add-NetLbfoTeamNic -Team "LACP_CL" -Name "LACP_CL_LM" -VlanID 12
Add-NetLbfoTeamNic -Team "LACP_CL" -Name "LACP_CL_3200" -VlanID 32

В результате получается такой список интерфейсов и остаётся настроить IP-адреса.
Т.к. интерфейсов уже довольно много, удобнее будет отсортировать вывод, к примеру, в алфавитном порядке:

Get-NetAdapter |Sort-Object Name |Format-Table -AutoSize

Выполняем командлет присвоения IP-адреса, внимательно подставляя свои адреса и номера интерфейсов:

New-NetIPAddress -InterfaceIndex "ifIndex" -IPAddress "IP-address" -PrefixLength 24

Если где-то ошиблись, удалить созданные виртуальные адаптеры можно командой, где «VLAN» — номер VLAN.

Remove-NetLbfoTeamNic -Team "Team-name" -VlanID "VLAN"

Ставим роли и службы:

Install-WindowsFeature failover-clustering, rsat-clustering, rsat-role-tools, rsat-hyper-v-tools, hyper-v-powershell

Теперь iSCSI

Сначала необходимо перевести сервис iSCSI-инициатора в режим автоматического запуска и запустить его:

Set-Service -Name msiscsi -StartupType automatic
Start-service msiscsi

Для работы с дисковыми устройствами по протоколу iSCSI необходимо настроить так называемый iSCSI target portal:

New-IscsiTargetPortal -TargetPortalAddress 192.168.130.102 -InitiatorPortalAddress 192.168.130.112

Где:
TargetPortalAddress — IP адрес устройства, к которому подключаемся
ItiniatorPortalAddress — IP адрес сетевого интерфейса, которым смотрим в сеть iSCSI, т.е. IP-адрес интерфейса на Hyper-V сервере. В нашем случае это адрес интерфейса с именем LACP_CL_3200.
Посмотреть на доступные iSCSI-таргеты можно комадлетом

Get-IscsiTarget

Подключаем доступные iSCSI-таргеты:

Get-IscsiTarget |Connect-IscsiTarget -IsPersistent $true -IsMultipathEnabled:$true

Либо можно вызвать обычную графическую консоль командой

iscsicpl


Всё то же самое необходимо выполнить и на втором сервере.

Можно начинать работать с дисками.

Для того, чтобы диски можно было добавить в кластер как общее дисковое хранилище — диски должны быть отформатированы в NTFS и должны быть доступны на обоих серверах.
Нам понадобится минимум два диска — диск-свидетель кворума и диск для хранения виртуальных машин. Диск-свидетель может быть небольшим, хватит объёма в 1 GB.
Командлет Get-Disk возвращает список доступных дисков на данном сервере:

Get-Disk|Format-Table -Autosize

Начнём работу с диска номер 4, объёмом 1GB:

Initialize-Disk -Number 4
New-Partition -DiskNumber 4 -DriveLetter Q -UseMaximumSize
Format-Volume -DriveLetter Q -FileSystem NTFS

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

Перезагружаем оба сервера.

Всё, основные вещи на серверах сделаны, можно приступать к сборке кластера.

Собираем кластер

Кластер будем собирать используя Failover Cluster Manager.

Если проводить настройки будем с какого-либо подходящего стороннего сервера — предварительно необходимо установить на него средства удалённого управления отказоустойчивым кластером: Failover Cluster Management Tools и Failover Cluster Module for Windows Powershell

Install-WindowsFeature RSAT-Clustering-Mgmt, RSAT-Clustering-Powershell

Если будем настраивать с десктопной ОС — все необходимые модули ставятся во время установки средств удалённого администрирования сервера. Взять их можно на сайте Microsoft: https://www.microsoft.com/ru-RU/download/details.aspx?id=45520

Теперь можем запустить Failover Cluster Manager и заняться непосредственно сборкой кластера. Прежде всего необходимо проверить конфигурацию серверов, из которых мы всё это будем собирать. В Failover cluster Manager’е есть подходящий функционал — в разделе Management ссылочный пункт «Validate Cluster»:

Запускаем мастер проверки конфигурации, указываем наши серверы, в следующем пункте оставляем отметку Run all tests, жмём пару раз Next и ждём завершения тестов.

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

После проведения проверки можно посмотреть отчёт, понятно — в отчёте не должно быть ошибок.
Отчёт записывается в текущий рабочий каталог, например C:\Users\UserName\AppData\Local\Temp

Когда удостоверились что конфигурация серверов выполнена правильно — можно приступать к непосредственному созданию кластера. Запускаем мастер создания кластера (Create Cluster), добавляем серверы.
На шаге Access Point for Administering the Cluster в поле Cluster Name указываем имя создаваемого кластера и чуть ниже в таблице указываем IP-адрес кластера. При создании кластера это имя будет зарегистрировано в AD как cluster computer object (или cluster name object, CNO).

Нажимаем далее и подтверждаем создание.

Созданный кластер должен появиться в списке слева в Failover Cluster Manager’е. Если этого не произошло — нажимаем Connect to Cluster и подключаемся к нему.

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

Начинаем с сетей кластера. Раскрываем древовидное представление в менеджере и выбираем Networks:

Такое представление не очень информативно, я предпочитаю переименовать все Cluster Network # в соответствии с их назначением.

Что означает столбец Cluster Use:
Cluster Only — эта сеть будет использоваться только для рабочих нагрузок кластера (CSV или Live Migration)
None — кластер не будет использовать эту сеть. Через эти сетевые адаптеры у нас подключены iSCSI диски с общих блочных хранилищ и за работу с ними отвечает операционная система.
Cluster and Clients — Эту сеть могут использовать как кластер, так и клиенты. Кластер данную сеть будет использовать для отслеживания доступности и работы нод кластера (т.н. HeartBeat-пакеты, ранее для этих целей было необходимо создавать отдельную сеть). Ну через эту же сеть будет осуществляться доступ к администрированию кластера и к виртуальным машинам, развёрнутым в кластере.

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

Идём в Storage — Disks и должны тут увидеть несколько дисков, подключенных и подготовленных на стадии подготовки серверов.

Если дисков в списке нет — их необходимо добавить. Нажимаем Add Disks и выбираем необходимые нам диски из списка предложенных. Если же система говорит что No disks Suitable for cluster disks were found… значит где-то ошиблись при подготовке дисков. Мастер проверки должен был об этом написать.
Диски необходимо отформатировать в NTFS, назначить им букву и добавить в список.

Диск-свидетель. Для него будем использовать диск объёмом 1GB, в моём случае это Cluster Disk 1.
Для настройки свидетеля необходимо выбрать сам кластер и в разделе Actions нажать More-Actions — Configure Cluster Quorum Settings… Снова откроется соответствующйи мастер.
В мастере на шаге Select Quorum Configuration Options выбираем Select the quorum witness. На следующем шаге — Configure a disk witness.
Так же есть возможность использовать свидетель кворума на основе сетевой папки общего доступа (необходимое условие — протокол SMB3.0, либо использовать «облачный» свидетель кворума).
Мы будем использовать диск-свидетель, полученный по iSCSI с дисковой полки.
На следующем шаге выбираем хранилище, на котором разместим свидетель кворума.
В списке дисков можно посмотреть что изменилось. Так же я переименовал диск свидетель, чтобы не путаться в дальнейшем (делается так же, как и с сетями кластера):

Теперь необходимо добавить общее хранилище (Cluster Shared Volume, CSV).
В разделе Disks выбираем диск, из которого хотим сделать CSV и жмём Add to Cluster Shared Volume.

После добавления диска в CSV на системном диске каждого хоста кластера в директории C:\ClusterStorage автоматически создаётся объект с именем Volume#, в нашем случае — Volume1. Опять же, для удобства его можно переименовать.

Ну вот вроде бы и всё что хотел рассказать о создании кластера Hyper-V на основе Microsoft Hyper-V Server 2019.
Не обязательно кластер собирать именно так, как я описал в этой статье, вариантов конфигурации множество, может отличаться конфигурация сети (разные варианты обеспечения отказоустойчивости, хоть вообще всё через один коммутатор соединяй — работать будет, но крайне не желательно так делать), тип общего дискового хранилища (SAN или NAS, разные протоколы) и .т.д. Я описал, по моему мнению, один из универсальных вариантов.

P.S. Как работать с кластером, в двух словах: ПКМ на пункт Roles — Configure Role, выбрать из списка Virtual Machine и выбрать необходимые ВМ, уже развёрнутые на одном из хостов кластера.

Что нового в отказоустойчивой кластеризации в Windows Server

  • Статья
  • 11 минут на чтение
  • 15 участников

Полезна ли эта страница?

Да Нет

Любая дополнительная обратная связь?

Отзыв будет отправлен в Microsoft: при нажатии кнопки отправки ваш отзыв будет использован для улучшения продуктов и услуг Microsoft.Политика конфиденциальности.

Представлять на рассмотрение

В этой статье

Применяется к: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, версии 21h3 и 20h3

В этом разделе объясняются новые и измененные функции отказоустойчивой кластеризации для Azure Stack HCI, Windows Server 2019 и Windows Server 2016.

Новые возможности Windows Server 2019 и Azure Stack HCI

  • Кластерные наборы

    Наборы кластеров

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

    Дополнительные сведения см. в разделе Наборы кластеров.

  • Кластеры с поддержкой Azure

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

  • Междоменная миграция кластера

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

  • USB-свидетель

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

  • Усовершенствования кластерной инфраструктуры

    Кэш CSV теперь включен по умолчанию для повышения производительности виртуальной машины. Теперь MSDTC поддерживает общие тома кластера, что позволяет развертывать рабочие нагрузки MSDTC в Storage Spaces Direct, например, с SQL Server. Усовершенствованная логика для обнаружения разделенных узлов с самовосстановлением для возврата узлов в состав кластера. Усовершенствованное обнаружение сетевых маршрутов кластера и самовосстановление.

  • Обновление с поддержкой кластера поддерживает Storage Spaces Direct

    Обновление с поддержкой кластера (CAU) теперь интегрировано и поддерживает Storage Spaces Direct, проверяя и обеспечивая выполнение ресинхронизации данных на каждом узле.Cluster Aware Updating проверяет обновления и разумно перезапускает их только в случае необходимости. Это позволяет организовывать перезапуски всех серверов в кластере для планового обслуживания.

  • Усовершенствования файлового ресурса-свидетеля

    Мы включили использование файлового ресурса-свидетеля в следующих сценариях:

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

    • Отсутствие общих дисков для диска-свидетеля.Это может быть гиперконвергентная конфигурация Storage Spaces Direct, SQL Server Always On Availability Groups (AG) или * Exchange Database Availability Group (DAG), ни одна из которых не использует общие диски.

    • Отсутствие подключения к контроллеру домена из-за того, что кластер находится за демилитаризованной зоной.

    • Рабочая группа или междоменный кластер, для которого нет объекта имени кластера Active Directory (CNO). Узнайте больше об этих улучшениях в следующем сообщении в блогах по серверам и управлению: файловый ресурс отказоустойчивого кластера-свидетель и DFS.

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

  • Кластерное упрочнение

    Внутрикластерная связь через блок сообщений сервера (SMB) для общих томов кластера и дисковых пространств Direct теперь использует сертификаты для обеспечения наиболее безопасной платформы.Это позволяет отказоустойчивым кластерам работать без зависимости от NTLM и обеспечивать базовые уровни безопасности.

  • Отказоустойчивый кластер больше не использует проверку подлинности NTLM

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

Новые возможности Windows Server 2016

Последовательное обновление операционной системы кластера

Последовательное обновление операционной системы кластера

позволяет администратору обновить операционную систему узлов кластера с Windows Server 2012 R2 до более новой версии, не останавливая рабочие нагрузки Hyper-V или масштабируемого файлового сервера. Используя эту функцию, можно избежать штрафов за простои в соответствии с соглашениями об уровне обслуживания (SLA).

Какое значение добавляет это изменение?

Обновление кластера Hyper-V или масштабируемого файлового сервера с Windows Server 2012 R2 до Windows Server 2016 больше не требует простоя.Кластер будет продолжать функционировать на уровне Windows Server 2012 R2 до тех пор, пока все узлы в кластере не будут работать под управлением Windows Server 2016. Функциональный уровень кластера будет обновлен до Windows Server 2016 с помощью командлета Windows PowerShell Update-ClusterFunctionalLevel .

Предупреждение

  • После обновления функционального уровня кластера невозможно вернуться к функциональному уровню кластера Windows Server 2012 R2.

  • Пока не запущен командлет Update-ClusterFunctionalLevel , процесс является обратимым, и можно добавлять узлы Windows Server 2012 R2 и удалять узлы Windows Server 2016.

Что работает иначе?

Отказоустойчивый кластер Hyper-V или масштабируемого файлового сервера теперь можно легко обновить без простоев или создать новый кластер с узлами, работающими под управлением операционной системы Windows Server 2016. Миграция кластеров на Windows Server 2012 R2 включала в себя перевод существующего кластера в автономный режим и переустановку новой операционной системы для каждого узла, а затем повторное подключение кластера к сети. Старый процесс был громоздким и требовал простоя.Однако в Windows Server 2016 кластеру не нужно отключаться в любой момент.

Операционные системы кластера для поэтапного обновления следующие для каждого узла в кластере:

  • Узел приостановлен, и на нем удалены все виртуальные машины.
  • Виртуальные машины (или другая рабочая нагрузка кластера) переносятся на другой узел в кластере.
  • Существующая операционная система удаляется и выполняется чистая установка операционной системы Windows Server 2016 на узле.
  • Узел под управлением операционной системы Windows Server 2016 снова добавлен в кластер.
  • На данный момент считается, что кластер работает в смешанном режиме, поскольку узлы кластера работают под управлением Windows Server 2012 R2 или Windows Server 2016.
  • Функциональный уровень кластера остается на уровне Windows Server 2012 R2. На этом функциональном уровне новые функции Windows Server 2016, влияющие на совместимость с предыдущими версиями операционной системы, будут недоступны.
  • В конечном итоге все узлы будут обновлены до Windows Server 2016.
  • Функциональный уровень кластера затем изменяется на Windows Server 2016 с помощью командлета Windows PowerShell Update-ClusterFunctionalLevel . На этом этапе вы можете воспользоваться преимуществами функций Windows Server 2016.

Дополнительные сведения см. в разделе Последовательное обновление операционной системы кластера.

Реплика хранилища

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

Какое значение добавляет это изменение?

Реплика хранилища

позволяет выполнять следующие действия:

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

  • Используйте транспорт SMB3 с проверенной надежностью, масштабируемостью и производительностью.

  • Растянуть отказоустойчивые кластеры Windows на большие расстояния.

  • Используйте сквозное программное обеспечение Microsoft для хранения и кластеризации, например Hyper-V, Storage Replica, Storage Spaces, Cluster, Scale-Out File Server, SMB3, дедупликацию данных и ReFS/NTFS.

  • Помогите снизить стоимость и сложность следующим образом:

    • Не зависит от оборудования и не требует определенной конфигурации хранилища, такой как DAS или SAN.

    • Разрешает стандартные хранилища и сетевые технологии.

    • Простота графического управления отдельными узлами и кластерами с помощью Failover Cluster Manager.

    • Включает в себя комплексные крупномасштабные возможности создания сценариев с помощью Windows PowerShell.

  • Сократите время простоя и повысьте надежность и производительность Windows.

  • Обеспечение возможности поддержки, показателей производительности и возможностей диагностики.

Дополнительные сведения см. в разделе Реплика хранилища в Windows Server 2016.

Свидетель облака

Облако-свидетель — это новый тип свидетеля кворума отказоустойчивого кластера в Windows Server 2016, который использует Microsoft Azure в качестве точки арбитража. Облако-свидетель, как и любой другой свидетель кворума, получает право голоса и может участвовать в подсчете кворума. Вы можете настроить облачный свидетель в качестве свидетеля кворума с помощью мастера настройки кворума кластера.

Какое значение добавляет это изменение?

Использование Cloud Witness в качестве свидетеля кворума отказоустойчивого кластера дает следующие преимущества:

  • Использует Microsoft Azure и устраняет необходимость в третьем отдельном центре обработки данных.

  • Использует стандартное общедоступное хранилище больших двоичных объектов Microsoft Azure, которое устраняет дополнительные затраты на обслуживание виртуальных машин, размещенных в общедоступном облаке.

  • Одна и та же учетная запись хранения Microsoft Azure может использоваться для нескольких кластеров (один файл большого двоичного объекта на кластер; уникальный идентификатор кластера используется в качестве имени файла большого двоичного объекта).

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

Дополнительные сведения см. в разделе Развертывание облака-свидетеля для отказоустойчивого кластера.

Что работает иначе?

Эта возможность впервые появилась в Windows Server 2016.

Устойчивость виртуальной машины

Отказоустойчивость вычислений Windows Server 2016 включает повышенную отказоустойчивость вычислений виртуальных машин, чтобы уменьшить проблемы с обменом данными внутри кластера в вашем вычислительном кластере следующим образом:

  • Параметры устойчивости, доступные для виртуальных машин: Теперь вы можете настроить параметры устойчивости виртуальных машин, которые определяют поведение виртуальных машин во время временных сбоев:

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

Дополнительные сведения о рабочем процессе устойчивости вычислений виртуальной машины и параметрах карантина узла, которые управляют тем, как ваш узел помещается в изоляцию или карантин, см. в разделе Устойчивость вычислений виртуальной машины в Windows Server 2016.

Отказоустойчивость хранилища В Windows Server 2016 виртуальные машины более устойчивы к временным сбоям хранилища. Улучшенная отказоустойчивость виртуальных машин помогает сохранить состояния сеансов виртуальных машин арендаторов в случае нарушения работы хранилища.Это достигается за счет интеллектуального и быстрого реагирования виртуальной машины на проблемы с инфраструктурой хранения.

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

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

Улучшения диагностики в отказоустойчивой кластеризации

Для диагностики проблем с отказоустойчивыми кластерами Windows Server 2016 включает следующее:

Отказоустойчивые кластеры с поддержкой сайта

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

Рабочие группы и многодоменные кластеры

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

.
  • Однодоменные кластеры. Кластеры со всеми узлами, присоединенными к одному домену.

  • Многодоменные кластеры. Кластеры с узлами, которые являются членами разных доменов.

  • Кластеры рабочих групп. Кластеры с узлами, являющимися рядовыми серверами/рабочей группой (не присоединенными к домену).

Дополнительные сведения см. в разделе Рабочие группы и многодоменные кластеры в Windows Server 2016

.

Балансировка нагрузки виртуальной машины

Балансировка нагрузки виртуальных машин — это новая функция отказоустойчивой кластеризации, которая упрощает плавную балансировку нагрузки виртуальных машин между узлами в кластере.Перегруженные узлы определяются на основе использования памяти виртуальной машины и ЦП на узле. Затем виртуальные машины перемещаются (живая миграция) с узла с чрезмерным выделением ресурсов на узлы с доступной пропускной способностью (если применимо). Интенсивность балансировки можно настроить для обеспечения оптимальной производительности и использования кластера. Балансировка нагрузки включена по умолчанию в Windows Server 2016 Technical Preview. Однако балансировка нагрузки отключается, когда включена динамическая оптимизация SCVMM.

Порядок запуска виртуальной машины

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

Упрощенные многоканальные сети SMB и кластерные сети с несколькими сетевыми картами

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

Дополнительные сведения см. в разделе Упрощенные многоканальные сети SMB и кластерные сети с несколькими сетевыми картами.

См. также

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

  • Статья
  • 5 минут на чтение
  • 10 участников

Полезна ли эта страница?

Да Нет

Любая дополнительная обратная связь?

Отзыв будет отправлен в Microsoft: при нажатии кнопки отправки ваш отзыв будет использован для улучшения продуктов и услуг Microsoft.Политика конфиденциальности.

Представлять на рассмотрение

В этой статье

Применяется к: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Azure Stack HCI, версии 21h3 и 20h3

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

  • Серверы : Мы рекомендуем вам использовать набор соответствующих компьютеров, которые содержат одинаковые или похожие компоненты.

    Примечание

    Если вы приобрели оборудование интегрированной системы Azure Stack HCI из каталога Azure Stack HCI через предпочитаемого партнера Microsoft по оборудованию, операционная система Azure Stack HCI должна быть предварительно установлена.

  • Сетевые адаптеры и кабель (для сетевой связи) : Если вы используете iSCSI, каждый сетевой адаптер должен быть предназначен либо для сетевой связи, либо для iSCSI, а не для того и другого одновременно.

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

    Примечание

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

  • Контроллеры устройств или соответствующие адаптеры для хранения :

    • Serial Attached SCSI или Fibre Channel : Если вы используете Serial Attached SCSI или Fibre Channel, на всех кластерных серверах все элементы стека хранения должны быть идентичными.Необходимо, чтобы программное обеспечение многопутевого ввода-вывода (MPIO) было идентичным, а программное обеспечение модуля для конкретных устройств (DSM) было идентичным. Рекомендуется, чтобы контроллеры запоминающих устройств — адаптер главной шины (HBA), драйверы HBA и встроенное ПО HBA — которые подключались к кластерному хранилищу, были идентичными. Если вы используете разные HBA, вам следует уточнить у поставщика системы хранения, что вы следуете их поддерживаемым или рекомендуемым конфигурациям.
    • iSCSI : Если вы используете iSCSI, каждый кластерный сервер должен иметь один или несколько сетевых адаптеров или HBA, выделенных для хранилища кластера.Сеть, которую вы используете для iSCSI, не должна использоваться для сетевого обмена данными. На всех кластерных серверах сетевые адаптеры, которые вы используете для подключения к целевому хранилищу iSCSI, должны быть идентичными, и мы рекомендуем вам использовать Gigabit Ethernet или выше.
  • Хранилище : вы должны использовать Storage Spaces Direct или общее хранилище, совместимое с Windows Server 2012 R2 или Windows Server 2012. Вы можете использовать подключенное общее хранилище, а также можете использовать SMB 3.0 в качестве общего хранилища для серверов с Hyper-V, настроенных в отказоустойчивом кластере. Дополнительные сведения см. в разделе Развертывание Hyper-V через SMB.

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

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

    • Мы рекомендуем отформатировать разделы в NTFS. Если вы используете общие тома кластера (CSV), раздел для каждого из них должен быть NTFS.

      Примечание

      Если у вас есть диск-свидетель для конфигурации кворума, вы можете отформатировать диск либо в NTFS, либо в отказоустойчивой файловой системе (ReFS).

    • Для стиля раздела диска можно использовать основную загрузочную запись (MBR) или таблицу разделов GUID (GPT).

      Диск-свидетель — это диск в хранилище кластера, предназначенный для хранения копии базы данных конфигурации кластера. Отказоустойчивый кластер имеет диск-свидетель, только если он указан как часть конфигурации кворума. Дополнительные сведения см. в разделе Общие сведения о кворуме в Storage Spaces Direct.

Требования к оборудованию для Hyper-V

Если вы создаете отказоустойчивый кластер, включающий кластеризованные виртуальные машины, серверы кластера должны поддерживать требования к оборудованию для роли Hyper-V.Для Hyper-V требуется 64-разрядный процессор, включающий следующее:

.
  • Аппаратная виртуализация. Это доступно для процессоров с опцией виртуализации, в частности для процессоров с технологией виртуализации Intel (Intel VT) или AMD Virtualization (AMD-V).
  • Должна быть доступна и включена аппаратная защита от выполнения данных (DEP). В частности, вы должны включить бит Intel XD (бит отключения выполнения) или бит AMD NX (без бита выполнения).

Дополнительные сведения о роли Hyper-V см. в разделе Обзор Hyper-V.

Развертывание сетей хранения данных с отказоустойчивыми кластерами

При развертывании сети хранения данных (SAN) с отказоустойчивым кластером следуйте этим рекомендациям:

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

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

  • Рассмотрите возможность использования программного обеспечения многопутевого ввода-вывода или объединенных сетевых адаптеров : В высокодоступной структуре хранения можно развернуть отказоустойчивые кластеры с несколькими адаптерами главной шины с помощью программного обеспечения многопутевого ввода-вывода или объединения сетевых адаптеров (также называемых балансировкой нагрузки и отказоустойчивость или LBFO). Это обеспечивает высочайший уровень резервирования и доступности.Для Windows Server 2012 R2 или Windows Server 2012 решение с несколькими путями должно быть основано на многопутевом вводе-выводе Microsoft (MPIO). Ваш поставщик оборудования, как правило, поставляет модуль MPIO для конкретного устройства (DSM) для вашего оборудования, хотя Windows Server включает один или несколько DSM как часть операционной системы.

    Важно

    Адаптеры главной шины и программное обеспечение многоканального ввода-вывода могут быть очень чувствительными к версии. Если вы реализуете решение с несколькими путями для своего кластера, тесно сотрудничайте с поставщиком оборудования, чтобы выбрать правильные адаптеры, встроенное ПО и программное обеспечение для версии Windows Server, на которой вы работаете.

  • Рассмотрите возможность использования дисковых пространств : Если вы планируете развернуть кластерное хранилище с последовательным подключением SCSI (SAS), настроенное с использованием дисковых пространств, требования см. в разделе Развертывание кластерных дисковых пространств.

Дополнительная информация

Как создать отказоустойчивый кластер в Windows Server 2019

В этой статье дается краткий обзор того, как создать отказоустойчивый кластер Microsoft Windows (WFC) с Windows Server 2019 или 2016.В результате получится двухузловой кластер с одним общим диском и вычислительным ресурсом кластера (компьютерный объект в Active Directory).

Подготовка

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

Два компьютера с Windows 2019 с установленными последними обновлениями. Машины имеют как минимум два сетевых интерфейса: один для рабочего трафика, другой для трафика кластера.В моем примере есть три сетевых интерфейса (один дополнительный для трафика iSCSI). Я предпочитаю статические IP-адреса, но вы также можете использовать DHCP.

Присоедините оба сервера к вашему домену Microsoft Active Directory и убедитесь, что оба сервера видят общее устройство хранения, доступное в управлении дисками. Пока не подключайте диск к сети.

Следующим шагом, прежде чем мы действительно сможем начать, является добавление функции Failover Clustering ( Диспетчер сервера > добавить роли и функции ).

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

  Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools  

После успешной установки Диспетчер отказоустойчивого кластера появится в меню «Пуск» в Инструментах администрирования Windows .

После установки компонента Failover-Clustering можно подключить общий диск к сети и отформатировать его на одном из серверов.Ничего не меняйте на втором сервере. На втором сервере диск остается в автономном режиме.

После обновления управления дисками вы можете увидеть что-то похожее на это:

Сервер 1 Управление дисками (состояние диска онлайн )

Сервер 2 Управление дисками (состояние диска в автономном режиме )

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

Перед созданием кластера необходимо убедиться, что все настроено правильно.Запустите Failover Cluster Manager  из меню «Пуск», прокрутите вниз до раздела управления и нажмите Validate Configuration .

Выберите два сервера для проверки.

Выполнить все тесты. Также есть описание того, какие решения поддерживает Microsoft.

Убедившись, что все применимые тесты прошли со статусом «успешно», вы можете создать кластер, установив флажок Создать кластер сейчас, используя проверенные узлы , или вы можете сделать это позже.Если у вас есть ошибки или предупреждения, вы можете использовать подробный отчет, нажав View Report .

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

Если вы решите создать кластер, нажав Создать кластер в Диспетчере отказоустойчивого кластера , вам снова будет предложено выбрать узлы кластера. Если вы используете флажок Создать кластер сейчас, используя проверенные узлы в мастере проверки кластера, вы пропустите этот шаг.Следующим важным шагом является создание точки доступа для администрирования кластера . Это будет виртуальный объект, с которым клиенты будут взаимодействовать позже. Это компьютерный объект в Active Directory.

Мастер запрашивает имя кластера и конфигурацию IP-адреса.

В качестве последнего шага подтвердите все и дождитесь создания кластера.

Мастер автоматически добавит общий диск в кластер по умолчанию.Если еще не настроили, то можно и потом.

В результате вы увидите новый объект компьютера Active Directory с именем WFC2019 .

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

В качестве альтернативы вы можете создать кластер также с помощью PowerShell. Следующая команда также автоматически добавит все подходящие хранилища:

  New-Cluster -Name WFC2019 -Node SRV2019-WFC1, SRV2019-WFC2 -StaticAddress 172.21.237.32  

Результат можно увидеть в диспетчере отказоустойчивого кластера в разделах Узлы и Хранилище > Диски .

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

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

В настоящее время кластер использует диск, настроенный ранее в качестве диска-свидетеля. Альтернативными вариантами являются файловый ресурс-свидетель или учетная запись хранения Azure в качестве свидетеля. В этом примере мы будем использовать файловый ресурс-свидетель. На веб-сайте Microsoft есть пошаговое руководство для облачного свидетеля. Я всегда рекомендую настроить свидетеля кворума для правильной работы. Итак, последний вариант на самом деле не вариант для производства.

Просто укажите путь и завершите работу мастера.

После этого общий диск доступен для использования для данных.

Поздравляем, вы настроили отказоустойчивый кластер Microsoft с одним общим диском.

Следующие шаги и резервное копирование

Одним из следующих шагов будет добавление роли в кластер, что выходит за рамки этой статьи. Как только кластер содержит данные, также пора подумать о резервном копировании кластера. Veeam Agent для Microsoft Windows может создавать резервные копии отказоустойчивых кластеров Windows с общими дисками.Мы также рекомендуем делать резервные копии «всей системы» кластера. Это также создает резервные копии операционных систем членов кластера. Это помогает ускорить восстановление вышедшего из строя узла кластера, так как не нужно искать драйвера и т.п. в случае восстановления.

Узнать больше:

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

Отказоустойчивый кластер позволит вам сделать службы Windows Server высокодоступными. В этом руководстве мы рассмотрим простую настройку отказоустойчивого кластера в Windows Server 2019 без настройки каких-либо служб.

Прежде чем мы начнем

Это ресурсы, которые вам понадобятся, если вы новичок в отказоустойчивой кластеризации — https://docs.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster

.

Предпосылки

Я предполагаю, что вы знаете основные сведения о Windows Server, прежде чем пытаться это сделать.

DC

Лабораторная лаборатория

для этого руководства состоит из следующего:

Домен: информатик.местный

Контроллер домена с именем DC1 — 10.0.0.31

МСКСИ

Один целевой сервер Windows Server ISCSI с именем ISCSI1 (если вы не знаете, как создать целевой сервер ISCSI, вот руководство)

ISCSI1 – 10.0.0.50

На этой машине есть один дополнительный диск емкостью 40 ГБ, который будет назначен целевому объекту ISCSI.

Опционально, вам не нужно поднимать целевой сервер iscsi и настраивать iscsi для отказоустойчивого кластера — вы также можете запустить отказоустойчивый кластер без хранилища.

Отказоустойчивый кластер

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

Отработка отказа1 — NIC1 10.0.0.52 NIC2 192.168.4.2

Отработка отказа2 — NIC1 10.0.0.53 NIC2 192.168.4.3

Сеть 192.168.4.xx предназначена только для внутренней конфигурации кластера (пульс). На сетевые карты, которые будут служить вам для сердцебиения и внутренней связи кластера – Панель управления | Центр управления сетями и общим доступом | Изменить настройки адаптера | щелкните правой кнопкой мыши сетевой адаптер, который будет использоваться для связи кластера – Свойства | на вкладке Сеть выберите IPv4 – Свойства | нажмите кнопку «Дополнительно» | на вкладке DNS снимите флажок Зарегистрировать адреса этого подключения в DNS | Вкладка WINS – выберите Отключить NetBIOS через TCP/IP .Делайте это ТОЛЬКО НА сетевых адаптерах, которые будут сервером для внутренней связи кластера!

Все эти машины должны быть частью домена.

Обязательно включите функцию MPIO и инициатор iSCSI на компьютерах Failover1 и Failover2. Обязательно следуйте моему руководству, которое я опубликовал выше, для создания цели ISCSI, в нем есть все подробности.

MPIO очень важен при использовании общего хранилища.

Подключите один 40-гигабайтный диск, который вы определили как цель ISCSI, к Failover1 и Failover2, оставьте его в автономном режиме на узле failover2.

Кластер будет называться Cluster1

Кластер 1 — 10.0.0.54

Свидетель кластера. Нам нужна дополнительная виртуальная машина, которая будет содержать файловый ресурс, который будет недоступен для нашего кластера — Witness1

.

Свидетель 1 – 10.0.0.55

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

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

Открыть диспетчер серверов | щелкните Управление | Добавить роли и функции | на экране «Функции» выберите «Отказоустойчивая кластеризация

».

Появится дополнительное всплывающее окно, нажмите «Добавить функции».

Следующий

Установить

Закройте мастер и перезагрузите сервер.

Повторите этот процесс на узле Failover2.

Проверка конфигурации кластера

После того, как вы установили отказоустойчивую кластеризацию на обоих узлах, войдите на узел Failover1, щелкните Пуск | Средства администрирования Windows | выберите диспетчер отказоустойчивого кластера

Нажмите «Диспетчер отказоустойчивого кластера» и на среднем экране выберите «Проверить конфигурацию…»

Следующий

Выберите оба сервера (в моем случае Failover1 и Failover2) и нажмите Далее

Выполнить все тесты | Далее

Следующий

Все тесты прошли успешно | Готово

Мы можем приступить к созданию кластера

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

Диспетчер отказоустойчивого кластера | на экране «Действие» выберите «Создать кластер

».

Следующий

Снова выберите оба сервера, которые будут частью кластера | Далее

Я назову кластер — Cluster1 и дам ему IP 10.0,54 | Далее

Следующий

Успех! Готово

Теперь мы можем видеть созданный кластер 1 и два узла как его часть.

Добавить свидетеля кворума кластера

Cluster Quorum Witness повысит доступность отказоустойчивого кластера. Я не буду вдаваться в подробности о роли свидетеля, вы можете найти больше деталей здесь — https://docs.microsoft.com/en-us/windows-server/failover-clustering/manage-cluster-quorum

.

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

На машине Witness1 я добавил папку с именем ClusterWitness и открыл к ней общий доступ.

Вернуться к узлу Failover1 — Открыть диспетчер отказоустойчивого кластера | выберите Действия | Дополнительные действия | Настройка параметров кворума кластера

Следующий

Выберите свидетеля кворума | Далее

У вас есть много вариантов, сегодня мы выберем «Настроить файловый ресурс-свидетель» Далее

Введите полное доменное имя для общей папки на свидетеле1.В моем случае это \witness1\ClusterWitness | Далее

Просмотрите и нажмите Далее

Успех! Готово

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

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

Отказ от ответственности

Новые возможности отказоустойчивой кластеризации Windows Server 2019: полный обзор

Блог NAKIVO > Администрирование и резервное копирование Hyper-V > 10 основных функций отказоустойчивой кластеризации Windows Server 2019: полный обзор

26 декабря 2019 г.

по Джесси Рид

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

Чтобы снизить риск простоя, вам необходимо убедиться, что ваш бизнес по-прежнему может предоставлять свои услуги после выхода из строя системы или любого из ее компонентов.Окончательный подход заключается в создании высокодоступной среды, что может быть достигнуто путем обеспечения избыточности всех компонентов системы. Существуют различные способы обеспечения высокой доступности для вашей среды — например, с помощью резервного копирования Windows Server. Другой популярный вариант — отказоустойчивая кластеризация. В сегодняшней записи блога мы опишем, как работает отказоустойчивая кластеризация на серверах Windows. Кроме того, мы обсудим, как изменилась функциональность отказоустойчивой кластеризации с выпуском Windows Server 2019.В частности, мы предоставим обзор 10 основных функций отказоустойчивой кластеризации Windows Server 2019, в том числе:

  • Междоменная миграция кластера
  • Усовершенствования общих томов кластера
  • Кластеры с поддержкой Azure
  • USB-файловый ресурс-свидетель для кворума
  • Обновленный файловый ресурс-свидетель для сценариев кворума
  • Наборы кластеров
  • Обновление кластера для Storage Spaces Direct
  • Аутентификация отказоустойчивого кластера Windows Server 2019
  • Самовосстанавливающиеся отказоустойчивые кластеры
  • Низкая цена4 по цене 99 долларов за сокет вы можете приобрести базовую версию NAKIVO Backup & Replication и получить доступ к основным функциям, которые может предложить наш продукт.Читайте дальше, чтобы узнать, как NAKIVO Backup & Replication может оптимизировать ваши действия по защите данных для достижения высочайшего уровня доступности и непрерывности бизнеса.

    Основы отказоустойчивой кластеризации Windows Server

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

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

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

    Две машины могут обмениваться данными, используя функцию сердцебиения, посредством чего они отправляют друг другу сигналы сердцебиения через выделенную сеть.Различают два типа сигналов: толчковые и тянущие сердечные сокращения. Пуш-такт отправляется с активного сервера на пассивный, тогда как пул-пульс отправляется с пассивного сервера на активный. Эти коммуникационные сигналы отправляются/принимаются через равные промежутки времени. Таким образом, если «пульс» не достигает сервера в ожидаемое время, идентифицируется сбой сервера, и рабочие нагрузки отказавшего компьютера берут на себя резервный сервер.

    Чтобы узнать, как сделать вашу среду высокодоступной и устойчивой к системным сбоям, вы можете прочитать запись в нашем блоге о том, как включить высокую доступность Hyper-V с помощью отказоустойчивого кластера.Для получения более подробного обзора этой технологии вы можете загрузить нашу электронную книгу, в которой описывается, как развернуть отказоустойчивый кластер, какие требования необходимо выполнить для создания отказоустойчивого кластера и как NAKIVO Backup & Replication может обеспечить непрерывную защиту кластеров Hyper-V.

    Основные новые функции отказоустойчивой кластеризации для Windows Server 2019

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

    Междоменная миграция кластера

    Раньше процесс междоменной миграции кластера был сложной и трудоемкой задачей.Узлы и кластеры нельзя было просто перемещать между разными доменами. Этот процесс потребовал полной перенастройки отказоустойчивых кластеров, что привело к нежелательным сбоям в обслуживании и значительному времени простоя. С Windows Server 2019 вы, наконец, можете перенести отказоустойчивые кластеры из одного домена Active Directory в другой. Обеспечивая быструю и простую консолидацию доменов, вы можете сэкономить время, усилия и ресурсы.

    Усовершенствования общих томов кластера

    Кэш общего тома кластера (CSV) позволяет выделять системную память в виде кэша со сквозной записью, что позволяет кэшировать небуферизованный ввод-вывод только для чтения.С помощью этой функции вы можете повысить производительность виртуальных машин Hyper-V, которые используют небуферизованный ввод-вывод при доступе к виртуальным жестким дискам. Кэш CSV доступен в Windows Server 2019 по умолчанию, что обеспечивает более высокую производительность и более высокую производительность виртуальных машин, работающих поверх общих томов кластера. Другие усовершенствования CSV включают в себя улучшенную логику обнаружения любых проблем в кластере, а также его оперативное исправление. Эта функциональность работает благодаря обнаружению сетевого маршрута кластера и разделенным узлам.

    Кластеры с поддержкой Azure

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

    Общий файловый ресурс USB-свидетель для кворума

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

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

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

    Обновленный файловый ресурс-свидетель для сценариев кворума

    В выпуске Windows Server 2019 механизм голосования кворума стал еще более отказоустойчивым. Обновленный файловый ресурс-свидетель может быть полезен в следующих случаях:

    • Когда вы не можете получить доступ к облачному свидетелю из-за медленного или отсутствующего подключения к Интернету.
    • При отсутствии доступных общих дисков для диска-свидетеля.
    • Когда отказоустойчивый кластер работает в демилитаризованной зоне (DMZ), где подключение к контроллеру домена недоступно.
    • При наличии рабочей группы или кластера смешанного домена без объекта имени кластера Active Directory (CNO).

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

    Наборы кластеров

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

    Обновление с учетом кластера для Storage Spaces Direct

    Функция обновления с учетом кластера впервые была представлена ​​в Windows Server 2012. Что на самом деле может делать эта функция? Cluster-Aware Updating позволяет автоматически обновлять кластерные серверы с минимальной потерей доступности. С выпуском Windows Server 2019 эту функцию можно интегрировать с Storage Spaces Direct (S2D), что позволяет выполнять автоматическую повторную синхронизацию данных на каждом узле в процессе обновления.Более того, Cluster-Aware Updating может определять, после каких обновлений требуется перезагрузка системы. Таким образом, перезапуски будут выполняться только при необходимости, что значительно сократит время простоя бизнеса.

    Проверка подлинности отказоустойчивого кластера Windows Server 2019

    Отказоустойчивые кластеры также подвержены различным угрозам безопасности. В предыдущих выпусках Windows Server проверка подлинности NTLM требовала решения этой проблемы. С выпуском Windows Server 2019 команда Microsoft еще раз улучшила свой подход к безопасности.Вместо проверки подлинности NTLM узлы кластера могут взаимодействовать друг с другом с помощью проверки подлинности на основе сертификатов и Kerberos. Таким образом, вы можете предотвратить слипание сетевого трафика и сделать отказоустойчивые кластеры более устойчивыми к внезапным атакам безопасности.

    Самовосстанавливающиеся отказоустойчивые кластеры

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

    Усиление кластера

    Еще одна функция безопасности, доступная в Windows Server 2019, — усиление кластера.Узлы в кластере могут обмениваться данными через блок сообщений сервера (SMB) для общих томов кластера и прямых дисковых пространств с использованием проверки подлинности на основе сертификатов. Это обеспечивает более высокий уровень безопасности внутрикластерной связи.

    Защита данных с помощью NAKIVO Backup & Replication

    Основной задачей отказоустойчивой кластеризации является обеспечение высочайшего уровня доступности инфраструктуры. Windows Failover Clustering можно по праву считать важной технологией для современных центров обработки данных, которые должны обеспечивать непрерывное предоставление услуг.Благодаря этому функционалу вы можете избежать незапланированных простоев и поддерживать один и тот же уровень производительности бизнеса практически при любых обстоятельствах.

    Однако вам по-прежнему необходимо разработать комплексную стратегию защиты данных, способную реагировать на угрозы безопасности и предотвращать возможные аварии. NAKIVO Backup & Replication — это надежное и доступное решение, которое может обеспечить надежную защиту данных несколькими способами.

    • С помощью NAKIVO Backup & Replication вы можете выполнять собственное резервное копирование на основе образов с учетом приложений для виртуальных машин VMware, Hyper-V, Nutanix AHV, экземпляров AWS EC2 и физических серверов Windows и Linux.Режим с учетом приложений гарантирует, что данные вашего приложения и базы данных останутся транзакционно непротиворечивыми. NAKIVO Backup & Replication поддерживает Microsoft Exchange, MS Active Directory, MS SQL, Oracle и другие.
    • Функция резервного копирования может добавить дополнительный уровень защиты от неожиданного повреждения данных, сбоя системы или аварии. Вы можете создавать копии существующих резервных копий и отправлять их за пределы офиса или в общедоступные облака. Кроме того, вы можете создать зеркальную копию репозитория резервных копий или оптимизировать весь процесс резервного копирования.
    • Поставьте свои действия по защите данных на автопилот, используя защиту данных на основе политик. Вы можете создать несколько правил защиты данных на основе имени, размера, местоположения, конфигурации, состояния питания, тега или комбинации этих параметров виртуальной машины. Эти правила политики могут регулярно сканировать вашу инфраструктуру, выявлять виртуальные машины, соответствующие заданным правилам, и автоматически добавлять их в соответствующие задания по защите данных.
    • Автоматизируйте и организуйте процесс аварийного восстановления от начала до конца с помощью рабочих процессов восстановления сайта.Объединив различные действия и условия в автоматизированный алгоритм, вы можете создать несколько заданий по восстановлению сайта для решения различных аварийных ситуаций. Более того, вы можете тестировать и обновлять задания восстановления сайта, когда это необходимо, не нарушая производственную среду.
    • NAKIVO Backup & Replication предлагает несколько вариантов восстановления, позволяя мгновенно восстанавливать виртуальные машины, файлы и объекты приложений непосредственно из сжатых и дедуплицированных резервных копий. Вы также можете восстанавливать виртуальные машины VMware в среду Hyper-V и наоборот с помощью межплатформенного восстановления.Более того, NAKIVO Backup & Replication позволяет восстанавливать физические машины на виртуальные машины VMware или Hyper-V, обеспечивая восстановление практически при любых обстоятельствах.

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

    Реализация отказоустойчивого кластера в Windows Server 2019

    Современные ИТ-среды «всегда активны» и «всегда доступны» требуют высокодоступной инфраструктуры.Проще говоря, вы не хотите иметь единую точку отказа в критически важной для бизнеса инфраструктуре. Если это так, то быстро становится очевидным, что вы настолько хороши, насколько хороши ваши самые слабые звенья. Избыточность должна существовать во всей среде, включая вашу физическую инфраструктуру и приложения.

    Когда дело доходит до ваших хостов, на которых работают приложения и службы, вы хотите убедиться, что у вас есть несколько хостов, которые могут обеспечить избыточность в случае сбоя одного из ваших хостов. Это верно, когда у вас есть хосты, на которых запущены такие приложения, как MS SQL Server, или если у вас есть хосты, которые служат виртуальными хостами для ваших виртуализированных сред.

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

    Windows Server 2019 — это самый передовой на сегодняшний день Windows Server; поскольку он предоставляет самые передовые функции с точки зрения возможностей аварийного переключения Windows. В этой статье давайте рассмотрим отказоустойчивую кластеризацию Windows в целом. Что это такое? Что такое отказоустойчивый кластер Hyper-V? Как они работают? Что нового в отказоустойчивом кластере Windows Server 2019 и во всех вариантах его использования? а также реализацию отказоустойчивого кластера Windows в Windows Server 2019.

    Что такое отказоустойчивая кластеризация Windows?

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

    Что такое отказоустойчивый кластер?

    Отказоустойчивый кластер в Windows Server — это группа независимых узлов, которые работают вместе как единая логическая единица для повышения доступности и масштабируемости ролей и служб, работающих поверх отказоустойчивого кластера; это может быть известное приложение, такое как MS SQL Server, или специальные роли виртуализации, такие как Hyper-V.

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

    Отказоустойчивый кластер Hyper-V

    Проще говоря, группа похожих серверов Hyper-V/Windows Server с включенными ролями Hyper-V, подключенными и работающими вместе, чтобы сбалансировать ситуацию, когда один из подключенных серверов, на котором запущено какое-либо приложение, служба или роль, выходит из строя. вниз или терпит неудачу; серверы Hyper-V в технических терминах называются узлами.

    Рабочий механизм отказоустойчивого кластера

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

    Отказоустойчивые кластеры

    предоставляют еще один чрезвычайно мощный механизм хранения под названием Cluster Shared Volume (CSV) . CSV позволяет предоставлять общее хранилище между узлами кластера, чтобы обеспечить согласованное распределенное пространство имен для доступа к общему хранилищу со всех узлов. Это также обеспечивает необходимую функциональность мультиподключенного хранилища для машин Hyper-V.

    Quorum в отказоустойчивой кластерной конфигурации — это специальный механизм голосования, помогающий предотвратить ситуацию, называемую split-brain .

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

    Подробнее: Общие сведения о кворуме в отказоустойчивом кластере

    Что нового в отказоустойчивом кластере Windows Server 2019?

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

    Давайте проверим:

    1. Наборы кластеров . Одной из замечательных новых функций решения для программно-определяемого центра обработки данных Windows Server 2019 является возможность формирования наборов кластеров.
    2. Что такое набор кластеров? — слабосвязанная группа из нескольких отказоустойчивых кластеров, включая вычислительную инфраструктуру, хранилище и гиперконвергентную инфраструктуру, которая позволяет перемещать виртуальные машины между кластерами и различными наборами кластеров.

    3. Кластеры с поддержкой Azure — Майкрософт упрощает выполнение рабочих нагрузок в среде Azure IaaS. Благодаря кластерам с поддержкой Azure отказоустойчивые кластеры Windows теперь могут обнаруживать, когда они работают в Azure. Когда они работают в среде Azure IaaS, они автоматически оптимизируются, чтобы обеспечить упреждающую отработку отказа и ведение журнала событий запланированного обслуживания Azure и т. д. Кроме того, вам больше не нужно настраивать балансировщик нагрузки с динамическим сетевым именем.
    4. Междоменная миграция кластера — Отказоустойчивые кластеры Windows, работающие поверх Windows Server 2019, теперь можно перемещать между разными доменами Active Directory. Это долгожданная функция для отказоустойчивых кластеров Windows, которая открывает множество возможностей и облегчает проблемы консолидации доменов, слияний и т. д.
    5. USB-свидетель — с конфигурацией USB-свидетеля, отказоустойчивым кластером Windows с двумя узлами, вы можете использовать простое USB-устройство, подключенное к обычному сетевому устройству, такому как маршрутизатор и т. д., чтобы предоставить компонент-свидетель для кворума, это называется true two-node .
    6. Улучшения инфраструктуры кластера — в Windows Server 2019 кэш CSV включен по умолчанию для повышения производительности виртуальных машин, работающих на общих томах кластера. Кроме того, были внесены улучшения, позволяющие отказоустойчивому кластеру Windows иметь больше возможностей и логики для обнаружения проблем с кластером и его автоматического устранения. Это включает в себя разделенные узлы и использование обнаружения сетевого маршрута.
    7. Обновление с учетом кластера поддерживает Storage Spaces Direct . Большим улучшением отказоустойчивых кластеров Windows в Windows Server 2012 стала функция обновления с учетом кластера.Это автоматизирует процесс применения обновлений программного обеспечения на кластерных серверах, сохраняя при этом доступность ролей, размещенных в кластере. Эта функция улучшалась с каждым выпуском Windows Server. Теперь в Windows Server 2019 функция CAU распознает и интегрируется с Storage Spaces Direct (S2D). Эта функция управляет перезапусками всех серверов в кластере для операций обслуживания, включая обновления.
    8. Усовершенствования файлового ресурса-свидетеля . В Windows Server 2019 реализованы новые усовершенствования, улучшения и отказоустойчивость файлового ресурса-свидетеля.Это включает в себя использование файлового ресурса-свидетеля в удаленных местах с плохим подключением к Интернету, отсутствие общих дисков, отсутствие контроллера домена, например, в демилитаризованной зоне, рабочей группе или междоменных кластерах, а также блокировку общих файловых ресурсов DFS.
    9. Повышение безопасности кластера — связь внутри кластера по SMB для томов CSV и S2D использует сертификаты, чтобы сделать связь максимально безопасной и устранить зависимость от New Technology LAN Manager (NTLM) .
    10. Отказоустойчивый кластер больше не использует проверку подлинности NTLM — NTLM ушла на второй план с проверкой подлинности отказоустойчивого кластера Windows Server 2019.В Windows Server 2019 отказоустойчивые кластеры используют исключительно Kerberos и проверку подлинности на основе сертификатов.

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

    Предварительные условия для установки отказоустойчивой кластеризации Windows

    Перед установкой функционального компонента Windows необходимо выполнить предварительные требования.Что это? Microsoft обычно отмечает следующее в качестве предварительных требований для установки функции отказоустойчивой кластеризации Windows и компонентов, характерных для Hyper-V:

    .
    • Установите одну и ту же версию Windows Server для всех узлов отказоустойчивого кластера
    • Наличие серверов с такой же или похожей конфигурацией оборудования
    • Убедитесь, что компоненты хранилища и сети подходят для подключений и т. д.
    • Общее хранилище. Для отказоустойчивого кластера требуется общее хранилище в виде локальных дисковых пространств (S2D) или общего хранилища.Общее хранилище может быть традиционным общим хранилищем через устройства SAN с целями iSCSI и NFS, а также с новыми программно-определяемыми подходами, такими как Storage Spaces Direct.
    • Подключенное хранилище должно содержать несколько физических дисков, настроенных таким образом, чтобы обеспечить избыточность. Некоторые конфигурации могут использовать диск или логическое хранилище в качестве диска-свидетеля
    • .
      • Поддерживаются базовые, а не динамические диски
      • С общими томами кластера используйте NTFS — с S2D рекомендуется использовать ReFS
    • Специально для программно-определяемых решений Windows Failover Cluster (т.е. Storage Spaces Direct и т. д.), используйте аппаратные решения
    • , сертифицированные WSSD.
    • Если вы используете специализированные отказоустойчивые кластеры Windows, такие как Storage Spaces Direct (S2D), вам следует обратить пристальное внимание на требования к оборудованию, поскольку у S2D очень специфические требования
    • Для конкретных кластеров Hyper-V серверы кластера должны поддерживать требования к оборудованию для роли Hyper-V, включая наличие процессоров с аппаратной виртуализацией. Сюда входит технология виртуализации Intel (Intel VT) или технология виртуализации AMD (AMD-V).Кроме того, должна быть включена аппаратная реализация DEP.

    Как реализовать отказоустойчивую кластеризацию в Windows Server?

    В следующем пошаговом руководстве давайте рассмотрим реализацию отказоустойчивой кластеризации в Windows Server 2019. Это включает в себя несколько следующих шагов:

    • Установка одной и той же версии Windows Server и исправлений как минимум на двух узлах отказоустойчивого кластера.
    • Выбор кластеров, присоединенных к домену, нескольких доменов или рабочих групп.
    • Настройка общего хранилища между узлами отказоустойчивого кластера.
    • Установка функции отказоустойчивого кластера и служб ролей, которые вы хотите кластеризовать (Hyper-V и т. д.).
    • Проверка конфигурации кластера.
    • Создание отказоустойчивого кластера.
    • Настройка кворума.

    Вы можете найти краткие пояснения к вышеуказанным шагам в следующих разделах:

    1. Установите Windows Server 2019 и исправления

      Давайте пропустим момент установки Windows Server, так как мы уже установили Windows Server 2019 на два хоста отказоустойчивого кластера.Важно отметить, что вы хотите убедиться, что узлы вашего отказоустойчивого кластера работают под управлением одной и той же версии Windows Server, а также имеют одинаковый уровень исправлений. Это гарантирует, что все между хостами работает согласованно, и между вашими узлами не будет непредвиденного поведения или расхождений.

      Убедитесь, что на узлах отказоустойчивого кластера установлена ​​та же версия Windows и один и тот же уровень исправлений.

    2. Присоединиться к домену Active Directory?

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

      Начиная с Windows Server 2016 и расширенной до 2019, вы можете иметь кластеры, присоединенные к домену, междоменные соединения (многодоменные) или кластеры рабочих групп. Для практического пошагового руководства мы используем типичную конфигурацию кластера, присоединенного к домену. Просто обратите внимание на другие опции, которые теперь доступны.

      Оба узла кластера присоединены к домену.

    3. Общее хранилище

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

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

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

      Щелкните правой кнопкой мыши имя отказоустойчивого кластера в диспетчере отказоустойчивого кластера > Дополнительные действия > Настроить параметры кворума кластера.

      Назначение кворума вручную

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

    4. Установка Hyper-V и других ролей в кластер

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

      • Install-WindowsFeature -Name Hyper-V -IncludeAllSubFeature-IncludeManagementTools -Restart

      Установка роли Hyper-V на узлы отказоустойчивого кластера

    5. Установка функции отказоустойчивой кластеризации

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

      .
      • Install-WindowsFeature – Name Failover-Clustering – IncludeManagementTools

      Установите компонент отказоустойчивой кластеризации.

    6. Тестирование конфигурации отказоустойчивого кластера

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

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

      Используя средство проверки кластера для проверки конфигурации отказоустойчивого кластера,
      вы также можете использовать PowerShell для запуска проверки потенциальных узлов отказоустойчивого кластера.

      Запуск командлета Test-Cluster для узлов вашего кластера перед созданием отказоустойчивого кластера.

      Процесс проверки создает отчет, расположенный на узле кластера, с которого он выполнялся. Отчет о проверке создается в каталоге C:\Windows\Cluster\Reports на узле отказоустойчивого кластера.

      Просмотр созданного отчета о проверке

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

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

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

      После проверки конфигурации кластера и устранения обнаруженных проблем можно приступить к созданию отказоустойчивого кластера.Создание отказоустойчивого кластера Windows Server легко выполняется в PowerShell:

      .
      • New-Cluster -Name HyperVCluster -node , -staticAddress

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

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

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

    Заключительные мысли

    Отказоустойчивые кластеры Windows Server

    представляют собой очень надежную и отказоустойчивую платформу для запуска критически важных бизнес-приложений и служб.С каждым выпуском платформы Windows Server отказоустойчивые кластеры продолжали совершенствоваться. А в выпуске Windows Server 2019 реализована самая многофункциональная отказоустойчивая кластерная платформа на сегодняшний день.

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

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

    В Vembu BDR Suite, даже когда ваши виртуальные машины перемещаются на другой хост Hyper-V, резервные копии будут продолжать работать без перебоев. Резервное копирование Vembu для Microsoft Hyper-V, используемое в сочетании со встроенными функциями высокой доступности в Hyper-V, обеспечивает доступность данных для ваших производственных рабочих нагрузок Hyper-V даже во время аварий.

    Vembu BDR Suite представляет собой очень надежное решение для резервного копирования с функциями корпоративного класса для эффективной защиты ваших кластеров Hyper-V по удивительной цене.Загрузите бесплатную полнофункциональную пробную версию Vembu BDR Suite.

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

    Как создать отказоустойчивый кластер в Windows Server 2019

    В этом блоге мы научимся создавать отказоустойчивый кластер Microsoft Windows с Windows Server 2019. Среда может представлять собой двухузловой кластер с одним общим диском.

    Сведения о среде:

    SRV2019-DC

                                10.0.0.0

    SRV2019-1

    Primary — 10.0.0.30

    Cluster — 192.168.0.10

    SRV2019-2

    Основное: 10.0.0.40

    Cluster: 192.168.0.20

    ISCSI Хранение: 10.0.0.100

    Имя кластера — XTCLUSTER

    IP-адрес кластера — 10.0.0.110

    1- Прежде чем мы начнем, убедитесь, что выполняются следующие предварительные условия:
    У меня есть 2 компьютера с Windows Server 2019 с установленными последними обновлениями. У машин как минимум два сетевых интерфейса, я их переименовываю в Primary и Cluster.

    Присоедините оба сервера к вашему домену Microsoft Active Directory и убедитесь, что оба сервера видят общее устройство памяти, доступное в управлении дисками. Так что пока не подключайте диск к сети.

    2- Используйте следующую команду PowerShell, чтобы включить отказоустойчивый кластер и управление узлом Toole 1 (SRV2019-1)

    Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools

    Failover Cluster Server 2019

    (СРВ2019-2).

    3- Откройте «Управление сервером», выберите панель инструментов и нажмите «ДОБАВИТЬ роли и функции».

    4- Итак, нажмите «Далее».

    5- Щелкните Установка на основе ролей или компонентов, а затем щелкните Далее.

    6- Выберите сервер из пула серверов и нажмите «Далее».

    7- Итак, нажмите «Далее».

    8- Выберите Отказоустойчивая кластеризация.

    9- Щелкните Добавить функции.

    10- После включения функции отказоустойчивой кластеризации нажмите «Далее».

    11- Затем нажмите «Установить».

    12- Успешно включите функцию отказоустойчивого кластера, поэтому нажмите «Закрыть».

    13- После успешной установки он появится в Диспетчере сервера, щелкните Инструменты, а затем Диспетчер отказоустойчивого кластера.

    После того, как вы установили функцию отказоустойчивой кластеризации, вы можете подключить общий диск к сети и отформатировать его на одном из серверов 1 Node (SRV2019-1).

    Следующие шаги выполняются на узле 1 (SRV2019-1).

    14- В диспетчере серверов щелкните Инструменты, а затем щелкните Управление компьютером.

    15- Нажмите «Управление дисками».

    Вы увидите диск 1, который находится в автономном режиме. Щелкните правой кнопкой мыши диск 1 и выберите «Онлайн».

    16- Щелкните правой кнопкой мыши диск 1 и выберите Инициализировать диск.

    17- Нажмите OK.

    18- Щелкните правой кнопкой мыши нераспределенный диск 1 и выберите «Новый простой том».

    19- Нажмите Далее.

    20- Нажмите Далее.

    21- Назначьте букву диска и нажмите «Далее».

    22- Введите метку тома и нажмите «Далее».

    23- Нажмите Готово.

    24- 1-й узел (SRV2019-1) Управление дисками (статус диска в сети)

    25- Пожалуйста, ничего не меняйте на 2-м -м узле (SRV2019-2), диск остается в автономном режиме. 2 ND Узел (SRV2019-2) Управление дисками (состояние диска в автономном режиме).

    Проверка готовности отказоустойчивого кластера 1 узел (SRV2019-1).


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

    26- В диспетчере серверов щелкните Инструменты и выберите Диспетчер отказоустойчивого кластера.

    27- В меню «Действие» нажмите «Проверить конфигурацию».

    28- Нажмите Далее.

    29- Нажмите кнопку обзора.

    30- Введите имя узла, нажмите «Проверить имя» и нажмите «ОК».

    31- После выбора двухузловых серверов для проверки нажмите «Далее».

    32- Выберите «Выполнить все тесты» (рекомендуется) и нажмите «Далее».

    33- Просмотрите подтверждение проверки конфигурации и нажмите «Далее».

    34 — Выполняется проверка кластера.

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

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

    36- В меню действий выберите «Создать кластер».

    37- Нажмите Далее.

    38- Нажмите кнопку обзора.

    39- Введите имена обоих узлов, нажмите «Проверить имена» и нажмите «ОК».

    40- Оба выбранных узла серверов, нажмите «Далее».

    41- Введите имя кластера, выберите IP-адрес и нажмите «Далее».

    42- В качестве последнего шага подтвердите все, нажмите «Далее» и дождитесь создания кластера.

    43- Настройка кластера успешно завершена, нажмите «Готово».

    44- Мастер автоматически добавит общий диск в кластер по умолчанию. Если вы его еще не настроили, то можно и потом. В результате вы увидите новый компьютерный объект Active Directory с именем XTCLUSTER.

    45- Вы можете пропинговать новый компьютер, чтобы проверить, находится ли он в сети (если вы разрешите ping на брандмауэре Windows).

    В качестве альтернативы вы также создадите кластер с помощью PowerShell. следующая команда также автоматически добавит все подходящие хранилища:

    New-Cluster -Name XTCLUSTER -Node SRV2019-1, SRV2019-2 -StaticAddress 10.

Добавить комментарий

Ваш адрес email не будет опубликован.