Category: it

Category was added automatically. Read all entries about "it".

Про SnapRAID + Aufs

Вопрос организации массива дисков встает перед каждым владельцем домашнего сервера. Вариантов тут масса, и все они неплохо задокументированы. Очень много русскоязычной информации можно почерпнуть в профильной ветке на iXBT и в блоге одного из главных ее активистов 2gusia. Одним из наиболее популярных вариантов является использование чудесной файловой системы ZFS. Это действительно невероятно мощная штука, по указанным мной ссылкам можно почерпнуть немало тому доказательств.

Однако (особенно если вы используете Linux) этот вариант не является единственным, и я бы хотел чуть подробнее рассказать об одной из альтернатив ZFS, вполне пригодной для использования в домашнем медиасервере. Это связка из двух программ: SnapRAID и aufs.

SnapRAID обеспечивает аналоги RAID 5-6(-7-8-9...), вычисляя контрольные суммы и храня эти данные на выделенных жестких дисках. В отличие от классического RAID и raidz, он работает поверх файловых систем - на выделенном разделе создается огромный parity-файл, каждый файл на диске лежит на одном конкретном диске. Всего для хранения контрольных сумм можно выделить до 6 дисков (т.е. в теории можно построить просто гигантский массив, устойчивый к гибели до 6 дисков). Важный момент - SnapRAID не обеспечивает полновесный пулинг дисков! В коробке есть функциональность монтирования read only-пула, построенного на симлинках, но оно нам надо? Задачи пулинга возложим на Aufs. Aufs позволяет объединить папки (их система называет Branches - ветки), располагающиеся на самых разных дисках, и взять на себя заботу - куда конкретно положить вот этот файл. Есть различные стратегии балансировки ветвей (забивать ли диски по очереди, или всегда писать на самый свободный). Файл, опять же, всегда находится на одном конкретном диске.

Эту связку активно продвигает сообщество Openmediavault, в нем даже есть плагины для установки и настройки SnapRAID и Aufs из веб-интерфейса.

Попробую описать плюсы и минусы указанной архитектуры. Критика и правки принимаются.

Плюсы:

  • Массив очень легко собрать и разобрать на любых имеющихся дисках. Да-да, тип ФС и заполненность дисков роли почти не играют. Понятно, что для Parity необходимо использовать самые большие из имеющихся дисков, и специфика его использования (один гигантский файл) накладывает некоторые ограничения на выбор ФС - это все описано на сайте SnapRAID. Мой личный конфиг - в SnapRAID массив объединены 5 дисков, 2x 4 Tb (один из них как раз под Parity) на Ext4, 1 x 1 Tb на Ext4, 2 x 1 Tb на NTFS (!). При этом в Aufs-пул не включен один из NTFS-дисков (там лежат файлы жены, и вообще он USB-шный). Вся эта радость довольно стабильно работает, и никто не запрещает добавлять/убирать диски без необходимости сливать куда-нибудь в сторонку всю информацию. Доступ к каждому диску индивидуально остается (например, посмотреть где физически лежит какой файл), хотя вносить изменения подобным образом не рекомендуется (например, если на одноименные папки наложить разные права, могут возникнуть конфузы, а это еще самый очевидный вариант извращения...).

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

  • для чтения 1 файла используется только 1 диск - теоретически, это приводит к некоторому уменьшению шума и энергопотребления сервера.

  • Сравнительно низкие требования к ресурсам ЦПУ и оперативной памяти.

Минусы:

  • SnapRAID заточен под медиасервера - сравнительно большие сравнительно редко меняющиеся файлы. Контрольные суммы вычисляются не в риалтайме, scrub тоже необходимо запускать. С обеими задачами справляется Cron.

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

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

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

Для автоматизации sync и scrub я использую модификацию довольно популярного скрипта. Изначально этот скрипт только выполнял пересчет контрольных сумм, потом автор SnapRAID-плагина адаптировал его к механизму отправки почты OMV, ну а я дописал туда Scrub массива на каждый 10-й запуск (при еженощном выполнении получаем обновление контрольных сумм каждую ночь, и проверку на ошибки каждые 10 ночей). Финальный скрипт можно почитать вот тут: http://pastebin.com/x2aK67TZ

