ZFS: Переосмысление традиционной архитектуры хранения данных (ч.1)

Традиционные системы хранения данных сталкивались с рядом проблем, таких как высокая стоимость специализированного оборудования, риск скрытого повреждения информации и ограниченные возможности масштабирования. В ответ на эти вызовы в начале XXI века появилась ZFS — файловая система, которую без преувеличения можно назвать революционной. Это не просто очередной инструмент, а целостная архитектура хранения, кардинально изменившая подходы к управлению данными. ZFS интегрирует в себе функции менеджера логических томов (подобно EVMS или LVM), RAID-контроллера и продвинутых механизмов кэширования, что делает её одной из ключевых вех в эволюции технологий хранения данных. Она призвана заменить разрозненные и не всегда эффективно взаимодействующие компоненты единым, надежным и гибким решением.

Одним из значительных преимуществ ZFS стала возможность использования менее дорогостоящего, стандартного оборудования по сравнению с тем, что традиционно требовалось в отрасли, обеспечивая при этом превосходную масштабируемость. Более того, ZFS зачастую демонстрирует лучшую производительность без использования дорогостоящих аппаратных RAID-контроллеров. Оптимальная аппаратная конфигурация для систем хранения данных (СХД) на базе ZFS, как правило, включает:

• Ёмкие жесткие диски (HDD) в качестве основных хранилищ данных.

• Значительный объем оперативной памяти (RAM), используемой для многоуровневого адаптивного кэширования наиболее востребованных данных.

• Твердотельные накопители (SSD), которые могут служить для расширения кэша чтения и для журнальных записей, ускоряя определенные типы операций.

Более подробно аппаратная конфигурация описана в документации.

В этой статье мы рассмотрим ключевые концепции, лежащие в основе ZFS, её внутренние компоненты, передовые механизмы защиты данных от повреждений и потерь, а также методы, используемые для ускорения операций чтения и записи.

Общая аппаратно-программная структура ZFS:

Виртуальное устройство хранения (vdev) состоит из одной или нескольких реальных устройств; пул хранения состоит из одной или нескольких vdev.

Фундаментальной единицей хранения в ZFS является пул хранения (storage pool или zpool). Пул формируется из одного или нескольких виртуальных устройств (virtual device или vdev). Каждое vdev, в свою очередь, состоит из одного или нескольких физических дисков (HDD или SSD). Такая архитектура позволяет гибко конфигурировать хранилище, обеспечивая различные уровни производительности и отказоустойчивости.

Из созданного пула пользователь получает наборы данных (датасеты или datasets). Датасеты — это основные логические единицы хранения в ZFS, во многом аналогичные традиционным томам в других файловых системах. Они могут представлять собой точки монтирования файловой системы или блочные устройства, которые в ZFS известны как ZFS тома (ZFS Volume или zvol). zvol часто используются как виртуальные диски для виртуальных машин, swap-разделы или для приложений, требующих прямого доступа к блочному устройству. К датасетам применяются такие полезные функции ZFS, как мгновенные снимки (snapshots), квоты, сжатие и шифрование.

Исторический экскурс: Рождение и эволюция ZFS

Разработка ZFS стартовала приблизительно в 2001 году под руководством Джеффа Бонвика и Мэттью Аренса из Sun Microsystems. Команда стремилась создать файловую систему, которая не просто хранила бы данные, но и активно управляла ими, обеспечивая их сохранность и упрощая администрирование на огромных массивах хранения. Само название ZFS, изначально расшифровывалось как Zettabyte File System, указывало на колоссальный объем поддерживаемых данных, измеряемый в зеттабайтах — величины, на тот момент недостижимой для других файловых систем.

Официальный анонс ZFS состоялся 14 сентября 2004 года, став первым публичным заявлением о новой технологии. Важной вехой стала интеграция исходного кода ZFS в основную ветку разработки операционной системы Solaris 31 октября 2005 года. Наконец, в июне 2006 года ZFS стала доступна широкому кругу пользователей в составе обновления 6/06 для Solaris 10. Первоначальная тесная связь с Solaris сыграла решающую роль в раннем распространении ZFS, опираясь на существующую пользовательскую базу Sun Microsystems и её прочную репутацию на рынке серверов.

Переход к открытому исходному коду и OpenSolaris

Компания Sun Microsystems была одним из немногих корпораций-сторонников открытого исходного кода в начале нулевых, и в июне 2005 года большая часть кодовой базы Solaris, включая ZFS, была выпущена под условно свободной лицензией CDDL.

Одновременно был создан проект OpenSolaris с целью формирования сообщества разработчиков и пользователей для развития ОС. Его создание позволило сообществу участвовать в развитии ZFS.

