第 2 章 : 構成

ここでは、インストール後の Enterprise Server の構成方法について説明します。この構成では、Directory Server と個別のエンタープライスサーバの両方の属性も設定します。また、パフォーマンスの考慮事項についても説明します。

はじめに

Enterprise Server を初めて起動する場合は、次の処理が必要です。

1. 環境を設定する
2. Directory Server のセキュリティを設定する
3. Directory Server の他の構成オプションを設定する
4. エンタープライズサーバの構成オプションを設定する

Enterprise Server をインストールすると、デフォルトのエンタープライズサーバ ESDEMO が 1 つ作成されます。このサーバはディプロイシステムサービスを提供します。Interface Mapping Toolkit を使用して COBOL サービスを自動的にディプロイすると、ディプロイサービスはサービスを受信し、サービスとその構成要素 (オペレーションとパッケージ) をエンタープライズサービスに追加します。ディプロイサービスおよび関連するリスナーの構成が必要になる場合があります。詳細は、『ディプロイサービスとディプロイリスナー』の節を参照してください。

環境の設定

Directory Server の構成作業を行うには、まず環境を設定して Directory Server を起動する必要があります。次の作業を実行する必要があります。

Process User ID

方法

システム全体の環境変数

Enterprise Server で発生するすべてのアクティビティに適用させるには、次の環境変数を設定する必要があります。

• COBDIR。Enterprise Server が存在するディレクトリを指定します。
• PATH。ランタイムシステムを含むすべての UNIX プログラムが実行形式ファイルを探すときに検索するディレクトリを指定します。
• LD_LIBRARY_PATH、LIBPATH または SHLIB_PATH (UNIX システムにより異なる)。UNIX システム、cob、およびランタイムシステムが、共有ライブラリおよび呼び出し可能共有オブジェクトを検索するための、ディレクトリを 1 つ以上指定します。

エンタープライズサーバ内からデータベースにアクセスする場合は、必要なライブラリを PATH 環境変数に追加し、使用している UNIX システムに応じて LIBPATH、SHLIB_PATH、または LD_LIBRARY_PATH 環境変数に追加する必要があります。データベースにアクセスするための環境変数の設定についての詳細は、データベースのベンダーが提供するマニュアルを参照してください。

Directory Server の最初の起動

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 は、デフォルトでポート 86 を使用する設定になっています。 このポートへの TCP および UDP アクセスを許可するよう、ファイアウォールを設定する必要があります。 同じように、デフォルトのエンタープライズサーバである ESDEMO には、ポート 9003 を使用する Web サービスリスナーがあります。 リモートクライアントがこのリスナーへ要求を送信できるようにするには、ファイアウォールがこのポートへのアクセスを許可しなければなりません。

リモートユーザがファイアウォールを介して Enterprise Server の機能にアクセスできるようにする場合には、固定のポート番号を使用して、アクセスを制御できるようにすることをお奨めします。

Directory Server のセキュリティの設定

Directory Server は、セキュリティを使用可能または使用不能にして実行できます。 セキュリティを使用不能にして Directory Server を実行すると、Directory Server と、それが管理するすべてのエンタープライズサーバに対して、誰でも変更を加えることができます。 常にセキュリティを使用可能にして Directory Serverity を実行することをお奨めします。

セキュリティは、ユーザ ID、ユーザ グループ、およびアクセス権を使用することで提供されます。Directory Server をインストールした直後はセキュリティが使用不能になっています。 Directory Server には、セキュリティを有効にしてから使用するための設定済みユーザアカウントがいくつかあります。

管理者としての最初の作業は、セキュリティを使用可能にし、ユーザのログオン情報を作成することです。

セキュリティを使用可能にするには、Enterprise Server Administration への Web インターフェイスを開始する必要があります。 次に、「構成オプション」ページで「ユーザアクセス制限」を選択します。

方法...

セキュリティを使用可能にすると、ユーザ ID とパスワードの入力がすぐに求められます。 次の構成済みのログオン情報を入力します。

