Na poskytovanie služieb IaaS (Virtual Data Center) sme používame komerčný orchestrátor (FCO). Toto riešenie má pomerne jedinečnú architektúru, ktorá ho odlišuje od Openstack a CloudStack, ktoré sú známe širokej verejnosti.
KVM, VmWare, Xen, Virtuozzo6/7, ako aj kontajnery z rovnakého Virtuozzo sú podporované ako hypervízory výpočtových uzlov. Podporované možnosti úložiska zahŕňajú lokálne úložisko, NFS, Ceph a Virtuozzo Storage.
FCO podporuje vytváranie a správu viacerých klastrov z jedného rozhrania. To znamená, že môžete spravovať klaster Virtuozzo a klaster KVM + Ceph prepínaním medzi nimi kliknutím myši.
FCO je vo svojej podstate komplexné riešenie pre poskytovateľov cloudu, ktoré okrem orchestrácie zahŕňa aj fakturáciu so všetkými nastaveniami, platobné pluginy, faktúry, notifikácie, predajcov, tarify atď. Fakturačná časť však nedokáže pokryť všetky ruské nuansy, preto sme od jej používania upustili v prospech iného riešenia.
Som veľmi spokojný s flexibilným systémom distribúcie práv na všetky cloudové zdroje: obrázky, disky, produkty, servery, firewally - to všetko je možné „zdieľať“ a udeľovať práva medzi používateľmi a dokonca aj medzi používateľmi rôznych klientov. Každý klient môže vo svojom cloude vytvoriť niekoľko nezávislých dátových centier a spravovať ich z jedného ovládacieho panela.
Architektonicky sa FCO skladá z niekoľkých častí, z ktorých každá má svoj vlastný nezávislý kód a niektoré majú vlastnú databázu.
Panoráma – admin a užívateľské rozhranie
nefrit – obchodná logika, fakturácia, riadenie úloh
tigerlily – koordinátor služieb, riadi a koordinuje výmenu informácií medzi obchodnou logikou a klastrami.
manažér XVP – správa prvkov klastra: uzly, úložisko, sieť a virtuálne stroje.
XVPAgent – agent nainštalovaný na uzloch na interakciu s XVPManager
Plánujeme zahrnúť podrobný príbeh o architektúre každého komponentu do série článkov, ak, samozrejme, téma vzbudí záujem.
Hlavná výhoda FCO vyplýva z jeho „škatuľkovanej“ povahy. Jednoduchosť a minimalizmus sú k vašim službám. Pre riadiaci uzol je na Ubuntu pridelený jeden virtuálny stroj, do ktorého sú nainštalované všetky potrebné balíčky. Všetky nastavenia sú umiestnené v konfiguračných súboroch vo forme premennej hodnoty:
# 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á konfigurácia sa najprv upraví v šablónach, potom sa spustí generátor
#build-config, ktorý vygeneruje súbor vars a prikáže službám, aby znova prečítali konfiguráciu. Používateľské rozhranie je pekné a dá sa ľahko označiť značkou.
Ako vidíte, rozhranie pozostáva z widgetov, ktoré môže používateľ ovládať. Môže jednoducho pridávať/odstraňovať miniaplikácie zo stránky, čím si vytvorí dashboard, ktorý potrebuje.
Napriek svojej uzavretej povahe je FCO vysoko prispôsobiteľný systém. Má obrovské množstvo nastavení a vstupných bodov na zmenu pracovného postupu:
- Podporované sú vlastné doplnky, napríklad si môžete napísať svoj vlastný spôsob fakturácie alebo vlastný externý zdroj, ktorý poskytnete používateľovi
- Podporované sú vlastné spúšťače pre určité udalosti, napríklad pridanie prvého virtuálneho počítača do klienta pri jeho vytvorení
- Podporované sú vlastné widgety v rozhraní, napríklad vkladanie videa z YouTube priamo do používateľského rozhrania.
Všetky úpravy sú napísané vo FDL, ktoré je založené na Lua. Ak poznáte Lua, s FDL nebudú žiadne problémy.
Tu je príklad jedného z najjednoduchších spúšťačov, ktoré používame. Tento spúšťač neumožňuje používateľom zdieľať svoje vlastné obrázky s inými klientmi. Robíme to preto, aby sme zabránili jednému používateľovi vytvoriť škodlivý obraz pre iných používateľov.
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
Funkciu registra zavolá jadro FCO. Vráti názov funkcie, ktorá sa má volať. Parameter „p“ tejto funkcie ukladá kontext hovoru a pri prvom volaní bude prázdny (nulový). Čo nám umožní zaregistrovať náš spúšťač. V type triggerType označujeme, že spúšťač je vyvolaný PRED operáciou zverejnenia a ovplyvňuje iba používateľov. Samozrejme, umožňujeme správcom systému všetko zverejňovať. V triggerOptions podrobne uvádzame operácie, pre ktoré sa spúšťač spustí.
A hlavná vec je návrat {exitState = “CANCEL”}, preto bol vyvinutý spúšťač. Keď sa používateľ pokúsi zdieľať svoj obrázok v ovládacom paneli, vráti sa chyba.
V architektúre FCO je akýkoľvek objekt (disk, server, obraz, sieť, sieťový adaptér atď.) reprezentovaný ako entita Resource, ktorá má spoločné parametre:
- UUID zdroja
- názov zdroja
- typ zdroja
- UUID vlastníka zdroja
- stav zdroja (aktívny, neaktívny)
- metadáta zdroja
- zdrojové kľúče
- UUID produktu, ktorý vlastní zdroj
- zdroj VDC
To je veľmi výhodné pri práci pomocou API, keď všetky zdroje pracujú podľa rovnakého princípu. Produkty konfiguruje poskytovateľ a objednáva ich klient. Keďže naša fakturácia je na strane, klient si môže ľubovoľne objednať akýkoľvek produkt z panelu. Vypočíta sa neskôr pri vyúčtovaní. Produktom môže byť IP adresa za hodinu, ďalší GB disku za hodinu alebo len server.
Klávesy možno použiť na označenie určitých zdrojov, aby sa zmenila logika práce s nimi. Napríklad môžeme označiť tri fyzické uzly kľúčom Weight a niektorých klientov označiť rovnakým kľúčom, čím tieto uzly pridelíme osobne týmto klientom. Tento mechanizmus používame pre VIP klientov, ktorí nemajú radi susedov vedľa svojich VM. Samotnú funkcionalitu možno využiť oveľa širšie.
Licenčný model zahŕňa platbu za každé jadro procesora fyzického uzla. Náklady sú ovplyvnené aj počtom typov klastrov. Ak plánujete používať napríklad KVM a VMware spolu, cena licencie sa zvýši.
FCO je plnohodnotný produkt, jeho funkcionalita je veľmi bohatá, preto plánujeme pripraviť niekoľko článkov naraz s podrobným popisom fungovania sieťovej časti.
Keďže s týmto orchestrátorom spolupracujeme už niekoľko rokov, môžeme ho označiť za veľmi vhodného. Bohužiaľ, produkt nie je bez chýb:
- museli sme optimalizovať databázu, pretože dopyty sa začali spomaľovať, keď sa v nich zvýšil objem údajov;
- po jednej nehode mechanizmus obnovy nefungoval kvôli chybe a museli sme obnoviť autá nešťastných klientov pomocou našej vlastnej sady skriptov;
- Mechanizmus zisťovania nedostupnosti uzla je pevne začlenený do kódu a nemožno ho prispôsobiť. To znamená, že nemôžeme vytvárať vlastné zásady na určenie nedostupnosti uzla.
- protokolovanie nie je vždy podrobné. Niekedy, keď potrebujete ísť na veľmi nízku úroveň, aby ste pochopili konkrétny problém, nemáte dostatok zdrojového kódu na to, aby niektoré komponenty pochopili prečo;
SPOLU: Vo všeobecnosti sú dojmy z produktu dobré. Sme v neustálom kontakte s vývojármi orchestrátora. Chlapci sú naklonení konštruktívnej spolupráci.
Napriek svojej jednoduchosti má FCO širokú funkčnosť. V budúcich článkoch plánujeme hlbšie preniknúť do nasledujúcich tém:
- vytváranie sietí v FCO
- poskytovanie živej obnovy a protokolu FQP
- písanie vlastných pluginov a widgetov
- pripojenie doplnkových služieb, ako je Load Balancer a Acronis
- zálohovanie
- jednotný mechanizmus na konfiguráciu a konfiguráciu uzlov
- spracovanie metadát virtuálneho stroja
ZY Napíšte do komentárov, ak vás zaujímajú iné aspekty. Zostaňte naladení!
Zdroj: hab.com