?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

Home Storage - morfizm


Nov. 23rd, 2014 10:50 pm Home Storage

Продолжаю вялотекущий проект по апгрейду домашнего файлового сервера.
(Предыдущие посты: про бэкапы, про storage systems).

Итак, есть ряд решений, на которые я посмотрел:
1. Множество разных NAS-ов на 1-2 диска, иногда они продаются просто как "enclosures", но с поддержкой локальной сети.
2. Решения под сервер с 3+ дисками:
2.1. WHS (Windows Home Server, мой текущий solution).
2.2. Synology (продаётся как софт + железка).
2.3. FreeNAS (бесплатный софт + ставишь на свою железку).
2.4. Железный RAID-контроллер + разный софт.

Ряд решений я отбросил.

*) Решения для 1-2 дисков слишком громоздки для тех объёмов, которые мне нужны. Придётся покупать много таких штук и все их обслуживать (для каждой свой провод сети, у каждой свой источник питания, каждую настраивать для сетевого доступа и т.п.). Все стандартные операции по сопровождению системы умножаются на количество девайсов. Грустно, отбрасываем.
Плюсы и минусы:
+ Компактно, дёшево.
- Много гемора в обслуживании. Особенно геморно получить performance benefit от striping при наличии redundancy (нужно конфигурить RAID 0 и делать redundancy на разные девайсы).
- Дорого делать redundancy (защититься от сбоя одного винча стоит 2x по количеству и объёму винчей).

*) WHS отбрасываем по целому ряду соображений, главный из которых, что он мне надоел, но для полноты картины перечислю плюсы и минусы.
+ Мало гемора, чтобы всё работало с Windows clients.
+ Отличный solution для инкрементальных бэкапов компьютеров-клиентов, с удобным partition level восстановлением, а также с file-level доступом.
- Нет поддержки комбинации из redundancy & striping. Всё в рамках стандартных вещей, доступных в disk manager for dynamic disks (either striping = equal size partitions on multiple disks or mirroring, again equal size)
- Системная партиция живёт на одном из дисков и переустанавливать её геморно.
- Не очень понятно, как делать encryption.

*) Synology. У Synology есть поддержка специального software-RAID'а, в котором допустимы диски разного размера, как со striping'ом, так и с redundancy, при этом можно растить объёмы, заменяя диски по одному. Также поддерживается encryption. Всё это прекрасно, но главное соображение, по которому отбрасывается Synology - это то, что они думают, что поддерживать ECC-память нужно только в серверных решениях экстра-класса, стоящих начиная от $3000 (цена на DS3612xs). Для обычных пользователей никакого ECC, следовательно, до свидания.

Выбранное решение.

*) FreeNAS. FreeNAS на сегодняшний день является предпочтительным вариантом, выбранным методом исключения. Плюсы и минусы:
+ Открытая система, если вдруг что-то сломается с софтварным RAID'ом, мне не нужно будет давать доступ в саппорт Synology, а я смогу полазить по форумам и, может быть, разобраться самостоятельно.
+ ZFS. Это файловая система и volume manager. Там много интересных фич, помогающих защититься от bit flip errors over time, нативная поддержка snapshot'ов, selective duplication, encryption, ну и главное это software'ный RAID в котором striping for performance сочетается с redundancy. Скажем, 4 диска по 2TB дадут 6TB юзабельного пространства (т.к. 1 диск redundant), но при этом скорость доступа будет втрое выше. Для меня достаточно важно максимизировать 1 GBit throughput. Отдельные винчи дают где-то 50-65% от 1 GBit в конце диска.
+ Для системы не нужен отдельный диск, можно грузиться с 4GB-флешки.
+ Хорошая поддержка криптования. Lower performance overhead. Я думаю, что вполне реально защититься от утечки данных в случае "украли железку", кроме случая если воры как-то специально хакнут систему питания, чтобы избежать power down.
- Нет поддержки разного размера дисков. Чтобы увеличить объём volume, нужно заменить *все* диски на диски большего размера. Что делает постепенный апгрейд сильно дороже. Я думаю, что нужно обновлять диски парами, так чтобы следующая пара всегда была с запасом, тогда можно платить лишь за два диска при каждом апгрейде, дающем дополнительное место (скажем, 2+2+3+3 даёт 6, потому что диски на 3 используются как если бы они были 2, но потом 5+5+3+3 даёт 9 - мы начали использовать всё по 3, соответственно, получили увеличение +3 по цене двух дисков по 5.)
- Довольно геморно использовать систему для чего-то кроме файлового сервера, особенно если использовать большую флешку. В частности "с наскоку" не получилось даже расширить системные партиции, gparted их не идентифицирует.

