Статья взята с pcmag.ru
Автор статьи: Виктор Латушкин ([email protected])

Оглавление:
* ZFS — новый взгляд на файловые системы
* Три кита ZFS
* ZFS изнутри: пулы
* ZFS изнутри: контроль целостности
* ZFA изнутри: RAID-Z
* ZFS изнутри: масштабируемость и производительность
* ZFS глазами администратора
* Заключение

zfs__novii_vzglyadna_failovie_sistemi_0Разговор о ZFS хотелось бы начать с нескольких слов о проблемах, присущих современным файловым системам (ФС), и причинах их возникновения. Во-первых, большинство современных файловых систем не имеют средств защиты от повреждений данных. Если данные на пути от диска до оперативной памяти машины будут повреждены, ни одна из систем, за исключением ZFS, не сообщит вам об этом.

Во-вторых, существующие файловые системы «бесчеловечны», когда речь идет об администрировании. Прежде чем создать файловую систему, необходимо диски отформатировать, разбить на разделы, создать тома, выбрать размер блока, определить, насколько большой должна быть система, до каких размеров она может вырасти и сколько файлов может быть создано… После того как файловая система создана, нужно добавить ее в конфигурационные файлы, чтобы обеспечить автоматическое монтирование при загрузке или предоставлении доступа к ней удаленным клиентам. При этом необходимо все время помнить ее параметры и наложенные ограничения (размер блока, максимальный размер системы, количество файлов, каталогов и т. д.). Если руководствоваться максимальными возможностями конкретной файловой системы, то можно столкнуться с неприятными сюрпризами.

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

Цель создания ZFS — решить проблемы традиционных ФС. Управление данными должно быть простым и комфортным, доступ к данным быстрым, и, что главное, данные должны быть в безопасности.

Разработчики ZFS понимали, что проблемы существующих файловых систем решить невозможно и нужно начинать «с чистого листа», отбросив устаревшие на 20 лет принципы.

Три кита ZFS.

Итак, каковы же основные принципы конструкции самой ZFS?

Первое — организация всего доступного дискового пространства в единый пул (пул накопителей). Основная идея — избавиться от управления отдельными дисками и томами и перейти к использованию концепций виртуальной памяти в проекции на дисковое пространство. Если нужно установить в сервер новые модули памяти, достаточно выключить его (при отсутствии средств динамической реконфигурации), установить новые модули и включить сервер снова. Не требуется никаких команд вроде dimmconfig, создания виртуальных «модулей памяти», разграничения прав… Все гораздо проще. Когда программе нужна память, она выдает запрос ОС, и та предоставляет ее. Неважно, где будет выделена эта память. Можно использовать такой же подход и для дискового пространства, ZFS работает именно так. Имеется пул накопителей, к нему добавляем имеющиеся диски (почти так же, как новые модули памяти). В результате появляются многочисленные новые возможности.

Второе — сквозной контроль целостности данных. Проверяется каждый блок данных, чтобы убедиться, что он такой, каким должен быть. 20 лет назад это считалось очень дорогостоящей (в смысле вычислительных ресурсов) операцией. Сегодня, когда скорость процессоров по сравнению со скоростью дисков возросла на порядки, оказалось, что это совсем недорого. Используемые в ZFS алгоритмы на современном процессоре класса Opteron позволяют вычислять контрольные суммы со скоростью 2—8 Гбайт/с. Это означает, что на большинстве современных машин можно пожертвовать небольшой долей процессорного времени для гарантирования целостности данных. Альтернатива — «неявные» повреждения данных, не проявляющиеся при чтении с диска.

Третье — транзакционность. Данные всегда хранятся в целостном и непротиворечивом состоянии. Существующие данные и метаданные на диске никогда не перезаписываются. В случае возникновения проблем всегда можно вернуться в предыдущее состояние. Все это позволяет снять практически все ограничения на порядок выполнения дисковых операций (что позволяет получить существенный выигрыш в производительности).

ZFS изнутри: пулы.

