4 VTCS ダッシュボードの使用

「VTCS ダッシュボードの使用」とは、基本的に MVC レポートと VTC レポートを確認することです。仮想テープ構成の主要なコンポーネントは VTSS、VTD、VTV、RTD、および MVC であるため、当然のように、日次または週次の多数のルーチンがこれらすべてを正常に稼働させるために実行されています。

仮想テープのステータスの確認 (日次)

VTSS を Nearline ACS の仮想物、VTD を Nearline の実テープドライブの仮想機能、および VTV を Nearline ボリュームの仮想物と考えると、VTSS、VTD、および VTV のすべてが正常に稼働していることを確認することが重要である理由がよくわかります。

Virtual テープのステータスを確認するには、次のことを実行します。

  1. Display VTSS コマンドを入力します。

    表4-1 のような表が表示されます。

    表4-1 Display VTSS からの出力例 - 正常な VTSS のステータス

    VTSS 名 容量 (MB) DBU 上限 AMT 下限 AMT VTV カウント MX MT MN MT DEF ACS AUTO MIG 状態

    HBVTSS16

    56,209

    55

    80

    60

    2440

    6

    3

    02

    -

    ONLINE

    HBVTSS17

    56,209

    50

    80

    60

    2180

    6

    3

    02

    -

    ONLINE

    HBVTSS18

    56,209

    52

    80

    60

    2288

    6

    3

    01

    -

    ONLINE

    HBVTSS19

    93,184

    45

    80

    60

    1900

    6

    3

    01

    -

    ONLINE

    表4-1 は、「正常に稼働している」4 つの VTSS のステータスを示しています。

    • まず、すべての VTSS はオンラインで、通常はこれが正常です。

    • LAMT はすべてが 60、HAMT はすべてが 80 です。これは、VTSS の使用率を最適化し、効果的な自動移行を促進するのに適した範囲です。

    • DBU はすべて HAMT より低い値で、正常です。これは、自動移行が開始されるまでに、VTSS に拡張する余地があることを意味します。これらの VTSS により多くの作業をルーティングして、仮想テープへの投資の最適化を検討することも可能です。

    • 各 VTSS に 8 台 の RTD が接続されているとします。MX MT (最大移行タスク) は 6 に設定され、MN MT (最小移行タスク) は 3 に設定されます。これは適切な数値です。最大の 6 は 2 つの RTD をリコール/リクレイムに残し、最小の 3 は複数の移行が一度に開始された場合に、その負荷を処理できるだけのタスクを確保します。

    Display VTSS が正常でないと思われる場合は、表4-2 のようになります。

    表4-2 Display VTSS からの出力例 - 運用上の大きな問題がある VTSS

    VTSSNAME 容量 (MB) DBU 上限 AMT 下限 AMT VTV カウント MX MT MN MT DEF ACS AUTOMIG 状態

    HBVTSS16

    56,209

    90

    80

    60

    27,888

    4

    2

    02

    -

    ONLINE

    HBVTSS17

    56,209

    92

    80

    60

    28,974

    4

    2

    02

    -

    ONLINE

    HBVTSS18

    56,209

    90

    80

    60

    22,005

    4

    2

    01

    -

    ONLINE

    HBVTSS19

    93,184

    92

    80

    60

    26,009

    4

    2

    01

    -

    ONLINE

    表4-2 は、大きな運用上の問題がある 4 つの VTSS のステータスを示しています。

    • 少なくともそれらはすべてオンラインです。そうでない場合、オフラインまたは保守モードにする理由がないかぎり、Vary VTSS コマンドを入力してオンラインに戻します。

    • DBU の値はいずれも大きすぎます。90 以上の範囲は VTSS による VTV の自動移行に支障があることを意味しており、これは、次の理由から驚くことではありません。

    • 各 VTSS に 8 台 の RTD が接続されているとします。MX MT (最大移行タスク) は 4 に設定され、MN MT (最小移行タスク) は 2 に設定されていますが、これは現在の移行の負荷を考えるとたしかに少し軽くなっています。

      問題を解決するには、手順 2 に進みます。

  2. 手順 1 で確認した内容が好ましくない場合は、現在の動作パラメータを調整します。

    まず、移行タスクの量を増やします。

    set migopt vtss(vtssname) maxmig(8) minmig(8) high(70) low(40)

    これで、すべての VTSS 上で、すべての RTD が移行に関与するようになりました。DBU が管理可能になるまでこの状態を維持します。そのあと、最大 6、最小 3 などに戻します。また、AMT を低い値は 40、高い値は 70 に変更します。これによって問題は解決し、次回から移行がすぐに開始され、バッファーが低い DBU に当てられるようになります。

    次に、Display VTD を入力して、システムの VTD の概要を取得します。

    表4-3 に Display VTD の出力例を示します。

    表4-3 Display VTD の出力例 - 正常な稼働

    ドライブ LOCATION VTV ステータス

    A800

    HBVTSS16

    X00778

    MOUNTED

    A801

    HBVTSS16

    X00775

    MOUNTED

    A802

    HBVTSS16

    -

    AVAILABLE

    A803

    HBVTSS16

    -

    AVAILABLE

    表4-3 で、ふたたび正常な状態に戻り、いくつかの VTD が使用中で、そのほかは使用可能な状態になっています。

    すべての VTD で、VTV がマウントされている場合はどうでしょうか。これは、利用できるドライブがない場合にジョブ割り振りエラーの危険があるため、適切だとは言えません。これが、手順 2 で発生したような問題であるなら、それを受け入れ、あとで VTD データの流入をうまく処理できるようにワークロードを調整するだけでかまいません。しかし、これが長期間に及ぶ問題である場合は、VTSS を追加したり、より大きな容量と多くの VTD を持つ VTSS にアップグレードしたりする必要があります。

  3. ここで、表4-4 に示されている出力を生成する Display SCRATCH コマンドを入力して、十分なスクラッチ VTV が手元にあることを確認します。

    表4-4 Display SCRATCH の出力例

    サブプール名 スクラッチカウント

    VIR000

    14,364

    VIR0002

    13,582

    VIRTUAL

    19,132

    VIRTUAL1

    9,905

    表4-4 に表示されているのは、HSC サブプールの VTV スクラッチカウントです。VTV に HSC サブプールを使用しない場合、システムに定義されているすべての VTV の VTV スクラッチカウントが表示されます。スクラッチカウントには、利用できるスクラッチ VTV がいくつかあるかぎり、適正または不適正な数値というのはありません。「利用できるスクラッチの適正数値」は、システム環境のニーズとワークロードによって変わります。

    表4-4 に各サブプールで使用できるスクラッチが 50 以下と表示されたとしたら、少し心配になるかもしれません。その場合、次の 1 つまたは複数のことを実行できます。

    • データが最新でない VTV をスクラッチすることにより、VTV の VOLSER を解放する。これは、システム内の VTV の合計が十分であるのに、利用できるスクラッチボリュームが十分でない場合に行う手段です。

      実際は、スクラッチを行うのはユーザーではなく、この処理を実行するように設定されている TMS であるため、初期構成で、VTV の VOLSER を TMS に定義しておくべきです。定義しなかった場合は、戻って定義します。それよりも、VTCS CONFIG 文で VTV の範囲を追加したのに、新しい範囲を TMS に追加するのを忘れている可能性の方が高いでしょう。この場合も、戻って問題を修正します。これについては、『ELS のインストール』ですべて説明されます。

      ただし、TMS で VTV をスクラッチとしてマークすることは解決の一部でしかありません。このほかにも、VSM 管理者のだれかが VTV データを最新でない (そのため書き込み可能) とマークし、それが VTSS 常駐の VTV の場合はそれらをバッファーから削除しています。

      VTV データを実際に削除することは重大な決定であるため (データは消去されます) そのつど判断します。これを「要求時」タスクと言います。そのため、このルーチンを行う場合は、「MVC スペースリクレイムの実行」を参照してください。

    • POOLPARM または VOLPARM を使用して VTV を追加する。これは、次善の選択肢です。最新でないデータのある VTV がまったくない場合は、これを実行します。POOLPARM または VOLPARM だけで解決しない場合は、適切な TMS の定義なども行う必要があります。これについても、『ELS のインストール』ですべて説明されます。

    • TAPEREQ 文または SMS ルーチンを変更し、追加の VTV を定義するまでの間、テープ作業を一時的に Nearline の HSC 処理に転送する。これは本質的に、もともと VSM に送信しようとしていたデータを Nearline テープに直接送信することになり、あとの処理も簡単ではないため、おそらく最後の選択肢になります。それでも、利用できる Nearline リソースがあり、スクラッチボリュームにデータを書き込む緊急の必要性がある場合、これが (一時的に) 取るべき方法となります。

