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.

Nuevas características de ONTAP 9.4

Hola de nuevo, casi sin tiempo para nada más ya nos encontramos con la nueva versión de ONTAP disponible para poder desplegarla en nuestros sistemas. La nueva versión 9.4 de ONTAP tiene características tan interesantes como las siguientes:

• Un volumen puede contener hasta 1023 snapshots. Esto nos permitirá ampliar la retención de aquellos volúmenes protegidos con SnapVault con lo que, para entornos en los que todavía necesitamos cintas, es una gran noticia que nos acerca a poder eliminar una buena cantidad de ellas, aunque solo sea para los backups incrementales diarios. Esta nueva característica se aplica a los volúmenes destino de una relación de SnapMirror, que ahora podrán mantener hasta 1019 snapshots.
• Desde ONTAP 9.3 ya existe la opción de crear un relación de protección con un solo comando. Usando el comando snapmirror protect podemos establecer dicha relación en un solo paso.
• Simplificación en el proceso de peering entre clusters y SVMs. Ahora, usando la opción generate-passphrase en el cluster de destino, podemos generar una contraseña válida solamente durante un tiempo determinado y para un solo cluster que, usada en el clsuter origen nos permitirá establecer la relación de peering entre ambos cluster mucho más rápidamente.
• Aunque es una funcionalidad existente desde la versión 9 de ONTAP, es importante recordar la posibilidad de utilizar RAID de triple paridad, o RAID-TEC, en nuestros aregados para asegurar que aquellos más grandes puedan soportar el fallo simultaneo de hasta tres discos.
• Se ha incluido soporte para CIFS multicanal, lo que permite un rendimiento mayor y tolerancia a fallos entre los clientes CIFS y nuestras SVMs.
• Esta nueva versión incluye soporte para NVMe sobre Fibre Channel (NVMe/FC) con lo que, con una conectividad completa NVMe/FC de un extremo a otro, las mejoras en rendimiento al sustituir nuestro viejo protocolo SCSI por el nuevo protocolo NVMe son enormes. Es importante tener en cuenta que la especificación para multipath del protocolo NVMe, llamada Asymmetric Namespace Access (ANA), está todavía en desarrollo.

Estas son solo algunas de las características que me han parecido más importantes así que, si queréis saber más, os recomiendo visitar la página de NetApp para obtener una lista de todas las nuevas funcionalidades en las release notes de la versión 9.4.

Creo que ya es hora de bajar la última versión del simulador de ONTAP para empezar a probar algunas de esas nuevas características en acción.

La importancia de las directivas en NetWorker

Hoy vamos a recordar algo que no suele suceder muy a menudo, el fallo de un backup causado por determinados ficheros. Vamos a revisar como podemos analizarlo y solucionarlo de manera muy sencilla.

En ocasiones se produce un fallo realizando un backup en algún save set que antes no fallaba. De repente las notificaciones de un cliente que lleva mucho tiempo configurado comienzan a informar de fallos en el proceso de backup, pero solamente en algunos de los directorios o save sets de los configurados para ese cliente. Cuando esto sucede suele producirse en servidores de ficheros a los que acceden usuarios mediante el protocolo CIFS, por ejemplo servidores Unix o Linux compartiendo su almacenamiento interno mediante samba con equipos Windows.

Llegados este punto, la forma más correcta de analizar el fallo es lanzar el comando save directamente desde el cliente sobre esa ruta y analizar la salida del mismo. Lanzariamos el comando save del siguiente modo:

Comando save con mucho log para analizar el fallo.

Podríamos añadir la opción -D9 para que se lance en modo debug, lo cual genera mucha más salida, pero en general suele bastar con la sintaxis anterior, que ya genera bastante información.

Quitando toda la información intermedia de salida del comando, la parte importante es justo el final del mismo que tendrá una pinta como la siguiente:

Salida del comando save.

La salida nos muestra que, cuando el comando save lanza el módulo uasm para hacer el backup del fichero /Ruta/Thumbs.db, se produce un core y el comando save sale de forma un poco fea.

Recordemos que NetWorker tiene diferentes módulos para realizar las operaciones de backup y recuperación de diferentes tipos de sistemas de archivos, siendo el módulo uasm el empleado para los sistemas de ficheros Unix y Linux y que en nuestro caso al intentar hacer backup del fichero Thumbs.db, falla generando la salida anterior.

