Capacidade de computação do Azure Stack Hub

Os tamanhos de VM (máquina virtual) com suporte no Azure Stack Hub são um subconjunto daqueles com suporte no Azure. O Azure impõe limites de recursos junto de muitos vetores para evitar o consumo excessivo de recursos (servidor local e nível de serviço). Sem impor alguns limites no consumo do locatário, as experiências de locatário sofrerão quando outros locatários consumirem excessivamente os recursos. Para saída de rede da VM, há limites de largura de banda em vigor no Azure Stack Hub que correspondem às limitações do Azure. Para recursos de armazenamento no Azure Stack Hub, os limites de IOPS de armazenamento evitam o consumo excessivo básico de recursos por locatários para acesso de armazenamento.

Importante

O Planejador de Capacidade do Azure Stack Hub não considera nem garante o desempenho de IOPS. O portal do administrador mostra um alerta de aviso quando o consumo total de memória do sistema atingiu 85%. Esse alerta pode ser corrigido adicionando capacidade adicional ou removendo máquinas virtuais que não são mais necessárias.

Posicionamento de VM

O mecanismo de posicionamento do Azure Stack Hub coloca VMs de locatário entre os hosts disponíveis.

O Azure Stack Hub usa duas considerações ao colocar VMs. Primeiro, há memória suficiente no host para esse tipo de VM? E duas, as VMs fazem parte de um conjunto de disponibilidade ou são conjuntos de dimensionamento de máquinas virtuais?

Para obter alta disponibilidade de uma carga de trabalho de produção de várias VMs no Azure Stack Hub, as VMs (máquinas virtuais) são colocadas em um conjunto de disponibilidade que as espalha por vários domínios de falha. Um domínio de falha em um conjunto de disponibilidade é definido como um único nó na unidade de escala. O Azure Stack Hub dá suporte a um conjunto de disponibilidade com no máximo três domínios de falha para ser consistente com o Azure. As VMs colocadas em um conjunto de disponibilidade serão fisicamente isoladas umas das outras, distribuindo-as da forma mais uniforme possível em vários domínios de falha (nós do Azure Stack Hub). Se houver uma falha de hardware, as VMs do domínio de falha serão reiniciadas em outros domínios de falha. Se possível, eles serão mantidos em domínios de falha separados das outras VMs no mesmo conjunto de disponibilidade. Quando o host voltar a ficar online, as VMs serão rebalanceados para manter a alta disponibilidade.

Os conjuntos de dimensionamento de máquinas virtuais usam conjuntos de disponibilidade no back-end e garantem que cada instância do conjunto de dimensionamento de máquinas virtuais seja colocada em um domínio de falha diferente. Isso significa que eles usam nós separados da infraestrutura do Azure Stack Hub. Por exemplo, em um sistema de quatro nós do Azure Stack Hub, pode haver uma situação em que um conjunto de dimensionamento de máquinas virtuais de três instâncias falhará na criação devido à falta de capacidade dos quatro nós em colocar três instâncias do conjunto de dimensionamento de máquinas virtuais em três nós separados do Azure Stack Hub. Além disso, os nós do Azure Stack Hub podem ser preenchidos em níveis variáveis antes de tentar o posicionamento.

O Azure Stack Hub não compromete demais a memória. No entanto, é permitido um excesso de confirmação do número de núcleos físicos.

Como os algoritmos de posicionamento não analisam a taxa de superprovisionamento entre núcleos físicos e virtuais existentes como um fator, cada host pode ter uma proporção diferente. Como Microsoft, não fornecemos diretrizes sobre a taxa de núcleo físico para virtual devido à variação nas cargas de trabalho e nos requisitos de nível de serviço.

Consideração para o número total de VMs

Há um limite no número total de VMs que podem ser criadas. O número máximo de VMs no Azure Stack Hub é 700 e 60 por nó de unidade de escala. Por exemplo, um limite de VM do Azure Stack Hub de oito servidores seria 480 (8 * 60). Para uma solução de 12 a 16 servidores do Azure Stack Hub, o limite seria de 700. Esse limite foi criado levando em consideração todas a capacidade de computação, como a reserva de resiliência e a taxa de virtual para físico da CPU que um operador gostaria de manter na unidade de escala.

Se o limite de escala da VM for atingido, os seguintes códigos de erro serão retornados como resultado: VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceeded.

