Voor het aanbieden van IaaS (Virtueel datacenter) gebruiken we een commerciële orchestrator (FCO). Deze oplossing heeft een vrij unieke architectuur die het onderscheidt van de meer bekende Openstack en CloudStack.
Als hypervisors voor compute-nodes worden KVM, VmWare, Xen, Virtuozzo6/7 ondersteund, evenals containers van hetzelfde Virtuozzo. Onder de ondersteunde opslag zijn lokaal, NFS, Ceph en Virtuozzo Storage.
FCO ondersteunt het creëren van meerdere clusters en het beheren ervan vanuit één interface. Dit betekent dat je tussen een Virtuozzo-cluster en een KVM + Ceph-cluster kunt schakelen met een muisklik.
In wezen is FCO een geïntegreerde oplossing voor cloudproviders die naast orchestration ook billing bevat, met alle instellingen, betalingsplugins, facturen, meldingen, resellers, tarieven, enzovoort. De billingsectie kan echter niet alle Russische nuance dekken, daarom hebben we ervoor gekozen deze niet te gebruiken ten gunste van een andere oplossing.
Het is fijn dat er een flexibel systeem is voor het toekennen van rechten op alle cloudresources: images, schijven, producten, servers, firewalls - al deze kunnen worden gedeeld en rechten kunnen worden toegewezen tussen gebruikers, zelfs tussen gebruikers van verschillende klanten. Iedere klant kan in zijn eigen cloud meerdere onafhankelijke datacenters creëren en deze beheren vanuit één controlepaneel.
Architectonisch bestaat FCO uit verschillende delen, elk met zijn eigen onafhankelijke code, en sommige zelfs met hun eigen database.
Skyline – de admin- en gebruikersinterface
Jade – bedrijfslogica, billing, taakbeheer
Tigerlily – servicecoördinator, beheert en coördineert de uitwisseling van informatie tussen de bedrijfslogica en de clusters.
XVPManager – het beheer van clustercomponenten: nodes, opslag, netwerk en virtuele machines.
XVPAgent – agent die op nodes wordt geïnstalleerd voor interactie met XVPManager
We zijn van plan een gedetailleerd verhaal over de architectuur van elk component in een serie artikelen te plaatsen, als het onderwerp natuurlijk interesse wekt.
De belangrijkste voordelen van FCO komen voort uit zijn 'kant-en-klare' aard. U profiteert van eenvoud en minimalisme. Voor de beheerlaag wordt er één virtuele machine met Ubuntu toegewezen, waarop alle noodzakelijke pakketten worden geïnstalleerd. Alle instellingen worden naar configuratiebestanden verplaatst in de vorm van sleutel-waarde paren:
# 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"
…
De gehele configuratie wordt aanvankelijk in sjablonen aangepast, waarna de generator wordt opgestart.
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Zoals te zien is, bestaat de interface uit widgets, waarvan de bediening toegankelijk is voor de gebruiker. Hij kan eenvoudig widgets aan de pagina toevoegen/verwijderen, waardoor hij zijn gewenste dashboard kan samenstellen.
Ondanks zijn gesloten karakter is FCO een zeer aanpasbaar systeem. Het beschikt over een enorme hoeveelheid instellingen en ingangen voor het wijzigen van de workflow:
- Aangepaste plugins worden ondersteund, bijvoorbeeld u kunt uw eigen factureringsmethode of externe middelen schrijven om aan de gebruiker te bieden.
- Aangepaste triggers voor specifieke gebeurtenissen worden ondersteund, zoals het toevoegen van de eerste virtuele machine aan een klant bij het aanmaken ervan.
- Aangepaste widgets in de interface worden ondersteund, bijvoorbeeld het ingebed integreren van een video van YouTube direct in de gebruikersinterface.
Alle aanpassingen worden geschreven in de FDL-taal, die gebaseerd is op Lua. Als u bekend bent met Lua, zult u geen problemen hebben met FDL.
Hier is een voorbeeld van een van de eenvoudigste triggers die we gebruiken. Deze trigger staat niet toe dat gebruikers hun eigen afbeeldingen met andere klanten delen. We doen dit zodat één gebruiker niet in staat is om een schadelijke afbeelding voor andere gebruikers te maken.
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
De functie register zal door de FCO-kern worden aangeroepen. Deze zal de naam van de functie retourneren die aangeroepen moet worden. De parameter 'p' van deze functie houdt de context van de aanroep vast, en bij de eerste aanroep zal deze leeg (nil) zijn. Dit stelt ons in staat om onze trigger te registreren. In triggerType geven we aan dat de trigger VOOR de publicatie-operatie wordt aangeroepen en alleen op gebruikers van toepassing is. Beheerders van het systeem mogen vanzelfsprekend alles publiceren. In triggerOptions specificeren we de bewerkingen waarvoor de trigger zal worden geactiveerd.
En het belangrijkste – return {exitState = 'CANCEL'}, waarvoor de trigger is ontwikkeld. Het zal mislukken wanneer de gebruiker probeert zijn afbeelding in het controlepaneel te delen.
In de FCO-architectuur wordt elk object (schijf, server, afbeelding, netwerk, netwerkadapter, enz.) weergegeven als een Resource-entiteit, die gemeenschappelijke parameters heeft:
- UUID van de bron
- naam van de bron
- type van de bron
- UUID van de eigenaar van de bron
- status van de bron (actief, inactief)
- metadata van de bron
- sleutels van de bron
- UUID van het product waaraan de bron toebehoort
- VDC van de bron
Dit is zeer handig bij het werken met de API, omdat de interactie met alle bronnen volgens één principe verloopt. Producten worden ingesteld door de provider en worden besteld door de klant. Aangezien onze facturering apart staat, kan de klant gratis elk product uit het paneel bestellen. Het wordt later in de facturering verrekend. Een product kan zijn: een IP-adres per uur, extra GB schijf per uur of gewoon een server.
Met sleutels kunnen bepaalde bronnen worden gemarkeerd om de logica van interactie met hen te wijzigen. Bijvoorbeeld, we kunnen drie fysieke knooppunten markeren met de sleutel Weight en sommige klanten met dezelfde sleutel markeren, waardoor deze knooppunten specifiek aan deze klanten worden toegewezen. Dit mechanisme gebruiken we voor VIP-klanten, die geen buren naast hun VM willen. De functionaliteit kan echter veel breder worden toegepast.
Het licentiemodel houdt in dat er betaald wordt voor elke CPU-core van een fysiek knooppunt. Ook het aantal typen clusters heeft invloed op de prijs. Als bijvoorbeeld KVM en VMware samen worden gebruikt, zal de licentiekosten stijgen.
FCO is een compleet product met een zeer rijk functioneel aanbod, daarom zijn we van plan om direct verschillende artikelen voor te bereiden met een gedetailleerde beschrijving van de werking van het netwerkgedeelte.
Na enkele jaren werken met deze orkestrator kunnen we zeggen dat deze zeer goed is. Helaas is het product niet vrij van gebreken:
- we moesten de database optimaliseren, omdat de aanvragen vertraagd raakten bij een toenemend aantal gegevens;
- na één storing door een bug functioneerde het herstelmechanisme niet en moesten we de machines van ongelukkige klanten weer opstarten met een eigen set scripts;
- het mechanisme voor het detecteren van het onbereikbaarheid van een knooppunt is in de code ingebouwd en is niet aanpasbaar. Dat wil zeggen, we kunnen geen eigen beleidsmaatregelen voor het bepalen van de onbereikbaarheid van een knooppunt creëren.
- Logging is not always detailed. Sometimes, when it’s necessary to dive very deep to analyze a specific issue, the source code of certain components is lacking to understand the reasons.
TOTAAL: Overall, the impressions of the product are good. We are in constant contact with the developers of the orchestrator. The guys are open to constructive collaboration.
Despite its simplicity, FCO has a wide range of functionality. In future articles, we plan to delve into the following topics:
- network organization in FCO
- ensuring live recovery and FQP protocol
- writing custom plugins and widgets
- connecting additional services such as Load Balancer and Acronis
- backup
- unified mechanism for configuring and setting up nodes
- handling virtual machine metadata
P.S. Please write in the comments if you're interested in other aspects. Stay tuned!
Bron: habr.com
