Conceptos avanzados de imágenes Docker - Parte III

Hola de nuevo, hoy seguimos trabajando con la construcción de imágenes para Docker. En este caso veremos como añadir opciones que nos permitan configurar los servicios que despliegan, según nuestras necesidades.

Siguiendo con nuestra imagen de un servicio de directorio basado en OpenLDAP,  vamos a ver como podemos especificar las opciones de configuración del mismo.

Con la imagen realizada hasta ahora se incluye el fichero de configuracion de OpenLDAP, que se encuentra en la ruta /ldap/etc/openldap/slapd.conf y que tiene una configuración por defecto.

Como es lógico, esta configuración no nos será de gran utilidad y necesitaremos cambiarla en función de nuestro servicio.

Para poder configurar adecuadamente el servidor OpenLDAP de nuestra imagen tenemos dos opciones, aunque en general podemos optar por estas dos aproximaciones para cualquier software contenido en una imagen cuya configuración dependa de un fichero o ficheros de texto.

La primera es, sabiendo donde está el fichero de configuración dentro de la imagen, montar un volumen que contenga un fichero slapd.conf que establezca la configuración deseada en el momento de crear un contenedor, por ejemplo:

Establecemos la configuración del servidor OpenLDAP con un volumen que contiene la configuración.

La otra opción consiste en complicar un poco nuestra imagen, usando un script de arranque que utilice los valores de variables de entorno que pasaremos a nuestro contenedor en el momento de su creación. Aunque puede sonar un poco complicado, vamos a ver que es muy sencillo.

Vamos a empezar con un ejemplo muy simple, para ello vamos a crear un contenedor en el que vamos a inyectar unas variables de entorno y vamos a comprobar como estas variables pasan a estar disponibles dentro del contenedor. Para inyectar variables en un contenedor solo tenemos que usar la opción --env en el momento de su creación es decir, solo tenemos que hacer algo como lo siguiente:

Inyección de variables de entorno en un contenedor.

Como es lógico podemos pasar tantas variables de entorno como necesitemos y, como vemos, conservarán el nombre y valor asignado. Por tanto, teniendo esto en cuenta, podemos hacer un script que recoja dichas variables de entorno y sustituya los valores de las mismas en el fichero de configuración de nuestro servicio, que en nuestro ejemplo es un servidor OpenLDAP.

Como el punto importante en este caso es el script que debemos crear, vamos a empezar por hacer una prueba sencilla con una imagen diferente. Este script debe comprobar si existen las variables de entorno, usarlas para cambiar el contenido del fichero de configuración slapd.conf y arrancar el demonio slapd. Adicionalmente debería mostrar un mensaje en stderr si falta alguna de las variables de configuración necesarias.

Como ejemplo de lo que podemos hacer en función de nuestras necesidades, esta sería la salida de una imagen de test generada a partir de la imagen ldap original. En ella hemos cambiado el ENTRYPOINT por nuestro nuevo script el cual, de momento, solo comprueba las variables pasadas y las registra en STDOUT y STDERR:

Creación del contenedor sin las variables requeridas.

En el caso de arrancar un contenedor con las variables requeridas por el servicio, la salida mostrada será la siguiente:

Creación del contenedor con todas las variables necesarias para la configuración del servicio OpenLDAP.

Por tanto, ya solo nos queda modificar el script para incluir una linea que arranque el servidor OpenLDAP, para lo cual lo mejor es incluir una llamada como la siguiente:

Arranque del servicio en nuestro script de inicio de la imagen ldap.

De este modo nos aseguramos que las señales enviadas al contenedor llegan de manera correcta al demonio slapd y que este se cierra ordenadamente cuando lo paremos.

Ahora podemos o bien crear una nueva imagen, cambiando el ENTRYPOINT para que use nuestro nuevo script o bien generar una imagen a partir de la original. En mi opinión, siempre dependiendo del servicio y teniendo bien documentadas las diferencias entre nuestras imágenes, creo que lo mejor es mantener ambas imágenes y usar una u otra en función de las necesidades que tengamos en cada momento.

