Necesito realizar copias de seguridad in situ de cientos de gigabytes desde algunas máquinas virtuales Xen en algún almacenamiento disponible en un servidor dedicado en la misma red, con una conexión Gigabit. Los datos son principalmente datos de MySQL (yo uso Percona XtraDB Cluster), respaldados localmente en los servidores con Xtrabackup, por lo que supongo que estos datos deberían ser altamente comprimibles.
En este momento estoy usando duplicity 0.6.08b con cifrado con frase de contraseña (no estoy usando claves), ya que también sincronizo los volúmenes de respaldo creados con duplicity con algún almacenamiento externo. El nivel de compresión es actualmente 6 y el tamaño del volumen es 250. Las copias de seguridad demoran más de un día, razón por la cual busco configuraciones de duplicidad recomendadas que resulten en copias de seguridad rápidas en el almacenamiento compartido de la red local sin ocupar demasiado espacio.
¿Alguna idea?
Respuesta1
Usted dice en un comentario que está viendo un rendimiento de aproximadamente 50 MB/s en esas copias de seguridad.
50 MB/s esdel orden delo que puede esperar del rendimiento de disco semialeatorio con discos giratorios únicos (es decir, RAID no reflejado o seccionado para permitir que las lecturas se distribuyan entre los discos para aumentar el rendimiento). Tenga en cuenta que algunas configuraciones RAID limitan efectivamente incluso el rendimiento en el mejor de los casos al de la unidad más lenta. Sí, muchos discos duros tienen una potencia de hasta ~200 MB/s, pero tenga en cuenta que esas cifras son números de acceso secuencial en el mejor de los casos. 50 MB/s también son aproximadamente 400 Mbit/s, lo que, con algunas modificaciones para la sobrecarga de IP, etc., da como resultado 500-600 Mbit/s en el cable de red, por lo que si bien no satura el enlace gigabit solo con eso, se están acercando bastante al territorio probable de colisiones.
No proporciona ninguna cifra sobre la utilización de la CPU mientras se ejecutan las copias de seguridad, excepto que "tiene tres hipervisores con un montón de máquinas virtuales en cada uno, más o menos ocupados". Pero copiar datos y comprimirlos no requiere mucho uso de la CPU, y si mientras se ejecutan las copias de seguridad tiene tiempo de sobra para la CPU, entonces no está limitado a la CPU.La única forma de responder realmente a esta pregunta es descubrir qué factor está limitando el rendimiento.y luego centra tus esfuerzos allí.
Mi conjeturasería que usted está vinculado a E/S, ya sea en lectura o escritura, y quepodríaestar vinculado a la red. Habla de un servidor de almacenamiento de respaldo dedicado con una conexión Gigabit Ethernet, pero no dice nada sobre la naturaleza de esa conexión. ¿La conexión de red para copias de seguridad entre los hosts físicos es compartida o dedicada? (Sería aceptable una red física separada que conecte cada uno de los HV al servidor de respaldo, si solo una VM o HV envía datos de respaldo a la vez).
Si la conexión de red física al servidor de respaldo se comparte con otro tráfico de red, podría pasar a una arquitectura de conexión dedicada. El beneficio que obtenga de esto depende en gran medida de dónde se comprimen los datos y de cuántas colisiones realmente esté viendo actualmente, pero si hace esto y nada más,podríapodrá duplicar el rendimiento de la red y, por lo tanto, si está conectado a la red, reducirá los tiempos de respaldo a la mitad.
Si está vinculado a la E/S en las lecturas y/o escrituras, entonces pasar a una configuración reflejada o seccionada que permita que la E/S del disco se distribuya en varios discos podría ayudar a aumentar el rendimiento; aumentaría el rendimiento total del bus de disco. Por supuesto, eso tiene sus propias desventajas. Dependiendo de la cantidad de datos que envíes en un momento dado, agregar másrápidocaché de disco al servidor de almacenamiento de respaldopodríaTambién ayuda, pero sospecho que si estás vinculado a E/S, está en el lado de lectura porque las escrituras probablemente sean más o menos secuenciales, en cuyo caso agregar caché no te ayudará mucho.
También podría considerar pasar a un sistema de archivos en las máquinas virtuales o HV, y/o en el servidor de almacenamiento de respaldo, que realice la compresión sobre la marcha de los datos tal como se escriben en el disco, o habilitar dicha compresión si es compatible. . Costará tiempo de CPU, pero aumenta laeficazvelocidad de transferencia de datos del disco porque es necesario mover menos datos hacia y desde los platos físicos para la misma cantidad de datos del espacio de usuario almacenados. Si eso sería o no una ganancia neta en cualquier situación es básicamente una moneda al aire y debe evaluarse caso por caso, pero ciertamente es una cuestiónposibilidadpara la situación en la que está vinculado a E/S, especialmente si, para empezar, los datos son altamente comprimibles. Incluso si los datos sólo se pueden comprimir al 20% (equivalente a una relación de compresión de 1,25:1, y definitivamente se puede lograr, por ejemplo, con texto en lenguaje natural; a modo de comparación, ZFS con compresión gzip-9 me da una compresión de 1,20:1 en una muestra de sitios web de Internet,incluyendo imágenes), esas mismas velocidades de transferencia del plato de 50 MB/s de repente le brindan más de 60 MB/s de datos útiles transferidos, suponiendo que la CPU del host pueda seguir el ritmo de la compresión y descompresión.Tenga en cuenta que los datos cifrados sonsupuestocomprimir muy mal, ya que debería parecerse a un ruido aleatorio; generalmente comprimirá antes del cifrado, si planea cifrar los datos, en cuyo caso la compresión a nivel del sistema de archivos en el lado cifrado no le servirá de nada.