6 トポロジのスケール・アウト(マシンのスケール・アウト)
- マシンのスケール・アウトについて
スケーラビリティとは、将来のニーズや状況に応じて、ハードウェア、ソフトウェア、ネットワークの構成を拡張または縮小できる能力を表します。スケーラブルなシステムは、レスポンス時間とスループットを低下させることなく、リクエストの増加に対処できます。 - トポロジのスケール・アウト手順
製品をインストールおよび構成し、管理対象サーバーのクラスタを設定したら、このロードマップを使用してトポロジをスケール・アウトします。 - オプションのスケール・アウト手順
標準的なインストール・トポロジ(SIT)に従うと、複数の管理対象サーバーが1つのホスト・コンピュータに割り当てられます。 - スケール・アウトの前提条件について
スケール・アウトのプロセスを開始するには、製品の標準的なインストール・トポロジ(SIT)を設定しておく必要があります。SITはスケール・アウトの開始点になります。 - リソース要件
トポロジをスケール・アウトする前に、現在の環境が特定の要件を満たしていることを確認します。 - 新しいマシンの作成
マシンは、1つまたは複数のWebLogic Serverインスタンス(管理対象サーバー)をホストするコンピュータの論理表現です。WebLogicドメインでは、マシン定義によってハードウェアの物理ユニットが識別され、それらの定義はホストする管理対象サーバーに関連付けられます。 - マシンのスケール・アップまたはスケール・アウト後のWLS JMSの構成
JMSシステム・リソースをクラスタに追加する場合は、新しい管理対象サーバーですべてのJMSシステム・リソースを手動で再作成する必要があります。 - APPHOST1上のドメインの圧縮
WebLogicドメイン上でpack
コマンドを実行して、管理対象サーバーのテンプレートを作成します。 - 新しいマシンの準備
新しいマシンmachine_2の準備として、APPHOST2からOracleホームがインストールされている共有ディスクにアクセスできるかどうかを検証するか、machine_1上にインストールしたものと同じソフトウェアをインストールします。 - テンプレートを転送するためのアンパックの実行
テンプレートをアンパックして、APPHOST1からAPPHOST2にdomain_name.jarファイルを転送するには、unpackコマンドを実行します。 - ノード・マネージャの起動
ノード・マネージャを使用して管理対象サーバーを起動します(管理コンソールまたはFusion Middleware Controlを使用)。 - 管理対象サーバーの起動
管理コンソールで管理対象サーバーを起動します。 - マシンのスケール・アウトの検証
マシンのスケール・アウトが正常に完了したかどうかを検証するには、(管理コンソールを使用してサーバーを起動した後に)サーバー・ステータスがRUNNINGになっていることを確認します。 - クラスタ用マルチキャスト・メッセージングの構成
サービスが使用可能かどうかなどの情報をクラスタ間でやり取りできるようにするために、メッセージングを使用するようにクラスタを構成します。
親トピック: 高可用性環境の作成
マシンのスケール・アウトについて
スケーラビリティとは、将来のニーズや状況に応じて、ハードウェア、ソフトウェア、ネットワークの構成を拡張または縮小できる能力を表します。スケーラブルなシステムは、レスポンス時間とスループットを低下させることなく、リクエストの増加に対処できます。
マシンのスケール・アウトとは、高可用性を実現するために、1つのマシン上に複数あるサーバーの1つを別のマシンに移行するプロセスを表します。マシンのスケール・アウトは、管理対象サーバーのスケール・アップとは異なります(管理対象サーバーのスケール・アップとは、すでに1つ以上の管理対象サーバーが稼働しているマシンに対して新しい管理対象サーバーをマシンに追加することです)。Oracle Fusion Middleware Oracle Fusion Middlewareの管理の環境のスケール・アップを参照してください。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
トポロジのスケール・アウト手順
製品をインストールおよび構成し、管理対象サーバーのクラスタを設定したら、このロードマップを使用してトポロジをスケール・アウトします。
表6-1は、トポロジをスケール・アウトするために行う必要のある標準的なステップを示します。
SITがすでにある場合(Oracle Fusion Middleware Infrastructureのインストールと構成およびOracle SOA SuiteおよびBusiness Process Managementのインストールと構成などの製品のインストレーション・ガイドで説明するとおり)、リソース要件、新しいマシンの作成およびマシンのスケール・アップまたはスケール・アウト後のWLS JMSの構成のステップを繰り返す必要はありません。
表6-1は、SITのステップを実施しなかった場合の完全なステップを示します。
表6-1 トポロジのスケール・アウト手順
作業 | 説明 | 参照先 |
---|---|---|
スケール・アウト用の製品の準備 |
製品のインストールと構成を行い、管理対象サーバーのクラスタが使用可能になっています。つまり、製品はSITの状態です。 |
|
リソース要件を満たしているかどうかの確認 |
ご使用の環境が特定の要件を満たしているかどうかを確認する必要があります。 |
|
新しいマシンの作成およびサーバーの割当て |
管理コンソールを使用して、新しいマシンを作成し、それに管理対象サーバーを追加します。 |
|
新しいJMSサーバーの作成およびターゲットの指定 |
新しいJMSサーバーを作成し、新しい管理対象サーバーをターゲットに指定します。 |
|
packコマンドの実行 |
ドメイン・ディレクトリをパックします。 |
|
新しいマシンの準備 |
最初のマシンにインストールしたソフトウェアと同じものをインストールします。 |
|
unpackコマンドの実行 |
管理対象サーバーのテンプレートを作成します。 |
|
サーバーの起動 |
新しいマシン上で管理対象サーバーを起動します。 |
|
トポロジの検証 |
新しい設定をテストします。 |
|
「クラスタのメッセージング・モード」を「マルチキャスト」に設定します。 |
メッセージング・モードを「ユニキャスト」から「マルチキャスト」に変更します(マルチサーバー・ドメインに適した設定)。 |
注意:
APPHOSTは物理ホスト・コンピュータを指します。マシンは、そのホストを説明名するWebLogic Serverマシンの定義を指します。詳細はOracle Fusion Middleware Infrastructureのインストールと構成のOracle Fusion Middleware Infrastructureの標準的なインストール・トポロジの理解を参照してください。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
オプションのスケール・アウト手順
標準的なインストール・トポロジ(SIT)に従うと、複数の管理対象サーバーが1つのホスト・コンピュータに割り当てられます。
この設定は、様々な要件にあわせてドメイン・トポロジを作成したりスケール・アウトできる、最も柔軟性の高い手法です。追加のコンピューティング・リソースが必要になった場合は、1) 単一ホスト・ドメインを作成および検証して、1つのホスト・コンピュータ上の1つのマシンにターゲット指定し、2)管理対象サーバーのターゲットを追加のマシンに変更します。また、先に基本ドメインを検証してから、スケール・アップやスケール・アウト(トラブルシューティング)を行うため、トラブルシューティングが容易になります。
ただし、ターゲットのトポロジが事前にわかっている場合は、ドメインの作成中に追加のマシンを作成して、パックとアンパックのステップのみを実行することができます。
最初のインストール中に、またはオンラインの管理操作を通じて、管理対象サーバーをターゲット・マシンに割り当てている場合は、手順(トポロジのスケール・アウト手順)に含まれている新しいマシンの作成をスキップしてください。
マシンのマッピングの詳細は、製品のインストレーション・ガイドの新しいマシンの作成に関する項を参照してください。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
スケール・アウトの前提条件について
スケール・アウトのプロセスを開始するには、製品の標準的なインストール・トポロジ(SIT)を設定しておく必要があります。SITはスケール・アウトの開始点になります。
ご使用の製品のインストレーション・ガイドに従ってステップを実行していれば、SITが構成されているはずです。SITの例は、『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』.のOracle Fusion Middleware Infrastructureの標準的なインストール・トポロジの理解に関する項の説明を参照してください。
注意:
SITの詳細は、ご使用の製品のインストレーション・ガイド、またはOracle Fusion Middlewareのインストールのプランニングの標準的なインストール・トポロジについてを参照してください。
注意:
このリリースのアプリケーション層製品は、動的クラスタをサポートしていません。動的クラスタは、アプリケーションのリソース・ニーズを満たすように動的にスケール・アップできるサーバー・インスタンスで構成されます。動的クラスタは、指定した数の生成された(動的)サーバー・インスタンスの構成を定義する単一のサーバー・テンプレートを使用します。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
リソース要件
トポロジをスケール・アウトする前に、現在の環境が特定の要件を満たしていることを確認します。
-
1つ以上のマシンが、製品に構成された複数の管理対象サーバーを実行する。これは製品のインストレーション・ガイドまたは管理ガイドに従ってサーバーを追加した状態です。
-
開始時のホスト・コンピュータとは別にホスト・コンピュータがある。
-
製品のバイナリが格納されているOracleホームに対して、次のいずれかの方法で各ホスト・コンピュータからアクセスできる。
-
元のインストールのバイナリが格納されている共有ディスク
-
新しいインストール(元のインストールと同じ)が格納されている専用ディスク
-
元のインストールから複製したバイナリが格納されている専用ディスク
共有記憶域の使用を参照してください。
-
-
ドメイン・ディレクトリに使用できる十分な記憶域がある。
-
元のインストールに使用したものと同じOracle Databaseまたはサード・パーティ・データベースにアクセスできる。
-
JMSおよびトランザクション・ログ・ファイル用の共有ディスクがある(ファイル永続性プロファイルを使用する場合は必須です)。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
新しいマシンの作成
マシンは、1つまたは複数のWebLogic Serverインスタンス(管理対象サーバー)をホストするコンピュータの論理表現です。WebLogicドメインでは、マシン定義によってハードウェアの物理ユニットが識別され、それらの定義はホストする管理対象サーバーに関連付けられます。
新しいマシンを作成するには、この項のステップに従います。
- 管理対象サーバーの停止
新しいマシンに移動する前に、管理対象サーバーを停止する必要があります。 - 新しいマシンの作成(管理コンソールの使用)
管理対象サーバーをホストし、ハードウェアの物理ユニットを識別するための、新しいマシンを作成します。通常、管理コンソールを使用して新しいマシンを作成します。 - 新しいマシンへの管理対象サーバーの割当て
新しいマシンに管理対象サーバーを割り当て、マシンでホストするサーバーを指定します。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
管理対象サーバーの停止
新しいマシンに移動する前に、管理対象サーバーを停止する必要があります。
現在稼働している場合は、管理コンソール・オンライン・ヘルプのサーバー・インスタンスの停止に関する項を参照して、新しいマシンがホストする管理対象サーバーを停止してください。管理対象サーバーがクラスタ内にある場合、クラスタ内のサーバー・インスタンスの停止に関する項を参照してください。
親トピック: 新しいマシンの作成
新しいマシンの作成(管理コンソールの使用)
管理対象サーバーをホストし、ハードウェアの物理ユニットを識別するための新しいマシンを作成します。通常、管理コンソールを使用して新しいマシンを作成します。
WLSTを使用して新しいマシンを作成する場合は、Oracle Fusion Middleware Oracle Fusion Middlewareの管理の特定のコンポーネントの新しいマシンの作成を参照してください。
注意:
この手順で作成するマシンには、ローカル・ホストの他に、特定のネットワーク・インタフェースのリスニング・アドレスを指定する必要があります。
ドメインに新しいマシンを作成する手順:
親トピック: 新しいマシンの作成
新しいマシンへの管理対象サーバーの割当て
新しいマシンに管理対象サーバーを割り当て、マシンでホストするサーバーを指定します。
新しく作成したマシンに管理対象サーバーを割り当てるには、管理コンソールで次の手順を実行します。
親トピック: 新しいマシンの作成
マシンのスケール・アップまたはスケール・アウト後のWLS JMSの構成
JMSシステム・リソースをクラスタに追加する場合は、新しい管理対象サーバーですべてのJMSシステム・リソースを手動で再作成する必要があります。
新しいJMSシステム・リソースは、クラスタ内の既存の管理対象サーバーからクローン作成します。新しいJMSシステム・リソースには、ドメイン内で一意の名前を与える必要があります。ドメインを作成した際に、構成ウィザードによって、次のパターンに従ったJMSシステム・リソース名が作成されます。管理性と利便性の点から、同じ命名パターンに従って名前を付けることをお薦めします。
新しい管理対象サーバーserver
_n上のJMSリソースを構成するには、次の手順を実行します。
-
「ドメイン構造」ツリーで「サービス」、「メッセージング」の順に選択します。「JMSサーバー」を選択して、「JMSサーバー」表を開きます。
-
「名前」列で、クラスタ内の既存の管理対象サーバー(たとえば、
server_1
)がターゲットに指定されているJMSサーバーを、すべて特定します。JMSサーバー名の書式は、リソース名_auto_番号です。
-
リソース名は、リソースを識別する名前です。
-
番号でJMSサーバーが識別されます(1または2の接尾辞を与えられているサーバーは、ドメインの作成時に作成されたサーバーです)。
-
-
JMSサーバーおよび永続ストアの名前をメモに記録します。例:
UMSJMSServer_auto_1
およびUMSJMSFileStore_auto_1
。 -
「新規」をクリックして、新しいJMSサーバーを作成します。
-
server_1
と同じ書式に従って、server
_nのJMSサーバーに名前を付けます。例:UMSJMSServer_auto_
n。 -
「永続ストア」で、「新しいストアの作成」をクリックします。
-
「タイプ」で、
server_1
上でそのJMSサーバーにより使用されているのと同じ永続性プロファイルを選択します。「次へ」をクリックします。 -
「名前」フィールドに、永続ストア名を入力します。
server_1
の永続ストアと同じと書式を使用します。例:UMSJMSFileStore_auto_
n。 -
「ターゲット」フィールドで、ドロップダウン・リストから、移行可能なターゲット
server_
n(移行可能)
用の移行可能なターゲットを選択します。 -
「ディレクトリ」フィールドには、永続ストアと同じ名前を使用します。「OK」をクリックして、永続ストアを作成します。
-
「新しいJMSサーバーの作成」画面で、新しい永続ストアを選択し、「次へ」をクリックします。
-
「JMSサーバーターゲット」で、ドロップダウン・リストから、
server
_n (移行可能)用の移行可能なターゲットを選択します。 -
「終了」をクリックし、JMSサーバーを作成します。
-
-
対応するJMSモジュールのサブデプロイメント・ターゲットを更新し、新しいJMSサーバーを追加します。
-
管理コンソールの「ドメイン構造」ツリーで、「サービス」ノードを開いて、「メッセージング」ノードを開いて、「JMSモジュール」を選択して、「JMSモジュール」表を開きます。
-
JMSサーバーに対応するJMSシステム・モジュールを特定します。名前に共通のルートが含まれています。たとえば、JMSサーバー
UMSJMSServer_auto_1
に対応したJMSモジュール名は、UMSJMSSystemResource
です。「名前」列で、JMSモジュール(ハイパーリンク)をクリックし、モジュールの「設定」ページを開きます。 -
「サブデプロイメント」タブを開き、「名前」列で、JMSモジュールのサブデプロイメントをクリックします。
-
新しい「JMSサーバー」
server
_nを選択します。「保存」をクリックします。 -
モジュールの「設定」ページに戻ります。「ターゲット」タブを選択します。「クラスタのすべてのサーバー」が有効になっていることを確認します。
-
変更を行った場合は、「保存」をクリックします。
-
JMSリソースをクラスタ内に構成した新しい管理対象サーバーが使用できます。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
APPHOST1上のドメインのパック
WebLogicドメイン上でpack
コマンドを実行して、管理対象サーバーのテンプレートを作成します。
注意:
パックおよびアンパックのステップを実行する際には、APPHOST1上で管理サーバーが稼働している必要があります。
APPHOST1上でpack
コマンドを実行して、テンプレート・パックを作成します。APPHOST2上のテンプレート・ファイルは、スケール・アウト・プロセスの後半でアンパックします。テンプレートを転送するためのアンパックの実行でアンパック・ステップについて説明します。
例:
ORACLE_HOME/oracle_common/common/bin/pack.sh \ -domain=DOMAIN_HOME \ -template=dir/domain_name.jar \ -managed=true \ -template_name="DOMAIN"
前述の例は、次のとおりです。
-
DOMAIN_HOMEを、ドメイン・ホーム・ディレクトリのフルパスに置き換えます。
-
dirを、新しいテンプレート・ファイルの作成先となる予約済ディレクトリのフルパスに置き換えます。
-
JARファイル名のdomain_nameをドメイン名に置き換えます。これは、
pack
コマンドで作成するテンプレート・ファイルの名前です。たとえば、mydomain.jar
です。注意:
管理対象サーバーのテンプレートを作成する方法の詳細は、WebLogicドメインおよびドメイン・テンプレートの作成に関するドキュメントのpackおよびunpackのコマンド・リファレンスに関する項を参照してください。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
新しいマシンの準備
新しいマシンmachine_2の準備として、APPHOST2からOracleホームがインストールされている共有ディスクにアクセスできるかどうかを検証するか、machine_1上にインストールしたものと同じソフトウェアをインストールします。
たとえば、Oracle Fusion Middlewareインフラストラクチャのドメインをスケール・アウトする場合は、APPHOST2からインフラストラクチャのOracleホームにアクセスできることを検証します。
注意:
共有記憶域を使用する場合は、同じインストール場所を再利用できます。
注意:
新しいインストールを実行するか、共有記憶域を使用してバイナリを再利用する場合、新しいファイルのパスの場所は元のマシンのパスの場所と正確に一致する必要があります。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
テンプレートを転送するためのアンパックの実行
テンプレートをアンパックして、APPHOST1からAPPHOST2にdomain_name.jarファイルを転送するには、unpackコマンドを実行します。
例:
ORACLE_HOME/oracle_common/common/bin/unpack.sh \
-domain=user_projects/domains/base_domain2 \
-template=/tmp/domain_name.jar \
-app_dir=user_projects/applications/base_domain2
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
ノード・マネージャの起動
ノード・マネージャを使用して管理対象サーバーを起動します(管理コンソールまたはFusion Middleware Controlを使用)。
ノード・マネージャを起動するには、次を実行します。
DOMAIN_HOME/bin/startNodeManager.sh &
マシンにスコープ指定したノード・マネージャを使用する場合、ノード・マネージャの起動オプションの詳細は、Oracle WebLogic Serverノード・マネージャの管理のノード・マネージャの使用を参照してください。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
管理対象サーバーの起動
管理コンソールで管理対象サーバーを起動します。
管理対象サーバーの起動手順:
- 管理コンソールの左側のペインで、「環境」,を展開し、「サーバー」を選択します。
- 「サーバー」表で、新しいマシンに移動した管理対象サーバー名をクリックします。「制御」タブを選択します。
- 起動するサーバー名の横のチェック・ボックスを選択し、「開始」をクリックして、サーバーを起動します。
注意:
WLSTコマンドまたはFusion Middleware Controlを使用して管理対象サーバーを起動する方法については、Oracle Fusion Middleware Oracle Fusion Middlewareの管理の管理対象サーバーの起動と停止を参照してください。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
マシンのスケール・アウトの検証
マシンのスケール・アウトが正常に完了したかどうかを検証するには、(管理コンソールを使用してサーバーを起動した後に)ステータスがRUNNINGになっていることを確認します。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
クラスタ用マルチキャスト・メッセージングの構成
サービスが使用可能かどうかなどの情報をクラスタ間でやり取りできるようにするために、メッセージングを使用するようにクラスタを構成します。
- クラスタ用マルチキャストとユニキャスト・メッセージングについて
クラスタでは、サービスの可用性、および継続的な可用性を示すハートビートをブロードキャストするために、メッセージングが使用されます。クラスタを構成して、ユニキャストまたはマルチキャスト・メッセージングを使用します。 - マルチキャスト・メッセージングを構成するための要件
マルチキャスト・メッセージングを構成する前に、システムとネットワークの要件が満たされていることを確認します。 - マルチキャスト・メッセージングの構成
管理コンソールで、マルチキャスト・メッセージングを有効にするクラスタを選択し、マルチキャスト・メッセージング・モードを選択して、マルチキャスト・メッセージングを構成します。
親トピック: トポロジのスケール・アウト(マシンのスケール・アウト)
クラスタ用マルチキャストとユニキャスト・メッセージングについて
クラスタでは、サービスの可用性、および継続的な可用性を示すハートビートをブロードキャストするために、メッセージングが使用されます。クラスタを構成して、ユニキャストまたはマルチキャスト・メッセージングを使用します。
-
マルチキャストは、単純なブロードキャスト技術です。複数のアプリケーションがIPアドレスとポート番号をサブスクライブし、メッセージをリスニングします。ハードウェアの構成およびサポートが必要なため、マルチキャストはユニキャストに比べて設定が複雑です。
-
ユニキャストは、TCPベースの信頼性あるの1対多通信です。マルチキャストに比べて設定が簡単です。
構成ウィザードでクラスタを作成した場合は、クラスタ・メッセージング・モードが、デフォルトでユニキャストに設定されます。ドメイン内の管理対象サーバー数が増加した場合は、マルチキャスト・メッセージングをお薦めします。
親トピック: クラスタ用マルチキャスト・メッセージングの構成
マルチキャスト・メッセージングを構成するための要件
マルチキャスト・メッセージングを構成する前に、システムとネットワークの要件が満たされていることを確認します。
-
少なくとも1つのクラスタを持つドメインが構成されていること。
-
ネットワークでマルチキャストをサポートするようハードウェアが構成されていること。
-
クラスタ内にマルチキャスト通信用のIPアドレスおよびポート番号があること。マルチキャスト・アドレスは、224.0.0.0から239.255.255.255までの範囲のIPアドレスです。(Weblogicでは、デフォルトで239.192.0.0が使用されます)。
-
MulticastTestユーティリティを実行して、環境がマルチキャストをサポートすることを確認済であること。これは、マルチキャストの問題をデバッグするユーティリティで、マルチキャスト・パケットを送信し、ネットワーク上でマルチキャストがどのくらい効果的に機能しているかに関するデータを返します。
注意:
マルチキャスト・メッセージングおよびクラスタ構成の詳細は、Oracle WebLogic Serverクラスタの管理のクラスタ内の通信を参照してください。
親トピック: クラスタ用マルチキャスト・メッセージングの構成
マルチキャスト・メッセージングの構成
管理コンソールで、マルチキャスト・メッセージングを有効にするクラスタを選択し、マルチキャスト・メッセージング・モードを選択して、マルチキャスト・メッセージングを構成します。
マルチキャスト・メッセージングを構成するには、次の手順を実行します。
これで、クラスタでマルチキャスト・メッセージングを使用できます。管理コンソールの「ドメイン構造」ペインで、「クラスタ」を選択すると、「クラスタのメッセージング・モード」に「マルチキャスト」と表示されます。
親トピック: クラスタ用マルチキャスト・メッセージングの構成