{"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\/es\/blog\/news\/flexiant-cloud-orchestrator-s-chem-ego-edyat","title":{"rendered":"Flexiant Cloud Orchestrator: \u00bfqu\u00e9 es y c\u00f3mo funciona?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Flexiant
\n
\nPara ofrecer el servicio IaaS (Centro de Datos Virtual), utilizamos Rusonyx<\/a><\/noindex> el orquestador comercial Flexiant Cloud Orchestrator<\/a><\/noindex> (FCO). Esta soluci\u00f3n tiene una arquitectura bastante \u00fanica que la diferencia de las conocidas Openstack y CloudStack.<\/a><\/noindex> <\/p>\n

Como hipervisores de nodos de computaci\u00f3n, se soportan KVM, VmWare, Xen, Virtuozzo6\/7, as\u00ed como los contenedores de Virtuozzo. Los almacenes soportados incluyen local, NFS, Ceph y Virtuozzo Storage.<\/p>\n

FCO soporta la creaci\u00f3n de varios cl\u00fasteres y su gesti\u00f3n desde una sola interfaz. Es decir, se puede gestionar un cl\u00faster de Virtuozzo y un cl\u00faster de KVM + Ceph alternando entre ellos con un clic del mouse.<\/p>\n

En esencia, FCO es una soluci\u00f3n integral para proveedores de nube, que adem\u00e1s de la orquestaci\u00f3n incluye facturaci\u00f3n, con todas las configuraciones, plugins de pago, facturas, notificaciones, revendedores, tarifas y m\u00e1s. Sin embargo, la parte de facturaci\u00f3n no puede cubrir todas las particularidades rusas, por lo que hemos decidido no utilizarla en favor de otra soluci\u00f3n.<\/p>\n

Nos alegra la flexible sistema de distribuci\u00f3n de derechos sobre todos los recursos de la nube: im\u00e1genes, discos, productos, servidores, cortafuegos; todo esto se puede \"compartir\" y otorgar permisos entre usuarios, incluso entre usuarios de diferentes clientes. Cada cliente puede crear en su nube varios centros de datos independientes y gestionarlos desde un panel de control unificado.<\/p>\n

\"Flexiant
\n
\nDesde el punto de vista arquitect\u00f3nico, FCO est\u00e1 compuesto por varias partes, cada una con su propio c\u00f3digo independiente, y algunas incluso con su propia base de datos.<\/p>\n

Skyline<\/b> \u2013 interfaz administrativa y de usuario
\nJade<\/b> \u2013 l\u00f3gica de negocio, facturaci\u00f3n, gesti\u00f3n de tareas
\nTigerlily<\/b> \u2013 coordinador del servicio, gestiona y coordina el intercambio de informaci\u00f3n entre la l\u00f3gica de negocio y los cl\u00fasteres.
\nXVPManager<\/b> \u2013 gesti\u00f3n de elementos del cl\u00faster: nodos, almacenamiento, red y m\u00e1quinas virtuales.
\nXVPAgent <\/b>\u2013 agente instalado en los nodos para interactuar con XVPManager.<\/p>\n

\"Flexiant
\n
\nPlaneamos incluir un relato detallado sobre la arquitectura de cada componente en una serie de art\u00edculos, si, por supuesto, el tema genera inter\u00e9s.<\/p>\n

La principal ventaja de FCO proviene de su 'cajonera'. A su disposici\u00f3n la simplicidad y el minimalismo. Para el nodo gestor se asigna una m\u00e1quina virtual en Ubuntu, en la que se instalan todos los paquetes necesarios. Todas las configuraciones se trasladan a archivos de configuraci\u00f3n en forma de variable-valor:<\/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
Toda la configuraci\u00f3n se modifica inicialmente en las plantillas, luego se ejecuta el generador
\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
\nComo se puede ver, la interfaz consiste en widgets, cuyo manejo est\u00e1 disponible para el usuario. Puede agregar\/eliminar widgets de la p\u00e1gina f\u00e1cilmente, formando as\u00ed el dashboard que necesita.<\/p>\n
A pesar de su cerradura, FCO es un sistema muy personalizable. Tiene una gran cantidad de configuraciones y puntos de entrada para modificar el flujo de trabajo:<\/p>\n
    \n
  1. Se admiten complementos personalizados, por ejemplo, se puede escribir su propio m\u00e9todo de facturaci\u00f3n o un recurso externo para ofrecer al usuario<\/li>\n
  2. Se admiten disparadores personalizados para ciertos eventos, como a\u00f1adir la primera m\u00e1quina virtual al cliente al crearlo<\/li>\n
  3. Se admiten widgets personalizados en la interfaz, por ejemplo, integrar un video de YouTube directamente en la interfaz del usuario.<\/li>\n<\/ol>\n
    \nToda la personalizaci\u00f3n se escribe en el lenguaje FDL, que se basa en Lua. Si conoce Lua, no tendr\u00e1 problemas con FDL.<\/p>\n
    Aqu\u00ed hay un ejemplo de uno de los disparadores m\u00e1s simples que utilizamos. Este disparador no permite a los usuarios compartir sus propias im\u00e1genes con otros clientes. Hacemos esto para que un usuario no pueda crear una imagen maliciosa para otros usuarios.<\/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 funci\u00f3n register ser\u00e1 llamada por el n\u00facleo de FCO. Devolver\u00e1 el nombre de la funci\u00f3n que debe ser llamada. El par\u00e1metro 'p' de esta funci\u00f3n contiene el contexto de la llamada, y en la primera llamada estar\u00e1 vac\u00edo (nil). Esto nos permitir\u00e1 registrar nuestro disparador. En triggerType indicamos que el disparador se activa ANTES de la operaci\u00f3n de publicaci\u00f3n, y se aplica solo a los usuarios. A los administradores del sistema, por supuesto, les permitimos publicar todo. En triggerOptions detallamos las operaciones para las que se activar\u00e1 el disparador.<\/p>\n
    Y lo m\u00e1s importante: return {exitState = 'CANCEL'}, para lo que se desarroll\u00f3 el disparador. Devolver\u00e1 un fallo cuando el usuario intente compartir su imagen en el panel de control.<\/p>\n
    En la arquitectura FCO, cualquier objeto (disco, servidor, imagen, red, adaptador de red, etc.) se representa como una entidad Recurso, que tiene par\u00e1metros comunes:<\/p>\n