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

«Кто так строит?!»

Какой адрес у маршрутизатора должен быть по-умолчанию в сети – это большой вопрос. На самом деле ничто не мешает ему быть любым адресом из подсети. И сочинители OpenStack тоже решили – давайте будет первый, что мучиться?

В итоге ты опомниться не успеваешь, как всё падает. Почему? Потому что неожиданно для всех default gw оказывается не на роутере, как ему положено, а на твоём опенстеке. Клиенты звонят, шеф лютует. А ты ищешь очередную причину падения. Просто коллега отцепил существующий адрес с целью замены, а опенстек оказался хитрее…

Жизнь продолжается

В некоторых случаях проблема возникает сразу, в некоторых – нет. Напомню: старая проблема состояла в том, что периодически начинались пропадания части IP-пакетов.

Попытаюсь немного оправдаться. – часто наши проблемы совпадали с наличием внешних атак. При этом во многих случаях казалось, что проблемы именно в перегруженных каналах. В каких-то случаях мы превышали лимит каналов и пакеты действительно дропались. Это усугублялось наличием заражённых машин в платформе, которые генерировали неимоверный объём внутреннего трафика. Плюс неисправности сетевого оборудования, в котором, из-за ошибок программистов тоже убивались не те пакеты. Кроме того, конфигурационные файлы просто огромны.

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

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

Странные временные решения

В старой ферме мы нашли относительно простой способ эту проблему обходить. Это делалось отрыванием внутреннего IP адреса и назначением его из другой подсети – нам при этом приходилось часто добавлять новые подсети. Проблема на какое-то время уходила. Часть машин при этом работала хорошо.

Решение где-то рядом

В ходе долго расследования, прерываемые на проектные работы, отвлекаемые проблемами от VIPов, мы всё-таки смогли выявить несколько ошибок. Кроме того, эти самые файлы различаются, если вы используете контроллер в качестве вычислительного узла, и если не используете. В одной из первых удачных конфигураций, мы его использовали. Затем от этого отказались. Часть настроек –осталась. Таким образом в двух из девяти машин были неправильные настройки (на вычислительные узлы попал параметр не dvr, а dvr-snat). В конце концов я нашёл правильный параметр и поставил на место.

Без понимания того, как работает виртуальный роутер – где же он берёт настройки, пришлось настраивать и его. Он, по идее, должен быть с одним адресом и, соответственно, с одним мак-адресом. Логично? Мы так рассуждали и соответственно настраивали с коллегой.

В какой-то момент при расследовании проблем с DHCP (см. часть 2) я нашёл задваивающиеся мак-адреса. Не один, два, а гораздо больше. Вот это номер!

Было принято решение сменить параметры настройки base_mac и dvr_base_mac. Теперь в каждой вычислительной машине и в каждом контроллере эти параметры разные.

Мы с самого начала ещё не включили l2population – ну просто руки не доходили. А в новой ферме включили. И гляди, после всех таких изменений – заработало! Мало того – пинги перестали пропадать от слова «вообще»! Раньше нет-нет, да и пропадёт пакетик просто так – 0,1% и мы считали, что это вообще неплохо. Потому что гораздо хуже, когда пропадала четверть, а то и половина.

Сутки терпеливо выждав (а ведь хотелось бегать, с криками «всё заработало!»), мы применили подобные изменения и в старой ферме. Вторая неделя – полёт нормальный.

Вывод

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

Автор: JohnSelfiedarum

Источник