OpenStack: toute la vérité sur la sortie "royale"

Woland à M. Boulgakov a déclaré que "une brique sans raison ne tombera jamais sur la tête de qui que ce soit". Peut-être que oui, mais quand ils m'ont demandé il y a deux ans et demi si je voulais faire connaissance avec OpenStack, c'était cette brique très bien voilée (et même pas une brique, mais une dalle de granit au départ). C'est 2016 qui est devenu pour moi le soi-disant «point de non-retour», jetant les bases d'un développement rapide des concepts du monde ouvert et influençant de manière significative la mentalité, transformant ma vie future en vacances. "Holiday", qui est toujours avec moi.

2016 - aujourd'hui

OpenStack n'était pas un coup de foudre. La première version que j'ai déployée pour les tests était Kilo, qui rimait facilement avec le mot «triste». Ayant existé pendant exactement trois semaines, il espérait être remplacé par Liberty, qui, sous un emballage attrayant - les notes de version - n'était pas en mesure de répondre aux attentes élevées. Mitaka n'a pas tellement apporté de nouvelles fonctionnalités car il contenait beaucoup de corrections et de «correctifs», et est toujours (!) Utilisé avec succès dans des environnements productifs. Newton, en fait, a marqué un tournant dans l'histoire d'OpenStack, fournissant tant de modifications architecturales, logiques et, par conséquent, de configuration qui ont à jamais bloqué le chemin de mise à niveau de la version précédente pour de nombreux clouds privés. Mais c'est avec la sortie d'Ocata en 2017, selon les analystes , que «l'âge d'or» d'OpenStack a commencé, qui comprend Pike, Queens et, je l'espère sincèrement, Rocky, qui est en début de carrière, entrera.


Cet article se concentrera sur la dernière version stable d'OpenStack - Queens, sur certaines innovations et lacunes - du point de vue d'une personne qui automatisait son déploiement basé sur la distribution Ubuntu 16.04 LTS (et continue de le faire car il n'y a pas de limite à la perfection) .

Il n'y a pas tellement de matériel sur Queens sur le réseau (si vous excluez la documentation officielle et les rapports du récent OpenStack Summit à Vancouver de l'échantillon), et le nombre d'avis des fournisseurs de cloud et des intégrateurs de système peut être compté sur les doigts d'une main. Sans surprise, son prédécesseur - Pike, dont le support officiel durera encore huit mois - avec des centaines d'utilisateurs élaborés et une procédure de mise à niveau bien documentée, semble plus adapté à la mise en œuvre. Notre équipe, qui a suivi de près le processus de développement de Queens depuis le tout début, est allée plus loin que beaucoup et a lancé avec confiance le "nouveau" en production. Quelle était la profondeur du terrier du lapin?

(ci-après, la terminologie OpenStack sera largement utilisée; on suppose que le lecteur est au moins familier avec l'architecture typique)

Fonctionnalités utiles

1. Pour moi personnellement, un bon bonus dans la nouvelle version a été l'expansion de la fonctionnalité de l'utilitaire nova-manage: vous pouvez maintenant supprimer des hôtes de certaines cellules (Cells v2) et les transférer vers d'autres! Pike a dû écrire des requêtes de base de données distinctes, et maintenant il est disponible «prêt à l'emploi».
2. La création d'un rôle personnalisé (_membre_ par défaut) pour Keystone est «coupée» de la phase d'amorçage. La raison en était la transition finale vers l'API v3, qui a d'autres formes de mécanismes d'autorisation et d'authentification, ce qui augmente également la sécurité de l'infrastructure (après tout, il y avait aussi un identifiant fixe pour le rôle d'utilisateur ...) Cependant, cela ne signifie pas du tout que le rôle d'utilisateur n'est pas nécessaire - tôt ou vous devrez le créer plus tard.
   

   Prévision: à partir de cette version, Identity API v2 est obsolète; son soutien est susceptible de cesser complètement dans un an (pessimiste dans la version Stein).

3. Les agents Neutron l3 et dhcp ont eu l'opportunité de basculer automatiquement - la commutation automatique (redéfinition) des réseaux et des routeurs des agents éteints aux agents actifs. La fonctionnalité DVR HA est activée par défaut ( [DEFAULT]/router_distributed , [DEFAULT]/l3_ha ). DVR / SNAT est alloué dans un espace de noms séparé. Lors de la création d'un routeur, le snat est créé par défaut, en prenant une autre adresse IP du sous-réseau interne:
   
   Ce bundle vous permet de basculer rapidement du routeur actuel vers le routeur de sauvegarde de l'agent l3 exécuté sur un autre nœud en cas de défaillance du service SNAT.
