Flexiant Cloud Orchestrator: cosa include

Flexiant Cloud Orchestrator: cosa include

Per fornire servizi IaaS (Virtual Data Center), noi Rusonyx utilizziamo un orchestratore commerciale Flexiant Cloud Orchestrator (FCO). Questa soluzione ha un'architettura piuttosto particolare, che la distingue da Openstack e CloudStack, noti al grande pubblico.

KVM, VmWare, Xen, Virtuozzo6/7, così come i contenitori dello stesso Virtuozzo sono supportati come hypervisor dei nodi di calcolo. Le opzioni di archiviazione supportate includono archiviazione locale, NFS, Ceph e Virtuozzo.

FCO supporta la creazione e la gestione di più cluster da un'unica interfaccia. Cioè puoi gestire un cluster Virtuozzo e un cluster KVM + Ceph passando dall'uno all'altro con un clic del mouse.

Fondamentalmente, FCO è una soluzione completa per i fornitori di servizi cloud che, oltre all'orchestrazione, include anche la fatturazione, con tutte le impostazioni, plug-in di pagamento, fatture, notifiche, rivenditori, tariffe e così via. Tuttavia, la parte relativa alla fatturazione non è in grado di coprire tutte le sfumature della Russia, quindi ne abbiamo abbandonato l’uso a favore di un’altra soluzione.

Sono molto soddisfatto del sistema flessibile per la distribuzione dei diritti su tutte le risorse cloud: immagini, dischi, prodotti, server, firewall: tutto questo può essere "condiviso" e concesso diritti tra utenti e persino tra utenti di client diversi. Ogni cliente può creare più data center indipendenti nel proprio cloud e gestirli da un unico pannello di controllo.

Flexiant Cloud Orchestrator: cosa include

Dal punto di vista architettonico, FCO è costituito da più parti, ciascuna delle quali ha il proprio codice indipendente e alcune hanno il proprio database.

Linea dell'orizzonte – interfaccia di amministrazione e utente
Giada – logica aziendale, fatturazione, gestione delle attività
Tigerlily – coordinatore del servizio, gestisce e coordina lo scambio di informazioni tra logiche di business e cluster.
XVPMeser – gestione degli elementi del cluster: nodi, storage, rete e macchine virtuali.
XVPAgent – un agent installato sui nodi per interagire con XVPManager

Flexiant Cloud Orchestrator: cosa include

Abbiamo intenzione di includere una storia dettagliata sull'architettura di ciascun componente in una serie di articoli, se, ovviamente, l'argomento suscita interesse.

Il vantaggio principale di FCO deriva dalla sua natura “in scatola”. Semplicità e minimalismo sono al tuo servizio. Per il nodo di controllo viene assegnata una macchina virtuale su Ubuntu, nella quale sono installati tutti i pacchetti necessari. Tutte le impostazioni vengono inserite nei file di configurazione sotto forma di valore variabile:

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

L'intera configurazione viene inizialmente modificata nei modelli, quindi viene avviato il generatore
#build-config che genererà un file vars e ordinerà ai servizi di rileggere la configurazione. L'interfaccia utente è gradevole e può essere facilmente personalizzata.

Flexiant Cloud Orchestrator: cosa include

Come puoi vedere, l'interfaccia è composta da widget che possono essere controllati dall'utente. Può facilmente aggiungere/rimuovere widget dalla pagina, creando così la dashboard di cui ha bisogno.

Nonostante la sua natura chiusa, FCO è un sistema altamente personalizzabile. Ha un numero enorme di impostazioni e punti di accesso per modificare il flusso di lavoro:

  1. Sono supportati plugin personalizzati, ad esempio puoi scrivere il tuo metodo di fatturazione o la tua risorsa esterna da fornire all'utente
  2. Sono supportati trigger personalizzati per determinati eventi, ad esempio l'aggiunta della prima macchina virtuale a un client al momento della sua creazione
  3. Sono supportati widget personalizzati nell'interfaccia, ad esempio incorporando un video di YouTube direttamente nell'interfaccia utente.

Tutta la personalizzazione è scritta in FDL, che è basato su Lua. Se conosci Lua, non ci saranno problemi con FDL.

