Поделиться через

Планирование емкости с помощью Azure Site Recovery

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

При репликации рабочих нагрузок виртуальных машин из первичного сайта в дополнительное расположение Azure Site Recovery в Azure Stack Hub предоставляет службы, которые могут поддерживать безопасность данных организации, доступности приложений и рабочих нагрузок во время сбоев. Например, при сбое на основной площадке происходит переключение на резервное местоположение для доступа к вашим приложениям. Как только основной сайт снова запущен, вы можете вернуться к нему. Для получения дополнительной информации см. в разделе О Site Recovery.

Чтобы включить репликацию виртуальных машин в двух метках Azure Stack Hub, настройте две среды:

  • Среда источника:
    • Конфигурация Azure Stack Hub, на которой работают виртуальные машины клиента.
  • целевая среда:
    • Где работает поставщик ресурсов Azure Site Recovery.

снимок состояния репликации виртуальных машин на двух стемпах Azure Stack Hub.

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

  • Цели времени восстановления (RTO) и цели точки восстановления (RPO) для определенных рабочих нагрузок, которые требуется защитить.

  • Рабочие нагрузки и характеристики приложения:

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

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

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

  • Пропускная способность сети между исходными и целевыми средами. Этот компонент может повлиять на RPOs.

Каждый из этих пунктов важен и имеет широкие последствия при создании плана BCDR.

В следующих разделах перечислены основные моменты, которые следует учитывать с точки зрения Azure Site Recovery. Каждый план BCDR отличается и основан на специфике рабочих нагрузок, которые вы планируете защитить. Поэтому этот список не является исчерпывающим.

Рекомендации по источнику

В исходной среде Azure Stack Hub запускает устройство виртуальной машины Azure Site Recovery. Виртуальная машина — это виртуальная машина Standard_DS4_v2 (8 виртуальных ЦП, 28 гб памяти, 32 диска данных), которая выполняется в подписке пользователя Azure Stack Hub.

В исходной среде рассмотрим следующие области:

  • Квота:

    • Необходимо иметь достаточный лимит для создания программно-аппаратного комплекса виртуальной машины Azure Site Recovery. В зависимости от общего плана требуется один или несколько.

  • Хранилище для устройства виртуальной машины Azure Site Recovery:

    • Само устройство виртуальной машины Azure Site Recovery имеет требования к данным, определенным по размеру виртуальной машины.

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

      Заметка

      Если существуют ограничения на хранение, отказоустойчивость и повторная защита могут завершиться с ошибкой: произошла внутренняя ошибка, сообщение. Пользователи должны проверить журналы событий на устройстве, чтобы подтвердить фактическую ошибку Azure Resource Manager. Дополнительные сведения см. в статье Известные проблемыAzure Site Recovery.

  • Пропускная способность:

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

Вопросы, касающиеся целевых объектов

В целевой среде существует два элемента, которые следует учитывать для планирования емкости:

  • Требования к службе Azure Site Recovery: сколько ресурсов используется для работы Azure Site Recovery, не обязательно защищая рабочие нагрузки.

  • Требования к защищенным рабочим нагрузкам.

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

Ресурсы RP для Azure Site Recovery

Для установки Azure Site Recovery в Azure Stack Hub требуется установить поставщик ресурсов Site Recovery (RP).

Заметка

При использовании Microsoft.SiteRecovery-1.2301.2216.2287 Azure Site Recovery в Azure Stack Hub не требует центров событий в качестве зависимости.

снимок экрана трех служб для установки Azure Site Recovery в Azure Stack Hub.

Эта служба создается в подписке администратора Azure Stack Hub и управляется самой Azure Stack Hub, поэтому конфигурация не требуется. Однако, как и в любой службе, эти ресурсы используют память, хранилище и выделяют определенные виртуальные ЦП:

Служба Виртуальное ядро Память Размер диска
Служба восстановления сайта Azure (Azure Site Recovery) 18 64 ГБ 384 ГБ

Заметка

Эти ресурсы — это службы Azure Stack Hub на стороне администрирования Azure Stack Hub. После установки платформа управляет этими ресурсами.

Защищенные рабочие нагрузки

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

  • Размер виртуальной машины, количество дисков, размер диска, операций ввода-вывода в секунду, изменение данных и создание новых данных.

  • Рекомендации по пропускной способности сети:

    • Пропускная способность сети, необходимая для разностной репликации.
    • Объем пропускной способности в целевой среде, которую Azure Site Recovery может получить из исходной среды.
    • Количество виртуальных машин для пакетной обработки за раз. Это число основано на предполагаемой пропускной способности для завершения начальной репликации в течение определенного периода времени.
    • RPO, который можно достичь для заданной пропускной способности.
    • Влияние на желаемую RPO при условии, что предоставлена низкая пропускная способность.

  • Рекомендации по хранению:

    • Сколько данных требуется для начальной репликации.
    • Сколько точек восстановления хранится и как увеличиваются данные для каждой защищенной виртуальной машины во время этих интервалов.
    • Сколько квот необходимо назначить пользовательским подпискам в Azure Stack Hub, чтобы у пользователей было достаточно ресурсов?
    • Учетная запись хранения кэша для репликации.

  • Рекомендации по вычислению:

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

