Автор: Джон Деверо (John Devereaux)
По мере развития OpenStack и предоставления сообществом новых функциональных возможностей по запросу частных и корпоративных клиентов есть один важный сервис, который должен выиграть от инфраструктуры как услуги (IaaS) под управлением OpenStack, – это база данных как услуга (dBaaS). На разработку dBaaS направлены усилия участников проекта OpenStack под названием Trove. Большинство разговоров, касающихся Trove, вращаются вокруг базы данных MySQL с открытым исходным кодом, но под управлением Trove могут работать и другие базы данных уровня предприятия, например Oracle dB 12c, которая фактически предоставляет необходимые предприятию функциональные возможности, поддержку которых должен обеспечить Trove, в том числе мультиарендность (multi-tenancy).
База данных (БД) является одним из наиболее критичных сервисов для предприятия. Ее функция – хранить данные, делать возможным поиск, анализ и извлечение данных для приложений. Клиентам необходима возможность масштабирования как реляционных, так и нереляционных облачных СУБД. Основная задача проекта Trove – предоставить пользователям OpenStack возможность легко и оперативно управлять БД, минуя сложности, связанные с администрированием на самой БД.
На данный момент модель Trove выглядит примерно так:
Как бы то ни было, другой важной целью проекта Trove является выделение ресурсов и автоматизация сложных операций, которые, как правило, выполняются инженером по сопровождению/администратором БД. К ним относятся: развертывание БД, применение исправлений на БД, резервное копирование данных и восстановление БД, мониторинг работы БД и настройка новой БД.
На сегодняшний день процесс создания экземпляра БД на основе текущей сборки Trove выглядит примерно следующим образом:
Это соответствует описанным ниже шагам:
Шаг 1: Отправляется запрос на создание виртуальной БД.
Шаг 2: Выполняется запрос на аутентификацию через Keystone.
Шаг 3: Предоставляется экземпляр Trove (что также приводит к созданию новой VM, на которой будет работать БД).
Шаг 4: Trove возвращает ответ, который включает описание экземпляра, в том числе:
a.ID экземпляра
b.Тип или версия хранилища данных
c.Размер тома
d.IP-адрес экземпляра
e.Другие запрашиваемые или требуемые переменные
На данный момент ограничением DBaaS платформы OpenStack является то, что Trove пока что поддерживает только работу экземпляров с одним арендатором. Одной из новых функциональных возможностей Oracle dB 12c является мультиарендность, которая является критичной функциональностью, в настоящее время внедряемой у таких клиентов, как Thomson Reuters и других компаний, работающих в сфере финансов. Принимая во внимание рост интереса к OpenStack с их стороны, включение реализации данной функциональной возможности в план развития является критичным для привлечения клиентов в финансовом секторе.
Мультиарендная архитектура позволяет одному экземпляру программного обеспечения (ПО) предоставлять сервисы нескольким клиентам. Каждый такой клиент называется арендатором. Арендаторы могут иметь возможность кастомизировать некоторые компоненты приложения, например цвет пользовательского интерфейса, но у них нет возможности кастомизации кода приложения.
Мультиарендная архитектура может быть экономичной, поскольку в этом случае расходы по разработке и сопровождению ПО разделяются между арендаторами. Ей можно противопоставить архитектуру с одним арендатором (single-tenancy), при которой у каждого клиента имеется свой собственный экземпляр ПО, а также может быть доступ к коду. При мультиарендной архитектуре провайдеру требуется делать обновления только раз. При архитектуре с одним арендатором для применения обновлений провайдеру необходимо охватить несколько экземпляров ПО.
Актуальный на сегодняшний день план Oracle по отношению к OpenStack Trove:
1. Каждый арендатор получает выделенный экземпляр БД
a.на основе предварительно сконфигурированного образа VM;
b.арендатор работает на вычислительном узле/узлах и на узле/узлах для хранения данных.
2. Клиент имеет возможность полного контроля над сервисами.
3. Должна быть обеспечена поддержка любого приложения БД, любого языка запросов к БД и методов подключения.
4. Oracle впервые изменит свою модель лицензирования каждого CPU/ядра и озвучит цены на ежемесячную подписку.
Для реализации данных изменений Trove необходимо немного модифицировать архитектуру:
В данном случае поток заданий выглядит следующим образом:
1.Пользователь отправляет запрос к БД (в нашем случае это портативная БД (PDB).
2.Keystone получает запрос на авторизацию.
3.Предоставляется контейнер БД (DC):
a.Гостевой агент просит Oracle создать PDB.
b.Oracle создает PDB.
c.Oracle отправляет ответ гостевому агенту с атрибутами соединения.
4.Ответ, содержащий учетные данные соединения, возвращается пользователю.
Чтобы это работало, проекту Trove требуются следующие компоненты:
a.API-сервер (API Server) –получает запросы и обращается напрямую к гостевым агентам для решения оперативных задач, таких как получение списка пользователей БД, но обращается к диспетчеру задач для решения сложных периодических задач.
b.Шина передачи сообщений (Message Bus) – брокер очереди сообщений (Messaging Queue Broker), выполняющий маршрутизацию сообщений между точками API, такими как диспетчер задач и гостевой агент, посредством HTTP-запросов.
c.Диспетчер задач (Task Manager) – это «рабочая лошадка» системы, отвечающая за провижининг экземпляров, контроль жизненного цикла каждого экземпляра и выполнение операций на любом экземпляре. Он взаимодействует с API-сервером, получая сообщения и отвечая на них. Помните о том, что и диспетчеру задач, и API-серверу требуется вызов функций HTTP для доступа к сервисам OpenStack.
d.Гостевой агент (Guest Agent) – сервис, работающий на гостевом экземпляре, на котором запущена БД, и осуществляющий управление и выполнение операций в хранилище данных. Он обеспечивает работу хранилища данных в режиме онлайн и передает heartbeat-сигнал на API через сервис Conductor.
e.Проводник (Conductor) – гостевой сервис, работающий на хосте, отвечающий за прием сообщений от гостевых экземпляров для обновления информации на хосте. При выполнении резервного копирования БД, проводник выполняет необходимые действия с использованием RPC-сообщений, переданных через шину сообщений, следующим образом:
1.trove-conductor является точкой входа
2.RpcService, сконфигурированный в /etc/trove/trove-conductor.conf, задает диспетчера проводника (conductor manager)
3.Запросы попадают в очередь сообщений.
4.Heartbeat обновляет статус всех экземпляров. Есть три основных варианта: NEW (НОВЫЙ), BUILDING (СОЗДАЕТСЯ) и ACTIVE (АКТИВНЫЙ). Можно добавить и другие статусы.
Однако Trove пока не совсем готов к такой новой структуре.
План развития сообщества для релиза Icehouse включает следующие пункты:
•Генерализация ядра для усовершенствования возможности расширения.
•Поддержка версионности БД с несколькими ядрами.
•Поддержка провижининга и управления кластерами.
•Расширяемость для формирования полных архитектур (с использованием компонентов Conductor и Scheduler).
•Поддержка функциональных возможностей наподобие “parameters-group” сервиса реляционных баз данных Amazon.
•Автоматизация и запуск задач по расписанию.
•Поддержка Designate / Ceilometer.
•Автоматизация обработки отказов.
•Охват тестов Tempest.
На сегодня в этом списке отсутствует, хотя должна быть мультиарендность. При использовании таких сервисов, как Murano (он позволяет вашим пользователям выбирать, какой сервис БД необходимо развернуть с соответствующими настройками разновидности), возможность определения количества ресурсов, которые требуется выделить для данного арендатора, является привлекательной для корпоративных клиентов, желающих по максимуму использовать инструмент оркестровки для объединения процессов управления и эксплуатации компонентов своего оборудования и ПО. Murano, например, усиливает контроль прав доступа при помощи сервиса Keystone, который гарантирует доступ только заданным пользователям и позволяет Trove взаимодействовать с гостевыми агентами, что делает возможным оперативное создание БД.
Все эти функциональные возможности являются привлекательными для пользователей уровня предприятия, и для многих этого достаточно. Но для тех клиентов, кому нужен дополнительный уровень корпоративных функциональных возможностей, план развития Trove должен предусматривать движение в данном направлении.
Оригинал статьи на английском языке.
По мере развития OpenStack и предоставления сообществом новых функциональных возможностей по запросу частных и корпоративных клиентов есть один важный сервис, который должен выиграть от инфраструктуры как услуги (IaaS) под управлением OpenStack, – это база данных как услуга (dBaaS). На разработку dBaaS направлены усилия участников проекта OpenStack под названием Trove. Большинство разговоров, касающихся Trove, вращаются вокруг базы данных MySQL с открытым исходным кодом, но под управлением Trove могут работать и другие базы данных уровня предприятия, например Oracle dB 12c, которая фактически предоставляет необходимые предприятию функциональные возможности, поддержку которых должен обеспечить Trove, в том числе мультиарендность (multi-tenancy).
База данных как услуга (DBaaS)
База данных (БД) является одним из наиболее критичных сервисов для предприятия. Ее функция – хранить данные, делать возможным поиск, анализ и извлечение данных для приложений. Клиентам необходима возможность масштабирования как реляционных, так и нереляционных облачных СУБД. Основная задача проекта Trove – предоставить пользователям OpenStack возможность легко и оперативно управлять БД, минуя сложности, связанные с администрированием на самой БД.
На данный момент модель Trove выглядит примерно так:
Как бы то ни было, другой важной целью проекта Trove является выделение ресурсов и автоматизация сложных операций, которые, как правило, выполняются инженером по сопровождению/администратором БД. К ним относятся: развертывание БД, применение исправлений на БД, резервное копирование данных и восстановление БД, мониторинг работы БД и настройка новой БД.
Trove сегодня
На сегодняшний день процесс создания экземпляра БД на основе текущей сборки Trove выглядит примерно следующим образом:
Это соответствует описанным ниже шагам:
Шаг 1: Отправляется запрос на создание виртуальной БД.
Шаг 2: Выполняется запрос на аутентификацию через Keystone.
Шаг 3: Предоставляется экземпляр Trove (что также приводит к созданию новой VM, на которой будет работать БД).
Шаг 4: Trove возвращает ответ, который включает описание экземпляра, в том числе:
a.ID экземпляра
b.Тип или версия хранилища данных
c.Размер тома
d.IP-адрес экземпляра
e.Другие запрашиваемые или требуемые переменные
На данный момент ограничением DBaaS платформы OpenStack является то, что Trove пока что поддерживает только работу экземпляров с одним арендатором. Одной из новых функциональных возможностей Oracle dB 12c является мультиарендность, которая является критичной функциональностью, в настоящее время внедряемой у таких клиентов, как Thomson Reuters и других компаний, работающих в сфере финансов. Принимая во внимание рост интереса к OpenStack с их стороны, включение реализации данной функциональной возможности в план развития является критичным для привлечения клиентов в финансовом секторе.
Мультиарендность и Trove
Мультиарендная архитектура позволяет одному экземпляру программного обеспечения (ПО) предоставлять сервисы нескольким клиентам. Каждый такой клиент называется арендатором. Арендаторы могут иметь возможность кастомизировать некоторые компоненты приложения, например цвет пользовательского интерфейса, но у них нет возможности кастомизации кода приложения.
Мультиарендная архитектура может быть экономичной, поскольку в этом случае расходы по разработке и сопровождению ПО разделяются между арендаторами. Ей можно противопоставить архитектуру с одним арендатором (single-tenancy), при которой у каждого клиента имеется свой собственный экземпляр ПО, а также может быть доступ к коду. При мультиарендной архитектуре провайдеру требуется делать обновления только раз. При архитектуре с одним арендатором для применения обновлений провайдеру необходимо охватить несколько экземпляров ПО.
Актуальный на сегодняшний день план Oracle по отношению к OpenStack Trove:
1. Каждый арендатор получает выделенный экземпляр БД
a.на основе предварительно сконфигурированного образа VM;
b.арендатор работает на вычислительном узле/узлах и на узле/узлах для хранения данных.
2. Клиент имеет возможность полного контроля над сервисами.
3. Должна быть обеспечена поддержка любого приложения БД, любого языка запросов к БД и методов подключения.
4. Oracle впервые изменит свою модель лицензирования каждого CPU/ядра и озвучит цены на ежемесячную подписку.
Для реализации данных изменений Trove необходимо немного модифицировать архитектуру:
В данном случае поток заданий выглядит следующим образом:
1.Пользователь отправляет запрос к БД (в нашем случае это портативная БД (PDB).
2.Keystone получает запрос на авторизацию.
3.Предоставляется контейнер БД (DC):
a.Гостевой агент просит Oracle создать PDB.
b.Oracle создает PDB.
c.Oracle отправляет ответ гостевому агенту с атрибутами соединения.
4.Ответ, содержащий учетные данные соединения, возвращается пользователю.
Чтобы это работало, проекту Trove требуются следующие компоненты:
a.API-сервер (API Server) –получает запросы и обращается напрямую к гостевым агентам для решения оперативных задач, таких как получение списка пользователей БД, но обращается к диспетчеру задач для решения сложных периодических задач.
b.Шина передачи сообщений (Message Bus) – брокер очереди сообщений (Messaging Queue Broker), выполняющий маршрутизацию сообщений между точками API, такими как диспетчер задач и гостевой агент, посредством HTTP-запросов.
c.Диспетчер задач (Task Manager) – это «рабочая лошадка» системы, отвечающая за провижининг экземпляров, контроль жизненного цикла каждого экземпляра и выполнение операций на любом экземпляре. Он взаимодействует с API-сервером, получая сообщения и отвечая на них. Помните о том, что и диспетчеру задач, и API-серверу требуется вызов функций HTTP для доступа к сервисам OpenStack.
d.Гостевой агент (Guest Agent) – сервис, работающий на гостевом экземпляре, на котором запущена БД, и осуществляющий управление и выполнение операций в хранилище данных. Он обеспечивает работу хранилища данных в режиме онлайн и передает heartbeat-сигнал на API через сервис Conductor.
e.Проводник (Conductor) – гостевой сервис, работающий на хосте, отвечающий за прием сообщений от гостевых экземпляров для обновления информации на хосте. При выполнении резервного копирования БД, проводник выполняет необходимые действия с использованием RPC-сообщений, переданных через шину сообщений, следующим образом:
1.trove-conductor является точкой входа
2.RpcService, сконфигурированный в /etc/trove/trove-conductor.conf, задает диспетчера проводника (conductor manager)
3.Запросы попадают в очередь сообщений.
4.Heartbeat обновляет статус всех экземпляров. Есть три основных варианта: NEW (НОВЫЙ), BUILDING (СОЗДАЕТСЯ) и ACTIVE (АКТИВНЫЙ). Можно добавить и другие статусы.
Однако Trove пока не совсем готов к такой новой структуре.
В перспективе
План развития сообщества для релиза Icehouse включает следующие пункты:
•Генерализация ядра для усовершенствования возможности расширения.
•Поддержка версионности БД с несколькими ядрами.
•Поддержка провижининга и управления кластерами.
•Расширяемость для формирования полных архитектур (с использованием компонентов Conductor и Scheduler).
•Поддержка функциональных возможностей наподобие “parameters-group” сервиса реляционных баз данных Amazon.
•Автоматизация и запуск задач по расписанию.
•Поддержка Designate / Ceilometer.
•Автоматизация обработки отказов.
•Охват тестов Tempest.
На сегодня в этом списке отсутствует, хотя должна быть мультиарендность. При использовании таких сервисов, как Murano (он позволяет вашим пользователям выбирать, какой сервис БД необходимо развернуть с соответствующими настройками разновидности), возможность определения количества ресурсов, которые требуется выделить для данного арендатора, является привлекательной для корпоративных клиентов, желающих по максимуму использовать инструмент оркестровки для объединения процессов управления и эксплуатации компонентов своего оборудования и ПО. Murano, например, усиливает контроль прав доступа при помощи сервиса Keystone, который гарантирует доступ только заданным пользователям и позволяет Trove взаимодействовать с гостевыми агентами, что делает возможным оперативное создание БД.
Все эти функциональные возможности являются привлекательными для пользователей уровня предприятия, и для многих этого достаточно. Но для тех клиентов, кому нужен дополнительный уровень корпоративных функциональных возможностей, план развития Trove должен предусматривать движение в данном направлении.
Оригинал статьи на английском языке.