Mejorando transferencia de ssh/rsync

Buscando la forma de mejorar la transferencia de backups (realizados con rsync, pero sobre un tunel de SSH), encontré que la velocidad de transferencia puede variar mucho dependiendo del cipher usado para crear la conexión con SSH.

En una primera búsqueda encontré unos tests que reproduje en mi ambiente. Las pruebas que hice consiste en copiar un archivo con contenidos aleatorios (generado desde /dev/urandom), de 512MB, sobre una conección Gigabit Ethernet, estando el archivo de origen y el de destino en el directorio /dev/shm (esto nos permite asegurarnos que el acceso a disco no influya en nuestros tests):


Warm up... Copiando con cipher por default...
random                           100%  512MB  42.7MB/s   00:12    

Copiando con cipher: 3des-cbc
random                           100%  512MB  16.5MB/s   00:31    

Copiando con cipher: aes128-cbc
random                           100%  512MB  85.3MB/s   00:06    

Copiando con cipher: aes192-cbc
random                           100%  512MB  73.1MB/s   00:07    

Copiando con cipher: aes256-cbc
random                           100%  512MB  64.0MB/s   00:08    

Copiando con cipher: aes128-ctr
random                           100%  512MB  42.7MB/s   00:12    

Copiando con cipher: aes192-ctr
random                           100%  512MB  34.1MB/s   00:15    

Copiando con cipher: aes256-ctr
random                           100%  512MB  32.0MB/s   00:16    

Copiando con cipher: arcfour128
random                           100%  512MB 102.4MB/s   00:05    

Copiando con cipher: arcfour256
random                           100%  512MB 102.4MB/s   00:05    

Copiando con cipher: arcfour
random                           100%  512MB 102.4MB/s   00:05    

Copiando con cipher: blowfish-cbc
random                           100%  512MB  56.9MB/s   00:09    

Copiando con cipher: cast128-cbc
random                           100%  512MB  51.2MB/s   00:10    

Luego probé copiar a "localhost":

Warm up... Copiando con cipher por default...

random                               100%  512MB  56.9MB/s   00:09    

Copiando con cipher: 3des-cbc

random                               100%  512MB  20.5MB/s   00:25    

Copiando con cipher: aes128-cbc

random                               100%  512MB 170.7MB/s   00:03    

Copiando con cipher: aes192-cbc

random                               100%  512MB 170.7MB/s   00:03    

Copiando con cipher: aes256-cbc

random                               100%  512MB 170.7MB/s   00:03    

Copiando con cipher: aes128-ctr

random                               100%  512MB  64.0MB/s   00:08    

Copiando con cipher: aes192-ctr

random                               100%  512MB  51.2MB/s   00:10    

Copiando con cipher: aes256-ctr

random                               100%  512MB  46.6MB/s   00:11    

Copiando con cipher: arcfour128

random                               100%  512MB 256.0MB/s   00:02    

Copiando con cipher: arcfour256

random                               100%  512MB 256.0MB/s   00:02    

Copiando con cipher: arcfour

random                               100%  512MB 170.7MB/s   00:03    

Copiando con cipher: blowfish-cbc

random                               100%  512MB  64.0MB/s   00:08    

Copiando con cipher: cast128-cbc

random                               100%  512MB  56.9MB/s   00:09    

El ganador en velocidad, es por mucho arcfour, pero por lo que he visto, no es recomendable usarlo cuando la seguridad es un factor crítico. El cipher aes128 es algo más lerdo, pero la taza de transferencia es de más del doble comparada al cipher por default.

Para usar un cipher específico con rsync + ssh, el comando a usar tendría la forma:

$ rsync -e 'ssh -c arcfour256' ......

El script que usé lo subí a un gist de GitHub.

Pentaho: primeros pasos con ETL, Kettle, Spoon, PDI

Mis primeros pasos en BI con Pentaho no fueron de lo más fácil. Hay mucha información, es un tema nuevo para mi (estoy aprendiendo a la vez BI y Pentaho), el producto posee una edición Open Source y otra cerrada, y diferentes nombres para cosas parecidas (por ejemplo: Kettle, Spoon, PDI/Pentaho Data Integration).

Así que en este artículo compartiré los pasos que seguí para hacer andar las herramientas necesarias para realizar el proceso de ETL (el artículo de WikiPedia sobre Data Warehouse es una muy buena referencia para un vistazo general).

El mejor tutorial para darlos primeros pasos que encontré es PDI / Pentaho Data Integration / Kettle. Los 4 pasos están muy bien explicados, aunque me topé con algunos inconvenientes, por eso incluyo links a los 4 pasos del turorial, con algunos comentarios:

01. Installing Kettle - Comentarios: lo bajé de aquí: PDI / Kettle 4.3 (la más reciente versión al momento de escribir el artículo). Actualmente, la versión que está disponible es referenciada desde algunas páginas como "Kettle 4.3.0 including Big Data Components", y el archivo se llama "pdi-ce-4.3.0-stable.tar.gz" o "pdi-ce-4.3.0-stable.zip" (dependiendo si se quiera bajar como tar.gz o zip).

02. Spoon Introduction - Comentarios: luego de descomprimirlo y lanzar Spoon, se abrío una instancia de Firefox y una aplicación Java. Entre los links que veo en Firefox, creo que el más relevante es Spoon User Guide.

03. Hello World Example - Comentarios: este paso desarrollamos un ejemplo completo de ETL. Tuve problemas en "Modified JavaScript Value Step", ya que al parecer, la línea que contiene:

name.getString()

no funciona correctamente, pero lo pude arreglar usando:

name.toString()

Al llegar a probar el "pan", para obtener la lista de modificadores aceptados, hay que ejecutar:

./pan.sh

(sin ningún modificador... primero intenté con -h y --help, pero esto no funciona). Hay más información en la página de Pan User Documentation.

En el caso de Linux, para especificar los modificadores del programa se usa "-" en vez de "/":

./pan.sh -norep -file ../ejemplo1/tutorial.ktr

04. Refining Hello World - Comentarios: el igual que con "pan.sh", en Linux, para especificar los modificadores de kitchen.sh se usa "-" en vez de "/". Además, no seguí al pié de la letra las instrucciones; particularmente, prefiero evitar la parametrización a través de "kettle.properties", y en su lugar, utilicé para los paths, la variable ${Internal.Job.Filename.Directory}.

Finalmente, después de renegar un rato, pude ejecutar correctamente el job desde la línea de comando (usando kitchen).

Como resumem, puedo decir que seguir el tutorial me dejó claro varias cosas:

• "Big Data components" se refiere al hecho de que pueden leerse y escribirse datos de/a Hadoop, Cassandra, etc., pero es algo que no usaremos inicialmente,
• Spoon es la herramienta gráfica para diseñar procesos de ETL,
• Pan y Kitchen permiten ejecutar los procesos de ETL desde la línea de comando (por lo tanto, sería una forma de automatizar estos procesos desde, por ejemplo, cron, aunque supongo que debe haber algún componente para realizar el scheduling de estas tareas),
• Kettle es lo mismo que PDI, que significa "Pentaho Data Integration", que incluye a todo lo anterior: herramientas visuales, CLI, todas las librerías que implementan las funcionalidades que tan fácilmente se utilizan desde Spoon.

Modificando el último commit con git rebase

Algunas veces, luego de hacer un commit, vemos que olvidamos algún pequeño detalle, y por cuestiones de "prolijidad", hubiéramos querido incluirlo en el commit recién realizado.

Generalmente, en estos casos utilizo git reset --soft HEAD^ para recuperar el commit anterior, pero siempre me pareció que debería haber alguna forma mejor. Utilizando rebase, el proceso es mucho más fácil, ya que evitamos, por ejemplo, re-ingresar el mensaje de commit, con la posibilidad de modificarlo si hace falta.

Los comandos a utilizar son:

$ git rebase --interactive HEAD^

Ahora git presentará un editor, donde mostrará una línea con el commit a editar, por ejemplo:

pick 9245320 Cambios en home: agregue nombre de usuario logueado

Hay que cambiar esta línea, reemplazando "pick" por "edit". 

edit 9245320 Cambios en home: agregue nombre de usuario logueado

Luego aparecerá:

Stopped at 9245320... Cambios en home: agregue nombre de usuario logueado
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

$ git add <archivos modificados>


$ git rebase --continue

Este último comando nos presentará el editor de texto con el mensaje de commit original, el que podremos modificar si hace falta.