Snapshot zerstört VM

[iwen]

Wir haben einen NetAPP SSD Cluster an Proxmox per NFS angeschlossen. Imageformat ist qcow2.
Vor grösseren Änderungen machen wir von den Systemen Snapshots. Wir machen das immer OFFLINE, um keine Transaktionsfehler zu bekommen.

Das klappte bisher immer problemlos. Bei einer grossen Instanz mit einer Platte > 1TB ist es jetzt zum Gau gekommen. Die Festplatten sind defekt, qemu check meldet seitenweise Fehler. Das System startet nicht mehr.

Was ist denn schiefgelaufen? Ohne zuverlässige Snapshots ist das doch eine Katastrophe.
Was habe ich falsch gemacht?

 

[Falk R.]

Ich könnte sagen du nutzt eine NetApp.
Scherz beiseite, ohne weitere Infos wird es schwer zu helfen. Es kann an ganz viele sachen liegen, meistens ist bei NFS aber das Filesystem dahinter oder die Disks dadrunter das Problem.

 

[iwen]

Ich könnte sagen du nutzt eine NetApp.
Scherz beiseite, ohne weitere Infos wird es schwer zu helfen. Es kann an ganz viele sachen liegen, meistens ist bei NFS aber das Filesystem dahinter oder die Disks dadrunter das Problem.

Ich weiß, Glaskugel.

Ich hatte die Hoffnung, dass jemand einen eklatanten Fehler anprangert - z.B. "NFS und qcow2 ist eine Zeitbombe". Wenn man Google fragt, findet man eine gruselige Geschichte nach der anderen. Aber keinen generellen Hinweis, dass man NFS nicht empfiehlt. Oder das qcow ein fragiles Format sei. Auf VMWARE Basis (ebenfalls mit NFS angebunden) hatten wir mit den VMDK Snapshots auf einer anderen Netapp niemals Probleme.

Das einzige, was ich nachvollziehen konnte, war ein Hinweis, dass kleinste Netzwerkstörungen den Snapshot behindern können. Es wundert mich jedoch, dass im Logfile oder Statusfenster kein Hinweis zu finden ist. "Snapshot OK" heisst "Snapshot OK" für mich. Nicht zu wissen, was die Ursache war, finde ich äußerst unbefriedigend!

Ein zertifizierter Kollege, der unter OpenStack/KVM ebenfalls einige NetApps im Einsatz hat, erklärte mir, sie nutzen die kvm /qemu Snapshots gar nicht. Snapshots und Backups werden ausschliesslich auf und über die NetApp durchgeführt.

Wir übernehmen das jetzt und konvertieren alle qcow2 in mehreren Nachtsitzungen und das etwas unempfindlichere RAW Format und verzichten auf lokale Snapshots.

 

[hec]

Ansich sollte es ja so sein dass Proxmox einen Snapshot auf der NetApp triggert. Nur leider will Proxmox nichts von NetApp und seinen Features wissen. Die Diskussion hat ja schon mal gegeben. Ich verwende auch nur Snapshots auf der NetApp und habe noch nie Probleme gehabt.

Was meinst du mit OFFLINE? Redest du von Datenbanken?

Wenn ja bitte direkt in die VMs mit NFS/iSCSI die Volumes Mounten. Backup mit SnapCenter. Beim OS reicht ein crash consistent Backup.
Schlimmstenfalls machst du einfach einen Flexclone mountest den und bist gleich wieder online.

 

[Falk R.]

Das ist aus Netapp Sicht die einfachste Lösung und funktioniert mit jedem Hypervisor gleich.
Das einzige Problem, was ich dabei habe ist. Du hast Snapshots aber kein Backup. Für ein Backup müsstest du die Snapshots noch per NDMP oder anderweitig auf ein weiteres Ziel sichern.

 

[hec]

Das ist aus Netapp Sicht die einfachste Lösung und funktioniert mit jedem Hypervisor gleich.
Das einzige Problem, was ich dabei habe ist. Du hast Snapshots aber kein Backup. Für ein Backup müsstest du die Snapshots noch per NDMP oder anderweitig auf ein weiteres Ziel sichern.

