Changes between Initial Version and Version 1 of Syncronize1.1-1.1multicast

Timestamp:

Jun 29, 2017, 1:12:35 PM (7 years ago)

Author:

irina

Comment:

--

Syncronize1.1-1.1multicast

@@ +1 @@
+[[TOC(heading=Índice)]]
+
+= Cambios de la versión 1.0.6 a la versión 1.1 (tipo archivo)  =
+
+== En la versión 1.0.6 ==
+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 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 ==
+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.0.6 y 1.1 ==
+
+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.0.6: La versión 1.1 trae el código de las sincronizadas de la 1.0.6.
+ * Versión 1.1: Después de instalar o actualizar a la versión 1.1 hay que instalar el ticket bajando el [source:branches/version1.1-tickets/Sincronizadas-multicast-ticket770/installer-info/install.sh script de instalación] y lo ejecutándolo con sudo.
+
+Si queremos pasar imágenes de la versión 1.0.6 a la 1.1 se puede utilizar el script de servidor /opt/opengnsys/bin/convertimage.