Capacidade de computação do Azure Stack Hub
Os tamanhos da máquina virtual (VM) suportados no Azure Stack Hub são um subconjunto dos suportados no Azure. O Azure impõe limites de recursos ao longo de muitos vetores para evitar o excesso de consumo de recursos (nível de serviço e local do servidor). Sem impor alguns limites ao consumo de inquilinos, as experiências de inquilino sofrerão quando outros inquilinos sobrecarregam os recursos. Para a saída de rede da VM, existem maiúsculas de largura de banda 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 básico de recursos por inquilinos para acesso ao armazenamento.
Importante
O Capacity Planner do Azure Stack Hub não considera nem garante o desempenho de IOPS. O portal de administrador mostra um alerta de aviso quando o consumo total de memória do sistema atingiu os 85%. Este alerta pode ser remediado ao adicionar capacidade adicional ou ao remover máquinas virtuais que já não são necessárias.
Colocação de VMs
O motor de colocação do Azure Stack Hub coloca as VMs do inquilino nos anfitriões disponíveis.
O Azure Stack Hub utiliza duas considerações ao colocar VMs. Primeiro, existe memória suficiente no anfitrião para esse tipo de VM? E segundo, as VMs fazem parte de um conjunto de disponibilidade ou são conjuntos de dimensionamento de máquinas virtuais?
Para alcançar uma elevada 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 num conjunto de disponibilidade que as distribui por vários domínios de falha. Um domínio de falha num conjunto de disponibilidade é definido como um único nó na unidade de escala. O Azure Stack Hub suporta 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 num conjunto de disponibilidade serão fisicamente isoladas umas das outras ao distribuí-las o mais uniformemente possível por vários domínios de falha (nós do Azure Stack Hub). Se ocorrer uma falha de hardware, as VMs do domínio de falha falhada serão reiniciadas noutros domínios de falha. Se possível, serão mantidos em domínios de falha separados das outras VMs no mesmo conjunto de disponibilidade. Quando o anfitrião voltar a estar online, as VMs serão reequilibradas para manter a elevada disponibilidade.
Os conjuntos de dimensionamento de máquinas virtuais utilizam conjuntos de disponibilidade no back-end e confirme que cada instância do conjunto de dimensionamento de máquinas virtuais é colocada num domínio de falha diferente. Isto significa que utilizam nós de infraestrutura do Azure Stack Hub separados. Por exemplo, num 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 falhará na criação devido à falta de capacidade de quatro nós para colocar três instâncias de 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 diferentes níveis antes de tentar colocar.
O Azure Stack Hub não sobrecompromissa a memória. No entanto, é permitido um sobrecompromisso do número de núcleos físicos.
Uma vez que os algoritmos de colocação não olham para a relação de sobreaprovisionamento entre núcleos virtuais e físicos existente como um fator, cada anfitrião pode ter uma proporção diferente. Como Microsoft, não fornecemos orientações sobre a proporção de núcleo físico para virtual devido à variação das cargas de trabalho e dos requisitos de nível de serviço.
Consideração para o número total de VMs
Existe um limite para o número total de VMs que podem ser criadas. O número máximo de VMs no Azure Stack Hub é de 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 do Azure Stack Hub de 12 a 16 servidores, o limite seria 700. Este limite foi criado tendo em conta todas as considerações sobre a capacidade de computação, como a reserva de resiliência e a relação virtual-física da CPU que um operador gostaria de manter no selo.
Se o limite de dimensionamento da VM for atingido, os seguintes códigos de erro são devolvidos como resultado: VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceeded.
Nota
Uma parte do máximo de 700 VMs está reservada para VMs de infraestrutura do Azure Stack Hub. Para obter mais informações, veja Planeador de capacidade do Azure Stack Hub.
Consideração para a implementaçã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 implementações de VM fiáveis para atingir uma escala de 700 VMs. Com a versão de 2005 do Azure Stack Hub, conseguimos aprovisionar VMs de forma fiável em tamanhos de lote de 40 com intervalo de 5 minutos entre implementações em lote. As operações Iniciar, Parar desalocar e atualizar devem ser efetuadas com 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 do inquilino realizarem a ativação pós-falha. Ao contrário de outras VMs, as VMs de GPU são executadas num modo não HA (elevada disponibilidade) e, por conseguinte, não efetuam a ativação pós-falha. Como resultado, a memória reservada para um carimbo apenas de VM de GPU é o que é necessário para a infraestrutura efetuar a ativação pós-falha, em vez de contabilizar também a memória da VM do inquilino ha.
Memória do Azure Stack Hub
O Azure Stack Hub foi concebido para manter as VMs em execução que foram aprovisionadas com êxito. Por exemplo, se um anfitrião estiver offline devido a uma falha de hardware, o Azure Stack Hub tentará reiniciar essa VM noutro anfitrião. Um segundo exemplo durante a aplicação de patches e a atualização do software do Azure Stack Hub. Se for necessário reiniciar um anfitrião físico, é efetuada uma tentativa de mover as VMs executadas nesse anfitrião para outro anfitrião disponível na solução.
Esta gestão ou movimento de VM só pode ser alcançado se existir capacidade de memória reservada para permitir que o reinício ou migração ocorra. Uma parte da memória total do anfitrião está reservada e indisponível para o posicionamento da VM do inquilino.
Pode rever um gráfico circular no portal do administrador que mostra a memória gratuita e utilizada no Azure Stack Hub. O diagrama seguinte mostra a capacidade de memória física numa unidade de escala do Azure Stack Hub no Azure Stack Hub:
A memória utilizada é composta por vários componentes. Os seguintes componentes consomem a memória na secção de utilização do gráfico circular:
- Utilização ou reserva do SO anfitrião: A memória utilizada pelo sistema operativo (SO) no anfitrião, as tabelas de páginas de memória virtual, os processos em execução no SO anfitrião e a cache de memória dos Espaços Diretos. Uma vez que este valor depende da memória utilizada pelos diferentes processos de Hyper-V em execução no anfitrião, pode flutuar.
- Serviços de infraestrutura: As VMs de infraestrutura que compõem o Azure Stack Hub. Conforme abordado anteriormente, estas 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 os nossos serviços de infraestrutura mais dimensionáveis e resilientes. Para obter mais informações, veja o planeador 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 inquilino durante uma única falha de anfitrião, bem como durante o patch e a atualização para permitir uma migração em direto bem-sucedida das VMs.
- VMs de inquilino: As VMs de inquilino criadas pelos utilizadores do Azure Stack Hub. Além de executar VMs, a memória é consumida por quaisquer VMs que tenham desembarcado nos recursos de infraestrutura. Isto significa que as VMs no estado "A Criar" ou "Com Falhas", ou as VMs encerradas a partir do convidado, irão consumir memória. No entanto, as VMs que foram desalocadas com a opção parar desalocada do portal/powershell/cli não consumirão memória do Azure Stack Hub.
- Fornecedores de recursos de valor acrescentado (RPs): VMs implementadas para os RPs de valor acrescentado, como SQL, MySQL, Serviço de Aplicações, etc.
A melhor forma de compreender o consumo de memória no portal é utilizar o Capacity Planner do Azure Stack Hub para ver o impacto de várias cargas de trabalho. O cálculo seguinte é o mesmo utilizado pelo planeador.
Este cálculo resulta na memória total disponível que pode ser utilizada para o posicionamento da VM do inquilino. Esta capacidade de memória destina-se à totalidade da unidade de escala do Azure Stack Hub.
Memória disponível para colocação de VMs = memória total do anfitrião – reserva de resiliência – memória utilizada pela execução de VMs de inquilino – Overhead 1 da Infraestrutura do Azure Stack Hub
- Memória total do anfitrião = Soma da memória de todos os nós
- Reserva de resiliência = H + R * ((N-1) * H) + V * (N-2)
- A memória utilizada pelas VMs do inquilino = Memória real consumida pela carga de trabalho do inquilino não depende da configuração ha
- Sobrecarga da 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 operativo para sobrecarga do SO, que é 0,15 nesta fórmula2
- V = Maior VM HA na unidade de escala
1 Sobrecarga da Infraestrutura do Azure Stack Hub = 268 GB + (4 GB x n.º de nós). São utilizadas aproximadamente 31 VMs para alojar a infraestrutura do Azure Stack Hub e, no total, consomem cerca de 268 GB + (4 GB x n.º de nós) de memória e 146 núcleos virtuais. A lógica para este número de VMs é satisfazer a separação de serviço necessária para satisfazer os requisitos de segurança, escalabilidade, manutenção e aplicação de patches. Esta estrutura de serviços internos permite a introdução futura de novos serviços de infraestrutura à medida que são desenvolvidos.
2 Reserva do sistema operativo para overhead = 15% (.15) de memória do nó. O valor de reserva do sistema operativo é uma estimativa e irá variar com base na capacidade de memória física do servidor e na sobrecarga geral do sistema operativo.
O valor V, a maior VM HA na unidade de escala, baseia-se dinamicamente no maior tamanho de memória da VM do inquilino. Por exemplo, o maior valor da VM HA é um mínimo de 12 GB (contabilização da VM de infraestrutura) ou 112 GB ou qualquer outro tamanho de memória de VM suportado na solução do Azure Stack Hub. A alteração da maior VM HA nos recursos de infraestrutura do Azure Stack Hub resultará num aumento da 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.
Cálculo de exemplo
Temos uma pequena implementação de quatro nós do Azure Stack Hub com 768 GB de RAM em cada nó. Planeamos 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 anfitrião = Soma de 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 utilizada pelas VMs do inquilino = Memória real consumida pela carga de trabalho do inquilino, não depende da configuração ha = 0 GB
- Sobrecarga da Infraestrutura do Azure Stack Hub = 268 GB + (4 GB x N) = 268 + (4 * 4) = 284 GB
Memória disponível para colocação da VM = memória total do anfitrião – reserva de resiliência – memória utilizada pela execução de VMs de inquilino – Sobrecarga da Infraestrutura do Azure Stack Hub
Memória disponível para colocação de VMs = 3072 - 1370 - 0 - 284 = 1418 GB
Considerações sobre a desalocada
Quando uma VM está no estado desalocado , os recursos de memória não estão a ser utilizados. Isto permite que outras VMs sejam colocadas no sistema.
Se a VM desalocada for iniciada novamente, a utilização ou alocação da memória é tratada como uma nova VM colocada no sistema e a memória disponível é consumida. Se não existir memória disponível, a VM não será iniciada.
As VMs grandes implementadas atuais mostram que a memória alocada é de 112 GB, mas a procura de memória destas VMs é de cerca de 2 a 3 GB.
| Name | Memória Atribuída (GB) | Procura 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 |
Existem três formas de desalocar a memória para colocação de VMs com a fórmula Reserva de resiliência = H + R * ((N-1) * H) + V * (N-2):
- Reduzir o tamanho da VM maior
- Aumentar a memória de um nó
- Adicionar um nó
Reduzir o tamanho da VM maior
Reduzir o tamanho da VM maior para a VM mais pequena seguinte 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 | GB do inquilino | Reserva de resiliência | Memória total 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 |
Adicionar um nó
Adicionar um nó do Azure Stack Hub desalocará a memória ao distribuir 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 | GB do inquilino | Reserva de resiliência | Memória total 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 |
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 | GB do inquilino | Reserva de resiliência | Memória total 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 Mais Frequentes
P: O meu inquilino implementou uma nova VM, quanto tempo demora o gráfico de capacidades no portal de administrador a mostrar a capacidade restante?
R: O painel de capacidade é atualizado a cada 15 minutos, por isso tenha isso em consideração.
P: Como posso ver os núcleos disponíveis e os núcleos atribuídos?
R: Na execução test-azurestack -include AzsVmPlacement -debugdo PowerShell, o 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 implementadas no meu Azure Stack Hub não mudou, mas a minha capacidade está a flutuar. Porquê?
R: A memória disponível para colocação de VMs tem múltiplas dependências, uma das quais é a reserva do SO anfitrião. Este valor depende da memória utilizada pelos diferentes processos hyper-V em execução no anfitrião, o que não é um valor constante.
P: Em que estado têm de estar as VMs inquilinas para consumir memória?
R: Além de executar VMs, a memória é consumida por quaisquer VMs que tenham desembarcado nos recursos de infraestrutura. Isto significa que as VMs que estão num estado "A Criar" ou "Com Falhas" consumirão memória. As VMs encerradas a partir do convidado em vez de pararem desalocadas do portal/powershell/cli também consumirão memória.
P: Tenho um Azure Stack Hub de quatro anfitriões. O meu inquilino tem 3 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 no dashboard resultaram num pico de utilização de 168 GB no painel de capacidade. O redimensionamento subsequente das outras duas VMs D5_v2 para D14_v2 resultou num aumento de apenas 56 GB de RAM cada. Porque é que isto é 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 do selo era de 56 GB de memória. Quando a VM foi redimensionada, a maior VM do selo tornou-se 112 GB de memória que não só aumentou a memória utilizada por essa VM de inquilino, como também aumentou a reserva de resiliência. Esta alteração resultou num aumento de 56 GB (aumento da memória da VM do inquilino de 56 GB para 112 GB) + aumento da memória da reserva de resiliência de 112 GB. Quando as VMs subsequentes foram redimensionadas, o maior tamanho da VM manteve-se como a VM de 112 GB e, portanto, não houve um aumento resultante da reserva de resiliência. O aumento do consumo de memória foi apenas o aumento da memória da VM do inquilino (56 GB).
Nota
Os requisitos de planeamento de capacidade para redes são mínimos, uma vez que 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, veja Adicionar endereços IP públicos.
Passos seguintes
Saiba mais sobre o armazenamento do Azure Stack Hub