1
Département informatique
2ème
année cycle d’ingénieur Logiciel et Système Informatique
Rapport du projet Nimbus cloud
Réalisé par : Encadré par :
El Ghashi Amine M.AmraniChaker
Hmimou Mohammed Charif
SoujaaKhaoula
Année universitaire 2013-2014
2
Sommaire
Introduction ............................................................................................................................................. 3
Projet Nimbus .......................................................................................................................................... 4
Introduction du projet .......................................................................................................................... 4
Les services fournis par Nimbus ......................................................................................................... 4
L’architecture d’un cloud Nimbus....................................................................................................... 5
L’installation et la configuration du cloud Nimbus ................................................................................. 6
Installation des dépendances ............................................................................................................... 6
L’installation des services ................................................................................................................... 6
Création de l’utilisateur Nimbus .................................................................................................... 7
Téléchargement et installation du paquet du service ................................................................... 7
Démarrage des services .................................................................................................................. 8
Création du premier utilisateur ...................................................................................................... 8
Installation du cloud client ............................................................................................................. 9
Tester l’installation du cloud client .............................................................................................. 10
Configuration du réseau et l’installation du DHCP ........................................................................... 10
Définition des plages d’adresses .................................................................................................. 10
L’installation et la configuration des nœuds virtuels ........................................................................ 13
Installer VMM KVM Software ...................................................................................................... 13
Choisir et créer un compte utilisateur privilégié ......................................................................... 14
Installer workspace-control ........................................................................................................... 14
Test des dépendances basiques ................................................................................................... 15
Obtenir l’image de l’échantillon ................................................................................................. 15
Configurer libvirt hyperviseur ................................................................................................... 15
Configurer le pont par défaut ........................................................................................................ 16
Configurer sudo et le script ebtables ............................................................................................. 16
Obtenir l’échantillon du réseau workspace-control ....................................................................... 17
Essai de VM .................................................................................................................................. 17
Configuration du SSH ..................................................................................................................... 19
Conclusion ............................................................................................................................................. 21
3
Introduction
Le Cloud Computing, ou « informatique dans les nuages », est un « nouveau » modèle
informatique qui consiste à proposer les services informatiques sous forme de services à la
demande, accessibles de n'importe où, n'importe quand et par n'importe qui. Cette approche
n’est pas tout à fait nouvelle (modèle ASP, IBM on demand). La réelle nouveauté réside dans
son approche systématique.
La traduction littérale « informatique dans les nuages » propose une informatique
dématérialisée, pouvant être délivrée à la demande. Cette philosophie n’est pas nouvelle car
elle est sans rappeler les concepts d’informatiques utilitaires proposés par John McCarthy en
1961.
Le Cloud Computing met en œuvre l'idée d'informatique utilitaire du type service public. Il
peut aussi être comparé au cluster de calcul dans lequel un groupe d'ordinateurs se relient
pour former un ordinateur virtuel unique permettant le calcul de haute performance (HPC),
mais aussi à l'informatique en grille (GridComputing) où des ordinateurs reliés et répartis
géographiquement permettent la résolution d’un problème commun.
Le Cloud Computing couplé, aux technologies de virtualisation, permet la mise à disposition
d'infrastructures et de plate-forme à la demande. Mais le Cloud Computing ne concerne pas
seulement l’infrastructure (IaaS), il bouleverse la plate-forme d’exécution (PaaS) et les
applications (SaaS).
4
Projet Nimbus
Introduction du projet
Issu du monde de la recherche, Nimbus permet de déployer un cloud de type
Iaas. Diffusée sous licence Apache 2.0, cette plate-forme supporte les
hyperviseurs Xen et KVM, et peut s’interfacer avec le cloud d’Amazon, EC2.
Elle est associée à autre projet, baptisé Cumulus, qui permet de déployer des
services de stockage en cloud, compatible avec le service Amazon S3. Nimbus a
été déployé, entre autres, par un réseau d’universités américaines qui proposent
des clouds en libre accès pour des projets de recherche.Nimbus permet aussi de
combiner Nimbus, OpenStack, Amazon et d'autres nuages.
Les services fournis par Nimbus
Le projet Nimbus offre des services de type infrastructures (IaaS : Infrastructure
as a Service) c’est-à-dire il fournit des capacités de
calcul et de stockage ainsi qu'une connectivité
réseau. Les serveurs, systèmes de stockage,
commutateurs, routeurs et autres équipements, sont
mis à disposition pour gérer une charge de travail demandée par les applications.
L'infrastructure comme un service ou IaaS, permet de disposer d'une
infrastructure à la demande, pouvant héberger et exécuter des applications, des
services ou encore stocker des données.
5
L’architecture d’un cloud Nimbus
Un cloud Nimbus peut être schématisé de la manière suivante :
-Un client de l'espace de travail spécial appelé le cloud-client appelle des opérations
sur les services IaaS et serveur Cumulus. Un certain nombre de valeurs par défaut sont
supposées qui rend ce travail hors de la boîte (les valeurs par défaut seront discutées
plus tard).
- Les fichiers sont transférés du-client à un système de stockage spécifique au client
sur le nœud référentiel (manuel ou d'autres types de transferts basés protocole S3 sont
également possibles pour les utilisateurs avancés).
- Le service invoque des commandes sur la VMM pour déclencher le transfert de
fichiers vers / à partir du nœud référentiel, les événements VM du cycle de vie, et de la
destruction / nettoyer.
- Si l’état du workspace(l'espace de travail change), le cloud client reflétera ce à l'écran
(et les fichiers journaux) et en fonction du changement pourrait également prendre des
mesures en réponse.
6
L’installation et la configuration du cloud Nimbus
Pour mettre en œuvre le cloud Nimbus et de bénéficier de ses services, il faut passer par les
six étapes suivantes :
1- L’installation des dépendances nécessaires pour les services.
2- L’installation des services.
3- La configuration du réseau et la mise en œuvre du service DHCP.
4- L’installation et la configuration des nœuds virtuels.
5- La configuration du SSH.
6- Les tests avant utilisation.
Installation des dépendances
Dans cette partie on va installer tous les dépendances c’est-à-dire tous les paquets
nécessaires pour la configuration du nœud de service. La liste suivante résume ce que doit
être installé dans le nœud de service :
Sun Java 1.6 Update ou bien des versions plus récentes.
Python 2.5 ou bien des versions plus récentes (sauf les versions 3.x).
Sqlite3.
GCC (nécessaire pour l’installation de Cumulus).
Apache Ant 1.6.2 ou bien des versions plus récentes.
L’installation des services
Dans cette étape nous allons installer les services centraux de nimbus et Cumulus, et nous
allons utiliser un client cloud pour accéder à notre cloud comme étant un utilisateur distant.
Mais cela ne marchera uniquement qu’en « mode faux » ce qui signifie que le service fait
seulement semblant de démarrer les machines virtuelles. Dans des étapes ultérieurs, on va activer
les VMMs, les connecter avec le service central et nous aurons un cloud qui fonctionne.
7
Création de l’utilisateur Nimbus
La première étape consiste à créer un compte Unix sous lequel on va installer et exécuter les
services Nimbus. Il n'est pas recommandé d'utiliser le compte root, parce que plus tard on va
configurer des clés sans mot de passe SSH entre ce compte et l’hyperviseur.
Téléchargement et installation du paquet du service
On a choisi d’installer la version ‘nimbus-iaas-2.10.1’ étant la dernière version stable de nimbus
cloud, le paquet est téléchargeable à l’aide de la commande suivante :
curl -O http://www.nimbusproject.org/downloads/nimbus-iaas-2.10.1-src.tar.gz
Après on doit décompresser le paquet avec la commande tar :
tar xfz nimbus-iaas-2.10.1-src.tar.gz
Ensuite, il faut accéder au dossier décompressé et créer le dossier de l’installation dont le
propriétaire sera l’utilisateur nimbus. Finalement on lance l’installation du service vers le dossier
de l’installation.
./install $Dossier_de_l’installation
L'installateur effectue plusieurs étapes:
- Installe Cumulus et ces dépendances à un Python virtualenv.
- Construit et installe les services centraux IaaS.
- Crée des bases de données initiales.
- Exécute un programme de configuration interactif pour recueillir des informations de base.
- Génère l’autorité de certification interne des certificats d’hôte.
8
Maintenant, le système nimbus est mis en place avec la sécurité, les services Web, et les
configurations sensibles par défauts. Mais le service est exécuté en mode "fake", où aucunes
des machines virtuelles sont réellement commencé. Il s'agit d'une excellente occasion de tester
le service et Cumulus avant de passer à VMM et la configuration du réseau.
Démarrage des services
Maintenant que les services sont installés, on va essayer de les démarrer pour la 1ère fois.
Création du premier utilisateur
Maintenant que Nimbus est installé et fonctionne, nous pouvons passer à l'essai avec un vrai
client. Mais d'abord, nous devons créer un compte utilisateur pour tester avec. Nous le ferons avec
l'outil nimbus-new-user. Il dispose de nombreuses options mais pour le moment nous allons
utiliser les paramètres par défaut, en spécifiant une adresse électronique à associer au compte ainsi
que dans un répertoire temporaire.
9
Installation du cloud client
Nous allons tester nos services en utilisant the Nimbus could client. Vous pouvez le faire à partir
du même système que vous installez, mais vous pouvez utiliser un système distinct de sorte que
vous pouvez vérifier que le réseau fonctionne correctement, ce qui est notre cas. Il est
recommandé d’installer des versions plus récentes, dans notre cas nous avons installé la dernière
version à l’aide de la commande :
curl -O http://www.nimbusproject.org/downloads/nimbus-cloud-client-022.tar.gz
Et comme d’habitude, on va le décompresser :
tar xfz nimbus-cloud-client-022.tar.gz
Maintenant, il faut installer les fichiers générés par ‘nimbus-new-user’, le fichier
‘cloud.properties’ doit être placé dans le répertoire ‘/conf’ du dossier décompressé. Les deux
fichiers ‘usercert.pem’ et ’userkey.pem’ doivent être installer dans ~/.nimbus/ dans le répertoire
personnel.
cp /tmp/newuser/cloud.properties nimbus-cloud-client-022/conf/
mkdir ~/.nimbus/
cp /tmp/newuser/*.pem ~/.nimbus/
Parce que nous testons avec un client dans un diffèrent système, on va utiliser scppour
copier ces fichiers.
Nous avons également besoin de prendre un peu plus de fichiers à partir de l'installation du
service Nimbus et les mettre dans le client. Ce sont les CA certificats internes ils permettent
au client de faire confiance au serveur.
cp $Dossier_de_l’installation/var/ca/trusted-certs/* nimbus-cloud-client-022/lib/certs/
10
Tester l’installation du cloud client
Nous allons d'abord essayer d'interroger le service. Cette commande affiche les machines
virtuelles en cours d'exécution que nous possédons. Bien sûr, on n’on a pas à ce point, mais
cela peut aider à diagnostiquer n'importe quelle configuration ou des problèmes de sécurité.
Nous avons interrogé avec succès le service de Nimbus démarré! L'étape suivante consiste à
interroger Cumulus et la liste des images disponibles, nous devons exécuter. Encore une fois,
bien sûr, nous allons avoir aucun.
La commande a bien marché, donc les services de Nimbus sont opérationnels.
Configuration du réseau et l’installation du DHCP
Dans cette partie, nous allons installer un démon DHCPd central, et on va configurer les
adresses réseau qu’on veut donner à nos machines quand elles démarrent.
Quand une VM est démarrée utilisant Nimbus, une adresse IP est donnée via DHCP. Nous
devons configurer un pool de réseaux et d’adresses disponibles dans le service. Nous devons
fournir au moins autant d'adresses que les machines virtuelles que nous voulons démarrer
simultanément.
En plus de la configuration des adresses disponibles dans le service Nimbus, nous devons
également mettre en place un serveur DHCP pour distribuer ces adresses.
Définition des plages d’adresses
Chaque fichier du répertoire $NIMBUS_HOME/services/etc/nimbus/workspace-
service/network-pools/ du nœud Service représente un réseau qui peut être donné aux
machines virtuelles.
11
Chaque réseau peut être lié aux différents réseaux physiques (ou les mêmes) par un pont, et
une seule VM peut se connecter à plusieurs réseaux. Quand une VM est démarrée, un ou
plusieurs réseaux sont demandés par le client.
Par défaut, Les installations Nimbus sont configurées avec deux réseaux, Publique et
privé. Commençons par le fichier du public puisqu'il contient beaucoup de documentation
utile. Pour chaque réseau, il faut configurer un serveur DNS ainsi que la liste des
emplacements de réseau disponibles.
Il est important de savoir que les seuls champs obligatoires sont le hostname et IP. La
passerelle, broadcast et subnet peuvent être spécifiées en tant que 'none'. On peut également
spécifier facultativement une adresse MAC comme dernier champ. Si on ne spécifie pas un
MAC, le service Nimbus va la générer pour nous.
Serveur DHCP
Tant que les adresses des VMs sont configurées et choisies ils sont physiquement interrogés via
un service DHCPd externe. Il y a deux façons d'arranger la configuration DHCP :
- Centralisé : un service DHCP nouveau ou existant qu’on configure avec Nimbus-
Cela est généralement plus simple à mettre en place et c’est ce que nous utiliserons par
la suite.
- Local : un serveur DHCP est installé sur chaque noeud du VMM et automatiquement
configuré avec les adresses appropriées juste avant une VM démarre. . C'est plus
compliqué à mettre en place au départ, mais peut-être préférable dans certains
scénarios.
Pour continuer, Nous devons avoir un serveur DHCP écoutant sur le réseau(x) qui sera
disponible pour les machines virtuelles. Nous pouvons utiliser un serveur de site existant ou
installer notre propre.
Quand une VM est créée en utilisant Nimbus, le service sélectionne une entrée du network
pool et envoi l’IP et le hostname au client. C’est le rôle du serveur DHCP d’assurer que la
VM donne des adresses IP correctes, sinon la VM ne pourra pas accéder au réseau. On doit
ajouter les corrects MAC aux adresses IP pour la configuration du serveur.
12
Après avoir configuré les entrées du network pool, on redémarre le service par la commande
suivante :
Dans $Dossier_de_l’installation/services/var/nimbus/ nous devons avoir plusieurs fichiers,
parmi ces fichiers on doit trouver ces trois :
o dhcpd.entries : Une liste générée des entrées d’host qui peut être inclue dans notre
DHCP configuration.
o ip_macs.txt : Une liste d’adresses IP et d’adresses MAC (séparés par des espaces).
o control.netsample.txt : Un échantillon d’une entrée du network pool, utile pour tester
les nouveaux nœuds VMM. On va utiliser ce fichier par la suite.
Ces fichiers changeront seulement si on modifie la configuration de notre network pool et
on redémarre le service.
La configuration à faire est d’inclure le fichier dhcpd.entries dans notre dhcpd.conf, on peut le
faire avec la directive include de la manière suivante: include "/path/to/dhcpd.entries";
Serveur metadata
Les VMs peuvent optionnellement demander un serveur metadata pour les données fournis
à l’utilisateur et aussi pour les informations à propos du déploiement. Par défaut, ce service
est désactivé, mais devra être activé si on veut utiliser le Nimbus Context Broker.
Sa configuration est dans $Dossier_de_l’installation/services/etc/nimbus/workspace-
service/metadata.conf. On doit choisir IP et le port pour le service pour qu’il en écoute. L’adresse
doit être accessible par les VMs. On doit modifier les lignes suivantes :
13
Installation des machines virtuelles
Dans cette partie, on installe the Nimbus VMM software workspace-control et ces
dépendances (y compris Xen ou KVM ainsi que libvirt, si ceux-ci ne sont pas déjà présents).
workspace-control contient des scripts qui nous aider à tester si l’installation de notre
Xen/KVM/libvirt travailleront avec les modèles d'accès programmatiques que Nimbus utilise.
L’installation et la configuration des nœuds virtuels
Les dépendances
Avant d’automatiser un nœud de VMM avec le logiciel Nimbus, il doit être un nœud VMM. Donc
la première chose que nous devons faire est de s'assurer que tous les virtualisation et dépendances
du réseau sont présents.
The workspace service gère actuellement Xen ou KVM VMs. Il s'interface avec ces deux
systèmes en utilisant une bibliothèque appelée libvirt.
Par la suite de ce rapport, on expliquera comment installer the Nimbus workspace control
software sur Xen 3.x et KVM.
Lors de l’installation de KVM et Xen il y a beaucoup d'étapes qui sont communs entre les deux.
Cependant, il y a aussi quelques légères différences à chaque étape. Nous avons essayé d’installer
les deux, mais on a rencontré des problèmes lors de l’installation de XEN.
Par la suite, on expliquera comment on a installée KVM.
Installer VMM KVM Software
Le projet Nimbus a une image échantillon de KVM qui peut être utilisé pour tester que KVM,
libvirt et Nimbus sont correctement installés. On l’a téléchargé depuis le lien
www.nimbusproject.org/downloads/ubuntu10.10.gz.
Il s'agit d'une VM ubuntu10.10 de base. Il tourne un serveur SSH lors de son démarrage.
14
Puis on a Installé ebtablesen utilisant les outils de gestion de paquets de votre distribution
Linux. Ainsi que libvirt.
Choisir et créer un compte utilisateur privilégié
Il y a deux comptes du système nécessaires dans Les VMM.
Compte privilégié : Choisissez un compte pour le favorisé (en utilisant sudo). Dans
ce guide, nous allons nous référer à un compte de ce type nommé nimbus avec un
terminal invite comme ‘’ nimbus $ ’’.
Compte super-utilisateur : Le compte root est nécessaire pour installer les
dépendances sur les nœuds de VMM (Xen / KVM, ebtables, etc) et aussi d’installer
l’agent Nimbus qui vit sur les nœuds de VMM (workspace control).
Dans ce guide, nous allons nous référer à un compte de ce type appelé root avec le
terminal invite comme "root #", root n'est pas nécessaire sur le nœud, juste ici sur le
VMM.
Maintenant que nous avons créé notre non-root utilisateur nimbus, nous devons lui permettre
de contrôler les machines virtuelles en utilisant libvirt.
D'abord, on a essayé une commande libvirt en tant que root (il ne changera rien si elle
marche ou pas).
Mettre le libvirtdomain socket disponibles pour la lecture et l'écriture par le groupe libvirtd
en permettant les configurations suivantes dans /etc /libvirt /libvirtd.conf.
Pour que les échanges effectués soient prises en considération, il faut redémarrer libvirtd.
Installer workspace-control
15
Nous pouvons maintenant télécharger le paquet de contrôle de VMM. Nous avons téléchargé
le fichier tar "Control Agents » à partir de la page de téléchargement, et nous l’avons
décompressé. Cet archive contient à la fois workspace-control et le pilote de the workspace.
Pour cette configuration, nous utilisons workspace-control. On doit le copier dans le
répertoire de destination /opt /nimbus comme ceci:
Test des dépendances basiques
Avant de passer au test de lancement du VM, nous devons d'abord confirmer les hypothèses
de base sur l'environnement. Le paquet workspace-control contient un script qui va examiner
le système.
On va vérifier par la commande suivante:
Obtenir l’image de l’échantillon
L’image de l'échantillon a été préparée pour le test. Il s'agit d'une machine virtuelle de base
que les développeurs de Nimbus sont familiers avec :
Il s’agit d’une image d’installation ubuntu 10.10. SSH fonctionne lors de son démarrage.
Mais, les mots de passe root sont désactivés.
Configurer libvirt hyperviseur
Le workspace control doit être configuré pour utiliser le libvirt hyperviseur correct. Cela se
fait dans / opt / Nimbus / etc / workspace-contrôle / libvirt.conf. La valeur par défaut du
hyperviseur est Xen. Parce que nous utilisons KVM, nous avons modifié la propriété VMM
dans ce fichier.
16
Configurer le pont par défaut
Nous avons précédemment mis en place KVM à utiliser les réseaux par pont, maintenant il
est temps de vérifier ce que le nom réel du pont sera, que l’invité de la carte réseau de VM
utilise pour obtenir du trafic sur le LAN.
Utilisation de l'outil de brctl :
Configurer sudo et le script ebtables
Avant que nous puissions faire un test en direct, il faut configurer workspace-control à utiliser
sudo privilégié correctement.
En utilisant la commande visudo, on doit ajouter les politiques sudo nécessaires. Ces
politiques reflètent le besoin d'utiliser l'utilisateur qui fait tourner workspace-control
("nimbus") et les chemins complets, corrects aux outils libexec. Voir /opt /Nimbus /etc
/workspace-contrôle /sudo.conf pour tous les détails et les règles de l'échantillon.
Assurez-vous que les règles du sudo travaillent sans un mot de passe comme l'utilisateur
nimbus.
Voir "ERROR" est une bonne chose ici.
17
L'objectif est d'effectuer cette commande à partir du compte nimbus sans avoir besoin de mot
de passe.
Obtenir l’échantillon du réseau workspace-control
Dans une section précédente de ce guide, vous avez configuré Dhcpd et les adresses réseau
pour donner aux machines virtuelles invitées.
Le conteneur de services IaaS central a écrit sur le fichier dhcpd.entries qui sera utilisé pour la
configuration du serveur DHCPd. Dans le même répertoire un fichier d'exemple pour
workspace-control a été écrit, nous allons l'utiliser pour tester un lancement d’une VM via
libvirt avec notre serveur DHCPd démarré. Le fichier que vous devez obtenir est appelé
control.netsample.txt
On a transféré ce fichier à partir du nœud central à n'importe où sur le nœud de VMM :
$Dossier_de_l’installation/services/var/nimbus/control.netsample.txt
Nous allons l'utiliser dans la prochaine étape. L'emplacement de l'exemple de la VMM sera
/tmp / control.netsample.txt.
Essai de VM
Une fois que nous avons obtenu le fichier control.netsample.txt, le noyau configuré et le pont
par défaut configuré, on est prêt à essayer de démarrer la machine virtuelle de test en utilisant
un fichier de configuration libvirt.
Ce n'est pas n'importe quel fichier de configuration libvirt, mais représentant exactement la
configuration que l'outil workspace-control va utiliser pour lancer des machines virtuelles sur
votre système automatiquement.
Un script appelé libvirt-xml.sh vies en /opt /Nimbus /sbin qui va générer XML que nous
pouvons utiliser pour lancer des machines virtuelles à l'aide de l'outil ligne de commande
libvirt appelés virsh.
18
Une fois qu’on a le XML :
Maintenant, en tant qu'utilisateur nimbus on exécute la commande virsh pour démarrer la
VM :
Maintenant, la VM démarre. Si elle obtient l'adresse réseau correcte de DHCP, on devra être
en mesure de faire un ping et même de nous connecter via SSH.
19
Configuration du SSH
Dans cette partie nous allons configurer le SHH dans notre cluster pour que les composants
Nimbus peuvent communiquer proprement et en toute sécurité.
Le service de Nimbus et les nœuds VMM communiquent via SSH, vous devez configurer les
touches sans mot de passe SSH. À ce stade, nous avons deux nœuds établis, chacun avec un
compte privilégié. On doit autoriser le compte du nœud de service de SSH à la VMM, et vice
versa.
Il ya plusieurs façons de mettre cela en place, mais le plus simple est de générer des clés sur
chaque nœud et ajouter les clés publiques les unes aux autres ~/.ssh/authorized_keys files.
Voici le résultat de la commande ssh-keygen :
On copie la clé publique générée au nœud, cette commande ne peut pas être exécutéedonc on
aura besoin de télécharger le paquet virt-viewerde VMM puis on se connecte directement.
Virt-viewerest un outil minimal pour l'affichage de la console graphique d'une machine
virtuelle. La console est accessible via le protocole VNC. Le client peut être appelé à partir de
son nom, ID, ou UUID. Si le client n'est pas déjà en cours d'exécution, l’utilisateur peut
attendre jusqu'à ce qu’il sera lancé, avant d'essayer de se connecter à la console l’utilisateur
20
peut se connecter à des hôtes distants de rechercher les informations de la console, puis
connectez également la console à distance en utilisant le même réseau transport.
Voici le résultat final, on aura notre machine virtuelle et on a une idée sur ses ressources :
21
Conclusion
Pour conclure, ce projet nous a permis de renforcer les connaissances que nous
avons acquis dans ce module 'la programmation parallèle’, et nous a donné une
occasion bénéfique sur les différents plans techniques et technologiques.
Le fait de partir d'une feuille blanche a été un facteur positif qui nous a permis
de s'affranchir à des contraintes liées à la structure des solutions existantes et à
leur adaptation.
Top Related