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

Размеры виртуальных машин, которые поддерживаются в Azure Stack Hub, поддерживаются и в Azure.The virtual machine (VM) sizes supported on Azure Stack Hub are a subset of those supported on Azure. В Azure используется несколько методов ограничения ресурсов. Это предотвращает их чрезмерное использование (на уровне локальных серверов и служб).Azure imposes resource limits along many vectors to avoid overconsumption of resources (server local and service-level). Если не ограничить потребление ресурсов клиентом, его работа может ухудшиться при чрезмерном использовании ресурсов другими клиентами.Without imposing some limits on tenant consumption, the tenant experiences will suffer when other tenants overconsume resources. Для исходящего трафика виртуальной машины в Azure Stack Hub применяются ограничения пропускной способности, соответствующие ограничениям в Azure.For networking egress from the VM, there are bandwidth caps in place on Azure Stack Hub that match Azure limitations. Для ресурсов хранилища в Azure Stack Hub предусмотрены ограничения на число операций ввода-вывода в секунду. Эти ограничения предотвращают чрезмерное использование основных ресурсов клиентами для доступа к хранилищу.For storage resources on Azure Stack Hub, storage IOPS limits avoid basic over consumption of resources by tenants for storage access.

Важно!

Планировщик ресурсов Azure Stack Hub не оценивает и не обеспечивает производительность операций ввода-вывода.The Azure Stack Hub Capacity Planner does not consider or guarantee IOPS performance.

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

Подсистема размещения Azure Stack Hub размещает виртуальные машины клиентов на доступных узлах.The Azure Stack Hub placement engine places tenant VMs across the available hosts.

В Azure Stack Hub учитываются два фактора при размещении виртуальных машин.Azure Stack Hub uses two considerations when placing VMs. Первый — это наличие у узла достаточного объема памяти для такого типа виртуальной машины.One, is there enough memory on the host for that VM type? Второй — принадлежность виртуальных машин к группе доступности или масштабируемым наборам виртуальных машин.And two, are the VMs a part of an availability set or are they virtual machine scale sets?

Чтобы обеспечить высокий уровень доступности рабочей нагрузки с несколькими виртуальными машинами в Azure Stack центре, виртуальные машины (ВМ) помещаются в группу доступности, которая распределяет их между несколькими доменами сбоя.To achieve high availability of a multi-VM production workload in Azure Stack Hub, virtual machines (VMs) are placed in an availability set that spreads them across multiple fault domains. Домен сбоя в группе доступности определяется как отдельный узел в единице масштабирования.A fault domain in an availability set is defined as a single node in the scale unit. Azure Stack Hub поддерживает группы доступности с максимально тремя доменами сбоя, что гарантирует согласованность с Azure.Azure Stack Hub supports having an availability set with a maximum of three fault domains to be consistent with Azure. Виртуальные машины, размещенные в группе доступности, физически изолированы друг от друга и как можно более равномерно распределяются по нескольким доменам сбоя (узлы Azure Stack Hub).VMs placed in an availability set will be physically isolated from each other by spreading them as evenly as possible over multiple fault domains (Azure Stack Hub nodes). В случае сбоя оборудования виртуальные машины домена со сбоем будут перезапущены в других доменах со сбоем.If there's a hardware failure, VMs from the failed fault domain will be restarted in other fault domains. Они будут храниться в доменах сбоя, отдельных от других виртуальных машин, но, по возможности, в той же группе доступности.If possible, they'll be kept in separate fault domains from the other VMs in the same availability set. Когда работоспособность узла восстанавливается, виртуальные машины перераспределяются, что обеспечивает высокий уровень доступности.When the host comes back online, VMs will be rebalanced to maintain high availability.