ユーザ ID schemaadmin は Directory Server Administrators グループのメンバーなので、Directory Server で変更を行うために必要なアクセス権があります。このユーザ ID の不正利用を防ぐための処置が必要です。 schemaadmin のパスワードはすぐに変更してください。 ユーザ ID schemaadmin を保護した後に、Schema Administrator アクセス権レベルをもつ新しいユーザ ID の作成が必要になる場合があります。 新しいユーザ ID を作成したり、事前設定済みのユーザ ID を削除したりすることもできます。

方法...

セキュリティとアクセス権の詳細は、『ユーザ、グループおよびアクセス権』の章を参照してください。

Directory Server

Directory Server のさまざまな属性を構成できます。たとえば、エンタープライズサーバが使用可能かどうかの監視、ジャーナルに記録するイベントの種類、Directory Server のクライアントがどのくらいの時間非アクティブの場合に自動的にログオフするかなどがあります。 これらのオプションの詳細は、「構成オプション」ページのヘルプを参照してください。

方法

エンタープライズサーバ

エンタープライズサーバのさまざまな属性を構成できます。たとえば、使用可能なメモリ量、起動するサービス実行プロセスの数、トレースする情報などがあります。 ほとんどの属性は、適切な値に設定されています。これらの属性の詳細は、「サーバの追加」ページと「サーバの編集」ページのそれぞれのヘルプを参照してください。

方法...

[ASection]
name1=value1
name2=value2

共有メモリ領域

共有メモリ領域は、エンタープライズサーバがその実行に必要なすべての情報を格納するメモリ領域です (『はじめに』の章にある『エンタープライズサーバのアーキテクチャ』の節を参照)。共有メモリ領域のサイズは、ページ数で表します (1 ページは 4 KB)。共有メモリのサイズは、サーバ内のオブジェクトのすべての定義と現在のクライアント要求をすべて格納するために十分な大きさである必要があります。サーバの実行中に共有メモリが不足した場合は、サーバのパフォーマンスが著しく低下し、クライアント要求の処理が妨げられます。

エンタープライズサーバに割り当てる共有メモリ領域のページ数の概算は、ここで説明する計算式を使用してください。

実際の共有メモリの要件は作業負荷によって異なりますが、安全を考えて大きめに割り当ててください。Enterprise Server は、処理量が最大でない限り物理ページ数の使用を最小にすることで共有メモリのリソースの使用を最適化します。

次の表の中央カラムに示した計算式を使用して、それぞれの計算結果を右側のカラムに書き込みます。右側のカラムに書き込んだ値の合計が共有メモリの最小必要バイト数です。合計バイト数を 4096 で除算し、その結果の端数を切り上げて、必要な共有メモリのページ数を求めます。

変数の内容は、次のとおりです。

共有メモリクッション

共有メモリクッションは、共有メモリ領域の一部です。共有メモリクッションの機能は、短期間に集中するサーバの要求を処理します。エンタープライズサーバが開始されたときは、共有メモリクッションは使用不能です。着信クライアント要求では使用されません。応答をクライアントに返す必要があるときに、その応答を処理する十分な空き領域が共有メモリにない場合にのみ使用されます。

共有メモリクッションのサイズは、ページ数で表します (1 ページは 4 KB)。共有メモリクッションのサイズは、共有メモリ領域サイズの 10 % に設定してください。

サービス実行プロセスの数

エンタープライズサーバには、1 つ以上のサービス実行プロセスがあります (『はじめに』の章の『サービス実行プロセス』の節にある『サービス実行プロセスの構成要素』の図を参照)。サービス実行プロセスは着信クライアント要求を処理します。応答がクライアントに返されると、サービス実行プロセスは別の要求を処理できます。すべてのサービス実行プロセスが要求を処理中である場合は、どれかのサービス実行プロセスが要求の処理を完了するまで、着信要求の処理は待機します。エンタープライズ内のサービス実行プロセスの数は、パフォーマンスに影響します。影響の程度はサービス実行プロセスの数によって異なります。特定のエンタープライズサーバに最適なサービス実行プロセスの数を見つけ出す必要があります。詳細は、『パフォーマンスに関する考慮事項』の節を参照してください。

サービス実行プロセスの実行中にサービス実行プロセスの数を変更できます。ただし、その変更はサーバが停止されるまで有効です。サーバを停止すると、サービス実行プロセスの数はサーバを追加したときの値またはサーバの詳細を編集したときの値に戻ります。

