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

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

Важно!

Планировщик ресурсов Azure Stack Hub не оценивает и не обеспечивает производительность операций ввода-вывода. На портале администрирования отображается предупреждение, когда общий объем системной памяти достигает 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 на узел единицы масштабирования. Например, для восьми серверов ограничение составит 480 (8 * 60) виртуальных машин Azure Stack Hub. Для количества серверов от 12 до 16 в решении Azure Stack Hub это ограничение составит 700. Ограничение было создано, чтобы учесть все возможные вычислительные мощности, например, резерв для устойчивости и соотношение виртуальных и физических ресурсов ЦП, которое оператор хотел бы сохранить в единице масштабирования.

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

Примечание

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

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

В выпусках до и в том числе 2002 г. 2–5 виртуальных машин на пакет с интервалом в 5 минут между пакетами обеспечивали надежное развертывание виртуальных машин для достижения масштаба 700 виртуальных машин. Начиная с версии Azure Stack Hub 2005 мы можем надежно подготавливать виртуальные машины с размером пакета 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:

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

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

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

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

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

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

Где:

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

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

² Резерв для нагрузки ОС составляет 15 % (0,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 ГБ

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

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

Добавление узла Azure Stack Hub приведет к освобождению памяти путем равномерного распределения памяти между двумя узлами.

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

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

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

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

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

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

Вопросы и ответы

Вопрос. Мой клиент развернул новую виртуальную машину. Сколько времени потребуется для отображения оставшейся емкости в диаграмме возможностей на портале администрирования?

О. Колонка емкости обновляется каждые 15 минут, поэтому учитывайте это.

Вопрос. Как просмотреть доступные и назначенные ядра?

О. В 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 не изменилось, но моя емкость меняется. Почему?

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

Вопрос. В каком состоянии должны находиться виртуальные машины клиента для использования памяти?

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

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

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

Примечание

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

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

Изучите информацию о хранилище Azure Stack Hub.