Microsoft AZ-305: Высокая доступность, аварийное восстановление и непрерывность бизнеса — Руководство по подготовке

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Часть Microsoft Azure Solutions Architect Expert AZ-305 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Высокая доступность (HA), аварийное восстановление (DR) и непрерывность бизнес-процессов (BC) в Azure требуют продуманного проектирования на уровнях вычислений, данных и сети. Отказоустойчивость начинается с четкого определения целевого времени восстановления (RTO) и целевой точки восстановления (RPO), а затем объединяет возможности платформы — Зоны доступности, глобальную маршрутизацию, репликацию данных, резервное копирование и оркестрацию отработки отказа — в протестированную, автоматизированную стратегию. Azure обеспечивает изоляцию сбоев на уровне зон и регионов, глобальное распределение на основе DNS и anycast, устойчивость данных в нескольких регионах и управляемое политиками резервное копирование/восстановление для достижения строгих целей при контроле затрат и операционной сложности.

Архитектура на основе RTO/RPO и отказоустойчивость на уровне зон/глобальном уровне

Проектирование начинается с RTO и RPO. RTO определяет, как быстро должен возобновиться сервис после сбоя; RPO определяет максимально допустимую потерю данных. Для достижения низкого RTO требуется автоматическая отработка отказа и предварительно выделенные мощности; для достижения низкого RPO требуется синхронная или почти синхронная репликация и частые согласованные точки восстановления.

Зоны доступности — это независимые домены сбоя в центрах обработки данных в пределах одного региона. Зональные сервисы (например, Virtual Machines, управляемые диски, общедоступные IP-адреса уровня Standard) привязаны к одной зоне. Сервисы, избыточные в пределах зоны (например, frontend’ы Azure Load Balancer Standard, избыточные между зонами, предложения хранилищ с избыточностью в пределах зоны и уровни Azure SQL с избыточностью в пределах зоны), автоматически охватывают несколько зон. Типичный отказоустойчивый паттерн предполагает развертывание зональных виртуальных машин как минимум в двух зонах, их размещение в одной виртуальной сети и предоставление доступа через frontend балансировщика нагрузки, избыточный между зонами. Это исключает сбой в одной зоне как причину простоя.

На глобальном уровне (global edge) выберите между распределением нагрузки на основе DNS и прокси-сервера с anycast-маршрутизацией:

Azure Traffic Manager основан на DNS. Он направляет клиентов к конечным точкам, используя методы маршрутизации: Производительность (наименьшая задержка), Взвешенный (для A/B-тестирования и постепенного переключения трафика), Приоритетный (активная/пассивная отработка отказа), Географический (обслуживание пользователей из конечных точек, соответствующих региональным требованиям), Множественное значение (возвращает несколько работоспособных записей IPv4/IPv6 для простых клиентов) и Подсеть (сопоставление диапазонов IP-адресов клиентов с конкретными конечными точками). Поскольку Traffic Manager основан на DNS, он не ускоряет доставку контента и не проксирует трафик; клиенты подключаются напрямую к выбранной конечной точке и подчиняются поведению локального кэширования DNS.
Azure Front Door (Standard/Premium) — это глобальный обратный прокси-сервер HTTP/HTTPS с anycast-маршрутизацией, интеллектуальной маршрутизацией, терминированием TLS и встроенным межсетевым экраном для веб-приложений (WAF). Правила маршрутизации срабатывают на основе домена, пути, метода и заголовков, а затем направляют трафик в группы источников (origin groups); действия движка правил могут переписывать URL/заголовки и принудительно выполнять перенаправления. Пробы работоспособности постоянно оценивают состояние источников по настраиваемому пути и протоколу; неработоспособные источники удаляются из ротации. Группы источников поддерживают приоритетное (активное/пассивное) и взвешенное распределение между регионами. Политики WAF применяются на уровне конечной точки или маршрута и включают управляемые наборы правил, пользовательские правила и ограничение скорости для противодействия угрозам OWASP и вредоносным клиентам. Используйте Front Door, когда вам нужна глобальная балансировка нагрузки с ускорением, безопасность на периметре сети и отработка отказа с учетом состояния приложения; комбинируйте его с Traffic Manager только тогда, когда вам нужны конечные точки, отличные от HTTP, или контроль на уровне DNS.

