Пользователь
0,0
рейтинг
5 марта 2014 в 13:22

Разработка → Еще один NAS своими руками, часть 1: из того, что было из песочницы

Аннотация


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

Эта статья не для специалистов по серверному хранению данных, геймеров и прочих оверклокеров. На вас, коллеги, и так вся индустрия работает. Она для начинающих сисадминов, любителей UNIX-систем и энтузиастов свободного программного обеспечения. У всех накопилось старое железо. Всем нужно хранить большие объемы дома или в офисе. Но далеко не у всех есть простой доступ к серверным технологиям.

Я очень надеюсь, что вы найдете для себя несколько полезных идей и все-таки научитесь на чужих ошибках. Помните: система стоит не столько, сколько вы заплатили за железо, а сколько вы вложите потом времени и сил в тестирование и эксплуатацию.
Если не хотите читать — посмотрите ссылки и выводы в конце; может, и передумаете.

DISCLAIMER


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

Благодарности


Респект Андрею Александровичу Бахметьеву, инженеру и изобретателю. Я горд, что Андрей Александрович преподавал для меня в институте! Желаю ему всяческих успехов в его проектах!

Задача


Итак, есть малый бизнес-стартап, генерирующий порядка 50Гб файлов в неделю, с необходимостью их архивного хранения в течение нескольких лет. Файлы крупные (порядка 10-20 Мб каждый), обычными алгоритмами не сжимаемые. Начальный объем данных порядка 2Тб. Совсем старые данные можно хранить в оффлайне, подключая по требованию.
Нужно уложиться в весьма скромный начальный бюджет решения 500 евро (в ценах лета 2013) и двухнедельный срок на сборку и тестирование.

За эти деньги нужно построить систему, которая позволит работать с файлами небольшой группе в одной локальной сети с разных платформ (Windows, Mac OS). Требуется длительная работа без сисадмина на площадке, защита от отказов и базовые функции управления правами доступа.

Традиционные пути


Безусловно, можно купить сетевое хранилище: их делают NetApp, QNAP, Synology и другие игроки, и притом делают неплохо даже для малого бизнеса. Но наши 500 евро – это только начало разговора для пустой коробки, без самих дисков. Если у вас есть 1000-2000 евро, лучше купите готовое изделие, а мы попробуем максимально заплатить знаниями и минимально — временем и деньгами.

UPD (спойлер ред. 2 от 2014-03-08):
Если собираете из нового железа, а не из хлама
По совокупности этого поста и его комментариев, любезно предоставленных хаброкомьюнити, предлагаю следующий алгоритм для простой четырехдисковой системы:
  1. Если двойного размера самой ёмкой из доступных моделей диска не хватает для хранимых данных, прекращаем читать спойлер (пример: модель 4Тб, требуется хранить 7Тб данных, тогда продолжаем; если требуется хранить 10Тб, тогда прекращаем)
  2. Выбираем изделие из линейки MicroServer известного производителя серверов Харлампий-Панкрат; например, n36l, n40l, n54l, с четырьмя отсеками для дисков (главное, чтобы была поддержка ECC-памяти)
  3. Обязательно комплектуем наш сервер памятью с контролем четности (ECC) из расчета 1Гб на каждый 1Тб хранимых данных, но не менее 8Гб (по рекомендации FreeNAS для дисков до 4Тб получается как раз всего 8Гб)
  4. Если у нас нет ECC-памяти, немедленно прекращаем читать этот спойлер, читаем пост до конца
  5. Выбираем производителя дисков, используя актуальный обзор отказов; например, вот этот: http://habrahabr.ru/post/209894
  6. Выбираем недорогую линейку SATA дисков с обязательным наличием ERC, а зачем, читаем здесь: http://habrahabr.ru/post/92701
  7. Выбираем ёмкость дисков (2Тб, 3Тб или 4Тб) из расчета, что их будет четыре, и что доступной для данных будет только половина (вторая половина на избыточность RAID)
  8. Перед закупкой еще раз внимательно и досконально проверяем совместимость железа между собой, количества слотов, отсеков, планок и прочего, но для FreeNAS самое главное — поддержка всего железа актуальным ядром FreeBSD
  9. Выбираем хорошую загрузочную флэшку, прочитав продолжение данного поста (часть 2: хорошие воспоминания)
  10. Закупаем, вдыхаем ароматы нового железа, собираем, подключаем, запускаем; для ZFS обязательно выключаем все аппаратные RAID'ы
  11. Создаем том RAIDZ2 из четырех дисков, обязательно с двойной избыточностью (на размерах тома около 12Тб есть риск повстречать злобного URE, читайте о нем в этом посте; если мы не боимся URE и все-таки собираем RAIDZ на четырех дисках, проверяем размер физического сектора — на современных дисках он 4Кб, и в этом случае получится совершенно нелепый страйп 43Кб, который еще и просадит нам скорость массива: forums.servethehome.com/hard-drives-solid-state-drives/30-4k-green-5200-7200-questions.html)
  12. Соль, сахар, перец, jail'ы, шары, скрипты и тому подобную сметану добавляем по вкусу



А как же облачное хранение, спросите вы? На момент написания этой статьи популярные облачные хранилища для наших объемов выглядят дороже, чем хотелось бы. Например, стоимость хранения неограниченного объема данных 36 месяцев на известном сервисе Брось Бокс обойдется в пару тысяч долларов с лишним, хотя и выплачивать их можно постепенно. Конечно, есть сервисы вроде Amazon Glacier (благодарю А.М. за подсказку) или Ажурных Окон, но, во-первых, они тарифицируют не только хранение, но и обращение (как его априорно подсчитать?), а во-вторых не будем забывать, что бизнес сидит на Интернет-аплинке 10Мбит, и маневры терабайтами потребуют не только определенных усилий по управлению процессами, но и будут весьма утомительными для пользователей.

Обычно в таких случаях берут старый компьютер, докупают большие диски, ставят Linux (не обязательно, кто-то ухитряется и Windows 7), делают массив RAID5. Отлично. Всё работает хорошо примерно полгода-год, но одним солнечным утром сервер вдруг пропадает из сети без всякого предупреждения. Конечно, сисадмин уже давно работает в другой фирме (текучка кадров), резервной копии нет (объемы слишком велики), а новый сисадмин починить систему не может (при этом на чем свет стоит ругает старого сисадмина и диалект Linux YYY, ведь надо было использовать Linux ZZZ, тогда проблем бы точно не было). Все эти истории повторяются давно и одинаково, меняются только версии ОС и растут объемы данных.

Отраслевые мифы


Миф о RAID5

Самый распространенный миф, в который я и сам верил до недавнего времени – это то, что второго подряд отказа в массиве на практике не может быть по теории вероятности. А вот и может, да еще как! Смоделируем реальную ситуацию: сервер проработал пару лет, после чего в массиве отказывает диск. Пока ничего страшного, ставим новый диск, и что происходит? Ага, реконструкция массива, т.е. длительная максимальная нагрузка на уже порядком изношенные диски. В такой ситуации отказы очень даже возможны и происходят.
Но это не все. Есть еще заложенная производителем методическая вероятность ошибки чтения, которая при определенных обстоятельствах сейчас уже практически гарантирует, что RAID5 после отказа диска обратно не соберется.

Миф о терабайте

Можно, конечно, считать всех производителей дисков начинающими программистами, но один отраслевой килобайт у них принят 1000 байт, строго по системе СИ (тот, другой килобайт, на самом деле с 1998г зовут кибибайт и обозначают KiB). Однако это не всё. Дело в том, что все выпускаемые шпиндельные диски имеют уже обнаруженные на фабрике дефекты, количество которых случайно, и потому фактический доступный размер «гуляет». У бюджетных моделей он гуляет даже в пределах одной партии одинаковых изделий, причем как в большую, так и в меньшую сторону. У меня в наборе из четырех одинаковых дисков номиналом 2Тб два оказались примерно на 2Гб меньше, а другие два – примерно на 400Мб больше номинального объема. Т.е. килобайт, подобно синусу в военное время, колеблется от 999 байт 6 бит до честных 1000 байтов даже с полубитом на конце. Либо изделия поставляют к нам на рынок на протекающих подводных лодках, либо наводнение виновато, но биты куда-то деваются.

Не стоит недооценивать данный фактор: если замена отказавшего диска в массиве окажется хоть на один блок короче номинального объема, то деградировавший RAID-массив теоретически может и не собраться до оптимального состояния, и мы получим головную боль, которую можно было легко избежать вначале. Исходя из этого, больше — не значит лучше, главное — постоянство.
Я предполагаю, что производители серверного оборудования решают эту проблему, всегда делая технологический запас и одновременно искусственно занижая объем доступного пространства в прошивке диска, поэтому по определенному коду изделия у них всегда (в пределах поддержки) можно получить диск, который имеет одну и ту же ёмкость. Наверное, это одна из причин, почему диск Seagate под известной серверной торговой маркой Харлампий-Панкрат и его «родной брат» без нее – не совсем одно и то же изделие. Но это только мое предположение. Возможно, у лидеров рынка хранения данных есть в рукаве и более технологичные козыри.

Риски проекта


В любом проекте важно понять риски, ведь в конечном итоге мы строим не ради забавы, но ради успеха бизнеса. Чтобы достичь гармонии Крепсондо (простите, непрерывности бизнеса), для начала мы построим упрощенную модель рисков, которая должна учитывать вероятные сбои и их последствия.

Аппаратные

По бюджету мы не имеем доступа к серверному оборудованию, поэтому и диски, и контроллеры можем использовать только дешевые, а это территория спонтанных отказов на ровном месте. К аппаратным рискам относим: механический износ (шпиндельные диски, вентиляторы), электрический износ (особенно касается флэш-памяти), ошибки в прошивках диска или контроллера, некачественный блок питания, некачественные диски, рассыпание аппаратного RAID-массива. Риском можно считать и отсутствие комплектующих запасного имущества прибора (ЗИП) в продаже вследствие устаревания.

Программные

К программным сбоям отнесем проблемы стандартных операционных систем, которые обладают склонностью к саморазрушению и не самой лучшей способностью к самовосстановлению после отказов питания, требуя регулярного администрирования. Добавим сюда ошибки реконструкции программного RAID-массива, ошибки в драйверах контроллеров, действия пользователей (намеренные и ненамеренные), действия вредоносного кода.

Имеющееся железо


Под рукой оказался мой старый компьютер примерно 2004г. выпуска на материнской плате Socket 478 GA-8IPE1000MK, с ЦП Pentium 4 @3ГГц и 1Гб ОЗУ. На корпусе написано ZEUS, он имеет целых шесть внутренних отсеков 3.5” (по тогдашним меркам это много), один 3.5” под архаичный FDD, четыре 5.25”, два места под вентиляторы охлаждения и блок питания на 250Вт. Видеокарта ATI RADEON 8500 в свое время рендерила такие хиты, как Soldiers of Anarchy, но ее вентилятор на масляном подшипнике уже давно воет, как собака Баскервилей (конечно, когда у него вообще получается вращение). Охлаждение ЦП было решено Zalman CNPS5700D-Cu, который затягивал нагретый воздух от радиатора и через эксцентричный воздуховод выдувал его внутрь корпуса, откуда его вновь приходилось выдувать наружу вторым вентилятором.

