test

Solstice Backup 5.1 管理者ガイド

クライアント/サーバー間通信

Backup の設定と構成の際に Backup ユーザーによって報告される問題の多くは、ネットワーク内の通信に関するものです。この節では、ネットワーク内の通信を検査する手順を説明します。

IP エラーを障害追跡するには

IP エラーを障害追跡するには、次の手順に従います。

  1. ご購入先に連絡する場合に備えて、対処した手順とその結果およびエラーメッセージを記録しておきます。

    必要な場合は、直接ご購入先に電子メールまたはファクシミリで送ってください。

  2. Backup クライアントとサーバーの両方に、ホストテーブルを設定します。

    次の 「ホストテーブルを構成するには」を参照してください。

  3. 検査を簡単にするため、ほかのネームサーバーを無効にします。

    詳細は、「障害追跡でのネームサーバーの無効化」を参照してください。

  4. ping コマンドを使って基本的な接続を確認します。

    詳細は、「ping コマンドを使ってネットワーク接続を検査するには」を参照してください。

  5. rpcinfo コマンドを使って、セッションが確立されていることと、ポートマッピングが正しいことを確認します。

    詳細は、「rpcinfo コマンドを使ってセッション確立を検査するには」を参照してください。

ホストテーブルを構成するには

IP 関連の問題の障害追跡には、ホストテーブルだけを使用することをお勧めします。しかしこれは、たとえば DNS などのネームサービスが Backup では使えない、ということではありません。Backup が正しくインストールされていることを確認する場合には、ホストテーブルだけを使います。Backup がホストテーブルで正しく動作することがわかったら、使用しているネームサーバーを有効にしてかまいません。

サーバーまたはクライアントでホストテーブルを構成するには、次の手順に従います。

  1. Backup クライアントで、その Backup クライアントそのものと、それが接続されている Backup サーバーを一覧表示させます。

    次に例を示します。


    127.0.0.1 localhost loopback
123.456.789.111 client client.domain.com
123.456.789.222 server server.domain.com

  2. Backup サーバーで、その Backup サーバーそのものと、それに接続されているすべてのクライアントを一覧表示させます。

    次に例を示します。


    127.0.0.1 localhost loopback
123.456.789.111 server server.domain.com
123.456.789.222 client client.domain.com

  3. 「ping コマンドを使ってネットワーク接続を検査するには」のガイドラインに沿って、各オペレーティングシステムでもっとも成功率の高いホストテーブルの構文解析方法を確認します。

    ホストテーブル構成での注意事項を次に示します。

    • ホストテーブルの本体 (ボディ) 部分には、空行は使わないでください。

    • ホストテーブルの最後には、必ず空行を入れます。

    • 手順 1 および 2 に示した順序と形式に従ったうえで、注釈のない最初のエントリは必ずループバック行にしなければなりません。

    • 注釈のない各行の最後の文字は、改行ではなく空白にしなければなりません。

    UNIX プラットフォームの場合は、ホストテーブルは /etc/hosts ファイルにあります。

    ホストテーブルは、必要に応じて DNS とともに使用できますが、障害追跡を容易にするためには、一時的に DNS を無効にします。

障害追跡でのネームサーバーの無効化

名前解決における問題の障害追跡を容易にするために、DNS、WINS、DHCP といったサービスを無効にすることをお勧めします。名前解決において問題が起こった場合は、まず使用しているマシンのホストテーブルだけを構成し、次にバックアップを検査します。

DNS、WINS、DHCP の各サービスで起こりうる共通の問題として、次のものがあります。

DNS はネットワーク全体で無効にする必要はなく、検査する Backup クライアントと Backup サーバーの最初の設定時にだけ無効にしてください。クライアントの機能のうち、DNS サーバーから IP の命名情報を取得する機能だけを無効にします。通常は、DNS サーバーそのものを無効にする必要はありません。

大部分の UNIX プラットフォームの DNS サーバーを無効にするには、/etc/resolv.conf ファイルの名前を変更して再起動します。

