Хотел как лучше, надежнее, масшабируемо, а получилось плохо

Спасибо @Alexey
Действительно, у меня на моей главной локации используется iSCSI хранилище, я работаю с ним с самого начала как получил приглашение в v3 (когда еще был только 1 сателит Стефана и не было Tardigrade сателитов). Из своего опыта могу сказать следующее:

  1. iSCSI можно использовать только тогда, когда вы уверены в вашей сетевой инфраструктуре, 1 отвал сети равносилен краху всех дисков которые были к нету подключены. Нужно использовать резервирование на всех уровнях, iscsi multipath, дублировать линки, дублировать коммутаторы, дублировать питание, дублировать резервное питание для каждого из коммутаторов.
    У меня все продублировано, и резервировано, только так можно обеспечить необходимый уровень надежности для iSCSI.
  2. Никогда не используйте виртуальное хранилище ZFS+iSCSI для задач рандомного чтения записли для которых важны задержки (а для Storj это очень важно). Вы не сможете обеспечить низкие задержки без очень глубоких знаний системы визуализации, и даже если у вас получится приемлемый результат, то он будет на несколько порядков хуже того, если бы просто выделили отдельную машину под iscsi хранилище без визуализации, или использовали готовый NAS с такой функцией.
    Я использую именно выделенное хранилище с которого я раздаю iSCSI LUN всем машинам.
  3. Необходимо использовать правильное оборудование для iSCSI. далеко не все сетевые карты работают хорошо с iSCSI, и ожидать хорошей производительности от десктопных карт не стоит. Я использую SFP+ карты, и у меня сторедж сеть отделена от общей сети физически.
  4. Необходимо правильно подключать iSCSI таргеты (сервер) к инициаторам (клиенты). Есть два проверенных способа: a) подключать таргет непосредственно к гипервизору и использовать его для размещения виртуальных дисков. б) Подключать таргет внутри виртуальной машины (в линуксе с помощью tgt). Каждый их этих способов имеет свои преимущества и недостатки.
  5. Необходимо контролировать IOPS своего стореджа, и не допускать его перегрузку, так как это чревато отвалом стореджа в целом.
  6. Необходимо правильно монтировать файловую систему с iSCSI дисков. (ZFS+iSCSI не терпит опцию discard это распространенная ошибка, и я тоже на нее наступил, но мне повезло и моя нода выжила )

Я бы не рекомендовал начинать с iSCSI, как видите это весьма не просто, и есть много нюансов. Гораздо проще использовать локальные диски. Переход на iSCSI может быть оправдан только в том случае если у вас больше 2-3 физических серверов виртуализации, или если вы строите отказоустойчивый кластер с выделенным хранилищем.
Лично я прошел весь цикл эволюции SNO и могу поделить его на несколько этапов:

  1. RPI - начальный этап, идеален для начинающих (и не только) SNO.
  2. mini-ITX (встроенный проц) - следующий этап после RPI, когда нужно добавить емкости на туже ноду и при этом сохранить энергоэфективность.
  3. Single server - серверное железо или ATX, когда mini-ITX уже нехватает
  4. Industrial SNO - когда серверов много, и они на разных локациях по всему миру.

Могу с уверенностью сказать, что использовать iSCSI до 4го этапа (если конечно в этом нет необходимости для других задач не связанных со Storj) нет никакого смысла, куда проще (и надежнее) организовать локальные диски.