Кто может рассказать как правильно настроить multipath в стеке (зайду с этой стороны)?

там отдельный контейнер для этого

multipathd

enable_multipathd: "yes"

Кто может рассказать как правильно настроить multipath в стеке (зайду с этой стороны)?

опция пробрасывается в контейнеры, не на хост, а в контейнер

ну как то так.

там отдельный контейнер для этого

И да и нет. Нова сама пытается в мультипас и обсерается вот на этом

Отдельный multipathd делает /dev/dm устройства

опция пробрасывается в контейнеры, не на хост, а в контейнер

Какая именно опция?

в конфиге новы включено? volume_use_multipath = True

в конфиге новы включено? volume_use_multipath = True

Включено. При отключении работает. При True - сыпет ошибкой что нет конфига мультипаса

Уже мозг кипит, решил уточнить

а сам конфиг у тебя есть?

в конфиге новы включено? volume_use_multipath = True

Наверное нет, эцсамое это еще при деплойменте задается

./config/multipathd/multipath.conf

а сам конфиг у тебя есть?

Где именно он есть?

./config/multipathd/multipath.conf

на деплоере вот тут

Кхм. Ща...

docker exec -it nova_compute ls /etc/multipath ls: cannot access '/etc/multipath': No such file or directory r docker exec -it multipathd ls /etc/multipath bindings wwids

подскажите, а для чего может понабиться такая настойка? для каких задач используется?

для iscsi

Искази, FC

если я правильно помню там какие то лимиты по сессиям до одного луна

LVM тоже

подскажите, а для чего может понабиться такая настойка? для каких задач используется?

ну как для чего? Вот у тебя блочка, к примеру FC и тут без мультипатч никуда.

мултипс это фиксит

Если знаете объяснение на формальном техническом языке, пишите

у меня в голове это всё как "блё блё блё бле бле бле"

если я правильно помню там какие то лимиты по сессиям до одного луна

Не совсем. Оно тебе просто условно MPIO реализует (но могу ошибаться)

Мне сейчас полку подарили, которая в lacp не умеет. У нее тупо МАК ездит между двух сосков. И два ИП адреса. Можно сделать MPIO

если я правильно помню там какие то лимиты по сессиям до одного луна

Нет, у тебя разные коммутаторы SAN и они крест на крест соединены до схд и к хосту.

которая позволяет использовать несколько путей для доступа к одному устройству хранения данных

надо будет почитать позже

таким образом если у тебя контролер на схд подох или сам SAN коммутатор то у тебя всегда остается альтернативный путь до lun

По FC ты по другому и не сделаешь. Тебе нужно иметь два+ пути

вот еще норм объяснение имхо одно SCSI-устройство может быть подсоединено к двум SCSI-контроллерам

которая позволяет использовать несколько путей для доступа к одному устройству хранения данных

это понятно, зачем мультипас в опестэк подключать? роль связи с схд можно же на ОС повесить

ну так у тебя же не ОС с дисками работает

а сервис опенстака

это понятно, зачем мультипас в опестэк подключать? роль связи с схд можно же на ОС повесить

Оно и вешает

Но управление этими подвесами - на стороне стека

опция пробрасывается в контейнеры, не на хост, а в контейнер

.

можно же подключить iscsi устройство по мультипасу к ОС а в опенстэк пусть работает с готовым блочным устройством через lvm или я неправильно понимаю?

.

Так о какой опции то речь? Ушла мысль

./config/multipathd/multipath.conf

.

А, да. Гляну рольку. Но странно тогда...

ничего странного. Если мы используем сервисы опенстека вне контейнера, например как все нормальные люди в самой операционной системе, то и настраиваем на слое операционной системы, если это контейнеры, то это уже другой слой абстракции

можно же подключить iscsi устройство по мультипасу к ОС а в опенстэк пусть работает с готовым блочным устройством через lvm или я неправильно понимаю?

правильно помню, что multipass обеспечивает не только резервирование, но и балансинг? зачем это отдавать ОС когда можно openstack-у самому порулить?

правильно помню, что multipass обеспечивает не только резервирование, но и балансинг? зачем это отдавать ОС когда можно openstack-у самому порулить?

у меня нет информации как лучше, поэтому и спрашиваю, с точки зрения администрирования проще когда мультипасом управляет ОС

если у меня есть 2 хранилки подключенных по мультипасу я их на уровне ОС добавляю в VG и отдаю опенстэку, если надо 3-ю схд, то добавлю ее в ту же VG или так не будет нормально работать?

если у меня есть 2 хранилки подключенных по мультипасу я их на уровне ОС добавляю в VG и отдаю опенстэку, если надо 3-ю схд, то добавлю ее в ту же VG или так не будет нормально работать?

Синдер который препарирует оперирует драйвером от СХД он то в контейнере

логично что и сервис multipathd тоже должен быть в контейнере

Синдер который препарирует оперирует драйвером от СХД он то в контейнере

я синдеру VG отдам, разве ему нужен для работы с VG драйвер СХД?

если у меня есть 2 хранилки подключенных по мультипасу я их на уровне ОС добавляю в VG и отдаю опенстэку, если надо 3-ю схд, то добавлю ее в ту же VG или так не будет нормально работать?

Речь про LVM у которого pv на FC хранилке? Или про какие VG? Изначальная обсуждаемая схема ведь не такая. Речь про FC хранилку, подключенную к каждой ноде по hba. Соответственно на каждой ноде д.б. Multipathd, который обеспечит подключение lun с этой хранилки через devmap в ОС.

Ну если нет cinder-driver, то можно и как вы предлагаете сделать.

Ну если нет cinder-driver, то можно и как вы предлагаете сделать.

это очень порочная практика, можно но не нужно

легитимно так делать наверное только в k8s да и то опасненько

это очень порочная практика, можно но не нужно

сможете пояснить почему эта практика порочная и с появлением каких проблем это связанно?

Ну смотри

Вот у тебя есть контейнеры циндера

Которые хотят по искази подключиться к хранилищу

А контейнера искази нету

Зато есть пакет искази на ОС

Как думаешь куда циндер пойдет чтобы попросить установить соединение с хранилищем

И мудак писал шаблон для запуска iscsid нахера там в дебаг режиме без возможности это поменять не понятно

И мудак писал шаблон для запуска iscsid нахера там в дебаг режиме без возможности это поменять не понятно

Кстати да

И оно срет в логи stdout

На убунте оно в сислог херачит и жрет место

Это да, мы потом отключали жестко

Как думаешь куда циндер пойдет чтобы попросить установить соединение с хранилищем

Если мы говорим про hba, то оно подается монопольно(как любое другое железо), поэтому проще через контейнер

Которые хотят по искази подключиться к хранилищу

Я говорил что iscsi подключение держит ОС а синдеру отдается VG т.е. он работает с LVM, в таком случае зачем синдеру подключаться по iscsi к хранилке?

проведи эксперимент

поставиь и запусти iscsi контейнер

и попробуй установить open-iscsi

на хост

Этот блять то же самое

что если у тебя будет работать либвирт на хосте и в контейнере

кто кого

Никит, iscsi это протокол, девайс например сетевая карта может не поддерживать такой протокол или хуже там может не поддерживаться аппаратно iscsi. Тут таже самая ситуация что интерфейсная карта это монопольно отданное устройство

ёмаё