подключить сетевое хранилище nas в серверную часть по trassir можно по протоколу

Полезная информация

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

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

Сотрудники компании DSSL знают, что объем архива крайне важен для каждого клиента, а способы его хранения рождают массу вопросов. Для решения столь насущной задачи было принято решение произвести тестирование сетевых носителей (NAS).

15.02.2010г. техническими специалистами компании DSSL тестировался сетевой носитель N5500 от компании Thecus.

Отличительной особенностью N5500 является возможность совмещать в себе функционал сетевого хранилища NAS,, подключаемого непосредственно к ПК устройства DAS или подключаемого по iSCSI тома.

Мощный процессор Intel ® и два гигабитных порта Ethernet с функциями балансировки нагрузки, автоматического переключения при сбое и объединения каналов на базе протокола 802.3 ad обеспечивают быстрый и надежный доступ к данным.

Для информационной среды предприятия чрезвычайно важна возможность непрерывного доступа к данным видеонаблюдения. Уникальная технология дублирования служебной памяти для хранения ОС устройства (disc on module, DOM) обеспечивает безотказную работу массива даже в случае программного сбоя или неудачной перепрошивки устройства. Максимальная гибкость и универсальность N5500 обеспечивается поддержкой различных файловых систем, среди которых XFS, ext3 и ZFS. Более того, возможен выбор различных типов файловых систем для каждого тома RAID.

Тестовый стенд: 1. TRASS IR Server; 2. 52 IP камеры Hikvision с D1 разрешением; 3. Thecus N5500 (NAS) с архивом на массиве RAID 6; 4. TRASSIR Client, подключенный к TRASSIR Server;

В результате тестирования было выявлено, что при потоке не более 15 Мб/с на сетевое хранилище Thecus N5500, система видеонаблюдения TRASSIR позволяет производить непрерывную запись не более 52 каналов с разрешением 704 х 576 и скоростью записи 25 к/с. *

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

* Данные параметры указаны исключительно для камер с переменным типом потока не более 2 Мбит/с и форматом видео H.264.

Источник

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

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

Сотрудники компании DSSL знают, что объем архива крайне важен для каждого клиента, а способы его хранения рождают массу вопросов. Для решения столь насущной задачи было принято решение произвести тестирование сетевых носителей (NAS).

15.02.2010г. техническими специалистами компании DSSL тестировался сетевой носитель N5500 от компании Thecus.

Мощный процессор Intel ® и два гигабитных порта Ethernet с функциями балансировки нагрузки, автоматического переключения при сбое и объединения каналов на базе протокола 802.3 ad обеспечивают быстрый и надежный доступ к данным.

Для информационной среды предприятия чрезвычайно важна возможность непрерывного доступа к данным видеонаблюдения. Уникальная технология дублирования служебной памяти для хранения ОС устройства (disc on module, DOM) обеспечивает безотказную работу массива даже в случае программного сбоя или неудачной перепрошивки устройства. Максимальная гибкость и универсальность N5500 обеспечивается поддержкой различных файловых систем, среди которых XFS, ext3 и ZFS. Более того, возможен выбор различных типов файловых систем для каждого тома RAID.

Тестовый стенд:
1.TRASS IR Server;
2.52 IP камеры Hikvision с D1 разрешением;
3.Thecus N5500 (NAS) с архивом на массиве RAID 6;
4.TRASSIR Client, подключенный к TRASSIR Server;

В результате тестирования было выявлено, что при потоке не более 15 Мб/с на сетевое хранилище Thecus N5500, система видеонаблюдения TRASSIR позволяет производить непрерывную запись не более 52 каналов с разрешением 704 х 576 и скоростью записи 25 к/с. *

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

* Данные параметры указаны исключительно для камер с переменным типом потока не более 2 Мбит/с и форматом видео H.264.

Источник

Варианты подключения не интегрированных IP-камер

ПО TRASSIR умеет работать практически с любым IP-оборудованием для видеонаблюдения.

Даже если необходимой камеры нет в списке поддерживаемых IP-устройств можно попробовать воспользоваться одним из альтернативных вариантов добавления устройства.

