Панель управления¶
Панель управления (horizon) — это веб-интерфейс который позволяет администраторам и пользователям управлять различными ресурсами и сервисами OpenStack.
В этом примере установки используется веб-сервер Apache.
updated: 2019-08-16 16:59
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.
- Guides
- Install Guides
- User Guides
- Configuration Guides
- Operations and Administration Guides
- API Guides
- Contributor Guides
- Languages
- 日本語 (Japanese)
- Deutsch (German)
- Français (French)
- Português (Portuguese)
- 简体中文 (Simplified Chinese)
- 한국어 (Korean)
OpenStack vs VMware: что лучше — open source или проприетарная платформа
Чем отличается облачная платформа на OpenStack от облака на базе VMware? Собрали экспертов и подискутировали на тему того, что лучше.
Эта инструкция — часть курса «Начинаем работу с VMware».
Смотреть весь курс
Чем отличается облачная платформа на OpenStack от облака на базе VMware? Собрали команду системных администраторов, разработчиков и продакт-менеджеров, чтобы обсудить вопрос и подискутировать на тему того, что лучше. Посмотрели на платформы с позиции пользователя, разработчика, менеджера. О том, что из этого получилось, рассказываем в статье.
В чем ключевая разница между платформами?
Сторона OpenStack
OpenStack — это open source-решение для создания инфраструктуры на базе публичных и частных облачных сервисов. При этом важно отметить, что это не система виртуализации, а некий оркестратор для управления гипервизорами, на которых запускаются виртуальные машины. Любой специалист может клонировать репозиторий и поднять свое облако: весь код проекта написан на Python и распространяется по лицензии Apache 2.0. Вопрос только в том, насколько качественным получится результат.
«В Linux можно настроить все, и ты будешь это делать» — наверное, это самое краткое и прямое определение open source, которое актуально для крупных проектов вроде OpenStack. Если нужно написать дополнительный сервис — напишешь самостоятельно. Если найдешь готовый — склонируешь и допишешь, когда дело дойдет до поддержки кода.
Сторона VMware
VMware — это закрытая система виртуализации «из коробки». В этом смысле сравнивать ее с OpenStack не совсем корректно: его могут переписать в отличное от нативной платформы решение. Но задачу они решают одну и помогают строить облачную инфраструктуру.
Несмотря на закрытость VMware, потенциально любой разработчик может повлиять на развитие этой платформы, написать в «саппорт» и попросить добавить новую фичу. Но по факту компания может отложить эту задачу в бесконечный бэклог и ничего не сделать вовсе. Даже если была анонсирована бета той самой фичи.
Обновления в VMware делятся на две группы: «прилетающие» от самой компании и небольшие автоматизации с API, которые можно написать самостоятельно. В этом плане решение похоже на OpenStack, при работе с которым можно подтянуть новые фичи из главного репозитория. Хотя внутри VMware все равно ничего изменить нельзя.
Аренда удаленных рабочих столов
Арендуйте DaaS в облаке на базе VMware Horizon VDI для безопасной работы из любой точки мира.
В мире управления продуктами: что сложнее разрабатывать
Открытость/закрытость OpenStack и VMware влияет на операционные затраты компаний, которые их используют. В первую очередь это связано с количеством специалистов, необходимых для разработки и поддержания облаков. Давайте обсудим это подробнее — на примере продуктов Selectel.
Сторона OpenStack
OpenStack изначально задумывался под частные, а не публичные облака. Поэтому у разработчиков не было задачи предоставить публичное решение и сразу его продавать. Если нужно поднять частное облако, проблем не будет. Но по-быстрому установить OpenStack и предоставить публичное облако как услугу не получится — нужна команда разработчиков.
Облачная платформа Selectel построена на OpenStack и довольно много разработчиков занимаются развитием отдельных ее компонентов. Есть команды виртуальных серверов, дисков, хранилища, сетей и другие. Кроме них — команды инфраструктурных администраторов, отвечающие за железные хосты и деплой OpenStack, и дежурная служба, которая решает клиентские задачи. И это еще без учета фронтенд-разработчиков, UX-проектировщиков и тестировщиков.
Сторона VMware
Поднять облако VMware может даже один администратор. Для квалифицированного специалиста это похоже на простое скачивание программы. Но, если разработчик ничего не знает о «внутрянке», вряд ли получится развить облако как услугу. Поэтому у нас есть команда, которая постоянно работает с клиентскими задачами и старается улучшить путь от регистрации до развертывания машин.
Большая часть специалистов облака на базе VMware — администраторы. Они следят, чтобы все работало стабильно, распределяют квоты и ресурсы, отвечают на вопросы клиентов. Треть команды — разработчики, которые пишут различные интерфейсы поверх API VMware. Например, функциональность для автоматизации и создания сетей, работы с биллинговой системой, VMware Terraform и так далее. Если хотите присоединиться и развивать публичные и частные облака вместе с нами, следите за вакансиями.
В мире разработки: компоненты и возможности решений
Гипервизоры
В качестве гипервизора в VMware встроен ESXi. Это решение, которое эмулирует аппаратные ресурсы, позволяет безопасно выполнять машинные инструкции, изолирует и разделяет ресурсы виртуальных машин. ESXi следит, чтобы операционные системы работали в рамках своей виртуализации и не затрагивали «чужие области памяти».
В OpenStack можно использовать, например, тот же ESXi или Qemu. Мы в облачной платформе Selectel используем KVM — это популярное open source-решение по виртуализации, которое поддерживает все основные дистрибутивы Linux. Так, клиент облачной платформы может установить на виртуальную машину любой из 26 готовых образов. Например, Ubuntu 18.04, 20.04 или 22.04, Fedora 35 или 36, Windows Server 2012–2019, Debian, CentOs и другое.
По умолчанию облако на базе VMware также поддерживает большое количество дистрибутивов. Среди них — Windows Server 2012R2–2022, Ubuntu 16.04, 18.04, 20.04, Oracle Linux 7, CentOS 7, RHEL 7, а также сборки ubuntu-16.04_k8.
Хранение данных
Обычно для хранения данных вместе с VMware используют аппаратные СХД вроде NetApp, Dell, HPE, Fujitsu, Hitachi и других. Мы в облаке на базе VMware выбрали vSAN. Это объектное хранилище с возможностью гиперконвергенции, которое позволяет объединять диски со всех хостов виртуализации. В результате клиенты могут использовать разные политики хранения (Storage Policies) данных в рамках одного кластера — например, vSSD и vHDD. А также управлять «распределением данных», не меняя само железо.
Хранение данных в OpenStack реализовано похожим образом. В качестве СХД облачной платформы мы в Selectel используем Ceph. Это одна из самых распространенных Cloud Storage систем, на базе которой можно сделать, например, объектное или блочное хранилища, кластерную FS.
Интерфейс и управление виртуальными машинами
В основе VMware — Cloud Director. Это платформа, с помощью которой можно создавать свои виртуальные машины, настраивать сети, NAT и файрволы. У нас в облаке на базе VMware есть также панель управления, через которую клиент может работать с верхнеуровневым интерфейсом. С помощью него можно управлять виртуальными дата-центрами, следить за потреблением ресурсов и заказывать дополнительные услуги.
В нативном OpenStack в качестве «промежуточного звена» вроде Cloud Director есть панель Horizon, которая идет в комплекте. Но когда она появилась, ее качество было сомнительным. Поэтому мы в облачной платформе разработали свою панель управления, которая упрощает работу с виртуальными машинами.
Кроме базовых компонентов ядра OpenStack (Nova, Neutron, Cinder, Keystone), облачная платформа использует дополнительные модули. Например, компонент Glance для хранения образов и другие сервисы для служебных целей. В общей сумме их несколько десятков — в том числе Watcher и Octavia.
Почти все компоненты пропатчены от багов и дополняют функционал облачной платформы как для обычных пользователей, так и для разработчиков. В результате у пользователей есть функциональный интерфейс и возможность управлять инфраструктурой через OpenStack API.
Если вам интересно, как мы автоматизировали тестирование OpenStack с помощью Tempest и Rally, переходите по ссылке.
В мире клиента: какой продукт на выходе?
Технические особенности OpenStack и VMware вносят свои коррективы. Посмотрим на конечный продукт и сравним облачную платформу, реализованную на нашем дистрибутиве OpenStack, с облаком на базе VMware.
Сторона OpenStack
Открытость OpenStack предоставляет большой простор для разработки отказоустойчивых сервисов.
- Облачные серверы — виртуальные машины с оплатой по потреблению и соответствием 152-ФЗ, доступные в различных конфигурациях.
- Приватные решения публичного облака — изолированный хост, сегмент или весь пул на базе публичного облака.
- Частное облако — полностью изолированное облако на вашей инфраструктуре с возможностью управления из нашей панели.
- Аттестованное облако — виртуальные серверы, аттестованные для работы с государственными информационными системами до класса 1 (К1), 1Г и ИСПДн до УЗ-1.
Вместе со всеми продуктами можно использовать хранилище с резервным копированием, базы данных и контейнеры Managed Kubernetes в рамках одной приватной сети.
Кроме того, в облачной платформе есть система управления доступами. Прямо в панели управления можно добавить пользователя и назначить ему роль. Главное условное — чтобы он был зарегистрирован.
Сторона VMware
Клиенты облака на базе VMware работают с другим уровнем «абстракций». В панели управления они могут создавать виртуальные дата-центры с лимитами по количеству виртуальных ядер, оперативной и долговременной памяти.
- Публичное облако — масштабируемая инфраструктура с оплатой по потреблению и соответствием 152-ФЗ до первого уровня защищенности.
- Частное облако — полностью изолированная от других клиентов виртуальная инфраструктура с ежемесячной фиксированной оплатой.
- Удаленные рабочие столы в облаке — аренда виртуальных рабочих мест на базе VMware Horizon VDI.
- Резервное копирование облака — копирование, хранение и восстановление данных виртуальных машин и приложений с помощью Veeam® Backup & Replication™.
- Аварийное восстановление в облако — построение отказоустойчивой инфраструктуры без капитальных затрат с Disaster Recovery as a Service.
Публичное облако, резервное копирование и аварийное восстановление доступны в панели управления и Cloud Director, с помощью которого можно мониторить потребление ресурсов, управлять виртуальными машинами, файерволами и маршрутизацией в Edge-роутерах.
В облаке на базе VMware также есть система доступов. Можно создавать группы и пользователей прямо в панели управления или через Cloud Director. В последнем случае неважно, зарегистрирован ли аккаунт в самой панели Selectel.
Как использовать преимущества двух облаков
Облачная платформа и облако на базе VMware не ограничивают в инфраструктуре. С помощью глобального роутера их можно объединить в приватную сеть с другими продуктами Selectel, удаленным дата-центром или on-premise площадкой.
Выделенные серверы | Облачные базы данных | Файловое хранилище SFS | Межсетевые услуги |
Облачные серверы | Кластеры Kubernetes | Облако на базе VMware | Colocation |
Продукты, которые можно связать с помощью глобального роутера.
Сетевая связность позволяет совмещать преимущества нескольких услуг. Например, можно использовать удаленные рабочие столы в связке c виртуальными машинами облачной платформы. Подробнее о кейсах читайте по ссылке.
Заключение
Выбор между OpenStack и VMware касается не только провайдера и разработчиков. Клиенты могут получить облако со знакомой оболочкой Cloud Director, если работали с VMware ранее, или интерфейсом в панели управления Selectel. Вместе с этим — разные возможности по управлению доступом, мониторингу и управлению виртуальными серверами. А если нужно совместить преимущества сразу двух облаков — объединить их в рамках одной приватной сети.
Присоединяйтесь к дискуссии
Мы рассмотрели лишь базовые вопросы. В видеоверсии дискуссии эксперты обсудили лицензирование, перспективы развития облачной платформы на OpenStack и облака на базе VMware. А также ответили на вопросы зрителей.
Итак, вы решили развернуть 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 виртуалкам. Тысячи их.
И это усугубляется тем, что…
Он становится еще больше
Как я уже упоминал, когда мы только начинали его использовать, служб было еще не так много, хотя некоторые проблемы были уже тогда. Но с каждым релизом служб становится еще больше.
Например, посмотрите на текущий список служб, каждая из которых добавляет еще несколько демонов на вашу машину:
- Identity service (keystone)
- Image service (glance)
- Compute service (nova)
- Networking service (neutron)
- Dashboard (horizon)
- Block Storage service (cinder)
- Bare Metal service (ironic)
- Container Infrastructure Management service (magnum)
- Database service (trove)
- DNS service (designate)
- Key Manager service (barbican)
- Messaging service (zaqar)
- Object Storage services (swift)
- Orchestration service (heat)
- Shared File Systems service (manila)
- Telemetry Alarming services (aodh)
- Telemetry Data Collection service (ceilometer)
Например, во времена 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).
- Системное администрирование
- Виртуализация
- Облачные вычисления
Облако OpenStack – преимущества и недостатки
Платформа OpenStack широко используется в облачных вычислениях; вероятно, вы встречали это название при поиске облачной платформы для бизнеса. Мы, SIM-Networks, долгое время используем OpenStack для создания облачных решений, поэтому хорошо знакомы с особенностями этого ПО. В этой статье мы расскажем, что такое OpenStack, в чем основные принципы этого программного комплекса, чем платформа отличается от аналогов, а также поделимся кейсами применения облака на OpenStack.
Что такое OpenStack и как он работает?
OpenStack – это программный комплекс для развертывания облачных платформ, совместно разработанный компанией Rackspace и NASA. Эти инструменты доступны любому пользователю бесплатно, а код программы открыт – ПО можно модифицировать для любых индивидуальных потребностей. У облаков на OpenStack есть общие элементы, однако реализация каждого конкретного продукта на базе этой платформы уникальна.
Облачные платформы используют технологию виртуализации при помощи гипервизоров – на базе серверов создаются виртуальные машины, каждая из которых использует часть ресурсов физического оборудования. Однако этого недостаточно для создания облака – гипервизор не обеспечивает взаимодействие между виртуальными машинами. Без программных надстроек пользователь не сможет пользоваться общим хранилищем для нескольких машин, управлять группами инстансов, обеспечить сетевую связь между ними и т.д.
Облачная архитектура объединяет виртуальные машины в единую систему. Каждая из них использует ресурсы нескольких физических серверов – такую систему просто масштабировать. Чтобы моментально изменить конфигурацию инстанса, достаточно указать желаемые параметры в панели управления. Это невозможно в случае с физическим сервером или обычным виртуальным сервером (VPS) – придется покупать новые компоненты или заново развертывать VPS.
Среди других преимуществ облачных платформ – высокая отказоустойчивость, децентрализованный доступ к ресурсам и данным, простое управление, повышенная безопасность за счет распределенного хранения данных и т.д. Задача OpenStack – обеспечить эти возможности на базовом уровне и предоставить разработчикам инструменты для развития собственной платформы IaaS (Infrastructure-as-a-Service).
Из каких компонентов состоит OpenStack?
Программный комплекс OpenStack состоит из множества элементов, каждый из которых отвечает за определенный аспект работы облачной платформы – управление инстансами, безопасность, хранение данных и другое. Разработчики OpenStack выделяют 7 основных компонентов, необходимых для работы облака – рассмотрим их подробнее.
Nova – ключевой инструмент, который управляет пулом вычислительных ресурсов в облаке. Этот сервис предоставляет пользователям основной функционал облачной платформы – возможность создавать виртуальные машины и изменять их конфигурации «на лету» в взаимодействии с гипервизором.
Neutron – сервис, который отвечает за виртуальную сетевую инфраструктуру облака. Neutron обеспечивает взаимодействие между инстансами, а также предоставляет возможность создавать виртуальные сети, настраивать VPN и брандмауэр.
Glance – сервис для управления образами программного обеспечения. Образы (то есть виртуальные носители данных) используются для установки ПО на виртуальные машины. Glance создает библиотеку таких образов для быстрой и удобной подготовки виртуальной машины для выполнения задач.
Keystone – сервис аутентификации и распределения пользовательских прав в облаке. Этот инструмент используется для предоставления и ограничения доступа к ресурсам и функциям других компонентов посредством авторизации пользователя.
Cinder – блочное хранилище данных на базе ресурсов облака. Блочное хранилище – технология хранения данных, которая часто используется в виртуализированных платформах за счет высокой производительности при работе с большими объемами данных. По принципу работы, Cinder – эквивалент обычного жесткого диска.
Swift – объектное хранилище с поддержкой распределенного хранения данных. Неструктурированные данные могут храниться на нескольких жестких дисках, при этом Swift будет отображать их как единое целое для пользователя. Этот сервис также автоматически удаляет дубликаты данных для экономии пространства в хранилище.
Horizon – графический интерфейс управления облаком для конечного пользователя. При помощи этого инструмента пользователь может создавать инстансы, изменять их конфигурации, устанавливать права доступа и пользоваться другим функционалом остальных компонентов OpenStack.
Преимущества и недостатки платформы OpenStack
Основное преимущество OpenStack – гибкость за счет открытого кода ПО. Множество облачных провайдеров используют этот комплекс в качестве основы для своих продуктов, однако конкретные предложения во многом кардинально отличаются. При необходимости, провайдер может изменять модули, чтобы ответить на конкретные запросы пользователей. Это невозможно в случае с, например, проприетарным ПО VMware vCloud. Пример такой модификации – сервис SIM-Cloud Dashboard на основе компонента Horizon. Если хотите ознакомиться с примером интерфейса в облаке OpenStack, читайте новость об обновлении панели управления публичного облака SIM-Networks.
Модульная структура OpenStack также способствует гибкости применения. Кроме основных компонентов, пользователь может подключать сервисы для других задач – например, для организации резервного копирования, работы с контейнерами, балансировки нагрузки на серверы и т.д. Таким образом, пользователям доступен стек решений для практически любого аспекта работы в облаке. Этим OpenStack отличается от своего аналога, OpenNebula – последнее решение предлагает пользователям интегрированную систему, а не набор модулей.
У этих преимуществ есть обратная сторона – разработчики не предоставляют комплексную техническую поддержку. Каждое облако OpenStack во многом уникально, поэтому решение проблем индивидуальных пользователей занимало бы слишком много времени. К счастью, этот недостаток вряд ли отразится на опыте конечного пользователя услуги IaaS – заказав облако у провайдера, вы получите поддержку специалистов, которые непосредственно разрабатывали решение. Кроме того, документацию каждого сервиса несложно найти на сайте разработчиков платформы.
В целом недостатки платформы OpenStack скорее отражаются на провайдерах облачных услуг, чем на конечных пользователях. Платформа развивается динамично – постоянно появляются новые сервисы, старые утрачивают актуальность, а для основных модулей выходят обновления. Облако на OpenStack необходимо регулярно модернизировать, чтобы использовать актуальные версии каждого элемента. По этой причине качество облачного решения во многом зависит от провайдера, а не от самой платформы. К примеру, облако SIM-Networks проходит модернизацию ежегодно.
Кейсы применения облака на OpenStack
Специалисты SIM-Networks работают с платформой OpenStack с момента выпуска публичного облака SIM-Cloud; мы также строим частные облака на базе этого ПО. За это время мы столкнулись с множеством кейсов применения облаков, которые используют этот программный комплекс. Рассмотрим несколько примеров.
Облако OpenStack для бизнеса с нуля
Задача клиента – перенести сервисы в облачную инфраструктуру на базе инстансов Windows OS. Как правило, клиенты передают администрирование облака провайдеру, однако владелец компании сделал акцент на том, чтобы управление IT-инфраструктурой было сосредоточено в руках штатных специалистов заказчика. В рамках проекта мы провели тренинг для сотрудников клиента и ознакомили их с основами работы на платформе OpenStack.
Наши технические специалисты провели миграцию 19 виртуальных машин клиента. Общий объем данных, которые требовалось перенести – 3 TB быстрого дискового пространства и 8 TB медленного. Между офисом клиента и облачной инфраструктурой была настроена сетевая связь, а также связь между облаком и площадкой devops. Основываясь на знаниях, полученных в ходе тренинга, сотрудники заказчика самостоятельно произвели первичные настройки и приступили к работе в облаке.
Публичное облако для оценки потребности в IT-ресурсах
Заказчик планировал перенести IT-сервисы в частное облако. Такой проект требует крупных вложений и затрат времени, поэтому клиент хотел предварительно оценить реальную потребность в ресурсах будущей IT-инфраструктуры. Мы предложили использовать публичное облако на OpenStack в качестве инструмента для предпроектной оценки – то есть развернуть в нем существующие сервисы клиента и на практике оценить, сколько ресурсов потребуется в частном облаке.
В ходе проекта мы развернули сервисы клиента в облаке и масштабировали ресурсы по мере роста бизнеса. За счет архитектуры решения это происходило быстро – конфигурации инстансов изменяли, как только возникала необходимость. В течение этого периода мы оптимизировали решение под конкретные потребности задач клиента. Когда работа инфраструктуры устроила заказчика, мы провели аудит ресурсов и создали частное облако на основе полученных данных.