Теперь сделаем небольшой экскурс в историю, чтобы понять, как появилась оказавшаяся весьма живучей концепция «том». Вначале был диск. Один диск, на котором создавалась файловая система. С течением времени, однако, кого-то перестала устраивать емкость одного диска, кого-то — скорость, кого-то — надежность. Возникла необходимость либо перепроектировать каждую файловую систему для работы с несколькими дисками, либо (что проще) сделать программную «прокладку», которая будет управлять несколькими дисками и представлять их файловой системе как один большой быстрый и надежный диск. Неудивительно, что был выбран более простой путь, и вокруг понятия «тома» выросла целая индустрия. Однако такой подход, по сути, лишь усугубил проблемы интерфейса файловая система—диск.

Вернемся теперь к первому принципу и сравним концепцию пула накопителей с традиционной моделью. При традиционном подходе имеются файловые системы, связанные с томами, которые, в свою очередь, связаны с дисками. Чтобы увеличить пространство или пропускную способность ФС, нужно добавить диски в соответствующий том. Представим ситуацию, когда две ФС переполнены, а нам необходимо еще по 10 Гбайт в каждой из них. Как добавить необходимое пространство для каждой ФС? Казалось бы, просто: берем пару дисков, подключаем и все. Но… В сервере есть место только для одного диска. Конечно, можно разбить этот новый диск на разделы и добавить их к каждому тому, но при этом возрастает сложность, снижается надежность и т. д.

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

Теперь вернемся к интерфейсу ФС—диск. Это интерфейс, оперирующий блоками данных фиксированного размера. Что же с ним не так? Он слишком прост. По существу, все, что мы можем выразить с его помощью, — это команды «запиши этот блок туда», «прочитай этот блок оттуда». И не более. Никакого способа выразить семантическую информацию, например «я пытаюсь переместить этот файл из текущего каталога в другой», не существует. Просто последовательность операций чтения и перезаписи разных блоков в разных местах диска. Это означает, что при исчезновении питания теряется целостность данных на диске, поскольку шел процесс внесения изменения в ФС. Для решения этой проблемы опять пошли простым путем и придумали механизм «журналирования»: прежде чем вносить изменение, сделать запись в журнале о том, что оно планируется, затем внести изменение и возвратиться к журналу, в котором записать, что изменение внесено. Теперь, если пропадает питание, известно, где может быть нарушена целостность состояния ФС. Однако это не решает проблему, а лишь позволяет ускорить команду fsck!

Когда дело доходит до менеджера томов и записи данных на физический диск, трудности добавляются. Во первых, менеджер томов понятия не имеет, какой смысл в записи одного блока в начале диска, затем одного блока в конце, потом посередине и т. д. Он не может оптимизировать порядок, даже если это даст многократный выигрыш в производительности, поскольку ФС, инициировавшая эти операции, зачастую рассчитывает на то, что они будут выполняться именно в указанном порядке. Проблемы, присущие ФС, также применимы и здесь: при потере питания теряется целостность, и необходимо ее восстанавливать, например копируя целиком один диск на другой при загрузке системы, даже если область, где целостность потеряна, составляет всего 2% размера диска. Было придумано так называемое журналирование измененных регионов, которое опять не решает изначальную проблему, а добавляет ограничения на порядок выполнения операций ввода-вывода.

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

ZFS изнутри: контроль целостности

Рассмотрим теперь концепцию целостности данных в ZFS. Во-первых, это использование техники копирования при записи (copy-on-write, COW), которая широко используется в современных системах виртуальной памяти. В ZFS никогда ни данные, ни метаданные не записываются поверх предыдущей их версии. Поэтому состояние ФС на диске всегда целостно, и команда fsck не нужна.

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

В-третьих, это использование контрольных сумм (далее — КС) для всех данных ФС. Благодаря им мы можем обнаруживать как «явные» (о которых система сообщает, например плохой сектор), так и «неявные» (которые есть, но о них система не сообщает) повреждения данных. Поскольку КС используются и для данных, и для метаданных, можно проверить целостность метаданных перед их использованием.

Проиллюстрируем, как работает механизм копирование при записи на примере (рис. 1).

