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

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

Пример рабочей нагрузки, предполагаемой этой архитектурой, — это многоуровневое веб-приложение, которое развертывается на отдельных наборах виртуальных машин . Виртуальные машины подготавливаются в рамках развертывания Azure Virtual Machine Scale Sets. Эту архитектуру можно использовать для следующих сценариев:

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

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

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

Макет статьи

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

Архитектура

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

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

Компоненты

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

Ресурсы рабочей нагрузки

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

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

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

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

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

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

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

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

  SKU "Стандартный" предоставляет доступ в интернет для виртуальных машин с помощью трех общедоступных IP-адресов.

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

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

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

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

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

Маршруты пользователей

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

Пользователь рабочей нагрузки

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

2. Шлюз приложений получает HTTPS-трафик, расшифровывает данные с помощью внешнего сертификата для проверки WAF и повторно шифрует их с помощью внутреннего подстановочного сертификата для передачи на фронтенд.

3. Шлюз приложений балансирует трафик между интерфейсными виртуальными машинами и пересылает запрос на интерфейсную виртуальную машину.

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

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

Оператор

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

1. Оператор входит на портал Azure или Azure CLI.
2. Оператор обращается к службе Бастион Azure и удаленно подключается к нужной виртуальной машине.

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

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

• Операции ввода-вывода процессора (ЦП), памяти и диска в секунду (IOPS).
• Архитектура процессоров.
• Размер образа операционной системы (ОС).

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

Для информации о поддерживаемых SKU виртуальных машин см. раздел Размеры виртуальных машин в Azure.

Начальная загрузка

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

• Расширения виртуальных машин. Эти расширения являются объектами Azure Resource Manager, которые управляются через развертывание с использованием Infrastructure-as-Code (IaC). Таким образом, любой сбой сообщается как ошибочное развертывание, с которым можно предпринять меры. Если для начальной загрузки нет расширения, создайте пользовательские скрипты. Рекомендуется запускать скрипты с помощью расширения пользовательского скрипта Azure.

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

  • Azure Monitor Агент (AMA) собирает данные мониторинга из гостевой ОС и передает его Azure Monitor.
  • Расширение пользовательского скрипта Azure (Windows, Linux) версии 2 загружает и запускает скрипты на виртуальных машинах Azure. Это расширение удобно для автоматизации конфигурации после развертывания, установки программного обеспечения или других задач настройки или управления.
  • расширение виртуальной машины Azure Key Vault (Windows, Linux) обеспечивает автоматическое обновление сертификатов, хранящихся в Key Vault путем обнаружения изменений и установки соответствующих сертификатов.
  • расширение Application Health с Масштабируемые наборы виртуальных машин важно, если Azure Virtual Machine Scale Sets выполняет автоматическое последовательное обновление. Azure зависит от мониторинга работоспособности отдельных экземпляров для выполнения обновлений. Вы также можете использовать расширение для мониторинга работоспособности приложения каждого экземпляра в масштабируемом наборе и выполнения восстановления экземпляров с помощью автоматического восстановления экземпляров.
  • Microsoft Entra ID и OpenSSH (Windows, Linux) интегрируются с проверкой подлинности Microsoft Entra. Теперь вы можете использовать Microsoft Entra ID в качестве основной платформы проверки подлинности и центра сертификации для SSH на виртуальной машине Linux с помощью проверки подлинности на основе сертификатов Microsoft Entra ID и OpenSSH. Эта функция позволяет управлять доступом к виртуальным машинам с помощью Azure управления доступом на основе ролей (Azure RBAC) и политик условного доступа.

• Агентно-ориентированная конфигурация. Виртуальные машины Linux могут использовать легковесную нативную конфигурацию желаемого состояния, доступную через cloud-init в различных образах виртуальных машин, предоставленных Azure. Конфигурация задается и контролируется по версиям вместе с артефактами IaC. Создание собственного решения по управлению конфигурацией является другим способом. Большинство решений следует декларативному подходу к начальной загрузке, но поддерживают пользовательские скрипты для гибкости. Популярные варианты включают Desired State Configuration для Windows, Desired State Configuration для Linux, Ansible, Chef, Puppet и других. Все эти решения конфигурации можно связать с расширениями виртуальных машин для оптимального взаимодействия.

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

