Cluster ONTAP - Parte II

Hola de nuevo, revisando las entradas sobre cluster ONTAP me he dado cuenta que hace infinito que no escribo nada y hemos hecho muchos cambios en el último año.

En aquel momento acabábamos de empezar la migración de nuestras controladoras, que por aquel entonces estaban en 7-Mode, a la versión 8.3.2 de cluster ONTAP, migración que realizamos satisfactoriamente usando la herramienta 7-Mode Transition Tool de NetApp.

Recientemente hemos realizado el último paso que nos faltaba, la conversión de un cluster switchless a switched, así que voy a explicar un poco las diferencias entre 7-Mode y cluster ONTAP a nivel hardware.

Para empezar, como siempre digo, recomiendo visitar la página web de NetApp en la cual podréis encontrar información más precisa y explicaciones mucho mejores que las mías.

Antes de cluster ONTAP, las controladoras se instalaban en parejas aisladas cuando queríamos disponer de alta disponibilidad. Con ONTAP 7-Mode, las controladoras se instalaban formando parejas. En una pareja, las dos controladoras se interconectaban entre sí para comunicarse enre ellas. Esta conexión podía realizarse internamente, cuando ambas estaban en un mismo chasis, o externamente cuando estaban separadas. Esta interconexión entre controladoras, llamada HA interconnect, nos permite forrmar lo que se denomina una pareja HA.

Cada controladora podía estar conectada a una o más stacks de bandejas de discos de las que era propietaria, asignándose dicha propiedad por software y para asegurar la máxima disponibilidad, también se conectaban a la controladora partner que formaba la pareja. Esta interconexion podemos verla así:

Conexiones básicas pareja HA.

A nivel software, cada controladora disponía de su servidor NFS y CIFS, además de proporcionar servicios FCP e iSCSI. Por tanto cada controladora de una pareja HA podía servir datos simultaneamente y ya dependía de nuestras necesidades, como repartir la carga y los servicios.

Con la nueva versión cluster de ONTAP todo esto ha cambiado sustancialmente. Ahora a nivel hardware, podemos tener varias parejas interconectadas entre sí formando un cluster. El concepto de parejas de controladoras se mantiene y es el bloque fundamental de construcción de los nuevos clusters, los cuales, en función del número de parejas que los formen pueden ser switchless cluster, en los cuales solo tenemos una pareja de controladoras interconectadas entre sí, además de mediante la conexión HA interconnect mediante una red de cluster, o switched cluster, en la cual dos o más parejas se interconectan entre sí mediante una red de cluster dedicada. Ambos casos podemos verlos más o menos del siguiente modo:

Switchless ONTAP cluster.

Switched ONTAP cluster.

Viendo estas imágenes está claro que la idea fundamental de cluster ONTAP es la escalabilidad del servicio de almacenamiento.

Por tanto, desde el punto de vista hardware, podríamos decir que mediante la red de cluster podemos interconectar parejas HA para conseguir más rendimiento y puertos de acceso, escalando horizontalmente nuestro sistema de almacenamiento. Así mismo, al conectar bandejas adicionales a cada pareja HA, añadiremos almacenamiento al sistema y por tanto escaleremos el cluster verticalmente añadiendo más capacidad.

Hasta aquí el resumen de las diferencias hadware. En los próximos posts intentaré explicar un poco las diferencias software y el modo de operación básico.

Usando Docker de manera práctica - Parte I

Hola de nuevo, en los posts anteriores sobre Docker he repasado un poco la teoría de operación de Docker y, de una manera muy básica, he realizado una introducción a ciertas características. Para poder profundizar un poco más en Docker y su funcionamiento vamos a ver unos cuantos casos prácticos.

Para empezar lo fundamental es instalar Docker. Esto podemos hacerlo de una manera muy sencilla con solo descargar el paquete correspondiente para nuestra distribución Linux. Por ejemplo, en sistemas como CentOS:

Instalación del motor de Docker.

con lo que nuestro motor de Docker ya estaría listo y disponible en nuestro sistema para empezar a usarlo.

Una vez instalado, el comando que vamos a utilizar para todo es docker, el cual interactua con el demonio docker que ahora estará arrancado en nuestro sistema.

El primer comando que vamos a utilizar, para comprobar que la instalación se ha realizado correctamente, nos dará la versión de Docker que estamos usando:

Comprobando la versión de Docker,.

Bien, una vez que tenemos nuestro motor de Docker instalado y funcionando correctamente vamos a realizar un ejemplo básico, pero en este caso no vamos a crear un contenedor que nos diga Hola mundo, sino vamos a hacer algo un poco más interesante, como montar con un solo comando un servidor web Apache.

