хз шо у них там в астре, а мне на нее надо опенстек натянуть
Самый простой способ эт заставь на ней работать lxc, lxd или докер и в контейнерах весь опенстековский контрол плейн разверни)
А то и в виртуалках на голом либвирте)
J
J
И да, поскольку никаких объективных причин калечить дистрибутив не было, я б скорее уволился или устроил забастовку.
Ilya
Не... В тех облаке ни кто не делает овс, это перебор. Там линукс бриджи надо бы.
Речь не про тех облако. А одно общее. И запуск этого облака после полного выключения
humster_88
я сперва пошел примерно по этому пути и опенстек-хелм тыкал. но пока не осилил
J
Типа давай, чисти унитаз зубной щеткой.
Pavel
Речь не про тех облако. А одно общее. И запуск этого облака после полного выключения
А если дать кусочек сетевой - то пропадёт миграция...
NS 🇷🇺
Так я же не веду крестовый поход "кто прав". Я говорю про нашу инсталляцию. Вроде работает. Можно делать.
Конечно, на железе контроллеры проще, но моё ощущение - правильнее виртуализовывать. Плюсов с железными серваками я пока не нашёл (кроме разве что жуткой нагрузки, но у нас - не упираемся)
Так и я просто говорю, что вы не решаете озвученные вами же проблемы. Те плюсов никаких минусы теже
Pavel
Так и я просто говорю, что вы не решаете озвученные вами же проблемы. Те плюсов никаких минусы теже
Постойте. Обозначим проблемы:
1. Неполная утилизация серверов под контроллеры.
2. Возможность миграции или быстрого подъёма контроллера на другом железе при сбое.
Всё вроде решается...
J
я сперва пошел примерно по этому пути и опенстек-хелм тыкал. но пока не осилил
Ды не надо helm.
kubernetes слишком навороченный для небольших и средних облаков. Просто контейнеры, чтобы внутри них получить нормальный дистрибутив.
Pavel
J
Хоть коллу хоть вручную созданные lxc контейнеры.
Лишь бы с астрой дела не иметь.
NS 🇷🇺
Постойте. Обозначим проблемы:
1. Неполная утилизация серверов под контроллеры.
2. Возможность миграции или быстрого подъёма контроллера на другом железе при сбое.
Всё вроде решается...
1) ну вы же понимаете, что можно и железо подобрать под требуемые ресурсы, а если вам еще нужны нетворк ноды с хорошей производительностью….
2) контроллер разворачивается за 15 минут с момента включения сервера, мигрировать у вас он может обсалютно столько же
и да, я не сторонник железных или виртуальных, я исхожу из требований заказчика. Нежно люблю колла и по работе приходится жить в кубере(не скажу что это плохо, но колла ближе к телу)
Pavel
Всем привет. Я гляжу тема зашла...
Pavel
Постойте. Обозначим проблемы:
1. Неполная утилизация серверов под контроллеры.
2. Возможность миграции или быстрого подъёма контроллера на другом железе при сбое.
Всё вроде решается...
у меня вопрос, если контроллер внутри ВМ, зачем 3 контроллера?
Pavel
HA
Pavel
у меня вопрос, если контроллер внутри ВМ, зачем 3 контроллера?
Потому-что бывает, что кролик падает.
Pavel
Как и всё остальное...
Pavel
HA
я так понимаю, что в случае виртуализации HA переносится на уровень ниже, гипервизорам на которых исполняется ВМ
NS 🇷🇺
NS 🇷🇺
святым духом поднимать планируете?
Pavel
я так понимаю, что в случае виртуализации HA переносится на уровень ниже, гипервизорам на которых исполняется ВМ
Програмные ошибки. Как их гипером чинить?
Pavel
Или кто-то на контроллере сделал rm-rf
Pavel
Потому-что бывает, что кролик падает.
кролик, да, тут спорить не буду, но он может и не подавать внешне признаков, что упал, и при этом не выполнять свою функцию.
Берік
Pavel
Любой сервис может отвалиться.
Pavel
я так понимаю, что в случае виртуализации HA переносится на уровень ниже, гипервизорам на которых исполняется ВМ
Нет конечно. вм/контейнер чтобы таскать было удобное. Дальше как обчно
Pavel
Если нужно просто виртуалки включенными держать - то и ол-ин-ван хватит.
Pavel
Короче, от задач зависит сильно.
J
у меня вопрос, если контроллер внутри ВМ, зачем 3 контроллера?
Быстрее и эффективнее держать несколько экземпляров каждого сервиса и между ними запросы балансировать. То есть, и распределение нагрузки и отказоустойчивость.
Pavel
Сбой в базе. В одной - проблема, в трёх - резерв. И так со всем.
сбой в базе... интересно, так как данные постоянно синхронизируются, по хорошему они должны реплицировать и на другие экземпляры.
Pavel
сбой в базе... интересно, так как данные постоянно синхронизируются, по хорошему они должны реплицировать и на другие экземпляры.
База просто сдохла. Я про софт базы.
Pavel
Тож кролик. Два остаются.
Pavel
Pavel
Тож любой сервис
J
Какие могут быть такие экзотические ошибки?
Pavel
Какие могут быть такие экзотические ошибки?
кривые руки админа, ошибся в трёх конфигах из 20 на каждом УУ
Pavel
Опять таки - потеря сервиса. Пока нашёл, пока поднимаешь
Mr
Коллеги доброго времени суток. Не судите строго за вопрос я только начинаю разбираться. Почему для продакшн систем везде требуется железные контроллеры? Т.е. насколько я понимаю не существует решения чтобы эти три контроллера были развернуты на виртуалках и крутились на тех же гипервизарах которыми управляют как у вари.
Я тут очень редко бываю, можно ткнуть пальцем, где скажем в фьюжене вынесенные железные контроллеры ? https://support.huawei.com/enterprise/en/cloud-computing/fusionsphere-openstack-pid-21100528/software/
J
Если руками поменьше лазить везде, а все изменения централизованно применять более-менее ко всем экземплярам сразу, то неожиданностей не будет.
Pavel
Pavel
Я вот просто думаю, если утащить все сервисы по максимуму на компьюты, то что останется на контроле?
J
Я вот просто думаю, если утащить все сервисы по максимуму на компьюты, то что останется на контроле?
Думаю, база данных и кролик или другая зараза для роутинга сообщений.
Pavel
А почему кролика не распихать на все компьюты?
NS 🇷🇺
Pavel
Я вот просто думаю, если утащить все сервисы по максимуму на компьюты, то что останется на контроле?
А зачем? Просто на компьютах не понятно что пользюки будут делать, могут нагрузку давануть, и подгрузить сервер, могут сеть загять. Что угодно.
Pavel
J
Pavel
Ну, можно опять таки и ол-ин-ван завести, делов то... От потребностей.
Pavel
да хочется, чтобы как в мерседесе было, чтобы отказоустойчивость узлов управления гарантировалась самой платформой, как у взрослых дядек.
J
Pavel
:)
Pavel
Всёж опенстек мерседесом назвать сложно. Хотя если внутрь глянуть куда угодно, хоть в мерс, хоть в варю, везде есть костыли.
NS 🇷🇺
Кубырнетис навернет?)
да бог его знает, что у них в головах. Не я уважаю молодых специалистов, но которые адекватно оценивают свой уровень
Pavel
Всёж опенстек мерседесом назвать сложно. Хотя если внутрь глянуть куда угодно, хоть в мерс, хоть в варю, везде есть костыли.
Но у вари они достаточно надёжно работают.
Pavel
Но у вари они достаточно надёжно работают.
стек тоже нормально работает. Только напильник нужен.
Pavel
стек тоже нормально работает. Только напильник нужен.
Не, тут целый цех набитый инженерами нужен.
Pavel
Для эксплуатации нашего продукта достаточно всего две команды - команда разработки и команда поддержки :)
Pavel
Для эксплуатации нашего продукта достаточно всего две команды - команда разработки и команда поддержки :)
Для серьёзной работы с опенстеком - да, желательно. Либо иметь очень прямой взгляд на вещи, ни чуточки не отличающийся от комьюнити.
Pavel
Ну, я не виноват, что вас так всех развели ребята :)
Pavel
А доработки сами делаете тоже?
NS 🇷🇺
Ну, я не виноват, что вас так всех развели ребята :)
я тебе так скажу, я не вижу причин иметь больше трех инженеров на стек
Pavel
я тебе так скажу, я не вижу причин иметь больше трех инженеров на стек
Это если эксплуатировать его как есть?
Yuriy
Коллеги, как правильно развернуть ovn если у тебя на бридже настроены vlan.
Yuriy
Что писать в bridge-interface-mapping и ovn-bridge-mapping?