Из этого предложения неясно, есть ли у вас аппаратный RAID5 с ZFS поверх него, или RaidZ1, что-то вроде RAID5. В любом случае — это не работает хорошо. Никаких шансов! Моя рекомендация, как я уже много раз упоминал здесь на форуме: используйте HBA, а не аппаратный RAID — убедитесь, что PVE видит все физические диски во время установки, создайте один ZFS пул из зеркальных vdev (похоже на RAID10) — и используйте все HDD для этого; в итоге каждый диск будет загрузочным, что очень удобно, правда ведь? После первоначальной настройки добавьте быструю "специальную конфигурацию", хотя бы зеркальную. Это критически важно! Используйте два NVMe, если возможно, или два SATA. Используйте устройства "корпорационного класса" с PLP для этого. Это нужно делать в командной строке, насколько я знаю. Вы найдете туториалы, если поищете... Это единственный подход, который я знаю, который потенциально (!) может обеспечить приемлемую производительность для общих задач. Обратите внимание, что только HDD сейчас просто недостаточно.

Все восемь - точно одна и та же модель? Контроллеры, к которым они подключены, идентичные? Думал ли ты о том, что HDD-шки просто могут оказаться недостаточно мощными для твоей нагрузки?

Я читал, что для Ceph рекомендуют использовать несколько HDD, но большей емкости, а не много маленьких. И там говорится как минимум о 3 нодах. Честно говоря, в интернете я нахожу разные мнения на этот счет.

На самом деле, я подумывал о том, чтобы добавить SSD для DB/WAL, что, как я понимаю, должно увеличить производительность.

Мне кажется, что лучше использовать ZFS в RAID10, а не Ceph?

Я бы хотел сделать ZFS raid 10 пул из 4 жестких дисков на 16 ТБ, а затем добавить 1 ТБ SSD для bd/wal, чтобы увеличить производительность. Возможно ли это сделать с ZFS?

Ладно. Это некорректная терминология. В ZFS есть необязательный CACHE, который является "только для чтения" устройством кэширования. И есть SLOG, "Separate LOG для ZIL (ZFS-Intention Log)". Оба обычно НЕ рекомендуются, так как работают не так, как ожидается - чаще всего. Cache — это расширение второго уровня для ARC (adaptive replacement cache), который всегда находится в оперативной памяти. Когда вы создаете вторичный Cache, ему также нужна оперативная память. Эта оперативная память отнимается у системы --> остается меньше оперативной памяти для обычного ARC. Добавление большого Cache может замедлить работу вашей системы. Рекомендация: увеличьте оперативную память до максимально возможного объема. Только после этого переоцените (научитесь читать вывод arc_summary) полезность второго уровня Cache. SLOG часто понимают как кэш для записи, чем он и не является. SLOG обычно работает только на запись. Данные с него никогда не считываются. Единственное исключение: если произошла потеря питания, и данные были записаны в SLOG, но еще не на основной диск. В этом случае данные считываются при следующей загрузке при импорте пула. Еще один аспект: SLOG ускоряет только SYNC записи. "Обычные" записи асинхронны, и SLOG тут ни при чем. Стоит отметить, что ZIL существует и с выделенным SLOG, и без него. Без выделенного SLOG ZIL находится на данных-дисках. Это основная причина, по которой SYNC записи работают медленно, и отдельный SLOG мог бы помочь с этим. В #3 я уже упоминал "Special Device". Это моя рекомендация. Оно должно быть хорошего качества (зеркальное и с PLP) поскольку потеря такого устройства означает потерю всего пула.

Интересно, почему они спонсируют Ceph, если он не делает то, что обещают? Но даже используя диски Dichi SDD серии enterprise ситуация всегда трагичная?