opérations sur les machines virtuellesblog.wargon.org/wp-content/uploads/cours/2016-2017/... ·...

Universitéde Marne-la-Vallée 53/59 Laurent Wargon

Opérations sur les machines virtuelles

● Allocations dynamiques des ressources :RAM, CPU, Disques, Bande Passante

● Installation, sauvegarde, déplacement à chaud● Répartition des machines virtuelles (VM) sur les

machines physiques pour optimiser les charges systèmes et la consommation d’énergie

● Sécurité, environnement de test● Livraison d'applicatif (appliance virtuelle)


Virtualisation

Société Produit

VMWare VMWare ESX

Citrix System Xen

Microsoft Microsoft Hyper-V

Contributeurs KVM

Oracle Virtualbox


Webservices

● Échange de données entre applications et systèmes hétérogènes

● Exemple– XML-RPC (XML - Remote Procedure Call) – SOAP (Simple Object Access Protocol)– REST (REpresentational State Transfer)


Webservices

RessourcesCPURAM

DisquesBande-passante

Nouvelle MachineHumain

Navigateur

MachineScript

Webservices

Cas de pilotage des machines virtuelles


L'automatisme

Écrire un pseudo code d'allocation des ressources qui respecte les caractéristiques du NIST


Architectures pour le Cloud


Architectures pour le Cloud

● Introduction● Les traitements● Les stockages de données● Les caches● Des exemples


Introduction


Montée en charge

Hits par minutes

11h 12h 13h 14h12 septembre 2012

500K

0K

Peak Traffic – Approximately 90K concurrent visitorsPublication de l'annonce de l'iphone5 sur le blogwww.engadget.com

59 serveurs Web

Hits max = 20 x Hits initial

http://www.engadget.com/


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


Comment faire ?

● la capacité des serveurs est limitée :– Gandi : 16 cœurs, 24Go RAM, 8 x 2To 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


Capacité d'accueil en fonction du nombre de serveurs


Les traitements


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



● Extensibilité cellulaire



● Extensibilité fonctionnelle

Application Web




Serveur Web Base de données




Accélérateur Web Base de donnéesServeur Web



● Extensibilité horizontale

AccélérateurWeb

Base de données

ApplicationWeb

Base de données

ServeurWeb

ServeurWeb

AccélérateurWeb

ApplicationWeb




AccélérateurWeb

Base de données

Accès aux données

Base de données

ApplicationWeb

ApplicationWeb

AccélérateurWeb

ApplicationWeb

Load balencer




AccélérateurWeb

Base de données

Accès aux données

Base de données

ApplicationWeb

ApplicationWeb

AccélérateurWeb

ApplicationWeb

Load balencerLoad balencer

Accès aux données


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


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


Où sont 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● Sur le réseau : http ou https, visible ou pas


Échanger l'ID de session

● Avec la méthode GET, dans l'url : http://www.example.com/shoppingCart?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 HTTPhttp://igm.univ-mlv.fr/~chilowi/teaching/subjects/java/net/web/http.htmlhttp://www.cnil.fr/vos-obligations/sites-web-cookies-et-autres-traceurs/que-dit-la-loi/

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


● 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


AccélérateurWeb

Base de données

Accès aux données

Base de données

ApplicationWeb

ApplicationWeb

AccélérateurWeb

ApplicationWeb

Loadbalencer

Loadbalencer

Fin de session SSL Fin de session SSL

Loadbalencer

Loadbalencer

Accès aux données

Gestion des sessions

Session en cookie : - pas d'affinité de serveur,- un peu d'overhead réseau,- points de sécurité à traiter

Session en base :- pas d'affinité de serveur,- petit impact en perfs sur l'accès

Session en mémoire distribuée :- pas d'affinité de serveur, - bonnes performances

Session en mémoire :- requiert l'affinité de serveur,- rapide mais contraignant


Configuration réseau

Plusieurs Datacenter


Tolérance de panne


Tolérance de panne

SPOF


Tolérance de panne


Load balancing en interne

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

Utilisé sur différents réseaux et prestataires


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


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


Les stockages de données


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


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é


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


Élasticité de la lecture

● M est une base Maître● E sont des bases Esclaves, en lecture seule


Élasticité de la lecture

● M est une base Maître● E sont des bases Esclaves en lecture seule● Réplication en cascade


Écriture d'un fichier de log


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)


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


Répartition Load Balencer

l'application neconnaît pas lepartitionnement


Répartition frontaux web

l'application connaît lepartitionnement


NoSQL

● Not only SQL● Lecture fréquente / écriture non fréquente ● Performance en lecture● Répartition de charge● Peu coûteux● Pas de propriétés ACID● BigTable (google), Dynamo (Amazon), Hbase

(Facebook), MongoDB (SourceForge), Redis


Les caches


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 à 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)


Cache en mode pull


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)


Cache en mode push


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


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,

http://www.site.com/fragment01'/


Le cache HTTP par fragment


Cache de données

● données en RAM– 1 million de membres– 50 Ko de données par membre

● Memcached– cache distribué, objet 1o à 1Mo– correspondance clé-valeur– utilisée par Facebook (2008)

800 serveurs, 28 To, 200 000 requêtes/s/serveur● Redis (GitHub, Groupon, Stack Overflow, ...)

50 Go RAM


Les Content Delivery Network (CDN)

● Paris – Californie : + 45 msParis – Sidney : + 85 ms

● Amazon : 100 ms de temps de chargement supplémentaires → 1% de ventes en moins

● Poids moyen des pages d'accueil :

2000 : moins de 100 Ko

2012 : 1 à 4 Mo ● Page médiane en 2012 :77 requêtes et 6,5s

http://www.cdn-tech.com/IMG/pdf/cdn-tech-ecritel-livreblanc-2012.pdf



● Fabriquer des nœuds où les contenus statiques sont répliqués au plus proche de l'internaute

Pour faire un CDN, il faut :

Serveurs d'origine

Nœuds où les contenus sont répliqués

Un mécanisme de routage


Les métriques des CDN

● Géographique → GeoDNS● Réseau → DNS Anycast● Calculée en temps réel →

utilisation de plusieurs CDN


CDN : Métrique géographique GeoDNS

● Base de données géographiquedes adresses IP (produits de la société maxmind : GeoIP)

● Configuration particulière du DNS● Faible coût● http://phix.me/geodns/


Adresse anycast (RFC 4786)

Adresse IP Unicast Adresse IP Anycast

opérations sur les machines virtuellesblog.wargon.org/wp-content/uploads/cours/2016-2017/... ·...

Documents