Previous Contents Next

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
Previous Contents Next