на 12 дисков которые есть - минимальный вариант 2дг (1+5)
можно сделать 3дг (1+3)
можно сделать 4дг (1+2)
можно сделать 2 ДГ 1+4 и 1+6 или 1+3 и 1+7 - работать будет. но 2(1+5) будет более предсказуемо
1 дг (1+11) сделать нельзя

если несколько нод будет 2*(1+5),а несколько - 2*(1+4)

тоже можно, но опять-таки общая рекомендация: чем однороднее конфигурация в кластере - тем лучше.

ок, спс

ох уж эти маркетологи 🙂

много кто “лидеры”

а емкость будет как-то ограничена в таком случае?

Нет. Сырая емкость = емкость всех capacity девайсов во всех хостах - пару процентов на файловую систему и метаданные.

Целых два 😂

А в 7 условная «скорость работы всана» все так же скейлится с ростом количества DG на хост?

Я не знаю, что вы имеете ввиду под "так же", но да, сейчас там практически линейный рост
до 3-4 DG (под seq нагрузками до всех 5), потому что 1 DG - это отдельное устройство на запись + полностью отдельный и независимый обработчик всех IO. Но разумеется это зависит от тестового сценария и профиля нагрузки. Т.е. Пока мы не упремся в DOM - увеличение числа дисковых групп будет линейно увеличивать производительность.

«Так же» это в сравнении с 6 версией

Спасибо!

Тогда не совсем :) за счёт performance оптимизаций в 7.0 и u1 там в целом ряде случаев она стала "линейнее" и "больше", но суть - да, не изменилась.

вот этот “упор в DOM” обычно где-то на 4-5 DG. Больше групп не имеет смысла с точки зрения производительности (пока еще больше недооптимизируют компоненты)

можно не принимать мои слова за факт, т.к. подтвердить не смогу))

А больше 5 и нельзя 🙂

а, точно. мне говорилось значит или про больше 5 дисков в DG нет смысла, или больше 3 DG

Но в целом, вы правы - 3-4DG - оптимально с точки зрения производительности на реальных нагрузках