а зачем делать full migration для обновлений ? Ensure Accessibility при ftt=2 вполне себе. Я вот прям не знаю, есть смелые люди у кого в проде ftt=1 ?

ftt 2 стандарт

Это ж золотой висан получается.

да прям. dedup/compression делают своё дело ) но если на гибриде то да, возможно будет несколько дороже, хотя...

Так. Мне опять прилетела на днях эта статья и я не сдержался.
По факту, вся эта статья сводится в следующим 4-м пунктам про vSAN (комментировать работу Nutanix я не хочу и не буду):
1.) Storage upgrades are independent of the hypervisor meaning no hardware reboots or host evacuations are required.
2.) vSAN requires VMs be evacuated from the host to perform storage upgrades
3.) vSAN requires bulk movements of data for some on-disk format changes
4.) vSAN does not maintain write I/O integrity during upgrades unless customers use the “Full Data Migration” option which requires significantly more free capacity (slack space) within the environment & causes upgrades to take significantly longer and have a higher impact.


1.) Storage upgrades are independent of the hypervisor meaning no hardware reboots or host evacuations are required.

Данный подход не дает явных преимуществ с точки зрения процесса обновления. VMware vSAN обновляется вместе с гипервизором (так как по факту vSAN и является функцией гипервизора) вместо того, чтобы обновлять сначала SDS, а потом отдельно гипервизор. При этом каждый пакет обновлений содержит исправления как для гипервизора, так и для программного хранилища (SDS), то есть общее количество обновлений, которые надо устанавливать, а соответственно трудозатраты/maintenance window меньше. К тому же такой подход полность решает проблему совместимости компонентнов гипервизора и SDS - обновления выходят в одном пакете и проходят совместное тестирование у вендора.


2.) vSAN requires VMs be evacuated from the host to perform storage upgrades

Процедуры обновления дисковой подсистемы, например, обновление версии файловой системы (см. следующий пункт) на дисках не требуют vMotion ВМ с этого хоста. Вы можете хоть отключить все дисковые группы на узле, а ВМ продолжат работать без изменений. Миграции требует процедура обновления гипервизора (см. прошлый пункт), но это справедливо для любой системы.


3.) vSAN requires bulk movements of data for some on-disk format changes

Что касается обновления файловой системы. Эвакуация данных при обновлении ФС требовалось всего два раза за 6 лет существования vSAN, при учете что сейчас 8-ая по счету версия файловой системы:
• При обновлении vSAN с первой версии на вторую в марте 2015 года, когда произошла смена файловой системы VMFSL на VirstoFS.
•  При обновлении vSAN с 6.1 (ESXi 6.0U1) на vSAN 6.2 (ESXi 6.0U2) в марте 2016 года, когда появились снепшоты vSANSparce, дедуп и компрессия, и внутренний блок увеличился до 1MB.
С весны 2016 года обновление версии ФС, которая происходит с каждым крупным обновлением не требует эвакуации данных. Это просто апдейт метаданных.
https://storagehub.vmware.com/t/vsan-6-7-upgrade-considerations-1/vsan-on-disk-format-versions-and-data-services-2/


4.) vSAN does not maintain write I/O integrity during upgrades unless customers use the “Full Data Migration” option which requires significantly more free capacity (slack space) within the environment & causes upgrades to take significantly longer and have a higher impact.

При проектировании продуктивных кластеров в любом случае нужно учесть наличие свободного места (free capacity/slack space) не менее, чем полезный объем, получаемый с одного сервера, что можно было сделать rebuild при отказе как минимум одного узла, эта рекомендация никак не зависит от того, какой тип вывода сервера в режим обслуживания выбирает пользователь.
Full Data Migration обеспечивает максимальный уровень доступности, по сравнению с альтернативными опциями, потому что сбой другого узла во время обслуживания одного не приводит, в том числе, и к простою. При этом такой подход (что логично) может заметно увеличить время обновления за счет миграции данных (особенно rolling-update на нагруженном кластере с "тяжелыми" по емкости узлами).

четвертый пунт не о том что все равно надо иметь запас по пространству, а о целостности данных. При изменениях данных (часть которых - копия на хосте в мейтенс моде) они пишутся только на активный хост и не дублируются. Соответственно если у нас что-то случится с диском на активном хосте и будет корапт даных то у нас не будет для них копии

четвертый пунт не о том что все равно надо иметь запас по пространству, а о целостности данных. При изменениях данных (часть которых - копия на хосте в мейтенс моде) они пишутся только на активный хост и не дублируются. Соответственно если у нас что-то случится с диском на активном хосте и будет корапт даных то у нас не будет для них копии

четвертый пунт не о том что все равно надо иметь запас по пространству, а о целостности данных. При изменениях данных (часть которых - копия на хосте в мейтенс моде) они пишутся только на активный хост и не дублируются. Соответственно если у нас что-то случится с диском на активном хосте и будет корапт даных то у нас не будет для них копии

Вся проблема многочасовых фулл миграций в том, что данные складываются по 255гб и неравномерно по хостам, что делает фулл миграции в принципе невозможными для патчинга каких-либо кластеров более скажем 8 хостов

почему Х себе это позволить может, а вмварь нет? Потому что размеры разных по 255гб