Критически важные базовые архитектуры в целевой зоне Azure

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

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

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

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

Основные стратегии проектирования

Примените эти стратегии на основе критически важных базовых показателей:

• Критический путь

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

• Жизненный цикл компонентов

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

• Внешние зависимости

  Свести к минимуму внешние зависимости от компонентов и процессов, которые могут привести к сбою. Архитектура имеет ресурсы, принадлежащие различным командам за пределами вашей команды. Эти компоненты (если критически важные) находятся в области для этой архитектуры.

• Топология подписки

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

• Автономная наблюдаемость в критическом пути

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

Архитектура

Скачайте файл Visio для этой архитектуры.

Компоненты этой архитектуры совпадают с критически важной базовой архитектурой с сетевыми элементами управления. Описания являются короткими для краткости. Дополнительные сведения см. в связанных статьях. Документация по продуктам о службах Azure см. в разделе "Связанные ресурсы".

Глобальные ресурсы

Эти ресурсы живут в подписках целевой зоны приложения. Глобальные ресурсы являются неэфемерными и совместно используют время существования системы. Службы Azure и их конфигурация остаются такими же, как базовые глобальные ресурсы.

Региональные сетевые ресурсы

Эти ресурсы живут в подписках целевой зоны платформы и подписках целевой зоны приложения. Базовая архитектура развертывает все ресурсы, принадлежащие вам. Однако в этой архитектуре сетевые ресурсы предоставляются через подписку на подключение , подготавливаются в рамках целевой зоны платформы.

В этой статье см. раздел "Виртуальная сеть регионального концентратора ".

Ресурсы региональных марок

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

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

В этой статье см. раздел " Региональные периферийные виртуальные сети ".

Внешние ресурсы

Рабочая нагрузка взаимодействует с локальными ресурсами. Некоторые из них находятся на критическом пути для рабочей нагрузки, например локальной базы данных. Эти ресурсы и обмен данными с ними учитываются в общем соглашении об уровне обслуживания (SLA) рабочей нагрузки. Все обмен данными осуществляется через подписку на подключение. Существуют и другие внешние ресурсы, которые могут достичь рабочей нагрузки, но они не считаются критически важными.

Ресурсы конвейера развертывания

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

Региональные ресурсы мониторинга

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

В этой статье см. раздел "Рекомендации по мониторингу ".

Ресурсы управления

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

Рекомендации по работе с сетями

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

Топология сети

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

Виртуальная сеть регионального концентратора

Подписка на подключение содержит виртуальную сеть концентратора с ресурсами, которые совместно используются всей организацией. Эти ресурсы принадлежат и поддерживаются командой платформы.

С критической точки зрения эта сеть неэфемерна, и эти ресурсы находятся на критическом пути.

Ресурс Azure	Цель
Azure ExpressRoute	Обеспечивает частное подключение из локальной среды к инфраструктуре Azure.
Брандмауэр Azure	Действует как NVA, который проверяет и ограничивает исходящий трафик.
Azure DNS	Предоставляет разрешение между локальными именами.
VPN-шлюз	Подключает ветви удаленной организации через общедоступный Интернет к инфраструктуре Azure. Также выступает в качестве альтернативы резервному подключению для добавления устойчивости.

Ресурсы подготавливаются в каждом регионе и пиринговые подключения к периферийной виртуальной сети (описано далее). Убедитесь, что вы понимаете и согласны с обновлениями NVA, правилами брандмауэра, правилами маршрутизации, отработкой отказа ExpressRoute на VPN-шлюз, инфраструктуру DNS и т. д.

Виртуальная сеть региональной периферийной сети

Целевая зона приложения имеет по крайней мере две предварительно подготовленные виртуальные сети Azure для каждого региона, на которые ссылается региональные метки. Эти сети являются неэфемерными. Один обслуживает рабочий трафик, а другой предназначен для развертывания vNext. Такой подход позволяет выполнять надежные и безопасные развертывания.

Виртуальная сеть операций

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

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

Совместная ответственность

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

Планирование IP-адресов

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

Команда платформы

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

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

Предварительно подготовленная виртуальная сеть и пиринги должны поддерживать ожидаемый рост рабочей нагрузки. Вы должны регулярно оценивать этот рост с помощью команды платформы. Дополнительные сведения см. в статье "Подключение к Azure".

