Azure Stack Hub capacidade de computação

Os tamanhos de VM (máquina virtual) com suporte Azure Stack Hub são um subconjunto daqueles com suporte 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 no consumo do locatário, as experiências de locatário sofrerão quando outros locatários sobreconsumirem recursos. Para saída de rede da VM, há limites de largura de banda em Azure Stack Hub que corresponderem à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 locatários para acesso de armazenamento.

Importante

O Azure Stack Hub Planejador de Capacidade 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 remediado adicionando capacidade adicionalou removendo máquinas virtuais que não são mais necessárias.

Posicionamento de VM

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

Azure Stack Hub usa duas considerações ao colocar VMs. Primeiro, 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 conjuntos de dimensionar 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 propaga entre 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. 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 serão fisicamente isoladas umas das outras, difundindo-as da maneira mais precisa possível em vários domínios de falha (Azure Stack Hub nós). Se houver uma falha de hardware, as VMs do domínio de falha com 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 dimensionar máquinas virtuais usam conjuntos de disponibilidade no back-end e garantem que cada instância do conjunto de dimensionar máquinas virtuais seja colocada em um domínio de falha diferente. Isso significa que eles usam nós Azure Stack Hub infraestrutura separados. Por exemplo, em um sistema de Azure Stack Hub de quatro nós, pode haver uma situação em que um conjunto de dimensionar máquinas virtuais de três instâncias falhará na criação devido à falta da capacidade de quatro nós para colocar três instâncias do conjunto de dimensionar máquinas virtuais em três nós Azure Stack Hub separados. Além disso, Azure Stack Hub nós podem ser preenchidos em níveis variáveis antes de tentar o posicionamento.

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

Como os algoritmos de posicionamento não têm a taxa de excesso de superprovisionamento do núcleo virtual para físico existente como um fator, cada host pode ter uma taxa diferente. Como a Microsoft, não fornecemos diretrizes sobre a taxa de núcleo físico para virtual devido à variação em cargas de trabalho e 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 total de VMs em Azure Stack Hub é 700 e 60 por nó de unidade de escala. Por exemplo, um limite de oito Azure Stack Hub VM seria 480 (8 * 60). Para uma solução de 12 a 16 Azure Stack Hub servidor, o limite seria de 700. Esse limite foi criado tendo em mente todas as considerações de capacidade de computação, como a reserva de resiliência e a taxa de virtual para física da CPU que um operador gostaria de manter no carimbo. Para obter mais informações, consulte a nova versão do planejador de capacidade.

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 a 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 forme 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 de forma confiável VMs 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

Azure Stack hub reserva memória para o failover de VMs de infraestrutura e locatário. Ao contrário de outras VMs, as VMs de GPU são executados 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 levar em conta a memória de VM de locatário de HA também.

Azure Stack Hub memória

Azure Stack Hub é 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, Azure Stack Hub tentará reiniciar essa VM em outro host. Um segundo exemplo durante a adoção e atualização do software Azure Stack Hub aplicativo. 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 a migração ocorra. Uma parte da memória total do host está reservada e não está disponí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 em Azure Stack Hub. O diagrama a seguir mostra a capacidade de memória física em uma Azure Stack Hub de escala no Azure Stack Hub:

Physical memory capacity on an Azure Stack Hub scale unit

