ESXiホストで実行されているsp1VMを使用したServer2008R2でのEMCNetWorkerサーバーの実行。 VMDKは、組織が実行している他のすべてのVMサーバーのVMDKとともにVNXeマシンに保存されます。他のVMにはこの問題はありません。
今週の後半の毎晩、午後9時以降、このサーバーはハードドライブを失います。午前中にシステムをチェックすると、PXEを試した後、このマシンが起動プロンプトに表示され、起動可能なデバイスが見つからないと報告されます。 VMの設定を確認すると、マシンにハードドライブが接続されていないことがわかりました。
リカバリは、システムに新しいハードドライブを割り当て、VNXeでホストされているデータストアにまだ存在している既存のVMDKを指すだけです。
VSphereサーバーは、問題やエラーを報告しません。
サーバー自体のシステムログには情報がないので、何が起こったのか見当がつかないと確信しています。
この問題は、NetWorkerシステムを使用してバックアップを増やし始め、バックアップに新しいホストを追加したときに始まりました。現在、NetWorkerサーバーに組み込まれている構成済みのVADPプロキシと、そのマシンにローカルにインストールされているNetWorkerクライアントを使用するテストSQLサーバー(VM)を使用して仮想ホストのみをバックアップしています。ドキュメントに問題はないはずであると記載されていたため、NetWorkerサーバー自体をバックアップしていましたが、この問題が見つかった直後にそのバックアップを無効にしました。
VMDKがNetWorkerサーバーから接続解除される方法と理由を確認する必要があります。誰かが私に明示的に教えてくれるのはいいことですが、システムで起こっていることすべてを示すvSphereログを見つけるのに役立つかもしれませんが、正しい方向への良いポイントになるでしょう。
更新:追加の詳細
VMのバックアップは、毎晩午後9時に開始するようにスケジュールされています。
このVMのvSphereログから:
このログに基づいて、次のことを確認する必要があります。
これらを確認し、成功または失敗について報告します。
更新2:トラブルシューティングレポート
私が見つけたもう1つのこと:NetWorkerの各VMクライアントの構成には、VMが存在するESXiホストを記録する場所があります。 VMを別のESXiホストにvMotionすると、NetWorkerでVM自動検出が有効になっていても、この値は更新されません。そこで、VMクライアント構成のこの値を現在のESXiホストに更新しました。 AutoDetectがそれ自体を更新し続けていれば素晴らしいでしょう。
それで、昨日試したトラブルシューティングについて報告するために:
まず、HDDは今朝も接続されていました。これは、問題が少なくともNetWorkerによって引き起こされていることを確認しています。昨日、すべてのバックアップを無効にし、NetWorkerサーバーを新しいESXiホストに移動しました。前の段落で説明したESXiホスト情報も更新しました。
今日、私はほとんどのバックアップを再度有効にしました(SQLやExchangeなどの高可用性システムは除外しました。
今夜HDDが取り外された場合、問題となるのはバックアップ構成です。
今夜HDDが取り外されていない場合は、ホスト構成情報またはホスト自体が問題の原因です。
アップデート3:トラブルシューティングのフォローアップ
昨夜、HDDが再び失われました。これは、おそらくNetWorker構成に問題があることを意味します。
要約すると、昨夜、いくつかのVM(NetWorkerサーバーではない)のスケジュールされたバックアップを実行し、午後9時の直後に、質問の前半で述べたのと同じログエントリが表示されたため、に関連付けられたHDDがなくなりました。 VM。
もう1つ試してみることがあります。EMCのドキュメントに基づくと、NetWorkerサーバーはストレージノードになることもでき、ほとんどのVMはこのノードを介してバックアップを処理しています(これはVADPとは別です)。ノードのバックアップを通じてこれらを無効にし、それが違いを生むかどうかを確認します。
また、物理システムのバックアップとNAS /ネットワークドライブからのNDMPバックアップは正常に機能しています。
VMを分離し、バックアップに一度に1つずつ追加して、特定のVMが問題の原因であるかどうかを判断できるかどうかを確認します。これは私が勤務時間中にテストできるはずのものです。
更新:テストは光を放ちます
わかりました。問題は、VADPを使用してVMをバックアップしようとするたびに発生します。
さまざまな設定順列を使用して、実行中および電源オフのVMのバックアップをテストしましたが、NetWorkerサーバーがドライブを失ったかどうかを判断する唯一の要因は、ターゲットにNetWorkerクライアントをインストールしたかどうかでしたVM NetWorkerクライアントまたはVADPを使用してバックアップしていました。
クライアントウィザードを使用してバックアップを構成する場合、最初に、新しいVADPプロキシを構成するか、VMバックアップクライアントを構成するか、またはNetWorkerクライアントを構成するかを選択します。
VMバックアップクライアントを選択すると、VADPを使用してバックアップするか(これがデフォルトです)、VMにインストールされているNetWorkerクライアントを使用してバックアップするか(これはバックアップに特別な構成が必要な場合のために。VADPは実際のVMDKにヒットし、VMWareと統合します。NetWorkerはクライアントがVMであることを「認識」しますが、特定のドライブ、VSS、およびその他の機能を指定するために使用できます。VADPはVMをバックアップします。ゲストリソースを使用せず、ESXiホストに完全に依存します。NetWorkerクライアントソフトウェアは、クライアントリソースを使用してバックアップを実行します。
したがって、VMホストのVADPバックアップを実行すると、NetWorkerサーバーからHDDが削除されます。また、HDDがドロップされたときにvSphereクライアントに表示されるログエントリがさらにあります。
おそらく手遅れですが、これは将来の計画に役立つ可能性があります。
これが発生した理由HotAddトランスポートモードを使用してバックアッププロキシとして機能する仮想マシンをバックアップした後、バックアップは正常に完了しますが、クリーンアップ中に、通常の仮想ディスクがHotAddedディスクとともに誤って削除されます。
当時のVDDKキットの既知の問題でした- http://www.vmware.com/support/developer/vddk/VDDK-1.2.1-Relnotes.html 。 hotadd環境を構築している間、VADPでプロキシをバックアップしないことが非常に重要です。
解決策は、最終的にNetWorkerサーバーを完全に再構築することでした。これは、いくつかの理由で良いことでした。
これでバックアップが実行され、NetWorkerサーバー/ VADPプロキシのドライブが削除されません。