方法
ここでは、インストール後の Enterprise Server の構成方法について説明します。 この構成では、Directory Server と個別のエンタープライスサーバの両方の属性も設定します。 また、パフォーマンスの考慮事項についても説明します。
Enterprise Server を初めて起動する場合は、次の処理が必要です。
Enterprise Server をインストールすると、デフォルトのエンタープライズサーバ ESDEMO が 1 つ作成されます。 このサーバはディプロイシステムサービスを提供します。Interface Mapping Toolkit を使用して COBOL サービスを自動的にディプロイすると、ディプロイサービスはサービスを受信し、サービスとその構成要素 (オペレーションとパッケージ) をエンタープライズサービスに追加します。 ディプロイサービスおよび関連するリスナーの構成が必要になる場合があります。詳細は、『ディプロイサービスとディプロイリスナー』を参照してください。
Directory Server の構成作業を行うには、まず環境を設定して Directory Server を起動する必要があります。 次の環境変数を設定する必要があります。
エンタープライズサーバ内からデータベースにアクセスする場合は、必要なライブラリを PATH 環境変数に追加し、さらに、使用している UNIX システムに応じて LIBPATH、SHLIB_PATH、または LD_LIBRARY_PATH 環境変数に追加する必要があります。 データベースにアクセスするための環境変数の設定についての詳細は、データベースのベンダーが提供するマニュアルを参照してください。
Directory Server を起動するコマンドは mfds です。 mfds コマンドを実行するには、root でログインする必要があります。
環境変数を設定するコマンドおよび Directory Server を起動するコマンドを起動シェルスクリプトに記述できます。この起動シェルスクリプトにより、マシンの起動時に Directory Server を自動的に起動できます。 Directory Server を起動するには TCP/IP が動作している必要があるため、mfds コマンドは、TCP/IP を起動するコマンドの後に記述する必要があります。 このようにコマンドを起動シェルスクリプトに記述すれば、Directory Server を起動する必要があるのは、マシンの起動後に Directory Server を停止した場合だけになります。
Directory Server は、セキュリティを使用可能または使用不能にして実行できます。 セキュリティを使用不能にして Directory Server を実行すると、すべてのユーザはエンタープライズサーバと Directory Server に変更を加えることができます。 常にセキュリティを使用可能にして Directory Serverity を実行することをお奨めします。
セキュリティは、ユーザ ID とパスワードを使用することで提供されます。 各ユーザ ID にはアクセス権レベルが関連付けられています。 Directory Server をインストールした直後はセキュリティが使用不能になっています。 一部のユーザ ID はセキュリティを使用可能にした場合にのみ使用するために提供されています。
管理者としての最初の作業は、セキュリティを使用可能にし、ユーザのログオン情報を作成することです。
セキュリティを使用可能にするには、Enterprise Server Administration への Web インターフェイスを開始する必要があります。次に、「構成オプション」ページで「ユーザアクセス制限」を選択します。
セキュリティを使用可能にすると、ユーザ ID とパスワードの入力がすぐに求められます。 次の構成済みのログオン情報を入力します。
| 「ユーザ ID:」 | schemaadmin |
| 「パスワード:」 | schemaadmin |
ユーザ ID schemaadmin には最も高いアクセス権レベル Schema Administrator が割り当てられているため、このユーザ ID の不正使用を防ぐ必要があります。 schemaadmin のパスワードはすぐに変更してください。 ユーザ ID schemaadmin を保護した後に、Schema Administrator アクセス権レベルをもつ新しいユーザ ID の作成が必要になる場合があります。 他のアクセス権レベルを割り当てたユーザ ID の新規作成や、すでに定義されているユーザ ID の削除も必要になる場合があります。
セキュリティとアクセス権レベルの詳細は、『Enterprise Server Administration の概要』の章を参照してください。
Directory Server のさまざまな属性を構成できます。たとえば、エンタープライズサーバが使用可能かどうかの監視、ジャーナルに記録するイベントの種類、Directory Server のクライアントがどのくらいの時間非アクティブの場合に自動的にログオフするかなどがあります。 これらのオプションの詳細は、「構成オプション」ページのヘルプを参照してください。
構成オプションの Process User ID については、注意が必要です。Process User ID はインストーラによってインストール時に提供されますが、後に「構成オプション」ページで変更できます。 変更する場合は、UNIX システムの既知のユーザ ID を使用する必要があります。 Process User ID は、Enterprise Server Administration の実行で起動されたすべてのエンタープライズサーバが動作する際に使用する UNIX ユーザ ID です。 Directory Server 自身も root として動作する必要があるため、Process User ID を指定する必要があります。Directory Server から起動したエンタープライズサーバもまた、別のユーザ ID を指定しない限り root として動作します。
エンタープライズサーバのさまざまな属性を構成できます。たとえば、使用可能なメモリ量、起動するサービス実行プロセスの数、トレースする情報などがあります。 ほとんどの属性は、適切な値に設定されています。これらの属性の詳細は、「サーバの追加」ページと「サーバの編集」ページのそれぞれのヘルプを参照してください。
以後では、一部のさらに複雑な属性について詳細に説明します。
共有メモリ領域は、エンタープライズサーバがその実行に必要なすべての情報を格納するメモリ領域です (『はじめに』の章にある『エンタープライズサーバのアーキテクチャ』の項を参照)。 共有メモリ領域のサイズは、ページ数で表します (1 ページは 4 KB)。共有メモリのサイズは、サーバ内のオブジェクトのすべての定義と現在のクライアント要求をすべて格納するのに十分な大きさである必要があります。 サーバの実行中に共有メモリが不足した場合は、サーバのパフォーマンスが著しく低下し、クライアント要求の処理が妨げられます。
エンタープライズサーバに割り当てる共有メモリ領域のページ数の概算は、ここで説明する計算式を使用してください。
実際の共有メモリの要件は作業負荷によって異なりますが、安全を考えて大きめに割り当ててください。 Enterprise Server は、処理量が最大でない限り物理ページ数の使用を最小にすることで共有メモリのリソースの使用を最適化します。
次の表の中央カラムに示した計算式を使用して、それぞれの計算結果を右側のカラムに書き込みます。 右側のカラムに書き込んだ値の合計が共有メモリの最小必要バイト数です。 合計バイト数を 4096 で除算し、その結果の端数を切り上げて、必要な共有メモリのページ数を求めます。
| 項目 | 計算式 | 計算結果 |
|---|---|---|
| オーバヘッド | 固定サイズ | 8192 |
| 共有メモリ領域管理 | 共有メモリ領域サイズ / 4096 | |
| トレース | エントリ数 × 24 | |
| ローカルトレース | サービス実行プロセスの数 × (エントリ数 × 24) | |
| サービス | サービスの数 × (128 + service-name-length) | |
| サービス実行プロセス | サービス実行プロセスの数 × 128 | |
| 要求ハンドラ | 要求ハンドラの数 × (128 + handler-name-length) | |
| パッケージ | パッケージの数 × (128 + IDT-name-length + application-path-length + module-name-length) | |
| 常駐 IDT | 常駐 IDT の数 × IDT-length | |
| クライアント要求 | 同時に処理されるクライアント要求の数 × (256 + クライアント要求の平均サイズ) | |
| 合計 |
変数の内容は、次のとおりです。
service-name-length は、サービスの名前の長さです。
handler-name-length は、要求ハンドラの名前の長さです。
IDT-name-length は、IDT の名前の長さです。
application-path-length は、パッケージ内の COBOL アプリケーションへのパスの長さです。
module-name-length は、アプリケーションを格納しているモジュールの名前の長さです。
IDT-length は、パッケージの IDT ファイルのサイズです。
共有メモリクッションは、共有メモリ領域の一部です。 共有メモリクッションの機能は、短期間に集中するサーバの要求を処理します。 エンタープライズサーバが開始されたときは、共有メモリクッションは使用不能です。着信クライアント要求では使用されません。 応答をクライアントに返す必要があるときに、その応答を処理する十分な空き領域が共有メモリにない場合にのみ使用されます。
共有メモリクッションのサイズは、ページ数で表します (1 ページは 4 KB)。共有メモリクッションのサイズは、共有メモリ領域サイズの 10 % に設定してください。
エンタープライズサーバには、1 つ以上のサービス実行プロセスがあります (『はじめに』の章にある『サービス実行プロセス』の項の『サービス実行プロセスの構成要素』の図を参照)。 サービス実行プロセスは着信クライアント要求を処理します。 応答がクライアントに返されると、サービス実行プロセスは別の要求を処理できます。 すべてのサービス実行プロセスが要求を処理中である場合は、どれかのサービス実行プロセスが要求の処理を完了するまで、着信要求の処理は待機します。 エンタープライズ内のサービス実行プロセスの数は、パフォーマンスに影響します。 影響の程度はサービス実行プロセスの数によって異なります。 特定のエンタープライズサーバに最適なサービス実行プロセスの数を見つけ出す必要があります。 詳細は、『パフォーマンスに関する考慮事項』の項を参照してください。
サービス実行プロセスの実行中にサービス実行プロセスの数を変更できます。ただし、その変更はサーバが停止されるまで有効です。 サーバを停止すると、サービス実行プロセスの数はサーバを追加したときの値またはサーバの詳細を編集したときの値に戻ります。
「サーバの追加」ページまたは「サーバの編集」ページの「構成情報」で環境変数を設定できます。 環境変数はサーバ内で実行されているすべてのサービスに適用されます。ただし、Interface Mapping Toolkit を使用してサービスの作成時に設定したサービスレベルの環境変数は、サーバレベルの設定を上書きします。
環境変数の形式は、次のとおりです。
[ES-Environment] environment-variable-name=environment-variable-setting
文字列内で要素を区切るには、次のようにセミコロンを使用します。
[ES-Environment] COBPATH=/home/adirectory;home/anotherdirectory
注：特に UNIX の場合には、エンタープライズサーバに COBDIR 環境変数を設定しないことをお奨めします。 これは、$COBDIR が製品の位置を示すのに使用されるためです。 $COBDIR を設定した場合、その結果は不確定です。 サービスプログラムの位置をエンタープライズサーバレベルで指定する場合は、COBPATH 環境変数を使用してください。 COBPATH 環境変数をエンタープライズサーバレベルで設定する場合は、「パッケージの追加」ページまたは「パッケージの編集」ページでも、「パッケージのパス」に $COBPATH を指定する必要があります。
環境変数を指定する際は、他の既に作成されている変数の解決済みの値をその環境変数値の一部として使用できます。 この場合、利用する環境変数の先頭に次のようにドル記号 ($) を付けます。
FILEROOT=/home/data FILEA=$FILEROOT/mydata.dat
この場合は、/home/data/mydata.dat となります。
環境変数にドル記号を、参照する別の環境変数のインジケータとしてではなく、実際の値の一部として指定したい場合は、次のようにバックスラッシュ (\) 文字をスケープ文字として使用します。
FILEA=\$\$fsserver1/mydata.dat
この場合は、$$fsserver1/mydata.dat となります。
エンタープライズサーバ内のどれかのサービスが Fileshare を使用してネットワーク上のファイルにアクセスする場合は、FHREDIR 構成ファイルの位置を FHREDIR 環境変数に設定する必要があります。次に例を示します。
[ES-Environment] FHREDIR=home/mydir/client.cfg
FHREDIR が静的な設定であるため、FHREDIR 構成ファイルの内容はエンタープライズサーバの初期化時に読み込まれ、動的に変更することはできません。 このため、FHREDIR 構成ファイルには、エンタープライズサーバにディプロイする、またはディプロイする予定のすべてのサービスを指定する必要があります。 あるサービスがエンタープライズサーバに動的にディプロイされ、Fileshare の構成に変更が必要な場合には、エンタープライズサーバをいったん停止して再起動するしかありません。
すべてのエンタープライズサーバが同じ構成ファイルを使用する場合は、各サーバごとに個別に設定するのではなく、Directory Server を起動する前にコマンド行で $FHREDIR を設定できます。
エンタープライズサーバ内にデータベースにアクセスするコンテナ管理サービスがある場合は、アプリケーションコンテナが対話する必要があるリソースマネージャの情報を指定する必要があります。 XA 互換のリソースマネージャのみ使用できます。 XA インターフェイスは、スイッチテーブルと呼ばれる構造体を記述します。スイッチテーブルは、リソースマネージャに実装された xa_ ルーチンの名前からなります。 この構造体は xa_switch_t と呼ばれます。 Server Express では、リソースマネージャに実装された XA スイッチデータ構造体のアドレスを取得するための、スイッチモジュールをいくつか用意しています。
Server Express では、Oracle および IBM DB2 用のスイッチモジュールのソースファイルがディレクトリ $COBDIR/src/enterpriseserver/xa に格納されています。 次のソースファイルがあります。
| ESORAXA.CBL | Oracle |
| ESDB2XA.CBL | IBM DB2 |
このディレクトリには、必要なスイッチモジュールをビルドするために使用できるスクリプト build も格納されています。スクリプトを実行するコマンドは、次のとおりです。
build database-name
database-name には、次のいずれかを指定します。
| ora | Oracle |
| db2 | IBM DB2 |
データベース環境が正しく設定されていることを確認してから、build スクリプトを実行する必要があります。 詳細については、データベースベンダーのマニュアルを参照してください。
Enterprise Server をスタンドアローンで実行している場合は、必要なスイッチモジュールを Server Express にビルドし、スタンドアローンの Enterprise Server で使用できるようにする必要があります。
Web インターフェイスの「サーバ詳細の編集」ページで 1 つのリソースマネージャの詳細を指定できます。
「サーバの追加」ページまたは「サーバの編集」ページの「構成情報」で複数のリソースマネージャの詳細を指定できます。 形式は、次のとおりです。
[ESXRM] rmtype=xa rmlabel=resource-manager-id rmname=resource-manager-name rmmodule=switch-module-name rmopenstring=open-string rmclosestring=close-string
パラメータの内容は、次のとおりです。
| resource-manager-id | 特定の XA 構成を識別するために内部的に使用するリソースマネージャ ID です。 リソースマネージャ ID は、エンタープライズサーバ内で一意である必要があります。 |
| resource-manager-name | リソースマネージャを認識する名前です。xa_switch_t 構造体の「name」フィールドで返される名前と一致する必要があります。 |
| switch-module-name | xa_switch_t 構造体をエンタープライズサーバに返すエントリポイントを含むスイッチモジュール共有オブジェクトの位置です。 |
| open-string | xa_open() 呼び出しでリソースマネージャに渡される文字列です。 通常、文字列には少なくともデータベース名、およびデータベースに接続するユーザ ID とパスワードが含まれます。 この文字列の内容は、データベース固有です。
DB2 の場合は、文字列の内容については、IBM 社の『DB2 管理の手引き』を参照してください。詳細は、『アプリケーション・プログラミングの手引き』を参照してください。 Oracle の場合は、『Oracle アプリケーション開発者ガイド 基礎編』を参照してください。 リソースマネージャが動的登録をサポートし、ax_reg 関数を提供するモジュールの名前を要求するデータベースベンダーの場合は、casaxlib を指定します。 |
| close-string | xa_close() 呼び出しでリソースマネージャに渡される文字列です。close-string を指定する必要があるかどうかは、データベースベンダーのマニュアルを参照してください。 |
次に例を示します。
[ESXRM] rmtype=xa rmlabel=XADB2 rmname=DB/2 rmmodule=/mydir/esdb2xa.so rmopenstring=db=sample,uid=myuser, pwd=mypasswd, axlib=casaxlib rmclosestring=
パフォーマンスを向上するためにエンタープライズサーバをどのように構成するかは、いつくかの要因によって決まります。 明らかな要因の 1 つは、予期されるサーバの作業負荷です。 クライアント要求が着信する頻度と、これらの要求に対して求められている応答速度を考慮する必要があります。
他の 2 つの要因は、サーバ内で実行するサービスの種類とサービスの要求の種類です。 サービスは、I/O バウンドまたは CPU バウンドに分類できます。クライアント要求は、短期実行または長期実行に分類できます。
多数の入出力要求を実行するサービスはその実行時に、要求の応答を待機する間は休止した状態になります。 ただし、入出力要求の処理では CPU の負荷を考慮すべき場合があります。 I/O バウンドサービスの場合には、サービス実行プロセスの数を増加すべきか検討する必要があります。
入出力要求を実行しない (またはほとんどない) サービスでは、一般に CPU の負荷が高くなります。 通常、I/O バウンドサービスの場合は、サービス実行プロセスの数が少ないほどよく動作します。実行されている作業間での CPU の切り替えによるオーバヘッドが小さくなるためです。
短期実行クライアント要求は、クライアントとサービスの間で 1 回のみ行われる要求です。クライアント要求が着信し、サービスが実行され、応答がクライアントに返されます。 Web サービスクライアントからの要求は常に短期実行です。
短期実行クライアント要求の場合は、サービス自体が I/O バウンドか、または CPU バウンドかのみを考慮する必要があります。
長期実行クライアント要求は、同じクライアントがサービスを繰り返し要求し、サービスのそれぞれの起動の間データを保持する必要がある場合の要求です。 Java 用語では、これらの要求はステートフル要求です。 クライアントが WebLogic または WebSphere などのアプリケーションサーバで実行されているステートフル Java bean の場合には、サービスは Java bean が実行されている間実行されます。 このような状況では、サービス自体が I/O バウンドではなく CPU バウンドの場合でもサービス実行プロセスの数を増加する必要があります。
エンタープライズサーバが要求がステートフルであることを検出すると、新しいサービス実行プロセスが自動的に開始されます。 サービス実行プロセスの数が動的に増加することでマシンのリソースが消費され、エンタープライズサーバのパフォーマンスが影響されます。 アプリケーションで実際にステートフルな相互運用が必要ない限り、長期実行クライアント要求の使用は最小にすることをお奨めします。
実行中のエンタープライズサーバにサービスを自動的にディプロイする Interface Mapping Toolkit の機能では、ディプロイサービスと呼ばれるシステムサービスを使用してサービスを配信します。 エンタープライズサーバ ESDEMO には、「Deployer」と呼ばれるデフォルトのディプロイサービスがあります。 このディプロイサービスを変更することも、異なる構成でディプロイサービスを新規に作成することもできます。 また、作成したエンタープライズサーバにディプロイサービスを追加することもできます。
Deployer サービスは、Web と呼ばれるリスナーを使用します。Web リスナーでは、http-switch コネクタを使用します。 Deployer サービスを変更する場合は、Web リスナーの構成の変更が必要になることもあります。 ディプロイサービスで使用する独自のリスナーを作成することもできます。
すべてのディプロイサービスでは属性を、次のように設定する必要があります。
| サービス Class | MF deployment |
| 会話タイプ | http-switch |
ディプロイサービスの構成情報は、次のようになります。
[MF client] scheme=http URL=virtual-directory-name-1/mfdeploy.exe/virtual-directory-name-2 accept=application/x-zip-compressed
virtual-directory-name-1 は、ディプロイプログラム mfdeploy.exe を格納するディレクトリです。virtual-directory-name-2 は、ディプロイしたサービスを含むディレクトリです。
scheme パラメータと accept パラメータの値は変更できません。
ESDEMO の Deployer サービスの設定は、次のとおりです。
[MF client] scheme=http URL=/cgi/mfdeploy.exe/uploads accept=application/x-zip-compressed
ディプロイサービスの構成は、サービスのリスナーの構成と一致する必要があります。URL パラメータには、mfdeploy.exe プログラムの位置として、リスナーが使用する仮想ディレクトリと同じ名前を指定する必要があります。 ディプロイ済みサービスを格納する仮想パスを、リスナーに対して構成された仮想ディレクトリ名に変更できます。
たとえば、次のようなリスナーの構成があります。
[virtual paths] <default>=/dev/null serverexpress=<ASEE>/bin project1=home/development/project1 project2=home/development/project2
「project1」という名前のディプロイサービスをこの構成で作成します。
[MF client] scheme=http URL=/serverexpress/mfdeploy.exe/project1 accept=application/x-zip-compressed
「project1」サービスを使用してディプロイしたサービスは /home/development/project1 に格納されます。 project2 に対して同じようなサービスを作成できます。
ディプロイディレクトリには、.mfdeploy ファイルが存在する必要があります。 $COBDIR/deploy/ から .mfdeploy ファイルをコピーして、必要に応じて変更してください。
ディプロイリスナーの構成情報には、[virtual paths] という名前のセクションがあり、URL の上位レベルディレクトリのリストと変更後のパスが後に続きます。 たとえば、ESDEMO の Deployer サービスが使用する Web リスナーの構成は、次のようになります。
[virtual paths] cgi=<ASEE>/bin uploads=<ASEE>/deploy <default>=/dev/null
仮想パス cgi は、ディプロイされる COBOL アーカイブファイルを受信する mfdeploy.exe プログラムの位置を指定します。仮想パス uploads は、アップロードされた COBOL アーカイブファイルを格納するディレクトリを mfdeploy.exe プログラムに示します。 特別なトークン <ASEE> は、COBDIR 環境変数で指定されたディレクトリに変換されます。これは、Enterprise Server の基本インストールディレクトリであるはずです。 たとえば、$COBDIR が /opt/cobol の場合、<ASEE>/deploy はディフォルトのディプロイディレクトリである /opt/cobol/deploy に変換されます。 Enterprise Server で使用される $COBDIR の値は、通常システムデーモンとして実行される Directory Server プロセスについて設定された値です。
URL の最初のディレクトリのみがリストと比較されるため、リスト内のエントリは 1 つのディレクトリ名にする必要があります。
<default> ディレクトリは、URL 内の最初のディレクトリがリスト内のどのエントリとも一致しない場合に使用されます。<default> ディレクトリを指定することは重要です。 指定しない場合には、サーバは現在のドライブのルートディレクトリを使用し、ネットワーク上のそのドライブのファイルをすべて公開します。
別の使用例を次に示します。
[virtual paths] <default>=/usr/web docs=/usr/web/documents images=/home/media/images
この構成では、URL http://host:port/docs/a.html はファイル /usr/web/documents/a.html を返し、URL http://host:port/images/gif/b.gif はファイル /home/media/images/gif/b.gif を返します。
Copyright © 2004 Micro Focus International Limited.All rights reserved.