За предоставяне на услугата IaaS (Виртуален дата център) ние в използваме търговски оркестратор (FCO). Това решение има достатъчно уникална архитектура, което го отличава от познатите на широката публика OpenStack и CloudStack.
Като хипервизори за compute нодове се поддържат KVM, VmWare, Xen, Virtuozzo6/7, както и контейнери от същия Virtuozzo. Поддържаните хранилища включват локално, NFS, Ceph и Virtuozzo Storage.
FCO поддържа създаването на множество клъстери и управлението им от един интерфейс. Тоест можете да управлявате клъстер Virtuozzo и клъстер KVM + Ceph, превключвайки между тях с клик на мишката.
По същество FCO е комплексно решение за облачни доставчици, което, освен оркестрация, включва и billing, с всички настройки, платежни модули, фактури, известия, реселъри, тарифи и така нататък. Въпреки това, billing частта не може да покрие всички руски нюанси, затова ние се отказахме от нейното използване в полза на друго решение.
Много ни радва гъвкавата система за разпределение на права за всички ресурси на облака: образи, дискове, продукти, сървъри, защитни стени – всичко това може да се 'дели' и да се предоставят права между потребители, дори между потребители на различни клиенти. Всеки клиент може да създаде в своя облак няколко независими дата центрове и да ги управлява от единна контролна панела.
Архитектурно, FCO се състои от няколко части, всяка от които има свой независим код, а някои и собствена база данни.
Skyline – администраторски и потребителски интерфейс
Jade – бизнес логика, билинг, управление на задачите
Tigerlily – координатор на услугата, управлява и координира обмена на информация между бизнес логиката и клъстерите.
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 и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Както виждате, интерфейсът е изграден от уиджети, чиято употреба е достъпна за потребителя. Той може лесно да добавя/отстранява уиджети от страницата, като така формира желаното от него табло.
Въпреки своята затвореност, FCO е много персонализирана система. Тя предлага огромно количество настройки и точки за достъп за изменение на работния поток:
- Поддържат се персонализирани приставки, например можете да напишете свой метод за таксуване или собствен външен ресурс за предоставяне на услуги на потребителя
- Поддържат се персонализирани тригери за определени събития, например добавяне на първата виртуална машина на клиента при неговото създаване
- Поддържат се персонализирани уиджети в интерфейса, например вграждане на видео от 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, когато работата с всички ресурси се извършва по един и същи принцип. Продуктите се настройват от доставчика, а клиентът ги поръчва. Тъй като нашето billing е отделно, клиентът може свободно и безплатно да поръчва всеки продукт от панела. Сметката ще бъде направена по-късно в billing-a. Продуктите могат да бъдат – IP адрес на час, допълнителен Гб дисково пространство на час или просто сървър.
Ключовете могат да бъдат използвани за маркиране на определени ресурси с цел промяна в логиката на работа с тях. Например, можем да маркираме три физически ноди с ключа Weight и да маркираме някои клиенти с този същия ключ, като по този начин персонализираме тези ноди за тези клиенти. Тази механика я използваме за VIP клиенти, които не обичат съседи до своите VM. Самата функционалност може да се прилага и в много по-широки контексти.
Моделът на лицензиране предвижда плащане за всяко ядро на процесора на физическата нода. Освен това, цената се влияе от количеството типове клъстери. Ако се предвижда да се използват заедно, например, KVM и VMware, цената на лицензията ще се увеличи.
FCO е напълно функционален продукт с много богати функции, затова планираме да подготвим няколко статии с подробно описание на работата на мрежовата част.
След продължителна работа с този оркестратор можем да го определим като много полезен. За съжаление, продуктът има недостатъци:
- бяхме принудени да оптимизираме БД, тъй като заявките започнаха да се забавят при увеличаване на количеството данни в тях;
- след един инцидент поради бъг механизмът за възстановяване не сработи и се наложи да възстановим машините на засегнатите клиенти с наш набор от скриптове;
- механизмът за откриване на недостъпност на нода е вграден в кода и не подлежи на персонализиране. Тоест не можем да създаваме собствени политики за определяне на недостъпност на нода.
- Логването не винаги е подробно. Понякога, когато е необходимо да се потопим на много дълбоко ниво, за да разберем конкретен проблем, липсва изходният код на определени компоненти за разбиране на причините;
ИТОГО: По принцип впечатленията от продукта са положителни. Винаги сме в контакт с разработчиците на оркестратора. Момчетата са отворени за конструктивно сътрудничество.
Въпреки своята простота, FCO разполага с широка функционалност. В бъдещи статии планираме да се задълбочим в следните теми:
- организация на мрежата в FCO
- осигуряване на live-recovery и протокол FQP
- писане на собствени плъгини и джаджи
- подключване на допълнителни услуги, като Load Balancer и Acronis
- бекъп
- унифициран механизъм за конфигуриране и настройка на възли
- обработка на метаданни на виртуални машини
P.S. Пишете в коментарите, ако Ви интересуват и други аспекти. Останете с нас!
Източник: habr.com