Como ya expliqué, el motor de Docker permite ejecutar aplicaciones dentro de un entorno aislado a partir de una imagen que contendrá todo el software que dicha aplicación necesita. Ahora bien, ¿de donde salen esas imágenes? Al igual que las diferentes distribuciones de Linux tienen repositorios con paquetes de software, Docker dispone de un repositorio público que contiene miles de imágenes que podemos descargar y utilizar para crear nuestros contenedores. Puedes consultar dicho repositorio en la URL https://hub.docker.com/ previo registro, el cual es absolutamente gratuito. Este registro en Docker Hub nos permitirá, más adelante, subir nuestras imágenes y hacerlas públicas si así lo deseamos.

Al igual que nuestro gestor de paquetes favorito nos permite buscar software por su nombre, el comando docker dispone de un subcomando search el cual, salvo que especifiquemos otro repositorio, buscará siempre en Docker Hub. Como para estas operaciones no es necesario que tengamos un usuario registrado, vamos a buscar una imagen para instalar nuestro servidor Apache:

Busqueda de imágenes de Apache en Docker Hub.

Como véis aparecen muchos resultados ya que, al buscar una cadena con el comando docker search, este realizará la búsuqeda tnato el nombre de la imagen como en la descripción de la misma. Como se vé en la salida, las imágenes tienen valoraciones con estrellas y además, en algunas se indica que son oficiales. Más adelante intentaré profundizar un poco más en toda esta información pero, de momento vamos a quedarnos con la imagen docker.io/httpd y vamos a crear nuestro primer contenedor con ella. Para esto solo es necesario ejecutar el comando; docker run -d --name webserver httpd:latest, como podemos ver a continuación:

Creación de un contenedor con un servidor web Apache.

Tras descargarse las capas de sistemas de ficheros necesarias que forman la imagen, podemos comprobar con el comando docker ps -a si hay algún contenedor corriendo:

Lista de contenedores arrancados y parados en el sistema.

La salida del comando muestra que hemos creado un contenedor con la imagen httpd:latest, que el nombre del contenedor es webserver, el estado del contenedor y que está escuchando en el puerto 80. Por tanto, ¿quiere esto decir que con tan solo ese comando hemos levantado un servidor web Apache y que es accesible por el puerto 80? La respuesta es no. Por defecto, un contenedor tendrá acceso al exterior del host donde se está ejecutando pero no podremos acceder a él desde fuera del host, solo desde el propio host. La manera más sencilla de comprobar esto es arrancar nuestro contenedor webserver con una shell, para ello solo tenemos que hacer lo siguiente:

Usando una shell en un contenedor.

Al arrancar así el contenedor, especificando el comando, no se ejecutará el comando por defecto de la imagen y por tanto, no estará corriendo el servidor apache pero podremos interactuar con el contenedor. Desde esta shell, si comprobamos la dirección IP y lanzamos un ping podremos comprobar que el contenedor puede acceder a la red sin problemas:

Acceso a la red desde un contenedor.

Como lo que queremos es comprobar que nuestro contenedor es un servidor web que está funcionando correctamente, arrancamos nuestro contenedor de nuevo sin pasarle ningún comando y a probamos a acceder desde el propio host. Para esto primero necesitamos saber que dirección IP le ha asignado docker a este contenedor, para esto podemos ejecutar el comando ip addr dentro del contenedor del siguiente modo:

Ejecutando un comando dentro de un contenedor.

Esto nos muestra una funcionalidad muy interesante y es que, siempre que el comando exista dentro del contenedor, podremos ejecutarlo y realizar acciones dentro de un contenedor que está corriendo. Con este sencillo comando hemos obtenido la dirección IP que nuestro contenedor webserver tiene con lo que ahora, con nuestro querido comando lynx podemos comprobar si de verdad está sirviendo una página web:

Accediendo con lynx a nuestro servidor web.

Aunque no es muy gráfico, nos permite comprobar que efectivamente, con un solo comando, hemos levantado un servidor web Apache totalmente operativo.

En el próximo post vamos a darle una pequeña vuelta a esto y explicar un poco más los comandos que hemos utilizado en este post, así como cambiar la forma en que creamos nuestro contenedor para que sea accesible desde el exterior.

Imágenes de software

Hola de nuevo, en el anterior post realicé una pequeña introducción a Docker. Como ya expliqué, con Docker podremos ejecutar software en entornos aislados de ejecución llamados contenedores. La pregunta obvia es ¿que software es el que se ejecuta dentro del contenedor?

Para poder crear un contenedor usaremos imágenes de software, las cuales contendrán las aplicaciones que necesitamos con todas sus dependencias.

Al hablar de imágenes de software podemos pensar que estas son ficheros únicos, como un paquete RPM o DEB, que descargamos y utilizamos para crear contenedores pero, en realidad, las imágenes de Docker son conjuntos de capas de ficheros.

Cada una de las capas de ficheros que forman una imagen contiene un conjunto de ficheros y directorios y todas esas capas juntas, mediante el uso de un union filesystem, formará el sistema de archivos completo que usará el contenedor.

Visualmente creo que se entiende mucho mejor, así que ahí va un esquema aclaratorio:

Sistema de archivos UFS y su relación con capas de ficheros.

Viendo esta imagen podemos entender como, al unir varias capas de sistemas de ficheros, se formará una imagen que contendrá todos los archivos necesarios para poder ejecutar una determinada aplicación.

Las capas de sistemas de ficheros se relacionarán entre ellas de tal manera que, la capa más baja será la capa padre de la siguiente y así sucesivamente, hasta formar una imagen completa que contenga toda la estructura de directorios y los ficheros necesarios para la ejecución de una determinada aplicación.

Por tanto, al crear un contenedor con una imagen, lo que tendremos serán todas esas capas montadas mediante un union filesystem que para el contenedor será un sistemas de ficheros HFS estándar, aunque realmente los archivos y directorios estén distribuidos entre las diferentes capas.

Cuando los procesos que corren en la aplicación deban realizar operaciones de escritura, lo harán sobre una capa superior que se añadira automáticamente a la imagen en el mismo momento de su creación.

Con esta forma de trabajar está claro que se consigue una reutilización de las capas de software para poder construir diferentes imágenes con solo relacionarlas entre ellas. Por ejemplo imaginemos una imagen que contenga el software de un servidor web como Apache o Nginx, aunque es una aproximación muy burda podemos imaginar que podría estar formada por dos capas de sistemas de ficheros:

1. La primera capa contendría las bibliotecas necesarias de sistema operativo, así como aplicaciones básicas como una shell bash.
2. La segunda capa, que sería hija de la anterior, contendría el software del propio servidor web, con sus bibliotecas, binarios y ficheros de configuración.

De este modo, al montar ambas capas juntas, el contenedor tendría acceso a un sistema de archivos donde "vería" ciertas carpetas con bibliotecas y binarios de sistema y, adicionalmente, las carpetas que contendrían el software del servidor web.

Más adelante volveremos sobre las imágenes, ya que lo interesante es ver como usarlas y construirlas, pero creo que para empezar es una buena introducción.

Muy pronto más información.

¿Que es Docker y como funciona?

Hola de nuevo, por fín regreso para comenzar una nueva sección y explorar Docker y sus funcionalidades.

De forma muy simplificada podemos decir que Docker nos permite utilizar ciertas características del kernel de Linux, como los namespaces o los cgroups, para crear entornos de ejecución aislados para aplicaciones.

Con esta definición básica ya tenemos varios puntos importantes sobre Docker:

• Al crear entornos aislados de ejecución usando funcionalidades del kernel, Docker no es un sistema de virtualización hardware y no requiere que el host que utilicemos exponga sus capacidades de virtualización de hardware.
• Los procesos que corren dentro de un entorno aislado serán capaces de realizar llamadas al kernel del host donde estén corriendo.
• Los entornos de aislamiento, que es lo que conocemos como contenedores, tendrán un acceso limitado a los recursos del sistema.

¿Que necesitamos para empezar con Docker? pues solamente un sistema operativo Linux e instalar el paquete correspondiente. Al usar funcionalidades del kernel, podremos usar Docker tanto en sistemas físicos como virtuales.

En la web oficial de Docker hay toneladas de información que explican todo esto mucho mejor que yo, así que es una parada obligatoria para todos los que queráis aprender de verdad sobre Docker.

En la próxima entrada intentaré explicar que es una imagen y como se usan para crear un contenedor.

 

Cluster ONTAP - Parte I

Hola de nuevo, después de muuuuucho tiempo sin postear absolutamente nada, aquí estoy de vuelta para comentar, aunque solo sea por quitarle el polvo al blog, que estoy liado migrando todos nuestros 7 Mode a la flamante ONTAP Cluster Mode, sobre unos FAS2552. Para no liarme mucho, ya que no tengo nada de tiempo libre, aunque mi jefe piense que sí, estamos montando clusters de 4 nodos en dos de nuestras oficinas y un switchless cluster en otra.

Espero volver en breve para actualizar un poco toda esta información, pero el resumen básico es que, para hacer una migración que vaya como la seda la herramienta a utilizar es 7 Mode Transition Tool.

Saludos.

Replicación usando SnapMirror

Hola de nuevo, tras un parón importante, aquí estoy de nuevo para dejar un apunte rápido sobre la replicación entre cabinas NetApp usando snapmirror.

Estamos en medio de un proyecto de DR entre varias de nuestras delegaciones, por fín después de mucho tiempo vamos a ponernos con ello y utilizando snapmirror de NetApp, no podría ser más sencillo. 

