Architecture des systèmes

Transcription

1 LIG, 2/12/2010 Architecture des systèmes Avancées et défis Sacha Krakowiak Université de Grenoble 1

2 Architecture des systèmes! Architecture art de construire les édifices art de créer et dʼorganiser des formes en vue dʼune fonction, en présence de contraintes 2 2

3 Architecture des systèmes! Architecture art de construire les édifices art de créer et dʼorganiser des formes en vue dʼune fonction, en présence de contraintes Christopher Alexander, Notes on the Synthesis of Form, Harvard University Press,

4 Architecture des systèmes! Architecture art de construire les édifices art de créer et dʼorganiser des formes en vue dʼune fonction, en présence de contraintes! Architecture de systèmes informatiques un (ou des) modèle(s) décrivant la structure et le comportement dʼun système en termes dʼéléments et de relations entre ces éléments une (ou des) méthode(s) pour construire un système répondant à des spécifications Christopher Alexander, Notes on the Synthesis of Form, Harvard University Press,

5 Quelques outils de lʼarchitecte! Des (méta) principes Règles génériques pouvant se décliner sous diverses formes concrètes Abstraction (ex. : hiérarchie de machines abstraites) Séparation des préoccupations (ex. : séparation politique/mécanismes, interface/réalisation) Économie (ex. : optimiser le cas fréquent, contrôle «de bout en bout») 3 3

6 Quelques outils de lʼarchitecte! Des (méta) principes Règles génériques pouvant se décliner sous diverses formes concrètes Abstraction (ex. : hiérarchie de machines abstraites) Séparation des préoccupations (ex. : séparation politique/mécanismes, interface/réalisation) Économie (ex. : optimiser le cas fréquent, contrôle «de bout en bout»)! Des paradigmes Paradigme : démarche, mode dʼorganisation, structure applicable à une large classe de situations, et ayant valeur dʼexemple, dans les deux sens du terme illustration dʼune démarche modèle à suivre 3 3

7 Quelques paradigmes de lʼarchitecture des systèmes! Virtualisation concrétiser un objet idéal multiplier un objet réel 4 4

8 Quelques paradigmes de lʼarchitecture des systèmes! Virtualisation concrétiser un objet idéal multiplier un objet réel! Composition et décomposition séparer les préoccupations (conception individuelle / assemblage) réutiliser les efforts de conception et de réalisation 4 4

9 Quelques paradigmes de lʼarchitecture des systèmes! Virtualisation concrétiser un objet idéal multiplier un objet réel! Composition et décomposition séparer les préoccupations (conception individuelle / assemblage) réutiliser les efforts de conception et de réalisation! Auto-adaptation et réflexivité réagir au changement (prévu ou imprévu) optimiser des critères de qualité 4 4

10 Quelques paradigmes de lʼarchitecture des systèmes! Virtualisation concrétiser un objet idéal multiplier un objet réel! Composition et décomposition séparer les préoccupations (conception individuelle / assemblage) réutiliser les efforts de conception et de réalisation une préoccupation «transversale» Formalisation, preuve! Auto-adaptation et réflexivité réagir au changement (prévu ou imprévu) optimiser des critères de qualité 4 4

11 Les deux faces de la virtualisation! Ascendante (abstraction) Un outil de partage de ressources Création de ressources «hautes» Multiplexage de ressources «basses» interface existante interface exportée 5 5

12 Les deux faces de la virtualisation! Ascendante (abstraction) Un outil de partage de ressources Création de ressources «hautes» Multiplexage de ressources «basses» interface existante interface exportée! Descendante (raffinement) Un outil de conception De la spécification à la réalisation Hiérarchie de machines abstraites interface souhaitée interface existante 5 5

13 Les deux faces de la virtualisation! Ascendante (abstraction) Un outil de partage de ressources Création de ressources «hautes» Multiplexage de ressources «basses» Interface visible, réalisation cachée Transformation (ou non) dʼinterfaces Préservation dʼinvariants! Descendante (raffinement) Un outil de conception De la spécification à la réalisation Hiérarchie de machines abstraites interface existante interface souhaitée interface existante interface exportée 5 5

14 Quoi virtualiser, et pourquoi?! Virtualiser des ressources À lʼintérieur dʼun système dʼexploitation processeur => processus, mémoire physique => mémoire virtuelle écran => fenêtre, périphérique => flot dʼentrée-sortie, 6 6

15 Quoi virtualiser, et pourquoi?! Virtualiser des ressources À lʼintérieur dʼun système dʼexploitation processeur => processus, mémoire physique => mémoire virtuelle écran => fenêtre, périphérique => flot dʼentrée-sortie,! Virtualiser une machine Pour multiplexer les ressources Pour accueillir plusieurs systèmes dʼexploitation Pour assurer sécurité et tolérance aux fautes 6 6

16 Quoi virtualiser, et pourquoi?! Virtualiser des ressources À lʼintérieur dʼun système dʼexploitation processeur => processus, mémoire physique => mémoire virtuelle écran => fenêtre, périphérique => flot dʼentrée-sortie,! Virtualiser une machine Pour multiplexer les ressources Pour accueillir plusieurs systèmes dʼexploitation Pour assurer sécurité et tolérance aux fautes! Virtualiser un réseau Pour spécialiser une fonction (sécurité, performances, ) 6 6

17 Quoi virtualiser, et pourquoi?! Virtualiser des ressources À lʼintérieur dʼun système dʼexploitation processeur => processus, mémoire physique => mémoire virtuelle écran => fenêtre, périphérique => flot dʼentrée-sortie,! Virtualiser une machine Pour multiplexer les ressources Pour accueillir plusieurs systèmes dʼexploitation Pour assurer sécurité et tolérance aux fautes! Virtualiser un réseau Pour spécialiser une fonction (sécurité, performances, )! Virtualiser un environnement dʼexécution Langage de programmation (machine virtuelle dédiée au langage) Plate-forme (+ intergiciel (+ support dʼapplications)) 6 6

18 Brève histoire de la virtualisation Mémoire stable MV Smalltalk Hardware UNCOL P-code (MV Pascal) Abstraction Layer (HAL) JVM (MV Java) CLI (.Net) THE IBM S/38 Windows NT Mémoire virtuelle Processus (processeur virtuel) Machine virtuelle (IBM CP) VM/370 VMware DISCO (grappe virtuelle) Xen Cloud Computing Réseaux de recouvrement (overlay) 7 7

19 Virtualisation pour les langages! Solution mixte entre compilation et interprétation Code source Code source Compilateur Code objet Machine physique Interprète (machine virtuelle) Machine physique 8 8

20 Virtualisation pour les langages! Solution mixte entre compilation et interprétation Code source Compilateur Code objet Machine physique Code source Interprète (machine virtuelle) Machine physique Code source Compilateur Code intermédiaire Machine virtuelle Machine physique 8 8

21 Virtualisation pour les langages! Solution mixte entre compilation et interprétation Code source Compilateur Code objet Machine physique Code source Interprète (machine virtuelle) Machine physique Code source Compilateur Code intermédiaire Machine virtuelle Machine physique! Avantages Portabilité (un seul compilateur) Abstractions «sur mesure» adaptées à un (une classe de) langage(s) Objets, composants, méta-données, Fonctions étendues pour la MV Sécurité Mise au point, mesures Réflexivité Exemples : P-Code (Pascal) JVM (Java) CLI 8 8

