Virtualisierung spielt in der heutigen Zeit eine entscheidende Rolle. Von der Desktop-Nutzung auf Verbraucherebene bis hin zu Cloud-Diensten auf Unternehmensebene gibt es eine Vielzahl von Anwendungen.
Dieser Leitfaden hilft Ihnen umfassend beim Einstieg in die Virtualisierung. Dadurch erhalten Sie als Student, Ingenieur oder sogar als CTO genügend grundlegendes Wissen, um verschiedene Arten der Virtualisierung zu verstehen und zu verstehen, wie sie heute in der Branche eingesetzt werden.
Dies ist ein riesiger Artikel, also lassen Sie mich zusammenfassen, worüber ich darin sprechen werde.
- Der erste Teil stellt Host-Betriebssysteme, virtuelle Maschinen (VMs) und Hypervisoren vor
- Der zweite Teil beschreibt wesentliche Komponenten der Virtualisierung:CPU, RAM, Netzwerk und Speicher
- Der dritte Teil beleuchtet die Vorteile der Virtualisierung
Fangen wir an!
Virtuelle Maschinen, Hosts und Hypervisoren
Um ein besseres Verständnis von virtuellen Maschinen, Hosts und Hypervisoren zu erlangen, ist es wichtig, dass Sie mit den Grundlagen der Hardware beginnen.
Zunächst benötigen Sie einen physischen Computer/Server, der die folgenden Komponenten enthält, aus denen das gesamte System besteht:
- Netzteil (PSU)
- Hauptplatine
- Zentraleinheit (CPU)
- Random Access Memory (RAM)
- Netzwerkschnittstellenkarte (NIC)
- Speicher – Festplatte (HDD) oder Solid State Drive (SSD)
Alle diese Komponenten werden zusammengebaut, die sich als eine einzige Recheneinheit synchronisieren und zu Ihrem eigenen Personal Computer (PC) oder Server werden. Warten Sie, ein persönlicher Server klingt interessant!
Was ist ein Betriebssystem (OS)?
Ein Betriebssystem ist eine Systemsoftware, die als Schnittstelle zwischen dem Benutzer und dem Computer fungiert, um eine Vielzahl von Anwendungen mit oder ohne grafische Benutzeroberfläche auszuführen. Eine dieser Anwendungen können beispielsweise dedizierte Virtualisierungsprogramme wie VirtualBox sein.
Was ist ein Hypervisor?
Ein Hypervisor ist eine Systemsoftware, die als Vermittler zwischen Computerhardware und virtuellen Maschinen fungiert. Es ist für die effektive Zuweisung und Nutzung von Hardwareressourcen verantwortlich, die von den jeweiligen virtuellen Maschinen verwendet werden, die einzeln auf einem physischen Host arbeiten. Aus diesem Grund werden Hypervisoren auch als Manager virtueller Maschinen bezeichnet.
Diese Systemsoftware fungiert als Schnittstelle zwischen dem Benutzer und dem Computer mit dem alleinigen Zweck der Virtualisierung, mit oder ohne grafische Benutzeroberfläche. Ein Beispiel für einen solchen Hypervisor ist VMware FXI.
Ein Hypervisor besteht aus drei Hauptmodulen:
Dispatcher — Es stellt den Einstiegspunkt des Monitors dar und leitet die von der Instanz der virtuellen Maschine ausgegebenen Anweisungen entweder an die unten beschriebenen Zuweisungs- oder Interpretermodule weiter.
Zuordnung – Immer wenn eine virtuelle Maschine versucht, eine Anweisung auszuführen, die zu einer Änderung der zugeordneten Maschinenressourcen führt, wird der Zuordner vom Dispatcher aufgerufen, der dann die Systemressourcen zuweist, die der virtuellen Maschine bereitgestellt werden sollen.
Dolmetscher — Es besteht aus Interpreter-Routinen, die immer dann ausgeführt werden, wenn eine virtuelle Maschine eine privilegierte Anweisung ausführt. Dies wird auch vom Dispatcher aufgerufen.
Sie müssen entweder ein Betriebssystem oder einen Hypervisor installieren, der als Schnittstelle für Sie fungiert, um mit einem physischen Host-Server/Computer zu interagieren.
Nehmen wir an, es ist Ubuntu Server, auf dem Sie verschiedene Anwendungen hosten oder ausführen können. Diese Anwendungen auf dem Server laufen innerhalb des Betriebssystems.
Durch die Verwendung der Hardware kann Ubuntu sie und die Menge der Ressourcen, auf die sie Zugriff haben, steuern.
Daher wird ein Betriebssystem oder Hypervisor zu einem Vermittler zwischen den Anwendungen und der Hardware selbst.
Was ist eine virtuelle Maschine (VM)?
Eine virtuelle Maschine ist eine Software, die alle Funktionen eines physischen Servers emuliert und auf einem Host-Betriebssystem oder einem Hypervisor ausgeführt wird.
Daher werden Sie Anwendungen nicht direkt auf dem physischen System ausführen. Sie werden auf virtuellen Maschinen ausgeführt, jede mit ihrem eigenen, unabhängigen Betriebssystem. Auf diese Weise können virtuelle Maschinen verschiedene Betriebssysteme einzeln innerhalb desselben physischen Systems ausführen.
Alle diese VMs können sich einen gemeinsamen Satz physischer Hardware teilen und sogar über ein virtuelles Netzwerk miteinander interagieren, genau wie es physische Computer tun.
Sie können eine Reihe virtueller Maschinen haben, jede mit ihrem eigenen unabhängigen Betriebssystem, die dieselben physischen Komponenten wie zuvor erwähnt gemeinsam nutzen und verwenden.
Ein Hypervisor oder eine Virtualisierungssoftware, die auf einem Betriebssystem ausgeführt wird, steuert tatsächlich die physischen Ressourcen.
Ein Hypervisor hat direkten Zugriff auf die physische Hardware und steuert, auf welche Ressourcen virtuelle Maschinen Zugriff erhalten.
Dazu gehören:
- Wie viel Arbeitsspeicher (RAM) zugewiesen wird
- Wie viel physischen CPU-Zugriff sie erhalten
- Wie greifen sie auf ihr Netzwerk zu
- Wie greifen sie auf ihren Speicher zu
Wenn mehr virtuelle Maschinen auf einer OS-Virtualisierungssoftware (verkürzen wir es auf OSVS) oder Hypervisor erstellt werden, teilen sie sich auch genau denselben Satz physischer Ressourcen.
Daher steuert OSVS oder Hypervisor:
- Wie Ressourcen für die einzelnen virtuellen Maschinen freigegeben werden
- Wie Ressourcen den einzelnen virtuellen Maschinen präsentiert werden
Arten von Hypervisoren
Werfen wir nun einen Blick auf die Arten von Hypervisoren und wie sie sich voneinander unterscheiden.
Typ-1-Hypervisor
Ein Hypervisor, der nativ installiert und direkt auf einem physischen Host ausgeführt werden kann, wird als Typ-1-Hypervisor bezeichnet.
Schlüsselhinweise
- Ein Typ-1-Hypervisor kann direkt auf einem Bare-Metal-System oder einem physischen Host installiert werden.
- Es muss kein Betriebssystem (OS) installiert oder verfügbar sein, um sich selbst auf einem Server bereitzustellen.
- Direkter Zugriff auf CPU, Speicher, Netzwerk, physischen Speicher.
- Die Hardwarenutzung ist effizienter und liefert die beste Leistung.
- Bessere Sicherheit, da keine zusätzliche Ebene für den Hardwarezugriff vorhanden ist.
- Jeder Typ-1-Hypervisor benötigt immer eine dedizierte physische Maschine.
- Kann mehr kosten und eignet sich besser für Unternehmenslösungen.
- VMware ESXi, Citrix Hypervisor und Microsoft Hyper-V sind einige Beispiele für Typ-1-Hypervisoren.
Typ-2-Hypervisor
Ein Hypervisor, der nicht nativ installiert werden kann und ein Betriebssystem benötigt, um auf einem physischen Host ausgeführt zu werden, wird als Typ-2-Hypervisor bezeichnet.
Schlüsselhinweise
- Ein Typ-2-Hypervisor kann nicht direkt auf einem Bare-Metal-System oder physischen Host installiert werden.
- Es erfordert, dass zuerst ein Betriebssystem installiert oder verfügbar ist, um sich selbst bereitzustellen.
- Indirekter Zugriff auf CPU, Arbeitsspeicher, Netzwerk, physischen Speicher.
- Aufgrund einer zusätzlichen Ebene (Betriebssystem) für den Zugriff auf Ressourcen kann die Hardwareauslastung weniger effizient sein und in der Leistung nachlassen.
- Mögliche Sicherheitsrisiken aufgrund der Verfügbarkeit des Host-Betriebssystems.
- Jeder Typ-2-Hypervisor benötigt keine dedizierte physische Maschine. Es können viele auf einem einzelnen Host vorhanden sein.
- Kann weniger kosten und eignet sich eher für Lösungen für kleine Unternehmen.
- VMware Workstation Player, VMware Workstation Pro und VirtualBox sind einige Beispiele für Typ-2-Hypervisoren.
Virtual-Machine-Dateien und Live-Status
Lassen Sie uns nun die Dateien verstehen, aus denen unsere virtuellen Maschinen bestehen, und wie sie gemeinsam genutzten Speicher nutzen.
Eine virtuelle Maschine nutzt den Arbeitsspeicher, die CPU, das Netzwerk und die Speicherhardware unseres physischen Hosts. Wie wird es gemacht?
Über den Hypervisor.
Wenn eine virtuelle Maschine ausgeführt wird, verfügt sie über bestimmte Informationen im Arbeitsspeicher. Diese Informationen sind Teil des Live-Status der VM.
Die VM ist also tatsächlich auf dem Host betriebsbereit. Immer wenn Sie ein Video abspielen oder einen Webbrowser auf der VM öffnen, finden diese Laufzeitvorgänge im Arbeitsspeicher der VM statt. Aber diese treten tatsächlich alle auf dem physischen Host auf. Dies ist der Live-Status jeder virtuellen Maschine.
Der Live-Zustand der virtuellen Maschine verarbeitet alle Laufzeitausführungen auf der CPU, weshalb dies auf dem Host geschieht.
Wenn Sie einen Browser öffnen, um eine Website zu laden, wird Netzwerkbandbreite durch die NIC geleitet, die auch Teil des physischen Hosts ist. All dies ist Teil des Live-Zustands einer VM, die Speicheradapter verwendet, um Datenverkehr an ein Speichergerät zu senden. Auch das geschieht live in Echtzeit auf dem Host.
Eine virtuelle Maschine hat keine physischen Festplatten. Wenn Sie Linux auf einer virtuellen Maschine ausführen, muss diese in der Lage sein, Daten auf und von einem physischen Laufwerk zu lesen und zu schreiben.
Dies bedeutet, dass der Zugriff auf eine physische Festplatte erforderlich ist. Die VM liest von und zu einem virtuell zugewiesenen Laufwerk und wird darauf ausgeführt. Aber die Vorgänge werden tatsächlich irgendwo auf ein physisches Speichergerät umgeleitet. Dies kann über ein Fibre-Channel-Netzwerk, ein Ethernet-Netzwerk oder die lokale Festplatte selbst erfolgen – direkt in der Hypervisor- oder Betriebssystem-Virtualisierungssoftware.
Virtuelle Maschinen müssen eine Reihe von Dateien für die Virtualisierungsverwaltung verwenden. Eine dieser Dateien repräsentiert ein virtuell zugewiesenes Laufwerk oder eine virtuelle Festplatte. Eine VM muss über diese Dateien von der virtuellen Festplatte lesen oder darauf schreiben. Der Datenverkehr wird dazu durch einen Speicheradapter geleitet.
Aus offensichtlichen Gründen könnte es viele solcher Dateien geben, die anderen virtuellen Maschinen entsprechen, die am selben physischen Ort auf der Festplatte gespeichert sind.
Lassen Sie uns nun darüber sprechen, wie virtuelle Maschinen heruntergefahren und wieder hochgefahren werden.
Um dies tun zu können, benötigt die VM Konfigurationsinformationen, die hauptsächlich den Live-Status umfassen:
- Wie viel Arbeitsspeicher soll die VM bekommen?
- Wie viel CPU soll es bekommen?
- Was ist die zugewiesene Festplattengröße?
- Wie würde die VM auf das Netzwerk zugreifen?
Auch hier werden alle diese Informationen in einer Datei gespeichert.
Lassen Sie mich alle Arten von Informationen eintragen, die Dateien der virtuellen Maschine speichern, um ihre volle Funktionalität sicherzustellen:
- Statischer oder dynamischer Speicher
- Konfigurationsinformationen
- BIOS-Informationen
- Schnappschüsse gemacht
Eine virtuelle Maschine speichert also zwei Arten von Zuständen:
Live-Status
Der Live-Status ist das, was in Echtzeit passiert, was, wie ich gerade besprochen habe, sein könnte:
- Wie viel aktueller Speicher verwendet wird
- Wie viel CPU verwendet wird
- Welche aktuellen Anwendungen verwendet werden
- Wie die Netzwerkbandbreite verwendet oder durchlaufen wird
Wenn der physische Host oder die darin enthaltene virtuelle Maschine ausfällt, gehen alle oben genannten Echtzeitinformationen verloren. Es ähnelt dem Trennen eines Computers.
Beständiger Zustand
Der persistente Zustand sind die Dateien dieser virtuellen Maschine, die dauerhaft gespeichert werden. Das wird ermöglicht durch:
- Speicherdateien
- Konfigurationsdateien
- Snapshot-Dateien
Die Dateien, die sich auf den persistenten Zustand beziehen, bilden die VM.
So wie wir Menschen ohne die richtige Ernährung nicht überleben können, müssen auch virtuelle Maschinen konsequent die richtige Zuweisung von Ressourcen haben. Das Fehlen dieser Ressourcen bedeutet, dass virtuelle Maschinen nicht optimal funktionieren.
Die vier wesentlichen Faktoren, ohne die VMs nicht ihre beste Leistung erzielen können, sind:
- Prozessor
- RAM
- Netzwerk
- Speicherung
CPU-Virtualisierung
Wie erhält eine virtuelle Maschine Zugriff auf die CPU-Ressourcen des physischen Hosts?
Der physische Host hat eine physische CPU. Nehmen wir zum Beispiel an, wir haben eine CPU mit 4 physischen Kernen. Wenn Sie nun zwei dieser physischen Kerne zuweisen möchten, weisen Sie beim Erstellen Ihrer virtuellen Maschinen zwei virtuelle CPUs zu. Das bedeutet, dass die virtuelle Maschine Zugriff auf 2 physische Prozessorkerne von der Haupt-CPU hätte, indem sie eine VM mit 2 virtuellen CPUs erstellt.
Diese Zuweisung bedeutet jedoch nicht, dass andere virtuelle Maschinen diese Kerne nicht nutzen können, was bedeutet, dass ich alle 4 Kerne einer anderen virtuellen Maschine zuweisen kann. Somit können diese Ressourcen von allen virtuellen Maschinen auf der Hypervisor- oder Betriebssystem-Virtualisierungssoftware gemeinsam genutzt werden.
Je nach Art der Arbeitslast sollten Sie die CPU-Kerne basierend auf der Notwendigkeit der virtuellen Maschinen zuweisen. Wenn eine VM mit 25 % CPU-Auslastung in Ordnung ist, könnten Sie die verbleibenden Ressourcen natürlich anderen VMs zuweisen.
Daher müssen Sie immer danach streben, Ihre virtuellen Maschinen immer entsprechend den Anwendungsanforderungen zu dimensionieren, insbesondere wenn es um CPU-Ressourcen geht.
Speichervirtualisierung
Lassen Sie uns nun verstehen, wie virtuelle Maschinen die Speicherressourcen des Hypervisors nutzen können.
Wie viel Arbeitsspeicher Sie einer virtuellen Maschine zuweisen können, hängt wiederum vom physischen Arbeitsspeicher (RAM) ab, den Sie auf Ihrem physischen Server haben.
Wenn Ihr Server beispielsweise über 8 GB RAM verfügt, können Sie 4 GB zuweisen und einen vollwertigen Ubuntu-Desktop auf Ihrer virtuellen Maschine ausführen. Der Ubuntu-Desktop "denkt", dass er 4 GB physischen Speicher hat. Aber was tatsächlich passiert, ist, dass dieser zugewiesene Speicher von den tatsächlichen 8 GB des physischen Speichers selbst abgebildet wird.
Wenn Sie der VM 4 GB zuweisen, kann sie nicht mehr Arbeitsspeicher als die zugewiesene Menge verwenden.
Wie bei CPUs bedeutet dies wiederum nicht, dass diese 4 GB jederzeit der VM gewidmet sind. Wenn die Anwendungen, die auf dieser VM ausgeführt werden, derzeit nicht so viel Arbeitsspeicher benötigen, kann eine andere VM bei Bedarf dieselbe Ressource nutzen.
Wenn eine Anwendung auf einer VM ausgeführt wird, weist das Betriebssystem (auf der VM) den Speicher basierend auf seiner eigenen Speichertabelle zu, und wenn es auf einer VM geschlossen wird, markiert das Betriebssystem diese Speicherseiten als frei. Da es sich jedoch nie des Vorhandenseins eines Hypervisors oder einer Virtualisierungssoftware "bewusst" ist, wird es den physischen Server niemals über diese Aufhebung der Zuordnung informieren.
Daher ist es die Aufgabe des Hypervisors oder der Virtualisierungssoftware, ständig in das Betriebssystem der VM zu schauen, um diese Zuordnungen zu überwachen und von Zeit zu Zeit ungenutzte Teile des Arbeitsspeichers anderen VMs zuzuweisen.
Im Gegensatz zu diesem gemeinsamen Aspekt der Arbeitsspeicherzuweisung zwischen virtuellen Maschinen können Sie auch eine Arbeitsspeicherreservierung für bestimmte VMs erzwingen, um einen bestimmten Teil des physischen Arbeitsspeichers zu verwenden. Dies bedeutet, dass andere VMs den reservierten Speicher nicht verwenden können, selbst wenn er nicht von der speicherreservierten VM verwendet wird. In der allgemeinen Praxis ist dieses Verfahren am besten zu vermeiden, da die gemeinsame Nutzung des Speichers am Ende des Tages eine effektive Ressourcennutzung gewährleistet.
Sie können dies auf gemeinsam genutzte und dedizierte Server beziehen, die über Linode bereitgestellt werden. Es ist wirtschaftlicher für gemeinsam genutzte Server in der täglichen Sysadmin-Praxis und -Produktion.
Netzwerkvirtualisierung
Eine Ubuntu-VM läuft auf einem Host auf einem Hypervisor oder einer Virtualisierungssoftware. Diese virtuelle Maschine hat eine sogenannte virtuelle NIC V-NIC. Das erweitert sich auf eine virtuelle Netzwerkschnittstellenkarte.
Das Betriebssystem (Ubuntu) weiß nicht, dass es in einer virtuellen Maschine läuft. Es erwartet also, dass es überall die gleiche Art von Hardware sieht, die es sehen würde, wenn es auf einem physischen Server laufen würde.
Wenn es um Netzwerkvirtualisierung geht, müssen Sie Ihrer virtuellen Maschine eine virtuelle Netzwerkschnittstellenkarte bereitstellen.
Ubuntu wird tatsächlich seine Treiber für eine Netzwerkschnittstellenkarte implementieren. Es wird als Gastbetriebssystem keine Ahnung haben, dass es nicht wirklich eine physische Netzwerkkarte ist.
Es handelt sich um eine virtuelle NIC, bei der es sich um gefälschte Hardware handelt, die unserer virtuellen Maschine präsentiert wird, als wäre sie echt. Wenn Sie also einen physischen Server mit einer physischen NIC haben, würden Sie Ihr Ethernet-Kabel vom Ethernet-Port zu einem physischen Switch verbinden.
Wenn Sie eine virtuelle Maschine mit einer virtuellen NIC haben, verbinden Sie sie mit einem Port auf einem virtuellen Switch, ähnlich wie Sie es mit einer physischen Maschine machen würden.
Daher werden wir in unserem Hypervisor oder unserer Virtualisierungssoftware etwas haben, das als virtueller Switch bezeichnet wird. Sie können mehrere virtuelle Maschinen mit diesem virtuellen Switch verbinden und sie können miteinander kommunizieren.
Solange Sie sie in dasselbe VLAN (virtuelles lokales Netzwerk) stellen, können sie über den virtuellen Switch genauso kommunizieren wie über jeden anderen physischen Switch.
Wenn Sie also eine einzelne VM mit einem virtuellen Switch verbunden haben, können Sie eine zweite VM verbinden. Dadurch wird das Senden von Datenverkehr von einer VM zu einer anderen direkt innerhalb dieses virtuellen Switches ermöglicht. Dieser Datenverkehr muss den Host niemals verlassen, solange sich diese virtuellen Maschinen im selben VLAN befinden. Solange sich diese VMs im selben VLAN befinden, können sie kommunizieren und der Datenverkehr muss nie das physische Netzwerk durchlaufen.
Aber hier ist ein wichtiger Punkt. Ein Teil des Netzwerkverkehrs müsste das physische Netzwerk durchqueren, daher benötigt der virtuelle Switch einen Uplink.
So wie ein physischer Switch Uplinks zu einem physischen Switch auf höherer Ebene oder einem physischen Router hat, benötigt auch unser virtueller Switch Uplinks. Diese Uplinks sind die eigentlichen physischen Adapter auf dem Host. Diese physischen Adapter werden P-NICs oder physische NICs oder VM-NICs genannt.
Eine physische Netzwerkschnittstellenkarte oder NIC ist immer in unsere modernen Motherboards auf unseren Servern integriert:
Aber wenn Sie möchten, können Sie sich auch für eine dedizierte NIC entscheiden, die für zusätzliches Networking an das Motherboard angeschlossen wird:
Wenn Sie einen Hypervisor auf einem Host erstellen, verfügt dieser Host über eine oder mehrere Netzwerkschnittstellenkarten, genau wie jeder andere Server.
Diese physischen Netzwerkschnittstellenkarten auf einem Host stellen eine Verbindung zu einem physischen Switch her, und dieser physische Switch wird Verbindungen zu Routern haben. Auf diese Weise wird der Datenverkehr ins Internet geleitet.
Durch diesen Mechanismus kann es auch eine Verbindung zu anderen physischen Servern herstellen, die sich im selben Rechenzentrum befinden.
Virtuelle Maschinen können also mit all diesen Komponenten mit oder innerhalb desselben physischen Servers kommunizieren.
Wenn der Datenverkehr tatsächlich den Host verlassen muss, um außerhalb des Hosts zu kommunizieren, um einen Router zu treffen und zu einem anderen VLAN oder einem anderen Netzwerk zu gelangen, wird dieser Datenverkehr aus der VM fließen.
Über den virtuellen Switch verbindet sich einer der virtuellen Switches mit dem physischen Netzwerk.
Wenn dieser Datenverkehr am physischen Switch ankommt, wird eine MAC-Tabelle nachgeschlagen (eine Aufzeichnung eindeutiger physischer Adressen).
Es stellt den entsprechenden Port für das entsprechende Ziel bereit, an das das Paket gesendet werden muss. Es könnte zum Internet oder zu einem physischen Host in Ihrem eigenen lokalen Netzwerk geleitet werden.
Dieser Mechanismus stellt jedoch sicher, dass alle Ihre virtuellen Maschinen mit allen Geräten in meinem physischen Netzwerk kommunizieren können. Das macht ein virtueller Schalter.
Die grundlegende Idee dabei ist, das Gastbetriebssystem auf der VM dazu zu bringen, zu „denken“, dass es eine physische Netzwerkschnittstellenkarte hat. Sie stellen Ubuntu also die gleichen Treiber zur Verfügung und es wird denken, dass es ein tatsächliches Hardwaregerät hat.
Wenn die Datenpakete gesendet werden, wird der Datenverkehr tatsächlich vom Hypervisor abgerufen, der ihn wie angewiesen an den entsprechenden virtuellen Switch weiterleitet.
Speichervirtualisierung
Nachdem Sie nun erfahren haben, wie VMs CPUs, Speicher und Netzwerk nutzen, können wir mit der letzten Ressource fortfahren:Speicher.
Lassen Sie mich noch einmal wiederholen, dass das Gastbetriebssystem keine Ahnung hat, dass es in einer virtuellen Maschine läuft. Eine VM hat keine dedizierte physische Hardware und dazu gehört auch eine Speicherfestplatte. Die VM hat keine dedizierte physische Festplatte.
Mit dem Netzwerk hatten wir eine virtuelle NIC.
Mit Speichervirtualisierung werden wir einen virtuellen SCSI-Controller haben, wenn wir darüber nachdenken, wie ein physischer Server mit internen Festplatten arbeitet. Wenn ein Betriebssystem Daten auf die Festplatte schreiben muss, generiert das Betriebssystem einen SCSI-Befehl.
Wenn Daten von der Festplatte gelesen werden müssen, generiert es einen SCSI-Befehl und sendet diesen Befehl an den SCSI-Controller, der mit physischen Festplatten verbunden ist. So arbeitet Ubuntu mit Speicher, es weiß nicht, dass es hier in einer virtuellen Maschine läuft.
Also müssen wir diese Illusion für das Gastbetriebssystem auch für Speichermechanismen aufrechterhalten.
Sie stellen also Linux (das auf der VM läuft) einen virtuellen SCSI-Controller zur Verfügung. Es wird so emuliert, als würde es echte physische Festplatten ausführen.
Wenn Ubuntu also irgendeine Art von Speicherbefehl ausführen muss, wird es denken, dass ich einen echten SCSI-Controller habe.
Wenn ein Speicherbefehl an den SCSI-Controller gesendet wird, leitet ihn der virtuelle SCSI-Controller (ein virtuelles Gerät) an den Hypervisor um. Die virtuelle Maschine sendet diese Speicherbefehle über ihren virtuellen SCSI-Controller und sie kommen beim Hypervisor an.
Der Hypervisor bestimmt von hier aus, was mit diesen Speicherbefehlen geschieht. Wenn die virtuelle Maschine über eine eigene VMDK- oder virtuelle Festplattendatei auf einer lokalen Festplatte verfügt, sendet sie diese Speicherbefehle einfach an diese Datei auf Ihrer lokalen Festplatte.
Abgesehen von dieser grundlegendsten Funktionalität könnte es auch sein
- ein Fibre-Channel-Speicher-Array
- ein Ethernet-basiertes iSCSI-Speicherarray
- Fibre Channel über Ethernet
Aber sie funktionieren alle auf ähnliche Weise.
Was sich unterscheiden würde, ist eigentlich das Netzwerk.
Wenn der Hypervisor diesen Speicherbefehl an einen Fibre Channel sendet, durchläuft dieser Speicherbefehl dieses Fibre Channel-Netzwerk, bis er schließlich auf der virtuellen Festplatte ankommt.
Unabhängig vom Hypervisor wird Ihre virtuelle Maschine eine virtuelle Festplatte haben.
Auf diese Weise gelangen die SCSI-Befehle von Ihrer virtuellen Maschine zu Ihrer virtuellen Festplatte, unabhängig davon, wo sich diese virtuelle Festplatte befindet.
Wenn eine Ubuntu-basierte virtuelle Maschine einen SCSI-Befehl generiert, sendet sie ihn an den virtuellen SCSI-Controller.
Der Hypervisor bestimmt den geeigneten Speicherort für dieses virtuelle Laufwerk und sendet ihn an den Speicheradapter, und der Speicherbefehl kommt im Datenspeicher an.
Diese Datendurchlaufänderungen werden tatsächlich in die Datei geschrieben, die die virtuelle Festplatte der virtuellen Maschine enthält. Es könnte .VMX, .VMDK oder ein anderer virtueller Dateityp sein.
Ich hoffe, Sie haben jetzt die Grundlagen der Netzwerk- und Speichervirtualisierung verstanden. Lassen Sie mich die Effizienz- und Mobilitätsvorteile der Virtualisierung hervorheben und auch, wie Sie physische Hosts in virtuelle Maschinen umwandeln können.
Vorteile der Virtualisierung
Bisher haben wir darüber gesprochen, wie die Virtualisierung im Wesentlichen durch die verschiedenen Modi des Ressourcenmanagements funktioniert. Lassen Sie uns nun über die vielen Hauptvorteile sprechen.
Konsolidierung
Lassen Sie uns zuerst über Effizienz sprechen.
Wenn Sie Ihre virtuelle Infrastruktur mit einem Fitnessstudio vergleichen, und einige von Ihnen haben dies vielleicht schon einmal erlebt.
Wenn Sie um den 1. Januar herum ins Fitnessstudio gehen, wird es im Fitnessstudio richtig voll.
Während der normalen Jahreszeit würde ein Fitnessstudio mit etwa 20 Laufbändern und 50 Trainingsgeräten ausreichen.
Aber wenn Sie ein Fitnessstudio besitzen, wissen Sie, dass im kommenden Januar zwei- bis dreimal so viele Leute dort sein werden und es produktiver wäre, die Größe Ihrer Umgebung zu verdreifachen.
Wenn all diese Leute merken, dass sie vielleicht nicht so gerne Sport treiben, gehen sie nicht mehr ins Fitnessstudio.
Von nun an können Sie das Fitnessstudio nach Bedarf verkleinern.
Das wäre jetzt auch ganz toll, wenn Sie das Gleiche mit der Hardware Ihres virtuellen Rechenzentrums machen könnten.
Wenn Sie sich mit Virtualisierung beschäftigen, kommen Sie auf die Idee des Cloud Computing, wo es zum Beispiel einen Anbieter oder Dienstleister wie Linode gibt. Damit können Sie eine Reihe temporärer virtueller Maschinen auf der Hardware einer anderen Person einrichten und diese geschäftige Zeit des Jahres für Ihre Kunden unterbringen.
Aber ohne Virtualisierung kommt man nicht wirklich zum Cloud Computing. Dies ist der erste Schritt auf diesem Weg zu dem, was wir einen Zustand der Elastizität nennen, in dem Ihre Infrastruktur schnell wachsen oder schrumpfen kann.
Virtualisierung ist ein Baustein für diese Art von Flexibilität. Es bietet uns die Möglichkeit, Workloads zu konsolidieren.
Unten sehen wir ein Rechenzentrum mit physischen Servern.
Als Best Practice sollte nicht auf jedem einzelnen dieser Server ein einzelnes Betriebssystem ausgeführt werden.
Überlegen Sie, wie viele zusätzliche Workloads Sie bewältigen könnten, wenn Sie 20 bis 30 Linux-Instanzen auf jedem einzelnen dieser Server ausführen würden, anstatt nur eine pro Server!
Das ist der größte Vorteil der Virtualisierung. Das ist der Vorteil, der diese Innovation ursprünglich zur Virtualisierung veranlasst hat:Konsolidierung.
Effizienz
Im folgenden Diagramm haben Sie drei verschiedene Server mit unterschiedlichen Rollen, die als einzelne physische Systeme in unserer Umgebung verfügbar sind:
Sie haben einen Druckserver, der 20 Prozent aller Ressourcen verbraucht, und das Gleiche gilt für den Web- und Datenbankserver.
Dies sind physische Server, die nicht wirklich alle ihre Ressourcen verwenden. Wenn Sie darüber nachdenken, haben Sie für all diese Hardware bezahlt, und wenn Sie nur 20 Prozent nutzen, verschwenden Sie 80 Prozent.
Durch das Stranden von Ressourcen auf einem physischen Host, der nur ein Betriebssystem ausführen kann, haben Sie jetzt zwei Möglichkeiten, dieses Problem zu lösen:
Sie könnten mit der Installation anderer Anwendungen auf unserem Server beginnen und mehrere Anwendungen auf demselben Server ausführen. Aber wenn Sie den Druckserver neu starten müssen, werden Sie sich Gedanken darüber machen, was sonst noch auf diesem Druckserver läuft?
Was können Sie durch Wartungsarbeiten an meinem Druckserver noch beeinflussen? Es wird zu viele voneinander abhängige Anwendungsfälle und -szenarien auf derselben Hardware geben, was die Effizienz erheblich beeinträchtigt.
Daher ist das, was wir am Ende meistens haben, nur Ressourcenverschwendung. Sie können stattdessen diese physischen Server loswerden und diese Workloads auf einem Hypervisor konsolidieren:
Durch diese Konsolidierung können Sie jetzt mehrere Betriebssysteminstanzen auf diesem Hypervisor ausführen. Jetzt können Sie sehr einfach und effizient maximieren, die Größe ändern und einen optimalen Punkt erreichen, der eine Ressourcenauslastung von 60 oder 70 % sein könnte.
Jetzt nutzen Sie also die erworbenen Ressourcen effizient, ohne sie zu überlasten.
Das ist unser ultimatives Ziel bei der Virtualisierung:die Investition in die hergestellte Hardware zu maximieren, ohne zusätzliches Kapital für Ressourcen zu verschwenden, die nie genutzt werden.
Mobilität
Ein weiterer großer Vorteil der Virtualisierung ist die Mobilität.
Wenn Sie sich daran erinnern können, wie Netzwerk- und Speichervirtualisierung funktioniert, stellen Sie sich hier ein Szenario vor, in dem Sie ein Fibre-Channel-Speicherarray haben. Nehmen wir auch an, dass Sie gerade in ein neues iSCSI-Speicher-Array investiert haben.
Angenommen, Sie haben Ihr Fibre-Channel-Speicher-Array und möchten diese virtuelle Maschine und alle ihre Dateien auf Ihr neues iSCSI-Speichergerät verschieben, das sich in einem anderen Netzwerk befindet.
Angenommen, es befindet sich im Ethernet-Netzwerk. Mit Ihrem Hypervisor oder Ihrer Virtualisierungssoftware können Sie jetzt ganz einfach umziehen. Wenn die SCSI-Befehle von Ihrer VM kommen, werden sie vom Hypervisor empfangen. Wenn Sie einen anderen Speicheradapter verwenden und diese VMS-Dateien auf das andere Speicherarray verlagern, erkennt der Hypervisor, dass Sie diese Änderung vorgenommen haben.
Es würde diese Speicherbefehle einfach an den neuen Speicherort umleiten, und der Pluspunkt ist, dass Sie dies sogar ohne Ausfallzeiten auf Ihrer virtuellen Maschine tun können.
Sehen wir uns ein anderes Szenario an.
Angenommen, Sie haben mehrere Hosts und entscheiden sich nun dafür, eine Linux-VM zu nehmen und den Live-Status der VM auf einen anderen Host zu verlagern. Das wird auch funktionieren, solange der andere Host die Möglichkeit hat, sich mit dem gemeinsam genutzten Speicher zu verbinden. Ihre VM kann weiterhin auf ihre virtuelle Festplatte und alle anderen wichtigen VM-Dateien zugreifen, die sie benötigt.
So tragen Storage, Virtualisierung und Shared Storage zur Mobilität bei. Sie können virtuelle Maschinen nehmen, sie auf verschiedene Hosts verschieben und ihre Dateien ohne Ausfallzeiten von einem Speichersystem auf ein anderes verschieben.
Das liegt alles am Hypervisor in der Mitte, der sich zwischen die virtuelle Maschine und die Hardware schiebt.
Dies wird im Volksmund als Entkopplung bezeichnet. Dies bedeutet, dass die virtuelle Maschine keine direkte Beziehung zu irgendeiner Hardware hat. Sie können es von einem physischen Server auf einen anderen verschieben. Sie können es auch von einem Speichersystem auf ein anderes verschieben. Es gibt keine feste Beziehung zwischen virtueller Maschine und spezifischer Hardware. Sie sind im wahrsten Sinne des Wortes entkoppelt.
Daher ist Mobilität, wie Sie sehen, ein großer Vorteil der Virtualisierung.
Eine andere Betrachtungsweise:
Angenommen, Sie haben mehrere Hosts und viele virtuelle Maschinen, die auf all diesen Hosts ausgeführt werden, und die Arbeitslast ist nicht so ausgeglichen wie gewünscht.
Wenn auf Host eins drei virtuelle Maschinen ausgeführt werden, möchten Sie möglicherweise einige dieser VMS auf Host zwei migrieren, um die Arbeitslast auf diesen beiden Hosts auszugleichen.
Sie möchten sicherstellen, dass die Ressourcenauslastung unserer Hosts jederzeit ziemlich gleichmäßig ausgelastet ist.
Wenn der Arbeitsspeicher von Host eins sehr knapp wird, können Sie einige VMs auf einen anderen Host verschieben, und das am besten ohne Ausfallzeiten.
Sie können eine Live-Migration durchführen und eine laufende VM ohne Ausfallzeit von einem physischen Server auf einen anderen verschieben. Das ist ein wichtiger Grund für die Migration von VMs.
Ein weiterer Grund ist auch, wenn Sie Wartungsarbeiten jeglicher Art durchführen müssen. Angenommen, Sie können etwas physischen Speicher installieren und einen weiteren Host oder eine andere Form der physischen Wartung hinzufügen.
Dies bedeutet, dass Sie Ausfallzeiten auf einem Host haben werden. To prevent that, you can migrate all of the VMs to another host, perform maintenance, install memory or whatever you want to, say installing patches or carrying out a necessary reboot. You can migrate all VMs off of that host, do whatever you need to and then bring them back once the host is back up. All this can happen without any disruption for users.
How this is done:
Let's take a look at an example, migration, Say here we have a virtual machine running on host one you want to patch up. You also need to reboot this host.
So you have to initiate a migration of this VM from host one to host two.
But there are some prerequisites:
- Shared storage
- Virtual disk files
- Configuration files
- Virtual NICs
- Snapshots
This is a VM that has network access and that virtual neck is connected to a virtual switch and it's available on a VLAN.
The virtual switch is connected to a physical switch and the virtual machine is addressed accordingly.
This VM exists on some VLAN that's got a port group on the virtual switch. If you move this VM down to another host and the virtual switch there does not have a matching configuration, that network would become unavailable.
You don't want that.
So you must ensure you have a compatible network on both of these hosts.
Simply said, you don't want the migrated VM to see anything different when it moves the host two and you want the compatable processors you want as they were on host one.
If they're Intel on host one, you want them to be compatible with AMD on host two.
You want these two hosts to be as much identical as you can possibly make them.
When it comes to the network and storage configuration, they obviously need to match up.
Finally, you need a way to perform the transfer from host one to host two. So you're going to have a special network that takes all of the contents of memory, takes what's currently happening on the current VM and creates a copy of it on the other host.
Once you've covered my prerequisites, the rest of it is pretty straightforward.
You write a copy of the VM that is going to be created on a destination host in this case.
Based on VMware terminology, you're going to use something called a VM kernel port to create a network, and that network is going to be used to create a copy of the current VM on the destination host.
When that copy is complete, you will capture everything that's changed in that VM during that copy process. You call this a memory bitmap.
All of the contents of this memory bitmap are transferred over to the new copy of the VM and that becomes your live running virtual machine.
The downtime is so negligible, that it's not even perceptible to the users of your applications. This is called live migration of a virtual machine, while it's running and moved from one host to another.
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. Thank you.