STA メディア検証は、テープライブラリシステム内のデータを確実に長期保存するのに役立つ STA のオプション機能です。これは、Oracle の StorageTek T10000C および T10000D ドライブのデータ整合性チェック機能を使用して、StorageTek SL8500 ライブラリ内の本番メディアに対して、ポリシー主導型の自動検証を提供します。STA は、検証結果を分析して、データ保存に関する推奨を行います。
注:
STA メディア検証は、最小要件を満たすテープライブラリシステム構成のみでサポートされています。STA、ライブラリ、ドライブ、およびメディア要件のリストについては、『STA 要件ガイド』を参照してください。この章の内容は次のとおりです。
このセクションの内容は次のとおりです。
STA では、1 つのユーザーインタフェースを使用して、テーブライブラリシステム内の SL8500 ライブラリ全体でメディア検証アクティビティーを自動化および管理できます。このセクションでは、STA メディア検証の利点について概要を示します。
STA メディア検証は、T10000C および T10000D ドライブ自体により内部で実行されるため、ほかのベンダーの提供する検証手法に対していくつもの利点があります。テープライブラリシステム内のデータは、ネットワークを介して別個のアプリケーションに送信する必要がないため、セキュアに保たれます。メディアやドライブから情報を読み取るための専用のホストサーバーも追加のホストソフトウェアも不要で、ドライブへの追加のファイバチャネルデータ接続が不要なため、コストが削減されます。
ホストアプリケーションが検証ドライブを使用することができず、ホストが検証中のメディアを必要とする場合には、ホストリクエストが優先権を得ます。ライブラリは、検証への割り込みを実行し、メディアをドライブからマウント解除して、メディアをアプリケーションから利用可能にします。これは、アプリケーションに対して透過的に実行されます。
すべてのメディア検証テストの有効性を裏付けるため、STA はオプションのドライブキャリブレーションおよび適格性確認機能を提供します。キャリブレーションにより検証ドライブが正常な動作状態にあることが保証され、適格性確認により、検証ドライブがキャリブレートされた状態を維持し、失敗した検証はドライブではなくメディアが問題の原因であることが保証されます。これらの機能は、いったん構成および有効化されると、ユーザーの介入なしで動作します。詳細は、ドライブのキャリブレーションと適格性検査を参照してください。
STA では、検証用のメディアを自動的に選択するためのポリシーを定義できます。たとえば、メディアの健全性がアクションを開始したり、ドライブが不正なメディア情報レコード (MIR) を検出したりしたときはいつでも検証を開始するポリシーを定義できます。 STA は、検証対象のメディアを互換性のあるドライブ上で自動的にキューに入れます。
STA は、検証アクティビティー用に確保してあるドライブの数に応じて、複数の検証を同時に開始および処理できます。詳細は、自動メディア検証の使用を参照してください。
STA を使用して、検証リクエストキューを管理できます。保留中の検証リクエストの再優先順位付けを行なったり、進行中のリクエストを取り消したり、検証を手動で開始したりできます。詳細は、STA メディア検証リクエストキューの管理を参照してください。
STA は、テープライブラリシステムで実行されたすべての検証アクティビティーの結果を表示します。これには、Oracle の StorageTek SL コンソールや Oracle の StorageTek Storage Archive Manager (SAM) などのほかのアプリケーションにより開始された検証が含まれます。STA は、検証結果を分析して、実行すべきアクションを推薦します。詳細は、検証リクエストのステータスを表示するを参照してください。
表8-1 で、STA と SL コンソールで使用可能なメディア検証機能を比較します。列の「X」は、その機能が製品でサポートされていることを示します。
表8-1 STA と SL コンソールのメディア検証機能の比較
機能 |
STA |
SL コンソール |
---|---|---|
検証ドライブプールを構成する。 |
X |
|
すべての T10000C および T10000D 検証テストタイプをサポートする。 |
X |
X |
誤検出の検証結果を自動的に軽減する。 |
X |
|
検証ドライブをキャリブレートする。 |
X |
|
継続的な検証ドライブ適格性確認を自動実行する。 |
X |
|
一度に 1 つの検証を実行する。 |
X |
X |
一度に複数の検証を実行する。 |
X |
|
複数のライブラリまたはコンプレックス内の検証を一度に実行する。 |
X |
|
自動化されたポリシー主導型検証を実行する。 |
X |
|
複数の検証リクエストをユーザー管理のリクエストキューに送信する。 |
X |
|
保留中の検証リクエストを再優先度付けする。 |
X |
|
進行中の検証について進捗インジケータを表示する。 |
X |
X |
検証結果を一度に 1 つ表示する。 |
X |
X |
複数の検証結果を一度に表示する。 |
X |
|
検証結果を表とグラフの形式で表示する。 |
X |
|
選択した日付範囲の検証履歴を表示する。 |
X |
|
検証の障害および処理に関する詳細情報を表示する。 |
X |
|
限界テープ品質の兆候を報告する (選択したドライブファームウェアバージョン上のみ)。 |
X |
|
検証結果に関するアラートを受信する |
X |
|
検証アクティビティーのダッシュボードサマリーを PC またはモバイルデバイス上に表示する |
X |
|
検証アクティビティーのエグゼクティブレポートサマリーを電子メールで受信する |
X |
T10000C および T10000D ドライブは次のメディア検証テストを実行し、そのすべてを STA で使用できます。メディア検証ポリシーを定義するか、手動メディア検証を開始する際に、実行するテストの種類を示します。手順については、手動メディア検証リクエストの送信および メディア検証ポリシーの作成を参照してください。
メディアがマウント可能であること、およびメディア情報レコード (MIR) が有効であることを確認します。ドライブは、メディアをマウントして、MIR を検証するだけです。この検証により、MIR が読み取り不可であるか、または同期が取れていないかが検出され、メディアの次のデータ属性が更新されます。
Exchange Recording Technique (ドライブがメディアへの書き込みに使用する記録フォーマット)
メディア疑いレベル
MB Written (メディアに書き込まれるデータの合計量)
注:
STA がポリシー主導型の検証でメディアを使用するには、少なくともこの情報がメディアに存在する必要があります。詳細は、自動検証に適したメディアを参照してください。この手法には約 2 分かかります。
もっとも優先順位の高いメディア領域が読み取り可能であることを検証します。ドライブは、テープの先頭 (BOT)、テープの末尾 (EOD)、およびテープの先端と末端に書き込まれている最外部のデータラップでレコードを検証します。
通常、この手法には、使用するデータ量および圧縮比に関係なく、最大 30 分かかります。
このテストは、空のテープでは有効ではありません。
メディアのすべてのデータレコードが読み取り可能であることを検証します。ドライブは、圧縮解除も復号化もせずに、レコード単位で検証を実行します。
デフォルトでは、検証の開始ポイントはテープの先頭 (BOT) です。T10000T2 メディアでは、オプションで、メディア RFID チップにより示される最後の検証位置から検証を再開することもできます。T10000T1 メディアの検証は、常に BOT から開始する必要があります。
ドライブは、メディアで使用されている圧縮比に関係なく、最大のテープ速度でデータを検証します。この手法には、開始ポイント、メディアのデータ量、およびドライブの種類により、約 5 - 9 時間かかることがあります。
このテストは、空のテープでは有効ではありません。
StorageTek データ整合性検証 (DIV) の検査を含め、メディアのすべてのデータレコードが読み取り可能であることを検証します。メディア上のデータレコードに、ホストにより追加された DIV 循環冗長性チェック (CRC) コードが含まれる場合、データは圧縮解除および復号化されます。そのため、このテストでは、検証ドライブが暗号化に対応していて、Oracle Key Manager (OKM) に接続されている必要があります。このテストは、FICON インタフェースを使用して構成されたドライブでは有効ではありません。
デフォルトでは、検証の開始ポイントはテープの先頭 (BOT) です。T10000T2 メディアでは、オプションで、メディア RFID チップにより示される最後の検証位置から検証を再開することもできます。T10000T1 メディアの検証は、常に BOT から開始する必要があります。
この手法には、開始ポイント、メディアのデータ量、ドライブの種類、および圧縮比により、約 5 - 9 時間かかることがあります。
このテストは、空のテープでは有効ではありません。
必要に応じて、MIR を検証および再構築します。ドライブは、最初に MIR を検証します。エラーが存在する場合、ドライブは最後に良好であったことが知られている MIR 上の領域を見つけ、テープ上のそのポイントまで高速検索を実行します。次に、ドライブは、圧縮解除も復号化もせずに、レコード単位で検証を実行します。MIR が無効であるか、同期されていない場合、ドライブはテープの先頭 (BOT) から開始してすべてのレコードを読み取り、MIR の再構築に必要な情報を収集してから、再構築を実行します。レコードは、圧縮解除も復号化も行われません。
交換時に破損した MIR が存在する場合に、このメソッドを使用します。
ドライブは、最大のテープ速度でデータを読み取ります。この手法には、開始ポイント、メディアのデータ量、およびドライブの種類により、約 5 - 9 時間かかることがあります。これは、ドライブの Virtual Operator Panel (VOP) を使用して MIR を再構築するよりも大幅に高速です。
このセクションの内容は次のとおりです。
STA でメディア検証を有効にする前に、次の準備段階を実行します。
メディア検証を実装するライブラリコンプレックスおよびスタンドアロンライブラリを決定します。
「STA Drives – Overview」画面で、これらのライブラリ内のメディア検証に使用するドライブを確認して選択します。詳細は、検証ドライブプールを参照してください。
SL コンソールを使用して、ドライブを検証プールに追加します。選択したスタンドアロンライブラリまたは選択したコンプレックスの一部であるライブラリ上で、SL コンソールにログインする必要があります。詳細は、『SL8500 ユーザーズガイド』を参照してください。
ドライブキャリブレーションおよび適格性確認を使用するかどうかを決定し、使用する場合にはキャリブレーションメディア論理グループを作成します。詳細は、ドライブのキャリブレーションと適格性検査を参照してください。
検証ドライブは、当分の間、メディア検証用に排他的に確保されているドライブです。これらのドライブにホストアプリケーションからアクセスすることはできません。これらは、SL コンソールを使用して、メディア検証ドライブプールに割り当てる必要があります。
各 SL8500 ライブラリコンプレックスおよびスタンダード SL8500 ライブラリには、独自の検証ドライブプールがあり、各プールに最大 10 台のドライブを割り当てることができます。メディアを検証するライブラリコンプレックスまたはスタンドアロンライブラリごとに、1 台以上のドライブをを割り当てる必要があります。暗号化されたメディアを検証する場合は、適応可能な各ライブラリ内で、暗号化が有効にされ、かつ Oracle Key Manager (OKM) に接続されているドライブを 1 台以上割り当てる必要があります。
注:
サイトに検証ドライブが 1 台しかない場合は、検証対象のメディアをそのライブラリに移動する必要があります。必要に応じてドライブを検証ドライブプールに追加したり、そこから削除したりできます。STA は、変更をすべて検出し、必要に応じて新しいドライブを使用します。
ドライブが検証ドライブプールに追加される際、SL コンソールは STA の最小要件を確認しません。このため、プール内のドライブは、STA での使用に合わせて必ずしも有効化されているとは限りません。ただし、「STA Media Validation Configuration」画面には、STA メディア検証の最小要件を満たす検証ドライブの総数が表示されます。そこから「Drives – Overview」画面にリンクし、そこで、ドライブの種類、ドライブの健全性インジケータ、およびドライブの位置などのドライブの詳細を表示できます。手順については、STA メディア検証用の検証ドライブを表示するを参照してください。
「Drives – Overview」画面を、ナビゲーションバーから直接選択して、「STA–Drive–MV」テンプレート (STA 定義済みテンプレート) を適用することもできます。図8-1 は、表示例です。
ドライブは SL コンソールを使用して検証ドライブプールに割り当てられますが、STA を使用して候補のドライブを確認および選択できます。
任意のドライブをプールに割り当てることができますが、STA がそれらを使用できるようにするには、次の最小要件を満たす必要があります。
ドライブのモデルが T10000C または T10000D であること。
ドライブのファームウェアバージョンの末尾が 5.40 以降 (これは、ファームウェアが TTI 5.4 をサポートすることを意味する) であること。
ドライブの健全性インジケータが使用中であること。
ドライブの疑いレベルが 0 であること。
図8-7 は、「Drives – Overview」画面で使用可能なサンプルフィルタです。
これらの最小要件に加え、最近アクティビティーが含まれ、エラーがほとんどあるいはまったく存在しない高品質のドライブを選択します。次の特性を持つドライブは、検証プール用の優れた候補となります。
過去 30 日間のアクティビティー。「Drive Dismounts (30 Days)」属性を参照してください。
ドライブエラーが存在しないこと。「Drive Errors (30 Days)」属性を参照してください。
過度なドライブ消去がないこと。「Cleans (30 Days)」属性を参照してください。
過度のアラートや SNMP トラップがないこと。アラートやトラップが存在する場合は、調査を行なって、それらがドライブの潜在的な問題を示しているかどうかを判断することをお勧めします。「Drive SNMP Trap Count (30 Days)」、および「Alert Count (30 Days)」属性を参照してください。
比較的高速であること。「Mount R/W MB/sec (30 Days)」属性を参照してください。
選択したドライブをグラフに適用して、ドライブの特性を視覚的に表示して選択を確認できます。図8-3 に、「Drives – Overview」画面のグラフに適用された 3 台の候補ドライブを示します。
STA メディア検証は、デフォルトでは無効になっているため、明示的に有効にする必要があります。これはグローバル設定であるため、いったん有効にすると、テープライブラリシステム内のすべての SL8500 ライブラリで STA メディア検証が有効になります。詳細な手順は、STA 上でメディア検証を有効または無効にするを参照してください。メディア検証の有効化および無効化するには、管理者権限が必要です。
メディア検証が有効になると、STA を使用して次のアクティビティーを実行できます。
手動メディア検証リクエストの作成。詳細は、手動検証リクエストの送信を参照してください。
メディア検証リクエストキューの表示および管理。STA メディア検証リクエストキューの管理を参照してください。
メディア検証ポリシーを使用した自動検証の実行。詳細は、自動メディア検証の使用を参照してください。
注:
STA でメディア検証を有効にする前に、検証ポリシーを作成できます。「Media Validation Configuration」画面に、STA メディア検証機能の現在の構成ステータスが表示されます。
ドライブのキャリブレーションおよび適格性確認なしでのメディア検証の構成中に、次のメッセージが表示されることがあります。図8-4 に例を示します。
Media Validation is DISABLED.
Media Validation successfully enabled.
Media Validation Enabled; Opted-out of Drive Calibration.
図8-4 Media Validation Configuration Success Message
ドライブのキャリブレーションおよび適格性確認機能の有効化と構成には、いくらか時間がかかる場合があります。このプロセスの進行中に、次のメッセージが表示されることがあります。図8-5 に例を示します。これらの機能については、ドライブのキャリブレーションと適格性検査を参照してください。
Media Calibration Process in Progress.
Media Operation to Create History in Progress.
Drive Qualification Type Pool Pre-Calibration SUCCESS.
Calibration Success.Drive Qualification is Now Active.
次のメッセージは、メディア検証構成に問題があることを示します。図8-6 に例を示します。
No Available Drives, Not Suitable for Media Validation Use.
No Available Media, Not Suitable for Calibration Use.
Warning: Insufficient Media in MV Media Pool for Number Of Drives in MV Partition.
メディア検証がサイトで有効になっている場合、ライブラリの保守時に一時的に無効にできます。詳細な手順は、STA 上でメディア検証を有効または無効にするを参照してください。
STA は、メディア検証が無効の場合には、新しいメディア検証リクエストを一切受け入れません。保留中または進行中のリクエストは、明示的に取り消さないかぎり、完了するまで処理されます。
メディア検証が無効になっていても、STA は、SL コンソールやライブラリコマンド行インタフェース (CLI) などのほかのソースから開始されたリクエストは表示します。
ドライブのキャリブレーションと適格性検査は、すべてのメディア検証テストの有効性を確認する、 STA のオプション機能です。これらの機能が有効な場合、STA はキャリブレートおよび適格性検査されたドライブのみを使用してメディア検証アクティビティーを実行します。
キャリブレーションは一回限りの設定プロセスであり、検証ドライブが、メディア検証での使用前に良好な動作状態にあることを保証します。適格性検査は、キャリブレートされたドライブで実行される、継続的で自動的なプロセスです。これは、失敗した検証が、ドライブではなくメディアの問題の結果であることを検証します。
これらの機能を組み合わせることで、それぞれ、そしてすべてのメディア検証の結果がテスト対象メディアの真の品質を反映しており、検証ドライブの未知の問題と取り違えられることがないことが保証されます。
このセクションの内容は次のとおりです。
これらは、ドライブのキャリブレーションと適格性検査の概念を理解するのに役立つ用語で、このセクション全体で使用されています。
ドライブがメディアとそのデータに対して指定された検証テストを実行する、メディアおよびドライブの交換。
「Degraded」または「Failed」ステータスで終了するメディア検証交換。
メディアではなく検証ドライブの問題により失敗した検証。STA は、ドライブのキャリブレーションと適格性検査プロセスを使用して、誤検出結果の可能性を抑え、失敗した検証がメディアの問題の結果であることを保証します。
オプションの STA メディア検証機能で、その目的は検証ドライブが最適に動作していることを保証することです。ドライブキャリブレーションが有効な場合、STA がメディア検証に検証ドライブを使用する前に、検証ドライブをキャリブレートする必要があります。
STA ドライブキャリブレーションプロセスに合格した検証ドライブ。キャリブレーションに失敗するドライブは、不適格と見なされ、STA で使用されません。STA ドライブキャリブレーション機能が無効の場合、すべての検証ドライブがキャリブレートされていないと見なされますが、STA により使用されます。
まだキャリブレートされていないドライブ、または STA キャリブレーション機能が有効でないシステム内の検証ドライブ。
検証ドライブがキャリブレートされた状態を維持していることを保証し、失敗した検証がドライブではなくメディアの問題であることを保証するのに役立つ、オプションの STA メディア検証機能。STA は、失敗した検証が存在する場合には常に自動的にドライブ適格性検査プロセスを開始します。ドライブ適格性検査は、ドライブキャリブレーションの一部として有効にされます。
ドライブキャリブレーションは、基本的に一回限りのプロセスであるのに対し、ドライブ適格性検査は継続的です。
STA ドライブ適格性検査プロセスに合格した、キャリブレート済みドライブ。
STA キャリブレーションまたは適格性検査に失敗したドライブ。
ドライブキャリブレーションおよび適格性検査のために特に確保されたメディア。STA を使用して、キャリブレーションメディアを手動論理グループに割り当てます。キャリブレーションメディアはドライブのキャリブレーション専用にし、本番データには使用しないことが、強く推奨されています。キャリブレーションメディアは、高品質のものにしてください。
メディアに残っているエラー修正量の測定。RQI は、全体として交換に適用され、交換に関係するメディアとドライブの両方からの関与を含みます。この用語は、メディア検証に固有であり、読み取りマージンとは異なります。
RQI は、割合でレポートされます。大きい値ほど望ましいです。
メディアに残っているエラー修正量の測定で、これは読み取り品質インデックス (RQI) と似ていますが、ドライブの関与を取り除くため、特にメディアを対象としています。ドライブキャリブレーションおよび適格性検査時に、STA は DQI を使用してドライブが適格か不適格かを判定します。
DQI は、割合でレポートされます。大きい値ほど望ましいです。
ドライブキャリブレーションおよび適格性検査はオプション機能ですが、次の重要な利点があるため、STA 上で有効にすることが強く推奨されています。
各交換にはメディアの一部とドライブの一部が両方含まれるため、交換の失敗が発生した場合、問題がドライブにあるのか、メディアにあるのか、それとも両方にあるのかは常に不確実です。本番メディアの場合、STA は、1 つにはメディアとドライブの利用可能な履歴データを活用することにより、不確実性を低減する高度な健全性および疑いアルゴリズムを使用します。利用可能なデータが増えるほど、分析の信頼性が高まります。
メディア検証の失敗にも、同じ本質的な不確実性が存在します。ただし、検証交換に問題メディアおよび履歴がほとんどあるいはまったく利用できないメディアが通常以上の割合で含まれる傾向があるため、問題はより複雑です。
たとえば、1 年以上使用されていないアーカイブメディアには、最小限の STA データしか含まれていない可能性があります。このメディアの検証がキャリブレートされていないドライブ上で実行され、その検証が失敗した場合、失敗は検証対象のメディアではなく、検証ドライブに関連した問題の結果である可能性があります。メディアで最小限の履歴データしか利用できない場合、検証結果の不確実性が高まります。STA ドライブキャリブレーションおよび適格性検査機能は、これらの不確実性に直接対処し、失敗した検証はメディアの問題であることが確実になります。
キャリブレーションと適格性検査のもう 1 つの利点は、ドライブ品質です。検証ドライブでは問題メディアとの交換が通常より多く行われるため、本番ドライブよりも早く機能が低下する可能性があります。ドライブ適格性検査により、STA は検証ドライブの健全性を継続的に検証します。ドライブの問題は早期に識別されるため、本番メディアで検証ドライブに問題が発生する前に修理または交換できます。
メディア検証が失敗した場合、結果を検証して、メディアに問題があることを確認するためのアクションが必要になります。ドライブキャリブレーションおよび適格性検査が無効である場合、この検証を手動で実行する必要があります。たとえば、別のドライブを使用してメディアに対して「Complete Verify」を実行し、この検証にも失敗するなら、ドライブではなくメディアに問題があると合理的に判断できます。メディア上のデータ量によっては、これは数時間かかる場合があります。
ドライブキャリブレーションおよび適格性検査が有効であれば、STA は、ドライブ適格性検査プロセスによりすべての失敗した検証を確認します。適格性検査は、ユーザーの介入なしで自動的に実行されます。STA は適格性検査済みのメディアを使用するため、適格性検査には「Complete Verify」よりも所要時間が大幅に短い「Standard Verify」を実行するだけで十分です。
キャリブレーションと適格性検査は別個のプロセスですが、まとめて有効化および無効化できます。キャリブレーションと適格性検査を使用する前に、これらのアクティビティーに使用するメディアの手動論理グループを作成しておく必要があります。詳細は、キャリブレーションと適格性検査の準備を参照してください。
ドライブキャリブレーションは、「Media Validation」画面でドライブキャリブレーションが有効になるとすぐに実行される、一回限りの設定プロセスです。検証ドライブプール内のすべてのドライブは、「Standard Verify」を使用してテストされます。これには、ドライブごとに 1 - 2 時間かかる場合があります。
ドライブキャリブレーションが構成および有効化されると、手動での介入なしで処理が自動的に実行されます。新しいドライブがメディア検証プールに追加されると、STA はこれを検出して、ドライブのキャリブレーションを自動的に開始します。また、STA はファームウェア更新後にドライブを自動的に再キャリブレートします。
キャリブレーションは、各検証ドライブで次の基本プロセスを使用します。
STA は、ドライブに対して 2 回 Standard Verify 検証を実行しますが、毎回キャリブレーションメディア論理グループから異なるメディアを使用します。
STA は、検証から得たデータ品質インデックス (DQI) 値を分析します。ドライブの適格性検査を実行するには、次の条件を満たす必要があります。
1 つのメディアは DQI >= 75 である必要があります。これは、ドライブにプライマリキャリブレーションメディアとして割り当てられます。
1 つのメディアは DQI >= 50 である必要があります。これは、ドライブに セカンダリキャリブレーションメディアとして割り当てられます。
DQI 結果に応じて、STA は、次の処理を実行します。
2 回の検証後に両方の条件が満たされる場合、ドライブはキャリブレートされます。このドライブでは 3 回目の検証は不要です。
2 回の検証後にこれらの条件の 1 つだけが満たされる場合、キャリブレーションメディア論理グループとは異なるメディアを使用して、3 回目の検証が実行されます。
3 回の検証で両方の条件が満たされない場合、ドライブは不適格と見なされます。
ドライブがキャリブレーションに合格した場合、そのドライブに 2 つのメディアが専用のプライマリおよびセカンダリキャリブレーションメディアとして割り当てられます。キャリブレーションプロセス中、これらのメディアは高品質であることが確認されます。各検証ドライブは、独自のプライマリおよびセカンダリキャリブレーションメディアを保持し、これらのメディアは、ドライブに対するすべてのドライブ適格性検査アクティビティーで使用されます。
ドライブがキャリブレーションに失敗する場合、それは不適格です。不適格なドライブには、「Not Suitable」というキャリブレーション状態が割り当てられ、これらは、ドライブキャリブレーションが有効な間、どのような STA 検証アクティビティーにも使用されません。これらは、SL コンソールを使用して明示的に削除しないかぎり、メディア検証ドライブプール内にとどまります。
注:
ドライブキャリブレーションが無効な場合、STA は「Not Suitable」キャリブレーション状態を無視して、そのドライブを検証に使用します。これは、キャリブレーションが STA 上で、ある時点で有効であり、それ以降無効になっている場合に発生します。すべてのドライブがキャリブレートされると、「Media Validation Configuration」画面に「Drive and Media Pool Setup Success--calibration has been successful.」と表示されます。個別のドライブに関する詳細な結果が「Drives – Overview」画面に表示されるので、結果を確認して適切なアクションを実行できます。手順については、STA メディア検証用の検証ドライブを表示するを参照してください。
検証ドライブの適格性が確認されると、ドライブが引き続きキャリブレートされた状態にあることが保証されます。適格性検査は、バックグラウンドで自動的に実行され、ユーザーの介入を必要としない継続的なプロセスです。STA は、メディア検証の結果が「Degraded」または「Failed」ステータスになる場合、常に適格性検査を自動的に開始します。
適格性検査の間、検証ドライブは「Standard Verify」を使用してテストされます。テストは、ドライブに割り当てられたプライマリおよびセカンダリのキャリブレーションメディアを使用して実行されます。適格性検査は、ドライブキャリブレーションに似たプロセスに従います。
適格性検査が完了すると、STA は、ドライブとメディアの品質に関して次のいずれかを推奨します。
ドライブは不適格である。
データメディアが不良である。
データメディアが不良で、セカンダリキャリブレーションメディアが不適格である。
不適格なメディアはドライブのキャリブレーションや適格性検査には使用されません。これらは、明示的に削除するまで、キャリブレーションメディア論理グループ内にとどまります。不適格なドライブに関する情報は、ドライブキャリブレーションの結果を参照してください。
適格性検査の結果は、「Media Validation Overview」画面の「Calibration」および「Qualification」属性に表示されます。結果を確認して、適切なアクションを実行できます。
キャリブレーションと適格性検査を有効にする前に、次の準備タスクを実行する必要があります。
「Logical Groups」画面で、ドライブキャリブレーションに使用するメディア用の手動論理グループを作成します。詳細は、キャリブレーションメディア論理グループを参照してください。このタスクには、オペレータ権限または管理者権限が必要です。
「Media – Overview」画面で、ドライブキャリブレーションに使用するメディアを確認して選択します。詳細は、キャリブレーションメディアの選択を参照してください。
メディアを論理グループに割り当てます。このタスクには、オペレータ権限または管理者権限が必要です。
ドライブのキャリブレーションと適格性検査を有効にします。手順については、ドライブキャリブレーションと適格性検査の有効化を参照してください。このタスクには、管理者権限が必要です。
ドライブのキャリブレーションと適格性検査に使用するメディアは、この目的専用の手動論理グループに割り当てる必要があります。これが、キャリブレーションメディア論理グループです。論理グループがキャリブレーションメディア論理グループとして指定されると、その内部のメディアはホスト操作には使用できなくなり、それらを通常のメディア検証操作に使用することは STA により許可されません。
キャリブレーションメディア論理グループは、テーブライブラリシステム全体で 1 つしか存在しません。検証ドライブプール内の各ドライブに少なくとも 2 つのメディアを割り当てる必要があり、メディアは検証ドライブと同じスタンドアロンライブラリおよびライブラリコンプレックス内に存在する必要があります。たとえば、コンプレックス SL8500 1 内に 8 台の検証ドライブがあり、スタンドアロンライブラリ SL8500‐Seattle 内に 1 台の検証ドライブがある場合、論理グループは、少なくともコンプレックス SL8500 1 内のライブラリからの 16 個のメディア、およびライブラリ SL8500‐Seattle からの 2 個のメディアを含んでいる必要があります。グループに割り当てることのできるメディアの最大数はありません。
必要に応じてメディアを論理グループに追加したり、そこから削除したりできます。STA は、変更をすべて検出し、必要に応じて新しいメディアを使用します。
キャリブレーションメディアはドライブキャリブレーションおよび適格性検査専用にし、本番データには使用しないことが、強く推奨されています。これは、メディアの品質が本番操作で低下しないことを保証するのに役立ちます。キャリブレーションメディアの優れた候補を次に示します。
使用されているが、必要でなくなったデータを含むメディア。たとえば、良好な状態にある期限切れバックアップメディア。
ダミーデータを書き込んだ、良好な状態にある新しいまたは未使用のメディア。データを暗号化するかどうかは、必要に応じて決定できます。
ドライブキャリブレーションと適格性検査に使用するには、メディアが次の条件を満たしている必要があります。
「Media Type」が「T10000T2」(つまり、T100000T2 または T10000T2 Sport) であること。T10000T1 メディアは検証可能ですが、ドライブキャリブレーションと適格性検査には使用できません。
「Media Health Indicator」が「Use」であること。
「Media Suspicion Level」が「0」であること。
少なくとも 2 つのデータラップがメディアに書き込まれていること。
注:
メディアをキャリブレーション論理グループに追加する場合、STA はこれらの条件をチェックしないため、キャリブレーションや適格性検査に使用できないメディアを割り当てることも可能です。注:
キャリブレーション論理グループに割り当てるいずれかのメディアに、最小限の必須 STA 履歴がない場合、STA はそれに対して Basic Verify を自動的に開始してから、ドライブキャリブレーションでの使用を試みます。Basic Verify により、最小限必要な履歴が提供されます。詳細は、検証テストの種類を参照してください。これらの要件を満たすメディアを見つけるため、フィルタを「Media – Overview」画面に適用できます。図8-7 に、「Media – Overview」画面で使用できるサンプルフィルタを示します。
「Media MB Avail Post」属性でフィルタ処理された結果をソートして、2 つ以上のデータラップを持つメディアを見つけることができます。これは、記録フォーマットおよびメディアタイプによって異なります。表8-2 に、必要な量のサマリーを示します。
STA 上で検証ドライブプールが作成され、メディア検証が有効になったら、STA を使用して手動検証リクエストを送信して、検証リクエストキューを管理できます。手順については、手動メディア検証リクエストの送信を参照してください。
注:
ドライブキャリブレーションを有効にしている場合、キャリブレーションメディア論理グループに含まれるメディアを手動または自動の検証リクエストに含めることはできません。STA は、そのメディアがメディア検証に適していないというエラーメッセージを表示します。これらのメディアの詳細は、キャリブレーションメディア論理グループを参照してください。次のいずれかの画面から手動検証リクエストを送信できます。
「Media Overview」 - 同じ検証テストで検証するメディアを一度に複数個選択できます。検証では、選択範囲において適格なメディアのみが確認されます。図8-8 に例を示します。選択範囲には、さまざまなメディアタイプが含まれており、中にはメディア検証で適格ではないメディアタイプも含まれています。
「Media Validation Overview」 – 1 回につき 1 つのメディアを検証用に選択できます。図8-9 に例を示します。
手動リクエストを生成するには、次の情報を指定します。図8-10 に手動検証リクエストの例を示します。
検証対象のメディア。STA で生成できるのは T10000 メディア用のリクエストだけです。「Media Overview」画面で複数のメディアを一度に選択し、T10000 はその一部のみである場合、適切なメディアだけが検証用に確認されます。
検証テストのタイプ。これは、メディア上で実行される検証テストのタイプです。詳細は、検証テストの種類を参照してください。
テープの先頭 (BOT) から開始するか、検証が最後に中断された位置から再開します。このオプションを使用できるのは、次のすべての条件が満たされる場合だけです。詳細は、T10000T2 メディア上で中断された「Complete Verify」テストを再開するを参照してください。
T10000T2 メディアを検証用に選択していること。(T10000T1 メディア検証は、常にテープの先頭から開始される。)
検証テストのタイプが「Complete Verify」または「Complete Verify Plus」であること。(その他のテストタイプは常にテープの先頭から開始される。)
選択したメディアの一部またはすべてに対して前回実行した検証が、100% 完了していないこと。(前回実行した検証が完了しているメディアは、常にテープの先頭から開始される。)
検証ドライブ – サイトに複数の検証ドライブが存在する場合、推奨されるドライブ選択方法は、STA で互換性のある検証ドライブを選択することです。ただし、選択したメディアすべてが同じスタンドアロンライブラリまたはライブラリコンプレックス内にある場合、使用するドライブを手動で指定できます。STA の提供する互換性のあるドライブのリストから選択できます。メディアが複数のスタンドアロンライブラリまたはコンプレックス間で分散されている場合、STA は使用するドライブを自動的に選択します。
手動リクエストを送信するとすぐに、STA メディア検証リクエストキューにそのリクエストが追加されます。検証は、互換性のあるドライブが使用可能になると開始されます。
互換性のないメディアまたはドライブに対して手動で「Verify and Rebuild MIR」リクエストを送信した場合 (たとえば、T10000D で検証される T10000C メディアにリクエストを送信した場合)、最小ファームウェアレベルが TTI 5.5.0 のドライブは、リクエストを適切に拒否します。ファームウェアが最小の TTI 5.5.0 要件を満たしていないドライブも、リクエストの処理を試みますが、MIR を再構築できる場合は、リクエストに対して誤って正常のステータスをレポートすることがあります。STA が生成するのは、メディアとドライブに互換性があるリクエストのみであるため、自動リクエストではこのような状況は発生しません。
「Verify and Rebuild MIR」リクエストの STA バージョンでは、最後に良好であったことが知られている領域がデータの末尾 (EOD) であった場合には、MIR を再構築できないことがあり、このときにはドライブの Virtual Operator Panel (VOP) を使用して MIR を再構築する必要があります。
STA を使用して任意の数のメディア検証ポリシーを定義でき、さまざまなユーザー定義条件に基づいて検証用のメディアが自動的に選択されます。STA は、選択したメディアごとに検証リクエストを生成し、それが STA 検証キューに送信されます。互換性のあるドライブが使用可能になるとすぐに、検証が開始されます。このアクティビティーは、STA によりすべて自動的に管理されます。
メディア検証ポリシーの数およびその定義方法によっては、1 つのメディアが 1 日に数回検証用に選択される可能性があります。これを防ぐために、STA は、自動検証をメディアごとに最大 1 日 1 回に制限します。あるメディアに対して検証リクエストが生成されると、STA は、その日、そのメディアに対する追加の検証リクエストを生成しません。
注:
ドライブキャリブレーションを有効にしている場合、キャリブレーションメディア論理グループに含まれるメディアを、手動または自動の検証リクエストに含めることはできません。STA は、これらのメディアを検証ポリシーから自動的に除外します。これらのメディアの詳細は、キャリブレーションメディア論理グループを参照してください。メディアが STA によりポリシー主導型の検証で使用されるには、メディアが最小限の履歴を保持している必要があります。メディアは、次の属性の値を保持している必要があります。
Exchange Recording Technique (ドライブがメディアへの書き込みに使用する記録フォーマット)
メディア疑いレベル
MB Written (メディアに書き込まれるデータの合計量)
STA でこの履歴を保持していないメディアを検証するには、Basic Verify を手動で開始して、これらの属性を指定する必要があります。詳細は、検証テストの種類および 手動メディア検証リクエストの送信を参照してください。
管理者権限を持つユーザーが、「Media Validation」画面の「Setup & Administration」タブでこの部分のプロセスを実行します。検証ポリシーを作成するために、STA でメディア検証を有効にする必要はないため、これは必要に応じて事前に実行できます。
検証ポリシーの作成時に、それをすぐに有効にすることも、しばらく無効のままにしておくこともできます。STA は、有効なポリシーのみを使用して、検証リクエストを生成します。
検証ポリシーを定義する場合は、次の情報を指定します。
ポリシー名 – 英数字のポリシー識別子。ポリシー名は一意である必要があります。
ポリシーの説明 – ポリシーのオプションの説明。
適用可能なメディアグループ – ポリシーの適用先を、指定したライブラリコンプレックス内の指定した記録フォーマットのメディアにするか、指定した論理グループ内のメディアにするかを選択できます。論理グループの詳細は、論理グループごとにメディアを検証するを参照してください。
選択条件 – 適用可能なメディアグループ内のメディアを検証用に選択するための定義済みの条件。詳細は、検証ポリシーの選択条件を参照してください。
検証テストのタイプ – メディア上で実行する検証テストのタイプ。詳細は、検証テストの種類を参照してください。
詳細な手順は、メディア検証ポリシーの作成を参照してください。
メディア検証ポリシーを任意の既存論理グループに適用できます (ポリシーごとに 1 つの論理グループ)。STA は、次の条件を両方とも満たすグループ内のメディアに対してのみ、検証リクエストを生成します。
T10000 メディア
STA の最小要件を満たすドライブの検証ドライブプールを持つ、スタンドアロン SL8500 ライブラリまたはライブラリコンプレックス内のメディア
STA は、次の定義済み条件のいずれかに基づいて検証用のメディアを選択できます。
「Random Selection」 – スタンドアロンライブラリまたはライブラリコンプレックス内の検証ドライブが使用可能である場合、常に検証用のメディアをランダムに選択します。
「Media Health = Action」 – 指定した数の一連の交換の結果が Exchange Media Health of Action であったメディアを選択します。1 - 5 回の交換を指定できます。
「Media Health = Evaluate」 – 指定した数の一連の交換の結果が Exchange Media Health of Evaluate であったメディアを選択します。1 - 5 回の交換を指定できます。
「Media Health = Monitor」 – 指定した数の一連の交換の結果が Exchange Media Health of Monitor であったメディアを選択します。1 - 5 回の交換を指定できます。
「Extended Period of non-use」 – 指定した日数の間、交換がなかったメディアを選択します。指定できるのは、365 - 1,095 日 (1 - 3 年) です。
「Newly Entered」 – 最近ライブラリに入れられたメディアを選択します。
「Bad MIR Detected」 – 交換の結果が Bad MIR Detected エラーであったメディアを選択します。不正なメディア情報レコード (MIR) は、メディアの高速アクセスが低下していることを示します。
メディア検証リクエストキューは、「Media Validation Overview」画面の「Tape System Activity」タブに表示されます。このキューには、テープライブラリシステム内で発生したすべてのメディア検証アクティビティーがリスト表示されます。これには、STA またはほかの任意のアプリケーションにより開始された、保留中および完了した検証リクエストが含まれます。デフォルトでは、リクエストは、リストの先頭が最新のリクエストになる逆 Priority Order でリスト表示されます。
「Media Validation Overview」画面で、次のいずれかのアクティビティーを実行できます。
「Media Validation Overview」画面には、すべての検証リクエストの詳細が表示されます。このセクションでは、この画面上の特に興味を引く属性について説明します。
注:
ドライブ、メディア、ライブラリ接続がテープライブラリシステムから削除された場合、関連する保留中の STA 検証リクエストは、明示的に取り消すまでリクエストキュー内にとどまります。手順については、保留中のメディア検証リクエストの取り消しを参照してください。Priority Order 属性は、キュー内の各検証リクエストの順序を示します。新たに作成されたリクエストには、新たに使用可能な Priority Order 値が割り当てられます。STA はリクエストを優先順位ごとに処理するため、保留中のリクエストをキュー内で上または下に移動させることで再優先順位付けを行うことができます。手順については、保留中のメディア検証リクエストの再順序付けを参照してください。
保留中および進行中のリクエストは逆 Priority Order でリスト表示されるため、最近受け取ったリクエストがリストの上部に配置されます。完了した検証の Priority Order 値は空白になります。
Request State は、各検証リクエストの進行状況を示します。通常、リクエストは次の順序で処理されます。
「Pending」 – リクエストが送信され、互換性のある検証ドライブが利用可能になるまで待機しています。Request Status Information 属性に、追加の詳細が表示されます。
「Starting」 – ドライブは、検証操作用に予約されています。
「In-Progress」 – 検証が進行中です。Elapsed Time および Estimated Time Remaining 属性は、操作の進行に応じて継続的に更新されます。
「Completed」 – 検証が完了しました。STA に表示される情報の詳細は、メディア検証結果を参照してください。
また、次の Request States がいつでも発生する可能性があります。
「Error」 – リクエストに関係するエラーが発生しました。Request Status Information 属性に、追加の詳細が表示されます。
「Stopping」または「Stop Requested」 – 手動またはホストアプリケーションからのメディアリクエストにより、リクエストが停止しました。詳細は、保留中または進行中の検証リクエストを取り消すを参照してください。
STA は、テープライブラリシステムから受信したすべてのメディア検証情報を報告します。そのため、STA により開始されないメディア検証が表示される場合があります。メディア検証はさまざまなアプリケーションから実行でき、Initiator 属性はそのソースを示します。オプションを次に示します。
「Drive」 – 検証が T10000C または T10000D ドライブ上で直接開始されたことを示します。
「Host」 – Oracle の StorageTek Storage Archive Manager (SAM) などの外部ホストアプリケーションを示します。これらのアプリケーションは、T10000C および T10000D ドライブの内部メディア検証機能を使用しません。
「Library」 – ライブラリコマンド行インタフェース (CLI) を示します。CLI を使用したメディア検証の開始が承認されるのは、Oracle サポート担当者 だけです。ただし、ライブラリ管理者は CLI を使用して保留中または進行中の検証を取り消すことができます。詳細は、『SL8500 ユーザーズガイド』を参照してください。
「SLC」 – SL コンソールを示します。
「STA」 – STA を示します。
検証が完了すると、メディアがメディアスロットに戻され、STA に結果および推奨されるユーザーアクションが表示されます。次に示すのは、特に結果がエラーとなった検証で、検証結果を解釈するのに役立つ可能性がある「Media Validation Overview」画面の属性です。
STA は、次の Validation Result 値のいずれかを完了した各検証に割り当てます。
「Use」 – メディアが検証に合格しました。
「Degraded」 – データを移行し、メディアを抹消してください。
「Failed」 – データを移行し、サイトのポリシーに従ってメディアを処理してください。
「Unknown」 – 次の状況で発生する可能性があります。
DQI は、検証結果に基づいて STA により計算される、メディアに残っているエラー修正量の尺度です。この値はパーセンテージで表現され、値が大きくなるほど結果が良好であることを意味します。次の場合に、この属性は空白になります。
検証が Basic Verify である場合。
検証結果で、メディア検証 Perm Status が True になる場合。
検証結果が Invalid MIR エラーである場合。
この属性には、ユーザーアクションに関する STA からの推奨事項が含まれます。次に、表示される可能性のあるいくつかのメッセージを示します。
「Media OK」: 引き続き使用してください。
Media Degraded--Perform Qualification.
Permanent error encountered: Perform drive qualification.
Not enough data to determine MV results.Rerun media validation.
Degraded Media: Rerun Media Validation Using a Different Drive.
Media Validation Interrupted.
通常、この属性は空白ですが、検証リクエストで発生した問題に関する情報が含まれることがあります。問題の説明および実行すべき修正アクションが含まれることがあります。次に、表示される可能性のあるいくつかのメッセージを示します。
Drive Timeout; MDV manager cancel – 検証を完了するのに 9 時間以上かかったため、STA がライブラリに対してメディアをメディアスロットに戻すことをリクエストしました。通常、これはライブラリ操作エラーの結果です。検証交換の Read Percentage 属性が 100% 未満である場合、検証は完了していません。メディアが繰り返しこのステータスになる場合、おそらくメディアに問題があります。ドライブが繰り返しこのステータスになる場合、おそらくドライブに問題があります。
ライブラリから返されたエラーコード – 検証リクエストの処理中にライブラリから返されたエラーコードを示します。エラーコードは、Library Error 属性内にも示されます。
特に Complete Verify または Complete Verify Plus 検証は完了までに数時間かかる場合があるため、検証リクエストを取り消すことが必要な場合があります。STA から、STA で開始された保留中または進行中の検証リクエストのみを取り消すことができます。これらのリクエストは、いつでも取り消すことができ、また複数のリクエストを一度に取り消すことができます。
保留中のリクエストは、取り消されるとすぐに検証リクエストキューから削除されます。
実行中の検証については、「Complete Verify」または「Complete Verify Plus」テストのみを取り消すことができます。進行中のリクエストが取り消されると、Request State が Stopped に変更され、STA が取り消しリクエストをそのドライブに送信します。ドライブがリクエストを受信して、メディアをロード解除およびマウント解除するのに数分かかることがあります。メディアがメディアスロットに戻されると、検証リクエストが検証リクエストキューから削除されます。あとで検証を再開したり繰り返したりできます。詳細は、T10000T2 メディア上で中断された「Complete Verify」テストを再開するを参照してください。
注:
このオプションは、T10000T2 メディアでのみ使用できます。T10000T1 メディアの検証は、常にテープの先頭 (BOT) で始める必要があります。T10000T2 メディアの場合、ホストメディアリクエストにより中断されたか、手動で取り消された Complete Verify および Complete Verify Plus 検証は、テープの先頭 (BOT) からやり直すことも、中断されたポイントから再開することもできます。検証を再開するには、前回の検証が中断された位置を、ドライブがメディア RFID から特定できる必要があります。
このオプションは、手動で送信されたリクエストと STA メディア検証ポリシーにより開始されたリクエストの両方で使用できます。手順については、手動メディア検証リクエストの送信および メディア検証ポリシーの作成を参照してください。
注:
前回の検証中断時以降にメディアで発生した読み取り/書き込み操作によっては、検証が有効ではなくなっている可能性があるため、操作を最初からやり直すこともできます。表8-3 に、STA メディア検証の構成に必要なユーザーの役割を示します。
ユーザーの役割 |
メディア検証構成のアクティビティー |
画面 |
---|---|---|
ビューア以上 |
メディア検証ドライブプール内のドライブを表示します。 |
「Tape System Hardware」を選択して、「Drives Overview」を選択します。 |
管理者のみ |
メディア検証ドライブプール内のドライブを表示します。 STA 上でのメディア検証を有効または無効にします。 指定されたメディア論理グループを選択して、ドライブキャリブレーションを有効または無効にします。 |
「Setup & Administration」を選択して、「Media Validation」を選択します。 |
表8-4 に、STA メディア検証リクエストキューの管理に必要なユーザーの役割を示します。
ユーザーの役割 |
メディア検証リクエストキューのアクティビティー |
画面 |
---|---|---|
ビューア以上 |
すべてのメディア検証リクエストのリストを表示、フィルタ処理、および出力します。 メディア検証リクエストのリストをスプレッドシートまたはドキュメントにエクスポートします。選択したメディア検証リクエストの詳細を表示します。 メディア検証リクエストを一度に 1 つ手動で送信します。 保留中のメディア検証リクエストを並べ替えます。 選択した保留中または進行中のメディア検証リクエストを取り消します。 T10000T2 メディアの中断した検証を再開します。 |
「Tape System Activity」を選択して、「Media Validation Overview」を選択します。 |
オペレータ以上 |
複数のメディア検証リクエストを手動で送信します。 複数回中断された T10000T2 メディアの検証を再開します。 |
「Tape System Hardware」を選択して、「Media Overview」を選択します。 |
表8-5 に、STA メディア検証ポリシーの管理に必要なユーザーの役割を示します。
ユーザーの役割 |
メディア検証ポリシーのアクティビティー |
画面 |
---|---|---|
オペレータ以上 |
メディア検証ポリシーのリストを表示および出力します。 |
「Setup & Administration」を選択して、「Media Validation」を選択します。 |
管理者のみ |
メディア検証ポリシーのリストを表示します。 メディア検証ポリシーを定義します。 メディア検証ポリシーを有効または無効にします。 メディア検証ポリシーをコピーします。 メディア検証ポリシーを次のように変更します。
メディア検証ポリシーを削除します。 |
「Setup & Administration」を選択して、「Media Validation」を選択します。 |
この手順を使用して、STA メディア検証の最小要件を満たす検証ドライブの情報を表示します。詳細は、STA で使用可能な検証ドライブを参照してください。
注:
検証ドライブプールの保守には、SL コンソールのみを使用します。プールの保守方法の詳細は、『SL8500 ユーザーズガイド』を参照してください。注:
この手順では、管理者権限が必要です。この手順は、次のいずれかの手法で実行できます。
注:
この手法には、オペレータまたは管理者の権限が必要です。ナビゲーションバーで、「Setup & Administration」を選択して、「Media Validation」を選択します。
画面の「Media Validation Configuration」セクションの「Number of Drives Reserved for Media Validation」フィールドに、検証プールに割り当てられていて、STA 最小要件を満たすドライブの総数が表示されます。リンクを選択します。
これらのドライブの詳細を表示するフィルタが適用済みの「Drives – Overview」画面に移動します。
注:
この手法は、どのユーザーでも実行できます。ナビゲーションバーで、「Tape System Hardware」を選択して、「Drives Overview」を選択します。
「Drives – Overview」画面が表示され、テープライブラリシステム内のすべてのドライブが表示されます。
テーブルツールバーで、「Filter Data」をクリックします。
「Filter Data」ダイアログボックスが表示されます。
選択条件メニューで、「MV Drive Capable」および「True」を選択します。次に「Apply」をクリックします。
テーブルが更新され、検証ドライブプールに割り当てられていて、STA メディア検証の最小要件を満たすドライブだけが表示されます。
この手順を使用して、STA 上でメディア検証機能現在の構成を確認して、有効または無効にします。デフォルトでは、STA のインストール時にはメディア検証は無効になっています。詳細は、メディア検証の有効化およびメディア検証の無効化を参照してください。
注:
有効になっているメディア検証を無効にする場合、STA は新しいメディア検証リクエストを受け入れません。ただし、保留中または進行中のすべてのリクエストは検証キュー内に残り、完了まで処理されます。これらのリクエストを取り消す場合は、メディア検証を無効にする前または無効にしたあとで実行できます。詳細は、保留中または進行中の検証リクエストを取り消すを参照してください。注:
この手順では、管理者権限が必要です。ナビゲーションバーで、「Setup & Administration」を選択して、「Media Validation」を選択します。
「Media Validation」画面が表示されます。
「Media Validation State」フィールドで、次のように「Enable」または「Disable」を選択します。
「Enable」 – STA によりモニターされるすべての SL8500 ライブラリで STA メディア検証を有効にします。
「Disable」 – STA によりモニターされるすべての SL8500 ライブラリで、STA メディア検証を無効にします。メディア検証を一時的に無効にして、ライブラリの保守を実行することもできます。
確認ダイアログボックスが表示されます。
選択を確認して、「Yes」を選択して確定します。
選択に応じて STA のメディア検証状態が更新され、新しいステータスが画面に示されます。この時点でメディア検証を有効にできない場合、理由が画面に示されます。
この手順を使用して、ドライブキャリブレーションと適格性検査に使用するメディアの論理グループを作成します。この論理グループ内のメディアをこの目的専用に確保することが推奨されています。詳細は、キャリブレーションメディア論理グループを参照してください。
注:
これは、オプションの手順であり、使用する必要があるのは、ドライブキャリブレーションと適格性検査を有効にする計画がある場合だけです。注:
この手順を使用する前に、キャリブレーションメディアのみに使用する手動論理グループを作成する必要があります。詳細は、キャリブレーションメディアの選択および手動論理グループの作成を参照してください。注:
この手順では、オペレータ権限または管理者権限が必要です。ナビゲーションバーで、「Tape System Hardware」を選択して、「Media Overview」を選択します。
「Media – Overview」画面が表示され、テープライブラリシステム内のすべてのメディアが表示されます。
テーブルツールバーで、「Filter Data」をクリックします。
「Filter Data」ダイアログボックスが表示されます。
選択条件メニューで、キャリブレーションメディアの選択に指定されている条件を入力し、「Apply」をクリックします。
テーブルが更新されて、条件を満たすメディアだけが表示されます。
「Media MB Avail Post」属性で結果をソートして、書き込まれたデータのラップが 2 つ以上あるメディアを見つけます。
リストから、ドライブキャリブレーションと適格性検査に使用するメディアを選択します。次にテーブルツールバーの「Logical Groups」をクリックします。
「Logical Groups」ダイアログボックスが表示されます。
メニューでキャリブレーションメディア用に作成した論理グループを選択して、「OK」をクリックします。
メディアが論理グループに追加されます。「Logical Groups」画面にこれらを表示できます。手順については、論理グループに割り当てられているすべてのドライブとメディアの一覧表示を参照してください。
この手順を使用して、STA 上でオプションのドライブキャリブレーションおよび適格性検査機能を有効にします。これらの機能は別個のプロセスですが、まとめて有効にしたり無効にしたりできます。
注:
STA メディア検証を使用している場合、ドライブキャリブレーションと適格性検査を有効にすることが強く推奨されています。これらの機能の利点の詳細は、ドライブのキャリブレーションと適格性検査を参照してください。注:
この手順では、管理者権限が必要です。ナビゲーションバーで、「Setup & Administration」を選択して、「Media Validation」を選択します。
「Media Validation」画面が表示されます。
「Use Media From the Following Manual Logical Group for Calibration」メニューで、キャリブレーションと適格性検査に使用するメディアを含む論理グループを選択します。このメニューには、手動論理グループのみが表示されます。
選択を確認し、「Save」をクリックして確定します。
ドライブキャリブレーションと適格性検査が有効になり、STA がメディア検証ドライブグループ内のドライブのキャリブレーションを開始します。
新しいステータスが画面に示されます。キャリブレーションが成功すると、画面にメッセージ「Drive and Media Pool Setup Success--calibration has been successful.」が表示されます。何か問題があれば、それも示されます。
この手順を使用して、STA 上でオプションのドライブキャリブレーションおよび適格性検査機能を無効にします。これらの機能は別個のプロセスですが、まとめて有効にしたり無効にしたりできます。
注:
STA メディア検証を使用している場合、ドライブキャリブレーションと適格性検査を有効にすることが強く推奨されています。これらの機能の利点の詳細は、ドライブのキャリブレーションと適格性検査を参照してください。注:
この手順では、管理者権限が必要です。ナビゲーションバーで、「Setup & Administration」を選択して、「Media Validation」を選択します。
「Media Validation」画面が表示されます。
「Use Media From the Following Manual Logical Group for Calibration」メニューで、「None (Opt out of calibration; not recommended)」を選択します。
選択を確認し、「Save」をクリックして確定します。
「Media Validation Configuration」ダイアログボックスが表示されます。
選択を確認し、「Yes」をクリックしてドライブキャリブレーションと適格性検査の無効化を確定します。
ドライブキャリブレーションが無効化され、STA はキャリブレーションや適格性検査の新規操作を一切開始しません。進行中のキャリブレーションまたは適格性検査アクティビティーは、処理されて完了します。
新しいステータスが画面に示されます。何か問題があれば、それも示されます。
この手順を使用して、保留中、進行中、および完了したメディア検証リクエストの情報を表示します。詳細は、検証リクエストのステータスを表示するを参照してください。
注:
STA でメディア検証が無効になっている場合でも、この手順を使用できます。注:
この手順は、どのユーザーでも実行できます。ナビゲーションバーから、「Tape System Activity」を選択して、「Media Validation Overview」を選択します。
「Media Validation Overview」画面が表示され、STA が情報を受信したすべての検証リクエストが表示されます。
デフォルトでは、リクエストは「1」から始まる Priority Order でソートされるため、もっとも古いリクエストが画面のいちばん上に表示されます。最近のリクエストを表示するには、画面の下部までスクロールするか、「Priority Order」列の「Descending Sort」矢印を選択します。
この画面で、次のいずれかのタスクを実行して、検証リクエストキューを管理できます。
また、「List View」テーブルで実行できるタスクとほぼ同じことを実行できます。手順については、次の手順を参照してください。
テーブルの出力可能なフォームをブラウザの別個のタブまたはウィンドウに表示するには、『STA 画面基本ガイド』を参照してください。
メディア検証リクエストのリストをエクスポートするには、『STA 画面基本ガイド』を参照してください。
表レコードをフィルタするには、「Filter Data」ダイアログボックスを使用したテーブルフィルタの変更を参照してください。
表に適用されたフィルタをリセットするには、現在のフィルタのクリアを参照してください。
テーブルをリフレッシュして新しいリクエストを表示するには、『STA 画面基本ガイド』を参照してください。
テーブルを画面から切り離して、ブラウザフォアグラウンド内の別個のウィンドウに表示するには、『STA 画面基本ガイド』を参照してください。
この手順を使用して、メディア検証リクエストを検証リクエストキューに手動で送信します。この手順は、STA でメディア検証が有効になるとすぐに使用できます。詳細は、手動検証リクエストの送信を参照してください。
この手順を使用して、新しい検証を開始したり、以前に中断した検証を再開したりできます。中断した検証を再開するオプションを使用できるのは、次の条件がすべて満たされる場合だけです。
T10000T2 メディアを検証用に選択していること。(T10000T1 メディア検証は、常にテープの先頭から開始される。)
検証テストのタイプが「Complete Verify」または「Complete Verify Plus」であること。(その他のテストタイプは常にテープの先頭から開始される。)
選択したメディアの一部またはすべてに対して前回実行した検証が、100% 完了していないこと。(前回実行した検証が完了しているメディアは、常にテープの先頭から開始される。)
この手順は、次のいずれかの手法で実行できます。
「Media – Overview」画面から。この手法を使用すると、複数のリクエストキューを一度に送信できます。
「Media Validation Overview」画面から。この手法を使用すると、リクエストを 1 回につき 1 つだけ送信できます。
注:
この手法は、どのユーザーでも実行できます。ナビゲーションバーから、「Tape System Hardware」を選択して、「Media Overview」を選択します。
「Media – Overview」画面が表示され、テープライブラリシステム内のすべてのメディアが表示されます。
適切なフィルタ条件を適用して、メディアのリストを絞り込みます。次の例では、画面が「Library Complex Name Is SL8500_14, and Media Health Indicator Isn't USE」のメディアを表示するようにフィルタ処理されています。
注:
定義済みの STA‐Media‐MV テンプレートでは SL8500 ライブラリ内の T10000 タイプのメディアだけを表示するようにフィルタ処理されるため、これを使用することもできます。検証するメディアを選択します。複数選択を使用して、任意の数のメディアを選択できます。次に、テーブルツールバーの「Media Validation」をクリックします。
「Validation Activities」ダイアログボックスが表示されます。検証に適したメディアの総数がメッセージに示され、適格なメディアがリスト表示されます。メディアが不適格になる理由として、次のいずれかが考えられます。
メディアが T10000 タイプではない。
メディアがクリーニングメディアである。
メディアが SL8500 スタンドアロンライブラリまたはコンプレックス内にない。
ライブラリまたはコンプレックス検証ドライブプール内のドライブが、メディアと互換性がない。
検証ドライブプール内のドライブが、STA メディア検証の最小要件を満たしていない。
注:
選択したメディアのいずれも検証に適していない場合、メッセージ「No valid media selected for validation」が表示されます。「Validation test to run」メニューで、実行する検証テストのタイプを選択します。オプションの詳細については、検証テストの種類を参照してください。
「Complete Verify」または「Complete Verify Plus」を選択した場合、次のオプションのいずれかを選択することも必要な場合があります。これらのオプションを使用できるのは、T10000T2 メディア上で「Complete Verify」または「Complete Verify Plus」検証を実行していて、これらのメディアに対する直前の検証が完了前に中断された場合だけです。
「Perform validations from beginning of tape」 – T10000T2 メディアをテープの先頭 (BOT) から検証することを示します。
「Continue validations from last known validated data point」 – 部分的に検証された T10000T2 メディアを、以前に検証が中断された位置から再開してテストすることを示します (ドライブがメディアの RFID チップからその位置を特定できる場合)。ドライブが以前の検証が中断された位置を特定できない場合は、テープの先頭から開始します。
これらのオプションの詳細は、T10000T2 メディア上で中断された「Complete Verify」テストを再開するを参照してください。
「Drive」メニューで、検証に使用するドライブを選択します。このオプションを使用できるのは、選択したすべてのメディアが同じライブラリコンプレックスまたはスタンドアロンライブラリ内に存在する場合だけです。メニューには、コンプレックスまたはスタンドアロンライブラリ内の検証ドライブがリスト表示されます。
注:
ドライブを 1 台だけ選択しますが、これは、可能な場合にすべてのメディアが同一のドライブにより検証されることを意味します。ドライブが一部のメディアと互換性がない場合 (たとえば、「Complete Verify Plus」の実行を選択したが、一部のメディアが暗号化されており、ドライブが暗号化に対応していない場合)、検証リクエストはリクエストキューに追加されますが、保留中の状態にとどまります。このため、STA がメディアごとに互換性のある検証ドライブを自動的に選択する「Autoselect」を選択することが推奨されています。
「Create」をクリックします。
検証リクエストが生成され、検証リクエストキューに追加されます。
「Media Validation Overview」画面にリクエストを表示できます。手順については、メディア検証リクエストキューの表示を参照してください。
デフォルトでは、各リクエストは、生成時に、次に使用可能な Priority Order に割り当てられます。再優先順位付けの手順については、保留中のメディア検証リクエストの再順序付けを参照してください。
この手法を使用すると、リクエストを 1 回につき 1 つだけ送信できます。複数のリクエストを一度に送信するには、「Media – Overview」画面からを参照してください。
注:
この手法には、オペレータまたは管理者の権限が必要です。ナビゲーションバーから、「Tape System Activity」を選択して、「Media Validation Overview」を選択します。
「Media Validation Overview」画面が表示されます。デフォルトでは、画面は昇順の Priority Order で表示されます。
画面を Volume Serial Number でソートする場合は、その列の「Ascending Sort」または「Descending Sort」矢印を選択します。
リクエストレコードを選択して、検証するメディアを選択します。次に、テーブルツールバーの「Media Validation」をクリックします。
注:
選択できるレコードは 1 回につき 1 つだけで、検証リクエストが保留中または進行中のメディアは選択できません。「Resubmit Media」ダイアログボックスが表示されます。
「Validation test to run」メニューで、実行する検証テストのタイプを選択します。デフォルトでは、このフィールドは「Basic Verify」に設定されていますが、このメディアに適した任意の検証テストを選択できます。オプションの詳細については、検証テストの種類を参照してください。
「Complete Verify」または「Complete Verify Plus」を選択した場合、次のオプションのいずれかを選択することも必要な場合があります。これらのオプションを使用できるのは、T10000T2 メディア上で「Complete Verify」または「Complete Verify Plus」検証を実行していて、メディアに対する直前の検証が完了前に中断された場合だけです。
「Perform validations from beginning of tape」 – T10000T2 メディアをテープの先頭 (BOT) から検証することを示します。
「Continue validations from last known validated data point」 – 部分的に検証された T10000T2 メディアを、以前に検証が中断された位置から再開してテストすることを示します (ドライブがメディアの RFID チップからその位置を特定できる場合)。ドライブが以前の検証が中断された位置を特定できない場合は、テープの先頭から開始します。
これらのオプションの詳細は、T10000T2 メディア上で中断された「Complete Verify」テストを再開するを参照してください。
「Drive」メニューで、検証に使用するドライブを選択します。メニューには、選択したメディアが現在存在するコンプレックスまたはスタンドアロンライブラリ内の検証ドライブがリスト表示されます。
注:
選択したドライブがメディアと互換性がない場合 (たとえば、「Complete Verify Plus」の実行を選択したが、メディアは暗号化されており、ドライブは暗号化に対応していない場合)、検証リクエストはリクエストキューに追加されますが、保留中の状態にとどまります。このため、STA がメディアと互換性のある検証ドライブを自動的に選択する「Autoselect」を選択することが推奨されています。
「OK」をクリックします。
リクエストが生成されて、検証リクエストキューに追加されます。デフォルトでは、これは次に使用可能な Priority Order に割り当てられます。リクエストを再優先順位付けする手順については、保留中のメディア検証リクエストの再順序付けを参照してください。
この手順を使用して、メディア検証リクエストキュー内の保留中のリクエストを再優先順位付けします。詳細は、メディア検証リクエストの優先度を参照してください。
注:
STA でメディア検証が無効になっている場合でも、この手順を使用できます。たとえば、ライブラリを保守するためにメディア検証を無効にしてから、検証キュー内に残された保留中のリクエストを再優先順位付けすることで、メディア検証がふたたび有効になったときに異なる順序で処理されるようになります。注:
この手順は、どのユーザーでも実行できます。ナビゲーションバーから、「Tape System Activity」を選択して、「Media Validation Overview」を選択します。
「Media Validation Overview」画面が表示されます。
デフォルトでは、リクエストは昇順の Priority Order でソートされます。最近のリクエストを表示するには、画面の下部にスクロールします。保留中のリクエストに留意してください。
テーブルツールバーの「Reorder Pending Requests」をクリックします。
「Reorder Pending Requests」ダイアログボックスが表示され、現在の優先順位ですべての保留中のリクエストが示されます。リクエストは、メディアの Volume Serial Number および現在の Priority Order で識別されます。
再優先順位付けするリクエストを選択し、適切な矢印をクリックしてリスト内で移動します。このダイアログボックスでは、複数選択がサポートされています。
矢印 |
説明 |
---|---|
![]() |
選択した項目 (複数可) を 1 回につき 1 つ上または下に移動します。 |
![]() |
選択した項目をリストの一番上または一番下に移動します。 |
リクエストが目的の順序になったら、「OK」をクリックします。
選択に従ってリクエストが再順序付けされ、「Media Validation Overview」画面の「Priority Order」値が更新されて新しい順序が反映されます。
この手順を使用して、1 つ以上の保留中の検証リクエストを取り消します。取り消された保留中のリクエストは、すぐに検証リクエストキューから削除され、再送信することはできません。詳細は、保留中または進行中の検証リクエストを取り消すを参照してください。
注:
STA でメディア検証が無効になっている場合でも、この手順を使用できます。たとえば、ライブラリを保守するためにメディア検証を無効にして、検証キューに残された保留中のリクエストを取り消すことができます。注:
この手順は、どのユーザーでも実行できます。ナビゲーションバーから、「Tape System Activity」を選択して、「Media Validation Overview」を選択します。
「Media Validation Overview」画面が表示されます。
デフォルトでは、リクエストは昇順の Priority Order でソートされます。最近のリクエストを表示するには、「Priority Order」列の「Descending Sort」矢印を選択します。保留中のリクエストに留意してください。
取り消すリクエストを選択し、テーブルツールバーの「Cancel」をクリックします。任意の数の保留中リクエストを選択できます。
注:
完了した検証を選択した場合、「Cancel」ボタンはアクティブになりません。「Cancel」ダイアログボックスが表示され、選択したリクエストのボリュームシリアル番号がリスト表示されています。
ボリュームシリアル番号のリストを確認し、「Yes」をクリックして取り消しを確定します。
リクエストが取り消され、「Media Validation Overview」画面から削除されます。
この手順を使用して、進行中の「Complete Verify」または「Complete Verify Plus」メディア検証を 1 つ以上取り消します。進行中のほかの検証タイプを取り消すことはできません。詳細は、保留中または進行中の検証リクエストを取り消すを参照してください。
注:
STA でメディア検証が無効になっている場合でも、この手順を使用できます。たとえば、ライブラリを保守するためにメディア検証を無効にして、検証キューに残された進行中の「Complete Verify」リクエストを取り消すことができます。注:
この手順は、どのユーザーでも実行できます。ナビゲーションバーから、「Tape System Activity」を選択して、「Media Validation Overview」を選択します。
「Media Validation Overview」画面が表示されます。
デフォルトでは、リクエストは昇順の Priority Order でソートされます。最近のリクエストを表示するには、「Priority Order」列の「Descending Sort」矢印を選択します。進行中の検証に留意してください。
停止する検証を選択して、テーブルツールバーの「Cancel」をクリックします。進行中の「Complete Verify」または「Complete Verify Plus」検証を任意の数だけ選択できます。
注:
完了した検証を選択した場合、「Cancel」ボタンはアクティブになりません。「Cancel」ダイアログボックスが表示され、選択した検証のボリュームシリアル番号が示されます。
表示された情報を確認し、「Yes」をクリックして取り消しを確定します。
STA が取り消しリクエストをドライブに発行します。このプロセスは、完了まで数分かかる場合があります。各メディアがドライブからマウント解除され、メディアスロットに戻されたら、関連する検証リクエストが「Media Validation Overview」画面から削除されます。
この手順を使用して、メディア検証ポリシーを作成します。メディア検証ポリシーを使用すると、テープライブラリシステム内のメディア検証を自動化できます。詳細は、自動メディア検証の使用を参照してください。
「Media Validation Policies」ウィザードを使用すると、ポリシーに関するすべての情報を段階を追って定義できます。
注:
この手順では、管理者権限が必要です。ナビゲーションバーで、「Setup & Administration」を選択して、「Media Validation」を選択します。
「Media Validation Policies」画面が表示されます。
「New Media Validation Policy」をクリックします。
次のようにウィザードの最初の画面に入力します。
「Policy Name」フィールドに、一意の名前を入力します。
入力には、長さ 250 文字までの英数字を含めることができます。
「Policy Description」フィールドに、ポリシーのオプションの説明を入力します。
「Next」をクリックします。
注:
ウィザードの任意の画面で、画面上部にあるブレッドクラムリンクを選択して、すぐ次の画面や、すでに表示した画面に直接移動できます。ウィザードの 2 番目の画面で、次のようにして、このポリシーで検証するメディアグループを指定します。
このポリシーで、特定の記録フォーマットの (オプションで特定のライブラリコンプレックス内の) メディアを検証する場合は、「Select media format and optional library complex」オプションを選択し、次の方法で関連するフィールドを指定します。
「Media Format」メニューで、このポリシーで検証するメディアの記録フォーマットを選択します。任意の数のフォーマットを選択できます。オプションは、T10000T1 メディアで使用可能な「T10000A」と「T10000B」、および T10000T2 メディアで使用可能な「T10000C」と「T10000D」です。
「Library Complex (Optional)」メニューで、このポリシーで検証するライブラリコンプレックスを選択します。「None」を選択した場合、ポリシーはすべてのコンプレックスで指定されたメディアタイプを検証します。ライブラリコンプレックスを選択した場合、ポリシーはそのコンプレックス内部のメディアだけを検証します。
このポリシーで特定の定義済み論理グループ内のメディアを検証する場合は、「Select logical group」オプションを選択します。「Logical Group」メニューで、論理グループを選択します。メニューに、定義されたすべての論理グループがリスト表示されます。
注:
検証ドライブのある SL8500 コンプレックスまたはスタンドアロンライブラリ内に T10000 メディアを含む論理グループを選択してください (STA ではこれは確認されないため)。「Next」をクリックします。
次の方法で、ウィザードの 3 番目の画面を完了します。
「Policy Criteria」メニューで、検証用メディアを選択する条件を選択します。オプションの説明については、検証ポリシーの選択条件を参照してください。
選択によっては、次に示す追加フィールドを指定する必要があります。
「Media Health = Action, Evaluate, or Monitor」を選択した場合は、メディアを検証用に選択する前に発生する必要のある、連続した「Number of exchanges」も指定する必要があります。オプションは 1 – 5 です。たとえば、「2」を指定した場合、指定されたメディアの健全性の連続した交換が 2 回発生するとすぐに、メディアが検証用に選択されます。
「Extended period of non-use」を選択した場合、「Number of days」も指定する必要があります。オプションは、365 – 1095 (1 - 3 年) です。たとえば、「730」を指定した場合、前回の交換から 730 日以上が経過すると、メディアが検証用に選択されます。
「Validation Test Type」メニューで、ドライブで実行する検証テストのタイプを選択します。オプションの説明については、検証テストの種類を参照してください。
「Complete Verify」または「Complete Verify Plus」を選択した場合は、次のオプションのいずれかも選択する必要があります。
注:
これらのオプションは、T10000T2 メディアにのみ適用されます。T10000T1 メディアの検証は、常にテープの先頭 (BOT) から始める必要があります。「Perform validations from beginning of tape」 – メディアが部分的に検証済みである場合でも、すべての T10000T2 メディアをテープの先頭 (BOT) からテストすることを示します。
「Continue validations from last known validated data point」 – 部分的に検証された T10000T2 メディアを、以前に検証が中断された位置から再開してテストすることを示します (ドライブがメディアの RFID チップからその位置を特定できる場合)。ドライブが以前の検証が中断された位置を特定できない場合は、テープの先頭 (BOT) から開始します。
これらのオプションの詳細は、T10000T2 メディア上で中断された「Complete Verify」テストを再開するを参照してください。
「Next」をクリックします。
次のようにウィザードの最後の画面に入力します。
すべてのポリシー情報が正しいことを確認します。
次の方法で、「Enable Policy」チェックボックスを指定します。
チェックボックスを選択すると、ポリシーを作成してただちに有効化します。
ポリシーを作成するが、とりあえず無効にしておく場合に、このチェックボックスを選択します。あとで有効にできます。手順については、メディア検証ポリシーの有効化または無効化を参照してください。
「Save」をクリックします。
ポリシーが作成されます。このポリシーが有効な場合、STA はすぐにポリシーに基づいてメディアの評価を開始し、必要に応じてメディア検証リクエストを生成します。
ポリシーが無効になっている場合、現在のところポリシーは評価されません。
この手順を使用して、すべての STA メディア検証ポリシーの情報を表示します。
注:
これらの手順では、オペレータまたは管理者の権限が必要です。ナビゲーションバーで、「Setup & Administration」を選択して、「Media Validation」を選択します。
「Media Validation Policies」画面が表示されます。定義されたポリシーが、「Media Validation Policies」セクションにリスト表示されます。
この画面から、次のいずれかのタスクを実行して検証ポリシーを管理できます。
また、「List View」テーブルで実行できるタスクとほぼ同じことを実行できます。手順については、次の手順を参照してください。
テーブルの出力可能なフォームをブラウザの別個のタブまたはウィンドウに表示するには、『STA 画面基本ガイド』を参照してください。
メディア検証ポリシーのリストをエクスポートするには、『STA 画面基本ガイド』を参照してください。
表レコードをフィルタするには、「Filter Data」ダイアログボックスを使用したテーブルフィルタの変更を参照してください。
表に適用されたフィルタをリセットするには、現在のフィルタのクリアを参照してください。
テーブルをリフレッシュして新しいポリシーを表示するには、『STA 画面基本ガイド』を参照してください。
テーブルを画面から切り離して、ブラウザフォアグラウンド内の別個のウィンドウに表示するには、『STA 画面基本ガイド』を参照してください。
この手順を使用して、選択したメディア検証ポリシーを有効または無効にします。STA は、有効なポリシーだけを使用して自動化されたメディア検証リクエストを生成します。詳細は、自動メディア検証の使用を参照してください。
ポリシーを無効にしても、そのポリシーから生成された保留中または進行中のメディア検証リクエストに影響はありません。これらは、取り消さないかぎり、完了するまで処理されます。
注:
この手順では、管理者権限が必要です。ナビゲーションバーで、「Setup & Administration」を選択して、「Media Validation」を選択します。
「Media Validation Policies」画面が表示されます。
変更するポリシーを選択します。
ポリシーが現在有効である場合、「Media Validation Policies」ツールバーの「Disable Media Validation Policy」アイコンがアクティブになります。ポリシーが現在有効でない場合、「Enable Media Validation Policy」アイコンがアクティブになります。
「Enable Media Validation Policy」または「Disable Media Validation Policy」のうち、適用されるものをクリックします。
ポリシーは、選択内容に応じて更新されます。
このポリシーを有効にしている場合、STA はすぐにポリシー条件に基づいてメディアの評価を開始し、必要に応じてメディア検証リクエストを生成します。
このポリシーを無効にしている場合、STA はポリシーのメディア検証リクエストを生成しなくなります。保留中または進行中のメディア検証リクエストは、取り消さないかぎり、完了するまで処理されます。詳細は、保留中または進行中の検証リクエストを取り消すを参照してください。
この手順を使用して、選択したメディア検証ポリシーをコピーします。ポリシーを新しいポリシーのベースとして使用するには、作成したいポリシーに近い既存のポリシーをコピーして、コピーを変更できます。手順については、メディア検証ポリシーを変更するを参照してください。
注:
この手順では、管理者権限が必要です。ナビゲーションバーで、「Setup & Administration」を選択して、「Media Validation」を選択します。
「Media Validation」画面が表示されます。
コピーするメディア検証ポリシーを選択して、「Copy Media Validation Policy」をクリックします。
「Media Validation Policies」ウィザードの最初の画面が表示されます。ポリシーのコピーには、次の点を除きオリジナルと同じすべての情報が含まれています。
「Copy」という単語が「Policy Name」の最後に追加されます。
ポリシーが有効になっています (「Enable Validation Policy」チェックボックスが選択されています)。
「Policy Name」フィールドに割り当てる名前を入力し、必要に応じて「Policy Description」を変更します。
「Next」ボタン、またはダイアログボックスの上部にあるウィザードのブレッドクラムを使用して、変更する情報がある画面に移動します。これらの画面の指定手順については、メディア検証ポリシーの作成を参照してください。
完了したら、「Save」をクリックします。
新しいポリシーが作成され、その情報で「Media Validation Policies」画面が更新されます。
次の例では、「STA‐T10000B non‐used」ポリシーが「STA‐T10000A non‐used」ポリシーからコピーされ、ポリシー条件が T10000B メディアに合わせて変更されています。
この手順を使用して、選択したメディア検証ポリシーを変更します。ポリシーの任意の属性を変更できます。
注:
ポリシーを有効または無効にするより直接的な手法については、メディア検証ポリシーの有効化または無効化を参照してください。注:
この手順では、管理者権限が必要です。ナビゲーションバーで、「Setup & Administration」を選択して、「Media Validation」を選択します。
「Media Validation Overview」画面が表示されます。
変更するメディア検証ポリシーを選択して、「Edit Media Validation Policy」をクリックします。
「Media Validation Policies」ウィザードの最初の画面が表示され、ポリシーの現在の情報が示されます。
「Next」ボタン、またはダイアログボックスの上部にあるウィザードのブレッドクラムを使用して、変更する情報がある画面に移動します。これらの画面の指定手順については、メディア検証ポリシーの作成を参照してください。
完了したら、「Save」をクリックします。
ポリシーが更新され、変更が「Media Validation Policies」画面に表示されます。
この手順を使用して、メディア検証ポリシーを削除します。ポリシーを削除しても、そのポリシーから生成済みのメディア検証リクエストは削除されません。これらは、引き続き「Media Validation Overview」画面に表示できます。ポリシーから生成された保留中および進行中のリクエストは、完了するまで処理されます。
メディア検証ポリシーを削除する前に無効にする必要はありません。
注:
この手順では、管理者権限が必要です。ナビゲーションバーで、「Setup & Administration」を選択して、「Media Validation」を選択します。
「Media Validation Policies」画面が表示されます。
削除するメディア検証ポリシーを選択して、「Delete Media Validation Policy」をクリックします。
「Delete」ダイアログボックスが表示されます。
選択を確認して、「Yes」をクリックして削除を確認します。
ポリシーが削除され、「Media Validation Policies」画面のリストが更新されます。