Рекомендации по приложениям для рабочих нагрузок Решение Azure VMware

  • Статья

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

К основным целям хорошо спроектированного приложения относятся:

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

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

Проектирование для обеспечения масштабируемости и эффективного распределения ресурсов

Влияние: надежность, эффективность производительности, безопасность

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

Использование доменов сбоя

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

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

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

Использование политик защиты от сходства vm-VM в трехуровневых приложениях

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

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

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

Схема архитектуры, показывающая трехуровневое приложение, сегментированное с помощью политик сходства vm-VM.

Рекомендации
  • Создавайте карты, показывающие взаимозависимости виртуальных машин, шаблоны взаимодействия и использования, чтобы гарантировать, что близость является обязательным требованием.
  • Определите, помогает ли политика размещения сходства виртуальных машин и виртуальных машин соответствовать метрикам производительности или соглашениям об уровне обслуживания ( SLA).
  • Проектируйте для обеспечения высокой доступности путем реализации политик размещения vm-VM anti-affinity для защиты от сбоев узлов и распределения приложения между несколькими узлами.
  • Чтобы избежать чрезмерной подготовки, распределите рабочую нагрузку между небольшими виртуальными машинами, а не между несколькими большими виртуальными машинами.
  • Регулярно отслеживайте, проверяйте и настраивайте политики сходства для выявления потенциальных состязаний за ресурсы. При необходимости адаптируйте эти политики с течением времени.

Использование политик сходства узлов виртуальной машины для изоляции производительности

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

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

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

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

Примечание

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

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

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

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

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

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

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

После развертывания приложений на виртуальных машинах рекомендуется использовать средство балансировки нагрузки, например Шлюз приложений Azure, для создания серверных пулов. Шлюз приложений — это управляемая подсистема балансировки нагрузки веб-трафика и служба доставки приложений, которая может управлять входящим трафиком HTTP и HTTPS в веб-приложения и оптимизировать их. В качестве точки входа для веб-трафика Шлюз приложений предлагает различные типы функциональных возможностей. Примеры включают завершение tls/SSL, маршрутизацию на основе URL-адресов, сходство сеансов и возможности брандмауэра веб-приложения.

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

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

Реализация завершения TLS/SSL и управления сертификатами

Шифрование TLS/SSL должно применяться для всех взаимодействий между приложением и браузерами пользователей. Это шифрование помогает защитить данные сеанса от перехвата и атак "злоумышленник в середине". Если приложению требуется завершение tls/SSL, настройте необходимый СЕРТИФИКАТ TLS/SSL в Шлюз приложений, чтобы разгрузить обработку TLS/SSL с внутренних виртуальных машин.

После создания TLS/SSL-сертификатов поместите их в службу, например Azure Key Vault, которая помогает безопасно хранить и получать к ним доступ. Для обновления и обновления сертификатов используйте PowerShell, Azure CLI или такие средства, как служба автоматизации Azure.

Управление интерфейсами API

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

На следующей схеме трафик от потребителей направляется в Управление API общедоступную конечную точку. Затем трафик пересылается в ИНТЕРФЕЙСы API серверной части, которые выполняются на Решение Azure VMware.

Схема архитектуры центра обработки данных Решение Azure VMware, подключенного к центральному концентратору. Концентратор размещает Шлюз приложений и Управление API.

Рекомендации
  • Чтобы повысить безопасность и производительность приложений Решение Azure VMware, используйте Шлюз приложений с Решение Azure VMware серверной части для распределения трафика в конечные точки приложения.
  • Убедитесь в наличии подключения между внутренними сегментами, на которых размещаются Решение Azure VMware, и подсетью, содержащей Шлюз приложений или подсистемой балансировки нагрузки.
  • Настройка работоспособности позволяет отслеживать работоспособность внутренних экземпляров.
  • Разгрузите завершение TLS/SSL для Шлюз приложений, чтобы снизить затраты на обработку на внутренних виртуальных машинах.
  • Безопасное хранение ключей TLS/SSL в хранилищах.
  • Оптимизируйте процессы, автоматив такие задачи, как обновление и продление сертификатов.

Оптимизация растянутых кластеров для повышения непрерывности бизнес-процессов и готовности к аварийному восстановлению

Влияние: надежность

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

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

Схема архитектуры, показывающая растянутый кластер vSAN между двумя зонами доступности. Третья зона содержит следящий сервер vSAN.

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

Настройка отказоустойчивости и сбоя политик (FTT)

Общая емкость приложения зависит от нескольких переменных. Примеры включают конфигурацию избыточного массива независимых дисков (RAID), значение атрибута failures to tolerate и политики отказа (FTT), которые управляют количеством сбоев, которые могут допускаться системой хранения. Командам приложений необходимо определить уровень избыточности, необходимый для приложения. Важно также отметить, что более высокие значения FTT повышают устойчивость данных, но увеличивают затраты на хранилище.

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

Настройка политик синхронизации данных и хранения

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

Владелец приложения может определить политику хранилища, чтобы обеспечить следующее:

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

Примеры политик могут включать следующие факторы:

  • Конфигурация vSAN. Используйте VMware vSAN с растянутыми кластерами между зонами доступности.
  • Количество неудач, допускаемых. Настройте политику так, чтобы она допускала по крайней мере один или несколько сбоев. Например, используйте макет RAID-1.
  • Производительность. Настройте параметры, связанные с производительностью, чтобы оптимизировать операции ввода-вывода в секунду и задержку для критически важных виртуальных машин.
  • Правила сходства. Настройте правила сопоставления, чтобы обеспечить размещение виртуальных машин или групп виртуальных машин в отдельных узлах или доменах сбоя в растянутом кластере, чтобы обеспечить максимальную доступность во время сбоев центра обработки данных.
  • Резервное копирование и репликация. Укажите интеграцию с решениями резервного копирования и репликации, чтобы обеспечить регулярное резервное копирование и репликацию данных виртуальных машин в дополнительное расположение для дополнительной защиты данных.
Рекомендации
  • Определите политики хранения данных в vSAN, чтобы указать избыточность и производительность, необходимые для различных дисков виртуальных машин.
  • Настройте приложения для запуска в конфигурации "активный — активный" или "активный — пассивный", чтобы критически важные компоненты приложений могли завершиться сбоем во время сбоев центра обработки данных.
  • Изучите требования к сети каждого приложения. Приложения, выполняемые в зонах доступности, могут нести более высокую задержку, чем приложения с трафиком в пределах зоны доступности. Проектируйте приложение так, чтобы оно допускали эту задержку.
  • Выполните тесты производительности для политик размещения, чтобы оценить их влияние на приложение.

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

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

Сеть

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

Оценка