Подсети региональной периферийной сети

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

• Подсеть частных конечных точек После того как трафик достигает виртуальной сети, обмен данными со службами PaaS в сети ограничен с помощью частных конечных точек, как и базовая архитектура с сетевыми элементами управления. Эти конечные точки помещаются в выделенную подсеть. Частные IP-адреса частным конечным точкам назначаются из этой подсети.

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

сегментация сети.

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

Эта архитектура использует группы безопасности сети (NSG) для ограничения трафика между подсетями и подпиской на подключение. Группы безопасности сети используют serviceTags для поддерживаемых служб.

Команда платформы

• Принудительное использование групп безопасности сети с помощью политик Azure Network Manager.

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

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

Исходящий трафик из региональных меток

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

Команда платформы

• Создайте определяемые пользователем параметры для этого настраиваемого маршрута.

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

• Предоставьте группе приложений надлежащие разрешения на управление доступом на основе ролей (RBAC), чтобы они могли расширить маршруты на основе требований рабочей нагрузки.

Избыточность в нескольких регионах

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

Команда платформы

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

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

Разрешение DNS

Подписка на подключение предоставляет частные зоны DNS. Однако централизованный подход может не учитывать потребности DNS, которые могут быть характерными для вашего варианта использования. Подготовьте собственные зоны DNS и свяжите ее с региональной меткой. Если команда приложений не владеет DNS, управление частными ссылками становится сложной задачей для глобальных ресурсов, таких как Azure Cosmos DB.

Команда платформы

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

• Для региональной сети концентратора задайте значение DNS-серверов по умолчанию (предоставлено Azure) для поддержки частных зон DNS, управляемых командой приложений.

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

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

Как поддерживается изоляция?

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

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

Какой ожидаемый жизненный цикл?

Предварительно созданные среды можно уничтожить после завершения тестов проверки. Рекомендуется, чтобы среды разработки поделились временем существования функции и уничтожаются после завершения разработки. Эти действия выполняются с помощью непрерывной интеграции и непрерывного развертывания (CI/CD).

Что такое компромиссы?

Рассмотрим компромиссы между изоляцией сред, сложностью управления и оптимизацией затрат.

Топология подписки для инфраструктуры рабочей нагрузки

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

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

Рабочая подписка

Могут быть ограничения ресурсов на подписку, предоставленную вам. Если выделить все эти ресурсы в одной подписке, вы можете достичь этих ограничений. На основе единиц масштабирования и ожидаемого масштабирования рассмотрите более распределенную модель. Например

• Одна подписка, содержащая агенты сборки Azure DevOps и глобальные ресурсы.

• Одна подписка на регион. Он содержит региональные ресурсы, ресурсы метки и ящики прыжков для региональных меток.

Ниже приведен пример топологии подписки, используемой в этой архитектуре.

Предварительная подписка

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

Подписка на разработку

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

Постарайтесь максимально сопоставить рабочую топологию.

Рекомендации по развертыванию

Неудачные развертывания или ошибочные выпуски являются распространенными причинами сбоя приложений. Тщательно протестируйте приложение (и новые функции) в рамках жизненного цикла приложения. При развертывании рабочей нагрузки в целевой зоне необходимо интегрировать проект с ресурсами и управлением, предоставляемыми платформой.

См. сведения о хорошо спроектированных критически важных рабочих нагрузках: развертывание и тестирование.

Инфраструктура развертывания

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

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

Настоятельно рекомендуется поддерживать изоляцию между ресурсами развертывания. Инфраструктура развертывания должна быть привязана к подпискам рабочей нагрузки для этой среды. Если вы используете несколько сред в предварительной подписке, создайте дополнительное разделение, ограничив доступ только к отдельным средам. Ресурсы развертывания по регионам можно считать более надежными для инфраструктуры развертывания.

Развертывание без простоя

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

• Полностью автоматизированные конвейеры развертывания.
• Развертывание обновлений в предварительной среде на чистой метке.

Дополнительные сведения см. в рекомендациях по развертыванию и тестированию, критически важных для миссии.

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

Модель развертывания

Базовая архитектура использует модель Blue-Green для развертывания обновлений приложений. Новые метки с изменениями развертываются вместе с существующими метками. После перемещения трафика на новую метку существующую метку уничтожается.

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