Immer diese Diskussion bezüglich Snapshots sind keine Backups.
Ein Backup ist etwas wovon ich restoren kann. NDMP brauche ich nur für Tape. Ich würde auf eine Nearstore mit SnapMirror oder SnapVault sichern. Eventuell gekoppelt mit SnapLock falls die Backups nicht gelöscht werden sollen für eine gewisse zeit.

Bis auf das Disk Backend ist alles redundant ausgeführt bei NetApp. Wenn auch das gewollt ist kann man einen MetroCluster nehmen. Dann werden alle Writes auf beide Plexes gleichzeitig geschrieben. Damit kann man dann auch Proxmox Cluster auf 2 Datacenter aufspannen.

Restore von einem Tape widerspricht meist den Anforderungen. Es würde einfach zu lange dauern.

 

[Falk R.]

Hi,
mit NDMP kannst du heutzutage auch auf Disksysteme sichern, Tape ist eher was fürs Archiv.
Die Frage ist, was nützt dir dein Snapshot wenn die NetApp offline geht? Ein SnapMirror / SnapVault auf ein anderes Storage kann man als Backup bezeichnen. Man legt ja die Backups mit PBS auch nicht auf das Primärstorage.
Ein Metrocluster hilft dir auch nicht beim Thema Backup, wenn da ein Softwarefehler auftaucht, hast du auch nix mehr.

Ich habe schon Full Restores bei Kunden machen müssen, die ein gespiegeltes Storage über 2 RZ haben. Wenn das aus welchem Grund auch immer ausfällt, brauchst du einen getrennten Backupspeicher. Alles andere ist fahrlässig.

 

[hec]

Hi,
mit NDMP kannst du heutzutage auch auf Disksysteme sichern, Tape ist eher was fürs Archiv.
Die Frage ist, was nützt dir dein Snapshot wenn die NetApp offline geht? Ein SnapMirror / SnapVault auf ein anderes Storage kann man als Backup bezeichnen. Man legt ja die Backups mit PBS auch nicht auf das Primärstorage.
Ein Metrocluster hilft dir auch nicht beim Thema Backup, wenn da ein Softwarefehler auftaucht, hast du auch nix mehr.

Ich habe schon Full Restores bei Kunden machen müssen, die ein gespiegeltes Storage über 2 RZ haben. Wenn das aus welchem Grund auch immer ausfällt, brauchst du einen getrennten Backupspeicher. Alles andere ist fahrlässig.

Wieso soll die NetApp offline gehen? Dann übernimmt der andere Head. Deswegen sind solche Systeme auf redundant ausgeführt.
Die Umschaltung bemerkt man nicht mal wenn man alles richtig konfiguriert hat.

Wie man einen Metrocluster komplett offline bringt möchte ich sehen ohne dass man das absichtlich macht.

 

[tom]

Nur leider will Proxmox nichts von NetApp und seinen Features wissen.

Nein, so stimmt das natürlich nicht. Wir (Proxmox) habe eine ganze Reihe von Storage plugins entwickelt. Die Voraussetzung ist, das die Storage Technologie open source ist und somit problemlos mit Proxmox VE zusammenspielt. Da NetApp kommerziell ist, können wir das nicht.

Aber jeder Hersteller eines Storagesystems kann natürlich ein StoragePlugin für Proxmox VE schreiben, genau dafür haben wir auch eine definierte Schnittstelle.

Ein Beispiel dazu ist das linstor-proxmox plugin.

 

[hec]

Nein, so stimmt das natürlich nicht. Wir (Proxmox) habe eine ganze Reihe von Storage plugins entwickelt. Die Voraussetzung ist, das die Storage Technologie open source ist und somit problemlos mit Proxmox VE zusammenspielt. Da NetApp kommerziell ist, können wir das nicht.

Aber jeder Hersteller eines Storagesystems kann natürlich ein StoragePlugin für Proxmox VE schreiben, genau dafür haben wir auch eine definierte Schnittstelle.

Ein Beispiel dazu ist das linstor-proxmox plugin.

Wieso muss die Storage Technologie komplett OS sein? Ich bin auch ein Freund von OS aber ich denke die API sollte doch dazu ausreichend sein um ein Plugin zu entwickeln.

 

[tom]

Wieso muss die Storage Technologie komplett OS sein? Ich bin auch ein Freund von OS aber ich denke die API sollte doch dazu ausreichend sein um ein Plugin zu entwickeln.

Der oben beschriebene Weg über die Schnittstelle ist da, das kann NetApp oder jeder andere kommerzielle Storageanbieter jederzeit anbieten.

Wir können nur open source über unsere ISO / repos ausliefern.

 

[Falk R.]

Wieso soll die NetApp offline gehen? Dann übernimmt der andere Head. Deswegen sind solche Systeme auf redundant ausgeführt.
Die Umschaltung bemerkt man nicht mal wenn man alles richtig konfiguriert hat.

Wie man einen Metrocluster komplett offline bringt möchte ich sehen ohne dass man das absichtlich macht.

Habe ich in 20 Jahren alles schon gesehen, angefangen von multiplen Disk Fehlern. Damals hatte eine ganze Reihe 146GB SAS Platten ein Problem das die nach fast 3 Jahren fast Zeitgleich ausgefallen sind. Wenn dann mal 3 Disks gleichzeitig im Raid ausfallen ist das schon blöd.
Wenn dann beim resync vom zweiten Storage dann wegen der höheren Last auch mehrere Disks ausfallen, hat man hoffentlich ein gutes Backup.

Auch Softwarefehler bei Storageherstellern habe ich genug gesehen, will aber lieber keine namen nennen. Sind aber alles Global Player gewesen.
Solche Ausfälle sind zum Glück seltener geworden, dafür gibts derzeit Hacker die mal eben ein gespiegeltes Storage auf Werksreset setzen.

Nur mal so als Beispiel aus meiner Persönlichen Erfahrung. Das ist der Grund warum ich beim Thema Backup sehr genau bin, selbst meine privaten Fotos liegen verschlüsselt in einem Immutbility S3 Bucket bei einem Cloud Provider.

 

[hec]

Die 146er Disken waren doch FC und nicht SAS. Da waren die Fehlerquoten wesentlich höher als bei den heutigen SAS Platten.
Die Frage ist auch ob gleich mal 3 Disks in einer RG ausfallen oder ob sie die über mehrere RGs verteilen.
Ansich sollte das aber das Disk Maint abfedern und die prefailen.

Meine Erfahrung ist bei den heutigen MCs gibt es die Probleme nicht mehr die wir mit den DS14 Mk2/Mk2 Shelfs gehabt haben.

Die DS224C laufen echt problemfrei da haben wir fast keine RMAs. Zu den NS Shelfs kann ich noch nichts sagen da müssen wir schauen wie sich das die nächsten Jahre entwickelt.

 

[Falk R.]

Mit den SAS Disks war keine Netapp, sondern ein noch öfter Verlass Storage.
Netapp sah über die Jahre auch nicht immer Top aus.
Es ist schön, dass die Systeme zur Zeit gut laufen, aber was ist wenn doch mal wieder ein Bug kommt? Ich gehe lieber auf Nummer sicher mit einem guten Backup.

 

[hec]

Ich streite ja nicht ab dass eine Nearstore sinnvoll ist. Aber zu 99% wird vom Snapshot direkt der Restore durchgeführt.

Klar Bugs kanns immer geben - datenvernichtende Bugs hätte ich aber noch nicht gesehen. Gerade bei einem MC habe ich ja die Daten auf beiden Seiten. Wenn müsste man die Nearstore dann sowieso auf einen 3. Standort stellen. Verkaufbar ist das in den wenigsten Fällen.