Cluster ONTAP - Replicación de datos con SnapMirror - Parte II

Hoy continuamos estudiando las funcionalidades que nos ofrece SnapMirror y cómo configurarlo para proteger los datos de nuestros sistemas ONTAP.

En el anterior post establecimos una relación de protección entre dos clusters, para lo cual realizamos la configuración de la relación de peering entre ambos y la transferencia inicial o baseline del volumen que queremos proteger.

Recordemos que el funcionamiento de SnapMirror consiste en que el sistema destino, en función del schedule que establezcamos, creará un snapshot del volumen en el sistema origen y lo transferirá junto con otros snapshots que pudiesen existir, lo cual estará en función de la política de replicación que establezcamos para la relación de SnapMirror.

Por tanto, una de las configuraciones es la política de replicación la cual, de forma simple, establece que snapshots queremos transferir al sistema destino. Las políticas de replicación predefinidas en ONTAP son las siguientes:

• MirrorAllSnapshots, esta política establece que en cada replicación deben transferirse todos aquellos snapshots que se hayan realizado desde la última replicación, así como el snapshot realizado por el propio SnapMirror.
• MirrorLatest, esta política establece que solo se transferirá el snapshot creado por SnapMirror en cada replicación.

Si listamos las políticas predefinidas para el tipo async-mirror correspondiente a SnapMirror, veremos lo siguiente:

Políticas predefinidas para SnapMirror.

Como podemos ver hay tres políticas diferentes, siendo la política DPDefault la política correspondiente al modo de replicación Data Protection que, como recordaremos, era el modo por defecto empleado al crear una relación SnapMirror hasta ONTAP 9.3. Si comparamos esta polítca con la política MirrorAllSnapshots podemos comprobar que son idénticas, ya que esta es la nueva política por defecto empleada desde ONTAP 9.3.

Como podemos ver en la salida del comando anterior, las políticas contienen una serie de reglas con lo que vamos a analizarlas más detenidamente:

Política MirrorAllSnapshots.

Política MirrorLatest.

Como podemos ver, la principal diferencia entre ambas políticas es que MirrorAllSnapshots contiene una regla que indica que hay que transferir todos los snapshots del origen, indicada por la regla número 2 y la etiqueta all_source_snapshots. La pregunta es ¿que son estas reglas y cual es su relación con la transferencia de snapshots?

Para esto primero empecemos por analizar un snapshot en nuestro sistema origen:

Características de un snapshot.

De todas las características que podemos ver en la salida, vemos que hay un campo Label for SnapMirror Operations, cuyo valor es standard. Debemos recordar, que esta etiqueta de snapshots la fijamos nosotros en el momento de crear las políticas de snapshots para nuestros volúmenes.

Si buscamos este mismo snapshot en el sistema destino veremos que tiene las mismas características y que, salvo los valores que cambian debido a que se ha transferido al cluster destino, veremos que el campo de etiqueta contiene el mismo valor identificado como standard.

Adicionalmente, si nos fijamos en los snapshots creados por las operaciones de snapmirror, identificados con el nombre snapmirror tanto en origen como en destino, veremos que también tienen un campo label, pero en este caso está vacia.

Lo que establecen las reglas de las políticas de SnapMirror es el nombre de la etiqueta de los snapshots que se transferiran y, en el caso de las políticas predefinidas las reglas establecen:

• sm_created - Esta etiqueta fuerza la transferencia del snapshot creado por SnapMirror en cada transferencia programada. Este snapshot siempre estará identificado con una etiqueta SnapMirror vacía. Como indica la documentación, esta regla no puede modificarse ni puede eliminarse de la política.
• all_source_snapshots - Esta etiqueta indica que deben transferirse todos los snapshots del volumen origen, realizados desde la útlima replicación.

Veamos un ejemplo modificando la etiqueta de un snapshot del volumen origen. Para esto, primero vamos a crear un snapshot del volumen origen al cual vamos a fijar una etiqueta de snapmirror diferente, lo cual podemos hacer con un comando como el siguiente:

