базовая архитектура Виртуальные машины Azure в целевой зоне Azure

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

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

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

Макет статьи

Архитектура	Решение по проектированию	Подход в рамках Azure Well-Architected Framework
▪ Схема архитектуры ▪ Ресурсы рабочей нагрузки ▪ Федеративные ресурсы	▪ Настройка подписки ▪ Требования к сети ▪ Изменения в структуре сети из базового плана ▪ Контроль ▪ Соответствие требованиям к патчам ▪ Управление организацией ▪ Управление изменениями	▪ Надёжность ▪ Безопасность ▪ Оптимизация затрат

Архитектура

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

Компоненты

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

Ресурсы, принадлежащие команде рабочей нагрузки

Следующие ресурсы остаются в основном неизменными из базовой архитектуры.

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

• Azure Load Balancer — это служба балансировки нагрузки уровня 4 для трафика протокола TCP и протокола UDP. В этой архитектуре внутренний балансировщик нагрузки распределяет трафик от фронтенд-ВМ к бэкенд-ВМ через различные зоны.

• Шлюз приложений Azure — это обратный прокси-сервер уровня 7 и подсистема балансировки нагрузки веб-трафика. В этой архитектуре он прекращает действие протокола защиты транспортного уровня (TLS), проверяет запросы и служит обратным прокси-сервером для маршрутизации трафика пользователей на фронтальные виртуальные машины. Выбранный SKU также размещает Брандмауэр веб-приложений Azure для защиты виртуальных машин фронтенда от потенциально вредоносного трафика.

• Azure Key Vault — это служба для управления секретами, ключами и сертификатами. В этой архитектуре хранятся сертификаты TLS, которые используют шлюз приложений и виртуальные машины.

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

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

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

• Периферийные подсети виртуальной сети и группы безопасности сети (NSG) предоставляют сегментированные пространства IP-адресов и границы фильтрации трафика. В этой архитектуре они реализуют изоляцию на основе уровней и контролируют потоки "восток-запад", а также потоки входящего и исходящего трафика для компонентов рабочей нагрузки.

• Приватные конечные точки обеспечивают доступ к платформенным службам на основе частного IP-адреса через сеть Azure. В этой архитектуре они обеспечивают безопасное подключение к решениям платформы как услуга (PaaS) и частным зонам DNS , необходимым для этих конечных точек.

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

Ресурсы, принадлежащие команде платформы

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

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

• Бастион Azure в узловой сети — это архитектурный подход, который обеспечивает подключение по протоколам удаленного рабочего стола (RDP) и Secure Shell (SSH) к виртуальным машинам через TLS без раскрытия общедоступных IP-адресов. В этой архитектуре он предоставляет общий рабочий доступ к виртуальным машинам рабочей нагрузки с аудитом. В базовой архитектуре команда рабочей нагрузки владеет этим компонентом.

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

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

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

Настройка подписки

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

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

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

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

• Частные приложения, такие как внутренние бизнес-приложения или коммерческие готовые решения (COTS), которые часто находятся в группе управления корпорации Azure посадочных зон.

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

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

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

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

Требования к рабочей нагрузке и выполнение

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

• Количество периферийных виртуальных сетей: В этой архитектуре требуется только один выделенный периферийный спицевой узел. Развернутые ресурсы не требуют охватывать несколько сетей и размещаются в одной виртуальной сети.

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

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

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

• Характеристики рабочей нагрузки и варианты проектирования: обмен данными о вариантах проектирования, компонентах и характеристиках в команде платформы. Например, если вы ожидаете, что рабочая нагрузка создаст большое количество одновременных подключений к Интернету (чат), команда платформы должна убедиться, что есть достаточно портов преобразования сетевых адресов источника (SNAT), чтобы предотвратить исчерпание. Они могут добавлять общедоступные IP-адреса в централизованный брандмауэр для расширения пула портов SNAT или присоединять Azure NAT Gateway для дальнейшего масштабирования емкости SNAT.

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

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

• Конфигурация брандмауэра: команда платформы должна знать о трафике, который покидает периферийную сеть и туннелируется в центральной сети. Брандмауэр в концентраторе не может заблокировать этот трафик.

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

• Operator access: если есть группы безопасности Microsoft Entra ID, которые операторы используют для доступа к виртуальным машинам через Бастион Azure, сообщите команде платформы. Бастион Azure обычно является центральным ресурсом. Важно убедиться, что группы безопасности и виртуальные машины поддерживают безопасный протокол.

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

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

  В этой архитектуре существует другой общедоступный IP-адрес для оперативного доступа через Бастион Azure. Команда платформы владеет этим общедоступным IP-адресом, который подключён к службе, например, к защите от атак DDoS, также управляемой командой платформы.