В один из дней мне настолько надоел весь этот аэродром, что я решил выпилить его в буквальном смысле: взял электропилу и вырезал круглое отверстие в корпусе (по решетке вентилятора), нарастив воздуховод куском пластиковой бутылки из-под минеральной воды Карма Дома. Убрал второй вентилятор и понизил первому (на ЦП) обороты реостатом.

В таком слегка панковском виде вся эта материальная часть и грустила на полке до наших дней.



Дополняла мою кунсткамеру дыра на задней панели корпуса из-за вольного трактования производителем корпуса стандартов ATX: вогнать туда панель-заглушку без напильника оказалось никак невозможно, и я оставил эти попытки.



Материнская плата имела контроллер ОЗУ, который не позволял менять планки в режиме STANDBY (это когда компьютер выключен кнопкой, но блок питания включен). Там даже светодиодный индикатор специальный выведен RAM_LED, задачей которого было предупреждать сисадмина о наличии напряжения в контуре:
When RAM_LED is ON, do not install / remove DIMM from socket

Конечно, в итоге контроллер накрылся; и если не пошевелить память в разъеме определенным шаманским образом, материнка ее не видела и начинала противно пищать. В справочнике писков данный сигнал мог означать как проблему ОЗУ, так и проблему блока питания, что окончательно сбивало с толку. Для довершения картины BIOS создавал какую-то особенно кривую среду при загрузке с флэшек, из-за чего у меня категорически не загружались все производные SYSLINUX (для справки: это почти безальтернативный загрузчик CD/флэшек для огромного количества вариантов Linux).
Так к чему я это всё?

Выводы:
  1. Такой компьютер для серверной задачи совершенно непригоден.
  2. Молодым сисадминам категорически противопоказан секс со старым железом.


Идеи


Замена железа

Конечно, глючная мать, изношенная механика и старый блок питания совершенно не укладываются в философию Крепсондо (ой, снова простите, непрерывность бизнеса), и потому подлежат замене в первую очередь и без лишних обсуждений. Гармония Крепсондо для нас важнее, поэтому попрощаемся со старым железом, оно свою историческую миссию выполнило.
Выбор замены для Socket 478 оказался невелик: ASRoсk P4i65G. Вроде бы неплохая мать с бортовой графикой, тремя PCI, двумя SATA и шестью USB на борту. Аппаратный мониторинг сделан на базе Winbond W83627 (поддерживается в пакете lm-sensors; это оказалось потом полезным при калибровке реостата вентилятора по температуре ЦП работающей системы).



Теперь ничего не пищит, загрузка с флэшек работает нормально, что уже радует. Бортовых ста мегабит для сети NAS маловато, поэтому один слот PCI сразу же занимаем бюджетным D-Link DGE-530T, еще два PCI оставляем на дисковые контроллеры. Обычно они имеют до четырех портов, что вместе с двумя бортовыми даст нам возможность подключить десять дисков.
Про новый блок питания я расскажу позже, пока лишь отмечу, что для моей системы на базе Socket 478 вполне хватало 250Вт. Поэтому, прикинув в уме запас мощности 200Вт на раскрутку шпиндельных дисков, я с ходу согласился на предложенный мне в магазине бюджетный источник FSP Group ATX-450PNR номиналом 450Вт. Поверхностно мне понравился большой низкооборотный 120мм вентилятор – значит, шуму будет меньше (UPD: забегая вперёд, ATX-450PNR, несмотря на все ухищрения, с поставленной задачей не справился, и я не рекомендую его использовать; см. habrahabr.ru/post/218387).



Заодно я прихватил пару вентиляторов Zalman ZM-F1-FDB на модном гидродинамическом подшипнике: первый пойдет на кулер ЦП, второй – на обдув первой группы дисков.
Собственно, осталось выбрать самое важное.

Дискововая подсистема


Для сетевого хранилища важнейшей задачей является выбор режима массива (RAID). Поскольку бюджет решения не позволяет нам воспользоваться серверным оборудованием, вздыхаем и сразу откладываем аппаратные RAID-контроллеры, SAS и прочие Fiber Channel в сторону. Туда же откладываем и твердотельные диски. Раз у нас на кухне NAS (простите за каламбур), то тернистый путь пройдет через волшебный мир программных решений RAID на базе дешевых шпиндельных дисков SATA. Так гораздо занимательнее, но да помогут нам практики Крепсондо.

Диски

На мой субъективный взгляд, у продуктов SATA (по сравнению с SAS/FC) с выбором всё еще более запутано и сильнее перемешано с маркетингом. У шпиндельных дисков Seagate я увидел два условных ценовых диапазона, которые отличаются примерно на 40%. Верхний принято считать решением для среднего бизнеса, а нижний – для домашних пользователей и малого бизнеса. Чем же грозит использование самых дешевых дисков? По субъективным оценкам некоторых экспертов (ссылка), дешевые диски отказывают ощутимо чаще дорогих в первую же неделю эксплуатации, и по результатам года тенденция сохраняется. Осторожно приведя здесь эту таблицу, повторю, что это очень приближенная субъективная оценка одного из пользователей Интернета, без указания конкретных изделий:

Технология Отказов в первую неделю Отказов в первый год
Fiber Channel 1 из 40 2 из 40
SAS 1 из 34 2 из 34
SATA дорогие 1 из 14 2-4 из 14
SATA дешевые 1 из 8 2-4 из 8


По наблюдению того же пользователя, примерно один-два из дюжины годовалых дисков SATA отказывают на втором году жизни. Само собой, все SATA ощутимо ведут себя хуже, чем SAS или Fiber Channel, с этим вряд ли можно спорить. Как, впрочем, и с выделенным бюджетом, который почти не оставляет нам выбора.

Производителя Seagate я выбрал достаточно интуитивно, поэтому не буду описывать данный процесс.

UPD:
Поскольку описанные события происходили летом 2013г, то я не прочитал вот этот замечательный пост: http://habrahabr.ru/post/209894/. Из него следует, что Seagate не самый лучший выбор, но читатель, безусловно, теперь предупрежден и вооружен. Благодарю, хаброкомьюнити, вы лучшие!

Бегло анализируя предложения в магазинах, я отметил, что цена бюджетных дисков крупного объема 4Тб почти на 90% выше предложений на 2Тб, т.е. удельная стоимость хранения гигабайта росла почти линейно от объема. Почему это так важно? Дело в том, что мне не удалось найти контроллер для шины PCI с гарантированной поддержкой накопителей 4Тб, а экспериментировать не было возможности. Это поставило перед непростым выбором: либо ограничить диски 2Тб, либо отказаться от старого железа и переходить на шину PCI Express (с покупкой нового компьютера). К счастью, почти линейная зависимость цены от ёмкости избавила от трудных решений, но читателю рекомендую всегда считать совокупную стоимость дисковой подсистемы, ибо в NAS она определяющая, и выгода от ёмких дисков может перевесить всё остальное.

Приглянулась своей ценой модель ST2000DM001. Это был самый бюджетный вариант в линейке Seagate на 2Тб, использует новый размер сектора 4Кб и требует правильной инициализации (форматирования) файловой системы. Интересно, что представители ST2000DM001 попадаются как с двумя, так и с тремя пластинами (на картинке — вариант с двумя).



Берем четыре штуки ST2000DM001 на 7200 об/мин, для начала хватит. Три купленных диска оказались с двумя пластинами (большее углубление на корпусе и третья литера серийного номера: E), а четвертый — с тремя (меньшее углубление на корпусе, третья литера серийного номера: F). Модификация дисков 1CH164, версия прошивки CC26. Не забываем, что мы имеем дело с дешевыми SATA-дисками, поэтому хотя бы обновляем прошивку до CC29.

Конечно, более приспособленным для нашей задачи является всё-таки представитель линейки NAS HDD ST2000VN000: данная модель обладает полезнейшим для массива ERC и работает на 5900 об/мин; можно ожидать, что диск меньше греется, дольше служит, да и разница в скорости вряд ли будет заметна в режиме сетевого хранилища.

UPD:
При выборе дисков для массива все-таки обязательно требуйте наличия ERC, читайте о нем здесь: habrahabr.ru/post/92701

Поначалу у модели ST2000DM001 сильно смутил параметр Power-On Hours 2400ч, но у Seagate это число часов работы в год, а не общее время жизни. Что ж, будем надеятся, что трети суток работы для малого бизнеса должно хватить. Можно уводить шпиндели в STANDBY по тайм-ауту, пожертвовав старт-стопами механики устройства. Оправдана ли такая экономия, покажет время.

Контроллер

Выбор винтажных контроллеров SATA для шины PCI оказался невелик. Я купил бюджетный 4-портовый STLab A-224 на базе Silicon Image SiI3114. Этот контроллер официально не поддерживает диски более 2.2Тб, хотя редкие пользователи на форумах утверждают обратное.



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

Несмотря на массу недостатков, у архаичного железа всё-таки есть одно существенное преимущество: драйверы, скорее всего, уже давно вшиты в ядра всех имеющихся в мире операционных систем, а за годы эксплуатации вытряхнуты почти все баги, причем как из драйверов, так и из прошивок самих контроллеров. Надеюсь, что в случае с A-224 так и есть, потому что прошивочные баги очень, очень опасны. Продавец, дайте два контроллера, пока они окончательно не исчезли из продаж.

Итого

Продукт Цена прибл., EUR Кол-во Стоимость, EUR
Мат. плата ASRock P4I65G 47 1 47
Контроллер STLab A-224 20 2 40
Диск ST2000DM001 76 4 304
Сетевой адаптер D-Link DGE-530T 8 1 8
Блок питания ATX 450PNR 32 1 32
Вентилятор Zalman ZM-F1-FDB 7 2 14
Флэш-память USB 8Гб 5 1 5
Кабели, переходники, термопаста и т.д. 10 - 10
ИТОГО 460


Оглядим еще раз нашу конструкцию. Простой, как шпала, контроллер в режиме JBOD наверняка не подведет. Четыре диска SATA третьего поколения моложе контроллера лет так на десять и выдают в среднем по пластине 150Мб/с (это больше, чем у всего PCI). Посему они выжмут из контроллера все соки, но это вряд ли будет сильно заметно по сети. Восстановление деградированного зеркала 2Тб займет от 8ч, это много, но не смертельно; на 4Тб было бы 16ч. Есть небыстрый процессор, немного ОЗУ, несколько портов USB, гигабитная сеть, полностью новая механика, свободные порты на контроллере, свободные отсеки в корпусе и запас электрической мощности. В бюджет по железу уложились, займемся софтом.

Выбор программного обеспечения


Из бесплатных систем хранения чаще всего упоминают FreeNAS, OpenMediaVault (OMV) и openfiler. У всех есть свои «фишки»: например, OMV очень скромен по требованиям, а openfiler имеет функцию удаленной репликации.