Creación de un snapshot con una etiqueta de pruebas.

Ahora podemos ver los snapshots del volumen y veremos que la etiqueta es difernte del resto de snpashots:

Lista de snapshots del volumen origen.

Con esta nueva etiqueta y la programación que establecimos para la relación de SnapMirror, vemos que la regla all_source_snapshots transfiere todos los snapshots existentes en el volumen origen como ya hemos visto independientemente de su etiqueta, y por tanto ahora tenemos nuestro snapshot snap_test en el volumen destino:

Snapshots del volumen destino incluyendo el snapshot de test.

Teniendo en cuenta que SnapMirror es una solución de disaster recovery y que, como es lógico, deberíamos tener nuestros datos de origen totalmente replicados en destino, el comportamiento de la política MirrorAllSnapshots es el esperado en ese caso.

Al comparar esta política con la política MirrorLatest, vemos que la diferencia fundamental es que únicamente contiene la regla con la etiqueta sm_created, es decir, todas aquellas relaciones de protección que utilicen esta política solo transferiran el snapshot creado por SnapMirror en cada actualización.

Y nos podemos preguntar ¿y si quiero crear mi propia política de SnapMirror y especificar reglas diferentes? Pues en ese caso, como podemos ver a continuación, veremos que no es posible cuando usamos una política de tipo async-mirror.

Emepcemos creando una nueva política de Snapmirror en nuestro cluster destino, en la cual vamos a especificar que es de tipo async-mirror por tratarse de una relación SnapMirror y que habrá una regla para los snapshots con una etiqueta DEVELOP, forzando así que no se transfieran todos los snapshots que puedan existir en el volumen origen, sino solo aquellos que contengan dicha etiqueta. Esta política podemos crearla con el siguiente comando:

Creación de una política de SnapMirror.

Como ya hemos visto, esta política recien creada tiene por defecto la regla sm_created, para asegurar que se transferirá en todas las actualziaciones de la relación de protección, el snapshot creado por SnapMirror:

Nuestra política recien creada. La regla sm_created la incluye ONTAP.

Si ahora intentamos añadir la regla indicando la etiqueta de los snapshots de origen que queremos que se transfieran, que en este caso es DEVELOP recibiremos un bonito mensaje de error como el siguiente:

Error al intentar modificar una política de tipo async-mirror.

De nuevo pensemos que SnapMirror es una solución de disaster recovery, está diseñado para replicar todos los datos de nuestros volúmenes de origen y establecer reglas para determinadas etiquetas implicaría no replicar toda la información. Para poder establecer relaciones de protección, en las que controlar los snapshots de origen que deben transferirse a destino, tendremos que establecer relaciones de SnapVault lo cual veremos en futuras entradas.

Por tanto, y en resumen, las políticas de SnapMirror contienen reglas que definen su comportamiento. En el caso de las relaciones SnapMirror de tipo async-mirror, o lo que es lo mismo relaciones de protección para disaster recovery, estas reglas se asegurarán de transferir siempre la información actual del volumen origen y, si así lo deseamos, de todos los snapshots que se hayan generado desde la última transferencia de datos.

Cluster ONTAP - Replicación de datos con SnapMirror - Parte I

Hoy, después de mucho tiempo sin publicar nada sobre sistemas NetApp, vamos a revisar como podemos crear una estrategia de disaster recovery para proteger los datos almacenados en sistemas ONTAP. Cómo creo que es necesario que sea bastante detallado, voy a hacer una serie de posts sobre SnapMirror en sistemas cluster ONTAP, siendo este el primero de la serie y donde veremos como establecer la relación de peering entre los clusters y comenzaremos la creación de la relación de SnapMirror.

En un post anterior, nada menos que de 2015, ya explicaba como configurar y usar SnapMirror en sistemas ONTAP 7-mode con lo que, lo que vamos a ver en este nuevo post es similar, pero con las características de la versión cluster ONTAP.

