Plateforme infonuagique : utilisation

4 Plateforme infonuagique : utilisation

Vous allez maintenant utiliser votre plateforme infonuagique pour administrer des serveurs virtuels de calcul et de stockage de données.

4.1 Déverminage

L'infrastructure d'openstack est complexe à déverminer, cette section donne quelques éléments pour savoir où se situent les bogues.

4.1.1 Les fichiers de contrôle

Vous pouvez activer le déverminage dans les services d'openstack. Pour cela, il suffit d'activer l'option debug dans les fichiers de configuration /etc/nova/nova.conf, /etc/nova/nova-compute.conf et /etc/neutron/neutron.conf. Regardez ensuite les informations dans les fichiers .log présents dans les répertoires /var/log/nova et /var/log/neutron. Vous avez aussi des informations intéressantes dans les répertoires /var/log/rabbitmq et /var/log/keystone.

4.1.2 Problème de lancement d'une instance

Quand vous démarrez une instance, une machine virtuelle KVM est lancé sur un de vos noeuds de calcul. Vous pouvez vérifier que cette machine est bien lancée en cherchant les processus contenant qemu-system dans leur nom. Théoriquement vous trouverez un répertoire contenant le disque et les messages de démarrage de l'instance dans le sur-répertoire /var/lib/nova/instances. Le nom du répertoire de votre instance est son identifiant que vous pouvez trouver dans l'interface Web. Si vous ne trouvez ni le processus ni le répertoire de l'instance, regardez dans les fichiers de contrôle sur le noeud de calcul et sur le noeud contrôleur, la raison de l'échec doit y être indiquée. Si la machine virtuelle est bien démarrée, cherchez l'option -spice pour trouver le port d'écoute de la console. Vous pouvez ensuite vous connecter sur cette console en utilisant un client spice comme spicec du paquetage spice-client.

4.1.3 Problème de connexion réseau

L'architecture réseau de neutron est très sophistiquée. Nous allons tenter d'en remonter le fil à partir d'un noeud réseau.

