Pentru a oferi serviciul IaaS (Centru de date virtual), folosim un orchestrator comercial (FCO). Această soluție are o arhitectură destul de unică, care o diferențiază de cunoscuții Openstack și CloudStack.
Ca hypervisoare pentru nodurile de calcul, sunt suportate KVM, VmWare, Xen, Virtuozzo6/7, precum și containere de la același Virtuozzo. Dintre stocările suportate – locale, NFS, Ceph și Virtuozzo Storage.
FCO suportă crearea mai multor clustere și gestionarea acestora dintr-o singură interfață. Asta înseamnă că poți gestiona un cluster Virtuozzo și un cluster KVM + Ceph, schimbând între ele cu un click.
De fapt, FCO este o soluție complexă pentru furnizorii de cloud, care pe lângă orchestrare include și billing, cu toate setările, pluginurile de plată, facturile, notificările, revânzătorii, tarifele și așa mai departe. Cu toate acestea, partea de billing nu poate acoperi toate nuanțele din Rusia, așa că am renunțat la utilizarea sa în favoarea unei alte soluții.
Suntem foarte mulțumiți de sistemul flexibil de repartizare a drepturilor pentru toate resursele cloud-ului: imagini, discuri, produse, servere, firewall-uri – toate acestea pot fi „partajate” și drepturile pot fi acordate între utilizatori, chiar și între utilizatorii diferitelor companii. Fiecare client poate crea în cloud-ul său mai multe centre de date independente ș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 chiar propria bază de date.
Skyline – interfața de administrare și utilizator
Jade – logica de afaceri, billing, gestionarea sarcinilor
Tigerlily – coordonatorul serviciului, care gestionează și coordonează schimbul de informații între logica de afaceri și clustere.
XVPManager – gestionarea elementelor cluster-ului: noduri, stocare, rețea și mașini virtuale.
XVPAgent – agentul instalat pe noduri pentru interacțiunea cu XVPManager
Intenționăm să includem o descriere detaliată a arhitecturii fiecărui component în cadrul unei serii de articole, dacă, desigur, subiectul va suscita interes.
Principala avantaj al FCO derivă din faptul că este „cutie”. La dispoziția dumneavoastră se află simplitatea și minimalismul. Pentru nodul de gestionare se rezervă o mașină virtuală pe Ubuntu, pe care sunt instalate toate pachetele necesare. Toate configurațiile sunt extrase în fișierele de configurare sub forma variabilă-valoare:
# 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"
…
Toată configurația este inițial modificată în șabloane, apoi se lansează generatorul
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
După cum se poate observa, interfața constă în widgeturi, ale căror gestionare este disponibilă pentru utilizatori. Aceștia pot adăuga/elimina cu ușurință widgeturi de pe pagină, astfel formând tabloul de bord dorit.
În ciuda închiderii sale, FCO este un sistem foarte personalizabil. Acesta are o cantitate uriașă de setări și puncte de intrare pentru modificarea fluxului de lucru:
- Sunt acceptate pluginuri personalizate, de exemplu, puteți scrie propriul metodă de facturare sau o resursă externă proprie pentru a o oferi utilizatorului
- Sunt acceptate triggeri personalizați pentru anumite evenimente, de exemplu, adăugarea primei mașini virtuale clientului la crearea acestuia
- Sunt acceptate widgeturi personalizate în interfață, de exemplu, integrarea unui videoclip de pe youtube direct în interfața utilizatorului.
Toată personalizarea este scrisă în limbajul FDL, care se bazează pe Lua. Dacă știți Lua, nu veți avea probleme cu FDL.
Iată un exemplu al unuia dintre cele mai simple triggeri pe care îi folosim. Acest trigger nu permite utilizatorilor să împărtășească propriile imagini cu alți clienți. Facem acest lucru pentru a ne asigura că un utilizator nu poate genera o imagine dăunătoare 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 register va fi apelată de nucleul FCO. Aceasta va returna numele funcției care trebuie apelată. Parametrul “p” al acestei funcții stochează contextul apelului, iar la prima invocare va fi gol (nil). Acest lucru ne va permite să ne înregistrăm triggerul. În triggerType arătăm că triggerul este apelat ÎNAINTE de operațiunea de publicare și se aplică doar utilizatorilor. Administratorilor sistemului, evident, le permitem să publice tot. În triggerOptions detaliem operațiile pentru care triggerul va fi activat.
Și cel mai important – returnarea {exitState = “CANCEL”}, motivul pentru care a fost dezvoltat triggerul. Acesta va returna o eroare atunci când utilizatorul va încerca să își împărtășească imaginea în panoul de control.
În arhitectura FCO – orice obiect (disk, server, imagine, rețea, adaptor de rețea etc.) este reprezentat sub forma unei entități Resource, care are parametrii comuni:
- UUID-ul resursei
- numele resursei
- tipul resursei
- UUID-ul proprietarului resursei
- starea resursei (activ, inactiv)
- metadatele resursei
- cheile resursei
- UUID-ul produsului căruia îi aparține resursa
- VDC-ul resursei
Acest lucru este foarte convenabil atunci când lucrăm prin API, deoarece toate resursele sunt gestionate după același principiu. Produsele sunt configurate de furnizor, iar clientul le comandă. Deoarece facturarea noastră este separată, clientul poate comanda liber și gratuit orice produs din panou. Acesta va fi calculat ulterior în sistemul de facturare. Produsul poate fi – o adresă IP pe oră, un GB suplimentar de disk pe oră sau pur și simplu un server.
Cheile pot fi utilizate pentru a marca anumite resurse pentru a schimba logica de lucru cu acestea. De exemplu, putem marca trei noduri fizice cu cheia Weight și putem marca unii clienți cu aceeași cheie, astfel evidențiind aceste noduri pentru clienții respectivi. Acest mecanism este folosit pentru clienții VIP, care nu își doresc vecini lângă VM-urile lor. Funcționalitatea poate fi extinsă și în alte moduri.
Modelul de licențiere prevede plata pentru fiecare nucleu al procesorului nodului fizic. De asemenea, costul este influențat de numărul de tipuri de clustere. Dacă se intenționează utilizarea simultană a, de exemplu, KVM și VMware, atunci costul licenței va crește.
FCO este un produs complet, funcționalitatea sa fiind foarte bogată, de aceea ne propunem să pregătim imediat mai multe articole cu descriere detaliată a funcționării părții de rețea.
După câțiva ani de lucru cu acest orchestrator, putem spune că este foarte competent. Din păcate, produsul nu este lipsit de defecte:
- a trebuit să optimizăm baza de date, deoarece interogările au început să se blocheze pe măsură ce volumul de date creștea;
- după un accident din cauza unui bug, mecanismul de recuperare nu a funcționat și a fost necesar să ridicăm mașinile clienților nefericiți cu un set propriu de scripturi;
- mecanismul de detectare a inaccesibilității nodului este în cod și nu poate fi personalizat. Cu alte cuvinte, nu putem crea propriile politici de determinare a inaccesibilității nodului.
- Jurnalizarea nu este întotdeauna detaliată. Uneori, când trebuie să coborâm la un nivel foarte scăzut pentru a înțelege o problemă specifică, ne lipsește codul sursă al unor componente pentru a înțelege cauzele;
TOTAL: În general, impresiile despre produs sunt bune. Suntem în contact permanent cu dezvoltatorii orchestratorului. Oamenii sunt deschiși la o colaborare constructivă.
În ciuda simplității sale, FCO oferă o funcționalitate largă. În articolele viitoare, ne propunem să ne aprofundăm în următoarele subiecte:
- organizarea rețelei în FCO
- asigurarea live-recovery și a protocolului FQP
- scrierea propriilor pluginuri și widget-uri
- conectarea serviciilor suplimentare, cum ar fi Load Balancer și Acronis
- backup
- mecanism unificat de configurare și setare a nodurilor
- prelucrarea metadatelor mașinilor virtuale
P.S. Scrieți în comentarii dacă sunt interesante și alte aspecte. Rămâneți aproape!
Sursa: habr.com
