🥇Flexiant Cloud Orchestrator: s čím se to jí

Pro poskytování služby IaaS (Virtuální datové centrum) používáme Rusonyx komerční orchestrátor Flexiant Cloud Orchestrator (FCO). Toto řešení má dostatečně unikátní architekturu, která jej odlišuje od známého Openstack a CloudStack.

Jako hypervizory compute uzlů jsou podporovány KVM, VmWare, Xen, Virtuozzo6/7 a také kontejnery od stejného Virtuozza. Mezi podporovaná úložiště patří lokální, NFS, Ceph a Virtuozzo Storage.

FCO podporuje vytváření několika clusterů a jejich správu z jednoho rozhraní. To znamená, že můžete spravovat cluster Virtuozzo a cluster KVM + Ceph přepínáním mezi nimi jedním kliknutím myši.

V podstatě je FCO komplexním řešením pro cloudové poskytovatele, které vedle orchestrace zahrnuje také billing, se všemi nastaveními, platebními pluginy, fakturami, upozorněními, resellery, tarify a tak dále. Nicméně, část billing není schopna pokrýt všechny ruské zvláštnosti, a proto jsme se rozhodli ji nepoužívat ve prospěch jiného řešení.

Velmi potěšuje flexibilní systém distribuce práv na všechny zdroje cloudu: obrazy, disky, produkty, servery, firewally – to vše lze "sdílet" a rozdělovat práva mezi uživateli, a dokonce i mezi uživateli různých klientů. Každý klient může ve svém cloudu vytvářet několik nezávislých datových center a spravovat je z jednotného ovládacího panelu.

Architektonicky se FCO skládá z několika částí, z nichž každá má svůj nezávislý kód, a některé dokonce i svou vlastní databázi.

Skyline – administrátorské a uživatelské rozhraní
Jade – obchodní logika, billing, správa úloh
Tigerlily – koordinátor služby, spravuje a koordinuje výměnu informací mezi obchodní logikou a clustery.
XVPManager – správa prvků clustru: uzlů, úložiště, sítě a virtuálních strojů.
XVPAgent – agent, instalovaný na uzlech pro interakci s XVPManagerem

Podrobný popis architektury každé komponenty plánujeme zahrnout do cyklu článků, pokud ovšem téma vzbudí zájem.

Hlavní výhodou FCO je jeho "boxovitost". K dispozici máte jednoduchost a minimalismus. Pro řídicí uzel je vyčleněn jeden virtuální stroj na Ubuntu, do kterého se instalují všechny potřebné balíčky. Všechna nastavení jsou vyvedena do konfiguračních souborů ve formátu proměnná-hodnota:

# 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"
…

Celá konfigurace se původně upravuje v šablonách, poté se spustí generátor
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.

Jak je vidět, rozhraní se skládá z widgetů, jejichž ovládání je uživateli dostupné. Může snadno přidávat/odebírat widgety ze stránky, čímž si formuje potřebný dashboard.

Navzdory své uzavřenosti je FCO velmi přizpůsobitelný systém. Má obrovské množství nastavení a vstupních bodů pro změnu workflow:

Podporovány jsou zákaznické pluginy, například můžete napsat svou vlastní platební metodu nebo vlastní externí zdroj pro poskytování uživateli
Podporovány jsou zákaznické spouštěče na určité události, například přidání první virtuální mašiny zákazníkovi při jeho vytvoření
Podporovány jsou zákaznické widgety v rozhraní, například lze integrovat video z YouTube přímo do uživatelského rozhraní.

Veškerá přizpůsobení jsou psána v jazyce FDL, který je založen na Lua. Pokud znáte Lua, s FDL nebudete mít žádné problémy.

Toto je příklad jednoho z nejjednodušších spouštěčů, které používáme. Tento spouštěč nedovoluje uživatelům sdílet jejich vlastní obrazy s ostatními zákazníky. Děláme to proto, aby jeden uživatel nemohl vytvořit škodlivý obraz pro ostatní uživatele.

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

