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

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

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

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

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

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

Макет статьи

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

Архитектура

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

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

Компоненты

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

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

• Azure Виртуальные машины служит вычислительным ресурсом для приложения и распределяется по зонам доступности. В целях иллюстрации используется сочетание виртуальных машин Windows и Linux.

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

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

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

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

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

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

• Внутренняя подсистема балансировки нагрузки Azure направляет трафик с внешнего уровня на внутренние серверы.

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

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

Вспомогательные ресурсы рабочей нагрузки

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

• Приложение Аналитика собирает журналы и метрики из приложения. Так как приложение не является фокусом этой архитектуры, коллекция журналов не демонстрируется в реализации.

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

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

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

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

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, путем обнаружения изменений и установки соответствующих сертификатов.
  • Расширение работоспособности приложений с Масштабируемые наборы виртуальных машин важно, если azure Масштабируемые наборы виртуальных машин выполняет автоматическое последовательное обновление. Azure использует мониторинг работоспособности отдельных экземпляров для выполнения обновлений. Вы также можете использовать расширение для мониторинга работоспособности приложения каждого экземпляра в масштабируемом наборе и выполнения восстановления экземпляров с помощью автоматического восстановления экземпляров.
  • Идентификатор Microsoft Entra и OpenSSH (Windows, Linux) интегрируются с проверкой подлинности Microsoft Entra. Теперь вы можете использовать идентификатор Microsoft Entra в качестве основной платформы проверки подлинности и центра сертификации для SSH на виртуальной машине Linux с помощью идентификатора Microsoft Entra ID и проверки подлинности на основе сертификата OpenSSH. Эта функция позволяет управлять доступом к виртуальным машинам с помощью политик управления доступом на основе ролей Azure (RBAC) и политик условного доступа.

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

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

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

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

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

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

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

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

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

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

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

Disks

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

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 для этой архитектуры.

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

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

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

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

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

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

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

Разрешение DNS

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

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

Наблюдение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сеть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Помните о компромиссе по затратам, связанным с чрезмерной подготовкой.

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

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

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

Надежность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Составной SLO: 99,94% | Простой в год: 0d 5h 15m 20s

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

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

Составной SLO: 99,34% | Простой в год: 2d 9h 42m 18s

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример развертывания для этой архитектуры можно найти на портале GitHub.

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

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

• Виртуальные машины Azure
• Масштабируемые наборы виртуальных машин Azure
• Виртуальная сеть Azure
• Шлюз приложений Azure Standard_v2
• Azure Load Balancer
• Azure Key Vault
• Бастион Azure
• Application Insights
• Служба Log Analytics

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

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

• Приложение уровня Windows N с помощью SQL Server в Azure