El script creado para este caso está disponible via git en https://github.com/locurastecnicas/DOCKER_scripts. Este script es muy mejorable ya que, al menos, debería generar la password de forma aleatoria en caso de no proporcionarla mediante una variable.

Trabajando con Jenkins en contenedores

Supongamos que tenemos un contenedor generado a partir de una imagen de Jenkins con el que queremos trabajar en nuestro entorno de CI/CD. Si creamos el contenedor de manera que sea efímero, al pararlo perderemos toda nuestra configuración salvo que seamos capaces de mantener el directorio que contiene toda la configuración del servicio Jenkins.

Para poder mantener dicha configuración, primero acudimos a la documentación de Jenkins la cual, en la URL https://wiki.jenkins.io/display/JENKINS/Administering+Jenkins, nos indica que toda la información de configuración utilizada por Jenkins se almacena en la ruta dada por la variable JENKINS_HOME. Si inspeccionamos la imagen podremos ver lo siguiente:

Variables de entorno de la imagen de Jenkins.

Adicionalmente veremos una referencia a un volumen en la definición de dicha imagen:

Declaración de volumen en la imagen de Jenkins.

Por tanto queda claro que necesitamos mantener el contenido de dicha ruta, si queremos mantener la configuración de nuestro servicio jenkins.

Ahora bien, ya tenemos un contenedor corriendo y hemos generado cierta configuración que no queremos perder, con lo que necesitamos saber donde está almacenada localmente dicha información para poder copiarla. Si inspeccionamos el contendor que está corriendo en nuestro sistema veremos lo siguiente:

Definición de montaje del volumen local para JENKINS_HOME.

Y al inspeccionar esta ruta tenemos lo siguiente, que veremos que coincide con el directorio de configuración de Jenkins:

El directorio de configuración del contenedor de Jenkins en nuestro disco local.

Por tanto copiamos todos esos ficheros a otra ruta local, que será la que utilizaremos como volumen para nuestro servicio Jenkins y volvemos a crear un nuevo contenedor efímero, pero esta vez mapeamos un volumen que apunte a esta nueva ruta que acabamos de crear:

Creación de nuevo contenedor con mapeo de volumen a la configuración de Jenkins.

Y como podemos comprobar, el servicio Jenkins vuelve a estar disponible con la configuración que hubiésemos realizado hasta ese momento:

Servicio Jenkins disponible con configuración existente.

A partir de este punto podemos seguir configurando y utilizando el servicio sin problemas. Siguiente parada, ejecución de compiladores mediante contenedores específicos para cada job.

Cluster ONTAP - Mapeo de usuarios

Como ya comenté en la entrada sobre acceso multiprotocolo, hay un concepto asociado a los accesos CIFS que es fundamental y que es muy importante comprender.

Siempre que un sistema cliente Windows accede a una carpeta compartida por CIFS, independientemente de si es un sistema NetApp 7-mode o C-mode, se realiza un mapeo de usuarios de Windows a Unix.

Esto se explica teniendo en cuenta los orígenes de los sistemas NetApp como servidores NFS y que están basados en FreeBSD.

Puede que no sea muy intuitivo pero, aunque no estemos hablando de acceso multiprotocolo este mapeo de usuarios siempre es necesario y en caso de que no se realice correctamente, se denegará el acceso al share.

Vamos a ver esto resumido con unos cuantos ejemplos empezando con una SVM que solo proporcione acceso CIFS. Este caso, que es el más simple, nos permite ver las opciones existentes para mapear usuarios.

Cuando creamos una SVM con protocolo CIFS, la unimos a un dominio y creamos un share CIFS, cuando nos conectamos y consultamos las sesiones CIFS veremos lo siguiente:

Sesiones CIFS existentes en una SVM.

 En la salida anterior vemos que nuestro usuario del dominio, se ha mapeado al usuario Unix pcuser. La pregunta evidente es de donde sale ese usuario y como se ha establecido dicho mapeo.

