Перенос рабочих нагрузок Служба Azure Kubernetes (AKS) и Гибкого сервера MySQL в поддержку зоны доступности

В этом руководстве описывается перенос рабочей нагрузки Служба Azure Kubernetes и гибкого сервера MySQL для завершения поддержки зоны доступности во всех зависимых службах. Полный список всех зависимостей рабочей нагрузки см. в разделе "Зависимости службы рабочей нагрузки".

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

В этом руководстве по миграции основное внимание уделяется вопросам инфраструктуры и доступности для выполнения следующей архитектуры в Azure:

Зависимости службы рабочей нагрузки

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

Существует два подхода поддерживаемых служб зоны доступности: зональные или избыточные между зонами. Большинство служб поддерживают одну или другую. Однако в некоторых случаях есть варианты выбора зонального или избыточного между зонами ресурса для этой службы. Мы указываем, какие службы поддерживают зональные и избыточные между зонами ресурсы в следующих рекомендациях. Мы также указываем, какие службы являются глобальными и региональными.

Архитектура рабочей нагрузки AKS и MySQL состоит из следующих зависимостей компонентов:

Служба Azure Kubernetes (AKS)

• Зональный : пул системных узлов и пулы пользовательских узлов зонируются при предварительном выборе зон, в которых пулы узлов развертываются во время создания. Рекомендуется предварительно выбрать все три зоны для повышения устойчивости. Дополнительные пулы узлов пользователей, поддерживающие зоны доступности, можно добавить в существующий кластер AKS, указав значение для zones параметра.

• Избыточность между зонами: компоненты плоскости управления Kubernetes, такие как etcd, сервер API, планировщик и диспетчер контроллеров, автоматически реплицируются или распределяются по зонам.

  Примечание.

  Чтобы включить избыточность между зонами компонентов уровня управления кластером AKS, необходимо определить пул системных узлов по умолчанию с зонами при создании кластера AKS. Добавление более зональных пулов узлов в существующий незональный кластер AKS не приведет к избыточности зоны кластера AKS, так как это действие не распределяет компоненты плоскости управления между зонами после факта.

База данных Azure для MySQL (гибкий сервер)

• Зональный: зональный режим доступности означает, что резервный сервер всегда доступен в той же зоне, что и основной сервер. Хотя этот параметр снижает время отработки отказа и задержку в сети, она менее устойчива из-за сбоя одной зоны, влияющей как на первичные, так и резервные серверы.

• Избыточность между зонами: режим доступности, избыточный между зонами, означает, что резервный сервер всегда доступен в другой зоне в том же регионе, что и основной сервер. Две зоны будут включены для избыточности зоны для основных и резервных серверов. Мы рекомендуем использовать эту конфигурацию для повышения устойчивости.

