Flexiant Cloud Orchestrator: wat het oplevert

Flexiant Cloud Orchestrator: wat het oplevert

Om IaaS-diensten (Virtual Data Center) te leveren, hebben wij Rusonyx we maken gebruik van een commerciële orkestrator Flexiant Cloud Orchestrator (FCO). Deze oplossing heeft een vrij unieke architectuur, die hem onderscheidt van de bij het grote publiek bekende Openstack en CloudStack.

KVM, VmWare, Xen, Virtuozzo6/7, evenals containers van dezelfde Virtuozzo worden ondersteund als hypervisors voor rekenknooppunten. Ondersteunde opslagopties zijn onder meer lokale, NFS, Ceph en Virtuozzo-opslag.

FCO ondersteunt de creatie en het beheer van meerdere clusters vanuit één interface. Dat wil zeggen dat u een Virtuozzo-cluster en een KVM + Ceph-cluster kunt beheren door met een muisklik hiertussen te schakelen.

In de kern is FCO een allesomvattende oplossing voor cloudproviders, die naast orkestratie ook de facturering omvat, met alle instellingen, betalingsplug-ins, facturen, meldingen, resellers, tarieven, enzovoort. Het factureringsgedeelte kan echter niet alle Russische nuances dekken, dus hebben we het gebruik ervan opgegeven ten gunste van een andere oplossing.

Ik ben erg blij met het flexibele systeem voor het distribueren van rechten op alle cloudbronnen: afbeeldingen, schijven, producten, servers, firewalls - dit alles kan worden "gedeeld" en rechten worden verleend tussen gebruikers, en zelfs tussen gebruikers van verschillende clients. Elke klant kan meerdere onafhankelijke datacenters in zijn cloud creëren en deze vanuit één enkel controlepaneel beheren.

Flexiant Cloud Orchestrator: wat het oplevert

Architectonisch gezien bestaat FCO uit verschillende delen, die elk hun eigen onafhankelijke code hebben, en sommige hebben hun eigen database.

Horizon – beheerders- en gebruikersinterface
Jade – bedrijfslogica, facturering, taakbeheer
Tijger Lily – servicecoördinator, beheert en coördineert de informatie-uitwisseling tussen bedrijfslogica en clusters.
XVPManager – beheer van clusterelementen: knooppunten, opslag, netwerk en virtuele machines.
XVPAgent – een agent die op knooppunten is geïnstalleerd voor interactie met XVPManager

Flexiant Cloud Orchestrator: wat het oplevert

We zijn van plan een gedetailleerd verhaal over de architectuur van elk onderdeel op te nemen in een reeks artikelen, als het onderwerp uiteraard interesse wekt.

Het belangrijkste voordeel van FCO komt voort uit het “boxed” karakter ervan. Eenvoud en minimalisme staan ​​tot uw dienst. Voor het besturingsknooppunt wordt één virtuele machine op Ubuntu toegewezen, waarin alle benodigde pakketten zijn geïnstalleerd. Alle instellingen worden in configuratiebestanden geplaatst in de vorm van een variabele-waarde:

# 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 in eerste instantie in sjablonen bewerkt, waarna de generator wordt gestart
#build-config die een vars-bestand genereert en de services opdracht geeft de configuratie opnieuw te lezen. De gebruikersinterface is mooi en kan gemakkelijk worden gebrandmerkt.

Flexiant Cloud Orchestrator: wat het oplevert

Zoals je kunt zien bestaat de interface uit widgets die door de gebruiker kunnen worden beheerd. Hij kan eenvoudig widgets toevoegen/verwijderen van de pagina, waardoor hij het dashboard creëert dat hij nodig heeft.

Ondanks het gesloten karakter is FCO een zeer aanpasbaar systeem. Het heeft een groot aantal instellingen en toegangspunten voor het wijzigen van de workflow:

  1. Aangepaste plug-ins worden ondersteund. U kunt bijvoorbeeld uw eigen factureringsmethode of uw eigen externe bron schrijven om de gebruiker te voorzien
  2. Aangepaste triggers voor bepaalde gebeurtenissen worden ondersteund, bijvoorbeeld het toevoegen van de eerste virtuele machine aan een client wanneer deze wordt gemaakt
  3. Aangepaste widgets in de interface worden ondersteund, bijvoorbeeld voor het rechtstreeks insluiten van een YouTube-video in de gebruikersinterface.

Al het maatwerk is geschreven in FDL, gebaseerd op Lua. Als je Lua kent, zullen er geen problemen zijn met FDL.

