Choix de la technologie et l'installation de docker

Choix de la technologie et l’installation de docker

REVUE DE LITTÉRATURE

Introduction :

Nous présentons dans ce chapitre la revue de littérature relative à notre travail. Entre autres, nous visons dans ce projet à tester les performances des ordinateurs mono-cartes ARM en mettant en place un cluster Beowulf. Pour cela, nous abordons dans un premier temps les études qui ont été faites sur les clusters Beowulf et notamment ceux basés sur les appareils ARM afin de situer le cadre de notre contribution. De plus, nous décidons du meilleur outil en terme de passage de messages en testant les deux principales plateformes utilisées, ainsi nous citons les travaux qui ont visé à comparer PVM et MPI. Aussi, nous mentionnons les études ayant été faites sur le déchargement des traitements de sécurité dans le cas des systèmes à ressources limités. De plus, nous présentons des techniques d’équilibrage de la charge mentionnées dans la littérature.
Notre seconde contribution consistant à appliquer la virtualisation sur les appareils ARM, nous abordons ensuite les études qui ont comparé les différentes technologies de virtualisation.

Cluster Beowulf :

Depuis le premier cluster Beowulf réalisé en 1994 par la NASA (Merkey, 2015), le domaine du HPC est devenu de plus en plus accessible au grand public. En effet, l’idée est que tout particulier peut avoir accès à une puissance de calcul plus ou moins importante en alliant plusieurs des équipements qui ne coûtent pas très cher.

Usage des clusters Beowulf :

Plusieurs exemples existent dans la littérature qui décrivent l’utilité des clusters Beowulf, (Datti, Umar et Galadanci, 2015)ont construit un cluster à but éducatif. En effet, les universités n’ont généralement pas les moyens de s’offrir un supercalculateur et le cluster Beowulf de (Datti, Umar et Galadanci, 2015) permet aux étudiants de s’initier aux HPC. Ce dernier délivre des performances satisfaisantes selon les auteurs qui testent dans un premier des multiplications de matrices et dans un second temps exécutent un algorithme qui trouve les nombres premiers dans un intervalle donné. Le cluster est composé de 5 nœuds et les résultats montre une augmentation maximale de 2,472 fois par rapport à l’exécution sur un seul nœud (séquentiel) pour la multiplication de matrice et de 2,459 pour la recherche des nombres premiers. La figure 2.1 montre l’accélération ainsi que l’efficacité dans le temps d’exécution de la multiplication de matrice selon le nombre de nœuds du cluster.

Cluster ARM :

Dans la littérature nous pouvons trouver deux exemples pertinents de l’utilisation des appareils ARM dans la construction d’un cluster : Le premier type est le cluster destiné au traitement de grands fichiers de données, ce qu’on appelle Big Data, le second type est un cluster sur lequel les applications suivantes ont été déployées : serveur web, transcodage vidéo et une base de données en mémoire. Bien que ces deux types de cluster puissent sembler similaires à première vue, il n’en est rien. Leur point en commun est de rassembler la puissance de plusieurs appareils ARM afin d’accomplir des tâches conséquentes. Cependant, la différence fondamentale est que le traitement de larges fichiers de données implique des ressources et des approches différentes que le traitement de trois applications du second cluster. Dans ce qui suit, nous présentons les études qui se sont intéressées à ces deux types de cluster.

Technologies de virtualisation :

La virtualisation a connu un essor important depuis une dizaine d’années, et diverses technologies de virtualisation ont vu le jour. Les deux techniques qui sont les plus populaires sont celles reposent sur les hyperviseurs, cependant la virtualisation au niveau noyau (légère) gagne en popularité(Hess, 2016).
(Morabito et al., 2015) effectuent une comparaison de ces deux techniques. Les auteurs motivent leur travail par le fait que le besoin en virtualisation s’accroit de jour en jour surtout pour les centres de données qui bénéficient de cette technologie pour tirer le maximum de leurs serveurs en terme de ressources ainsi que pour avoir des environnements plus sécurisés en tirant avantage de l’isolation qu’offre la virtualisation.
Les auteurs procèdent à une comparaison du point de vue de l’approche et de l’architecture des deux technologies : La virtualisation basée sur les hyperviseurs simule tout le matériel ce qui apporte un coût supplémentaire lors de l’accès à ce dit matériel, puisque les appels devront passer par l’hyperviseur d’abord. Par contre, pour la virtualisation basée sur l’isolation, ce coût n’apparait pas, car le matériel n’est pas virtualisé. Une autre différence est le fait que l’isolation permet d’avoir des images (des systèmes virtualisés) plus légères puisqu’elles partagent toutes le même noyau. Par contre, pour les hyperviseurs les images sont relativement plus lourdes puisqu’il s’agit de systèmes d’exploitation complets. Cette caractéristique implique aussi un désavantage pour l’isolation qui ne permet pas de virtualiser des systèmes autres que Linux, ce qui n’est pas le cas pour la virtualisation basée sur l’hyperviseur.