22 Virtualisation dʼune ressource : la mémoire stable Read Write observation Disque physique [hypothèses de défaillance] B. W. Lampson and H. E. Sturgis. Crash Recovery in a Distributed Data Storage System, unpublished technical report, Xerox PARC, June 1979, 25 pp. 9 9

23 Virtualisation dʼune ressource : la mémoire stable CarefulPut CarefulGet Disque soigneux Read Write [invariants] élimine défaillances transitoires observation Disque physique [hypothèses de défaillance] B. W. Lampson and H. E. Sturgis. Crash Recovery in a Distributed Data Storage System, unpublished technical report, Xerox PARC, June 1979, 25 pp. 9 9

24 Virtualisation dʼune ressource : la mémoire stable Cleanup Disque stable Disque soigneux StableGet StablePut CarefulGet CarefulPut [invariants] Read Write [invariants] résiste aux défaillances non catastrophiques élimine défaillances transitoires observation Disque physique [hypothèses de défaillance] B. W. Lampson and H. E. Sturgis. Crash Recovery in a Distributed Data Storage System, unpublished technical report, Xerox PARC, June 1979, 25 pp. 9 9

25 Virtualisation dʼune ressource : la mémoire stable Cleanup Disque stable Disque soigneux StableGet StablePut CarefulGet CarefulPut [invariants] Read Write [invariants] résiste aux défaillances non catastrophiques élimine défaillances transitoires observation Disque physique [hypothèses de défaillance] B. B. W. W. Lampson, Atomic and H. Transactions, E. Sturgis. Crash in Distributed Recovery in Systems Architecture a Distributed Data Storage and Implementation, System, unpublished ed. Lampson, technical Paul, report, and Xerox Siegert, PARC, LNCS June 105, 1979, Springer, 25 pp. 1981, pp

26 Machines virtuelles «classiques» Interface machine physique MV1 MV2 Hyperviseur Machine physique 10 10

27 Machines virtuelles «classiques» Interface machine physique Appli. Appli. Appli. MV1 OS MV2 OS Hyperviseur Machine physique 10 10

28 Machines virtuelles «classiques»! Lʼhyperviseur, un super-os Présente une interface uniforme aux machines virtuelles (MVs) Gère (et protège) les ressources physiques Encapsule lʼétat interne des MVs Cʼest un composant critique Isolation Défaillances Sécurité Interface machine physique Appli. Appli. Appli. MV1 OS MV2 OS Hyperviseur Machine physique 10 10

29 Machines virtuelles «classiques»! Lʼhyperviseur, un super-os Présente une interface uniforme aux machines virtuelles (MVs) Gère (et protège) les ressources physiques Encapsule lʼétat interne des MVs Cʼest un composant critique Isolation Défaillances Sécurité Interface machine physique Appli. Appli. Appli. MV1 OS MV2 OS Hyperviseur James E. Smith, Ravi Nair, Virtual Machines, Morgan Kaufmann, 2005 Virtualization Technologies, IEEE Computer, May 2005 Machine physique 10 10

30 Machines virtuelles : comment çà marche Appli. Mode utilisateur OS Trap Instructions privilégiées Mode privilégié Machine physique 11 11

31 Machines virtuelles : comment çà marche Appli. Mode utilisateur Trap Instructions privilégiées OS Interruption Instructions privilégiées Mode privilégié Machine physique 11 11

32 Machines virtuelles : comment çà marche Appli. Appli. OS Mode utilisateur Instructions privilégiées OS Entrées-sorties Interruptions Mémoire virtuelle Trap Instructions privilégiées Interruption Instructions privilégiées Mode privilégié Hyperviseur Trap État MV1 État MV2 Machine physique Machine physique 11 11

33 Machines virtuelles : comment çà marche Appli. Appli. OS Mode utilisateur Instructions privilégiées OS Entrées-sorties Interruptions Mémoire virtuelle Trap Instructions privilégiées Interruption Instructions privilégiées Mode privilégié Hyperviseur Trap État MV1 État MV2 Machine physique Machine physique! Un problème Sur les machines actuelles (IA-32, etc.), lʼeffet de certaines instructions dépend du mode courant (privilégié ou utilisateur) De telles instructions ne sont pas virtualisables 11 11

34 Machines virtuelles Interface modifiée MV1 MV2 Hyperviseur Machine physique 12 12

35 Machines virtuelles Interface modifiée Appli. Appli. Appli. Unix MV1 modifié Windows MV2 modifié Hyperviseur Machine physique 12 12

36 Machines virtuelles! Comment contourner le problème des instructions multi-modes? La paravirtualisation : changer lʼinterface de lʼhyperviseur Remplacer les instructions non virtualisables Lʼinterface nʼest plus celle de la machine physique Les OS doivent donc être modifiés! En pratique, on ne modifie que la HAL (couche dʼabstraction) Interface modifiée Appli. Unix MV1 modifié HAL-U Appli. Appli. Hyperviseur Windows MV2 modifié HAL-W Machine physique 12 12

37 Machines virtuelles! Comment contourner le problème des instructions multi-modes? La paravirtualisation : changer lʼinterface de lʼhyperviseur Remplacer les instructions non virtualisables Lʼinterface nʼest plus celle de la machine physique Les OS doivent donc être modifiés! En pratique, on ne modifie que la HAL (couche dʼabstraction) Interface modifiée La traduction dynamique de code binaire : Remplacer à la volée les instructions non virtualisables Appli. Unix MV1 modifié HAL-U Appli. Appli. Hyperviseur Windows MV2 modifié HAL-W Machine physique 12 12

38 Machines virtuelles! Comment contourner le problème des instructions multi-modes? La paravirtualisation : changer lʼinterface de lʼhyperviseur Remplacer les instructions non virtualisables Lʼinterface nʼest plus celle de la machine physique Les OS doivent donc être modifiés! En pratique, on ne modifie que la HAL (couche dʼabstraction) Interface modifiée La traduction dynamique de code binaire : Remplacer à la volée les instructions non virtualisables Dans lʼavenir : Appli. Unix MV1 modifié HAL-U Les nouveaux processeurs sont conçus pour la virtualisation Appli. Appli. Hyperviseur Windows MV2 modifié HAL-W Machine physique 12 12

39 Grappes virtuelles UC UC UC UC UC UC UC UC Réseau dʼinterconnexion (+ mémoire partagée) niveau physique 13 13

40 Grappes virtuelles MV MV MV Application Application App App OS OS Système dʼexploitation Cellular Disco (Hyperviseur) UC UC UC UC UC UC UC UC Réseau dʼinterconnexion (+ mémoire partagée) niveau physique 13 13

41 Grappes virtuelles MV MV MV Application Application App App OS OS Système dʼexploitation limites de confinement des fautes Cellular Disco (Hyperviseur) UC UC UC UC UC UC UC UC Réseau dʼinterconnexion (+ mémoire partagée) niveau physique 13 13

42 Grappes virtuelles MV MV MV Application Application App App OS OS Système dʼexploitation limites de confinement des fautes Cellular Disco (Hyperviseur) UC UC UC UC UC UC UC UC Réseau dʼinterconnexion (+ mémoire partagée) niveau physique 13 13