zfs__novii_vzglyadna_failovie_sistemi_1
zfs__novii_vzglyadna_failovie_sistemi_2
zfs__novii_vzglyadna_failovie_sistemi_3
zfs__novii_vzglyadna_failovie_sistemi_4
Мы имеем изначальное дерево блоков (квадрат 1). Отметим, что логически ФС можно представлять как дерево блоков. Все данные в ФС могут быть найдены с помощью ссылок на дочерние блоки, начиная с корневого. Хотя дерево, представленное в примере, похоже на двоичное, фактическое дерево данных в ZFS недвоично. Оно более широкое и неглубокое, чем аналогичное по количеству узлов двоичное дерево. Глубина его также не имеет никакого отношения к глубине вложенности каталогов в ФС. Теперь мы хотим записать новые данные (блоки зеленого цвета в квадрате 2) вместо некоторых старых. Находим неиспользуемое место на диске и записываем туда наши «зеленые» данные. Далее надо сделать так, чтобы кто-то на них указывал и их можно было найти впоследствии. Для этого опять найдем свободное место для новых «зеленых» блоков косвенной адресации, расположенных выше по дереву, изменяем в них адреса блоков данных и записываем «зеленые» блоки косвенной адресации, а затем повторяем эту же операцию для блоков косвенной адресации, лежащих выше. Как только записаны все измененные блоки косвенной адресации, мы получим две копии целостного состояния ФС — синее, соответствующее первоначальному, и сине-зеленое, соответствующее измененному состоянию. Теперь для перевода ФС из одного целостного состояния в другое необходимо записать лишь один блок (uber-блок). А это — атомарная операция, в том смысле, что она состоит в записи ровно 1 сектора на диске. Поскольку этот блок — отправная точка, для его защиты принимаются специальные меры.

Как только записан этот сектор, ФС переведена из одного целостного состояния в другое. Насколько это все эффективно? Для записи всего лишь одного измененного блока данных потребуется прочитать и записать заново пару уровней блоков косвенной адресации и uber-блок. Делать это для каждого изменения очень дорого, поэтому в ZFS используется объединение изменений в группы, которые затем записываются на диски единым потоком. Это позволяет поддерживать накладные расходы на низком уровне — практические измерения показывают, что записываемые метаданные составляют 1–2% объема данных.

А что происходит с синими блоками данных при переходе от квадрата 3 к квадрату 4, не теряются ли они? Ответ — нет, потому что мы привязываем к изменениям пользовательских данных в рамках одной группы транзакций все необходимые изменения наших метаданных, и если мы выделяем дополнительные блоки или освобождаем ранее занятые, то производим необходимые изменения и метаданных. В результате чего все остается целостным.

В качестве бонуса мы получаем моментальные снимки практически бесплатно. Все, что нужно сделать, — это не освобождать старые «синие» блоки, а сохранить ссылку на корень «синего» дерева, т. е. нам проще даже делать моментальные снимки, чем не делать их, поскольку в последнем случае придется освобождать ранее занятые блоки, модифицировать метаданные, а это дополнительная работа.

Обратимся теперь к сквозному контролю целостности данных. Зачем он нужен, когда есть разнообразные контрольные суммы на разных уровнях, начиная с диска? Чтобы ответить на этот вопрос, посмотрим, как наиболее часто используются КС в существующих системах. Пальма первенства в использовании КС для проверки данных принадлежит не нам. КС уже многие годы применяется в самых разных технологиях и компаниях. Например, многие изготовители дисковых систем используют в своих массивах секторы увеличенного размера — 520 байт вместо 512 байт. В этих 8 байт как раз и хранится КС и другая служебная информация. Проблема однако в том, что такая контрольная сумма записывается вместе с блоком данных, который она должна проверять, поэтому, если мы даем диску команду записать новый блок данных поверх старого, а диск ее не выполняет вообще, например из-за ошибки в микрокоде, или выполняет, но неправильно, записывая данные не туда, куда просили, при последующем прочтении этого блока мы получим старый блок со старой правильной контрольной суммой. Но мы будем думать, что это новый блок! И подобные ошибки очень тяжело обнаружить. Конечно, это не частые события, но, во-первых, в индустрии есть даже специальные термины для их обозначения, а во-вторых, любой, кто проработал в области хранения данных продолжительное время, наверняка сталкивался, а возможно, и участвовал в анализе подобных проблем и может подтвердить, что это занятие не из приятных. Нельзя также исключить и случаи непреднамеренного повреждения данных, связанные с человеческими ошибками, например использованием диска для ФС и области подкачки системы виртуальной памяти и т. п. Встречаются иногда ошибки, возникающие при передаче данных с диска в оперативную память машины.