Si analizamos la configuración del servidor CIFS de nuestra SVM, usando el comando cifs options show, veremos un montón de opciones de configuración y entre ellas, la siguiente:

Opciones de configuración del servidor CIFS de una SVM.

Esa opción denominada Default Unix User, es la que establece que usuario se usará por defecto para mapear cualquier usuario Windows que se conecte a este servidor CIFS, sino hay otro método establecido de mapeo. En ONTAP 7-mode el equivalente es usar el comando options con la opción de configuración wafl.default_unix_user la cual, por defecto, también es pcuser.

Lo que nos queda es saber de donde sale ese usurio, para lo cual, solo tenemos que revisar los usuarios de la SVM desde la sección SVM Settings:

Usuarios Unix locales de una SVM.

Por tanto, como podemos ver, una SVM tendrá un conjunto de usuarios Unix por defecto, entre ellos el usuario pcuser que se usará por defecto para mapear a cualqueir usuario Windows que se conecte a una carpeta compartida mediante CIFS.

Como vemos hay un apartado Name Mapping desde el cual podemos crear nuestras propias reglas de mapeo en caso de ser necesario. Hagamos una prueba y creemos una regla de mapeo según la cual para determinados usuarios del dominio vamos a usar un usuario Unix local de la SVM diferente. Para esto creamos un par de usuarios Unix nuevos en la SVM, que llamaremos proyecto1 y proyecto2:

Creamos dos nuevos usuarios locales Unix en la SVM.

Y ahora establecemos reglas de mapeo específicas para los usuarios del dominio usrprj1 y usrprj2, para esto solo necesitamos crear las reglas en el apartado Name Mapping desde SVM Settings, las cuales serán:

Regla de mapeo para un usuario de Windows a Unix.

Reglas de mapeo de Win a Unix establecidas para dos usuarios del dominio.

Con estas dos reglas creadas, al conectarnos de nuevo a la carpeta compartida por CIFS tendremos el siguiente resultado:

Sesión CIFS establecida para un usuario con mapeo específico.

Si nos conectamos a esa misma carpeta compartida con un usuario que no tenga ninguna regla de mapeo específica, lo que tendremos será lo siguiente:

Conexión de un usuario con mapeo por defecto.

Con lo que, evidentemente se utiliza el uusario pcuser por defecto para realizar el mapeo del usuario Windows que realiza la conexión.

El hecho de que se especifique un usuario Unix para el mapeo es muy importante en el caso de acceso multiprotocolo como vimos en la entrada anterior, ya que los permisos del sistema de archivos en una SVM multiprotocolo deberían ser Unix, mientras que en una SVM CIFS como la de nuestro ejemplo, el sistema de archivos que debemos usar en nuestra SVM debe ser NTFS.

Es decir, lo recomendado cuando tengamos que crear una SVM a la que solo accederán clientes Windos mediante protocolo CIFS, es que la seguridad del sistema de archivos sea NTFS y que dejemos las opciones de mapeo de usuarios por defecto. De este modo no tendremos ningún problema de acceso ni permisos ya que, como podemos ver, el sistema de archivos de la SVM establece perfectamente los permisos según los usuarios del dominio e independientemente de los mapeos de los usuarios:

Permisos NTFS en el share de la SVM.

Al pasar a un entorno multiprotocolo, como el explicado en el post anterior, la cosa se complica un poco más ya que, como vimos, clientes CIFS y NFS accederán a la misma información, en ocasiones simultáneamente. Como un acceso CIFS desde un cliente Windows siempre requiere un mapeo correcto de usuario, el mapeo debe realizarse a un usuario Unix válido conocido por los sistemas cliente Unix o Linux que accederán a la misma información mediante el protocolo NFS.

Esto nos lleva a que la SVM debe usar como servicio de nombres el mismo que usen nuestros clientes NFS, ya que dicho servicio debe contener todos los usuarios válidos y al mismo tiempo, nos debe permitir realizar el mapeo entre clientes Windows y Unix.

 

