Знаете ли вы, почему ZFS обеспечивает безопасность данных?

Файловая система ZFS была разработана Sun для системы Solaris. ZFS - это 128-битная файловая система, которая может обрабатывать до 256 квадриллионов данных ZB (1ZB = миллиард ТБ). Работа над ZFS началась в 2001 году, но была официально объявлена ​​в конце 2004 года. В 2005 году ZFS была впервые представлена ​​OpenSolaris, а годом позже, в 2006 году, она была интегрирована с системой Solaris 10. Стоит отметить, что в то же время NetApp подала в суд на Sun и обвинила в использовании семи патентов. Спор в суде между компаниями продолжался до тех пор, пока в 2010 году Sun не перешла к Oracle. После приобретения Oracle подписала соглашение с NetApp, и с этого момента Oracle решила сделать код ZFS доступным по открытой лицензии sorce.

Прежде чем перейти к подробному описанию преимуществ системы ZFS, необходимо указать, на что не способны другие файловые системы. Прежде всего, не существует инструмента для устранения тихого повреждения данных, которое может быть вызвано поврежденным жестким диском, неисправным контроллером RAID, плохо написанным драйвером, прошивкой или неисправным лазером. Вы читаете это хорошо, поврежденный лазер может вызвать ошибки при сохранении данных. Например, в среде Fibre Channel операционная система записывает данные в матрицу SAN по сети и протоколу FC. К сожалению, прежде чем они достигнут матрицы, они повреждаются в пути лазером конвергентного передатчика, установленного на сервере. Современные файловые системы не имеют инструмента, который может обнаружить любые ошибки в записи.

Другая проблема - всевозможные ограничения, такие как размер тома, размер файла, количество файлов в одном каталоге или количество снимков. У нас также нет возможности мигрировать между различными платформами (x86, SPARC, PowerPC, ARM), без повторной синхронизации всей файловой системы.

Оказывается, что простое управление файловыми системами не просто; например, для CIFS, NFS или iSCSI нам нужно использовать разные инструменты. На проблемы управления также влияет необходимость создания томов, разделов и меток. Вы можете добавить медленное действие, использование постоянного блока данных, длительное расширение и аварийное восстановление или долгое время для создания новых томов.

Разработчики системы ZFS руководствовались одним девизом

«Создан для обеспечения целостности данных»

Система ZFS была разработана с нуля, что устранило 20 лет устаревших предположений, которые используют другие файловые системы. Этот подход был разработан для упрощения управления большими наборами данных. Кроме того, работа на наборах должна была быть возможной, пока они онлайн.

Стандартные файловые системы используют так называемые объемы. Это уровень, который обеспечивает связь между файловой системой и группой дисков. Это связано с тем, что большинство файловых систем предназначались для управления только одним диском. Тем не менее, развитие этой технологии позволило объединить диски для повышения производительности и надежности. Этот подход дал два варианта: сложный, или восстановление всей файловой системы с нуля, или простой, и, таким образом, добавление еще одного слоя так называемого. том, задачей которого было обеспечение связи между файловой системой и дисками. К сожалению, новый слой не решил всех проблем. Например, он не может обрабатывать более одной группы RAID одновременно, что приводит к ограничению размера такого тома и его производительности.

Например, он не может обрабатывать более одной группы RAID одновременно, что приводит к ограничению размера такого тома и его производительности

Схема связи в обычных файловых системах

В системе ZFS у нас есть так называемые «Дисковый пул», представляющий поверхность дисков и назначенных ему групп RAID. Благодаря такому подходу мы получаем практически неограниченные возможности расширения и, безусловно, лучшую производительность.

В обычной файловой системе, когда мы используем диск SATA 7200, который позволяет производить запись со скоростью 150 МБ / с, мы достигнем производительности на уровне емкости диска, то есть 150 МБ / с. Когда мы добавляем второй диск, мы должны создать на нем вторую независимую файловую систему, и все же максимум, который мы можем получить, составляет 150 МБ / с. В ZFS мы можем увеличить эту пропускную способность, добавив диски в один и тот же пул дисков и получив 300 МБ / с.

