3.2. Travail réalisé
Le déploiement du Cloud privé sur lequel nous
avons établie de nouveau changements pour but d'amélioration
était basé sur trois noeuds (trois serveurs) le noeud Compute qui
assure le calcul, le noeud contrôleur (Controller) qui exécute le
tableau de bord, le service de réseau et d'autres services, et en
dernier le noeud de stockage en bloc (Cinder). La raison pour laquelle nous
avons choisi ce mode de déploiement en plusieurs noeuds était
d'apprendre au mieux le fonctionnement et les étapes de configuration.
Maintenant que nous avons acquis ces compétences, nous pouvons choisir
un déploiement sur un seul noeud et une installation avec paquets, et
apporter des changements aux fichiers de configuration installé par
défaut, nous économiserons le temps d'installation des services
et les ressources matérielles de notre machine physique. Cette
dernière est un ordinateur portable de type HP PROBOOK avec une espace
de stockage disque 500Go HDD, une RAM de 16Go et un processeur Intel®
Core™ i5-7200U CPU @ 2.50GHz. Sachant que les ressources en mémoire
(RAM) consommées par les trois noeuds de nos déploiements
étaient de 6Go pour le Contrôleur et le Compute et 1Go pour le
stockage en Bloc, nous nous retrouvons seulement 3Go de mémoire
disponible ce qui ne permet pas une installation des deux noeuds du service de
stockage d'objet puisque cette dernière demande au minimum deux noeud de
2Go de RAM chacun. La solution était d'utiliser packstack qui est un
utilitaire qui utilise des modules Puppet pour déployer automatiquement
diverses parties d'OpenStack sur un ou plusieurs serveurs
préinstallés via SSH, de cette façon nous aurons à
notre disposition tous les services précédemment cités
(Identité, Image, Réseau, Calcul, Stockage en Bloc) en plus du
Tableau de bord et des services secondaire (file de message, base de
données...etc.) Cette installation est faite en un seul noeud consomme
moins de ressource matérielles(soit 6Go de RAM), avec ce mode de
déploiement nous allons gagner de temps d'installation et les ressources
matérielles disponibles pour nous investir pleinement dans la
configuration des fichiers de chaque service de manière à
améliorer le fonctionnement de notre Cloud.
3.2.1.
Configuration du service Neutron
Le service de réseau appelé Neutron dans
OpenStack, contient des agents qui vont se charger d'établir la
connectivité au sein de notre plateforme de Cloud. L'ancienne
configuration a été réalisé avec les composants
suivants : Le Plugin ML2, L'agent L2, L'agent Linuxbridge, L'agent L3,
L'agent DHCP, L'agent Metadata. Après plusieurs manipulations et
recherches nous avons trouvé que le problème se posait au niveau
du Plugin ML2 et l'agent L3. En effet, la configuration du Plugin ML2 est
réalisée avec les drivers de mécanisme
« Linuxbridge » et « l2 population »
pour construire l'infrastructure du réseau virtuel layer-2 (Bridging et
Switching) pour les instances et la configuration de l'agent L3 manque de la
notion du bridge externe. Ce que nous avons décidé de faire
était d'utiliser un autre mécanisme de drivers pour le plugin ML2
qui est l'Open vSwitch (OVS), contrairement à LinuxBridge, ce dernier
permet la configuration du bridge externe (br-ex) qui est un pont OVS
utilisé pour connecter des ports physiques (comme eth0), afin que le
trafic IP flottant pour les réseaux de projet puisse être
reçu de l'infrastructure du réseau physique (et Internet) et
acheminé vers les ports réseau du projet en libre-service.
Les étapes de configuration sont
présentées dans l'annexe et la nouvelle configuration est
désormais comme suit :
Figure 26 : schéma de
l'architecture de réseau avec le mécanismes Open
vSwitch[46]
Dans notre projet nous avons créé un
réseau externe qui est le même réseau physique auquel
l'ordinateur portable est connecté (192.168.1.0/24) suivit d'une
création d'un projet dans lequel on dispose d'un ensemble de ressources
(donnée par l'administrateur et manipulées par les utilisateurs
de ce projets) comme les réseaux virtuels, les routeurs, le stockage, la
mémoire Ram...etc. Nous avons donc créé un réseau
privé (10.0.1.0/24) relié au réseau externe via un routeur
virtuel, à ce même réseau virtuel nous avons attaché
des instances qui ont chacune une adresse IP (privée) 10.0.1.17 et
10.0.1.42. Une troisième instance de test é été
ajoutée avec l'adresse 10.0.1.31.
Le schéma suivant représente la topologie du
réseau informatique dans la plateforme de Cloud
précédemment détaillée.
Figure 27 : Topologie simple
du réseau informatique
Nous pouvons représenter graphiquement notre
déploiement du cloud par rapport au réseau externe comme
cela :
Machines virtuelles
Réseau physique
Cloud privé
Réseau virtuel
Routeur virtuel
Figure 28 : Topologie
graphique du réseau informatique
Cette nouvelle configuration du réseau nous permet
d'avoir une meilleure connectivité du réseau, Afin de tester la
connectivité et la disponibilité des instance nous avons
autorisé l'accès ICMP/TCP dans les règles de
sécurité associé à ces instances, ce qui les rends
être accessible via Internet (en utilisant leurs adresses IP flottantes
associés) et via SSH (en utilisant les paires de clés) tout en
accédant au réseau internet. Nous pouvons après
héberger dans une instance un site internet et y accéder depuis
le navigateur Web. La figure suivante montre ces fonctionnalités :
Figure 29 : Test ICMP &
TCP des instances
Sur l'invité de commande cmd de Windows nous avons pu
accéder à la première instance (10.0.1.17) et depuis cette
dernière nous avons lancé la commande ifconfig qui
montre bien l'adresse IP de cette machine (en effet l'instance ne se rends pas
compte qu'elle dispose d'une adresse IP flottante, la sortie de cette commande
le montre bien) pour la deuxième instance (10.0.1.42) nous avons pu lui
lancer un Ping depuis la première.
| 
