Actualización del Firmware de una Shelf IOM en Data ONTAP 7-Mode

Para actualizar una bandeja de discos con módulos IOM3 o IOM6, de forma no disruptiva, deberemos descargar el firmware en la página de soporte de NetApp http://support.netapp.com (necesitamos una cuenta de acceso). En general descargaremos el firmware para el módulo IOM y para el ACP.

Una vez descargados los binarios deberemos copiar los archivos .SFW y .FVF en el directorio /volumen_root/etc/shelf_fw y los archivos .AFW y .FVF en /volumen_root/etc/acpp_fw.

 

Actualización del Firmware de una Shelf IOM en Data ONTAP 7-Mode

Ejecutada la secuencia de comandos anterior la controladora gestiona el acceso a los discos para actualizar los módulos de entrada/salida de forma no disruptiva.

En cabinas con doble controladora HA observaremos los mensajes siguientes:

Controladora donde ejecutamos la actualización:

fas2040b-up*> Wed Sep 18 11:32:41 CEST [fas2040b-up: sfu.ctrllerElmntsPerShelf:info]: [storage download shelf]: 2 ES controller elements can be updated on 0d.shelf1.

Wed Sep 18 11:32:41 CEST [fas2040b-up: sfu.downloadStarted:info]: Update of disk shelf firmware started on 1 shelf.

Wed Sep 18 11:32:41 CEST [fas2040b-up: sfu.downloadingController:info]: [storage download shelf]: Downloading IOM3.0160.SFW on disk shelf controller module A on 0d.shelf1.

Wed Sep 18 11:33:07 CEST [fas2040b-up: sfu.rebootRequest:info]: Issuing a request to reboot disk shelf 0d.shelf1 module A.

Wed Sep 18 11:33:07 CEST [fas2040b-up: sfu.adapterSuspendIO.ndu:info]: Suspending SMP to SAS adapter 0d for 30 seconds while shelf firmware is updated.

Wed Sep 18 11:33:36 CEST [fas2040b-up: sfu.downloadingController:info]: [storage download shelf]: Downloading IOM3.0160.SFW on disk shelf controller module B on 0d.shelf1.

Wed Sep 18 11:36:05 CEST [fas2040b-up: sfu.rebootRequest:info]: Issuing a request to reboot disk shelf 0d.shelf1 module B.

Wed Sep 18 11:36:05 CEST [fas2040b-up: sfu.adapterSuspendIO.ndu:info]: Suspending SMP to SAS adapter 0d for 30 seconds while shelf firmware is updated.

Wed Sep 18 11:36:35 CEST [fas2040b-up: sfu.downloadSuccess:info]: [storage download shelf]: Firmware file IOM3.0160.SFW downloaded on 0d.shelf1.

Wed Sep 18 11:36:35 CEST [fas2040b-up: sfu.downloadSummary:info]: Shelf firmware updated on 1 shelf.

En la controladora partner:

fas2040b-dw> Wed Sep 18 11:32:41 CEST [fas2040b-dw: sfu.suspendSES:info]: Suspending enclosure services — partner is updating disk shelf firmware.

Wed Sep 18 11:33:07 CEST [fas2040b-dw: sfu.adapterSuspendIO.ndu:info]: Suspending SMP to SAS adapter 0c for 30 seconds while shelf firmware is updated.

Wed Sep 18 11:33:07 CEST [fas2040b-dw: sfu.adapterSuspendIO.ndu:info]: Suspending SMP to SAS adapter 0d for 30 seconds while shelf firmware is updated.

Wed Sep 18 11:36:05 CEST [fas2040b-dw: sfu.adapterSuspendIO.ndu:info]: Suspending SMP to SAS adapter 0c for 30 seconds while shelf firmware is updated.

Wed Sep 18 11:36:05 CEST [fas2040b-dw: sfu.adapterSuspendIO.ndu:info]: Suspending SMP to SAS adapter 0d for 30 seconds while shelf firmware is updated.

Wed Sep 18 11:36:35 CEST [fas2040b-dw: sfu.partnerUpdateComplete:info]: Partner is no longer updating disk shelf firmware. Resuming enclosure services.

Ahora lanzamos el comando storage download acp para actualizar el firmware de ACP:

Actualización del Firmware de una Shelf IOM en Data ONTAP 7-Mode

Finalizado el proceso podemos verificar las actualizaciones de firmware mediante el comando sysconfig –a.


Licencia de Creative Commons

This Post by David Solé Pérez is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

Pagina Principal

Mover el vol0 o volumen root de NetApp

Puede que en determinados escenarios necesitemos mover el vol0 o volumen root de NetApp de un agregado a otro. Uno de los casos en los que me he encontrado ha sido una NetApp donde, en un primer diseño, habían discos SAS y SATA mezclados repartidos de forma homogénea en las dos controladoras del chasis y tras la compra de más discos se decidió mover los rápidos a una controladora y los lentos a la otra.

De forma esquemática el caso del ejemplo tenía la siguiente distribución de discos:

 

NetApp1: 6+1 SPARE discos SAS formando el aggr0 (root) y 6+1 SPARE discos SATA formando el aggr1

NetApp2: la misma disposición de discos siendo también root el agregado SAS

Ampliación: 6 discos SAS y 6 discos SATA

Para optimizar el rendimiento en este escenario se tuvo en cuenta:

a) Si se reparten los discos de forma homogénea 3+3 quedan los agregados con 9 discos SAS y 9 discos SATA (por controladora). Si se hace el movimiento y se reagrupan todos los discos se obtienen agregados de 18 discos (a mayor número de discos más rendimiento). En este caso además los RGs son inicialmente de 6 discos por lo que tras el movimiento se pueden configurar 2 RGs de 9 discos para un rendimiento más óptimo.

b) El rendimiento general de una controladora no es óptimo si ésta tiene que cambiar su velocidad de acceso cuando lee/escribe SAS o SATA.

Por tanto la posibilidad de mover el volumen de root es determinante para la optimización del sistema de almacenamiento en este escenario. La forma de proceder es la siguiente:

1) Asignación de los nuevos discos SAS a NetApp1: esto se haría de forma habitual con los comandos disk assign.

2) Cambiar el tamaño máximo de los RGs a 9: con esto conseguimos formar RG0 y RG1 de 9 discos cada uno.

3) Ampliación del agregado aggr0 de la NetApp1 con los 6 discos: en este punto la controladora dispondrá de un RG0 de 9 discos y un RG1 de 3.

4) Movimiento de los datos del aggr0 SAS de NetApp2 a aggr0 SAS de NetApp1: esto normalmente implica una parada técnica de servicio que puede ser planificada para minimizar el impacto en el negocio.

5) El mismo procedimiento se sigue para el caso de SATA en NetApp2: se asignan los discos nuevos, se ajusta el tamaño de RG a 9 y se mueven los datos de aggr1 en NetApp1 a aggr1 de NetApp2.

6) Una vez se han movido todos los datos SATA de NetApp1 entonces el aggr1 se puede destruir mediante aggr destroy. Los discos SATA se reasignan a la controladora NetApp2 mediante los comandos disk.

7) Ampliación de aggr1 de NetApp2 con los 6 discos asignados provenientes de NetApp1. Esta controladora queda con el aggr1 formado por RG0 de 9 discos y el RG1 de otros 9. Ahora solo falta que aggr1 sea root para poder liberar los 6 discos SAS y asignarlos a NetApp1.

8) En NetApp2 creación de nuevo volumen en aggr1 con el mismo tamaño que el volumen de root (puede ser mayor pero no menor):

vol create “nuevo_root” aggr1 40g

9) Copiar el contenido del volumen de root al nuevo volumen:

vol restrict “nuevo_root”

vol copy start vol0 “nuevo_root”

NOTA: normalmente NetApp nombra el volumen de root como vol0.

10) Una vez finalizada la copia lanzar el comando vol online “nuevo_root” y posteriormente lanzar el comando:

vol options “nuevo_root”root

Con este comando traspasamos la propiedad root al nuevo volumen (el antiguo root deja de serlo de forma automática)

11) Reiniciar la controladora NetApp2 y verificar que el “nuevo_root” es root mediante el comando vol options “nuevo_root” (en la salida del comando veremos si lo es). El reinicio de la controladora se puede hacer mediante una combinación takeover/giveback para minimizar el impacto.

12) Si todo ha ido bien se puede destruir el volumen root antiguo así como el agregado aggr0 SAS de NetApp2.

13) Asignación de los 6 discos SAS a NetApp1  y ampliación del agregado aggr0 quedando los 2 RGs 9+9.

Con este procedimiento la cabina queda configurada para un rendimiento óptimo aunque se ha sacrificado espacio neto para datos. Este punto es muy importante tenerlo en cuenta y saberlo transmitir correctamente para no encontrarnos con sorpresas. Repasemos:

a) Partíamos de agregados de 6 discos con RGs en RAID-DP por lo que 2 de los 6 discos eran de paridad. En este diseño quedan 4 discos para datos (hay que descontar formateos, metas, WAFL, …).

