For at levere IaaS-tjenesten (Virtuelt datacenter) bruger vi en kommerciel orkestrator (FCO). Denne løsning har en temmelig unik arkitektur, hvilket adskiller den fra de bredt kendte Openstack og CloudStack.
Som hypervisorer understøttes KVM, VmWare, Xen, Virtuozzo6/7, samt containere fra samme Virtuozzo. De understøttede lagringssystemer inkluderer – lokal, NFS, Ceph og Virtuozzo Storage.
FCO understøtter oprettelse af flere klynger og styring af dem fra en enkelt interface. Det vil sige, at man kan administrere en Virtuozzo-klynge og en KVM + Ceph-klynge ved at skifte mellem dem med et musetryk.
I sin essens er FCO en omfattende løsning til cloud-udbydere, der udover orkestrering også inkluderer fakturering med alle indstillinger, betalingsplugins, fakturaer, meddelelser, forhandlere, takster osv. Dog kan faktureringsdelen ikke dække alle de russiske nuancer, hvorfor vi har fravalgt at bruge den til fordel for en anden løsning.
Det glæder os, at der er et fleksibelt system til fordeling af rettigheder til alle ressourcer i cloud'en: billeder, diske, produkter, servere, firewalls – alt dette kan "dele" og give rettigheder mellem brugere, og endda mellem brugere fra forskellige kunder. Hver kunde kan oprette flere uafhængige datacentre i deres cloud og administrere dem fra et enkelt kontrolpanel.
Arkitektonisk består FCO af flere dele, hver med sin egen uafhængige kode og nogle også med deres egen database.
Skyline – administrativt og brugerinterface
Jade – forretningslogik, fakturering, opgavehåndtering
Tigerlily – servicekoordinator, der styrer og koordinerer informationsudvekslingen mellem forretningslogikken og klyngerne.
XVPManager – styring af klyngeelementer: noder, lagring, netværk og virtuelle maskiner.
XVPAgent – agent, der installeres på noder for at interagere med XVPManager
Vi planlægger at placere en detaljeret fortælling om arkitekturen af hver komponent i en serie artikler, hvis emnet selvfølgelig vækker interesse.
Hovedfordelen ved FCO kommer fra dets "boksløsning". Du får enkelhed og minimalisme. Der tildeles en virtuel maskine med Ubuntu til kontrolnoden, hvor alle nødvendige pakker installeres. Alle indstillinger gemmes i konfigurationsfiler som 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 rettes oprindeligt i skabelonerne, hvorefter generatoren aktiveres.
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Som det ses, består grænsefladen af widgets, som brugeren har adgang til at styre. Han kan nemt tilføje/fjerne widgets fra siden, og derved danne det dashboard, han ønsker.
På trods af sin lukkethed er FCO en meget tilpasselig system. Den har et enormt antal indstillinger og adgangspunkter til at ændre workflowet:
- Tilpassede plugins understøttes, for eksempel kan du skrive din egen betalingsmetode eller et eget eksternt ressourcer til at give brugeren.
- Tilpassede triggere understøttes ved bestemte hændelser, for eksempel tilføjelse af den første virtuelle maskine til kunden ved oprettelsen.
- Tilpassede widgets understøttes i grænsefladen, for eksempel at integrere videoer fra YouTube direkte i brugerens interface.
Al tilpasning skrives i FDL-sproget, som er baseret på Lua. Hvis du kender Lua, vil der ikke være problemer med FDL.
Her er et eksempel på en af de simpleste triggere, som vi bruger. Denne trigger forhindrer brugere i at dele deres egne billeder med andre kunder. Vi gør dette for at forhindre, at én bruger kan skabe skadelig billeder til 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
Funktionen register vil blive kaldt af FCO-kernen. Den vil returnere navnet på den funktion, der skal kaldes. Parameteren “p” i denne funktion indeholder konteksten for kaldet, og ved det første kald vil den være tom (nil). Dette giver os mulighed for at registrere vores trigger. I triggerType angiver vi, at triggere aktiveres FØR offentliggørelsen og kun gælder for brugerne. Systemadministratorer har selvfølgelig tilladelse til at offentliggøre alt. I triggerOptions detaljerer vi de operationer, som triggeren skal reagere på.
Og vigtigst af alt – return {exitState = “CANCEL”}, som triggeren er designet til. Den vil returnere fejl, når brugeren forsøger at dele sit billede i kontrolpanelet.
I FCO-arkitektur er ethvert objekt (disk, server, billede, netværk, netværksadapter osv.) repræsenteret som en enhed kaldet Resource, som har fælles parametre:
- UUID for ressourcen
- navn på ressourcen
- type af ressource
- UUID for ejer af ressourcen
- status for ressourcen (aktiv, inaktiv)
- metadata for ressourcen
- nøgler for ressourcen
- UUID for produktet, som ressourcen tilhører
- VDC for ressourcen
Dette er meget praktisk, når man arbejder via API, da man arbejder med alle ressourcer efter samme princip. Produkter konfigureres af udbyderen, og de bestilles af kunden. Da vores fakturering er separat, kan kunden frit bestille ethvert produkt fra panelet. Det vil senere blive opgjort i faktureringen. Et produkt kan være – ip-adresse pr. time, ekstra GB disk pr. time eller simpelthen en server.
Man kan mærke bestemte ressourcer med nøgler for at ændre logikken i arbejdet med dem. For eksempel kan vi mærke tre fysiske noder med nøglen Weight og mærke nogle kunder med den samme nøgle, hvilket dermed giver disse noder tilpassede tildelinger til de pågældende kunder. Denne mekanisme bruger vi til VIP-kunder, som ikke bryder sig om naboer ved siden af deres VM. Selve funktionen kan dog anvendes meget bredere.
Licensmodellen indebærer betaling for hvert CPU-kerne i den fysiske node. Antallet af klustertyper påvirker også prisen. Hvis man planlægger at bruge både KVM og VMware sammen, vil licensprisen stige.
FCO er et komplet produkt med en meget rig funktionalitet, så vi planlægger at forberede flere artikler med detaljerede beskrivelser af netværksfunktionen.
Efter at have arbejdet med denne orkestrator i flere år, kan vi bedømme den som meget solid. Desværre er produktet ikke uden mangler:
- vi har været nødt til at optimere databasen, da forespørgsler begyndte at bremse, når mængden af data voksede;
- efter en fejl var recovery-mekanismen ikke aktiv, og vi måtte genstarte maskinerne for uheldige kunder med et eget sæt scripts;
- mekanismen til at opdage, når en node ikke er tilgængelig, er indbygget i koden og kan ikke tilpasses. Det vil sige, at vi ikke kan oprette vores egne politikker for at bestemme, hvornår en node ikke er tilgængelig.
- Logging er ikke altid detaljeret. Nogle gange, når man skal dykke ned til et meget lavt niveau for at forstå et bestemt problem, mangler kildekoden til nogle komponenter for at forstå årsagerne.
TOTAL: Generelt er indtrykkene af produktet positive. Vi er i konstant kontakt med udviklerne af orkestratoren. Drengene er åbne for konstruktivt samarbejde.
På trods af sin enkelhed har FCO bred funktionalitet. I fremtidige artikler planlægger vi at dykke ned i følgende emner:
- Organisation af netværk i FCO
- Sikring af live-recovery og FQP-protokol
- Skrivning af egne plugins og widgets
- Tilslutning af ekstra tjenester, såsom Load Balancer og Acronis
- Backup
- En enhedlig mekanisme til konfiguration og opsætning af noder
- Behandling af metadata for virtuelle maskiner
P.S. Skriv i kommentarerne, hvis der er andre aspekter, I er interesserede i. Hold øje med os!
Kilde: habr.com
