Runecast-Akademie
4
:

Virtuelle Maschinen

Werfen Sie einen tieferen Blick auf verschiedene Aspekte virtueller Maschinen (VMs) in der E-Learning-Serie der Runecast Academy über Virtualisierungstechnologien.

Virtuelle Maschinen

Willkommen zurück! Bisher haben wir in dieser Serie die Grundlagen der Virtualisierung und die Bedeutung eines Hypervisors behandelt. In Teil 4 stellen (und beantworten) wir zwei wichtige Fragen und erklären ein paar andere Dinge.

Zum Beispiel:

  • Eine virtuelle Maschine... was ist das?
  • Virtuelle Festplatten, Auslagerungsdateien, Hostprotokolle, Speicher-Snapshots und mehr!
  • "Was bedeutet das alles?!" (AKA "Das ist kein Voodoo")

Zu Beginn dieses Artikels werden wir uns auf VMware vSphere konzentrieren (was es uns ermöglicht, die Themen näher zu betrachten), aber beachten Sie, dass die meisten dieser Prinzipien auch für andere Virtualisierungsplattformen gelten.

Was ist eine virtuelle Maschine?

Während der Hypervisor die dem Host zur Verfügung stehenden physischen Ressourcen in Slices darstellt, die je nach Bedarf genutzt werden können, sind virtuelle Maschinen (VMs) die Objekte, die diese Ressourcen verbrauchen. Eine VM ist wie eine normale Maschine - sie hat Zugriff auf Rechen-, Speicher- und Netzwerkressourcen. Wie der Hypervisor nimmt auch die virtuelle Maschine die Konzepte, aus denen ein physischer Computer besteht, und unterteilt sie in einige CPU-Slices, einige RAM-Blöcke, eine virtuelle Netzwerkkarte (NIC)... und alles andere wird als Dateien dargestellt.

Virtuelle Festplatten

Es ist zwar möglich, dass eine VM direkt auf ein Blockspeichergerät (z. B. eine SCSI-Festplatte) zugreift, und in der Vergangenheit gab es auch einige gute Gründe dafür, aber die überwiegende Mehrheit der Nutzung von VM-Speicher erfolgt über das Konstrukt der virtuellen Festplatte.

Ein virtuelles Laufwerk ist nur eine Datei auf dem Host-Betriebssystem (OS). Eigentlich stimmt das nicht ganz: Eine virtuelle Festplatte besteht normalerweise aus einer Reihe von Dateien, die jedoch als eine oder mehrere Festplatten dargestellt werden. Auf dem Screenshot des vSphere-Clients (mehr zur Verwaltung später in der Serie!) sehen wir eine VM, die eine einzelne virtuelle Festplatte hat:

Diese virtuelle Festplatte befindet sich auf dem NFS-Datenspeicher (mehr zum Thema Speicher später in dieser Serie!) und heißt "Lab Jumpbox.vmdk". Es handelt sich um eine Thin-Provisioning-Lösung, auf die wir in einem eigenen Kapitel über Speicher genauer eingehen werden. Schauen wir uns diese VMDK-Datei in der Befehlszeilenschnittstelle (CLI) an.

Wow, abgesehen davon, dass das eine riesige Textwand ist... Hatten wir nicht gesagt, dass wir nur eine virtuelle Festplatte haben? Was hat es mit den anderen Dateien auf sich?

Die Datei "Lab Jumpbox.vmdk" ist eigentlich eine Deskriptor-Datei, weshalb sie nur 554 Byte groß ist. Diese Datei zeigt an, wo sich die eigentlichen Daten im großen Ganzen befinden. Werfen wir einen Blick hinein.

Ok, das sind eine Menge Informationen. Wir können sehen, dass die eigentliche Datendatei "Lab Jumpbox-flat.vmdk" heißt. In diese Datei werden unsere Daten geschrieben, und wenn wir auf den vorherigen Screenshot zurückgreifen, können wir sehen, dass diese Datei 40 GB groß ist. Daraus können wir auch einige andere Dinge ablesen: den Adaptertyp, an den sie angeschlossen ist, ob sie Thin Provisioning betreibt, ob und welche Version der VMware Tools auf der VM installiert ist und auch die Version der virtuellen Hardware (auch als VM-Kompatibilitätsebene bekannt) der VM. All diese Dinge werden in dieser Serie näher erläutert.

Hoffentlich macht das Sinn? Was war das auf der Rückseite? Eine Frage dazu, was all diese anderen Dateien sind? Wir sind froh, dass Sie gefragt haben! Die anderen Dateien, die wir im ersten Terminal-Screenshot sehen, sind die .vswp-Datei, die .hlog-Datei, die .vmsn-Datei, die .nvram-Datei und die .vmx-Datei. Es gibt noch ein paar andere Dateien, die aber nicht zu den Kernkomponenten der VM gehören.

Auslagerungsdatei

Diese Datei ist die .vswp-Datei, und wenn Sie keinen Speicher für die VM reservieren, hat sie die gleiche Größe wie der der VM zugewiesene RAM-Speicher. Dies ist erforderlich, damit physische Speicherseiten auf die Festplatte ausgelagert werden können, falls der physische Speicher knapp wird. Dies ist zwar nicht wünschenswert (da der auf die Festplatte ausgelagerte Speicher um Größenordnungen langsamer ist als der physische RAM-Speicher), aber es handelt sich um einen Mechanismus, mit dem Sie VMs mehr Speicher zuweisen können, als Sie tatsächlich auf Ihren Servern installiert haben.

