He estado intentando descubrir por qué mis copias de seguridad han sido lentas usando ghettoVCB desde el host ESXI.
Actualmente estoy haciendo una copia de seguridad de mis objetos virtuales usando ghettoVCB en un recurso compartido NFS en TrueNAS desde el sistema operativo host.
Cuando copio archivos al recurso compartido NFS desde un invitado (Ubuntu 20.04) en la máquina ESXI, obtengo aproximadamente 257 MB/s (lo cual es correcto ya que tengo un canal dedicado de 2,5 GB entre el NAS y ESXI)
su@test:/mnt/guest$ time sh -c "dd if=/dev/zero of=test bs=1MB count=1024 && sync"
1024+0 records in
1024+0 records out
1024000000 bytes (1.0 GB, 977 MiB) copied, 3.98153 s, 257 MB/s
real 0m4.470s
user 0m0.002s
sys 0m0.619s
Guest NFS Mount Options:
rw, relatime, vers=4.2,
rsize=1048576, wsize=1048576,
namlen=255, hard, proto=tcp, timeo=600,
retrans=2, sec=sys, local_lock=none,
Cuando intento copiar al mismo recurso compartido NFS desde el host ESXI, el rendimiento es mucho menor, aproximadamente 45 MB/s:
/vmfs/volumes/9043e582-0376fe3e] time sh -c "dd if=/dev/zero of=./test bs=1MB count=1024 && sync"
1024+0 records in
1024+0 records out
real 0m 22.70s
user 0m 0.00s
sys 0m 0.00s
ESXI NFS Mount Options
Cant seem to find a way to see the mount options ESXI uses?
Una cosa que sí noté es que desactivar la sincronización en el recurso compartido de datos ZFS en el servidor aceleró las escrituras en ESXI a 146 MB/s. Sigue siendo mucho más bajo que el sistema operativo invitado.
Mi suposición es que ESXI está siendo súper seguro y garantiza que todo esté sincronizado al 100%. ¿Alguien sabe si este es el caso y tiene algún consejo para mejorar el rendimiento de la copia de seguridad?
Respuesta1
Lo que ves es absolutamente normal y no se puede arreglar TAL CUAL. VMware ESXi “por diseño” no tiene caché de disco a diferencia del sistema operativo invitado dentro de una VM, ¡ese realmente lo tiene! Entonces, cuando copia su archivo (que es una prueba fraudulenta en sí misma, debería usar puntos de referencia más sofisticados) desde dentro de una máquina virtual, está saturando su red ya que su lectura secuencial canalizada es más rápida que la red misma, pero el host ESXi tiene que leer. los datos (lentos, no hay lectura anticipada) en búferes de memoria de red/almacenamiento compartido con mmap(), inician la escritura NFS sin estado, leen el disco nuevamente y continúan en el bucle. Si inicia WireShark, verá que el tráfico de transmisión de la máquina virtual invitada es constante y el sistema operativo host lo hace con una especie de picos en la transmisión.
Como solución alternativa, es posible que desee obtener un controlador RAID de almacenamiento en caché con una memoria integrada potente o agregar un segundo nodo, crear un clúster y configurar vSAN (el precio de VMUG es bastante asequible para vSphere+vSAN). VMware vSAN almacenará en caché los discos locales a su nivel, por debajo de VMFS, por lo que saturará sus 2,5 Gb nuevamente.
Respuesta2
Como solución alternativa, es posible que desee obtener un controlador RAID de almacenamiento en caché con una memoria integrada potente o agregar un segundo nodo, crear un clúster y configurar vSAN (el precio de VMUG es bastante asequible para vSphere+vSAN). VMware vSAN almacenará en caché los discos locales a su nivel, por debajo de VMFS, por lo que saturará sus 2,5 Gb nuevamente.
Esa es una opción que vale la pena. Alternativamente, espere Starwind VSAN, que funciona a nivel de bloque y debería brindarle un mejor rendimiento. Admite una incursión mdamd que también podría tener sentido probar.