Flexiant Cloud Orchestrator: con qué viene

Flexiant Cloud Orchestrator: con qué viene

Para proporcionar servicios IaaS (Centro de datos virtual), nosotros Rusonyx utilizamos un orquestador comercial Orquestador de nube flexible (FCO). Esta solución tiene una arquitectura bastante única, que la distingue de Openstack y CloudStack, conocidos por el público en general.

KVM, VmWare, Xen, Virtuozzo6/7, así como contenedores del mismo Virtuozzo, son compatibles como hipervisores de nodos de computación. Las opciones de almacenamiento admitidas incluyen almacenamiento local, NFS, Ceph y Virtuozzo.

FCO admite la creación y gestión de múltiples clústeres desde una única interfaz. Es decir, puede administrar un clúster Virtuozzo y un clúster KVM + Ceph cambiando entre ellos con un clic del mouse.

En esencia, FCO es una solución integral para proveedores de la nube que, además de la orquestación, también incluye facturación, con todas las configuraciones, complementos de pago, facturas, notificaciones, revendedores, tarifas, etc. Sin embargo, la parte de facturación no es capaz de cubrir todos los matices rusos, por lo que abandonamos su uso en favor de otra solución.

Estoy muy satisfecho con el sistema flexible para distribuir derechos a todos los recursos de la nube: imágenes, discos, productos, servidores, firewalls; todo esto se puede "compartir" y otorgar derechos entre usuarios, e incluso entre usuarios de diferentes clientes. Cada cliente puede crear varios centros de datos independientes en su nube y gestionarlos desde un único panel de control.

Flexiant Cloud Orchestrator: con qué viene

Arquitectónicamente, FCO consta de varias partes, cada una de las cuales tiene su propio código independiente y algunas tienen su propia base de datos.

Skyline – interfaz de usuario y administrador
Jade – lógica de negocios, facturación, gestión de tareas
Lirio de tigre – coordinador de servicios, gestiona y coordina el intercambio de información entre la lógica de negocio y los clusters.
XVPManager – gestión de elementos del cluster: nodos, almacenamiento, red y máquinas virtuales.
XVPAgente – un agente instalado en los nodos para interactuar con XVPManager

Flexiant Cloud Orchestrator: con qué viene

Planeamos incluir una historia detallada sobre la arquitectura de cada componente en una serie de artículos, si, por supuesto, el tema despierta interés.

La principal ventaja de FCO surge de su naturaleza "en caja". La sencillez y el minimalismo están a tu servicio. Para el nodo de control, se asigna una máquina virtual en Ubuntu, en la que se instalan todos los paquetes necesarios. Todas las configuraciones se colocan en archivos de configuración en forma de valor variable:

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

Toda la configuración se edita inicialmente en plantillas, luego se inicia el generador
#build-config que generará un archivo vars y ordenará a los servicios que vuelvan a leer la configuración. La interfaz de usuario es agradable y se puede personalizar fácilmente.

Flexiant Cloud Orchestrator: con qué viene

Como puede ver, la interfaz consta de widgets que el usuario puede controlar. Puede agregar o eliminar fácilmente widgets de la página, creando así el panel que necesita.

A pesar de su naturaleza cerrada, FCO es un sistema altamente personalizable. Tiene una gran cantidad de configuraciones y puntos de entrada para cambiar el flujo de trabajo:

  1. Se admiten complementos personalizados; por ejemplo, puede escribir su propio método de facturación o su propio recurso externo para proporcionar al usuario
  2. Se admiten activadores personalizados para ciertos eventos, por ejemplo, agregar la primera máquina virtual a un cliente cuando se crea.
  3. Se admiten widgets personalizados en la interfaz, por ejemplo, incrustar un vídeo de YouTube directamente en la interfaz de usuario.

Toda la personalización está escrita en FDL, que se basa en Lua. Si conoces Lua, no habrá problemas con FDL.