Observação

Uma parte do máximo de 700 VMs é reservada para VMs de infraestrutura do Azure Stack Hub. Para obter mais informações, consulte o planejador de capacidade do Azure Stack Hub.

Consideração para implantação em lote de VMs

Em versões anteriores e incluindo 2002, 2 a 5 VMs por lote com intervalo de 5 minutos entre lotes forneceu implantações de VM confiáveis para alcançar uma escala de 700 VMs. Com a versão 2005 do Azure Stack Hub em diante, podemos provisionar VMs de forma confiável em tamanhos de lote de 40 com intervalo de 5 minutos entre implantações em lote. As operações Iniciar, Parar desalocar e atualizar devem ser feitas em um tamanho de lote de 30, deixando 5 minutos entre cada lote.

Consideração para VMs de GPU

O Azure Stack Hub reserva memória para a infraestrutura e as VMs de locatário para failover. Ao contrário de outras VMs, as VMs de GPU são executadas em um modo não HA (alta disponibilidade) e, portanto, não fazem failover. Como resultado, a memória reservada para um carimbo somente de VM de GPU é o que é exigido pela infraestrutura para failover, em vez de considerar a memória da VM do locatário de HA também.

Memória do Azure Stack Hub

O Azure Stack Hub foi projetado para manter as VMs em execução que foram provisionadas com êxito. Por exemplo, se um host estiver offline devido a uma falha de hardware, o Azure Stack Hub tentará reiniciar essa VM em outro host. Um segundo exemplo ocorre durante a adoção e atualização do software do Azure Stack Hub. Se houver a necessidade de reinicializar um host físico, será feita uma tentativa de mover as VMs em execução nesse host para outro host disponível na solução.

Esse gerenciamento ou movimentação de VM só poderá ser obtido se houver capacidade de memória reservada para permitir que a reinicialização ou migração ocorra. Uma parte da memória total do host está reservada e indisponível para o posicionamento da VM do locatário.

Você pode revisar um gráfico de pizza no portal do administrador que mostra a memória livre e usada no Azure Stack Hub. O diagrama a seguir mostra a capacidade de memória física em uma unidade de escala no Azure Stack Hub:

A memória usada é composta de vários componentes. Os seguintes componentes consomem a memória na seção de uso do gráfico de pizza:

• Uso ou reserva do sistema operacional do host: A memória usada pelo sistema operacional (SO) no host, tabelas de páginas de memória virtual, processos em execução no sistema operacional host e o cache de memória do Spaces Direct. Como esse valor depende da memória usada pelos diferentes processos do Hyper-V em execução no host, ele pode flutuar.
• Serviços de infraestrutura: As VMs de infraestrutura que compõem o Azure Stack Hub. Conforme discutido anteriormente, essas VMs fazem parte do máximo de 700 VMs. A utilização de memória do componente de serviços de infraestrutura pode mudar conforme trabalhamos para tornar nossos serviços de infraestrutura mais escalonáveis e resilientes. Para obter mais informações, consulte o planejador de capacidade do Azure Stack Hub
• Reserva de resiliência: O Azure Stack Hub reserva uma parte da memória para permitir a disponibilidade do locatário durante uma única falha de host, bem como durante o patch e a atualização para permitir a migração dinâmica bem-sucedida de VMs.
• VMs de locatário: As VMs de locatário criadas pelos usuários do Azure Stack Hub. Além de executar VMs, a memória é consumida por todas as VMs que chegaram à malha. Isso significa que as VMs no estado "Criando" ou "Com falha", ou VMs desligadas de dentro do convidado, consumirão memória. No entanto, as VMs que foram desalocadas usando a opção parar desalocada do portal/powershell/cli não consumirão memória do Azure Stack Hub.
• RPs (provedores de recursos de adição de valor): VMs implantadas para os RPs com valor agregado, como SQL, MySQL, Serviço de Aplicativo e assim por diante.

A melhor maneira de entender o consumo de memória no portal é usar o Planejador de Capacidade do Azure Stack Hub para ver o impacto de várias cargas de trabalho. O cálculo a seguir é o mesmo usado pelo planejador.

Esse cálculo resulta na memória total disponível que pode ser usada para o posicionamento da VM do locatário. Essa capacidade de memória é para toda a unidade de escala do Azure Stack Hub.

