NetWorker：名前解決のトラブルシューティングに関するベスト プラクティス

NetWorkerは名前解決に依存しています。名前解決が正しくなく、全体に整合性がない場合、NetWorkerの操作の多くで問題が発生する可能性があります。NetWorkerは潜在的に機密性の高いデータを管理するため、さまざまな方法でやり取りするホストのIDを確認する必要があります。

次のようなNetWorkerで発生する症状は、NetWorkerでの名前解決が不完全であることが原因である可能性があります。

• 前方参照または逆引き参照の問題を示すエラー メッセージ。
• バックアップ中にクライアントを調査できない
• クライアントがサーバーに手動で保存できないまたはリカバリーできない。
• ストレージ ノード デバイスのクローン作成またはアクセス時の問題
• 参照またはメディア データベース レコードの問題。
• 起動時または通常動作中に、サーバまたはストレージ ノードが応答を停止します。
• インデックス ディレクトリの名前が間違っている、またはネストされている
• クライアントの設定ミス エラー

名前解決ワークフロー

コマンドまたは内部構成で使用されるホスト名を解決するには、IPアドレスに解決する必要があります。次のリソースが次の順序でチェックされ、 name:IP がすでにキャッシュされているかどうかがチェックされます。名前が一致すると停止します。 

1. NetWorkerの名前キャッシュ: ほとんどの主要なNetWorkerデーモン。nsrla データベースで設定可能なライフタイム
2. ローカル ホスト リゾルバー キャッシュ: オペレーティング システムによって異なり、ホストまたはDNSルックアップからのロードを延期します
3. ローカル ホスト ファイルの エントリー: 高速ローカル検索、ただし手動で管理されます。DNS解決を上書きするのに便利です
4. DNS サーバーのルックアップ: 一元管理により業界に好まれるが、時間がかかる

1.NetWorkerキャッシュ:

NetWorkerデーモンは内部の名前キャッシュを保持します。クライアントは解決された名前を nsrexecdにキャッシュしますが、 nsrd や nsmmdbd などのコア デーモンは独自のキャッシュを保持します。これは最初にチェックされるIPテーブルであり、最速です。内部キャッシュの有効期間は、次を使用して、各NetWorkerホストのnsrlaデータベースで設定できます。 nsradminが使用するJava Runtime Environmentへのパスを定義します。

Linux/UNIX

printf ". type: nsrla\nshow positive DNS cache TTL; negative DNS cache TTL\nprint\n" | nsradmin -p nsrexec -s remote_host

Windows

(echo . type: nsrla & echo show positive DNS cache TTL; negative DNS cache TTL & echo print) | nsradmin -p nsrexec -s remote_host

デフォルトで 30 分 (1800 秒) を返す必要があります。

positive DNS cache TTL: 1800;
negative DNS cache TTL: 1800;

この値は、NetWorkerがプロセス キャッシュを意図的にパージし、次のレイヤーから順次更新されるまでの時間を制御します。そのため、DNS ルックアップは遅いが、DNS アドレッシングが比較的静的である環境に適しています。逆に、アドレスが頻繁に変更される環境では、より低い値が望ましい場合があります。 

必要な名前がNetWorkerの内部キャッシュに存在する場合は、その名前が使用され、それ以降のクエリーは停止します。トラブルシューティングでは、キャッシュされた名前からIPへのマッピングが正しくないと思われる場合は、コマンドを使用して現在のキャッシュをログに記録し、エントリーをフラッシュまたは再解決します。

• • dbgcommand -n nsrd PrintDnsCache=1 (daemon.rawへのダンプ)
  • dbgcommand -n nsrd FlushDnsCache=1 (フラッシュ)、または、 
  • dbgcommand -n nsrd FlushDnsCache=9 (キャッシュをフラッシュしてすぐに再解決/再構築)

• • Linux/UNIX： ps -ef | grep nsr 
  • Windowsの場合： tasklist | findstr nsr

2.リゾルバー キャッシュ：

• • リゾルバー キャッシュのフラッシュは、OS/ディストリビューションによって異なります。ベンダーのドキュメントを参照してください。
  • Windowsの場合： ipconfig /flushdns

3.hostsファイル：

• • UNIX/Linux: /etc/hosts
  • Windowsの場合：%systemroot%\System32\drivers\etc\hosts

4.正引きによる名前解決：

• そのノードで nslookup 対話型プロンプトを入力するための引数はありません。
• 参照する名前を繰り返し入力し、Enterを押して、接続先のDNSサーバーから前方レコードを取得します。
• 名前レコードが異なるホスト間でサイレントにラウンド ロビンされているか、同じデータを返すのかを確認するには、同じ名前をさらに2回入力します。
• そのホストが他のホストから呼び出される可能性があるか、自身を同じIPアドレスに対応していると見なす可能性がある名前のインスタンスについても、同じプロセスを繰り返します。
• 「server next_dns_server」と入力してホストが使用できるように構成されている他のDNSサーバーにも、同じプロセスを繰り返します。

5.逆引きによる名前解決：

• そのノードで nslookup 対話型プロンプトを入力するための引数はありません。
• セットの入力 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.

名前解決のテスト

すべての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ホスト(クライアントなど)から、2番目のNetWorkerホスト(サーバーなど)に接続します。 nsradmin -s remote_host -p nsrexec - セッションを開いたままにします。
    2.同じホスト上で、nsradminのプロセス(たとえば、Windows、 tasklist | findstr nsradmin)
3.netstat を実行して、そのプロセスに関連付けられているソケット (たとえば、Windows、 netstat -ao | findstr process_id)
4.そのホストから接続しているソケットを確認します（出力の左端にある「IP:port」のペア）。
5.リモート ホストで、次のコマンドを実行します。 netstat -a と findstr/grep :calling_port_from_first_host。
    6.コロンの前のホスト名は、インバウンド接続を受け入れるときに2番目のホストが最初のホストを解決する方法です。
    7.次のコマンドを使用して再度実行します。 -n スイッチをnetstatコマンドに追加して、同じソケットのIPを検証し、IP/ルートが予期されているかどうかを確認します。
    8.同じテストを逆にして、2番目のホストが予想されるパラメーター内で最初のホストを解決していることを確認します。

NetWorkerクライアント エイリアスについて

NetWorkerには、「エイリアス」と呼ばれるすべてのクライアント インスタンスに対してグローバルな構成可能なフィールドもあります。これは、そのクライアントで解決可能なすべての名前を反映する必要があります。これにより、NetWorkerは複数の解決された名前を1つのクライアント インスタンスにリンクできます。たとえば、 client1.domain.prod は、使用されているIPに応じて、 client1.domain.bkup または client1と表示されることもあります。

セーブグループなどのNetWorker操作では、複数のTCPソケット(制御、データ、インデックスの更新にそれぞれ1つ)を使用します。一貫性のない (ただし有効な) 名前を使用するソケットがある場合、操作は失敗する可能性があります。

• ラウンド ロビンは意図的に使用および構成されることはありますが、通常は想定されていないため回避されます。
• netstat -a オープン/アクティブなTCPソケットを表示し、OSで解決された外部ホストの名前を表示します - これは問題を特定するために使用できます
• ネットワーク トラフィックで予期しない/不要なアダプターが使用されている場合、静的ルーティングが必要になることがあり、後で名前解決の問題につながる可能性があります。

次の資料も参照してください。  NetWorkerプロセスとポート