Разделы:

• Главная
• Блог
• Контакты

Заметки по организации домашнего файлохранилища

Вначале были файлы и было их много. Больше чем моего терпения на поиск нужных в общей свалке. И подумал я, что так дальше продолжатся не может и начал искать способы их упорядочить. Что из этого получилось - ниже.

Теперь серьезно - здесь описываются различные попытки организации файлового хранилища с постоянно растущим объемом.

Итак, летопись деяний славных:

v1.0

История сего крестового похода против ха*о*са и анархии начинается приблизительно1 в 2004 году, когда у меня появилась возможность накапливать информацию в больших объемах.

Изначально это выглядело как 2 винчестера на 80 и 120Гб, забитых под завязку и несколько стопок дисков. Индекс по дискам был создан с помощью WhereIsIt и периодически2 обновлялся. Это неплохо работало, но объемы росли и накладные расходы стали возрастать непропорционально удобству. Общий объем данных тогда я оцениваю примерно в 400Гб.

Было принято решение наращивать объем за счет dvd-дисков с жесткой сортировкой по типу данных, опциональным шифрованием, и опять же - индексом на основе WhereIsIt'а.

Примерно в 2006 году я выкачал из университетской сети большое количество анимы и музыки - ~220/70Гб, что почти полностью заняло новенький 320Гб диск3. Опять задача о "волке, козе и капусте" встала в полный рост. Весь следующий год я смотрел, слушал и сортировал это хозяйство. Именно тогда образовался первый 80-дисковый кейс.

От WhereIsIt'а я отказался, т.к. большинство контента с точки зрения структуры было однотипным. Вместо этого, была написана простенькая база данных и прикручена на сайт нашей локалки. Сизифов труд. Поиск по связке "залезть в бд, найти нужный диск в кейсе" занимал примерно одинаковое время с методом поиска "перебрать весь кейс, заодно потешить свое ЧСВ".

В начале 2007 года подошла еще одна, намного большая, партия контента: Алексей со стоянки любезно поделился своей коллекцией vhs-кассет. Всё это заняло ещё три 80-дисковых кейса. Индекс был создан на основе той же самописной БД. Наконец-то поиск по базе стал быстрее перебора. Но время доступа к данным всё ещё было устрашающим. Кроме того, столкнулся с тем, что данные, записанные 2 года назад на бюджетные матрицы переставали читаться полностью.

Где-то в это время я перешел на линукс в качестве основной системы.

В начале 2008 года я ещё раз пересмотрел свою политику хранения данных и обратил взгляд на рынок hdd. Тогдашние объемы дисков в 500-750Гб были дешевле дисков в пересчете на гигабайт данных, кроме того - обладали 2 важными свойствами - перезаписываемостью и большим размером тома данных.

Был куплен винчестер на 500Гб и засунут в сервер для хранения данных. Позже, было куплено ещё 2 подобных винчестера. В сервер был добавлен ещё один диск и новый контент лился уже на него, чтобы не забивать первый полностью и хоть как-то поддерживать сортировку по типу контента.

"И первое время все было хорошо"4

В ночь на 1 января 2009 года основной винчестер с контентом в сервере испустил дух. Это была та самая печально известная 11я серия Seagat'ов, проклятая до скончания времен всеми, кому посчастливилось её купить. Потери составили 332Гб данных, большая часть - софт, мелкие видео и прочие данные, которые бэкапить нет особого смысла - устареют через полгода. Мой пост на сайте ЛС, полный отчаянья - тому свидетельство. Оставшиеся сигейты были срочно перепрошиты, но наполнять их было уже нечем.

v 2.0

После этого эпичного факапа были срочно проведены исследования в области отказоустойчивого хранения данных. На dvd-диски обратно мне возвращаться не хотелось, поэтому было решено продолжать эксперименты с raid'ами. К сигейтам, даже прошитым, доверия у меня уже не осталось, да и объемы дисков за это время выросли, поэтому злополучные диски я решил заменить как можно скорее на что-то понадежнее. Оставшийся диск был "подзеркален" и в таком виде система проработала до конца 2009 года.

На замену было куплено два 1,5Тб диска от WD. Требования были - экономичность (5400 оборотов на шпинделе, "зеленая" серия), размер сектора в 512б5. Организована связка raid5 -> шифрование -> ext4. Получился один здоровенный том на 1,5Тб. Позже, был докуплен ещё один подобный диск.

За прошедший год часть контента была восстановлена, часть - накачана заново, и все это добро было залито на новое место. Сразу же была отмечена долгая пересборка массива - порядка полутора суток, нагрев дисков до ~55-60 градусов и сильное, но ожидаемое, падение производительности i/o во время пересборки массива.

