Я дал ссылку на pdf, где подробно объясняется как распределяются vCPU по ядрам процессоров

Если не прибить гвоздями, то те, которые простаивают.

тут искать?

бинго!

понял

Если у ВМ всего 1 виртуальный сокет, то при увеличении vCPU, исполнение машины будет производиться на одном физическом процессоре исключительно на его физических ядрах без использования технологии Hyperthreading. При превышении количества vCPU над количеством физических ядер процессора, ВМ продолжит исполняться в пределах этого физического процессора, но уже с использование Hyperthreading. Если количество vCPU превысило количество ядер процессора с учетом Hyperthreading, то начнут использоваться ядра соседних NUMA нод (других физических процессоров), что приведет к потере производительности (если указать неверное количество виртуальных сокетов). В случае, когда физический процессор сильно нагружен, и свободных физических ядер не осталось, то в любом случае будет использоваться технология Hyperthreading (если иное не указано в конфигурации виртуальной машины). Если посмотреть на цифры, то в среднем ВМ теряет порядка 30-40% производительности, если она работает на чистом Hyperthreading по сравнению с чистыми физическими ядрами. Но сам физический процессор имеет общую производительность примерно на 30% больше с технологией Hyperthreading, чем без нее (используя только физические ядра). Данный показатель очень зависит от типа нагрузки и оптимизации приложений ВМ к многопоточной работе.

это верное утверждение?

Дмитрий, это оффтопик

Тут группа по вопросам VSAN

Вам уже несколько раз на это указали

предлагаю перенести в @vmugru

Ну и полезных ссылок вам коллеги предоставили уже прилично

Так. Мне опять прилетела на днях эта статья и я не сдержался.
По факту, вся эта статья сводится в следующим 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 на нагруженном кластере с "тяжелыми" по емкости узлами).

Но при этом, надо отметить, что процедура обновления всего кластера с опцией Full Data Migration может делаться полностью в автоматическом режиме без участия оператора - запустил один раз и он поехал обновлять один за другим кластер. В случае, если что-то идет не так, то обновление останавливается.
С другой стороны в режиме Ensure Accessibility время вывода хоста в режим обслуживания значительно меньше (нет принудительной миграции данных для которых настроена политика отказойчивости). Данный режим целесообразно выбирать если вы настроили политику FTT2 (RAID6/RAID1 tiple mirror). В таком случае данные останутся целыми даже если при выводе сервера в режим обслуживания откажет еще один сервер, то есть риск получить неконсистентные данные минимален. По нашему опыту на all-flash кластерах как раз чаще всего используется политика RAID6, поэтому данный данный режим вполне востребован.

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

А если взять 16-24 хоста кластер, то про это можно забыть

Но тема спорная, разумеется

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

ftt 3)

не везде, но есть