Ознакомьтесь с хорошо спроектированной платформой: RE:02 — рекомендации по проектированию автоматизации.

Подключение к виртуальной машине

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

Если рабочая нагрузка нуждается в низкой задержке связи между виртуальными машинами в виртуальной сети, рассмотрите возможность ускорения сети, которая поддерживается сетевыми адаптерами виртуальных машин Azure. Дополнительные сведения см. в разделе "Преимущества ускорения сети".

Наборы масштабирования виртуальных машин с гибкой оркестрацией

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

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

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

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

Диски

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

Azure предоставляет ряд вариантов с точки зрения производительности, универсальности и стоимости. Начните с SSD уровня "Премиум" для большинства рабочих нагрузок. Выбор зависит от номера SKU виртуальной машины. Номера SKU, поддерживающие SSD класса Premium, содержат s в имени ресурса, например Dsv4, но не Dv4.

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

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

• Ограничения SKU ВМ. Диски работают в виртуальной машине, к которой они подключены, с ограничениями операций ввода-вывода в секунду и пропускной способностью. Убедитесь, что диск не ограничивает ограничения виртуальной машины и наоборот. Выберите размер диска, производительность и возможности виртуальной машины (ядро, ЦП, память), которые оптимально выполняют компонент приложения. Избегайте переизбытка ресурсов, так как это влияет на затраты.

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

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

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

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

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

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

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

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

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

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

При использовании этой архитектуры:

• Диски ОС всех виртуальных машин являются временными и расположены на диске кэша.

  Программа рабочей нагрузки в клиентской части (Linux) и серверной части (Windows Server) терпима к сбоям отдельных виртуальных машин и использует небольшие образы (около 30 ГБ). Такие атрибуты позволяют использовать диски Эфемерной ОС, созданные в рамках локального хранилища виртуальной машины (секции кэша), а не диска постоянной ОС, сохраненного в удаленных Azure ресурсах хранилища. В этой ситуации нет затрат на хранение дисков ОС, а также повышает производительность, обеспечивая более низкую задержку и сокращая время развертывания виртуальной машины.

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

Макет сети

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

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

Виртуальная сеть

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

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

В этой архитектуре адресное пространство установлено в /21, решение было принято на основе прогнозируемого роста.

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

В виртуальной сети подсети делятся на функциональность и требования к безопасности, как описано ниже.

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

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

Другим вариантом использования является обновление ОС виртуальной машины, для которого могут потребоваться временные IP-адреса. Оптимизация ресурсов обеспечивает требуемый уровень сегментации, гарантируя, что аналогичные ресурсы правильно группируются, чтобы значимые правила безопасности с помощью групп безопасности сети (NSG) могли быть применены к границам подсети. Дополнительные сведения см. в разделе "Безопасность: сегментация".

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

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

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

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

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

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

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

Рекомендуется выделить порты на основе максимального числа бекенд-экземпляров. Если количество добавленных экземпляров превышает доступное количество оставшихся портов SNAT, операции масштабирования Масштабируемые наборы виртуальных машин могут быть заблокированы, или новые виртуальные машины не будут иметь достаточного количества портов SNAT.

Вычислите порты для каждого экземпляра следующим Number of front-end IPs * 64K / Maximum number of back-end instancesобразом:

Существуют другие варианты, которые можно использовать, например развертывание ресурса Azure NAT Gateway, подключенного к подсети. Другим вариантом является использование Брандмауэр Azure или другого сетевого виртуального устройства с пользовательским определяемым пользователем маршрутом (UDR) в качестве следующего прыжка через брандмауэр. Этот параметр показан в базовой архитектуре виртуальной машины в зоне высадки Azure.

Разрешение DNS

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

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

Наблюдение

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

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

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

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

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

На этом рисунке показан стек мониторинга для базового плана с компонентами для сбора данных из инфраструктуры и приложения, приемников данных и различных средств потребления для анализа и визуализации. Реализация развертывает некоторые компоненты, такие как Application Insights, диагностика загрузки виртуальных машин и Log Analytics. Другие компоненты показаны для демонстрации параметров расширяемости, таких как панели мониторинга и оповещения.

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

Мониторинг на уровне инфраструктуры

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

ресурс Azure	Метрики и журналы	Оповещения
Шлюз приложений	описание метрик и журналов Шлюз приложений	Оповещения шлюза приложений
Application Insights	Метрики Application Insights и API OpenTelemetry	Application Insights оповещения
Бастион Azure	Метрики Бастион Azure
Хранилище ключей	Описания метрик и журналов Key Vault	оповещения Key Vault
Балансировщик нагрузки	Журналы и метрики подсистемы балансировки нагрузки	Оповещения для Балансировщика нагрузки
Общедоступный IP-адрес	Описание метрик и журналов общедоступного IP-адреса	Оповещения о метриках общедоступных IP-адресов
виртуальная сеть	Справочник по метрикам и журналам виртуальной сети	Оповещения виртуальной сети
Виртуальные машины и наборы виртуальных машин.	Справочник по метрикам и журналам виртуальных машин	Оповещения и руководства по виртуальным машинам
Брандмауэр веб-приложений	Описание метрик и журналов Брандмауэр веб-приложений	Оповещения брандмауэра для веб-приложений.

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

Виртуальные машины

Диагностика загрузки Azure включена, чтобы наблюдать за состоянием виртуальных машин во время загрузки путем сбора информации из последовательных журналов и снимков экрана. В данной архитектуре данные доступны через портал Azure и команду Azure CLI vm boot-diagnostics get-boot-log. Azure управляет данными. У вас нет контроля или доступа к базовому ресурсу хранилища. Но если бизнес-требования подразумевают больший контроль, вы можете создать собственный аккаунт хранилища для сохранения диагностических данных загрузки.

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

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

Сеть

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

Управляемые диски

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

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

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

Мониторинг на уровне приложения

Несмотря на то, что эталонная реализация не использует ее, Application Insights подготавливается в качестве APM для целей расширяемости. Используйте дистрибуцию OpenTelemetry Azure Monitor для инструментирования вашего приложения и отправки данных в рабочую область Log Analytics. Application Insights также может визуализировать эти данные из приложений рабочей нагрузки.

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

Управление обновлениями

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

Обновления инфраструктуры

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

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

Некоторые рабочие нагрузки могут не допускать даже нескольких секунд замораживания или отключения виртуальной машины для обслуживания. Для более полного контроля над всеми действиями обслуживания, включая обновления, не влияющие на работу системы и не требующие перезагрузки, см. в разделе «Конфигурации обслуживания». Создание конфигурации обслуживания позволяет пропустить все обновления платформы и применить обновления в удобном режиме. Если задана настраиваемая конфигурация, Azure пропускает все обновления с ненулевым влиянием, включая обновления, не требующие перезагрузки системы. Дополнительные сведения см. в разделе "Управление обновлениями платформы с помощью конфигураций обслуживания"

Обновление образа операционной системы (ОС)

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

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

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

Вы можете использовать Azure Update Management для управления обновлениями ОС для виртуальных машин Windows и Linux в Azure. Диспетчер обновлений Azure предоставляет решение SaaS для управления обновлениями программного обеспечения Windows и Linux в облаке Azure, на локальных и многооблачных средах.

Исправление гостевой ОС

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

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

Для управления воспользуйтесь автоматическим обновлением образа ОС на Масштабируемые наборы виртуальных машин в рамках политики Azure.

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

Учтите компромисс по затратам, связанным с избыточным распределением.

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

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

Для виртуальных машин Windows следуйте рекомендациям из статьи «Масштабируемое управление исправлениями виртуальных машин Windows», чтобы реализовать поэтапный, управляемый процесс установки исправлений с использованием запланированного исправления в Диспетчер обновлений Azure, динамического определения области действия и отчетности о соответствии требованиям.

Соображения

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

Надежность

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

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

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

Все остальные компоненты в этой архитектуре являются либо:

• Зональная избыточность означает, что они реплицируются в нескольких зонах для обеспечения высокой доступности, таких как Шлюз приложений или публичные IP-адреса.
• Устойчивость к сбоям в зоне, подразумевая, что они могут противостоять таким сбоям, как, например, Key Vault.
• Региональные или глобальные ресурсы, доступные в разных регионах или глобально, например Microsoft Entra ID.

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

Стратегии, используемые в архитектуре, основаны на контрольном списке проверки надежности, приведенном в Azure Well-Architected Framework. Разделы аннотированы с рекомендациями из этого контрольного списка.

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

Приоритеты гарантий надежности для каждого потока пользователя

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

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

Ознакомьтесь с хорошо спроектированной платформой: RE:02 — рекомендации по выявлению и оценке потоков.

Определение потенциальных точек сбоя

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

Компонент	Риск	Вероятность	Эффект/смягчение/примечание	Отключение
Microsoft Entra ID	Неправильные настройки	Средняя	Пользователи Ops не могут войти в систему. Нет последующего эффекта. Служба технической поддержки сообщает о проблеме с конфигурацией команде по управлению идентификацией.	нет
Шлюз приложений	Неправильные настройки	Средняя	Во время развертывания ошибки конфигурации должны быть обнаружены. Если эти ошибки возникают во время обновления конфигурации, команда DevOps должна откатить изменения. Большинство развертываний, использующих номер SKU версии 2, занимает около шести минут для подготовки. Однако для некоторых типов развертывания может потребоваться больше времени. Например, развертывания в нескольких зонах доступности с большим количеством экземпляров могут занять более шести минут.	Полностью
Шлюз приложений	Атака DDoS	Средняя	Потенциальные сбои. Корпорация Майкрософт управляет защитой от атак DDoS (L3 и L4). Потенциальный риск воздействия атак L7.	Полностью
Масштабируемые наборы виртуальных машин	Перебой в работе службы	Низкий	Возможный сбой рабочей нагрузки при наличии неработоспособных экземпляров виртуальных машин, которые активируют автоматическое восстановление. Зависит от корпорации Майкрософт для устранения проблемы.	Потенциальный сбой
Масштабируемые наборы виртуальных машин	Сбой зоны доступности	Низкий	Не влияет. Масштабируемые наборы развертываются с избыточностью по зонам.	нет

Ознакомьтесь с хорошо спроектированной архитектурой: RE:03 — рекомендации по выполнению анализа отказов.

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

Для принятия решений по проектированию важно вычислить целевые показатели надежности, такие как составные цели уровня обслуживания (SLOS) рабочей нагрузки. Это предполагает понимание соглашений об уровне обслуживания, предоставляемых службами Azure, используемыми в архитектуре. Целевые показатели уровня обслуживания (SLO) для рабочей нагрузки не должны превышать обязательства, определенные в соглашениях об уровне обслуживания Azure. Тщательно изучите каждый компонент из виртуальных машин и их зависимостей, параметров сети и хранилища.

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

Поток операций

Компонент	SLO
Microsoft Entra ID	99,99 %
Бастион Azure	99,95 %

Составной SLO: 99,94% | Время простоя в год: 0д 5ч 15м 20с

Поток пользователя приложения

Компонент	SLO
Шлюз приложений	99,95 %
Azure Load Balancer (внутренний)	99,99 %
Клиентские виртуальные машины, использующие премиальное хранилище (составной SLO)	99,70 %
Серверные виртуальные машины, использующие хранилище класса Premium (составной SLO)	99,70 %

Составной SLO: 99,34% | Простой в год: 2 д 9 ч 42 м 18 с

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

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

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

Ознакомьтесь с хорошо спроектированной платформой: RE:04 — рекомендации по определению целевых показателей надежности.

Избыточность

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

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

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

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

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

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

• Azure предлагает устойчивые к зонам службы для повышения надежности, например Key Vault.

• Глобальные ресурсы Azure всегда доступны и при необходимости могут переключиться на другой регион, например, основной поставщик удостоверений Microsoft Entra ID.

Ознакомьтесь с хорошо архитектированным фреймворком: RE:05 — рекомендации для проектирования с учётом избыточности.

Стратегия масштабирования

Чтобы предотвратить снижение уровня обслуживания и сбои, убедитесь в надежных операциях масштабирования. Масштабируйте рабочую нагрузку по горизонтали (масштабирование наружу), по вертикали (масштабирование вверх) или используйте сочетание обоих подходов. Используйте Azure Monitor Autoscale для подготовки достаточного объема ресурсов для поддержки спроса на ваше приложение, не выделяя избыточной емкости и избегая ненужных затрат.

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

Хотя Azure Virtual Machine Scale Sets в гибком режиме поддерживает разнородные среды, автоматическое масштабирование нескольких профилей не поддерживается. Рассмотрите возможность создания различных масштабируемых наборов для управления ими отдельно, если планируется использовать автомасштабирование с несколькими типами виртуальных машин.

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

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

Ознакомьтесь с хорошо спроектированной платформой: RE:06 — рекомендации по проектированию надежной стратегии масштабирования.

Самовосстановление и возможность восстановления

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

Ознакомьтесь с Well-Architected Framework: рекомендации по самовосстановлению и самосохранению.

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

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

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

Сегментация (Segmentation)

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

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

• Сегментация идентификаторов. Назначайте отдельные роли различным идентичностям с необходимыми разрешениями для выполнения их задачи. Эта архитектура использует удостоверения, управляемые Microsoft Entra ID, для сегментирования доступа к ресурсам.

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

Ознакомьтесь с хорошо спроектированной платформой: SE:04 — рекомендации по созданию стратегии сегментации.

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

Мы рекомендуем Microsoft Entra ID для проверки подлинности и авторизации пользователей и служб.

Для доступа к виртуальным машинам требуется учетная запись пользователя, контролируемая Microsoft Entra ID аутентификацией и поддерживаемая группами безопасности. Эта архитектура обеспечивает поддержку путем развертывания расширения проверки подлинности Microsoft Entra ID на всех виртуальных машинах. Мы рекомендуем пользователям использовать корпоративные удостоверения в Microsoft Entra ID клиента организации. Убедитесь, чтобы доступ на основе доверенности службы не делится между функциями.

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

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

Базовая архитектура использует сочетание назначаемых системой и назначаемых пользователем управляемых удостоверений. Эти удостоверения необходимы для использования Microsoft Entra ID для авторизации при доступе к другим ресурсам Azure.

Ознакомьтесь с хорошо спроектированной платформой: SE:05 — рекомендации по управлению удостоверениями и доступом.

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

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

  Дополнительная безопасность обеспечивается с помощью Брандмауэр веб-приложений, интегрированной с шлюзом приложений. Он имеет правила, которые проверяют входящий трафик и могут принимать соответствующие меры. WAF отслеживает уязвимости Open Web Application Security Project (OWASP), предотвращающие известные атаки.

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

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

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

• Рабочий трафик. Рекомендуется обеспечить безопасный рабочий доступ к рабочей нагрузке через Бастион Azure, что устраняет необходимость общедоступного IP-адреса. В этой архитектуре эта связь выполняется по протоколу SSH и поддерживается как Windows, так и виртуальными машинами Linux. Microsoft Entra ID интегрирован с SSH для обоих типов виртуальных машин с помощью соответствующего расширения виртуальной машины. Эта интеграция позволяет удостоверению оператора проходить проверку подлинности и авторизоваться через Microsoft Entra ID.

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

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

  Для повышения безопасности используйте Microsoft Entra управление привилегированными пользователями (PIM). PIM — это служба в Microsoft Entra ID, которая позволяет управлять, контролировать и отслеживать доступ к важным ресурсам в организации. Управление привилегированными идентификациями (PIM) обеспечивает активацию ролей на основе времени и утверждения, чтобы снизить риски, связанные с избыточными, ненужными или неправомерными разрешениями на доступ к важным для вас ресурсам.

• Частное подключение к платформенным службам (PaaS). Обмен данными между виртуальными машинами и "Key Vault" осуществляется через сервис "Приватный канал". Для этой службы требуются частные конечные точки, которые помещаются в отдельную подсеть.

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

Ознакомьтесь с хорошо спроектированной платформой: SE:06 — рекомендации по сети и подключению.

Шифрование

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

  • app.contoso.com: внешний сертификат, используемый клиентами и Шлюз приложений для безопасного общедоступного интернет-трафика.
  • *.workload.contoso.com: универсальный сертификат, используемый компонентами инфраструктуры для защищённого внутреннего трафика.

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

Ознакомьтесь с хорошо спроектированной платформой: SE:07 — рекомендации по шифрованию данных.

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

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

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

Виртуальные машины используют расширение Key Vault виртуальной машины для автоматического обновления отслеживаемых сертификатов. Если в локальном хранилище сертификатов обнаружены какие-либо изменения, расширение извлекает и устанавливает соответствующие сертификаты из Key Vault. Расширение поддерживает типы контента сертификатов PKCS #12 и PEM.

Ознакомьтесь с хорошо спроектированной платформой: SE:09 — рекомендации по защите секретов приложений.

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

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

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

Затраты на компоненты

Выберите образы виртуальных машин, оптимизированные для рабочей нагрузки вместо использования образов общего назначения. В этой архитектуре для Windows и Linux выбираются относительно небольшие образы виртуальных машин, по 30 ГБ каждый. При использовании небольших образов номера SKU виртуальных машин с дисками также меньше, что приводит к снижению затрат, снижению потребления ресурсов и более быстрому развертыванию и времени загрузки. Преимуществом является повышение безопасности из-за уменьшения площади поверхности.

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

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

Ознакомьтесь с хорошо спроектированной платформой: CO:07 — рекомендации по оптимизации затрат на компоненты.

Поток затрат

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

Ознакомьтесь с Хорошо архитектурированной системой: CO:09 — рекомендации по оптимизации затрат на работу потоков.

Масштабирование затрат

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

• Лицензирование программного обеспечения. Более крупные виртуальные машины могут обрабатывать больше рабочих нагрузок, что может снизить количество необходимых лицензий на программное обеспечение.
• Время обслуживания: меньшее количество крупных виртуальных машин может снизить эксплуатационные затраты.
• Балансировка нагрузки. Меньше виртуальных машин может привести к снижению затрат на балансировку нагрузки. Например, в этой архитектуре существует несколько уровней балансировки нагрузки, например шлюз приложений на переднем крае и внутренней подсистеме балансировки нагрузки в середине. Затраты на балансировку нагрузки будут увеличиваться, если необходимо управлять большим количеством экземпляров.
• Хранилище дисков. Если существуют приложения с отслеживанием состояния, больше экземпляров нуждаются в более подключенных управляемых дисках, увеличивая затраты на хранение.

Ознакомьтесь с хорошо спроектированной платформой: CO:12 — рекомендации по оптимизации затрат на масштабирование.

операционные расходы;

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

Ознакомьтесь с хорошо спроектированной платформой: CO:13 — рекомендации по оптимизации времени персонала.

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

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

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

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

• Виртуальные машины Azure
• Azure Наборы масштабирования виртуальных машин
• Виртуальная сеть Azure
• Шлюз приложений Azure Standard_v2
• Azure Load Balancer
• Хранилище ключей Azure
• Бастион Azure
• Аналитика приложений
• Log Analytics

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

Просмотрите эталонные архитектуры IaaS, показывающие параметры уровня данных:

• Windows многоуровневое приложение, использующее SQL Server на Azure