Еще раз об архитектуре OpenStack: Версия Essex

Краткий обзор компонентов проекта OpenStack и его истории в целях общего понимания вопроса: проект был основан в 2010 г. при сотрудничестве Rackspace и NASA, было выпущено четыре версии, и скоро, в апреле, выйдет пятая (“Essex” или 2012.1) (вышла 5 апреля – прим. перев.).

Вначале проект состоял из трех “основных” компонентов:

Приближающийся релиз переводит два новых проекта в разряд “основных”:

Два этих новых проекта предоставляют дополнительную инфраструктуру для поддержки трех существующих проектов.

Схематичная архитектура

Проект OpenStack в целом разработан с целью “предоставления широкомасштабной облачной операционной системы”. Для достижения этой цели, каждый из составных сервисов спроектирован для предоставления полной “Инфраструктуры как услуги” (IaaS). Интеграция достигается при помощи программных интерфейсов приложений (API), предоставляемых каждым сервисом (и, в свою очередь, отвечающим на запросы через этот интерфейс). Эти API-интерфейсы позволяют любым сервисам взаимодействовать друг с другом в системе, а также позволяют реализаторам подключить свою реализацию сервиса при условии, что они имплементируют тот же набор методов. По большей части это тот же набор API методов, что доступен конечным пользователям облака.

Схематично взаимоотношения между сервисами можно представить так:

Схематичная архитектура

Это стилизованный и упрощенный вид архитектуры с учетом того, что реализатор использует все сервисы вместе в наиболее распространенной конфигурации. Кроме того, на этой диаграмме изображена только сторона “оператора” – на ней не показано, как пользователи могут все это применять. К примеру, многие пользователи сервиса compute будут широко (и напрямую) использовать хранение объектов.

Логическая архитектура

Как можно было догадаться, логическая архитектура намного более сложная, чем схематичная архитектура, приведенная выше. Как с любой сервис-ориентированной архитектурой, диаграммы очень быстро становятся “нечитабельными” при попытке проиллюстрировать все возможные комбинации взаимодействия сервисов. В диаграмме ниже я привел наиболее, с моей точки зрения, типичную “интегрированную” архитектуру облака на основе OpenStack.

OpenStack End Users

Данная иллюстрация подходит под предыдущее описание, поскольку:

В нижеслудеющих параграфах мы подробно рассмотрим архитектуру каждого сервиса.

Инструментальная панель

Horizon – это модульное Django веб приложение, предоставляющее конечному пользователю интерфейс администратора для управления сервисами OpenStack.

Horizon

Как и в большинстве веб-приложений, архитектура довольно проста:

С точки зрения сетевой инфраструктуры, данный сервис должен быть доступен для клиента, а также иметь возможность связи с открытым API каждого сервиса. Если требуется получить административную функциональность (например, для других сервисов), модулю также необходимо предоставить подключение к конечным узлам с административным API (которые не должны быть доступны для клиентов).

Compute

Не так уж много изменилось в архитектуре Nova. Добавилось несколько новых вспомогательных сервисов для совместимости с EC2 и консольными сервисами.

В последних двух релизах Nova расширила список консольных сервисов. Консольные сервисы позволяют конечным пользователям получить доступ к консолям их инстансов виртуальных машин через прокси. Для этого используется пара новых демон-процессов (nova-console и nova-consoleauth).

Nova может взаимодействовать с привычным набором инструментов: Keystone для аутентификации, Glance для работы с изображениями и Horizon для веб-интерфейса. Взимодействие с Glance происходит весьма любопытно. API процесс может загружать образы на Glance и выполнять запросы, в то время как nova-compute скачивает образы для использования в процессе запуска виртуальных машин.

Хранилище объектов

Архитектура Swift весьма распределенна с целью предотвращения единой точки отказа, а также возможности горизонтального масштабирования. Она включает в себя следующие модули:

Аутентификация обрабатывается при помощи конфигурируемого WSGI межпрограммного обеспечения (обычно используется Keystone).

Хранилище образов

Архитектура Glance не претерпела существенных изменений с момента релиза Cactus. Самым существенным архитектурным изменением явилось добавление аутентификации, которая была добавлена в релизе Diablo. Краткое напоминание – Glance состоит их четырех частей:

Также, на Glance периодически запускается ряд процессов для поддержки кэширования. Наиболее важными из них являются службы репликации, задачей которых является обеспечение корректности и доступности данных в кластере. В число других периодических процессов входят аудиторы, процессы обновления и сборщики мусора.

Как можно увидеть из диаграммы, Glance играет центральную роль в общей картине IaaS. Он принимает запросы на образов (или метаданные образов) через API от конечных пользователей или модулей Nova и может хранить файлы на дисках.

Аутентификация и авторизация

Keystone предоставляет единую точку интеграции правил, каталога, токена, и аутентификации OpenStack.

Большинство людей использует эту функциональность в качестве точки настройки под уже существующий у них сервис аутентификации.

Будущие проекты

На этом обзор архитектуры OpenStack Essex закончен. Однако на этом OpenStack останавливаться не собирается – следующий релиз OpenStack (“Folsom”) будет включать в себя еще один основной сервис:

Хотя дата релиза Folsom еще не определена (вероятно, осень 2012), я не буду ждать шесть месяцев, чтобы обновить диаграмму.

Автор: Ken Pepple

Подписка на RSS канал
« »

Комментарии

Оставить комментарий
или