Context Navigation

Changes between Version 3 and Version 4 of Syncronize1.1

Timestamp:: Jun 27, 2017, 1:53:37 PM (7 years ago)
Author:: irina
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

Syncronize1.1

-                      v3
+                      v4
 [[TOC(headinf=Índice)]]
+{{{
+#!div style="width:50%; background: #ffd; font: bold italic large sans-serif">
+En construcción
+}}}
+== En construcción ==
 = Pruebas de mejoras en imágenes sincronizadas =
 …
 == Problema de espacio en disco ==
 === Concepto imágenes "hijas" ===
+=== 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.
 …
  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.
+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 hija__
+__Pruebas velocidad al crear una imagen clonada__
 Tamaño de la imagen:  3,7Gb → 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:
 …
   * FUSE: FuseCompress or CompFUSEd.
+==== Pruebas con Btrfs ====
+==== 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:
+ * 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.
+ * 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 ====
 …
 }}}
+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.
+== 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.
+=== Uso de tar: descartado ===
+=== 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.
 …
 || 5m 24s || 5m 5s || 10m 45s ||
-=== 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 con el comando cp: descartado ===
 …
 ||  cp -rp $OGCAC$OGIMG/UbuntuSync/* /mnt/sda1 ||
 || 1m 56s ||