Файловая система WAFL: Архитектура и особенности реализации

Введение

Компьютерная файловая система

Write Anywhere File Layout (WAFL) — это проприетарная файловая система, поддерживающая большие высокопроизводительные массивы RAID, быструю перезагрузку без длительных проверок целостности в случае сбоя или отключения питания, а также быстрое увеличение размера файловой системы. Она была разработана NetApp для использования в своих системах хранения, таких как NetApp FAS, AFF, Cloud Volumes ONTAP и ONTAP Select. Автор WAFL утверждает, что это не файловая система, хотя она и включает в себя одну. WAFL отслеживает изменения аналогично журналируемым файловым системам, используя журналы (известные как NVLOGs) в выделенном устройстве хранения энергонезависимой памяти с произвольным доступом, называемой NVRAM или NVMEM. WAFL предоставляет механизмы, позволяющие различным файловым системам и технологиям получать доступ к дисковым блокам.

Дизайн

WAFL хранит метаданные вместе с данными в файлах; метаданные, такие как иноды и карты блоков, указывающие, какие блоки в томе выделены, не хранятся в фиксированных местах в файловой системе. Файл верхнего уровня в томе – это файл inode, который содержит иноды для всех остальных файлов; инод для самого файла inode, называемый корневым инодом, хранится в блоке с фиксированным местоположением. Инод для достаточно маленького файла содержит содержимое файла; в противном случае он содержит список указателей на блоки данных файла или список указателей на косвенные блоки, содержащие списки указателей на блоки данных файла и так далее, с таким количеством уровней косвенных блоков, сколько необходимо, формируя дерево блоков. Все блоки данных и метаданных в файловой системе, кроме блока, содержащего корневой инод, хранятся в файлах в файловой системе. Таким образом, корневой инод может быть использован для определения местоположения всех блоков всех файлов, кроме файла inode. Оперативная память используется в качестве кэша страниц для блоков из файлов. Когда в блок файла вносятся изменения, копия в кэше страниц обновляется и помечается как "грязный", а разница записывается в энергонезависимую память в журнал, называемый NVLOG. Если "грязный" блок в кэше страниц должен быть записан в постоянное хранилище, он не перезаписывается в блок, из которого он был прочитан; вместо этого новый блок выделяется в постоянном хранилище, содержимое блока записывается в новое местоположение, а инод или косвенный блок, указывавший на этот блок, обновляется в оперативной памяти. Если блок, содержащий инод, или косвенный блок, должен быть записан в постоянное хранилище, он также записывается в новое место, а не перезаписывается в предыдущем месте. Это и есть суть "Write Anywhere" в "Write Anywhere File Layout".

Снимок

WAFL поддерживает снимки, которые являются копиями файловой системы, доступными только для чтения. Снимки создаются путем выполнения тех же операций, что и в точке согласованности, но вместо обновления корневого inode, соответствующего текущему состоянию файловой системы, сохраняется копия корневого inode. Поскольку все данные и метаданные в файловой системе можно получить из корневого inode, все данные и метаданные файловой системы на момент создания снимка можно получить из копии корневого inode снимка. Для создания снимка не требуется копировать какие-либо другие данные. Списки контроля доступа (ACL) или простая битовая маска, в то время как более новая модель Windows основана на списках контроля доступа. Эти две возможности позволяют записать файл в сетевую файловую систему типа SMB и затем получить к нему доступ через NFS с Unix-рабочей станции. Помимо обычных файлов, WAFL может содержать файловые контейнеры, называемые LUN, с необходимыми специальными атрибутами, такими как серийный номер LUN для блочных устройств, к которым можно получить доступ с использованием протоколов SAN, работающих в программном обеспечении ONTAP OS.

FlexVol

