Depuis quelques années la virtualisation sous toutes ses formes est devenue l'alpha et l'oméga de l'informatique, elle a révolutionné en quelques années la manière d'administrer les serveurs et de gérer les données. Cette dépêche est un essai de vulgarisation sur la virtualisation pour en exposer ses grands principes techniques, ses avantages et inconvénients et ses enjeux sous-jacents.
Sommaire
- Commençons par quelques définitions
- C'est quoi les avantages de la virtualisation ?
- Il existe d'autres types de virtualisation ?
- Autres concepts autour de la virtualisation
- Les enjeux
- En guise de réponse aux enjeux
- En guise de conclusion
- Pour aller plus loin
Commençons par quelques définitions
C'est quoi la virtualisation ?
Pour pouvoir illustrer concrètement ce qu'est la virtualisation, à une époque pas si lointaine que ça, dans le monde professionnel on retrouvait des serveurs physiques dédiés, par exemple un serveur pour gérer les mails, un autre pour le serveur web et un dernier comme serveur de fichiers. Chacun des serveurs pouvant tourner sur des systèmes d'exploitation (OS) différents. Dans notre exemple il en résulte qu'il faut maintenir et administrer trois machines différentes qui vont prendre de la place et consommer de l'électricité, sans une utilisation optimale de chacune des machines, si le serveur web par exemple a besoin momentanément d'un accroissement de puissance et de mémoire, il ne pourra pas bénéficier des ressources des autres serveurs physiques.
Avec la virtualisation, sur une seule machine physique on va faire tourner plusieurs environnements de serveurs distincts en même temps, sans avoir à redémarrer, ils vont se partager les ressources matérielles de la machine physique de manière plus optimale et efficace en réduisant les coûts d'administration. On retrouvera donc sur une seule machine physique, nos serveurs de courriel, web et de fichiers, chacun dans un environnement distinct fonctionnant de manière autonome et isolée.
C'est quoi une machine virtuelle ?
On appellera chaque environnement distinct machine virtuelle, elle s'exécute sur une machine physique avec son propre système d'exploitation, ses applications et avec les ressources de la machine physique qu'on veut bien lui allouer (mémoire, puissance de traitement, stockage). On dit aussi que la machine physique est appelée machine hôte et les machines virtuelles sont des machines invitées. Une machine hôte peut faire tourner plusieurs machines invitées.
Une machine virtuelle fonctionne comme n'importe quel poste informatique avec son OS qu'on peut mettre à jour, ses applications, ses paramètres système et on pourra à partir de la machine hôte accéder à toutes les machines virtuelles.
C'est quoi un hyperviseur ?
Pour que les machines virtuelles puissent s'exécuter indépendamment et utiliser les ressources de la machine hôte simultanément sans qu'elles interfèrent entre elles, il est nécessaire de rajouter une couche logicielle qui va gérer tout ça, c'est ce qu'on appelle un hyperviseur.
Il existe deux types d'hyperviseur:
- L'hyperviseur de type 1, ou bien encore hyperviseur de matériel nu (bare metal en anglais) est en interface direct avec l'ordinateur physique, cela sous entend que votre machine soit compatible (Intel VT pour les processeurs Intel et AMD-V pour les processeurs AMD). Dans le monde libre, proxmox est certainement l'hyperviseur de type 1 le plus connu.
- L'hyperviseur de type 2 ou bien encore hyperviseur de matériel invité (host metal en anglais) fonctionne dans un système d'exploitation déjà préinstallé, c'est le cas par exemple de VirtualBox qui permet de faire tourner une instance de windows dans un environnement Linux.
Un hyperviseur de type 1 est une couche logicielle très légère et offre de meilleures performances et est la solution privilégiée pour des serveurs en production, l'hyperviseur de type 2 est plutôt une solution destinée aux utilisateurs qui souhaitent tester d'autres systèmes d'exploitation ou faire tourner un logiciel sur un OS particulier sur un poste de travail classique. Mais rien ne vous empêche de faire tourner plusieurs machines virtuelles sur un hyperviseur de type 2 qui pourront communiquer entre elles et fonctionner comme un hyperviseur de type 1, à la différence qu'elles seront moins performantes.
Par abus de langage, le terme d'hyperviseur fait référence plutôt à l'hyperviseur de type 1.
C'est quoi les avantages de la virtualisation ?
Une administration centralisée et facilitée
L'hyperviseur fournit des outils de gestion des machines virtuelles qui simplifient sensiblement le travail d'administration, comme les outils de déploiement à partir de modèles de machines virtuelles, les outils de gestion de charge, de sauvegarde et de restauration de machines virtuelles.
La disponibilité et la robustesse aux pannes
Un autre avantage de la virtualisation est la fonctionnalité de migration à chaud, elle permet de déplacer une machine virtuelle d'une machine physique à une autre sans qu'il soit nécessaire de l'arrêter. Si un serveur physique présente des défaillances, les machines virtuelles sont automatiquement déplacées sur un autre hôte physique.
Alors bien sûr si le serveur physique tombe en rade sans crier gare, la migration à chaud peut ne pas être opérante, dans ce cas on peut très bien envisager la mise en place d'une machine physique redondante sur laquelle les machines virtuelles sont répliquées et qui prendra le relais automatiquement si le serveur primaire tombe.
L'amélioration des performances
La migration à chaud évoquée plus haut a un autre avantage si une machine virtuelle est sursollicitée et nécessite de la puissance de traitement et de la mémoire, elle pourra être déplacée automatiquement sur un autre serveur moins sollicité à ce moment-là.
La sécurité
La virtualisation isole les services chacun dans leur machine virtuelle, en cas de corruption d'une machine virtuelle par cyberattaque, l'impact est nul pour les autres services et la restauration d'une machine virtuelle est autrement plus rapide et plus simple qu'avec une machine physique.
La disparition des machines physiques
Le stade ultime de la virtualisation est de déléguer à un prestataire la gestion des machines physiques qui se retrouve quelque part dans un datacentre. On s'abstrait totalement du matériel physique et des contraintes qui vont avec et on gère seulement nos machines virtuelles à distance, c'est totalement transparent pour les utilisateurs qui accèdent à leurs services via internet ou sur un réseau privé. On parle aussi d'infrastructure virtuelle.
Il existe d'autres types de virtualisation ?
On a surtout évoqué jusqu'à présent la virtualisation des serveurs, mais il existe également d'autres types de virtualisation comme:
La virtualisation du stockage
Cela consiste en la création d'un espace virtuel de stockage à partir d'installations physiques de stockage bien réelles comme les serveurs de fichiers, NAS ou SAN qu'ils soient locaux ou distants. Cela permet de mettre en commun toutes ces installations et de la gérer à partir d'un outil unique de gestion pour effectuer toutes les opérations de sauvegarde, réplication, d'archivage et de restauration.
La virtualisation des réseaux
Un réseau est composé d'un tas d'éléments actifs comme les commutateurs, les routeurs et autres pare-feux, de type et de marques différentes. Là aussi on va créer un réseau virtuel qui combine l'ensemble de ces éléments actifs physiques pour pouvoir centraliser leur gestion sans avoir à y accéder physiquement. La virtualisation des réseaux permettra également d'améliorer les performances du réseau avec des analyseurs de trafic qui pourront équilibrer la charge ou favoriser certains flux.
La virtualisation des données
Les données sont issues de diverses sources, ont chacune leur format et sont stockées sur différents supports locaux ou distants. La virtualisation des données est une couche logicielle qui va gérer l'ensemble de ces données de manière centralisée et les mettre à disposition des utilisateurs et des applications dans le format désiré.
La virtualisation d'application
La virtualisation d'application permet de séparer l'application de son système d'exploitation hôte et de fonctionner sur un poste utilisateur sans qu'elle soit installée. Dans la pratique l'application est installée sur un serveur centralisé et peut tourner sur un poste utilisateur du réseau comme si elle était installée localement, quand bien même l'OS du poste utilisateur n'est pas celui pour lequel l'application a été conçue.
La virtualisation des postes de travail
La virtualisation permet de virtualiser des serveurs mais pas seulement, on peut virtualiser également des postes de travail pour en faciliter la gestion qui seront accessibles aux utilisateurs du réseau via un client léger bien moins cher qu'un PC client classique.
Autres concepts autour de la virtualisation
C'est quoi une infrastructure convergée et hyperconvergée ?
Une infrastructure convergée regroupe plusieurs composants informatiques traditionnels et bien physiques comme les serveurs de calcul, les dispositifs de stockage ou les éléments actifs réseau pour en assurer la gestion dans un tout cohérent. Cela simplifie la gestion de l'administration et ça optimise les ressources matérielles et logicielles. On dit que c'est une approche modulaire basée sur le matériel physique.
L'hyperconvergence a une approche plutôt logicielle, elle intègre une couche logicielle qui va combiner les ressources de calcul, de stockage et de réseau dans ce qu'on appelle un nœud. Les nœuds sont interconnectés et combinés entre eux pour former des pools au sein d'un cluster, on retrouve ainsi un pool de stockage ou un pool de calcul, si un nœud venait à défaillir ça n'aurait pas de conséquence pour les autres nœuds et le fonctionnement du pool et du cluster.
OK, mais une fois que tout ça est posé, quelle est la différence entre les deux ?
L'infrastructure convergée a une approche basée sur le matériel physique, c'est à dire qu'un serveur physique peut être séparé du reste du dispositif et toujours fonctionner comme un serveur indépendant alors que ce n'est pas possible avec l'infrastructure hyperconvergée où les noeuds sont nécessairement interconnectés entre eux pour que le cluster puisse fonctionner correctement. Par ailleurs l'infrastructure convergée intègre de base d'autres fonctionnalités comme la sauvegarde, la réplication, la déduplication des données, la compression, l'optimisation du réseau, etc.
C'est quoi un cluster haute disponibilité ?
On a bien vu que finalement qu'elle soit dans vos locaux ou chez un prestataire de service, la machine physique reste le maillon faible du dispositif. Pour améliorer encore plus la disponibilité et la robustesse, on va dupliquer les machines physiques et si possible en les dispatchant dans des locaux et sites différents. Le tout étant géré comme un seul système. La virtualisation du stockage prend alors toute son importance, pour éviter de se rendre dépendant d'un serveur physique de données.
C'est quoi le cloud computing ?
On appelle cloud computing le fait de confier à un tiers sur internet la gestion de services informatiques (applications, stockage, outils de gestion, …) mais aussi le fait d'utiliser des services fournis par un prestataire via internet. Le cloud computing repose largement sur la virtualisation, on peut dire que le cloud computing est un environnement alors que la virtualisation est une technologique. En matière de cloud computing, il en existe de différentes sortes :
- Infrastructure as a service (IaaS) ou infrastructure en tant que service : L'IaaS offre une infrastructure informatique complète (serveurs, stockage, réseau, …) sur un réseau privé (ressources en accès limité), public (ressources en accès libre) ou hybride (qui mélange les deux).
- Platform as a service (PaaS) ou plate-forme en tant que service : Le PaaS c'est grosso modo la même chose que l'IaaS sauf qu'en plus on bénéficie d'outils supplémentaires pour pouvoir développer des applications qu'on retrouvera sur le cloud et tous un tas de services supplémentaires, gestion de base de données, aide à la décision, etc.
- Le Software as a service (SaaS) ou logiciel en tant que service : Le SaaS est une offre logicielle complète qu'on retrouvera sur internet, c'est typiquement des offres comme Microsoft Office 365 ou Google Workspace, dans le monde opensource, on peut dire que certains prestataires recensés par les CHATONS se rapprochent d'une solution SaaS.
NdM: il est question ici de cloud computing sur un cloud public, une infrastructure gérée par un hébergeur tiers. Il est aussi possible de faire du cloud computing privé, interne, dans une grosse structure qui en a la capacité, ce qui revient à déléguer l'hébergement à un tiers (des collègues dans ce cas). Et on peut combiner les deux pour faire du cloud hybride. Le cloud computing implique aussi la création de ressources en libre-service, de la facturation à l'usage et de la mutualisation.
Les enjeux
Enjeu environnemental
L'adoption quasi généralisée de solutions autour de la virtualisation dans le monde professionnel a conduit à la disparition progressive des serveurs locaux d'entreprise au profit d'un développement effréné des datacenters de par le monde. Or un datacenter est constitué de machines bien physiques tournant 24h24 7j/7 avec tout un dispositif lui aussi bien physique pour assurer leur fonctionnement optimal, leur sécurisation et la robustesse aux pannes, il s'agit notamment de :
- La climatisation et le traitement d’air pour maintenir des conditions satisfaisantes de température et hygrométrie avec toute un système de circulation et de refroidissement d'air
- La distribution de l’électricité avec un dispositif de sécurisation en cas de coupure d'alimentation, souvent basé sur tout un ensemble d'onduleurs et appuyé par groupes électrogènes
- la protection physique de l'installation avec contrôle d'accès, vidéosurveillance et autres systèmes anti intrusion
Le tout nécessite une consommation électrique massive et une forte consommation en eau. Si l'on traduit cela en équivalent d'émission de gaz de serre (GES), d'après une étude de l'ADEME les datacenters ont déjà atteint le même niveau d'émission que le transport aérien à l'échelle mondiale.
Il se trouve que le destin des datacenters est maintenant également étroitement lié à celui de l'IA, même si dans ce domaine on envisage plutôt des datacenters dédiés, or les besoins générés par l'IA dopent l'expansion globale des datacenters dans le monde. La demande de puissance de calcul de l'IA est exponentielle et double tous les 3,4 mois selon OpenAI. Selon une étude Gartner citée par le Monde Informatique, rien que les besoins liés à l'IA feront exploser la demande énergétique des datacenters au point que les fournisseurs d'énergie ne pourront y répondre dès 2027 !
Dans ce contexte il n'est pas étonnant donc que les grands acteurs du secteur poussent au développement des centrales nucléaires qui leur permettra par la même occasion de verdir leur image. Mais ces acteurs ne sont pas à une contradiction près, on peut s'étonner du développement dans certaines régions qui de prime abord ne se prêtent pas particulièrement à leur installation contrairement aux pays nordiques. Le projet d'installation de Meta dans une région aride d'Espagne où chaque goutte d'eau compte, en est une triste illustration. Les températures régionales élevées décupleront ses besoins en électricité et en eau pour les circuits de refroidissement alors que la région souffre de sécheresse chronique. On peut déplorer que tout cela ne pourrait se faire sans le soutien des gouvernements et des élus locaux qui ne trouvent rien à redire.
Enjeu de résilience
Le marché actuel est dominé par trois acteurs qui représentent à eux trois plus de 60% du marché mondial il s'agit dans l'ordre d'AWS (Amazon), d'Azure (Microsoft) et de Google Cloud Platform, on parle d'eux comme des hyperscalers car ils fournissent des services à l'échelle mondiale à grande échelle. Cette hyperconcentration des acteurs et des solutions techniques fragilise l'économie mondiale en la rendant davantage sensible et moins résiliente aux pannes, la défaillance d'un simple outil de sécurité a ainsi entraîné en cascade une panne informatique mondiale en juillet dernier avec des conséquences graves comme l'arrêt partiel du contrôle aérien, de centres d'appels d'urgence ou de services hospitaliers. Plus modestement l'incendie subi par OVH en 2021 a impacté des milliers d'entreprise et services publics, toutes les données contenues sur les serveurs sont perdues, puisqu'OVH a commis l'erreur de stocker au même endroit les données et les sauvegardes. NdM: historique de pannes GCP, AWS ou Azure
Cette hyperconcentration fait planer également des risques en termes de cybersécurité, la corruption d'un élément du système et sa prise de contrôle par un hacker aura vite des conséquences majeures.
Enjeu de souveraineté
Il faut savoir que les données gérées par un datacenter sont soumises à la réglementation propre au pays où il est installé. Les autorités aux États-Unis, au nom du Patriot Act peuvent donc ainsi accéder aux données stockées sur leur territoire. Les datacenters souverains sont donc un enjeu majeur pour certains pays pour garantir que les données seront protégées par les lois nationales, sans ingérence étrangère possible.
En France notamment, 71% des entreprises se reposent sur des solutions américaines dont des acteurs étatiques. Une affaire illustre à elle seule cet état de fait, la solution Azure de Microsoft a été ainsi choisi pour héberger l'ensemble des données de santé de 4 établissements hospitaliers (et non de l'ensemble des Français) à des fins de recherche dans un entrepôt de données de santé dénommé EMC2. Sauf qu'en l'espèce Microsoft a répondu à un appel d'offre en bonne et due forme, que la CNIL a donné son autorisation et que les différents recours à ce stade ont tous échoué. Néanmoins voici ci-dessous texto la conclusion du rapport de la CNIL en 2023 :
(début de citation)
- qu’aucun prestataire potentiel ne propose d’offres d’hébergement répondant aux exigences techniques et fonctionnelles du GIP PDS (Note de l'auteur : groupement d’intérêt public « Plateforme de données de santé", appelé aussi Health Data Hub) pour la mise en œuvre du projet EMC2 dans un délai compatible avec les impératifs ce dernier ;
- que le développement d’un démonstrateur " cloud de confiance ", respectant les conditions de la circulaire précitée et permettant à terme d’héberger des projets de cette nature, et notamment la plateforme du GIP PDS, devrait se poursuivre sur les prochaines années ;
- que la construction d’une plateforme d’hébergement spécifique pour le projet EMC2 pourrait retarder la migration de la solution d’hébergement du GIP PDS pour l’ensemble de ses missions ;
- qu’en attendant cette migration, le projet EMC2 soit mené sur la solution technique actuelle du GIP PDS.
À la lumière de ces conclusions, la CNIL déplore qu’aucun prestataire susceptible de répondre actuellement aux besoins exprimés par le GIP PDS ne protège les données contre l’application de lois extraterritoriales de pays tiers.
De manière générale, elle regrette que la stratégie mise en place pour favoriser l’accès des chercheurs aux données de santé n’ait pas fourni l’occasion de stimuler une offre européenne à même de répondre à ce besoin. Le choix initial du GIP PDS, dès sa fondation, de recourir au cloud a conduit à privilégier des offres d’acteurs étasuniens dont il apparaît désormais difficile de se détacher à court terme malgré l’émergence progressive de fournisseurs souverains. Le projet EMC2 aurait pu être retenu par le GIP PDS pour préfigurer la solution souveraine vers laquelle il doit migrer.
(fin de citation)
À la lumière de cette conclusion, on peut comprendre que la CNIL s'est sentie contrainte et forcée de répondre favorablement pour ne pas faire capoter ce projet en espérant que cette solution ne soit que transitoire et qu'elle pourra basculer sur une solution souveraine dans quelques années.
Autre affaire d'actualité, le contrat entre EDF et AWS pour le stockage de certaines informations sensibles de maintenance du parc nucléaire français, le Canard enchaîné vient de révéler récemment que le contrat battait de l'aile car Amazon refuse d'inscrire noir sur blanc dans le contrat que les données d'EDF seront stockées en France (autre article).
Aussi la France cherche à développer son "cloud souverain" pour ne plus être dépendant des géants américains mais peine à avancer sur le sujet faute de barrières réglementaires et juridiques, de réticences des élus et des populations sur les territoires pouvant accueillir des datacenters et d'une certaine frilosité des banques et acteurs technologiques.
En guise de réponse aux enjeux
Réponse à l'enjeu environnemental
Pour ne pas courir à la catastrophe annoncée, la mise en place de technologies plus efficaces et économes en énergie est un enjeu majeur, parmi les axes d'innovation on peut citer:
- l'utilisation d'énergie renouvelable
- le refroidissement des datacenters basé sur des technologies peu gourmandes en eau,
- la réutilisation de l'énergie dissipée par les datacenters.
Réponse à l'enjeu de résilience
Des normes et des certifications se sont mises en place qu'elles soient internationales, européennes ou nationales. On peut citer :
- TIA 942 qui couvre différents domaines comme la disponibilité, la sécurité, l'efficacité énergétique, le refroidissement, la redondance et la gestion de l'espace;
- ANSI/BICSI-002 qui définit des standards de conception et de pose des systèmes de câblage, d'électricité, dissipation de chaleur, refroidissement, etc.
- ISO 27001 qui couvre la gestion de la sécurité de la donnée;
- ISO 22237 qui couvre l'installation et les infrastructures des datacenters;
- le référentiel de sécurisation des services cloud SecNumCloud élaboré par l’ANSSI;
- la certification d'Uptime Institute avec sa classification du niveau de sécurité des datacenters de Tier I à Tier IV.
En France, France Datacenter est une organisation professionnelle qui fédère les entreprises qui conçoivent, construisent et exploitent les datacenters. Elle publie également des guides à destination de ses adhérents qui font référence, on peut citer notamment "le livre blanc sur la sécurité incendie" ou "l'humain et la sécurité du datacenter".
D'un point de vue réglementaire, on peut citer :
- le règlement général sur la protection des données RGPD;
- La directive européenne relative à DEE l’efficacité énergétique DEE;
- La directive européenne relative à la sécurité des réseaux et de l’information, dite NIS 2 pour Network and Information System Security.
Le respect de ces normes, certification et a fortiori de la réglementation sont une garantie que les datacenters sont construits suivant les règles de l'art avec le niveau de qualité, de sécurité et de fiabilité attendu. A ce propos pour en revenir à l'incident OVH, les procédures judiciaires qui en ont découlé et qui ont conduit à la condamnation d'OVH ont mis en évidence que la société qui se targuait d'être certifié ISO 27001 n'a pas respecté la norme pour ne pas avoir prévu une copie de sauvegarde sur un site distant.
Réponse à l'enjeu de souveraineté
Le respect du RGPD et de la certification SecNumCloud sont une première réponse à la menace des lois extraterritoriales sur la confidentialité des données, en parallèle le premier ministre de l'époque a diffusé en 2021 une circulaire relative à la doctrine d'utilisation de l'informatique en nuage par l'État qui a été actualisé en 2023. Cette dernière "exige (…) en cas de recours à une offre commerciale d'informatique en nuage, l'hébergement des données d'une sensibilité particulière par des solutions disposant de la qualification SecNumCloud (…) et immunisées contre toute réglementation extracommunautaire".
Il faut par ailleurs créer l'environnement pour que des acteurs locaux puissent se développer et former une alternative crédible aux hyperscalers. L'émergence d'acteurs alternatifs de proximité est donc un enjeu que le marché seul ne suffit pas à faire percer, il faut une volonté politique, une stratégie et une vision à long terme, des financements, une adaptation de la réglementation à l'échelle européenne et nationale.
À ce sujet le précédent gouvernement avait concocté une loi de simplification de la vie économique destinée à faciliter l'installation de datacenters en France en les qualifiant de projets d'intérêt national majeur (PINM) pour qu'ils puissent bénéficier de mesures dérogatoires, de procédures accélérées tout en contournant le pouvoir des élus locaux puisque ça sera l’État qui signera les permis de construire. Avec cette loi la métropole de Rennes n'aurait sans doute pas pu refuser l'implantation d'un datacenter de Microsoft s'il avait été jugé d'intérêt national. Aujourd'hui ce projet de loi continue son bonhomme de chemin législatif malgré l'instabilité politique actuelle.
Cet objectif de développement d'une offre de proximité n'est pas forcément compatible des objectifs environnementaux et de développement durable que la France s'est imposée, mais il faut voir ça comme une opportunité pour innover et ne plus être à la traîne des États-Unis dans ces domaines technologiques.
En guise de conclusion
D'une simple présentation technique autour de la virtualisation, on en arrive en tirant la pelote à des considérations à fort enjeu sur la gestion et la confidentialité des données que bien des utilisateurs de cloud n'imaginent pas, ni même ne considèrent à sa juste importance. Pourtant il suffirait qu'ils en prennent conscience pour orienter leur choix vers des solutions respectueuses qui peinent encore aujourd'hui à émerger malgré les vœux pieux de l’État qui n'est pas toujours exemplaire dans le domaine.
Pour aller plus loin
Quelques pages de vulgarisation
- la page wikipedia sur la virtualisation https://fr.wikipedia.org/wiki/Virtualisation
- La page d'AWS (Amazon) https://aws.amazon.com/fr/what-is/virtualization/
- La page d'Azure (Microsoft) https://azure.microsoft.com/fr-fr/resources/cloud-computing-dictionary/what-is-cloud-computing
- Qu'est-ce qu'une machine virtuelle sur le site de redhat https://www.redhat.com/fr/topics/virtualization/what-is-a-virtual-machine
- Le cloud computing sur le site de redhat https://www.redhat.com/fr/topics/cloud-computing
- Comparaison IaaS, PaaS et SaaS sur le site de redhat https://www.redhat.com/fr/topics/cloud-computing/iaas-vs-paas-vs-saas
Une sélection de sites sur les enjeux et le futur autour de la virtualisation et les datacenters
- La page wikipedia sur les datacenters avec ses différents enjeux https://fr.wikipedia.org/wiki/Centre_de_donn%C3%A9es qui mène vers autant de liens tout aussi intéressants
- L'empreinte environnementale du numérique par l'ARCEP https://www.arcep.fr/la-regulation/grands-dossiers-thematiques-transverses/lempreinte-environnementale-du-numerique.html
- Envoyer un datacenter dans l'espace ! https://hellofuture.orange.com/fr/empreinte-carbone-souverainete-pourquoi-envoyer-un-datacenter-dans-lespace/
- Penser des datacenters moins énergivores par le CNRS https://lejournal.cnrs.fr/articles/penser-des-datacenters-moins-energivores
Sites divers
- Le rapport d'enquête établi par le Bureau d’enquêtes et d’analyses sur les risques industriels sur l'incendie d'OVH https://www.igedd.developpement-durable.gouv.fr/IMG/pdf/rapport_ovh_67_vdif_cle01cf13.pdf
Aller plus loin
- Virtualisation (55 clics)
# intéressant ...
Posté par PLuG . Évalué à 10 (+11/-0).
Bonjour,
Merci pour cet article que j'ai trouvé très intéressant même si il me semble parsemé d'interprétations et d'imprécisions, peut-être dues à la volonté de vulgariser un peu ? Je donne des exemples, peut-être que l'on pourrait modifier compléter ces points pour améliorer le contenu ?
exemples:
c'est quoi la virtualisation : on y apprend que c'est vachement mieux qu'avant, que désormais on ne monopolise plus une machine physique par besoin (mail, serveur web, …)…. sans expliquer que "avant" on n'avait pas le choix : les machines physiques étaient beaucoup moins puissantes.
la virtualisation c'est une réponse (bien pratique au demeurant) a un problème : les serveurs fournissent une puissance de calcul qu'il est impossible de consommer avec un simple serveur de mail, le nombre de cores a explosé et l'industrie logicielle elle même a encore du mal à développer correctement en multithread. L'explication de la virtualisation ne parle (sans le dire) que de x86, mais cela fait des lustres que les vraies grosses machines (solaris, mainframe IBM, …) utilisent de la virtualisation pour optimiser la consommation de leurs ressources (importantes).
Sur la tolérance aux pannes, peut-être qu'on pourrait préciser que le move de VM apporte une tolérance à la panne physique (et encore, il est bien expliqué que … pas vraiment si la panne est brutale). Le move c'est plutôt une facilité de gestion du capacity planning. Pour la tolérance aux pannes, rien ne vaut non pas le serveur répliqué comme expliqué, mais plutôt 2 instances différentes de serveurs virtuels, ce qui permet de résister aux pannes logicielles de l'OS lui même (exemple : une manip/un patch qui casse le serveur) et qui permet de faire des évolutions en pleine période d'utilisation en isolant une des instances.
La virtualisation d'applications: le résultat c'est qu'on déporte l'affichage (l'application ne tourne pas sur le poste comme écrit)
La virtualisation poste de travail : j'ai pu lire plusieurs comparaisons de couts, et il semble compliquer de conclure que le "poste Léger" est moins onéreux que le CP standard. Ce qui est écrit reste vrai (le poste léger est moins cher), mais la structure de cout de la solution complète est très différente, et inclure dedans les couts serveurs, licences de virtualisation, … fait que ça revient grosso modo au même, avec des contraintes d'utilisation (et de maintenance) différentes.
Sur le Cloud Computing, heureusement la NDM vient compléter le texte, très partisan du cloud public
Sur l'enjeu de résilience, la panne "Azure" n'est pas une panne Azure mais une panne Crowdstrike comme expliqué dans le texte. Cependant je ne sais pas comment l'impact sur les compagnies d'aviation peut être relié à Azure, rien ne dit que ces compagnies n'utilisaient pas crowdstrike sur leurs serveurs windows en interne. Le nombre de serveurs windows touché a dépassé largement Azure…
Sur l'enjeu de souveraineté, il ne me semble pas que le sujet soit uniquement la localisation du datacenter, mais plutôt la nationalité de l'hébergeur. Azure, Oracle, Google, AWS possèdent des datacenter en France et/ou en Europe mais cela ne constitue pas une réponse "cloud de confiance" pour autant.
Encore une fois, j'ai réellement hésité à à signaler ces points, ce serait dommage de ne retenir que mon commentaire alors que l'article proposé est très documenté et sourcé et très bien rédigé. C'est un travail que je salue et qui pourrait faire référence.
[^] # Re: intéressant ...
Posté par Funix (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Merci pour ton commentaire, les commentaires sont également là pour enrichir les dépêches/journaux et les corriger s'il le faut.
Je te confirme que le sujet est finalement tellement vaste que j'ai pris quelques virages, je n'ai pas souhaité aller trop loin dans la technique mais m'attarder sur les enjeux.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: intéressant ...
Posté par PLuG . Évalué à 5 (+4/-0).
Pour moi ces évolutions sont liées aux capacités du hardware et au prix des composants.
A une époque on cherchait à utiliser au mieux un serveur X86 finalement pas si puissant que cela. on parlait d'overcloking pour gonfler les CPU, de mutualiser les pages mémoires (bibliothèques partagées , nos lib.so sous linux ou dll sous windows) pour contenir la consommation RAM.
Les serveurs Unix, Z, … plus puissants avaient déjà de la virtualisation.
Aujourd'hui à l'heure des containers, on fait l'inverse : on essaie d'utiliser toute la puissance des machines et on multiplie les bibliothèques dans chaque container, copiées de multiples fois en pages mémoire dans le but de simplifier les gestes de gestion (la RAM n'est plus un problème).
Dans les modèles de gestion, je trouve que de la même manière on vit un effet boomerang. A une époque une équipe resserrée administrait le serveur et développait l'application. Puis on a "professionnalisé" : séparé des spécialistes de l'administration, d'autres du développement. ça tombe bien, l'administration est devenue compliquée avec les risques de sécurité et autres contraintes. Mais on pousse le bouchon au point que les équipes séparées ne se parlent plus. le modèle devient peu efficace. On décide alors d'inventer le DevOps : génial on va mettre les gens ensemble :-)
[^] # Re: intéressant ...
Posté par Benoît Sibaud (site web personnel) . Évalué à 7 (+4/-0).
Sur la tolérance aux pannes : tu troques de rares pannes à grand effet voire fatales (perdre un serveur physique par exemple) contre de petites pannes fréquentes (plus tu as d'instances, de répartisseurs de charge, de datacentres impliqués, plus les chances qu'un soit en panne augmente, et plus tu essaies de te débrouiller pour ne pas être gêné ou très peu sur chaque petite panne). Et le prix est la complexité et le coût de l'automatisation (pour un gain scalabilité et disponibilité).
Sur l'enjeu de souveraineté : question compliquée suivant ce qu'on y met. Prenons les États-Unis pour l'exemple. Hébergeur AWS / GCP / Azure, c'est assez clair. Mais quid d'un hébergeur français qui ne fait que du WMware (bref qui dépend totalement d'un logiciel étatsunien) ? Ou sur un datacenter américain (Equinix a plein de datacenters en France par exemple) ? Ou sur du matériel américain (difficile à éviter en processeurs ou baie de stockage ou réseau) ? Ou qui recourt à des logiciels/services américains tiers (Cloudflare, Crowdstrike, etc.) Et puis l'alternative ne serait pas forcément mieux : Russie, Chine, Israël, etc. ?
[^] # Re: intéressant ...
Posté par Funix (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Oui c'est exact, le choix des solutions techniques et logicielles font partie de l'enjeu de souveraineté et dans ce cadre là les logiciels libres auraient leur mot à dire.
Mais j'ai quand même l'impression que la plupart des utilisateurs du particulier à l'acteur étatique font appel à un service et ils se moquent de savoir ce qu'il y a sous le capot, d'autant plus si l'offre respecte certaines normes et référentiels dont le secnumcloud de l'anssi.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: intéressant ...
Posté par Eh_Dis_Mwan . Évalué à 1 (+0/-0). Dernière modification le 12 janvier 2025 à 21:36.
Sur le oremier point, il y eu un état intrrmédiaire: les serveurs mutualisés. Ici le problème concernait le reboot des machines pour un upgrade d’un petit service ou lib.
Mais quand même, j’ai eu à faire une presentation similaire lors d’onboarding et mettre des mots simole sur des cinceots complexes, c’est pqs donné à tous le monde. Donc bravo à l’auteur de ce journal
# Copain de titre
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à 3 (+2/-0).
Très bon article très synthétique. Oui il y a des raccourcis mais c'est obligatoire lorsqu'on traite d'un sujet aussi vaste. Bon travail.
C'est marrant, il y a 5 ans quasiment jour pour jour j'avais pondu un article sur mon blog avec quasiment le même titre :)
Un gentil du net
# Type 2 et extensions SVM / VMX
Posté par Sébastien Rohaut . Évalué à 3 (+1/-0).
Bonjour, très beau document.
Une précision sur la description des hyperviseurs de type 1 ou 2: les extensions Intel VT-x (VMX) ou AMD AMD-V (SVM) ne sont pas limitées aux hyperviseurs de types 1. Des solutions de type 2 comme KVM, VMWare (workstation ?) ou Virtualbox exploitent ces capacités de virtualisation matérielles.
Dans le même sens, la Paravirtualisation n'est pas abordée, elle permet, via des pseudo-interfaces, un accès plus direct et privilégié aux couches basses ou au matériel, y compris sur les hyperviseurs de type 2, voire même de présenter directement le périphérique à la machine virtuelle (exemple, une vraie carte graphique, ou un vrai contrôleur disque). Ainsi, bien que le performances restent un peu inférieures aux type 1, ont obtient des performances très proches d'une machine native.
[^] # Re: Type 2 et extensions SVM / VMX
Posté par Yth (Mastodon) . Évalué à 3 (+1/-0).
Avec qemu/kvm tu peux en effet faire du PCI-passthrough et flécher l'intégralité du flux PCI d'une carte vers une VM dédiée.
C'est plutôt efficace.
# “Container” et machine virtuelle ?
Posté par pieq (site web personnel, Mastodon) . Évalué à 2 (+1/-0).
Merci pour cet article de vulgarisation !
Je travaille pas mal en anglais, et on utilise beaucoup le terme de “container”. Du coup, j'avais l'impression que “container” et “virtual machine” étaient deux termes qui définissaient deux choses différentes. Le présent article ne mentionne pas du tout l'idée de “container”, du coup je suis un peu perdu…
Dans mon esprit, un container partage le noyau avec le système hôte. Impossible donc d'avoir un container Windows sur une machine Linux. Par opposition, une machine virtuelle permet de faire tourner à peu près n'importe quoi sur n'importe quel système hôte. Me trompè-je ?
[^] # Re: “Container” et machine virtuelle ?
Posté par PLuG . Évalué à 2 (+1/-0).
Non tu ne te trompes pas, je me suis aussi fait cette réflexion : l'article aborde le cloud computing sous l'angle de la virtualisation alors que quand on se lance dans des clusters openshift on revient aux machines physiques pour les nœuds de calcul.
Une partie sur les containers, docker, k8s, openshift serait certainement bienvenue. C'est une façon différente de découper l'accès aux ressources d'une machine. Plus proche de l'application + ses dépendances (bibliothèques). Sans embarquer l'os qui est partagé. Avec les containers on va multiplier des 100aines d'instances d'applications sur une machine physique pour tirer profit de sa puissance.
Le modèle permet aussi plus de souplesse pour gérer le déploiement (le container est une entité simple ) déployé avec peu de dépendances), la montée en charge (les moteurs de container vont être capable de multiplier les instances si besoin pour tenir la charge), la résilience (idem, possibilité de déployer des instances dans une autre zone d'hébergement en cas de sinistre), …
L'article mentionne des "niveaux" de cloud (IaaS, PaaS, SaaS), le modèle cloud est adapté à la description d'environnements complets (base de donnée, load-balancer, application, reverse proxy, …) et sera capable de gérer le déploiement du tout de façon cohérente (donc répétable à l'envie, toujours la même qualité, rapidité de mise en œuvre, … et à la fin en mode "selfcare" pour les équipes de développement).
Au prix d'une complexité accrue, et du déplacement de certaines responsabilités. Par exemple traditionnellement les mises à jour de sécurité des bibliothèques fournies par le système était lié au patch management de l'OS. Avec les containers, en général fournis par les développeurs applicatifs, et incluant toutes les dépendances, ils héritent de cette responsabilité.
[^] # Re: “Container” et machine virtuelle ?
Posté par PLuG . Évalué à 2 (+1/-0).
bigre, ce n'est pas simple d'être précis. J'ai écris OS mutualisé mais j'aurai du écrire Kernel, le reste de l'os (souvent minimaliste) est embarqué dans le container.
[^] # Re: “Container” et machine virtuelle ?
Posté par ChrisJ (site web personnel) . Évalué à 3 (+3/-0).
Oui, pour moi les machines virtuelles et les conteneurs permettent tous deux de faire de la virtualisation, mais au niveau de deux interfaces différentes :
Dans les deux cas, on obtient une isolation entre invités et entre invités et hôte.
(*) ISA du processeur simulé par la machine virtuelle (qui n'est pas forcément le même que celui de la machine hôte !)
[^] # Re: “Container” et machine virtuelle ?
Posté par Funix (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
oui je me rends compte que j'ai omis de développer ce point mais bon tout est dit dans vos commentaires
https://www.funix.org mettez un manchot dans votre PC
# Merci
Posté par vmagnin (site web personnel) . Évalué à 7 (+5/-0).
Merci pour cet article pour les nuls ! Ca montre la complexité du monde moderne et sa fragilité à l'heure où la géopolitique est en ébullition.
[^] # Re: Merci
Posté par Funix (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
En partant d'un sujet purement technique et en tirant la pelote je me doutais pas que j'allais tomber sur des considérations géopolitiques en résonance avec le tumulte du monde. Ces outils deviennent des instruments d'hégémonie sans doute bien plus efficaces que des armes.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Merci
Posté par vmagnin (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 10 janvier 2025 à 22:04.
Mais attention à l'effet boomerang (c'est d'ailleurs une arme). Les choses ne se passent pas exactement comme prévu il y a 25 ans.
On notera aussi que stocker (ou sauvegarder) ses données à l'étranger n'est pas toujours une mauvaise idée. Un data center sous les bombes, c'est pas très résilient…
# Bon brossage de tableau !
Posté par zerodeux (site web personnel) . Évalué à 7 (+6/-0).
Je mettrai bien mon grain de sel sur la partie sécurité/souverraineté/simplicité.
Déjà via le Cloud Act qui est un très bon (gros) point d'entrée dans le sujet : l'expression "les données gérées par un datacenter" me semble trop approximative, il faudrait plutôt parler des "données gérées par un opérateur" car la question est de savoir 1/ à qui appartiennent les équipements qui manipulent lesdites données et 2/ qui les contrôle.
Cas hostile : tu met des données dans des équipements situés en France mais appartenant à un cloud américain et géré par lui; le Cloud Act leur permet de siphonner ce qu'ils veulent quand ils veulent. De toute façon tu consommes du "cloud (IaaS)" et il n'y a aucun espoir que tu crées le moindre rideau de confidentialité, puisque le cloud gère toutes les clés de chiffrage pour toi. Si tu les gères manuellement ça ne change rien, à un moment il faut qu'une clé de chiffrage existe en clair (même brièvement, même en RAM) sur le(s) serveur(s) concernés. J'appellerai ça le modèle "à poil sur Internet".
Cas intermédiaire : tu met des données dans des équipements situés en France appartenant à un opérateur français. Cet opérateur peut techniquement aspirer tes données (cf. paragraphe précédent), mais légalement non. On en revient donc à une relation de confiance traditionnelle (avec l'opérateur, avec la loi de son pays, avec la façon dont son application est contrôlée, etc). Et bien sûr on est toujours sujet à l'écoute légale, qui est un mécanisme considéré acceptable quand il est bien contenu (limité à la justice, doit passer par un juge pour approbation, etc). En France actuellement on peut tout à fait être insatisfait de ce niveau de confidentialité : par ex. si on héberge un blog écolo on peut tout à fait se faire "écouter" par la cellule anti-terroriste.
Cas prudent : tu mets des données dans des équipements situés en France, qui t'appartiennent et que tu gères. En théorie tu n'est donc sujet qu'à l'interception légale, soit au niveau de ton peering, soit éventuellement directement sur tes équipements mais dans ce cas tu recevras une demande de la PJ ou de la DGSE (tu seras donc bien informé, et tu ne pourras pas refuser). Et il reste aussi l'accès physique : même si tu loues une "suite privée" dans un datacenter, tous les techniciens du datacenter peuvent y accéder. Tu ne peux pas formellement assurer que tu es le seul à pouvoir accéder physiquement à tes équipements, c'est pas interdit d'être parano en monitorant ce qui se plugge sur les switches, bloquer tous les ports serveurs eth/usb non utilisés, etc.
Evidemment tout ceci est à analyser au prisme d'un modèle de menace : si tu héberges une boutique qui vend des pots de miel, tout ce qui a été cité t'importe très peu. Au pire tu crains une attaque de concurrents, qui n'useront probablement pas d'attaque physique (le remote via les failles des apps web + ingénierie sociale restant hélas très efficaces).
Quant à l'avantage de la virtualisation, OK pour ceux cités, mais …
En premier lieu quand tu passes à la virtu toi-même (par ex. tu installes Proxmox), tu dois acquérir une compétence en plus. Et elle n'est souvent pas mince, les outils de virtu (avec tout ce qu'ils tirent : Xen/KVM, H-A, Ceph/NFS/etc) peuvent venir à un gros update de bagage technique. Evidemment ça peut rapporter gros sur la partie opérationnelle si les besoins de nouveaux "serveurs" sont fréquents : si ces derniers sont virtuels, on élimine une grosse friction. Mais j'ai vu des cas où ces besoins étaient quasi nuls, et il était tout à fait raisonnable de ne pas envisager de passer aux VMs.
En second lieu quand tu délègues la virtu, tu :
* change de business model : au lieu d'acheter du matériel et l'amortir, tu passes sur du récurrent; l'impact peut être important car un bon matériel peut s'amortir sans problème sur 5 à 10 ans (autant dire qu'à +2 ans ton "compute" est quasi-gratuit vu du modèle du cloud)
* renonce à plein de garanties de sécurité et de confidentialité (cf. le barratin plus haut)
* dépend du support du cloud : ce que tu savais réparer en 30min va peut être se transformer en ticket fleuve d'1 semaine (dans mon expérience hélas récurrente, retirez le "peut être")
* en général la dispo des VMs du cloud est meilleure que ce tu faisais par toi-même (si ce n'était pas ton métier), mais le cloud ça plante quand même; du coup les problèmes de H-A se posent toujours et ne sont pas magiquement résolus (sauf réplication en continu de VM à la VMware, jamais testé, mais à chaque fois qu'on m'a proposé ça coûtait 3 bras et 5 fesses)
* c'est peut être un avis plus perso, mais les "clouds" ont parfois une complexité et charge cognitive bien supérieur à ton petit cluster Xen/KVM; si tu es un profil technique ça peut devenir contre-productif et démotivant de te battre contre des usines à gaz relativement abstraites
[^] # Re: Bon brossage de tableau !
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Il existe une réponse technique partielle à cela : le chiffrement homomorphe (ton cloud verra des données chiffrées uniquement, éventuellement il fera des opérations sur des données chiffrées, mais sans les connaître). Les performances sont tellement mauvaises (facteur 10000 ou 100000) qu'il faut un sacré besoin pour justifier la débauche de ressources et donc le coût correspondant. Toutes les opérations ne sont pas possibles (donc fonctionnellement ça peut limiter beaucoup). Et ça n'est pas magique non plus, ton cloud pourrait stocker tes données pour casser plus tard par exemple (l'intérêt pourrait apparaître avec mon exemple suivant). Mais si tu voulais héberger une solution de vote par internet sur un cloud public (je n'ai pas dit que c'était une bonne idée mais bon), tu pourrais lui demander d'additionner des votes sans que le cloud y ait accès en clair (sauf à casser la crypto), et pour un usage ponctuel, le surcoût de ressources pourrait être acceptable. En pratique, c'est très peu utilisé.
# Contre-sens sur le Patriot Act
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
Comme on dit sur Wikipédia : « référence nécessaire ». En résumé : c'est faux.
C'est un contre-sens : le Patriot Act (et autres textes étatsuniens) donne au contraire aux autorités étatstunienns le pouvoir d'accéder aux données qui ne sont pas sur leur territoire. (Sinon, cela n'aurait rien d'extraordiniare.)
[^] # Re: Contre-sens sur le Patriot Act
Posté par Funix (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Pour le premier point, je confirme que les données gérées par un datacenter sont soumises à la réglementation où le pays où il est installé (du moins quand elle existe), exemple en Europe avec le RGPD qui est une obligation réglementaire, pour la référence je te renvoie vers le RGPD.
Pour le deuxième point, oui effectivement, j'aurais pu préciser "sur leur territoire ainsi qu'en dehors des US".
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Contre-sens sur le Patriot Act
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Je veux bien le numéro de l'article qui dit ça. Car le RGPD, dans son article 3, dit exactement le contraire : il s'applique à toutes les données des résidents européens, quel que soit l'emplacement des données.
[^] # Re: Contre-sens sur le Patriot Act
Posté par Benoît Sibaud (site web personnel) . Évalué à 8 (+5/-0). Dernière modification le 11 janvier 2025 à 18:18.
Elles sont notamment soumises à la réglementation du pays où il est installé. Si une boîte japonaise fait un datacenter à Berlin, elle sera concernée par la loi allemande / européenne, et potentiellement par la loi japonaise, et potentiellement à des lois extraterritoriales supplémentaires si les autres pays arrivent à mettre la main sur des gens / faire pression sur l'entreprise (exemple dans un autre domaine : banques suisses vs États-Unis).
# La description du passé est contestable
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8 (+6/-0).
Alors, je parle d'expérience (mon âge, etc) et ce n'était pas comme cela qu'on faisait : on mettait plusieurs services sur la même machine (ce qui ferait hurler les RSSI d'aujourd'hui mais Unix était précisément conçu pour cela). Cela répond à l'argument « utilisation optimale de chacune des machines ».
[^] # Re: La description du passé est contestable
Posté par Funix (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Perso quand j'ai commencé ma carrière sur des stations UNIX, c'était comme ça que ça marchait, un serveur physique par grand service, je ne prétends pas que c'était une règle universelle et ça dépendait sans doute des moyens de la boite.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: La description du passé est contestable
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Il fallait vraiment avoir du fric ! Ces serveurs physiques étaient chers et on ne pouvait pas se permettre de les dédier à un usage intermittent.
[^] # Re: La description du passé est contestable
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
Vous ne parlez pas de la même situation je dirais.
Exemple avec chiffres pris au pif :
Si ton service courriel c'est 15% d'un serveur physique, que ton web c'est 25% et que ta base de données c'est 20%, alors tu vas te dire qu'un serveur c'est bien assez en ressources (en disponibilité c'est autre chose). Là on est dans le cas de services unix et du partage sur un système (ça ressemble au cas LinuxFr.org par exemple).
Si ton service courriel c'est 30 à 60% d'un serveur physique, que ton web c'est de 15 à 45% et que ta base de données c'est 20 à 40%, alors tu n'as pas envie de tout mettre sur un seul serveur physique de toute façon, donc plusieurs serveurs, et tu va commencer à avoir pas mal de gâchis de ressources pour éviter des pics de charge qui pourraient coïncider. Là on commence à avoir du mal à mettre plusieurs services par serveur (sans parler du cirque pour les déplacer en cas de besoin).
La promesse de la virtualisation, de Kubernetes, etc., c'est de pouvoir dire je veux des minimums de 30%/15%/20%, je veux un max de 60%/45%/40%, et de compter sur l'infra pour gérer.
Après la disponibilité et la répartition de charges font que mettre 10 instances d'un même service sur un même serveur, ça ne serait pas idéal, donc on met des règles de non-affinité, donc on a besoin de plein de serveurs différents, et puis on fait répartir à des endroits différents, donc on a besoin d'encore plus de serveurs différents. Et on compte sur l'hébergeur d'infra pour mutualiser et rationaliser tout ça (et il margera là-dessus).
[^] # Re: La description du passé est contestable
Posté par steph1978 . Évalué à 2 (+0/-0).
Et on fait toujours comme ça. Avec systemd ou Docker ou tout autre gestionnaire de services.
# XEN et migration à chaud
Posté par Micromy (site web personnel) . Évalué à 4 (+3/-0).
Bonjour et merci pour ce long article qui présente un certain état de l'art de la virtualisation informatique.
Je souhaite compléter en citant comme hyperviseur de niveau 1 XEN. C'est un hyperviseur qui s'installe sur le matériel physique car orienté à l'origine pour la paravirtualisation, et qui se gère depuis une machine virtuelle invitée privilégié, le "domaine 0".
XEN est un peu en perte de vitesse, mais c'était la base technique d'Amazon AWS, et on le retrouve encore dans son offre bas de gamme dans le type T2.
Concernant la migration à chaud présentée comme un avantage, il faut bien être conscient que de la théorie à la pratique il y a un écart, voir un fossé. En effet selon les applications utilisées sur la machine virtuelle et la charge des traitements ça peut effectivement être "magique" ou bien catastrophique. Le principe est que la mémoire de la machine virtuelle sur l'hyperviseur source est recopiée sur hyperviseur cible. Si les disques ne sont pas en réseau (SAN ou NAS) ils doivent aussi être transférés. Tout ça prend du temps, donc des resynchronisations régulières sont effectuées jusqu'à arriver à un état très proche entre les deux machines virtuelles. À ce moment l'hyperviseur source fige la machine d'origine, envoie les dernières données en écart, et l'hyperviseur cible démarre aussi vite qu'il le peut la nouvelle instance.
On voit vite les limites : Si les processeurs physiques sont différents (instructions étendues différentes par exemple) ça peut coincer. Il y a aussi le lien réseau pas assez capacitaire pour le transfert des données de mémoire et/ou de disque et atteindre le point de syncro, ou également les logiciels intolérants aux micro sauts dans le temps de l'horloge. D'expérience, un serveur Web simple encaisse très bien, mais des bases de données type IBM DB2 d'il y a quelques années supportent beaucoup moins.
VMware semble se débrouiller assez bien, mais c'est un hyperviseur type 2, et les fournisseurs de cloud aussi à priori. Mais il vaut mieux éviter de tenter le diable. D'ailleurs souvent les fournisseurs de cloud imposent l'arrêt des machines lorsqu'on souhaite changer le type de serveur et de processeur dans leur offre, ce qui dans les faits est un changement d'hyperviseur.
# pinaillage proxmox
Posté par steph1978 . Évalué à 2 (+0/-0). Dernière modification le 15 janvier 2025 à 09:52.
Proxmox est un outil de gestion de virtualisation mais pas un hyperviseur.
L'hyperviseur c'est celui du noyeau Linux : KVM. Mais il en gère d'autre.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.