Варианты разработки виртуальных машин

Номера SKU виртуальной машины и диски остаются такими же, как и базовая архитектура.

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

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

Нетворкинг

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

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

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

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

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

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

Подсети виртуальной сети

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

При развертывании рабочей нагрузки в целевой зоне приложения все равно необходимо реализовать сетевые элементы управления. Организации могут ввести ограничения для защиты от кражи данных и обеспечить видимость центра управления безопасностью (SOC) и ИТ-группы.

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

Входящий трафик

Входящий поток трафика остается таким же, как и в базовой архитектуре.

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

Исходящий трафик

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

Этот дизайн отличается в этой архитектуре. Весь трафик, покидающий периферийную виртуальную сеть, направляется через пиринговую сеть концентратора через брандмауэр исходящего трафика. Маршрут подключен ко всем возможным подсетям в периферийной сети, перенаправляя весь трафик для IP-адресов, не найденных в локальной виртуальной сети (0.0.0.0/0), на Брандмауэр Azure концентратора.

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

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

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

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

Сообщите о любых уникальных требованиях к исходящему трафику команде платформы. Брандмауэр применяет преобразование сетевых адресов источника (SNAT) к потокам исходящего трафика, заменяя исходный IP-адрес рабочей нагрузки одним из своих общедоступных IP-адресов. Количество подключенных IP-адресов ограничивает бюджет порта SNAT. Если рабочая нагрузка устанавливает многочисленные одновременные исходящие подключения, сообщите группе платформы, чтобы снизить нехватку портов SNAT, подключив Azure NAT Gateway или добавив более общедоступные IP-адреса в региональный брандмауэр. Также поделитесь набором общедоступных IP-адресов брандмауэра с партнерами по downstream, чтобы разрешающие списки покрывали весь возможный диапазон исходных IP-адресов.

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

Зоны Частная зона DNS

Архитектуры, использующие частные конечные точки, нуждаются в частных зонах DNS для работы с поставщиком DNS. Команда по рабочей нагрузке должна иметь четкое представление о требованиях к управлению частными зонами DNS в подписке, которую предоставляет команда платформы. Частная зона DNS-зоны обычно управляются в большом масштабе с использованием политик DINE, позволяя Брандмауэр Azure выступать как надежный прокси-сервер DNS и поддерживать сетевые правила для полных доменных имен (FQDN).

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

Тестирование подключения

Для архитектур на основе виртуальных машин существует несколько средств тестирования, которые помогут определить проблемы с сетевой линией зрения, маршрутизацией и DNS. Вы можете использовать традиционные средства устранения неполадок, например netstat, nslookupили tcping. Кроме того, можно проверить параметры протокола конфигурации динамического узла (DHCP) сетевого адаптера и DNS. При наличии сетевых адаптеров у вас есть дополнительные возможности устранения неполадок, которые позволяют выполнять проверки подключения с помощью Azure Network Watcher.

Доступ оператора

Как и архитектура baseline, операционный доступ через Бастион Azure поддерживается в этой архитектуре.

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

Удостоверение оператора

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

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

Соответствие исправлениям и обновления ОС

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

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

Контроль

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

Команда рабочей нагрузки подготавливает ресурсы для мониторинга, в том числе:

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

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

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

Как и в базовом плане, все ресурсы настроены для отправки журналов диагностики Azure в рабочую область Log Analytics, подготовленную командой по управлению рабочей нагрузкой в рамках развертывания инфраструктуры как кода (IaC) для этих ресурсов. Также возможно, потребуется отправить журналы в центральную рабочую область Log Analytics. В Azure зонах высадки эта рабочая область находится в управляющей подписке.

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

Сопоставление данных из нескольких приемников

Журналы и метрики рабочей нагрузки и её компоненты инфраструктуры хранятся в рабочей области Log Analytics этой нагрузки. Однако журналы и метрики, которые создают такие централизованные службы, как Брандмауэр Azure, Microsoft Entra ID и Бастион Azure, хранятся в центральной рабочей области Log Analytics. Сопоставление данных из нескольких приемников может быть сложной задачей.

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

Политика Azure

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

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

Управление изменениями с течением времени

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

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

Изменения платформы, влияющие на рабочую нагрузку

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

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

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

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

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

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

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

Изменения рабочей нагрузки, влияющие на платформу

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

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

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

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

• Изменения владения: обмен данными об изменениях в собственности и точках связи с командой платформы.

