?

Log in

No account? Create an account

Previous Entry | Next Entry

Про SnapRAID + Aufs

Вопрос организации массива дисков встает перед каждым владельцем домашнего сервера. Вариантов тут масса, и все они неплохо задокументированы. Очень много русскоязычной информации можно почерпнуть в профильной ветке на iXBT и в блоге одного из главных ее активистов 2gusia. Одним из наиболее популярных вариантов является использование чудесной файловой системы ZFS. Это действительно невероятно мощная штука, по указанным мной ссылкам можно почерпнуть немало тому доказательств.

Однако (особенно если вы используете Linux) этот вариант не является единственным, и я бы хотел чуть подробнее рассказать об одной из альтернатив ZFS, вполне пригодной для использования в домашнем медиасервере. Это связка из двух программ: SnapRAID и aufs.

SnapRAID обеспечивает аналоги RAID 5-6(-7-8-9...), вычисляя контрольные суммы и храня эти данные на выделенных жестких дисках. В отличие от классического RAID и raidz, он работает поверх файловых систем - на выделенном разделе создается огромный parity-файл, каждый файл на диске лежит на одном конкретном диске. Всего для хранения контрольных сумм можно выделить до 6 дисков (т.е. в теории можно построить просто гигантский массив, устойчивый к гибели до 6 дисков). Важный момент - SnapRAID не обеспечивает полновесный пулинг дисков! В коробке есть функциональность монтирования read only-пула, построенного на симлинках, но оно нам надо? Задачи пулинга возложим на Aufs. Aufs позволяет объединить папки (их система называет Branches - ветки), располагающиеся на самых разных дисках, и взять на себя заботу - куда конкретно положить вот этот файл. Есть различные стратегии балансировки ветвей (забивать ли диски по очереди, или всегда писать на самый свободный). Файл, опять же, всегда находится на одном конкретном диске.

Эту связку активно продвигает сообщество Openmediavault, в нем даже есть плагины для установки и настройки SnapRAID и Aufs из веб-интерфейса.

Попробую описать плюсы и минусы указанной архитектуры. Критика и правки принимаются.

Плюсы:

  • Массив очень легко собрать и разобрать на любых имеющихся дисках. Да-да, тип ФС и заполненность дисков роли почти не играют. Понятно, что для Parity необходимо использовать самые большие из имеющихся дисков, и специфика его использования (один гигантский файл) накладывает некоторые ограничения на выбор ФС - это все описано на сайте SnapRAID. Мой личный конфиг - в SnapRAID массив объединены 5 дисков, 2x 4 Tb (один из них как раз под Parity) на Ext4, 1 x 1 Tb на Ext4, 2 x 1 Tb на NTFS (!). При этом в Aufs-пул не включен один из NTFS-дисков (там лежат файлы жены, и вообще он USB-шный). Вся эта радость довольно стабильно работает, и никто не запрещает добавлять/убирать диски без необходимости сливать куда-нибудь в сторонку всю информацию. Доступ к каждому диску индивидуально остается (например, посмотреть где физически лежит какой файл), хотя вносить изменения подобным образом не рекомендуется (например, если на одноименные папки наложить разные права, могут возникнуть конфузы, а это еще самый очевидный вариант извращения...).

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

  • для чтения 1 файла используется только 1 диск - теоретически, это приводит к некоторому уменьшению шума и энергопотребления сервера.

  • Сравнительно низкие требования к ресурсам ЦПУ и оперативной памяти.

Минусы:

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

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

  • каждый файл пишется на единственный диск - ни о каком приросте скорости речи быть не может. Хотя не скажу, что для домашнего сервера это критично...

  • Сохраняются только файлы, симлинки и хардлинки - права доступа, владельцы, расширенные атрибуты не сохраняются.

Для автоматизации sync и scrub я использую модификацию довольно популярного скрипта. Изначально этот скрипт только выполнял пересчет контрольных сумм, потом автор SnapRAID-плагина адаптировал его к механизму отправки почты OMV, ну а я дописал туда Scrub массива на каждый 10-й запуск (при еженощном выполнении получаем обновление контрольных сумм каждую ночь, и проверку на ошибки каждые 10 ночей). Финальный скрипт можно почитать вот тут: http://pastebin.com/x2aK67TZ

upd от 05.01.2015: в текущей версии OMV скрипт уже умеет из коробки делать scrub, и даже настраивается из веб-морды, так что ссылка выше уже неактуальна.

 Вопрос выбора архитектуры хранения данных вообще не является однозначно решаемым, и каждый должен найти свой ответ под свои задачи. В случае Linux-медиасервера связка SnapRAID + Aufs, однозначно, заслуживает пристального внимания и права на жизнь.