Cloud computing

Transcription

1 Cloud computing /74

2 Architectures pour le Cloud 2/74

3 Architectures pour le Cloud Introduction Les traitements Les stockages de données Les caches Des exemples 3/74

4 Introduction 4/74

5 Montée en charge Peak Traffic Approximately 90K concurrent visitors Publication de l'annonce de Hits par minutes l'iphone5 sur 500K le blog 59 serveurs Web Hits max = 20 x Hits initial 0K 11h 5/74 12h 13h 12 septembre h

6 La demande fonctionnelle Capacité d'accueil inclue les pointes de trafic Haute disponibilité tolérance aux pannes Temps de réponse en lien avec l'architecture Qualité de service de façon globale Exploitabilité supervision & maintenance Évolutivité plan fonctionnels & techniques Extensibilité dans de bonnes conditions 6/74

7 Comment faire? la capacité des serveurs est limitée : Gandi : 16 cœurs, 24Go RAM, 8 x 1To Disque pas de Scale-UP chez Amazon Concevoir en même temps l'application, l'architecture et la maintenance Augmenter la capacité d'accueil en augmentant le nombre de serveurs 7/74

8 Capacité d'accueil en fonction du nombre de serveurs 8/74

9 Les traitements 9/74

10 Objectif : élasticité Scalabilité : capacité d'une architecture à croître sans rupture, en ajoutant du matériel Extensibilité cellulaire (Scale Up) augmenter la puissance du serveur Extensibilité fonctionnelle (verticale) répartition des fonctions par serveurs Extensibilité horizontale (Scale Out) répartition de fonctions identiques sur différents serveurs homologues 10/74

11 Contraintes de la solution 1.Répartir la charge de façon équilibrée 2.Résister aux pannes 3.Spécialiser des serveurs 4.Faciliter l'exploitation 5.Répartition entre serveurs d'un même LAN ou entre des datacenters 6.Répartir les requêtes HTTP ou les sessions 11/74

12 Rappel sur les protocoles réseaux TCP : protocole de niveau 4 TCP possède des numéros de séquence TCP réémet les paquets perdus TCP met de l'ordre à l'arrivée HTTP : protocole de niveau 5 sans état Le besoin de gérer les sessions conduit à construire la notion d'état au niveau applicatif 12/74

13 Où sont stockés ces sessions http? Coté client Cookie : dans le navigateur du client Dans la page HTML Coté serveur Sur le serveur dans un fichier Dans un système de gestion de mémoire cache Dans la base de données 13/74

14 Echanger l'id de session Avec la méthode GET, dans l'url : sessionid=37af3ee56785acd Avec la méthode POST, dans un formulaire en tant que champ caché : <input type="hidden" name="sessionid" value="37af3ee56785acd"> En utilisant un cookie (RFC 2109) dans le header HTTP 14/74

15 Répartition de charge de niveau DNS DNS Round Robin (DNS RR) {S1, S2, S3}, {S3, S1, S2}, {S2, S3, S1} pas de gestion de contexte sessions non gérées par les frontaux pas de gestion des pannes données erronées en cache DNS pas de mesures de charges serveurs pas d'aiguillage en fonction des charges Solution : répartir la charge au niveau TCP/IP 15/74

16 Configuration réseau Schéma de principe identique pour les répartitions des niveaux 4 et 7 16/74

17 Configuration réseau Plusieurs Datacenter 17/74

18 Configuration réseau Plusieurs Datacenter Single Point of Failure 18/74

19 Tolérance de panne 19/74

20 Tolérance de panne SPOF 20/74

21 Tolérance de panne 21/74

22 Load balancing en interne 22/74

23 Répartition de charge de niveau 4 Round-robin Weighed round-robin Least-connection Weighed least-connection Priority activation IP source Aléatoire Objectif : 30% de charge par serveur 23/74

24 Répartition de charge de niveau 7 Affinité de serveurs cookie sur serveur répartition par URI (URL + param) expression régulière / Hachage Terminer la session SSL Performances 1000 fois inférieures / niveau 4 24/74

25 Gestion des sessions sans affinité de serveur Cookies Partage de contexte en cache global non conservé sur le serveur par exemple memcached, redis Partage de contexte coté serveur données conservées en base de données 25/74

