La virtualisation à l'heure actuelle joue un rôle essentiel. De l'utilisation du bureau au niveau du consommateur aux services cloud au niveau de l'entreprise, il existe une variété d'applicabilités.
Ce guide vous aidera à démarrer avec la virtualisation de manière complète. Cela vous donnera suffisamment de connaissances fondamentales pour vous en tant qu'étudiant, ingénieur ou même en tant que CTO pour comprendre les différents types de virtualisation et comment ils sont utilisés dans l'industrie aujourd'hui.
C'est un article énorme, alors laissez-moi résumer ce dont je vais parler.
- La première partie présente le système d'exploitation hôte, les machines virtuelles (VM) et les hyperviseurs
- La deuxième partie décrit les composants essentiels de la virtualisation :CPU, RAM, réseau et stockage
- La troisième partie met en lumière les avantages de la virtualisation
Commençons !
Machines virtuelles, hôtes et hyperviseurs
Pour mieux comprendre les machines virtuelles, les hôtes et les hyperviseurs, il est essentiel que vous commenciez par les fondamentaux du matériel.
Tout d'abord, vous avez besoin d'une machine/serveur physique qui comprend les composants suivants qui composent l'ensemble du système :
- Unité d'alimentation (PSU)
- Carte mère
- Unité centrale de traitement (CPU)
- Mémoire à accès aléatoire (RAM)
- Carte d'interface réseau (NIC)
- Stockage – Disque dur (HDD) ou Solid State Drive (SSD)
Tous ces composants sont assemblés et se synchronisent en une seule unité informatique devenant votre propre ordinateur personnel (PC) ou serveur. Attendez, un serveur personnel semble intéressant !
Qu'est-ce qu'un système d'exploitation ?
Un système d'exploitation est un logiciel système qui agit comme une interface entre l'utilisateur et l'ordinateur pour exécuter une variété d'applications, avec ou sans interface utilisateur graphique. L'une de ces applications peut être des programmes de virtualisation dédiés tels que VirtualBox, par exemple.
Qu'est-ce qu'un hyperviseur ?
Un hyperviseur est un logiciel système qui agit comme intermédiaire entre le matériel informatique et les machines virtuelles. Il est chargé d'allouer et d'exploiter efficacement les ressources matérielles à utiliser par les machines virtuelles respectives, qui fonctionnent individuellement sur un hôte physique. Pour cette raison, les hyperviseurs sont également appelés gestionnaires de machines virtuelles.
Ce logiciel système agit comme une interface entre l'utilisateur et l'ordinateur dans le seul but de la virtualisation, avec ou sans interface utilisateur graphique. Un exemple d'un tel hyperviseur est VMware FXI.
Un hyperviseur se compose de trois modules principaux :
Répartiteur — Il constitue le point d'entrée du moniteur et redirige les instructions émises par l'instance de machine virtuelle vers les modules alloueurs ou interprètes décrits ci-dessous.
Allocation — Chaque fois qu'une machine virtuelle tente d'exécuter une instruction qui entraîne la modification des ressources de la machine associée, l'allocateur est appelé par le répartiteur, qui alloue ensuite les ressources système à fournir à la machine virtuelle.
Interprète — Il se compose de routines d'interpréteur qui sont exécutées chaque fois qu'une machine virtuelle exécute une instruction privilégiée. Ceci est également invoqué par le répartiteur.
Vous devez installer soit un système d'exploitation, soit un hyperviseur qui agit comme une interface vous permettant d'interagir avec un serveur/ordinateur hôte physique.
Supposons qu'il s'agisse d'Ubuntu Server où vous pouvez héberger ou exécuter diverses applications. Ces applications sur le serveur s'exécutent à l'intérieur du système d'exploitation.
En utilisant le matériel, Ubuntu peut les contrôler ainsi que la quantité de ressources auxquelles ils ont accès.
Par conséquent, un système d'exploitation ou un hyperviseur devient un intermédiaire entre les applications et le matériel lui-même.
Qu'est-ce qu'une machine virtuelle (VM) ?
Une machine virtuelle est un logiciel qui émule toutes les fonctionnalités d'un serveur physique et s'exécute au-dessus d'un système d'exploitation hôte ou d'un hyperviseur.
Par conséquent, vous n'allez pas exécuter directement des applications sur le système physique. Ils seront exécutés sur des machines virtuelles, chacune avec son propre système d'exploitation indépendant. De cette manière, les machines virtuelles peuvent exécuter différents systèmes d'exploitation individuellement au sein du même système physique.
Toutes ces machines virtuelles peuvent partager un ensemble commun de matériel physique et même interagir les unes avec les autres sur un réseau virtuel, tout comme le font les ordinateurs physiques.
Vous pouvez avoir un tas de machines virtuelles, chacune avec son propre système d'exploitation indépendant, partageant et utilisant les mêmes composants physiques que ceux mentionnés précédemment.
Un hyperviseur ou un logiciel de virtualisation s'exécutant sur un système d'exploitation est en fait ce qui contrôle les ressources physiques.
Un hyperviseur a un accès direct au matériel physique et contrôle les ressources auxquelles les machines virtuelles ont accès.
Cela inclut :
- Quelle quantité de mémoire (RAM) est allouée
- Combien d'accès au processeur physique ils obtiennent
- Comment accèdent-ils à leur réseau ?
- Comment accèdent-ils à leur espace de stockage ?
Au fur et à mesure que de plus en plus de machines virtuelles sont créées sur un logiciel de virtualisation de système d'exploitation (réduisons-le à OSVS) ou à un hyperviseur, elles partagent également exactement le même ensemble de ressources physiques.
Par conséquent, l'OSVS ou l'hyperviseur contrôle :
- Comment les ressources sont partagées entre les machines virtuelles individuelles
- Comment les ressources sont présentées aux machines virtuelles individuelles
Types d'hyperviseurs
Examinons maintenant les types d'hyperviseurs et leurs différences.
Hyperviseur de type 1
Un hyperviseur qui peut être installé nativement et exécuté directement sur un hôte physique est appelé un hyperviseur de type 1.
Points clés
- Un hyperviseur de type 1 peut être installé directement sur un système bare metal ou un hôte physique.
- Il ne nécessite pas qu'un système d'exploitation (OS) soit installé ou disponible en premier, afin de se déployer sur un serveur.
- Accès direct au processeur, à la mémoire, au réseau et au stockage physique.
- L'utilisation du matériel est plus efficace, offrant les meilleures performances.
- Meilleure sécurité en raison de l'absence de toute couche supplémentaire pour l'accès matériel.
- Chaque hyperviseur de type 1 nécessite toujours une machine physique dédiée.
- Peut coûter plus cher et convenir davantage aux solutions d'entreprise
- VMware ESXi, Citrix Hypervisor et Microsoft Hyper-V sont quelques exemples d'hyperviseurs de type 1.
Hyperviseur de type 2
Un hyperviseur qui ne peut pas être installé en mode natif et qui nécessite un système d'exploitation pour s'exécuter sur un hôte physique est appelé un hyperviseur de type 2.
Points clés
- Un hyperviseur de type 2 ne peut pas être directement installé sur un système bare metal ou un hôte physique.
- Il nécessite d'abord qu'un système d'exploitation soit installé ou disponible, afin de se déployer.
- Accès indirect au processeur, à la mémoire, au réseau et au stockage physique.
- En raison d'une couche supplémentaire (système d'exploitation) pour accéder aux ressources, l'utilisation du matériel peut être moins efficace et ralentir les performances.
- Risques de sécurité potentiels en raison de la disponibilité du système d'exploitation hôte.
- Chaque hyperviseur de type 2 ne nécessite pas de machine physique dédiée. Il peut y en avoir plusieurs sur un seul hôte.
- Peut coûter moins cher et convenir davantage aux solutions destinées aux petites entreprises
- VMware Workstation Player, VMware Workstation Pro et VirtualBox sont quelques exemples d'hyperviseurs de type 2.
Fichiers de la machine virtuelle et état en direct
Comprenons maintenant les fichiers qui composent nos machines virtuelles et comment ils exploitent le stockage partagé.
Une machine virtuelle exploite la mémoire, le processeur, le réseau et le matériel de stockage de notre hôte physique. Comment ça se passe ?
Via l'hyperviseur.
Lorsqu'une machine virtuelle est en cours d'exécution, elle possède certaines informations en mémoire. Ces informations font partie de l'état en direct de la VM.
La VM est donc réellement opérationnelle sur l'hôte. Chaque fois que vous lisez une vidéo ou ouvrez un navigateur Web sur la machine virtuelle, ces opérations d'exécution se produisent en mémoire sur la machine virtuelle. Mais ceux-ci se produisent en fait tous sur l'hôte physique. Il s'agit de l'état en direct de n'importe quelle machine virtuelle.
L'état en direct de la machine virtuelle traite toutes les exécutions d'exécution sur le CPU, c'est pourquoi cela se produit sur l'hôte.
Lorsque vous ouvrez un navigateur pour charger un site Web, la bande passante du réseau est traversée par la carte réseau qui fait également partie de l'hôte physique. Tout cela fait partie de l'état en direct d'une machine virtuelle qui utilise des adaptateurs de stockage pour envoyer le trafic de données vers un périphérique de stockage. Encore une fois, cela se passe en direct et en temps réel sur l'hôte.
Une machine virtuelle n'a pas de disques durs physiques. Si vous exécutez Linux sur une machine virtuelle, celle-ci doit pouvoir lire et écrire des données vers et depuis un lecteur physique.
Cela signifie que l'accès à un disque physique est nécessaire. La machine virtuelle lit vers et depuis et s'exécute sur un lecteur virtuellement alloué. Mais les opérations sont en fait redirigées vers un périphérique de stockage physique quelque part. Il peut s'agir d'un réseau Fibre Channel, d'un réseau Ethernet ou du disque local lui-même, directement à l'intérieur de l'hyperviseur ou du logiciel de virtualisation du système d'exploitation.
Les machines virtuelles doivent utiliser un ensemble de fichiers pour la gestion de la virtualisation. L'un de ces fichiers représente un lecteur virtuellement alloué ou un disque virtuel. Une machine virtuelle doit lire ou écrire sur le disque virtuel via ces fichiers. Le trafic de données passera par un adaptateur de stockage pour que cela se produise.
Pour des raisons évidentes, de nombreux fichiers de ce type peuvent correspondre à d'autres machines virtuelles stockées au même emplacement physique sur le disque dur.
Parlons maintenant de la façon dont les machines virtuelles s'arrêtent et redémarrent.
Pour pouvoir le faire, la VM a besoin d'informations de configuration qui comprennent principalement l'état en direct :
- Combien de mémoire la VM est-elle censée avoir ?
- Combien de CPU est-il censé avoir ?
- Quelle est la taille de disque allouée ?
- Comment la VM accéderait-elle au réseau ?
Encore une fois, toutes ces informations sont stockées dans un fichier.
Permettez-moi de répertorier tous les types d'informations stockées dans les fichiers de la machine virtuelle pour garantir leur pleine fonctionnalité :
- Stockage statique ou dynamique
- Informations de configuration
- Informations du BIOS
- Instantanés pris
Ainsi, une machine virtuelle stocke deux types d'états :
État en direct
L'état en direct est ce qui se passe en temps réel, ce qui, comme je viens de le dire, pourrait être :
- Quelle est la quantité de mémoire actuellement utilisée
- Combien de CPU est utilisé
- Quelles sont les applications actuellement utilisées
- Comment la bande passante du réseau est utilisée ou traversée
Si l'hôte physique ou la machine virtuelle qu'il contient tombe en panne, toutes les informations en temps réel ci-dessus seront perdues. C'est comme débrancher un ordinateur.
État persistant
L'état persistant sont les fichiers de cette machine virtuelle, qui sont sauvegardés en permanence. Cela est rendu possible grâce à :
- Fichiers de stockage
- Fichiers de configuration
- Fichiers instantanés
Les fichiers liés à l'état persistant constituent la VM.
Comme nous, les humains, ne pouvons pas survivre sans une alimentation adéquate, les machines virtuelles doivent également disposer de manière cohérente d'une allocation appropriée des ressources. Le manque de ces ressources signifie que les machines virtuelles ne fonctionneront pas de manière optimale.
Les quatre éléments essentiels sans lesquels les VM ne peuvent pas atteindre leurs meilleures performances sont :
- Processeur
- RAM
- Réseau
- Stockage
Virtualisation du processeur
Comment une machine virtuelle accède-t-elle aux ressources CPU de l'hôte physique ?
L'hôte physique a un CPU physique. Disons, par exemple, que nous avons un processeur avec 4 cœurs physiques. Maintenant, si vous souhaitez allouer 2 de ces cœurs physiques, lorsque vous commencerez à créer vos machines virtuelles, vous allouerez 2 CPU virtuels. Cela signifie que la machine virtuelle aurait accès à 2 cœurs de processeur physique à partir du processeur principal en créant une machine virtuelle avec 2 processeurs virtuels.
Mais cette allocation ne signifie pas que d'autres machines virtuelles ne peuvent pas exploiter ces cœurs, ce qui signifie que je peux attribuer les 4 cœurs à une autre machine virtuelle. Donc, de manière concluante, ces ressources peuvent être partagées par toutes les machines virtuelles sur l'hyperviseur ou le logiciel de virtualisation du système d'exploitation.
Selon le type de charge de travail, vous devez attribuer les cœurs de processeur en fonction de la nécessité des machines virtuelles. Si une machine virtuelle fonctionne bien avec une utilisation du processeur de 25 %, vous pouvez bien sûr affecter les ressources restantes à d'autres machines virtuelles.
Par conséquent, vous devez toujours vous efforcer de toujours redimensionner vos machines virtuelles en fonction des exigences de l'application, en particulier en ce qui concerne les ressources CPU.
Virtualisation de la mémoire
Voyons maintenant comment les machines virtuelles sont capables d'utiliser les ressources mémoire de l'hyperviseur.
La quantité de mémoire que vous pouvez allouer à une machine virtuelle est à nouveau basée sur la mémoire physique (RAM) dont vous disposez sur votre serveur physique.
Par exemple, si votre serveur dispose de 8 Go de RAM, vous pouvez allouer 4 Go et exécuter un bureau Ubuntu à part entière sur votre machine virtuelle. Le bureau Ubuntu "pense" qu'il dispose de 4 Go de mémoire physique. Mais ce qui se passe réellement, c'est que cette mémoire allouée est mappée à partir des 8 Go réels de mémoire physique elle-même.
Lorsque vous attribuez 4 Go à la machine virtuelle, elle ne peut pas utiliser plus de mémoire que la quantité allouée.
Comme les CPU, cela ne veut pas dire encore une fois que ces 4 Go sont dédiés à la VM en permanence. Si les applications s'exécutant sur cette machine virtuelle n'ont actuellement pas besoin d'autant de mémoire, une autre machine virtuelle peut utiliser la même ressource, au fur et à mesure des besoins.
Lorsqu'une application s'exécute sur une machine virtuelle, le système d'exploitation (sur la machine virtuelle) alloue la mémoire en fonction de sa propre table de mémoire, et lorsqu'elle est fermée sur une machine virtuelle, le système d'exploitation marque ces pages de mémoire comme libres. Mais comme il n'est jamais "au courant" de la présence d'un hyperviseur ou d'un logiciel de virtualisation, il ne va jamais informer le serveur physique de cette désallocation.
Par conséquent, c'est le travail de l'hyperviseur ou du logiciel de virtualisation de continuer à regarder à l'intérieur du système d'exploitation de la machine virtuelle pour surveiller ces allocations et attribuer de temps en temps des portions de mémoire inutilisées à d'autres machines virtuelles.
Contrairement à cet aspect partagé de l'allocation de mémoire entre les machines virtuelles, vous pouvez également appliquer la réservation de mémoire pour des machines virtuelles spécifiques afin d'utiliser une partie spécifique de la mémoire physique. Cela signifie que les autres machines virtuelles ne peuvent pas utiliser la mémoire réservée même si elle n'est pas utilisée par la machine virtuelle à mémoire réservée. En pratique générale, il est préférable d'éviter cette procédure, car le partage de la mémoire garantit une utilisation efficace des ressources en fin de journée.
Vous pouvez associer cela aux serveurs partagés et dédiés fournis via Linode. Il est plus économique d'utiliser des serveurs partagés dans la pratique et la production quotidiennes de l'administrateur système.
Virtualisation du réseau
Une machine virtuelle Ubuntu s'exécute sur un hôte sur un hyperviseur ou un logiciel de virtualisation. Cette machine virtuelle possède ce que nous appelons une carte réseau virtuelle V-NIC. Cela s'étend à la carte d'interface réseau virtuelle.
Le système d'exploitation (Ubuntu) ne sait pas qu'il s'exécute dans une machine virtuelle. Il s'attend donc à voir le même type de matériel qu'il verrait s'il fonctionnait sur un serveur physique.
Lorsqu'il s'agit de virtualisation de réseau, vous devez fournir votre machine virtuelle, une carte d'interface réseau virtuelle.
Ubuntu va en fait implémenter ses pilotes pour une carte d'interface réseau. En tant que système d'exploitation invité, il n'aura aucune idée que ce n'est pas vraiment une carte réseau physique.
C'est une carte réseau virtuelle qui est un faux matériel présenté à notre machine virtuelle comme s'il était réel. Donc, si vous avez un serveur physique avec une carte réseau physique, vous devez connecter votre câble Ethernet du port Ethernet vers un commutateur physique.
Si vous avez une machine virtuelle avec une carte réseau virtuelle, vous allez la connecter à un port sur un commutateur virtuel, un peu comme vous le feriez avec une machine physique.
Par conséquent, à l'intérieur de notre hyperviseur ou logiciel de virtualisation, nous allons avoir quelque chose appelé le commutateur virtuel. Vous pouvez connecter plusieurs machines virtuelles à ce commutateur virtuel et elles peuvent communiquer entre elles.
Tant que vous les mettez sur le même VLAN (réseau local virtuel), ils pourront communiquer via le commutateur virtuel comme s'ils pouvaient communiquer via n'importe quel autre type de commutateur physique.
Ainsi, si vous avez une seule machine virtuelle connectée à un commutateur virtuel, vous pouvez connecter une deuxième machine virtuelle. Cela permet d'envoyer le trafic d'une machine virtuelle à une autre directement dans ce commutateur virtuel. Ce trafic ne doit jamais quitter l'hôte tant que ces machines virtuelles sont sur le même VLAN. Tant que ces machines virtuelles sont sur le même VLAN, elles peuvent communiquer et le trafic n'a jamais à traverser le réseau physique.
Mais, voici un point important. Une partie du trafic réseau devra traverser le réseau physique, et le commutateur virtuel aura donc besoin d'une liaison montante.
Tout comme un commutateur physique a des liaisons montantes vers un commutateur physique de niveau supérieur ou un routeur physique, notre commutateur virtuel nécessite également des liaisons montantes. Ces liaisons montantes sont les adaptateurs physiques réels sur l'hôte. Ces adaptateurs physiques sont appelés P-NIC ou cartes réseau physiques ou cartes réseau VM.
Une carte d'interface réseau physique ou NIC est toujours intégrée à nos cartes mères modernes sur nos serveurs :
Mais si vous le souhaitez, vous pouvez également opter pour une carte réseau dédiée, branchée sur la carte mère pour une mise en réseau supplémentaire :
Lorsque vous créez un hyperviseur sur un hôte, cet hôte possède une ou plusieurs cartes d'interface réseau, comme n'importe quel autre serveur.
Ces cartes d'interface réseau physiques sur un hôte se connectent à un commutateur physique, et ce commutateur physique aura des connexions aux routeurs. C'est ainsi qu'il achemine le trafic vers Internet.
Grâce à ce mécanisme, il peut également se connecter à d'autres serveurs physiques qui se trouvent dans le même centre de données.
Ainsi, les machines virtuelles peuvent communiquer avec tous ces composants avec ou au sein du même serveur physique.
Si le trafic doit réellement quitter l'hôte pour communiquer à l'extérieur de l'hôte pour atteindre un routeur et accéder à un autre VLAN ou à un autre réseau, ce trafic sortira de la VM.
Grâce au commutateur virtuel, l'un des commutateurs virtuels établit une liaison montante vers le réseau physique.
Lorsque ce trafic arrive au commutateur physique, il effectue une recherche dans la table MAC (un enregistrement d'adresses physiques uniques).
Il fournira le port approprié vers la destination appropriée où ce paquet doit aller. Il peut être dirigé vers Internet ou vers un hôte physique sur votre propre réseau local.
Mais ce mécanisme garantit la capacité de toutes vos machines virtuelles à communiquer avec tous les appareils de mon réseau physique. C'est ce que fait un commutateur virtuel.
L'idée fondamentale ici est de tromper le système d'exploitation invité sur la machine virtuelle en lui faisant "penser" qu'il a une carte d'interface réseau physique. Donc, vous fournissez les mêmes pilotes à Ubuntu et il pensera qu'il a un véritable périphérique matériel.
Lorsque les paquets de données sont envoyés, le trafic est en fait récupéré par l'hyperviseur, qui le dirige vers le commutateur virtuel approprié, comme indiqué.
Virtualisation du stockage
Maintenant que vous savez comment les machines virtuelles exploitent les processeurs, la mémoire et le réseau, passons à la dernière ressource :le stockage.
Permettez-moi de répéter que le système d'exploitation invité n'a aucune idée qu'il s'exécute dans une machine virtuelle. Une machine virtuelle n'a pas de matériel physique dédié et cela inclut un disque de stockage. La VM n'a pas de disque physique qui lui est dédié.
Avec la mise en réseau, nous avions une carte réseau virtuelle.
Avec la virtualisation du stockage, nous allons avoir un contrôleur SCSI virtuel, si nous pensons à la façon dont un serveur physique fonctionne avec des disques durs internes. Lorsqu'un système d'exploitation a besoin d'écrire une sorte de données sur le disque, le système d'exploitation génère une commande SCSI.
S'il a besoin de lire des données à partir du disque, il génère une commande SCSI et envoie cette commande au contrôleur SCSI, qui s'interface avec les disques physiques. C'est ainsi qu'Ubuntu fonctionne avec le stockage, il ne sait pas qu'il s'exécute dans une machine virtuelle ici.
Nous devons donc maintenir cette illusion pour le système d'exploitation invité pour les mécanismes de stockage également.
Vous fournissez donc à Linux (s'exécutant sur la VM) un contrôleur SCSI virtuel. Il s'émulera comme s'il exécutait des disques physiques réels.
Par conséquent, lorsqu'Ubuntu devra exécuter une sorte de commande de stockage, il pensera que j'ai un véritable contrôleur SCSI.
Lorsqu'une commande de stockage est envoyée au contrôleur SCSI, ce qui se passe réellement, c'est que le contrôleur SCSI virtuel (un périphérique virtuel) les redirige vers l'hyperviseur. La machine virtuelle envoie ces commandes de stockage via son contrôleur SCSI virtuel et elles arrivent à l'hyperviseur.
L'hyperviseur détermine ce qu'il advient de ces commandes de stockage à partir d'ici. Si la machine virtuelle possède son propre VMDK ou fichier de disque virtuel sur un disque local, elle enverra simplement ces commandes de stockage à ce fichier sur votre disque dur local.
En dehors de cette fonctionnalité la plus basique, il pourrait également être
- une baie de stockage Fibre Channel
- une baie de stockage iSCSI basée sur Ethernet
- un canal fibre sur Ethernet
Mais ils fonctionnent tous de la même manière.
Ce qui serait différent, c'est en fait le réseau.
Si l'hyperviseur envoie cette commande de stockage à un Fibre Channel, cette commande de stockage traversera ce réseau Fibre Channel jusqu'à ce qu'elle arrive finalement sur le disque virtuel.
Quel que soit l'hyperviseur, votre machine virtuelle disposera d'un disque virtuel.
C'est ainsi que les commandes SCSI passent de votre machine virtuelle à votre disque virtuel, quel que soit l'emplacement de ce disque virtuel.
Lorsqu'une machine virtuelle basée sur Ubuntu génère une commande SCSI, elle l'envoie au contrôleur SCSI virtuel.
L'hyperviseur détermine l'emplacement approprié pour ce disque virtuel et l'envoie à l'adaptateur de stockage, et la commande de stockage arrive au magasin de données.
Ces modifications de traversée de données sont en fait écrites dans le fichier qui contient le disque virtuel de la machine virtuelle. Il peut s'agir de .VMX, .VMDK ou de tout autre type de fichier virtuel.
J'espère que vous avez maintenant compris les bases de la virtualisation du réseau et du stockage. Permettez-moi de souligner les avantages de la virtualisation en matière d'efficacité et de mobilité, ainsi que la façon dont vous pouvez convertir des hôtes physiques en machines virtuelles.
Avantages de la virtualisation
Jusqu'à présent, nous avons parlé du fonctionnement de la virtualisation à travers les différents modes de gestion des ressources. Parlons maintenant des nombreux avantages clés.
Consolidation
Parlons d'abord de l'efficacité.
Si vous comparez votre infrastructure virtuelle à un gymnase, certains d'entre vous en ont peut-être déjà fait l'expérience.
Si vous êtes un amateur de gym vers le 1er janvier, la salle de sport commence à être très occupée.
Pendant la partie normale de l'année, une salle de sport avec environ 20 tapis roulants et 50 machines d'exercice suffirait.
Mais si vous êtes propriétaire d'une salle de sport, vous savez qu'en janvier, il y aura deux à trois fois plus de monde et il serait plus productif de tripler la taille de votre environnement.
Quand tous ces gens se rendent compte que, oui, peut-être qu'ils n'aiment pas vraiment faire de l'exercice, ils arrêtent d'utiliser la salle de sport.
Désormais, vous pouvez réduire la taille de la salle de sport selon vos besoins.
Maintenant, ce serait aussi vraiment bien si vous pouviez faire la même chose avec le matériel de votre centre de données virtuel.
Lorsque vous traitez de la virtualisation, cela vous amène à l'idée du cloud computing, où il existe un fournisseur ou un fournisseur de services comme Linode, par exemple. Avec lui, vous pouvez faire tourner un tas de machines virtuelles temporaires sur le matériel de quelqu'un d'autre et vous adapter à cette période chargée de l'année pour vos clients.
Mais vous ne pouvez pas vraiment accéder au cloud computing sans d'abord virtualiser. Il s'agit de la première étape sur cette voie pour arriver à ce que nous appelons un état d'élasticité, où votre infrastructure peut rapidement se développer ou se réduire.
La virtualisation est un élément de base vers ce type de flexibilité. Il nous permet de consolider les charges de travail.
Ci-dessous, nous voyons un centre de données de serveurs physiques.
Pour les meilleures pratiques, chacun de ces serveurs ne devrait pas exécuter un seul système d'exploitation.
Pensez au nombre de charges de travail supplémentaires que vous pourriez accomplir si vous exécutiez 20 à 30 instances Linux sur chacun de ces serveurs au lieu d'une seule par serveur !
C'est le plus grand avantage de la virtualisation. C'est l'avantage qui a initialement poussé cette innovation à se virtualiser :la consolidation.
Efficacité
Dans le diagramme ci-dessous, vous avez trois serveurs différents avec des rôles différents qui sont disponibles en tant que systèmes physiques individuels dans notre environnement :
Vous avez un serveur d'impression qui utilise 20 % de toutes les ressources et il en va de même pour le serveur Web et de base de données.
Ce sont des serveurs physiques qui n'utilisent pas vraiment toutes leurs ressources. Si vous y réfléchissez, vous avez payé pour tout ce matériel, et si vous n'en utilisez que 20 %, vous en gaspillez 80 %.
En bloquant les ressources sur un hôte physique qui ne peut exécuter qu'un seul système d'exploitation, vous avez maintenant deux choix pour résoudre ce problème :
Vous pouvez commencer à installer d'autres applications sur notre serveur et exécuter plusieurs applications sur le même serveur. Mais si vous devez redémarrer le serveur d'impression, vous vous demanderez quoi d'autre est en cours d'exécution sur ce serveur d'impression ?
Sur quoi d'autre pouvez-vous avoir un impact en effectuant une maintenance sur mon serveur d'impression ? Il y aura trop de cas d'utilisation et de scénarios d'application interdépendants sur le même matériel, ce qui réduira considérablement l'efficacité.
Par conséquent, la plupart du temps, nous nous retrouvons avec un gaspillage de ressources. Vous pouvez à la place vous débarrasser de ces serveurs physiques et consolider ces charges de travail sur un hyperviseur :
Grâce à cette consolidation, vous pouvez désormais exécuter plusieurs instances de système d'exploitation sur cet hyperviseur. Désormais, vous pouvez très facilement et efficacement maximiser, redimensionner et atteindre un point idéal qui pourrait être de 60 ou 70 % d'utilisation des ressources.
Alors maintenant, vous utilisez efficacement les ressources que vous avez achetées, mais vous ne les surchargez pas.
C'est notre objectif ultime avec la virtualisation :maximiser l'investissement dans le matériel fabriqué sans gaspiller de capital supplémentaire sur des ressources qui ne seront jamais utilisées.
Mobilité
Un autre grand avantage de la virtualisation est la mobilité.
Si vous pouvez vous rappeler comment fonctionne la virtualisation du réseau et du stockage, pensez à un scénario ici où vous avez une baie de stockage Fibre Channel. Considérons également que vous venez d'investir dans une nouvelle baie de stockage iSCSI.
Supposons maintenant que vous ayez votre baie de stockage Fibre Channel et que vous souhaitiez déplacer cette machine virtuelle et tous ses fichiers vers votre nouveau périphérique de stockage iSCSI, qui se trouve sur un autre réseau.
Dites que c'est sur le réseau Ethernet. Vous pouvez désormais vous déplacer facilement avec votre hyperviseur ou votre logiciel de virtualisation. Lorsque les commandes SCSI sortent de votre machine virtuelle, elles sont reçues par l'hyperviseur. Lorsque vous utilisez un autre adaptateur de stockage et que vous déplacez ces fichiers VMS vers l'autre baie de stockage, l'hyperviseur saura que vous avez apporté cette modification.
Cela redirigerait simplement ces commandes de stockage vers le nouvel emplacement et le point positif est que vous pouvez même le faire sans aucun temps d'arrêt sur votre machine virtuelle.
Regardons un autre scénario.
Supposons que vous disposiez de plusieurs hôtes et que vous choisissiez maintenant de prendre une machine virtuelle Linux et de déplacer l'état en direct de la machine virtuelle vers un autre hôte. Cela fonctionnera également, tant que l'autre hôte a la possibilité de se connecter au stockage partagé. Votre machine virtuelle pourra toujours accéder à son disque virtuel et à tous les autres fichiers critiques de machine virtuelle dont elle a besoin.
C'est ainsi que le stockage, la virtualisation et le stockage partagé contribuent à la mobilité. Vous pouvez prendre des machines virtuelles, les déplacer vers différents hôtes, déplacer leurs fichiers d'un système de stockage à un autre sans aucun temps d'arrêt.
Tout cela grâce à l'hyperviseur au milieu qui s'interpose entre la machine virtuelle et le matériel.
C'est ce qu'on appelle communément le découplage. Cela signifie que la machine virtuelle n'a de relation directe avec aucun matériel. Vous pouvez le déplacer d'un serveur physique à un autre. Vous pouvez également le déplacer d'un système de stockage à un autre. Il n'y a pas de relation fixe entre la machine virtuelle et le matériel spécifique. Ils sont découplés au vrai sens du terme.
Par conséquent, comme vous pouvez le voir, la mobilité est un avantage majeur de la virtualisation.
Une autre façon de voir les choses :
Supposons que vous ayez plusieurs hôtes et que de nombreuses machines virtuelles s'exécutent sur tous ces hôtes et que la charge de travail ne soit pas très équilibrée comme vous le souhaitez.
Si sur l'hôte un, vous avez trois machines virtuelles en cours d'exécution, vous souhaiterez peut-être migrer certains de ces VMS vers l'hôte deux pour égaliser la charge de travail sur ces deux hôtes.
Vous voulez vous assurer que l'utilisation des ressources de nos hôtes est utilisée de manière assez uniforme à tout moment.
Si l'hôte un manque de mémoire, vous pouvez déplacer certaines machines virtuelles vers un autre hôte et, idéalement, vous voudriez le faire sans aucun temps d'arrêt.
Vous pouvez effectuer une migration en direct et prendre une machine virtuelle en cours d'exécution et la déplacer d'un serveur physique à un autre sans temps d'arrêt. C'est l'une des principales raisons pour lesquelles vous voudrez peut-être migrer des machines virtuelles.
Une autre raison est également lorsque vous devez effectuer tout type d'activité de maintenance. Disons que vous pouvez installer de la mémoire physique et ajouter un autre hôte ou toute autre forme de maintenance physique.
Cela signifie que vous allez avoir des temps d'arrêt sur un hôte. Pour éviter cela, vous pouvez migrer toutes les machines virtuelles vers un autre hôte, effectuer une maintenance, installer de la mémoire ou tout ce que vous voulez, par exemple installer des correctifs ou effectuer un redémarrage nécessaire. Vous pouvez migrer toutes les machines virtuelles hors de cet hôte, faire tout ce dont vous avez besoin, puis les ramener une fois l'hôte sauvegardé. Tout cela peut se produire sans aucune interruption pour les utilisateurs.
Comment cela se fait :
Jetons un coup d'œil à un exemple, la migration, disons ici que nous avons une machine virtuelle en cours d'exécution sur l'hôte que vous souhaitez corriger. Vous devez également redémarrer cet hôte.
Vous devez donc initier une migration de cette VM de l'hôte un vers l'hôte deux.
Mais il y a quelques prérequis :
- Stockage partagé
- Fichiers de disque virtuel
- Fichiers de configuration
- Cartes réseau virtuelles
- Instantanés
Il s'agit d'une machine virtuelle qui a un accès au réseau et ce cou virtuel est connecté à un commutateur virtuel et il est disponible sur un VLAN.
Le commutateur virtuel est connecté à un commutateur physique et la machine virtuelle est adressée en conséquence.
Cette machine virtuelle existe sur un VLAN qui a un groupe de ports sur le commutateur virtuel. Si vous déplacez cette machine virtuelle vers un autre hôte et que le commutateur virtuel n'a pas de configuration correspondante, ce réseau deviendra indisponible.
Vous ne voulez pas ça.
Vous devez donc vous assurer que vous disposez d'un réseau compatible sur ces deux hôtes.
En termes simples, vous ne voulez pas que la machine virtuelle migrée voie quoi que ce soit de différent lorsqu'elle déplace l'hôte deux et vous voulez les processeurs compatibles que vous voulez comme ils l'étaient sur l'hôte un.
S'ils sont Intel sur l'hôte un, vous voulez qu'ils soient compatibles avec AMD sur l'hôte deux.
Vous voulez que ces deux hôtes soient aussi identiques que possible.
En ce qui concerne la configuration du réseau et du stockage, ils doivent évidemment correspondre.
Enfin, vous avez besoin d'un moyen d'effectuer le transfert de l'hôte un à l'hôte deux. Vous allez donc avoir un réseau spécial qui prend tout le contenu de la mémoire, prend ce qui se passe actuellement sur la machine virtuelle actuelle et en crée une copie sur l'autre hôte.
Une fois que vous avez couvert mes prérequis, le reste est assez simple.
Vous écrivez une copie de la VM qui va être créée sur un hôte de destination dans ce cas.
D'après la terminologie VMware, vous allez utiliser quelque chose appelé un port de noyau de machine virtuelle pour créer un réseau, et ce réseau sera utilisé pour créer une copie de la machine virtuelle actuelle sur l'hôte de destination.
Une fois cette copie terminée, vous capturerez tout ce qui a été modifié dans cette machine virtuelle au cours de ce processus de copie. Vous appelez cela un bitmap mémoire.
Tout le contenu de ce bitmap mémoire est transféré vers la nouvelle copie de la machine virtuelle et celle-ci devient votre machine virtuelle en cours d'exécution.
Le temps d'arrêt est tellement négligeable qu'il n'est même pas perceptible par les utilisateurs de vos applications. C'est ce qu'on appelle la migration en direct d'une machine virtuelle, lorsqu'elle est en cours d'exécution et déplacée d'un hôte à un autre.
This facilitates amazing flexibility, because you can move VMs wherever you need to.
Another notable advantage is automated load balancing.
You can group together hosts in what's called a cluster. Once you group those together, what you would now want is to allow your virtual machines to efficiently make use of the resources of the cluster as a whole.
You'll want to consider all of these hosts are interchangeable. It doesn't matter which host your VMs run on. If VMs need to move around to equalize workload, you can definitely make that to happen automatically.
That's the purpose of automatic load bouncing in VMware terminology.
This is also called distributed resource scheduler, in order to allow virtual machines to automatically be live migrated from host to host for the purposes of load balancing across themselves.
Converting physical servers to VMs
In this section, you'll learn about some concepts required to convert a physical machine to a virtual machine.
There are different software options out there to accomplish that.
Let's say you have a physical server with Ubuntu installed on it. It has all kinds of physical hardware like CPUs, RAM and network adapters and storage disks.
Our Ubuntu operating system has drivers for devices such as network adapters. It knows what kind of CPUs are being used:be it AMD or Intel CPUs. It has got a SCSI controller to connect to physical disks and the operating system is also aware of the actual physical hardware.
When we take this physical server and use one of our software tools to convert it to a virtual machine, the first step that happens is that virtual machine is created as virtual replica of the physical machine.
You're going to have a virtual machine present your hypervisor with the appropriate CPU, memory, network and storage specifications. It might not exactly match up with what we had in the physical server.
When you create a virtual machine, your goal should always be to rightsize that virtual machine. It's never to just take what the physical server had and duplicate it. The goal is always to right size it to give the virtual machine the correct resources that it needs to do its job (efficiently run applications) and nothing extra.
You'd want your resource consumption to be about 60, 70 percent utilization for CPU and the same for memory. You don't want them unutilized at 10 percent with four CPUs. That's not efficient.
You're also going to need a physical NIC, for the virtual machine and this is going to be a hardware change for the guest operating system.
So what would be most ideal to have is a network interface card that was specifically designed to run on a virtual machine, a good example of this is the VMware VMAX.
The beautiful thing about this, is that now the virtual machine has no relationship with actual physical hardware, so we get mobility by breaking out of specific hardware dependency everytime.
Other benefit that is often overlooked is the fact that as you virtualize, all of your OS instances(Linux/Mac/Windows) are going to have a similar set of virtual hardware. It allows you to standardize your operating system configuration.
You replace our physical hardware with virtual hardware and your physical hard disk with a virtual disk.
This is a file that could be on a local storage of the host, it could be on:
- a fibre channel
- a SCSI storage array
- an NFS server
What's most important is that you create this virtual disk and migrate all of the data from the source virtual machine to the virtual disk. When the power's on, it's got its new hardware with its new disk. From this point on, it should just work.
That's how you convert a physical server to a virtual machine.
Depending on which hypervisor you're using:
- VMware has vCenter converter
- Microsoft has VM converter
- Veeam has disk to VHD
You can start using these solutions on your existing physical servers, convert them to virtual machines and run them on your hypervisor. Helder has shared some tips on building homelab which is a good way to experiment.
Hope you found this detailed introduction to virtualization helpful. Please leave any feedback if you have in the comment section below. Merci.