Каждый гибкий том (FlexVol) представляет собой отдельную файловую систему WAFL, расположенную на агрегате и распределенную по всем дискам в этом агрегате. Каждый агрегат может содержать и обычно содержит несколько томов FlexVol. ONTAP в процессе оптимизации данных, включая алгоритм "Tetris", завершающийся созданием точек согласованности (см. NVRAM), запрограммирован на максимально равномерное распределение блоков данных в каждом томе FlexVol по всем дискам агрегата, чтобы каждый FlexVol мог потенциально использовать всю доступную производительность всех дисков данных в агрегате. Благодаря такому равномерному распределению блоков данных по дискам агрегата, ограничение производительности для FlexVol может выполняться динамически с помощью Storage QoS и не требует выделенных агрегатов или RAID-групп для каждого FlexVol для гарантии производительности и предоставления неиспользуемой производительности тому FlexVol, которому она необходима. Каждый FlexVol может быть сконфигурирован с толстым или тонким выделением пространства и впоследствии изменен в любое время "на лету". Доступ к блочным устройствам с использованием протоколов SAN (storage area network), таких как iSCSI, Fibre Channel (FC) и Fibre Channel over Ethernet (FCoE), осуществляется посредством эмуляции LUN, аналогичной технике Loopback-устройства, поверх тома FlexVol; таким образом, каждый LUN в файловой системе WAFL представляется как файл, но обладает дополнительными свойствами, необходимыми для блочных устройств. LUN также могут быть настроены с толстым или тонким выделением пространства и изменены впоследствии "на лету". Благодаря архитектуре WAFL, FlexVols и LUN могут динамически увеличивать или уменьшать используемое пространство. Если FlexVol содержит данные, внутреннее пространство может быть уменьшено не ниже используемого. Хотя размер LUN с данными на файловой системе WAFL может быть уменьшен, ONTAP не имеет информации о структуре блоков верхнего уровня из-за архитектуры SAN, поэтому он может усечь данные и повредить файловую систему на этом LUN. Поэтому хост должен мигрировать блоки, содержащие данные, в новую границу LUN, чтобы предотвратить потерю данных. Каждый FlexVol может иметь собственные политики QoS, FlashPool, FlashCache или FabricPool. Если создаются два тома FlexVol, каждый на отдельном агрегате, принадлежащем разным контроллерам, и системному администратору необходимо использовать пространство этих томов через протокол NAS, то будут созданы два сетевых ресурса, по одному на каждый том. В этом случае администратор, скорее всего, даже создаст разные IP-адреса, каждый из которых будет использоваться для доступа к выделенному сетевому ресурсу. Каждый том будет иметь одно сродство записи (write affinity), и будут два пула пространства. Даже если два тома находятся на одном контроллере и, например, на одном агрегате (в этом случае второй агрегат не будет использоваться), и к обоим томам осуществляется доступ через один IP-адрес, все равно будет два сродства записи, по одному на каждый том, и всегда будут два отдельных пула пространства. Следовательно, чем больше томов, тем больше сродств записи (лучшая параллелизация и, следовательно, более эффективное использование ЦП), но тогда будет несколько томов (и несколько пулов пространства, а значит, несколько сетевых ресурсов).