Para estos entornos, lo recomendado es disponer de un dominio Windows, al que uniremos nuestra SVM y que además usaremos de servicio de nombres para nuestras máquinas cliente Unix o Linux así como para nuestra SVM. Hay más opciones disponibles, como usar un servidor OpenLDAP como servicio de nombres implementando el esquema LDAP correspondiente a la RFC 2307 para nuestros sistemas Unix y AD para los sistemas Windows, pero creo que lo más sencillo es disponer de una sola fuente de nombres basada en AD.

Entre los muchos atributos de las entradas de grupos y cuentas de usuario de AD, hay una serie de atributos correspondientes a la RFC 2307 que, mediante la correcta configuración del servicio de nombres de los clientes Unix y Linux y de nuestras SVMs, podremos usar para obtener información de usuarios y grupos, además de poder realizar el mapeo de usuarios del que estamos hablando.

Veamos algunos de esos atributos directamente en las cuentas de usuario de nuestro laboratorio de pruebas:

Editor de atributos de una cuenta de usuario.

Como vemos, hay una serie de atributos que contienen valores que definen una cuenta de usuario de un sistema Unix o Linux, como homeDirectory, loginShell o gidNumber, así como la definición de la clase de objeto posixAccount. En concreto la lista de atributos y clases de objeto está definida en la RFC 2307 y es recomendable su consulta para implementar un servidor LDAP como servicio de nombres para máquinas Unix o Linux.

En el caso de nuestras SVMs, debemos configurarlas para que usen como servicio de nombres de grupos y cuentas de usuario un servidor LDAP, para lo cual solo tenemos que utilizar los siguientes comandos:

Configuración del cliente LDAP de una SVM.

Configuración servicio de nombres de una SVM para que use LDAP para usuarios y grupos.

De este modo estamos configurando el cliente LDAP de la SVM para que busque la información de grupos y nombres en un servidor LDAP, indicando el DN para realizar las búsquedas, así como el dominio de AD existente, las bases de búsuqeda para cuentas de usuario y de grupo así como el ámbito de las búsquedas.

Con esta configuración establecida, al conectar mediante el protocolo CIFS a nuestra SVM multiprotocolo ya vimos que el mapeo se realizaba correctamente y que al escribir o crear datos, los permisos eran los del usuario mapeado:

Mapeo correcto de usuario Windows a usuario Unix.

Creación de una carpeta en el share.

Comprobamos que la carpeta se ha creado con el usuario Unix mapeado correcto.

Por tanto, si queremos usar SVMs en entornos multiprotocolo, lo recomendado es configurar nuestro servicio de nombres para que use nuestros DCs como fuente de nombres, tanto para los clientes Unix y Linux como para las SVMs. De este modo solo tendremos un servicio de nombres y, el principal problema será la modificación de forma correcta de los atributos correspondientes en AD, pero para esto solo hace falta un poco de Perl o Python y una pequeña web que nos deje modificarlos de forma simple o bien implementarlo en el proceso de alta de usuarios con scripts PowerShell.

Usando Jenkins como gestor de eventos

Hay ocasiones en las que ciertas herramientas pueden usarse para resolver problemas de administración, aunque sus funcionalidades estén enfocadas a otros ámbitos.

Imaginemos que al terminar la instalación de un sistema, es necesario realizar ciertas tareas adicionales que requieren acceso a una red aislada, pero el equipo en cuestión no tiene permisos de acceso a dicha red. Por ejemplo pensemos en la instalación y configuración de un equipo de usuario que, en su paso final debe acceder a la red de administración para lanzar un script que realizará unas tareas de configuración adicionales.

Para casos similares a este y muchos otros más, podemos usar Jenkins configurando un job parametrizable que podremos lanzar mediante una simple petición HTTP POST.

La idea es usar Jenkins como gestor de eventos, siendo el evento generado por nosotros mediante la petición HTTP la cual, al corresponder a un job configurado, ejecutará un script con los parámetros que pasemos en la petición.