Для области Azure Site Recovery в Azure Stack Hub приведена отправная точка для вычислений, особенно для используемой учетной записи хранения кэша:

  1. При переключении на резервный во время обычных операций умножьте количество дисков, реплицированных на основе среднего RPO. Например, возможно, у вас есть (2 МБ * 250 с). Обычно размер учетной записи хранения кэша составляет от нескольких килобайт до 500 МБ на диск.

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

    Важный

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

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

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

Создайте план BDCR на основе особенностей решения, которое вы пытаетесь защитить.

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

Конфигурация

Размер блока Пропускная способность и диск
2 МБ 2 МБ/с
64 КБ 2 МБ/с
8 КБ 1 МБ/с
8 КБ 2 МБ/с

Результат

Количество поддерживаемых дисков Общая пропускная способность Всего OPS Узкое место
68 136 МБ/с 68 хранение
шестьдесят 120 МБ/с 2048 хранение
28 28 МБ/с 3584 ЦП и память Azure Site Recovery
16 32 МБ/с 4096

Заметка

8 КБ — самый маленький размер блока данных Azure Site Recovery. Любые изменения менее 8 КБ обрабатываются как 8 КБ.

Для дальнейшего тестирования мы создали согласованный тип рабочей нагрузки. Например, последовательные изменения данных в хранилище в блоках по 8 КБ, которые в сумме составляют до 1 МБ/с на диск. Этот сценарий маловероятен в условиях реальной рабочей нагрузки, учитывая, что изменения могут происходить в разное время суток или в всплески разного масштаба.

Для воспроизведения этих случайных узоров мы также проверили сценарии в следующих условиях:

  • 120 виртуальных машин (80 Windows, 40 Linux), защищенных с помощью того же устройства виртуальной машины Azure Site Recovery.

    • Каждая виртуальная машина, генерирующая с случайными интервалами, по крайней мере дважды в час, случайные блоки данных общим объёмом 5 ГБ, распределённые по пяти файлам.

    • Репликация выполнена на всех 120 виртуальных машинах с низкой и средней нагрузкой на службы Azure Site Recovery.

      Заметка

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

Как вам следует планировать и тестировать

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

  • Требования к доступности приложений и данных:

    • Требования RTO и RPO для каждой рабочей нагрузки.
    • Поддержка шаблонов доступности активный-активный и активный-пассивный.

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

    Заметка

    Приложение может поддерживать нативный запуск или иметь компоненты, способные работать в нескольких средах Azure Stack Hub. В этом случае вы можете использовать Azure Site Recovery для репликации только виртуальных машин с компонентами, у которых отсутствует такая функциональность; например, решение клиентского или серверного типа, в котором можно развернуть клиентские системы в средах Azure Stack Hub.

  • Избегайте использования перекрывающихся диапазонов IP-адресов в рабочих сетях и сетях аварийного восстановления.

    • Производственные и сети аварийного восстановления с аналогичными IP-адресами требуют процесса переключения, который может усложнить и отложить переключение приложения. По возможности запланируйте сетевую архитектуру BCDR, которая обеспечивает параллельное подключение ко всем сайтам.

  • Определение размера целевых сред.

    • Если вы используете источник и целевой объект в 1:1, выделите немного больше хранилища в целевой среде. Это связано с тем, как происходит история закладок диска. Это выделение не является двукратным увеличением, так как оно включает только изменения в данные. В зависимости от типа данных и ожидаемых изменений, а также от политик репликации, которые требуют увеличения хранилища на целевом ресурсе в 1,5–2 раза, убедитесь, что процессы переключения не вызывают никаких проблем.
    • Вы можете рассмотреть возможность использования целевой среды Azure Stack Hub в качестве цели для нескольких источников Azure Stack Hub. В этом случае вы снижаете общую стоимость, но должны планировать то, что происходит при снижении определенных рабочих нагрузок; Например, какой источник должен быть приоритетным.
    • Если целевая среда используется для выполнения других рабочих нагрузок, план BCDR должен включать поведение этих рабочих нагрузок. Например, можно запустить виртуальные машины разработки и тестирования в целевой среде, а если возникла проблема с исходной средой, вы можете отключить все виртуальные машины в целевом объекте, чтобы обеспечить доступность достаточных ресурсов для запуска защищенных виртуальных машин.

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

Дальнейшие действия

Azure Site Recovery в Azure Stack Hub