Конечно, в обычной системе вы можете настроить RAID для повышения производительности, например, RAID 0, и тогда мы достигнем 300 МБ / с, только при таком подходе ZFS к одному и тому же пулу дисков может подключить несколько групп RAID 0, что обеспечит определенную производительность выше. Это связано с тем, что стандартная файловая система не может обрабатывать более одной группы RAID одновременно. Более того, ZFS позволяет добавлять разные группы RAID и диски с разными спецификациями дисков в один и тот же пул дисков, что значительно повышает гибкость такой системы.

Если этого недостаточно, в конфигурации пула дисков мы можем настроить количество копий для каждого блока. Они могут быть одной, двумя или тремя копиями соответственно. Следовательно, вместо того, чтобы конфигурировать две группы RAID 0 и добавлять их в пул дисков, мы просто настраиваем RAID Z2 на четыре диска и по-прежнему емкостью 600 МБ / с, а из четырех дисков сбои могут быть 2. В примере обычного сбоя файловой системы один диск вызывает полную потерю данных.

Еще одним преимуществом использования дисковых пулов является динамическое распределение пространства. В стандартных файловых системах мы должны определиться с размером раздела. Это приводит к тому, что большие значения часто назначаются так, чтобы в будущем не оказалось, что у нас не хватит места. К сожалению, такой подход часто означает, что на практике используется только 30% выделенного пространства, а оставшиеся 70% просто теряются. В ZFS пространство распределяется динамически, что означает, что нам не нужно беспокоиться, в момент создания системы, какого размера и что важнее, мы не будем испытывать, как в случае обычных систем неиспользуемого пространства данных.

Сравнение пула хранения из ZFS с другими файловыми системами

В случае ZFS создание файловой системы происходит немедленно, а расширение пула дисков происходит так же быстро. В обычных файловых системах нам всегда приходится ждать, пока система отформатирует диски, а затем синхронизировать блоки данных, если мы настроили группу RAID. Добавление нового диска в группу RAID снова инициирует процесс синхронизации.

В случае отказа диска обычные системы снова синхронизируют весь том блока после блока, не проверяя, были ли данные в блоке или нет. ZFS синхронизирует только те блоки, на которых фактически существуют данные, что значительно ускоряет процесс восстановления. Например, если у нас есть файловая система ZFS объемом 1 ТБ, в которой было сохранено 250 ГБ данных, то восстановление такой системы после сбоя диска происходит на 382% быстрее, чем в случае стандартной файловой системы.

Например, если у нас есть файловая система ZFS объемом 1 ТБ, в которой было сохранено 250 ГБ данных, то восстановление такой системы после сбоя диска происходит на 382% быстрее, чем в случае стандартной файловой системы

Сравнение стандартной файловой системы связи с ZFS

Как вы можете видеть на диаграмме выше, и ZFS, и стандартные файловые системы имеют три уровня связи. В обычных файловых системах операции верхнего уровня выполняются на блоках, каждая операция записывается в журнал, который используется при синхронизации файловой системы после сбоя. К сожалению, такой подход не решает проблему «дыр в записи для RAID 5».

ZFS реализует процедуру связи, основанную на объектах, поэтому первый уровень ZPL заключается в преобразовании операций, выполняемых над данными, в изменения, внесенные в объекты, и объединении их в одну транзакцию. Следующим уровнем DMU является объединение транзакций, полученных в группы транзакций, и отправка созданных таким образом групп на уровень SPA, задачей которого является выполнение операций, сохраненных в полученных транзакциях. В этом случае наиболее важным изменением от стандартной файловой системы является использование транзакций, этот подход гарантирует, что файловая система будет одновременно выполнять все изменения объектов, хранящихся в транзакции, или не будет их выполнять. В результате, когда происходит сбой, системе не нужно выполнять повторную синхронизацию, как это происходит в обычных файловых системах, и нет необходимости сохранять журнал изменений для каждой операции, поскольку в других файловых системах есть места, что сильно влияет на производительность.

