Как построить расширяемое хранилище из нескольких iscsi дисков?

Question

[Денис Смирнов]

Передо мной стоит задача построить легко расширяемое хранилище для DICOM снимков PACS'а. По факту - нужна обычная файлопомойка. Ресурсы для этого - пара NAS фирмы QNAP, на которых поднят raid5 и нарезано по iscsi диску на 5ТБ. Через полгода появится в отдельной серверной еще одна NAS того же производителя, от которой можно отрезать еще ~20ТБ. Из всего этого нужно создать некое хранилище данных, которое можно было бы легко расширить. Монтироваться оно будет в единую точку монтирования на PACS сервере (ubuntu 16.04). Хочется следующего поведения - если отвалилась одна из NAS, то ее файлы просто становятся недоступны, а файлы остальных NAS - доступны и новые снимки пишутся на доступные iscsi.
Я перебрал уже пару не устроивших меня вариантов:

• iscsi загнать в JBOD через mdadm и поверх построить lvm
  
• поверх iscsi построить lvm
  

Вариант не устроил тем, что при недоступности одной из NAS, все данные становятся недоступны или ведут себя непредсказуемо.
Пока прорабатываю вариант с монтированием iscsi устройств на сервер и объединение их посредством aufs с режимом записи на тот iscsi, где больше места. Пока все подключено, ее поведение идеально. Но при недоступности одного из iscsi дисков и попытке записать на него что-то, вся точка монтирования aufs переходит в read-only и требует перемонтирования. Кто-то знает, как это можно победить? Или, возможно, есть другие варианты?

Comments

[Kheus]

А смотрели в сторону iSCSI + GPT + ZFS ?

[Денис Смирнов]

Нет, zfs не пробовал ставить (вроде Ubuntu 16.04 его должна уметь из репозитория). Сколь я смотрел, zfs может собирать аналоги raid'ов своими средствами. Рейды с избыточностью хранения мне не нужны - iscsi нарезаны на NAS, где уже raid5. По факту мне нужна union файловая система, а не raid или jbod. zfs могла бы мне дать аналог raid1, но при вылете одного из iscsi дисков (в серверной с NAS этого iscsi что-то случилось) я теряю весь массив. А при union-like файловой системе, я перехожу в read-only или продолжаю работать со всеми данными, кроме тех, которые на вылетевшем NAS. Хотя я могу не правильно понимать zfs, я ее еще руками не пробовал. Если не прав, поправьте, пожалуйста!

Answer 1

[Денис Смирнов]

Я понял, что aufs не умеет корректно обрабатывать ситуацию, когда один из слоев недоступен (iscsi отвалился). В этом случае вся совокупность слоев помечается сбойной и требует перемонтирования iscsi и пересоздания aufs. Мне этот вариант не подходит.
На замену нашел mergerfs. Он работает аналогично aufs с точки зрения использования (только через fuse, но это при моих нагрузках не важно), но в отличие от последней, при недоступности одной из точек монтирования, mergerfs продолжает нормально работать. Невозможно прочитать только файлы с недоступного iscsi, остальные отлично работают и даже пишутся... правда есть нюанс. Политики выбора точки записи могут быть типа: где меньше места, где больше, рандомно. И возможна ситуация, когда согласно политике надо писать на недоступный iscsi и тогда мы вываливаемся в честный read only. В принципе неплохо, но возможно я придумаю вариант, как обойти это ограничение. Проблема на текущий момент в том, что после того, как iscsi стал недоступен, его точка монтирования все еще знает его свободное место до факта недоступности. Если я узнаю, как убедить систему, что если диск отвалился, то его размер равен нулю, то в read only я уже не попадаю никогда и это полная победа. Отпишу по результату.

Comments

[Денис Смирнов]

Насчет "убедить систему, что размер диска равен нулю"... мда, пробелы в базовых знаниях никогда ни к чему хорошему не приводили. При монтировании iscsi в точку монтирования корневой системы, точка монтирования получает свою таблицу inodes, в которой содержатся сами inodes (тупо id) файлов и их атрибуты (в том числе и размер). По ним и считается свободное место на iscsi. Поэтому, когда связь с физическим iscsi теряется, таблица inodes никуда из точки монтирования не делась и размер все еще определяется как на момент потери связи. Так что mergerfs порой будет уходить в read only при потери связи с iscsi с самым большим свободным местом, тут ничего не поделать. Всяко это будет редко, да и перемонитировать - пара пустяков в случае сбоя.

Answer 2

[Дмитрий Шицков]

Не знаю как решить вашу задачу, т.к. не имею чёткого понятия как работает PACS сервер.
Выскажу костыльное решение - писать на выбранное по round-robin хранилище из доступных. Так возможно? Или система должна быть сконфигурирована на запись в конкретное место? Возможно ли стримить данные в некий демон-посредник, который уже разрулит куда записать снимок?

Comments

[Денис Смирнов]

Нет, к сожалению такой вариант не сработает. PACS представляет из себя службу, слушающую порт, базу данных и некую точку монтирования, куда помещаются прилетевшие dicom снимки. dicom снимок - это контейнер с тегами (имя человека, на каком аппарате сделано и т.д.) и содержимым (серии фотографий, видео и т.д.). Когда такой снимок прилетает на службу PACS, PACS сам решает, куда положить на точке монтирования снимок и индексирует его теги и путь хранения в БД. Я использую Orthanc, он опенсорсный и поддерживает lua скрипты внутри. Но я сильно сомневаюсь, что они позволяют проверять доступность файловой системы перед записью и корректно обрабатывать исключение. А если и могут, то это очень мудреный вариант, я бы хотел его избежать))) А просто демон не подойдет, адрес, куда будет сохранен файл определяет PACS и перед этим кладет его в индекс в БД. Если демон его переместит, PACS потом не найдет снимок.

Answer 3

[zvl]

https://www.mylinuxplace.com/building-raid-over-ne...

Comments

[Денис Смирнов]

Да, я пробовал этот вариант. Но это лишний оверхед - получится, что я строю пятый рейд из iscsi, отрезанных от NAS с пятыми рейдами. Плюс я теряю место. Ну и еще минус - если один из iscsi дисков рейда стал недоступен из-за проблем сети/питания, то при его возвращении в рейд, рейд придется пересобирать. Это очень больно, долго и вообще порочно.