Поэтому в ZFS КС хранятся отдельно от данных (рис. 2).

zfs__novii_vzglyadna_failovie_sistemi_5

КС блоков данных хранятся в блоках косвенной адресации, указывающих на них, КС блоков косвенной адресации — в блоках косвенной адресации предшествующего уровня и т. д. до uber-блока, который только единственный хранит свою контрольную сумму. Получившееся дерево при условии использования хороших хэш-функций для вычисления КС на языке математики называется хэш-деревом, и КС uber-блока может рассматриваться как КС всего пула данных. Такой подход позволяет обнаруживать больше ошибок, чем традиционный.

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

Предположим, приложению понадобился блок данных с диска, оно запросило его у ФС, которая, в свою очередь, запросила этот блок у менеджера томов. Менеджер томов, зная, что данные хранятся на зеркале из двух дисков, может считывать их с любого подзеркала, например с левого. Предположим также, что интересующий нас блок данных на левом подзеркале «неявно» поврежден. Что произойдет дальше? Менеджер томов прочитает «битые» данные с левого подзеркала и благополучно вернет их ФС.

Если это окажется блок метаданных ФС, есть шанс аварийно завершить работу и предотвратить дальнейшее распространение ошибки. Если же нет — ФС вернет «левые» данные приложению, и не известно, к каким дальнейшим ошибкам это приведет.

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

zfs__novii_vzglyadna_failovie_sistemi_6
zfs__novii_vzglyadna_failovie_sistemi_7
zfs__novii_vzglyadna_failovie_sistemi_8

Поскольку в ZFS нет искусственного разделения на менеджер томов и файловую систему, в момент обнаружения поврежденного блока можно проверить, нет ли у нас избыточной копии этого блока. Если есть, а в случае зеркала она есть на правом подзеркале, можно прочитать ее, проверить контрольную сумму и вернуть правильный блок приложению. И это еще не все. Можно исправить поврежденный блок на левом подзеркале, записав его заново! Таким образом, мы не только обнаружим ошибку, но и исправим ее! Кроме этого, мы можем пожаловаться на плохое поведение диска FMA (системе, обрабатывающей сбои и отказы), который, имея информацию о конфигурации системы и статистику всех ошибок, способен сказать, нужно ли продолжать использовать этот диск. Все это также применимо и в случае использования других методов создания избыточности (RAID-Z и дубль-блоков), о которых мы сейчас и поговорим.

ZFA изнутри: RAID-Z.

Что такое RAID-Z? Всем знакома концепция RAID в общем и RAID-5 в частности. RAID-Z — реализация RAID-5 без присущих ему недостатков. Основные недостатки RAID-5 — фиксированный размер страйпа и проблема, называемая «write hole». Известно, что в классическом RAID-5 при модификации неполного страйпа необходимо считать старые данные, изменить их, вычислить новые данные и новое значение четности, а затем записать. Даже если мы меняем один сектор, то необходимо записывать два сектора — сначала данные, а потом четность (или наоборот). Если в промежутке между этими двумя операциями записи произойдет потеря питания, на нашем диске окажется мусор — блок данных или блок четности окажется неправильным. Конечно, есть способы обойти эту проблему — стоит лишь добавить в систему ту или иную форму энергонезависимой памяти. Однако это, во-первых, дорого, а во вторых, энергонезависимая память чаще всего «зависит» от небольшой батареи, которой хватает на 1—3 суток. Что будет при пропадании питания на более длительный срок — нетрудно представить.

