For å tilby IaaS-tjenester (Virtual Data Center) må vi vi bruker en kommersiell orkestrator (FCO). Denne løsningen har en ganske unik arkitektur, som skiller den fra Openstack og CloudStack, kjent for allmennheten.
KVM, VmWare, Xen, Virtuozzo6/7, samt beholdere fra samme Virtuozzo støttes som beregningsnodehypervisorer. Støttede lagringsalternativer inkluderer lokal, NFS, Ceph og Virtuozzo Storage.
FCO støtter oppretting og administrasjon av flere klynger fra ett enkelt grensesnitt. Det vil si at du kan administrere en Virtuozzo-klynge og en KVM + Ceph-klynge ved å bytte mellom dem med et museklikk.
I kjernen er FCO en helhetlig løsning for skyleverandører, som i tillegg til orkestrering også inkluderer fakturering, med alle innstillinger, betalingsplugins, fakturaer, varsler, forhandlere, tariffer og så videre. Faktureringsdelen er imidlertid ikke i stand til å dekke alle russiske nyanser, så vi forlot bruken til fordel for en annen løsning.
Jeg er veldig fornøyd med det fleksible systemet for å distribuere rettigheter til alle skyressurser: bilder, disker, produkter, servere, brannmurer - alt dette kan "deles" og gis rettigheter mellom brukere, og til og med mellom brukere av forskjellige klienter. Hver klient kan opprette flere uavhengige datasentre i skyen sin og administrere dem fra ett enkelt kontrollpanel.
Arkitektonisk består FCO av flere deler, som hver har sin egen uavhengige kode, og noen har sin egen database.
Skyline – admin og brukergrensesnitt
Jade – forretningslogikk, fakturering, oppgavehåndtering
Tigerlily – tjenestekoordinator, styrer og koordinerer informasjonsutveksling mellom forretningslogikk og klynger.
XVPManager – styring av klyngeelementer: noder, lagring, nettverk og virtuelle maskiner.
XVPAgent – en agent installert på noder for å samhandle med XVPManager
Vi planlegger å inkludere en detaljert historie om arkitekturen til hver komponent i en serie artikler, hvis emnet selvfølgelig vekker interesse.
Den største fordelen med FCO stammer fra dens "boksede" natur. Enkelhet og minimalisme står til tjeneste. For kontrollnoden er en virtuell maskin på Ubuntu tildelt, der alle nødvendige pakker er installert. Alle innstillinger er plassert i konfigurasjonsfiler i form av en variabelverdi:
# 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 konfigurasjonen blir først redigert i maler, deretter startes generatoren
#build-config som vil generere en vars-fil og kommandere tjenestene til å lese konfigurasjonen på nytt. Brukergrensesnittet er fint og kan enkelt merkes.
Som du kan se, består grensesnittet av widgets som kan kontrolleres av brukeren. Han kan enkelt legge til/fjerne widgets fra siden, og dermed lage dashbordet han trenger.
Til tross for sin lukkede natur, er FCO et svært tilpassbart system. Den har et stort antall innstillinger og inngangspunkter for å endre arbeidsflyten:
- Tilpassede plugins støttes, for eksempel kan du skrive din egen faktureringsmetode eller din egen eksterne ressurs for å gi brukeren
- Egendefinerte utløsere for visse hendelser støttes, for eksempel å legge til den første virtuelle maskinen til en klient når den opprettes
- Egendefinerte widgets i grensesnittet støttes, for eksempel ved å bygge inn en YouTube-video direkte i brukergrensesnittet.
All tilpasning er skrevet i FDL, som er basert på Lua. Hvis du kjenner Lua, vil det ikke være noen problemer med FDL.
Her er et eksempel på en av de enkleste triggerne vi bruker. Denne utløseren tillater ikke brukere å dele sine egne bilder med andre klienter. Vi gjør dette for å hindre en bruker i å lage et ondsinnet bilde for andre brukere.
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
Registerfunksjonen kalles opp av FCO-kjernen. Det vil returnere navnet på funksjonen som skal kalles. "p"-parameteren til denne funksjonen lagrer anropskonteksten, og første gang den kalles opp vil den være tom (null). Som vil tillate oss å registrere triggeren vår. I triggerType indikerer vi at triggeren påkalles FØR publiseringsoperasjonen, og kun påvirker brukere. Selvfølgelig lar vi systemadministratorer publisere alt. I triggerOptions beskriver vi operasjonene som utløseren vil utløses for.
Og det viktigste er retur {exitState = “CANCEL”}, som er grunnen til at triggeren ble utviklet. Det vil returnere feil når brukeren prøver å dele bildet sitt i kontrollpanelet.
I FCO-arkitekturen er ethvert objekt (disk, server, bilde, nettverk, nettverksadapter, etc.) representert som en ressursenhet, som har vanlige parametere:
- Ressurs UUID
- ressursnavn
- ressurstype
- Ressurseier UUID
- ressursstatus (aktiv, inaktiv)
- ressursmetadata
- ressursnøkler
- UUID for produktet som eier ressursen
- ressurs VDC
Dette er veldig praktisk når du arbeider med en API, når alle ressurser jobbes etter samme prinsipp. Produktene konfigureres av leverandøren og bestilles av kunden. Siden vår fakturering er på siden, kan kunden fritt bestille ethvert produkt fra panelet. Det vil bli beregnet senere i faktureringen. Produktet kan være en IP-adresse per time, en ekstra GB disk per time, eller bare en server.
Nøkler kan brukes til å merke visse ressurser for å endre logikken i arbeidet med dem. For eksempel kan vi merke tre fysiske noder med vektnøkkelen, og merke noen klienter med samme nøkkel, og dermed allokere disse nodene personlig til disse klientene. Vi bruker denne mekanismen for VIP-klienter som ikke liker naboer ved siden av VM-ene sine. Selve funksjonaliteten kan brukes mye bredere.
Lisensmodellen innebærer å betale for hver prosessorkjerne i en fysisk node. Kostnaden påvirkes også av antall klyngetyper. Hvis du planlegger å bruke KVM og VMware sammen, for eksempel, vil kostnaden for lisensen øke.
FCO er et fullverdig produkt, funksjonaliteten er veldig rik, så vi planlegger å forberede flere artikler samtidig med en detaljert beskrivelse av funksjonen til nettverksdelen.
Etter å ha jobbet med denne orkestratoren i flere år, kan vi markere den som svært egnet. Dessverre, produktet er ikke uten feil:
- vi måtte optimalisere databasen fordi spørringene begynte å avta etter hvert som mengden data i dem økte;
- etter en ulykke fungerte ikke gjenopprettingsmekanismen på grunn av en feil, og vi måtte gjenopprette bilene til uheldige kunder ved å bruke vårt eget sett med skript;
- Mekanismen for å oppdage node utilgjengelighet er koblet inn i koden og kan ikke tilpasses. Det vil si at vi ikke kan lage våre egne retningslinjer for å fastslå utilgjengelighet av en node.
- logging er ikke alltid detaljert. Noen ganger, når du trenger å gå ned til et veldig lavt nivå for å forstå et bestemt problem, har du ikke nok kildekode til at enkelte komponenter kan forstå hvorfor;
TOTAL: Generelt er inntrykkene av produktet gode. Vi er i kontinuerlig kontakt med orkestratorutviklerne. Gutta er innstilt på et konstruktivt samarbeid.
Til tross for sin enkelhet har FCO bred funksjonalitet. I fremtidige artikler planlegger vi å gå dypere inn i følgende emner:
- nettverk i FCO
- gir live-gjenoppretting og FQP-protokoll
- skrive dine egne plugins og widgets
- kobler til tilleggstjenester som Load Balancer og Acronis
- backup
- enhetlig mekanisme for å konfigurere og konfigurere noder
- behandle virtuell maskin metadata
ZY Skriv i kommentarfeltet hvis du er interessert i andre aspekter. Følg med!
Kilde: www.habr.com