LXF165-166:ZFS в действии
Olkol (обсуждение | вклад) (→Подключение репозитория) |
Olkol (обсуждение | вклад) |
||
Строка 1: | Строка 1: | ||
[[Категория:Постоянные рубрики]] | [[Категория:Постоянные рубрики]] | ||
− | |||
'''ZFS в действии''' | '''ZFS в действии''' | ||
− | |||
− | |||
== ZFS on Linux: Как начать применять == | == ZFS on Linux: Как начать применять == | ||
Текущая версия на 13:11, 5 ноября 2018
|
|
|
ZFS в действии
Содержание |
[править] ZFS on Linux: Как начать применять
Алексей Федорчук продолжает рассказ о новой файловой системе – теперь в практическом аспекте.
Настоящая статья посвящена практическому использованию ZFS в Linux. Оно рассмотрено на примере openSUSE, хотя почти все из сказанного применимо и к любым другим дистрибутивам – все дистроспецифические детали оговорены явным образом.
[править] Обзор возможностей
Прежде чем погружаться в вопросы, связанные с ZFS, читатель, вероятно, хотел бы убедиться в том, что это стоит делать. То есть – ознакомиться с возможностями, которые будут ему предоставлены.
Для начала – немного цифр. В отличие от всех предшествовавших файловых систем и систем размещения данных, ZFS является 128-битной. То есть теоретическое ограничение на ее объем и объемы ее составляющих превышают не только реальные, но и воображаемые потребности любого пользователя. По выражению создателя ZFS, Джеффа Бонвика [Jeff Bonwick], для ее заполнения данными и их хранения потребовалось бы вскипятить океан.
Так, объем пула хранения данных (zpool – максимальная единица в системе ZFS) может достигать величины 3 × 1023 петабайт (а один петабайт, напомню, это 1015 или 250 байт, в зависимости от системы счисления). Каждый пул может содержать до 264 устройств (например, дисков), а всего пулов в одной системе может быть тоже не больше 264.
Пул может быть разделен на 264 наборов данных (dataset – в этом качестве выступают, например, отдельные файловые системы), по 264 каждая. Правда, ни одна из таких файловых систем не может содержать больше 248 файлов. Зато размер любого файла ограничивается опять же значением в 264 байт.
Количество таких ограничений можно умножить. Как уже было сказано, они лежат вне пределов человеческого воображения и возможностей. И привожу я их только для того, чтобы вселить в пользователя уверенность: ни он сам, ни его внуки и правнуки в реальности не столкнутся c ограничениями на размер файловой системы или отдельного файла, как это бывало при использовании FAT или ext2fs.
Так что перейду к особенностям ZFS, наиболее интересным, по моему мнению, десктопному пользователю. Здесь в первую очередь надо отметить гибкое управление устройствами. В пул хранения данных можно объединить произвольное (в обозначенных выше пределах) число дисков и их разделов. Устройства внутри пула могут работать в режиме расщепления данных, зеркалирования или избыточности с подсчетом контрольных сумм, подобно RAID’ам уровней 0, 1 и 5, соответственно. В пул можно включать накопители, специально предназначенные для кэширования дисковых операций, что актуально при совместном использовании SSD и традиционных винчестеров.
Пул хранения становится доступным для работы сразу после его создания, без рестарта машины. В процессе работы дополнительные диски или разделы, в том числе и устройства кэширования, могут как присоединяться к пулу, так и изыматься из его состава в «горячем» режиме.
Пул хранения может быть разделен на произвольное количество иерархически организованных файловых систем. По умолчанию размер их не определяется, и растет по мере заполнения данными. Это избавляет пользователя от необходимости расчета места, потребного под системные журналы, домашние каталоги пользователей и другие трудно прогнозируемые вещи. С другой стороны, не запрещено при необходимости и квотирование объема отдельных файловых систем – например, домашних каталогов отдельных излишне жадных пользователей.
Файловые системы ZFS также доступны для размещения на них данных сразу после создания, никаких специальных действий по обеспечению их монтирования не требуется. Создание файловых систем внутри пула – процесс предельно простой: разработчики стремились сделать его не сложнее создания каталогов, и это им вполне удалось. Но при этом составляющие пула остаются именно самостоятельными файловыми системами, которые могут монтироваться со своими специфическими опциями, в зависимости от назначения.
Среди других возможностей ZFS, интересных настольному пользователю, можно упомянуть:
» создание снапшотов файловой системы, позволяющих восстановить ее состояние в случае ошибки;
» клонирование файловых систем;
» компрессия данных файловой системы и дедупликация (замена повторяющихся данных ссылками на «первоисточник»);
» создание нескольких копий блоков с критически важными данными и, напротив, возможность отключения проверки контрольных сумм для повышения скорости доступа к ним.
В общем, даже если не говорить о быстродействии ZFS (а оно весьма высоко, особенно в многодисковых конфигурациях), перечислять ее достоинства можно очень долго. Так долго, что поневоле успеваешь задаться вопросом: а есть ли у нее недостатки?
Разумеется, есть. Хотя большая их часть – скорее особенности: например, ограничения при добавлении или удалении накопителей в пуле, или отсутствие поддежки TRIM.
По большому счету, для пользователя Linux’а у ZFS обнаруживается два кардинальных недостатка: некоторая усложненность ее использования, обусловленная юридическими факторами, и высокие требования к аппаратуре.
Первый недостаток если не ликвидирован, то сглажен трудами Брайана Белендорфа [Brian Behlendorf] со товарищи и майнтайнерами прогрессивных дистрибутивов вкупе с примкнувшими к ним независимыми разработчиками. Аппаратные же претензии ZFS мы сейчас и рассмотрим.
[править] Аппаратные потребности
Итак, ZFS предоставляет пользователю весьма много возможностей. И потому вправе предъявлять немало претензий к аппаратной части – процессору (изобилие возможностей ZFS создает на него достаточную нагрузку), оперативной памяти и дисковой подсистеме.
Впрочем, претензии эти отнюдь не сверхъестественные. Так, процессор подойдет любой из относительно современных, начиная, скажем, с Core 2 Duo. Минимальный объем памяти определяется в 2 ГБ, с оговоркой, что применение компрессии и дедупликации требуют 8 ГБ и более.
Сама по себе ZFS прекрасно функционирует и на одиночном диске. Однако в полном блеске предстает при двух и более накопителях. В многодисковых конфигурациях рекомендуется разнесение накопителей на разные контроллеры: современные SSD способны полностью загрузить все каналы SATA-III, и равномерное распределение нагрузки на пару контроллеров может увеличить быстродействие.
К «железным» претензиям добавляются и притязания программные. В первую очередь, ZFS on Linux потребует 64-битной сборки этой ОС, поскольку в 32-разрядных системах действует ограничение на адресное пространство физической памяти. Кроме того, в конфигурации ядра должнв быть отключена опция CONFIG_PREEMPT. Поэтому, например, в openSUSE ZFS может использоваться с ядром kernel-default, но не kernel-desktop, каковое, вопреки названию, устанавливается по умолчанию при стандартной настольной инсталляции.
Если вас привлекли достоинства ZFS и не устрашили ее «железные» аппетиты, самое время опробовать ее в деле. Что потребует знакомства с некоторыми специфическими понятиями.
[править] Терминология
» Пул хранения данных [zpool] – центральное понятие ZFS. В него может объединяться несколько физических устройств хранения – дисков или дисковых разделов, причем первый вариант рекомендуется. Но не запрещено и создание пула из одного диска или его раздела. В каждый пул входят
> Виртуальные устройства [vdev], одно или несколько. В качестве таковых могут выступать устройства без избыточности (то есть все те же диски и/или их разделы) или устройства с избыточностью – зеркала и массивы типа RAID-Z.
> Зеркальное устройство [mirror] – виртуальное устройство, хранящее на двух или более физических устройствах, но при четном их количестве, идентичные копии данных на случай отказа диска.
> RAID-Z – виртуальное устройство на нескольких устройств физических, предназначенное для хранения данных и их контрольных сумм с однократным или двойным контролем четности. В первом случае теоретически требуется не менее двух, во втором – не менее трех физических устройств.
Если пул образован устройствами без избыточности (просто дисками или разделами), то одно из vdev, соответствующее ему целиком, выступает как
> Корневое устройство. Пул из устройств с избыточностью может содержать более одного корневого устройства – например, два зеркала.
Пулы, образованные виртуальными устройствами, служат вместилищем для наборов данных [dataset]. Они бывают следующих видов:
» файловая система [filesystem] – набор данных, смонтированный в определенной точке и ведущий себя подобно любой другой файловой системе;
» снапшот [snapshot] – моментальный снимок текущего состояния файловой системы, доступный только для чтения;
» клон [clone] – точная копия файловой системы в момент его создания; создается на основе снимка, но, в отличие от того, доступен для записи;
» том [volume] – набор данных, эмулирующий физическое устройство, например, раздел подкачки.
Наборы данных пула должны носить уникальные имена такого вида:
pool_name/path/[dataset_name][@snapshot_name]
Пулы и наборы данных в именуются по правилам пространства имен ZFS, впрочем, довольно простым. Запрещенными символами для всех являются символы подчеркивания, дефиса, двоеточия, точки и процента. Имя пула при этом обязательно должно начинаться с алфавитного символа и не совпадать с одним из зарезервированных имен – log, mirror, raidz или spare (последнее обозначает имя устройства «горячего» резерва). Все остальные имена, в соответствие с демократическими традициями пространства имен ZFS, разрешены.
А вот об именах физических устройств, включаемых в пул, следует сказать особо.
[править] Модели именования устройств
В современном Linux’е использование для накопителей имен «верхнего уровня», имеющих вид /dev/sda, не является обязательным, а в некоторых случаях и просто нежелательно. Однако правила менеджера устройств udev позволяют определять и другие модели идентификации накопителей.
В частности, штатными средствами дисковой разметки дистрибутива openSUSE предусмотрены варианты идентификации накопителей по:
» метке тома (/dev/disk/by-label);
» идентификатору диска (/dev/disk/by-id);
» пути к дисковому устройству (/dev/disk/by-path);
» универсальному уникальному идентификатору, Universally Unique IDentifier (/dev/disk/by-uuid).
С полным списком вариантов идентификации блочных устройств можно ознакомиться, просмотрев имена подкаталогов в каталоге /dev/disk; их содержимое – это символические ссылки на имена «верхнего уровня».
С идентификацией по метке тома и по UUID, вероятно, знакомо большинство читателей. И к тому же в пространстве имен ZFS они не используются. А вот с идентификацией by-path и by-id нужно познакомиться поближе.
Модель именования by-path использует имена устройств, привязанные к их положению на шине PCI и включающие номер шины и канала на ней. Имя дискового устройства выглядит приблизительно так:
pci-0000:00:1f.2-scsi-0:0:0:0
Дисковые разделы маркируются добавлением к имени устройства суффикса part#.
Модель именования by-path идентифицирует устройства вполне однозначно, и особенно эффективна при наличии более чем одного дискового контроллера. Однако сами имена и устройств, и разделов описываются довольно сложной для восприятия последовательностью. Да и в большинстве «десктопных» ситуаций модель эта избыточна.
Модель идентификации by-id представляет имена носителей информации в форме, наиболее доступной для человеческого понимания. Они образованы из названия интерфейса, имени производителя, номера модели, серийного номера устройства и, при необходимости, номера раздела, например:
ata-SanDisk_SDSSDX120GG25_120823400863-part1
Таким образом, все компоненты имени устройства в модели by-id определяются не условиями его подключения или какими-то правилами, а задаются производителем и жестко прошиты в «железе». И потому эта модель является наиболее однозначной для именования устройств. А также, что немаловажно, строится по понятной человеку логике. Не случайно именно она принята по умолчанию в инсталляторе openSUSE.
Какую из моделей именования устройств выбрать для данного пула – зависит от его назначения и масштабов. Имена «верхнего уровня» целесообразно применять для однодисковых пулов (особенно если в машине второго диска нет и не предвидится, как обычно бывает в ноутбуках). Они же, по причине удобопонятности и простоты, рекомендуются для экспериментальных и разрабатываемых пулов. И очень не рекомендуются – во всех остальных случаях, так как зависят от условий подключения накопителей.
Этого недостатка лишена модель by-id: как пишет Брайан, при ее использовании «диски можно отключить, случайно смешать и подключить опять произвольным образом – и пул будет по-прежнему корректно работать». Как ее недостаток рассматривается сложность конфигурирования больших пулов с избыточностью. И потому она рекомендуется для применения в «десктопных» и «квартирных» (типа семейного сервера) условиях.
Для больших (более 10 устройств) пулов из дисков, подключенных к нескольким контроллерам, рекомендуется идентификация by-path. Однако в наших целях она громоздка и избыточна.
Наконец, ZFS on Linux предлагает и собственную модель идентификации – /dev/disk/zpool, в котором именам by-path ставятся в соответствие уникальные и осмысленные «человекочитаемые» имена, даваемые пользователем. Модель эта рекомендуется для очень больших пулов, каковых на настольной машине ожидать трудно.
Так что дальше я буду использовать имена «верхнего уровня», говоря об абстрактных или экспериментальных ситуациях, и об именах by-id, когда речь зайдет о практических примерах применения ZFS.
[править] Включение поддержки ZFS
Для практического использования ZFS on Linux перво-наперво необходимо обеспечить ее поддержку в вашем дистрибутиве – ибо по причинам, описанным в предыдущей статье, сама собой она не поддержится ни в одном Linux’е.
Как это сделать, зависит от дистрибутива. В Сети можно найти подробные инструкции для Ubuntu и Gentoo, которые легко распространяются на клоны обеих систем. Не столько инструкции, сколько руководства к самостоятельному действию имеются на сайте проекта ZFS on Linux для абстрактных RPM- и Deb-based дистрибутивов. Я же расскажу о том, как это делается в openSUSE релизов 12.1 и 12.2.
Как вы наверняка догадались, ZFS не поддерживается в openSUSE ни «искаропки», ни в официальных репозиториях. Но зато в репозиториях неофициальных, так называемых «домашних», пакеты ее поддержки представлены аж в двух экземплярах: в munix9 и в ghaskins. Точные их адреса легко найти через систему OBS (Open Builging System) по ключевому слову zfs.
Какому из репозиториев отдать предпочтение – вопрос спорный. Первые свои опыты с ZFS on Linux я проводил, основываясь на пакетах из munix9. И они прошли без всяких осложнений, хотя и велись в сугубо экспериментальном режиме. К моменту понимания, что эта система для меня – «всерьез и надолго», последняя тогда версия zfs имелась только в репозитории ghaskins. Однако его использование требует некоторых дополнительных манипуляций.
Кроме того, в репозитории ghaskins на данный момент имеются пакеты только для openSUSE релизов 12.1 и 12.2. Репозиторий же munix9 охватывает все актуальные ныне версии SLE и openSUSE. включая Tumbleweed и Factory.
Различаются репозитории и набором пакетов (рис. 1 и 2). Так что окончательный выбор я предоставляю читателю. Но на какой бы репозиторий он ни пал, его следует подключить. Тех, кто с этим затрудняется, отсылаю ко врезке.
[править] Подключение репозитория
Сделать это можно любым из трех способов. Первый – через командную строку, с помощью zypper’а:
# zypper ar -f [URL] [Name]
Второй – через центр управления YaST2 (см врезку «Шаг за шагом» на предыдущей странице).
После подключения репозитория надо будет установить (с помощью zypper’а или модуля управления пакетами YaST’а) дополнительные компоненты (рис. 3).
Наконец, третий способ, для самых ленивых – отыскать пакеты zfs, spl и сопутствующие через OBS и прибегнуть к «установке в один клик». В этом случае подключение репозиториев будет совмещено с установкой пакетов.
- Метамодернизм в позднем творчестве В.Г. Сорокина
- ЛитРПГ - последняя отрыжка постмодерна
- "Ричард III и семиотика"
- 3D-визуализация обложки Ridero создаем обложку книги при работе над самиздатом.
- Архитектура метамодерна - говоря о современном искусстве, невозможно не поговорить об архитектуре. В данной статье будет отмечено несколько интересных принципов, характерных для построек "новой волны", столь притягательных и скандальных.
- Литература
- Метамодерн
- Рокер-Прометей против изначального зла в «Песне про советскую милицию» Вени Дркина, Автор: Нина Ищенко, к.ф.н, член Союза Писателей ЛНР - перепубликация из журнала "Топос".
- Как избавиться от комаров? Лучшие типы ловушек.
- Что делать если роблокс вылетает на windows
- Что делать, если ребенок смотрит порно?
- Почему собака прыгает на людей при встрече?
- Какое масло лить в Задний дифференциал (мост) Visco diff 38434AA050
- О чем может рассказать хвост вашей кошки?
- Верветки
- Отчетность бюджетных учреждений при закупках по Закону № 223-ФЗ
- Срок исковой давности как правильно рассчитать
- Дмитрий Патрушев минсельхоз будет ли преемником Путина
- Кто такой Владислав Поздняков? Что такое "Мужское Государство" и почему его признали экстремистским в России?
- Как правильно выбрать машинное масло в Димитровграде?
- Как стать богатым и знаменитым в России?
- Почему фильм "Пипец" (Kick-Ass) стал популярен по всему миру?
- Как стать мудрецом?
- Как правильно установить FreeBSD
- Как стать таким как Путин?
- Где лучше жить - в Димитровграде или в Ульяновске?
- Почему город Димитровград так называется?
- Что такое метамодерн?
- ВАЖНО! Временное ограничение движения автотранспортных средств в Димитровграде
- Тарифы на электроэнергию для майнеров предложено повысить
Возможно, не вредным окажется и пакет zfs-test. А вот zfs-dracut, предназначенный для создания initrd с поддержкой ZFS, несмотря на его потенциальную нужность, установить не удастся: требуемый для него пакет dracut в openSUSE пока не поддерживается.
Следует учесть, что при использовании ядра kernel-desktop (а скорее всего, так оно и есть) пакет zfs-kmp-default потянет за собой и соответствующее ядро kernel-default. Пункт загрузки которого будет внесен в меню Grub, но не будет отмечен как умолчальный – этим надо озаботиться самому.
И, наконец, при использовании пакетов из ghaskins потребуется, скорее всего, сделать в каталогах /etc/init.d/rc3.d и /etc/init.d/rc5.d символические ссылки на файл /etc/init.d/zfs. Иначе файловые системы ZFS, к созданию которых мы приближаемся, не будут автоматически монтироваться при старте и размонтироваться при останове системы.
При использовании репозитория munix9 эти действия будут выполнены в ходе установки пакетов нечувствительно для пользователя.
Вот теперь можно приступать к применению ZFS в мирных практических целях. Что мы с вами и предпримем – но уже в следующем номере. |