На уровне 4 Azure Load Balancer обеспечивает распределение нагрузки TCP/UDP со сверхнизкой задержкой. Standard Load Balancer поддерживает зональные и избыточные между зонами frontend’ы, порты высокой доступности (HA ports), правила для исходящего трафика и безопасное по умолчанию поведение (явная настройка NSG и пула backend’ов). Пробы работоспособности (TCP/HTTP) определяют состояние backend’ов; в случае сбоя экземпляры удаляются из ротации. Basic Load Balancer не поддерживает зоны, не имеет расширенных функций и SLA — избегайте его использования в производственной среде. Cross-region Load Balancer добавляет глобальный anycast frontend, который распределяет нагрузку между региональными Standard Load Balancer, позволяя создавать мультирегиональные архитектуры в режиме «активный-активный» для нагрузок, отличных от HTTP, и обеспечивая быструю отработку отказа на уровне региона на основе проверок работоспособности.

Защита данных и аварийное восстановление: Azure Backup и Site Recovery

Azure Backup обеспечивает восстановление на определённый момент времени; Azure Site Recovery (ASR) предоставляет репликацию рабочих нагрузок и оркестрованный переход на другой ресурс (failover). Они решают взаимодополняющие задачи и часто используются вместе.

Варианты хранилищ Azure Backup:

Хранилище Recovery Services защищает виртуальные машины Azure, SQL Server на виртуальных машинах Azure, SAP HANA на виртуальных машинах Azure, Azure Files и агенты MARS/MABS. Оно интегрируется с политиками резервного копирования, которые определяют расписания, сроки хранения и согласованные с приложениями резервные копии, где это поддерживается.
Хранилище Backup — это модернизированное хранилище для новых рабочих нагрузок, таких как резервное копирование Azure Disks и Azure Blobs, предлагающее гранулярный RBAC и хранилище, избыточное между зонами, в поддерживаемых регионах. Выбирайте тип хранилища в соответствии с рабочей нагрузкой и моделью управления.

Политики резервного копирования определяют, когда выполняются резервные копии, их уровни хранения (ежедневные/еженедельные/ежемесячные/ежегодные) и параметры согласованности. Обратимое удаление (soft delete) добавляет окно безопасности, в течение которого удалённые элементы резервных копий можно восстановить, что защищает от случайного или злонамеренного удаления. Восстановление между регионами (cross-region restore) позволяет выполнять восстановление из вторичного региона, когда хранилище использует геоизбыточные опции; эту функцию необходимо включить, и её доступность зависит от поддержки в регионе и готовности плоскости данных.

Azure Site Recovery реплицирует рабочие нагрузки между зонами или регионами и оркестрирует сквозное аварийное восстановление (DR):

Политики репликации определяют частоту создания моментальных снимков, срок хранения точек восстановления, периодичность создания согласованных с приложениями снимков и пороговые значения для оповещений RPO. Политики позволяют сбалансировать пропускную способность репликации, затраты на хранение и точность восстановления.
Планы восстановления обеспечивают упорядоченный переход на другой ресурс (failover) для многоуровневых приложений с помощью групп (например, база данных, API, веб-сервер), шагов до и после, а также автоматизации через runbooks службы Azure Automation, скрипты или ручные действия. Интегрируйте в план изменения DNS, обновления конечных точек Traffic Manager/Front Door и конфигурацию приложений.
Тестовый переход на другой ресурс (test failover) запускает изолированное восстановление с использованием непроизводственной VNet или тестовой сети для проверки runbooks, порядка загрузки и работоспособности приложений без влияния на производственную среду или репликацию. Регулярное тестирование необходимо для подтверждения RTO.
Восстановление исходного состояния (failback) возвращает рабочие нагрузки на исходную площадку или в исходный регион после их восстановления. После перехода на другой ресурс повторно защитите рабочую нагрузку в новом основном направлении, синхронизируйте изменения, запланируйте окно для планового восстановления и проверьте репликацию после него. В сценариях Azure-to-Azure обычно выполняется переход между парными регионами и реверсирование репликации для восстановления исходной топологии, когда всё готово.

