SMSは「クラウド」である
SMS （Storage Management Subsystem、製品としての名称はDFSMS）は、ストレージ管理の自動化・仮想化を実現するz/OSの機能として、四半世紀以上前から使用されてきた。
「データがどこにあるか」をユーザーが意識しなくてよいように、また細かい知識や手順は知らなくても最低限必要な情報を伝えるだけでストレージをすぐ利用できるように、必要な容量をストレージ・プールから取得する仕組みがSMSである。
これは、最近よく聞く何かに似ていないだろうか。そう、「クラウド」である。z/OSのSMSは、クラウドという言葉が一般化するずっと以前から提供されているので意識されにくいが、「物理的なデータの場所を意識せず、使いたいときにすぐ使えるようにする」という意味で、SMSは実はクラウドなのである。
クラウド時代である今、世界的に見てSMSの利用はほぼ標準であり、必須機能となっている。SMSを前提とする最新機能も多い。SMS化なくしては、データ増加に伴って肥大するストレージ管理コストへの対応は難しく、最新機能によるメリットも享受できない。SMS化の推進は必須である。
しかし日本ではストレージ管理を完全にSMS化する例は、まだ少数にとどまっている。なぜ日本のユーザーでは、SMSの利用が進まないのだろうか。一因として考えられるのは、SMS化のメリットが十分に訴求されておらず、必要性を感じられないことである。SMSを利用せずとも安定的に運用しているユーザーでは、わざわざSMSへ移行する手間やコストに見合うメリットを見出せないのである。
そこで本稿では、SMSの基本的な動き、自動化・仮想化以外でも役立つ機能、SMS前提の最新機能で得られるメリットなどについて具体例を挙げながら解説する。
SMSの基本的な動き
まず、SMSの基本的な動きとその効果を確認する。
図表1の左に示す非SMS管理の場合、データセットを作ろうとすると、JCL上でVOLSER指定が必要になる。目的に応じて利用できるボリュームを確保し、そこに必要なスペースがあるかを確認する。
アロケーションするデータセットの容量が増えてきたら、スペースの空き状況を再度チェックして追加のボリュームを指定したり、マルチ・ボリューム化したりする必要も生じる。このように非SMS管理の場合、JCLやボリュームの管理に手間がかかる。また、JCLの指定次第で使用するボリュームを自由に選べるので、本来使うべきではないボリュームを使うなど、決められた用途以外の使用を防止できない。
一方、図表1の右に示すSMS管理の場合は、まずストレージ管理者がボリュームのプールを定義し、どのようなデータをどのプールに作成するか、あらかじめアロケーション・ルールを作成しておく。そうすれば、ユーザーはJCL上でそのルールに従うようにデータセット名などを指定するだけで、データセットを作成できる。VOLSERを指定する必要はなく、スペース管理はプール単位で行われるので、ユーザーが必要な空きスペースを気にしたり、ボリュームを追加する必要はない。
ユーザーの観点から、SMS管理で得られる一般的な効果を図表2にまとめた。業務アプリケーション担当者（ジョブ作成者）から見ると、非SMS環境に比べてSMS環境では、個々のジョブで使用するボリュームの空き容量の確認やデータセットのボリューム配置設計から解放され、ワークロード削減が可能となる。
またストレージ管理者から見ると、データセットをルールどおりにアロケーションさせることで一元的にストレージを管理でき、使用量の監視やデータ増加への対応も容易になる。
このような自動化・仮想化によるストレージ管理の効率化は、SMSの一般的な効果であるが、ほかにも多彩なメリットがSMS化により得られる。以下に紹介しよう。
ユーザーの課題を解決する
SMSの機能と効果
SMS管理では、最新機能を含めたさまざまな機能を使用できる。図表3では、SMS化により利用できる機能を、「ベース機能」と「追加機能」に分けて整理した。
ベース機能とは、前述のようなストレージ管理を効率化する基本的な部分で、z/OSの標準機能として提供される。効率化だけでなく、X37 ABENDの回避など、あまり知られていない機能も含まれる。
追加機能は、SMSのオプショナル・コンポーネントであるHSMやRMM、他製品でSMSを前提とする最新機能など多彩である。たとえば、zEC12からサポートされている新しいデータ圧縮ソリューション「zEDC」（IBM z Enterprise Data Compression）は、高い圧縮率によるパフォーマンス向上を期待できるが、SMS管理が前提となる。
またDB2 FCIC （FlashCopy Image Copy）は、DB2 V10からサポートされたFlashCopyを利用してイメージ・コピーを取得する機能であるが、これもFCICのソースとターゲット双方ともにSMS管理データセットが前提となる。図表3には記載していないが、z/OS V2R3からのデータセット・レベルの暗号化（全方位型暗号化）も同様にSMSが前提となる。
以下に、一例としてX37 ABENDの回避とzEDCによるデータ圧縮を説明しよう。
X37 ABENDの回避
X37 ABENDは、スペース不足によるB37/D37/E37 ABENDをまとめて指すもので、z/OS担当者なら誰でも経験するエラーである。よくある原因として、たとえばアロケーションしようとしたボリューム内に十分な空きスペースがないこと、順次データセットが16エクステントまで拡張されていることなどが挙げられる。
このX37 ABENDの回避には、それを目的としたツール（TAAM、STOP-X37など）が比較的よく使われている。しかし、SMSの機能により同様の改善が可能であることは意外に知られていない。
SMSによるX37 ABENDの回避では、コンポーネントの1つであるData Classを利用する。図表4に、Data Classに設定する関連オプションをまとめた。
たとえば「Space Constraint Relief」（以下、SCR）。通常、アロケーションで要求した容量を満たす連続したスペースがない場合、1ボリューム上で5エクステントまで分割してアロケーションできるが、SCR=Yを指定すると、5エクステントの制限を超えてアロケーションをリトライできるようになる。
また「Dynamic Volume Count」（以下、DVC）は、リトライ時に指定した値まで動的にボリュームを追加し、自動時にマルチ・ボリュームを使えるようにする。
図表5で、SCRとDVC利用時の動きを説明する。
左にある非SMS管理の環境では、データセットをアロケーションする際、指定したVOLSER中に、指定したサイズに見合う十分なスペースがないとABENDしてしまう。
それに対して、右にあるSMS管理の環境で、SCR=Y、DVC=2を指定すると、ABENDを回避できる。データセットをアロケーションしようとすると、プール内のボリューム群からボリュームが選択されるが、そこに十分なスペースがなくても、SCRが有効なのでリトライを実行し、さらにDVCの機能を使って動的にボリュームを追加して、マルチ・ボリューム化することで必要なサイズを確保する。
図表6では、SCRとDVCに加えて、さらに「Space Reduce Up to （%）」（以下、Space Reduce）使用時の動きを説明する。
非SMS環境ならABENDする状況でも、SMS管理上でSCR=Y、DVC=3、Reduce Space=30％を指定すると、ABENDを回避できる。プール内のボリューム群から選択されたボリュームに十分なスペースがなくても、SCRによりリトライされ、そこでDVCにより動的にボリュームが追加されてマルチ・ボリューム化し、さらにサイズを最大30％縮小することでアロケーションを成功させる。
このほか、「Extent Constraint Removal」では、VSAMの最大エクステント数の上限を緩和することで、エクステント数を使い切ってABENDする可能性を低減できる（具体的には、VSAMの最大255エクステントまで、という制限を最大7257エクステントまで使用可能にする）。
また「Data Set Name Type」でExtended formatを利用すると、データセットが拡張フォーマットでアロケーションされ、最大サイズやエクステントの制限を緩和できる。順次データセットの場合、通常1ボリューム当たり6万5535トラックが最大サイズであるが、拡張フォーマットになると1ボリューム当たりで使用できるトラック数の上限を撤廃できる。
このようにSMSのベース機能を利用することで、ツールを使用せずにX37 ABENDを回避できる。ワークロード削減のためにも、これらの機能が有用であることをぜひ知っていただきたい。
SMS管理を前提とするzEDC
次に、SMS管理が前提である最新機能の例としてzEDCを紹介する（zEDCはzEC12、z/OS V2R1以降でサポートされ、zEDC Express featureが必要になる）。
従来のハードウェア圧縮では、得られる圧縮率に対してCPUコスト増加率が高く、限定的にしか使われていなかった。これに対し、zEC12からの新しいデータ圧縮ソリューションであるzEDCは、従来よりも低いCPUコストで高い圧縮率が期待できる。これにより、ディスク使用効率の向上や、I/O時間の削減によるアプリケーションのパフォーマンス向上が可能となる。
図表7のとおり、従来のハードウェア圧縮とzEDCでは実行場所やフォーマット、サポート対象となるデータに違いがある。
どの程度の効果があるか、筆者の手元の環境で検証した結果を図表8にまとめた。zEC12、z/OS V2R1の環境で、3000cylの順次データセット（SAM）をICEGENERでコピーした結果である。このテストでは約3倍（67%減）の圧縮率が得られた。データ量が減ったことでI/O時間が短縮され、コピーに要する時間は40％削減できた。また、CPU使用率は非圧縮時と比べると増加したが、従来の圧縮に比べると90％減と大幅に削減された。
圧縮率はデータパターンにより大きく変わるので、必ずこのような効果が得られるとは限らないが、従来のハードウェア圧縮と比べても、高い圧縮率やパフォーマンス向上を十分に期待できる結果である。
このzEDCの利用は、SMS管理が前提になる。順次データセットをデータ圧縮するには拡張フォーマットであることが必要で、拡張フォーマットにするには、SMSのData ClassでExtended formatを指定せねばならない。
zEDCはほんの一例であり、SMS化により、このほかにも新機能のメリットを多く享受できる。つまりSMS化していない場合、現在のz/OSが備える価値を十分に活かせない可能性が高いと言える。
SMSは、大容量化・大規模化が避けられない近年のストレージ環境では必須である。ストレージ管理を効率化するだけでなく、X37 ABENDの回避による運用ワークロード削減のようなメリットも得られる。
またSMS前提の新機能も多い。zEDC利用によるパフォーマンス向上やディスク容量削減はその一例である。z/OSの価値を相対的に高めるためにも、SMS化の価値を再認識し、SMS化を進めることが重要である。
著者｜藤原 輪
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
メインフレーム・テクノロジー
アドバイザリーITスペシャリスト
2004年入社。以後、DB2 for z/OSの技術サポートを担当。2014年からz/OS DFSMSおよびメインフレーム・テープ製品の技術サポートに携わる。
