För att tillhandahålla IaaS-tjänsten (Virtuellt datacenter) använder vi en kommersiell orkestrator (FCO). Denna lösning har en ganska unik arkitektur som skiljer sig från de välkända Openstack och CloudStack.
Som hypervisorer för compute-noder stöds KVM, VmWare, Xen, Virtuozzo6/7, samt containrar från samma Virtuozzo. De stödda lagringslösningarna inkluderar – lokal, NFS, Ceph och Virtuozzo Storage.
FCO stöder skapandet av flera kluster och hanterar dem från ett enda gränssnitt. Det innebär att man kan hantera ett Virtuozzo-kluster och ett KVM + Ceph-kluster genom att växla mellan dem med ett musklick.
I grunden är FCO en heltäckande lösning för molnleverantörer, som utöver orkestrering även inkluderar fakturering, med alla inställningar, betalnings-pluginer, fakturor, meddelanden, återförsäljare, prissättningar och så vidare. Men faktureringdelen kan inte täcka alla ryska specifika krav, så vi avstod från att använda den till förmån för en annan lösning.
Man blir verkligen glad över det flexibla systemet för resurstilldelning i molnet: bilder, diskar, produkter, servrar, brandväggar – allt detta kan "delas" och ge rättigheter mellan användare, och även mellan användare från olika kunder. Varje kund kan skapa flera oberoende datacenter i sitt moln och hantera dem från ett gemensamt kontrollpanel.
Arkitekturmässigt består FCO av flera komponenter, var och en med sitt eget oberoende kod och vissa även med sin egen databas.
Skyline – admin- och användargränssnitt
Jade – affärslogik, fakturering, uppgiftshantering
Tigerlily – tjänstekoordinator, hanterar och samordnar informationsutbytet mellan affärslogiken och klustren.
XVPManager – hantering av klusterkomponenter: noder, lagring, nätverk och virtuella maskiner.
XVPAgent – agent som installeras på noder för att interagera med XVPManager.
En detaljerad berättelse om arkitekturen för varje komponent planerar vi att få plats med i en serie artiklar, om ämnet förstås väcker intresse.
Den främsta fördelen med FCO kommer från dess "boxighet". Du får enkelhet och minimalism. En virtuell maskin på Ubuntu dedikeras för kontrollnoden, där alla nödvändiga paket installeras. Alla inställningar hanteras i konfigurationsfiler i form av variabel-vä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"
…
All konfigurering görs först i mallar, och sedan startas generatorn
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Som syns består gränssnittet av widgetar, vars hantering är tillgänglig för användaren. Han kan enkelt lägga till/ta bort widgetar från sidan och därmed skapa sin önskade dashboard.
Trots sin slutna natur är FCO ett mycket anpassningsbart system. Det har ett stort antal inställningar och ingångspunkter för att ändra arbetsflödet:
- Anpassade tillägg stöds, till exempel kan du skriva din egen faktureringsmetod eller en egen extern resurs för att tillhandahålla användaren
- Anpassade triggar för specifika händelser stöds, till exempel att lägga till den första virtuella maskinen till en kund vid dess skapelse
- Anpassade widgetar i gränssnittet stöds, till exempel att bädda in video från YouTube direkt i användargränssnittet.
All anpassning skrivs på språket FDL, som är baserat 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 triggarna vi använder. Denna trigger tillåter inte användare att dela sina egna avbilder med andra kunder. Vi gör detta för att en användare inte ska kunna skapa en skadlig avbild 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. Den kommer att returnera namnet på funktionen som ska anropas. Parametern "p" i denna funktion lagrar anropskontexten, och vid första anropet kommer den att vara tom (nil). Detta gör det möjligt för oss att registrera vår trigger. I triggerType visar vi att triggern anropas FÖRE publiceringsoperationen och sprids endast till användare. Administratörer tillåts givetvis att publicera allt. I triggerOptions specificerar vi operationerna för vilka triggern ska aktiveras.
Och viktigast av allt – return {exitState = "CANCEL"}, det som triggern är utvecklad för. Den kommer att återge ett misslyckande när användaren försöker dela sin avbild i kontrollpanelen.
I FCO-arkitekturen representeras varje objekt (disk, server, avbild, nätverk, nätverksadapter osv.) i form av en resursentitet, som har gemensamma parametrar:
- UUID för resursen
- resursnamn
- resurstyp
- UUID för resursens ägare
- resursstatus (aktiv, inaktiv)
- resursmetadata
- resursnycklar
- UUID för produkten som resursen tillhör
- VDC för resursen
Detta är mycket praktiskt när man arbetar med API:er, eftersom all hantering av resurser följer ett och samma mönster. Produkter konfigureras av leverantören, och beställs av kunden. Eftersom vår billing finns externt kan kunden fritt och utan kostnad beställa valfri produkt från panelen. Den kommer senare att räknas i billing. Produkten kan vara – en IP-adress per timme, en extra GB disk per timme eller helt enkelt en server.
Genom nycklar kan specifika resurser märkas för att ändra logiken för hanteringen av dem. Till exempel kan vi märka tre fysiska noder med nyckeln Weight, och också märka vissa kunder med samma nyckel, vilket gör att dessa noder särskiljs för dessa kunder. Denna mekanism används för VIP-kunder som inte vill ha grannar nära sina VM. Själva funktionen kan tillämpas mycket bredare.
Licensieringsmodellen innebär betalning för varje kärna i processorn på den fysiska noden. Antalet klustertyper påverkar också kostnaden. Om man planerar att använda KVM och VMware tillsammans kommer licenskostnaden att öka.
FCO är en fullfjädrad produkt, dess funktionalitet är mycket rik, därför planerar vi att förbereda flera artiklar med detaljerad beskrivning av nätverksdelen.
Efter att ha arbetat med denna orkestrator i flera år kan vi säga att den är mycket kompetent. Tyvärr är produkten inte utan brister:
- vi har tvingats optimera databasen eftersom frågorna började bromsa när mängden data ökade;
- efter en krasch på grund av en bugg fungerade återställningsmekanismen inte, och vi var tvungna att återställa de otursamma kundmaskinerna med vår egen uppsättning skript;
- mekanismen för att upptäcka otillgänglighet av noder är inbyggd i koden och är inte anpassningsbar. Det betyder att vi inte kan skapa våra egna policys för att definiera otillgänglighet av noder.
- Loggning är inte alltid detaljerad. Ibland, när man behöver gå ner på en mycket låg nivå för att analysera ett visst problem, saknas källkoden för vissa komponenter för att förstå orsakerna.
SUMMA: Överlag är intrycken av produkten positiva. Vi är i ständig kontakt med utvecklarna av orkestratorn. Killarna är öppna för konstruktivt samarbete.
Trots sin enkelhet har FCO bred funktionalitet. I kommande artiklar planerar vi att fördjupa oss i följande ämnen:
- nätverksorganisation i FCO
- säkra live-recovery och FQP-protokollet
- skriva egna plugins och widgets
- ansluta ytterligare tjänster, såsom Load Balancer och Acronis
- backup
- enhetlig mekanism för konfiguration och inställning av noder
- bearbetning av metadata för virtuella maskiner
P.S. Skriv i kommentarerna om det finns andra aspekter ni är intresserade av. Stay tuned!
Källa: habr.com