Купленное железо под FreeNAS:
* HP Proliant N40L подержанный за $250+tax ($265). Он очень маленький и тихий. В нём есть место для 4 дисков на 3.5".
** В него можно вставить две PCI-e карты расширения. Собираюсь поставить карту для поддержки USB 3.0. Пока там только USB 2.0.
* 16GB ECC-памяти я купил примерно за $200, но она сейчас продаётся за $180+tax.
* Купил отдельно для бэкапов WD Green 5TB. До этого попробовал более дешёвый Samsung на 4TB и он оказался очень шумным. WD как и были лидеры в области бесшумных винчей, так и остались ими.

32 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:kot_begemot
Date:November 24th, 2014 02:08 pm (UTC)
(Link)
16GB памяти для ZFS - это явно недостаточно. Процессор - явно слишком слабый.
Будет тормозить, даже на хороших дисках. Если так нравится ZFS, то не стоит ограничиваться FreeNAS, стоит посмотреть на Nexenta Community Edition, а также на SoftNAS - если у них есть версия для железа, последний раз я на них смотрел полгода назад и они были только виртуально-клаудные.
From:morfizm
Date:November 24th, 2014 06:58 pm (UTC)
(Link)
Я читал про RAM reqs. Во-первых, у меня на сервере в основном большие файлы (от пары мегабайт и выше) и sequential access, во-вторых я не собираюсь использовать deduplication, только RaidZ + encryption. Размер массива будет 8T (2+2+2+2), в какой-то момент я планирую рост до 20T (5+5+5+5) на том же железе. Неужели мне не хватит 16GB RAM, чтобы заполнить 1GBit/sec на дисках, которые, работая по отдельности, могут заполнить половину от 1GBit/sec?

Другие вещи посмотрю, спасибо.
From:kot_begemot
Date:November 24th, 2014 08:04 pm (UTC)
(Link)
CPU нужен чтобы считать block pointers - в них на каждый блок крипто-чексумма вычисляется, помимо прочего.
Память нужна, во-первых, для того, чтобы строить transaction tress - основное свойство ZFS в том, что она всё время copy-on-write, т.е. на каждую транзакционную группу строится полное новое дерево блоков, представляющее всю файловую систему целиком. Во-вторых, память нужна для того, чтобы сгладить эффект random read slowdown, который неизбежно возникает как следствие copy-on-write.
Последний эффект можно несколько снизить, добавив в систему SSD в качестве dedicated L2ARC device, ну и второй под ZIL не помешает.
Кстати, при заполнении дисков более чем на 60% производительность уходит вниз очень сильно, а после 80% система вообще не работает.
From:morfizm
Date:November 24th, 2014 11:06 pm (UTC)
(Link)
Спасибо за объяснение. Почитал ещё про ZFS.

Я понимаю потенциал тормозни и требования ещё большей памяти для разных юс-кейсов как для нагруженного файл-сервера (много пользователей, много маленьких файлов туда-сюда, NFS), так и для локального диска (скажем, база данных на диске). Всё же мой юс-кейс довольно lightweight и мне было бы очень странно видеть, если ZFS будет тормозить на нём с 16GB:

1) Snapshots я буду использовать в одном-единственном случае - во время полного бэкапа сервера, и это будет происходить раз в неделю, не чаще.
2) Deduplication я использовать не буду, пусть client backup software само делает инкрементальные бэкапы.
3) Регулярное чтение и запись файлов происходит с довольно большими файлами, скажем, я не ожидаю больше, чем 10-20 файлов в секунду на чтение или на запись.
4) Почти вся запись в режиме удаления файлов и добавления файлов. Открытие файла и random access write будет крайне редко.
5) Кроме бэкапа и scrubbing, использование файлового сервера довольно лёгкое - в большинстве случаев 0-1 юзер at a time, иногда 2.

