Fabrique à nuages

Xavier Redon

1   Introduction

Cet atelier vise à vous expliquer, par la pratique, ce qu'est l'infonuagique. La méthode consiste à vous faire installer une plateforme infonuagique. Votre plateforme devra permettre le déploiement de serveurs virtuels pour exécuter un calcul de Mandelbrot en parallèle et le stockage distribué de documents divers.

Même en 2016/2017, cet objectif reste ambitieux. Il est donc prévu de commencer par un exercice mieux maîtrisé à base de machines virtuelles, de gestion DNS et de serveurs Web.

2   Mise en jambes

Le but de ce premier exercice est, pour chaque binôme, d'implanter un serveur web accessible d'Internet en utilisant une seule adresse IPv4 routée pour l'ensemble de la promotion. Dans un second temps il est demandé de sécuriser les serveurs Web.

2.1   Architecture

L'architecture de votre système doit être composée d'un serveur virtuel de redirection Web commun à la promotion et d'un serveur virtuel pour chaque binôme. Le serveur de redirection doit avoir deux interfaces réseau : une dans le VLAN ALTERNATE et une dans le VLAN INSECURE. L'interface ALTERNATE permet l'accès en provenance d'Internet et l'interface INSECURE permet la communication avec les serveurs virtuels des binômes. Comme adresse IPv4 dans le VLAN ALTERNATE, vous utiliserez 5.23.44.84/29 et 5.23.44.85/29 suivant le groupe de TD. Le serveur de redirection doit avoir comme adresse de passerelle 5.23.44.81.

Pour les adresses dans le VLAN INSECURE, vous utilisez les adresses IPv4 dans la plage 172.26.79.100 à 172.26.79.139 sachant que le masque réseau est 255.255.240.0.

Comme adresse IPv4 de serveur DNS vous pouvez utiliser 193.48.57.34.

2.2   Machines virtuelles

Vous devez créer des machines virtuelles sur le serveur physique chassiron.insecserv.deule.net (mot de passe administrateur habituel). Tous vos objets (serveurs virtuels et partitions logiques) doivent être préfixés par gis4- puis, par binôme, par un nom pris dans un thème commun à la promotion. D'un point de vue réseau les ponts virtuels à utiliser sont bridgeAlternate et bridgeInsecure.

La création des machines virtuelles fera par la commande xen-create-image. Il faut préciser à cet utilitaire le nom de votre machine (option --hostname), la configuration réseau (option --dhcp dans un premier temps) et le répertoire où les disques virtuels doivent être créés (option --dir), c'est-à-dire /usr/local/xen. Une fois la machine créée, modifiez son fichier /etc/network/interfaces pour y implanter la configuration réseau correcte. Utilisez ping pour tester la connexion réseau entre votre machine virtuelle, le serveur de redirection et votre machine de TP.

Installez des serveurs ssh et Web (paquetages openssh-server et apache2) dans vos serveurs. Créez un petit site Web sur votre serveur virtuel.

2.3   Nom DNS

Trouvez un nom pour votre serveur Web. Vous pouvez par exemple prendre le nom de votre machine virtuelle comme nom de base. Le domaine de votre nom sera stratocumulus.org. Ce domaine est géré par le registrar GANDI sous le compte XR206-GANDI (mot de passe habituel). Vous utiliserez l'interface de GANDI pour ajouter un enregistrement à votre nom de serveur Web pointant vers le serveur de redirection Web.

2.4   Configurations Web

Pour que votre site Web soit accessible, il vous faut modifier deux configurations de serveurs Apache. Celle du serveur de redirection et celle du serveur de votre binôme. Sur le serveur de redirection vous aurez pris soin de vérifier que les modules Apache proxy et proxy_http soient activés. Il vous faut aussi y définir un site Web virtuel (répertoire /etc/apache2/sites-available). Pour cela documentez-vous en trouvant des exemples d'utilisation des blocs VirtualHost et des directives Proxy* dans les configurations Apache. Vous devez aussi configurer votre site sur votre serveur virtuel de binôme. Pour ce dernier vous n'avez pas besoin des directives concernant le proxy.

Vérifiez que votre site est opérationnel, en particulier qu'il est accessible en dehors de l'école.

2.5   Certificat X509

Maintenant, il s'agit de sécuriser votre site en utilisant HTTPS. Pour cela vous allez utiliser l'autorité de certification "Let's Encrypt" : https://letsencrypt.org/. La version stretch de la distribution Debian comprend un paquetage letsencrypt. Ajoutez dans le fichier de configuration /etc/apt/sources.list une référence à cette version de la distribution Debian. Mettez à jour la liste des paquetages avec la commande apt-get update. Installez le paquetage letsencrypt. Pour éviter des soucis de mélange de version, retirez les références à la version stretch. Le certificat X509 s'obtient très facilement avec la commande letsencrypt certonly avec la méthode --webroot. Attention cependant cette méthode doit être utilisée sur votre machine virtuelle de binôme alors que le certificat est requis sur le serveur de redirection.

2.6   Configuration sécurisée

Modifiez les configurations Apache en utilisant les directives SSL* pour utiliser le protocole HTTPS. Attention vous ne pourrez définir de multiples sites sécurisés avec Apache que si votre version d'Apache implante le protocole SNI (Server Name Indication, RFC 4366). La plupart des navigateurs font confiance aux certificats de "Let's Encrypt", vous ne devriez donc pas avoir à inclure d'autorité de certification dans votre navigateur.

Vérifiez que votre site est opérationnel, en particulier faites afficher le certificat X509 de votre site à votre navigateur.

2.7   Equilibrage de charge

Vous venez de créer une ferme de sites Web sécurisés mais que va-t-il se passer en cas de succès ? Vos serveurs Web vont devoir supporter une charge de plus en plus importante et éventuellement refuser des connexions. Vous allez donc dupliquer votre serveur. Commencez par créer un ou plusieurs nouveaux hyperviseurs sur des machines de projet. Ensuite copiez les fichiers de votre machine virtuelle sur un des nouveaux hyperviseurs. N'oubliez pas de mettre à jour adresses Ethernet et IPv4 (utilisez des IPv4 à partir de 172.26.79.220). Pour modifier le nom de votre nouvelle machine, éditez les fichiers /etc/hostname, /etc/mailname et /etc/hosts. Vous devriez obtenir un clone fonctionnel de votre serveur Web. Sur le serveur de redirection, ajoutez les modules Apache d'équilibrage de charge proxy_balancer et lbmethod_byrequests. Enfin déclarez vos deux sites Web dans votre définition de site virtuel en utilisant les balises Proxy. Vous pouvez tester le gestionnaire de répartition qui peut être intégré au serveur de redirection.

2.8   Haute disponibilité

Ceux qui veulent aller plus loin constateront une faille dans l'architecture de notre système. Si le serveur de redirection tombe, les sites Web deviennent indisponibles. Il est proposé de créer un système résistant aux pannes en couplant les serveurs de redirection des deux groupes de TD. Pour cela il faut définir les sites virtuels des deux groupes sur les deux serveurs de redirection et privilégier une des deux adresses IPv4 routées. Il faut aussi installer un système de gestion d'adresse virtuelle avec le paquetage heartbeat. Le serveur de redirection actif s'attribuera l'adresse IPv4 routée. Si jamais il tombe, le serveur de secours s'appropriera cette adresse. La configuration d'heartbeat s'effectue dans 3 fichiers du répertoire /etc/ha.d/. Ces fichiers de configuration sont ha.cf, haresources et authkeys. Des exemples sont disponibles dans le répertoire /usr/share/doc/heartbeat ou sur Internet.

3   Plateforme infonuagique : installation

Vous allez installer une plateforme infonuagique libre : OpenStack. Cette installation est assez complexe et demande la configuration de plusieurs machines : le noeud contrôleur, la noeud réseau et des noeuds de calcul. Les deux premiers noeuds seront installés dans des machines virtuelles Xen et les noeuds de calcul seront installé dans des machines virtuelles KVM.

3.1   Guide d'installation d'openstack

Cette procédure d'installation est fortement inspirée du document http://docs.openstack.org/icehouse/install-guide/install/apt-debian/content/ auquel vous pouvez vous référer à tout moment. Vous remarquerez que ce document concerne une ancienne distribution Debian et une encore plus ancienne version d'openstack : icehouse. Ce manuel convient pour l'actuelle distribution stable de la distribution Debian, à savoir jessie. N'hésistez pas à installer la version de test de la Debian, à savoir stretch, qui propose l'actuelle version stable d'openstack : newton.

3.2   Principe de rigueur