26 Gestion des sessions Session en cookie : - pas d'affinité de serveur, - un peu d'overhead réseau, - points de sécurité à traiter Session en mémoire : - requiert l'affinité de serveur, - rapide mais contraignant Session en mémoire distribuée : - pas d'affinité de serveur, - bonnes performances Session en base : - pas d'affinité de serveur, - petit impact en perfs sur l'accès 26/74

27 Tolérance de panne Surveillance des équipements Maintient de la priorité de la correction Tester les équipements de remplacement Optimiser le ratio coût de la redondance / coût de la panne 27/74

28 Répartion de charge pour les traitements asynchrones MapReduce et Hadoop Décomposition des tâches : map Consolidation des résultats : reduce Exemple : compter les occurrences d'un mot dans un fichier Autre exemple : création de l'index de Google 28/74

29 Les stockages de données 29/74

30 Les stockages de données Gestion ACID pour données critiques Réplication pour les données en lecture seule Consolidation des données en écriture seule Partitionnement associé à un datawarehouse 30/74

31 La gestion des données des critiques Transaction début fin (commit - rollback) Propriétés ACID Atomicité une transaction en tout ou rien Cohérence respect des contraintes Isolation transactions simultanées Durabilité résistance aux pannes Pseudo transactionnel Difficulté : combiner prop. ACID et élasticité 31/74

32 Le cluster Commit à deux phases Coordinator R1 R2 Discuter l'argumentaire de la page suivante : 32/74

33 Élasticité de la lecture M est une base Maître E sont des bases Esclaves, en lecture seule 33/74

34 Élasticité de la lecture M est une base Maître E sont des bases Esclaves en lecture seule Réplication en cascade 34/74

35 Écriture d'un fichier de log 35/74

36 Partitionnement des données Une entité partitionnée est gérée par un unique serveur Les entités liées sont sur le même serveur Certaines entités de référence peuvent être répliquées sur différents serveurs Quelle logique de répartition? Segmentation définie déconseillée Arbitraire table d'allocation (entité, serveur) 36/74

37 Requêtes transverses Requêtes adressées en parallèle à tous les serveurs et consolider les réponses Création d'une base consolidée permanente (datawarehouse) Ne concerne qu'une partie de l'information Gros volume / taux d'accès faible Lieu naturel de la table d'allocation 37/74

38 Partitionnement par user L'application ne connaît pas le partitionnement 38/74

39 Partitionnement par user L'application connaît le partitionnement 39/74

40 Les caches 40/74

41 Le cache Principes : recopier les données de la source dans une zone d'accès plus rapide : le cache Navigateur, proxy, reverse proxy, serveur cache Compression des données multiplier par 100 à la capacité d'accueil Deux modes Pull : le cache va chercher les données (passif) Push : la source pousse les données (actif) 41/74

42 Cache en mode pull 42/74

43 Cache en mode pull time to live TTL : une durée de vie est attribuée aux données la durée de vie peut être : illimitée unique spécifiée par le fournisseur fonctionnement Most Recently Used (MRU) fonctionnement Most Frequently Used (MFU) 43/74

44 Le cache HTTP Distribution HTTP Accélération HTTP la durée de vie est attribuée par le producteur dans l'entête HTTP pages statiques, css, javascript images, pdf formats d'images intermédiaires zoom d'images résultats de recherche fragments de page 44/74

45 Le cache HTTP par fragment Durée de vie attribuée au fragment actualité rafraîchie tous les 1/4 d'heure pied de page toutes les 24 heures Norme Edge Side Incluce (ESI) définie par un groupe d'entreprise (Akamai, Oracle, ) soumise au W3C <esi:include src=' agrégation coté client : iframes, javascript, Ajax, 45/74

46 Le cache HTTP par fragment 46/74

47 Cache en mode push 47/74

48 Cache de données données en RAM 50 Go RAM Memcached 1 million de membres 50 Ko de données par membre cache distribué, objet 1o à 1Mo correspondance clé-valeur utilisée par Facebook : 800 serveurs, 28 To, requêtes/s/serveur Redis (GitHub, Groupon, Stack Overflow,...) 48/74