方法

通信プロセスの数

通信プロセスは、クライアントとエンタープライズサーバの間の通信を処理し、多数のサービスリスナーで構成されます。エンタープライズサーバが作成された場合は、1 つの通信プロセスをもちます。何らかの理由で通信が失敗した場合は、通信プロセスが再開されるまで、エンタープライズサーバはどのような作業も処理できません。通信に失敗してもエンタープライズサーバの能力を保つために、1 つのエンタープライズサーバで複数の追加通信プロセスを作成できます。追加通信プロセスは、既存の通信プロセスをコピーして作成します。新しい通信プロセスは、元の通信プロセスのクローンですが、固定ポート番号はコピーされません。新しく作成するエンタープライズサーバの最初の通信プロセスは、「通信プロセス 1」で Web サービスリスナーとディプロイリスナーを含んでいます。新しいエンタープライズサーバの作成中に、この通信プロセス定義をコピーする前に変更したい場合は、サーバ計画の作業負荷に依存します。

方法

耐障害性をもつには、少なくとも 2 つの通信プロセスが必要です。オペレーティングシステムのスレッド制限を解決するために 2 つ以上の通信プロセスが必要になる場合があります。最大数は 32 です。

詳細は、『ディプロイサービスとディプロイリスナー』の節を参照してください。通信プロセスとリスナーの管理の詳細は、『通信プロセスとサービスリスナー』の章を参照してください。

環境変数

「サーバの追加」ページまたは「サーバの編集」ページの「構成情報」で環境変数を設定できます。環境変数はサーバ内で実行されているすべてのサービスに適用されます。ただし、Interface Mapping Toolkit を使用してサービスの作成時に設定したサービスレベルの環境変数は、サーバレベルの設定を上書きします。

環境変数の形式は、次のとおりです。

[ES-Environment]
environment-variable-name=environment-variable-setting
        

文字列内で要素を区切るには、次のようにセミコロンを使用します。

[ES-Environment]
COBPATH=/home/adirectory;home/anotherdirectory

環境変数を指定する際は、他のすでに作成されている変数の解決済みの値をその環境変数値の一部として使用できます。この場合、利用する環境変数の先頭に次のようにドル記号 ($) を付けます。

FILEROOT=/home/data
FILEA=$FILEROOT/mydata.dat

この場合は、/home/data/mydata.dat となります。

環境変数にドル記号を、参照する別の環境変数のインジケータとしてではなく、実際の値の一部として指定したい場合は、次のように円記号 (¥) 文字をスケープ文字として使用します。

FILEA=¥$¥$fsserver1/mydata.dat

この場合は、$$fsserver1/mydata.dat となります。

方法

Fileshare

エンタープライズサーバ内のどれかのサービスが Fileshare を使用してネットワーク上のファイルにアクセスする場合は、FHREDIR 構成ファイルの位置を FHREDIR 環境変数に設定する必要があります。次に例を示します。

[ES-Environment]
FHREDIR=home/mydir/client.cfg

FHREDIR が静的な設定であるため、FHREDIR 構成ファイルの内容はエンタープライズサーバの初期化時に読み込まれ、動的に変更することはできません。このため、FHREDIR 構成ファイルには、エンタープライズサーバにディプロイする、またはディプロイする予定のすべてのサービスを指定する必要があります。あるサービスがエンタープライズサーバに動的にディプロイされ、Fileshare の構成に変更が必要な場合には、エンタープライズサーバをいったん停止して再起動するしかありません。

すべてのエンタープライズサーバが同じ構成ファイルを使用する場合は、各サーバごとに個別に設定するのではなく、Directory Server を起動する前にコマンド行で $FHREDIR を設定できます。

エンタープライズサーバの起動前に、アクセスする必要のあるエンタープライズサーバ内のサービスですべての Fileshare サーバを起動する必要があります。また、Fileshare サーバを停止する前にエンタープライズサーバを停止する必要があります。

Fileshare の詳細は、『Fileshare ユーザガイド』を参照してください。

リソースマネージャ

