NetWorker：テープ デバイスのSCSIリセットおよびラベル上書きのトラブルシューティング

テープ デバイスに対して生成されるSCSIリセットにつながる可能性のあるイベントには、次のようなものがあります。

• 予期しないホストからテープ デバイスへのアクセスを許可するゾーニングの変更。
• 1つのゾーンに複数のイニシエーターを誤って配置するゾーニングの変更。
• ゾーニングの変更により、ディスクとテープ ターゲットが同じゾーンに配置されます。
• イニシエーターが個別にゾーニングされているゾーニングの変更は、テープとディスクのターゲットに対しても別々に行われます。
• 同じHBA上にある場合、別々のイニシエーターを持つゾーニングの変更は、テープとディスクのターゲットにゾーニングされます。
• 電源イベントまたはSANハードウェアの誤動作。
• ゾーニングされたホスト上でのソフトウェアのインストールまたは変更。これにより、あらゆる種類の照会やテープ アクセスを実行できます。
• ゾーニングされたホストのオペレーティング システムの調整可能、ドライバーまたはファームウェアの変更。
• 仮想および物理テープ デバイスのデータ ロス

• マウントできないボリューム
• ロボット工学に関する潜在的な問題
• プラグアンドプレイ オペレーティング システム用にデバイス名を変更

SCSIプロトコルにより、イニシエーターは SCSI_RESET コマンドは、リセットが発行されたデバイスのクラス、およびデバイスの状態に基づいて、さまざまな効果を持つ可能性があります。この記事では、テープ クラスのデバイスに発行されるリセットについて説明します。テープ・クラス・デバイスの場合、 SCSI_RESET 予約が破棄されるだけでなく、テープ デバイスの巻き戻しも発生します。

リセットは通常、転送環境でのハードウェアの誤動作 (まれ)、またはビジー状態のデバイスと通信しようとするプロセスという 2 つの条件のいずれかの結果です。後者の条件では、デバイスがプロセスの要求に応答しないときにSCSIプロトコルがリセットを要求します。

SCSIの設計では、1つのホストと1つのプロセスがデバイスとのすべての通信を処理する、シンプルなシングルアクセサー環境を想定しています。複数のホストまたはプロセスがSCSIデバイスにアクセスすると、NetWorkerなどのマルチホスト スイートの外部で、無関係なプロセスの調整が欠如しているため、リセットが発生する可能性があります。

リセットするとテープが巻き戻されるため、リセットはテープ環境でダメージを与えます。ほとんどのソフトウェアは、使用中にテープが巻き戻されることを想定していません。ドライバーは書き込みを終了し、次のセッションのためにテープをデータの終わり (EOD) に残します。予期しない巻き戻しは、意図したEOD追加がテープの物理的な先頭ではなく、書き込みを開始するように強制することで損傷を引き起こします。

リセットは、多くの場合、検出が困難です。UNIXオペレーティングシステムには、システムリセットの表示とデバイスログが含まれている場合があります。Windowsは通常、サポートしていません。同様に、NetWorkerはリセットの発生を検出しません。また、リセットによってテープが巻き戻される可能性があるため、ラベルが不注意でサイレントに上書きされることがあります。

次の一連のイベントは、NetWorkerが仮想テープまたは物理テープにラベルを付け、書き込みを開始した後のテープの構造を示しています。これは、2つの32 KBラベル ブロック、256 KBデータ ブロック、セッション間のファイルマーク、およびデータの論理的な終わりを示す二重のファイルマークを示しています。

この表現は、メディアの物理的な始まりを示し、物理的な終わりは表現しません。

この段階では、NetWorkerの nsrmmd プロセスは追加のデータを待機しており、ドライバーにアクティブに接続されており、UIには「書き込み中、アイドル状態」と反映されています。他のプロセスによってSCSIリセットが発行された場合、デバイスはサイレントに巻き戻されます。これと同じ方法で、より多くのデータ セッションが始まります nsrmmd、書き込みを続けているが、テープの冒頭から:

これで、ラベルは上書きされ、データは最初にテープのスパンを占有していました。上書きされていないデータも、新しい二重ファイルマーク/論理 EOD によってドライブのそれ以降の読み取りがブロックされるため、アクセスできなくなります。

SCSIリセットには、比較的多くの既知の原因があります。

• Microsoftオペレーティング システム(自動実行)での頻繁なテスト ユニット準備完了(TUR)信号
• 同じテープ ドライバーを使用するように構成された他のバックアップ ソフトウェア。
• テープ デバイスに問い合わせたり、HBAデバイスのフル スキャンを実行したりするモニタリング ソフトウェア。
• テープ ドライバーにアクセスする個々のプロセスまたはスクリプト (mt、 tar、によって使用されるいくつかのプログラム udev 等々)。

SANゾーニング