Funkce register bude vyvolána jádrem FCO. Vrátí název funkce, kterou je potřeba volat. Parametr “p” této funkce uchovává kontext volání, a při prvním volání bude prázdný (nil). Což nám umožní zaregistrovat náš spouštěč. V triggerType ukazujeme, že spouštěč je vyvolán PŘED operací publikování, a vztahuje se pouze na uživatele. Správcům systému samozřejmě dovolujeme publikovat vše. V triggerOptions detailujeme operace, pro které bude spouštěč aktivní.

A hlavně – return {exitState = “CANCEL”}, to je to, kvůli čemu byl spouštěč vyvíjen. Vrátí neúspěch, když se uživatel pokusí sdílet svůj obraz v ovládacím panelu.

V architektuře FCO je jakýkoliv objekt (disk, server, obraz, síť, síťový adaptér atd.) reprezentován jako entita Resource, která má společné parametry:

UUID zdroje
název zdroje
typ zdroje
UUID vlastníka zdroje
stav zdroje (aktivní, neaktivní)
metadata zdroje
klíče zdroje
UUID produktu, kterému zdroj náleží
VDC zdroje

To je velmi pohodlné při práci s API, kdy se se všemi zdroji pracuje podle jednoho principu. Produkty jsou nastavovány poskytovatelem a objednává je klient. Protože náš billing je na straně, klient může svobodně a zdarma objednávat jakýkoliv produkt z panelu. Bude to později vyúčtováno v billingu. Produktem může být – IP adresa na hodinu, další GB disku na hodinu nebo prostě server.

Klíče lze použít k označení určitých zdrojů pro změnu logiky práce s nimi. Například můžeme označit tři fyzické uzly klíčem Weight a označit některé klienty tímto stejným klíčem, čímž tyto uzly osobně přidělíme daným klientům. Tento mechanismus používáme pro VIP klienty, kteří nechtějí mít sousedy vedle svých VM. Samotnou funkci lze aplikovat mnohem šířeji.

Model licencování předpokládá platbu za každý procesorový jádro fyzického uzlu. Také na cenu má vliv počet typů clusterů. Pokud se plánuje používat KVM a VMware dohromady, cena licence se zvýší.

FCO je plnohodnotný produkt, jeho funkčnost je velmi bohatá, proto plánujeme připravit hned několik článků s podrobným popisem fungování síťové části.

Po několika letech práce s tímto orchestrátorem můžeme říci, že je velmi kvalitní. Bohužel, produkt není bez nedostatků:

museli jsme optimalizovat databázi, protože dotazy začaly zpomalovat s narůstajícím množstvím dat v nich;
po jedné havárii kvůli chybě mechanismus obnovení nepracoval a museli jsme opětovně spouštět stroje nešťastných klientů vlastním souborem skriptů;
mechanismus detekce nedostupnosti uzlu je zabudován v kódu a nepodléhá přizpůsobení. To znamená, že nemůžeme vytvářet vlastní politiky určování nedostupnosti uzlu.
Logování není vždy podrobné. Někdy, když je potřeba se dostat na opravdu nízkou úroveň pro řešení konkrétního problému, chybí zdrojový kód některých komponent pro pochopení příčin;

CELKEM: Celkově máme dobré dojmy z produktu. Stále jsme v kontaktu s vývojáři orchestrátoru. Kluci jsou otevření konstruktivní spolupráci.

Navzdory své jednoduchosti FCO disponuje širokou funkcionalitou. V budoucích článcích plánujeme proniknout do následujících témat:

organizace sítě v FCO
zajištění live-recovery a protokolu FQP
psaní vlastních pluginů a widgetů
připojení dalších služeb, jako je Load Balancer a Acronis
zálohování
unifikovaný mechanismus konfigurace a nastavení uzlů
zpracování metadat virtuálních strojů

P.S. Pište do komentářů, pokud vás zajímají i další aspekty. Stay tuned!

Zdroj: habr.com