ZFS не нуждается в различных инструментах для предоставления служб NFS, CIFS или iSCSI, более того, для всех наборов данных, созданных в пуле дисков, доступны встроенные функции, такие как моментальные снимки, сжатие, шифрование, дедупликация или клонирование.

Единая файловая система Единая файловая система   Копирование при записи (COW) Копирование при записи (COW)

На приведенном выше рисунке показано, как ZFS сохраняет данные, что повышает производительность и устраняет «дыру в записи для RAID 5». Общее правило заключается в том, что новые данные никогда не перезаписывают обновленные данные, новые данные всегда сохраняются в новых пустых блоках. Благодаря тому, что это новые блоки, запись всегда последовательная, а не случайная.

На изображении № 1 вы можете увидеть старые данные, для 2 была начата новая запись данных, где блоки данных сначала сохраняются. На рисунке 3 ZFS продолжает записывать новые данные, на этот раз блоки контрольных сумм для новых данных обновляются. Старые данные остаются неповрежденными, только на рисунке 4 видно, что новые данные были успешно записаны, а старые данные в это время удаляются с дисков.

В случае стандартной файловой системы старые данные немедленно перезаписываются новыми. Таким образом, если процесс записи прерывается из-за сбоя питания, например, на шаге 3 изображения, где блоки данных были сохранены, а контрольные суммы не были обновлены, то после запуска системы у нас нет доступа к старым данным, поскольку они были частично перезаписаны. Хуже всего то, что файловая система не обнаружит эту ошибку, потому что в журнале событий будет информация о том, что блоки данных были сохранены правильно, и, к сожалению, журнал не проверяет запись контрольных сумм. Такая ситуация приводит к тому, что после сбоя система запускается и синхронизируется с использованием неправильных блоков, которые повредят всю файловую систему. Этот эффект называется «дырой в записи RAID5».

снимки в системе ZFS

Файловая система ZFS позволяет делать снимки, количество которых практически не ограничено на практике. Снимки в ZFS по сравнению со снимками в стандартных файловых системах не нагружают систему и занимают мало места, поскольку они хранят только дельту изменений. Создание снимка не означает, что данные сразу передаются ему, данные в снимке сохраняются только тогда, когда исходные данные перезаписываются.

Принцип снимков в ZFS

Оказывается, эта тема первой в мире переехала в лабораторию ЦЕРН. Что ж, в ЦЕРН было подозрение, что данные, записанные на 3000 матрицах, являются подозрительными. Что сделано? Была написана программа FSPro, задачей которой было записать на матрицах файл размером 1 ГБ, разбитый на блоки по 1 МБ, которые были записаны с интервалом в 1 секунду. Затем файл 1 ГБ также считывался в блоках по 1 МБ с интервалом в 1 секунду. Поскольку было известно, что было записано, было очевидно, какого чтения следует ожидать. Выяснилось, что после 3 недель испытаний было обнаружено до 152 случаев молчаливого повреждения данных.

ZFS может обнаруживать повреждение данных без вывода сообщений, тогда как стандартные системы могут обнаруживать повреждение только одного бита в блоке данных. Почему это происходит?

Почему это происходит

Целостность данных в ZFS

Основная проблема заключается в расположении контрольной суммы. Ну, стандартные файловые системы сохраняют блоки данных и их контрольную сумму в одном и том же блоке данных одновременно. Таким образом, если один бит поврежден в этом блоке, файловая система может обнаружить поврежденные данные при чтении данных из этого блока. Проблема возникает при записи спектра, записи в неправильный блок или чтении неправильного блока и т. Д.

О чем идет речь? Например, мы сохраняем состояние нашей учетной записи в блоке данных, пусть это будет 5000 злотых и их контрольная сумма. Затем система попросит вас обновить эту сумму до 10000PLN и ее контрольной суммы. Поэтому он отправляет запрос на диск для обновления этого блока, и мы получаем обратную связь, что обновление было выполнено. На практике диск этого не делал. В этот момент, когда система снова считывает блок, она получит информацию о том, что баланс счета составляет 5000 злотых, конечно, проверьте контрольную сумму, чтобы убедиться, что данные не повреждены, но, поскольку сумма не была сохранена, данные с системной точки зрения не являются повреждены.

