Capacidade de computação do Azure Stack Hub
Os tamanhos de máquina virtual (VM) suportados no Azure Stack Hub são um subconjunto daqueles suportados no Azure. O Azure impõe limites de recursos ao longo de muitos vetores para evitar o consumo excessivo de recursos (servidor, local e nível de serviço). Sem impor alguns limites ao consumo do inquilino, o inquilino sofre quando outros inquilinos consomem recursos em excesso. 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 pelos locatários para acesso ao armazenamento.
Importante
O Planejador de Capacidade 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 atinge 85%. Esse alerta pode ser corrigido adicionando mais capacidadeou removendo máquinas virtuais que não são mais necessárias.
Posicionamento da VM
O mecanismo de posicionamento do Azure Stack Hub coloca VMs locatárias nos hosts disponíveis.
O Azure Stack Hub usa duas considerações ao colocar VMs. Um, há memória suficiente no host para esse tipo de VM? E dois, as VMs fazem parte de um conjunto de disponibilidade ou são parte de 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 máquinas virtuais (VMs) são colocadas em um conjunto de disponibilidade que as distribui 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 ter um conjunto de disponibilidade com um máximo de 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 afetado 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 rebalanceadas para manter a alta disponibilidade.
Os conjuntos de dimensionamento de máquina virtual usam conjuntos de disponibilidade no back-end e certifique-se de que cada instância do conjunto de dimensionamento de máquina virtual seja colocada em um domínio de falha diferente. Isso significa que eles usam nós de infraestrutura separados do Azure Stack Hub. Por exemplo, em um sistema Azure Stack Hub de quatro nós, pode haver uma situação em que um conjunto de escala de máquina virtual de três instâncias falha na criação devido à falta da capacidade de quatro nós para colocar três instâncias de conjunto de escala de máquina virtual em três nós separados do Hub de Stack do Azure. Além disso, antes de tentar o posicionamento, os nós do Azure Stack Hub podem ser preenchidos em vários níveis.
O Azure Stack Hub não sobrecompromete a memória. No entanto, é permitido alocar mais núcleos virtuais do que núcleos físicos disponíveis.
Como os algoritmos de posicionamento não analisam a taxa de superprovisionamento de núcleo virtual para físico existente como um fator, cada host pode ter uma proporção diferente. Como Microsoft, não fornecemos orientação sobre a relação entre núcleo físico e virtual devido à variação nas cargas de trabalho e nos requisitos de nível de serviço.
Consideração do 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 700. Esse limite é criado com todas as considerações de capacidade de computação em mente, como a reserva de resiliência e a relação virtual/física da CPU 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.
Observação
Uma parte do máximo de 700 VMs está reservada para VMs de infraestrutura do Azure Stack Hub. Para obter mais informações, consulte o planificador 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 os lotes forneciam implantações de VM confiáveis para atingir 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 as implantações em lote. As operações de início, parada-deslocalização e atualização devem ser feitas em um tamanho de lote de 30, deixando 5 minutos entre cada lote.
Considerações sobre VMs de GPU
O Azure Stack Hub reserva memória para a infraestrutura e para as VMs locatárias realizarem o failover. Ao contrário de outras VMs, as VMs 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 contabilizar também a memória de VM de locatário 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 durante a aplicação de patches e a atualização do software Azure Stack Hub. Se houver 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 movimento de VM só pode ser alcançado 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 consultar um gráfico circular 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 do Azure Stack Hub no Azure Stack Hub:
A memória utilizada é composta por vários componentes. Os seguintes componentes consomem memória na seção de uso do gráfico circular:
- Uso ou reserva do sistema operativo do host: A memória usada pelo sistema operativo (SO) no host, tabelas de página de memória virtual, processos que estão a ser executados no sistema operativo do host e a 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. Como discutido anteriormente, essas VMs fazem parte do máximo de 700 VMs. A utilização da memória do componente de serviços de infraestrutura pode mudar à medida que trabalhamos para tornar nossos serviços de infraestrutura mais escaláveis e resilientes. Para obter mais informações, consulte o planejador de capacidade do Azure Stack Hub
- Reserva de resiliência: Azure Stack Hub reserva uma parte da memória para permitir a disponibilidade do inquilino durante a falha de um único host, bem como durante a aplicação de patches e atualizações para permitir a migração ao vivo bem-sucedida de VMs.
- VMs de inquilino: As máquinas virtuais de inquilino criadas por utilizadores do Azure Stack Hub. Além de executar VMs, a memória é consumida por todas as VMs que foram implantadas na infraestrutura. Isso significa que as VMs em estado de "a ser criado" ou "em falha", ou as VMs desligadas dentro do sistema convidado, consomem memória. No entanto, as VMs que foram desalocadas usando a opção stop deallocated do portal/powershell/cli não consumirão memória do Azure Stack Hub.
- Provedores de recursos de valor agregado (RPs): VMs implantadas para 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 do Planejador de Capacidade do Hub de Pilha do Azure 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 a totalidade da unidade de escala do Azure Stack Hub.
Memória disponível para colocação de VM = memória total do host - reserva de resiliência - memória usada por VMs de inquilinos em execução - sobrecarga da infraestrutura do Azure Stack Hub 1
- 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 da Infraestrutura do Azure Stack Hub = 268 GB + (4GB x N)
Onde:
- H = Tamanho da memória de servidor único
- N = Tamanho da Unidade de Escala (número de servidores)
- R = A reserva do sistema operativo para a sobrecarga do sistema, que é .15 nesta fórmula2
- V = Maior VM HA na unidade de escalonamento
1 sobrecarga da 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 é satisfazer a separação de serviços necessária para atender aos requisitos de segurança, escalabilidade, manutenção e aplicação de patches. Esta estrutura interna de serviços permite a introdução futura de novos serviços de infraestrutura à medida que são desenvolvidos.
2 Reserva do sistema operacional para sobrecarga = 15% (.15) de memória do nó. O valor de reserva do sistema operacional é uma estimativa e varia com base na capacidade de memória física do servidor e na sobrecarga geral do sistema operacional.
O valor V, a maior VM de Alta Disponibilidade na unidade de escala, é baseado dinamicamente no maior tamanho de memória da VM de um locatário. Por exemplo, o maior valor de VM HA é um mínimo de 12 GB (contabilizando a VM de infraestrutura) ou 112 GB ou qualquer outro tamanho de memória de VM suportado na solução Azure Stack Hub. Alterar a maior VM 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 da GPU são executadas no modo não-HA.
Cálculo da amostra
Temos uma implantação do Azure Stack Hub de quatro nós pequena, com 768 GB de RAM em cada nó. Planejamos colocar uma máquina virtual para o servidor SQL com 128 GB de RAM (Standard_E16_v3). Qual é a memória disponível para o posicionamento da VM?
- Total de memória 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 locatárias = Memória real consumida pela carga de trabalho do locatário, não depende da configuração HA = 0 GB
- Sobrecarga da Infraestrutura do Hub do Azure Stack = 268 GB + (4GB x N) = 268 + (4 * 4) = 284 GB
Memória disponível para colocação de VM = memória total do host - reserva de resiliência - memória usada por VMs de locatário em execução - sobrecarga de infraestrutura do Azure Stack Hub
Memória disponível para posicionamento de VM = 3072 - 1370 - 0 - 284 = 1418 GB
Considerações para a liberação
Quando uma VM está no estado desalocado, os recursos de memória não estão a ser usados. Isso permite que outras VMs sejam colocadas no sistema.
Se a VM desalocada for então 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) | Nome do Computador |
|---|---|---|---|
| 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 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 (24 GB) reduz o tamanho da reserva de resiliência.
Reserva de resiliência = 384 + 172,8 + 48 = 604,8 GB
| Memória total | Infra GB | GB do locatário | Reserva de resiliência | Total de memória reservada | Total de GB disponíveis para colocação |
|---|---|---|---|---|---|
| 1536 gigabytes | 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 desaloca a memória ao distribuí-la igualmente 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 | Total de memória reservada | Total de GB disponíveis para colocação |
|---|---|---|---|---|---|
| 1536 GB | 258 GB | 329,25 GB | 604,8 GB | 258 + 329,25 + 604,8 = 1168 GB | ~ 344 GB |
Aumente a memória em cada nó para 512 GB
Aumentar a memória de cada nó aumenta a quantidade total de memória disponível.
Reserva de resiliência = 512 + 230,4 + 224 = 966,4 GB
| Memória total | Infra GB | GB do locatário | Reserva de resiliência | Total de memória reservada | Total de GB disponíveis para colocação |
|---|---|---|---|---|---|
| 2048 (4 * 512) GB | 258 GB | 505,75 GB | 966,4 GB | 1730,15 GB | ~ 318 GB |
Perguntas Frequentes
Q: Meu locatário implantou uma nova VM, quanto tempo leva para o gráfico de capacidade no portal do administrador mostrar a capacidade restante?
A: A lâmina de capacidade é atualizada a cada 15 minutos, então leve isso em consideração.
Q: Como posso ver os núcleos disponíveis e os núcleos atribuídos?
Um: No PowerShell executar 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
Q: O número de VMs implantadas no meu Azure Stack Hub não mudou, mas minha capacidade está flutuando. Porquê?
Um: A memória disponível para a colocação de VMs tem várias dependências, uma das quais é a reserva do sistema operativo anfitrião. Esse valor depende da memória usada pelos diferentes processos de Hyper-V em execução no host, que não é um valor constante.
Q: Em que estado as VMs locatárias precisam estar para consumir memória?
Uma: Além de executar VMs, a memória é consumida por todas as VMs que aterraram no tecido. Isso significa que as VMs que estão em um estado "Criando" ou "Falhado" consomem memória. As VMs são desligadas a partir do sistema operativo convidado, em vez de serem paradas e desalocadas através do portal, powershell ou CLI, também consomem memória.
Q: Tenho um Azure Stack Hub de quatro hosts. 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 o relatório de memória disponível no painel resultou em um pico de uso de 168 GB na capacidade disponível. O redimensionamento subsequente das outras duas D5_v2 VMs para D14_v2 resultou em apenas 56 GB de RAM de aumento cada. Porquê?
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 selo 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 na plataforma tornou-se uma VM com 112 GB de memória, o que não só aumentou a memória usada por essa VM locatária, mas também aumentou a reserva de resiliência. Essa alteração resultou em um aumento de 56 GB (aumento de memória da VM locatária de 56 GB para 112 GB) + aumento de memória de reserva de resiliência de 112 GB. Quando as VMs subsequentes foram redimensionadas, o maior tamanho da VM permaneceu como a VM de 112 GB e, portanto, não houve aumento resultante da reserva de resiliência. O aumento no consumo de memória foi apenas devido ao aumento da memória da VM do locatário (56 GB).
Observação
Os requisitos de planeamento de capacidade para a rede de comunicação são mínimos, pois apenas a dimensão do VIP público é ajustá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.