Иными словами all flash с производительным ssd в кэше, это будет так себе история?

Нет. В кэше (точнее буфере) быстрые ssd нужны и глубокие очереди тоже нужны. Поэтому обычно под нагруженные системы ставят  sas или nvme

А вот в capacity - да. Смысла намного меньше

Тут дело в том, что, как минимум, каждые 255gb создаётся новый компонент.

ну это понятно. а если диск маленький ? до 255 гб

Тогда да, страйпинг. Но вот я что то не видел много задач, когда нужно выжимать очень много Performance на чтение C ВМ c диском в 10gb.

И то плясками это назвать сложно. Create new storage policy - assign storage policy на vmdk. Всё.

ну это было образное выражение

И мы автоматом получаем 24 диска на бекенде под 1 ВМ

а когда ребилд большой пойдет - как себя sata и нагрузка будут чувствовать ?

он через кэш идет ?

Нормально, ибо пойдёт все равно через быстрый буфер

А на бекенде опять 8-16 дисков по 500MB/s

Но вообще надо не на throughput, а iops

Небольшой вопрос, возможно кто-то сталкивался с таким поведением.

Есть небольшой гибридный кластер vSAN из 7 нод.
В качестве транспорта на каждой ноде используется Mellanox ConnectX-3 Pro 2x10Gb под трафик виртуальных серверов и ConnectX-3 Pro 2x40Gb под трафик vSAN.

Также используется два коммутатора Mellanox SX1012.
На портах коммутатора, которые используются для передачи трафика vSAN наблюдается увеличение счетчика Inbound packets discarded. При этом на портах, через которые идет трафик виртуальных серверов этот счетчик не меняется.

Multicast or Unicast используете в vSAN?

Unicast

vMotion не через те же сетевухи что и VSAN Traffic ?

Через ту же, но по двум разным портам сетевого адаптера. Под vMotion Active является Passive для vSAN и наоборот

наблюдали на Juniper QFX при старте vMotion рост ошибок на портах
в итоге вендор ответил что-то вроде: да QFX при появлении новых маков на доли секунды становится хабиком 🙈