VM Sizing na Prática: vCPU, Memória, IOPS e Limites por Família

Quando uma aplicação apresenta lentidão numa Azure Virtual Machine, a primeira reação tende a ser aumentar o número de vCPUs ou a memória RAM. Essa resposta pode resolver alguns casos, mas muitos problemas resultam de limites de IOPS, throughput de disco, largura de banda de rede, CPU burstável ou de um rácio inadequado entre computação e memória.

Cada tamanho de VM estabelece um envelope de desempenho. Esse envelope inclui recursos visíveis, como vCPU e RAM, e limites que nem sempre são considerados no desenho inicial, como IOPS agregados, throughput de armazenamento, número máximo de discos de dados, interfaces de rede e desempenho de rede esperado. Compreender estes limites é fundamental para garantir que os recursos provisionados estão alinhados com os requisitos reais da carga de trabalho e com os objetivos de desempenho da organização.

1. Introdução

O sizing de uma VM é uma decisão de arquitetura com impacto direto no desempenho, na estabilidade, na escalabilidade e no custo. Em ambientes tradicionais, é frequente migrar servidores numa relação 1:1, preservando CPU e memória do equipamento de origem. Na cloud, essa abordagem pode transportar desperdícios antigos e ignorar características específicas da plataforma.
Um sizing sólido começa por compreender a workload. É necessário saber quando ocorrem os picos, quanta memória é realmente utilizada, qual o padrão de leitura e escrita, quanto tráfego atravessa a rede e que margem de crescimento deve ser mantida. O objetivo não é prever tudo com perfeição, mas formular uma hipótese tecnicamente sustentada e validá-la com métricas reais.

2. O que o Tamanho de uma Azure VM Realmente Define

Número de vCPUs e arquitetura do processador.
Quantidade de memória RAM e rácio GiB por vCPU.
Presença e capacidade de armazenamento temporário local.
Número máximo de discos de dados que podem ser anexados.
Limites agregados de IOPS e throughput para armazenamento remoto.
Quantidade máxima de interfaces de rede e desempenho de rede esperado.
Suporte para capacidades específicas, como Premium SSD, Ultra Disk, GPU, InfiniBand, computação confidencial ou nested virtualization.

Importante
O nome da família indica a finalidade geral, mas a validação final deve ser feita no tamanho específico e na região de implementação. Gerações e variantes da mesma família podem ter limites diferentes.

3. O Quatro Pilares do VM Sizing
3.1 vCPU: Capacidade de Processamento e Paralelismo

A vCPU representa uma unidade de processamento virtual atribuída à VM. O número necessário depende da concorrência, do perfil da aplicação, da eficiência do código, da frequência do processador e da capacidade da workload para executar tarefas em paralelo.

CPU média e percentis elevados durante períodos representativos.
Duração dos picos e impacto no tempo de resposta.
Comprimento das filas de processamento.
Capacidade da aplicação para utilizar vários cores.
Restrições de licenciamento por core, especialmente em produtos empresariais.

Uma utilização elevada e sustentada pode justificar scale-up ou scale-out. Contudo, aumentar vCPU não resolve espera de disco, paginação, contenção interna da aplicação ou saturação de rede.

3.2 Memória: Cache, Working Set e Paginação

A memória permite manter dados e processos ativos sem recorrer continuamente ao armazenamento. Bases de dados, caches distribuídas, sistemas ERP, motores de pesquisa e plataformas analíticas são particularmente sensíveis à RAM. Uma VM com CPU disponível pode continuar lenta quando o sistema

Memória disponível e memória comprometida.
Working set dos processos principais.
Page faults e utilização do pagefile ou swap.
Crescimento do dataset e necessidade de cache.
Reserva para sistema operativo, agentes e mecanismos de segurança.

3.3 IOPS: Quantidade de Operações por Segundo