Изменения бизнес-требований рабочей нагрузки

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

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

Соображения

Эти рекомендации реализуют основы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в разделе Microsoft Azure Well-Architected Framework.

Надёжность

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

Эта архитектура соответствует гарантии надежности в базовой архитектуре.

Целевые показатели надежности

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

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

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

Критические зависимости

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

Для этой архитектуры рассмотрим следующие зависимости:

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

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

• политики DINE: политики DINE для частных DNS-зон Azure DNS (или любой другой зависимости, предоставляемой платформой) осуществляются по принципу лучшего исполнения, без гарантии уровня обслуживания (SLA) на выполнение. Задержка в конфигурации DNS может привести к задержкам в готовности приложения к обработке трафика.

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

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

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

Безопасность

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

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

Элементы управления сетью

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

Входящий трафик

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

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

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

Исходный материал	Цель	Управление рабочей нагрузкой	Управление платформой
Интернет	Потоки трафика пользователей	Направляет все запросы через NSG, Брандмауэр веб-приложений и правила маршрутизации, чтобы разрешить переход общественного трафика в частный, который поступает в фронтенд виртуальные машины.	Отсутствует
Бастион Azure	Доступ оператора к виртуальным машинам	Группа безопасности сети в подсетях виртуальных машин, которая блокирует весь трафик к портам удаленного доступа, если его источник не находится в выделенной платформой подсети Бастион Azure.	Отсутствует
Другие периферийные компоненты	Отсутствует	Блокировка с помощью правил NSG	Нетранзитивная маршрутизация или правила Брандмауэр Azure в случае защищенного концентратора Виртуальная глобальная сеть Azure

Исходящий трафик

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

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

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

Конечная точка	Цель	Управление рабочей нагрузкой (NSG)	Управление платформой (хабом)
ntp.ubuntu.com	Протокол сетевого времени (NTP) для виртуальных машин Linux	UDP/123 в Интернете в подсети интерфейсной виртуальной машины (брандмауэр исходящего трафика сужает это широкое открытие)	Разрешение на сетевое правило брандмауэра такое же, как для управления рабочей нагрузкой
конечные точки клиентский компонент Центра обновления Windows	Функциональность клиентский компонент Центра обновления Windows с серверов компании Майкрософт	TCP/443 и TCP/80 в Интернете в подсети серверной виртуальной машины (брандмауэр исходящего трафика сужает это широкое открытие)	Правило квоты брандмауэра с тегом FQDN WindowsUpdate
Мониторинг конечных точек агента	Обязательный трафик для расширения Монитора на виртуальных машинах	TCP/443 в Интернете в обеих подсетях виртуальных машин (брандмауэр исходящего трафика сужает это широкое открытие)	Необходимые квоты правил приложения брандмауэра для всех конкретных полных доменных имен в TCP/443
nginx.org	Установка Nginx (пример компонента приложения) непосредственно от поставщика	TCP/443 в интернет на подсеть виртуальной машины на стороне фронтенда (брандмауэр для исходящего трафика ограничивает этот широкий доступ)	Необходимое разрешение для правила приложения брандмауэра для nginx.org на TCP/443
Хранилище ключей	Импорт сертификатов TLS в шлюзе приложений и виртуальных машинах	- TCP/443 в подсеть частной конечной точки из обеих подсетей виртуальной машины в подсеть частной конечной точки - TCP/443 из подсети шлюза приложений к подсети частной конечной точки - TCP/443 из виртуальных машин, помеченных назначением обязательной группы безопасности приложений (ASG), и из подсети шлюза приложений.	Отсутствует

Защита от атак DDos

Определите, кто отвечает за применение плана защиты от атак DDoS, охватывающего все общедоступные IP-адреса вашего решения. Команда платформы может использовать планы защиты IP-адресов или даже использовать Политика Azure для применения планов защиты виртуальных сетей. Эта архитектура должна иметь охват, так как она включает общедоступный IP-адрес для входящего трафика из Интернета.

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

Управление секретами

Для управления секретами эта архитектура соответствует базовой архитектуре.

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

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

Оптимизация затрат

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

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

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

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

• Брандмауэр Azure
• Сведения о безопасности и управление событиями (SIEM)
• хосты Бастион Azure
• Кросс-локальное подключение, например ExpressRoute

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

Дополнительные сведения см. в рекомендациях по сбору и просмотру данных о затратах.

Развертывание этого сценария

Доступна реализация этой эталонной архитектуры на GitHub.

Следующий шаг

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

Vending подписки