Wird ein VMWare-Snapshot permanent ausgeführt, was die Leistung beeinträchtigt?

Ich verstehe, dass die VMWare-KB bei langen Snapshots hauptsächlich aus zwei Gründen die Stirn runzelt (meiner Meinung nach)

Das Aufnehmen von tonnenweise Schnappschüssen kann den Datenspeicher füllen. Schnappschüsse sind einfach Delta-Dateien. Nehmen wir an, Sie haben ein fast volles VMDK mit 50 Gig und machen einen Schnappschuss. In deinem Schnappschuss drehst du jedes einzelne Bit um. Ihre Delta-Datei wird auch etwa 50 GB groß sein. Snapshot nochmal, flip the bits, eine weitere 50 Gig Delta Datei. Diese können schnell außer Kontrolle geraten.
Das Festlegen großer Schnappschüsse birgt Risiken. Bei der Konsolidierung von Snapshots werden die Delta-Änderungen in das ursprüngliche VMDK geschrieben. Dies nimmt Zeit in Anspruch und birgt das Risiko, dass Sie Ihre VMDK im Falle eines Ereignisses aufgerieben haben.

Ihre Warnungen scheinen logisch zu sein.

Ist es angesichts dessen von Natur aus schlecht, meinen Computer permanent von einem Snapshot-VMDK aus zu betreiben? Ich möchte aus meinem Baum folgendes machen:

Base
- Snap1
  - Fang 2
  - Du bist da

Die Snaps 1 und 2 werden sofort nach der Installation und Bereitstellung des Basissystems ausgeführt. Dies sind Maschinen, die ich regelmäßig aktualisieren möchte, damit mein Baum einfach wie folgt aussieht:

Base
- Snap1
  - Du bist da
  - Fang 2

Löschen Sie Snap2 und erstellen Sie Snap2 neu.

Ich kann nicht sehen, wie sich dies aus den folgenden Gründen auswirken könnte:

Da ich einfach ein Basis-Image installiert habe und meine Deltas sofort nach dem letzten Versuch aufgenommen habe, konnte ich möglicherweise den Datenspeicher füllen. Angenommen, mein Basis-Image hat nur 10 GB (auf einer Thin Provisioning-Festplatte mit 50 GB), und selbst wenn mein Delta jedes einzelne Bit umgedreht hat, beträgt meine maximale Gesamtnutzung 60 GB (10 GB Basis-VMDK, die gesperrt ist, + 50 GB Delta-In) die Snapshot-VMDK-Datei). Dies setzt voraus, dass ich keine weiteren Schnappschüsse erstelle.
Da mein Anwendungsfall keine Konsolidierung der Snapshots erfordert, riskiere ich keine Fehler bei der Konsolidierung meiner Deltas. Wenn ich zurück zu Snap1 gehe und Snap2 lösche, wird das gesamte Delta, das sich in Snap2 befand, einfach gelöscht.
Die Speicherlast ist genau gleich, daher sollte ich die gleichen IOPS erhalten. Ich verstehe, dass einige Dateien (hauptsächlich Systemdateien) auf dem ursprünglichen VMDK vorhanden sein werden und andere (alles nach der Basis) im Delta gespeichert sein werden, aber ich sehe nicht, wie ESXI sich dafür interessieren würde. Alle Dateien befinden sich im selben physischen Datenspeicher, sodass die Leistung der Referenzierung aller Elemente im ursprünglichen VMDK ohne Snapshots entsprechen sollte.

Irgendwelche Gedanken? ESXI 5.5 mit dem Datenspeicher als RAID-DAS.

Ich besitze keine vCenter-Lizenz, sodass das Vorlagen- und Klonenproblem nicht mehr besteht.

Testergebnisse

Ich bin heute früh angereist, um ein paar Tests durchzuführen. Hier sind die Ergebnisse. Es gibt eine Leistungsstrafe, aber ich weiß nicht warum.

Vor dem Schnappschuss:

Nach dem Schnappschuss: Nach dem Shapshoting

— VM_Storage_Inception
quelle

Nicht sicher - mit der Zeit werden die Schnappschüsse immer weiter auseinander gehen. Schließlich handelt es sich um grundsätzlich unterschiedliche Kopien. Konvertieren Sie den Snapshot in ein völlig separates Volume, nachdem Sie nicht mehr viel Speicherplatz durch Snapshots verschont haben. Wie? Normalerweise verwende ich dd von einer dritten VM, aber meistens bin ich hier fast für solche ketzerischen Meinungen wie diese gekreuzigt. :-) Aber: es wird funktionieren und wird effektiv sein .

— Peter sagt wieder Monica

