Théorie générale et archéologie de la virtualisation x86

Présentation

Équipe d'auteurs

Publié par Anton Zhbankov ( AntonVirtual , cloudarchitect.cc )
Co-auteurs: Grigory Pryalukhin , Evgeny Parfenov

Concepts généraux de virtualisation

J'ai dû voir beaucoup d'interprétations de ce qu'est la virtualisation et écouter beaucoup de controverses, pas un peu plus près de discuter du résultat pratique. Et comme vous le savez, l'argument de deux personnes intelligentes se résume à un débat sur les définitions. Définissons ce qu'est la virtualisation et ce qui en découle.

La définition la plus proche de la virtualisation sera probablement «l'abstraction» de la programmation orientée objet. Ou, si traduit en russe normal, cela cache l'implémentation derrière une interface abstraite. Ce qui, bien sûr, expliquait tout à la fois. Réessayons, mais pour ceux qui n'ont pas étudié la programmation.

Virtualisation - cacher une implémentation spécifique derrière une méthode standardisée universelle d'accès aux ressources / données.

Si vous essayez de mettre cette définition en pratique, il s'avère qu'elle fonctionne sur des sujets complètement inattendus. Disons l'horloge. Ainsi, un cadran solaire a été inventé il y a plusieurs milliers d'années, et au Moyen Âge, un cadran mécanique a été inventé. Qu'y a-t-il en commun? Le soleil et quelques engrenages? Une sorte de non-sens. Et puis les oscillateurs à quartz et tout le reste.
L'essentiel est que nous avons une interface standard - un pointeur ou un pointeur numérique, qui sous une forme standard universelle indique l'heure actuelle. Mais est-ce important pour nous de savoir comment ce mécanisme est spécifiquement implémenté à l'intérieur de la boîte, si l'heure est indiquée avec une précision suffisante pour nous?
«Laissez-moi», vous pouvez dire, «mais je pensais que la virtualisation concernait les machines, les processeurs là-bas, etc.!
Oui, il s'agit de voitures et de processeurs, mais ce n'est qu'un cas spécial. Regardons plus largement, puisque l'article revendique hardiment une théorie générale.

POZOR!

Uwaga! Achtung! Pozor!

Cet article a un objectif pédagogique général pour relier un tas de technologies et de mots effrayants avec l'histoire dans une certaine structure, et en raison de cette circonstance contient une quantité importante de simplifications intentionnelles . Bien sûr, il contient également un grand nombre d'omissions ennuyeuses, et même des erreurs ringardes avec des fautes de frappe. Les critiques constructives ne sont que les bienvenues, en particulier sous la forme de "Permettez-moi de vous rappeler cette partie."

Types de virtualisation

Revenons de concepts complètement abstraits aux plus familiers à nos ordinateurs bien-aimés.

Virtualisation du stockage

Le premier, probablement, est le type de virtualisation qu'un geek novice rencontre - la virtualisation d'un système de stockage de données. Dans ce cas, le système de stockage n'est pas utilisé dans le sens d'une grande baie avec des disques connectés via Fibre Channel, mais comme un sous-système logique responsable du stockage de données à long terme.

FS -> LBA -> CHS

Prenez le cas le plus simple d'un système de stockage sur un seul disque magnétique dur. Le format habituel pour travailler avec des données est les fichiers qui se trouvent sur le lecteur logique. Le fichier peut être ouvert, lu, fermé. Mais un objet tel qu'un fichier n'existe tout simplement pas physiquement - il n'y a qu'un moyen d'accéder à certains blocs de données en utilisant la méthode d'adressage du formulaire «lecteur: \ dossier1 \ dossier2 \ fichier». C'est-à-dire nous rencontrons la première couche de virtualisation - du mnémonique et compréhensible aux humains, nous traduisons tout en adresses compréhensibles par le système. Dans les tableaux de métadonnées, le pilote du système de fichiers recherche le type de blocs de données et nous obtenons l'adresse dans le système d'adressage de bloc logique (LBA). Dans le système LBA, les blocs ont une taille fixe et se suivent linéairement, c'est-à-dire d'une manière ou d'une autre, cela peut avoir à voir avec le stockage de données sur bande magnétique, mais le disque dur est en quelque sorte complètement différent! Et nous passons ici à la deuxième couche de virtualisation - traduction de l'adressage LBA en CHS (cylindre / culasse / secteur).



CHS, à son tour, déjà dans le contrôleur de disque dur commence à se traduire en paramètres physiques pour la lecture, mais c'est une histoire complètement différente.
Même dans un accès simple au fichier pour, par exemple, visualiser un vidosik avec des mémos, nous avons rencontré immédiatement trois couches de virtualisation.
Tout serait trop simple si les couches ne commençaient pas à se chevaucher dans un ordre aléatoire et de diverses manières.

RAID

La prochaine couche de virtualisation, que beaucoup de gens ne considèrent pas à tort comme de la virtualisation, est le RAID (matrice redondante de disques peu coûteux / indépendants).

La caractéristique clé du RAID dans le contexte des concepts discutés n'est pas sa capacité à protéger les données contre la défaillance d'un disque physique particulier. RAID fournit un deuxième niveau d'adressage LBA en plus de plusieurs (parfois très nombreuses) adresses LBA indépendantes. Étant donné que nous pouvons accéder au RAID, quel que soit le niveau RAID, exactement de la même manière qu'un seul disque sans RAID, nous pouvons dire avec confiance:

RAID est la virtualisation de disque.

De plus, le contrôleur RAID ne crée pas seulement un grand disque virtuel à partir de plusieurs disques physiques, mais peut en créer un nombre arbitraire en ajoutant une autre couche de virtualisation.

Voir la virtualisation

Le prochain type de virtualisation, que beaucoup d'entre nous utilisent presque tous les jours, mais ne considèrent pas comme une virtualisation, est une connexion à distance au bureau.

Les serveurs de terminaux, VDI et même juste RDP via VPN vers le serveur sont tous des virtualisations de session. En utilisant une interface standard (moniteur, clavier, souris), nous travaillons soit avec une vraie machine, soit avec une conception incompréhensible à partir d'un bureau virtuel sur un clone lié avec une application conteneurisée, à partir de laquelle nous transférons des données via un tampon vers une application avec livraison en streaming. Ou non, qui le découvrira, à part celui qui l'a conçu?

Introduction à la virtualisation x86

Histoire et vue d'ensemble des processeurs

Exécution du programme

Lors de la première leçon d'un cours de programmation spécial, Vladimir Denisovich Lelyukh (repose en paix pour lui) a dit aux élèves: l'ordinateur, malgré son nom, ne peut pas compter, il peut prétendre qu'il peut compter. Mais si quelque chose ressemble à un canard, marche comme un canard et charlatan comme un canard, d'un point de vue pratique, c'est un canard.

Essayons de nous en souvenir pour une utilisation pratique supplémentaire.

L'ordinateur, et en particulier le processeur, ne fait rien - il attend juste certains paramètres d'entrée à certains endroits, puis, à travers une terrible magie noire, donne des résultats à certains endroits.

Un programme dans ce cas est un certain flux de commandes exécutées strictement séquentiellement, à la suite de quoi nous nous attendons à voir un certain résultat.
Mais si le programme est en cours d'exécution, comment les données peuvent-elles être saisies? Et en général, interagissent en quelque sorte sur un ordinateur?

Pour cela, des interruptions matérielles ont été inventées. L'utilisateur appuie sur une touche - le contrôleur du clavier le signale et il y a une interruption dans l'exécution du thread de code actuel. Les adresses des gestionnaires d'interruption sont enregistrées dans une zone de mémoire spécifique, et après avoir enregistré l'état actuel, le contrôle est transféré au gestionnaire d'interruption. À son tour, le gestionnaire devrait, en théorie, tout traiter rapidement, puis lui et le gestionnaire, écrire la touche enfoncée dans le tampon souhaité et retourner le contrôle. Ainsi, l'application semble fonctionner et nous pouvons interagir avec le système.

Les gestionnaires d'interruptions (et les principaux types de gestionnaires sont des pilotes de périphériques) ont la possibilité d'entrer dans un mode processeur spécial, lorsque d'autres interruptions ne peuvent pas être implémentées avant de quitter ce mode. Ce qui au final a souvent conduit à un problème de blocage - une erreur dans le pilote n'a pas permis de sortir de l'interruption.

Multitâche

Que faire dans une situation s'il est nécessaire d'exécuter plusieurs programmes (flux de code avec leurs structures de données et de mémoire) en même temps? Évidemment, s'il y a plus de flux de code que de périphériques capables de les exécuter, c'est un problème.

Le pseudo-multitâche apparaît lorsqu'une tâche est exécutée lors du passage direct à celle-ci.

À l'avenir, une coopérative (multitâche non préemptive) apparaît - la tâche exécutable elle-même comprend qu'elle n'a plus besoin de ressources processeur et donne le contrôle à quelqu'un d'autre. Mais tout cela ne suffit pas.

