CSP ゲートウェイの概要

ゲートウェイ・コンポーネントと物理的なインストール・パス

このドキュメントの後半のセクションでは、サポートされているすべての Web サーバを使用してゲートウェイ・コンポーネントを構成する方法を説明します。 コンポーネントのインストール・パスは、文字どおり受け取るのではなく、例として考えてください。 また、インターシステムズのインストーラは、同じホスト上に存在する可能性のある内部 (プライベート) Web サーバとサードパーティの Web サーバ用に別個のゲートウェイ・インストールを作成して維持します。 ここでは、「サードパーティの Web サーバ」は、インターシステムズがインストールしたソフトウェアの一部ではない Web サーバを指します。

ゲートウェイ・コンポーネントの正確なインストール場所は、以下の場合は特に重要ではありません。

• 物理的なインストール・パスが、ホスト Web サーバの適切な構成で指定されたものと一致する場合。

• 個々のコンポーネントに対する必要なアクセスに関連するセキュリティ設定が、適切に調整されている場合。 Web サーバは通常、それらがアクセスできるファイル (および実行できる実行可能ファイル) を慎重に制御できるようにロック・ダウンされているため、これは Web サーバが直接アクセスするゲートウェイ・コンポーネントにとって特に重要です。 それら自身が Web サーバのコア実行可能ファイルにバインドしている、ゲートウェイ・バイナリがアクセスするゲートウェイの構成 (およびログ) ファイルでは、セキュリティの考慮も重要であることに注意してください。

• ホスト Web サーバのセキュリティ・ポリシーが配慮されている場合。 一部の Web サーバ (特に Secure Linux (SELinux) や OpenVMS (HPSWS) に同梱の Web サーバ) は、自らのファイル・システム外に置かれたファイルにはアクセスできないように構成されています。 この制限により、Web サーバに対面する特定ゲートウェイ・コンポーネントをインストール可能な場所が明らかに左右されます。

次の 4 種類のゲートウェイ・コンポーネントを考慮する必要があります。

1. Web サーバがロードするバイナリ (API ベースの拡張)。

   これには、Windows DLL、UNIX 共有オブジェクト、および OpenVMS 共有可能イメージが含まれます。

   CSPms[Sys].dll
   CSPn3[Sys].(dll|so|exe)
   CSPa*[Sys].(dll|so)
   mod_csp*.(so|exe)
   

   

   これらがインストールされる物理的な場所は、ホスト Web サーバ構成の対応する構成の指示文と一致することが必要です。 これには、ロードする必要があるサードパーティ・モジュールを示す指示文が含まれます。 Web サーバは、これらのモジュールを読み取ってロードするためのアクセス許可を必要とします。 CSP* という名前のモジュールは、ゲートウェイ構成ファイルおよびログ・ファイル (CSP.ini、CSP.log) に対する読み取りおよび書き込み許可が必要です。 これらは通常、ゲートウェイ・バイナリと同じ場所に作成されます。

   これらのモジュールへのアクセス制御を考慮する際、依存する構成ファイルおよびログ・ファイルと共にモジュールにアクセスできる必要があるのは、Web サーバのワーカ・プロセスであることに注意してください。 例えば、Apache の場合は、サーバは通常、スーパーユーザの権限で開始されますが、実際に Web 要求を処理するワーカ・プロセスは、これよりはるかに下位の権限 (Apache 構成ファイル内で User および Group 指示文で指定) で実行されます。 ワーカ・プロセスに指定されたユーザとグループには、ゲートウェイ・モジュールをロードするためのアクセス許可と (適切な場合は) 構成ファイルおよびログ・ファイル (CSP.ini および CSP.log) の読み取りおよび書き込み許可を付与する必要があります。

2. Web サーバが呼び出す実行可能ファイル (CGI モジュール)。(すべての構成でこれらの実行可能ファイルが必要なわけではありません。)

   [nph-]CSPcgi[Sys][.exe]
   

   

   これらがインストールされる物理的な場所は、ホスト Web サーバ構成の対応する構成の指示文と一致することが必要です。これには、これらの CGI モジュールが処理する必要がある Web 要求を示す指示文が含まれます。

   ホスト Web サーバのワーカ・プロセスは、これらのモジュールに対する実行許可を必要とします。 それ以上の依存関係はありません。

