Télécharger le fichier original (Mémoire de fin d’études)
Modèle centralisé
Ce modèle s’appuie sur une seule instance de chaque fonction de traitement et d’exposition. Il peut s’appuyer, par contre, sur différentes instances de fonctions d’observation. Cette catégorie d’architectures est représentée sur la première colonne du tableau de la figure 2.1.
Ce modèle architectural est le plus intuitif et le plus simple à réaliser. Cependant, étant donné que la multi-instanciation des fonctions d’observation et de traitement n’est pas possible, une solution ayant ce modèle architectural ne peut pas être déployée à proximité de tous les utilisateurs et de toutes les ressources supervisées en même temps dans un contexte d’infrastructure Edge massivement distribuée. Elle ne peut donc pas satisfaire la proximité vis-à-vis des utilisateurs. En plus, ce modèle est limité en termes de passage à l’échelle. En effet, vu que les éléments de traitement et d’exposition ne peuvent pas être multi-instanciés, le passage à l’échelle horizontal n’est pas supporté. Seul le passage à l’échelle vertical (augmentation des capacités des ressources hôtes) peut être mis en place. Enfin, la solution s’appuyant sur ce modèle n’est pas résiliente aux pannes/volatilité des serveurs car l’instance qui ne peut pas être multi-instanciée représente un point de défaillance critique.
Modèle hiérarchique
Le modèle hiérarchique n’impose pas de contrainte sur le nombre d’instances des fonctions. Cependant, il exige que les instances forment une structure arborescente. Autrement dit, chaque instance envoie un flux à une autre dans un niveau hiérarchique supérieur. L’instance de plus haut niveau dispose de la vue la plus globale de l’infrastructure et, par conséquent, elle est la plus adaptée pour assurer la fonction d’exposition. Cette catégorie d’architecture correspond à la deuxième colonne du tableau de la figure 2.1.
En permettant la multi-instanciation des fonctions de supervision, ce modèle permet de les répartir à proximité des ressources supervisées et des utilisateurs. Ainsi, il satisfait la proximité vis-à-vis des utilisateurs. En plus, la possibilité de multi-instancier des éléments permet d’assurer le passage à l’échelle horizontal. Cependant, ce modèle n’est pas résilient aux pannes/volatilité des serveurs. En effet, la maintenance des architectures hiérarchiques est complexe et coûteuse. Pour remplacer une ressource hôte en panne, il faut reconstruire l’organisation de l’arbre des instances. Cela nécessite un processus électoral pouvant introduire une charge et un délai non négligeables [Zhang et al. 2009]. Plus le niveau du nœud en panne ou disparu est élevé, plus le nombre des nœuds concernés par le processus électoral est grand et plus l’impact de la maintenance est important.
Modèle pair-à-pair
Ce dernier modèle d’architecture permet de multi-instancier les fonctions de supervision sans imposer une structure spécifique entre elles. N’importe quelle instance peut être connectée à une autre selon le modèle de communication pair-à-pair. Cette catégorie d’architectures est représentée sur la troisième colonne de la figure 2.1.
En permettant de multi-instancier les fonctions de supervision, ce modèle architectural retient les propriétés satisfaites par le modèle hiérarchique qui sont la proximité vis-à-vis des utilisateurs et le passage à l’échelle. De plus, l’absence de hiérarchie entre les fonctions dans cette architecture limite l’impacte de la panne [Mastroianni et al. 2008]. En effet, le système de supervision n’est pas coupé en deux sous-systèmes isolés lorsque un élément n’est pas fonctionnel. Ainsi, ce modèle architectural satisfait la résilience à la volatilité/pannes des serveurs.
Évaluation des solutions existantes
En combinant les différents modèles architecturaux et décompositions fonctionnelles, nous définissons les neuf catégories d’architectures illustrées par la figure 2.1. L’évaluation de chacune par rapport aux propriétés requises dépend de son modèle architectural et de sa décomposition fonctionnelle comme cela a été détaillé dans la section précédente. Pour évaluer qualitativement les principales solutions de la littérature, nous les classons selon ces neuf catégories.
Évaluation des solutions existantes
Aucune décomposition fonctionnelle
Les solutions n’ayant aucune décomposition fonctionnelle n’utilisent pas leurs propres sondes pour superviser les ressources distantes mais elles utilisent des sondes offertes par les ressources.
Modèle centralisé
Les solutions qui ont été conçues selon le modèle centralisé et qui n’ont aucune décompo-sition fonctionnelle s’appuient sur un seul élément qui assure les fonctions d’observation, traitement et d’exposition. Nous appelons cette architecture C0, sur la figure 2.1.
Near Field Monitoring [Suneja et al. 2014] (NFM) est une solution destinée à la supervision des machines virtuelles. Elle s’appuie sur des techniques d’introspection. Comme illustré par la figure elle fait appel à l’API de l’hyperviseur pour accéder à des captures (ou frames) de la mémoire disque et la mémoire vive de la machine virtuelle supervisée. Les informations disponibles au niveau de la mémoire disque lui permettent de déterminer le système d’exploitation de la machine virtuelle ainsi que sa configuration. En utilisant ces informations, NFM détermine les états des machines virtuelles supervisées. Il enregistre ces états dans une base de données centrale et les expose via son API aux applications qui sont éligibles à y accéder. À noter que les techniques d’introspection nécessitent d’analyser le noyau du système d’exploitation ce qui introduit un temps considérable à la supervision. En plus, l’application de cette technique peut être inefficace voire impossible pour les systèmes d’exploitation qui sont propriétaires ou n’offrent pas une documentation suffisamment détaillée. Enfin, cette technique expose les données disponibles au niveau des machines virtuelles ce qui risque d’introduire des failles de sécurité.
La supervision sans déployer une sonde sur la ressource supervisée présente plusieurs avantages. Par exemple, cela permet d’éviter d’introduire des vulnérabilités sur cette ressource. Cependant, il faut que la ressource permette l’observation de son état d’une manière compatible avec la solution de supervision. Afin de standardiser ce mode de supervision et lui offrir ainsi plus d’interopérabilité, des protocoles ont été proposés par la communauté réseau :
• Simple Network Management Protocol (SNMP) [Stallings 1998] a été développé en 1988 et est ainsi largement supporté par les équipements réseau. Les ressources supervisées qui le supportent mettent à disposition une sonde qui expose leurs états et leurs configurations via une interface appelée « base d’information pour la gestion du réseau » (MIB). La solution de supervision, quant à elle, doit intégrer un composant appelé « station de gestion réseau » (NMS) qui sollicite en mode pull la ressource supervisée pour recevoir les mesures.
• sFlow 1 est un autre protocole qui offre des fonctionnalités de supervision. Contrai-rement aux sondes de SNMP, celles de sFlow poussent (push) les mesures à la solution de supervision. Initialement, ce protocole ne permet de superviser que le réseau en capturant le trafic qui y circule. Le projet Host Flow 2 permet aux ressources supervisées (par exemple, des applications, des machines virtuelles ou des machines physiques) d’intégrer des sondes qui exposent leurs états avec le protocole sFlow.
• En plus de la configuration, OpenFlow [ONF 2015] permet également la supervi-sion des commutateurs des réseaux programmables (SDN). En effet, à l’aide de ce protocole, le contrôleur du réseau peut demander à un commutateur des informations sur un flux bien déterminé en envoyant un message de type « FlowStatisticsRequest ». Le commutateur répond à ce message par la durée de support et le nombre d’octets du flux en question en envoyant un message de type « FlowStatisticsReply ».
Pour chacun de ces protocoles nous donnons un exemple d’une solution de supervision centralisée qui s’appuie dessus :
• Cacti [Kundu et al. 2009] est une solution de supervision qui s’appuie sur SNMP. Cette solution est utilisée typiquement pour superviser le réseau. Elle permet notamment de visualiser des courbes représentant les mesures observées (par exemple, bande passante) via une interface web.
• ntop [Deri et al. 2000] est une solution de supervision qui s’appuie sur sFlow (elle représente un « collecteur » dans la terminologie de sFlow). Elle a une architecture centralisée qui assure les trois fonctions que nous avons spécifiées : « Packet capture » s’appuie sur la bibliothèque libpcap pour capturer et observer les paquets. « Packet analyser » traite les paquets et les classe dans une base de données SQL. Enfin, une interface permet à l’utilisateur d’accéder aux données collectées via un terminal ou un site web.
Table des matières
I Introduction
II Contexte & État de l’art
1 Contexte
1.1 Informatique en nuage ou Cloud Computing
1.1.1 Modèles de services du Cloud
1.1.2 Modèles de déploiement du Cloud
1.1.3 Importance de l’économie d’échelle dans le succès du Cloud
1.2 Défi des applications de nouvelle génération
1.2.1 Applications de nouvelle génération et leurs exigences
1.2.2 Limites du Cloud Computing
1.3 L’Edge Computing : une réponse aux exigences des applications de nouvelle génération
1.3.1 Présentation du Edge Computing
1.3.2 Infrastructure Edge
1.3.3 Caractéristiques de l’infrastructure Edge
1.4 Gestionnaire de ressources pour l’infrastructure Edge
1.5 Conclusion
2 État de l’art
2.1 Spécifications de la solution de supervision
2.1.1 Propriétés fonctionnelles
2.1.2 Propriétés non fonctionnelles
2.2 Une approche qualitative d’évaluation
2.2.1 Décomposition fonctionnelle
2.2.2 Modèles architecturaux
2.3 Évaluation des solutions existantes
2.3.1 Aucune décomposition fonctionnelle
2.3.2 Décomposition fonctionnelle élémentaire
2.3.3 Décomposition fonctionnelle avancée
2.3.4 Modèles hybrides
2.4 Synthèse
2.5 Conclusion
III Contribution
3 Canevas logiciel pour la supervision d’une infrastructure Edge
3.1 Architecture du service de supervision
3.2 Langage de description des besoins des utilisateurs
3.2.1 Lexique
3.2.2 Grammaire
3.3 Langage de description de l’infrastructure
3.3.1 Lexique
3.3.2 Grammaire
3.3.3 Comparaison avec des langages existants
3.4 Calculateur de placement
3.5 Cas d’utilisation
3.5.1 Description des besoins de supervision de l’opérateur
3.5.2 Description de l’infrastructure
3.5.3 Placement mutualisé des fonctions de supervision
3.6 Conclusion
4 Formalisation du problème de placement mutualisé
4.1 Présentation du problème
4.1.1 Travaux existants
4.1.2 Modélisation par un problème de satisfaction de contraintes
4.2 Modèle du problème de placement mutualisé
4.2.1 Notions et notation
4.2.2 Entrées du problème
4.2.3 Définition des variables
4.2.4 Définition des domaines
4.2.5 Contraintes du problème
4.2.6 Fonction objectif
4.3 Évaluation
4.3.1 Scénarios du test
4.3.2 Résultats du test
4.4 Conclusion
IV Conclusion générale & perspectives
5 Conclusion générale
6 Perspectives
6.1 Évaluation des langages de description définis
6.2 Calcul de mutualisation
6.2.1 Réduction du temps de calcul
6.2.2 Résilience à la dynamicité de l’infrastructure Edge
6.2.3 Extension du modèle
6.3 Mise en oeuvre de l’architecture de déploiement
6.4 Application de la mutualisation dans le contexte de l’IdO
6.5 Coopération entre différents gestionnaires de services
V Références
Bibliographie
Table des figures
Liste des tableaux
