Editions ENI Livres | Vidéos | e-Formations
Administration d'OpenStack
Outils
1. tcpdump, dhcpdump et Wireshark
Dans le cas de problèmes surtout avec Neutron, il est souvent nécessaire d’analyser le trafic réseau, que ce soit entre la machine virtuelle et le nœud compute mais surtout avec les services L3 de Neutron.
a. tcpdump
Le premier des outils indispensables. tcpdump permet d’analyser le trafic réseau en capturant les paquets TCP/IP.
Il s’installe facilement avec le gestionnaire de paquets du système d’exploitation. Toutefois, certaines organisations peuvent considérer que cet outil peut contrevenir aux règles de sécurité réseau, tant sa puissance et ses capacités peuvent être utilisées à mauvais escient.
tcpdump examine les en-têtes des paquets et imprime une ligne par paquet capturé. Voici quelques commandes utiles pour l’utiliser :
Listez les interfaces disponibles :
$ sudo tcpdump -D
1.eth0
2.virbr0
3.nflog (Linux netfilter log (NFLOG) interface)
4.nfqueue (Linux netfilter queue (NFQUEUE) interface)
5.any (Pseudo-device that captures on all interfaces)
6.lo [Loopback] Capturez les paquets pour une interface. Interrompez avec la combinaison [Ctrl] C, sinon utilisez l’option -c 10 pour ne capturer que 10 lignes.
$ sudo tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:23:12.584643 IP s05837e0.dmn.openstack.mdns > 224.0.0.251.mdns:
0 AAAA (QM)? XAD-IP193052.local. (36)
10:23:12.584736 IP s05837e0.dmn.openstack.mdns > 224.0.0.251.mdns:
0 A (QM)? XAD-IP193052.local. (36)
10:23:12.587578 IP s09248r0.dmn.openstack.37426 >
site079.ddi.openstack.domain: 25024+ PTR?
251.0.0.224.in-addr.arpa....Arrêts et relances
Le but ici est d’arrêter et relancer complètement et le plus proprement possible un environnement OpenStack. Il faut savoir qu’une telle opération est très rarement utile et introduit une part de risque non négligeable si elle n’est pas correctement effectuée.
L’exemple pris concerne un environnement RHOSP, mais il peut être aisément transposable à d’autres environnements. Compte tenu de la multiplicité des services et de leurs interdépendances, il est préférable de privilégier un arrêt manuel au détriment d’un script pour garder un maximum de maîtrise sur l’enchaînement des opérations.
La méthode présentée ici concerne un arrêt/relance de tout le cluster. Il est rare, sauf dans un but de sauvegarde à froid ou de décommissionnement, de devoir arrêter tout un cluster OpenStack.
1. Arrêt et relance des contrôleurs
Commencez par arrêter, s’il existe, le gestionnaire de cluster, afin d’empêcher un éventuel redémarrage automatique. Ici, l’exemple pris est le pacemaker :
stack@undercloud$ ssh heat-admin@controller1
heat-admin@controller1$ sudo pcs cluster stop
heat-admin@controller1$ sudo reboot Attendez le redémarrage complet du contrôleur et contrôler l’état du cluster et l’état des services. Tout doit être lancé et fonctionnel. Les services étant normalement gérés par systemctl, il n’y a pas besoin de les redémarrer manuellement. Dans le cas contraire, et si la dernière commande sort en erreur, activez le démarrage automatique des services au redémarrage.
heat-admin@controller1 $ sudo pcs status
heat-admin@controller1...Créer une image
Créer des images et les personnaliser sont des tâches courantes pour l’administrateur Openstack. Elle peuvent être effectuées assez facilement avec des outils de virtualisation existants : VirtualBox, qemu-img, etc. Il suffit de créer une machine virtuelle dans ces outils et de récupérer le disque virtuel.
Dans la pratique, l’outil le plus utilisé et mis en avant par OpenStack, est diskimage-builder. À vrai dire, cet utilitaire est un wrapper autour de qemu-img.
L’utilitaire s’installe en clonant le repository Git. Il est fortement recommandé d’utiliser l’environnement tox embarqué avec le package :
$ git clone https://opendev.org/openstack/diskimage-builder
$ cd diskimage-builder
$ tox -e bindep
$ sudo apt-get install <les packages qui manquent listés par
la commande précédente> L’utilitaire peut être directement invoqué en ligne de commande si le virtualenv, ou mieux le tox est correctement activé. L’utilitaire peut créer des images aux formats suivants : qcow2, tar, tgz, squashfs, vhd, docker et raw.
Si le back-end de stockage d’images est Ceph, seul le format raw est supporté selon https://access.redhat.com/solutions/2434691, et ceci pour des raisons purement d’optimisation. Selon le cas, les images sont de toute façon converties en raw au niveau des nœuds compute quand elles sont téléchargées.
1. Éléments
Avec diskimage-builder, DIB pour simplifier, la création d’une image est relativement simple et se fait en une instruction :
$ disk-image-create -a amd64 vm base centos7 L’image obtenue est une image très basique de centos7. Elle peut d’ailleurs être explorée avec guestfish. Mais elle n’est...
RHOSP : suppression et ajout d’un nœud compute
Dans un contexte RHOSP où les déploiements sont faits avec TripleO, voici les procédures à suivre pour enlever et/ou ajouter un nœud compute au cluster.
1. Suppression d’un nœud compute
a. Migrer les instances
Avant de pouvoir supprimer un nœud compute de l’overcloud, il faut migrer toutes les instances qui s’y trouvent sur d’autres nœuds, même les instances qui ne sont plus utilisées. En effet, des références à ces instances existent toujours dans OpenStack et peuvent introduire des incohérences ou des erreurs insoupçonnées plus tard.
La même méthode que celle vue plus haut pour les arrêts/relances peut être utilisée pour migrer les instances sur d’autres compute. Une autre alternative est d’utiliser la CLI Nova.
Obtenez la liste des services Nova qui tournent.
$ source ~/stack/overcloudrc
$ nova service-list Désactivez les services sur le nœud qui doit être décommissionné pour éviter le lancement de nouvelles instances sur ce nœud :
$ nova service-disable <nom du nœud> nova-compute Migrez chacune des instances du nœud. Les nœuds seront "re-schédulés" sur des instances automatiquement choisies. Pour chacune des instances :
$ openstack server migrate <nom de l'instance> Surveillez le statut de la migration avec la commande :
$ nova migration-list Quand la migration de chaque instance est terminée, Nova offre la possibilité de les annuler ou de les confirmer en les mettant dans le statut VERIFY_RESIZE. Pour chaque instance dans ce statut, il faudra confirmer la migration avec la commande :
$ nova resize-confirm <nom de l'instance> Quand toutes les instances...
La certification OpenStack
1. Présentation
a. Prérequis
À date, la seule certification officielle d’OpenStack est le COA : Certified Openstack Administrator. C’est un examen accessible à toute personne qui a au moins six mois d’expérience sur OpenStack. Il est même abordable avec moins d’expériences, si celles-ci sont des expériences en production.
Il n’y a pas de formation préalable ni de cycle de certifications. Il est toutefois nécessaire, en plus d’OpenStack, d’avoir de bonnes bases en Linux en ligne de commandes.
b. Le déroulement
Après l’inscription et le paiement des droits d’examen, le candidat est amené à choisir sa date de passage et son créneau horaire. L’examen se fait entièrement en anglais et dure trois heures. Il se fait de préférence depuis un endroit calme et bien éclairé, par visioconférence, avec l’examinateur ayant accès à l’écran du candidat et à son environnement immédiat puisque la caméra doit être allumée. Une inspection de l’environnement physique du candidat est faite à la connexion. Tous les candidats présents se voient pendant toute la durée de l’examen. Évidemment, seul l’examinateur voit les écrans des candidats.
Il est interdit d’interagir entre candidats, mais il est autorisé de poser des questions à l’examinateur soit oralement au début de l’examen soit par message via l’interface de dialogue partagée.
Tout recours aux documentations est interdit, sauf la documentation interne, type man pages existant déjà dans l’environnement.
Les résultats sont envoyés quelques heures à quelques jours après par e-mail...