Упражнение. Развертывание дизайна в нескольких регионах
Компании Contoso Shoes требуется способ противостоять региональным сбоям. Вы хотите развернуть текущую метку в топологии active-active, shared-state и multi-region. Архитектура должна быть разработана для перенаправления трафика в другой регион в случае сбоя региона.
Текущее состояние и проблема
Для приложения достаточно одного региона. Тем не менее, недавний региональный сбой, который повлиял на сеть, заставил систему перейти в автономный режим с точки зрения конечных пользователей. Горизонтальное масштабирование в пределах региона или даже развертывание новой метки в этом регионе не могло бы восстановить приложение из состояния сбоя.
DNS хранится существующим регистратором.api.contososhoes.com Запись DNS разрешается в конечную точку внутренних Служба приложений () с периодом времени жизни (apicontososhoes.azurewebsites.netTTL) в течение 2 дней. При развертывании решения в нескольких регионах необходимо перенести 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 оставили в качестве одноэлементных? Как вы оправдали свой выбор для каждой службы? Вы внесите какие-либо изменения в конфигурацию?
- Вы регистрируют ресурсы? Вы думаете, что это повлияет на вашу способность проверять журналы для общей системы?