Et là encore, les interruptions + la capacité de faire semblant viennent à notre secours. Peu importe à l'utilisateur qu'ils soient exécutés strictement simultanément, il suffit de ressembler à ça.
Par conséquent, un gestionnaire est simplement raccroché pour interrompre le temporisateur, qui commence à contrôler le flux de code qui doit être exécuté ensuite. Si le temporisateur est déclenché assez souvent (disons 15 ms), alors pour l'utilisateur, tout ressemble à une opération parallèle. Et donc il y a un multitâche moderne d'éviction.

Mode réel

Le véritable mode processeur dans cet article peut être décrit simplement - toute la mémoire est disponible pour tout le monde. Toute application, y compris les logiciels malveillants (logiciels malveillants, logiciels malveillants), peut accéder n'importe où, à la fois pour la lecture et l'écriture.

Il s'agit du mode de fonctionnement initial de la famille de processeurs Intel x86.

Mode protégé

En 1982, une innovation est apparue dans le processeur Intel 80286 (ci-après simplement 286) - un mode de fonctionnement protégé, qui a apporté des innovations dans l'organisation du travail avec la mémoire (par exemple, l'allocation des types de segments de mémoire - code, données, pile). Mais la chose la plus importante que le processeur 286 a apportée au monde x86 est le concept d'anneaux de protection, que nous utilisons toujours.

Le concept d'anneaux de protection est apparu à l'origine dans le système d'exploitation Multics pour le mainframe GE645 (1967) avec une implémentation partiellement logicielle et entièrement matérielle déjà en 1970 dans le système Honeywell 6180.



L'idée de base des anneaux de défense ressemble à des forteresses médiévales à plusieurs niveaux; la plus précieuse réside au centre même derrière les multiples murs. Dans ce cas, la chose la plus précieuse est un accès direct illimité à n'importe quelle zone de RAM et un contrôle sur tous les processus. Ils sont possédés par des processus opérant dans l'anneau de protection zéro. Derrière le mur, dans le premier anneau, des processus moins importants fonctionnent, tels que les pilotes de périphérique et, dans le dernier, les applications utilisateur. Le principe est simple - de l'intérieur, vous pouvez sortir, mais de l'extérieur vers l'intérieur est interdit. C'est-à-dire aucun processus utilisateur ne peut accéder à la mémoire du noyau du système d'exploitation, comme cela était possible auparavant en mode réel.

Dans la toute première mise en œuvre complète du Honeywell 6180, 8 anneaux de protection ont été mis en œuvre, mais Intel a décidé de simplifier le circuit à 4, dont les fabricants de systèmes d'exploitation ont commencé à n'utiliser que deux, zéro et troisième.

32bit

En 1985, un autre processeur extrêmement important sur le plan architectural de la gamme x86 a été lancé - 80386 (ci-après 386), qui implémentait un adressage mémoire 32 bits et utilisait des instructions 32 bits. Et bien sûr, la virtualisation de la mémoire. Comme déjà mentionné, la virtualisation est la dissimulation de la mise en œuvre réelle par la fourniture de ressources artificielles «virtuelles». Dans ce cas, nous parlons d'adressage mémoire. Le segment de mémoire a son propre adressage, qui n'a rien à voir avec l'emplacement réel des cellules de mémoire.
Le processeur s'est avéré si demandé qu'il a été produit avant 2007.
L'architecture en termes d'Intel s'appelle IA32.

64bit

Bien sûr, même sans virtualisation au milieu des années 2000, l'industrie se heurtait déjà aux limites de 32 bits. Il existe des solutions de contournement partielles sous la forme de PAE (Physical Address Extension), mais elles compliquent et ralentissent le code. La transition vers 64 bits était une fatalité.

AMD a présenté sa version de l'architecture, appelée AMD64. Chez Intel, ils espéraient la plate-forme IA64 (Intel Architecture 64), que nous connaissons également sous le nom d'Itanium. Cependant, le marché a rencontré cette architecture sans grand enthousiasme et, par conséquent, Intel a été contraint d'implémenter son propre support pour les instructions AMD64, qui s'appelait d'abord EM64T, puis juste Intel 64.

En fin de compte, nous connaissons tous cette architecture comme AMD64, x86-64, x86_64 ou parfois x64.

Étant donné que l'utilisation principale des serveurs à l'époque était censée être physique, sans virtualisation, une drôle de technique s'est produite avec les premiers processeurs 64 bits de la virtualisation. Les hyperviseurs imbriqués étaient souvent utilisés comme serveurs de laboratoire; tout le monde ne pouvait pas se permettre plusieurs clusters de serveurs physiques. Et à la fin, il s'est avéré que la machine virtuelle de charge dans l'hyperviseur intégré ne pouvait fonctionner qu'en mode 32 bits.

Dans les premiers processeurs x86-64, les développeurs, tout en conservant une compatibilité totale avec le mode de fonctionnement 32 bits, ont supprimé une partie importante des fonctionnalités en mode 64 bits. Dans ce cas, le problème était de simplifier considérablement la segmentation de la mémoire. La possibilité de garantir l'inviolabilité d'un petit morceau de mémoire dans la machine virtuelle où fonctionnait le gestionnaire d'exceptions de l'hyperviseur a été supprimée. En conséquence, le système d'exploitation invité a pu le modifier.
Par la suite, AMD a renvoyé la possibilité de limiter les segments, et Intel a simplement attendu l'introduction de la virtualisation matérielle.

UMA

Les systèmes multiprocesseurs X86 ont commencé à fonctionner avec le mode UMA (Uniform Memory Access), dans lequel la distance entre tout processeur (retard dans l'accès à une cellule de mémoire) et n'importe quelle barre de mémoire est la même. Dans les processeurs Intel, ce schéma de travail a été conservé même après l'apparition des processeurs multicœurs jusqu'à la génération 54xx (Harpertown). À partir de la génération 55xx (Nehalem), les processeurs sont passés à l'architecture NUMA.

Du point de vue de la logique d'exécution, c'est l'apparition de threads matériels supplémentaires, sur lesquels vous pouvez affecter des flux de code pour une exécution en parallèle.

NUMA

NUMA (Non Uniform Memory Access) - architecture avec un accès inégal à la mémoire. Dans cette architecture, chaque processeur possède sa propre mémoire locale, accessible directement avec une faible latence. La mémoire des autres processeurs est accessible indirectement avec des retards plus élevés, ce qui entraîne une baisse des performances.

Pour les processeurs Intel Xeon Scalable v2 pour 2019, l'architecture interne reste toujours UMA dans le socket, se transformant en NUMA pour les autres sockets (bien que pas vraiment, et cela ne fait que prétendre l'être). Les processeurs Opteron d'AMD avaient une architecture NUMA même à l'époque du plus ancien UMA Xeon, puis NUMA est devenu même à l'intérieur du socket jusqu'à la dernière génération de Rome, dans laquelle ils sont revenus au socket NUMA =.

Machine virtuelle

Machine virtuelle , la plate-forme hôte), ou virtualiser une plate-forme et créer des environnements qui isolent les programmes et même les systèmes d'exploitation les uns des autres. Wikipédia
Dans cet article, nous dirons «machine virtuelle», ce qui signifie «machines virtuelles système», permettant de simuler complètement toutes les ressources et le matériel sous la forme de constructions logicielles.
Il existe deux principaux types de logiciels pour créer des machines virtuelles - avec full et resp. virtualisation incomplète.

La virtualisation complète est une approche dans laquelle tout le matériel, y compris le processeur, est émulé. Vous permet de créer des environnements indépendants du matériel et d'exécuter par exemple le système d'exploitation et les logiciels d'application pour la plate-forme x86 sur les systèmes SPARC, ou les émulateurs Spectrum bien connus avec le processeur Z80 sur le x86 familier. Le revers de la médaille de l'indépendance totale est le surcoût élevé de virtualisation du processeur et les faibles performances globales.

La virtualisation incomplète est une approche dans laquelle pas 100% du matériel est virtualisé. Étant donné que la virtualisation incomplète est la plus courante dans l'industrie, nous en parlerons. A propos des plateformes et technologies des machines virtuelles système à virtualisation incomplète pour l'architecture x86. Dans ce cas, la virtualisation du processeur est incomplète, c'est-à-dire à l'exception de la substitution partielle ou du masquage de certains appels système, le code binaire de la machine virtuelle est exécuté directement par le processeur.

Virtualisation logicielle

La conséquence évidente de l'architecture du processeur et des habitudes des systèmes d'exploitation pour fonctionner dans le ring zéro était le problème - le noyau de l'OS invité ne peut pas fonctionner à l'endroit habituel. L'anneau zéro est occupé par l'hyperviseur, et il suffit de laisser le système d'exploitation invité y arriver également - d'une part, nous sommes revenus en mode réel avec toutes les conséquences, et d'autre part, le système d'exploitation invité n'attend personne là-bas et détruira instantanément toutes les structures de données et abandonnera la voiture.

Mais tout a été décidé tout simplement: puisque pour l'hyperviseur, le système d'exploitation invité n'est qu'un ensemble de pages mémoire avec accès direct complet, et le processeur virtuel n'est qu'une file d'attente de commandes, pourquoi ne pas les réécrire? À la volée, l'hyperviseur rejette de la file d'attente d'instructions à exécuter sur le processeur virtuel toutes les instructions qui nécessitent des privilèges de sonnerie nulle, en les remplaçant par des privilèges moins privilégiés. Mais le résultat de ces instructions est présenté exactement de la même manière que si l'OS invité était dans l'anneau zéro. Ainsi, vous pouvez virtualiser n'importe quoi, jusqu'à l'absence totale d'un OS invité.
Cette approche a été mise en œuvre par l'équipe de développement en 1999 dans le produit VMware Workstation, puis en 2001 dans les hyperviseurs de serveur GSX (le deuxième type, comme Workstation) et ESX (le premier type).

Paravirtualisation

La paravirtualisation est un concept très simple, qui suppose que le système d'exploitation invité sait qu'il se trouve dans une machine virtuelle et sait comment accéder au système d'exploitation hôte pour certaines fonctions du système.Cela élimine le problème d'émulation de l'anneau zéro - le système d'exploitation invité sait qu'il n'est pas dans le zéro et se comporte en conséquence.
La paravirtualisation en x86 est apparue en 2003 avec le projet Linux Xen.

Certaines fonctions paravirtualisées sont également implémentées dans des hyperviseurs avec virtualisation complète via des pilotes virtuels spéciaux dans les OS invités qui communiquent avec l'hyperviseur pour réduire la surcharge de virtualisation. Par exemple, VMware ESXi pour machines virtuelles dispose d'un adaptateur SCSI paravirtuel PVSCSI, qui améliore les performances globales des machines virtuelles avec des opérations de disque intensives, telles que les SGBD chargés. Les pilotes pour les périphériques paravirtuels sont fournis dans des packages supplémentaires (par exemple VMware Tools), ou sont déjà inclus dans les distributions Linux (open-vm-tools).

Virtualisation matérielle

Avec le développement et la croissance de la popularité de la virtualisation, les deux fabricants de plates-formes ont souhaité réduire leurs coûts de support et, d'un point de vue de la sécurité, garantir la protection du matériel.

Le problème a été résolu de manière très simple - les technologies de virtualisation matérielle propriétaires Intel VT-x et AMD-V ont été ajoutées, si nous ignorons les détails techniques approfondis, moins le premier anneau de protection pour l'hyperviseur. Ainsi, la situation de travail dans l'anneau zéro familier à l'OS a finalement été établie.

Types d'hyperviseurs

Type 2 (hébergé)

Les hyperviseurs du deuxième type sont des applications qui s'exécutent sur le système d'exploitation hôte. Tous les appels de machine virtuelle sont gérés par le système d'exploitation hôte en amont. Les hyperviseurs du deuxième type ont des performances très limitées, car l'application de l'hyperviseur, n'ayant pas le droit à l'allocation exclusive de ressources informatiques, est obligée de rivaliser pour eux avec d'autres applications utilisateur. En termes de sécurité, les hyperviseurs de type 2 dépendent directement des politiques de sécurité de l'OS utilisateur et de sa vulnérabilité aux attaques. Aujourd'hui, il existe une opinion unanime dans l'industrie selon laquelle de telles plates-formes de virtualisation au niveau de l'entreprise ne conviennent pas. Cependant, ils sont bien adaptés au développement multiplateforme et au déploiement de stands directement sur les machines des développeurs de logiciels, car ils sont faciles à gérer et à déployer.

Exemples du deuxième type d'hyperviseur: VMware Workstation / Fusion, Oracle VM VirtualBox, Parallels Desktop, VMware Server (ex-GSX), Microsoft Virtual Server 2005

Type 1 (métal nu)

Les hyperviseurs du premier type ne nécessitent pas de système d'exploitation à usage général, contrairement aux précédents. L'hyperviseur lui-même est un monolithe qui contrôle à la fois l'allocation des ressources informatiques et les E / S. Dans l'anneau de sécurité zéro, il y a un microcœur, au-dessus duquel toutes les structures de contrôle fonctionnent. Dans cette architecture, l'hyperviseur contrôle la distribution des ressources informatiques et contrôle lui-même tous les appels des machines virtuelles aux appareils. VMware ESX était considéré comme le premier hyperviseur du premier type pour x86 depuis longtemps, bien que maintenant nous l'attribuions à 1+. Le seul représentant «honnête» de ce type aujourd'hui est VMware ESXi - le successeur d'ESX, après avoir été mordu de la section parent avec RHEL.

Par exemple, considérez l'architecture ESXi. Les commandes de gestion d'hyperviseur sont exécutées via l'API d'agent, qui s'exécute au-dessus de VMkernel. Cela peut sembler être une connexion directe à l'hyperviseur, mais ce n'est pas le cas. Il n'y a pas d'accès direct à l'hyperviseur, ce qui distingue ce type d'hyperviseur du deuxième type d'hyperviseur en termes de sécurité.



L'inconvénient est ici les pilotes de périphériques: pour assurer la «finesse» de la plateforme et éliminer les complications inutiles de version en version, les pilotes de périphériques sont tournés, ce qui rend l'infrastructure physique dépendante de HCL (liste de compatibilité matérielle).

Type 1+ (hyperviseur hybride)

Les hyperviseurs de type hybride (alias 1+, 1a, 1.5) sont caractérisés par l'isolement du système d'exploitation de base dans une entité spéciale appelée la partition parent (partition parent dans la terminologie Microsoft Hyper-V) ou le domaine parent (domaine dom0 dans la terminologie Xen). Ainsi, après avoir installé le rôle de l'hyperviseur, le noyau passe en mode de prise en charge de la virtualisation et l'hyperviseur est responsable de l'allocation des ressources sur l'hôte. Mais la section parent prend en charge la fonction de traitement des appels aux pilotes de périphérique et des opérations d'E / S.

En fait, la section parent devient une sorte de fournisseur entre toutes les entités de la pile de virtualisation. Cette approche est pratique du point de vue de la compatibilité avec les équipements: vous n'avez pas besoin d'incorporer des pilotes de périphériques dans l'hyperviseur, comme c'est le cas avec ESXi, ce qui signifie que la liste des périphériques est beaucoup plus étendue et dépend moins de HCL. Les avantages incluent le déchargement de l'hyperviseur de la tâche de traitement des appels aux pilotes de périphérique, car tous les appels sont traités par la section parent.

L'architecture de niveau supérieur des hyperviseurs de type 1+ ressemble à ceci:



Les hyperviseurs de ce type incluent: les hyperviseurs VMware ESX, Microsoft Hyper-V, Xen décédés (implémentations Citrix XenServer et Xen dans diverses distributions Linux). Rappelons que Citrix XenServer est un système d'exploitation RHEL légèrement tronqué, et que sa version et ses fonctionnalités dépendent directement de la version actuelle de Red-Hat Enterprise Linux. Dans le cas d'autres implémentations Xen, la situation n'est pas très différente: il s'agit du même noyau Linux en mode hyperviseur Xen et du système d'exploitation de base dans le domaine dom0. Cela conduit à la conclusion sans ambiguïté que les hyperviseurs à base de Xen sont de type hybride et ne sont pas des hyperviseurs honnêtes de type 1.

Principales technologies des plateformes industrielles

La base sera prise par la terminologie de VMware, en tant que plate-forme de virtualisation la plus avancée technologiquement. Dans cet article, nous nous limitons aux technologies des hyperviseurs eux-mêmes et du système de contrôle de base. Toutes les fonctionnalités avancées mises en œuvre par des produits supplémentaires pour de l'argent supplémentaire seront laissées en coulisses. Les technologies sont regroupées en groupes conditionnels dans le but principal, comme il semble à l'auteur, avec qui vous avez le droit d'être en désaccord.

SLA

Il s'agit d'un ensemble de technologies qui affectent principalement les performances des SLA pour l'accessibilité (RPO / RTO).

HA

Haute disponibilité - une technologie pour assurer la haute disponibilité des machines virtuelles dans un cluster par un hyperviseur. En cas de décès d'un hôte, la machine virtuelle redémarre automatiquement sur les hôtes survivants. Effet: minimisation du RTO avant l'expiration de HA + redémarrage OS / services.

FT

Fault Tolerance - technologie pour assurer un fonctionnement continu des machines virtuelles même en cas de décès de l'hôte. Une machine virtuelle fantôme est créée sur le deuxième hôte, qui est complètement identique à la principale et répète les instructions derrière. Ainsi, la différence dans les états de VM est mesurée en dizaines ou centaines de millisecondes, ce qui est tout à fait acceptable pour de nombreux services. Lorsque l'hôte meurt, l'exécution passe automatiquement à la machine virtuelle fantôme. Effet: minimiser le RTO à zéro.

Tco

Il s'agit d'un ensemble de technologies qui influencent principalement le TCO.

vMotion

