Size: a a a

2021 April 19

AK

Alexander Kupchinets... in VMware vSAN
те команда убрать 2й и 3й хост в ММ не заставит CLOM прервать процесс эвакуации данных с хоста 1
источник

N

Nikolay Kulikov in VMware vSAN
И это даже тянет на feature request, потому что смысл в такой логике присутствует, но ИМХО это настолько редкий и специфический кейс, и с настолько простым workaround («забейте и спокойно переводите три хоста по очереди, а то что чуть больше данным скопируется - мало на что влияет»), что я не очень верю в его реализацию. В формате чего-то большего - что-то типа, массовое обновление всех хостов в FD/AZ через vLCM/VCF  смысл может появится, но тут надо подумать, потому при том же обновлении будут делать не Full Data Migration, Ensure Accesability, что сводит на нет весь смысл описанного выше.
источник

N

Nikolay Kulikov in VMware vSAN
неа. Ну по крайней мере, раньше это было так. Потому что задачи служебные/процессные связанные с доступностью/консистентностью данных имеют намного больший приоритет по сравнению с задачами по штатному обслуживанию отдаваемые оператором, что прекрасно защищает от стрельбы по ногам (хотя руками перевести хост будет все равно можно, только не в режиме по умолчанию, а с do nothing опцией, но тут ССЗБ и он еще покажет где именно у вас появится дырка в ноге). Тем более появилась бы обратная проблема - пусть мы делаем миграцию, а потом на 99% случайно жмем перевод другого хоста в MM и весь прогресс теряется и мы начинаем заново эвакуировать данные куда-то еще.
источник

N

Nikolay Kulikov in VMware vSAN
Это не совсем так работает. Если вы переводите хост с Full Data Migration, то он СНАЧАЛА отстраивает новые объекты (всю половину R1 для FTT=1), а только потом выключает узел/удаляет данные. Поэтому даже в режиме FTT=0 вы можете вывести несколько хостов в MM залпом, главное чтобы на эти узлы данные не лились в процессе эвакуации, потому что ругнется (см. выше).
источник

SK

Sergey Kraev in VMware vSAN
спасибо за разъяснение
источник

SK

Sergey Kraev in VMware vSAN
@KulikovNikolay вас не затруднит еще прояснить по вопросу выше ? https://t.me/VMwarevSAN/19832
Telegram
Sergey Kraev in VMware vSAN
В продолжении темы переноса. Вас не затруднит ответить по ситуации.
была попытка миграции вм с дисками такого объема (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 у политики, на какой временной интервал расчитывать и для чего нужна задержка.
источник

N

Nikolay Kulikov in VMware vSAN
С отсеканиями копий  все просто - если это зеркала, то бах! и сносим все компоненты одной из копий. Если это Erasure Coding->Mirror или наоборот, то сначала создаем новый целевой объект, а потом удаляем старый
источник

N

Nikolay Kulikov in VMware vSAN
источник

N

Nikolay Kulikov in VMware vSAN
Про учет vMotion места с FTT - в 7.0 оно учитывалось при vMotion, а для U1-U2 надо посмотреть/проверить на стенде
источник

SK

Sergey Kraev in VMware vSAN
Если это быстрая операция тогда почему миграция не началась сразу?  расчет у storage vmotion все равно выдавал превышение как на vsandatastore так и на обычный с СХД
источник

N

Nikolay Kulikov in VMware vSAN
а про задержку - 🤷 надо смотреть/читать/разбираться
источник

N

Nikolay Kulikov in VMware vSAN
а вы политику на каком кластере меняли? Целевом (куда мигрировали) или исходном (от куда)?
источник

SK

Sergey Kraev in VMware vSAN
на исходном , для самого большого по размеру vmdk на ВМ
источник

SK

Sergey Kraev in VMware vSAN
сделал как написали здесь https://t.me/VMwarevSAN/10662
источник

N

Nikolay Kulikov in VMware vSAN
да, это понятно. И для 6.6.1 - это точно так. Изменилось ли что-то сейчас - не проверял, не знаю. Аоткуда взялась задержка, честно говоря, не знаю. надо смотреть внутренности, логи и т.д.
источник

SK

Sergey Kraev in VMware vSAN
понял. действительно возможно это будет неактуально после апгрейда vSAN
источник

N

Nikolay Kulikov in VMware vSAN
не уверен, честно говоря, что это пофиксили. потому что формально - это не баг, а «особенности расчета места». Хотя стоило бы.
источник
2021 April 20

E

Eminov in VMware vSAN
источник

D

Dmitry in VMware vSAN
Коллеги, AF vSAN кластер 7.0 update 2 в продуктиве кто-то уже использует? Или всё ещё "тех.поддержка не рекомендует"?
источник

МЧ

Михаил Черноусов... in VMware vSAN
Приветствую. Подскажите кто небудь сталкивался с такой ошибкой на vsan 7.0 update 2.   vSAN Build Recommendation Engine Health VMware Update Manager (VUM) is disabled or is not installed.
источник