В RAID-Z размер страйпа не фиксирован: он равен размеру логического блока файловой системы, записываемого или считываемого в данный момент. Благодаря интегрированности системы, т. е. отсутствию искусственного разделения ФС и менеджера томов, мы просто храним необходимые параметры страйпа в метаданных этого логического блока. Таким образом, все операции записи в RAID-Z превращаются в операции записи целого страйпа, что положительно сказывается на производительности и вместе с COW устраняет необходимость в дорогой энергонезависимой памяти. Помимо этого, благодаря логическому блоку всегда можно обнаружить ошибку и попытаться произвести комбинаторную реконструкцию правильного блока.

RAID-Z2 — аналог RAID-Z, использующий два диска для хранения информации о четности, что позволяет продолжать работу даже в случае отказа двух дисков.

Дубль-блоки — это еще один механизм создания избыточности, выходящий за рамки возможностей традиционных ФС и менеджеров томов. Он позволяет создавать до трех копий особенно важных данных даже на одном диске. Пример таких данных — собственно метаданные файловой системы, для которых две (и даже три) копии делаются всегда. Этот механизм можно задействовать также и для пользовательских данных. Распределение данных в этом случае осуществляется определенным образом. Если пул состоит из нескольких накопителей, то копии будут распределяться по ним при наличии свободного места. Если диск всего один, то данные будут распределяться максимально далеко друг от друга. Очевидно, что такой механизм может быть полезен для ноутбуков.

Механизм восстановления избыточности в ZFS также интеллектуален благодаря интегрированности системы. При восстановлении избыточности (ресинхронизации) обычные системы считывают содержимое дисков целиком, даже если они едва заполнены, поскольку менеджер томов не знает, где есть данные, а где их нет. ZFS точно знает, где находятся данные, поэтому копирует только их, начиная с корня дерева и не тратя время на копирование мусора. Кстати, зеркала и RAID-Z в ZFS благодаря этому создаются практически мгновенно.

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

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

ZFS изнутри: масштабируемость и производительность

Теперь поговорим о масштабируемости и производительности ZFS. ZFS — первая в мире 128-битная ФС. Несмотря на кажущуюся огромность дискового пространства, которое позволяет адресовать 64-битная ФС, оказалось, что до момента реализации всех ее возможностей потребуется не слишком много времени. Уже сейчас есть заказчики, оперирующие петабайтными объемами данных (2 в степени 50). Для достижения предела потребуется всего лишь 14 удвоений, и, если существующие тенденции сохранятся, 65-й бит потребуется уже через 10–15 лет. Поэтому для ZFS было выбрано 128 бит. Достаточно ли этого? Наверное, да, во всяком случае, расчеты показывают, что предел размера ФС в ZFS превышает возможности накопителя, который теоретически можно создать на нашей планете, а энергии, которая потребуется только для того, чтобы установить в нужное состояние 2 в степени 128 бит, хватит, чтобы несколько раз вскипятить весь мировой океан.

Все метаданные в ZFS — полностью динамические. Нет никаких статических регионов, индексных дескрипторов (inode) и т. п., все подобные структуры выделяются динамически, так что фактический предел размера и количества файлов, каталогов, файловых систем, мгновенных снимков, клонов и т. д. определяется только объемом доступной дисковой памяти. Соответственно отсутствуют и разные непонятные ограничения, вроде количества inode в одной группе цилиндров.

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

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

Динамическое чередование помогает наиболее полно реализовать пропускную способность дисков. При статическом чередовании, предусмотренном в RAID-0, используется фиксированное число дисков. В ZFS можно добавить диски в пул, при этом все новые записываемые данные будут распределяться по всем имеющимся дискам, а старые данные, благодаря COW, тоже будут постепенно перераспределены по всем дискам.

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

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

ZFS глазами администратора.

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

Создадим пул с именем tank и поместим в него одно зеркало, состоящее из двух дисков с1t0d0 и c2t0d0:

zpool create tank mirror c1t0d0 c2t0d0

Это все. А поскольку пул сам по себе, кроме того, и файловая система, мы одной командой создали зазеркалированную файловую систему «/tank».

