Все так, Neutron в своей изначальной инкарнации был большой болью для разработчиков и операторов. После волны фрустраций коммьюнити конкретно за него взялось и смогло привести в состояние, пригодное для работы в сравнительно большом продакшене. Тому есть подтверждение, где-то с год назад мы проводили исследование его работоспособности (~200-250 нод) и даже выкладывали результаты в блог. Все это давно уже история, не вижу смысла тратить на это время.
Можно только порадоваться за вас, что скромные возможности OpenNebula полностью удовлетворяют потребности вашей компании. Тем не менее и для того "монстра" как OpenStack есть свой потребитель, и это как верно подметили ниже крупные ИТ и Телко компании, которым всегда нужно "чуточку больше". Более того, они инвестируют миллионы в развитие внутренней OpenStack экосистемы и инструментария управления жизненным циклом облака, просто потому что это позволяет в долгосрочной перспективе сэкономить десятки миллионов.
Претензию по поводу статей "как я развернул на 2 машины" лучше отправить их авторам. Лично я ничего плохого не вижу в том, что кому-то интересно поделиться своим опытом.
Вы так говорите, как будто это что-то плохое. Люди пробуют пробуют, разбираются, зачастую успешно, описывают свой опыт. Почему нет? У каждого свои задачи, которые он волен решать так как считает нужным. Я лично не вижу смысла тащить OpenStack туда, где справится что-то более простое.
Ну, поддержка ISO в OpenStack появилась, если не изменяет память, еще в Juno 3 года назад. В чем заключались ваши танцы с бубном, извините, не могу знать, допускаю что это ваш конкретный corner case.
Про недостатки и достоинства Fuel можно долго разговаривать, продукт прошел большой путь и в целом, нашел своего пользователя. В последнем 9 релизе его сильно переделали, тем не менее на этом его разработка прекращается, и остается только поддержка.
Если отбросить сарказм, то продукт действительно стал лучше по всем перечисленным вами параметрам.
кастомизацию стало делать проще, т.к. архитектурно продукт теперь гораздо больше выверен, с точки зрения изоляции функций облака в пределах выделенных сервисов и большего количества точек для интеграции. То, для чего раньше приходилось патчить код глубоко внутри, сейчас в подавляющем большинстве случаев достижимо через плагины. Дьявол, разумеется, в деталях.
компонентов, если речь идет о высокоуровневых подсистемах, таких как Keystone или Glance, стало больше, каждый из них несет свой набор функций. Но, по-прежнему, для минимально работоспособного облака вам будет достаточно набора из Keystone, Nova, Glance и Neutron (консерваторы могут ограничиться nova-network, да, оно еще поддерживается). Каждая из подсистем по-прежнему имеет свой набор сервисов, вынесенных в отдельные процессы, каждый выполняет отдельно выделенную функцию. В указанном минимальном наборе у вас будет крутиться 9 сервисов на контроллере (+инфраструктура: БД, RabbitMQ и т.д. ) и 3 на compute ноде. Подобный подход к архитектуре может быть не слишком удобен на небольших инсталляциях, но позволяет достаточно гибко масштабировать систему в долгосрочной перспективе.
надежней OpenStack стал. Не в последнюю очередь благодаря развитию обширной инфраструктуры функциональных и нагрузочных тестов. Ну и усилиями вендоров, разумеется. Да, проблемы случаются, но зачастую они связаны с неправильным проектированием конкретного облака.
документация OpenStack всегда находится в положении догоняющего, это факт. Тем не менее ответ на большее число простых вопросов она способна дать. Конкретно вашу проблему можно решить просто через т.н. provider networks либо через DVR.
Если вам действительно интересно, могу рассказать больше.
Это не есть правда. Например Mirantis Fuel начиная с 7 версии вполне способен развернуть production-ready облако на 50 и более машин. И таки да, из ISO. Он же решает проблему обновлений в пределах релиза.
Полностью избавиться от танцев с бубном, конечно, не получится, все-равно найдутся отдельные взятые клиенты у которых "не взлетает" из-за кривой конфигурации сети или экзотического RAIDа, но в общем случае юзабилити OpenStack за последние годы поднялся на более-менее адекватный уровень, не в последнюю очередь стараниями вендоров.
По этой причине собственно и появился MCP, который к OpenStack имеет весьма отдалённое отношение.
Вот ведь как. "А мужики и не знают..." Главное и непосредственное предназначение Mirantis Cloud Platform — обеспечение непрерывного цикла развертывания и управления enterprise-grade облаком. Это задача с которой, увы, так не смог (или не успел, если угодно) справиться Mirantis Fuel.
Все претензии изложенные в статье справедливы, но лишь отчасти и с точки зрения админа, которому начальство выделило пяток серверов и приказало "сделай облако". Инструменты нужно подбирать соответственно целям. Нужно что-то действительно простое, по функциям, архитектуре и внедрению? Берите ту же OpenNebula и не морочьте голову ни себе ни людям.
В общем, в 2012-м мы развернули OpenStack, на тот момент это был Essex, запустили проект, прожили с такой облачной инфраструктурой до 2014-го года, кажется до релиза Grizzly включительно. Сил и желания поддерживать его дальше не было, и OpenStack был с позором выпилен.
Вы бы еще про Cactus релиз написали. В 2017 году, ага. Во-первых, с тех пор OpenStack стал сильно лучше (но все еще не идеал, конечно). Во-вторых, вне зависимости от релиза, OpenStack надо уметь готовить — это я вам говорю с высоты 6 лет опыта, ~20 проектов разного масштаба и назначения и просто консультаций без числа.
Из коробки, да. В последнем релизе Havana выбор одного из L3/DHCP агентов для обеспечения сетевых функций выполняется при момощи механизма схожего с планировщиком, существующим в Nova github.com/openstack/neutron/blob/stable/havana/neutron/scheduler/l3_agent_scheduler.py#L33 Теоретически, его можно научить учитывать availability zone, но это потребует очень неплохого допиливания Neutron.
Другими словами, при «правильной» настройке виртуалки она будет сносить каждый из вычислительных узлов по-очереди.
Из какой информации вы сделали столь неожиданный вывод?
Потрясающее решение, да.
Повторю ещё раз: пока снизу там не будет адекватного софта, можно хоть триста уровней тулстека накрутить, стабильно работать не будет.
Позвольте и мне повторить, «из коробки» в вопросах построения виртуальной вычислительной сети OpenStack опирается на штатные возможности сетевого оборудования и ОС вычислительных нод. Задачу обеспечения отказоустойчивости виртуальной сети OpenStack _не решает в принципе_. Хотите застраховаться от сетевых атак изнутри — выбирайте и настраивайте «адекватный софт» самостоятельно, поддержать его со стороны оркестратора большой проблемы не составит.
Задача, которую решал автор данной статьи — обеспечение отказоустойчивости _элементов сети управления_, а не сети данных. При грамотном подходе к построению кластера из виртуалки вы контроллер не положите — в худшем случае потеряется вычислительная нода, не более того. Для защиты от злоумышленников изнутри необходимо применять совсем иные средства. Самое простое что приходит на ум — ограничение пропускной способности виртуального NIC средствами гипервизора или хост-системы, наверняка можно придумать и что-то поумнее — выбор в конечном итоге остается за вами как за архитектором кластера, стоит ориентироваться на специфику конкретной инсталляции. Короче говоря, суть вашей претензии не совсем ясна.
Значит, в будущем мы также увидим оптимизацию OpenStack под процессоры Intel, что, как и в случае с Hadoop, наверняка позволит получить заметный выигрыш.
Какая чушь. Что можно оптимизировать в OpenStack под процессоры Intel? Скрипты на Python??
— OpenStack пытается раскрутиться через громкое слово «облако» и поддержке «Rackspace and NASA». Другие знаменитые компании подключаются к этому проекту. Хотя всё может оказаться не так радужно. Бесконечной масштабируемости в настоящее время нет.
Очень неожиданный вывод, учитывая что Swift сам по себе не является неотъемлимой частью OpenStack. Можно без особенных проблем сконфигурировать кластер для работы с любым S3-совместимым хранилищем. И, поверьте, большая часть коммьюнити совсем не в восторге от Swift, который все еще страдает кучей детских болячек.
Все так, Neutron в своей изначальной инкарнации был большой болью для разработчиков и операторов. После волны фрустраций коммьюнити конкретно за него взялось и смогло привести в состояние, пригодное для работы в сравнительно большом продакшене. Тому есть подтверждение, где-то с год назад мы проводили исследование его работоспособности (~200-250 нод) и даже выкладывали результаты в блог. Все это давно уже история, не вижу смысла тратить на это время.
Можно только порадоваться за вас, что скромные возможности OpenNebula полностью удовлетворяют потребности вашей компании. Тем не менее и для того "монстра" как OpenStack есть свой потребитель, и это как верно подметили ниже крупные ИТ и Телко компании, которым всегда нужно "чуточку больше". Более того, они инвестируют миллионы в развитие внутренней OpenStack экосистемы и инструментария управления жизненным циклом облака, просто потому что это позволяет в долгосрочной перспективе сэкономить десятки миллионов.
Претензию по поводу статей "как я развернул на 2 машины" лучше отправить их авторам. Лично я ничего плохого не вижу в том, что кому-то интересно поделиться своим опытом.
Вы так говорите, как будто это что-то плохое. Люди пробуют пробуют, разбираются, зачастую успешно, описывают свой опыт. Почему нет? У каждого свои задачи, которые он волен решать так как считает нужным. Я лично не вижу смысла тащить OpenStack туда, где справится что-то более простое.
Ну, поддержка ISO в OpenStack появилась, если не изменяет память, еще в Juno 3 года назад. В чем заключались ваши танцы с бубном, извините, не могу знать, допускаю что это ваш конкретный corner case.
Про недостатки и достоинства Fuel можно долго разговаривать, продукт прошел большой путь и в целом, нашел своего пользователя. В последнем 9 релизе его сильно переделали, тем не менее на этом его разработка прекращается, и остается только поддержка.
Если отбросить сарказм, то продукт действительно стал лучше по всем перечисленным вами параметрам.
Если вам действительно интересно, могу рассказать больше.
Это не есть правда. Например Mirantis Fuel начиная с 7 версии вполне способен развернуть production-ready облако на 50 и более машин. И таки да, из ISO. Он же решает проблему обновлений в пределах релиза.
Полностью избавиться от танцев с бубном, конечно, не получится, все-равно найдутся отдельные взятые клиенты у которых "не взлетает" из-за кривой конфигурации сети или экзотического RAIDа, но в общем случае юзабилити OpenStack за последние годы поднялся на более-менее адекватный уровень, не в последнюю очередь стараниями вендоров.
Вот ведь как. "А мужики и не знают..." Главное и непосредственное предназначение Mirantis Cloud Platform — обеспечение непрерывного цикла развертывания и управления enterprise-grade облаком. Это задача с которой, увы, так не смог (или не успел, если угодно) справиться Mirantis Fuel.
Все претензии изложенные в статье справедливы, но лишь отчасти и с точки зрения админа, которому начальство выделило пяток серверов и приказало "сделай облако". Инструменты нужно подбирать соответственно целям. Нужно что-то действительно простое, по функциям, архитектуре и внедрению? Берите ту же OpenNebula и не морочьте голову ни себе ни людям.
Вы бы еще про Cactus релиз написали. В 2017 году, ага. Во-первых, с тех пор OpenStack стал сильно лучше (но все еще не идеал, конечно). Во-вторых, вне зависимости от релиза, OpenStack надо уметь готовить — это я вам говорю с высоты 6 лет опыта, ~20 проектов разного масштаба и назначения и просто консультаций без числа.
Из какой информации вы сделали столь неожиданный вывод?
Позвольте и мне повторить, «из коробки» в вопросах построения виртуальной вычислительной сети OpenStack опирается на штатные возможности сетевого оборудования и ОС вычислительных нод. Задачу обеспечения отказоустойчивости виртуальной сети OpenStack _не решает в принципе_. Хотите застраховаться от сетевых атак изнутри — выбирайте и настраивайте «адекватный софт» самостоятельно, поддержать его со стороны оркестратора большой проблемы не составит.
Какая чушь. Что можно оптимизировать в OpenStack под процессоры Intel? Скрипты на Python??
Очень неожиданный вывод, учитывая что Swift сам по себе не является неотъемлимой частью OpenStack. Можно без особенных проблем сконфигурировать кластер для работы с любым S3-совместимым хранилищем. И, поверьте, большая часть коммьюнити совсем не в восторге от Swift, который все еще страдает кучей детских болячек.