OpenNebula. Notes rapides

Bonjour à tous. Cet article s'adresse à ceux qui hésitent encore entre les choix de plateformes de virtualisation et après avoir lu un article de la série « Nous avons installé proxmox et tout fonctionne parfaitement, 6 ans de disponibilité sans aucune interruption ». Cependant, après avoir installé une solution prête à l'emploi, une question se pose : comment ajuster ici et là pour que la surveillance soit plus claire, et là pour contrôler les sauvegardes... Puis vient le moment où vous réalisez que vous souhaitez quelque chose de plus fonctionnel, ou il vous faut que votre système soit totalement compréhensible, et non cet abaque noir, ou vous voulez utiliser autre chose qu'un hyperviseur et une multitude de machines virtuelles. Cet article présentera quelques réflexions et de la pratique basée sur la plateforme Opennebula — j'ai choisi cela car elle n'est pas gourmande en ressources et son architecture n'est pas trop complexe.

Ainsi, comme nous le voyons, de nombreux fournisseurs de cloud opèrent sur KVM et construisent une interface externe pour gérer les machines. Il est évident que les grands hébergeurs développent leurs propres interfaces pour l'infrastructure cloud, YANDEX par exemple. Certains utilisent OpenStack et construisent une interface sur cette base — SELECTEL, MAIL.RU. Mais si vous avez votre propre matériel et une petite équipe de spécialistes, vous choisissez généralement quelque chose de prêt à l'emploi — VMWARE, HYPER-V, avec des licences gratuites et payantes, mais ce n'est pas de cela dont nous allons parler maintenant. Parlons des passionnés — ce sont ceux qui n'ont pas peur de proposer et d'essayer de nouvelles choses, même si dans l'entreprise, on a clairement fait comprendre : « Qui va s'en occuper après vous ? », « Est-ce que nous allons vraiment le mettre en production plus tard ? Ça fait peur. » Mais on peut commencer par appliquer ces solutions dans un environnement de test et si tout le monde est satisfait, on peut alors discuter d'un développement ultérieur et de leur utilisation dans des environnements plus sérieux.

Voici également un lien vers la présentation. www.youtube.com/watch?v=47Mht_uoX3A d'un participant actif au développement de cette plateforme.

Il est possible que cet article contienne des éléments superflus et évidents pour un spécialiste expérimenté, et dans certains cas, je ne décrirai pas tout, car des commandes similaires et des descriptions se trouvent sur le Web. Ici, je partage uniquement mon expérience avec cette plateforme. J'espère que les participants actifs compléteront dans les commentaires ce qui peut être amélioré et quelles erreurs j'ai pu commettre. Toutes les actions se sont déroulées dans un environnement domestique composé de 3 PC avec différentes caractéristiques. De plus, j'ai délibérément évité de préciser comment fonctionne ce logiciel et comment l'installer. Non, il s'agit uniquement de mon expérience d'administration et des problèmes auxquels j'ai été confronté. Peut-être que cela sera utile à quelqu'un dans son choix.

Alors, commençons. Pour moi, en tant qu'administrateur système, les points suivants sont importants, sans lesquels je ne vais probablement pas utiliser cette solution.

1. Répétabilité de l'installation

Il existe une multitude de guides d'installation pour opennebula, cela ne devrait pas poser de problème. D'une version à l'autre, de nouvelles fonctionnalités apparaissent et ne fonctionneront pas toujours lors de la mise à niveau.

2. Surveillance

Nous allons surveiller le nœud lui-même, kvm et opennebula. Heureusement, il y a déjà des solutions toutes faites. Pour la surveillance des hôtes Linux, il existe de nombreuses options, comme Zabbix ou Node Exporter — à chacun ses préférences — je considère actuellement que la surveillance des métriques système (température où cela peut être mesuré, cohérence du tableau de disques) se fait via Zabbix, tandis que ce qui concerne les applications est traité par un exporter vers Prometheus. Pour la surveillance de kvm, par exemple, on peut utiliser le projet github.com/zhangjianweibj/prometheus-libvirt-exporter.git et le lancer avec systemd, cela fonctionne plutôt bien et montre les métriques de kvm, il existe également un tableau de bord prêt à l'emploi. grafana.com/grafana/dashboards/12538.

Par exemple, voici mon fichier :

/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter

[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"

[Install]
WantedBy=multi-user.target

Et donc, nous avons un exporter, il nous faut un second pour surveiller opennebula lui-même, j'ai utilisé celui-ci github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

On peut l'ajouter au normal node_exporter pour la surveillance du système ci-après.

Dans le fichier de node_exporter, nous modifions le démarrage comme suit :

ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collector

Créons le répertoire mkdir -p /var/lib/opennebula_exporter

Le script bash présenté ci-dessus doit d'abord être testé via la console, s'il affiche ce qu'il faut (s'il donne une erreur, nous installons xmlstarlet), nous le copions dans /usr/local/bin/opennebula_exporter.sh.

Ajoutons une tâche cron pour chaque minute :

*\/1 * * * * (\/usr\/local\/bin\/opennebula_exporter.sh > \/var\/lib\/opennebula_exporter\/textfile_collector\/opennebula.prom)

Les métriques commencent à apparaître, on peut les récupérer avec Prometheus, construire des graphiques et créer des alertes. Dans Grafana, par exemple, on peut dessiner un tableau de bord simple.

(on voit que j'ai ici fait un overcommit CPU, RAM)

Pour ceux qui aiment et utilisent Zabbix, il y a github.com\/OpenNebula\/addon-zabbix

Pour la surveillance, c'est tout, l'essentiel est qu'elle existe. Bien sûr, on peut en complément utiliser les outils de surveillance intégrés des machines virtuelles et exporter les données vers la facturation, chacun a sa propre vision, je n'y ai pas encore beaucoup réfléchi.

Concernant la journalisation, je n'ai pas encore vraiment commencé. La solution la plus simple est d'ajouter td-agent pour parser le répertoire \/var\/lib\/one avec des expressions régulières. Par exemple, le fichier sunstone.log correspond à la regexp de nginx et d'autres fichiers qui montrent l'historique des interactions avec la plateforme — quel est l'avantage ? Eh bien, par exemple, on peut clairement suivre le nombre d'« Erreur, erreur » et repérer plus rapidement où et à quel niveau se trouve le problème.

3. Sauvegardes

Il existe aussi des projets payants évolués — par exemple sep wiki.sepsoftware.com\/wiki\/index.php\/4_4_3_Tigon:OpenNebula_Backup. Ici, nous devons comprendre qu'il ne suffit pas de sauvegarder l'image de la machine, car nos machines virtuelles doivent fonctionner avec une intégration complète (le même fichier de contexte, dans lequel sont décrites les paramètres réseau, le nom de la VM et les paramètres personnalisés pour vos applications). Donc ici, nous déterminons quoi et comment nous allons sauvegarder. Dans certains cas, il est préférable de faire des copies de ce qui se trouve dans la VM elle-même. Et peut-être que nous devons sauvegarder seulement un disque de cette machine.

Par exemple, nous avons décidé que toutes les machines démarrent avec des images persistantes, donc en lisant docs.opennebula.io\/5.12\/operation\/vm_management\/img_guide.html

cela signifie qu'on peut d'abord exporter l'image de notre VM :

onevm disk-saveas 74 3 prom.qcow2
Image ID: 77

Voyons sous quel nom elle a été enregistrée

oneimage show 77
\/var\/lib\/one\/\/datastores\/100\/f9503161fe180658125a9b32433bf6e8
   
Et ensuite, nous copions où nous en avons besoin. Bien sûr, c'est une méthode peu pratique. Je voulais juste montrer qu'en utilisant des outils OpenNebula, on peut construire de telles solutions.

J'ai également trouvé une présentation intéressante et il y a encore un projet open-source, mais celui-ci ne supporte que le stockage qcow2.

Mais comme nous le savons tous, tôt ou tard vient le moment où l'on souhaite des sauvegardes incrémentielles. C'est ici que cela devient plus compliqué, et il se peut que la direction débloque des fonds pour une solution payante, ou qu'on opte pour une autre voie, en comprenant que nous utilisons uniquement des ressources, et que la sauvegarde doit se faire au niveau des applications en ajoutant un nombre croissant de nouveaux nœuds et de machines virtuelles. Oui, ici, je parle de l'utilisation du cloud uniquement pour le lancement de clusters d'applications, tandis que les bases de données doivent être lancées sur une autre plateforme ou il faudrait adopter une solution prête à l'emploi de fournisseur, si cela est possible.

4. Facilité d'utilisation

Dans ce point, je vais décrire les problèmes auxquels j'ai été confronté. Par exemple, pour les images, comme nous le savons, il y a persistent : lors du montage de cette image à une VM, toutes les données sont enregistrées dans cette image. Et si c'est non-persistent, alors l'image est copiée sur le stockage et les données sont écrites dans ce qui a été copié de l'image source. C'est ainsi que fonctionnent les modèles de préparation. Je me suis souvent créé des problèmes en oubliant de spécifier persistent, et les 200 Go de l'image étaient copiés. Le problème est qu'il est certainement impossible d'annuler cette procédure, il faut aller sur le nœud et arrêter le processus actuel « cp ».

Un des inconvénients majeurs est qu'on ne peut pas annuler les actions simplement en utilisant l'interface graphique. En fait, vous les allez annuler, et vous verrez que rien ne se passe, et vous recommencerez. Vous annulez, et en réalité, il y aura déjà deux processus cp qui copient l'image.

Et là vient la compréhension, pourquoi OpenNebula numérote chaque nouvelle instance avec un nouvel ID. Par exemple, dans Proxmox, vous créez une VM avec l'ID 101, vous la supprimez, puis vous la recréez et elle obtient l'ID 101. Dans OpenNebula, cela ne se produira pas, chaque nouvelle instance sera créée avec un nouvel ID, et cela a sa propre logique — par exemple, pour nettoyer les anciennes données ou les installations ratées.

Il en va de même pour le stockage, cette plateforme est principalement axée sur le stockage centralisé. Il existe des addons pour l'utilisation de stockage local, mais ce n'est pas de cela dont il s'agit ici. Je pense qu'à l'avenir, quelqu'un écrira un article sur la façon dont il a réussi à utiliser le stockage local sur les nœuds et à l'utiliser avec succès en production.

5. Simplicité maximale

Bien sûr, plus vous avancez, moins vous trouvez de personnes qui vous comprendront.

Dans le cadre de mon environnement — 3 nœuds avec un stockage NFS — tout fonctionne bien. Mais si nous effectuons des expériences de coupure d'énergie, par exemple lors du lancement d'un instantané et d'une coupure d'alimentation du nœud, nous conservons les paramètres dans la base de données, indiquant qu'il existe un instantané, alors qu'en réalité, il n'existe pas (nous comprenons tous que l'action a été initialement enregistrée dans la base de données SQL, mais l'opération n'a pas été réussie). En revanche, lors de la création d'un instantané, un fichier distinct est généré avec un « parent », donc en cas de problème, même si l'interface graphique ne fonctionne pas, nous pouvons récupérer le fichier qcow2 et restaurer séparément. docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

