wiki:Syncronize1.1-1.1multicast

Cambios de la versión 1.1 a la versión 1.1 multicast (tipo archivo)

En la versión 1.1

La imágenes se guardan en un archivo que contiene el sistema de ficheros EXT4/BTRFS con el contenido de la partición original.

Cuando se va a crear o restaurar la imagen se monta el sistema de ficheros de la imagen sobre un directorio y se sincroniza con rsync dicho directorio con la partición.

Para guardar la imagen en cache podemos enviar el fichero completo o montar el sistema de ficheros sobre un directorio y sincronizar los archivos que contiene.

Nota: se recomienda el sistema de fichero EXT4 para las imágenes.

Características de está versión

Tamaño de las imágenes

La imagen ocupa lo mismo que los datos de la partición; no se ha encontrado forma de comprimirlos. (Se intentó con btrfs pero sin éxito).

Velocidad de transferencia

Se mejora utilizando los protocolos multicast o torrent la primera vez que se manda la imagen a cache. Para ello es necesario que la imagen se “empaquete” en un archivo.

Comportamiento de los scripts

updateCache

Al guardar la imagen en cache por primera vez se puede enviar el fichero completo utilizando los mismos protocolos que para las imágenes monolíticas o rsync. Rsync en más lento que multicast o torrent.

Cuando ya existe la imagen en cache y se ha modificado la del servidor, para actualizar se montarán ambas imágenes y sólo se transferirán las diferencias.

restoreBaseImage y restoreDiffImage

Para copiar la imagen a la partición, ya sea de servidor o desde cache sólo podemos utilizar la sincronización con rsync. La primera vez tendrán que pasarse todos los datos pero las siguientes sólo los que se hayan modificado.

Se tiene la opción de no borrar los ficheros nuevos que haya creado el usuario. Por defecto sí se borran.

En la versión 1.1 multicast

Las imágenes se guardan en un directorio.

Cuando se va a crear o restaurar la imagen desde el repositorio se sincroniza el directorio de con rsync o multicast con la partición.

De igual modo para guardar la imagen en cache utilizaremos rsync o multicast.

Para transferir de la cache a la partición sólo podemos utilizar rsync.

Características de está versión

Tamaño de las imágenes

Se mejora respecto a la versión anterior al clonar las imágenes con enlaces duros y utilizando en cache el sistema de ficheros btrfs con compresión.

Velocidad de transferencia

Para permitir clonar las imágenes no podemos “empaquetarlas” en un archivo, esto no permite que use los protocolos multicast o torrent de igual forma que las monolíticas.

Podemos utilizar multicast pero hemos de dar tres pasos:

  • Detección de los ficheros a transferir con rsync.
  • Transferencia de los ficheros empaquetado en un tar con multicast (udp-sender/udp-receiver).
  • Creación de enlaces simbólicos o "duros" con rsync.

Comportamiento de los scripts

initCache o mountCache

La cache de los equipos se puede formatear en btrfs y montar de forma comprimida consiguiendo que las imágenes ocuparán menos espacio. Por defecto se mantiene el sistema de ficheros ext4 para la cache.

createBaseImage

Cuando se crea una nueva imagen primero se busca si existe otra del mismo sistema operativo y se clona (copia con enlaces duros) la más cercana en tamaño. Los datos que sean iguales de una a otra sólo ocuparán el espacio una vez.

  • Con el script cloneImage o la función ogCloneImage puedo elegir antes de crear la imagen cuál es la que considero más parecida a la nueva.
  • La función ogInitImage es utilizada por createBaseImage para elegir cuál es la imagen más cercana clonarla con ogCloneImage.

Nota: el script createDiffImage no clona una imagen existente por no tener un criterio para saber si son similares, pero si existiera una parecida sí podríamos clonarla antes de crear la imagen.

updateCache

Al guardar la imagen en cache por primera vez se puede utilizar multicast o rsync. Si utilizamos multicast se darán tres pasos:

  • Detección de los ficheros a transferir con rsync.
  • Transferencia de los ficheros empaquetado en un tar con multicast (udp-sender/udp-receiver).
  • Creación de enlaces simbólicos o "duros" con rsync.

restoreBaseImage y restoreDiffImage

Para copiar la imagen a la partición si el origen es el servidor podemos utilizar la sincronización con multicast con los mismos pasos que updateCache o con rsync. Cuando se restaura un grupo de ordenadores con multicast, estos mandarán el listado de los ficheros a transferir al servidor y el servidor los unirá en uno solo, mandando todos los ficheros que necesitan los equipos.

Para copiar los datos de la cache a la partición se utilizará siempre rsync.

Cuando existan datos en la partición sólo se transferirán los que se hayan cambiado o borrado.

Se tiene la opción de no borrar los ficheros nuevos que haya creado el usuario. Por defecto sí se borran.

Pruebas de la versión 1.1 y 1.1 multicast

Como queremos poder probar cual de las dos versiones es mejor en cuanto a velocidad de restauración y tamaño de las imágenes no se ha integrado el ticket en la rama de desarrollo. Para probar las dos versiones hay que hacer:

Versión 1.1

Es el código que la versión 1.1. Se han realizado pocos cambios desde la versión 1.0.6.

Versión 1.1 multicast

Después de instalar o actualizar a la versión 1.1 hay que instalar el ticket bajando el script de instalación y ejecutándolo con sudo.

Para probar la compresión de la cache con BTRFS hay que utilizar el ogLive ogLive-xenial-4.8.0-amd64-r5331 y modificar en /opt/opengnsys/client/etc/engine.cfg

CACHEFS=BTRFS

Si queremos pasar imágenes de la versión 1.1 a la 1.1 multicast se puede utilizar el script de servidor /opt/opengnsys/bin/convertimage.

Opcional

Hay otra variable que se puede configurar: cuando se restaura por multicast los equipos mandan al servidor el listado de los archivos a restaurar y esperan un tiempo LISTWAIT antes de solicitar la transferencia multicast. La espera se realiza para qué los otros equipos envíen sus listados.

  • Si el tiempo es muy corto habrá equipos que no hayan mandado el listado y en el último paso de la restauración tardarán más (ya que rsync copiará lo que no se haya transferido con multicast)
  • Si el tiempo es muy largo se retrasará la restauración innecesariamente.
Last modified 20 months ago Last modified on Nov 17, 2017, 12:45:21 PM