Archivo

Entradas Etiquetadas ‘scp’

Optimizando copia de archivos grandes con scp

Jueves, 19 de febrero de 2009

Ya antes les había comentado sobre una técnica para copiar varios archivos de manera más eficiente. Ahora les voy a mostrar como copiar un archivo grande usando scp.

Primero veamos una copia normal con scp:

auyan:Downloads josevnz$ time scp SentillaWork-1.1.1.tar 10.0.1.198:/Users/josevnz/Downloads/
SentillaWork-1.1.1.tar                                                                                                     100%  295MB 504.9KB/s   09:58

real    10m4.025s
user    0m8.129s
sys    0m3.263s

10 minutos para 295MB. No está tan mal para una red inalambrica. Sin embargo si aplicamos estos dos trucos juntos:

  1. Aplicamos un algoritmo de encriptación débil, dado que no nos importa mucho que el contenido sea interceptado y analizado. Si tardamos menos tiempo cifrando los datos y más enviandolos eso es bueno.
  2. Comprimimos los datos a medida que los enviamos en la red. Siempre es bueno enviar menos (el lado malo es que el CPU de ambos lados trabajará más pero eso no es un grave inconveniente).

En OpenSSH estos dos parametros con ‘-c arcfour’ (blowfish también es bueno) y -C (-C utiliza gzip por omisión). Probando de nuevo:

auyan:Downloads josevnz$ time scp -C -c arcfour SentillaWork-1.1.1.tar 10.0.1.198:/Users/josevnz/Downloads/
SentillaWork-1.1.1.tar                        100%  295MB 852.9KB/s   05:54

real    5m56.157s
user    0m19.166s
sys    0m2.916s
auyan:Downloads josevnz$

¡5 minutos nada más! Una mejora substancial.

Recuerde que también usted puede emplear este truco con ssh y muchos archivos:

tar cf – * | ssh -C -c archfour “cd $HOME && tar -xf -)

Sin embargo siempre existen maneras de mejorar el resultado. ¿Existe otra forma? En otra entrega les comentaré como hacer el proceso aún más rápido.
Veneblogs: , , ,

Blogalaxia: , , ,

To2blogs: , , ,

Technorati: , , ,

Del.icio.us: , , ,

opensource , , ,

Distribución de archivos en una granja de servidores: ¿Hay algo mejor que NFS por allí?

Viernes, 21 de noviembre de 2008

Mi problema es el siguiente: Tengo que distribuir archivos de manera rutinaria a más de 500 servidores los cuales corren Linux / Solaris. Ninguno de ellos es mayor de 10 MB por si sólo, pero tengo muchisimos de ellos y la distribución de los archivos debe ser lo más rapida posible además de tener cierta tolerancia a fallos.

Por ahora estas son mis opciones:

NFS: Más vale diablo por viejo que por diablo
NFS es muy conveniente; Es fácil de compartir información, y sin embargo tiene problemas de desempeño y seguridad. Si usted tiene una aplicación que requiere compartir datos com más de 500 servidores entonces ya seguramente sabe de lo que estoy hablando.

¿Entonces como se puede reemplazar a NFS? Una de las opciones más atractivas es AFS. El problema es que es más complejo de administrar, y esa es una barrera dificil de superar en el mundo corporativo (ojo, muchas compañias grandes lo utilizan).

Rsync: Preparence a escribir scripts

Rsync utiliza un novedoso algoritmo el cual envia por la red solamente diferencias entre el destino y la fuente, lo cual lo hace muy eficiente. Sin embargo si usted quiere utilizarlo para duplicar información entonces seguro se verá escribiendo un shell script para adaptarlo a sus necesidades. Otros inconvenientes: Si usted tiene muchos archivos entre la fuente y el destino entonces deberá esperar un buen tiempo mientras rsync decide que copiar. Otro problema es que es considerado inseguro por muchos administradores de sistemas (los cuales prefieren no lidiar con su configuración adecuada).

Secure Copy / Secure FTP: Scripts y la historia de la tortuga

¿Y que tal scp or sftp? Trabaja bien, es muy seguro pero no es más rápido que rsync. Preparese a echar código si quiere una solución a la medida. Por otro lado rsync y ssh pueden trabajar juntos (opción -rsh=ssh de rsync).

P2P: Suena bien, pero ¿sólo en papel?
Yo en particular no he visto casos de como distribuir archivos en una red corporativa usando P2P. Java en particular tiene su estandar llamado JXTA pero no he visto mucha acción allí. Algunos ejemplos interesantes incluyen el uso de clientes como Azureus los cuales utilizan el protocolo Bittorrent para lograr su cometido.

¿Y entonces, qué hago?

Por ahora estoy utilizando una combinación de NFS, Rsync y scp para copias pequeñas. Sin embargo estoy seguro de que existe una mejor manera de hacer esto.

¿Y ustedes conocen una mejor solución a este problema?

Buscar en otros sitios:

Blogalaxia:, , , , ,
Technorati:, , , , ,
To2blogs:, , , , ,
Del.icio.us:, , , , ,

Sin categoría , , , ,