Открытый стек с плавающим ip недоступен

описание

После включения dvr две виртуальные машины vip настраиваются с помощью keealived. Когда VIP частной сети дрейфует, открытый плавающий ip не может быть доступен.

более подробно следующим образом:

Два узла, конфигурация частной сети keepalived Host1 192.168.1.2 Host2 192.168.1.3 vip192.168.1.4 Дрейф vip в частной сети не проблема, vip-доступ в частной сети не является проблемой Проблема заключается в том, что после дрейфа vip внутренней сети внешний Плавающий ip, соответствующий этому vip, недоступен, и может быть доступен до дрейфа. Феномен: Обновите порт частной сети, к которой перемещается vip. Плавающая сеть может быть использована. Что вызывает эту проблему?

Ссылка на конфигурацию

https://hk.saowen.com/a/4d7a3dcd044eb53ae0fc81e4d1445ba76bbb02423ff6c7b4a53a8ad59945883d

Процесс настройки

предпосылка: предположим, что уже есть две виртуальные машины 10.10.10.6, 10.10.10.7, настроенные с помощью keepalived, vip - 10.10.10.201. Сконфигурируйте шаги для поддержки VIP и плавающего IP-доступа в OpenStack:

  1. Группа безопасности плюс протокол vrrp 112

    нейтронная группа безопасности-правило-создать -протокол 112 по умолчанию

  2. Создать VIP

    нейтронный порт-create --fixed_ip ip_address=10.10.10.201 --security группы по умолчанию vrrp_net

  3. Привязать vip к плавающему ip

    нейтронное плавание ip-create --port-id=3d7e70e9-cfcb-4aa9-95cc-60b5b6b67ec3 admin_floating_net

  4. Добавьте allow_address_pairs к порту виртуальной машины для поддержки нескольких сетевых карт для нескольких сетевых карт.

Запросить порт виртуальной машины 1

нейтронный порт-лист | grep 10.10.10.6

Обновление порта виртуальной машины 1

обновление нейтронного порта df22ba59-9c58-41a5-9fa3-98b09e644fe5 - список разрешенных_адресных_пар =true тип =dict ip_address=10.10.10.201

Запросить порт виртуальной машины 2

нейтронный порт-лист | grep 10.10.10.7

Обновите порт виртуальной машины 2

обновление нейтронного порта 4c93d5b7-f26f-4136-a785-4db1479dbd81 -> список разрешенных_адресных_пар =true type=dict ip_address=10.10.10.201

Источник

1 ответ

У нас была такая же проблема в OpenStack Pike. Для нас это кажется исчезнувшим после обновления до Квинса. Какую версию вы используете?

В нашем случае правила iptables для snat / dnat в пространстве имен snat на узлах сети не были обновлены после отработки отказа.

Вы можете проверить это в вашей установке, позвонив:

ip netns exec snat-<uuid of your router> iptables -t nat -L

Вы должны увидеть одно правило snat и одно правило dnat для вашего плавающего IP.

Еще несколько ошибок Launchpad и PR для дальнейшего использования:

Источник
Другие вопросы по тегам