3. Web サーバが返す静的ファイル。

   Note:

   現在の CSP ゲートウェイ構成では、CSP はしばしば、Web サーバから静的ファイルを返すのではなく、Cache から直接静的ファイルを提供するように構成されます。 このセクションは、このような構成には適用されません。

   JavaScript モジュール (CSPBroker.js、CSPxmlhttp.js など)

   Java アプレット (CSPBroker.class、CSPBroker.jar など)

   イメージ (created-with-csp.gif など)

   ホスト Web サーバのワーカ・プロセスは、これらのファイルに対する読み取り許可を必要とします。

4. CSP NSD (Network Service Daemon)。

   Note:

   すべての構成がこの機能を必要とするわけではありません。

   CSPnsd[Sv][.exe]
   

   

   これは任意の場所にインストールすることができ、これと Web サーバとの通信はTCP (通常はポート 7038) によって行われるため、Web サーバがその物理的場所を認識する必要はありません。

   NSD は、ゲートウェイ構成ファイル (CSP.ini) およびログ・ファイル (CSP.log) に対する読み書きの許可を必要とします。通常、それらは同じ場所に作成されます。

   Note:

   セキュリティの理由から、このモジュールは Web サーバからアクセスできる場所にはインストールしないでください。 このモジュールは、手順 1、2、または 3 にリストされているモジュールと同じ場所にインストールするべきではありません。このドキュメントで説明されている多くの Web サーバ構成では、Web サーバがアクセスできるアクセス可能ファイルのリストからこのモジュールを明示的に除外しています。 そうではあっても、ファイル・システムの他の場所に NSD を物理的にインストールするほうが、はるかに安全です。

可能であれば、ゲートウェイは、永続ストレージで、大きいファイル (Zen アプリケーションの大きい JavaScript ファイルなど) のコンテンツを、付随する HTTP 応答ヘッダとともに検索します。 重要な制御情報 (有効期限など) およびキャッシュされたすべてのファイルのインデックスは、共有メモリ・セクタにあります。 このアーキテクチャでは、キャッシュ・エントリそれぞれが (メモリ使用状況に関して) 小さなキャッシュ・スペースを使用します。エントリあたり 1 キャッシュ・ブロックのみの場合もあります。

キャッシュされたコンテンツは、ゲートウェイの temp ディレクトリにあるタイプ .dat のファイルに保存されます。このディレクトリは、インストール・スクリプトによって、ゲートウェイのインストール・ディレクトリの直下に配置されます。 例えば、通常の IIS インストールでは、C:\inetpub\CSPGateway\temp となります。 この場所は、ホスト Web サーバのワーカ・プロセスに対する完全な読み取り/書き込み/削除許可が必要です。

Ensemble のための CSP ゲートウェイの構成

CSP ゲートウェイは、Caché と Ensemble の両方の製品群に対して、Web 接続を提供します。どちらの場合も、ゲートウェイ・コンポーネントは同じです。Caché のインストールでゲートウェイがインストールされると、Ensemble への Web 接続が提供されます。逆の場合も同様です。

このドキュメントでは簡単にするために、Caché をインストールした場合の使用法について説明します。既定のパス名を除いて、このドキュメントに示す手順は Ensemble にも同様に適用できます。既定の Ensemble 名では Cache が Ensemble に置き換えられます。

ゲートウェイ管理モジュールの構成

ゲートウェイ・アーキテクチャは、ホスト Web サーバの API に直接機能し、通常は管理モジュール (CSPmsSys.dll など) とランタイム・モジュール (CSPms.dll など) の 2 つのモジュールから構成されます。 ランタイム・モジュールは CSP ファイルに対する要求を処理し、管理モジュールはゲートウェイの管理インタフェースを提供します。 CSP ゲートウェイでは、ランタイム・モジュールが管理モジュールに対する管理要求をロードおよび転送します。CSP ゲートウェイに対するすべての要求 (CSP および管理) は、ランタイム・モジュールによって処理されます。 管理モジュールはランタイム・モジュールと同じ場所にインストールする必要があります。

CSP で処理されるファイルの種類

