Растянутый кластер что это
Настройка растянутого кластера (stretch-cluster) на Windows server 2016
В данной статье мы рассмотрим как настроить отказоустойчивый растянутый кластер на базе Windows Server 2016.
В нашем сценарии кластер будет растянут между двумя дата центрами, при этом между хранилищами с помощью технологии storage replica будет настроена репликация данных.
Предположим у нас есть 2 сайта, в одном ДЦ у нас будет 2-е активные ноды кластера, в другом 2-е запасные, на случай отказа основного ДЦ.
Перед настройкой серверов убедимся что мы соблюдаем следующие условия:
Используется лес доменных служб Active Directory (использовать Windows Server2016 не обязательно).
Есть минимум два сервера с установленным выпуском Windows Server2016 Datacenter.
Хранилище должно содержать жесткий диск и твердотельный накопитель, а также поддерживать постоянное резервирование.
Доступ к каждому набору хранилищ нужно предоставить только для двух серверов (асимметричная конфигурация).
Каждый набор хранилищ должен допускать создание по меньшей мере двух виртуальных дисков: один для реплицируемых данных и один для журналов.
На всех дисках данных в физическом хранилище необходимо использовать одинаковый размер секторов. На всех дисках с журналами в физическом хранилище необходимо использовать одинаковый размер секторов.
На каждом сервере должно быть создано по меньшей мере одно подключение 1Гбит Ethernet для синхронной репликации, но желательно использовать RDMA.
Правила всех задействованных брандмауэров и маршрутизаторов должны разрешать двунаправленный трафик ICMP, SMB (порт 445, а также 5445 для SMB Direct) и WS-MAN (порт 5985) между всеми узлами.
Сеть между серверами должна иметь достаточную пропускную способность для ваших рабочих нагрузок ввода-вывода, а средняя задержка приема-передачи должна составлять 5мс для синхронной репликации.
Для асинхронной репликации рекомендации по задержке приема и передачи отсутствуют.
При настройке я буду использовать следующие сервера расположенные в 2-х разных ДЦ (LA и Mexico)
Site Mexico:
m-srv-cl2
m-srv-cl1
Site LA:
l-srv-cl1
l-srv-cl2
Редакция Windows Server должна быть Datacenter Edition, если у вас редакция Standard выполните следующий Powershell скрипт:
После установки ролей Storage-Replica,Failover-Clustering,FS-FileServer перейдем к настройке дисков.
Подключите общее хранилище к каждому серверу внутри одного ДЦ
Соблюдайте следующие требования:
Необходимо создать два тома на каждой полке: один для данных и один для журналов.
Диски журналов и данных следует инициализировать как GPT, а не MBR.
Два тома данных должны иметь одинаковый размер.
Два тома журналов должны иметь одинаковый размер.
Все реплицируемые диски данных должны иметь одинаковый размер сектора.
Все диски журналов должны иметь одинаковый размер сектора.
Тома журналов должны использовать хранилище на базе флэш-памяти и параметры устойчивости, обеспечивающие высокую производительность.
Майкрософт рекомендует, чтобы хранилище журналов работало так же быстро или быстрее, чем хранилище данных.
Томы журнала никогда не должны использоваться для других задач.
В качестве дисков данных можно использовать жесткие диски, твердотельные накопители или их многоуровневое сочетание.
Диски можно организовать как зеркальные массивы, массивы с контролем четности, RAID1 или 10, RAID5 или RAID50.
Том журнала должен иметь размер по умолчанию не менее 9ГБ, но может отличаться как в большую, так и в меньшую сторону в зависимости от требований к ведению журнала.
Тома должны форматироваться с помощью файловой системы NTFS или ReFS.
Роль файлового сервера необходима только для работы Test-SRTopology, так как она открывает порты брандмауэра, необходимые для тестирования.
Для дисковых полок JBOD:
Убедитесь, что каждый набор узлов в парах серверов может видеть только дисковые полки своего сайта (асимметричное хранилище) и что подключения SAS правильно настроены.
Для хранилища iSCSI:
Убедитесь, что каждый набор узлов в парах серверов может видеть только дисковые полки своего сайта (асимметричное хранилище). При работе с iSCSI следует использовать несколько сетевых адаптеров.
Для хранилища Fibre Channel в сети SAN:
Убедитесь, что каждый набор узлов в парах серверов может видеть только дисковые полки своего сайта (асимметричное хранилище) и что правильно выбраны зоны узлов.
Подготовьте хранилище в соответствии с документацией поставщика.
Теперь зайдем на сервера в каждом ДЦ и по аналогии настроим общие диски, открываем консоль управления дисками и начинаем
Переводим диск в online
Инициализируем диск как GPT, это обязательное требование
Создаем новый раздел
Не назначаем букву диску
Форматируем диск в NTFS и задаем ему Label
Проделываем тоже самое на втором диске для логов.
Запускаем консоль cluadmin.msc и создаем новый кластер
Добавляем наши узлы кластера
Запускаем тестирование кластера и дожидаемся окончания проверки
Вводим имя кластера и подключаем доступные хранилища
Перейдем к настройке кворума
Выбираем quorum witness
В качестве кворума будем использовать сетевую шару
Далее просто укажите сетевой путь к шаре и завершите работу мастера.
Реакция на аварию: растянутый кластер против DR-площадки
У нас есть два подхода к Disaster Recovery: «растянутый» кластер (active-active-инсталляция) и площадка с выключенными виртуальными машинами (репликами). Они имеют несколько точек сохранения снэпшотов.
Запрос на катастрофоустойчивость есть, и многим нашим клиентам это реально нужно. Поэтому мы начали прорабатывать обе схемы в рамках нашего продакшна.
У методов есть плюсы и минусы, сейчас про них расскажу.
«Растянутый» кластер
Как видите, это стандартная история метрокластера. В плюсах — практически нулевой простой, пауза только на время запуска виртуальных машин. Отрабатывает такая фича — VMware High Availability (HA). Она видит, что хосты потерялись, и сразу же перезапускает ВМ на удалённой площадке.
Запуск делается сразу с СХД, которая находится в кластере.
СХД с геораспределённым кластером — это маркетинговая фича NetApp. У других производителей есть нечто с похожим названием. По сути, это продуманная асинхронная репликация с одной стороны на другую. Пишем на одну ноду в локальной сети и синхронизируем через специализированные каналы связи с другой.
В случае отказа одной из СХД оставшаяся (на другой площадке) презентует пути к дискам оставшимся же хостам. На них перезапускаются ВМ, которые погибли. Всё происходит автоматически — ЦОД грохнулся, всё перезагрузилось, СХД отработали, VMware отработала. Клиент увидел, что всё моргнуло и перезапустилось.
Единственное, кэш из оперативной памяти ВМ может потеряться. Но если база данных его скинула, то потеря нулевая по времени.
Если у нас теряется связь между площадками, то всё продолжает работать на своих местах и, как только связь восстанавливается, начинает синхронизироваться.
Минус — высокая цена. Потому что нужна фактически двойная СХД (причём аналогичная по типам, скорости и объёму дисков первой СХД на основной площадке), которую нельзя как-то использовать, кроме как под резерв. Плюс обвязка к СХД для метрокластера, это FC-бриджи, FC-сеть и прочее.
У нас два ЦОДа, между ними FC-связка по двум лучам (четыре линии тёмной оптики и DWDM). Это две железки, каждая обеспечивает по 200 Гбит пропускной способности для FC и Ethernet.
Альтернатива с DR
Есть софт с интуитивно запоминающимся названием — VMware vCloud Availability for Cloud-to-Cloud DR.
Это система создания идентичной ВМ на удалённой площадке раз, условно говоря, в 15 минут. К ней на изоленте примотана система презентации всего этого правильным образом в механизмы управления облаком.
То есть в бэкенде находится технология VMware Replication. В случае отказа мы вручную запускаем DR-план на второй площадке, он автоматически прекращает попытки реплицировать, затем регистрирует ВМ в vCloud Director, кастомизирует IP-адреса (чтобы не пришлось менять их на ВМ) и запускает ВМ в нужном порядке. В нашем решении менять адресацию не нужно, мы растягиваем сети на оба ЦОДа.
Машины реплицируются постоянно, но не весь ЦОД, а только выбранные — критичные процессы. Реплицируется раз в какое-то время, минимальный интервал — 15 минут (это идеальный случай, когда всё летает и есть выделенный сервер репликации и минимум изменений на ВМ). На практике у вас есть копия на полчаса или час назад. Если что-то пошло не так, то данные, которые попали в интервал, потерялись. 15 минут — это вопрос агента, который собирает новую репликацию. Veeam говорят, что могут меньше 15 минут, но по факту тоже на практике дольше, если не используют фичи СХД. Я не видел на промышленной машине (не на тесте), чтобы было иначе.
Уже давно у NetApp, как и у многих других производителей СХД, есть технология SnapMirror, которая позволяет переложить работу по репликации с гипервизоров на СХД, и VMware Replication умеет этим пользоваться.
Пока сервис репликации пробежит, поезд уходит далеко. Но зато это дёшево.
Почему ещё дёшево — потому что можно использовать любую СХД с любой стороны (от разных производителей, разного класса), не надо выделять заранее большой объём дисков.
Не надо выделять большую дисковую группу, внутри которой нарезаются луны. Просто берётся место на локальной СХД и применяется по факту наличия записи от виртуальной машины. За счёт этого оптимальнее занимается место на СХД, если она используется под другие задачи. А она используется, так как мы не всем клиентам даём такую услугу.
Минус — надо настраивать репликацию на уровне ВМ, то есть контролировать, что всё верно настроено, что это та машина, следить за тем, что репликация проходит, что ошибок нет. Создавать DR-планы для каждого клиента, проводить их испытания.
В первом случае СХД берётся, условно, инфраструктурно, чуть ли не по секторам (точнее, по объектам). А тут одна машина может отвалиться по причине отваливания задачи из-за каких-то софтверных причин, связанных с багом на высоких уровнях, или из-за проблем с доступностью. Это случается чуть чаще, чем если брать именно низкие уровни.
В плюсе — DR хранит несколько точек. Можно откатиться на несколько снепшотов назад.
Снаружи от гостевых ОС нужен дополнительный софт.
Чтобы до Vcloud Director прокинуть все нужные сети, нужна работа нашего администратора. Вообще, вся сетевая связность в этом варианте остаётся на нашем администраторе. Для клиента облака это означает заявку, что тоже занимает время.
Репликация настраивается тоже через заявку. Добавил ВМ — надо отправить заявку, что необходимо её реплицировать. Автоматом она в задачи по репликации не попадёт. Нужно уделять внимание админу.
Разница
В итоге цена может отличаться больше чем в два раза. Репликация будет умножать стоимость дискового пространства на два и больше (две полные копии + история изменений), плюс что-то за сервис и резервацию вычислительных ресурсов. В случае с метрокластером стоимость пространства будет умножаться на два, но само пространство будет стоить значительно дороже, плюс надо жёстко резервировать узлы на удалённой площадке. То есть и вычислительные ресурсы должны умножаться на два, мы их не можем утилизировать под что-то ещё.
В случае с метрокластером мы можем использовать только одинаковые типы дисков, чтобы было полное зеркало. Если на основном ЦОДе часть дисков быстрые, часть медленные на 10 тысяч оборотов в минуту, то нужна идентичная конфигурация. В случае реплики возможны более медленные диски на резервной площадке, а это дешевле за счёт хранения. Но при переключении на резерв он окажется по производительности меньше. То есть если он что-то хранит на SSD в основном кластере, а реплицируется на обычные диски, то хранение будет значительно дешевле ценой замедления инфраструктуры резерва.
Прямо сейчас мы выбираем то, что войдёт в более ранний релиз, поэтому хотим посоветоваться: можете коротко рассказать, как вы организуете свои DR-площадки и что бы от них хотели вообще в целом?
Общие сведения о растянутых кластерах
Область применения: Azure Stack ХЦИ, версии 21H2 и 20H2
Отказоустойчивое решение кластера Azure Stack ХЦИ для аварийного восстановления обеспечивает автоматический переход на другой ресурс для быстрого восстановления рабочей среды и без необходимости вмешательства вручную. служба хранилища реплика обеспечивает репликацию томов между сайтами для аварийного восстановления, при этом все серверы синхронизируются.
служба хранилища реплика поддерживает как синхронную, так и асинхронную репликацию:
Для асинхронной репликации необходимо вручную перенести целевые тома с другого сайта в оперативный режим после отработки отказа. Дополнительные сведения см. в разделе асинхронная репликация.
Существует два типа растянутых кластеров: «активный — пассивный» и «активный — активный». Можно настроить репликацию на уровне «активный — пассивный», где есть предпочитаемый сайт и направление репликации. Репликация «активный — активный» заключается в том, где репликация может выполняться в двунаправленном режиме с любого сайта. В этой статье рассматривается только конфигурация «активный/пассивный».
Проще говоря, Активный сайт — это тот, который содержит ресурсы и предоставляет роли и рабочие нагрузки для подключения клиентов. Пассивный сайт — это тот, который не предоставляет никаких ролей или рабочих нагрузок для клиентов и ожидает отработки отказа с активного сайта для аварийного восстановления.
Сайты могут находиться в двух разных штатах, в разных городах, в разных этажах или в разных комнатах. Растянутые кластеры, использующие два сайта, обеспечивают аварийное восстановление и непрерывность бизнес-процессов в случае сбоя или отказа сайта.
Потратьте несколько минут, чтобы просмотреть видео о растянутой кластеризации с Azure Stack ХЦИ:
Активный-пассивный Растянутый кластер
На следующей схеме показан сайт 1 в качестве активного сайта с репликацией на сайт 2, однонаправленная репликация.
Активный-активный кластер с растяжением
На следующей схеме показаны сайт 1 и сайт 2 как активные сайты с двунаправленной репликацией на другой сайт.
Вопросы отработки отказа гостевой IP-адреса
Если речь идет о растянутой кластеризации, необходимо учитывать, что виртуальные машины и используемые IP-адреса должны быть учетными записями. Центры обработки данных, расположенные в разных расположениях, обычно имеют разные IP-подсети. IP-адреса, используемые виртуальными машинами, хорошо подходят для одного центра обработки данных, но недоступны в другом. Поэтому планирование работы с изменениями IP-адресов необходимо учитывать для. В большинстве случаев существует четыре разных способа обработки изменения IP-адреса на виртуальной машине при отработке отказа. Могут быть другие, но в этом документе будут рассмотрены первые четыре.
Первый и самый простой способ — использование DHCP. При перемещении виртуальной машины с одного сайта на другой один шаг, который будет выполнен, запрашивает DHCP-адрес. При этом будет получен правильный IP-адрес для соответствующего сайта, пока доступен DHCP-сервер.
Далее используется статический адрес. Однако, в отличие от реплики Hyper-V, не существует способа указать альтернативный IP-адрес. Поэтому необходимо создать сценарий, чтобы назначить правильный IP-адрес для виртуальной машины в зависимости от того, на каком сайте он находится. Например, сайт a использует сеть 1. x, а Ситеб использует сеть 156. x. Этот сценарий должен определить сеть, в которой находится виртуальная машина, и установить схему IP-адресов 1. x, если она находится на сайте a или в схеме IP-адреса «156. x», если она находится в Ситеб. Службы доменных имен (DNS) также должны быть осведомлены об изменениях и репликации между сайтами.
Другим вариантом является использование промежуточного сетевого устройства, предоставляющего один IP-адрес для виртуальной машины для подключения клиентов, который может направить трафик на виртуальную машину на сайт, на котором она сейчас находится. Клиенты и DNS всегда будут иметь один и тот же адрес для виртуальной машины, и промежуточное устройство должно будет отправлять фактический IP-адрес и расположение виртуальной машины, чтобы клиенты направлялись на виртуальную машину соответствующим образом.
Последний вариант — использование растянутой виртуальной ЛС. При использовании растянутой виртуальной ЛС виртуальные машины могут иметь один и тот же IP-адрес независимо от того, на каком сайте он находится. Однако из-за некоторых сложностей, связанных с настройкой и обслуживанием растянутой виртуальной ЛС, этот вариант не рекомендуется корпорации Майкрософт.
При использовании любого из перечисленных выше параметров необходимо учитывать дополнительные моменты (DNS, кэши ARP, TTL и т. д.). необходимо учитывать, когда дело доходит до подключения клиентов и должно быть тщательно продумано. Обратитесь к группе работы с сетью, чтобы узнать наилучший вариант в соответствии с вашими потребностями.
Репликация растянутого кластера с помощью общего хранилища
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
В этом примере оценки вы настроите компьютеры и их хранилища в одном растянутом кластере, где два узла будут совместно использовать один набор хранилищ и еще два узла — другой набор хранилищ. Затем будет выполнено зеркалирование обоих наборов хранилищ в кластере путем репликации, чтобы обеспечить немедленную отработку отказа. Эти узлы и соответствующие хранилища желательно расположить на различных физических сайтах, но это не является обязательным требованием. Здесь приведены отдельные шаги для создания кластеров Hyper-V и файлового сервера в рамках примеров сценариев.
В этой оценке серверы на различных сайтах должны взаимодействовать с другими серверами через сеть и не должны быть подключены к общему хранилищу другого сайта с помощью физических средств. В этом сценарии не используются локальные дисковые пространства.
Вы также можете использовать решение Azure Stack ХЦИ для реализации растянутых кластеров. Дополнительные сведения см. в разделе Общие сведения о растянутых кластерах в Azure Stack хЦи.
Термины
В этом пошаговом руководстве в качестве примера используется следующая среда:
четыре сервера с именами SR-SRV01, SR-SRV02, SR SRV03 и SR-SRV04, объединенные в один кластер с именем SR-SRVCLUS;
пара логических «сайтов», представляющих два разных центра обработки данных, один из которых называется Redmond, а второй — Bellevue.
Можно использовать только два узла. При этом на каждом сайте используется по одному узлу. Тем не менее невозможно выполнить отработку отказа внутри сайта, используя только два сервера. Можно использовать до 64 узлов.
рис. 1. репликация служба хранилища в растянутом кластере
Предварительные требования
хотя можно подключить устройство хранения к одному серверу и использовать его для репликации, Windows отказоустойчивая кластеризация по-прежнему использует постоянные резервирования SCSI. поэтому хранилище по-прежнему должно быть общим типом служба хранилища, таким как технология SAN. Локальные диски или диски, представленные гипервизором, могут быть несовместимыми. в Azure диски должны иметь размер SSD (цен. категория «Премиум»), который поддерживает общий доступ, даже если к ней будет присоединена только одна виртуальная машина.
Подготовка операционной системы, функций, ролей, хранилища и сети
установите Windows server на всех узлах сервера, используя параметры установки server Core или server с возможностями рабочего стола.
С этого момента вход в систему всегда нужно выполнять от имени пользователя домена, входящего в группу встроенной учетной записи администратора на всех серверах. Не забывайте повысить полномочия командных строк PowerShell и CMD, запуская их через графический интерфейс на компьютере с ОС Windows 10.
Добавьте сведения о сети и присоедините узлы к домену, а затем перезапустите их.
Начиная с этого этапа в руководстве предполагается, что у вас есть две пары серверов для использования в растянутом кластере. Глобальная или локальная сеть разделяет серверы, принадлежащие к физическим или логическим сайтам. Здесь также предполагается, что сервер SR-SRV01 и SR-SRV02 находятся на узле Redmond, а SR-SRV03 и SR SRV04 — на узле Bellevue.
Подключите первый набор общих хранилищ (дисковую полку JBOD, общий диск VHDX, цель iSCSI или Fibre Channel SAN) к серверам на сайте Redmond.
Подключите второй набор хранилищ к серверу на сайте Bellevue.
Установите на всех четырех узлах, насколько применимо, все последние версии встроенного ПО и драйверов, предоставляемых поставщиками для полки дисков, HBA, BIOS или UEFI, для сетевых адаптеров и для набора микросхем материнской платы. Перезапустите узлы при необходимости.
Для настройки общих хранилищ и сетевого оборудования обратитесь к документации поставщика оборудования.
Убедитесь, что для параметров BIOS или UEFI настроена высокая производительность, например отключено C-состояние, установлена скорость QPI, включена архитектура NUMA и установлена максимально возможная частота памяти. Убедитесь, что для управления питанием в Windows Server выбрана схема высокой производительности. При необходимости перезагрузите компьютер.
Настройте роли следующим образом.
Графический интерфейс
Запустите ServerManager.exe и добавьте все узлы сервера, щелкнув Управление и Добавление серверов.
Установите роли и компоненты отказоустойчивой кластеризации и реплики хранилища на всех узлах и перезапустите их. Если планируется использовать другие роли, например Hyper-V, файловый сервер и т. д., их также можно установить.
Использование метода с Windows PowerShell
На сервере SR-SRV04 или на компьютере удаленного управления выполните следующую команду в консоли Windows PowerShell, которая установит все необходимые компоненты и роли для растянутого кластера на четырех узлах и перезапустит их:
Дополнительные сведения об этих действиях см. в статье Установка и удаление ролей, служб ролей и компонентов.
Настройте хранилище следующим образом:
Полки дисков JBOD
Убедитесь, что каждый набор узлов в парах серверов может видеть только дисковые полки своего сайта (асимметричное хранилище) и что подключения SAS правильно настроены.
Подготовьте хранилище с помощью дисковых пространств, выполнив шаги 1–3 из статьи Развертывание дисковых пространств на автономном сервере с помощью Windows PowerShell или диспетчера сервера.
Для хранилища iSCSI:
Убедитесь, что каждый набор узлов в парах серверов может видеть только дисковые полки своего сайта (асимметричное хранилище). При работе с iSCSI следует использовать несколько сетевых адаптеров.
Подготовьте хранилище в соответствии с документацией поставщика. При использовании целей iSCSI для Windows изучите статью Блочное хранилище конечного сервера iSCSI, краткое руководство.
Для хранилища Fibre Channel в сети SAN:
Убедитесь, что каждый набор узлов в парах серверов может видеть только дисковые полки своего сайта (асимметричное хранилище) и что правильно выбраны зоны узлов.
Подготовьте хранилище в соответствии с документацией поставщика.
Настройте отказоустойчивый кластер Hyper-V или кластерный файловый сервер для общего использования.
После настройки узлов сервера создайте кластер одного из следующих типов:
Настройка отказоустойчивого кластера Hyper-V
Теперь создадим обычный отказоустойчивый кластер. После настройки, проверки и тестирования он будет растянут с помощью реплики хранилища. вы можете выполнить все приведенные ниже действия на узлах кластера напрямую или на удаленном компьютере управления, содержащем средства удаленного администрирования сервера Windows Server.
Графический интерфейс
Запустите Cluadmin. msc.
Проверьте предложенный кластер и проанализируйте результаты, чтобы убедиться, что можно продолжить.
Из-за использования асимметричного хранилища при проверке кластера могут возникнуть ошибки хранилища.
Создайте вычислительный кластер Hyper-V. Убедитесь, что имя кластера содержит не более 15 символов. В примере ниже использован кластер SR-SRVCLUS. Если узлы будут находиться в разных подсетях, необходимо создать IP-адрес для имени кластера для каждой подсети и использовать зависимость «или». Дополнительные сведения можно найти в разделе Настройка IP-адресов и зависимостей для кластеров с несколькими подсетями. часть III.
Настройте файловый ресурс-свидетель или облако-свидетель для предоставления кворума в случае потери сайта.
WIndows Server теперь включает параметр для следящего сервера, основанного на облаке (Azure). Можно выбрать этот вариант кворума вместо файлового ресурса-свидетеля.
Просмотрите статью Network Recommendations for a Hyper-V Cluster in Windows Server 2012 (Рекомендации в отношении сети для кластера Hyper-V в Windows Server 2012) и убедитесь, что сеть кластера настроена оптимально.
Добавьте один диск сайта Redmond к кластеру CSV. Для этого щелкните правой кнопкой мыши исходный диск в узле Disks (Диски) раздела Storage (Хранилище) и нажмите кнопку Add to Cluster Shared Volumes (Добавить к общим томам кластера).
Выполните шаги 7–10 в руководстве Deploy a Hyper-V Cluster (Развертывание кластера Hyper-V) на сайте Redmond, чтобы создать тестовую виртуальную машину. Это нужно только для того, чтобы обеспечить нормальную работу кластера с двумя узлами, которые совместно используют хранилище на первом тестовом сайте.
Это ожидаемое поведение в Windows Server 2016.
Например, для проверки двух предложенных узлов растянутого кластера, в которых есть тома D: и E:, и выполнения тестирования в течение 30 минут:
Переместите все доступные хранилища на сервер SR-SRV01.
Щелкните команду Создать пустую роль в разделе Роли диспетчера отказоустойчивости кластеров.
Добавьте интернет-хранилище в пустую роль с именем Новая роль.
Переместите все доступные хранилища на сервер SR-SRV03.
Щелкните команду Создать пустую роль в разделе Роли диспетчера отказоустойчивости кластеров.
Переместите пустую роль Новая роль (2) на сервер SR-SRV03.
Добавьте интернет-хранилище в пустую роль с именем New Role (2) (Новая роль (2)).
Верните диски в доступное хранилище и удалите временные пустые роли.
После этого удалите тестовую виртуальную машину. Добавьте настоящие тестовые виртуальные машины, необходимые для дальнейшей оценки, в предложенный исходный узел.
Настройте доступность сведений о сайтах растянутого кластера таким образом, чтобы сервер SR-SRV01 и SR-SRV02 находились на сайте Redmond, SR-SRV03 и SR SRV04 — на сайте Bellevue, а сайт Redmond был предпочтительным для хранения узлов исходного хранилища и виртуальных машин.
Невозможно настроить доступность сведений о сайтах с помощью диспетчера отказоустойчивости кластеров в Windows Server 2016.
(Необязательно) Настройка сети кластера и Active Directory для ускорения отработки отказа сайта DNS. Для этого можно использовать программно-конфигурируемую сеть Hyper-V, распределенные виртуальные локальные сети, устройства для абстрагирования сети, сокращение срока жизни DNS и другие распространенные методы.
Чтобы получить дополнительные сведения, ознакомьтесь с материалами семинара конференции Microsoft Ignite Stretching Failover Clusters and Using Storage Replica in Windows Server vNext (Растягивание отказоустойчивых кластеров и использование реплики хранилища в Windows Server vNext) и записью блога Enable Change Notifications between Sites — How and Why? (Включение уведомлений об изменениях между сайтами: выполнение процесса и преимущества).
(Необязательно.) Настройте устойчивость виртуальной машины, чтобы работа гостей не прерывалась надолго во время сбоев узлов. Вместо этого будет выполняться отработка отказа с переключением на новое хранилище источника репликации за 10 секунд.
Нет возможности настроить устойчивость виртуальной машины с помощью диспетчер отказоустойчивости кластеров в Windows Server 2016.
Метод с Windows PowerShell
Протестируйте предложенный кластер и проанализируйте результаты, чтобы убедиться, что можно продолжить.
Из-за использования асимметричного хранилища при проверке кластера могут возникнуть ошибки хранилища.
Создайте файловый сервер для общего использования кластера хранилища (необходимо указать собственный статический IP-адрес, который будет использоваться кластером). Убедитесь, что имя кластера содержит не более 15 символов. Если узлы находятся в разных подсетях, необходимо создать IP-адрес для дополнительного сайта с помощью зависимости «или». Дополнительные сведения можно найти в разделе Настройка IP-адресов и зависимостей для кластеров с несколькими подсетями. часть III.
Настройте файловый ресурс-свидетель или облако-свидетель Azure в кластере, который указывает на общий ресурс, размещенный в контроллере домена или на другом независимом сервере. Например:
WIndows Server теперь включает параметр для следящего сервера, основанного на облаке (Azure). Можно выбрать этот вариант кворума вместо файлового ресурса-свидетеля.
Просмотрите статью Network Recommendations for a Hyper-V Cluster in Windows Server 2012 (Рекомендации в отношении сети для кластера Hyper-V в Windows Server 2012) и убедитесь, что сеть кластера настроена оптимально.
Это ожидаемое поведение в Windows Server 2016.
Выполните шаги 7–10 в руководстве Deploy a Hyper-V Cluster (Развертывание кластера Hyper-V) на сайте Redmond, чтобы создать тестовую виртуальную машину. Это нужно только для того, чтобы обеспечить нормальную работу кластера с двумя узлами, которые совместно используют хранилище на первом тестовом сайте.
После этого удалите тестовую виртуальную машину. Добавьте настоящие тестовые виртуальные машины, необходимые для дальнейшей оценки, в предложенный исходный узел.
Настройте распознавание сайта Stretch Cluster, чтобы серверы SR-SRV01 и SR-SRV02 были включены в сайт Redmond, SR-компьютера SRV03 и SR-SRV04 находятся в Бельвьюсайта, а Redmond является основным для владения узлами исходного хранилища и виртуальных машин.
(Необязательно) Настройка сети кластера и Active Directory для ускорения отработки отказа сайта DNS. Для этого можно использовать программно-конфигурируемую сеть Hyper-V, распределенные виртуальные локальные сети, устройства для абстрагирования сети, сокращение срока жизни DNS и другие распространенные методы.
Чтобы получить дополнительные сведения, ознакомьтесь с материалами семинара конференции Microsoft Ignite Stretching Failover Clusters and Using Storage Replica in Windows Server vNext (Растягивание отказоустойчивых кластеров и использование реплики хранилища в Windows Server vNext) и записью блога Enable Change Notifications between Sites — How and Why (Включение уведомлений об изменениях между сайтами: выполнение процесса и преимущества).
(Необязательно.) Настройте устойчивость виртуальной машины, чтобы работа гостей не прерывалась надолго во время сбоев узлов. Вместо этого будет выполняться отработка отказа с переключением на новое хранилище источника репликации за 10 секунд.
Невозможно настроить устойчивость виртуальной машины с помощью диспетчера отказоустойчивости кластеров в Windows Server 2016.
Настройка кластерного файлового сервера для общего использования
Пропустите этот раздел, если вы уже настроили отказоустойчивый кластер Hyper-V, как описано в разделе Настройка отказоустойчивого кластера Hyper-V.
Теперь создадим обычный отказоустойчивый кластер. После настройки, проверки и тестирования он будет растянут с помощью реплики хранилища. вы можете выполнить все приведенные ниже действия на узлах кластера напрямую или на удаленном компьютере управления, содержащем средства удаленного администрирования сервера Windows Server.
Графический интерфейс
Запустите файл cluadmin.msc.
Проверьте предложенный кластер и проанализируйте результаты, чтобы убедиться, что можно продолжить.
Из-за использования асимметричного хранилища при проверке кластера могут возникнуть ошибки хранилища.
Создайте кластер хранилища файлового сервера для общего использования. Убедитесь, что имя кластера содержит не более 15 символов. В примере ниже использован кластер SR-SRVCLUS. Если узлы будут находиться в разных подсетях, необходимо создать IP-адрес для имени кластера для каждой подсети и использовать зависимость «или». Дополнительные сведения можно найти в разделе Настройка IP-адресов и зависимостей для кластеров с несколькими подсетями. часть III.
Настройте файловый ресурс-свидетель или облако-свидетель для предоставления кворума в случае потери сайта.
WIndows Server теперь включает параметр для следящего сервера, основанного на облаке (Azure). Можно выбрать этот вариант кворума вместо файлового ресурса-свидетеля.
Дополнительные сведения о конфигурации кворума см. в разделе Настройка свидетеля руководства о настройке кворума и управлении им на отказоустойчивом кластере Windows Server 2012. Дополнительные сведения о командлете Set-ClusterQuorum см. в статье Set-ClusterQuorum.
Это ожидаемое поведение в Windows Server 2016.
Убедитесь, что сеть кластера настроена оптимально.
Прежде чем перейти к следующему шагу, установите роль файлового сервера. |
В разделе Роли щелкните Настройка роли. Просмотрите экран Перед началом работы и нажмите кнопку Далее.
Выберите Файловый сервер и нажмите кнопку Далее.
Не снимайте флажок Файловый сервер для общего использования и нажмите кнопку Далее.
Укажите имя точки доступа клиента (не более 15 символов) и нажмите кнопку Далее.
Выберите диск, который будет использоваться в качестве тома данных, и нажмите кнопку Далее.
Проверьте параметры и нажмите кнопку Далее. Нажмите кнопку Готово.
Щелкните новую роль файлового сервера правой кнопкой мыши и выберите пункт Добавить общий файловый ресурс. Следуйте указаниям мастера для настройки общих ресурсов.
(Необязательно.) Добавьте другую роль файлового сервера, использующую другое хранилище на этом сайте.
Настройте доступность сведений о сайтах растянутого кластера таким образом, чтобы сервер SR-SRV01 и SR-SRV02 находились на сайте Redmond, SR-SRV03 и SR SRV04 — на сайте Bellevue, а сайт Redmond был предпочтительным для хранения узлов исходного хранилища и виртуальных машин.
Невозможно настроить доступность сведений о сайтах с помощью диспетчера отказоустойчивости кластеров в Windows Server 2016.
(Необязательно.) Настройте сеть кластера и Active Directory для ускоренной отработки отказа сайта DNS. Для этого можно использовать распределенные виртуальные локальные сети, устройства для абстрагирования сети, сокращение срока жизни DNS и другие распространенные методы.
Чтобы получить дополнительные сведения, ознакомьтесь с материалами семинара конференции Microsoft Ignite Stretching Failover Clusters and Using Storage Replica in Windows Server vNext (Растягивание отказоустойчивых кластеров и использование реплики хранилища в Windows Server vNext) и записью блога Enable Change Notifications between Sites — How and Why (Включение уведомлений об изменениях между сайтами: выполнение процесса и преимущества).
Метод для PowerShell
Протестируйте предложенный кластер и проанализируйте результаты, чтобы убедиться, что можно продолжить.
Из-за использования асимметричного хранилища при проверке кластера могут возникнуть ошибки хранилища.
Создайте вычислительный кластер Hyper-V (необходимо указать собственный статический IP-адрес для кластера). Убедитесь, что имя кластера содержит не более 15 символов. Если узлы находятся в разных подсетях, необходимо создать IP-адрес для дополнительного сайта с помощью зависимости «или». Дополнительные сведения можно найти в разделе Настройка IP-адресов и зависимостей для кластеров с несколькими подсетями. часть III.
Настройте файловый ресурс-свидетель или облако-свидетель Azure в кластере, который указывает на общий ресурс, размещенный в контроллере домена или на другом независимом сервере. Например:
Windows Server теперь включает параметр для облака-свидетеля с помощью Azure. Можно выбрать этот вариант кворума вместо файлового ресурса-свидетеля.
Дополнительные сведения о конфигурации кворума см. в разделе Общие сведения о кластере и кворуме пула. Дополнительные сведения о командлете Set-ClusterQuorum см. в статье Set-ClusterQuorum.
Это ожидаемое поведение в Windows Server 2016.
Убедитесь, что сеть кластера настроена оптимально.
Настройте роль файлового сервера. Например:
Настройте доступность сведений о сайтах растянутого кластера таким образом, чтобы сервер SR-SRV01 и SR-SRV02 находились на сайте Redmond, SR-SRV03 и SR SRV04 — на сайте Bellevue, а сайт Redmond был предпочтительным для хранения узлов исходного хранилища и виртуальных машин.
(Необязательно.) Настройте сеть кластера и Active Directory для ускоренной отработки отказа сайта DNS. Для этого можно использовать распределенные виртуальные локальные сети, устройства для абстрагирования сети, сокращение срока жизни DNS и другие распространенные методы.
Чтобы получить дополнительные сведения, ознакомьтесь с материалами семинара конференции Microsoft Ignite Stretching Failover Clusters and Using Storage Replica in Windows Server vNext (Растягивание отказоустойчивых кластеров и использование реплики хранилища в Windows Server vNext) и записью блога Enable Change Notifications between Sites — How and Why (Включение уведомлений об изменениях между сайтами: выполнение процесса и преимущества).
Настройка растянутого кластера
Теперь необходимо настроить растянутый кластер с помощью диспетчера отказоустойчивости кластеров или Windows PowerShell. вы можете выполнить все приведенные ниже действия на узлах кластера напрямую или на удаленном компьютере управления, содержащем средства удаленного администрирования сервера Windows Server.
Метод для диспетчера отказоустойчивости кластеров
Для рабочих нагрузок Hyper-V на одном узле с данными, которые нужно реплицировать, добавьте исходный диск данных из доступных дисков, чтобы поместить общие тома в кластер, если они не настроены. Не добавляйте все диски. Просто добавьте один диск. На этом этапе для половины дисков будет отображаться автономное состояние, так как это асимметричное хранилище. Если репликация рабочей нагрузки физического диска выполнялась так же, как и репликация файлового сервера для общего использования, у вас уже есть готовый диск, подключенный к роли.
Щелкните диск CSV или диск, подключенный к роли, правой кнопкой мыши и выберите Репликация, а затем — Включить.
Выберите соответствующий конечный том данных и нажмите кнопку Далее. Тома отобразившихся конечных дисков и выбранного исходного диска будут одинакового размера. При перемещении между диалоговыми окнами мастера доступное хранилище переместится автоматически и при необходимости перейдет в оперативный режим работы в фоновом режиме.
Выберите соответствующий исходный диск журнала и нажмите кнопку Далее. Исходный том журнала должен находиться на диске, использующем твердотельный накопитель или подобный носитель с быстрой передачей данных, а не на вращающихся дисках.
Выберите соответствующий конечный том журнала и нажмите кнопку «Далее». Тома отобразившихся конечных дисков журнала и выбранного исходного диска журнала будут одинакового размера.
Оставьте для параметра Режим репликации значение Синхронная репликация, если планируется использовать репликацию без целевых точек восстановления. Измените значение на Асинхронная репликация, если планируется растянуть кластер по сетям с более длительными задержками или требуется снизить задержку операций ввода-вывода на узлах основного сайта.
Оставьте значение Группа согласованности для параметра Максимальная производительность, если не планируется использовать порядок записи позже с парой дополнительных дисков в группе репликации. Если планируется добавить дополнительные диски в эту группу репликации и требуется обеспечить гарантированный порядок записи, выберите значение Включить порядок записи и нажмите кнопку Далее.
Нажмите кнопку Далее, чтобы настроить репликацию и растянуть кластер.
На экране «Сводка» обратите внимание на результаты в диалоговом окне завершения. Отчет можно просмотреть в браузере.
На этом этапе настроено партнерство реплики хранилища между двумя частями кластера. Репликация все еще выполняется. Просмотреть состояние репликации с помощью графического средства можно несколькими способами.
Используйте столбец Роль репликации и вкладку Репликация. После завершения начальной синхронизации репликация исходного и конечного дисков будет находиться в состоянии Непрерывная репликация.
Запустите файл eventvwr.exe.
На исходном сервере выберите Приложения и службы\Майкрософт\Windows\StorageReplica\Администратор и просмотрите события 5015, 5002, 5004, 1237, 5001 и 2200.
На конечном сервере выберите Приложения и службы\Майкрософт\Windows\StorageReplica\Операционное и дождитесь события 1215. Это событие сообщает количество скопированных байтов и время выполнения. Пример
На конечном сервере выберите Приложения и службы\Майкрософт\Windows\StorageReplica\Администратор и просмотрите события 5009, 1237, 5001, 5015, 5005 и 2200 для отслеживания хода обработки события. В этой последовательности не должно быть предупреждений или ошибок. Будет много событий 1237, которые указывают ход выполнения.
Загрузка ЦП и памяти может быть выше обычного до завершения начальной синхронизации.
Метод с Windows PowerShell
Убедитесь, что консоль Powershell выполняется с использованием учетной записи администратора с повышенными привилегиями.
Добавьте исходное хранилище данных в качестве CSV-файла только в кластер. Чтобы получить сведения о размере, разделах и структуре томов доступных дисков, используйте следующие команды:
Задайте правильный диск для CSV-файла с помощью следующих команд:
Настройте растянутый кластер, указав следующее:
Исходные и конечные узлы (исходный диск данных является диском CSV, а все остальные диски — нет).
Имена исходной и конечной групп репликации.
Исходный и конечный диски с разделами одинакового размера.
Исходный и конечный тома журналов с достаточным объемом свободного места для хранения журналов на обоих дисках. При этом в качестве хранилища используется твердотельный накопитель или аналогичный носитель с быстрой передачей данных.
Исходный и конечный тома журналов с достаточным объемом свободного места для хранения журналов на обоих дисках. При этом в качестве хранилища используется твердотельный накопитель или аналогичный носитель с быстрой передачей данных.
Исходный том журнала должен находиться на диске, использующем твердотельный накопитель или подобный носитель с быстрой передачей данных, а не на вращающихся дисках.
Кроме того, можно использовать New-SRGroup для одного узла на каждом сайте и New-SRPartnership для создания поэтапной, а не одновременной репликации всех объектов.
Определите этап репликации.
На исходном сервере введите следующую команду и изучите события 5015, 5002, 5004, 1237, 5001 и 2200.
На конечном сервере выполните следующую команду для просмотра событий реплики хранилища, которые показывают создание партнерства. Это событие сообщает количество скопированных байтов и время выполнения. Пример
На конечном сервере выполните следующую команду и проверьте события 5009, 1237, 5001, 5015, 5005 и 2200 для отслеживания хода обработки события. В этой последовательности не должно быть предупреждений или ошибок. Будет много событий 1237, которые указывают ход выполнения.
Кроме того, группа конечных серверов для реплики постоянно сообщает количество оставшихся байтов для копирования, и эти сведения можно запрашивать через PowerShell. Например:
Пример контроля выполнения (не завершается самостоятельно):
Управление репликацией растянутого кластера
Теперь вы приступите к управлению растянутым кластером и к его эксплуатации. вы можете выполнить все приведенные ниже действия на узлах кластера напрямую или на удаленном компьютере управления, содержащем средства удаленного администрирования сервера Windows Server.
Метод с использованием графических средств
Используйте диспетчер отказоустойчивости кластеров, чтобы узнать источник и назначение репликации и их текущее состояние.
Для измерения производительности репликации выполните файл Perfmon.exe на исходном и конечном узлах.
На конечном узле сделайте следующее:
Добавьте объект Статистика реплики хранилища со всеми счетчиками производительности для тома данных.
На исходном узле сделайте следующее:
Добавьте объекты Статистика реплики хранилища и Статистика ввода-вывода раздела реплики хранилища со всеми счетчиками производительности для тома данных (последний доступен только с данными на текущем исходном сервере).
Чтобы изменить источник и назначение репликации в растянутом кластере, используйте следующие методы:
Чтобы переместить источник репликации между узлами на одном сайте, щелкните исходный CSV правой кнопкой мыши, выберите пункт Move Storage (Переместить хранилище), щелкните Выбрать узел и выберите узел на том же сайте. При использовании хранилища другого типа для диска с назначенной ролью нужно переместить роль.
Чтобы переместить источник репликации с одного сайта на другой, щелкните исходный CSV правой кнопкой мыши, выберите пункт Move Storage (Переместить хранилище), щелкните Выбрать узел и выберите узел на другом сайте. Если настроен предпочтительный сайт, можно использовать лучший узел, на который можно постоянно перемещать исходное хранилище — узел на предпочтительном сайте. При использовании хранилища другого типа для диска с назначенной ролью нужно переместить роль.
Чтобы выполнить запланированную отработку отказа для изменения направления репликации с одного узла на другой, завершите работу обоих узлов на одном сайте, используя ServerManager.exe или SConfig.
Чтобы выполнить незапланированную отработку отказа для изменения направления репликации с одного сайта на другой, отключите оба узла на одном сайте.
В Windows Server 2016 может потребоваться использовать диспетчер отказоустойчивости кластеров или Move-ClusterGroup для перемещения конечных дисков на другой сайт вручную после перехода узлов в оперативный режим.
Реплика хранилища отключает конечные тома. Это сделано намеренно.
Чтобы добавить другую пару реплицированных дисков в имеющуюся группу репликации, необходимо убедиться, что в доступном хранилище есть по крайней мере один дополнительный диск. Затем можно щелкнуть исходный диск правой кнопкой мыши и выбрать пункт Add replication partnership (Добавить партнерство репликации).
Эта потребность в дополнительном диске в доступном хранилище продиктована ухудшением функциональности, а не намеренным изменением. Диспетчер отказоустойчивости кластеров ранее нормально обрабатывал добавление дополнительных дисков и снова будет его поддерживать в более поздней версии.
Чтобы удалить имеющуюся репликацию, сделайте следующее:
Запустите файл cluadmin.msc.
Щелкните исходный диск CSV правой кнопкой мыши и выберите пункт Репликация, а затем щелкните Удалить. Подтвердите запрос с предупреждением.
При необходимости удалите хранилище из диска CSV, чтобы вернуть его в доступное хранилище для дальнейшего тестирования.
Чтобы добавить буквы дисков к томам после возврата в доступное хранилище, может понадобиться использовать файл DiskMgmt.msc или ServerManager.exe.
Метод с Windows PowerShell
Используйте Get-SRGroup и (Get-SRGroup).Replicas, чтобы узнать источник и назначение репликации и их текущее состояние.
Для измерения производительности репликации выполните командлет Get-Counter на исходном и конечном узлах. Ниже перечислены имена счетчиков.
\Статистика ввода-вывода раздела реплики хранилища(*)\Количество раз приостановки записи на диск
\Статистика ввода-вывода раздела реплики хранилища(*)\Количество вводов-выводов записи на диск в ожидании
\Статистика ввода-вывода раздела реплики хранилища(*)\Количество запросов для последней записи в журнал
\Статистика ввода-вывода раздела реплики хранилища(*)\Средняя длина очереди записи на диск
\Статистика ввода-вывода раздела реплики хранилища(*)\Текущая длина очереди записи на диск
\Статистика ввода-вывода раздела реплики хранилища(*)\Количество запросов записи приложения
\Статистика ввода-вывода раздела реплики хранилища(*)\Среднее число запросов в операции записи в журнал
\Статистика ввода-вывода раздела реплики хранилища(*)\Средняя задержка записи приложения
\Статистика ввода-вывода раздела реплики хранилища(*)\Средняя задержка чтения приложения
\Статистика реплики хранилища(*)\Целевая RPO
\Статистика реплики хранилища(*)\Текущая RPO
\Статистика реплики хранилища(*)\Средняя длина очереди журнала
\Статистика реплики хранилища(*)\Длина очереди текущего журнала
\Статистика реплики хранилища(*)\Всего байт получено
\Статистика реплики хранилища(*)\Всего байт отправлено
\Статистика реплики хранилища(*)\Средняя время задержки исходящих данных в сети
\Статистика реплики хранилища(*)\Состояние репликации
\Статистика реплики хранилища(*)\Средняя задержка приема-передачи сообщения
\Статистика реплики хранилища(*)\Время, затраченное на последнее восстановление
\Статистика реплики хранилища(*)\Количество транзакций восстановления, записанных на диск
\Статистика реплики хранилища(*)\Количество транзакций восстановления
\Статистика реплики хранилища(*)\Количество транзакций репликации, записанных на диск
\Статистика реплики хранилища(*)\Количество транзакций репликации
\Статистика реплики хранилища(*)\Максимальный порядковый номер журнала
\Статистика реплики хранилища(*)\Количество полученных сообщений
\Статистика реплики хранилища(*)\Количество отправленных сообщений
Дополнительные сведения о счетчиках производительности, доступных в Windows PowerShell, см. в статье Get-Counter.
Чтобы изменить источник и назначение репликации в растянутом кластере, используйте следующие методы:
Чтобы переместить источник репликации с одного узла на другой на сайте Redmond, переместите ресурс CSV, используя командлет Move-ClusterSharedVolume.
Чтобы изменить направление репликации с одного сайта на другой в запланированном режиме, переместите ресурс CSV, используя командлет Move-ClusterSharedVolume.
При этом также соответствующим образом переместятся журналы и данные для других сайтов и узлов.
Чтобы выполнить незапланированную отработку отказа для изменения направления репликации с одного сайта на другой, отключите оба узла на одном сайте.
Реплика хранилища отключает конечные тома. Это сделано намеренно.
чтобы изменить размер журнала с 8 гб по умолчанию, используйте Set-срграуп как в исходной, так и в конечной служба хранилища группах реплик. Например, чтобы задать для всех журналов размер в 2 ГБ, выполните следующее команды:
Чтобы добавить другую пару реплицированных дисков в имеющуюся группу репликации, необходимо убедиться, что в доступном хранилище есть по крайней мере один дополнительный диск. Затем можно щелкнуть исходный диск правой кнопкой мыши и выбрать пункт Add replication partnership (Добавить партнерство репликации).
Эта потребность в дополнительном диске в доступном хранилище продиктована ухудшением функциональности, а не намеренным изменением. Диспетчер отказоустойчивости кластеров ранее нормально обрабатывал добавление дополнительных дисков и снова будет его поддерживать в более поздней версии.
Используйте командлет Set-SRPartnership с параметрами -SourceAddVolumePartnership и -DestinationAddVolumePartnership.
При использовании компьютера удаленного управления понадобится указать имя кластера для этих командлетов, а также имена двух групп ресурсов.