b) Si añadíamos los discos de forma homogénea, como hemos visto no óptimo, quedaban los agregados con 9 discos (sin cambiar el tamaño de los RGs, que por defecto es de 16 discos, 7 de ellos quedan para datos). De esta forma todo el espacio nuevo es “neto”.

c) Si hacemos el movimiento siguiendo el procedimiento anterior pero en el punto de ajustar el tamaño de los RGs en vez de configurarlo a 9 lo hacemos a su máximo (en general 28 discos en SAS  y 20 discos en SATA) no formamos el nuevo RG1 en cada controladora por lo que no se “pierden” discos de datos.

d) Con el cambio de configuración del tamaño de los RGs hemos forzado la creación de 2 nuevos para SAS y 2 para SATA (uno para cada controladora) por lo que hemos perdido la friolera de 4 discos SAS y 4 discos SATA. Si se necesita más espacio o hay una previsión a corto/medio plazo de más capacidad quizás sería conveniente adquirir un número mayor de discos para poder hacer los RGs más grandes. Ahora bien no es recomendable tener RGs demasiado grandes aunque esté soportado ya que el tiempo de reconstrucción en caso de fallo de discos es mucho mayor y por tanto el impacto al sistema también lo es.

Resumiendo es importante tener especial cuidado con las decisiones de diseño en cada caso y defenderlas en función de los criterios y especificaciones. Habrá entornos en los que la inversión de 6 discos será  muy importante para mejora de rendimiento y sobretodo mayor espacio para datos y otros donde se priorizará el acceso a disco lo más rápido posible por las exigencias de las aplicaciones o del negocio.


Licencia de Creative Commons

This Post by David Solé Pérez is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

Pagina Principal

La importancia de los Raid Groups

En esta nueva entrada destacaremos la importancia de los Raid Groups de las cabinas NetApp. Los que estéis acostumbrados a trabajar con estas cabinas ya sea en vuestras instalaciones o en clientes externos estaréis conmigo que el tema del espacio es siempre un gran debate: yo he comprado 3 Teras y solo me quedan 1.5, había comprado 8 discos y solo me quedan 6 para datos, … Seguramente os suene mucho y tengáis un amplio repertorio de quejas varias.

Veamos, NetApp recomienda que los Raid Groups estén configurados en RAID-DP por su seguridad y buen rendimiento. Normalmente esto está bien aceptado aunque “duela” al principio en instalaciones con pocos discos: si instalamos una FAS2040 con el chasis lleno de discos y sin bandejas adicionales normalmente daremos 6 a cada controladora de los cuales 2 serán paridad y 1 de spare por lo que de 12 se quedan 6 para datos. Esto es el 50% del espacio “perdido”.

Cuando vamos necesitando espacio adicional en nuestro sistema de almacenamiento debemos tener en cuenta algunos factores:

1) Si se requiere el máximo del espacio disponible, de momento descartando configuraciones como RAID 4 o NO SPARE, en el caso de discos SAS deberíamos configurar el Raid Size a 28. Para discos SATA normalmente es 20. De esta forma se “pierden” solo 2 discos de paridad más el disco de spare que, como sabemos, es global para todos los RGs del agregado.

2) Si el rendimiento es prioritario entonces deberemos configurar los RGs con prudencia: sabemos que la distribución de los datos entre RGs  se hace a través de un RAID-0 global entre todos ellos. Por tanto es sumamente importante que el tamaño de todos los RGs sea idéntico puesto que en el caso de tener diferencias la velocidad de acceso quedará limitada al RG más pequeño:

RG0: 10 discos SAS RAID-DP

RG1: 10 discos SAS RAID-DP

RG2: 7 discos SAS RAID-DP

Si lo comparamos con vehículos, por ejemplo, podríamos decir que RG0 y RG1 tienen una velocidad punta de 150 kms/h mientras que RG2 va a 120 kms/h. La pregunta es, ¿a qué velocidad se accederá a los datos? A 120 kms/h.

3) Si se desconoce la prioridad de rendimiento o espacio igualmente deberemos tener en cuenta el tamaño de los RGs: si añadimos discos a un agregado sin consultar la configuración del Raid Size nos podemos encontrar con un pequeño desastre. Imaginemos que nuestra controladora tiene 12 discos con RG0 de 11 en RAID-DP más 1 de SPARE y la configuración del Raid Size está por defecto, generalmente 16 discos. Si hemos adquirido 8 discos y no tenemos en cuenta este punto podemos encontrarnos con un agregado formado por RG0 de 16 y RG1 de 3 discos. Sin darnos cuenta hemos sacrificado 2 discos (los 2 de paridad del nuevo RG1) y tenemos un problema de rendimiento.

