Используйте преимущества файловой системы ZFS в Solaris::Журнал СА 3.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5101
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6343
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7599
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7922
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6978
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Используйте преимущества файловой системы ZFS в Solaris

Архив номеров / 2007 / Выпуск №3 (52) / Используйте преимущества файловой системы ZFS в Solaris

Рубрика: Администрирование /  Администрирование

Алексей Коробкин

Используйте преимущества файловой системы ZFS в Solaris

В летнем релизе 6/06 ОС Solaris версии 10 появилась поддержка новой файловой системы ZFS. Это интересное нововведение, и оно не менее значительно, нежели зоны или система самодиагностики DTrace. Почему понадобилось изобретать новую файловую систему вместо привычной ufs и чем она интересна?

Управление дисками

Когда администратор сервера подключает новое хранилище, он действует примерно так: при помощи встроенного в хранилище менеджера дисков формирует один или несколько аппаратных RAID-массивов, полученные дисковые тома разбивает на разделы fdisk, а разделы затем размечает под файловые системы с помощью newfs, mkfs и прочих. Если администратор, следуя современным тенденциям [2], решил построить программный, а не аппаратный RAID-массив, то он должен воспользоваться ещё и менеджером дисков операционной системы. Иными словами, процесс не выглядит слишком простым: нужно совершить три действия, требующие повышенного внимания и тщательного планирования, запустив для этого три программы, качество одной из них зачастую зависит только от поставщика хранилища.

Инженеры Sun попытались упростить эту работу. Созданная ими ZFS объединяет в себе все три слоя управления хранилищами. Новизна подхода в том, что верхний слой – файловая система – знает, на каком массиве она работает. В чем здесь преимущество? Например, зная размер файлов, которые она туда пишет, ZFS может создавать полоски (stripes) переменной длины на массивах RAID-0 и RAID-5, обеспечивая таким образом высокую скорость работы и повышенную отказоустойчивость. ZFS высчитывает контрольные суммы для файлов, а не блоков данных, избавляясь от возможной ошибки обычных RAID-массивов, когда блок с правильной суммой бывает записан не туда, куда надо.

Кроме того, ZFS – транзакционная, а не журналируемая файловая система. Она использует методику копирования при записи (copy on write), и в случае, например, сбоя питания транзакция либо завершается, либо игнорируется. При этом файловая система всегда остается в исправном состоянии.

Подключенные к серверу новые диски ZFS может начать использовать сразу же. По аналогии с оперативной памятью, если мы добавили в сервер память, нет необходимости что-то делать – операционная система автоматически её распознает и задействует. Ограничений объёма практически нет: ZFS – 128-битная файловая система, и её полное название звучит как Zettabyte File System. Она может хранить 128 квадриллионов зетабайт данных.

Предполагается, что мы всегда объединяем все доступные серверу хранилища и диски в единый массив ZFS, а внутри него строим столько файловых систем, сколько нужно. Такой массив носит название пул (pool). Конфигурация пула может быть самой разнообразной, варианты вы сейчас посмотрите на примерах.

Пул файловых систем ZFS можно создать либо на пустых дисках, либо на слайсах (slice) ufs, либо на отдельных файлах большого размера. Естественно, в последнем случае надежность и скорость будут зависеть от свойств основной файловой системы. Сначала попробуем на одном диске:

# zpool create zoopark c1t1d0

Пул zoopark займёт весь диск c1t1d0 целиком, а команда zpool автоматически создаст внутри него готовую новую файловую систему и примонтирует её к /zoopark. Вот статус системы:

# zpool status zoopark

  pool: zoopark

 state: ONLINE

 scrub: none requested

 config:

 

        NAME        STATE     READ WRITE CKSUM

        zoopark     ONLINE       0     0     0

          c1t1d0    ONLINE       0     0     0

Один диск – это не очень интересно. Построим новый пул zerkalo3 на основе тройного зеркала, то есть RAID-1 на трех дисках:

# zpool create zerkalo3 mirror c1t1d0 c1t2d0 c1t3d0