Interface de l'instance :: examinez les options du processus qemu-system de votre instance pour trouver l'adresse Ethernet de l'instance, listez les interfaces tap sur votre noeud de calcul avec la commande ip tuntap show, cherchez celle qui possède une adresse MAC de même suffixe que celle de votre machine (seul l'octet de poids fort diffère).
Connexion sur le commutateur d'intégration :: trouvez dans quel commutateur virtuel Linux se trouve l'interface tap de votre instance en utilisant la commande brtcl show, cherchez l'interface qui se trouve dans le même commutateur virtuel Linux dans le commutateur virtuel openVSwitch d'intégration br-int, vous pouvez lister les interfaces dans br-int avec la commande ovs-vsctl show.
Connexion sur votre instance :: vous pouvez faire un test de connexion au niveau du noeud de calcul, il suffit de créer une interface de type VLAN au dessus du commutateur openVSwitch br-int, utilisez pour cela l'utilitaire vconfig du paquetage vlan, le numéro du VLAN à utiliser est celui du tag openVSwitch, affectez une adresse IPv4 à votre nouvelle interface dans le réseau IPv4 de votre instance, vous pouvez alors vous connecter par ssh sur l'instance.
Connexion avec le noeud réseau :: vous pouvez constater dans la sortie de la commande ovs-vsctl show que le commutateur d'intégration br-int est connecté au commutateur des tunnels br-tun via les interfaces patch-tun et patch-int, la connexion est réalisée via des régles qui sont affichées par la commande ovs-ofctl dump-flows br-tun, les paquets sont alors transmis au noeud réseau via le tunnel GRE listé dans le commutateur br-tun, notez que ces tunnels utilisent des adresses IPv4 du réseau des tunnels.
Test de connectivité :: lancez, de votre instance, un ping sur le serveur DHCP virtuel et analysez les paquets à destination de l'adresse IPv4 dans le réseau des tunnels de votre noeud réseau avec la commande tcpdump -n -vvv -i eth0 host <@IPv4 contrôleur>, vous devez voir passer des paquets ICMP encapsulés dans le protocole GRE, vous pouvez faire la même chose sur le noeud réseau.
Arrivé sur le noeud réseau :: le noeud réseau comporte les mêmes commutateurs openVSwitch br-tun et br-int, le même dispositif permet de récupérer les paquets via un tunnel GRE et grâce à des régles openVSwitch de les envoyer dans différents VLANs sur le commutateur d'intégration, vous pouvez afficher les commutateurs et les régles openVSwitch via les commande ovs-vsctl show et ovs-ofctl dump-flows br-tun.
Seconde connexion sur votre instance :: vous pouvez faire un test de connexion au niveau du noeud réseau, il suffit de créer une interface de type VLAN au dessus du commutateur openVSwitch br-int, utilisez pour cela l'utilitaire vconfig du paquetage vlan, le numéro du VLAN à utiliser est celui du tag openVSwitch, affectez une adresse IPv4 à votre nouvelle interface dans le réseau IPv4 de votre instance, vous pouvez alors vous connecter par ssh sur l'instance.
Connexion au serveur DHCP virtuel :: listez les différentes instances de pile TCP/IP sur votre noeud réseau avec la commande ip netns show, prenez l'instance préfixée par qdhcp-, listez les interfaces dans cette instance avec la commande ip netns exec qdhcp-... ip address show, vous trouvez l'adresse IPv4 du serveur DHCP sur une interface tap, cette interface se retrouve dans le commutateur br-int et comme argument d'un processus dnsmasq.
Connexion au routeur virtuel :: listez les différentes instances de pile TCP/IP sur votre noeud réseau avec la commande ip netns show, prenez l'instance préfixée par qrouter-, listez les interfaces dans cette instance avec la commande ip netns exec qrouter-... ip address show, vous trouvez les adresses IPv4 du routeur sur deux interfaces Ethernet virtuelles, une interface se retrouve dans le commutateur openVSwitch br-int et une autre dans le commutateur openVSwitch br-ex avec l'interface vers Internet eth2.
Troisième connexion sur votre instance :: vous pouvez faire un second test de connexion au niveau du noeud réseau, il suffit pour cela d'affecter une adresse IPv4 au commutateur openVSwitch br-ex, adresse dans le réseau IPv4 routé bien entendu, après avoir ajouté une route du réseau privé de votre projet vers l'adresse routée de votre routeur virtuel, vous pouvez vous connecter par ssh sur l'instance.
Quatrième connexion sur votre instance :: un troisième test de connexion au niveau du noeud réseau est possible, autorisez la connexion par ssh sur l'instance, trouvez l'espace TCP/IP d'un routeur de votre nuage et utilisez la commande ip netns exec qrouter-... ssh cirros@<IP>.

Si vous avez commis des erreurs dans les fichiers de configuration des extensions de neutron des tunnels GRE peuvent avoir été créés avec des adresses IP fantaisistes. Pour supprimer ces tunnels qui peuvent perturber les connexions réseau, supprimez les adresses superflues dans la table ml2_gre_endpoints.

4.2 Tests avancés

Avant de vous lancer dans des exercices plus complexes d'utilisation d'openstack vous pouvez effectuer quelques tests pour vérifier que votre infrastructure infonuagique fonctionne.

4.2.1 Première instance

Créez un réseau privé dans le projet Admin. Vous pouvez utiliser 192.168.0.0/24 comme réseau IPv4. Lancez une instance de votre image cirros sur ce réseau. Consultez avec votre interface Web les messages de démarrage de votre instance (onglet log). Vous ne pourrez pas utiliser la console car, pour l'instant, le client spice javascript ne fonctionne qu'avec des claviers qwerty. Vous pouvez vous connecter en utilisant le client spice spicy du paquetage spice-client-gtk en parallèle avec le clavier virtuel florence. Une fois connecté sur l'instance, vérifiez que vous pouvez pinguer le serveur DHCP virtuel.

4.2.2 Connexion à Internet

Créez, en tant qu'administrateur global, un réseau partagé et externe sans adresse de passerelle et sans DHCP. Comme réseau IPv4 utilisez TP-NET2, l'adresse de la passerelle est la dernière de ce réseau. Attention à utiliser comme intervalle d'adresses disponibles pour votre architecture info-nuagique un bloc non utilisé par les autres implantations. Votre bloc peut inclure une dizaine d'adresses.

Ensuite, dans le projet Admin, créez un routeur virtuel avec, comme passerelle, ce réseau externe. Ajoutez à ce routeur une interface dans le réseau local. Vérifiez que votre instance a désormais accès à Internet.

Ajoutez une adresse routée flottante à votre instance. Vérifiez qu'elle peut être pinguée d'Internet après avoir autorisé le protocole ICMP pour l'instance.

4.3 Maquette avec des projets distincts

Le but de cette réalisation est d'explorer les possibilités d'openstack en terme de cloisonnement des projets.

4.3.1 Architecture réseau

Supprimez l'instance et le réseau privé du projet Admin mais gardez le réseau partagé et externe. Créez ensuite un projet par binôme (tenants en anglais) nommés par exemple Projet1, Projet2, etc. Ajoutez à ces projets l'utilisateur admin avec un rôle d'administrateur. Créez deux réseaux privés dans chaque projet. Vous pouvez utiliser les réseaux IPv4 192.168.1.0/24 et 192.168.2.0/24. Toujours dans chaque projet, créez un routeur virtuel entre vos deux réseaux privés.

4.3.2 Déploiement d'instances

Lancez deux instances sur chaque réseau local. Connectez-vous avec spicy sur une instance, vérifiez que vous pouvez contacter l'autre. Autorisez les accès SSH sur vos instances en ajoutant la règle ad hoc dans le groupe de sécurité par défaut. Connectez-vous d'une instance sur l'autre.

Vérifiez que toutes les instances ne sont pas lancées sur le même noeud de calcul. Vérifiez que chaque noeud de calcul fonctionne, c'est à dire qu'ils hébergent tous au moins une instance.

Vérifiez la connectivité entre des instances de projets différents.

4.3.3 Connexion à Internet

Ensuite, dans votre projet, créez un routeur virtuel avec, comme passerelle, le réseau externe. Ajoutez à ce routeur une interface dans un de vos réseaux locaux. Vérifiez que votre instance a désormais accès à Internet.

Ajoutez une adresse routée flottante à votre instance. Vérifiez que l'on peut se connecter dessus en provenance d'Internet avec ssh.

4.4 Architecture Web

Utilisez openstack pour réaliser une ferme de serveurs Web. Une instance avec une adresse IP flottante doit transmettre les requêtes HTTP à des instances privées tout en assurant un équilibrage de charge. Pour cette maquette, une image de type Debian va être nécessaire.

Votre système doit permettre un ajout automatique d'instance privée. Vous devez pouvoir générer un cliché (snapshot) de votre instance implantant un serveur Web privé, ajouter une instance à partir de ce cliché et faire en sorte que cette nouvelle instance soit automatiquement prise en compte. Il suffit qu'au lancement de l'instance un script modifie la configuration apache2 de votre instance d'équilibrage de charge et relance le service.

Un contrôle du bon fonctionnement du système doit pouvoir se faire en utilisant le gestionnaire apache2 de l'équilibrage de charge (voir 2.7).

4.5 Stockage distribué

Ajoutez un mandataire swift sur le noeud contrôleur et des conteneurs swift sur les noeuds que vous utilisez déjà comme noeuds de calcul. Testez cette fonctionnalité.

4.6 Programmation distribuée

Déployez le programme de calcul de l'ensemble de Mandelbrot disponible à l'URL http://docs.openstack.org/developer/taskflow/examples.html sur vos noeuds de calcul. Vérifiez que l'ensemble est calculé plus vite quand le nombre de tâches augmente.