N
Alexander Ts
прикольно, ни один объект не лежит на том хосте, где вм запущена
разумеется, и не должен
Size: a a a
2020 December 11
N
Хм, а если объекты лежат не на том хосте, на котором на данный момент находится VM, как пойдет io path?
ровно, как написано на слайде выше
EZ
Там указана ситуация, при которой H1 является владельцем объекта и на нем же живет VM. А если VM живет на H4?
N
У вас на хосте, где работает ВМ всегда находится DOM Owner, но не сам компонент
EZ
ага
EZ
то есть prepare операция будет отправлена на H1 и H2?
N
Там указана ситуация, при которой H1 является владельцем объекта и на нем же живет VM. А если VM живет на H4?
Тогда DOM Owner уедет на H4, а компоненты будет по-прежнему лежать на H1 и H2
AT
разумеется, и не должен
почему не должен?
N
Alexander Ts
почему не должен?
А почему он должен быть там?
EZ
Кстати, может немного глупый вопрос - поскольку VSAN все же объектный сторадж, как реализовано версионирование объектов (если оно там, конечно, есть)?
AT
А почему он должен быть там?
хоть какой-то объект (диск, конфиг) может же быть расположен на хосте, где вм запущена? Не должен, а может?
Если нет. тогда при vmotion вм между хостами происходит еще и перемещение объектов
Если нет. тогда при vmotion вм между хостами происходит еще и перемещение объектов
N
Кстати, может немного глупый вопрос - поскольку VSAN все же объектный сторадж, как реализовано версионирование объектов (если оно там, конечно, есть)?
Есть. У каждого компонента есть CSN (configuration sequence number)
EZ
О, спасибо.
N
Alexander Ts
хоть какой-то объект (диск, конфиг) может же быть расположен на хосте, где вм запущена? Не должен, а может?
Если нет. тогда при vmotion вм между хостами происходит еще и перемещение объектов
Если нет. тогда при vmotion вм между хостами происходит еще и перемещение объектов
В общем случае, может, но ключевое тут в том, что вопрос выбора placement компонентов никак не зависит от расположения ВМ именно потому, что ВМ имеют свойство часто ездить между узлами, а данные мы за ними не перемещаем
N
DISCLAIMER: Все о чем я пишу тут и ранее, не касается вещей типа vSAN Host Affinity и vSAN SNA
EZ
После прочтения поста появился вопрос.
Что произойдет если сначала упадет 1 копия (2 копия и витнесс живы), затем VM что-то запишет (CSN вырастет), после этого упадет вторая копия, причем насовсем (ну, к примеру, диск умер) и поднимется первая копия
Что произойдет если сначала упадет 1 копия (2 копия и витнесс живы), затем VM что-то запишет (CSN вырастет), после этого упадет вторая копия, причем насовсем (ну, к примеру, диск умер) и поднимется первая копия
EZ
Из поста создается ощущение что объект будет inaccessible из-за того, что CSN на витнессе выше чем на 1 копии, но 2 копию восстановить невозможно. Как быть в такой ситуации? (к слову, мы словили на SDS другого вендора именно эту ситуацию однажды - подключался саппорт и через какую-то лютую саппорт-тулзу вручную фиксил версии объектов)
N
Из поста создается ощущение что объект будет inaccessible из-за того, что CSN на витнессе выше чем на 1 копии, но 2 копию восстановить невозможно. Как быть в такой ситуации? (к слову, мы словили на SDS другого вендора именно эту ситуацию однажды - подключался саппорт и через какую-то лютую саппорт-тулзу вручную фиксил версии объектов)
Абсолютно - потому что первая копия содержит другие и устаревшие данные относительно последних известных wintness (а без него они не запустятся ибо нет кворума), она не станет активной
N
Правильный ответ в таком случае - обратиться в суппорт, который сделает Promote служебной командой - т.е. скажет черт с ним с CSN - теперь ты активный.