Пул, использующий RAID-Z, создается так же просто, например:

zpool create pool raidz c1t1d0 c2t1d0 c3t1d0 c4t1d0

Для получения пула, не использующего механизмов создания избыточности, достаточно просто опустить ключевое слово mirror или raidz в приведенных выше командах.

Добавить дополнительное пространство в пул очень просто:

zpool add tank mirror c3t0d0 c4t0d0

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

Уничтожить пул можно командой:

zpool destroy tank

Однако она уничтожает пул, даже если в нем есть используемые файловые системы.

Команда zpool также позволяет подготовить пул к перемещению на другую систему. Для этого используются подкоманды export и import. Отметим, что если пул создан на системе с архитектурой x86, то его можно экспортировать и импортировать на машины архитектуры SPARC, и наоборот. Это достигается благодаря автоматической адаптации к порядку байтов в слове.

Список возможностей по управлению пулами, предоставляемый командой zpool, на этом не исчерпывается. Полное описание можно найти в справочном руководстве по команде zpool, а также в «Руководстве администратора ZFS».

Для управления файловыми системами используется также одна команда — zfs. Но прежде чем перейти к примерам, нужно сказать несколько слов о том, как файловые системы в ZFS облегчают жизнь системного администратора.

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

Справиться с управлением большим количеством ФС помогает механизм наследования свойств. Например, можно создать ФС home в пуле tank, настроить для нее все свойства для ФС пользователей, используемые по умолчанию, а затем создавать в ней ФС для отдельных пользователей. Если пользователю понадобится изменить какой-то параметр, например увеличить квоту, это можно сделать, изменив соответствующее свойство его ФС. Если требуется изменить какие-то параметры для всех пользователей, достаточно изменить их для родительской ФС.

Все операции с ФС можно выполнять на ходу: не нужно останавливать работу, чтобы поменять какой-то параметр, сделать мгновенный снимок и т. д., все это происходит мгновенно.

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

Приведем несколько примеров. Создадим файловую систему home в пуле tank

zfs create tank/home

Установим для нее точку монтирования /export/home, затем создадим в ней файловые системы для пользователей ahrens, bonwick, billm, установим для пользователя bonwick резерв в 100 Гбайт, а для пользователя billm квоту в 50 Гбайт, включим сжатие для всего пула и выключим его для пользователя ahrens, а затем откроем доступ к файловым системам пользователей по NFS.

По умолчанию каждая созданная ФС монтируется в каталог, соответствующий ее имени, т. е. tank смонтируется в каталог /tank, tank/home — в каталог /tank/home

zfs set mountpoint=/export/home tank/home

Выполнив эту команду, ФС tank останется смонтированной в каталоге /tank, а ФС tank/home окажется смонтированной в каталоге /export/home. Если такового нет, он будет создан автоматически, поскольку было выражено наше намерение с помощью команды. Если такой каталог существует и не пуст, то команда сообщит об ошибке.

zfs create tank/home/ahrens
zfs create tank/home/bonwick
zfs create tank/home/billm

После выполнения этих трех команд мы получим три ФС для трех пользователей, и они автоматически, в силу наследования свойств, будут смонтированы в подкаталоги ahrens, bonwick, billm каталога /export/home.

zfs set reservation=100G tank/home/bonwick

После выполнения этой команды для пользователя bonwick будет зарезервировано 100 Гбайт дискового пространства.

zfs set quota=50G tank/home/billm

После выполнения этой команды пользователь billm не сможет использовать более 50 Гбайт пространства в своей файловой системе.

zfs set compression=on tank
zfs set compression=off tank/home/ahrens

Первой из двух предыдущих команд включается сжатие для всех данных в пуле — включаем его для корня иерархии, и в силу наследования это свойство применяется для всех вложенных в него ФС. Второй командой можем выключить сжатие для ФС одного из пользователей, если он, например, хранит в своей ФС плохо сжимаемые данные. Следующей командой можно предоставить доступ к файловой системе tank/home по сети только на чтение.