Lo primero es crear un usuario que será el que utilicemos para todas las tareas de gestión de eventos y darle los permisos necesarios que, si estamos usando el modo de seguridad basado en proyecto, deben ser al menos de lectura global, de lectura y ejecución de jobs y de update de ejecuciones. Para diferenciar este usuario del resto lo mejor es darle un nombre distintivo, en nuestro caso creamos el usuario Event Manager (eventmgr).

Ahora, para definir el job solo tenemos que asegurarnos de marcar la opción Esta ejecución debe parametrizarse y Lanzar ejecuciones remotas. En resumen, la forma de configurarlo es la siguiente:

Creación inicial del job y asignación de seguridad.

Configuración de parametrización y especificación de los parámetros.

Marcamos el job como ejecutable remotamente y generamos un token de seguridad.

Especificamos que se ejecutará, en este caso de ejemplo un simple echo.

Con el job ya configurado, lo único que es necesario hacer ya es lanzar una petición HTTP a nuestro servidor Jenkins con los parámetros necesario, en nuestro ejemplo solo nos va a generar un fichero con los valores de ambos parámetros. La URL a la que debemos realizar la petición HTTP será:

Acceso a la URL especificando los parámetros para nuestro job.

Y podemos comprobar que el job se ha ejecutado correctamente y ha generado el fichero con los valores especificados en los parámetros pasados al job:

Resultado de la ejecución del job.

Por tanto con Jenkins podremos realizar acciones basándonos en eventos que nosotros mismos generemos, lo cual nos facilitará bastante ciertas tareas administrativas.

Cluster ONTAP - Acceso multiprotocolo

Hoy continuamos la entrada anterior, en la que trabajamos con SVMs básicas, con una nueva entrada en la que vamos a seguir trabajando con SVMs pero en este caso, configuraremos una SVM multiprotocolo.

¿Que nos permite una SVM multiprotocolo? Poder acceder a nuestros datos en un entorno NAS usando NFS y CIFS, algo que con sistemas ONTAP es posible y simple de configurar.

El acceso multiprotocolo está indicado para entornos heterogéneos, donde tenemos clientes Unix, Linux y Windows que necesitan acceder a los mismos datos simultáneamente.

Ya vimos en la anterior entrada como crear una SVM, concretamente una NFS para clientes Unix y Linux. Lo que haremos ahora es añadir a dicha SVM el protocolo CIFS y configurarla para unirla a un dominio Windows para nuestras pruebas.

Para empezar necesitamos añadir el protocolo CIFS a la SVM ya existente, para esto solo tenemos que abrir OnCommand System Manager y en el apartado SVMs seleccionamos la que vamos a editar y añadimos el protocolo CIFS a la misma:

Añadimos el protocolo CIFS a la SVM existente.

Al hacer esto, OnCommand nos mostrará un mensaje de advertencia indicándonos que debemos configurar el protocolo CIFS. Para poder continuar y realizar esta configuración, debemos añadir CIFS como protocolo de datos a la LIF de esta SVM. Como de momento, oajalá NetApp cambie pronto este pequeño problema, solo puede hacerse en el momento de crear la LIF, necesitamos destruir nuestra LIF actual y crearla de nuevo con ambos protocolos:

Creamos una nueva LIF con ambos protocolos para nuestra SVM.

Ahora continuamos y, desde la sección de SVMs, seleccionamos la que estamos configurando, pinchamos sobre SVM Settings y pasaremos a las opciones de configuración generales de la SVM. Ahora desde la sección CIFS de este apartado, solo tenemos que pinchar sobre Setup para configurar el servicio CIFS:

Configuración de SVM, vamos a configurar el protocolo CIFS.

Configuración del servicio CIFS de la SVM.

Una vez configurado el servidor CIFS, podemos ver como el estado del servidor CIFS ha cambiado a iniciado y refleja el nombre del dominio al que pertenece la SVM:

Servidor CIFS de una SVM configurado y unido a un dominio.

Los puntos mas importantes a tener en cuenta para poder unir correctamente una SVM a un dominio Windows son la resolución DNS, la sincronización horaria entre el cluster y los controladores de dominio y que utilicemos un usuario del dominio con permisos para añadir máquinas.

Como podemos comprobar, una nueva cuenta de equipo correspondiente a nuestra SVM aparece en nuestro DC de laboratorio:

Cuenta de equipo correspondiente a nuestra SVM.

Antes de continuar debemos tener en cuenta un punto muy importante, el cual es imprescindible entender correctamente cuando hablamos de acceso CIFS en sistemas ONTAP. Cuando un cliente Windows se conecta a una carpeta compartida desde una SVM, esta siempre va a realizar un mapeo del usuario que realiza la petición de conexión a un usuario Unix. Este punto implica que debemos tener una forma de mapear nuestros usuarios Windows, ya sean de un dominio o un grupo de trabajo, a usuarios Unix que pueden ser locales a la SVM o proprocionados por un servicio de nombres externo. En una entrada posterior explicaré este punto más detenidamente, por ahora solo debemos tener en cuenta que, para asegurar que nuestros usuarios del dominio de laboratorio pueden acceder y escribir en nuestra carpeta compartida por CIFS, necesitamos cambiar ciertos atributos de sus entradas en Active Directory para que contengan los mismos valores que los usuarios homónimos en nuestra máquina Linux y establecer la configuración de mapeo en nuestra SVM.

Una vez configurada la SVM, vamos a compartir el qtree que creamos con anterioridad usando el protocolo CIFS, con lo que podremos acceder a la misma información desde sistemas Windows. Para compartir un qtree mediante el protocolo CIFS solo es necesario realizar la siguiente configuración desde la sección Shares del apartado Storage:

Creación de un nuevo share.

Y a continuación modificamos los permisos de acceso para que solo un grupo determinado de usuarios pueda montar dicha carpeta remotamente, por ejemplo vamos a permitirlo solo a los miembros de un determinado grupo. Para esto solo tenemos que editar nuestro share y, desde la pestaña Permissions, añadir el grupo deseado:

Modificación de los permisos de acceso al share.

Ahora solo nos queda probar el acceso desde una máquina Linux y una máquina Windows a esta carpeta con los usuarios adecuados para confirmar que se accede correctamente desde ambos y que se pueden compartir los datos sin problemas.

Montamos la carpeta por NFS y modificamos los permisos de la misma para que solo los miembros del grupo Proyecto2 puedan acceder a la misma y creamos un par de archivos de prueba con esos usuarios:

Pruebas de acceso a la carpeta desde Linux.

Ahora accedemos al share desde una sistema Windows y si hemos configurado todo adecuadamente, deberíamos ver el contenido de la carpeta:

Conexión al share CIFS creado en nuestra SVM.

La misma carpeta accediendo desde un sistema Windows.

Esto ya es un avance bastante importante, ahora solo nos queda comprobar que sucede cuando escribimos y leemos desde ambos sistemas. Si creo un archivo desde mi cliente Windows tengo que verlo con los permisos adecuados desde mi máquina Linux:

Creo un archivo desde el sistema Windows.

Y puedo verlo desde la máquina Linux.

Es importante darse cuenta que, aunque he creado el fichero desde un sistema Windows, el propietario del mismo es el usuario usrprj2.

Ahora puedo editar ese fichero desde mi sistema Linux y añadir datos que luego podré ver desde el cliente Windows y modificarlos:

Añadimos datos desde el sistema Linux.

Comprobamos desde el cliente Windows que podemos modificar los datos.

Y volvemos a comporbar que nuestro sistema Linux accede a los datos.

Una última comprobación que es recomendable realizar es comprobar que la sesión CIFS muestra un mapeo correcto entre el usuario Windows de dominio y el usuario Unix con el que se mapea. Para esto necesitamos lanzar el comando siguiente:

Comprobación de sesion CIFS.

Como podemos ver en la salida anterior, el usuario del dominio LAB\usrprj2 se ha mapeado correctamente con el usuario UNIX usrprj2 lo que nos permite acceder sin problemas al share y mantener los permisos que hacen posible el acceso desde un sistema Unix o Linux.

En resumen, los sistemas  ONTAP nos permiten compartir sin problemas en entornos heterogéneos siendo los puntos más importantes a tener en cuenta una correcta configuración de red y resolución DNS, la sincronización horaria entre todos los sistemas involucrados, principalmente el cluster  y los DCs y la correcta configuración del sistema de mapeo de usuarios en la SVM multiprotocolo.

En las próximas entradas comentaré más en detalle como funciona el mapeo entre usuario y como configurarlo, ya que es fundamental para este tipo de entornos.

Cluster ONTAP - Trabajando con SVMs

Hola de nuevo, en esta entrada vamos a seguir trabajando con cluster ONTAP definiendo máquinas virtuales de almacenamiento (SVMs) para proporcionar servicios de fichero o bloque a nuestros clientes.

Como ya vimos en las entradas anteriores, una SVM es una instancia de uno o más protocolos de acceso proporcionados por ONTAP. Es decir, una SVM proporcionará servicios de acceso a fichero (NFS, CIFS) o bloque (FCP, iSCSI, FCoE) de forma aislada al resto de SVMs del cluster.

Cada SVM tendrá sus volúmenes propios y separados del resto, aunque dentro de los mismos agregados que el resto de posibles SVMs del cluster.

Por último, una SVM tendrá una o más interfaces lógicas de red (LIFs) para permitir el acceso a los datos, ya sea mediante protocolos como NFS, CIFS o iSCSI o interfaces de fibra dedicadas para una SAN y acceso mediante FCP.

Teniendo todo esto en cuenta pasemos a crear una SVM básica. Para ello vamos a usar la interfaz gráfica y luego crearemos otra mediante el interfaz de línea de comandos.

Gran parte de la administración puede realizarse desde el OnCommand System Manager que está incluido en el sistema y que es accesible desde la dirección de administración del cluster. Con lo que nos conectamos y encontraremos el siguiente dashboard de inicio:

Pantalla de login a OnCommand System Manager.

Dashboard principal de OnCommand System Manager.

Para aquellos acostumbrados a utilizar OnCommand Unified Manager, el dashboard de OnCommand System Manager incluido en las recientes versiones de ONTAP 9.3 y 9.4, les será muy familiar.

Para crear una SVM desde OnCommand System Manager solo tenemos que navegar hasta el apartado SVMs dentro de la sección Storage:

Creación de SVMs desde OnCommand System Manager.

Como es lógico, desde aquí veremos que el proceso es muy simple y solo necesitamos seguir el asistente de creación que aparece al pinchar sobre Create. De forma resumida, la creación de una SVM podemos verla en las imágenes siguientes:

Lanzamos el asistente de creación de una SVM.

Configuramos la red de la nueva SVM.

Fijamos la contraseña del usuario vsadmin de la SVM.

Con esto ya tenemos nuestra nueva SVM que, de momento, solo tiene su volumen root de configuración, con lo que añadimos un nuevo volumen donde crearemos los qtrees que luego exportaremos por NFS. Para esto, desde la sección Storage solo es necesario que dentro de Volumes escojamos nuestra SVM para añadir un volumen de datos a la misma. Realizamos la configuración básica del volumen y el resto de opciones, las configuraremos más tarde:

Creación básica de un volumen.

Una de las primeras opciones que vamos a cambiar es la política de snapshots, es decir, cuando vamos a hacer un snapshot de un volumen y cuantos snapshots vamos a mantener de cada tipo. Para esto solo es necesario que seleccionemos Snapshot Policies dentro de la sección Protection y creemos una nueva política de snapshots en la que podemos usar una programación ya definidia o una creada por nosotros:

Creación de una política de snapshots.

De esta manera establecemos una política de snapshots en la cual, usando una programación específica, se crearán tres snapshtos diarios a las 8:00, a las 14:00 y a las 18:00 y queremos que se mantengan 21 de esos snapsots, lo que nos da un total de 7 días con lo que, cuando se lance el snapshot de las 8:00 horas el octavo día, se borrará automáticamente el snapshot de las 8:00 horas del día 1.

Ahora solo tenemos que modificar el volumen que hemos creado para nuestra SVM y cambiar la política de snapshots del volumen:

Configurando la política de snapshots de un volumen.

Seleccionamos la política que hemos creado antes.

Adicionalmente podemos configurar las opciones de deduplicación del volumen y asignar una programación para dichas tareas, así como las opciones de autosize del volumen si es necesario.

Para terminar solo nos falta crear un qtree y compartirlo por NFS con el resto de nuestras máquinas, para esto solo tenemos que crear una polítca de exports NFS, para especificar que permisos damos en función de las direcciones IP de los clientes, crear el qtree y aplicar la política de exportación que hemos creado. De forma resumida podemos verlo del siguiente modo:

Creación y exportación de un qtree.

Editando el qtree podremos fijar una cuota en el mismo para evitar que el cliente o clientes que monten dicho recurso por NFS, no consuman todo el espacio disponible en el volumen.

Por último desde nuestro cliente, montamos el recurso NFS para comprobar que la configuración es correcta y que la cuota se está aplicando correctamente:

Montando el qtree exportado por NFS en el cliente.

Como vemos en la salida anterio, nuestro volumen es de 1 GB pero, al aplicar una cuota de 200 MB al qtree, el espacio disponible en el cliente es de tan solo 200 MB.

Ahora que hemos visto como hacerlo graficamente, pasemos a crear una SVM por línea de comandos lo cual veremos que es igual de sencillo aunque más largo. Para ello lo primero que debemos hacer es conectarnos al cluster por ssh y una vez iniciada la sesión, solo tenemos que usar el comando vserver con unas cuantas opciones, como podemos ver en la siguiente imagen:

Creación de una nueva SVM.

A continuación tenemos que configurar los protocolos que queremos que la nueva SVM uilice para servir datos, darle una nueva interfaz lógica con una dirección IP, ya que se trata de una SVM que dará servicio NAS y crear un nuevo volumen de datos para la misma. Todo esto podemos verlo en las siguientes imágenes:

Seleccionamos que protocolos usará la nueva SVM.

Creamos una nueva LIF y la asignamos a la SVM recien creada.

Creamos un nuevo volumen de datos para la nueva SVM.

Para terminar, asignamos la política de snapshots que hemos creado antes a este nuevo volumen. Adicionalmente crearemos una política de export NFS que aplicaremos al volumen y crearemos un qtree que exportaremos a nuestras máquinas cliente:

Asignamos la política de snapshots al nuevo volumen. El warning indica el cambio de política.

Creación de una política de export y un qtree que se comparte por NFS.

Ya solo nos falta aplicar una cuota a dicho volumen, como hemos hecho en el caso anterior y montar el recurso NFS en nuestra máquina cliente:

Creación y aplicación de la cuota.

Tras montar el directorio en el cliente veremos que el espacio disponible es de 200 MB, como en el caso anterior.

Como es lógico, el proceso de crear una SVM por línea de comandos es algo más largo pero, teniendo claro todas las partes que la forman y los requisitos necesarios, solo es cuestión de usar los comandos adecuados.

En caso de crear una SVM que sirviese datos a clientes Windows, o una SVM multiprotocolo para clientes Windows y Linux, podremos unir la SVM a un dominio Windows sin problemas, pero ese ejemplo lo dejaremos para otro día.

En las próximas entradas, además de revisar las SVMs con acceso CIFS o multiprotocolo, también veremos como funcionan las relaciones de protección SnapMirror y SnapVault en las nuevas versiones y como crearlas.