Openstack. Детективная история или куда пропадает связь? Часть вторая. IPv6 и прочее

Давно не брал я в руки шашки… Проблема оказалась глубже и интересней, чем можно было себе представить. Попытаюсь изложить то, что найдено со времени предыдущей статьи.

Приключения с IPv6

Прежде всего скажу – ребята, я не понимаю, для чего нужен IPv6 на платформе, которая сама по себе никуда не привязана по этому самому протоколу и адреса она себе назначает какие хочет. Мы с коллегой решили – «нафига козе баян?» – и запретили IPv6. Основательно так запретили. В трёх местах, на уровне ядра и модулей. Заодно обновили софт до последней стабильной версии.

И тут упала у нас раздача адресов по DHCP. При этом, естественно, и пароли в новые машины перестали заводиться.

Что поменялось? Похоже, не запускается dnsmasq. Тогда я нашёл в бэкапах старые версии софта и подложил их. Но боже ж ты мой – всё равно не работает!

Что за чудеса? В логах много всего, но никаких конкретных указаний, что происходит. Начал шерстить все логи подряд, в том числе и системные. Случайно увидел, что на самом деле есть логи, говорящие что произошло – но они лежат вовсе не в /var/log, как можно было бы ожидать. Нет, их почему-то прячут в /var/lib/neutron/ha_confs и далее – в названии каталога участвует имя подсети. Там лежат сгенерированный нейтроном конфиг и логи запуска для keepalived. У нас же «устойчивая» конфигурация. Автоматом сгенерированный конфиг содержит IPv6 адреса. Демон keepalived не стартует – от системы он получает отбой. Мы же запретили IPv6? После этого уже не стартует на нужном адресе dnsmasq – потому что адреса нет, его должен был поднять keepalived. Пришлось вернуть обратно.

Вывод: Если мы запрещаем IPv6 на уровне ядра, то dnsmasq перестаёт запускаться.
Не запрещайте IPv6 в Openstack версии Mitaka!

Старая проблема

Но старая история продолжается.

В некоторых случаях проблема возникает сразу после создания виртуальной машины, в некоторых – нет. Напомню: периодически начинает пропадать часть пакетов. И иногда это выглядит даже так, как на представленном рисунке.

Мы нашли относительно простой способ эту проблему обходить. Сейчас это делается отрыванием внутреннего IP адреса и назначением его из другой подсети – нам при этом приходится часто добавлять новые подсети. Проблема на какое-то время уходит. Часть машин при этом работают замечательно. Самые настоящие «танцы с бубном».

Новые горизонты

Недавно я доказал себе, что эта проблема – в глубине OpenStack. Мы сооружали новую платформу по образу и подобию старой, при этом на тестовых диапазонах. Всё работало шикарно при заведении до 300 машин в ферме, и при этом никаких сбоев!

Обрадовались и стали готовить её в «продакшн». Это подразумевало введение «рваных» диапазонов ip адресов – так получилось. Мы очистили ферму, убрав эти самые триста машин. И вдруг на трёх тестовых виртуалках случилось то же, что и на старой ферме – стали пропадать пакеты, в большом количестве. Похоже, дело в самой сетевой настройке OpenStack.

Да, да! Всё дело в настройке виртуального роутера. К великому сожалению, примеров нормального построения сети более чем для 20 виртуальных машин, в сети не отыскать. Так что, похоже, продолжение следует…