Cómo ya sabemos, la replicación de datos entre sistemas ONTAP se basa en el uso de SnapMirror, con el cual podemos replicar los snapshots de un volumen a una localización de respaldo, desde donde servir los datos replicados en caso de desastre en el site principal. Cómo es lógico, en el caso de estar implementando una solución de backup a disco con SnapVault, ONTAP también está empleando SnapMirror para replicar los snapshots de los volúmenes, pero se establecen una serie de reglas de retención en función de nuestras necesidades de backup.

La principal diferencia que encontramos en cluster ONTAP, es la necesidad de crear una relación entre ambos clusters para poder establecer la relación de SnapMirror entre ellos. Esta medida de seguridad nos asegura que solamente los clusters autorizados podrán establecer una relación SnapMirror para la réplica de datos. Esta relación de peering debe existir también entre las SVMs propietarias de los volúmenes.

Adicionalmente, ya que en cluster ONTAP creamos SVMs para servidr datos mediante diferentes protocolos, podremos establecer relaciones de SnapMirror no solamente entre volúmenes, sino entre las SVMs propietarias de los volúmenes. De este modo, todo o parte de la configuración de la SVM se replicará al sistema secundario, así como los datos de los volúmenes de los que es propietaria la SVM. La replicación de SVMs la trataremos en otro post de la serie en más detalle.

Hay dos modos o motores de replicación diferentes implementados en ONTAP, denominados XDP (eXtended Data Protection) y DP (Data Protection). La diferencia fundamental entre ambos es que, si creamos una relación de SnapMirror de tipo DP, las versiones ONTAP de los sistemas involucrados debe ser la misma, mientras que el modo XDP soporta que las versiones sean diferentes. Este punto, aunque pueda parecer secundario, es importante por sus implicaciones y porque hasta ONTAP 9.3, DP era el modo por defecto empleado al crear una relación SnapMirror.

Para establecer la relación entre los clusters, o peering, es necesario que estos tenga interfaces dedicadas para la comunicación entre clusters, los denominados LIF de tipo intercluster. Estos LIFs deben existir en todos los nodos de los clusters que vayan formar parte de la relación de peering y pueden ser dedicados o compartidos con data LIFs. En resumen, necesitaremos crear tantos LIFs de tipo intercluster como nodos, siendo la configuración la habitual, tanto por CLI como usando OnCommand System Manager, pero especificando que el rol del LIF es intercluster.

Una vez que hemos contado todo el rollo teórico básico, vamos a la parte interesante y configuremos una relación de SnapMirror básica, siendo el punto de partida dos clusters de dos nodos con los LIFs de intercluster ya configurados:

LIFs intercluster configuradas.

LIFs intercluster configuradas.

Una vez creadas las LIFs de tipo intercluster y tras comprobar que existe conectividad y que ningún firewall nos impide el acceso a los puertos necesarios, creamos la relación de peering entre los dos clusters.

En versiones anteriores a ONTAP 9.3 el comando usado para crear la relación de peering era bastante largo, además de que era necesario especificar las direcciones IP de intercluster, con lo que era bastante más cómodo usar OnCommand System Manager para establecer la relación de peering.

A partir de ONTAP 9.3, el comando cluster peer create es mucho más simple y nos permite crear la relación de peering de una forma mucho más sencilla. Solo tenemos que lanzar el comando cluster peer create en el sistema ONTAP de destino, el cual generará una salida incluyendo la passphrase que usaremos para establecer el peering con el cluster de origen. Por ejemplo:

Creamos la relación de peering en el sistema ONTAP de destino.

Aceptamos la relación de peering en el sistema ONTAP de origen.

Como vemos, la creación de la relación de peering es muy simple y es importante tener en cuenta que la passphrase generada es única para cada ejecución del comando y válida solamente para un cluster. Solamente en el caso del sistema origen de nuestros datos es necesario que especifiquemos las direcciones IP de los LIFs intercluster del sistema ONTAP con el que queremos establecer la relación de peering.

