История внедрения облачной платформы OpenNebula (Леонид Kaнтер, OSSDEVCONF-2016)
Материал из 0x1.tv
Содержание
Аннотация
- Докладчик
- Леонид Kaнтер
Критерии выбора продукта OpenNebula в качестве корпоративной облачной платформы для разработки ПО. Опыт развёртывания и эксплуатации.
Видео
Слайды
Расширенные тезисы
Предыстория
Наша компания занимается разработкой программного обеспечения для ОС Linux, в том числе и специализированной версии дистрибутива для провайдеров услуги shared hosting. Поэтому для нас очень важно обеспечить комфортные условия для работы наших программистов и тестеров — быструю, надёжную и удобную инфраструктуру, которая позволяла бы разработчикам максимально быстро видеть результат их работы в действии, а сотрудникам QA тестировать продукты в условиях, максимально приближённых к тем, которые есть у наших клиентов.
Ещё в начале 2014 года количество сотрудников нашей компании не превышало 40, и большая их часть была сконцентрирована в донецком офисе. Там же был небольшой датацентр, в котором размещались сборочный сервер, git и несколько серверов виртуальных машин на базе Parallels Cloud Server 6, которые использовались для разработки и тестирования. Но после известных событий практически все сотрудники были вынуждены перейти на удалённую работу, и пришлось часть сервисов перенести на Hetzner. А потом за достаточно короткое время количество сотрудников увеличилось практически до 100 человек, и возникла необходимость в построении для внутренних нужд небольшого частного облака.
Поскольку наиболее «раскрученной» платформой для корпоративных облаков является OpenStack, естественно, появилось желание внедрить именно его. Однако сразу возник вопрос — какой именно OpenStack брать? OpenStack — очень сложный проект, состоящий на текущий момент как минимум из 14 компонентов, и кроме свободно распространяемых исходных текстов, существует множество бинарных сборок со своими утилитами для развертывания. Практически каждый вендор предлагает не просто OpenStack, а свой продукт со своими достоинствами и недостатками. Это и Red Hat OpenStack Platform с поддерживаемой сообществом версией RDO, и Ubuntu, и Mirantis со своим Fuel, не говоря уже о такой компании, как HP.
Выбор дистрибутива OpenStack
Поскольку мы в основном работаем с системами на базе Red Hat, начали сразу смотреть в сторону дистрибутива RDO. Но оказалось, что его установщик хорошо настраивает только all-in-one сервер, а с кластером из нескольких серверов уже возникают проблемы. Mirantis Fuel Community Edition хорошо умеет разворачивать достаточно сложные конфигурации с использованием файлового хранилища Ceph, отдельными контроллерами и т. д., но с точки зрения администратора установленный таким образом кластер представляет собой своего рода «чёрный ящик» — все изменения конфигурации делаются через веб-интерфейс, а то, что исправлялось вручную, может быть затёрто, например, при добавлении в кластер нового узла. Плюс требуется выделенный сервер в качестве управляющей машины и достаточно сложная конфигурация сети с тремя интерфейсами на каждый узел кластера. В результате было принято решение создать сценарий развертывания кластера OpenStack самостоятельно на базе Ansible, для чего была сформирована команда из четырёх человек. В качестве пакетной базы было принято взять за основу пакеты из RDO, некоторые пакеты пришлось пересобирать с изменениями.
Проблемы, возникшие при эксплуатации OpenStack, и поиск альтернативы
После обкатки решения на стенде и развертывания окончательного варианта OpenStack на кластере выбранной конфигурации первые разработчики и тестеры начали получать учётные записи. И если у тех, кто уже имел опыт работы с OpenStack, никаких проблем не возникло, то те сотрудники, которые привыкли работать с Virtuozzo, начали жаловаться на отсутствие полноценных снимков состояния VM (так называемых live snapshots) и невозможность создания VM с реальными адресами на интерфейсе — 1:1 NAT, используемый в OpenStack, не всегда удобен. Кроме этого, администрирование кластера OpenStack довольно трудоёмко и затратно из-за его сложности. Поэтому руководство компании поручило рассмотреть альтернативные варианты, которые имеют поддержку полных снимков состояния VM. Было рассмотрено три продукта — Apache CloudStack, Proxmox и OpenNebula. CloudStack был отклонён из-за сравнимой с OpenStack сложности в развёртывании и использовании Java/Tomcat, что могло бы затруднить оперативное внесение изменений. Proxmox — из-за того, что он поставляется в виде дистрибутива ОС, а не в виде универсальных пакетов для ОС. В результате мы остановились на OpenNebula, которая представляет собой очень простую в установке и настройке (всего три пакета) и написанную на языке Ruby открытую облачную платформу, предоставляющую всю необходимую нам функциональность.
Преимущества OpenNebula
Одним из важных преимуществ OpenNebula является модель разработки. Разработка координируется из единого центра и ориентируется на нужды конечных пользователей, в то время как OpenStack ориентируется на нужды участвующих в его разработке и конкурирующих между собой вендоров. Второе важное преимущество — иной взгляд на модель облака. Если OpenStack изначально разрабатывался по модели Public Cloud в качестве открытой замены AWS и лишь потом начал проникать в корпоративный сегмент, то OpenNebula разрабатывалась по модели Enterprise Cloud, глядя на VMware vCloud в качестве образца.
Заключение
В результате успешного внедрения два кластера OpenNebula эксплуатируются без сбоев уже около пяти месяцев, что позволило нам значительно повысить эффективность разработчиков и тестеров, внедрив технологии непрерывной интеграции.
!.jpg)
Примечания и отзывы
Plays:1020
Comments:2