Wednesday, December 07, 2011

Protección de datos mediante códigos de redundancia

Muchos de nosotros somos usuarios habituales de utilidades de compresión de datos como 7zip o gzip, pero llegado el momento de realizar un backup la fiabilidad de los datos se vuelve tanto o más importante que el tamaño.

dvdisaster working on a damaged CD
Dvdisaster en pleno proceso de reconstrucción
Es por ello que utilidades como dvdisaster nos ayudan a proteger la información que almacenamos en CDs, DVDs o incluso discos Blu-Ray mediante códigos de redundancia Reed-Solomon. Si a la hora de grabar un DVD de 4,7GB de capacidad lo llenásemos con aproximadamente 4GB de datos y añadiésemos el resto con datos de redundancia estaríamos protegiendo el dvd ante algo más que serios arañazos, deterioros causados por luz ultravioleta o simplemente el paso del tiempo. 

Otra utilidad altamente interesante es par2 (Parity Archive), pues permite crear ficheros de redundancia adicionales que pueden ser utilizados posteriormente para reconstruir archivos parcialmente dañados. Interfaces gráficas como la de QuickPar en Windows o PyPar2 en Linux facilitan la creación, verificación o reconstrucción de datos mediante estos archivos de extensión ".par2". 

Imaginemos que creamos algunos ficheros par2 con redundancia suficiente como para proteger varios cientos de imágenes almacenadas en un directorio compartido. Años después podremos detectar si alguna de estas imágenes o sus etiquetas exif han sido modificadas, en cuyo caso tendremos la opción  de reconstruir las imágenes para devolverlas a su estado original.

Saturday, May 21, 2011

IPv6 Readiness Assesment

Consultando documentación sobre la conocida herramienta de red IT Guru Network Planner de OPNET acabo de redescubrir una perla que llevaba largo tiempo buscando.

IPv6 IT Guru CompressorSe trata del módulo denominado “IPv6 Planning and Operations”, el cual puede servirnos de una fantástica ayuda si estamos interesados en la realización de evaluaciones y auditorias de IPv6 con el objetivo de facilitar los despliegues.

Todo ello en tan sólo 5 sencillos pasos:
   1.- Documenta la red
   2.- Evalúa la disponibilidad de IPv6
   3.- Diseña la migración a IPv6
   4.- Predice el impacto de la migración
   5.- Genera informes de conclusiones

Lo único que todavía me sigue dejando intranquilo es que no logro entender porqué OPNET ahora parte de Riverbed al igual que otros muchos fabricantes se empeñan en seguir queriendo vendernos el concepto de "migración a IPv6" cuando en realidad dudo mucho que la mayoría de empresas, universidades y mucho menos los ISPs se puedan permitir el lujo de olvidarse completamente de IPv4, pues ambos protocolos están condenados a convivir durante décadas.

Thursday, May 05, 2011

OpenDNS bajo IPv6

OpenDNS: Servidores de DNS gratuitos ahora también disponibles a través de IPv6 (2620:0:ccc::2 & 2620:0:ccd::2)

Wednesday, May 04, 2011

Zsync: Alternativa a rsync para sincronizar grandes ficheros

Siempre me he sentido atraído por la elegancia con la que rsync solventa mediante algoritmos tipo ‘window checksum’ la necesidad de descargar grandes ficheros partiendo de versiones parciales.

Sin embargo rsync ahorra ancho de banda permitiendo intercambiar únicamente los bloques de datos modificados enviándolos de forma incremental (llamados deltas) a costa de un consumo elevado de CPU tanto en el cliente como el servidor.
 
Este elevado consumo de procesador tanto en la aplicación cliente como en el servidor tiene el grave inconveniente de no escalar adecuadamente, pues unos pocos clientes concurrentes son capaces de saturar a un servidor no excesivamente potente.

En el modelo de distribución actual de servicios, es muy habitual encontrarnos con que un fichero voluminoso, digamos una imagen de CD o DVD de una distribución de Linux debe ser descargada por múltiples clientes. De esta forma si en vez de tener que hacer los pesados cálculos computacionales de checksums de bloques una y otra vez, el servidor almacenase esta información en algún otro sitio, la ganancia sería enorme.

Pues bien, zsync permite hacer justamente esto, en el servidor se computan una sola vez los checksums necesarios y se almacenan en un fichero adicional con extensión .zsync. Este fichero .zsync es consultado por los clientes que desean sincronizar y son ellos los únicos que realizan los cómputos necesarios para averiguar que bloques han de descargar. Una vez la versión zsync que corre en el cliente conoce los bloques que ha de descargar, esta procede a descargarlos mediante el protocolo HTTP 1.1 abriendo múltiples conexiones simultáneas para obtenerlos.

Imaginemos un escenario bastante frecuente.

Tras haber descargado la versión Alternate del CD de Ubuntu 11.04 a 64 bits. Posteriormente cambiamos de idea y preferimos la versión server. Aunque ambas imágenes .iso son distintas muchos de los paquetes de ambas versiones serán los mismos por lo que es de esperar que ambos ficheros tengan algunas partes comunes, de hecho en este caso con zsync nos ahorramos descargar casi la mitad del contenido de nuevo.

En este caso, como el 48.9% del contenido de la versión server era igual a la de la versión alternate que ya habíamos descargado, nos hemos ahorrado descargar 357 MB.

Por cierto, el comando fue algo tan simple como:
$ zsync -i ubuntu-11.04-alternate-amd64.iso http://releases.ubuntu.com/releases/11.04/ubuntu-11.04-server-amd64.iso.zsync
zsync, rsync, jigdo, metafiles, torrents, ... todos ellos intentan atajar el problema de distribuir grandes ficheros por la red a miles de usuarios, pero cada una tiene sus propias particularidades, ¿Para vosotros cuál es la mejor de ellas, alguna preferencia?

Sunday, April 24, 2011

Números asombrosos de IPv6

Por el momento el protocolo IPv6 se sigue viendo como el eterno sustituto de IPv4 para aliviar el problema de las cada vez más escasas direcciones de internet.

Sin embargo uno se pregunta como de grande es el espacio de direcciones de IPv6 como para garantizar que no nos volvemos a quedar sin más IPs en otros 40 años.
El espacio de direcciones de IPv6 es de 2^128, es decir del orden de 3,4*10^38 (340.282.366.920.938.463.463.374.607.431.768.211.456 direcciones IP)

Veamos cuanto de grande es este espacio de direcciones IPv6:
  • Hay suficientes direcciones como para asignar varios miles de billones de direcciones IP por cada ser humano sobre el planeta.
  • Se podría asignar una dirección IP a cada grano de arena del planeta Tierra y aún quedarían algunas por asignar.
  • Si representásemos el espacio de direcciones de IPv4 en un cuadro de 4 centímetros de lado, el cuadro de las direcciones IPv6 tendría el tamaño aproximado de nuestro sistema solar.
  • Si desde que empezó a formarse el planeta Tierra si se hubiesen asignado IPs al ritmo de 1.000 millones por segundo, ni siquiera se habría llegado a consumir ni la mil billonésima parte del espacio de direcciones total.
  • Teniendo en cuenta el tamaño de la superficie de la Tierra y el tamaño actual de los ordenadores de sobremesa, si cada uno tuviese una dirección IPv6 no bastaría con cubrir la superficie entera de la Tierra (mares incluídos) con PCs para agotar las direcciones IPs sino que habría que apilarlos uno encima de otro hasta formar columnas de 10.000 millones de PCs de alto.
Espero haber despejado las dudas de los lectores que pensaban que gracias a IPv6 volveríamos a aguantar unas pocas décadas más antes de agotar todas las IPs.

Sunday, April 17, 2011

IPv6 Ready?

En Telco los fabricantes hablan mucho de LTE como la próxima generación móvil, pero apenas nadie habla de IPv6 cuando en realidad ésta se basa exclusivamente en IPv6.

Sin embargo esta ceguera parece estar bastante extendida y muy pocos están preparados ya para la transición a IPv6 lo cual ocasionará mayores costes de integración que de otra forma podrían haberse evitado.

Quizá mi entusiasmo por IPv6 esté enturbiando mi juicio, por lo que aquí lanzo una pregunta:

  • ¿Es todavía temprano y se debe esperar a que se agoten las direcciones IP antes de saltar a IPv6?