Открытый исходный код способствовал быстрому распространению ZFS, и вскоре начались работы по её портированию на другие операционные системы:

• FreeBSD: Экспериментальная поддержка появилась в 2007 году (FreeBSD 7.0), а к 2009 году (FreeBSD 8.0) ZFS вышла из стадии бета-тестирования.

• Linux: Разработка порта FUSE началась в 2006 году, а нативного порта — в 2008 году. Первый стабильный релиз ZFS на Linux состоялся в 2013 году.

• macOS: Компания Apple начала портирование ZFS в 2007 году (в macOS 10.5 появилась поддержка только для чтения), за которым последовал проект MacZFS, разработанный сообществом.

Решение Sun сделать ZFS открытым исходным кодом значительно расширило её охват и влияние. Активные усилия по портированию подчеркнули огромный интерес и воспринимаемую ценность ZFS в широком Unix-сообществе. Однако некоторые нюансы лицензии CDDL, в частности её неполная совместимость с GPL, создавали определенные сложности для более широкой интеграции ZFS, особенно в ядро Linux.

Эпоха Oracle и разделение на OpenZFS и Oracle ZFS

В 2010 году произошло знаковое событие: компания Oracle приобрела Sun Microsystems. Это имело значительные последствия для будущего ZFS. После поглощения Oracle приняла решение прекратить публичное развитие OpenSolaris и перевела свою версию ZFS в разряд проприетарных продуктов. Это решение вызвало серьезную обеспокоенность в сообществе открытого исходного кода, поставив под вопрос дальнейшую судьбу ZFS как свободного проекта.

В ответ на это в 2010 году был создан проект illumos как форк последнего публичного релиза OpenSolaris. Его целью стало продолжение разработки OpenSolaris и ZFS в частности как открытого проекта.

В 2013 году был официально анонсирован проект OpenZFS, призванный координировать разработку открытой версии ZFS на различных платформах. С этого момента развитие Oracle ZFS и OpenZFS пошло независимыми путями, что потенциально могло привести к проблемам совместимости и расколу сообщества, развивающего проект.

Однако в 2017 года Oracle уволила практически всех своих основных разработчиков Solaris, сообщество интерпретировало это так, что Oracle больше не намерена поддерживать разработку платформы и ZFS в частности. 

Приобретение Sun Microsystems компанией Oracle и последующее изменение стратегии развития послужили катализатором для того, чтобы сообщество открытого исходного кода взяло на себя контроль над будущим ZFS. Это подчеркивает устойчивость и адаптивность проектов с открытым исходным кодом, сталкивающихся с изменениями в корпоративной политике. Формирование illumos, а затем OpenZFS стало прямым ответом на стремление сделать проект проприетарным.

OpenZFS сегодня: Совместная разработка и инновации

Разработка OpenZFS носит открытый характер, в неё вносят вклад различные частные лица и организации. Всю кодовую базу OpenZFS можно посмотреть в репозитории на GitHub. Вы можете поучаствовать в разработке проекта с помощью создания предложений по улучшению кода. Очень ценным будет тестирование работы master ветки и в случае нахождения ошибок создания pull request с исправлением ошибок в коде или создание issue с описанием проблемы.

Также вы можете поучаствовать в разработке проекта, посредством пожертвований в НКО, поддерживающем основных разработчиков OpenZFS.

В OpenZFS постоянно появляются улучшения и новые функции, такие как возможность расширять виртуальное устройство (vdev) после создания пула, расширенные возможности сжатия (например, ZStandard), распределенный RAID с контролем чётности (dRAID).

OpenZFS получила широкое распространение в различных Unix-подобных системах:

• Linux: Благодаря проекту ZFS on Linux (ZoL), который теперь объединен с OpenZFS, эта файловая система завоевала значительную популярность и даже интегрирована в такие дистрибутивы, как TrueNAS Scale.

• FreeBSD: ZFS является встроенной и основной частью этой операционной системы.

• Другие системы: Поддержка также присутствует в дистрибутивах illumos, OpenIndiana, NetBSD и ведутся экспериментальные работы по портированию на Windows (проект openZFS on Windows).

Слияние ZFS on Linux с OpenZFS в 2020 году стало важным событием, объединившим кодовые базы и оптимизировавшим разработку для Linux и других платформ. Различные уровни интеграции и поддержки в разных операционных системах (нативная в FreeBSD, сторонние модули в Linux и т. д.) отражают проблемы кроссплатформенной разработки и влияние вопросов лицензирования. Существование проектов, управляемых сообществом, таких как openZFS on Windows, подчеркивает стремление предоставить преимущества ZFS более широкому кругу пользователей, даже там, где официальная поддержка не предполагается. 

Базовые концепции RAID