Caché では、CSP によって処理されるファイルの種類は、.csp、.cls、および .zen です。 その他のファイル (静的ファイル) はすべて Web サーバまたは CSP によって処理されます。 CSP は CSP アプリケーション・パスに配置されているあらゆる種類のファイルを処理できます (静的ファイルを含む)。 静的ファイルを処理するための CSP の設定により、アプリケーションの静的ファイルが存在する場所を表すために Web サーバ構成にエイリアスを作成する必要がなくなるので、CSP アプリケーションの Web サーバ構成はより単純化されます。 静的ファイルを提供するように CSP を設定することで、単一 (共通) の Web サーバで 2 つの異なるバージョンの Caché を提供する場合に、それぞれで異なるバージョンの特定の静的ファイル (例えば、ハイパーイベントのブローカ・コンポーネント) を必要とするといった競合上の問題を解決できます。

特定の CSP アプリケーションの静的ファイルを CSP で提供するには、静的ファイルを (Web サーバ独自のドキュメント・ファイル・システムではなく) CSP アプリケーションのファイル・システム内の、アプリケーションを構成する CSP ファイルに関する適正位置に配置します。 (Unicode テキストを含むファイルを提供する場合、CSP は BOM を使用して適切なエンコードを判断します。そのため、BOM が Unicode テキスト・ファイル内に存在する必要があります。)

各自のプラットフォームごとの操作については、このドキュメントの各セクションを参照してください。

Caché からの静的ファイルの提供

Caché が静的ファイルを提供できるように Web サーバおよびゲートウェイ・インストールを構成できます。 Caché がすべてのコンポーネントをアプリケーションに提供するように、管理ポータルおよび Zen サンプルが構成されて提供されています。 ただし、Web サーバが静的ファイルを提供する機能を保持するように Web サーバを構成することも可能です。

マルチ・プロセス/マルチスレッドのハイブリッド型 Web サーバ・アーキテクチャ

ゲートウェイには、マルチ・プロセス/マルチ・スレッドのハイブリッド型 Web サーバ・アーキテクチャの拡張サポートが含まれています。 UNIX の Apache バージョン 2.x.x は、このアーキテクチャに従って実装された Web サーバの例です。

ゲートウェイの以前のビルドでは、スタンドアロン・モジュール (CSPa2*[Sys].so) はサポートされていましたが、それぞれのホスト Web サーバのワーカ・プロセスは、結合してゲートウェイの独立したインスタンスを作成していました。 つまり、各ワーカ・プロセスは、ゲートウェイの独自のインスタンスをロードし、次にこれが実行する構成の独自のコピーをロードし、独自の接続テーブルおよびフォーム・キャッシュを管理します。 ゲートウェイ・システム・ステータス・フォームで [更新] を選択するたびに、この動作の主な観察できる症状が変化します。 ステータス・フォームの更新それぞれは、ステータス・フォームの要求を処理することになるワーカ・プロセスおよびゲートウェイ・インスタンスのみのステータスになります。 また、ステート認識モード (保持モード 1) は、マルチ・プロセス・アーキテクチャではサポートできません。その理由は、このモードの処理では、セッションのすべての要求を同じ Caché プロセスにルーティングできること、つまり Caché へのすべての接続を単一のマルチスレッド・プロセスに保持する必要があるためです。

すべてのゲートウェイ・リソースがすべての Web サーバ・プロセス間で重複しているアーキテクチャは不要であり、むだです。

コア・ゲートウェイ・リソースは、共有メモリ・セクタに保持されるようになりました。 すべての Web サーバのワーカ・プロセスは、共通の実行中構成、接続テーブルおよびフォーム・キャッシュを共有します。 ゲートウェイ・システム・ステータス・フォームには、単一のワーカ・プロセスのステータスのみではなく、Web サーバのインストール全体のステータスが表示されます。 ステータス・フォームの接続テーブルには、Caché への各接続に対応する Web サーバ・プロセス ID を含む追加の列が含まれます。

最後に、ステート認識セッションはマルチプロセス・アーキテクチャでサポートされます。 (Caché への) 接続プールはいくつかの Web サーバ・プロセス間で配布されますが、ゲートウェイは IPC (InterProcess Communications) プロトコルを使用して、ステート認識セッションの要求を Web サーバ環境の正しいホスティング・プロセスにルーティングします。

