Pour fournir des services IaaS (Virtual Data Center), nous nous utilisons un orchestrateur commercial (FCO). Cette solution possède une architecture assez unique, qui la distingue d’Openstack et CloudStack, connus du grand public.
KVM, VmWare, Xen, Virtuozzo6/7, ainsi que les conteneurs du même Virtuozzo sont pris en charge en tant qu'hyperviseurs de nœuds de calcul. Les options de stockage prises en charge incluent le stockage local, NFS, Ceph et Virtuozzo.
FCO prend en charge la création et la gestion de plusieurs clusters à partir d'une seule interface. Autrement dit, vous pouvez gérer un cluster Virtuozzo et un cluster KVM + Ceph en basculant entre eux d'un simple clic de souris.
À la base, FCO est une solution complète pour les fournisseurs de cloud qui, en plus de l'orchestration, comprend également la facturation, avec tous les paramètres, plugins de paiement, factures, notifications, revendeurs, tarifs, etc. Cependant, la partie facturation n’est pas capable de couvrir toutes les nuances russes, nous avons donc abandonné son utilisation au profit d’une autre solution.
Je suis très satisfait du système flexible de répartition des droits sur toutes les ressources cloud : images, disques, produits, serveurs, pare-feu - tout cela peut être « partagé » et accordé des droits entre utilisateurs, et même entre 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 panneau de contrôle.
Sur le plan architectural, FCO se compose de plusieurs parties, chacune possédant son propre code indépendant, et certaines possédant leur propre base de données.
Ligne d'horizon – interface administrateur et utilisateur
Jade – logique métier, facturation, gestion des tâches
Tigerlily – coordinateur de services, gère et coordonne l’échange 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 – un agent installé sur les nœuds pour interagir avec XVPManager
Nous prévoyons d'inclure une histoire détaillée sur 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 du FCO vient de sa nature « en boîte ». La simplicité et le minimalisme sont à votre service. Pour le nœud de contrôle, une machine virtuelle sur Ubuntu est allouée, dans laquelle tous les packages nécessaires sont installés. Tous les paramètres sont placés dans des fichiers de configuration sous la forme d'une valeur 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"
…
L'ensemble de la configuration est dans un premier temps édité dans des templates, puis le générateur est lancé
#build-config qui générera un fichier vars et ordonnera aux services de relire la configuration. L'interface utilisateur est agréable et peut être facilement personnalisée.
Comme vous pouvez le constater, l'interface est constituée de widgets pouvant être contrôlés par l'utilisateur. Il peut facilement ajouter/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 hautement personnalisable. Il dispose d'un grand nombre de paramètres et de points d'entrée pour modifier le flux de travail :
- Les plugins personnalisés sont pris en charge, par exemple, vous pouvez écrire votre propre méthode de facturation ou votre propre ressource externe pour fournir à l'utilisateur
- Des déclencheurs personnalisés pour certains événements sont pris en charge, par exemple l'ajout de la première machine virtuelle à un client lors de sa création.
- Les widgets personnalisés dans l'interface sont pris en charge, par exemple l'intégration d'une vidéo YouTube directement dans l'interface utilisateur.
Toute personnalisation est écrite en FDL, basé sur Lua. Si vous connaissez Lua, il n'y aura aucun problème avec FDL.
Voici un exemple de l’un des déclencheurs les plus simples que nous utilisons. Ce déclencheur ne permet pas aux utilisateurs de partager leurs propres images avec d'autres clients. Nous faisons cela pour empêcher un utilisateur de créer une image malveillante pour d'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 de registre sera appelée par le noyau FCO. Il renverra le nom de la fonction à appeler. Le paramètre « p » de cette fonction stocke le contexte d'appel, et la première fois qu'elle sera appelée, il sera vide (nil). Ce qui nous permettra d'enregistrer notre déclencheur. Dans triggerType, nous indiquons que le déclencheur est invoqué AVANT l'opération de publication et n'affecte que les utilisateurs. Bien entendu, nous permettons aux administrateurs système de tout publier. Dans triggerOptions, nous détaillons les opérations pour lesquelles le déclencheur se déclenchera.
Et l'essentiel est return {exitState = « CANCEL »}, c'est pourquoi le déclencheur a été développé. Il renverra un échec lorsque l’utilisateur tentera de partager son image dans le panneau de configuration.
Dans l'architecture FCO, tout objet (disque, serveur, image, réseau, adaptateur réseau, etc.) est représenté comme une entité ressource, qui possède des paramètres communs :
- UUID de la ressource
- nom de la ressource
- type de ressource
- UUID du propriétaire de la ressource
- état de la ressource (actif, inactif)
- métadonnées des ressources
- clés de ressources
- UUID du produit propriétaire de la ressource
- ressource VDC
C'est très pratique lorsque l'on travaille avec une API, lorsque toutes les ressources fonctionnent selon le même principe. Les produits sont configurés par le fournisseur et commandés par le client. Puisque notre facturation se fait à côté, le client peut commander librement n’importe quel produit du panel. Il sera calculé ultérieurement lors de la facturation. Le produit peut être une adresse IP par heure, un Go 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 leur utilisation. Par exemple, nous pouvons marquer trois nœuds physiques avec la clé Weight, et marquer certains clients avec la même clé, attribuant ainsi personnellement ces nœuds à ces clients. Nous utilisons ce mécanisme pour les clients VIP qui n'aiment pas les voisins à côté de leurs VM. La fonctionnalité elle-même peut être utilisée beaucoup plus largement.
Le modèle de licence implique de payer pour chaque cœur de processeur d'un nœud physique. Le coût est également affecté par le nombre de types de clusters. Si vous envisagez d'utiliser KVM et VMware ensemble, par exemple, le coût de la licence augmentera.
FCO est un produit à part entière, ses fonctionnalités sont très riches, nous prévoyons donc de préparer plusieurs articles à la fois avec une description détaillée du fonctionnement de la partie réseau.
Ayant travaillé avec cet orchestrateur pendant plusieurs années, nous pouvons le qualifier de très approprié. Hélas, le produit n'est pas sans défauts :
- nous avons dû optimiser la base de données car les requêtes commençaient à ralentir à mesure que la quantité de données qu'elles contenaient augmentait ;
- après un accident, le mécanisme de récupération n'a pas fonctionné à cause d'un bug, et nous avons dû récupérer les voitures de clients malheureux en utilisant notre propre ensemble de scripts ;
- Le mécanisme de détection de l’indisponibilité des nœuds est intégré au code et ne peut pas être personnalisé. Autrement dit, nous ne pouvons pas créer nos propres politiques pour déterminer l'indisponibilité d'un nœud.
- la journalisation n’est pas toujours détaillée. Parfois, lorsqu'il faut descendre à un niveau très bas pour comprendre un problème particulier, on ne dispose pas de suffisamment de code source pour que certains composants comprennent pourquoi ;
TOTAL: En général, les impressions du produit sont bonnes. Nous sommes en contact permanent avec les développeurs d'orchestrateurs. Les gars sont disposés à une coopération constructive.
Malgré sa simplicité, FCO possède de nombreuses fonctionnalités. Dans les prochains articles, nous prévoyons d’approfondir les sujets suivants :
- réseautage chez FCO
- fournissant une récupération en direct et un protocole FQP
- écrire vos propres plugins et widgets
- connecter des services supplémentaires tels que Load Balancer et Acronis
- sauvegarde
- mécanisme unifié pour la configuration et la configuration des nœuds
- traitement des métadonnées de la machine virtuelle
ZY Écrivez dans les commentaires si d'autres aspects vous intéressent. Restez à l'écoute!
Source: habr.com