4. Toutes les fonctionnalités de l'agent vpn de Neutron sont transférées à l'agent l3; dans sa config il faut faire le seul montage:
   
   

    [agent]/extensions = vpnaas 

   
   Enfin, la présence d'un agent vpn a cessé d'interférer avec la construction de la logique de déploiement automatique dans le cas de l'inclusion d'un rôle (auparavant, les agents vpn et l3 étaient mutuellement exclusifs: si vous mettez un package, l'autre est supprimé).
5. Glance-registry (proxy pour interagir avec la base de données dans l'API v1) a été déclaré un service obsolète, vous pouvez maintenant configurer et utiliser uniquement le service glance-api. Pas de surprise, mais elles seront discutées un peu plus tard.
6. Mamma mia! Le tableau de bord thermique est livré dans un emballage séparé (panneau de connexion) pour Horizon. Le plugin a subi de nombreuses modifications, mais la fonctionnalité la plus inattendue était ... de glisser-déposer des objets dans le processus de génération de modèles. Il est plus facile de voir une fois:
   
   
   
7. Ajout de la prise en charge du multi-attachement de volume dans Cinder - la possibilité de connecter un seul disque à plusieurs machines virtuelles. Jusqu'à présent, cette fonctionnalité n'a été mise en œuvre que pour un nombre limité de pilotes pris en charge par le service: LVM, NetApp / SolidFire, Dell EMC ScaleIO et Oracle ZFSSA - en fait, il s'agit d'un très grand pas en avant pour l'ensemble du projet (la mise en œuvre du mécanisme a pris plus de deux ans ).
   

   Prévision: pour Ceph RBD, la prise en charge du multi-attachement de volume Cinder n'a pas encore été annoncée; très probablement, il devrait être attendu au plus tôt dans un an (de manière optimiste - dans la version Stein).

Bugs ennuyeux

(Les bogues suivants ont été découverts lors du déploiement d'OpenStack Queens sur la distribution Ubuntu 16.04.4 LTS (Xenial Xerus); il est possible qu'ils n'apparaissent pas sur d'autres distributions Linux)

1. Dans la communauté Linux, il existe un «mainteneur» - un spécialiste qui maintient / maintient / dirige un certain composant logiciel (dans un cas particulier, un package binaire). Ainsi, les responsables d'Ubuntu ont à nouveau (un bug existait dans la version de Pike) fourni des packages pour le service de base de données chronologique régulier - Gnocchi. Les installer dans un environnement Python 2.7 via apt «rompt» certains des services associés fonctionnant sous libapache2-mod-wsgi: Keystone, Cinder, Nova Placement, Horizon. Le cas le plus triste est lorsque vous souhaitez utiliser une seule méthode de livraison de paquets au système. Cependant, alors que pour Gnocchi, ils ont au moins essayé de compiler des packages, pour Octavia, seuls pip et git existent toujours.
2. Je ne prétends pas le dire, mais peut-être que les mêmes responsables ont contribué à la création de packages nova-compute. Au moins, cela expliquerait pourquoi lorsqu'ils sont installés sur le système (assemblages de noyau 116, 119 et 124; versions de packages de 17.0.1 à 17.0.4), le programme d'installation «tombe» avec une erreur:
   
   

    Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ... adduser: The user 'nova' does not exist. dpkg: error processing package nova-compute-libvirt (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of nova-compute-kvm: nova-compute-kvm depends on nova-compute-libvirt (= 2:17.0.1-0ubuntu1~cloud0); however: Package nova-compute-libvirt is not configured yet. 

   
   Voici la chose: pendant l'installation, un script est exécuté qui devrait créer le groupe système nova et l'utilisateur du système nova. Le script échoue avec l'erreur, l'installation se bloque et une solution de contournement est ajoutée à l'automatisation: effectuez les gestes mentionnés avant d'installer les packages. Soit dit en passant, ce bogue n'est toujours pas fermé.
   

   UPD: en cours d'écriture de l'article, le bug a finalement été confirmé et a fixé la priorité moyenne. Au moment de résoudre le problème (les dépendances cycliques des packages Nova les uns par rapport aux autres), le mainteneur a proposé une autre solution: installez d'abord le package nova-common, puis nova-compute. Dans un avenir proche, nous pouvons nous attendre à la version des packages 17.0.5, dépourvue de cet inconvénient.

3. En testant le fonctionnement du service Neutron FWaaS, il s'est avéré que lorsqu'un pare-feu est supprimé d'un routeur distribué, rien ne se passe ... absolument. Le pare-feu passe de l'état "en ligne" à l'état éternel "en attente de suppression", et vous pouvez résoudre le problème en utilisant des requêtes dans la base de données ou en supprimant le routeur entier (ce bogue existait dans la version de Pike). Le principal problème pour le moment est que le correctif (qui résout vraiment!) A été proposé il y a quelques mois, mais n'a toujours pas atteint la dernière version stable.
4. Déjà au stade des tests de charge de l'infrastructure, il a été constaté que le "neutron-openvswitch-agent EATING CPU AAAAAAA" - en mode veille, l'openvswitch-agent a chargé l'un des cœurs de processeur à 100%:
   
   

    $ ps aux | grep 16233 neutron 16233 99.5 0.0 311112 143156 ? Rs 19:47 67:11 /usr/bin/python2 /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/openvswitch_agent.ini --log-file=/var/log/neutron/neutron-openvswitch-agent.log $ time strace -c -p 16233 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 0 95725 epoll_wait 0.00 0.000000 0 15 read 0.00 0.000000 0 6 open 0.00 0.000000 0 6 close 0.00 0.000000 0 6 stat 0.00 0.000000 0 15 fstat 0.00 0.000000 0 20 sendto 0.00 0.000000 0 79 41 recvfrom 0.00 0.000000 0 2 setsockopt 0.00 0.000000 0 94 epoll_ctl ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 95968 41 total real 0m10.300s user 0m0.324s sys 0m2.576s 

   
   La solution au problème a été trouvée par les développeurs du service dès que possible; Le correctif est fourni dans la version du package Neutron 12.0.1-0ubuntu1.1.

Royal Fakap

Dans OpenStack Queens, les développeurs ont introduit une nouvelle méthode de téléchargement d'images - le téléchargement Web, qui permet à l'utilisateur final de "télécharger" une image par référence. Il était une fois, alors que l'API Image v1 n'était pas encore obsolète et n'était pas remplacée par l'API v2, cette fonctionnalité existait. Il semblerait que ce qui aurait pu mal tourner? ..


Dans la configuration du service glance-api, les deux méthodes de chargement d'image - directement et par référence - sont activées par défaut ( [DEFAULT]/enabled_import_methods ). Dans la poursuite de l'objectif simple de tester l'option, j'éteins l'une des méthodes, surcharge le service et me précipite!

 CRITICAL glance [-] Unhandled error: ValueError: tuple.index(x): x not in tuple ERROR glance Traceback (most recent call last): ERROR glance File "/usr/bin/glance-api", line 10, in <module> ERROR glance sys.exit(main()) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 97, in main ERROR glance fail(e) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 71, in fail ERROR glance return_code = KNOWN_EXCEPTIONS.index(type(e)) + 1 ERROR glance ValueError: tuple.index(x): x not in tuple 

Après avoir bricolé le patch, je surcharge à nouveau le service:

 glance-api[26538]: ERROR: Value for option enabled_import_methods is not valid: Value should start with "[" systemd[1]: glance-api.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: glance-api.service: Unit entered failed state. systemd[1]: glance-api.service: Failed with result 'exit-code'. 

Sérieusement, ou quoi?! L'option dans la configuration a acquis la forme inadéquate suivante:

 [DEFAULT]/enabled_import_methods = [glance-direct] 

Bien sûr, un bug a été soigneusement ouvert par moi. Les développeurs au moment de résoudre le problème ont même publié une annonce sur ces problèmes connus, ils les connaissaient et ont envoyé un commit à la branche principale du projet. Deux mois après la découverte du bogue, le correctif «partait» pour une future version; les heureux propriétaires de Queens devront attendre les packages de Glance version 16.0.2.
Tout va bien qui finit bien.

"Ne perdez pas la tête, balancez vos muscles"

Au cours du travail d'automatisation du déploiement (impliquant également les étapes de configuration et de test fonctionnel), Queens s'est révélé fort, pas surchargé de nouvelles fonctionnalités, sans qu'une «béquille» ne dépasse de partout, mettant la barre haute pour son successeur.

Cependant, malgré le fait que Queens soit la dix-septième (!) Version OpenStack, la tendance générale se maintient depuis de nombreuses années: «l' imprévu n'est pas prévisible par une intuition imprévue ». Cette citation de la piste du projet Atlantida, à mon avis, décrit le mieux possible toute la gamme des sensations reçues en interagissant avec le produit. D'une part, le déploiement de services réguliers (Keystone, Glance, Swift, Cinder, Nova, Neutron, Horizon) avec des paramètres de base a longtemps été débogué et ne causera pas de problèmes, même pour un ingénieur débutant. D'un autre côté, quand il s'agit d'introduire des services relativement jeunes, les «vacances» susmentionnées commencent: triez-les comme vous le souhaitez dans la maigre documentation, préparez-vous à passer des jours à regarder le code et à vous asseoir sur le populaire traqueur de bogues.

Cependant, toutes ces souffrances ne sont qu'un effet secondaire du syndrome de Stockholm. Mais en fait, l'exercice à pile ouverte secoue le cerveau plus rapidement que n'importe quel jeu logique, développe des compétences utiles de manière exponentielle, se maintient constamment en bonne forme et ne vous laisse certainement pas vous ennuyer. OpenStack n'était certainement pas mon amour à première vue, réduit à la chaleur blanche et à l'évanouissement, mais il mérite définitivement un peu d'amour maintenant. Et si vous êtes prêt à toucher presque au toucher à travers l'obscurité des consoles, poussé par le besoin de vous réaliser (et d'améliorer un peu le monde open source), c'est peut-être votre voie.