upd от 05.01.2015: в текущей версии OMV скрипт уже умеет из коробки делать scrub, и даже настраивается из веб-морды, так что ссылка выше уже неактуальна.

 Вопрос выбора архитектуры хранения данных вообще не является однозначно решаемым, и каждый должен найти свой ответ под свои задачи. В случае Linux-медиасервера связка SnapRAID + Aufs, однозначно, заслуживает пристального внимания и права на жизнь.

Хроники домашнего сервера: phase 1: софт

Итак, наконец дошли руки рассказать немного о программной части чудо-сервера.

В качестве ОС после долгих душевных терзаний была выбрана OpenMediaVault - легковесная сборка на базе Debian Squeeze, обладающая довольно красивым веб-интерфейсом. После феерии с установкой (пришлось оттащить сервак к другу, у которого есть монитор и клавиатура, а потом 4 часа старенький терабайтник WD Green фыркал ошибками и всячески провоцировал вызов fchk при перезапуске) сервер вошел в более-менее стабильный режим для фазы 1.

Ядро Linux пришлось в первый же день обновить из бэкпортов до 3.2 - старое 2.6 не поддерживает термодатчики Ivy Bridge, скрипт для рисования графиков температуры нашелся где-то в гугле (ссылка потерялась).

Был также подключен USB-хард с NTFS, определился вмиг, проблем никаких. Самба-шары легко настроились через вебморду.

Также, был произведен ряд экспериментов с сервисами, которыми можно нагрузить сервер:

RSS. Поставил Tiny Tiny RSS, пощупал немного - и ушел на Feedly, лень стало возиться :-)

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

  • Ampache. По итогам десятиминутного общения - выглядит страшно, склонен к падениям и не любит кириллицу в именах файлов. Удалил в ужасе.

  • Jinzora. Не имеет веб-плеера (только генерирует m3u-файлы). Интерфейсом красива. Имеет проблемы с кириллицей в именах файлов. Удалил, но хотя бы не в ужасе.

  • Subsonic. Мой личный фаворит. Серверная часть написана на Java, имеет удобный браузерный проигрыватель на флэше или HTML5, возможность подключения сторонних приложений (правда, только в премиум-версии), умеет транслировать не только музыку, но и видео (тоже только в платной версии), также можно и генерировать m3u-файлики. Платная лицензия на сервер, открывающая доступ к премиум-функционалу, стоит целый 1 доллар в месяц. Все завелось из коробки, кроме одного момента - по умолчанию серверная часть запускается с ограничением в 150 Мб ОЗУ, что приводит к неприятным зависаниям при попытке добавить в плейлист несколько сотен песен. После разрешения использовать 512 Мб проблема исчезла.

Скачка торрентов. В составе плагинов к OMV нашелся Transmission, управляется через Transmission Remote GUI либо через веб-интерфейс.

Синхронизация папок с сервером. Поставил BitTorrent Sync, правда, пока дальше экспериментов не использую.

Более мощные функции "облачной файлопомойки". Установлен Ajaxplorer, пока не настроен.

Галерея. Сейчас установлена Gallery, но пока что я с ней играюсь и думаю - а надо ли вообще что-нибудь такое поднимать, или же держать на сервере личный фотоархив, а публиковать снимки в каком-нибудь Flickr (который недавно стал намного Biggr).