# zpool status

  pool: zerkalo3

 state: ONLINE

 scrub: none requested

config:

 

        NAME        STATE     READ WRITE CKSUM

        zerkalo3    ONLINE       0     0     0

          mirror    ONLINE       0     0     0

            c1t1d0  ONLINE       0     0     0

            c1t2d0  ONLINE       0     0     0

            c1t3d0  ONLINE       0     0     0

В больших хранилищах редко встретишь зеркала: алгоритм контроля четности и избыточности данных RAID-5 более популярен. В реализации ZFS ему соответствуют сразу два алгоритма, RAIDZ и RAIDZ2. Первый, RAIDZ, рекомендуется для получения максимального объема массива. Второй, RAIDZ2, использует алгоритм двойной четности и потому существенно более отказоустойчив. Если при создании массива конкретный алгоритм не указан, массивы собираются в RAID-0. Всего ZFS поддерживает четыре конфигурации RAID: RAID-0, RAID-1, RAIDZ и RAIDZ2.

Отличие RAIDZ и RAIDZ2 от алгоритмов RAID-4, RAID-5 и подобных состоит в исправлении некоторых фундаментальных ошибок этих алгоритмов. В частности, согласно [1], так называемый сбой при записи RAID-5 может появиться, когда питание массива было прервано в момент записи полоски данных. Тогда подсчитанная четность массива и реальная четность данных оказываются рассинхронизированы, и восстановление данных по чётности приводит к их порче. В ZFS эта ошибка устранена благодаря тому, что файловая система и менеджер дисков объединены в одно целое. Полоса переменного размера записывается в один проход, и сбой при записи не нарушает чётности всего остального массива. Транзакционность файловой системы помогает обеспечить постоянную целостность данных, а связь файловой системы с информацией о массиве даёт возможность правильно рассчитывать длину полосок.

Построим RAIDZ на нескольких дисках:

# zpool create veer raidz c1t1d0 c1t2d0 c1t3d0 c1t4d0

# zpool status veer

  pool: veer

 state: ONLINE

 scrub: none requested

config:

 

        NAME        STATE     READ WRITE CKSUM

        veer        ONLINE       0     0     0

          raidz1    ONLINE       0     0     0

            c1t1d0  ONLINE       0     0     0

            c1t2d0  ONLINE       0     0     0

            c1t3d0  ONLINE       0     0     0

            c1t4d0  ONLINE       0     0     0

Если у вас много дисков, Sun рекомендует разбивать их на группы от трех до девяти для повышения производительности.

Обратите внимание на повторяющееся ключевое слово raidz2 в списке:

# zpool create kombi raidz2 c1t1d0 c1t2d0 c1t3d0 c1t4d0 raidz2 c1t5d0 c1t6d0 c1t8d0 c1t9d0

# zpool status

  pool: kombi

 state: ONLINE

 scrub: none requested

config:

 

        NAME        STATE     READ WRITE CKSUM

        kombi       ONLINE       0     0     0

          raidz2    ONLINE       0     0     0

            c1t1d0  ONLINE       0     0     0

            c1t2d0  ONLINE       0     0     0

            c1t3d0  ONLINE       0     0     0

            c1t4d0  ONLINE       0     0     0

          raidz2    ONLINE       0     0     0

            c1t5d0  ONLINE       0     0     0

            c1t6d0  ONLINE       0     0     0

            c1t8d0  ONLINE       0     0     0

            c1t9d0  ONLINE       0     0     0

Таким образом, у нас два массива RAIDZ2 объединены в пул. Обратите внимание: данные в таких конфигурациях динамически распределяются по всем массивам пула, не подчиняясь каким-либо строгим алгоритмам. Это значит, что, например, создать зеркало из двух RAIDZ нельзя. Зато можно добавлять в существующий пул любое количество новых дисков, и Solaris будет постепенно раскладывать данные по всем массивам. Добавим еще один набор дисков в пул kombi:

# zpool add kombi raidz2 c1t10d0 c1t11d0 c1t12d0 c1t15d0