vMotion est une technologie de migration en direct d'un point d'exécution de machine virtuelle d'un hôte entièrement fonctionnel à un autre. Dans le même temps, le point de commutation du point d'exécution est inférieur aux délais d'expiration de la connexion réseau, ce qui nous permet de considérer la migration comme live, c'est-à-dire sans interruption dans le travail des services productifs. Effet: réduction du RTO à zéro pour les pannes planifiées pour la maintenance du serveur et, par conséquent, élimination partielle des pannes elles-mêmes.

Storage vMotion

Storage vMotion est une technologie pour la migration en direct d'un point de stockage VM d'un stockage entièrement fonctionnel à un autre. Dans le même temps, le travail avec le système de disques ne s'arrête pas, ce qui permet de considérer la migration comme active. Effet: réduction du RTO à zéro pour les pannes planifiées pour la maintenance du stockage et, par conséquent, élimination partielle des pannes elles-mêmes.

DPM

Distributed Power Management - technologie pour contrôler le niveau de charge de l'hôte et la mise sous / hors tension des hôtes à mesure que la charge du cluster change. Nécessite DRS pour son fonctionnement. Effet: réduction globale de la consommation d'énergie.

VSwitch distribué

VSwitch distribué est une technologie de gestion centralisée des paramètres réseau des commutateurs d'hôte virtuel. Effet: réduction du volume et de la complexité du travail de reconfiguration du sous-système réseau, réduction des risques d'erreurs.

EVC

La compatibilité vMotion améliorée est une technologie qui permet de masquer les instructions de processeur disponibles pour les machines virtuelles en mode automatique. Il est utilisé pour aligner le travail des machines virtuelles dans un cluster inégal avec la plus ancienne famille de processeurs, offrant la possibilité de migrer des machines virtuelles vers n'importe quel hôte. Effet: économie sur la complexité de l'infrastructure tout en augmentant progressivement la capacité / mise à niveau partielle des clusters.

QoS

Il s'agit d'un ensemble de technologies qui influencent principalement les performances du SLA en termes de qualité de service.

vNUMA

vNUMA est une technologie qui permet au système d'exploitation invité de communiquer avec la topologie NUMA virtuelle de la machine virtuelle pour les machines larges (vCPU ou vRAM> nœud NUMA). Effet: L'absence de pénalité sur les performances des logiciels d'application prenant en charge NUMA.

Pool de ressources

Pools de ressources - la technologie consistant à combiner plusieurs machines virtuelles en un seul pool de ressources pour contrôler la consommation ou garantir l'allocation des ressources. Effet: simplifier l'administration, fournir un niveau de service.

Limite / réserve

La limitation / redondance du processeur / mémoire vous permet de limiter l'allocation des ressources, ou inversement, pour garantir leur allocation en situation de rareté et de concurrence pour assurer la maintenance des VM / pools prioritaires.

DRS

Dynamic Resource Scheduler - équilibrage automatique des machines virtuelles par les hôtes en fonction de la charge pour réduire la fragmentation des ressources dans le cluster et fournir un niveau de service pour les machines virtuelles. Nécessite le support de vMotion.

Contrôle d'E / S de stockage

Le contrôle d'E / S de stockage est une technologie qui limite le «voisin bruyant», une machine à faible priorité avec une charge de disque élevée pour maintenir les performances d'un système de stockage coûteux disponibles pour des charges de travail productives. A titre d'exemple, un système d'indexation / moteur de recherche interne et un SGBD productif.

Contrôle d'E / S réseau

Network IO Control est une technologie pour limiter le «voisin bruyant», une machine à faible priorité avec une charge réseau élevée.

Intégration de stockage (VAAI, etc.)

Deux catégories de technologies entrent dans la section d'intégration:

• L'intégration du système de gestion de la virtualisation avec le système de gestion du stockage peut grandement simplifier la sélection et la présentation des volumes / ballons de stockage aux hyperviseurs, réduisant le risque d'erreurs et la complexité du travail.
• Intégration au niveau du protocole - VAAI, ODX. Ces technologies vous permettent de décharger le sous-système de disque, transférant une partie de la charge standard à l'élimination du stockage intelligent. Par exemple, cette catégorie comprend des opérations telles que la mise à zéro des blocs, le clonage de machines virtuelles, etc. De ce fait, le canal vers le système de stockage est considérablement déchargé et le système de stockage lui-même effectue les opérations sur disque de manière plus optimale.

La sécurité

Microsegmentation

La microsegmentation d'un réseau virtuel en pratique est la possibilité de construire un pare-feu distribué virtuel qui contrôle les réseaux virtuels à l'intérieur de l'hôte. Améliore considérablement la sécurité du réseau virtuel.

AV sans agent

La technologie prend en charge les antivirus sans agent. Au lieu d'être vérifié par des agents dans le système d'exploitation invité, le trafic des opérations de disque de la machine virtuelle est dirigé par l'hyperviseur vers la machine virtuelle de service sélectionnée. Réduit considérablement la charge sur les processeurs et le système de disques, tuant ainsi efficacement les «tempêtes antivirus».

Systèmes hyper convergés

Les systèmes convergents, comme leur nom l'indique, sont des systèmes avec une combinaison de fonctions. Et dans ce cas, nous entendons la combinaison du stockage et de l'exécution de la VM. Cela semble simple, mais le marketing fait soudainement irruption.

Pour la première fois avec le terme systèmes convergents, les spécialistes du marketing font irruption sur le marché. Les systèmes convergents vendaient des serveurs classiques classiques + stockage + commutateurs. Un peu moins d'un numéro de partenaire. Ou ils ne vendaient même pas, mais un document intitulé «architecture de référence» a été produit. Nous condamnons sincèrement cette approche et passons à la considération architecturale.

L'architecture

En gardant la convergence comme principe architectural, nous obtenons une combinaison du point de stockage et du point d'exécution de la VM dans un seul système.

L'architecture convergente, en d'autres termes, implique l'utilisation des mêmes services matériels à la fois pour exécuter des machines virtuelles et pour les stocker sur des disques locaux. Eh bien, puisqu'il devrait y avoir une tolérance aux pannes - dans une architecture convergente, il y a une couche de SDS distribués.

Nous obtenons:

• Le système classique - les logiciels, le stockage, la commutation et les serveurs proviennent de différents endroits, combinés par les mains du client / intégrateur. Contrats de support séparés.
• Système convergé - le tout à partir d'une seule source, d'un seul support, d'un seul numéro de partenaire. À ne pas confondre avec l'auto-assemblage d'un fournisseur.

Et il s'avère que le terme de notre architecture convergente est déjà pris. Exactement la même situation qu'avec le superviseur.

Système hyperconvergé - Un système convergé avec une architecture convergente.
Bien sûr, ce ne fut pas sans la seconde venue des spécialistes du marketing. Des systèmes convergents sont apparus dans lesquels il n'y avait pas de combinaison de stockage, mais il existe des nœuds de stockage dédiés sous le contrôle de SDS distribués. Dans le cadre des guerres de commercialisation, même le terme spécial HCI désagrégé (infrastructure hypervergénique désagrégée) est apparu. En particulier, par exemple, NetApp avec un système similaire s'est d'abord battu assez intensément pour le droit d'appeler son système hyper-convergent, mais s'est finalement rendu. NetApp HCI aujourd'hui (fin 2019) - infrastructure cloud hybride.

Options d'implémentation

Étant donné que les systèmes hyperconvergés fonctionnent avec la virtualisation, il existe en fait deux options et demie pour la mise en œuvre.

• 1. Le module du noyau. SDS fonctionne comme un monolithe au cœur de l'hyperviseur, par exemple vSAN + ESXi
• 1.5 Module de section parent. SDS fonctionne comme un service dans le cadre de la section parent de l'hyperviseur, par exemple S2D + Hyper-V
• 2. La machine virtuelle. SDS est implémenté en tant que machine virtuelle dédiée sur chaque hôte. Nutanix, Cisco Hyperflex, HPE Simplivity.

De toute évidence, en plus des problèmes abordés concernant l'effet de l'intégration sur les performances, il existe un problème très important d'isolement et de prise en charge des hyperviseurs tiers. Dans le cas 1, il est évident qu'il ne peut s'agir que d'un seul système du fournisseur de l'hyperviseur, tandis que 2 peut potentiellement fonctionner dans n'importe quel hyperviseur.

Conteneurs

La virtualisation conteneurisée, bien que techniquement très différente de la virtualisation complète, a une structure assez simple. Comme pour le modèle de réseau OSI, la question est de niveau. La virtualisation des conteneurs est un niveau supérieur - au niveau de l'environnement d'application, et non au niveau physique.

La tâche principale de la virtualisation de conteneurs est de diviser le système d'exploitation en éléments indépendants, à partir desquels les applications isolées ne peuvent pas interférer les unes avec les autres. La virtualisation complète n'est pas partagée par le système d'exploitation, mais par un serveur physique.

VM vs Container

Les avantages et les inconvénients des deux approches sont assez simples et directement opposés.

