Надежность в службе отмены идентификации служб данных Azure Health (предварительная версия)
В этой статье описывается поддержка надежности в службе отмены идентификации (предварительная версия). Более подробный обзор принципов надежности в Azure см. в статье "Надежность Azure".
Аварийное восстановление между регионами
Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем начать думать о создании плана аварийного восстановления, ознакомьтесь с рекомендациями по разработке стратегии аварийного восстановления.
Когда дело доходит до аварийного восстановления, корпорация Майкрософт использует модель общей ответственности. В модели общей ответственности корпорация Майкрософт гарантирует, что доступны базовые службы инфраструктуры и платформы. В то же время многие службы Azure не автоматически реплицируют данные или не реплицируются из неудающегося региона для перекрестной репликации в другой включенный регион. Для этих служб вы отвечаете за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления, и вы можете использовать специальные функции службы для поддержки быстрого восстановления для разработки плана аварийного восстановления .
Каждая служба отмены идентификации (предварительная версия) развертывается в одном регионе Azure. Если весь регион недоступен или производительность значительно снижается:
- Функциональность плоскости управления ARM ограничена только чтением во время сбоя. Метаданные службы (например, свойства ресурсов) всегда резервируются за пределами региона корпорацией Майкрософт. Когда сбой закончится, вы можете читать и записывать данные в плоскость управления.
- Все запросы плоскости данных завершаются сбоем во время сбоя, таких как запросы на деидентификацию или API заданий. Данные клиента не теряются, но могут быть потеряны метаданные хода выполнения задания. После завершения сбоя можно читать и записывать данные в плоскость данных.
Руководство по аварийному восстановлению
Если весь регион Azure недоступен, вы по-прежнему можете обеспечить высокий уровень доступности рабочих нагрузок. Вы можете развернуть две или более служб деиденификации в конфигурации active-active с помощью Azure Front door, используемой для маршрутизации трафика в оба региона.
В этом примере архитектуры:
- Идентичные службы отмены идентификации развертываются в двух отдельных регионах.
- Azure Front Door используется для маршрутизации трафика в оба региона.
- Во время аварии один регион становится автономным, а Azure Front Door направляет трафик исключительно в другой регион. Цель времени восстановления во время такой геоработки отказа ограничена временем, когда Azure Front Door принимает для обнаружения того, что одна служба неработоспособна.
RTO и RPO
При внедрении конфигурации "активный— активный" необходимо ожидать целевого времени восстановления (RTO) в 5 минут. В любой конфигурации следует ожидать, что цель точки восстановления (RPO) составляет 0 минут (данные клиента не будут потеряны).
Проверка плана аварийного восстановления
Необходимые компоненты
Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу.
Для работы с этим руководством:
Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см . в кратком руководстве по Bash в Azure Cloud Shell.
Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.
Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других возможностях, доступных при входе, см. в статье Вход с помощью Azure CLI.
Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений с Azure CLI.
Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.
Создание или изменение группы ресурсов
Для работы с этим руководством требуется два экземпляра службы отмены идентификации (предварительная версия) в разных регионах Azure. В этом руководстве используются регионы "Восточная часть США" и "Западная часть США 2", но вы можете выбрать собственные регионы.
Чтобы упростить управление и очистку, используйте одну группу ресурсов для всех ресурсов в этом руководстве. Рассмотрите возможность использования отдельных групп ресурсов для каждого региона или ресурса для дальнейшего изоляции ресурсов в ситуации аварийного восстановления.
Выполните следующую команду, чтобы создать группу ресурсов.
az group create --name my-deid --location eastus
Создание служб отмены идентификации (предварительная версия)
Выполните действия, описанные в кратком руководстве. Развертывание службы отмены идентификации (предварительная версия) для создания двух отдельных служб, один в восточной части США и один в западной части США 2.
Обратите внимание на URL-адрес службы каждой службы отмены идентификации, чтобы можно было определить внутренние адреса при развертывании Azure Front Door на следующем шаге.
Создавать Azure Front Door.
Развертывание с несколькими регионами может использовать конфигурацию "активный—активный" или "активный- пассивный". Конфигурация active-active распределяет запросы по нескольким активным регионам. Конфигурация "активный- пассивный" сохраняет выполнение экземпляров в дополнительном регионе, но не отправляет трафик туда, если основной регион не завершается ошибкой. Azure Front Door имеет встроенную функцию, которая позволяет включить эти конфигурации. Дополнительные сведения о разработке приложений для обеспечения высокой доступности и отказоустойчивости см. в статье "Архитектор приложений Azure для обеспечения устойчивости и доступности".
Создание профиля Azure Front Door
Теперь вы создадите Azure Front Door Premium для маршрутизации трафика в службы.
Выполните команду az afd profile create
, чтобы создать профиль Azure Front Door.
Примечание.
Если вы хотите развернуть Azure Front Door Standard вместо premium, замените значение --sku
параметра Standard_AzureFrontDoor. Вы не можете развертывать управляемые правила с помощью политики WAF, если выбран уровень "Стандартный". Подробное сравнение ценовых категорий см . в сравнении ценовой категории Azure Front Door.
az afd profile create --profile-name myfrontdoorprofile --resource-group my-deid --sku Premium_AzureFrontDoor
Параметр | Стоимость | Описание |
---|---|---|
profile-name |
myfrontdoorprofile |
Имя профиля Azure Front Door, уникальное в группе ресурсов. |
resource-group |
my-deid |
Группа ресурсов, содержащая ресурсы из этого руководства. |
sku |
Premium_AzureFrontDoor |
Ценовая категория профиля Azure Front Door. |
Добавление конечной точки Azure Front Door
Выполните команду az afd endpoint create
, чтобы создать конечную точку в профиле Azure Front Door. Эта конечная точка направляет запросы к службам. После завершения работы с этим руководством можно создать несколько конечных точек в профиле.
az afd endpoint create --resource-group my-deid --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
Параметр | Стоимость | Описание |
---|---|---|
endpoint-name |
myendpoint |
Имя конечной точки в профиле, уникальное глобально. |
enabled-state |
Enabled |
Следует ли включить эту конечную точку. |
Создание группы источников Azure Front Door
Выполните команду az afd origin-group create
, чтобы создать группу источников, содержащую две службы де идентификации.
az afd origin-group create --resource-group my-deid --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Https --probe-interval-in-seconds 60 --probe-path /health --sample-size 1 --successful-samples-required 1 --additional-latency-in-milliseconds 50 --enable-health-probe
Параметр | Стоимость | Описание |
---|---|---|
origin-group-name |
myorigingroup |
Имя исходной группы. |
probe-request-type |
GET |
Тип запроса проверки работоспособности, который выполняется. |
probe-protocol |
Https |
Протокол, используемый для пробы работоспособности. |
probe-interval-in-seconds |
60 |
Число секунд между выполнением проб работоспособности. |
probe-path |
/health |
Путь относительно источника, который используется для определения работоспособности источника. |
sample-size |
1 |
Количество выборок, рассматриваемых при балансировке нагрузки. |
successful-samples-required |
1 |
Количество выборок в течение примера периода, который должен завершиться успешно. |
additional-latency-in-milliseconds |
50 |
Дополнительная задержка в миллисекундах для зондов, чтобы попасть в самый низкий сегмент задержки. |
enable-health-probe |
Переключитесь на управление состоянием пробы работоспособности. |
Добавление источников в группу источников Azure Front Door
Выполните команду az afd origin create
, чтобы добавить источник в группу источников. --host-name
Для значений и --origin-host-header
параметров замените значение <service-url-east-us>
заполнителя URL-адресом службы "Восточная часть США", оставляя схему (https://
). У вас должно быть такое abcdefghijk.api.eastus.deid.azure.com
значение.
az afd origin create --resource-group my-deid --host-name <service-url-east-us> --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name deid1 --origin-host-header <service-url-east-us> --priority 1 --weight 1000 --enabled-state Enabled --https-port 443
Параметр | Стоимость | Описание |
---|---|---|
host-name |
<service-url-east-us> |
Имя узла основной службы де-идентификации. |
origin-name |
deid1 |
Имя источника. |
origin-host-header |
<service-url-east-us> |
Заголовок узла для отправки запросов к этому источнику. |
priority |
1 |
Задайте для этого параметра значение 1, чтобы направить весь трафик в основную службу де идентификации. |
weight |
1000 |
Вес источника в заданной группе источников для балансировки нагрузки. Значение должно находиться в диапазоне от 1 до 1000. |
enabled-state |
Enabled |
Следует ли включить этот источник. |
https-port |
443 |
Порт, используемый для HTTPS-запросов к источнику. |
Повторите этот шаг, чтобы добавить второй источник. --host-name
Для значений и --origin-host-header
параметров замените значение <service-url-west-us-2>
заполнителя URL-адресом службы "Западная часть США 2", оставив схему (https://
).
az afd origin create --resource-group my-deid --host-name <service-url-west-us-2> --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name deid2 --origin-host-header <service-url-west-us-2> --priority 1 --weight 1000 --enabled-state Enabled --https-port 443
Обратите внимание на --priority
параметры в обеих командах. Так как оба источника имеют приоритет 1
, Azure Front Door обрабатывает оба источника как активный и прямой трафик в обоих регионах. Если для одного источника задано 2
значение приоритета, Azure Front Door обрабатывает этот источник как вторичный и направляет весь трафик к другому источнику, если только он не исчезнет.
Добавление маршрута Azure Front Door
Запустите az afd route create
, чтобы сопоставить конечную точку с группой источника. Этот маршрут перенаправляет запросы от конечной точки в группу источников.
az afd route create --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --origin-group myorigingroup --supported-protocols Https --link-to-default-domain Enabled
Параметр | Стоимость | Описание |
---|---|---|
endpoint-name |
myendpoint |
Имя конечной точки. |
forwarding-protocol |
MatchRequest | Протокол этот правило используется при переадресации трафика на серверные серверы. |
route-name |
route |
Имя маршрута. |
supported-protocols |
Https |
Список поддерживаемых протоколов для этого маршрута. |
link-to-default-domain |
Enabled |
Связан ли этот маршрут с доменом конечной точки по умолчанию. |
Разрешите выполнение этого шага примерно через 15 минут, так как это займет некоторое время, чтобы это изменение распространялось глобально. После этого периода azure Front Door полностью работает.
Тестирование Front Door
При создании профиля Azure Front Door уровня "Стандартный" или "Премиум" глобальное развертывание конфигурации требует нескольких минут. После завершения вы сможете получить доступ к созданному интерфейсному узлу.
Выполните команду az afd endpoint show
, чтобы получить имя узла конечной точки Front Door. Он должен выглядеть следующим образом. abddefg.azurefd.net
az afd endpoint show --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
В браузере перейдите к имени узла конечной точки, возвращенной предыдущей командой: <endpoint>.azurefd.net/health
Запрос должен автоматически направляться в основную службу де идентификации в восточной части США.
Чтобы проверить моментальную глобальную отработку отказа:
Откройте браузер и перейдите к имени узла конечной точки:
<endpoint>.azurefd.net/health
Выполните действия, описанные в статье "Настройка частного доступа " для отключения доступа к общедоступной сети для службы отмены идентификации в восточной части США.
Обновите свой браузер. Вы должны увидеть ту же информационную страницу, так как трафик теперь направляется в службу де-идентификации в западной части США 2.
Совет
Чтобы завершить отработку отказа, может потребоваться обновить страницу несколько раз.
Теперь отключите доступ к общедоступной сети для службы отмены идентификации в западной части США 2.
Обновите свой браузер. На этот раз вы увидите сообщение об ошибке.
Повторно включите доступ к общедоступной сети для одной из служб отмены идентификации. Обновите браузер и снова увидите состояние работоспособности.
Теперь вы проверили, что вы можете получить доступ к службам через Azure Front Door и эти функции отработки отказа, как это предполагается. Включите доступ к общедоступной сети в другой службе, если вы завершите тестирование отработки отказа.
Очистка ресурсов
На предыдущем шаге вы создали ресурсы Azure в группе ресурсов. Если эти ресурсы вам не понадобятся в будущем, удалите группу ресурсов, выполнив следующие команды:
az group delete --name my-deid
Эта команда может занять несколько минут.
Инициирование восстановления
Чтобы проверить состояние восстановления службы, можно отправить запросы <service-url>/health
в .