Flexiant Cloud Orchestrator: hva er det?

For providing the IaaS (Virtual Data Center) service, we at Rusonyx use a commercial orchestrator Flexiant Cloud Orchestrator (FCO). This solution has a fairly unique architecture that distinguishes it from the widely known Openstack and CloudStack.

As hypervisors for compute nodes, KVM, VmWare, Xen, Virtuozzo6/7, as well as containers from the same Virtuozzo are supported. Supported storage includes local, NFS, Ceph, and Virtuozzo Storage.

FCO supports the creation of multiple clusters and managing them from a single interface. That is, it is possible to manage a Virtuozzo cluster and a KVM + Ceph cluster by switching between them with a mouse click.

Essentially, FCO is a comprehensive solution for cloud providers that, besides orchestration, also includes billing, with all the settings, payment plugins, invoices, notifications, resellers, tariffs, and so on. However, the billing part is not able to cover all the nuances in Russia, so we opted out of using it in favor of another solution.

We are pleased with the flexible system for distributing rights to all cloud resources: images, disks, products, servers, firewalls – all of this can be 'shared' and rights can be issued among users, even between users of different clients. Each client can create several independent data centers in their cloud and manage them from a single control panel.

Architecturally, FCO consists of several parts, each with its own independent code, and some even have their own database.

Skyline – admin and user interface
Jade – business logic, billing, task management
Tigerlily – service coordinator, manages and coordinates the exchange of information between business logic and clusters.
XVPManager – management of cluster elements: nodes, storage, networks, and virtual machines.
XVPAgent – agent installed on nodes to interact with XVPManager

We plan to include a detailed account of the architecture of each component in a series of articles, if, of course, the topic generates interest.

Den største fordelen med FCO kommer fra dens "kasseformat". Du får enkelhet og minimalisme. For styringsnodene allokeres en virtuell maskin på Ubuntu, der alle nødvendige pakker installeres. Alle innstillinger lagres i konfigurasjonsfiler som en variabel-verdi:

# 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 opprinnelig redigert i maler, deretter starter generatoren.
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.

Som du kan se, består grensesnittet av widgets, som brukeren har tilgang til å administrere. Han kan enkelt legge til eller fjerne widgets fra siden, og dermed forme sin ønskede dashboard.

Til tross for sin lukkede natur, er FCO et svært tilpassbart system. Det har et stort antall innstillinger og inngangspunkter for å endre arbeidsflyten:

1. Egne plugins støttes, for eksempel kan du skrive din egen betalingsmetode eller egen ekstern ressurs for å tilby brukeren.
2. Egne triggere støttes for spesifikke hendelser, for eksempel ved å legge til den første virtuelle maskinen til kunden ved opprettelsen.
3. Egnet tilpassede widgets i grensesnittet, for eksempel å integrere videoer fra YouTube direkte i brukergrensesnittet.

All tilpasning skrives på FDL-språket, 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 triggeren forhindrer brukere fra å dele sine egne avbildninger med andre kunder. Vi gjør dette for å hindre at en bruker kan lage skadelige avbilder for andre.

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

Register-funksjonen vil bli kalt av FCO-kjernen. Den vil returnere navnet på funksjonen som må kalles. Parameteren "p" for denne funksjonen lagrer konteksten for anropet, og ved første anrop vil den være tom (nil). Dette lar oss registrere vår trigger. I triggerType viser vi at triggeren kalles FØR publiseringsoperasjonen, og det gjelder kun for brukere. Systemadministratorer får selvsagt lov til å publisere alt. I triggerOptions detaljert vi operasjonene som triggeren skal aktiveres for.

Og viktigst av alt – return {exitState = "CANCEL"}, som triggeren ble utviklet for. Den vil returnere en feil når brukeren prøver å dele sin avbildning i kontrollpanelet.

I FCO-arkitekturen blir ethvert objekt (disk, server, bilde, nettverk, nettverksadapter osv.) representert som en enhet kalt Resource, som har felles parametere:

• UUID for ressursen
• navn på ressursen
• type ressurs
• UUID for eieren av ressursen
• status for ressursen (aktiv, inaktiv)
• metadata for ressursen
• nøklene til ressursen
• UUID for produktet som ressursen tilhører
• VDC for ressursen

Dette er veldig praktisk når man jobber med API, når all interaksjon med ressursene følger det samme prinsippet. Produktene settes opp av leverandøren, mens kunden bestiller dem. Siden vår abonnering er adskilt, kan kunden fritt og kostnadsfritt bestille hvilket som helst produkt fra panelet. Det vil bli regnet ut senere i faktureringen. Et produkt kan være – IP-adresse per time, ekstra GB disk per time eller bare en server.

Nøklene kan brukes til å merke spesifikke ressurser for å endre logikken i hvordan man arbeider med dem. For eksempel kan vi merke tre fysiske noder med nøkkelen Weight, og merke noen kunder med den samme nøkkelen, og dermed tildele disse nodene spesifikt til disse kundene. En slik mekanisme bruker vi for VIP-kunder som ikke liker å ha naboer ved siden av sine VM-er. Den samme funksjonaliteten kan brukes mye mer bredt.

Lisensieringsmodellen innebærer betaling for hver kjern prosessor i den fysiske noden. Antallet typer klynger påvirker også kostnaden. Hvis man planlegger å bruke KVM og VMware sammen, vil prisen for lisenser øke.

FCO er et fullt produkt, og funksjonaliteten er svært rik, derfor planlegger vi å forberede flere artikler med detaljert beskrivelse av nettverksdelen.

Etter å ha jobbet med denne orkestratoren i flere år, kan vi si at den er av meget god kvalitet. Dessverre er ikke produktet uten feil:

• vi har måttet optimalisere databasen, ettersom forespørslene begynte å bremse opp når mengden data i dem økte;
• etter en krasj på grunn av en feil, fungerte ikke gjenopprettingsmekanismen, og vi måtte sette opp maskinene til de uheldige kundene med vårt eget sett av skript;
• mekanismen for å oppdage utilgjengeligheten til en node er innebygd i koden og kan ikke tilpasses. Det vil si at vi ikke kan lage våre egne retningslinjer for å bestemme utilgjengeligheten til en node.
• Logging is not always detailed. Sometimes, when you need to dive down to a very low level to resolve a specific issue, the source code of certain components is lacking to understand the causes;

TOTAL: Overall, the impressions of the product are good. We are in constant contact with the orchestrator developers. 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
• a unified mechanism for configuring and setting up nodes
• processing metadata of virtual machines

P.S. Feel free to comment if you are interested in other aspects. Stay tuned!

Kilde: habr.com