Масштабируемые наборы виртуальных машин используют группы доступности в серверной части, чтобы каждый экземпляр масштабируемого набора виртуальных машин размещался в домене сбоя.Virtual machine scale sets use availability sets on the back end and make sure each virtual machine scale set instance is placed in a different fault domain. Это означает, что они используют отдельные узлы инфраструктуры Azure Stack Hub.This means they use separate Azure Stack Hub infrastructure nodes. Например, в системе Azure Stack Hub из четырех узлов создание масштабируемого набора виртуальных машин, состоящего из трех экземпляров, может завершиться сбоем из-за того, что емкости четырех узлов будет недостаточно для размещения трех экземпляров масштабируемого набора виртуальных машин на трех отдельных узлах Azure Stack Hub.For example, in a four-node Azure Stack Hub system, there may be a situation where a virtual machine scale set of three instances will fail at creation due to the lack of the four-node capacity to place three virtual machine scale set instances on three separate Azure Stack Hub nodes. Кроме того, узлы Azure Stack Hub можно заполнять с разными уровнями нагрузки, прежде чем будет выполнена попытка размещения.In addition, Azure Stack Hub nodes can be filled up at varying levels before trying placement.

Azure Stack Hub не допускает чрезмерное выделение памяти.Azure Stack Hub doesn't overcommit memory. При этом допускается интенсивное использование определенного числа физических ядер.However, an overcommit of the number of physical cores is allowed.

Так как алгоритмы подготовки не учитывают избыточную подготовку виртуальных ядер относительно физических, это отношение в каждом узле может быть разным.Since placement algorithms don't look at the existing virtual to physical core overprovisioning ratio as a factor, each host could have a different ratio. Корпорация Майкрософт не предоставляет рекомендации по соотношению физических и виртуальных ядер из-за отличающихся рабочих нагрузок и требований к уровню обслуживания.As Microsoft, we don't provide guidance on the physical-to-virtual core ratio because of the variation in workloads and service level requirements.

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

Существует новый подход для точного планирования ресурсов Azure Stack Hub.There's a new consideration for accurately planning Azure Stack Hub capacity. Ограничение на количество создаваемых виртуальных машин было введено в обновлении 1901 и будет действовать во всех последующих обновлениях.With the 1901 update (and every update going forward), there's now a limit on the total number of VMs that can be created. Данное ограничение является временным и предназначено для предотвращения сбоев в решении.This limit is intended to be temporary to avoid solution instability. Источник ошибок стабильности при большом количестве виртуальных машин обрабатывается, но точное время его устранения еще не установлено.The source of the stability issue at higher numbers of VMs is being addressed but a specific timeline for remediation hasn't been determined. Сейчас действует ограничение в 60 виртуальных машин на один сервер, а максимальное общее число виртуальных машин равно 700.There's now a per-server limit of 60 VMs with a total solution limit of 700. Например, для восьми серверов ограничение составит 480 (8 * 60) виртуальных машин Azure Stack Hub.For example, an eight-server Azure Stack Hub VM limit would be 480 (8 * 60). Для количества серверов от 12 до 16 в решении Azure Stack Hub это ограничение составит 700.For a 12 to 16 server Azure Stack Hub solution, the limit would be 700. Ограничение было создано, чтобы учесть все возможные вычислительные мощности, например, резерв для устойчивости и соотношение виртуальных и физических ресурсов ЦП, которое оператор хотел бы сохранить в единице масштабирования.This limit has been created keeping all the compute capacity considerations in mind, such as the resiliency reserve and the CPU virtual-to-physical ratio that an operator would like to maintain on the stamp. Дополнительные сведения см. в разделе о новом выпуске планировщика ресурсов.For more information, see the new release of the capacity planner.

Если предел масштабирования виртуальной машины достигнут, будут возвращены следующие коды ошибок: VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceeded.If the VM scale limit is reached, the following error codes are returned as a result: VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceeded.

Вопросы и сведения о развертывании виртуальных машин в пакетном режимеConsideration for batch deployment of VMs