Por norma general en cualquier decisión de diseño para la escalabilidad de nuestro sistema de almacenamiento NetApp el concepto Raid Size debería ser tomando como un punto clave. Un error de cálculo nos puede producir un impacto muy negativo tanto en términos de espacio necesario como en rendimiento.

Como resumen podríamos definir los siguientes puntos:

1) No es recomendable tener RGs muy grandes por su impacto en la reconstrucción

2) Los RGs que forman parte de un mismo agregado deberían tener el mismo número de discos para que el acceso a los datos sea eficiente

3) El tamaño de los RGs se puede modificar al alza pero no a la baja

4) Cuando se asigna un nuevo disco se puede indicar a qué RG queremos que pertenezca con el comando aggr add “aggr0” –g “RG1” –d #disco. De esta forma controlamos exactamente la ubicación del disco dentro de nuestro agregado.


Licencia de Creative Commons

This Post by David Solé Pérez is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

Pagina Principal

Disk Bad Label Version

Este error, en general poco frecuente, se puede dar cuando añadimos discos de reemplazo en nuestras controladoras NetApp. Con el paso del tiempo los discos se degradan y se tienen que reemplazar por otros nuevos mediante el procedimiento habitual: el disco fallido se remueve de la cabina, se sustituye por el nuevo, se asigna a la controladora donde estaba el otro quedando éste como SPARE y se añade al agregado si es necesario (si sólo es un disco normalmente se quedará como SPARE).

Durante el proceso de cambio en el momento de lanzar el comando de asignación disk assign #nombre_disco puede que la controladora indique el error siguiente:

… [raid.assim.disk.badlabelversion:error]: Disk 3a.03.0 Shelf 3 Bay 0 X has raid label with version (11), which is not within the currently supported range (5 – 10). Please contact NetApp Global Services.
… [raid.config.disk.bad.label.version:error]: Disk 3a.03.0 Shelf 3 Bay 0 X has an unsupported label version.
… [callhome.dsk.label.v:CRITICAL]: Call home for DISK BAD LABEL VERSION

Para corregir el problema podemos seguir este procedimiento:

1) Entrar en modo avanzado mediante el comando priv set diag o con priv set advanced

2) Lanzar el comando disk unfail -s 3a.03.0 (este es el nombre del disco del ejemplo)

3) Asignar nuevamente el disco con disk assign 3a.03.0

El disco estará disponible como SPARE. Si es un caso de sustitución de más de 1 disco y es necesario añadirlo al agregado, al venir de unfail, la controladora hará un cero de éste antes de introducirlo en el agregado.


Licencia de Creative Commons

This Post by David Solé Pérez is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

Pagina Principal

Mover volumes con NetApp vol move

En esta nueva entrada vamos a ver cómo mover volumes con NetApp vol move. Una forma sencilla de mover volúmenes en caliente entre agregados de una misma controladora es mediante el uso del comando vol move. Esto es muy útil cuando nos encontramos controladoras donde creamos agregados nuevos (por ejemplo con discos más rápidos o más grandes) y necesitamos mover los volúmenes de forma no disruptiva .

Para hacer esto posible necesitamos seguir estos pasos:

1) Instalar una licencia de SnapMirror: si no la tenemos podemos solicitar una de evaluación en el portal de NetApp.

2) Lanzar el comando con el parámetro -d para un análisis previo: el modificador -d nos ayudará a saber si el movimiento es factible o tiene errores.

vol move start nombre_volumen aggr_new -d

3) Lanzar el movimiento tras analizar la salida (si no hay errores)

vol move start nombre_volumen aggr_new

4) Monitorizar el proceso: para ello se pueden usar los siguientes comandos:

a) vol move status -v
b) snapmirror status

5) IMPORTANTE: una vez finalizado el proceso el volumen de destino tiene el snapshot usado durante la transferencia. Es conveniente borrarlo para que no ocupe espacio innecesario.


Licencia de Creative Commons

This Post by David Solé Pérez is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

Pagina Principal

NetApp Data Compression and Deduplication

Muy buenas lectores,

He estado resolviendo algunas dudas sobre deduplicación en cabinas NetApp con Data Ontap 7-Mode y me he encontrado en el camino este excelente documento sobre NetApp Data Compression and Deduplication. En él encontraréis algunos tips y mejores prácticas para poder ahorrar espacio de forma eficiente optimizando los recursos de las controladoras.


