Administración básica de Docker swarm - Parte II

Hoy continuamos con la administración de Docker swarm y en concreto, vamos a repasar como usar volúmenes con los servicios que desplegamos en nuestros clusters de dockerhosts.

Originalmente, como ya vimos en su momento, se usaba la opción -v o --volume, para montar volúmenes con nuestros contenedores standalone y, para el despliegue de servicios, se usaba la opción -m o --mount. Desde la versión 17.06 de Docker lo recomendado es usar --mount en ambos casos, aunque se sigue soportando el uso de --volume con contenedores standalone.

Recordando un poco lo que ya sabemos de Docker, hay dos tipos de montajes o volúmenes que podemos usar. Los dos tipos de montajes o volúmenes disponibles son:

• Volúmenes de datos (volume mounts). Estos son los volúmenes independientes de nuestros dockerhosts y que deben ser gestionados de manera separada. Lo lógico es que estos volúmenes los proporcionen sistemas de almacenamiento específicos y que, mediante un driver determinado, podamos interactuar con el proveedor del almacenamiento y administrar los volúmenes.
• Volúmenes de tipo bind. De forma muy simple estos son volúmenes que están en cada dockerhost del swarm, es decir son rutas dentro del sistema de archivos de nuestros dockerhosts.

Como ya he comentado, aunque se sigue soportando la opción -v o --volume, lo recomendado es usar siempre la opción -m o --mount, independientemente del tipo de volumen a usar. Al montar nuestros volúmenes con --mount podremos especificar diferentes opciones, como vimos en el post sobre Trident.

Para especificar los volúmenes de nuestros servicios o contenedores, la sintaxis de la opción --mount utiliza determinadas claves, mediante las cuales podemos especificar las siguientes opciones:

• Tipo de montaje, con la opción type. Esta opción nos permite especificar si el montaje será de tipo bind, volume o tmpfs. El tipo tmpfs nos permite crear un volumen en la memoria asignada al contenedor, lo cual está indicado para aquellos datos temporales que no queremos o no es necesario que tengan persistencia. 
• Origen del montaje, con la opción source. Para volúmenes con un nombre determinado, este campo contendrá el nombre del volumen. Si no especificamos un nombre se creará un volumen anónimo.
• Ruta o punto de montaje, con la opción destination. Con esta opción especificaremos el punto de montaje dentro del contenedor.
• Resto de opciones, especificadas como volume-opt, que nos permitirán especificar opciones adicionales de configuración.

Recordando el post sobre Trident, creamos un servicio montando un volumen y especificando un driver, del siguiente modo:

Especificamos un volumen en la creación de un servicio.

Vamos a revisarlo más detenidamente, definiendo un servicio simple que incluya volúmenes y modificando un servicio ya existente añadiendo o eliminando volúmenes.

Empezando por la parte más sencilla, con el subcomando volume de docker podemos controlar los volúmenes de nuestro cluster swarm, o de dockerhosts individuales. Las opciones disponibles del comando docker volume son las siguientes:

Opciones disponibles del comando docker volume.

Si usamos el comando docker volume sin ninguna opción, el driver utilizado será local, es decir las operaciones se realizarán sobre volúmenes locales del dockerhost sobre el que estemos operando. Por ejemplo, podemos crear un volumen en un solo dockerhost: 

Creación de un volumen local en un dockerhost.

Tambien podemos crear un volumen, con el mismo nombre, en cada uno de los dockerhost que forman parte del swarm:

Creación de un volumen local en los nodos de un swarm.

De la salida del comando docker volume ls vemos que, la primera columna indica que el driver utilizado es local. Esto indica que ese volumen solo existe en el dockerhost y por tanto, los datos que un servicio o contenedor genere y almacene en dicho volumen solo estarán disponibles en dicho dockerhost.

Los volúmenes creados con el driver local se crearán siempre en la ruta /var/lib/docker/volumes, lo cual podemos comprobar usando el comando docker volume inspect:

Obteniendo la información de un volumen.

Como es lógico, podemos cambiar esta ruta especificando la opción --data-root en el arranque del demonio dockerd.