IOPS, ou Input/Output Operations Per Second, mede a quantidade de operações de leitura e escrita executadas por segundo. É particularmente relevante para workloads transacionais que realizam muitas operações pequenas, como bases de dados OLTP, sistemas financeiros e aplicações ERP.
O valor de IOPS isolado não descreve toda a workload. O tamanho médio das operações, a proporção entre leitura e escrita, a aleatoriedade dos acessos e a latência observada devem ser analisados em conjunto.

3.4 Throughput: Volume de Dados Transferido

Throughput mede o volume de dados transferido por unidade de tempo, normalmente em MB/s. Backups, restore, ETL, cópias de grandes ficheiros e analytics sequencial podem consumir muito throughput sem gerar uma quantidade extraordinária de IOPS.

4. O Princípio do Menor Limite

O desempenho entregue corresponde ao menor limite aplicável em toda a cadeia: aplicação, sistema operativo, controlador, VM, discos e rede. Por isso, a soma teórica dos discos não garante que a VM consiga entregar o mesmo resultado.

Regra prática
Compare sempre os limites do disco com os limites agregados do tamanho da VM. Para cada métrica, considere o valor mais baixo como teto operacional.

5. Cached e Uncached: Porque a Diferença Importa

O acesso a discos remotos pode beneficiar da cache do host, conforme o tipo de disco, a configuração de caching e o padrão de I/O. A cache pode reduzir latência e tráfego ao armazenamento remoto em cenários apropriados, mas não deve ser tratada como uma garantia universal de desempenho.

Para bases de dados, siga sempre as recomendações específicas do fabricante para discos de dados e logs. Nunca altere caching em produção sem testes, plano de reversão e validação de consistência.

6. Famílias de VM e Perfil de Dimensionamento

6.1 Série B: Compreender Créditos de CPU

As VMs burstable destinam-se a workloads com baixa utilização média e picos ocasionais. Quando a VM trabalha abaixo da baseline, acumula créditos; quando ultrapassa essa baseline, consome-os. Após o esgotamento, o desempenho regressa ao nível base. Por isso, a série B não deve ser escolhida apenas porque apresenta o número desejado de vCPUs a um preço inferior.

6.2 Séries D, E e F: Escolher o Rácio Correto

As famílias D, E e F representam três padrões recorrentes: equilíbrio, memória e computação. A escolha deve partir do rácio entre CPU e RAM observado na aplicação, e não apenas do total absoluto de recursos.

6.3 Séries L, M, N e H: Requisitos Especializados

As famílias especializadas justificam-se quando a workload possui um requisito dominante que uma família general purpose não satisfaz eficientemente. L privilegia armazenamento local e I/O; M oferece memória em grande escala; N acrescenta GPU; H destina-se a HPC. Nestes casos, a compatibilidade de software, a persistência dos dados, a topologia de rede e a disponibilidade regional tornam-se parte do sizing.

7. Limites de Rede Também Fazem parte do Sizing

Cada tamanho possui capacidades de rede próprias, incluindo número de NICs e desempenho de rede esperado. Uma aplicação distribuída pode apresentar CPU e disco saudáveis e, ainda assim, sofrer latência, retransmissões ou degradação durante picos de tráfego.

Bytes enviados e recebidos por segundo.
Padrões east-west entre componentes da aplicação.
Fluxos simultâneos e duração das ligações.
Latência e retransmissões.
Necessidade de Accelerated Networking e compatibilidade do sistema operativo.

8. Metodologia Prática de Sizing

Passo 1: Classificar a Workload

Intermitente ou sustentada.
Stateless ou stateful.
Compute-intensive, memory-intensive, storage-intensive ou network-intensive.
Escalável horizontalmente ou dependente de scale-up.
Sensível a latência, perda de desempenho ou janelas de manutenção.

Passo 2: Recolher uma Baseline Representativa

Recolha dados que cubram períodos normais, picos, fechos mensais, backups, batch e outras janelas relevantes. Utilize percentis e duração de picos, não apenas médias, porque uma média confortável pode esconder eventos que afetam diretamente o negócio.

Passo 3: Converter Métricas em Requisitos

Passo 4: Selecionar Família, Geração e Tamanho

