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

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

詳細は次のとおりです。

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で発生します。

提案！？

PSこの種のことを防ぐために、デバイスがマウントされると「予約」されると予想していましたか？それともLinuxでは不可能ですか？

編集：まず、ハイパーバイザー内のKDEが原因だと確信しています。KDEは、ログに記録できるデバイスをマウントしてデスクトップアイコンを作成しているようです。ただし、他のXenサーバーでは同じことは起きていませんが、他のすべてのサーバーははるかに古いバージョンのSLESおよびKDEを実行しています...

さらに、2つの重要ではないVMがハングしました。それらをシャットダウンした後、ファイルシステムの破損のために再起動しませんでした。メイン/実稼働VMはまだ実行中で、その上のデータベースはまだ動作していますが、明らかにこれは時限爆弾です。お客様は、別のサーバー上の別のVMで環境を再構築しようとしていますが、一部のコンポーネントの構成に関する問題に固執しているため、お待ちしています...

いずれにせよ、これまでのところ「ベストプラクティスは常に適切にシャットダウンされる」以上の答えはなかったと感じています。考え。シャットダウンすると、未処理のIO、特にハイパーバイザーからのファイルシステムメタデータの更新が同期され、ファイルシステムが破損する可能性がありますか？

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

私には具体的な理由はありませんが、私の直感は次のことが最善のアプローチかもしれないことを教えてくれます：

1. アプリケーションをシャットダウンします。
2. ネットワークを介してVMからすべてのデータをバックアップ場所にコピーします。
3. VM内からファイルシステムをアンマウントします。
4. VMをシャットダウンします。（現在、このホストで実行されているVMは1つだけです）。
5. domUが自動的に開始するように設定されていないことを確認します。
6. ホストの電源を切り、ハイパーバイザーが「クローズ」アクション、未処理のI / Oの同期などを実行しないようにします。
7. VMを起動し、ハイパーバイザー自体がパワーヤンクに耐えることを期待します。
8. 失敗した場合は、環境を再構築します。（VMのブートディスクはファイルベースですが、データマウントポイントはブロックデバイスとして割り当てられた外部ディスクに存在します）
9. ハイパーバイザーがdomUに属するファイルシステムをマウントしているかどうかを確認します。domUを開始する前にこれらのマウントを解除してください）
10. KDEの自動マウントをオフにします。
11. VMを起動し、完全なFSチェックを強制します。

11の代替：VMを起動し、完全なfsckなしでファイルシステムをマウントします。

理由は、domUファイルシステムで破損を引き起こすために絶対に必要なXenハイパーバイザーにこれ以上のチャンスを与えたくないからです。

私はXenの専門家ではなく、まだ経験がありません。しかし、私があなたの場所にいた場合の私のアプローチは、次のとおりです。次に、スナップショットを作成してからVMを一時停止し、安全な別の環境に復元します。
私はあなたに間違った希望を与えたくありませんが、何かを回復できれば幸運になると思います。

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

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

その後、ライブスナップショットを試すことができます。次の記事の指示に従ってください：Xenでのスナップショットの作成。あなたのfindコマンドのようにスタックする可能性はありますが、バイト単位のスナップショットに行きます...しかし、私はこれほど希望を与えません。

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

がんばって。