A memória usada é feita 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 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 dos Espaços Diretos. 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 com Azure Stack Hub. A partir da versão 2102 do Azure Stack Hub, isso inclui aproximadamente 31 VMs que levam até 268 GB + (4 GB x não. de nós) de memória. 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.
  • Reserva de resiliência: 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 ao vivo bem-sucedida de VMs.
  • VMs de locatário: As VMs de locatário criadas Azure Stack Hub usuários. Além de executar VMs, a memória é consumida por todas as VMs que foram paradas na malha. Isso significa que as VMs no estado "Criando" ou "Falha" ou as VMs desligadas de dentro do convidado consumirão memória. No entanto, as VMs que foram desalocadas usando a opção parar desalocar do portal/powershell/cli não consumirão memória de Azure Stack Hub.
  • RPs (provedores de recursos de aplicaçã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 Azure Stack Hub Planejador de Capacidade 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 posicionamento de VM de locatário. Essa capacidade de memória é para toda a unidade de Azure Stack Hub escala.

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 Azure Stack Hub infraestrutura 1

Reserva de resiliência = N * R + (N-2)* V + min(H-R, sum(memoryofHAVMs))

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 sistema operacional, que é 0,15 nesta fórmula2
  • V = Maior VM de ALTA na unidade de escala
  • memoryofHAVMs = soma da memória de todas as VMs de HA na unidade de escala. Isso inclui 142 GB de infraestrutura de HA + memória de VMs de locatário de HA

1 Azure Stack Hub de infraestrutura = 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, consumir cerca de 268 GB + (4 GB x nº 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 a patch. Essa estrutura de serviço interna permite a introdução futura de novos serviços de infraestrutura à medida que eles 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 variará 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 HA na unidade de escala, é baseado dinamicamente no maior tamanho de memória da VM de locatário. Por exemplo, o maior valor de VM de ALTA é um mínimo de 12 GB (contabilização para a VM de infraestrutura) ou 112 GB ou qualquer outro tamanho de memória de VM com suporte na solução Azure Stack Hub. Alterar a maior VM de HA na Azure Stack Hub fabric resultará em um aumento na reserva de resiliência e também no aumento na memória da própria VM. Lembre-se de que as VMs de GPU são executados no modo não HA.

Considerações para desalocação

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

Se a VM desaloqueada for iniciada novamente, o uso ou a 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á iniciar.

As VMs grandes implantadas atuais 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 LTD01P-NODE01
10cd7b0f-68f4-40ee-9d98-b9637438ebf4 112 2.2392578125 LTD01P-NODE01
2e403868-ff81-4abb-b087-d9625ca01d84 112 2.2392578125 LTD01P-NODE04

Há três maneiras de desalocar a memória para o posicionamento da VM usando a fórmula Resiliência reserve = 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 VM menor no carimbo (24 GB) reduzirá o tamanho da reserva de resiliência.

Reduce the VM size

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

Memória total Infra GB GB de locatário Reserva de resiliência Memória reservada total Total de GB disponível 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 Azure Stack Hub nó de rede desalocará a memória distribuindo igualmente a memória entre os dois nós.

Add a node

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

Memória Total Infra GB GB de locatário Reserva de resiliência Memória reservada total Total de GB disponível 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á o total de memória disponível.

Increase the size of the node

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

Memória Total Infra GB GB de locatário Reserva de resiliência Memória reservada total Total de GB disponível 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 que o gráfico de funcionalidades no portal do administrador mostre 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?

Um: no PowerShell, execute , 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 em 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 das quais é a reserva do sistema operacional host. Esse valor depende da memória usada pelos diferentes processos do Hyper-V em execução no host, que não é um valor constante.

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

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

P:Tenho uma conta de quatro Azure Stack Hub. Meu locatário tem três VMs que consomem 56 GB de RAM (D5_v2) cada. Uma das VMs é relizada 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 folha de capacidade. O reizing 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 por Azure Stack Hub. A reserva de resiliência é uma função do maior tamanho de VM no Azure Stack Hub carimbo. A princípio, a maior VM no carimbo era de 56 GB de memória. Quando a VM foi relizada, a maior VM no carimbo se tornou 112 GB de memória, o que não apenas 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 memória de 56 GB (56 GB para 112 GB de VM de locatário) + aumento de memória de reserva de resiliência de 112 GB. Quando as VMs subsequentes foram reorganizadas, o maior tamanho da VM ficou como a VM de 112 GB e, portanto, não houve nenhum 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 Azure Stack Hub, consulte Adicionar endereços IP públicos.

Próximas etapas

Saiba mais sobre Azure Stack Hub armazenamento