Еще один механизм, существенно облегчающий управление данными, — моментальные снимки (далее просто снимки) и клоны. Снимок — это состояние ФС, зафиксированное на определенный момент времени. Как уже отмечалось, снимки создаются мгновенно. Сразу после создания они практически не занимают места, а с течением времени, по мере изменения снятой ФС, в них накапливаются только измененные блоки. Для создания снимков не нужно резервировать специальное хранилище, необходимое для них место выделяется из общего пула. Если объем изменений в ФС невелик, то и объем данных снимка остается небольшим. Добавьте к этому практически неограниченное их количество, и получите очень мощный инструмент для управления данными, создания резервных копий и т. д. Существующие снимки файловой системы могут быть доступны всем желающим через специальный каталог с именем .zfs в корне соответствующей файловой системы.

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

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

Приведем несколько примеров.

Создать снимок файловой системы пользователя ahrens можно командой

zfs snapshot tank/home/[email protected]

Здесь tank/home/ahrens задает имя ФС, снимок которой мы хотим создать, символ @ служит для отделения имени ФС от имени снимка, а today — имя, под которым мы хотим сохранить создаваемый снимок.

Создать клон можно при помощи команды

zfs clone tank/home/[email protected] tank/home/copy

Здесь мы указываем сначала имя снимка, а затем имя, которое мы хотим присвоить клону.

Резервная копия может быть создана при помощи следующих команд:

zfs send tank/home/ahrens > /backup/ahrens.full
zfs send -i tank/home/[email protected] tank/home/[email protected]/backup/ahrens.incr

Первая команда создает полную резервную копию ФС пользователя ahrens, в то время как вторая — копию изменений состояния ФС между снимками yesterday (вчера) и today (сегодня). Отметим, что вывод команды zfs send можно перенаправить не только в файл, но и на другую машину, например при помощи ssh. Таким образом, можно организовать репликацию данных по сети на машину, находящуюся в другом здании, городе, стране…

Безопасность данных в ZFS обеспечивается с помощью списков контроля доступа в стиле NFSv4 или Windows NT. Они позволяют описывать самые нетривиальные наборы прав доступа. В сочетании с наследованием это превращается в исключительно гибкий и мощный механизм разграничения доступа к файлам.

Сегодня ведется активная работа по использованию ZFS в качестве корневой файловой системы. Начиная с Solaris Express Community Release b62, можно, воспользовавшись ручной процедурой, перенести ОС на ZFS и загружаться с нее. Это означает, что можно использовать инструменты управления данными для выполнения самых неприятных задач системного администрирования, таких, как установка патчей и обновление версии ОС. Больше не нужно переключаться в однопользовательский режим для выполнения этих операций — можно просто создать новый клон загрузочной среды и установить в него патчи или обновить версию ОС, не останавливая полезную работу ни на минуту. Все, что понадобится для активации изменений, — это загрузиться с модифицированного клона. Если вдруг что-то пойдет не так, можно будет вернуться к предыдущему состоянию, загрузившись с оригинальной ФС. Это очень похоже на технологию Live Upgrade, но без присущих ей недостатков: не требуется выделения отдельных дисков для копии загрузочной среды и полного копирования загрузочной среды. Конечно же, эти возможности ZFS будут со временем использованы и в Live Upgrade.

Заключение.

В завершение хотелось бы отметить, что создание ZFS явилось своего рода прорывом в технологии современных файловых систем. Возможности, которые ZFS несет пользователям, настолько широки, что для эффективного их использования нам нужно пересмотреть многие подходы к управлению данными, господствовавшие последние 10 лет. И это может быть весьма непростой задачей. Чтобы сделать ее проще, нужно совсем немного: начать пробовать ZFS и возможности, предоставляемые ею. Для этого не требуется рядом дисковый массив с кучей дисков, достаточно нескольких USB Flash-накопителей или нескольких гигабайтов свободного пространства на любой системе, где может быть установлена ZFS, даже в виртуальной машине, поскольку ZFS позволяет использовать для создания пула не только физические накопители, но и самые обычные файлы. Так что не стоит откладывать практическое знакомство с ZFS на завтра, начните делать это уже сегодня!



Дополнительные записи: