stringtranslate.com

Diseño de archivo para escribir en cualquier lugar

El diseño de archivos Write Anywhere ( WAFL ) es un sistema de archivos propietario que admite matrices RAID de gran tamaño y alto rendimiento , reinicios rápidos sin largas comprobaciones de consistencia en caso de fallo o falla de energía y un rápido aumento del tamaño de los sistemas de archivos. Fue diseñado por NetApp para su uso en sus dispositivos de almacenamiento como NetApp FAS, AFF , Cloud Volumes ONTAP y ONTAP Select .

Su autor afirma que WAFL no es un sistema de archivos, aunque incluye uno. [3] Realiza un seguimiento de los cambios de forma similar a los sistemas de archivos de registro en forma de registros (conocidos como NVLOG) en un dispositivo de almacenamiento de memoria dedicado , la memoria de acceso aleatorio no volátil , denominada NVRAM o NVMEM. WAFL proporciona mecanismos que habilitan una variedad de sistemas de archivos y tecnologías que desean acceder a bloques de disco .

Diseño

Estructura de inodo WAFL, metadatos almacenados junto con los datos

WAFL almacena metadatos, así como datos, en archivos; los metadatos, como los inodos y los mapas de bloques que indican qué bloques del volumen están asignados, no se almacenan en ubicaciones fijas en el sistema de archivos. El archivo de nivel superior en un volumen es el archivo de inodo, que contiene los inodos de todos los demás archivos; el inodo del archivo de inodo en sí, llamado inodo raíz, se almacena en un bloque con una ubicación fija. Un inodo para un archivo suficientemente pequeño contiene el contenido del archivo; de lo contrario, contiene una lista de punteros a bloques de datos de archivo o una lista de punteros a bloques indirectos que contienen listas de punteros a bloques de datos de archivo, y así sucesivamente, con tantas capas de bloques indirectos como sean necesarias, formando un árbol de bloques. Todos los bloques de datos y metadatos en el sistema de archivos, excepto el bloque que contiene el inodo raíz, se almacenan en archivos en el sistema de archivos. El inodo raíz se puede utilizar para localizar todos los bloques de todos los archivos excepto el archivo de inodo. [4]

La memoria principal se utiliza como caché de páginas para bloques de archivos. Cuando se realiza un cambio en un bloque de un archivo, la copia en la caché de páginas se actualiza y se marca como sucia, y la diferencia se registra en la memoria no volátil en un registro llamado NVLOG . Si el bloque sucio en la caché de páginas se va a escribir en el almacenamiento permanente, no se reescribe en el bloque desde el que se leyó; en su lugar, se asigna un nuevo bloque en el almacenamiento permanente, el contenido del bloque se escribe en la nueva ubicación y el inodo o bloque indirecto que apuntaba al bloque en cuestión se actualiza en la memoria principal. Si el bloque que contiene el inodo, o el bloque indirecto, se va a escribir en el almacenamiento permanente, también se escribe en una nueva ubicación, en lugar de sobrescribirse en su posición anterior. Esto es a lo que se refiere "Write Anywhere" en "Write Anywhere File Layout". [4]

Como todos los bloques, excepto el bloque que contiene el inodo raíz, se encuentran a través del inodo raíz, ninguno de los cambios escritos en el almacenamiento permanente son visibles en el almacenamiento permanente hasta que se actualiza el inodo raíz. El inodo raíz se actualiza mediante un proceso llamado punto de consistencia , en el que todos los bloques sucios que aún no se han escrito en el almacenamiento permanente se escriben en el almacenamiento permanente y se escribe un nuevo inodo raíz, que apunta a los bloques en la nueva versión del archivo de inodo. En ese punto, todos los cambios en el sistema de archivos son visibles en el almacenamiento permanente, utilizando el nuevo inodo raíz. Las entradas NVLOG para los cambios que ahora son visibles se descartan para dejar espacio para las entradas de registro para los cambios posteriores. Los puntos de consistencia se realizan periódicamente o si la memoria no volátil está cerca de estar llena de entradas de registro. [4]

Si el servidor falla antes de que todos los cambios en un sistema de archivos se hayan hecho visibles en un punto de consistencia, los cambios que no se han hecho visibles aún están en el NVLOG; cuando el servidor se reinicia, reproduce todas las entradas en el NVLOG, registrando nuevamente los cambios en el NVLOG, de modo que no se pierdan.

Características