A continuación se muestra un ejemplo de uno de los desencadenantes más simples que utilizamos. Este activador no permite a los usuarios compartir sus propias imágenes con otros clientes. Hacemos esto para evitar que un usuario cree una imagen maliciosa para otros usuarios.

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 función de registro será llamada por el kernel FCO. Devolverá el nombre de la función a llamar. El parámetro "p" de esta función almacena el contexto de la llamada y la primera vez que se llama estará vacío (nulo). Lo que nos permitirá registrar nuestro disparador. En triggerType indicamos que el disparador se invoca ANTES de la operación de publicación y solo afecta a los usuarios. Por supuesto, permitimos que los administradores del sistema publiquen todo. En triggerOptions detallamos las operaciones para las cuales se activará el disparador.

Y lo principal es devolver {exitState = “CANCEL”}, razón por la cual se desarrolló el disparador. Devolverá falla cuando el usuario intente compartir su imagen en el panel de control.

En la arquitectura FCO, cualquier objeto (disco, servidor, imagen, red, adaptador de red, etc.) se representa como una entidad de recurso, que tiene parámetros comunes:

  • UUID de recurso
  • nombre del recurso
  • tipo de recurso
  • UUID del propietario del recurso
  • estado del recurso (activo, inactivo)
  • metadatos de recursos
  • claves de recursos
  • UUID del producto propietario del recurso.
  • recurso VDC

Esto es muy conveniente cuando se trabaja con una API, cuando todos los recursos funcionan según el mismo principio. Los productos son configurados por el proveedor y solicitados por el cliente. Dado que nuestra facturación es lateral, el cliente puede pedir libremente cualquier producto desde el panel. Se calculará más adelante en la facturación. El producto puede ser una dirección IP por hora, un GB adicional de disco por hora o simplemente un servidor.

Las claves se pueden utilizar para marcar ciertos recursos y cambiar la lógica de trabajar con ellos. Por ejemplo, podemos marcar tres nodos físicos con la clave Peso y marcar algunos clientes con la misma clave, asignando así estos nodos personalmente a estos clientes. Usamos este mecanismo para clientes VIP a quienes no les gustan los vecinos al lado de sus máquinas virtuales. La funcionalidad en sí se puede utilizar mucho más ampliamente.

El modelo de licencia implica pagar por cada núcleo de procesador de un nodo físico. El costo también se ve afectado por la cantidad de tipos de clústeres. Si planea utilizar KVM y VMware juntos, por ejemplo, el costo de la licencia aumentará.

FCO es un producto completo, su funcionalidad es muy rica, por lo que planeamos preparar varios artículos a la vez con una descripción detallada del funcionamiento de la parte de red.

Habiendo trabajado con este orquestador durante varios años, podemos calificarlo como muy adecuado. Por desgracia, el producto no está exento de defectos:

  • tuvimos que optimizar la base de datos porque las consultas comenzaron a ralentizarse a medida que aumentaba la cantidad de datos en ellas;
  • después de un accidente, el mecanismo de recuperación no funcionó debido a un error y tuvimos que recuperar los autos de clientes desafortunados usando nuestro propio conjunto de scripts;
  • El mecanismo para detectar la indisponibilidad del nodo está integrado en el código y no se puede personalizar. Es decir, no podemos crear nuestras propias políticas para determinar la indisponibilidad de un nodo.
  • el registro no siempre es detallado. A veces, cuando necesitas bajar a un nivel muy bajo para comprender un problema en particular, no tienes suficiente código fuente para que algunos componentes comprendan el motivo;

Total: En general las impresiones del producto son buenas. Estamos en contacto constante con los desarrolladores del orquestador. Los muchachos están dispuestos a una cooperación constructiva.

A pesar de su simplicidad, FCO tiene una amplia funcionalidad. En futuros artículos planeamos profundizar en los siguientes temas:

  • networking en FCO
  • proporcionando recuperación en vivo y protocolo FQP
  • escribiendo tus propios complementos y widgets
  • conectar servicios adicionales como Load Balancer y Acronis
  • respaldo
  • Mecanismo unificado para configurar y configurar nodos.
  • Procesamiento de metadatos de máquinas virtuales.

ZY Escribe en los comentarios si estás interesado en otros aspectos. ¡Manténganse al tanto!

Fuente: habr.com

Añadir un comentario