В выпусках, выпущенных до и включая 2002, 2-5 виртуальных машин на пакет с 5-минутным разрывом между пакетами, предоставляли надежные развертывания виртуальных машин для достижения масштаба 700 виртуальных машин.In releases prior to and including 2002, 2-5 VMs per batch with 5 mins gap in between batches provided reliable VM deployments to reach a scale of 700 VMs. Благодаря версии 2005 центра Azure Stack можно надежно подготавливать виртуальные машины на размерах пакетов 40 с интервалом в 5 минут между пакетными развертываниями.With the 2005 version of Azure Stack Hub, we are able to reliably provision VMs at batch sizes of 40 with 5 mins gap in between batch deployments.

Память для Azure Stack HubAzure Stack Hub memory

Azure Stack Hub поддерживает работу виртуальных машин, которые были успешно подготовлены.Azure Stack Hub is designed to keep VMs running that have been successfully provisioned. Например, если узел отключится из-за сбоя оборудования, Azure Stack Hub попытается перезапустить его виртуальную машину на другом узле.For example, if a host is offline because of a hardware failure, Azure Stack Hub will attempt to restart that VM on another host. Второй пример — установка исправлений и обновлений программного обеспечения Azure Stack Hub.A second example during patching and updating of the Azure Stack Hub software. Если нужно перезагрузить физический узел, будет предпринята попытка переместить виртуальные машины, работающие на этом узле, на другой узел, доступный в решении.If there's a need to reboot a physical host, an attempt is made to move the VMs executing on that host to another available host in the solution.

Такое управление виртуальными машинами или их перемещение возможно только при наличии зарезервированного объема памяти для перезапуска или миграции.This VM management or movement can only be achieved if there's reserved memory capacity to allow for the restart or migration to occur. Часть всей памяти узла резервируется и становится недоступной для размещения виртуальной машины клиента.A portion of the total host memory is reserved and unavailable for tenant VM placement.

Вы можете просмотреть на портале администрирования круговую диаграмму, на которой показана неиспользуемая и используемая в Azure Stack Hub память.You can review a pie chart in the administrator portal that shows the free and used memory in Azure Stack Hub. На схеме ниже показан объем физической памяти в единице масштабирования Azure Stack Hub в системе Azure Stack Hub:The following diagram shows the physical memory capacity on an Azure Stack Hub scale unit in the Azure Stack Hub:

Управление емкостью физической памяти в единице масштабирования Azure Stack Hub

