Pentru a furniza servicii IaaS (Virtual Data Center), noi folosim un orchestrator comercial (FCO). Această soluție are o arhitectură destul de unică, care o deosebește de Openstack și CloudStack, cunoscute publicului larg.
KVM, VmWare, Xen, Virtuozzo6/7, precum și containerele din același Virtuozzo sunt acceptate ca hipervizoare de noduri de calcul. Opțiunile de stocare acceptate includ stocarea locală, NFS, Ceph și Virtuozzo.
FCO acceptă crearea și gestionarea mai multor clustere dintr-o singură interfață. Adică, puteți gestiona un cluster Virtuozzo și un cluster KVM + Ceph comutând între ele cu un clic de mouse.
La bază, FCO este o soluție cuprinzătoare pentru furnizorii de cloud, care, pe lângă orchestrare, include și facturare, cu toate setările, pluginuri de plată, facturi, notificări, revânzători, tarife și așa mai departe. Cu toate acestea, partea de facturare nu este capabilă să acopere toate nuanțele rusești, așa că am abandonat utilizarea acesteia în favoarea unei alte soluții.
Sunt foarte mulțumit de sistemul flexibil de distribuire a drepturilor pentru toate resursele cloud: imagini, discuri, produse, servere, firewall - toate acestea pot fi „partajate” și pot fi acordate drepturi între utilizatori și chiar între utilizatorii diferiților clienți. Fiecare client poate crea mai multe centre de date independente în cloud și le poate gestiona dintr-un singur panou de control.
Din punct de vedere arhitectural, FCO constă din mai multe părți, fiecare având propriul cod independent, iar unele au propria lor bază de date.
Orizont – interfață de administrare și utilizator
Jad – logica de afaceri, facturare, managementul sarcinilor
Tigerlily – coordonator de servicii, gestionează și coordonează schimbul de informații între logica de afaceri și clustere.
XVPManager – managementul elementelor clusterului: noduri, stocare, rețea și mașini virtuale.
XVPAgent – un agent instalat pe noduri pentru a interacționa cu XVPManager
Ne propunem să includem o poveste detaliată despre arhitectura fiecărei componente într-o serie de articole, dacă, desigur, tema trezește interes.
Principalul avantaj al FCO provine din natura sa „cutie”. Simplitatea și minimalismul vă stau la dispoziție. Pentru nodul de control, este alocată o mașină virtuală pe Ubuntu, în care sunt instalate toate pachetele necesare. Toate setările sunt plasate în fișierele de configurare sub forma unei valori variabile:
# 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"
…
Întreaga configurație este editată inițial în șabloane, apoi este lansat generatorul
#build-config care va genera un fișier vars și va comanda serviciilor să recitească configurația. Interfața cu utilizatorul este plăcută și poate fi ușor de marcat.
După cum puteți vedea, interfața constă din widget-uri care pot fi controlate de utilizator. El poate adăuga/elimina cu ușurință widget-uri din pagină, creând astfel tabloul de bord de care are nevoie.
În ciuda naturii sale închise, FCO este un sistem extrem de personalizabil. Are un număr mare de setări și puncte de intrare pentru schimbarea fluxului de lucru:
- Sunt acceptate pluginuri personalizate, de exemplu, puteți scrie propria metodă de facturare sau propria resursă externă pentru a oferi utilizatorului
- Declanșatoarele personalizate pentru anumite evenimente sunt acceptate, de exemplu, adăugarea primei mașini virtuale la un client atunci când este creată
- Widgeturile personalizate din interfață sunt acceptate, de exemplu, încorporarea unui videoclip YouTube direct în interfața cu utilizatorul.
Toată personalizarea este scrisă în FDL, care se bazează pe Lua. Dacă o cunoști pe Lua, nu vor fi probleme cu FDL.
Iată un exemplu de unul dintre cele mai simple declanșatoare pe care le folosim. Acest declanșator nu permite utilizatorilor să partajeze propriile imagini cu alți clienți. Facem acest lucru pentru a împiedica un utilizator să creeze o imagine rău intenționată pentru alți utilizatori.
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
Funcția de înregistrare va fi apelată de nucleul FCO. Va returna numele funcției care va fi apelată. Parametrul „p” al acestei funcții stochează contextul apelului, iar prima dată când este apelat acesta va fi gol (nul). Ceea ce ne va permite să ne înregistrăm declanșatorul. În triggerType indicăm că declanșatorul este invocat ÎNAINTE de operația de publicare și afectează numai utilizatorii. Desigur, le permitem administratorilor de sistem să publice totul. În triggerOptions detaliem operațiunile pentru care declanșatorul se va declanșa.
Și principalul lucru este returnarea {exitState = „CANCEL”}, motiv pentru care a fost dezvoltat declanșatorul. Va returna eșecul atunci când utilizatorul încearcă să-și partajeze imaginea în panoul de control.
În arhitectura FCO, orice obiect (disc, server, imagine, rețea, adaptor de rețea etc.) este reprezentat ca o entitate Resurse, care are parametri comuni:
- UUID resursă
- numele resursei
- tipul de resursă
- UUID proprietar al resursei
- starea resursei (activ, inactiv)
- metadatele resurselor
- cheile de resurse
- UUID-ul produsului care deține resursa
- resursă VDC
Acest lucru este foarte convenabil atunci când lucrați folosind un API, când toate resursele sunt lucrate conform aceluiași principiu. Produsele sunt configurate de furnizor și comandate de client. Deoarece facturarea noastră este laterală, clientul poate comanda liber orice produs din panou. Acesta va fi calculat ulterior în facturare. Produsul poate fi o adresă IP pe oră, un GB suplimentar de disc pe oră sau doar un server.
Cheile pot fi folosite pentru a marca anumite resurse pentru a schimba logica de lucru cu ele. De exemplu, putem marca trei noduri fizice cu cheia Weight și putem marca unii clienți cu aceeași cheie, alocand astfel aceste noduri personal acestor clienți. Folosim acest mecanism pentru clienții VIP cărora nu le plac vecinii de lângă VM-urile lor. Funcționalitatea în sine poate fi folosită mult mai pe scară largă.
Modelul de licențiere implică plata pentru fiecare nucleu de procesor al unui nod fizic. Costul este, de asemenea, afectat de numărul de tipuri de cluster. Dacă intenționați să utilizați KVM și VMware împreună, de exemplu, costul licenței va crește.
FCO este un produs cu drepturi depline, funcționalitatea sa este foarte bogată, așa că intenționăm să pregătim mai multe articole simultan cu o descriere detaliată a funcționării părții de rețea.
După ce am lucrat cu acest orchestrator de câțiva ani, îl putem marca ca fiind foarte potrivit. Din păcate, produsul nu este lipsit de defecte:
- a trebuit să optimizăm baza de date deoarece interogările au început să încetinească pe măsură ce cantitatea de date din ele creștea;
- după un accident, mecanismul de recuperare nu a funcționat din cauza unui bug și a trebuit să recuperăm mașinile clienților nefericiți folosind propriul nostru set de scripturi;
- Mecanismul de detectare a indisponibilității nodului este conectat în cod și nu poate fi personalizat. Adică, nu ne putem crea propriile politici pentru a determina indisponibilitatea unui nod.
- înregistrarea nu este întotdeauna detaliată. Uneori, când trebuie să coborâți la un nivel foarte scăzut pentru a înțelege o anumită problemă, nu aveți suficient cod sursă pentru ca unele componente să înțeleagă de ce;
TOTAL: În general, impresiile produsului sunt bune. Suntem în contact permanent cu dezvoltatorii orchestratorului. Băieții sunt dispuși la o cooperare constructivă.
În ciuda simplității sale, FCO are o funcționalitate largă. În articolele viitoare intenționăm să aprofundăm următoarele subiecte:
- networking la FCO
- furnizarea de recuperare live și protocol FQP
- scrierea propriilor plugin-uri și widget-uri
- conectarea serviciilor suplimentare, cum ar fi Load Balancer și Acronis
- backup
- mecanism unificat pentru configurarea și configurarea nodurilor
- procesarea metadatelor mașinii virtuale
ZY Scrieți în comentarii dacă sunteți interesat de alte aspecte. Rămâneţi aproape!
Sursa: www.habr.com