Host-Protokoll

Die .hlog-Datei wird verwendet, um die Migration der virtuellen Maschine von einem Datenspeicher zu einem anderen zu verfolgen.

Speicher-Schnappschuss

Diese Datei wird erstellt, wenn Sie einen Snapshot erstellen, der den Speicher der VM enthält. Wenn Sie einen Snapshot erstellen, ohne den Speicher zu erfassen, befindet sich Ihre VM bei der Wiederherstellung des Snapshots in einem ausgeschalteten Zustand. Ein Speicher-Snapshot wird zwar standardmäßig erstellt, wird aber normalerweise nur für forensische Zwecke verwendet.

Schnappschuss-Deskriptor

Dies ist die .vmsd-Datei, die dazu dient, Snapshot-Delta-Platten zu verwalten. Wenn ein Snapshot erstellt wird, wird die ursprüngliche Basisplatte schreibgeschützt und eine neue Datei -delta.vmdk wird erstellt, die alle Schreibvorgänge verarbeitet. Diese Dateien sind anfangs klein, können aber schnell anwachsen, wenn eine große Menge an Festplatteneingaben erfolgt. Aus diesem Grund wird empfohlen, Snapshots nur so lange wie unbedingt nötig aufzubewahren. Snapshots sind eine gute Möglichkeit, eine Änderung zu sichern, aber sie sind absolut kein Backup. Seien Sie nicht so ein Typ...

Es gibt einige Gründe, warum Sie Snapshots nicht als Sicherungskopien verwenden oder sie lange aufbewahren sollten. 

Erstens können Sie bei einem Verlust Ihrer VM nicht von einem Snapshot wiederhergestellt werden (da der Snapshot ein Teil der VM-Konstruktion ist). 

Zweitens: Um den von einem Snapshot belegten Speicherplatz zurückzufordern, benötigen Sie möglicherweise bis zu 100 % des Snapshots als freien Speicherplatz, während die Blöcke in die VMDK-Basisdatei übertragen werden. Wenn Ihnen der Speicherplatz ausgeht, können Sie den Snapshot nicht einfach löschen. 

Drittens hat die Verwendung von Snapshots Auswirkungen auf die Leistung. Je länger die Kette wird (je mehr Snapshots Sie hinzufügen), desto größer sind die Auswirkungen auf die Leistung. Wenn Sie Ihre ursprüngliche Leistung beibehalten wollen, müssen Sie Snapshots so kurz wie möglich in Betrieb halten.

Es gibt noch weitere Gründe, die gegen langlebige Druckknöpfe oder lange Schnappschussketten sprechen, aber das sind die wichtigsten.

NVRAM-Datei

Diese Datei enthält die BIOS-Einstellungen für die VM. Wenn Sie VM Encryption verwenden, enthält diese Datei auch den Verschlüsselungsschlüssel zum Starten der verschlüsselten VM (und ist tatsächlich auch verschlüsselt, allerdings mit einem anderen Schlüssel).

VMX/VMXF-Dateien

Diese 2 Dateien enthalten die Konfiguration der betreffenden VM. Wenn Sie eine neue VM im vSphere-Client erstellen, werden die von Ihnen getroffenen Auswahlen (neben anderen Daten) in die VMX geschrieben. Es wird empfohlen, diese Dateien niemals von Hand zu bearbeiten, da selbst eine falsche Syntax katastrophale Folgen haben kann. Diese Dateien können nicht direkt bearbeitet werden, wenn die VM eingeschaltet ist.

Was bedeutet das alles?

Ich hoffe, Sie haben jetzt verstanden, dass es sich bei einer virtuellen Maschine nicht um Voodoo handelt. Eine virtuelle Maschine besteht aus einem Haufen Dateien und läuft auf einer Art Hypervisor (siehe das letzte Kapitel, um mehr darüber zu erfahren, was ein Hypervisor ist). Hier führen Sie Ihre Anwendungen aus, und das VM-Konstrukt ermöglicht es, diese Anwendungen von einem physischen Server auf einen anderen zu verschieben, so dass Sie geplante Ausfallzeiten für Hardware-Upgrades verwalten können, ohne die Anwendung außer Betrieb zu setzen.

Das bedeutet auch, dass Sie dieselbe Fähigkeit nutzen können, um Ihre bestehenden Arbeitslasten zu einem Cloud-Service-Anbieter zu verlagern, z. B. VMware Cloud on AWS, Microsoft Azure VMware Solution oder Google Cloud VMware Engine, ohne die Anwendung neu erstellen zu müssen.

Sie können auch Tools wie VMware Site Recovery Manager, Zerto und Veeam Backup & Replication verwenden, um Ihre VM als Teil einer Business Continuity/DisasterRecovery-Strategie an einem anderen Standort zu replizieren.

In unserem nächsten Runecast Academy-Artikel tauchen wir in die Welt der Speicherung ein.

Kev Johnson

Kev ist ein altgedienter Systemadministrator, Technologieberater und 5-facher vExpert. Bevor er als Systemingenieur zu Runecast kam, war er Technical Marketing Architect für vSphere Lifecycle bei VMware. Außerhalb der Arbeit sind seine Leidenschaften schottischer Fußball, Käse, Craft-Biere, Reisen und scharfes Essen. Sie finden Kev in seinem Blog https://v-it.pro und als Co-Moderator des OpenTechCast-Podcasts. Sie finden ihn auf Twitter unter @kev_johnson.

Alle Artikel der Akademie
Keine Artikel gefunden.