@PeterHorvath - Das ist das Zeug, das ich gerne höre. Smarte, hackige, effektive und einfache Lösungen. Wenn es Ihnen nichts ausmacht, können Sie mir schreiben, was Sie in Pastebin oder so machen? Bestimmen Sie das VMDK und den Snapshot gemeinsam?

— VM_Storage_Inception

Wenn ich das öfter machen musste, habe ich es mit einem Skript gemacht. Aber das ist nicht der Fall, und in den meisten Fällen verwende ich nicht einmal Schnappschüsse, weil sie langsam sind.

— Peter sagt wieder Monica

Antworten:

Ja, es gibt Auswirkungen auf die Leistung von Snapshots mit langer Laufzeit. Es gibt noch größere Auswirkungen auf die Konsolidierung von Delta-VMDKs auf die ursprüngliche Festplattendatei. Dies kann dazu führen, dass das Betriebssystem Ihrer VM nicht mehr reagiert oder ein anderes unerwünschtes Verhalten auftritt.

In VMware sind Vorlagen- und Klonfunktionen in vCenter integriert. Sie benötigen eine vSphere Essentials-Lizenz im Wert von 600 USD, um dies zu ermöglichen.

Sie können eine VM nach Ihrem Geschmack erstellen und sie dann in eine Vorlage klonen. Diese Vorlage kann dann verwendet werden, um neue virtuelle Maschinen aus einem "Golden Master" -Image zu generieren .

Bildbeschreibung hier eingeben

Auf diese Weise können Sie einen "bereinigten Status" haben, aber auch dauerhafte oder permanente VMs aus diesem Master-Image erstellen. Schnappschüsse sind nicht erforderlich.

— ewwhite
quelle

Interessant, ich werde das untersuchen und sehen, wie es funktioniert. Leider besitze ich keine vCenter-Lizenz und möchte von meiner Organisation nicht die 600 US-Dollar zahlen lassen, wenn die in der von mir beschriebenen Weise verwendeten Snapshots keine Auswirkungen auf die Leistung haben. Auch das Templating und Klonen scheint nicht anders zu sein, als eine OVA zu nehmen und erneut bereitzustellen. Das Löschen der Snapshots scheint viel schneller zu sein, und ich kann logischerweise nicht erkennen, wie sich dies auf die Leistung auswirken würde, selbst wenn es sich nicht um die "Offizielle VMWare-genehmigte Methode" handelt.

— VM_Storage_Inception

Könnten Sie mich auf einen Artikel verweisen oder erläutern, welche Auswirkungen die Leistung haben würde, um auf Ihre Bearbeitung zu antworten? Ich kann nicht sehen, wie es welche geben würde, wenn ich sie so benutze, wie ich sie beschreibe. Außerdem würde ich die Snapshots niemals wieder auf das ursprüngliche VMDK konsolidieren.

— VM_Storage_Inception

Ich denke, ich versuche zu verstehen, warum Sie darauf bestehen, ein Feature zu entwerfen, das für den kurzfristigen Zugriff vorgesehen ist.

— ewwhite

@VM_Storage_Inception - Es hört sich fast so an, als wollten Sie den Ansatz eines armen Mannes für VMWares verstorbenes Produkt Lab Manager.

— TheCleaner

Manchmal ist es sinnvoll , die richtige Lösung zu kaufen . Sie haben sich mehr Mühe und Arbeitszeit gegeben, um nach einer Problemumgehung zu suchen, als nur eine vSphere Essentials-Lizenz (600 US-Dollar) zu bezahlen, mit der Sie eine unterstützte Vorlage / Klonoption erhalten.

— ewwhite

Die Antwort von ewwhite ist richtig, aber nur um die Leistung ein wenig zu verbessern, betrachten Sie das folgende Szenario:

Sie erstellen eine VM. Ein virtueller Lesevorgang vom VMDK erfordert einen physischen Lesevorgang mit derselben Größe. Ziemliech direkt.

Stellen Sie sich nun vor, Sie machen einen Schnappschuss der VM. Jetzt müssen Sie für jeden virtuellen Lesevorgang zwei physische Lesevorgänge ausführen, einen vom Basis-VMDK und einen vom Delta-VMDK, da Sie Informationen von beiden benötigen, um den aktuellen Status abzurufen. Sie haben jetzt die doppelte Anzahl an Lesevorgängen für die physische Festplatte.

Bei zwei Schnappschüssen führen Sie drei Lesevorgänge durch und so weiter. Wenn Sie viele Schnappschüsse haben, können Sie sehen, dass dies eine ziemlich erhebliche Leistungseinbuße sein kann. Dies bedeutet nicht unbedingt eine um das n-fache schlechtere Leistung (aufgrund von Caching, nicht geänderten Abschnitten usw.), ist jedoch keine gute Vorgehensweise.