Como se mencionó anteriormente, WAFL no almacena datos ni metadatos en ubicaciones predeterminadas en el disco. En cambio, ubica automáticamente los datos utilizando la localidad temporal para escribir metadatos junto con los datos del usuario de una manera diseñada para minimizar la cantidad de operaciones de disco necesarias para guardar los datos en un almacenamiento de disco estable utilizando RAID basado en paridad simple y doble.

El uso de una ubicación de datos basada en la localidad temporal de referencia puede mejorar el rendimiento de la lectura de conjuntos de datos que se leen de una manera similar a la forma en que se escribieron (por ejemplo, un registro de base de datos y su entrada de índice asociada); sin embargo, también puede causar fragmentación desde la perspectiva de la localidad espacial de referencia. En los discos duros giratorios , esto no afecta negativamente a los archivos que se escriben secuencialmente, se leen aleatoriamente o se leen posteriormente utilizando el mismo patrón temporal, pero sí afecta a los patrones de acceso a datos espaciales de lectura secuencial después de la escritura aleatoria debido a que el cabezal magnético solo puede estar en una posición a la vez para leer datos del plato, mientras que la fragmentación no tiene efecto en las unidades SSD .

Las versiones de ONTAP desde la 7.3.1 han incluido una serie de técnicas para optimizar el diseño de datos espaciales, como el comando reallocate para realizar una desfragmentación programada y manual , y la opción de volumen Write after Reading que detecta y corrige automáticamente patrones de acceso a datos subóptimos causados ​​por la fragmentación espacial. Las versiones de ONTAP 8.1.1 incluyen otras técnicas para optimizar automáticamente el espacio libre contiguo dentro del sistema de archivos, lo que también ayuda a mantener diseños de datos óptimos para la mayoría de los patrones de acceso a datos. Antes de 7G, el comando wafl scan reallocate tendría que invocarse desde un nivel de privilegio avanzado y no podía programarse. Las versiones de ONTAP desde la 9.1 han incluido una serie de técnicas para optimizar el uso de SSD, como la compactación de datos en línea (en la 9.1), comenzando con la funcionalidad ONTAP 9.2 FabricPool para la clasificación automática de datos fríos para ralentizar el almacenamiento S3 y viceversa si es necesario para agregados SSD , y la deduplicación de volumen cruzado dentro de un agregado con un máximo de 800 TiB para cada agregado. [5]

Instantáneas

Copia de seguridad de datos en el lugar con la técnica tradicional de Copiar al escribir
Copia de seguridad de datos de instantáneas de NetApp RoW en el lugar

WAFL admite instantáneas , que son copias de solo lectura de un sistema de archivos. Las instantáneas se crean realizando las mismas operaciones que se realizan en un punto de consistencia, pero, en lugar de actualizar el inodo raíz correspondiente al estado actual del sistema de archivos, se guarda una copia del inodo raíz. Como todos los datos y metadatos de un sistema de archivos se pueden encontrar desde el inodo raíz, todos los datos y metadatos de un sistema de archivos, a partir del momento en que se crea la instantánea, se pueden encontrar desde la copia de la instantánea del inodo raíz. No es necesario copiar ningún otro dato para crear una instantánea. [4]

Los bloques se asignan cuando se escriben utilizando un mapa de bloques, que realiza un seguimiento de qué bloques están en uso y qué bloques están libres. Una entrada en el mapa de bloques contiene un bit que indica si el bloque está en uso en la versión actual del sistema de archivos y varios bits, uno por instantánea, que indican si el bloque está en uso en la instantánea. Esto garantiza que los datos de una instantánea no se sobrescriban hasta que se elimine la instantánea. Al utilizar el mapa de bloques, todas las nuevas escrituras y reescrituras se escriben en nuevos bloques vacíos, WAFL solo informa que la reescritura del bloque se realizó correctamente, pero en realidad no se produce ninguna reescritura; este enfoque se denomina técnica de redireccionamiento en escritura (ROW). [4] ROW es mucho más rápido en las operaciones de reescritura en comparación con la copia en escritura, donde el bloque de datos antiguo que se va a reescribir en el lugar y se captura en una instantánea debe copiarse primero en el espacio asignado para la reserva de instantáneas con el fin de preservar los datos originales, esto genera operaciones de copia de datos adicionales una vez que el sistema obtiene reescrituras en ese bloque.

Las instantáneas proporcionan copias de seguridad en línea a las que se puede acceder rápidamente, a través de directorios ocultos especiales en el sistema de archivos, lo que permite a los usuarios recuperar archivos que se han eliminado o modificado accidentalmente. [4]

