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.

Backups NDMP.

Bueno, pues voy con otra entrada relacionada con el backup y el almacenamiento.

Si como en mi caso, administras filers de NetApp lo mejor para realizar un backup muy rápidamente es utilizar el protocolo NDMP.

De forma resumida, cada vez que se lanza el backup de un volumen o qtree, aunque lo recomendado es hacer backups NDMP solo de volúmenes, ONTAP hace un snapshot de dicho volumen, lo convierte en un stream de datos y lo envía por red al servidor de backup el cual lo escribirá en disco o cinta.

Hasta aquí todo muy bien, el backup no tarda mucho pero ¿y cuando queremos recuperar algo de esos backups NDMP? Entonces amigos es cuando llega la lentitud, pero lentitud muy lenta. Por como funciona el protocolo NDMP y como debe recuperarse la información del sistema de archivos WAFL, nos encontramos que incluso para recuperar un mísero archivo de 1 KB es necesario que nuestro querido Legato lea tooooodo el backup correspondiente para poder hacer la recuperación. Como referencia, aquí os pego lo que dice la guía de administración de Legato NetWoker 8.1 SP1 en su página 683:

By default, the NDMP recover process reads an entire tape from start to finish. The recover
process extracts the data as it encounters the data on the tape. For large backup images,
recovery is slow.

Lo de recovery is slow se queda corto la verdad. Así que, para mejorar bastante el tiempo de las recuepraciones, hay un par de variables de entorno a utilizar siempre que queramos hacer una recuperación NDMP. Estas variables las exportaremos con nuestro querido comando export cuando estemos usando el comando recover en Unix/Linux, o tendremos que fijarlas como variables del sistema en nuestro Windows.

Las variables son:

NSR_NDMP_DAR=y

NSR_NDMP_DDAR=y

y al usarlas Legato irá al punto de la cinta exacto donde está la información que queremos recuperar, lo cual nos ahorra el leer todo el backup para poder recuperar un simple fichero y ahorra bastante tiempo.

Saludos.

Snapshots en plataformas VNX

Hace unos meses recibimos un VNX5200 con el que llevo pegándome desde entonces. Mientras espero a recibir el curso correspondiente, que debería ser en breve, estoy investigando la plataforma y sus características.

Una de las cosas que más me ha llamado la atención, sobre todo viniendo de plataformas NetApp, es que, aunque se pueden hacer snapshots, no hay un scheduler de los mismos como en Data ONTAP y que hay que hacer bricolage para programar tus snapshtos y controlar su expiración.

Afortunadamente EMC proporciona para todos los sistemas operativos una herramienta muy interesante, el comandito naviseccli el cuál, una vez instalado, te deja hacer practicamente de todo.

Así, para listar las LUNs existentes en el sistema, basta con utilizar un comando tan cómodo como el siguiente:

/opt/Navisphere/bin/naviseccli -User USUARIO -Password PASSWORD -Scope 0 -Address DIR_IP lun -list
 

Con lo que, si queremos hacer snapshots es necesario que nos curremos un script que se encargue de hacer el snapshot de todas las LUNs que hayamos creado.

Para los snapshots el subcomando que hay que usar es snap, quien lo hubiera dicho, el cuál tiene bastantes opciones.

Subcomando snap y opciones

Viendo la salida del subcomando snap solo necesitamos crear un script en el que, con la opción -create, podremos hacer los snapshots de nuestras LUNs. Para controlar la expiración y borrado automático de esos snapshots, usaremos la opción -keepFor especificando el tiempo que deseémos mantener el snapshot. Por ejemplo, para crear el snapshot de una LUN y mantener dicho snapshot 15 días el comando será:

/opt/Navisphere/bin/naviseccli -User USUARIO -Password PASSWORD -Scope 0 -Address DIR_IP snap -create -res LUN_ID -name NOMBRE_SNAPSHOT -keepFor 15d

Todo esto en un bonito shell script controlado por nuestro viejo amigo crontab y ya tenemos snapshots de las LUNs de nuestro VNX5200.

Seguiremos investigando.

Backups incrementales de Exchange 2010 promocionados a full

Bueno, pues voy a hacer la primera anotación técnica de un problemilla que acabamos de tener y la primera entrada de la sección de backup.

Soy el responsable de backup y usamos EMC Legato NetWorker, el cual he actualizado hace poco a la versión 8.1.1 SP2 y me he encontrado que todos los backups de Exchange 2010 de un determindao grupo de backup, independientemente del schedule configurado, son promocionados a full. La versión de NMM en los clientes es la 2.4.1.

Curiosamente esto ya nos sucedió hace un tiempo, también con Exchange 2010 pero con un DAG y un grupo de backup diferente, pero no recordaba como lo solucionamos.

Afortunadamente, la magia del buscador de la web de soporte de EMC me ha recordado que el problema, por raro que sea, tiene que ver con la configuración del pool de cintas a utilizar para los backups. De forma resumida este problema se produce si, en la confgiruación de los clientes miembros del grupo de backup configuramos el pool de cintas así como en la definición del grupo. Es decir que para que esto no suceda el campo Pool de la configuración de los clientes debe estar vacío:

Configuración del cliente

Pero en la configuración del grupo de backup si es necesario definir correctamente el pool de cintas, que será además de tipo snapshot por tratarse de un backup de Exchange:

Configuración del grupo de backup

Pues si niños, si defines en dos sitios el pool de cintas a utilizar, para backups de Exchange 2010 con NMM 2.4.1 y Legato NetWorker 8.1.1 SP2 conseguiréis qur los backups incrementales de Exchange 2010 se conviertan en unos bonitos full.

Saludos.