WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化
このトピックは、z/OS オペレーティング・システムにのみ適用されます。

構成ファイル・システム

この項目では、WebSphere® Application Server for z/OS® 構成ファイル・システムをセットアップする際に必要な計画の決定について説明します。

セル、ノード、サーバー設定は、およびデプロイ済みアプリケーションは、 WebSphere Application Server for z/OS 構成ファイル・システムに保管されます。
注: 構成ファイル・システムには、zSeries® ファイル・システム (zFS) または階層ファイル・システム (HFS) を使用することができます。
以下のセクションでは、 WebSphere Application Server for z/OS 構成ファイル・システムのセットアップ時に行う決定事項を記載し、 計画した構成の必要性に基づいた決定方法に関する情報を提供します。

各ノードにはホーム・ディレクトリーが必要

WebSphere Application Server for z/OS の各ノードには、 それがスタンドアロン・アプリケーション・サーバーか、 デプロイメント・マネージャーか、管理対象アプリケーション・サーバー・ノードか、ロケーショ ン・サービス・デーモンかにかかわらず、読み取り/書き込みホーム・ディレクトリー (WAS_HOME と呼ばれることもある) が必要です。

次の例は、 /WebSphere/V6R1 にマウントされた、WebSphere Application Server for z/OS 構成ファイル・システムの構造です。 ここでは、 BBOS001 という名前の単一アプリケーション・サーバー用の WebSphere Application Server ホーム・ディレクトリー (セルとノードの名前はどちらも SYSA) が含まれています。
    /WebSphere/V6R1
        /AppServer
            /bin
            /classes
            /java
            /lib
            /logs
            /profiles
            /default    -> this is the profile_root directory  
            /temp
            ...
       /Daemon
            /config
                /SYSA
       SYSA.SYSA.BBODMNB       ->  /WebSphere/V6R1/Daemon/config/SYSA/SYSA/BBODMNB
       SYSA.SYSA.BBOS001       ->  
/WebSphere/V6R1/AppServer/profiles/default/config/cells/SYSA/nodes/SYSA/servers/server1
       SYSA.SYSA.BBOS001.HOME  ->  /WebSphere/V6R1/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/V6_test
                  /DevServer    - home to stand-alone server DVCELL, with server DVSR01A 
                  /TestServer1  - home to stand-alone server cell T1CELL, with server T1SR01A 
                  /TestServer2  - home to stand-alone server cell T2CELL, with server T2SR01A
                  /QAServer     - home to Network Deployment cell QACELL, with deployment manager QADMGR and server QVSR01A
実動セルに対しては、次のように別の構成 HFS を用意することができます。
    /WebSphere/V6_prod
                  /CorpServer1  - home to Network Deployment cell CSCELL, with deployment manager CSDMGR and server CSSR01A

マルチシステム z/OS シスプレックス (HFS の共用なし) の場合:

マルチシステム・シスプレックスで HFS を共用しない場合には、 各 z/OS システムに、 それぞれ独自の構成ファイル・システム・データ・セットが必要です。 スタンドアロン・アプリケーション・サーバーや、 複数のシステムにまたがることのない Network Deployment セルでは、オプションは、 単一の z/OS システムの場合と同じです。

複数システムにわたる Network Deployment セルの場合:

この場合は、次の 2 つのオプションがあります。
  • 各システムで、セルの構成ファイル・システム・データ・セットに、 別々のマウント・ポイントを使用することができます。 こうすると、システム間のノードの移動 (例えば、 システムが操作不能になったり、アップグレードされたりした場合) が容易になります。 これは、それぞれのマウント・ポイントが、シスプレックス内の他のシステムでは未使用なので、 障害が発生したシステムの構成ファイル・システム・データ・セットをシスプレックス内の代替システムにマウントすることができるためです。

    例えば、システム LPAR1 では、セルの一部に構成ファイル・システムが必要になります。
        /var/WebSphere/V6config1
                          /DeploymentManager  - home to deployment manager F1DMGR in cell F1CELL
                          /AppServer1         - home to node F1NODEA and servers F1SR01A and F1SR02A
    また、 LPAR2 では 2 番目の構成ファイル・システムが必要です。
        /var/WebSphere/V6config2
                          /AppServer2         - home to node F1NODEB and servers F1SR02B (clustered) and F1SR03B
    このようなセットアップには、デプロイメント・マネージャーとノード F1NODEA を LPAR2 に移動したり、 あるいはノード F1NODEB を LPAR1 に移動したりできるという利点があります。この構成の欠点は、 F1NODEA と F1NODEB で、別々のカタログ式プロシージャー・セットが必要だということです。
  • あるいは、特定セルでは、すべての構成ファイル・システム・データ・セットに対して、 同じマウント・ポイントを使用することができます。 こうすると、共通のカタログ式プロシージャーを使用して、 システムを同じように見せることができます。

    次の例では、上記と同じセル・セットアップを使用して、 ノード LPAR1 に構成ファイル・システムを 1 つ設定します。
        /var/WebSphere/V6F1
                          /DeploymentManager  - home to deployment manager F1DMGR in cell F1CELL
                          /AppServer1         - home to node F1NODEA and servers F1SR01A and F1SR02A
    また、 LPAR2 には、同じマウント・ポイントに別のファイル・システムが割り当てられます。
        /var/WebSphere/V6F1
                          /AppServer2         - home to node F1NODEB and servers F1SR02B (clustered) and F1SR03B
    しかし、 いずれかの LPAR のノード (複数可) を他のシステムに再配置する場合は、 1 つの構成ファイル・システムのコピーを別の構成ファイル・システムにマージする必要があります。

マルチシステム z/OS シスプレックス (共用 HFS) の場合:

シスプレックスに共用階層ファイル・システムが備わっている場合は、 セル全体で使用する大規模な構成ファイル・システムをマウントすればよいだけです。 カスタマイズ・ダイアログを使用する際に、 各システムで共通の構成ファイル・システムのマウント・ポイントを指定します。 前述のように、 構成ファイル・システムの更新は、デプロイメント・マネージャーをホストしている z/OS システムから行います。 パフォーマンスは、構成変更の頻度によって決まります。このオプションを選択する場合は、 必ず、十分な調整を行ってください。

あるいは、 次のように、各システムの /&SYSNAME にマウントされているシステム固有のファイル・システムを使用して、 各システムで別々の構成ファイル・システムをマウントすることもできます。
    /LPAR1/WebSphere/V6F1
                        /DeploymentManager  - home to deployment manager F1DMGR in cell F1CELL
                        /AppServer1         - home to node F1NODEA and servers F1SR01A and F1SR02A

    /LPAR2/WebSphere/V6F1
                        /AppServer2         - home to node F1NODEB and servers F1SR02B (clustered) and F1SR03B
各システム (LPAR1 と LPAR2) は、 それぞれのシステム固有のマウント・ポイントで、 独自の構成ファイル・システムをマウントします。 カスタマイズ・ダイアログを使用する場合は、次のように指定してください。
  • /LPAR1/WebSphere/V6F1 (LPAR1 の場合)
  • /LPAR2/WebSphere/V6F1 (LPAR2 の場合)
このオプションの方が、共用シスプレックスよりパフォーマンスに優れています。 また、マウント・ポイントの選択によっては、元の所有システムがダウンした場合に、 構成ファイル・システムを一時的に別の LPAR にマウントすることもできます。 構成ファイル・システムのマウント・ポイントを選択するには、 カタログ式プロシージャーをシステム固有にするか、&SYSNAME を使用します。
すべての構成ファイル・システム・データ・セットで同じ明確なマウント・ポイントを使用する必要がある場合 は、 次のように、シンボリック・リンクを使用して、共通マウント・ポイントを各システム上の別のファイル・システムに指定変更します。
  • -s $SYSNAME/WebSphere WebSphere において、
  • /LPAR1/WebSphere/V6F1 で、LPAR1 の構成ファイル・システムをマウントします。
  • /LPAR2/WebSphere/V6F1 で、LPAR2 の構成ファイル・システムをマウントします。
これが正しく実行されると、 カスタマイズ・ダイアログで各システムの /WebSphere/V6F1 の構成マウント・ポイントを指定できるようになり、さらに、 システム固有のカスタマイズ・ファイル・システム・データ・セットの利点を享受することもできます。 ただし、このセットアップを使用すると、構成ファイル・システム・データ・セットをシステム間で、 簡単に移動することはできなくなります。 すべてのノードのデータは、/WebSphere/V6F1 に入ることになっており、 各システムのこのマウント・ポイントでは、構成ファイル・システムを 1 つしかマウントすることができません。
推奨:
  • 単一の z/OS システムの場合:
    • /WebSphere/V6R0 で構成ファイル・システムを作成し、それを使用して「練習用」スタンドアロン・サーバーを作成します。 同じ構成ファイル・システムに、追加の非実動スタンドアロン・アプリケーション・サーバーのホーム・ディレクトリーを配置します。
    • /WebSphere/V6R0_cell_short_name に、 実動スタンドアロン・サーバーまたは Network Deployment セルごとに別々の構成ファイル・システムを作成します。
  • マルチシステム・シスプレックス (ファイル・システムの共用なし) では、 単一の z/OS システムに対する前述の推奨事項に従ってください。 そうすると、 各セルで共通のカタログ式プロシージャーが使用できるようになります。 シスプレックス内の代替システム上でリカバリーする必要のある任意のセルに対しては、 各システムで別々のマウント・ポイントを設定します。
  • マルチシステム・シスプレックス (共用ファイル・システムあり) では、パフォーマンスが問題にならない場合、 あるいは WebSphere Application Server for z/OS の特定の機能をサポートするた めに共用ファイル・システムが必要になる場合に、共用の構成ファイル・システムを使用します。 パフォーマンスが問題になる場合、 あるいは Single Point of Failure を回避しなければならない場合には、 非共用の構成ファイル・システム・データ・セットを使用してください。

WebSphere Application Server のホーム・ディレクトリー名の選択

WebSphere Application Server のホーム・ディレクトリーは、常に、 それが置かれている構成ファイル・システムを基準に表されます。 したがって、カスタマイズ・ダイアログでは、 ある 1 つのパネルで構成ファイル・システムのマウント・ポイントを選択すると、別のパネルでは、 ホーム・ディレクトリーの単一のディレクトリー名だけを記入します。 ただし、サーバーの WAS_HOME ディレクトリーに移動するようにという指示では、 構成ファイル・システムとホーム・ディレクトリー名を結合したパス名全体のことを言っています (例えば、/WebSphere/V6R1/AppServer です)。

ホーム・ディレクトリーには、 構成ファイル・システム内で固有である場合、任意の名前を選択することができます。 スタンドアロン・アプリケーション・サーバーまたは新規の管理対象サーバー・ノードを作成して、 Network Deployment セルに統合する場合は、 Network Deployment セルの構成ファイル・システムで使用されていないものを選択してください。

システムごとにノードが 1 つずつある場合は、 何らかの形式のノード名またはシステム名を使用することができます。 あるいは、デプロイメント・マネージャーの場合は「DeploymentManager」、 各アプリケーション・サーバー・ノードの場合は「AppServern」を使用することもできます。

構成ファイル・システムと製品 HFS の関係

構成ファイル・システムには、 製品 HFS (デフォルトで (/usr/lpp/zWebSphere/V6R1) 内のファイルへのシンボリック・リンクが多数含まれています。 これによって、サーバー・プロセス、管理者、およびクライアントが、 一貫した WebSphere Application Server for z/OS コード・ベースにアクセスできるようになります。

これらのシンボリック・リンクは、WebSphere Application Server ホーム・ディレクトリーの作成時にセットアップされるので、 変更が容易ではありません。 したがって、高可用性を必要とするシステムでは、 システム保守を可能とするために、使用中の各保守レベルおよびサービス・レベル (テスト、確認、実動など) ごとに、 WebSphere Application Server for z/OS の製品 HFS と製品データ・セットのコピーを別々に保管し、 中間シンボリック・リンクを使用して、各構成 HFS をその製品 HFS と接続するようにしてください。

ヒント: カスタマイズ・ダイアログで製品 HFS パスにデフォルト値を使用して Network Deployment 環境を構成すると、 その結果、すべてのノードが直接製品 HFS のマウント・ポイントを指すようになります。 これにより、非破壊的な方法でローリング保守を行うことがほとんど不可能になります。 セルがこの方法で構成されている場合は、 製品 HFS にサービスを適用するとすべてのノードが同時に影響を受けます。 また、複数のセルがこの方法で構成されている場合は、製品 HFS にサービスを適用するとすべてのセルが同時に影響を受けます。 各ノードの構成 HFS と製品 HFS の実際のマウント・ポイントの間に、 いわゆる「中間シンボリック・リンク」と呼ばれるものを指定する場合もあります。 この戦略については、ホワイト・ペーパー「WebSphere Application Server for z/OS V5 - Planning for Test, Production and Maintenance」に説明があります。 この問題と保守の適用との関連について詳しくは、 ホワイト・ペーパー「WebSphere z/OS V6 -- WSC Sample ND Configuration」を参照してください。 詳しくは、「WebSphere for z/OS: Updating an Existing Configuration HFS to Use Intermediate Symbolic Links」を参照してください。 既存の構成 HFS を更新して、中間シンボリック・リンクを使用できるようにするユーティリティーの取得と使用に関する情報があります。

WebSphere Application Server for z/OS ノードの始動時には、 構成のサービス・レベルが、製品ファイル・システムのサービス・レベルと比較されます。 構成ファイル・システムのサービス・レベルが 製品ファイル・システムのサービス・レベルより高い場合 (古い製品ファイル・システムがマウントされている可能性があることを意味します)、 そのノードのサーバーは、エラー・メッセージを出して終了します。 構成ファイル・システムのサービス・レベルが 製品ファイル・システムのサービス・レベルよりも低い場合 (ノードが最後に始動した後に、 サービスが製品コード・ベースに適用されたことを意味します) は、ポスト・インストーラーと呼ばれるタスクが、 最新の状態に保つために構成ファイル・システムで実行する必要があるアクションを検査します。 ポスト・インストーラーについて詳しくは、製品保守の適用 を参照してください。




関連概念
カタログ式プロシージャー
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/cins_planfs.html