openstack что это простыми словами
Боль и страдания Openstack
Содержание статьи
OpenStack — очень модное слово в современном айтишном медиапространстве. Слышал о нем практически каждый, но в деле видели не очень многие. А попробовать его всерьез отважились вообще единицы. Мы у себя рискнули-таки, и сегодня я расскажу, чем это для нас обернулось и почему мода зачастую бежит впереди рассудительности и стабильности.
Мы уже как-то писали краткий обзор «карманной облачной инфраструктуры» в одном из предыдущих номеров, но было это давно и неправда (подумать только, уже почти три года прошло!). Так что на всякий случай вот краткая выжимка: OpenStack — это открытая (Apache License 2.0) платформа, позволяющая малыми силами организовать на любом количестве железных серверов облачную инфраструктуру а-ля Amazon Web Services. Тут вам и масштабирование виртуалок, и живые миграции, и балансировка нагрузки по нодам, и устойчивость к выходу из строя некоторого процента узлов. В числе основных разработчиков — небезызвестная NASA и Rackspace, Red Hat, Canonical, IBM, AT&T и некоторые другие конторы. В целом затея благая и очень дельная — такой инструмент, в теории, был бы полезен при разработке различных новых систем и сервисов, позволяя на ходу жонглировать инфраструктурой, экспериментировать с архитектурой. Но это все в теории и официальном описании. А что в жизни?
История первая
В жизни все сильно сложнее. OpenStack — это как беременность в шестнадцать. Завести его себе обычно оказывается сильно проще, чем потом с ним адекватно сосуществовать. Через день, неделю, если повезет, то через месяц придет Осознание. К примеру, в один не очень прекрасный момент по какой-то причине виртуалки просто перестанут создаваться. Все хорошо, все есть — и место на дисках, и свободные вычислительные мощности, и IP-адреса в сети. Но нет. Висит себе в состоянии Creating Instance, и все. Полчаса, час, два, пять. Ничего не происходит. В логах тишина. Еще несколько часов, проведенных в гугле, наудачу перезагружаем «кролика», и оп — все внезапно заработало. Виртуалки создаются, поднимаются, все снова хорошо. Вопрос «И что это было?» повисает в воздухе.
История вторая
Злоключение
Как уже успели на себе прочувствовать те немногие, кто решился использовать OpenStack в относительном продакшене, он еще «не готов для десктопа». Пока, к сожалению, он не дает удовольствия ограничить общение с собой исключительно нажиманием кнопочек в веб-интерфейсе для создания новых виртуалок и распределением доступов к ним. Шаг вправо, шаг влево — и можно наткнуться на что-то такое, про что еще даже в гугле не написали. И на отладку может уйти не только не один день, но даже не одна неделя. Ребята в одной из самых известных компаний — поставщиков готовых решений на базе OpenStack сравнивают этот процесс с постройкой дома:
«При упоминании OpenStack хороша аналогия с домом. OpenStack опирается на множество сложных открытых проектов, слепленных друг с другом через различные API, которые зачастую ставят в тупик даже самых прожженных инженеров. С точки зрения бизнеса попытка самостоятельно во всем этом разобраться может пагубно сказаться на сроках сдачи проекта и достижении поставленных целей. Подход „сделай сам“ пока еще очень популярен в среде OpenStack-новичков и часто не приводит их к сколько-нибудь удовлетворительному результату, отчего мнение о всей системе остается не очень лестное.
Главной целью поставщика готовых решений в данном случае является помощь в проектировании и развертывании надежной площадки для проектов клиента. И ключевой момент в данном вопросе — правильный выбор опытного поставщика, который сможет собрать все необходимые части системы, корректно их связать и в дальнейшем поддерживать то, что получилось. Пожалуйста, доверьте поддержку OpenStack проверенному поставщику».
В чем-то с ними даже можно согласиться. Далеко не каждый может позволить себе тратить такое количество админо-часов на даже банальное поддержание текущей работоспособности системы, не говоря уже о каком-то дальнейшем развитии.
О новинках
Но если капризы работоспособности OpenStack’а — это уже в некоторой степени стабильный вопрос, немало обшученный, то новинкам проекта, думаю, стоит уделить внимание.
Heat — это основной инструмент оркестровки, используемый в мире OpenStack. Он позволяет запускать готовые облачные архитектуры из темплейтов, описанных текстом, своего рода подобием программного кода. Формат темплейтов у Heat свой собственный, но помимо него поддерживается совместимость с форматом AWS CloudFormation. Таким образом, многие уже готовые темплейты CloudFormation вполне можно будет запускать и под OpenStack’ом. У Heat есть возможность общаться с внешним миром как через родной ReST API OpenStack’а, так и через совместимый API запросов CloudFormation’а.
Хакер #191. Анализ безопасности паркоматов
Как это вообще работает?
Ничего знакомого в этом всем не заметил? Правильно, схожие идеи мы уже видели в таких проектах, как Chef и Puppet. Использовать или нет — это уже на твой вкус. Говорят, у Heat’а даже есть какое-то подобие интеграции с ними, но мы пока не пробовали, так что детальнее рассказать, к сожалению, не смогу.
Ceilometer
Ceilometer — это инструмент для сбора различных статистических данных в облаке OpenStack. Основной целью проекта является мониторинг нагрузки и измерения потребления ресурсов клиентами, но возможности фреймворка могут быть расширены и для других нужд. Доступ к метрикам можно получать через отдельно реализованный REST API.
Архитектура Ceilometer
Центральный агент (Central Agent) опрашивает данные по утилизации ресурсов, которые не связаны с виртуальными машинами или вычислительными узлами (Compute Nodes). В каждой системе Ceilometer может быть запущен только один центральный агент.
Вычислительный агент (Compute Agent) собирает данные измерений и статистику с вычислительных узлов (в основном гипервизора). Вычислительный агент должен быть запущен на каждом вычислительном узле, состояние которого необходимо отслеживать.
Коллектор (Collector) отслеживает очереди сообщений (на предмет уведомлений, которые присылает инфраструктура, и на предмет результатов измерений от агентов). Уведомления обрабатываются, преобразовываются в измерительные данные, затем подписываются и возвращаются на шину передачи сообщений в соответствующую тему. Коллектор может работать на одном или нескольких серверах управления.
Хранилище данных (Data Store) — это база данных, которая может обрабатывать одновременные запись (с одного или нескольких коллекторов) и чтение данных (с API-сервера). Коллектор, центральный агент и API могут работать на любом узле.
Эти службы сообщаются с помощью стандартной шины передачи сообщений OpenStack. Только коллектор и API-сервер имеют доступ к хранилищу данных. Поддерживаются SQL базы данных, совместимые с SQLAlchemy, а также MongoDB и HBase. Однако разработчики Ceilometer рекомендуют именно MongoDB, в связи с более эффективной обработкой одновременных операций чтения/записи данных. Кроме того, только конфигурация Ceilometer с MongoDB прошла тщательное тестирование и развертывание в коммерческих средах. Для базы данных Ceilometer рекомендуется использовать выделенный узел, так как инфраструктура может создавать изрядную нагрузку на БД. Согласно оценкам разработчиков, измерение инфраструктуры на коммерческом уровне предполагает до 386 записей в секунду и 33 360 480 событий в день, что потребует до 239 Гб для хранения статистики за месяц.
Архитектура Ceilometer
В проекте Ceilometer реализованы три типа измерений:
Каждый измеритель собирает данные с одного или нескольких образцов (собираемых из очереди сообщений или агентами), которые представлены счетчиками. Каждый счетчик имеет следующие поля:
Полный список доступных на данный момент измерений можно найти в документации Ceilometer (https://wiki.openstack.org/wiki/Ceilometer).
Ceilometer — это довольно перспективный проект, ставящий своей целью унификацию возможностей по сбору информации обо всех аспектах жизни облачной инфраструктуры. Использование Ceilometer позволяет поставить «карманное облако» на достаточно крепкие коммерческие рельсы.
Зе енд
Как видно, не все так просто в Датском королевстве. Есть там место и бедам и приключениям. OpenStack развивается очень активно, но все еще не готов к быстрому и простому использованию в производстве, как некоторые продукты коммерческой виртуализации прошлого поколения.
Если виртуализация — это одно из основных направлений твоей деятельности, то, без сомнения, уже пора начинать в нем разбираться. Если нет, но все равно интересно, то, пожалуйста, пробуй, но в производство без крайней нужды пускать не советую. На данный момент лучше будет пользоваться классическими системами виртуализации всем, у кого нет особых против того противопоказаний. Сбережете много нервов и денег. Мы же у себя подумываем в некотором не очень отдаленном будущем тоже открывать направление поддержки OpenStack-решений. Кажется, это будет довольно интересно :).
Итак, вы решили развернуть OpenStack
Вы наверняка слышали об OpenStack. Блин, да о нем говорят на каждом более-менее связанном мероприятии. Все кому не лень пропагандируют OpenStack. Модно, молодежно, все уже есть, Open Source, вливайся давай. И вот наслушавшись тонны маркетингового булшита, вы решаетесь: Будем ставить OpenStack!
Я не проводил специальных изысканий на этот счет, но отрицательных отзывов о нем вроде бы не так много, по крайней мере на русском. На первый взгляд все выглядит просто фантастически. Что ж, извольте представить мой личный пост ненависти к OpenStack.
Предыстория
Об OpenStack я узнал на одной из конференций по OSS году примерно в 2012-м. В то время я работал в компании активно использующей большие кластера (100+ машин), однако без виртуализации, оркестрирования (kickstarter + IBM CSM в счет?) и в основном с пакетным исполнением задач: запустил, отработало, забрал результат. Полноценного понимания что такое облака и зачем они нужны еще не было, но интерес возник. Конечно сразу же возникло желание развернуть новую крутую штуку, которая вот прям сейчас сделает все хорошо.
Чуть позже в том же году, такая возможность представилась, правда уже в рамках стартапа. Нужно было развернуть проект, использующий кластеризацию и горизонтальное масштабирование, при этом нужна была изоляция окружений и совместное использование ресурсов одной машины несколькими службами — бюджет все-таки не резиновый.
В общем, в 2012-м мы развернули OpenStack, на тот момент это был Essex, запустили проект, прожили с такой облачной инфраструктурой до 2014-го года, кажется до релиза Grizzly включительно. Сил и желания поддерживать его дальше не было, и OpenStack был с позором выпилен.
Когда-то давно я даже думал написать статью как правильно его ставить, с комментариями на что обратить внимание. Но знаете, я передумал. Не ставьте его лучше вообще. Просто не связывайтесь. Вероятно, часть тезисов уже устарела, напишите в комментариях о том какой я м***к и ничего не понял, но в целом не думаю, что ситуация кардинально поменялась.
Итак, приступим, что же мне не нравится в Openstack и весьма вероятно не понравится вам.
Он чересчур комплексный
Даже не так. Он, *****, МОНСТРУОЗНЫЙ. Нет, взгляните сами.
Когда-то давно, когда мы ставили Essex, там было все относительно просто и понятно. Keystone (служба авторизации), Glance (служба хранилища образов) и Nova (служба управления гипервизорами). Кроме того там еще был Horizon (дашборд) и куча мелких и не очень зависимостей. Каждый узел системы обрастает чуть ли не десятками вспомогательных демонов. На controller node через некоторое время становится страшно смотреть.
Так, когда наш виртуальный кластер приблизился к 20 серверам, controller node стал безбожно тормозить, по непонятной причине. Ну точнее понятной, но мне непонятно, зачем identity service грузила процессор на 100%?
Из комплексности происходит следующий недостаток.
Он запутанный
Архитектура OpenStack достаточно сильно фрагментирована. Есть очень большое количество «движущихся частей», взаимосвязь который между собой не всегда абсолютно ясна. У вас что-то сломалось? Окей, попробуй понять где это что-то сломалось и почему. OpenStack Foundation похоже гордится, что в OpenStack более 20 миллионов строк кода, даже на главную своего сайта вынесли. Так вот, ЭТО НИФИГА НЕ ДОСТОИНСТВО.
Код в большинстве своем написан на Python. Спасибо, OpenStack, благодаря тебе я возненавидел Python и все что с ним связано. Возможно сейчас с документацией получше, но раньше ее практически не было. Логика вполне может начинаться в одном демоне, а потом с помощью запросов через RabbitMQ исполнятся совершенно в другом и даже на другой машине. Стоит ли говорить, что писать собственные расширения для OpenStack совсем не просто. Одно дело если это просто небольшой хак, другое дело если это полноценный подключаемый модуль с новым функционалом. 5 строчками кода вы точно не обойдетесь.
Если вам надо залезть под капот, чтобы понять что там происходит…
Дело в том, что являясь OSS, OpenStack пытается быть kind of unix-way. Т.е. под капотом все эти монструозные службы на самом деле дергают десятки и сотни unix-утилит по собственной логике, которую вам придется изучить и возможно даже дебажить. С документацией, по крайней мере раньше было, все плохо. Зачем вам рассказывать какие именно правила iptables мы добавляем на хост и для чего? У нас же суперкрутое приложение которое делает все само и не требует вашего вмешательства. Хотите добавить свои правила? Нуу, удачи, исходники-то открыты.
Пока вы более-менее вписываетесь в сценарий, предполагаемый авторами — все более-менее окей. Если же вам понадобилось сделать шаг в сторону, ждите трудностей. Запасайтесь man’ами, терпением, возможно вам придется изучить еще несколько несвязанных напрямую с задачей проблем, например как работает RabbitMQ и что ему еще надо?
Из этого проистекает следующая проблема.
Он ненадежный
Казалось бы логично, чем сложнее система, тем менее она надежна. Но видимо эта истина не для всех. Готовьтесь искать источник подземных стуков, запускать демоны в ПРАВИЛЬНОЙ последовательности, много гуглить и читать логи, копаться в исходниках и вот это все.
Некоторые решения на мой взгляд просто спорные. Служба метаданных на виртуальном IP-адресе эмулируемом через iptables? Серьезно? Очень «надежная» работа dnsmasq по выдаче IP виртуалкам. Тысячи их.
И это усугубляется тем, что…
Он становится еще больше
Как я уже упоминал, когда мы только начинали его использовать, служб было еще не так много, хотя некоторые проблемы были уже тогда. Но с каждым релизом служб становится еще больше.
Например, посмотрите на текущий список служб, каждая из которых добавляет еще несколько демонов на вашу машину:
Например, во времена Essex не было простого способа добавить запись о вашей новой виртуалке в ваш DNS-сервис. Руками — пожалуйста. Хуки? Не, не слышали. Я рождения designate так и не дождался.
Он ломается
От релиза к релизу. Т.е. ну вот вы наконец-то запилили инфраструктуру своей мечты, все худо-бедно работает как рассчитывали, но не хватает одной мааааленькой детали. А в новом релизе она есть. Ну по крайней мере по Release Notes.
Окей гугл, давай обновим наш OpenStack. И тут выясняется, что функционал, который вы с радостью использовали — выпилили. Ну потому что. Ну некрасивый он был и вообще, мы лучше сделаем, честно-честно. В следующем релизе. Может быть. А пока вот вам попроще, но ведь работает же! Ну и плевать что не в вашем случае, но работает!
В нашем случае это был функционал сети. Сеть вообще больной вопрос, доставляющий больше всего боли в OpenStack. В общем, наше приложение потребляет трафик из интернета, иногда весьма интенсивно. Конечно это не совсем стандартное требование, но наилучшим для нас вариантом было, когда виртуалки используют собственный хост в качестве роутера, а сам хост уже напрямую отправляет трафик провайдеру. И это можно было сделать в Essex. И это худо-бедно работало.
А в следующем релизе ребята из OpenStack решили что баста, мы выпилим функционал работы с сетью в отдельный модуль (будущий neutron), реализуем что-нибудь простое вроде один роутер на виртуальную сеть ну и играйтесь пока. Т.е. нужно было бы пустить весь трафик целого кластера через единичный узел нашей сети, он бы и стал бутылочным горлышком.
В итоге, OpenStack это такая штука, которая вот действительно, работает — не трогай. Даже не пытайся туда свои рученки совать, п**р. Лучше даже на всякий случай хосты не перезагружать, а то вдруг оно больше не поднимется? Любое обновление — это аврал, нервы, ненависть.
Он сырой (местами)
А еще очень дивное чувство испытываешь, когда тебе нужен функционал, ну, скажем, деление на зоны. Ну вот есть у тебя машины с большими винтами, есть с SSD, есть с видюхами, хочу разбить кластер на зоны, чтобы виртуалка падала на ту машину, у которой необходимый ресурс есть. Ну ок, читаем доку, вроде бы availability zones подходит. Настраиваем, включаем. И ничего. В доке написано что все должно, а на практике ничего. Лезем в код, а там.
Будет реализовано. В следующем релизе. Может быть. Ну ты понял. Смотри предыдущий пункт.
Есть ли плюсы, какие будут выводы?
Лично для меня вывод простой. Ванильную версию OpenStack лучше не использовать. Я не знаю как обстоят дела с вендорскими версиями и у всяких контор, торгующих инсталляциями «под ключ», но как по мне это несколько противоречит самой идеологии «свободного облака». Мы опять получаем vendor lock-in, только под другим соусом.
Хотите попытать счастье с ванильным OpenStack? Нет, ну в целом пожалуйста. Плагинов много, комьюнити большое, маркетингового булшита вообще выше крыши. Удачи, в общем. Но для небольших и средних инсталляций я бы скорее не советовал.
На мой взгляд одна из главных проблем OpenStack проистекает из не совсем верного архитектурного посыла. Стремясь сделать просто для конечного пользователя, они сделали по итогу слишком сложно. Любой допил под свои нужды превращается в кошмар, потому что даже такой простой и банальной вещи как хуки на события не завезли. А как бы это упростило реализацию многих вещей…
В общем после полутора лет борьбы с OpenStack мы от него отказались и перешли на другое облако. Управление инфраструктурой стало простым и приятным, а обновлять версий также просто как apt dist-upgrade.
Что это за облако и почему оно удобнее OpenStack я постараюсь рассказать в следующей статье. (Спойлер: это OpenNebula).
VMware vs OpenStack: сравниваем две платформы для развертывания инфраструктуры
VMware и Openstack — две платформы, между которыми обычно выбирают, когда хотят развернуть виртуальную инфраструктуру.
Разберемся, почему сравнивать VMware или Openstack на самом деле некорректно и какое решение больше подойдет для инфраструктуры на своих серверах и в облаке.
Как устроены VMware и OpenStack и почему на самом деле нельзя их сравнивать
В интернете часто сравнивают VMware и Openstack «в лоб». На самом деле делать так не совсем корректно — ведь это не просто два продукта, а принципиально разные инструменты со своими особенностями и функциями. Разберем особенности каждой платформы и посмотрим, что на самом деле мы сравниваем.
Что такое VMware и как она развивалась
Что такое VMware. Это не одна платформа, а вендор с несколькими продуктами. У компании много продуктов, среди которых есть VMware vSphere — платформа для виртуализации. VMware создали эту платформу, в том числе лежащий под ней гипервизор ESX, чтобы оптимизировать работу серверов: уплотнить нагрузку на них, использовать их ресурсы эффективнее, а следовательно, экономить, кроме того, получить дополнительную гибкость управления виртуальными машинами. В частности, быстрее выдавать ресурсы под новые проекты и легче масштабировать их под существующие. То есть VMware — это про серверы.
Что входит в платформу. В ее состав входят несколько основных компонентов и механизмов, например:
В зависимости от версии могут быть добавлены такие инструменты, как vRealize Operations для мониторинга виртуальных машин и инфраструктуры, программно-определяемое хранилище VMware vSAN, можно отдельно купить и добавить виртуализацию сетевых функций VMware NSX. Есть и много дополнительного софта, например, продукт для пребиллинга, позволяющий отправлять данные в CRM для расчета конкретных цен, или инструмент для бесплатной миграции Physical-to-Virtual.
Особенности. VMware vSphere задумывалась для виртуализации и работы с виртуальными машинами — для их создания, оптимизации и поддержки. Сейчас вендор пытается изменить такое представление, добавляя дополнительные сервисы для автоматизации. Не только те, которые мы видели выше: есть и такие компоненты, как vRealize Automation, по сути, являющийся основой реализации частного облака — он позволяет автоматизировать управление инфраструктурой. Однако этот инструмент дает только базовую функциональность. Если нужно реализовать что-то дополнительное, то дальше нужно дописывать код, чтобы получить желаемое поведение системы.
VMware vSphere — готовый коробочный продукт. Приобретая его, вы сразу получаете инструменты виртуализации, можете дополнять их готовыми решениями от вендора.
Так выглядит облачная инфраструктура, которую создает VMware vSphere: гипервизор стоит поверх железных серверов, ВМ — внутри гипервизора, а управляет всем VMware vCenter Server. При этом управляющий сервер также установлен на виртуальной машине, не используется контейнеризация, что не позволяет получить активную балансировку нагрузки и другие преимущества подобной реализации
VMware долгое время считалась эталоном платформы виртуализации, пока большие провайдеры облачных услуг не стали создавать платформы, ориентированные больше на разработчиков, чем на администраторов. То есть не только предлагать больше инструментов для Self-Service на базе IaaS, но и реализовывать решения, закрывающие большинство типовых задач по разработке, часто сокращая объем кода, который нужно писать для реализации бизнес-логики.
При этом облачные платформы нового типа позволяют разработчикам использовать ресурсы без привлечения администраторов, что разгружает последних для других задач. Современный рынок стал диктовать новые требования, VMware перестала им соответствовать и теперь только пытается догнать новые тренды и закрыть потребности пользователей. Зато появились новые платформы, в том числе и Open Source, позволяющие на 100% закрыть задачи разработки.
Что такое OpenStack и из каких компонентов состоит эта платформа
OpenStack. Это модульная платформа, основное предназначение которой — автоматизация рутинных задач системного администрирования на всех уровнях ИТ-среды.
OpenStack начал развиваться после успеха AWS, сервисы которого долгое время доминировали на рынке. Было очевидно, что предпочтения пользователей сдвигаются в сторону платформ, обеспечивающих богатый инструментарий для разработки, предоставляющих широкие возможности для автоматизации построения IT-систем, а также поддержания их высокой производительности и надежности. Именно такой платформой и стал OpenStack: решение позволяет реализовать Cloud Native-подход к разработке и Self-Service в управлении инфраструктурой. То есть OpenStack — это платформа для разработки и инструмент для качественного предоставления сервиса конечным пользователям платформы виртуализации.
OpenStack состоит из Open Source-проектов, объединенных единой идеологией. Соответственно, в состав платформы входит множество инструментов, которые можно использовать для создания облачной инфраструктуры:
У всех компонентов открытый исходный код — их можно модифицировать под свои нужды. Компоненты OpenStack можно реализовывать с помощью разных технологий, в том числе заменять стандартные собственными разработками. Уже конкретные механизмы — гродукты/решения, обеспечивающие работу того или иного компонента, — управляются специальными драйверами, которые обычно готовятся производителем или разработчиком нужного софта, но также можно найти свободные реализации от сообщества разработчиков. Обычно существует как минимум один готовый продукт, который также имеет открытый исходный код и поставляется с нужным компонентом в стандартной комплектации.
Все модули OpenStack можно запускать в контейнерах — для них это даже рекомендуемый сценарий деплоймента, позволяющий получить и гибкость, и надежность. То есть платформа реализована в полном соответствии с Cloud Native-подходом.
OpenStack не привязан к какому-то конкретному типу гипервизора — платформу можно поставить поверх любого решения.
Так может выглядеть устройство OpenStack c применением виртуализации через KVM
Чаще всего OpenStack по умолчанию используют с гипервизором KVM. В компоненте также реализована функциональность по управлению большим количеством гипервизоров. Их можно объединять в вычислительные кластеры и далее управлять ресурсами на более высоком уровне абстракции — OpenStack также называют облачной операционной системой. Это помогает создавать высокодоступные сервисы за счет избыточности ресурсов кластера и механизмов управления гипервизорами.
Механизмы, которые нужны для работы KVM, встроены в ядро Linux. Поэтому KVM обычно поставляется именно с этой ОС, и поэтому OpenStack хорошо поддерживает разное физическое оборудование, так как для него под Linux уже существуют драйверы.
Как упоминалось выше, KVM также опенсорсный инструмент, для его использования не нужно покупать лицензию. Чтобы посмотреть, что он умеет, не нужен даже отдельный сервер — можно быстро развернуть специальный дистрибутив DevStack в виртуальной машине на своем ноутбуке. Есть и другие гипервизоры, с которыми может работать OpenStack, например XEN.
Если использовать OpenStack с платформой виртуализации от VMware, данная функциональность перекладывается на vSphere, так как тут производитель предлагает свои проприетарные инструменты.
Так выглядит OpenStack, установленный над продуктом VMware vSphere с помощью его гипервизора
Благодаря модульности OpenStack и широким возможностям ее кастомизации платформу используют облачные провайдеры для построения на ее основе своих облаков — у них обычно достаточно компетенции и ресурсов, чтобы полностью довести платформу до ума. Самостоятельно построить такое решение в виде частного облака сложно: нужно много ресурсов, хорошее оборудование и штат профильных специалистов. OpenStack также помогает провайдерам размещать на инфраструктуре продвинутые платформенные сервисы за счет большого количества совместимых модулей — на обычных платформах виртуализации это сложнее, а часто и невозможно. По этой же причине платформа подходит для построения частных облаков.
Так что мы сравниваем?
Получается, что, сравнивая VMware vSphere и OpenStack, мы сравниваем, по сути, два разных продукта:
Но можно поговорить об особенностях коробочного решения VMware vSphere и OpenStack на базе любого гипервизора, а также об их возможностях на практике.
Функции VMware: платформы для обычной виртуализации на собственном железе
VMware vSphere — готовый продукт, который можно купить у компании VMware. Платформа давно на рынке, зарекомендовала себя как стабильное и надежное решение для виртуализации серверов.
У него есть следующие особенности, которые иногда бывают преимуществом:
В VMware vSphere есть набор нужных инструментов для виртуализации. Систему просто развернуть, не нужно ничего дорабатывать и интегрировать. Благодаря этому с виртуализацией справится даже не очень опытный системный администратор.
VMware vSphere — один из первых продвинутых продуктов для виртуализации, сама платформа отлично работает и упростила жизнь многим администраторам.
С помощью VMware vSphere можно в виртуальной среде почти полностью повторить ту инфраструктуру, которая была на железных серверах. Это может быть важно, если вы используете старое ПО, которое не умеет работать в среде виртуализации и тем более в облаках. Тогда с помощью VMware можно с высокой точностью имитировать в виртуальной среде железные серверы и связи между ними, устаревшее ПО будет чувствовать себя на нем как дома. Также есть современный софт, который разработан с учетом особенностей VMware. Однако многие современные приложения реализованы иначе, в том числе с отказоустойчивостью на уровне приложения. Тогда VMware уже не будет лучшим вариантом для их размещения, а всего лишь одним из многих.
Так как это достаточно старое решение, на рынке много администраторов, которые умеют работать с платформой.
Недостатком VMware можно назвать неполное соответствие современным подходам Cloud Native. Они предполагают, что используются легко заменяемые в случае отказа Commodity-серверы. Механизмы надежности, которые идеально отработаны в VMware, в современном мире часто превращаются в минус. Дело в том, что обеспечивать надежность за счет инструментов платформы дорого, и здесь чем выше SLA, тем дороже разработка.
При Cloud Native-подходе проблема решается перемещением механизмов надежности внутрь разрабатываемого ПО, что повышает надежность среды в целом. При построении приложений с Cloud Native-архитектурой настроить механизмы автоматического восстановления штатной работы системы с минимальной потерей данных и простоем намного проще. Ведь разработчики сами заложат правильные механизмы защиты и восстановления с учетом логики приложения. Обучать платформу правильно работать с приложениями, как это происходит в случае с VMware, в разы сложнее и затратнее.
Cloud Native-подход снижает затраты на инфраструктуру, помогает не потерять в надежности и получить дополнительную гибкость. Также он позволяет избавиться от vendor lock-in: требования к приложениям у всех облачных провайдеров примерно одинаковы, переносить их из одного облака в другое проще, чем Legacy-приложения, под которые ориентирована VMware.
Получается, что VMware хорошо подходит для реализации обычной виртуализации под стандартные приложения, что дает не только плюсы, но и минусы. Можно реализовать ее, не нанимая дорогих подрядчиков, а потом обслуживать систему силами рядовых системных администраторов. При этом полный доступ к ВМ есть только у сисадминов: разработчики и другие конечные пользователи через веб-интерфейс смогут только включать и выключать виртуалки, создание и конфигурирование машин им недоступно.
OpenStack: облачная платформа, предназначенная для быстрой разработки
OpenStack — модульная система для построения частных и публичных облаков, в отличие от VMware здесь больше набор инструментов и есть возможности self-service. Для виртуализации можно выбрать и установить любой гипервизор.
У OpenStack есть следующие особенности:
OpenStack разрабатывался после появления AWS, фактически как его клон и основа для работы различных сервисов, ускоряющих разработку, например, сервисов оркестрации контейнеров, очередей сообщений и других. AWS впоследствии ушел вперед, поэтому современные провайдеры, использующие OpenStack, часто дорабатывают платформу и разрабатывают собственные, более продвинутые, дистрибутивы. После настройки платформы разработчики могут сами, без участия администратора, создавать, конфигурировать и удалять виртуальные машины для разработки и тестирования, запускать контейнеры и так далее. Это позволяет сократить время выпуска IT-продуктов на рынок за счет ускорения их разработки.
Например, в облачной парадигме принята реализация отказоустойчивости на уровне приложения, а не на уровне инфраструктуры. Такой подход позволяет сэкономить, так как отказоустойчивость на уровне инфраструктуры обходится дороже. О причине мы говорили выше: надо придумывать механизмы, которые позволят прозрачно резервировать ресурсы приложений и открывать к ним доступ. Эти механизмы вносят дополнительные накладки, в том числе на обработку данных, при этом не гарантируют 100% бесперебойной работы систем, так как нет возможности полноценно мониторить работу приложения и видеть причину сбоев. Реализация отказоустойчивости на уровне приложения не только выгоднее, но и делает приложение независимым от инфраструктурных сбоев и ошибок администратора. OpenStack как инфраструктурная платформа хорошо подходит именно для современных Cloud Native-приложений.
У каждого модуля есть свое предназначение, но за счет наличия драйверов для различных сочетаний можно под каждый модуль выбирать из нескольких продуктов. Это дает дополнительную гибкость в итоговой реализации платформы. Также у OpenStack открытый исходный код. Это значит, что все модули платформы можно изменять и дорабатывать как угодно в зависимости от потребностей компании, главное — наличие внутренней экспертизы. Вокруг OpenStack большое комьюнити, которое разрабатывает и развивает платформу. Это значит, что в интернете много готовых изменений и модулей, разработанных другими программистами — можно выбрать что-нибудь подходящее. Компоненты VMware по функциональности сильно ограничены по сравнению с OpenStack, они не такие гибкие.
OpenStack — бесплатная платформа. Чтобы ее устанавливать, использовать и дорабатывать, не нужно ничего платить. Это поможет сэкономить деньги на лицензиях, так как продукты VMware платные.
Сокращаются расходы на администрирование самой платформы и уже отданных разработчикам ресурсов. За счет Self-Service сокращается время разработки. Облачные провайдеры с платформами на базе OpenStack предлагают большое количество платформенных сервисов и готовых шаблонов популярных инструментов для разработки в маркетплейсе. Это дополнительно сокращает Time-to-Market, экономит средства на выпуск IT-продуктов и позволяет обогнать конкурентов, не переключившихся на Cloud Native.
За такую гибкость приходится платить. Если вы хотите развернуть на OpenStack частное облако, поставить и настроить платформу будет сложнее, чем в случае VMware. Здесь не хватит рядового специалиста — понадобится опытный и умелый администратор, знакомый с ее спецификой, который потом также будет поддерживать платформу.
Однако в этом есть и плюс: такой администратор может сам поддерживать платформу. В то время как при возникновении проблем с VMware придется обращаться в техподдержку: развернуть платформу может любой, не разбираясь в ней, а вот чтобы поправить сбои, уже нужны знания и опыт. А еще администратор OpenStack после запуска платформы занимается только ее поддержкой, а не сидит и не выпускает виртуальные машины. ВМ себе запускает и конфигурирует уже сам пользователь платформы, то есть разработчик, указывая нужные параметры и не дожидаясь администратора.
В целом разворачивать частное облако на OpenStack дорого, долго и сложно: нужно покупать серверы, нанимать опытных системных администраторов и заниматься настройкой инструментов для разработки. Если вам понадобятся продвинутые технологии вроде Kubernetes, их также придется внедрять и настраивать самостоятельно, что вызывает трудности, несмотря на то что OpenStack хорошо интегрируется с любыми современными инструментами и есть сообщества пользователей, готовых делиться опытом.
Альтернативный вариант — использовать частное облако облачного провайдера. Эксперты провайдера помогут развернуть платформу на ваших серверах и настроить ее. В этом случае вы получаете больше, чем обычный OpenStack: поставщики облачных решений под ключ кастомизируют платформу, исправляя недостатки ее модулей, добавляя к ним новые и собственные разработки. А также реализуют на ее основе платформенные управляемые сервисы, вроде того же Kubernetes aaS, который в VK Cloud Solutions (бывш. MCS) сертифицирован CNCF, или облачных СУБД. Их также можно перенести на серверы клиента.
Также можно размещать приложения в публичном облаке, построенном на базе OpenStack. Так вы получите уже готовую инфраструктуру, на которой сможете быстро развернуть виртуальные серверы даже силами не самого опытного системного администратора, а также возможность в любой момент подключать нужные PaaS. Использование Kubernetes и контейнеров при этом снимает vendor-lock-in: и в облаке любого провайдера, и в On-premise можно использовать те же образы контейнеров, Helm-чарты и конфигурационные файлы. Это обеспечивает хорошую переносимость приложений между разными платформами.
Конечно, переезд в облако потребует переделать архитектуру ваших нынешних приложений. Зато в будущем их будет проще и дешевле обновлять, дорабатывать и делать отказоустойчивыми. А еще потом легче перенести всю инфраструктуру и приложения на другую платформу, если захотите сменить вендора. Получается, что выгоднее один раз потратиться на переезд в облако и доработку приложений — это поможет сэкономить в будущем.