Облачные вычисления — самый модный и порванный баззворд в сфере IT за последние несколько лет. Даже агенство Gartner в своём ежегодном отчёте второй год подряд упоминает этот термин, обозначая одну из стратегических технологий. При всём ажиотаже, нет ничего плохого в том, чтобы отделить зёрна от плевел, и создать свою маленькую и уютную «тучку».
Итак, давайте понимать облачные вычисления как технологию предоставления ресурсов по требованию пользователя, контролирующую весь их жизненный цикл: создание, использование, модификацию, учёт и уничтожение.
Часто к «облакам» навешивают ярлык какой-либо бизнес-модели: IaaS, PaaS, SaaS, etc. Я расскажу про развёртывание полноценного IaaS-облака в совершенно реальном месте — Институте математики и механики УрО РАН.
Так сложилось, что нам понадобилась инфраструктура, позволяющая быстро запустить пачку виртуальных машин, а также быстро её удалить и развернуть пачку других виртуальных машин. Ещё в нашем ЦОД часто ломаются работающие сервера и нередко покупаются новые. Встал вопрос о выборе связующего ПО.
Мы долго выбирали между модным нынче OpenStack и менее знаменитой OpenNebula.
Главной причиной отказа от OpenStack было то, что мне он показался довольно неудачной попыткой слепить нечто рабочее из обломков существующих «облачных» решений. В итоге вместо унифицированного инструментария мы имеем дело с разрозненными останками разношёрстных «облачных» решений, что сильно затрудняет конфигурацию, поддержку и повседневную работу с системой.
Было решено использовать OpenNebula, и сейчас видно, что решение оказалось правильным.
Ядро OpenNebula написано на C++ и занимается исключительно управлением состоянием системы. Вокруг ядра имеется множество утилит, написанных на Ruby и Shell, которые решают различные задачи: управление пользователями, контроль виртуальных машин, хранилища образов, и т. д.
OpenNebula разделяет понятие управляющей машины и узла «облачного» кластера. Очевидно, управляющая машина отдаёт узлам кластера команды на выполнение (например, запустить VM под гипервизором Xen), а сами узлы всего лишь выполняют полученные команды. Для обмена данными OpenNebula использует протокол SSH с перенаправлением потоков ввода-вывода и авторизацией при помощи секретных ключей. Программное обеспечение OpenNebula ставится только на управляющие машины.
Сегодня OpenNebula поддерживает такие гипервизоры, как KVM, Xen и Hyper-V. В качестве системы хранения образов виртуальных машин поддерживается NFS, MooseFS, а также тупое пробрасывание образов через SCP. Увы, поддержка клёвого хранилища OpenStack Swift отсутствует, потому что все операции в OpenNebula выполняются при помощи библиотеки libvirt, которая пока не способна работать со Swift.
Мы развернули свою «тучку» из остатков старого вычислительного кластера, умеющих аппаратную виртуализацию. В качестве гипервизора выбрали модный KVM, а данные решено было хранить в файловой системе NFS на имеющемся NAS от EMC².
Можно представить структуру «облака» графически:
После решения оргвопросов:
- выделили отдельную управляющую машину с CentOS 6 на борту, где запустили демон oned, Web-интерфейс Sunstone и сервер MySQL для хранения состояния системы;
- забрали у старого вычислительного кластера три сервера с поддержкой аппаратной виртуализации, установили туда Scientific Linux 6.1 и отключили SELinux, который требует настройки и мешает работе KVM;
- создали пары SSH-ключей, при помощи которых машины могут «ходить» друг к другу от пользователя oneadmin без пароля;
- на каждом узле кластера установили сетевой мост, позволяющий каждой виртуальной машине быть полноценным членом ЛВС ИММ УрО РАН;
- сконфигуровали в oned политику «если VM упала, то пытаться перезапустить её на другом узле»;
- закрыли подсеть «облака» брандмауэром, дав доступ к конкретным машинам и портам только через сетевой шлюз;
- создали собственный образ Scientific Linux, заточенный на быстрый запуск внутри OpenNebula в качестве VM;
- запустили на его основе тестовую машину с полуработающим морфологическим анализатором myaso.
Таким образом, получилась полноценная, простая в использовании и масштабируемая «облачная» инфраструктура с поддержкой живых миграций виртуальных машин, мониторингом состояния кластера, наличием мер по обеспечению отказоустойчивости, а также многими другими радостями, о которых можно прочесть в документации.
Как я уже говорил, всё вышеперечисленное достигается благодаря тому, что система не переусложнена, все виртуальные машины хранятся на независимом NFS-томе, а взаимодействие управляющей машины с узлами кластера ведётся через надёжный SSH:
Напоследок, приложу скриншот Sunstone. Как видно, прямо сейчас у нас практически нет нагрузки, и балансировщик запихал две VM на третий сервер. В случае выхода его из строя, виртуальные машины мгновенно перенесутся на другие узлы и продолжат свою работу без каких-либо заметных проблем:
