Wie komme ich sicher aus dieser Situation heraus?
Details sind wie folgt:
Ein Xen-Server hat Blockgeräte, die VMs zugewiesen sind. Aber diese Geräte wurden auch in Xen gemountet.
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 davon wird auf einem separaten Mountpoint gemountet. Mit anderen Worten, die Geräte werden tatsächlich jeweils 5 Mal montiert.
Das VM-Gastbetriebssystem sieht den Pfad über ein PowerPath-Pseudogerät (dem domU als phy:block-Gerät zugewiesen)
Einige der Geräte sind als ext2 und reiserfs formatiert.
Sie müssen mir die Risiken der Beschädigung des Dateisystems hier nicht erklären.
Ich befürchte, dass sogar das bloße Unmounten der Dateisysteme zu Beschädigungen führen kann, und ich bin der Meinung, dass zu diesem Zeitpunkt die sicherste Option ist, den Host vom Strom zu nehmen .
Beachten Sie, dass die Anwendungen, größtenteils Oracle-Datenbanken, in allen VMs noch ausgeführt und verwendet werden.
Ich habe dies entdeckt, als ich die hohe CPU-Auslastung auf dom0 untersucht habe. Es gibt einen nicht zu beendenden „Find“-Prozess mit cwd -> /media/disk-12, der von /dev/sdf1 gemountet wird, das zu /dev/emcpowerr gehört
Bevor jemand fragt, das einzige Mal, dass ich gesehen habe, dass Prozesse nicht beendet werden können und weiterhin CPU und RAM verwenden (im Gegensatz zu einem nicht mehr funktionierenden / Zombie-Prozess), ist, wenn es ausstehende festgeschriebene E / A gibt, z. B. die Synchronisierung zurückgegeben, aber noch nicht physisch auf der Festplatte . Dies tritt häufiger bei Band-E/A auf.
Vorschläge!?
P.S. Ich hätte erwartet, dass Geräte nach der Montage „reserviert“ werden, um so etwas zu verhindern? Oder ist das unter Linux nicht möglich?
EDIT:Erstens bin ich davon überzeugt, dass KDE im Hypervisor) der Schuldige ist. Es sieht so aus, als würde KDE die Geräte mounten, die es beim Anmelden zum Erstellen von Desktopsymbolen verwenden kann. Das Gleiche passiert jedoch nicht auf anderen Xen-Servern, sondern auf allen anderen Servern läuft eine viel ältere Version von SLES und KDE … V4 scheint die beleidigende zu sein, wobei sich 3.4 besser verhält).
Außerdem sind zwei nicht kritische VMs hängengeblieben. Nach dem Herunterfahren würden sie aufgrund einer Beschädigung des Dateisystems nicht wieder hochfahren. Die Haupt-/Produktions-VM läuft noch und die Datenbank darauf funktioniert noch, aber das ist eindeutig eine Zeitbombe. Der Kunde versucht, die Umgebung auf einer anderen VM auf einem anderen Server neu zu erstellen, bleibt aber bei Problemen bei der Konfiguration einiger der Komponenten hängen, also warten wir…
Auf jeden Fall habe ich das Gefühl, dass bisher keine der Antworten mehr war als „Best Practice wird immer ordnungsgemäß heruntergefahren“. Und ich hoffe, etwas Konkreteres zu bekommen … Auf jeden Fall denke ich, dass diese Situation ein sorgfältigeres Nachdenken erfordern könnte. Wird das Herunterfahren dazu führen, dass ausstehende E/A, insbesondere Dateisystem-Metadatenaktualisierungen vom Hypervisor, synchronisiert werden und möglicherweise größere Dateisystembeschädigungen verursachen?
Verwandt:Mehrere Spalten aus einer ausgewählten Unterabfrage abrufen?Akzeptierte Antwort:
Wenn die Platten von einem einzelnen Einhängepunkt aus beschrieben werden, wird kein Schaden angerichtet. Führen Sie ein sauberes Herunterfahren durch (sichern Sie es aus dem suspendierten Zustand, wenn Sie so wollen), reparieren Sie die Halterungen. Führen Sie auf der Dom0 nichts außer den notwendigen Apps aus. Wenn, OTOH, Partitionen von mehreren Pfaden geschrieben werden, ist das SCHLECHT und wird von Sekunde zu Sekunde schlimmer. Stecker ziehen.