VDDKエラーの美しさと恐ろしさは、一方ではどこで発生したかが完全に明確であり、他方では、なぜ、どのように修正するのかが完全に理解できないことです。これは、Windowsの世界でRPC呼び出し関数が失敗したようなものです。
もちろん、すべてがそれほどひどいわけではありませんが。一部のエラーには、非常に具体的な原因と処理があります。そして、いくつか-最も一般的な原因とそれらを修正するためのオプションの古くから知られているリスト。
もちろん、Veeamテクニカルサポートはそのような知識を蓄積しているので、今日はそれらのエントリを見ていきます。したがって、最も一般的なVDDKエラーとそれらを排除する方法を紹介できることを大変嬉しく思います。
VDDKエラー。それは何で、どのように入手されますか?
名前から推測できるように、これらは、VDDK Api(仮想ディスク開発キット)のレベルでのある種の問題です。これは、vSphereインフラストラクチャと対話するための最良の方法です。それが別個のESXiホストであるか広大なvCenterであるかは関係ありませんが、インフラストラクチャから何かを書き込んだり読み取ったりする必要がある場合、これを行う最良の方法は無料のVDDKです。
可能な限り単純化するために、この相互作用は次のようになります。たとえば、Veeamサーバーは、ホストから何かを読み取り(または書き込み)、要求を送信することを望んでいます。どのディスクから、どれだけ読み取りたいか、どのオフセットから、メモリ内のどのバッファに送信するかを示す読み取り呼び出しが作成されます。または、同様に、指定されたバッファから書き込みます。簡単だ。
しかし、これは完璧な世界です。
実際には、この単純なアルゴリズムの途中でエラーが発生することがあります。そのため、リクエストを完了できません。そして、期待される応答の代わりに、エラー番号が表示され、ログに注意深く記録されます。
今日は、最も一般的なそのような間違いについて話します。
重要な免責事項!
わからない-しないでください!何も押さないでください!Veeamサポートに電話または手紙を書くことは、製品を試すよりも常に優れています。幸い、私たちのサポートはロシア語を話し、非常に技術的です。
少しでも疑問がある場合は、電話して質問してください。「このような問題があります。ネットワーク上でこの解決策を見つけました。解決に役立ちますか?」-正常で正しい。正常ではなく、正しくないのは、自分の行動に確信が持てず、多くのことを行い、5分以内に廃墟からすべてを復元するように依頼することです。
はい、もちろん、この場合は私たちがお手伝いしますが、最良の戦いは存在しなかった戦いです。したがって、常に自分の行動とすべての大きな稼働時間を批判的に評価するようにしてください。
VDDKエラー1:不明なエラー
実際、この間違いに関するHFの記事全体があります。そして、それが言うように、ほとんどの場合、このエラーは、インストールされているパフォーマンスカウンターが多すぎる場合に発生します。そして、すべてを修正するパッチをVMwareからダウンロードします。
一方で、コメントすることすらありません。ここに問題があり、ここに説明があります(それがあまり明確ではない場合でも)、そして最も重要なことに、ここに薬へのリンクがあります。ただし、すべてがそれほど単純というわけではありません。私たちの観察によると、このエラーは、カウンターの退屈な問題だけでなく、次の理由でも発生する可能性があります。
- VMDK . , , . — — . , . , , .
- datastore. . , .
- HBA . , . . ?
- , : ESXi vCenter.
まあ、まあ、私はそれに追いついた、とあなたは言います。そして、何?新しいディスクを緊急に実行する時が来たことを理解する方法-またはパッチを適用して息を吐くのに十分ですか?
そして、私はあなたに答えます-何かが起こった場合にあなたが正しい決定をするのを助ける一連の簡単なテストを保管してください。
- Storage vMotionを起動するか、疑わしいマシンを別のデータストアにクローンしてから、バックアップを開始しようとします。クローン作成が失敗した場合は、ディスクサブシステムのどこかに間違いなく問題があります。パラノイアモードを最大限に-そしてディスクからコントローラーまですべてをチェックします。
クローンが作成されて正常に保存された場合は、VMDKが破損していることを意味します。これは、クローン作成中にVMwareがコンテンツを再作成し、エラーが発生していないためです。
- , . , . « — » .
- , , , — VMware.
- , . , .
VDDK error 2: Value: 0x0000000000000002
ほとんどの場合、VDDKエラー1と密接に関連しています。統計によると、エラーの出現は通常、vCenter / ESXiバンドルの特定のバージョンに関連しているため、ここでの最善のアドバイスは、少なくともバージョン6.7にアップグレードすることです。そしてより良いそして7.0。
それでも問題が解決しない場合は、プランBに進み
ます。ESXiホストがNFC読み取りバッファーに割り当てられたメモリーを使い果たすと、エラー自体が表示されます。デフォルトでは、Veeamは非同期NBD / NFC読み取りモードで動作します。通常の状態では、このバッファーを拡張する必要があります。しかし、これは常に起こるわけではありません。したがって、このモードを無効にするには、特別なキーがあります。
Name: VMwareDisableAsyncIo
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Type: REG_DWORD
Value: 1
作成後、Veeam Backup Serviceを再起動し、パフォーマンスが約10%低下する準備をする必要があります。
別のオプションは、ホスト側からログインして管理エージェントを再起動することです。
/etc/init.d/hostd restart
/etc/init.d/vpxa restart
手順はVMwareのKBに詳しく説明されているので、書き直しません。
そして、診断プロセス中に整理するのに不必要ではないオプションの標準セット:
- エラーのあるマシンを別のホストに移行します。
- 別のトランスポートモードを試してください-仮想プロキシまたはDirectSANを使用したHotAdd。
VDDKエラー3:パラメータの1つが無効です
仮想アプライアンスモード(別名HotAddモード)を使用しているときにほとんど常に発生するエラー。
ここで特別なことは何もありません。多くのオプションが説明されている2つのKBへのリンクを示します。すぐにサポートに来たとしても、そこに書かれていることはすべて行うように求められます。
KB1218-考えられる問題の一般的な説明とそれらを排除する方法。
KB1332 -VeeamサーバーがHotAddモードのプロキシとして機能する場合
VDDKエラー13:このファイルへのアクセス権がありません
そしてこの場合、KB2008があります。はい、この問題を解決するための多くのオプションがありますが、そのような間違い。あなたのケースで何が起こったのかを明確に言うことはほとんど不可能なので、リスト全体を繰り返して調べる必要があります。
さらに言いたいこと追加のトラブルシューティングセクションには十分注意してください。はい、書かれていますが、おそらく多くのことにはあまりにも明白です。しかし、そのような礼儀でさえ、最も専門的な専門家を逃れます。 1週間後、自分たちですべてを解決しようとして、技術要件のリストを注意深く読んでいないことなどを知っただけでサポートに来る場合がよくあります。そして、それは費やされた時間の恥と残念です。
そして、常に2つのヒント:
- Veeam proxy , UUID . - , . , , .
- ( — ), , VDDK .
VDDK error 18000: Cannot connect to the host
ほとんどの場合、このエラーの障害は、VDDK自体のバグにあります。具体的には、gvmomi.dllライブラリが原因です。そして、彼は重い負荷の下でのみ自分自身を示しています。たとえば、多数のマシンを並行してバックアップすると、関数の1つが0になり、ライブラリが崩壊する可能性があります。そして、他のすべてが落ちます。
これは悲しい話です。
しかし、この話で最悪なのは、バグの状態を正確に再現することが不可能なことです。これは、テスターがフローティングバグと呼ぶものです。したがって、クラッシュの原因となっている並列マシンの数を正確に言うことは不可能です。
ただし、公式リリースノートによるとこのバグは完全に修正されました。したがって、正しい方法はホストを更新することです。しかし、何らかの理由でこれを行うことが不可能な場合、私たちが支援できる唯一の方法は、同時に処理されるマシンの数を減らすようにアドバイスすることです。
他に方法はありません。
VDDKエラー14008:指定されたサーバーに接続できませんでした
したがって、この問題が発生した場合、最初に行うことはネットワークをチェックすることです。ほとんどの場合、vCenterとVeeamプロキシ間の通信がダウンしています。すべてのDNS名が予想されるIPアドレスに正しく解決されているかどうか、すべてのポートが開いていてアクセス可能かどうかを確認します。さらに、失敗したジョブに関係する特定のプロキシをチェックする必要があり、その隣に立っているプロキシではありません(場合があります)。
このエラーのあるケースの95%は、「クライアントインフラストラクチャのDNS /ポートの問題」のマークで閉じられています。
したがって、ここでも、正しいDNSサーバーがどこにでも示されているかどうか、閉じたポートがあり、どのIPでFQDN名が解決されているかを注意深く確認することをお勧めします。
古いバージョンのVDDKでは、vCenterの操作にデフォルト以外のポートを使用したときに同様のエラーが発生しました。これは残りの5%を占めていましたが、VMwareはその説明でKBを非表示にしました。これは、KBが関連しなくなったことを意味します。ただし、2108658のインターネットアーカイブで検索できます(VMware vCenter Serverにデフォルト以外のポートが指定されている場合、バックアップは失敗します)。
VDDKエラー14009:サーバーが接続を拒否しました
そして、今日のトップの最後の間違いは、サーバーが接続を拒否したことです。ここではすべてが完全に平凡です。何かがホストとプロキシ間の接続を妨げています。ほとんどの場合、ファイアウォールが原因です。しかし、微妙な点は、ポートが閉じているためではなく、遅延が発生しているためです。そのため、まず、ポート443のオープン性を確認してから、タイムアウトを確認します。
両方のオプションで何も得られなかった場合は、サポートにアクセスしてください。ホスト自体を確認する必要があります。おそらく彼は忙しすぎて時間内に応答する時間がない、そしておそらく何か他のものです。
そして最後に、いくつかの便利なリンク:
- 受賞歴のあるテクニカルサポートのポータル。
- Veeamサポートナレッジベース