OpenStack : l'IA en filigrane de la nouvelle version

Publié par Clément Bohic le 3 oct. 2024 - mis à jour à 15:40

De Nova à Blazar, la dernière version d'OpenStack apporte des capacités susceptibles de favoriser l'usage des GPU.

OpenStack, un peu plus adapté aux workloads IA ? La dernière version ("Dalmatian", 2024.2) flexibilise en tout cas l'usage des GPU.

Nova (la brique de compute) gère maintenant la persistance des vGPU en cas de redémarrage de l'hôte. Condition : utiliser au minimum libvirt 7.3.0. Par ailleurs, sur les GPU supportant SR-IOV, il est nécessaire de réactiver les fonctions de virtualisation après le reboot.

Blazar (service de réservation de ressources) permet quant à lui désormais de réserver des instances sur la base de templates Nova. Ce qui devrait simplifier la mise en oeuvre d'instances GPU.

Avec OpenStack 2024.2, Nova gagne aussi en sécurité. Il devient par exemple possible d'exiger des connexions TLS pour les consoles SPICE. S'y ajoute la détection automatique du support vTPM avec les versions de libvirt postérieures à la 8.0.0. Les instances de type UEFI peuvent par ailleurs être lancées avec un firmware sans état (libvirt 8.6.0+).

Un rôle de plus sur Neutron

Sur Neutron (brique réseau), le RBAC englobe un rôle supplémentaire : le "manager". Son niveau de privilèges est moins important que celui d'un admin, mais plus important que celui d'un membre de projet. Il a, par exemple, des droits sur l'API permettant de paramétrer un type de volume par défaut pour un projet.
Neutron se dote aussi d'un nouvel algo pour comparer les règles associées aux groupes de sécurité avec les ACN d'OVN. Promesse : une plus grande efficace sur les grands ensembles, grâce à un tri préalable en fonction de l'ID des règles. On notera aussi la disponibilité d'un pilote OVN permettant de créer des interfaces de routage sans ports de commutateur logique sous-jacents (Neutron agit alors en simple gestionnaire d'adresses IP).

QoS et actif/actif se répandent sur Cinder

Sur la partie stockage bloc (Cinder), la QoS arrive dans le pilote Hitachi. Même chose sur le pilote PowerStore (4.0+), qui gagne aussi le support actif/actif - comme le pilote ONTAP iSCSI/FC. Le pilote Eternus DX permet désormais d'ajouter des métadonnées aux snapshots (nom et numéro du volume + nom du pool), quand le pilote Lightbits permet d'en créer plusieurs simultanément à partir d'un même volume. L'ensemble des pilotes peuvent déclarer leur capacité à cloner un volume dans un autre pool (Cinder ne vérifie alors pas la compatibilité des pools des volumes source et de destination).

Sur la partie stockage objet (Swift), une option de config permet désormais aux clients d'interagir avec des objets expirés (requêtes GET, HEAD et POST). Les délais de grâce peuvent en outre être gérés par compte et par conteneur. Quant au limiteur de débit, il supporte le rechargement dynamique des limites. Un paramètre apparaît aussi dans le middleware SLO pour ne demander qu'une partie d'un gros objet.

pytest en première ligne sur Horizon

Avec OpenStack 24.02, Manila (plan de contrôle du stockage) permet de contrôler des capacités de stockage via les métadonnées des partages. Le pilote ONTAP s'enrichit du support des partages WORM (write once, read many) via la techno NetApp SnapLock. Il devient par ailleurs possible de planifie des partages sur des hôtes en cours d'exécution mais signalés comme étant en maintenance.

Sur Horizon (console d'administration), le SDK prend le relais de neutronclient pour les réseaux, sous-réseaux, trunks et ports. Et pytest devient l'outil par défaut pour les tests d'intégration.

Comme Nova, Ironic (gestion bare metal) progresse sur le volet sécurité. Entre autres, en limitant la journalisation lors de la phase de nettoyage, en exigeant HTTPS par défaut pour la communication avec l'agent et en imposant le hachage des mots de passe de secours. Il permet aussi de ne pas autoriser certains modes d'amorçage pour l'enregistrement et/ou le déploiement de noeuds.