ARCHITECTURE

Architecture du cluster :

Le cluster qui a été réalisé dans ce travail est de type Beowulf . L’architecture sera la même pour les différents scénarios des expérimentations que nous avons prévus, à savoir un nœud master qui est responsable du partage des tâches entre les autres nœuds du cluster et qui récoltera les données du monitorage en les stockant dans une base de données locale.
La communication entre les composants du cluster se fait à travers ssh, qui doit être installé sur tous les nœuds et une connexion sans authentification a été configurée afin de permettre à PVM et MPI de communiquer avec les différents nœuds.

Module de monitoring :

Pour implémenter ce module, nous avons choisi de nous baser sur l’outil collectl qui est open source. Cet outil permet de monitorer un grand nombre de ressources que ce soit sur un seul nœud ou à travers tout le cluster. Notre choix ici est motivé principalement par la « légèreté » de ce logiciel relativement au nombre de métriques qu’il arrive à surveiller (highscalability, 2008) et dont l’overhead est inférieur à 0.1%.
Entre autres, collectl offre les avantages suivants :
• La possibilité de s’exécuter en tant que service en arrière-plan ou en temps réel.
• La possibilité d’afficher les sorties sous plusieurs formats.
• Intégration des métriques surveillées par top, ps, vmstat et iotop.
• Possibilité de sauvegarder les métriques surveillées.
• La possibilité d’exporter les données récoltées sous plusieurs formats, ce qui est très intéressant afin de l’intégrer dans notre module de monitoring.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION
CHAPITRE 1 NOTIONS DE BASE
1.1 Introduction
1.2 Informatique de haute performance
1.2.1 Généralités
1.2.2 Gestion de la mémoire
1.2.3 Cluster Beowulf
1.2.4 Mécanismes de passage des messages
1.3 Appareils ARM
1.3.1 Historique
1.3.2 Évolution de l’architecture ARM
1.4 Virtualisation
1.4.1 Définition
1.4.2 Types de virtualisation
1.4.3 Docker
1.5 Conclusion
CHAPITRE 2 REVUE DE LITTÉRATURE
2.1 Introduction
2.2 Cluster beowulf
2.2.1 Usage des clusters beowulf
2.2.2 Cluster ARM
2.3 MPI vs PVM
2.3.1 Différences entre les deux approches
2.3.2 Comparaison des caractéristiques
2.4 Déchargement des traitements de sécurité
2.5 Technologies de virtualisation
2.6 Équilibrage de la charge
2.7 Conclusion
CHAPITRE 3 ARCHITECTURE
3.1 Introduction
3.2 Architecture du cluster
3.3 Module de monitoring
3.3.1 Métriques
3.3.2 Architecture et implémentation
3.3.3 Visualisation temps-réel
3.4 Équilibrage de la charge
3.5 Algorithmes
3.5.1 AES
3.5.2 Correspondance de patrons
CHAPITRE 4 EXPÉRIMENTATIONS ET RÉSULTATS
4.1 Introduction
4.2 Environnement
4.2.1 Matériel utilisé
4.2.2 Environnement logiciel
4.3 Défis techniques
4.3.1 Installation des environnements
4.3.2 Surchauffe des Parallella
4.3.3 OMAP5432 et KVM
4.3.4 Déploiement de Docker
4.3.5 OpenMPI et Parallella
4.4 AES
4.4.1 Distribution naïve
4.4.2 Débit d’exécution
4.4.3 Équilibrage de la charge
4.5 Correspondance de patrons
4.5.1 Distribution naïve
4.5.2 Équilibrage de la charge
4.6 AES parallèle
4.7 Résultats de la virtualisation
4.7.1 Choix de la technologie et l’installation de docker
4.7.2 Tests de performance
4.8 Conclusion
CONCLUSION
BIBLIOGRAPHIE