ゲートウェイ・レジストリ

ゲートウェイは、新しい Caché ベースのゲートウェイ・レジストリを使用して提供されます。 すべての Web サーバおよびゲートウェイのインストールは、接続時に Caché に登録されます。 レジストリには、構成を読み書きし、システム状態およびイベント・ログを監視するために、Caché コードで接続したゲートウェイ・インストールと通信できるインフラストラクチャが含まれています。

高可用性ソリューションのハードウェア・ロード・バランサでのスティッキー・セッションの有効化

CSP 上で実行している高可用性ソリューションについては、ハードウェア・ロード・バランサを使用して負荷分散とフェイルオーバーを行うことをお勧めします。この場合のロード・バランサでは、スティッキー・セッションのサポートを有効にする必要があります。これにより、ゲートウェイの指定したインスタンスと指定のアプリケーション・サーバとの間でセッションを確立しておけば、そのユーザがそれ以降に発行するすべての要求は、必ず同じインスタンスとサーバの組み合わせで処理されるようになります。この構成では、セッション ID とサーバ側のセッション・コンテキストが常に同期していることが保証されます。この構成を使用しない場合は、セッションがあるサーバ上で生成されたにもかかわらず、そのユーザからの次の要求はこのセッションが存在しない別のシステムで処理される可能性があり、その結果として実行時エラーが発生します (特に、要求を復号化するためにセッション・キーを必要とするハイパーイベントを使用している場合)。 スティッキー・セッションのサポートを有効にする方法については、使用しているロード・バランサのドキュメントを参照してください。

ゲートウェイ構成を再起動するスクリプトの有効化

外部 (非 Cache ベース) スクリプトを有効にして、ゲートウェイ構成を再起動することができます。

スクリプトでは、ゲートウェイの構成ファイルの SYSTEM セクションに次の行 (大文字と小文字が区別される) を追加する必要があります。

   [SYSTEM]
   RELOAD=1

ゲートウェイ・ケアテイカー・デーモンは、ほぼ 1 分おきに RELOAD フラグを確認し、正しく設定されていれば、その構成を再ロードおよび再起動して、ファイルからフラグを削除します。 再ロード操作が成功すると、以下のメッセージがイベント・ログに書き込まれます。

   Gateway Management
   Gateway Configuration Reloaded and Reactivated

プライベート Web サーバの構築

(既定の) 完全な Apache サーバは、通常、次のコマンドのシーケンスを使用して作成されます。

./configure --prefix=<install-dir>
make
make install

一般的に、Apache の最小ビルドは以下のように作成されます。

./configure --prefix=/usr/cachesys/httpd --with-port=57772 \
            --with-pcre=$srcdir/pcre \
            --enable-mods-static="log_config mime alias unixd authz_core" \
            --disable-ssl \
            --enable-so --without-gdbm --without-ndbm \
            --without-berkeley-db --with-included-apr --with-expat=builtin \
            --with-mpm=prefork --disable-shared
make
make install

ここでは、通常はプロダクション・グレードのインストールに必要なサービスの多くが除外されている点に注意してください。

このサーバを他の CSP アプリケーションのホストに使用することは可能ですが、その目的では完全な独立した Web サーバのインストール環境を使用することを強くお勧めします。ホストの Caché インストールをアップグレードすると、管理ポータルの Apache インストールの構成に対する変更が上書きされる点に注意してください。

管理ポータルの Apache インストール環境は、次の CSP ゲートウェイ・モジュールを使用して Caché と通信します。

• Windows：CSPa2.dll および CSPa2Sys.dll

• UNIX®：CSPa2.so および CSPa2Sys.so

• OpenVMS：インターシステムズでは、OpenVMS システムに対応する Apache インストールを提供していません。これらのシステムの場合、リモートの OpenVMS 以外のプラットフォームで動作する Web サーバ (および CSP ゲートウェイ) のインストール、またはヒューレット・パッカードから提供される Apache Web サーバのいずれかを使用して管理ポータルをホストできます。この Apache Web サーバは HP Secure Web Server (SWS) として知られ、Apache に基づくものです。具体的には、SWS バージョン 2.2 が Apache バージョン 2.0.63 に基づいています。

