TOC(headinf=Índice)?

En construcción

Pruebas de mejoras en imágenes sincronizadas

Introducción

Actualmente no están utilizando las imágenes sincronizadas por tener una serie de problemas:

• Falta de compresión en la imagen, por lo que ocupa mucho espacio en el servidor.
• La transferencia es más lenta que las imágenes monolíticas.
• Las Acl de Windows se tiene que restaurar de forma independiente, después de restaurar los archivos.

En está página mostraremos los resultados de las últimas pruebas que estamos haciendo.

Problema de espacio en disco

Concepto clonar imagen

Observando como trabaja rsnapshop vemos que al crear una nueva copia de seguridad de un dispositivo toma como punto de partida una anterior y luego aplica rsync entre el equipo origen y el nuevo backup. OpenGnsys podría utilizar este procedimiento para imágenes similares.

Primera copia:	rsync user@equipo_remoto::/carpeta backup1
Segunda copia:	cp -al backup1 backup2 rsync user@equipo_remoto::/carpeta backup2

La opción -l del comado cp crea enlaces “duros” a los archivos en vez que copiarlos, de esta forma no se ocupa nuevo espacio en el disco duro y es mucho más rápido.

En rsync es imprescindible no usar la opción “--inplace”

Si no se usa esta opción, rsync copia el archivo que está sincronizando en un fichero temporal y al final sustituye el original, eliminando el enlace entre los archivos de distintas imágenes.

Si ponemos esta opción rsync modifica directamente el archivo, no rompe el enlace y modifica todas la imágenes que tengamos.

Podría desaparecer el concepto de diferencial, ya que todas contienen los datos completos. Tendríamos imágenes clonadas, tomando como partida una imagen parecida y luego sincronizándola con la partición del equipo modelo.

Las imágenes serían tipo directorio, ya que es la única forma de hacer enlaces entre archivos de varias imágenes.