Мне так кажется, что кэширование и readahead нафиг не нужны. Если нужно будет что-то подкрутить в ZFS, чтобы их отключить, я их отключу. Общее количество файлов строго меньше миллиона, из них регулярный доступ может лишь к десяткам тысяч.
From:kot_begemot
Date:November 25th, 2014 08:20 pm (UTC)
(Link)
ZIL нужен для ускорения записи, L2ARC - для ускорения чтения. Оба желательно иметь, иначе совсем грустно будет с производительностью.
From:morfizm
Date:November 25th, 2014 07:47 pm (UTC)
(Link)
Правильно ли я понимаю, что дерево блоков нужно будет строить во-первых, не для всей файловой системы, а только для affected files, а, во-вторых, это происходит только если имеется хотя бы один активный snapshot?

(В моём юс-кейсе snapshots я буду использовать только коротко на время полного бэкапа, а, может, и вообще не буду использовать)
From:morfizm
Date:November 24th, 2014 07:00 pm (UTC)
(Link)
По поводу процессора и памяти - более крутая железка, в которую влезет и процессор получше и больше памяти, would defeat the purpose - потребуется большой вентилятор и будет шумно. Я отталкивался от железки главным образом for environmental reasons (чтобы не шумело и не грелось).
From:kot_begemot
Date:November 24th, 2014 08:05 pm (UTC)
(Link)
Если плясать от железки, то надо ставить что-то другое.
From:morfizm
Date:November 24th, 2014 11:08 pm (UTC)
(Link)
Есть конкретные варианты дающие software RAID, сравнимый с RaidZ + encryption?
From:ermouth
Date:November 25th, 2014 05:31 pm (UTC)
(Link)
А если не секрет, что за задачи такие дома, что требуется постоянные 1Gbit/s?
From:morfizm
Date:November 25th, 2014 06:48 pm (UTC)
(Link)
Обычные задачи.

Мне кажется, тебе надо отталкиваться не от потребностей, а от возможностей, чтобы это лучше понять. Поставь себе на desktop workstation хотя бы stripped 2xSSD (RAID 0) чтобы max out SATA III, и привыкни к этому experience'у. Мне кажется, через месяц после этого ты меньше, чем на гигабит для серверного storage не согласишься :) Я понимаю, что апгрейд сети на 10 GBit это мегагемор и слишком дорого, не планирую это делать в ближайшие год-два. Но уж гигабит дайте весь.

Проблема в том, что файлы немножко растут. Видео тяжелее, фотки тяжелее, даже музыка тяжелее (я научился слышать разницу между 128 и 320, и теперь использую max quality VBR в lame, что даёт average где-то 250 kbps). Простейшие сценарии:
- показать фотки гостям,
- проинсталлировать что-то на новую машину,
- скопировать виртуальную машину,
- стримить видео,
уже требуют гигабита. На меньших скоростях перестаёшь хранить вещи на сервере и хранишь их локально, чтобы не тормозило. Ну или приходится maintain'ить несколько коллекций с разным уровнем сжатия.

Ещё - бэкапы. У меня каждый день все машины бэкапятся инкрементально на сервер, кроме того, весь сервер бэкапится тоже. Все машины суммарно это 0.7T. Это два часа с гигабитом, но со 100 мегабитами это сутки. Уже один бэкап наступает на горло другому.
From:ermouth
Date:November 25th, 2014 08:04 pm (UTC)
(Link)
Тезис «отталкиваться от возможностей» считаю немного странным. Это не политика же.

Сценарий «инкремент на сервер раз в сутки плюс бэкап сервера» – на мой вкус не очень. Такая перерезервированная конфигурация бэкапа только данных и при этом всего раз в сутки – это просто иллюзия надёжности.

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

Плюс не учитывается ремонтопригодность, а с этим делом при экзотических конфигурациях беда.

Работу в обе стороны с чем-то объёмным с сетевых носителей есчо я не рассматриваю вообще, в первую очередь из-за самого устройства API, «превращающих» сетевое подключение в файл. Все эти API с родовыми травмами.


С другой стороны, я и похлеще эксперименты ставил )