Посмотрим на проект FreeNAS на базе платформы FreeBSD. Для тех, кто не в курсе: «фришка» (как ее ласково называют) – это не Linux, а бесплатный классический UNIX имени Университета Беркли, Калифорния. Кстати, фришку можно считать дедушкой (бабушкой?) современной Mac OS X.

Почему FreeNAS? Главное преимущество FreeNAS состоит в том, что это бесплатный проект системы с промышленным дизайном, подобно гипервизору известной марки Вымой Варю загружаемый с малоразмерной флэшки. Что значит промышленный дизайн? FreeNAS монтирует корневую файловую систему флэшки в режиме read-only, а логи пишет в хранилище или в RAM-диск (не нашел такого режима ни в OMV, ни в openfiler). Это не только сбережет флэш-память от износа, но и неплохо защитит сервер от программных сбоев. Бесплатный FreeNAS реально воплотить в виде turnkey box, т.е. ящика с одной кнопкой ВКЛ. В соответствии с парадигмой Крепсондо это идеальное решение для бизнеса. Вспомним также про требования по поддержке клиентов рабочих станций Windows и Mac OS.
Отличная «фишка» FreeNAS — это фришные jail'ы (виртуальные машины-песочницы), в которых можно поднять Linux, а в нем уже почти все, что успел родить Open Source, без пересборки.

Но не стоит воспринимать FreeNAS как бюджетное решение. Акцент команда FreeNAS делает на развитие современной файловой системы ZFS. Это целая галактика технологий, но для нас первостепенное значение имеет ее прожорливость по ОЗУ: 8Гб памяти и, соответственно, 64-битная архитектура – это начало разговора для адекватной производительности на нашем объеме хранимых данных (ссылка1, ссылка2). Не спорю, ZFS можно завести на архитектуре i386 даже с 1Гб ОЗУ. Но несмотря на мои усилия, на старом железе даже в простых линейных операциях чтения/записи ZFS показала настолько отвратительную производительность, что я могу считать такой вариант лишь макетом системы, но не решением. Вдобавок к этому, на четырех дисках ZFS рекомендует использовать RAIDZ2, т.е. эффективный объем будет половинным (как в RAID1), но при этом требовать непомерного расхода ресурсов ЦП и ОЗУ. Спрашивается, а насколько вообще оправдан ZFS на четырех-то дисках? По идее, массив ZFS быстрее реконструируется, но есть один очень неприятный для нас фактор.

Основная проблема в том, что система ZFS очень чувствительна к ошибкам ОЗУ. Вот вывод экспертного исследования методической устойчивости ZFS к ошибкам ОЗУ, проведенного группой Yupu Zhang, Abhishek Rajimwale, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau из Университета Висконсин-Мэдисон (цитата из труда End-to-end Data Integrity for File Systems: A ZFS Case Study):
In the last section we showed the robustness of ZFS to disk corruptions. Although ZFS was not specifically designed to tolerate memory corruptions, we still would like to know how ZFS reacts to memory corruptions, i.e., whether ZFS can detect and recover from a single bit flip in data and metadata blocks. Our fault injection experiments indicate that ZFS has no precautions for memory corruptions: bad data blocks are returned to the user or written to disk, file system operations fail, and many times the whole system crashes.


Ого, как вам отказ всего массива на кучу ТБ из-за ошибки ОЗУ? Нет уж, спасибочки, мы адепты Крепсондо, подобные варианты видим заранее и насквозь. На новые планки памяти с контролем ошибок (ECC RAM) и новую серверную материнскую плату (а заодно: процессор, охлаждение, корпус, блок питания и т.д.) нашего бюджета точно не хватит. Поэтому без лишних сожалений откладываем ZFS в сторону. Хорошая технология, но без серверного железа — мина замедленного действия.

Вывод: если выбирать промышленный дизайн в стиле turnkey box, то это FreeNAS; если собирать на старом хламе, то это никак не ZFS; остается UFS на каркасе GEOM. Единственная проблема в том, что FreeNAS даже с UFS рекомендует минимум 2Гб ОЗУ, которых у нас нет. Это риск, но наша рабочая нагрузка будет совсем невелика.

Немного истории

Каркас geom(4) – это модульная подсистема обработки дисковых операций, разработанная примерно в 2003г. лабораторией безопасности Network Associates (McAfee) для проекта FreeBSD в рамках контракта с самим DARPA, alma mater всея Интернета. Т.е. с определенного угла GEOM можно считать неким дисковым родственником самого Интернета, «зашитым» в ядро UNIX стараниями программистов антивирусной лаборатории. Вот так коктейль.
Стоит вспомнить и о судьбе самого проекта FreeNAS, пережившего своего рода раздвоение личности (точнее, растроение, если считать упомянутый OMV на платформе Debian). Не углубляясь в подробности, на выходе имеем два очень похожих проекта: новый FreeNAS и старый, по юридическим причинам именуемый теперь NAS4free.

Похоже, новые владельцы проекта FreeNAS не пожалели сил на глубокий рефакторинг кода, который, вероятно, дался ценой отказа от некоторых «устаревших» функций (например, RAID5). Во всяком случае, FreeNAS выглядит сильным драйвером развития для FreeBSD, и заметен явный интерес к развитию ZFS во «фришном» ядре. Что ж, пожелаем удачи коллегам.

Если сравнивать FreeNAS и его предка-бранч NAS4free, то для меня субъективно FreeNAS выглядит сильнее, несмотря на отсутствие RAID5. Есть некое ощущение, которое непросто объяснить словами: сквозь графический интерфейс NAS4free так и веет запахом кода, требующего глубокого рефакторинга («кода с душком»). Так что же это за рефакторинг такой? Вот вам простой пример: в отличие от NAS4free, даже при работе с флэшки FreeNAS может применять изменения в конфигурации без полной перезагрузки системы. И это при том, что корневая система смонтирована в режиме read-only. Для меня это был сильный аргумент. К тому же FreeNAS перешел на хранение конфигурации в РСУБД SQlite, а NAS4free до сих пор использует простой, но не самый надежный формат XML.

RAID5 или не RAID5

Хотя UFS и софтверные RAID-массивы GEOM и не дотягивают по технологичности до ZFS с RAIDZ (на первый взгляд вообще кажется, что это соревнование набора шпал против вантового моста), но популярные режимы RAID0/1/5 в GEOM есть. Однако современный FreeNAS при этом не позволяет создавать тома RAID5, а для совместимости оставлены только простейшие режимы RAID0 (stripe) и RAID1 (зеркало).

Почему так?

На это, наверное, есть две причины, назовем их упрощенно: механическая и математическая (хотя в шпиндельных дисках они переплетены подобно корпускулярно-волновому дуализму).

Представим себе отказ/замену одного диска в массиве 10Тб спустя два года эксплуатации: процесс реконструкции в течение недели (!) будет мучить уже и так изношенные шпиндели (см. выше Миф о RAID5). Но при таком стрессе старые диски могут не протянуть и трех дней, повалив массив окончательно, вот тогда стресс начнется уже у нас, да еще какой.

