text：高田 新 日本アイ・ビー・エム システムズ・エンジニアリング
本稿では、z/OS環境においてディスク容量の効率的利用を推進するCKD（*）シンプロビジョニング機能について、その概要と利点・効果、利用に必要な作業概要と使用上のポイントを解説する。
（*）CKD: Count Key Dataの略で分散系のディスク・フォーマットに対してメインフレーム系で使用されるディスク・フォーマット
当シンプロビジョニング機能自体は、2016年に出荷されたDS8000のR8.1以降（現時点の機種モデルとしてはDS8880、DS8900F）のz/OS環境で利用可能となっていたが、実際の利用は一部のシステム環境にとどまっていた。
しかしながら、その後の機能拡張や世の中のFlashドライブの浸透により、今では当機能採用のハードルが下がってきていると、筆者は考えている。以降、機能概要や利点の解説の後、これらの点に触れていきたいと思う。
シンプロビジョニング機能とは
シンプロビジョニング機能は、分散系システム環境ではすでに利用が進んでいる技術分野なのでご承知の読者も多いと思うが、まずは、その機能の概要を説明する。
シンプロビジョニング（以下、シンプロ）機能は、z/OSなどのサーバーOSからは一定量のディスク容量が認識されているが、ディスク装置上は、その容量はその時点では確保されず、ディスク装置上に容量が確保されるのは、サーバーOSからデータが書き込まれた時点で行われるという機能である。
当機能により、実際に書かれたデータの容量のみがディスク装置において消費されるため、ディスクの未使用容量の削減が可能となる。一般的には、ボリューム単位やグループ単位のデータ量増大への備えとして、一定量の未使用容量は、システムの運用上確保せざるを得ない。シンプロ機能は、この未使用容量をディスク装置全体で確保することにより、全体量を削減できる機能である。
シンプロ機能の具体的な動きを図表1で解説する。
シンプロとして定義したディスク上の1ボリューム（以下、シンプロ・ボリューム）は、z/OSのLISTVTOCやISPF 3.4でVTOC（Volume Table of Contents）の容量を見ると、たとえば3390-9型であれば、10017シリンダーの容量が存在するように見える（図中左のボリューム。灰色部分）。この時、このボリュームに100シリンダー分のデータが書かれると、DS8000上では、100シリンダー分のディスク容量しか消費されない（図中右のオレンジ色の部分）。データが書き込まれていない残りの約9900シリンダー分の容量は利用可能なエリアとして残っている状態となる（図中右の緑色部分）。これが、シンプロ環境の状態である。
もう少しz/OS環境に踏み込んで解説してみよう。
1000シリンダーのデータセットをシンプロ・ボリュームとして設定し、まだデータの書き出しを行っていない段階を考えてみる。この段階では、作成されたデータセットの情報を持つために、VTOCとVTOCインデックスが更新されるのみである。
VTOCやVTOCインデックスは、ボリュームの初期化時にフォーマットされ、その段階でその容量はDS8000上で消費されている。よって、この段階では、DS8000上のディスク容量は消費されていない。次に、該当のデータセットに100シリンダー分のデータが書き込まれたとする。その時点で、DS8000上のディスク容量も100シリンダー分が消費される。なおDS8000では、ボリュームを定義する時にシンプロ機能の使用の有無を指定する。
シンプロ機能の利点・効果
図表2を用いて、シンプロ機能の具体的な利点・効果を説明しよう。
現在の典型的なディスク容量の割り当て状況を、青の点線の非シンプロ構成の場合の箇所で示す。業務開発部門は、業務ごとにある程度の余裕をもってディスク管理部門に必要容量の割り当てを依頼する。結果として、たとえば、業務Aについて、10TBの割り当てが行われる。業務Aの稼働後、実際には5TBが使用されたが、残り5TBは未使用の状況となる。業務Bも同様に20TBの割り当てが行われ、実際には15TBが使用され、5TBは未使用となる。
先に述べたように、一般的に、ディスク装置はボリューム単位またはそのグループ単位で、データ量増加への対応としてある程度の空き容量を確保する運用となることが多い。そのため、空き容量は分散されて確保されることとなり、結果、未使用容量の増大を招くこととなる。
さらに、ディスク管理部門は、今後の容量依頼への備えとして10TBの予備ディスク容量を確保している。業務Aと業務Bはそれぞれの未使用容量を共有することはなく、それぞれの業務で容量不足が予想されると、管理部門に追加の容量割り当てが依頼されることとなる。
一方、シンプロ構成の場合（赤の点線）、業務Aおよび業務Bの未使用容量は、管理部門の予備容量とともに共有された全体の予備容量となる。当例では、20TBの予備容量が確保されている。シンプロ環境では、予備容量を業務ごとではなく、全体で確保することになるため、予備容量を不要に多く確保する必要がなくなる。この点がシンプロ機能の利点・効果となる。
非シンプロ環境において、現在どれくらいの未使用領域が使用中のz/OSシステム環境にあるかは、z/OS IDCAMSのDCOLLECTコマンドとDFSORTのICETOOLを使用すれば簡単に把握できる。図表3は、その出力を行うサンプル・ジョブである。このサンプルではVOLSERがST98で始まるボリューム群についての未使用容量（この例では、データセットが作成されていないエリアを未使用容量としている）を出力する。
図表4がその出力例となり、FREE（MB）のTOTAL行で全体の容量を把握できる。ある本番システム環境では、全体のディスク容量の半分程度しかデータセットが割り振られていなかった例もあり、一度調査してみる価値はあるだろう。
シンプロ機能採用に関する以前の懸念事項とその現状
上述のようにディスク容量の効率的利用を可能とするシンプロ機能だが、当機能が最初に使用可能となった時点では、比較的大きな懸念事項として下記の2つがあった。
・業務I/Oパフォーマンスへの影響
・Global Mirrorなどのディスク災害対策機能との併用
この2つの懸念事項について現状を以下に述べる。
1つ目のパフォーマンスへの影響については、ミッションクリティカルな業務が稼働するz/OS環境では特に大きな懸念事項であった。これについては、ディスク装置に搭載される物理ドライブがFlashドライブとなることで解消すると考えてよい。
図表5に示すように、ハード・ディスク・ドライブ（図中、HDDと表記した一番左の値）では、シンプロ機能を使用したボリュームへの高負荷書き出しジョブの処理速度は、シンプロ機能を使用しない場合と比べると、1/1.7程度に低くなっている。これは、シンプロ環境ではデータの書き出し場所が事前に決まっていないため、書き出し処理時に書き出し場所の記録処理がディスク装置内で行われるためである。
ところが、同じ処理をFlashドライブ環境で行うと、処理速度そのものも約7倍に大きく伸びると同時に、シンプロ機能を使用した場合にもその高速処理が低下しない結果となっている（Flash-8ジョブの値）。このような結果となる背景は、シンプロ環境では書き出し時に発生する書き出し場所の記録処理もHDDではなくFlashドライブで行われるため、遅延が小さくなるためと考えられる。
また、より高負荷の書き出し処理（Flash-16ジョブの値）においてもシンプロ環境でのパフォーマンス低下の懸念がほぼないことを示している。当データから、多くのシステム環境でAll Flashディスクと呼ばれるFlashドライブのみのディスク装置が主流として使用されてきている現状では、当初あったパフォーマンス面の懸念事項は払拭されていると考えられる。
次に2つ目の懸念事項であった「Global Mirrorなどのディスク災害対策機能との併用」についての現状を述べる。
当初（DS8880のマイクロレベルR8.4以前）は、データセット削除後の使用スペースの再利用のためには、Global Mirrorのデータ送信をいったん停止する必要があった。DS8000のGlobal Mirror機能は、ミッションクリティカルなシステム環境での災害対策として国内でも多く利用されており、一時的なデータ送信の中断はRPO（Recovery Point Objective）と呼ばれる被災時のデータ鮮度を落とすことになる。この懸念点については、DS8880 R8.5以降、最新のDS8900Fを含めて解消されおり、Global Mirror稼働中のスペースの再利用が可能となっている。
シンプロ環境の構築ステップ
今まで述べてきたように、z/OS環境のシンプロ機能の活用は多くのシステム環境で有効であり、また、当初の懸念点も解消されてきている。ここからは、シンプロ環境の構築はどの程度の作業となるかをイメージしていただくために、必要なステップを書き出している。
１．DS8000論理構成時のランク（RAIDアレイ）作成時にExtent Sizeを21シリンダーで設定
２．論理ボリューム作成時にシンプロ指定とする（DSCLIコマンド:mkckdvol –sam ese）
３．容量監視ジョブとスペース解放ジョブの作成と定期実行、および容量監視部門の確定
４．z/OS監視メッセージの追加
上記からシンプロ環境の構築に必要な作業は、それほど大きな負荷ではないことがおわかりいただけると思う。
1.の設定は、論理ボリューム作成後では困難であるため（作成後の変更のためには論理ボリュームを削除しランクの再作成が必要）、当面シンプロ機能を使用する予定がない場合にも21シリンダーのExtent Sizeの指定をお勧めする。
Extent Sizeの単位でDS8000は、書き出されたデータに対してディスク容量の割り当てを行う。たとえば、順次書き込みの場合には、最初のデータ書き込み時に21シリンダーの容量が割り当てられ、22シリンダー目のデータ書き込みで次の21シリンダー分が割り当てられる。未指定の場合は、Extent Sizeは1113シリンダーとなり、シンプロ機能を有効に使えない。たとえば、1シリンダー分のデータがz/OSから書き出された場合でも、100シリンダー分のデータが書き出された場合でも、1113シリンダー分の容量割り当てが行われ、無駄な未使用エリアが多くなる可能性が高い。
シンプロ機能の使用の有無は論理ボリューム単位で設定可能であるが（ステップ2で実施）、1.でExtent Sizeが21シリンダーで指定されていない場合は、その効果が極めて限定されることになる。なお、Extent Sizeを21シリンダーで設定した場合には、DS8000搭載のプロセッサ・メモリが512GB以下の時、論理ボリュームの1筐体の物理総容量は最大512TBとなる点に注意が必要だが、512TBはかなり大きな容量なので通常問題にはならない。
3.は、z/OS IDCAMS LISTDATAコマンド（DS8000上の物理使用容量をレポート）とDFSMSdss SPACERELコマンド（削除データセットのスペースの解放）のジョブを定期的に実行するよう運用システムに組み込む作業である。また、このレポートからDS8000上の物理容量の状況をある程度の期間ごとに確認し、ディスク容量の不足が懸念されないかといったキャパシティ・プランを実施する部門を明確にしておくことも重要である。
そして4.において、DS8000の空き物理容量の割合が設定値以下になった時点で、z/OSコンソールに出力されるメッセージ（IEA499E）を監視対象とする。3.において定期的な容量監視は実施済みであるため、このメッセージが出力される状況は通常はないと考えられるため、このメッセージ監視は不測の事態の発生を検知するものである。
シンプロ機能採用にあたっての考慮点
最後に、当機能を利用する際の考慮点をまとめておく。
シンプロ機能は、今までのボリューム単位のディスク容量割り当ての運用形態を大きく変えるものであるため、まずは安全を見て、十分なディスク容量を確保した状態で使用を開始するのが、システム管理者の負担も少なくてよい。
具体的には、ディスク更改にあたって、シンプロ機能なしで必要となるディスク容量を搭載し、そのうえで、シンプロ機能を使用する。このやり方では、ディスク更改時の費用削減にはつながらないが、将来のディスク容量追加の時期を遅らせたり、その次のディスク更改時には、必要容量の削減が可能となる。
また、Global Mirrorなどのリモートコピー環境では、使用スペースの解放処理は通常運用に支障なく実施可能だが、ボリューム単位の差分FlashCopy機能については、リレーションを維持したままのスペース解放処理は実施できない。現在、差分FlashCopy（ボリューム単位の処理のみ可能）を使用中の環境では、対応の検討が必要である。
本稿では触れられなかったが、Global MirrorのCボリュームでもシンプロ機能が利用可能で、災対サイトに必要となるディスク容量の削減が可能である。ただし、使用にあたっては細かな考慮事項があるため、検討にあたってはIBM技術者にご相談いただくのがよいと考える。
本稿では、z/OS環境においてディスク容量の効率的な利用を可能とするシンプロ機能をご紹介した。導入作業は比較的容易であり、リスクも小さく、メリットも期待できるので、今後のディスク更改時などでご検討いただければ幸いである。
◎参考
・IBMストレージの最新機能のWebセミナー案内と資料（英語）
・IBMストレージの様々なご紹介資料（英語）
高田 新 氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
テクニカル・コンピテンシー
エグゼクティブITスペシャリスト
1983年、日本IBM入社後、MVS/XA（z/OSの前身）環境でのストレージソフトウェアおよびハードウェアのSE技術支援を実施。その後、お客様担当SEを経て、再度、SE技術支援部門に戻り、メインフレーム環境およびオープン・システム環境のストレージ製品関連のSE技術支援を実施。現在、ISEにおいて海外の開発部門やITスペシャリストと連携し、メインフレーム環境のストレージ・ソリューションの提案活動やお客様環境への導入支援活動を多数継続中。
［i Magazine・IS magazine］