Licencia de Creative Commons

This Post by David Solé Pérez is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

Pagina Principal

Fundamentos de WAFL

El sistema de archivos que usan las controladoras Netapp, Write Anywhere File Layout, está basado en Inodes de la misma forma que los sistemas UNIX/Linux. De hecho la Shell de Ontap se asemeja bastante a UNIX por la naturaleza de sus comandos.

La descripción que NetApp hace de un Inode la podemos consultar aquí (requiere una cuenta de registro).

El tamaño de bloque de WAFL es de 4KB y cada Inode está formado por 16 punteros así que para ficheros de menos de 64KB, cada puntero apunta a un bloque de datos. En el caso de ficheros muy pequeños (menos de 64KB) los datos se mantienen en el propio Inode. Para el caso de ficheros grandes o muy grandes se usan punteros a bloques indirectos o dobles punteros.

Los meta-datos de WAFL se almacenan en archivos siendo éstos los siguientes:

1)      Inode File: almacena los Inodes del sistema de archivos.

2)      Block Map File: almacena los bloques libres.

3)      Inode Map File: identifica los Inodes libres.

Fundamentos de WAFL

El Inode raíz debe permanecer en una ubicación fija. Los demás bloques se pueden escribir en cualquier ubicación (de ahí el nombre Write Anywhere).

Fundamentos de WAFL

De entre muchas funcionalidades presentes en un sistema WAFL sin lugar a dudas la más famosa son los Snapshots. La secuencia siguiente muestra un ejemplo de su funcionamiento:

Fundamentos de WAFL

En realidad cuando se crea un Snapshot se copia el Inode raíz manteniendo los punteros a los bloques originales. Cuando un bloque se modifica el Inode raíz apunta a un nuevo bloque indirecto:

Fundamentos de WAFL

Analizando este comportamiento se concluye lo siguiente: cuando se genera un nuevo Snapshot el espacio que éste ocupa es prácticamente de unos pocos KBs correspondientes al clonado del Root Inode. Como lo inmediatamente posterior a un primer Snapshot es el Active Filesystem, la información “viva”, los bloques se van modificando produciendo un aumento proporcional del espacio consumido por el Snapshot (a mayor número de cambios más espacio consume el Snapshot). Por este motivo los Snapshots de volúmenes con pocos cambios, como por ejemplo un repositorio de backups, consumen mucho menos espacio que aquellos que sí los tienen, una base de datos Oracle por ejemplo. Además de esto último un factor a tener en cuenta es el número de inodes/bloques implicados ya que, lógicamente, no es lo mismo hacer un cambio en un VMDK de 300GBs que un fichero de Excel de 3MBs.

Para finalizar esta pequeña introducción a WAFL comentar que este filesystem tiene unos Snapshots especiales denominados consistency point que se generan cada pocos segundos para evitar realizar test de integridad en el caso de desconexión del sistema de almacenamiento (fallo eléctrico por ejemplo). En cada CP se escriben los datos a disco y, entre la creación de uno y otro, la información solamente se escribe en RAM la cual está protegida por la NVRAM (los bloques de RAM pasan a la NVRAM a modo de Backup). De forma esquemática se podría definir este funcionamiento como sigue:

1) Partimos de cero escribiendo datos en el sistema de almacenamiento que se ubican en la RAM principal.

2) Los datos escritos en RAM se ubican en la NVRAM a modo de Backup para casos de fallo.

3) El filesystem crea un CP por lo que los datos se consolidan a disco.

4) Seguimos escribiendo datos en RAM y éstos pasan a la NVRAM.

5) Nuevamente se genera un CP para consolidar los datos.

La secuencia anterior es “infinitamente recursiva” mientras no se produzca un paro controlado o bien se de un caso de fallo. Si el sistema sufre un paro inesperado entonces la NVRAM se mantiene alimentada por la NVRAM Battery durante un máximo de 72 horas, tiempo más que suficiente para arrancar nuevamente los discos y poder así consolidar los cambios.


Licencia de Creative Commons

This Post by David Solé Pérez is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

Pagina Principal

System Manager la herramienta de administración de NetApp

System Manager la herramienta de administración de NetApp o mejor dicho, OnCommand System Manager, se puede descargar de la página Web de soporte en el enlace http://support.netapp.com/NOW/cgi-bin/software/ (requiere login con una cuenta de NetApp) y está disponible para plataformas Linux y Windows. Continuar leyendo “System Manager la herramienta de administración de NetApp”