Рубрика:
Администрирование /
Администрирование
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Алексей Коробкин
Используйте преимущества файловой системы 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 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 и отвлечься на более интересные задачи, не беспокоясь о сохранности корпоративной информации.
Удачи.
- Solaris ZFS Administration Guide – http://docs.sun.com/app/docs/doc/819-5461.
- Jeff Garzik. Linux: Why Software RAID? – http://linux.yyz.us/why-software-raid.html.
- Doug Scott, ZFS Root on Solaris (Part 1, 2, 3) – http://solaristhings.blogspot.com/2006/06/zfs-root-on-solaris.html.
- System Administration Guide: Security Services – http://docs.sun.com/app/docs/doc/816-4557.
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|