z/OSのボリューム構成を体系的に理解する：SYSRESやSYSPLEX CDSの役割

はじめに

z/OS環境では、SYSRESやSYSPLEX CDSをはじめ、役割や配置場所が異なる、様々なボリュームが使われています。あるボリュームはLPAR（区画）ごとに用意され、またあるボリュームはSYSPLEXという単位で複数のLPARから共有されます。

この一見複雑に見える構成も、その背景にある「LPAR」と「SYSPLEX」という基本アーキテクチャを理解することで、なぜそのような配置になっているのか、その理由が見えてきます。

本記事では、この基本アーキテクチャを土台として、各ボリュームが担う役割と配置の意図を体系的に解説します。

基本：LPARとSYSPLEX

ボリュームの構成を理解する上で、まず押さえておくべきなのが「LPAR」と「SYSPLEX」という2つの概念です。なぜSYSRESはLPARごとに必要なのか、なぜSYSPLEX CDSは共有されるのか、その答えを解説してきます。

LPAR (Logical Partition)
LPARとは、一台の物理的なサーバーを、論理的に複数に分割した区画のことです。それぞれのLPARは、独立したOS（z/OS）が稼働する単位と考えることができます。重要なのは、各LPARが個別に起動・停止でき、それぞれが他のLPARとは切り離されたOSとして動作する点です。

SYSPLEX (System Complex)
SYSPLEXとは、複数のLPARを協調動作させるための仕組みです。SYSPLEXがLPARを束ねて一つのOSにするわけではないです。各LPARはあくまで独立したOSとして存在し続け、個別に起動・停止することも可能です。

SYSPLEXは独立したLPAR同士が連携するための仕組みです。これにより、利用者やアプリケーションからは、どのLPARで動作しているかを意識することがありません。LPAR同士で互いに処理を分担したり、データを共有したり、あるLPARに障害が発生した際には他のLPARが処理を引き継いだりすることで、可用性と運用効率を高めることができます。

この「独立して動くLPAR」と、それを「束ねて連携させるSYSPLEX」という関係性が、ボリュームの役割と配置を決定づける基本原則となります。

LPAR固有ボリューム：「SYSRES」とその他

前章で、LPARはそれぞれが独立したOSとして動作する単位だと解説しました。OSが独立して起動するためには、OS自身のプログラムや設定ファイル、そしてそのLPARだけが使用する専用の作業領域が必要になります。

これらが他のLPARと混在してしまうと、一方のLPARでの変更が他方に意図しない影響を及ぼす可能性があり、独立性が損なわれます。そのため、他のLPARとは共有しない、各LPARに固有のボリューム群が存在します。ここではその代表的なものを紹介します。

OSの中核：IPLボリュームとしてのSYSRES

LPAR固有ボリュームの最も代表的なものがSYSRES（System Residence）です。このボリュームには、z/OSの中核をなすプログラム（SYS1.NUCLEUSなど）や、システムの基本的な動作を定義するライブラリ（SYS1.LPALIBなど）が格納されています。

LPARの電源が入り、OSが起動（IPL）する際には、このSYSRESからOSプログラムが読み込まれます。そのためSYSRESは「IPLボリューム」とも呼ばれ、これがなければLPARを起動させることはできません。個々のOSにとっての中核であり、起動ディスクと言えます。本番稼働用のSYSRESとは別に、メンテナンス作業用のSYSRESを用意し、万が一の切り戻しや安全なバージョンアップに備える構成が一般的です。

LPARの稼働を支えるボリューム

SYSRES以外にも、LPARが安定して稼働するために不可欠なボリュームがあります。

• PAGEデータセット
  これは、メモリ（実記憶）の容量を物理的な上限以上に拡張して見せる「仮想記憶」の仕組みを支える、一時的な作業領域です。メモリ上で処理しきれないデータをディスクに退避させることで、多くの処理を同時に動かすことを可能にします。各LPARのメモリ状況に応じて利用されるため、LPARごとに用意されます。

• DUMPデータセット
  システムやアプリケーションが予期せぬエラーで異常終了（ABEND）した際に、その瞬間のメモリ情報を丸ごと書き出すための領域です。このダンプデータは、障害の根本原因を調査するための重要な情報となります。問題が発生したLPARの状況を正確に記録するため、LPAR固有で管理されます。

• SMFデータセット
  CPU使用率、I/O回数、ジョブの実行記録といった、システムの活動状況を詳細に記録するためのデータセットです。パフォーマンス分析、キャパシティプランニング、セキュリティ監査、利用料金の計算など、様々な目的で利用されます。どのLPARでどのような処理が行われたかを個別に把握するために必須です。

これらのボリュームがLPARごとに独立して存在することで、各OSは他のOSに影響を与えることなく、その独立性を維持できます。