La virtualisation complète (VM) donne une indépendance totale au niveau du fer, y compris des piles de système d'exploitation, de disque et de réseau entièrement indépendantes. D'un autre côté, chaque application, parce que nous adhérons au schéma 1 application = 1 serveur, nécessite son propre système d'exploitation, son propre disque et sa propre pile réseau. c'est-à-dire il y a une dépense multiple de ressources.

Les conteneurs ont des piles de disque et de réseau communes avec le système d'exploitation hôte, et tous ensemble, ils utilisent un cœur sur l'ensemble du serveur physique (enfin, ou virtuel, récemment), ce qui dans son ensemble vous permet d'économiser de manière assez significative les ressources sur des paysages homogènes.

Historiquement, x86 avait initialement des conteneurs pour tout, ainsi que des serveurs physiques. Après l'avènement de la virtualisation complète, l'importance des conteneurs a chuté de près de 15 ans, et les machines virtuelles épaisses ont régné dans le monde de l'entreprise. À cette époque, les conteneurs se sont retrouvés chez des hébergeurs qui fournissaient des centaines de serveurs Web du même type, où leur légèreté était recherchée. Mais ces dernières années, depuis environ 2015, les conteneurs sont revenus à la réalité d'entreprise sous la forme d'applications natives du cloud.

Conteneurs 0,1

chroot

Le prototype de conteneurs en 1979 était chroot.

«Chroot consiste à changer le répertoire racine sur les systèmes d'exploitation de type Unix. Un programme lancé avec un répertoire racine modifié n'aura accès qu'aux fichiers contenus dans ce répertoire. »

C'est-à-dire en fait, l'isolement se fait uniquement au niveau du système de fichiers, sinon ce n'est qu'un processus normal dans le système d'exploitation.

La prison de Freebsd

La prison de BSD gratuite, apparue en 1999, était beaucoup plus avancée. La prison vous a permis de créer des instances de système d'exploitation virtuel à part entière avec leurs propres ensembles d'applications et de fichiers de configuration basés sur FreeBSD de base. Il y a sûrement ceux qui disent - et que fait la prison dans des conteneurs, parce que c'est la paravirtualisation! Et ils auront partiellement raison.

Cependant, avant la virtualisation complète (et sa variante sous forme de paravirtualisation), la prison n'a pas la possibilité d'exécuter le noyau d'une version différente dans la machine virtuelle invitée et le clustering avec la migration de la machine virtuelle vers un autre système hôte.

Zones Solaris

Solaris Zones est une technologie de virtualisation de système d'exploitation (virtualisation de conteneurs), introduite en 2004 dans Sun Solaris. Le principe de base est une faible surcharge de virtualisation.

Ne gagne pas beaucoup de popularité, migré vers OpenSolaris et les distributions basées sur celui-ci, disponible en 2019.

Containers 1.0

À l'ère des conteneurs 1.0, deux directions principales de la conteneurisation sont apparues - ce sont les produits commerciaux pour les hébergeurs et la conteneurisation des applications.

Virtuozzo / OpenVZ

Russian SWsoft a présenté en 2001 sa première version de virtualisation de conteneurs Virtuozzo, destinée au marché des hébergeurs. En raison de la détermination et du public cible spécifique, le produit s'est avéré être un succès et a gagné en popularité. Technologiquement, en 2002, le fonctionnement simultané de 2500 conteneurs sur un serveur à 8 processeurs a été démontré.

En 2005, une version ouverte des conteneurs Virtuozzo pour Linux appelée OpenVZ est apparue. Et est presque devenu l'étalon-or pour l'hébergement de VPS.

Lxc

LinuX Containers (LXC) est une autre virtualisation de conteneurs bien connue basée sur des espaces de noms et des groupes de contrôle, qui est apparue en 2008. Elle sous-tend les dockers actuellement populaires, etc.

Containers 1.1 (Application Virtualization)

Si le reste des conteneurs est conçu pour diviser l'OS de base en segments, alors pourquoi ne pas arracher cette couche du système et l'emballer dans une seule boîte avec l'application et avec tout son environnement. Et puis, ce package prêt à l'emploi peut être lancé en tant qu'application de niveau utilisateur standard.

App-v

Microsoft Application Virtualization (App-V), anciennement Softricity SoftGrid - technologie de conteneurisation d'applications spécifiques (le conteneur est l'inverse) dans un bac à sable isolé, puis Microsoft. En 2006, Microsoft a acquis la startup Softricity, qui a en fait transformé le conteneur.

Thinapp

VMware ThinApp (anciennement Thinstall) est un produit de conteneurisation d'applications de Jilt acquis par VMware en 2008. VMware estime que 90 à 95% de toutes les applications packagées dans le monde utilisent cette technologie.

Conteneurs 2.0

L'histoire de l'émergence des conteneurs 2.0 est très associée à un changement dans le processus de développement logiciel. Le désir de l'entreprise de réduire un paramètre aussi important que le délai de mise sur le marché a contraint les développeurs à reconsidérer leurs approches de création de produits logiciels. La méthodologie de développement Waterfall (longs cycles de publication, toute l'application est mise à jour) est remplacée par Agile (courts cycles de publication à durée fixe, les composants de l'application sont mis à jour indépendamment) et oblige les développeurs à séparer les applications monolithiques en composants. Alors que les composants des applications monolithiques sont encore assez volumineux et peu nombreux peuvent être placés dans des machines virtuelles, mais lorsqu'une application est constituée de dizaines ou de centaines de composants, les machines virtuelles ne sont plus très adaptées. En outre, le problème des versions de logiciels auxiliaires, des bibliothèques et des dépendances se pose également, il arrive souvent que différents composants nécessitent des versions différentes ou des variables d'environnement configurées différemment. Ces composants doivent être distribués sur différentes machines virtuelles, car il est presque impossible d'exécuter simultanément plusieurs versions de logiciels dans le même système d'exploitation. Le nombre de VM commence à croître comme une avalanche. Ici, des conteneurs apparaissent sur la scène, permettant dans le cadre d'un OS invité de créer plusieurs environnements isolés pour lancer des composants d'application. La conteneurisation des applications vous permet de continuer à segmenter une application monolithique en composants encore plus petits et de passer au paradigme d'une tâche = un composant - un conteneur, c'est ce qu'on appelle une approche de microservice, et chacun de ces composants est un microservice.

Conteneur sous le capot

Si vous regardez le conteneur avec un coup d'œil de l'administrateur système, ce ne sont que des processus Linux qui ont leurs propres pids, etc. Qu'est-ce qui permet d'isoler les processus s'exécutant dans des conteneurs les uns des autres et de consommer ensemble les ressources de l'OS invité? Deux mécanismes standard présents dans le noyau de toute distribution Linux moderne. Le premier, Linux Namespaces, qui garantit que chaque processus voit sa propre représentation du système d'exploitation (système de fichiers, interfaces réseau, nom d'hôte, etc.) et le second, Linux Control Groups (cgroups), limitant le processus à la consommation des ressources du système d'exploitation invité (CPU, mémoire bande passante réseau, etc.).

Espaces de noms Linux

Par défaut, chaque système Linux contient un seul espace de noms. Toutes les ressources système, telles que les systèmes de fichiers, les identifiants de processus (ID de processus), les identifiants d'utilisateur (ID d'utilisateur), les interfaces réseau appartiennent à cet espace de noms. Mais personne ne nous empêche de créer des espaces de noms supplémentaires et de redistribuer les ressources système entre eux.

Lorsqu'un nouveau processus démarre, il démarre dans un espace de noms, standard du système ou l'un des créés. Et ce processus ne verra que les ressources disponibles dans l'espace de noms utilisé pour l'exécuter.

Mais tout n'est pas si simple, chaque processus n'appartient pas à un seul espace de noms, mais à un espace de noms dans chacune des catégories:

• Mont (mnt)
• ID de processus (pid)
• Réseau (net)
• Communication inter-processus (ipc)
• UTS
• ID utilisateur (utilisateur)

Chaque type d'espace de noms isole un groupe de ressources correspondant. Par exemple, l'espace UTS définit le nom d'hôte et le nom de domaine visibles par les processus. Ainsi, deux processus au sein du système d'exploitation invité peuvent supposer qu'ils s'exécutent sur des serveurs différents.

L'espace de noms réseau détermine la visibilité des interfaces réseau, le processus à l'intérieur ne verra que les interfaces appartenant à cet espace de noms.

Groupes de contrôle Linux (cgroups)

Les groupes de contrôle Linux (cgroups) sont le mécanisme du système du noyau (noyau) des systèmes Linux qui limite la consommation des ressources système par les processus. Chaque processus ou groupe de processus ne pourra pas obtenir plus de ressources (CPU, mémoire, bande passante réseau, etc.) qu'il n'est alloué et ne pourra pas capturer les "autres" ressources - les ressources des processus voisins.

Docker