Ecco un esempio di uno dei trigger più semplici che utilizziamo. Questo trigger non consente agli utenti di condividere le proprie immagini con altri client. Lo facciamo per impedire a un utente di creare un'immagine dannosa per altri utenti.

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 funzione di registro verrà chiamata dal kernel FCO. Restituirà il nome della funzione da chiamare. Il parametro “p” di questa funzione memorizza il contesto della chiamata e la prima volta che verrà chiamato sarà vuoto (nil). Ciò ci consentirà di registrare il nostro trigger. In triggerType indichiamo che il trigger viene richiamato PRIMA dell'operazione di pubblicazione e influisce solo sugli utenti. Naturalmente consentiamo agli amministratori di sistema di pubblicare tutto. In triggerOptions descriviamo in dettaglio le operazioni per le quali verrà attivato il trigger.

E la cosa principale è return {exitState = “CANCEL”}, motivo per cui è stato sviluppato il trigger. Restituirà un errore quando l'utente tenta di condividere la propria immagine nel pannello di controllo.

Nell'architettura FCO, qualsiasi oggetto (disco, server, immagine, rete, adattatore di rete, ecc.) è rappresentato come un'entità Risorsa, che ha parametri comuni:

  • UUID della risorsa
  • nome della risorsa
  • tipo di risorsa
  • UUID del proprietario della risorsa
  • stato della risorsa (attivo, inattivo)
  • metadati delle risorse
  • chiavi delle risorse
  • UUID del prodotto che possiede la risorsa
  • risorsa VDC

Ciò è molto comodo quando si lavora utilizzando un'API, quando tutte le risorse funzionano secondo lo stesso principio. I prodotti sono configurati dal fornitore e ordinati dal cliente. Poiché la nostra fatturazione è separata, il cliente può ordinare liberamente qualsiasi prodotto dal pannello. Verrà calcolato successivamente in fase di fatturazione. Il prodotto può essere un indirizzo IP all'ora, un GB aggiuntivo di disco all'ora o semplicemente un server.

Le chiavi possono essere utilizzate per contrassegnare determinate risorse per modificare la logica di lavoro con esse. Ad esempio, possiamo contrassegnare tre nodi fisici con la chiave Weight e contrassegnare alcuni client con la stessa chiave, assegnando così questi nodi personalmente a questi client. Utilizziamo questo meccanismo per i clienti VIP a cui non piacciono i vicini accanto alle loro VM. La funzionalità stessa può essere utilizzata in modo molto più ampio.

Il modello di licenza prevede il pagamento per ciascun core del processore di un nodo fisico. Il costo dipende anche dal numero di tipi di cluster. Se prevedi di utilizzare KVM e VMware insieme, ad esempio, il costo della licenza aumenterà.

FCO è un prodotto a tutti gli effetti, le sue funzionalità sono molto ricche, quindi prevediamo di preparare più articoli contemporaneamente con una descrizione dettagliata del funzionamento della parte di rete.

Avendo lavorato con questo orchestratore per diversi anni, possiamo considerarlo molto adatto. Ahimè, il prodotto non è esente da difetti:

  • abbiamo dovuto ottimizzare il database perché le query hanno cominciato a rallentare con l'aumentare della quantità di dati in esse contenute;
  • dopo un incidente, il meccanismo di recupero non ha funzionato a causa di un bug, e abbiamo dovuto recuperare le auto degli sfortunati clienti utilizzando il nostro set di script;
  • Il meccanismo per rilevare l'indisponibilità del nodo è integrato nel codice e non può essere personalizzato. Cioè, non possiamo creare le nostre politiche per determinare l'indisponibilità di un nodo.
  • la registrazione non è sempre dettagliata. A volte, quando è necessario scendere a un livello molto basso per comprendere un particolare problema, non si dispone di codice sorgente sufficiente per consentire ad alcuni componenti di capirne il motivo;

TOTALE: In generale, le impressioni del prodotto sono buone. Siamo in costante contatto con gli sviluppatori dell'orchestratore. I ragazzi sono disposti a una cooperazione costruttiva.

Nonostante la sua semplicità, FCO ha un'ampia funzionalità. Nei prossimi articoli intendiamo approfondire i seguenti argomenti:

  • networking presso FCO
  • fornendo live-recovery e protocollo FQP
  • scrivere i tuoi plugin e widget
  • connettendo servizi aggiuntivi come Load Balancer e Acronis
  • backup
  • meccanismo unificato per la configurazione e la configurazione dei nodi
  • elaborazione dei metadati della macchina virtuale

ZY Scrivi nei commenti se sei interessato ad altri aspetti. Rimani sintonizzato!

Fonte: habr.com

Aggiungi un commento