OpenStack à l Inria Saclay Île-de-France

Transcription

1 OpenStack à l Inria Saclay Île-de-France Marianne Lombard Inria Saclay Île-de-France 1, rue Honoré d Estienne d Orves Palaiseau Résumé Cette présentation est un retour d expérience sur la mise en place d un cloud privé à destination des chercheurs du centre Inria Saclay et de certaines équipes des autres centres de recherche. Nous reviendrons sur les étapes, les difficultés de ce projet et sur les solutions que nous avons mis en place pour garantir une disponibilité de service. Sur le plan du réseau, nous aborderons la mise en place d une architecture Ethernet en 10 giga plutôt que de l Infiniband. Au niveau du stockage distribué, nous évoquerons les choix d architecture qui ont été faits et le tuning nécessaire pour améliorer les performances du cluster Ceph. Enfin nous verrons comment nous répondons à un large panel de besoins de nos chercheurs avec seulement 32 serveurs et sans installer toutes les couches logicielles possibles et imaginables. Mots clefs Openstack, Cloud, Calcul 1 Introduction La plate-forme présentée dans cet article est l aboutissement de plus d un an de travail par le service informatique du centre de recherche. Elle n est pas figée et continue à croitre et évoluer, et nous l espérons, continuera encore longtemps à le faire. Cette plate-forme a été mise en place pour les équipes de recherche de l Inria Saclay Île-de-France 2 Rappels sur OpenStack Pour ceux qui ne connaissent pas (encore) OpenStack, cette plate-forme est un système d Infrastructure as a Service. Les utilisateurs sont très autonomes et ont la maitrise presque totale de leur environnement. Ils peuvent créer de façon complètement indépendante leurs instances (serveurs virtuels) en choisissant un gabarit parmi un ensemble de gabarits pré-définis (nombre de CPU, mémoire, espace disque), leur image système (distributions Linux standards ou images personnalisées) et leur configuration réseau (nombre de cartes, sous-réseaux, etc.). Il y a également des possibilités d orchestration (création d un ensemble d instance et si besoin du sous-réseau associé à partir d un fichier descriptif). Les utilisateurs sont regroupés dans des projets et ces projets sont isolés entre eux. L isolation par projets et la création de VLANs à la demande sont possible grâce aux possibilités offertes par le module Neutron en terme de Software-Defined Networking. JRES Nantes 1/7

2 3 Choix du matériel et de la stack logicielle 3.1 Naissance du projet Ce projet est né d une subvention CPER et était initialement prévu pour remplacer un cluster HPC "classique". Le financement de l État a représenté euros auquel le centre de recherche a ajouté euros. Diverses raisons, dont le coût des licences et la grande variété des demandes, nous ont conduit à changer de paradigme et passer à un projet de cloud. En raison de contrainte de temps, nous avons conservé l architecture matérielle de type "HPC" qui avait été sélectionnée avant le changement de cap. C est un choix que nous avons partiellement regretté, comme je le détaillerai par la suite. 3.2 Hardware Pour des raisons de simplicité administrative, nous sommes passés par le marché Matinfo (Matinfo 3 au moment de l achat). Tout le matériel a donc été acheté dans le catalogue Dell. La frontale est un serveur PowerEdge R630. Les nœuds compute sont des châssis C6320 et les serveurs de stockage des R730xd avec des baies MD1300. Les châssis C6320 sont des châssis 2U hébergeant chacun 4 nœuds. L alimentation est partagée mais chaque serveur dispose de sa carte-mère, ses cartes réseaux, ses disques. Ces châssis sont prévus pour des configurations HPC et Cloud. Le matériel réseau Ethernet est également du matériel Dell au catalogue Matinfo. 3.3 Logiciel Une fois le choix de passer à une infrastructure de cloud fait, nous avons choisi d utiliser OpenStack car c est un des environnements d Infrastructure as a Service les plus utilisés et notamment par le CERN ou la NASA. Étant déjà des utilisateurs de CentOS pour notre infrastructure, nous nous sommes dirigés sur RDO plutôt que sur la version Ubuntu. Nous avons installé la version Mitaka (dernière version stable au moment de l installation). 4 Installation 4.1 Installation du matériel Le matériel a été réparti sur deux baies dans la salle serveur, pour éviter de dépasser les capacités électriques des baies. Les Dell PowerEdge C6320 sont équipés chacun de 2 alimentations 1100W, ce qui impose d être attentif à ces problématiques. Les deux baies ne sont pas physiquement pleines mais approchent de leurs limites en capacité électrique. Vous pouvez voir un schéma de l infrastructure dans la figure Installation d OpenStack OpenStack a été installé via PackStack. Cet outil de déploiement permet de déployer un cloud OpenStack depuis la ligne de commande, à l aide d un fichier de réponse préparé à l avance. Ce fichier détaille les modules OpenStack à installer et leurs paramètres (dans certaines limites). Il est donc nécessaire de connaître les modules que l ont souhaite installer et sur quelles machines. PackStack génère des modules puppet et les applique sur les différentes machines, déployant les configurations. Il utilise ssh pour transférer les données, réalisant l échange de clé au début de son exécution (il est nécessaire de pouvoir se connecter en ssh en tant que root à cette étape). Les principaux défauts de PackStack sont la conséquence de son exhaustivité. Les JRES Nantes 2/7

3 Figure 1 - Schéma de la plate-forme configurations possibles étant extrêmement nombreuses, le fichier de réponse est énorme (plusieurs milliers de ligne) et les noms des options peuvent être plus ou moins clair, en particulier pour les sections dédiées au réseau. Un autre point négatif est l absence de support de l intégration de Ceph comme backend de stockage dans l installation avec PackStack. Cette intégration a du être faite manuellement après l installation. Nous avons choisi Packstack car c est l outil utilisé lors des formations que nous (les administrateurs) avons suivi. D autres possibilités existent (Triple0, puppet, ansible, etc.). 4.3 Modules installés Je vais revenir plus en détails sur certains modules que nous avons installés et les éléments pertinents de configuration Keystone Compte-tenu de l architecture du module d authentification, si on veut utiliser une authentification externe sur OpenStack, il est préférable d utiliser la version 3 de l API du module Keystone (permettant d avoir plusieurs sources d authentification). Cela permet de conserver les comptes "techniques" en local sur le cluster et les utilisateurs dans un annuaire externe (LDAP ou Active Directory par exemple). JRES Nantes 3/7

4 4.3.2 Nova Le module Compute (Nova) sert à lancer et piloter les instances des utilisateurs. Dans notre cas, il a été paramétrée pour utiliser KVM comme technologie de virtualisation. Comme expliqué plus loin, nous limitons fortement la sur-allocation mémoire et vcpu afin de limiter l impact de la virtualisation sur les performances Neutron Neutron est le module réseau. C est également un des plus complexes à configurer, compte-tenu de son exhaustivité. Il peut aussi bien piloter directement des routeurs de différents constructeurs qu un OpenVSwitch. Au niveau des projets utilisateurs, il permet de créer des réseaux à la demande pour connecter les instances entre elle et leur permettre d accéder à internet et d être accédées par les utilisateurs. Dans notre installation, il est configuré pour utiliser OpenVSwitch et générer des réseaux VxLANs pour les projets des utilisateurs Heat Heat est un module d orchestration. L utilisateur prépare un fichier descriptif en YAML de l infrastructure qu il souhaite lancer (caractéristiques des instances, configuration réseau, images disques à utiliser, etc.). En passant ensuite ce fichier au module Heat, l utilisateur pourra lancer son infrastructure en une ligne de commande, automatisant ainsi la création de son environnement Ironic Le module Ironic n a pas été installé immédiatement mais fin Il permet de déployer des instances en bare-metal (directement sur du matériel) plutôt que instances virtuelles. Cela permet d utiliser directement le hardware, ce qui peut éviter d avoir à configurer du PCI-passthrough pour exploiter par exemple des cartes graphiques. 4.4 Ceph La brique de stockage choisie pour notre cloud OpenStack est Ceph. C est un système de stockage objet distribué, utilisant un système de réplication pour permettre une tolérance aux pannes. Il est accessible de plusieurs façons : soit en mode objet directement, soit pour stocker des images en mode block, soit en mode système de fichiers (CephFS, qui n est pas utilisé dans le contexte OpenStack). En raison de son fonctionnement réparti, Ceph demande d avoir au moins trois serveurs pour répartir les données. L installation de Ceph a été faite avec l outil ceph-deploy (fournit par le projet Ceph). Nous avons ensuite intégré manuellement ce stockage Ceph à OpenStack pour l utiliser comme backend de stockage pour les modules Nova (module Compute), Glance (module de stockage des images) et Cinder (module de stockage en mode bloc). Cette intégration s est déroulée sans difficulté. 5 Difficultées rencontrées 5.1 Réseau Le premier blocage que nous avons rencontré a été le réseau. Pour disposer d un réseau rapide, nous avons conservé le matériel infiniband prévu dans l architecture HPC. Malheureusement, les cartes fournies ne JRES Nantes 4/7

