Pour fournir le service IaaS (Centre de données virtuel), nous chez utilisons un orchestrateur commercial (FCO). Cette solution possède une architecture suffisamment unique qui la distingue des solutions connues du grand public comme Openstack et CloudStack.
En tant qu'hyperviseurs pour les nœuds de calcul, nous supportons KVM, VMware, Xen, Virtuozzo6/7, ainsi que les conteneurs de Virtuozzo. Parmi les systèmes de stockage pris en charge, on trouve le stockage local, NFS, Ceph et Virtuozzo Storage.
FCO prend en charge la création et la gestion de plusieurs clusters à partir d'une seule interface. Cela signifie que vous pouvez gérer un cluster Virtuozzo et un cluster KVM + Ceph en basculant entre eux d'un simple clic de souris.
Essentiellement, FCO est une solution complète pour les fournisseurs de cloud, qui, en plus de l'orchestration, inclut également la facturation, avec toutes les configurations, les plugins de paiement, les factures, les notifications, les revendeurs, les tarifs, etc. Cependant, la partie facturation n'est pas capable de couvrir toutes les nuances russes, c'est pourquoi nous avons choisi de ne pas l'utiliser au profit d'une autre solution.
Nous sommes très satisfaits du système flexible de distribution des droits sur toutes les ressources du cloud : images, disques, produits, serveurs, pare-feu – tout cela peut être « partagé » et des droits peuvent être attribués entre les utilisateurs, et même entre les utilisateurs de différents clients. Chaque client peut créer plusieurs centres de données indépendants dans son cloud et les gérer depuis un seul tableau de bord.
Architecturalement, FCO est constitué de plusieurs parties, chacune ayant son propre code indépendant, et certaines même sa propre base de données.
Skyline – interface administrateur et utilisateur
Jade – logique métier, facturation, gestion des tâches
Tigerlily – coordinateur de service, gère et coordonne les échanges d'informations entre la logique métier et les clusters.
XVPManager – gestion des éléments du cluster : nœuds, stockage, réseau et machines virtuelles.
XVPAgent – agent installé sur les nœuds pour interagir avec XVPManager
Nous prévoyons d'inclure un récit détaillé de l'architecture de chaque composant dans une série d'articles, si bien sûr le sujet suscite de l'intérêt.
Le principal avantage de FCO réside dans son aspect « boîte ». Vous bénéficiez d'une simplicité et d'un minimalisme. Une machine virtuelle sous Ubuntu est dédiée à la nœud de gestion, sur laquelle tous les paquets nécessaires sont installés. Tous les réglages sont extraits dans des fichiers de configuration sous la forme de variable-valeur :
# 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"
…
Toute la configuration est initialement modifiée dans les modèles, puis le générateur est lancé.
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Comme vous pouvez le voir, l'interface se compose de widgets, dont la gestion est accessible à l'utilisateur. Il peut facilement ajouter ou supprimer des widgets de la page, créant ainsi le tableau de bord dont il a besoin.
Malgré sa nature fermée, FCO est un système très personnalisable. Il offre un grand nombre de réglages et de points d'entrée pour modifier le flux de travail :
- Des plugins personnalisés sont pris en charge, par exemple, vous pouvez écrire votre propre méthode de facturation ou une ressource externe pour fournir aux utilisateurs.
- Des déclencheurs personnalisés sont pris en charge pour certains événements, par exemple, l'ajout de la première machine virtuelle au client lors de sa création.
- Des widgets personnalisés sont supportés dans l'interface, par exemple, vous pouvez intégrer une vidéo de youtube directement dans l'interface utilisateur.
Toute la personnalisation est codée en FDL, qui est basé sur Lua. Si vous connaissez Lua, vous n'aurez aucun problème avec FDL.
Voici un exemple de l'un des déclencheurs les plus simples que nous utilisons. Ce déclencheur empêche les utilisateurs de partager leurs propres images avec d'autres clients. Nous faisons cela pour empêcher qu'un utilisateur puisse créer une image malveillante pour les autres utilisateurs.
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 fonction register sera appelée par le noyau FCO. Elle retournera le nom de la fonction à appeler. Le paramètre “p” de cette fonction contient le contexte d'appel, et lors du premier appel, il sera vide (nil). Cela nous permettra d'enregistrer notre déclencheur. Dans triggerType, nous indiquons que le déclencheur est appelé AVANT l'opération de publication et ne concerne que les utilisateurs. Bien sûr, nous permettons aux administrateurs du système de publier tout. Dans triggerOptions, nous détaillons les opérations pour lesquelles le déclencheur sera activé.
Et surtout – return {exitState = “CANCEL”}, c'est le but du déclencheur. Il retournera un échec lorsque l'utilisateur essaiera de partager son image dans le panneau de contrôle.
Dans l'architecture FCO, tout objet (disque, serveur, image, réseau, adaptateur réseau, etc.) est présenté sous la forme d'une entité Resource, qui a des paramètres communs :
- UUID de la ressource
- nom de la ressource
- type de ressource
- UUID du propriétaire de la ressource
- statut de la ressource (actif, inactif)
- métadonnées de la ressource
- clés de la ressource
- UUID du produit auquel appartient la ressource
- VDC de la ressource
C'est très pratique lors de l'utilisation de l'API, lorsque toutes les ressources sont manipulées selon le même principe. Les produits sont configurés par le fournisseur, et le client les commande. Comme notre facturation est séparée, le client peut commander librement et gratuitement n'importe quel produit depuis le panneau. Il sera comptabilisé plus tard dans la facturation. Un produit peut être – une adresse IP par heure, un gigaoctet de disque supplémentaire par heure ou simplement un serveur.
Les clés peuvent être utilisées pour marquer certaines ressources afin de modifier la logique de travail avec elles. Par exemple, nous pouvons marquer trois nœuds physiques avec la clé Weight, et marquer certains clients avec cette même clé, de sorte à attribuer ces nœuds spécifiquement à ces clients. Ce mécanisme est utilisé pour les clients VIP, qui n'aiment pas avoir de voisins à côté de leurs VM. La fonctionnalité peut cependant être appliquée de manière beaucoup plus large.
Le modèle de licence implique un paiement pour chaque cœur de processeur de nœud physique. De plus, le coût est influencé par le nombre de types de clusters. Si l'on prévoit d'utiliser ensemble, par exemple, KVM et VMware, le coût de la licence augmentera.
FCO est un produit complet, sa fonctionnalité est très riche, c'est pourquoi nous prévoyons de préparer plusieurs articles avec des descriptions détaillées du fonctionnement de la partie réseau.
Après avoir travaillé avec cet orchestrateur pendant plusieurs années, nous pouvons le qualifier de très bon. Malheureusement, le produit n'est pas sans défauts :
- nous avons dû optimiser la base de données, car les requêtes commençaient à ralentir avec l'augmentation de la quantité de données qu'elle contenait ;
- après un incident causé par un bug, le mécanisme de récupération n'a pas fonctionné, et nous avons dû restaurer les machines des malheureux clients avec notre propre ensemble de scripts ;
- le mécanisme de détection d'indisponibilité d'un nœud est codé en dur et ne peut pas être personnalisé. Cela signifie que nous ne pouvons pas créer nos propres politiques de détection d'indisponibilité des nœuds.
- La journalisation n'est pas toujours détaillée. Parfois, lorsqu'il faut descendre à un niveau très bas pour analyser un problème spécifique, il manque le code source de certains composants pour comprendre les causes.
TOTAL: Dans l'ensemble, les impressions sur le produit sont bonnes. Nous sommes en contact permanent avec les développeurs de l'orchestrateur. Les gars sont ouverts à une coopération constructive.
Malgré sa simplicité, FCO possède une large fonctionnalité. Dans de futurs articles, nous prévoyons d'approfondir les sujets suivants :
- l'organisation du réseau dans FCO
- la garantie de la récupération en direct et du protocole FQP
- l'écriture de plugins et de widgets personnalises
- la connexion de services supplémentaires tels que Load Balancer et Acronis
- sauvegarde
- un mécanisme unifié de configuration et de paramétrage des nœuds
- le traitement des métadonnées des machines virtuelles
P.S. N'hésitez pas à commenter si d'autres aspects vous intéressent. Restez à l'écoute !
Source : habr.com