43 Grappes virtuelles MV MV MV Application Application App App OS OS Système dʼexploitation limites de confinement des fautes Cellular Disco (Hyperviseur) UC UC UC UC UC UC UC UC Réseau dʼinterconnexion (+ mémoire partagée) niveau physique K. Govil, D. Teodosiu, Y. Huang, M. Rosenblum. Cellular Disco: Resource Management Using Virtual Clusters on Shared-Memory Multiprocessors, ACM Trans. on Computer Systems, 18(3), Aug

44 Réseaux de recouvrement 14 14

45 Réseaux de recouvrement! Objectifs Routage Fiabilité Sécurité, confidentialité Qualité de service Support dʼune plate-forme 14 14

46 Réseaux de recouvrement! Objectifs Routage Fiabilité Sécurité, confidentialité Qualité de service Support dʼune plate-forme! Exemples LʼInternet lui-même Tables de hachage réparti VPN Service spécialisé (distribution de contenu) 14 14

47 Cloud computing : lʼinformatique dans les nuages! Une vision ancienne «computing may someday be organized as a public utility just as the telephone system is a public utility» John McCarthy,

48 Cloud computing : lʼinformatique dans les nuages! Une vision ancienne «computing may someday be organized as a public utility just as the telephone system is a public utility»! en voie de réalisation? John McCarthy,

49 Cloud computing : lʼinformatique dans les nuages! Une vision ancienne «computing may someday be organized as a public utility just as the telephone system is a public utility»! en voie de réalisation?! Virtualisation à grande échelle John McCarthy, 1961 du matériel : Infrastructure as a Service (Amazon EC2) de lʼenvironnement dʼexécution : Platform as a Service (Microsoft Azure) du support dʼapplications : Software as a Service (Google Docs) 15 15

50 Cloud computing : lʼinformatique dans les nuages! Une vision ancienne «computing may someday be organized as a public utility just as the telephone system is a public utility»! en voie de réalisation?! Virtualisation à grande échelle John McCarthy, 1961 du matériel : Infrastructure as a Service (Amazon EC2) de lʼenvironnement dʼexécution : Platform as a Service (Microsoft Azure) du support dʼapplications : Software as a Service (Google Docs)! Un nouveau modèle économique mais des problèmes potentiels 15 15

51 Cloud computing : lʼinformatique dans les nuages! Une vision ancienne «computing may someday be organized as a public utility just as the telephone system is a public utility»! en voie de réalisation?! Virtualisation à grande échelle John McCarthy, 1961 du matériel : Infrastructure as a Service (Amazon EC2) de lʼenvironnement dʼexécution : Platform as a Service (Microsoft Azure) du support dʼapplications : Software as a Service (Google Docs)! Un nouveau modèle économique mais des problèmes potentiels! Un domaine de recherche ouvert [voir journée Clouds, ENS Lyon, 13 décembre 2010] 15 15

52 Questions sur les nuages! Quels sont les traits originaux? 16 16

53 Questions sur les nuages! Quels sont les traits originaux? «Élasticité» : le client paie ce quʼil consomme, facturation à grain fin Pour le client : économie, pas de risque de sur/sous-dimensionnement, capacité potentiellement illimitée Pour le fournisseur : gain (effet dʼéchelle, multiplexage statistique, rentabilisation des investissements) Réactivité aux variations de la demande D. Owens, Securing Elasticity in the Cloud, Comm. of the ACM, vol. 53, no 6, June

54 Questions sur les nuages! Quels sont les traits originaux? «Élasticité» : le client paie ce quʼil consomme, facturation à grain fin Pour le client : économie, pas de risque de sur/sous-dimensionnement, capacité potentiellement illimitée Pour le fournisseur : gain (effet dʼéchelle, multiplexage statistique, rentabilisation des investissements) Réactivité aux variations de la demande! Quels sont les risques et les difficultés? D. Owens, Securing Elasticity in the Cloud, Comm. of the ACM, vol. 53, no 6, June 2010 Limites techniques : évolution, passage à grande échelle, latence 16 16

55 Questions sur les nuages! Quels sont les traits originaux? «Élasticité» : le client paie ce quʼil consomme, facturation à grain fin Pour le client : économie, pas de risque de sur/sous-dimensionnement, capacité potentiellement illimitée Pour le fournisseur : gain (effet dʼéchelle, multiplexage statistique, rentabilisation des investissements) Réactivité aux variations de la demande! Quels sont les risques et les difficultés? D. Owens, Securing Elasticity in the Cloud, Comm. of the ACM, vol. 53, no 6, June 2010 Limites techniques : évolution, passage à grande échelle, latence Perte de contrôle sur les données (localisation, sécurité, ) 16 16

56 Questions sur les nuages! Quels sont les traits originaux? «Élasticité» : le client paie ce quʼil consomme, facturation à grain fin Pour le client : économie, pas de risque de sur/sous-dimensionnement, capacité potentiellement illimitée Pour le fournisseur : gain (effet dʼéchelle, multiplexage statistique, rentabilisation des investissements) Réactivité aux variations de la demande! Quels sont les risques et les difficultés? D. Owens, Securing Elasticity in the Cloud, Comm. of the ACM, vol. 53, no 6, June 2010 Limites techniques : évolution, passage à grande échelle, latence Perte de contrôle sur les données (localisation, sécurité, ) Pas de baisse significative du prix sans sacrifier les garanties de performances les garanties de disponibilité les garanties de sécurité D. Durkee, Why Cloud Computing Will Never Be Free, Comm. of the ACM, vol. 53, no 5, May

57 Virtualisation dans les systèmes embarqués! Contraintes spécifiques Complexité croissante des applications Maîtrise des performances Réduction de la taille de la base informatique de confiance 17 17

58 Virtualisation dans les systèmes embarqués! Contraintes spécifiques Complexité croissante des applications Maîtrise des performances Réduction de la taille de la base informatique de confiance! Un renouveau pour les micro-noyaux Le micro-noyau comme hyperviseur à bas niveau Des systèmes dʼexploitation «sur mesure» pour une application permet de réaliser des «appareils virtuels» (appareil + son OS spécifique) Les pilotes peuvent sortir de la base de confiance Les composants critiques peuvent être isolés dans des MV G. Heiser, The Role of Virtualization in Embedded Systems, Proc. First Workshop on Isolation and Integration in Embedded Systems (IIESʼ08), pp 11-16, April

59 Un micro-noyau vérifié 2010, S. Krakowiak Congrès Specif

60 Un micro-noyau vérifié! Une version du micro-noyau L4 Machine virtuelle donnant une image simplifiée du matériel! Difficultés Asynchronisme Gestion de la mémoire (pointeurs) Accès direct aux fonctions du matériel (MMU, ) Gerwin Klein et al., sel4: Formal Verification of an Operating-System Kernel, Communications of the ACM, vol. 53, no 6, pp , June , S. Krakowiak Congrès Specif

61 Un micro-noyau vérifié! Une version du micro-noyau L4 Machine virtuelle donnant une image simplifiée du matériel! Difficultés Asynchronisme Gestion de la mémoire (pointeurs) Accès direct aux fonctions du matériel (MMU, ) conception prototype Haskell Simulateur Isabelle/HOL spécification abstraite Gerwin Klein et al., sel4: Formal Verification of an Operating-System Kernel, Communications of the ACM, vol. 53, no 6, pp , June , S. Krakowiak Congrès Specif