Nearline テープのステータスの確認 (日次)

「仮想テープのステータスの確認 (日次)」では、システムの VTSS、VTD、および VTV を正常に稼働させることの重要性について説明しました。

VSM の Nearline コンポーネント (RTD および MVC)、VTV の移行先とリコール元、そしてバックグラウンドで実行される MVC スペースリクレイムを考えると、この部分に十分な注意を払う価値があることがわかるでしょう。

Nearline テープのステータスを確認するには、次のことを実行します。

  1. Display RTD を入力します。

    適切な状態の場合、表4-5 のようになります。

    表4-5 VT Display RTD コマンドの出力例 - すべてが良好

    RTD ステータス マウント 割当 ホスト VTSS

    B200

    ONLINE/FREE

    -

    -

    -

    HBVTSS16

    B201

    ONLINE/FREE

    -

    -

    -

    HBVTSS16

    0B79

    ONLINE/FREE

    -

    -

    -

    HBVTSS16

    0B7A

    RECALL VTV

    DMV051*

    DMV051

    EC20

    HBVTSS16

    1600

    MVS1 :MIGRATE

    -

    -

    -

    -

    1601

    MVS1 :MIGRATE

    -

    -

    -

    -

    表4-5 では、RTD の移行、リコール、そして新しい作業用のバランスが良いため、処理が滞りなく実行されます。表4-6 ではそうなりません。

    表4-6 VT Display RTD コマンドの出力例 - RTD に問題

    RTD ステータス マウント 割当 ホスト VTSS

    B200

    MVS1 :MIGRATE

    -

    -

    -

    -

    B201

    MVS1 :MIGRATE

    -

    -

    -

    -

    0B79

    MVS2 :MIGRATE

    -

    -

    -

    -

    0B7A

    MVS2 :MIGRATE

    -

    -

    -

    -

    1600

    MVS1 :MIGRATE

    -

    -

    -

    -

    1601

    MVS1 :MIGRATE

    -

    -

    -

    -

    表4-6 が手順 2 で行なった一種の緊急手段の結果である場合は、状態が正常に戻るまで待つほかありません。しかし、利用できる RTD がほかにある場合、たとえば MVS および VSM と手動で共有している RTD がある場合は、それらを MVS に対してオフラインにして、Vary RTD を使用し、それらを VTCS に対して利用可能にします。

  2. 次に、Display MVCPool コマンドを使用して、MVC の状態を確認します。

    図4-1 は、MVC プール名が指定されていない Display MVCPool の出力を示しているため、システムのすべての MVC 情報が参照できます。

    図4-1 Display MVCPool からの出力例 (プール名の指定がない場合)

    図4-1 の説明が続きます
    説明: 図4-1 Display MVCPool からの出力例 (プール名の指定がない場合)

    図4-1 は、MVC コレクションが正常な状況であることを示しています。複数の ACS と MVC メディアタイプに、十分な空き MVC (100% 利用可能なスペース、移行された VTV を含まない) と十分な空き容量があります。リクレイムに選択可能な MVC の数は比較的少なく、自動スペースリクレイムが移行/リコール処理の邪魔にはならないだろうことを意味しています。

    使用済み MVC は、空き MVC に対して問題ないようですが、ACS 01 の ECART、ZCART メディアには問題があります。これらの MVC について、少し調べてみましょう。これらの MVC を表すストレージクラスと、これらのストレージクラスに対応するマネージメントクラス、いくつかの VTV をスクラッチした可能性のあるマネージメントクラスを調べます。

    Display MVCPool の結果、図4-2 のように表示された場合はどうでしょうか。

    図4-2 Display MVCPool からの出力例 - ACS01 で問題

    図4-2 の説明が続きます
    説明: 図4-2 Display MVCPool からの出力例 - ACS01 で問題

    ご覧のように、ACS 01 で状況が悪くなっています。ここで何をすべきでしょうか。次のことを順番に検討します。

    • 要求リクレイムを実行して、スペースを解放します。詳細については、「MVC スペースリクレイムの実行」を参照してください。

    • 「RTD デバイスタイプの変更」の説明のように、MVC を追加します。

    • これらの MVC を表すストレージクラスと、これらのストレージクラスに対応するマネージメントクラス、いくつかの VTV をスクラッチした可能性のあるマネージメントクラスを調べます。

      フォローアップとして、現在のポリシーを再検討し、必要に応じて調整します。これらのポリシーを変更すると、空き MVC か、または MVC 上に空きスペースを作成できる場合があります。

