Disposition des fichiers Write Anywhere

Le système WAFL ( Write Anywhere File Layout ) est un système de fichiers propriétaire qui prend en charge les baies RAID hautes performances de grande taille , les redémarrages rapides sans vérifications de cohérence fastidieuses en cas de panne ou de panne de courant, et l'augmentation rapide de la taille des systèmes de fichiers. Il a été conçu par NetApp pour être utilisé dans ses appareils de stockage tels que NetApp FAS, AFF , Cloud Volumes ONTAP et ONTAP Select .

Son auteur affirme que WAFL n'est pas un système de fichiers, bien qu'il en inclue un. Il suit les changements de la même manière que les systèmes de fichiers journalisés sous forme de journaux (connus sous le nom de NVLOG) dans un périphérique de stockage dédié à la mémoire vive non volatile , appelé NVRAM ou NVMEM. WAFL fournit des mécanismes qui permettent à une variété de systèmes de fichiers et de technologies d'accéder aux blocs de disque .

WAFL stocke les métadonnées, ainsi que les données, dans des fichiers ; les métadonnées, telles que les inodes et les cartes de blocs indiquant quels blocs du volume sont alloués, ne sont pas stockées dans des emplacements fixes dans le système de fichiers. Le fichier de niveau supérieur d'un volume est le fichier inode, qui contient les inodes de tous les autres fichiers ; l'inode du fichier inode lui-même, appelé inode racine, est stocké dans un bloc avec un emplacement fixe. Un inode pour un fichier suffisamment petit contient le contenu du fichier ; sinon, il contient une liste de pointeurs vers des blocs de données de fichier ou une liste de pointeurs vers des blocs indirects contenant des listes de pointeurs vers des blocs de données de fichier, et ainsi de suite, avec autant de couches de blocs indirects que nécessaire, formant un arbre de blocs. Tous les blocs de données et de métadonnées du système de fichiers, autres que le bloc contenant l'inode racine, sont stockés dans des fichiers du système de fichiers. L'inode racine peut ainsi être utilisé pour localiser tous les blocs de tous les fichiers autres que le fichier inode.

La mémoire principale est utilisée comme cache de pages pour les blocs provenant de fichiers. Lorsqu'une modification est apportée à un bloc d'un fichier, la copie dans le cache de pages est mise à jour et marquée comme sale, et la différence est enregistrée dans la mémoire non volatile dans un journal appelé NVLOG . Si le bloc sale dans le cache de pages doit être écrit sur la mémoire permanente, il n'est pas réécrit dans le bloc à partir duquel il a été lu ; à la place, un nouveau bloc est alloué sur la mémoire permanente, le contenu du bloc est écrit au nouvel emplacement et l'inode ou le bloc indirect qui pointait vers le bloc en question est mis à jour dans la mémoire principale. Si le bloc contenant l'inode, ou le bloc indirect, doit être écrit sur la mémoire permanente, il est également écrit dans un nouvel emplacement, plutôt que d'être écrasé à sa position précédente. C'est à cela que fait référence l'expression « Write Anywhere » dans « Write Anywhere File Layout ».

Comme tous les blocs, autres que le bloc contenant l'inode racine, sont trouvés via l'inode racine, aucune des modifications écrites sur le stockage permanent n'est visible sur le stockage permanent jusqu'à ce que l'inode racine soit mis à jour. L'inode racine est mis à jour par un processus appelé point de cohérence , dans lequel tous les blocs sales non encore écrits sur le stockage permanent sont écrits sur le stockage permanent, et un nouvel inode racine est écrit, pointant vers les blocs de la nouvelle version du fichier inode. À ce stade, toutes les modifications apportées au système de fichiers sont visibles sur le stockage permanent, à l'aide du nouvel inode racine. Les entrées NVLOG pour les modifications qui sont maintenant visibles sont supprimées pour faire de la place aux entrées de journal pour les modifications ultérieures. Les points de cohérence sont effectués périodiquement ou si la mémoire non volatile est sur le point d'être pleine d'entrées de journal.

