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

4.7/5 - (3 votos)
2.945 Visitas del Post

¿Te ha gustado este artículo? ¡Suscríbete!

Artículos Relacionados

  • Configurar BGInfo en servidores de Active Directory Estimados lectores, tras unas vacaciones aquí estoy de nuevo esta vez con un clásico y es que vamos a ver cómo configurar BGInfo en servidores de Active Directory. La verdad es que hace […]
  • CommVault Simpana 10, Conceptos Básicos Hola a todos: Después de mucho buscar por Internet, he visto que documentación de este producto en Castellano, no es que haiga mucha. Por lo que a partir de hoy, intentare explicar […]
  • Determinar la version de VMware ESXi Estimados lectores, en este artículo veremos cómo determinar la versión de VMware ESXi o VMware ESX para saber exactamente de qué Update estamos hablando. Generalmente acostumbramos a ver […]
  • Comandos para crear un volumen de NetApp 7-Mode Estimados lectores, ya sé que desde hace bien poquito estamos trabajando con la versión cDOT de NetApp pero todavía tenemos mucho recorrido con 7-Mode así que vamos a ver los comandos para […]
  • Instalación de NetApp Data ONTAP 7-Mode En este post veremos cómo realizar la instalación de NetApp Data ONTAP 7-Mode en una nueva controladora FAS2240-2 que ha sido previamente inicializada mediante la opción 4 del boot […]
  • Ampliar una NetApp FAS3140 Hace unos días he tenido que ampliar una NetApp FAS3140 de chasis simple con doble controladora que tenía un stack FC y otro SATA con las míticas DS14mk4 y DS14mk2, respectivamente, […]

Autor: David Solé Pérez

Padre de Paula e Ivet, entusiasta de las Tecnologías de la Información y de la Comunicación.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *