?

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: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:ermouth
Date:November 25th, 2014 11:27 pm (UTC)
(Link)
Я немного не по порядку, сорри.

Насчёт слуха – всё же разница есть. Кейворд – auditory masking. Искажения, которые вносит 320 отличаются от искажений, которые вносит 128, в тех областях спектральной функции, в которых падение слуха судя по графикам особенно существенно.

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

С другой стороны, мне пришло в голову, что помимо чисто механических свойств уха есть ещё проф. навык музыканта, который позволяет слышать такие изъяны, которые просто ухо не очень различает.

Это примерно как я на глаз вижу различия в JPEG-упаковке очень близкого качества, хотя не должен бы по идее. Более «зажатый» снимок выглядит менее естественно, и я далеко не всегда смогу сказать, в чём именно – но определяю безошибочно.

Примеры по ссылке скачать затруднительно, там Flash, так что лучше тебе попробовать из браузера, где есть Flash.

----

Насчёт бэкапа – да, full version control непрерывно. У меня это сделано несколькими способами. Основной для FS – TimeMachine.

----

Резервирование «среды исполнения» – это, по-хорошему, не тогда, когда её нужно откуда-то восстанавливать. Это когда она непрерывно доступна вне зависимости от состояния отдельных единиц оборудования. До определённого предела, конечно.

----

Работу с чем-то объёмным по сети я не рассматриваю дома.

В бизнесе – да запросто, я же из полиграфии. Фотонабор рисует 500-мегабайтную битовую карту 14х20 инчей в 3600 точек на дюйм за 30 секунд (это 120 Мбит/с), и это был рядовой производственный процесс 15 лет назад. И происходил он параллельно с растрированием других карт, сбором исходников по сети и тд. И процесс этот (рисования лазером на плёнке) – синхронный, ога.

Так что я представляю, что такое сеть, где сетевые диски иногда быстрее локальных. И я точно знаю, что такую сеть нереалистично построить по радиоканалу за разумные деньги. А дома у меня вайфай.
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)
(На работе у меня гигабитный интернет, кстати).