[recovery mode] Openstack. Детективная история или куда пропадает связь? Часть первая08.02.2017 16:03

В принципе она была тестовой, пока в один прекрасный день не стала боевой. Мы знать не знали проблем, с которыми столкнулись потом. Начальство, радостно потирая руки, решило обновить парк систем. В том числе и тестовую платформу OpenStack.

Решили разворачивать вручную, поскольку в тот момент не было fuel решений под версию Mitaka. Поэтому развернули всё по рецептам c официального сайта. Конечно, немного добавили и от себя, например, заменили Memcached на Couchbase, а в качестве базы данных взяли percona в кластерном режиме. И всё шло хорошо. До определённого момента.

Cтали у нас пропадать пакеты. Сначала мы думали, что виноват коммутатор. На нём была Junos довольно старой версии — 11, которая имеет известные баги. И на консоли у неё действительно были сообщения, подтверждающие нашу догадку. Мы заменили это железо на другое, с новой, 15-й прошивкой Junos.

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

Есть у нас один клиент, много трафика потребляет. И генерирует в ответ тоже много. У него трансляции с веб-камер идут. Стал он жаловаться: пропадает связь и всё тут.

Вот что мы увидели на мониторинге:

Действительно — клиент прав, что-то не так. Но где??? В один из таких моментов мы нашли причину — не тот ARP светился в сети. Где же виновник? Виновный адрес был найден на выпускающем файрволе. Там стояла строчка, по-ошибке вписанная админом:

set security nat proxy-arp interface xxxx address yy.zz.tt.cc/32

Мы продолжали искать, и стало ясно, что проблема где-то внутри OpenStack. Когда я стал пинговать тестовую виртуальную машину — чуть не упал со стула:

Мы поделимся тем, что смогли раскопать, но позже. Хотелось бы увидеть мнение уважаемой публики, что мы делали не так и где надо было искать

Комментарии (0)