A escolha do tamanho correto de uma Máquina Virtual no Microsoft Azure é uma decisão de arquitetura que influencia diretamente o desempenho, a escalabilidade e o custo da solução. As Azure VMs estão organizadas em famílias e séries, cada uma otimizada para determinados perfis de carga, como utilização variável de CPU, computação geral, processamento intensivo, elevada memória, armazenamento local de alto desempenho, HPC ou aceleração por GPU.
Este artigo explica como interpretar a nomenclatura das VMs, relacionar CPU, memória, armazenamento e rede com os requisitos da aplicação e aplicar uma matriz de decisão para selecionar a família mais adequada. A abordagem recomendada assenta no levantamento de requisitos, numa escolha inicial fundamentada, na validação com métricas reais e no right-sizing contínuo através do Azure Monitor e do Azure Advisor.
O objectivo não é escolher a MV maior, mas selecionar a família e o tamanho que melhor correspondem ao perfil real da carga de trabalho, mantendo a margem controlada para o crescimento.
Introdução
Uma das decisões mais importantes ao implementar uma máquina virtual no microsoft azure é a escolha do tamanho correto. Um dimensionamento inadequado pode resultar em desperdício financeiro, limitações de desempenho ou instabilidade operacional.
É comum iniciar a escolha apenas pelo número de vCPUs e pela memória RAM. contudo, cada tamanho de VM também possui limites próprios de armazenamento, IOPS, troughput e largura de banda de rede. Além disso, pertence a uma família concebida para um determinado perfil de utilização.
Compreender esta anatomia permite transformar o sizing de uma escolha baseada em intuição numa decisão técnica, mensurável e repetível.
O que Define uma Azure VM ?
uma Azure VM diaponibiliza capacidade computacional virtualizada, com sistema operativo próprio e recursos atribuídos segundo o tamanho selecionado. os principais componentes a avaliar são:
- vCPUs e características da plataforma de processamento;
- Memória RAM disponível para o sistema operativo e aplicações;
- Armazenamento temporário local, quando incluído na série;
- Discos geridos e respetivos limites de IOPS e throughput;
- Largura de banda e número máximo de interfaces de rede;
- Aceleradores especializados, como GPU ou conectividade InfiniBand;
- Funcionalidades adicionais de segurança, isolamento e computação confidencial.
Importante
O tamanho da VM estabelece limites de desempenho. Um disco rápido, por exemplo, pode não alcançar o seu potencial se a própria VM tiver um limite inferior de IOPS ou throughput.
Como Interpretar o Nome de um VM
A nomenclatura dos tamanhos do azure ajuda a identificar a família, o número de vCPUs, determinadas capacidades e a geração do hardware. Considere o exemplo:
As letras e sufixos podem variar entre famílias. Por isso, a nomenclatura deve ser usada como um primeiro indicador e confirmada da documentação da série e na região de implementação.
Principais Famílias de VM no AZure
Série B – Burstable
Concebida para cargas que operam normalmente com baixo ou moderado consumo de CPU, mas que precisam de aumentar temporariamente o processamento. Utiliza um modelo de créditos de CPU: acumula créditos em períodos de baixa utilização e consome-os durante picos.
Casos de utilização:
- Desenvolvimento e testes;
- Websites de baixo tráfego;
- Pequenas bases de dados;
- Servidores de prova de conceito e gestão.
Critério de decisão
Evite-a quando a carga exige CPU elevada de forma contínua, pois o esgotamento de créditos pode limitar o desempenho.
Série D – Propósito Geral
Oferece uma combinação equilibrada de vCPU, memória e recursos de plataforma. É frequentemente um ponto de partida adequado para cargas empresariais de produção que não apresentam um requisito dominante.
Casos de utilização:
- Servidores Web e de aplicações;
- APIs e serviços empresariais;
- Bases de dados pequenas e médias;
- Serviços de integração.
Critério de decisão
Use-a quando o perfil da aplicação é equilibrado e ainda não existem métricas que justifiquem uma família especializada.
Série E – Otimizada para Memória
Disponibiliza uma relação de memória por vCPU superior à das famílias de propósito geral. Procura reduzir pressão de memória, paginação e contenção em workloads que mantêm grandes conjuntos de dados em RAM.
Casos de utilização:
- Microsoft SQL Server;
- SAP HANA em SKUs certificados;
- Caches e bases de dados in-memory;
- ERP, CRM e analytics.
Critério de decisão
A série E é indicada quando a memória, e não a CPU, constitui o recurso dominante.
Série F – Otimizada para Computação
Privilegia capacidade de processamento por unidade de memória, sendo apropriada para tarefas CPU-intensivas e aplicações que beneficiam de elevado desempenho por núcleo.
Casos de utilização:
- Processamento batch;
- Servidores de jogos;
- Modelação e simulação;
- Serviços de análise intensiva.
Critério de decisão
É uma escolha eficaz quando as métricas demonstram utilização persistente de CPU e consumo moderado de RAM.
Série L – Otimizada para Armazenamento
Combina computação com armazenamento NVMe local de alto desempenho, adequado a cargas que exigem baixa latência e elevado throughput em dados temporários ou replicados.
Casos de utilização:
- Cassandra e MongoDB;
- Elasticsearch;
- Hadoop e processamento de dados;
- Bases NoSQL com replicação.
Critério de decisão
Os dados no disco temporário local não devem ser tratados como persistentes. A aplicação deve suportar replicação ou reconstrução.
Série M – Memória de Grande Escala
Destina-se a aplicações empresariais que exigem quantidades muito elevadas de memória e capacidade computacional.
Casos de utilização:
- SAP HANA de grande escala;
- Bases de dados in-memory massivas;
- Sistemas financeiros e analíticos críticos.
Critério de decisão
Valide certificações da aplicação, disponibilidade regional, quotas e custo antes de selecionar esta família.
Série N – Aceleração por GPU
Integra GPUs para computação, treino de modelos, inferência, visualização e ambientes gráficos. As subfamílias NC, ND e NV respondem a perfis distintos.
Casos de utilização:
- IA e Machine Learning;
- Deep Learning e inferência;
- CAD e renderização 3D;
- Virtual Desktop com aceleração gráfica.
Critério de decisão
A escolha deve considerar o modelo e número de GPUs, memória de GPU, drivers, framework, licenciamento e disponibilidade regional.
Série H – High Performance Computing
É direcionada a computação científica e HPC, incluindo workloads paralelos que podem exigir elevada largura de banda entre nós e conectividade especializada.
Casos de utilização:
- Dinâmica de fluidos;
- Simulações científicas;
- Meteorologia e investigação;
- Processamento paralelo distribuído.
Critério de decisão
Confirme se a aplicação beneficia efetivamente de paralelismo, MPI e rede de baixa latência antes de assumir o custo e a complexidade de HPC.
Matriz de Decisão por Cenário
Metodologia prática de sizing
- Caracterizar a Carga
Documente o sistema operativo, arquitetura de CPU suportada, número de utilizadores, padrão de utilização, dependências, requisitos de disponibilidade e crescimento esperado. - Medir CPU e Memória
Recolha utilização média, percentis e picos. Identifique se os picos são ocasionais ou sustentados e verifique pressão de memória, paginação e consumo por processo. - Dimensionar Armazenamento
Determine capacidade, IOPS, throughput, latência e perfil de leitura/escrita. Considere separação entre sistema operativo, dados e logs. - Avaliar Rede
Analise throughput de entrada e saída, número de NICs, latência, sessões simultâneas e necessidade de Accelerated Networking. - Identificar Requisitos Especiais
Confirme necessidades de GPU, InfiniBand, computação confidencial, isolamento, arquitetura Arm ou disco temporário local. - Selecionar Família e Tamanho Inicial
Escolha a família de acordo com o recurso dominante e um tamanho que cubra a carga prevista com margem controlada, sem sobredimensionamento excessivo. - Validar na Região
Verifique disponibilidade do SKU, quotas, restrições de zona, compatibilidade com discos, funcionalidades de rede e modelo de segurança. - Testar e Otimizar
Execute testes representativos, monitorize o comportamento em produção e aplique right-sizing com base em métricas e recomendações do Azure Advisor.
Checklist Antes da Decisão
- A aplicação exige arquitetura x86 ou suporta Arm?
- A CPU é ocasional, constante ou o principal gargalo?
- Qual é a memória média, máxima e prevista para crescimento?
- Quais são as IOPS, throughput e latência exigidos pelos discos?
- Qual é o limite de rede necessário e a VM suporta Accelerated Networking?
- A carga precisa de GPU, HPC, isolamento ou computação confidencial?
- O tamanho está disponível na região e nas Availability Zones pretendidas?
- Existem quotas suficientes para a família selecionada?
- A aplicação permite resize, scale-out ou uma arquitetura com múltiplas instâncias?
- O custo foi estimado para Pay-As-You-Go e para opções de compromisso aplicáveis?
Exemplo Prático de Seleção
Considere uma aplicação empresarial com quatro vCPUs, cerca de 12 GiB de memória em utilização normal, SQL Server, crescimento esperado e necessidade de desempenho estável.
A escolha final não deve ser feita apenas pela descrição do cenário. Deve ser validada através de métricas da carga atual, testes de desempenho, limites da VM e custos na região selecionada. Neste exemplo, a família E constitui uma candidata natural, enquanto o tamanho exato depende da medição real.
Erros Comuns a Evitar
- Escolher a VM apenas pelo número de vCPUs;
- Assumir que mais vCPUs resolvem um problema causado por memória, disco ou rede;
- Utilizar série B para CPU elevada e sustentada;
- Confundir armazenamento temporário local com armazenamento persistente;
- Ignorar limites agregados da VM para IOPS, throughput e rede;
- Selecionar um SKU antes de validar a disponibilidade regional e as quotas;
- Manter permanentemente o tamanho inicial sem revisão por métricas;
- Migrar uma VM on-premises numa relação direta 1:1 sem assessment e right-sizing.
Boas Práticas Operacionais
- Comece com uma hipótese de sizing fundamentada, não com a maior VM disponível;
- Utilize ambientes de teste e cargas representativas antes de produção;
- Monitorize CPU, memória guest, discos, rede e experiência da aplicação;
- Defina alertas para saturação persistente e para capacidade próxima dos limites;
- Reavalie o tamanho após alterações de versão, aumento de utilizadores ou mudança de arquitetura;
- Considere scale-out quando a aplicação o permite, em vez de depender apenas de scale-up;
- Registe a decisão de sizing, as métricas utilizadas, as suposições e a data da próxima revisão.
Concluindo, escolher corretamente uma Azure VM exige alinhar o perfil técnico da carga com a finalidade da família e os limites do tamanho. A série B responde a cargas variáveis; a D a cenários equilibrados; a E a requisitos elevados de memória; a F a processamento intensivo; a L a armazenamento local de alto desempenho; a M a memória de grande escala; a N a aceleração por GPU; e a H a HPC.
O processo não termina no deployment. O sizing deve evoluir com base em monitorização, testes, crescimento e análise de custos. Esta disciplina reduz desperdício, evita throttling e cria uma infraestrutura mais previsível, eficiente e sustentável.
Conclusão
A VM certa é aquela que satisfaz os requisitos medidos da aplicação, respeita os limites da plataforma e mantém um custo justificável. Sizing é um processo contínuo, não uma decisão única.
Para leitura adicional segue os links da documentação:
Virtual machine sizes overview – Azure Virtual Machines | Microsoft Learn
Virtual Machine series | Microsoft Azure
Até ao próximo artigo