Más información en [​Easy Automated Snapshot-Style Backups with Linux and Rsync (rsnapshop se basa en este artículo).

Pruebas velocidad al crear una imagen clonada

Tamaño de la imagen: 3,7Gb → 0m 56s

cdc@ogdevel:/opt/opengnsys/bin$ sudo ./cloneimage Ubuntu16Sync UbuntuClone 
Copiamos los archivos de una imagen a otra. 
   * cd /opt/opengnsys/images 
   * cp -lrP /opt/opengnsys/images/Ubuntu16Sync /opt/opengnsys/images/UbuntuClone 
La copia ha terminado correctamente. 
   Fin del script. Tiempo total: 0m 56s 

Pruebas con Btrfs

Permite montar con compresión de forma transparente. Pero:

• du muestran el tamaño de los datos como si estuvieran descomprimidos (según la documentación por coherencia con los sistemas de ficheros anteriores)
• df sí muestra la ocupación del sistema de ficheros teniendo en cuenta la compresión. Para saber el tamaño de una imagen habría que calcular la ocupación del repositorio (cache o repo) antes y después de crearla.

Prueba creación de una imagen

Partición cliente	df /dev/sda1 14G 3,8G 9,5G 29% /mnt/sda1
Imagen en cliente	ls $OGCAC$OGIMG UbuntuSync df /dev/sda4 39G 1,9G 35G 6% /opt/opengnsys/cache
Imagen en servidor	du -sh UbuntuSync 3,7G UbuntuSync

Prueba creación de dos imágenes una clonada de otra

Tamaño de los datos en las particiones del cliente (con df):

Partición 1 cliente	/dev/sda1 14632408 3877776 9988280 28% /mnt/sda1	3,7G
Partición 2 cliente	/dev/sda2 29397972 20644320 7237848 75% /mnt/sda2	20G

Al crear la segunda imagen el primer paso es clonar la imagen del mismo sistema operativo que tenga el tamaño más parecido.

Tamaño de las imágenes en la partición cache (con df):

Creo imagen de la primera partición	/dev/sda4 40000000 2030032 36181552 6% /opt/opengnsys/cache	2,0G
Creo imagen de la segunda partición	/dev/sda4 40000000 11574108 27603108 30% /opt/opengnsys/cache	11G

Nota: al copiar la imagen en Btrfs es necesario incluir la opción -P para que no siga los enlaces simbólicos. En ext4 no se presenta este problema.

Creo diferencial

En servidor: cp -al Ubuntu14 Ubuntu14bis
En cliente: rsync -aHAX --password-file=/scripts/passrsync --exclude 'coredump' --numeric-ids --progress --inplace --delete /mnt/sda1/ opengnsys@$ogrepo::syncimages/Ubuntu14bis

Error: diff Ubuntu14/etc/hosts Ubuntu14bis/etc/hosts → son iguales

Solución: Para que no se mantenga el enlace y no reescriba los ficheros de otras imágenes hay que eliminar la opción –inplace.

Problema de velocidad de transferencia

Hasta ahora para transferir una imagen a la partición destino se utiliza rsync, ya esté en el repositorio o en cache. Vamos a utilizar multicast si la transferencia es desde el repositorio y tar de la partición cache a la definitiva si está en local.

Se realizan varios pasos:

• En cada cliente con rsync se crea un listado con los ficheros que hay que modificar y se envían al servidor (unificándolo con los que ya se hayan mandado).
• El servidor envía a todos los clientes los ficheros del listado por multicast y si es desde cache a la partición se usa tar.
• Cada cliente vuelve a ejecutar rsync para comparar los atributos y enlaces.

Influencia del cambio de imagen

La primera vez que copiamos a la cache el comando restaurar realiza dos pasos:primero pasa la imagen del servidor a la cache y luego de la cache. Aunque estos pasos son independientes en las pruebas se aprecia que el paso de transferir la imagen de la cache a la partición dura mucho más si se ha realizado antes un updateCache de la imagen completa.

Repetimos la última prueba sin borrar la cache, ni modificar la imagen en el servidor (4 pruebas)

updateCache	rsync	total
0m 35s	2m 4s	2m 51s

Nota: no hemos probado que pasa si la modificación de la imagen en el servidor es menor.

Pruebas descartadas

Espacio en disco

Compresión de los datos en el servidor

Encontramos varios procedimientos:

• Montar los dispositivos remotos con compresión: no lo hemos probado

  sshfs -o nonempty,sshfs_sync,compression=yes username@host:/path/archives/ /mounted/compress
  

• Sistemas de fichero comprimidos. Encontramos varios:
  • Btrfs
  • ZFS
  • FUSE: FuseCompress? or CompFUSEd.

Sistemas de ficheros descartados

FuseCompress Según su página en ​https://github.com/tex/fusecompress github "El archivo se vuelve ilegible cuando llega a una condición de espacio insuficiente." Descartado.

CompFUSEd Parece que el proyecto está abandonado: últimas informaciones de 2009. Descartado

Btrfs Permite montar con compresión de forma transparente. Pero:

• df u du muestran el tamaño de los datos como si estuvieran descomprimidos (según la documentación por coherencia con los sistemas de ficheros anteriores)
• Al crear el sistema de ficheros no hay opción de compresión, por lo que el tamaño es igual si los datos están comprimidos o sin comprimir.

Pruebas con ZFS

En un equipo cliente al actualizar una imagen en la cache en zfs por multicast se queda completamente colgado. Descartamos está opción

Las pruebas se hacen con Ubuntu16, ya que los nuevos kernel traen mejor soporte para este sistema de ficheros.

ZFS permite gestionar varios dispositivos (discos o archivos) para crear un pool y en el puede definir los sistemas de ficheros que queramos.

Por comodidad usamos un archivo para el dispositivo.

Creamos un sistema de fichero con compresión y acl:

truncate --size="10"G /opt/opengnsys/images/store
zpool create sync /opt/opengnsys/images/store
zfs create sync/images
zfs set compression=on sync/images
zfs set acltype=posixacl sync

Opciones de montaje:

Mount
sync/images on /sync/images type zfs (rw,relatime,xattr,posixacl)

Configuramos el demonio rsync en el servidor para compartir el directorio de las imágenes sincronizadas. En /etc/rsyncd.conf:

    [ogimages]
    comment = Carpeta de imagenes sincronizadas
    path = /sync/images
    read only = no
    list = yes
    uid = root
    gid = root  
    auth users = opengnsys
    secrets file = /etc/rsyncd.secrets

Tamaño de los datos

En Ubuntu 16.04

Recién creado	df -h → sync/images 10094464 0 10094464 0% /sync/images
Creamos imagen Ubuntu14 origen 1.1Gb	df -h → sync/images 9.7G 584M 9.1G 6% /sync/images sudo du -sh Ubuntu14 → 609M Ubuntu14

Creo Ubuntu 16 origen 3,9G	df -h → sync/images 9.7G 2.6G 7.1G 27% /sync/images sudo du -sh * → 609M Ubuntu14 → 2.1G Ubuntu16
Creo diferencial cp -al Ubuntu14 Ubuntu14bis rsync (sin opción --inplace)	df -h → sync/images 9.7G 2.6G 7.1G 27% /sync/images sudo du -sh * → 609M otra → 2.1G Ubuntu16 → 629M Ubuntu14bis

Rsync compara correctamente los ficheros de la partición origen a la imagen comprimida.

Observamos que hay diferencias entre los archivos de las distintas imágenes:

diff Ubuntu14/etc/hosts Ubuntu14bis/etc/hosts
10a11,12
> 
> 192.168.2.10	ogrepo

Velocidad de transferencia

Uso de tar: descartado

Sustituir el rsync para pasar de la partición cache a la partición definitiva por el comando tar.

De la imagen del servidor a la cache transfiere por multicast y de la cache a la partición se pasa con un archivo tar:

cd $OGCAC$OGIMG/$NOMBRE_IMG 
tar -c | - tar -x -C  /mnt/sdaX

Se han hecho pruebas de velocidad y se descarta.

Restauramos una imagen básica borrando antes la cache y la partición. El comando utilizado es el siguiente:

RestoreBaseImage CACHE UbuntuSync  1 1 MULTICAST 9010:full-duplex:239.194.17.2:200M:20:60

Resumen de 4 pruebas

updateCache	TAR	rsync	total
5m 16s	5m 31s	39s	11m45s

Eliminamos el paso del TAR (tampoco hay que crear las diferencias) (2 pruebas)

updateCache	rsync	total
5m 24s	5m 5s	10m 45s

Pruebas con el comando cp: descartado

Al descartar el tar se ha pensado como alternativa el comando cp, también se descarta. Copiar la misma imagen de la cache a la partición tarda prácticamente lo mismo.

cp -rp $OGCAC$OGIMG/UbuntuSync/* /mnt/sda1

1m 56s