Solaris の場合には、resolv.conf ファイルの名前を変更する代わりに、DNS サービスの前にホストテーブルが検索されるように、IP 名の検索順序を設定することができます。

IP 名の検索順序を設定するには、次の手順に従います。

  1. /etc/nsswitch.confファイルを編集して、/etc/resolv.conf ファイルがあることを確認します。

  2. ホストファイルが先頭、2 番目が DNS、最後が NIS になるように、検索順序を指定します。

    次に例を示します。


    hosts: files [NOTFOUND=continue] DNS [NOTFOUND=continue] nis

ping コマンドを使ってネットワーク接続を検査するには

ホストテーブルを作成したら、ping コマンドを使って接続を検査します。

Backup クライアントでの操作


# ping mars
# ping mars.oak.com

Backup サーバーでの操作 (サーバーが唯一のクライアントである場合は、アスタリスク (*) を付けた手順だけを実行)

rpcinfo コマンドを使ってセッション確立を検査するには

ping コマンドによって接続が確認されたにも関わらず、依然としてバックアップの問題が解決できない場合は、rpcinfo コマンドを使って検査することもできます。Backup はポートのマッピングに非常に大きく依存しているので、rpcinfo コマンドを使ってポートマッパの動作を調べます。ping コマンドは、OSI モデルで言えばネットワーク層までの接続を検査するもので、rpcinfo コマンドは、そのセッション層までの通信を調べるものと言えます。

rpcinfo コマンドによる検査は、ping コマンドの場合と同じです。サーバーそのものが唯一のクライアントである場合は、前述の操作のうちアスタリスク (*) を付けた検査だけを行います。

rpcinfo コマンドを実行するためには、コマンド行にホスト名が入力されるマシンにおいてポートマッパが稼働していなければなりません。Sun のポートマッパは、ほとんどの場合、完全な機能を備えた Sun 以外のベンダー製のポートマッパ と互換性があります。独自のポートマッパ付きの製品を使用している場合は、Backup が環境内のほかの部分に対しても動作することが検証されるまでは、サードパーティのポートマッパをロードしないことをお勧めします。これで、未知のポートマッパを追加せずにポートマッパの互換性を検証できます。

Solaris では、rpcbind デーモンが動作していなければなりません。rpcinfo ユーティリティは、オペレーティングシステムの一部に組み込まれています。

TCP を使用しているポートを表示するための rpcinfo コマンドの構文は、次のとおりです。


rpcinfo -p hostname

ping コマンドの場合と同様に、hostname 変数の位置にロングネームとショートネームを指定します。

そのほかの rpcinfo コマンド行オプションを表示するには、コマンド行に rpcinfo と入力します。rpcinfo コマンドについての注意とエラーメッセージは、UNIX の rpcinfo のマニュアルページを参照してください。このマニュアルの ping の説明で示したすべてのサーバーおよびクライアントの位置を繰り返し指定して、rpcinfo コマンドを入力してください。

rpcinfo コマンドが正常に実行されると、ポートの番号と名前が一覧表示されます。障害追跡で必要となるのは、エラーメッセージの正確なテキストです。rpcinfo コマンドに対する正常な応答の一般的な形式は、次のとおりです。


rpcinfo for mars
program vers proto   port
100000    2   tcp    111  portmapper
100000    2   udp    111  portmapper
390103    2   tcp    760
390109    2   tcp    760
390110    1   tcp    760
390103    2   udp    764
390109    2   udp    764
390110    1   udp    764
390113    1   tcp   7937
390105    5   tcp    821
390107    4   tcp    819
390107    5   tcp    819
390104  105   tcp    822

スイッチとルーターのファームウェアの検査

あるべンダーのスイッチまたはルーターを使用している場合は、RPC (遠隔手続き呼び出し) のトラフィックが正常に処理されていることを確認するため、ネットワーク上のすべてのスイッチまたはルーターのファームウェアが、1995 年 8 月以降に作成されたものかどうかを調べます。スイッチベンダーとルーターベンダーの多くは、1995 年 8 月以降に、RPC トラフィックの処理能力を大きく向上させました。

