Эта история про OpenStack + KVM. Все началось, когда все работало хорошо.
«Старая» платформа всех устраивала.
Его вырастили без нас, и он немного устарел.
Это была Юнона.
При этом она работала.
В принципе, это было испытание, пока однажды оно не заработало.
Мы не знали, с какими проблемами столкнулись позже.
Руководство, радостно потирая руки, решило обновить парк систем.
Включая тестовую платформу OpenStack. Мы решили развернуть его вручную, так как на тот момент не было топливных решений для версии «Митака».
Поэтому мы развернули все по рецептам с официального сайта.
Мы, конечно, немного добавили от себя, например, заменили Memcached на Couchbase, а в качестве базы данных взяли percona в режиме кластера.
И все прошло хорошо.
До определенного момента.
Наши посылки начали пропадать.
Сначала мы думали, что виноват переключатель.
Там была довольно старая версия Юноса - 11, в которой были известные ошибки.
И у нее действительно были сообщения на консоли, подтверждающие нашу догадку.
Мы заменили это железо на другое, с новой 15-й прошивкой Юноса.
Между тем проблема не исчезла, а лишь начала медленно расширяться.
Распространенным симптомом является внезапная потеря пингов.
Связь постоянно обрывается.
Разочарование для нас и клиентов.
У нас есть один клиент, он потребляет много трафика.
И это тоже порождает много откликов.
Он ведет трансляции через веб-камеру.
Он начал жаловаться: связь пропала и всё.
Вот что мы увидели в ходе мониторинга: 
Действительно, клиент прав, что-то не так.
Но где??? В один из таких моментов мы нашли причину — в сети светился неправильный ARP. Где виноват? Адрес виновника был найден на выдающем брандмауэре.
Там была строка, ошибочно введенная администратором:
Слава богу, нашли – это была моя первая мысль.set security nat proxy-arp interface xxxx address yy.zz.tt.cc/32
Но не тут-то было.
Потеря пакетов, неважно какой tcp, icmp, udp, продолжалась.
Мы продолжили поиск и стало ясно, что проблема где-то внутри OpenStack. Когда я начал пинговать тестовую виртуальную машину, я чуть не упал со стула: 
Это означало, что некоторые пакеты по каким-то причинам не транслировались и выпадали с серыми адресами! Естественно, эти посылки никому не дошли.
О том, что нам удалось раскопать, мы поделимся, но позже.
Хотелось бы увидеть мнение уважаемой публики, что мы сделали не так и куда надо было смотреть Теги: #*nix #it-инфраструктура #Системное администрирование #Облачные вычисления #Конфигурация Linux #openstack #network #errors #neutron #mitaka
-
Мысли О Python 3
19 Oct, 24 -
Стадо Помогает Вам Добиться Успеха
19 Oct, 24
