恐ろしい状況-複数の独立したOSインスタンスによって同時にマウントされたファイルシステム

Question

この状況から安全に抜け出すにはどうすればよいですか？

詳細は以下の通りです。

Xenサーバーには、VMに割り当てられたブロックデバイスがあります。しかし、これらのデバイスはXen内にもマウントされています。

実際、これらのブロックデバイスのうち44個がこのように取り付けられています。さらに悪いことに、各物理デバイスは4つのパス上にあり、それぞれが別々のマウントポイントにマウントされています。言い換えれば、デバイスは実際にはそれぞれ5回マウントされます。

VMゲストOSは、PowerPath疑似デバイス（phy：ブロックデバイスとしてdomUに割り当てられている）を介してパスを認識します

一部のデバイスは、ext2およびreiserfsとしてフォーマットされています。

ここに含まれるファイルシステムの破損リスクについて説明する必要はありません。

ファイルシステムをアンマウントするだけでも破損する可能性があるのではないかと心配しており、この時点でホストから電源を切るのが最も安全なオプションですと感じています。

すべてのVMのアプリケーション（ほとんどの場合、Oracleデータベース）はまだ実行中であり、使用されていることに注意してください。

Dom0で高いCPU使用率を調査したときに、これを発見しました。/dev/emcpowerrに属する/ dev/sdf1からマウントされるcwd->/media/disk-12を使用した、強制終了できない「検索」プロセスがあります。

誰かが尋ねる前に、プロセスを強制終了してCPUを使い続けることができないのを一度見たときは、RAM（廃止された/ゾンビプロセスとは異なり）、未処理のコミットされたI/Oがあるときです。たとえば、同期は返されましたが、物理的にはまだディスク上にありません。より一般的には、これはテープI/Oで発生します。

提案！？

P.S.このようなことを防ぐために、一度マウントするとデバイスが「予約」されると思っていたでしょうか。それともLinuxでは不可能ですか？

編集：最初に、ハイパーバイザー内のKDEが原因であると確信しています。 KDEは、デスクトップアイコンを作成するためにログに記録できるデバイスをマウントしているようです。ただし、他のXenサーバーでも同じことは発生していませんが、他のすべてのサーバーははるかに古いバージョンのSLESとKDEを実行しています... V4は問題のあるサーバーのようで、3.4の方が動作が優れています）。

さらに、2つの重要ではないVMがハングしました。それらをシャットダウンした後、ファイルシステムの破損のために再度起動することはありませんでした。メイン/本番VMはまだ実行中であり、その上のデータベースはまだ機能していますが、明らかにこれは時限爆弾です。お客様は別のVMですが、一部のコンポーネントの構成の問題でスタックしているため、待機しています...

いずれにせよ、これまでのところ「ベストプラクティスは常に優雅にシャットダウンされる」以上の答えはないと感じています。もっと具体的なことをしたいと思っています...いずれにせよ、この状況にはもっと注意が必要だと思います。考え。シャットダウンすると、未処理のIO、特にハイパーバイザーからのファイルシステムメタデータの更新が同期され、重大なファイルシステムの破損が発生する可能性がありますか？

Alien Life Form · Answer

ディスクが単一のマウントポイントから書き込まれている場合、害はありません。クリーンシャットダウンを実行し（必要に応じて一時停止状態からバックアップします）、マウントを修正します。 Dom0で必要なアプリ以外は実行しないでください。 OTOHの場合、パーティションが複数のパスから書き込まれている場合、それは悪いことであり、秒単位で悪化します。プラグを抜く。

Huygens · Answer

私はXenの専門家ではなく、まだ経験がありません。しかし、私があなたの代わりにいた場合の私のアプローチは次のようになります。まず、データを失う可能性があることを知っています（おそらくすべて）。次に、スナップショットを作成してからVMを一時停止し、安全な別の環境に復元しようとします。
私はあなたに誤った希望を与えたくありませんが、何かを取り戻すことができればあなたは幸運だと思います。

警告：これらのアドバイスに従うと、すべてのデータが失われる可能性があります。これは、リスクに見合う価値があるかどうかを確認するのはあなた次第です。

運が良ければ、使用しているデータはすべて揮発性メモリにあるため、アプリケーションは引き続き機能します。この状況を利用して（アプリごとにそれが当てはまるかどうかを評価してみてください）、アプリケーションがそのような機能を提供している場合は、ライブデータをネットワーク共有にエクスポートする必要があります。ディスク上にデータがある場合、このエクスポート関数はfindステートメントのように「ロック」されるか、ディスクデータが変更または破損したためにクラッシュ（およびアプリケーションまたはOSをクラッシュ）する可能性があります。

次に、ライブスナップショットを実行してみることができます。次の記事の手順： Xenでスナップショットを作成する。 findコマンドのようにスタックする可能性はありますが、バイトごとのスナップショットを作成します...ただし、これほどの希望はありません。

前のコマンドを実行する前に、Citrixからこのドキュメントを読む必要があります。これは Xen（PDF）のスナップショットを理解するに役立ちます。

がんばって。