 |
|
管理ガイド 05/21/03 10:02:24 |
この章では、負荷分散およびフェイルオーバを実装するためにNovell exteNd Application Serverでサーバクラスタリング機能を使用する方法について説明します。また、クラスタ環境をセットアップして維持する方法についても説明します。この章は、次の節で構成されています。
処理の高負荷に対応するために、アプリケーションサーバでは、サーバクラスタリング機能を使用して負荷分散を実装します。
「サービスクラスタ」は、処理負荷を分担する異なるホストで実行されているサーバのセットです。アプリケーションサーバ環境では、クラスタは、同じSilverMasterデータベースに接続されている単一のシステムとして連携して動作する独立したシステムのグループです。この設定では、クライアントは、パフォーマンスと信頼性が高い単一のアプリケーションサーバのようなクラスタと通信します。
注記: サーバのクラスタでは、長期にわたり、1つの大きなマシンよりもさらに効率的に要求を処理できます。これは、複数のマシンの帯域幅とリソースを合わせた合計は、1つの大きなマシンの帯域幅とリソースの合計よりも大きい(および安価)であるためです。
|
利点 |
説明 |
|---|---|
|
スケーラビリティおよびパフォーマンス |
特定の期間にわたって処理されるリクエストの数は、増やすことが可能です。全体的な負荷がクラスタ内のシステムの能力を超えた場合は、別のシステムをクラスタへ容易に追加できます。 |
|
キャッシュ管理 |
アプリケーションを変更した場合、キャッシュ管理によって、クラスタ内の各サーバにその変更が伝達されるようになります。 |
|
負荷管理 |
クライアントリクエストは、全体的なパフォーマンスを最適にするために、サーバに分散されます。 サードパーティ製のロードマネージャを使用することもできます。 |
|
フェイルオーバ |
フェイルオーバ機能は、サーバクラスタの各コンポーネントに提供されています。特定なシステムフェイルオーバ機能については、 コンポーネントフェイルオーバの管理の説明を参照してください。 |
アプリケーションサーバクラスタには、次のコンポーネントが含まれています
。
クラスタ要件 クラスタ設定では、次の一般的な要件を満たしている必要があります。
クラスタオプション クラスタ設定内には、次のオプションがあります。
各アプリケーションサーバには、一般的にアクセスするデータ(セキュリティ情報など)をメモリに保存するための、インテリジェントなキャッシュメカニズムがあります。各リクエストに対してデータベースからこの情報を読み込むことは非常に効率が悪いため、アプリケーションサーバでは、この情報をキャッシュメモリで保持します。情報がサーバで更新されると(新しいセキュリティ許可が適用されたり、J2EEアーカイブが配備されたりした場合など)、アプリケーションサーバのキャッシュも更新されます。
クラスタ内の複数のサーバ間でこのキャッシュを保持することは、アプリケーションとデータの整合性に対して重要です。クラスタ環境において、複数のサーバでは、アプリケーションサーバのシステムテーブル内にある同じデータを同時に変更できるため、この状況により、メモリにキャッシュされたデータが破損または矛盾した状態のままになることがあります。Cache Managerでは、キャッシュオブジェクトがサーバによって無効にされた場合にクラスタ内の他のサーバに通知することで、このような競合を防ぎます。すべてのサーバでは、無効なキャッシュエントリを破棄し、オブジェクトが次回必要になった場合にリソースの更新バージョンを取得します。
Cache Managerは、個別のマシン、またはサーバクラスタ内の任意のマシンで実行できます。クラスタ内のサーバを起動する前に、Cache Managerは実行されている必要があります。起動時に、アプリケーションサーバでは、SilverMasterカタログからセットアップに関するクラスタリング情報を読み込み、Cache Managerとの連絡を開始します。Cache Managerでは、サーバの存在を登録し、クラスタのメンバーとして識別します。
サーバによって既存のオブジェクトが変更されると、特定のオブジェクトを他のサーバで無効にしなければならないことをCache Managerに通知します。アプリケーションサーバ環境のオブジェクトはすべてURLで示すことができるため、サーバでは、すべてのサーバに対して指定されているURLを無効にするためにCache Managerを呼び出します。Cache Managerでは、登録されている各サーバ(無効化を開始するサーバ以外)を呼び出して、URLにより識別されるオブジェクトを無効にするように通知します。
Load Managerは、クラスタと同じネットワーク上にある任意のマシンでサービスまたは標準のプロセスとして実行できるプログラムです。Load Managerの役割は、クラスタ内にあるアクティブな各サーバとその相対処理「負荷」(または、次の 分散マッピングで説明されているウェイト)を追跡することです。この情報に基づいて、Load Managerでは分散マップを生成します。この分散マップは、設定でDispatcherに送信されます。
クラスタ内のサーバを起動する前に、Load Managerは実行されている必要があります。起動時に、サーバでは、SilverMasterからセットアップに関するクラスタリング情報を読み込み、Load Managerとの連絡を開始して、サーバの存在を登録します。Load Managerでは、サーバが実行されていることをまず登録し、サーバへの連絡方法を次に判断した後、分散マップにサーバを組み込みます。Load Managerでは、起動時に、プロパティファイルからセットアップに関するDispatcher情報を読み込み、分散マップを今後送信できるように、Dispatcherとの連絡を開始します。
Load Managerによって動的に生成される分散マップでは、クラスタ内の各サーバに対する処理負荷が決定されます。各サーバの分散ウェイトは、1から10までの範囲の整数で表されます。
デフォルトでは、負荷を分散するために「ラウンドロビンシステム」が使用されます。つまり、クラスタ内のすべてのサーバでは、長期にわたり同じ数のヒットを取得し、ウェイトも同じになります。
この分散は変更できません。たとえば、サーバ1を8、サーバ2を4、サーバ3を2にそれぞれ設定した場合、特定の期間にわたって、サーバ1ではサーバ2の2倍のヒットを取得し、サーバ2ではサーバ3の2倍のヒットを取得します。ウェイト設定のその他の例は、次の表のとおりです。
|
クラスタ内のサーバ |
ウェイト |
結果 |
|---|---|---|
|
1、2、3 |
null |
ラウンドロビン |
|
1、2、3 |
1、1、1 |
ラウンドロビン |
|
1、2、3 |
2、4、6 |
サーバ1は、ヒット数が最も少なく、サーバ2は、結果としてサーバ1の2倍のヒット数になり、サーバ3は、結果としてサーバ1の3倍のヒット数になる |
|
1、2、3 |
1、1、10 |
サーバ3は、結果としてサーバ1とサーバ2の10倍のヒット数になる |
分散の変更の詳細については、
サーバの相対負荷ウェイトの指定を参照してください。
Dispatcherは、サーバクラスタへのWebクライアントのエントリポイントとして機能します。クライアントでは、DispatcherのURLを通してクラスタに最初はアクセスします。
Dispatcherは、ウェイトの軽いHTTP/HTTPSサポートのプログラムで、Load Managerによって提供される分散マップに従ってサーバにクライアントリクエストを送信するために、他のクラスタコンポーネントと通信します。Dispatcherは、クラスタサーバと同じネットワーク上にある任意のマシンで、サービスまたは標準のプロセスとして実行できます。DispatcherとLoad Managerは別個のマシンやプラットフォームで実行でき、SilverMasterデータベースにアクセスする必要はありません。
クライアントから初めて呼び出されると、Dispatcherでは、Load Managerから受信した分散マップに基づいて、リクエストに最適なサーバを検出します。次に、HTTPリダイレクトという標準のプロセスを使用して、リクエストをクライアントにリダイレクトし直します。その後、クライアントでは、このリクエストを指定のサーバに直接送信します。
Dispatcherから特定のサーバにセッションが送信されると、すべてのクライアント通信は、Dispatcherを通さずにサーバに直接送信され、リダイレクションはマスクされます(つまり、ブラウザでは、DispatcherのURLではなく、サーバのURLがユーザに表示されます)。
Dispatcherでは、HTTPS (および、HTTP 1.0とHTTP 1.1の両方も)サポートしています。これは、クラスタをセットアップした後でサーバ証明書をインストールできることを意味します( サーバクラスタの管理を参照)。
アプリケーションサーバのソフトウェアであるDispatcherは、負荷分散およびフェイルオーバの多くのニーズに対して優れたソリューションですが、Dispatcherによって提供されない機能も必要になることがあります。
次の理由に対しては、サードパーティ製の送信ソリューションの使用が推奨されます。
ここで説明したような状況では、Load ManagerとDispatcherに対してサードパーティ製の送信ソリューションを代わりに使用することが推奨されます。アプリケーションサーバのCache Managerは、キャッシュを一貫した状態に保つために依然として使用し、SMCも、サーバを管理するために使用します。
標準のHTTPサーバ負荷分散ソリューションは、アプリケーションサーバで機能するはずです。
アプリケーションサーバでは、一時的なエラーや持続的なエラーが発生した場合にシステムフェイルオーバおよび回復を実行します。クラスタ内のコンポーネントのいずれかに障害が発生すると、SilverMonitorというバックグラウンドプログラムによってエラーが検出されます。
SilverMonitorでは、システムで実行されているデーモン、プロセス、およびサービスの状態を観察します。サーバクラスタの各コンポーネントは、SilverMonitorによって監視されます。コンポーネントのいずれかに障害が発生すると、SilverMonitorでは、エラーを検出して、そのコンポーネントを再起動しようとします。
SilverMonitorを使用すると、通常は、障害が発生したコンポーネントをすばやく回復できるようになります。エラーが持続する場合は(たとえば、ハードウェアエラーなどの理由のために)、システムリソースを節約するために、SilverMonitorでは、あらかじめ定義されている回数だけ試行した後、試行を中止します。
注記: SilverMonitorは、デフォルトにより、各クラスタで実行されます。また、特定のプログラムパラメータを定義できるサーバ起動オプションとしても提供されます。詳細については、 SilverMonitorの使用を参照してください。
クラスタ内のサーバがダウンし、正しく再起動しない場合は、次の結果が発生します。
サーバで障害が発生すると、接続されていたクライアントでは接続が切断されます。そのため、クライアントでは、再起動、またはブラウザからDispatcherへの別のリクエストの送信が必要となります。
サーバの再起動にかなりの時間がかかる場合は、着信クライアントリクエストをできるだけ効率的に処理できるように、クラスタコンポーネントでクラスタの強制再設定が行われます。持続的なエラーが発生している間、アクティブなコンポーネントは次のように応答します。
アプリケーションサーバのクラスタリングコンポーネント(Cache Manager、Load Manager、およびDispatcher)は、アプリケーションサーバの特定のバージョンで使用可能です。
最初のサーバをインストールし、SilverMasterを作成します。インストールが完了している場合は、SilverMasterセットアップがクラスタに対して適切であることを確認します。
アプリケーションサーバのインストールおよびSilverMasterデータベースの設定の詳細については、『インストールガイド』を参照してください。
インストールプログラムを使用して、クラスタリングコンポーネントを1つまたは複数のマシンにインストールします。プラットフォーム(UNIX、NetWare、およびWindows)は組み合わせて使用できます。
詳細については、『インストールガイド』を参照してください。
詳細については、次の
クラスタリングコンポーネントの起動を参照してください。
デーモンまたはサービスとしてコンポーネントをインストールした場合は、このモードで停止して再起動できます。
インストールプログラムを使用して、クラスタの一部である他のサーバをそれぞれインストールします。
詳細については、
クラスタサーバのインストールを参照してください。
詳細については、
クラスタの作成を参照してください。
クラスタを作成したら、サーバとコンポーネントをすべて再起動し、クラスタを有効にします。
詳細については、
クラスタサーバの再起動を参照してください。
負荷分散ソフトウェアがネットワーク上で現在サービスとして実行されていない場合、これらのプログラムを常駐マシンで手動により実行する必要があります。アプリケーションサーバのLoad Managerを使用している場合は、次の手順に示す順序でコマンドを実行します。
WindowsおよびUNIXでは、次の手順で指定されているプログラムは、サーバの\binディレクトリにあります。NetWareでは、システムコンソールからコマンドを入力します。
|
オペレーティングシステム |
コマンド |
|---|---|
|
NetWare |
SilverCacheMgr |
|
UNIX |
/bin/SilverCacheMgr |
|
Windows |
\bin\SilverCacheMgr.exe |
|
オペレーティングシステム |
コマンド |
|---|---|
|
NetWare |
SilverDispatcher |
|
UNIX |
/bin/SilverDispatcher |
|
Windows |
\bin\SilverDispatcher.exe |
|
オペレーティングシステム |
コマンド |
|---|---|
|
NetWare |
SilverLoadMgr |
|
UNIX |
/bin/SilverLoadmgr |
|
Windows |
\bin\SilverLoadMgr.exe |
これらの各実行可能ファイルを使用して、起動するJVMを指定することができます。詳細については、 使用するJVMの指定を参照してください。
Dispatcherでの起動パラメータの使用 Dispatcherは、次に説明するパラメータを使用して起動できます
|
パラメータ |
説明 |
|---|---|
|
-p propfile |
代替Dispatcher.ddlファイルの名前と場所。 Dispatcher.DDLファイルは、クラスタ設定時にSMCによって作成されます。Dispatcherに対するRMI、HTTP、およびHTTPSのデフォルトのポートが指定されるこのファイルは、サーバの\Resourcesディレクトリにあります。 代替Dispatcher.ddlファイルの使用、またはSMC外でのこのファイルの編集は、推奨されていません。 |
|
-c upload-certificate |
Dispatcherをupload-certificateモードで実行します。
|
|
-h host |
ここで指定したホスト名は、次でIPアドレスに変換されます。 InetAddress.getByName(host_name); このパラメータを指定した場合、Dispatcherでは、このIPアドレスのみでリッスンするサーバソケットを開きます。指定しなかった場合、ソケットは、ローカルマシンのすべてのIPアドレスでリッスンします。 |
|
+cp:p path |
指定したpathをクラスパスに付けます。このデバッグオプションは、Novell exteNdテクニカルサポートに連絡せずに使用しないでください。代わりに、AGCLASSPATHを使用して、追加のJavaクラスをアプリケーションに対して使用可能にします。
|
|
+cp:a path |
指定したpathをクラスパスに付けます。このオプションは、指定したパスをクラスパスに付けることによって、追加のJavaクラスをアプリケーションに対して使用可能にします。 注記: Javaクラスを拡張するには、AGCLASSPATH環境変数を使用してください。
|
。
クラスタのSilverMasterデータベースを含むサーバをインストールしたら、インストールプログラムを使用して他のサーバをインストールします。他のサーバをインストールする場合は、これらのサーバが、インストールした最初のサーバ(SilverMasterデータベースが含まれています)を指すようにする必要があります。これは、1つのクラスタ内の全サーバで同じSilverMasterデータベースが使用されなければならないためです。
この節では、WindowsおよびUNIXに対するインストール手順を説明します。詳細については、『インストールガイド』を参照してください。
クラスタをセットアップする場合の1つの手順は、クラスタに含めるホストマシンそれぞれにアプリケーションサーバをインストールすることです。これらをインストールする際には、次のガイドラインに従って、［Database Information］画面で情報を適切に入力する必要があります。
クラスタ内の最初のアプリケーションサーバのインストール クラスタ内では、最初のアプリケーションサーバのみにSilverMasterデータベースが含まれます。このサーバをインストールする際は、［Database Information］画面で通常通りに情報を入力します。例は次のとおりです(ホストAマシンにインストールする場合)。
クラスタ内の他のアプリケーションサーバのインストール クラスタ内の他のアプリケーションサーバでは、最初のサーバのSilverMasterデータベースを使用します。これらのサーバをインストールする際は、［Database Information］画面でこのデータベースを指すように情報を入力し、Execute SilverMasterInit設定のチェックは解除します(このデータベースのSilverMasterシステムテーブルが再初期化されないようにするために)。例は次のとおりです(ホストBマシンにインストールする場合)。
各サーバをクラスタに追加したら、SMCを使用してクラスタを作成できます(次の クラスタの作成を参照)。
クラスタのSilverMasterに関するデータベースタイプと、ユーザおよびパスワードの情報を入力します。
注記: Windowsサーバが含まれているクラスタにUNIXサーバを含めることができるかどうかは、データベースドライバの有用性によって影響される場合があります。
クラスタ内の各マシンは、他のマシンのミラーコピーでなければなりません。これは、次のことを意味しています。
SilverMasterInitの再実行を行わないようにするには、アプリケーションサーバの設定を尋ねるメッセージが表示されたときに「いいえ」と回答します。
注記: SMCを使用してクラスタにこのサーバをすでに追加した場合は、ここで指定するポート値が、クラスタにサーバを追加したときに入力した値と一致していなければなりません。
エラーが表示された場合は、既存のSilverMasterデータベースに関する情報を誤って入力した可能性があります。このような状況では、情報を再度指定する必要があります。
各サーバをクラスタに追加したら、SMCを使用してクラスタを作成できます(次の クラスタの作成を参照)。
［Full］、［Custom］、または［Server only install］を選択します(［Custom］を選択した場合は、アプリケーションサーバと共通コンポーネントが選択されていることを確認します)。
アプリケーションサーバの設定を尋ねるメッセージが表示されたら、［Configure exteNd Application Server (execute SilverMasterInit)］をオフにします。代わりに、インストールした最初のサーバによって使用されるSilverMasterを使用します。
SilverMasterのデータベースタイプを選択するとき、このデータベースタイプは、インストールした最初のサーバ(SilverMasterが含まれています)によって使用されるデータベースタイプと同じにする必要があります。
［Sybase Adaptive Server Anywhere］を選択した場合は、既存のデータベースを使用するか、または新しいデータベースを作成するかを尋ねられます。［Use an existing database for SilverMaster］をオンにし、［Next］をクリックします。
SilverMaster名と他のデータベース情報を入力するように指示されたら、クラスタに対してインストールした最初のサーバによって使用されるSilverMasterを指定する必要があります。
クラスタ内の各マシンは、他のマシンのコピーでなければなりません。これは、次のことを意味しています。
インストールの最後でエラーが表示された場合は、既存のSilverMasterデータベースに関する情報を誤って入力した可能性があります。このような状況では、情報を再度指定する必要があります。
各サーバをクラスタに追加したら、SMCを使用してクラスタを作成できます(次の説明を参照)。
複数のサーバが単一のSilverMasterを指すように設定したら、クラスタを作成して設定することができます。アプリケーションサーバは、1つのクラスタにのみ含めることが可能です。
クラスタを作成するには、HTTPポートを使用する必要があります。管理ポートを設定した場合は、この管理ポートを使用しなければなりません。
詳細については、
別個のポートおよびファイアウォールの使用を参照してください。
Cache Manager、Dispatcher (使用する場合)、およびLoad Manager (使用する場合)が実行されていることを確認します。
詳細については、
クラスタリングコンポーネントの起動を参照してください。
New Clusterウィザードが表示されます。
次のパネルが表示されます。
修飾名と、それに続けてポート番号も適切に入力して、［OK］をクリックします (サーバ名と、それを修飾する方法は、サーバがリッスンするものに一致している必要があります。名前は、サーバコンソールでエコーされるように指定します)。例は次のとおりです。
agserver.myco.com:50001
追加する最初のサーバは、SilverMasterが含まれているものになるようにします。その後追加したサーバは、すべて同じSilverMasterを使用するように設定する必要があります。
ポートが80に設定されている場合、ポート番号を指定する必要はありません。ただし、管理ポートを定義した場合は、そのポート番号を指定しなければなりません。アプリケーションサーバがプライマリWebサーバではない場合は、5000よりも大きい数にポートを変更する必要があります。ポートの変更方法については、 一般的なサーバのプロパティの指定を参照してください。
［Add］を再びクリックし、クラスタに追加する全サーバの名前を入力します。各サーバは、クラスタに追加するたびに［New Cluster］フォームにリストされます。
［Next］をクリックして、Cache Managerをセットアップします。
次のパネルが表示されます。
Cache Managerのホスト名を入力します。Cache ManagerのデフォルトのRMIポート番号は、54891です。クラスタを最初に作成するときには、デフォルトのポートを指定しなければなりませんが、このポートは、必要に応じて後に変更することが可能です。
デフォルトのポート変更の詳細については、
クラスタリングコンポーネントのプロパティの変更を参照してください。
アプリケーションサーバのLoad Managerを使用する予定がある場合は、［Use Novell exteNd Load Manager components］チェックボックスをオンにして、次の手順に進みます。
現時点ではLoad Managerを使用する予定がない場合は、［Finish］をクリックして、 クラスタサーバの再起動に移動します。
Load Managerのホスト名を入力します。デフォルトのRMIポートは、54891です。クラスタを最初に作成するときには、デフォルトのポートを指定しなければなりませんが、このポートは、必要に応じて後に変更することが可能です。
デフォルトのポート変更の詳細については、
クラスタリングコンポーネントのプロパティの変更を参照してください。
［Edit Dispatcher ports］をクリックして、Dispatcherを追加します。
次のようなパネルが表示されます。
Dispatcherがリッスンする各プロトコルタイプのポートの一部またはすべてに対して、ポート設定を指定します。
Dispatcherは、設定したすべてのポートタイプ(すでに設定して有効にした次の固有なサーバポートに対するHTTP、RSA、およびDSA)でリッスンします。
HTTPポートを無効にし、HTTPSまたはRMIクライアント通信を使用することができます。詳細については、 HTTP接続のオフを参照してください。
各セキュリティプロトコルのデフォルトのポート設定の詳細については、
ポートタイプを参照してください。
パネルに表示されるポート設定は、次の表のとおりです。クラスタを最初に作成するときには、各クラスタに対してデフォルトのポートを指定しなければなりませんが、これらのポートは、必要に応じて後に変更することが可能です。
|
項目 |
説明 |
|---|---|
|
RMI Port |
Load ManagerとのDispatcher通信に対するポート。Dispatcher、Cache Manager、およびLoad Managerによって使用されます。 デフォルトは54891です。 |
|
HTTP Settings: Runtime Port Admin Port |
Dispatcherによって使用されるクライアントとの非暗号化通信に対するHTTPポート。HTTPポートは、3つまで設定できます。 デフォルトにより、クラスタのランタイムポートと管理ポートでは、同じデフォルトのポート番号の54892が使用されます。
|
|
RSA Settings: Runtime Port Admin Port |
Dispatcherによって使用される(HTTPSを使用した)非暗号化通信に対するRSAポート。 デフォルトにより、Dispatcherでは、クラスタのすべてのRSAランタイムポートとRSA管理ポートに対して、同じデフォルトのポート番号(54893)を使用します。 |
|
DSA Settings: Runtime Port Admin Port |
Dispatcherによって使用される(HTTPSを使用した)非暗号化通信に対するDSAポート。 デフォルトにより、Dispatcherでは、クラスタのすべてのDSAランタイムポートとDSA管理ポートに対して、同じデフォルトのポート番号(54894)を使用します。 |
デフォルトのポート変更の詳細については、
クラスタリングコンポーネントのプロパティの変更を参照してください。
クラスタを作成したら、各サーバを再起動しなければなりません。Load Managerを実行している場合は、Load ManagerとDispatcherも再起動する必要があります。
サーバの再起動の詳細については、
アプリケーションサーバの再起動を参照してください。
クラスタリングコンポーネントの起動を参照してください。
クラスタの作成後、SMCには、クラスタ環境に固有なオプションが表示されます。
クラスタを作成すると、クラスタ内のサーバでは、スタンドアロンサーバとして最初に設定された時点から、「サーバローカル」プロパティと「サーバ保存」プロパティを保持します。これらの設定は、保持したり、またはサーバレベルで変更したりすることができます。
詳細については、
クラスタでのサーバレベルのプロパティの設定を参照してください。
ただし、クラスタ内に含まれているサーバでは、「クラスタ共有」プロパティとして定義されているプロパティの値は保持しません。クラスタ内の各サーバの「クラスタ共有」プロパティの値は、サーバがスタンドアロンサーバであった時点とは異なる可能性があるため、「クラスタ共有プロパティ」はクラスタレベルで再設定しなければならないためです。
したがって、新しいクラスタを作成すると、「クラスタ共有」プロパティの値は、すべてデフォルトの値に設定されます。これらの設定は維持したり、クラスタレベルで変更したりできます。クラスタレベルのプロパティを変更すると、新しい値が、クラスタ内のすべてのサーバに適用されます。クラスタを解除すると、クラスタ内のすべてのサーバは、スタンドアロンサーバになります。
詳細については、次の
クラスタレベルのプロパティの設定を参照してください。
前に説明したように、クラスタ環境で作業する場合には、クラスタレベルで終了するプロパティとサーバレベルで終了するプロパティがあります。SMCの左側でクラスタを選択すると、クラスタレベルのプロパティが表示されます。ほとんどのクラスタプロパティは、スタンドアロンサーバに対して設定されているものと同じです。クラスタレベルのプロパティに関するドキュメントの相互参照は、次の表のとおりです。
クラスタレベルの設定プロパティは、複数のSMCパネルにグループ化されています。
|
パネル |
説明 |
|---|---|
|
General |
クラスタに対するRMI/ORBプロパティおよびリモートオブジェクト用SSLプロパティ。
|
|
Advanced |
パフォーマンス、Cache Manager、およびLoad Managerのプロパティ。
|
|
Licenses |
ライセンス情報。
|
|
Managers |
Cache Manager、Load Manager、およびDispatcherのプロパティ。これらは、クラスタを作成したときに指定したプロパティです。これらのプロパティは、クラスタの作成後に編集できます。
|
|
Servers |
既存のクラスタにサーバを追加したり、既存のクラスタからサーバを削除したり、サーバの負荷ウェイトを変更したりできるようにします。 |
クラスタレベルのセキュリティプロパティは、次のSMCパネルにグループ化されています。
|
パネル |
説明 |
|---|---|
|
General |
クラスタに対する一般的なセキュリティ設定を指定します。
|
|
Advanced |
クラスタに対するクライアント証明書レベルと信頼するクライアントリストを指定します。
|
|
Permissions |
クラスタ設定を読み込んだり、クラスタ設定を変更したり、クラスタに対する許可を設定したりします。
|
|
Users & Groups |
クラスタに対してSilver Securityのユーザとグループおよび証明書のユーザとグループを管理します。
|
|
Certificates |
サーバにインストールされている証明書と、認識されているCA (認証局)を表示します。
|
|
Security Providers |
外部セキュリティプロバイダ(Windowsディレクトリサービス、LDAP、NIS+、および証明書発行者を含む)を設定します。
|
クラスタレベルの監視プロパティは、スタンドアロンサーバに対するプロパティのサブセットです。
監視プロパティの詳細については、
サーバのアクティビティの監視を参照してください。
スタンドアロンサーバがクラスタに追加されると、そのサーバレベルのプロパティの多くはクラスタレベルのプロパティになります。
SMCの左側でクラスタ内のサーバを選択した場合、クラスタ内の「サーバ」のプロパティが表示されます。クラスタ内にあるサーバのほとんどのプロパティは、スタンドアロンサーバに対して設定されているものと同じです。
この節では、クラスタ内のサーバのプロパティに関するドキュメントの相互参照をリストします。クラスタ内のサーバの設定プロパティは、次のSMCパネルにグループ化されています。
|
パネル |
説明 |
|---|---|
|
General |
サーバの一般的な設定。 |
|
Advanced |
デバッグ、パフォーマンス、キャッシュ、トランザクション、Cache Manager、およびLoad Managerのプロパティ。
|
|
Pools |
コネクタ接続プールおよびJDBC接続プール。
|
|
Connections |
クライアント接続プロパティ。
|
|
Databases |
クラスタの配備データベース(クラスタのSilverMasterに認識されているデータベース)に関する情報。クラスタ内にある各サーバのデータベース接続の最小数および最大数は変更できます。
|
サーバレベルでクラスタを管理するサーバのアクセラレータ設定。
アクセラレータ設定の詳細については、
CHI (Cryptographic Hardware Integration)の使用を参照してください。
クラスタの監視プロパティは、スタンドアロンサーバに対するプロパティと同じです。
監視プロパティの詳細については、
サーバのアクティビティの監視を参照してください。
クラスタ内の各サーバに対しては、相対処理ウェイトを指定できます。Load Managerでは、この情報を使用して、ランタイム時における各サーバの処理負荷を決定する分散マップを生成します。
ウェイトのしくみの詳細については、
分散マッピングを参照してください。
SMCでは、システムエラーが発生した場合のCache ManagerとLoad Managerでの対応方法を制御するプロパティにアクセスできます。通常は、これらのプロパティを編集する必要はありません。
Cache ManagerプロパティおよびLoad Managerプロパティは、クラスタレベルとサーバレベルの両方で存在します。クラスタレベルでプロパティを設定すると、クラスタ内の各サーバに対して値を設定できます。その後、クラスタ内の任意のサーバの値を上書きすることが可能です。ただし、クラスタレベルで任意のプロパティを後に変更した場合は、サーバレベルで行った設定が上書きされてしまうので注意してください。
Cache Managerプロパティは、サーバとの接続に失敗した場合にCache Managerで対応する方法を決定します。
クラスタレベルでプロパティを設定するためにクラスタを選択するか、またはサーバレベルでプロパティを設定するためにクラスタ内のサーバを選択します。
|
プロパティ |
説明 |
|---|---|
|
Start sleep interval |
サーバとの再接続を連続して試行し始める前にCache Managerで待機する秒数。 |
|
Reconnect sleep interval |
新しい一連の再接続試行までの秒数。 |
|
Start try count |
エラーを生成する前に一連の再接続試行を開始する回数。 |
|
Reconnect try count |
再接続を試行する、一連内での回数。 |
Load Managerプロパティは、サーバとの通信に失敗した場合にLoad Managerで対応する方法を決定します。
クラスタレベルでプロパティを設定するためにクラスタを選択するか、またはサーバレベルでプロパティを設定するためにクラスタ内のサーバを選択します。
|
プロパティ |
説明 |
|---|---|
|
Connect try interval |
再試行の各一連の後に待機する秒数。 |
|
Connect sleep interval |
一連内での各接続再試行の後に待機する秒数。 |
|
Connect try count |
Load Managerでサーバとの接続を連続して試行し始める回数。 |
|
Connect sleep count |
一連内での接続再試行の数。 |
クラスタは解除することが可能です。クラスタを解除すると、次のことが行われます。
クラスタリングコンポーネント(Load Manager、Dispatcher、およびCache Manager)を実行するホストは、変更することが可能です。また、クラスタリングコンポーネントで使用するポートを変更することもできます。
クラスタを作成した後、異なるホストでクラスタリングコンポーネントを実行することを決定する場合があります。
デフォルトにより、すべてのクラスタリングコンポーネントでは、RMIポートに対してポート54891を使用します。また、Dispatcherでは、HTTPポート、RSAポート、およびDSAポートに対して、ポート54892、54893、および54894をそれぞれ使用します。固有なランタイムポートや管理ポートを定義する必要がない限り、通常は、これらのポート値を変更しません。
ただし、固有なランタイムポートや管理ポートの定義が必要になった場合は、クラスタを作成した後でポートを変更できます。
注記: すべてのクラスタリングコンポーネントでは、同じRMIポートを使用しなければなりません。
クラスタ内の各サーバと各クラスタリングコンポーネントを停止して再起動します。
Cache Managerのポートを変更した場合は、次のコマンドラインを使用してCache Managerを起動する必要があります。
SilverCacheMgr -p portNumber
クラスタがHTTPSポートでリッスンして機能するようにするには、クラスタ内の各サーバにサーバ証明書をインストールする必要があります。アプリケーションサーバのソフトウェアであるDispatcher (SilverDispatcher)を使用する場合は、Dispatcherに対しても証明書をインストールしなければなりません。
証明書およびHTTPS/SSLの詳細については、
証明書の使用を参照してください。
アプリケーションサーバのソフトウェアであるDispatcherをクラスタに対して使用する場合は、各アプリケーションサーバのサーバ証明書のDNS名が「サーバ」のホスト名に一致していなければなりません。
URLマスキング(クラスタ内のサーバにヒットしたブラウザでディスパッチャのホスト名が表示されるようにすべてのURLをマスクすること)を行うCisco LocalDirectorなどのサードパーティ製のハードウェアディスパッチャを使用する場合は、各アプリケーションサーバのサーバ証明書のDNS名が「ディスパッチャ」のホスト名に一致していなければなりません。
アプリケーションサーバのDispatcherを使用する場合は、Dispatcherのマシンに対して1つ(DNS名: www.myhost.com)、各サーバに対して1つずつ(DNS名: server1.myhost.com、server2.myhost.com、およびserver3.myhost.com)、合わせて4つのサーバ証明書を作成する必要があります。
サードパーティ製のURLマスキングディスパッチャを使用する場合は、サーバ証明書を1つだけ作成し(DNS名: www.myhost.com)、各サーバにアップロードする必要があります。
SMCを使用して、RSA証明書またはDSA証明書を生成します。
アプリケーションサーバのソフトウェアであるDispatcherを使用する場合は、クラスタ内で使用される各サーバとDispatcherに対して、それぞれ異なる証明書を生成します。
サードパーティ製のディスパッチャを使用する場合は、ディスパッチャのDNS名を持つ証明書を1つ生成します(前の説明を参照)。
詳細については、
証明書についてを参照してください。
証明書をインストールする(Dispatcherソフトウェアを使用する場合)
詳細については、
SMC使用によるサーバ証明書の作成およびインストールを参照してください。
サーバは、HTTPSポート(デフォルト: RSA証明書とDSA証明書に対しては443)でリッスンするようになります。
Dispatcherに証明書をインストールするには、-c起動オプションを使用してDispatcherを起動します。これにより、Dispatcherは、証明書をアップロードできるモードになります。
詳細については、
クラスタリングコンポーネントの起動を参照してください。
AgDigitalIDStep2を呼び出して、Dispatcherを含むマシンに証明書をインストールします。
詳細については、
Using AgDigitalIDStep2を参照してください。
画面の指示に従って、アプリケーションサーバのDispatcherを含むマシンと、DispatcherがリッスンするHTTPポート(デフォルト: 54892)を指定します。
証明書をインストールしたら、Dispatcherを停止し、通常通りに再起動します(-c起動オプションを使用せずに)。
Dispatcherは、HTTPSポート(デフォルト: RSA証明書に対しては54893、DSA証明書に対しては54894)でリッスンするようになります。
証明書をインストールする(サードパーティ製のディスパッチャを使用する場合)
AgDigitalIDStep2を呼び出して、ディスパッチャのDNS名を参照する証明書をサーバにインストールします。
詳細については、
Using AgDigitalIDStep2を参照してください。
画面の指示に従って、サーバと、サーバがリッスンするHTTPポート(デフォルト: NetWareの場合は83、NTの場合は80、UNIXの場合は8080)を指定します。
サーバのhttpd.propsファイル(サーバの\Resourcesディレクトリにあります)に次の行を追加します。
http-server.com.sssw.srv.https.cert.hostname=DispatcherName
ここで、DispatcherNameは、ディスパッチャのDNS名です。
サーバは、HTTPSポート(デフォルト: RSA証明書とDSA証明書に対しては443)でリッスンするようになります。
|
|
管理ガイド 05/21/03 10:02:24 |
Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC, a wholly owned subsidiary of Novell, Inc. All rights reserved.