Давно не брал я в руки шашки… Проблема оказалась глубже и интересней, чем можно было себе представить. Попытаюсь изложить то, что найдено со времени предыдущей статьи.
Приключения с IPv6
Прежде всего скажу – ребята, я не понимаю, для чего нужен IPv6 на платформе, которая сама по себе никуда не привязана по этому самому протоколу и адреса она себе назначает какие хочет. Мы с коллегой решили – «нафига козе баян?» – и запретили IPv6. Основательно так запретили. В трёх местах, на уровне ядра и модулей. Заодно обновили софт до последней стабильной версии.
- В файле /etc/default/grub к строке GRUB_CMDLINE_LINUX_DEFAULT добавили параметр ipv6.disable=1
- В файле /etc/modprobe.d/aliases поставили alias net-pf-10 off и alias ipv6 off
- В файле /etc/sysctl.conf назначили net.ipv6.conf.all.disable_ipv6 = 1 и net.ipv6.conf.default.disable_ipv6 = 1
И тут упала у нас раздача адресов по 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 виртуальных машин, в сети не отыскать. Так что, похоже, продолжение следует…
Автор: JohnSelfiedarum