Comme indiqué ci-dessus, Docker n'a pas inventé les conteneurs en tant que tels. Les conteneurs existent depuis de nombreuses années (y compris ceux basés sur LXC), mais Docker les a rendus très populaires en créant le premier système qui facilitait et simplifiait le transfert de conteneurs entre différentes machines. Docker a créé un outil pour créer des conteneurs - empaqueter l'application et ses dépendances, et exécuter des conteneurs sur n'importe quel système Linux avec Docker installé.

Une caractéristique importante de Docker est la portabilité non seulement de l'application elle-même et de ses dépendances entre des distributions Linux complètement différentes, mais également la portabilité de l'environnement et du système de fichiers. Par exemple, un conteneur créé sur CentOS peut être exécuté sur un système Ubuntu. Dans ce cas, à l'intérieur du conteneur lancé, le système de fichiers sera hérité de CentOS et l'application considérera qu'il s'exécute au-dessus de CentOS. Ceci est quelque peu similaire à une image OVF d'une machine virtuelle, mais le concept d'une image Docker utilise des couches. Cela signifie que lors de la mise à jour d'une partie seulement de l'image, il n'est pas nécessaire de télécharger à nouveau l'image entière, il suffit de télécharger uniquement la couche modifiée, comme si l'image OVF pouvait mettre à jour le système d'exploitation sans mettre à jour l'image entière.

Docker a créé un écosystème pour créer, stocker, transférer et lancer des conteneurs. Le monde Docker comprend trois composants clés:

• Images - une image, c'est l'entité qui contient votre application, l'environnement nécessaire et d'autres métadonnées nécessaires pour lancer le conteneur;
• Registres - référentiel, lieu de stockage pour les images Docker. Il existe une variété de référentiels, allant du site officiel - hub.docker.com et se terminant par des répertoires privés déployés dans l'infrastructure de l'entreprise;
• Conteneurs - un conteneur, un conteneur Linux créé à partir d'une image Docker. Comme mentionné ci-dessus, il s'agit d'un processus Linux exécuté sur un système Linux avec Docker installé, isolé des autres processus et du système d'exploitation lui-même.

Tenez compte du cycle de vie des conteneurs. Initialement, un développeur crée une image Docker avec son application (la commande de construction Docker), complètement à partir de zéro ou en utilisant des images déjà créées comme base (rappelez-vous des calques). De plus, cette image peut être lancée par le développeur directement sur sa propre machine ou peut être transférée sur une autre machine - le serveur. Pour la portabilité, les référentiels sont souvent utilisés (la commande push du docker) - ils chargent l'image dans le référentiel. Après cela, l'image peut être téléchargée sur n'importe quelle autre machine ou serveur (docker pull). Enfin, créez un conteneur de travail (docker run) à partir de cette image.

Kubernetes

Comme nous l'avons déjà dit, le concept de microservices signifie diviser une application monolithique en de nombreux petits services, exécutant généralement une seule fonction. Eh bien, lorsqu'il existe des dizaines de ces services, ils peuvent toujours être gérés manuellement via, par exemple, Docker. Mais que faire quand il existe des centaines et des milliers de tels services? En plus de l'environnement industriel, vous avez besoin d'un environnement de test et d'environnements supplémentaires pour différentes versions du produit, c'est-à-dire multipliez par 2, par 3 ou même plus. Google a également été confronté aux mêmes problèmes, ses ingénieurs ont été l'un des premiers à utiliser des conteneurs à l'échelle industrielle. C'est ainsi que Kubernetes (K8s) est né, créé sous le nom de Borg dans les murs du produit Google, plus tard donné au grand public et renommé.

K8s est un système qui facilite le déploiement, la gestion et la surveillance des applications conteneurisées (microservices). Comme nous le savons déjà, n'importe quelle machine Linux convient pour lancer des conteneurs et les conteneurs sont isolés les uns des autres, respectivement, et les K8 peuvent gérer différents serveurs avec un matériel différent et sous le contrôle de différentes distributions Linux. Tout cela nous aide à utiliser efficacement le matériel disponible. Comme la virtualisation, K8s nous fournit un pool commun de ressources pour le lancement, la gestion et la surveillance de nos microservices.

Étant donné que cet article est principalement destiné aux ingénieurs de virtualisation, pour une compréhension générale des principes de fonctionnement et des principaux composants des K8, nous vous recommandons de lire l'article qui établit le parallèle entre K8 et VMware vSphere: https://medium.com/@pryalukhin/kubernetes-introduction-for-vmware- users-232cc2f69c58

Historique de la virtualisation industrielle X86

VMware

VMware est apparu en 1998, en commençant par le développement d'un deuxième type d'hyperviseur, qui est devenu plus tard VMware Workstation.

La société est entrée sur le marché des serveurs en 2001 avec deux hyperviseurs - GSX (Ground Storm X, deuxième type) et ESX (Elastic Sky X, premier type). Au fil du temps, les perspectives du deuxième type dans les applications serveur sont devenues évidentes, à savoir Aucun. Et le GSX payant a d'abord été transformé en serveur VMware gratuit, puis complètement arrêté et enterré.

En 2003, le système de gestion central de Virtual Center, la technologie vSMP et la migration en direct des machines virtuelles sont apparus.

En 2004, VMware a été acquis par EMC, un géant du stockage, mais est resté opérationnel indépendant.

En 2008, devenant la norme de facto de l'industrie, VMware a stimulé la croissance rapide des offres concurrentielles - Citrix, Microsoft, etc. Il devient clair qu'il était nécessaire d'obtenir une version gratuite de l'hyperviseur, ce qui était impossible - car une section parent d'ESX utilisait un RHEL entièrement commercial. Le projet de remplacement de RHEL par quelque chose de plus simple et gratuit a été mis en œuvre en 2008 avec le système busybox. Le résultat est ESXi, connu de tous aujourd'hui.

En parallèle, l'entreprise se développe à travers des projets internes et des acquisitions de startups. Il y a quelques années, la liste des produits VMware occupait quelques pages A4, alors disons simplement. VMware pour 2019 est toujours la norme de facto sur le marché de la virtualisation complète d'entreprise sur site avec une part de marché de plus de 70% et un leader technologique absolu, et un examen détaillé de l'histoire mérite un article très volumineux.

Connectix

Fondée en 1988, Connectix a travaillé sur une variété d'utilitaires système jusqu'à la virtualisation. En 1997, le premier produit VirtualPC pour Apple Macintosh a été créé, permettant à Windows de s'exécuter sur une machine virtuelle. La première version de VirtualPC pour Windows est apparue en 2001.

En 2003, Microsoft a acheté VirtualPC et, en accord avec Connectix, les développeurs sont passés à Microsoft. Après cela, Connectix a fermé.

Le format VHD (disque dur virtuel) a été développé par Connectix pour VirtualPC, et pour rappel, les disques virtuels des machines Hyper-V contiennent «conectix» dans leur signature.
VIrtual PC, comme vous pouvez le deviner, est un hyperviseur de bureau classique du deuxième type.

Microsoft

L'aventure de Microsoft dans la virtualisation industrielle a commencé avec l'achat de Connectix et le changement de marque de Connectix Virtual PC dans Microsoft Virtual PC 2004. Virtual PC développé pendant un certain temps, a été inclus sous le nom Windows Virtual PC dans Windows 7. Dans Windows 8 et versions ultérieures, Virtual PC a été remplacé par version de bureau d'Hyper-V.

Basé sur Virtual PC, l'hyperviseur du serveur Virtual Server a été créé, qui existait jusqu'au début de 2008. En raison de la perte technologique évidente avant VMware ESX, il a été décidé de limiter le développement du deuxième type d'hyperviseur au profit de son propre premier type d'hyperviseur, qui est devenu Hyper-V. Il existe une opinion non officielle dans l'industrie selon laquelle Hyper-V est étonnamment similaire à Xen en architecture. Identique à .Net en Java.