Ahora podemos comprobar que la relación de peering es correcta entre ambos clusters:

Estado de la relación de peering en un cluster.

Estado de la relación de peering en el otro cluster.

Ahora establecemos la relación de peering entre las SVMs implicadas, para lo cual solo tenemos que lanzar el comando siguiente desde nuestro cluster ONTAP destino:

Creamos la relación de peering entre las SMVs. Es necesario especificar el tipo de aplicación.

Este comando crea una petición de peering que es necesario que aceptemos en el sistema ONTAP origen:

La petición de peering de SVMs pendieente en origen.

La petición de peering de SVMs pendieente en destino.

Para aceptar la petición de peering solo tenemos que lanzar el comando vserver peer accept:

Aceptamos la petición de peering entre las SVMs en el sistema ONTAP origen.

Tras lanzarlo podemos comprobar cómo la relación entre ambas SVMs pasa a estado peered.

Relación entre SVMs en estado peered.

En uno de los posts siguientes de esta serie veremos como podemos crear la relación de SnapMirror en un solo paso con el comando snapmirror protect, pero creo que para entender mejor ese comando y todo lo que implica, vamos a crear la relación de SnapMirror paso a paso.

Crear una relación de SnapMirror entre dos clusters implica realizar una serie de pasos simples los cuales, en resumen, son los siguientes:

1. Es necesario crear en el sistema destino un volumen que contendrá los datos del volumen origen. Cómo es lógico el tamaño del volumen destino debe ser igual o superior al de origen.
2. Creamos una programación o schedule para especificar cuando queremos que se realicen las actualizaciones de los datos entre los volúmenes de la relación SnapMirror.
3. Especificamos la política de replicación que queremos emplear. De esta manera establecemos que snapshots queremos transferir entre los clusters y como queremos hacerlo.
4. Creamos la relación de SnapMirror entre los volúmenes, en función de los pasos anteriores.
5. Inicializamos la relación de SnapMirror, realizando la copia de datos inicial que se denomina transferencia baseline.

Siguiendo los pasos anteriores, si quiero proteger el volumen VOL_nfsserver1_datos de la SVM SVM_nfsserver1, primero debo crear un volumen en el sistema destino. Por ejemplo, podemos hacerlo del siguiente modo y usando un nombre descriptivo que nos permita distinguir rápidamente que es un volumen replicado. Además es importante indicar que el tipo de volumen es DP, indicando así que se va a utilizar para destino de SnapMirror:

Creamos el volumen destino de tipo DP.

Aunque en este ejemplo no lo hemos especificado, el volumen puede ser thin provisioned, con lo que solo tenemos que especificar la opción space-guarantee a none en el momento de crearlo.

Ahora establecemos la programación de la tarea de replicación, para lo cual podemos crear uno o usar uno de los ya predefinidos. Suponiendo que necesitamos que nuestros datos se repliquen de lunes a viernes desde las 8:00, cada 3 horas, hasta las 23:00 horas, nuestro schedule podría ser el siguiente:

Creamos la programación de nuestra tarea de replicación.

Este schedule lo crearemos en el cluster destino ya que, es importante recordar que SnapMirror siempre se inicia en el sistema ONTAP destino el cual hace un pull de los datos desde el sistema origen.

Ahora necesitamos crear la política de replicación o bien usar una de las predefinidas. En este caso, y por sencillez, vamos a usar la política MirrorAllSnapshots, mediante la cual SnapMirror trnasferirá todos los snapshots, tanto en la inicialización cómo en las actualizaciones. Así conseguimos que los snapshots que realice el sistema ONTAP origen también se transfieran al sistema destino.

Con los datos anteriores, el comando que debemos utilizar en el cluster destino para establecer la relación de SnapMirror es el siguiente:

Creamos la relación de SnapMirror entre los dos volúmenes.