62 Un micro-noyau vérifié! Une version du micro-noyau L4 Machine virtuelle donnant une image simplifiée du matériel! Difficultés Asynchronisme Gestion de la mémoire (pointeurs) Accès direct aux fonctions du matériel (MMU, ) conception prototype Haskell génération automatique Isabelle/HOL spécification abstraite spécification exécutable Gerwin Klein et al., sel4: Formal Verification of an Operating-System Kernel, Communications of the ACM, vol. 53, no 6, pp , June , S. Krakowiak Congrès Specif

63 Un micro-noyau vérifié! Une version du micro-noyau L4 Machine virtuelle donnant une image simplifiée du matériel! Difficultés Asynchronisme Gestion de la mémoire (pointeurs) Accès direct aux fonctions du matériel (MMU, ) conception prototype Haskell génération automatique Isabelle/HOL spécification abstraite spécification exécutable raffinement preuve Gerwin Klein et al., sel4: Formal Verification of an Operating-System Kernel, Communications of the ACM, vol. 53, no 6, pp , June , S. Krakowiak Congrès Specif

64 Un micro-noyau vérifié! Une version du micro-noyau L4 Machine virtuelle donnant une image simplifiée du matériel! Difficultés Asynchronisme Gestion de la mémoire (pointeurs) Accès direct aux fonctions du matériel (MMU, ) conception prototype Haskell génération automatique Isabelle/HOL spécification abstraite spécification exécutable code C optimisé raffinement preuve raffinement preuve Gerwin Klein et al., sel4: Formal Verification of an Operating-System Kernel, Communications of the ACM, vol. 53, no 6, pp , June , S. Krakowiak Congrès Specif

65 Un micro-noyau vérifié! Une version du micro-noyau L4 Machine virtuelle donnant une image simplifiée du matériel! Difficultés Asynchronisme Gestion de la mémoire (pointeurs) Accès direct aux fonctions du matériel (MMU, )! sel4, base dʼun microviseur OKL4 (Open Kernel Labs) Base installée : un milliard conception prototype Haskell génération automatique Isabelle/HOL spécification abstraite spécification exécutable code C optimisé raffinement preuve raffinement preuve Gerwin Klein et al., sel4: Formal Verification of an Operating-System Kernel, Communications of the ACM, vol. 53, no 6, pp , June , S. Krakowiak Congrès Specif

66 Avancées et défis pour la virtualisation! Renaissance et extension du champ de la virtualisation Des nuages aux systèmes embarqués Plate-formes et applications dématérialisés Portables dʼun support à un autre, dʼun lieu à un autre Outil de gestion globale des ressources Support dʼexpérimentation 19 19

67 Avancées et défis pour la virtualisation! Renaissance et extension du champ de la virtualisation! Défis Des nuages aux systèmes embarqués Plate-formes et applications dématérialisés Portables dʼun support à un autre, dʼun lieu à un autre Outil de gestion globale des ressources Support dʼexpérimentation Pour lʼutilisateur Contrôle sur le management et les données Garanties de disponibilité et de sécurité Pour le concepteur Modélisation et vérification des hyperviseurs Administration automatique des grandes infrastructures Gestion dʼenvironnements virtuels multiples 19 19

68 Composition (et décomposition)! Un objectif dʼapparence simple Composer un système à partir de pièces élémentaires Éléments réutilisables et remplaçables ( échange standard ) Interface visible, réalisation cachée M. D. McIlroy (1968) Mass Produced Software Components, in P. Naur and B. Randell, eds., Software Engineering, NATO Science Committee 20 20

69 Composition (et décomposition)! Un objectif dʼapparence simple Composer un système à partir de pièces élémentaires Éléments réutilisables et remplaçables ( échange standard ) Interface visible, réalisation cachée! mais une route semée dʼembûches Conceptuelles Modèle(s) Expression dʼune description globale Garanties Pratiques Configuration et déploiement Gestion de lʼévolution Infrastructures M. D. McIlroy (1968) Mass Produced Software Components, in P. Naur and B. Randell, eds., Software Engineering, NATO Science Committee 20 20

70 Propriétés de la composition! Composabilité Les propriétés de chaque composant sont préservées dans le système composé 21 21

71 Propriétés de la composition! Composabilité Les propriétés de chaque composant sont préservées dans le système composé Séparation interfaceréalisation Respect de règles de «bon assemblage» 21 21

72 Propriétés de la composition! Composabilité Les propriétés de chaque composant sont préservées dans le système composé Séparation interfaceréalisation Respect de règles de «bon assemblage»! Compositionnalité Les propriétés du système composé se déduisent de celles des composants et des règles dʼassemblage 21 21

73 Propriétés de la composition! Composabilité Les propriétés de chaque composant sont préservées dans le système composé Séparation interfaceréalisation Respect de règles de «bon assemblage» Beaucoup plus difficile!! Compositionnalité Les propriétés du système composé se déduisent de celles des composants et des règles dʼassemblage Modèle formel de composition Expression de la sémantique Garanties à lʼexécution 21 21

74 Deux styles de composition! Dirigé par le flot dʼexécution Méthodes Interfaces Données (encapsulées) Dérivé de modules, objets Divers composants industriels Exemples : OpenCOM, Fractal, OSGi, 22 22

75 Deux styles de composition! Dirigé par le flot dʼexécution Méthodes Interfaces Données (encapsulées)! Dirigé par le flot de données État, transitions Portes (entrée, sortie) Dérivé de modules, objets Divers composants industriels Exemples : OpenCOM, Fractal, OSGi, Flots et filtres Événements Systèmes réactifs Exemples : Ptolemy, Bip, 22 22

76 Deux styles de composition! Dirigé par le flot dʼexécution Méthodes Interfaces Données (encapsulées)! Dirigé par le flot de données État, transitions Portes (entrée, sortie) Les deux peuvent coexister Dérivé de modules, objets Divers composants industriels Exemples : OpenCOM, Fractal, OSGi, Flots et filtres Événements Systèmes réactifs Exemples : Ptolemy, Bip, Propriétés communes Description globale Préservation à lʼexécution Indépendance par rapport au langage Dépendances explicites 22 22

77 Brève histoire de la (dé)composition Modèles de composants Simula-67 Objets Smalltalk-80 RM-ODP fabrique de Types Modula liaison abstraits Mesa Clu Ada Fractal, Koala, Ptolemy, UML 2, BIP, 1960 Flot de Acteurs Langages Systèmes données pipes Unix synchrones hybrides subroutines procédures mass-produced software components information hiding programming in the large RPC MILs ADLs SOM COM, DCOM,.Net OSGi Conic, Darwin, EJB Services Web Wright, Rapide, ACME, ADML, ArchJava software architecture: an emerging discipline ADLs dynamiques Configuration formalisation types, preuves 23 23

78 Architecture de systèmes composés (1) Interface Connecteur Composant Composant Composant 24 24

79 Architecture de systèmes composés (1) Interface Connecteur Composant Composant Configuration Composant 24 24

80 Architecture de systèmes composés (1) Interface Connecteur Composant Composant fournie requise Composant flot entrée flot sortie Configuration 24 24