命名の要件

UNIX 版 Backup クライアントのリリース 4.2 以降では、/nsr/res サブディレクトリにある servers ファイルを使って、Backup サーバーがクライアントのデータをバックアップする許可を与えられているかどうかを判断します。servers ファイルがない場合は、好みのエディタを使って、そのファイルを /nsr/res に作成できます。

クライアント上の servers ファイルに、クライアントのデータをバックアップしたいサーバーのショートネームとロングネームの両方が記載されていることを確認します。たとえば、oak.com というドメインにある mars という Backup サーバーは、Backup クライアントの servers ファイルに次のように記載されます。


mars
mars.oak.com

「Clients」リソースでショートネームとロングネームの両方を指定し、各クライアントに該当するほかの別名があれば、それらも「Alias」属性に指定します。

サーバーエラーとの関連付け

Backup は、クライアント/サーバーモデルに対応しています。このモデルでは、RPC によってサーバーがクライアントにサービスを提供します。これらのサービスは、長期間存続するプロセスであるデーモンの内部で存続します。

クライアントがデーモンを探し出すためには、デーモンを登録サービスに登録しておかなければなりません。デーモンは、起動時に、ポートマッパが提供する登録サービスに自動的に登録されます。

Backup サーバーは、バックアップと復旧の両方のサービスを提供します。Backup サーバーはクライアントからデータを受け取り、バックアップメディアに保存し、要求があった時点で取り出します。Backup デーモンが動作していないときに Backup サービスが要求されると、セーブグループ完了メールに次のメッセージが表示されます。


Server not available
RPC error, remote program is not registered

これらのメッセージは、Backup デーモンである nsrd、nsrexecd、nsrindexd、nsrmmd、および nsrmmd が動作していない可能性があることを示しています。デーモンを再起動するには、スーパーユーザーになって、シェルプロンプトで次のコマンドを入力します。


# /etc/init.d/networker start

リモートファイルシステムの保存

リモートクライアントのバックアップが失敗すると、セーブグループ完了メールに、次のようなエラーメッセージが表示される場合があります。


All: host hostname cannot request command execution
All: sh: permission denied

最初のメッセージは、クライアント上の nsrexecd デーモンが、サーバーがクライアントのファイルをバックアップできるように構成されていないことを意味しています。2 番目のメッセージは、クライアント上で現在 nsrexecd デーモンが動作していないことを意味しています。

これらの問題を解決するには、クライアント上で nsrexecd デーモンが動作していることを確認し、サーバーのホスト名がブート時ファイルに記載されていることを確認します。ブート時ファイルは、インストールスクリプトが終了する前に自動的に作成され、バックアップのためにクライアントと交信するすべてのサーバー名をユーザーに尋ね、ユーザーが応答するサーバー名を優先度の順に並べます。表 C-1 にブート時ファイルのディレクトリを示します。

nsrexecd デーモンの詳細は、nsrexecd(1m) のマニュアルページを参照してください。

表 C-1 ブート時ファイルのディレクトリ

オペレーティングシステム 

ブート時ファイル 

Solaris 

/etc/rc2.d/S95networker

SunOS 4.1.x 

/etc/rc.local

リモート復旧のためのアクセス権

「Client」リソースを構成することにより、復旧に必要なクライアントへのアクセスを制御できます。復旧のためにクライアントのセーブセットにアクセスできるユーザー名が、「Remote Access」リストに表示されます。ファイルに必要なセキュリティレベルに応じて、ユーザー名を追加したり削除したりできます。

次に示すユーザーは、「Remote Access」リストの内容にかかわらず、どのクライアントのどのファイルでも復旧できます。

これら以外のユーザーは、ファイルがバックアップされた時点でのファイルのモードと所有者に応じて、読み取りを許可されているファイルだけを復旧できます。スーパーユーザー、オペレータ、オペレータグループ以外のユーザーがファイルを復旧すると、そのユーザーがファイルを所有します。