Ahora podemos ver que la relación de SnapMirror esta creada pero no inicializada, todavía no se ha transferido ningún dato entre ambos volúmenes:

La relación de SnapMirror creada pero no inicializada.

Para inicializarla es necesario realizar la primera copia, llamada baseline transfer, entre ambos volúmenes. De esta manera todos los datos del volumen, así como todos los snapshots existentes, se transferirán al volumen destino ya que la política que hemos especificado es MirrorAllSnapshots. Para lanzar la transferencia baseline, y por tanto inicializar de forma efectiva la relación de SnapMirror, solo tenemos que lanzar el siguiente comando desde el sistema ONTAP destino:

Lanzamos la transferencia baseline entre ambos volúmenes.

Esta transferencia inicial tardará más o menos timepo, dependiendo de la cantidad de información que deba transferir.

Proceso de inicialización de la relación SnapMirror.

Una vez terminado el proceso de transferencia inicial, podremos comprobar que la relación SnapMirror ha pasado a estado Snapmirrored y, más importante todavía, que todos los datos, así como los snapshots del volumen origen, se han replicado al volumen destino.

La relación SnapMirror ya establecida entre ambos volúmenes.

Lista de snapshots en el volumen destino.

Con esto ya hemos establecido la relación de SnapMirror entre nuestros dos sistemas ONTAP y hemos protegido un volumen. En las siguientes entradas de esta serie veremos más en detalle los tipos de políticas existentes, como establecer relaciones de DR para SVMs completas y como usar los datos replicados en caso de desastre.

Cluster ONTAP - Configuración de SVMs con subredes

Hoy vamos con una entrada sencilla de cluster ONTAP. Veamos como podemos usar la característica de subnets o subredes, para configurar de forma automática la red de nuestras SVMs.

Mediante el uso de subredes, la configuración de red de cualquier SVM se realizará de forma automática. Al aplicar una subred a una SVM configuraremos la dirección IP, la máscara de subred y el gateway de la LIF asociada a dicha SVM.

Esta característica está claramente orientada a los proveedores de servicio, donde cada cliente tendrá su propia red separada del resto.

Veamos como crear una subred y aplicarla a la configuración de nuestras SVMs.

Primero crearemos un IPspace y un dominio de broadcast, en el que incluiremos los puertos físicos que tendrán acceso a dicha red:

Creación del IPspace y dominio de broadcast para la subred.

Al listar los puertos de red de nuestro cluster, podremos comprobar que los puertos especificados están en el IPspace y dominio de broadcast recien creados:

Puertos ethernet del cluster, IPspace y dominio de broadcast.

Ahora podemos crear la subred, lo más importante es definir el pool de direcciones IP que se asignarán a las SVMs en el momento de crearlas:

Creación de la subred.

Nuestra subred desde OnCommand System Manager.

Ahora, en el momento de configurar la red de una nueva SVM, elegiremos Using a subnet y seleccionaremos la subred recien creada:

Creación de una SVM con una subred, asignamos el IPspace.

Creación de una SVM con una subred, configuración del data LIF.

Información de uso de la subred desde OnCommand System Manager.

Como vemos, la LIF de la nueva SVM tiene habilitado el DNS dinámico, pero dentro de la configuración de la SVM será necesario habilitarlo si disponemos de un servidor DNS que permita las, tan temidas por algunos, actualizaciones dinámicas:

Configuración del data LIF de la nueva SVM. La opción DDNS está activada.

Habilitamos el DNS dinámico en la configuración de la SVM.

Al permitir las actualizaciones automáticas en el DNS la IP se registrará perfectamente.

Por tanto, como vemosc los sistemas NetApp nos permiten configurar de forma rápida las LIFs de nuestras SVMs y además, de una forma muy simple, integrarlo con nuestro servicio DNS.

En próximas entradas veremos como podemos replicar datos usando SnapMirror para establecer una estrategia de recuperación de desastres.

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.