| Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.2.1.3.0) E90317-02 |
|
 前 |
 次 |
クラスタの構成を定義する情報を格納およびメンテナンスする仕組みと、構成タスクを実施するために使用できる方法を理解します。
注意:
この章の情報の多くは、サーバー・インスタンスがクラスタ化されていないWebLogicドメインの構成プロセスに関連するものです。
config.xmlファイルは、WebLogic Serverドメインの構成を記述したXMLドキュメントです。
config.xmlファイルは、一連のXML要素で構成されています。<domain>要素はトップレベルの要素であり、ドメイン内のすべての要素は<domain>要素の子要素です。<domain>要素には、<server>、<cluster>、<application>などの子要素があります。子要素の中にさらに子要素がある場合もあります。たとえば、<server>要素には、子要素として<WebServer>、<SSL>、および<Log>があります。<application>要素には<EJBComponent>と<WebAppComponent>という子要素があります。
各要素には、1つ以上の構成可能な属性があります。config.dtdに定義されている属性には、構成APIに対応する属性があります。たとえば、Server要素にはListenPort属性があり、同様に、weblogic.management.configuration.ServerMBeanにもListenPort属性があります。構成可能な属性は読取り可能かつ書込み可能であり、言い換えると、ServerMBeanにはgetListenPortメソッドとsetListenPortメソッドがあります。
config.xmlファイルの詳細は、Oracle WebLogic Serverドメイン構成の理解のドメイン構成ファイルを参照してください。
管理サーバーは、そのドメイン内のWebLogic Serverインスタンス群を構成および管理するWebLogic Serverインスタンスです。
ドメインには複数のWebLogic Serverクラスタと、クラスタ化されないWebLogic Serverインスタンスが存在できます。厳密に言うと、ドメインは1つのWebLogic Serverインスタンスだけでも構成できます。ただしその場合、各ドメインには必ず1つの管理サーバーが存在しなければならないため、その唯一のサーバー・インスタンスが管理サーバーになります。
「クラスタを構成する方法」で説明されているように、管理サーバーのサービスを呼び出して構成タスクを実施する方法はいくつかありますどの方法を使用する場合でも、構成を修正するときはクラスタの管理サーバーが稼働している必要があります。
管理サーバーが起動すると、ドメインのconfig.xmlがロードされます。config.xmlは、次のディレクトリで検索されます。
ORACLE_HOME/user_projects/domains/domain_name/config
domain_nameはドメインに固有のディレクトリで、その名前はドメインと同じです。
注意:
configディレクトリまたはサブディレクトリに構成ファイル以外のファイルを追加しないでください。構成ファイル以外のファイルにはログ(.log)ファイルおよびロック(.lck)ファイルが含まれます。管理サーバーは、すべての管理対象サーバー・インスタンスのconfigディレクトリをレプリケートします。構成ファイル以外のファイルをconfigディレクトリに格納すると、ドメインにおいてパフォーマンスの問題が発生する可能性があります。
管理サーバーが正常に起動するたびに、config.xml.bootedという名前のバックアップ構成ファイルがドメイン・ディレクトリに作成されます。サーバー・インスタンスの存続期間中に万一config.xmlファイルが破損した場合、このファイルを使用して以前の構成に戻すことができます。
図4-1は、1つの管理サーバーと複数のWebLogic Serverインスタンスで構成される典型的な本番環境を示しています。このようなドメインでサーバー・インスタンスを起動すると、まず管理サーバーが起動します。その他の各サーバー・インスタンスは、起動時に管理サーバーにアクセスしてその構成情報を取得します。このように、管理サーバーはドメイン全体の構成の一元的な制御エンティティとして動作します。
ドメインの管理サーバーで障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。管理対象のサーバー・インスタンスが(クラスタ化されているかいないかには関係なく)動作しているときにドメインの管理サーバーが使用できなくなっても、その管理対象サーバーは処理を続けます。ドメインにクラスタ化サーバー・インスタンスがある場合は、管理サーバーに障害が発生しても、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバー機能を使用できます。
注意:
ホスト・マシン上のハードウェアまたはソフトウェアに障害が発生したために管理サーバーに障害が発生した場合、同じマシン上の他のサーバー・インスタンスも同様に影響を受けることがあります。ただし、管理サーバー自体で障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。
管理サーバーを再起動する手順は、Oracle WebLogic Serverサーバーの起動と停止の管理のサーバー障害のリカバリとサーバー障害からのリカバリを参照してください。
WebLogic Serverでは、ドメイン・リソースの構成属性を動的に(サーバー・インスタンスの動作中に)変更できます。ほとんどの場合では、変更を有効にするためにサーバー・インスタンスを再起動する必要はありません。属性を構成しなおすと、新しい値が、実行時の現在の属性値とconfig.xmlに格納されている永続的な値の両方にただちに反映されます。
しかし、構成へのすべての変更が動的に適用されるわけではありません。たとえば、管理対象サーバーのListenPort値を変更した場合、新しいポートは管理対象サーバーを次に起動するまで使用されません。更新された値はconfig.xmlに保存されますが、実行時の値は影響を受けません。
WebLogic Server管理コンソールは、範囲外エラーやデータ型の不一致エラーをチェックして属性の変更を検証し、エラーがあるエントリではエラー・メッセージを表示します。
WebLogic Server管理コンソールの起動後に、管理サーバーに割り当てられたリスニング・ポートを別のプロセスが獲得した場合、ポートを獲得したプロセスを停止することをお薦めします。リスニング・ポートを獲得したプロセスを削除できない場合、config.xmlファイルを編集して、ListenPort値を変更します。
一般的なデプロイメント・タスクの実行手順については、「アプリケーションをデプロイする」を参照してください
次の方法を使用して、クラスタにアプリケーションをデプロイできます。
WebLogic Server管理コンソールおよびFusion Middleware Control (FMWC)
WebLogic Server管理コンソールおよびFMWCは、管理サービスにアクセスするためのグラフィカル・ユーザー・インタフェース(GUI)です。
weblogic.Deployer
weblogic.Deployerユーティリティは、WebLogic ServerデプロイメントAPIにコマンド行インタフェースを提供するJavaベースの開発ツールです。
WebLogic Scripting Tool
WebLogic Scripting Tool (WLST)は、アプリケーションのデプロイメント構成やデプロイメント操作などドメインの構成タスクの自動化に使用できるコマンド行インタフェースです。
これらのデプロイメント・ツールは、Oracle WebLogic Serverへのアプリケーションのデプロイのデプロイメント・ツールで説明されています。
使用するデプロイメント・ツールに関係なく、デプロイメント・プロセスを開始するときは、デプロイするコンポーネントとデプロイ先のターゲット(クラスタ、またはクラスタかドメイン内の個々のサーバー・インスタンス)を指定します。
プロセスの間、ドメインの管理サーバーはクラスタ内の管理対象サーバーと通信しながらデプロイメント・プロセスを管理します。各管理対象サーバーはデプロイするコンポーネントをダウンロードし、ローカルのデプロイメント・タスクを開始します。デプロイメント状態は、デプロイされるコンポーネントの関連するMBeanに保持されます。『デプロイメント管理API』を参照してください。
注意:
WebLogic Serverにデプロイする前にアプリケーションをパッケージ化する必要があります。『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリからのデプロイとパッケージ化に関する項にあるパッケージ化に関するトピックを参照してください。
WebLogic Serverでは、アプリケーションは2つのフェーズでデプロイされます。開始前に、WebLogic Serverはクラスタ内の管理対象サーバーが使用可能かどうかを判断します。
デプロイメントの第1フェーズでは、アプリケーション・コンポーネントがターゲット・サーバー・インスタンスに配布されます。アプリケーション・コンポーネントが正常にデプロイされるように、計画されたデプロイメントが検証されます。このフェーズでは、デプロイされるアプリケーションへのユーザー・リクエストは許可されません。
配布および検証プロセス中に障害が発生した場合は、検証が成功したインスタンスも含めて、すべてのサーバー・インスタンス上でデプロイメントが中止されます。ステージングされたファイルは削除されませんが、準備中に実行されたコンテナ側の変更は元に戻されます。
アプリケーション・コンポーネントは、ターゲットに配布されて検証された後で、ターゲット・サーバー・インスタンス上に完全にデプロイされます。デプロイされたアプリケーションはクライアントから使用できるようになります。
デプロイメントの第2フェーズ中に障害が発生した場合、サーバーは次のいずれかの動作で起動します。
ターゲット・サーバー・インスタンスへのデプロイ中に失敗した場合は、サーバー・インスタンスがADMIN状態で起動します。Oracle WebLogic Serverサーバーの起動と停止の管理のADMIN状態を参照してください。
クラスタ・メンバーがアプリケーションのデプロイに失敗した場合は、デプロイできなかったアプリケーションが使用不可能になります。
デプロイメント・プロセス中は、クラスタ内のすべての管理対象サーバーが実行中で使用可能になっていることが理想的です。クラスタ内の一部のメンバーが使用できないときにアプリケーションをデプロイすることはお薦めしません。クラスタにアプリケーションをデプロイする前に、可能であれば、クラスタ内のすべての管理対象サーバーを実行し、管理サーバーからアクセスできるようにしておきます。
注意:
デプロイメント時に分断された管理対象サーバー(実行中だが管理サーバーからアクセスできない状態)にアプリケーションをデプロイすると、その管理対象サーバーがクラスタに復帰するときに、管理対象サーバーへのアクセスについて問題が発生する可能性があります。同期化期間中、クラスタ化された他の管理対象サーバーが以前に分断されたサーバー・インスタンスとの通信を再確立している間、デプロイ済アプリケーションへのユーザー・リクエストや、そのサーバー・インスタンスでのセカンダリ・セッションの作成は失敗します。ClusterConstraintsEnabledを設定することで、この状況が発生するリスクを減らせます。詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイのすべての構成済クラスタ・メンバーへの一貫性のあるデプロイメントの実施を参照してください。
デプロイメント・プロセス中はクラスタ・メンバーシップを変更しないでください。デプロイメント開始後は、次の操作を行わないでください。
対象のクラスタへの管理対象サーバーの追加または削除
対象のクラスタ内の管理対象サーバーの停止
以前のバージョンのWebLogic Serverでは、クラスタへのデプロイメントに関して次の制限が課せられていました:
部分的なデプロイメントの禁止 - クラスタ内の1つまたは複数の管理対象サーバーが使用できない場合、デプロイメント・プロセスは終了し、デプロイメントを試行する前に、アクセスできない管理対象サーバーを再起動するか、クラスタから削除することを指示するエラー・メッセージが生成されます。
固定サービスはクラスタ内の複数の管理対象サーバーにデプロイできない - あるアプリケーションがクラスタにデプロイされていない場合、そのアプリケーションはクラスタ内の1つの管理対象サーバーにのみデプロイできます。
デフォルトでは、WebLogic Serverは部分的なクラスタへのデプロイメントを許可します。クラスタ内の1つまたは複数の管理対象サーバーが使用できない場合は、次のメッセージが表示されます。
Unable to contact "servername". Deployment is deferred until "servername" becomes available.
アクセスできない管理対象サーバーが使用可能になると、そのサーバー・インスタンスへのデプロイメントが開始されます。デプロイメント・プロセスが完了するまで、管理対象サーバーでは、クラスが見つからない、またはクラスが古いなどのエラーが発生する可能性があります。
ClusterConstraintsEnabledを設定すると、クラスタ内のすべての管理対象サーバーがアクセス可能な場合にのみデプロイメントが実行されるようにできます。ClusterConstraintsEnabledを「true」に設定すると、クラスタ内のすべてのメンバーがアクセス可能で、指定したファイルをデプロイできる場合のみクラスタへのデプロイメントが成功します。詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイのすべての構成済クラスタ・メンバーへの一貫性のあるデプロイメントの実施を参照してください。
固定サービスはクラスタ内の複数の管理対象サーバーにターゲット指定できます。この実践はお薦めしません。固定サービスをクラスタ内の複数の管理対象サーバーにデプロイすると、クラスタのロード・バランシング機能とスケーラビリティが悪影響を受ける可能性があります。固定サービスを複数の管理対象サーバーにターゲット指定すると、次のメッセージがサーバー・ログに出力されます。
Adding server servername of cluster clustername as a target for module modulename. This module also includes server servername that belongs to this cluster as one of its other targets. Having multiple individual servers in a cluster as targets instead of having the entire cluster as the target can result in non-optimal load balancing and scalability. Hence this is not usually recommended.
いくつかのWebLogic Server管理ツールのいずれか、および構成ウィザード、WebLogic Server管理コンソール、Fusion Middleware Control (FMWC)、WebLogic Serverアプリケーション・プログラミング・インタフェース(API)、WebLogic Scripting Tool (WLST)、Java Management Extensions (JMX)などの方法を使用してクラスタを構成できます。
構成ウィザード
新しいドメインやクラスタを作成するには、構成ウィザードを使用することをお薦めします。詳細は、構成ウィザードによるWebLogicドメインの作成の概要を参照してください。クラスタの作成と構成の詳細は、クラスタを参照してください。
WebLogic Server管理コンソールおよびFMWC
WebLogic Server管理コンソールおよびFMWCは、管理サービスにアクセスするためのグラフィカル・ユーザー・インタフェース(GUI)です。これらから、各種のドメイン構成およびモニター機能を実行できます。
WebLogic Serverアプリケーション・プログラミング・インタフェース(API)
WebLogic Serverに付属する構成APIに基づいて、構成属性を変更するプログラムを記述することができます。この方法は、初期のクラスタ実装に対してはお薦めできません。
WebLogic Scripting Tool (WLST)
WebLogic Scripting Tool (WLST)はコマンドライン・スクリプト・インタフェースです。システム管理者およびオペレータは、このインタフェースでWebLogic Serverのインスタンスやドメインの監視と管理を行います。『WebLogic Scripting Toolの理解』を参照してください。
Java Management Extensions (JMX)
JMXは、ネットワーク上のリソースをモニターおよび管理するためのJava EEソリューションです。WebLogic Serverには、JMXを使用してWebLogic Serverリソースを構成、モニター、および管理するための様々なMBeanが用意されています。
