Ещё вопрос: сейчас хосты в состоянии cpu pressure , можно ли как-то гарантировать вычислительные возможности подсистеме VSAN в этом случае?

А значение TBW в HCL в каких единицах измерения?

В TB :)

Vsan работает в ядре - он свое всегда возьмёт, потому что приоритет ядерных процессов выше, чем vmm.

Супер) Спасибо)

Вопрос про stretched cluster. В stretched cluster guide в разделе Topology L2 vs L3 указано, что для конфигурации на картинке использование L2 для witness поддерживается только в случае толстых каналов до третьего сайта. Если соединение с третьим сайтом будет медленное, то в случае разрыва соединения между сайтами 1 и 2 трафик пойдет через медленный сайт 3 и перформансу будет плохо. Это все логично и понятно, теперь собственно вопрос - поддерживается ли конфигурация если witness включен  гигабитными линками напрямую в switch 1 и в switch 2 (без switch 3)? Я так понимаю виртуальный коммутатор ESXi не будет заниматься перенаправлением пакетов между сайтами, и собственно останется в работе только preferred site.

W TB 😂

Витнесс выступает арбитром, никак не для хранения данных. У вас растянутый актив-актив кластер?

Это понятно. Кластер растянутый, актив-актив. Если схема как на рисунке - то при пропадании линка sw1-sw2 связность L2 между сайтами 1 и 2 останется через sw3 и трафик хранения vsan между сайтами 1-2 пойдет через него, и если линки до третьего сайта тонкие (как часто бывает), будут проблемы. Вопрос что будет если исключить из схемы sw3, и будет ли такая схема поддерживаемой

Почему данные должны идти через витнес? К требованию витнес предъявляются очень низкие показатели, задержка может достигать 200мс, она вообще может находится далеко в облаке, что априори означает, что данные через нее не гуляют.

If the network connection fails between the two active sites, the witness host and the preferred site continue to service storage operations, and keep data available. When the network connection returns, the two active sites are resynchronized.

В настройках Вы указываете префайред сайт. Т.е. из двух активных у вас всегда кто-то будет приоритетным. Если идет потеря линка между сайтами, для избежания ситуации сплит-брейн, витнес видя оба сайта, отдает команду продолжить работу и обслуживание дисковых операций на приоритетном сайте и соответственно гасит эти операции на «вторичном» активном сайте.

L2 связность до витнес не является минимальным требованием. Можете витнес вынести как вам будет удобно. Если у вас инфраструктура позволяет сделать растянутый L2 сегмент с высокой производительностью и низкой задержкой - стройте третий сайт. Только данные ходить через витнес не будут, а просто в рамках L2 сегмента на уровне коммутатора отработают и пойду до второго сайта через третий. Но это честно говоря жирновато и иногда бесполезно. Проще просто грамотно зарезервировать устройства в обоих цод и проложить несколькими путями оптику/несколько провайдеров/и тд

Данные пойдут не через витнесс, а через switch 3

Ну а проблема в чем? Не хотите что бы ходили данные через 3 сайт, закройте L2 доступность для данной сети/влана/сегмента, где ходит всан и весь служебный трафик

Вопрос в поддерживаемости конфигурации если switch 3 из данной схемы исключить

Он и не нужен там. Почитайте тревания к витнес. И обеспечьте ей на уровне виртуализации (или что там у вас) необходимую связность по L3 до сайтов и все.

В том то и дело что городить L3 со статическими маршрутами до витнесса не особенно хочется, если можно сделать простую схему на L2. Вопрос в поддержке. В документации прямого указания не нашёл

Собственно первоисточник: https://core.vmware.com/resource/vsan-stretched-cluster-guide#sec6-sub3