Si le serveur tombe en panne avant que toutes les modifications apportées à un système de fichiers n'aient été rendues visibles dans un point de cohérence, les modifications qui n'ont pas été rendues visibles sont toujours dans le NVLOG ; lorsque le serveur redémarre, il relit toutes les entrées dans le NVLOG, en effectuant à nouveau les modifications enregistrées dans le NVLOG, afin qu'elles ne soient pas perdues.

Comme indiqué ci-dessus, WAFL ne stocke pas les données ou les métadonnées dans des emplacements prédéterminés sur le disque. Au lieu de cela, il place automatiquement les données en utilisant la localité temporelle pour écrire les métadonnées aux côtés des données utilisateur d'une manière conçue pour minimiser le nombre d'opérations de disque requises pour valider les données sur un stockage sur disque stable à l'aide d'un RAID à parité simple et double.

L'utilisation d'un placement de données basé sur la localité temporelle de référence peut améliorer les performances de lecture des ensembles de données qui sont lus de manière similaire à la manière dont ils ont été écrits (par exemple, un enregistrement de base de données et son entrée d'index associée), mais elle peut également provoquer une fragmentation du point de vue de la localité spatiale de référence. Sur les disques durs rotatifs, cela n'affecte pas les fichiers qui sont écrits séquentiellement, lus de manière aléatoire ou lus ultérieurement en utilisant le même modèle temporel, mais affecte les modèles d'accès aux données spatiales de lecture séquentielle après écriture aléatoire, car la tête magnétique ne peut être que dans une seule position à la fois pour lire les données du plateau alors que la fragmentation n'a aucun effet sur les disques SSD .

Les versions d' ONTAP depuis la version 7.3.1 ont inclus un certain nombre de techniques pour optimiser la disposition des données spatiales, telles que la commande reallocate pour effectuer une défragmentation planifiée et manuelle , et l' option de volume Write after Reading qui détecte et corrige automatiquement les modèles d'accès aux données sous-optimaux causés par la fragmentation spatiale. Les versions d' ONTAP 8.1.1 incluent d'autres techniques pour optimiser automatiquement l'espace libre contigu au sein du système de fichiers, ce qui permet également de maintenir des dispositions de données optimales pour la plupart des modèles d'accès aux données. Avant la version 7G, la commande wafl scan reallocate devait être invoquée à partir d'un niveau de privilège avancé et ne pouvait pas être planifiée. Les versions d' ONTAP depuis la version 9.1 ont inclus un certain nombre de techniques pour optimiser l'utilisation des disques SSD, telles que la compression des données en ligne (dans la version 9.1), en commençant par la fonctionnalité FabricPool d'ONTAP 9.2 pour la hiérarchisation automatique des données froides afin de ralentir le stockage S3 et inversement si nécessaire pour les agrégats SSD , et la déduplication entre volumes au sein d'un agrégat avec un maximum de 800 Tio pour chaque agrégat.

WAFL prend en charge les instantanés , qui sont des copies en lecture seule d'un système de fichiers. Les instantanés sont créés en effectuant les mêmes opérations que celles effectuées dans un point de cohérence, mais, au lieu de mettre à jour l'inode racine correspondant à l'état actuel du système de fichiers, en enregistrant une copie de l'inode racine. Comme toutes les données et métadonnées d'un système de fichiers peuvent être trouvées à partir de l'inode racine, toutes les données et métadonnées d'un système de fichiers, au moment de la création de l'instantané, peuvent être trouvées à partir de la copie de l'inode racine de l'instantané. Aucune autre donnée ne doit être copiée pour créer un instantané.

Les blocs sont alloués lors de l'écriture à l'aide d'une table de blocs, qui conserve la trace des blocs utilisés et des blocs libres. Une entrée dans la table de blocs contient un bit indiquant si le bloc est utilisé dans la version actuelle du système de fichiers et plusieurs bits, un par instantané, indiquant si le bloc est utilisé dans l'instantané. Cela garantit que les données d'un instantané ne sont pas écrasées tant que l'instantané n'est pas supprimé. En utilisant la table de blocs, toutes les nouvelles écritures et réécritures sont écrites dans de nouveaux blocs vides, WAFL signale uniquement que la réécriture de bloc a réussi, mais aucune réécriture ne se produit réellement, cette approche est appelée technique de redirection sur écriture (ROW). ROW est beaucoup plus rapide sur les opérations de réécriture par rapport à la copie sur écriture où l'ancien bloc de données qui va être réécrit sur place et capturé dans un instantané doit d'abord être copié dans l'espace alloué à la réserve d'instantanés afin de préserver les données d'origine, cela génère des opérations de copie de données supplémentaires une fois que le système réécrit ce bloc.

Les instantanés fournissent des sauvegardes en ligne auxquelles on peut accéder rapidement, via des répertoires cachés spéciaux dans le système de fichiers, permettant aux utilisateurs de récupérer des fichiers qui ont été accidentellement supprimés ou modifiés.

Le système d'exploitation Data ONTAP Release 7G de NetApp prend en charge un snapshot en lecture/écriture appelé FlexClone . Les snapshots sont la base de technologies telles que SnapMirror , SnapVault et Online Volume Move , tandis que des fonctionnalités telles que FlexClone , SnapLock et SnapRestore sont des technologies de type snapshot qui exploitent les capacités et propriétés WAFL telles que les manipulations avec les inodes. À partir d'ONTAP 9.4, le nombre maximal de snapshots pris en charge pour chaque FlexVol est de 1 024, tandis que pour les versions précédentes, la limite maximale était de 255.

À partir d'ONTAP 9.5, des fonctionnalités de partage de snapshots ont été ajoutées pour exécuter une analyse de déduplication sur le système de fichiers actif et les snapshots. Les économies de déduplication sont d'une ampleur considérable en termes de nombre de snapshots. Avant 9.5, les données non dédupliquées verrouillées dans un snapshot ne pouvaient pas être utilisées par le processus de déduplication et s'exécutaient uniquement sur le système de fichiers actif.

Une caractéristique importante de WAFL est sa prise en charge d'un modèle de fichiers et de répertoires de style Unix pour les clients NFS et d'un modèle de fichiers et de répertoires de style Microsoft Windows pour les clients SMB . WAFL prend également en charge les deux modèles de sécurité, y compris un mode dans lequel différents fichiers sur le même volume peuvent avoir différents attributs de sécurité qui leur sont associés. Unix peut utiliser soit des listes de contrôle d'accès (ACL) soit un simple masque de bits, tandis que le modèle Windows plus récent est basé sur des listes de contrôle d'accès. Ces deux fonctionnalités permettent d'écrire un fichier sur un système de fichiers en réseau de type SMB et d'y accéder ultérieurement via NFS à partir d'un poste de travail Unix. Outre les fichiers ordinaires, WAFL peut contenir des conteneurs de fichiers appelés LUN avec des attributs spéciaux requis comme le numéro de série LUN pour les périphériques de bloc, auxquels on peut accéder à l'aide de protocoles SAN exécutés sur le logiciel ONTAP OS.

Chaque volume flexible (FlexVol) est un système de fichiers WAFL distinct, situé sur un agrégat et distribué sur tous les disques de l'agrégat. Chaque agrégat peut contenir et possède généralement plusieurs volumes FlexVol. ONTAP pendant le processus d'optimisation des données, y compris le « Tetris » qui se termine par des points de cohérence (voir NVRAM), est programmé pour répartir uniformément les blocs de données autant que possible dans chaque volume FlexVol sur tous les disques de l'agrégat afin que chaque FlexVol puisse potentiellement utiliser toutes les performances disponibles de tous les disques de données de l'agrégat. Avec l'approche de la distribution uniforme des blocs de données sur tous les disques de données d'un agrégat, la limitation des performances d'un FlexVol peut être effectuée de manière dynamique avec la qualité de service du stockage et ne nécessite pas d'agrégats dédiés ou de groupes RAID pour chaque FlexVol afin de garantir les performances et de fournir les performances inutilisées à un volume FlexVol qui en a besoin. Chaque FlexVol peut être configuré comme un espace provisionné épais ou mince et peut ensuite être modifié à la volée à tout moment. L'accès aux périphériques de bloc avec les protocoles SAN ( Storage Area Network ) tels que iSCSI , Fibre Channel (FC) et Fibre Channel over Ethernet (FCoE) s'effectue avec une émulation LUN similaire à la technique de périphérique en boucle sur un volume FlexVol. Ainsi, chaque LUN sur le système de fichiers WAFL apparaît comme un fichier, mais possède des propriétés supplémentaires requises pour les périphériques de bloc. Les LUN peuvent également être configurés comme provisionnés de manière épaisse ou fine et peuvent être modifiés ultérieurement à la volée. En raison de l'architecture WAFL, les FlexVol et les LUN peuvent augmenter ou diminuer l'utilisation de l'espace configuré à la volée. Si un FlexVol contient des données, l'espace interne peut être réduit au même titre que l'espace utilisé. Même si la taille du LUN contenant des données peut être réduite sur le système de fichiers WAFL, ONTAP n'a aucune connaissance de la structure de bloc de niveau supérieur en raison de l'architecture SAN, il peut donc tronquer les données et endommager le système de fichiers sur ce LUN. L'hôte doit donc migrer les blocs contenant les données vers une nouvelle limite de LUN pour éviter toute perte de données. Chaque FlexVol peut avoir ses propres politiques QoS , FlashPool , FlasCache ou FabricPool .

Si deux volumes FlexVol sont créés, chacun sur deux agrégats et ces agrégats appartenant à deux contrôleurs différents, et que l'administrateur système doit utiliser l'espace de ces volumes via un protocole NAS. Ensuite, il créera deux partages de fichiers, un sur chaque volume. Dans ce cas, l'administrateur créera très probablement même des adresses IP différentes ; chacune sera utilisée pour accéder à un partage de fichiers dédié. Chaque volume aura une seule affinité d'écriture et il y aura deux compartiments d'espace. Cependant, même si deux volumes résident sur un seul contrôleur, et par exemple sur un seul agrégat (donc si le deuxième agrégat existe, il ne sera pas utilisé dans ce cas) et que les deux volumes seront accessibles via une seule adresse IP, il y aura toujours deux affinités d'écriture, une sur chaque volume et il y aura toujours deux compartiments d'espace distincts. Par conséquent, plus vous avez de volumes, plus vous aurez d'affinités d'écriture (meilleure parallélisation et donc meilleure utilisation du processeur), mais vous aurez alors plusieurs volumes (et plusieurs compartiments pour l'espace, donc plusieurs partages de fichiers).

