Schreckliche Situation - Dateisysteme, die gleichzeitig von mehreren unabhängigen Betriebssysteminstanzen bereitgestellt werden

Wie komme ich sicher aus dieser Situation heraus?

Details sind wie folgt:

Einem Xen-Server sind Blockgeräte für VMs zugewiesen. Diese Geräte wurden jedoch auch in Xen eingebunden.

Tatsächlich wurden 44 dieser Blockgeräte so montiert. Um die Sache noch schlimmer zu machen, wird jedes physische Gerät über 4 Pfade gesehen, und jeder dieser Pfade wird auf einem separaten Mountpunkt gemountet. Mit anderen Worten, die Geräte werden tatsächlich jeweils fünfmal montiert.

Das VM-Gastbetriebssystem sieht den Pfad über ein PowerPath-Pseudogerät (der domU als phy: Block-Gerät zugewiesen).

Einige der Geräte sind als ext2 und reiserfs formatiert.

Es ist nicht nötig, mir die Korruptionsrisiken des Dateisystems zu erklären.

Ich befürchte, dass bereits das Abmelden der Dateisysteme zu Beschädigungen führen kann, und halte es derzeit für die sicherste Option, die Stromversorgung des Hosts zu unterbrechen .

Beachten Sie, dass die Anwendungen, hauptsächlich Oracle-Datenbanken, auf allen VMs noch ausgeführt und verwendet werden.

Ich habe dies entdeckt, als ich die hohe CPU-Auslastung auf dem dom0 untersuchte. Es gibt einen unkillable "find" -Prozess mit cwd -> / media / disk-12, der von / dev / sdf1 eingehängt wird, das zu / dev / emcpowerr gehört

Bevor jemand fragt, kann ein Prozess, den ich einmal gesehen habe, nicht beendet werden und verwendet weiterhin CPU und RAM (im Gegensatz zu einem defekten / Zombie-Prozess), wenn ausstehende festgeschriebene E / A-Vorgänge vorliegen, z . Dies tritt häufiger bei Band-E / A auf.

Vorschläge!?

PS Ich hätte erwartet, dass Geräte nach dem Mounten "reserviert" werden, um so etwas zu verhindern. Oder ist das unter Linux nicht möglich?

EDIT: Erstens bin ich überzeugt, dass KDE innerhalb des Hypervisors der Schuldige ist. Es sieht so aus, als ob KDE die Geräte bereitstellt, die es bei der Protokollierung verwenden kann, um Desktopsymbole zu erstellen. Dasselbe passiert jedoch nicht auf anderen Xen-Servern, aber auf allen anderen Servern wird eine viel ältere Version von SLES und KDE ausgeführt.

Außerdem sind zwei nicht kritische VMs hängen geblieben. Nach dem Herunterfahren würden sie aufgrund einer Beschädigung des Dateisystems nicht mehr hochfahren. Die Haupt- / Produktions-VM läuft noch und die Datenbank darauf funktioniert noch, aber dies ist eindeutig eine Zeitbombe. Der Kunde versucht, die Umgebung auf einer anderen VM auf einem anderen Server neu zu erstellen, steckt aber bei Problemen mit der Konfiguration einiger Komponenten fest. Wir warten also ...

Auf jeden Fall habe ich das Gefühl, dass keine der Antworten mehr war als "Best Practice wird immer ordnungsgemäß beendet". Und ich hoffe auf etwas Konkreteres ... Ich bin auf jeden Fall der Meinung, dass diese Situation etwas sorgfältiger sein könnte Denken. Werden beim Herunterfahren ausstehende E / A-Vorgänge, insbesondere Dateisystem-Metadatenaktualisierungen vom Hypervisor, synchronisiert und möglicherweise größere Dateisystemschäden verursacht?

Wenn die Datenträger von einem einzelnen Bereitstellungspunkt aus beschrieben werden, wird kein Schaden angerichtet. Führen Sie ein sauberes Herunterfahren durch (sichern Sie es aus dem angehaltenen Zustand, wenn Sie möchten), um die Halterungen zu reparieren. Führen Sie auf dem Dom0 nur die benötigten Apps aus. Wenn, OTOH, Partitionen aus mehreren Pfaden geschrieben werden, ist das SCHLECHT und wird von Sekunde zu Sekunde schlechter. Den Stecker ziehen.

Ich habe keinen konkreten Grund, aber mein Bauchgefühl sagt mir, dass das Folgende der beste Ansatz sein kann:

1. Beenden Sie Anwendungen.
2. Kopieren Sie alle Daten von der VM über das Netzwerk an einen Sicherungsspeicherort.
3. Hängen Sie die Dateisysteme von der VM aus aus.
4. Fahren Sie die VM herunter. (Derzeit ist nur eine VM auf diesem Host aktiv.)
5. Stellen Sie sicher, dass keine DomUs so eingestellt sind, dass sie automatisch gestartet werden.
6. Trennen Sie den Host von der Stromversorgung, um zu verhindern, dass der Hypervisor Aktionen zum Schließen, zum Synchronisieren ausstehender E / A-Vorgänge usw. ausführt.
7. Starten Sie die VM in der Hoffnung, dass der Hypervisor selbst den Stromausfall überlebt hat.
8. Wenn dies fehlschlägt, erstellen Sie die Umgebung neu. (Die VMs-Startdisketten sind dateibasiert, die Datenbereitstellungspunkte befinden sich jedoch auf einer externen Festplatte, die als Blockgeräte zugewiesen ist.)
9. Überprüfen Sie, ob der Hypervisor Dateisysteme bereitstellt, die zu den domUs gehören. Deinstallieren Sie diese, bevor Sie domUs starten.)
10. Deaktivieren Sie die automatische KDE-Einbindung.
11. Starten Sie die VM und erzwingen Sie eine vollständige FS-Überprüfung.

Alternative zu 11: Starten Sie die VM und hängen Sie die Dateisysteme ohne einen vollständigen FSCK ein.

Der Grund dafür ist, dass ich nicht möchte, dass der Xen-Hypervisor mehr Chancen hat, als unbedingt erforderlich, um Beschädigungen auf den domU-Dateisystemen zu verursachen.

Ich bin kein Xen-Experte und hatte noch keine Erfahrung damit. Aber wenn ich an Ihrer Stelle wäre, würde ich folgendermaßen vorgehen: Zuerst weiß ich, dass ich möglicherweise Daten (vielleicht sogar alle) verliere. Zweitens würde ich versuchen, Snapshots zu erstellen und dann die VMs anzuhalten, um sie in einer sicheren anderen Umgebung wiederherzustellen.
Ich möchte Ihnen keine falschen Hoffnungen machen, aber ich denke, Sie werden Glück haben, wenn Sie etwas wiederherstellen können.

Warnung : Das Befolgen dieser Anweisungen kann zum Verlust aller Daten führen. Es liegt an Ihnen, zu prüfen, ob sich das Risiko lohnt oder nicht.

Mit viel Glück funktionieren Ihre Anwendungen immer noch, da sich die von ihnen verwendeten Daten im flüchtigen Speicher befinden. Sie sollten versuchen, diese Situation auszunutzen (versuchen Sie zu bewerten, ob dies auf der Basis von Apps der Fall sein könnte) und die Live-Daten auf eine Netzwerkfreigabe exportieren, wenn die Anwendungen eine solche Funktion bieten. Wenn sich Daten auf der Festplatte befinden, kann diese Exportfunktion ähnlich wie Ihre findAnweisung gesperrt sein oder zum Absturz führen (und die Anwendung oder das Betriebssystem zum Absturz bringen), da die Daten auf der Festplatte geändert oder beschädigt wurden.

Anschließend können Sie versuchen, einen Live-Snapshot zu erstellen. Die Anweisungen hierzu finden Sie im folgenden Artikel: Erstellen von Snapshots in Xen . Ich würde mich für den byteweisen Schnappschuss entscheiden, obwohl er ähnlich wie Ihr findBefehl hängen bleiben könnte ... Allerdings würde ich nicht so viel Hoffnung geben.

Bevor Sie den vorherigen Befehl ausführen, sollten Sie dieses Dokument in Citrix lesen, um die Snapshots in Xen (PDF) besser verstehen zu können .

Ich wünsche Dir viel Glück.