Растянутый кластер что это такое
Общие сведения о растянутых кластерах
Область применения: 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 и т. д.). необходимо учитывать, когда дело доходит до подключения клиентов и должно быть тщательно продумано. Обратитесь к группе работы с сетью, чтобы узнать наилучший вариант в соответствии с вашими потребностями.
Обзор вариантов реализации отказоустойчивых кластеров: Stratus, VMware, VMmanager Cloud
Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.
Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности.
Предисловие
В области защиты от сбоев на кластерах терминология в Интернете различается от сайта к сайту. Для того чтобы избежать путаницы, мы обозначим термины и определения, которые будут использоваться в этой статье.
На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.
Continuous availability / непрерывная доступность
Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.
Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности — vSphere от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.
В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:
Мы не стали расписывать конкретные конфигурации нод: состав комплектующих в серверах всегда зависит от задач кластера. Сетевое оборудование описывать также смысла не имеет: во всех случаях набор будет одинаковым. Поэтому в данной статье мы решили считать только то, что точно будет различаться: стоимость лицензий.
Стоит упомянуть и о тех продуктах, разработка которых остановилась.
Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.
Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.
Первый — Kemari, продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.
Второй — Micro Checkpointing, основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.
Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.
Итак, практика показывает, что несмотря на преимущества систем непрерывной доступности, есть немало трудностей при внедрении и эксплуатации таких решений. Однако существуют ситуации, когда отказоустойчивость требуется, но нет жёстких требований к непрерывности сервиса. В таких случаях можно применить кластеры высокой доступности, КВД.
High availability / высокая доступность
В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.
В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.
Таким образом, кластер высокой доступности делится на два подкластера:
VMmanager Cloud
Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.
В упрощённой форме алгоритм такой:
Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.
Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.
FirstByte
Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:
Отличительные черты кластера:
Данная конфигурация подходит для хостинга сайтов с высокой посещаемостью, для размещения игровых серверов и баз данных с нагрузкой от средней до высокой.
FirstVDS
Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.
К использованию VMmanager Cloud компания пришла из следующих соображений:
В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.
Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.
Эпилог
Подведём итог статьи. Если каждая секунда простоя сервиса приносит значительные убытки — не обойтись без кластера непрерывной доступности.
Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.
Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости — избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать — резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя.
Если вы решили, что для ваших задач больше подходит схема высокой доступности и выбрали VMmanager Cloud как инструмент для её реализации, к вашим услугам инструкция по установке и документация, которая поможет подробно ознакомиться с системой. Желаем вам бесперебойной работы!
P. S. Если у вас в организации есть аппаратные CA-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно 🙂
Реакция на аварию: растянутый кластер против 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-площадки и что бы от них хотели вообще в целом?
Репликация растянутого кластера с помощью общего хранилища
Область применения: 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.
При использовании компьютера удаленного управления понадобится указать имя кластера для этих командлетов, а также имена двух групп ресурсов.