Each Flexible Volume (FlexVol) is a separate WAFL file system, located on an aggregate and distributed across all disks in the aggregate. Each aggregate can contain and usually has multiple FlexVol volumes. ONTAP during data optimization process including the "Tetris" which finishes with Consistency Points (see NVRAM) is programmed to evenly distribute data blocks as much as possible in each FlexVol volume across all disks in aggregate so each FlexVol could potentially use all available performance of all the data disks in the aggregate. With the approach of even data block distribution across all the data disks in an aggregate, performance throttling for a FlexVol could be done dynamically with storage QoS and does not require dedicated aggregates or RAID groups for each FlexVol to guarantee performance and provide the unused performance to a FlexVol volume which requires it. Each FlexVol could be configured as thick or thin provisioned space and later could be changed on the fly any time. Block device access with storage area network (SAN) protocols such as iSCSI, Fibre Channel (FC), and Fibre Channel over Ethernet (FCoE) is done with LUN emulation similar to Loop device technique on top of a FlexVol volume; thus each LUN on WAFL file system appears as a file, yet have additional properties required for block devices. LUNs can also be configured as thick or thin provisioned and can be changed later on the fly. Due to WAFL architecture, FlexVols and LUNs can increase or decrease configured space usage on the fly. If a FlexVol contains data, internal space can be decreased no less than used space. Even though LUN size with data on it could be decreased on WAFL file system, ONTAP has no knowledge about upper level block structure due to SAN architecture so it could truncate data and damage the file system on that LUN, so the host needs to migrate the blocks containing the data into a new LUN boundary to prevent data loss. Each FlexVol can have its own QoS, FlashPool, FlasCache or FabricPool policies. If two FlexVol volumes are created, each on two aggregates and those aggregates owned by two different controllers, and the system administrator needs to use space from these volumes through a NAS protocol. Then they would create two file shares, one on each volume. In this case, the administrator will most probably even create different IP addresses; each will be used to access a dedicated file share. Each volume will have a single write waffinity, and there will be two buckets of space. Though even if two volumes reside on a single controller, and for example on a single aggregate (thus if the second aggregate exists, it will not be used in this case) and both volumes will be accessed through a single IP address, there will still be two write affinities, one on each volume and there always will be two separate buckets of space. Therefore, the more volumes you have, the more write waffinities you'll have (better parallelization and thus better CPU utilization), but then you'll have multiple volumes (and multiple buckets for space thus multiple file shares).

Плексы

Подобно RAID 1, плексы в системах ONTAP могут хранить зеркальные данные в двух местах, но в то время как обычный RAID 1 должен существовать в пределах одной системы хранения, два плекса могут быть распределены между двумя системами хранения. Каждый агрегат состоит из одного или двух плексов. Обычные системы хранения с высокой доступностью (HA) имеют только один плекс для каждого агрегата, в то время как конфигурации SyncMirror Local или MetroCluster могут иметь два плекса для каждого агрегата. С другой стороны, каждый плекс включает в себя базовое дисковое пространство из одной или нескольких групп RAID NetApp или LUN от сторонних систем хранения (см. FlexArray) в одном плексе, аналогично RAID 0. Если агрегат состоит из двух плексов, один плекс считается главным, а второй – ведомым; ведомые плексы должны состоять из точно такой же конфигурации RAID и дисков. Например, если у нас есть агрегат, состоящий из двух плексов, где главный плекс состоит из 21 диска данных и 3 SAS-дисков паритета объемом 1,8 ТБ в RAID TEC, то ведомый плекс должен состоять из 21 диска данных и 3 SAS-дисков паритета объемом 1,8 ТБ в RAID TEC. Второй пример: если у нас есть агрегат, состоящий из двух плексов, где главный плекс состоит из одного RAID 17 дисков данных и 3 SAS-дисков паритета объемом 1,8 ТБ, сконфигурированных как RAID TEC, а второй RAID в главном плексе – RAID DP с 2 дисками данных и 2 SSD-дисками паритета объемом 960 ГБ, то второй плекс должен иметь ту же конфигурацию: один RAID 17 дисков данных и 3 SAS-дисков паритета объемом 1,8 ТБ, сконфигурированных как RAID TEC, а второй RAID в ведомом плексе – RAID DP с 2 дисками данных и 2 SSD-дисками паритета объемом 960 ГБ. Конфигурации MetroCluster используют технологию SyncMirror для синхронной репликации данных. Существует два варианта SyncMirror: MetroCluster и Local SyncMirror, оба использующие одну и ту же технику плексов для синхронной репликации данных между двумя плексами. Local SyncMirror создает оба плекса в одном контроллере и часто используется для дополнительной защиты от сбоя всего дискового полока в системе хранения. MetroCluster позволяет реплицировать данные между двумя системами хранения. Каждая система хранения может состоять из одного контроллера или быть сконфигурирована как пара HA с двумя контроллерами. В одной паре HA возможно наличие двух контроллеров в отдельных шасси, расстояние между которыми может составлять десятки метров, в то время как в конфигурации MetroCluster расстояние может достигать 300 км.

