Recuerdo el primer día en clase de redes cuando el profesor nos dijo “no desestiméis el ancho de banda de un camión lleno de CDs”. Eso mismo debió pensar alguien en AWS cuando pusieron en marcha su servicio de Snowball.

Lo cierto es que muchas veces había escuchado hablar a los de Consultoría en mi compañía de la solución Snowball, si bien hasta hace poco no he podido demostrar la existencia del mítico artefacto.

Recientemente, conseguimos un proyecto para la migración completa de los sistemas del archivo digital a AWS. Se trata de un proyecto interesantísimo por el cual el cliente podrá garantizar la disponibilidad de los vídeos, noticias, fotografías y demás contenido para el acceso de sus usuarios, facilitándoles una plataforma always-on y con el menor coste.

El problema vino cuando hicimos el cálculo del tiempo que tendría pasar los 150TB (terabytes) de información y el impacto que esta subida tendría penalizando el ancho de banda que dicho medio tenía contratado. Partiendo de los 150 TB , esto supone 1.200.000 Gb (gigabits) y teniendo en cuenta que el cliente dispone de una línea de 1 Gbps (gigabits por segundo), el cálculo nos daba que supuesta un coeficiente de retransmisión y gestión de errores del 40%, que necesitaríamos 23,15 días en los que el cliente estaría sin poder hacer nada más con su acceso internet que subir todo su archivo digital… Esto es, el proyecto no era viable.

Volviendo a una de las preguntas del examen de certificación de AWS, recordé que era el momento de probar la existencia del famoso Snowball. Me puse manos a la obra:

Entré al portal de AWS, y poniendo en el buscador Snowball encontramos fácilmente el servicio:

Una vez en él, procedemos a configurarlo. Tenemos 3 soluciones, una para importar datos a AWS, otro para exportarlos y otro que nos permite tener un entorno híbrido. En nuestro caso será una tarea de importación:

Lo siguiente es introducir la dirección a la cual queremos que llegue el Snowball y el tipo de envío, el estándar que tarda entre 3-7 días o el Express que tarda de 1-2 días.

Ahora debemos elegir el tipo de Snowball que queremos que nos envíen. Cuando yo hice el trabajo, solo había un par de opciones, de 80TB y 100TB, sin embargo, hace muy poco han añadido Snowball optimizados, como podemos ver en la siguiente captura, pero además ahora tenemos la capacidad de cargar de AMIs (imagenes virtuales de máquinas de AWS) en el Snowball y tener un datacenter portátil… esto lo comentaremos en posteriores posts, pero centrémonos en la importación.

Una vez seleccionado el tipo de Snowball, en nuestro caso el Normal de 80TB, tenemos que seleccionar también el bucket de S3 donde queremos que terminen nuestros datos.

Pasamos a la parte de la seguridad de nuestros datos. Primero tenemos que crear un rol de IAM, para dar permisos al Snowball sobre nuestros recursos, por ejemplo, subir ficheros a un bucket en concreto.

También tenemos que crear una clave KMS para encriptar nuestros datos mientras están almacenados en el Snowball:

Configurado esto, elegiremos si queremos recibir notificaciones por correo o SMS, revisamos que todo esté bien y pedimos nuestro dispositivo.

En la siguiente pantalla que nos aparezca, podremos descargarnos nuestro manifiesto y podremos ver nuestra clave para posteriormente iniciar la copia de los datos.

Tardó 3 días en llegar, pero fue tan sencillo como la recepción de los pedidos de Amazon en la oficina que recibe todos los días Iván en Enimbos. Nos lo entregaron en la oficina, sin ninguna caja, y con todos los cables necesarios para su conexión, tanto los RJ45 tradicionales como uno de fibra.

Una vez recibido, me desplacé junto con un par de compañeros al datacenter a conectarlo. Lo primero que hay que hacer es configurar la red del Snowball, tenemos que conectarlo a un switch y que obtenga la IP por DHCP o podemos configurarla también manualmente.

Vamos a cargar el manifiesto y la clave en nuestro servidor, para que este pueda establecer una conexión cifrada con el Snowball, y empezamos con la transmisión de datos.

Si estamos familiarizados con la CLI de AWS, para transmisiones a S3, nos será muy sencillo, este es el comando del Snowball: snowball cp [OPTION…] SRC… s3://DEST

Por ejemplo, para copiar todo nuestro NFS al Snowball, usamos el siguiente comando: snowball cp –recursive /NFS s3://lab-enimbos

Ponemos a nuestro Snowball a copiar y nos aparecerá en pantalla el progreso de la copia.

Cuando termine la copia, lo único que tenemos que hacer es llamar al mensajero para que venga a por él y ya sabrá a donde llevárselo porque estará en pantalla la etiqueta de envío.

Estamos en la era de los youtubers y los influencers, de los contenidos digitales, que son cada vez de mayor calidad y tamaño, por lo cual se convierte en un reto almacenar y compartir estos contenidos de forma rápida y sencilla.

Para eso tenemos a AWS que es experto en proveer soluciones para los retos más grandes como subir 50TB de videos en un tiempo récord.

Posee una conexión ultrarápida de 10Gbs para transferir varios TB en un par de días contando el tiempo de envío, un millón de veces los datos mensuales que puedes transferir con tu tarifa típica de datos 4G y varias capas de encriptación para que tus datos viajen de forma segura hasta su destino

También piensan en la durabilidad por lo que es muy resistente y portable, le puedes dar hasta patadas porque soporta aceleraciones de hasta 6G.

En Enimbos somos expertos en soluciones Cloud, por lo que utilizamos productos como Snowball para el transporte de los datos de nuestros clientes al cloud, y si no te llega con 100TB, siempre se puede contratar el Snowmobile, un camión que envían a tu datacenter con un contenedor reforzado de 13,71 metros de longitud y es capaz de transferir hasta 100 PB (petabyte), algo que si tuvieses que hacer por internet sería imposible por el tiempo que tardaría (años).

Quizá con nuestro siguiente cliente ya no nos llegue con un par de Snowball y podamos probar el Snowmobile. ¿Quién será el conductor?

About Miguel Camba

Cloud Engineer. Miguel is studying a degree in Information Systems at Politechnic University of Madrid, and he has AWS Certification Exam Readiness Workshop: AWS Certified Solutions Architect – Associate, 533 Exam: Implementing Microsoft Azure Infrastructure Solutions and in 535 Exam: Architecting Microsoft Azure Solutions. He started his professional career as Head of Information Technology at Complutense University of Madrid, and in 2017 he joined Enimbos as Cloud Engineer.