Эта история про 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

Слава богу, нашли — была первая мысль. Но не тут-то было. Пропадание пакетов, не важно каких tcp, icmp, udp — продолжалось.

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

Странный пинг

Это значило, что по какой-то причине часть пакетов не транслировалась, и вывалилась наружу с серыми адресами! Естественно, эти пакеты ни до кого не дошли.

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

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


  1. Smile42RU
    08.02.2017 16:28
    +3

    http://serverfault.com


  1. divanikus
    08.02.2017 17:07
    +5

    OpenStack… счастливо пое*аться.


  1. xcore78
    08.02.2017 17:41

    Если на правах «поязвить», то трогать коммутатор было не самым взвешенным решением (хотя, догадываюсь, что самым простым).

    Из того, что вы написали, можно пока что принять точку зрения divanikus
    Мало информации. В частности, непонятно, откуда пинговали.

    Проблемы с хост-машинами были, или только с гостями? Если эта гипотеза проверена, как проведена изоляция проблемы?


  1. Shaz
    08.02.2017 23:39

    ИМХО — не так вы делали то, что выпустили в продакшн систему без тестирования, судя по тексту основываясь на том, что предыдущая сборка была без проблем.
    И кстати, раз вы говорите что проблема проявлялась в виде обрыва пингов, то интересно какие у тех пингов были значения, и если также по 1.5-3 секунды то почему не обратили внимания на это. И еще

    Конечно, немного добавили и от себя, например, заменили Memcached на Couchbase, а в качестве базы данных взяли percona в кластерном режиме. И всё шло хорошо. До определённого момента.
    — в части виртуализации сети тоже наверно добавили отсебятины?


  1. Konkase
    09.02.2017 08:28

    А вы точно проблему решили? Или решили так оригинально задать вопрос на хабре, а не на тостере?


  1. Shaz
    09.02.2017 14:01

    Судя по пингам в 17 или 38 мс (в зависимости от площадки) таки починили.
    Надеюсь что сервисы МинФина не на этой платформе лежат?


  1. zip_zero
    09.02.2017 18:07

    Предсказываю, что будет как всегда: из тонны комментариев — 1% по делу.