 |
|
|
|
Используйте преимущества файловой системы 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. Вот статус системы:
Один диск – это не очень интересно. Построим новый пул zerkalo3 на основе тройного зеркала, то есть RAID-1 на трех дисках:
В больших хранилищах редко встретишь зеркала: алгоритм контроля четности и избыточности данных 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 на нескольких дисках:
Если у вас много дисков, Sun рекомендует разбивать их на группы от трех до девяти для повышения производительности. Обратите внимание на повторяющееся ключевое слово raidz2 в списке:
Таким образом, у нас два массива RAIDZ2 объединены в пул. Обратите внимание: данные в таких конфигурациях динамически распределяются по всем массивам пула, не подчиняясь каким-либо строгим алгоритмам. Это значит, что, например, создать зеркало из двух RAIDZ нельзя. Зато можно добавлять в существующий пул любое количество новых дисков, и Solaris будет постепенно раскладывать данные по всем массивам. Добавим еще один набор дисков в пул kombi:
Как видите, гибкость и простота настройки массивов невероятные, при том что ошибиться практически невозможно. Впрочем, перед выполнением команды можно заранее посмотреть, что именно будет выполнено (ключ -n):
А затем и создать массив:
Веб-интерфейс Впрочем, иногда хочется отдохнуть от командной строки и воспользоваться графическими инструментами. У 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 автоматически определит это и соберет все массивы в правильном порядке. Перейдём к ошибкам. Что делать, если массив был ненароком уничтожен? Если после уничтожения никакие другие массивы не создавались, то диски находятся в прежнем состоянии и массив можно воскресить. Сначала смотрим список уничтоженных или отключенных массивов:
Solaris не только показывает, в каком состоянии находится массив, но и пишет понятный комментарий о возможных действиях по его восстановлению.
Что происходит, когда выходит из строя диск?
Мы видим, что пул rombik отмечен как degraded, напротив соответствующего диска указана причина ошибки, а в свойствах пула появилось подробное описание проблемы и даже ссылка на более актуальную документацию онлайн. Сообщение «No known data errors» означает, что нет ошибок, непосредственно связанных с порчей данных, поскольку доступных дисков достаточно для восстановления утерянной информации. Столбцы READ, WRITE и CHECKSUM указывают количество ошибок при чтении, записи и подсчёте контрольных сумм. При обнаружении таких ошибок ZFS проверяет целостность затронутого файла и исправляет файл целиком, а не только испорченный блок данных. Команды fsck для ZFS не существует в силу транзакционности файловых операций. Для поиска плохих секторов используется команда zpool scrub, которая выполняет поблочную проверку файлов и их контрольных сумм в фоновом режиме и с самым низким приоритетом. Таким образом, сервер с файловой системой ZFS останавливать на обслуживание нет необходимости, все его файловые системы всегда доступны. Файловая система До сих пор для работы с ZFS мы использовали только одну команду, zpool. На самом деле команд в комплекте ZFS целых две. Вторая, zfs, работает с файловыми системами внутри пула, и именно здесь лежит одно из фундаментальных отличий ZFS от других средств управления хранилищами. Пул хранит в себе неограниченное количество файловых систем, отличающихся друг от друга только указанными администратором свойствами: именем, объёмом, точкой монтирования, сжатием, наследованием привилегий, родительской файловой системой и прочими. Файловая система внутри пула никак не привязана к физическому или логическому устройству – только к самому пулу. Администратор не должен думать о том, как именно располагаются его данные на физических дисках. Ему достаточно создать пул устройств, как мы это делали выше, построить внутри него нужное количество файловых систем и работать непосредственно с ними. Исследуем работу файловых систем внутри пула на примерах:
При создании пула в нём сразу же создается файловая система zoo и подключается к каталогу /zoo. Обратите внимание, что в /etc/vfstab ничего писать не надо – файловые объекты ZFS по умолчанию монтируются автоматически. Как при создании пула, так и при создании файловой системы, и при загрузке Solaris, управляет этим процессом бинарный файл /etc/zfs/zpool.cache. Создадим файловые системы animals и fish внутри zoo:
То, что мы сейчас сделали, очень сильно отличается от обычной работы с файловыми системами. Мы ничего не форматировали, мы не указывали размер, физический диск или точку монтирования. Мы просто создали в пуле zoo две дополнительные файловые системы, и моментально можем начинать работать с ними. Все необходимые параметры мы можем задать потом или пронаследовать из вышестоящей файловой системы. Например, изменим параметр compression (сжатие) файловой системы zoo/fish.
Поле Source указывает, откуда взято значение параметра. До изменения в этом поле стояло ключевое слово default, «по умолчанию». Теперь там local – параметр указан непосредственно для данной файловой системы. Если мы создадим внутри zoo/fish файловую систему shark, то параметр compression пронаследуется от fish:
Чтобы указать размер файловой системы, мы используем свойство quota:
Уменьшим доступное zoo/fish пространство до пяти гигабайт: # zfs set quota=5gb zoo/fish Список файловых систем теперь выглядит так (ключ -r перебирает все вложенные файловые системы):
Как видите, вместе с размером файловой системы fish сократился и размер системы fish/shark. Понятно, что если бы мы таким образом создавали домашние каталоги пользователей, мы могли бы просто и легко на лету менять доступное им свободное пространство, включать компрессию данных и многое другое. Посмотрим, какие еще есть свойства у файловых систем ZFS:
Параметры, у которых поле Source пустое – только для чтения. К ним можно обращаться, чтобы узнать текущее состояние системы. Например, занятое место на файловой системе:
Ключ -H убирает заголовок результата, чтобы можно было легко передать данные скрипту. Поля used, available, и quote относятся к размеру самой файловой системы, а referenced – к размеру данных, занятых служебной информацией. Интересное поле reservation дает возможность зарезервировать свободное пространство для файловой системы, чтобы никакие другие файловые системы на него не претендовали и считали занятым. Свойство mountpoint указывает, к какой папке подключена файловая система. Мы не обязаны сохранять иерархию, предлагаемую по умолчанию, и можем монтировать файловые системы куда угодно. Например, перенесём zoo/fish в /mnt:
Как видите, вложенные файловые системы унаследовали точку монтирования. А если 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 Вот результат:
Внутри зоны мы видим пул zoo и делегированную файловую систему. Другие файловые системы мы не видим, и сами новую систему вне делегированной создать не можем:
Есть еще одно интересное применение ZFS для работы с зонами – клонирование файловых систем. Клонирование – это по сути то же самое, что и всем хорошо знакомые мгновенные снимки, snapshots. При клонировании файловой системы её клон не занимает места на диске – он начинает поглощать пространство только тогда, когда данные клона и оригинала начинают различаться. Занимаемое клоном место в точности равно этой разнице. А теперь предположим, что у нас есть уже настроенная зона, все файлы которой расположены на ZFS. Если мы хотим настроить очень похожую зону, то можно при её создании указать, что файловую систему зоны следует клонировать с уже имеющейся. Экономия пространства на диске, времени и сил администратора налицо! Вернемся в глобальную зону и посмотрим, на что влияют остальные параметры файловой системы. NFS v4 и списки контроля доступа Если вы включите параметр sharenfs, файловая система автоматически станет доступна по NFS, при этом /etc/dfs/dfstab редактировать не надо.
Зачем так сделано? Как вы уже успели заметить, файловые системы ZFS очень гибкие и легкие, и постоянно следить, куда именно переместилась та или иная система, неудобно. А всякий раз соответственно редактировать dfstab было бы просто мукой. Поэтому вы один раз указываете, какие файловые системы должны быть доступны по сети, делаете с ними что хотите, а они тем не менее остаются доступны. Обеспечение безопасности осуществляется списками контроля доступа. Вместо списков POSIX-draft ACL, которые можно использовать на ufs, файловая система ZFS поддерживает новые списки стандарта NFS v4, формат которых похож на списки NTFS. Управление осуществляется обычными командами chmod, chown и ls; никаких getfacl и setfacl для ZFS не существует. По умолчанию все файлы имеют упрощенный список прав доступа:
Список читается сверху вниз, двоеточие служит разделителем полей. Каждая строка определяет либо то, что явно разрешено, либо то, что явно запрещено, неявных значений быть не может. Назначение полей в строке прав доступа к файлу Разберем строку номер 1 (cм. таблицу):
Попробуем для примера добавить права нашему пользователю:
Я использую команду ls -v для подробного просмотра прав доступа к файлу. В повседневной работе это не очень удобно, проще использовать сокращенное отображение:
Полный синтаксис назначения прав доступа с примерами лучше всего посмотреть в руководстве [1]. Резервное копирование Как и в большинстве современных файловых систем, в ZFS реализованы мгновенные снимки, snapshots. Ничего нового про них рассказать не получится: снимок делается командой zfs snapshot, к нему можно получить доступ на чтение и сохранить данные на ленту, не мешая работать приложениям сервера. Кроме того, можно откатить состояние файловой системы ко времени создания любого снимка, обеспечив таким образом скоростное восстановление информации. Откатываются только изменившиеся блоки данных. Наверное, единственным интересным отличием снимков ZFS является возможность их пересылки из одной файловой системы в другую (команды zfs send/receive). Такую функциональность можно использовать для репликации файловых систем, быстрого восстановления или резервного копирования на удаленный сервер. Недостатки Первая же мысль, которая приходит после изучения всех достоинств новой файловой системы, – перевести все сервера целиком на ZFS. Увы, не получится. Чтобы загрузчик нашел при старте ядро Solaris, он должен уметь читать ZFS, а стандартный GRUB этого не умеет. Впрочем, если выделить небольшой кусочек диска под каталог /boot на ufs, то можно обеспечить загрузку микроядра, которое сделает остальную работу. Можно даже реализовать альтернативную загрузку в безопасном режиме, с подключением корня и других файловых систем стандартно в каталог /a, как это описано в [3]. К другим недостаткам относится повышение требований к объему оперативной памяти сервера. Для обеспечения высокой производительности Sun советует иметь не менее одного гигабайта оперативной памяти на серверах, использующих ZFS. Выводы Новая файловая система, безусловно, заслуживает самого пристального внимания системных администраторов. Высокая производительность, надежность, масштабируемость, удобство в управлении и множество новых свойств, которых Solaris так не хватало раньше, теперь полностью и совершенно бесплатно доступны каждому. Современные серверs с их необъятными и почти неуправляемыми хранилищами, высокой нагрузкой и требованиями к постоянной доступности отныне можно оснастить ZFS и отвлечься на более интересные задачи, не беспокоясь о сохранности корпоративной информации. Удачи.
|
Алексей Коробкин
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
