6 cuellos de botella ocultos en la migración de datos en la nube

Seth Noble es fundador y presidente de Data Expedition.

Mover terabytes o incluso petabytes de datos a la nube es una tarea abrumadora. Pero es importante mirar más allá del número de bytes. Probablemente sepa que sus aplicaciones se comportarán de manera diferente cuando se acceda a ellas en la nube, que las estructuras de costos serán diferentes (con suerte, mejores) y que llevará tiempo mover todos esos datos.

Debido a que mi empresa, Data Expedition, se dedica a la transferencia de datos de alto rendimiento, los clientes acuden a nosotros cuando esperan que la velocidad de la red sea un problema. Pero en el proceso de ayudar a las empresas a superar ese problema, hemos visto muchos otros factores que amenazan con descarrilar las migraciones a la nube si se pasan por alto.

Recopilar, organizar, formatear y validar sus datos puede presentar desafíos mucho mayores que moverlos. A continuación, se muestran algunos factores comunes que se deben tener en cuenta en las etapas de planificación de una migración a la nube, para que luego pueda evitar problemas costosos y que consumen mucho tiempo.

Cuello de botella n. ° 1 en la migración a la nube: almacenamiento de datos

El error más común que vemos en las migraciones a la nube es enviar datos al almacenamiento en la nube sin considerar cómo se utilizarán. El proceso de pensamiento típico es: "Quiero poner mis documentos y bases de datos en la nube y el almacenamiento de objetos es barato, así que pondré mis documentos y archivos de base de datos allí". Pero los archivos, los objetos y las bases de datos se comportan de manera muy diferente. Poner sus bytes en el incorrecto puede paralizar sus planes en la nube.

Los archivos están organizados por una jerarquía de rutas, un árbol de directorios. Se puede acceder rápidamente a cada archivo, con una latencia mínima (tiempo hasta el primer byte) y alta velocidad (bits por segundo una vez que los datos comienzan a fluir). Los archivos individuales se pueden mover, renombrar y cambiar fácilmente hasta el nivel de bytes. Puede tener muchos archivos pequeños, una pequeña cantidad de archivos grandes o cualquier combinación de tamaños y tipos de datos. Las aplicaciones tradicionales pueden acceder a archivos en la nube como lo harían en las instalaciones, sin ningún conocimiento especial de la nube.

Todas estas ventajas hacen que el almacenamiento basado en archivos sea la opción más cara, pero almacenar archivos en la nube tiene algunas otras desventajas. Para lograr un alto rendimiento, solo se puede acceder a la mayoría de los sistemas de archivos basados ​​en la nube (como Amazon EBS) mediante una sola máquina virtual basada en la nube a la vez, lo que significa que todas las aplicaciones que necesitan esos datos deben ejecutarse en una única máquina virtual en la nube. Para dar servicio a varias máquinas virtuales (como Azure Files), es necesario utilizar un protocolo NAS (almacenamiento conectado a la red) como SMB, que puede limitar gravemente el rendimiento. Los sistemas de archivos son rápidos, flexibles y compatibles con versiones anteriores, pero son costosos, útiles solo para aplicaciones que se ejecutan en la nube y no escalan bien.

Los objetos no son archivos. Recuerda eso, porque es fácil de olvidar. Los objetos viven en un espacio de nombres plano, como un directorio gigante. La latencia es alta, a veces cientos o miles de milisegundos, y el rendimiento es bajo, a menudo superando los 150 megabits por segundo a menos que se utilicen trucos inteligentes. Gran parte del acceso a los objetos se reduce a trucos inteligentes como la carga de varias partes, el acceso al rango de bytes y la optimización del nombre de la clave. Los objetos pueden ser leídos por muchas aplicaciones nativas de la nube y basadas en la web a la vez, tanto dentro como fuera de la nube, pero las aplicaciones tradicionales requieren soluciones paralizantes del rendimiento. La mayoría de las interfaces para acceder al almacenamiento de objetos hacen que los objetos parezcan archivos: los nombres de las claves se filtran por prefijo para que parezcan carpetas, los metadatos personalizados se adjuntan a los objetos para que aparezcan como metadatos de archivos,y algunos sistemas como FUSE caché de objetos en un sistema de archivos de VM para permitir el acceso de aplicaciones tradicionales. Pero tales soluciones son frágiles y debilitan el rendimiento. El almacenamiento en la nube es barato, escalable y nativo de la nube, pero también es lento y de difícil acceso.

Las bases de datos tienen su propia estructura compleja y se accede a ellas mediante lenguajes de consulta como SQL. Las bases de datos tradicionales pueden estar respaldadas por almacenamiento de archivos, pero requieren un proceso de base de datos en vivo para atender consultas. Esto se puede llevar a la nube copiando los archivos y aplicaciones de la base de datos en una máquina virtual o migrando los datos a un servicio de base de datos alojado en la nube. Pero copiar un archivo de base de datos en el almacenamiento de objetos solo es útil como copia de seguridad sin conexión. Las bases de datos escalan bien como parte de un servicio alojado en la nube, pero es fundamental garantizar que las aplicaciones y los procesos que dependen de la base de datos sean totalmente compatibles y nativos de la nube. El almacenamiento de la base de datos es altamente especializado y específico de la aplicación.

