NetWorkerは名前解決に依存しています。名前解決が正しくなく、全体に整合性がない場合、NetWorkerの操作の多くで問題が発生する可能性があります。NetWorkerは潜在的に機密性の高いデータを管理するため、さまざまな方法でやり取りするホストのIDを確認する必要があります。
次のようなNetWorkerで発生する症状は、NetWorkerでの名前解決が不完全であることが原因である可能性があります。
- 前方参照または逆引き参照の問題を示すエラー メッセージ。
- バックアップ中にクライアントを調査できない。
- クライアントがサーバーに手動で保存できないまたはリカバリーできない。
- ストレージ ノード デバイスのクローン作成またはアクセスに関する問題。
- 参照またはメディア データベース レコードの問題。
- サーバーまたはストレージ ノードが起動時または通常の操作中に応答を停止する。
- インデックス ディレクトリーの名前が間違っているまたはネストされている。
- クライアントが正しく設定されていない問題。
名前解決は、さまざまなメカニズムによってさまざまなレベルで行われます。
- NetWorkerネーム キャッシュ
- ローカル ホスト リゾルバー キャッシュ
- ローカルhostsファイル エントリー
- DNSルックアップ
名前解決の方法
1.NetWorkerのキャッシング：NetWorkerは内部ネーム キャッシュを保持しているため、サービスを再起動せずに名前解決の問題を修正するために行われた環境の変更を反映していない場合があります。また、NetWorkerには、すべてのクライアント インスタンスに対してグローバルな、「エイリアス」と呼ばれる構成可能なフィールドもあります。複数のタイプの問題を回避するには、エイリアスにそのクライアント インスタンスに対して解決可能なすべての名前を反映する必要があります。NetWorkerの内部キャッシュに必要な名前が存在する場合は、そこから使用され、ホスト リゾルバー キャッシュは参照されません。NetWorkerサーバー デーモン(nsrd)は、解決された名前キャッシュをdaemon.rawにダンプしたり、キャッシュをフラッシュしたり、名前をフラッシュして再解決したりする機能を備えています。
- dbgcommand -n nsrd PrintDnsCache=1（daemon.rawにダンプ）
- dbgcommand -n nsrd FlushDnsCache=1（フラッシュ）
- dbgcommand -n nsrd FlushDnsCache=9（フラッシュおよび解決）
- 上記のコマンドでは、「-n process name」または「-p PID」を使用できます。PIDを使用するには、最初に別のコマンドを実行してPIDを取得する必要があります。例えば、「ps -ef | grep nsr」(Linux)または「tasklist | findstr nsr」(Windows)。
2.リゾルバー キャッシュ：すべてのホストとオペレーティング システムには、hostsファイルまたはDNSサーバーに依存することなく、ホストの解決と速度を支援するローカル リゾルバー キャッシュがあります。このキャッシュは、通常のオペレーティング システム名前解決ルールに従って次にチェックされ、ホスト レコードが存在する場合（古い場合でも正しくない場合でも）、他のデータ ソースにクエリーを実行する前に使用されます。リゾルバー キャッシュ エントリーは、最初に解決試行が「成功」したときにキャッシュに入力され、所定の時間保持されます。一部のオペレーティング システムでは、リゾルバー キャッシュの内容を表示できます（例えば、Windowsホストは「ipconfig /displaydns」を実行できます）。また、すべてに強制的にクリアまたはフラッシュするためのメカニズムがあります。
- LinuxでのDNSのフラッシュは、Linuxディストリビューションとインストールされているパッケージによって異なる場合があります。ベンダーのマニュアルを参照してください。
- Windows：ipconfig /flushdns
3.hostsファイル：ホスト解決の従来のメカニズムでは、IPアドレスを明示的に入力し、そのアドレスに対して解決する名前を、空白で区切られた個別の行に入力します。これは、WindowsではデフォルトでDNSの前にチェックされます。Linuxでは、解決ソースの順序は通常、「/etc/nsswitch.conf」または「/etc/netsvc.conf」で設定できます。hostsファイルは、クエリー対象の最初の一致エントリーに対してのみ解析されます。したがって、IPアドレスまたはホスト名の2番目のインスタンスは、短いまたは長い場合でも、名前解決を試行しても見つかりません。すべての名前を対応するIPアドレスの同じ行に入力する必要があるため、各名前またはIPは1回だけ表示される必要があります。
- UNIX/Linux：/etc/hosts
- Windowsの場合： %systemroot%\System32\drivers\etc\hosts
メモ: hostsファイルは、他のファイルと同様に破損する可能性があります。不明な場合は、既存のhostsファイルの名前を変更し、新しいファイルを作成し、リゾルバー キャッシュをクリアして再試行します。
4.正引きによる名前解決：名前が指定されている場合に外部ホストと通信するには、ホストはTCP/IP通信を開始するために外部ホストのIPアドレスを見つける必要があります。DNSを使用する場合、IPアドレスを取得するには、前方参照ゾーンでそのホスト名に対してクエリーを実行する必要があります。クライアントが使用できるように複数のDNSホストが構成されている場合があります。Windowsシステムでは、「ipconfig /all」を使用してDNS名を取得します。Linux/UNIXオペレーティング システムでは通常、「/etc/resolv.conf」を使用してDNSサーバーの順序を取得します。「nslookup」は、DNSをクエリーするための最も一般的なツールであり、すべてのプラットフォームに存在しますが、よく誤って使用されます。前方ゾーンのクエリーを実行するには、次の手順を実行します。
- 引数を指定せず「nslookup」を実行して、対話形式のプロンプトを表示します。
- 参照する名前を繰り返し入力し、Enterを押して、接続先のDNSサーバーから前方レコードを取得します。
- 名前レコードが異なるホスト間でサイレントにラウンド ロビンされているか、同じデータを返すのかを確認するには、同じ名前をさらに2回入力します。
- そのホストが他のホストから呼び出される可能性があるか、自身を同じIPアドレスに対応していると見なす可能性がある名前のインスタンスについても、同じプロセスを繰り返します。
- 「server next_dns_server」と入力してホストが使用できるように構成されている他のDNSサーバーにも、同じプロセスを繰り返します。
メモ: 返されるすべてのレコードは、それぞれ整合性があり、管理者が正しいと理解しているものと一致している必要があります。すべての既知の名前を考慮に入れて、確認する必要があります。
5.逆引きによる名前解決：IPアドレスが指定されている場合に外部ホストと通信するには、ホストはそのホスト名を検索する必要がある場合があります。DNSを使用する場合、該当するIPアドレスのホスト名を検索するため、逆引き参照ゾーンに対してクエリーが実行されます。また、これも頻繁に誤って使用されます。nslookup IP_Addressと入力したり、「nslookup」にIPアドレスを入力したりしても、逆引き参照ゾーンのクエリーは実行されません。
- 引数を指定せず「nslookup」を実行して、対話形式のプロンプトを表示します。
- クエリー タイプを逆引きゾーンに変更するには、「set q=ptr」と入力します。
- 逆引きで解決するIPアドレスを入力し、Enterを押します。
- 逆引きレコードで返された名前が、前方レコード名/IPと一致していることを確認します。
[root@linux_a~]# nslookup linux_a
Server: 1.2.3.4
Address: 1.2.3.4#53
Name: linux_a.domain.com
Address: 5.6.7.8
[root@linux_a~]# nslookup 5.6.7.8
Server: 1.2.3.4
Address: 1.2.3.4#53
Name: linux_a.domain.com
Address: 5.6.7.8
[root@linux_a~]# nslookup
> set q=ptr
> 5.6.7.8
Server: 1.2.3.4
Address: 1.2.3.4#53
Non-authoritative answer:
8.7.6.5.in-addr.arpa name = linux_a.domain.com.
上記の例では、「nslookup」を対話形式以外で実行しても、逆引き参照ゾーンのクエリーが実行されないことは明らかです。
メモ: NetWorkerは、完全に整合性のある逆引き解決と標準的な正引き解決に大きく依存しています。これは、その認証プロセスの一部であり、IPスプーフィングやバックアップ データを盗むことを目的としたその他のタイプの攻撃を防ぐために意図的に設計されています。
解決策
すべてのNetWorkerホストは、通信するすべてのホストに対して、正引きと逆引きの両方で一貫した名前解決が保証されている必要があります（データ ゾーンの役割によって異なります）。NetWorker管理者にとって、ホスト解決の問題が直ちに完全に解決されるようにすることは重要です。
名前解決の問題をトラブルシューティングする場合、またはNetWorkerデータ ゾーンで問題を除外する場合は、次の手順を実行します。
1.障害が発生した操作に関連するすべてのホスト（サーバー、クライアント、場合によってはストレージ ノードなど）を検索します。
2.それぞれに対して、ローカルに構成されたIPアドレスと、それらのIPに対して想定されているすべての解決可能な名前を確認します。
3.ホスト解決にDNSの前にhostsファイルを使用するようにすべてのホストを構成します。
4.1つのホストのhostsファイルの先頭に、IPごとに1つのエントリーを構成し、すべての名前が同じ行でそれに対応するようにします。
5.これらの行を最初のホストから他の関連ホストのhostsファイルに正確にコピーします。
6.NetWorkerクライアント オブジェクトを編集して、必要なIPにエイリアスが正しく対応するようにします。
7.関連するすべてのホストでNetWorkerをシャットダウンします。
8.適切なオペレーティング システム メカニズムを使用して、各ホストのリゾルバー キャッシュをクリアします。
9.NetWorkerを再起動し、問題のある操作を再試行します。
特定のホストによって解決されている名前を調査するには、次のテストを使用します。
1.最初のNetWorkerホスト（例：クライアント）から、
nsradmin -s remote_host -p nsrexecを使用して2番目のホスト（サーバーなど）に接続します。セッションは開いたままにします。
2.同じホスト上で、「nsradmin」のプロセスを確認します（例：Windowsでは、
tasklist | findstr nsradminなど）。
3.「netstat」を実行して、そのプロセスに関連付けられているソケットを表示します（例：Windowsでは、
netstat -ao | findstr process_id）。
4.そのホストから接続しているソケットを確認します（出力の左端にある「IP:port」のペア）。
5.リモート ホストで、「:calling_port_from_first_host」に対して「netstat -a」と「findstr/grep」を実行します（右側に表示されます）。
6.コロンの左側に表示されるホスト名は、2番目のホストがインバウンド接続を解決する最初のホストの名前です。
7.「netstat」コマンドに追加された-nスイッチを使用して再度実行して、同じソケットのIPを確認し、IP/ルートが想定内であるかを確認します。
8.同じテストを逆にして、2番目のホストが想定されたパラメーター内で最初のホストを解決することを確認します。
多くのNetWorker操作（savegroupなど）では、複数の個別のTCPソケットを使用します。「savegroup」の例では、1つは制御セッション用、1つはデータ用、もう1つはインデックス更新用です。いずれかのセッションで整合性のない（技術的には正しい）名前を使用している場合は、操作に失敗する可能性があります。
- ラウンド ロビンは意図的に使用および構成されることはありますが、通常は想定されていないため回避されます。
- 「netstat -a」は、オープン/アクティブなTCPソケットを表示します。これにより、外部ホストのOS解決済み名が表示されます。これを、問題を特定するために使用できます。
- ネットワーク トラフィックが想定されていない/望ましくないアダプターを使用している場合、後で名前解決の問題につながる可能性があるため、静的ルーティングが必要になる場合があります。
次の記事も参照してください。
KB 463606：
「DNSと名前解決の問題のトラブルシューティング」