Concernant les réseaux, malheureusement, ce n'est pas si simple. Enfin, c'est tout de même plus simple qu'avec OpenStack, j'ai utilisé uniquement VLAN (802.1Q) — cela fonctionne plutôt bien, mais si vous faites des modifications dans les paramètres du template réseau, ces paramètres ne s'appliqueront pas aux machines déjà fonctionnelles, c'est-à-dire qu'il faut supprimer et réajouter la carte réseau pour appliquer les nouveaux paramètres.

Si nous voulons comparer avec OpenStack, on peut dire qu'OpenNebula n'a pas de définition claire des technologies à utiliser pour le stockage des données, la gestion du réseau et des ressources — chaque administrateur décide lui-même de la manière qui lui convient le mieux.

6. Plugins et installations supplémentaires

En effet, comme nous le savons, la plateforme cloud peut gérer non seulement KVM, mais aussi VMware ESXi. Malheureusement, je n'avais pas de pool avec VCenter, si quelqu'un a essayé, faites-le savoir.

Il a été annoncé dans le support d'autres fournisseurs de cloud docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

J'ai également essayé de connecter VMware Cloud de Selectel, mais cela n'a pas fonctionné — en résumé, j'ai abandonné car il y a trop de facteurs, et il n'est pas utile d'écrire au support technique de l'hébergeur.