Непрерывность на уровне данных: Azure SQL, репликация хранилища и Cosmos DB

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

Azure SQL Database и Azure SQL Managed Instance:

Активная георепликация создаёт до четырёх читаемых вторичных реплик для отдельных баз данных или эластичных пулов. Она предлагает репликацию на уровне базы данных с ручным или управляемым через API переходом на другой ресурс, обеспечивая масштабирование чтения и DR. Этот вариант подходит, когда требуется контроль на уровне отдельных баз данных и кастомная оркестрация.
Группы автоматического перехода на другой ресурс (auto-failover groups) создают группу баз данных (или целый управляемый экземпляр), которые переключаются вместе с помощью конечной точки прослушивателя. Это упрощает межрегиональный переход на другой ресурс и управление строками подключения, а также поддерживает автоматический переход после льготного периода. Используйте группы отработки отказа для приложений с несколькими базами данных, требующих скоординированного перехода и упрощённого подключения клиентов.
Избыточность между зонами (zone redundancy) размещает реплики в разных зонах одного региона для переживания сбоев на уровне зоны без межрегионального восстановления. Включите её для поддерживаемых уровней служб, чтобы повысить локальную доступность без изменения профилей задержки.

Варианты репликации Azure Storage:

GRS (геоизбыточное хранилище) асинхронно реплицирует данные из основного региона (три копии) в парный вторичный регион (три копии). В обычном режиме операции чтения и записи направляются в основной регион.
RA-GRS добавляет доступ на чтение к вторичной конечной точке для сценариев, таких как экстренная отчётность или аналитика, когда основной регион работает с перебоями.
GZRS (геоизбыточное хранилище между зонами) сочетает ZRS в основном регионе для обеспечения долговечности на уровне зон с асинхронной репликацией во вторичный регион, повышая как локальную, так и региональную отказоустойчивость.
RA-GZRS добавляет доступ на чтение к вторичной реплике для учётных записей GZRS. Если основной регион не подлежит восстановлению, можно инициировать переход учётной записи на вторичный регион. После перехода учётная запись хранения становится основной во вторичном регионе и обычно переключается в режим локальной избыточности (пока вы не перенастроите её). Ожидайте некоторого RPO (из-за асинхронной репликации); приложения должны обрабатывать идемпотентность и согласование данных после перехода.

Azure Cosmos DB:

Запись в несколько регионов (multi-region writes) позволяет выполнять запись в любой настроенный регион с политиками разрешения конфликтов (побеждает последняя запись по указанному свойству, кастомные или multi-master стратегии). Это снижает задержку записи и повышает доступность.
Автоматический переход на другой ресурс использует список регионов с приоритетами для назначения нового региона для записи в случае сбоя. В сочетании с выбранными уровнями согласованности (от Strong до Eventual) вы управляете компромиссом между доступностью и согласованностью.
SLA охватывают доступность, пропускную способность, задержку и согласованность. При записи в несколько регионов Cosmos DB предлагает доступность до 99,999% как для чтения, так и для записи, при условии правильной конфигурации. Проектируйте клиенты с использованием SDK с обнаружением конечных точек и повторными попытками, чтобы в полной мере использовать эти гарантии.

Собираем все вместе: достижение конкретных целей восстановления

Сопоставьте каждый уровень с его механизмом обеспечения непрерывности, руководствуясь RTO/RPO и доменами сбоя:

Доступность в пределах региона: используйте зоны доступности (Availability Zones). Развертывайте зональные вычислительные ресурсы как минимум в двух зонах; используйте отказоустойчивые к сбоям зон внешние интерфейсы (Standard Load Balancer, Application Gateway v2 с избыточностью между зонами или Front Door на границе сети). Включите избыточность между зонами для SQL там, где это поддерживается, и используйте GZRS для хранилищ, которым требуется устойчивость как на уровне зон, так и на уровне регионов.
Межрегиональное аварийное восстановление (DR): для уровней с отслеживанием состояния (stateful) предпочтительно использовать встроенную георепликацию (группы автоматической отработки отказа SQL, учетные записи Cosmos DB с несколькими регионами, хранилище GRS/GZRS) для достижения низкого RPO. Для IaaS с отслеживанием состояния или рабочих нагрузок без встроенной репликации используйте Azure Site Recovery с точно настроенными политиками репликации и планами восстановления. Для эфемерных вычислительных ресурсов восстанавливайте их из образов или VM Scale Sets, используя подход «инфраструктура как код» (Infrastructure as Code).
Глобальная маршрутизация и аварийное переключение: для HTTP/S служба Azure Front Door обеспечивает аварийное переключение на основе проб работоспособности с учетом состояния приложения и защиту с помощью WAF. Для протоколов, отличных от HTTP, или смешанных протоколов добавьте Traffic Manager (DNS) или Cross-region Load Balancer (L4 anycast) по мере необходимости. Используйте маршрутизацию по приоритету для строгих целей RTO в конфигурации «активный-пассивный»; используйте взвешенную маршрутизацию для поэтапного развертывания и маршрутизацию по производительности для обеспечения минимальной задержки для пользователей.
Резервные копии как последняя линия защиты: даже при наличии репликации поддерживайте резервное копирование с помощью Azure Backup с политиками хранения, соответствующими требованиям комплаенса, включите обратимое удаление для защиты от событий полной очистки и настройте межрегиональное восстановление для хранилищ, использующих геоизбыточное хранилище. Резервные копии защищают от логического повреждения данных, атак программ-вымогателей и ошибок оператора — рисков, которые репликация может распространить.

Тестирование не подлежит обсуждению. Планируйте регулярные тестовые отработки отказа ASR, проводите учения по проверке работоспособности Front Door/Traffic Manager, проверяйте поведение групп отработки отказа SQL под нагрузкой и выполняйте симуляции аварийного переключения хранилища в изолированной среде (песочнице). Организуйте измерение RTO и автоматизируйте откат/возврат в исходное состояние с помощью runbooks. Документируйте и отрабатывайте операционные runbooks, чтобы дежурные специалисты могли действовать последовательно в стрессовых ситуациях.

Практический сценарий

Expedia Group необходимо модернизировать свою глобальную платформу бронирования путешествий, чтобы обеспечить RTO ≤ 15 минут и RPO ≤ 5 минут для основных операций бронирования, выдерживая при этом 10-кратные всплески трафика во время крупных туристических событий. Платформа обслуживает веб- и мобильных клиентов по всему миру со смешанными HTTP и не-HTTP рабочими нагрузками.

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

Разверните микросервисы без отслеживания состояния (stateless) в виде зональных VM Scale Sets в двух или более зонах доступности с отказоустойчивыми к сбоям зон внешними интерфейсами Standard Load Balancer. Это устраняет риск сбоя в одной зоне и обеспечивает низкую задержку для трафика внутри региона.
Используйте Azure SQL Database с группами автоматической отработки отказа и включенной избыточностью между зонами. Группы автоматической отработки отказа обеспечивают скоординированное аварийное переключение баз данных и стабильный прослушиватель, что позволяет достичь RTO в 15 минут с минимальными операционными затратами.
Храните артефакты сессий и изображения в учетных записях хранения GZRS, чтобы сочетать зональную устойчивость с асинхронной региональной защитой. В сочетании с идемпотентностью на стороне приложения это позволяет достичь RPO в 5 минут.

Добавление межрегионального аварийного восстановления (DR) с активным чтением в нескольких регионах (active/active reads)

Настройте источники (origins) веб-приложения/API для бронирования в двух парных регионах за Azure Front Door Standard. Пробы работоспособности и маршрутизация по приоритету обеспечивают быстрое аварийное переключение при сбоях в работе приложения, а технология anycast ускоряет пользовательский трафик. Политики WAF с управляемыми наборами правил и ограничением скорости защищают от объемных атак и атак на уровне приложений, что критически важно во время всплесков трафика.
Включите запись в несколько регионов в Cosmos DB для сервисов маршрутов и персонализации, чтобы уменьшить задержку записи для пользователей по всему миру и обеспечить доступность на уровне 99,999%. Автоматическое аварийное переключение отдает приоритет вторичному региону, сохраняя низкий RTO без ручного вмешательства.
Используйте группы автоматической отработки отказа SQL в тех же двух регионах для транзакционных бронирований, что позволяет масштабировать чтение на вторичных репликах для отчетности и обеспечивает быстрое, скоординированное аварийное переключение.

Защита состояния и поддержка восстановления после повреждения данных

Используйте хранилища Recovery Services для резервного копирования виртуальных машин Azure (с согласованностью на уровне приложений, где это поддерживается) и SQL на ВМ, если остались какие-либо устаревшие компоненты. Применяйте политики резервного копирования с многоуровневым хранением и включайте обратимое удаление для защиты от случайных или злонамеренных удалений.
Для дисков Azure Disks, на которых размещены специализированные рабочие нагрузки, добавьте резервное копирование Azure Disk Backup на основе хранилища Backup, чтобы создавать инкрементальные снимки независимо от агентов гостевой ОС. Это диверсифицирует варианты восстановления.
Включите межрегиональное восстановление для хранилищ, использующих геоизбыточное хранилище, что позволяет восстанавливать данные на уровне данных (data-plane) из вторичного региона во время частичных сбоев на уровне управления (control-plane).

Оркестрация аварийного восстановления (DR) и проверка RTO

Настройте Azure Site Recovery для любых служб, не имеющих встроенной репликации (например, устаревших служб Windows). Создайте планы восстановления, которые определяют последовательность готовности базы данных, затем API, затем веб-уровня, и включите runbooks Azure Automation для обновления ссылок в Key Vault, очистки кэшей CDN через правила Front Door и переключения приоритета Traffic Manager для конечных точек, не использующих HTTP.
Планируйте ежеквартальные тестовые отработки отказа в изолированные виртуальные сети (VNet) с использованием маскированных данных для проверки runbooks, измерения фактической продолжительности аварийного переключения и уточнения резервирования мощностей. После тестов очищайте артефакты и анализируйте метрики на соответствие целевому RTO в 15 минут.

Глобальная маршрутизация для смешанных протоколов

Для HTTP/S служба Front Door управляет аварийным переключением на основе проб работоспособности и безопасностью на границе сети. Для протоколов, отличных от HTTP (например, интеграции с партнерами по TCP), разверните Cross-region Load Balancer с региональными Standard Load Balancers в качестве дочерних конечных точек. Пробы работоспособности мгновенно удаляют отказавшие регионы, поддерживая подключение без зависимостей от TTL DNS. Если требуется геолокационная фильтрация на уровне DNS (например, для регуляторных требований), добавьте перед специфичными для региона конечными точками маршрутизацию по географическому признаку с помощью Azure Traffic Manager.

Почему выбраны именно эти службы

Зоны доступности и отказоустойчивые к сбоям зон внешние интерфейсы устраняют сбои в одной зоне с минимальным влиянием на задержку. Группы отработки отказа Azure SQL абстрагируют управление подключениями и автоматизируют аварийное переключение, что соответствует RTO в 15 минут. Запись в несколько регионов в Cosmos DB отвечает требованиям сверхвысокой доступности и низкой задержки записи в глобальном масштабе. Опции GZRS и RA обеспечивают устойчивость на уровне зон и регионов с контролируемыми компромиссами по RPO. Front Door предоставляет глобальное ускорение, аварийное переключение с учетом состояния приложения и WAF на границе сети. Cross-region Load Balancer и Traffic Manager покрывают потребности в маршрутизации для не-HTTP протоколов и географической маршрутизации. Azure Backup и ASR предоставляют независимые пути восстановления — от восстановления на определенный момент времени до полного аварийного переключения стека — обеспечивая возможность восстановления платформы как после сбоев инфраструктуры, так и после логического повреждения данных.

← Сетевое взаимодействие и подключение · Все домены · Архитектура безопасности и Zero Trust →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →