WebSphere® Application Server for z/OS® 構成ファイル・システムをセットアップする際に必要な計画の決定がいくつかあります。
セル、ノード、サーバー設定は、およびデプロイ済みアプリケーションは、
WebSphere Application
Server for z/OS 構成ファイル・システムに保管されます。
構成ファイル・システムには、zSeries ファイル・システム (ZFS) または階層ファイル・システム (HFS) を使用することができます。
ヒント: WebSphere Application
Server for z/OS バージョン 7.0 以降では、SBBOLOAD および SBBOLD2 データ・セットは存在しなくなっています。
これは、ロード・モジュールが現在製品ファイル・システム内にあるためです。製品ファイル・システム内でロード・モジュールの使用する構成から、データ・セット内でロード・モジュールを使用する構成に切り替える場合、
「
switchModules コマンド」で説明されているツールを使用することができます。WebSphere
Application Server for z/OS バージョン 8.0 以降、データ・セット (STEPLIB、LPA またはリンク・リスト内に含まれる) に入れられた DLL をサーバーが使用するために
server_dlls_in_hfs 環境変数も
0 に設定する必要があります。
デーモンが DLL を使用するようにするために、
WAS_DAEMON_ONLY_server_dlls_in_hfs はセル・レベルで設定する必要があります。
各ノードにはホーム・ディレクトリーが必要
WebSphere Application Server for z/OS の各ノードには、それがスタンドアロン・アプリケーション・サーバーか、デプロイメント・マネージャーか、管理対象アプリケーション・サーバー・ノードか、ロケーション・サービス・デーモンかにかかわらず、読み取り/書き込みホーム・ディレクトリー (WAS_HOME と呼ばれることもある) が必要です。
次の例は、/WebSphere/V9R0 にマウントされた、WebSphere Application Server for z/OS 構成ファイル・システムの構造です。ここでは、BBOS001 という名前の単一アプリケーション・サーバー用の WebSphere Application Server ホーム・ディレクトリー (セルとノードの名前はどちらも SYSA) が含まれています。
/WebSphere/V9R0
/AppServer
/bin
/classes
/java
/lib
/logs
/profiles
/default -> this is the profile_root directory
/temp
...
/Daemon
/config
/SYSA
SYSA.SYSA.BBODMNB -> /WebSphere/V9R0/Daemon/config/SYSA/SYSA/BBODMNB
SYSA.SYSA.BBOS001 ->
/WebSphere/V9R0/AppServer/profiles/default/config/cells/SYSA/nodes/SYSA
/servers/server1
SYSA.SYSA.BBOS001.HOME -> /WebSphere/V9R0/AppServer
BBOS001 の WebSphere Application Server ホーム・ディレクトリーの名前は、AppServer です。
ここには、
SYSA ノードと BBOS001 サーバーの完全な構成情報を持つディレクトリーが含まれています。
/Daemon ディレクトリーには、
この構成ファイル・システム内のノードに定義されたロケーション・サービス・デーモンの構成情報が含まれています。
注: /Daemon/config サブディレクトリーは、セル名でさらに分けられます。
セルのショート・ネームがそれぞれ異なる場合、
各セルのロケーション・サービス・デーモン情報は別々に保管されます。
デーモンのホーム・ディレクトリーの名前は、固定の WebSphere Application Server ホーム名
Daemon となります。
開始パラメーターへのアクセスに使用されるシンボリック・リンク
WebSphere Application Server ホーム・ディレクトリーそのものだけでなく、
構成ファイル・システムにも、各サーバーへの複数パーツのシンボリック・リンクが含まれ、
そのサーバーの開始パラメーターを指しています。
このシンボリック・リンクの名前は、cell_short_name.node_short_name.server_short_name です。
前述の構成ファイル・システムの例には、
ロケーション・サービス・デーモンを開始するシンボリック・リンク SYSA.SYSA.BBODMNB と、
BBOS001 アプリケーション・サーバーを開始するシンボリック・リンク SYSA.SYSA.BBOS001 が含まれています。
2 番目のシンボリック・リンクは、
MVS™ コンソールからサーバーまたはロケーション・サービス・デーモンを開始するときに、
次のように START コマンドの ENV パラメーターで指定されます。
START procname,JOBNAME=BBOS001,ENV=SYSA.SYSA.BBOS001
シンボリック・リンクはそれぞれ、サーバーの was.env ファイルが置かれているサブディレクトリーを指します。このファイルには、サーバーの始動に必要な情報が含まれています。
注: ポストインストール処理中には、後述のように、サーバーの JCL で、was.env ファイルの場所ではなく、WebSphere Application Server ホーム・ディレクトリーそのものを指定する必要があります。これが、前述の SYSA.SYSA.BBOS001.HOME シンボリック・リンクの目的です。
セル間での構成ファイル・システムの共有
複数の WebSphere Application Server for z/OS セル (スタンドアロン・アプリケーション・サーバー、Network Deployment、またはその両方) は、以下の条件が満たされる場合、1 つの WebSphere Application Server for z/OS 構成ファイル・システムを共有することができます。
- 構成ファイル・システムを使用するセルはすべて、同じ共通グループとユーザーを使用してセットアップする必要があります。
特に、各セルの管理者ユーザー ID と構成グループは同じでなければなりません。
- セルには、それぞれを区別するショート・ネームが必要です。
- 各ノードには、他のノードまたはセルと共有されない、独自の WAS_HOME ディレクトリーが必要です。
前述のように、セル間でデーモンのホーム・ディレクトリー (
/Daemon) を共有できます。これには、構成ファイル・システム内の各セルごとに下層のサブディレクトリーがあるためです。
注: セル間で構成ファイル・システムを共有すると、1 つのセルで問題が起こった場合に、
同じ構成ファイル・システム内の他のセルでも問題が生じる可能性が高まることに注意してください。
システム間での構成ファイル・システムの共有
複数の z/OS システムは、その z/OS システムに共有ファイル・システムがあり、構成ファイル・システムが R/W でマウントされている場合には、構成ファイル・システムを共有することができます。更新はすべて、そのマウント・ポイントを所有する z/OS システムが行います。Network Deployment セルでは、これは一般に、
そのセルのデプロイメント・マネージャーが構成されている z/OS システムです。
WebSphere Application Server for z/OS 構成ファイル・システムのマウント・ポイントの選択
WebSphere Application Server for z/OS 構成ファイル・システムのマウント・ポイントの選択は、
z/OS システムのレイアウト、そこに含まれるアプリケーション・サービス環境の性質、
およびいくつかの要因 (セットアップや保守のしやすさ、パフォーマンス、回復可能性、
連続可用性の必要など) の相対的重要度によって決まります。
- 単一の z/OS システムの場合:
単一の z/OS システムで WebSphere Application Server for z/OS を実行する場合は、
z/OS 構成ファイル・システムのマウント・ポイントにはさまざまな選択肢があります。
単一の構成ファイル・システム内の複数のスタンドアロン・アプリケーション・サーバーに、実動サーバーまたは Network Deployment セルごとに別々の構成ファイル・システムを設定することもできます。別々の構成ファイル・システム・データ・セットを使用すると、パフォーマンスや信頼性が増しますが、構成ファイル・システムを共有すると、必要なアプリケーション・サーバーのカタログ式プロシージャーの数が少なくてすみます。
次の例のように、開発サーバー、テスト・サーバー、
および品質保証サーバー (すべて同じ共通グループ内にあります) に対して構成ファイル・システムが 1 つ必要になります。
/WebSphere/V9R0_test
/DevServer - home to standalone server DVCELL, with server DVSR01A
/TestServer1 - home to standalone server cell T1CELL, with server T1SR01A
/TestServer2 - home to standalone server cell T2CELL, with server T2SR01A
/QAServer - home to Network Deployment cell QACELL, with deployment manager QADMGR and server QVSR01A
実動セルに対しては、次のように別の構成ファイル・システムを用意することができます。
/WebSphere/V9R0_prod
/CorpServer1 - home to Network Deployment cell CSCELL, with deployment manager CSDMGR and server CSSR01A
- マルチシステム z/OS シスプレックス (ファイル・システムの共有なし) の場合:
マルチシステム・シスプレックスでファイル・システムを共有しない場合には、各 z/OS システムに、それぞれ独自の構成ファイル・システム・データ・セットが必要です。スタンドアロン・アプリケーション・サーバーや、複数のシステムにまたがることのない Network Deployment セルでは、オプションは、単一の z/OS システムの場合と同じです。
- 複数システムにわたる Network Deployment セルの場合:
この場合は、次の 2 つのオプションがあります。
- 各システムで、セルの構成ファイル・システム・データ・セットに、別々のマウント・ポイントを使用することができます。こうすると、システム間のノードの移動 (例えば、システムが操作不能になったり、アップグレードされたりした場合) が容易になります。これは、それぞれのマウント・ポイントが、シスプレックス内の他のシステムでは未使用なので、障害が発生したシステムの構成ファイル・システム・データ・セットをシスプレックス内の代替システムにマウントすることができるためです。
例えば、システム LPAR1 では、セルの一部に構成ファイル・システムが必要になります。
/var/WebSphere/V9R0config1
/DeploymentManager - home to deployment manager F1DMGR in cell F1CELL
/AppServer1 - home to node F1NODEA and servers F1SR01A and F1SR02A
また、
LPAR2 では 2 番目の構成ファイル・システムが必要です。
/var/WebSphere/V9R0config2
/AppServer2 - home to node F1NODEB and servers F1SR02B (clustered) and F1SR03B
このようなセットアップには、デプロイメント・マネージャーとノード F1NODEA を LPAR2 に移動したり、
あるいはノード F1NODEB を LPAR1 に移動したりできるという利点があります。この構成の欠点は、
F1NODEA と F1NODEB で、別々のカタログ式プロシージャー・セットが必要だということです。
- あるいは、特定セルでは、すべての構成ファイル・システム・データ・セットに対して、同じマウント・ポイントを使用することができます。こうすると、共通のカタログ式プロシージャーを使用して、
システムを同じように見せることができます。
次の例では、上記と同じセル・セットアップを使用して、
ノード LPAR1 に構成ファイル・システムを 1 つ設定します。
/var/WebSphere/V9R0F1
/DeploymentManager - home to deployment manager F1DMGR in cell F1CELL
/AppServer1 - home to node F1NODEA and servers F1SR01A and F1SR02A
また、
LPAR2 には、同じマウント・ポイントに別のファイル・システムが割り当てられます。
/var/WebSphere/V9R0F1
/AppServer2 - home to node F1NODEB and servers F1SR02B (clustered) and F1SR03B
しかし、
いずれかの LPAR のノード (複数可) を他のシステムに再配置する場合は、
1 つの構成ファイル・システムのコピーを別の構成ファイル・システムにマージする必要があります。
- マルチシステム z/OS シスプレックス (共有ファイル・システム) の場合:
シスプレックスに共有階層ファイル・システムが備わっている場合は、
セル全体で使用する大規模な構成ファイル・システムをマウントすればよいだけです。
プロファイル管理ツール、もしくは zpmt コマンドを使用する際に、各システムで共通の構成ファイル・システムのマウント・ポイントを指定します。前述のように、
構成ファイル・システムの更新は、デプロイメント・マネージャーをホストしている z/OS システムから行います。
パフォーマンスは、構成変更の頻度によって決まります。このオプションを選択する場合は、
必ず、十分な調整を行ってください。
あるいは、
次のように、各システムの
/&SYSNAME にマウントされているシステム固有のファイル・システムを使用して、
各システムで別々の構成ファイル・システムをマウントすることもできます。
/LPAR1/WebSphere/V9R0F1
/DeploymentManager - home to deployment manager F1DMGR in cell F1CELL
/AppServer1 - home to node F1NODEA and servers F1SR01A and F1SR02A
/LPAR2/WebSphere/V9R0F1
/AppServer2 - home to node F1NODEB and servers F1SR02B (clustered) and F1SR03B
各システム (LPAR1 と LPAR2) は、
それぞれのシステム固有のマウント・ポイントで、
独自の構成ファイル・システムをマウントします。
プロファイル管理ツールまたは
zpmt コマンドを使用する際には、以下を指定します。
- /LPAR1/WebSphere/V9R0F1 (LPAR1 の場合)
- /LPAR2/WebSphere/V9R0F1 (LPAR2 の場合)
このオプションの方が、共有シスプレックスよりパフォーマンスに優れています。
また、マウント・ポイントの選択によっては、元の所有システムがダウンした場合に、
構成ファイル・システムを一時的に別の LPAR にマウントすることもできます。
構成ファイル・システムのマウント・ポイントを選択するには、
カタログ式プロシージャーをシステム固有にするか、&SYSNAME を使用します。
すべての構成ファイル・システム・データ・セットで同じ明確なマウント・ポイントを使用する必要がある場合は、次のように、シンボリック・リンクを使用して、共通マウント・ポイントを各システム上の別のファイル・システムに指定変更します。
- -s $SYSNAME/WebSphere WebSphere で、
- /LPAR1/WebSphere/V9R0F1 で、LPAR1 の構成ファイル・システムをマウントします。
- /LPAR2/WebSphere/V9R0F1 で、LPAR2 の構成ファイル・システムをマウントします。
これが正しく実行されると、プロファイル管理ツールまたは
zpmt コマンドで各システムの /WebSphere/V9R0F1 の構成マウント・ポイントを指定できるようになり、さらに、システム固有のカスタマイズ・ファイル・システム・データ・セットの利点を享受することもできます。ただし、このセットアップを使用すると、構成ファイル・システム・データ・セットをシステム間で、簡単に移動することはできなくなります。すべてのノードのデータは、/WebSphere/V9R0F1 に入ることになっており、各システムのこのマウント・ポイントでは、構成ファイル・システムを 1 つしかマウントすることができません。
- 推奨:
- 単一の z/OS システムで、/wasv90config で読み取り/書き込みファイル・システムを作成し、プロファイル管理ツールのデフォルトを使用して、/wasv90config/cell_name/node_name で各構成ファイル・システムをマウントします。
- マルチシステム・シスプレックス (ファイル・システムの共有なし) では、
単一の z/OS システムに対する前述の推奨事項に従ってください。
そうすると、
各セルで共通のカタログ式プロシージャーが使用できるようになります。
シスプレックス内の代替システム上でリカバリーする必要のある任意のセルに対しては、
各システムで別々のマウント・ポイントを設定します。
- マルチシステム・シスプレックス (共有ファイル・システムあり) では、パフォーマンスが問題にならない場合、
あるいは WebSphere Application Server for z/OS の特定の機能をサポートするた
めに共有ファイル・システムが必要になる場合に、共有の構成ファイル・システムを使用します。
パフォーマンスが問題になる場合、あるいは Single Point of Failure を回避しなければならない場合には、非共有の構成ファイル・システム・データ・セットを使用してください。
WebSphere Application Server のホーム・ディレクトリー名の選択
WebSphere Application Server のホーム・ディレクトリーは、常に、
それが置かれている構成ファイル・システムを基準に表されます。
したがって、プロファイル管理ツールまたは zpmt コマンドでは、ある 1 つのパネルで構成ファイル・システムのマウント・ポイントを選択すると、別のパネルでは、ホーム・ディレクトリーの単一のディレクトリー名だけを記入します。ただし、サーバーの WAS_HOME ディレクトリーに移動するようにという指示では、構成ファイル・システムとホーム・ディレクトリー名を結合したパス名全体のことを言っています (例えば、/WebSphere/V9R0/AppServer です)。
ホーム・ディレクトリーには、
構成ファイル・システム内で固有である場合、任意の名前を選択することができます。
スタンドアロン・アプリケーション・サーバーまたは新規の管理対象サーバー・ノードを作成して、Network Deployment セルに統合する場合は、Network Deployment セルの構成ファイル・システムで使用されていないものを選択してください。
システムごとにノードが 1 つずつある場合は、
何らかの形式のノード名またはシステム名を使用することができます。
あるいは、デプロイメント・マネージャーの場合は DeploymentManager、各アプリケーション・サーバー・ノードの場合は AppServern を使用することもできます。
構成ファイル・システムと製品ファイル・システムの関係
構成ファイル・システムには、製品ファイル・システム (デフォルトで /usr/lpp/WebSphere/AppServer/V9R0) 内のファイルへのシンボリック・リンクが多数含まれています。これによって、サーバー・プロセス、管理者、およびクライアントが、
一貫した WebSphere Application Server for z/OS コード・ベースにアクセスできるようになります。
これらのシンボリック・リンクは、WebSphere Application Server ホーム・ディレクトリーの作成時にセットアップされるので、
変更が容易ではありません。
したがって、高可用性を必要とするシステムでは、システム保守を可能とするために、使用中の各保守レベルおよびサービス・レベル (テスト、確認、実動など) ごとに、WebSphere Application Server for z/OS の製品ファイル・システムと製品データ・セットのコピーを別々に保管し、中間シンボリック・リンクを使用して、各構成ファイル・システムをその製品ファイル・システムと接続するようにしてください。
WebSphere Application Server for z/OS ノードの始動時には、
構成のサービス・レベルが、製品ファイル・システムのサービス・レベルと比較されます。
構成ファイル・システムのサービス・レベルが
製品ファイル・システムのサービス・レベルより高い場合 (古い製品ファイル・システムがマウントされている可能性があることを意味します)、
そのノードのサーバーは、エラー・メッセージを出して終了します。
構成ファイル・システムのサービス・レベルが
製品ファイル・システムのサービス・レベルよりも低い場合 (ノードが最後に始動した後に、
サービスが製品コード・ベースに適用されたことを意味します) は、ポスト・インストーラーと呼ばれるタスクが、
最新の状態に保つために構成ファイル・システムで実行する必要があるアクションを検査します。