Para ofrecer el servicio IaaS (Centro de Datos Virtual), utilizamos el orquestador comercial (FCO). Esta solución tiene una arquitectura bastante única que la diferencia de las conocidas Openstack y CloudStack.
Como hipervisores de nodos de computación, se soportan KVM, VmWare, Xen, Virtuozzo6/7, así como los contenedores de Virtuozzo. Los almacenes soportados incluyen local, NFS, Ceph y Virtuozzo Storage.
FCO soporta la creación de varios clústeres y su gestión desde una sola interfaz. Es decir, se puede gestionar un clúster de Virtuozzo y un clúster de KVM + Ceph alternando entre ellos con un clic del mouse.
En esencia, FCO es una solución integral para proveedores de nube, que además de la orquestación incluye facturación, con todas las configuraciones, plugins de pago, facturas, notificaciones, revendedores, tarifas y más. Sin embargo, la parte de facturación no puede cubrir todas las particularidades rusas, por lo que hemos decidido no utilizarla en favor de otra solución.
Nos alegra la flexible sistema de distribución de derechos sobre todos los recursos de la nube: imágenes, 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.
Desde el punto de vista arquitectónico, FCO está compuesto por varias partes, cada una con su propio código independiente, y algunas incluso con su propia base de datos.
Skyline – interfaz administrativa y de usuario
Jade – lógica de negocio, facturación, gestión de tareas
Tigerlily – coordinador del servicio, gestiona y coordina el intercambio de información entre la lógica de negocio y los clústeres.
XVPManager – gestión de elementos del clúster: nodos, almacenamiento, red y máquinas virtuales.
XVPAgent – agente instalado en los nodos para interactuar con XVPManager.
Planeamos incluir un relato detallado sobre la arquitectura de cada componente en una serie de artículos, si, por supuesto, el tema genera interés.
La principal ventaja de FCO proviene de su 'cajonera'. A su disposición la simplicidad y el minimalismo. Para el nodo gestor se asigna una máquina virtual en Ubuntu, en la que se instalan todos los paquetes necesarios. Todas las configuraciones se trasladan a archivos de configuración en forma de variable-valor:
# 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 modifica inicialmente en las plantillas, luego se ejecuta el generador
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Como se puede ver, la interfaz consiste en widgets, cuyo manejo está disponible para el usuario. Puede agregar/eliminar widgets de la página fácilmente, formando así el dashboard que necesita.
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:
- Se admiten complementos personalizados, por ejemplo, se puede escribir su propio método de facturación o un recurso externo para ofrecer al usuario
- Se admiten disparadores personalizados para ciertos eventos, como añadir la primera máquina virtual al cliente al crearlo
- Se admiten widgets personalizados en la interfaz, por ejemplo, integrar un video de YouTube directamente en la interfaz del usuario.
Toda la personalización se escribe en el lenguaje FDL, que se basa en Lua. Si conoce Lua, no tendrá problemas con FDL.
Aquí hay un ejemplo de uno de los disparadores más simples que utilizamos. Este disparador no permite a los usuarios compartir sus propias imágenes con otros clientes. Hacemos esto para que un usuario no pueda crear 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 register será llamada por el núcleo de FCO. Devolverá el nombre de la función que debe ser llamada. El parámetro 'p' de esta función contiene el contexto de la llamada, y en la primera llamada estará vacío (nil). Esto nos permitirá registrar nuestro disparador. En triggerType indicamos que el disparador se activa ANTES de la operación de publicación, 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á el disparador.
Y lo más importante: return {exitState = 'CANCEL'}, para lo que se desarrolló el disparador. Devolverá un fallo 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 Recurso, que tiene parámetros comunes:
- UUID del recurso
- nombre del recurso
- tipo de recurso
- UUID del propietario del recurso
- estado del recurso (activo, inactivo)
- metadatos del recurso
- claves del recurso
- UUID del producto al que pertenece el recurso
- VDC del recurso
Esto es muy conveniente al trabajar con API, ya que todos los recursos se manipulan de la misma manera. Los productos son configurados por el proveedor y los solicita el cliente. Dado que nuestra facturación está en otro lugar, el cliente puede solicitar libremente cualquier producto desde el panel. Su costo se calculará más tarde en la facturación. Un producto puede ser una dirección IP por hora, un GB adicional de disco por hora o simplemente un servidor.
Las claves se pueden usar para marcar ciertos recursos y modificar la lógica de interacción con ellos. Por ejemplo, podemos marcar tres nodos físicos con la clave Peso y a algunos clientes con esta misma clave, destacando así estos nodos para dichos clientes. Este mecanismo lo utilizamos para clientes VIP, que no les gusta tener vecinos cerca de sus VM. Sin embargo, la funcionalidad se puede aplicar de manera más amplia.
El modelo de licenciamiento implica el pago por cada núcleo del procesador del nodo físico. Además, el costo se ve afectado por la cantidad de tipos de clústeres. Si se planea usar KVM y VMware juntos, el costo de la licencia aumentará.
FCO es un producto completo, su funcionalidad es muy rica, por lo que planeamos preparar varios artículos con una descripción detallada del funcionamiento de la parte de red.
Después de trabajar con este orquestador durante varios años, podemos destacarlo como muy adecuado. Lamentablemente, el producto no está exento de defectos:
- tuvimos que optimizar la base de datos, ya que las consultas comenzaron a ralentizarse con el aumento de la cantidad de datos en ella;
- después de un accidente debido a un error, el mecanismo de recuperación no funcionó y tuvimos que levantar las máquinas de los desafortunados clientes con nuestro propio conjunto de scripts;
- el mecanismo de detección de la indisponibilidad de nodos está codificado 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 es necesario descender a un nivel muy bajo para analizar un problema específico, falta el código fuente de algunos componentes para entender las causas.
TOTAL: En general, las impresiones del producto son buenas. Mantenemos un contacto constante con los desarrolladores del orquestador. Los chicos están abiertos a la colaboración constructiva.
A pesar de su simplicidad, FCO tiene una amplia funcionalidad. En futuros artículos, planeamos profundizar en los siguientes temas:
- organización de la red en FCO
- provisión de recuperación en vivo y protocolo FQP
- escritura de plugins y widgets personalizados
- conexión de servicios adicionales, como Load Balancer y Acronis
- respaldo
- mecanismo unificado de configuración y ajuste de nodos
- procesamiento de metadatos de máquinas virtuales
P.D. Escriban en los comentarios si están interesados en otros aspectos. ¡Manténganse atentos!
Fuente: habr.com
