Pull to refresh

Сам себе AWS. Часть 0

Reading time 4 min
Views 42K
Доброго времени суток, %username%!

Сегодня я расскажу тебе, как при помощи напильника, кучки серверов и такой-то матери собрать что-то смутно похожее на EC2 от Amazon.
Статья получилась больше обзорная, так что придётся разбить её на несколько частей.

image
Я тебя слепила из того что было.

Это — демостенд, 6 х i5-3570T/8Gb RAM/рассыпуха всяких дисков.

Как-то встала у меня задача упорядочить все офисные сервисы, хаотично разбросанные по зоопарку серверов и операционок (у меня тут даже OpenBSD где-то бегает). И так вышло, что я давно хотел посмотреть на облака, а реального тесткейса не было. Так я и решил изучить, что нынче есть интересного в мире open-source и можно ли это применить в боевых условиях.

На текущий момент я посмотрел такие решения как MaaS + Juju имени Cannonical, RDO имени RedHat, Foreman с плагином и Fuel.

Забегая немного вперёд — Fuel для меня оказался самым адекватным, но пройдёмся по порядку.

MaaS

image
Простой и аскетичный дизайн

MaaS представляет собою концепцию Metal as a Service, по сути — занимается менеджментом «голого» железа. Вы можете выбрать какую версию убунты установить на тот или иной сервер, узнать его ТТХ и по сути всё. Сервера можно разделять по регионам доступности. Так же умеет работать с виртуалками через libvirtd. Интересное начинается когда вы прикручиваете ко всему этому Juju — теперь вы можете сказать «установи мне бложек» и оно выберет из списка доступного метала железку и накатит туда весь необходимый софт, как то mysql, apache, wordpress/drupal/etc. Мило, удобно, но когда я попытался подобным образом развернуть OpenStack, всё встало колом. Возможно я делал что-то не так, возможно что-то не так делали создатели конфигов для juju. Но в итоге мне не удалось нормально развернуть контроллер на одном сервере. Под каждый компонент контроллера оно хотело отдельную железку. Т.е. нужен вам keystone?, не вопрос — вот отдельный сервер под keystone. И так со всем. Ко всему этому добавилась моя нелюбовь к ubuntu как серверной ОС, так что решение пришлось отложить.

RDO

Этот проект мне понравился гораздо больше. Его преимущество было в одной команде: packstack --allinone. Вот так легко и незатейливо вы получаете рабочий OpenStack на одном сервере. Тут вам и контроллер и рабочая нода. Хотите кастомизации? не вопрос — редактируете полученный после первого запуска answer-file и запускаете packstack снова, указывая в качестве конфига этот файл. Легко, приятно, удобно. Смущало только одно — очень мало документации. Приходилось убивать кучу времени на решение странных ошибок, например потому, что забыл прикрутить нужный репозиторий. Местами даже приходилось править документацию на их сайте, чтобы она соответствовала текущей действительности, поскольку много вещей было написано для OpenStack Havana, а с тех пор много чего поменялось.
Возможно сейчас, зная гораздо больше про OpenStack и его внутреннюю работу, я бы дал второй шанс для RDO. Но новичку построить что-то отличное от стандартной конфигурации предлагаемой скриптом будет сложно. Кроме того, система предполагает что у вас уже подготовлены сервера и на них установлена Centos/RedHat minimal. Так что никаких PXE и прочих прелестей.

Foreman

image
Тысячи графиков, начальство будет счастливо

Сам по себе The Foreman это вебинтерфейс для управления puppet'овыми конфигами и в этой роли он вполне удобен и интересен. Но помимо этого он умеет и provisioning. Так что, как и с MaaS, вы можете сказать серверу грузиться по сети, а дальше управлять установкой через удобную вебморду. Имея такое удобное решение сложно было не прийти к идее разворачивания клауда на его основе. И всякие народные умельцы начали это потихоньку реализовывать. На текущий момент в nightly build'ах есть плагин foreman-installer-staypuft. С его помощью вы устанавливаете как сам Foreman, так и необходимые плагины. Удобство этой конструкции в том, что буквально из одной точки вы можете установить ОС (причём как Linux-based, так и Windows), после чего раздать нужные роли и установить необходимый набор софта. Или развернуть клауд, и опять же из вебморды foreman'а назначить роли для инстансов в этом клауде. Есть только одно существенное НО — ночные сборки достаточно нестабильны.
Возможно со временем это решение доделают и оно будет вполне production-ready, но на текущий момент можно только баловаться и отправлять багрепорты разработчикам. Благо они активно читают гугло-группу.

Fuel

image
У них похоже есть дизайнер

На текущий момент самое совершенное решение по разворачиванию клауда от достаточно именитой компании Mirantis. По сути — это заточенный исключительно на разворачивания клауда софт. Как и rdo/foreman — делает он это с помощью puppet'овых скриптов. Установка controller + 3 compute node занимает около 30 минут, зависит от скорости ваших винтов. Можно создавать как High availability, так и non-HA кластер. Умеет из коробки работать с Ceph, в версии 5.1 так же добавили драйвера для Mellanox'овых сетевух, что в комбинации LVM+Infiniband позволяет использовать RDMA (пока не проверял в действии, жду когда приедет свитч и сетевухи). Огромным плюсом является наличие большого количества документации.

В следующий раз я расскажу вам что же собственно у меня вышло сделать при помощи Fuel, немного про особенности ceph, как использовать несколько гипервизоров в одном клауде и как упростить себе жизнь автоматизировав всё и вся. А если ко мне таки доедет InfiniBand, то, возможно, и про особенности его работы с ceph и openstack.
Tags:
Hubs:
+36
Comments 17
Comments Comments 17

Articles