81 Architecture de systèmes composés (1) Interface Connecteur Composant Composant fournie requise Composant flot entrée flot sortie Configuration! Flot dʼexécution ou flot de données Similitudes Composants matériels ou logiciels Une configuration est un composant Les interfaces sont typées Différences Rôle des interfaces, ou ports Modèle dʼinteraction (séquentiel, parallèle) Synchrone, rendez-vous, événements, etc

82 Architecture de systèmes composés (1) Interface Connecteur Composant Composant fournie requise Composant flot entrée flot sortie Configuration! Flot dʼexécution ou flot de données Similitudes Composants matériels ou logiciels Une configuration est un composant Les interfaces sont typées Différences Rôle des interfaces, ou ports Modèle dʼinteraction (séquentiel, parallèle) Synchrone, rendez-vous, événements, etc. Description globale Implicite (dépendances) Explicite (Architecture Description Language, ADL) Rôle des connecteurs Assurer la liaison Opération complexe en système réparti Gérer lʼinteraction En particulier dans les modèles parallèles 24 24

83 Architecture de systèmes composés (2)! Cycle de vie Configuration Déploiement Exécution Reconfiguration 25 25

84 Architecture de systèmes composés (2)! Cycle de vie Configuration Déploiement Exécution Reconfiguration! Réflexivité Examiner son propre état («introspection») Agir sur son propre état («intercession») Méta-niveau et connexion causale Interface de management Exemples Rainbow, OpenCOM, Fractal, Interface de management méta-niveau niveau de base 25 25

85 Formalisation de la composition : trois exemples! Déterminer la validité de la construction dʼun système composé (composabilité) Configuration dʼun assemblage de composants 26 26

86 Formalisation de la composition : trois exemples! Déterminer la validité de la construction dʼun système composé (composabilité) Configuration dʼun assemblage de composants! Déterminer la validité de lʼexécution dʼun système composé (compositionnalité) Applications du typage 26 26

87 Formalisation de la composition : trois exemples! Déterminer la validité de la construction dʼun système composé (composabilité) Configuration dʼun assemblage de composants! Déterminer la validité de lʼexécution dʼun système composé (compositionnalité) Applications du typage! Déterminer la validité de lʼévolution dʼun système composé Reconfiguration 26 26

88 Un problème de configuration! Source : EDOS (Environment for the development & Distribution of Open Source Software) Projet de recherche collaborative du 6ème programme-cadre européen Distribution de logiciel libre, constitué de packages Description implicite, par un ensemble de relations Référence :

89 Un problème de configuration! Source : EDOS (Environment for the development & Distribution of Open Source Software) Projet de recherche collaborative du 6ème programme-cadre européen Distribution de logiciel libre, constitué de packages Description implicite, par un ensemble de relations! Gestion des relations entre packages Dépendance : spécifie des packages (y compris numéros de version) qui doivent être présents pour faire fonctionner le package courant Conflit : spécifie des packages qui ne peuvent pas coexister avec le package courant Pré-dépendance : spécifie des packages qui doivent déjà être présents pour pouvoir déployer le package courant Taille typique : packages, relations Référence :