エンタープライズサーバ内にデータベースにアクセスするコンテナ管理サービスがある場合は、アプリケーションコンテナが対話する必要があるリソースマネージャの情報を指定する必要があります。XA 互換のリソースマネージャのみ使用できます。XA インターフェイスは、スイッチテーブルと呼ばれる構造体を記述します。スイッチテーブルは、リソースマネージャに実装された xa_ ルーチンの名前からなります。この構造体は xa_switch_t と呼ばれます。XA 互換のリソースマネージャにアクセスするには、スイッチモジュールが必要です。スイッチモジュールは、リソースマネージャに実装された XA スイッチデータ構造体のアドレスを取得します。

Server Express では、Oracle および IBM DB2 用のスイッチモジュールのソースファイルがディレクトリ $COBDIR/src/enterpriseserver/xa に格納されています。次のソースファイルがあります。

このディレクトリには、必要なスイッチモジュールをビルドするために使用できるスクリプト build も格納されています。スクリプトを実行するコマンドは、次のとおりです。

build database-name

database-name には、次のどれかを指定します。

データベース環境が正しく設定されていることを確認してから、build スクリプトを実行する必要があります。詳細は、データベースベンダーのマニュアルを参照してください。

Enterprise Server をスタンドアローンで実行している場合は、必要なスイッチモジュールを Server Express にビルドし、スタンドアローンの Enterprise Server で使用できるようにする必要があります。

Web インターフェイスの「サーバの編集 > 属性 > XA リソース」ページで XA リソースマネージャの詳細を指定できます。XA リソースマネージャ定義を編集および削除できます。エンタープライズサーバを開始したときにアクティブにするリソースマネージャを個別に制御できます。

方法

パフォーマンスに関する考慮事項

パフォーマンスを向上するためにエンタープライズサーバをどのように構成するかは、いつくかの要因によって決まります。明らかな要因の 1 つは、予期されるサーバの作業負荷です。クライアント要求が着信する頻度と、これらの要求に対して求められている応答速度を考慮する必要があります。

他の 2 つの要因は、サーバ内で実行するサービスの種類とサービスの要求の種類です。サービスは、I/O バウンドまたは CPU バウンドに分類できます。クライアント要求は、短期実行または長期実行に分類できます。

I/O バウンドサービス

多数の入出力要求を実行するサービスはその実行時に、要求の応答を待機する間は休止した状態になります。ただし、入出力要求の処理では CPU の負荷を考慮すべき場合があります。I/O バウンドサービスの場合には、サービス実行プロセスの数を増加すべきか検討する必要があります。

CPU バウンドサービス

入出力要求を実行しない (またはほとんどない) サービスでは、一般に CPU の負荷が高くなります。通常、CPU バウンドサービスの場合には、サービス実行プロセスの数が少ないほどよく動作します。これは、実行されている作業間での 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 リスナーの構成の変更が必要になることもあります。ディプロイサービスで使用する独自のリスナーを作成することもできます。

方法

ディプロイサービス

ディプロイサービスの構成情報は、次のようになります。

[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=<ES>/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=<ES>/bin
 uploads=<ES>/deploy
 <default>=/dev/null

仮想パス cgi は、ディプロイされる COBOL アーカイブファイルを受信する mfdeploy.exe プログラムの位置を指定します。仮想パス uploads は、アップロードされた COBOL アーカイブファイルを格納するディレクトリを mfdeploy.exe プログラムに示します。特別なトークン <ES> は、COBDIR 環境変数で指定されたディレクトリに変換されます。これは、Enterprise Server の基本インストールディレクトリであるはずです。たとえば、$COBDIR が /opt/cobol の場合には、<ES>/deploy はディフォルトのディプロイディレクトリである /opt/cobol/deploy に変換されます。Enterprise Server で使用される $COBDIR の値は、通常システムデーモンとして実行される Directory Server プロセスについて設定された値です。

ディプロイを実行するクライアントで指定されている URL の最初のディレクトリのみがリストと比較されるため、リスト内のエントリは 1 つのディレクトリ名にする必要があります。

別の使用例を次に示します。

[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 © 2006 Micro Focus (IP) Ltd. All rights reserved.