Les prochains satellites d’Airbus entièrement exploités par l’Open source
Airbus Defence & Space Geo a mis en chantier un datacenter basé sur OpenStack, OpenShift, Ansible et autres Ceph pour traiter de manière fiable les 40 To d’images quotidiennes de la constellation Pleiades Neo.
La branche Geo d’Airbus Defence & Space a fait le choix d’une infrastructure 100 % Open source pour motoriser l’immense datacenter chargé de traiter et de distribuer les images de sa nouvelle constellation de satellites Pleiades Neo. Selon elle, le choix de ces technologies lui permet de garantir un maximum d’interopérabilité entre les modules, de sorte à industrialiser les déploiements afin qu’ils soient plus fiables, et à mieux observer chaque rouage pour intervenir rapidement en cas d’incident.
Lancés entre 2020 et 2022 à une altitude de 620 km et embarquant un télescope de 1,35 mètre de diamètre tourné vers la Terre, ces satellites prennent deux fois par jour en photo n’importe quel endroit de la planète avec une finesse de détails qui descend jusqu’à 30 cm. Les images, qui représentent quotidiennement 40 To de données, sont exploitées par les clients d’Airbus Defence & Space, aussi bien dans les domaines de la défense (la Direction Générale pour l’Armement, par exemple), que parmi des acteurs privés, notamment dans les activités maritimes.
« Ce programme spatial doit s’accompagner d’un segment sol, un datacenter dont la tâche est de recevoir, contrôler, traiter, stocker, indexer et redistribuer les images. »
Guillaume BrandelyResponsable de l’usine numérique, Airbus Defence & Space
« Ce programme spatial doit s’accompagner d’un segment sol, un datacenter dont la tâche est de recevoir, contrôler, traiter, stocker, indexer et redistribuer les images. La puissance nécessaire est telle que nous prévoyons pour ce programme 5 000 machines virtuelles utilisant 40 000 vCPU et 13 Po de stockage, répartis sur 500 serveurs physiques », explique Guillaume Brandely, responsable de l’usine numérique d’Airbus Defence & Space, dans l’entretien qu’il a accordé à l’occasion du récent Red Hat Forum EMEA 2020.
Le projet de ce datacenter a démarré en 2015. « Dès l’origine, nous souhaitions nous baser sur des blocs techniques standardisés afin de pouvoir étendre facilement les capacités de traitements et de stockage au gré de nos besoins. Nous avons ici conçu le design d’une étagère rack-type, dont la moitié se compose de processeurs avec un haut niveau de densité, un tiers est dédié au stockage et le reste à la connectique top-of-the-rack, celle à partir de laquelle nous enchaînons les racks les uns derrière les autres. »
OpenStack pour la base, Ansible pour l’industrialisation
Au-delà du matériel, il y a surtout le logiciel. « Selon nous, l’élasticité n’est possible qu’avec des technologies logicielles de type cloud. Plus que la virtualisation, il y a la notion d’avoir un datacenter contrôlable depuis des API », ajoute Clément Bisso, en charge des services techniques chez Airbus Defence & Space.
Rapidement, l’équipe se tourne vers la plateforme de virtualisation OpenStack. La version Helion 5 de ce système, celle mise au point par HPE est déployée dès 2017. Les API sont dès lors celles fournies par le module Heat d’OpenStack ; celui-ci permet de programmer des actions automatiques, comme le déploiement de nouvelles ressources lorsqu’un événement survient. Heat est complété par le logiciel Open source Ansible Tower, qui se charge de déclencher toutes les tâches nécessaires à la moindre mise en service, aux bons endroits et dans le bon ordre.
À cette époque, cette architecture est testée sur les images recueillies par la précédente constellation de satellites Pleiades, lancée en 2011. Airbus Defence & Space fait le choix de stocker ses données sur des baies SAN 3PAR, également fournies par HPE. L’équipe déploie aussi OpenShift Origin, un logiciel Open source pour orchestrer des applications en containers, mais qui ne fonctionnent pas encore avec les technologies Docker et Kubernetes standardisées par la suite.
Cette solution d’infrastructure globale remplissait ses fonctions, mais un événement va rapidement inciter l’équipe à changer son fusil d’épaule : l’abandon d’OpenStack par HPE. « HPE ayant cédé son activité OpenStack à Suse, nous avons continué avec les versions suivantes de nos logiciels Open source fournies par ce dernier. En revanche, c’est à ce moment-là que nous avons jugé pertinent de remplacer la baie SAN 3PAR par le système de stockage Ceph », raconte Clément Bisso.
« Ceph a plusieurs avantages. Le premier est qu’il est beaucoup mieux intégré à OpenStack. Le second est qu’il s’agit là aussi d’un logiciel Open source. Nous étions déjà convaincus que l’Open source est un moyen d’assurer la pérennité de notre datacenter et aussi de garantir qu’il sera toujours le plus efficace possible. Nous nous sommes en pratique rendu compte que cette combinaison de produits Open source nous apportait une vraie facilité pour gérer nos plateformes de manière automatique. »
Red Hat pour une intégration à 100 %
Mais Clément Bisso veut encore plus : automatiser au maximum les interactions serait la clé de l’excellence de son projet. Alors, au début de cette année 2020, à la faveur d’une dernière mise à jour avant le lancement de la première paire de satellites Pleiades Neo, Airbus Defence & Space décide de changer de fournisseur. L’industriel va à présent se fournir en logiciels Open source auprès de Red Hat.
« Nous avions avec eux [Red Hat] la garantie d’une interopérabilité 100 % fonctionnelle entre OpenStack, Ansible et Ceph. »
Clément BissoEn charge des services techniques, Airbus Defence & Space
« Red Hat nous a paru plus impliqué que Suse dans le suivi des produits. En particulier, nous avions avec eux la garantie d’une interopérabilité 100 % fonctionnelle entre OpenStack, Ansible et Ceph », se félicite le responsable des services techniques.
En particulier, l’équipe de Clément Bisso découvre avec Red Hat une fonction très pratique : les inventaires dynamiques. « Une fois que l’on dispose d’un projet applicatif prêt à être déployé sur OpenStack, nous pouvons créer un inventaire dynamique qui va constamment tenir à jour la liste des machines virtuelles, des containers, des labels, des métadonnées du projet. Et, ça, c’est excessivement pratique parce qu’Ansible s’en sert pour savoir tout seul ce qu’il doit configurer quand une action est déclenchée. Au final, les opérations sont si automatisées que notre travail ne consiste plus qu’à faire de la surveillance ! », se plaît-il à dire.
Ce rapprochement avec Red Hat se veut un âge de raison. Dès lors, l’équipe souscrira à un accompagnement autour de la version complète d’OpenShift. De plus, le module Heat est remplacé par le logiciel Terraform, plus moderne. « Nous avons évalué l’opportunité de plutôt adopter GitHub Actions. Cependant, nous avons observé que Terraform était plus fréquent dans les projets cloud et qu’il était plus facile de recruter des experts sur cette technologie. » En amont de Terraform, les codes applicatifs eux-mêmes sont mis à jour avec l’outil Open source Elm.
« Le scénario est le suivant : nous déployons avec Terraform, Ansible met tout à jour automatiquement grâce aux inventaires dynamiques et, avant les prochains déploiements, il lance aussi des processus de production. On pense à tout ce qui a trait à la maintenance, comme les sauvegardes évidemment. Mais Ansible sert aussi à nourrir nos outils de monitoring avec les bonnes données. »
En l’occurrence, l’équipe de Clément Bisso en utilise plusieurs : Grafana, Kibana, Centreon… Selon les ressources observées, ils indiquent l’évolution de leur consommation, des métriques en temps réel sur l’infrastructure ; ils produisent un reporting complet concernant le déroulement des actions automatisées ou à propos des tests de fiabilités.
Bientôt du bare-metal et de l’OCS
Le datacenter n’est pas totalement terminé. « Pour l’heure, nous avons déployé 14 000 vCPU. D’une part, exécuter les applications de traitement d’images avec un stockage Ceph en mode bloc de 800 To. Et, d’autre part, pour les héberger dans des formats finaux sur un stockage Ceph en mode objet de 2 Po. Cette seconde partie comporte aussi une certaine quantité de processus applicatifs : nous cataloguons les images, les mettons à disposition sous différents formats, nous assurons un archivage à long terme… », indique Guillaume Brandely.
Mis à part le reste des ressources prévues, qui seront ajoutées au fil du temps par l’ajout de blocs racks supplémentaires, il manque aussi certaines fonctions. L’équipe d’Airbus Defence & Space Geo veut pouvoir exécuter certaines applications en bare-metal, c’est-à-dire directement sur des serveurs physiques, sans passer par une couche de virtualisation.
« Nous pensons que cela nous permettrait de gagner 10 à 20 % de performances sur certaines applications. Le bare-metal est activable facilement dans OpenStack, via le module Ironic. Nous ne savons en revanche pas encore si nous devons exécuter ainsi des applications d’ordinaire en VM ou plutôt des clusters de containers ; auquel cas il faut configurer un Kubernetes bare-metal », ajoute le responsable de l’usine numérique.
Il précise d’ailleurs qu’un autre élément manquant est OCS (Openshift Container Storage), à savoir la version du système Ceph entièrement pilotable depuis la console OpenShift. Elle serait nécessaire pour, justement, attribuer du stockage aux applications exécutées par Kubernetes, sans passer par la couche de virtualisation.
3,5 milliards de logs par semaine
« À l’heure actuelle, notre datacenter exécute déjà 117 projets Openstack. »
Guillaume BrandelyResponsable de l’usine numérique, Airbus Defence & Space
« À l’heure actuelle, notre datacenter exécute déjà 117 projets Openstack [des configurations applicatives, N.D.R.]. Cela peut paraître beaucoup. Pourtant, cette segmentation nous a paru plus simple pour conserver le contrôle et pour l’efficacité de nos applications. La quantité de configurations n’est plus un problème dès que tout est industrialisé grâce aux inventaires dynamiques, que tout est reproductible grâce à la standardisation des déploiements depuis Terraform, et que tout est vérifié grâce à Ansible. »
« Ces projets OpenStack engendrent en tout 3,5 milliards de logs par semaine. Mais ce n’est pas non plus un problème : avec des outils comme Kibana, nous pouvons faire des analyses de l’état de santé de notre informatique à grande échelle et nous détecter des pannes assez rapidement. Cette observabilité est essentielle pour garantir à nos clients l’efficacité de notre plateforme. Nous n’aurions jamais atteint un tel niveau de monitoring avec des solutions commerciales », conclut Guillaume Brandely en se félicitant une nouvelle fois d’avoir fait le choix des logiciels Open source.