Como uasm es un módulo que puede llamarse por separado, es decir podemos ejecutarlo directamente desde línea de comandos, vamos a obtener una traza del mismo para intentar determinar más en profundidad cual es el fallo que se está produciendo.

En este punto, es muy importante que conozcamos que herramientas proporcionan los diferentes sistema operativos de forma nativa para poder obtener la traza de un comando y analizar las llamadas al sistema que realiza. En concreto en sistemas Solaris el comando que usaremos será truss y en sistemas Linux strace. Estos comandos generan muchísima salida, con lo que es recomendable utilizar la opción para volcar la traza del comando a un fichero para analizarla posteriormente.

Para el caso que nos ocupa, lanzamos el siguiente comando truss por tratarse de un sistema Solaris 11.3:

Generamos la traza del comando uasm

Y la salida que tenemos del comando anterior es la siguiente:

Salida del comando truss para analizar el comando de backup.

Esta salida, que en principio parece que no dice nada, realmente nos está indicando que el binario uasm, al procesar ese fichero Thumbs.db, ha intentado acceder a una dirección de memoria no válida, lo que nos hace pensar que puede haber un bug en el comando que provoca que, en determinados casos ciertos ficheros provocan este tipo de fallos.

Como está claro que este fallo implica abrir un caso de soporte pero necesitamos realizar el backup de la ruta afectada, lo mejor es establecer una directiva para ese cliente o todos aquellos clientes que puedan contener ese tipo de ficheros, indicando que deben ser ignorados al hacer backup.

Los ficheros Thumbs.db de Windows son pequeñas cachés utilizadas para hacer la visualización de miniaturas en directorios más rápida con lo que, sin ninguna duda, podemos ignorar estos archivos en nuestros backups sin problemas.

Por tanto para solucionar el problema, la directiva que debemos especificar es tan sencilla como la siguiente:

Directiva básica de exclusión de archivos.

Con esta directiva básica, que deberíamos usar para cualquier cliente de backup que contenga datos generados en sistemas Windows de usuario, nos aseguramos de excluir los ficheros Thumbs.db así como cualquier fichero temporal generado por el paquete Office. La última directiva indica que se comprimirán el resto de ficheros de esa ruta. Al especificar el carácter + delante de cada directiva, le estamos indicado a NetWorker que es necesario aplicar la operación a la ruta y todos sus subdirectorios.

Lo expuesto aquí, por mi experiencia, es algo que no suele producirse muy a menudo, con lo que no estaremos generando trazas de procesos de backup habitualmente. Sin embargo estas herramientas suelen ser muy útiles en general para detectar fallos y problemas de todo tipo de aplicaciones que, quizás de otro modo, nos costaría mucho más analizar y solucionar.

Como nota adicional, cuando se trata de sistemas Linux, el comando strace que suelo utilizar es el siguiente:

Comando strace equivalente en sistemas Linux.

 

Almacenamiento hiperescalable con Ceph

Hola a todos, hoy voy a empezar una nueva sección para el estudio de Ceph y sus características. Recientemente hemos comenzado a trabajar en un proyecto de almacenamiento distribuido e hiperescalable y la primera parada es el estudio de Ceph.

De momento hemos comenzado leyendo la tonelada de documentación existente pero, como puntos importantes a tener en cuenta durante el estudio y posible despliegue del sistema tenemos lo siguiente:

• Como cluster hiperescalable de almacenamiento, el sistema se basa en bloques de construcción formados por nodos que se van añadiendo al cluster con lo que, cuantos más nodos añadamos más almacenamiento y más rendimiento deberíamos obtener, siempre y cuando escalemos la red adecuadamente.
• Es muy importante que estos bloques de construcción de los que hablamos sean idénticos para asegurar el mismo rendimiento en todos los casos y un adecuado balanceo de la carga entre todos.
• De forma muy simple un cluster Ceph tiene dos tipos de demonios, los OSDs que permiten a los clientes leer o escribir los datos y los monitor, encargados de mantener la información actualizada del estado del cluster y el mapa de distribución de los datos.
• Los hosts se comunicarán con los monitor y los OSDs directamente usando un cliente específico que, usando el algoritmo CRUSH, permitirá determinar donde se encuentran los datos. Esto implica que los hosts que accedan al cluster Ceph deben tener instalado un cliente específico.
• El cliente Ceph no está disponible para sistemas Windows, con lo que será necesario usar gateways para dichos casos.