Немного о планах на будущее (помимо настройки уже имеющегося функционала):

  1. Разобраться, почему не ходят е-мейл отбивки. По сути, самая крупная проблема. Не ходють - и все тут, висит себе процесс smtp и висит, а из вебморды проверка утверждает, что все зашибись. И Билайн в личном кабинете утверждает, что 25 порт открыт. Короче, надо ковыряться upd. сие был привет от роутера, и после перехода на прошивку от энтузиастов все стало хорошо.

  2. Поднять VPN-сервер -- раньше он работал в роутере, но после смены прошивки надо решать - либо втыкать в роутер USB HDD и устанавливать его ручками, либо пытаться настроить OpenVPN на домашнем сервере.

  3. Поднять какую-нибудь http-качалку с веб-интерфейсом, чтобы можно было скармливать ей ссылки на скачки файлов. upd. Нужный функционал обнаружился у Ajaxplorer

  4. После закупки HDD перейти на ZFS при помощи ZFS on Linux и, соответственно, поднять RaidZ.

  5. После обустройства системы в целом определиться с бэкапами. Пока что лидирует мысль про CrashPlan.

Полезные тезисы с курса "Разработка распределенных информационных систем"

В конце января я посетил курс в Учебном центре 1С №1 курс под названием "Разработка распределенных информационных систем в "1С:Предприятие 8" (почитать описание и записаться можно тут). Ведет его замечательный преподаватель и методист, Арутюнов Сергей Рафаэльевич. Курс просто архиполезен для всех, кто сталкивается с необходимостью разделять системы по функциональным областям - базами (РИБ, внешние источники), ролями, RLS-ами, разделителями...

