¿Cada VM de Hyper‑V “se come” solo una décima parte de tu 10 GbE al replicar? No es un límite oficial: suele ser consecuencia de pocos flujos TCP por VM, compresión por defecto y cuellos de CPU o de aplicación de cambios en el destino. A continuación tienes un plan práctico, probado y escalable para recuperar el caudal.
Escenario típico y síntomas
- Conectividad de diez gigabits: una o dos máquinas virtuales replicando rondan entre uno y dos gigabits por segundo, aunque la red esté ociosa.
- Al añadir más máquinas virtuales, el agregado sube (dos a cuatro gigabits por segundo, y así sucesivamente) pero ninguna VM individual llena el enlace.
- Copias SMB entre hosts alcanzan siete gigabits por segundo o más, lo que sugiere que discos y CPU son capaces.
- En enlaces de un gigabit, cada VM replica alrededor de cien megabits por segundo, manteniendo la misma proporción.
Lo que realmente ocurre
No existe un “límite del diez por ciento por VM” documentado en Hyper‑V Replica. La réplica usa un número reducido de flujos TCP por máquina virtual y, por defecto, aplica compresión. En hosts modernos con diez gigabits, esa combinación puede quedar limitada por la CPU y por la naturaleza de los flujos largos con ventana de congestión en crecimiento paulatino. El resultado: con pocos flujos y compresión activa, es habitual ver uno o dos gigabits sostenidos por VM aunque la red pueda más. Cuando varias VMs replican en paralelo, los flujos agregados sí consiguen llenar mejor el enlace.
Objetivo y estrategia
La meta no es “desbloquear un tope oculto”, sino aumentar el paralelismo efectivo y reducir trabajo por byte para que el motor de réplica aproveche el enlace. Para ello, actúa en tres frentes: configuración por VM (compresión), concurrencia de transferencias y salud de la ruta de datos (QoS, pila TCP y NIC), sin olvidar el subsistema de almacenamiento del servidor réplica.
Solución recomendada, de menor a mayor intrusividad
Prueba con compresión desactivada en una o dos VMs
La compresión ahorra red pero consume CPU. En una LAN de baja latencia con diez gigabits, desactivarla temporalmente en una o dos VMs suele incrementar el rendimiento por flujo.
# Comprobar si la compresión está activada por VM
Get-VMReplication -VMName 'VM01' | Select-Object VMName, CompressionEnabled
Desactivar compresión en la VM de prueba
Set-VMReplication -VMName 'VM01' -CompressionEnabled:\$false
(Tras medir, vuelve a activarla si no mejora o si replicas por WAN)
Set-VMReplication -VMName 'VM01' -CompressionEnabled:\$true Cómo medir el efecto: observa el caudal de la interfaz física y la ocupación de CPU del servicio de administración de Hyper‑V durante la ventana de réplica. Si la descompresión del lado destino no es el cuello, deberías notar un aumento claro.
Aumenta el paralelismo entre VMs con transferencias activas
De fábrica, el servicio de virtualización limita el número de transferencias simultáneas. Elevarlo permite que más VMs empujen datos en paralelo y, por suma, llenen el enlace.
# Aumentar el número máximo de transferencias activas
$rk = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication'
New-Item -Path $rk -Force | Out-Null
New-ItemProperty -Path $rk -Name 'MaximumActiveTransfers' -PropertyType DWord -Value 8 -Force | Out-Null
Reiniciar el servicio de administración de Hyper‑V para aplicar
Restart-Service vmms -Force Guía rápida: empieza con ocho y evalúa. Si tu host replica pocas VMs, este ajuste no tendrá impacto; si replicas muchas, suele marcar la diferencia.
Descarta QoS o límites accidentales
Una directiva de Calidad de Servicio mal aplicada puede estrangular HTTP/HTTPS usado por la réplica del servidor. Comprueba y, si procede, retira políticas que apliquen límites de tasa o DSCP que deriven en colas lentas.
# Revisión de políticas de QoS en el host
Get-NetQosPolicy | Format-Table -Auto
Eliminar una política no deseada
Remove-NetQosPolicy -Name 'Throttle-HVR'
Optimiza la ruta de red del host
Las siguientes características impactan el rendimiento por flujo y la eficiencia de CPU:
- RSC en el vSwitch: puede reducir la sobrecarga de CPU agregando segmentos.
- RSS y VMQ: evitan que un solo núcleo maneje toda la cola de red.
- Offloads adecuados en la NIC física.
# RSC en el vSwitch
Get-VMSwitch | Select-Object Name, EnableSoftwareRsc
Activar o desactivar para probar su impacto
Set-VMSwitch -Name 'vSwitch10G' -EnableSoftwareRsc $true
RSC en la NIC física
Get-NetAdapterRsc
Set-NetAdapterRsc -Name 'NIC10G' -IPv4 \$true -IPv6 \$true
RSS y VMQ
Get-NetAdapterRss
Enable-NetAdapterRss -Name 'NIC10G'
Get-NetAdapterVmq
Enable-NetAdapterVmq -Name 'NIC10G'
Consejo: realiza cambios de uno en uno y mide cinco a diez minutos de carga real: el efecto de RSC y RSS depende de drivers y del patrón de tráfico del entorno.
Verifica que el cuello no esté en el almacenamiento del destino
Mientras se aplican los cambios en el servidor réplica, el subsistema de discos puede convertirse en el limitante. Observa latencia y cola de disco en el destino durante la recepción de logs. Si se satura, considera ajustar los parámetros de aplicación de cambios o distribuir los discos de réplica en más spindles/SSD.
# Indicadores rápidos del lado destino
Get-PhysicalDisk | Sort-Object -Property CurrentQueueLength -Descending | Select-Object -First 10 FriendlyName, MediaType, Size, HealthStatus, CurrentQueueLength
Contadores útiles (ejecútalos durante la réplica)
- Observar "LogicalDisk()\Avg. Disk sec/Write" y "PhysicalDisk()\Disk Writes/sec"
Claves avanzadas (solo si detectas saturación al aplicar logs): existen parámetros de control de paralelismo y de cola durante la aplicación de cambios, como el límite concurrente por VHD y el “throttle” de escritura de bloques. Úsalos con cautela y siempre tras confirmar que el disco del destino es el cuello.
Cuando necesitas exprimir el enlace de diez gigabits
- Multiplica la concurrencia “natural”: inicia o programa inicializaciones y resincronizaciones de varias VMs a la vez para sumar caudal.
- Pre‑seed los VHDX en el destino para minimizar la transferencia inicial por red y concentrarte en el delta.
- Valora Windows Storage Replica si el requisito es caudal sostenido máximo y control fino del ancho de banda. Al replicar a nivel de volumen sobre SMB 3 aprovecha Multichannel y, si lo tienes, RDMA. Además, permite fijar límites explícitos en la asociación.
# Ejemplo orientativo: asociación de Storage Replica con límite de caudal
(los valores de -Bandwidth se especifican en bits por segundo)
New-SRPartnership `
-SourceComputerName SRV1 -SourceRGName RG01 -SourceVolumeName D: `
-DestinationComputerName SRV2 -DestinationRGName RG02 -DestinationVolumeName E: `
-Bandwidth 7500000000
Plan de prueba A/B reproducible
- Estabiliza el entorno: elige dos VMs similares y programa su ventana de réplica para que no coincida con otras cargas pesadas.
- Captura la línea base: registra caudal por interfaz, uso de CPU y latencia de disco en origen y destino; anota la latencia de red real.
- Desactiva compresión en una VM y deja la otra como control.
- Repite con diferentes valores de transferencias activas (por ejemplo, cinco, ocho y doce) y guarda los resultados.
- Prueba con RSC activado y desactivado en el vSwitch, sin tocar nada más entre pruebas.
- Valida que no exista QoS limitando HTTP/HTTPS y que no haya contención de IRQ/CPU (RSS/VMQ).
- Documenta el mejor conjunto y aplícalo de forma controlada al resto del entorno.
Matriz de diagnóstico rápido
| Síntoma | Causa probable | Indicadores | Acción recomendada |
|---|---|---|---|
| Una VM no supera uno o dos gigabits por segundo en diez gigabits | Pocos flujos TCP y compresión consumiendo CPU | CPU del host alta durante la réplica, RTT bajo | Probar réplica sin compresión en esa VM; aumentar concurrencia entre VMs |
| Varias VMs suman caudal alto pero cada una por separado rinde poco | Limitación por flujo individual | Flujos 80/443 escasos y estables | Incrementar MaximumActiveTransfers para paralelizar |
| Caudal bajo con CPU y red ociosas | QoS o shaping no intencional en el host o en la red | Políticas de QoS definidas o colas con descarte | Eliminar o ajustar la política; verificar colas del switch o firewall |
| Caudal irregular con picos de latencia en el destino | Discos del servidor réplica saturados al aplicar cambios | Cola de disco elevada, latencias de escritura altas | Optimizar almacenamiento, aumentar paralelismo de aplicación solo si procede |
| Enlaces de un gigabit clavados en cien megabits por VM | Mismo patrón de limitación por flujo | Una VM ≈ cien megabits; varias VMs llenan el gigabit | Sumar VMs en paralelo y/o desactivar compresión selectivamente |
Buenas prácticas de red para réplica
- Mantén auto‑tuning TCP activo y evita forzar parámetros de ventana o proveedores de congestión no probados.
- Evita colocalizar el tráfico de réplica con vNICs que usen políticas de mínimo garantizado o límites de Egress en el vSwitch.
- Separa lógicamente la red de réplica en VLAN o interfaz dedicada cuando el volumen sea alto; simplifica así la observabilidad y el control.
- Si atraviesas firewalls entre sitios, confirma que inspecciones profundas no añadan latencia o shaping.
Checklist operativo
- Medir antes y después con el mismo patrón de carga.
- Desactivar compresión en una o dos VMs de prueba y evaluar.
- Subir concurrencia de transferencias activas y reiniciar el servicio de Hyper‑V.
- Revisar y limpiar QoS accidental.
- Verificar RSC, RSS y VMQ en NIC y vSwitch.
- Auditar el almacenamiento del destino mientras se aplican cambios.
- Escalar con pre‑seed y, si necesitas caudal sostenido máximo y control fino, considerar Storage Replica.
Preguntas frecuentes
¿Hay un tope “duro” por VM? No. Lo que ves es la combinación de pocos flujos TCP, compresión por defecto y límites prácticos por hilo/flujo.
¿Conviene desactivar siempre la compresión? No. En WAN o enlaces de menor capacidad suele ser clave para no saturar la línea. Desactívala selectivamente en LAN rápidas si la CPU es el cuello.
¿Elevar el número de transferencias activas perjudica la estabilidad? Si ajustas de forma incremental y mides, no. Evita valores exagerados en hosts con muchos discos lentos o CPU limitadas.
¿Por qué SMB copia más rápido? SMB 3 emplea múltiples flujos y, con Multichannel y RDMA, aprovecha mejor la red que un puñado de flujos HTTP/HTTPS.
¿Puedo limitar o reservar ancho de banda? Con Hyper‑V Replica puedes aplicar QoS explícitamente si lo necesitas; con Storage Replica, además, puedes fijar un máximo por asociación.
Apéndice de comandos útiles
Visibilidad y control de réplica
# Estado de la réplica por VM
Get-VMReplication | Select-Object VMName, State, Health, CompressionEnabled
Forzar resincronización (planificada)
Start-VMResynchronizeReplication -VMName 'VM01' -ResynchronizeStartTime (Get-Date).AddMinutes(5)
Inicialización de réplica (cuando acabas de habilitarla)
Start-VMInitialReplication -VMName 'VM01' QoS y red
# Políticas de QoS
Get-NetQosPolicy | Format-Table -Auto
Clases y mapeos DSCP
Get-NetQosTrafficClass
Get-NetQosDcbxSetting
Conexiones TCP en uso por HTTP/HTTPS (visión rápida)
Get-NetTCPConnection -State Established | Where-Object { \$.LocalPort -in 80,443 -or \$.RemotePort -in 80,443 } |
Group-Object -Property LocalAddress,RemoteAddress | Select-Object Count, Name RSC, RSS y VMQ
# RSC en vSwitch y NIC
Get-VMSwitch | Select-Object Name, EnableSoftwareRsc
Get-NetAdapterRsc
RSS y VMQ
Get-NetAdapterRss
Get-NetAdapterVmq Concurrencia y servicio
# Ver valor actual de MaximumActiveTransfers
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication' `
-Name 'MaximumActiveTransfers' -ErrorAction SilentlyContinue
Ajuste recomendado por pasos
New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication' \`
-Name 'MaximumActiveTransfers' -PropertyType DWord -Value 8 -Force | Out-Null
Restart-Service vmms -Force Tabla de parámetros y cuándo tocarlos
| Parámetro | Dónde se aplica | Valor base | Cuándo ajustarlo | Efecto esperado |
|---|---|---|---|---|
| Compresión de réplica | Por máquina virtual | Activada | LAN de baja latencia con diez gigabits y CPU ociosa | Más caudal por VM a costa de consumir más red |
| Transferencias activas | Registro del servicio de virtualización | Tres | Cuando replicas varias VMs y el enlace no se llena | Mayor paralelismo agregado y mejor ocupación del enlace |
| QoS de réplica | Directiva de host o red | Ninguna | Solo si necesitas limitar conscientemente | Control explícito de uso de ancho de banda |
| RSC, RSS, VMQ | vSwitch y NIC del host | Depende del driver | Cuando el uso de CPU es alto por paquete o un núcleo se satura | Mejor rendimiento por flujo y menor carga de CPU |
| Parámetros de aplicación de cambios | Servidor réplica | Equilibrados | Si el disco del destino se satura al aplicar logs | Menos latencia de escritura y caudal más estable |
| Storage Replica | Nivel de volumen (SMB 3) | No aplica | Si necesitas caudal sostenido máximo o RDMA | Mejor escalado y control fino de ancho de banda |
Errores comunes que conviene evitar
- Aplicar muchos cambios a la vez (RSC, RSS, VMQ, QoS y registros) sin medir entre pasos; dificulta aislar la causa.
- Desactivar compresión en WAN o enlaces estrechos, provocando congestión y colas elevadas.
- Elevar en exceso el paralelismo cuando el destino escribe en un único disco mecánico; el cuello vuelve a aparecer, ahora en el almacenamiento.
- Asumir que la cifra de SMB es directamente comparable: el patrón de acceso y el número de flujos son distintos.
Resumen accionable
- Prueba la réplica sin compresión en una o dos VMs y mide el caudal.
- Aumenta el valor de transferencias activas para paralelizar cuando tengas varias VMs.
- Comprueba que no exista QoS limitando el tráfico de réplica.
- Revisa RSC, RSS y VMQ en vSwitch y NIC del host.
- Valida que el almacenamiento del servidor réplica no sea el cuello.
- Si sigues sin llenar el enlace y lo necesitas, evalúa Storage Replica para escenarios de caudal sostenido y control fino.
Conclusión: el aparente “límite del diez por ciento” es un efecto colateral de cómo replica una VM individual (pocos flujos y trabajo adicional por byte). Con pequeños cambios —desactivar compresión selectivamente, aumentar la concurrencia y afinar la ruta de red— es posible escalar el caudal hasta niveles coherentes con un enlace de diez gigabits, manteniendo la estabilidad y sin sacrificar la recuperabilidad.
Implementa los pasos en el orden propuesto, registra métricas antes y después, y documenta el conjunto ganador para tu plataforma. La mejora suele ser inmediata y sostenida.