Эта история про OpenStack + KVM. Всё началось, когда работало всё хорошо. «Старая» платформа всех удовлетворяла. Её поднимали без нас, и она слегка устарела. Это была Juno. При этом она работала.
В принципе она была тестовой, пока в один прекрасный день не стала боевой. Мы знать не знали проблем, с которыми столкнулись потом. Начальство, радостно потирая руки, решило обновить парк систем. В том числе и тестовую платформу 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
К сожалению, не доступен сервер mySQL