Sistemas de almacenamiento en Docker (Parte II)

Por Javier Ramírez.

Prosiguiendo con el post anterior, ahora nos ocuparemos de los datos de aplicativo. Estos datos deben estar disponibles en todo host susceptible de ejecutar tareas (instancias) de nuestro servicio. Cuando tratamos con un número finito de hosts lo más sencillo es dar visibilidad de los datos en todos y cada uno de ellos usando por ejemplo NFS o cualquier sistema de almacenamiento compartido (es importante observar que no todos los servicios pueden hacer uso de NFS por ejemplo ya que su rendimiento en la lectura/escritura sobre el almacenamiento proporcionado puede ser crítico), y después ejecutar los contenedores asociando el punto de montaje con un volumen. Hasta aquí parece sencillo, pero nos encontramos con problemas cuando el número de hosts crece, los sistemas de almacenamiento no permiten varios puntos de montaje o necesitamos asegurar un único acceso a los datos, por ejemplo. En entornos con cientos de hosts esta aproximación no es factible.

Para tratar este tipo de problemas de almacenamiento de datos de aplicativo, existen los plugins de almacenamiento, que se encargan de gestionar la meta-información necesaria para montar los volúmenes de datos única y exclusivamente en los hosts que ejecutan en ese momento el contenedor (tarea asociada a un servicio).

La evolución de Docker como producto ha ido incluyendo de forma muy rápida nuevas funcionalidades que comenzaron su desarrollo como plugins para proporcionar una característica que el core no proporcionaba. En la versión 17.03 (1.13) por ejemplo es posible usar volúmenes NFS de forma nativa, perfectamente válidos para despliegues con contenido estático o aquellos aplicativos en los que el contenido se cargue en memoria en arranque, por ejemplo.

# docker service create –name nfstest \

–mount type=volume,volume-opt=o=addr=192.168.1.111,volume-opt=device=:/DATA/NFS,volume-opt=type=nfs,source=DATA_NFS,target=/DATA,readonly=false \

–replicas 1 busybox ping www.google.es

# docker nfstest cd607740218a ls -lart /DATA

total 4

-rw-r–r– 1 root root 0 Jan 3 10:33 test_file

drwxrwxrwx 2 65534 65534 32 Jan 3 11:12 .

drwxr-xr-x 19 root root 4096 Mar 21 14:47 ..

En este ejemplo podemos comprobar el funcionamiento de los volúmenes gestionados de esta forma.

Existe gran variedad de plugins para poder conectar con nuestro almacenamiento y la elección de unos frente a otros estará fundamentada en nuestra infraestructura, tanto hardware como software (hardware defined storage o software defined storage). Sólo por citar algunos de los más conocidos:

  • Azure File Storage -> Permite montar almacenamiento de Azure en contenedores usando SMB.
  • Contiv -> Permite el uso de almacenamiento en entornos multi-tenant usando Ceph y NFS.
  • Convoy -> Plugin que permite el uso de diferentes back-ends, tales como device mapper y NFS. Permite realizar snapshots, backups/restore de volúmenes.
  • Flocker -> Permite almacenamiento multi-host en un entorno de software defined storage.
  • GCE-docker -> Permite usar almacenamiento perstistente del entorno cloud de Google.
  • GlusterFS -> Uso de volúmenes mediante GlusterFS.
  • HPE 3Par -> Soporta almacenamiento HPE 3Par and StoreVirtual iSCSI del fabricante HPE.
  • NetApp (nDVP) -> Soporta volúmenes sobre productos de NetApp.
  • Netshare -> Permite el uso de NFS 3/4, AWS EFS y CIFS. Es una buena alternativa al plugin nativo de Docker y muy sencillo de usar.
  • REX-Ray -> Incluye soporte para diversas plataformas como VirtualBox, EC2, Google Compute Engine, OpenStack, y productos EMC. Permance como opensource respaldado por Dell-EMC.
  • VMware vSphere Storage -> Plugin específico para trabajar con la plataforma vSphere.

