OpenStack рівня підприємства і база даних як послуга (DBaaS)

Автор: Джон Деверо (John Devereaux)

По мірі розвитку OpenStack та надання співтовариством нових функціональних можливостей за запитом приватних і корпоративних клієнтів є один важливий сервіс, який повинен виграти від інфраструктури і послуги (IaaS) під управлінням OpenStack, — це база даних як послуга (dBaaS). На розробку dBaaS спрямовані зусилля учасників проекту OpenStack під назвою Скарб. Більшість розмов, що стосуються Скарб, обертаються навколо бази даних MySQL з відкритим вихідним кодом, але під управлінням Скарб можуть працювати й інші бази даних рівня підприємства, наприклад Oracle dB 12c, яка фактично надає необхідні підприємству функціональні можливості, підтримку яких повинен забезпечити Скарб, у тому числі мультиарендность (multi-tenancy).

image

База даних як послуга (DBaaS)

База даних (БД) є одним з найбільш критичних сервісів для підприємства. Її функція — зберігати дані, робити можливим пошук, аналіз і витяг даних для додатків. Клієнтам необхідна можливість масштабування як реляційних, так і нереляційних хмарних СУБД. Основне завдання проекту Скарб — надати користувачам OpenStack можливість легко і оперативно керувати БД, минаючи складності, пов'язані з адмініструванням на самій БД.

На даний момент модель Скарб виглядає приблизно так:

image

Як би те ні було, іншою важливою метою проекту Скарб є виділення ресурсів і автоматизація складних операцій, які, як правило, виконуються інженером по супроводу/адміністратором БД. До них належать: розгортання БД, застосування виправлень на БД, резервне копіювання даних і відновлення БД, моніторинг роботи БД та налаштування нової БД.

Скарб сьогодні

На сьогоднішній день процес створення екземпляра БД на основі поточної збірки Скарб виглядає приблизно наступним чином:

image

Це відповідає описаним нижче кроків:

Крок 1: Відправляється запит на створення віртуальної БД.
Крок 2: Виконується запит на аутентифікацію через Keystone.
Крок 3: Надається примірник Скарб (що також призводить до створення нової VM, на якій буде працювати БД).
Крок 4: Скарб повертає відповідь, який включає опис примірника, в тому числі:

a.ID примірника

b.Тип або версія сховища даних

с.Размер тома

d.IP-адреса примірника

е.Другие запитувані або необхідні змінні

На даний момент обмеженням DBaaS платформи OpenStack є те, що Скарб поки що тільки підтримує роботу примірників з одним орендарем. Однією з нових функціональних можливостей Oracle dB 12c є мультиарендность, яка є критичною функціональністю, в даний час впроваджується у таких клієнтів, як Thomson Reuters та інших компаній, працюючих у сфері фінансів. Беручи до уваги зростання інтересу до OpenStack з їх боку, включення реалізації даної функціональної можливості в план розвитку є критичним для залучення клієнтів у фінансовому секторі.

Мультиарендность і Скарб


Мультиарендная архітектура дозволяє одному примірнику програмного забезпечення (ПО) надавати сервіси кільком клієнтам. Кожен такий клієнт називається орендарем. Орендарі можуть мати можливість кастомизировать деякі компоненти програми, наприклад колір користувальницького інтерфейсу, але у них немає можливості кастомізації коду програми.

Мультиарендная архітектура може бути економічною, оскільки в цьому випадку витрати по розробці і супроводу ЗА розділяються між орендарями. Їй можна протиставити архітектуру з одним орендарем (single-tenancy), при якій у кожного клієнта є свій власний екземпляр, а також може бути доступ до коду. При мультиарендной архітектурі провайдеру потрібно робити оновлення тільки раз. При архітектурі з одним орендарем для застосування оновлень провайдера необхідно охопити кілька примірників.

Актуальне на сьогоднішній день план Oracle по відношенню до OpenStack Скарб:

1. Кожен орендар отримує виділений примірник БД
а.на основі попередньо настроєний образу VM;

b.арендатор працює на обчислювальному вузлі/вузлах і на вузлі/вузлах для зберігання даних.

2. Клієнт має можливість повного контролю над сервісами.
3. Повинна бути забезпечена підтримка будь-якого додатка БД, будь-якої мови запитів до БД і методів підключення.
4. Oracle вперше змінить свою модель ліцензування кожного CPU/ядра і озвучить ціни на щомісячну передплату.
Для реалізації даних змін Скарб потрібно трохи модифікувати архітектуру:

