För att tillhandahålla IaaS-tjänster (Virtual Data Center) har vi vi använder en kommersiell orkestrator (FCO). Denna lösning har en ganska unik arkitektur, som skiljer den från Openstack och CloudStack, kända för allmänheten.
KVM, VmWare, Xen, Virtuozzo6/7, såväl som behållare från samma Virtuozzo stöds som beräkningsnodshypervisorer. Lagringsalternativ som stöds inkluderar lokal, NFS, Ceph och Virtuozzo Storage.
FCO stöder skapandet och hanteringen av flera kluster från ett enda gränssnitt. Det vill säga, du kan hantera ett Virtuozzo-kluster och ett KVM + Ceph-kluster genom att växla mellan dem med ett musklick.
I sin kärna är FCO en heltäckande lösning för molnleverantörer, som förutom orkestrering även inkluderar fakturering, med alla inställningar, betalningsplugins, fakturor, aviseringar, återförsäljare, tariffer och så vidare. Faktureringsdelen är dock inte kapabel att täcka alla ryska nyanser, så vi övergav användningen till förmån för en annan lösning.
Jag är mycket nöjd med det flexibla systemet för att distribuera rättigheter till alla molnresurser: bilder, diskar, produkter, servrar, brandväggar - allt detta kan "delas" och beviljas rättigheter mellan användare, och till och med mellan användare av olika klienter. Varje klient kan skapa flera oberoende datacenter i sitt moln och hantera dem från en enda kontrollpanel.
Arkitektoniskt består FCO av flera delar, som var och en har sin egen oberoende kod, och några har sin egen databas.
Skyline – admin och användargränssnitt
Jade – affärslogik, fakturering, uppgiftshantering
Tigerlilja – tjänstekoordinator, hanterar och koordinerar informationsutbytet mellan affärslogik och kluster.
XVPManager – Hantering av klusterelement: noder, lagring, nätverk och virtuella maskiner.
XVPAgent – en agent installerad på noder för att interagera med XVPManager
Vi planerar att ta med en detaljerad berättelse om varje komponents arkitektur i en serie artiklar, om ämnet förstås väcker intresse.
Den största fördelen med FCO härrör från dess "boxade" natur. Enkelhet och minimalism står till din tjänst. För kontrollnoden tilldelas en virtuell maskin på Ubuntu, i vilken alla nödvändiga paket är installerade. Alla inställningar placeras i konfigurationsfiler i form av ett variabelvärde:
# 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"
…
Hela konfigurationen redigeras initialt i mallar, sedan startas generatorn
#build-config som genererar en vars-fil och beordrar tjänsterna att läsa om konfigurationen. Användargränssnittet är trevligt och kan enkelt märkas.
Som du kan se består gränssnittet av widgets som kan styras av användaren. Han kan enkelt lägga till/ta bort widgets från sidan och därigenom skapa den instrumentpanel han behöver.
Trots sin slutna karaktär är FCO ett mycket anpassningsbart system. Den har ett stort antal inställningar och ingångspunkter för att ändra arbetsflödet:
- Anpassade plugins stöds, till exempel kan du skriva din egen faktureringsmetod eller din egen externa resurs för att ge användaren
- Anpassade utlösare för vissa händelser stöds, till exempel att lägga till den första virtuella maskinen till en klient när den skapas
- Anpassade widgets i gränssnittet stöds, till exempel att bädda in en YouTube-video direkt i användargränssnittet.
All anpassning är skriven i FDL, som är baserad på Lua. Om du känner till Lua kommer det inte att vara några problem med FDL.
Här är ett exempel på en av de enklaste triggers vi använder. Denna utlösare tillåter inte användare att dela sina egna bilder med andra klienter. Vi gör detta för att förhindra en användare från att skapa en skadlig bild för andra användare.
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 kommer att anropas av FCO-kärnan. Det kommer att returnera namnet på den funktion som ska anropas. Parametern "p" för denna funktion lagrar anropskontexten och första gången den anropas kommer den att vara tom (noll). Vilket gör att vi kan registrera vår trigger. I triggerType anger vi att triggern anropas INNAN publiceringsoperationen och endast påverkar användare. Självklart tillåter vi systemadministratörer att publicera allt. I triggerOptions beskriver vi operationerna för vilka triggern kommer att aktiveras.
Och det viktigaste är att returnera {exitState = “CANCEL”}, vilket är anledningen till att triggern utvecklades. Det kommer att returnera fel när användaren försöker dela sin bild i kontrollpanelen.
I FCO-arkitekturen representeras vilket objekt som helst (disk, server, bild, nätverk, nätverkskort, etc.) som en resursentitet, som har gemensamma parametrar:
- Resurs UUID
- resursnamn
- resurstyp
- Resursägarens UUID
- resursstatus (aktiv, inaktiv)
- resursmetadata
- resursnycklar
- UUID för produkten som äger resursen
- resurs VDC
Detta är mycket praktiskt när man arbetar med ett API, när alla resurser arbetas enligt samma princip. Produkterna konfigureras av leverantören och beställs av kunden. Eftersom vår fakturering är vid sidan av kan kunden fritt beställa vilken produkt som helst från panelen. Det kommer att beräknas senare i faktureringen. Produkten kan vara en IP-adress per timme, ytterligare GB disk per timme eller bara en server.
Nycklar kan användas för att markera vissa resurser för att ändra logiken i att arbeta med dem. Till exempel kan vi markera tre fysiska noder med viktnyckeln och markera vissa klienter med samma nyckel, och därigenom allokera dessa noder personligen till dessa klienter. Vi använder den här mekanismen för VIP-klienter som inte gillar grannar bredvid sina virtuella datorer. Funktionaliteten i sig kan användas mycket mer brett.
Licensmodellen innebär att man betalar för varje processorkärna i en fysisk nod. Kostnaden påverkas också av antalet klustertyper. Om du planerar att använda KVM och VMware tillsammans, till exempel, kommer kostnaden för licensen att öka.
FCO är en fullfjädrad produkt, dess funktionalitet är mycket rik, så vi planerar att förbereda flera artiklar på en gång med en detaljerad beskrivning av nätverksdelens funktion.
Efter att ha arbetat med denna orkestrator i flera år kan vi markera den som mycket lämplig. Tyvärr är produkten inte utan brister:
- vi var tvungna att optimera databasen eftersom frågorna började sakta ner när mängden data i dem ökade;
- efter en olycka fungerade inte återställningsmekanismen på grund av en bugg, och vi var tvungna att återställa olyckliga kunders bilar med vår egen uppsättning skript;
- Mekanismen för att upptäcka nods otillgänglighet är inkopplad i koden och kan inte anpassas. Det vill säga, vi kan inte skapa våra egna policyer för att avgöra om en nod inte är tillgänglig.
- loggning är inte alltid detaljerad. Ibland, när du behöver gå ner till en mycket låg nivå för att förstå ett visst problem, har du inte tillräckligt med källkod för att vissa komponenter ska förstå varför;
TOTALT: Generellt sett är intrycken av produkten bra. Vi har ständig kontakt med orkestratorns utvecklare. Killarna är benägna till ett konstruktivt samarbete.
Trots sin enkelhet har FCO bred funktionalitet. I framtida artiklar planerar vi att fördjupa oss i följande ämnen:
- nätverk på FCO
- tillhandahåller live-återställning och FQP-protokoll
- skriva dina egna plugins och widgets
- ansluta ytterligare tjänster som Load Balancer och Acronis
- säkerhetskopiering
- enhetlig mekanism för att konfigurera och konfigurera noder
- bearbeta virtuell maskin metadata
ZY Skriv i kommentarerna om du är intresserad av andra aspekter. Håll ögonen öppna!
Källa: will.com