Вы спросите: как же так, почему неделя на реконструкцию? Обратим взор на представителей двух поколений Seagate Barracuda (используем материалы http://www.storagereview.com):

Линейка Примерный год Ёмкость Ср. скорость чтения по пластине, Мб/с Полное чтение, ч Реконструкция RAID5
7200.9 2005 500Гб 50 ~02:45 очень долго
7200.14 2012 4Тб 150 ~07:25 запредельно долго


Если ёмкости выросли примерно в 8 раз, то скорости лишь троекратно. Ирония, правда, в том, что априорно мы можем представить тут скорость реконструкции RAID1, и даже такой быстрый вариант на нашем винтажном PCI-контроллере будет не ахти. В массивах же RAID5 скорость вообще определяется математическими способностями процессора, и по разным оценкам составляет порядка суток на каждый Тб данных (увы, ссылок дать не могу, простите).

Но и это еще не все, дорогой читатель. Диски имеют параметр, именуемый Unrecoverable Read Error Rate, который на современных бюджетных моделях SATA составляет 1 сектор на каждые сто триллионов битов. Т.е. примерно из каждых записанных 12Тб диск один раз скажет «прости, хозяин, но выдать обратно нужный сектор совершенно никак невозможно; ошибка чтения». Это методическая ошибка, заложенная производителем и потому теоретически гарантирующая невозможность реконструкции массива RAID5 емкостью более 12Тб на дешевых дисках (справедливости ради отметим, что URE на дисках SAS, как минимум, на порядок меньше, а критический объем, соответственно, больше). Эпитафию RAID5 написал Robin Harris в своей статье Why RAID 5 stops working in 2009.

По итогам выбора железа максимальная совокупная ёмкость наших дисков составляет 20Тб (18TiB), поэтому в очередной раз напомним себе о пути к непрерывности бизнеса через философские практики Крепсондо, вздохнем и дружно помянем RAID5.

Окончательный выбор: разборный массив

Итак, я отказываюсь и от аппаратных RAID (дорого), и от ZFS (дорого) и от софтверного RAID5 (медленно и ненадежно). Выбираю FreeNAS с томами UFS на базе технологий GEOM: просто, надежно и при необходимости ремонтируется, как автомат Калашникова. То, что надо.
Добавим USB флэшку для загрузки системы – шпиндельные диски целиком отведем для данных. Мы не хотим, чтобы торчащую снаружи загрузочную флэшку кто-то случайно выдернул, поэтому выбираем бюджетную флэшку с наименьшими габаритами (как потом выяснилось, это было роковое и необдуманное решение: http://habrahabr.ru/post/214803/).



Из вариантов Stripe и Mirror я выбираю, понятное дело, Mirror (т.е. RAID1). Итоговая дисковая система выглядит как набор из нескольких независимых томов-зеркал. Каждое зеркало собрано из пары дисков 2Тб (ограничение контроллера), инициализируется и монтируется независимо. Максимальный объем онлайн хранимых данных на десяти дисках составит около 10Тб в пяти независимых томах (точнее, 9TiB).

Хоть такой дизайн и может показаться несколько неуклюжим, но он действительно оправдан при наших объемах данных и количестве дисков: иначе мы бы получили неразборный монолит с запредельным временем реконструкции при отказах.

Добавим сюда один маленький штрих: поскольку используются дешевые потребительские диски, придется при создании томов искусственно занижать объем, чтобы не иметь потом проблем с заменой отказавших дисков новыми (с плавающей около 2Тб емкостью). Оставим в конце технологические «хвосты» для лучшего сна.

О пропускной способности вагона, груженого стриммерными кассетами

С точки зрения архивного хранения не стоит вообще расстраиваться по поводу ёмкости: массив-то у нас разборный. Исчерпав доступный объем хранимых данных на сервере онлайн в томах №№1-5, мы можем вручную отключить самый старый том №1, извлечь его диски, установить два новых диска по 2Тб и инициализировать новый том №6. Старые диски затем можно обуть в USB-конструктив и подключать по требованию бизнеса к тому же серверу FreeNAS, не разбирая при этом весь корпус. Можно их монтировать read-only. При большом желании можно подключить это и к Windows, и к Mac. В любом случае, помните: старый шпиндельный диск лучше по пустякам не трясти, а то от возраста посыплется магнитный песок из гермоблока.

Есть еще интересный сценарий с unionfs: заполненные тома переводить в режим для чтения и подкладывать «вниз» под файловую систему «верхнего» тома, тогда будет иллюзия непрерывности дискового пространства. Правда, unionfs — штука заумная и потому опасная, а вариант с read-only, наверное, единственный более-менее обкатанный.

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

Корпусная инженерия


Подумаем немного о первичном охлаждении, ибо диски наши на 7200rpm будут тепленькими. Находим в корпусе место для обдува отсеков 3.5” и с почти хирургическим трудом приспосабливаем туда наш вентилятор Zalman ZM-F1-FDB на антивибрационных резинках, которые приходится тянуть пальцами через тонкие щели корпуса. Черт бы побрал эти потребительские корпуса с их проходами и щелями…



Вспомнил старую комедию.
Солдата спрашивают: «Почему так плохо видишь?». Тот отвечает: «Ну, есть одна глазная операция, но ее делают через задний проход, а я туда ни одного мужика не подпущу»…

Эксцентрично-зеленый пластик бутылки из-под минеральной воды Карма Дома, торчащий сзади корпуса, уже порядком намозолил глаза. Поэтому разбираем кулер CNPS5700D-Cu, берем с собой воздуховод и идем в продуктовый магазин за покупками. Примерив по очереди бутылки с минеральной водой разных марок, убеждаемся в идеальном совпадении диаметров двухлитровой бутылки Звон Аква с круглой частью воздуховода CNPS5700D-Cu (на одном заводе их отливали что ли?).



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



Ставим в кулер новый вентилятор ZM-F1-FDB 80мм, его гидродинамические подшипники обладают сопоставимым ресурсом, но потише звонких шариковых. В последний момент, само собой, выясняется, что отверстие на корпусе находится на полсантиметра выше, чем надо, поэтому добавляем лепестковую юбку из клейкой ленты, идею которой подсказали авиаконструкторы истребителей с изменямым вектором тяги.





Наше изделие действительно чем-то смахивает на отклоняемое сопло, но выглядит уже не так по-панковски.



Наконец, пришло время разобраться с тем самым местом, где мне десять лет назад не удалось разгадать Великий Китайский Инженерный Замысел. Напомню, речь о задней панельке на разъемы ATX, идущей в комплекте с материнской платой, точнее, о невозможности ее установить вот в это гнездо:



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





Во избежание эффекта спагетти шнуры SATA прихватываем друг к другу стяжками, ибо макаронным изделиям в серверных корпусах не место. Кабели помечаем, используя маркеры для витой пары. Реостат вентилятора крепим к корпусу на оказавшейся очень к месту незанятой ножке для материнской платы. Старые диски пока стоят в корпусе для лучшей калибровки обдува, но скоро мы от них избавимся.





Руководствуясь опять же соображениями тепловой эффективности, массивы-зеркала из дисков будем собирать хотя бы через один отсек, т.е. так, чтобы диски одного массива не оказались соседями по отсекам и не грели друг друга, особенно на длинных операциях реконструкции. Диски также маркируем, хотя бы номером тома. UPD: лучше еще и серийный номер диска разместить, напечатав его на ленточном термопринтере, а при отсутствии оного просто на полоске бумаги под прозрачной клейкой лентой. Когда дисков больше двух, это бывает очень полезным при спешных и аварийных работах.



Осталось только включить питание, померять температуру и откалибровать реостаты вентиляторов под нагрузкой.

Питание

Про блок питания FSP Group ATX-450PNR отзываются скорее положительно, но недостатком считают (ссылка1, ссылка2) КПД кипятильника и архаичный дизайн в жанре минимализма (отсутствие корректора мощности). Преимущество – надежность (UPD: через полгода к надежности возникли вопросы) и относительно тихий низкооборотный 120мм вентилятор.
Пусковая мощность четырех шпинделей ST2000DM001 ожидается порядка 2.5А x 4 x 12В = 120Вт, что в сочетании с холодной архитектурой Pentium 4 без графики должно с запасом влезть в 250Вт.

Примечательно, что на тайваньском сайте FSP Group мне не удалось найти данный блок питания среди продуктов, но магазины в РФ ими явно не бедствовали. Возникло подозрение, что это специально удешевленный OEM-вариант для рынка СНГ, в котором оторвано всё, что только можно за счет низкого КПД. У нас ведь в стране долгие зимы и избыток электроэнергии, которую мы с удовольствием превращаем неэффективными приборами в уютное тепло домов и офисов.
Короче говоря, несмотря на КПД кипятильника, наш блок выдает пока примерно на 200Вт больше, чем требуется, что не может не радовать. Но есть нюанс, о котором мы напишем в следующих частях нашей истории…

Выводы


  1. Непропорциональный рост ёмкостей накопителей практически похоронил проверенные временем вещи типа RAID5.
  2. В борьбе за время реконструкции массива побеждают новые, высокотехнологичные файловые системы, но они реализуемы только на дорогом железе (из-за ECC памяти).
  3. Построение сервера на хламе было и остается риском; в такой ситуации побеждает рациональная простота, граничащая с примитивом (наподобие разборного массива зеркал).
  4. Архаичному железу — винтажные технологии, но в новой «промдизайнерской» упаковке.


Продолжение следует


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

UPD:
Все части истории про Ещё один NAS своими руками:
часть 1: из того, что было
часть 2: хорошие воспоминания (Флэш-память для загрузки FreeNAS и прочих embedded OS)
часть 3: приключения в старой башне
часть 4: призрак Чернобыля

Ссылки


End-to-end Data Integrity for File Systems: A ZFS Case Study by Yupu Zhang,
Abhishek Rajimwale, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau (Computer
Sciences Department, University of Wisconsin-Madison)

www.netapp.com
www.qnap.com
www.synology.com
www.openmediavault.org
www.openfiler.com
aws.amazon.com/glacier
www.freebsd.org
www.linux.org
sqlite.org
www.freenas.org
www.nas4free.org
forums.freenas.org/threads/what-number-of-drives-are-allowed-in-a-raidz-config.158/#post-38835
www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162
www.wikipedia.org/wiki/ZFS
wiki.freebsd.org/ZFSTuningGuide
doc.freenas.org/index.php/Hardware_Recommendations
hardforum.com/showthread.php?t=1689724
www.wikipedia.org/wiki/GEOM
www.freebsd.org/cgi/man.cgi?query=geom&sektion=4
www.wikipedia.org/wiki/Unix_File_System
www.asrock.com/mb/overview.asp?Model=P4i65G
www.lm-sensors.org/ticket/1865
www.fsp-power.ru/product/atx_450pnr
www.fsp-group.com.tw
article.techlabs.by/print/36_29785.html
www.wasp.kz/articles.php?article_id=465
www.computerhope.com/beep.htm
www.gigabyte.com/products/product-page.aspx?pid=1648
www.zalman.com/eng/product/Product_Read.php?Idx=266
www.zalman.com/eng/product/Product_Read.php?Idx=410
www.dlink.com/us/en/home-solutions/connect/adapters/dge-530t-dge-530t-32-bit-10-100-1000-base-t-pci-adapter
@teleghost
карма
60,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (114)

  • +17
    Вроде ничего принципиально нового не написано, но подход и стиль изложения не дают остаться равнодушным :)
  • +1
    Отлично написано, спасибо, однако осталась не раскрыта тема «провала» связанного с выбором дешевой микроскопической флешки.
    • +6
      vogel, тема с выбором флэшки для этого хозяйства требует отдельного поста; он немного провокационный, уже написан, но еще не опубликован. Я не заставлю себя долго ждать ;-)
    • 0
      vogel, мой пост про флэш-память, если не видели: habrahabr.ru/post/214803/
      • 0
        Прочитал в момент выхода. Спасибо большое ещё раз. Ваши статьи следует читать как минимум ради соблюдения принципа Крепсондо отличного слога!
        • 0
          благодарю:)
  • +2
    Данные по статистике смертности HDD на бОльших выборках можно посмотреть тут: olegart.ru/wordpress/ru/2010/12/08/3813/
    • 0
      bougakov, благодарю за ссылку. Если я правильно понял, там только кросс-вендорная статистика возвратов потребительских дисков, которые у меня обозначены «SATA дешевые». Т.е. автор не сравнивает между собой классы (SAS vs SATA), но сравнивает, в основном, производителей.

      Тем не менее Ваш коммент отчасти восполняет пробел в моем субъективном выборе Seagate :)
  • +7
    Извините за возможный оффтоп, но после упоминания Андрей Саныча Бахметьева я вообще ни на секунду не сомневался, что будут использованы пластиковые бутылки. И точно
    В один из дней мне настолько надоел весь этот аэродром, что я решил выпилить его в буквальном смысле: взял электропилу и вырезал круглое отверстие в корпусе (по решетке вентилятора), нарастив воздуховод куском пластиковой бутылки из-под минеральной воды Карма Дома.

    А вообще, передавайте ему привет при случае.
  • +2
    Странная статья, не менее странные фразы по ходу («В среднем, очередной пост про NAS появляется примерно раз в полгода, и рассказывает о том, как поставить систему по документации.» — да нет, все ок, пишут о реальных вещах, а не про хранение документации; «Эта статья не для специалистов по серверному хранению данных, геймеров и прочих оверклокеров. На вас, коллеги, и так вся индустрия работает. Она для начинающих сисадминов, любителей UNIX-систем и энтузиастов свободного программного обеспечения.» — Геймеры и прочие оверклокеры на которых работает индустрия по разработке для них NAS...). Ну да шут с ними с фразами, это я наверное придираюсь скорее. Статья объемная, но ничего нового нет, я думаю так же собирал бы NAS на базе старого компьютера любой из хабражителей, достаточно очевидные вещи.
    • +2
      sphinks, в компетенции хабражителей лично у меня вообще никаких сомнений нет, а вот нерезиденты этого почетного клуба и прочие хабрагости по-прежнему запускают сервера на десктопном железе с ZFS. Статья помещена в хаб «Старое Железо», на новизну не претендую:)
      • 0
        Действительно как-то по незнанию запускал ZFS на архаичном железе года четыре назад. Правда ошибку понял уже на второй день, потому-что пришлось много читать что-бы понять отчего оно всё настолько медленно работало. Хотя там было несколько запутанее: я в PCI запихнул ASC-39160 PCI-X (пришлось на материнке конденсатор даже выпаять и припаять с «ногами» потому как мешал он длинную карту вставить) и этот контролер ещё и работал, что только добавило медлительности. Так-что статья ещё как актуальная для тех у кого куча хлама в наличии и кто в первый раз собирается собрать хранилище.
  • +7
    > Ого, как вам отказ всего массива на кучу ТБ из-за ошибки ОЗУ?
    > Поэтому без лишних сожалений откладываем ZFS в сторону.

    Только вот другие ФС и софтрейды ровно также «was not specifically designed to tolerate memory corruptions» и им снесёт крышу от флипа бита абсолютно также вплоть до полной невозможности восстановить данные, а в статье это почему-то представлено как ZFS-специфичная проблема.

    Более того, именно ZFS благодаря чексуммам имеет все шансы обнаружить ошибку и не допустить битые данные до пользователя (а обнаружение ошибок скорее всего и является причиной «file system operations fail, and many times the whole system crashes», и именно это должно происходить при повреждении памяти вместо «тихого» чтения мусора вместо данных и повреждения ФС), а благодаря версионной архитектуре даже при повреждении данных на дисках в теории откатиться до рабочего состояния.

    Мне посчастливилось словить не просто bit flip, а полноценно битую планку памяти сыпавшую мусором, и у меня есть основания полагать что только благодаря ZFS данные на дисках остались в сохранности — более того, после scrub я это знаю точно.

    Касательно geom mirror — насколько я помню, оно очень любило разваливаться после перезагрузки по питанию, после чего восстанавливалось полным копированием одного диска на другой с очевидными последствиями для производительности и надёжности.
    • 0
      AMDmi3, благодарю за критику, именно такие комменты меня интересуют в данный момент. Специфика моих данных позволяет немного расслабиться по одиночным ошибкам, лишь бы не крякнулся весь массив (у меня он разборный). Про ZFS я увидел явное указание на возможный отказ всего массива, но отложил ZFS в основном из-за ОЗУ. Про UFS / GEOM такого же красного флага не увидел, если не лень, дайте, пожалуйста, ссылку. И очень рад, что Вас спас высокотехнологичный вантовый мост, дай Бог каждому. Отказы geom mirror на сбросе питания — согласен, фигово и медленно, но шпалу переложить проще, чем заново натянуть вантовый мост:)
      • 0
        > Про UFS / GEOM такого же красного флага не увидел, если не лень, дайте, пожалуйста, ссылку

        Это должно быть очевидно и без флагов — повреждение памяти всегда приводит к непредсказуемым последствиям, независимо от ФС они могут стать фатальными. А вообще в том же исследовании есть глава 7 Beyond ZFS где в двух словах описывется такой же эксперимент с ext2 которую можно считать относительно близкой к UFS по структуре.

        > Отказы geom mirror на сбросе питания — согласен, фигово и медленно, но шпалу переложить проще, чем заново натянуть вантовый мост:)

        С одной стороны, вы пишете про «миф о RAID5» и связанную с ним опасность, с другой полная пересборка зеркала вас устраивает. Как-то это нелогично.
        • +1
          вижу, что на пост пришел таки специалист по хранению данных:) Давайте подумаем вместе.

          Вероятность второго механического отказа при реконструкции RAID5 сопоставима с моим разборным массивом из N томов-зеркал (RAID1), если все мои зеркала уходят в длинную реконструкцию («плохой» отказ по питанию? замена половины дисков сразу?). Однако даже в таком случае второй отказ диска губит только одно зеркало из N, а не всех. Да и почему обязательно должен отказать второй диск в той же паре? Вероятно, но мало.

          Другая опасность RAID5 — это проявление URE на дешевых монолитных томах около 12Тб и далее. В моем случае есть теоретически обоснованная устойчивость к URE, потому что размер каждого тома весьма далек от критической отметки.

          Наконец, скорость. Мой разборный массив из зеркал ограничен по скорости восстановления шиной PCI, а вот насчет RAID5 я уже совсем не уверен. Интуитивно это будет еще в два-три раза медленнее. Ваша оценка? Сколько Тб в сутки соберет RAID5 на том хламе, который я использовал?

          Не забываем про разборность и оффлайн хранение, это не монолитный RAID5. А что в ZFS? Там можно заданный Бизнесом кусок файловой системы отправить в оффлайн (отключить и убрать в шкаф данные за 2012 год)? Кажется, что-то такое было, но не совсем в моей постановке задачи. Расскажите, если знаете.

          В целом ремонтопригодность у UFS / GEOM RAID1 считаю ощутимо выше, чем у RAID5 и у ZFS, особенно какими-нибудь попавшими под руку утилитами, ибо себя к суперспецам по восстановлению не отношу. Отказ технологичной ZFS меня пугает невозможностью вообще что-то предпринять. Мне нужен автомат Калашникова в сфере хранения данных, легкоразборный, ремонтопригодный, и без требований по ОЗУ (у меня его просто не было по экономическим причинам, о чем я уже говорил).
          • +2
            > вижу, что на пост пришел таки специалист по хранению данных:) Давайте подумаем вместе.

            Я далеко не специалист по хранению данных, но 2 и 2 сложить могу.

            > Вероятность второго механического отказа при реконструкции RAID5 сопоставима с моим разборным массивом из N томов-зеркал

            Пусть вероятность выхода из строя диска при штатном использовании — p, вероятность выхода из строя при нагрузке возникающей при ребилде — P. Тогда с RAID5 вероятность потерять данные составит ~ p * (Nдисков-1) * P (навернулся один диск + навернулся второй при ребилде). С зеркалами это будет P * Nзеркал * Nребутов (считаем worst-case, т.е. все зеркала перестраиваются при ребуте) — напомню что когда gmirror перестраивается это по сути один диск без какой-либо избыточности, зато под нагрузкой. Не берусь считать какая вероятность больше и насколько, но игнорировать вторую никак нельзя. Потерю лишь части данных я за плюс не считаю — это всё равно потеря данных.

            > В моем случае есть теоретически обоснованная устойчивость к URE

            Обоснованная чем? Устойчивости к URE быть не может — если есть вероятность не прочитать блок то рано или поздно он не будет прочитан, если в этот момент не будет избыточности то ой.

            > Наконец, скорость
            > Не забываем про разборность и оффлайн хранение

            Я замечу что агитирую не за «RAID5 вместо зеркала» а всего лишь за «RAID который не пересобирается целиком при ребуте». ZFS умеет и зеркало и несколько независимых массивов — соответственно ни со скоростью ни с отключением отдельных зеркал проблем не имеет, даже наоборот — можно воткнуть новый диск, переехать половину зеркала на него без уменьшения избыточности, а старую половинку убрать в архив, с возможностью восстановить зеркало из неё. Да и на raidz (RAID5) проблем со скоростью я лично не ощущаю — у меня 16T raidz2 (с двойной чётностью) на ST3000VX000-1CU166 даёт 300MB/s линейного чтения в обычном состоянии и почему-то 350MB/s в degraded без одного диска — в любом случае этого хватит чтобы записать новый диск на полной скорости.

            > В целом ремонтопригодность у UFS / GEOM RAID1 считаю ощутимо выше, чем у RAID5 и у ZFS

            Тут я соглашусь, учитывая простоту UFS, количество и обкатанность утилит. Однако целесообразней мне всё равно видится выбор ФС которая с большей вероятностью не потребует «ремонта» + бэкапы важных данных. А так у zfs есть утлита zdb — если совсем припечёт всегда можно расковырять том ей.
            • 0
              > Потерю лишь части данных я за плюс не считаю — это всё равно потеря данных.
              Как правило при таких требованиях к железу и таком бюджете на хранение, данные не являются логически цельными. А судя по бюджету их критичность для бизнеса так себе.
              Тут стоит предположить что потеря одного письма из архива писем будет несущественна ибо наверняка информация продублирована в «FW:» и «RE: RE: RE». Кроме того такие системы строятся по принципу «чтобы було тут рядом», ибо примонтировать диск с архивом в NAS за пятьсот американских рублей гораздо дешевле, чем бежать в бумажный архив. И если из полумилиона файлов один не откроется… ну велика беда… А вот если не откроется все — то грош цена такому NAS.
              Все определяется стоимостью и задачей. В том числе и критерий «надежность».
              • 0
                Это всё понятно, но я всё же вижу противоречия и не вижу логики. RAID делается, значит наверное данные важные, бэкапы не делаются, значит наверное не важные. Затрагивается тема bit flip, значит наверное пипец какие важные, однако потом выясняется что периоды когда зеркало находится без избыточности и потеря одного зеркала из нескольких некритична. Вполне возможно что raid тут и не нужен совсем, а диски можно было пустить под бэкапы.

                А касательно потери информации, речь как-бы идёт не об одном файле из полумиллиона, а о значительной части — половине или трети. Толку будет от того что потеряно не всё, если именно то что нужно в данный конкретный момент потеряно?
                • 0
                  AMDmi3, и дай Вам Бог никогда не решать противоречивые задачи со взаимоисключающими условиями:) Ну будто Вы не знаете, как в реальности приходится проталкиваться через технико-экономические щели и коридоры требований заказчиков. «Сделайте это, и вот это, и вон то, но вот за столько-то». Я вот свой математический максимализм убрал давно в п… портмоне, просто надо риски взвешивать и сопоставлять с бюджетом. Малый бизнес-стартап и домашний NAS, тут полно таких.

                  Как только будет реально надо, перейдем на серверное железо с ZFS или чем еще, будем тут тоже рисовать красивые комменты «у меня массив X терабайт на RAIDZN выдает почему-то 100000000Мб/с, хотя должен 999999999» :)))

                  Это не запись орбитальных экспериментов за год, это файловый архив, воспринимайте его как набор сменных дисковых картриджей. Потеряли один — посчитаем, сколько стоит восстановить, сравним со стоимостью данных и примем решение. Два из пяти потеряем вряд ли.

                  За комменты в любом случае спасибо, которое я выразил Вам в +1, но предлагаю уже не мусолить дальше эту тему, хотите, перейдем в личку…

                  FYR, европейских рублей, а не американских:)
    • 0
      Не полным, оно умеет восстанавливать только рассинхронизированное.
      • +1
        Увы, всегда наблюдал только полную синхронизацию.
        • +1
          Кстати, да. Я тоже. Слышал, что умеет частично восстанавливаться (что логично), но всегда видел только полную ресинхронизацию. Может быть кто-то подобные счастье видел или знает как получить?
          • 0
            у меня после отказа питания где-то через полчаса все тома gmirror были уже оптимальные
            полная синхронизация за такое время на моем железе невозможна
            какой вывод?
            • 0
              А они вообще были degraded? Журнал используется? До этого в каком они состоянии были?

              Факт в том что чтобы знать что синхронизировать на диске как минимум должны храниться метаданные о поколении каждого блока, а их нет — метаданные gmirror занимают всего один сектор. Как я понял из беглого чтения исходников gmirror, всё что он умеет — запоминать сколько данных синхронизировано, поэтому если перезагрузиться в процессе ресинхронизации она продолжится с того же места на котором прервалась. Но если при перезагрузке у дисков не совпали syncid (число, увеличивающееся при каждой записи и хранящееся в том самом секторе с метаданными), что очень вероятно после «грязной» перезагрузки (один диск записал этот сектор, второй не успел), диск с меньшим syncid будет синхронизирован полностью.
  • +1
    > резервной копии нет (объемы слишком велики)

    и далее ни слова про резервную копию.
    RAID != резервная копия.
    • 0
      fifonik, абсолютно согласен, что RAID != backup, но объемчики у нас на LTO6, а бюджет при этом малого бизнеса, экономический конфликт:)
      • +1
        Проектировать систему хранения данных без обдумывания (заранее) системы резервного копирования — нельзя.

        P.S. Если что, у меня дома и RAID5 и резервное копирование, т.к. я считаю свои данные ценными.
        • +1
          все верно, коллега, порекомендуйте, пожалуйста, чем спасать 6-10Тб данных? предприятия покупают упомянутый стриммер LTO6, там начало разговора где-то у 100,000руб. без картриджей.

          Лично мне тут в голову не приходит ничего, кроме дешевых дисков SATA уже на 4Тб в USB-конструктиве.
          • 0
            Дешёвые диски, но зачем USB? Также понатыкать, но добавить автоматическое размонтирование на время между бэкапами, чтобы избежать вероятности катастрофических для всех системы одномоментных отказов. Можно даже в спячку укладывать между бэкапами (правда, вроде как, все серьёзные «облачники» говорят, что бездействующий вращающийся диск живёт дольше, чем спящий.)
            • 0
              Диски бэкапа нужно держать в отдельной машине. И очень желательно — в помещении подальше, работающем от другого ввода по питанию. Иначе серьёзный отказ блока питания или скачок напряжения — и нету ни данных, ни бэкапа.
          • 0
            У меня нет решения, как это реализовать за «три копейки».
            Однако я уверен, что в случае возникновения проблем при отсутствии резервного копирования, восстановление данных (даже если оно будет успешным) обойдётся дороже (время/работа).
            Т.е. моё «решение»: донести таки до тех, кто выделяет средства, что это необходимо, а потому денег на реализацию требуется больше. И потом спокойно спать.
  • +3
    И думаю не лишним будет в очередной раз привести ссылку на пост про SCT Error Recovery Control (http://habrahabr.ru/post/92701/) который стоит иметь в виду при настройке RAID'ов дабы обеспечить адекватное поведение массива при появлении битых секторов на одном из дисков.

    Добавлю что в портах FreeBSD есть скрипт (http://www.freshports.org/sysutils/scterc) который позволяет настроить ERC на дисках при загрузке системы (сами по себе диски не сохраняют настройки ERC между перезагрузками).
    • 0
      полностью согласен, коллега:
      Конечно, более приспособленным для нашей задачи является всё-таки представитель линейки NAS HDD ST2000VN000: данная модель обладает полезнейшим для массива ERC...

      наверное, стоило выделить полужирным
      • 0
        Мне казалось что наличие ERC в современных дисках — уже правило. Хотя это мнение основано на нерепрезентативной выборке, но в обычных десктопных сигейтах ~пятилетней давности ERC уже был. Кроме того, основной смысл — в его правильной настройке, критерием для которой является только факт использования диска в массиве с избыточностью.
        • 0
          увы, Seagate, начисто выпилил ERC в модели ST2000DM001 (слоган «Seagate Desktop HDD: сила одиночки»); если кто вдруг его там найдет, порадуйте меня
  • 0
    А теперь поехали сложные вопросы.

    Как выбирается «пара» для записи? Запись синхронная или асинхронная? Если асинхронная, что делать при падении ноды, если синхронная, как защищаются от перегрузки спары? Парность полная (сервер-сервер) или блочная (а-ля ceph)? Какое latency на запись при трёх нодах и latency ethernet'а в 100µs?

    Предположим, что всё железо работает исправно. Какая надёжность системы в этой конфигурации?
    • +2
      amarao, там старый PCI и около 100Мбайт/с по шине на всех, включая Gigabit Ethernet, так что на сложные вопросы вынужден дать простой ответ: все довольно медленно (что-то около 30Мб/с на линейной записи), но зато относительно надежно и дешево. Для малой рабочей группы хватает.

      Пара — это том gmirror(8), который монтируется на свою папку. Про режимы управления записью см. фришные доки. Я в стартовых скриптах в итоге применил mount_nullfs(8), чтобы выглядело понятнее для пользователей. Понятное дело, что при таких делах еще пришлось дурить самбу по свободному месту, применил опцию dfree command из smb.conf(5).

      В итоге для пользователей это выглядит примерно так:
      \\NAS\SHARE\
      \\NAS\SHARE\X1
      \\NAS\SHARE\X2
      \\NAS\SHARE\X3


      На все остальные вопросы про спары, latency и прочее мне пытаться ответить или можно не мучиться? Я просто не уверен, что все слова понял в Вашем вопросе:)
      • +5
        Чёрт. Это вопросы были в соседний топик про «типа революция в SAN». К вам никаких вопросов нет, извините.
        • +5
          А удачно получилось.
  • +1
    В пределах 200 евро можно было купить HP MicroServer из серии n36l/n40l/n54l и за 300 евро туда добавить 4 HDD. Мне такое решение кажется получше чем ваше. Туда за пару евро добавить usb flash и установить её во внутрь. На неё же поставить freeNAS
    • 0
      Kwull, хороший вариант, и я люблю запах нового железа, особенно утром:) Хотя диски можно брать и по 4Тб, но оставаться с 4 шпинделями при таких апетитах, как у моего заказчика, показалось несколько рискованным, и железо старое хотелось пристроить.
      но читателю рекомендую всегда считать совокупную стоимость дисковой подсистемы, ибо в NAS она определяющая, и выгода от ёмких дисков может перевесить всё остальное.

      Если бы знал про n36l, правда, подумал бы дважды. Кстати, а что там у него в качестве SATA контроллера? На этом FreeNAS работает? Прошивка не глючная?

      флэшку только не вздумайте покупать за пару евро:), я об этом расскажу вскоре, спасибо, коллега
      • 0
        про флэшку я образно :)
      • 0
        По поводу железа есть очень хорошее n40l вики. Железо почти одинаковое что у n36l, что у n40l. FreeNAS работает
      • +1
        На самом деле, там есть место под 5-й диск, вместо дисковода. Мы так и сделали и на него накатили Nas4free (о чем сожалеть пришлось).
        • 0
          На самом деле там есть еще много места ;)
        • 0
          121212121, если не затруднит, можно подробнее? Догадка: 5-й диск отказал из-за того, что старый шпиндель был?
          • +1
            Ой, извините, только сейчас вопрос заметил.
            Нет, дело было не в железке, а в программе sourceforge.net/p/nas4free/bugs/143/
            • 0
              Писец какой
            • 0
              Отличный баг! Да, это старый релиз 2013, но у кого-то эта версия может использоваться. Будьте внимательны!
              Извините, не могу удержаться:
              Renaming the SMB share (server) name removes all the share contents.
              NAS4Free version — 9.1.0.1 2013-08-18 installed to dedicated hard drive.

              Steps to reproduce:
              1. Create ZFS Raid1 array.
              2. Enable CIFS/SMB, fill Samba server name and use created ZFS volume as Samba share.
              3. Copy noticeable amount of test data over the network to the created Samba share.
              Check the monitor — it reports some drive space is in use.
              Check the Samba mount point contents (use console) — copied files are in place.
              4. Go to CIFS/SMB settings and change the Samba server name and workgroup. Save changes
              5. At this point Samba share appears to be re-created from scratch.
              All the contents of the previous share is lost without any warning.
              Check the mount point contents with console one more time — it is now empty.
              каково, а?
              • 0
                Да я сам охренел, поэтому и зарепортил сразу.
                Реакция нулевая, кстати. Проект не подает признаков жизни.
                Это и неудивительно, читая историю NAS4Free пришел к выводу, что после форка его никто не развивает.
                Volker Theile занимается OpenMediaVault, а сообщества не осталось в NAS4Free.
                Ну оно есть, но только из потребителей контента, в основном, мало кто вкладывает силы в его разработку.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    > Пока ничего страшного, ставим новый диск, и что происходит? Ага, реконструкция массива, т.е. длительная максимальная нагрузка на уже порядком изношенные диски.

    Кто вам запрещает понизить эту «максимальную» нагрузку хоть до 100КБ/с?
    • 0
      Может быть время? На полной скорости пусть будет 8 часов, а на 100кб/с? Однако, ценную информацию лучше считывать неделю, чем потерять совсем.
  • 0
    Disasm, при всем уважении вычитка 2Тб на такой скорости займет примерно 230 дней :))
    Да и корень проблемы механический, головки там скачут туда-сюда и все в таком духе. А сколько по проводу бит пройдет — уже не так важно.
  • 0
    Отличная статья, пригодится. Жду продолжения
  • +1
    Отличная статья! Вы сэкономили мне время на раздумья о raid и zfs ))
    Сейчас занимаюсь чем-то похожим: собрал сервер из старья. Процессор AMD x64 на 1800 MHz и 512 Mb памяти. Пришлось купить видеоплату, чтобы хоть как-то настроить параметры БИОС. Но она пригодилась потом — воткнул в стационарный ПК вместо интегрированной. Через неделю работы посыпался жесткий диск, который до этого 4 года стоял на стационаре (Seagate sata 250 gb). Так что пришлось еще докупить новый диск — взял ST250DM000. И заменил блок питания как раз на такой же, как у вас (старый был на 250ватт). На сервере FreeBSD 9, поднята вики, для нее апач, mysql. Далее будет работать, как самописный сервер игровой логики на erlang, riak, с++. Хранения больших объемов данных не предполагается, поэтому железка должна справиться. Однако, посчитав затраты за две недели его работы и найдя на авито б/у серверы 1u в москве, начал сомневаться в своем выборе.
    После падения данные сумел восстановить, но на перенастройку ушло 6 часов. Как только у меня в руках появится любой диск, настрою на него бэкап через dump. Для себя, с моими объемами, считаю, что лучше 1 диск и бэкап на другое устройство, чем зеркало. В случае падения основного диска будет установлен новый с неведомым размером но с нулевым ресурсом. Если менять один диск в зеркале, то второй будет старым.
    • 0
      Спасибо.

      Не ставьте старые диски в только что собранные серверы, они накрываются (к счастью, довольно быстро, но все равно не сразу:). Я опубликую короткую заметку на тему отказов.

      Б/У серверы, конечно, риск, но там есть ECC-память, и я видел один ролик, где слегка нестриженный хлопец переделал DL380G5 под SATA, выпилив (буквально) пластиковые салазки и поработав с паяльником над блоком питания. По странному стечению обстоятельств он использовал тот же PCI контроллер A-224. Старый или Б/У сервер — один из вариантов под объемное, но не самое критичное хранение. Обязательно используйте ECC-память, лучше много, тогда можно и ZFS. Мне кажется, что из БУ лучше какой-нибудь Харлампий-Панкрат, но всю механику очень желательно заменить.

      Помимо того, что сейчас лежит в черновиках, у меня будет еще (я надеюсь) через какое-то время пост про «безголовый» режим и serial console поверх IP. Я хочу попробовать себя немного в жанре пром. электроники, изготовив простой бортовой контроллер: http://toster.ru/q/71632
      • 0
        У меня сейчас как раз безголовый режим, видеоплаты нет, клавиатуры нет. Хожу но ssh. Нульмодем присоединил, но пока не разобрался, как настроить выдачу ядра на com. С интересом почитаю, если будет написано применительно к FreeBSD.
        • 0
          UA3MQJ, для FreeBSD есть хотя бы вот это: http://www.freebsd.org/doc/handbook/serialconsole-setup.html. Наверное, я немного добавлю соли с перцем в своем будущем посте.

          У фришки вся эта история делится условно на три фазы (boot.config, loader.conf и прочий userland output), причем первые две дублируются при желании на VGA и в RS232, но самое интересное (userland output с матюками fsck и требованием вмешаться) выдается только в одно место. И чтобы этим местом был RS232, надо сказать в loader.conf

          console="comconsole,vidconsole"

          признаюсь, это очень компактное объяснение, но мы его можем потом развить.
          вероятно, что с ZFS fsck работает по-другому.

          вообще, очень рекомендую использовать для экспериментов систему виртуализации Вымой Варю. Например, Workstation. Я вот запустил там FreeNAS (можно и голую фришку), выведя аж два виртуальных COM-порта через файл-сокет на хост Windows и «поймав» их прямо в putty. Долго недоумевал, почему fsck говорит со мной на VGA, сколько я ни стараюсь. Разобрался в итоге (см. выше).
          • 0
            У ZFS нет fsck в принципе. Да он не нужен, потому что система отслеживает целостность данных «на лету».
            • 0
              виноват, вместо fsck прошу читать «проверка файловой системы», да, это действительно совсем по-другому, чем fsck
      • 0
        переделал DL380G5 под SATA

        Что-то я не понял — у него 380G5 был без RAID контроллера вообще? Родные P200/400 умеют SATA диски кушать.
        • 0
          NickyX3, не только Вы так считаете :) см. комментарий пользователя PLRtx: all-kvn.ru/video?watch=WW8xNFFUSFF1a2M=

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

          на всякий случай прямая ссылка на видео youtu.be/Yo14QTHQukc
  • 0
    Посмотрел на ваши обозначения на дисках… Я в таких ситуациях клею на них серийный номер диска. Чтобы виден был без его вынимания. Потом проблемы какие — скажем, один диск не определяется — смотрим из системы серийники тех, что определяются, и методом исключения вынимаем сдохший.

    Пару раз это даже помогало.
    • 0
      Да, серийники у них на спинах гермоблоков, и всегда скрыты соседями по отсекам. В документации я всех пишу по серийникам, вот только как их лепить? Ленточный термопринтер? Простой скотч с бумажкой? Пожалуй, это вариант, с торца видеть точно удобнее.
      • 0
        Ленточный термопринтер. Но вообще, любой способ.
  • 0
    Интересное предложение:
    «Отличная «фишка» FreeNAS — это фришные jail'ы (виртуальные машины-песочницы), в которых можно поднять Linux, а в нем уже почти все, что успел родить Open Source.»
    Удивился. Погугулил, но не понял как это сделать. Не подскажите?
    • 0
      RuJet, фича появилась буквально недавно, кажется, в 9.2, и фактически сорвала пробку, под которой сидело море всяких утилит для работы с файлами и облачными хранилищами, полезных и бесполезных.

      Добавляем Jail типа Linux (выбрав нужный диалект), надо только сначала указать один из томов хранилища, где все это будет лежать. FreeNAS некоторое время загружает образ файловой системы (интерфейс GUI может при этом тупить, потерпите). Потом с помощью того же mount_nullfs(8) инжектируем в jail нужную папку нашего хранилища. Ну а дальше насколько фантазии хватит. Можно поставить клиента облачного сервиса Брось Бокс, ибо под Linux (в отличие от FreeBSD) их как грязи, по-моему. Можно торрент-качалку. Можно анализатор EXIF-тегов. Можно антивирус. Можно сборщик мусора. Да все, что хотите:)
    • 0
      Процитированная фраза некорректна. Во-первых, jail это не виртуальная машина (песочница — да, аналог chroot). Во-вторых, «всё что успел родить Open Source» можно нативно запустить на FreeBSD.
      А касательно вопроса — достаточно сделать chroot/jail в директорию куда распакован/смонтирован Linux дистрибутив — благодаря бинарной совместимости внутри этого chroot будут работать исполняемые файлы Linux в родном для них окружении. Подробнее: www.freebsd.org/doc/en/books/handbook/linuxemu.html

      У этой совместимости есть свои ограничения — в частности, она довольно сильно отстала от оригинала, поэтому заработают только бинарники под достаточно старые версии ядра. В дереве портов есть рабочие «linux base» окружения от Fedora 10 и CentOS 6 — можно играться с ними.
      • 0
        AMDmi3, я так понял, Вас не устраивает термин виртуализация по отношению к запуску chroot-окружения с использованием бинарной совместимости. Хотя формально Вы правы, я обычно не цепляюсь к термину виртуальная, у него может быть ну очень широкое трактование. К тому же, что такое виртуальная машина, знают многие. А вот что такое песочница и chroot, то м.б. и не все резиденты хабра. Но я все равно поправлю:)

        At this time, the Linux distro must be a 32-bit version and any applications installed into the jail must be available as a 32-bit binary.

        и в уже означенной документации FreeNAS ссылка стоит почти туда же (она битая, ха-ха: www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu.html), т.е. http://www.freebsd.org/doc/en/books/handbook/linuxemu.html.

        Собственно, команда FreeNAS и поддерживает хранилище деревьев для разных систем и диалектов Linux (называется просто Jail Template), и тут чертик подставляет пингвинчику плечо, а не ногу или другую часть тела. В 9.2.0 ссылки на шаблоны видны прямо в GUI, можно свои использовать при необходимости. Вот, например, CentOS: cdn.freenas.org/9.2.0/RELEASE/x86/jails/linux-centos-6.4.tgz
  • +2
    странно, так обстоятельно выбирали диск, но не поинтересовались статистикой отказов по брендам. Seagate худшие диски по надежности. Подтверждаю личным обытом.
    • 0
      dts, очень, очень ценная ссылка! Если бы ее можно было прочитать летом 2013 года, не факт, что я бы выбрал Seagate.
      Вклеиваю в пост прямо сейчас.
      • 0
        я вообще видел несколько постов с подобной статистикой, почему-то посты былых времен не находятся. Вот, например, этот пост точно на хабре был когда-то.
        • +1
          Ну так качество дисков меняется со временем. В детстве, помню, Quantum Fireball дохли от первого скачка напряжения, WDшки просто дохли, а Seagate были столпом надёжности. А про диски hitachi тогда никто и не слышал. А ещё были «дятлы» — IBM серии DTLA, которые при работе стучали как дятлы, были капризны к питанию, но вообще так надёжные (не дохли, в отличие от квантумов).

          А если вспомнить ещё более ранние времена — у меня был такой диск на 210 мегабайт — его смерти я в итоге не увидел, он был кому-то подарен, а перед этим прожил у нас лет десять — сначала как системный 386-м, потом как резервный в pentum 120, а потом как дискета.

          Так что да, статистика меняется, это нормально.
    • 0
      Подтверждаю. В середине 2012 г. купили 12 x ST3000DM001 для NAS, через год использования начали сыпаться один за другим, к данному моменту заменили уже половину.
      • 0
        да, для массива они плохой выбор, но я это понял уже потом.
        на всякий случай: прошивой firmware никак не лечилось?
        • 0
          Краем уха слышал, что лечится, но смогу попробовать только через месяц.
  • 0
    Память нынче столь дешева, что это не самый дорогой ресурс в NAS. Зато ZFS вы легко ускорите в дальнейшем, добавив SSD как кеш и под ZIL.
    • 0
      Лучше два SSD под ZIL :)
      • 0
        Я образно ) Именно в плане того, что вложений в SSD на старте не требуется, если уже бюджет экономить.

        Два небольших в страйп под L2ARC, два небольших серверного класса в зеркало под ZIL — это явно не дороже, чем ставить десяток enterprise-класса «шпинделей».

        Опять же, ZFS неплохо себя умеет проверять и лечить.
  • 0
    У Вас там куча SATA на одном PCI. PCI «качает» не более 133 МБ/c максимум в теории. Вопрос, сколько дисков SATA с пропускной способностью 80..120 МБ/с сможет обслужить такой контроллер?
    Оно будет очень странно работать в смысле скорости.
    • 0
      Почитал комментарии — Вас 30 МБ/с устраивает. Но у меня хуже получалось — когда 100% загрузка дисков оно совсем затыкалось (скорость падала до ~ 10 МБ/с). Такого нет?
      • 0
        в малой рабочей группе длительную загрузку просто некому создавать

        а во время реконструкции все довольно грустно, само собой:)
  • 0
    Как-то думал по поводу NAS. Тоже есть железо свободное… Меня только смущает всегда один факт — потребляемая мощность. В итоге получается, что если рассчитывать БП (а еще с учетом отношения жручесть/производительность старого железа в плане «а там еще думаю вебсервер накинуть и возможно еще X, но пентиум не потянет в связке с X, без провисания при одновременной нагрузке на собственно NAS-часть и X, а не охота две железки держать включенными постоянно») и разницу в оплате электроэнергии скажем за год (или больше), задумываюсь о том, что лучше я куплю железо поновее с меньшим энергопотреблением и поставлю БП послабее — за год может и окупиться, если работать будет постоянно. Да еще эти соцнормы…
    Иногда думаю и о чем-то интегрированном типа HP'шных микросерверов, на которые можно поставить Linux/FreeNAS, чтобы еще уменьшить энергопотребление…

    Пока все в рассчетах, оторванных от реальных цифр — иногда есть желание забить на рассчеты, купить самый дешевый счетчик, сделать сервер из существующего железа и посмотреть скажем за сутки сколько киловатт набежит чисто от этого «сервера» — никто ничего подобного не делал?
    • 0
      Всей статистики по энергопотреблению я ещё не собирал, так как мой N54L молодой. К стандартной комплектации добавьте планку памяти на 4 Гб, сетевую карту от Интел и всё это крутится под unRAID на флешке (просто тестирую разные решения) — сервер потребляет 33 Вт.
      Когда выполнил команду Spin Down и притормозил дефолтный винт на 250 Гб, то энергопотребление снизилось до 29 Вт. В общем, как пишет интернет — по 4 Вт на винт.
      • 0
        Vest, дружище, про unRaid постов я тут не нашел, как и сравнений разных бесплатных NAS-систем ;-)
        • 0
          Я сейчас втихаря пишу сравнения в одном стрёмном блоге, но я не к тому.
          Я просто ответил на вопрос выше об энергопотреблении «какого-нибудь» HP MicroServer N54L, на «каком-нибудь» программном обеспечении :) Просто в сравнении с готовым решением от того же Synolodgy проигрыш можно получить где-то до 10 Вт, а людям всегда интересно сколько «жрёт» та или иная железка хотя бы на холостом ходу.
    • 0
      электрометр — о да, я поставлю это себе в backlog микроэлектронных проектов! Телеметрия энергопотребления по IP:) Почти как электросчетчики в новых домах с шиной RS485.
      • 0
        а это мысль…
        особенно если мерить ток не в разрыв.
    • 0
      Максимальная мощность импульсного блока питания не влияет на объем потребления энергии. Реальная потребляемая мощность зависит от того, сколько потребляет железо и это значение увеличивается, в зависимости от КПД блока питания.
      Если экономить на электроэнергии, то роутер TPLink 3020 за 900р и габаритах 1/2 ide hdd может быть файловым сервером (и много чем еще, на базе openwrt), потребляя свои максимальные 5 ватт, при этом не шуметь и не собирать пыль.
  • 0
    Автор, хочу знать как произносите IBM и DELL :)
    • 0
      nagimov, может, так:
      известный производитель мэйнфреймов Ибрагим-Бек Машины
      второй пока вертится в голове, но никак не оформится
      • 0
        ничего в голову не лезет, кроме
        лидер рынка аппаратного обеспечения ШМЕЛЛ
  • 0
    Оффтопик:

    «Карма Дома» — лучший производитель воздуховодов для серверов начального и среднего уровня!»
  • 0
    Если сравнивать FreeNAS и его предка-бранч NAS4free,

    Хм… Кто кому предок?
    habrahabr.ru/post/124414/

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

    Смотря какие изменения.
    • 0
      Rimlyanin, отличный вопрос; я рассказываю про FreeNAS версии 9, основанный на тех кодах, которые на момент написания статьи уже переименованы в NAS4free, хотя изначально именно те, старые коды назывались FreeNAS. Там был развод и раздел имущества. Но при этом NAS4free тоже на месте не стоит и, чтобы потом не заниматься казуистикой, я так и написал про NAS4free «предок-бранч».

      Предложите лучшее обозначение для столь нетривиальных родственных связей. Можете еще добавить к семейному древу проект OMV, который один из членов команды FreeNAS / NAS4free перетащил на Debian. По крайней мере, на морде в графическом интерфейсе OMV семейные черты читаются отчетливо.

      Смотря какие изменения

      Я не говорю, что NAS4free — плохой продукт, коллега. Но беглое прохождение по интерфейсу NAS4free летом 2013г. показало, что те вещи, которые я с ходу вкатывал во FreeNAS 9, у NAS4free требовали перезагрузки. Я думаю, что NAS4free рано или поздно уйдет и от этой практики, и от хранения настроек в плоском XML. И вообще желаю ребятам всяческих успехов.
      • 0
        Вы по ссылке ходили?
        Тот пост датирован мартом 2012го.
        Скорее FreeNAS предок NAS4Free.

        И да, я осенью 2012го собирал NAS, ставил на него NAS4Free, и весь процесс настройки (ZFS, SMB, Transmissoin и остальное) ни потребовал ни одного ребута.

        А вообще, да, и тот и другой продукт после отпочкования продолжают развиваться, и тут уже каждый «выбирает для себя, каждый выбирает по себе». У меня NAS4Free «взлетел с пол пинка», Вам FreeNAS больше по душе пришелся.

        P.S. И да, насчет XML: приносили NAS под NAS4Free с полу-мертвой флешкой. Бакапа настроек конечно же не было. С флешки легко восстановились несколько копий разной давности конфигурационных файлов, один из которых был скормлен свежеустановленной системе и все «взлетело». Вот так.
        • 0
          Rimlyanin, ладно, уговорили, FreeNAS предок NAS4free :)) Последний, у меня, кстати, тоже завелся с полпинка, и даже порадовал более управляемым, что-ли, процессом создания томов. Т.е. у NAS4free IMHO больше чисто юниксовых вещей вытащено в GUI, там еще есть файл-менеджер и прочие фишки, и системные требования вроде были скромнее. Но мне все это не пригодилось.

          re: XML
          у меня (правда, совсем в другом проекте) файл XML просто погибал у некоторых заказчиков при абсолютно исправной дисковой системе, в результате отказа питания. Я как представлю себе все эти DOMы c SAXами и чтение-запись всех настроек только одним махом… И с другой стороны «РСУБД-внедренка» SQLite, с журналом и доступом на уровне одиночных записей. Да, найти на разбитой в хлам файловой системе обломки XML и затем склеить их, конечно, реально. Но лично я вывел у себя условный рефлекс: поменял настройку — сразу забэкапил. Пара жестов мышью и все.

          Кстати, можно еще /data бэкапить куда-нибудь, запросто настраивается по Cron_Jobs. По-моему, сходная техника прокатит и для NAS4free, только там раздел по-другому называется.
          • +1
            Я бы сказал что NAS4Free — почка от FreeNAS. C частью разработчиков.
            Но не в этом суть:)

            re: re: XML
            Так что NAS4Free, что FreeNAS, держат себя и настройки в оперативке, если, конечно, речь идет о embedded варианте, с установкой на флешку (а в других случаях оно флешку «сточит» довольно быстро), так что «отказы питания» тут совершенно не причем.

            Увы, не все бакапят. А потом ко мне и приходят :)

            по крону оно будет бакапится куда? на тот же NAS? :)
            • 0
              Rimlyanin, почка +1 :)))

              по крону можно действительно положить на системный том (во FreeNAS 9.2.1.1 появилось понятие «системный том», не смейтесь; но можно и не несистемный тоже), либо отправить на email администратора (Вам рекомендую, «на коленке» через base64 или более научным способом), либо по SSH/SCP на другой сервер, дальше сами можете продолжить;)

              про стачивание флэшек планирую отдельный пост, следите, если интересно

              PS
              моя история про XML совсем не относится к NAS'ам:) Это другие продукты, а отказ питания с потерей XML — просто эпизод из истории их эксплуатации.
              • –1
                Может не надо мне рекомендаций человека, который допускает оплошности в статье?
                Мои серваки бакапятся, бакапы копируются на другой сервак, и все это делается автоматически. Мне остается лишь просматривать письма, да и то, там сортировка настроена. Ну и изредка проверять бакапы, что бы быть в них уверенным.

                Кстати, вот прямо сейчас на серваках выполняется restore -xvf {img.name} для проверки целостности.

                Про стачивание флешек конечно интересно, но понимаете ли вы разницу по стачиванию флешек при установке embedded-варианта FreeNAS или NAS4Free?

                P.S. Ваша ситуация с XML напоминает мне «я как то отравился пирожным, с тех пор больше я пирожных нигде не покупаю»
                • 0
                  У меня примерно аналогичная настройка. Только на флэшке стоит полноценный ubuntu server, флэшка по крону dump'ится на тот же сервер но на другой диск — локальный полунадежный бэкап, зато быстро восстановить. ВСЕ диски вместе с бэкапом флэшки бэкапятся на внешние мои сервера + в облако crashplan через crashplan. Письма красивые приходят тоже.

                  У меня вопрос, а как вы целостность проверяете? Просто restore -xvf {img.name}? и если не было ошибок, то значит все в порядке?
                  • 0
                    FS на флешке в RO или в RW?
                    темпы и логи куда пишутся?

                    Целостность — да. Забыл сказать что дампы дополнительно пакуются в gz. Так ято по факту проверяется и целостность архива и его целостность после передачи между площадками.
                    Ну и проверяется бакап распаковкой на виртуалку и проверкой, что бы все «завелось».
                    Иначе можно делать бакапы и думать что все в порядке, а на самом деле при форс-мажоре обнаружить что бакапы делались, но толку от них мало.
                    • 0
                      темпы и логи в tmpfs. Да, не очень хорошо логи в памяти хранить, но для домашнего nas+ в самый раз.
                      FS думаю в RO перевести, только вот не уверен нужно ли при условии что большая часть в памяти хранится.
                    • 0
                      «Ну и проверяется бакап распаковкой на виртуалку и проверкой, что бы все «завелось». » руками или как то автоматически например через vagrant?
                      • 0
                        Нет, проверяется ручками. Да и не вижу смысла проверять автоматом, лучше самому проверить и понять, есть косяки или нету.
                        Тем более это ж не так часто. Сама система не так часто бакапится, гораздо реже данных.
                • +1
                  Rimlyanin, раз спросили, найдите отличия между двумя embedded-вариантами:

                  [root@freenas] ~# mount
                  /dev/ufs/FreeNASs1a on / (ufs, local, read-only)
                  devfs on /dev (devfs, local, multilabel)
                  /dev/md0 on /etc (ufs, local)
                  /dev/md1 on /mnt (ufs, local)
                  /dev/md2 on /var (ufs, local)
                  /dev/ufs/FreeNASs4 on /data (ufs, local, noatime, soft-updates)
                  


                  NAS4free ставил в варианте №2
                  nas4free: ~ # mount
                  /dev/md0 on / (ufs, local)
                  devfs on /dev (devfs, local, multilabel)
                  procfs on /proc (procfs, local)
                  /dev/md1 on /var (ufs, local)
                  /dev/ada0s1a on /cf (ufs, local, read-only)
                  


                  Причина, по которой я выбрал FreeNAS
                  отдельная файловая система для хранения настроек
                  /dev/ufs/FreeNASs4 on /data (ufs, local, noatime, soft-updates)
                  

                  NAS4free для сохранения настроек должен каждый раз перемонтировать «корень» со всеми вытекающими, и я обоснованно считаю это позором недостатком проекта в 2014г. Оттуда же и перезагрузки берутся в некоторых случаях.


                  Я уже не говорю про то, что NAS4free предлагает (спасибо, что хоть ненавязчиво) создать еще и swap на флэшке.

                  Коллега, либо объясните прямо сейчас, в чем плюс хранения настроек XML прямо на корневой файловой системе read-only, либо давайте закроем эту тему и уйдем в личку. Пляски с бубном симлинками, конечно, допускаются, но учтите входной порог квалификации для их применения.

                  PS
                  У FreeNAS есть свои тараканы, можете не беспокоиться, и некоторых я планирую вывести на свет божий в следующем посте.
                  • –1
                    Хм, ты ему про Фому, он тебе про Ерему.
                    Коллега, перечитайте диалог. Причем тут отдельный раздел если вы же писали о бакапе настроек?
                    • +1
                      Виноват, это было вот сюда:
                      Про стачивание флешек конечно интересно, но понимаете ли вы разницу по стачиванию флешек при установке embedded-варианта FreeNAS или NAS4Free?

                      Ответ: думаю, что понимаю (см. комментарий выше).

                      А вот сюда:
                      Может не надо мне рекомендаций человека, который допускает оплошности в статье?

                      все, молчу, молчу, уважаемый гуру:)) вижу, бэкапы Вы и без моих рекомендаций умеете лихо делать:)
        • +1
          Совсем не в тему влезу, но про XML: на работе отрубили электричество, комп от УПСа какое-то время жил, потом заряд кончился. После восстановления питания винда радовала несколькими невразумительными критическими сообщениями от разных приложений с общим смыслом о невозможности запуска. Разбор полётов показал что у них настройки хранятся в XML и там почему-то вместо содержимого забито всё 0x00.
          • +1
            +1, жаль, что у меня плюсомет однозарядный, не жаль и половину обоймы потратить на Ваш ответ:)
            моя история про XML совсем не относится к NAS'ам:) Это другие продукты, а отказ питания с потерей XML — просто эпизод из истории их эксплуатации.

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

            ясен день, что системы разные, но в моем случае код был под две системы Windows и Linux. Значит, сильно велики шансы иметь общие корни open source библиотек. И не исключено, что тут те же…
            • 0
              Возможно, один из был GoldenDict, кто ещё — не помню, но вроде больше ничего opensource не используется.
        • 0
          Чего вы спорите, на сайтах всех трех указанных подробно описана вся Санта Барбара кто чей мать.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.