Планирование ресурсов с помощью Azure Site Recovery
В организации крайне важно внедрить стратегию непрерывности бизнес-процессов и аварийного восстановления (BCDR), которая обеспечивает безопасность данных, доступность приложений и рабочие нагрузки в Сети во время плановых и незапланированных простоей.
Благодаря репликации рабочих нагрузок виртуальных машин из первичного сайта в дополнительное расположение azure Site Recovery в Azure Stack Hub предоставляет службы, которые могут поддерживать безопасность данных организации, доступность приложений и рабочие нагрузки во время сбоев. Например, при сбое на основном сайте выполняется отработка отказа в дополнительное расположение для доступа к приложениям. Как только первичный сайт снова будет запущен, вы можете вернуться к нему. Дополнительные сведения см. в статье Azure Site Recovery.
Чтобы включить репликацию виртуальных машин между двумя метками Azure Stack Hub, настройте две среды:
- Исходная среда:
- Метка Azure Stack Hub, где выполняются виртуальные машины клиента.
- Целевая среда:
- Где выполняется поставщик ресурсов Azure Site Recovery.
Важным компонентом для успешного выполнения плана непрерывности бизнес-процессов и аварийного восстановления является планирование ресурсов. При планировании ресурсов необходимо учитывать несколько факторов.
Целевые значения времени восстановления (RTO) и целевые точки восстановления (RPO) для конкретных рабочих нагрузок, которые требуется защитить.
Рабочие нагрузки и характеристики приложения:
- Как часто данные изменяются на соответствующей виртуальной машине.
- Какой объем данных создается или удаляется?
- Как выглядит дизайн приложения и многое другое?
Размеры виртуальных машин, количество дисков и способ привязки каждой виртуальной машины к другим виртуальным машинам.
- Для решений, требующих нескольких виртуальных машин, определите, в каком порядке эти виртуальные машины должны быть запущены.
Пропускная способность сети между исходной и целевой средами. Этот компонент может повлиять на RPO.
Каждый из этих пунктов имеет важное значение и имеет широкие последствия при создании плана BCDR.
В следующих разделах перечислены main моменты, которые следует учитывать с точки зрения Site Recovery Azure. Каждый план BCDR отличается и зависит от особенностей рабочих нагрузок, которые вы планируете защитить. Поэтому этот список не является исчерпывающим.
Рекомендации по источнику
В исходной среде Azure Stack Hub запускает (модуль) виртуальной машины Azure Site Recovery. Виртуальная машина — это Standard_DS4_v2 (8 виртуальных ЦП, 28 ГБ памяти, 32 диска данных), которая выполняется в пользовательской подписке Azure Stack Hub.
В исходной среде рассмотрите следующие области:
Quota:
- Необходимо иметь достаточную квоту для создания (модуль) виртуальной машины Azure Site Recovery. Вам потребуется один или несколько в зависимости от общего плана.
Хранилище для (модуль) виртуальной машины Azure Site Recovery:
Для (модуль) виртуальной машины Azure Site Recovery требования к данным определяются размером виртуальной машины.
При планировании емкости убедитесь, что виртуальная машина (модуль) имеет достаточно места для использования механизмов восстановления размещения и повторной защиты.
Примечание
При наличии ограничений хранилища восстановление размещения и повторная защита могут завершиться ошибкой Сообщение о внутренней ошибке . Пользователи должны проверка журналы событий на (модуль), чтобы подтвердить фактическую ошибку Azure Resource Manager. Дополнительные сведения см. в статье Известные проблемы для azure Site Recovery.
Полоса пропускания:
- Начальная репликация приводит к высокой пропускной способности.
- Изменения на каждой виртуальной машине реплицируются в зависимости от политик репликации и каждого типа приложения.
Рекомендации по целевому объекту
В целевой среде при планировании емкости необходимо учитывать два элемента:
Требования к службе Azure Site Recovery: сколько требуется для запуска Azure Site Recovery, без обязательной защиты рабочих нагрузок.
Требования к защищенным рабочим нагрузкам.
Для защиты виртуальных машин от источника в целевой среде требуется создать одно хранилище Site Recovery Azure для каждой Site Recovery (модуль) (по одной (модуль) на каждое хранилище). Хотя это не является ограничением с точки зрения емкости, его следует учитывать при планировании проектирования общей среды.
Ресурсы azure Site Recovery RP
Для установки azure Site Recovery в Azure Stack Hub необходимо установить поставщик ресурсов Site Recovery (RP).
Примечание
При использовании Microsoft.SiteRecovery-1.2301.2216.2287 Site Recovery Azure в Azure Stack Hub не требуют концентраторов событий в качестве зависимости.
Эта служба создается в подписке администратора Azure Stack Hub и управляется самим Azure Stack Hub, поэтому настройка не требуется. Однако, как и в случае с любой службой, эти ресурсы потребляют память, хранилище и имеют выделенные виртуальные ЦП:
| Служба | Виртуальное ядро | Память | Размер диска |
|---|---|---|---|
| Azure Site Recovery | 12 | 42 ГБ | 1,4 ТБ |
Примечание
Эти ресурсы являются службами Azure Stack Hub на стороне администрирования Azure Stack Hub. После установки платформа управляет этими ресурсами.
Защищенные рабочие нагрузки
При создании плана BCDR учитывайте все аспекты защищенных рабочих нагрузок. Следующий список не является полным и должен рассматриваться как отправная точка:
Размер виртуальной машины, количество дисков, размер диска, операции ввода-вывода в секунду, отток данных и создание новых данных.
Рекомендации по пропускной способности сети.
- Пропускная способность сети, необходимая для разностной репликации.
- Объем пропускной способности в целевой среде, которую Site Recovery Azure может получить из исходной среды.
- Количество виртуальных машин для пакетной обработки за раз. Это число основано на предполагаемой пропускной способности для завершения начальной репликации за заданное время.
- RPO, которая может быть достигнута для заданной пропускной способности.
- Влияние на требуемую RPO при подготовке более низкой пропускной способности.
Рекомендации по хранилищу.
- Сколько данных требуется для начальной репликации.
- Сколько точек восстановления удерживается и как увеличивается объем данных для каждой защищенной виртуальной машины в течение этих интервалов.
- Сколько квот необходимо назначить целевым подпискам пользователей Azure Stack Hub, чтобы пользователи имели достаточно ресурсов.
- Учетная запись хранения кэша для репликации.
Рекомендации по вычислению.
- При отработке отказа виртуальные машины запускаются в целевых пользовательских подписках Azure Stack Hub. Для запуска этих ресурсов виртуальных машин необходимо выделить достаточно квоты.
- Во время защиты виртуальной машины, когда защищенная виртуальная машина активна в исходной среде, в целевой среде не используются ресурсы, связанные с виртуальными машинами, такие как виртуальные ЦП, память и т. д. Эти ресурсы становятся актуальными только во время процесса отработки отказа, например тестовой отработки отказа.
Для область Azure Site Recovery в Azure Stack Hub вот отправная точка для вычислений, особенно для используемой учетной записи хранения кэша:
При отработке отказа во время обычных операций умножьте количество реплицируемых дисков на среднее значение RPO. Например, у вас может быть (2 МБ * 250 с). Обычно учетная запись хранения кэша составляет от нескольких КБ до 500 МБ на диск.
В случае отработки отказа в худшем случае умножьте количество дисков, реплицированных на среднее значение RPO за полный день.
Важно!
Если некоторые части Site Recovery Azure не работают, а другие работают, в учетной записи хранения может быть не более одного дня, прежде чем Site Recovery Azure решит иссыкать время ожидания.
Восстановление размещения на новой виртуальной машине. Вычисление суммы размеров дисков каждого пакета.
- Чтобы применить целевую виртуальную машину, необходимо скопировать весь диск в учетную запись хранения кэша, так как целевой диск является пустым.
- Связанные данные удаляются после копирования, но, скорее всего, будет наблюдаться пиковое использование с суммой дисков всех размеров.
Создайте план BDCR на основе особенностей решения, которое вы пытаетесь защитить.
В следующей таблице приведен пример тестов, выполняемых в наших средах. Эти аналитические сведения можно использовать для получения базовых показателей для собственного приложения, но каждая рабочая нагрузка отличается:
Конфигурация
| Размер блока | Пропускная способность/диск |
|---|---|
| 2 МБ | 2 МБ/с |
| 64 КБ | 2 МБ/с |
| 8 КБ | 1 МБ/с |
| 8 КБ | 2 МБ/с |
Результат
| Число поддерживаемых дисков | Общая пропускная способность | Всего операций | Bottleneck |
|---|---|---|---|
| 68 | 136 МБ/с | 68 | носителей. |
| 60 | 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, определите требования к аварийному восстановлению платформы (DR) и учитывайте все эти факторы в своей разработке:
Требования к доступности приложений и данных:
- Требования RTO и RPO для каждой рабочей нагрузки.
- Поддержка моделей доступности "активный — активный" и "активный — пассивный".
Поддержка развертывания в нескольких регионах для отработки отказа с расположением компонента для производительности. Во время сбоя могут возникнуть операции приложения с ограниченной функциональностью или снижением производительности.
Примечание
Приложение может быть изначально известно для запуска или иметь определенные компоненты, которые могут выполняться в нескольких средах Azure Stack Hub. В этом случае можно использовать azure Site Recovery для репликации только виртуальных машин с компонентами, которые не имеют этой функции. Например, решение внешнего или внутреннего типа, в котором можно развертывать внешние интерфейсы в средах Azure Stack Hub.
Избегайте использования перекрывающихся диапазонов IP-адресов в рабочих сетях и сетях аварийного восстановления.
- Для рабочих сетей и сетей аварийного восстановления с перекрывающимися IP-адресами требуется процесс отработки отказа, который может усложнить и задержать отработку отказа приложений. По возможности спланируйте архитектуру сети BCDR, которая обеспечивает одновременную связь со всеми сайтами.
Определение размера целевых сред:
- Если вы используете исходный и целевой объекты в режиме 1:1, выделите немного больше хранилища в целевой среде. Это связано с тем, как происходит история закладок диска. Это выделение не увеличивается в 2 раз, так как оно включает только изменения данных. В зависимости от типа данных и ожидаемых изменений, а также политик репликации с большим объемом хранилища в 1,5–2 раз в целевом объекте гарантируется, что процессы отработки отказа не вызывают проблем.
- Вы можете использовать целевую среду Azure Stack Hub в качестве целевой для нескольких источников Azure Stack Hub. В этом случае вы снижаете общую стоимость, но должны планировать, что произойдет при сбое определенных рабочих нагрузок; например, какой источник должен быть приоритезирован.
- Если целевая среда используется для выполнения других рабочих нагрузок, план BCDR должен включать поведение этих рабочих нагрузок. Например, можно запустить виртуальные машины разработки и тестирования в целевой среде, а в случае возникновения проблемы с исходной средой можно отключить все виртуальные машины в целевом объекте, чтобы обеспечить наличие достаточного количества ресурсов для запуска защищенных виртуальных машин.
Следует тестировать BCDR и регулярно проверять. Это можно сделать с помощью процессов тестовой отработки отказа или путем перемещения всех рабочих нагрузок для комплексной проверки потоков.
Дальнейшие действия
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по