Avec l'expérience dans le secteur IT, on commence à réaliser que les systèmes ont leur propre caractère. Ils peuvent être dociles, silencieux, capricieux ou austères. Ils peuvent attirer ou repousser. Quoi qu'il en soit, il faut "négocier" avec eux, naviguer entre les "pièges" et établir des chaînes d'interaction.
Nous avons donc eu l'honneur de construire une plateforme cloud, et pour cela, il a fallu "convaincre" quelques sous-systèmes de travailler avec nous. Heureusement, nous avons notre "langage API", des mains habiles et une grande dose d'enthousiasme.
Cet article n'abordera pas le côté technique hardcore, mais décrira les problèmes auxquels nous avons été confrontés lors de la construction du cloud. J'ai décidé de narrer notre parcours sous la forme d'une légère fantaisie technique sur comment nous avons cherché un langage commun avec les systèmes et ce qu'il en est ressorti.
Bienvenue sous le capot.
Le début du parcours
Il y a quelque temps, notre équipe a reçu pour mission de lancer une plateforme cloud pour nos clients. Nous avions le soutien de la direction, des ressources, une infrastructure matérielle et la liberté de choisir les technologies pour la mise en œuvre du logiciel.
Il y avait aussi quelques exigences :
- le service doit disposer d'un espace client convivial ;
- la plateforme doit être intégrée dans le système de facturation existant ;
- la partie logicielle et matérielle : OpenStack + Tungsten Fabric (Open Contrail), que nos ingénieurs ont appris à "préparer" assez bien.
Nous parlerons de la manière dont l'équipe s'est constituée, de la conception de l'interface de l'espace client et des décisions de design lors d'une autre occasion, si la communauté Habr en montre l'intérêt.
Les outils que nous avons décidé d'utiliser :
- Python + Flask + Swagger + SQLAlchemy — un ensemble Python tout à fait standard ;
- Vue.js pour le frontend ;
- nous avons décidé de gérer l'interaction entre les composants et les services avec Celery sur AMQP.
Pour anticiper les questions sur le choix de Python, je vais expliquer. Ce langage a trouvé sa place dans notre société et autour de lui s'est formée une petite, mais réelle culture. Il a donc été décidé de commencer à construire le service avec ce langage. D'autant plus que la rapidité de développement est souvent cruciale dans ce genre de tâches.
Alors, commençons notre découverte.
Bill le silencieux — facturation
Nous connaissions ce gars depuis longtemps. Il était toujours assis à côté et comptait quelque chose en silence. Parfois, il nous transmettait les requêtes des utilisateurs, émettait des factures clients, gérait les services. C'était un gars ordinaire et travailleur. Cependant, il y avait des difficultés. Il était taciturne, parfois pensif et souvent — dans ses pensées.
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 était lors du traitement des services.
Par exemple, lors de la création ou de la suppression, la tâche passe dans la file d'attente interne de la facturation. Ainsi, un système de travail asynchrone avec les services est réalisé. Pour traiter nos types de services, nous devions « empiler » nos tâches dans cette file d'attente. Et c'est là que nous avons rencontré un problème : le manque de documentation.
D'après la description de l'API logicielle, il est néanmoins possible de résoudre cette tâche, mais nous n'avions pas le temps de nous consacrer au reverse engineering, donc nous avons extrait la logique à l'extérieur et organisé une file de tâches au-dessus de RabbitMQ. L'opération sur le service est initiée par le client dans son tableau de bord, enveloppée dans une « tâche » Celery côté backend et exécutée du côté de la facturation et d'OpenStack. Celery permet de gérer les tâches assez facilement, d'organiser des répétitions et de suivre l'état. Pour plus d'informations sur « Celery », vous pouvez lire, par exemple, .
De plus, la facturation n'a pas arrêté le projet lorsque l'argent était épuisé. En discutant avec les développeurs, nous avons découvert que lors du comptage selon les statistiques (et nous devons mettre en œuvre exactement cette logique), il y a une relation complexe des règles d'arrêt. Mais ces modèles ne s'adaptent pas bien à notre réalité. Nous avons également réalisé cela via des tâches sur Celery, en déplaçant la logique de gestion des services côté backend.
Les deux problèmes mentionnés ci-dessus ont conduit à un léger bouffissement du code et nous devrons nous occuper du refactoring à l'avenir, pour extraire la logique de gestion des tâches dans un service distinct. Nous devons également stocker une partie des informations sur les utilisateurs et leurs services dans nos propres tables, afin de maintenir cette logique.
Un autre problème est le silence.
Pour certaines requêtes à l'API, Billy répond en silence par « Ok ». Par exemple, cela s'est produit lorsque nous avons effectué des crédits de paiements promis pendant une période de test (dont nous parlerons plus tard). Les requêtes étaient exécutées correctement et nous ne voyions pas d'erreurs.
J'ai dû examiner les logs en travaillant avec le système via l'interface utilisateur. Il s'est avéré que le module de facturation exécute de telles requêtes en modifiant le scope pour un utilisateur spécifique, par exemple, admin, en le transmettant dans le paramètre su.
Dans l'ensemble, malgré les lacunes de la documentation et quelques erreurs mineures dans l'API, tout s'est plutôt bien passé. Les logs sont tout à fait lisibles même sous forte charge, si l'on comprend comment ils sont structurés et ce qu'il faut rechercher. La structure de la base de données est complexe, mais assez logique et même attrayante dans certains aspects.
Ainsi, pour résumer, les principaux problèmes que nous avons rencontrés lors de l'interaction sont liés aux particularités de la mise en œuvre du système spécifique :
- des « fonctionnalités » non documentées qui nous ont affectés d'une manière ou d'une autre ;
- des sources fermées (le module de facturation est écrit en C++), ce qui signifie qu'il était impossible de résoudre le problème 1 autrement qu'en utilisant la méthode de l'essai et de l'erreur.
Heureusement, le produit dispose d'une API suffisamment développée, et nous avons intégré les sous-systèmes suivants dans notre espace client :
- un module de support technique — les requêtes de l'espace client sont « proxifiées » dans le système de facturation, de manière transparente pour les clients du service ;
- un module financier — permet d'émettre des factures aux clients actuels, de réaliser des prélèvements et de générer des documents de paiement ;
- un module de gestion des services — pour lequel nous avons dû créer notre propre gestionnaire. L'extensibilité du système a joué en notre faveur et nous avons « appris » Billie à gérer un nouveau type de service.
Cela a demandé du travail, mais néanmoins, je pense que nous nous entendrons avec Billie.
Promenades à travers des champs de tungstène — Tungsten Fabric
Des champs de tungstène parsemés de centaines de fils, transportant des milliers de bits d'information. Les données sont regroupées en « paquets », analysées, construisant des parcours complexes, comme par magie.
C'est le domaine d'un second système avec lequel nous avons dû nous familiariser — Tungsten Fabric (TF), anciennement OpenContrail. Sa tâche est de gérer le matériel réseau, en fournissant une abstraction logicielle à nous, en tant qu'utilisateurs. TF — SDN, encapsule une logique complexe de travail avec le matériel réseau. Il existe un bon article sur la technologie elle-même, par exemple, .
Le système est intégré à OpenStack (que nous allons aborder ci-dessous) via le plugin Neutron.
Interaction des services OpenStack.
Nous avons été introduits à ce système par les gars du département d'exploitation. Nous utilisons l'API du système pour gérer la pile réseau de nos services. Pour l'instant, il ne nous a posé aucun problème majeur ou d'incommodité (je ne me permettrais pas de parler au nom des gars de l'OE), bien qu'il y ait eu quelques incidents cocasses d'interaction.
Le premier problème était le suivant : les commandes nécessitant l'affichage d'un grand volume de données sur la console de l'instance lors de la connexion via SSH « suspendaient » la connexion, alors que par VNC tout fonctionnait correctement.
Pour ceux qui ne sont pas familiers avec le problème, cela semble plutôt amusant : ls /root fonctionne correctement, alors que, par exemple, top « se fige » complètement. Heureusement, nous avons déjà rencontré des problèmes similaires. Nous avons réussi à les résoudre en ajustant le MTU sur le chemin entre les nœuds de calcul et les routeurs. À propos, ce n'est même pas un problème de TF.
Le problème suivant nous attendait au tournant. À un moment « merveilleux », la magie du routage a disparu, tout simplement. TF a cessé de gérer le routage sur le matériel.
Nous avons travaillé avec OpenStack depuis le niveau administrateur et, ensuite, nous passions au niveau de l'utilisateur requis. Le SDN semble « intercepter » le champ d'application de l'utilisateur sous lequel les actions sont effectuées. Le problème est que ce même compte administrateur est utilisé pour la communication entre TF et OpenStack. Lors de l'étape de changement vers l'utilisateur, la « magie » disparaissait. Nous avons décidé de créer un compte distinct pour travailler avec le système. Cela a permis de travailler sans casser les fonctionnalités d'intégration.
Les formes de vie silicium — OpenStack
L'être en silicone de forme étrange vit près des champs de tungstène. Il ressemble le plus à un enfant prépubère, capable d'écraser d'un simple geste, mais il n'exprime pas d'agressivité manifeste. Il ne génère pas de peur, mais sa taille inspire des inquiétudes. Tout comme la complexité de ce qui se passe autour.
OpenStack est le noyau de notre plateforme.
OpenStack a plusieurs sous-systèmes, parmi lesquels nous utilisons principalement Nova, Glance et Cinder. Chacun a sa propre API. Nova gère les ressources de calcul et la création d'instances, Cinder s'occupe de la gestion des volumes et de leurs instantanés, Glance est le service d'image qui gère les modèles de systèmes d'exploitation et les métadonnées associées.
Chaque service s'exécute dans un conteneur, et le courtier de messages est le « lapin blanc » — RabbitMQ.
Ce système nous a causé le plus de tracas inattendus.
Le premier problème s'est rapidement manifesté lorsque nous avons essayé de connecter un volume supplémentaire au serveur. L'API Cinder a catégoriquement refusé d'exécuter cette tâche. En vérité, selon OpenStack lui-même, la connexion s'établit, mais à l'intérieur du serveur virtuel, le périphérique de disque est absent.
Nous avons décidé de "contourner" le problème et avons demandé la même action à l'API Nova. Résultat — le périphérique se connecte correctement et est accessible à l'intérieur du serveur. Il semble que le problème survienne lorsque le stockage de blocs ne répond pas à Cinder.
Une autre difficulté nous attendait lors de la manipulation des disques. Nous n'avons pas pu détacher le volume système du serveur.
Encore une fois, OpenStack "jure" qu'il a détruit la connexion et qu'il est maintenant possible de travailler correctement avec le volume séparément. Mais l'API était catégoriquement réticente à effectuer des opérations sur le disque.
Nous avons décidé ici de ne pas trop nous battre, mais de changer notre perspective sur la logique de fonctionnement du service. Puisqu'il y a une instance, il doit y avoir un volume système. Ainsi, l'utilisateur ne peut pas supprimer ou déconnecter le "disque" système sans d'abord supprimer le "serveur".
OpenStack est un système complexe avec sa propre logique d'interaction et un API compliqué. La documentation assez détaillée et, bien sûr, la méthode des essais et des erreurs (comment faire sans ?) nous ont bien aidés.
Lancement de test
Nous avons réalisé le lancement de test en décembre dernier. L'objectif principal était de vérifier en conditions réelles notre projet du point de vue technique et de l'expérience utilisateur. Le public a été invité de manière sélective et le test était fermé. Cependant, nous avons également laissé la possibilité de demander un accès aux tests sur notre site.
Le test, bien sûr, ne s'est pas déroulé sans moments cocasses, car nos aventures ne font que commencer.
Tout d'abord, nous avons mal évalué l'intérêt pour le projet et avons dû ajouter des nœuds de calcul rapidement pendant le test. Un cas normal pour un cluster, mais il y avait aussi des nuances. Dans la documentation pour une version spécifique de TF, une version précise du noyau sur lequel la fonction avec vRouter a été testée est indiquée. Nous avons décidé de lancer les nœuds avec des noyaux plus récents. En conséquence, TF n'a pas reçu de routes des nœuds. Il a fallu revenir d'urgence aux noyaux précédents.
Un autre incident est lié à la fonctionnalité du bouton "changer le mot de passe" dans l'espace personnel.
Nous avons décidé d'utiliser JWT pour gérer l'accès au tableau de bord, afin d'éviter de travailler avec des sessions. Étant donné que les systèmes sont variés et largement dispersés, nous gérons notre propre jeton, dans lequel nous « encapsulons » les sessions de facturation et le jeton d'OpenStack. Lorsqu'un mot de passe est modifié, le jeton devient évidemment invalide, car les données de l'utilisateur ne sont plus valides et doivent être réémises.
Nous avons négligé ce point, et nous n'avions tout simplement pas les ressources pour écrire cette partie rapidement. Nous avons dû retirer des fonctionnalités juste avant le lancement des tests.
À l'heure actuelle, nous déconnectons l'utilisateur si le mot de passe a été changé.
Malgré ces nuances, le test s'est bien passé. En quelques semaines, environ 300 personnes ont visité notre service. Nous avons pu voir le produit du point de vue des utilisateurs, le tester en conditions réelles et recueillir des retours qualitatifs.
La suite à suivre
Pour beaucoup d'entre nous, il s'agit du premier projet de cette envergure. Nous avons tiré plusieurs leçons précieuses sur le travail en équipe, la prise de décisions architecturales et de conception. Comment intégrer des systèmes complexes avec des ressources limitées et les déployer en production.
Bien sûr, il y a encore beaucoup à améliorer tant sur le plan du code que sur les points d'intégration des systèmes. Le projet est encore jeune, mais nous avons la ferme intention d'en faire un service fiable et convivial.
Nous avons déjà réussi à convaincre les systèmes. Bill s'occupe consciencieusement du comptage, de l'émission des factures et des demandes des utilisateurs dans son petit bureau. La « magie » des champs de tungstène nous assure une connexion stable. Et seulement OpenStack fait parfois des siennes, lançant des messages tels que « WSREP has not yet prepared node for application use ». Mais c'est une toute autre histoire...
Nous avons récemment lancé le service.
Tous les détails sont disponibles sur notre .
Équipe de développement CLO
Liens utiles
OpenStack
Tungsten Fabric
Source : habr.com