Ahora que hemos creado un volumen común a todos los dockerhosts del swarm, podemos arrancar un servicio simple que use dicho volumen, especificándolo con --mount, mediante el comando siguiente:

Creación de un servicio con un volumen local.

De esta manera, al crear el servicio sin especificar un driver, docker usará el driver local y buscará un volumen con el nombre especificado en el dockerhost para montarlo en los contenedores. En caso de especificar un volumen que no exista, el volumen se creará con el nombre especificado o, si no especificamos un nombre, se creará un volumen anónimo:

Creación de un servicio con múltiples volúmenes.

Al listar los volúmenes disponibles en cada uno de los dockerhosts del swarm, vemos que se ha creado el volumen VOL_logs_swarm que no existía antes y dos volúmenes anónimos, uno se corresponde con el volumen para la ruta especificada /WWW_tmp y el otro volumen anónimo es para el volumen indicado en la definición de la imagen usada, que en este caso  se monta en /WWW.

Volúmenes creados para el servicio.

Por tanto, docker nos permitirá crear los volúmenes o los creará en caso de ser necesario, ya que como vemos se crea un volumen anónimo cada vez que lanzamos un contenedor a partir de una imagen que incluye volúmenes en su configuración.

Cuando queramos eliminar volúmenes que ya no se usen, podremos usar el comando docker volume prune, lo cual los eliminará. Como es lógico, al no especificar el driver, esto solo se aplicará a los volúmenes locales:

Eliminamos los volúmenes no usados. En este caso son volúmenes locales.

Ahora, usando plugins específicos para la creación de volúmenes para nuestros servicios, como por ejemplo el driver Trident para interactuar con sistemas NetApp, podemos crear un servicio que utilice volúmenes de datos comunes proporcionados por una SVM y volúmenes locales para datos temporales que no necesitamos que se mantengan:

Creación de un servicio con volúmenes desde una SVM.

En este ejemplo creamos un servicio que usa un volumen ya existente en la SVM (swarm_HTML), otro volumen que no existe y que el driver creará por nosotros (swarm_LOG) y un volumen local que tampoco existía con anterioridad (LOCAL_tmp) y que Docker creará en cada dockerhost:

El volumen VOL_swarm_LOG lo creará Trident al crear el servicio.

Lista de volúmenes existentes en nuestro swarm.

Por tanto podemos combinar volúmenes de diferentes poveedores en el mismo servicio con solo especificar el driver correcto para cada uno de ellos. Podemos comprobar los volúmenes en uso por el servicio usando el comando docker service inspect:

Lista de volúmenes en uso por el servicio.

En caso de ser necesario podemos actualizar la configuración del servicio y añadir o quitar volúmenes, mediante la opción --mount-rm del comando docker service update. Por ejemplo, si ncesitamos eliminar el volumen local, podemos hacer lo siguiente:

Eliminamos un volúmen de un servicio.

Con lo que ahora, al inspeccionar el servicio, vemos que solo está usando los volúmenes proporcionado por la SVM del sistema NetApp:

El servicio ahora usa solo dos volúmenes, dados por el driver Trident.

Para aplicar este update, como vemos en la salida siguiente, Docker ha parado cada contenedor del servicio y lo ha vuelto a arrancar con la nueva configuración:

Contenedores arrancados con la nueva configuración de volúmenes.

Por tanto y para terminar, hemos visto como Docker nos permite gestionar los volúmenes necesarios para nuestros contenedores o servicios y su integración con proveedores de almacenamiento como NetApp. Como siempre, para una información mucho más detallada, os recomiendo consultar la documentación oficial de Docker.

Cluster ONTAP - Usando SyncMirror

Hoy volvemos con una nueva entrada sobre ONTAP, en la que veremos que es y cómo usar SyncMirror.

De forma muy simple, SyncMirror permite realizar mirrors de agregados, es decir, nos permite añadir otra capa de protección adicional replicando todos los datos de un agregado de forma local o remota. SyncMirror es una de las funcionalidades que emplea MetroCluster para replicar datos entre diferentes sites, permitiéndonos tener copias de los agregados del site principal en el site secundario.