Hier is een voorbeeld van een van de eenvoudigste triggers die we gebruiken. Met deze trigger kunnen gebruikers hun eigen afbeeldingen niet delen met andere clients. We doen dit om te voorkomen dat één gebruiker een kwaadaardig beeld voor andere gebruikers maakt.

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 registerfunctie wordt aangeroepen door de FCO-kernel. Het retourneert de naam van de functie die moet worden aangeroepen. De parameter “p” van deze functie slaat de oproepcontext op en de eerste keer dat deze wordt aangeroepen, zal deze leeg zijn (nul). Hierdoor kunnen we onze trigger registreren. In triggerType geven we aan dat de trigger wordt aangeroepen VOOR de publicatiebewerking en alleen van invloed is op gebruikers. Natuurlijk staan ​​we systeembeheerders toe alles te publiceren. In triggerOptions beschrijven we de bewerkingen waarvoor de trigger wordt geactiveerd.

En het belangrijkste is return {exitState = “CANCEL”}, daarom is de trigger ontwikkeld. Er wordt een fout geretourneerd wanneer de gebruiker zijn afbeelding probeert te delen in het configuratiescherm.

In de FCO-architectuur wordt elk object (schijf, server, afbeelding, netwerk, netwerkadapter, enz.) weergegeven als een Resource-entiteit, die gemeenschappelijke parameters heeft:

  • Bron-UUID
  • naam van de bron
  • soort bron
  • UUID van resource-eigenaar
  • resourcestatus (actief, inactief)
  • metagegevens van bronnen
  • bronsleutels
  • UUID van het product dat eigenaar is van de bron
  • bron VDC

Dit is erg handig als u met een API werkt, wanneer alle bronnen volgens hetzelfde principe werken. Producten worden geconfigureerd door de aanbieder en besteld door de klant. Omdat onze facturering aan de zijkant gebeurt, kan de klant vrijelijk elk product via het paneel bestellen. Dit wordt later bij de facturering verrekend. Het product kan een IP-adres per uur zijn, een extra GB schijf per uur of gewoon een server.

Sleutels kunnen worden gebruikt om bepaalde bronnen te markeren om de logica van het werken ermee te veranderen. We kunnen bijvoorbeeld drie fysieke knooppunten markeren met de toets Gewicht, en sommige klanten met dezelfde sleutel markeren, waardoor deze knooppunten persoonlijk aan deze klanten worden toegewezen. We gebruiken dit mechanisme voor VIP-klanten die niet van buren naast hun VM's houden. De functionaliteit zelf kan veel breder worden gebruikt.

Het licentiemodel omvat het betalen voor elke processorkern van een fysiek knooppunt. De kosten worden ook beïnvloed door het aantal clustertypen. Als u bijvoorbeeld van plan bent om KVM en VMware samen te gebruiken, zullen de licentiekosten stijgen.

FCO is een volwaardig product, de functionaliteit is zeer rijk, dus we zijn van plan meerdere artikelen tegelijk voor te bereiden met een gedetailleerde beschrijving van de werking van het netwerkgedeelte.

Omdat we al enkele jaren met deze orkestrator samenwerken, kunnen we hem als zeer geschikt bestempelen. Helaas is het product niet zonder gebreken:

  • we moesten de database optimaliseren omdat zoekopdrachten langzamer begonnen te worden naarmate de hoeveelheid gegevens daarin toenam;
  • na één ongeval werkte het herstelmechanisme niet vanwege een bug, en moesten we de auto's van ongelukkige klanten herstellen met behulp van onze eigen set scripts;
  • Het mechanisme voor het detecteren van de onbeschikbaarheid van knooppunten is in de code verankerd en kan niet worden aangepast. Dat wil zeggen dat we niet ons eigen beleid kunnen opstellen om de onbeschikbaarheid van een knooppunt te bepalen.
  • logboekregistratie is niet altijd gedetailleerd. Soms, als je naar een heel laag niveau moet gaan om een ​​bepaald probleem te begrijpen, heb je voor sommige componenten niet genoeg broncode om te begrijpen waarom;

TOTAAL: Over het algemeen zijn de indrukken van het product goed. We staan ​​voortdurend in contact met de orkestratorontwikkelaars. De jongens zijn geneigd tot constructieve samenwerking.

Ondanks zijn eenvoud heeft FCO een brede functionaliteit. In toekomstige artikelen willen we dieper ingaan op de volgende onderwerpen:

  • netwerken bij FCO
  • het verstrekken van live-herstel en FQP-protocol
  • het schrijven van uw eigen plug-ins en widgets
  • het aansluiten van aanvullende diensten zoals Load Balancer en Acronis
  • back-up
  • uniform mechanisme voor het configureren en configureren van knooppunten
  • het verwerken van metagegevens van virtuele machines

ZY Schrijf in de reacties als je geïnteresseerd bent in andere aspecten. Blijf kijken!

Bron: www.habr.com

Voeg een reactie