De plus, dans la nouvelle version, il y a Firecracker — il s'agit de lancer des microVM, un type de wrapper KVM sur Docker, ce qui offre encore plus de polyvalence, de sécurité et d'augmentation des performances car il n'est pas nécessaire de gaspiller des ressources pour émuler le matériel. Je ne vois que des avantages par rapport à Docker dans le sens où cela ne consomme pas de processus supplémentaires et qu'il n'y a pas de sockets occupés lors de l'utilisation de cette émulation, donc cela peut tout à fait être utilisé comme équilibreur de charge (mais cela mérite probablement un article séparé, car je n'ai pas encore réalisé tous les tests pleinement).

7. Expérience positive d'utilisation et débogage des erreurs

Je voulais partager mes observations sur le fonctionnement, j'ai décrit une partie ci-dessus, mais je souhaite en écrire davantage. En réalité, je ne suis probablement pas le seul à penser au départ que ce n'est pas le bon système et que tout est bricolé ici — comment cela fonctionne-t-il vraiment ? Mais ensuite, on arrive à comprendre que tout cela a du sens. Bien sûr, il est impossible de plaire à tout le monde et certains aspects nécessitent des ajustements.

Par exemple, une opération simple de copie d'image de disque d'un datastore à un autre. Dans mon cas, il y a 2 nœuds avec NFS, j'envoie l'image — la copie se fait via le frontend OpenNebula, alors que nous avons tous l'habitude de copier les données directement entre les hôtes — dans VMware ou Hyper-V, c'est exactement cela, mais ici c'est différent. Ici, la démarche et l'idéologie sont autres, et dans la version 5.12, le bouton « migrer vers le datastore » a été supprimé — seule la machine elle-même est déplacée, mais pas le stockage, car un stockage centralisé est supposé.

Ensuite, une erreur fréquente avec différentes raisons « Erreur lors du déploiement de la machine virtuelle : Impossible de créer un domaine depuis /var/lib/one//datastores/103/10/deployment.5 » Ci-dessous, il y aura un top, il faut regarder.

• Les autorisations sur l'image pour l'utilisateur oneadmin;
• Les autorisations pour l'utilisateur oneadmin pour démarrer libvirtd;
• Le datastore est-il monté correctement ? Allez vérifier le chemin sur le nœud lui-même, il est possible que quelque chose ait été déconnecté ;
• Réseau mal configuré, en effet sur le frontend les paramètres réseau indiquent que le br0 est comme interface principale pour le VLAN, alors que sur le nœud il est indiqué — bridge0 — il faut que ce soit identique.

Le datastore système stocke les métadonnées de votre VM, si vous lancez une VM avec une image persistante, il est nécessaire que la VM ait accès à la configuration initialement créée sur le stockage où vous avez créé la VM — c'est très important. Donc, lors du transfert de la VM vers un autre datastore, tout doit être vérifié à nouveau.

8. Documentation, communauté. Développement futur

Et d'autres aspects, une bonne documentation, une communauté et surtout que le projet continue à vivre.

Dans l'ensemble, tout est plutôt bien documenté et même selon la source officielle, il ne sera pas difficile de l'installer et de trouver des réponses aux questions.

Communauté active. Publie de nombreuses solutions prêtes à l'emploi que vous pouvez utiliser dans vos installations.

Actuellement, avec la version 5.12, certaines politiques dans l'entreprise ont changé. forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Il sera intéressant de voir comment le projet va évoluer. Au début, j'ai spécifiquement mentionné certains fournisseurs qui utilisent leurs propres solutions et ce que propose l'industrie. Bien sûr, il n'y a pas de réponse claire à ce que vous devriez utiliser. Mais pour les petites organisations, le maintien de leur propre petit cloud privé peut s'avérer moins coûteux que cela ne paraît. L'essentiel est de savoir exactement ce dont vous avez besoin.

En fin de compte, peu importe ce que vous choisissez comme système cloud, il ne faut pas s'en tenir à un seul produit. Si vous avez le temps, il vaut la peine de se pencher sur d'autres solutions plus ouvertes.

Il y a un bon petit chat t.me/opennebula ils aident activement et ne vous envoient pas chercher une solution sur Google. Rejoignez-nous.

Source : habr.com