3 WebLogic Server MessagingサービスのWebLogic Replicated Storeの使用
ノート:
Oracle Exalogic Elastic Cloud環境での使用のみを意図したWebLogic Replicated Storeは、Oracle WebLogic Serverバージョン12.2.1.3.0では非推奨になり、将来のリリースで削除されます。DomainMBean.ReplicatedStores
属性、weblogic.management.configuration.ReplicatedStoreMBean
APIなど、WebLogic Replicated Storeの構成および管理を有効にするWebLogic Serverコンポーネントも非推奨になり、削除されます。Oracle WebLogic Server 12.2.1.3.0以降では、JMSメッセージ・ストレージのためにJDBCストアまたはカスタム・ファイル・ストアのいずれかを使用することをお薦めします。
WebLogic Replicated StoreはOracle Enterprise LinuxシステムがホストするOracle Exalogic Elastic Cloud環境でのみサポートされる点に注意してください。WebLogic Replicated Storeは仮想Exalogic環境ではサポートされません。ExalogicシステムでサポートされているOracle Enterprise Linuxバージョンの詳細は、「Oracle Fusion Middlewareサポートされるシステム構成」を参照してください。
レプリケートされたストアの概要
WebLogic Messaging Services (JMS)は、既存のファイルおよびJDBC記憶域オプションのパフォーマンスの高い代替としてレプリケートされたストアを使用できます。レプリケートされたストアは、ローカルExalogicノード・メモリーにデータを格納し、2番目のノードのメモリーにレプリケートして、直線的にスケーラブルなパフォーマンスを実現する一方で単一点障害のない高可用性を提供します。
WebLogic Server Messagingサービスは、共有グローバル・ディレクトリに格納されている構成情報を使用して、WebLogic Replicated Storeを使用してデーモン・クラスタにデータを保存します。メッセージの状態がローカルに格納されますが、ノードのストア・インスタンスを実行して同じデーモン・クラスタをホストする任意のノードからリカバリできます。レプリケートされたストアは、デーモン・クラスタの領域がファイル・ストアのファイルまたはJDBCストア表に対応するファイルまたはJDBCストアに似ています。
ノート:
ファイルおよびJDBCストアの詳細は、『WebLogic永続ストアの管理』のWebLogic永続ストアの使用に関する項を参照してください。
表3-1に、レプリケートされたストアへの接続を作成できるWebLogicサービスを定義します。レプリケートされたストアを使用する各サブシステムには、そのサブシステムを特定するための一意の接続IDが指定されます。
表3-1 レプリケートされたストアのユーザー
サブシステム/サービス | 格納対象 | 詳細 |
---|---|---|
JMSサーバーおよびSAFエージェント |
永続メッセージ、恒久サブスクライバ |
『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージング・モデルの理解に関する項 |
パス・サービス |
メッセージのグループからメッセージング・リソースへのマッピング |
『Oracle WebLogic Server JMSリソースの管理』のWebLogicパス・サービスの使用に関する項 |
ストア・アンド・フォワード(SAF)サービス・エージェント |
SAF送信エージェントからSAF受信エージェントに再転送するメッセージ |
『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項 |
ストアの接続IDの詳細は、「ストア接続のモニター」を参照してください。
レプリケートされたストアの特長
レプリケートされたストアは、冗長ハードウェア、大きい物理メモリー、高い帯域幅のInfiniBandネットワーク、効率的なRemote Direct Memory Access (RDMA)の一意の組合せを提供するOracle Exalogic Elastic Cloudハードウェアおよびソフトウェアを活用します。
レプリケートされたストアのスケーラビリティおよび高可用性
レプリケートされたストアは、非永続メッセージよりも大幅に向上した障害リジリエンスを実現する一方で優れた直線的なスケーラビリティを提供します。
表3-2に、Oracle Exalogic Elastic Cloud環境で使用可能なデータ記憶域タイプによって提供される相対的なパフォーマンスおよび高可用性を説明します。
表3-2 データを保存するためのレプリケートされたストアのパフォーマンスと高可用性レベルの比較
ストア・タイプ | 記憶域 | パフォーマンス | 高可用性レベル |
---|---|---|---|
なし |
非永続 |
最高速 |
単一点障害。 |
レプリケートされたストア |
デーモン・クラスタのレプリケートされたメモリー領域に格納されたデータ。 |
2番目に高速 |
単一点障害なし。 データ損失を発生させる2つのノードまたはプロセスの同時障害 |
ファイル・ストア |
ファイル・システムのファイルに格納されたデータ。 |
3番目に高速 |
Oracle ZFS Storage Applianceを使用するために構成されている場合に単一点障害なし。 |
JDBCストア |
JDBC表に格納されているデータ。 |
最低速 |
Oracle Exadataデータベース・マシンで構成されている場合に単一点障害なし。Oracle Data Guardを使用したマルチサイト障害リカバリを構成するオプション機能。 |
レプリケートされたストアのサーバーおよびサービス移行
レプリケートされたストア構成は、次の項に示されているようにサーバーおよびサービス・レベル移行をサポートしています。
レプリケートされたストアのサーバー全体移行
高可用性の点では、WebLogic Replicated Storeインスタンスは、サーバー全体移行(WSM)機能の一部としてその親サーバーとともに移行できます。この場合、サービス・レベルではなく、サーバー・レベルで自動または手動で移行できます。WSMにより、失敗したWebLogic Server Replicated Storeインスタンスが自動的に再起動または移行されます。JMSサーバー・インスタンスまたはレプリケートされたストア・インスタンスが失敗した場合、レプリケートされたストア・インスタンスは、デーモン・クラスタの実行中のRSデーモンをホストするマシンで再起動して特定の領域をリカバリできます。詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。
レプリケートされたストアのサービス・レベル移行
WebLogic Replicated Storeインスタンスは、ストアに依存してデータを保持するJMSサーバー、SAFエージェント、パス・サービスなどのJMS関連サービスの自動サービス移行(ASM)の一部として移行することもできます。サービス・レベルの移行は、JMS関連サービスをグループ化した移行可能なターゲットに制御されます。移行可能なターゲットは、クラスタ内の1つの物理サーバーのみでホストされます。ホストされているサービスは、ヘルス・モニター・サブシステムを使用することで、現在異常のあるホスト・サーバーから正常なアクティブ・サーバーに自動的に移行されます。移行可能なターゲットによってホストされるJMSサービスは、サーバー障害への対処として、または定期的なサーバー・メンテナンスの一環として手動でも移行できます。移行可能ターゲットを移行すると、そのターゲットによってホストされているすべての固定サービスも移行されます。ASMにより、失敗したWebLogic Server Replicated Storeインスタンスが自動的に再起動または移行されます。JMSサーバー・インスタンスまたはレプリケートされたストア・インスタンスが失敗した場合、レプリケートされたストア・インスタンスは、デーモン・クラスタの実行中のRSデーモンをホストするマシンで再起動して特定の領域をリカバリできます。サービス・レベルの移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサービスの移行に関する項を参照してください。
ノート:
パス・サービスの場合は、専用のレプリケートされたストアと移行可能ターゲットを使用するのがベスト・プラクティスです。
レプリケートされたストアの管理
次の項では、レプリケートされたストアを管理する方法について説明します。
レプリケートされたストアを使用するクイック・スタート・ガイド
次の手順を使用して、レプリケートされたストアを起動および停止します。
レプリケートされたストアの停止
次のステップを使用して、レプリケートされたストアを停止します。
- 関連付けられたWebLogicクラスタを停止します。ストアを使用して一時的に停止するには、サーバー・インスタンス、動的クラスタまたは移行可能なターゲットからターゲット指定を解除して、WebLogic Serverを停止せずにデーモン・クラスタから切断できます。
- オプションで、
stopRSDaemon.sh
スクリプトを実行して、デーモン・クラスタの各デーモンを停止します。デーモンを停止しないように選択すると、再起動されたストアによってストア・データを後でリカバリに使用できます。「stopRSDaemon.shスクリプトを使用したデーモンの停止」を参照してください
グローバル・ディレクトリの管理
グローバル・ディレクトリは、デーモン・クラスタのホストExalogicマシンのZFS Storage Applianceのカスタム・チューニングされたNFSマウントを必要とする共有ディレクトリです。WebLogic Replicated Storeインスタンスおよび管理ユーティリティは、関連付けられたデーモン・クラスタにアクセスするためにグローバル・ディレクトリを参照します。
表3-3に、グローバル・ディレクトリの構造を説明します。
表3-3 グローバル・ディレクトリのコンポーネント
ファイル名 | 説明 |
---|---|
|
管理者が作成した構成ファイル。同じデーモン・クラスタ内のすべてのデーモン、およびこれらのデーモンのすべてのクライアントは、同じ
|
|
生成されるデーモン・ログ・ファイル。「デーモン情報の記録」を参照してください |
|
内部ランタイム・ファイル。 |
|
領域を保護するためにデーモンが使用するロック・ファイル。通常領域が開いている場合のみ存在するロック・ファイル。 |
|
領域を保護するためにWebLogic Replicated Store構成が使用するロック・ファイル。このロック・ファイルは領域を閉じた後も存続します。WebLogic Replicated Store構成を削除した後にのみ削除できます。 |
グローバル・ディレクトリの構成およびチューニング要件
次の項は、関連付けられたデーモン・クラスタのグローバル・ディレクトリを作成する管理者の構成およびチューニング要件を示しています。
-
startRSDaemon.sh
スクリプトを使用して、グローバル・ディレクトリを作成します。「デーモン・クラスタの起動および停止」を参照してください -
デーモン・クラスタとグローバル・ディレクトリは1対1に対応しています。異なるデーモン・クラスタは、同じグローバル・ディレクトリを共有できません。
-
グローバル・ディレクトリは、ExalogicマシンのZFS Storage Applianceにある必要があるチューニングされたNFSマウントで、関連付けられたデーモン・クラスタのコンポーネントをホストするすべてのExalogicノードで集中的にアクセス可能である必要があります。
-
安定性を確保するため、NFSマウントには次のチューニングが必要です。
-
各Exalogicノードに
/etc/fstab "actimeo=0"
を設定します。これはファイル操作パフォーマンスに大きな影響を与えるため、レプリケートされたストアに対するグローバル・ディレクトリのNFSマウントの使用を制限することをお薦めします。 -
すべてのNFSクライアントおよびサーバーに対して常にNFS v4を使用します。Oracle Exalogic Elastic Cloud Machine所有者ガイドのExalogic上のNFS Version 4 (NFSv4)の構成に関する項を参照してください。
-
ベスト・プラクティスは、グローバル・ディレクトリをホストするZFSA NFSボリュームのファイル・アクティビティを最小化することです。たとえば、デーモン冗長トレースが必要な場合、グローバル・ディレクトリをホストするZFSA NFSボリューム以外のボリュームを使用します。
「デーモン・クラスタの起動および停止」
の-logdirパラメータを参照してください
-
WebLogic Replicated Storeの管理
WebLogic Server Replicated StoreインスタンスはWebLogic Server、クラスタまたは移行可能なターゲットで実行され、データをデーモン・クラスタの領域に保存するクライアントとして機能します。特定のインスタンスは、同じノードで実行されて同じグローバル・ディレクトリを共有するデーモンにのみアタッチできます。アタッチされた後、インスタンスは、インスタンスが所有して一意に名前が付けられているデーモン・クラスタの一連の領域を作成またはオープンするか、あるいはその両方を実行します。グローバル・ディレクトリのロック・ファイルは、インスタンスが領域を共有しないことを保証します。
WebLogic Replicated Storeを作成および構成する方法
WebLogic Replicated Storeを作成および構成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのレプリケートされたストアの作成に関する項を参照してください。
レプリケートされたストアのモニター
既存のそれぞれのレプリケートされたストアおよび開かれている各ストア接続の統計情報をモニターできます。
ストアのモニター
それぞれのレプリケートされたストアは、実行時にはPersistentStoreRuntimeMBeanインスタンスによって表されます。次のオプションが用意されています。
表3-4 レプリケートされたストアの実行時オプション
オプション | 機能 |
---|---|
CreateCount |
このストアに対して発行された作成リクエストの数 |
ReadCount |
このストアに対して発行された読込みリクエストの数 |
UpdateCount |
このストアによって発行された更新リクエストの数。 |
DeleteCount |
このストアによって発行された削除リクエストの数。 |
ObjectCount |
このストアに含まれるオブジェクトの数 |
接続 |
このストアのアクティブな接続の数 |
PhysicalWriteCount |
ストアが恒久ストレージにデータをフラッシュする回数。 |
ストア接続のモニター
開かれているレプリケートされたストアの接続ごとに、次のオプションを提供するPersistentStoreConnectionRuntimemMBeanが登録されます。
表3-5 レプリケートされたストア接続の実行時オプション
オプション | 機能 |
---|---|
CreateCount |
この接続に対して発行された作成リクエストの数 |
ReadCount |
この接続に対して発行された読取りリクエストの数 |
UpdateCount |
この接続によって発行された更新リクエストの数 |
DeleteCount |
この接続によって発行された削除リクエストの数 |
ObjectCount |
この接続に含まれるオブジェクトの数 |
表3-6に、レプリケートされたストアへの接続を作成できるWebLogicサービスおよびサブシステムのランタイム接頭辞名の大部分を示します。
表3-6 レプリケートされたストアのランタイム接頭辞名
サブシステム/サービス | ランタイム接頭辞名 |
---|---|
JMSサービス |
JMSサーバー
JMS恒久サブスクライバ
|
パス・サービス |
|
SAFサービス |
SAFエージェント
SAF恒久サブスクライバ
|
WebLogic Replicated Storesのベスト・プラクティスおよび考慮事項
次の項では、WebLogic Replicated Storeインスタンスを構成する場合のベスト・プラクティスと他の考慮事項について説明します。
-
インスタンスと同じノードで使用できるデーモンがない場合、レプリケートされたストアの起動に失敗し、エラーが記録されます。失敗したレプリケートされたストアを自動的に再起動または移行する構成オプションは、「レプリケートされたストアのサーバーおよびサービス移行」を参照してください。
-
単一ノードに複数のExalogicインスタンスがある場合、各ノードの単一のデーモンに接続する必要があります。これは、各デーモンが異なるノードで実行されているデーモンに状態をレプリケートすることを保証して、高可用性を促進します。
-
本番以外の環境で単一ノードに複数のデーモンを構成する場合、
Local Index
属性を使用してアタッチメントを確認します。Oracle WebLogic Server MBeanリファレンスのLocalIndexに関する項を参照してください。 -
RegionSize
パラメータを使用して領域のサイズを構成できます。Oracle WebLogic Server管理者コンソール・オンライン・ヘルプのレプリケートされたストア: 構成に関する項を参照してください。作成した後に領域のサイズを変更できません。RegionSize
を変更すると、変更が実装された後にインスタンスが作成する可能性がある新しい領域に影響を与えます。 -
領域サイズは、大きいメッセージを送信および受信する場合に処理される最大の単一メッセージ、メッセージのバッチまたはSAFウィンドウ・サイズより大きくする必要があります。また、『Oracle WebLogic Serverのパフォーマンスのチューニング』のネットワーク・プロトコルの最大メッセージ・サイズの設定に関する項の説明に従って、
MaxMessageSize
の設定を考慮する必要がある場合があります。 -
同じデーモン・メモリーを共有している可能性がある各ストア・インスタンスに対していくつかの領域を作成できる領域サイズを選択します。例: ストア・インスタンスが最大512MBのデータをホストする場合、50MBより小さい領域サイズを選択します。
-
レプリケートされたストア・インスタンスは、領域内で使用されるスペースを再利用します。領域の指定されたメモリーの場所のデータが不要になった場合、メモリーの場所を新しいデータの格納に使用できます。既存の領域がいっぱいで新しいデータに対応できない場合のみ、新しい領域が作成されます(たとえば、未処理のJMSメッセージのバックログの増加など)。
-
次のいずれかが適用されるまで、領域は削除されず、バックアップ・マシンのメモリーは解放されません。
-
デーモン・クラスタ全体が停止するか、
-
領域を参照するWebLogic Replicated Storeインスタンスが停止し、領域が管理者によって削除されています。「管理ユーティリティを使用したデーモン・クラスタの管理」を参照してください
-
デーモン・クラスタの管理
次の項では、デーモン・クラスタの管理方法について説明します。
デーモンの構成
同じデーモン・クラスタのすべてのデーモンとこれらのデーモンのすべてのクライアントは、グローバル・ディレクトリのルートにある同じrs_daemons.cfg
ファイルを共有します。
rs_daemons.cfgファイルの作成
rs_daemons.cfg
は、デーモン・クラスタの各デーモンの単一エントリを含む管理者によって作成された簡単なテキスト・ファイルです。オプションの空白行と"#
"で接頭辞が付けられたオプションのコメントが含まれる場合があります。各値が1つ以上の空白で区切られている次の形式を使用して、各行エントリにアドレス、ポート、共有メモリー・キーおよびオプションのメモリー制限を指定します。
address port starting-shared-memory-key shared-memory-limit
-
アドレスとポート - 各エントリには、アドレスとポートの一意の組合せを指定する必要があります。2つのエントリに同じアドレスと同じポートを使用することはできません。アドレスには名前または数値のIPを指定できますが、デーモンのノードのInfiniBandアドレスに対応する必要があります。ポートは、1024から49151の間の範囲である必要があります。
ノート:
追加のOSチューニングを使用して、49151より大きいポート番号を構成できる場合があります。
-
共有メモリー・キー - 各領域のプライマリまたはセカンダリ共有メモリーの一意の場所を表すために使用される動的に生成されたキー。同じノードで実行されるデーモンは、異なる共有メモリー・キーを使用する必要があります。共有メモリー・キーが競合する場合、デーモンは起動しません。「デーモンの共有メモリー・キー」を参照してください。
-
共有メモリー制限 - 領域データを格納するためにデーモンが使用する共有メモリー。デーモンの共有メモリー制限は、メガバイトを"M"または"MB"、ギガバイトを"G"または"GB"で修飾した整数として指定されます。ノードが失敗した後にデーモンが予測された数のストア・インスタンスのプライマリおよびセカンダリ領域に簡単に対応できるメモリー制限を選択します。たとえば、3ノード・クラスタの場合、各ノードは、1つのノードが失敗した場合にメモリー使用量の50パーセントの上昇に対応できる必要があります。「レプリケートされたストアのメモリー使用率の管理」を参照してください。
例3-1は、rs_daemon.cfg
ファイルのコンテンツの例を示しています。
例3-1 rs_daemon.cfgファイルのデーモン構成の例
#ipaddress portno shmkey memlmt 123.456.78.9 4545 4545 2G 123.456.78.6 4546 4545 2G
デーモンのnumberは、rs_daemons.cfg
ファイルの相対的なファイルの場所によって自動的に決定されます(コメントと空白行は除外されます)。デーモン番号はゼロから開始されるため、ファイルの最初のエントリはデーモン番号0(ゼロ)と対応し、行を追加するたびにデーモン番号が1つずつ増えます。この数値を使用してロギングおよびランタイム管理の目的でデーモンを識別します。
デーモン・クラスタの起動および停止
デーモン・クラスタを管理するため、startRSDaemon.sh
とstopRSDaemon.sh
スクリプトが用意されています。これらのスクリプトは、Weblogic ServerインストールのWL_HOME/server/bin
ディレクトリにあります。
startRSDaemon.shスクリプトを使用したデーモンの起動
指定されたグローバル・ディレクトリにあるrs_daemons.cfg
ファイルの情報を使用してデーモンを起動し、関連付けられたロギング構成を設定するには、startRSDaemon.sh
スクリプトを使用します。
表3-7 startRSDaemon.shスクリプトの構成パラメータ
パラメータ | 説明 |
---|---|
|
pathは、WebLogic Server
このディレクトリは、特別にチューニングされたNFSマウントにあることが必要です。グローバル・ディレクトリの構成とチューニングの要件に関する項を参照してください。レプリケートされたストアのグローバル・ディレクトリの場所を指定するときは、絶対パスを指定することをお薦めします。 |
|
|
|
デフォルト値は2です。 |
|
相対パスとして指定される場合、GlobalDir GlobalDir デフォルト値は「.」です。 |
|
デフォルト値は500です。 |
|
ログ・ファイルの最大数。 デフォルト値は10です。 |
|
このスクリプトのヘルプ。 |
stopRSDaemon.shスクリプトを使用したデーモンの停止
指定されたグローバル・ディレクトリにあるrs_daemons.cfg
ファイルの情報を使用してデーモンを停止するには、stopRSDaemon.sh
スクリプトを使用します。
表3-8 stopRSDaemon.shスクリプトの構成パラメータ
パラメータ | 説明 |
---|---|
|
pathは、WebLogic Server
このディレクトリは、特別にチューニングされたNFSマウントにあることが必要です。グローバル・ディレクトリの構成とチューニングの要件に関する項を参照してください。レプリケートされたストアのグローバル・ディレクトリの場所を指定するときは、絶対パスを指定することをお薦めします。 |
|
デフォルト値は0です。 |
|
説明:
デフォルト値は |
|
このスクリプトのヘルプ。 |
デーモン情報の記録
デーモンは、最初のブートストラップ情報をWebLogic Server管理コンソール(stdout
)に報告し、RSグローバル・ディレクトリのルートに1つ以上の一意のログ/トレース・ファイルを生成します。ログ・ファイルには、WebLogic Server管理コンソールに報告された情報およびランタイム・ログ・メッセージが含まれます。次のパターンを使用して、デーモンのログ・ファイルに名前が付けられます。
rs_daemon_dnum_xxx.xxx.xxx.xxx_ppppp_nnn.log
説明:
-
dnumは、
rs_daemons.cfg
ファイルの3桁のゼロが入力された値のデーモン番号を指定します。「rs_daemons.cfgファイルの作成」を参照してください -
xxx.xxx.xxx.xxxは、IPアドレスを指定します。
-
pppppは、ポート番号を指定します。
-
nnnは、ログ・ファイル番号を指定します。
ログ構成(ログ・ファイルの場所、ファイルの最大サイズ、ログ・ファイルの最大数)はstartRSDaemon.sh
で制御されます。startRSDaemon.shスクリプトを使用したデーモンの起動に関する項を参照してください。ログ・ファイルは、現在のログ・ファイルがlogfilesize
で指定された特定のサイズに達したときに古いメッセージが別のファイルに移動するようローテーションされます。最新のログ・ファイルは数値000を使用し、最も古い可能性があるログ・ファイルはlogfilemax - 1
の値を使用します。ログ・ファイルのnnnがlogfilemax
と同じである場合、削除されます。
管理ユーティリティを使用したデーモン・クラスタの管理
管理ユーティリティにより、管理者は実行しているデーモンと関連付けられた領域を管理するコマンドを含むデーモン・クラスタのトラブルシューティングを行うことができます。「管理ユーティリティを示す例」に示されているように、このユーティリティをJavaコマンドラインから実行できます
ノート:
WLSTを使用したレプリケートされたストア・コマンドはサポートされていません。
デーモン・クラスタを管理するには、rsattach
コマンドを使用して、まずデーモン・クラスタのローカル・デーモンにアタッチする必要があります。このユーティリティの最も一般的なユース・ケースは、デーモン・クラスタ全体のメモリー使用率の監視、使用されていないリージョンの削除と、デーモンの停止です。終了したら、rsdetach
コマンドを使用してデーモン・クラスタから切断します。
表3-9に、使用可能なレプリケートされたストアの管理コマンドを定義します。
表3-9 レプリケートされたストアの管理オプション
Javaコマンド | パラメータ | 機能 |
---|---|---|
|
パラメータが指定されない場合、すべての使用可能なレプリケートされたストア・コマンド、使用方法および例を表示します。 説明: parameterはコマンド名です。コマンド名が指定されると、名前が付けられたコマンドに固有の追加のヘルプが表示されます。 このコマンドを使用するために管理ユーティリティをデーモンにアタッチする必要はありません。 |
|
|
|
管理ユーティリティをデーモンにアタッチします。成功した場合にプロンプトが 説明:
|
|
説明:
|
|
|
デーモン・クラスタから切断します。成功した場合にプロンプトが |
|
|
|
デーモンを監視します。 説明:
|
[-sort name|time|size] |
リストまたは表出力をソートします。 説明:
|
|
|
出力の形式。 説明:
|
|
|
|
デーモンを停止します。管理ユーティリティは、停止デーモンから自動的にデタッチします。 説明:
|
|
説明:
|
|
|
|
デーモン・クラスタの領域をリストします。 説明:
|
|
リストまたは表出力をソートします。 説明:
|
|
|
出力の形式。 説明:
|
|
|
|
|
|
|
領域がレプリケートされたストアで現在開いていないかぎり、プライマリおよびセカンダリ・コピーを含む指定された領域のすべてのコピーを削除します。 必要な場合、 説明:
|
|
管理セッションを終了します。 |
管理ユーティリティを示す例
開始する前に、$WL_HOME/server/bin/setWLEnv.sh
などのスクリプトを実行して、シェル環境を設定します。
Javaコマンド行から管理ユーティリティを開くには、java weblogic.store.Adminを入力します。次に例を示します。
> java weblogic.store.Admin
> storeadmin->
レプリケートされたストアのrshelpのアクセス
rshelp
と入力すると、使用できるレプリケートされたストア管理コマンドの詳細な説明と、典型的なコマンド使用例が表示されます。たとえば、次の包括的なヘルプがデーモンからユーティリティを解放するために使用されるrsdetach
コマンドに対して用意されています。
storeadmin->rshelp rsdetach Command: rsdetach Summary: detach from a RS Daemon Cluster Usage: rsdetach Description: Use "rsdetach" to detach from a RS Daemon Cluster. When an rsdetach succeeds, the command prompt will change so that it no longer includes '[RS]'. . . .
デーモンへのアタッチ
この例は、管理ユーティリティをデーモンにアタッチします。
storeadmin:-> rsattach INFO: Attached to Daemon 3 with global dir [.]. storeadmin:[RS]-> . . .
lsdコマンドからの表出力の例
次の項では、lsd
コマンドからの表出力の例を示します。
Current Time: 2014-02-18 11:50:29 AM EST Idx IP Port Up Rgns Rgns Rgns Rgns Mem Mem Address Time Closed Open Open Total Used Used HHHHH:MM:SS Prima Rplca MB % --- --------------- ------ ----------- ------ ------ ------ ------ ------- ----- 000 192.168.0.127 8000 0:27:28 0 0 2 2 257 3.14 001 192.168.0.128 8000 0:27:27 0 2 0 2 257 3.14
lsdコマンドからのリスト出力の例
次の項では、lsd
コマンドからの表出力の例を示します。
Index : 001 Status : UP Reachable over IB : TRUE IP Address : 192.168.0.128 Port : 8000 Shared Memory Key (hex) : 0x1f40 Shared Memory Key (decimal) : 8000 Startup Time (YYYY-MM-DD HH:MM:ss) : 2014-02-18 11:23:02 AM EST Current Time (YYYY-MM-DD HH:MM:ss) : 2014-02-18 11:55:40 AM EST Up Time (HHHH:MM:ss) : 00019:32:37 Startup Time (micros since epoch) : 1392740582473595 Current Time (micros since epoch) : 1392742540074899 Up Time (micros) : 1957601304 Total Configured Memory (MB) : 8192 Current Memory Usage (MB) : 257 Number of Regions Closed : 0 Number of Regions Opened as Primary : 2 Number of Regions Opened as Replica : 0 Total Number of Regions Managed : 2 Number of Resilvers in Progress : 0 Number of Daemons in Cluster : 2
デーモン・クラスタの理解
デーモン・クラスタは、複数のExalogicノードにまたがるレプリケートされたメモリー記憶域です。この記憶域は一意に名前が付けられた一連の領域として編成され、1つ以上のデーモンで管理されます。
WebLogic Replicated Storeは、データをデーモン・クラスタに保存し、デーモン・クラスタの領域がファイル・ストアのファイルまたはJDBCストア表に対応しているファイルまたはJDBCストアと似ています。WebLogic Replicated Storeをデーモンにアタッチすると、後続の通信は共有メモリーとInfiniBand RDMAを使用します。
領域の一意性
WebLogic Server Replicated Storeインスタンスは、デーモン・クラスタの1つ以上の領域を開くことができます。ファイル・ストアのファイルとJDBCストア表のように、領域は一度に1つのクライアントによってのみ安全にアクセスできます。領域の整合性を確保するため、指定された時間に複数のクライアントが領域にアクセスすることをできるかぎり防ぐためにロック・ファイルおよび構成チェックを使用します。
ノート:
複数のWebLogicドメインを構成して同じデーモン・クラスタを使用する場合、WebLogicドメインが一意であることを確認する必要があります。そうでない場合、ドメイン間で同じ名前が付けられたWebLogic Replicates Storesは、同じ領域を開こうとしてクラッシュします。その結果、WebLogic Serverおよびデーモン・ログにロック・エラーが発生します。
デーモンの高可用性
デーモン・クラスタは、既存の領域から領域の新しい同期コピーを作成するプロセスである復元を使用して、領域に個別のデーモンの各領域の2つのコピーがあることを保証します。
WebLogic Replicated Storeが新しい領域を開くと、ローカル・デーモンは領域のプライマリ・コピーの保持を管理し、次に使用可能なデーモンは領域のセカンダリ・コピーを保持します。次に使用可能なデーモンは次によって決定されます。
-
稼働している
rs_daemons.cfg
ファイルのプライマリの最近定義された次のデーモンを検索するか、 -
プライマリがファイルの最後のデーモンの場合、
rs_daemons.cfg
ファイルの先頭から開始し、次に定義されたデーモンを検索します。
レプリケートされたストアがストアのローカル・デーモンの事前に定義されたコピーがない既存の領域を開き、クラスタのどこかにコピーがすでにある場合、オープンに成功し、既存のコピーのいずれかが領域のオープンの一部としてローカル・デーモンに透過的に復元されます。また、領域のセカンダリは、次に使用可能なデーモンに復元されます。セカンダリの復元により、領域をデーモン・クラスタ全体で均一に分散できます。
ノート:
領域は一度に1つのクライアントによってのみ開くことができます。失敗後に領域を開いてリカバリするために、WebLogic Replicated Storesを再起動するか、新しいノードに移行するかあるいはその両方を実行することが予期されています。
デーモンが失敗した場合の処理
デーモンが失敗した場合、アタッチされたクライアント(たとえば、Weblogic Replicated Store)も失敗します。クライアントは、失敗したデーモンに定期的に再アタッチするか、同じデーモン・クラスタの異なるデーモンにアタッチして、特定の領域データをリカバリできます。定期的な再試行の自動化の詳細は、「レプリケートされたストアのサーバーおよびサービス移行」を参照してください
クラスタの他のデーモンは失敗を検出し、失敗したデーモンのプライマリおよびセカンダリ領域コピーがそれぞれ別のデーモンに自動的に復元されます(十分なメモリーがあるデーモンが存在する場合)。WebLogic Replicated Storeが再起動せず、クラスタの任意の場所に再アタッチしなくても、復元が発生します。
ノート:
復元が進行中の場合およびデーモン・クラスタが単一のデーモンになっている場合、またはデーモン・クラスタに各領域の2つのコピーをホストする十分なメモリーがない場合、領域は単一点障害に対して脆弱になります。
その他の考慮事項
-
管理者は準備されたデーモンを再起動でき、それはデーモン・クラスタに再度参加します。
-
デーモンは、管理者により管理ユーティリティ(管理ユーティリティを使用したデーモン・クラスタの管理に関する項を参照)またはデーモン・シャットダウン・スクリプト(レプリケートされたストアの停止に関する項を参照)を使用して安全に停止できます。デフォルトでは、停止によってデーモンの領域(プライマリとセカンダリ)がすべて復元されて、デーモンの停止前に復元が完了するまでブロックされます。
-
領域がプライマリを新しいセカンダリに復元しており、そのセカンダリのホスト・デーモンが強制停止されている場合、復元は、透過的かつ非同期的に、別のデーモン上の新しいセカンダリで再度開始されます。クラスタ内で少なくとも2つのデーモンがまだ実行されていることと、領域のコピーをホストするのに十分な空きメモリーがある別のデーモンが存在することが必要となります。
デーモンの共有メモリー・キー
デーモンは、領域データを格納する共有メモリーを保持します。新しい各領域(プライマリまたはセカンダリ)には、動的に生成された秘密共有メモリー・キーを使用して内部的に表される固有の一意な場所があります。このメモリーを固定して、O/Sがディスクに情報をページングすることを防ぎます。次の場合のみ、この共有メモリーが解放されます。
-
デーモンがクラッシュして強制停止しているか、管理者によって停止されています。
-
領域が管理者によって削除されています。
管理者は、rs_daemons.cfg
ファイルに各デーモンの候補の公開共有メモリー・キーを構成します(デーモンごとに1つの公開キー共有メモリーの場所)。たとえば、デーモンが5つの領域プライマリと4つの領域セカンダリをホストする場合、合計9つの動的に生成された秘密共有メモリー・キーと1つの公開キーを予約します。
開発環境のローカル索引の使用
ローカル索引は、複数のデーモンを構成して現在のノードで実行する場合に起動する特定のローカル・デーモンを決定します。次の式は選択するデーモンを決定します。
((idx) modulo (number-of-local-daemons))
idxはrs_daemons.cfg
ファイルのエントリです。デフォルト(idx=0)では、これは現在のノードと同じネットワークを使用してrs_daemons.cfg
ファイルの最初のエントリに解決されます。
ノート:
本番環境でローカル索引を使用することはお薦めしません。本番環境の高可用性を確保するには、複数のノードにデーモン・クラスタを構成し、各ノードに1つのデーモンを割り当てます。
レプリケートされたストアのメモリー使用率の管理
デーモン・クラスタの各デーモンには、過剰なメモリー使用量を防ぐために関連付けられたrs_daemons.cfg
ファイルに定義された共有メモリー制限があります。メモリー不足イベントを管理してレプリケートされたストアの致命的な障害を防ぐために、定義済およびチューニング可能なシステム・プロパティが用意されています。
デーモンの共有メモリー制限の設定の詳細は、「rs_daemons.cfgファイルの作成」を参照してください
レプリケートされたストアのメモリー使用量
次の項では、デーモンのメモリー使用率を変更するアクションについて説明します。
-
次の場合のみ、デーモンのメモリー使用量が減ります。
-
アタッチされているレプリケートされたストアが別のデーモンに移行されています。
-
レプリケートされたストアの領域が管理者によって削除されています。
-
領域のホストされたセカンダリ・コピーが別のデーモンに移動されています。
-
-
アタッチされているレプリケートされたストア・インスタンスの現在のデータ・セットが新しい領域を作成するために必要なポイントに達している場合にのみ、デーモンのメモリー使用量が増えます。
-
レプリケートされたストア・インスタンスがメッセージ・レコードを削除すると、領域のメモリーが変更されず、後続の新しいレコードを格納するために割り当てられたままになります。
ノート:
他のすべてのタイプの永続性のように、レプリケートされたストアの永続メッセージがWebLogic Server JVMメモリーにキャッシュされます。JMSサーバー・ページングをチューニングしてこのメモリー使用量を減らすことができますが、重大なパフォーマンスの影響がある可能性があります。
メモリー使用率の監視
次の項では、管理者がデーモン共有メモリー使用率を監視できる方法について説明します。
-
管理ユーティリティは、領域およびデーモンのメモリー使用量を報告するコマンドを提供します。「管理ユーティリティを使用したデーモン・クラスタの管理」を参照してください
-
UNIX
ipcs
コマンドは、共有メモリー・キーの監視情報を提供します。 -
トレース・レベルが3以上に設定されている場合のデーモン・ロギング。メモリー使用量が
shared-memory-limit
の10パーセント上または下に変更されると、デーモンはメモリー使用量を記録します。すべてのメモリー使用率ロギング情報がWARNING
ロギング・レベルで書き込まれる80パーセントの警告しきい値にメモリー使用率が増えるまで、メモリー使用率メッセージはINFO
ロギング・レベルで書き込まれます。「デーモンの構成」を参照してください -
WebLogic Serverは、デーモンの共有メモリー制限を記録します。
-
shared-memory-limit
のSpaceLoggingStartPercent
で定義されているように、メモリー使用量のINFO
メッセージを記録します。 -
shared-memory-limit
のSpaceOverloadYellowPercent
で定義されているように、メモリー使用量のWARNING
メッセージを記録します。 -
shared-memory-limit
のSpaceOverloadRedPercent
で定義されているように、メモリー使用量のERRORメッセージを記録します。
WebLogic Serverのメモリー使用の動作のチューニングについては、表3-10を参照してください。
-
-
JMSサーバーおよび宛先のバイトおよびメッセージの現在および中断している数を監視します。
メモリー使用率の制御
次の項では、管理者がデーモン共有メモリー使用率を監視できる方法について説明します。
-
shared-memory-limit
。デーモンは、shared-memory-limit
がオペレーティング・システムのshmlimitおよびmemlock制限以下であることを確認します。「rs_daemons.cfgファイルの作成」を参照してください -
WebLogic Serverは、レプリケートされたストアおよび関連付けられたデーモンのメモリー使用量を管理してオーバーロード状況を防ぐためにチューニング可能なシステム・プロパティを提供します。これらにより、システムがレプリケートされたストアのメモリー使用量を記録する方法、レプリケートされたストアを使用する宛先に格納できるメッセージの最大サイズおよびオーバーロード保護アクションをトリガーするしきい値が制御されます。表3-10に、WebLogicサーバー・インスタンスのすべてのレプリケートされたストアまたは
store-name
という名前の特定のストアのプロパティを示します。表3-10 メモリー不足管理のチューニング可能なシステム・プロパティ
プロパティ タイプ デフォルト値 範囲 説明 weblogic.store.replicated.MaximumMessageSizePercent
weblogic.store.replicated.
store-name
.MaximumMessageSizePercent
int
レプリケートされたストアの領域サイズの1パーセント
1から100
ストア領域サイズのパーセンテージとして指定されるレプリケートされたストアによって支援されるJMS宛先の最大メッセージ・サイズ。このサイズを超える新しいメッセージは、
ResourceAllocationException
を取得します。すべての現在書き込まれているレプリケートされたストアのメッセージの合計サイズは領域サイズ未満にする必要があります。そうしないと失敗する可能性があります。「JMSサーバーまたは宛先の最大メッセージ・サイズ」の関連する設定を参照してください。
weblogic.store.replicated.SpaceLoggingStartPercent
weblogic.store.replicated.
store-name
.SpaceLoggingStartPercent
int
70
1から100
レプリケートされたストアがデーモン共有メモリー使用量の記録を開始する場合のデーモン共有メモリー制限のパーセンテージ。
weblogic.store.replicated.SpaceLoggingDeltaPercent
weblogic.store.replicated.
store-name
.SpaceLoggingDeltaPercent
int
10
1から100
レプリケートされたストアのデーモン・スペース使用量ロギング・デルタ。
例: デフォルトは10パーセントです。これはストアがスペース使用量の変更の10パーセントごとに記録することを意味します。
weblogic.store.replicated.SpaceOverloadYellowPercent
weblogic.store.replicated.
store-name
.SpaceOverloadYellowPercent
int
80
1から100
デーモンのすべてのレプリケートされたストアによって使用されるメモリーがデーモン共有メモリー制限のこのパーセンテージを超え、ストアに格納されているデータが特定のストアに割り当てられた合計領域メモリーのこのパーセンテージも超える場合、JMSサーバーは
ResourceAllocationException
とともに新しいメッセージを拒否します。weblogic.store.replicated.SpaceOverloadRedPercent
weblogic.store.replicated.
store-name
.SpaceOverloadRedPercent
int
90
1から100
デーモンのすべてのレプリケートされたストアによって使用されるメモリーがデーモン共有メモリー制限のこのパーセンテージを超える場合、新しいストアまたは移行されたストアのオープンに失敗し、
ERROR
メッセージが記録されます。 -
宛先およびJMSサーバーのメッセージ割当属性
Bytes Maximum
、Messages Maximum
およびMaximum Message Size
をチューニングします。これらの割当制限を超えるメッセージにより、送信アプリケーションがResourceAllocationException
を受け取ります。
使用可能なメモリーを超えた場合のレプリケートされたストアの動作
新しい領域を割り当てるためにすでに実行されているWebLogic Replicated Storeの十分なメモリーがないまれな状況の場合、ストアが失敗して閉じ、ERROR
メッセージが記録されます。ストア・インスタンスの失敗と同様に、使用可能なメモリーを超えたために起動またはクローズに失敗したストアは、自動サービス移行またはサーバー全体移行を使用して自動的に再起動または移行できます。「レプリケートされたストアのサーバーおよびサービス移行」を参照してください
レプリケートされたストアの相互運用の考慮事項
この項では、レプリケートされたストアの相互運用について説明します。
-
レプリケートされたストアの今後のリリースは、このリリースと互換性がない場合があります。その場合、レプリケートされたストアのオープンに失敗し、バージョンの互換性がないメッセージが記録され、関連付けられた領域が変更されないままになります。
-
WebLogic Replicated Storeまたはデーモン・クラスタは、サポートされていないプラットフォームで起動せず、エラー・メッセージが記録されます。サポートされているプラットフォームの詳細は、『ライセンス情報』のExalogic Elastic Cloudソフトウェアに関する項を参照してください。
レプリケートされたストアのセキュリティの考慮事項
この項では、レプリケートされたストアを使用する場合のセキュリティの考慮事項について説明します。
管理者のセキュリティの考慮事項
次の項では、管理者がレプリケートされたストアを保護するために実装する必要があるセキュリティ要件について説明します。
-
すべてのデーモンを同じUIDを使用して開始し、グローバル・ディレクトリに書込み可能である必要があります。グローバル・ディレクトリの読取り/書込み権限があり、他のデーモンと同じグローバル・ディレクトリを指定している場合を除き、デーモンはクラスタの他のデーモンと通信できません。
-
管理ユーティリティはデーモンと同じUIDを使用する必要があります。グローバル・ディレクトリの読取り/書込み権限があり、このディレクトリがデーモンのグローバル・ディレクトリと同じである場合を除き、管理ユーティリティをアタッチできません。
-
WebLogic Serverは、共有メモリーにアクセスするためにアタッチされているデーモンと同じGIDを使用する必要があります。
-
管理ユーティリティはアタッチされているデーモンと同じUIDを使用する必要があります。
-
デーモンを通常の権限を持つユーザーとして実行することをお薦めしますが、デーモンが固有のプロセス優先度を上げてランタイムUIDおよびグループをドメインを開始するユーザーのUIDおよびグループに変更する権限を持つように、デーモン実行可能バイナリに引き続きUNIX
root
、set uid
およびset group
権限を割り当てる必要があります。「デーモン・クラスタの起動および停止」を参照してくださいノート:
実行可能なデーモンに十分な権限がない場合、デーモン起動スクリプトは、権限をデーモンに割り当てるために必要な手順を出力します。
レプリケートされたストアの一般的なセキュリティの考慮事項
次の項では、レプリケートされたストア・コンポーネント間で安全にアクセスする方法について説明します。
-
グローバル・ディレクトリ・アクセス権限 - グローバル・ディレクトリは、クライアントおよびデーモンを起動するO/Sユーザーに対して読取り/書込みアクセス可能である必要があります。ユーザーにこのディレクトリにアクセスする権限がない場合、ユーザーはこのディレクトリを使用するデーモンまたはクライアントを起動できません。
-
同一ディレクトリ検証 - デーモンは、次を行うことによって他のデーモン、レプリケートされたストアまたは管理ユーティリティからの接続リクエストが同じグローバル・ディレクトリを参照していることを検証します。
-
ディレクトリ・パスが一致し、
rs_daemons.cfg
チェックサムが一致することを確認します。 -
リクエスタがこのディレクトリに書き込まれているUUIDの値を送信できることを検証します(ランダム共有シークレット)。デーモンの再起動ごとにUUIDが一度変更されます。
-
-
共有メモリー・アクセス権限 - デーモンはグループのみの権限を使用して共有メモリーを作成します。一致するグループ権限を持つユーザーを使用したクライアントのみがこの共有メモリーを使用できます。
レプリケートされたストアの制限事項
次の制限事項は、レプリケートされたストアに適用されます。
-
レプリケートされたストアは、2つのサーバー・インスタンスから同時に開かないでください。同時に開いた場合、領域内のデータが破損しないという保証はありません。可能であればレプリケートされたストアはこの場合にエラーを戻そうとしますが、この状態を必ず検知できるとはかぎりません。この可能性を防ぐため、それぞれに同じ名前が付いたレプリケートされたストアを使用した2つの同じ名前が付けられたドメインが完全に同じデーモン・クラスタを使用しないことを保証するのは管理者の責任です。同じ名前、同じドメイン名および同じグローバル・ディレクトリを持つ場合、2つのレプリケートされたストアが競合します。
-
デーモン・ロギングはWebLogic Server診断、Java Flight Recorder (JFR)、ロギングまたはDebugMBeansと統合されません。