Escolha primeiro o perfil de família, depois a geração e finalmente o tamanho. Compare pelo menos duas alternativas, considerando desempenho, disponibilidade na região, quota, compatibilidade de discos, capacidades de rede e custo total da solução.

Passo 5: Validar com teste Representativo

Execute testes com dados, concorrência e padrões semelhantes aos de produção. Valide não apenas o valor máximo, mas a estabilidade, a latência e o comportamento durante picos. Documente a hipótese de sizing, os resultados e os critérios de aceitação.

Passo 6: Monitorizar e Aplicar Right-Sizing Contínuo

Depois do deployment, utilize Azure Monitor, VM Insights e Azure Advisor para rever tendências e recomendações. O sizing deve acompanhar alterações na aplicação, no volume de utilizadores, nos dados e nas gerações de hardware disponíveis.

9. Caso Prático: SQL Server Empresarial

Considere uma base de dados com 8 vCPUs, working set de aproximadamente 55 GiB, necessidade de 20.000 IOPS durante picos e tráfego sequencial significativo em operações de manutenção. Uma escolha baseada apenas em vCPU pode conduzir a uma D-series com memória insuficiente ou envelope de armazenamento inadequado

Resultado esperado
A decisão final pode exigir uma E-series maior, múltiplos discos agregados ou um tipo de disco diferente. O ponto central é que o SKU deve resultar da medição completa, e não de uma preferência genérica por uma família.

10. Checklist Antes de Aprovar o SKU

A família corresponde ao recurso dominante da workload.
A geração está disponível na região e zona pretendidas.
A subscrição possui quota suficiente para a família.
vCPU e RAM incluem margem operacional justificada.
IOPS e throughput dos discos estão dentro do limite agregado da VM.
O número máximo de discos e NICs é suficiente.
O caching está alinhado com as recomendações da aplicação.
Os requisitos de rede e Accelerated Networking foram validados.
Foram consideradas licenças, reservas, Azure Hybrid Benefit e operação.
Existe monitorização, alerta e plano de right-sizing.

11. Erros Comuns a Evitar

Escolher a VM apenas pela quantidade de vCPUs.
Assumir que um disco com muitos IOPS entregará sempre esse valor.
Somar o desempenho dos discos sem verificar o limite agregado da VM.
Confundir armazenamento temporário local com armazenamento persistente.
Utilizar série B para CPU elevada e sustentada.
Ignorar throughput e analisar apenas IOPS.
Ignorar rede, NICs, quotas e disponibilidade regional.
Migrar servidores on-premises numa relação 1:1 sem assessment.
Sobredimensionar permanentemente para acomodar um pico raro.
Manter o tamanho inicial sem revisão baseada em métricas.

12. Boas Práticas Operacionais

Registe a hipótese de sizing e os requisitos que justificaram a escolha.
Defina métricas, alertas e limites aceitáveis antes da entrada em produção.
Teste picos, tarefas de manutenção e falhas, não apenas operação normal.
Considere scale-out para aplicações stateless e scale-up para componentes que o exijam.
Reavalie após alterações de versão, crescimento de dados ou mudança no padrão de utilização.
Compare gerações mais recentes quando disponíveis, sem assumir equivalência automática.
Distinga otimização de desempenho de otimização de custos e encontre um equilíbrio explícito.

Como conclusão, dimensionar uma Azure VM exige tratar computação, memória, armazenamento e rede como um sistema único. Uma decisão baseada apenas em vCPU e RAM pode parecer correta no portal e falhar quando a aplicação atinge o limite de IOPS, throughput ou largura de banda do tamanho selecionado. A abordagem recomendada é simples e disciplinada: medir a workload, identificar o recurso dominante, escolher a família adequada, verificar todos os limites do SKU, testar com carga representativa e rever continuamente a decisão. Este método reduz throttling, evita desperdício e cria uma infraestrutura mais previsível.

Para leitura adicional consulte os links abaixo:

Leave a Comment Cancel Reply