Si nos fijamos en la salida del comando aggr show de cualquier agregado en un sistema NetApp, independientemente de si es 7-mode o C-mode, veremos que siempre aparece un dispositivo llamado plex0 asociado con los raid groups de los agregados:

Relación entre plexes y agregados.

Ese dispositivo plex0 representa una de las "patas" de nuestro mirror y lo que SyncMirror nos permite es añadir la otra "pata", que será plex1. Cada plex estará formado por discos de diferentes pools, siendo un pool un conjunto lógico de discos.

Lo primero que es necesario tener en cuenta es que para asegurar el mirror, debemos usar discos separados físicamente. En el caso del despliegue de un MetroCluster, esa separación ya viene dada y en el caso de usarlo localmente, tendremos que usar discos de diferentes bandejas y stacks. Esta comprobación la realiza de forma automática el sistema, comprobando que los discos son idénticos y que están en diferentes stacks.

Por defecto, todos los discos de un sistema ONTAP están siempre en el Pool0, como podemos ver en la siguiente imagen:

Por defecto no hay discos en el Pool1.

En caso de intentar hacer un mirror de un agregado ya existente con discos del mismo pool, recibiremos un error como el siguiente:

Necesitaremos discos en pools separados para poder crear el mirror de un agregado.

Por tanto, para poder usar SyncMirror tendremos que asignar discos a diferentes pools y, teniendo en cuenta que estamos usando el simulador, debemos asignar los discos por bandeja virtual. Como cada bandeja del simulador tiene 14 discos, y cada una empieza en la bahía 16, será necesario deshabilitar el autoassign de uno de los nodos, eliminar el propietario de la mitad de discos del nodo y volver a asignarlos, ya especificando que se añadan al Pool1. En resumen, la asignación de discos la realizamos del siguiente modo:

Agregamos discos al Pool1 del simulador.

Listamos los discos disponibles en el Pool1.

De esta manera tendremos la mitad de los discos del nodo en cada uno de los pools y podremos crear el mirror con el siguiente comando, que nos dará el siguiente mensaje de error indicando que al menos son necesarios diez discos para crear correctamente el agregado en mirror: 

Necesitaremos al menos un total de 10 discos, 5 por pool, para crear el agregado en mirror usando RAID-DP.

Como independientemente de estar creando un agregado en mirror, es necesario crear los raid groups de los agregados con el número de discos requeridos por tipo de RAID, si creamos raid groups de tipo RAID-DP el mínimo número es 5, con lo que si por ejemplo vamos a usar 7 discos por Pool, es decir 7 del Pool0 y 7 del Pool1, el total de discos será 14.

Para crear el agregado replicado con SyncMirror solo es necesario ejecutar el siguiente comando, la primera vez con la opción simulate:

Simulamos la creación del agregado en mirror.

y cómo no recibimos ningún error adicional, creamos el agregado en mirror repitiendo el comando anterior pero sin la opción simulate. Tras esto, la salida del comando storage aggregate show-status es la siguiente:

 

Podemos comprobar que el agregado está en mirror con el comando storage aggregate show:

Agregado en estado mirrored.

Y si comprobamos los detalles del agregado especificando el nombre del mismo, o usamos el parámetro -instance, podemos ver los plexes y los discos de cada uno de ellos:

Ahora, para realizar alguna prueba de sincronización, lo más sencillo es crear una SVM y asignar un volúmen a la misma dentro de dicho agregado. Exportamos el nuevo volúmen por NFS y lo montamos en un cliente Linux para escribir datos de prueba.

Con el volúmen ya exportado y montado en un cliente por NFS, podemos poner uno de los plexes offline, para comprobar como el agregado y por tanto el volúmen, sigue estando accesible y es totalmente transparente para el cliente NFS. Si quiero consultar los plexes existentes en un sistema, puedo usar el comando siguiente:

Consultamos los plexes disponibles en el sistema.

Y para pasar al estado offline el primer Plex, y por tanto simular un fallo, ejecutamos el siguiente comando:

Pasamos el plex0 al estado offline.

Ahora, al comprobar los plexes existentes, podemos ver que el plex0 está inactivo:

Uno de los plexes está inactivo.