Equilibrar los ahorros de costos aparentes del almacenamiento de objetos con la funcionalidad de archivos y bases de datos requiere una consideración cuidadosa de exactamente qué funcionalidad se requiere. Por ejemplo, si desea almacenar y distribuir muchos miles de archivos pequeños, archívelos en un archivo ZIP y guárdelo como un solo objeto en lugar de intentar almacenar cada archivo individual como un objeto separado. Las elecciones de almacenamiento incorrectas pueden generar dependencias complejas que son difíciles y costosas de cambiar más adelante.

Cuello de botella de la migración a la nube n. ° 2: preparación de datos

Mover datos a la nube no es tan simple como copiar bytes en el tipo de almacenamiento designado. Se necesita mucha preparación antes de copiar algo, y ese tiempo requiere un presupuesto cuidadoso. Los proyectos de prueba de concepto a menudo ignoran este paso, lo que puede generar costosos sobrecostos en el futuro.

El filtrado de datos innecesarios puede ahorrar mucho tiempo y costes de almacenamiento. Por ejemplo, un conjunto de datos puede contener copias de seguridad, versiones anteriores o archivos temporales que no necesitan ser parte del flujo de trabajo en la nube. Quizás la parte más importante del filtrado es priorizar qué datos deben moverse primero. Los datos que se utilizan activamente no tolerarán estar desincronizados durante las semanas, meses o años que se necesitan para completar todo el proceso de migración. La clave aquí es encontrar un medio automatizado para seleccionar qué datos se enviarán y cuándo, luego mantener registros cuidadosos de todo lo que se hace y lo que no se hace.

Los diferentes flujos de trabajo en la nube pueden requerir que los datos estén en un formato u organización diferente al de las aplicaciones locales. Por ejemplo, un flujo de trabajo legal puede requerir la traducción de miles de documentos pequeños de Word o PDF y empaquetarlos en archivos ZIP, un flujo de trabajo de medios puede involucrar la transcodificación y el empaquetado de metadatos, y un flujo de trabajo bioinformático puede requerir la selección y puesta en escena de terabytes de datos genómicos. Tal reformateo puede ser un proceso intensamente manual y que requiere mucho tiempo. Puede requerir mucha experimentación, mucho almacenamiento temporal y mucho manejo de excepciones. A veces es tentador aplazar cualquier reformateo al entorno de la nube, pero recuerde que esto no resuelve el problema, simplemente lo traslada a un entorno en el que cada recurso que utiliza tiene un precio.

Parte de las preguntas sobre almacenamiento y formato pueden involucrar decisiones sobre compresión y archivo. Por ejemplo, tiene sentido comprimir millones de pequeños archivos de texto antes de enviarlos a la nube, pero no un puñado de archivos multimedia de varios gigabytes. Archivar y comprimir datos facilita la transferencia y el almacenamiento de datos, pero considere el tiempo y el espacio de almacenamiento que se necesita para empaquetar y descomprimir esos archivos en ambos extremos.

Cuello de botella de la migración a la nube n. ° 3: validación de la información

La verificación de la integridad es el paso más importante y también el más fácil de equivocarse. A menudo, se asume que se producirán daños durante el transporte de datos, ya sea mediante medios físicos o transferencia de red, y se pueden detectar realizando sumas de comprobación antes y después. Las sumas de comprobación son una parte vital del proceso, pero en realidad es la preparación e importación de los datos donde es más probable que sufra pérdidas o daños.

Cuando los datos cambian de formatos y aplicaciones, el significado y la funcionalidad se pueden perder incluso cuando los bytes son los mismos. Una simple incompatibilidad entre las versiones de software puede hacer que petabytes de datos "correctos" sean inútiles. Crear un proceso escalable para verificar que sus datos sean correctos y utilizables puede ser una tarea abrumadora. En el peor de los casos, puede convertirse en un proceso manual impreciso y laborioso de "me parece que está bien". Pero incluso eso es mejor que ninguna validación. Lo más importante es asegurarse de que podrá reconocer los problemas antes de que se retiren los sistemas heredados.

Cuello de botella de la migración a la nube n. ° 4: clasificación de transferencias

Al llevar un solo sistema a la nube, es relativamente fácil copiar los datos preparados en un medio físico o enviarlos a través de Internet. Pero este proceso puede ser difícil de escalar, especialmente para medios físicos. Lo que parece "simple" en una prueba de concepto puede convertirse en una "pesadilla" cuando entran en juego muchos y variados sistemas.

