Openstack. Детективна історія або куди пропадає зв'язок? Частина перша

Ця історія про OpenStack + KVM. Все почалося, коли все працювало добре. «Стара» платформа всіх задовольняла. Її піднімали без нас, і вона злегка застаріла. Це була Juno. При цьому вона працювала.

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

Читати далі →

Адмінських байки: у гонитві за фрагментацією тунелів в оверлейной мережі

Ліричний вступ

Коли адміністратори стикаються з несподіваною проблемою (раніше працювало, і, раптом, після оновлення, перестало), у них існує два можливих алгоритму поведінки: fight or flight. Тобто або разбиратся в проблемі до кінця, або втекти від проблеми не вникаючи в його суть. У контексті оновлення відкотитися назад.

Відкотитися після невдалого апгрейда — це, можна сказати, сумна best practice. Існують цілі керівництва як готуватися до відкоту, як їх проводити, і що робити, якщо відкотитися не вдалося. Ціла індустрія боягузливого поведінки.

Альтернативний шлях — розбиратися до останнього. Це дуже важкий шлях, в якому ніхто не обіцяє успіху, обсяг витрачених зусиль буде непорівнянний з результатом, а на виході буде лише трохи більше розуміння події.

Зав'язка драми
Хмара «Instant Servers» Webzillа. Рутинне оновлення хоста nova-compute. Новий live image (у нас використовується PXE-завантаження), відпрацьована шеф. Все добре. Раптово, скарга від клієнта: «одна з виртуалок дивно працює, начебто працює, але як починається реальне навантаження, так все завмирає». Инстансы клієнта переносимо на іншу ноду, проблема клієнта вирішена. Починається наша проблема. Запускаємо інстанси на цій ноде. Картинка: логін по ssh на Cirros успішний, на Ubuntu — зависає. ssh-v показує, що все зупиняється на етапі «debug1: SSH2_MSG_KEXINIT sent».

Всі можливі зовнішні методи налагодження працюють — метадані виходять, DHCP-оренда инстансом оновлюється. Виникає підозра, що інстанси не отримує опцію DHCP з MTU. Tcpdump показує, що опція відправляється, але не відомо, чи приймає її інстанси.

Нам дуже хочеться потрапити на інстанси, але на Cirros, куди ми можемо потрапити, MTU правильний, а на Ubuntu, щодо якої є підозра про проблему MTU, ми як раз потрапити не можемо. Але дуже хочемо.

Якщо це проблема з MTU, то у нас є раптовий помічник. Це IPv6. При тому, що «білі» IPv6 ми не виділяємо (вибачте, воно поки що не production-ready в openstack), link-local IPv6 працюють.

Читати далі →

OpenStack і VMware: коли сервери «Pets» і «Cattle» працюють разом

    Якщо ви читаєте цей блог, то, напевно, знаєте чимало про платформу OpenStack і про те, як вона управляє інфраструктурою як послугою (головним чином серверами так званого класу «cattle» (англ. «велика рогата худоба»). Однак ви можете бути не настільки добре обізнані в технологіях VMware, які вже досить тривалий час використовуються для управління сервісами віртуалізації (власне, серверами так званого класу «pets» (англ. «домашні вихованці»), а за пару останніх циклів розробки стали частиною екосистеми OpenStack .
Читати далі →

Боротьба з надмірною логгірованіем в Openstack

  Зміст: Несамовита швидкість росту auth.log на хостах з neutron-plugin-openvswitch-agent. Аналіз причин, метод усунення. Трохи про роботу sudo, PAM і його сесії.
 
 
 
Про що піде мова? Openstack — платформа для побудови хмар. Neutron — назва його підсистеми відповідає за мережу, модною хіпстерской вебдванольний , cчитался досконалішою і функціональною, ніж перша спроба під назвою nova-networking. openvswitch-plugin — це плагін до neutron, який реалізує його функціональність за допомогою Open vSwitch — програмного комутатора, що дозволяє робити розумні штуки, начебто GRE-тунелів, бондинга і міррорінга портів, накладення правил на порт всередині віртуального комутатора в стилі iptables і т.д.
 
neutron-openvswitch-plugin-agent — одна з компонент цього плагіна, що працює на всіх хостах, які мають хоч якесь реальне ставлення до передачі мережевого трафіку віртуалок. Іншими словами, це все compute-вузли (там, де працюють виртуалки), networking-вузли (які роблять «інтернет» для віртуалок). Зі списку випадають тільки сервера API та інші службові сервера. З урахуванням, що більша частина хмари складається з compute + networking, можна, злегка огрубляя, говорити, що цей neutron-openvswitch-plugin-agent встановлений на всіх хостах. Logstash — система централізованої збірки логів, Elasticsearch — база даних для роботи з цими логами.
 
Для своєчасної реакції на проблеми ПО, все логи всіх додатків повинні збиратися і аналізуватися системою моніторингу. Докладніше про це у нас вже було написано . Однак, навіть хорошого може бути занадто багато. Швидко виявилося, що більша частина зібраного з хостів — безглузді повідомлення наступного вигляду:
 
Читати далі →

Побудова тестових оточень за допомогою OpenStack

  Автор: Євгенія Шумахер
 
 Євгенія Шумахер — бізнес-аналітик компанії Mirantis і автор пропозиції: How to Avoid Picking Problems that OpenStack Can't Solve , доповідач по темі Will your Cloud be Compliant? на саміті OpenStack, який пройде цієї весни в Атланті.
Читати далі →

PaaS-стратегія OpenStack

  Автор: Алекс Фрідлaнд
 
 Від перекладача: в даній статті розглядаються два протилежні погляди на питання, чи загрожує розвиток OpenStack індустрії PaaS чи ні.
Читати далі →