Abychom mohli poskytovat služby IaaS (Virtual Data Center), my používáme komerční orchestrátor (FCO). Toto řešení má poměrně unikátní architekturu, která jej odlišuje od Openstack a CloudStack, známých široké veřejnosti.
KVM, VmWare, Xen, Virtuozzo6/7 a také kontejnery ze stejného Virtuozzo jsou podporovány jako hypervizory výpočetních uzlů. Podporované možnosti úložiště zahrnují místní úložiště, NFS, Ceph a Virtuozzo Storage.
FCO podporuje vytváření a správu více clusterů z jednoho rozhraní. To znamená, že můžete spravovat cluster Virtuozzo a cluster KVM + Ceph přepínáním mezi nimi kliknutím myši.
FCO je v jádru komplexní řešení pro cloudové poskytovatele, které kromě orchestrace zahrnuje i fakturaci, se všemi nastaveními, platebními pluginy, fakturami, notifikacemi, prodejci, tarify a tak dále. Fakturační část však není schopna pokrýt všechny ruské nuance, proto jsme od jejího použití upustili ve prospěch jiného řešení.
Jsem velmi spokojen s flexibilním systémem pro distribuci práv ke všem cloudovým zdrojům: image, disky, produkty, servery, firewally – to vše lze „sdílet“ a udě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 vytvořit několik nezávislých datových center a spravovat je z jednoho ovládacího panelu.
Architektonicky se FCO skládá z několika částí, z nichž každá má svůj vlastní nezávislý kód a některé mají vlastní databázi.
Panoráma – admin a uživatelské rozhraní
Nefrit – obchodní logika, fakturace, správa úkolů
Tigerlily – koordinátor služeb, řídí a koordinuje výměnu informací mezi obchodní logikou a klastry.
Správce XVP – správa prvků clusteru: uzlů, úložiště, sítě a virtuálních strojů.
XVPAgent – agent nainstalovaný na uzlech pro interakci s XVPManager
Plánujeme zahrnout podrobný příběh o architektuře každé komponenty do série článků, pokud téma samozřejmě vzbudí zájem.
Hlavní výhoda FCO vyplývá z jeho „krabicové“ povahy. Jednoduchost a minimalismus jsou k vašim službám. Pro řídicí uzel je na Ubuntu přidělen jeden virtuální stroj, do kterého se nainstalují všechny potřebné balíčky. Všechna nastavení jsou umístěna v konfiguračních souborech ve formě 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 nejprve upraví v šablonách, poté se spustí generátor
#build-config, který vygeneruje soubor vars a přikáže službám, aby znovu přečetly konfiguraci. Uživatelské rozhraní je pěkné a lze jej snadno označit.
Jak vidíte, rozhraní se skládá z widgetů, které může uživatel ovládat. Může snadno přidávat/odebírat widgety ze stránky, čímž si vytvoří řídicí panel, který potřebuje.
Navzdory své uzavřené povaze je FCO vysoce přizpůsobitelný systém. Má obrovské množství nastavení a vstupních bodů pro změnu pracovního postupu:
- Vlastní pluginy jsou podporovány, můžete si například napsat vlastní způsob účtování nebo svůj vlastní externí zdroj, který poskytnete uživateli
- Jsou podporovány vlastní spouštěče pro určité události, například přidání prvního virtuálního počítače ke klientovi při jeho vytvoření
- Podporovány jsou vlastní widgety v rozhraní, například vkládání videa z YouTube přímo do uživatelského rozhraní.
Veškeré úpravy jsou napsány ve FDL, které je založeno na Lua. Pokud znáte Lua, nebudou s FDL žádné problémy.
Zde je příklad jednoho z nejjednodušších spouštěčů, které používáme. Tento spouštěč neumožňuje uživatelům sdílet své vlastní obrázky s jinými klienty. Děláme to proto, abychom zabránili jednomu uživateli 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 registru bude volána jádrem FCO. Vrátí název funkce, která má být volána. Parametr „p“ této funkce ukládá kontext volání a při prvním volání bude prázdný (nulový). Což nám umožní zaregistrovat náš spouštěč. V triggerType označujeme, že trigger je vyvolán PŘED operací publikování a ovlivňuje pouze uživatele. Správcům systému samozřejmě umožňujeme vše zveřejnit. V triggerOptions podrobně popisujeme operace, pro které se trigger spustí.
A hlavní věc je návrat {exitState = “CANCEL”}, proto byl vyvinut trigger. Vrátí chybu, když se uživatel pokusí sdílet svůj obrázek v ovládacím panelu.
V architektuře FCO je jakýkoli 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
- zdrojové klíče
- UUID produktu, který vlastní zdroj
- zdroj VDC
To je velmi výhodné při práci pomocí API, kdy všechny zdroje pracují podle stejného principu. Produkty konfiguruje poskytovatel a objednává klient. Vzhledem k tomu, že naše fakturace je na straně, klient si může libovolně objednat jakýkoli produkt z panelu. Vypočítá se později při vyúčtování. Produktem může být IP adresa za hodinu, další GB disku za hodinu nebo jen server.
Pomocí kláves lze označit určité zdroje a změnit tak logiku práce s nimi. Můžeme například označit tři fyzické uzly pomocí klíče Weight a označit některé klienty stejným klíčem, čímž tyto uzly osobně přiřadíme těmto klientům. Tento mechanismus používáme pro VIP klienty, kteří nemají rádi sousedy vedle svých VM. Samotnou funkcionalitu lze využít mnohem šířeji.
Model licencování zahrnuje platbu za každé jádro procesoru fyzického uzlu. Náklady jsou také ovlivněny počtem typů clusterů. Pokud plánujete používat například KVM a VMware společně, cena licence se zvýší.
FCO je plnohodnotný produkt, jeho funkcionalita je velmi bohatá, proto plánujeme připravit více článků najednou s podrobným popisem fungování síťové části.
Vzhledem k tomu, že s tímto orchestrátorem spolupracujeme již několik let, můžeme jej označit za velmi vhodný. Bohužel, produkt není bez chyb:
- museli jsme optimalizovat databázi, protože dotazy se začaly zpomalovat, jak se v nich zvětšovalo množství dat;
- po jedné nehodě mechanismus obnovy nefungoval kvůli chybě a museli jsme obnovit auta nešťastných klientů pomocí naší vlastní sady skriptů;
- Mechanismus zjišťování nedostupnosti uzlu je pevně začleněn do kódu a nelze jej přizpůsobit. To znamená, že nemůžeme vytvářet vlastní zásady pro určování nedostupnosti uzlu.
- protokolování není vždy podrobné. Někdy, když potřebujete klesnout na velmi nízkou úroveň, abyste pochopili konkrétní problém, nemáte dostatek zdrojového kódu, aby některé komponenty pochopily proč;
CELKEM: Obecně jsou dojmy z produktu dobré. Jsme v neustálém kontaktu s vývojáři orchestrátoru. Kluci jsou nakloněni konstruktivní spolupráci.
Navzdory své jednoduchosti má FCO širokou funkčnost. V budoucích článcích se plánujeme ponořit hlouběji do následujících témat:
- vytváření sítí ve společnosti FCO
- poskytování živé obnovy a protokolu FQP
- psaní vlastních pluginů a widgetů
- připojení dalších služeb, jako je Load Balancer a Acronis
- záloha
- jednotný mechanismus pro konfiguraci a konfiguraci uzlů
- zpracování metadat virtuálního stroje
ZY Napište do komentářů, jestli vás zajímají další aspekty. Zůstaňte naladěni!
Zdroj: www.habr.com