Per fornire il servizio IaaS (Data Center Virtuale), utilizziamo l'orchestratore commerciale (FCO). Questa soluzione presenta un'architettura piuttosto unica, che la distingue dai noti Openstack e CloudStack.
Come hypervisor per i nodi compute, sono supportati KVM, VmWare, Xen, Virtuozzo6/7, oltre ai container dello stesso Virtuozzo. Tra gli storage supportati ci sono: locale, NFS, Ceph e Virtuozzo Storage.
FCO supporta la creazione di più cluster e la loro gestione da un'unica interfaccia. Ciò significa che è possibile gestire il cluster Virtuozzo e il cluster KVM + Ceph passando da uno all'altro con un clic del mouse.
In sostanza, FCO è una soluzione completa per i fornitori di cloud, che oltre all'orchestrazione include anche la fatturazione, con tutte le impostazioni, i plugin di pagamento, fatture, notifiche, rivenditori, tariffe e così via. Tuttavia, la parte di fatturazione non è in grado di coprire tutte le peculiarità russe, quindi abbiamo deciso di non utilizzarla a favore di un'altra soluzione.
Siamo molto soddisfatti del sistema flessibile di distribuzione dei diritti su tutte le risorse del cloud: immagini, dischi, prodotti, server, firewall – tutto questo può essere condiviso e i diritti possono essere assegnati tra utenti, anche tra utenti di clienti diversi. Ogni cliente può creare nel proprio cloud diversi data center indipendenti e gestirli da un'unica interfaccia di gestione.
Architettonicamente, FCO è composto da diverse parti, ognuna delle quali ha il proprio codice indipendente, e alcune anche il proprio database.
Skyline – interfaccia di amministrazione e utente
Jade – logica di business, billing, gestione delle attività
Tigerlily – coordinatore del servizio, gestisce e coordina lo scambio di informazioni tra la logica di business e i cluster.
XVPManager – gestione degli elementi del cluster: nodi, storage, rete e macchine virtuali.
XVPAgent – agente installato sui nodi per interagire con XVPManager
Intendiamo inserire una descrizione dettagliata dell'architettura di ciascun componente in una serie di articoli, se, ovviamente, il tema susciterà interesse.
Il principale vantaggio di FCO deriva dalla sua 'modularità'. A vostra disposizione ci sono semplicità e minimalismo. Per la nodo di gestione viene dedicata una macchina virtuale su Ubuntu, dove vengono installati tutti i pacchetti necessari. Tutte le impostazioni sono portate in file di configurazione nel formato variabile-valore:
# 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"
…
Tutta la configurazione viene inizialmente modificata nei modelli, quindi viene avviato il generatore
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Come si può vedere, l'interfaccia è composta da widget, la gestione dei quali è accessibile all'utente. Egli può facilmente aggiungere/rimuovere widget dalla pagina, creando così il proprio dashboard.
Nonostante la sua chiusura, FCO è un sistema altamente personalizzabile. Ha un'enorme quantità di impostazioni e punti di accesso per modificare il workflow:
- Supporta plugin personalizzati, ad esempio è possibile scrivere il proprio metodo di billing o una propria risorsa esterna per fornire l'utente
- Supporta trigger personalizzati per eventi specifici, come l'aggiunta della prima macchina virtuale per il cliente al momento della sua creazione
- Supporta widget personalizzati nell'interfaccia, ad esempio incorporare video da youtube direttamente nell'interfaccia utente.
Tutta la personalizzazione è scritta in linguaggio FDL, che si basa su Lua. Se conosci Lua, non avrai 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 clienti. Lo facciamo affinché un utente non possa generare un'immagine dannosa per gli 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 register sarà chiamata dal nucleo FCO. Restituirà il nome della funzione da invocare. Il parametro "p" di questa funzione contiene il contesto della chiamata, e alla prima invocazione sarà vuoto (nil). Questo ci permetterà di registrare il nostro trigger. In triggerType indichiamo che il trigger viene attivato PRIMA dell'operazione di pubblicazione e si applica solo agli utenti. Naturalmente, agli amministratori del sistema consentiamo di pubblicare tutto. In triggerOptions dettagliamo le operazioni per cui il trigger si attiverà.
E, cosa più importante, return {exitState = "CANCEL"}, per cui il trigger è stato progettato. Restituirà un errore quando l'utente cercherà di condividere la propria immagine nel pannello di controllo.
Nell'architettura FCO, ogni oggetto (disco, server, immagine, rete, adattatore di rete, ecc.) è rappresentato come un'entità Resource, che ha parametri comuni:
- UUID della risorsa
- nome della risorsa
- tipo di risorsa
- UUID del proprietario della risorsa
- stato della risorsa (attivo, inattivo)
- metadati della risorsa
- chiavi della risorsa
- UUID del prodotto a cui appartiene la risorsa
- VDC della risorsa
Questo è molto comodo quando si lavora tramite API, poiché tutte le operazioni vengono eseguite con lo stesso principio. I prodotti sono configurati dal fornitore, mentre il cliente li ordina. Poiché la nostra fatturazione è separata, il cliente può ordinare liberamente e gratuitamente qualsiasi prodotto dal pannello. Verrà conteggiato in un secondo momento nella fatturazione. Un prodotto può essere, ad esempio, un indirizzo IP all'ora, un ulteriore GB di disco all'ora o semplicemente un server.
Le chiavi possono essere utilizzate per contrassegnare risorse specifiche al fine di modificare la logica del loro utilizzo. Ad esempio, possiamo contrassegnare tre nodi fisici con la chiave Weight e contrassegnare alcuni clienti con la stessa chiave, evidenziando così questi nodi per questi clienti specifici. Questo meccanismo viene utilizzato per i clienti VIP, che preferiscono non avere vicini accanto alle loro VM. La funzionalità stessa può essere applicata in modo molto più ampio.
Il modello di licenza prevede il pagamento per ogni core del processore di un nodo fisico. Anche il numero dei tipi di cluster influisce sul costo. Se si prevede di utilizzare KVM e VMware insieme, ad esempio, il costo della licenza aumenterà.
FCO è un prodotto completo, con una ricca funzionalità, quindi pianifichiamo di preparare diversi articoli con una descrizione dettagliata del funzionamento della parte rete.
Dopo aver lavorato con questo orchestratore per diversi anni, possiamo affermare che è molto valido. Purtroppo, il prodotto non è privo di difetti:
- abbiamo dovuto ottimizzare il database, poiché le query iniziavano a rallentare con l'aumento della quantità di dati in esso;
- dopo un incidente causato da un bug, il meccanismo di recovery non ha funzionato, e abbiamo dovuto ripristinare le macchine dei clienti sfortunati con il nostro set di script;
- il meccanismo di rilevamento dell'indisponibilità del nodo è incorporato nel codice e non è personalizzabile. Ciò significa che non possiamo creare le nostre politiche di determinazione dell'indisponibilità del nodo.
- Il logging non è sempre dettagliato. A volte, quando è necessario scendere a un livello molto basso per analizzare un problema specifico, manca il codice sorgente di alcuni componenti per comprendere le cause;
TOTALE: Nel complesso, le impressioni sul prodotto sono buone. Siamo in contatto costante con gli sviluppatori dell'orchestratore. I ragazzi sono aperti a una collaborazione costruttiva.
Nonostante la sua semplicità, FCO offre un'ampia funzionalità. Negli articoli futuri, prevediamo di approfondire i seguenti argomenti:
- organizzazione della rete in FCO
- garanzia di live-recovery e protocollo FQP
- scrittura di plugin e widget personalizzati
- integrazione di servizi aggiuntivi, come Load Balancer e Acronis
- backup
- meccanismo unificato di configurazione e impostazione dei nodi
- gestione dei metadati delle macchine virtuali
P.S. Scrivete nei commenti se vi interessano altri aspetti. Rimanete sintonizzati!
Fonte: habr.com
