Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Решение Azure VMware предоставляет частные облака, содержащие кластеры VMware vSphere, созданные из выделенной физической инфраструктуры Azure. Решение Azure VMware доступно в Azure Commercial и Azure Government. Минимальное начальное развертывание — три узла с возможностью добавления дополнительных узлов до 16 узлов на кластер. Все подготовленные частные облака имеют VMware vCenter Server, VMware vSAN, VMware vSphere и VMware NSX. Поэтому вы можете перенести рабочие нагрузки из локальных сред, развернуть новые виртуальные машины и использовать службы Azure из частных облаков. Сведения об уровне обслуживания см. на странице соглашений об уровне обслуживания Azure .
Решение Azure VMware подтверждено компанией VMware, которая постоянно проверяет и тестирует улучшения и обновления. Корпорация Майкрософт управляет и поддерживает инфраструктуру частного облака и программное обеспечение, что позволяет сосредоточиться на разработке и выполнении рабочих нагрузок в частных облаках для обеспечения ценности бизнеса.
На следующей схеме показана связь между частными облаками и виртуальными сетями в Azure, службами Azure и локальными средами. Сетевой доступ из частных облаков к службам и виртуальным сетям Azure обеспечивает интеграцию конечных точек служб Azure с поддержкой соглашений об уровне обслуживания. ExpressRoute Global Reach подключает локальную среду к частному облаку решения Azure VMware.
Типы частного облака решения Azure VMware
Решение Azure VMware предоставляет два разных поколения частного облака:
Решение Azure VMware поколения 1 предоставляет кластеры VMware vSphere, созданные на основе выделенных узлов без операционной системы, развернутых в средствах центра обработки данных Azure. Каналы ExpressRoute, управляемые корпорацией Майкрософт, обеспечивают подключение между узлами VMware vSphere и собственными ресурсами Azure, развернутыми в виртуальных сетях.
Решение Azure VMware поколения 2 (общедоступная предварительная версия) предоставляет кластеры VMware vSphere, созданные на основе выделенных физических узлов Azure. Azure VMware Solution Generation 2 включает обновленную сетевую архитектуру, в которой узлы VMware vSphere подключаются непосредственно к виртуальным сетям Azure. Это предложение поддерживается только в SKU AV64.
Узлы, кластеры и частные облака
Кластеры решений Azure VMware основаны на гиперконвергентной инфраструктуре. В следующей таблице показаны спецификации ЦП, памяти, диска и сети узла.
| Тип хоста | ЦП (ядра/ГГц) | ОЗУ (ГБ) | Архитектура vSAN | Уровень кэша vSAN (ТБ, необработанный**) | Уровень емкости vSAN (ТБ, необработанный**) | Доступность в регионах |
|---|---|---|---|---|---|---|
| AV36 | Двойной процессор Intel Xeon Gold 6140 (Skylake microarchitecture) с 18 ядрами/ЦП @ 2,3 ГГц, всего 36 физических ядер (72 логических ядер с гиперпотоком) | 576 | Обструктивное апноэ сна (ОАС) | 3.2 (NVMe) | 15.20 (SSD) | Выбранные регионы (*) |
| AV36P | Два процессора Intel Xeon Gold 6240 (микроархитектура Cascade Lake) с 18 ядрами на процессор при частоте 2,6 гигагерца / 3,9 гигагерца в турбо-режиме, всего 36 физических ядер (72 логических ядра с гиперпоточностью) | 768 | Обструктивное апноэ сна (ОАС) | 1.5 (Кэш Intel) | 19.20 (NVMe) | Выбранные регионы (*) |
| AV48 | Два процессора Intel Xeon Gold 6442Y (микроархитектура Sapphire Rapids) с 24 ядрами на процессор, частота 2,6 ГГц / 4,0 ГГц в турбо режиме, всего 48 физических ядер (96 логических ядер с поддержкой гиперпоточности) | 1024 | ЕКА | Не применимо | 25.6 (NVMe) | Выбранные регионы (*) |
| AV52 | Два процессора Intel Xeon Platinum 8270 (микроархитектура Cascade Lake) с 26 ядрами на процессор, частота 2,7 ГГц / 4,0 ГГц Turbo, всего 52 физических ядра (104 логических ядра с гиперпоточностью) | 1536 | Обструктивное апноэ сна (ОАС) | 1.5 (Кэш Intel) | 38.40 (NVMe) | Выбранные регионы (*) |
| AV64 | Двойной процессор Intel Xeon Platinum 8370C (Ice Lake microarchitecture) с 32 ядрами/ЦП @ 2,8 ГГц / 3,5 ГГц Turbo, всего 64 физических ядер (128 логических ядер с гиперпотоком) | 1024 | Обструктивное апноэ сна (ОАС) | 3.84 (NVMe) | 15.36 (NVMe) | Выбранные регионы (**) |
Для кластера решения Azure VMware требуется не менее трех узлов. Узлы одного типа можно использовать только в одном частном облаке Решения Azure VMware. Хосты, используемые для построения или масштабирования кластеров, поступают из изолированного пула хостов. Эти узлы прошли аппаратные тесты, и все данные были безопасно удалены перед добавлением в кластер.
Все предыдущие типы узлов имеют пропускную способность сетевого интерфейса 100 Гбит/с.
*Сведения доступны с помощью калькулятора цен Azure.
**Предварительные требования AV64: частное облако Azure VMware Solution, развернутое с AV36, AV36P или AV52, требуется перед добавлением AV64.
Raw соответствует международному стандарту единиц (SI), сообщаемому производителями дисков. Пример: 1 ТБ Raw = 100000000000000 байт. Пространство, вычисляемое компьютером в двоичном файле (1 ТБ двоичного файла = 1099511627776 байтов) равно 931,3 гигабайтам, преобразованным из необработанного десятичного разряда.
Вы можете развернуть новые или масштабировать существующие частные облака с помощью портал Azure или Azure CLI.
Решение Azure VMware для расширения частного облака с размером узлов AV64
AV64 — это SKU узла решения Azure VMware, который доступен для расширения частного облака решения Azure VMware, созданного с использованием существующего SKU AV36, AV36P или AV52. Если вы хотите развернуть AV64 напрямую, обратитесь к решению Azure VMWare в виртуальной сети Azure. Используйте документацию Майкрософт для проверки доступности номера SKU AV64 в регионе.
Требования для расширения AV64 на AV36, AV36P и AV52
См. следующие предварительные требования для развертывания кластера AV64.
Частное облако решения Azure VMware создается с помощью AV36, AV36P, AV48 или AV52 в поддерживаемом регионе ИЛИ AZ AV64.
Для управления кластерами AV64 вам потребуется один блок адресов /23 или три (смежные или несмежные) /25.
Поддержка сценариев клиента
Клиент с существующим частным облаком решения Azure VMware: если клиент имеет развернутое частное облако решения Azure VMware, он может масштабировать частное облако, добавив отдельный кластер узлов AV64 vCenter в это частное облако. В этом сценарии клиенты должны выполнить следующие действия.
- Получите утверждение квоты AV64 от Корпорации Майкрософт не менее чем на три узла. Добавьте другие сведения о частном облаке Azure VMware Solution, которое вы планируете расширить с помощью AV64.
- Используйте существующий рабочий процесс добавления кластера в решении Azure VMware с узлами AV64 для расширения.
Клиент планирует создать частное облако решения Azure VMware: когда клиент хочет создать частное облако решения Azure VMware, которое может использовать SKU AV64, но только для расширения. В этом случае клиенты соответствуют предусловиям для решения Azure VMware для частного облака, включающего AV36, AV36P или AV52 SKU. Клиенту необходимо приобрести не менее трех узлов AV36, AV36P или AV52 SKU, прежде чем расширяться с помощью AV64. Для этого сценария выполните следующие действия.
- Получите утверждение квоты для AV36, AV36P или AV52, а также AV64 от Корпорации Майкрософт с минимальным количеством трех узлов для каждого.
- Создайте частное облако в Azure VMware Solution с помощью SKU AV36, AV36P или AV52.
- Используйте существующий рабочий процесс добавления кластера в решении Azure VMware с узлами AV64 для расширения.
Решение Azure VMware с растянутыми кластерами в частном облаке: SKU AV64 не поддерживается в растянутых кластерах частного облака решения Azure VMware. Это означает, что расширение на базе AV64 невозможно для частного облака Azure VMware Solution с распределёнными кластерами.
Примечание.
Весь трафик от узла AV64 к клиентской сети будет использовать IP-адрес сетевого интерфейса VMKernel 1.
Проектирование и рекомендации по отказоустойчивому домену в кластере AV64 vSAN.
Традиционные кластеры хостов решения Azure VMware не имеют явной конфигурации vSAN FD. Причина заключается в том, что логика выделения узлов гарантирует, что два узла не находятся в одном и том же домене физического сбоя в регионе Azure. Эта функция, по сути, обеспечивает устойчивость и высокую доступность для хранилища, которые должны быть обеспечены конфигурацией vSAN FD. Дополнительные сведения о FD vSAN см. в документации по VMware.
Кластеры узлов Azure VMware Solution AV64 имеют явную конфигурацию домена отказов vSAN. Контрольная плоскость решения Azure VMware настраивает семь областей отказов vSAN (FDs) для кластеров AV64. Хосты равномерно распределяются по семи FD, когда пользователи масштабируют хосты в кластере с трёх узлов до 16 узлов. Некоторые регионы Azure по-прежнему поддерживают не более пяти FDs в рамках первоначального выпуска 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 Solution обеспечивает равномерное добавление узлов из всех семи FDs. В следующем примере пользователи могут удалить одного из хостов из 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, корпорация Майкрософт позволяет клиентам использовать политику хранилища RAID-5 FTT1 vSAN для кластеров AV64 с шестью или более узлами, чтобы соответствовать соглашению об уровне обслуживания (SLA). Для получения дополнительной информации см. таблицу сопоставления типов хостов с зонами доступности региона Azure.
| Конфигурация RAID | Отказы, которые следует терпеть (FTT) | Минимальное количество необходимых узлов |
|---|---|---|
| Параметр по умолчанию RAID-1 (зеркальное отображение). | 1 | 3 |
| RAID-5 (стирающее кодирование) | 1 | 4 |
| RAID-1 (зеркалирование) | 2 | 5 |
| RAID-6 (стирающее кодирование) | 2 | 6 |
| RAID-1 (зеркалирование) | 3 | 7 |
Хранилище
Решение Azure VMware поддерживает расширение емкости хранилища данных за пределы того, что входит в состав vSAN с помощью служб хранилища Azure, что позволяет расширить емкость хранилища данных без масштабирования кластеров. Дополнительные сведения см. в разделе "Параметры расширения емкости хранилища данных".
Сеть
Решение 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 Solution является собственной областью ExpressRoute (собственным виртуальным устройством MSEE), что позволяет подключать Global Reach к 'локальной' точке сопряжения. Вы можете подключать несколько инстанций Решения Azure VMware в одном регионе к одной и той же точке пиринга.
Примечание.
Для расположений, в которых возможность ExpressRoute Global Reach не включена, например из-за местных нормативных требований, необходимо создать решение маршрутизации с помощью виртуальных машин Azure IaaS. Примеры см. в статье Azure Cloud Adoption Framework — топология сети и подключение для решения Azure VMware.
Виртуальные машины, развернутые в частном облаке, имеют доступ к интернету посредством функции публичного IP-адреса Azure Virtual WAN. Для новых частных облаков доступ к Интернету отключен по умолчанию.
Дополнительные сведения см. в разделе "Архитектура сети".
Доступ и безопасность
Для повышения безопасности частные облака решения Azure VMware используют управление доступом на основе ролей vSphere. Вы можете интегрировать возможности LDAP SSO в vSphere с идентификатором Microsoft Entra. Дополнительные сведения см. на странице архитектуры доступа и удостоверений.
Шифрование неактивных данных vSAN включено по умолчанию и используется для обеспечения безопасности хранилища vSAN. Дополнительные сведения см. в разделе "Архитектура хранилища".
Местонахождение данных и клиентские данные
Решение Azure VMware не хранит данные клиента.
Версии программного обеспечения VMware
В следующей таблице перечислены версии программного обеспечения, используемые в новых развертываниях частных облаков решения Azure VMware.
| Программное обеспечение. | Версия | номер сборки |
|---|---|---|
| VMware vCenter Server | 8.0 U2d | 23929136 |
| VMware ESXi | 8.0 U2d | 24585300 |
| VMware vSAN | 8.0 U2 | 24585300 |
| Свидетель VMware vSAN | 8.0 U2 | 24585300 |
| Формат VMware vSAN на диске | 19 | Не применимо |
| Архитектура хранилища VMware vSAN | OSA | Не применимо |
| VMware NSX | 4.1.1 | 22224317 |
| VMware HCX | 4.10.3 | 24447633 |
| Диспетчер восстановления сайта VMware | 8.8.0.3 | 23263429 |
| Репликация VMware vSphere | 8.8.0.3 | 23166649 |
Если указанный номер сборки не соответствует номеру сборки, указанному в заметках о выпуске, это связано с применением пользовательского исправления для поставщиков облачных служб.
Текущая версия программного обеспечения применяется к новым кластерам, добавленным в существующее частное облако, если версия vCenter Server поддерживает ее.
Обслуживание жизненного цикла узла и программного обеспечения
Регулярное обновление программного обеспечения для частного облака решения Azure VMware и ПО VMware гарантирует, что в частных облаках всегда действуют самые новые наборы функций, технологий безопасности и стабильности. Дополнительные сведения см. в разделе "Обслуживание узла" и управление жизненным циклом.
Мониторинг частного облака
После развертывания решения Azure VMware в вашей подписке журналы Azure Monitor создаются автоматически.
В частном облаке вы можете выполнять следующие действия:
- Собирать логи на каждой из ваших виртуальных машин.
- Скачайте и установите агент MMA на виртуальных машинах Linux и Windows.
- Включите расширение диагностики Azure.
- Создание и запуск новых запросов.
- выполнять те же запросы, которые обычно выполняются на виртуальных машинах.
Шаблоны мониторинга в Решении Azure VMware аналогичны шаблонам виртуальных машин Azure на платформе IaaS. Дополнительные сведения и инструкции см. в статье "Мониторинг виртуальных машин Azure" с помощью Azure Monitor.
Взаимодействие с клиентами
Вы можете найти проблемы со службами, плановое обслуживание, советы по состоянию системы и уведомления по безопасности, публикуемые через Service Health в портале Azure. Настроив оповещения для журнала действий, вы сможете своевременно реагировать на эти уведомления. Дополнительные сведения см. в статье "Создание оповещений о работоспособности службы" с помощью портала Azure.
матрица ответственности Решение Azure VMware — Корпорация Майкрософт и клиент
Решение Azure VMware реализует модель общей ответственности, которая определяет отдельные роли и обязанности двух сторон, участвующих в предложении: клиент и Корпорация Майкрософт. Ответственность за общие роли детально показана в следующих двух таблицах.
Таблица матрицы общей ответственности описывает основные задачи, которые клиенты и Корпорация Майкрософт обрабатывают при развертывании и управлении рабочими нагрузками частного облака и клиентского приложения.
В следующей таблице представлен подробный список ролей и обязанностей между клиентом и корпорацией Майкрософт, который охватывает наиболее частые задачи и определения. Для получения дополнительных вопросов обратитесь в корпорацию Майкрософт.
| Роль | Задача и сведения |
|---|---|
| Корпорация Майкрософт — Решение Azure VMware | Физическая инфраструктура
(необязательно) VMware HCX развертывается с полностью настроенным вычислительным профилем на облачной стороне в качестве надстройки (необязательно) VMware SRM развертывает, обновляет и масштабирует вверх/вниз Поддержка — платформы частного облака и VMware HCX |
| Клиент | Запрос сметы на хост Azure VMware у Microsoft Планирование и создание запроса частных облаков на портал Azure с помощью:
Добавление или удаление запросов узлов к кластеру с портала Развертывание и управление жизненным циклом решений партнеров (сторонних производителей) |
| Партнерская экосистема | Поддержка продукта или решения. Для справки, вот некоторые из поддерживаемых решений или продуктов партнеров для решения Azure VMware.
|
Следующие шаги
Следующим шагом является изучение основных концепций архитектуры частного облака.