Was bedeutet das? Auf dem Server selbst oder bei Netcup?
vda: Der minimal notwendige Speicherplatz zur Erstellung eines Snapshots wurde unterschritten, daher kann kein weiterer Snapshot angelegt werden.
Speicherplatz Snapshots
- TechnikOnkel
- Thread is marked as Resolved.
-
Du hast einen gewissen Speicher beim Server (auf dem Host bie NetCup) verfügbar, den du für Daten und Snapshots verwenden kannst. Die Meldung deutet darauf hin, dass dein Gastsystem zusammen mit den bereits gemachten Snapshots (falls es welche gibt) so viel Platz auf dem Host belegen, dass keine weiteren Snapshots mehr gemacht werden können.
-
Du hast einen gewissen Speicher beim Server (auf dem Host bie NetCup) verfügbar, den du für Daten und Snapshots verwenden kannst. Die Meldung deutet darauf hin, dass dein Gastsystem zusammen mit den bereits gemachten Snapshots (falls es welche gibt) so viel Platz auf dem Host belegen, dass keine weiteren Snapshots mehr gemacht werden können.
Genau das soll laut dem Provider Netcup bzw. [netcup] Lars S. mittlerweile für uns Kunden aufgehoben worden sein.
Zum Beispiel: Wenn ich einen Server habe, dessen virtuelle Platte nun 8TB groß ist und ich die auch bis zu 99% fülle, so soll zukünftig unter der Berücksichtigung, dass auch auf dem Host noch so viel Platz vorhanden ist, dennoch ohne Probleme ein Snapshot angelegt werden können.
Mehr siehe auch hier.
-
Snapshots sind COW (Copy On Write), belegen also erstmal keinen Platz. Jeder Schreibzugriff in der VM belegt dann aber zusätzlichen Platz, auch wenn er nur bereits im Snapshot belegten Platz überschreibt. Die Frage ist immer, was dann passiert, wenn die Snapshots und die aktuelle Version des Images zusammen mehr Platz belegen, als in dem Tarif zur Verfügung steht. Wenn dir auf deinem Computer die Platte volläuft, und der Hypervisor keinen Platz mehr für die Schreibzugriffe findet, pausiert er die VM. Vielleicht macht Netcup das auch so, aber vielleicht ist das Accounting für Snapshots auch anders. Ich würde auf einem Production-System keine dauerhaften Snapshots anlegen, wenn die Möglichkeit besteht, dass der belegte Speicher plus Snapshots den Tarifspeicherplatz überschreitet, erst recht nicht, wenn der Speicherplatz schon fast voll ist, auch wenn das mittlerweile "geht".
-
Genau das soll laut dem Provider Netcup bzw. [netcup] Lars S. mittlerweile für uns Kunden aufgehoben worden sein.
Zum Beispiel: Wenn ich einen Server habe, dessen virtuelle Platte nun 8TB groß ist und ich die auch bis zu 99% fülle, so soll zukünftig unter der Berücksichtigung, dass auch auf dem Host noch so viel Platz vorhanden ist, dennoch ohne Probleme ein Snapshot angelegt werden können.
Mehr siehe auch hier.
Soweit ich das verstanden habe gilt das aber nicht, wenn sich Daten nach dem/den Snapshot(s) verändert haben, genau wie NaN geschrieben hat.
Sonst könnte man ja ein Vielfaches des gebuchten Speicherplatzes auf dem Host belegen, wenn sich nach dem Anlegen eines Snapshots immer wieder Daten verändern.
-
Wenn dir auf deinem Computer die Platte volläuft, und der Hypervisor keinen Platz mehr für die Schreibzugriffe findet, pausiert er die VM. Vielleicht macht Netcup das auch so, aber vielleicht ist das Accounting für Snapshots auch anders. Ich würde auf einem Production-System keine dauerhaften Snapshots anlegen, wenn die Möglichkeit besteht, dass der belegte Speicher plus Snapshots den Tarifspeicherplatz überschreitet, erst recht nicht, wenn der Speicherplatz schon fast voll ist, auch wenn das mittlerweile "geht".
Das Problem hatten wir aber auch schon vor der Neuregelung.
Ich als Kunde gehe eher mal davon aus, dass wenn uns der Speicherplatz von ca. 199% (Speicherplatz für die virtuelle Platte = 100% und Speicherplatz für Snapshots = 99%) mal eingeräumt wurde, so interpretiere ich diese Mitteilung, wir Diesen auch ohne weitere ungewollte Störungen nutzen können.
Weitere Probleme, wie z.B. nicht mehr genügend Speicherplatz auf dem Host, auf dem der Hypervisor für unsere VM´s läuft, kann uns auch dann treffen, wenn wir kein Snapshot angelegt haben.
Von daher ist es aus meiner Sicht eher ratsamer, zu mindestens für den Extremfall - und der damit verbundenen Vorzüge eines Snapshots, ein System sehr schnell wieder auf dem Urzustand bringen zu können - zu mindestens ein halbwegs aktuellen Snapshot auch und gerade für Produktivsysteme angelegt zu haben.
Soweit ich das verstanden habe gilt das aber nicht, wenn sich Daten nach dem/den Snapshot(s) verändert haben, genau wie NaN geschrieben hat.
Sonst könnte man ja ein Vielfaches des gebuchten Speicherplatzes auf dem Host belegen, wenn sich nach dem Anlegen eines Snapshots immer wieder Daten verändern.
Snapshots wachsen nicht an und bleiben von daher von deren Größe und Inhalt unverändert, wenn in der virtuellen Platte weitere Daten hinzufügt oder geändert werden.
-
Streng genommen wurde gar nichts eingeräumt sondern lediglich eine künstliche Beschränkung, wann Snapshots angelegt werden können, verändert/aufgehoben. Der Speicherbedarf steigt durch den Snapshot ja zunächst nicht an, sondern erst, wenn in der VM geschrieben wird. Was passiert, wenn Snapshots und aktuelle Version zusammen zu viel Speicher belegen, ist noch offen. Das konnte bisher auch passieren, war aber natürlich unwahrscheinlicher, als wenn man einen Snapshot bei fast voll belegter Platte anlegt.
Gegen Snapshots spricht außerdem, dass sie eine auomatische Hostmigration verhindern. M.M.n. sind Snapshots vor allem geeignet, um halbwegs konsistente Full-Disk-Backups zu ziehen, ohne die VM herunterfahren zu müssen, oder um die Downtime zu verringern, wenn man ein solches Backup des ausgeschalteten Zustands ziehen möchte. Man kann auch vor riskanten Änderungen einen Snapshot machen und dann entweder Zurückrollen oder bei Erfolg den Snapshot löschen. In allen Fällen braucht man den Snapshot aber nur kurzzeitig, so dass die Überschreitung durch Aktivität in der VM unwahrscheinlich ist und der Snapshot auch keine Verschiebung auf einen anderen Host verhindert.
-
Snapshots wachsen nicht an und bleiben von daher von deren Größe und Inhalt unverändert, wenn in der virtuellen Platte weitere Daten hinzufügt oder geändert werden.
Das habe ich auch nicht behauptet :-).
-
Das habe ich auch nicht behauptet :-).
Das sollte auch so nicht rüberkommen, sondern ich habe deinen Beitrag nur interpretiert und entsprechend für die Allgemeinheit darauf ganz normal geantwortet.
-
TechnikOnkel Wie viel GB sind denn laut SCP belegt? Eventuell einmal die Speicheroptimierung im SCP unter Medien anklicken.
-
Sollte man das regelmäßig machen?
Nein, wenn man nicht regelmäßig alle Snapshots löscht.
Zielführender ist wahrscheinlich eine regelmäßige Ausführung von fstrim -va (oder bei ZFS zpool trim …), was bei einigen Distributionen bereits standardmäßig durch Systemd gemacht wird.
-
Zielführender ist wahrscheinlich eine regelmäßige Ausführung von fstrim -va (oder bei ZFS zpool trim …), was bei einigen Distributionen bereits standardmäßig durch Systemd gemacht wird.
Müßte es nicht schon reichen, wenn der Hypervisor diese Befehle auf dessen nativen SSD ausführt? Denn unsere Platten sind ja strenggenommen eigentlich nur Dateien, in denen wir überwiegend unverschlüsselt Daten ablegen oder auch wieder löschen.
-
Die Dateien werden wie Blockdevices genutzt, der Hypervisor müsste also erst wissen, welche Teile der Dateien freigegeben werden können. Das erfährt er über das fstrim und geht mehr dieser Info dann zu seinen SSDs. So hoch wie der Stack mit allen beteiligten Komponenten ist, bin ich an dieser Stelle immer wieder begeistert, dass es am Ende tatsächlich funktioniert.
-
Müßte es nicht schon reichen, wenn der Hypervisor diese Befehle auf dessen nativen SSD ausführt? Denn unsere Platten sind ja strenggenommen eigentlich nur Dateien, in denen wir überwiegend unverschlüsselt Daten ablegen oder auch wieder löschen.
Der TRIM-Befehl innerhalb der VM sagt dem Host ja nur, welche Bereiche aktuell garantiert ungenutzt sind und wie NUL behandelt werden dürfen. Je nach Speicherformat auf dem Hostsystem, wird das dann weitergereicht und dort freigegeben. Mit einem echten TRIM der SSDs auf dem Hostsystem hat das erst einmal gar nichts zu tun. Das kann unabhängig davon sowieso jederzeit passieren und beeinflusst unsere VMs nicht.
Falls damit gemeint war, dass es von außerhalb im virtuellen Speichermedium stattfinden soll: Wie soll der Hypervisor das machen, wenn er nicht die exklusive Kontrolle über das verwendete Dateisystem hat? Da wäre (bei einer laufenden VM) der Datenverlust bzw. ein defektes Dateisystem vorprogrammiert. Wenn die VM hingegen nicht läuft, passiert das beim Klick auf die Speicheroptimierung vielleicht eh. So genau habe ich das noch nie getestet.
Ich kann diesbezüglich zum Testen nur Sparse-Dateien empfehlen. Die verhalten sich ziemlich identisch und sind ein toller Ort für eigene Experimente, wenn man (über ein Loop-Device) darin ein weiteres Dateisystem aufzieht.
-
Versehentlich zitiert statt editiert. Sorry!