Pero desde el cliente NFS comprobamos que este sigue teniendo acceso a la ruta montada sin problemas y puede realizar operaciones de escritura y lectura:

El cliente NFS no experimenta ningún corte y el mirror del agregado funciona perfectamente.

Si copiamos mas datos y aumentamos el tamaño del volumen, podremos ver como ONTAP resincroniza ambos plexes cuando volvamos a poner online el plex0:

Aumentamos el tamaño del volumen y copiamos más datos.

Ahora ponemos de nuevo online el plex0 y, comprobando la salida del comando storage aggregate plex show, podemos comprobar que ambos plexes se están resincronizando:

Ponemos el plex0 online y el sitema resincroniza ambos plexes.

La salida del comando nos muestra el porcentaje de resincronización.

Cómo es lógico, este proceso puede tardar más o menos en función de cuantos datos tengan que resincronizarse.

Para que un agregado deje de estar en mirror solo es necesario borrar uno de los plexes usando el subcomando delete, como podemos ver en la siguiente imagen:

Borrado de uno de los plexes de un agregado en mirror.

Cómo el comando anterior solo borra uno de los plexes del agregado, no se produce ningún tipo de pérdida de datos y el estado del agregado sigue apareciendo como normal:

Estado de los agregados tras borrar el plex.

Si intentamos borrar un plex de un agregado que no está en mirror, recibiremos el siguiente mensaje de error indicando que el agregado no está en mirror y que, por tanto, no puede borrarse el último plex de un agregado:

Error al intentar borrar el último plex de un agregado.

Por útlimo, indicar que no hace falta crear el agregado en mirror desde el principio con SyncMirror, sino que podemos hacer mirror de cualquier agregado ya existente con solo ejecutar el siguiente comando:

Protegemos un agregado existente con SyncMirror.

Aquí vemos como se sincronizan ambos plexes.

El último punto a tener en cuenta es que es recomendable que los discos estén zeroed, ya que en caso contrario el sistema hará el zero de los mismos y los añadirá al plex una vez que haya terminado con lo que si antes de terminar de hacer el zero se rebota el nodo, entonces el plex se queda vacio y hay que eliminarlo manualmente para repetir el proceso.

Cluster ONTAP - Usando RAID TEC

Hola de nuevo, en este post voy a repasar una funcionalidad disponible en ONTAP desde la versión 9.0 y que, en función de la criticidad de nuestros datos o del tamaño de los discos que estemos usando, puede ser interesante tener en cuenta. Me estoy refiriendo al RAID Triple Erasure Coding o RAID-TEC para abreviar.

Primero vamos al rollo teórico y resumamos un poco que es RAID-TEC y como funciona, aunque para ello será buena idea que revisemos primero como funcionan los modos RAID4 y RAID-DP que hemos estado utilizando hasta ahora.

Como ya sabemos, a grandes rasgos, RAID4 soporta el fallo de un disco de un raid group y RAID-DP el fallo de dos discos de un raid group. Siempre que nuestro sistem tenga suficientes discos spare, ONTAP será capaz de sustituir el disco fallido y reconstruir la información del mismo a partir de la información de paridad correspondiente. En general y solo desde mi punto de vista, no es recomendable construir agregados usando RAID4, salvo que los datos que contenga no sean datos de producción y dispongamos de suficientes discos spare.

Pero, ¿como funcionan realmente RAID4 y RAID-DP? Como habremos comprobado muchas veces, cuando consultamos la distribución de discos de un agregado, vemos algo como lo siguiente:

Distribución de discos de un agregado.

En la imagen anterior tenemos la salida del comando aggr show que nos muestra los raid groups que forman un agregado y, como podemos ver, hay dos discos marcados como discos de paridad ya que el raid group en cuestión es de tipo RAID-DP. Cada disco de paridad almacena un tipo de paridad diferente, más concretamente, el tipo de paridad por disco es el siguiente:

• Disco de paridad o de paridad de banda. Este disco almacenaría el cálculo de paridad de banda, mediante el uso de una operación XOR, de cada una de las escrituras distribuidas en cada uno de los discos de datos del raid group. Esto podemos verlo de manera muy simple como:

Cálculo de paridad de fila.

• Disco de paridad diagonal. Este disco almacenaría el cálculo de paridad diagonal de cada una de las bandas diagonales distribuidas en cada uno de los discos de datos del raid group. De nuevo, de manera muy simplificada, podemos verlo del siguiente modo:  

Cálculo de paridad diagonal.

Teniendo esto en cuenta, podemos ver un raid group completo, con sus discos de paridad y de paridad diagonal, del siguiente modo:

Paridad de banda y diagonal de un raid group.

Llegados a este punto, está claro que en el caso de usar RAID-TEC, tendremos un nuevo disco que contendrá un nuevo cálculo de paridad y ¿que nos queda para poder hacer ese cálculo? Pues en este caso la solución de NetApp es añadir un cálculo de paridad anti-diagonal que se almacenará en nuestro tercer disco de paridad. Esta paridad anti-diagonal podemos verla de forma muy simplificada del siguiente modo:

Paridad anti-diagonal.

Como vemos, para el cálculo de la paridad anti-diagonal solo se utilizan los discos de datos y el disco de paridad de banda.

Para el cálculo de paridad es muy importante tener en cuenta como trabaja ONTAP y su relación con la NVRAM. En una entrada posterior revisaremos todo esto un poco más en detalle.

Como es lógico, RAID-TEC está pensado para aquellos agregados en los que usemos discos de gran capacidad, pensando en evitar que el fallo de un disco, mientras se está realizando la reconstrucción de un raid group, provoque la pérdida irreversible de datos. La recomendación de NetApp es usarlo para agregados con discos de capacidades superiores a los 4 TB.

Para cada tipo de RAID, el número mínimo de discos es el siguiente:

• RAID4, son necesarios al menos 3 discos, dos discos de datos y uno de paridad de banda para agregados con un solo raid group. Si se trata del agregado root, el raido group puede ser de dos discos únicamente.
• RAID-DP, el mínimo número de discos necesarios para un agregado con un solo raid group es 5, tres discos de datos, uno de paridad de banda y otro de paridad diagonal. Sin embargo, si se trata del agregado root, el raid group puede estar formado por 3 discos solamente.
• RAID-TEC, para este caso el mínimo número de discos es 7, 4 discos de datos y 3 para cada uno de los tipos de paridad.

Una forma sencilla de comprobar el número de discos requeridos para cada tipo de raid, es lanzar el comando de creación de un agregado con un solo disco ya que, la salida del comando nos indicará el mínimo número de discos requeridos:

Discos requeridos por tipo de RAID.

Vamos a ver como crear un nuevo agregado de tipo RAID-TEC con dos raid groups, para esto solo necesitamos ejecutar un comando como el siguiente:

  

Creación de un agregado con protección RAID-TEC.

Como podemos ver en la salida del comando, vamos a crear un agregado que estará formado por 14 discos en total, con dos raid groups de 7 discos cada uno (opción maxraidsize) con protección RAID-TEC en cada raid group. Esto se refleja en la distribución de cada raid group con los discos de paridad parity, dparity y tparity, siendo el resto discos de datos.

Una de las ventajas de ONTAP es la capacidad que nos proporciona de cambiar el tipo de RAID utilizado en un agregado con solo usar un comando. Veamos un ejemplo en el cual, creamos un agregado con una protección RAID4 y lo cambiamos a RAID-DP y finalmente a RAID-TEC:

Creación de un agregado de tipo RAID4.

Conversión del agregado a tipo RAID-DP.

Conversión del agregado a tipo RAID-TEC.

Como podemos ver, el sistema ha ido añadiendo discos de paridad al agregado en cada uno de los casos y reconstruyendo su contenido según lo hemos convertido. Para hacer esto es necesario que tengamos en cuenta los siguientes puntos:

• Es necesario que dispongamos de suficientes discos de spare en el sistema. En este ejemplo cada raid group ya tiene el mínimo número de discos requerido para cada tipo de raid, con lo que solo es necesario añadir un disco de paridad a cada raid group en cada paso. 
• En caso de que el número de discos en los raid groups ya existentes sea inferior al número de discos requeridos, será necesario incremental el número de discos requeridos en cada raid group hasta el número necesario antes de poder hacer la conversión de tipo de RAID.
• El sistema reconstruye el disco de paridad correspondiente a partir de los datos existentes en el agregado. Si tenemos que convertir un agregado con una gran cantidad de datos, es muy probable que el proceso de reconstrucción sea bastante largo.

Hasta aquí un repaso de RAID-TEC y como usarlo en nuestros sistemas ONTAP. En breve una entrada sobre como proteger nuestros agregados localmente usando SyncMirror.

Usando plugins en Docker - NetApp Trident

Hoy vamos a estudiar cómo podemos extender las funcionalidades de Docker mediante el uso de plugins.

Docker y por tanto Docker Swarm, al igual que orquestadores como Kubernetes o Rancher, permite el uso de plugins o módulos adicionales que nos permitirán la integración de nuestra infraestructura de contenedores con otros servicios o añadirán funcionalidades adicionales. Estos plugins, disponibles en Docker Hub, nos permiten integrar nuestros dockerhosts con sistemas de almacenamiento, añadir funcionalidades de logging o extender las capacidades de red.

Para estudiar el funcionamiento del sistema de plugins de Docker, voy a centrarme en el plugin Trident desarrollado por NetApp, que nos permite administrar y montar volúenes alojados y servidos por sistemas NetApp en nuestros dockerhosts.

Plugin Trident de NetApp disponible en Docker Hub.

En la página del plugin en Docker Hub tenemos disponible la descripción del plugin así como las instrucciones de instalación del mismo, pero es recomendable seguir las instrucciones de configuración oficiales dadas en el siguiente enlace.

En resumen, para usar este plugin debemos realizar los siguientes pasos:

1. Debemos crear el fichero de configuración en todos los dockerhosts que vayamos a integrar con nuestros sistemas NetApp.
2. Crearemos una o más SVMs que proporcionarán los servicios de bloque o fichero necesarios. Es muy importante que dichas SVMs tengan asignado uno o más agregados para la creación de volúmenes.
3. Creamos un rol y un usuario específico para el uso del plugin en cada una de las SVMs que vayan a proporcionar servicio a nuestros dockerhosts.
4. Por último instalamos el plugin en todos nuestros dockerhosts.

Empecemos por el fichero de configuración, como indica la documentación este fichero debe estar en la ruta /etc/netappdvp y es un fichero JSON cuyo nombre por defecto será config.json. Una configuración simple del fichero, para un entorno NAS, podría ser:

Fichero de configuración de Trident.

En esta configuración estoy especificando:

• Los parámetros managementLIF y dataLIF contienen el nombre DNS o dirección IP de las LIF de gestión y datos de la SVM para esta instanacia de configuración.
• El parámetro svm indica el nombre de la SVM que estamos usando, siendo username y password las credenciales del usuario que usaremos para interactuar con dicha SVM.
• La sección default establece una serie de valores por defecto para la creación de nuestros volúmenes desde los dockerhosts. En este ejemplo establecemos la política de snapshots así como la política de exportación de volúmenes, el tamaño de los volúmenes creados, el tipo de seguridad y la reserva de espacio para snapshots.

En caso de cambiar la configuración de Trident, será necesario reiniciar el plugin con los comandos docker plugin disable y docker plugin enable.

 

Creamos una SVM con el mismo nombre que el que indicamos en el fichero de configuración, así como el rol con los permisos adecuados que luego asignaremos al usuario que tabién vamos a crear. Los permisos necesarios para el rol son los siguientes:

Creación del rol necesario para el plugin.

Creamos el usuario y le asignamos el rol que acabamos de crear, es importante que establezcamos como tipo de aplicación a usar por el usuario ontapi:

Creación del usuario y asignación del rol.

Ahora ya podemos instalar el plugin en todos nuestros dockerhosts, siendo la salida de la instalación como la siguiente:

Instalación del plugin Trident en los dockerhosts.

El plugin ya instalado y disponible.

Una vez instalado el plugin, al estar habilitado, el demonio docker se encargará de arrancarlo cada vez que iniciemos el sistema. Podemos comprobarlo viendo los procesos de cada uno de nuestros dockerhosts:

Procesos del plugin Trident.

En caso de ser necesario, podemos parar el plugin usando el comando docker plugin del siguiente modo:

Parando el plugin Trident en un dockerhost.

Como ya he comentado la SVM debe tener agregados asignados a ella para permitir la creación de volúmenes desde el plugin. En caso de no ser así recibiríamos un error como el siguiente:

Error cuando la SVM no tiene agregados asignados.

Desde OnCommand System Manager podemos asignar de forma muy rápida y simple los agregados a la SVM con solo editarla desde el apartado SVMs:

Asignamos un agregado a nuestra SVM para el usuao de Trident.

Lo primero que podemos hacer es crear los volúmenes que vayamos a necesitar usando el comando docker volume. Como es lógico esto solo lo haremos desde uno de nuestros dockerhosts, así que como ejemplo creamos varios volúmenes desde diferentes dockerhosts:

Creamos varios volúmenes usando el plugin Trident.

Comprobamos que los nuevos volúmenes existen en el agregado.

Es muy importante que nos demos cuenta que al delegar un agregado a la SVM como hemos hecho, el usuario que utilicemos tiene control total sobre los volúmenes que existan en dicho agregado. Por tanto, si el agregado está compartido con más clientes, es posible borrar el resto de volúmenes con los comandos de gestión de volúmenes de Docker a través de Trident, siempre y cuando todos los volúmenes de dicho agregado contengan el mismo prefijo que hemos establecido en la configuación del plugin. Por ejemplo, si listamos los volúmenes disponibles vemos que aparece uno que no hemos creado con Trident:

Listado de volúmenes disponibles.

Para evitar problemas, si es necesario que diferentes cliente compartan el mismo agregado, lo mejor es que los volúmenes controlados por Trident utilicen un prefijo distinto al del resto de volúmenes del agregado.

 

Una vez creados los volúmenes, podemos pasar a usarlos montándolos cuando despleguemos un contenedor o un servicio en nuestro swarm:

Creación de un servicio replicado con un volumen.

El comando anterior utiliza la sintaxis mount para el montaje de volúmenes, esta sintaxis está disponible desde la versión 17.06 de Docker para contenedores standalone y no solo para swarm. En próximas entradas explicaré más detalladamente como utilizarla y sus diversas opciones, por ahora quedémonos en que vamos a montar un volumen controlado por el plugin Trident.

 

Al ejecutar el comando anterior, swarm orquesta el montaje del volúmen especificado en los hosts en los que se despliegue un contenedor que lo necesite, con lo que, de forma automática montará por NFS el volumen swarm_HTML que hemos creado anteriormente y que está sirviendo nuestra SVM. Esto lo podemos comprobar del siguiente modo:

Escalamos el servicio a 3 réplicas.

Ahora el contenedor solo está corriendo en tres de los dockerhosts que forman el swarm, con lo que el volumen necesario solo está montado en dichos hosts como podemos ver:

Docker Swarm ha montado el volumen en los hoosts necesarios.

Si ahora escalamos de nuevo el servicio, comprobaremos que se montará el volumen en el nodo swarm-nodo2 para poder levantar correctamente el contenedor con el volumen requerido:

Docker Swarm monta el volumen en el nodo restante.

Como es lógico, al borrar el servicio, el volumen se desmontará de todos los nodos si ningún otro servicio lo está utilizando.

Por tanto, y en resumen, hemos visto como Docker Swarm es capaz de orquestar perfectamente el montaje de volúmenes externos, en este caso controlados por el plugin Trident de NetApp y como este plugin nos permite integrar nuestra infraestructura de contenedores basada en Docker con los sistemas de almacenamiento NetApp. Además hemos podido comprobar como expandir las funcionalidades de Docker mediante el uso de plugins.

Como es lógico este plugin también está disponible para Kubernetes, el cual espero poder estudiar dentro de un tiempo y repasar su funcionamiento.

En próximas entradas, repasaré las opciones disponibles para la gestión y uso de volúmenes en servicios implementados en Docker Swarm con la opción mount.