"Bien sûr, vous pourriez penser que Microsoft a volé l'idée de Java." Mais ce n'est pas vrai, Microsoft l'a inspirée! - (extrait d'un discours prononcé par un représentant de Microsoft lors de la présentation de Windows 2003 Server)

À partir des moments curieux, on peut noter qu'à l'intérieur de Microsoft, l'utilisation de produits de virtualisation propriétaires au cours des années zéro était, pour le moins, facultative. Il y a des captures d'écran de Technet à partir d'articles sur la virtualisation, où le logo VMware Tools est clairement présent dans la barre d'état. En outre, Mark Russinovich sur la plateforme 2009 à Moscou a effectué une démonstration avec VMware Workstation.

Afin de pénétrer de nouveaux marchés, Microsoft a créé son propre cloud public, Azure, en utilisant un serveur Nano hautement modifié avec prise en charge Hyper-V, S2D et SDN comme plate-forme. Il convient de noter qu'au départ, Azure était à certains moments loin derrière les systèmes sur site. Par exemple, la prise en charge des machines virtuelles de deuxième génération (avec prise en charge du démarrage sécurisé, du démarrage à partir des partitions GPT, du démarrage PXE, etc.) n'est apparue dans Azure qu'en 2018. En local, les machines virtuelles de deuxième génération sont connues depuis Windows Server 2012R2. Il en va de même pour les solutions de portail: jusqu'en 2017, Azure et le Windows Azure Pack (solution cloud multi-tenancy avec prise en charge SDN et VM blindée, qui a remplacé System Center App Controller en 2013) ont utilisé la même conception de portail. Après que Microsoft a annoncé un cours sur les clouds publics, Azure s'est avancé pour développer et implémenter divers savoir-faire. Autour de l'année 2016, vous pouvez observer une image tout à fait logique: maintenant toutes les innovations de Windows Server viennent d'Azure, mais pas dans la direction opposée. Le fait de copier des parties de la documentation d'Azure vers sur site "en l'état" l'indique (voir la documentation sur Azure SDN et le contrôleur de réseau), qui d'une part fait allusion à l'attitude vis-à-vis des solutions sur site, et d'autre part, indique la relation des solutions en termes d'entités et d'architecture. Qui a copié de qui et comment c'est vraiment - une question discutable.

En mars 2018, Satya Nadela (PDG de Microsoft) a officiellement annoncé que le cloud public devenait la priorité de l'entreprise. Ce qui, évidemment, symbolise le pliage et la décoloration graduels de la gamme de serveurs pour les produits sur site (cependant, une stagnation a été observée en 2016, mais a été confirmée avec la première version bêta de Windows Server et d'autres gammes de produits sur site), à ​​l'exception d'Azure Edge - le serveur minimum requis Infrastructure dans le bureau du client pour des services qui ne peuvent pas être transférés vers le cloud.

Fer virtuel

Fondé en 2003, Virtual Iron a offert une version commerciale de Xen et a été l'un des premiers à offrir au marché une prise en charge complète de la virtualisation matérielle.
En 2009, Oracle a été repris pour développer sa propre ligne de virtualisation Oracle VM et l'étendre sur x86. Auparavant, Oracle VM n'était proposé que sur la plate-forme SPARC.

Innotek

Début 2007, Innotek GmbH a commercialisé l'hyperviseur de bureau propriétaire de deuxième type, VirtualBox, qui est gratuit pour une utilisation non commerciale. La même année, une version open source est sortie.

En 2008, il a été acquis par Sun, qui à son tour a été acquis par Oracle. Oracle a maintenu l'utilisation gratuite du produit à des fins non commerciales.
VirtualBox prend en charge trois formats de disques virtuels - VDI (natif), VMDK (VMware), VHD (Microsoft). En tant qu'OS hôte, Windows, macOS, Linux, Solaris et OpenSolaris sont pris en charge. Le fork de VirtualBox pour FreeBSD est connu.

Ibm

Le mainframe est l'ordinateur principal du centre de données avec une grande quantité de mémoire interne et externe (pour référence: dans les années 60, 1 Mo de mémoire était considéré comme irréaliste). En fait, l'ordinateur central était un centre de calcul: les premiers ordinateurs occupaient des salles de machines entières et consistaient en d'énormes racks. De nos jours, cela s'appelle les centres de données. Mais dans les centres de données d'une même salle des machines, il peut y avoir des milliers d'ordinateurs et, à l'aube de la technologie informatique, un ordinateur occupait une salle entière. Chaque rack a vendu un (!) Périphérique informatique (racks séparés avec mémoire, racks séparés avec périphériques de stockage et périphériques séparément). Le cœur de cette énorme machine était un rack avec un processeur - on l'appelait le principal, ou mainframe.Après le passage aux circuits intégrés à transistors, la taille de ce miracle de la pensée scientifique et technique a considérablement diminué, et le mainframe d'IBM et de leurs analogues a commencé à être compris comme le mainframe.

Dans les années 60 du XXe siècle, la location de la puissance de calcul de l'ensemble du mainframe, sans parler de son achat, a coûté cher. Très peu d'entreprises et d'institutions pouvaient se permettre un tel luxe. La location de la puissance de calcul était horaire (le prototype du modèle moderne Pay as you go dans les clouds publics, n'est-ce pas?). L'accès aux locataires pour l'informatique a été accordé séquentiellement. La solution logique était de paralléliser la charge de calcul et d’isoler les calculs des locataires les uns des autres.

Pour la première fois, l'idée d'isoler plusieurs instances de systèmes d'exploitation sur un seul ordinateur central a été proposée par IBM Cambridge Science Center sur la base de l'ordinateur central IBM System / 360-67. Le développement a été appelé CP / CMS et, en fait, a été le premier hyperviseur et a fourni la paravirtualisation. CP (Control Program) - l'hyperviseur lui-même, qui a créé plusieurs "machines virtuelles" (VM) indépendantes. CMS (à l'origine le Cambridge Monitor System, renommé plus tard Conversational Monitor System) était un système d'exploitation léger à utilisateur unique. Curieusement, CMS est toujours en vie et est toujours utilisé dans la dernière génération de mainframes z / VM. Il convient de noter qu'à cette époque et jusqu'aux années 90, une machine virtuelle signifiait une séparation logique des disques physiques (les disques ou les périphériques de stockage étaient partagés,l'hyperviseur n'a pas fourni de stockage pour ses propres besoins) avec un morceau dédié de mémoire virtuelle et de temps processeur utilisant la technologie Time-Sharing. Les machines virtuelles ne prévoyaient pas d'interaction avec le réseau, car les machines virtuelles de l'époque concernaient le calcul et le stockage de données, et non leur transfert. En ce sens, les VM de cette époque ressemblaient plus à des conteneurs que des VM au sens moderne.

Le premier hyperviseur commercial basé sur CP / CMS, appelé VM / 370, est apparu sur les ordinateurs centraux de la série System / 370 le 2 août 1972. Le nom général de cette famille de systèmes d'exploitation est VM, et dans le cadre de cette section, VM sera considérée comme l'hyperviseur IBM. La possibilité d'exécuter plusieurs systèmes d'exploitation en même temps, garantissant la stabilité du système et isolant les utilisateurs les uns des autres (une erreur dans le système d'exploitation d'un utilisateur ne pouvait pas affecter les calculs d'un autre utilisateur) - était révolutionnaire et est devenue un facteur clé du succès commercial de VM / 370. Un fait curieux: à cette époque en URSS, les efforts de l'Institut de recherche scientifique en informatique (Minsk) ont très bien cloné l'architecture System / 370 et créé sa propre VM / 370 analogique sous le nom de l'ordinateur de l'UE (avec le soutien de la virtualisation intégrée! - pour la possibilité de développer le système d'exploitation le plus élémentaire).Ces unités centrales étaient utilisées par les instituts de recherche et les entreprises de défense du camp socialiste.

Les années 80 peuvent être appelées en toute sécurité «l'ère du mainframe». VM a été un succès auprès des développeurs de systèmes d'exploitation, des applications ont été écrites pour cela et des calculs ont été effectués. C'était la décennie où la part des bases de données dominées par VM OS a commencé à prévaloir dans les mainframes. L'un des changements les plus importants a été les ressources d'accès aux partitions logiques (LPAR), qui offraient en fait deux niveaux de virtualisation. Les clients peuvent désormais utiliser le même ensemble de processeurs, de périphériques d'E / S et de modems dans les systèmes de VM s'exécutant dans différentes partitions logiques et permettant la migration des ressources d'un système de VM vers un autre. Cela a permis aux organisations informatiques de fournir des performances cohérentes tout en traitant les pics de charge de travail. Pour rationaliser la clientèle croissante, VM a été divisée en trois produits distincts,disponible à la fin des années 80:

VM / SP - le système d'exploitation de virtualisation polyvalent habituel pour les serveurs System z
HPO (option haute performance) - VM / SP haute performance pour les anciens modèles de serveurs System z
VM / XA (architecture étendue) - Variante VM avec prise en charge de l'architecture S / S étendue 370

Au début des années 90, la simplicité et la commodité de l'architecture x86 sont devenues plus attrayantes pour les clients, et les mainframes ont rapidement perdu de leur pertinence. Les mainframes ont été remplacés par des systèmes de cluster, comme le grunge, qui a remplacé le glam metal en même temps. Cependant, pour une certaine classe de tâches, par exemple, lors de la construction d'un entrepôt de données centralisé, les mainframes se justifient à la fois en termes de productivité et d'un point de vue économique. Par conséquent, certaines entreprises utilisent encore des mainframes dans leurs infrastructures et IBM conçoit, publie et prend en charge les nouvelles générations.

Linux Xen

Xen (prononcé zen) est un hyperviseur développé à l'Université de Cambridge Computer Lab sous la direction d'Ian Pratt et distribué sous GPL. La première version publique est apparue en 2003. Par la suite, Ian a continué à travailler sur l'hyperviseur dans sa version commerciale, créant la société XenSource.
En 2013, Xen est passé sous le contrôle de la Linux Foundation.

XenSource

Existant depuis plusieurs années sur le marché avec les produits XenServer et XenEnterprise, il a été racheté fin 2007 par Citrix.

Citrix XenServer

