По компонентам посмотрел скриптом какие наиболее выгодные вм к переносу

тут я совсем потерялся, ну да ладно.

В общем я не вижу никаких проблем по очереди выводить хосты. Да, мигрировать нужно будет чуть дольше за счет того, что некая часть данных будет ездить несколько раз, но да и черт с ним. в 6.5 P02 уже есть Adaptive Resync, т.е. на производительность влияния оказывает мало, а на доступности вообще никак не сказывается ибо full data migration.

Тоже не понимаю, почему не выводить хосты поочередно? Даже если подумать логически, наврядли возможно наличие инструмента для данной ситуации, так как сама логика неверная: всан старается размазать данные равномерно, а тут получается, что его надо насильно заставить перераспределить данные так, что бы 3 хоста были свободные, а остальные несбалансированны.

Кстати про ресинг данных и производительность, @KulikovNikolay можете прокомментировать ситуацию?

Вопрос про sexigraf - я так понимаю проект уже закрылся, как и (видимо его предшественник) sexilog. Кто-нибудь может порекомендовать какое-нибудь актуальное бесплатное готовое решение, заточенное под мониторинг vsphere/vsan?

почему закрылся? сайт у них постоянно умирал Nov 16, 2020 https://github.com/sexibytes/sexigraf

Да, ориентировался по сайту. Спасибо!

хотелось успеть провести работы за выходные, когда рабочая нагрузка не такая большая.

простите за долгий ответ, приболел. ссылку уже дали ниже, но рекомендую потестировать версии и текущую и на релиз меньше. т.к. изменились методы сбора метрик (можно сравнить скрипты в /root).

В продолжении темы переноса. Вас не затруднит ответить по ситуации.
была попытка миграции вм с дисками такого объема (200 Гб; 5,88 ТБ; 6,64 ТБ; 21,48 ТБ) с политикой FTT=2 , Thin, с одного всан кластера на другой всан кластер. оба кластера 6.6.1, гибрид.
Перед миграцией мастер выдал ошибку что не может произвести миграцию из-за большого объема vmdk. (File is larger than the maximum size supported by datastore 'vsanDatastore2')
Нашел ответ здесь в конференции и изменил политику для vmdk на FTT=1.
и попробовал сразу снова сделать миграцию, но выдало то же самое предупреждение. следующие попытки через 2 часа и примерно 18 часов - тоже самое.
по наблюдениям объем Storage Usage в статусе ВМ не изменялся.
а вот следующая попытка через 42 часа была уже успешной. миграция началась и была успешна.
перед миграцией отметил что объем Storage Usage изменился на требуемый.
можете прояснить как работает механизм отсекания копий при смене FTT у политики, на какой временной интервал расчитывать и для чего нужна задержка.

Т.к. у служебных операций отдельная очередь и процессинг, то для него строится отдельный график. Большие latency для таких операций - норма, при условии, что latency прод нагрузки адекватная. причины для этого, как правило две - часто отрабатывает троттлинг/задержка отдельных или многих операций/блоков из-за раюоты adaptive resync, что сказывается на суммарной latency + там достаточно большие блоки на 100% write.

Тут Миша Михеев предложил еще одну мысль - перевести 2 хоста из трех в MM с режимом Ensure availability, что помешает записывать на них данные с третьего хоста (который мы переведем с Full Data Migration). Ну а после вывода одного узла, взять вторый вывести из MM и завести снова с Full Data Migration.

окей, понял. Спасибо за ответ 👍

спасибо! можно попробовать . как я понимаю ClomRepairDelay потребуется поставить побольше на двух хостах

а 3 хоста сразу в ММ нельзя отправить с Full Data Migration?

у нас политики не все с FTT 2,  что то еще  осталось на FTT 1. меня могут поправить, но вроде как три вместе не получается.

хм
а как FTT влияет на ММ?
15 хостов
компоненты ВМ размазаны от 3 до 6 хостов каждый
даже если и совпадет что вм с ftt=1/mirroring полностью попала на 3 хоста. которые уходят в ММ - в режиме Full Data Migration хост же не уйдет в ММ, пока компоненты с него не уедут...
или не хочется рисковать что все компоненты одной вм едут одновременно?

насколько я понимаю у нас RAID 1 из , например. трех RAID 0 цепочек компонент . если компоненты трех RAID 0 будут на выводимых хостах то как я понимаю целиком весь RAID 1 будет порушен.
к сожалению вывод Get-VsanComponent в powercli не дает мне понять какой компонент в какой рейд группе. для того чтобы это рассчитать придется парсить например  вывод с RVC (vsan.vm_object_info). пока не это нет времени

FTT действительно никак не связан с MM. И увести можно любое число хостов в MM независимо от FTT (при условии, что есть хосты куда писать/копировать). Но тут проблема в другом. Ты не можешь ОДНОВРЕМЕННО увести 3 хоста в MM. Ты всегда это делаешь по очереди (даже если очень быстро). И это приводит к следующей логике - хост уводим в MM. В CLOM идет запрос на перераспредленние объектов - тот выдает план миграции взависимости от условий (увезем вот эти компоненты вот сюда). Это показывается на этапе precheck. Если все норм и выполнение такго перераспределения возможно без нарушений условий задачи (соблюдение storage policy, доступность объектов, хватит места и т.д.), то мы жамкаем OK и CLOM передает задание на миграцию в DOM и тот начинает переливать данные и изменять структуру обращений к этим данным со стороны ВМ. Проблема в том, что он может запустить процесс записи на узел, который ты захочешь перевести в MM спустя 2 минуты. Но CLOM не даст этого сделать, потому что будет нарушены требования по доступности/соответсвия требованиям ранее расчитанным (выглядит как ошибка перевода хоста в MM). А в логике самого CLOM не заложен расчет перервода в MM нескольких узлов (т.е. на этапе первого расчета мы не можем сказать «»а расчитай ты нам карту миграций при учете, что мы выводим в MM вот эти N-хостов разом)