— tfrederick74656
quelle

Ich bin mir fast sicher, dass Snapshots eine Tabelle verwenden, die besagt, welcher Block in welcher Datei ist. Das Lesen eines einzelnen Blocks führt also dazu, dass nur ein Block aus der entsprechenden Datei gelesen wird. Das Lesen mehrerer Blöcke kann natürlich dazu führen, dass auf mehrere Dateien zugegriffen wird. Dies bedeutet eine Strafe für das Verschieben von Plattenköpfen, wenn Sie nicht von einer SSD ausgeführt werden, aber die Gesamtzahl der Zugriffe auf Plattenblöcke sollte sich nicht ändern.

— Guntram Blohm unterstützt Monica

So wie ich es verstehe, speichern Snapshots nur Änderungen von der Originaldiskette. Wenn Sie Datei A speichern, einen Schnappschuss erstellen und dann Datei A erneut ändern, werden nur die Änderungen an dieser Datei in den Schnappschuss geschrieben. Daher müssen Sie sowohl das ursprüngliche VMDK als auch den Snapshot lesen, um die gesamte Datei abzurufen. Andernfalls wäre jeder Schnappschuss einfach eine vollständige Kopie der Originalfestplatte, was sie nicht sind.

— Tfrederick74656

Das mag richtig sein, aber die Gesamtanzahl der zu lesenden Blöcke bleibt gleich (z. B. 10 Blöcke vom Snapshot und 100 Blöcke von der Basisplatte). ESXi überprüft zunächst die vorhandenen Snapshots auf die benötigten Blöcke, bis der richtige Snapshot (oder die Basisfestplatte) gefunden wird. Möglicherweise wird eine geringfügige Strafe verhängt, da das System den Teil, der den Snapshot durchläuft, wahrscheinlich vollständig überspringt, wenn überhaupt kein Snapshot vorhanden ist. Darüber hinaus wird eine Snapshot-Datei mit langer Laufzeit möglicherweise stark fragmentiert.

— Dirk Trilsbeek

Ein virtuelles Festplatten-Snapshot-System, das N-Lesevorgänge für N-Snapshots ausführt, wäre eine sehr dumme Implementierung. Ich bezweifle, dass es so in VMWare implementiert ist. Eine einfache Optimierung kann durch einfaches Erstellen einer Indexdatei erfolgen, in der gespeichert wird, in welcher Datenträgerdatei sich die einzelnen Blöcke des emulierten Laufwerks befinden. Angenommen, Sie haben eine virtuelle 512-GB-Festplatte mit einer Blockgröße von 4 KB. Sie benötigen nur einen 64-MB-Index, um in konstanter Zeit zu bestimmen, welche der bis zu 16 virtuellen Festplattendateien einen Block enthält.

— Lie Ryan

Aufgrund der Antworten in serverfault.com/questions/430138 muss ich nicht zustimmen. Ich habe immer an Schnappschüsse gedacht, die das Ergebnis einer binären Arithmetik sind, nicht nur eine Sammlung neuer Daten. Wenn Sie also die Bits 01010101 in Ihrem Basis-VMDK haben, erstellen Sie einen Snapshot und ändern Sie diese Bits in 10101010. Ihr Delta würde dann 11111111 enthalten (was anzeigt, dass sich jedes Bit in der Originaldatei geändert hat, NICHT der neue Wert von 10101010). Soweit ich dem obigen Kommentar zustimme, handelt es sich bei VMDKs angeblich um Rohdateien. Wo soll der Index gespeichert werden? Ich habe dies noch nie in VMWare-Pubs gesehen.

— Tfrederick74656

VMware ESX-Snapshots sind für die kurzfristige Verwendung gedacht.

Eine lange Nutzung und hohe E / A-Belastung können zum Einfrieren der VM führen. Wenn Sie den Fall haben, dass die Schreib-E / A größer / schneller als die Snapshot-Konsolidierung ist, wird ESX die VM zum Schutz der Daten einfrieren. Wenn Zeitschnappschüsse fragmentiert werden und ESX die interne Konsolidierung durchführt, kann es zu regelmäßigen Einfrierungen kommen.

Sie können das VM-Template manuell über ssh erstellen. Kopieren Sie den VM-Ordner mit vmdk, vmx usw. in einen neuen Ordner. In der VMX-Datei der neu kopierten VM ändern Sie UID und MAC-Adresse.

VMware hat das Produkt Linked Clone, das Sie auch versuchen. Und sie sagen, dass es potenzielle Leistungsprobleme hat. In der Praxis werden Sie nach einer Weile VMs remastern. https://www.vmware.com/support/ws5/doc/ws_clone_typeofclone.html

— Dario
quelle