De forma rápida y resumida, mediante snapmirror, dos cabinas de NetApp son capaces de replicar el contenido de una de ellas, que llamaremos origen, en otra remota que llamaremos destino. No es necesario que pensemos en ubicaciones separadas geograficamente cientos de kilomentros, podemos usar snapmirror para replicar los datos de una vieja NetApp en una nueva y reluciente.

Todo el procedimiento se basa en los siguientes y simples pasos:

1.- Debemos instalar las licencias necesarias en ambas controladoras. Que haríamos sin nuestras queridas licencias.
2.- Habilitamos snapmirror en ambos sistemas, para esto nos basta con usar el comando snapmirror on.
3.- En el sistema origen debemos especificar que hosts remotos pueden establecer relaciones snapmirror. Para esto solo tenemos que modificar la opción snapmirror.access, especifcando los hosts remotos que podrán conectarse:

Opción snapmirror.access en origen.

4.- En el sistema destino crearemos un volumen, si vamos a replciar un volumen, del mismo tamaño que tenga el volumen en origen y que queramos replicar. Una vez creado lo restringimos con el comando vol.

5.- Una vez llegados a este punto solo falta iniciar la relación snapmirror entre origen y destino. Para esto, desde el sistema destino, usaremos el comando: 

snapmirror initialize -S ORIGEN:VOLUMEN_ORIGEN DESTINO:VOLUMEN_DESTINO

Una vez comenzada la replicación, la cual monitorizaremos con el comando snapmirror status, tendremos que esperar a que esta termine para establecer la programación de replicación entre ambos sistemas.

En breve ampliaré este artículo con más información útli e interesante........

NFS y Kerberos

Llevo un tiempo con un proyecto para cambiar el estilo de seguridad de nuestros exports NFS a kerberos. En Data ONTAP, al crear un nuevo export, el estilo de seguridad por defecto, si no especificamos uno, es SYS que se basa únicamente en el user-id y los groups-id a los que pertenece el usuario.

Como referencia, para usar Kerberos como método de autenticación al montar recursos NFS remotos, podemos usar tres tipos de modos de seguridad diferentes:

• krb5, es el más simple y solo se basa en la autenticación del usuario, que intenta acceder al punto de montaje, mediate el protocolo Kerberos V5.
• krb5i, añade al antetrior comprobaciones de integridad para asegurar que no se han alterado los datos en la red, con algún tipo de ataque MITM.
• krb5p, el más seguro de los tres y que, a los dos modos anteriores, añade la encriptación a todo el tráfico de red entre el cliente y el servidor NFS. Como es lógico este estilo de seguridad puede impactar en el rendimiento de los equipos implicados en la comunicación.

Y todo esto, ¿como lo usamos en Data ONTAP?, pues para no variar de una manera muy simple, siempre y cuando hayamos configurado el servicio nfs para usar un KDC, ya sea un AD o un KDC Unix, al lanzar el comando nfs setup.

Suponiendo que ya lo tengamos correctamente configurado, exportar cualquier qtree usando cualquiera de los tres modos de seguridad kerberos, es tan sencillo como usar un comando como el mostrado en la siguiente imagen.

Exportando un qtree con seguridad kerberos.

De esta manera forzamos a que el cliente solo pueda usar el modo krb5p con lo que, si no lo soporta, no será capaz de montar dicho export. Una forma más correcta y compatible de hacerlo es especificar varios modos al realizar el export, lo cual hacemos separando cada estilo de seguridad disponible del siguiente modo:

Exportando un qtree con varios modos de seguridad kerberos.

De esta manera, cuando un cliente NFS intente montar dicho recurso negociará con el servidor el modo de seguridad a utilizar entre los que tenga disponibles.

Bueno, pues esta es la parte fácil, luego hay que ir a cada cliente y configurarlo adecuadamente. En el caso de Solaris 10, un sistema operativo de verdad, es tan fácil como descomentar las líneas de cada uno de los modos de seguridad que queremos que soporte el cliente NFS del archivo /etc/nfssec.conf y lanzar el comando mount:

Montando un recurso NFS usando seguridad krb5p en Solaris 10.

Pero espera, ¿que root no puede acceder a esa ruta? totalmente lógico, porque dicho usuario no debería tener un ticket de kerberos, fácil de comprobar con el comando klist. Para poder acceder a dicho punto de montaje, necesitaré que root tenga un ticket de kerberos válido y para eso, usando el comando kinit y el nombre de un usuario válido en el reino kerberos conseguiremos el acceso que necesitamos:

Accediendo a un puntode montaje con un ticket kerberos.

Pues otro día continúo un poco más con esto, pero lo cierto es que ya es más configurar los clientes que hacer cambios en el almacenamiento ya que, en ONTAP, el proceso es bastante rápido y simple como hemos visto.