Informatique confidentielle
Merci pour cet article Laurent. Quelques remarques.
Y a-t-il dans ces articles une comparaison des temps de calcul entre une exécution directe sur une vraie machine et sur une machine virtuelle ? Ma propre expérience de réalisation d’une machine virtuelle (pour un interprète LISP) m’a montré que descendre en-dessous d’un facteur 50 ne me paraît pas possible, et atteindre cette limite demande déjà beaucoup de travail. J’aurais aimé savoir si les nouvelles instructions des processeurs conçues pour ce genre d’exécution ont pu réduire significativement cette barrière. J’en doute, surtout avec le surcoût de sécurisation ici décrit, mais je peux me tromper.
Avoir un service informatique privé ou le faire héberger par un prestataire est une vieille question, il serait intéressant d’en faire l’histoire car je crois qu’il y a eu plusieurs tours du balancier à ce sujet. Aujourd’hui le pendule est du côté des hébergeurs, mais je ne serais pas surpris qu’un bon scandale de vol de données finisse par arriver sur l’une de ces plateformes, faisant repartir le pendule de l’autre côté. Pour ma part je reste assez hostile à l’hébergement : j’ai peu confiance d’une part, et le surcoût énergétique est probablement incompatible avec les enjeux climatiques.
Il est dommage que la question de l’énergie consommée soit la plupart du temps omise ou traitée superficiellement. Ce biais est d’ailleurs une raison supplémentaire de se méfier : faire l’impasse sur un sujet qui pourrait ternir l’image, ce n’est pas très honnête.
Les machines virtuelles proposées par les hyperviseurs sont de nature différente des VM proposées par l’environnement Java par exemple. Les instructions en langage machine sont les mêmes que sur la machine hôte, on a simplement un mode non privilégié qui n’a pas accès à l’ensemble des ressources du serveurs, et seules certaines instructions privilégiées (et utilisées par l’OS hébergé) sont émulées.
Ah, merci de cette précision. Si je comprends bien il s’agit moins d’une machine virtuelle que d’un système exploitation virtuel : le code binaire non privilégié est exécuté directement par le processeur, et c’est seulement les instructions privilégiées qui sont émulées, limitant le facteur 50 dont je parlais à ces seules instructions. C’est bien ça ?
Si oui, une fois de plus il faut déplorer que le vocabulaire de l’informatique soit aussi polysémique, pour ne pas dire franchement trompeur.
Si, Emmanuel, c’est bien une machine virtuelle, mais d’une variété différente des machines-langages comme la JVM. Cf. mon article à ce propos :
https://laurentbloch.net/MySpip3/Introduction-aux-machines-virtuelles-255
qui énumère le catalogue de ces variétés, dont “Machines virtuelles pour des langages”.
Merci pour vos précisions à tous les deux, mais je continue à penser que la locution "machine virtuelle" n’est pas adaptée à la technique décrite. Puisqu’une partie des instructions du programme fourni est exécutée directement par le processeur il n’y a pas virtualisation à ce moment, et comme cette partie des instructions est majoritaire, le recours à cette locution est trompeur. Néanmoins je comprends que ma proposition de "système d’exploitation virtuel" est trompeuse d’un autre point de vue, puisque ce ne sont que les dénommés "appels-système" qui sont virtualisés, pas tout le système d’exploitation. Ces appels, dans les systèmes que je connais du moins, étant déclarés dans le dénommé "vecteur d’interruptions", c’est donc lui seul qui doit être qualifié de virtuel. Mais évidement pour M.&Mme ToutleMonde, ce n’est pas très compréhensible.
La clé pour comprendre est peut-être qu’il s’agit ici de "machine virtuelle" et non de "processeur virtuel". En effet une machine virtuelle émule beaucoup de choses (interface réseau, disque, voire affichage...), même si le processeur n’est pas émulé (à l’exception des instructions privilégiées, ce qui n’est pas anodin vu du système d’exploitation).
Je cite "moins d’une machine virtuelle que d’un système exploitation virtuel". On a vraiment une machine virtuelle dans le sens où le système d’exploitation hébergé croit gérer une machine complète.
Les termes "Système virtuel" sont plus adéquats aux approches container/jail... là on fait croire aux applications qu’ils sont seuls sur le système d’exploitation.
Bref, machine virtuelle est un terme bien choisi, même s’il y a plusieurs types d’implémentation (hyperviseur tournant directement sur le matériel - type 1 - ... ou au sein d’un OS - type 2).
Lorsque j’étais responsable du SI de Dauphine, il s’est rapidement avéré que la solution la plus rationnelle pour déployer les applications, c’était une VM par application. L’overhead n’était pas nul, mais tout à fait supportable, en tout cas un facteur nettement inférieur à 2.
Hébergement “on premises” ou chez un prestataire ? En termes de coûts, de sécurité, de qualité de service, sauf cas particuliers, le prestataire extérieur sera meilleur. Mais il y a deux inconvénients : tout prestataire établi aux États-Unis est soumis au Cloud Act et au Patriot Act, ce qui est problématique pour la confidentialité, et selon ceux qui ont essayé changer de prestataire Cloud est très compliqué et onéreux, les prestataires verrouillent leurs clients.
Pour la consommation énergétique, aucune hésitation : la mutualisation des moyens matériels par le Cloud procure des gains considérables par rapport à des centaines de serveurs allumés 24/7/12 pour la plupart du temps ne rien faire.