GlusterFS забросили многие, но тут нужно понять суть вопроса.

У вас сейчас есть несколько типов хранилищ:
1. Кластер серверов хранения, который прикидывается NAS
2. Единый сервер хранения применяющий Storage Bridge Bay
3. Software Defined Storage - кластер применяющий репликацию локальных дисков.

Второй вариант - это частный случай первого, когда 2 стандартизированных блейда ("контроллера") подключаются к одному и тому же JBOD через стандартизированный аппаратный интерфейс. Емнип, TrueNAS/FreeNAS с таким не работает. На втором варианте применяются проприетарные варианты FreeBSD, Windows Storage Server, Solaris или, что реже, RHEL.

TrueNAS CORE - это вариант 1, он же аналог Windows Storage Spaces (не Direct). В общем случае у вас есть какой-то SAN. Enclosure-ы подключены через HBA к вашим серверам. Дальше вы делаете Fault Domain в этом кластере по узлам с одной стороны и по дискам/полкам/стойкам с другой стороны. В основе лежат SAS-протоколы iSCSI/FCP. И у вас там повсюду Multipath IO. Вот эту задачу исторически решал ZFS.
В понимании Microsoft и вендоров проприетарных стораджей разных мастей "SCALE" в этой ситуации - это добавление новых полок JBOD/JBOF и новых стоек выделенного хранилища. Взять тот же Microsoft Scale-Out File Server.

В этих Scale-Out системах, если они построены на базе Ethernet/iSCSI, а не FC, вам придётся выстроить специфическую топологию сторадж-сетей с двумя iSCSI-сетями для MPIO и вам также нужна поддержка Offload Data Xfer стека, который выносит с проца всю работу традиционных SCSI-протоколов на ASIC адаптера сторадж-сети.

И вот это всё в последние годы начало плохо себя чувствовать из-за прихода NVMe, который теоретически поддерживает SAS/iSCSI/FC стек, но на практике он работает медленнее. А если использовать NVMe-oF (не важно через какую фабрику) не будет поддержки MPIO. Из-за отсутствия MPIO весь "SCALE" вертикальным способом (добавления новых полок и подключения к нескольким контроллерам) идёт на смарку. Это не поддерживается.

Что приводит к варианту 3, то есть программно-определяемым хранилищам вроде VMware VSAN, Ceph и Storage Spaces Direct. Эти продукты производят репликацию через RDMA-сеть. То есть у них либо InfiniBand, либо RoCE (iWarp вы в большом развертывании не найдёте). В этих хранилищах другая задача. Они по большей части оптимизируют кэш между разными тирами стораджа и не ожидают, что вы будете работать с ними как с дисками.

В итоге TrueNAS SCALE пошел по пути SMB и делает свою реализацию Scale-Out File Server, ну ksmbd им в помощь =)
Программно-определяемого хранилища я у них не вижу, потому что с отказом от Gluster функционал ничем не заменили и не планируют. И это ни хорошо, ни плохо и вот почему:

1. Программно-определяемое хранилище хорошо работает для объектных данных серверов приложений и для виртуализации.
2. Для работы с БД вам нужен SCSI-стек, ODX и прочее, чего нету в программно определяемых хранилищах. Банально, кластер серверов БД посылает команду на запись журнала транзакций в основной файл базы. Он шлёт Writethrough, чтобы очистить грязные буферы в памяти и опракинуть кэш на диски. Удачи вам с программными стораджами, NFS и SMB... Они этого не понимают. Опять же, для виртуальных БД инфраструктуры виртуализации предлагают виртуальные диски с поддержкой виртуального SCSI, но мы же про производительность думаем, а не...
3. GlusterFS - это ни рыба, ни мясо. Оно не может оптимально работать ни в одном варианте, ни в другом варианте и никто не планирует его доводить до ума и учить работать с современными стандартами железа и сетей.

Собственно, как я понимаю TrueNAS для кластеризации переходит на собственную реализацию кластера SMB и предлагает свою версию Microsoft SoFS и Storage Spaces (не Direct). Ну ок, ничего страшного. Вон Oracle продаёт аналогичные хранилки на ZFS, вроде бы на Solaris и его кластеризацией стораджа. Это всё дело вкуса.