Используемая память состоит из нескольких компонентов.Used memory is made up of several components. Следующие компоненты используют память в соответствующем разделе круговой диаграммы:The following components consume the memory in the use section of the pie chart:

  • Использование или резервирование ОС узла: Память, используемая операционной системой (ОС) на узле, в таблицах страниц виртуальной памяти, процессах, выполняющихся в ОС узла, и кэш памяти Direct.Host OS usage or reserve: The memory used by the operating system (OS) on the host, virtual memory page tables, processes that are running on the host OS, and the Spaces Direct memory cache. Так как это значение зависит от памяти, используемой другими работающими на узле процессами Hyper-V, оно может меняться.Since this value is dependent on the memory used by the different Hyper-V processes running on the host, it can fluctuate.
  • Службы инфраструктуры: Виртуальные машины инфраструктуры, составляющие концентратор Azure Stack.Infrastructure services: The infrastructure VMs that make up Azure Stack Hub. В выпуске Azure Stack Hub 1904 для нее выделяется примерно 31 виртуальная машина. Вместе они потребляют примерно 242 ГБ (4 ГБ x число узлов) памяти.As of the 1904 release version of Azure Stack Hub, this entails ~31 VMs that take up 242 GB + (4 GB x # of nodes) of memory. Объем памяти, используемый компонентом служб инфраструктуры, может измениться, так как мы работаем над улучшением масштабируемости и устойчивости служб инфраструктуры.The memory utilization of the infrastructure services component may change as we work on making our infrastructure services more scalable and resilient.
  • Резерв устойчивости: Концентратор Azure Stack резервирует часть памяти, чтобы обеспечить доступность клиента во время сбоя одного узла, а также во время исправления и обновления, чтобы обеспечить успешную динамическую миграцию виртуальных машин.Resiliency reserve: Azure Stack Hub reserves a portion of the memory to allow for tenant availability during a single host failure as well as during patch and update to allow for successful live migration of VMs.
  • Виртуальные машины клиента: Виртуальные машины клиента, созданные пользователями центра Azure Stack.Tenant VMs: The tenant VMs created by Azure Stack Hub users. Наряду с работающими виртуальными машинами память также потребляют виртуальные машины, которые работают в структуре.In addition to running VMs, memory is consumed by any VMs that have landed on the fabric. Это означает, что виртуальные машины, которые находятся в состоянии "Создание" или "Сбой" либо работа которых завершена из гостевой ОС, также будут потреблять память.This means that VMs in "Creating" or "Failed" state, or VMs shut down from within the guest, will consume memory. При этом виртуальные машины, распределение которых было отменено путем остановки с помощью портала, PowerShell или интерфейса командной строки, не потребляют память Azure Stack Hub.However, VMs that have been deallocated using the stop deallocated option from portal/powershell/cli won't consume memory from Azure Stack Hub.
  • Значение — Добавление поставщиков ресурсов (RPS): Виртуальные машины, развернутые для значения — Add RPs, например SQL, MySQL, служба приложений и т. д.Value-add resource providers (RPs): VMs deployed for the value-add RPs like SQL, MySQL, App Service, and so on.

Лучший способ оценить потребление памяти на портале — воспользоваться планировщиком ресурсов Azure Stack Hub и оценить влияние разных рабочих нагрузок.The best way to understand memory consumption on the portal is to use the Azure Stack Hub Capacity Planner to see the impact of various workloads. Следующие вычисления соответствуют расчетам планировщика.The following calculation is the same one used by the planner.

Это вычисление позволяет рассчитать общий объем доступной памяти для размещения виртуальных машин арендатора.This calculation results in the total available memory that can be used for tenant VM placement. Этот объем памяти предназначен для всей единицы масштабирования Azure Stack Hub.This memory capacity is for the entirety of the Azure Stack Hub scale unit.

Доступный объем памяти для размещения виртуальных машин = общий объем памяти на узле – резерв для устойчивости – объем памяти, используемый работающими виртуальными машинами клиента – служебная память для инфраструктуры Azure Stack Hub 1Available memory for VM placement = total host memory - resiliency reserve - memory used by running tenant VMs - Azure Stack Hub Infrastructure Overhead 1

Резерв устойчивости = H + R * ((N-1) * H) + V * (N-2)Resiliency reserve = H + R * ((N-1) * H) + V * (N-2)

Где:Where:

  • H = размер памяти на одном сервереH = Size of single server memory
  • N = размер единицы масштабирования (число серверов)N = Size of Scale Unit (number of servers)
  • R = резерв для нагрузки ОС, который составляет 0,15 в этой формуле 2R = The operating system reserve for OS overhead, which is .15 in this formula2
  • V = самая большая виртуальная машина в единице масштабированияV = Largest VM in the scale unit

1 Служебная память для инфраструктуры Azure Stack: примерно 242 ГБ (4 ГБ x число узлов).1 Azure Stack Hub Infrastructure overhead = 242 GB + (4 GB x # of nodes). Для размещения инфраструктуры Azure Stack Hub используется приблизительно 31 виртуальная машина. Все они в совокупности потребляют примерно 242 ГБ памяти (4 ГБ х число узлов) и имеют 146 виртуальных ядер.Approximately 31 VMs are used to host Azure Stack Hub's infrastructure and, in total, consume about 242 GB + (4 GB x # of nodes) of memory and 146 virtual cores. Такое количество виртуальных машин обусловлено необходимостью в разделении служб с целью удовлетворить требованиям к безопасности, масштабируемости, обслуживанию и применению исправлений.The rationale for this number of VMs is to satisfy the needed service separation to meet security, scalability, servicing, and patching requirements. Внутренняя структура служб позволяет вводить в будущем новые службы инфраструктуры по мере их разработки.This internal service structure allows for the future introduction of new infrastructure services as they're developed.

2 Резерв для нагрузки ОС составляет 15 % (0,15) памяти узла.2 Operating system reserve for overhead = 15% (.15) of node memory. Значение резерва операционной системы является приблизительным и зависит от объема физической памяти на сервере и общих накладных расходов операционной системы.The operating system reserve value is an estimate and will vary based on the physical memory capacity of the server and general operating system overhead.

Значение V (самая большая виртуальная машина в единице масштабирования) меняется динамически в зависимости от максимального размера памяти виртуальной машины в клиенте.The value V, largest VM in the scale unit, is dynamically based on the largest tenant VM memory size. Например, это значение может быть равно 7 ГБ, 112 ГБ или соответствовать другому размеру памяти виртуальной машины, поддерживаемому решением Azure Stack Hub.For example, the largest VM value could be 7 GB or 112 GB or any other supported VM memory size in the Azure Stack Hub solution. Изменение самой большой виртуальной машины в структуре Azure Stack приведет к увеличению резерва для устойчивости, а также увеличению объема памяти самой виртуальной машины.Changing the largest VM on the Azure Stack Hub fabric will result in an increase in the resiliency reserve and also to the increase in the memory of the VM itself.

Рекомендации по освобождениюConsiderations for deallocation

Если виртуальная машина находится в освобожденном состоянии, ресурсы памяти не используются.When a VM is in the deallocated state, memory resources aren't being used. Это позволяет разместить в системе другие виртуальные машины.This allows others VMs to be placed in the system.

Если виртуальная машина, распределение которой было отменено, снова запускается, то она использует память или выделенные ресурсы как новая виртуальная машина в системе и потребляет доступную память.If the deallocated VM is then started again, the memory usage or allocation is treated like a new VM placed into the system and available memory is consumed. Если доступной памяти нет, виртуальная машина не запустится.If there's no available memory, then the VM won't start.

Текущие развернутые крупные виртуальные машины показывают, что выделенная память составляет 112 ГБ, но потребность в памяти этих виртуальных машин составляет около 2-3 ГБ.Current deployed large VMs show that the allocated memory is 112 GB, but the memory demand of these VMs is about 2-3 GB.

ИмяName Назначенная память (ГБ)Memory Assigned (GB) Потребность в памяти (ГБ)Memory Demand (GB) ИмяКомпьютераComputerName
ca7ec2ea-40fd-4d41-9d9b-b11e7838d508ca7ec2ea-40fd-4d41-9d9b-b11e7838d508 112112 2.23925781252.2392578125 LISSA01P — NODE01LISSA01P-NODE01
10cd7b0f-68f4-40ee-9d98-b9637438ebf410cd7b0f-68f4-40ee-9d98-b9637438ebf4 112112 2.23925781252.2392578125 LISSA01P — NODE01LISSA01P-NODE01
2e403868-ff81-4abb-b087-d9625ca01d842e403868-ff81-4abb-b087-d9625ca01d84 112112 2.23925781252.2392578125 LISSA01P-NODE04LISSA01P-NODE04

Существует три способа освободить память для размещения виртуальных машин с помощью функции устойчивости Reserve = H + R * ((n-1) * H) + V * (n-2):There are three ways to deallocate memory for VM placement using the formula Resiliency reserve = H + R * ((N-1) * H) + V * (N-2):

  • Уменьшение размера самой крупной виртуальной машиныReduce the size of the largest VM
  • Увеличение объема памяти узлаIncrease the memory of a node
  • Добавление узлаAdd a node

Уменьшение размера самой крупной виртуальной машиныReduce the size of the largest VM

Уменьшение размера самой крупной виртуальной машины до следующей наименьшей виртуальной машины в отметке (24 ГБ) уменьшит размер резерва устойчивости.Reducing the size of the largest VM to the next smallest VM in stamp (24 GB) will reduce the size of the resiliency reserve.

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

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

Общий объем памятиTotal memory В ГИГАБАЙТахInfra GB ГБ клиентаTenant GB Резерв устойчивостиResiliency reserve Общий объем зарезервированной памятиTotal memory reserved Общий объем доступных ГБ для размещенияTotal GB available for placement
1536 ГБ1536 GB 258 ГБ258 GB 329,25 ГБ329.25 GB 604,8 ГБ604.8 GB 258 + 329,25 + 604,8 = 1168 ГБ258 + 329.25 + 604.8 = 1168 GB ~ 344 ГБ~344 GB

Добавление узлаAdd a node

Добавление узла концентратора Azure Stack приведет к дераспределению памяти путем равномерного распределения памяти между двумя узлами.Adding an Azure Stack Hub node will deallocate memory by equally distributing the memory between the two nodes.

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

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

Общий объем памятиTotal Memory В ГИГАБАЙТахInfra GB ГБ клиентаTenant GB Резерв устойчивостиResiliency reserve Общий объем зарезервированной памятиTotal memory reserved Общий объем доступных ГБ для размещенияTotal GB available for placement
1536 ГБ1536 GB 258 ГБ258 GB 329,25 ГБ329.25 GB 604,8 ГБ604.8 GB 258 + 329,25 + 604,8 = 1168 ГБ258 + 329.25 + 604.8 = 1168 GB ~ 344 ГБ~ 344 GB

Увеличение объема памяти на каждом узле до 512 ГБIncrease memory on each node to 512 GB

Увеличение объема памяти каждого узла приведет к увеличению общего объема доступной памяти.Increasing the memory of each node will increase the total available memory.

Увеличение размера узла

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

Общий объем памятиTotal Memory В ГИГАБАЙТахInfra GB ГБ клиентаTenant GB Резерв устойчивостиResiliency reserve Общий объем зарезервированной памятиTotal memory reserved Общий объем доступных ГБ для размещенияTotal GB available for placement
2048 (4 * 512) ГБ2048 (4*512) GB 258 ГБ258 GB 505,75 ГБ505.75 GB 966,4 ГБ966.4 GB 1730,15 ГБ1730.15 GB ~ 318 ГБ~ 318 GB

Вопросы и ответыFrequently Asked Questions

Вопрос. мой клиент развернул новую виртуальную машину, сколько времени займет на диаграмме возможностей на портале администратора, чтобы отобразить оставшуюся емкость?Q: My tenant deployed a new VM, how long will it take for the capability chart on the administrator portal to show remaining capacity?

Ответ. колонка емкость обновляется каждые 15 минут, поэтому примите во внимание.A: The capacity blade refreshes every 15 minutes, so take that into consideration.

Вопрос. как можно увидеть доступные ядра и назначенные ядра?Q: How can I see the available cores and assigned cores?

Ответ. в PowerShell выполните команду test-azurestack -include AzsVmPlacement -debug , которая создает следующий результат:A: In PowerShell run test-azurestack -include AzsVmPlacement -debug, which generates an output like this:

    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 не изменилось, но емкость моей емкости изменяется.Q: The number of deployed VMs on my Azure Stack Hub hasn't changed, but my capacity is fluctuating. Почему?Why?

Ответ . объем доступной памяти для размещения виртуальных машин зависит от нескольких зависимостей, один из которых является резервом ОС узла.A: The available memory for VM placement has multiple dependencies, one of which is the host OS reserve. Это значение зависит от памяти, используемой другими работающими на узле процессами Hyper-V, объем которой может меняться.This value is dependent on the memory used by the different Hyper-V processes running on the host, which isn't a constant value.

Вопрос. какое состояние клиентские виртуальные машины должны использовать для использования памяти?Q: What state do tenant VMs have to be in to consume memory?

Ответ . в дополнение к работающим виртуальным машинам память потребляется виртуальными машинами, которые были выработаны в структуре.A: In addition to running VMs, memory is consumed by any VMs that have landed on the fabric. Это означает, что виртуальные машины, которые находятся в состоянии "Создание" или "Сбой", будут потреблять память.This means that VMs that are in a "Creating" or "Failed" state will consume memory. Виртуальные машины, работа которых была завершена из гостевой ОС (а не путем отмены распределения с помощью портала, PowerShell или интерфейса командной строки), будут потреблять память.VMs shut down from within the guest as opposed to stop deallocated from portal/powershell/cli will also consume memory.

Вопрос. у меня есть Azure Stack концентратор с четырьмя узлами.Q: I have a four-host Azure Stack Hub. У моего арендатора три виртуальные машины (D5_v2), которые используют по 56 ГБ ОЗУ.My tenant has 3 VMs that consume 56 GB of RAM (D5_v2) each. Размер одной из виртуальных машин был увеличен до 112 ГБ ОЗУ (D14_v2), а в колонке емкости на панели мониторинга значение доступной памяти уменьшилось на 168 ГБ.One of the VMs is resized to 112 GB RAM (D14_v2), and available memory reporting on dashboard resulted in a spike of 168 GB usage on the capacity blade. Последующее изменение размера двух других виртуальных машин D5_v2 до размера D14_v2 привело к увеличению потребления памяти всего на 56 ГБ ОЗУ для каждой из виртуальных машин.Subsequent resizing of the other two D5_v2 VMs to D14_v2 resulted in only 56 GB of RAM increase each. Чем это обусловлено?Why is this so?

Ответ. доступная память является функцией резерва устойчивости, поддерживаемой центром Azure Stack.A: The available memory is a function of the resiliency reserve maintained by Azure Stack Hub. Резерв для устойчивости в свою очередь определяется по размеру крупнейшей виртуальной машины в метке Azure Stack Hub.The Resiliency reserve is a function of the largest VM size on the Azure Stack Hub stamp. Изначально самая крупная виртуальная машина в метке занимала 56 ГБ.At first, the largest VM on the stamp was 56 GB memory. После изменения размера виртуальной машины до 112 ГБ увеличился не только объем памяти, используемый такой виртуальной машиной клиента, но и объем резерва для устойчивости.When the VM was resized, the largest VM on the stamp became 112 GB memory which not only increased the memory used by that tenant VM but also increased the resiliency reserve. В итоге значение увеличилось на 56 ГБ (разница при изменении размера виртуальной машины клиента с 56 до 112 ГБ) плюс 112 ГБ резерва для устойчивости.This change resulted in an increase of 56 GB (56 GB to 112 GB tenant VM memory increase) + 112 GB resiliency reserve memory increase. При последующем изменении размера виртуальных машин объем памяти, используемой крупнейшей виртуальной машиной, не менялся, поэтому общий резерв для устойчивости также не увеличивался.When subsequent VMs were resized, the largest VM size remained as the 112 GB VM and therefore there was no resultant resiliency reserve increase. Объем потребляемой памяти изменился только с учетом увеличения размера виртуальной машины клиента (56 ГБ).The increase in memory consumption was only the tenant VM memory increase (56 GB).

Примечание

Требования к планированию ресурсов для сети минимальны, так как настраивается только размер общедоступного виртуального IP-адреса.The capacity planning requirements for networking are minimal as only the size of the public VIP is configurable. Ознакомьтесь с дополнительными сведениями о добавлении общедоступных IP-адресов в Azure Stack Hub.For information about how to add more public IP addresses to Azure Stack Hub, see Add public IP addresses.

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

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