En travaillant dans l'informatique, vous commencez à remarquer que les systèmes ont leur propre caractère. Ils peuvent être flexibles, silencieux, excentriques et sévères. Ils peuvent attirer ou repousser. D'une manière ou d'une autre, il faut « négocier » avec eux, manœuvrer entre les « pièges » et construire des chaînes de leur interaction.
Nous avons donc eu l'honneur de construire une plate-forme cloud, et pour cela, nous devions « persuader » quelques sous-systèmes de travailler avec nous. Heureusement, nous avons un « langage API », des mains directes et beaucoup d’enthousiasme.
Cet article ne sera pas techniquement compliqué, mais décrira les problèmes que nous avons rencontrés lors de la construction du cloud. J'ai décidé de décrire notre parcours sous la forme d'une légère fantaisie technique sur la façon dont nous avons recherché un langage commun avec les systèmes et ce qui en a résulté.
Bienvenue au chat.
Début d'un voyage
Il y a quelque temps, notre équipe a été chargée de lancer une plateforme cloud pour nos clients. Nous disposions d'un soutien en matière de gestion, de ressources, d'une pile matérielle et de la liberté de choisir les technologies pour mettre en œuvre la partie logicielle du service.
Il y avait également un certain nombre d'exigences :
- le service a besoin d'un compte personnel pratique ;
- la plateforme doit être intégrée au système de facturation existant ;
- logiciel et matériel : OpenStack + Tungsten Fabric (Open Contrail), que nos ingénieurs ont assez bien appris à « cuisiner ».
Nous vous raconterons une autre fois comment l'équipe a été constituée, l'interface du compte personnel a été développée et les décisions de conception ont été prises, si la communauté Habra est intéressée.
Les outils que nous avons décidé d'utiliser :
- Python + Flask + Swagger + SQLAlchemy - un ensemble Python entièrement standard ;
- Vue.js pour le front-end ;
- Nous avons décidé de faire l'interaction entre les composants et les services en utilisant Celery sur AMQP.
En anticipant les questions sur le choix de Python, je vais vous expliquer. La langue a trouvé sa place dans notre entreprise et une petite culture s'est développée autour d'elle. Par conséquent, il a été décidé de commencer à construire le service sur cette base. De plus, la rapidité d’évolution de ces problèmes est souvent décisive.
Alors, commençons notre connaissance.
Silent Bill - facturation
Nous connaissons ce type depuis longtemps. Il s'asseyait toujours à côté de moi et comptait quelque chose en silence. Parfois, il nous transmettait les demandes des utilisateurs, émettait des factures clients et gérait des services. Un gars ordinaire qui travaille dur. Il est vrai qu’il y a eu des difficultés. Il est silencieux, parfois pensif et souvent seul.
La facturation est le premier système avec lequel nous avons essayé de nous lier d'amitié. Et la première difficulté que nous avons rencontrée a été lors du traitement des prestations.
Par exemple, lorsqu'elle est créée ou supprimée, une tâche est placée dans la file d'attente de facturation interne. Ainsi, un système de travail asynchrone avec les services est mis en œuvre. Pour traiter nos types de services, nous devions « mettre » nos tâches dans cette file d'attente. Et là, nous nous sommes heurtés à un problème : le manque de documentation.
À en juger par la description de l'API logicielle, il est toujours possible de résoudre ce problème, mais nous n'avons pas eu le temps de faire de l'ingénierie inverse, nous avons donc sorti la logique et organisé une file d'attente de tâches au-dessus de RabbitMQ. Une opération sur un service est initiée par le client depuis son compte personnel, se transforme en « tâche » Celery sur le backend et est réalisée côté facturation et OpenStack. Le céleri facilite la gestion des tâches, l'organisation des répétitions et le suivi de l'état. Vous pouvez en savoir plus sur le « céleri », par exemple, .
De plus, la facturation n’a pas arrêté un projet qui manquait d’argent. En communiquant avec les développeurs, nous avons découvert que lors du calcul des statistiques (et nous devons mettre en œuvre exactement ce type de logique), il existe une interrelation complexe des règles d'arrêt. Mais ces modèles ne correspondent pas bien à nos réalités. Nous l'avons également implémenté via des tâches sur Celery, en prenant la logique de gestion des services du côté backend.
Les deux problèmes ci-dessus ont rendu le code un peu gonflé et à l'avenir, nous devrons refactoriser afin de déplacer la logique de travail avec les tâches dans un service distinct. Nous devons également stocker certaines informations sur les utilisateurs et leurs services dans nos tables pour prendre en charge cette logique.
Un autre problème est le silence.
Billy répond silencieusement « Ok » à certaines requêtes API. Ce fut le cas, par exemple, lorsque nous avons effectué les paiements promis lors du test (nous y reviendrons plus tard). Les demandes ont été exécutées correctement et nous n’avons vu aucune erreur.
J'ai dû étudier les journaux tout en travaillant avec le système via l'interface utilisateur. Il s'est avéré que la facturation elle-même effectue des requêtes similaires, en modifiant la portée pour un utilisateur spécifique, par exemple admin, en la transmettant dans le paramètre su.
En général, malgré les lacunes de la documentation et les défauts mineurs de l'API, tout s'est plutôt bien passé. Les journaux peuvent être lus même sous une charge importante si vous comprenez comment ils sont structurés et ce qu'il faut rechercher. La structure de la base de données est ornée, mais tout à fait logique et même attrayante à certains égards.
Ainsi, pour résumer, les principaux problèmes que nous avons rencontrés au stade de l'interaction sont liés aux caractéristiques de mise en œuvre d'un système spécifique :
- des « caractéristiques » non documentées qui nous ont affectés d'une manière ou d'une autre ;
- source fermée (la facturation est écrite en C++), par conséquent - il est impossible de résoudre le problème 1 autrement que par « essais et erreurs ».
Heureusement, le produit dispose d'une API assez étendue et nous avons intégré les sous-systèmes suivants dans notre compte personnel :
- module d'assistance technique - les demandes de votre compte personnel sont « transmises » à la facturation de manière transparente pour les clients du service ;
- module financier - vous permet d'émettre des factures aux clients actuels, de procéder à des radiations et de générer des documents de paiement ;
- module de contrôle de service - pour cela, nous avons dû implémenter notre propre gestionnaire. L'évolutivité du système a fait notre jeu et nous avons « appris » à Billy un nouveau type de service.
C'était un peu compliqué, mais d'une manière ou d'une autre, je pense que Billy et moi allons nous entendre.
Marcher à travers les champs de tungstène – Tungsten Fabric
Des champs de tungstène parsemés de centaines de fils, qui transmettent des milliers de bits d'informations. Les informations sont collectées en « paquets », analysées, créant ainsi des itinéraires complexes, comme par magie.
C'est le domaine du deuxième système avec lequel nous avons dû nous lier d'amitié - Tungsten Fabric (TF), anciennement OpenContrail. Sa tâche est de gérer les équipements réseau, en nous fournissant une abstraction logicielle en tant qu'utilisateurs. TF - SDN, résume la logique complexe du travail avec les équipements réseau. Il existe un bon article sur la technologie elle-même, par exemple : .
Le système est intégré à OpenStack (discuté ci-dessous) via le plugin Neutron.
Interaction des services OpenStack.
Les gars du service des opérations nous ont présenté ce système. Nous utilisons l'API du système pour gérer la pile réseau de nos services. Cela ne nous a pas encore causé de problèmes ou d’inconvénients sérieux (je ne peux pas parler au nom des gars de l’OE), mais il y a eu quelques bizarreries dans l’interaction.
La première ressemblait à ceci : les commandes qui nécessitaient de transmettre une grande quantité de données à la console de l'instance lors de la connexion via SSH « raccrochaient » simplement la connexion, tandis que via VNC, tout fonctionnait correctement.
Pour ceux qui ne connaissent pas le problème, cela a l'air assez drôle : ls /root fonctionne correctement, tandis que, par exemple, top « se fige » complètement. Heureusement, nous avons déjà rencontré des problèmes similaires. Cela a été décidé en ajustant le MTU sur la route allant des nœuds de calcul aux routeurs. Soit dit en passant, ce n'est pas un problème de TF.
Le problème suivant était imminent. En un « beau » moment, la magie du routage a disparu, juste comme ça. TF a arrêté la gestion du routage sur les équipements.
Nous avons travaillé avec Openstack à partir du niveau administrateur, puis sommes passés au niveau utilisateur requis. Le SDN semble « détourner » la portée de l’utilisateur par lequel les actions sont effectuées. Le fait est que le même compte administrateur est utilisé pour connecter TF et OpenStack. A l’étape du passage à l’utilisateur, la « magie » a disparu. Il a été décidé de créer un compte distinct pour travailler avec le système. Cela nous a permis de travailler sans casser la fonctionnalité d'intégration.
Formes de vie en silicium - OpenStack
Une créature en silicone aux formes bizarres vit à proximité des champs de tungstène. Surtout, cela ressemble à un enfant trop grand qui peut nous écraser d'un seul coup, mais il n'y a aucune agressivité évidente de sa part. Il ne fait pas peur, mais sa taille inspire la peur. Tout comme la complexité de ce qui se passe autour.
OpenStack est le cœur de notre plateforme.
OpenStack possède plusieurs sous-systèmes, parmi lesquels nous utilisons actuellement le plus activement Nova, Glance et Cinder. Chacun d'eux possède sa propre API. Nova est responsable des ressources de calcul et de la création d'instances, Cinder est responsable de la gestion des volumes et de leurs instantanés, Glance est un service d'image qui gère les modèles de système d'exploitation et les métainformations qu'ils contiennent.
Chaque service s'exécute dans un conteneur et le courtier de messages est le « lapin blanc » - RabbitMQ.
Ce système nous a posé les problèmes les plus inattendus.
Et le premier problème ne s'est pas fait attendre lorsque nous avons tenté de connecter un volume supplémentaire au serveur. L'API Cinder a catégoriquement refusé d'effectuer cette tâche. Plus précisément, si l'on en croit OpenStack lui-même, la connexion est établie, mais il n'y a aucun périphérique disque à l'intérieur du serveur virtuel.
Nous avons décidé de faire un détour et avons demandé la même action à l'API Nova. Le résultat est que l'appareil se connecte correctement et est accessible au sein du serveur. Il semble que le problème se produise lorsque le stockage en bloc ne répond pas à Cinder.
Une autre difficulté nous attendait lorsque nous travaillions avec des disques. Le volume système n'a pas pu être déconnecté du serveur.
Encore une fois, OpenStack lui-même « jure » qu'il a détruit la connexion et vous pouvez désormais travailler correctement avec le volume séparément. Mais l'API ne voulait catégoriquement pas effectuer d'opérations sur le disque.
Ici, nous avons décidé de ne pas nous battre particulièrement, mais de changer notre vision de la logique du service. S'il existe une instance, il doit également y avoir un volume système. Par conséquent, l'utilisateur ne peut pas encore supprimer ou désactiver le « disque » système sans supprimer le « serveur ».
OpenStack est un ensemble de systèmes plutôt complexe doté de sa propre logique d'interaction et d'une API élaborée. Nous sommes aidés par une documentation assez détaillée et, bien sûr, par essais et erreurs (où en serions-nous sans cela).
Essai
Nous avons effectué un lancement test en décembre de l'année dernière. La tâche principale était de tester notre projet en mode combat du côté technique et du côté UX. Le public a été invité de manière sélective et les tests ont été clôturés. Cependant, nous avons également laissé la possibilité de demander l’accès aux tests sur notre site Internet.
Le test lui-même, bien sûr, n’a pas été sans moments amusants, car c’est là que nos aventures ne font que commencer.
Premièrement, nous avons quelque peu mal évalué l'intérêt du projet et avons dû ajouter rapidement des nœuds de calcul dès le test. Un cas courant pour un cluster, mais il y avait ici aussi quelques nuances. La documentation d'une version spécifique de TF indique la version spécifique du noyau sur laquelle le travail avec vRouter a été testé. Nous avons décidé de lancer des nœuds avec des noyaux plus récents. En conséquence, TF n’a pas reçu de routes des nœuds. J'ai dû restaurer les noyaux de toute urgence.
Une autre curiosité est liée à la fonctionnalité du bouton « changer le mot de passe » de votre compte personnel.
Nous avons décidé d'utiliser JWT pour organiser l'accès à notre compte personnel afin de ne pas travailler avec des sessions. Les systèmes étant divers et largement dispersés, nous gérons notre propre token, dans lequel nous « enveloppons » les sessions de facturation et un token d'OpenStack. Lorsque le mot de passe est modifié, le token, bien sûr, « se détériore », puisque les données utilisateur ne sont plus valides et doivent être réémises.
Nous avons perdu ce point de vue et il n’y avait tout simplement pas assez de ressources pour terminer rapidement cette pièce. Nous avons dû supprimer la fonctionnalité juste avant de lancer le test.
Actuellement, nous déconnectons l'utilisateur si le mot de passe a été modifié.
Malgré ces nuances, les tests se sont bien déroulés. En quelques semaines, environ 300 personnes sont passées par là. Nous avons pu regarder le produit à travers les yeux des utilisateurs, le tester en action et recueillir des retours de haute qualité.
se poursuivre
Pour beaucoup d’entre nous, il s’agit du premier projet de cette envergure. Nous avons appris un certain nombre de leçons précieuses sur la façon de travailler en équipe et de prendre des décisions en matière d'architecture et de conception. Comment intégrer des systèmes complexes avec peu de ressources et les mettre en production.
Bien sûr, il y a quelque chose à travailler tant au niveau du code qu'au niveau des interfaces d'intégration système. Le projet est assez jeune, mais nous sommes pleins d'ambitions pour en faire un service fiable et pratique.
Nous avons déjà réussi à convaincre les systèmes. Bill gère consciencieusement le comptage, la facturation et les demandes des utilisateurs dans son placard. La « magie » des champs de tungstène nous offre une communication stable. Et seul OpenStack devient parfois capricieux, criant quelque chose comme « 'WSREP n'a pas encore préparé le nœud pour l'utilisation de l'application ». Mais c'est une toute autre histoire...
Nous avons récemment lancé le service.
Vous pouvez découvrir tous les détails sur notre .
Équipe de développement CLO
Liens utiles
Pile ouverte
Tissu de tungstène
Source: habr.com