https://docs.openstack.org/ocata/networking-guide/deploy.html

Спасибо!

https://docs.openstack.org/mitaka/networking-guide/config-bgp-dynamic-routing.html

В данном случае, получается l3 agent один и на контроллере ?

Спасибо!

Да не за что! В Nova, например, забыли упомянуть про Nova Placement, патч находится на рассмотрении: https://review.openstack.org/#/c/438328/

В данном случае, получается l3 agent один и на контроллере ?

Не специалист в BGP, но похоже на то

> https://docs.openstack.org/ocata/networking-guide/deploy.html Выглядит страшно... Если нужен именно BGP-пиринг с инфраструктурой -- посмотрите в сторону Calico.

Теперь нету нетворк нод?

Теперь нету нетворк нод?

Их теперь отдельно не выделяют, агенты ставят тут же на контроллере

Их теперь отдельно не выделяют, агенты ставят тут же на контроллере

Всегда можно собрать их на отдельном железе :)

Нетворк-нода является анахронизмом со времен, когда не было всяких NFV и DVR

Нетворк-нода является анахронизмом со времен, когда не было всяких NFV и DVR

А примеры для openstack есть ?

А примеры для openstack есть ?

Примеры чего? Чтобы далеко не ходить, поробуйте MOS со включенным DVR.

Примеры чего? Чтобы далеко не ходить, поробуйте MOS со включенным DVR.

Mos, это что - mirantis openstack? И расшифруйте, что есть dvr?

верно. https://wiki.openstack.org/wiki/Neutron/DVR

кстати как вообще MOS/fuel для средне-масштабного продакшена на десяток нод?

стабилен/удобен? пока в лабе вроде все бегает

кстати как вообще MOS/fuel для средне-масштабного продакшена на десяток нод?

тестируется до 200 нод

20-50-200

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

это так и есть и все руками делают что-то сложнее базового функционала?

лайв-миграция из коробки всегда была

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

Хорайзон не для продакшн. Есть нормальный API

ну апи да, терраформ у меня ходит в апи

а глазками куда смотреть? :)

в вывод cli утилит

грустно

грустно

Все равно все свою вебку прикручивают

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

мне не нужно мультитенанси, облако чисто приватное

но морду таки хочется

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

обычный пользователь вообще не должен работать с физическими ресурсами

И не надо сравнивать, пожалуйста VMware и OpenStack. Системы создавались под разные задачи и подход изначально был разный

обычный пользователь вообще не должен работать с физическими ресурсами

я лишь ответил про миграцию и её наличиее в dashboard

> Vyacheslav Все равно все свою вебку прикручивают ну вот это я под "руками" и имел в виду.

т.е. еще что-то прогать надо чтобы оно удобно ехало.

т.е. еще что-то прогать надо чтобы оно удобно ехало.

для Private Cloud сгодится то что есть

для Private Cloud сгодится то что есть

+1 Horizon неплох для небольших частных облаков

Я вот что в DVR не понимаю, там роутеры с одинаковыми ип адресами на интерфейсах, каким чудом оно работает?

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

миграция есть, доступна в админ тенанте

Я вот что в DVR не понимаю, там роутеры с одинаковыми ип адресами на интерфейсах, каким чудом оно работает?

namespace

Мм, в плане что qrouter с Compute01 не знает ничего о qrouter c Compute02. А уникальность только на уровне floating-ip?

ну а в чем проблема? все верно сказали, linux namespaces (аналог VRF в сетевых железках)

ну а в чем проблема? все верно сказали, linux namespaces (аналог VRF в сетевых железках)

Так а floating-ip все равно с network ноды обслуживаются?

В общем, если я правильно понял, чтобы DVR работал. На compute01 вешаем floating на DVR - 10.10.0.1 На сompute02 вешаем floating на DVR - 10.10.0.2 instance01 на compute01 имеет floating ip 10.10.0.5 для него есть маршрут на внешнем роутере, типа ip route 10.10.0.5 via 10.10.0.1 Когда падает compute01 маршрут меняется на 10.10.0.5 via 10.10.0.2

да и это печальное разбазаривание IPv4

если фипы реальные адреса

да и это печальное разбазаривание IPv4

Ну маршрутизировать аля white_ip via 10.10.0.1

Я так понимаю маршрутизация не в ведении openstack? типа делаем все руками? Или подключаем BGP, https://docs.openstack.org/mitaka/networking-guide/config-bgp-dynamic-routing.html

смотря какая... на куроутерах маршруты можно прописывать

Внешняя, типа кто вот этот маршрут напишет что instance01 доступен через compute01

разве fip не переедет вместе с VM? он же уникален для порта

Так а в концепции DVR, как внешний маршрутизатор об этом узнает?

зачем ему знать? это будет переезд не l3 а l2.

mac fip просто перееден на другой порт tor свитча

вы же compute nodes не сразу в роутер включаете

Там внутри qrouter-ов все виртуалки между собой в L2?

вы же compute nodes не сразу в роутер включаете

А как, схема говорит сразу в интернет, в этом магия DVR ?

VM которая хочет пойти в другую сетку спросит mac шлюза, в int бридже трафик завернут в роутер

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

Расскажите это разработчикам опенстека, где при использовании ДВР, на каждом компуте создается фип неймспейс, если на этом компуте есть хотя бы одна машина с фип

Ваша картинка как раз об этом и говорит )

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

А как он обратно себе дорогу найдет? Я почти понял и почти опять все не понял

так чем это противоречит моим словам?

я же и схему с этим fip привел

так чем это противоречит моим словам?

Никак, еще раз их перечитал

Вот у меня есть DVR 10.10.0.1 и 10.10.0.2. В какой то момент instance01 с ip 10.10.0.10 переехал на 10.10.0.2. Получается что трафик должен прийти на 10.10.0.2, оттуда он SNATится и уходит уже по маку. Потому что между всеми compute есть L2

шлюз у VM один

например 10.10.0.1

The DVR agent takes responsibility for creating, updating, or deleting the routers in the router namespaces. For all clients in the network owned by the router, the DVR agent populates the ARP entry. By pre-populating ARP entries across compute nodes, the distributed virtual router ensures traffic goes to the correct destination.

Ну так правильно с нее трафик без проблем убегает, а как он с интернета к ней то путь находит?

так через fip и находит

просто без dvr fip на network node а c dvr на compute node

а там обычный nat на iptables

Интересно когда я Вас достану 😂 Спасибо за потраченное время! =)

Пограничный маршрутизатор: ip route add 10.10.0.10 via 10.10.0.1 —------------------------------------------------— Compute01 - 10.10.0.1 is down Compute02 - 10.10.0.2 up \ instance01 10.10.0.10 is up (compute02)

Нифига не работает, потому что трафик идет на умерший хост

внешний fip vm ведь тот же останется

Внешний fip = 10.10.0.10