Pour une installation de cette complexité un peu de rigueur est de mise. Vous allez donc tenir, sur chaque machine, un cahier d'installation sous la forme d'un fichier texte /root/notes. Il est recommandé de sauver régulièrement ces fichiers. Vous inscrirez dans ces cahiers toutes les étapes réalisées en précisant tout particulièrement les identifiants et mots de passe utilisés.

3.3   Détail de l'architecture système

Votre infrastructure infonuagique doit être constitué de 4 machines, 2 machines virtuelles Xen et 2 machines virtuelles KVM. Vous utiliserez le serveur de virtualisation chassiron.insecserv.deule.net pour héberger les machines virtuelles Xen. Il faut allouer 2,5Go de mémoire au noeud contrôleur. Pour le noeud réseau, 512Mo suffisent. Pour le nom des machines virtuelles, utilisez gis4- comme préfixe et -ctl et -net comme suffixes. Les machines virtuelles KVM doivent être installées sur des machines de projet. Commencez par utiliser celle sur laquelle vous travaillez. Quand votre infrastructure fonctionnera vous ajouterez un second noeud de calcul.

3.4   Distribution Linux Debian

La distribution Linux Debian fut une distribution respectant l'esprit de simplicité d'Unix. D'où son succès jusqu'ici. Depuis quelques années on peut noter quelques entorses à ce précepte. Probablement pour adresser le marché des machines de bureautique. Citons par exemple l'installation par défaut de Gnome comme environnement graphique. Les machines sur lesquelles vous travaillerez n'utilisent pas cet environnement inutilement complexe. Deux autres systèmes sont à prohiber si vous souhaiter garder le contrôle de votre système d'exploitation. Il s'agit des paquetages network-manager et systemd. Le premier tente de configurer automatiquement les interfaces réseau ce qui est un peu génant quand vous souhaitez le faire vous-même. N'hésitez pas à supprimer ce paquetage. Notez que network-manager est un prérequis pour Gnome ce qui est une raison suffisante pour qu'un utilisateur averti évite cet environnement graphique. Le paquetage systemd se veut un remplacement moderne pour le classique système de démarrage des services Unix sysvinit. Le moins que l'on puisse dire c'est qu'il ne fait pas l'unanimité. Actuellement, le paquetage systemd se montre incapable de démarrer les services d'openstack dans la version Jessie. Il est donc conseillé d'installer le classique sysvinit, de supprimer systemd (par exemple avec la commande apt-get purge et de relancer votre machine. Si vous effectuez ce remplacement dans une machine virtuelle Xen, modifiez la ligne ci-dessous dans le fichier /etc/inittab avant le redémarrage de la machine. 
1:2345:respawn:/sbin/getty 38400 hvc0
Pour des "raisons de sécurité" (meilleure excuse du 21ème siècle pour faire n'importe quoi), la connexion à distance sur une machine Debian avec le compte root est interdit. Comme nous n'avons que cet utilisateur sur nos machines virtuelles, il faut pouvoir activer cette fonctionnalité. Editez le fichier /etc/ssh/sshd_config et modifiez la valeur de l'option PermitRootLogin en yes. Relancez ssh : service ssh restart.

Par ailleurs, utilisez la commande ci-dessous pour pouvoir utiliser des bases de données distantes avec l'interface de configuration debconf. 
apt-get install dbconfig-common && dpkg-reconfigure dbconfig-common

3.5   Détail de l'architecture réseau

Trois réseaux IPv4 vont être utilisés dans votre infrastructure infonuagique : un réseau de gestion, un réseau pour établir les tunnels entre les instances et un réseau d'accès à Internet.

Le premier est le réseau INSECURE 172.26.64.0/20. Pour vos machines virtuelles vous allez choisir deux adresses IPv4 consécutives dans la plage 172.26.79.140 à 172.26.79.219. Donnez la première adresse au noeud contrôleur et la seconde au noeud réseau. Vous pouvez, par exemple, pour le premier groupe utiliser 172.26.79.140+2x et 172.26.79.141+2x où x est votre numéro de machine de projet. Les machines de projet ont déjà une adresse IPv4 dans le réseau INSECURE. Quand une adresse IPv4 vous est demandée dans les écrans de configuration utilisez celles du réseau INSECURE.

Le second réseau IPv4 que vous utiliserez est un réseau privé 192.168.y.0/24. Pour le premier groupe, vous pouvez prendre pour y la valeur de 140+2x. Vous allez ajouter une interface réseau eth1 au noeud réseau et vous donnerez l'adresse 192.168.y.1 à cette nouvelle interface. Vous allez aussi ajouter une adresse IPv4 de 192.168.y.0/24 aux noeuds de calcul, là aussi sur une seconde interface réseau.

Enfin le troisième réseau IPv4 à utiliser est le réseau TP-NET2 193.48.65.192/26. Seul le noeud réseau possédera une interface dans ce réseau. Ajoutez lui donc une interface réseau dans le commutateur virtuel bridgeInternet.

Il vous faut tester votre architecture réseau via des ping et des ssh entre les différentes machines et en utilisant leurs adresses dans INSECURE et dans votre réseau privé. Testez l'interface publique du noeud réseau en utilisant la commande ip pour lui affecter une adresse et une route par défaut vers Internet via 193.48.65.254. Utilisez ping sur une machine d'Internet pour vérifier la connectivité.

Chaque machine doit être synchronisée par NTP avec le serveur NTP de l'école : ntp.polytech-lille.fr. Ajoutez donc les paquetages ntpdate et ntp. Modifiez les fichiers de configuration /etc/default/ntpdate et /etc/ntp.conf. Relancez le service ntp avec la commande service.

3.6   Installation du noeud contrôleur

Le noeud contrôleur doit comporter les services suivants :

3.6.1   Installation de la base de données

Commencez par installer les paquetages mysql-server et phpmyadmin. Vous rendrez la base de données accessible par réseau en modifiant le paramètre bind-address dans le fichier de configuration /etc/mysql/my.cnf ou /etc/mysql/mysql.conf.d/mysqld.cnf suivant la version de votre Debian. Relancez le service. Faites en sorte que toutes les machines du réseau INSECURE puissent se connecter à votre serveur MySQL en utilisant l'utilisateur root. Pour cela utilisez l'interface Web phpmyadmin.

Testez votre configuration en installant le paquetage mysql-client sur vos autres machines et en utilisant la commande mysql pour lister les bases présentes sur le serveur (vous devez au minimum voir la base de phpmyadmin).

3.6.2   Installation du service d'échange de messages

Un service d'échange de messages compatible avec OpenStack est RabbitMQ. Installez le sur le noeud contrôleur via le paquetage rabbitmq-server. Il est préférable de changer le mot de passe du compte que nous allons utiliser dans la suite de l'installation par la commande ci-dessous. 
rabbitmqctl change_password guest <votre mot de passe>
Il faut aussi autoriser ce compte à être utilisé par d'autres machines de votre réseau privé. Cela se fait en créant un fichier de configuration /etc/rabbitmq/rabbitmq.config contenant le texte ci-dessous. 
[{rabbit, [{loopback_users, []}]}].
Pour tester un minimum votre service d'échange de messages installez l'extension rabbitmq_management par la commande rabbitmq-plugins enable rabbitmq_management. N'oubliez pas de relancer le service. Vous pouvez ensuite vous connecter sur l'interface Web de gestion de RabbitMQ. Utilisez l'adresse IPv4 INSECURE de votre noeud contrôleur et le port 15672.

3.6.3   Installation du service d'identification

Ce service d'OpenStack est utilisé comme service d'identification mais aussi comme répertoire des autres services d'OpenStack installés. Vous constaterez, lors des installations, qu'il vous est souvent demandé si vous voulez enregistrer votre service. C'est auprès de keystone que l'enregistrement se fera. Le nom du paquetage à installer est keystone. Notez bien la clef (token) que vous déclarez ainsi que le mot de passe du compte administrateur.

Pour tester le bon fonctionnement de keystone, créez un petit script /root/credits contenant les lignes suivantes. 
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=<votre mot de passe>
export OS_AUTH_URL=http://127.0.0.1:35357/v2.0
Incluez ce script dans votre session courante et vérifiez que les commandes ci-dessous ne générent pas d'erreurs. 
keystone token-get
keystone user-list
Pour les versions plus récentes d'OpenStack vous pouvez tester avec la commande 
openstack user list
Pour tester votre clef, vous pouvez créer un second script /root/token contenant juste deux lignes. 
export OS_SERVICE_TOKEN=<votre clef>
export OS_SERVICE_ENDPOINT=http://127.0.0.1:35357/v2.0
Après inclusion, la commande keystone user-list doit toujours lister votre utilisateur administrateur.

Pour la suite de l'installation nous allons créer un groupe de services avec la commande suivante. 
keystone tenant-create --name=service --description="Service Tenant"
Pour les versions plus récentes vous pouvez utiliser la commande ci-dessous. 
openstack create project --description="Service Tenant" service

3.6.4   Installation du service de gestion des images disque

Le service d'OpenStack qui gère les images disque système des système d'exploitation à virtualiser s'appelle glance. C'est aussi le nom du paquetage Debian à installer. Veillez à ce qu'il s'enregistre bien auprès de keystone.

Il peut être intéressant de créer un utilisateur glance avec les droits d'administration sur ce service, sans avoir à recourir à admin. 
keystone user-create --name=glance --pass=<mot de passe pour glance> --email=root@localhost
keystone user-role-add --user=glance --tenant=service --role=admin
Pour les nouvelles version d'OpenStack les commandes sont : 
openstack user create --password=<mot de passe pour glance> --email=root@localhost glance
openstack role add --user=glance --project=service admin
Faites aussi en sorte que la base glancedb soit accessible de INSECURE en utilisant le compte glance-common avec le mot de passe déjà spécifié à l'installation.

Pour tester le bon fonctionnement de ce service, commencez par vérifier qu'il s'est bien enregistré par keystone service-list. Ensuite récupérez une image d'un système test en utilisant les commandes ci-dessous. 
cd /tmp
wget http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
Tentez de déposer cette image dans glance par la commande suivante. 
glance image-create --name=cirros034 --disk-format=qcow2 --container-format=bare --is-public=true < cirros-0.3.4-x86_64-disk.img
Si tout se passe bien vous pouvez ensuite la retrouver dans l'entrepôt des images par la commande glance image-list. Pour les versions plus récentes d'OpenStack les commandes sont données ci-dessous. 
openstack image create --disk-format=qcow2 --container-format=bare --public cirros034 < cirros-0.3.4-x86_64-disk.img
openstack image list

3.6.5   Installation du service de calcul

Ce service supervise les instances, c'est à dire les machines virtuelles que les utilisateurs de l'infastructure infonuagique décident de déployer. Les paquetages Debian à installer pour ce service sont nova-api, nova-cert, nova-conductor, nova-consoleauth, nova-consoleproxy, nova-scheduler et python-novaclient. Comme interfaces de programmation, spécifiez osapi_compute et metadata.

L'accès à la console des instances doit se faire avec le protocole spice HTML5. Comme le configurateur Debian debconf n'est pas encore au point à ce sujet vous devez ajouter à la main l'adresse IPv4 INSECURE du contrôleur dans la directive html5proxy_base_url du fichier /etc/nova/nova.conf. Le configurateur Debian produit une configuration dépréciée pour la section [keystone_authtoken] du même fichier. Utilisez le format ci-dessous pour la section. 
[keystone_authtoken]
identity_uri = http://<@IPv4 INSECURE controleur>:35357
auth_uri = http://<@IPv4 INSECURE controleur>:5000/v2.0/
admin_tenant_name = admin
admin_user = admin
admin_password = <mot de passe>
Pour l'interaction entre nova et neutron, il est nécessaire de créer un utilisateur nova avec les droits d'administration sur ce service, sans avoir à recourir à admin. 
keystone user-create --name=nova --pass=<mot de passe pour nova> --email=root@localhost
keystone user-role-add --user=nova --tenant=service --role=admin
Pour les nouvelles version d'OpenStack les commandes sont : 
openstack user create --password=<mot de passe pour nova> --email=root@localhost nova
openstack role add --user=nova --project=service admin
Faites aussi en sorte que la base novadb soit accessible de INSECURE en utilisant le compte nova-common avec le mot de passe déjà spécifié à l'installation. Pour les version plus récentes d'OpenStack il faut aussi rendre la base novaapidb accessible de INSECURE en utilisant le compte nova-api.

Un test minimal de la bonne installation de ce service peut être effectué en vérifiant que la commande nova image-list donne le même résultat que la commande glance image-list.

Pour les versions plus récentes d'OpenStack essayez la commande openstack compute service list vous devez obtenir une liste de services sur votre contrôleur.

3.6.6   Installation du service réseau

L'installation du service réseau est l'un des plus complexes. Ce service, appelé neutron, vous permettra par l'intermédiaire d'une application Web de définir un réseau virtuel pour vos machines virtuelles. Le réseau virtuel comportera des réseaux locaux virtuels et et des routeurs virtuels.

Le paquetage à installer est neutron-server. Tentez de vous en tenir, dans un premier temps, à la configuration automatique de Debian. Nous allons configurer neutron avec comme pilote réseau ML2 (Modular Layer 2). ML2 sera, à son tour, configuré pour utiliser le mécanisme réseau openVSwitch (mécanisme de commutateur virtuel) avec comme type de transport inter-machines des tunnels GRE.

La modification pour la section [keystone_authtoken] du fichier de configuration de nova doit aussi être effectuée dans le fichier de configuration de neutron : /etc/neutron/neutron.conf.

Pour l'interaction entre nova et neutron, il est nécessaire de créer un utilisateur neutron avec les droits d'administration sur ce service, sans avoir à recourir à admin. 
keystone user-create --name=neutron --pass=<mot de passe de neutron> --email=root@localhost
keystone user-role-add --user=neutron --tenant=service --role=admin
Pour les nouvelles version d'OpenStack les commandes sont : 
openstack user create --password=<mot de passe pour neutron> --email=root@localhost neutron
openstack role add --user=neutron --project=service admin
Faites aussi en sorte que la base neutrondb soit accessible de INSECURE en utilisant le compte neutron-common avec le mot de passe déjà spécifié à l'installation.

Pour la version icehouse d'openstack, la configuration des notifications de neutron vers nova n'est pas effectuée par le configurateur Debian. Il vous faut donc modifier le fichier de configuration /etc/neutron/neutron.conf à la main. Trouvez les directives de la section [DEFAULT] décrites ci-dessous et modifiez les valeurs comme indiqué. 
notify_nova_on_port_status_changes=True
notify_nova_on_port_data_changes=True
nova_url=http://<@IPv4 INSECURE controleur>:8774/v2
nova_admin_username=nova
nova_admin_tenant_id=<identifiant du groupe de services>
nova_admin_password=<mot de passe de l'utilisateur nova>
nova_admin_auth_url=http://<@IPv4 INSECURE controleur>:35357/v2.0
Vous pouvez trouver l'identifiant du groupe de services avec la commande keystone tenant-get service.

De la même façon il faut modifier le fichier de configuration de nova /etc/nova/nova.conf pour que le service de supervision des instances sache comment gérer la partie réseau via neutron. Trouvez les directives de la section [DEFAULT] décrites ci-dessous et modifiez les valeurs comme indiqué. 
network_api_class=nova.network.neutronv2.api.API
security_group_api=neutron
linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver
firewall_driver=nova.virt.firewall.NoopFirewallDriver

neutron_url=http://<@IPv4 INSECURE controleur>:9696
neutron_auth_strategy=keystone
neutron_admin_tenant_name=service
neutron_admin_username=neutron
neutron_admin_password=<mot de passe de l'utilisateur neutron>
neutron_admin_auth_url=http://<@IPv4 INSECURE controleur>:35357/v2.0
Enfin il faut configurer le pilote ML2 via son fichier de configuration /etc/neutron/plugins/ml2/ml2_conf.ini. Les directives à activer sont données ci-après.

[ml2]
type_drivers=gre
tenant_network_types=gre
mechanism_drivers=openvswitch

[ml2_type_gre]
tunnel_id_ranges=1:1000

[securitygroup]
enable_security_group=True
firewall_driver=neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
Un test basique pour vérifier le fonctionnement de neutron est de tenter la commande neutron net-list ou openstack network list sur les versions plus récentes. Comme vous n'avez pas encore créé de réseau virtuel la commande doit vous retourner une liste vide mais sans erreur.

3.6.7   Installation de l'application Web

L'élément indispensable à toute infrastructure infonuagique est l'application Web de configuration des architectures virtuelles. Elle permet aux utilisateurs de définir leurs architectures sans se préoccuper des couches système et réseau sous-jacentes.

Pour dashboard, vous devez installer les paquetages apache2, memcached , libapache2-mod-wsgi, openstack-dashboard et openstack-dashboard-apache.

Pour accélérer l'application Web vous pouvez la configurer pour utiliser lee système de cache distribué memcached. Modifiez comme indiqué ci-dessous la valeur de CACHES dans le fichier de configuration /etc/openstack-dashboard/local_settings.py .

CACHES = {
  'default': {
  'BACKEND' : 'django.core.cache.backends.memcached.MemcachedCache',
  'LOCATION' : '127.0.0.1:11211'
  }
}
Si, en testant l'application Web à l'URL https://<@IPv4 INSECURE controleur>/, vous rencontrez une erreur HTTP de type 500, ce peut être à cause du nouveau paquetage python-django pour lequel dashboard n'est pas encore adapté. Une solution consiste à rétrograder à la version 1.6.5 du paquetage. Vous trouverez ce paquetage sur le site http://debian.org. Installez-le à l'aide de la commande dpkg -i. Vous aurez peut être à supprimer un autre paquetage de la nouvelle version à l'aide de la commande dpkg --purge.

3.6.8   Finalisation de l'installation

Vous pouvez redémarrer la machine virtuelle contrôleur vu le grand nombre de modifications apportées. Pour faire un premier test vous pouvez vous connecter de votre machine de projet sur dashboard et vous connecter avec admin. Le tour de l'application Web sera limité vu que vous n'avez pas encore configuré de noeud réseau et de noeud de calcul.

3.7   Installation du noeud réseau

Le noeud réseau ne comporte que des services liés à neutron mais possède une interface réseau d'accès à Internet. Installez les paquetages Debian neutron-plugin-ml2, neutron-plugin-openvswitch-agent, neutron-l3-agent, neutron-dhcp-agent et neutron-metadata-agent.

La modification pour la section [keystone_authtoken] du fichier de configuration /etc/neutron/neutron.conf doit être appliquée comme pour l'installation de neutron sur le noeud contrôleur.

Il faut permettre le routage au niveau de la machine virtuelle Linux. Le fichier système /etc/sysctl.conf doit être modifié pour que les variables système ci-dessous aient les valeurs indiquées. 
net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
Un commutateur virtuel de type openVSwitch doit être créé manuellement pour la sortie vers Internet. Les commutateurs virtuels openVSwitch sont une version plus versatile des commutateurs virtuels Linux vus en cours. La création du commutateur se fait à l'aide des deux commandes suivantes. 
ovs-vsctl add-br br-ex
ovs-vsctl add-port br-ex eth2
Quelques autres configurations manuelles sont nécessaires. Il faut maintenant permettre la communication entre le module metadata de neutron sur le noeud réseau et nova sur le noeud contrôleur. Sur le noeud réseau modifiez le fichier de configuration /etc/neutron/metadata_agent.ini pour qu'il contienne les informations ci-dessous.

auth_url=http://<@IPv4 INSECURE controleur>:5000/v2.0
admin_tenant_name=service
admin_user=neutron
admin_password=<mot de passe de l'utilisateur neutron>
nova_metadata_ip=<@IPv4 INSECURE controleur>
metadata_proxy_shared_secret=<secret>
Pour les versions plus récentes d'OpenStack, modifiez simplement la directive nova_metadata_ip.

Sur le noeud contrôleur éditez le fichier de configuration /etc/nova/nova.conf et modifiez les directives ci-après dans la section [DEFAULT]. 
service_neutron_metadata_proxy=true
neutron_metadata_proxy_shared_secret=<secret>
Redémarrez les noeuds contrôleur et réseau. Si tout se passe bien, la commande neutron agent-list lancée sur le noeud contrôleur doit lister 4 agents sur le noeud réseau (openVSwitch, L3, Metadata, DHCP). Les quatre agents doivent être actifs.

Pour les versions plus récentes d'OpenStack, la commande à taper est : 
openstack network agent list

3.8   Installation des noeuds de calcul

Les noeuds de calcul possèdent des services liés à neutron et nova et peuvent gérer des machines virtuelles. Nous utiliserons le système de virtualisation KVM qui ne nécessite pas d'installation particulière dans une distribution Linux Debian. Pour faire en sorte que plusieurs installations d'OpenStack cohabitent sur les machines de projet, les noeuds de calcul ne seront pas directement installés sur les machines de projets mais dans une machine virtuelle hébergée par les machines de projet. Ainsi les instances de votre infrastructure infonuagique seront des machines virtuelles KVM lancées dans une machine virtuelle KVM en utilisant un procédé de virtualisation imbriquée.

3.8.1   Machine virtuelle KVM

Pour pouvoir gérer des machines virtuelles KVM, installez sur votre machine de projet, le paquetage kvm. Commencez par créer un disque pour votre machine : 
qemu-img create <nom_du_fichier_disque> 10G
Récupérez le premier DVD d'installation de la version visée de la distribution Debian. Vous pouvez alors démarrer votre machine virtuelle (le XX représente votre numéro de machine de TP) : 
kvm -m 4096 -hda <nom_du_fichier_disque> -cdrom <iso_du_DVD_d_installation> \
    -net bridge,br=bridge -net nic,macaddr=00:01:01:01:01:XX,model=e1000
Il vous faudra peut être ajouter créer un fichier /etc/qemu/bridge.conf contenant la ligne 
allow bridge
Une fois la machine virtuelle correctement configurée d'un point de vue réseau, vous pouvez la lancer sans le lecteur optique et sans écran graphique avec l'option -nographic. 
kvm -m 4096 -hda <nom_du_fichier_disque> -nographic -net bridge,br=bridge \
    -net nic,macaddr=00:01:01:01:01:XX,model=e1000 \
    -net nic,macaddr=00:02:02:02:02:XX,model=e1000

3.8.2   Virtualisation imbriquée

Pour permettre une virtualisation imbriquée par KVM il faut ajouter une option au module de gestion de la virtualisation de votre machine de projet : 
echo "options kvm-intel nested=1" >> /etc/modprobe.d/kvm-intel.conf
Vous pouvez ensuite relancer votre machine de projet ou taper les commandes suivantes : 
rmmod kvm_intel
modprobe kvm-intel nested=1
Pour vérifier que votre machine de projet est bien configurée, affichez le contenu du fichier /sys/module/kvm_intel/parameters/nested il doit contenir la lettre y.

Il faut ensuite démarrer la machine virtuelle avec les options nécessaires pour qu'elle dispose d'un processeur avec les instructions de virtualisation. Il suffit de lancer kvm avec l'option -cpu host. Vérifiez, dans la machine virtuelle, que son processeur dispose bien de la fonctionnalité vmx : affichez le fichier noyau /proc/cpuinfo.

3.8.3   Installation du service de calcul

L'installation de nova sur un noeud de calcul se fait simplement sous Debian grâce aux paquetages mysql-client et nova-compute-kvm. Comme interface de programmation, spécifiez uniquement metadata.

La modification pour la section [keystone_authtoken] du fichier de configuration /etc/nova/nova.conf doit être appliquée comme pour l'installation de nova sur le noeud contrôleur.

Pour que nova utilise neutron pour la gestion des réseaux virtuels, il faut appliquer la même modification à son fichier de configuration /etc/nova/nova.conf que décrite en 3.6.6. L'adresse IPv4 utilisée dans la modification doit toujours être celle du noeud contrôleur dans INSECURE.

Dans le fichier de configuration de nova, cherchez les occurences de my_ip et vérifiez que son utilisation est bien adéquate. Si nécessaire remplacez cette variable avec l'adresse IP du noeud contrôleur.

3.8.4   Installation du service réseau

L'installation de neutron sur un noeud de calcul se fait via les paquetages neutron-common, neutron-plugin-ml2, neutron-plugin-openvswitch-agent.

Appliquez les mêmes modifications au fichier système /etc/sysctl.conf que celle expliquées en 3.7.

La modification pour la section [keystone_authtoken] du fichier de configuration /etc/neutron/neutron.conf doit être appliquée comme pour l'installation de neutron sur le noeud contrôleur.

Appliquez les mêmes modifications que celles présentées en 3.7 pour les fichiers de configuration : Dans les deux derniers fichiers de configuration, l'adresse IPv4 à utiliser est celle du noeud de calcul dans le réseau des tunnels.

3.8.5   Test basique

Redémarrez le noeud de calcul. Si tout se passe bien, la commande nova service-list lancée sur le noeud contrôleur doit lister un service nova-compute sur le noeud de calcul. De la même façon, la commande neutron agent-list lancée sur le noeud contrôleur doit lister un agent openVSwitch actif sur le noeud de calcul.

Pour les versions plus récentes d'OpenStack, les commandes sont : 
openstack compute service list
openstack network agent list

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.

This document was translated from LATEX by HEVEA.