OpenStack Essex: разворачиваем пилот частного облака на Ubuntu 12.04

Клиент пришёл с запросом на «что-то вроде своего облака» - возможность запускать виртуальные машины через браузер, не дёргая каждый раз системного администратора. Примерно три физических сервера, Ubuntu, желательно без покупки новых лицензий. Мы подумали и решили попробовать OpenStack Essex - апрельский релиз как раз принёс Horizon и задекларировал стабильную связку Nova + Glance + Keystone. До этого каждый раз что-то разваливалось при совместном использовании трёх компонентов.

Это не боевой продакшен - это пилот. И у пилота, как обычно, своя программа.

Архитектура, которую мы выбрали

Три идентичных физических сервера на Ubuntu 12.04 LTS - мы только что смотрели на неё как на базу для новых развёртываний и она сюда подходит: пакеты Essex лежат прямо в репозитории, не нужно тянуть сторонние PPAs.

Схема выглядит так:

• Один узел - контроллер. На нём живут Keystone (аутентификация и токены), Glance (образы ВМ), nova-api, nova-scheduler, Horizon. Никаких виртуальных машин на нём не крутится.
• Два оставшихся - nova-compute. Здесь гипервизор KVM, libvirt, nova-compute демон. Сюда планировщик распихивает ВМ.
• Сеть - nova-network в flat-режиме. VLAN и Quantum не трогаем - для пилота плоская сеть с фиксированными пулами адресов достаточна.

По сравнению с VMware vSphere - который мы разбирали в марте - архитектурный контраст разительный. У OpenStack нет единого монолитного API-сервера типа vCenter. Каждый компонент - отдельный процесс со своим конфигом, своей базой и своим набором граблей. Это и гибкость, и то, от чего хочется выпить.

Первые три дня: работает, но не сразу

Установка по официальной документации Essex на Ubuntu 12.04 занимает чуть больше времени, чем хотелось бы - примерно полтора дня с отладкой. Документация местами отстаёт от реального состояния пакетов: пара директив в nova.conf, которые документация требует прописать, вызывают DeprecationWarning и игнорируются. Пришлось сверяться с исходниками.

После того как компоненты поднялись и заговорили друг с другом, Horizon открылся в браузере и выглядел вполне прилично - горизонтальная панель с разделами «Instances», «Images», «Security Groups». Для человека, который раньше работал только через nova-manage в командной строке, разница ощутимая.

Запустили первую тестовую ВМ через браузер - получилось. Клиент посмотрел, покивал, попросил добавить ещё образов.

Грабля с Keystone-токенами

На четвёртый день началось интересное.

Пользователи стали жаловаться: Horizon то работает нормально, то выдаёт «Unauthorized (401)» без видимой причины. При этом перелогин помогал, но ненадолго.

Поначалу грешили на сессии в Django (Horizon написан на Django). Покопались в конфиге Horizon - там всё выглядело разумно. Потом пошли смотреть в логи Keystone.

Оказалось: Keystone в Essex выдаёт токены с фиксированным временем жизни - по умолчанию 86400 секунд (24 часа). Но Horizon не всегда корректно обрабатывает ситуацию, когда токен истёк в процессе работы с интерфейсом. Пользователь оставляет вкладку открытой на ночь, утром кликает - получает 401, который Horizon обрабатывает непоследовательно: в одном месте редиректит на логин, в другом просто показывает ошибку.

Это известная проблема в Essex-треке - на bugs.launchpad.net есть несколько репортов. Часть из них уже с патчами, которые в пакеты Ubuntu 12.04 ещё не попали.

Что мы сделали:

• Уменьшили token_expiration в keystone.conf до 3600 секунд (1 час). Меньше время жизни - меньше шанс словить протухший токен в середине сессии.
• Подняли token_expiration в конфиге Horizon - там отдельный параметр SESSION_TIMEOUT, который нужно синхронизировать с Keystone.
• Добавили в документацию для клиента пункт: если видишь 401 - просто перелогинься, это не ошибка в твоих данных.

Последний пункт - не решение, а временный workaround. Но для пилота терпимо.

Что сейчас работает

После недели эксплуатации картина такая:

• Запуск и остановка ВМ через Horizon - работает без сбоев.
• Загрузка образов через Glance (qcow2 формат) - работает, но с нюансом: большие образы (более 5 ГБ) лучше загружать через glance-клиент напрямую, а не через веб-форму.
• Мониторинг ресурсов через Horizon - показывает vCPU, RAM, дисковые квоты по проектам. Клиент доволен - видит, кто сколько потребляет.
• Live Migration - в нашей конфигурации flat-сети не настраивали, это следующий шаг.

Из чего сделаны образы: Ubuntu 12.04 Server, CentOS 6.2, Windows Server 2008 R2 (последний - отдельный разговор, там лицензирование требует осмысления).

Что не решено

Nova-network в flat-режиме - не то, что клиент захочет оставить навсегда. Как только понадобится изоляция между проектами или более тонкая сетевая политика - придётся смотреть на Quantum (сетевой компонент, который в Essex числится как «экспериментальный»). Мы его в пилот не включили сознательно.

Резервное копирование ВМ - пока решается снаружи Essex: снапшоты через nova image-create и последующая выгрузка через Glance. Не изящно, но работает.

Вопрос мониторинга самого OpenStack - не ВМ внутри него, а состояния компонентов - пока закрываем стандартным Zabbix на хосты и процессы. Специфических OpenStack-шаблонов для Zabbix толком нет.

Пилот продолжается. Первое ощущение от Essex - это продукт, который работает, но требует понимания своей внутренней механики на уровне выше, чем просто «следуй доку». Keystone-грабля - показательный пример: без знания того, как токены живут и умирают, диагностировать 401 было бы значительно дольше.

Если вам интересно попробовать похожую схему - мы занимаемся такими внедрениями в рамках управления инфраструктурой.