La tecnología de contenedores se ha convertido en uno de los grandes focos de atención para las áreas de TI: ha conseguido demostrar que plantea una solución adecuada frente al reto del empaquetado de software. Los contenedores combinan perfectamente con los distintos requisitos nativos de la nube y también son una excelente opción a la hora de proporcionar almacenamiento persistente para aplicaciones nativas en un entorno de cloud híbrida.
La gestión de paquetes de Linux, la virtualización de aplicaciones y las máquinas virtuales han permitido ir avanzando en el camino del “empaquetado de software”, que tiene como objetivo permitir el agrupamiento e instalación de aplicaciones en sus propios entornos. Pero fue el formato de imagen de contenedores y su tiempo de ejecución, que ahora está estandarizado bajo la denominada OCI (open container initiative), lo que provocó una evolución real a la hora de conseguir que las aplicaciones fuesen realmente transferibles entre diferentes sistemas y entornos.
Además, los contenedores han ayudado a reforzar el cambio hacia patrones de aplicaciones nativas de la nube (por ejemplo, los microservicios) y también se han beneficiado de esta tendencia. Sin embargo, debido a que los enfoques más puristas de las arquitecturas nativas de la nube restaron importancia a las denominadas “aplicaciones con estado” (stateful apps), los beneficios de los contenedores en lo que respecta a la portabilidad del almacenamiento no han recibido tanta atención. Esto parece haber sido un error, ya que la capacidad de conservar el almacenamiento y hacerlo portátil es importante, especialmente en los entornos de cloud híbrida —que abarcan tanto nubes públicas, como privadas e infraestructuras TI tradicionales— que cada vez más son la norma.
La gravedad de los datos
Una de las razones que demuestran el grado de importancia que hay detrás de la portabilidad de los datos la podemos encontrar profundizando en el concepto data gravity (datagravity.org), acuñado por Dave McCrory. Aunque este término se ha ido desarrollando con mayor nivel de detalle, su definición básica es bastante simple: debido a los límites de ancho de banda de la red, la latencia, costes y otras consideraciones, los datos “quieren” estar cerca de las aplicaciones que analizan, transforman o que trabajan en ellos.
Las arquitecturas de acceso a la memoria no uniforme (NUMA, non-uniform memory access), que describen prácticamente todos los sistemas informáticos de la actualidad en mayor o menor grado, han tenido que gestionar de manera similar la ubicación física de la memoria en relación con los procesadores que acceden a ella. Del mismo modo, especialmente para aquellas aplicaciones que requieren un acceso rápido a los datos o que precisan operar con grandes conjuntos de datos, es necesario pensar dónde están ubicados en relación con la aplicación que hace uso de ellos. Además, lógicamente, si se decide trasladar una aplicación desde un contexto local hacia, por ejemplo, la nube pública —para mejorar en escalabilidad o por otras razones—, es muy probable que deban moverse también los datos.
En entornos de cloud híbrida es importante conservar el almacenamiento y hacerlo portátil
Almacenamiento definido por software
Pero para conseguir esa movilidad de los datos es necesario salvar una serie de obstáculos. Por un lado, los límites y los costes asociados a la red han sido, y son en la actualidad, una de las limitaciones más evidentes. Por otra parte, el almacenamiento de datos propietario, más tradicional, impuso también sus propias restricciones, lo que ha impedido iniciar una matriz de almacenamiento en un proveedor de nube pública que coincida con la de su propio centro de datos.
Como su nombre indica, el SDS (software-defined storage o almacenamiento definido por software) permite abstraer y agrupar la capacidad de almacenamiento, ya sea en entornos locales o en la nube, para que sea posible escalar independientemente de componentes de hardware específicos. Fundamentalmente, el almacenamiento tradicional se creó para aplicaciones desarrolladas en los años setenta y ochenta. En el caso del SDS, está diseñado para admitir las aplicaciones de hoy y de mañana, que ni se ven ni se comportan como las del pasado y que requieren, entre otras cosas, una rápida escalabilidad, especialmente para los datos no estructurados de gran volumen que pueden necesitar expandirse rápidamente.
Sin embargo, con respecto a la portabilidad de los datos, uno de los mayores beneficios del SDS es que el software de almacenamiento se ejecuta en hardware genérico estándar de la industria y en infraestructura virtualizada, gracias a herramientas como por ejemplo Red Hat Gluster Storage. Esto significa que puede aumentar el almacenamiento allí donde tenga más sentido, ya sea por razones de coste, de rendimiento o de flexibilidad.
Contenerizando el almacenamiento
El siguiente paso es simplificar el despliegue del almacenamiento persistente definido por software, y resulta que los contenedores también son la respuesta a esto. En efecto, el almacenamiento puede tratarse como una aplicación contenerizada dentro de un clúster de Kubernetes (esta es la herramienta de orquestación que agrupa los componentes contenerizados en una aplicación completa).
Con este enfoque, los contenedores de almacenamiento se implementan junto con otros contenedores dentro de los nodos de Kubernetes. En lugar de simplemente acceder al almacenamiento efímero desde el contenedor, este modelo despliega este elemento en sus propios contenedores, junto con la aplicación contenerizada. Por ejemplo, los contenedores de almacenamiento pueden implementar un bloque de Red Hat Gluster Storage para crear un volumen GlusterFS altamente disponible que maneje los recursos de almacenamiento presentes en cada nodo del servidor.
Dependiendo de la configuración del sistema, algunos nodos solo pueden ejecutar contenedores de almacenamiento, otros únicamente aplicaciones contenerizadas y otros nodos pueden ejecutar una combinación de ambos. Usando Kubernetes, con su soporte para el almacenamiento persistente como herramienta de coordinación general, se podrían iniciar fácilmente contenedores de almacenamiento adicional para acomodar la demanda en este aspecto o para recuperarse de un nodo fallido. Por ejemplo, Kubernetes podría iniciar servidores web contenerizados adicionales en respuesta a la demanda o a la carga, pero podría reiniciar tanto la aplicación como los contenedores de almacenamiento en el caso de un fallo de hardware.
Si se decide trasladar una aplicación, es muy probable que deban moverse también los datos
Aplicaciones modulares y los datos
El modelo emergente para diseños de aplicaciones nativas de la nube es aquel en el que los componentes se comunican a través de interfaces bien documentadas. Independientemente de si un proyecto determinado adopta un enfoque puro de “microservicios”, las aplicaciones generalmente tienden a volverse más modulares y orientadas al servicio, las dependencias son explícitamente declaradas y aisladas, el escalado es horizontal, las configuraciones se almacenan en el entorno y los componentes se pueden iniciar de forma rápida y sin problemas.
No todas las aplicaciones en la nube son “sin estado” (stateless apps) o pueden depender de un backing store (memoria no volátil) que esté en otro lugar. Recordemos esa “gravedad de los datos” y que es importante dónde se encuentran.