Здесь я бы хотел отметить некоторые тезисы, которые вынес для себя после прохождения курса:

  1. В отличие от платформы 8.1, где каждая информационная база могла встречаться в списке ровно один раз, в 8.2/8.3 можно ее вписать столько раз, сколько нужно, обвешав, например, разными параметрами. Соответственно, каждая строка списка теперь несет несколько иной методический смысл - группа ИБ идентифицирует информационную систему, а конкретный элемент списка - точку входа в данную систему. Благодаря обилию средств интеграции с одной стороны и разделителей - с другой, понятия "точка входа" и "информационная база" в общем случае не совпадают.

  2. В платформе 8.3 появилась очень мощная функция, которую, кстати, почему-то проигнорировал в своем обзоре Евгений Гилев - ключ /UsePrivilegedMode , который позволит пользователю с административными правами запустить сеанс в привилегированном режиме. Это позволяет вообще отказаться от роли "ПолныеПрава", и дать администратору роль, в которой будет только галочка "Администрирование". А когда потребуется доступ к данным - он сможет культурно войти с ключом, сделать свое грязное дело и культурно выйти. Важное замечание - ключ не откроет аналог "полного" интерфейса - командный интерфейс будет отображать только то, к чему есть доступ в роли (в описанном случае - ничего), так что Use "Все действия", Luke...

  3. Небольшая заметка касательно ролей - если мы играем доступом к объектам/реквизитам, стандартные реквизиты в 8.3 надо контролировать отдельно - галочки доступа к ним не изменяются, если взвести/снять галочку доступа к самому объекту.

  4. В значениях разделителей не рекомендуется использовать символы + и -, т.к. они используются в строке соединения для указания значений разделителей.

  5. Разделители создают обособленные области памяти, и разделяют, помимо собственно данных, также блокировки, нумераторы и т.д. Так что при использовании разделителей может оказаться ненужным механизм префиксов номеров. Ну и автоматически работающая сквозная автонумерация внутри каждого разделителя еще раз подчеркнет, что не стоит для аналогичных задач использовать RLS (добавлю также от себя, что RLS - это то еще средство внесения тормозов в систему...)

  6. В случае, если разделителем является справочник, значение его идентифицируется по коду.

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

  8. На любую условность в отображении надо заводить функциональные опции

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

  10. В лаунчере функция "Добавить существующую базу" не проверяет существование файловой базы. Этим можно пользоваться для проектирования распределенной системы.

  11. Типовой механизм создания начального образа базы не может накладывать на данные никакие отборы. Если есть необходимость выгружать не все - придется писать свой механизм.

  12. Очень мощный метод - УстановитьПривилегированныйРежим(). Работает только на сервере. Позволяет, например, реализовать следующую архитектуру взаимодействия баз: создаем общий модуль, в котором будут интерфейсные процедуры, каждая из них будет начинаться с установки привилегированного режима. Снимать его не обязательно- при завершении процедуры он сбросится автоматически. А внешний пользователь будет иметь право ТОЛЬКО на внешнее соединение :-) Таким образом мы не паримся с его ролями, и контролируем все, что он сможет увидеть, внутри интерфейсных процедур. Общий принцип проектирования: внешняя часть интерфейса должна быть стабильной!

  13. Если мы используем РИБ, то для каждого действия должна быть единственная точка ввода данных! Например, если часть бухгалтерии (какой-нибудь филиал) мы вынесли в периферийный узел, для остальных филиалов также надо создать периферийные узлы, в архивной базе первичные данные вводиться уже не должны!

  14. Платформа 8.3 имеет полновесные конфигуратор и клиент под Linux, что позволяет на линуксовом сервере программно запускать конфигуратор, например, для выгрузки/загрузки базы, методом ЗапуститьПриложение.

  15. Веб-сервисы - единственный способ взаимодействия баз 1С под Linux (ну нету там COM-соединения, это чисто виндовая технология...)

  16. Если не получается подключиться по COM к внешней базе, можно программно проверить, существует ли файл comcntr.dll нужной версии и выполнить regsvr прямо в процедуре.

  17. 1С: Предприятие имеет возможность указания пользовательских параметров запуска в командной строке по ключу /C. Если передаваемую строку параметров парсить в процедуре ПередНачаломРаботыСистемы, можно создать свое API для конкретной конфигурации. Исполняться оно будет на клиенте. Далее можно использовать эти команды, например, в bat-файлах. Получится такой вот аналог фоновых/регламентных заданий на клиенте.

  18. Когда COM-соединение перестает нам быть нужным, надо не забывать его рубить кодом типа Соединение = неопределено. Иначе есть риск, что оно подвиснет, и будет у нас висячее зомби...

  19. Какие-либо процедуры, кроме предопределенных обработчиков, методически некорректно прописывать в модулях приложения. Надо заводить отдельные модули.

  20. При использовании веб-сервисов рекомендуется в качестве типа параметров использовать строку - это самый базовый тип, который все понимают :-)

  21. Еще одно преимущество веб-сервисов перед COM - внешнее COM-соединение съест еще 1 лицензию. А подключение к веб-сервису лицензию не ест, т.к. не активируется еще один клиент.

  22. WSСсылки работают только на сервере!

  23. COM-соединение должно служить только для взаимодействия 2 клиентов 1С под Windows. Во всех остальных случаях (например, для связи 2 серверов) рекомендуется использовать вебсервисы.

  24. Для внешнего доступа к веб-сервису рекомендуется завести отдельного пользователя, и дать ему права только на операции веб-сервиса.

  25. Методически правильно работать с Automation через неглобальный общий модуль.

  26. Хитрость при организации хранилища сопроводительных файлов - если именовать все файлы в папке GUID-ами, то ОС очень быстро ее проиндексирует за счет того, что длина имен файлов будет одинаковой. А сопоставление понятного имени GUID-у будет выполнять 1С. Получается быстро, и база не распухает.

  27. Если мы передаем в процедуру/функцию параметры, которые не планируем изменять, всегда рекомендуется их помечать словом Знач. Дело вот в чем. 1С возвращает назад не только результат функции, но и все параметры, не помеченные как Знач. Еще раз: если мы с клиента вызвали серверную процедуру - она нам вернет все параметры, которые мы ей отдали. А это мало того что трафик, так еще и возможна ситуация, когда с клиента на сервер улетела строка, а прилетела ТаблицаЗначений, которая, как мы помним, на клиенте существовать не может. Пример гипотетический, понято, что это очевидный косяк, но все же...

  28. Механизм внешних источников данных до сих пор сырой.

  29. Новый функционал 8.3 - поддержка иерархии внешних источников данных. Мы задаем поле, содержащее в себе идентификатор родителя. Эту иерархию подхватывают формы списка и СКД.

  30. не разобрал свой почерк :-) Будет еще один повод тебе, мой дорогой читатель, сходить на эти курсы :-)