ACSLS は高度なカートリッジ管理機能を提供します。これらの機能はいくつかの方法で提供されます。
自動的 (失われたカートリッジの回復など)。
デフォルトで有効 (不在カートリッジと取り出し済みカートリッジに関する情報の保持など)。
顧客による定義 (カートリッジが監査によってデータベースに追加される場合、または CAP を介して挿入される場合の、ボリューム属性の割り当てなど)。
適切なカートリッジ管理機能を使用することで、ACSLS が提供するものの価値が高まります。
カートリッジ管理は次で構成されます。
カートリッジは、ライブラリがオフラインのときにセルに手動で配置するか、CAP を介してライブラリに挿入できます。
ライブラリと ACSLS を適切に機能させるための重要な要件は、マウント解除、パススルー、および取り出し操作に対応させるために、各 LSM のいくつかの空きセルが使用可能であることです。各 LSM に取り付けられているテープドライブごとに、少なくとも 1 つの空きセルを予約する必要があります。
LSM の空きセル数を確認するには、次のコマンドを発行します。
query lsm lsm_id
SL8500 では、各レールが LSM として定義されます。
次のセクションでは、CAP のタイプ、状態、モード、および優先順位を説明します。
CAP の各タイプには、カートリッジをロードするための標準の容量と方法があります。1 つの LSM に複数のタイプの CAP がある場合があります。次の表に、サポートされている CAP のタイプ、識別子と容量、およびロードの方法を示します。
| CAP のタイプ | 識別子と容量 | ロードの方法 |
|---|---|---|
|
StorageTek VTL |
CAP 0。20 個のカートリッジを保持します |
仮想ボリュームは Audit を使用して検出されます。VTL の動作を参照してください。 |
|
SL3000 |
CAP 6 およびオプションで CAP 1-5、CAP 7-10。それぞれが 26 個のカートリッジを保持します。 |
CAP 内にロードされている 2 つの取り外し可能なマガジンのそれぞれに、13 個のカートリッジが配置されます。 |
|
SL8500 回転式 |
CAP 0 およびオプションで CAP 1。それぞれが 39 個のカートリッジを保持します。 |
CAP 内にロードされている 3 つの取り外し可能なマガジンのそれぞれに、13 個のカートリッジが配置されます。 |
|
SL8500 バルク |
CAP 0 および CAP 1。それぞれが 33 個または 36 個のカートリッジを保持します |
CAP 内にロードされている 3 つの取り外し可能なマガジンのそれぞれに、11 個または 12 個のカートリッジが配置されます。一括 CAPを参照してください。 |
|
SL500 |
CAP 0。5 個から 25 個までのカートリッジを保持します |
CAP 内にロードされている取り外し可能なマガジンに、5 個のカートリッジが配置されます。基本モジュールに 1 つのマガジン。CAP が含まれている拡張モジュールに 2 つのマガジン。 |
|
L180 |
CAP 0、10 個のカートリッジを保持します。 |
CAP 内にロードされている 2 つの取り外し可能なマガジンのそれぞれに、5 個のカートリッジが配置されます。 |
|
L700 |
CAP 0 およびオプションで CAP 1。それぞれが 20 個のカートリッジを保持します。 |
CAP 内にロードされている 4 つの取り外し可能なマガジンのそれぞれに、5 個のカートリッジが配置されます。 |
|
拡張 (4410 および 9310) |
CAP 0 および CAP 1。それぞれが 40 個のカートリッジを保持します。 |
CAP 内にロードされている取り外し可能なマガジンにカートリッジが配置されます。 |
|
9360 |
CAP 0 は 20 個のカートリッジを保持します。オプションの CAP 1 は 30 個のカートリッジを保持します。 |
CAP 内にロードされている取り外し可能なマガジンにカートリッジが配置されます。 |
|
優先 (PCAP) |
CAP 2。1 つのカートリッジを保持します。 |
カートリッジは一度に 1 つずつ、CAP に直接挿入します。 |
|
9710 または 9740 CAP |
CAP 0、14 個のカートリッジ、または 10 個のカートリッジを格納できるマガジンを保持します。 |
カートリッジは、CAP セルに直接ロードするか、CAP 内にロードされている取り外し可能なマガジンに配置します。 |
|
9714、9730、または 9738 CAP |
CAP 0、1 つのカートリッジを保持します |
カートリッジは単一セル CAP に直接ロードされます。 |
|
レガシー 4400 |
CAP。21 個のカートリッジを保持します。 |
カートリッジは CAP のセルに直接ロードされます。 |
CAP の状態は、カートリッジの挿入と取り出しが可能かどうかを決定します。次の表では、有効な CAP の状態について説明します。CAP の状態を決定する手順については、CAP 情報の表示を参照してください。デバイス状態の変更の詳細については、コマンド、query poolを参照してください。
注:
SL8500 ライブラリに関する詳細については、SL8500 内部アドレスと ACSLS アドレスについてを参照してください。SL500 ライブラリに関する詳細については、SL500 CAP の動作を参照してください。| 状態 | 説明 | リクエストを処理する方法 |
|---|---|---|
|
|
正常な動作状態です。 |
すべてのリクエストが受け入れられて、処理されます。 |
|
|
CAP は論理的に無効になっています。 |
すべてのリクエストが拒否されます。 |
|
|
移行状態。CAP がオンラインからオフラインになるときに発生します。 |
すべての新しいリクエストが拒否されます。 現行および保留中のリクエストは、完了するまで処理されます。 |
|
|
CAP はクライアントアプリケーションからの干渉なしで診断アクティビティーに使用できます。 |
クライアントアプリケーションからのリクエストは拒否されます。
|
|
|
移行状態。CAP がオフラインからオンラインになるときに発生します。 |
新しいリクエストは拒否されます。 |
CAP のモードは、カートリッジの挿入と取り出しのための CAP の使用方法を制御します。次の表では、有効な CAP モードについて説明します。CAP のモードを決定する手順については、CAP 情報の表示を参照してください。CAP のモードの変更の詳細については、コマンド、query capを参照してください。
ヒント: CAP のモードは、CAP の使用中は変更できません。つまり、手動または自動のいずれかの挿入操作中にドアが開いている場合は、挿入操作を完了するまでそのモードは変更できません。
| モード | 説明 | 挿入/取り出しへの影響 |
|---|---|---|
|
手動 |
使用中ではないときは CAP はロックされています。これはすべての複数カートリッジ CAP の初期モードです。 |
コマンドを明示的に発行したあとでのみ、カートリッジを挿入したり取り出したりできます。コマンドに cap_id を指定するか、以前に定義した CAP の優先順位に基づいた CAP の自動選択を ACSLS に許可します。 一部のクライアントアプリケーションでは、CAP を手動モードにする必要があります。テープ管理システムのドキュメントを参照してください。 |
|
自動 |
使用中ではないときは CAP はロック解除されています。これはすべての優先順位の CAP の初期モードです。 パーティション分割されたライブラリには、CAP のモードを自動に設定することはできません。この例外は専用の CAP (1 つのパーティションにのみ割り当てられている) であり、SL3000 では自動モードに設定できます。 SL8500 のアクセスドアが開いたり閉じたりするとき、SL8500 は CAP をロックされた状態にします。CAP がロックされている場合、自動モードの挿入には使用できません |
CAP のドアが開いている場合は、すべてのカートリッジを取り外して、ドアを閉じます。 CAP のドアが閉じていて、カートリッジがライブラリに移動中の場合は、残りのカートリッジをライブラリに挿入できるようにする必要があります。そのあと カートリッジを取り出すには、 ACSLS に自動モードの CAP が表示されていても、ロックされていて開かないため自動挿入に使用できない場合: ACSLS と SL8500 を同期してから、CAP を自動挿入に戻します。
|
CAP の優先順位は、CAP リクエストが CAP ID にアスタリスクを指定したときに、ACSLS が CAP を自動的に選択する方法を指定します。次の表では、CAP の優先順位とそれらの結果について説明します。CAP の優先順位を決定する手順については、CAP 情報の表示を参照してください。CAP の優先順位の変更の詳細については、query capを参照してください。
| 優先順位 | 結果 |
|---|---|
|
16 (もっとも高い) |
最初に使用される |
|
15 (次に高い) |
次に使用される |
|
- |
|
|
1 (もっとも低い) |
最後に使用される |
|
0 |
自動的に選択されることはない (すべての CAP の初期の優先順位) |
CAP の優先順位と自動 CAP 選択は、次のコマンドに適用されます。
audit
eject
enter
venter
これらのコマンドを、cap_id のすべてまたは一部にアスタリスク (*) を含めて入力すると、ACSLS は自動的に、リクエストで指定された各 ACS または LSM に対してもっとも高いゼロ以外の優先順位を持つ使用可能な CAP を選択します。
例:
audit * server
ACSLS は各 ACS のもっとも高いゼロ以外の優先順位の CAP を選択します。
enter 0,1,*
ACSLS は LSM 0,1 のもっとも高いゼロ以外の優先順位の CAP を選択します。
カートリッジの挿入を手動にするか自動にするかを選択できます。
カートリッジを手動で挿入するには、enter コマンドを発行する必要があります。これにより CAP のロックが解除されるため、カートリッジを挿入できるようになります。
自動挿入は、自動モードになっている CAP を開くことによって開始されます。CAP が自動モードのときは、挿入コマンドを発行する必要はありません。
次の手順で挿入プロセスについて説明します。
挿入を開始すると、CAP のロックが解除されて予約されます。これは別のホストでは使用できません。
CAP を開いたあと、CAP にカートリッジを配置して、CAP を閉じます。これで、CAP はロックされました。
ACSLS ライブラリロボットが CAP 内のカートリッジを検査/監査します。挿入するすべてのカートリッジに、この ACSLS サーバーによってすでに管理されているほかの vol_ids と重複しない、有効な外部ラベルが付いている必要があります。
注:
仮想挿入では、一部のライブラリ内にラベルのないカートリッジを挿入できます。ACSLS が、有効なカートリッジにライブラリ内のホームセルを割り当て、それらを割り当てられたホームセルの位置に移動します。
重複するカートリッジと外部ラベルなしのカートリッジは CAP 内に残り、削除される必要があります。
完了すると、CAP のロックが解除されるため、追加のカートリッジを挿入できます。
CAP が自動モードの場合は、自動挿入が完了し、CAP の予約が解除されて使用可能になります。
これが手動挿入の場合、CAP は手動挿入用に予約されたままになります。自動挿入を終了するには、cancel コマンドを使用するか、挿入が開始された cmd_proc で Ctrl + c によってキャンセルします。
enter コマンドの追加情報については、enterを参照してください。
注:
カートリッジの追跡が有効になっている場合は、イベントログにすべてのカートリッジの挿入が記録されます。| タスク | コマンド |
|---|---|
|
自動モードでのカートリッジの挿入 |
|
|
手動モードでのカートリッジの挿入 |
|
|
仮想ラベルが付いたカートリッジの挿入 (venter) |
ラベルがない、または読み取れないカートリッジは、ACSLS が管理できないため、LSM のドアを開いてこれらのカートリッジをストレージセル内に配置しないでください。監査中に ACSLS は、ストレージセル内に配置されたラベルがない、または読み取れないカートリッジを取り出します。 |
これらの手順を使用して、現行または保留中の手動挿入または仮想挿入を、終了またはキャンセルします。
cancel コマンドを使用して、進行中の自動挿入操作をキャンセルすることはできません。進行中の自動挿入を終了するには:
CAP のドアが開いている場合は、すべてのカートリッジを取り外して、ドアを閉じます
CAP のドアが閉じていて、カートリッジがライブラリに移動中の場合は、残りのカートリッジをライブラリに挿入できるようにする必要があります。そのあと挿入が終了します。
手動挿入をキャンセルするには:
現行および保留中のすべてのライブラリのアクティビティーを表示します。
query request all
キャンセルしたい enter/venter リクエストの request_id をメモします。
cmd_proc から、次を入力します。
cancel request_id
ここで、request_id はキャンセルしたいリクエストの識別子です。
CAP のロックが解除されるのを待ってから、CAP を開き、すべてのカートリッジを取り外します。
cmd_proc は、キャンセルリクエストが受信される前にライブラリに挿入されたカートリッジの数を示すメッセージを表示します。これらのカートリッジは引き続き ACSLS によって制御されます。
enterを参照してください。
ライブラリからカートリッジを取り出すには、eject コマンドを発行する必要があります。
次の手順で取り出しプロセスについて説明します。
取り出しを開始したあと、CAP はロックされます。これは別のホストでは使用できません。
ロボットが指定されたカートリッジを指定された CAP に配置し、次に ACSLS が、カートリッジが格納されていたセル位置をほかのカートリッジが使用できるようにします。
CAP を開き、CAP からすべてのカートリッジを取り外し、CAP を閉じます。そのあと、ACSLS が CAP を調べて空であることを確認します。これで、CAP が挿入または監査などの別の操作に使用できるようになります。
eject コマンドで CAP いっぱいのカートリッジよりも多く指定する場合は、いっぱいになったときに CAP を空にして CAP を閉じると、すべてのカートリッジが取り出されるまで ACSLS が取り出しプロセスを続行します。
eject コマンドの追加情報については、ejectを参照してください。また、ejecting.shも参照してください。
ボリューム統計の収集が有効になっている場合は、acsss_stats.log にすべてのカートリッジの取り出しが記録されます。一般的な製品動作変数の設定を参照してください。
このセクションでは、CAP の回復について説明します。
一般的な CAP の回復手順を次に示します。
可能な場合は、キャンセルして CAP を回復しようとするのではなく、挿入または取り出しを完了させてください。これにより、複雑さが減り、CAP のハングのリスクが減ります。
CAP いっぱいのカートリッジの挿入を完了してから、キャンセルすることで手動挿入を終了します。(自動モードでは、CAP は一度に 1 つの CAP いっぱいのカートリッジのみを挿入します。)
可能な場合は、取り出しコマンドに指定されたすべてのカートリッジを取り出してください。そうでない場合は、取り出しをキャンセルしようとする前に、いっぱいになった CAP のカートリッジを ACSLS に取り出させて CAP を空にしてください。
CAP を回復するには、強制的にオフラインに変更する必要があります。CAP を強制的にオフラインに変更してからオンラインに戻すことで CAP が回復し、通常は、CAP を使用しているハングした enter または eject も終了します。
CAP を強制的にオフラインに変更します。
vary cap cap_id offline force
現在のロボットのリクエストのみが完了し、そのあとすぐに CAP がオフラインになります。保留中のリクエストは破棄され、新しいリクエストは拒否されます。
ハングした手動 enter または eject は、通常はキャンセルされます。
まだアクティブの場合は、enter または eject リクエストをキャンセルします。
enter または eject リクエストがまだアクティブかどうかを確認するには:
query request all
enter または eject がまだアクティブな場合は、次のコマンドを入力してキャンセルします。
cancel request_id
CAP をオンラインに戻します。
vary cap cap_id online
これにより CAP が回復し、ほかのリクエストに使用できるようになります。
ACSLS は、SL8500 または SL3000 のアクセスドアを開いてから閉じたり、SL8500 または SL3000 を再初期化したりしたあとに、自動挿入モードの CAP のロックを解除するようになりました。
SL8500 または SL3000 ライブラリの再初期化のあとに CAP のロックが解除されて、それを回復する必要がある場合は、次の適切な手順に従って CAP を回復してください。
自動挿入のためにロックが解除されない CAP を回復するには、ACSLS とライブラリ両方の間で CAP の状態を同期する必要があります。
CAP モードを手動に設定して、自動挿入モードを終了します。
set cap mode manual cap_id
CAP を自動モードに設定し直します。
set cap mode automatic cap_id
手動挿入のためにロックが解除されない CAP を回復するには、ACSLS とライブラリ両方の間で CAP の状態を同期する必要があります。
CAP を強制的にオフラインに変更します。
vary cap cap_id offline force
CAP をオンラインに戻します。
vary cap cap_id online
手動挿入を再開します。
enter cap_id
取り出しを行なっていた CAP を回復するには、ロックされた CAP 内に残っているカートリッジを取り外し、ACSLS とライブラリ両方の間で CAP の状態を同期する必要があります。
CAP 内のすべてのカートリッジを取り外します。
CAP を強制的にオフラインに変更 (vary) します。
vary cap cap_id offline force
CAP をオンラインに変更 (vary) します。
vary cap cap_id online
次のいずれかを選択します。
CAP が自動モードになっている場合:
CAP モードを手動に設定して、自動挿入モードを終了します。
set cap mode manual cap_id
CAP を自動モードに設定します。これにより CAP のロックが解除されます。
set cap mode automatic cap_id
CAP を開き、CAP 内に残っているすべてのカートリッジを取り外します。
CAP が自動モードでない場合:
手動 enter を開始します。
enter cap_id
CAP 内に残っているすべてのカートリッジを取り外します。
挿入をキャンセルします。
挿入を待機している cmd_proc で Ctrl + c を使用するか、enter リクエスト ID をキャンセルします。
取り出しを再開します。
enter cap_id vol_id | volrange…
L1400、L700、L700e、または L180 ライブラリで挿入または取り出しに使用する CAP のロックが解除されない場合は、ライブラリで IPL を実行して CAP を回復できます。CAP を回復するには、次の適切な手順に従ってください。
手動挿入のためにロックが解除されない CAP を回復するには:
enter をキャンセル (cancel) します。
挿入が完了するのを待機している cmd_proc で Ctrl + c を使用するか、enter リクエスト ID をキャンセル (cancel) します。
オペレータパネルの「RESET」ボタンを押して、ライブラリを再 IPL します。
ライブラリの初期化が終了したら、別の挿入を開始します。
自動挿入のためにロックが解除されない CAP を回復するには:
CAP モードを手動に設定し直して、自動挿入モードを終了します。
set cap mode manual cap_id
オペレータパネルの「RESET」ボタンを押して、ライブラリを再 IPL します。
ライブラリの初期化が完了したら、CAP を自動モードに設定し直します。
set cap mode automatic cap_id
取り出しのためにロックが解除されない CAP を回復するには (CAP がいっぱいになったあと、またはすべてのボリュームが取り出されたあと):
ライブラリへのアクセスドアを開き、すべてのカートリッジを CAP から取り外して、アクセスドアを閉じます。
オペレータパネルの「RESET」ボタンを押して、ライブラリを再 IPL します。
ライブラリの再 IPL により、ACSLS が取り出しを「ライブラリ障害」で終了します。
オプションで、ライブラリを監査します。
ライブラリの初期化が完了したあとに監査を実行することは良いアイデアですが、必須ではありません。
すべてのカートリッジが取り出されていない場合は、別の取り出しを開始します。
このセクションでは、新しい再アクティブ化されたカートリッジにポリシーを自動的に適用する方法について説明します。
最新のクリーニングカートリッジには、クリーニングカートリッジ専用に予約されているメディアタイプのラベルが付けられています。たとえば、T10000 下位互換のクリーニングカートリッジにはメディアドメインとタイプ「CL」のラベルが付けられ、LTO ユニバーサルクリーニングカートリッジには「CU」のラベルが付けられています。
ACSLS は、これらのメディアドメインとタイプを持つカートリッジがクリーニングカートリッジ専用であると認識するため、監査、挿入、またはカートリッジ回復によってこれらのカートリッジが追加されると、クリーニングカートリッジ属性を自動的に設定します。これには、それらをクリーニングカートリッジとして識別することと、それらの最大クリーニング使用回数を設定することが含まれます。
watch_vols ユーティリティーでは、データベースに追加されたり監査によって再アクティブ化されたりしたカートリッジに、それらが挿入または再挿入されたときにも、自動的に属性を割り当てることができます。ポリシーは vol_attr.dat ファイルに指定され、vol_id または vol_range によって選択されます。このユーティリティーは、自動的に次を実行できます。
vol_id の範囲、または vol_attr.dat ポリシーテーブルにリストされている特定のボリュームに基づいて、ボリュームの所有権を割り当てます。
カートリッジをスクラッチプールに割り当てます。
新しい再アクティブ化されたカートリッジを、特定の LSM に移動します。
カートリッジを論理ライブラリに割り当てます。
詳細については、watch_volsを参照してください。
テープドライブは、読み取り/書き込み記録ヘッドから染み汚れと付着物を取り除くため、定期的にクリーニングする必要があります。ドライブ制御ユニットは、テープが各ドライブを通過する回数を追跡し、ドライブでクリーニングが必要になったときに ACSLS にメッセージを送信します。
クリーニングカートリッジの詳細については、次を参照してください。
ACSLS は、TCP/IP またはシリアル (HLI) 接続のライブラリ (SL8500、SL3000、および 9310) には自動クリーニングを実行できますが、ファイバまたは SCSI 接続のライブラリ (SL150、SL500、および L700) には実行できません。
自動クリーニングが有効になっている場合、ACSLS は必要なときにテープドライブにクリーニングカートリッジを自動的にマウントします。AUTO_CLEAN 動的変数が TRUE (デフォルト) に設定されている場合、自動クリーニングは有効になっています。
最新のテープドライブは、必要に応じてクリーニングをリクエストします。ドライブがライブラリに通知し、それにより ACSLS にメッセージが転送されます。ACSLS は、ドライブをクリーニングする必要があることを記録します。ACSLS がドライブに対する次のマウントリクエストを処理すると、そのあとにマウントとクリーニング操作が行われます。これには、互換性のあるクリーニングカートリッジを選択し、クリーニングカートリッジをマウントし、クリーニングカートリッジをマウント解除してから、元のマウントリクエストに指定されているデータカートリッジのマウントに進むことが含まれます。
ACSLS は、クリーニング操作中に使用済み (使い果たされた) クリーニングカートリッジのマウントなどの回復可能な問題が発生した場合は、別のクリーニングカートリッジを選択してクリーニング操作を再試行します。AUTO_CLEAN_RETRY_LIMIT 動的変数は再試行の回数 (デフォルトの 1 回の再試行と 0-5 回の再試行) を制御します。この変数を表示および変更するには、acsss_config を使用して「General Product Behavior Variables」を選択します。
UNIFORM_CLEAN_USE 動的変数は、クリーニングカートリッジの選択に使用する方法を定義します。オプションは次のとおりです。
VOLID_SORT – vol_id の順。次を使用する前に 1 つのクリーナーを使い果たします。
LEAST_USED – 使用回数の順。使用回数を均等に分散します。
MOST_CAPACITY – 残りの使用回数の順。すべてのクリーナーを同時に使い果たします。
デフォルトは VOLID_SORT です。この変数を表示および変更するには、acsss_config を使用して「General Product Behavior Variables」を選択します。
ACSLS による自動クリーニングの詳細については、次を参照してください。
CSI チューニング変数の設定の「AUTO_CLEAN」
CSI チューニング変数の設定の「AUTO_CLEAN_RETRY_LIMIT」。
さまざまなクリーニングカートリッジタイプのそれぞれには、使い果たされた (期限切れまたは使用済みである) ことがドライブから報告されるまでの最大使用回数があります。この最大使用回数は、クリーニングカートリッジのタイプに応じて異なります。ACSLS がクリーニングカートリッジを追加すると、カートリッジの最大使用回数が ACSLS データベースに記録されます。ACSLS は、クリーニングの access_count (カートリッジのマウントなどが行われた回数) が max 使用回数より少ない場合のみ、自動クリーニング用のクリーニングカートリッジを選択します。テープドライブからクリーニングカートリッジが使い果たされた (使用済みである) ことが報告されると、ACSLS は max 使用回数より多いアクセス数を設定します。
ACSLS がクリーニングカートリッジに自動的に設定する最大使用回数は、カートリッジがサポートする実際のクリーニング使用回数より大きい数です。これは、一部のアプリケーションが、ドライブがクリーニングをリクエストしていなくても、クリーニングカートリッジのマウントをスケジュールするためです。ドライブでクリーニングの準備ができていない場合は、ヘッドが早く摩耗してしまわないように「擬似クリーニング」を行うことがあります。これは、ドライブのアクセス数が、実際にはクリーニングカートリッジを使用しなくても増分されていることを意味します。max 使用回数の値をより大きくすると、ドライブから使用済みと報告されるまで、これらのカートリッジを使用できます。
set clean コマンドを使用して、クリーニングカートリッジを定義し、その最大使用回数を設定できます。
set clean max_usage vol_id | volrange
ここでは:
max_usage は、ACSLS がカートリッジをクリーニングするカートリッジの選択を停止するまでにクリーニングカートリッジが使用される回数です。
vol_id | volrange は、クリーニングカートリッジまたはカートリッジの範囲を指定します。
set clean を使用して次を実行します。
クリーニングカートリッジの最大使用回数を変更します。
たとえば、クリーニングの必要がなかったドライブにクリーニングカートリッジが手動でマウントされ、access_count が増分しましたが、行われたのは「擬似クリーニング」だけでした。クリーニングカートリッジから最大の使用回数を得るには、より大きい max_usage を設定してください。
set clean max_usage vol_id|volrange
カートリッジのクリーニングカートリッジ属性をオフに設定します。たとえば、誤ってデータカートリッジをクリーニングカートリッジとして定義した場合は、カートリッジのクリーニングカートリッジ属性をオフに設定して、カートリッジをデータカートリッジとして再定義します。
set clean off vol_id|volrange
使用済みのクリーニングカートリッジを取り出して、ライブラリ内のクリーニングカートリッジをモニタリングする必要があります。必要に応じて新しいクリーニングカートリッジを挿入します。
すべてのクリーニングカートリッジを表示するには:
query clean all
ACS 内の 1 つの media_type のすべてのクリーニングカートリッジを表示するには、display コマンドを使用します。
display volume * -home acs,*,*,*,* -media media_type
カートリッジの最大クリーニング使用回数と現在の使用回数を表示するには:
display volume * -home acs,*,*,*,* -media media_type –f vol_id acs lsm media max_use access_count
ACS 内のすべてのクリーニングカートリッジを、その最大クリーニング使用回数および現在の使用回数とともに表示するには:
display volume CLN* -home acs,*,*,*,* -f acs lsm type media max_use access_count
使用済みのすべてのクリーニングカートリッジを表示するには (これらのカートリッジは、取り出して新しいクリーニングカートリッジと交換する必要があります):
display volume * -spent_clean
関連項目:
クリーニングカートリッジを挿入するときは、必ず次の手順を完了してください。
メディアタイプがライブラリ内のドライブタイプと互換性のあるクリーニングカートリッジを使用してください。ACSLS が自動的に、クリーニング操作ごとに正しいタイプのカートリッジを選択します。
ドライブタイプと互換性のあるクリーニングカートリッジを確認するには、「ACSLS 製品情報」マニュアルのドライブとメディアの互換性の表を参照するか、drive_media.sh ユーティリティーを使用してください。
ライブラリ内のドライブタイプごとに、少なくとも 2、3 のクリーニングカートリッジを定義してください。ほとんどの場所では、少なくとも 4 つのドライブごとに 1 つのクリーニングカートリッジが適切です。
ACSLS にクリーニングカートリッジを定義するには:
CAP の挿入を準備します。
詳細については、カートリッジの挿入を参照してください。
クリーニングカートリッジを挿入します。
cmd_proc は、挿入したカートリッジのカートリッジ ID を含むメッセージを表示します。
クリーニングカートリッジ属性の自動割り当てで説明しているように、ACSLS はクリーニングカートリッジを、それらが監査、挿入、またはカートリッジ回復によって挿入または追加されたときに自動的に定義します。これにはそれらの最大使用回数が含まれます。
ACSLS は、クリーニングカートリッジがその最大使用回数に達したとき、またはドライブからクリーニングカートリッジが使用済みであると報告されたときに、イベントログにメッセージを記録します。ACSLS はカートリッジをライブラリ内に残しますが、それをクリーニング用には選択しなくなります。使用済みのクリーニングカートリッジを取り出して、交換品を挿入します。
使用済みのクリーニングカートリッジを取り出すには:
query clean および display volume を使用して、最大使用回数を超えた、または使用済みのクリーニングカートリッジを識別します。
query clean all
display volume * -spent_clean
クリーニングカートリッジを取り出します。
eject cap_id vol_id | volrange
ここでは:
cap_id は、クリーニングカートリッジを取り出すために使用される CAP を指定します。
vol_id | volrange は、取り出すクリーニングカートリッジの ID を指定します。
使用済みのクリーニングカートリッジを取り外します。
クリーニングカートリッジのモニタリングを参照してください
自動クリーニングが無効になっているとき、または動作していないときにドライブをクリーニングするには、この手順を使用します。
ドライブを手動でクリーニングするには:
クリーニングするドライブと互換性のあるクリーニングカートリッジタイプを確認します。
各ドライブタイプのクリーニングカートリッジのリストについては、「製品情報ガイド」を参照し、「ドライブとメディアの互換性」の表を調べてください。
使用可能なクリーニングカートリッジを表示します。
query clean all
ドライブと同じ ACS 内の互換性のあるすべてのクリーニングカートリッジを表示するには、display コマンドを使用します。
display volume * -home acs,*,*,*,* -media media_type
カートリッジの最大クリーニング使用回数と現在の使用回数を表示するには:
display volume * -home acs,*,*,*,* -media media_type -f vol_id acs lsm media max_use access_count
ACS 内のすべてのクリーニングカートリッジを、それらの最大クリーニング使用回数および現在の使用回数とともに表示するには:
display volume CLN* -home acs,*,*,*,* -f acs lsm type media max_use access_count
それらのリストにあるものから互換性のあるクリーニングカートリッジを選択し、ドライブにマウントします。
mount vol_id drive_id
ドライブがクリーニングされ、クリーニングカートリッジがアンロードされたあと、クリーニングカートリッジをマウント解除します。
dismount vol_id drive_id
ACSLS 自動クリーニングは、ファイバ接続ライブラリ内のドライブではサポートされていません。これらのドライブは、クリーニングカートリッジを手動でマウントすることによってのみ、ACSLS を使用してクリーニングできます。ただし、ファイバ接続ライブラリでは、ライブラリ GUI を使用して自動クリーニングを有効にできます。詳細については、ライブラリのドキュメントを参照してください。
次に、ドライブがクリーニングされていないときに試すいくつかのトラブルシューティングのヒントを示します。
自動クリーニングが無効になっている場合は、ドライブにクリーニングが必要になると ACSLS がイベントログにメッセージを記録して、cmd_proc でクリーニングメッセージを表示します。クリーニングカートリッジを手動でマウントする必要があります。
自動クリーニングを有効または無効にするには、acsss_config を使用します。さらに、acsss_config を使用すると、選択または照会のためのクリーニングカートリッジの順序付けの方法を指定できます。
AUTO_CLEAN 動的変数がデフォルト設定である TRUE (オン) に設定されている場合、自動クリーニングは有効になっています。AUTO-CLEAN を確認するには、次を入力します。
dv_config -e AUTO_CLEAN
ファイバ接続ライブラリの場合、ACSLS は自動クリーニングを実行しません。
すべてのクリーニングカートリッジが期限切れになっている (max_usage 値を超えている)、またはドライブから使用済みと報告されている場合、ACSLS はドライブをクリーニングせずに元のマウントリクエストを実行します。そのマウントと、クリーニングされていないドライブへの以降の各マウントについて、ACSLS がイベントログにメッセージ 376 N 「Drive drive_id: No Cleaning cartridge available」をポストします。クリーニングカートリッジの手動の定義の説明に従って、ドライブタイプと互換性のあるクリーニングカートリッジをさらに追加します。
ドライブがクリーニングされていない場合は、ライブラリ内にそのドライブ用のクリーニングカートリッジがあることと使用回数がまだ残っていることを確認してください。
cmd_proc から、display コマンドを使用して次を表示できます。
すべてのクリーニングカートリッジとそれらの使用回数:
display volume * -clean -f media access_count max_use
特定のメディアタイプのすべてのボリューム。
たとえば、すべての LTO クリーニングカートリッジを表示するには:
display volume * -media LTO-CLNU -f access_count max_use
使い果たされた (使用済みの) すべてのクリーニングカートリッジとそれらの使用回数:
display volume * -spent_clean -f media access_count max_use
SL8500 または SL3000 の自動クリーニングが動作しない問題が発生したことがある場合は、SL コンソールを使用して自動クリーニングがライブラリに対して有効になっていないことを確認してください。
ACSLS を使用して自動クリーニングを有効にすると、マウント解除後にライブラリから「drive needs cleaning」というメッセージを受信したときに、次のマウントの前にクリーニングカートリッジが自動的にマウントされます。
SL コンソールを使用してライブラリレベルで自動クリーニングを有効にしている場合は、ライブラリによって自動クリーニングが行われます。ライブラリ自動クリーニングが有効になっている場合、ライブラリは ACSLS に drive needs cleaning メッセージを送信しません。ACSLS はドライブをクリーニングする必要があることを認識できません。そのあと、ACSLS がマウント解除応答を送信する前にドライブをクリーニングするために、ライブラリがそのシステムセルのいずれかからクリーニングカートリッジをマウントしようとします。
結果として、ライブラリが自動クリーニングを実行しようとしていても、システムセルにはクリーニングカートリッジがないという混乱が生じることがあります。ACSLS が通常のストレージセルのクリーニングカートリッジを管理することはありますが、ACSLS は「drive needs cleaning」メッセージを受信しません。その結果、ドライブはクリーニングされません。
これを解決するには:
ACSLS で自動化されたクリーニングが有効になっていても、ドライブがクリーニングされていない場合は、ライブラリでも自動クリーニングが有効になっているかどうかを確認してください。
ライブラリで自動クリーニングが有効になっている場合は、SL コンソールを使用して無効にしてください。
SL コンソールまたはライブラリオペレータパネルを使用します。
「System Detail」タブを選択します。
「Library」を選択します。
「Auto Clean」タブを選択します。
「Configure」タブを選択します。
自動クリーニングがこのパーティション (または「Partition 1 or None」) に対して有効になっているかどうかチェックします。
自動クリーニングが有効になっている場合は、無効にします。
自動クリーニングは、障害のあるクリーニングカートリッジが繰り返し選択されないよう、問題のあるカートリッジを選択しません。カートリッジに読み取り不能なラベルがあることがライブラリから報告されると、カートリッジに questionable とマークされます。
display コマンドを使用して、questionable とマークされたクリーニングカートリッジを特定できます。これにより、クリーニングカートリッジの ACS、LSM、タイプ、max_use、および access_count も表示されます。
display volume CLN* -f media_status acs lsm media_status type max_use access_count
questionable のステータスをクリアするには:
カートリッジを取り出して検査し、問題がない場合はライブラリに再度挿入します。
カートリッジを挿入すると、questionable のステータスがクリアされます。
スクラッチカートリッジには、データが含まれていないか、上書きできるデータが含まれています。ユーザーまたはアプリケーションがスクラッチカートリッジをマウントして、そのカートリッジに新しいデータを書き込みます。
スクラッチステータスを割り当てるには:
カートリッジは、スクラッチカートリッジとして定義して、set scratch コマンドによってスクラッチプールに割り当てることができます。
watch_vols ユーティリティーは、カートリッジの vol_id または volrange に基づいて、カートリッジを自動的にスクラッチプールに割り当てることができます。watch_volsを参照してください。
ボリュームスクラッチステータスのクリア:
カートリッジのスクラッチステータスは、(mount scratch または normal mount リクエストのいずれかによって) カートリッジが正常にマウントされたときにクリアされます。
注:
set scratch コマンドを使用して、スクラッチステータスをクリアできます。ボリュームのスクラッチステータスはボリュームがマウントされたときにクリアされますが、pool id はクリアされません。その結果、データボリュームがプールに割り当てられます。set scratch コマンドは、次を使用してスクラッチプールにデータボリュームを割り当てるためにも使用できます。
set scratch off pool_id vol_id | volrange
ライブラリにスクラッチマウントリクエストを満たすために使用できる十分なスクラッチカートリッジがあることを確認する必要があります。詳細については、次を参照してください。
次のセクションでは、スクラッチカートリッジとスクラッチプールの管理についての追加情報を提供します。
スクラッチプール情報を表示するには、次の ACSLS 関数を使用します。
query pool
スクラッチプールの属性を表示します。query poolを参照してください。
query scratch
スクラッチカートリッジの情報を表示します。query scratchを参照してください。
query mount *
指定したスクラッチプール (および、オプションでプール内の特定のカートリッジメディアタイプ) のメディア互換カートリッジのステータスを表示します。query mount *を参照してください。
カスタマイズされたボリュームレポート
選択されたスクラッチボリューム情報をレポートします。ロギングボリューム統計レポートの作成を参照してください。
スクラッチカートリッジをライブラリに追加するには、この手順を使用します。
ライブラリにスクラッチカートリッジを追加するには:
必要に応じて、新しいスクラッチプールを作成します。
詳細については、query scratchを参照してください。
スクラッチカートリッジをライブラリに挿入します。
詳細については、カートリッジの挿入を参照してください。
手順 2 で挿入したカートリッジをスクラッチカートリッジとして定義し、それらをスクラッチプールに割り当てます。
これは、watch_vols ユーティリティーの vol_attr.dat に定義されているポリシーを使用して、または set scratch を使用して実行できます。
スクラッチカートリッジをプール間で移動することによってスクラッチプールをリバランスするには、この手順を使用します。
スクラッチプールをリバランスするには:
すべてのスクラッチプールの属性を表示します。
query pool all
詳細については、query poolを参照してください
リバランスするプール内のスクラッチカートリッジの ID を表示するには、query scratch コマンドを使用します。
詳細については、query scratchを参照してください
スクラッチカートリッジをプール間で移動するには、set scratch コマンドを使用します。
たとえば、カートリッジ YUMA20 から YUMA80 (現時点ではプール 5 からプール 10 に存在します) を再割り当てするには、次を入力します。
set scratch 10 YUMA20-YUMA80
詳細については、set scratchを参照してください。
スクラッチプールを管理するために、スクラッチカートリッジがもう含まれていないすべてのスクラッチプールを削除する場合があります。共通プール (プール 0) を削除することはできません。削除できるのは空のスクラッチプールのみであることに注意してください。データまたはスクラッチカートリッジのいずれかが含まれている場合、スクラッチプールは削除できません。ただし、すべての空のプールの削除を使用して、すべての空のプールを削除できます (ACSLS はスクラッチまたはデータカートリッジが含まれているプールを削除しません)。
スクラッチプールを削除する前に空にするには、この手順を使用します。
スクラッチプールを空にするには:
データカートリッジをプールの外に移動するには、次を入力します。
set scratch off 0 vol_id volrange ...
ここで、 vol_id または volrange は、共通プール (プール 0) に移動するデータカートリッジを指定します。詳細については、set scratchを参照してください。
スクラッチカートリッジをプールの外に移動するには、次のいずれかを実行します。
カートリッジを別のプールに移動します。
カートリッジの取り出しを参照してください。ただし、スクラッチカートリッジを取り出すと、ACSLS はこれらのカートリッジを管理しなくなります。あとでこれらのカートリッジを使用する場合は、それらを再挿入し、スクラッチプールに割り当てる必要があります。
delete pool all コマンドは、スクラッチまたはデータカートリッジを含むプールではなく、空のスクラッチプールのみを削除します。
すべての空のプールを削除するには:
delete pool all
mount scratch (cmd_proc を使用した mount *) コマンドは、指定されたドライブと互換性があり、できるだけ近くにあるスクラッチカートリッジを選択し、それをドライブにマウントします。プールが指定されている場合、スクラッチカートリッジはそのプールに割り当てる必要があります。
ホームセル内または別の回復エラーでスクラッチカートリッジが見つからないために、スクラッチカートリッジのマウントが失敗した場合、ACSLS は自動的に別のスクラッチカートリッジを選択しようとしてマウントを再試行します。
スクラッチカートリッジのマウントごとのボリュームアクセス制御ポリシーを設定でき、それをマウントした ACSAPI ユーザーによって自動的に所有されます。ボリュームの所有権の確立を参照してください。
単一メディア環境と混合メディア環境でスクラッチカートリッジをマウントするには、次の手順を使用します。
指定されたプールからカートリッジをマウントするには:
mount * drive_id pool_id
指定されたプールから使用できるカートリッジがなく、プールが「overflow」に設定されていた場合、ACSLS は共通プール (プール 0) からカートリッジを選択します。
共通プールからカートリッジをマウントするには:
mount * drive_id
指定したプールから指定したメディアタイプのスクラッチカートリッジをマウントするには:
mount * drive_id pool_id media media_type
指定されたプールから使用できるカートリッジがなく、プールが overflow に設定されていた場合、ACSLS は共通プール (プール 0) から指定されたメディアタイプのカートリッジを選択します。
スクラッチ優先順位で決定されたメディアタイプを持つ指定されたプールからスクラッチカートリッジをマウントするには:
mount * drive_id pool_id media *
指定されたプールから使用できるカートリッジがなく、プールが overflow に設定されていた場合、ACSLS は、定義されているスクラッチ優先順位に従って、共通プール (プール 0) からカートリッジを選択します。
指定されたメディアタイプの共通プールからカートリッジをマウントするには:
mount * drive_id media media_type
スクラッチ優先順位で決定されたメディアタイプを持つ共通プールからカートリッジをマウントするには:
mount * drive_id media *
スクラッチカートリッジは、マウント時のデータカートリッジステータスに自動的に再割り当てされます。
エラーでスクラッチされたカートリッジを「スクラッチ解除」する (それらをデータカートリッジステータスに戻す) には、この手順を使用します。
カートリッジをスクラッチ解除するには:
query pool および query scratch コマンドを使用して、スクラッチ解除するカートリッジのカートリッジおよびプール ID を表示します。
詳細については、query poolおよびquery scratchを参照してください。
選択されたカートリッジをスクラッチ解除するには、次を入力します。
set scratch off 0 vol_id volrange ...
ここで、vol_id または volrange は、スクラッチモードから変更して共通プール (プール 0) に移動するカートリッジを指定します。詳細については、set scratchを参照してください。
ACSLS での不在カートリッジのサポートは、ライブラリ内で見つからないカートリッジを削除するのではなく、それらに不在とマークします。これらのカートリッジがあとでライブラリ内で見つかると、ACSLS は、それらをデータベースに再度追加するのではなく、それらをアクティブステータスに変更します。再アクティブ化により、アクセス数と、プール、ボリュームアクセス制御所有権、ロックなどの設定が保持されます。
同様に、取り出し済みカートリッジのサポートは、カートリッジが取り出されたときのカートリッジ情報を保持します。カートリッジは再挿入されたときに再アクティブ化されます。
不在ボリュームと取り出し済みボリュームのサポートは、ABSENT_VOLUME_RETENTION_PERIOD がゼロ以外の日数に設定されているときに有効になっています。デフォルト値は 5 日です。
不在カートリッジと取り出し済みカートリッジのサポートのその他の面として、次が含まれます。
手動ボリューム削除 (del_vol) ユーティリティーは、-d オプションが指定されていないかぎり、ボリュームを不在として保持します。このオプションが指定されている場合、ボリュームは、不在または取り出し済みというステータスの期限切れを待たずに削除されます。
ACSLS は、SL3000 および SL8500 ライブラリで失われたカートリッジの場所を照会します。
ACSLS は、ライブラリ内の予期された場所で見つからないボリュームを検索することで、ボリュームの回復を向上させます。ACSLS は、ボリュームを自動的に削除する代わりに、記録されたすべての場所を検索します。
クライアントは、ENABLE_STATUS_VOLUME_ABSENT および ENABLE_STATUS_VOLUME_MISSING 構成設定を使用して、それらが不在、取り出し済み、および見つからないというステータスとして ACSAPI を介して報告されるかを指定できます。
-i オプションを指定した volrpt ユーティリティーは、不在または取り出し済みというステータスのボリュームレコードを報告します。デフォルトでは、volrpt は不在または取り出し済みボリュームを報告しません。
ACSLS は 3 つのカートリッジ (ボリューム) のステータスを報告します。
missing
LSM がオフラインになっているかドライブが通信中ではないため、カートリッジがライブラリ内で見つからず、カートリッジの記録された少なくとも 1 つの場所を検索できません。カートリッジに関する情報は保持されています。
absent
カートリッジがライブラリ内で見つかりません。カートリッジの記録されたすべての場所は検索済みで、それらのどこにもカートリッジがありません。カートリッジに関する情報は保持されています。(保持期間が期限切れになる前に) カートリッジが見つかった、またはライブラリに再挿入された場合、再アクティブ化されます。
ejected
カートリッジは取り出し済みです。カートリッジに関する情報は保持されていて、(保持期間が期限切れになる前に) 見つかった、または再挿入された場合、カートリッジは再アクティブ化されます。
ACSLS は、 ACSLS コマンドに応答してステータスが「missing」、「absent」、または「ejected」のカートリッジ (ボリューム) を報告し、これは ACSAPI リクエストに応答した場合とは異なります。
ACSLS コマンドに応答して表示される情報は、カートリッジを「missing」、「absent」、または「ejected」として識別します。
ただし、ACSLS が ACSAPI リクエストに応答して表示するカートリッジのステータス情報は、次の ACSLS 動的変数によって制御されます。
missing
ACSLS 動的変数 ENABLE_STATUS_VOLUME_MISSING が TRUE の場合、ACSLS は STATUS_VOLUME_MISSING を報告します。
ACSLS 動的変数 ENABLE_STATUS_VOLUME_MISSING が FALSE の場合、ACSLS は STATUS_VOLUME_IN_TRANSIT を報告します。
absent
ACSLS 動的変数 ENABLE_STATUS_VOLUME_ABSENT が TRUE の場合、ACSLS は STATUS_VOLUME_ABSENT を報告します
ACSLS 動的変数 ENABLE_STATUS_VOLUME_ABSENT が FALSE の場合、ACSLS はボリュームを ACSLS データベースから削除されているかのように扱い、STATUS_VOLUME_NOT_IN_LIBRARY を報告します。
ejected
ACSLS 動的変数 ENABLE_STATUS_VOLUME_EJECTED が TRUE の場合、ACSLS は STATUS_VOLUME_EJECTED を報告します
ACSLS 動的変数 ENABLE_STATUS_VOLUME_EJECTED が FALSE の場合、ACSLS はボリュームを ACSLS データベースから削除されているかのように扱い、STATUS_VOLUME_NOT_IN_LIBRARY を報告します。
ABSENT_VOLUME_RETENTION_PERIOD 動的変数”
ABSENT_VOLUME_RETENTION_PERIOD 動的変数は、不在ボリュームと取り出し済みボリュームが ACSLS データベースに保持される時間を制御し、これらのボリュームが保持される日数を指定します。2 つの特殊な値があります。
値 0 (ゼロ) 日は、ボリュームが削除され、不在または取り出し済みとマークされないことを指定します。(これは ACSLS 6.1 より前の ACSLS リリースの動作です。)
値 999 日は、不在ボリュームと取り出し済みボリュームがデータベースにいつまでも保持されることを指定します。
カートリッジ回復 (acscr) は ACSLS 内部プロセスで、ストレージセルまたはテープドライブの実際の内容が ACSLS データベースに保存されている情報と一致しない場合は常に、不一致を解決するために呼び出されます。これは次によって行われます。
ライブラリで、ボリュームのホームセルと、場合によってはドライブを調べられるようにします。そのあと、その結果で ACSLS データベースを更新します。
ACSLS (SL3000 および SL8500 ライブラリを含む) で、カートリッジが置かれているライブラリを確認してから、ライブラリの応答を使用して ACSLS データベースを更新することで、カートリッジを回復できるようにします。
カートリッジ回復で、別の場所に記録されているカートリッジなどの不一致が見つかった場合は、別の回復リクエストが作成され、それがリクエストキューに追加されます。(これは「カスケード」と呼ばれます。)
その他のプロセスは、ACSLS データベースとライブラリの実際の内容の間に不一致が発生したときに、カートリッジ回復に回復リクエストを渡します。そのため、カートリッジ回復は、カートリッジに見つからないとマークされたり、不在に変更されたり、再アクティブ化されたりする、中心となる場所です。したがって、ほかの多くの ACSLS コマンドおよびユーティリティーの動作のように見える動作は、実際には、ライブラリによって報告された情報に一致するようにデータベースを更新するときにカートリッジ回復によって行われます。
ほかのプロセスがカートリッジ回復に回復リクエストを渡すときは、次のことができます。
続行し、非同期でカートリッジ回復を続行させます (カートリッジ回復は独立して進行します)。
失われた特定のカートリッジが必要な場合は、カートリッジ回復がこの回復リクエストの処理を終了するのを待ってから、見つかったものを報告してください。
次の場合、カートリッジは見つからないとしてマークされます。
カートリッジ回復でライブラリ内のカートリッジが見つかりません。
カートリッジのすべての記録された位置 (カートリッジに 1 つのドライブ位置が記録されている場合は、ホームセルとドライブ) を調べることができません。
たとえば、カートリッジ回復がオフラインの LSM またはオフラインのドライブのホームセルを調べることができない場合と、ほかの場所にあるカートリッジを探さない場合は、カートリッジに見つからないとしてマークされます。
カートリッジ回復は、カートリッジのホームセルを調べて、そこで別のカートリッジが見つからないかぎり、カートリッジのホーム位置を維持します。この場合、カートリッジには「homeless」とマークされ、home_lsm フィールドにマイナス 1 (-1) が入ります。
カートリッジ回復が見つからなかったカートリッジを見つけると、見つからなかったカートリッジが見つかった場所に応じて、そのカートリッジのステータスがデータベース内で「home」または「in drive」に変更されます。
カートリッジが記録されたホームセル以外のセル内で見つかった場合、カートリッジ回復はカートリッジのホームセルをチェックして、重複したカートリッジが見つかったかどうかを確認します。
カートリッジが記録されたホームセル内にない場合、カートリッジ回復は、それが見つかったセルをその新しいホームセルとして記録します。
新しいカートリッジが重複している場合、カートリッジ回復はイベントログにこれを報告します。重複するカートリッジは取り出されません。
カートリッジ回復は、ドライブで「homeless」カートリッジを見つけた場合は、新しいホームセルを割り当てません。カートリッジがマウント解除されるときに、マウント解除プロセスで新しいホームセルが割り当てられます。
このセクションでは、不在カートリッジと取り出し済みカートリッジについて説明します。
カートリッジ回復が記録されたすべての場所を調べることができ、カートリッジを見つけることができない場合:
ABSENT_CARTRIDGE_RETENTION_PERIOD が 0 の場合、カートリッジ回復は、
カートリッジのレコードをデータベースから削除します。
カートリッジのホームセルだったセルのデータベース内のセルレコードに、「empty」とマークします。
ABSENT_CARTRIDGE_RETENTION_PERIOD が 0 より大きい場合、カートリッジ回復は、
まだカートリッジに不在か取り出し済みとマークされていない場合は、データベース内のカートリッジのレコードのステータスを「absent」に変更します。
カートリッジを「homeless」として記録します (home_lsm フィールドにマイナス 1 (-1) が入ります)。
カートリッジの以前のホームセルのデータベース内のセルレコードに「empty」とマークします。
手動ボリューム削除ユーティリティー、del_vol により、オフラインになっていて使用できない LSM 内にあるボリュームにアクセスできます。カートリッジを手動で LSM から取り出して、別の LSM に再挿入しようとすると、ACSLS は duplicate volume メッセージを発行し、カートリッジを挿入しません。del_vol ユーティリティーを使用すると、最初にデータベースからボリュームを削除してから、オフラインの LSM から手動で取り外して、オンラインの LSM 内に正常に再挿入できます。
del_vol ユーティリティーは、ボリュームを削除するためのオプションを使用して、ボリュームを不在として保持するようになりました。ボリュームは、不在または取り出し済みというステータスの期限切れを待たずに削除できます。
注:
オンライン LSM からカートリッジを取り外すには、カートリッジに対してeject コマンドを発行します。カートリッジが実際には LSM 内にない場合は、-f (force オプション) を指定して del_vol を実行できます。このユーティリティーを使用するには、ACSLS とデータベースが稼働している必要があります。システムの回復中は del_vol を実行しないでください。予期しない結果が発生する可能性があります。このユーティリティーの詳細については、del_volを参照してください。
del_vol ユーティリティーを使用してカートリッジを削除するには:
acsss としてログインします。
カートリッジを削除します。
del_vol vol_id
テープカートリッジがその設計寿命を超えると、メディアが擦り切れて、カートリッジのゲートのような機械部品が摩耗することがあります。カートリッジが設計された寿命の終わりに達したときは、それらのデータを新しいカートリッジに移行して、古いカートリッジを廃棄することを検討してください。これにより、カートリッジの機械の部品が故障したりデータが読み取り不可になったりするわずかなリスクを回避できます。
カートリッジの時系列経過時間と使用時間は異なります。いくつかの 9840 カートリッジが 10 年間使用され続けていても、それらの使用パターンは異なります。毎日使用されていたものもあれば、規模の大きいアーカイブに使用され、まれにしかアクセスされないものもあります。設計寿命を越えたカートリッジを特定することは、きわめて重要です。
廃棄する必要のあるカートリッジを特定するには、それらの使用状況を確認する必要があります。カートリッジの使用状況はカートリッジのディレクトリに記録され、カートリッジがマウント解除される前に、ドライブがディレクトリを更新します。
ACSLS によって制御されるライブラリ内のカートリッジの場合:
ACSLS が管理する一部のライブラリの場合、カートリッジの使用状況は「保証期限」と「寿命」のパーセンテージとして表示されます。
ACSLS の以前のリリースとライブラリの場合は、display コマンドと volrpt ユーティリティーを使用して ACSLS access_count を表示できます。
最新のファームウェアを実行中の最新のライブラリと、最新のファームウェアを実行中の StorageTek ドライブでは、カートリッジがマウント解除されるときに、テープドライブからライブラリにカートリッジの「保証期限」と「寿命のパーセンテージ」が報告されます。そのあと、ライブラリがこれを ACSLS に報告します。ACSLS はこの情報をそのデータベースに保存するため、ACSLS の display volume コマンドを実行することでそれを表示できます。display コマンドオプションの使用を参照してください。
例: すべての T9840 カートリッジを end_of_life でソートして、ACS、LSM、メディア、および end_of_life 情報とともに表示するには:
display volume * -media STK1R -f acs lsm media end_of_life warranty_life -s end_of_life
具体的には、これらのライブラリとドライブについて、この情報が ACSLS に報告されます。
ライブラリ:
SL3000
SL8500 (4.10 ファームウェア)
テープドライブ:
すべての T10000 テープドライブ - 1.38 ファームウェア
T9840A、T9840C、および T9840D (T9840B を除くすべての T9840 テープドライブ。) – 1.42 ファームウェア
T9940A および T9940B テープドライブ – 1.42 ファームウェア
多くの場合、カートリッジ寿命のレポートは使用可能ではありません。このような場合は、ACSLS access_count が使用可能な最良の情報です。ACSLS データベースは、ボリュームが選択またはアクセスされた回数を記録します。これは、カートリッジが接続されたライブラリのグループ (ACS 内) に置かれたままだった場合に、それらがマウントされた回数を推定するために使用できます。
この情報はライブラリのタイプに関係なく収集されるため、9310、4410、および 9360、さらに SL8500 と SL3000 についても維持されます。ACSLS はこの情報を 10 年間保存しているため、まだ下位レベルのリリースを使用している場合でも、この情報は引き続き存在しています。ただし、このデータには制限があります。もっとも大きいのは、カートリッジがライブラリに挿入されたときにカウントがゼロ (0) に設定されることです。
設定されている保持期間のボリュームについての情報が保持されるため、カートリッジが ACS から取り出され、保持期間内に同じまたは別の ACS に再挿入されたときに、カウントが保存されます。デフォルトの保持期間は 5 日です。ただし、ボリュームがライブラリから取り出され、ボリューム情報の保持期間よりも長くオフサイトに置かれたままの場合、ボリュームに関する情報は ACSLS データベースから削除されます。
単一のライブラリ内に残されていたカートリッジの場合、これらの ACSLS アクセス数は非常に役立ちます。T9840 カートリッジの場合は、ACSLS access_count が 11,000 を超えている場合、問題のカートリッジがまだ寿命を過ぎていない場合は寿命に近づいています。T10000 カートリッジの寿命の値は 16,000 マウントです。
ACSLS は新しいリリースの ACSLS がインストールされたときにデータベース情報を保持および移行できるツールを提供しているため、この情報は 10 年以上遡って存在できます。カートリッジからのデータが存在しない場合は、これが唯一のオプションです。
この ACSLS フィールドは access_count と呼ばれます。これは次をカウントします。
マウント (マウント解除はカウントされません)
挿入と取り出し (多くの場合、挿入と取り出しはまれにしかありません)
移動 (ただし、cmd_proc を使用した move コマンドはまれにしか使用されず、ACSAPI クライアントでは使用できません)
access_count は、主にカートリッジがマウントされた回数のカウントです。ACSLS は取り出し済みボリュームを ABSENT_VOLUME_RETENTION_PERIOD (デフォルトは 5 日) の間記憶します。カートリッジが ACS 間で移動し、オフサイトに送られてからオンサイトに戻るときに、ACSLS が access_count を記憶できます。
次の両方を使用して、ACSLS access_count を参照できます。
ACSLS display コマンド。
アクセス数でソートされたすべての 9840 データカートリッジを表示し、メディアタイプ、ACS、および LSM も表示するには:
display volume * -media STK1R -s access_count -f media access_count acs lsm
volrpt ユーティリティー。
volrpt は使用回数 (access_count) でソートでき、選択されたフィールドのみを含めることができます。たとえば、vol_id、media type、access_count、および location が含まれているカスタムの volrpt は、スクリプトによってさらに処理できるようにフラットファイルに出力できます。
ACSLS はテープドライブからカートリッジをマウント解除するときに、ほかの LSM からテープドライブと同じ LSM 内の新しいホームセルに移動したカートリッジを「フロート」することで、パススルーを回避しようとします。
たとえば、カートリッジが SL8500 ライブラリ 3、レール 2 (LSM 9) からライブラリ 1、レール 4 (LSM 3) のドライブにマウントされる場合、これには 2 回の水平方向のパススルーと 1 回のエレベータパススルーが必要です。ACSLS は、カートリッジをマウント解除するときに、LSM 4 内の新しいホームセルを見つけてマウント解除時のパススルーを回避しようとします。
問題:
LSM に空き (未割り当て) ストレージセルがない場合は、LSM にカートリッジをフロートできません。テープドライブの LSM に空きセルがない場合、ACSLS は引き続きカートリッジをドライブにもっとも近い LSM にマウント解除しようとしますが、これには少なくとも 1 回のパススルーが必要です。
解決方法:
長時間にわたってアクセスされていないカートリッジを特定し、それらをいっぱいになった LSM から出して、カートリッジがマウント解除時にフロートできる空きセルを用意します。
カートリッジがマウントまたはマウント解除、挿入、または移動されるたびに、ACSLS がカートリッジに関して記録する情報の中の access_date が更新されます。access_date はそれらのアクティブではないカートリッジを特定するために使用できます。
このプロセス全体は、同じ ACS 内にボリュームを移動するだけで、カートリッジの取り出しやそれらのステータスの変更など、これらのカートリッジの将来のマウントを妨げる可能性のあることを何も実行しない場合は安全です。
もっとも長い間使用されていないカートリッジを特定して移動するには、次の手順に従います。
空きセルが少なすぎる LSM と空のセルを含む LSM を特定します。
もっとも早いアクセス日で LSM 内のカートリッジを選択します。
いっぱいになった LSM から空のセルを含む LSM にカートリッジを移動します。
cmd_proc の使用:
query lsm all
「Free Cell Count」列を使用すると、空きセルがほとんどないかまったくない LSM と、非アクティブなカートリッジを移動できる空のセルがある LSM の両方を特定できます。
例:
ACSSA> query lsm all
2011-08-29 18:15:45 LSM Status
Identifier State Free Cell Audit Mount Dismount Enter Eject
Count C/P C/P C/P C/P C/P
1,0 online 1 0/0 3/0 3/0 0/0 0/0
1,1 online 1 0/0 4/0 5/0 0/0 0/0
1,2 online 1 0/0 3/0 3/0 0/0 0/0
1,3 online 0 0/0 4/0 5/0 0/0 0/0
1,4 online 388 0/0 11/0 1/0 0/0 0/0
1,5 online 162 0/0 4/0 5/0 0/0 0/0
1,6 online 552 0,0 7/0 2/0 0/0 0/0
1,7 online 601 0/0 5/0 3/0 0/0 0/0
ここで、ACS 内のほかの LSM に移動できる非アクティブなカートリッジを特定する必要があります。
アクセス日がソートの助けになる方法で報告されていることを確認します。日付が報告される形式は、TIME_FORMAT 動的変数によって制御されます。
デフォルト形式 TIME_FORMAT=%Y-%m-%d %H:%M:%S を使用して、カートリッジをアクセス日で簡単にソートできるようにします。UNIX コマンドプロンプトで、次を入力します。
dv_config -p TIME_FORMAT
変数プロンプトで Enter ? と入力して、ヘルプを表示します。
変更を行なった場合は、共有メモリー内の動的変数を更新します。
dv_config -u
十分な空きセルがない LSM ごとに、最終アクセス日でソートされたカートリッジをリストします。VOLID と access_date のみを選択するカスタムの volrpt が必要です。
詳細については、次でコメントのヘッダーを参照してください。
$ACS_HOME/data/external/volrpt/owner_id.volrpt
一列になったフィールドは、field_name、field_length、および delimiter_length (このフィールドのあとは空白) です。
次の例では、2 行のアクティブな行があります。おそらく 6 文字の VOLUME_ID が表示されます。ACCESS_DATE については日付部分のみが必要で、時間は必要ありません。
VOLUME_ID 6 2 ACCESS_DATE 10 2
次のように入力します: $cd ACS_HOME/data/external/volrpt。
owner_id.volrpt をコピーして、access_date.volrpt などのファイルに保存します
ロギングボリューム統計レポートの作成を参照してください。
テキストエディタを使用して、ACCESS_DATE を編集します。
LSM のカートリッジのソートされたリストを作成します。
volrpt -l <lsm_id> -d -f access_date.volrpt | sort -k 2,2 -0 vols_sorted_lsm_##
ここで、access_date.volrpt はカスタムレポートの名前で、## は LSM 番号です。
vols_sorted_lsm_## ファイルを調べて、各 LSM の最終アクセス日の分布を確認します。
現在は、移動するカートリッジのリストを作成して、空き容量のある LSM に移動する必要があります。
アクセス日でソートされたカートリッジのリストが含まれるファイルを取得し、アクセス日を削除してカートリッジのリストだけが含まれるようにします。
cat vols_sorted_LSM_## | cut –d” ” –f1 > vols_LSM_##_tmp
各 vols_LSM_## ファイルを取得し、移動するカートリッジの最初の 100 (または指定する数) を選択します。
head -100 vols_LSM_##_tmp > vols_LSM_##
前述の操作の両方を組み合わせることができます。
cat vols_sorted_LSM_## | cut –d” ” –f1 | head -100 > vols_LSM_##
LSM が機能せず、オフラインにした場合、データパスが引き続き動作している場合は、ライブラリドライブにカートリッジを手動でロードできます。
無効になっている LSM 内のドライブにカートリッジを手動でロードするには:
LSM ドアを開きます。
すでにドライブ内にあるカートリッジのカートリッジラベルをメモして、それらを取り外します。この手順の最後にこれらのカートリッジを交換する必要があります。
読み取りまたは書き込みするカートリッジのあるドライブをロードします。
LSM が修復されるまで必要なだけこの手順を繰り返してから、手順 4 に進みます。
注意:
この手順では、カートリッジをライブラリセルから取り外して、これらのカートリッジをドライブにロードできます。これらのカートリッジのセル位置をメモし、手順 4 でカートリッジを確実にこれらの位置に戻してください。LSM が修復されたあと、すべてのカートリッジをドライブから取り外して、手順 2 でメモした元のカートリッジと交換します。
LSM ドアを閉じて、LSM をオンラインに vary し、通常の操作を再開します。