opengnsys-1.1.0 (#14) - Deploy imagen cache intra-aula via torrent (#364) - Message List

Deploy imagen cache intra-aula via torrent
 unsolved

Hola,

como ya comentamos en el curso avanzado en UPC, tenemos un problema de saturación de enlace entre edificios. Para minimizar el uso del enlace y del servidor planteabamos la idea de desplegar un equipo master por aula y después realizar el despliegue al resto de la misma.

Con el asistente de clonación de particiones podemos clonar una partición y parece que una imagen que esté en cache en el equipo master sobre una partición del resto de equipos.

Con las pruebas que hemos realizado lo que mejor nos funciona es el deploy via torrent, no nos funciona el multicast y en unicast saturamos el enlace. Mientras que via torrent hemos desplegado con una media de transacción de 130Mb/s desde el servidor 30 equipos sin problemas. Pero son solo el 9% de los equipos del campus. De ahí la necesidad del esquema de replicación que explico al inicio.

Querríamos saber si es posible hacer una copia de esa imagen en chache en el equipo master del aula sobre la cache del resto del aula via torrent. ¿Es posible?

Mirando el código del script de cloneRemoteFromMaster: # @function cloneremoteFromMaster: @brief Restaura una particion o imagen sobre las particiones de equipos cliente remotos #@param $1 str_origen admite dirección IP del equipo Master. #@param $2 str_origen admite int_disk str_REPO|str_CACHE #@param $3 str_origen admite int partorigen stre_imagen #@param $4 str_sesion multicast #@param $5 int_disco_destino #@param $6 init_particion_destino #@param ejemplo: cloneRemoteFromMaster 172.17.36.11 1 1 9000:full-duplex:239.194.17.36:70M:50:100 1 1 partclone lzop #@param ejemplo: cloneRemoteFromMaster 172.17.36.11 REPO /imagen1 9000:full-duplex:239.194.17.36:70M:50:100 1 1 partclone lzop #@param ejemplo: cloneRemoteFromMaster 172.17.36.11 CACHE /imagen1 9000:full-duplex:239.194.17.36:70M:50:100 1 1 partclone lzop #@return la propia de la herramienta de clonacion partimage o ntfsclone

unicamente está definido el destino en partición, pero en nuestro caso querríamos dejarlo en caché por 2 motivos:

  • para no tener que desplegarla cada vez
  • para evitar la modificación de la partición en modo desatendido.

Saludos,

Andrés

  • Message #811

    Andrés, buenas tardes, Sí que comentaste vuestra particularidad, y la recuerdo perfectamente.

    Voy por partes:

    1) La "implementación gráfica" actual de las clonaciones usando el Master, solo permite como destino la partición de un cliente. Ya se está gestionando más opciones para esta forma de trabajar de manera descentralizada. Te he puesto que la "implementación gráfica" tiene sus limitaciones, pero desde línea de comando tienes opciones de aplicar esta nueva funcionalidad.

    2) Parto de tu forma de trabajar: a) Desde el servidor despliegas la imagen a la cache de los equipos Master que están distribuidos por edificios.

    b) Una vez que están los equipos Master actualizados, puedes hacer que sean ellos los que compartan "seedeen" la imagen torrent al resto de equipos. Aplicando esta rutina sobre los equipos Master, consigues que en el enjambre torrent, tengas n_Servidores.

    c) Una vez que tengas a los Master como seeder, haces el deploy en los demás clientes. Los clientes, analizarán el fichero .torrent de la imagen desde el server, conectarán con el tracker (el server) y éste reportará a los clientes que existen n_Servidores con esa imagen.

    ¿Como lo ves?

    Seguro que sabes como aplicar esta filosofía, yo intentaré mañana dejar en este hilo la instrucción que deberías de ejecutar en el equipo máster para que se comporte como seeder 100%.

    Saludos.

    • Message #812

      Hola Antonio, es exactamente tal y como lo describes.

      La cosa está en que analizando el contenido del script que se utiliza en la parte gráfica no he visto el modo de pasar la imagen cache de los n-master a los clientes via torrent.

      Entiendo que debe ser algo del estilo:

      cloneRemoteFromMaster 172.16.18.2 CACHE /imagen 1 1 TORRENT peer:60

      ¿O la instrucción/script deployImage permite asignar como origen uno de los masters? Aunque esto nos la escribiría directamente en disco 1 1 y queremos que quede en CACHE, para restaurarla en otro momento.

      deployImage 172.16.18.2 /imagen 1 1 TORRENT peer:60

      De igual forma la instrucción updateCache ¿permite el uso de un nodo master como origen?

      updateCache 172.16.18.2 /imagen TORRENT peer:60

      Estás son las opciones que me he planteado pero sin conseguir que funcionen.

      Gracias de nuevo,

      Andrés

      • Message #814

        Andres,

        Tienes que utilizar esta función: ogTorrentStart() del Protocol.lib

        • Conectate por ssh a un cliente y ejecutar la instrucción con el parámeto help: ogTorrentStart help
        • La sintaxis es:
          • ogTorrentStart CACHE /file.torrent sesionTorrent.
          • La sesión torrent está compuesta por el modo de P2P y el tiempo en segundos que se desea que que esté trabajando.
        • Por ejemplo:
          • ogTorrentStart CACHE /ubuntuv03.img.torrent seeder:3600

        Notas previas sobre el servio Tracker asociado al repositorio:

        • El fichero torrent se genera en el repositorio en el momento de crear la imagen y asocia datos en él para su compartición.
        • Uno de los datos que almacena en el fichero es la dirección IP del TRACKER. Y utiliza la IP del repositorio.
        • Por lo tanto, habrá tantos tracker como repositorios. Y el cliente contactará con el tracker-repositorio que tenga asociado en fichero .torrent.
        • Si quieres visualizar el tracker asociado a un fichero torrent: ctorrent -x fichero.img
        • Voy a crear una incidencia para el estudio de un sólo tracker(en el servidor de administración) o varios tracker (en cada repositorio).
          • En el caso de que quieras disponer de un sólo tracker, coméntalo y te paso la instrucción para hacerlo. Pero quizás, ahora mismo te vaya bien con la configuración estandar de opengnsys.

        Entonces, con todo lo anterior expuesto y centrandome en tu entorno, que presupongo, estos datos:

        • 1) imagen comprobada que es correcta: ubuntuv03
        • 2) La imagen está en el respositorio y con el objeto creado en la interfaz web.
        • 3) La imagen ubuntuv03 se ha descargado previamente a los equipos MASTER en sus respectivas particiones CACHE por torrent.

        El proceso a realizar para forzar a que un MASTER envié por torrent una imagen:

        • 1) Arrancar los equipos MASTER.
        • 2) Ejecutar la instrucción en cada uno de los MASTER: ogTorrentStart CACHE /ubuntuv03.img.torrent seeder:3600
          • El segundo parámetro de la sessión torrent: es el tiempo que deseas que esté el equipo compartiendo, asignale el tiempo que necesiten dependiendo del tamaño de la imagen.
          • Puedes ejecutar la instrucción desde la opcion web "ejecutar scrips" y almacenarla como un procedimiento, para su posterior reutilización.
        • 3) Esperar un tiempo, dependiendo del tamaño de la imagen, para que el MASTER cheque la información del torrent e informe al tracker. Puedes ver la información del tracker accediendo a http://IPtracker:6969
        • 4) Arrancar los clientes en el ogLive
        • 5) Desde la consola web, proceder con una restauración torrent-cache a los clientes.
          • Presta atención de no mandarle la instrucción a un MASTER
          • El clientes contactará con el repositorio, copiará el .torrent e internamente hará una llamada a ogTorrentStart en modo peer para proceder con la descarga.
          • El cliente analizará el .torrent y contactará con el tracker. Y el tracker le informará de que equipos dispone de la imagen, por lo que el cliente se descargará la imagen desde todos los equipos MASTER y Repositorio. Hay un concepto, en p2p que es el "enjambre", esto hace que el tracker va haciendo grupos entre seeder y peer. Quizás te encuentres con dos clientes, que cada uno de ellos esté en enjambres distintos.

        Andrés, sería muy interesante que compartieras tu experiencias y los cambios que hagas para poder ampliar la funcionalidad de la operativa con MASTER.

        Saludos.

        P.D. espero no haber cometido ningún error en las instrucciones que te he indicado. Pero ya sabes, conectate por ssh a un cliente y ve ejecutando el proceso paso a paso, para analizar el comportamiento. Es la mejor manera detectar fallos y mejorar los procesos.

        • Message #817

          Buenas Antonio,

          Primeras pruebas realizadas siguiendo tus pasos. Te comento.

          MASTER:

          Descargado un MASTER arranco el servicio torrent en modo seeder via consola:

          ogTorrentStart CACHE ESEIAATLTSB1819v1193.img.torrent seeder:3600 imagen ya descargada MODE seeder ctorrent [1] 16834 META INFO Announce: http://172.16.1.78:6969/announce Created On: Wed Nov 21 15:10:02 2018 Piece length: 4194304 Comment: 576d6fa907dd42d40cfe13efedc2fe61 Created with: Enhanced-CTorrent/dnh3.3.2 FILES INFO <1> ESEIAATLTSB1819v1193.img [109081620283] Total: 104028 MB Skipping hash checks and forcing seed mode.


          Listening on 0.0.0.0:2706 Press 'h' or '?' for help (display/control client options). Seed for others 72 hours / 0/0/3 [26008/26008/26008] 0MB,0MB | 0,0K/s | 0,0K E:0,280

          CLIENTE

          Lanzo tarea torrent-cache que genera un updateCache que lanzo en consola ssh.

          BCT-TEST# updateCache REPO /ESEIAATLTSB1819v1193.img TORRENT peer:60 [1] /opt/opengnsys/scripts/updateCache REPO /ESEIAATLTSB1819v1193.img TORRENT peer:60 REPO 172.16.1.78 TORRENT peer:60

          TRUE(0), es necesario actualizar. Paso 1, la cache no contiene esa imagen

          TRUE(0), es necesario actualizar. Paso 1, la cache no contiene esa imagen ogCopyFile REPO /ESEIAATLTSB1819v1193.img.torrent absolute /opt/opengnsys/cacheopt/opengnsys/images sending incremental file list ESEIAATLTSB1819v1193.img.torrent

          520.42K 100% 465.06MB/s 0:00:00 (xfr#1, to-chk=0/1)

          sent 520.66K bytes received 35 bytes 1.04M bytes/sec total size is 520.42K speedup is 1.00

          [ ] : 17 seconds

          [ ] : ogTorrentStart CACHE /ESEIAATLTSB1819v1193.img.torrent peer:60

          descarga inicial Donwloading Torrent as peer META INFO Announce: http://172.16.1.78:6969/announce Created On: Wed Nov 21 15:10:02 2018 Piece length: 4194304 Comment: 576d6fa907dd42d40cfe13efedc2fe61 Created with: Enhanced-CTorrent/dnh3.3.2 FILES INFO <1> /opt/opengnsys/cache/opt/opengnsys/images/ESEIAATLTSB1819v1193.img [109081620283] Total: 104028 MB Creating file "/opt/opengnsys/cache/opt/opengnsys/images/ESEIAATLTSB1819v1193.img" Already/Total?: 0/26008 (0%) Files were not present; overriding force mode! Listening on 0.0.0.0:2706 Press 'h' or '?' for help (display/control client options).

          • 0/0/1 [0/26008/0] 0MB,0MB | 0,0K/s | 0,0K E:0,0 Connecting

          \ 0/0/1 [0/26008/0] 0MB,0MB | 0,0K/s | 0,0K E:0,0 Connecting | 1/1/3 [0/26008/26008] 0MB,0MB | 0,0K/s | 0,0K E:0,1 / 1/1/3 [0/26008/26008] 0MB,0MB | 0,0K/s | 0,0K E:0,1

          \ 1/1/3 [4/26008/26008] 16MB,0MB | 9595,0K/s | 9392,0K E:0,1 | 1/1/3 [6/26008/26008] 26MB,0MB | 9885,0K/s | 10432,0K E:0,1 / 1/1/3 [9/26008/26008] 36MB,0MB | 10122,0K/s | 10720,0K E:0,1

          \ 1/1/3 [14/26008/26008] 58MB,0MB | 10369,0K/s | 10768,0K E:0,1 | 1/1/3 [17/26008/26008] 68MB,0MB | 10353,0K/s | 10176,0K E:0,1 / 1/1/3 [19/26008/26008] 79MB,0MB | 10465,0K/s | 11248,0K E:0,1

          \ 1/1/3 [24/26008/26008] 98MB,0MB | 10357,0K/s | 9728,0K E:0,1 Connecting

          He probado a parar el servidor, para verificar que puede descargar solo del MASTER y perfecto. Al volver a arrancarlo no se une a la descarga, pero en nuestro caso es un mal menor, e incluso un comportamiento deseable. Ya que nos libera el servidor para el resto de deploys, evitando además saturación del enlace.

          He probado a variar la velocidad de upload del equipo MASTER y también funciona correctamente.

          Ahora solo me queda probar a fijar el máximo upload en el TRACKER (server) para no saturar el enlace y tendremos operativo el entorno de pruebas para empezar a testear casos y posibles fallos.

          Muchas gracias por la guia!!!

          • Message #818

            Un último detalle, el comando que lanzas en el master ogTorrentStart

            lo podrías sustituir por:

            updateCache REPO /ESEIAATLTSB1819v1193.img TORRENT seeder:3600

            Saludos.

            • Message #822

              Buenas, seguimos con las pruebas.

              ¿con el updateCache grantizamos que en caso de tener el torrent obsoleto lo volvemos a descargar del server?

              Lo que no consigo es meter el parametro "--max_upload_rate 1000" en el lugar correcto al iniciar el servicio de bittornado.

              Modificando los parámetros en /etc/init.d/opengnsys, en Ubuntu 16.04. Tanto en $SEEDERSTART como en $EXTRAOPTS, me da un error de sintaxis al iniciar y no lo carga.

              ¿sabeis exactamente donde hay que colocarlo? ¿entre alguno de los parámetros iniciales que ya existen?

              Nuestro razonamiento será fijarlo al 60% de la capacidad de los enlaces para evitar saturarlos.

              Saludos, Andrés

              • Message #825

                Hola, Andrés. Te respondo:

                • updateCache:
                  Se acaba realizando una llamada a rsync --progress --inplace -avh "$SOURCE" "$TARGET", con que lo que se debería actualizar.
                • opciones para semillero:
                  $SEEDERSTART $BTSEEDER $EXTRAOPTS $BTTORRENTSDIR --max_upload_rate 1000 &>/dev/null $ENDOPTS

                Saludos.

                • Message #828

                  Muchas gracias Baritono,

                  lo había probado pero con comillas "--max_upload_rate 1000" y al arrancar lanzaba un error.

                  updateCache entonces garantiza que el torrent se mantiene actualizado en los clientes aunque se rehaga al hacer el rsync actualizará el cliente que tenga la versión obsoleta.

                  Saludos, Andrés

  • Message #813

    Buenas, Andrés. Para un despliegue vía torrent, necesitas conectarte al tracker (cuya url está en el fichero .torrent) para localizar al resto de peers. Estos pueden informar al tracker de que son seeders sí poseen la imagen completa.

    Aislar cada aula para que sólo se alimente del master que tuvieras en ella lo veo complicado, pues el ogClient no dispone de iptables para filtrar a nivel IP, por lo que los peers se intentarán conectar a cualquier seeder que esté disponible, incluyendo el que reside en el propio repositorio.

    Veo más factible que actúes, dependiendo de lo que necesites, sobre los parámetros del semillero del servidor y del cliente ctorrent. Puedes establecer así un máximo de conexiones y de ancho de banda de subida/descarga. Para el semillero tendrás que modificar /etc/init.d/opengnsys (busca BTSEEDER para ver cuál utilizas) y para el cliente /opt/opengnsys/client/lib/engine/bin/Protocol.lib .

    Echa un vistazo a:

    Saludos

    • Message #815

      Barítono, buenas.

      Gracias por compartir tu experiencia.

      El comportamiento actual de OpenGnsys es crear tantos tracker como repositorios. Cada repositorio hace de tracker de sus imágenes.

      Quizás si Andrés desea que no haya ningún trafico de p2p entre edificios, deberá de establecer repositorios en cada edificio. Y verificar que el torrent de cada repositorio tiene configurado que su tracker sea el repositorio.

      Y también es muy interesante y efectivo como has comentado, limitar la tasa de transferencia en el repositorio. Creo que le vendrá muy bien a Andrés.

      Hay usuarios que instalan en el servicio de monotorización del ctorrent CTS [1] para ajustar el ancho de banda. Según comentan es muy efectivo.

      [1] http://www.rahul.net/dholmes/ctorrent/ctcs.html

      • Message #816

        Muchas gracias a los 2 por vuestras respuestas.

        Tenemos que darle un par de vueltas más al tema porque lo que queríamos eliminar eran los repositorios por edificio. Para minimizar infraestructura.

        La ventaja principal para nosotros con el torrent es que en el tiempo en el que antes realizábamos 10 equipos hemos podido hacer 90 via torrent, utilizando el 60% del ancho de banda del enlace entre edificios.

        Gracias!!!

Attachments

No attachments created.