Вопрос вообще про VC 6.7, хосты 6.5.

Если Коля говорит, что все хокей, это поддерживаемая тема и можно так оставлять на длительный срок, у меня больше комментариев нет.

- доктор, меня все игнорируют
- следующий

есть что сказать по данному вопросу ?

Я задал вопрос внутри ) Посмотрим что нам скажет тот, кто за это отвечает со стороны GSS ) Может, действительно, придется голову пеплом посыпать ))))

В общем, как уже нафлудили/обсудили ниже. Да, vCenter можно оставлять старшей версии без апдейта vsan. Перед любым обновлением vCenter стоит сделать его файловый бекап, чтобы откатиться при необходимости (и вообще это полезная привычка - настройте сразу в 6.7 бекап по расписанию). База объектов не живёт в vCenter, они живёт на каждом хосте vsan кластера. Ровно как и конфигурация хостов в кластере, поэтому она разъехаться не может. Что может произойти - если вы создали ВМ после обновления, то при даунгрейде они будут не зарегистрированны в vCenter (но работать будут, как обычно). В этом случае, регистрируем ВМ и все. Если у вас изменился состав кластера, то вылезет алерт в health check. Читаем что там пишут, добавляем хосты в кластер vCenter, что бы кластер vsan и vCenter совпадали и жмём синк.

Спасибо

Честно говоря, надо посмотреть внимательнее , но записи при удалении данных (только я не смотрел при удалении всех данных, а при удалении только части данных) с включённым дедупом и компрессий - это естественно. При удалении данных у вас пересчитывается metadata и обновляется таблица с указанием адресов блоков. Скорее всего, процесс удаления всех данных не одномоментный, а последовательный, поэтому таблица и пересчитывается пока это происходит. Поэтому же, при отсутствии дедупа такого нет. То, что при выключении vsan ничего не меняется - это правильное поведение, потому что выключение vsan ничего не делает с самими данными на кластере, только убирает точку монтирования vsan datastore на хостах кластера - это "защита от дурака", чтобы случайно жамкнув одну кнопку не потеряли данные. При удалении дисковой группы происходит её форматирование, потому что удалить все дисковые группы "случайно " - надо постараться. Но честно говоря, я пока до сих пор не могу понять в чем проблема - удаление в продуктиве всегда происходит частично и при этом, метаданные надо пересчитывать, отсюда и запись. Ресурс ssd?  однократная (вы же не заполняете, а потом удаляете все данные в кластере залпом в проме каждый день) запись на диски по определению не может хоть сколько нибуть заметно  снизить endurance. Но я спрошу у наших PM, может быть есть другое объяснение.

ok. если будет еще что - пиши, я заинтригован )

но вот при _выключении_ vsan можно было бы все фоновые процессы vsan тормозить. я вот ни одной причины не могу найти почему бы этого не делать.

Это нужно, чтобы после включения vsan обратно все данные были доступны, консистентностны и готовы к работе, а не стояли в непонятном состоянии

а все данные или не все удалять тут разницы ни какой, на самом деле.

сколько удалите столько же, примерно, и получите записи на диски

Уважаемые коллеги. Что-то подзабыл. Если vsan выдает warning на адаптеры, а esxi установлен с dellemc custom image. Качаем дрова по ссылкам hcl vsan и ручками ставим? Или же накатываем последний custom image, а уже потом (Предустановлен предпоследний) накатываем ручками. Железо vsan ready node

Операцию делал давно эту

Там так-то словами пишут, почему варнинг горит

На hba330 firmware ставится из update manager. Драйвера тоже можно ставить через VUM отдельным baseline.

в общем все равно, главное, чтобы прошивка была из HCL