NetWorker:NetWorkerでのテープ ライブラリーのロード問題のトラブルシューティング
概要: この記事は、サポーターと管理者がライブラリ レベルまたはアプリケーション レベルでライブラリの読み込みの問題をトラブルシューティングするのを支援することを目的としています。問題が論理的なものか物理的なものか、およびロボット、ドライブ、またはメディアテープカートリッジの問題であるかどうかを判断します。
現象
- ライブラリへのテープカートリッジのロード中に散発的または一貫したエラーが発生する
- ライブラリー メディアからバックアップまたはリカバリーを実行できない
- ライブラリーが検出可能で、機能していることが確認され、準備完了
- ロード操作またはラベル付け操作を実行できません
- テープが「ラベルなし」とマークされている
- システム ログまたはアプリケーション ログにASC/ASCQ/SCSI SENSEエラーまたはメッセージが表示される可能性がある
- 特定またはランダムなライブラリ操作を実行する散発的または一貫性のあるエラー
原因
ライブラリ構成が以前は機能していたが、突然問題が発生した場合は、検出と構成を妨げる可能性のある変更を検討してください。
- ロボット、スイッチ、またはアダプターのファームウェア、ドライバー、または構成の変更
- ドライブ、テープ カートリッジ、またはその他のライブラリー コンポーネントの追加、交換、または取り外し
- NetWorkerソフトウェア バージョン、オペレーティング システム パッチの変更
- データ パス内のコンポーネントの電源喪失や再起動などのハードウェア イベント
- NetWorker構成とライブラリ間の不一致(たとえば、テープ カートリッジがNetWorkerの制御外に移動された場合)
ライブラリーが機能していない場合は、『 NetWorkerハードウェア互換性ガイド 』でハードウェアがサポートされていることを確認します(Dellサポート アカウントへのサインインが必要)。ライブラリが部分的に機能する可能性があることに注意してください。検出だけでは、操作性やサポート性は保証されません。
解決方法
ライブラリーのロードに関する問題をトラブルシューティングするには、最新の既知の変更を検討した後、プロセスをそのプリミティブ構成要素に委譲し、それらを個別にテストすることでトラブルシューティングを行います
必要なデータが収集されます NSRGet で実行すると、 -o:d スイッチは使用できません。NetWorker:「NSRGet NetWorkerデータ コレクション ツールの使用方法(英語)」
そうでない項目は、手動で試みると危険であると見なされる可能性のある操作に限定されます。
ライブラリーのロード: コミュニケーション
- 繰り返しになりますが、先に進む前に、ライブラリーが応答し、準備ができていることを確認してください。点灯しない場合は、次の手順に従います。
ライブラリーのロード: 物理操作
- ライブラリ操作が基本レベルで物理的に可能であることを確認します。ライブラリーがアクティブでないときにテストを行い、テープ カートリッジを元の場所に交換するようにしてください。
sjirdtag <changer address>
次に、テープ カートリッジをエレメント間で移動し、再びエレメントに戻します。
sjimm <changer address> <drive|slot|inlt|mt> <element_number> <drive|slot|inlt|mt> <element_number>
- エラーが予想される状況がいくつかあります。たとえば、自動取り出しがライブラリ レベルで有効になっていないライブラリでは、ドライブから他の要素に移動しようとするとエラーが発生します(テープ カートリッジは、
mt -f <device_handle> offlineコマンドを使用します)。 - ロボット操作(SCSI ASC/ASCQコード エラー)を試行したときに、散発的または一貫してエラーが返される場合は、ライブラリー ベンダーへのエスカレーションを検討してレビューを受けることを検討してください。
ライブラリーのロード: 論理演算
物理操作にエラーがないことを確認したら(少なくとも表面的には)、NetWorker内で問題の追跡を試みることができます。
- NSRジュークボックスの状態情報をロボットのテープ カートリッジ情報と比較して、ライブラリーのレイアウトを決定し、その準備ができていることを確認します。
nsrjb [<-j library_name>] -C sjirdtag <changer address>
- 影響を受けるテープを高冗長性で影響を受けるドライブにロードしてみます。
nsrjb [<-j library_name>] -lvvvvv -f <device_handle> -S <slot_number>
ライブラリーが問題なく繰り返し読み込まれる場合、ロードの問題は、永続的な障害ではなく、特定の状況要因が原因である可能性があります。ロード障害につながる状態を切り分けるためにあらゆる努力を払い、その状態をデバッグする必要があります (下記参照)。
- 通常のロード操作が失敗した場合、特にボリュームが「ラベルなし」とマークされている場合は、ロード試行中にラベルの読み取りが失敗しています( これにより、マウント が失敗します)。同じテープをマウントせずに、同じドライブに冗長性の高いリロードを試みます。
nsrjb [<-j library_name>] -lnvvvvv -f <device_handle> -S <slot_number>
- スタンドアロンのラベル検証を実行して、ラベル読み取りの失敗が一時的なものか、整合性があるかを確認します。
nsrmm -pvvvvv -f <device_handle>
- ラベルが正常に読み取られた場合は、テープ デバイスを物理的にロードした後、準備が整う前にラベルの読み取りが試行されることで、問題が解決される場合があります。この場合、システム環境または起動スクリプトで変数を設定してみてください。
MAX_LOAD_RETRIES=10
変数を設定した後も、複合ロード/マウント(ラベル読み取り)操作中にロード操作が引き続き失敗すると思われる場合は、「デバッグ」セクションに進んでください。
ライブラリーのロード: デバッグ
他のすべてが失敗した場合は、対象分野の専門家(SME)に相談する前に、問題のデバッグに役立つ適切なデータを収集します。
- NetWorkerで問題を再現する前に、NSR Jukeboxリソースで デバッグ トレース レベル を5に変更します
- 以下も使用します
dbgcommand実行中のデバッグレベルを上げるためにnsrdとnsrmmgdプロセスを 5 にdbgcommand -n PROCESS_NAME Debug=5- 無効にするには、次の手順を実行します。
dbgcommand -n PROCESS_NAME Debug=0 - NetWorker:デバッグ情報レベル
- 考慮
truss/tusc/strace、pstack、gcore/gencore適切なnsrlcpd問題発生前および問題発生中 - 豊富なデバッグ データを取得するために、システム環境(Windows)またはスタートアップ スクリプト(UNIX)でデバッグ変数を設定します。
SJI_DEBUG=9 LUS_DEBUG=9 CDI_DEBUG=9 SCSI_DEBUG=9 JBDEBUG=9
上記のいずれの方法でも問題が解決しない場合、「NetWorkerでのテープ ライブラリー検出の問題のトラブルシューティング」および「NetWorkerでのテープ ライブラリーのアクセスに関する問題のトラブルシューティング」に従って、デバッグから収集された証拠が内部異常を示唆している場合は、ライブラリー ベンダーに適宜サポートを依頼してください;それ以外の場合コードの欠陥の可能性を追求するために、デバッグ出力がNetWorkerサポート内でエスカレーションされていることを確認します。
その他の情報
この記事は、「Troubleshooting Tape Library with NetWorker」のシリーズの1つです。