NetBackup™ トラブルシューティングガイド

ネットワークとホスト名のトラブルシューティングについて

複数のネットワークと複数のホスト名があるクライアントを含む構成では、NetBackup 管理者はポリシーのエントリを慎重に構成する必要があります。管理者は、ネットワーク構成 (物理的な構成、ホスト名とエイリアス、NIS や DNS などのネームサービス、ルーティングテーブルなど) を考慮する必要があります。バックアップデータおよびリストアデータを特定のネットワークパスで送信する場合には、特にこれらを考慮する必要があります。

バックアップの場合、NetBackup は、ポリシーで構成されたホスト名に接続されます。オペレーティングシステムのネットワークコードでこの名前を解決し、システムのルーティングテーブルに定義されたネットワークパスでその接続を送信します。この判断には、bp.conf ファイルは関与しません。

クライアントからのリストアの場合、そのクライアントはプライマリサーバーに接続されます。たとえば、UNIX コンピュータの場合、プライマリサーバーは /usr/openv/netbackup/bp.conf ファイルの先頭に指定されているサーバーです。Windows コンピュータの場合、プライマリサーバーは、［NetBackup マシンおよびポリシー形式の指定 (Specify NetBackup Machines and Policy Type)］ダイアログボックスの［バックアップおよびリストアに使用するサーバー (Server to use for backups and restores)］ドロップダウンメニューで指定します。このダイアログを開くには、 のバックアップ、アーカイブおよびリストアインターフェースを起動し、［ファイル (File)］メニューから［NetBackup マシンおよびポリシー形式の指定 (Specify NetBackup Machines and Policy Type)］を選択します。サーバー名を IP アドレスにマッピングする、クライアントのネットワークコードによってサーバーへのネットワークパスが決定されます。

接続を受信すると、ターゲットホストによって接続しているホストのピアホスト名が判断されます。ターゲットホストがプライマリサーバーの場合は、ピアホスト名からクライアントの構成名も判断されます。

ピアネームは、接続の IP アドレスから導出します。これは、(getnameinfo() ネットワークルーチンを使用して) アドレスがホスト名に変換される必要があることを意味します。接続が確立されると、次の行に示すとおり、この名前が bpcd または bprd のデバッグログに表示されます。

bpcd: Connection from host peername ipaddress ...

bprd: Connection from host peername ipaddress ...

クライアントでは、接続しているサーバーのピアホスト名は、ローカル NetBackup 構成内のサーバーまたはメディアサーバーのエントリと一致する必要があります (各サーバーエントリについて、文字列一致するか、getaddrinfo() の情報と比較)。

プライマリサーバーでは、比較の方が複雑です。

その後、bpdbm プロセスの問い合わせ (UNIX/Linux ホストの場合) または NetBackup Database Manager サービス (Windows ホストの場合) によって、クライアントの構成名がピアネームから導出されます。

最初に文字列の比較が行われます。この比較は、ピアネームをクライアント名のリストと比較することで検証されます。

名前が一致しなかった場合、総あたり的な方法が使用されます。この方法では、リスト内の各クライアント名について、getaddrinfo() を使用して見つかったすべての名前とエイリアスが比較されます。

最初に一致した名前が構成名になります。

比較が失敗すると、ほとんどの場合、要求内のホスト名がネットワークや NetBackup 構成などの管理制御下にないため、bprd が要求元クライアント (次に示す) をピアネームに置き換えます。

失敗した比較の例を次に示します。

クライアントに新しいネットワークインターフェースがあり、新しいネットワークを利用するために最初のサーバーエントリを変更したとします。プライマリサーバーのネームサービスが、クライアントの新しいソース IP を、どのポリシーのクライアントのネットワークエイリアスでもないピアネームに解決します。

VERBOSE が設定されている場合、これらの比較は bpdbm のデバッグログに記録されます。クライアント上で bpclntcmd コマンドを実行すると、クライアントの構成名を確認できます。たとえば、

# /usr/openv/netbackup/bin/bpclntcmd -pn (UNIX)

# install_path\NetBackup\bin\bpclntcmd -pn (Windows)

expecting response from server wind.abc.me.com 
danr.abc.me.com danr 194.133.172.3 4823

browse client 名は、表示するクライアントファイル、またはリストア元のクライアントを識別するために使用されます。クライアント上のユーザーは、この名前を変更して、異なるクライアントからファイルのリストアを行うことができます。たとえば、Windows クライアントの場合、ユーザーはバックアップ、アーカイブおよびリストアインターフェースを使用してクライアント名を変更できます。(手順については、NetBackup のオンラインヘルプを参照)。ただし、この変更を有効にするには、管理者もそれに対応する変更をサーバーで行う必要があります。

『NetBackup 管理者ガイド Vol. 1』を参照してください。

要求元クライアントは、CLIENT_NAME の値またはクライアントの gethostname() 関数で取得された値です。

destination client 名は、管理者がサーバーからクライアントへのリストアを実行する場合だけ関連します。ユーザーリストアの場合、destination client と requesting client は同じです。管理者主導リストアの場合、管理者は destination client に異なる名前を指定できます。

これらの名前が bprd のデバッグログに表示されるまでに、requesting client 名はクライアントの構成名に変換されます。

リストアを完了するためにクライアントに接続し直すときに使う名前は、クライアントのピアネームまたは構成名のいずれかです。この処理は、リストア要求の種類 (サーバーの root ユーザーからのリストア要求、クライアントからのリストア要求、異なるクライアントへのリストア要求など) によって影響を受けます。

クライアントが複数のネットワークでサーバーへ接続されているか、接続に関連する問題が原因でそのクライアントからのリストア要求が失敗した場合、これらのクライアント名について、管理者が手動で変更を加える必要がある可能性があります。

traceroute (UNIX) および tracert (Windows) プログラムは通常、ネットワークの構成に関する有益な情報を提供します。

ドメインネームサービス (DNS) を使用している場合に、クライアントが gethostname() ライブラリを実行して取得した名前がプライマリサーバーの DNS で認識されないと、プライマリサーバーがクライアントの要求に応答できないことがあります。クライアントとサーバーの構成により、この状況が存在するかどうかを判断できます。クライアントで gethostname() 関数を使用すると、プライマリサーバーの DNS で解決できない、修飾されていないホスト名が戻される場合があります。

ネームサービスを再構成する (ホストファイルを含む) ことも可能ですが、この解決方法が常に最適とはかぎりません。そのため、NetBackup では、プライマリサーバーに特別なファイルが提供されています。このファイルは次のとおりです。

/usr/openv/netbackup/db/altnames/host.xlate (UNIX)

install_path\NetBackup\db\altnames\host.xlate (Windows)

このファイルを作成および編集することで、NetBackup クライアントのホスト名を目的の名前に強制的に変換することができます。

host.xlate ファイルの各行には、数値キーと 2 つのホスト名の 3 つの要素が含まれます。各行は左揃えで、行内の各要素は空白文字で区切られます。

    key peername client_as_known_by_server
  

次に例を示します。

0 danr danr.eng.aaa.com

構成したクライアント名に対する要求 (数値キー 0 (ゼロ)) をプライマリサーバーが受信した場合、名前は常にピアネームを置換します。