Estos son algunos de los puntos que, con lo poco que hemos leido, hemos encontrado importantes y que debemos tener muy en cuenta.

Según avancemos iré añadiendo entradas con más información sobre este sistema de almacenamiento y sus características.

Conceptos avanzados de imágenes Docker - Parte II

Hola, en la entrada anterior vimos como complicarnos un poco a la hora de construir imágenes. Hoy toca complicarnos un poco más y estudiar algunas de las opciones disponibles para la construcción de imágenes.

Hasta ahora hemos construido imágenes que nos permiten crear contenedores que ejecutarán una aplicación dererminada. La pregunta es ¿como le hemos indicado a docker qué debe ejecutar?¿cómo se ejecuta? y más importante todavía ¿que opciones tenemos?

Evidentemente la primera pregunta es la más sencilla. Si recordamos el dockerfile para nuestra imagen de un servidor ldap, teníamos lo siguiente:

Dockerfile de imagen ldap.

Como ya sabemos, mediante la instrucción ENTRYPOINT le estamos indicando a docker que programa o comando de nuestra imagen ejecutar al crear un contenedor basado en ella.

Ahora nos queda responder a las otras dos preguntas, las cuales están muy relacionadas entre si así que, como diría Groucho, respondamos primero a la segunda pregunta.

Ya sabemos que al crear una imagen es necesario que indiquemos en el dockerfile que la describe que se ejecutará dentro del contenedor. Para esto hay disponibles dos instrucciones que podemos usar en nuestros dockerfiles, estas instrucciones son CMD y ENTRYPOINT y en ambos casos el resultado al usar una u otra es muy similar, salvo por los siguientes puntos que debemos tener en cuenta:

• El objetivo al usar CMD es el de especificar parámetros por defecto para nuestros contenedores. En este caso, siempre es necesario especificar un ENTRYPOINT junto con la instrucción CMD, la cual no contendrá ningún ejecutable.
• Al usar ENTRYPOINT definiremos siempre un ejecutable que se lanzará al arrancar un contenedor. Esta definición siempre debe contener la ruta al ejecutable que queremos lanzar al crear nuestros contenedores. 

Es decir, aunque con ambas instrucciones podemos especificar el programa a ejecutar, lo ideal es siempre usar ENTRYPOINT para especificar el ejecutable y CMD para establecer los parámetros por defecto del mismo. Al especificarlo de esta manera, permitimos que cualquier parámetro que pasemos al comando docker run sustituya a los definidos en la instrucción CMD. Teniendo todo esto en cuenta, nuestro dockerfile para la imagen ldap quedaría del siguiente modo:

Nuevo dockerfile con parámetros por defecto.

Con esta nueva definición contruimos de nuevo nuestra imagen y ahora, al crear un contenedor, se ejecutará el servidor ldap indicado en ENTRYPOINT con los parámetros por defecto especificados en CMD. Si al crearlo pasamos otros parámetros al comando docker run, estos nuevos parámetros sustituirán a los que hemos especificado en el dockerfile. Veamoslo con un pequeño ejemplo:

Contenedor creado a partir de la imagen ldap.

Como podemos ver. nuestro conetendor está ejecutando el servidor ldap con los parámetros por defecto indicados en la instrucción CMD de nuestro nuevo dockerfile.

Si ahora creo otro contenedor y especifico otros parámetros el resultado será el siguiente:

Cambiando los parámetros en tiempo de creación del contenedor.

Es importante tener en cuenta que también podemos usar CMD para especificar el ejecutable, es decir, podemos usar ENTRYPOINT o CMD para especificar que ejecutar al crear un contenedor, incluso los dos a la vez si queremos y, como siempre, todo dependerá de nuestras necesidades y entorno.

Desde mi punto de vista, creo que lo mejor es usar la combinación de ENTRYPOINT, para el ejecutable y CMD, para los parámetros por defecto, cuando pueda ser necesario cambiar estos últimos al crear un contenedor. Cuando lo que buscamos es asegurarnos de que no se pueden alterar los parámetros por defecto, lo mejor será que nuestro dockerfile solo contenga una entrada ENTRYPOINT que especifique tanto el ejecutable como los parámetros necesarios. En este último caso cualquier parámetro que se añada en el momento de crear el contenedor se añadirá a los parámetros por defecto sin sustituirlos, con lo que nos aseguramos que el servicio arrancará con los parámetros deseados.

Otro punto importante que debemos tener en cuenta al utilizar ENTRYPOINT es el formato que utilizamos. Según la documentación, tenemos dos opciones al especificar la instrucción ENTRYPOINT:

• Formato shell, que es más o menos: ENTRYPOINT comando param1 param2 ...
• Formato exec, que es más o menos: ENTRYPOINY ["ejecutable", "param1", "param2", ... ]

Bueno y ¿cual es la diferencia y por qué es importante? La diferencia y por tanto su importancia, viene derivada de como se ejecuta el servicio en un caso y en el otro.

Hasta ahora siempre hemos usado el segundo formato en nuestros dockerfile, el denominado formato exec, en el cual especificamos el ejecutable y sus parámetros como un array JSON. Cuando hemos creado contenedores e inspeccionado los procesos corriendo en los mismos, hemos visto que nuestro ejecutable era siempre el PID número 1. Si usamos el formato shell, ¿que es lo que sucede? Como siempre veamoslo con un ejemplo muy sencillo:

Contenedor creado usando el formato shell de ENTRYPOINT.

Como podemos ver en la salida anterior, nuestro comando no es el PID 1 dentro del contenedor y esto es importante si queremos que nuestros servicios se paren ordenadamente. Cuando paramos un contenedor con el comando docker stop, en estos caso, el contenedor no parará de forma limpia ya que solo la shell usada para arrancar nuestro comando recibirá la señal, pero nuestro servicio no con lo que, en algunos casos, puede que tras un timeout docker deba enviar una señal SIGKILL al proceso, lo que puede provocar que el servicio no se pare adecuadamente. Teniendo esto en cuenta lo mejor será siempre usar la forma exec de ENTRYPOINT, como recomienda la documentación de Docker.

Hasta aquí un poco más de información sobre Docker y como trabajar con imágenes. En la siguiente entrada veremos como personalizar en el momento de crear un contenedor la configuración de nuestro servicio ldap.

Integración de NetWorker y Data Domain VE

Hola de nuevo, vamos con otra entrada sobre backup, en concreto como integrar un appliance virtual Data Domain con NetWorker 9.x.

Un sistema Data Domain nos permite realizar backups a disco con características muy superiores a las de un dispositivo AFTD de NetWorker, con el que se integra desde su versión 7.6, siendo sus principales características:

• Deduplicación de los datos. Los sistemas Data Domain deduplican los datos almacenados, lo que nos permitirá mantener más backups.
• Replicación entre los sistemas Data Domain desplegados.
• Protocolo DD Boost. El uso de este protocolo con NetWorker, acelera enormemente los backups y las recuperaciones.

Desde hace un tiempo está disponible una versión virtual de Data Domain, la cual se licencia por capacidad a partir de 500 GB. Esta appliance virtual que puede desplegarse en VMware e Hyper-V, incluye todas las licencias que nos interesan para nuestro servicio de backup, la licencia del protocolo DD Boost, la licencia de deduplicación y la de replicación. Por tanto, si queremos integrar sistemas Data Domain virtuales en nuestra infraestructura de backup, solo necesitaremos adquirir una licencia DiskBackup de NetWorker.

Tras la aburrida teoría, vamos a lo práctico. Primero desplegamos el appliance, para lo cual tenemos que seguir el asistente que se lanza al desplegar el fichero OVA del appliance virtual. Las opciones que debemos configurar en el despliegue son las tarjetas de red virtuales y el tipo de sistema DD que vamos a desplegar, siendo el mínimo el correspondiente a un sistema que soporta hasta 4 TB. Una vez desplegada nuestra appliance, en el primer arranque realizaremos la configuración inicial del sistema DD cuando iniciemos sesión en la consola por primera vez.

Lo primero es cambiar la contraseña del usuario sysadmin que nos permite administrar el sistema:

Primero cambiamos la password de sysadmin.

En los pasos siguientes configuramos la red del sistema donde, al menos uno de los interfaces, debe estar configurado por DHCP:

Especificamos la configuración de red.

En el siguiente paso el asistente de configuración nos preguntará si queremos introducir ya el código de licencia, así como la configuración del sistema la cual será más sencilla de realizar desde el interfaz gráfico de administración.