SYSPLEX共有ボリューム：「SYSPLEX CDS」

LPARが「独立」を基本とするのに対し、SYSPLEXは「連携」を目的とします。複数のLPARが連携して動作するためには、お互いの状態を把握し、作業内容やルールといった情報を共有するための場所が必要になります。

この「共有の場所」の役割を担うのが、SYSPLEX共有ボリュームです。SYSPLEXに所属する全てのLPARからアクセスできるこのボリューム群によって、システム全体としての可用性や運用効率が高まります。

SYSPLEX Couple Data Set (CDS)

SYSPLEX共有ボリュームの中でも、最も重要となるのがSYSPLEX Couple Data Set (CDS)です。これはSYSPLEX全体の構成情報や、各LPARの稼働状況をリアルタイムに管理するデータセットです。

具体的には、以下のような情報を保持しています。

• メンバー管理: どのLPARがSYSPLEXに参加しているか。
• 状態監視: 各LPARが正常に稼働しているか（ハートビート通信）。
• メッセージング: LPAR間で制御情報をやりとりする際の経路。

あるLPARで障害が発生し、応答が途絶えた場合、CDSの情報に基づいて他のLPARがそれを検知し、処理の引き継ぎなどの回復動作を開始します。CDSがなければ、LPARは単独で存在するだけで、SYSPLEXとしての連携は不可能です。その重要性から、CDSは必ず二重化（Primary/Alternate）され、万が一の障害に備える構成を取ります。

ジョブの流れを司るJES2/JES3

ユーザーが投入したジョブの実行を管理するJES（Job Entry Subsystem）も、SYSPLEX環境ではその情報を共有ボリュームに置きます。

• Checkpointデータセット: 実行中のジョブの状態や、実行待ちのジョブキューの情報を保持します。これにより、あるLPARが停止しても、他のLPARがCheckpoint情報を参照し、中断されたジョブの処理を引き継ぐことができます。
• Spoolボリューム: ジョブの出力リストなどを一時的に格納する領域です。共有ボリュームに置くことで、どのLPARからジョブを投入しても、出力結果を任意のLPARから参照・印刷することが可能になります。

セキュリティを司るRACF

RACF（Resource Access Control Facility）は、ユーザー認証やデータへのアクセス権限を管理するセキュリティ製品です。このRACFのデータベースをSYSPLEXで共有することにより、ユーザーはどのLPARにログオンしても同じ権限で作業ができます。管理者はユーザー情報を一元管理できます。

このように、SYSPLEX共有ボリュームは、個々のLPARを連携させるために不可欠です。

全社共通ボリューム

これまでは主に一つのSYSPLEX内でのボリューム構成を見てきました。しかし、多くの企業では複数のSYSPLEXを運用しています。これらの環境間でソフトウェアのバージョンや設定が異なると、管理が難しくなります。

そこで、SYSPLEXを越えて、全社的に共有・管理されるボリュームがあります。

SMP/E

SMP/Eは、z/OSやミドルウェアの導入、バージョンアップ、修正パッチの適用といったソフトウェア保守を一元管理するためのツールです。その管理情報を共通ボリュームに置くことで、全ての環境で「どのソフトウェアが、どのバージョンで、どの修正が適用済みか」を把握できます。

DLIB

DLIB（Distribution Library）は、ベンダーから提供されたソフトウェアが格納されているライブラリです。各LPARで利用するSYSRESやアプリケーションのライブラリは、このDLIBを原本としてコピーし、カスタマイズを加えて作成されます。原本を一つに集約することで、全システムに同じ品質のソフトウェアを配布することができるようになります。

IODF

IODF（I/O Definition File）は、ディスクやテープ装置といったI/Oデバイスの物理的な接続情報や設定を定義したファイルです。これも共通ボリュームで管理することで、特に本番環境と災害対策環境で全く同じハードウェア構成を保証するなど、厳密な構成管理を実現します。

これらの共通ボリュームは、個々のシステムを越えて全体の管理効率を支える役割を担っています。

まとめ：SYSRESの「独立性」とCDSの「協調性」

ここまで見てきたように、z/OSのボリューム構成は、一見すると複雑ですが、その背後には設計の目的が存在します。

SYSRESに象徴される、個々のOSの独立性を確保するLPAR固有ボリューム。そして、SYSPLEX CDSに代表される、システム全体の協調性を実現するSYSPLEX共有ボリューム。この二つの目的に沿って、z/OSのボリュームは設計されています。

一つ一つのボリュームがなぜその場所に配置されているのか。その意味を理解することは、日々の運用や障害発生時の迅速な対応、システムを設計する上での土台となります。

ここまでお読みいただきありがとうございました。