Memória disponível para posicionamento da VM = memória total do host – reserva de resiliência – memória usada pela execução de VMs de locatário – Sobrecarga ¹ da infraestrutura do Azure Stack Hub

• Memória total do host = Soma da memória de todos os nós
• Reserva de resiliência = H + R * ((N-1) * H) + V * (N-2)
• Memória usada por VMs de locatário = Memória real consumida pela carga de trabalho do locatário, não depende da configuração de HA
• Sobrecarga de infraestrutura do Azure Stack Hub = 268 GB + (4 GB x N)

Em que:

• H = Tamanho da memória de servidor único
• N = tamanho da unidade de escala (número de servidores)
• R = a reserva do sistema operacional para sobrecarga do SO, que é .15 nesta fórmula²
• V = Maior VM de HA na unidade de escala

¹ Sobrecarga de infraestrutura do Azure Stack Hub = 268 GB + (4 GB x # de nós). Aproximadamente 31 VMs são usadas para hospedar a infraestrutura do Azure Stack Hub e, no total, consomem cerca de 268 GB + (4 GB x # de nós) de memória e 146 núcleos virtuais. A lógica para esse número de VMs é atender à separação de serviço necessária para atender aos requisitos de segurança, escalabilidade, manutenção e aplicação de patch. Essa estrutura de serviço interna permite a introdução futura dos novos serviços de infraestrutura à medida que eles são desenvolvidos.

² a reserva do sistema operacional para sobrecarga = 15% (.15) da memória do nó. O valor de reserva do sistema operacional é uma estimativa e deve variar com base na capacidade da memória física do servidor e na sobrecarga geral do sistema operacional.

O valor V, maior VM de HA na unidade de escala, é dinamicamente baseado no maior tamanho de memória da VM do locatário. Por exemplo, o maior valor de VM de HA é um mínimo de 12 GB (contabilizando a VM de infraestrutura) ou 112 GB ou qualquer outro tamanho de memória de VM com suporte na solução do Azure Stack Hub. Alterar a maior VM de HA na malha do Azure Stack Hub resultará em um aumento na reserva de resiliência e também no aumento da memória da própria VM. Lembre-se de que as VMs de GPU são executadas no modo não HA.

Exemplo de cálculo

Temos uma pequena implantação do Azure Stack Hub de quatro nós com 768 GB de RAM em cada nó. Planejamos colocar uma máquina virtual para o SQL Server com 128 GB de RAM (Standard_E16_v3). Qual será a memória disponível para o posicionamento da VM?

• Memória total do host = Soma da memória de todos os nós = 4 * 768 GB = 3072 GB
• Reserva de resiliência = H + R * ((N-1) * H) + V * (N-2) = 768 + 0,15 * ((4 - 1) * 768) + 128 * (4 - 2) = 1370 GB
• Memória usada por VMs de locatário = Memória real consumida pela carga de trabalho do locatário, não depende da configuração de HA = 0 GB
• Sobrecarga de infraestrutura do Azure Stack Hub = 268 GB + (4 GB x N) = 268 + (4 * 4) = 284 GB

Memória disponível para posicionamento de VM = memória total do host – reserva de resiliência – memória usada pela execução de VMs de locatário – Sobrecarga de infraestrutura do Azure Stack Hub

Memória disponível para posicionamento de VM = 3072 - 1370 - 0 - 284 = 1418 GB

Considerações sobre desalocação

Quando uma VM está no estado desalocado , os recursos de memória não estão sendo usados. Isso permite que outras VMs sejam colocadas no sistema.

Se a VM desalocada for iniciada novamente, o uso ou alocação de memória será tratado como uma nova VM colocada no sistema e a memória disponível será consumida. Se não houver memória disponível, a VM não será iniciada.

As VMs grandes implantadas atualmente mostram que a memória alocada é de 112 GB, mas a demanda de memória dessas VMs é de cerca de 2 a 3 GB.

Nome	Memória Atribuída (GB)	Demanda de Memória (GB)	ComputerName
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á três maneiras de desalocar a memória para o posicionamento da VM usando a fórmula Reserva de resiliência = H + R * ((N-1) * H) + V * (N-2):

• Reduzir o tamanho da maior VM
• Aumentar a memória de um nó
• Adicionar um nó

Reduzir o tamanho da maior VM

Reduzir o tamanho da maior VM para a próxima menor VM no selo (24 GB) reduzirá o tamanho da reserva de resiliência.

Reserva de resiliência = 384 + 172,8 + 48 = 604,8 GB

Memória total	Infra GB	Locatário GB	Reserva de resiliência	Memória reservada total	Total de GB disponíveis para posicionamento
1536 GB	258 GB	329,25 GB	604,8 GB	258 + 329,25 + 604,8 = 1168 GB	~344 GB

Adicionar um nó

Adicionar um nó do Azure Stack Hub desalocará a memória distribuindo igualmente a memória entre os dois nós.

Reserva de resiliência = 384 + (0,15) ((5)*384) + 112 * (3) = 1008 GB

Memória Total	Infra GB	Locatário GB	Reserva de resiliência	Memória reservada total	Total de GB disponíveis para posicionamento
1536 GB	258 GB	329,25 GB	604,8 GB	258 + 329,25 + 604,8 = 1168 GB	~ 344 GB

Aumentar a memória em cada nó para 512 GB

Aumentar a memória de cada nó aumentará a memória total disponível.

Reserva de resiliência = 512 + 230,4 + 224 = 966,4 GB

Memória Total	Infra GB	Locatário GB	Reserva de resiliência	Memória reservada total	Total de GB disponíveis para posicionamento
2048 (4*512) GB	258 GB	505,75 GB	966,4 GB	1730,15 GB	~ 318 GB

Perguntas frequentes

P: Meu locatário implantou uma nova VM, quanto tempo levará para o gráfico de funcionalidades no portal do administrador mostrar a capacidade restante?

R: A folha de capacidade é atualizada a cada 15 minutos, portanto, leve isso em consideração.

P: Como posso ver os núcleos disponíveis e os núcleos atribuídos?

R: No PowerShell , execute test-azurestack -include AzsVmPlacement -debug, que gera uma saída como esta:

    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

P: O número de VMs implantadas no meu Azure Stack Hub não foi alterado, mas minha capacidade está flutuando. Por quê?

R: A memória disponível para o posicionamento da VM tem várias dependências, uma delas é a reserva do sistema operacional host. Esse valor depende da memória usada pelos diferentes processos do Hyper-V em execução no host, o que não é um valor constante.

P: Em que estado as VMs de locatário precisam estar para consumir memória?

R: Além de executar VMs, a memória é consumida por todas as VMs que caíram na malha. Isso significa que as VMs que estão em um estado "Criando" ou "Falha" consumirão memória. As VMs desligadas de dentro do convidado em vez de parar desalocadas do portal/powershell/cli também consumirão memória.

P: Eu tenho um Azure Stack Hub de quatro host. Meu locatário tem três VMs que consomem 56 GB de RAM (D5_v2) cada uma. Uma das VMs é redimensionada para 112 GB de RAM (D14_v2) e os relatórios de memória disponíveis sobre dashboard resultaram em um pico de 168 GB de uso na folha de capacidade. O redimensionamento subsequente das outras duas VMs D5_v2 para D14_v2 resultou em apenas 56 GB de aumento de RAM cada uma. Por que isso é assim?

R: A memória disponível é uma função da reserva de resiliência mantida pelo Azure Stack Hub. A reserva de resiliência é uma função do maior tamanho de VM no carimbo do Azure Stack Hub. No início, a maior VM no selo era de 56 GB de memória. Quando a VM foi redimensionada, a maior VM no carimbo tornou-se 112 GB de memória, o que não só aumentou a memória usada por essa VM de locatário, mas também aumentou a reserva de resiliência. Essa alteração resultou em um aumento de 56 GB (aumento de memória de VM de locatário de 56 GB a 112 GB) + aumento de memória de reserva de resiliência de 112 GB. Quando as VMs subsequentes foram redimensionadas, o maior tamanho de VM permaneceu como a VM de 112 GB e, portanto, não houve aumento de reserva de resiliência resultante. O aumento no consumo de memória foi apenas o aumento de memória da VM do locatário (56 GB).

Observação

Os requisitos de planejamento de capacidade para rede são mínimos, pois apenas o tamanho do VIP público é configurável. Para obter informações sobre como adicionar mais endereços IP públicos ao Azure Stack Hub, consulte Adicionar endereços IP públicos.

Próximas etapas

Saiba mais sobre o armazenamento do Azure Stack Hub