Страйп (Stripe)

В системах хранения данных, которые используют несколько дисков, данные не записываются на один диск целиком. Для повышения производительности (скорости чтения и записи) и обеспечения избыточности (в зависимости от уровня RAID), данные разбиваются на более мелкие блоки.

Страйп – это набор блоков данных, которые записываются и считываются одновременно с нескольких дисков в массиве. 

Размер страйпа (Stripe Size / Stripe Unit Size) – это размер блока данных, который записывается на каждый отдельный диск в рамках одного страйпа. Этот размер обычно выбирается при настройке массива и может быть, например, 64 КБ, 128 КБ и т.д.

Ширина страйпа (Stripe Width) – это количество дисков, по которым распределяется один страйп данных. Если массив из 4 дисков данных (например, RAID 0 из 4 дисков), то страйп может быть распределен по всем 4 дискам.

Запись данных "страйпами" позволяет системе выполнять операции ввода-вывода параллельно на нескольких дисках, что существенно увеличивает пропускную способность по сравнению с записью данных последовательно на один диск.

Динамическая ширина страйпа - это более продвинутая функция, используемая в RAIDZ в ZFS. Она показывает, что система может изменять или адаптировать способ распределения данных по дискам (то есть, фактическую "ширину" или паттерн страйпа) в зависимости от различных факторов:

1. Тип рабочей нагрузки: Различные операции (например, большие последовательные записи/чтения против мелких случайных) могут быть более эффективны при разной ширине страйпа.

2. Размер операции ввода-вывода: Для очень мелких операций распределение данных  по всем дискам может быть неэффективно. Система может записать их на меньшее количество дисков.

3. Текущая загрузка системы: Система может адаптировать распределение для оптимизации использования ресурсов дисков.

Избыточность (Redundancy)

Избыточность является ключевым механизмом, который позволяет системе хранения данных продолжать работать и предотвращать потерю данных даже при выходе из строя одного или нескольких дисков в массиве.

Избыточность в RAID означает, что кроме самих пользовательских данных на дисках массива хранятся дубликаты данных и дополнительная служебная информация. Эта информация используется для:

1. Обнаружения отказа диска: Система может понять, что один из дисков больше не отвечает или содержит некорректные данные.

2. Восстановления потерянных данных: Если один диск выходит из строя, данные, которые были на нем, могут быть реконструированы или получены из избыточной информации, хранящейся на оставшихся дисках.

3. Поддержания работоспособности: Система может продолжать обслуживать запросы на чтение и в том числе на запись в "деградированном" состоянии, пока сбойный диск не будет заменен.

Чётность (Parity)

Один из основных методов обеспечения избыточности для защиты от потери данных.

Механизм четности в RAID:

1. Вычисление контрольной информации: На основе блоков пользовательских данных, хранящихся на нескольких дисках (N дисков), вычисляется специальный контрольный блок — блок четности. Чаще всего для этого используется операция исключающее ИЛИ (XOR).

2. Хранение блока четности: Вычисленный блок четности записывается на один или несколько других дисков в массив, в зависимости от желаемой избыточности.

3.  Восстановление данных при сбое: Если один из физических дисков выходит из строя, система может реконструировать потерянные данные. Для этого она использует данные с оставшихся исправных дисков и хранящуюся информацию о четности. Применяя ту же операцию XOR к имеющимся блокам данных и блоку четности, система может вычислить содержимое сбойного блока.

XOR (исключающее ИЛИ)

Операция XOR – это логическая операция, которая возвращает true (1), только если нечетное количество ее аргументов истинно. Если говорить о битах (0 и 1):

• 0 XOR 0 = 0

• 0 XOR 1 = 1

• 1 XOR 0 = 1

• 1 XOR 1 = 0

Если два бита одинаковые, результат XOR – 0. Если биты разные, результат XOR – 1.

Применение XOR для вычисления блока четности

Есть несколько дисков с данными. Для простоты берется 3 диска с данными (D1, D2, D3) и один диск для хранения блока четности (P).

1. Берется один бит: для вычисления бита четности взят один бит из соответствующей позиции на каждом диске с данными.

Допустим есть первые биты на каждом диске:

• Диск 1 (D1): 1

• Диск 2 (D2): 0

• Диск 3 (D3): 1

2. XOR применяется последовательно: Вычисление XOR для этих битов:

(D1 XOR D2) XOR D3

(1 XOR 0) XOR 1

1 XOR 1

0

3. Результат: Полученный бит (0) записывается в соответствующую позицию на диске четности.

Этот процесс повторяется для каждой позиции битов во всех блоках данных. В результате на диске четности формируется блок, где каждый бит является результатом XOR соответствующих битов данных.

Продолжение в следующей статье.