概要の把握 (週次)

これはそれほど複雑ではなく、基本的にほかの主要な 2 つのステータス確認用ツール (MVC レポートおよび VTV レポート) を週次で実行することから構成されます。

VTV レポートの使用

注記:

VTV レポートは、次のいずれかのコマンドを使用して実行します。

  • VTVRPT BASIC。EXPORT コマンドを使用して MVC に移行されたすべての VTV コピーを表示します

  • VTVRPT COPIES。EXPORT コマンドを使用して MVC に移行されたすべての VTV コピーと、EEXPORT コマンドによって移行されたすべての VTV コピーを表示します

まず、VTV レポートは図4-3 のように表示されます。

図4-3 VTVRPT の出力例

図4-3 の説明が続きます
説明: 図4-3 VTVRPT の出力例

VTV レポートは一見すると膨大で、直感的ではないように見えます。システム内にある各 VTV を確認するために必要なすべてのデータが、多数の行に出力されています。

VTV レポートを各自の状況でより便利に活用するにはどうすればよいでしょうか。まず、VOLSER のリスト、VOLSER の範囲または個々の VOLSER に対して VTVRPT ユーティリティーを実行できます。検証したい特定の VTV がある場合は、これらの選択方法のいずれかを使用してください。

次に、VTVRPT ユーティリティーで OPTION(UNAVAIL) パラメータも指定できます。これは、図4-4 のように、利用できない VTV のレポートを生成します。

