стоп а почему только один сервис cinder-volume?

а причем тут сinder host ? если у вас есть 5 бэкендов, то в конечном итоге на всех 5 бэках будет по одному инстанцу образа

спасибо большое, попробую

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

это один бекенд на разных cinder-volume на разных контролах

То что на картинке исходя из вашего опсиания - да, неправильно

То есть оно конечно будет работать но хреново.

у меня же работает

Обоснуй, у меня эта картинка работает 6 лет 😄

у тебя HA нету

я только 1н cinder-volume вижу

а потом оно включится, подтащит из workers "повисшие в процессе" по ее мнению волюмы и начнет их удалять.

Артемий, расшифруй свои опасения плиз

При операциях с волюмом синдер пишет в таблицу workers что он делает. И при старте смотрит в неё и клинапит свои хвосты после возможно аварийного завершения. Если у тебя все хосты схлопываются в один то рестарт любого из них приведёт к преждевременному клинапу тасок на всех волюмах.

При операциях с волюмом синдер пишет в таблицу workers что он делает. И при старте смотрит в неё и клинапит свои хвосты после возможно аварийного завершения. Если у тебя все хосты схлопываются в один то рестарт любого из них приведёт к преждевременному клинапу тасок на всех волюмах.

Вы не путаете host и backend_host? Судя по доке, такие опасения применимы только к ситуации с несколькими одинаковыми значениями host. https://docs.openstack.org/cinder/latest/contributor/high_availability.html#cinder-volume

путает

Не-а. Workers ссылается на service в которой сервисы идентифицируются по host@backend. В правильном конфиге хостовые части идентификаторов сервисов должны быть различны. То есть кластерный бакенд будет виден как несколько записей а не как на картинке одна

При этом он ориентироваться будет не на backend_host а на host, а он как раз указывает туда куда надо

Backend_host это просто способ переопределить хостовую часть у service record. Там действительно можно написать что угодно при условии сохранения уникальности идентификатора сервиса. Главное чтобы можно было однозначно идентифицировать бакэнд.

А требование сохранить бакэндовую часть сервиса растёт от генерации статистики для пулов. Так что в списке должно было быть что то вроде one@dorado, two@dorado, three@dorado а не та хрень что на картинке

А сервисов три :-)

Вот-вот -) Артемий дело говорит ) у нас тоже так )))

да и если у тебя будет one@dorado, two@dorado, three@dorado то у тебя диск будет создаваться one@dorado#pool two@dorado#pool three@dorado#pool и если твой one@dorado дохнет то ты теряешь управление диском one@dorado#pool и похуй что он лежит на той же схд что и two@dorado#pool да еще и в том же пуле

так ты не рассказал, как вы этого достигли =)

поднимаешь рядом с дорадо2 - дорадо1 😉

ну ты ж понимаешь, что это такие же костыли. Когда я пришле в MCS они там вообще host тоже меняли =)

да и если у тебя будет one@dorado, two@dorado, three@dorado то у тебя диск будет создаваться one@dorado#pool two@dorado#pool three@dorado#pool и если твой one@dorado дохнет то ты теряешь управление диском one@dorado#pool и похуй что он лежит на той же схд что и two@dorado#pool да еще и в том же пуле

А вот теперь гонишь. У волюма есть cluster и те волюмбакенды которые входят в кластер работают через общую очередь кластера. Поэтому все живые бакенды одного кластера берут таски в раундробине

можно прям мордой в параметр этого кластера?

https://docs.openstack.org/cinder/latest/contributor/high_availability.html#cinder-volume про active-active

ну ты ж понимаешь, что это такие же костыли. Когда я пришле в MCS они там вообще host тоже меняли =)

И я даже знаю кто менял. И кластер прописывали прямо в базе у 20к волюмов

так это расходимся =) хуавей драйвер туда не умеет для валлаби

Так укажи в коде что он поддерживает active-active :-)

Могу научить это правильно сделать чтобы апстрим не ломать. Дорого :-)

Не. Это для сисьадминов и девопсов.

Не. Немножко ооп и магии и норм