Size: a a a

2021 January 06

N

Nikolay Kulikov in VMware vSAN
Если вам нужно, чтобы другая ВМ могла писать на этот диск, то раздайте его по nfs с гостя и подключите, как сетевой диск в этой самой второй ВМ
источник

AJ

Alex Juk in VMware vSAN
Тоже как вариант
источник

AJ

Alex Juk in VMware vSAN
В любом случае спасибо за инфу и наводку
источник

A

Artur in VMware vSAN
кстати, пока тут активно...
Кто чем смотрит smart ssd дисков?
источник

N

Nikolay Kulikov in VMware vSAN
esxcli storage core device smart get -d?
источник

N

Nikolay Kulikov in VMware vSAN
И вообще - зачем в него смотреть?
источник

N

Nikolay Kulikov in VMware vSAN
Если он плохой, то алерт вылезет через cim. А если хороший, то хороший
источник
2021 January 07

VD

Vladimir Deneko in VMware vSAN
Alexander Kupchinetsky
Я бы сказал это скорее про способ раскидывать низлежащие данные, но не работа с самими файловыми сервисами, нет? Чтобы раскидывать сессии primary ip должен как-то раскидывать их между блоками/стойками, но таких настроек вроде как нет, да и сказано что шара обслуживается только одним файловым сервером, но по событиям  видимо в момент сбоя она раскидывает через nfs4 referrals, так?  Или в них уже как-то берутся узлы исходя из awareness?
источник

N

Nikolay Kulikov in VMware vSAN
Vladimir Deneko
Я бы сказал это скорее про способ раскидывать низлежащие данные, но не работа с самими файловыми сервисами, нет? Чтобы раскидывать сессии primary ip должен как-то раскидывать их между блоками/стойками, но таких настроек вроде как нет, да и сказано что шара обслуживается только одним файловым сервером, но по событиям  видимо в момент сбоя она раскидывает через nfs4 referrals, так?  Или в них уже как-то берутся узлы исходя из awareness?
А в чем смысл rack awareness для самих файлеров, а не для самих данных за исключением stretched cluster?
источник

N

Nikolay Kulikov in VMware vSAN
От чего мы защищаемся?
источник

MD

Mista D in VMware vSAN
Nikolay Kulikov
2.) RDM (vRDM или pRDM)
который отдается в вм как vmdk ;)
источник

VD

Vladimir Deneko in VMware vSAN
Nikolay Kulikov
От чего мы защищаемся?
От сбоя блока/стойки, чтобы файловые сервисы продолжали быть доступны при сбое отдельных компонентов, особенно если это единый кластер для хранения и вм, например те же контейнеры и нфс или vdi и профили. Как быстро узнается о недоступности, невозможности использовать вышедшие из строя узлы, например блока? Нужно увеличивать таймауты, чтобы дошло до рабочего узла?
источник

N

Nikolay Kulikov in VMware vSAN
Vladimir Deneko
От сбоя блока/стойки, чтобы файловые сервисы продолжали быть доступны при сбое отдельных компонентов, особенно если это единый кластер для хранения и вм, например те же контейнеры и нфс или vdi и профили. Как быстро узнается о недоступности, невозможности использовать вышедшие из строя узлы, например блока? Нужно увеличивать таймауты, чтобы дошло до рабочего узла?
Если у тебя сбойнула стойка, но при этом настроены fault domains, то файлеры по прежнему будут доступны - они просто перезапустятся на остальных выживших узлах. Этот сценарий абсолютно аналогичен тому, как у тебя вышел из строя один Хост просто затронет больше шар, но не приведет к не доступности
источник

К

Константин in VMware vSAN
А тут инженера и представили VMware имеются ?
источник

К

Константин in VMware vSAN
Всем добрый день
источник

MD

Mista D in VMware vSAN
зал замер
источник

N

Nikolay Kulikov in VMware vSAN
Константин
А тут инженера и представили VMware имеются ?
Не смотря на то, что технически они тут имеются - данный чатик не может считаться официальным каналом обращения к ним. Если вам нужно официальный вопрос/ответ с представителями вендора - welcome в почту. А Тут мы просто отдельные персоналии с личным индивидуальным мнением, который может не отображать мнение работодателя
источник

К

Константин in VMware vSAN
Понял ) благодарю )
источник

N

Nikolay Kulikov in VMware vSAN
Email могу подсказать, если что ;)
источник

N

Nikolay Kulikov in VMware vSAN
Nikolay Kulikov
Если у тебя сбойнула стойка, но при этом настроены fault domains, то файлеры по прежнему будут доступны - они просто перезапустятся на остальных выживших узлах. Этот сценарий абсолютно аналогичен тому, как у тебя вышел из строя один Хост просто затронет больше шар, но не приведет к не доступности
В общем, за счёт текущего дизайна и stateless самих fsvm и nfs/smb контейнеров в нем, то никакого rack awareness не нужно - весь функционал связанный с state, изоляцией/партиционироварием и т.д. На уровне стандартных storage policy + vdfs в ядре. Единственное, где это требуется - растянутый кластер, чтобы избежать доп задержки на rtt при чтении и нагрузки на isl. Там хочется, чтобы запросы на шару с сайта 1 не бегали на контейнер на сайте 2. Это есть в ближайших планах.
источник