For at levere IaaS (Virtual Data Center) tjenester, vi vi bruger en kommerciel orkestrator (FCO). Denne løsning har en ret unik arkitektur, som adskiller den fra Openstack og CloudStack, kendt af den brede offentlighed.
KVM, VmWare, Xen, Virtuozzo6/7 samt containere fra samme Virtuozzo understøttes som beregningsknudehypervisorer. Understøttede lagermuligheder omfatter lokal, NFS, Ceph og Virtuozzo Storage.
FCO understøtter oprettelse og styring af flere klynger fra en enkelt grænseflade. Det vil sige, at du kan administrere en Virtuozzo-klynge og en KVM + Ceph-klynge ved at skifte mellem dem med et museklik.
I sin kerne er FCO en samlet løsning til cloud-udbydere, som udover orkestrering også omfatter fakturering, med alle indstillinger, betalingsplugins, fakturaer, notifikationer, forhandlere, takster mv. Imidlertid er faktureringsdelen ikke i stand til at dække alle russiske nuancer, så vi opgav brugen af den til fordel for en anden løsning.
Jeg er meget tilfreds med det fleksible system til at distribuere rettigheder til alle cloud-ressourcer: billeder, diske, produkter, servere, firewalls - alt dette kan "deles" og tildeles rettigheder mellem brugere, og endda mellem brugere af forskellige klienter. Hver klient kan oprette flere uafhængige datacentre i deres sky og administrere dem fra et enkelt kontrolpanel.
Arkitektonisk består FCO af flere dele, som hver har sin egen uafhængige kode, og nogle har deres egen database.
Skyline – admin og brugergrænseflade
jade – forretningslogik, fakturering, opgavestyring
Tiger lilje – servicekoordinator, styrer og koordinerer udvekslingen af information mellem forretningslogik og klynger.
XVPManager – styring af klyngeelementer: noder, storage, netværk og virtuelle maskiner.
XVPAgent – en agent installeret på noder for at interagere med XVPManager
Vi planlægger at inkludere en detaljeret historie om hver komponents arkitektur i en række artikler, hvis emnet naturligvis vækker interesse.
Den største fordel ved FCO stammer fra dens "boksede" natur. Enkelhed og minimalisme står til din tjeneste. Til kontrolnoden er der tildelt én virtuel maskine på Ubuntu, hvori alle de nødvendige pakker er installeret. Alle indstillinger placeres i konfigurationsfiler i form af en variabel-værdi:
# 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"
…
Hele konfigurationen redigeres i første omgang i skabeloner, hvorefter generatoren startes
#build-config som vil generere en vars-fil og kommandere tjenesterne til at genlæse konfigurationen. Brugergrænsefladen er fin og kan nemt mærkes.
Som du kan se, består grænsefladen af widgets, der kan styres af brugeren. Han kan nemt tilføje/fjerne widgets fra siden, og derved skabe det dashboard, han har brug for.
På trods af sin lukkede natur er FCO et system, der kan tilpasses meget. Det har et stort antal indstillinger og indgangspunkter til at ændre arbejdsgangen:
- Brugerdefinerede plugins understøttes, for eksempel kan du skrive din egen faktureringsmetode eller din egen eksterne ressource for at give brugeren
- Brugerdefinerede triggere for visse hændelser understøttes, f.eks. tilføjelse af den første virtuelle maskine til en klient, når den oprettes
- Brugerdefinerede widgets i grænsefladen understøttes, for eksempel indlejring af en YouTube-video direkte i brugergrænsefladen.
Al tilpasning er skrevet i FDL, som er baseret på Lua. Hvis du kender Lua, vil der ikke være nogen problemer med FDL.
Her er et eksempel på en af de enkleste triggere, vi bruger. Denne trigger tillader ikke brugere at dele deres egne billeder med andre klienter. Vi gør dette for at forhindre en bruger i at skabe et ondsindet billede for andre brugere.
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
Registerfunktionen kaldes af FCO-kernen. Det vil returnere navnet på den funktion, der skal kaldes. "p" parameteren for denne funktion gemmer opkaldskonteksten, og første gang den kaldes vil den være tom (nul). Hvilket giver os mulighed for at registrere vores trigger. I triggerType angiver vi, at triggeren aktiveres FØR publiceringsoperationen og kun påvirker brugere. Selvfølgelig tillader vi systemadministratorer at offentliggøre alt. I triggerOptions detaljerer vi de operationer, som triggeren udløses for.
Og det vigtigste er at returnere {exitState = “CANCEL”}, hvorfor triggeren blev udviklet. Det vil returnere fejl, når brugeren forsøger at dele sit billede i kontrolpanelet.
I FCO-arkitekturen er ethvert objekt (disk, server, billede, netværk, netværksadapter osv.) repræsenteret som en ressourceentitet, som har fælles parametre:
- Ressource UUID
- ressourcenavn
- ressourcetype
- Ressourceejer UUID
- ressourcestatus (aktiv, inaktiv)
- ressourcemetadata
- ressourcenøgler
- UUID for det produkt, der ejer ressourcen
- ressource VDC
Dette er meget praktisk, når du arbejder med en API, når alle ressourcer arbejdes efter samme princip. Produkter konfigureres af udbyderen og bestilles af kunden. Da vores fakturering er på siden, kan kunden frit bestille ethvert produkt fra panelet. Det vil blive beregnet senere i faktureringen. Produktet kan være en IP-adresse i timen, en ekstra GB disk i timen eller blot en server.
Taster kan bruges til at markere visse ressourcer for at ændre logikken i at arbejde med dem. For eksempel kan vi markere tre fysiske noder med vægtnøglen og markere nogle klienter med den samme nøgle, og derved allokere disse noder personligt til disse klienter. Vi bruger denne mekanisme til VIP-klienter, der ikke kan lide naboer ved siden af deres VM'er. Selve funktionaliteten kan bruges meget bredere.
Licensmodellen involverer betaling for hver processorkerne i en fysisk node. Omkostningerne er også påvirket af antallet af klyngetyper. Hvis du for eksempel planlægger at bruge KVM og VMware sammen, vil prisen på licensen stige.
FCO er et fuldgyldigt produkt, dets funktionalitet er meget rig, så vi planlægger at forberede flere artikler på én gang med en detaljeret beskrivelse af netværksdelens funktion.
Efter at have arbejdet med denne orkestrator i flere år, kan vi markere den som meget velegnet. Desværre er produktet ikke uden fejl:
- vi var nødt til at optimere databasen, fordi forespørgsler begyndte at blive langsommere, efterhånden som mængden af data i dem steg;
- efter en ulykke virkede gendannelsesmekanismen ikke på grund af en fejl, og vi var nødt til at gendanne biler fra uheldige klienter ved hjælp af vores eget sæt scripts;
- Mekanismen til at detektere nodes utilgængelighed er forbundet med koden og kan ikke tilpasses. Det vil sige, at vi ikke kan oprette vores egne politikker til at bestemme utilgængeligheden af en node.
- logning er ikke altid detaljeret. Nogle gange, når du skal ned på et meget lavt niveau for at forstå et bestemt problem, har du ikke nok kildekode til, at nogle komponenter kan forstå hvorfor;
ALT: Generelt er indtrykket af produktet gode. Vi er i konstant kontakt med orkestratorudviklerne. Fyrene er indstillet på et konstruktivt samarbejde.
På trods af sin enkelhed har FCO bred funktionalitet. I fremtidige artikler planlægger vi at dykke dybere ned i følgende emner:
- netværk hos FCO
- leverer live-gendannelse og FQP-protokol
- at skrive dine egne plugins og widgets
- tilslutning af yderligere tjenester såsom Load Balancer og Acronis
- backup
- samlet mekanisme til konfiguration og konfiguration af noder
- behandle virtuel maskine metadata
ZY Skriv i kommentarerne, hvis du er interesseret i andre aspekter. Bliv hængende!
Kilde: www.habr.com