{"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> un orchestratore commerciale Flexiant Cloud Orchestrator<\/a><\/noindex> (FCO). Questa soluzione ha un'architettura abbastanza unica, che la distingue da conosciute soluzioni come Openstack e CloudStack.<\/a><\/noindex> <\/p>\n

Come hypervisor, le nodi compute supportano KVM, VmWare, Xen, Virtuozzo6\/7, oltre ai container dello stesso Virtuozzo. Tra i sistemi di 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. \u00c8 possibile gestire un cluster Virtuozzo e un cluster KVM + Ceph semplicemente cliccando.<\/p>\n

Essenzialmente, FCO \u00e8 una soluzione completa per i fornitori cloud, che oltre all'orchestrazione include anche il billing, con tutte le configurazioni, i plugin di pagamento, le fatture, le notifiche, i rivenditori, le tariffe e cos\u00ec via. Tuttavia, la parte di billing non pu\u00f2 coprire tutte le specificit\u00e0 russe, quindi abbiamo deciso di rinunciare al suo utilizzo a favore di un'altra soluzione.<\/p>\n

\u00c8 molto apprezzata la flessibile distribuzione dei diritti su tutte le risorse del cloud: immagini, dischi, prodotti, server, firewall \u2013 tutto ci\u00f2 pu\u00f2 essere 'condiviso' e i diritti possono essere concessi tra gli utenti, anche tra utenti di clienti diversi. Ogni cliente pu\u00f2 creare nel proprio cloud diversi data center indipendenti e gestirli da un'unica dashboard.<\/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 per amministratori e utenti
\nJade<\/b> \u2013 logica business, billing, gestione dei task
\nTigerlily<\/b> \u2013 coordinatore del servizio, gestisce e coordina lo scambio di informazioni tra la logica 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
\nUn racconto dettagliato sull'architettura di ogni componente \u00e8 previsto in un ciclo di articoli, se, naturalmente, l'argomento susciter\u00e0 interesse.<\/p>\n

Il principale vantaggio di FCO deriva dalla sua \"struttura a scatola\". Avrete a disposizione semplicit\u00e0 e minimalismo. Per il nodo di gestione viene allocata una macchina virtuale su Ubuntu, in cui vengono installati tutti i pacchetti necessari. Tutte le configurazioni sono estratte in file di configurazione in 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, poi si avvia 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 cui gestione \u00e8 accessibile all'utente. Pu\u00f2 facilmente aggiungere\/rimuovere widget dalla pagina, formando cos\u00ec il dashboard desiderato.<\/p>\n
Nonostante la sua chiusura, FCO \u00e8 un sistema altamente personalizzabile. Ha un numero enorme di impostazioni e punti di ingresso per modificare il flusso di lavoro:<\/p>\n
    \n
  1. Sono supportati plugin personalizzati, ad esempio, \u00e8 possibile scrivere il proprio metodo di fatturazione o una risorsa esterna per fornire all'utente<\/li>\n
  2. Sono supportati trigger personalizzati per eventi specifici, ad esempio l'aggiunta della prima macchina virtuale a un cliente al momento della sua creazione<\/li>\n
  3. Sono supportati widget personalizzati nell'interfaccia, per esempio, integrare video da youtube direttamente nell'interfaccia utente.<\/li>\n<\/ol>\n
    \nTutta la personalizzazione viene 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 per evitare che un utente possa creare un'immagine dannosa per altri.<\/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 verr\u00e0 chiamata dal nucleo di FCO. Restituir\u00e0 il nome della funzione che dovr\u00e0 essere chiamata. Il parametro \u201cp\u201d di questa funzione conserva il contesto di chiamata, e al primo invio sar\u00e0 vuoto (nil). Ci\u00f2 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. Gli amministratori di sistema, ovviamente, sono autorizzati a pubblicare tutto. In triggerOptions dettagliamo le operazioni per cui il trigger verr\u00e0 attivato.<\/p>\n
    E infine \u2013 return {exitState = \u201cCANCEL\u201d}, motivo per cui il trigger \u00e8 stato sviluppato. Restituir\u00e0 un errore quando l'utente tenter\u00e0 di condividere la propria immagine nella dashboard.<\/p>\n
    Nell'architettura FCO, qualsiasi oggetto (disco, server, immagine, rete, adattatore di rete, ecc.) \u00e8 rappresentato come un'entit\u00e0 Resource, che ha parametri comuni:<\/p>\n