Similaires à RAID 1 , les plex des systèmes ONTAP peuvent conserver des données en miroir à deux endroits, mais alors que RAID-1 conventionnel doit exister dans les limites d'un système de stockage, deux plex peuvent être répartis entre deux systèmes de stockage. Chaque agrégat se compose d'un ou deux plex. Les systèmes de stockage HA conventionnels n'ont qu'un seul plex pour chaque agrégat, tandis que les configurations locales SyncMirror ou MetroCluster peuvent avoir deux plex pour chaque agrégat. D'autre part, chaque plex inclut l'espace de stockage sous-jacent d'un ou plusieurs groupes RAID NetApp ou LUN de systèmes de stockage tiers (voir FlexArray ) dans un seul plex de manière similaire à RAID 0. Si un agrégat se compose de deux plex, un plex est considéré comme maître et le second comme esclave ; les esclaves doivent être constitués exactement de la même configuration RAID et des mêmes lecteurs. Par exemple, si nous avons un agrégat composé de deux plex où le plex maître est composé de 21 données et de 3 disques de parité SAS de 1,8 To en RAID-TEC, alors le plex esclave doit être composé de 21 données et de 3 disques de parité SAS de 1,8 To en RAID-TEC. Le deuxième exemple, si nous avons un agrégat composé de deux plex où le plex maître est composé d'un RAID 17 de données et de 3 disques de parité SAS de 1,8 To configurés en RAID-TEC et le deuxième RAID dans le plex maître est RAID-DP avec 2 données et 2 disques de parité SSD de 960 Go. Le deuxième plex doit avoir la même configuration : un RAID 17 de données et 3 disques de parité SAS de 1,8 To configurés en RAID-TEC, et le deuxième RAID dans le plex esclave est RAID-DP avec 2 données et 2 disques de parité SSD de 960 Go. Les configurations MetroCluster utilisent la technologie SyncMirror pour la réplication synchrone des données. Il existe deux options SyncMirror : MetroCluster et Local SyncMirror, qui utilisent toutes deux la même technique plex pour la réplication synchrone des données entre deux plex. Local SyncMirror crée les deux plex dans un seul contrôleur et est souvent utilisé pour une sécurité supplémentaire afin d'éviter une panne d'une étagère de disques entière dans un système de stockage. MetroCluster permet de répliquer les données entre deux systèmes de stockage. Chaque système de stockage peut être constitué d'un contrôleur ou être configuré comme une paire HA avec deux contrôleurs. Dans une seule paire HA, il est possible d'avoir deux contrôleurs dans des châssis séparés et la distance entre eux peut être de plusieurs dizaines de mètres, tandis que dans la configuration MetroCluster, la distance peut atteindre 300 km.

Comme de nombreux concurrents, les systèmes NetApp ONTAP utilisent la mémoire comme support de stockage beaucoup plus rapide pour accepter et mettre en cache les données des hôtes et, plus important encore, pour l'optimisation des données avant les écritures, ce qui améliore considérablement les performances de ces systèmes de stockage. Alors que les concurrents utilisent largement la mémoire vive non volatile (NVRAM) pour conserver les données en cas d'événements inattendus comme un redémarrage à la fois pour la mise en cache des écritures et l'optimisation des données, les systèmes NetApp ONTAP utilisent la mémoire vive ordinaire (RAM) pour l'optimisation des données et la NVRAM ou NVDIMM dédiée pour la journalisation des données initiales dans un état inchangé tel qu'elles proviennent des hôtes de la même manière que la journalisation des transactions effectuée dans les bases de données relationnelles . Ainsi, en cas de catastrophe, naturellement, la RAM sera automatiquement effacée après le redémarrage, et les données stockées dans la mémoire non volatile sous la forme de journaux appelés NVLOG survivront après le redémarrage et seront utilisées pour restaurer la cohérence. Toutes les modifications et optimisations dans les systèmes ONTAP sont effectuées uniquement dans la RAM, ce qui permet de réduire la taille de la mémoire non volatile pour les systèmes ONTAP. Après les optimisations, les données des hôtes sont structurées de manière similaire à Tetris, optimisées et préparées en passant par quelques étapes (c'est-à-dire WAFL et RAID) pour être écrites sur les disques sous-jacents dans les groupes RAID sur l' agrégat où les données vont être stockées. Après les optimisations, les données vont être écrites séquentiellement sur les disques dans le cadre de la transaction de point de cohérence (CP). Les données écrites sur les agrégats contiendront les métadonnées WAFL et la parité RAID nécessaires , de sorte qu'aucune lecture supplémentaire à partir des disques de données, ni aucun calcul et aucune écriture sur les disques de parité ne se produiront comme avec les groupes RAID-6 et RAID-4 traditionnels. CP crée d'abord un instantané du système sur un agrégat où les données vont être écrites, puis optimise et prépare les données de la RAM écrites séquentiellement en tant que transaction unique sur l'agrégat. En cas d'échec, toute la transaction échoue en cas de redémarrage soudain, ce qui permet au système de fichiers WAFL d'être toujours cohérent. En cas de transaction CP réussie, un nouveau point de système de fichiers actif est propagé et les NVLOG correspondants sont effacés. Toutes les données vont toujours être écrites à un nouvel emplacement et aucune réécriture ne peut se produire. Les blocs de données supprimés par les hôtes marqués comme libres afin qu'ils puissent être utilisés ultérieurement lors des prochains cycles CP et que le système ne manque pas d'espace avec la politique d'écriture permanente des nouvelles données dans un nouvel emplacement de WAFL. Seuls les NVLOG dans les systèmes de stockage HA sont répliqués de manière synchrone entre deux contrôleurs pour la capacité de basculement du système de stockage HA, ce qui permet de réduire les frais généraux de protection de la mémoire système globale. Dans un système de stockage avec deux contrôleurs en configuration HA ou MetroClusteravec un contrôleur sur chaque site, chacun des deux contrôleurs divise sa propre mémoire non volatile en deux parties : locale et son partenaire. Dans une configuration MetroCluster avec quatre nœuds, chaque mémoire non volatile est divisée en deux parties : locale, partenaire local et partenaire distant.

À partir du système All-Flash FAS A800, NetApp a remplacé le module NVRAM PCI par des NVDIMM connectés au bus mémoire, augmentant ainsi les performances.