Я и гиперв могу , дешевле будет .

просто сам кейс, два сервера, если это достаточно удаленная точка и сервер выйдет из строй(например из-за жары), ехать на объект дорогостояще. А вот если каналы связи позволяют то почему бы не отдать ресурсы в облаке?

зачем ставить интернеты везде стабильные и быстрые

А облако оно как, везде стабильное? Скажем Гознак? Или МТС ? )))))

вот что сразу начинается то? У Амазона стабильное! 9999

Это не мне ( и дальше начинается денег нет итд

При чем там роль member я ваще не понял.

Роль админа могла создавать все без проблем в том числе порты, а роль мембер перестала создавать(в логах очевидных ошибок не было) По итогу проблема в версиях зависимостей нейтрона была. Обновили версию, но оставив некоторые зависимости "старые" и все стало хорошо, что самое главное) —- Всем спасибо за помощь, работаем дальше 💪

40 хостов, а сколько инстансов?

Сейчас расчёт на 2000 если не ошибаюсь

Привет, комьюнити 👋🏻 Планируется строительство двух географически разнесённых кластеров (регионов) ≈40 хостов каждый + хосты под ceph. ip фабрики будут строится с нуля. Вопрос: насколько имеет смысл при таком объёме внедрять opensdn(tf)? Видится, что поддержка облака на opensdn требует бОльших компетенций, а следовательно будет дороже. Или плюсов настолько больше, что стоит внедрять несмотря ни на что?) Очень интересует мнения коллег на опыте) как бы вы поступили?

однако, есть и негативная сторона: на 5к+ портах поиск порта или openstack port list падает в ошибку по таймауту, ребята с мирантиса (емнип) изучают этот случай

однако, есть и негативная сторона: на 5к+ портах поиск порта или openstack port list падает в ошибку по таймауту, ребята с мирантиса (емнип) изучают этот случай

А это насколько старая проблема? Или всплыла в последних релизах?

Так, из всего сказанного похоже, что opensdn выглядит как лучший фундамент для будущего потенциального роста. И развития сервисов.

Этой проблеме уже лет 8, причины известны, оно слишком долго собирает инфу из всех таблиц и много сериализации и де сериализации из джсон в питон объекты и обратно

А это насколько старая проблема? Или всплыла в последних релизах?

да, но только Андрей страхуйте как минимум нормальным CI/CD и хотя бы подготовьте площадку, то есть для прода вам нужно: 1. Dev стенд на котором будет обматываться механизмы того или иного взаимодействия с компонентами опенстека, а так же будет собираться дебаг для дальнейшего открытия на ланчпаде или у поставщика(если это комерческий поставщик) issue. 2. QA стенд где уже и первая и вторая линия будет смотреть куда и как взаимодействовать с продуктом. 3. PreProd(Stage III) где уже точно будут закомиченая версия прода и будет не просто тестирование а создание рабочих нагрузок, возможно это будет кусок внутренней виртуализации. ну и сам прод, тут все понятно я думаю.

Спасибо! Подобие такого стенда уже собрано, но на гораздо меньшем кол-ве хостов. Конвеер только ещё не доделали

Привет, комьюнити 👋🏻 Планируется строительство двух географически разнесённых кластеров (регионов) ≈40 хостов каждый + хосты под ceph. ip фабрики будут строится с нуля. Вопрос: насколько имеет смысл при таком объёме внедрять opensdn(tf)? Видится, что поддержка облака на opensdn требует бОльших компетенций, а следовательно будет дороже. Или плюсов настолько больше, что стоит внедрять несмотря ни на что?) Очень интересует мнения коллег на опыте) как бы вы поступили?

вопрос со звездочкой вообще то.

берём opensdn и раскатываем на 2 цода и соединяем интерконнектом

если клиенты будут автоматом ожидать видимости внутренних сетей между цодами - нужна будет автоматизация таких настроек в тангстене при создании клиетами сетей в разных тангстенах( в разных цодах). если тангстен будет общий, там такой проблемы не будет, но будет растянутая кассандра

Делайте в каждом дц отдельный регион, мой вам совет

да домены отказов лучше изолировать. поэтому это самое надежное

а зачем так мучительно? разве в 2024 году нельзя сказать, что "дорогие клиенты/пользователи, никакого DR-а наша заоблачная система не обеспечивает. вот вам два региона (вообще лучше три), делайте DR итд сами на уровне своих приложений"?

Я тут в кубер вкатываюсь по-немногу и возникла задача в мир выставлять голой жопой сервисы. Хочу заюзать octavia. Какие подводные камни? Что по производительности?

А я в ОпенСтэк вкатываюсь) уже год как

С 4ого раза вроде попроще, но все равно, хер его знает как обеспечить использование NodePort в случае если на нодах будут тенанты других юзеров (cozystack). Конфликт же будет по идее

Угу, поэтому не надо нодпорт юзать. Лучше все через LoadBancer, а вообще если у тебя ОпенСтэк, ты можешь установить CCM OpenStack - https://github.com/kubernetes/cloud-provider-openstack

Это ок подход, что куб ходит в опенстак и просит создать балансировщик?

Это ок подход, что куб ходит в опенстак и просит создать балансировщик?

Да, AWS/DO так делают

добрый день коллеги, а можно значение max_instances_per_host указать для одной конкретной compute ноды?

Угу, поэтому не надо нодпорт юзать. Лучше все через LoadBancer, а вообще если у тебя ОпенСтэк, ты можешь установить CCM OpenStack - https://github.com/kubernetes/cloud-provider-openstack

Да, AWS/DO так делают

моё почтение, поставил таску раскатать октавию как чуть посвободнее буду, будем тестить, чтобы не взорвалось

Рад был помочь! Пиши если ещё будут вопросы по куберу

прост.. есть провайдеры OVN Octavia provider driver Radware provider driver for OpenStack Octavia AmphoraV2 Хотелось бы какую то сравнительную таблицу что ли, потому что про первый провайдер чет вообще мало информации

https://docs.openstack.org/ovn-octavia-provider/latest/admin/driver.html Ovn provider ток на L4 (TCP, UDP, SCTP) может балансировать, те уже можно забыть про часть фунций, которые могут клиенту быть нужны, аля терминация https. Еще healthchecks своеобразно работают https://docs.openstack.org/releasenotes/ovn-octavia-provider/2023.2.html#known-issues Те пока без амфоры никак)