Как это выглядит, когда вы пишете в неправильный блок? Предположим, что ситуация аналогична: система просит вас сохранить данные в блоке 93, данные естественно содержат состояние нашей учетной записи, на этот раз это будет 3000 злотых, через некоторое время система попросит вас обновить блок 93, на этот раз состояние нашей учетной записи имеют стоимость 7000 злотых. Диск выполняет запись и подтверждает ее для файловой системы. Только на практике диск вместо записи данных в блок 93 сохранил его, заблокировав головку 72. Хотя данные были сохранены правильно, они находятся в неправильном секторе диска, и, следовательно, данные в блоке 93, а также их сумма не была перезаписана. Когда система считывает данные из блока 93, потому что она знает, что должны быть данные о состоянии нашей учетной записи, то с точки зрения целостности данных все будет хорошо, поэтому в этот момент мы испарим 4000 PLN с нашей учетной записи.

Что изменилось в ZFS, чтобы он мог обнаруживать повреждение данных в режиме без вывода сообщений? Прежде всего, ZFS записывает блоки данных отдельно и сохраняет контрольные суммы отдельно. Кроме того, ZFS использует самопроверяющееся дерево в соответствии с терминологией криптографии, поэтому для контрольной суммы производятся последующие итоги, пока не будет достигнут самый высокий блок в дереве, также называемый корневым блоком. Стоит отметить, что контрольные суммы являются 256-битными и сохраняются в метаданных файловой системы.

Как ZFS справляется с призрачной записью? Когда в ZFS мы сохраняем состояние нашей учетной записи, которое первоначально составляет 5000 злотых, блок данных и сумма метаданных сохраняются отдельно, а теперь, если мы обновляем, предполагая, что диск не сохранит блок данных, как это было раньше в конце концов, это сохранит новую сумму. Благодаря этому во время чтения система обнаружит, что сумма не будет соответствовать сохраненным данным, поэтому они будут считаться поврежденными.

Похожая ситуация - запись в неправильный блок. Например, если мы запишем состояние нашей учетной записи в блок 93, а сумма будет сохранена в метаданные, а затем мы обновим, где данные будут записаны в блок 72 вместо 93, тогда контрольная сумма данных обновления будет правильно сохранена в метаданные. Таким образом, при чтении система может проверить, что данные в блоке 93, которые не были обновлены, не соответствуют сумме.

Теперь, когда мы знаем, как ZFS обнаруживает поврежденные данные, теперь стоит написать, как это исправить. Ниже приведен чертеж, который показывает, что происходит с поврежденными данными в других файловых системах. Как видите, хотя данные повреждены, они все еще обрабатываются.

Бесшумное повреждение данных в обычной файловой системе

В случае ZFS это выглядит иначе. Данные восстанавливаются в режиме реального времени благодаря инструменту RAID Scrubbing, который эквивалентен инструменту FSCK для других систем. Основное отличие заключается в том, что FSCK можно запускать только на отключенном томе, а RAID Scrubbing работает в режиме онлайн.

Механизм ремонта сайлентблока в ZFS

Как видно из рисунка выше, когда поврежденный блок считывается с дисков, ZFS обнаружит его, после обнаружения он немедленно восстановит его, используя копию этого блока, сохраненную на других дисках, и только затем предоставит данные из этого блока для приложения.

Файловая система ZFS была разработана для динамического выбора размеров блоков для данных, которые на ней сохраняются. Размеры блоков в ZFS варьируются от 512B до 128K. Почему размер динамического блока так важен? Когда у нас есть обычная файловая система с фиксированными 4K-блоками и мы сохраняем номер телефона в текстовом файле, который занимает чуть меньше 47B, мы теряем много места.

Когда у нас есть обычная файловая система с фиксированными 4K-блоками и мы сохраняем номер телефона в текстовом файле, который занимает чуть меньше 47B, мы теряем много места

