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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройки, которые сделали нам хорошо - neutron.conf для controller node

root@mama:~# cat /etc/neutron/neutron.conf |grep -v "^#.*"|strings
[DEFAULT]
bind_host = 192.168.1.4
auth_strategy = keystone
core_plugin = ml2
allow_overlapping_ips = True
service_plugins = router
base_mac = fa:17:a1:00:00:00
notify_nova_on_port_status_changes = true
notify_nova_on_port_data_changes = true
advertise_mtu = true
allow_automatic_dhcp_failover = true
dhcp_agents_per_network = 3
dvr_base_mac = fa:17:b1:00:00:00
router_distributed = true
allow_automatic_l3agent_failover = true
l3_ha = true
max_l3_agents_per_router = 3
rpc_backend = rabbit
[agent]
root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf
[database]
connection = mysql+pymysql://neutron:ZPASSWORDZ@mama/neutron
[keystone_authtoken]
auth_uri = mama:5000
auth_url = mama:35357
memcached_servers = mama:11230
auth_plugin = password
project_domain_name = default
user_domain_name = default
project_name = service
username = neutron
password = ZPASSWORDZ
[nova]
auth_url = mama:35357
auth_plugin = password
project_domain_name = default
user_domain_name = default
region_name = RegionOne
project_name = service
username = nova
password = ZPASSWORDZ
[oslo_messaging_rabbit]
rabbit_userid = openstack
rabbit_password = ZPASSWORDZ
rabbit_durable_queues = true
rabbit_hosts = mama:5673
rabbit_retry_interval = 1
rabbit_retry_backoff = 2
rabbit_max_retries = 0
rabbit_ha_queues = false
[quotas]
quota_network = 100
quota_subnet = 200
quota_port = -1
quota_router = 100
quota_floatingip = -1
quota_security_group = -1
quota_security_group_rule = -1

Настройки, которые сделали нам хорошо - neutron.conf для compute node

root@baby:~# cat /etc/neutron/neutron.conf |grep -v "^#.*"|strings
[DEFAULT]
bind_host = 192.168.1.7
bind_port = 9696
auth_strategy = keystone
core_plugin = ml2
allow_overlapping_ips = True
service_plugins = router
base_mac = fa:17:c1:00:00:00
notify_nova_on_port_status_changes = true
notify_nova_on_port_data_changes = true
allow_automatic_dhcp_failover = true
dhcp_agents_per_network = 3
dvr_base_mac = fa:17:d1:00:00:00
router_distributed = true
allow_automatic_l3agent_failover = true
l3_ha = true
max_l3_agents_per_router = 3
rpc_backend = rabbit
[agent]
root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf
[database]
connection = mysql+pymysql://neutron:ZPASSWORDZ@mama/neutron
[keystone_authtoken]
auth_uri = mama:5000
auth_url = mama:35357
memcached_servers = mama:11230
auth_plugin = password
project_domain_name = default
user_domain_name = default
project_name = service
username = neutron
password = ZPASSWORDZ
[nova]
auth_url = mama:35357
auth_plugin = password
project_domain_name = default
user_domain_name = default
region_name = RegionOne
project_name = service
username = nova
password = ZPASSWORDZ
[oslo_messaging_rabbit]
rabbit_hosts = mama:5673
rabbit_userid = openstack
rabbit_password = ZPASSWORDZ
rabbit_durable_queues = true
rabbit_retry_interval = 1
rabbit_retry_backoff = 2
rabbit_max_retries = 0
rabbit_ha_queues = true

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

Вывод

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

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