"И первое время все было хорошо".

Через месяц после начала использования (в феврале 2010 года) один из дисков начал сыпать бэдами. Помня события прошлогодней давности, весь массив был в срочном порядке остановлен и я понесся в магазин за заменой. Замену искали месяц, изначально предлагали из серии EARS, но все-таки нашли такую же модель. Сейчас уже трудно сказать, что послужило причиной поломки, но я думаю это был первоначальный перегрев. Опять пересборка массива на сутки.

Ещё через 2 месяца вылетел второй WD'шный диск. На этот раз уже плюнул - и взял аналогичный от Samsung.

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

Хотя у меня и осталось ощущение "хождения по краю бездны", но потерь данных не было, что и требовалось. Теперь осталось только разобраться с этим самым ощущением.

v3.0

После того случая с отключением света, внутренняя жаба была зверски задавлена и было принято волевое решение перейти на зеркальный raid. Также было решено сделать несколько томов с данными(по объему дисков), объединенными при помощи aufs. Я не стал делать raid10/01, т.к. это опять ставит проблему изменения размера ФС и шифрованного тома поверх, собственно, raid'а.

Похоже с железной частью я наконец-то разобрался, но есть несколько недоработок на уровне софта:

• Например если категория контента((Фильмы в данном случае)) размещена больше чем на 2х томах - поиск нужного файла с целью его удалить - то ещё удовольствие. Пока что посматриваю в сторону btrfs, но когда её допилят до приличного состояния - большой вопрос (да, это опять идея одного большого тома). Хотя этот вопрос можно обойти разбиением категории на несколько - помельче.
• Иерархия внутри ФС файлохранилища должна быть четко определенной, перемещение данных с одного тома на другой - дорогая операция.
• Пригодился бы какой-нибудь поисковик по контенту, вроде tracker'а но:
  • я пока не решил, так ли он нужен,
  • большая часть данных - видео, нечего там индексировать,
  • упомянутый tracker ориентирован на документы, не имеет нормальной поддержки томов данных и достаточно сыроват. Когда я им пользовался - постоянно что-то индексировал, даже если за последний месяц менялось всего три десятка файлов.

Технические данные

По состоянию на середину 2011 года сейчас в массиве - 5 дисков на 1.5Тб, не считая отдельного системного. Один том пока что не зеркальный, т.к. физически нет места на ещё один диск. Диски в "зеркальных" томах - Samsung, не "зеркальный" - последний оставшийся из WD.

Общий объем массива - 4,5Тб (занята пока половина места) + старый архив на dvd-дисках - примерно 2Тб.

Организация томов с данными.

• Системный диск (640Гб/LVM) (система, данные сервера, linux-репы, торренты, upload). Используется для задач где требуется много и часто писать на диск.
• Том 1: raid1 (хранение)
• Том 2: raid1 (хранение)
• Том 3: noraid (хранение, новые данные на сортировку)

Все это крутится на машине с P4 3.0, БП - 450W, материнка - от Gigabyte. Внешних SATA-контроллеров пока что нет. Теоретически, уже сейчас можно поставить все раком из-за шифрования, начав много и быстро качать контент. Но! пока что мне удается это сделать только на гигабитной сетке. Планируется поставить туда что-то помощнее и с поддержкой виртуализации.

Иерархия ФС

Организация физических томов в хранилище:

/mnt/vol-01/pub||dir1/
/mnt/vol-02/pub||dir2/
...
/mnt/vol-rw/pub||dir3/

где: - // - точки монтирования физического тома, - || - точки объединения товов с помощью aufs - vol-XX - тома хранения данных, vol-rw - том для записи новых данных и их сортировки. При заполнении становится очередным томом хранения.

Плюсы:

• такая организация массива позволяет обходится без изменения размера ФС и накладных расходов на шифрование при этом
• можно легко снять один или несколько томов без перестройки всего массива
• легкость замены тома - из-за raid1
• большая гранулярность

Минусы:

• перемещения между томами - дорогая операция. Также, эта операция неизбежна при сколько-нибудь неоднородной структуре данных.
• при реальных операциях с данными (!чтение) приходится искать данные по нескольким томам. Частично проблема снимается за счет размещения данных одного типа на одном тоие.

Дополнительная директория "pub" (в данном случае) позволяет хранить на том же томе другие данные, которые не должны включаться в объединенную фс. Данные "ниже" этой директории могут иметь произвольную структуру. Об этом речь пойдет дальше.

Итоговый результат будет таким:

/mnt/vol-united
  |->dir1
  |->dir2
  |->dir3
  ...
  `->dirN