Упражнение. Развертывание дизайна в нескольких регионах

30 мин

Компании Contoso Shoes требуется способ противостоять региональным сбоям. Вы хотите развернуть текущую метку в топологии active-active, shared-state и multiregion. Архитектура должна быть разработана для перенаправления трафика в другой регион в случае сбоя региона.

Текущее состояние и проблема

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

DNS хранится существующим регистратором.api.contososhoes.com Запись DNS разрешается в конечную точкуapicontososhoes.azurewebsites.net внутренних Служба приложений () с периодом времени жизни (TTL) в два дня. При развертывании решения в нескольких регионах необходимо перенести DNS.

Спецификация

Расширьте архитектуру для работы в топологии с поддержкой активных и многорегионных операций.
Измените модель метки развертывания, которая позволяет динамически добавлять и удалять регионы по мере необходимости вместо списка жестко закодированных ресурсов в двух регионах.
Если произошел региональный сбой, трафик должен направляться в неисправный регион без каких-либо заметных последствий для клиентов, уже неисправных.
Клиенты не должны быть закреплены в регионе.
Клиентам не нужно изменять URL-адреса для связи с API. DNS следует перенести на глобальный маршрутизатор.

Рекомендуемый подход

Чтобы приступить к работе с проектом, рекомендуется выполнить следующие действия.

1– топология с несколькими агрегатами

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

Регион должен иметь возможность противостоять сбоям центра обработки данных в этом регионе.
Службы Azure и возможности, используемые в архитектуре, должны поддерживаться в регионе.
Регион и ресурсы, развернутые в регионе, должны иметь близкое расположение к конечным пользователям и зависимым системам, чтобы свести к минимуму задержку в сети.

Продумайте сценарий сбоя. Предположим, что регион 1 получает 75 % трафика, а ваш только что добавленный регион 2 получает оставшийся трафик. Они оба масштабируются соответствующим образом для обработки этой нагрузки. В регионе 1 есть региональный сбой, и весь трафик теперь направляется в регион 2. Можете ли вы сделать этот переход гладким? Может ли регион 2 поддерживать увеличение нагрузки трафика?

Проверка хода выполнения: глобальное распределение

2–глобальная маршрутизация

Чтобы клиенты были прозрачно перенаправлены в любой рабочий регион, добавьте глобальную подсистему балансировки нагрузки. Подсистема балансировки нагрузки должна использовать проверки работоспособности, добавленные в предыдущем упражнении, чтобы определить, является ли метка работоспособной. Можно ли подумать о способах обслуживания частых и аналогичных запросов, которые могут выполняться без достижения серверной части?

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

Проверка хода выполнения: глобальная маршрутизация трафика

3–Изменения метки развертывания

Идеальное состояние — это конфигурация active-active, которая не требует отработки отказа вручную, и клиентские запросы можно обслуживать из любого региона. Подумайте о том, что подразумевает для вашей архитектуры. Например, у вас есть какое-либо состояние, хранящееся в региональной метке?

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

Изучите функции надежности служб Azure, используемых в архитектуре. Вы можете начать с этих функций и изучить дополнительные сведения о максимальной надежности.

Служба Azure	Функция
Azure Cosmos DB	Запись в нескольких регионах
Реестр контейнеров Azure	Георепликация
План Службы приложений Azure	Поддержка зоны доступности

Проверка хода выполнения: платформа данных платформы | приложений

Проверьте свою работу

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

Какой другой регион Azure вы выбрали для топологии с несколькими регионами и почему?
Вы активируете две или более Зоны доступности Azure в каждом регионе Azure для защиты от сбоев центра обработки данных?
Вы включили Брандмауэр веб-приложений для управления трафиком входящего трафика? Какие правила маршрутизации вы выполнили и почему?
Как подсистема балансировки нагрузки поддерживает имеющуюся запись DNS?
Как вы использовали API проверки работоспособности из предыдущего упражнения?
Вы защитили приложение от атак DDoS, особенно предотвращая обход подсистемы балансировки нагрузки и достижения региональных экземпляров вредоносных клиентов?
Как вы подошли к миграции DNS?
Вы внесите какие-либо изменения номера SKU в существующий компонент для поддержки топологии нескольких регионов?
Какие службы Azure оставили в качестве одноэлементных? Как вы оправдали свой выбор для каждой службы? Вы внесите какие-либо изменения в конфигурацию?
Вы регистрируют ресурсы? Вы думаете, что это повлияет на вашу способность проверять журналы для общей системы?