Что такое Решение Azure VMware?

Решение Azure VMware предоставляет частные облака, содержащие кластеры VMware vSphere, построенные на выделенной безвиртуальной инфраструктуре Azure. Решение Azure VMware доступен в Azure Commercial и Azure для государственных организаций. Минимальное начальное развертывание — три узла с возможностью добавления дополнительных узлов до 16 узлов на кластер. Все подготовленные частные облака имеют VMware vCenter Server, VMware vSAN, VMware vSphere и VMware NSX. В результате можно перенести рабочие нагрузки из локальных сред, развернуть новые виртуальные машины и использовать Azure службы из частных облаков. Информация об уровне обслуживания смотрите на странице соглашения об уровне обслуживания Azure.

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

На схеме показана зависимость между частными облаками и виртуальными сетями в Azure, службах Azure и локальных средах. Сетевой доступ из частных облаков к службам Azure или виртуальным сетям (VNet) обеспечивает интеграцию конечных точек служб Azure на основе SLA. ExpressRoute Global Reach подключает локальную среду к вашему Решение Azure VMware частному облаку.

Решение Azure VMware типы частных облаков

Решение Azure VMware предоставляет два разных поколения частного облака:

1. Решение Azure VMware поколения 1 предоставляет кластеры VMware vSphere, созданные на основе выделенных физических серверов, развернутых в центрах обработки данных Azure. каналы Microsoft управляемых ExpressRoute обеспечивают подключение между узлами VMware vSphere и собственными ресурсами Azure, развернутыми в виртуальных сетях.

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

Узлы, кластеры и частные облака

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

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

Все предыдущие типы узлов имеют пропускную способность сетевого интерфейса 100 Гбит/с.

*Сведения доступны через калькулятор цен Azure.

Предварительные требования для AV64: перед добавлением AV64 требуется частное облако Решение Azure VMware, развернутое с использованием AV36, AV36P, AV48 или AV52.

Raw соответствует международному стандарту единиц (SI), сообщаемому производителями дисков. Пример: 1 ТБ Raw = 100000000000000 байт. Пространство, вычисляемое компьютером в двоичном файле (1 ТБ двоичного файла = 1099511627776 байтов) равно 931,3 гигабайтам, преобразованным из необработанного десятичного разряда.

ESA применяется к развертываниям AV64 Gen 2.

Вы можете развернуть новые или масштабировать существующие частные облака с помощью портала Azure или Azure CLI.

Расширение частного облака Решение Azure VMware с узлом размера AV64

AV64 — это SKU узла Решение Azure VMware, который доступен для расширения Решение Azure VMware частного облака, созданного с использованием существующего SKU AV36, AV36P или AV52. Если вы хотите развернуть AV64 напрямую, обратитесь к Решение Azure VMware в Azure Virtual Network. Используйте документацию Microsoft для проверки доступности номера SKU AV64 в регионе.

Требования для расширения AV64 на AV36, AV36P и AV52

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

• Частное облако решения VMware Azure создается с помощью AV36, AV36P, AV48 или AV52 в AV64, поддерживаемом region/AZ.

• Для управления кластерами AV64 вам потребуется один блок адресов /23 или три (смежные или несмежные) /25.

Поддержка сценариев клиента

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

1. Получите утверждение квоты AV64 от Microsoft как минимум с тремя узлами. Добавьте другие сведения о частном облаке Решение Azure VMware, которое планируется расширить с помощью AV64.
2. Используйте существующий рабочий процесс добавления кластера в Решение Azure VMware с узлами AV64 для расширения.

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

1. Получите утверждение квоты на AV36, AV36P, AV52 и AV64 от Microsoft при условии наличия не менее трех узлов каждый.
2. Создайте частное облако Решение Azure VMware с помощью SKU AV36, AV36P или AV52.
3. Используйте существующий рабочий процесс добавления кластера в Решение Azure VMware с узлами AV64 для расширения.

Частное облако с растянутыми кластерами Решение Azure VMware: SKU AV64 не поддерживается в частном облаке с растянутыми кластерами Решение Azure VMware. Это означает, что расширение на основе AV64 невозможно для частного облака растянутых кластеров в Решение Azure VMware.

Улучшенная совместимость vMotion (EVC) с расширением AV64

Добавление узлов AV64 в частное облако Решение Azure VMware создает разнородную среду, что приводит к проблемам Enhanced vMotion Compatibility (EVC) между кластерами AV64 и базовыми кластерами, использующими SKU AV36, AV36P или AV52. Кластеры AV64 используют режим EVC Icelake из-за процессоров Intel Icelake, в то время как кластеры AV36, AV36P и AV52, созданные на старых ЦП Intel, не имеют явного режима EVC. Дополнительные сведения о поколениях ЦП для каждого номера SKU приведены выше.

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

• vMotion к кластеру AV64 из базового кластера SKU — это работает хорошо, так как виртуальная машина перемещена из кластера с более низким режимом EVC в кластер с более высоким режимом EVC.

• vMotion для базового кластера SKU из кластера AV64 — два сценария

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

  • Если виртуальная машина была создана в кластере AV64 или в цикле питания, даже если она была ранее vMotioned из базового кластера SKU, live vMotion завершится ошибкой совместимости EVC.

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

Проектирование и рекомендации по отказоустойчивому домену в кластере AV64 vSAN.

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

Кластеры узлов AV64 в Решение Azure VMware имеют конфигурацию домена сбоя vSAN с явно заданными параметрами. Решение Azure VMware контрольная плоскость настраивает семь доменов отказов vSAN (FD) для кластеров AV64. Хосты равномерно распределяются по семи FD, когда пользователи масштабируют хосты в кластере с трёх узлов до 16 узлов. Некоторые регионы Azure по-прежнему поддерживают не более пяти FD в рамках первичного выпуска SKU AV64. Для получения дополнительной информации обратитесь к таблице сопоставления типа узлов для зоны доступности региона Azure.

Рекомендация по размеру кластера

Минимальный поддерживаемый размер кластера vSphere для Решение Azure VMware — три узла. Избыточность данных vSAN обрабатывается путем обеспечения минимального размера кластера трех узлов в разных FD VSAN. В кластере vSAN с тремя узлами, каждый из которых находится в отдельной зоне отказа (FD), если произойдет сбой в одной из них (например, если выйдет из строя коммутатор верхней стойки), данные vSAN будут защищены. Сбой таких операций, как создание объектов (новая виртуальная машина, VMDK и другие). То же самое относится к любым действиям по обслуживанию, когда узел ESXi помещается в режим обслуживания и (или) перезагружается. Чтобы избежать таких сценариев, рекомендуется развернуть кластеры vSAN с четырьмя узлами ESXi.

Рабочий процесс удаления узла AV64 и рекомендации

Из-за конфигурации домена сбоя кластера AV64 vSAN (FD) и необходимости балансировки узлов по всем FD, процесс удаления узла из кластера AV64 отличается от процесса удаления в традиционных кластерах узлов Решение Azure VMware с другими номерами SKU.

В настоящее время пользователь может выбрать один или несколько узлов, которые будут удалены из кластера с помощью портала или API. Одно из условий заключается в том, что кластер должен иметь не менее трех хостов. Однако кластер AV64 работает по-разному в определенных сценариях, когда AV64 использует FD vSAN. Любой запрос на удаление узла проверяется на потенциальный дисбаланс FD vSAN. Если запрос на удаление узла создает дисбаланс, он отклоняется с ответом "HTTP 409-Conflict". Код состояния ответа http 409-Conflict указывает на конфликт запроса с текущим состоянием целевого ресурса (узлов).

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

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

  

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

  

• Удаление выбранного хоста приводит к тому, что в системе остается менее трех активных vSAN FDs. Этот сценарий маловероятен, учитывая, что все регионы AV64 имеют по пять или семь FDs. Добавляя узлы, плоскость управления Решение Azure VMware заботится о добавлении узлов из всех семи FD равномерно. В следующем примере пользователи могут удалить одного из хостов из FD 1, но не из FD 2 или 3.

  

Как определить узел, который можно удалить, не вызывая дисбаланс fD vSAN: пользователь может перейти к интерфейсу клиента vSphere, чтобы получить текущее состояние FD и узлов vSAN, связанных с каждым из них. Это помогает определить узлы (на основе предыдущих примеров), которые можно удалить без влияния на баланс FD vSAN и избежать ошибок в операции удаления.

Конфигурация RAID, поддерживаемая AV64

Эта таблица содержит список поддерживаемых конфигураций RAID и требований к узлу в кластерах AV64. Политики RAID-6 FTT2 и RAID-1 FTT3 поддерживаются с SKU AV64 в некоторых регионах. В Azure регионах, которые в настоящее время ограничены пятью FD, Microsoft позволяет клиентам использовать политику хранения RAID-5 FTT1 vSAN для кластеров AV64 с шестью или более узлами для соответствия соглашению об уровне обслуживания (SLA). Для получения дополнительной информации обратитесь к таблице сопоставления типа узлов для зоны доступности региона Azure.

Storage

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

Networking

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

При развертывании частного облака создаются частные сети для управления, разграничения ресурсов и vMotion. Эти частные сети используются для доступа к VMware vCenter Server и VMware NSX Manager и виртуальной машине vMotion или развертыванию.

ExpressRoute Global Reach используется для подключения частных облаков к локальным средам. Он подключает цепи непосредственно на уровне Microsoft Edge. Для подключения к локальной среде в вашей подписке требуется виртуальная сеть (vNet) и канал ExpressRoute для связи с локальной инфраструктурой. Причина заключается в том, что шлюзы виртуальной сети (шлюзы ExpressRoute) не могут передавать трафик, что означает, что вы можете подключить два канала к одному шлюзу, но он не отправляет трафик из одного канала в другой.

Каждая среда Решение Azure VMware — это собственный регион ExpressRoute (собственное виртуальное устройство MSEE), что позволяет подключить Global Reach к «локальному» месту пиринга. Он позволяет подключать несколько экземпляров Решение Azure VMware в одном регионе к одному и тому же месту равноправного объединения.

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

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

Доступ и безопасность

Решение Azure VMware частные облака используют управление доступом на основе ролей vSphere для повышения безопасности. Вы можете интегрировать возможности LDAP для единого входа vSphere с Microsoft Entra ID. Дополнительные сведения см. на странице архитектуры доступа и удостоверений.

Шифрование неактивных данных vSAN включено по умолчанию и используется для обеспечения безопасности хранилища vSAN. Дополнительные сведения см. в разделе "Архитектура хранилища".

Местонахождение данных и клиентские данные

Решение Azure VMware не хранит данные клиента.

Версии программного обеспечения VMware

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

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

Текущая версия программного обеспечения применяется к новым кластерам, добавленным в существующее частное облако, если версия vCenter Server поддерживает ее.

Обслуживание жизненного цикла узла и программного обеспечения

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

Мониторинг частного облака

После развертывания Решение Azure VMware в подписке автоматически создаются журналы Azure Monitor.

В частном облаке вы можете выполнять следующие действия:

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

Шаблоны мониторинга в Решение Azure VMware аналогичны шаблонам мониторинга виртуальных машин Azure в рамках платформы IaaS. Дополнительные сведения и инструкции см. в статье Мониторинг ВМ Azure с помощью Azure Monitor.

Взаимодействие с клиентами

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

Матрица ответственности Решение Azure VMware — Microsoft и клиент

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

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

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

Дальнейшие шаги

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