{"id":32318,"date":"2019-10-31T21:46:20","date_gmt":"2019-10-31T18:46:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/flexiant-cloud-orchestrator-s-chem-ego-edyat\/"},"modified":"2019-10-31T21:46:20","modified_gmt":"2019-10-31T18:46:20","slug":"flexiant-cloud-orchestrator-s-chem-ego-edyat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/flexiant-cloud-orchestrator-s-chem-ego-edyat","title":{"rendered":"Flexiant Cloud Orchestrator: a cosa serve","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Flexiant
\n
\nPer fornire il servizio IaaS (Data Center Virtuale), utilizziamo Rusonyx<\/a><\/noindex> l'orchestratore commerciale Flexiant Cloud Orchestrator<\/a><\/noindex> (FCO). Questa soluzione presenta un'architettura piuttosto unica, che la distingue dai noti Openstack e CloudStack.<\/a><\/noindex> <\/p>\n

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.<\/p>\n

FCO supporta la creazione di pi\u00f9 cluster e la loro gestione da un'unica interfaccia. Ci\u00f2 significa che \u00e8 possibile gestire il cluster Virtuozzo e il cluster KVM + Ceph passando da uno all'altro con un clic del mouse.<\/p>\n

In sostanza, FCO \u00e8 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\u00ec via. Tuttavia, la parte di fatturazione non \u00e8 in grado di coprire tutte le peculiarit\u00e0 russe, quindi abbiamo deciso di non utilizzarla a favore di un'altra soluzione.<\/p>\n

Siamo molto soddisfatti del sistema flessibile di distribuzione dei diritti su tutte le risorse del cloud: immagini, dischi, prodotti, server, firewall \u2013 tutto questo pu\u00f2 essere condiviso e i diritti possono essere assegnati tra utenti, anche tra utenti di clienti diversi. Ogni cliente pu\u00f2 creare nel proprio cloud diversi data center indipendenti e gestirli da un'unica interfaccia di gestione.<\/p>\n

\"Flexiant
\n
\nArchitettonicamente, FCO \u00e8 composto da diverse parti, ognuna delle quali ha il proprio codice indipendente, e alcune anche il proprio database.<\/p>\n

Skyline<\/b> \u2013 interfaccia di amministrazione e utente
\nJade<\/b> \u2013 logica di business, billing, gestione delle attivit\u00e0
\nTigerlily<\/b> \u2013 coordinatore del servizio, gestisce e coordina lo scambio di informazioni tra la logica di business e i cluster.
\nXVPManager<\/b> \u2013 gestione degli elementi del cluster: nodi, storage, rete e macchine virtuali.
\nXVPAgent <\/b>\u2013 agente installato sui nodi per interagire con XVPManager<\/p>\n

\"Flexiant
\n
\nIntendiamo inserire una descrizione dettagliata dell'architettura di ciascun componente in una serie di articoli, se, ovviamente, il tema susciter\u00e0 interesse.<\/p>\n

Il principale vantaggio di FCO deriva dalla sua 'modularit\u00e0'. A vostra disposizione ci sono semplicit\u00e0 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:<\/p>\n

# cat \/etc\/extility\/config\/vars\n\u2026\nexport LIMIT_MAX_LIST_ADMIN_DEFAULT=\"30000\"\nexport LIMIT_MAX_LIST_USER_DEFAULT=\"200\"\nexport LOGDIR=\"\/var\/log\/extility\"\nexport LOG_FILE=\"misc.log\"\nexport LOG_FILE_LOG4JHOSTBILLMODULE=\"hostbillmodule.log\"\nexport LOG_FILE_LOG4JJADE=\"jade.log\"\nexport LOG_FILE_LOG4JTL=\"tigerlily.log\"\nexport LOG_FILE_LOG4JXVP=\"xvpmanager.log\"\nexport LOG_FILE_VARS=\"misc.log\"\n\u2026\n<\/code><\/pre>\n
Tutta la configurazione viene inizialmente modificata nei modelli, quindi viene avviato il generatore
\n#build-config \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0441\u0444\u043e\u0440\u043c\u0438\u0440\u0443\u0435\u0442 \u0444\u0430\u0439\u043b vars \u0438 \u0434\u0430\u0441\u0442 \u043a\u043e\u043c\u0430\u043d\u0434\u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430\u043c \u043f\u0435\u0440\u0435\u0447\u0438\u0442\u0430\u0442\u044c \u043a\u043e\u043d\u0444\u0438\u0433. \u041f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0439 \u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441 \u043f\u0440\u0438\u044f\u0442\u043d\u044b\u0439 \u0438 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043b\u0435\u0433\u043a\u043e \u0437\u0430\u0431\u0440\u0435\u043d\u0434\u0438\u0440\u043e\u0432\u0430\u043d.<\/p>\n
\"Flexiant
\n
\nCome si pu\u00f2 vedere, l'interfaccia \u00e8 composta da widget, la gestione dei quali \u00e8 accessibile all'utente. Egli pu\u00f2 facilmente aggiungere\/rimuovere widget dalla pagina, creando cos\u00ec il proprio dashboard.<\/p>\n
Nonostante la sua chiusura, FCO \u00e8 un sistema altamente personalizzabile. Ha un'enorme quantit\u00e0 di impostazioni e punti di accesso per modificare il workflow:<\/p>\n
    \n
  1. Supporta plugin personalizzati, ad esempio \u00e8 possibile scrivere il proprio metodo di billing o una propria risorsa esterna per fornire l'utente<\/li>\n
  2. Supporta trigger personalizzati per eventi specifici, come l'aggiunta della prima macchina virtuale per il cliente al momento della sua creazione<\/li>\n
  3. Supporta widget personalizzati nell'interfaccia, ad esempio incorporare video da youtube direttamente nell'interfaccia utente.<\/li>\n<\/ol>\n
    \nTutta la personalizzazione \u00e8 scritta in linguaggio FDL, che si basa su Lua. Se conosci Lua, non avrai problemi con FDL.<\/p>\n
    Ecco un esempio di uno dei trigger pi\u00f9 semplici che utilizziamo. Questo trigger non consente agli utenti di condividere le proprie immagini con altri clienti. Lo facciamo affinch\u00e9 un utente non possa generare un'immagine dannosa per gli altri utenti.<\/p>\n
    function register()\n    return {\"pre_user_api_publish\"}\nend\n   \nfunction pre_user_api_publish(p)  \n    if(p==nil) then\n        return{\n            ref = \"cancelPublishImage\",\n            name = \"Cancel publishing\",\n            description = \"Cancel all user\u2019s images publishing\",\n            triggerType = \"PRE_USER_API_CALL\",\n            triggerOptions = {\"publishResource\", \"publishImage\"},\n            api = \"TRIGGER\",\n            version = 1,\n        }\n    end\n\n    -- Turn publishing off\n    return {exitState = \"CANCEL\"}\n   \nend\n<\/code><\/pre>\n
    La funzione register sar\u00e0 chiamata dal nucleo FCO. Restituir\u00e0 il nome della funzione da invocare. Il parametro \"p\" di questa funzione contiene il contesto della chiamata, e alla prima invocazione sar\u00e0 vuoto (nil). Questo ci permetter\u00e0 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\u00e0.<\/p>\n
    E, cosa pi\u00f9 importante, return {exitState = \"CANCEL\"}, per cui il trigger \u00e8 stato progettato. Restituir\u00e0 un errore quando l'utente cercher\u00e0 di condividere la propria immagine nel pannello di controllo.<\/p>\n
    Nell'architettura FCO, ogni oggetto (disco, server, immagine, rete, adattatore di rete, ecc.) \u00e8 rappresentato come un'entit\u00e0 Resource, che ha parametri comuni:<\/p>\n