プライベート Web サーバの管理

通常の動作環境では、Caché を起動すると特定の Caché インスタンスの管理ポータル Web サーバも起動し、Caché を停止すると Web サーバも終了します。場合によっては、対応する Caché サーバを中断せずに管理ポータル Web サーバを再起動する必要があります。例えば、Web サーバの構成 (httpd.conf) を変更した場合に、Web サーバを再起動する必要があります。

管理ポータル Web サーバを起動および停止するには、以下のコマンドを使用します。

管理ポータル Web サーバの起動 ：

<cache-install-dir>\httpd\bin\httpd -k start -n <instname>httpd -c "Listen <port>"

管理ポータル Web サーバの停止 ：

<cache-install-dir>\httpd\bin\httpd -k stop -n <instname>httpd

Caché のインストール場所 ： C:\cachesys

Caché インスタンス名 ： CACHE

Apache の TCP ポート ： 57772

起動 ：

C:\cachesys\httpd\bin\httpd -k start -n CACHEhttpd -c "Listen 57772"

停止 ：

C:\cachesys\httpd\bin\httpd -k stop -n CACHEhttpd

管理ポータル Web サーバの起動 ：

<cache-install-dir>/httpd/bin/httpd -d <cache-install-dir>/httpd -c "Listen <port>"

管理ポータル Web サーバの停止 ：

kill `cat <cache-install-dir>/httpd/logs/httpd.pid`

Caché のインストール場所 ： /usr/cachesys

Apache の TCP ポート ： 8972

起動 ：

/usr/cachesys/httpd/bin/httpd -d /usr/cachesys/httpd -c "Listen 8972"

停止 ：

kill `cat /usr/cachesys/httpd/logs/httpd.pid`

プライベート Web サーバの制限

この節では、PWS の構成と通常のプロダクション・グレードの Apache インストールの構成の違いについて説明します。

Windows ベースの Apache インストールでは、オペレーティング・システムの最適化方法により適した特殊なマルチスレッド形式の Apache マルチプロセッシング・モジュール (MPM) を使用します。 したがって、Windows での PWS の動作は、同時に発生する負荷を処理する機能に関する限り、プロダクション・グレードでの Apache の構築の動作と似ています。

高可用性およびプロダクション・グレードのセキュリティが必要になる場合、Web 情報の他のソースと統合する必要がある場合、または Web サーバに対する高度な制御を必要とする場合は、Apache の別のプロダクション・グレードの構築をお勧めします。この場合、独自のサーバで動作することが理想です。 一方、予期される HTTP トラフィックが少量で、高可用性やセキュリティに対する要求がそれほどない場合、このような状況で PWS を導入することは適切です。

既定では、PWS は Apache グループの Prefork マルチプロセッシング・モジュール (MPM) を使用します。 これは、非スレッド化サーバ・モデルです。同時に処理できる要求の数は、プール内の Apache ワーカ・プロセスの数に直接関係します。

PWS は、プールに対して作成を許可するワーカ・プロセスの数を 2 つまでとすることで、占有するフットプリントが最小限になるように構成されています。 PWS に対する Apache 構成 (httpd.conf) の設定は以下のようになります。

MinSpareServers 1
MaxSpareServers 2

一方、プロダクション・グレードの構築に対する既定の Apache 構成は、通常以下のとおりです。

StartServers       5
MinSpareServers    2
MaxSpareServers   20
ServerLimit      256
MaxClients       256

この構成によって、Apache は起動時に 5 つのワーカ・プロセスを作成でき、同時に発生する負荷の増加に伴って最大 256 個まで増やすことが可能です。 構成においてこのような違いがあるために、PWS のパフォーマンスは、プロダクション・グレードでの Apache の構築のパフォーマンスよりも明らかに劣るようになります。 このパフォーマンス不足は、同時に発生する負荷が増加するにつれて、より目立つようになります。 ただし、PWS の構成を変更して、完全な Apache インストールの構成 (上記) に合わせることができます。 これらのパラメータを変更した後に、Apache を完全に再起動する必要があります。