а то как-то странно

ok, интересно поведение без дедупа

у меня нет дедупа, гибридный vSAN

супер

можно тогда в личку прислать параметры запуска и попробую чуть позже

Нет, там общее заполнение.

Без дедупа used = written x FTT

тэкс... я опять к вам пришел со странными вопросами )
Представим что есть не очень заполненный кластер. На каждом capacity диске утилизировано примерно 20%. У нас 2 DG на хост. В 1 DG вылетает диск, мы ее теряем, но это не проблема, ребилд прошел. Но!, теперь у нас на этом хосте сильно утилизированная оставшаяся дисковая группа на которой стало примерно в 1,5 раза больше компонентов и утилизированного места чем на остальных DG в кластере. Соответственно IO на эту DG теперь попадает куда больше, даже если мы оживили вторую DG.  Вопрос - как то vSAN умеет в ребаланс DG в зависимости от кол-ва компонент или только по дельте заполнения умеет ?

Вообще хорошо бы он умел еще hot spotы вычислять, и равномерно их размазывать, но это я уже так, придираюсь )

Откуда выводы:
- что при вылете диска мы теряем DG?
- при вылете 1 DG на хосте на оставшуюся пойдёт больше IO?

Нет. Согласно политикам он раскидывает данные по остальным DG и повышения нагрузки на оставшуюся в одиночестве DG на хосте не происходит.

я забыл написать что dedup включен. ну если нагрузка на ВМ примерно одинаковая то ответ очевиден, мне кажется.

Тогда да, вся ДГ «пропадает»
Нагрузка ляжет на все оставшиеся ДГ
Если хостов достаточно для выполнения FTT - IO и ребилд пойдёт равномерно на все оставшиеся ДГ
Если было 3 хоста и ftt=1 с mirroring или 4 хоста и ftt=1 c EC - тогда да, ребилд придётся делать в оставшуюся ДГ на тот же хост

Ага, и когда мы вернем "восстановленную" DG на ней ничего не будет и нагрузка будет продолжать идти только на первую DG пока мы не создадим еще новых ВМ или не сработает threshold по rebalance (который учитывает только дельту по месту)

Количество компонентов +- равно утилизации по месту, потому что компоненты примерно +- одинаковые по размеру. Включите автоматический ребаланс и поставьте трешхолд (я бы оставил дефолтный 30%).

Вопрос в том, что hot spot - существует в моменте - неделю его нет, а потом 5 минут есть. Или нет. Заранее предсказать это невозможно. А миграция данных занимает время и создаёт доп. Нагрузку именно на те компоненты и тогда, когда с них нужна максимальная производительность

После хот спот может позникнуть уже в другом месте, потому что опять таки заранее предсказать что и как будет генерировать нагрузку невозможно

при низкой утилизации по месту можно долго ждать 30%

При низкой утилизации по месту запаса Performance - вагон

хорошо бы кол-во компонентов как то учитывать