Editions ENI Livres | Vidéos | e-Formations
TripleO
Déployer OpenStack avec OpenStack
1. Principes
De toutes les solutions de déploiement d’OpenStack, de l’installation service par service, en passant par les outils tels que Ansible, TripleO, pour OpenStack On OpenStack, est sans doute le plus original. Cela tombe à point nommé : c’est justement la solution qui est mise en avant par OpenStack, en tant que projet à part entière de la fondation.
a. Fonctionnement
Il s’agit tout simplement de déployer OpenStack en se servant d’une installation minimale d’OpenStack, appelée Undercloud, et de la puissance de HEAT, le langage d’orchestration propre à OpenStack, combiné à Ironic, le module de déploiement de serveurs physiques, pour construire un environnement de production, de test, ou de l’usage souhaité, qui est l’Overcloud. De plus, l’Undercloud ne se contente pas de déployer. Il sert aussi à monitorer et à mettre à jour l’Overcloud, bref, à en garantir le cycle de vie.
Architecture simplifiée de TripleO
TripleO exploite plusieurs composants de base existants d’OpenStack, notamment Nova, Ironic, Neutron, Heat, Glance et Ceilometer pour déployer OpenStack sur du serveur physique. Nova et Ironic sont utilisés dans l’Undercloud pour gérer les instances BareMetal qui composent l’infrastructure de l’Overcloud. Neutron est utilisé pour fournir un environnement réseau dans lequel déployer l’Overcloud, les images machines sont stockées dans Glance. Ceilometer servira plus tard au monitoring des machines qui sont dans l’Overcloud.
Pour que ce soit plus clair, le schéma suivant résume la relation et les rôles que peuvent avoir l’Undercloud et l’Overcloud :
Workflow de déploiement de TripleO
Dans...
Notions de bases sur HEAT
Bien qu’il soit envisageable de se passer de HEAT pour faire un déploiement, ce serait un non-sens total. Dans ce cas, autant installer tout de suite un environnement OpenStack manuellement. HEAT est en effet le langage d’automatisation d’OpenStack. Comme vu dans le chapitre sur OpenStack en production, HEAT fait partie des briques Infrastructure as Code.
Selon OpenStack Fundation, HEAT est un moteur d’orchestration permettant de lancer plusieurs applications cloud composites basées sur des modèles sous forme de fichiers texte pouvant être traités comme du code. En termes simples, HEAT fournit aux utilisateurs d’OpenStack un moyen d’automatiser la création de composants cloud tels que des réseaux, des instances, des périphériques de stockage et bien plus encore.
1. Architecture de HEAT
a. Architecture
HEAT est constitué de quatre composants, dont chacun est en charge d’une fonction unique :
-
heat est le client ligne de commande. Il va dialoguer avec heat-api.
-
heat-api est le serveur OpenStack-native ReST API qui va rediriger les requêtes vers le heat-engine.
-
heat-api-cfn : ce composant fournit une API de requête de style AWS et compatible avec AWS CloudFormation. A l’instar de heat-api, il traite les demandes et les envoie au heat-engine.
-
heat-engine est le cœur du système et effectue le travail principal d’orchestrer le lancement des templates HEAT pour lancer les requêtes API vers les consommateurs qui sont les services standards d’OpenStack.
b. Concepts
À côté de cette architecture finalement basique, il est important de connaître les notions et terminologies utilisées dans HEAT.
Il y a tout d’abord les ressources. Ce sont les objets élémentaires qui vont être manipulés (créés, détruits)...
Ironic
1. Généralités
a. Pourquoi Ironic ?
Ironic permet aux utilisateurs de gérer une infrastructure BareMetal comme ils le feraient avec des machines virtuelles. Bien que TripleO n’implique pas forcément Ironic, et vice versa, ils ont quand même une affinité particulière puisque dans la plupart des implémentations TripleO, il s’agit de provisionner des machines physiques.
Tout l’objet de ce livre est de décrire OpenStack, un système d’exploitation de cloud, agissant principalement sur des ressources virtualisées, que ce soit les serveurs, le stockage ou les réseaux. Pourtant, il y a un élément fondamental qui sous-tend tout dans cette couche d’abstraction logicielle : le besoin d’un matériel correctement configuré et géré pour les héberger. Il s’agit d’un problème universel en informatique, que ce soit pour un appareil aussi petit qu’une montre ou un téléphone, ou un ordinateur personnel ou l’hébergement d’un cluster entier de serveurs délivrant des millions de requêtes, chaque application démarre directement ou indirectement avec le provisionnement léger du matériel physique, connu sous le nom de baremetal prêt à l’emploi.
Malgré tous les progrès de l’abstraction informatique, la gestion du BareMetal reste un problème fondamental qui doit être résolu. Comme dans le domaine de la construction où, quels que soient le cadre ou les matériaux de construction utilisés, la fondation doit être solide, stable et sécurisée pour résister à la charge, aux contraintes externes et autres aléas.
Le manque de standardisation de l’API BareMetal a entraîné une prolifération...
Installation de l’Undercloud
1. Prérequis
a. Choix du serveur Undercloud
Le serveur d’Undercloud peut être en pratique une machine virtuelle. D’expérience, et à date, un minimum de 16 Go de RAM et de 20 Go d’espace disque est nécessaire pour faire tourner l’Undercloud. Après tout, cela reste un environnement OpenStack entier, avec donc au moins un gestionnaire de queue et une base de données.
Assez gourmand en opérations d’entrées/sorties disques, il est aussi conseillé d’avoir pour l’Undercloud des disques rapides, types SSD. De même, il convient d’avoir suffisamment d’espace disque, les images étant stockées deux fois, une fois dans Glance et une seconde fois lors des appels PXE.
À date, seuls les systèmes basés sur la distribution Red Hat sont supportés pour l’Undercloud. Les autres systèmes sont certainement compatibles, mais peuvent nécessiter des adaptations supplémentaires.
b. Réseau
Les nœuds Overcloud seront déployés à partir de la machine Undercloud et, par conséquent, les paramètres réseau des machines doivent être modifiés pour permettre aux nœuds Overcloud d’être démarrés par PXE à l’aide de la machine Undercloud.
-
Toutes les machines Overcloud de la configuration doivent prendre en charge IPMI ou le protocole propriétaire équivalent.
-
Un réseau de provisionnement de gestion est configuré pour toutes les machines Overcloud. Une carte réseau de chaque machine doit se trouver dans le même domaine de diffusion du réseau de provisionnement. Cela peut nécessiter la configuration d’un nouveau VLAN sur le switch physique, VLAN qui sera dédié au réseau de provisionnement....
Déploiement de l’Overcloud
Déployer l’Overcloud est un processus long et complexe, dans lequel le moindre détail peut avoir un impact décisif. Il est préférable, avant toute opération, de revoir dans le détail tous les fichiers nécessaires aux déploiements, à commencer par les caractéristiques matérielles, la présence et l’adéquation des images.
L’installation se fait avec une seule commande, openstack overcloud deploy, mais ce qui ajoute la complexité est la diversité des scénarios et options de configuration qui sont pour la plupart faits au niveau des paramètres HEAT des templates prédéfinis sous :
/usr/share/openstack-tripleo-heat-templates Le principe est simple : toujours partir des templates originaux, les copier ailleurs pour les modifier et les inclure en option à l’instruction overcloud deploy en ayant toujours en tête que l’ordre est important. En effet, c’est la dernière valeur définie d’un paramètre qui est prise en compte.
Lors d’un déploiement, il est conseillé de toujours inclure ce répertoire original des templates. Ce point sera étudié en détail par la suite.
1. Installation et configuration simple
Dans cette section, le cas le plus simple d’une installation de l’Overcloud sera abordé. Le but est de mettre en lumière les grandes étapes du processus.
a. Obtenir et créer les images
Les images doivent être créées avant d’effectuer un déploiement. Un disque virtuel IPA, un disque virtuel de déploiement et une image openstack-full peuvent tous être créés à l’aide d’instack-undercloud . Il est recommandé de construire des images directement...