90 Formalisation de lʼinstallabilité dans EDOS! chaque package p (version v) est désigné par une variable booléenne p v! chaque contrainte sur une version (e.g., v > 4.0 ) est traduite dans la disjonction des packages qui satisfont cette contrainte, e.g., p v1! p v2!! chaque dépendence est interprétée comme une implication, e.g., aterm => libc6 " (libce6! xlibs) "! chaque conflit entre des packages (soit a et b) est interprétée comme la formule (a " b) 28 28

91 Formalisation de lʼinstallabilité dans EDOS! chaque package p (version v) est désigné par une variable booléenne p v! chaque contrainte sur une version (e.g., v > 4.0 ) est traduite dans la disjonction des packages qui satisfont cette contrainte, e.g., p v1! p v2!! chaque dépendence est interprétée comme une implication, e.g., aterm => libc6 " (libce6! xlibs) "! chaque conflit entre des packages (soit a et b) est interprétée comme la formule (a " b) Alors un package p v est installable ssi il existe une affectation de valeurs qui rende p v VRAI et qui satisfasse la conjonction de toutes les implications logiques introduites par les dépendances et les conflits

92 Formalisation de lʼinstallabilité dans EDOS! chaque package p (version v) est désigné par une variable booléenne p v! chaque contrainte sur une version (e.g., v > 4.0 ) est traduite dans la disjonction des packages qui satisfont cette contrainte, e.g., p v1! p v2!! chaque dépendence est interprétée comme une implication, e.g., aterm => libc6 " (libce6! xlibs) "! chaque conflit entre des packages (soit a et b) est interprétée comme la formule (a " b) Alors un package p v est installable ssi il existe une affectation de valeurs qui rende p v VRAI et qui satisfasse la conjonction de toutes les implications logiques introduites par les dépendances et les conflits. Lʼinstallabilité des packages est équivalente à la satisfaisabilité booléenne (SAT), problème NP-complet. Dans les situations pratiques, il est néanmoins traitable

93 Compositionnalité dans Dream Dream : canevas pour la construction dʼintergiciels de communication Un message est une séquence de champs nommés. Exemple [Nom: "test"] [TS: 10] [IP: ] Un message circule entre des composants qui le traitent Exemple de traitements : ajouter, supprimer, consulter un champ Opérations interdites (provoquent une erreur à lʼexécution) Ajouter un champ présent, supprimer ou consulter un champ non présent M. Leclercq, V. Quéma, J.-B. Stefani, "DREAM: A Component Framework for Constructing Resource- Aware, Configurable Middleware," Distributed Systems Online, IEEE, 6:9, Sept

94 Compositionnalité dans Dream Dream : canevas pour la construction dʼintergiciels de communication Un message est une séquence de champs nommés. Exemple [Nom: "test"] [TS: 10] [IP: ] Un message circule entre des composants qui le traitent Exemple de traitements : ajouter, supprimer, consulter un champ Opérations interdites (provoquent une erreur à lʼexécution) Ajouter un champ présent, supprimer ou consulter un champ non présent (X) Duplicator (X) (X) canaux ReadTS AddTS M. Leclercq, V. Quéma, J.-B. Stefani, "DREAM: A Component Framework for Constructing Resource- Aware, Configurable Middleware," Distributed Systems Online, IEEE, 6:9, Sept

95 Compositionnalité dans Dream Dream : canevas pour la construction dʼintergiciels de communication Un message est une séquence de champs nommés. Exemple [Nom: "test"] [TS: 10] [IP: ] Un message circule entre des composants qui le traitent Exemple de traitements : ajouter, supprimer, consulter un champ Opérations interdites (provoquent une erreur à lʼexécution) Ajouter un champ présent, supprimer ou consulter un champ non présent (X) Duplicator (X) (X) canaux ReadTS AddTS erreur si TS absent de X erreur si TS présent dans X M. Leclercq, V. Quéma, J.-B. Stefani, "DREAM: A Component Framework for Constructing Resource- Aware, Configurable Middleware," Distributed Systems Online, IEEE, 6:9, Sept

96 Compositionnalité dans Dream Dream : canevas pour la construction dʼintergiciels de communication Un message est une séquence de champs nommés. Exemple [Nom: "test"] [TS: 10] [IP: ] Un message circule entre des composants qui le traitent Exemple de traitements : ajouter, supprimer, consulter un champ Opérations interdites (provoquent une erreur à lʼexécution) Ajouter un champ présent, supprimer ou consulter un champ non présent (X) Duplicator (X) (X) canaux ReadTS AddTS erreur si TS absent de X erreur si TS présent dans X Les types Java ne permettent pas ces vérifications M. Leclercq, V. Quéma, J.-B. Stefani, "DREAM: A Component Framework for Constructing Resource- Aware, Configurable Middleware," Distributed Systems Online, IEEE, 6:9, Sept

97 Types Dream! Exemple (tschunk: pre(ts); Y) (tschunk: pre(ts); Y) (X) Duplicator (X) (X) canaux ReadTS abs ou liste de champs (tschunk: abs(ts); Z) (tschunk: pre(ts); Z) AddTS 30 30

98 Types Dream! Exemple (tschunk: pre(ts); Y) (tschunk: pre(ts); Y) (X) Duplicator (X) (X) canaux ReadTS abs ou liste de champs (tschunk: abs(ts); Z) Repose sur un nouveau calcul de processus, avec un algorithme dʼinférence de types AddTS (tschunk: pre(ts); Z) Typing Component-Based Communication Systems. M. Lienhardt, C. A. Mezzina, A. Schmitt, and J.-B. Stefani. In Proc. 11th Formal Methods for Open Object-Based Distributed Systems (FMOODS) & 29th Formal Techniques for Networked and Distributed Systems (FORTE), June

99 Types Dream! Exemple (tschunk: pre(ts); Y) (tschunk: pre(ts); Y) (X) Duplicator (X) (X) canaux ReadTS abs ou liste de champs (tschunk: abs(ts); Z) Repose sur un nouveau calcul de processus, avec un algorithme dʼinférence de types AddTS (tschunk: pre(ts); Z) Il faut résoudre (X) = (tschunk: pre(ts); Y) (X) = (tschunk: abs(ts); Z) ce qui est impossible Le système nʼest pas typable, et aura une erreur à lʼexécution Typing Component-Based Communication Systems. M. Lienhardt, C. A. Mezzina, A. Schmitt, and J.-B. Stefani. In Proc. 11th Formal Methods for Open Object-Based Distributed Systems (FMOODS) & 29th Formal Techniques for Networked and Distributed Systems (FORTE), June

100 Reconfiguration (1)! Quʼest-ce que la reconfiguration (dynamique)? Changement de la composition et/ou de la structure dʼun système en cours dʼexécution ajouter/supprimer un composant, déplacer un composant, changer des liaisons, modifier des attributs, 31 31

101 Reconfiguration (1)! Quʼest-ce que la reconfiguration (dynamique)? Changement de la composition et/ou de la structure dʼun système en cours dʼexécution ajouter/supprimer un composant, déplacer un composant, changer des liaisons, modifier des attributs,! Pourquoi reconfigurer un système? Maintenance, optimisation, insertion de sondes de mesure, réaction aux défaillances, surcharges, attaques, Opération naturelle pour les mobiles, réseaux de capteurs, etc

102 Reconfiguration (1)! Quʼest-ce que la reconfiguration (dynamique)? Changement de la composition et/ou de la structure dʼun système en cours dʼexécution ajouter/supprimer un composant, déplacer un composant, changer des liaisons, modifier des attributs,! Pourquoi reconfigurer un système? Maintenance, optimisation, insertion de sondes de mesure, réaction aux défaillances, surcharges, attaques, Opération naturelle pour les mobiles, réseaux de capteurs, etc.! Quelques bonnes pratiques Reconfiguration dirigée par lʼarchitecture Utilisation de la réflexivité Maintien de la cohérence Préservation dʼinvariants Perturbation minimale Interface de management méta-niveau niveau de base 31 31

103 Reconfiguration (2)! Spécification dʼinvariants Architecturaux : contraintes sur la structure Pas de circuit, pas de partage de composant, contraintes spécifiques à lʼapplication Comportementaux : contraintes sur lʼétat Cohérence de lʼétat, résistance aux pannes 32 32

104 Reconfiguration (2)! Spécification dʼinvariants Architecturaux : contraintes sur la structure Pas de circuit, pas de partage de composant, contraintes spécifiques à lʼapplication Comportementaux : contraintes sur lʼétat Cohérence de lʼétat, résistance aux pannes! Utilisation de la réflexivité Réification de lʼarchitecture Inspection et modification de lʼétat 32 32

105 Reconfiguration (2)! Spécification dʼinvariants Architecturaux : contraintes sur la structure Pas de circuit, pas de partage de composant, contraintes spécifiques à lʼapplication Comportementaux : contraintes sur lʼétat Cohérence de lʼétat, résistance aux pannes! Utilisation de la réflexivité Réification de lʼarchitecture Inspection et modification de lʼétat! Mécanique de la reconfiguration Détection de quiescence Interposition dynamique Remplacement de composant 32 32

106 Mise en œuvre de la reconfiguration : exemple! Un modèle de composants Fractal, fournit la réflexivité (interfaces de management) M. Léger, Th. Ledoux, Th. Coupaye. Reliable Dynamic Reconfigurations in a Reflective Component Model, Proc. CBSE 2010, LNCS 6092, pp , Springer Verlag 33 33

107 Mise en œuvre de la reconfiguration : exemple! Un modèle de composants Fractal, fournit la réflexivité (interfaces de management)! Un modèle pour lʼexpression des règles dʼassemblage Relations entre interfaces, attributs, composants ex : un composant possède une interface, une interface est liée à une interface, un composant contient un composant, Contraintes dʼintégrité : prédicats sur les éléments et relations M. Léger, Th. Ledoux, Th. Coupaye. Reliable Dynamic Reconfigurations in a Reflective Component Model, Proc. CBSE 2010, LNCS 6092, pp , Springer Verlag 33 33

108 Mise en œuvre de la reconfiguration : exemple! Un modèle de composants Fractal, fournit la réflexivité (interfaces de management)! Un modèle pour lʼexpression des règles dʼassemblage Relations entre interfaces, attributs, composants ex : un composant possède une interface, une interface est liée à une interface, un composant contient un composant, Contraintes dʼintégrité : prédicats sur les éléments et relations! Un outil de vérification des contraintes dʼintégrité Cohérence globale : Alloy (langage déclaratif + solveur SAT) Réalisation en Fractal : FPath M. Léger, Th. Ledoux, Th. Coupaye. Reliable Dynamic Reconfigurations in a Reflective Component Model, Proc. CBSE 2010, LNCS 6092, pp , Springer Verlag 33 33

109 Mise en œuvre de la reconfiguration : exemple! Un modèle de composants Fractal, fournit la réflexivité (interfaces de management)! Un modèle pour lʼexpression des règles dʼassemblage Relations entre interfaces, attributs, composants ex : un composant possède une interface, une interface est liée à une interface, un composant contient un composant, Contraintes dʼintégrité : prédicats sur les éléments et relations! Un outil de vérification des contraintes dʼintégrité Cohérence globale : Alloy (langage déclaratif + solveur SAT) Réalisation en Fractal : FPath! Une exécution transactionnelle Opérations via FScript (action sur interfaces de management) Garanties ACID M. Léger, Th. Ledoux, Th. Coupaye. Reliable Dynamic Reconfigurations in a Reflective Component Model, Proc. CBSE 2010, LNCS 6092, pp , Springer Verlag 33 33

110 Avancées et défis pour la composition! Avancées Composants, architectures logicielles Patrons et canevas pour la composition Début de formalisation 34 34

111 Avancées et défis pour la composition! Avancées! Défis Composants, architectures logicielles Patrons et canevas pour la composition Début de formalisation Bases formelles Multiplicité de modèles et des langages peut-être inévitable Intégration matériel-logiciel Compositionnalité en particulier : performances, synchronisation, temps physique Systèmes à grande échelle X 34 34

112 Systèmes auto-adaptables! Pourquoi des systèmes auto-adaptables? Maintenir lʼintégrité et la qualité de service dʼun système dans un environnement variable et imprévisible Besoins Charge Défaillances Attaques 35 35

113 Systèmes auto-adaptables! Pourquoi des systèmes auto-adaptables? Maintenir lʼintégrité et la qualité de service dʼun système dans un environnement variable et imprévisible Besoins Charge Défaillances Attaques! Approches de lʼauto-adaptation Centralisée Comportement global imposé Modèle : automatique, boucle de commande Décentralisée Comportement global résultant dʼinteractions locales Modèle : systèmes biologiques 35 35

114 Brève histoire des systèmes auto-adaptables Contrôle dʼadmission Tolérance aux fautes «Autonomic Adaptation computing» Systèmes dirigée par Régulateur réflexifs lʼarchitecture de charge Ordinateurs Programmes Programmation reconfigurables par aspects Application des reconfigurables méthodes de lʼautomatique 2010 Aloha Routage adaptatif Ethernet QoS dans les réseaux Systèmes multi-agents «Colonies de fourmis» Algorithmes épidémiques Gestion de lʼénergie Réseaux pair à pair Réseaux de capteurs 36

115 Auto-adaptation par rétroaction Comportement souhaité capteurs Système de commande Analyse, Décision Action Système commandé actionneurs 37 37

116 Auto-adaptation par rétroaction Comportement souhaité capteurs Système de commande Analyse, Décision Action Modèle du système commandé Modèle de la charge charge Système commandé actionneurs 37 37

117 Auto-adaptation par rétroaction Comportement souhaité capteurs Système de commande Analyse, Décision Action Modèle du système commandé Modèle de la charge charge Système commandé actionneurs Pour un système informatique, comment définir Le comportement souhaité? Les capteurs? Les actionneurs? Les modèles? La stratégie de décision? 37 37

118 Auto-adaptation par rétroaction Comportement souhaité Système de commande Modèle du système commandé capteurs Analyse, Décision Action Modèle de la charge Domaines dʼaction Qualité de service charge Système commandé actionneurs Tolérance aux fautes Sécurité Configuration Pour un système informatique, comment définir Le comportement souhaité? Les capteurs? Les actionneurs? Les modèles? La stratégie de décision? 37 37

119 Un exemple : auto-adaptation pour la QoS! Objectifs Contrat (Service Level Agreement), décliné en sous-objectifs (SLO) Exemple : 95% des requêtes sont servies en moins de 5 s Réduction du coût 38 38

120 Un exemple : auto-adaptation pour la QoS! Objectifs Contrat (Service Level Agreement), décliné en sous-objectifs (SLO) Exemple : 95% des requêtes sont servies en moins de 5 s Réduction du coût! Capteurs Problème : modélisation de la charge Problème : les paramètres de QoS sont difficiles à capturer Plus accessibles : lʼoccupation des ressources 38 38

121 Un exemple : auto-adaptation pour la QoS! Objectifs Contrat (Service Level Agreement), décliné en sous-objectifs (SLO) Exemple : 95% des requêtes sont servies en moins de 5 s Réduction du coût! Capteurs Problème : modélisation de la charge Problème : les paramètres de QoS sont difficiles à capturer Plus accessibles : lʼoccupation des ressources! Actionneurs Agir sur la demande : le contrôle dʼadmission Autre idée : applications auto-adaptables Agir sur lʼoffre : allocation de ressources (physiques, virtuelles) 38 38

122 Un exemple : auto-adaptation pour la QoS! Objectifs Contrat (Service Level Agreement), décliné en sous-objectifs (SLO) Exemple : 95% des requêtes sont servies en moins de 5 s Réduction du coût! Capteurs Problème : modélisation de la charge Problème : les paramètres de QoS sont difficiles à capturer Plus accessibles : lʼoccupation des ressources! Actionneurs Agir sur la demande : le contrôle dʼadmission Autre idée : applications auto-adaptables Agir sur lʼoffre : allocation de ressources (physiques, virtuelles)! Stratégie Seuils Commande proportionnelle / intégrale ] combinaison 38 38

123 Un exemple ancien avec contrôle dʼadmission taux dʼactivité CPU # # et n mesurés sur dernier intervalle dʼobservation (t- t, t) 100% Charge normale Sous-charge Surcharge a) modèle simple de comportement du système n Nombre de remplacements de page 39

124 Un exemple ancien avec contrôle dʼadmission taux dʼactivité CPU # # et n mesurés sur dernier intervalle dʼobservation (t- t, t) 100% Charge normale Sous-charge Surcharge a) modèle simple de comportement du système n Nombre de remplacements de page every t do if (overload) move one process from ready set to waiting set else if (underload and (waiting set $)) $ admit one waiting process to ready set 39

125 Un exemple ancien avec contrôle dʼadmission taux dʼactivité CPU # # et n mesurés sur dernier intervalle dʼobservation (t- t, t) Prévention de lʼécroulement : expériences IBM M44/44X (1968) 100% Charge normale B. Brawn, F. Gustavson. Program behavior in a paging environment. Proc. AFIPS FJCC, pp (1968) Sous-charge Surcharge a) modèle simple de comportement du système n Nombre de remplacements de page every t do if (overload) move one process from ready set to waiting set else if (underload and (waiting set $)) $ admit one waiting process to ready set Temps dʼexécution (secondes) sans contrôle dʼadmission avec contrôle dʼadmission Nombre de processus actifs b) effet de la limitation de charge par contrôle dʼadmission 39

126 Auto-adaptation pour la QoS : exemple (1) clients Web Application Stockage actionneurs capteurs commande Fournisseur Nuage 40 40

127 Auto-adaptation pour la QoS : exemple (1) clients Web Application Stockage actionneurs capteurs commande Fournisseur Nuage Exemple : commande de lʼétage «stockage de données» Allocation de serveurs à partir dʼun fournisseur de nuages Objectif : garantir le temps de réponse en présence de pics de charge Expérience sur Hadoop Distributed File System H. C. Lim, S. Babu, J. S. Chase. Automated Control for Elastic Storage, International Conf. On Autonomic Computing (ICAC), June 7-11,

128 Auto-adaptation pour la QoS : exemple (2)! Organisation de la commande Pour lʼallocation de serveurs actionneur : allouer/libérer des serveurs (interface du fournisseur) capteur : taux dʼutilisation du CPU (bien corrélé avec temps de réponse) stratégie : commande intégrale avec seuil (stabilité) 41 41

129 Auto-adaptation pour la QoS : exemple (2)! Organisation de la commande Pour lʼallocation de serveurs actionneur : allouer/libérer des serveurs (interface du fournisseur) capteur : taux dʼutilisation du CPU (bien corrélé avec temps de réponse) stratégie : commande intégrale avec seuil (stabilité) Pour la reconfiguration de lʼétage stockage (répartition de données) actionneur : fraction de bande passante allouée à la reconfiguration (qui interfère avec le traitement) capteur : temps nécessaire en fonction de la taille + impact de la reconfiguration sur le temps de réponse 41 41

130 Auto-adaptation pour la QoS : exemple (2)! Organisation de la commande Pour lʼallocation de serveurs actionneur : allouer/libérer des serveurs (interface du fournisseur) capteur : taux dʼutilisation du CPU (bien corrélé avec temps de réponse) stratégie : commande intégrale avec seuil (stabilité) Pour la reconfiguration de lʼétage stockage (répartition de données) actionneur : fraction de bande passante allouée à la reconfiguration (qui interfère avec le traitement) capteur : temps nécessaire en fonction de la taille + impact de la reconfiguration sur le temps de réponse Coordination entre les deux commandes ci-dessus but : eviter sur- ou sous-allocations ; éviter les oscillations moyen : machine à états assurant lʼalternance entre les deux commandes avec temporisation 41 41

131 Auto-adaptation pour la QoS : exemple (3) ENTATION! Résultats tone Guest Application Très bonne réactivité à un pic de charge modified and configured Cloudstone to run with front-end application server tier, PostgreSQL as or structured data, and HDFS as a distributed stort objects such as PDF documents and image files. (a posteriori) Bonne ing an HDFS class abstraction to Cloudstone to DFS storage corrélation APIs. We alsoentre added new temps paramestone s configuration de réponse file so that et users utilisation can easily tch between different file systems without having ource code. CPU In all, this involved adding 200 lines stone. The experiments use a block size in the 0KB, which is the maximum size of binary files udstone. The HDFS replica count is set to three ctices from production deployments. tributes the content objects (files) across an elasge nodes, called datanodes. A namenode tracks g replica counts and locations for each file. implementation, HDFS does not ensure that storest-balanced, since its internal policy isbasedon ty. However, Cloudstone s workload generator is t structured data and content objects are accessed ibution, which naturally balances requests across es. ified HDFS to expose the rebalancer s bandwidth ctuator to the external controller. We created an he HDFS namenode that notifies all HDFS datan Time (s) x 10 4 CPU Utilization (%) WH CPU Utilization Target (20%) (a) Average CPU utilization of the HDFS datanodes with static provisioning CPU Utilization (%) Rebalance +9 Storage Nodes WH CPU Utilization y h (20%) Time (s) x 10 4 y l Response Time (s) Response Time Target (3s) Time (s) x 10 4 (b) Response time of the Cloudstone application with static provisioning Response Time (s) Response Time Target (3s) Time (s) x 10 4 (c) Average CPU utilization of (d) Response time of the Cloudstone application with dynamic the HDFS datanodes with dynamic provisioning provisioning Figure 6: The performance of Cloudstone with static allocation (a,b) and our control policy (c,d), under a 10-fold increase in workload volume. The time periods with high volume of workload 42 is labeled as WH. 42

132 Auto-adaptation pour la QoS : exemple (3) ENTATION! Résultats tone Guest Application Très bonne réactivité à un pic de charge modified and configured Cloudstone to run with front-end application server tier, PostgreSQL as or structured data, and HDFS as a distributed stort objects such as PDF documents and image files. (a posteriori) Bonne ing an HDFS class abstraction to Cloudstone to DFS storage corrélation APIs. We alsoentre added new temps paramestone s configuration de réponse file so that et users utilisation can easily tch between different file systems without having ource code. CPU In all, this involved adding 200 lines stone. The experiments use a block size in the 0KB, which is the maximum size of binary files udstone. The HDFS replica count is set to three ctices from production deployments. tributes Figure the6 content of: objects (files) across an elasge nodes, called datanodes. A namenode tracks g replica H. C. counts Lim, and S. Babu, locations J. S. forchase. each file. implementation, Automated HDFS Control does for not Elastic ensurestorage, that storest-balanced, International sinceconf. its internal On Autonomic policy isbasedon ty. However, Computing Cloudstone s (ICAC), June workload 7-11, generator 2010 is t structured data and content objects are accessed ibution, 2010 which ACM, naturally Inc. balances requests across es. Included here by permission. ified HDFS to expose the rebalancer s bandwidth ctuator to the external controller. We created an he HDFS namenode that notifies all HDFS datan Time (s) x 10 4 CPU Utilization (%) WH CPU Utilization Target (20%) (a) Average CPU utilization of the HDFS datanodes with static provisioning CPU Utilization (%) Rebalance +9 Storage Nodes WH CPU Utilization y h (20%) Time (s) x 10 4 y l Response Time (s) Response Time Target (3s) Time (s) x 10 4 (b) Response time of the Cloudstone application with static provisioning Response Time (s) Response Time Target (3s) Time (s) x 10 4 (c) Average CPU utilization of (d) Response time of the Cloudstone application with dynamic the HDFS datanodes with dynamic provisioning provisioning Figure 6: The performance of Cloudstone with static allocation (a,b) and our control policy (c,d), under a 10-fold increase in workload volume. The time periods with high volume of workload is labeled as WH

133 Avancées et défis pour lʼauto-adaptation! Avancées Interaction fructueuse avec lʼautomatique domaine continu (boucle de commande) domaine discret (synthèse de contrôleurs) résultats pour QoS Composants et architectures réflexifs 43 43

134 Avancées et défis pour lʼauto-adaptation! Avancées! Défis Interaction fructueuse avec lʼautomatique domaine continu (boucle de commande) domaine discret (synthèse de contrôleurs) résultats pour QoS Composants et architectures réflexifs Approches multiniveaux (piloté vs auto-organisé) Expression des objectifs objectifs multicritères (performances, énergie, disponibilité, ) prise en compte de situations non prévues Modélisation, vérification, garanties liaison continu-discret, prise en compte du temps Sécurité 43 43

135 Remarques finales! Sur les paradigmes de lʼarchitecture Permanence des concepts, raffinement (lent ) dans leur mise en œuvre Nouveaux paradigmes mobilité, autonomie, 44 44

136 Remarques finales! Sur les paradigmes de lʼarchitecture Permanence des concepts, raffinement (lent ) dans leur mise en œuvre Nouveaux paradigmes mobilité, autonomie, puissance de lʼabstraction puissance (et développement) des modèles 44 44

137 Remarques finales! Sur les paradigmes de lʼarchitecture Permanence des concepts, raffinement (lent ) dans leur mise en œuvre Nouveaux paradigmes mobilité, autonomie,! Quelques défis pour lʼavenir Conceptuels modéles formels pour lʼarchitecture validité de la construction modélisation de la sécurité systèmes hybrides Pratiques description déclarative des environnements et contraintes génération automatique de systèmes spécialisés puissance de lʼabstraction puissance (et développement) des modèles administration et qualité de service des très grands systèmes 44 44