Está a ver cada VM do Hyper‑V Replica usar apenas ~10% da rede enquanto cópias de ficheiros batem vários Gb/s? Boa notícia: isto costuma ser comportamento normal do desenho da réplica por VM e resolve‑se com afinação de paralelismo, validação de QoS e alguns cuidados de rede e storage. Abaixo vai o guia completo.
Visão geral do cenário
Em hosts Windows Server 2022 com ligações de 10 GbE, é frequente observar que um único par de VM em Hyper‑V Replica consome apenas cerca de 1 Gb/s, enquanto a soma de duas ou três VMs a replicar em simultâneo escala para 2–4 Gb/s. Ao mesmo tempo, uma cópia de ficheiros entre os mesmos hosts atinge 6–8 Gb/s, o que sugere que a rede e os discos estão saudáveis. Essa diferença aparece porque a réplica trabalha por VM e, por predefinição, o host limita o número de transferências paralelas ativas. Consequência: um único fluxo TCP raramente satura um link de 10 GbE, mas vários fluxos paralelos costumam saturar.
O que realmente está a acontecer
- Sem “cap” fixo por VM: não existe um limite rígido de 10% por VM. O que existe é a dinâmica de um único fluxo de replicação por VM que, por natureza (latência de ida‑e‑volta, janelas TCP, offloads e comportamento de compressão), dificilmente esgota 10 GbE.
- Limite de paralelismo no host: o Hyper‑V Replica controla quantas transferências paralelas um host pode executar. O parâmetro de registo
MaximumActiveTransferstem predefinição conservadora (normalmente 3). Aumentar o paralelismo permite mais fluxos concorrentes e aproxima o débito agregado do limite físico da ligação. - Aplicação de alterações no destino: além de transferir blocos alterados, o destino precisa de os aplicar ao VHDX. Existem limites separados para o número de VHDs e de VMs aplicados em paralelo, o que pode tornar o apply o gargalo real.
Sinais de que o comportamento é “by design”
- A soma de várias VMs cresce quase linearmente até se aproximar dos 10 Gb/s.
- Cópias de ficheiros são muito mais rápidas porque usam múltiplos fluxos (p. ex., SMB Multichannel) e tiram partido de janelas TCP maiores, pré‑leitura e cache.
- Latência baixa, CPU do host folgada e contadores de backlog da réplica estáveis sugerem que não há um gargalo “duro”, apenas paralelismo insuficiente.
Passos práticos de resolução e afinação
Confirmar se não há QoS a estrangular a réplica
É comum existir QoS a limitar as portas usadas pela réplica (HTTP/80 ou HTTPS/443), aplicada por Group Policy ou por políticas locais.
# Listar políticas de QoS ativas
Get-NetQosPolicy
Se existir uma política que identifique as portas de réplica,
ajuste a largura de banda ou desative-a temporariamente para teste.
Com QoS involuntária ativa, cada VM parece “bater no teto” e não escala. Valide e documente qualquer alteração antes de prosseguir.
Aumentar o paralelismo de transferências
O objetivo é permitir mais transferências simultâneas a partir do host de origem, para que múltiplos fluxos TCP utilizem melhor o link. A chave de registo a ajustar é:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication\MaximumActiveTransfers
- Tipo:
DWORD - Predefinição: normalmente
3 - Recomendação inicial para 10 GbE em LAN:
6a8(evoluir consoante medições)
Exemplo em PowerShell (cria ou atualiza a entrada e reinicia o serviço do Hyper‑V):
# Executar em PowerShell elevado
$path = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication'
New-Item -Path $path -Force | Out-Null
New-ItemProperty -Path $path -Name 'MaximumActiveTransfers' -PropertyType DWord -Value 8 -Force | Out-Null
Reiniciar o serviço de gestão do Hyper‑V para aplicar
Restart-Service vmms -Force Após o ajuste, inicie duas ou mais replicações em paralelo e observe o débito agregado. Se a curva continuar a crescer com mais VMs, está no caminho certo.
Otimizar a aplicação dos logs no destino
Se a transferência parece ir bem mas a aplicação das alterações é lenta (ex.: backlog cresce no destino, disco fica com filas altas), ajuste os limites de aplicação. Estas chaves vivem, em geral, sob o mesmo ramo de Virtualization\Replication:
| Chave | Função | Predefinição | Sugestão inicial | Risco colateral |
|---|---|---|---|---|
ApplyVHDLimit | N.º de VHDs por VM aplicados em paralelo | Até 4 | Manter 4; reduzir se o storage for modesto | IOPS altos podem afetar outras cargas |
ApplyVMLimit | N.º de VMs da mesma origem aplicadas ao mesmo tempo | Conservador | Incrementar gradualmente | Pico de latência no destino |
ApplyChangeReplicaDiskThrottle | Profundidade de fila/IO na aplicação | Controlado pelo sistema | Aumentar com cautela | Saturação do subsistema de disco |
Boas práticas: altere um parâmetro de cada vez, meça com PerfMon e reverta se observar latências de disco persistentes ou aumento de tempos de resposta em VMs de produção.
Boas práticas de rede para tráfego de réplica
- Isolamento lógico ou físico: use vNICs/NICs dedicadas ou, ao mínimo, um vSwitch lógico dedicado para tráfego de réplica, evitando competir com SMB, tráfego de backup e produção.
- Offloads e filas: verifique RSS, VMQ, RSC e LSO. Atualize drivers e firmware. Em alguns cenários, desativar RSC no vSwitch melhora a latência (e por tabela o throughput efetivo da réplica).
# Estado da NIC e offloads principais
Get-NetAdapter | ft Name, Status, LinkSpeed
Get-NetAdapterRss
Get-NetAdapterRsc
Propriedades avançadas (p. ex., VMQ, Jumbo, etc.)
Get-NetAdapterAdvancedProperty -Name "Ethernet\*"
RSC no vSwitch
Get-VMSwitch | Select-Object Name, EnableSoftwareRsc
Para desativar RSC num vSwitch específico:
Set-VMSwitch -Name "vSwitch\_Replica" -EnableSoftwareRsc \$false
Se usar Jumbo Frames, garanta consistência end‑to‑end (vNIC, vSwitch, NIC física, rede interligada). Qualquer salto sem Jumbo anula o benefício e pode gerar fragmentação.
Validações de antivírus e EDR
Faça as exclusões recomendadas para Hyper‑V: processos vmms.exe, vmwp.exe, extensões .vhd/.vhdx e pastas onde residem as VMs. A análise em tempo real, sobretudo durante a replicação inicial, pode reduzir significativamente a taxa de transferência.
Estratégias para a replicação inicial
Para seeds grandes, evite depender de um único fluxo pela WAN/LAN. Use “Enviar cópia inicial usando média externa” (disco USB/SAN) ou “Usar VM existente no servidor de réplica”. Isto reduz a janela de sincronização inicial e livra a rede do pico de tráfego.
Quando precisa de mais débito por fluxo do que por VM
Se a exigência for esgotar 10/25/40 GbE com poucos objetos, considere Storage Replica, que replica a nível de volume via SMB, aproveitando SMB Multichannel e RDMA (se disponível). Em geral, Storage Replica escala melhor o throughput por fluxo do que Hyper‑V Replica, que é orientada a VMs e a ciclos de alteração.
Método rápido de diagnóstico e afinação
- Medir o teto real da rede: execute uma cópia de ficheiros grande entre os hosts de origem e destino (mesmo caminho físico/logical da réplica). Registe a taxa sustentada em GB/s.
- Verificar QoS: confirme se não há políticas a limitar portas 80/443 usadas pela réplica. Ajuste temporariamente para validação.
- Ajustar
MaximumActiveTransfers: teste com 6–8 em 10 GbE local. Reinicie ovmms. Observe o agregado com 2, 3 e 4 VMs. - Observar o destino: se a transferência voa mas o backlog cresce, afine
ApplyVHDLimiteApplyVMLimitgradualmente. - Rever offloads: alinhe RSS/VMQ/RSC/LSO e drivers. Em caso de dúvida, atualize primeiro; só depois desative funcionalidades.
- Aplicar exclusões de AV/EDR e repetir testes.
Parâmetros e onde encontrá‑los
| Parâmetro | Local no registo | Tipo | Predefinição típica | Quando alterar | Observações |
|---|---|---|---|---|---|
MaximumActiveTransfers | ...Virtualization\Replication | DWORD | 3 | Link ≥10 GbE; várias VMs a replicar | Aumentar em passos de 2; medir |
ApplyVHDLimit | ...Virtualization\Replication | DWORD | Até 4 | Destino com folga de IOPS | Risco de ruído no storage |
ApplyVMLimit | ...Virtualization\Replication | DWORD | Conservador | Backlog a crescer no destino | Elevar com cautela |
ApplyChangeReplicaDiskThrottle | ...Virtualization\Replication | DWORD | Automático | Quando o disco não é saturado | Controla profundidade de fila |
Checklist de comandos úteis
# QoS ativo?
Get-NetQosPolicy
Estado de tuning na NIC (amostra)
Get-NetAdapter | ft Name, Status, LinkSpeed
Get-NetAdapterRss
Get-NetAdapterRsc
Get-NetAdapterAdvancedProperty -Name "Ethernet\*"
vSwitch RSC (pode impactar latência/throughput)
Get-VMSwitch | Select-Object Name, EnableSoftwareRsc
Após ajustar MaximumActiveTransfers
Restart-Service vmms Configurações de réplica e segurança
- Protocolo: pode optar por HTTP com Kerberos ou HTTPS com certificados. Siga a política de segurança da sua organização; em ambientes internos bem autenticados, HTTP com Kerberos é comum e tem overhead menor de CPU do que TLS em hosts sem offload.
- Compressão: a compressão de tráfego de réplica reduz o volume transmitido, ótima para WANs. Em LANs de 10 GbE com CPU pressionada, teste com/sem compressão para ver qual dá maior débito efetivo.
- Frequência de replicação: em Windows Server 2022, a réplica pode operar em janelas curtas (p. ex., 30 s) ou mais longas (5/15 min). Janelas mais curtas aumentam o número de ciclos e metadados; janelas mais longas aumentam o tamanho de cada envio. Ajuste ao seu RPO e perfil de alterações.
Métricas para monitorizar
- PerfMon → Hyper‑V Replica: Bytes Sent/sec, Bytes Received/sec, Average Replication Latency, Backlog
- Disco: Avg. Disk sec/Read/Write no volume que acolhe os VHDX de destino
- Rede: Bytes Total/sec por NIC dedicada, pacotes descartados, TCP Retransmits/sec
- Eventos: registos Microsoft‑Windows‑Hyper‑V‑VMMS/Operational e Hyper‑V‑Worker para erros de aplicação
Erros de diagnóstico comuns
- Presumir gargalo de CPU porque um único fluxo não passa de ~1 Gb/s; na prática, é limitação normal de janela/latência.
- Ignorar QoS herdada: políticas antigas continuam a limitar portas 80/443.
- Basear‑se em Jumbo Frames sem confirmar caminho completo; inconsistência gera fragmentação e perda de desempenho.
- Aumentar agressivamente os limites de apply sem monitorizar storage, causando impacto nas VMs de produção.
Fluxo de decisão rápido
Se uma única VM usa ~10% do link → teste com duas e três VMs. Se a soma cresce, o problema é apenas paralelismo: aumente MaximumActiveTransfers e valide QoS. Se a soma não cresce, há outro limitador: QoS ativa, RSC/VMQ mal afinados, CPU saturada por compressão, ou apply do destino a atrasar.
Exemplos de scripts de apoio
Definir um valor de paralelismo baseado numa regra prática: dividir a largura de banda disponível pelo throughput medido com uma cópia de ficheiros grande entre os hosts (resultado inteiro, mínimo 3).
# Exemplo: se a cópia de ficheiros sustenta 7 Gb/s num link de 10 Gb/s,
podemos começar com 7 "unidades" de paralelismo.
\$throughputGbps = 7
\$maxTransfers = \[Math]::Max(3, \[Math]::Min(16, \[Math]::Floor(\$throughputGbps)))
\$path = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication'
New-Item -Path \$path -Force | Out-Null
New-ItemProperty -Path \$path -Name 'MaximumActiveTransfers' -PropertyType DWord -Value \$maxTransfers -Force | Out-Null
Restart-Service vmms -Force Quando considerar Storage Replica
Se o requisito funcional for maior débito por volume ou janelas de RPO muito curtas com poucos objetos, Storage Replica normalmente entrega melhor throughput graças a SMB Multichannel e RDMA, além de gestão de paralelismo a nível de volume. Mantenha Hyper‑V Replica onde a granularidade por VM, simplicidade e orquestração de failover por VM são mais relevantes.
Notas finais de operação
- Em WAN: seja conservador no aumento de paralelismo. Prefira QoS para proteger a largura de banda de produção. Teste sempre fora de horário crítico.
- Backups: a réplica não substitui backups. Garanta que a sua estratégia de cópias de segurança está em conformidade com RPO/RTO, mesmo após afinações.
- Documentação: registe valores e resultados de testes. Atualize runbooks de DR para refletir novas configurações.
Resumo prático
O padrão “uma VM ≈ 10% do link, várias VMs escalam” é coerente com a arquitetura do Hyper‑V Replica. Em redes de 10 GbE, o caminho rápido para usar melhor a largura de banda é: confirmar que não há QoS a estrangular, elevar com critério o MaximumActiveTransfers, otimizar a aplicação no destino quando necessário e seguir boas práticas de rede e de exclusões de antivírus. Para replicações iniciais pesadas, use mídia externa ou VMs pré‑semeadas. Quando o objetivo é throughput máximo por volume com poucos objetos, avalie Storage Replica. Com estes ajustes, é comum ver o agregado aproximar‑se muito do limite físico do link, mantendo RPOs consistentes e impacto mínimo nas cargas de produção.
Comandos‑úteis de bolso
# QoS ativo?
Get-NetQosPolicy
Estado de tuning na NIC (amostra)
Get-NetAdapter | ft Name, Status, LinkSpeed
Get-NetAdapterRss
Get-NetAdapterRsc
Get-NetAdapterAdvancedProperty -Name "Ethernet"
vSwitch RSC (pode impactar latência/throughput)
Get-VMSwitch | Select-Object Name, EnableSoftwareRsc
Após ajustar MaximumActiveTransfers
Restart-Service vmms Dica: escolha HTTP com Kerberos ou HTTPS com certificados para o tráfego de réplica segundo a política de segurança da sua rede; a opção é definida nas configurações de réplica do Hyper‑V.
Conclusão: não há um teto “mágico” de 10% por VM — há sim limites de paralelismo e características de transporte que fazem um único fluxo parecer tímido num link rápido. Ao abrir mais pistas paralelas e cuidar do apply, QoS, offloads e AV, a réplica deixa de “gotejar” e passa a fluir.