Pour fournir le service IaaS (Virtual Data Center), chez
Rusonyx , nous utilisons l'orchestre commercial
Flexiant Cloud Orchestrator (FCO). Cette solution a une architecture assez unique, ce qui la distingue des plus connues du grand public Openstack et CloudStack.
En tant qu'hyperviseurs de nœuds de calcul, KVM, VmWare, Xen, Virtuozzo6 / 7, ainsi que des conteneurs du même Virtuozzo sont pris en charge. Des stockages pris en charge - local, NFS, Ceph et Virtuozzo Storage.
FCO prend en charge la création et la gestion de plusieurs clusters à partir d'une seule interface. Autrement dit, vous pouvez gérer le cluster Virtuozzo et le cluster KVM + Ceph en basculant entre eux en cliquant avec la souris.
En substance, 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, les plug-ins de paiement, les comptes, les notifications, les revendeurs, les tarifs, etc. Cependant, la partie facturation n'est pas en mesure de couvrir toutes les nuances russes, nous avons donc refusé de l'utiliser en faveur d'une autre solution.
Le système flexible de distribution des droits sur toutes les ressources cloud est très agréable: images, disques, produits, serveurs, pare-feu - tout cela peut être "fouillé" et octroyé des droits 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 à partir d'un seul panneau de contrôle.
Sur le plan architectural, FCO se compose de plusieurs parties, chacune ayant son propre code indépendant, et certaines ont sa propre base de données.
Skyline - interface administrateur et utilisateur
Jade - logique métier, facturation, gestion des tâches
Tigerlily est un coordinateur de services qui 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
Une histoire détaillée sur l'architecture de chaque composant que nous prévoyons d'intégrer dans une série d'articles, à moins, bien sûr, que le sujet ne vous intéresse.
Le principal avantage du FCO tient à sa «boîte». Il offre simplicité et minimalisme. 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 transférés dans des fichiers de configuration sous forme de 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" …
La configuration entière est corrigée initialement dans les modèles, puis le générateur démarre
# build-config qui formera le fichier vars et demandera aux services de relire la config. L'interface utilisateur est agréable et peut être facilement marquée.
Comme vous pouvez le constater, l'interface est constituée de widgets dont la gestion est à la disposition de l'utilisateur. Il peut facilement ajouter / supprimer des widgets de la page, formant ainsi le tableau de bord dont il a besoin.
Malgré sa proximité, 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 à fournir à l'utilisateur
- Les déclencheurs personnalisés pour certains événements sont pris en charge, par exemple, l'ajout de la première machine virtuelle au client lors de sa création
- Les widgets personnalisés sont pris en charge dans l'interface, par exemple, incorporer des vidéos de YouTube directement dans l'interface utilisateur.
Toute personnalisation est écrite dans le langage 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 le faisons afin qu'un utilisateur ne puisse pas 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 concours d'appel, et lors du premier appel il sera vide (nul). Cela nous permettra d'enregistrer notre déclencheur. Dans triggerType, nous montrons que le déclencheur est appelé AVANT l'opération de publication et s'applique uniquement aux utilisateurs. Pour les administrateurs système, bien sûr, nous autorisons la publication de tout. Dans triggerOptions, nous détaillons les opérations pour lesquelles le déclencheur se déclenchera.
Et surtout, renvoyez {exitState = "CANCEL"}, c'est pourquoi le déclencheur a été développé. Il renverra l'é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 a des paramètres communs:
- Uuid de ressource
- nom de la ressource
- type de ressource
- UUID du propriétaire de la ressource
- état des ressources (actif, inactif)
- métadonnées de ressource
- clés de ressource
- UUID du produit auquel appartient la ressource
- Ressource VDC
Ceci est très pratique lorsque vous travaillez sur l'API, lorsque le travail avec toutes les ressources est effectué sur le même principe. Les produits sont configurés par le fournisseur et le client les commande. Étant donné que notre facturation est en marge, le client peut commander n'importe quel produit du panneau librement et gratuitement. Il sera pris en compte plus tard dans la facturation. Le produit peut être - une adresse IP par heure, un Go supplémentaire de disque par heure ou simplement un serveur.
Vous pouvez marquer certaines ressources avec des clés pour changer la logique de travail avec elles. Par exemple, nous pouvons marquer trois nœuds physiques avec la clé Weight et marquer certains clients avec la même clé, mettant ainsi en surbrillance ces nœuds personnellement pour ces clients. Nous utilisons un tel mécanisme pour les clients VIP qui n'aiment pas les voisins à côté de leurs machines virtuelles. La fonctionnalité elle-même peut être appliquée beaucoup plus largement.
Le modèle de licence implique le paiement de chaque cœur d'un processeur d'un nœud physique. Le coût est également affecté par le nombre de types de cluster. Si vous prévoyez d'utiliser ensemble, par exemple, KVM et VMware, le coût de la licence augmentera.
FCO est un produit à part entière, sa fonctionnalité est très riche, 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 orchestre pendant plusieurs années, nous pouvons le marquer comme 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 ont commencé à ralentir à mesure que la quantité de données qu'elles contenaient augmentait;
- après un accident, dû à un bug, le mécanisme de récupération n'a pas fonctionné, et nous avons dû élever les machines de clients mécontents avec notre propre jeu de scripts;
- le mécanisme de détection d'inaccessibilité du nœud est câblé dans le code et ne peut pas être personnalisé. Autrement dit, nous ne pouvons pas créer nos propres politiques pour déterminer l'inaccessibilité d'un nœud.
- la journalisation n'est pas toujours détaillée. Parfois, lorsque vous devez descendre à un niveau très bas pour analyser un problème spécifique, le code source de certains composants n'est pas suffisant pour comprendre les raisons;
TOTAL: dans l' ensemble, l'expérience du produit est bonne. Nous sommes en contact permanent avec les développeurs de l'orchestre. Les gars sont arrangés pour une coopération constructive.
Malgré sa simplicité, FCO possède de nombreuses fonctionnalités. Dans les prochains articles, nous prévoyons d'explorer les sujets suivants:
- réseautage au FCO
- Live-Recovery et prise en charge du protocole FQP
- écrire des plugins et widgets personnalisés
- connexion de services supplémentaires tels que Load Balancer et Acronis
- sauvegarde
- mécanisme unifié de configuration et de configuration des nœuds
- traitement des métadonnées de la machine virtuelle
PS Écrivez dans les commentaires si d'autres aspects sont intéressants. Restez à l'écoute!