SPONSORED

ABOUT THIS PODCAST

Podcast de tecnologia para sysadmins y devops
Spanish
Argentina
38 episodes
since July 14, 2016

LATEST EPISODE

Te doy la bienvenida al episodio 37 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 2 de mayo de 2019. Hace un rato que no deployo una edición del podcast, confío que a partir de ahora poder hacerlo en forma en forma periódica. Por supuesto, que siempre puedes seguir cuando sale una edición nueva a través de twitter o instagram @deployandome, o escuchar con tu aplicación de podcast preferida, porque tendrá mucho espacio entre ediciones, pero seguro está en todos lados que he conseguido publicarlo. Me ha sucedido muchas veces que me piden replicar, copiar, espejar los archivos de una carpeta en otro servidor. Generalmente cuando se desea tener una contingencia pasiva del servicio que presta un servidor, es decir, que el servidor principal recibe archivos y se copian a un segundo equipo como contingencia si el primero falla. No creo que esta sea una situación muy excepcional ya que personalmente me ha pasado unas cuantas veces y estamos hablando aquí de algo adicional a un método de respaldos. Mientras que un respaldo habilita puntos de recuperación históricos, sincronizar archivos entre servidores, de mantener un espejo de un servidor en otro. Si has estado en la situación de armar una solución que cumpla estos requerimientos, me inclino a pensar que optaste por lo que siempre suelo optar en primer lugar: por rsync. rsync es una herramienta espectacular para hacer esta sincronización. Cada vez que se corre rsync compara los archivos del origen con el destino y trasmite solamente los diferenciales binarios. Rsync copiará obviamente los archivos nuevos, puede borrar los que no existen más en el origen, pero no copiará los archivos que han cambiado; lo que hace rsync obtener hashes de trozos de los archivos y comparar con el hash correspondiente en destino, si e hash coincide procesa el pedazo siguiente y si no coincide, transfiere el pedazo hasta igualarlo en el destino. Al final los archivos quedan idénticos. Por esta funcionalidad rsync es muy apreciado a la hora de copiar archivos grandes sobre redes que pueden introducir errores o cortes de comunicación, pues cuando la tarea finalice puedes estar seguro que los archivos son iguales. Pero rsync tiene un problema bastante grave: no escala. Si tengo una carpeta con 100 archivos rsync revisará cada uno buscando diferencias y si están iguales finaliza su tarea, para esto demora algunos segundos. Ahora supongamos que estmos frente a una una carpeta con 4 millones de archivos, como ya me ha pasado, y supongamos también que solo un archivo ha cambiado o es nuevo, entonces rsync revisara los 3.999.999 archivos iguales y sincronizará solo el archivo que ha cambiado, para lo cual seguramente demorará... si, muchas horas. Por lo tanto hay un problema de escala donde rsync deja de ser óptimo por el tiempo que demora, necesitamos algo más inteligente ... y de eso, te voy a contar en esta edición de deployandome Si has seguido la explicación anterior, te habrás dado cuenta que el problema de escala que tiene rsync se soluciona dándole inteligencia como para evitar procesar archivos que ya han sido copiados a destino. Y como todo en ingeniería, la solución para este problema puede ser abordada desde distintas enfoques. Un enfoque simple, es decirle a rsync que si el archivo existe en destino lo considere como idéntico y no lo revise por pedazos para saber si hay cambios. Esto se logra con la opción --ignore-existing de rsync, que es ideal, por ejemplo, cuando tenemos la carpeta donde los usuarios de un sitio web suben su foto de perfil; estos archivos no se modifican, lo qu
SPONSORED
Disclaimer: The podcast and artwork embedded on this page are from Rodolfo Pilas, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.

PODCAST IS CLAIMED

This podcast page is claimed and managed by @deployandome

EDIT

Thank you for helping to keep the podcast database up to date.
SPONSORED

RECOMMENDATIONS

SPONSORED