5 supportent pas l utilisation d OpenVSwitch. Nous avons dû investir dans de nouveaux switchs 10g (et les câbles correspondants) pour disposer d une infrastructure réseau suffisante. Les serveurs ayant tous été achetés avec des cartes 10g internet, nous n avons pas eu de modification à faire sur ce plan. 5.2 Ceph N ayant pas d expérience dans les systèmes de fichiers distribués au début de l installation de la plate-forme, nous avons commis des erreurs de débutants. Lors de l installation de Ceph, nous avons utilisé des volumes RAID comme OSD, limitant ainsi les performances et l intérêt de ce stockage. Nous avons donc décidé de "casser" ces OSDs en RAID et de créer un OSD par disque, comme recommandé. C est là que l on voit tout l intérêt d un stockage distribué en haute disponibilité, puisque nous avons pu, en travaillant volume RAID par volume RAID, modifier la configuration à chaud, sans interruption de service. Toutes ces opérations ont été faite avec ceph-deploy. Notre seconde erreur a été de mettre nos journaux ceph sur un disque SSD mais en ne prévoyant qu un disque SSD par serveur. La recommandation officielle est d un disque SSD pour 4 disques SATA. En reconfigurant notre cluster pour héberger les journaux sur les mêmes disques que les OSDs, nous avons vu une augmentation significative des performances en écriture (multiplication par quatre). 5.3 Performances Le fait de travailler dans des machines virtuelles peut avoir des impacts sur les performances. Nous avons essayé d optimiser au maximum notre infrastructure pour limiter cette impact. Nous limitons donc très fortement la sur-allocation des ressources processeurs et mémoire. (Ces réglages ont été fait dès l installation mais sont facilement modifiables par la suite). Il reste malgré tout une légère perte à ce niveau, liée au fonctionnement même de la virtualisation, signalée par nos utilisateurs. Nous travaillons sur la mise en place du module OpenStack Ironic, prévu pour déployer des machines physiques de la même façon que les instances virtuelles. Cela permettra de s affranchir de ce problème. 6 Questions d organisation Vu la grande autonomie des utilisateurs sur les plate-formes d IaaS, il est très facile pour eux de détourner en partie l utilisation de la plate-forme. Pour éviter ces problèmes, nous avons mis en place deux choses. 6.1 Accès depuis l extérieur Cette plate-forme OpenStack a une vocation stricte de recherche scientifique. Elle n est pas destinée à la publication de résultats ou à l hébergement de sites web personnels ou d équipe. Pour limiter les tentations, le réseau public du cluster est un réseau privé ( xxx.0/24 en IPv4). Il n est pas routé sur Internet et n est accessible que depuis le réseau interne du centre (ou la passerelle ssh). Cela n empêchera pas quelqu un d héberger un serveur web destiné à un usage interne, mais ce risque est limité. 6.2 Machines IDLE Le second risque est lié au fonctionnement même d OpenStack. Il est très simple de lancer une infrastructure virtuelle et de laisser celle-ci tourner en permanence, bloquant l utilisation de la plate-forme pour d autres utilisateurs. OpenStack dispose nativement d un système de quotas par projet, permettant de limiter le nombre d instance, de mémoire, de CPU, etc. mais n a pas d outil natif pour décommissionner les machines JRES Nantes 5/7