El sistema operativo Data ONTAP Release 7G de NetApp admite una instantánea de lectura y escritura denominada FlexClone . Las instantáneas son la base de tecnologías como SnapMirror , SnapVault y Online Volume Move , mientras que funciones como FlexClone , SnapLock y SnapRestore son tecnologías similares a las instantáneas que aprovechan las capacidades y propiedades de WAFL, como las manipulaciones con inodos. A partir de ONTAP 9.4, la cantidad máxima de instantáneas admitidas para cada FlexVol es 1024, mientras que para las versiones anteriores el límite máximo era 255.

A partir de ONTAP 9.5, se agregó la función de uso compartido de instantáneas para ejecutar un análisis de deduplicación en el sistema de archivos activo y las instantáneas, y el ahorro en la deduplicación es una magnitud de la cantidad de instantáneas. Antes de la versión 9.5, los datos no deduplicados bloqueados en una instantánea no se podían usar mediante el proceso de deduplicación y solo se ejecutaban en el sistema de archivos activo.

Modelo de archivos y directorios

Una característica importante de WAFL es su compatibilidad con un modelo de archivos y directorios de estilo Unix para clientes NFS y un modelo de archivos y directorios de estilo Microsoft Windows para clientes SMB . WAFL también admite ambos modelos de seguridad, incluido un modo en el que diferentes archivos en el mismo volumen pueden tener diferentes atributos de seguridad adjuntos a ellos. Unix puede usar [6] listas de control de acceso (ACL) o una máscara de bits simple, mientras que el modelo más reciente de Windows se basa en listas de control de acceso. Estas dos características permiten escribir un archivo en un sistema de archivos en red de tipo SMB y acceder a él más tarde a través de NFS desde una estación de trabajo Unix. Junto con los archivos ordinarios, WAFL puede contener contenedores de archivos llamados LUN con los atributos especiales necesarios, como el número de serie de LUN para dispositivos de bloque, a los que se puede acceder utilizando protocolos SAN que se ejecutan en el software ONTAP OS.

Vol flexible

Diseño de WAFL FlexVol: bloques y metadatos de inodo junto con datos de usuario

Cada volumen flexible (FlexVol) es un sistema de archivos WAFL independiente, ubicado en un agregado y distribuido en todos los discos del agregado. Cada agregado puede contener y, por lo general, tiene varios volúmenes FlexVol. ONTAP, durante el proceso de optimización de datos, incluido el "Tetris", que finaliza con puntos de consistencia (consulte NVRAM), está programado para distribuir de manera uniforme los bloques de datos tanto como sea posible en cada volumen FlexVol en todos los discos del agregado, de modo que cada FlexVol pueda potencialmente utilizar todo el rendimiento disponible de todos los discos de datos del agregado. Con el enfoque de distribución uniforme de bloques de datos en todos los discos de datos de un agregado, la limitación del rendimiento de un FlexVol se puede realizar de manera dinámica con QoS de almacenamiento y no requiere agregados dedicados ni grupos RAID para cada FlexVol para garantizar el rendimiento y proporcionar el rendimiento no utilizado a un volumen FlexVol que lo requiera. Cada FlexVol se puede configurar como espacio de aprovisionamiento grueso o fino y, más tarde, se puede cambiar sobre la marcha en cualquier momento. El acceso a dispositivos de bloque con protocolos de red de área de almacenamiento (SAN) como iSCSI , Fibre Channel (FC) y Fibre Channel over Ethernet (FCoE) se realiza con emulación de LUN similar a la técnica de dispositivo Loop sobre un volumen FlexVol; por lo tanto, cada LUN en el sistema de archivos WAFL aparece como un archivo, pero tiene propiedades adicionales requeridas para dispositivos de bloque. Los LUN también se pueden configurar como de aprovisionamiento grueso o fino y se pueden cambiar más tarde sobre la marcha. Debido a la arquitectura WAFL, FlexVols y LUN pueden aumentar o disminuir el uso de espacio configurado sobre la marcha. Si un FlexVol contiene datos, el espacio interno se puede reducir no menos que el espacio utilizado. Aunque el tamaño de LUN con datos en él podría reducirse en el sistema de archivos WAFL, ONTAP no tiene conocimiento sobre la estructura de bloques de nivel superior debido a la arquitectura SAN, por lo que podría truncar los datos y dañar el sistema de archivos en ese LUN, por lo que el host necesita migrar los bloques que contienen los datos a un nuevo límite de LUN para evitar la pérdida de datos. Cada FlexVol puede tener sus propias políticas de QoS , FlashPool , FlasCache o FabricPool .

