[[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 [[http://www.mikerubel.org/computers/rsync_snapshots 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 ||