Для надання послуги IaaS (Віртуальний дата-центр) ми використовуємо комерційний оркестратор (FCO). Це рішення має досить унікальну архітектуру, що відрізняє його від відомих широкому загалу Openstack і CloudStack.
Як гіпервізори compute нод підтримуються KVM, VmWare, Xen, Virtuozzo6/7, а також контейнери від того ж Virtuozzo. З підтримуваних сховищ – локальне, NFS, Ceph та Virtuozzo Storage.
FCO підтримує створення кількох кластерів та керування ними з одного інтерфейсу. Тобто, можна керувати кластером Virtuozzo і кластером KVM + Ceph перемикаючись між ними на кліку миші.
По суті своїй FCO – це комплексне рішення для клауд-провайдерів, яке окрім оркестрації включає ще й білінг, з усіма налаштуваннями, платіжними плагінами, рахунками, повідомленнями, реселлерами, тарифами і так далі. Проте білінг частина не здатна покрити всі російські нюанси, тому ми відмовилися від її використання на користь іншого рішення.
Дуже радує гнучка система розподілу прав на всі ресурси хмари: образи, диски, продукти, сервери, файрволи – все це можна «шарити» та видавати права між користувачами, і навіть між користувачами різних клієнтів. Кожен клієнт може створювати у своїй хмарі кілька незалежних дата-центрів та керувати ними з єдиної панелі керування.
Архітектурно, FCO складається з кількох частин, кожна з яких має свій незалежний код, а деякі і свою власну базу даних.
Горизонт – адмінський та інтерфейс користувача
нефрит – бізнес логіка, білінг, управління завданнями
Тигролі – координатор сервісу, управляє та координує обмін інформації між бізнес логікою та кластерами.
XVPManager – керування елементами кластера: нодами, сховищем, мережею та віртуальними машинами.
XVPAgent - Агент, що встановлюється на ноди для взаємодії з XVPManager
Детальну розповідь про архітектуру кожного компонента ми плануємо вмістити в цикл статей, якщо, звичайно, тема викликає інтерес.
Головна перевага FCO випливає з його "коробочості". До ваших послуг простота та мінімалістичність. Для ноди, що управляє, виділяється одна віртуальна машина на Ubuntu, в яку встановлюються всі необхідні пакети. Усі налаштування виносяться в конфігураційні файли у вигляді змінна-значення:
# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…
Вся конфігурація правиться спочатку у шаблонах, потім запускається генератор
#build-config, який сформує файл vars і дасть команду сервісам перечитати конфіг. Інтерфейс користувача приємний і може бути легко забрендований.
Як видно, інтерфейс складається з віджетів, керування якими доступне користувачеві. Він може легко додавати/видаляти віджети зі сторінки, тим самим формуючи необхідний dashboard.
Незважаючи на свою закритість, FCO – кастомізована система. Вона має величезну кількість налаштувань та вхідних точок для зміни workflow:
- Підтримуються кастомні плагіни, наприклад, можна написати свій білінг-метод або власний зовнішній ресурс для надання користувачеві
- Підтримуються кастомні тригери на певні події, наприклад, додавання першої віртуальної машини клієнту при його створенні
- Підтримуються кастомні віджети в інтерфейсі, наприклад, вбудувати відео з youtube прямо в інтерфейс користувача.
Вся кастомізація пишеться мовою FDL, яка заснована Lua. Якщо ви знаєте Lua, з FDL жодних проблем не буде.
Ось приклад одного із найпростіших тригерів, які ми використовуємо. Цей тригер не дозволяє користувачам ділитися своїми образами з іншими клієнтами. Ми робимо це для того, щоб один користувач не зміг сформувати шкідливий образ для інших користувачів.
function register()
return {"pre_user_api_publish"}
end
function pre_user_api_publish(p)
if(p==nil) then
return{
ref = "cancelPublishImage",
name = "Cancel publishing",
description = "Cancel all user’s images publishing",
triggerType = "PRE_USER_API_CALL",
triggerOptions = {"publishResource", "publishImage"},
api = "TRIGGER",
version = 1,
}
end
-- Turn publishing off
return {exitState = "CANCEL"}
end
Функція register буде викликана ядром FCO. Вона поверне назву функції, яку треба буде викликати. Параметр “p” цієї функції зберігає контест виклику, і за першому викликі він порожнім (nil). Що дозволить нам зареєструвати наш тригер. У triggerType ми показуємо, що тригер викликається ДО операції опублікування, і поширюється лише користувачів. Адміністраторам системи, зрозуміло, ми дозволяємо публікувати все. У triggerOptions ми деталізуємо операції, для яких тригер буде спрацьовувати.
І головне - return {exitState = "CANCEL"}, то навіщо тригер і розроблявся. Він поверне неуспіх, коли користувач спробує поділитися в панелі управління.
В архітектурі FCO – будь-який об'єкт (диск, сервер, образ, мережа, мережевий адаптер та ін.) представлені у вигляді сутності Resource, який має загальні параметри:
- UUID ресурсу
- ім'я ресурсу
- тип ресурсу
- UUID власника ресурсу
- статус ресурсу (активний, неактивний)
- метадані ресурсу
- ключі ресурсу
- UUID продукту, якому належить ресурс
- VDC ресурсу
Це дуже зручно під час роботи з API, коли з усіма ресурсами робота ведеться за одним принципом. Продукти налаштовуються провайдером, а замовляє клієнт. Оскільки у нас білінг знаходиться осторонь, клієнт може вільно-безкоштовно замовляти будь-який продукт з панелі. Порахується він пізніше у білінгу. Продуктом може бути ip адреса на годину, додатковий Гб диска на годину або просто сервер.
Ключами можна помітити певні ресурси зміни логіки роботи з ними. Наприклад, ми можемо позначити три фізичні ноди ключем Weight, і помітити деяких клієнтів тим самим ключем, тим самим виділивши ці ноди персонально даним клієнтам. Такий механізм ми використовуємо для VIP-клієнтів, які не люблять сусідів поряд зі своїми VM. Сам же функціонал можна застосовувати значно ширше.
Модель ліцензування передбачає оплату за кожне ядро процесора фізичної ноди. Також на вартість впливає кількість типів кластерів. Якщо планується використовувати разом, наприклад, KVM та VMware, вартість ліцензії зросте.
FCO є повноцінним продуктом, функціонал його дуже багатий, тому ми плануємо підготувати одразу кілька статей із детальним описом функціонування мережної частини.
Пропрацювавши з цим оркестратором кілька років можемо відзначити його як дуже придатний. На жаль, продукт не позбавлений вад:
- нам доводилося оптимізувати БД, оскільки запити починали гальмувати при наростанні кількості даних у них;
- після однієї аварії через баг не відпрацював механізм recovery, і довелося піднімати машини нещасних клієнтів власним набором скриптів;
- механізм детекту недоступності ноди зашитий у код і піддається кастомізації. Тобто, ми не можемо створювати власні політики визначення недоступності ноди.
- логування який завжди докладне. Іноді, коли потрібно спуститись на дуже низький рівень для розбору певної проблеми, не вистачає вихідного коду деяких компонентів для розуміння причин;
РАЗОМ: загалом, враження від продукту добрі. Ми перебуваємо у постійному контакті з розробниками оркестратора. Хлопці схильні до конструктивної співпраці.
Незважаючи на свою простоту FCO, має широку функціональність. У майбутніх статтях ми плануємо заглибитись у наступні теми:
- організації мережі у FCO
- забезпечення live-recovery та протоколу FQP
- написання власних плагінів та віджетів
- підключення додаткових сервісів, таких як Load Balancer та Acronis
- бекап
- уніфікований механізм конфігурування та налаштування нод
- обробка метаданих віртуальних машин
З.И. Пишіть у коментарях, якщо цікаві й інші аспекти. Stay tuned!
Джерело: habr.com