Capacidade de computação do Azure Stack Hub

Os tamanhos da 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 ao consumo de locatário, as experiências do locatário sofrem quando outros locatários superconsumem recursos. Para a saída de rede da VM, há limites de largura de banda implementados 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.

Posicionamento da VM

O mecanismo de posicionamento do Azure Stack Hub posiciona as VMs do locatário nos 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 são fisicamente isoladas umas das outras, espalhando-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 são mantidos em domínios de falha separados das outras VMs no mesmo conjunto de disponibilidade. Quando o host volta a ficar online, as VMs são reequilibradas 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 do Azure Stack Hub de quatro nós, pode haver uma situação em que um conjunto de dimensionamento de máquinas virtuais de três instâncias falha na criação devido à falta da capacidade de quatro nós de 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 virtuais e físicos 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-virtual devido à variação de cargas de trabalho e requisitos de nível de serviço.

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

Há um limite no número total de VMs que podem ser criadas. O Azure Stack Hub suporta até 700 VMs no total, com um limite de 60 VMs 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 considerando todas as considerações de capacidade de computação, como a reserva de resiliência e a proporção de CPU virtual para física que um operador gostaria de manter no carimbo.

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

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 forneceram implantações confiáveis de VM para atingir uma escala de 700 VMs. Com a versão 2005 do Azure Stack Hub em diante, podemos provisionar de forma confiável VMs em tamanhos de lote de 40 com intervalo de 5 minutos entre implantações em lote. As operações de iniciar, parar e desalocar, e atualizar devem ser feitas com um tamanho de lote de 30, deixando um intervalo de 5 minutos entre cada lote.

Considerações sobre Máquinas Virtuais de GPU

O Azure Stack Hub reserva memória para que as VMs de infraestrutura e de clientes possam fazer 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 é necessário para que a infraestrutura faça failover, em vez de contabilizar também a memória da VM do locatário de HA.

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 do host, as tabelas de página de memória virtual, processos em execução no sistema operacional do host e o cache de memória do Spaces Direct. Como esse valor depende da memória usada pelos diferentes processos de 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 quaisquer VMs que tenham chegado na malha. Isso significa que VMs no estado "Criando" ou "Com falha", ou VMs desligadas de dentro do convidado, consomem memória. No entanto, as VMs que foram desalocadas usando a opção parar desalocar do portal/powershell/cli não consumirão a memória do Azure Stack Hub.
• RPs (provedores de recursos de adição de valor): VMs implantadas para os RPs de 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 alocação de VM = memória total do host – reserva de resiliência – memória usada por VMs de locatários em execução – custos indiretos 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)

Onde:

• H = Tamanho da memória de servidor único
• N = Tamanho da Unidade de Escala (número de servidores)
• R = A reserva para a sobrecarga do sistema operacional, que é 0,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.

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

O valor V, maior VM HA na unidade de escala, é baseado dinamicamente 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 resulta 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 implantação pequena de Azure Stack Hub com quatro nós, cada um deles com 768 GB de RAM. Planejamos colocar uma máquina virtual para SQL Server com 128 GB de RAM (Standard_E16_v3). Qual é a memória disponível para 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.

Há três maneiras de desalocar a memória para posicionamento de 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 disponível na plataforma (24 GB) diminui o tamanho da reserva de resiliência.

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

Adicionar um nó

Adicionar um nó do Azure Stack Hub desaloca 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

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

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

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

Perguntas frequentes

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

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

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

A: 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 que?

A: a memória disponível para posicionamento de VM tem várias dependências, uma das quais é a reserva do sistema operacional host. Esse valor depende da memória usada pelos diferentes processos de 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?

A: Além de executar VMs, a memória é consumida por quaisquer VMs que tenham chegado à malha. Isso significa que as VMs que estão em um estado "Criando" ou "Falha" consomem memória. As VMs desligadas de dentro do convidado, em vez de serem desalocadas do portal/powershell/cli, também consomem memória.

P: Eu tenho um Azure Stack Hub de quatro host. Meu locatário tem 3 VMs que consomem 56 GB de RAM (D5_v2) cada. Uma das VMs é redimensionada para 112 GB de RAM (D14_v2) e os relatórios de memória disponíveis no painel 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 no aumento de apenas 56 GB de RAM cada. Por que isso é assim?

A: 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 carimbo era de 56 GB de memória. Quando a VM foi redimensionada, a maior VM no carimbo tornou-se memória de 112 GB, 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 na memória da VM de locatário (de 56 GB para 112 GB), além de um aumento de 112 GB na memória de reserva de resiliência. 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 causado somente pelo aumento da memória da VM do locatário (56 GB).

Próximas etapas

Saiba mais sobre o armazenamento do Azure Stack Hub