# zpool status

  pool: kombi

 state: ONLINE

 scrub: none requested

config:

 

        NAME         STATE     READ WRITE CKSUM

        kombi        ONLINE       0     0     0

          raidz2     ONLINE       0     0     0

            c1t1d0   ONLINE       0     0     0

            c1t2d0   ONLINE       0     0     0

            c1t3d0   ONLINE       0     0     0

            c1t4d0   ONLINE       0     0     0

          raidz2     ONLINE       0     0     0

            c1t5d0   ONLINE       0     0     0

            c1t6d0   ONLINE       0     0     0

            c1t8d0   ONLINE       0     0     0

            c1t9d0   ONLINE       0     0     0

          raidz2     ONLINE       0     0     0

            c1t10d0  ONLINE       0     0     0

            c1t11d0  ONLINE       0     0     0

            c1t12d0  ONLINE       0     0     0

            c1t15d0  ONLINE       0     0     0

Как видите, гибкость и простота настройки массивов невероятные, при том что ошибиться практически невозможно. Впрочем, перед выполнением команды можно заранее посмотреть, что именно будет выполнено (ключ -n):

# zpool create -n lusterko mirror c1t1d0 c1t2d0 mirror c1t3d0 c1t4d0 mirror c1t5d0 c1t6d0 mirror c1t8d0 c1t9d0 spare c1t10d0 c1t11d0

would create 'lusterko' with the following layout:

 

        lusterko

          mirror

            c1t1d0

            c1t2d0

          mirror

            c1t3d0

            c1t4d0

          mirror

            c1t5d0

            c1t6d0

          mirror

            c1t8d0

            c1t9d0

А затем и создать массив:

# zpool create lusterko mirror c1t1d0 c1t2d0 mirror c1t3d0 c1t4d0 mirror c1t5d0 c1t6d0 mirror c1t8d0 c1t9d0 spare c1t10d0 c1t11d0

# zpool status

  pool: lusterko

 state: ONLINE

 scrub: none requested

config:

 

        NAME        STATE     READ WRITE CKSUM

        lusterko    ONLINE       0     0     0

          mirror    ONLINE       0     0     0

            c1t1d0  ONLINE       0     0     0

            c1t2d0  ONLINE       0     0     0

          mirror    ONLINE       0     0     0

            c1t3d0  ONLINE       0     0     0

            c1t4d0  ONLINE       0     0     0

          mirror    ONLINE       0     0     0

            c1t5d0  ONLINE       0     0     0

            c1t6d0  ONLINE       0     0     0

          mirror    ONLINE       0     0     0

            c1t8d0  ONLINE       0     0     0

            c1t9d0  ONLINE       0     0     0

        spares

          c1t10d0   AVAIL

          c1t11d0   AVAIL

Веб-интерфейс

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

# /usr/sbin/smcwebconsole start

Адрес интерфейса https://имя_сервера:6789/zfs. По умолчанию использовать этот интерфейс может только супер-пользователь, root. Чтобы делегировать полномочия другому пользователю, нужно воспользоваться системой ролевого управления доступом – RBAC (Role-Based Access Control). Подробней про роли и профили безопасности в Solaris можно почитать в официальном руководстве [4].

Веб-интерфейс управления файловой системой ZFS

Веб-интерфейс управления файловой системой ZFS

Управление массивами определено ролями ZFS Storage Management и ZFS File System Management. Можно, например, создать специального пользователя zfsadmin и дать ему эти роли.

# useradd -P 'ZFS Storage Management', 'ZFS File System Management' zfsadmin

Теперь пользователь zfsadmin может управлять файловыми системами и пулами ZFS как из веб-интерфейса, так и из командной строки. А вот добавлять диски и удалять их из пула у него не получится: на это требуется весь спектр привилегий супер-пользователя.

Обработка ошибок

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

Перейдём к ошибкам. Что делать, если массив был ненароком уничтожен? Если после уничтожения никакие другие массивы не создавались, то диски находятся в прежнем состоянии и массив можно воскресить.

Сначала смотрим список уничтоженных или отключенных массивов:

# zpool import -D

  pool: rombik

    id: 90651616518883316

 state: ONLINE (DESTROYED)

action: The pool can be imported using its name

        or numeric identifier.

        The pool was destroyed, but can be imported

        using the '-Df' flags.

config:

 

        rombik      ONLINE

          raidz2    ONLINE

            c1t1d0  ONLINE

            c1t2d0  ONLINE

            c1t3d0  ONLINE

            c1t4d0  ONLINE

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

# zpool import -D -f rombik

# zpool status

  pool: rombik

 state: ONLINE

 scrub: none requested

config:

 

        NAME        STATE     READ WRITE CKSUM

        rombik      ONLINE       0     0     0

          raidz2    ONLINE       0     0     0

            c1t1d0  ONLINE       0     0     0

            c1t2d0  ONLINE       0     0     0

            c1t3d0  ONLINE       0     0     0

            c1t4d0  ONLINE       0     0     0

Что происходит, когда выходит из строя диск?

# zpool status

  pool: rombik

 state: DEGRADED

status: One or more devices could not be opened.

        Sufficient replicas exist for the pool

        to continue functioning in a degraded state.

action: Attach the missing device and

        online it using 'zpool online'.

   see: http://www.sun.com/msg/ZFS-8000-D3

 scrub: none requested

config:

 

        NAME        STATE     READ WRITE CKSUM

        rombik      DEGRADED     0     0     0

          raidz2    DEGRADED     0     0     0

            c1t1d0  ONLINE       0     0     0

            c1t2d0  UNAVAIL      0     0     0 cannot open

            c1t3d0  ONLINE       0     0     0

            c1t4d0  ONLINE       0     0     0

 

errors: No known data errors

Мы видим, что пул rombik отмечен как degraded, напротив соответствующего диска указана причина ошибки, а в свойствах пула появилось подробное описание проблемы и даже ссылка на более актуальную документацию онлайн. Сообщение «No known data errors» означает, что нет ошибок, непосредственно связанных с порчей данных, поскольку доступных дисков достаточно для восстановления утерянной информации. Столбцы READ, WRITE и CHECKSUM указывают количество ошибок при чтении, записи и подсчёте контрольных сумм. При обнаружении таких ошибок ZFS проверяет целостность затронутого файла и исправляет файл целиком, а не только испорченный блок данных.

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

Файловая система

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

Пул хранит в себе неограниченное количество файловых систем, отличающихся друг от друга только указанными администратором свойствами: именем, объёмом, точкой монтирования, сжатием, наследованием привилегий, родительской файловой системой и прочими. Файловая система внутри пула никак не привязана к физическому или логическому устройству – только к самому пулу. Администратор не должен думать о том, как именно располагаются его данные на физических дисках. Ему достаточно создать пул устройств, как мы это делали выше, построить внутри него нужное количество файловых систем и работать непосредственно с ними.

Исследуем работу файловых систем внутри пула на примерах:

# zpool create zoo raidz c1t1d0 c1t2d0 c1t3d0 c1t4d0

# zfs list zoo

NAME       USED  AVAIL  REFER  MOUNTPOINT

zoo        124K  23.4G  36.7K  /zoo

При создании пула в нём сразу же создается файловая система zoo и подключается к каталогу /zoo. Обратите внимание, что в /etc/vfstab ничего писать не надо – файловые объекты ZFS по умолчанию монтируются автоматически. Как при создании пула, так и при создании файловой системы, и при загрузке Solaris, управляет этим процессом бинарный файл /etc/zfs/zpool.cache.

Создадим файловые системы animals и fish внутри zoo:

# zfs create zoo/animals

# zfs create zoo/fish

Что получилось?

# zfs list

NAME              USED  AVAIL  REFER  MOUNTPOINT

zoo               214K  23.4G  39.6K  /zoo

zoo/animals      36.7K  23.4G  36.7K  /zoo/animals

zoo/fish         36.7K  23.4G  36.7K  /zoo/fish

То, что мы сейчас сделали, очень сильно отличается от обычной работы с файловыми системами. Мы ничего не форматировали, мы не указывали размер, физический диск или точку монтирования. Мы просто создали в пуле zoo две дополнительные файловые системы, и моментально можем начинать работать с ними. Все необходимые параметры мы можем задать потом или пронаследовать из вышестоящей файловой системы. Например, изменим параметр compression (сжатие) файловой системы zoo/fish.

# zfs set compression=on zoo/fish

# zfs get compression zoo/fish

NAME        PROPERTY       VALUE   SOURCE

zoo/fish    compression    on      local

Поле Source указывает, откуда взято значение параметра. До изменения в этом поле стояло ключевое слово default, «по умолчанию». Теперь там local – параметр указан непосредственно для данной файловой системы. Если мы создадим внутри zoo/fish файловую систему shark, то параметр compression пронаследуется от fish:

# zfs create zoo/fish/shark

# zfs get compression zoo/fish/shark

NAME            PROPERTY     VALUE  SOURCE

zoo/fish/shark  compression  on     inherited from zoo/fish

Чтобы указать размер файловой системы, мы используем свойство quota:

# zfs get quota zoo/fish

NAME         PROPERTY       VALUE   SOURCE

zoo/fish     quota          none    default

Уменьшим доступное zoo/fish пространство до пяти гигабайт:

# zfs set quota=5gb zoo/fish

Список файловых систем теперь выглядит так (ключ -r перебирает все вложенные файловые системы):

# zfs list -r zoo

NAME             USED  AVAIL  REFER  MOUNTPOINT

zoo              261K  23.4G  39.6K  /zoo

zoo/animals     36.7K  23.4G  36.7K  /zoo/animals

zoo/fish        74.8K  5.00G  38.2K  /zoo/fish

zoo/fish/shark  36.7K  5.00G  36.7K  /zoo/fish/shark

Как видите, вместе с размером файловой системы fish сократился и размер системы fish/shark. Понятно, что если бы мы таким образом создавали домашние каталоги пользователей, мы могли бы просто и легко на лету менять доступное им свободное пространство, включать компрессию данных и многое другое.

Посмотрим, какие еще есть свойства у файловых систем ZFS:

# zfs get all zoo/fish

NAME      PROPERTY       VALUE             SOURCE

zoo/fish  type           filesystem        -

zoo/fish  creation       Tue Jan 23 18:50  -

zoo/fish  used           54.4M             -

zoo/fish  available      4.95G             -

zoo/fish  referenced     25.5K             -

zoo/fish  compressratio  1.00x             -

zoo/fish  mounted        yes               -

zoo/fish  quota          5G                local

zoo/fish  reservation    none              default

zoo/fish  recordsize     128K              default

zoo/fish  mountpoint     /zoo/fish         default

zoo/fish  sharenfs       off               default

zoo/fish  checksum       on                default

zoo/fish  compression    on                local

zoo/fish  atime          on                default

zoo/fish  devices        on                default

zoo/fish  exec           on                default

zoo/fish  setuid         on                default

zoo/fish  readonly       off               default

zoo/fish  zoned          off               default

zoo/fish  snapdir        hidden            default

zoo/fish  aclmode        groupmask         default

zoo/fish  aclinherit     secure            default

Параметры, у которых поле Source пустое – только для чтения. К ним можно обращаться, чтобы узнать текущее состояние системы. Например, занятое место на файловой системе:

# zfs get -H used zoo/fish

zoo/fish  used    54.4M   -

Ключ -H убирает заголовок результата, чтобы можно было легко передать данные скрипту. Поля used, available, и quote относятся к размеру самой файловой системы, а referenced – к размеру данных, занятых служебной информацией. Интересное поле reservation дает возможность зарезервировать свободное пространство для файловой системы, чтобы никакие другие файловые системы на него не претендовали и считали занятым. Свойство mountpoint указывает, к какой папке подключена файловая система. Мы не обязаны сохранять иерархию, предлагаемую по умолчанию, и можем монтировать файловые системы куда угодно. Например, перенесём zoo/fish в /mnt:

# zfs set mountpoint=/mnt/fish zoo/fish

# zfs list -r zoo

NAME               USED  AVAIL  REFER  MOUNTPOINT

zoo                174K  7.81G  25.5K  /zoo

zoo/animals       24.5K  7.81G  24.5K  /zoo/animals

zoo/fish            50K  5.00G  25.5K  /mnt/fish

zoo/fish/shark    24.5K  5.00G  24.5K  /mnt/fish/shark

Как видите, вложенные файловые системы унаследовали точку монтирования. А если mountpoint указать как none, файловая система никуда подключена не будет.

ZFS и зоны

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

# zfs set mountpoint=legacy zoo/fish

# zonecfg -z aquarium

zonecfg:aquarium> add fs

zonecfg:aquarium:fs> set type=zfs

zonecfg:aquarium:fs> set special=zoo/fish

zonecfg:aquarium:fs> set dir=/export/home/fish

zonecfg:aquarium:fs> end

Вы можете столкнуться с ошибкой установки, если подключите файловую систему на этапе создания зоны (Bug 6449301, пока не исправлен), поэтому подключение следует делать уже после того как зона установлена.

В указанной конфигурации администратор зоны не может управлять файловой системой zoo/fish. Полный контроль над файловой системой делегируется иначе:

# zonecfg -z aquarium

zonecfg:aquarium> add dataset

zonecfg:aquarium:dataset> set name=zoo/fish

zonecfg:aquarium:dataset> end

Вот результат:

# zlogin aquarium

[Connected to zone 'aquarium' pts/1]

# zpool list

NAME     SIZE     USED  AVAIL  CAP  HEALTH   ALTROOT

zoo     31.8G     353K  31.7G   0%  ONLINE   -

# zfs list -r

NAME              USED  AVAIL  REFER  MOUNTPOINT

zoo               260K  23.4G  38.2K  /zoo

zoo/fish         74.8K  5.00G  38.2K  legacy

Внутри зоны мы видим пул zoo и делегированную файловую систему. Другие файловые системы мы не видим, и сами новую систему вне делегированной создать не можем:

# zfs create zoo/crocodile

cannot create 'zoo/crocodile': permission denied

# zfs create zoo/fish/salmon

# zfs list -r

NAME                 USED  AVAIL  REFER  MOUNTPOINT

zoo                  260K  23.4G  38.2K  /zoo

zoo/fish            74.8K  5.00G  38.2K  legacy

zoo/fish/salmon     36.7K  5.00G  36.7K  legacy

Есть еще одно интересное применение ZFS для работы с зонами – клонирование файловых систем. Клонирование – это по сути то же самое, что и всем хорошо знакомые мгновенные снимки, snapshots. При клонировании файловой системы её клон не занимает места на диске – он начинает поглощать пространство только тогда, когда данные клона и оригинала начинают различаться. Занимаемое клоном место в точности равно этой разнице.

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

Вернемся в глобальную зону и посмотрим, на что влияют остальные параметры файловой системы.

NFS v4 и списки контроля доступа

Если вы включите параметр sharenfs, файловая система автоматически станет доступна по NFS, при этом /etc/dfs/dfstab редактировать не надо.

# zfs set sharenfs=on zoo/fish

# share

-            /mnt/fish         rw   ""

-            /mnt/fish/shark   rw   ""

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

Вместо списков POSIX-draft ACL, которые можно использовать на ufs, файловая система ZFS поддерживает новые списки стандарта NFS v4, формат которых похож на списки NTFS. Управление осуществляется обычными командами chmod, chown и ls; никаких getfacl и setfacl для ZFS не существует. По умолчанию все файлы имеют упрощенный список прав доступа:

# touch /zoo/animals/snake

# ls -v /zoo/animals/snake

-rw-r--r-- 1 root root  0 Feb 1 13:12 /zoo/animals/snake

     0:owner@:execute:deny

     1:owner@:read_data/write_data/append_data

         /write_xattr/write_attributes/write_acl

         /write_owner:allow

     2:group@:write_data/append_data/execute:deny

     3:group@:read_data:allow

     4:everyone@:write_data/append_data/write_xattr

         /execute/write_attributes

         /write_acl/write_owner:deny

     5:everyone@:read_data/read_xattr/read_attributes

         /read_acl/synchronize:allow

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

Назначение полей в строке прав доступа к файлу

Разберем строку номер 1 (cм. таблицу):

1:owner@:read_data/write_data/append_data

         /write_xattr/write_attributes/write_acl

         /write_owner:allow

Попробуем для примера добавить права нашему пользователю:

# chmod A+user:korobkin:read_data/write_data:allow snake

# ls -v /zoo/animals/snake

-rw-r--r--+  1 root root 0 Feb 6 18:01 /zoo/animals/snake

     0:user:korobkin:read_data/write_data:allow

     1:owner@:execute:deny

     2:owner@:read_data/write_data/append_data

         /write_xattr/write_attributes

         /write_acl/write_owner:allow

     3:group@:write_data/append_data/execute:deny

     4:group@:read_data:allow

     5:everyone@:write_data/append_data

         /write_xattr/execute/write_attributes

         /write_acl/write_owner:deny

     6:everyone@:read_data/read_xattr

         /read_attributes/read_acl/synchronize:allow

Я использую команду ls -v для подробного просмотра прав доступа к файлу. В повседневной работе это не очень удобно, проще использовать сокращенное отображение:

# ls -V /zoo/animals/snake

-rw-r--r--+  1 root root 0 Feb 6 18:01 /zoo/animals/snake

     user:korobkin:rw------------:------:allow

            owner@:--x-----------:------:deny

            owner@:rw-p---A-W-Co-:------:allow

            group@:-wxp----------:------:deny

            group@:r-------------:------:allow

         everyone@:-wxp---A-W-Co-:------:deny

         everyone@:r-----a-R-c--s:------:allow

Полный синтаксис назначения прав доступа с примерами лучше всего посмотреть в руководстве [1].

Резервное копирование

Как и в большинстве современных файловых систем, в ZFS реализованы мгновенные снимки, snapshots. Ничего нового про них рассказать не получится: снимок делается командой zfs snapshot, к нему можно получить доступ на чтение и сохранить данные на ленту, не мешая работать приложениям сервера. Кроме того, можно откатить состояние файловой системы ко времени создания любого снимка, обеспечив таким образом скоростное восстановление информации. Откатываются только изменившиеся блоки данных.

Наверное, единственным интересным отличием снимков ZFS является возможность их пересылки из одной файловой системы в другую (команды zfs send/receive). Такую функциональность можно использовать для репликации файловых систем, быстрого восстановления или резервного копирования на удаленный сервер.

Недостатки

Первая же мысль, которая приходит после изучения всех достоинств новой файловой системы, – перевести все сервера целиком на ZFS. Увы, не получится. Чтобы загрузчик нашел при старте ядро Solaris, он должен уметь читать ZFS, а стандартный GRUB этого не умеет. Впрочем, если выделить небольшой кусочек диска под каталог /boot на ufs, то можно обеспечить загрузку микроядра, которое сделает остальную работу. Можно даже реализовать альтернативную загрузку в безопасном режиме, с подключением корня и других файловых систем стандартно в каталог /a, как это описано в [3].

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

Выводы

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

Удачи.

  1. Solaris ZFS Administration Guide – http://docs.sun.com/app/docs/doc/819-5461.
  2. Jeff Garzik. Linux: Why Software RAID? – http://linux.yyz.us/why-software-raid.html.
  3. Doug Scott, ZFS Root on Solaris (Part 1, 2, 3) – http://solaristhings.blogspot.com/2006/06/zfs-root-on-solaris.html.
  4. System Administration Guide: Security Services – http://docs.sun.com/app/docs/doc/816-4557.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru