Поделиться через


Вычислительные ресурсы Azure Stack Hub

Размеры виртуальных машин, поддерживаемых в Azure Stack Hub, являются подмножеством поддерживаемых в Azure. Azure накладывает ограничения ресурсов на множество векторов, чтобы избежать чрезмерного использования ресурсов (локального сервера и уровня обслуживания). Без введения некоторых ограничений на потребление арендаторов, их опыт страдает, когда другие арендаторы чрезмерно расходуют ресурсы. Для исходящего трафика сети с виртуальной машины существуют ограничения пропускной способности в Azure Stack Hub, соответствующие ограничениям Azure. Для ресурсов хранилища в Azure Stack Hub ограничения операций ввода-вывода в секунду помогают избежать избыточного потребления ресурсов клиентами при доступе к хранилищу.

Важный

Планировщик емкости Azure Stack Hub не учитывает и не гарантирует производительность IOPS. На портале администрирования отображается предупреждение, когда общее потребление памяти системы достигает 85%. Это оповещение можно устранить, добавить дополнительныеемкости или удалить виртуальные машины, которые больше не требуются.

Размещение виртуальной машины

Модуль размещения Azure Stack Hub помещает виртуальные машины клиента на доступные узлы.

Azure Stack Hub использует два соображения при размещении виртуальных машин. Хватает ли памяти на узле для этого типа виртуальной машины? И две виртуальные машины являются частью группы доступности или масштабируемых наборов виртуальных машин?

Чтобы обеспечить высокий уровень доступности рабочей нагрузки с несколькими виртуальными машинами в Azure Stack Hub, виртуальные машины помещаются в группу доступности, которая распределяет их по нескольким доменам сбоя. Домен сбоя в группе доступности определяется как один узел в единице масштабирования. Azure Stack Hub поддерживает наличие группы доступности с не более чем тремя доменами сбоя, которые должны быть согласованы с Azure. Виртуальные машины, размещенные в группе доступности, физически изолированы друг от друга, равномерно распределяясь по нескольким доменам отказа (узлам Azure Stack Hub). Если произошел сбой оборудования, виртуальные машины из зоны отказа перезапускаются в других зонах отказа. По возможности они хранятся в отдельных доменах сбоя от других виртуальных машин в той же группе доступности. Когда хост снова подключается к сети, виртуальные машины перераспределяются для поддержания высокой доступности.

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

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

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

Рекомендации по общему количеству виртуальных машин

Существует ограничение на общее количество виртуальных машин, которые можно создать. Максимальное количество виртуальных машин в Azure Stack Hub составляет 700 и 60 на узел единицы масштабирования. Например, ограничение виртуальной машины Azure Stack Hub на восьми серверах равно 480 (8 * 60). Для решения Azure Stack Hub для 12–16 серверов ограничение равно 700. Это ограничение создано с учетом всех рекомендаций по вычислительной емкости, таких как резерв устойчивости и соотношение виртуальных к физическим ЦП, которое оператор хотел бы поддерживать на платформе.

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

Заметка

Часть максимальной виртуальной машины 700 зарезервирована для виртуальных машин инфраструктуры Azure Stack Hub. Дополнительные сведения см. в планировщике емкостей для Azure Stack Hub.

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

В выпусках до и включая 2002 год, использовались 2–5 виртуальных машин на пакет с интервалом в 5 минут между пакетами, что обеспечивало надежные развертывания виртуальных машин для достижения масштаба в 700 виртуальных машин. Начиная с версии 2005 Azure Stack Hub, мы можем надежно подготавливать виртуальные машины размером партии 40, с интервалом в 5 минут между пакетными развертываниями. Операции запуска, остановки и освобождения, а также обновления должны выполняться с размером пакета 30, при этом между каждым пакетом оставляется интервал 5 минут.

Рекомендации по использованию виртуальных машин GPU

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

Память Azure Stack Hub

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

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

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

емкость физической памяти в масштабируемом блоке Azure Stack Hub

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

  • использование или резервирование ОС на хосте: память, используемая операционной системой (ОС) на хосте, таблицами страниц виртуальной памяти, процессами, работающими в ОС хоста, и кэшем памяти Spaces Direct. Так как это значение зависит от памяти, используемой разными Hyper-V процессами, выполняемыми на узле, он может колебаться.
  • службы инфраструктуры : виртуальные машины инфраструктуры, составляющие Azure Stack Hub. Как упоминалось ранее, эти виртуальные машины входят в максимальное количество семисот виртуальных машин. Использование памяти компонента служб инфраструктуры может измениться, так как мы работаем над тем, чтобы наши службы инфраструктуры были более масштабируемыми и устойчивыми. Для получения дополнительной информации см. планировщик ресурсов Azure Stack Hub
  • резерв устойчивости: Azure Stack Hub резервирует часть памяти, чтобы обеспечить доступность клиента во время сбоя одного узла, а также во время исправления и обновления, чтобы обеспечить успешную динамическую миграцию виртуальных машин.
  • виртуальные машины клиента: виртуальные машины клиента, созданные пользователями Azure Stack Hub. В дополнение к запуску виртуальных машин, память используется всеми виртуальными машинами, размещёнными в инфраструктуре. Это означает, что виртуальные машины в состоянии "Создание" или "Сбой", или виртуальные машины, выключенные из гостевой операционной системы, продолжают использовать память. Тем не менее виртуальные машины, которые были деактивированы с помощью опции "остановка и высвобождение ресурсов" на портале, в powershell или cli, не будут использовать память из Azure Stack Hub.
  • поставщики ресурсов, создающие дополнительную ценность (RPS): виртуальные машины, развернутые для поставщиков ресурсов с добавленной стоимостью, таких как SQL, MySQL, Служба приложений и т. д.

Лучший способ понять потребление памяти на портале — использовать Планировщик емкости Azure Stack Hub, чтобы увидеть влияние различных рабочих нагрузок. Следующее вычисление совпадает с тем, что используется планировщиком.

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

Доступная память для размещения виртуальных машин = общая память узла — резерв устойчивости — память, используемая виртуальными машинами клиента — накладные расходы на инфраструктуру Azure Stack Hub 1

  • Общая память узла = сумма памяти со всех узлов
  • Резерв устойчивости = H + R * ((N-1) * H + V * (N-2)
  • Память, используемая виртуальными машинами клиента = фактическая память, используемая рабочей нагрузкой клиента, не зависит от конфигурации высокого уровня доступности.
  • Затраты на инфраструктуру Azure Stack Hub = 268 ГБ + (4 ГБ x N)

Где:

  • H = размер памяти одного сервера
  • N = размер единицы масштабирования (количество серверов)
  • R = резервируется операционной системой для накладных расходов ОС, которое составляет .15 в этой формуле2
  • V = крупнейшая виртуальная машина высокой доступности в единице масштабирования

1 затраты на инфраструктуру Azure Stack Hub = 268 ГБ + (4 ГБ x # узлов). Примерно 31 виртуальные машины используются для размещения инфраструктуры Azure Stack Hub и, в общей сложности, используют около 268 ГБ + (4 ГБ x # узлов) памяти и 146 виртуальных ядер. Обоснование этого числа виртуальных машин заключается в обеспечении необходимого разделения служб для удовлетворения требований безопасности, масштабируемости, поддержки и исправления. Эта внутренняя структура служб позволяет в будущем вводить новые службы инфраструктуры по мере их разработки.

2 зарезервированная операционной системой память для накладных расходов = 15% (.15) объема памяти узла. Значение резерва операционной системы — это оценка и зависит от емкости физической памяти сервера и общих затрат на операционную систему.

Значение V, крупнейшая виртуальная машина высокой доступности в единице масштабирования, динамически зависит от размера памяти виртуальной машины клиента. Например, наибольшее значение виртуальной машины высокой доступности составляет не менее 12 ГБ (учет виртуальной машины инфраструктуры) или 112 ГБ или любой другой поддерживаемый размер памяти виртуальной машины в решении Azure Stack Hub. Изменение крупнейшей виртуальной машины высокого уровня доступности в структуре Azure Stack Hub приводит к увеличению резерва устойчивости, а также увеличению памяти самой виртуальной машины. Помните, что виртуальные машины GPU выполняются в режиме без отказоустойчивости.

Пример вычисления

У нас есть маленькое четырехузловое развертывание Azure Stack Hub с 768 ГБ ОЗУ на каждом узле. Мы планируем разместить виртуальную машину для SQL Server с 128 ГБ ОЗУ (Standard_E16_v3). Что такое доступная память для размещения виртуальных машин?

  • Общая память узла = сумма памяти со всех узлов = 4 * 768 ГБ = 3072 ГБ
  • Резерв устойчивости = H + R * ((N-1) * H + V * (N-2) = 768 + 0,15 * ((4 - 1) * 768) + 128 * (4 - 2) = 1370 ГБ
  • Память, используемая виртуальными машинами клиента = фактическая память, используемая рабочей нагрузкой клиента, не зависит от конфигурации высокого уровня доступности = 0 ГБ
  • Затраты на инфраструктуру Azure Stack Hub = 268 ГБ + (4 ГБ x N) = 268 + (4 * 4) = 284 ГБ

Доступная память для размещения виртуальных машин = общая память узла — резерв устойчивости — память, используемая виртуальными машинами клиента — затраты на инфраструктуру Azure Stack Hub

Доступная память для размещения виртуальных машин = 3072 – 1370 – 0 – 284 = 1418 ГБ

Соображения по деалокации

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

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

Текущие развернутые большие виртуальные машины показывают, что выделенная память составляет 112 ГБ, но объем памяти этих виртуальных машин составляет около 2–3 ГБ.

Имя Назначенная память (ГБ) Спрос на память (ГБ) Имя компьютера
ca7ec2ea-40fd-4d41-9d9b-b11e7838d508 112 2.2392578125 LISSA01P-NODE01
10cd7b0f-68f4-40ee-9d98-b9637438ebf4 112 2.2392578125 LISSA01P-NODE01
2e403868-ff81-4abb-b087-d9625ca01d84 112 2.2392578125 LISSA01P-NODE04

Существует три способа освободить память для размещения виртуальных машин с помощью резерва устойчивости формулы = H + R * (N-1) * H+ V * (N-2):

  • Уменьшение размера крупнейшей виртуальной машины
  • Увеличение памяти узла
  • Добавление узла

Уменьшение размера крупнейшей виртуальной машины

Уменьшение размера крупнейшей виртуальной машины до следующей меньшей виртуальной машины с объемом памяти 24 ГБ уменьшает размер резерва устойчивости.

уменьшить размер виртуальной машины

Резерв устойчивости = 384 + 172,8 + 48 = 604,8 ГБ

Общая память Инфраструктура GB ГБ клиента Резерв устойчивости Общий объем зарезервированной памяти Общий объем гигабайт, доступный для размещения
1536 ГБ 258 ГБ 329,25 ГБ 604,8 ГБ 258 + 329.25 + 604.8 = 1168 ГБ ~344 ГБ

Добавление узла

Добавление узла Azure Stack Hub освобождает память, равномерно распределяя её между двумя узлами.

Добавление узла

Резерв устойчивости = 384 + (0,15) ((5)*384) + 112 * (3) = 1008 ГБ

Общая память Инфра GB ГБ арендатора Резерв устойчивости Общий объем зарезервированной памяти Общий объем памяти в ГБ, доступный для размещения
1536 ГБ 258 ГБ 329,25 ГБ 604,8 ГБ 258 + 329.25 + 604.8 = 1168 ГБ ~ 344 ГБ

Увеличение памяти на каждом узле до 512 ГБ

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

Увеличьте размер узла

Резерв устойчивости = 512 + 230,4 + 224 = 966,4 ГБ

Общая память Инфра ГБ арендатор GB Резерв устойчивости Общий объем зарезервированной памяти Общее количество ГБ, доступное для размещения
2048 (4*512) ГБ 258 ГБ 505,75 ГБ 966,4 ГБ 1730,15 ГБ ~ 318 ГБ

Часто задаваемые вопросы

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

A. Лезвие емкости обновляется каждые 15 минут, поэтому имейте это в виду.

Q: как просмотреть доступные и назначенные ядра?

. В PowerShell запустите test-azurestack -include AzsVmPlacement -debug. Это создаст выходные данные, как показано ниже:

    Starting Test-AzureStack
    Launching AzsVmPlacement
     
    Azure Stack Scale Unit VM Placement Summary Results
     
    Cluster Node    VM Count VMs Running Physical Core Total Virtual Co Physical Memory Total Virtual Mem
    ------------    -------- ----------- ------------- ---------------- --------------- -----------------
    LNV2-Node02     20       20          28            66               256             119.5            
    LNV2-Node03     17       16          28            62               256             110              
    LNV2-Node01     11       11          28            47               256             111              
    LNV2-Node04     10       10          28            49               256             101              
    
    PASS : Azure Stack Scale Unit VM Placement Summary

вопрос. Количество развернутых виртуальных машин в Azure Stack Hub не изменилось, но моя емкость колеблется. Почему?

A: Доступная память для размещения виртуальных машин имеет несколько зависимостей, одна из которых — резерв операционной системы хоста. Это значение зависит от памяти, используемой разными Hyper-V процессами, выполняемыми на узле, что не является константным значением.

Q: Каком состоянии должны находиться виртуальные машины арендатора, чтобы использовать память?

A. Помимо запуска виртуальных машин, память также используется любыми виртуальными машинами, которые размещены в инфраструктуре. Это означает, что виртуальные машины, которые находятся в состоянии "Создание" или "Сбой", используют память. Виртуальные машины выключаются изнутри гостевой ОС, а не останавливаются с портала или через PowerShell/CLI и продолжают использовать память.

вопрос: У меня есть четыре узла Azure Stack Hub. У моего клиента есть 3 виртуальных машины, которые используют 56 ГБ ОЗУ (D5_v2) каждый. Одна из виртуальных машин изменена до 112 ГБ ОЗУ (D14_v2), а отчеты о доступной памяти на панели мониторинга привели к пику использования 168 ГБ в разделе емкости. Последующее изменение размера двух остальных виртуальных машин D5_v2 до D14_v2 привело к увеличению объема ОЗУ на 56 ГБ для каждой. Почему это так?

. Доступная память — это функция резерва устойчивости, поддерживаемого Azure Stack Hub. Резерв устойчивости — это функция наибольшего размера виртуальной машины на метке Azure Stack Hub. Сначала крупнейшая виртуальная машина на метке была с 56 ГБ памяти. При изменении размера виртуальной машины самая большая виртуальная машина на платформе стала с объемом 112 ГБ памяти, что не только увеличило память, используемую этой виртуальной машиной клиента, но и увеличило резерв устойчивости. Это изменение привело к увеличению объема памяти виртуальной машины клиента на 56 ГБ (56 ГБ до 112 ГБ) + 112 ГБ резервной памяти. При изменении размеров последующих виртуальных машин, максимальный размер остался на уровне 112 ГБ, и в результате не произошло увеличения резерва устойчивости. Увеличение потребления памяти касалось только увеличения памяти арендуемой виртуальной машины (56 ГБ).

Заметка

Требования к планированию ёмкости для сетевых ресурсов минимальны, поскольку можно настроить только размер общедоступного виртуального IP-адреса. Сведения о добавлении дополнительных общедоступных IP-адресов в Azure Stack Hub см. в статье Добавление общедоступных IP-адресов.

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

Узнайте о хранилище Azure Stack Hub