Apache プロセス管理および処理能力の計画
Apache は、UNIX® オペレーティング・システム向けに 3 つのプロセス管理モジュールを提供しています。 このアーキテクチャでは、InterSystems Web ゲートウェイ・モジュールは Apache ワーカ・プロセスに直接バインドされます。 したがって、プロセス・プールを管理するための Apache の構成方法が、Web ゲートウェイに直接の影響を与えます。
Apache は各プロセス管理モデルをマルチプロセッシング・モジュール (MPM) として実装します。
Prefork MPM は、従来のマルチプロセス (UNIX®) サーバ・アーキテクチャです。これはスレッドを使用しないため、サードパーティの API モジュール (DSO) がスレッドセーフである必要はありません。参照 ： http://httpd.apache.org/docs/current/mod/prefork.htmlOpens in a new tab
Worker MPM は、より新しいマルチスレッド/マルチプロセスのハイブリッド型サーバ・アーキテクチャです。 これはスレッドを使用するため、使用されるすべてのサードパーティ製 API モジュール (DSO) はスレッドセーフであることが必要です。参照 ： http://httpd.apache.org/docs/current/mod/worker.htmlOpens in a new tab
Event MPM は、一部の処理作業をリスナ・スレッドに渡してワーカ・スレッドを解放し、新しい要求を処理できるようにすることで、より多くの要求を同時に処理できるように設計されています。参照 ： http://httpd.apache.org/docs/current/mod/event.htmlOpens in a new tab
どちらのサーバ・モデルが既存のインストールに使用されているかを判別するには、Apache 実行可能プログラムを次のように修飾して直接呼び出します。
httpd -V
さらに、以下の 2 つの関連する詳細リストが用意されています。
Web ゲートウェイ DSO はスレッドセーフで、どのサーバ・モデルにも展開できます。Apache の調整に関する役立つガイドが、http://httpd.apache.org/docs/current/misc/perf-tuning.htmlOpens in a new tab にあります。
セキュリティ
3 つのサーバ・アーキテクチャすべてで、親プロセスは、TCP ポート 80 にバインドするために、通常、スーパーユーザ特権が割り当てられたアカウント (UNIX® の root) から開始します。 Apache が起動する子プロセスは、特権の少ないユーザとして実行されます。(Apache 構成内の) User および Group 指示文は、Apache 子プロセスの特権を設定するために使用されます。 子プロセスは、それらが処理するすべてのコンテンツを読み取る能力 (および Web ゲートウェイの構成およびイベント・ログ・ファイルへの読み取り/書き込みアクセス権) が必要ですが、これ以外に付与する特権は最小限にする必要があります。詳細は、Apache ドキュメントを参照してください。
Apache MPM と Web ゲートウェイ DSO
Web ゲートウェイ・ダイナミック・リンク・モジュール (DSO) はスレッドセーフで、どのサーバ・モデルにも展開できます。
StartServers 指示文は、すべてのマルチプロセッシング・モジュール (MPM) について、開始する子 (ワーカ) プロセスの数を指定します。 この指示文はまた、存在できる Web ゲートウェイ DSO のインスタンスの数を示します (例 ： Apache の子プロセスごとに 1 つ)。
すべての MPM が、複数の子 (ワーカ) プロセスにわたる負荷分散に関係します。
各ゲートウェイ・インスタンスはすべての Apache 子プロセスそれぞれによって個々にロードされますが、実行中の構成、接続テーブル、およびフォーム・キャッシュは共有メモリ・セクタに保持されます。 Web ゲートウェイ・システム・ステータス・フォームのコンテンツは、更新しても同じになります (もちろん、アクティビティの更新結果による変更は除きます)。 表示される接続テーブル (および接続数) は Apache インスタンス全体に共通で、この理由から、各 InterSystems IRIS 接続が関連付けられる Web サーバ・プロセス ID を示す追加列が含まれます。
サーバ接続最大数
Web ゲートウェイの負荷は複数の Web サーバ・プロセスに分散されますが、サーバ接続最大数パラメータは、Web ゲートウェイが特定の InterSystems IRIS サーバに対して確立できる接続数についての全体的な制限を 1 つだけ設定します。つまり、ホスト Web サーバによって開始されるワーカ・プロセスの数は、Web ゲートウェイが作成できる最大接続数に影響を与えません。この最大数は、接続を行うプロセスのタイプや使用中の MPM の影響も受けません。(このモデルは、サーバ接続最大数パラメータがプロセスごとに影響を受け、複数の要因の影響を受ける一般的なスロットルとして機能していた、以前のバージョンからの変更を表しています。)
Apache の負荷のほとんどがインターシステムズのファイル・タイプから構成されるインストールでは、Web ゲートウェイのサーバ接続最大数指示文に値を指定しないで、対応する Apache 構成パラメータを使用して実行できる並行作業量 (したがって、InterSystems IRIS への接続数) を制御することをお勧めします。ただし、インターシステムズのファイル・タイプが Apache インストール全体の負荷の一部でしかないインストールでは、Web ゲートウェイのサーバ接続最大数指示文に独立した値を設定するのは有効です。
ステート認識セッション (保持モード 1)
複数のワーカ・プロセスに負荷を分散する Web サーバでのステート認識セッションのサポートは、個々のワーカ・プロセス間の要求の転送を管理する IPC (プロセス間通信) プロトコルに依存します。この Web サーバ・アーキテクチャで動作する Web ゲートウェイは、どのワーカ・プロセスが特定の要求を処理するかを制御することはできません。
Web ゲートウェイはその IPC プロトコルに UNIX® ドメイン・ソケットを使用します。ステート認識セッションをサポートする方法について、以下に説明します。
例として、P1、P2、および P3 の 3 つのワーカ・プロセスに負荷を分散する Web サーバ・インストールについて考えてみましょう。 各ワーカ・プロセスは、使用されている Web サーバの MPM と構成に従って、任意の数のスレッド (T1、T2 … Tn) を開始できます。
アプリケーションがそのセッションをステート認識 (保持モード 1) とマークする要求を行い、Web ゲートウェイがプロセス P2 でその指示を認識すると仮定します。 今ではプライベートの InterSystems IRIS プロセスへの接続 (およびセキュリティ・コンテキスト) は Web サーバのワーカ・プロセス P2 によってホストされます。 そのユーザ/セッションに対する以降の要求は、すべてワーカ・プロセス P2 で処理する必要があります。 ただし、Web ゲートウェイは Web サーバが以降の要求をどのワーカ・プロセスに転送するかを制御できないため、Web ゲートウェイは P2 と (可能性として) そのセット内の他の任意のワーカ・プロセスとの間で IPC チャンネルを確立する必要があります。
Web ゲートウェイは P2 でステート認識として接続をマークすると、別個の分離されたスレッドで待ち受けサービスを開始します。 ログ・レベル v2 の場合は、以下のようなメッセージがイベント・ログに書き込まれます。
IPC Server
Process ID: 28457 Listening on Domain Socket: /tmp/csp28457.str
次に、例えば、同じセッションに対するさらなる要求がワーカ・プロセス P3 によって処理されると仮定します。 Web ゲートウェイはその要求を、以前に確立された IPC チャンネルを介してプロセス P2 に転送し、応答を待機します。 ログ・レベル v2 の場合は、以下のようなメッセージが記録されます。
Route request over IPC to another web server process
PrivateSession=2; pid_self=28456; ipc_to_pid=28457;
もちろん、そのセッションに対する要求が Web サーバによって P2 に直接転送される場合は、P2 がセッションのプライベート接続をホストしているため、Web ゲートウェイ環境でさらなる転送は必要ありません。
以前作成された IPC チャンネルに Web ゲートウェイが接続して要求を転送できない場合は、エラーが発生したコンテキストに応じて以下のメッセージのいずれかが記録されます。
IPC CLIENT: Error
Cannot connect
または
IPC CLIENT: Error
Cannot send request
この領域で問題が発生する最も一般的な理由は、Apache がワーカ・プロセスを閉じたこと (またはリサイクルしたこと) です (P2 の例の場合)。 もちろん、(アクセス違反/SIGSEGV エラーなどで) プロセスはクラッシュし、この場合は、おそらくエラー・メッセージが Apache エラー・ログに報告されます。
Apache はまた、既定では、ワーカ・プロセスを定期的にリサイクルします。
ステート認識セッションを使用する場合は、以下のようにインストールを構成して、ワーカ・プロセスをリサイクルしないように Apache を構成してください。
(おそらくモジュールの故障が原因で) Apache が定期的にプロセスをリサイクルするのを阻止できない場合に、ステート認識セッションを使用する必要があるときは、NSD ベースのゲートウェイ構成を使用できます。 NSD ベースのアーキテクチャは、Web ゲートウェイのプロセス管理を Web サーバから効果的に切り離すため、前述の問題を回避します。 Web ゲートウェイの Network Service Daemon (NSD) を使用する際のオプションについては、"Microsoft Windows での NDS の使用方法" および "UNIX®、Linux、および macOS での NSD の使用方法" を参照してください。