Un dispositivo de medios, como una AWS Snowball, debe estar conectado a cada máquina. Eso podría significar caminar físicamente con el dispositivo por uno o más centros de datos, hacer malabares con los conectores, actualizar los controladores e instalar software. La conexión a través de la red local evita el movimiento físico, pero la configuración del software aún puede ser un desafío y la velocidad de copia puede caer muy por debajo de lo que se podría lograr con una carga directa a Internet. La transferencia de datos directamente desde cada máquina a través de Internet ahorra muchos pasos, especialmente si los datos están listos para la nube.

Si la preparación de datos implica copiar, exportar, reformatear o archivar, el almacenamiento local puede convertirse en un cuello de botella. Puede que sea necesario configurar un almacenamiento dedicado para organizar los datos preparados. Esto tiene la ventaja de permitir que muchos sistemas realicen la preparación en paralelo y reduce los puntos de contacto para los medios de envío y el software de transferencia de datos a un solo sistema.

Cuello de botella de la migración a la nube # 5: transferencia de datos

Al comparar la transferencia de red con el envío de medios, es fácil centrarse solo en el tiempo de envío. Por ejemplo, un dispositivo AWS Snowball de 80 terabytes podría enviarse por mensajería al día siguiente, logrando una velocidad de datos aparente de más de ocho gigabits por segundo. Pero esto ignora el tiempo que lleva adquirir el dispositivo, configurarlo y cargarlo, prepararlo para la devolución y permitir que el proveedor de la nube copie los datos en el back-end. Nuestros clientes que hacen esto regularmente informan que los tiempos de respuesta de cuatro semanas (desde el pedido de dispositivos hasta los datos disponibles en la nube) son comunes. Eso reduce la tasa de transferencia de datos real de envío del dispositivo a solo 300 megabits por segundo, mucho menos si el dispositivo no está completamente lleno.

Las velocidades de transferencia de la red también dependen de varios factores, siendo el principal el enlace ascendente local. No puede enviar datos más rápido que la velocidad de bits física, aunque una preparación cuidadosa de los datos puede reducir la cantidad de datos que necesita enviar. Los protocolos heredados, incluidos los que los proveedores de la nube utilizan de forma predeterminada para el almacenamiento de objetos, tienen dificultades con la velocidad y la confiabilidad en las rutas de Internet de larga distancia, lo que puede dificultar el logro de esa tasa de bits. Podría escribir muchos artículos sobre los desafíos involucrados aquí, pero este es uno que no tiene que resolver usted mismo. Data Expedition es una de las pocas empresas que se especializa en garantizar que la ruta se utilice por completo, independientemente de qué tan lejos estén sus datos de su destino en la nube. Por ejemplo, una conexión a Internet gigabit con software de aceleración como CloudDat produce 900 megabits por segundo,tres veces el rendimiento neto de una AWS Snowball.

La mayor diferencia entre el envío físico y la transferencia de red es también una de las que más se pasa por alto durante la prueba de concepto. Con el envío físico, el primer byte que carga en el dispositivo debe esperar hasta que se cargue el último byte antes de que pueda enviarlo. Esto significa que si lleva semanas cargar el dispositivo, algunos de sus datos estarán desactualizados por semanas para cuando lleguen a la nube. Incluso cuando los conjuntos de datos alcanzan niveles de petabytes en los que el envío físico puede ser más rápido en general, la capacidad de mantener actualizados los datos prioritarios durante el proceso de migración aún puede favorecer la transferencia de red para activos clave. La planificación cuidadosa durante la fase de filtrado y priorización de la preparación de datos es esencial y puede permitir un enfoque híbrido.

Es posible que la transferencia de datos a un proveedor en la nube no sea el final del paso de transferencia de datos. Si necesita replicarse en varias regiones o proveedores, planifique cuidadosamente cómo llegará allí. La carga a través de Internet es gratuita, mientras que AWS, por ejemplo, cobra hasta dos centavos por gigabyte por la transferencia de datos interregionales y nueve centavos por gigabyte por la transferencia a otros proveedores de la nube. Ambos métodos enfrentarán limitaciones de ancho de banda que podrían beneficiarse de la aceleración del transporte como CloudDat.

Cuello de botella de la migración a la nube n. ° 6: escalamiento de la nube

Una vez que los datos llegan a su destino en la nube, el proceso de migración solo está a medio terminar. Las sumas de comprobación son lo primero: asegúrese de que los bytes que llegaron coincidan con los que se enviaron. Esto puede ser más complicado de lo que imagina. El almacenamiento de archivos utiliza capas de cachés que pueden ocultar la corrupción de los datos que se acaban de cargar. Tal corrupción es poco común, pero hasta que haya borrado todas las cachés y vuelva a leer los archivos, no puede estar seguro de ninguna suma de verificación. Reiniciar la instancia o desmontar el almacenamiento hace un trabajo aceptable de borrar las cachés.

La validación de las sumas de comprobación de almacenamiento de objetos requiere que cada objeto se lea en una instancia para el cálculo. Contrariamente a la creencia popular, las “etiquetas electrónicas” de objetos no son útiles como sumas de verificación. Los objetos cargados mediante técnicas de varias partes en particular solo se pueden validar volviéndolos a leer.