• 前述のように、リセットのトラブルシューティングと防止を容易にするために、次のゾーニングのベスト プラクティスに従ってください。
• デバイスを使用するように構成された同じデータゾーンのNetWorkerホストのみをゾーニングする必要があります(他のデータゾーンは含めないでください)。
• シングルイニシエーター ゾーニングが必要です。1:1のゾーニングが推奨されます。ディスクとテープは、同じゾーンを共有してはならず、理想的には同じイニシエーターまたはHBAを共有してはなりません。
• 理想的には、テープとディスクのトラフィックをスイッチ レベルで分離し、最高のパフォーマンスと信頼性を実現する必要があります。

ゾーニングされたホスト プロセス

• 各ホストについて、テープ ドライブに何らかの方法でアクセスする可能性のある インストール済みのソフトウェア、サービス、 スクリプトを確認します。
• その他のバックアップ ソフトウェアは、どのような種類のバックアップ ソフトウェアでも、NetWorkerストレージ ノードまたはサーバーと共存させることはできません。
• テープ デバイスとの通信を試行するセキュリティ ソフトウェアまたは監視ソフトウェアを実行しないでください。

ゾーニングされたホスト オペレーティング システムの構成

Windows

• 確保 StorPort ドライバーは最新です。
• テープ ドライバーの[Test Unit Ready]を無効にします。「サポート技術情報」 (Microsoft Knowledge Base) アーカイブ 
• Windowsホストを再起動すると、ゾーニングされたすべてのデバイスにリセットが発行されることがある

Linux

• 使用しない udev ドライブ自体に問い合わせるユーティリティーを使用するルール(標準装備) udev ルールが推奨されます)。
• CDIおよびデバイス構成の簡易予約機能を有効にします。

Solaris

• ATape ドライバーで CDI を使用しないでください。CDIが想定され、強く推奨されるため、代わりにネイティブ ドライバーをお勧めします。

HP-UX

• Disable dm_stape モジュール：編集 /var/stm/configuration/tools/monitor/dm_stape.cfg 値を使用するには POLL_INTERVAL=0 EMS を再起動します。
• 確保 PHKL_40389 テープのホットフィックスがインストールされています。
• カーネル チューナブルを設定して、OSレベルの予約がリセットされるようにする st_san_safe=1の詳細を確認してください。
• そのノードで scsimgr set_attr -d estape -a norewind_close_disabled=1の詳細を確認してください。
• そのノードで scsimgr save_attr -d estape -a norewind_close_disabled=1の詳細を確認してください。

AIX

• 予約がOSレベルでオフになっていることを確認します。 /usr/sbin/chdev -l rmt<#> -a res_support=noの詳細を確認してください。
• ATape動的トラッキング機能を無効にします。

NetWorker構成の回避策 上記の点をすべて調査して修正しても、原因を特定できず、問題が解決しない場合は、次の手順を実行します。

1. データゾーン内のすべてのテープ デバイスで、テープ デバイス(SCSIコマンド)と永続的な予約でCDIを有効にします。
2. ファイラー オペレーティング システムでもSCSI予約(理想的には永続的/SCSI-3)を有効にします(詳細については、ベンダーにお問い合わせください)。

この回避策は理想的ではなく、通常は必要ありませんが、根本原因を特定できない場合は、この回避策によって部分的に緩和される場合があります。

NetWorkerフォレンジック

• 影響を受けたテープはマウントに失敗し、NetWorkerによって「ラベルなし」とマークされます(ただし、メディア データベースのエントリーはそのまま残りますが、正しくありません)。
• ボリュームが過度に大量のデータを保持しているように見える場合があります(複数の未検出の巻き戻しによる)。
• テープが「早期にフルとマークされている」というエラーでバックアップが失敗する場合は、書き込みSCSIの中間リセットを示している可能性があります。
• NetWorkerの最初の20行は、SCSIリセットが発生していることを最も明確に示しています。
  • 予期しないファイル番号で、2が必要でしたが、34 を取得しました(実際の数は異なる場合があります)。
• エラーで 取得した 番号を比較することで、リセットがいつ発生したかを判断できる場合があります。
  • セーブセットの表示元 mminfo その最小の mediafile 値 (マイナス 3) は、リセット が発生する前に 書き込みを完了し、その完了により、リセットが行われた書き込み アイドル期間につながった ものです。 sscomp(22) mminfo 値はリセット 前 です。
  • セーブセットの表示元 mminfo その番号の最も低い mediafile 値 (マイナス 2) を持つのは、リセット が発生した後 に書き込みを開始した人であり 、書き込み、アイドル 期間 (リセットが行われた後) に開始した人 - ssccreate(22) mminfo 値はリセット後です。
• その時点で書き込みを実行するホストは、リセット イニシエーターである必要はありません。デバイスにゾーニングされた異なるソフトウェアを搭載した別のホスト、ローカル ソフトウェアの干渉、またはその他のドライバー レベルまたはSANレベルの問題が考えられます。

この記事は、「Troubleshooting Media Problems with NetWorker」シリーズの1つです。リストはここにあります:
NetWorker: テープ ライブラリーのトラブルシューティングのホーム ページ