Azure Load Balancer (цен. категория или Шлюз приложений Azure

Подсистема балансировки нагрузки (цен. категории "Стандартный")

Сведения о рекомендациях, связанных с Load Balancer (цен. категория ресурсами, см. в статье Load Balancer и Зоны доступности.

• Избыточность между зонами. Выбор избыточности между зонами — это рекомендуемый способ настройки внешнего IP-адреса с помощью существующей подсистемы балансировки нагрузки. Интерфейс, избыточный между зонами, соответствует внутреннему пулу кластера AKS, который распределяется по нескольким зонам.

• Зональный: если вы закрепляете пулы узлов к определенным зонам, таким как зона 1 и 2, можно предварительно выбрать зону 1 и 2 для внешнего IP-адреса в существующей подсистеме балансировки нагрузки. Причина, по которой может потребоваться закрепить пулы узлов к определенным зонам, может быть вызвана доступностью специализированных рядов SKU виртуальной машины, таких как серия M.

Шлюз приложений Azure

Использование надстройки контроллера входящего трафика Шлюз приложений с кластером AKS поддерживается только в Шлюз приложений номера SKU версии 2 (standard и WAF). Дополнительные рекомендации, связанные с Шлюз приложений Azure, см. в статье Масштабирование Шлюз приложений версии 2 и WAF версии 2.

Зональный: Чтобы использовать преимущества зон доступности, рекомендуется создать Шлюз приложений ресурс в нескольких зонах, таких как зона 1, 2 и 3. Выберите все три зоны для оптимальной стратегии устойчивости внутри региона. Однако для соответствия пулам внутренних узлов можно закрепить пулы узлов к определенным зонам, предварительно выбрав зону 1 и 2 во время создания ресурса шлюза приложений. Причина, по которой может потребоваться закрепить пулы узлов в определенных зонах, может быть вызвана доступностью специализированных рядов SKU виртуальной машины, таких как M-series.

Хранилище, избыточное между зонами (ZRS)

• Рекомендуется настроить кластер AKS с управляемыми дисками ZRS, так как они являются ресурсом, избыточным между зонами. Тома можно запланировать во всех зонах.

• Kubernetes учитывает зоны доступности Azure, начиная с версии 1.12. Объект, ссылающийся на управляемый PersistentVolumeClaim диск Azure, можно развернуть в кластере AKS с несколькими зонами. Kubernetes будет заботиться о планировании любого модуля pod, который утверждает, что этот ПВХ в правильной зоне доступности.

• Для базы данных Azure для SQL рекомендуется размещать файлы данных и журналов в хранилище, избыточном между зонами (ZRS). Файлы данных и журналов реплицируются на резервный сервер через репликацию на уровне хранилища ZRS.

Брандмауэр Azure

Зональный. Чтобы использовать преимущества зон доступности, рекомендуется создать ресурс Брандмауэр Azure в нескольких зонах, таких как зона 1, 2 и 3. Рекомендуется выбрать все три зоны для оптимальной стратегии устойчивости внутри региона.

Бастион Azure

Регион. Бастион Azure развертывается в виртуальных сетями или одноранговых виртуальных сетями и связан с регионом Azure. Дополнительные сведения см . в бастионе Azure.

Реестр контейнеров Azure (ACR)

Избыточность между зонами. Рекомендуется создать реестр, избыточный между зонами, на уровне служб "Премиум". Вы также можете создать реплику реестра, избыточной по зонам, задав zoneRedundancy свойство для реплики. Сведения о том, как включить избыточность зоны для ACR, см. в статье "Включение избыточности зоны" в Реестр контейнеров Azure обеспечения устойчивости и высокой доступности.

Кэш Azure для Redis

Избыточность между зонами: Кэш Azure для Redis поддерживает конфигурации, избыточные между зонами, на уровнях Premium и Enterprise. Кэш, избыточный между зонами, помещает узлы в разные зоны доступности в одном регионе.

Microsoft Entra ID

Global: Идентификатор Microsoft Entra — это глобальная служба с несколькими уровнями внутренней избыточности и автоматической возможностью восстановления. Идентификатор Microsoft Entra развертывается в более чем 30 центрах обработки данных по всему миру, которые предоставляют зоны доступности, в которых присутствует. Это число быстро растет по мере развертывания большего числа регионов.

Azure Key Vault

Регион. Azure Key Vault развертывается в регионе. Чтобы обеспечить высокую устойчивость ключей и секретов, содержимое хранилища ключей реплицируется в пределах региона и в дополнительный регион в том же географическом регионе.

Избыточность между зонами. Для регионов Azure с зонами доступности и без пары регионов Key Vault использует хранилище, избыточное между зонами (ZRS), для репликации содержимого хранилища ключей три раза в одном расположении или регионе.

Рекомендации по рабочей нагрузке

Служба Azure Kubernetes (AKS)

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

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

• По таким причинам производительности модули pod могут находиться в одном центре обработки данных в пределах одной зоны доступности. Чтобы совместно находить модули pod в одном центре обработки данных в одной зоне доступности, можно создать пулы узлов пользователей с уникальной зоной и группой размещения близкого взаимодействия. Группу размещения близкого взаимодействия (PPG) можно добавить в существующий кластер AKS, создав новый пул узлов агента и указав PPG. Используйте ограничения распространения топологии pod для управления распространением модулей pod в кластере AKS между зонами доступности, узлами и регионами.

• После того как модули pod, требующие низкой задержки, находятся в одной зоне доступности, обмен данными между модулями pod не является прямым. Вместо этого обмен данными pod направляется через службу, которая определяет логический набор модулей pod в кластере AKS. Модули Pod можно настроить для связи с AKS, а связь со службой будет автоматически балансировать нагрузку на все модули pod, которые являются членами службы.

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

  Например, можно использовать Standard_M32ms под M-series узлами пользователей, так как микрослужбы в приложении требуют высокой пропускной способности, низкой задержки и оптимизированных для памяти размеров виртуальных машин, которые обеспечивают большое количество виртуальных ЦП и большие объемы памяти. В зависимости от региона развертывания при выборе размера виртуальной машины в портал Azure этот размер виртуальной машины поддерживается только в зоне 1 и 2. Эту конфигурацию устойчивости можно принять в качестве компромисса для высокой производительности.

• Размер виртуальной машины для пула узлов нельзя изменить после создания. Дополнительные сведения об ограничениях пула узлов см. в разделе "Ограничения".

База данных Azure для MySQL (гибкий сервер)

Последствия развертывания пулов узлов в определенных зонах, таких как зона 1 и 2, заключается в том, что все зависимости служб кластера AKS также должны поддерживать зону 1 и 2. В этой архитектуре рабочей нагрузки кластер AKS имеет зависимость службы от База данных Azure для MySQL гибких серверов с устойчивостью зоны. Вы выбрали зону 1 для основного сервера и зоны 2, чтобы резервный сервер был совместно расположен с пулами пользовательских узлов AKS.

Кэш Azure для Redis

• Кэш Azure для Redis распределяет узлы в кэше, избыточном между зонами, по выбранным зонам доступности.

• Вы не можете обновить существующий кэш класса Premium, чтобы использовать избыточность зоны. Чтобы использовать избыточность зоны, необходимо повторно создать Кэш Azure для Redis.

• Чтобы обеспечить оптимальную устойчивость, рекомендуется создать Кэш Azure для Redis с тремя или более репликами, чтобы можно было распределить реплики между тремя зонами доступности.

Рекомендации по аварийному восстановлению

Зоны доступности используются для повышения устойчивости для обеспечения высокой доступности рабочей нагрузки в основном регионе развертывания.

Аварийное восстановление состоит из операций восстановления и методик, определенных в плане непрерывности бизнес-процессов. План непрерывности бизнес-процессов определяет, как рабочая нагрузка восстанавливается во время разрушительного события, так и о том, как она полностью восстанавливается после события. Рассмотрите возможность расширения развертывания в альтернативном регионе.

Для уровня приложений ознакомьтесь с рекомендациями по непрерывности бизнес-процессов и аварийному восстановлению для AKS в этой статье.

• Рассмотрите возможность запуска нескольких кластеров AKS в альтернативных регионах. Альтернативный регион может использовать дополнительный парный регион. Кроме того, если для основного региона нет связывания регионов, можно выбрать альтернативный регион на основе вашего рассмотрения доступных служб, емкости, географической близости и суверенитета данных. Ознакомьтесь с руководством по принятию решений по регионам Azure. Также просмотрите шаблон метки развертывания.

• Вы можете настроить активный-активный, активный-резервный, активный пассивный для кластеров AKS.

• Для уровня базы данных функции аварийного восстановления включают геоизбыточные резервные копии с возможностью запуска геовосстановления и развертывания реплик чтения в другом регионе.

• Во время сбоя необходимо решить, следует ли инициировать восстановление. Вам потребуется инициировать операции восстановления только в том случае, если сбой, скорее всего, будет длиться дольше, чем цель времени восстановления рабочей нагрузки (RTO). В противном случае вы дождитесь восстановления службы, проверив состояние службы на панели мониторинга работоспособности служб Azure. В колонке "Работоспособность службы" портал Azure можно просмотреть любые уведомления, связанные с подпиской.

• При запуске восстановления с помощью функции геовосстановки в База данных Azure для MySQL создается новый сервер базы данных с помощью данных резервного копирования, реплицируемых из другого региона.

Next Steps

Дополнительные сведения:

Службы Azure, поддерживающие Зоны доступности