6 après un temps donné. Les quotas par défaut (nombre de vcpu, mémoire total, espace disque cumulé, etc.) sont très bas pour notre utilisation et nous les avons donc augmenté très fortement (en multipliant par quatre ou cinq les valeurs par défaut), en indiquant bien que nous sommes prêts à les ajuster au besoin. Dans la plupart des cas, les instances restent active car les utilisateurs oublient de les éteindre mais on peut imaginer que certains veulent se réserver ainsi une partie des ressources. Le système de quotas limite déjà fortement l impact de cette tactique. Ce comportement n est pas spécifique à l IaaS et peut se retrouver sur d autres clusters de calcul. La mise en place prévue d une facturation, à l aide du module CloudKitty, devrait nous aider. Il n est pas question ici d une facturation réelle, mais de pouvoir mettre en parallèle les ressources utilisées et le prix qu aurait couté la même utilisation sur des clouds publics tels que Microsoft Azure ou Amazon EC2 (facturation à l heure des instances "UP", le tarif horaire étant fonction de taille de l instance). On pourra également utiliser ces indicateurs pour solliciter des contributions à l évolution de la plate-forme. 7 Et coté ressources humaines? Nous sommes deux personnes à travailler sur cette plate-forme, assistés parfois par une troisième collègue. Aucun de nous ne travaille à temps plein sur OpenStack, nous avons tous d autres projets et responsabilités. Nous assurons les mises à jour de la plate-forme, la publication des nouvelles images systèmes, la formation des utilisateurs et bien sûr, la rédaction des documentations utilisateurs et administrateurs. L installation de la plate-forme a représenté la plus grosse charge de travail. OpenStack étant aujourd hui un projet mature, disposant d outils d installation aboutis, celle-ci est techniquement assez simple (pour qui maitrise un minimum les environnements Linux). Mais il est toujours nécessaire de comprendre le fonctionnement du projet et de réfléchir à l architecture à mettre en place avant de se commencer la mise en place. 8 Coté utilisateur 8.1 Accès Nous avons fait le choix d avoir un projet par équipe de recherche. Les équipes de recherche doivent signaler leur souhait d utiliser la plate-forme pour que nous ouvrions l accès. Nous profitons de ce filtrage pour proposer une formation rapide des utilisateurs, adaptée à leurs besoins et à leurs connaissances préalables des environnements de cloud computing. Les chercheurs sont libres d utiliser indifféremment l interface web ou le client en ligne de commande. Les quotas mis en place à la création du projet sont modifiables sur simple demande des utilisateurs, en fonction des besoins et de l utilisation de l équipe. 8.2 Nombres d équipes utilisatrices La plate-forme OpenStack est aujourd hui utilisé par une dizaine d équipes de recherche, certaines de façon intensive, d autres étant encore en phase de tests. Suite à une décision du directeur du centre de recherche, l accès est désormais ouvert à tous les centres de recherche Inria avec déjà des utilisateurs des centres Inria de Sophia-Antipolis - Méditerranée et Nancy - Grand-Est. 9 Évolution de la plate-forme Entre l installation en 2016 et aujourd hui, la plate-forme OpenStack a évolué. Fin 2017, nous avons réalisé une montée de version d OpenStack (de Mitaka vers Newton) et de Ceph (de Hammer vers Jewel). La JRES Nantes 6/7

7 partie upgrade d OpenStack a été réalisée avec un prestataire. Nous avons également travaillé avec lui pour installer le module Ironic (déploiement d instances en bare-metal). En interne, nous avons travaillé pour proposer des instances NUMA-Aware, celles-ci en permettant de lier les cœurs virtuels aux cœurs physiques, améliorent les performances jusqu à trente pour cent. D autres évolutions sont prévues : l ajout de stockage objet (suite à des demandes d utilisateurs) et la mise en place d un module de facturation (CloudKitty) 10 Conclusion Ce projet a été pour moi, et pour mes collègues, un apprentissage. Nous avons appris énormément sur un plan technique, en découvrant le monde du Cloud Computing. La grande modularité d OpenStack est un atout dans un environnement aussi complexe que celui de l Inria. Une des questions qui peut se poser est l intérêt de passer par un cloud privé plutôt qu un cloud public. La facturation est une des raisons. La majorité des clouds publics facturent à l utilisation (durée, gabarit utilisé, quantité de données téléchargées, etc) ce qui s accorde mal avec le fonctionnement par devis et bons de commande de la fonction publique. La souveraineté en est une autre, les plus gros opérateurs de cloud public étant américains. Et compte tenu des législations américaines et des obligations de l Inria en matière de protection du patrimoine scientifique français, l hébergement de données doit être fait en France ou à minima dans l Union Européenne. OpenStack ne remplace pas (encore) complètement les architectures HPC (pour les calculs utilisant MPI) mais sa souplesse permet de répondre aux besoins plus variés de nos équipes de recherche. La possibilité de personnaliser les images systèmes permet de s affranchir de l enfer des dépendances qui peut bloquer les mises à jour des outils sur les environnements plus traditionnels. Il peut par contre demander un accompagnement plus important des utilisateurs lors du début de l utilisation, en particulier s ils doivent créer leurs images systèmes personnalisées avec des bibliothèques logicielles et outils non installées sur les images fournies par défaut. JRES Nantes 7/7