Changes between Version 3 and Version 4 of Syncronize1.1


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

--

Legend:

Unmodified
Added
Removed
Modified
  • Syncronize1.1

    v3 v4  
    11[[TOC(headinf=Índice)]]
    2 {{{
    3 #!div style="width:50%; background: #ffd; font: bold italic large sans-serif">
    4 En construcción
    5 }}}
    6 
     2
     3== En construcción ==
    74
    85= Pruebas de mejoras en imágenes sincronizadas =
     
    1714== Problema de espacio en disco ==
    1815
    19 === Concepto imágenes "hijas" ===
     16=== Concepto clonar imagen ===
    2017
    2118Observando 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.
     
    3229 Si ponemos esta opción rsync modifica directamente el archivo, no rompe el enlace y modifica todas la imágenes que tengamos.
    3330
    34 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.
     31Podrí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.
    3532
    3633Las imágenes serían tipo directorio, ya que es la única forma de hacer enlaces entre archivos de varias imágenes.
     
    3835Má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).
    3936
    40 __Pruebas velocidad al crear una imagen hija__
     37__Pruebas velocidad al crear una imagen clonada__
    4138
    4239Tamaño de la imagen:  3,7Gb → 0m 56s
     
    5249
    5350
     51
     52
     53==== Pruebas con Btrfs ====
     54
     55Permite montar con compresión de forma transparente. Pero:
     56 * 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)
     57 * 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.
     58
     59__Prueba creación de una imagen__
     60
     61|| Partición cliente || df \\ /dev/sda1              14G  '''3,8G'''  9,5G  29% /mnt/sda1 ||
     62|| Imagen en cliente || ls $OGCAC$OGIMG \\ !UbuntuSync \\ df \\/dev/sda4              39G  '''1,9G'''   35G   6% /opt/opengnsys/cache ||
     63|| Imagen en servidor || du -sh !UbuntuSync \\ '''3,7G'''       !UbuntuSync ||
     64
     65__Prueba creación de dos imágenes una clonada de otra__
     66
     67Tamaño de los datos en las particiones del cliente (con df):
     68|| Partición 1 cliente || /dev/sda1             14632408  '''3877776'''   9988280  28% /mnt/sda1 || '''3,7G''' ||
     69|| Partición 2 cliente || /dev/sda2             29397972 '''20644320'''   7237848  75% /mnt/sda2 || '''20G''' ||
     70
     71Al crear la segunda imagen el primer paso es clonar la imagen del mismo sistema operativo que tenga el tamaño más parecido.
     72
     73Tamaño de las imágenes en la partición cache (con df):
     74|| Creo imagen de la primera partición || /dev/sda4   40000000  '''2030032'''  36181552   6% /opt/opengnsys/cache || '''2,0G''' ||
     75|| Creo imagen de la segunda partición || /dev/sda4   40000000 '''11574108'''  27603108  30% /opt/opengnsys/cache || '''11G '''||
     76
     77Nota: 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.
     78
     79
     80
     81Creo diferencial
     82
     83'''En servidor: cp -al Ubuntu14 Ubuntu14bis \\
     84En cliente: rsync -aHAX  --password-file=/scripts/passrsync  --exclude 'coredump' --numeric-ids --progress --inplace --delete   /mnt/sda1/ opengnsys@$ogrepo::syncimages/Ubuntu14bis'''
     85
     86Error: diff Ubuntu14/etc/hosts Ubuntu14bis/etc/hosts → son iguales
     87
     88Solución: Para que no se mantenga el enlace y no reescriba los ficheros de otras imágenes hay que eliminar la opción –inplace.
     89
     90== Problema de velocidad de transferencia ==
     91
     92Hasta 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.
     93
     94Se realizan varios pasos:
     95
     96   * 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).
     97   * 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.
     98   * Cada cliente vuelve a ejecutar rsync para comparar los atributos y enlaces.
     99
     100
     101
     102
     103=== Influencia del cambio de imagen ===
     104La 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.
     105
     106Repetimos la última prueba sin borrar la cache, ni modificar la imagen en el servidor (4 pruebas)
     107|| updateCache || rsync || total ||
     108|| 0m 35s || 2m 4s || 2m 51s  ||
     109
     110Nota: no hemos probado que pasa si la modificación de la imagen en el servidor es menor.
     111
     112
     113== Pruebas descartadas ==
     114
     115=== Espacio en disco ===
     116
    54117=== Compresión de los datos en el servidor ===
    55118Encontramos varios procedimientos:
     
    64127  * FUSE: FuseCompress or CompFUSEd.
    65128
    66 ==== Pruebas con Btrfs ====
    67 
     129==== Sistemas de ficheros descartados ====
     130__FuseCompress__
     131Segú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.
     132
     133__CompFUSEd__
     134Parece que el proyecto está abandonado: últimas informaciones de 2009. Descartado
     135
     136__Btrfs__
    68137Permite montar con compresión de forma transparente. Pero:
    69  * 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)
    70  * 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.
    71 
    72 __Prueba creación de una imagen__
    73 
    74 || Partición cliente || df \\ /dev/sda1              14G  '''3,8G'''  9,5G  29% /mnt/sda1 ||
    75 || Imagen en cliente || ls $OGCAC$OGIMG \\ !UbuntuSync \\ df \\/dev/sda4              39G  '''1,9G'''   35G   6% /opt/opengnsys/cache ||
    76 || Imagen en servidor || du -sh !UbuntuSync \\ '''3,7G'''       !UbuntuSync ||
    77 
    78 __Prueba creación de dos imágenes una hija de otra__
    79 
    80 Tamaño de los datos en las particiones del cliente (con df):
    81 || Partición 1 cliente || /dev/sda1             14632408  '''3877776'''   9988280  28% /mnt/sda1 || '''3,7G''' ||
    82 || Partición 2 cliente || /dev/sda2             29397972 '''20644320'''   7237848  75% /mnt/sda2 || '''20G''' ||
    83 
    84 Al crear la segunda imagen el primer paso es clonar la imagen del mismo sistema operativo que tenga el tamaño más parecido.
    85 
    86 Tamaño de las imágenes en la partición cache (con df):
    87 || Creo imagen de la primera partición || /dev/sda4   40000000  '''2030032'''  36181552   6% /opt/opengnsys/cache || '''2,0G''' ||
    88 || Creo imagen de la segunda partición || /dev/sda4   40000000 '''11574108'''  27603108  30% /opt/opengnsys/cache || '''11G '''||
    89 
    90 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.
     138 * 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)
     139 * 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.
     140
     141
    91142
    92143==== Pruebas con ZFS ====
     
    150201}}}
    151202
    152 Errores resueltos:
    153 
    154 '''rsync -aHAX  --password-file=/scripts/passrsync  --exclude 'coredump' --numeric-ids --progress --inplace --delete   /mnt/sda1/ opengnsys@$ogrepo::syncimages/otra'''
    155 
    156 La segunda vez no syncroniza nada → aunque está comprimido rsync compara bien los archivos
    157 
    158 Error haciendo imagen de Ubuntu 16 (sólo este error)
    159  * rsync: set_acl: sys_acl_set_file(media/instalcdc, ACL_TYPE_ACCESS): Operation not supported (95)
    160  * Solución: zfs set acltype=posixacl sync   # Para que soporte acl
    161 
    162 
    163 
    164 
    165 Creo diferencial
    166 
    167 '''En servidor: cp -al Ubuntu14 Ubuntu14bis \\
    168 En cliente: rsync -aHAX  --password-file=/scripts/passrsync  --exclude 'coredump' --numeric-ids --progress --inplace --delete   /mnt/sda1/ opengnsys@$ogrepo::syncimages/Ubuntu14bis'''
    169 
    170 Error: diff Ubuntu14/etc/hosts Ubuntu14bis/etc/hosts → son iguales
    171 
    172 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.
    173 
    174 
    175 
    176 
    177 ==== Sistemas de ficheros descartados ====
    178 __FuseCompress__
    179 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.
    180 
    181 __CompFUSEd__
    182 Parece que el proyecto está abandonado: últimas informaciones de 2009. Descartado
    183 
    184 __Btrfs__
    185 Permite montar con compresión de forma transparente. Pero:
    186  * 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)
    187  * 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.
    188 
    189 
    190 == Problema de velocidad de transferencia ==
    191 
    192 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.
    193 
    194 Se realizan varios pasos:
    195 
    196    * 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).
    197    * 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.
    198    * Cada cliente vuelve a ejecutar rsync para comparar los atributos y enlaces.
    199 
    200 
    201 
    202 === Uso de tar: descartado ===
     203
     204=== Velocidad de transferencia ===
     205
     206==== Uso de tar: descartado ====
     207
     208Sustituir el rsync para pasar de la partición cache a la partición definitiva por el comando tar.
     209
     210De la imagen del servidor a la cache transfiere por multicast y de la cache a la partición se pasa con un archivo tar:
     211
     212{{{
     213cd $OGCAC$OGIMG/$NOMBRE_IMG
     214tar -c | - tar -x -C  /mnt/sdaX
     215}}}
     216
    203217Se han hecho pruebas de velocidad y se descarta.
    204218
     
    217231|| 5m 24s || 5m 5s || 10m 45s ||
    218232
    219 === Influencia del cambio de imagen ===
    220 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.
    221 
    222 Repetimos la última prueba sin borrar la cache, ni modificar la imagen en el servidor (4 pruebas)
    223 || updateCache || rsync || total ||
    224 || 0m 35s || 2m 4s || 2m 51s  ||
    225 
    226 Nota: no hemos probado que pasa si la modificación de la imagen en el servidor es menor.
    227 
    228233=== Pruebas con el comando cp: descartado ===
    229234
     
    232237||  cp -rp $OGCAC$OGIMG/UbuntuSync/* /mnt/sda1 ||
    233238|| 1m 56s ||
    234