Si se crean dos volúmenes FlexVol, cada uno en dos agregados y esos agregados pertenecen a dos controladores diferentes, y el administrador del sistema necesita usar el espacio de estos volúmenes a través de un protocolo NAS, entonces crearía dos recursos compartidos de archivos, uno en cada volumen. En este caso, el administrador probablemente incluso creará diferentes direcciones IP; cada una se usará para acceder a un recurso compartido de archivos dedicado. Cada volumen tendrá una única afinidad de escritura y habrá dos contenedores de espacio. Sin embargo, incluso si dos volúmenes residen en un único controlador y, por ejemplo, en un único agregado (por lo tanto, si existe el segundo agregado, no se usará en este caso) y se accederá a ambos volúmenes a través de una única dirección IP, seguirá habiendo dos afinidades de escritura, una en cada volumen y siempre habrá dos contenedores de espacio separados. Por lo tanto, cuantos más volúmenes tenga, más afinidades de escritura tendrá (mejor paralelización y, por lo tanto, mejor utilización de la CPU), pero luego tendrá múltiples volúmenes (y múltiples contenedores para el espacio, por lo tanto, múltiples recursos compartidos de archivos).

Plexus

Replicación de SyncMirror mediante plexes

De manera similar a RAID 1 , los plexes en los sistemas ONTAP pueden mantener datos reflejados en dos lugares, pero mientras que el RAID-1 convencional debe existir dentro de los límites de un sistema de almacenamiento, se pueden distribuir dos plexes entre dos sistemas de almacenamiento. Cada agregado consta de uno o dos plexes. Los sistemas de almacenamiento HA convencionales tienen solo un plex para cada agregado, mientras que las configuraciones locales o MetroCluster de SyncMirror pueden tener dos plexes para cada agregado. Por otro lado, cada plex incluye espacio de almacenamiento subyacente de uno o más grupos RAID de NetApp o LUN de sistemas de almacenamiento de terceros (consulte FlexArray ) en un solo plex de manera similar a RAID 0. Si un agregado consta de dos plexes, un plex se considera maestro y el segundo como esclavo; los esclavos deben constar exactamente de la misma configuración RAID y unidades. Por ejemplo, si tenemos un agregado que consta de dos plexes donde el plex maestro consta de 21 datos y 3 unidades de paridad SAS de 1,8 TB en RAID-TEC, entonces el plex esclavo debe constar de 21 datos y 3 unidades de paridad SAS de 1,8 TB en RAID-TEC. El segundo ejemplo, si tenemos un agregado que consta de dos plexes donde el plex maestro consta de un RAID 17 de datos y 3 unidades de paridad SAS de 1,8 TB configurados como RAID-TEC y el segundo RAID en el plex maestro es RAID-DP con 2 datos y 2 SSD de paridad de 960 GB. El segundo plex debe tener la misma configuración: un RAID 17 de datos y 3 unidades de paridad SAS de 1,8 TB configurados como RAID-TEC, y el segundo RAID en el plex esclavo es RAID-DP con 2 datos y 2 SSD de paridad de 960 GB. Las configuraciones de MetroCluster utilizan la tecnología SyncMirror para la replicación de datos sincrónica. Existen dos opciones de SyncMirror: MetroCluster y Local SyncMirror, ambas utilizan la misma técnica de plex para la replicación sincrónica de datos entre dos plexes. Local SyncMirror crea ambos plexes en un único controlador y se utiliza a menudo para mayor seguridad a fin de evitar fallos en todo un estante de discos de un sistema de almacenamiento. MetroCluster permite replicar datos entre dos sistemas de almacenamiento. Cada sistema de almacenamiento puede constar de un controlador o configurarse como un par de alta disponibilidad con dos controladores. En un único par de alta disponibilidad, es posible tener dos controladores en chasis separados y la distancia entre ellos puede ser de decenas de metros, mientras que en la configuración de MetroCluster la distancia puede ser de hasta 300 km.

Memoria no volátil

Duplicación de caché de memoria no volátil en un MetroCluster y HA

