Cloud computing 2012-13 laurent@wargon.org 1/71
Architectures pour le Cloud 2/71
Architectures pour le Cloud Introduction Les traitements Les stockages de données Les caches Des exemples 3/71
Introduction 4/71
Montée en charge Peak Traffic Approximately 90K concurrent visitors Publication de l'annonce de Hits par minutes l'iphone5 sur 500K le blog www.engadget.com 59 serveurs Web Hits max = 20 x Hits initial 0K 11h 5/71 12h 13h 12 septembre 2012 14h
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/71
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/71
Capacité d'accueil en fonction du nombre de serveurs 8/71
Les traitements 9/71
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/71
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 entres des datacenters 6.Répartir les requêtes HTTP ou les sessions 11/71
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 - session non gérée 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 12/71
Configuration réseau Schéma de principe identique pour les répartitions des niveaux 4 et 7 13/71
Configuration réseau Plusieurs Datacenter 14/71
Configuration réseau Plusieurs Datacenter Single Point of Failure 15/71
Tolérance de panne 16/71
Tolérance de panne SPOF 17/71
Tolérance de panne 18/71
Load balancing en interne 19/71
Rappel sur les protocoles réseaux TCP : protocole de niveau 4 message TCP décomposé en paquets IP 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 20/71
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 21/71
Répartition de charge de niveau 7 Aiguillage suivant : un cookie contient l'identification de session Affinité de serveurs l'uri (URL + paramètres) Expression régulière Hachage Terminer la session SSL au niveau 4 Performances 1000 fois inférieurs / niveau 4 22/71
Gestion des sessions sans affinité de serveur Cookies Partage de contexte coté serveur données conservées sur le navigateur données conservées en base de données Partage de contexte en cache global par exemple memcached, redis 23/71
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 24/71
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 25/71
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 26/71
Les stockages de données 27/71
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 Partionnement associé à un datawarehouse 28/71
La gestion 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é 29/71
Le cluster Commit à deux phases Coordinator R1 R2 Discuter l'argumentaire de la page suivante : http://blog.developpez.com/sqlpro/p10387/langage-sql-norme/le_mythe_du_commit_a_deux_phases 30/71
Élasticité de la lecture M est une base Maître E sont des bases Esclaves, en lecture seule 31/71
Élasticité de la lecture M est une base Maître E sont des bases Esclaves en lecture seule Réplication en cascade 32/71
Écriture d'un fichier de log 33/71
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é Arbitraire table d'allocation (entité, serveur) 34/71
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 35/71
Partitionnement par user L'application ne connaît pas le partitionnement 36/71
Partitionnement par user L'application connaît le partitionnement 37/71
Les caches 38/71
Le cache Principes : recopier les données de la source dans une zone d'accès plus rapide : le cache Navigateur, proxy, reverse proxy Compression des données multiplier par 100 à 1 000 la capacité d'accueil Deux modes Pull : le cache va chercher les données (passif) Push : la source pousse les données (actif) 39/71
Cache en mode pull 40/71
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) 41/71
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 42/71
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='http://www.site.com/fragment01'/> agrégation coté client : iframes, javascript, Ajax, 43/71
Le cache HTTP par fragment 44/71
Cache en mode push 45/71
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é par Facebook : 800 serveurs, 28 To, 200 000 requête/s/serveur Redis (GitHub, Groupon, Stack Overflow,...) 46/71
Les Content Delivery Network (CDN) Paris Californie : + 45 ms Paris Sidney : + 85 ms Amazon a estimé que 100 millisecondes de temps de chargement supplémentaires entraînent 1% de ventes en moins Fabriquer des noeuds où les contenus statiques sont répliqués au plus proche de l'internaute 47/71
Les Content Delivery Network (CDN) 48/71
Les métriques des CDN Géographique GeoDNS Réseau DNS Anycast Calculée en temps réel Pair à pair 49/71
CDN : Métrique géographique GeoDNS Base de données géographique des adresses IP (produits de la société maxmind : GeoIP) Configuration particulière du DNS Faible coût 50/71
Adresse anycast Adresse IP Unicast Adresse IP Anycast 51/71
CDN : Métrique réseau Le DNS possède une adresse anycast et renvoie unicast d'un serveur HTTP proche Le DNS possède une adresse quelconque et renvoie une adresse anycast de serveur HTTP qui répond par un redirect HTTP vers un serveur unicast proche pour les fichiers de taille imporante. 52/71
Système à CDN Multiples Base de données Cedexis : collecte de données (1,3 milliard de mesures / jour) des éditeurs web livrent des pages qui contiennent des sondes pour faire des mesures sur les Cloud et CDN Utilisation de mesures temps réel (cdntech.com) 53/71
Évaluer les temps de réponse www.cedexis.com/fr/radar/speedtest.html#cdn 1) Temps de connexion http = temps de résolution dns + temps de connexion tcp (petit objet) 2) Temps de réponse http = utilise la connexion tcp ouverte par la première mesure (petit objet) 3) Débit HTTP = utilise la connexion tcp déjà ouverte (gros objet) 54/71
Système à CDN Multiples l'url de la ressource est : cdn.mon_domaine.org c'est un CNAME vers 789456.cedexis.com Suivant les mesures collectées, ce nom de domaine sera : soit un CNAME vers 132456.akamay.com ou Soit un CNAME vers 456963.cdn77.net Le TTL est paramétrable (20s) 55/71
Système à CDN Multiples Netflix (30 % du trafic descendant aux US) : changement de CDN si débit < 100Kbps Utilisation de plusieurs CDN en simultané pour le streaming vidéo groupe de travail CDN Interconnection de l'ietf plusieurs RFC 56/71
Système pair-à-pair Chaque client est aussi un serveur Fichiers, Flux (streaming), calcul réparti, service (téléphonie, bureau distant, ) Élasticité Architectures centralisée décentralisée : recherche exponentielle décentralisée structuré : recherche logarithmique 57/71
WebRTC Web Real-Time Communication Communications temps réel entre navigateurs : voix sur IP, visioconférence, pair-à-pair API javascript et HTML5 58 % des navigateurs projet porté par Google, Mozilla and Opera Depuis 2011 : API (W3C), protocole (IETF) 58/71
CDN pair à pair PeerCDN (béta) Réduction de bande passante Javascript Plus de visiteurs plus d'hébergeur Utilisation de WebRTC Fonctionne avec les autres CDN Sécurisé, Fiable 59/71
Des exemples 60/71
Une configuration CDN Plateforme HTTP : serveur PXE, syslog, déploiement, monitoring,... Distribution HTTP (Source) : nginx Accélération HTTP (Edge) : cartes 10Gbps, disques SSD, XFS, RAID0, nginx, syslog distant et centralisé (réduction des I/O locales et gestion des statistiques) http://francois.aichelbaum.com/creer-un-caching-http-facon-cdn/ 61/71
Une configuration CDN Edge Source Edge User Load Balencer Edge Source Origin Edge Origin http://francois.aichelbaum.com/creer-un-caching-http-facon-cdn/ 62/71
Architecture type Facebook 63/71
Sport 24 CMS ez Publish contexte de session en base de données pas d'affinité de serveurs media conservé en base de données agrégation coté client avec du javascript match en temps réel sont rechargés par javascript sans recharger la page coté serveur SSI Server Side Include d'apache 64/71
Sport 24 cache squid en frontal (2 000 pages/seconde) génération de pages statiques : création des articles dans le back-office script de génération des pages statiques diffusion vers les frontaux NFS ou RSync 65/71
Sport 24 66/71
Sport 24 67/71
01 Informatique 68/71
Source Livre Blanc Plateformes web Hautes Performances Principes d'architecture et outils open source Société Smile 69/71
Des questions? 70/71
Montée en charge Publication de l'annonce de l'iphone5 sur le blog gdgt Peak Traffic Approximately 90K concurrent visitors Hits par minutes 500K 59 Web Server 5 load balencers Proposer une architecture 0K 11h 71/71 12h 13h 12 septembre 2012 14h