Similar to RAID 1, plexes in ONTAP systems can keep mirrored data in two places, but while conventional RAID 1 must exist within the bounds of one storage system, two plexes could be distributed between two storage systems. Each aggregate consists of one or two plexes. Conventional HA storage systems have only one plex for each aggregate, while SyncMirror local or MetroCluster configurations can have two plexes for each aggregate. On the other hand, each plex includes underlying storage space from one or more NetApp RAID groups or LUNs from third party storage systems (see FlexArray) in a single plex similarly to RAID 0. If an aggregate consists of two plexes, one plex is considered a master and second as a slave; slaves must consist of exactly the same RAID configuration and drives. For example, if we have an aggregate consisting of two plexes where the master plex consists of 21 data and 3 1.8 TB SAS parity drives in RAID TEC, then the slave plex must consist of 21 data and 3 1.8 TB SAS parity drives in RAID TEC. The second example, if we have an aggregate consisted of two plexes where master plex consists of one RAID 17 data and 3 parity SAS drives 1.8 TB configured as RAID TEC and second RAID in the master plex is RAID DP with 2 data and 2 parity SSD 960 GB. The second plex must have the same configuration: one RAID 17 data and 3 parity SAS drives 1.8 TB configured as RAID TEC, and the second RAID in the slave plex is RAID DP with 2 data and 2 parity SSD 960 GB. MetroCluster configurations use SyncMirror technology for synchronous data replication. There are two SyncMirror options: MetroCluster and Local SyncMirror, both using the same plex technique for synchronous replication of data between two plexes. Local SyncMirror creates both plexes in a single controller and is often used for additional security to prevent failure for an entire disk shelf in a storage system. MetroCluster allows data to be replicated between two storage systems. Each storage system could consist of one controller or be configured as an HA pair with two controllers. In a single HA pair, it is possible to have two controllers in separate chassis and distance from each other could be tens of meters, while in MetroCluster configuration distance could be up to 300 km.

Нелетучая память

Как и многие конкуренты, NetApp ONTAP использует память как значительно более быстрый носитель для приема и кэширования данных от хостов и, что наиболее важно, для оптимизации данных перед записью, что значительно повышает производительность таких систем хранения. В то время как конкуренты широко используют энергонезависимую память с произвольным доступом (NVRAM) для сохранения данных в ней при неожиданных событиях, таких как перезагрузка, как для кэширования записи, так и для оптимизации данных, системы NetApp ONTAP используют обычную память с произвольным доступом (RAM) для оптимизации данных и выделенную NVRAM или NVDIMM для ведения журнала исходных данных в неизменном виде, как они поступают от хостов, аналогично ведению журнала транзакций в реляционных базах данных. Следовательно, в случае сбоя оперативная память будет автоматически очищена после перезагрузки, а данные, хранящиеся в энергонезависимой памяти в виде журналов, называемых NVLOGs, переживут перезагрузку и будут использованы для восстановления согласованности. Все изменения и оптимизации в системах ONTAP выполняются только в оперативной памяти, что позволяет уменьшить объем энергонезависимой памяти, необходимой для систем ONTAP. После оптимизации данные от хостов структурируются подобно принципу "Тетрис", оптимизируются и подготавливаются, проходя несколько этапов (например, WAFL и RAID), для записи на базовые диски в RAID-группы на агрегате, где будут храниться данные. После оптимизации данные последовательно записываются на диски в рамках транзакции точки согласованности (CP). Данные, записанные в агрегаты, содержат необходимые метаданные WAFL и четность RAID, поэтому дополнительные операции чтения с дисков данных, вычисления и записи на диски четности не выполняются, как в традиционных RAID 6 и RAID 4 группах. CP сначала создает системный снимок на агрегате, куда будут записаны данные, затем оптимизированные и подготовленные данные из оперативной памяти записываются последовательно в виде единой транзакции в агрегат. В случае сбоя вся транзакция откатывается при внезапной перезагрузке, что гарантирует согласованность файловой системы WAFL. В случае успешного завершения транзакции CP новая активная точка файловой системы распространяется, а соответствующие NVLOGs очищаются. Все данные всегда записываются в новое место, и переписывание исключено. Блоки данных, удаленные хостами, помечаются как свободные, чтобы их можно было использовать в последующих циклах CP, и система не столкнется с нехваткой места благодаря политике WAFL, которая всегда записывает новые данные в новое место. Только NVLOGs в системах хранения HA реплицируются синхронно между двумя контроллерами для обеспечения отказоустойчивости системы хранения HA, что помогает снизить общие накладные расходы на защиту памяти системы. В системе хранения с двумя контроллерами в конфигурации HA или MetroCluster с одним контроллером на каждом узле каждый из двух контроллеров разделяет свою энергонезависимую память на две части: локальную и принадлежащую партнеру. В конфигурации MetroCluster с четырьмя узлами каждая энергонезависимая память разделена на следующие части: локальную, локальную память партнера и удаленную память партнера. Начиная с системы All Flash FAS A800, NetApp заменила модуль NVRAM PCI на NVDIMM, подключенные к шине памяти, что повысило производительность.