図4-4 VTVRPT (UNAVAIL オプション) からの出力例

図4-4 の説明が続きます
説明: 図4-4 VTVRPT (UNAVAIL オプション) からの出力例

常駐していると考えている VTV にアクセスできないジョブ (または VTCS) のレポートがあった場合は、明らかに OPTION(UNAVAIL) が最善の選択肢です。

また、VTVRPT ユーティリティーの XML 出力が持つ柔軟性を活用できます。選択したレポートおよびユーティリティーに対して、構造化 XML またはカンマ区切り (CSV) XML の出力を生成できます。

構造化 XML と CSV の出力にはどのような違いがあるのでしょうか。次のことを考えてみます。

  • 構造化 XML には、各コマンドまたはユーティリティーに示されるすべてのタグと構造が含まれています (選択したプログラミング言語を使用して、必要に応じて処理できます)。

  • CSV 出力を利用すると、必要なタグ (および順番) だけを選択できます。各出力行には、固定数のフィールドがカンマで区切られていて、それをスプレッドシートやレポートライターに入力して、カスタマイズ後に分析したりレポートにしたりできます。

システム環境のニーズに応じて基本的な VTV レポートを効果的にカスタマイズできる方法が 2 つあります。このトピックの詳細については、『ELS プログラミングリファレンス』を参照してください。

最後に、LCM は、VTCS MVC および VTV レポートを含む ELS/VTCS 機能に対応した拡張管理機能とレポート機能を提供します。詳細については、「LCM 制御文」を参照してください。

MVC レポートの使用

最後に、MVC サマリーレポートを見ていきます。これは、図4-5 のようになります。

図4-5 MVC サマリーレポートの例

図4-5 の説明が続きます
説明: 図4-5 MVC サマリーレポートの例

MVC サマリーレポートは、標準の VTV レポートと非常によく似ています。探しているものが明確であれば有用ですが、おそらく明確でないと情報が多すぎるでしょう。

MVC 詳細レポートから得られる追加フィールドは、より詳細な概要を得るのに役立ちます。図4-6 に注目してください。

図4-6 MVC 詳細レポートの例 (追加フィールド)

図4-6 の説明が続きます
説明: 図4-6 MVC 詳細レポートの例 (追加フィールド)

次は、必要な場合に診断作業に利用できる、MVC 上の VTV に関する詳細情報です。

VTV レポートで利用できるようになったように、MVC レポートでも次のいずれかを実行できます。

  • 構造化 XML またはコンマ区切り (CSV) XML で出力を作成できます。詳細は、『ELS プログラミングリファレンス』を参照してください。

  • 対応する LCM レポートを使用できます。「LCM 制御文」を参照してください。

サマリー

これまで、VTCS ダッシュボードの使用方法について説明してきました。Named MVC プールを使用する場合の MVC プールレポートの実行など、ほかにも実行可能な (おそらく、今後実行可能になる予定の) タスクは数多くあります。ただし、これは「要求時」管理タスクに関する情報です。

この章で重要な点は、仮想テープのステータスの確認 (日次)とNearline テープのステータスの確認 (日次)で説明されている日次処理、「概要の把握 (週次)」で説明されている週次処理、および VTCS システムを適正に実行し続けることです。