DESCRIPTION DES GENERALITES SUR LE CLOUD ET LA VIRTUALISATION

## Objectifs et prérequis **Objectifs** : À la fin de ce chapitre, l’élève sera capable de : 1. Définir le cloud computing et en citer les caractéristiques essentielles selon le modèle NIST. 2. Distinguer les trois modèles de service (IaaS, PaaS, SaaS) et les quatre modèles de déploiement (public, privé, hybride, communauté). 3. Expliquer les avantages et les limites du cloud pour une entreprise ou un établissement scolaire. 4. Définir la virtualisation, distinguer un hyperviseur de type 1 et de type 2, et citer des exemples concrets. 5. Décrire le fonctionnement d’une machine virtuelle (VM) et d’un conteneur, et comparer leurs points forts et leurs faiblesses. 6. Réaliser des calculs simples liés au coût d’utilisation de ressources cloud et au taux de consolidation d’une infrastructure virtuelle. 7. Identifier les erreurs fréquentes lorsqu’on aborde ces notions et savoir les éviter. **Prérequis** : - Notions de base sur les matériels informatiques (processeur, mémoire vive, stockage). - Connaissances élémentaires des systèmes d’exploitation (rôle du noyau, gestion des processus). - Notions de réseaux (adresse IP, bande passante, protocole TCP/IP). - Maîtrise des opérations arithmétiques simples et du pourcentage. > **À retenir** : Le cloud computing repose sur la fourniture de services informatiques sous forme de ressources élastiques, mesurables et accessibles via Internet. --- ## Introduction contextualisée Depuis le début des années 2000, la croissance exponentielle du volume de données et la nécessité d’assurer une disponibilité constante des applications ont poussé les organisations à repenser leurs infrastructures informatiques. L’acquisition traditionnelle de serveurs physiques, coûteuse et peu flexible, ne permettait plus de répondre rapidement aux variations de charge (pics d’utilisation, déploiement de nouvelles applications, tests et développements). Le **cloud computing** apparaît alors comme une réponse à ces contraintes : il propose de louer, à la demande, des capacités de calcul, de stockage et de réseau auprès de fournisseurs spécialisés, en ne payant que ce qui est réellement consommé. Cette logique de « paiement à l’usage » s’accompagne d’une **virtualisation** poussée du matériel, qui permet de partager un même serveur physique entre plusieurs environnements logiques isolés. Dans le contexte camerounais, où les établissements scolaires et les petites entreprises doivent souvent faire face à des budgets limités tout en devant garantir un accès fiable aux ressources numériques, comprendre les mécanismes du cloud et de la virtualisation devient indispensable. Ce chapitre vise donc à fournir les bases théoriques et pratiques permettant à l’élève d’analyser, de choisir et d’évaluer des solutions cloud ou virtuelles adaptées à des scénarios réels. > **À retenir** : La virtualisation est le socle technique qui rend possible l’élasticité et le partage des ressources au cœur du cloud computing. --- ## I. Leçon 27 : Initiation au Cloud computing ### A. Définition du Cloud computing Le **cloud computing** (informatique en nuage) est un modèle permettant un accès ubiquitaire, pratique et à la demande à un ensemble partagé de ressources informatiques configurables (serveurs, stockage, réseaux, applications, services) pouvant être rapidement provisionnées et libérées avec un minimum d’effort de gestion ou d’interaction avec le fournisseur de service. Cette définition provient du **National Institute of Standards and Technology (NIST)**, publiée en 2011. > **À retenir** : Selon le NIST, le cloud computing se caractérise par cinq caractéristiques essentielles, trois modèles de service et quatre modèles de déploiement. ### B. Caractéristiques essentielles (modèle NIST) 1. **Self‑service à la demande** : l’utilisateur peut provisionner unilatéralement des capacités de calcul (ex. temps serveur, stockage) selon ses besoins, sans nécessiter l’intervention humaine du fournisseur. 2. **Large accès réseau** : les capacités sont disponibles sur le réseau et accessibles via des mécanismes standards (ex. navigateur web, API) qui favorisent l’utilisation par des plateformes hétérogènes (mobile, tablette, PC). 3. **Mise en commun des ressources** : les ressources du fournisseur sont mutualisées pour servir plusieurs consommateurs à l’aide d’un modèle multi‑locataire, avec une affectation dynamique selon la demande. 4. **Élasticité rapide** : les capacités peuvent être rapidement augmentées ou diminuées, souvent de façon automatique, pour suivre l’évolution de la charge. 5. **Mesure du service** : l’utilisation des ressources est monitorée, contrôlée et facturée selon un modèle de mesure (ex. tarif horaire, volume de stockage transféré). > **À retenir** : L’élasticité rapide et la mesure du service sont les deux propriétés qui différencient le cloud d’un simple hébergement traditionnel. ### C. Modèles de service | Modèle | Description | Exemples courants | |--------|-------------|-------------------| | **IaaS** (Infrastructure as a Service) | Fourniture de ressources informatiques de base : machines virtuelles, stockage, réseaux. L’utilisateur gère le système d’exploitation, les middleware et les applications. | Amazon EC2, Microsoft Azure Virtual Machines, Google Compute Engine | | **PaaS** (Platform as a Service) | Fourniture d’une plateforme permettant de développer, tester et déployer des applications sans gérer l’infrastructure sous‑jacente (système d’exploitation, serveur, stockage). | Google App Engine, Microsoft Azure App Service, Heroku | | **SaaS** (Software as a Service) | Fourniture d’une application logicielle complète, accessible via un navigateur ou un client léger. L’utilisateur ne gère rien au niveau de l’infrastructure ou de la plateforme. | Google Workspace, Microsoft 365, Salesforce | > **À retenir** : Dans le modèle IaaS, le consommateur possède le plus de contrôle ; dans le modèle SaaS, il en possède le moins. ### D. Modèles de déploiement | Modèle | Description | Cas d’usage typique | |--------|-------------|---------------------| | **Cloud public** | Ressources mises à disposition du grand public ou d’un large groupe d’industries via Internet. | Start‑up souhaitant tester rapidement une application. | | **Cloud privé** | Infrastructure dédiée à une seule organisation, pouvant être située sur site ou hébergée par un tiers. | Banque nécessitant un contrôle strict de la sécurité des données. | | **Cloud hybride** | Combinaison d’un cloud privé et d’un ou plusieurs clouds publics, avec une orchestration permettant la portabilité des données et des applications. | Entreprise qui garde ses données sensibles en privé tout en utilisant le public pour le débordement de charge. | | **Cloud communautaire** | Infrastructure partagée entre plusieurs organisations ayant des préoccupations communes (sécurité, juridiction, politique). | Consortium d’universités partageant une plateforme de recherche. | > **À retenir** : Le choix du modèle de déploiement dépend principalement des exigences de sécurité, de conformité et de contrôle souhaité par l’organisation. ### E. Avantages et inconvénients du cloud **Avantages** - **Réduction des coûts d’investissement (CAPEX)** : pas besoin d’acheter du matériel coûteux ; on passe à un modèle OPEX (dépenses opérationnelles). - **Scalabilité** : capacité à augmenter ou diminuer les ressources en quelques minutes. - **Disponibilité et résilience** : les fournisseurs offrent souvent des SLA (Service Level Agreement) de 99,9 % voire plus, avec une répartition géographique des data‑centers. - **Mise à jour automatique** : le fournisseur gère les correctifs de sécurité et les mises à jour de l’infrastructure. - **Accessibilité géographique** : les utilisateurs peuvent accéder aux services depuis n’importe quel endroit disposant d’une connexion Internet. **Inconvénients** - **Dépendance à la connectivité** : une panne Internet rend les services inaccessibles. - **Sécurité et confidentialité** : les données sont stockées chez un tiers ; il faut faire confiance aux mesures de protection du fournisseur. - **Coût imprévisible** : sans une bonne gouvernance, la facturation à l’usage peut dépasser le budget prévu (ex. instances laissées allumées). - **Limites de personnalisation** : certaines configurations très spécifiques peuvent être difficiles à obtenir en IaaS/PaaS. - **Verrouillage fournisseur (vendor lock‑in)** : migrer d’un cloud à un autre peut être complexe et coûteux. > **À retenir** : Une bonne gouvernance du cloud (politiques d’usage, surveillance des coûts, chiffrement des données) permet de maximiser les avantages tout en maîtrisant les risques. ### F. Exemples concrets de fournisseurs cloud - **Amazon Web Services (AWS)** : lancé en 2006, propose plus de 200 services couvrant IaaS, PaaS et SaaS. - **Microsoft Azure** : lancé en 2010, fortement intégré aux produits Microsoft (Windows Server, SQL Server, Office 365). - **Google Cloud Platform (GCP)** : lancé en 2008, connu pour ses capacités d’analyse de données (BigQuery) et d’intelligence artificielle (TensorFlow). - **OpenStack** : plateforme open‑source permettant de construire un cloud privé ou hybride ; utilisée par de nombreux opérateurs télécoms et établissements de recherche. > **À retenir** : Le choix d’un fournisseur dépend souvent de l’écosystème logiciel déjà utilisé par l’organisation et des certifications de sécurité (ISO 27001, SOC 2, PCI‑DSS) qu’il possède. ### G. Démonstration : calcul du coût d’utilisation d’une machine virtuelle Supposons que nous voulons estimer le coût mensuel d’exécution d’une instance **t2.micro** sur AWS : - Tarif horaire (région : Europe (Francfort)) : **0,0116 $ / h**. - Durée d’utilisation prévue : **100 heures** dans le mois (ex. serveur de développement allumé seulement en journée). Le coût total s’obtient par la formule : \[ \text{Coût} = \text{Tarif horaire} \times \text{Heures utilisées} \] En remplaçant : \[ \text{Coût} = 0{,}0116 \,\$/\text{h} \times 100 \,\text{h} = 1{,}16 \,\$ \] > **À retenir** : Même une petite instance peut générer un coût non négligeable si elle reste allumée 24 h/24 ; il convient donc d’arrêter les ressources lorsqu’elles ne sont plus nécessaires. ### H. Deux exemples entièrement résolus #### Exemple 1 – Coût d’un stockage S3 Un établissement souhaite stocker **50 Go** de sauvegardes hebdomadaires sur Amazon S3 (région : US East (N. Virginia)). Le tarif de stockage standard est **0,023 $ / Go‑mois**. Calcul : \[ \text{Coût mensuel} = 50 \,\text{Go} \times 0{,}023 \,\$/\text{Go‑mois} = 1{,}15 \,\$ \] Si les données sont conservées pendant **6 mois**, le coût total sera : \[ 1{,}15 \,\$ \times 6 = 6{,}90 \,\$ \] #### Exemple 2 – Comparaison IaaS vs achat de serveur Une petite entreprise envisage d’acquérir un serveur physique coûtant **1 200 €** (hors taxes) avec une durée de vie estimée à **3 ans**. Le serveur consomme en moyenne **150 W** et le coût de l’électricité est **0,15 €/kWh**. - Consommation annuelle : \(150 \,\text{W} \times 24 \,\text{h/j} \times 365 \,\text{j/an} = 1{,}314 \,\text{kWh/an}\). - Coût énergétique annuel : \(1{,}314 \,\text{kWh} \times 0{,}15 \,\€/\text{kWh} = 197{,}10 \,\€/\text{an}\). - Sur 3 ans : \(3 \times 197{,}10 = 591{,}30 \,\€\). Coût total de possession (TCO) sur 3 ans : \[ 1{,}200 \,\€ + 591{,}30 \,\€ = 1{,}791{,}30 \,\€ \] Supposons maintenant que l’entreprise loue une instance équivalente sur AWS (t2.medium, 2 vCPU, 4 Go RAM) au tarif **0,0416 $ / h** (≈ 0,038 €/h après conversion 1 $ ≈ 0,92 €). - Heures utilisées en 3 ans (24 h/365 j) : \(3 \times 365 \times 24 = 26{,}280 \,\text{h}\). - Coût location : \(26{,}280 \,\text{h} \times 0{,}038 \,\€/\text{h} = 998{,}64 \,\€\). Dans ce scénario simplifié, la location sur 3 ans revient moins chère que l’achat (998,64 € vs 1 791,30 €), sans compter les frais de maintenance, de renouvellement matériel et de gestion des licences logicielles. > **À retenir** : Le modèle économique du cloud peut être avantageux pour des charges de travail variables ou à durée limitée, tandis que l’achat de matériel peut rester pertinent pour des charges stables et prévisibles sur le long terme. --- ## II. Leçon 28 : Notions de base sur la virtualisation ### A. Définition de la virtualisation La **virtualisation** est une technique qui permet de créer une abstraction du matériel physique (processeur, mémoire, stockage, périphériques d’entrée/sortie) afin d’exécuter plusieurs environnements isolés, appelés **machines virtuelles (VM)**, sur un même serveur physique. Chaque VM possède son propre système d’exploitation invité et croit disposer d’un matériel dédié, alors qu’en réalité les ressources sont partagées et allouées dynamiquement par un **hyperviseur**. > **À retenir** : La virtualisation découpe le logiciel du matériel, permettant une meilleure utilisation des ressources et une isolation des charges de travail. ### B. Hyperviseur : type 1 et type 2 | Type | Description | Exemples | |------|-------------|----------| | **Hyperviseur de type 1 (bare‑metal)** | S’exécute directement sur le matériel hôte, sans système d’exploitation intermédiaire. Il gère le matériel et crée les VM. | VMware ESXi, Microsoft Hyper‑V (mode serveur), KVM (Kernel‑based Virtual Machine), Xen | | **Hyperviseur de type 2 (hébergé)** | S’exécute comme une application au sein d’un système d’exploitation hôte conventionnel. Il repose sur le noyau du système hôte pour accéder au matériel. | Oracle VirtualBox, VMware Workstation, Parallels Desktop (macOS) | > **À retenir** : Les hyperviseurs de type 1 offrent généralement de meilleures performances et sont privilégiés en production, tandis que ceux de type 2 sont plus adaptés aux environnements de test, de développement ou d’utilisation personnelle. ### C. Machine virtuelle (VM) : allocation de ressources Une VM se voit attribuer une partie des ressources physiques : - **CPU** : nombre de cœurs virtuels (vCPU) ou pourcentage de temps CPU. - **Mémoire vive (RAM)** : quantité de mémoire allouée, généralement en mégaoctets (Mo) ou gigaoctets (Go). - **Stockage** : espace disque virtuel (souvent sous forme de fichier VMDK, VHD, QCOW2). - **Réseau** : carte réseau virtuelle connectée à un commutateur virtuel ou à un pont physique. L’hyperviseur assure l’isolation : les processus d’une VM ne peuvent pas accéder directement à la mémoire ou au CPU d’une autre VM, sauf si des mécanismes de partage explicite sont configurés (ex. dossiers partagés). > **À retenir** : L’allocation de ressources doit être réalisée avec prudence ; une sur‑allocation (overcommit) peut conduire à une dégradation des performances si la demande réelle dépasse la capacité physique. ### D. Conteneurs vs machines virtuelles | Aspect | Machine virtuelle | Conteneur (ex. Docker) | |--------|-------------------|------------------------| | Niveau d’abstraction | Matériel complet (CPU, RAM, périphériques) | Niveau du système d’exploitation (noyau partagé) | | Système d’exploitation invité | Complet (Linux, Windows, etc.) | Partage le noyau de l’hôte ; uniquement les bibliothèques et l’application | | Démarrage | Secondes à minutes (boot du système d’exploitation) | Millisecondes | | Overhead | Plus important (émulation du matériel) | Très faible | | Isolation | Forte (niveau matériel) | Bonne, mais dépend du noyau et des namespaces/cgroups | | Cas d’usage typique | Applications nécessitant un OS complet, légacies, tests de différents kernels | Micro‑services, déploiement continu, densité élevée d’instances | > **À retenir** : Les conteneurs offrent une densité d’exécution beaucoup plus élevée que les VM, mais ils ne remplacent pas la virtualisation lorsqu’une isolation matérielle forte ou un système d’exploitation différent est requis. ### E. Avantages de la virtualisation 1. **Consolidation des serveurs** : plusieurs VM peuvent tourner sur un même serveur physique, réduisant le nombre de machines nécessaires. 2. **Flexibilité et agilité** : provisionnement rapide d’une VM (clonage, modèle, snapshot). 3. **Isolation et sécurité** : les pannes ou les infections d’une VM n’affectent pas les autres (sauf vulnérabilité de l’hyperviseur). 4. **Gestion des sauvegardes et reprise après sinistre** : snapshots et clonage facilitent les sauvegardes à chaud et la restauration. 5. **Migration à chaud (live migration)** : possibilité de déplacer une VM en cours d’exécution d’un hôte physique à un autre sans interruption de service. 6. **Réduction de la consommation énergétique** : moins de serveurs physiques = moins d’alimentation et de refroidissement. ### F. Inconvénients de la virtualisation - **Overhead de l’hyperviseur** : consommation de CPU et de mémoire pour la gestion des VM (typiquement 5‑15 %). - **Complexité de gestion** : nécessité d’outils d’orchestration (vCenter, SCVMM, OpenStack) et de compétences spécialisées. - **Risque de point unique de défaillance** : si l’hyperviseur tombe, toutes les VM de l’hôte sont affectées. - **Licences logicielles** : certains éditeurs imposent des licences par cœur physique ou par VM, ce qui peut augmenter les coûts. - **Performance E/S** : l’accès au disque ou au réseau peut être limité par la couche d’abstraction, nécessitant des optimisations (paravirtualisation, SR‑IOV). > **À retenir** : Une bonne planification de la capacité, un monitoring continu et l’utilisation de fonctionnalités avancées (comme le stockage en réseau SAN/NAS ou les cartes réseau dédiées) permettent de minimiser les inconvénients. ### G. Démonstration : calcul du taux de consolidation Considérons un serveur physique doté de : - **32 cœurs CPU** (threads logiques). - **256 Go de RAM**. Chaque VM que nous souhaitons déployer nécessite : - **2 vCPU**. - **8 Go de RAM**. Le nombre maximal de VM que l’on peut placer sans sur‑allocation est déterminé par la ressource la plus limitante : \[ \text{Nb VM}_{\text{CPU}} = \left\lfloor \frac{32}{2} \right\rfloor = 16 \] \[ \text{Nb VM}_{\text{RAM}} = \left\lfloor \frac{256}{8} \right\rfloor = 32 \] Le facteur limitant est le CPU ; donc \[ \boxed{\text{Nb VM}_{\max}=16} \] Le **taux de consolidation** (ratio de machines virtuelles par serveur physique) est donc : \[ \text{Taux de consolidation} = \frac{16}{1} = 16 \] Cela signifie qu’un seul serveur physique peut remplacer seize serveurs dédiés, chacun exécutant une seule charge de travail. > **À retenir** : Le taux de consolidation dépend toujours de la ressource la plus contrainte ; il faut donc analyser simultanément CPU, RAM, stockage et bande passante réseau. ### H. Deux exemples entièrement résolus #### Exemple 1 – Sur‑allocation (overcommit) de CPU Un administrateur décide d’autoriser un **overcommit de 150 %** sur le CPU du serveur précédent (32 cœurs physiques). Cela signifie que le total de vCPU alloués peut atteindre \[ 32 \times 1{,}5 = 48 \text{ vCPU} \] Chaque VM nécessite toujours 2 vCPU. Le nombre maximal de VM devient alors \[ \left\lfloor \frac{48}{2} \right\rfloor = 24 \text{ VM} \] Cependant, la RAM reste la même (256 Go, 8 Go/VM) : \[ \left\lfloor \frac{256}{8} \right\rfloor = 32 \text{ VM (limite RAM)} \] Le facteur limitant redevient le CPU (24 VM). Ainsi, avec un overcommit de 150 %, on peut exécuter **24 VM** sur le même serveur, à condition que l’usage réel du CPU ne dépasse pas fréquemment la capacité physique. > **À retenir** : L’overcommit augmente la densité mais nécessite une surveillance précise de l’utilisation réelle du CPU pour éviter la saturation et la dégradation des performances. #### Exemple 2 – Utilisation effective après allocation dynamique Supposons que nous déployions 20 VM, chacune configurée avec 2 vCPU et 8 Go RAM, sur le même serveur (32 cœurs, 256 Go RAM). - **Allocation théorique** : CPU = 20 × 2 = 40 vCPU (overcommit de 25 %), RAM = 20 × 8 = 160 Go. Après une période d’observation, l’utilisation moyenne mesurée est : - CPU : 18 vCPU utilisés en moyenne. - RAM : 120 Go utilisés en moyenne. Le **taux d’utilisation effective** est donc : \[ \text{CPU}_{\text{util}} = \frac{18}{32} \times 100 \% \approx 56,25 \% \] \[ \text{RAM}_{\text{util}} = \frac{120}{256} \times 100 \% \approx 46,88 \% \] Ces valeurs montrent que, malgré un overcommit théorique, l’usage réel reste bien en dessous des limites physiques, ce qui confirme la sûreté de la configuration. > **À retenir** : Mesurer l’utilisation réelle (via des outils comme `top`, `vmstat`, ou des solutions de monitoring cloud) est essentiel pour valider les décisions d’overcommit et ajuster les allocations. --- ## Synthèse du chapitre - **Cloud computing** : modèle NIST (self‑service, large accès réseau, mise en commun, élasticité rapide, mesure du service). - **Modèles de service** : IaaS (infrastructure), PaaS (plateforme), SaaS (logiciel). - **Modèles de déploiement** : public, privé, hybride, communautaire. - **Avantages** : réduction CAPEX, scalabilité, disponibilité, mises à jour automatiques, accès géographique. - **Inconvénients** : dépendance réseau, sécurité, coût imprévisible, limites de personnalisation, vendor lock‑in. - **Virtualisation** : abstraction du matériel via hyperviseur (type 1 bare‑metal, type 2 hébergé). - **Machine virtuelle** : allocation de vCPU, RAM, stockage, réseau ; isolation forte. - **Conteneurs** : partage du noyau, démarrage rapide, densité élevée, moindre isolation. - **Avantages de la virtualisation** : consolidation, agilité, isolation, sauvegarde simplifiée, migration à chaud, économies d’énergie. - **Inconvénients** : overhead, complexité, point unique de défaillance, licences, performance E/S. - **Calculs clés** : coût cloud = tarif horaire × heures utilisées ; taux de consolidation = min(CPU disponible / vCPU par VM, RAM disponible / RAM par VM) ; overcommit = facteur × ressources physiques. --- ## Glossaire | Terme | Définition | |-------|------------| | **Cloud computing** | Modèle de fourniture de services informatiques (calcul, stockage, réseau) à la demande via Internet, caractérisé par l’auto‑service, l’accès réseau large, la mise en commun des ressources, l’élasticité rapide et la mesure du service. | | **IaaS** | Infrastructure as a Service : fourniture de ressources matérielles virtuelles (VM, stockage, réseau) laissant au consommateur la gestion du système d’exploitation et des applications. | | **PaaS** | Platform as a Service : fourniture d’une plateforme de développement et d’exécution qui masque l’infrastructure sous‑jacente. | | **SaaS** | Software as a Service : fourniture d’une application logicielle complète accessible via un navigateur ou un client léger. | | **Hyperviseur de type 1** | Logiciel de virtualisation qui s’exécute directement sur le matériel hôte sans système d’exploitation intermédiaire (ex. VMware ESXi, KVM). | | **Hyperviseur de type 2** | Logiciel de virtualisation qui s’exécute comme une application au sein d’un système d’exploitation hôte (ex. VirtualBox, VMware Workstation). | | **Machine virtuelle (VM)** | Environnement logiciel isolé qui émule un matériel complet et exécute son propre système d’exploitation invité. | | **Conteneur** | Unité logique d’exécution qui partage le noyau du système hôte et encapsule une application avec ses dépendances (ex. Docker). | | **Overcommit** | Pratique consistant à allouer davantage de ressources virtuelles que de ressources physiques disponibles, en comptant sur une utilisation moyenne inférieure à la capacité totale. | | **Taux de consolidation** | Rapport entre le nombre de machines virtuelles pouvant être exécutées sur un serveur physique et le nombre de serveurs physiques nécessaires sans virtualisation (ex. 16 VM/serveur). | | **Snapshot** | Capture instantanée de l’état d’une VM (disque, mémoire, configuration) permettant une restauration rapide. | | **Live migration** | Déplacement d’une machine virtuelle en cours d’exécution d’un hôte physique à un autre sans interruption de service perceptible pour l’utilisateur. | | **SLA** | Service Level Agreement : contrat définissant le niveau de service garanti (disponibilité, temps de réponse, etc.) entre un fournisseur cloud et son client. | | **Elasticité rapide** | Capacité du cloud à augmenter ou diminuer automatiquement les ressources allouées en fonction de la charge de travail. | | **Mesure du service** | Fonction de suivi et de facturation basée sur l’utilisation réelle des ressources (ex. tarif horaire, volume de données transférées). | --- ## Exercices d'application corrigés ### Exercice 1 – Calcul de coût cloud (niveau facile) Une entreprise loue une instance **t2.small** sur AWS (tarif : 0,0208 $ / h) pendant 150 heures dans un mois. Quel est le coût mensuel ? **Corrigé** \[ \text{Coût} = 0{,}0208 \,\$/\text{h} \times 150 \,\text{h} = 3{,}12 \,\$ \] Réponse : **3,12 $**. --- ### Exercice 2 – Choix du modèle de service (niveau intermédiaire) Un lycée souhaite déployer une plateforme de cours en ligne où les enseignants peuvent créer des quiz, suivre les résultats des élèves et générer des rapports, sans avoir à gérer les serveurs ni le système d’exploitation. Quel modèle de service cloud convient le mieux ? Justifiez votre réponse. **Corrigé** Le besoin décrit concerne une **plateforme prête à l’emploi** pour développer et héberger des applications web (quiz, suivi, rapports). Le lycée ne veut pas gérer l’infrastructure sous‑jacente (serveurs, OS). Cela correspond exactement au modèle **PaaS** (Platform as a Service). - En PaaS, le fournisseur fournit le runtime, la base de données, les serveurs web et l’environnement de développement. - Le lycée se concentre uniquement sur le code de l’application et les données. Réponse : **PaaS** (ex. Google App Engine, Microsoft Azure App Service). --- ### Exercice 3 – Détermination du taux de consolidation (niveau intermédiaire) Un serveur physique dispose de 24 cœurs CPU et de 128 Go de RAM. Chaque VM requiert 3 vCPU et 16 Go de RAM. Quel est le nombre maximal de VM que l’on peut déployer sans sur‑allocation ? Quel est le taux de consolidation ? **Corrigé** - Limite CPU : \(\displaystyle \left\lfloor \frac{24}{3} \right\rfloor = 8\) VM. - Limite RAM : \(\displaystyle \left\lfloor \frac{128}{16} \right\rfloor = 8\) VM. Les deux limites donnent le même résultat : **8 VM** maximum. Taux de consolidation : \[ \frac{8 \text{ VM}}{1 \text{ serveur physique}} = 8 \] Réponse : **8 VM**, taux de consolidation **8**. --- ### Exercice 4 – Overcommit de mémoire (niveau avancé) Un centre de données possède un serveur avec 64 Go de RAM. L’administrateur décide d’autoriser un overcommit de mémoire de 130 %. Chaque VM est configurée avec 4 Go de RAM. Combien de VM peuvent être lancées théoriquement ? Si l’utilisation réelle moyenne de la RAM tombe à 70 % de la capacité physique, quelle est la quantité de RAM réellement utilisée ? **Corrigé** - Capacité physique : 64 Go. - Overcommit 130 % → capacité virtuelle autorisée = \(64 \times 1{,}30 = 83{,}2\) Go. Nombre de VM théoriques : \[ \left\lfloor \frac{83{,}2}{4} \right\rfloor = \left\lfloor 20{,}8 \right\rfloor = 20 \text{ VM} \] - Utilisation réelle moyenne : 70 % de 64 Go = \(0{,}70 \times 64 = 44{,}8\) Go. Réponse : **20 VM** peuvent être lancées théoriquement ; l’utilisation réelle moyenne de la RAM est **44,8 Go**. --- ### Exercice 5 – Comparaison coût d’achat vs location (niveau avancé) Une PMS (Petite et Moyenne Structure) envisage d’acquérir un serveur physique coûtant 2 000 € (hors taxes) avec une durée de vie de 4 ans. Le serveur consomme 200 W en moyenne et le prix de l’électricité est 0,18 €/kWh. Alternativement, elle peut louer une instance équivalente sur un cloud au tarif de 0,045 $ / h (taux de change : 1 $ = 0,92 €). Déterminer le coût total de possession (TCO) de l’achat sur 4 ans et le coût de location sur la même période (en supposant une utilisation 24 h/24, 365 j/an). Quelle solution est la plus économique ? **Corrigé** **Coût d’achat** - Prix d’acquisition : 2 000 €. - Consommation annuelle : \(200 \,\text{W} \times 24 \,\text{h/j} \times 365 \,\text{j/an} = 1{,}752 \,\text{kWh/an}\). - Coût énergétique annuel : \(1{,}752 \,\text{kWh} \times 0{,}18 \,\€/\text{kWh} = 315{,}36 \,\€/\text{an}\). - Sur 4 ans : \(4 \times 315{,}36 = 1{,}261{,}44 \,\€\). TCO achat = \(2 000 + 1 261{,}44 = 3 261{,}44 \,\€\). **Coût de location** - Tarif horaire en euros : \(0{,}045 \,\$ \times 0{,}92 \,\€/\$ = 0{,}0414 \,\€/\text{h}\). - Heures sur 4 ans : \(4 \times 365 \times 24 = 35{,}040 \,\text{h}\). - Coût location : \(35{,}040 \,\text{h} \times 0{,}0414 \,\€/\text{h} = 1{,}450{,}66 \,\€\). **Comparaison** - Achat : **3 261,44 €**. - Location : **1 450,66 €**. La location est nettement moins chère dans ce scénario (environ 55 % d’économie). Réponse : **Location du cloud** (1 450,66 € sur 4 ans) est plus économique que l’achat du serveur physique (3 261,44 €). --- ### Exercice 6 – Analyse d’un scénario de migration à chaud (niveau expert) Un administrateur souhaite migrer une machine virtuelle exécutant un serveur de base de données d’un hôte A vers un hôte B sans interrompre le service. Les deux hôtes disposent d’un réseau de stockage partagé (SAN) accessible via Fibre Channel à 8 Gbps. La VM occupe 100 Go de disque virtuel et consomme en moyenne 150 MiB/s de lecture/écriture pendant la migration. Estimer le temps théorique nécessaire pour transférer le disque virtuel si la bande passante réseau disponible pour la migration est de 6 Gbps (en supposant que le reste du trafic est négligeable). **Corrigé** - Taille du disque virtuel : 100 Go. - Convertir en bits : \(100 \,\text{Go} \times 8 \,\frac{\text{Gbit}}{\text{Go}} = 800 \,\text{Gbit}\). - Bande passante disponible : 6 Gbps. Temps théorique : \[ t = \frac{800 \,\text{Gbit}}{6 \,\text{Gbit/s}} = 133{,}\overline{3} \,\text{s} \approx 2{,}22 \,\text{min} \] Cependant, pendant la migration, la VM continue d’écrire : 150 MiB/s ≈ \(150 \times 8 = 1{,}200 \,\text{Mbit/s} = 1{,}2 \,\text{Gbit/s}\). Cette écriture supplémentaire consomme de la bande passante, réduisant ainsi la capacité dédiée au transfert. Bande passante effective pour le transfert = 6 Gbps − 1,2 Gbps = 4,8 Gbps. Nouveau temps : \[ t = \frac{800 \,\text{Gbit}}{4{,}8 \,\text{Gbit/s}} = 166{,}\overline{6} \,\text{s} \approx 2{,}78 \,\text{min} \] Réponse : environ **2 minutes 48 secondes** (en tenant compte de l’écriture continue). --- ## Erreurs fréquentes 1. **Confondre IaaS, PaaS et SaaS** - *Erreur* : croire que SaaS implique toujours la gestion du système d’exploitation. - *Correction* : rappeler que dans SaaS l’utilisateur n’a aucun contrôle sur l’infrastructure ni la plateforme ; il utilise simplement l’application. 2. **Oublier la notion d’élasticité rapide** - *Erreur* : penser que le cloud ne permet que d’augmenter les ressources, pas de les réduire. - *Correction* : insister sur le fait que l’élasticité s’applique aussi bien à la montée qu’à la descente de charge, permettant des économies lorsqu’on diminue l’allocation. 3. **Sur‑estimer le taux de consolidation sans vérifier la ressource limitante** - *Erreur* : calculer le nombre de VM uniquement en fonction du CPU et ignorer la RAM ou le stockage. - *Correction* : toujours déterminer le minimum entre les limites CPU, RAM, stockage et bande passante avant d’affirmer le taux de consolidation. 4. **Négliger l’overcommit et ses risques** - *Erreur* : autoriser un overcommit élevé sans mettre en place de monitoring, conduisant à des saturations de CPU ou de mémoire. - *Correction* : prévoir des alertes (ex. utilisation > 80 %) et des politiques de scaling automatique pour éviter la dégradation de service. 5. **Confondre machine virtuelle et conteneur** - *Erreur* : penser qu’un conteneur possède son propre noyau ou qu’il offre le même niveau d’isolation qu’une VM. - *Correction* : expliquer que les conteneurs partagent le noyau de l’hôte et que leur isolation repose sur les namespaces et cgroups, ce qui les rend plus légers mais moins isolés au niveau matériel. 6. **Mauvaise conversion d’unités lors des calculs de coût ou de bande passante** - *Erreur* : oublier de convertir les heures en secondes, les gigaoctets en gigabits, ou négliger le facteur de change dollar/euro. - *Correction* : systématiquement écrire les unités dans les formules, vérifier la cohérence (ex. $/h × h = $) et utiliser des facteurs de conversion clairement indiqués. > **À retenir** : La rigueur dans les définitions, les unités et les hypothèses de charge est essentielle pour éviter les erreurs classiques en cloud et en virtualisation. --- *Fin du cours de référence.*