Существуют следующие варианты подключения:

Добавление IP-устройства через Автоопределение

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

Подробнее о добавлении IP-устройства с использованием Автоопределения описано в руководстве пользователя TRASSIR

Добавление IP-устройства работающего по протоколу ONVIF

ONVIF — это единый протокол, по которому работает большинство современных IP-камер.

Уточните поддержку протокола ONVIF в технической документации к видеокамере.

Подробнее о подключении IP-устройства с использованием протокола ONVIF описано в руководстве пользователя TRASSIR

Добавление IP-устройства с использованием протокола RTSP

Для того чтобы воспользоваться данным способом необходимо знать какой URL для запроса видеопотока по RTSP используется для вашего устройства. Если по каким-то причинам, в технической документации, не удается найти какой вид запроса используется в данном устройстве, то для уточнения RTSP ссылки можно воспользоваться бесплатной утилитой ONVIF Device Manager (для работы с утилитой необходима поддержка камерой протокола ONVIF)

Подробнее о подключении IP-устройства с использованием протокола RTSP описано в руководстве пользователя TRASSIR

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

Подключение по универсальному протоколу unified

Данное подключение доступно только для IP-устройств следующих производителей: Hikvision, HiWatch, Dahua, AXIS

В окне Настройки на закладке IP-устройства нажмите кнопку «Добавить вручную»

В появившемся списке выберите нужного производителя камеры (Hikvision, Dahua или AXIS. Для моделей HiWatch выберите Hikvision).

При необходимости вы можете воспользоваться быстрым поиском чтобы сократить список производителей.

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

На шаге 2, из появившегося перечня моделей, выберите Unified.

При необходимости вы можете воспользоваться быстрым поиском чтобы сократить отображаемый список.

В открывшемся окне необходимо указать данные для подключения и нажать кнопку «Создать»

Откроется окно Настройки параметров устройства.

Добавление под «похожей» моделью

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

Данный способ не гарантирует полноценную корректную работу устройства в ПО TRASSIR

При установлении соединения, в настройках IP-устройства, будет отображаться ошибка «Неправильная модель».

Индикацию данной ошибки можно отключить с помощью скрипта Model missmatch off

Для каждого способа подключения необходима соответствующая лицензия.

Протестировать все способы подключения можно на demo-версии ПО TRASSIR.

Скачайте актуальную версию ПО TRASSIR с нашего сайта и при первом запуске активируйте демо-режим.

Источник

Еще один 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):

А как же облачное хранение, спросите вы? На момент написания этой статьи популярные облачные хранилища для наших объемов выглядят дороже, чем хотелось бы. Например, стоимость хранения неограниченного объема данных 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).
Так к чему я это всё?

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

Конечно, глючная мать, изношенная механика и старый блок питания совершенно не укладываются в философию Крепсондо (ой, снова простите, непрерывность бизнеса), и потому подлежат замене в первую очередь и без лишних обсуждений. Гармония Крепсондо для нас важнее, поэтому попрощаемся со старым железом, оно свою историческую миссию выполнило.
Выбор замены для 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%. Верхний принято считать решением для среднего бизнеса, а нижний – для домашних пользователей и малого бизнеса. Чем же грозит использование самых дешевых дисков? По субъективным оценкам некоторых экспертов (ссылка), дешевые диски отказывают ощутимо чаще дорогих в первую же неделю эксплуатации, и по результатам года тенденция сохраняется. Осторожно приведя здесь эту таблицу, повторю, что это очень приближенная субъективная оценка одного из пользователей Интернета, без указания конкретных изделий:

По наблюдению того же пользователя, примерно один-два из дюжины годовалых дисков 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 так и есть, потому что прошивочные баги очень, очень опасны. Продавец, дайте два контроллера, пока они окончательно не исчезли из продаж.

Итого

Оглядим еще раз нашу конструкцию. Простой, как шпала, контроллер в режиме 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):

02:45

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Вт больше, чем требуется, что не может не радовать. Но есть нюанс, о котором мы напишем в следующих частях нашей истории…

Выводы

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

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

Ссылки

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)

Источник