Desde la versión 17.03 de Docker existen los “Plugins Certificados”. Esto supone que Docker Inc, certifica estos desarrollos de los fabricantes en la infraestructura Docker de manera que tendremos el aseguramiento y soporte de ambos para su correcto funcionamiento. Como no podría ser de otra forma, dentro de los plugins certificados, los de almacenamiento son de gran importancia porque muestran el compromiso de los fabricantes con la plataforma Docker.

Como podemos ver no están aún certificados algunos de los plugins de almacenamiento más conocidos, pero este listado está en continua actualización a medida que los fabricantes de dispositivos de almacenamiento mejoran el soporte de su integración.

Los avances técnicos en el área de almacenamiento han evolucionado estas infraestructuras sobre todo en el consumo de los servicios que proporcionan. Además, la apertura de código de las APIs de conexión por parte de los fabricantes y las infraestructuras orientadas a los entornos cloud han dado lugar a una serie de herramientas y protocolos de uso estandarizados que facilitan el consumo de los servicios en infraestructuras basadas en código como Docker.

Este tipo de plugins permite por ejemplo el despliegue de servicios de Base de Datos que requieren de un almacenamiento persistente con accesos garantizados, ágiles y disponibles en cualquier host.

# docker node ls

ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS

efxmwp0aca10mvhz38d6sxxqi swarmnode4 Ready Active

f3sdb6qghxhar55333z5kyxna swarmnode2 Ready Active Leader

j9eocihozmh2ti5hz05rl4h0q swarmnode3 Ready Active Reachable

rdc6hqtalzky2l75yzfoyabjz * swarmnode1 Ready Active Reachable

Creamos el volumen “pgdata” en todos los nodos del cluster de swarm, con 1GB de tamaño:

# docker volume create -d rexray –name pgdata –opt=size=1

# docker volume ls|grep pgda

rexray pgdata

Creamos el servicio “pgdb” con la ejecución de PostgreSQL montando el volumen creado previamente:

# docker service create –replicas 1 –name pgdb \

–mount type=volume,source=pgdata,target=/var/lib/postgresql/data \

–env POSTGRES_PASSWORD=mysecretpassword \

–publish 5432:5432 postgres

Revisamos las tareas (contenedores) creados para el servicio “pgdb”:

# docker service ps pgdb

ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS

m1sb2q7dtppc pgdb.1 postgres:latest swarmnode1 Running Running about a minute ago

Nos conectamos a swarmnode1 y revisamos la tarea (contenedor del servicio) ejecutándose en el nodo:

# docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

34836490ed14 postgres@sha256:6ac0fbeddde3bb7b0003a2ace8c126f742f8bdd90695801337d3edaaf1fcc478 “docker-entrypoint…” 2 minutes ago Up 2 minutes 5432/tcp pgdb.1.m1sb2q7dtppcpk41uf6mshxwh

Matamos el contenedor de la base de datos:

# docker kill 34836490ed14

34836490ed14

Unos segundos después, observamos que el servicio de Base de Datos PostgreSQL está de nuevo disponible (con una tarea nueva), montando el mismo volumen “pgdata”, esta vez en swarmnode3.

# docker service ps pgdb

ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS

q1ge9nngdzsh pgdb.1 postgres:latest swarmnode3 Running Running 8 seconds ago

m1sb2q7dtppc \_ pgdb.1 postgres:latest swarmnode1 Shutdown Failed 49 seconds ago “task: non-zero exit (137)”

Cuando trabajamos con servicios en los que el almacenamiento es crítico, ya sea por velocidad de acceso de lectura/escritura o por garantizar que es único, es importante entender que a día de hoy Docker se preocupa de la gestión de la infraestructura. Esto supone que nosotros como administradores de la misma somos los encargados de gestionar convenientemente tanto la disponibilidad de los datos (usando los plugins de la forma más apropiada) como del acceso que se realiza a los mismos de forma no simultánea (nuestros servicios deben controlar el acceso que realizan a los datos y saber si pueden o no consumirlos/modificarlos).

En resumen, es de vital importancia conocer las diferentes alternativas que Docker proporciona para gestionar los datos en nuestra infraestructura de contenedores y las herramientas que nos facilitan estos procesos. Con ellas y con el entorno de almacenamiento adecuado podemos usar en contenedores cualquier aplicación que nos propongamos, incluidos por supuesto motores de bases de datos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.