| Oracle® Fusion Middleware高可用性ガイド 12c (12.2.1.2) E82746-02 |
|
 前へ |
 次へ |
packコマンドを実行して、サーバーのテンプレートを作成します。親トピック: 高可用性環境の作成
スケーラビリティとは、将来のニーズや状況に応じて、ハードウェア、ソフトウェア、ネットワークの構成を拡張または縮小できる能力を表します。スケーラブルなシステムは、レスポンス時間とスループットを低下させることなく、リクエストの増加に対処できます。
マシンのスケール・アウトとは、高可用性を実現するために、1つのマシン上に複数あるサーバーの1つを別のマシンに移行するプロセスを表します。マシンのスケール・アウトは、管理対象サーバーのスケール・アップとは異なります(管理対象サーバーのスケール・アップとは、すでに1つ以上の管理対象サーバーが稼働しているマシンに対して新しい管理対象サーバーをマシンに追加することです)。Oracle Fusion Middleware Oracle Fusion Middlewareの管理の環境のスケール・アップを参照してください。
製品をインストールおよび構成し、管理対象サーバーのクラスタを設定したら、このロードマップを使用してトポロジをスケール・アウトします。
表6-1は、トポロジをスケール・アウトするために行う必要のある標準的な手順を示します。
SITがすでにある場合(『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』およびOracle Fusion Middleware 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の管理の特定のコンポーネントの新しいマシンの作成を参照してください。
注意:
この手順で作成するマシンには、ローカル・ホストの他に、特定のネットワーク・インタフェースのリスニング・アドレスを指定する必要があります。
ドメインに新しいマシンを作成する手順:
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リソースをクラスタ内に構成した新しい管理対象サーバーが使用できます。
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クラスタの管理のクラスタ内の通信を参照してください。