Al igual que muchos competidores, los sistemas NetApp ONTAP utilizan la memoria como un medio de almacenamiento mucho más rápido para aceptar y almacenar en caché los datos de los hosts y, lo que es más importante, para la optimización de los datos antes de las escrituras, lo que mejora enormemente el rendimiento de dichos sistemas de almacenamiento. Mientras que los competidores utilizan ampliamente la memoria de acceso aleatorio no volátil (NVRAM) para preservar los datos en ella durante eventos inesperados como un reinicio tanto para el almacenamiento en caché de escritura como para la optimización de los datos, los sistemas NetApp ONTAP utilizan la memoria de acceso aleatorio (RAM) ordinaria para la optimización de los datos y NVRAM o NVDIMM dedicados para el registro de los datos iniciales en un estado sin cambios tal como vinieron de los hosts de manera similar al registro de transacciones realizado en las bases de datos relacionales . Entonces, en caso de desastre, naturalmente, la RAM se borrará automáticamente después del reinicio, y los datos almacenados en la memoria no volátil en forma de registros llamados NVLOG sobrevivirán después del reinicio y se utilizarán para restaurar la consistencia. Todos los cambios y optimizaciones en los sistemas ONTAP se realizan solo en la RAM, lo que ayuda a reducir el tamaño de la memoria no volátil para los sistemas ONTAP. Después de las optimizaciones, los datos de los hosts se estructuraron de manera similar a Tetris, se optimizaron y prepararon con el paso de algunas etapas (es decir, WAFL y RAID) para escribirse en discos subyacentes en grupos RAID en el agregado donde se almacenarán los datos. Después de las optimizaciones, los datos se escribirán secuencialmente en los discos como parte de la transacción del Punto de consistencia (CP). Los datos escritos en los agregados contendrán los metadatos WAFL necesarios y la paridad RAID, por lo que no se producirán operaciones adicionales de lectura de los discos de datos, cálculo y escritura en discos de paridad como con los grupos RAID-6 y RAID-4 tradicionales. El CP primero crea una instantánea del sistema en un agregado donde se escribirán los datos, luego optimiza y prepara los datos de la RAM escritos secuencialmente como una sola transacción en el agregado, si falla, toda la transacción falla en caso de un reinicio repentino que permite que el sistema de archivos WAFL siempre sea consistente. En caso de una transacción CP exitosa, se propaga el nuevo punto del sistema de archivos activo y se borran los NVLOG correspondientes. Todos los datos siempre se escribirán en un nuevo lugar y no se pueden producir reescrituras. Los bloques de datos eliminados por los hosts marcados como libres se pueden usar más adelante en los próximos ciclos de CP y el sistema no se quedará sin espacio con la política de siempre escribir nuevos datos en un nuevo lugar de WAFL. Solo los NVLOG en los sistemas de almacenamiento de alta disponibilidad se replican de manera sincrónica entre dos controladores para la capacidad de conmutación por error del sistema de almacenamiento de alta disponibilidad, lo que ayuda a reducir los costos generales de protección de la memoria del sistema. En un sistema de almacenamiento con dos controladores en configuración de alta disponibilidad o MetroClusterCon un controlador en cada sitio, cada uno de los dos controladores divide su propia memoria no volátil en dos partes: la local y la de su socio. En la configuración de MetroCluster con cuatro nodos, cada memoria no volátil se divide en las siguientes partes: la local, la del socio local y la del socio remoto. [7]

A partir del sistema All-Flash FAS A800, NetApp reemplazó el módulo NVRAM PCI con NVDIMM conectados al bus de memoria, lo que aumentó el rendimiento.

Véase también

Notas

  1. ^ "Límites de almacenamiento". library.netapp.com .
  2. ^ "Cifrado de volumen de NetApp: los detalles | IOPS.ca". 30 de noviembre de 2016.
  3. ^ "¿WAFL es un sistema de archivos?". Blogs.netapp.com. Archivado desde el original el 15 de julio de 2014.
  4. ^ abcdef Dave Hitz ; James Lau; Michael Malcolm (19 de enero de 1994). Diseño de sistema de archivos para un servidor de archivos NFS (PDF) . USENIX Invierno de 1994.
  5. ^ Parisi, Justin (14 de julio de 2017). "¿Está ejecutando VMware en ONTAP? ¿Por qué debería considerar actualizar a ONTAP 9.2?".
  6. ^ "Listas de control de acceso POSIX en Linux". Suse.de. Archivado desde el original el 24 de enero de 2007.
  7. ^ "Clustered Data ONTAP® 8.3. Guía de gestión y recuperación ante desastres de MetroCluster™: duplicación de caché NVRAM y NVMEM en una configuración de MetroCluster". NetApp. 1 de septiembre de 2015. Archivado desde el original (url) el 24 de enero de 2018. Consultado el 24 de enero de 2018 .

Enlaces externos