Что меня действительно иногда раздражает и местами здорово ограничивает – так это нераспараллеленность (однопоточность) очень многих приложений, которым стоило бы быть многопоточными.

-------

Про 320 MP3 от 128 – мне пришло в голову интересное соображение. Если ты слышишь эту разницу ухом, которое у тебя слышит хуже, значит, возможно, дело не физической деградации слухового канала. Судя по картинкам из недавнего поста, ты вроде бы не должен отчётливо слышать эту разницу при одинаковом кодеке. И мне даже кажется, что обоими ушами.

Например http://www.noiseaddicts.com/2009/03/mp3-sound-quality-test-128-320/
From:morfizm
Date:November 25th, 2014 10:06 pm (UTC)
(Link)
"Тезис «отталкиваться от возможностей» считаю немного странным. Это не политика же."

Это психология, кроме того, это культура, причём, на мой взгляд, это, в некоторой степени, изъян в культуре. В современном мире принято заниматься problem solving'ом. Центральный аргумент, чтобы что-то делать - это *проблема*, которую надо решить. Какой-то pain point. Причём, на мой взгляд, по-настоящему революционные "решения" не решают проблемы, они их создают, они открывают новые юскейсы, а не "улучшают старые".

Простейший пример - попробуй убедить человека, всю жизнь сидевшего за лаптопом, в лучшем случае за одним 20" монитором, в том, насколько важен хороший desktop setup с двумя мониторами по 24". (Предлагаю не углубляться в религиозную войну, что лучше, 2x24" или 1x30", это не относится к делу). Ну так вот, убедить такого человека не получится, т.к. он привык работать за компьютером с небольшим screen real estate. Если что-то у него делается неоптимально, он не видит этого, потому что в его setup'е невозможно быстрее и лучше, это психологически ощущается как оптимально и комфортно. На каждый рациональный довод будет пожатие плечами и объяснение, как всё это можно сделать с одним небольшим монитором. Дай этому человеку нормальный setup на полгодика, и он будет недоумевать, как можно вообще за лаптопом делать что-то полезное, его будет скручивать pain :)

Примерно так и с производительностью домашних серверов. Ты работу в обе стороны с чем-то объёмным с сетевых носителей не рассматриваешь вообще, а у нас на работе практически всё идёт через сетевые носители, подмаунченные как файловые системы, и performance на них не отличим от локального диска, местами даже быстрее. Но ты не воспринимаешь этот юс-кейс, потому что реально быстрого сетапа у тебя просто не было, твой workflow организован на основе тех мощностей, к которым ты привык.


"Без резервирования среды исполнения такая зверская конфигурация бэкапа данных в домашних условиях имхо круууто перебор."

У меня бэкап всех дисков at partition level, обычно хранятся 10 версий: 3 последних дня, 3 последних недели, 3 последних месяца + 1 мануальный бэкап, делаемый раз в 6-12 месяцев. Причём "среда исполнения" это всегда системная партиция, отдельная от партиции с данными - их можно восстанавливать независимо.


Непрерывный бэкап данных ещё не пробовал организовать. Не очень понятно, как. Какой бэкап ты имеешь в виду - full version control, или просто копию типа rsync/robocopy? Дело в том, что потери данных куда чаще случаются в результате неаккуратного удаления или порчи чего-то, чем от потери железа, и тупо копия не поможет тебе от удаления (удаление или порча засинхронизируются и копия будет тоже негодна).


Насчёт твоего sound quality test - он не открывается. Можешь скачать и перезалить или дать другую ссылку на что-то похожее?

Я не очень понимаю, какая связь между способностью различать звуки (разрешающей способностью) и уровнем слуха. В плеерах вообще-то можно громкостью повышать :) Если я повышаю громкость на 30 db, то я слышу как все нормальные люди, а нижние частоты слышу даже лучше.
From:morfizm
Date:November 25th, 2014 06:53 pm (UTC)
(Link)
К интернету 25 MBit/sec аналогичным образом привыкаешь. 10 MBit/sec уже unusable. Но на днях мне провайдер обновил модем и скорость стала 60 MBit/sec. Я боюсь, что скоро мне будет тяжело на 25 :)
From:morfizm
Date:November 25th, 2014 07:10 pm (UTC)
(Link)
(На работе у меня гигабитный интернет, кстати).