image

У даному разі потік завдань виглядає наступним чином:
1.Пользователь надсилає запит до БД (в нашому випадку це портативна БД (PDB).

2.Keystone отримує запит на авторизацію.

3.Предоставляется контейнер БД (DC):
а.Гостевой агент просить Oracle створити PDB.

b.Oracle створює PDB.

c.Oracle відправляє відповідь гостьовому агенту з атрибутами з'єднання.

4.Ответ, що містить облікові дані сполуки, повертається користувачу.

Щоб це працювало, проектом Скарб потрібні наступні компоненти:
a.API-сервер (Server API) -отримує запити і звертається безпосередньо до гостьовим агентам для вирішення оперативних завдань, таких як отримання списку користувачів БД, але звертається до диспетчера завдань для вирішення складних періодичних завдань.

b.Шина передачі повідомлень (Message Bus) — брокер черги повідомлень (Messaging Queue Broker), що виконує маршрутизацію повідомлень між точками API, такими як диспетчер завдань та гостьовий агент, за допомогою HTTP запитів.

с.Диспетчер завдань (Task Manager) — це «робоча конячка» системи, що відповідає за провіжінінг примірників, контроль життєвого циклу кожного екземпляра і виконання операцій на кожному примірнику. Він взаємодіє з API-сервером, отримуючи повідомлення і відповідаючи на них. Пам'ятайте про те, що і диспетчеру завдань, і API-сервера потрібно виклик функцій HTTP для доступу до сервісів OpenStack.

d.Гостевой агент (Guest Agent) — сервіс, що працює на гостьовому примірнику, на якому запущена БД, та здійснює управління і виконання операцій в сховище даних. Він забезпечує роботу сховища даних в режимі онлайн і передає heartbeat-сигнал на API через сервіс Conductor.

е.Проводник (Conductor) — гостьовий сервіс, який працює на хості, який відповідає за прийом повідомлень від гостьових примірників для оновлення інформації на хості. При виконанні резервного копіювання БД, провідник виконує необхідні дії з використанням RPC-повідомлень, переданих через шину повідомлень, наступним чином:

1.trove-conductor є точкою входу

2.RpcService, конфігурований в /etc/trove/trove-conductor.conf, задає диспетчера провідника (conductor manager)

3.Запросы потрапляють в чергу повідомлень.

4.Heartbeat оновлює статус усіх примірників. Є три основні варіанти: NEW (НОВИЙ), BUILDING (СТВОРЮЄТЬСЯ) і ACTIVE (АКТИВНИЙ). Можна додати й інші статуси.

Однак Скарб поки не зовсім готовий до такої новій структурі.

У перспективі


План розвитку спільноти для релізу Icehouse включає наступні пункти:
•Генералізація ядра для удосконалення можливості розширення.

•Підтримка версійності БД з декількома ядрами.

•Підтримка провижининга і управління кластерами.

•Розширюваність для формування повних архітектур (з використанням компонентів Conductor і Scheduler).

•Підтримка функціональних можливостей на зразок «parameters-group» сервісу реляційних баз даних Amazon.

•Автоматизація та виконання завдань за розкладом.

•Підтримка Designate / Ceilometer.

•Автоматизація обробки відмов.

•Охоплення тестів Tempest.

На сьогодні в цьому списку відсутня, хоча повинна бути мультиарендность. При використанні таких сервісів, як Murano (він дозволяє користувачам вибирати, який сервіс БД необхідно розгорнути з відповідними налаштуваннями різновиди), можливість визначення кількості ресурсів, що потрібно виділити для даного орендаря, є привабливою для корпоративних клієнтів, охочих по максимуму використовувати інструмент оркестровки для об'єднання процесів управління і експлуатації компонентів свого обладнання та ПЗ. Murano, наприклад, посилює контроль прав доступу за допомогою сервісу Keystone, який гарантує доступ тільки визначеним користувачам і дозволяє Скарб взаємодіяти з гостьовими агентами, що робить можливим оперативне створення БД.
Всі ці функціональні можливості є привабливими для користувачів рівня підприємства, і для багатьох цього достатньо. Але для тих клієнтів, кому потрібен додатковий рівень корпоративних функціональних можливостей, план розвитку Скарб повинен передбачати рух в даному напрямку.

Оригінал статті на англійській мові.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.