Tengo una pregunta sobre mi laboratorio de pruebas. Es más comprender el concepto que aplicarlo en la producción:
Tengo un ESXi con algunas máquinas virtuales Linux/Windows configuradas y me gustaría usar el convertidor VMWare para crear copias de seguridad.
Para acelerar el proceso, decidí crear una máquina virtual Windows en el mismo host ESXi donde instalé Windows 7 y VMWare Converter.
El Host tiene una tarjeta gigabit pero actualmente está conectada a un puerto FD de 100 Mb. Windows 7 ve una tarjeta de 1 GB conectada.
Cuando hago la copia de seguridad usando el convertidor VMWare, especifico la IP del host como origen y destino, por lo que pensé que la copia podría ser más rápida que usar mi computadora portátil a través de la red.
Bueno, para abreviar: obtengo un rendimiento terrible (4 Mb/seg). Estoy un poco confundido con esto porque a pesar de que el host está ejecutando una comunicación de 100 Mb entre las máquinas virtuales y los hosts no debería (corríjame si me equivoco) tener ninguna limitación.
Modifiqué Windows 7 para optimizar el rendimiento de la red, pero obtuve solo una pequeña mejora. Todavía necesito 4 horas para hacer una copia de seguridad de una máquina virtual (delgada) de 50 Gb.
Además, quería preguntar: ¿Ayudaría el marco jumbo en esto? Sé que el marco jumbo debe ser compatible de extremo a extremo, y el conmutador de red donde está conectado actualmente el host no lo admite, pero me preguntaba:
1) ¿El host ESXi admite tramas gigantes?
2) ¿Puedo habilitarlo de alguna manera?
3) Si lo hago, supongo que la transferencia masiva entre las máquinas virtuales y el host mejoraría, pero ¿afectaría esto la comunicación que pasa a través del conmutador real, ya que no funciona como jumbo?
Gracias por leer
Respuesta1
Las tramas gigantes pueden marcar alguna diferencia, pero sus problemas de rendimiento indican un problema mucho más grave. Puede habilitar tramas Jumbo en ESXi, pero requiere el uso de las herramientas de línea de comandos vCLI; puede encontrar instrucciones específicas en esteDocumento de configuración de VMware ESXi.
Hay algunas causas posibles.
Es posible que sus datos entren y salgan del host ESXi; en ese caso, Converter copiaría los datos desde la máquina virtual en el host ESXi a la interfaz de administración a través de su red física. Dado que es un enlace ascendente de 100 Megabits, todavía espero que obtengas un par de Megabytes/seg en lugar de los 4 Megabits/seg que informas.
Es posible que las NIC de su host ESX en realidad no estén negociando correctamente la configuración de 100 Mbps/Full dúplex con el conmutador; asegúrese de que tanto el conmutador como la configuración de pNIC en su host ESXi estén configurados correctamente.
El convertidor no es muy eficiente en términos de rendimiento, pero si está utilizando la copia de disco basada en bloques (en lugar de a nivel de archivo), está bien (la velocidad de transferencia será >50% del ancho de banda máximo del enlace; digamos 4 megas/seg en una red de 100 Mbps). red, 40Meg/seg en GigE). Si su copia utiliza copia a nivel de archivo, las cosas serán mucho más lentas.
Toda esta actividad supone una buena cantidad de carga adicional en el subsistema de disco en el que están almacenadas sus máquinas virtuales. Si está ejecutando todo esto en un almacenamiento bastante lento (por ejemplo, un puñado de unidades SATA en RAID 5), entonces es posible que el disco esté fallando, pero para una configuración de almacenamiento saludable, este tipo de cosas no deberían ser estresantes.
Sin embargo, creo que el problema está en su red virtual; suponiendo que así sea, debe considerar lo siguiente:
Si su puerto de administración ESXi está en el mismo conmutador virtual que el grupo de puertos de red de producción de su VM, entonces el tráfico debería regresar internamente dentro del conmutador virtual. Si eso no sucede, comenzaría a verificar si las VLAN están configuradas en los puertos/grupos de puertos o verificaría si su dirección IP está causando que el tráfico piense que tiene que salir del conmutador antes de regresar (por ejemplo, si tiene la opción Management puerto en una subred diferente a la red VM y dependen de un enrutador externo para permitirles comunicarse). Si sospecha que su red no está haciendo lo anterior correctamente, puede colocar las máquinas virtuales de origen y de destino en la misma subred que el puerto de administración y conectarlas a un grupo de puertos de máquinas virtuales en el mismo vSwitch que el puerto de administración. Entonces debería obtener el tráfico entre los distintos sistemas (la fuente, la máquina virtual del convertidor y el host ESX) permanezca dentro de los límites del vSwitch. Mueva los grupos de puertos de VM en lugar de alterar el puerto de administración; si comete un error con eso, tendrá que volver a la consola física de ESXi para arreglar las cosas y es mejor evitar correr riesgos con eso.
También cierre todo lo que pueda antes de comenzar en caso de que algo como un proceso de copia de seguridad esté acaparando todo el ancho de banda de la red del puerto de administración, etc.
Respuesta2
Desactivar el cifrado SSL es una forma de solucionar este problema. Así es como se hace:
Open the converter-worker.xml configuration file. It is located in
"%ALLUSERSPROFILE%\VMware\VMware vCenter Converter Standalone"
folder for Windows Vista or newer or in
"%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Converter Standalone"
for older Windows versions.
Set the key Config/nfc/useSsl to false and save the configuration file.
Restart "VMware vCenter Converter Standalone Worker" service.
Es decir, debería verse así:
...
<nfc>
<readTimeoutMs>120000</readTimeoutMs>
<useSsl>false</useSsl>
...
"Reinicie el servicio "VMware vCenter Converter Standalone Worker".