ハリケーンマシューにより、当社はすべてのサーバーを2日間シャットダウンしました。サーバーの1つは、HP StorageWorks MSA60が接続されたESXiホストでした。
今日電源を入れ直してvSphereクライアントにログインすると、使用可能なゲストVMがないことに気付きました(すべて「アクセス不能」としてリストされています)。また、vSphereのハードウェアステータスを見ると、アレイコントローラーと接続されているすべてのドライブは「通常」と表示されますが、ドライブはすべて「未構成のディスク」と表示されます。
サーバーを再起動し、RAID構成ユーティリティにアクセスして、そこからどのように表示されるかを確認しようとしましたが、次のメッセージが表示されました。
POST中に無効なドライブの動きが報告されました。無効なドライブの移動に続いてアレイ構成を変更すると、古い構成情報と元の論理ドライブの内容が失われます。
言うまでもなく、何も「動かされなかった」ので、私たちはこれに非常に混乱しています。何も変わっていません。 MSAとサーバーの電源を入れるだけで、それ以来この問題が発生しています。
MSAは1本のSAS=ケーブルで接続されており、ドライブにはステッカーが貼られているので、ドライブが移動したり切り替えられたりしていません
---------------------
| 01 | 04 | 07 | 10 |
---------------------
| 02 | 05 | 08 | 11 |
---------------------
| 03 | 06 | 09 | 12 |
---------------------
現時点では、ドライブの種類とモデルはわかりませんが、すべて1TBですSASドライブ。
私は2つの主な質問/懸念があります:
デバイスの電源をオフにしてから再度オンにする以外に何もしなかったので、これを引き起こす原因は何でしょうか?もちろん、アレイを再構築して最初からやり直すこともできますが、これが再び発生する可能性については心配です(特に、原因がわからないため)。
すべてを再構築してVMバックアップを復元する必要がなく、アレイとゲストのVMを復旧できる可能性があります。
そう、これは非常に不安定な状況です...
そのため、HP Smart Arrayコントローラーは、アレイ構成を壊す前に、特定の数の物理ドライブの動きを処理できます。 HP RAIDメタデータは、コントローラーではなく物理ドライブに存在することに注意してください...
MSA60は、12ベイの3.5インチ第1世代SAS JBODエンクロージャです。2008/ 2009年にサポートが終了しました。十分に古いため、クリティカルパスに含めるべきではありません。今日のanyvSphere展開の。
この場合、P411コントローラーはユーザーを保護しようとしています。複数のドライブの障害状態が発生したか、ファームウェアのバグが発生したか、MSA60の背面にある2つのコントローラーインターフェイスの1つが失われたか、その他の奇妙なエラーが発生した可能性があります。
これは、古いサーバー設定のようにも聞こえます。そこで、関係するサーバーとSmart ArrayP411ファームウェアのリビジョンについて知りたいのですが。
すべてのコンポーネントの電源を切ることをお勧めします。数分待っています。電源を入れています... POST.
ここで私の答えの詳細を参照してください:
HP Smart Array P800の論理ドライブが再起動後に認識されない
mayは、以前に故障した論理ドライブを再度有効にするオプションと、F1
またはF2
を押すオプションがあります。提示された場合は、F2
を試してください。
あなたたちはこれを信じるつもりはありません...
最初に既存のMSAの新しいコールドブートを試み、数分待ってからESXiホストの電源を入れましたが、問題は解決しませんでした。次に、ホストとMSAをシャットダウンし、ドライブをスペアのMSAに移動し、電源を入れ、数分待ってから、ESXiホストの電源を入れました。問題はまだ残っていました。
その時点で、私はかなりねじ込まれていると思いました。RAIDコントローラの初期化中には、故障した論理ドライブを再度有効にするオプションがありませんでした。そこでRAID構成で起動し、論理ドライブが存在しないことを再度確認して、新しい論理ドライブを作成しました(2台のスペアドライブを備えたRAID 1 + 0。このホストを最初にセットアップしたときに約2年前に行ったのと同じです)。ストレージ)。
次に、サーバーをvSphereで再起動し、vCenter経由でアクセスしました。最初に行ったのは、ホストをインベントリから削除してから再度追加することでした(この方法で、アクセスできないすべてのゲストVMをクリアしたいと思っていましたが、インベントリからクリアされませんでした)。ホストがインベントリに戻ったら、各ゲストVMを一度に1つずつ削除しました。インベントリがクリアされたら、データストアが存在しないこと、およびディスクが基本的に「データディスク」として準備ができて待機していることを確認しました。そこで、先に進んで新しいデータストアを作成しました(ここでも、VMFSを使用して数年前に作成したのと同じです)。最終的にマウントオプションを指定するように求められ、「既存の署名を保持する」オプションがありました。この時点で、署名を保持する価値があると考えました。問題が解決しない場合は、いつでも署名を吹き飛ばして、データストアを再作成できます。署名の保持オプションを使用してデータストアを構築するプロセスを完了した後、データストアに移動して、データストアに何かがあるかどうかを確認しました。好奇心から、私はホストにSSHで接続し、そこからチェックしました。驚いたことに、すべての古いデータとすべての古いゲストVMを見ることができました。 vCenterに戻り、ストレージを再スキャンしてコンソールを更新しました。古いゲストVMはすべてそこにありました。各VMを再登録し、すべてを回復できました!すべてのゲストVMがバックアップされ、ネットワーク上で正常に通信しています。
ITコミュニティのほとんどの人は、このようなことが起こる可能性は非常に低いか不可能であることに同意すると思います。
私に関する限り、これは神の奇跡でした...