Flexiant Cloud Orchestrator: amb què es menja

Flexiant Cloud Orchestrator: amb què es menja

Per oferir serveis IaaS (Virtual Data Center), nosaltres Rusonyx fem servir un orquestrador comercial Flexiant Cloud Orchestrator (FCO). Aquesta solució té una arquitectura força única, que la distingeix d'Openstack i CloudStack, coneguts pel gran públic.

KVM, VmWare, Xen, Virtuozzo6/7, així com els contenidors del mateix Virtuozzo són compatibles com a hipervisors de nodes de càlcul. Les opcions d'emmagatzematge admeses inclouen emmagatzematge local, NFS, Ceph i Virtuozzo.

FCO admet la creació i gestió de múltiples clústers des d'una única interfície. És a dir, podeu gestionar un clúster Virtuozzo i un clúster KVM + Ceph canviant entre ells amb un clic del ratolí.

En el seu nucli, FCO és una solució integral per a proveïdors de núvol, que, a més de l'orquestració, també inclou la facturació, amb tota la configuració, connectors de pagament, factures, notificacions, revenedors, tarifes, etc. Tanmateix, la part de facturació no és capaç de cobrir tots els matisos russos, per la qual cosa vam abandonar el seu ús a favor d'una altra solució.

Estic molt satisfet amb el sistema flexible per distribuir drets a tots els recursos del núvol: imatges, discs, productes, servidors, tallafocs; tot això es pot "compartir" i concedir drets entre usuaris, i fins i tot entre usuaris de diferents clients. Cada client pot crear diversos centres de dades independents al seu núvol i gestionar-los des d'un únic panell de control.

Flexiant Cloud Orchestrator: amb què es menja

Arquitectònicament, FCO consta de diverses parts, cadascuna de les quals té el seu propi codi independent i algunes tenen la seva pròpia base de dades.

Horitzó - Interfície d'usuari i administrador
jade – lògica de negoci, facturació, gestió de tasques
tigerlily – coordinador de serveis, gestiona i coordina l'intercanvi d'informació entre la lògica de negoci i els clústers.
XVPManager – gestió dels elements del clúster: nodes, emmagatzematge, xarxa i màquines virtuals.
XVPAgent – un agent instal·lat als nodes per interactuar amb XVPManager

Flexiant Cloud Orchestrator: amb què es menja

Tenim previst incloure una història detallada sobre l'arquitectura de cada component en una sèrie d'articles, si, és clar, el tema desperta interès.

El principal avantatge de FCO prové de la seva naturalesa "en caixa". La senzillesa i el minimalisme estan al vostre servei. Per al node de control, s'assigna una màquina virtual a Ubuntu, a la qual s'instal·len tots els paquets necessaris. Tots els paràmetres es col·loquen als fitxers de configuració en forma de valor variable:

# 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"
…

Tota la configuració s'edita inicialment en plantilles i després s'inicia el generador
#build-config que generarà un fitxer vars i ordenarà als serveis que tornin a llegir la configuració. La interfície d'usuari és agradable i es pot marcar fàcilment.

Flexiant Cloud Orchestrator: amb què es menja

Com podeu veure, la interfície consta de ginys que poden ser controlats per l'usuari. Pot afegir/eliminar ginys fàcilment de la pàgina, creant així el tauler de control que necessita.

Malgrat la seva naturalesa tancada, FCO és un sistema altament personalitzable. Té un gran nombre de configuracions i punts d'entrada per canviar el flux de treball:

  1. S'admeten connectors personalitzats, per exemple, podeu escriure el vostre propi mètode de facturació o el vostre propi recurs extern per proporcionar a l'usuari
  2. S'admeten activadors personalitzats per a determinats esdeveniments, per exemple, afegir la primera màquina virtual a un client quan es crea
  3. Els ginys personalitzats a la interfície són compatibles, per exemple, la inserció d'un vídeo de YouTube directament a la interfície d'usuari.

Tota la personalització està escrita en FDL, que es basa en Lua. Si coneixeu Lua, no hi haurà problemes amb FDL.

Aquí teniu un exemple d'un dels activadors més senzills que fem servir. Aquest activador no permet als usuaris compartir les seves pròpies imatges amb altres clients. Ho fem per evitar que un usuari creï una imatge maliciosa per a altres usuaris.

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

La funció de registre serà cridada pel nucli FCO. Tornarà el nom de la funció a cridar. El paràmetre "p" d'aquesta funció emmagatzema el context de la trucada i la primera vegada que es crida estarà buit (nul). El que ens permetrà registrar el nostre disparador. A triggerType indiquem que el disparador s'invoca ABANS de l'operació de publicació i només afecta els usuaris. Per descomptat, permetem que els administradors del sistema publiquin tot. A triggerOptions detallem les operacions per a les quals es dispararà el disparador.

I el més important és retornar {exitState = “CANCEL”}, per això es va desenvolupar el disparador. Tornarà a fallar quan l'usuari intenti compartir la seva imatge al tauler de control.

A l'arquitectura FCO, qualsevol objecte (disc, servidor, imatge, xarxa, adaptador de xarxa, etc.) es representa com una entitat Resource, que té paràmetres comuns:

  • UUID del recurs
  • nom del recurs
  • tipus de recurs
  • UUID del propietari del recurs
  • estat del recurs (actiu, inactiu)
  • metadades dels recursos
  • claus de recursos
  • UUID del producte propietari del recurs
  • recurs VDC

Això és molt convenient quan es treballa amb una API, quan tots els recursos es treballen segons el mateix principi. Els productes són configurats pel proveïdor i encarregats pel client. Com que la nostra facturació és lateral, el client pot demanar lliurement qualsevol producte des del panell. Es calcularà més endavant en la facturació. El producte pot ser una adreça IP per hora, un GB addicional de disc per hora o només un servidor.

Les claus es poden utilitzar per marcar determinats recursos per canviar la lògica de treballar-hi. Per exemple, podem marcar tres nodes físics amb la clau de pes i marcar alguns clients amb la mateixa clau, assignant així aquests nodes personalment a aquests clients. Utilitzem aquest mecanisme per als clients VIP als quals no els agraden els veïns al costat de les seves màquines virtuals. La pròpia funcionalitat es pot utilitzar molt més àmpliament.

El model de llicència implica pagar per cada nucli de processador d'un node físic. El cost també es veu afectat pel nombre de tipus de clúster. Si teniu previst utilitzar KVM i VMware junts, per exemple, el cost de la llicència augmentarà.

FCO és un producte complet, la seva funcionalitat és molt rica, per la qual cosa tenim previst preparar diversos articles alhora amb una descripció detallada del funcionament de la part de la xarxa.

Després d'haver treballat amb aquest orquestrador durant diversos anys, podem marcar-lo com a molt adequat. Per desgràcia, el producte no està exempt de defectes:

  • vam haver d'optimitzar la base de dades perquè les consultes van començar a disminuir a mesura que augmentava la quantitat de dades que contenien;
  • després d'un accident, el mecanisme de recuperació no va funcionar a causa d'un error, i vam haver de recuperar els cotxes de clients desafortunats utilitzant el nostre propi conjunt d'scripts;
  • El mecanisme per detectar la indisponibilitat del node està connectat al codi i no es pot personalitzar. És a dir, no podem crear les nostres pròpies polítiques per determinar la indisponibilitat d'un node.
  • el registre no sempre és detallat. De vegades, quan necessiteu baixar a un nivell molt baix per entendre un problema en particular, no teniu prou codi font perquè alguns components entenguin el perquè;

TOTAL: En general, les impressions del producte són bones. Estem en contacte constant amb els desenvolupadors de l'orquestrador. Els nois estan disposats a la cooperació constructiva.

Malgrat la seva senzillesa, FCO té una àmplia funcionalitat. En propers articles tenim previst aprofundir en els següents temes:

  • networking a FCO
  • proporcionant un protocol de recuperació en viu i FQP
  • escrivint els vostres propis connectors i ginys
  • connectant serveis addicionals com ara Load Balancer i Acronis
  • còpia de seguretat
  • mecanisme unificat per configurar i configurar nodes
  • processament de metadades de la màquina virtual

Z.Y. Escriu als comentaris si t'interessen altres aspectes. Estigueu atents!

Font: www.habr.com

Afegeix comentari