Like many competitors, NetApp ONTAP systems utilizing memory as a much faster storage medium for accepting and caching data from hosts and, most importantly, for data optimization before writes which greatly improves the performance of such storage systems. While competitors widely using non volatile random access memory (NVRAM) to preserve data in it during unexpected events like a reboot for both write caching and data optimization, NetApp ONTAP systems using ordinary random access memory (RAM) for data optimization and dedicated NVRAM or NVDIMM for logging of initial data in an unchanged state as they came from hosts similarly as transaction logging done in Relational databases. So in case of disaster, naturally, RAM will be automatically cleared after reboot, and data stored in non volatile memory in the form of logs called NVLOGs will survive after reboot and will be used for restore consistency. All changes and optimizations in ONTAP systems done only in RAM, which helps to reduce the size of non volatile memory for ONTAP systems. After optimizations data from hosts structured in Tetris like manner, optimized and prepared with passing few stages (i. e., WAFL and RAID) to be written in underlying disks in RAID groups on the aggregate where data are going to be stored. After optimizations, data is going to be sequentially written on disks as part of the Consistency Point (CP) transaction. Data written to aggregates will contain necessary WAFL metadata and RAID parity so no additional read from data disks, calculate and write to parity disks operations will occur as with traditional RAID 6 and RAID 4 groups. CP at first creating system snapshot on an aggregate where data are going to be written, then optimized and prepared data from RAM written sequentially as a single transaction to the aggregate, if it fails, the whole transaction fails in case of a sudden reboot which allows WAFL file system always to be consistent. In case of successful CP transaction new active file system point is propagated and corresponding NVLOGs cleared. All data are always going to be written to a new place, and no rewrites can occur. Data blocks deleted by hosts marked as free so they could be used later on next CP cycles and the system will not run out of space with the always write new data to new place policy of WAFL. Only NVLOGs in HA storage systems is replicated synchronously between two controllers for HA storage system failover capability, which helps to reduce overall system memory protection overheads. In a storage system with two controllers in HA configuration or MetroCluster with one controller on each site, each of the two controllers divides its own non volatile memory into two pieces: local and its partner. In MetroCluster configuration with four nodes, each non volatile memory divided into next pieces: local, local partner's and remote partner's. Starting with the All Flash FAS A800 system, NetApp replaced the NVRAM PCI module with NVDIMMs connected to the memory bus, increasing the performance.