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.

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.