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

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

то-есть автоматизировать это нельзя?

нужно настроить политику хранения + мониторинг с алертами и реагировать соответствующим образом

ну вот, все ясно :)

хот спаре где ? в рейде ? рекомендуют вообще делать прямые диски

если есть свободое место то всан сам перестроится , если нет то нет

меня интересует, есть ли смысл в хостах vsan иметь запасные диски, и что это дает

hot spare наверно не корректно, согласен

можно, но слегка извращенным способом - отключаете hba mode, из двух кешей делаете R1, каждый капасити делаете как R0

Не соврал выходит

Добрый день!
Mеня зовут Алексей Радченко, я работаю в VMware Global Support Services и буду помогать Вам в решении Вашей проблемы.

На текущий момент эта проблема на стадии решения. В последних версиях были некоторые изменения, которые повлекли за собой эту проблему. Комментарий инженеринга:
===
Restore the earlier behaviour of having same iqn for an iSCSI adapter across reboots

If iqn is not set by the user then we generate a unique and random iqn.
Earlier (before moving to config-store), this generated iqn was consistent
and not changing across reboot because it was stored in vmkiscsid.db.
But now it changes after reboot because currently we delete entries from
vmkiscsid.db (except 'isid' and 'internal' table entries) on boot. Through
this fix we are restoring the earlier behaviour by storing the generated
iqn inside internal table.

====
Это поведение будет исправлено. На текущий момент имеется несколько обходных решений:
1. Не проводить обновление. На текущий момент VMware не рекомендует обновление до версии 7.0 U2, так как в нем были выявлены еще некоторые проблемы - https://kb.vmware.com/s/article/83063. Возможно, по этому Вы и видите информацию о бета тестировании.
2. Презентовать LUN по IP или другим параметрам, не используя IQN.
3. Сделать параметры iqn статичными. Для этого необходимо выполнить для каждого iSCSI адаптера команду:
esxcli iscsi adapter set -A vmhba64 -n iqn.1998-01.com.vmware:....

Рекомендованный вариант - не проводить обновление до выхода следующего патча, который должен закрыть эту и другие проблемы.

нет, не имеет. ничего не дает.

Это сверх-эффективный способ выкинуть деньги, а заодно слететь с поддержки.

У вас по сути hot spare - все диски во всем кластере, а ребилд  начинается автоматически при сбое диска. А ребилд не пойдёт только когда у вас физически место во всем кластере кончится, но в таком случае у вас уже проблемы. P.s хотя в нынче есть operation reserve, который несколько мешает заполнить так, чтобы не куда было ребилдится

спасибо! все ясно.

👍

Знаю что от Вас можно получить квалифицированный ответ, есть два вопроса, допустим есть всан из трех нод два допустим по 10 тб и один на 20, так можно? Что будет если диск выпадет?
И ещё, если часть нод ssd часть hdd, как оно балансировать будет?

Если на 3х узловом кластере выпадет диск в одним из серверов, то начнётся ребилд (если конечно место есть на других дисках на этом узле)