Al acceder a cualquier de las dos direcciones IP anteriores accederemos a la consola de administración Data Domain System Manager (DDSM) desde la cual podremos terminar de configurar el sistema y administrarlo:

Pantalla de validación para DDSM.

Al entrar por primera vez en DDSM y no haber introducido un código de licencia en la configuración inicial, lo primero que nos pedirá el sistema es introducir el fichero de licencia. La descarga del appliance incluye un fichero de licencia de evaluación, para que podamos hacer todas las pruebas que queramos durante 30 días. Basta con indicar donde esá el fichero de licencia para activar el DD virtual:

Introduciendo licencia de evaluación.

Tras este paso llegamos a la consola principal de adminsitración de DDSM que tiene la siguiente pinta:

Pantalla principal de DDSM.

El siguiente paso es añadir un disco al DD para que pueda usarlo como almacenamiento para nuestros backups. Como podemos añadir los discos en caliente, solo tenemos que añadir un nuevo disco virtual a la VM y configurarlo para su uso. Al añadir el nuevo disco veremos que este aparece en el apartado Devices dentro de la sección Hardware y también como almacenamiento utilizable, dentro del apartado Overview:

El disco disponible para ser añadido al sistema.

Para añadir el disco solo tenemos que pinchar sobre Configure y añadir el disco disponible al tier  activo como se puede ver en la siguiente imagen:

Añadimos el disco al tier activo para su uso.

El disco añadido y el uso de licencia asociado.

Al añadir el disco el sistema nos indicará que es necesario crear un sistema de archivos en el nuevo dispostivo para poder usarlo y el disco aparecerá en la consola como dispositivo que no está en uso. Para poder usar este nuevo disco necesitamos crear un sistema de archivos sobre él, para esto solo tendremos que seguir el asistente de creación de nuevo file system desde el apartado correspondiente dentro de la sección Data Management. Este asistente nos preguntará para que queremos utilizar el sistema, realizando unos tests de rendimiento específicos en cada caso. Como queremos integrarlo con NetWorker, seleccionamos la primera opción cuando llegamos al siguiente paso del asistente:

Seleccionamos la primera opción para usarlo como dispositivo de backup.

Una vez terminado el asistente de creación del file system este ya estará disponible para su uso con lo que ahora, para poder usarlo en nuestra infraestructura de backup, solo necesitamos conectarnos a la consola de nuestro servidor NetWorker y desde la sección devices, lanzar el asistente de creación de nuevo dispositivo. Al tratarse de un dispositivo DD el tipo de dispositivo que crearemos será un dispositivo Data Domain.

Lanzamos el asistente de creación de nuevo dispositivo.

Selecciona Data Domain como nuevo dispositivo.

Las opciones que debemos configurar para nuestro nuevo dispositivo son básicamente, la dirección IP del sistema y las credenciales del usuario con acceso para usar el protocolo DDboost:

Configuración de la IP y credenciales del dispositivo DD.

En el siguiente paso NetWorker se conectará con el Data Domain y podremos crear una carpeta específica en el file system y dar nombre a nuestro nuevo dispositivo. Esto nos permitirá tener cierta organización y crear diferentes dispositivos apuntando al mismo sistema DD.

Creación de carpeta y nombre de dispositivo.

Ya los siguientes pasos nos permiten crear un pool específico y asignarlo a este dispositivo, el nodo de almacenamiento que usará el dispositivo DD y la configuración de SNMP para que NetWorker pueda monitorizar los eventos SNMP que genere el sistema Data Domain. Con toda esta configuración realizada, nuestro nuevo dispositivo DD aparecerá en la lista de dispositivos del servidor NetWorker listo para ser usado para realizar backups.

El dispositivo DD ya está disponible para su uso.

Adicionalmente desde la DDSM, podemos ver la conexión activa desde el servidor NetWoker con el DD usando el protocolo DD Boost:

Conexión activa con el DD desde el servidor NetWorker.

Ya solo tendremos que cambiar nuestros workflows, o crear otros nuevos, para utilizar el nuevo pool que utiliza el dispositivo que acabamos de crear y empezar así, a hacer backups a disco.

Hasta aquí la configuración básica de un sistema Data Domain y como integrarlo con nuestro servidor NetWorker para poder hacer backusp a disco. En una próxima entrada veremos como configurar el DD para hacer backups directos de los clientes usando protocolos como NFS o CIFS.