wiki:Syncronize1.1

Version 2 (modified by irina, 7 years ago) (diff)

--

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 imágenes "hijas"

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.

Desaparecería en concepto de diferencial, ya que todas contienen los datos completos. Tendríamos imágenes hermanas o hijas, 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 hija

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 

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:

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 hija 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.

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

Errores resueltos:

rsync -aHAX --password-file=/scripts/passrsync --exclude 'coredump' --numeric-ids --progress --inplace --delete /mnt/sda1/ opengnsys@$ogrepo::syncimages/otra

La segunda vez no syncroniza nada → aunque está comprimido rsync compara bien los archivos

Error haciendo imagen de Ubuntu 16 (sólo este error)

  • rsync: set_acl: sys_acl_set_file(media/instalcdc, ACL_TYPE_ACCESS): Operation not supported (95)
  • Solución: zfs set acltype=posixacl sync # Para que soporte acl

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.

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.