Модель canary может обеспечить безопасное развертывание с возможностью отката. Во-первых, новая метка развертывается с изменениями кода. Конвейер развертывания ссылается на предварительно подготовленную виртуальную сеть и выделяет подсети, развертывает ресурсы, добавляет частные конечные точки. Затем он перемещает трафик в эти подсети в этой предварительно подготовленной виртуальной сети.

Если существующая метка больше не требуется, все ресурсы меток удаляются конвейером, за исключением ресурсов, принадлежащих платформе. Сохраняются виртуальные сети, параметры диагностики, пиринг, пространство IP-адресов, конфигурация DNS и управление доступом на основе ролей (RBAC). На этом этапе метка находится в чистом состоянии и готова к следующему новому развертыванию.

Политики Azure DINE (deploy-if-not-exists)

Целевые зоны приложений Azure могут иметь политики Azure DINE (deploy-if-not-exists). Эти проверки гарантируют, что развернутые ресурсы соответствуют корпоративным стандартам в целевых зонах приложений, даже если они принадлежат группе приложений. Может возникнуть несоответствие между развертыванием и конечной конфигурацией ресурсов.

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

Управление доступом к подписке развертывания

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

Команда платформы

• Предоставьте командам приложений авторизацию для операций с разрешениями, указанными в подписке целевой зоны приложения.

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

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

Рекомендации по мониторингу

Платформа целевой зоны Azure предоставляет общие ресурсы наблюдения в рамках подписок управления. Централизованная группа операций рекомендует группам приложений использовать федеративную модель. Но для критически важных рабочих нагрузок единое централизованное хранилище наблюдаемости не рекомендуется, так как это может быть одной точкой сбоя. Критически важные рабочие нагрузки также создают данные телеметрии, которые могут не применяться или действовать для централизованных рабочих групп.

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

Базовая архитектура следует этому подходу и продолжается в этой эталонной архитектуре. Azure Log Analytics и Azure Application Insights развертываются локально и глобально для мониторинга ресурсов в этих областях. Агрегирование журналов, создание панелей мониторинга и оповещений находится в области работы вашей команды. Воспользуйтесь преимуществами возможностей диагностики Azure, которые отправляют метрики и журналы в различные приемники для поддержки требований платформы к сбору журналов и метрик.

Модель работоспособности

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

Команда платформы

• Предоставьте запрос на основе ролей (RBAC) и считывайте приемники журналов для соответствующих ресурсов платформы, которые используются в критическом пути к критически важному приложению.

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

В этой архитектуре модель работоспособности включает журналы и метрики из ресурсов, подготовленных в подписке на подключение. Если вы расширяете эту структуру для доступа к локальному ресурсу, например к базе данных, модель работоспособности должна включать сетевое подключение к этому ресурсу, включая границы безопасности, такие как сетевые виртуальные устройства в Azure и локальной среде. Эта информация важна для быстрого определения первопричины и исправления влияния надежности. Например, произошел сбой при попытке маршрутизации в базу данных или возникла проблема с базой данных?

См. сведения о хорошо спроектированных критически важных рабочих нагрузках: моделирование работоспособности.

Интеграция с политиками и правилами, предоставляемыми платформой

Подписка целевой зоны приложения наследует политики Azure, правила Azure Network Manager и другие элементы управления из своей группы управления. Команда платформы предоставляет эти охранники.

Для развертываний не зависят исключительно от политик, предоставляемых платформой, так как:

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

Настоятельно рекомендуется создавать и назначать политики Azure в развертываниях. Это может привести к некоторым дублированию, но это приемлемо, учитывая потенциальное влияние на надежность системы. Если в политиках платформы есть изменения, политики рабочей нагрузки по-прежнему будут применяться локально.

Команда платформы

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

Развертывание этой архитектуры

Сетевые аспекты этой архитектуры реализуются в реализации критически важных подключенных подключений.

Дальнейшие действия

Просмотрите область проектирования сети и подключения в Azure Well-architected Framework.

Связанные ресурсы

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

• группы управления Azure
• Политика Azure
• Диспетчер сети Azure
• Azure Monitor
• Виртуальные сети
• Таблицы маршрутов