¿Alguien ha logrado una verdadera sincronización diferencial con rsync en ESXi?


11

Más tarde me regañó por el hecho de que estoy usando la consola de servicio para hacer cualquier cosa en ESXi ...

Tengo un binario rsync que funciona (v3.0.4) que puedo usar en ESXi 4.1U1. Tiendo a usar rsync sobre cp cuando copio máquinas virtuales o copias de seguridad de un almacén de datos local a otro almacén de datos local. He usado rsync para copiar datos de un cuadro de ESXi a otro, pero eso fue solo para archivos pequeños.

Ahora trato de hacer verdaderas sincronizaciones diferenciales de copias de seguridad tomadas a través de ghettoVCB entre mi máquina ESXi primaria y una secundaria. Pero incluso cuando hago esto localmente (un almacén de datos en otro almacén de datos en la misma máquina ESXi) parece que rsync copia los archivos en su totalidad. Tengo dos de VMDK totalmente 80GB de tamaño, y rsync todavía se lleva a cualquier lugar entre 1 y 2 horas, pero los de VMDK no están creciendo que tanto diaria.

A continuación se muestra el comando rsync que estoy ejecutando. Estoy copiando localmente porque finalmente estos archivos se copiarán en un almacén de datos creado a partir de un LUN en un sistema remoto. No es un rsync que será atendido por un demonio rsync en un sistema remoto.

rsync -avPSI VMBACKUP_2011-06-10_02-27-56/* VMBACKUP_2011-06-01_06-37-11/ --stats --itemize-changes --existing --modify-window=2 --no-whole-file
sending incremental file list
>f..t...... VM-flat.vmdk
 42949672960 100%   15.06MB/s    0:45:20 (xfer#1, to-check=5/6)
>f..t...... VM.vmdk
         556 100%    4.24kB/s    0:00:00 (xfer#2, to-check=4/6)
>f..t...... VM.vmx
        3327 100%   25.19kB/s    0:00:00 (xfer#3, to-check=3/6)
>f..t...... VM_1-flat.vmdk
 42949672960 100%   12.19MB/s    0:56:01 (xfer#4, to-check=2/6)
>f..t...... VM_1.vmdk
         558 100%    2.51kB/s    0:00:00 (xfer#5, to-check=1/6)
>f..t...... STATUS.ok
          30 100%    0.02kB/s    0:00:01 (xfer#6, to-check=0/6)

Number of files: 6
Number of files transferred: 6
Total file size: 85899350391 bytes
Total transferred file size: 85899350391 bytes
Literal data: 2429682778 bytes
Matched data: 83469667613 bytes
File list size: 129
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2432530094
Total bytes received: 5243054

sent 2432530094 bytes  received 5243054 bytes  295648.92 bytes/sec
total size is 85899350391  speedup is 35.24

¿Es esto porque ESXi está haciendo tantos cambios en los VMDK que, en lo que respecta a rsync, todo el archivo tiene que ser retransmitido?

¿Alguien ha logrado realmente la sincronización de diferencias real con ESXi?


rsynce es incremental por defecto. Difícil de creer, pero cierto. Tengo curiosidad de dónde va la descarga de rsynce que funciona en ESXi. Tengo ESXi 4.1

Respuestas:


6

Parece que solo has transferido 2 GB de cambios incrementales. Recuerde que rsync todavía tiene que leer en un archivo completo y sumarlo para que tenga que leer 80 GB de datos. Verifique las estadísticas de su servidor durante el rsync. ¿Está CPU o IO obligado durante la operación? ¿Qué tan rápido puede leer el archivo de 80GB en el disco? Eso estará cerca de su tiempo de transferencia mínimo absoluto.

También es de destacar que rsync hace una copia del archivo durante la transferencia y luego mueve el archivo final a su lugar en una operación atómica. Puede ver esto al ver un nombre de archivo similar con un sufijo aleatorio durante la transferencia en el directorio de destino. Esto significa que debe leer 160 GB de datos (80 GB cada uno para cada origen y destino) y escribir 80 GB en el lado del destino. ¿Has mirado la opción --inplace? Puede ser beneficioso aquí.

En resumen, es posible que solo tenga 2 GB de cambios, pero rsync está haciendo MUCHO trabajo. Probablemente esté obligado a IO ya que toda esa lectura y escritura en el mismo disco podría causar mucha contención y desaceleración.


Gracias bot403 por tu respuesta. Me di cuenta de que los bytes transferidos eran significativamente más bajos, pero todavía estaba buscando un tiempo de espera de más de 30-45 minutos. También podría haber reenviado los archivos en su totalidad. Podría haber un cuello de botella IO aquí, pero creo que está dentro de ESXi y no tanto en el hardware. Lo moveré a un LUN y probaré allí. Muchas gracias a todos.
JuliusPIV

4

Este hilo es muy antiguo, pero puede ayudar a alguien.

Como ESX está bloqueando el sistema de archivos en cada escritura de nuevos bloques, el rendimiento no es tan bueno, con la opción: en el lugar puede obtener mejores resultados, pero tenga en cuenta que si cancela la sincronización, el archivo no será consistente más. Acerca de la coherencia, rsync de un archivo abierto podría ser inconsistente de cualquier manera -> mejor usar la instantánea antes de rsync.

Saludos cordiales Marc


2

Por lo que parece, está haciendo una copia local a local con rsync. En ese caso, el comportamiento predeterminado de rsynces desactivar el algoritmo de transferencia delta y realizar transferencias de "archivo completo". La razón de este comportamiento predeterminado es que las transferencias locales a locales que usan el algoritmo delta-xfer generalmente serían más lentas que simplemente copiar los archivos completos, ya que el algoritmo delta implica mucho más procesamiento de la CPU que simplemente hacer la copia de todo el archivo.

Si cree que una copia local a local se beneficiaría con el uso del algoritmo delta-xfer, puede forzar rsyncsu uso especificando la opción --no-W(o --no-whole-file).


Gracias por la respuesta Steven! Estás en lo correcto: estoy haciendo una copia local solo con fines de prueba (también conocido como para confirmar que realmente hará una sincronización diferencial). Finalmente, los archivos se copiarán en un almacén de datos local, un LUN que he expuesto que reside en una máquina remota. En realidad, no será un tipo de sincronización de demonio de rsync a rsync. Por lo que vale, estoy usando la --no-whole-fileopción como parte del comando rsync; está más allá de la vista de la pantalla.
JuliusPIV

@Julius: ¡Vaya, me perdí esa barra de desplazamiento horizontal! Oh bueno, perdón por perder tu tiempo.
Steven lunes
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.