Блок 4к записан с 47 байтами

Когда тот же самый текстовый файл с номером телефона записывается в меньший блок, например 512B, тогда мы теряем намного меньше места.

Размер блока 512B сохранен 47Bytes

Другим примером является файл, который занимает 17 ГБ, пусть это будет фильм. В тот момент, когда мы сохраняем его на 4K-блоках, мы должны сохранить его на 4456448 блоках. Если один и тот же файл будет сохранен в блоках 128 КБ, то он будет только 139264 блоками, то есть будет в 35 тысяч раз меньше операций ввода-вывода, что приведет к повышению производительности системы. Конечно, кто-то скажет, что в этом случае вы можете использовать еще большие блоки, например, 100 МБ, тогда при таком большом файле будет еще меньше блоков для записи. Однако оказывается, что это не так просто, потому что, если мы хотим отредактировать 100 КБ из этого фильма, то нам придется прочитать блок до 100 МБ. Создатели ZFS провели множество тестов, которые подтвердили, что диапазон предлагаемых блоков оптимально подобран.

Блоки переменных данных в системе ZFS

Если вы говорите о файловой системе, проще всего представить ее в виде треугольника, вверху находятся глобальные метаданные, в середине - локальные метаданные, а внизу - реальные данные. Когда дело доходит до занятости, сами метаданные занимают около 1% площади.

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

В случае ZFS восстановление системы всегда начинается сверху, с самых важных блоков, то есть с метаданных. Благодаря этому мы все еще можем получить доступ к некоторым данным во время реконструкции. Когда мы не можем восстановить 100% данных, по крайней мере, у нас есть доступ к данным, которые не были повреждены.

Поврежденная файловая система

Конечно, разработчики файловой системы ZFS заявили, что было бы глупо терять несколько ГБ данных только потому, что один блок метаданных был поврежден, тем более что они занимают только 1% поверхности. Вот почему так называемые То же самое и локальные метаданные имеют 2 копии данных, а глобальные блоки данных имеют 3 копии. Если к пулу дисков добавлен RAID 1, то в локальных метаданных будет 4 копии данных, а в глобальных копиях - 6 копий данных. Таким образом, ZFS может пережить сбои, которые не может пережить ни одна другая файловая система.

Файловая система ZFS может анализировать трафик данных и искать в нем определенные шаблоны поведения, которые она использует для повышения производительности после распознавания. Если в обычной файловой системе одно и то же видео будет воспроизводиться тремя пользователями одновременно, тогда чтение будет рассматриваться как чтение в случайном режиме, которое имеет худшую производительность.

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

Анализ видео, воспроизводимого в системе ZFS

Кроме того, ZFS может анализировать движение в двух измерениях одновременно, что означает, что его также можно использовать с приложениями HPC.

Анализ матрицы данных в двух измерениях

Файловая система ZFS использует ОЗУ определенным образом. В стандартных системах это работает так, как показано на рисунке ниже, то есть самые последние данные хранятся в ОЗУ, самые старые передаются на жесткие диски.

RAM в стандартной файловой системе

ZFS решила реорганизовать принцип работы оперативной памяти. Он разделил его на две части: первая действует как стандартное ОЗУ, а вторая предназначена для хранения наиболее часто используемых данных с целью ускорения доступа к ним. Это своего рода «автоуровни».

Это своего рода «автоуровни»

ARC или RAM в ZFS

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

Я надеюсь, что после прочтения этой статьи вы не сомневаетесь, какую файловую систему следует использовать для хранения ваших ценных данных. Если вы ищете NAS-сервер, который поддерживает ZFS, мы рекомендуем его QNAP ES1640dc.

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

Мы анализируем системный сбой, ZFS Sun Microsystem, и [...] ZFS успешно обнаруживает все повреждения и восстанавливает их от других. Кэширование в памяти и периодическая очистка метаданных при фиксации транзакции .

Также стоит посмотреть видео ниже, где показано, насколько устойчива ко всем типам сбоев матричный кластер на основе ZFS и GlusterFS.