Ayant absorbé XenSource pour 500 millions de dollars, Citrix n'a pas pu commercialiser le problème. Plus précisément, je n'ai pas vraiment essayé de le faire, ne considérant pas XenServer comme le produit principal et comptant sur le bon marché des licences permanentes. Après des ventes franchement infructueuses au milieu du très réussi VMware ESX, il a été décidé de lancer XenServer dans le monde gratuitement et en open source en 2009. Cependant, le code du système de gestion propriétaire XenCenter ne s'est pas ouvert.
Il convient de noter une coïncidence chronologique intéressante des initiatives Citrix et Microsoft dans le domaine de la virtualisation industrielle, malgré le fait que les entreprises étaient toujours très proches.

Malgré leur nom marketing commun, Citrix XenApp et XenDesktop n'ont rien à voir avec l'hyperviseur Xen.

Amazon

Amazon a présenté son offre publique de cloud IaaS appelée EC2 (Elastic Compute) en 2006. Initialement, la plate-forme EC2 a utilisé l'hyperviseur Xen, puis Amazon a divisé la plate-forme en trois parties, chacune utilisant une branche et une version distinctes de l'hyperviseur pour minimiser l'effet des erreurs du code sur la disponibilité du service.

En 2017, KVM pour les charges lourdes est apparu comme un hyperviseur supplémentaire dans EC2. Selon certains, cela indique le transfert progressif d'EC2 vers KVM entièrement à l'avenir.

Linux QEMU / KVM

QEMU (Quick EMUlator) est un logiciel universel pour émuler le matériel de diverses plates-formes, distribué sous licence GPL v2. En plus de x86, ARM, MIPS, RISC-V, PowerPC, SPARC, SPARC64 sont également pris en charge. Avec la polyvalence d'une plate-forme avec virtualisation complète, QEMU manquait de performances comparables à un système non virtualisé. Pour accélérer le travail de QEMU sur x86, deux options principales ont été proposées, qui ont finalement été rejetées en faveur du développement KVM (Kernel-based Virtual Machine) de Qumranet.

Nous disons KVM - nous voulons dire QEMU KVM, et en conséquence nous obtenons le format de disque virtuel qcow2 (QEMU copy-on-write 2) pour toutes les plates-formes basées sur l'hyperviseur KVM.
Bien que QEMU fonctionne initialement comme un deuxième type d'hyperviseur, QEMU / KVM est un premier type d'hyperviseur.

Qumranet

Une société israélienne, ancien développeur et sponsor principal de l'hyperviseur KVM et du protocole SPICE. Fondée en 2005, a acquis une renommée après avoir incorporé KVM dans le noyau Linux. 4 septembre 2008, acquis par Red Hat.

Chapeau rouge

Comme tous les fabricants de distribution GNU / Linux, jusqu'en 2010, Red Hat avait une prise en charge intégrée de l'hyperviseur Xen dans leurs distributions. Cependant, étant un acteur majeur du marché et une marque sérieuse, j'ai pensé à ma propre implémentation de l'hyperviseur. L'hyperviseur KVM, peu remarquable mais prometteur, a ensuite pris la base. La première version de Red Hat Enterprise Virtualization 2.2 (RHEV) a été introduite en 2010 avec la prétention de concurrencer une partie du marché des solutions VDI avec Citrix et VMware en raison du développement de Qumranet, acquis deux ans plus tôt. Des clusters haute disponibilité, Live Migration et des outils de migration M2M (RHEL uniquement) étaient disponibles. Il est à noter que, à en juger par la documentation de l'époque, Red Hat a conservé la notation Xen lors de la description de l'architecture de la solution.

Le 28 octobre 2018, IBM a annoncé l'achat de Red Hat.

Openstack

Historiquement, le projet OpenStack a émergé comme une initiative pour contraster quelque chose avec le monopole réel de VMware dans le domaine de la virtualisation de serveurs lourds x86. Le projet est apparu en 2010 grâce aux efforts conjoints de Rackspace Hosting (un fournisseur de cloud) et de la NASA (qui a ouvert le code de sa propre plate-forme Nebula). Le piquant de la situation a été donné par le fait qu'en 2012, VMware a rejoint la direction du projet OpenStack et a provoqué une vague d'indignation parmi les militants fondateurs.

Au fil du temps, Canonical (Ubuntu Linux), Debian, SUSE, Red Hat, HP, Oracle ont rejoint le projet.

Cependant, tout n'a pas été fluide. En 2012, la NASA a quitté le projet, optant pour AWS. Début 2016, HPE a complètement clôturé son projet Helion basé sur OpenStack.

Dans le cadre du projet OpenStack, KVM a été adopté comme hyperviseur standard. Cependant, en raison de la modularité de l'approche, un système basé sur OpenStack peut être implémenté en utilisant d'autres hyperviseurs, ne laissant, par exemple, qu'un système de contrôle d'OpenStack.

Il existe un large éventail d'opinions concernant le projet OpenStack, du culte enthousiaste au scepticisme sérieux et aux critiques sévères. La critique n'est pas sans raison - un nombre important de problèmes et de pertes de données ont été enregistrés lors de l'utilisation d'OpenStack. Ce qui n'empêche cependant pas les fans de tout nier et de se référer à la courbure dans la mise en œuvre et le fonctionnement des systèmes.

Le projet OpenStack ne se limite pas uniquement à la virtualisation, mais avec le temps, il est devenu un nombre important de divers sous-projets et composants à étendre dans le domaine de la pile de services de cloud public. De plus, l'importance d'OpenStack devrait probablement être évaluée précisément dans cette partie - ces composants sont devenus essentiels dans de nombreux produits et systèmes commerciaux, dans le domaine de la virtualisation et au-delà.

En Russie, OpenStack en dehors des clouds publics est largement connu principalement pour son rôle dans la substitution des importations. La grande majorité des solutions et produits de virtualisation, y compris les systèmes hyperconvergés, sont conditionnés par OpenStack avec différents degrés de raffinement.

Nutanix AHV

Depuis sa création, Nutanix est un produit et une plate-forme exclusivement pour VMware vSphere. Cependant, en partie en raison de la volonté d'élargir l'offre pour d'autres hyperviseurs, en partie en raison de la crise politique dans les relations avec VMware, il a été décidé de développer leur propre hyperviseur, qui compléterait la plateforme en boîte et permettrait d'abandonner les produits tiers. KVM a été choisi comme son propre hyperviseur, qui dans le cadre de la plate-forme s'appelait AHV (Acropolis HyperVisor).

Parallels

Dans la version 7 de Virtuozzo, la société est passée de son propre hyperviseur à KVM.

Proxmox

Proxmox VE (Virtual Environment) est un projet open source de la société autrichienne Proxmox Server Solutions GmbH basé sur Debian Linux. La première version date de 2008.
Le produit prend en charge la virtualisation de conteneurs LXC (anciennement OpenVZ) et la virtualisation complète avec l'hyperviseur KVM.

Parallels / Virtuozzo / Rosplatform

Fondé en 1999 par Sergey Belousov, SWsoft a adopté un logiciel de gestion d'hébergement. En 2003, la société rivale Plosk de Novossibirsk a été acquise.

En 2004, SWsoft a acquis la société russe Parallels Nikolai Dobrovolsky avec son produit Parallels Workstation (hyperviseur de bureau du deuxième type sous Windows).
La nouvelle société conserve son nom Parallels et va bientôt faire exploser le marché avec Parallels Desktop pour Mac (hyperviseur de bureau du deuxième type pour MacOS).

Dans le cadre de la virtualisation des serveurs, l'accent continue d'être mis sur les fournisseurs d'hébergement et les centres de données, plutôt que sur l'utilisation en entreprise. En raison des spécificités de ce marché particulier, les conteneurs Virtuozzo et OpenVZ, plutôt que les machines virtuelles système, sont devenus le produit clé. Par la suite, Parallels, sans grand succès, tente de pénétrer le marché de la virtualisation des serveurs d'entreprise avec le produit Parallels Bare Metal Server (par la suite Parallels Hypervisor et Cloud Server, puis Virtuozzo), ajoute une hyper-convergence avec son Cloud Storage. Les travaux se poursuivent sur l'automatisation et l'orchestration des hébergeurs.

En 2015, sur la base des produits de virtualisation de serveurs, le projet de plateforme Rosplatform est créé - techniquement (en omettant les problèmes juridiques et organisationnels) le même Virtuozzo, uniquement avec des fonds d'écran modifiés et dans le registre russe des logiciels. Basé sur le logiciel de la plateforme Rosplatform et les équipements Depo, IBS crée une offre hyperconvergée de package Scala-R.

Avant la version 7, Virtuozzo utilisait un hyperviseur de sa propre conception; dans la version 7, une transition vers KVM a été effectuée. En conséquence, Rosplatform est également basé sur KVM.
Après plusieurs fusions, acquisitions et rebrandings, l'image suivante se forme d'ici 2019.

Parallels Desktop est une filiale de Parallels et vendue à Corel. Toute l'automatisation a été confiée à Odin et revendue à IngramMicro. La virtualisation des serveurs est restée sous la marque de plateforme Virtuozzo / Rosplatform.