Oracle® Fusion Middleware

WebLogic Server Multitenantの使用

12c (12.2.1.1.0)

E77392-02(原本部品番号:E69721-02)

2016年8月

このドキュメントでは、Oracle WebLogic Server Multitenant (MT)の機能と使用方法、およびWebLogic Server Multitenant環境でのドメイン・パーティションの使用方法について説明します。

Oracle Fusion Middleware WebLogic Server Multitenantの使用 12c (12.2.1.1.0)

E77392-02

Copyright (C) 2015, 2016, Oracle and/or its affiliates All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

- このリリースでの新機能と変更された機能

1 Oracle WebLogic Server Multitenant

- WebLogic Server MTについて

- Java EEアプリケーションのみをサポートするWebLogic Server MT

- WebLogic Server MTの主な概念

- テナント

- リソース・グループ

- リソース・グループ・テンプレート

- 仮想ターゲット

- スコープ

- リソースの分離

- WebLogic Server MTのユーザーおよびロール

- SaaSマルチテナントの理解

- Saas環境でのアプリケーションのテスト

- PaaSマルチテナントの理解

- ライフサイクル管理

2 Oracle WebLogic Server Multitenantの構成

- WebLogic Server MTの管理方法

- WebLogic Server MTの構成

3 仮想ターゲットの構成

- 仮想ターゲットの構成: 概要

- 仮想ターゲットのコンポーネント

- 仮想ターゲットおよびロード・バランシング

- 仮想ターゲットでのパーティション・チャネルの使用方法

- パーティションの管理用仮想ターゲットについて

- 仮想ターゲットの作成: 主な手順および例

- 仮想ターゲットの作成: WLSTの例

- 仮想ターゲットの作成: RESTの例

- 仮想ターゲットの管理: 主な手順および例

- パーティションで使用中の仮想ターゲットの削除

- ドメイン・レベルでリソース・グループが使用中の仮想ターゲットの削除

- 仮想ターゲットの管理: WLSTの例

- 仮想ターゲットの管理: RESTの例

- 仮想ターゲットの構成: 関連タスクおよびリンク

4 リソース・グループ・テンプレートの構成

- リソース・グループ・テンプレートの構成: 概要

- リソース・グループ・テンプレートとリソース・グループ間の相違とは

- リソース・グループ・テンプレートとは

- リソース・グループ・テンプレートおよびオーバーライド

- リソース・グループ・テンプレートの例

- リソース・グループ・テンプレートの作成: 主な手順およびWLSTの例

- リソース・グループの作成: WLSTの例

- リソース・グループ・テンプレートの構成: 主な手順およびWLSTの例

- リソース・グループ・テンプレートのデプロイメント設定の構成

- リソース・グループ・テンプレートのサービス設定の構成

- リソース・グループ・テンプレートのJDBC設定の構成

- リソース・グループ・テンプレートのJMS設定の構成

- JMSサーバー設定の構成

- SAFエージェント設定の構成

- JMSリソース設定の構成

- JMSモジュール設定の構成

- メッセージング・ブリッジの構成

- JMSブリッジ宛先の構成

- パス・サービスの構成

- リソース・グループのメール・セッション設定の構成

- リソース・グループの永続ストア設定の構成

- リソース・グループの外部JNDIプロバイダ設定の構成

- リソース・グループの診断システム・モジュール設定の構成

- リソース・グループ・テンプレートのノートの構成

- リソース・グループ・テンプレートの構成: WLSTの例

- リソース・グループ・テンプレートの削除: 主な手順およびWLSTの例

- リソース・グループ・テンプレートの削除: WLSTの例

- リソース・グループ・テンプレートの構成: 関連タスクおよびリンク

5 セキュリティの構成

- ドメイン・パーティションの新しいセキュリティ機能

- ドメイン・パーティションのセキュリティ・レルム: 概要

- アイデンティティ・ドメイン: 概要

- アイデンティティ・ドメインのタイプ

- デフォルトのアイデンティティ・ドメインの値

- 構成および管理用の管理ロール

- 管理アイデンティティ・ドメインの構成: 主な手順およびWLSTの例

- 管理アイデンティティ・ドメインの構成: WLSTの例

- セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: 主な手順および例

- セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: WLSTの例

- セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: RESTの例

- 「アイデンティティ・ドメイン対応プロバイダが必要」コントロールの設定: 主な手順

- ドメイン・パーティションへの直接接続: 主な手順およびWLSTの例

- ドメイン・パーティションへの直接接続: WLSTの例

- パーティション管理者としてのセキュリティ・データの管理: 主な手順および例

- パーティション管理者としてのユーザーおよびグループの管理: Fusion Middleware Controlの例

- パーティション管理者としての新規ユーザーの作成: WLSTの例

- パーティション管理者としてのユーザーおよびグループの管理: RESTの例

- ドメイン・パーティションでのSSLの構成

- ドメイン・パーティションでのセキュリティの構成: 関連タスクおよびリンク

6 Oracle Traffic Directorの構成

- Oracle Traffic Directorの構成: 概要

- Oracle Traffic Directorパーティション

- モニタリング

- ロギング

- Oracle Traffic Directorの構成: 主な手順

- Oracle Traffic Directorのドメインの作成

- Oracle Traffic DirectorのMT構成およびインスタンスの作成

- Fusion Middleware Controlを使用した構成およびインスタンスの作成

- WLSTを使用した構成およびインスタンスの作成

- Oracle Traffic Directorランタイムの登録

- Oracle Traffic Director: トラブルシューティング

- よくある質問

- Oracle Traffic Directorの構成: 関連タスクおよびリンク

7 ドメイン・パーティションの構成

- ドメイン・パーティションの構成: 概要

- ドメイン・パーティションの作成: 前提条件

- Oracle Traffic Director: WebLogic Serverプラグインの有効化に関する前提条件

- ドメイン・パーティションの作成: 主な手順および例

- ドメイン・パーティションの作成: WLSTの例

- ドメイン・パーティションの作成: RESTの例

- ドメイン・パーティションの管理: 主な手順および例

- ドメイン・パーティションの管理: WLSTの例

- ドメイン・パーティションの管理: RESTの例

- ドメイン・パーティションの制御: 主な手順および例

- パーティションの再起動を必要とする操作

- ドメイン・パーティションの制御: WLSTの例

- ドメイン・パーティションの制御: RESTの例

- ドメイン・パーティションの構成: 関連タスクおよびリンク

8 リソース・グループの構成

- リソース・グループの構成: 概要

- リソース・グループとは

- リソース・グループとオーバーライド

- グローバル・スコープおよびパーティションでのリソース・グループ

- 複数のターゲットへのリソース・グループのターゲット設定

- リソース・グループの作成: 主な手順および例

- リソース・グループの作成: WLSTの例

- リソース・グループの作成: RESTの例

- リソース・グループの構成: 主な手順および例

- リソース・グループの一般設定の構成

- リソース・グループのデプロイメント設定の構成

- リソース・グループへのアプリケーションのデプロイ

- リソース・グループへのアプリケーションの再デプロイ

- リソース・グループからのアプリケーションのアンデプロイ

- リソース・グループのサービス設定の構成

- リソース・グループのJDBC設定の構成

- リソース・グループのJMS設定の構成

- JMSサーバー設定の構成

- SAFエージェント設定の構成

- JMSリソース設定の構成

- JMSモジュール設定の構成

- メッセージング・ブリッジの構成

- JMSブリッジ宛先の構成

- パス・サービスの構成

- リソース・グループのメール・セッション設定の構成

- リソース・グループの永続ストア設定の構成

- リソース・グループの外部JNDIプロバイダ設定の構成

- リソース・グループの診断システム・モジュール設定の構成

- リソース・グループのターゲットの構成

- リソース・グループのノートの構成

- リソース・グループの構成: WLSTの例

- リソース・グループの構成: RESTの例

- リソース・グループの削除: 主な手順およびWLSTの例

- リソース・グループの削除: WLSTの例

- リソース・グループの制御: 主な手順およびWLSTの例

- リソース・グループの制御: WLSTの例

- リソース・グループの移行: 主な手順およびWLSTの例

- リソース・グループの移行: WLSTの例

- パーティション・リソース・グループでの管理アプリケーションおよびリソースの管理

- 管理リソース・グループの作成

- 管理リソース・グループのターゲット指定

- パーティションのライフサイクル状態および遷移について

- リソース・グループの構成: 関連タスクおよびリンク

9 リソース・オーバーライドの構成

- リソース・オーバーライド: 概要

- 構成MBeanオーバーライドの使用方法

- リソース・デプロイメント・プランの使用方法

- resource-deployment-plan構文

- サンプル・リソース・デプロイメント・プラン

- リソースMBeanオーバーライドの構成: 主な手順およびWLSTの例

- JDBCシステム・リソース・オーバーライドの構成: 主な手順

- JDBCシステム・リソース・オーバーライドの構成: WLSTの例

- JMSシステム・リソース・オーバーライドの構成: 主な手順

- JMSシステム・リソース・オーバーライドの構成: WLSTの例

- メール・セッション・オーバーライドの構成: 主な手順

- メール・セッション・オーバーライドの構成: WLSTの例

- リソース・デプロイメント・プランの構成: 主な手順およびWLSTの例

- リソース・オーバーライドの構成: 関連タスクおよびリンク

10 リソース消費管理の構成

- リソース消費管理の構成: 概要

- RCMを使用するためのソフトウェア要件

- リソース消費管理が必要な理由

- RCMを有効化する方法

- RCMのサポートされるリソース

- リソース消費管理の構成: 主な手順

- トリガー

- フェア・シェア

- リソースのフェア・シェアの割当ての決定

- リソース・マネージャの作成

- config.xmlでのRCMの構成例

- リソース・マネージャの動的再構成

- リソース消費管理の構成: リソース使用量のモニタリング

- リソース消費管理を使用する際のベスト・プラクティスおよび考慮事項

- 一般的な考慮事項

- リソースの平均使用率およびピーク使用率のモニター

- トリガーを使用する状況

- フェア・シェアを使用する状況

- 補足的ワークロードの使用

- パーティション・スコープのRCMポリシーを使用する状況

- CPU使用率の管理

- ヒープの管理

- RCMの制限事項

- リソース消費管理の構成: WLSTの例

- RCMのWLSTの例: 概要

- RCMのWLSTの例: WLSTスクリプト

- リソース消費管理の構成: 関連タスクおよびリンク

11 アプリケーションのデプロイ

- デプロイメント・スコープについて

- アプリケーションのリソース・グループ・テンプレートへのデプロイ

- アプリケーションのリソース・グループ・テンプレートへのデプロイ: 主な手順

- アプリケーションのリソース・グループ・テンプレートへのデプロイ: 例

- アプリケーションのリソース・グループ・テンプレートへのデプロイ: WLSTの例

- アプリケーションのリソース・グループ・テンプレートへの再デプロイ: WLSTの例

- アプリケーションのリソース・グループ・テンプレートからのアンデプロイ: WLSTの例

- リソース・グループ・テンプレートのアプリケーションの更新: WLSTの例

- アプリケーションのリソース・グループ・テンプレートへの配布: WLSTの例

- アプリケーションのリソース・グループ・テンプレートへのデプロイ: 関連タスクおよびリンク

- パーティション・リソース・グループへのアプリケーションのデプロイ

- パーティション・リソース・グループへのアプリケーションのデプロイ: 主な手順

- パーティション・リソース・グループへのアプリケーションのデプロイ: 例

- パーティション・リソース・グループへのアプリケーションのデプロイ: WLSTの例

- パーティション・リソース・グループへのアプリケーションの再デプロイ: WLSTの例

- パーティション・リソース・グループからのアプリケーションのアンデプロイ: WLSTの例

- パーティション・リソース・グループのアプリケーションの更新: WLSTの例

- パーティション・リソース・グループへのアプリケーションの配布: WLSTの例

- パーティション・リソース・グループのアプリケーションの起動: WLSTの例

- パーティション・リソース・グループのアプリケーションの停止: WLSTの例

- パーティション・リソース・グループへのアプリケーションのデプロイ: RESTの例

- パーティション・リソース・グループへのアプリケーションのデプロイ: 関連タスクおよびリンク

- パーティション管理者としてのアプリケーションのデプロイ

- アプリケーション構成のオーバーライド

- アプリケーション構成のオーバーライド: 主な手順

- アプリケーション構成のオーバーライド: WLSTの例

- アプリケーション構成のオーバーライド: 関連タスクおよびリンク

- アプリケーション・オーバーライドの削除

- アプリケーション・オーバーライドの削除: 主な手順

- アプリケーション・オーバーライドの削除: WLSTの例

- アプリケーション・オーバーライドの削除: 関連タスクおよびリンク

- パーティション固有のデプロイメント・プランの使用方法

- パーティション固有のデプロイメント・プランの使用方法: 主な手順

- パーティション固有のデプロイメント・プランの使用方法: WLSTの例

- パーティション固有のデプロイメント・プランの使用方法: 関連リンクおよびタスク

- マルチテナント環境での並行デプロイの有効化

12 共有アプリケーション・クラス・ローダーの構成

- 共有アプリケーション・クラス・ローダーの構成: 概要

- 共有アプリケーション・クラス・ローダーの構成: 主な手順

- 共有アプリケーション・クラス・ローダーの構成: 関連タスクおよびリンク

13 Oracle Coherenceの構成

- Oracle Coherenceの構成: 概要

- マルチテナント・ドメインでのOracle Coherenceアプリケーションのデプロイ

- キャッシュ構成プロパティのオーバーライド

- パーティション間でのキャッシュ共有の有効化

- マルチテナント・ドメインでのOracle Coherenceアプリケーションの保護

- Oracle Coherenceの構成: 関連タスクおよびリンク

14 JDBCの構成

- JDBCの構成: 前提条件

- サポートされるデータ・ソース・タイプについて

- JDBCデータ・ソースの構成: 考慮事項

- データ・ソースのスコープ

- ランタイム・モニタリング

- セキュリティ

- トランザクションのスコープ

- パーティション・ライフサイクル

- 診断イメージのソース

- ロギング

- JNDIバインド

- サポートされていない非推奨のドライバ

- JDBCデータ・ソースの構成: WLSTの例

- JDBCデータ・ソースの構成: 管理コンソールの例

- JDBCデータ・ソースの構成

- JDBCデータ・ソースのモニタリング

- JDBCデータ・ソース診断の構成

- パーティション・スコープのデプロイメントの構成

- リソース・デプロイメント・プランの使用方法

- JDBCデータ・ソースの構成: Fusion Middleware Controlの例

- JDBCデータ・ソースの構成: RESTの例

- JDBCデータ・ソースの構成: 関連タスクおよびリンク

15 メッセージングの構成

- メッセージングの構成: 前提条件

- メッセージング構成のスコープについて

- 構成検証およびターゲット指定のルールについて

- メッセージング・コンポーネントの構成

- JDBCまたはファイル永続ストアの構成

- JMSサーバーの構成

- ストア・アンド・フォワード・エージェントの構成

- 分散宛先による順序単位の使用をサポートするパス・サービスの構成

- メッセージング・ブリッジの構成

- JMSシステム・リソースおよびアプリケーション・スコープのJMSモジュールの構成

- パーティション固有のJMSオーバーライドの構成

- JNDIを使用したパーティション・スコープのメッセージング・リソースへのアクセス

- URLを指定しない

- パーティション仮想ホストまたはパーティションURIの指定

- 専用ポートURLの指定

- local: URLまたは修飾されたJNDI名を使用したローカル・クロス・パーティションのユースケース

- JMSでのパーティション関連付けについて

- 接続ファクトリとその接続またはJMSコンテキストとの間のパーティション関連付け

- 非同期コールバックとのパーティション関連付け

- 一致するスコープが必要な接続ファクトリおよび宛先

- 一時宛先のスコープ

- パーティション・スコープのメッセージング・コンポーネントの管理

- ランタイム・モニタリングおよびランタイム・コントロール

- パーティション・スコープのセキュリティの管理

- トランザクションの管理

- パーティションおよびリソース・グループのライフサイクル操作の管理

- パーティション・スコープのJMS診断イメージのソース

- パーティション・スコープのJMSロギング

- メッセージ・ライフサイクル・ロギング

- 管理ヘルパー

- ファイルの場所

- メッセージングの構成: ベスト・プラクティス

- メッセージングの構成: 制限事項

- メッセージング・リソース・グループの移行

- 永続データを含むリソース・グループの移行

- 非クラスタ・サービスの永続データの移行

- クラスタ・シングルトン・サービスの永続データの移行

- クラスタ分散サービスの永続データの移行

- ストア・アンド・フォワード・メッセージの移行

- メッセージドリブンBean (MDB)の移行

- サード・パーティJMSとグローバル・トランザクションに関する考慮事項

- リソース・グループの移行中のクライアント・フェイルオーバー

- 手動フェイルオーバー

- Oracle Traffic Director TCPプロキシの使用方法

16 JNDIの構成とプログラミング

- 外部JNDIプロバイダの構成: 概要

- 外部JNDIプロバイダの構成: 前提条件

- 外部JNDIプロバイダの構成: 主な手順

- 外部JNDIプロバイダの作成: WLSTの例

- パーティション環境でのJNDIのプログラミング

- パーティション・スコープとドメイン・スコープのJNDIリソースについて

- オブジェクトベースのパーティション関連付け

- コンテキストのパーティション情報の取得

- JNDIリソースへのリモートおよびパーティションをまたがるアクセス

- パーティションをまたがる認証

- パーティション環境でのクラスタ化JNDI

- パーティションJNDIリソースのライフサイクル

- 外部JNDIプロバイダの作成: 関連タスクおよびリンク

17 パーティション・ワーク・マネージャの構成

- パーティション・ワーク・マネージャ: 概要

- パーティション・ワーク・マネージャの構成: 主な手順

- パーティション・ワーク・マネージャの定義: WLSTの例

- ドメイン・レベルのパーティション・ワーク・マネージャの構成: WLSTの例

- パーティションのパーティション・ワーク・マネージャへの関連付け: WLSTの例

- パーティションでのパーティション・ワーク・マネージャ属性の定義: WLSTの例

- パーティション・ワーク・マネージャの構成: 関連タスクおよびリンク

18 ドメイン・パーティションへのWebLogic Serverドメインの移行

- ドメイン・パーティションへのWebLogic Serverドメインの移行: 概要

- Domain to Partition Conversion Toolの新機能

- ドメイン・パーティションへのWebLogic Serverドメインの移行: 前提条件

- ドメイン・パーティションへのWebLogic Serverドメインの移行: 主な手順

- WebLogic Serverドメイン・アプリケーション環境のエクスポートの準備

- WebLogic Serverドメイン・アプリケーション環境のエクスポート

- JSONファイルを使用したインポート時のデフォルトのオーバーライド

- ドメイン・パーティションへのアプリケーション・アーカイブ・ファイルのインポート

- レポートを使用したエクスポートおよびインポート操作のモニタリング

- ドメイン・パーティションへのWebLogic Serverドメインの移行: 制限事項と考慮事項

- JMSリソースを含むドメインのインポートの考慮事項と制限事項

19 パーティション同時管理対象オブジェクトの構成

- パーティション同時管理対象テンプレートの構成: 概要

- 同時管理対象オブジェクト・コンポーネント

- CMOによるパーティション・レベルの非同期タスク管理

- パーティション・レベルのMESテンプレート構成要素

- パーティション・レベルのMSESテンプレート構成要素

- パーティション・レベルのMTFテンプレート構成要素

- 長時間実行スレッドのパーティション・レベルCMO制約

- 最大同時長時間実行リクエストの制限の設定

- 最大同時新規スレッドの制限の設定

- パーティションCMOテンプレートの構成: 主な手順

- 管理コンソールでのパーティション・スコープCMOテンプレートの構成

- MBeanでのCMOテンプレートの構成

- パーティションの同時制約の構成: 主な手順

- 管理コンソールでのパーティションの同時制約の構成

- MBeanでの同時制約の構成

- パーティション・レベルCMOテンプレートのモニタリング

- 管理コンソールでのCMOテンプレートのモニタリング

- MBeanでのCMOテンプレートのモニタリング

- パーティション同時管理対象オブジェクトの構成: 関連タスクおよびリンク

20 パーティション・バッチ・ジョブ・ランタイムの構成

- パーティション・バッチ・ジョブ・ランタイムの構成: 概要

- パーティション・バッチ・ジョブ・ランタイムの構成: 主な手順

- 前提条件

- 管理コンソールを使用したパーティション・バッチ・ジョブ・ランタイムの構成

- パーティション・バッチ・ジョブ・ランタイムの構成: WLSTの例

- バッチ・ジョブ・ランタイムの問合せ

- 管理コンソールを使用したバッチ・ジョブ・ランタイムの問合せ

- すべてのバッチ・ジョブの詳細の取得

- ジョブの実行に関する詳細の取得

- ジョブのステップ実行に関する詳細の取得

- ランタイムMBeanを使用したバッチ・ジョブ・ランタイムの問合せ

- getJobDetailsを使用したすべてのバッチ・ジョブの詳細の取得

- getJobExecutionsを使用したジョブ実行の詳細の取得

- getStepExecutionsを使用したジョブ・ステップ実行の詳細の取得

- パーティション・バッチ・ジョブ・ランタイムの構成: 関連タスクおよびリンク

21 リソース・アダプタの構成

- ドメイン・パーティションでのリソース・アダプタの構成: 概要

- ドメイン・レベルのリソース・アダプタのconfig.xmlの例

- パーティション・レベルのリソース・アダプタのconfig.xmlの例

- ドメイン・パーティションでリソース・アダプタを使用する際のベスト・プラクティスおよび考慮事項

- パーティション・レベルのリソース・アダプタのクラス・ロード動作の定義

- パーティションのアプリケーション構成のオーバーライド

- リソース・アダプタのリソース定義の考慮事項

- リソース・グループ移行およびリソース・アダプタ

22 パーティションのエクスポートおよびインポート

- ドメイン・パーティションのエクスポートおよびインポート: 概要

- パーティションのエクスポートについて

- パーティション・アーカイブ・ファイルの作成

- パーティション・アーカイブ・ファイルのコンテンツ

- パーティションのインポートについて

- アプリケーションのエクスポートおよびインポート

- 暗号化された属性のエクスポートおよびインポート

- ドメイン・パーティションのエクスポートおよびインポート: 主な手順およびWLSTの例

- ドメイン・パーティションのエクスポート: 主な手順

- ドメイン・パーティションのエクスポート: WLSTの例

- ドメイン・パーティションのインポート: 主な手順

- ドメイン・パーティションのインポート: WLSTの例

- ドメイン・パーティションのエクスポートおよびインポート: 関連タスクおよびリンク

23 名前が付いた同時編集セッションの管理

- 名前が付いた同時編集セッション: 概要

- 名前が付いた同時編集セッションの管理: 主な手順

- 名前が付いた同時編集セッションの管理: WLSTの例

- 名前が付いた同時編集セッションの管理: 関連タスクおよびリンク

24 トランザクションの構成

- ドメイン・パーティションでのトランザクションの構成: 概要

- ドメイン・パーティションのLLRデータ・ソース、JDBC TLogデータ・ソースおよび決定子リソースの構成: 制限事項

25 Webサービスの構成

- Webサービスの構成: 概要

- Webサービスの構成: 主な手順

- Webサービスの構成: SOAP over JMSでのパーティション化された分散トピックの使用

- Webサービスの構成: 関連タスクおよびリンク

26 パーティションのモニタリングおよびデバッグ

- ドメイン・パーティションのモニタリング: 概要

- パーティション・ログおよび診断データ

- パーティション・スコープのロギングの構成

- パーティション・スコープのデバッグの構成

- 診断システム・モジュールの構成

- メトリックの収集

- ポリシーとアクションの構成

- 診断データへのアクセス

- 共有ログ・ファイル

- パーティション固有のログ・ファイル

- WLDFデータ・アクセサの使用

- リソース消費管理のモニタリング

- RCMの構成

- パーティション・スコープのRCMメトリック

- パーティション・スコープのアプリケーションの計測

- パーティション・スコープの診断イメージ・キャプチャの構成

- パーティション管理者用のWLST診断コマンド

はじめに

このガイドでは、Oracle WebLogic Server Multitenantの機能と使用方法、およびWebLogic Server Multitenant (MT)環境でのドメイン・パーティションの使用方法について説明します。

対象読者

このガイドは、システム管理者を対象としています。Oracle WebLogic Serverのシステム管理者は、ドメイン・パーティション内のアプリケーションおよびリソースを含め、ドメインに対して完全なアクセスおよび制御が可能です。

関連する管理者の責務として、重要な本番システムの保守、セキュリティ・レルムの構成と管理、サーバー・リソースとアプリケーション・リソースへの認証および認可方式の実装、セキュリティ機能のアップグレード、およびセキュリティ・プロバイダのデータベースの保守などが含まれる場合もあります。システム管理者は、Webサービス、WebアプリケーションとEnterprise JavaBeans (EJB)のセキュリティ、公開鍵セキュリティ、Secure Sockets Layer (SSL)、Security Assertion Markup Language (SAML)を含むJavaセキュリティ・アーキテクチャに関する深い知識を備えています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

次の情報はWebLogic Server MTに関連します。

- 『Fusion Middleware ControlによるOracle WebLogic Serverの管理』 - Fusion Middleware Controlを使用してOracle WebLogic ServerおよびOracle WebLogic Server Multitenantを構成、管理およびモニターする方法について説明します。

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』 - WebLogic ServerインスタンスまたはクラスタへのJava EEアプリケーションまたはアプリケーション・モジュールのデプロイについて説明します(ドメイン・パーティション、リソース・グループ・テンプレートおよびリソース・グループへのデプロイを含む)。

- 『Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』 - WebLogic Serverでのセキュリティの構成方法について説明します。

- 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』 - 様々なタイプのWebLogic Serverリソースを紹介し、WebLogic Serverを使用してそれらのリソースを保護するための情報を提供します。このドキュメントの現在のバージョンでは、URL (Web)リソースとEnterprise JavaBeans (EJB)リソースのセキュリティについて重点的に説明します。

- 『Oracle WebLogic Serverのアップグレード』 - バージョン6n 以前のWebLogic Serverから最新バージョンのWebLogic Serverにアップグレードするために必要な手順などの情報を提供します。また、6n 以前のバージョンからアプリケーションを移行するための情報も記載されています。詳細は、『Oracle WebLogic Serverのアップグレード』を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このリリースでの新機能と変更された機能

このリリースで導入されたWebLogic Serverの新機能の一覧については、『Oracle WebLogic Serverの新機能』 12.2.1.1.0を参照してください。

1 Oracle WebLogic Server Multitenant

Oracle WebLogic Server Multitenant (MT)は、Software as a Service (SaaS)およびPlatform as a Service (PaaS)用にOracleプラットフォームを拡張し、完全なライフサイクル管理(Web層、中間層、キャッシュおよびデータベース)を提供します。

この章では、WebLogic Server MTを紹介し、マルチテナント環境でのその使用方法について説明します。

この章の内容は次のとおりです。

- WebLogic Server MTについて

- WebLogic Server MTの主な概念

- WebLogic Server MTのユーザーおよびロール

- SaaSマルチテナントの理解

- PaaSマルチテナントの理解

- ライフサイクル管理

注意:

リソース・グループ、リソース・グループ・テンプレート、デプロイメント・プランのオーバーライドなどのWebLogic Server MTの新機能の多くは、WebLogic Serverの非MTバージョンである12.2.1でも使用可能です。この章では、特定の機能が非MTバージョンで使用可能になる場合について記載し、必要に応じてWebLogic Serverドキュメントおよびオンライン・ヘルプを参照します。

WebLogic Server MTについて

WebLogic Serverのマルチテナントにより、複数の組織で使用できる共有可能なインフラストラクチャが提供されます。これらの組織は、テナントとして考えることができる、独自に選択した概念的なグループです。1つのドメインが複数のテナントをサポートできるようにすることによって、WebLogic Server MTは、複数のアプリケーションを共有しようとする際によく発生する困難(アプリケーション間のランタイムの影響、セキュリティの相違、データの混在、管理の課題など)を排除しながら、密度を改善し、リソースの効率的な使用を実現します。

WebLogic Server MTにより、テナントに対する実行中のアプリケーション・インスタンスおよび関連リソースの専用WebLogic Serverドメインの管理スライスとランタイム・スライスであるドメイン・パーティション内のリソースの分離が実現します。ドメイン・パーティションによって、アプリケーション・インスタンスと関連リソースがドメイン、WebLogic Server自体、Java仮想マシン(JVM)およびオペレーティング・システムを共有できるようにすることで密度が改善されることに加えて、図1-1に示すように、テナント固有のアプリケーション・データ、構成およびランタイム・トラフィックが分離されます。

図1-1 WebLogic Serverドメイン・パーティション

各ドメイン・パーティションには、独自のアプリケーションおよびリソースのランタイム・コピーが含まれます。WebLogic Serverによるクラス・ロードの処理方法の変更により、アプリケーションの分離と効率性の両方が実現します。マルチテナント環境にデプロイする場合は、アプリケーションを変更する必要はありません。たとえば、アプリケーションを変更せずに、異なるドメイン・パーティションにある給与計算アプリケーションの複数のインスタンスを実行できます。

WebLogic Server MTでは、ロード・バランサから中間層、キャッシュ層およびデータベース層までのマルチテンシを含む、エンドツーエンドのマルチテナント・インフラストラクチャが実現されます。WebLogic Server MTでは、Oracle WebLogic Server Enterprise EditionとOracle WebLogic Suiteの各製品が拡張されて、次のコンポーネントが含まれます。

- Oracle WebLogic Server MT。セキュアな分離を維持しながら、(ドメイン内のパーティションを許可することによって)アプリケーションをより少数のドメインに統合できます。

- Java SE Advancedに対するWebLogic MTの拡張機能。これにより、JVM内でアプリケーションのメモリー、CPUおよびI/Oの分離、モニタリングおよび管理が可能になります。

- Oracle WebLogic Coherence Enterprise EditionからGrid Editionまでのオプション。セキュアな分離を維持しながら、キャッシュをより少数のOracle Coherenceクラスタに統合できます。

- Oracle Traffic Director。WebLogic Server MTに対応し、完全に統合されたテナント対応ローカル・ロード・バランシングを提供します。

ライセンス情報の詳細は、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle WebLogic Server Multitenantに関する項を参照してください。

Java EEアプリケーションのみをサポートするWebLogic Server MT

WebLogic Server MTのこのリリースでは、Java Platform, Enterprise Edition (Java EE)アプリケーションのみがサポートされます。Oracle Java Required Files (JRF)に依存する製品はサポートされません。

JRFは、Oracleビジネス・アプリケーションおよびアプリケーション・フレームワークに共通の機能を提供する、WebLogic Serverインストールに含まれていないコンポーネントで構成されています。JRFは他に依存することなく開発されたライブラリやアプリケーションで構成されており、これらが共通の場所にデプロイされます。JRFの一部とみなされるコンポーネントには、Oracle Application Development Framework、Oracle Fusion Middleware監査フレームワーク、ダイナミック・モニタリング・サービス、Fabric Common、HTTPクライアント、インフラストラクチャ・セキュリティ、Javaオブジェクト・キャッシュ、JMXフレームワーク、JPS、ロギング、MDS、OJSP.Next、Oracle Webサービス、Oracle Web Services Manager、Oracle TopLink、UCP、XDKなどがあります。

これは、WebLogic Server MTは次の製品をサポートしないことを意味します。

- Oracle Web Services Manager。

- Oracle SOA Suite

- Oracle Application Development Framework (Oracle ADF)

- Oracle WebCenter

- Oracle Service Bus

- Oracle Enterprise Scheduler

- Oracle WebLogic Service Component Architecture (SCA)

WebLogic Server MTの主な概念

ドメイン・パーティションに加えて、WebLogic Server MTには次の新しい概念があります。

テナント

WebLogic Serverドメイン内でアプリケーションおよびリソースを使用する異なる外部の企業(たとえば、CompanyAとCompanyB)や、1つの企業内の異なる部署(たとえば、HRと会計)などの、個別のユーザー組織です。

テナントは独自に選択した論理グループで、これは構成可能なオブジェクトではありません。つまり、テナントではなく、ドメイン・パーティションを管理します。

テナントのアイデンティティは、特定のユーザーの特定のテナントとの関連付けです。たとえば、テナントFinanceをFinance-partitionという特定のドメイン・パーティションと関連付けるように選択できます。

ユーザー・アイデンティティ・ストアの指定に従い、ユーザーのアイデンティティから、特定のユーザーが属するテナントが識別されます。さらに、ユーザーのアイデンティティは、そのユーザーがユーザーの属するテナントを含む(ただしこれに限定されない)システム全体を移動する際の、認可される操作の適用に役立ちます。

リソース・グループ

(通常は)デプロイ可能な関連リソースの名前付きのコレクションです(たとえば、Java EEアプリケーションとそのデータ・ソース、JMSアーティファクト、アプリケーションが使用する他のリソースなどです)。

従来のWebLogic Serverドメインには、Java EEアプリケーション、JMSサーバーおよびキュー、データ・ソースなどの、複数のタイプのデプロイ可能なリソースを含めることができます。この従来のモデルでは、アプリケーション・スイートに複数のJava EEアプリケーションとそれらのアプリケーションをサポートする様々なリソースが含まれる場合は、管理者が一貫性のある単位としてではなく、個別にこれらのリソースを定義し、これらのアプリケーションをデプロイします。

WebLogic Server MTは、Java EEアプリケーションとそれらが使用するリソースを、ドメイン内の個別の管理単位にグループ化するための便利な方法として、リソース・グループを導入しています。リソースとアプリケーションは完全修飾されており、その中に、それらのリソースを開始したりそれらに接続するために必要なすべての情報(データ・ソースに接続するための資格証明やJava EEアプリケーションのターゲット指定情報を含む)が管理者によって提供されます。リソース・グループは、これらのデプロイ可能なリソースを直接含むか、リソースを定義するリソース・グループ・テンプレートを参照します。リソース・グループは、ドメイン・レベルで定義することも、ドメイン・パーティションに固有のものとすることもできます。

リソース・グループ内のすべてのリソースまたはリソース・グループによって参照されるすべてのリソースは、(同じターゲットに)まとめてターゲット指定されます。リソース・グループは起動および停止できます。

リソース・グループ・テンプレート

(通常は)複数のリソース・グループによってパターンとして使用されるデプロイ可能なリソースの名前付きのドメイン・レベル・コレクション。特定のテンプレートを参照する各リソース・グループには、そのテンプレートに定義されているリソースの独自のランタイム・コピーが含まれます。リソース・グループ・テンプレートは、複数テナント用にリソースを定義およびレプリケートする便利な方法です。リソース・グループ・テンプレートにより、アプリケーションとリソースの同じコレクションを複数のドメイン・パーティションにデプロイすることが非常に簡単になります。

リソース・グループ・テンプレートでは、次を定義できます。

- アプリケーションのデプロイメント

- ライブラリのデプロイメント

- Java Database Connectivity (JDBC)システム・リソース

- JMSシステム・リソース

- Oracle Coherenceシステム・リソース

- ファイル・ストア

- JMSサーバー

- メッセージング・ブリッジ

- パス・サービス

- 永続ストア

- ストア・アンド・フォワード(SAF)エージェント

- 外部JNDIプロバイダ

- メール・セッション

- WebLogic診断フレームワーク(WLDF)モジュール

リソース・グループ・テンプレートはドメイン・レベルで定義され、その後1つ以上のリソース・グループに参照されます。

リソース・グループ・テンプレートは、WebLogic Server MTが同じアプリケーションとリソースを複数回アクティブ化する(ドメイン・パーティションごとに1回ずつ) SaaS環境で特に役立ちます。そのようなリソースに関する情報のいくつかはすべてのドメイン・パーティションで同じになり、JMSキューの属性やデータベース接続の属性などのそのいくつかはパーティション間で異なります。たとえば、データ・ソースへの接続に使用されるURL、ユーザー名およびパスワードは、パーティション間で異なります。WebLogic Server MTは、パーティションごとに異なるテンプレートによって表されるアプリケーション・スイートをアクティブ化します。オーバーライド構成MBeanとリソース・デプロイメント・プランを指定して、パーティションのいくつかの属性値をオーバーライドできます。詳細は、「リソース・オーバーライドの構成」を参照してください。

仮想ターゲット

パーティションまたはリソース・グループが実行される場所であり、トラフィックをこれらにルーティングする手順(アドレス、プロトコル設定およびターゲット指定を含む)です。リクエスト・ルーティングは、ホスト名とオプションのURIで決定します。

次が含まれます。

- ホスト名とポート

- オプションのURI

- ネットワーク・アクセス・ポイント/チャネル

- プロトコル固有構成

- ターゲット・クラスタおよび管理対象サーバー

仮想ターゲットにより、ドメイン・パーティションとグローバル(ドメイン・レベル)ランタイムがターゲットのWebLogic Serverインスタンスの物理属性から分離されるため、アプリケーションがこれらの詳細を認識する必要がなくなります。

スコープ

アプリケーションまたはライブラリをデプロイする場合、4つのデプロイメント・スコープ・オプションから選択できます。

- グローバル。これは、非パーティション環境のドメイン・レベルと同等です。

- リソース・グループ・テンプレートこれは常にドメイン・レベルです。リソース・グループ・テンプレートにデプロイするアプリケーションまたはライブラリがドメイン・レベルとパーティションのいずれで使用できるかは、リソース・グループ・テンプレートを参照するリソース・グループのスコープに応じて異なります。

- パーティション内のリソース・グループ。これは、パーティションに制限される唯一のスコープです。

- ドメイン・レベルでのリソース・グループ。

ドメイン・パーティション間でアプリケーションまたはライブラリを共有できません。アプリケーションまたはライブラリはパーティション内でのみ使用可能です。アプリケーションまたはライブラリをデプロイするときに、パーティション内のリソース・グループを指定します。Fusion Middleware Controlでは、パーティション内のリソース・グループにデプロイされるアプリケーションおよびライブラリに、ドメイン・パーティションの名前と、それらがデプロイされたそのパーティション内のリソース・グループが表示されます。

ドメイン・レベルで実行されるアプリケーションまたはクラスと、パーティションのコンテキストで実行されるアプリケーションまたはクラスの主な違いは、次のとおりです。

- ドメイン・レベルで実行されるアプリケーションまたはクラスはドメイン全体で使用できますが、パーティションでは使用できません。

- パーティションのコンテキストで実行されるアプリケーションまたはクラスは、そのパーティション内でのみ使用できます。

注意:

ベスト・プラクティスとして、すべてのアプリケーションおよびリソースをドメイン・パーティションにデプロイすることをお薦めします。

リソースの分離

リソースの分離は、パーティション環境では非常に重要です。ドメイン・パーティションにリソース・グループを作成すると、WebLogic Server MTによって、JMSサーバー、JMSストアおよびJMSモジュール(接続ファクトリ、キュー、トピックなど)、Java Connector Architecture (JCA)アダプタおよびその他の関連するリソースを含む、アプリケーションに必要なすべてのリソースのランタイム・コピーが作成されます。

パーティション内にアプリケーションまたはライブラリをデプロイすると、行った構成の変更はそのパーティションに固有のものとなります。WebLogic Server MTでは、1つのパーティション内のアプリケーションはそのパーティションに適用されたリソースのみを参照するようになり、他のパーティションに関連付けられたリソースは参照しません。

WebLogic Server MTのリソースの分離には次が含まれます。

- セキュリティ: 各ドメイン・パーティションの一意のセキュリティ・レルムおよびアイデンティティ・ドメイン。

- 管理:

- パーティション固有の管理

- 独立したデプロイメント、構成およびソフトウェア更新

- パーティション固有のモニタリングおよびトラブルシューティング

- ランタイム:

- 専用のJava Naming and Directory Interface (JNDI): パーティションを認識する、JNDIレベルでのパーティション間の分離。アプリケーションで名前付きオブジェクトをバインドして、パーティションごとにそれらを取得できます。各リソースはパーティション固有の名前で(内部的に)タグ付けされ、パーティション専用のJNDIツリーに配置されます。クラスタ内のパーティションのアプリケーション内通信およびアプリケーション間通信は、パーティションで自動的に分離されます。

- 分離されたデータ: JMS、ファイル・システムおよびデータ・ソース。

- リソースの分離と公平性: JVMまたはOSによって提供されるリソースのリソース消費管理(RCM)。これにより、システム管理者が、CPU、ヒープ、ファイル、ネットワークなどのリソースに対して、リソース消費管理ポリシー(制約、リコース・アクション、通知など)を指定できるようになります。

- パーティション・ワーク・マネージャ: 同じWebLogic Serverインスタンスを共有するパーティション間での、作業リクエストのスレッド使用量の公平な分配および作業リクエストの優先度付け。

WebLogic Server MTのユーザーおよびロール

WebLogic Server MTの2つの主なユーザーは、WebLogic Serverシステム管理者とパーティション管理者です。

WebLogic Serverシステム管理者は、テナントのパーティションを作成および削除します。システム管理者は、パーティションのセキュリティ特性(セキュリティ・レルムやSSL構成など)の設定または変更と、共有(ドメイン・レベル)リソース・グループまたはリソース・グループ・テンプレートの参照を行うことができます。

「構成および管理用の管理ロール」で説明しているように、WebLogic Serverシステム管理者とパーティション管理者の大きな違いは、パーティション管理者はパーティション固有のセキュリティ・レルムに直接ログインすることです。

パーティション管理者は、パーティション内のリソース・グループごとに、パーティション構成の変更、アプリケーションのデプロイ、JMSリソース、データ・ソースおよびJDBC接続の作成など、パーティション・レベルでパーティションを管理します。パーティション管理者は、パーティションに関連付けられているセキュリティ・レルム・データ(ユーザーおよびグループ、資格証明マップ、ロール、ポリシーなど)を管理することもできます。パーティション管理者のセキュリティ管理機能を有効にするには、システム管理者が、パーティション管理者が属するマネージメント・アイデンティティ・ドメインを指定する必要があります。マネージメント・アイデンティティ・ドメインは、「セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: 主な手順および例」の手順5に示されているパーティションのプライマリ・アイデンティティ・ドメインと同じである必要があります。

システム管理者とパーティション管理者の両方が、次の操作を行います。

- パーティション内のリソース・グループを作成、変更および削除します。

- パーティション内のリソース・グループに対してアプリケーションをデプロイおよびアンデプロイします。

- パーティションを起動および停止します。すべてのリソース・グループとそれらのリソース・グループにデプロイされたすべてのアプリケーションが起動または停止されます。

- パーティション内のユーザーおよびグループ、資格証明マップ、ロールおよびポリシーを管理します。

WebLogicのロールと同様に、デプロイヤ、オペレータおよびモニターにはパーティションで制約されたロールが存在します。

SaaSマルチテナントの理解

SaaS環境で、アプリケーションが内部的にテナントごとのビューまたは必要なテナントごとの分離を提供できない場合は、かわりにテナントごとに個別のアプリケーションのインスタンスとその関連するサーバー側リソースをデプロイできます。これは、少なくとも非効率的です。各テナントで、ハードウェア容量またはJava仮想マシン、WebLogic Serverドメイン、管理サーバー、管理対象サーバー、クラスタ、およびWebサーバー、データ・グリッド、ネットワーキング、記憶域などのその他の関連リソースを含む独自のスタックが取得される場合があります。

WebLogic Server MTのSaaSモデルでは、引き続きリソースの分離を提供しながら、サーバー・リソースを最大限効率的に使用する方法が提供されます。各テナントで、アプリケーション・インスタンスと、ターゲット・サーバーおよびクラスタのリソース・インスタンスが取得されます。複数のドメイン・パーティションで、1つ以上の同じアプリケーションが同時に独立して実行されます。アプリケーションのコードの変更は必要なく、WebLogic Serverによってドメイン・パーティションの識別と分離が管理されます。

SaaSモデルでは、通常、1つ以上のアプリケーションと、それらがリソース・グループ・テンプレートで依存するリソースを定義します。その後、同じアプリケーションを使用するすべてのドメイン・パーティションからこのテンプレートを参照します。ドメイン・パーティション固有の変更を行うには、関連するリソース・グループの値を編集します。

SaaSモデルの手順フローの概要は次のとおりです。

1. WebLogic Serverシステム管理者が、リソース・グループ・テンプレートのJMSリソース、データ・ソースおよびその他のリソースを作成します。

2. WebLogic Serverシステム管理者は、必要なアプリケーションをリソース・グループ・テンプレートにデプロイします。

3. テナントに対してデプロイする準備ができたら、システム管理者が次の手順を実行します。

a. 必要な場合は、仮想ターゲットを作成します。

b. リソース・グループ、プラガブル・データベース情報、仮想ターゲット、セキュリティ・レルムを含むドメイン・パーティション構成を作成し、パーティションのターゲットとしてクラスタまたは一連の管理対象サーバーを指定します。

c. 特定のリソース・グループの一部の属性とすべてのアプリケーション・デプロイメント値をオーバーライドします。

d. パーティションを起動することで、そのパーティションのリソース・グループにデプロイされたすべてアプリケーションを起動します。

4. パーティションが起動された後は、パーティション管理者がパーティションのアプリケーションおよびリソースのランタイム状態を確認したり、パーティションのログ・エントリを確認したり、パーティションのセキュリティ・レルム・データを管理したり、パーティションのアプリケーションを停止および再起動できます。

デプロイ時に、リソース・グループ・テンプレートのアプリケーションおよびリソースがリソース・グループの各ドメイン・パーティションにレプリケートされてデプロイされ、さらに結果として次のようになります。

- WebLogic Serverインフラストラクチャがドメイン・パーティション間で共有されます。

- 個々のアプリケーション・インスタンスが独自のJNDIツリーとリソースを持つようになります。

- ランタイム・トラフィックが分離されます。アプリケーションには仮想ターゲットを使用してアクセスします。

- パーティション・ワーク・マネージャにより、パーティション間で作業リクエストのスレッド使用量および優先度付けの公平性が実現します。

- データがプラガブル・データベースによって分割されます。データ・ソースの実装によって、各ドメイン・パーティションに、そのパーティションに割り当てられているプラガブル・データベース対する個別の物理接続プールが作成されます。

Saas環境でのアプリケーションのテスト

SaaS環境でドメイン・パーティションを使用する多くの利点のうちの1つは、制御された本番環境で新しいバージョンのアプリケーションをテストできることです。

たとえば、ビジネスで重要なアプリケーションがPartition Aにデプロイされているとします。このアプリケーションに大きな変更を行う場合は、多くの場合それがユーザーに一般提供される前に、それを本番環境でテストする必要があります。WebLogic Server MTでは、これを簡単に実行できます。Partition Aで実行されているアプリケーションの安定したバージョンに影響を与えることなく、Partition Bを作成して、更新されたアプリケーションをデプロイできます。

Partition Bで実行されているアプリケーションの更新バージョンのターゲットとして実際の本番クラスタおよびデータ・ソースを指定して、制御された環境内でパフォーマンス・メトリックなどのすべてをテストして調整できます。

PaaSマルチテナントの理解

WebLogic Server MT PaaSモデルは、統合と同じ意味です。統合は、多数のテナントからの異なるアプリケーションを同じWebLogic Serverインフラストラクチャにデプロイできることを意味します。WebLogic Server MTでは、インフラストラクチャと、ドメイン、クラスタ、管理対象サーバー、ハードウェア、ネットワークなどの基礎となるリソースが共有されます。

SaaSユースケースでは、通常、WebLogic Serverシステム管理者がすべてのドメイン・パーティションと、それらのリソース・インスタンスを管理します。ただし、PaaSユースケースでは、多くの場合パーティション管理者がリソースの構成、パーティションのセキュリティ・レルム・データの管理、アプリケーションのデプロイなどを行って、それぞれのドメイン・パーティションとその中のリソースを管理します。

統合:

- 多数のテナントからのアプリケーションを同じWebLogic Serverインフラストラクチャに簡単にデプロイできます。

- 結果として、管理するドメインが1つ、リソースを消費するJVMが1つになります。

- 管理を分離します。WebLogic Serverシステム管理者がインフラストラクチャを管理します。パーティション管理者が、パーティションのセキュリティ・レルム・データ、パーティションのデプロイメントおよび関連するリソースを管理します。

- パーティション固有のコンポーネント(セキュリティ・レルム(テナントごと)、仮想ターゲット(アドレス)、プラガブル・データベース、JNDI (内部トラフィック)、JMS、パーティション・ワーク・マネージャ)を含むランタイムを分離します。各テナントで、アプリケーション・インスタンスと専用リソースの独自のセットを取得します。

PaaSユースケースでは、通常、各テナントで異なるアプリケーションが実行されて、これらのアプリケーションが他のテナントで実行されたアプリケーションと重複する場合としない場合があります。WebLogic Server MT PaaSソリューションを実装すると、通常、リソース・グループ・テンプレートを参照しないが、かわりにドメイン・パーティション内でのみ使用可能になるアプリケーションとその関連リソースを表す、自己完結型のリソース・グループを作成します。ただしこれは、PaaSソリューションではリソース・グループ・テンプレートがあまり使用されないとしても、それらがユースケースに適合する場合にPaaSソリューションでリソース・グループ・テンプレートを使用できないことを意味するわけではありません。

PaaSモデルの手順フローの概要は次のとおりです。

1. WebLogic Serverシステム管理者が、必要に応じて仮想ターゲットを作成します。

2. WebLogic Serverシステム管理者が、ワークロードを管理する指定されたパーティション・ワーク・マネージャまたはサービス品質(QoS)定義とともにドメイン・パーティションを作成します。
パーティション・ワーク・マネージャでは、パーティションの相対的な優先度と、基礎となるメモリーとCPUの可用性が定義されます。

3. WebLogic Serverシステム管理者が、ドメイン・パーティションのセキュリティ・レルムを選択し、使用可能なターゲットのリストを設定します。
ドメイン・パーティションのリソースとアプリケーションは、ドメイン・パーティションのセキュリティ・レルム内のユーザーのみが使用できます。他のテナントでは、リソースまたはアプリケーションを表示することもアクセスすることもできません。

4. WebLogic Serverシステム管理者が、パーティション管理者にパーティションを割り当てます。
リソース、アプリケーションおよびパーティションのセキュリティ・レルム・データは、パーティション管理者が管理します。(基礎となる管理対象サーバーとクラスタはパーティション管理者によって管理されません。)

5. パーティション管理者が、そのドメイン・パーティションに1つ以上のリソース・グループを作成し、使用可能なターゲットのリストからリソース・グループを選択します。

6. パーティション管理者が、ドメイン・パーティションの各リソース・グループに、異なるJMSリソース、データ・ソース、PDB情報、アプリケーションのデプロイメントなどを作成します。

7. パーティション管理者がパーティションを起動し、これによってパーティションのリソース・グループにデプロイされたすべてアプリケーションを起動します。

8. 追加のテナントごとに、手順1-4を繰り返します。

ライフサイクル管理

Oracle Fusion Middlewareのエンタープライズ・デプロイメントは複雑になる場合があります。WebLogic Server MTは、分離のためのパーティションを使用して、多くのドメインを1つに統合することを簡略化し、コンポーネント構成間の新しいレベルの調整を導入します。

WebLogic Server MTライフサイクル管理は、異なるコンポーネント間のパーティションを接続して、テナントのニーズに応える1つの結合ユニットを形成します。これを行うために、ライフサイクル・マネージャ(LCM)は、コンポーネント全体の構成を統合します。

Representational State Transfer (REST)、WebLogic Scripting Tool (WLST)、Fusion Middleware ControlまたはOracle WebLogic Server管理コンソールのいずれかを使用して、パーティションが作成、更新または削除されると、ライフサイクル・マネージャはこれらのバンド外のアクションを検出して、その構成を管理サーバーの構成と同期します。ライフサイクル・マネージャは、登録されているプラグイン(Oracle Traffic Directorプラグインなど)にこれらの変更を通知して、環境全体で同期を維持します。

WebLogic Server MTでドメイン・パーティションが作成または更新されると、変更は複数の層にわたって編成されます。

- Oracle Traffic Director構成が更新され、新しいパーティションと同期されます。

- アプリケーションがOracle Coherenceのキャッシュまたはサービスと関連付けられます。

- データ・ソースが既存のデータベースまたはプラガブル・データベース(PDB)に関連付けられるか、新しいプラガブル・データベースが作成されます。

図1-2に、トラフィックの分離と、Web層からデータベース層へのフローを示します。

図1-2 ライフサイクル管理

2 Oracle WebLogic Server Multitenantの構成

この章では、Oracle WebLogic Server Multitenant (MT)の構成の概観について説明します。この章では、適宜追加情報について、Oracle Fusion Middleware、Oracle CoherenceおよびOracle Traffic Directorのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章では次の項について説明します。

- WebLogic Server MTの管理方法

- WebLogic Server MTの構成

WebLogic Server MTの管理方法

次の4つのツールのいずれかを使用して、WebLogic Server MTを管理できます。

- Oracle Enterprise Manager Fusion Middleware Control (FMWC) (推奨のグラフィカル・ユーザー・インタフェース)

- Oracle WebLogic Server管理コンソール

- WebLogic Scripting Tool(WLST)

- Representational State Transfer (REST) API

この章では、各タスクに関して次のことを示します。

- 所定のタスクを達成するための主な手順(関連するFusion Middleware Controlオンライン・ヘルプ・トピックへのリンクが含まれます)

- WLSTの例

場合によっては、Fusion Middleware ControlとWebLogic Server管理コンソールで、機能が提示される方法が異なります。この章では、これらの場合について示し、必要に応じてWebLogic Server管理コンソール・オンライン・ヘルプへのリンクを示します。

WebLogic Server MTの構成

図2-1に示されているWebLogic Server MTの概観を考えてみます。この図は、ドメイン・パーティション、Oracle Traffic Director、WebLogic ServerドメインおよびOracle Coherenceの関係を示しています。

図2-1 WebLogic Server MTの概観

図2-1のWebLogic Server MTを構成するには、次のようにします。

1. 『Oracle WebLogic ServerおよびCoherenceのインストールと構成』のWebLogic Server MT用のOracle WebLogic ServerおよびOracle Coherenceのインストールに関する項の説明に従い、MT用のWebLogic Serverをインストールします。

注意:

Oracle Traffic Directorを使用して、パーティションで実行中のアプリケーションへのトラフィックを管理する予定の場合、管理対象サーバーが実行されるリモート・ホスト上の同じパスにWebLogic Serverをインストールする必要があります。新しいライフサイクル管理機能では、管理サーバー・ホストにインストールされたものと同じ相対パスで使用できる必要があるプラグインJava Archive (JAR)ファイルにアクセスする必要があります。

2. Oracle Traffic Directorを使用してパーティションへのトラフィックを管理するには、『Oracle Traffic Directorインストレーション・ガイド』の説明に従い、Oracle Traffic Directorをコロケート・モードでインストールします。
Oracle Traffic DirectorとWebLogic Serverは、(図2-1に示すように)異なるシステム上の異なるOracle_Homeの場所にインストールすることも、単一システム上の同じOracle_Homeにインストールすることもできます。

3. Oracle Traffic Directorを使用してパーティションへのトラフィックを管理するには、「Oracle Traffic Directorのドメインの作成」の説明に従い、構成ウィザードを使用してOracle Traffic Directorドメインを作成します。
Oracle Traffic Director - Restricted JRFテンプレートを使用して、ドメインを作成します。このテンプレートによって、他の必要なテンプレートの多くが自動的に含められます。

4. 『構成ウィザードによるWebLogicドメインの作成』のWebLogic Serverドメインの作成に関する項の説明に従い、新しいドメインを作成します。
『Oracle WebLogic ServerおよびCoherenceのインストールと構成』のWebLogic Server MultitenantのためのOracle WebLogic ServerおよびCoherenceのインストールに関する項の説明に従い、Oracle Enterprise Manager - Restricted JRFテンプレートを使用してドメインを作成します。このテンプレートによって、他の必要なテンプレートの多くが自動的に含められます。

5. WebLogic Serverのライフサイクル・マネージャ(LCM)を使用して、パーティション構成の変更をOracle Traffic Directorと調整するには、WLSTを使用して、WebLogic ServerドメインでLCMを有効にします。

edit()
startEdit()
cd("/")
lcmConfig=cmo.getLifecycleManagerConfig();
lcmConfig.setDeploymentType("admin")
lcmConfig.setOutOfBandEnabled(true)

6. ドメイン・パーティションで使用する必要があるクラスタおよび管理対象サーバーを作成します。
Fusion Middleware ControlまたはWebLogic Server管理コンソールを使用する場合は、クラスタの作成時にパーティション固有の事項はありません。詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogicクラスタの設定に関する項を参照してください。

ただし、WLSTを使用して管理対象サーバーを作成する場合は(手動構成か動的かを問わない)、必要なOracle Java Required Files (JRF)テンプレートが適用されません。Fusion Middleware Controlでは、ドメインのモニタリングを有効にするために、JRFテンプレートが必要です。

したがって、WLSTを使用する場合は次のようにします。

a. WLSTを使用してクラスタまたは管理対象サーバーを作成します。

b. applyJRFコマンドを使用して、JRFテンプレートを管理対象サーバーに適用します。詳細は、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』を参照してください。

7. 「仮想ターゲットの構成」の説明に従い、1つ以上の仮想ターゲットを作成します。

8. 「リソース・グループ・テンプレートの構成」の説明に従い、リソース・グループ・テンプレートを作成して構成します。

9. オプションで、「アプリケーションのデプロイ」の説明に従い、アプリケーションをリソース・グループ・テンプレートにデプロイします。パーティション固有のデータベース接続がアプリケーションで必要となる場合があります。

10. 「セキュリティの構成」の説明に従い、新しいセキュリティ・レルムを作成します。

11. Oracle Traffic Directorを使用してパーティションへのトラフィックを管理するには、「Oracle Traffic DirectorのMT構成およびインスタンスの作成」の説明に従い、Fusion Middleware Controlを使用してOracle Traffic Directorインスタンスを作成します。

12. 「ドメイン・パーティションの構成」の説明に従い、ドメイン・パーティションを作成します。

13. 「リソース・オーバーライドの構成」の説明に従い、Java Database Connectivity (JDBC)接続などのリソースをオーバーライドします。

14. オプションで、「Oracle Coherenceの構成」の説明に従い、Oracle Coherenceを構成します。

15. オプションで、「リソース消費管理の構成」の説明に従い、リソース・マネージャを構成します。

16. 「パーティションのモニタリングおよびデバッグ」の説明に従い、ドメイン・パーティションをモニターします。

3 仮想ターゲットの構成

この章では、仮想ターゲットの構成方法について説明します。ドメイン・パーティションまたはリソース・グループを作成する場合、仮想ターゲットは前提条件となります。この章では、適宜追加情報について、Oracle Fusion MiddlewareおよびOracle Traffic Directorのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章の内容は次のとおりです。

- 仮想ターゲットの構成: 概要

- 仮想ターゲットの作成: 主な手順および例

- 仮想ターゲットの管理: 主な手順および例

- 仮想ターゲットの構成: 関連タスクおよびリンク

仮想ターゲットの構成: 概要

仮想ターゲットは、ドメイン・レベルとドメイン・パーティションの両方におけるリソース・グループのターゲットを表します。これにより、リソース(1つ以上のホスト名、URI接頭辞、仮想ターゲット自体がターゲット指定される管理対象サーバーまたはクラスタなど)へのアクセス・ポイントを定義します。

仮想ターゲットは、Oracle WebLogic Serverにおける仮想ホストと同様です。仮想ターゲットでは、仮想ホストのように、ターゲットごとに個別のHTTPサーバー(Webコンテナ)が提供されます。

仮想ターゲットでは、コンテナが実行中の物理属性からリソース・グループを分離します。

各リソース・グループには、1つ以上の仮想ターゲットが必要です。選択できる仮想ターゲットは、リソース・グループがドメイン・レベルであるか、ドメイン・パーティションに関連付けられているかによって、次のように異なります。

- ドメイン・レベルのリソース・グループの場合、使用可能なターゲットとしてパーティションにまだ割り当てられていない、任意の既存の仮想ターゲットを選択できます。

- ドメイン・パーティションのリソース・グループの場合、そのパーティションで使用可能な既存の仮想ターゲットのみから選択する必要があります。

仮想ターゲットの使用に関する次のガイドラインを考慮します。

- 仮想ターゲットは、一度に1つのパーティションのみで使用したり、ドメイン・レベルで使用することができます。仮想ターゲットは、複数のパーティションで共有されたり、パーティションとドメイン・レベルで共有されることはありません。

- 仮想ターゲットは、パーティション内の多数のリソース・グループでも、ドメイン・レベルの多数のリソース・グループでも使用できます。

- 1つの仮想ターゲットは、1つのクラスタまたは1つの管理対象サーバーにターゲット指定できます。

- 多数の仮想ターゲットは、同じクラスタまたは管理対象サーバーにターゲット指定できます。

- 2つの仮想ターゲットが同じホスト名、URI接頭辞およびポート番号を持つ場合は、異なるクラスタまたは管理対象サーバーにターゲット指定する必要があります。

仮想ターゲットのコンポーネント

仮想ターゲットには次のものが含まれます。

- ホスト名。この仮想ターゲットがリクエストを処理するホスト名のリスト。指定するホスト名は、適切なサーバーまたはロード・バランサに解決されるドメイン・ネーム・システム (DNS)エントリを持っている必要があります。

- Oracle Traffic Directorを使用してパーティションの接続ロード・バランスを行っていない場合、WebLogic Serverクラスタまたは管理対象サーバーの実際のホスト名を指定します。

- Oracle Traffic Directorを使用してパーティションの接続のロード・バランスを行っている場合、Oracle Traffic Directorを介してアプリケーションにアクセスします。仮想ターゲットに指定するホスト名は、Oracle Traffic Director管理サーバーの場所に解決される必要があります。

ホスト名を指定しない場合は、すべての着信リクエストに一致するようにホスト名にワイルドカードを使用する場合と同等になります。

リソース・グループにアクセスするためにクライアントが使用するホスト名は、仮想ターゲットで指定したホスト名のいずれかと厳密に一致する必要があります。

仮想ターゲットに複数のホスト名を指定できます。確実に一致するように、簡易ホスト名と完全修飾ホスト名の両方を指定すると便利な場合があります。

- この仮想ターゲットがリクエストを処理するオプションのURI接頭辞。たとえば、ホスト名としてwww.example.com、URI接頭辞としてMyAppを入力した場合、この仮想ターゲットは、www.example.com/MyAppへのリクエストは処理しますが、www.example.comやwww.example.com/fooへのリクエストは処理しません。
この例を拡張し、アプリケーション・ルートが/appであるとします。結果として得られるアプリケーションのURLは、www.example.com/MyApp/appになります。

- 現在のドメイン内のターゲットのリストからのターゲット・クラスタおよび管理対象サーバー。ターゲットは、単一サーバーまたは単一クラスタである必要があります。

仮想ターゲットを使用する場合、ホスト名(http://partition1.com、http://partition2.com)によるルーティングまたはURI接頭辞(http://server.com/partition1、http://server.com/partition2)によるルーティングという2つの一般的な方法があります。1つの方法を常に使用すると環境の管理がより簡単になりますが、そのようにする必要があるわけではありません。

少なくとも1つのホスト名、URI接頭辞またはポート番号を指定する必要があります。

仮想ターゲットおよびロード・バランシング

仮想ターゲットでは、リクエストが特定のサーバーに到達する方法は決定しません。DNSまたはロード・バランサで、リクエストが特定のサーバー・インスタンスに到達する方法を決定します。仮想ターゲットで使用されるホスト名は、ルーティングを制御しませんが、ルーティングと一貫性がある必要があります。

仮想ターゲットでは、サーバーに入ったリクエストに対する処理を決定します。リクエストは、サーバーに入ると、そのサーバーをターゲットとするすべての仮想ターゲットと照合されます。着信リクエストがいずれかの仮想ターゲットの情報に一致する場合、そのリクエストはその仮想ターゲットを対象としているとみなされます。ホスト名とURI接頭辞の両方が指定されている場合、両方が一致している必要があります。2つの仮想ターゲットが一致する場合、最も長いURI接頭辞が一致するほうがリクエストを受信します。一致しない場合、リクエストはデフォルトのHTTPサーバーに送信されます。

たとえば、ホスト名www.example1.com、www.example2.comおよびwww.example3.comを含む仮想ターゲットがあるとします。仮想ターゲットは、cluster1にターゲット指定されています。www.example1.com、www.example2.comおよびwww.example3.comに送信されたリクエストはすべてその仮想ターゲットに一致し、すべてcluster1に送信されます。

1つのリソース・グループに複数の仮想ターゲットを指定した場合でも、仮想ターゲットの照合は同様に機能します。仮想ターゲット間に暗黙的なロード・バランシングはありません。

たとえば、PartitionAに、ホスト名がwww.example1.comで、cluster1にターゲット指定された仮想ターゲットと、ホスト名がwww.example2.comで、cluster2にターゲット指定された2番目の仮想ターゲットがあるとします。www.example1.comに送信されたリクエストは、その仮想ターゲットにのみ一致し、cluster1にのみ送信されます。www.example2.comに送信されたリクエストは、その仮想ターゲットにのみ一致し、cluster2にのみ送信されます。

ロード・バランシングが必要な場合、Oracle Traffic Directorを使用します。

仮想ターゲットでのパーティション・チャネルの使用方法

オプションで、既存のチャネルおよびポート(明示的またはオフセット)情報を指定して、仮想ターゲットのパーティション固有のチャネルのための参照として使用できます。

ネットワーク・チャネルは、WebLogic Serverに対するネットワーク接続の属性を定義する構成可能なリソースです。WebLogic Serverインスタンスのネットワーク・チャネルは、通信プロトコル、リスニング・アドレス、リスニング・ポートおよびチャネル名という4つの属性の組合せです。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項を参照してください。

チャネルは、選択したターゲット上に存在し、同じプロトコルを使用して構成されている必要があります。「パーティション・チャネル」の値を指定する場合は、明示的なポートまたはポート・オフセットのいずれかを指定する必要があります。

明示的なポートに使用できる値は1から65535で、1から1023 (ウェル・ノウン・ポートまたはシステム・ポート)ではシステム(またはルート)のプロセス権限が必要です。ポートは、別のプロセスによってバインドされていない必要があります。

次に例を示します。

1. ホスト名myexample.comおよびURI接頭辞/fooを含む仮想ターゲットを作成します。

2. 「パーティション・チャネル」フィールドで、パーティション固有チャネルを作成するための参照として使用する既存のチャネルChannel-1を指定します。

3. Channel-1には、127.0.0.1:7002のリスニング・アドレスとリスニング・ポート、および127.0.0.1:7002の外部アドレスとリスニング・ポートがあります。

4. ポート・オフセットとして5を指定します。リスニング・ポートの場合は7002 +5の結果となります。

5. myexample.comは127.0.0.1に解決される必要があります。

6. この仮想ターゲットにアクセスするには、myexample.com:7007/fooを使用します。

7. 同様にChannel-1を使用する別の仮想ターゲットを作成する場合は、別のポート・オフセット(または明示的なポート)を使用する必要があり、そのようにしないと、ポートの競合が発生します。

8. すべての場合について、そのまま使用する明示的ポート値、またはポート・オフセットを指定します。そのようにしない場合、ポートが割り当てられず、チャネルが作成および使用されません。

Oracle WebLogic Server管理コンソールを使用して、チャネルを作成します。詳細は、WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ネットワーク・チャネルの構成に関する項を参照してください。

注意:

Oracle Traffic Directorを使用してドメイン・パーティションのロード・バランシングを行う場合、パーティション・チャネルは無視されます。

パーティションの管理用仮想ターゲットについて

パーティション管理仮想ターゲットは、各パーティションの作成時に自動的に作成される仮想ターゲットであり、ドメインの管理サーバーがその物理ターゲットとして使用されます。

パーティション管理仮想ターゲットには次の設定があります。

- ホスト名: 空(ワイルドカード)

- uriPrefix: /partitions/<partition-name>

注意:

uriPrefixの/partitionsは別のものに変更できます。この設定はドメイン全体に対して使用されます。変更するには、次のようにします。

DomainMBean.setPartitionUriSpace(String uriPrefix);

ただし、可能な場合は、デフォルト設定をそのまま使用することをお薦めします。

- ターゲット: 管理サーバー

- その他の設定は管理サーバーのデフォルトHTTPサーバーから継承します。

パーティション管理仮想ターゲットの設定は、パーティションの構成MBeanから取得できます。

WebLogic Scripting Tool (WLST):の使用

serverConfig()
partition = cmo.lookupPartition(partitionName)
adminVT = partition.getAdminVirtualTarget()

管理仮想ターゲットは、パーティションに対して使用可能なターゲットのリストに自動的に追加されることはありません。パーティション管理者がこれをリソース・グループのターゲット指定に使用できるようにするには、システム管理者がパーティションの使用可能なターゲットとして明示的に追加する必要があります。

管理仮想ターゲットは、その他の仮想ターゲットの場合と同様に、パーティションのターゲット指定に使用できます。ただし、管理仮想ターゲットは読取り専用であり、変更したり削除することはできません。

仮想ターゲットの作成: 主な手順および例

注意:

仮想ターゲットは、ホスト名: ""、URI接頭辞: /、明示的ポート: 0、ポート・オフセット: 0として構成しないでください。この構成では、仮想ターゲットがデフォルトHTTPサーバー宛てのすべてのリクエストをインターセプトします。この構成は許可されません。

仮想ターゲットを作成する主な手順は次のとおりです。

1. この仮想ターゲットの名前を入力します。

2. オプションで、この仮想ターゲットのURI接頭辞を入力します。

3. 仮想ターゲットの名前を1つ以上追加します。指定するホスト名は、指定するターゲット・クラスタおよび管理対象サーバーに解決されるか、またはOracle Traffic Directorを使用してロード・バランシングを行う場合はOracle Traffic Director管理サーバーに解決される必要があります。

4. オプションで、「仮想ターゲットでのパーティション・チャネルの使用方法」の説明に従い、この仮想ターゲットに使用するパーティション・チャネルおよびポート(明示的またはオフセット)情報を指定します。チャネルは、選択したターゲット上に存在し、同じプロトコルを使用して構成されている必要があります。「パーティション・チャネル」の値を指定する場合は、明示的なポートまたはポート・オフセットのいずれかを指定する必要があります。

注意:

Oracle Traffic Directorを使用してドメイン・パーティションのロード・バランシングを行う場合、これらのオプションは無視されます。

5. 使用可能なターゲットから1つのターゲットを選択します。単一の管理対象サーバーまたは単一のクラスタを選択できます。

6. WebLogic Server管理コンソール、WebLogic Scripting Tool (WLST)またはRepresentational State Transfer (REST)を使用して仮想ターゲットを作成している場合は、追加のHTTP構成オプションを仮想Webサーバーの構成に使用できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの仮想ターゲットのHTTPの構成に関する項を参照してください。

Fusion Middleware Controlを使用して仮想ターゲットを作成する場合は、オンライン・ヘルプの仮想ターゲットの作成に関する項を参照してください。

仮想ターゲットの作成: WLSTの例

この例では、次の操作を実行しています。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. 仮想ターゲットを管理サーバーにターゲット設定します。(通常は、WebLogic管理サーバーは選択しません。)

5. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

6. リソース・グループを作成します。

7. 仮想ターゲットをリソース・グループに追加します。

8. 変更をアクティブ化します。

9. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

# Create virtual target
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> tgt=getMBean('/Servers/AdminServer')
wls:/base_domain/edit/ !> vt.addTarget(tgt)
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)

仮想ターゲットの作成: RESTの例

RESTを使用した仮想ターゲットの作成の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティションの作成に関する項を参照してください。

特に、新しいパーティションの仮想ターゲットの作成に関する項を参照してください。

仮想ターゲットの管理: 主な手順および例

実行中のパーティションの実行中のリソース・グループで使用されている仮想ターゲットに変更を加えた場合、変更を有効にするにはパーティションの再起動が必要になることがあります。

仮想ターゲットを管理する主な手順は次のとおりです。

1. 管理する仮想ターゲットを選択します。

2. この仮想ターゲットのURI接頭辞を入力するか、既存のURI接頭辞を変更します

3. 仮想ターゲットの名前を1つ以上追加します。指定するホスト名は、指定するターゲット・クラスタおよび管理対象サーバーに解決されるか、またはOracle Traffic Directorを使用してロード・バランシングを行う場合はOracle Traffic Director管理サーバーに解決される必要があります。

4. 必要に応じて、仮想ターゲットの1つ以上のホスト名を削除します。

5. オプションで、「仮想ターゲットでのパーティション・チャネルの使用方法」の説明に従い、この仮想ターゲットに使用するパーティション・チャネルおよびポート(明示的またはオフセット)情報を指定します。チャネルは、選択したターゲット上に存在し、同じプロトコルを使用して構成されている必要があります。「パーティション・チャネル」の値を指定する場合は、明示的なポートまたはポート・オフセットのいずれかを指定する必要があります。

注意:

Oracle Traffic Directorを使用してドメイン・パーティションのロード・バランシングを行う場合、これらのオプションは無視されます。

6. 使用可能なターゲットから1つのターゲットを選択します。単一の管理対象サーバーまたは単一のクラスタを選択できます。(特別な理由がないかぎり、通常は、WebLogic Server管理サーバーは選択しません。)
使用しないターゲットの選択を解除します。

7. WebLogic Server管理コンソール、WLSTまたはRESTを使用して仮想ターゲットを管理している場合は、追加のHTTP構成オプションを仮想Webサーバーの構成に使用できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの仮想ターゲットのHTTPの構成に関する項を参照してください。

8. 実行中のパーティションの実行中のリソース・グループで使用されている仮想ターゲットに変更を加えた場合、変更を有効にするにはパーティションを再起動します。

Fusion Middleware Controlを使用して仮想ターゲットを管理する場合は、Fusion Middleware Controlオンライン・ヘルプの仮想ターゲットの構成に関する項を参照してください。

パーティションで使用中の仮想ターゲットの削除

パーティション内のリソース・グループが使用中の仮想ターゲットは、削除できません。まずこれをリソース・グループから削除する必要があります。

パーティションで使用中の仮想ターゲットを削除するには、次のようにします。

1. パーティションを停止します。

2. そのパーティションのリソース・グループから仮想ターゲットを削除します。

3. パーティションの使用可能なターゲットのリストから仮想ターゲットを削除します。

4. 仮想ターゲットがパーティションでデフォルトで使用されている場合は、このオプションの選択を解除します。

5. パーティションを再起動します。

6. 仮想ターゲットを削除します。

Fusion Middleware Controlを使用して仮想ターゲットを削除する場合は、Fusion Middleware Controlオンライン・ヘルプのパーティションで使用中の仮想ターゲットの削除に関する項を参照してください。

ドメイン・レベルでリソース・グループが使用中の仮想ターゲットの削除

ドメイン・レベルでリソース・グループが使用中の仮想ターゲットは、削除できません。まずこれをリソース・グループから削除する必要があります。

ドメイン・レベルのリソース・グループで使用中の仮想ターゲットを削除するには、次のようにします。

1. 削除する必要がある仮想ターゲットをリソース・グループから削除します。

2. 仮想ターゲットを削除します。

仮想ターゲットを削除する場合は、Fusion Middleware Controlオンライン・ヘルプのドメイン・レベルでリソース・グループが使用中の仮想ターゲットの削除に関する項を参照してください。

仮想ターゲットの管理: WLSTの例

次の例では、URI接頭辞/appを含む既存の仮想ターゲットTestVTを変更し、ホスト名をmyhost.example.comに設定します。

myVTは、VirtualTargetMBeanのインスタンスです。

cd('/')
edit()
startEdit()
cd('VirtualTargets')
cd ('TestVT')
cmo.setUriPrefix('/app')
cmo.setHostNames(jarray.array([String("myhost.example.com")],String))
activate()

DomainMBeanを使用して、名前で仮想ターゲットをルックアップし、VirtualTargetMBeanを返すこともできます。

domain=getMBean('/')
vt=domain.lookupVirtualTarget('TestVT')
vt.setUriPrefix('/app')

仮想ターゲットの削除

次の例では、仮想ターゲットTestVTを削除します。最初に、パーティションPepの使用可能なターゲットとして仮想ターゲットを削除します。

cd('/')
edit()
startEdit()
domain=getMBean('/')
vt=domain.lookupVirtualTarget('TestVT')
part=domain.lookupPartition('Pep')
part.removeAvailableTarget(vt)
domain.destroyVirtualTarget(vt)
activate()

仮想ターゲットの再指定

この例では、次の操作を実行しています。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. 仮想ターゲットを管理サーバーにターゲット設定します。(特別な理由がないかぎり、通常は、WebLogic Server管理サーバーは選択しません。)

5. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

6. リソース・グループを作成します。

7. 仮想ターゲットをリソース・グループに追加します。

8. 変更をアクティブ化します。

9. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

10. ターゲットとしての管理サーバーを削除します。

11. 仮想ターゲットのターゲットとしてCluster-0を再指定します。

# Create Pep partition and ResourceGroup
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> tgt=getMBean('/Servers/AdminServer')
wls:/base_domain/edit/ !> vt.addTarget(tgt)
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)
startEdit()
wls:/base_domain/edit/ !> vt.removeTarget(tgt)
wls:/base_domain/edit/ !> tgt=getMBean('/Clusters/Cluster-0')
wls:/base_domain/edit/ !> vt.addTarget(tgt)
wls:/base_domain/edit/ !> activate()

仮想ターゲットの管理: RESTの例

RESTを使用した仮想ターゲットの作成の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティションの作成に関する項を参照してください。

特に、新しい仮想ターゲットのデフォルト値の表示に関する項を参照してください。

仮想ターゲットの構成: 関連タスクおよびリンク

次の追加情報を参照してください。

- ドメイン・パーティションの作成の詳細は、「ドメイン・パーティションの構成」

- ネットワーク・チャネルの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項を参照してください。

4 リソース・グループ・テンプレートの構成

この章では、リソース・グループ・テンプレートを構成する方法について説明します。この章では、適宜追加情報について、Oracle Fusion Middleware、Oracle WebLogic Server、Oracle CoherenceおよびOracle Traffic Directorのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章の内容は次のとおりです。

- リソース・グループ・テンプレートの構成: 概要

- リソース・グループ・テンプレートの作成: 主な手順およびWLSTの例

- リソース・グループ・テンプレートの構成: 主な手順およびWLSTの例

- リソース・グループ・テンプレートの削除: 主な手順およびWLSTの例

- リソース・グループ・テンプレートの構成: 関連タスクおよびリンク

リソース・グループ・テンプレートの構成: 概要

リソース・グループ・テンプレートは、複数のリソース・グループによってパターンとして使用されるデプロイ可能なリソースの名前付きのドメイン・レベル・コレクションです。特定のテンプレートを参照する各リソース・グループには、そのテンプレートに定義されているリソースの独自のランタイム・コピーが含まれます。

リソース・グループ・テンプレートは、複数テナント用にリソースを定義およびレプリケートする便利な方法です。リソース・グループ・テンプレートにより、アプリケーションとリソースの同じコレクションを複数のドメイン・パーティションにデプロイすることが非常に簡単になります。

リソース・グループ・テンプレートは、WebLogic Server Multitenant (MT)が同じアプリケーションとリソースを複数回(ドメイン・パーティションごとに1回ずつ)アクティブ化するSoftware-as-a-Service環境で特に役立ちます。そのようなリソースに関する情報のいくつかはすべてのドメイン・パーティションで同じになり、Java Message Service (JMS)キューの属性やデータベース接続の属性などのそのいくつかはパーティション間で異なります。

リソース・グループ・テンプレートは次の2つの方法で作成できます。

- 新しいリソース・グループ・テンプレートを作成します。これにより、リソース・グループ・テンプレートの基本構造が作成されます。次に、このリソース・グループ・テンプレートを必要に応じて編集する必要があります。

- Oracle WebLogic Server管理コンソールを使用している場合は、既存のリソース・グループ・テンプレートのクローン(コピー)を作成できます。構成は、テンプレートから新しいリソース・グループ・テンプレートにコピーされます。次に、リソース・グループ・テンプレートからの値を必要に応じて編集およびオーバーライドする必要があります。

この項には次のトピックが含まれます:

- リソース・グループ・テンプレートとリソース・グループ間の相違とは

- リソース・グループ・テンプレートとは

- リソース・グループ・テンプレートおよびオーバーライド

リソース・グループ・テンプレートとリソース・グループ間の相違とは

リソース・グループ・テンプレートとリソース・グループ間の主な相違の1つは、リソース・グループ・テンプレートにはターゲットがないことです。リソース・グループ・テンプレートは(場合によっては多数のパーティション内の)複数のリソース・グループによってパターンとしてのみ使用されることを目的としているため、ターゲット固有の情報は、ほとんどの場合リソース・グループに固有となります。

したがって、次のようになります。

- アプリケーションをリソース・グループ・テンプレートにデプロイする場合は、リソース・グループ・テンプレートがリソース・グループによって参照されるまで、アプリケーションを起動できません。

- リソース・グループ・テンプレートを開始または停止できません。

リソース・グループ・テンプレートとは

リソース・グループ・テンプレートは、ResourceGroupTemplateMBeanに基づき、次のリソースを含めることができます。

- 全般(名前)

- デプロイメント

- サービス

- Java Database Connectivity(JDBC)

- メッセージ

- メール・セッション

- 永続ストア

- 外部Java Naming and Directory (JNDI)プロバイダ

- OSGiフレームワーク

- 診断

- ノート

リソース・グループ・テンプレートおよびオーバーライド

リソース・オーバーライドによって、パーティション・レベルでリソースをカスタマイズできます。

リソース・グループ・テンプレートから導出されたリソース設定を次のようにオーバーライドします。

1. リソース・グループ・テンプレートを作成します。

2. 必要に応じて、アプリケーションをリソース・グループ・テンプレートにデプロイします。

3. 必要に応じて、リソース・グループ・テンプレートでサービスを定義します。

4. パーティションを作成してから、リソース・グループ・テンプレートを参照するリソース・グループを作成します。

5. リソース・グループのリソース・グループ・テンプレートからの値をオーバーライドします。

オーバーライド構成MBean、リソース・デプロイメント・プランおよびパーティション固有のアプリケーション・デプロイメント・プランを使用して、パーティションのリソース定義をオーバーライドできます。リソース・オーバーライドの詳細は、「リソース・オーバーライドの構成」を参照してください。アプリケーション・オーバーライドの詳細は、「パーティション・リソース・グループへのアプリケーションのデプロイ」を参照してください。

リソース・グループ・テンプレートの例

SaaS環境があり、特定のビジネス・アプリケーションの1つのインスタンスを3つの異なるパーティションで実行する必要があると仮定します。このビジネス・アプリケーションには1つのプラガブル・データベースが必要です。つまり、各アプリケーション・インスタンスには、他のアプリケーション・インスタンスから分離された独自のデータが必要であるため、パーティションごとに1つのプラガブル・データベースが必要です。

さらに、プラガブル・データベースの構成が、データベース名、ユーザー名およびパスワードを除き、3つのパーティションで同じであると仮定します。これらの値には、表4-1の値を使用するとします。

表4-1 プラガブル・データベースの例

PDB名

ユーザー名/パスワード

使用元

pdb1.example.com

pdbuser1/pdbuser1

Partition1

pdb2.example.com

pdbuser2/pdbuser2

Partition2

pdb3.example.com

pdbuser3/pdbuser3

Partition3

リソース・グループ・テンプレートを構成するには、次の手順に従います。

1. リソース・グループ・テンプレートを作成します。

2. 「サービス」→「JDBC」に移動します。

3. JDBCシステム・データ・ソースを作成します。この例の目的のために、汎用データ・ソースを作成します。

4. JDBCデータ・ソースの構成値を入力します。

5. 接続プロパティ用に、次の値を使用します。

このリソース・グループ・テンプレートを参照するリソース・グループでこれらの値をオーバーライドします。ただし、ここで初期値を入力すると、データベース接続をテストできます。

- データベース名を入力します。たとえば、表4-1のpdb1.example.comを入力します。

- データベース・ユーザー名を入力します。たとえば、表4-1のpdbuser1を入力します。

- パスワードを入力します。たとえば、表4-1のpdbuser1を入力します。

6. リソース・グループ・テンプレートに基づいたリソース・グループを使用して、表4-1の3つのパーティションを作成します。

7. Partition1では、リソース・グループ・テンプレートで正しい値を使用しているため、いずれのJDBCデータ・ソース値もオーバーライドする必要はありません。

8. Partition2およびPartition3では、データベース名、ユーザー名およびパスワードを表4-1の正しい値でオーバーライドします。

Oracle Enterprise Manager Fusion Middleware Controlを使用してこれを行うには、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverのリソース・オーバーライドに関する項の説明に従い、「ドメイン・パーティション」→「パーティション」→「リソース・オーバーライド」に移動します。

リソース・グループ・テンプレートの作成: 主な手順およびWLSTの例

新しいリソース・グループ・テンプレートを作成するには、次のようにします。

1. 「ドメイン」→「環境」→「リソース・グループ・テンプレート」に移動します。

2. 新しいリソース・グループ・テンプレートを作成します。この名前はドメイン内で一意にする必要があります。

これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループ・テンプレートの作成に関する項で説明しています。

最初のリソース・グループ・テンプレート構成は基本スケルトンで、使用する前に構成する必要があります。タスクには、JDBCシステム・データ・ソース、JMSサーバーおよびリソース、外部JNDIプロバイダなどの構成が含まれます。

詳細は、「リソース・グループ・テンプレートの構成: 主な手順およびWLSTの例」を参照してください。

リソース・グループの作成: WLSTの例

この例では、次の操作を実行しています。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

5. リソース・グループを作成します。

6. 仮想ターゲットをリソース・グループに追加します。

7. リソース・グループ・テンプレートを作成します。

8. リソース・グループをリソース・グループ・テンプレートに関連付けます。

9. 変更をアクティブ化します。

10. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

# Create Pep partition resource group, and resource group template
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('VirtualTarget-0')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> peprgt=domain.createResourceGroupTemplate('TestRGT')
wls:/base_domain/edit/ !> peprg.setResourceGroupTemplate(peprgt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)

リソース・グループ・テンプレートの構成: 主な手順およびWLSTの例

この項では、次のタスクを取り上げます。

- リソース・グループ・テンプレートのデプロイメント設定の構成

- リソース・グループ・テンプレートのサービス設定の構成

- リソース・グループ・テンプレートのノートの構成

リソース・グループ・テンプレートのデプロイメント設定の構成

リソース・グループ・テンプレートのデプロイメント設定を表示および定義するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 次のデプロイメント・アクションを実行できます。

- デプロイ

- 再デプロイ

- アンデプロイ

- デプロイメント・プランのフェッチ

3. 変更を保存します。

これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループ・テンプレートのデプロイメントの構成に関する項で説明しています。

詳細は、「アプリケーションのリソース・グループ・テンプレートへのデプロイ」を参照してください。

リソース・グループ・テンプレートのサービス設定の構成

この項では、次のタスクを取り上げます。

- リソース・グループ・テンプレートのJDBC設定の構成

- リソース・グループ・テンプレートのJMS設定の構成

- リソース・グループのメール・セッション設定の構成

- リソース・グループの永続ストア設定の構成

- リソース・グループの外部JNDIプロバイダ設定の構成

- リソース・グループの診断システム・モジュール設定の構成

リソース・グループ・テンプレートのJDBC設定の構成

このリソース・グループ・テンプレートに作成されたJDBCシステム・リソースの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「JDBC」に移動します。

リソース・グループの読取り専用のJDBC情報は、次のとおりです。

- 名前

- JNDI名

- タイプ

- アルゴリズム・タイプ

- 行プリフェッチ有効

- 行プリフェッチ・サイズ

- ストリーム・チャンク・サイズ

3. 必要に応じて、システム・データ・ソースを作成または削除します。

4. 変更を保存します。

詳細は、「JDBCの構成」を参照してください。

リソース・グループ・テンプレートのJMS設定の構成

この項では、次のタスクを取り上げます。

- JMSサーバー設定の構成

- SAFエージェント設定の構成

- JMSリソース設定の構成

- JMSモジュール設定の構成

- メッセージング・ブリッジの構成

- JMSブリッジ宛先の構成

- パス・サービスの構成

JMSサーバー設定の構成

このリソース・グループ・テンプレートに作成されたJMSサーバーの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「メッセージング」→「JMSサーバー」に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートにすでに構成されているJMSサーバーで使用できます。

- 名前

- ヘルス

- ヘルスの理由

- 永続ストア

- 一時的なテンプレート名

- 最大バイト数

- 最大メッセージ数

- 最大バイトしきい値

- 最小バイトしきい値

- 最大メッセージしきい値

3. 必要に応じて、JMSサーバーを作成または削除します。

4. 変更を保存します。

これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverメッセージングに関する項で説明しています。

詳細は、「メッセージングの構成」を参照してください。

SAFエージェント設定の構成

このリソース・グループ・テンプレートに作成されたストア・アンド・フォワード(SAF)エージェントの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「メッセージング」→「SAFエージェント」に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートに構成されているSAFエージェントで使用できます。

- 名前

- エージェント・タイプ

- 永続ストア

3. 必要に応じて、SAFエージェントを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のSAFエージェント設定の構成に関する項を参照してください。

詳細は、「メッセージングの構成」を参照してください。

JMSリソース設定の構成

リソース・グループ・テンプレートのリソース設定をモニターするには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「メッセージング」→「JMSリソース」に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートに構成されているJMSリソースで使用できます。

- 名前

- タイプ

- JMSモジュール名

- JNDI名

- サブデプロイメント

3. 必要に応じて、JMSリソースを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のSAFエージェント設定の構成に関する項を参照してください。

既存のJMSリソースの構成の詳細は、「メッセージングの構成」を参照してください。

JMSモジュール設定の構成

リソース・グループ・テンプレートのJMSモジュールを構成するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「メッセージング」→「JMSモジュール」→「JMSモジュール」に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートに構成されているJMSモジュールで使用できます。

- 名前

- キュー

- トピック

- 接続ファクトリ

- 分散キュー

- 分散トピック

- 外部サーバー

- 割当て制限

- SAFエラー・ハンドラ

- SAFインポート済宛先

- SAFリモート・コンテキスト

- テンプレート

- 共通分散キュー

- 共通分散トピック

- 宛先キー

- タイプ

3. 必要に応じて、JMSモジュールを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJMSモジュール設定の構成に関する項を参照してください。

詳細は、「メッセージングの構成」を参照してください。

メッセージング・ブリッジの構成

リソース・グループ・テンプレートのメッセージング・ブリッジ設定を構成するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「メッセージング」→「メッセージング・ブリッジ」に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートに構成されているメッセージング・ブリッジで使用できます。

- 名前

- ソース・ブリッジ宛先

- ターゲット・ブリッジ宛先

3. 必要に応じて、メッセージング・ブリッジを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のメッセージング・ブリッジの構成に関する項を参照してください。

詳細は、「メッセージングの構成」を参照してください。

JMSブリッジ宛先の構成

リソース・グループ・テンプレートのJMSブリッジ宛先設定を構成するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「メッセージング」→ブリッジ宛先に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートに構成されているJMSブリッジ宛先で使用できます。

- 名前

- アダプタのJNDI名

3. 必要に応じて、JMSブリッジ宛先を作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJMSブリッジ宛先の構成に関する項を参照してください。

詳細は、「メッセージングの構成」を参照してください。

パス・サービスの構成

リソース・グループ・テンプレートのパス・サービス設定を構成するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「メッセージング」→「パス・サービス」に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートに構成されているパス・サービスで使用できます。

- 名前

- 永続ストア

3. 必要に応じて、パス・サービスを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のパス・サービスの構成に関する項を参照してください。

詳細は、「メッセージングの構成」を参照してください。

リソース・グループのメール・セッション設定の構成

このリソース・グループ・テンプレートに作成されたメール・セッションの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「メール」に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートに構成されているメール・セッションで使用できます。

- 名前

- JNDI名

3. 必要に応じて、メール・セッションを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverメール・セッションに関する項を参照してください。

リソース・グループの永続ストア設定の構成

このリソース・グループ・テンプレートに作成された永続ストアの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「永続ストア」に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートに構成されている永続ストアで使用できます。

- 名前

- タイプ

3. 必要に応じて、永続ストアを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Server永続ストアに関する項を参照してください。

詳細は、「メッセージングの構成」を参照してください。

リソース・グループの外部JNDIプロバイダ設定の構成

このリソース・グループ・テンプレートに作成された外部JNDIプロバイダの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「外部JNDIプロバイダ」に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートに構成されている外部JNDIプロバイダで使用できます。

- 名前

- 初期コンテキスト・ファクトリ

- プロバイダURL

- ユーザー

- ターゲット

3. 必要に応じて、外部JNDIプロバイダを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Server外部JNDIプロバイダに関する項を参照してください。

詳細は、「JNDIの構成とプログラミング」を参照してください。

リソース・グループの診断システム・モジュール設定の構成

このリソース・グループ・テンプレートに作成された診断システム・モジュールの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループ・テンプレートを選択します。

2. 「サービス」→「診断」に移動します。

次の読取り専用情報は、このリソース・グループ・テンプレートに構成されている診断システム・モジュールで使用できます。

- 名前

- 説明

- ターゲット

3. 必要に応じて、診断システム・モジュールを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Server診断に関する項を参照してください。

詳細は、「パーティションのモニタリングおよびデバッグ」を参照してください。

リソース・グループ・テンプレートのノートの構成

リソース・グループ・テンプレートのノートを作成するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「ノート」に移動します。

3. ノートを入力します。

4. 変更を保存します。

リソース・グループ・テンプレートの構成: WLSTの例

この例では、次の操作を実行しています。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

5. リソース・グループを作成します。

6. 仮想ターゲットをリソース・グループに追加します。

7. リソース・グループ・テンプレートを作成します。

8. アプリケーションMySimpleEjbをリソース・グループ・テンプレートにデプロイします。

9. リソース・グループをリソース・グループ・テンプレートに関連付けます。

10. 変更をアクティブ化します。

11. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

# Create Pep partition resource group, and resource group template
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('VirtualTarget-0')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> peprgt=domain.createResourceGroupTemplate('TestRGT')
wls:/base_domain/edit/ !> deploy(appName='MySimpleEJB', path='c:/webservices/MySimpleEjb.jar', resourceGroupTemplate='TestRGT')
wls:/base_domain/edit/ !> peprg.setResourceGroupTemplate(peprgt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)

リソース・グループ・テンプレートの削除: 主な手順およびWLSTの例

リソース・グループ・テンプレートがリソース・グループによって参照されている場合は、このリソース・グループ・テンプレートを削除する前に、参照を削除する必要があります。

1. 削除するリソース・グループを選択します。

2. リソース・グループを削除します。

リソース・グループ・テンプレートの削除: WLSTの例

この例では、次の操作を実行しています。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

5. リソース・グループを作成します。

6. 仮想ターゲットをリソース・グループに追加します。

7. リソース・グループ・テンプレートを作成します。

8. リソース・グループをリソース・グループ・テンプレートに関連付けます。

9. リソース・グループ・テンプレートをリソース・グループから設定解除します。

10. リソース・グループ・テンプレートをドメインから削除します。

11. 変更をアクティブ化します。

12. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

# Create Pep partition resource group, and resource group template
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('VirtualTarget-0')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> peprgt=domain.createResourceGroupTemplate('TestRGT')
wls:/base_domain/edit/ !> peprg.setResourceGroupTemplate(peprgt)
wls:/base_domain/edit/ !> peprg.unSet('ResourceGroupTemplate')
wls:/base_domain/edit/ !> domain.destroyResourceGroupTemplate(peprgt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)

リソース・グループ・テンプレートの構成: 関連タスクおよびリンク

リソース・グループ・テンプレート関連の追加情報は、次の項を参照してください。

- WebLogic Server MTの主な概念

- 仮想ターゲットの構成

- リソース・グループの構成

- メッセージングの構成

5 セキュリティの構成

この章では、Oracle WebLogic Server Multitenant (MT)でセキュリティを構成する方法について説明します。この章では、適宜追加情報について、Oracle WebLogic Serverのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章では、『Oracle WebLogic Serverセキュリティの理解』で説明しているWebLogic Serverのセキュリティ概念やタスクの実用的な知識を有していることを前提としています。

この章の内容は次のとおりです。

- ドメイン・パーティションの新しいセキュリティ機能

- 管理アイデンティティ・ドメインの構成: 主な手順およびWLSTの例

- セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: 主な手順および例

- 「アイデンティティ・ドメイン対応プロバイダが必要」コントロールの設定: 主な手順

- ドメイン・パーティションへの直接接続: 主な手順およびWLSTの例

- パーティション管理者としてのセキュリティ・データの管理: 主な手順および例

- ドメイン・パーティションでのSSLの構成

- ドメイン・パーティションでのセキュリティの構成: 関連タスクおよびリンク

ドメイン・パーティションの新しいセキュリティ機能

WebLogic Server MTでは、従来のWebLogic Serverセキュリティ・サポートを次の2つの重要な方法で拡張しています。

- 複数のレルム。WebLogic Server MTでは、複数のアクティブなレルムをサポートし、異なるレルムに対して各パーティションを実行できます。
従来どおり、グローバル(ドメイン)レベルで使用されるアクティブなデフォルト・レルムは1つのみです。

- アイデンティティ・ドメイン。アイデンティティ・ドメインは、ユーザーおよびグループの論理ネームスペースであり、通常は、物理データ・ストア内のユーザーとグループの1つの個別セットを表します。アイデンティティ・ドメインを使用して、特定のパーティションに関連付けられているユーザーを識別します。

- パーティションに直接ログインする場合の構成および管理用の管理ロール。Fusion Middleware ControlおよびWebLogic Scripting Tool (WLST)を使用して、ドメイン・レベルにログインするのではなく、ドメイン・パーティションに直接接続できます。

これらの変更内容は、後続の項で説明されています。

ドメイン・パーティションのセキュリティ・レルム: 概要

『Oracle WebLogic Serverセキュリティの理解』のセキュリティ・レルムに関する項で説明しているように、セキュリティ・レルムにはWebLogic Serverリソースを保護するためのメカニズムが含まれます。各セキュリティ・レルムは、構成済みのセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーで構成されます。レルムを使用して、認証、認可、ロール・マッピング、資格証明マッピング、監査およびその他のサービスを構成します。

WebLogic Serverでは、従来、ドメイン構成で複数のレルムをサポートしていますが、特定の時間にアクティブになることができるレルム(通常、デフォルト・レルムまたは管理レルムと呼ばれる)は1つのみです。

一方、WebLogic Server MTでは、複数のアクティブなレルムをサポートし、異なるレルムに対して各パーティションを実行できるようになっています。

これは、パーティションが固有のセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロールおよびセキュリティ・ポリシーを持つことができることを意味します。ドメイン・パーティションのリソースとアプリケーションは、ドメイン・パーティションのセキュリティ・レルム内のユーザーのみが使用できます。他のテナントでは、リソースまたはアプリケーションを表示することもアクセスすることもできません。

注意:

パーティションでは、独立性や分離性を損なう結果となりますが、セキュリティ・レルムを共有できます。特に、パーティションの作成時にレルムを指定しなかった場合は、デフォルト・レルムがそのパーティションと共有され、そのパーティションとドメイン間でセキュリティが分離されません。

アイデンティティ・ドメイン: 概要

注意:

アイデンティティ・ドメインは、ユーザー・ストアでアイデンティティ・ドメインをサポートしている場合にのみ使用できるオプション機能です。アイデンティティ・ドメイン自体の構造、構成および管理は、WebLogic Serverにとって制御外であり、認識できません。

アイデンティティ・ストアの目的は、パーティションのユーザーがそのパーティションにアクセスできるようにする一方で、他のパーティションのユーザーはアクセスできないようにすることです。

アイデンティティ・ドメインでは、異なるパーティションに関連付けられているユーザーを区別します。パーティションに関連付けられている一連のユーザーを識別するアイデンティティ・ドメインを使用して、パーティションを構成できます。アクセス・ポリシーにより、これらのユーザーはパーティションにアクセスできますが、他のアイデンティティ・ドメインのユーザーはアクセスできません。

アイデンティティ・ドメイン名は、現在の環境でわかりやすい名前にする必要があります。

一般に、パーティションとアイデンティティ・ドメイン間には1対1のマッピングがあります。ただし、複数のパーティションで同じアイデンティティ・ドメインを使用することは可能です。結果として、これらのパーティションのユーザー間の区別がなくなり、環境によっては不適切である可能性があります。

アイデンティティ・ドメインのタイプ

次の2つのタイプのアイデンティティ・ドメインがあります。

- 管理アイデンティティ・ドメイン: ドメイン内のデフォルト・セキュリティ・レルムのアイデンティティ・ドメイン。管理アイデンティティ・ドメインの目的は、グローバル・ドメイン・ユーザーとパーティション・ユーザーを区別することです。WebLogic Serverシステム管理者は、この管理アイデンティティ・ドメインに属しています。
管理アイデンティティ・ドメインは、Oracle WebLogic Server管理コンソールの「ドメイン」 > 「セキュリティ」ページに表示されます。

- プライマリ・アイデンティティ・ドメイン: パーティション用に構成されたプライマリ・アイデンティティ・ドメイン。プライマリ・アイデンティティ・ドメインは、パーティション・ユーザーの認証時およびパーティション・リソースの所有権を判別する場合に、デフォルトのアイデンティティ・ドメインとして使用されます。
このプライマリ・アイデンティティ・ドメインは、WebLogic Server管理コンソールの認証プロバイダのプロバイダ固有のページに表示されます。

アイデンティティ・ドメインのユーザー・ストアの表現には、基礎となるテクノロジでサポートされるすべての表現を使用できます。次に例を示します。

- アイデンティティ・ドメインごとに個別のLightweight Directory Access Protocol (LDAP)インスタンスを作成できます。

- アイデンティティ・ドメイン・フィールドは、データベース内のユーザー・レコードに追加できます。

- アイデンティティ・ドメインは、単一のOracle Internet Directory (OID)インスタンスの「ユーザーとグループ」階層内の異なるサブツリーとして表されます。

パーティション管理者がパーティション内のレルム・セキュリティ・データにアクセスできるようにするには、システム管理者がそのレルムに対してマネージメント・アイデンティティ・ドメインを構成する必要があります。マネージメント・アイデンティティ・ドメインは、プライマリ・アイデンティティ・ドメイン、管理アイデンティティ・ドメイン、またはオーセンティケータがレルムでサポートしている別のアイデンティティ・ドメインにできます。このマネージメント・アイデンティティ・ドメインと一致するアイデンティティ・ドメインを持つパーティション管理者は、一部のセキュリティMBeanにアクセスし、そのMBeanに対して管理操作を呼び出すことができます。管理アイデンティティ・ドメインをマネージメント・アイデンティティ・ドメインにすることもできますが、システム管理者はセキュリティ・レルムを管理する権限をすでに持っているため、その必要はありません。

デフォルトのアイデンティティ・ドメインの値

WebLogic Server MTは、次のようなデフォルトの管理アイデンティティ・ドメインおよびデフォルトのプライマリ・アイデンティティ・ドメインを作成します。

- 管理アイデンティティ・ドメイン: WebLogic Server MTは、デフォルト・セキュリティ・レルムにidd_DOMAINというデフォルトのアイデンティティ・ドメインを作成します。管理アイデンティティ・ドメインは、本番モードで最初のパーティションをドメインに作成すると作成されます。
開発モードで最初のパーティションをドメインに作成した場合、デフォルト値はnullになります。(この場合のみ、nullが有効なアイデンティティ・ドメインとみなされます。)

- プライマリ・アイデンティティ・ドメイン: WebLogic Server MTは、パーティションの作成時に、iddの接頭辞が付いたパーティションの名前を使用してパーティションにデフォルトのアイデンティティ・ドメインを作成します。
このプライマリ・アイデンティティ・ドメインは、WebLogicのデフォルト・オーセンティケータ・プロバイダ用のプロバイダ固有のWebLogic Server管理コンソール・ページに表示されます。

デフォルトのプライマリ・アイデンティティ・ドメインは、組込みLDAPで使用するデフォルト・オーセンティケータの便利な機能です。テストおよび内部開発での使用が目的で、本番環境向けではありません。組込みLDAPでは、アイデンティティ・ドメインを実際には使用しません。

構成および管理用の管理ロール

「ドメイン・パーティションへの直接接続: 主な手順およびWLSTの例」の説明に従い、Fusion Middleware ControlおよびWLSTを使用して、ドメイン・レベルでログインするのではなく、ドメイン・パーティションに直接接続できます。

表5-1に、パーティション環境でのWebLogic Server管理ロールの構成機能と管理機能を示します。

表5-1 構成および管理用の管理ロール

ロール

ドメインへのログイン

パーティションへのログイン

管理者

パーティションの構成および管理を含む、ドメイン・リソースに対するフル・コントロール。

レルムMBeanに関するマネージメント・アイデンティティ・ドメインの属性を構成します。

パーティションが所有するMBeanへの書込みアクセス。

所有するPartitionMBean.Realm属性とPartitionMBean.PrimaryIdentityDomain属性への読取り専用アクセス。

所有するRealmMBeanおよびその子への読取り専用アクセス。

マネージメント・アイデンティティ・ドメインのパーティション管理者:

- 独自のパーティション内の一部のセキュリティおよびレルム・ランタイムMBeanに対してメソッドを呼び出すことができます。

- 独自のパーティション内のセキュリティ・プロバイダMBeanに対する一部の管理操作でメソッドを呼び出すことができます。

デプロイヤ

リソースをドメインおよびパーティション内に構成し、そのドメインおよびパーティション内でアプリケーションをデプロイ、再デプロイ、アンデプロイ、起動、停止します。

リソースをパーティション内に構成し、そのパーティション内でアプリケーションをデプロイ、再デプロイ、アンデプロイ、起動、停止します。

オペレータ

サーバー、パーティション、リソース・グループを起動/停止します。

パーティションおよびリソース・グループを起動/停止します。

モニター

ドメインおよびパーティションのリソースへの読取り専用アクセス。

パーティション・リソースへの読取り専用アクセス。

管理アイデンティティ・ドメインの構成: 主な手順およびWLSTの例

管理アイデンティティ・ドメインは、WebLogic Server管理コンソールの「ドメイン」 > 「セキュリティ」ページに表示されます。

WebLogic Server管理者の資格証明のみを格納するデフォルト・オーセンティケータが含まれたデフォルト・セキュリティ・レルムを使用する場合は、デフォルト値idd_DOMAINをそのまま使用できます。詳細は、「セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: 主な手順および例」を参照してください。

ただし、デフォルト・レルムに選択したユーザー・ストアがアイデンティティ・ドメインをサポートし、アイデンティティ・ドメインをWebLogic Server管理者用に構成している場合は、管理アイデンティティ・ドメイン値と一致する認証プロバイダをデフォルト・レルムに少なくとも1つ構成する必要があります。

WebLogic Server管理コンソールを使用する場合:

1. デフォルト・レルムの認証プロバイダを選択し、既存の管理アイデンティティ・ドメインを指定します。

a. ナビゲーション・ペインで、「セキュリティ・レルム」を選択します。

b. デフォルトのセキュリティ・レルムを選択します。

c. 「プロバイダ」ページを選択します。

d. 認証プロバイダを選択します。

e. 「プロバイダ固有」ページを選択します。

f. 有効な管理アイデンティティ・ドメインの名前を「アイデンティティ・ドメイン」フィールドに入力します。

g. 変更内容を保存します。

2. 「ドメイン」 > 「セキュリティ」ページに移動し、「管理アイデンティティ・ドメイン」値を管理アイデンティティ・ドメインの名前に変更します。

3. 変更内容を保存します。

4. 管理サーバーを再起動します。

管理アイデンティティ・ドメインの構成: WLSTの例

この例では、次の操作を実行しています。

1. ドメインMBeanを取得します。

2. ドメインのセキュリティ構成を取得します。

3. セキュリティ構成の管理アイデンティティ・ドメインを設定します。

4. セキュリティ構成のデフォルト・レルムを取得します。

5. レルムのデフォルトの認証プロバイダをルックアップします。

6. デフォルトの認証プロバイダにアイデンティティ・ドメインを設定します。

注意:

管理サーバーを再起動する必要があります。管理アイデンティティ・ドメインの値の設定は、動的でない変更であるため、サーバーを再起動する必要があります。

edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')

wls:/base_domain/edit/ !> ADMIN_IDD = "Admin-idd"
wls:/base_domain/edit/ !> secure=domain.getSecurityConfiguration()
wls:/base_domain/edit/ !> secure.setAdministrativeIdentityDomain(ADMIN_IDD)
wls:/base_domain/edit/ !> realm = secure.getDefaultRealm()
wls:/base_domain/edit/ !> defAtn = realm.lookupAuthenticationProvider('DefaultAuthenticator')
wls:/base_domain/edit/ !> defAtn.setIdentityDomain(ADMIN_IDD)

セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: 主な手順および例

セキュリティ・レルムを作成する必要はありません。パーティションでは、セキュリティ・レルムを共有したり、デフォルト・レルムを使用することができます。ただし、ベスト・プラクティスは、パーティションごとにセキュリティ・レルムを作成することです。このことは、特に、アイデンティティ・ドメインを使用してパーティション間を分離する場合に該当します。

ユーザー・ストアでアイデンティティ・ドメインがサポートされている場合は、この項の説明に従って、プライマリ・アイデンティティ・ドメインおよびマネージメント・アイデンティティ・ドメインを構成します。

次の手順を実行して、セキュリティ・レルムおよびアイデンティティ・ドメインをドメイン・パーティションに構成します。一部の手順でWebLogic Server管理コンソールが必要となることに注意してください。

1. セキュリティ・レルムを作成します。名前はドメイン内で一意である必要があります。
Fusion Middleware Controlを使用する場合は、「WebLogicドメイン」 > 「セキュリティ」 > 「セキュリティ・レルム」に移動します。デフォルト・プロバイダが新しいレルムに自動的に作成されます。

WebLogic Server管理コンソールを使用する場合は、ナビゲーション・ペインで「セキュリティ・レルム」を選択します。多くの場合、デフォルト・プロバイダを新しいレルムに作成するオプションを選択することが、最も便利です。

2. パーティション固有のユーザーをセキュリティ・レルムに追加します。
Fusion Middleware Controlを使用する場合は、「WebLogicドメイン」 > 「セキュリティ」 > 「ユーザーとグループ」に移動します。作成したセキュリティ・レルムを選択し、「ユーザー」ページと「グループ」ページで「作成」をクリックして、ユーザーとグループをレルムに追加します。

WebLogic Server管理コンソールを使用する場合は、ナビゲーション・ペインで「セキュリティ・レルム」を選択します。作成したセキュリティ・レルムを選択してから、「ユーザーとグループ」ページを選択します。「ユーザー」ページと「グループ」ページで「新規」をクリックして、ユーザーとグループをレルムに追加します。

3. 『Oracle WebLogic Server管理コンソール・オンライン・ヘルプ』のセキュリティ・プロバイダの管理に関する項の説明に従って、プロバイダをセキュリティ・レルムに構成します。
WebLogic Server管理コンソールでこの手順を実行します。

4. オプションで、作成した認証プロバイダを選択し、既存のアイデンティティ・ドメインを指定します。アイデンティティ・ドメインは、ユーザー・ストアでアイデンティティ・ドメインをサポートしている場合にのみ使用できるオプション機能です。
WebLogic Server管理コンソールでこの手順を実行します。

a. 「プロバイダ固有」ページを選択します。

b. 「アイデンティティ・ドメイン」フィールドに、有効なアイデンティティ・ドメインの名前を入力します。

c. 変更内容を保存します。

5. 「ドメイン・パーティションの構成」の説明に従ってパーティションを後で作成する場合、またはドメインの構成ウィザードを使用してドメインを作成したときにパーティションを作成した場合、次のようにします。

a. 作成したセキュリティ・レルムを指定します。
WebLogic Server管理コンソールを使用して、ドメインの構成ウィザードで作成したパーティションを構成する場合は、「パーティション」 > 「構成」 > 「一般」ページの「レルムの使用」フィールドでセキュリティ・レルムを選択します。

b. 認証プロバイダに設定したアイデンティティ・ドメインを指定します。
Fusion Middleware Controlを使用してドメイン・パーティションを作成している場合は、「ドメイン・パーティションの作成: 一般」ページで、プライマリ・アイデンティティ・ドメインを指定します。値を指定しない場合、WebLogic Server MTでは、パーティションの作成時にiddの接頭辞が付いたパーティションの名前を使用して、そのパーティションのデフォルトのアイデンティティ・ドメインを作成します。

WebLogic Server管理コンソールを使用してドメイン・パーティションを作成する場合、WebLogic Server MTでは、iddの接頭辞が付いたパーティションの名前を使用して、デフォルトのアイデンティティ・ドメインを作成します。パーティションを作成してから、変更内容をアクティブ化するまでの間に、「パーティション」 > 「構成」 > 「一般」ページに移動して、「プライマリ・アイデンティティ・ドメイン」フィールドのデフォルトの名前を実際のアイデンティティ・ドメイン名に変更します。

c. レルムのマネージメント・アイデンティティ・ドメインの属性に、パーティションのプライマリ・アイデンティティ・ドメインに使用したものと同じ値を設定します。
WebLogic Server管理コンソールでこの手順を実行します。

ナビゲーション・ペインで「セキュリティ・レルム」を選択します。パーティションのセキュリティ・レルムを選択し、「構成」 > 「一般」を選択して、「詳細」をクリックします。「管理アイデンティティ・ドメイン」フィールドに、パーティションに対して構成したプライマリ・アイデンティティ・ドメインの名前を入力し、「保存」をクリックします。

セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: WLSTの例

この例では、次の操作を実行しています。

1. ドメインMBeanを取得します。

2. ドメインのセキュリティ構成を取得します。

3. セキュリティ構成の管理アイデンティティ・ドメインを設定します。

4. セキュリティ構成のデフォルト・レルムを取得します。

5. レルムのデフォルトの認証プロバイダをルックアップします。

6. デフォルトの認証プロバイダにアイデンティティ・ドメインを設定します。

7. パーティションの新しいレルムを作成します。

8. 新しいレルムで必要なセキュリティ・プロバイダを作成します。

9. ドメイン・パーティションを作成します。

10. 仮想ターゲットを作成します。

11. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

12. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

13. パーティションのセキュリティ・レルムを設定します。

14. パーティションのプライマリ・アイデンティティ・ドメインを設定します。

15. パーティションのマネージメント・アイデンティティ・ドメインを設定します。

16. リソース・グループを作成します。

17. 仮想ターゲットをリソース・グループに追加します。

18. 変更をアクティブ化します。

19. パーティションを起動します。

注意:

パーティションを起動する前に、管理サーバーを再起動する必要があります。管理アイデンティティ・ドメインの値の設定は、動的でない変更であるため、サーバーを再起動する必要があります。

edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')

wls:/base_domain/edit/ !> ADMIN_IDD = "Admin-idd"
wls:/base_domain/edit/ !> secure=domain.getSecurityConfiguration()
wls:/base_domain/edit/ !> secure.setAdministrativeIdentityDomain(ADMIN_IDD)
wls:/base_domain/edit/ !> realm = secure.getDefaultRealm()
wls:/base_domain/edit/ !> defAtn = realm.lookupAuthenticationProvider('DefaultAuthenticator')
wls:/base_domain/edit/ !> defAtn.setIdentityDomain(ADMIN_IDD)

wls:/base_domain/edit/ !> partrealm=secure.createRealm('partrealm')

wls:/base_domain/edit/ !> partrealm.createAuthenticationProvider("DefaultAuthenticator","weblogic.security.providers.authentication.DefaultAuthenticator")
wls:/base_domain/edit/ !> defAtnP = partrealm.lookupAuthenticationProvider('DefaultAuthenticator')
wls:/base_domain/edit/ !> defAtnP.setIdentityDomain('partID')
wls:/base_domain/edit/ !> partrealm.createAuthenticationProvider("DefaultIdentityAsserter","weblogic.security.providers.authentication.DefaultIdentityAsserter")
wls:/base_domain/edit/ !> partrealm.createAuthorizer("XACMLAuthorizer","weblogic.security.providers.xacml.authorization.XACMLAuthorizer")
wls:/base_domain/edit/ !> partrealm.createRoleMapper("XACMLRoleMapper","weblogic.security.providers.xacml.authorization.XACMLRoleMapper")
wls:/base_domain/edit/ !> partrealm.createAdjudicator("DefaultAdjudicator","weblogic.security.providers.authorization.DefaultAdjudicator")
wls:/base_domain/edit/ !> partrealm.createCredentialMapper("DefaultCredentialMapper","weblogic.security.providers.credentials.DefaultCredentialMapper")
wls:/base_domain/edit/ !> cert = partrealm.createCertPathProvider("WebLogicCertPathProvider","weblogic.security.providers.pk.WebLogicCertPathProvider")
wls:/base_domain/edit/ !> partrealm.setCertPathBuilder(cert)
wls:/base_domain/edit/ !> partrealm.setManagementIdentityDomain('partID')
wls:/base_domain/edit/ !> pv = partrealm.createPasswordValidator('SystemPasswordValidator','com.bea.security.providers.authentication.passwordvalidator.SystemPasswordValidator')
wls:/base_domain/edit/ !> pv.setMinPasswordLength(8)
wls:/base_domain/edit/ !> pv.setMinNumericOrSpecialCharacters(1)

wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('somehost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peppart.setRealm(partrealm)
wls:/base_domain/edit/ !> peppart.setPrimaryIdentityDomain('partID')
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)

セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: RESTの例

Representational State Transfer (REST)からのドメイン・パーティションの作成の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティションの作成に関する項を参照してください。

この例では、次を含むパーティションの作成方法を示します。

- パーティションの新しいセキュリティ・レルム(セキュリティ・プロバイダ、プライマリ・アイデンティティ・ドメインおよびマネージメント・アイデンティティ・ドメインを含む)。

- アプリケーションが実行されるクラスタの仮想ターゲット。

- デプロイヤ・ロールがシステム・リソースを作成し、アプリケーションをデプロイできるようにするための、管理サーバーの仮想ターゲット。

- 各仮想ターゲットのリソース・グループ。

- 管理者、デプロイヤ、モニターおよびオペレータ・ロールのパーティション・ユーザー。

パーティションに対してマネージメント・アイデンティティ・ドメインを設定する方法を示す例は、「パーティション管理者としてのユーザーおよびグループの管理: RESTの例」を参照してください

「アイデンティティ・ドメイン対応プロバイダが必要」コントロールの設定: 主な手順

次のWebLogic Serverセキュリティ・プロバイダは、アイデンティティ・ドメインが構成されている環境で正しく機能するために、アイデンティティ・ドメイン対応である必要があります。

- ロール・マッピング

- Authorization

- 資格証明マッピング

- 監査

たとえば、アイデンティティ・ドメインを認識しない認可プロバイダは、同じ名前を持つがアイデンティティ・ドメインは異なる2人のユーザーを適切に区別できないため、認可上の有効な決定を行うことができません。

標準のWebLogic Serverセキュリティ・プロバイダは、アイデンティティ・ドメインに対応しています。ただし、デフォルト・ロール・マッパーやデフォルト認可プロバイダなどの非推奨プロバイダはアイデンティティ・ドメインに対応していません。

アイデンティティ・ドメインをユーザー・ストアに構成している場合は、「アイデンティティ・ドメイン対応プロバイダが必要」コントロールを設定して、アイデンティティ・ドメイン対応プロバイダの使用を強制できます。このコントロールの設定では、アイデンティティ・ドメインが構成されていない場合でも、アイデンティティ・ドメインをサポートするロール・マッピング、認可、資格証明マッピングおよび監査のプロバイダのみを使用することを指定します。

WebLogic Server管理コンソールを使用する場合:

1. 「ドメイン」 > 「セキュリティ」ページに移動します。

2. 「アイデンティティ・ドメイン対応プロバイダが必要」コントロールを設定します。

3. 変更を保存します。

ドメイン・パーティションへの直接接続: 主な手順およびWLSTの例

Fusion Middleware ControlとWLSTのどちらを使用しても、ドメイン・レベルにログインすることなく、ドメイン・パーティションに直接接続できます。このことを実行すると、指定したユーザー名は、そのパーティションのセキュリティ・レルムおよびマネージメント・アイデンティティ・ドメインと照合して検証されます。

Fusion Middleware Controlを使用してパーティションにログインするには、次のようにします。

1. WebブラウザにURLを入力します。次に例を示します。
http://host1.example.com:7001/em

2. パーティション・ユーザーの名前とパスワードを入力し、「パーティションへのログイン」をクリックします。

3. 「パーティション名」フィールドにパーティションの名前を入力し、「サインイン」をクリックします。
パーティションに直接ログインした場合のWebLogic Server管理ロールの構成機能と管理機能については、表5-1を参照してください。

ドメイン・パーティションへの直接接続: WLSTの例

WLSTを使用して、ドメイン・レベルにログインするのではなく、ドメイン・パーティションに直接接続できます。これを行う場合、次のことに注意してください。

- 指定したユーザー名は、そのパーティションのセキュリティ・レルムと照合して検証されます。
パーティションに直接ログインした場合のWebLogic管理ロールの構成機能と管理機能については、表6-1を参照してください。

- MBean階層の初期ビューは、パーティション固有です。

WLST構文は次のとおりです。t3接続のみがサポートされていることに注意してください。

MBean階層の初期ビューは、パーティション固有です。

パーティション名を使用した場合

wls:/offline> connect('username','password',"t3://system:port/partitions/partition-name")

次に例を示します。

wls:/offline> connect('weblogic','password',"t3://somehost:7001/partitions/Partition-0")
Connecting to t3://somehost:7001/partitions/Partition-0 with userid
weblogic ...
Successfully connected to partition "Partition-0".
wls:/base_domain/serverConfig/Partitions/Partition-0>

仮想ターゲットを使用した場合

パーティションに構成された仮想ターゲットに一致するURLを指定します。たとえば、ホスト名のない仮想ターゲットがあり、uriPrefixが/fooの場合、次のように接続できます。

connect('weblogic','password',"t3://somehost:7001/foo")

パーティション固有のMBean階層

接続後のMBean階層は、次のようにパーティション固有です。

wls:/base_domain/serverConfig/Partitions/Partition-0> ls()
dr--   AvailableTargets
dr--   CoherencePartitionCacheConfigs
dr--   DataSourceForJobScheduler
dr--   DataSourcePartition
dr--   DefaultTargets
dr--   JDBCSystemResourceOverrides
dr--   JMSSystemResourceOverrides
dr--   JTAPartition
dr--   MailSessionOverrides
dr--   ManagedExecutorServiceTemplates
dr--   ManagedScheduledExecutorServiceTemplates
dr--   ManagedThreadFactoryTemplates
dr--   PartitionLog
dr--   PartitionWorkManager
dr--   PartitionWorkManagerRef
dr--   ResourceGroups
dr--   ResourceManager
dr--   ResourceManagerRef
dr--   SelfTuning
dr--   SystemFileSystem
dr--   WebService

-r--   BatchJobsExecutorServiceName                 null
-r--   DataSourceForJobScheduler                    null
-r--   GracefulShutdownTimeout                      0
-r--   IgnoreSessionsDuringShutdown                 false
-r--   JobSchedulerTableName                        WEBLOGIC_TIMERS
-r--   MaxConcurrentLongRunningRequests             50
-r--   MaxConcurrentNewThreads                      50
-r--   Name                                         Partition-0
-r--   ParallelDeployApplicationModules             false
-r--   ParallelDeployApplications                   true
-r--   PartitionID                                  085b48c2-6d70-434e-8200-f4eb
f28ca3a0
-r--   PartitionLifeCycleTimeoutVal                 120
-r--   PartitionWorkManager                         null
-r--   PartitionWorkManagerRef                      null
-r--   PrimaryIdentityDomain                        idd_Partition-0
-r--   RCMHistoricalDataBufferLimit                 250
-r--   ResourceDeploymentPlanPath                   null
-r--   ResourceManager                              null
-r--   ResourceManagerRef                           null
-r--   StartupTimeout                               0
-r--   Type                                         Partition
-r--   UploadDirectoryName                          C:\Oracle\Middleware\Oracle_
Home\user_projects\domains\base_domain/partitions/Partition-0/system\servers\Adm
inServer\upload\

パーティション管理者としてのセキュリティ・データの管理: 主な手順および例

パーティション管理者は、マネージメント・アイデンティティ・ドメインのメンバーとしてパーティションにログインまたは接続することによって、そのパーティションに関連付けられているセキュリティ・レルム・データ(ユーザーとグループ、資格証明マップ、ロール、ポリシーなど)を管理できます。このリリースでは、パーティション管理者はレルムの構成を変更できません。

注意:

パーティション管理者用にセキュリティ管理機能を有効にする場合、システム管理者は、レルムに対するマネージメント・アイデンティティ・ドメインの属性をプライマリ・アイデンティティ・ドメインと同じ値に設定する必要があります。「セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: 主な手順および例」を参照してください。

Fusion Middleware Controlで、パーティション管理者はユーザーおよびグループを管理できます。サポートされているMBeanに対してその他のセキュリティ管理操作を呼び出すには、WLST、REST APIまたはJMXを使用できます。

プロセスの概要を次に示します。

1. システム管理者は、レルムに対してマネージメント・アイデンティティ・ドメインを構成します。このマネージメントIDDと一致するアイデンティティ・ドメインを持つパーティション管理者は、セキュリティ・ランタイムMBean操作を呼び出してレルムの動作を制御できます。次に例を示します。

- システム管理者は、値idd-DOMAINを使用して、セキュリティ構成MBeanに対する管理アイデンティティ・ドメインを構成します。

- システム管理者は、ドメイン内にパーティションPartition1を構成します。パーティションMBeanに構成されているプライマリ・アイデンティティ・ドメインの値はidd-Partition1です。Partition1に対して認証されるユーザーはidd-Partition1アイデンティティ・ドメインに属します。

- システム管理者は、ドメイン内でPartition1レルムを構成し、値idd-Partition1を使用して、レルムMBeanに対するマネージメント・アイデンティティ・ドメインを構成します。

- システム管理者は、パーティション管理ユーザーを作成し、Administratorsグループに割り当てます。

- アイデンティティ・ドメインidd-DOMAINを持つユーザー(システム管理者など)およびアイデンティティ・ドメインidd-Partition1を持つユーザー(パーティション管理者など)は、レルムに含まれているレルムMBeanおよびセキュリティ・プロバイダMBeanに対するセキュリティ管理操作にアクセスできます。

2. パーティション管理者は、Fusion Middleware Controlを使用してユーザーおよびグループを管理できます。

3. パーティション管理者は、パーティションMBeanレルムの属性を使用してレルムに移動できます。

4. パーティション管理者は、レルムMBeanプロバイダ関連の属性を使用してセキュリティ・プロバイダに移動できます。

5. パーティション管理者は、セキュリティ・プロバイダMBeanで一部のメソッドを呼び出すことができます。パーティション管理者が使用可能なセキュリティ・プロバイダのMBean混合インタフェースのリストは、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のセキュリティMBeanに関する項で表6-3を参照してください。

複数のパーティションが1つのレルムを参照する共有レルム・シナリオでは、システム管理者は、いずれかのパーティションのプライマリ・アイデンティティ・ドメインと一致するマネージメント・アイデンティティ・ドメインを構成します。この場合、デフォルトでは、該当するパーティションのユーザーのみがセキュリティ管理操作にアクセスできます。システム管理者は、特定のマネージメント・アイデンティティ・ドメインをサポートする個別のオーセンティケータを構成することもでき、この場合、マネージメント・アイデンティティ・ドメインを認証および指定するすべてのパーティションのユーザーがセキュリティ管理操作にアクセスできます。

表5-2に、パーティション管理者がパーティションに接続してMBean操作を呼び出すことができるセキュリティ管理パッケージを示します。

表5-2 パーティション管理者がアクセス可能なセキュリティ・パッケージ

パッケージ

説明

weblogic.management.security

WebLogicセキュリティ・レルムでセキュリティ・プロバイダを制御およびモニターするためのインタフェースとクラスを提供します。

weblogic.management.security.audit

WebLogicセキュリティ・レルムで監査セキュリティ・プロバイダを制御およびモニターするためのインタフェースとクラスを提供します。

weblogic.management.security.authentication

WebLogicセキュリティ・レルムで認証セキュリティ・プロバイダを制御およびモニターするためのインタフェースとクラスを提供します。

weblogic.management.security.authorization

WebLogicセキュリティ・レルムで認可、裁決およびロール・マッピング・セキュリティ・プロバイダを制御およびモニターするためのインタフェースとクラスを提供します。

weblogic.management.security.credentials

WebLogicセキュリティ・レルムで資格証明マッピング・セキュリティ・プロバイダを制御およびモニターするためのインタフェースとクラスを提供します。

weblogic.management.security.pk

WebLogicセキュリティ・レルムで証明書パス・セキュリティ・プロバイダを制御およびモニターするためのインタフェースとクラスを提供します。

weblogic.management.utils

WebLogicセキュリティ・レルムでセキュリティ・プロバイダから返されたデータのリストを示すインタフェースとクラスを提供します。

JMXを使用してセキュリティ・レルムを管理する方法の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXでのセキュリティ・レルムの管理に関する項を参照してください。

パーティション管理者としてのユーザーおよびグループの管理: Fusion Middleware Controlの例

Fusion Middleware Controlを使用してユーザーおよびグループを管理するには、次のようにします。

1. パーティション管理者としてパーティションにログインします。パーティション管理者は、パーティション・レルムに対して設定されたマネージメント・アイデンティティ・ドメインに属している必要があります。

2. 「ドメイン・パーティション」メニューから、「セキュリティ」、「ユーザーとグループ」の順に選択します。

3. ユーザーを作成またはモニターするには、「ユーザー」タブをクリックします(まだ選択されていない場合)。

- 新規ユーザーを作成するには、「作成」をクリックします。「ユーザーの作成」ページで、ユーザーの名前、説明、プロバイダおよびパスワードを入力し、「作成」をクリックします。

- 既存のユーザーの設定を編集するには、表でユーザー名を選択します。ユーザーの設定ページで、必要に応じて「一般設定」、「パスワード」、「属性」および「グループ」を編集し、「保存」をクリックします。

4. グループを作成またはモニターするには、「グループ」タブをクリックします。

- 新規グループを作成するには、「作成」をクリックします。「グループの作成」ページで、グループの名前、説明およびプロバイダを入力し、「作成」をクリックします。

- 既存のグループの設定を編集するには、表でグループ名を選択します。グループの設定ページで、必要に応じてそのグループの「一般設定」および「メンバーシップ」を編集し、「保存」をクリックします。

パーティション管理者としての新規ユーザーの作成: WLSTの例

次の例は、パーティション管理者としてパーティションPartition1にログインし、レルム・パーティションおよび認証プロバイダPartition1Realm/auth_provider2)に接続し、使用可能な操作をリストし、新規ユーザーをレルムに追加する方法を示しています。

1. 「ドメイン・パーティションへの直接接続: 主な手順およびWLSTの例」の説明に従い、パーティション管理者P1Adminとしてパーティションに接続します。

次に例を示します。

wls:/offline> connect('P1Admin','password','t3://somehost:7001/partitions/Partition1')
Connecting to t3://somehost:7001/partitions/Partition1 with userid P1Admin ...
Successfully connected to partition "Partition1".

2. パーティション・レルムの認証プロバイダに移動します。

次に例を示します。

wls:/base_domain/serverConfig/Partitions/Partition1> cd ("Realm/Partition1Realm")
wls:/base_domain/serverConfig/Partitions/Partition1/Realm/Partition1Realm>
cd("AuthenticationProviders/auth_provider2")

3. MBeanに対して使用可能な操作をリストします。

次に例を示します。

wls:/base_domain/serverConfig/Partitions/Partition1/Realm/Partition1Realm/AuthenticationProviders/auth_provider2> ls('o')

-r-x   addMemberToGroup                             Void : String(groupName),String(memberUserOrGroupName)
-r-x   advance                                      Void : String(cursor)
-r-x   changeUserPassword                           Void : String(userName),String(oldPassword),String(newPassword)

-r-x   close                                        Void : String(cursor)
-r-x   createGroup                                  Void : String(groupName),String(description)
-r-x   createUser                                   Void : String(userName),String(password),String(description)
-r-x   exportData                                   Void : String(format),String(filename),java.util.Properties
-r-x   getCurrentName                               String : String(cursor)
-r-x   getGroupDescription                          String : String(groupName)
-r-x   getSupportedUserAttributeType                javax.management.openmbean.OpenType : String(userAttributeName)

-r-x   getUserAttributeValue                        Object : String(userName),String(userAttributeName)
-r-x   getUserDescription                           String : String(userName)
-r-x   groupExists                                  Boolean : String(groupName)
-r-x   haveCurrent                                  Boolean : String(cursor)
-r-x   importData                                   Void : String(format),String(filename),java.util.Properties
-r-x   isMember                                     Boolean : String(parentGroupName),String(memberUserOrGroupName),Boolean(recursive)
-r-x   isUserAttributeNameSupported                 Boolean : String(userAttributeName)
-r-x   listAllUsersInGroup                          String[] : String(groupName),String(userNameWildcard),Integer(maximumToReturn)
-r-x   listGroupMembers                             String : String(groupName),String(memberUserOrGroupNameWildcard),Integer(maximumToReturn)
-r-x   listGroups                                   String : String(groupNameWildcard),Integer(maximumToReturn)
-r-x   listMemberGroups                             String : String(memberUserOrGroupName)
-r-x   listUsers                                    String : String(userNameWildcard),Integer(maximumToReturn)
-r-x   removeGroup                                  Void : String(groupName)
-r-x   removeMemberFromGroup                        Void : String(groupName),String(memberUserOrGroupName)
-r-x   removeUser                                   Void : String(userName)
-r-x   resetUserPassword                            Void : String(userName),String(newPassword)
-r-x   setGroupDescription                          Void : String(groupName),String(description)
-r-x   setUserAttributeValue                        Void : String(userName),String(userAttributeName),Object(newValue)
-r-x   setUserDescription                           Void : String(userName),String(description)
-r-x   userExists                                   Boolean : String(userName)

4. 新規ユーザーをレルムに追加します。

次に例を示します。

wls:/base_domain/serverConfig/Partitions/Partition1/Realm/Partition1Realm/AuthenticationProviders/auth_provider2>
cmo.createUser("myuser2","mypassword2","A user in the Partition1 default authenticator")

5. 新規ユーザーが正常に作成されたことを確認します。

次に例を示します。

wls:/base_domain/serverConfig/Partitions/Partition1/Realm/Partition1Realm/AuthenticationProviders/auth_provider2>
if cmo.userExists('myuser2'):
print "User myuser2 added"
...
User myuser2 added

パーティション管理者としてのユーザーおよびグループの管理: RESTの例

パーティションのセキュリティ・データをパーティション管理者としてRepresentational State Transfer (REST)から管理する方法の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のユーザーの構成に関する項を参照してください。

この例は、パーティション管理者がパーティションのデプロイヤ、オペレータおよびモニター・ユーザーを作成し、これらのユーザーをそれぞれ該当するグループに割り当てる方法を示しています。

ドメイン・パーティションでのSSLの構成

Secure Sockets Layer (SSL)の構成はパーティション固有ではありません。『 Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』のSSLの構成に関する項で説明しているように、すべてのパーティションは標準のWebLogic Server SSL構成を使用します。

ただし、次の重要な相違点に注意してください。

- 「仮想ターゲットの構成」の説明に従い、仮想ターゲットの明示的なポートまたはオフセット・ポートを構成する場合、SSLはその仮想ターゲットでサポートされません。
これは、クライアント(たとえばRemote Method Invocation (RMI)クライアント)が、ポート・ベースのルーティングを使用するパーティションにSSLを介して直接通信できないことを意味します。

- デフォルトではないセキュリティ・レルム(1つ以上のパーティションに関連付けられたセキュリティ・レルムなど)で構成された証明書パス・プロバイダは、追加のSSL検証の一部として実行されません。デフォルトのセキュリティ・レルムの証明書パス・プロバイダのみが実行されます。

ドメイン・パーティションでのセキュリティの構成: 関連タスクおよびリンク

次の追加情報を参照してください。

- 『Oracle WebLogic Server管理コンソール・オンライン・ヘルプ』のセキュリティ・プロバイダの管理に関する項

- 『Oracle WebLogic Server管理コンソール・オンライン・ヘルプ』のユーザーの作成に関する項

- 『Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』のSSLの構成に関する項

6 Oracle Traffic Directorの構成

この章では、Oracle WebLogic Server Multitenant (MT)でOracle Traffic Directorを構成する方法について説明します。この章の説明に従い、Oracle Enterprise Manager Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)を使用して、Oracle Traffic Directorを構成できます。この章では、適宜追加情報について、Oracle Traffic Directorドキュメントおよびオンライン・ヘルプを参照します。

この章の内容は次のとおりです。

- Oracle Traffic Directorの構成: 概要

- Oracle Traffic Directorの構成: 主な手順

- Oracle Traffic Director: トラブルシューティング

- Oracle Traffic Directorの構成: 関連タスクおよびリンク

Oracle Traffic Directorの構成: 概要

通常のデプロイメント・シナリオでは、Oracle Traffic Directorは、受信クライアント・リクエストをOracle WebLogic Serverに配布します。WebLogic Server MT環境では、Oracle Traffic Directorは、明示的なユーザー・アクションなしで自動的に、WebLogic Server MTパーティション管理を使用して構成を調整することによって、受信クライアント・リクエストをWebLogic Server MTパーティションに配布します。ただし、Oracle Traffic Directorマルチテナント・サポートを使用する場合は、この後の各項の説明に従って、1回のみの、Oracle Traffic Directorの初期構成を実行する必要があります。

次のデプロイメント・トポロジについて考えます。

- 別のドメインにあるOracle WebLogic Server MTおよびOracle Traffic Director
このトポロジでは、Oracle Traffic Directorは、WebLogic Server MTドメインとは別のドメインに存在します。これらのドメインは、異なるホスト上に指定できます。そのドメインに存在するOracle Traffic Directorインスタンスは、異なるホスト上に存在する複数のWebLogic Server MTドメインにクライアント・リクエストを配布します。Oracle Traffic Directorは別のドメインにあっても、管理のためにWebLogic Serverとともに配置される必要があります。詳細は、『インストールガイド』のOracle Traffic Directorドメイン構成の選択に関する項を参照してください。

- 単一のドメインにあるOracle WebLogic Server MTおよびOracle Traffic Director
このトポロジでは、Oracle Traffic Directorは、WebLogic Server MTドメインと同じドメインにあります。Oracle Traffic Directorインスタンスは、同じWebLogic Server MTドメインに存在し、そのドメインにクライアント・リクエストを配布します。このトポロジでも、Oracle Traffic Directorは管理のためにWebLogic Server MTとともに配置される必要があります。詳細は、『インストールガイド』のOracle Traffic Directorドメイン構成の選択に関する項を参照してください。

要約すると、次を行う必要があります。

- WebLogic Server MTとともに配置するOracle Traffic Directorをインストールし、Oracle Traffic Directorドメインを作成します。詳細は、「Oracle Traffic Directorのドメインの作成」を参照してください。

- 1回のみの、Oracle Traffic Directorの初期構成を実行して、Oracle Traffic Directorマルチテナンシ機能を有効にします。これには、Oracle Traffic Director MT構成およびインスタンスの作成と、ライフサイクル・マネージャ(LCM)へのOracle Traffic Directorランタイムの登録が含まれます。詳細は、「Oracle Traffic DirectorのMT構成およびインスタンスの作成」および「Oracle Traffic Directorランタイムの登録」を参照してください。

- パーティションの作成中に、WebLogic Server MTパーティションのロード・バランサ構成を作成するときに、登録されたOracle Traffic Directorランタイムを使用します。「ライフサイクル管理」で説明しているように、完了すると、LCMは、オーケストレーションをOracle Traffic Directorと適切に調整します。

Oracle Traffic Directorパーティション

Fusion Middleware Controlを使用してWebLogic Server MTパーティションを作成すると、対応するOracle Traffic Directorパーティションが自動的に作成されます。Oracle Traffic Directorパーティションは、単純に、パーティションおよびリソース・グループと同じ名前のグループです。Fusion Middleware Controlでは、パーティションおよびリソース・グループにマップされるOracle Traffic Directorアーティファクトを識別するためのOracle Traffic Directorパーティションのリストを含むサマリー表が提供されます。WLSTを使用して、Oracle Traffic Directorパーティションをリストすることもできます。詳細は、『WebLogic Scripting Toolコマンド・リファレンス』のotd_listPartitionsおよびotd_listResourceGroupsを参照してください。

次のように、Oracle Traffic DirectorアーティファクトはWebLogic Server MTアーティファクトにマップされます。

- 各クラスタは、オリジン・サーバー・プールにマップします。

- パーティションまたはリソース・グループ、あるいはその両方に関連付けられた仮想ターゲットのホスト名は、仮想サーバーにマップされます。

- 仮想ターゲットのURI接頭辞は、仮想ターゲットのホスト名に対応する仮想サーバー内のルートにマップされます。

Oracle Traffic Directorアーティファクトの詳細は、『管理者ガイド』のOracle Traffic Directorの用語に関する項を参照してください。

モニタリング

メトリックはパーティションごとに収集されます。システム管理者は、Fusion Middleware ControlまたはWLSTのいずれかを使用して、パーティション・メトリックにアクセスできます。詳細は、『管理者ガイド』のOracle Traffic Directorインスタンスをモニターする方法に関する項を参照してください。

ロギング

Oracle Traffic Directorには、パーティションごとに個別のアクセス・ログがあります。パーティションのアクセス・ログ・ファイル名は、パーティション名自体と同じです。

Fusion Middleware ControlおよびWLSTを使用して、ログを表示および管理できます。詳細は、『管理者ガイド』のFusion Middleware Controlを使用したログの表示に関する項およびWLSTを使用したログの表示に関する項を参照してください。

Oracle Traffic Directorの構成: 主な手順

この項では、WebLogic Server MT環境でOracle Traffic Directorのドメインおよび構成を作成する主な手順について説明します。次の項目が含まれます。

- Oracle Traffic Directorのドメインの作成

- Oracle Traffic DirectorのMT構成およびインスタンスの作成

- Oracle Traffic Directorランタイムの登録

Oracle Traffic Directorのドメインの作成

Oracle Traffic Director MT構成およびインスタンスを作成するには、まずWebLogic Server MTドメインを作成し、制限付きのOracle Java Required Files (JRF)テンプレートを使用してOracle Traffic Director用に拡張する必要があります。その後、WLSTまたはFusion Middleware Controlを使用して、Oracle Traffic Director構成およびインスタンスを作成できます。

次のように、Oracle WebLogic Server MTドメインを作成します。

- 単一のOracle Traffic Directorインスタンスがクライアント・リクエストを複数のOracle WebLogic Server MTドメインに配布する、大規模なエンタープライズ・デプロイメントでは、Oracle WebLogic Server MTおよびOracle Traffic Director用に別のドメインを作成します。
たとえば、2台のマシン(m1およびm2)を使用し、m1にOracle Traffic Directorドメイン、m2にWebLogic Server MTドメインを置く場合は、次のようにします。

次のように、m1にOracle Traffic Directorドメインを作成します。

1. $ORACLE_HOMEに、JRFとともにWebLogic Server MTをインストールします。

2. 同じ$ORACLE_HOMEに、Oracle Traffic Directorをインストールします。

3. 構成ウィザードを呼び出します。

4. Oracle Traffic Director用にOracle Traffic Director - Restricted JRFテンプレートを選択し、ドメインの作成を続行します。

これらの手順では、WebLogic Server MTドメインを作成してOracle Traffic Director用に拡張し、Oracle Traffic Director構成およびインスタンスの作成を続行できるようにしています。Oracle Traffic Directorドメインでも、WebLogic Server MTをJRFとともにインストールして、WebLogic Server MTドメインを作成し、Oracle Traffic Director用に拡張する必要があることに注意してください。

m2にWebLogic Server MTドメインを作成するには、次のようにします。

1. $ORACLE_HOMEにWebLogic Server MTをインストールします(JRFを含むWebLogic Server MTは必要ありません)。

2. 構成ウィザードを呼び出します。

3. 基本的なWebLogic Server MTドメインを作成します。

- 配置されたドメインで、WebLogic Server MTをインストールした場所と同じORACLE_HOMEにOracle Traffic Directorをインストールします。
たとえば、Oracle Traffic DirectorとWebLogic Server MTの両方をm1マシン上の単一のドメインに置く場合は、次のようにします。

1. $ORACLE_HOMEに、JRFとともにWebLogic Server MTをインストールします。

2. 同じ$ORACLE_HOMEに、Oracle Traffic Directorをインストールします。

3. 構成ウィザードを呼び出します。

4. Oracle Traffic Director用にOracle Traffic Director - Restricted JRFテンプレートを選択し、ドメインの作成を続行します。

このデプロイメント・シナリオでは、WebLogic Server MTおよびOracle Traffic Directorの両方が同じドメインにあり、Oracle Traffic Directorによって、このドメイン内に作成されるWebLogic Server MTパーティションが管理されます。

構成ウィザードを使用してドメインを作成する場合、新規ドメインを作成するように選択する必要があり、「テンプレート」ダイアログで、Oracle Traffic Director - 12.2.1 Restricted JRFテンプレートを選択する必要があります。

ドメインのインストールおよび構成の詳細な手順は、『Oracle Traffic Directorインストレーション・ガイド』を参照してください。

Oracle Traffic DirectorのMT構成およびインスタンスの作成

Oracle Traffic Directorドメイン(実際にはOracle Traffic Director用に拡張されたWebLogic Server MTドメイン)を作成した後で、Fusion Middleware ControlまたはWLSTを使用して、ブートストラップOracle Traffic Director構成を作成する必要があります。

Fusion Middleware Controlを使用した構成およびインスタンスの作成

Fusion Middleware Controlを使用したOracle Traffic Director MT構成およびインスタンスの作成の詳細は、『管理者ガイド』のFusion Middleware Controlを使用した構成の作成に関する項およびFusion Middleware Controlを使用したOracle Traffic Directorインスタンスの作成に関する項を参照してください。

WLSTを使用した構成およびインスタンスの作成

WLSTを使用したOracle Traffic Director MT構成およびインスタンスの作成の詳細は、『管理者ガイド』のWLSTを使用した構成の作成に関する項およびWLSTを使用したOracle Traffic Directorインスタンスの作成に関する項を参照してください。

Oracle Traffic Directorランタイムの登録

Fusion Middleware Controlを使用して、Oracle Traffic Directorランタイムを登録して、ライフサイクル・イベントまたは操作を有効にします。

注意:

Oracle Traffic DirectorランタイムをWebLogic Server MTドメインに登録する必要があります。Oracle Traffic Directorランタイムを登録する前に、Fusion Middleware Controlを使用して、WebLogic Server MTドメインにログインしてください。

1. 「WebLogicドメイン」メニューから「環境」→「OTDランタイム」を選択します。

2. 「レジスタ・ランタイム」をクリックします。

Oracle Traffic Directorの新規ランタイムの名前を指定して、このランタイムを配置する場所の情報(ホスト、ポートおよび資格証明)を入力します。任意のOracle Traffic Directorランタイム名を指定できますが、パーティションの作成中に、WebLogic Server MTパーティションのロード・バランサ構成を作成する場合は、同じランタイム名を選択する必要があります。

MTで使用される既存のOracle Traffic Director構成の名前も指定する必要があります。たとえば、「Fusion Middleware Controlを使用した構成およびインスタンスの作成」で作成した構成を使用する場合、Oracle Traffic Director構成の作成時に指定した名前と同じ名前を指定する必要があります。

注意:

「レジスタ・ランタイム」ダイアログで、Oracle Traffic Directorドメインの管理サーバーのホストおよびポートの詳細と(Oracle Traffic Directorドメインの)管理サーバーの資格証明を指定する必要があります。

Oracle Traffic Director: トラブルシューティング

次に、一般的なデバッグのヒント、よくある質問、WebLogic Server MTコンポーネントとOracle Traffic Directorコンポーネントが同期されなくなった場合に実行できる修正アクションについて説明します。

Oracle Traffic DirectorをWebLogic Server MTパーティションに関連付ける前に、次のことを確認してください。

- WebLogic Server MT管理サーバーおよびノード・マネージャが、Oracle Traffic Directorドメイン内で稼働していること。

- WebLogic Server MT管理サーバーがノード・マネージャに問題なくアクセスできること。

- MTで使用するOracle Traffic Director構成および対応するインスタンスを作成してあること。詳細は、「Oracle Traffic DirectorのMT構成およびインスタンスの作成」を参照してください。

- ライフサイクル・マネージャ(LCM)に正しいOracle Traffic Directorランタイムを登録してあること。詳細は、「Oracle Traffic Directorランタイムの登録」を参照してください。

よくある質問

よくある質問および問題には、次の応答で対応します。次のFAQは、Oracle Traffic DirectorとともにLCMを使用して、MTおよびパーティション管理のためにOracle Traffic Directorを構成する操作に関連します。

- MT用に既存のOracle Traffic Director構成を使用できますか。
はい。ただし、configurationというランタイム・プロパティを使用してOracle Traffic DirectorランタイムをLCMに登録する際には、既存の構成名を指定する必要があります。指定しない場合、名前はデフォルトでmtに設定されます。

- Oracle Traffic DirectorがWebLogic Server MTパーティションに正常に関連付けられているかどうかを確認するには、どうすればよいですか。
関連付けが成功している場合は、仮想サーバーやルートなどのOracle Traffic Directorアーティファクトが、Oracle Traffic DirectorのWebLogic Server MTパーティション用に作成されています。

Oracle Traffic Directorドメインでotd_listPartitionsおよびotd_listResourceGroups WLSTコマンドを呼び出して、関連付けが成功していることを確認してください。

- 低レベルのRepresentational State Transfer (REST) APIを使用する場合、Oracle Traffic Directorパーティションを明示的に作成する必要はありますか。
はい。Fusion Middleware ControlではOracle Traffic Directorパーティションが暗黙的に作成されますが、低レベルのREST APIでは作成されません。

Oracle Traffic Directorパーティション名は、WebLogic Server MTパーティション名と同じである必要があります。

Oracle Traffic Directorパーティションは、機能するアーティファクトではないことに注意してください。これは、WebLogic Server MTパーティションに対するリクエストを処理するすべてのOracle Traffic Directorアーティファクトを論理的にグループ化するためにのみ使用されます。

- Oracle Traffic DirectorがLCMから通知されるかどうかを判別するには、どうすればよいですか。
LCMから通知される場合、Oracle Traffic Directorプラグインによってデバッグ情報がログに記録されます。ログ・メッセージのサンプルは次のとおりです。

<[com.oracle.weblogic.lifecycle.plugin.otd.OTDUtil:log] OTDLifeyclePlugin : Associating OTD with the WLS MT partition>

- Oracle Traffic Directorプラグインのデバッグを有効にするには、どうすればよいですか。
WebLogic Server MT管理サーバー・ドメインのログ・レベルをDebugに設定します。

- Oracle WebLogic Server管理コンソールで、「環境」→「サーバー」→「ロギング」→「詳細」を選択し、必要な重大度レベル(「ログの最低の重大度」や「ログ・ファイル」重大度レベルなど)をDebugに設定します。

- WLSTを使用する場合: cd('/Servers/AdminServer/Log/AdminServer')を実行し、必要な重大度レベルをDebugに設定します(cmo.setLoggerSeverity('Debug'))。

- WebLogic Server MTパーティションのターゲットとして指定された仮想ターゲットのホスト名およびURI接頭辞の値を変更しましたが、Oracle Traffic Directorは更新されませんでした。なぜですか。
仮想ターゲットのホスト名およびURI接頭辞は、有効にするにはパーティションの再起動が必要な非動的属性です。Oracle Traffic Directorを更新するには、WebLogic Server MTパーティションを再起動してください。

- 既存のWebLogic Server MTパーティションに新しいリソース・グループを追加しましたが、Oracle Traffic Directorは更新されませんでした。なぜですか。
これは既知の問題です。詳細は、『Oracle WebLogic Serverリリース・ノート』のリソース・グループの変更で更新されないOracle Traffic Directorに関する項を参照してください。

- WebLogic Server MTとOracle Traffic Directorが非同期になった場合に、同期するにはどうすればよいですか。
sync LCM REST APIを呼び出します。

curl -v \
--user $WLS_DOMAIN_ADMIN_USERNAME:$WLS_DOMAIN_ADMIN_PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-X POST http://$WLS_DOMAIN_ADMIN_HOSTNAME:$WLS_DOMAIN_ADMIN_PORT/management/lifecycle/latest/environments/$ENVIRONMENT_NAME/sync

$トークンを適切に置換する必要があります。

- sync REST APIによってWebLogic Server MTとOracle Traffic Directorが同期されない場合は、どうすればよいですか。
WebLogic Server MTパーティションとOracle Traffic Directorの関連付けを解除してから、再度関連付けます。

REST APIを使用して、次のことを行います。

関連付けを解除するには、次を実行します。

curl -v \
--user $WLS_DOMAIN_ADMIN_USERNAME:$WLS_DOMAIN_ADMIN_PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d '{ "partition1Name": "$WLSPartition_Name", "partition1RuntimeName" : "$WLS_RUNTIME_NAME", "partition2Name": "$OTDPartition_Name", "partition2RuntimeName": "$OTD_RUNTIME_NAME", "properties" :[]}' \
-X POST http://$WLS_DOMAIN_ADMIN_HOSTNAME:$WLS_DOMAIN_ADMIN_PORT/management/lifecycle/latest/environments/$ENVIRONMENT_NAME/dissociatePartitions

関連付けを行うには、次を実行します。

curl -v \
--user $WLS_DOMAIN_ADMIN_USERNAME:$WLS_DOMAIN_ADMIN_PASSWORD \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json \
-d '{ "partition1Name": "$WLSPartition_Name", "partition1RuntimeName" : "$WLS_RUNTIME_NAME", "partition2Name": "$OTDPartition_Name", "partition2RuntimeName": "$OTD_RUNTIME_NAME", "properties" :[]}' \
-X POST http://$WLS_DOMAIN_ADMIN_HOSTNAME:$WLS_DOMAIN_ADMIN_PORT/management/lifecycle/latest/environments/$ENVIRONMENT_NAME/associatePartitions

Fusion Middleware Control:

- 「ドメイン・パーティション」→「管理」→「ロード・バランシング構成」に移動します。

- 関連付けを解除するには、「ロード・バランシングにOTDを使用します」チェック・ボックスを選択解除します。

- 再度関連付けを行うには、同じチェック・ボックスを選択します。

- Oracle Traffic Directorパーティションごとに異なるログ・ファイルがありますか。
はい。パーティション・ログ・ファイル名は、パーティション名と同じです(たとえば、<OTD_PARTITION_NAME>.logは<OTD_DOMAIN_HOME>/servers/<OTD_INSTANCE_NAME>/logsにあります)。

次のWLSTコマンドを使用できます: otd_getPartitionAccessLogPropertiesおよびotd_setPartitionAccessLogProperties。

Oracle Traffic Directorの構成: 関連タスクおよびリンク

LCMオーケストレーションを使用すると、受信クライアント・リクエストをWebLogic Server MTパーティションに正常に配布するために必要なOracle Traffic Directorアーティファクトのみが、自動的に構成されます。これらのアーティファクトには、仮想サーバー、オリジン・サーバー・プール(オリジン・サーバーを含む)およびルートがあります。これ以外に、Oracle Traffic DirectorのSecure Sockets Layer (SSL)の有効化、Oracle Traffic Directorでのフェイルオーバー・グループの作成および管理などのその他すべての構成を、Oracle Traffic Director管理インタフェースを使用して明示的に実行する必要があります。詳細は、管理者ガイドを参照してください。

7 ドメイン・パーティションの構成

この章では、ドメイン・パーティションの作成、構成および管理の方法について説明します。この章の説明に従い、Oracle Enterprise Manager Fusion Middleware Control (FMWC)、WebLogic Scripting Tool (WLST)またはRepresentational State Transfer (REST)を使用できます。この章では、適宜追加情報について、Oracle Fusion Middleware、Oracle CoherenceおよびOracle Traffic Directorのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章の内容は次のとおりです。

- ドメイン・パーティションの構成: 概要

- ドメイン・パーティションの作成: 主な手順および例

- ドメイン・パーティションの管理: 主な手順および例

- ドメイン・パーティションの制御: 主な手順および例

- ドメイン・パーティションの構成: 関連タスクおよびリンク

ドメイン・パーティションの構成: 概要

Oracle WebLogic Server Multitenant (MT)は、ドメイン・パーティションと呼ばれる、ドメインの管理スライスとランタイム・スライスを実装します。ドメイン・パーティションはWebLogic Serverドメインの一部分であり、実行中のアプリケーション・インスタンスおよび関連するリソース専用となります。

任意の数のドメイン・パーティションを1つのドメインの中に作成できます。

注意:

最高のパフォーマンスを実現するために、基本的には1つのドメイン内のパーティションを10個以下とすることをお薦めします。ただし、実際のサーバー環境によっては、これよりも多くのパーティションがサポートされる可能性があります。

ドメイン・パーティションの作成: 前提条件

ドメイン・パーティションを作成するには、次の前提条件を満たしている必要があります。

1. 使用する予定のドメインをまだ作成していない場合は作成します。
Oracle Enterprise Manager - Restricted JRFテンプレートを使用してドメインを作成します。このテンプレートによって、他の必要なテンプレートの多くが自動的に含められます。

ベスト・プラクティスは、新しいドメインを作成することです。既存のドメインをアップグレードする予定の場合、「セキュリティの構成」の説明に従い、新しいセキュリティ・レルムを引き続き作成する必要があります。

注意:

Fusion Middleware ControlまたはOracle WebLogic Server管理コンソールを使用する場合は、クラスタ作成時にWebLogic Server MTに固有の事項はありません。

ただし、WLSTを使用して管理対象サーバーを作成する場合は(手動構成か動的かを問わない)、必要なOracle Java Required Files (JRF)テンプレートが適用されません。その後でFusion Middleware Controlを使用してドメインをモニターするときに、JRFテンプレートが適用されていないサーバーに対してはモニタリングが機能しません。

したがって、WLSTを使用する場合は次のようにします。

a. WLSTを使用してクラスタまたは管理対象サーバーを作成します。

b. applyJRFコマンド(『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』を参照)を使用してJRFテンプレートを管理対象サーバーに適用します。

2. ライフサイクル管理のためのデプロイメント・モードを設定します。この手順は、WebLogic Server管理コンソールまたはWLSTから実行できます。
WebLogic Server管理コンソールを使用する場合:

a. ナビゲーション・ペインで、ドメインを選択します。

b. 「構成」→「一般」ページを選択します。

c. 「詳細」コントロールを展開します。

d. 「ライフサイクル管理サービスの可用性」コントロールをLocal Admin Serverに変更します。

e. これは動的でない変更です。管理サーバーを再起動します。

WLSTから、次を実行します。

edit()
startEdit()
cd('/LifecycleManagerConfig/mydomain')
cmo.setDeploymentType('admin')
activate()

これは動的でない変更です。管理サーバーを再起動します。

3. パーティションのセキュリティ・レルムをまだ作成していない場合は作成します。各パーティションに1つのセキュリティ・レルムが必要です。使用する手順は、「セキュリティの構成」を参照してください。

4. 1つ以上の仮想ターゲットをまだ作成していない場合は作成します。使用する手順は、「仮想ターゲットの構成」を参照してください。

5. このドメイン・パーティションでリソース・グループ・テンプレートを使用する場合、先にリソース・グループ・テンプレートを作成します。使用する手順は、「リソース・グループ・テンプレートの構成」を参照してください。

6. ロード・バランシングにOracle Traffic Directorを使用している場合は、Oracle Traffic Directorランタイム構成を登録します。実行する手順は、「Oracle Traffic Directorランタイムの登録」を参照してください。

Oracle Traffic Director: WebLogic Serverプラグインの有効化に関する前提条件

ロード・バランシングにOracle Traffic Directorを使用している場合は、WebLogic Server管理コンソールで「WebLogicプラグインの有効化」コントロールを設定する必要があります。

このコントロールは3つのレベルのいずれかに設定できます。これらのレベルには階層があります。あるレベルでの設定は、それよりも下のレベルのデフォルト値となり、下のレベルでの設定はそれよりも上のレベルでの設定よりも優先されます。レベルは次のとおりです。

- ドメイン・レベル: ドメイン・レベルで設定すると、そのドメイン内のクラスタおよび管理対象サーバーのそれぞれに対して設定されます。

- クラスタ・レベル: クラスタ・レベルの設定は、そのクラスタの一部である管理対象サーバーすべてに適用されます。これは、ドメイン・レベルの値よりも優先されます。

- 個々の管理対象サーバー・レベル: 管理対象サーバー・レベルでの設定は、クラスタまたはドメインのレベルで設定された値よりも優先されます。

含まれているクラスタや管理対象サーバーに関係なく、Oracle Traffic Directorを使用するパーティションが影響を受けるように、「WebLogicプラグインの有効化」コントロールをドメイン・レベルで設定することが最も簡単な場合があります。または、Oracle Traffic Directorで使用するパーティションのターゲットとして、特定のクラスタまたは管理対象サーバーのみが指定されることがわかっている場合、「WebLogicプラグインの有効化」コントロールをクラスタ・レベルまたは管理対象サーバー・レベルで設定するように選択できます。

ドメイン・レベル

WebLogic Server管理コンソールを使用して、ドメイン・レベルで「WebLogicプラグインの有効化」コントロールを設定するには、次の手順を実行します。

1. ナビゲーション・ペインで、ドメインを選択します。

2. 「構成」ページを選択し、「Webアプリケーション」を選択します。

3. 「WebLogicプラグインの有効化」コントロールを設定します。

4. 変更内容を保存します。

クラスタ・レベル

WebLogic Server管理コンソールを使用して、クラスタ・レベルで「WebLogicプラグインの有効化」コントロールを設定するには、次の手順を実行します。

1. ナビゲーション・ペインで、「環境」を展開します。

2. 「クラスタ」を選択します。

3. 管理するクラスタを選択します。

4. 「一般」ページを選択し、「詳細」をクリックします。

5. 「WebLogicプラグインの有効化」コントロールを設定します。

6. 変更内容を保存します。

管理対象サーバー・レベル

WebLogic Server管理コンソールを使用して、管理対象サーバー・レベルで「WebLogicプラグインの有効化」コントロールを設定するには、次の手順を実行します。

1. ナビゲーション・ペインで、「環境」を展開します。

2. 「サーバー」を選択します。

3. 管理するサーバーを選択します。

4. 「一般」ページを選択し、「詳細」をクリックします。

5. 「WebLogicプラグインの有効化」コントロールを設定します。

6. 変更内容を保存します。

ドメイン・パーティションの作成: 主な手順および例

ドメイン・パーティションを作成する主な手順は次のとおりです。

1. パーティション名を入力します。パーティション名は、ドメイン内で一意である必要があります。

2. このパーティションのセキュリティ・レルムを選択します。

セキュリティ・レルムは、このパーティションに対して一意とすることも、複数のパーティションで共有することもできます。

3. オプションで、このパーティションのプライマリ・アイデンティティ・ドメインの名前を入力します。または、名前を入力せず、デフォルトを受け入れることを選択できます。

4. ロード・バランシングにOracle Traffic Directorを使用している場合は、Oracle Traffic Directorランタイム構成を選択します。事前にOracle Traffic Directorランタイムを登録してある必要があります。

5. このドメイン・パーティションで使用できるようにする1つ以上の既存の仮想ターゲットを選択します。複数のパーティションで同じ仮想ターゲットを使用することはできません。1つの仮想ターゲットは、1つのパーティションでのみ、またはグローバル(ドメイン)レベルで使用できます。

6. このパーティションのリソース・グループが明示的に識別していない場合、既存の仮想ターゲットのいずれかをデフォルトとして使用するように選択します。

7. リソース・グループを作成します。2つの方法でリソース・グループを作成できます。

- 新しいリソース・グループを作成します。パーティションの作成が終了したら、必要に応じてこのリソース・グループを編集する必要があります。
リソース・グループ名を入力します。リソース・グループ名はパーティション内で一意であることが必要です。

- リソース・グループ・テンプレートに基づいた新しいリソース・グループを作成します。(リソース・グループ・テンプレートの詳細は、「リソース・グループ・テンプレートの構成」を参照してください。)構成は、テンプレートから新しいリソース・グループにコピーされます。
リソース・グループ名を入力します。リソース・グループ名はドメイン内で一意であることが必要です。

使用するリソース・グループ・テンプレートを選択します。

8. このリソース・グループで使用する仮想ターゲットを選択します。

9. これがこのドメインに作成した最初のパーティションであり、本番モードでドメインを実行中の場合は、WebLogic管理サーバーを再起動します。

この手順は、ドメインの最初のパーティションを作成する場合、かつドメインを本番モードで実行している場合にのみ必要です。

10. パーティションを起動します。パーティションは、停止状態で作成されるため、その中のリソースにアクセスできるように起動する必要があります。

11. リソース・グループをリソース・グループ・テンプレートから作成していない場合、必要に応じてリソース・グループを編集します。

使用する主な手順は、「リソース・グループの構成」を参照してください。

ドメイン・パーティションをFusion Middleware Controlを使用して作成するには、オンライン・ヘルプのドメイン・パーティションの作成に関する項を参照してください。

ドメイン・パーティションの作成: WLSTの例

次の例では、ドメイン・パーティションPartitionMBeanをpepという名前でDomainMBeanから作成します。次を実行します。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

5. リソース・グループを作成します。

6. 仮想ターゲットをリソース・グループに追加します。

7. 変更をアクティブ化します。

8. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

# Create Pep partition and ResourceGroup
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)

ドメイン・パーティションの作成: RESTの例

RESTを使用したドメイン・パーティションの作成の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティションの作成に関する項を参照してください。

ドメイン・パーティションの管理: 主な手順および例

リソース・グループまたはリソース・グループのオーバーライドの構成時に、パーティションに必要な構成のほとんどを実行します。タスクには、JDBCシステム・データ・ソース、JMSサーバーおよびリソース、外部JNDIプロバイダなどの構成が含まれます。これらのタスクは、それぞれ「リソース・グループの構成」および「リソース・オーバーライドの構成」で説明されています。

この項では、ドメイン・パーティション自体に対して実行する管理タスクに重点を置いており、関連付けられたリソース・グループについては詳しく説明しません。

ドメイン・パーティションの管理の主な手順は次のとおりです。

1. 管理するドメイン・パーティションを選択します。

2. パーティションのパフォーマンスと使用状況をモニターします。

3. このドメイン・パーティションに使用できる仮想ターゲットを表示および変更します。

4. このパーティションに対して構成されているリソース・グループを表示および変更します。

5. このパーティションにデプロイされたアプリケーションを表示および変更します。(厳密に言えば、アプリケーションのデプロイ先はパーティション自体ではなく、パーティション内のリソース・グループです。)

6. ロード・バランシングにOracle Traffic Directorを使用している場合は、このパーティションで使用されているOracle Traffic Directorランタイム構成を表示して変更します。

7. JDBCおよびJMSモジュールのパーティション・オーバーライド構成を表示および変更します。

8. このパーティションに対して構成されているパーティション・ワーク・マネージャおよびリソース消費マネージャを表示および変更します。

9. このパーティションのセキュリティ・レルムとデフォルト・ターゲットを表示および変更します。

10. オプションで、Notes属性を使用してこのパーティションの追加情報を指定します。

ドメイン・パーティションをFusion Middleware Controlを使用して管理するには、オンライン・ヘルプのドメイン・パーティションの構成に関する項を参照してください。

ドメイン・パーティションの管理: WLSTの例

この例では、次の操作を実行しています。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

5. リソース・グループを作成します。

6. 仮想ターゲットをリソース・グループに追加します。

7. 変更をアクティブ化します。

8. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

9. アプリケーションMySimpleEjbをリソース・グループにデプロイします。

# Create Pep partition and ResourceGroup
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> activate()

wls:/base_domain/edit/ !> startPartitionWait(peppart)

wls:/base_domain/edit/ !> deploy(appName='MySimpleEjb', path='c:/webservices/MySimpleEjb.jar', partition='Pep', resourceGroup='TestRG',
deploymentOrder=10,securityModel='DDOnly')
:
Completed the deployment of Application with status completed
Current Status of your Deployment:
Deployment command type: deploy
Deployment State : completed
Deployment Message : no message

ドメイン・パーティションの管理: RESTの例

次のRESTの例を参照してください。

- RESTを使用したパーティション・スコープのデータ・ソースおよびJMSシステム・リソースの作成の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティション・スコープのシステム・リソースの作成に関する項を参照してください。

- RESTを使用したパーティション・スコープのアプリケーションのデプロイの例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティション・スコープのアプリケーションのデプロイに関する項を参照してください。

ドメイン・パーティションの制御: 主な手順および例

グローバルおよびパーティション固有のリソースを再構成するときに、関連するサーバーやクラスタを再起動する必要はありません。あるパーティションへの変更が他のパーティションに影響することはないため、パーティションの作成、起動、停止および削除を個別に行うことができます。

ドメイン・パーティションの制御の主な手順は次のとおりです。

1. 制御するパーティションを選択します。パーティションをインポートするときはパーティションを選択する必要はありません。

2. パーティションを起動します。すべてのリソース・グループ(およびこれらのリソース・グループにデプロイされたすべてのアプリケーション)が起動します。

3. パーティションを停止します。すべてのリソース・グループ(およびこれらのリソース・グループにデプロイされたすべてのアプリケーション)が停止します。リソース・グループを停止すると、そのリソース・グループのアプリケーションとリソースは実行を停止し、メモリーから削除されます。

パーティションを停止することは、アプリケーションやリソースのアンデプロイを実行時に行うのと同じことになりますが、アンデプロイ時とは異なり、そのアプリケーションやリソースの構成が構成ファイルから削除されることはありません。管理対象サーバーに配信された構成も削除されません。

4. パーティションを一時停止します。一時停止操作によって、パーティションがRUNNING状態からADMIN状態に正常に遷移します。

5. パーティションを再開します。再開操作によって、パーティションがADMIN状態からRUNNING状態に正常に遷移します。

6. パーティションをインポートします。パーティションを別のドメインにインポートするときに、必要な構成変更の数は最小限です。詳細は、パーティションのエクスポートおよびインポートを参照してください。

7. パーティションをエクスポートします。パーティションをあるドメイン(ソース・ドメイン)からエクスポートして別のドメイン(ターゲット・ドメイン)にインポートできます。詳細は、パーティションのエクスポートおよびインポートを参照してください。

8. パーティションを削除します。パーティションを削除すると、パーティション内のすべてのリソース・グループが削除され、パーティションにデプロイされているすべてのアプリケーションがアンデプロイされます。

注意:

パーティションを削除するには、最初にそのパーティションを停止する必要があります。

ドメイン・パーティションをFusion Middleware Controlを使用して制御するには、オンライン・ヘルプのドメイン・パーティションの制御に関する項を参照してください。

パーティションの再起動を必要とする操作

次の操作を行うときはパーティションの再起動が必要です。

- リソース・グループ内のシステム・リソースの動的ではない属性の変更。たとえば、JDBCデータベース接続のURLです。

- システム・リソースの動的ではない属性に影響するオーバーライド。たとえば、外部JMSサーバーの接続URLです。

- 実行中のパーティションで使用中の仮想ターゲットのターゲット指定ではない変更。たとえば、URI接頭辞です。

- リソース・デプロイメント・プランの変更。

ドメイン・パーティションの制御: WLSTの例

WLSTによるパーティションのインポートおよびエクスポートの例は、「パーティションのエクスポートおよびインポート」を参照してください。

次の例では、WLSTのstartPartitionWait()コマンドを使用してドメイン・パーティションpepをルートDomainMBeanから起動します。startPartitionWait()の詳細は、『WebLogic Server WLSTコマンド・リファレンス』を参照してください。

startPartitionWait()コマンドでは、パーティションが起動している必要があります。PartitionMBeanはDomain.createPartition()やDomain.lookupPartition()などから取得できます。

edit()
startEdit()
domain=getMBean('/')
startPartitionWait(domain.lookupPartition("Pep"))
[MBeanServerInvocationHandler]com.bea:Name=_5_START,Type=PartitionLifeCycleTaskRuntime,PartitionLifeCycleRuntime=Pep

PartitionLifeCycleRuntimeMBeanによるフル・コントロール

startPartitionWait()コマンドは、便宜のためのコマンドです。パーティションの停止など、パーティション・ライフサイクルのフル・コントロールの場合、PartitionLifeCycleRuntimeMBeanを使用します。詳細は、Oracle WebLogic Server MBeanリファレンスのPartitionLifeCycleRuntimeMBeanを参照してください。

次の例では、パーティションpepを正常に停止します。

domainRuntime()
cd('DomainPartitionRuntimes')
cd ('pep')
cd('PartitionLifeCycleRuntime')
cd ('pep')
cmo.shutdown()
[MBeanServerInvocationHandler]com.bea:Name=_3_SHUTDOWN,Type=PartitionLifeCycleTaskRuntime,DomainPartitionRuntime=pep,PartitionLifeCycleRuntime=pep

次の例では、パーティションpepを起動します。

domainRuntime()
cd('DomainPartitionRuntimes')
cd ('pep')
cd('PartitionLifeCycleRuntime')
cd ('pep')
cmo.start()
[MBeanServerInvocationHandler]com.bea:Name=_4_START,Type=PartitionLifeCycleTaskRuntime,DomainPartitionRuntime=pep,PartitionLifeCycleRuntime=pep

次の例では、パーティションpepを一時停止します。

domainRuntime()
cd('DomainPartitionRuntimes')
cd ('pep')
cd('PartitionLifeCycleRuntime')
cd ('pep')
cmo.suspend()
[[MBeanServerInvocationHandler]com.bea:Name=_5_SUSPEND,Type=PartitionLifeCycleTaskRuntime,DomainPartitionRuntime=pep,PartitionLifeCycleRuntime=pep

ドメイン・パーティションの制御: RESTの例

RESTを使用したドメイン・パーティションの制御の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティションの起動および停止に関する項を参照してください。

ドメイン・パーティションの構成: 関連タスクおよびリンク

次の追加情報を参照してください。

- Oracle WebLogic Server Multitenant

- 仮想ターゲットの構成

- リソース・グループ・テンプレートの構成

- リソース・グループの構成

- リソース・オーバーライドの構成

- リソース消費管理の構成

- Oracle Coherenceの構成,

- パーティション・ワーク・マネージャの構成

- パーティションのエクスポートおよびインポート

- パーティションのモニタリングおよびデバッグ

8 リソース・グループの構成

この章では、リソース・グループを構成する方法について説明します。この章では、適宜追加情報について、Oracle Fusion MiddlewareとOracle WebLogic Serverのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章の内容は次のとおりです。

- リソース・グループの構成: 概要

- リソース・グループの作成: 主な手順および例

- リソース・グループの構成: 主な手順および例

- リソース・グループの削除: 主な手順およびWLSTの例

- リソース・グループの制御: 主な手順およびWLSTの例

- リソース・グループの移行: 主な手順およびWLSTの例

- パーティション・リソース・グループでの管理アプリケーションおよびリソースの管理

- リソース・グループの構成: 関連タスクおよびリンク

リソース・グループの構成: 概要

従来のOracle WebLogic Serverドメインには、多くのタイプのデプロイ可能なリソース(アプリケーション、JMSサーバーとJMSキュー、データ・ソースなど)を含めることができます。この従来のモデルでは、アプリケーション・スイートに複数のアプリケーションとそれらのアプリケーションをサポートする様々なリソースが含まれる場合は、管理者が一貫性のある単位としてではなく、個別にこれらのリソースを定義し、これらのアプリケーションをデプロイします。

リソース・グループは、アプリケーションとそれらが使用するリソースを、ドメイン内の個別の管理単位にグループ化します。通常、指定されたリソース・グループ内でリソースがなんらかの方法で関連付けられます。たとえば、それらが単一のアプリケーション・スイートを構成します。

リソースとアプリケーションには、それらのリソースを開始したりそれらに接続するために必要なすべての情報(データ・ソースに接続するための資格証明やアプリケーションのターゲット指定情報を含む)があります。リソース・グループにデプロイされたアプリケーションは、起動可能な状態にする必要があります。

リソース・グループは次の2つの方法で作成できます。

- 新しいリソース・グループを作成します。これにより、リソース・グループの基本構造が作成されます。次に、このリソース・グループを必要に応じて編集する必要があります。

- リソース・グループ・テンプレートに基づいた新しいリソース・グループを作成します。(リソース・グループ・テンプレートの詳細は、「リソース・グループ・テンプレートの構成」を参照してください。)構成は、テンプレートから新しいリソース・グループにコピーされます。次に、リソース・グループ・テンプレートからの値を必要に応じて編集およびオーバーライドする必要があります。

この節では、以下のトピックについて説明します。

- リソース・グループとは

- リソース・グループとオーバーライド

- グローバル・スコープおよびパーティションでのリソース・グループ

- 複数のターゲットへのリソース・グループのターゲット設定

リソース・グループとは

リソース・グループはResourceGroupMBeanに基づくもので、次のリソースを含めることができます。

- 一般(名前、スコープ、リソース・グループ・テンプレートに基づくかどうか)

- デプロイメント

- サービス:

- JDBC

- メッセージ

- メール・セッション

- 永続ストア

- 外部JNDIプロバイダ

- OSGiフレームワーク

- 診断

- ターゲット

- モニタリング機能(JDBC、メッセージ)

- 制御機能(JDBC、メッセージ、移行)

- ノート

リソース・グループとオーバーライド

リソース・オーバーライドによって、パーティション・レベルでリソースをカスタマイズできます。リソース・グループ・テンプレートから導出されたリソース設定をオーバーライドできます。

オーバーライドには、主に2つのタイプがあります。

- リソース・オーバーライド構成MBeanおよびリソース・デプロイメント・プランを使用して、特定のリソースのリソース設定をオーバーライドできます。

- 別のデプロイメント・プランを指定して、リソース・グループ・テンプレートに定義されているアプリケーションおよびモジュールのデフォルト・アプリケーション構成をオーバーライドできます。アプリケーションまたはモジュールは、アプリケーション構成用の新しいデプロイメント・プランを使用して再デプロイされます。

リソース・オーバーライドの詳細は、「リソース・オーバーライドの構成」を参照してください。アプリケーション・オーバーライドの詳細は、「パーティション・リソース・グループへのアプリケーションのデプロイ」を参照してください。

グローバル・スコープおよびパーティションでのリソース・グループ

リソース・グループは、ドメイン・レベルで作成することも、ドメイン・パーティションに固有のものとして作成することもできます。ドメイン・レベルでリソース・グループを作成する場合、それにグローバル・スコープが指定され、非パーティション環境のドメイン・レベルと同等になります。ドメイン・レベルで実行されるアプリケーションまたはクラスはドメイン全体で使用できますが、パーティションでは使用できません。

パーティション・レベルで作成したリソース・グループは、そのパーティションにのみスコープ指定されます。パーティション・レベルで実行されるアプリケーションまたはクラスはそのパーティションで使用できますが、ドメイン・レベルまたは他のパーティションでは使用できません。

複数のターゲットへのリソース・グループのターゲット設定

複数の仮想ターゲットを持つようにリソース・グループを構成できます。たとえば、リソース・グループをCluster1、Cluster2およびCluster3の仮想ターゲットにターゲット設定して、リソース・グループのアプリケーションが3つすべてのクラスタで実行できます。

ただし、2つの重要な制限が存在します。

- 一部のリソース・グループ構成には、複数のターゲットに適用されないターゲット固有のリソースがある場合があります。次にこのようなリソースの例を示します(これらに限定されるものではありません)。

- JMSサーバー

- メッセージング・ブリッジ

- パス・サービス

- JMSブリッジ宛先

- ファイル・ストア

- JDBCストア

- JMSシステム・リソース

リソース・グループのターゲットとして複数の仮想ターゲットを指定しようとしたときに、これらのリソースのいずれかが存在する場合、WebLogic Server MTでエラーが生成されます。

- 同じ物理サーバーをターゲットとしている複数の仮想ターゲットには、リソース・グループをターゲット設定できません。
たとえば、リソース・グループRGのターゲットとしてVT1およびVT2が指定され、かつVT1とVT2の両方のターゲットとしてServer1が指定されている場合は、WebLogic Server MTによってエラーが生成されます。

リソース・グループの作成: 主な手順および例

パーティションまたはグローバル・スコープで新しいリソース・グループを作成するには、次のようにします。

1. 必要に応じて、パーティションまたはドメイン・レベルに移動します。
次の移動の相違点に注意してください。

- Fusion Middleware Controlを使用している場合は、「WebLogicドメイン」→「環境」→「リソース・グループ」に移動して、パーティション・レベルまたはドメイン・レベルでリソース・グループを作成できます。

- Oracle WebLogic Server管理コンソールを使用している場合は、「WebLogicドメイン」→「環境」→「リソース・グループ」に移動して、ドメイン・レベルでリソース・グループを作成します。
「WebLogicドメイン」→「ドメイン・パーティション」→「パーティション」→「リソース・グループ」に移動して、パーティション・レベルでリソース・グループを作成します。

2. 新しいリソース・グループを作成します。

3. 新しいリソース・グループに対して、次の構成設定を定義できます。

- 新しいリソース・グループの名前を入力します

- パーティション・レベルかドメイン・レベルかを選択します。

- オプションで、この新しいリソース・グループに使用するリソース・グループ・テンプレートを選択します

- この新しいリソース・グループのターゲットを選択します。

- 新しいリソース・グループのノートを入力します

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループの作成に関する項を参照してください。

リソース・グループをリソース・グループ・テンプレートから作成しなかった場合、最初のリソース・グループ構成は基本スケルトンで、使用する前に構成する必要があります。リソース・グループまたはリソース・グループのオーバーライドの構成時に、パーティションに必要な構成のほとんどを実行します。タスクには、JDBCシステム・データ・ソース、JMSサーバーおよびリソース、外部JNDIプロバイダなどの構成が含まれます。

詳細は、「リソース・グループの構成: 主な手順および例」を参照してください。

リソース・グループの作成: WLSTの例

この例では、次の操作を実行しています。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

5. リソース・グループを作成します。

6. 仮想ターゲットをリソース・グループに追加します。

7. 変更をアクティブ化します。

8. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

# Create Pep partition and ResourceGroup
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)

リソース・グループの作成: RESTの例

RESTを使用したリソース・グループの作成の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティションの作成に関する項を参照してください。

特に、新しいパーティションのリソース・グループの作成に関する項を参照してください。

リソース・グループの構成: 主な手順および例

この項では、次のタスクを取り上げます。

- リソース・グループの一般設定の構成

- リソース・グループのデプロイメント設定の構成

- リソース・グループのサービス設定の構成

- リソース・グループのターゲットの構成

- リソース・グループのノートの構成

リソース・グループの一般設定の構成

リソース・グループの一般設定を表示および定義するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 次のような、リソース・グループの一般的な構成設定を表示および定義します。

- 名前

- スコープ

- リソース・グループ・テンプレート

3. 変更内容を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループの一般設定の構成に関する項を参照してください。

リソース・グループのデプロイメント設定の構成

リソース・グループのデプロイメント設定を表示および定義するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 次のデプロイメント・アクションを実行できます。

- デプロイ

- 再デプロイ

- アンデプロイ

- デプロイメント・プランのフェッチ

- オーバーライドの追加

- オーバーライドの削除

- 起動

- 停止

3. 変更内容を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループのデプロイメント設定の構成に関する項を参照してください。

リソース・グループへのアプリケーションのデプロイ

アプリケーションをデプロイすると、物理ファイルまたはディレクトリがWebLogic Serverで認識されます。

リソース・グループにアプリケーションをデプロイするには、次のようにします。

1. 構成するリソース・グループを選択します。

2. デプロイするアプリケーションを探し、デプロイメント・プランをアップロードするか、新しいデプロイメント・プランを作成するかを選択します。

3. 必要に応じてアプリケーション属性を更新します。これらの属性は次のとおりです。

- アプリケーション名

- 分散

- ソースのアクセス可能性

4. アプリケーションをデプロイします。

5. デプロイメント設定を更新するか、このアプリケーションのデプロイメントを完了します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループへのアプリケーションのデプロイに関する項を参照してください。

リソース・グループへのアプリケーションの再デプロイ

アプリケーションを再デプロイすると、アーカイブ・ファイルまたは展開済ディレクトリが再デプロイされます。アプリケーションを変更し、その変更がWebLogic Serverクライアントで使用されるようにする場合に、アプリケーションを再デプロイします。

リソース・グループにアプリケーションまたはモジュールを再デプロイするには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 再デプロイするアプリケーションを選択します。

3. デプロイメント・プランをアップロードするか、新しいデプロイメント・プランを作成するかを決定します。

4. 必要に応じてアプリケーションの分散を更新します。

5. オプションで、デプロイメント・プランを編集し、より高度なデプロイメント・オプションを設定して、ローカル・ディスクにデプロイメント・プランを保存します。

6. アプリケーションを再デプロイして、このアプリケーションの再デプロイメントを完了します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループへのアプリケーションの再デプロイに関する項を参照してください。

リソース・グループからのアプリケーションのアンデプロイ

アプリケーションをアンデプロイすると、アプリケーションがデプロイされているドメインの各ターゲットからアプリケーションが削除されます。アプリケーションをドメインからアンデプロイした後で、WebLogic Serverクライアントでアプリケーションを使用できるようにするには、再度アプリケーションをデプロイする必要があります。WebLogic Serverクライアントでアプリケーションを一時的に使用できないようにするには、アプリケーションをアンデプロイするのではなく、停止します。

パーティション・リソース・グループからアプリケーションをアンデプロイするには、次のようにします。

1. 構成するリソース・グループを選択します。

2. デプロイ済アプリケーションからアンデプロイするアプリケーションを選択します。

3. アプリケーションをアンデプロイします。

4. 削除されたアプリケーションを後でデプロイする場合は、「リソース・グループへのアプリケーションのデプロイ」を参照してください。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループからのアプリケーションのアンデプロイに関する項を参照してください。

リソース・グループのサービス設定の構成

この項では、次のタスクを取り上げます。

- リソース・グループのJDBC設定の構成

- リソース・グループのJMS設定の構成

- リソース・グループのメール・セッション設定の構成

- リソース・グループの永続ストア設定の構成

- リソース・グループの外部JNDIプロバイダ設定の構成

- リソース・グループの診断システム・モジュール設定の構成

リソース・グループのJDBC設定の構成

このリソース・グループで作成されたJDBCシステム・リソースの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「JDBC」に移動します。

リソース・グループの読取り専用のJDBC情報は、次のとおりです。

- 名前

- JNDI名

- タイプ

- ターゲット

- アルゴリズム・タイプ

- 行プリフェッチ有効

- 行プリフェッチ・サイズ

- ストリーム・チャンク・サイズ

3. 必要に応じて、システム・データ・ソースを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループのJDBC設定の構成に関する項を参照してください。

このリソース・グループで作成されたJDBCシステム・データ・ソースの構成の詳細は、「JDBCの構成」を参照してください。

リソース・グループのJMS設定の構成

この項では、次のタスクを取り上げます。

- JMSサーバー設定の構成

- SAFエージェント設定の構成

- JMSリソース設定の構成

- JMSモジュール設定の構成

- メッセージング・ブリッジの構成

- JMSブリッジ宛先の構成

- パス・サービスの構成

JMSサーバー設定の構成

このリソース・グループに作成されたJMSサーバーの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「メッセージング」→「JMSサーバー」に移動します。

次の読取り専用情報は、このリソース・グループにすでに構成されているJMSサーバーで使用できます。

- 名前

- ヘルス

- ヘルスの理由

- 永続ストア

- 一時的なテンプレート名

- 最大バイト数

- 最大メッセージ数

- 最大バイトしきい値

- 最小バイトしきい値

- 最大メッセージしきい値

3. 必要に応じて、JMSサーバーを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJMSサーバー設定の構成に関する項を参照してください。

このリソース・グループで構成されたJMSサーバーの構成の詳細は、「JMSサーバーの構成」を参照してください。

SAFエージェント設定の構成

このリソース・グループに作成されたストア・アンド・フォワード(SAF)エージェントの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「メッセージング」→「SAFエージェント」に移動します。

次の読取り専用情報は、このリソース・グループに構成されているSAFエージェントで使用できます。

- 名前

- エージェント・タイプ

- 永続ストア

3. 必要に応じて、SAFエージェントを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のSAFエージェント設定の構成に関する項を参照してください。

このリソース・グループで構成されたSAFエージェントの構成の詳細は、「ストア・アンド・フォワード・エージェントの構成」を参照してください。

JMSリソース設定の構成

リソース・グループのリソース設定をモニターするには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「メッセージング」→「JMSリソース」に移動します。

次の読取り専用情報は、このリソース・グループに構成されているJMSリソースで使用できます。

- 名前

- タイプ

- JMSモジュール名

- JNDI名

- サブデプロイメント

3. 必要に応じて、JMSリソースを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のSAFエージェント設定の構成に関する項を参照してください。

既存のJMSリソースの構成の詳細は、「JMSシステム・リソースおよびアプリケーション・スコープのJMSモジュールの構成」を参照してください。

JMSモジュール設定の構成

リソース・グループのJMSモジュールを構成するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「メッセージング」→「JMSモジュール」→「JMSモジュール」に移動します。

次の読取り専用情報は、このリソース・グループに構成されているJMSモジュールで使用できます。

- 名前

- キュー

- トピック

- 接続ファクトリ

- 分散キュー

- 分散トピック

- 外部サーバー

- 割当て制限

- SAFエラー・ハンドラ

- SAFインポート済宛先

- SAFリモート・コンテキスト

- テンプレート

- 共通分散キュー

- 共通分散トピック

- 宛先キー

- タイプ

3. 必要に応じて、JMSモジュールを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJMSモジュール設定の構成に関する項を参照してください。

既存のJMSモジュールの構成の詳細は、「メッセージング・コンポーネントの構成」を参照してください。

メッセージング・ブリッジの構成

リソース・グループのメッセージング・ブリッジ設定を構成するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「メッセージング」→「メッセージング・ブリッジ」に移動します。

次の読取り専用情報は、このリソース・グループに構成されているメッセージング・ブリッジで使用できます。

- 名前

- ソース・ブリッジ宛先

- ターゲット・ブリッジ宛先

3. 必要に応じて、メッセージング・ブリッジを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のメッセージング・ブリッジの構成に関する項を参照してください。

このリソース・グループで構成されたメッセージング・ブリッジの構成の詳細は、「メッセージング・ブリッジの構成」を参照してください。

JMSブリッジ宛先の構成

リソース・グループのJMSブリッジ宛先設定を構成するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「メッセージング」→ブリッジ宛先に移動します。

次の読取り専用情報は、このリソース・グループに構成されているJMSブリッジ宛先で使用できます。

- 名前

- アダプタのJNDI名

3. 必要に応じて、JMSブリッジ宛先を作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJMSブリッジ宛先の構成に関する項を参照してください。

パス・サービスの構成

リソース・グループのパス・サービス設定を構成するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「メッセージング」→「パス・サービス」に移動します。

次の読取り専用情報は、このリソース・グループに構成されているパス・サービスで使用できます。

- 名前

- 永続ストア

3. 必要に応じて、パス・サービスを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のパス・サービスの構成に関する項を参照してください。

既存のパス・サービスの構成の詳細は、「分散宛先による順序単位の使用をサポートするパス・サービスの構成」を参照してください。

リソース・グループのメール・セッション設定の構成

このリソース・グループで作成されたメール・セッションの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「メール」に移動します。

次の読取り専用情報は、このリソース・グループに構成されているメール・セッションで使用できます。

- 名前

- JNDI名

3. 必要に応じて、メール・セッションを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverメール・セッションに関する項を参照してください。

リソース・グループの永続ストア設定の構成

このリソース・グループで作成された永続ストアの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「永続ストア」に移動します。

次の読取り専用情報は、このリソース・グループに構成されている永続ストアで使用できます。

- 名前

- タイプ

3. 必要に応じて、永続ストアを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Server永続ストアに関する項を参照してください。

既存の永続ストアの構成の詳細は、「JDBCまたはファイル永続ストアの構成」を参照してください。

リソース・グループの外部JNDIプロバイダ設定の構成

このリソース・グループで作成された外部JNDIプロバイダの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「外部JNDIプロバイダ」に移動します。

次の読取り専用情報は、このリソース・グループに構成されている外部JNDIプロバイダで使用できます。

- 名前

- 初期コンテキスト・ファクトリ

- プロバイダURL

- ユーザー

- ターゲット

3. 必要に応じて、外部JNDIプロバイダを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Server外部JNDIプロバイダに関する項を参照してください。

既存の外部JNDIプロバイダの構成の詳細は、「JNDIの構成とプログラミング」を参照してください。

リソース・グループの診断システム・モジュール設定の構成

このリソース・グループで作成された診断システム・モジュールの構成設定を表示するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「サービス」→「診断」に移動します。

次の読取り専用情報は、このリソース・グループに構成されている診断システム・モジュールで使用できます。

- 名前

- 説明

- ターゲット

3. 必要に応じて、診断システム・モジュールを作成または削除します。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Server診断に関する項を参照してください。

既存の診断システム・モジュールの構成の詳細は、「パーティションのモニタリングおよびデバッグ」を参照してください。

リソース・グループのターゲットの構成

このリソース・グループのターゲットを指定するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「ターゲット」に移動します。

3. このリソース・グループのターゲットとする1つ以上の仮想ターゲットを指定します。

リソース・グループを複数の仮想ターゲットにターゲット指定する場合の重要な考慮事項は、「複数のターゲットへのリソース・グループのターゲット設定」を参照してください。

仮想ターゲットは、パーティション内の多数のリソース・グループでも、ドメイン・レベルの多数のリソース・グループでも使用できます。

4. 変更を保存します。

これらのタスクの詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』の仮想ターゲットの構成に関する項を参照してください。

実際の仮想ターゲットの構成の詳細は、「仮想ターゲットの構成」を参照してください。

リソース・グループのノートの構成

リソース・グループのノートを作成するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「ノート」に移動します。

3. ノートを入力します。

4. 変更を保存します。

リソース・グループの構成: WLSTの例

この例では、次の操作を実行しています。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

5. リソース・グループを作成します。

6. 仮想ターゲットをリソース・グループに追加します。

7. 変更をアクティブ化します。

8. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

9. アプリケーションMySimpleEjbをリソース・グループにデプロイします。

# Create Pep partition and ResourceGroup
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> activate()

wls:/base_domain/edit/ !> startPartitionWait(peppart)

wls:/base_domain/edit/ !> deploy(appName='MySimpleEjb', path='c:/webservices/MySimpleEjb.jar', partition='Pep', resourceGroup='TestRG',
deploymentOrder=10,securityModel='DDOnly')
:
Completed the deployment of Application with status completed
Current Status of your Deployment:
Deployment command type: deploy
Deployment State : completed
Deployment Message : no message

リソース・グループの構成: RESTの例

RESTを使用したリソース・グループの構成の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティションの作成に関する項を参照してください。

特に、新しいパーティションのリソース・グループの表示に関する項およびシステム・リソースを構成するパーティション・デプロイヤの説明に関する項を参照してください。

リソース・グループの削除: 主な手順およびWLSTの例

リソース・グループを削除する前に、まずそれを停止する必要があります。リソース・グループを停止すると、リソース・グループのアプリケーションとリソースは処理を停止し、メモリーから削除されます。

1. 削除するリソース・グループを選択します。

2. 「制御」→「停止」に移動します。通常、作業の完了時にリソース・グループを停止するよう選択する必要があります。

3. リソース・グループを停止します。

4. リソース・グループを削除します。

リソース・グループの削除: WLSTの例

この例では、次の操作を実行しています。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

5. リソース・グループを作成します。

6. 仮想ターゲットをリソース・グループに追加します。

7. リソース・グループの設定を解除します。

8. リソース・グループを削除します。

9. 別のリソース・グループを作成します。

10. そのリソース・グループに仮想ターゲットを追加します。

11. 変更をアクティブ化します。

12. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

# Create Pep partition and Resource Group. Remove Resouce Group
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> peppart.unSet('ResourceGroups')
wls:/base_domain/edit/ !> peprg=peppart.destroyResourceGroup(peprg)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG2')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)

リソース・グループの制御: 主な手順およびWLSTの例

リソース・グループを制御するには、次のようにします。

1. 構成するリソース・グループを選択します。

2. 「制御」に移動します。

実行可能な操作は次のとおりです。

- 起動: 現在実行されていないアプリケーションのデプロイメントとリソースがアクティブになります。

- 停止: リソース・グループのアプリケーションとリソースは処理を停止し、メモリーから削除されます。これは、アプリケーションまたはリソースのアンデプロイと同等のランタイムです。ただし、実際のアンデプロイメントで行われるように、config.xmlファイルからアプリケーションまたはリソースの構成が削除されることはありません。

リソース・グループの制御: WLSTの例

リソース・グループの停止

次の例は、「リソース・グループの作成: WLSTの例」に示すWLSTの例を基に作成されています。ResourceGroupLifeCycleRuntime MBeanへのナビゲーションを示し、リソース・グループTestRGを停止します。

wls:/base_domain/serverConfig/> domainRuntime()
wls:/base_domain/domainRuntime/> domain=cmo
wls:/base_domain/domainRuntime/> partrun = cmo.lookupDomainPartitionRuntime('Pep')
wls:/base_domain/domainRuntime/> partliferun = partrun.getPartitionLifeCycleRuntime()
wls:/base_domain/domainRuntime/> rgliferun = partliferun.lookupResourceGroupLifeCycleRuntime('TestRG')
wls:/base_domain/domainRuntime/> rgliferun.shutdown()
[MBeanServerInvocationHandler]com.bea:Name=_2_SHUTDOWN,Type=ResourceGroupLifeCyc
leTaskRuntime,DomainPartitionRuntime=Pep,ResourceGroupLifeCycleRuntime=TestRG,Pa
rtitionLifeCycleRuntime=Pep

リソース・グループの起動

次の例は、「リソース・グループの作成: WLSTの例」に示すWLSTの例を基に作成されています。ResourceGroupLifeCycleRuntime MBeanへのナビゲーションを示し、リソース・グループTestRGを起動します。

wls:/base_domain/serverConfig/> domainRuntime()
wls:/base_domain/domainRuntime/> domain=cmo
wls:/base_domain/domainRuntime/> partrun = cmo.lookupDomainPartitionRuntime('Pep')
wls:/base_domain/domainRuntime/> partliferun = partrun.getPartitionLifeCycleRuntime()
wls:/base_domain/domainRuntime/> rgliferun = partliferun.lookupResourceGroupLifeCycleRuntime('TestRG')
wls:/base_domain/domainRuntime/> rgliferun.start()
[MBeanServerInvocationHandler]com.bea:Name=_4_START,Type=ResourceGroupLifeCycleT
askRuntime,DomainPartitionRuntime=Pep,ResourceGroupLifeCycleRuntime=TestRG,Parti
tionLifeCycleRuntime=Pep
wls:/base_domain/domainRuntime/>

リソース・グループの移行: 主な手順およびWLSTの例

リソース・グループを移行する場合、リソース・グループが使用している仮想ターゲットを、ある物理ターゲット(クラスタ/サーバー)から別の物理ターゲットに変更します。移行後、仮想ターゲットは新しい物理ターゲット(クラスタ/サーバー)を参照します。

この変更は、この仮想ターゲットを使用しているパーティション・レベルまたはドメイン・レベルのリソース・グループに影響を及ぼします。

Fusion Middleware Controlを使用してリソース・グループを移行するには、次の手順を実行します。

1. 「WebLogicドメイン」メニューから「環境」を選択し、「リソース・グループ」を選択します。

「リソース・グループ」表には、現在のドメインで構成された各リソース・グループに関する情報が表示されます。

2. 「リソース・グループ」表で、構成するリソース・グループを選択します。

3. 「移行」に移動します。

4. リソース・グループに関連付けられた仮想ターゲットの新しいターゲットを選択します。単一の管理対象サーバーまたは単一のクラスタを選択できます。

5. 変更を保存します。

リソース・グループの移行: WLSTの例

この例では、次の操作を実行しています。

1. ドメイン・パーティションを作成します。

2. 仮想ターゲットを作成します。

3. 仮想ターゲットのホスト名およびURI接頭辞を設定します。

4. 仮想ターゲットを管理サーバーにターゲット設定します。(通常は、仮想ターゲットのターゲットとして管理サーバーを指定することはありません。)

5. この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。

6. リソース・グループを作成します。

7. 仮想ターゲットをリソース・グループに追加します。

8. 変更をアクティブ化します。

9. パーティションを起動します。

注意:

これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。

10. ターゲットとしての管理サーバーを削除します。

11. 仮想ターゲットをCluster-0に移行(ターゲット指定)します。

# Create Pep partition and ResourceGroup
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> tgt=getMBean('/Servers/AdminServer')
wls:/base_domain/edit/ !> vt.addTarget(tgt)
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)
startEdit()
wls:/base_domain/edit/ !> vt.removeTarget(tgt)
wls:/base_domain/edit/ !> tgt=getMBean('/Clusters/Cluster-0')
wls:/base_domain/edit/ !> vt.addTarget(tgt)
wls:/base_domain/edit/ !> activate()

注意:

非ライブ移行中、パーティションのジョブ・スケジューラ・サービスで使用されるデータ・ソースを管理リソース・グループで構成する必要があります。これは、移行前にパーティションが停止したときに管理リソース・グループは停止しないためです。管理リソース・グループの詳細は、「パーティション・リソース・グループでの管理アプリケーションおよびリソースの管理」を参照してください。

パーティション・リソース・グループでの管理アプリケーションおよびリソースの管理

管理対象サーバーおよびクラスタで実行されるアプリケーション・コードに加えて、多数のアプリケーションおよびサービスに管理用とみなされるコンポーネントが含まれています。管理コンポーネントは主に管理サーバー上で実行され、パーティションが停止していても、これらのコンポーネントは実行を継続する必要があります。

管理アプリケーションは、1つ以上のエンド・ユーザー・アプリケーションで使用される一部のサポート・インフラストラクチャを管理します。通常、エンド・ユーザーには管理アプリケーションへのアクセス権はありません。例としては、企業向け製品や部品番号カタログ管理アプリケーションなどがあります。新製品の追加や、製品の販売終了に伴って内部ユーザーがカタログを更新する一方、エンド・ユーザー・アプリケーションは、エンド・ユーザー・トランザクションを実行するときにこのカタログを参照します。管理リソースの例として、カタログ・データが格納されているデータベースにアクセスするためにアプリケーションで使用するJDBCシステム・リソースをあげることができます。

管理アプリケーションおよびリソースが含まれているリソース・グループを管理リソース・グループに指定すると、パーティションを(SHUTDOWN.HALTED状態からSHUTDOWN.BOOTED状態にして)ブートしたときに、それらのアプリケーションは使用可能になりますが、エンド・ユーザー向けの非管理アプリケーションは使用可能になりません。パーティションのライフサイクル状態の詳細は、「パーティションのライフサイクル状態および遷移について」を参照してください。

管理リソース・グループの特徴:

- 管理アプリケーションおよびリソースが含まれています。

- 通常は、管理サーバーがターゲットとして指定されます。

- パーティション・ライフサイクル操作によって独自の方法で処理されます。詳細は、「パーティションのライフサイクル状態および遷移について」を参照してください。

このリリースでは、次のことが可能です。

- アプリケーションおよびリソースを管理リソース・グループに配置して、これらを管理用として指定します。

- パーティションの停止時に、管理アプリケーションおよびリソースの実行を継続します。

- 管理アプリケーションおよびリソースのターゲットとして管理サーバーを自動的に指定します。詳細は、「管理リソース・グループのターゲット指定」を参照してください。

管理リソース・グループの作成

パーティション管理リソース・グループ内のすべてのアプリケーションおよびリソースは(リソース・グループで直接定義されているか、リソース・グループ・テンプレートを使用して間接的に定義されているかに関係なく)、管理アプリケーションおよびリソースとみなされます。

管理リソース・グループを作成するには、リソース・グループのAdministrative属性をtrueに設定します。

WLST編集セッションが進行中で、rgが対象のResourceGroupMBeanを含む変数であると仮定すると、次のようになります。

rg.setAdministrative(true)

パーティションには、ゼロ個以上の管理リソース・グループを含めることができます。

管理リソース・グループのターゲット指定

他のリソース・グループと同様、管理リソース・グループのターゲットとして、仮想ターゲットまたはパーティションの管理用仮想ターゲット(使用可能である場合)を指定できます。詳細は、「パーティションの管理用仮想ターゲットについて」を参照してください。

このリリースでは、リソース・グループに新しいブール属性autoTargetAdminServerがあり、これはデフォルトではfalseになっています。システム管理者がこの属性をtrueに設定すると、リソース・グループのターゲットとして管理サーバーが指定され、このことは、パーティションの管理用仮想ターゲットをリソース・グループ・ターゲットとして明示的に追加することと同じです。

WLST編集セッションが進行中で、rgが対象のResourceGroupMBeanを含む変数であると仮定すると、次のようになります。

rg.setAutoTargetAdminServer(true)

パーティションの管理用仮想ターゲットの詳細は、「パーティションの管理用仮想ターゲットについて」を参照してください。

パーティションのライフサイクル状態および遷移について

パーティション・ライフサイクルの状態を図8-1に示しています。このリリースでは、パーティション・ライフサイクルの状態は変更されていませんが、BOOTEDおよびHALTEDの2つのサブ状態がSHUTDOWN状態に追加されています。

図8-1 パーティション・ライフサイクルの状態

パーティションを停止すると、SHUTDOWN.BOOTED状態になります。パーティションがSHUTDOWN.BOOTED状態である場合、管理リソース・グループは実行されていますが、その他すべてのリソース・グループは停止されています。

パーティションがSHUTDOWN.HALTED状態である場合、パーティションのすべてのリソース・グループは停止されており、パーティションはすべてのターゲット上で完全に停止されています。

新しく作成されるパーティションはSHUTDOWN.HALTED状態で作成されます。パーティションは、SHUTDOWN.BOOTEDまたはSHUTDOWN.HALTEDのいずれかの状態から起動できます。

次の表に、パーティションの作成から実行までの、パーティション・ライフサイクルの状態の考えられるワークフローの1つを示します。

操作

パーティションの状態

パーティションのサブ状態

リソース・グループのアクティビティ

パーティションの作成

SHUTDOWN

HALTED

該当せず

管理リソース・グループおよび非管理リソース・グループの作成

SHUTDOWN

HALTED

リソース・グループは実行されていません。

パーティションおよびリソース・グループのターゲット指定

SHUTDOWN

HALTED

リソース・グループは実行されていません。

パーティションの起動

RUNNING

NA

すべてのリソース・グループが実行されています。

パーティションの停止

SHUTDOWN

BOOTED

管理リソース・グループのみが実行されています。

パーティションの一時停止

SHUTDOWN

HALTED

リソース・グループは実行されていません。

パーティション構成の変更の中には、有効にするためにパーティションの再起動を必要とするものがあります。このことは、通常、パーティションを停止してから再起動することで行います。管理リソース・グループに対する変更の場合は、パーティションを一時停止してから起動するか、管理リソース・グループを個別に再起動する必要があります。

次の新しいライフサイクル操作がパーティションでサポートされます。

- halt(): パーティションはSHUTDOWN.BOOTED、ADMINまたはRUNNING状態からSHUTDOWN.HALTED状態になります。

- boot(): パーティションはSHUTDOWN.HALTED状態からSHUTDOWN.BOOTED状態になります。

まとめると、次のようになります。

- パーティションをブートすると、SHUTDOWN.HALTED状態からSHUTDOWN.BOOTED状態になります。管理アプリケーションのみが実行されています。パーティション管理者はパーティションを管理できますが、エンド・ユーザーはエンド・ユーザー向けアプリケーションにアクセスできません(アプリケーションが実行されていないため)。

- パーティションを起動すると、SHUTDOWN状態(SHUTDOWN.HALTEDまたはSHUTDOWN.BOOTED状態)からRUNNING状態になります。すべてのアプリケーションが実行されています。

- パーティションを停止すると、RUNNINGまたはADMIN状態からSHUTDOWN.BOOTED状態になります。管理アプリケーションが実行されています。パーティション管理者はパーティションを管理できますが、エンド・ユーザーはアプリケーションにアクセスできません。

- パーティションを一時停止すると、RUNNINGまたはADMIN状態またはSHUTDOWN.BOOTED状態からSHUTDOWN.HALTED状態になります。アプリケーションはパーティションで実行されていません。パーティション管理者はパーティションを管理できません。

リソース・グループの構成: 関連タスクおよびリンク

リソース・グループ関連の詳細は、次の項を参照してください。

- Oracle WebLogic Server Multitenant

- 仮想ターゲットの構成

- リソース・グループ・テンプレートの構成

- リソース・オーバーライドの構成

- メッセージングの構成

9 リソース・オーバーライドの構成

この章では、リソース・オーバーライドについて、およびその構成方法について説明します。この章の説明に従い、Oracle Enterprise Manager Fusion Middleware Control (FMWC)、Oracle WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して、リソース・オーバーライドを構成できます。この章では、適宜追加情報について、Fusion MiddlewareとWebLogic Serverのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章の内容は次のとおりです。

- リソース・オーバーライド: 概要

- リソースMBeanオーバーライドの構成: 主な手順およびWLSTの例

- リソース・デプロイメント・プランの構成: 主な手順およびWLSTの例

- リソース・オーバーライドの構成: 関連タスクおよびリンク

リソース・オーバーライド: 概要

リソース・オーバーライドによって、管理者は、パーティション・レベルでリソースをカスタマイズできます。リソース・グループ・テンプレートを拡張するリソース・グループを含むパーティションを作成する場合は、そのリソース・グループ・テンプレートで定義されている特定のリソースの設定をオーバーライドできます。リソース・グループ・テンプレートを拡張しないリソース・グループをパーティション内に作成し、このリソース・グループ内にリソースを作成する場合、オーバーライドは不要で、これらのリソースにパーティション固有の値を設定します。オーバーライドは、主にリソースに共通の定義が存在する場合に、リソース・グループ・テンプレートなどで使用されます。

リソース・グループ・テンプレートは、WebLogic Server Multitenant (MT)が同じアプリケーションとリソースを複数回(ドメイン・パーティションごとに1回ずつ)アクティブ化するSoftware-as-a-Service (SaaS)環境で特に役立ちます。そのようなリソースに関する情報は、すべてのドメイン・パーティション間で同じ情報もあれば、JMSキューやデータベース接続など、パーティションごとに異なる情報もあります。たとえば、異なるパーティション間でデータ・ソースに接続するために使用されるURL、ユーザー名およびパスワードをカスタマイズする必要があります。

管理者は、次の手法を使用して、パーティションのリソース定義をオーバーライドできます。

- リソース・オーバーライド構成MBean: 既存のリソース構成MBeanの属性のサブセットを公開する構成MBean。オーバーライド構成MBeanのインスタンス上の属性セットは、対応するリソース構成MBeanインスタンス内のその属性の値を置き換えます。

- リソース・デプロイメント・プラン: パーティション内のリソースを識別し、それらのリソースの属性設定をオーバーライドするXMLファイル。

- パーティション固有のアプリケーション・デプロイメント・プラン: アプリケーション・デプロイメント・プランと同様に、管理者は、パーティション内のアプリケーション・デプロイメントごとに、パーティション固有のアプリケーション・デプロイメント・プランを指定できます。パーティション固有のアプリケーション・デプロイメント・プランの詳細は、「パーティション固有のデプロイメント・プランの使用方法」を参照してください。

管理者は、これらのリソース・オーバーライド手法を任意に組み合せることができます。システムでは、次に示す昇順の優先度でこれらが適用されます。

- パーティション固有のアプリケーション・デプロイメント・プランを含む、config.xmlファイルおよび外部ディスクリプタ

- リソース・デプロイメント・プラン

- オーバーライド構成MBean
属性がリソース・デプロイメント・プランおよびオーバーライド構成MBeanの両方で参照される場合、オーバーライド構成MBeanが優先されます。

構成MBeanオーバーライドの使用方法

オーバーライド構成MBeanでは、JMSキューまたはデータベース接続の属性など、頻繁に調整される属性をカスタマイズできます。オーバーライド構成MBeanの属性は、属性が置かれている場所に応じて、リソースのconfig.xml設定をオーバーライドするか、またはリソースの外部ディスクリプタの設定をオーバーライドします。

このリリースでは、WebLogic Server MTは、次のリソース・オーバーライド構成MBeanを提供します。

- JDBCSystemResourceOverrideMBean

- JMSSystemResourceOverrideMBean

- ForeignServerOverrideMBean

- ForeignConnectionFactoryOverrideMBean

- ForeignDestinationOverrideMBean

- MailSessionOverrideMBean

リソース構成オーバーライドMBeanは、通常、オーバーライド構成MBeanの名前をリソースMBeanの名前と照合することで機能します。詳細は、「リソースMBeanオーバーライドの構成: 主な手順およびWLSTの例」を参照してください。

リソース・デプロイメント・プランの使用方法

リソース・デプロイメント・プランは、単一のパーティション内の1つ以上のリソースの属性をオーバーライドするXMLファイルです。各パーティションは、そのパーティション内の任意のリソースをオーバーライドできるリソース・デプロイメント・プランを最大で1つ持つことができます。これには、パーティションのリソース・グループが参照するリソース・グループ・テンプレートで定義されているリソース、およびリソース・グループで直接宣言されているリソースが含まれます。

サーバーが再起動すると、リソース・デプロイメント・プラン(およびオーバーライド構成MBean)からの動的でない属性への変更は、リソースがアクティブになる前に適用されます。所定のリソースが実行された後、そのリソースの動的でない属性に影響する、リソース・デプロイメント・プランに対する変更は、パーティションが再起動されるまで有効になりません。

リソース・デプロイメント・プランを次のリソースとともに使用して、config.xmlファイルまたは外部ディスクリプタ・ファイルで構成されているオプションをオーバーライドできます。

- CoherenceClusterSystemResource

- FileStore

- ForeignJNDIProvider

- JDBCStore

- JDBCSystemResource

- JMSBridgeDestination

- JMSServer

- JMSSystemResource

- MailSession

- ManagedExecutorService

- ManagedScheduledExecutorService

- ManagedThreadFactory

- MessagingBridge

- PathService

- SAFAgent

- WLDFSystemResource

resource-deployment-plan構文

リソース・デプロイメント・プランは、weblogic-resource-deployment-plan.xsdファイルに基づくもので、WebLogic Serverアプリケーション・デプロイメント・プランに対して同様の構文があります。リソース・デプロイメント・プランは、変更対象のリソースおよび属性値を識別し、値の置換、新しい値の追加、および既存の値の削除をサポートします。

resource-deployment-plan構文のサマリーは次のとおりです。

resource-deployment-plan (@global-variables)
description
version
variable-definition
variable*
name
value
external-resource-override*
resource-name
resource-type
root-element
variable-assigment*
name
xpath
config-resource-override*
resource-name
resource-type
variable-assigment*
name
xpath
operation

@記号はXML属性を示し、アスタリスク(*)は要素が繰返し可能であることを意味します。operation要素はオプションですが、external-resource-override要素内であるかconfig-resource-override要素内であるかに関係なく、任意のvariable-assignment要素で使用できます。

リソース・デプロイメント・プラン内の基本要素は、次の関数に対する処理を行います。

- resource-deployment-planは、ルート要素であり、リソース・デプロイメント・プランの内容すべてをカプセル化します。

- variable-definitionは、1つまたは複数のvariable要素を定義します。各variableは、プラン内で使用される変数のname、および割り当てるvalue(nullでも可)を定義します。「サンプル・リソース・デプロイメント・プラン」に示すサンプル・プランには、メール・セッション・ユーザー名、メール・セッションJavaMailプロパティ、JDBC接続プール・パラメータ、テスト対象の表名プロパティに加えた変更に対する変数定義が含まれます。

- 各external-resource-overrideとconfig-resource-override要素(およびそれらの子要素)は、次の3つを実行します。

1. 影響するリソースを識別します(resource-nameおよびresource-type)。
パーティション内のリソースは、そのパーティション内で一意の名前を持つ必要があります。

2. 属性が定義される場所を特定します。
config-resource-override要素のすべての属性は、config.xmlファイルにあります。external-resource-override要素の属性は、外部ディスクリプタ・ファイルに格納されます。リソース・デプロイメント・プランの場合、ディスクリプタ・パスは、パーティションのconfig/ディレクトリに相対的です

3. そのリソースの属性をいくつか指定して、(variable-assignment要素を)オーバーライドします。
リソースの属性が見つかると、variable-assignment要素が適用されます。XPath式で、影響を受ける属性がbeanツリーに表示される場所(特定されるリソースのbeanに相対的)を示します。nameは、事前に定義されたvariable定義を示します。そのvariableは、元の属性設定に含まれるものを置換するvalueも設定します。

デフォルトでは、variable-assignment要素の値は記述子内で定義済みの値に追加されます。variable-assignment要素内のoperation下位要素を、それぞれreplaceまたはremoveの各値に設定することにより、variable-assignment要素が記述子内で定義された値を置き換えるように、またはこれらの値を削除するように、この動作を変更できます。

WebLogic Serverリソース・デプロイメント・プランの内容の詳細は、http://xmlns.oracle.com/weblogic/resource-deployment-plan/1.0/resource-deployment-plan.xsdを参照してください。WebLogic Serverアプリケーション・デプロイメント・プランの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・プランの内容の理解に関する項を参照してください。

サンプル・リソース・デプロイメント・プラン

次に、サンプル・リソース・デプロイメント・プランを示します。

<resource-deployment-plan
xmlns="http://xmlns.oracle.com/weblogic/resource-deployment-plan"
xmlns:xsi="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/resource-deployment-plan http://xmlns.oracle.com/weblogic/resource-deployment-plan/1.0/resource-deployment-plan.xsd"
>
<description>Example RDP</description>
<variable-definition>
<variable>
<name>mailNewSessionUsername</name>
<value>aaron</value>
</variable>
<variable>
<name>mailNewProps</name>
<value>mail.user=someoneElse;mail.host=myMailServer.oracle.com</value>
</variable>
<variable>
<name>jdbcTableToTest</name>
<value>JUNK_TABLE</value>
</variable>
</variable-definition>
<external-resource-override>
<resource-name>myjdbc</resource-name>
<resource-type>jdbc-system-resource</resource-type>
<root-element>jdbc-data-source</root-element>
<variable-assignment>
<name>jdbcTableToTest</name>
<xpath>/jdbc-data-source/jdbc-connection-pool-params/test-table-name</xpath>
</variable-assignment>
</external-resource-override>
<config-resource-override>
<resource-name>myMail</resource-name>
<resource-type>mail-session</resource-type>
<variable-assignment>
<name>mailNewSessionUsername</name>
<xpath>/mail-session/session-username</xpath>
</variable-assignment>
<variable-assignment>
<name>mailNewProps</name>
<xpath>/mail-session/properties</xpath>
</variable-assignment>
</config-resource-override>
</resource-deployment-plan>

リソースMBeanオーバーライドの構成: 主な手順およびWLSTの例

ドメイン・パーティションにリソース・オーバーライドを作成する前に、オーバーライドするリソースをリソース・グループ・テンプレートで最初に定義しておく必要があります。

JDBCシステム・リソース・オーバーライドの構成: 主な手順

JDBCシステム・リソース・オーバーライドを構成する主な手順は次のとおりです。

1. オーバーライドするデータ・ソースの名前でJDBCシステム・リソース・オーバーライドを作成します。

2. オプションで、パーティション固有のURL、ユーザー名およびパスワードの値を指定します。

3. リソースが実行中の場合は、オーバーライドを有効にするために、パーティションを再起動します。

JDBCシステム・リソース・オーバーライドの構成: WLSTの例

次の例は、WLSTを使用してJDBCシステム・リソース・オーバーライドを構成する方法を示しています。

edit()
startEdit()
cd('/Partitions/myPartition')
cmo.createJDBCSystemResourceOverride('myGDS')

cd('/Partitions/myPartition/JDBCSystemResourceOverrides/myJDBCSystemResourceOverride')
cmo.setURL('jdbc:oracle:thin:@lcr01156:1521:wldevdb2')
cmo.setUser('admin')
setEncrypted('Password', 'Password_1440013198602', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Config', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Secret')
activate()

JMSシステム・リソース・オーバーライドの構成: 主な手順

JMSシステム・モジュールや外部サーバー・オーバーライドを構成する主な手順は次のとおりです。

1. 外部サーバー・オーバーライドの名前を指定します。
システムでは、オーバーライド構成MBeanの名前を使用するオーバーライドと、オーバーライドされる実際のリソースの名前を照合します。

2. オプションで、初期コンテキスト・ファクトリ、接続URL、JNDIプロパティ資格証明およびJNDIプロパティのパーティション固有の値を指定します。

3. リソースが実行中の場合は、オーバーライドを有効にするために、パーティションを再起動します。

JMS外部サーバー・オーバーライドや外部宛先オーバーライドを構成する主な手順は次のとおりです。

1. 外部宛先オーバーライドの外部JMS宛先名を指定します。
この外部宛先オーバーライドの名前は、オーバーライドされる実際のリソースの名前に一致している必要があります。

2. オプションで、パーティション固有のリモートJNDI名の値を指定します。

3. リソースが実行中の場合は、オーバーライドを有効にするために、パーティションを再起動します。

JMS外部サーバー・オーバーライドや外部接続ファクトリ・オーバーライドを構成する主な手順は次のとおりです。

1. 外部接続ファクトリ・オーバーライドの外部JMS接続ファクトリ名を指定します。

この外部接続ファクトリ・オーバーライドの名前は、オーバーライドされる実際のリソースの名前に一致している必要があります。

2. オプションで、リモートJNDI名、ユーザー名およびパスワードのパーティション固有の値を指定します。

3. リソースが実行中の場合は、オーバーライドを有効にするために、パーティションを再起動します。

JMSシステム・リソース・オーバーライドの構成: WLSTの例

次の例は、WLSTを使用してJMSシステム・リソース・オーバーライドを構成する方法を示しています。

edit()
startEdit()
cd('/Partitions/myPartition')
cmo.createJMSSystemResourceOverride('myJMSmoduleOverride')
activate()

startEdit()
cd('/Partitions/myPartition/JMSSystemResourceOverrides/myJMSmoduleOverride')
cmo.createForeignServer('newJMSforeignServer')

cd('/Partitions/myPartition/JMSSystemResourceOverrides/myJMSmoduleOverride/ForeignServers/newJMSforeignServer')
setEncrypted('JNDIPropertiesCredential', 'JNDIPropertiesCredential_1440013308523', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Config', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Secret')
cmo.setConnectionURL('java.naming.provider.url')
cmo.setInitialContextFactory('weblogic.jndi.WLInitialContextFactory')
activate()

startEdit()
cmo.createForeignDestination('myForeignDestinationOverride')
cd('/Partitions/myPartition/JMSSystemResourceOverrides/myJMSmoduleOverride/ForeignServers/newJMSforeignServer/ForeignDestinations/myForeignDestinationOverride')
cmo.setRemoteJNDIName('/remote')
activate()

startEdit()
cd('/Partitions/myPartition/JMSSystemResourceOverrides/myJMSmoduleOverride/ForeignServers/newJMSforeignServer')
cmo.createForeignConnectionFactory('myJMSconnectionFactoryOverride')

cd('/Partitions/myPartition/JMSSystemResourceOverrides/myJMSmoduleOverride/ForeignServers/newJMSforeignServer/ForeignConnectionFactories/myJMSconnectionFactoryOverride')
setEncrypted('Password', 'Password_1440013370283', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Config', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Secret')
cmo.setUsername('wlsqa')
cmo.setRemoteJNDIName('/remote')
activate()

メール・セッション・オーバーライドの構成: 主な手順

メール・セッション・オーバーライドを構成する主な手順は次のとおりです。

- メール・セッション・オーバーライドの名前を指定します。
システムでは、オーバーライド構成MBeanの名前を使用するオーバーライドとリソースMBeanの名前を照合します。

- オプションで、セッション・ユーザー名、セッション・パスワードおよびJavaMailプロパティのパーティション固有の値を指定します。

- リソースが実行中の場合は、オーバーライドを有効にするために、パーティションを再起動します。

メール・セッション・オーバーライドの構成: WLSTの例

次の例は、WLSTを使用してメール・セッション・オーバーライドを構成する方法を示しています。

edit()
startEdit()
cd('/Partitions/myPartition')
cmo.createMailSessionOverride('myMailSessionOverride')
cd('/Partitions/myPartition/MailSessionOverrides/myMailSessionOverride')
cmo.setSessionUsername('wlsqa')
setEncrypted('SessionPassword', 'SessionPassword_1440013452297', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Config', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Secret')
cmo.setProperties({})
activate()

リソース・デプロイメント・プランの構成: 主な手順およびWLSTの例

リソース・デプロイメント・プランを構成する主な手順は次のとおりです。

1. XMLエディタを使用して、リソース・デプロイメント・プランを作成します。「resource-deployment-plan構文」および「サンプル・リソース・デプロイメント・プラン」を参照してください。

2. リソース・デプロイメント・プラン・ファイルへのパスを指定して、リソース・デプロイメント・プランをパーティションに関連付けます。

3. リソースが実行中の場合は、パーティションを再起動します。

次に、リソース・デプロイメント・プランを既存のパーティションに関連付けるWLSTコマンドを示します。

edit()
startEdit()
partition=cmo.lookupPartition(partitionName)
partition.setResourceDeploymentPlanPath('/path/to/the/file.xml')
save()
activate()

リソース・オーバーライドの構成: 関連タスクおよびリンク

次の追加情報を参照してください。

- 『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverリソース・オーバーライドに関する項。

- 『Oracle WebLogic Server管理コンソール・オンライン・ヘルプ』のJDBCオーバーライドに関する項、メール・セッション・オーバーライドに関する項およびJMSオーバーライドに関する項。

10 リソース消費管理の構成

この章では、サーバー・インスタンスに配置されたドメイン・パーティションによって、リソース割当ての公平性を保証し、共有リソースの競合を減らす、リソース消費管理(RCM)の使用方法について説明します。Oracle Enterprise Manager Fusion Middleware Control (FMWC)またはWebLogic Scripting Tool (WLST)を使用してRCMポリシーを作成して、マルチテナント環境でドメイン・パーティションの一貫したパフォーマンスを提供できます。

この章の内容は次のとおりです。

- リソース消費管理の構成: 概要

- リソース消費管理の構成: 主な手順

- リソース・マネージャの動的再構成

- リソース消費管理の構成: リソース使用量のモニタリング

- リソース消費管理を使用する際のベスト・プラクティスおよび考慮事項

- RCMの制限事項

- リソース消費管理の構成: WLSTの例

- リソース消費管理の構成: 関連タスクおよびリンク

リソース消費管理の構成: 概要

リソース消費管理(RCM)は、共有リソースを管理し、MT環境でドメイン・パーティションの一貫したパフォーマンスを提供するために、WebLogic Serverシステム管理者に柔軟性のある動的なメカニズムを提供します。

RCMポリシーは、リソース・マネージャとして構成されます。ドメイン・レベルのグローバル・スコープでリソース・マネージャを作成して、ドメイン内の任意のパーティションに対してRCMポリシーとして使用できます。パーティションにそのパーティションに固有のRCM特性がある場合は、パーティション・スコープのリソース・マネージャを作成することもできます。「リソース消費管理の構成: 主な手順」を参照してください

RCMを使用するためのソフトウェア要件

RCMには、Oracle Java Development Kit (JDK) 8u60ビルド32以降が必要です。

リソース消費管理が必要な理由

アプリケーションが複数のドメイン・パーティションにデプロイされた場合、低レベルのリソース(CPU、ヒープ、ネットワーク、ファイル・ディスクリプタなど)を共有すると、リソース割当てが不公平になる可能性があります。高トラフィック、アプリケーション設計、悪質なコードなどの様々な理由により、異常なリソース消費のリクエストが発生する可能性があります。これらのリクエスト・タイプにより、別に配置されたドメイン・パーティションがリソースにアクセスしないように、共有リソースの容量が過負荷となります。ドメイン・パーティション・レベルで適切なRCMポリシーを使用することによって、リソース消費管理は、あるパーティションのアプリケーションが他のパーティションのアプリケーションに悪影響を及ぼさないようにします。

RCMを有効化する方法

次のJVM引数を設定して、環境内でRCMを有効化します。

-XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC

このフラグは、RCMが有効化されるすべてのサーバー・インスタンス(JVM)に適用する必要があります。

代替方法は、ドメインの作成時に作成されるstartWeblogic.shファイル内の次のJAVA_OPTIONSをコメント解除することです。

#JAVA_OPTIONS="-XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC ${SAVE_JAVA_OPTIONS}

これは、各サーバー・インスタンスで行う必要があり、WebLogic Serverインスタンスの起動前に行う必要があります。

WebLogic ServerでJavaセキュリティ・マネージャが使用される場合、RCMは、weblogic.policyで次の権限を付与する必要があります。

permission RuntimePermission("jdk.management.resource.getResourceContextFactory")

Javaセキュリティ・マネージャを使用したWeblogic Serverのリソースの保護の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaセキュリティ・マネージャを使用したWebLogicリソースの保護に関する項を参照してください。

RCMのサポートされるリソース

次の共有リソースは、RCMポリシーで管理できます。

- FileOpen: パーティションで使用中の開いているファイル・ディスクリプタの数。これには、FileInputStream、FileOutputstream、RandomAccessFileおよびNIO Fileのチャネルを介して開いているファイルが含まれます。

- HeapRetained: パーティションで保存される/使用中のヒープの量(MB)。

- CpuUtilization: WebLogic Serverプロセスの使用可能なCPU時間に対する、パーティションで使用されるCPU時間の割合。

リソース消費管理の構成: 主な手順

システム管理者は、リソース・マネージャを使用して、ドメインのパーティションごとに共有リソースに対するリソース消費管理ポリシーを指定します。リソース・マネージャは、1つ以上の共有リソースに対する1つ以上のポリシーで構成されます。各ポリシーは、リソースに対する制約値と、制約値に達したときにWebLogic Serverインスタンスによって実行される指定されたアクションで構成されます。

次のRCMポリシー・タイプがサポートされています。

- トリガー

- フェア・シェア

トリガー

トリガーは、許可されるリソース使用量の静的制約値を定義します。そのリソースの使用量が制約値を超えると、指定したアクションが実行されます。このポリシー・タイプは、ドメインのパーティションによるリソース使用量が予測可能である環境に最適です。

システム管理者は、トリガー・ポリシーの作成時に、次のアクションを選択できます。

- Notify: 制約値に達したことがシステム管理者に通知されます。リソースに複数のNotifyトリガーを追加できます。たとえば、Open Filesが20を超えたときにNotify、Open Filesが50を超えたときにNotifyなどです。また、WebLogic診断フレームワーク(WLDF)を使用して、ログ・メッセージをリスニングするようにウォッチ・ルールを作成し、拡張通知を行うことができます。

- Slow: リソースの消費率を低下します。Slowアクションがトリガーされると、パーティション・ワーク・マネージャのフェア・シェア値が減少し、パーティションで使用可能になったthread-usage timeが減少します。パーティション・ワーク・マネージャの詳細は、「パーティション・ワーク・マネージャの構成」を参照してください。

- Fail: 使用量が制約値を下回るまで、リソースのリソース消費リクエストが失敗します。

注意:

FailはOpen Filesに対してのみ適用可能で、その他のリソースには適用できません。

たとえば、パーティションP1の開かれたファイルの数を100ファイル未満に制限するには、P1パーティションに対してOpen Filesリソースの100個の制約値とFailアクションを持つトリガー・ポリシーを含むリソース・マネージャを作成します。

- Shutdown: クリーンアップを許可しているときにパーティションの停止を開始します。このアクションは、パーティションが既知の制約値を超え、ドメイン内の他のパーティションによって使用される共有リソースの悪影響が予想される場合に役立ちます。パーティションは、制約値に達した管理対象サーバーでのみ停止し、クラスタ環境での継続的な可用性が実現します。FailトリガーとShutdownトリガーは一緒に使用しないでください。

- Restart: パーティションのリソース消費量の割当て違反が発生しているサーバー・インスタンスでパーティションを再起動します。多くの場合、アプリケーションが一時的に誤動作しており、単に再起動することで状況が修正されます。システム管理者の介入が必要となる場合もありますが、このパーティションの自動再起動アクションを有効にするほうが理想的です。その他のRCMアクションと同様、パーティションの再起動アクションは特定の管理対象サーバーにのみスコープ指定されています。
さらに、パーティションの再起動がループすることを防ぐために、次のオプションの構成プロパティを指定できます。

- max-restart-allowed
指定した期間内で許容される、RCMで始動されたパーティションの再起動の最大数。これを超えると、RCM始動のパーティションの再起動リクエストでパーティションが一時停止されます。

- max-restart-allowed-interval
max-restart-allowed-intervalは、指定した数(max-restart-allowed)のRCM始動のパーティションの再起動が許可される、固定幅のスライディング・ウィンドウ期間(秒単位)です。max-restart-allowed-interval内にmax-restart-allowed数を超えるパーティションの再起動リクエストがあると、パーティションは再起動されず、一時停止されます。

- restart-delay
パーティションを起動する前に組み込まれる遅延(秒単位)。

RCMポリシーでのこれらのプロパティは、config.xmlファイルの<resource-manager>で定義できます。特定のRCMポリシー内のすべての再起動アクションが、これらの構成可能プロパティの値を共有します。管理者は、パーティションが再起動されるときの再起動の遅延も指定できます。構成された遅延はパーティションの起動前に組み込まれ、パーティションが短期間に繰り返し再起動されたり、一時的な外部エラー状態が解消されるよりも前に再起動されることを防ぎます。

次に、RCM再起動アクションのサンプル構成を示します。

<resource-manager>
<name>ResourceManager-1</name>

<restart-loop-protection>

<!--This indicates whether restart loop protection is enabled or
not. If you want to disable the restart loop protection,
set this flag to false. -->
<restart-loop-protection-enabled>true</restart-loop-protection-enabled>

<!-- The partition can be restarted a maximum of 3 times in 60 minutes
by the RCM restart action. Subsequently, the partition
would be halted. -->
<max-restart-allowed>3</max-restart-allowed>

<!-- Within any contiguous interval of 60 minutes,
a maximum number of 3 restarts are allowed,
as specified by the max-restart-allowed property. -->
<max-restart-allowed-interval>3600</max-restart-allowed-interval>

<!-- Introduce a delay of 10 seconds before starting the
partition. -->
<restart-delay>10</restart-delay>
</restart-loop-protection>

<file-open>
<name>RM1-FileOpenResource</name>
<trigger>
<name>RM1-Trigger-1</name>
<value>20</value>
<action>restart</action>
</trigger>
</file-open>
</resource-manager>

構成された再起動アクションのトリガーを超えると、次の図に示すようにパーティションの再起動リクエストが生成されます。

注意:

ポリシー・アクションは、アクション・タイプに応じて同期的にも非同期的にも実装されます。たとえば、Failアクションは、開いているファイルをリクエストしたスレッドを同期的に使用します。その他のアクション(Heap Retainedリソースに構成されたSlowアクションなど)は、非同期的に続行します。

フェア・シェア

フェア・シェア・ポリシーにより、システム管理者が、ドメイン内の各パーティションの代表的な負荷に基づき、シェア(使用可能リソースのパーセンテージ)を割り当てることができます。フェア・シェア・ポリシーが使用されるのは、リソースの使用量の正確な要件を決定できない場合、またはリソースを効率的および公平に利用できるようにリソース・マネージャを使用する際に実装することが現実的ではない場合です。特定のリソースについてドメインのパーティション間で競合がない場合、各パーティションでその即時のワークロードに必要なリソースの量を使用できます。特定のリソースについてパーティション間で競合がある場合、各パーティションは使用可能リソースのフェア・シェアのみの使用に制約されます。メモリー消費全体が使用可能な最大メモリー(メモリー不足例外となる)を超えないように、制限が設定されていることを確認します。

リソースのフェア・シェアの割当ての決定

シェアは、リソースの指定された量を使用するための割当てです。システム管理者が、関連するリソース・マネージャのフェア・シェア・ポリシーで1から1000までの整数値を指定して、パーティションにシェアを割り当てます。ドメインの同じリソースのすべてのフェア・シェア値の合計に対する、特定のパーティションのその構成されたフェア・シェア値の比率によって、割り当てられるリソースの量が決定します。

たとえば、システム管理者がパーティションP1でリソースに対して150のフェア・シェア値を指定し、パーティションP2で同じリソースに対して100の値を指定します。ワークロードが両方のパーティションでそのリソースの競合を作成するのに十分に高い場合、パーティションP1のリソース割当ては、150/(150+100)または使用可能なリソースの60パーセントです。

リソース・マネージャの作成

リソース・マネージャは、1つ以上の共有リソースに対する1つ以上のポリシーで構成されます。各ポリシーは、リソースに対する制約値と、制約値に達したときにWebLogic Serverインスタンスによって実行される指定されたアクションで構成されます。

リソース・マネージャを構成するには、次を参照してください。

- 『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・マネージャの作成に関する項。

- リソース消費管理の構成: WLSTの例

config.xmlでのRCMの構成例

次の例は、「リソース消費管理の構成: WLSTの例」に表示されたWLSTの例に類似した、注釈が付いたRCM構成です。

<domain>
...
<!--Define RCM Configuration -->
<resource-management>
<resource-manager>
<name>Approved</name>
<file-open>
<trigger>
<name>Approved2000</name>
<value>2000</value><!-- in units-->
<action>shutdown</action>
</trigger>
<trigger>
<name>Approved1700</name>
<value>1700</value>
<action>slow</action>
</trigger>
<trigger>
<name>Approved1500</name>
<value>1500</value>
<action>notify</action>
</trigger>
</file-open>
<heap-retained>
<trigger>
<name>Approved2GB</name>
<value>2097152</value>
<action>shutdown</action>
</trigger>
<fair-share-constraint>
<name>FS-ApprovedShare</name>
<value>60</value>
</fair-share-constraint>
</heap-retained>
</resource-manager>

<resource-manager>
<name>Trial</name>
<file-open>
<trigger>
<name>Trial1000</name>
<value>1000</value><!-- in units-->
<action>shutdown</action>
</trigger>
<trigger>
<name>Trial700</name>
<value>700</value>
<action>slow</action>
</trigger>
<trigger>
<name>Trial500</name>
<value>500</value>
<action>notify</action>
</trigger>
</file-open>
...
</resource-manager>

<resource-manager>
<name>RestartPartition</name>
<file-open>
<name>FileOpenQuota</name>
<trigger>
<name>MaxFileOpenAllowed</name>
<value>20</value>
<action>restart</action>
</trigger>
</file-open>
<restart-loop-protection>
<restart-loop-protection-enabled>true</restart-loop-protection-enabled>
<max-restart-allowed>3</max-restart-allowed>
<max-restart-allowed-interval>3600
</max-restart-allowed-interval>
<restart-delay>10</restart-delay>
</restart-loop-protection>
</resource-manager>
</resource-management>

<partition>
<name>Partition-0</name>
<resource-group>
<name>ResourceTemplate-0_group</name>
<resource-group-template>ResourceTemplate-0</resource-group-template>
</resource-group>
...
<partition-id>1741ad19-8ca7-4339-b6d3-78e56d8a5858</partition-id>

<!-- RCM Managers are targeted to partitions during partition
creation or later by system administrators. -->
<resource-manager-ref>Approved</resource-manager-ref>
...
</partition>
..
</domain>

リソース・マネージャの動的再構成

ドメイン・パーティションから、リソース管理ポリシーを動的に適用または削除できます。リソース管理ポリシーへの変更は、そのポリシーを使用するすべてのドメイン・パーティションに適用されます。

アクティブなドメイン・パーティションのポリシー更新が、リソースの現在の使用量より低いリソースに対してトリガー値を設定した場合、そのリソースのその後の使用量には、ポリシーのリコース・アクションが適用されています。ポリシーを変更すると、現在の使用量の値に基づいてアクティブなドメイン・パーティションが即時停止される場合、その変更は、動的再構成の変更として受け入れられません。

リソース消費管理の構成: リソース使用量のモニタリング

パーティション内の共有リソースのRCMメトリックは、PartitionResourceMetricsRuntimeMBeanを介して使用可能になります。

これらのメトリックは次のために使用できます。

- パーティションでの現在のリソース使用量をモニターします。

- パーティションのリソース消費をプロファイルおよび分析して、有効なリソース・マネージャとWLDFウォッチおよび通知を作成するために必要な、代表的な負荷、ピーク負荷、ピーク負荷時間などのデータを生成します。

Fusion Middleware Controlでリソース・マネージャをモニターするには、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・マネージャのモニターに関する項を参照してください。

デフォルトでは、リソース・メーターの即時登録は無効です。そのため、特定のリソースについてリソース消費メトリックの問合せが初めて行われたときに作成されます。その場合、リソース・アカウンティングが遅れて開始されていて、リソース消費メトリックから返される値がパーティションで消費されたリソースの実際の値と異なることがあります。

パーティションで消費されたリソース量が正しく反映された値を得るには、メーターをパーティションの起動時に即座に登録する必要があります。リソース・メーターの即時登録を有効にするには、WebLogic Serverインスタンスの起動時に、JVM引数としてweblogic.rcm.enable-eager-resource-meter-registrationプロパティをtrueに設定します。

リソース消費管理を使用する際のベスト・プラクティスおよび考慮事項

次の各項では、リソース管理ポリシーを開発するシステム管理者のベスト・プラクティスと考慮事項について説明します。

- 一般的な考慮事項

- リソースの平均使用率およびピーク使用率のモニター

- トリガーを使用する状況

- フェア・シェアを使用する状況

- 補足的ワークロードの使用

- パーティション・スコープのRCMポリシーを使用する状況

- CPU使用率の管理

- ヒープの管理

一般的な考慮事項

リコース・アクションは、システム管理者が慎重に選択する必要があります。多くのリソース間には、複雑な相互作用があります。たとえば、CPU使用率を低下させる(その結果、ドメイン・パーティションに割り当てられるスレッドが少なくなる)と、ヒープの常駐が増加し、これによって維持されるヒープ使用量に影響を与える可能性があります。

遅れたリコース・アクションを有効にするために、アプリケーションがスレッドを作成または管理することはできません。アプリケーションで、WebLogic Serverの機能(EJBタイマー、Common Jワーク・マネージャおよびタイマー、管理対象エグゼキュータ・サービス、バッチAPIなど)のいずれかを使用して、遅れたリコース・アクションが有効になるようにタスクを管理することをお薦めします。

リソースの平均使用率およびピーク使用率のモニター

RCMポリシーを指定する前に、システム管理者は、平均とピークのリソースの使用率データをモニターし、十分なヘッドルームでポリシーを構成して、リソースを効率的に使用することとサービス・レベル合意(SLA)を満たすことのバランスをとることをお薦めします。「リソース消費管理の構成: リソース使用量のモニタリング」を参照してください。

トリガーを使用する状況

対応するトリガーを実行する必要がある正確な限度を管理者が認識している場合に、トリガーを使用します。トリガーは、ファイルなどのリソースに対して構成されたしきい値を超えると実行され、ヒープやCPUなどのリソースに対して遅れる可能性があります。

フェア・シェアを使用する状況

フェア・シェア・ポリシーは、通常、バインド・サイズ共有のリソースが、競合するコンシューマによって効率的に(かつ十分に)共有されていることをシステム管理者が確認するために使用します。また、フェア・シェア・ポリシーは、パーティションによるリソースの正しい使用量を事前に正確に決定できないことをよく理解している場合に、システム管理者によって使用することもでき、システム管理者は、共在するパーティションへの共有リソースの公平な割当てが確実に行われるようにしながら、リソースを有効に利用します。パーティション間のリソースに補足的ワークロードがある場合に、環境内でフェア・シェア・ポリシーを使用します。「補足的ワークロードの使用」を参照してください

補足的ワークロードの使用

可能な場合は、パーティション間でピーク使用時間のバランスを調整してリソースの密度を最大化することで、ピーク使用時間が重複せず、かつ、それらの平均の合計が最大ピーク値を超えないようにします。一方、対立するワークロードがある場合、ピーク使用時間が重複し、平均の合計が最大のピーク値を超過します。

異なるリソースを実行するパーティション・ワークロードを配置することも考えてみます。たとえば、大部分がCPUバインドされたワークロードを持つパーティションと、メモリー・バインドされたワークロードを持つ別のパーティションをホストすると、密度および全体的なリソース使用状況が改善されます。

パーティション・スコープのRCMポリシーを使用する状況

パーティションに固有のリソース要件がある場合に、パーティション・スコープの動的なRCMポリシーを使用します。これらのポリシーにより、既存のドメインに対するパーティションRCMポリシーのインポートおよびエクスポートが容易になります。

リソース管理ポリシーがパーティションで明示的に設定されていない場合、そのパーティションの使用可能な共有リソースへのアクセスには制約がありません。

CPU使用率の管理

CPU使用率は、配置されたドメイン・パーティションによってCPUの競合を追跡する優れたメトリックで、CPUバインドされたワークロードのフェア・シェア・ポリシーで特に役立ちます。CPU使用率を最大化するためにRCMポリシーを使用する場合は、次のことを考慮します。

- ドメイン内のすべてのパーティションのワークロード(統合ワークロード)を考慮したときに、CPUのピーク使用率がCPUの平均使用率を大きく超えないようにする必要があります。CPUのピーク負荷とCPUの平均負荷の差を最小化すると、ドメインのCPU使用率を最大化できます。

- CPU使用率の約75%がドメインのパーティションに格納されたアプリケーションに使用されるようにRCMのCPUポリシーを構成することをお薦めします。残りの25%の10%ほどは操作タスク(バックアップ、スケジュール済タスクおよびその他の管理)に、15%ほどはクラスタ・フェイルオーバーに割り当てる必要があります。

ヒープの管理

ドメインおよびその他のシステム・ワークに十分な量の使用可能なヒープ(ヘッドルーム)を提供し続けながら、パーティションのアプリケーションの要件をサポートするメモリー使用プランを作成します。ドメインのヒープ要件を評価する際に、各パーティションの代表的なワークロードの低、平均、安定した状態およびピークのHeap Retainedの使用量の値を考慮します。

RCMの制限事項

次のRCMの制限事項に注意してください。

- ヒープ・リソース消費の追跡および管理は、G1ガベージ・コレクタで実行される場合のみサポートされます(他のJDKコレクタではRCMはサポートされません)。

- JNI/ネイティブ・コードで発生するアクティビティのリソース消費メトリックの測定および計上はサポートされていません。

- 保持されるヒープとCPU使用率の測定は非同期的に実行されるため、現在の(ポイント・イン・タイムの)値を表しません。

- 静的フィールド内のオブジェクトのヒープ使用状況の区別、およびシステムからロードされたクラスおよび共有クラス・ローダーのシングルトン・オブジェクトに問題があり、最終会計値で正確に表されない可能性があります。システムからロードされたクラスおよび共有クラス・ローダーのインスタンスがパーティションによってロードされた場合、インスタンスのヒープの使用がそのパーティションに対して計上されます。

- ガベージ・コレクション・アクティビティは、Oracle JDK 8u40を使用したWebLogic Server 12.2.1の特定のドメイン・パーティションに分離されません。

- サーバー・インスタンスでリソース消費の追加の追跡および管理が発生するため、RCM機能を有効にする際にパフォーマンスへの悪影響があります。

リソース消費管理の構成: WLSTの例

WLSTを使用して、RCMポリシーを実装およびモニターできます。

- RCMのWLSTの例: 概要

- RCMのWLSTの例: WLSTスクリプト

RCMのWLSTの例: 概要

次に、WLSTを使用してRCM構成を作成する例を示します。この例では、システム管理者によって次が定義されています。

- ドメインのすべてのProduction層を持つドメイン・パーティションに対してシステム管理者が確立する一連のリソース消費管理ポリシーを表すProductionリソース・マネージャ。Productionリソース・マネージャには様々なリソースに対するポリシーがあります。

- FileOpenリソース・タイプには、3つのトリガーが指定されています。Production2000トリガーにより、開いているファイル・ディスクリプタの数が2000に達したときにパーティションが停止されます。Production1700トリガーにより、開いているファイル・ディスクリプタの数が1700を超えたときに、ドメイン・パーティションを低速化する必要があることが指定されています。Production1500トリガーにより、通知アクションが指定されます。

- HeapRetainedリソース・タイプでは、Production2GBトリガーが作成され、パーティションの保持されるヒープ値が2GBに達したときにパーティションが停止されます。Productionリソース・マネージャに、60のフェア・シェア値が割り当てられています。

- Trialリソース・マネージャは同様に定義しますが、一連のポリシーが減少します。

- Partition-0という名前のパーティション。

このスクリプトが完了すると、Partition-0にProductionリソース・マネージャが割り当てられます。

RCMのWLSTの例: WLSTスクリプト

「RCMのWLSTの例: 概要」で説明されているポリシーは、次の例に示すWLSTスクリプトを使用して作成できます。

startEdit()

cd('/ResourceManagement')
cd(domainName)
rm=cmo.createResourceManager('Approved')
fo=rm.createFileOpen('Approved-FO')
fo.createTrigger('Approved2000',2000,'shutdown')
fo.createTrigger('Approved1700',1700,'slow')
fo.createTrigger('Approved1500',1500,'notify')
hr=rm.createHeapRetained('Approved-HR')
hr.createTrigger('Approved2GB',2097152,'shutdown')
hr.createFairShareConstraint('FS-ApprovedShare', 60)

cd('/ResourceManagement')
cd(domainName)
rm=cmo.createResourceManager('Trial')
fo=rm.createFileOpen('Trial-FO')
fo.createTrigger('Trial1000',1000,'shutdown')
fo.createTrigger('Trial700',700,'slow')
fo.createTrigger('Trial500',500,'notify')

cd('/ResourceManagement')
cd(domainName)
rm = cmo.createResourceManager('RestartPartition')
rlp = rm.getRestartLoopProtection()
rlp.setRestartLoopProtectionEnabled(true)
rlp.setMaxRestartAllowed(3)
rlp.setMaxRestartAllowedInterval(3600)
rlp.setRestartDelay(10)
fo = rm.createFileOpen('FileOpenQuota')
fo.createTrigger('MaxFileOpenAllowed',20,'restart')

save()
activate()

startEdit()
cd('/Partitions')
cd(partition-0)
cmo.setResourceManagerRef(getMBean('/ResourceManagement/'+domainName+'/ResourceManager/Approved'))
save()
activate()

リソース消費管理の構成: 関連タスクおよびリンク

この項では、環境へのRCMの実装時に便利な追加情報を示します。

- ガベージファースト(G1)ガベージ・コレクタはサーバー形式のガベージ・コレクタで、大容量のメモリーを搭載するマルチプロセッサ・マシンを対象としています。ガベージ・コレクション一時停止時間目標を高い確率で満たしながら、高いスループットを実現します。詳細は、http://docs.oracle.com/javase/8/docs/technotes/guides/vm/G1.htmlを参照してください。

- 共在するアプリケーションのリソースの分離と管理を提供するその他のWebLogic Server機能は、次のとおりです。

- クラス・ローダー・ベースの分離: アプリケーションの共有ライブラリに属していないクラスは、相互に分離されます。詳細は、「共有アプリケーション・クラス・ローダーの構成」および『Oracle WebLogic Serverアプリケーションの開発』のWebLogic Serverアプリケーションのクラスローディングの理解に関する項を参照してください。

- WebLogic Serverワーク・マネージャ: 一連のスケジューリング・ガイドラインを構成して、処理の実行を優先度付けします。これにより、ワーク・マネージャは、アプリケーションに割り当てられているスレッドを管理し、それらのスレッドに対するワーク・マネージャ・インスタンスのスケジューリングを管理して、サービス・レベル合意に準拠できるようになります。詳細は、「パーティション・ワーク・マネージャの構成」および『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください

詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のマルチテナントのチューニングの推奨事項に関する項を参照してください。

11 アプリケーションのデプロイ

この章では、マルチテナント環境にアプリケーションとモジュールをデプロイする方法について説明します。また、この章では、アプリケーションのデプロイメント・パラメータのオーバーライド方法、パーティション固有のデプロイメント・プランの使用方法およびデプロイメントのパフォーマンスを向上させるための並行デプロイの有効化方法についても説明します。

注意:

リソース・グループ、リソース・グループ・テンプレート、アプリケーション・オーバーライドなどのOracle WebLogic Server Multitenant (MT)の多くの新機能は、WebLogic Serverの12.2.1バージョンでも使用できます。この章では、適宜これらの機能について、WebLogic Serverドキュメントを参照します。

この章には次の項が含まれます:

- デプロイメント・スコープについて

- アプリケーションのリソース・グループ・テンプレートへのデプロイ

- パーティション・リソース・グループへのアプリケーションのデプロイ

- パーティション管理者としてのアプリケーションのデプロイ

- アプリケーション構成のオーバーライド

- アプリケーション・オーバーライドの削除

- パーティション固有のデプロイメント・プランの使用方法

- マルチテナント環境での並行デプロイの有効化

デプロイメント・スコープについて

Oracle Enterprise Manager Fusion Middleware ControlやWebLogic Scripting Tool (WLST)などの一般的なデプロイメント・ツールを使用して、アプリケーションおよびライブラリを4つのデプロイメント・スコープ・オプションのいずれかにデプロイできます。

- グローバル。これは、非パーティション環境のドメイン・レベルと同等です。

- リソース・グループ・テンプレートこれは常にドメイン・レベルです。リソース・グループ・テンプレートにデプロイするアプリケーションまたはライブラリがドメイン・レベルまたはパーティションで使用できるかどうかは、リソース・グループ・テンプレートを参照するリソース・グループのスコープに応じて異なります。

- パーティション内のリソース・グループ。これは、パーティションに制限される唯一のスコープです。

- ドメイン・レベルでのリソース・グループ。

デプロイメント・スコープの詳細は、「スコープについて」を参照してください。

アプリケーションのリソース・グループ・テンプレートへのデプロイ

アプリケーションとライブラリの共通のセットをリソース・グループ・テンプレートにデプロイして、ドメインまたはドメイン・パーティション全体のアプリケーション構成を簡略化できます。リソース・グループは、リソース・グループ・テンプレートを参照したときに、テンプレートで定義されたリソースの独自のランタイム・コピーを取得します。その後、リソース・グループ・テンプレートにデプロイされたすべてのアプリケーションとライブラリがリソース・グループにデプロイされます。

リソース・グループ・テンプレートにより、アプリケーションの同じコレクションを複数のドメイン・パーティションにデプロイすることが簡単になります。アプリケーション構成をカスタマイズするために、リソース・グループの特定のアプリケーションに対して別のデプロイメント・プランを指定して、デフォルトのリソース・グループ・テンプレート構成をオーバーライドできます。

サポートされるデプロイメント操作と使用可能なデプロイメント・クライアントに関する情報を含む、アプリケーションのリソース・グループ・テンプレートへのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のリソース・グループ・テンプレートを使用したアプリケーションのデプロイメントに関する項を参照してください。

アプリケーションのリソース・グループ・テンプレートへのデプロイ: 主な手順

WebLogic Serverシステム管理者のみが、アプリケーションおよびライブラリをリソース・グループ・テンプレートにデプロイできます。主要な手順は次のとおりです。

1. アプリケーションまたはライブラリをデプロイするリソース・グループ・テンプレートを指定します。

2. アプリケーションまたはライブラリの名前とディレクトリ・パスを指定します。

3. デプロイメント・プランを使用している場合は、デプロイメント・プランのパスを指定します。

4. (オプション)追加のデプロイメント・オプションを指定します。アプリケーションでは参照元のリソース・グループに関連付けられたターゲットが使用されるため、targetsオプションを指定しないでください。

アプリケーションがリソース・グループ・テンプレートにデプロイされると、追加のデプロイメント操作を実行できます。

5. アプリケーションを再デプロイまたは更新します。

アプリケーションを更新すると、元のアーカイブ・ファイルまたは展開されたディレクトリの再デプロイや、元のアーカイブ・ファイルのかわりの新しいアーカイブ・ファイルのデプロイをWebLogic Serverで行うように指定できます。また、アプリケーションに関連付けられているデプロイメント・プランを変更することも可能です。

6. アプリケーションを配布します。

配布操作により、参照元のリソース・グループに関連付けられたターゲット(または、リソース・グループ・レベルにターゲットが存在しない場合はパーティション・レベルのデフォルト・ターゲット)にデプロイメント・ファイルがコピーされて、準備された状態のアプリケーションが配置されます。その後は、アプリケーションを管理モードで起動して、アプリケーションを外部クライアント接続に対して開いたり、接続されたクライアントを中断することなく、最終テストを実行できます。

7. アプリケーションをアンデプロイします。

アンデプロイ操作により、リソース・グループ・テンプレートおよび参照元のリソース・グループに関連付けられたターゲットからアプリケーションが削除されます。

これらの操作は、リソース・グループ・テンプレートを参照しているリソース・グループから実行する必要があるため、リソース・グループ・テンプレートにデプロイされたアプリケーションは起動または停止できません。

注意:

リソース・グループ・テンプレートに対してデプロイメント操作を実行すると、テンプレートを参照しているすべてのリソース・グループでただちに操作が実行されます。たとえば、リソース・グループ・テンプレートからアプリケーションをアンデプロイすると、そのリソース・グループ・テンプレートを参照しているすべてのリソース・グループからアプリケーションがアンデプロイされます。

Fusion Middleware Controlを使用してリソース・グループ・テンプレートにアプリケーションをデプロイするには、オンライン・ヘルプのリソース・グループ・テンプレートのデプロイメントの構成に関する項を参照してください。

アプリケーションのリソース・グループ・テンプレートへのデプロイ: 例

次の例では、WLSTを使用して、リソース・グループ・テンプレートを使用したデプロイメント操作を実行する方法を示します。

アプリケーションのリソース・グループ・テンプレートへのデプロイ: WLSTの例

次の例では、sampleappアプリケーションをリソース・グループ・テンプレートmyRGTにデプロイします。

edit()
startEdit()
deploy(appName='sampleapp', path='path_to_application', resourceGroupTemplate='myRGT')
activate()

アプリケーションのリソース・グループ・テンプレートへの再デプロイ: WLSTの例

次の例では、デプロイメント・プラン・ファイルplan.xmlを使用して、sampleappアプリケーションをリソース・グループ・テンプレートmyRGTに再デプロイします。

edit()
startEdit()
redeploy(appName='sampleapp', planPath='path_to_plan.xml', resourceGroupTemplate='myRGT')
activate()

アプリケーションのリソース・グループ・テンプレートからのアンデプロイ: WLSTの例

次の例では、sampleappアプリケーションをリソース・グループ・テンプレートmyRGTからアンデプロイします。

edit()
startEdit()
undeploy (appName='sampleapp', resourceGroupTemplate='myRGT')
activate()

リソース・グループ・テンプレートのアプリケーションの更新: WLSTの例

次の例では、デプロイメント・プラン・ファイルplan.xmlを使用して、リソース・グループ・テンプレートmyRGTのsampleappアプリケーションを更新します。

edit()
startEdit()
updateApplication(appName='sampleapp', planPath='path_to_plan.xml', resourceGroupTemplate='myRGT')
activate()

アプリケーションのリソース・グループ・テンプレートへの配布: WLSTの例

次の例では、sampleappアプリケーションをリソース・グループ・テンプレートmyRGTに配布します。

edit()
startEdit()
distributeApplication (appPath='path_to_sampleapp', resourceGroupTemplate='myRGT')
activate()

アプリケーションのリソース・グループ・テンプレートへのデプロイ: 関連タスクおよびリンク

次の追加情報を参照してください。

- リソース・グループ・テンプレートの詳細は、「リソース・グループ・テンプレートの構成」を参照してください

- リソース・グループ・テンプレートへのアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のリソース・グループ・テンプレートを使用したアプリケーションのデプロイメントに関する項を参照してください

- Fusion Middleware Controlを使用したアプリケーションのデプロイに関するオンライン・ヘルプは、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のアプリケーションのデプロイメントに関する項を参照してください

- Fusion Middleware Controlを使用したリソース・グループ・テンプレートの構成に関するオンライン・ヘルプは、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverのリソース・グループ・テンプレートに関する項を参照してください

- weblogic.Deployerを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.Deployerコマンド行リファレンスに関する項を参照してください

- WLSTを使用したアプリケーションのデプロイの詳細は、『WebLogic Server WLSTコマンド・リファレンス』のデプロイメント・コマンドに関する項を参照してください

- wldeploy Antタスクを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のwldeploy Antタスクの属性のリファレンスに関する項を参照してください

- Mavenを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のMavenプラグイン・ゴールに関する項を参照してください

- JSR-88デプロイメントAPIを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Server Java APIリファレンス』を参照してください

- JMXデプロイメントAPIを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Server MBeanリファレンス』のDeploymentManagerMBeanに関する項を参照してください

パーティション・リソース・グループへのアプリケーションのデプロイ

ドメインまたはパーティション・レベルでリソース・グループにアプリケーションとライブラリをデプロイして、それらのアプリケーションに対して、起動や停止などのデプロイメント操作を実行できます。リソース・グループは、Java EEアプリケーションとそれらのリソースを個別の管理単位にグループ化するため便利であり、さらにドメイン・レベルで定義することも、ドメイン・パーティションに固有のものとすることもできます。リソース・グループは、リソースを直接含むか、リソースを含むリソース・グループ・テンプレートを参照できます。

リソース・グループのリソースとアプリケーションは、それらのリソースを起動したりそれらに接続するために必要なすべての情報を管理者が指定するという点で、完全修飾されます。リソース・グループにデプロイされたすべてのアプリケーションによって、そのリソース・グループに関連付けられたターゲットが使用されます。

パーティション・リソース・グループにより、各パーティションにリソースとアプリケーションの異なるセットを含めることができます。パーティション・リソース・グループ内のアプリケーションとライブラリに対して、次のデプロイメント操作を実行できます。

- デプロイ

- アンデプロイ

- 再デプロイ

- 更新

- 配布

- 起動

- 停止

操作が成功すると、指定したパーティション・リソース・グループに関連付けられたターゲットに、アプリケーションまたはライブラリがデプロイされます(または再デプロイや起動などが行われます)。パーティション・リソース・グループに対するターゲットが存在しない場合は、パーティションのデフォルト・ターゲットにアプリケーションまたはライブラリがデプロイされます。

パーティション・リソース・グループを使用したアプリケーションのデプロイメントでは、次の考慮事項に注意してください。

- デプロイメント操作を実行するときに、partitionオプションを使用してパーティション名を指定します。指定したパーティションが存在する必要があり、そうでない場合は操作が失敗します。

- アプリケーション名は、各パーティション内で一意である必要があります。

- deployおよびdistributeの操作では、resourceGroupオプションを使用してパーティション・リソース・グループ名を指定する必要があります。ただし、パーティションにリソース・グループが1つのみ存在する場合は、resourceGroupはオプションです。
その他のデプロイメント操作では、resourceGroupオプションを指定しないでください。WebLogic Serverでは、パーティション名と一意のアプリケーション名からリソース・グループが導出されます。指定したパーティション・リソース・グループが存在しない場合、または必要なときにresourceGroupオプションを指定しない場合は、デプロイメント操作が失敗します。

- リソース・グループ・レベルのアプリケーションに対してデプロイメント操作を実行するときにtargetsオプションを指定すると、デプロイメント操作が失敗します。アプリケーションではリソース・グループに関連付けられたターゲットが使用されるため、リソース・グループの個々のアプリケーションはターゲット指定できません。

- リソースはパーティションのリソース・グループ全体で一意である必要があるため、パーティションには特定のライブラリを1回のみデプロイできます。同じパーティション・リソース・グループのアプリケーションまたはパーティションの他のリソース・グループは、ターゲットが一致する場合にライブラリを参照できます。パーティションにデプロイされたアプリケーションは、他のパーティション内のライブラリも、ドメイン内の他のライブラリも参照できません。

- リソース・グループは、リソース・グループ・テンプレートからアプリケーション構成を継承できます。リソース・グループがリソース・グループ・テンプレートを参照する場合、リソース・グループ・テンプレートにデプロイされたアプリケーションまたはライブラリは、ただちに参照元のリソース・グループにデプロイされます。必要に応じて、デフォルトのリソース・グループ・テンプレートのアプリケーション構成をオーバーライドして、リソース・グループの特定のアプリケーションをカスタマイズできます。詳細は、「アプリケーション構成のオーバーライド」を参照してください。

- パーティション管理者は、WLSTを使用して独自のパーティションのアプリケーションに対してのみデプロイメント操作を実行でき、グローバル・アプリケーションや他のパーティションのアプリケーションに対しては実行できません。partitionオプションは、パーティション管理者にはオプションです。パーティション管理者がpartitionオプションを使用してパーティションを指定する場合、そのパーティションが彼らの関連するパーティションに一致しないと、操作が失敗します。パーティション管理者としてのWLSTを使用したアプリケーションのデプロイの詳細は、「セキュリティの構成」を参照してください。

ドメイン・リソース・グループへのアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のドメイン・リソース・グループを使用したアプリケーションのデプロイメントに関する項を参照してください。

パーティション・リソース・グループへのアプリケーションのデプロイ: 主な手順

パーティションのリソース・グループにアプリケーションおよびライブラリをデプロイする主な手順は、次のとおりです。

1. アプリケーションまたはライブラリをデプロイするパーティション・リソース・グループを指定します。

2. アプリケーションまたはライブラリの名前とディレクトリ・パスを指定します。

3. デプロイメント・プランを使用している場合は、デプロイメント・プランのパスを指定します。

4. (オプション)追加のデプロイメント・オプションを指定します。アプリケーションではリソース・グループに関連付けられたターゲットが使用されるため、targetsオプションを指定しないでください。リソース・グループに対するターゲットが存在しない場合は、アプリケーションでパーティションのデフォルト・ターゲットが使用されます。

アプリケーションがリソース・グループにデプロイされると、追加のデプロイメント操作を実行できます。

5. アプリケーションを起動または停止します。

アプリケーションまたはモジュールを起動すると、WebLogic Serverクライアントでそれが使用できるようになります。アプリケーションまたはモジュールを停止すると、それを再起動するまではWebLogic Serverクライアントで使用できなくなります。

6. アプリケーションを再デプロイまたは更新します。

アプリケーションを更新すると、元のアーカイブ・ファイルまたは展開されたディレクトリの再デプロイや、元のアーカイブ・ファイルのかわりの新しいアーカイブ・ファイルのデプロイをWebLogic Serverで行うように指定できます。また、アプリケーションに関連付けられているデプロイメント・プランを変更することも可能です。

7. アプリケーションを配布します。

配布操作により、リソース・グループに関連付けられたターゲット(または、リソース・グループ・レベルにターゲットが存在しない場合はパーティション・レベルのデフォルト・ターゲット)にデプロイメント・ファイルがコピーされて、準備された状態のアプリケーションが配置されます。その後は、アプリケーションを管理モードで起動して、アプリケーションを外部クライアント接続に対して開いたり、接続されたクライアントを中断することなく、最終テストを実行できます。

8. アプリケーションをアンデプロイします。

アンデプロイ操作により、リソース・グループおよびリソース・グループに関連付けられたターゲットからアプリケーションが削除されます。

Fusion Middleware Controlを使用してパーティション・リソース・グループにアプリケーションをデプロイするには、オンライン・ヘルプのドメイン・パーティションのアプリケーション・デプロイメントの制御に関する項を参照してください。

パーティション・リソース・グループへのアプリケーションのデプロイ: 例

次の例では、WLSTを使用して、パーティション・リソース・グループに対するデプロイメント操作を実行する方法を示します。

パーティション・リソース・グループへのアプリケーションのデプロイ: WLSTの例

次の例では、sampleappアプリケーションをパーティションmyPartitionのリソース・グループmyRGにデプロイします。

edit()
startEdit()
deploy(appName='sampleapp', partition='myPartition', resourceGroup='myRG', path='path_to_application')
activate()

パーティション・リソース・グループへのアプリケーションの再デプロイ: WLSTの例

次の例では、デプロイメント・プラン・ファイルplan.xmlを使用して、sampleappアプリケーションをパーティションmyPartitionに再デプロイします。

WebLogic Serverで一意のアプリケーション名とパーティション名からリソース・グループが導出されるため、パーティション・リソース・グループを指定する必要はありません。

edit()
startEdit()
redeploy(appName='sampleapp', planPath='path_to_plan.xml', partition='myPartition')
activate()

パーティション・リソース・グループからのアプリケーションのアンデプロイ: WLSTの例

次の例では、パーティションmyPartitionからsampleappアプリケーションをアンデプロイします。

WebLogic Serverで一意のアプリケーション名とパーティション名からリソース・グループが導出されるため、パーティション・リソース・グループを指定する必要はありません。

edit()
startEdit()
undeploy (appName='sampleapp', partition='myPartition')
activate()

パーティション・リソース・グループのアプリケーションの更新: WLSTの例

次の例では、デプロイメント・プラン・ファイルplan.xmlを使用して、パーティションmyPartitionのsampleappアプリケーションを更新します。

WebLogic Serverで一意のアプリケーション名とパーティション名からリソース・グループが導出されるため、パーティション・リソース・グループを指定する必要はありません。

edit()
startEdit()
updateApplication(appName='sampleapp', planPath='path_to_plan.xml', partition='myPartition')
activate()

パーティション・リソース・グループへのアプリケーションの配布: WLSTの例

次の例では、sampleappアプリケーションをパーティションmyPartitionのリソース・グループmyRGに配布します。

edit()
startEdit()
distributeApplication (appPath='path_to_sampleapp', resourceGroup='myRG', partition='myPartition')
activate()

パーティション・リソース・グループのアプリケーションの起動: WLSTの例

次の例では、パーティションmyPartitionのsampleappアプリケーションを起動します。

WebLogic Serverで一意のアプリケーション名とパーティション名からリソース・グループが導出されるため、パーティション・リソース・グループを指定する必要はありません。

edit()
startEdit()
startApplication (appName='sampleapp', partition='myPartition')
activate()

パーティション・リソース・グループのアプリケーションの停止: WLSTの例

次の例では、パーティションmyPartitionのsampleappアプリケーションを停止します。

WebLogic Serverで一意のアプリケーション名とパーティション名からリソース・グループが導出されるため、パーティション・リソース・グループを指定する必要はありません。

edit()
startEdit()
stopApplication (appName='sampleapp', partition='myPartition')
activate()

パーティション・リソース・グループへのアプリケーションのデプロイ: RESTの例

Representational State Transfer (REST) APIを使用してアプリケーションをデプロイするデプロイヤ・ロールのパーティション・ユーザーの例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティション・スコープのアプリケーションのデプロイに関する項を参照してください。

パーティション・リソース・グループへのアプリケーションのデプロイ: 関連タスクおよびリンク

次の追加情報を参照してください。

- パーティションの詳細は、「ドメイン・パーティションの構成」を参照してください

- リソース・グループの詳細は、「リソース・グループの構成」を参照してください

- ドメイン・レベルでのリソース・グループへのアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のドメイン・リソース・グループを使用したアプリケーションのデプロイメントに関する項を参照してください

- Fusion Middleware Controlを使用したアプリケーションのデプロイに関するオンライン・ヘルプは、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のアプリケーションのデプロイメントに関する項を参照してください

- Fusion Middleware Controlを使用したパーティションの構成に関するオンライン・ヘルプは、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverのドメイン・パーティションに関する項を参照してください

- Fusion Middleware Controlを使用したリソース・グループの構成に関するオンライン・ヘルプは、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverのリソース・グループに関する項を参照してください

- weblogic.Deployerを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.Deployerコマンド行リファレンスに関する項を参照してください

- WLSTを使用したアプリケーションのデプロイの詳細は、『WebLogic Server WLSTコマンド・リファレンス』のデプロイメント・コマンドに関する項を参照してください

- wldeploy Antタスクを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のwldeploy Antタスクの属性のリファレンスに関する項を参照してください

- Mavenを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のMavenプラグイン・ゴールに関する項を参照してください

- JSR-88デプロイメントAPIを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Server Java APIリファレンス』を参照してください

- JMXデプロイメントAPIを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Server MBeanリファレンス』のDeploymentManagerMBeanに関する項を参照してください

パーティション管理者としてのアプリケーションのデプロイ

パーティション管理者は、独自のパーティションのアプリケーションに対してのみデプロイメント操作を実行でき、グローバル・アプリケーションや他のパーティションのアプリケーションに対しては実行できません。同様に、自分自身のパーティション内のアプリケーションでのみデプロイメントAPIを呼び出すことができます。アプリケーションまたはターゲットのリストを返すデプロイメントAPIを呼び出すと、自分自身のパーティション内のアプリケーションおよびターゲットのみが返されます。

WebLogic Serverシステム管理者は、パーティション管理者のかわりにアプリケーションをパーティションにデプロイできます。JMX APIを使用してアプリケーションをパーティションにデプロイする場合、(ドメイン・レベルのDeploymentManagerMBeanインスタンスを使用するかわりに)、関連するパーティションの下のDeploymentManagerMBeanインスタンスを取得する必要があります。次の例は、システム管理者およびパーティション管理者がJMXデプロイメントAPIを使用してパーティションでデプロイメント操作を実行する方法を示しています。

- システム管理者がグローバル・ドメイン(たとえばt3://localhost:7001)に接続する場合:

- JMXルックアップは、DomainPartitionRuntime=partition_nameを含めて、パーティションのDeploymentManagerMBeanを取得する必要があります。

- WLSTを使用して、パーティションのDomainPartitionRuntimeMBeanに移動して、partition_nameのDeploymentManagerMBeanを取得する必要があります。次に例を示します。

connect('system_admin', 'gumby1234', 't3://localhost:7001')
domainRuntime()
cd('DomainPartitionRuntimes/partitionA')
cd('DeploymentManager/partitionA')
props=java.util.Properties()
props.setProperty("resourceGroup", "partitionAResourceGroup")
path="/scratch/user/foo.war"
cmo.deploy("foo", path, None, None, props)

- パーティション管理者がドメイン・パーティション(たとえばt3://localhost:7001/partitionA)に接続する場合:

- JMXルックアップは、PartitionDomainRuntime=partitionAを含めて、partitionAのDeploymentManagerMBeanを取得する必要はありません。JMXコンテナによって追加されます。

- WLSTを使用して、domainRuntime()コマンドを実行すると、cmoがパーティションのDomainPartitionRuntimeMBeanに設定されます。

connect('partitionA_admin', 'welcome1', 't3://localhost:7001/partitionA')
domainRuntime()
cd('DeploymentManager/partitionA')
props=java.util.Properties()
props.setProperty("resourceGroup", "partitionAResourceGroup")
path="/scratch/user/foo.war"
cmo.deploy("foo", path, None, None, props)

他のデプロイメント・クライアントを使用する場合、partitionオプションは、パーティション管理者にはオプションです。weblogic.Deployerの使用方法:

java weblogic.Deployer -deploy -adminurl <partition_url> -username <partition_admin_user> -password <partition_admin_password> -name <application_name> path_to_application

次に例を示します。

java weblogic.Deployer -deploy -username partition1_admin -password welcome1 -adminurl t3://localhost:7001/partition1 -name foo /scratch/user/foo.war

アプリケーション構成のオーバーライド

リソース・グループは、リソース・グループ・テンプレートを参照したときに、リソース・グループ・テンプレートで定義されたリソースまたはアプリケーションの独自のランタイム・コピーを取得します。リソース・グループはリソース・グループ・テンプレートで定義されたアプリケーション構成を継承するため、各アプリケーションを手動でデプロイおよび構成する必要はありません。リソース・グループ・テンプレートにデプロイされたアプリケーションとライブラリは、ただちに参照元のリソース・グループにデプロイされます(または実行したデプロイメント操作に応じて、アンデプロイや再デプロイなどが行われます)。

リソース・グループの特定のアプリケーションをカスタマイズする必要がある場合は、別のデプロイメント・プランを指定して、デフォルトのアプリケーション構成をオーバーライドできます。そのデプロイメント・プランで、リソース・グループ・テンプレートのデプロイメント・パラメータを、特定のアプリケーションに使用する値でオーバーライドします。元のデプロイメント・プラン・ファイル内の個々のエントリのみではなく、デプロイメント・プラン・ファイル全体がオーバーライドされます。その後、アプリケーションまたはモジュールが、リソース・グループ・テンプレートで設定された値ではなく、そのアプリケーション構成用の新しいデプロイメント・プランを使用して更新または再デプロイされます。

注意:

リソース・グループ・テンプレートからアプリケーションをアンデプロイすると、参照元のリソース・グループで定義されたアプリケーション構成のオーバーライドが削除されます。

リソース・グループ・テンプレートにアプリケーションを再デプロイすると、参照元のリソース・グループで定義されたアプリケーション構成のオーバーライドがそのアプリケーションの以前のデプロイメントから削除されます。このシナリオでは、リソース・グループのアプリケーション構成を再びオーバーライドして、オーバーライド値を維持する必要があります。

オーバーライド・デプロイメント・プランを使用するためにアプリケーションを更新するか、再デプロイするかは、オーバーライドするプロパティのタイプに応じて異なります。動的プロパティのオーバーライド時のみにupdateコマンドを使用します。updateコマンドでアプリケーションが中断されることはありません。動的プロパティと非動的プロパティのオーバーライド時にredeployコマンドを使用します。redeployコマンドではアプリケーションが中断されます。

ドメインまたはパーティション・レベルのリソース・グループのアプリケーション構成をオーバーライドできます。ドメイン・リソース・グループのアプリケーション構成のオーバーライドの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のアプリケーション構成のオーバーライドに関する項を参照してください。

アプリケーション構成のオーバーライド: 主な手順

継承されたリソース・グループ・テンプレートで定義されたデフォルトのアプリケーション構成をオーバーライドして、リソース・グループの特定のアプリケーションをカスタマイズする主な手順は、次のとおりです。

1. カスタマイズするアプリケーションに使用する別のデプロイメント・プランを作成します。

2. 新しいデプロイメント・プランで、そのアプリケーションのオーバーライドする属性の値を定義します。

3. アプリケーションを再デプロイまたは更新するときに、新しいオーバーライド・デプロイメント・プランを指定します。

これにより、アプリケーションで、その構成に対してデフォルトのテンプレート構成ではなく、オーバーライド・デプロイメント・プランが使用されるようになります。

複数のリソース・グループが同じリソース・グループ・テンプレートを参照している場合は、すべての必要なリソース・グループのアプリケーション構成を確実にオーバーライドします。

アプリケーション構成のオーバーライド: WLSTの例

次に、例を示します。

1. デプロイメント・プラン・ファイルplan.xmlを使用して、アプリケーションsampleappをリソース・グループ・テンプレートmyRGTにデプロイします。

edit()
startEdit()
deploy(appName='sampleapp', resourceGroupTemplate='myRGT', path='path_to_application', planPath='path_to_plan.xml')
activate()

2. パーティションmyPartition内の参照元のパーティション・リソース・グループに対して、オーバーライド・デプロイメント・プランoverride_plan.xmlを使用するようにアプリケーションsampleappを更新または再デプロイします。
WebLogic Serverで一意のアプリケーション名とパーティション名からリソース・グループが導出されるため、パーティション・リソース・グループを指定する必要はありません。

アプリケーションの動的属性のオーバーライド時にupdateコマンドを使用します。アプリケーションの動的属性または非動的属性のオーバーライド時にredeployコマンドを使用します。

edit()
startEdit()
updateApplication(appName='sampleapp', planPath='path_to_override_plan.xml', partition='myPartition')
activate()

edit()
startEdit()
redeploy(appName='sampleapp', planPath='path_to_override_plan.xml', partition='myPartition')
activate()

アプリケーション構成のオーバーライド: 関連タスクおよびリンク

次の追加情報を参照してください。

- ドメイン・レベルでのアプリケーション構成のオーバーライドの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のアプリケーション構成のオーバーライドに関する項を参照してください

- JMSやJDBCなどのリソース構成のオーバーライドの詳細は、「リソース・オーバーライドの構成」を参照してください

- Fusion Middleware Controlを使用したアプリケーション構成のオーバーライドに関するオンライン・ヘルプは、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のアプリケーション構成のオーバーライドに関する項を参照してください

- weblogic.Deployerを使用したアプリケーション構成のオーバーライドの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.Deployerコマンド行リファレンスに関する項を参照してください

- WLSTを使用したアプリケーション構成のオーバーライドの詳細は、『WebLogic Server WLSTコマンド・リファレンス』のデプロイメント・コマンドに関する項を参照してください

- wldeploy Antタスクを使用したアプリケーション構成のオーバーライドの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のwldeploy Antタスクの属性のリファレンスに関する項を参照してください

- Mavenを使用したアプリケーション構成のオーバーライドの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のMavenプラグイン・ゴールに関する項を参照してください

- JSR-88デプロイメントAPIを使用したアプリケーション構成のオーバーライドの詳細は、『Oracle WebLogic Server Java APIリファレンス』を参照してください

- JMXデプロイメントAPIを使用したアプリケーション構成のオーバーライドの詳細は、『Oracle WebLogic Server MBeanリファレンス』のDeploymentManagerMBeanに関する項を参照してください

アプリケーション・オーバーライドの削除

リソース・グループの特定のアプリケーションをカスタマイズする必要がなくなった場合、オーバーライド属性を含むデプロイメント・プランを削除して、アプリケーション・オーバーライドを削除できます。アプリケーション構成がそのデフォルトの構成に戻ります。

アプリケーション・オーバーライドの削除: 主な手順

リソース・グループからアプリケーション・オーバーライドを削除する主な手順は、次のとおりです。

1. オーバーライドを含むアプリケーションを選択します。

2. 動的属性に対する既存のオーバーライドを削除するには、アプリケーションを更新してremovePlanOverrideオプションを指定します。

3. 動的属性および非動的属性に対する既存のオーバーライドを削除するには、アプリケーションを再デプロイしてremovePlanOverrideオプションを指定します。

Fusion Middleware Controlを使用してアプリケーション・オーバーライドを削除するには、オンライン・ヘルプのアプリケーション構成のオーバーライドの削除に関する項を参照してください。

アプリケーション・オーバーライドの削除: WLSTの例

次の例では、removePlanOverrideオプションを使用して、アプリケーションsampleappを再デプロイして既存のオーバーライド・デプロイメント・プランを削除します。

edit()
startEdit()
redeploy(appName='sampleapp', removePlanOverride, partition='myPartition')
activate()

アプリケーション・オーバーライドの削除: 関連タスクおよびリンク

次の追加情報を参照してください。

- ドメイン・レベルでのアプリケーション・オーバーライドの削除の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のアプリケーション・オーバーライドの削除に関する項を参照してください

- JMSやJDBCなどのリソース構成のオーバーライドの詳細は、「リソース・オーバーライドの構成」を参照してください

- Fusion Middleware Controlを使用したアプリケーション・オーバーライドの削除に関するオンライン・ヘルプは、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のアプリケーション構成のオーバーライドの削除に関する項を参照してください

- weblogic.Deployerを使用したアプリケーション・オーバーライドの削除の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.Deployerコマンド行リファレンスに関する項を参照してください

- WLSTを使用したアプリケーション・オーバーライドの削除の詳細は、『WebLogic Server WLSTコマンド・リファレンス』のデプロイメント・コマンドに関する項を参照してください

- wldeploy Antタスクを使用したアプリケーション・オーバーライドの削除の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のwldeploy Antタスクの属性のリファレンスに関する項を参照してください

- Mavenを使用したアプリケーション・オーバーライドの削除の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のMavenプラグイン・ゴールに関する項を参照してください

- JSR-88デプロイメントAPIを使用したアプリケーション・オーバーライドの削除の詳細は、『Oracle WebLogic Server Java APIリファレンス』を参照してください

- JMXデプロイメントAPIを使用したアプリケーション・オーバーライドの削除の詳細は、『Oracle WebLogic Server MBeanリファレンス』のDeploymentManagerMBeanに関する項を参照してください

パーティション固有のデプロイメント・プランの使用方法

パーティション固有のデプロイメント・プランを使用して、リソース・グループ・テンプレートまたはパーティション内のリソース・グループにデプロイされたアプリケーションをカスタマイズできます。パーティション固有のデプロイメント・プランは、同じアプリケーションのセットを共有し、パーティションごとにいくつかのカスタマイズを必要とする、異なるパーティションを含む環境で特に役立ちます。

パーティション固有のデプロイメント・プランは、パーティション・レベルではなく、パーティション内のリソース・グループ・レベルで指定します。WebLogic Serverによってパーティション固有のデプロイメント・プランが指定されたアプリケーションに適用される場合、プランで指定された変更は、そのパーティション内のアプリケーションのデプロイメントのみに影響します。

注意:

リソース・グループ・テンプレートでアプリケーション・デプロイメント・プランを指定し、同じアプリケーションに対してパーティション固有のデプロイメント・プランを指定した場合、パーティション固有のデプロイメント・プランによってリソース・グループ・テンプレートのプランがオーバーライドされて、パーティション固有のデプロイメント・プランが使用されます。

パーティション固有のアプリケーション・デプロイメント・プランを使用するには、redeployまたはupdateApplicationのWLSTコマンドを使用します。

パーティション固有のデプロイメント・プランの使用方法: 主な手順

パーティション固有のデプロイメント・プランを使用する主な手順は、次のとおりです。

1. 使用するパーティション固有のアプリケーション・デプロイメント・プランを作成します。

2. redeployまたはupdateApplicationのWLSTコマンドを使用し、パーティション固有のデプロイメント・プランを使用してアプリケーションを再デプロイまたは更新します。

パーティション固有のデプロイメント・プランからアプリケーションまたはモジュールに対して行われる変更が非動的または動的である場合は、redeployコマンドを使用します。パーティション固有のデプロイメント・プランからアプリケーションまたはモジュールに対して行われる変更が動的である場合にのみ、updateApplicationコマンドを使用します。

3. 対応するWLSTオプションを指定して、パーティション固有のデプロイメント・プランを使用するアプリケーションのデプロイメントを含むスコープを指定します。

スコープ

WLSTオプション

リソース・グループ・テンプレート

resourceGroupTemplate

ドメイン・リソース・グループ

なし

ドメイン・リソース・グループの場合はリソース・グループ名を指定する必要はありません。アプリケーション名はドメイン内で一意であるため、WebLogic Serverによってアプリケーション名からリソース・グループが導出されます。

パーティション・リソース・グループ

partition

パーティション・リソース・グループの場合はリソース・グループ名を指定する必要はありません。アプリケーション名はパーティション内で一意であるため、WebLogic Serverによってアプリケーション名およびパーティション名からリソース・グループが導出されます。

4. WLSTオプションplanPathおよびappNameを使用して、パーティション固有のデプロイメント・プランの場所と、変更するアプリケーションのデプロイメントの名前を指定します。

5. 変更をアクティブ化します。

これで、指定したアプリケーションでその構成にパーティション固有のデプロイメント・プランが使用されるようになりました。

パーティション固有のデプロイメント・プランの使用方法: WLSTの例

次に、例を示します。

1. アプリケーションsampleappをリソース・グループ・テンプレートmyRGTにデプロイします。パーティションmyPartitionはリソース・グループ・テンプレートmyRGTを参照します。

edit()
startEdit()
deploy(appName='sampleapp', resourceGroupTemplate='myRGT', path='path_to_application')
activate()

2. パーティションmyPartitionでパーティション固有のデプロイメント・プランpartition_plan.xmlを使用するようにアプリケーションsampleappを更新または再デプロイします。
アプリケーションの動的属性を変更する場合にのみ、updateコマンドを使用します。アプリケーションの動的属性または非動的属性を変更する場合、redeployコマンドを使用します。

edit()
startEdit()
updateApplication(appName='sampleapp', planPath='path_to_partition_plan.xml', partition='myPartition')
activate()

edit()
startEdit()
redeploy(appName='sampleapp', planPath='path_to_partition_plan.xml', partition='myPartition')
activate()

パーティション固有のデプロイメント・プランの使用方法: 関連リンクおよびタスク

次の追加情報を参照してください。

- JMSやJDBCなどのリソース構成のオーバーライドの詳細は、「リソース・オーバーライドの構成」を参照してください

- WLSTを使用したアプリケーション・オーバーライドの削除の詳細は、『WebLogic Server WLSTコマンド・リファレンス』のデプロイメント・コマンドに関する項を参照してください

マルチテナント環境での並行デプロイの有効化

並行デプロイにより、複数のアプリケーションのデプロイメント、複数のモジュールを含む単一のアプリケーションのデプロイメントまたは複数のパーティションにまたがる1つ以上のアプリケーションのデプロイメントを含むユースケースで、パフォーマンスが向上します。

複数のパーティションにアプリケーションがデプロイされると、WebLogic Serverではアプリケーションの各インスタンスが独立したアプリケーションとして表示されます。並行デプロイが有効化されていない場合、アプリケーションの各インスタンスは各パーティションに順にデプロイされます。

パフォーマンスを向上させるために、並行デプロイを有効化して、アプリケーションのインスタンスを相互に並行してデプロイできます。

- パーティション間のアプリケーションの並行デプロイを有効化するには、PartitionMBeanのParallelDeployApplications属性を構成します。
この属性が有効化されると、デプロイ順序が同じアプリケーションが相互に並行してデプロイされます。パーティション・レベルの設定により、パーティションのアプリケーションのドメイン・レベルの設定がオーバーライドされます。

リソースとアプリケーションの全体のデプロイ順序は変更されないため、標準のデプロイ順序でアプリケーションよりも優先されるデプロイメント・タイプ(JDBCシステム・リソースやJava EEライブラリなど)が、アプリケーションがデプロイされる前に完全にデプロイされることが保証されます。

- パーティションにデプロイされたアプリケーション内のモジュールの並行デプロイを有効化するには、PartitionMBeanのParallelDeployApplicationModules属性を構成します。

- アプリケーションごとにモジュールの並行デプロイを有効化するには、AppDeploymentMBeanのParallelDeployModules属性を構成します。この属性を設定すると、個々のアプリケーションのドメインとパーティションの値がオーバーライドされます。

WebLogic Server 12.2.1以上で作成されたドメインでは、ParallelDeployApplications属性とParallelDeployApplicationModules属性がデフォルトで有効になっています。12.2.1より前のWebLogic Serverで作成されたドメインでは、これらの属性はデフォルトで無効になっています。

注意:

相互依存のないアプリケーションのみを並行してデプロイする必要があります。アプリケーションが他のアプリケーションに依存する場合、このアプリケーションには、依存する対象のアプリケーションの依存関係の順序よりも高い依存関係の順序が必要です。そうでない場合、並行デプロイで、その依存する対象のアプリケーションがアクティブ化される前に依存アプリケーションでデプロイが試行されると、依存のエラーが発生する可能性があります。同様に、相互依存のないモジュールを含むアプリケーションに対してのみ、モジュールの並行デプロイを有効化します。

並行デプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のアプリケーションおよびモジュールの並行デプロイの有効化に関する項を参照してください。

12 共有アプリケーション・クラス・ローダーの構成

この章では、Oracle WebLogic Server Multitenant (MT)で共有アプリケーション・クラス・ローダーを使用する方法について説明します。この章では、適宜追加情報について、WebLogic Serverのドキュメント・セットおよびオンライン・ヘルプを参照します。

クラス・ローダー機能は、アプリケーション開発者による使用のみを対象としています。この章では、『Oracle WebLogic Serverアプリケーションの開発』のWebLogic Serverアプリケーションのクラス・ローディングの理解に関する項で説明しているように、WebLogic Serverアプリケーションのクラス・ローディングを理解していることを前提としています。WebLogic Serverアプリケーションのクラス・ローディングについて理解していない場合は、その章を最初にお読みください。

この章の内容は次のとおりです。

- 共有アプリケーション・クラス・ローダーの構成: 概要

- 共有アプリケーション・クラス・ローダーの構成: 主な手順

- 共有アプリケーション・クラス・ローダーの構成: 関連タスクおよびリンク

共有アプリケーション・クラス・ローダーの構成: 概要

同じアプリケーションの複数のインスタンスを異なるパーティションで実行する場合、これらのインスタンス間でクラス・ローディング・メモリーを最適化する必要がある場合があります。WebLogic Server MTには、この目的のためにデプロイメント・ディスクリプタ・ベースのクラス・ローディング機能が含まれています。

WebLogic Server MTには、次の2つのタイプのクラス・ローダーが用意されています。

- パーティション・クラス・ローダー: パーティション・クラス・ローダーは、各パーティションに自動的に作成されます。このクラス・ローダーは、パーティション全体かつそのパーティションでのみ表示可能である必要があり、ドメインの残りの部分では表示できないクラスをロードします。(これには、グローバル・コネクタが含まれます。)

注意:

グローバル・コネクタは、サーバー内のすべてのアプリケーションで表示可能および使用可能になるように構成された、特定のタイプのコネクタ・モジュールです。これらのモジュールは、スタンドアロンとして、またはエンタープライズ・アーカイブ(EAR)ファイルのモジュールとしてデプロイされます。

- 共有アプリケーション・クラス・ローダー: 共有アプリケーション・クラス・ローダーは、アプリケーションがリソース・グループ・テンプレートにデプロイされている場合、Software-as-a-Service (SaaS)ユースケースでのみ関係します。クラス・ローダーは、あるアプリケーションのすべてのインスタンスでパーティションを越えて表示可能である必要があるが、他のアプリケーションでは表示できないクラスをロードします。(パーティションではなく)ドメインに直接デプロイされているアプリケーションは、パーティションが構成されている場合でも影響を受けません。
WebLogic Serverデプロイメント・ディスクリプタでは、アプリケーション・パッケージング内のAPP-INF/classesディレクトリのJARファイルおよびクラスを識別するために新しいshareable構成をサポートしています。これらのクラスは、共有アプリケーション・クラス・ローダーからロードされる必要があります。

shareable構成は、エンタープライズ・アプリケーションのweblogic-application.xmlファイルで、および本番モードでのみサポートされます。

パーティションを作成するときに、新しいパーティション・クラス・ローダーが作成され、パーティションの最初のアプリケーションがリソース・グループにデプロイされます。既存のパーティション・クラス・ローダーは、パーティションが削除されると削除され、パーティションの最後のアプリケーションがリソース・グループからアンデプロイされます。

新しい共有アプリケーション・クラス・ローダーは、(共有可能JARが構成された)アプリケーションがリソース・グループ・テンプレートにデプロイされたときに作成される可能性があり、そのリソース・グループ・テンプレートはパーティションのリソース・グループによって参照されます。

既存の共有アプリケーション・クラス・ローダーは、関連するアプリケーションがリソース・グループ・テンプレートからアンデプロイされると削除されます。アプリケーションをリソース・グループ・テンプレートからアンデプロイすると、そのテンプレートを参照するすべてのリソース・グループからアプリケーションはただちにアンデプロイされます。

注意:

クラス・ローディングが共有されると仮定できません。共有は可能な場合と可能でない場合があります。たとえば、パーティションごとに異なる構成を取得するようにフィルタリングが設定されている場合、共有はできません。フィルタ・クラス・ローダーの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のフィルタ・クラス・ローダーの使用方法に関する項を参照してください。

このため、共有可能なJARファイルを指定することはできますが、これらのJARファイルからのクラスが1回のみロードされ共有されると想定することはできません。

共有アプリケーション・クラス・ローダーの構成: 主な手順

XMLエディタを使用すると、アプリケーション開発者は、アプリケーションの作成時にweblogic-application.xmlファイルを編集し、<class-loading>要素内に1つ以上のshareable要素を追加できます。

次に例を示します。

<class-loading>
<shareable dir="APP-INF-LIB">
<include>coupon-generator.jar</include>
<include>group-discounts.jar</include>
</shareable>
<shareable dir="LIB-DIR">
<exclude>program-guide.jar</exclude>
</shareable>
</class-loading>

dir属性は、以降のパターンが適用されるディレクトリを識別します。dirでサポートされる値は、次の値のみです。

- APP-INF-LIBは、WebLogic ServerスタイルのAPP-INF/libディレクトリを識別します。

- LIB-DIRは、Java EEスタイルのライブラリ・ディレクトリを識別します。

- APP-INF-CLASSESは、WebLogic ServerスタイルのAPP-INF/classesディレクトリを識別します。

APP-INF-LIBおよびLIB-DIRディレクトリの場合、<include></include>要素で設定した値は、問題なく共有できると考えられるJARファイルを識別します。これらのJARファイルのクラスは、次のものに依存できません。

- 共有可能とみなされていないJARファイルのクラス。

- グローバル・コネクタなど、パーティション・スコープのクラス。

同様に、APP-INF-LIBおよびLIB-DIRディレクトリの場合、<exclude></exclude>要素は、共有できないJARファイルの識別に役立ちます。

次の構成ルールが適用されます。

- APP-INF-LIBおよびLIB-DIRが、includeまたはexclude構成なしで識別される場合、そのディレクトリのすべてのJARファイルは共有可能とみなされます。

- APP-INF-LIBおよびLIB-DIRが、include構成を使用して識別される場合、includeパターンを使用して識別されたJARファイルのみが共有可能とみなされます。

- APP-INF-LIBおよびLIB-DIRがexclude構成で識別される場合、excludeパターンによって識別されるJARファイルを除くディレクトリのすべてのJARファイルが共有可能とみなされます。

APP-INF-CLASSES

APP-INF-CLASSESディレクトリの場合、includeおよびexclude構成は、存在しても無視されます。APP-INF-CLASSESが共有可能と識別された場合、すべてのクラスが共有可能と宣言されます。

APP-INF-CLASSESディレクトリは、コード・ソースの場所であり、includeおよびexclude要素は必要ありません。共有アプリケーション・クラス・ローダー実装では、コード・ソースの場所内に要素を含めたり除外することはできません。

APP-INF-CLASSESディレクトリは、アプリケーションまたはライブラリのいずれであるかに関係なく、ディスクリプタのパッケージング単位でのみ有効です。アプリケーションおよびライブラリの場合は、個別に宣言する必要があります。

共有アプリケーション・クラス・ローダーの構成: 関連タスクおよびリンク

フィルタ・クラス・ローダーの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のフィルタ・クラス・ローダーの使用方法に関する項を参照してください。

13 Oracle Coherenceの構成

この章では、WebLogic Server Multitenant (MT)でOracle Coherenceを構成する方法について説明します。この章の説明に従い、Oracle Enterprise Manager Fusion Middleware Control (FMWC)またはWebLogic Scripting Tool (WLST)を使用して、Oracle Coherenceを構成できます。この章では、適宜追加情報について、Oracle Coherenceのドキュメントおよびオンライン・ヘルプを参照します。

この章の内容は次のとおりです。

- Oracle Coherenceの構成: 概要

- マルチテナント・ドメインでのOracle Coherenceアプリケーションのデプロイ

- キャッシュ構成プロパティのオーバーライド

- パーティション間でのキャッシュ共有の有効化

- マルチテナント・ドメインでのOracle Coherenceアプリケーションの保護

- Oracle Coherenceの構成: 関連タスクおよびリンク

Oracle Coherenceの構成: 概要

Oracle Coherenceアプリケーションは、Weblogic Server MTで提供される密度および操作効率を最大限に活用できます。すべてのテナントのインストゥルメンテーションは自動的に提供され、アプリケーションに変更を加える必要はありません。

マルチテナント・ドメインでは、すべてのドメイン・パーティションで使用可能な単一の共有Oracle Coherenceクラスタを使用します。アプリケーション・キャッシュは独立しており、ドメイン・パーティション・レベルで共有することもできます。一般的なデプロイメント・ツールはOracle Coherenceグリッド・アーカイブ(GAR)モジュールのデプロイおよび管理に使用され、一般的なパーティション・ライフサイクル操作はOracle Coherenceサービスのライフサイクルの管理に使用されます。

マルチテナント・ドメインでのOracle Coherence設定の理解

マルチテナント・ドメインでのOracle Coherenceの設定では、管理対象Oracle Coherenceサーバーを使用する必要があります。ドメインのOracle Coherenceクラスタを最初に作成し、すべての管理対象Oracle Coherenceサーバーがそのクラスタの一部になるように構成する必要があります。管理対象Oracle Coherenceサーバーは、通常、WebLogic Serverクラスタを使用して層内に設定され、これにより、Oracle Coherenceは必要に応じて簡単にスケール・アップまたはスケール・ダウンできます。詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。さらに、マルチテナント・ドメインにデプロイするために、Oracle CoherenceアプリケーションをGARモジュールとしてパッケージ化する必要があります。Oracle CoherenceアプリケーションのGARモジュールとしてのパッケージ化の詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。

マルチテナント・ドメインでのキャッシュ分離の理解

マルチテナント・ドメインでのキャッシュ分離では、複数のドメイン・パーティションに単一のGARモジュールをデプロイし、すべてのテナントで使用されるようにすることができます。分離はドメイン・パーティション・レベルで提供され、アプリケーションに対して透過的です。GARモジュールがドメイン・パーティションにデプロイされると、新しいキャッシュ・サービス・インスタンスが作成され、そのドメイン・パーティションに分離されます。GARモジュールは、Oracle Coherenceサービスの起動時に適切なtenant-idおよびmeta-dataを生成します。一部のキャッシュ構成プロパティは、各ドメイン・パーティション用の異なる値でオーバーライドされる場合があります

キャッシュ共有の理解

キャッシュの共有により、複数のドメイン・パーティションで単一のキャッシュ・インスタンスを使用できます。各テナントは同じキャッシュにアクセスできます。キャッシュの共有は、パーティション・レベルで有効化され、キャッシュにアクセスする各ドメイン・パーティションで設定する必要があります。キャッシュの共有は、アプリケーションに対して透過的です。

キャッシュ共有では、最大限のキャッシュ再利用を行い、最も効率的にリソースを使用します。ただし、キャッシュ共有は、キャッシュ・データがいずれのテナントにも固有でない場合にのみ使用する必要があります。

マルチテナント・ドメインでのOracle Coherenceアプリケーションのデプロイ

Oracle Coherenceアプリケーションは、Fusion Middleware ControlやWLSTなどの一般的なデプロイ・ツールを使用してデプロイされます。マルチテナント環境でのアプリケーションのデプロイの詳細は、「アプリケーションのデプロイ」を参照してください。

Oracle Coherenceアプリケーションをデプロイする場合は、「スコープ」フィールドを使用して、アプリケーションがデプロイされるドメイン・パーティションを指定します。Oracle Coherenceアプリケーションは、次のものにデプロイできます。

- グローバル・スコープ: グローバル・スコープは、非マルチテナント・デプロイメントと同等で、キャッシュ分離は設定されません。

- リソース・グループ・テンプレート: アプリケーションは指定されたリソース・グループ・テンプレートを使用するように構成されたドメイン・パーティションにデプロイされます。キャッシュ・インスタンスは各ドメイン・パーティションに分離されます。

- パーティションのリソース・グループ: アプリケーションは指定されたリソース・グループを使用するように構成されたパーティションにデプロイされます。キャッシュ・インスタンスは各ドメイン・パーティションに分離されます。

キャッシュ構成プロパティのオーバーライド

キャッシュ構成プロパティは、各ドメイン・パーティションで指定できます。GARモジュールの初期化時に、パーティション固有の値がキャッシュ構成に挿入されます。たとえば、1つのパーティションのキャッシュが5分後にエントリを失効するように構成され、別のドメイン・パーティションのキャッシュが10分後にエントリを失効するように構成される場合があります。どちらの場合も、同じキャッシュ構成ファイルがGARモジュールにデプロイされます。

キャッシュ構成プロパティをオーバーライドする主な手順は次のとおりです。

1. パーティション設定を編集するパーティションを選択します。

2. オーバーライドされるプロパティの名前および値を追加して、Oracle Coherence構成設定を更新します。

Fusion Middleware Controlを使用して、キャッシュ構成プロパティをオーバーライドするには、オンライン・ヘルプのドメイン・パーティションOracle Coherenceキャッシュの構成に関する項を参照してください。

WLSTの使用

キャッシュ構成プロパティをオーバーライドし、Weblogic ServerドメインMBeanサーバーに接続して、プロパティを指定する場合はcreateCoherencePartitionCacheProperty操作を実行し、プロパティ値を入力する場合はsetValue操作を実行します。次に例を示します。

cd('/')
cd('/Partitions/MyPartition-1')
cmo.createCoherencePartitionCacheConfig('MyConfig')
cd('CoherencePartitionCacheConfigs/MyConfig')
cmo.createCoherencePartitionCacheProperty('expiry-delay')
cd('CoherencePartitionCacheProperties/expiry-delay')
cmo.setValue('3600s')

キャッシュ構成プロパティは、destroyCoherencePartitionCacheConfig操作を使用して削除することもできます。次に例を示します。

cd('/')
cd('/Partitions/MyPartition-1')
cmo.createCoherencePartitionCacheConfig('MyConfig')
cd('CoherencePartitionCacheConfigs/MyConfig/CoherencePartitionCacheProperties/
expiry-delay')
property = cmo
cd('..')
cmo.destroyCoherencePartitionCacheProperty(property)

パーティション間でのキャッシュ共有の有効化

キャッシュの共有は、キャッシュをデプロイする各パーティションで明示的に設定する必要があります。1つのパーティションのキャッシュに対してキャッシュ共有を有効にした場合、すべてのパーティションで自動的にキャッシュが共有されることはありません。

同じキャッシュ・スキームをマルチテナント・ドメインで共有キャッシュおよび非共有キャッシュの両方に使用することはできません。ただし、キャッシュ・スキームでは、スキーム参照を使用して、同じスキーム定義を再利用できます。次に例を示します。

<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>ExamplesPartitioned-NonShared</scheme-name>
</cache-mapping>
<cache-mapping>
<cache-name>example-shared</cache-name>
<scheme-name>ExamplesPartitioned-Shared</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<distributed-scheme>
<scheme-name>ExamplesPartitioned-NonShared</scheme-name>
<scheme-ref>ExamplesPartitionedScheme</scheme-ref>
</distributed-scheme>
<distributed-scheme>
<scheme-name>ExamplesPartitioned-Shared</scheme-name>
<scheme-ref>ExamplesPartitionedScheme</scheme-ref>
</distributed-scheme>
<distributed-scheme>
<scheme-name>ExamplesPartitionedScheme</scheme-name>
<service-name>ExamplesPartitionedCache</service-name>
<backing-map-scheme>
<local-scheme>
<high-units>32M</high-units>
<unit-calculator>binary</unit-calculator>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>

キャッシュ共有を有効化する主な手順は次のとおりです。

1. パーティション設定を編集するパーティションを選択します。

2. パーティションにOracle Coherenceキャッシュを追加します。

3. キャッシュが共有されることを指定します。

4. キャッシュを共有する各パーティションでこのプロセスを繰り返します。構成値は、各パーティションで同じである必要があります。

Fusion Middleware Controlを使用して、キャッシュ共有を有効化するには、オンライン・ヘルプのドメイン・パーティションOracle Coherenceキャッシュの構成に関する項を参照してください。

WLSTの使用

パーティション間でのキャッシュ共有を有効化するには、Weblogic ServerドメインMBeanサーバーに接続し、trueパラメータを指定してsetShared操作を実行します。次に例を示します。

cd('/')
cd('/Partitions/MyPartition-1')
cmo.createCoherencePartitionCacheConfig('MyConfig')
cd('CoherencePartitionCacheConfigs/MyConfig')
cmo.setShared(true)

cd('/')
cd('/Partitions/MyPartition-2')
cmo.createCoherencePartitionCacheConfig('MyConfig')
cd('CoherencePartitionCacheConfigs/MyConfig')
cmo.setShared(true)

マルチテナント・ドメインでのOracle Coherenceアプリケーションの保護

Oracle Coherenceアプリケーションでは、WebLogic Serverで使用可能な認可機能を使用します。認可ロールおよびポリシーは、キャッシュおよびサービスに構成され、各パーティションに設定される必要があります。マルチテナント・ドメインでのセキュリティの詳細は、「セキュリティの構成」を参照してください。WebLogic ServerにおけるOracle Coherenceセキュリティの詳細は、『Oracle Coherenceの保護』を参照してください。

注意:

共有キャッシュは、グローバル・パーティションによって所有され、認可はグローバル・レルムに基づきます。

Oracle Coherenceの構成: 関連タスクおよびリンク

- マルチテナントでのOracle Coherenceの使用例の詳細は、WebLogic Serverコード・サンプルに含まれている、管理対象Oracle Coherenceサーバー - マルチテナント例に関する項を参照してください。

- Oracle Coherenceクラスタの作成の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。

- Oracle Coherenceアプリケーションのパッケージ化の詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。

- Oracle WebLogic ServerにおけるOracle Coherenceの保護の詳細は、『Oracle Coherenceの保護』を参照してください。

14 JDBCの構成

この章では、Oracle WebLogic Server Multitenant (MT)でデータ・ソース・リソース定義がどのようにサポートされているかについて説明します。

この章の内容は次のとおりです。

- JDBCの構成: 前提条件

- サポートされるデータ・ソース・タイプについて

- JDBCデータ・ソースの構成: 考慮事項

- JDBCデータ・ソースの構成: WLSTの例

- JDBCデータ・ソースの構成: 管理コンソールの例

- JDBCデータ・ソースの構成: Fusion Middleware Controlの例

- JDBCデータ・ソースの構成: RESTの例

- JDBCデータ・ソースの構成: 関連タスクおよびリンク

JDBCの構成: 前提条件

マルチテナント環境でJava Database Connectivity (JDBC)を構成する前に、次のものをすでに作成していることを前提としています。

- 仮想ターゲット。詳細は、「仮想ターゲットの構成」を参照してください。

- ドメイン・パーティション。詳細は、「ドメイン・パーティションの構成」を参照してください。

- パーティションに固有のセキュリティ・レルム(必要な場合)。詳細は、セキュリティの構成を参照してください。

- リソース・グループ・テンプレート(必要な場合)。詳細は、「リソース・グループ・テンプレートの構成」を参照してください。

- リソース・グループ。詳細は、「リソース・グループの構成」を参照してください。

この章では、既存のWebLogic Serverデータ・ソースを熟知していることを前提としています。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』を参照してください

サポートされるデータ・ソース・タイプについて

非マルチテナントWebLogic Server環境で作業する場合、データ・ソースは、システム・リソースとして定義することも、ドメイン・レベルでデプロイすることもできます。マルチテナント環境でWebLogic Server MTを使用する場合、データ・ソースは次のスコープで定義することもできます。

- ドメイン・レベルで作成されたリソース・グループの一部として。参照されるデータ・ソースは、ドメイン・レベルのスコープの適切なデータベース資格証明、URL、ドライバ・プロパティおよび属性で修飾される必要があります。ドメイン・レベルでリソース・グループによって参照されるデータ・ソースは、グローバル・システム・リソースです。データ・ソース・モジュール・ディスクリプタは、単一のドメイン・レベルのリソース・グループのみが参照できます。

- パーティション・レベルで作成されたリソース・グループの一部として。参照されるデータ・ソースは、パーティションの適切なデータベース資格証明、URL、ドライバ・プロパティおよび属性で修飾される必要があります。データ・ソース・ディスクリプタは、パーティション内の単一のリソース・グループのみが参照できます。

- ドメイン・レベルで作成されたリソース・グループ・テンプレートの一部として。このような定義は、リソース・グループ・テンプレートを参照する個々のパーティションによって完全修飾されたテンプレート・データ・ソース定義とみなされます。

- リソース・グループ・テンプレートに基づいたパーティション・レベルのリソース・グループの一部として。リソース・グループ・テンプレートによって参照されるテンプレート・リソース・ディスクリプタが、URLや資格証明が不足しているか正しくない、またはその両方により完全ではない可能性があるため、各リソース・グループによって定義されるリソースは、パーティション・ランタイムへのデプロイメントに指定された適切なオーバーライドを持っている必要があります。
JDBCSystemResourceOverrideMBeanを使用して、パーティション・レベルで定義されたリソース・グループ・テンプレートに基づいたリソース・グループの、user、passwordおよびURL属性をオーバーライドできます。これらの3つの属性は、ほとんどのテンプレート・データ・ソース設定がパーティション間で共通のSoftware-as-a-Service (SaaS)ユースケースの場合に、通常パーティションごとに修飾されるデータ・ソース設定を表します。オーバーライドMBeanを使用する場合、リソース・グループによって参照される各データ・ソースに対して個別のオーバーライドMBeanを定義する必要があります。実行時(データ・ソース・デプロイメント後)に行われたこれらの属性への構成変更は、パーティション・データ・ソースを再起動して、変更を有効にする必要があります。

リソース・グループによって参照されるデータ・ソース・ディスクリプタの任意の属性をオーバーライドできるリソース・グループに対してリソース・デプロイメント・プランを指定できます。単一のデプロイメント・プランは、パスがパーティション構成内に指定される外部ファイルで定義され、パーティション内のすべてのデータ・ソースに適用されます。リソース・グループ参照されたデータ・ソースにオーバーライド属性を適用する前に、リソース・デプロイメント・プランが処理されます。特定のデータ・ソース属性がリソース・デプロイメント・プランとオーバーライドMBeanの両方で指定された場合、オーバーライドMBeanの値が優先されます。詳細は、「リソース・オーバーライドの構成」を参照してください。

注意:

JDBCを直接使用するJava EEアプリケーションでJDBCオーバーライドを使用するには、かわりにデータ・ソースを使用するようにアプリケーションを更新する必要があります。

- パーティション・レベルでデプロイされたオブジェクトの一部として。これには、EARやWARファイル内のパッケージ化されたデータ・ソース、スタンドアロン・データ・ソース・モジュール、またはアプリケーションのJava注釈やディスクリプタ・ファイルで定義されたJava EEデータ・ソース定義などが含まれます。これらの各オブジェクトは、パーティションにデプロイできます。パッケージ化されたデータ・ソースおよびスタンドアロン・データ・ソースは、アプリケーション・デプロイメント・プランを使用して更新でき、対応するパーティション化されていないデータ・ソースと同じです。Java EEデータ・ソース定義には、オーバーライド・メカニズムはありません。

まとめると、データ・ソース・コンポーネントは、次のデータ・ソース・デプロイメント・タイプをサポートしています。

データ・ソース・デプロイメント・タイプ

パラメータ・オーバーライド・サポート

オプションでリソース・グループにスコープされた、ドメイン・レベルのシステム・リソース

オーバーライド・サポートはありません。データ・ソースを直接変更します。

リソース・グループ・テンプレートのシステム・リソース

データ・ソースを直接変更するか、リソース・グループ・テンプレートから導出されたリソース・グループでオーバーライドします。

リソース・グループのパーティション・レベルのシステム・リソース

オーバーライド・サポートはありません。データ・ソースを直接変更します。

リソース・グループ・テンプレートに基づいたリソース・グループのパーティション・レベルのシステム・リソース

JDBCシステム・リソース・オーバーライドまたはリソース・デプロイメント・プランを使用します。

ドメインまたはパーティションにデプロイされたアプリケーション・スコープの/パッケージ化されたデータ・ソース

アプリケーション・デプロイメント・プランを使用します。

ドメインまたはパーティションにデプロイされたスタンドアロン・データ・ソース・モジュール

アプリケーション・デプロイメント・プランを使用します。

ドメインまたはパーティションにデプロイされたデータ・ソース定義(Java EE 6)

オーバーライド・サポートはありません。

データ・ソースに関連するドメイン構造は次のとおりです。

- ドメイン:

- グローバル・スコープのデータ・ソース

- グローバル・スコープのデータ・ソースを含むドメイン・レベルのリソース・グループ

- データ・ソースを含むドメイン・レベルのリソース・グループ・テンプレート

- パーティション:

- データ・ソースを含むパーティション・レベルのリソース・グループ

- リソース・グループ・テンプレートに基づいたパーティション・レベルのリソース・グループ

- パーティション・レベルのJDBCシステム・リソース・オーバーライド

- パーティション・レベルのリソース・デプロイメント・プラン

- パーティション・レベルでデプロイされたオブジェクト

リソース・グループ・テンプレートは、データ・ソース・モジュール・ディスクリプタなどのシステム・リソース定義を参照します。パーティションは、システム・リソース定義を直接参照する、またはリソース・グループ・テンプレートを参照する、あるいはその両方を参照する、1つ以上のリソース・グループを定義します。

JDBCデータ・ソースの構成: 考慮事項

次の各項では、マルチテナント環境でデータ・ソースを構成する際の考慮事項について説明します。

データ・ソースのスコープ

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたデータ・ソースの作成は、ドメイン・レベルのシステム・リソースの作成と似ています。唯一の追加の手順は、スコープを指定することです。Oracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Control (FMWC)では、作成プロセスの最初の手順に、データ・ソースの作成に使用できるスコープを示すメニューがあります。WebLogic Scripting Tool (WLST)を使用する場合、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateJDBCSystemResourceメソッドを使用して、データ・ソースを作成する必要があります。

データ・ソースを編集する場合、データ・ソースが正しいスコープ内に存在する必要があります。データ・ソースを更新するための追加の変更はありません。

ランタイム・モニタリング

既存のデータ・ソース・ランタイムMBeanは、パーティション・スコープのデータ・ソース・デプロイメントでサポートされており、JMXベースの管理クライアントにアクセスできます。ランタイムMBeanタイプは、デプロイされるデータ・ソース・タイプに依存します。たとえば、汎用データ・ソースはJDBCDataSourceRuntimeMBeanタイプで表されます。

パーティション・スコープのデータ・ソース・デプロイメントに対して作成されたDataSourceRuntimeMBeanは、パーティションのJDBCPartitionRuntimeMBeanが親で、パーティションのデータ・ソース・インスタンスに固有の統計および実行時操作を提供します。

パーティション・スコープのデータ・ソース・ランタイムMBeanには、次のような名前属性があります。

com.bea:ServerRuntime=myserver,Name=ds,Type=JDBCDataSourceRuntime, JDBCPartitionRuntime=Partition1,PartitionRuntime=Partition1

親属性は次のように設定されます。

com.bea:ServerRuntime=myserver,Name=Partition1,Type=JDBCPartitionRuntime

前述の例では、パーティション・スコープのデータ・ソース名はds、パーティション名はPartition1、サーバー名はmyserverです。

データ・ソース・ランタイムMBeanは、serverRuntime/PartitionRuntimes/partition/JDBCPartitionRuntimeの下のランタイムMBean階層にあります。一方、非パーティション・スコープのデータ・ソース・デプロイメントのランタイムMBeanは、serverRuntime/JDBCServiceRuntimeの下にあります。

ドメイン・レベルで定義されたMBeanは、パーティション・ユーザーには表示されません。非動的パラメータがパーティションで更新された場合、変更はただちに有効になりませんが、次にパーティションのデータ・ソースを再起動するか、パーティション自体を再起動すると、有効になります。サーバーを再起動する必要はありません。

セキュリティ

パーティション・データ・ソース構成に関連するセキュリティ・ロールおよびポリシー定義は、システム管理者が担当します。詳細は、セキュリティの構成を参照してください。パーティションに固有のセキュリティ・レルムの構成は、オプションです。その他の点では、パーティション・スコープのデータ・ソースのセキュリティの構成は、グローバル・データ・ソースの場合と似ています。データ・ソース・セキュリティの詳細は、WebLogic Server MBeanのセキュリティに関する項およびデータ・ソース・セキュリティの理解に関する項を参照してください。

データ・ソース認可検証は、パーティション固有のセキュリティ・レルムを使用したパーティション・スコープのデプロイメントでサポートされます(該当する場合)。

パーティション・スコープのデプロイメントのためのデータ・ソース・セキュリティ機能で使用する資格証明マッパー・エントリの定義がサポートされています。データ・ソース資格証明マッパー・エントリは、データ・ソース・セキュリティ・オプション(アイデンティティ・ベースのプーリング、クライアント識別子の設定およびプロキシ認証)で使用されます。資格証明マッパー・エントリは、WebLogic Server管理コンソールで作成する必要があります(Fusion Middleware Controlではサポートされていません)。

トランザクションのスコープ

XAトランザクションのスコープは、ドメイン・レベルで、パーティション・レベルのリソースへのアクセスに及びます。パーティション・スコープのリソース名は、パーティション名で修飾され、リソースがトランザクション・マネージャに対して一意となり、独立して管理されるようにします。

トランザクション構成および制限の詳細は、「トランザクションの構成」を参照してください。

パーティション・ライフサイクル

パーティションに関連付けられたデータ・ソースは、パーティションの起動中に起動し、パーティションの停止中または強制シャットダウン中に停止します。パーティションの起動および停止は、WebLogic Serverシステム管理者およびオペレータ、パーティション管理者およびパーティション・オペレータが実行できます。

診断イメージのソース

診断イメージのスコープをパーティションに制限できます。パーティションを指定する診断イメージ・キャプチャ・リクエストの場合、データ・ソース出力は、ターゲット・パーティションにスコープされたデータ・ソースに制限されます。詳細は、「パーティション・スコープの診断イメージ・キャプチャの構成」を参照してください。

ロギング

ドメイン・ログ・フォーマットが12.2.1以前のロギングとの下位互換性のために構成されていない場合、パーティション・スコープのデータ・ソース・ログ・メッセージは、パーティションIDと名前で修飾されます。ロギングの詳細は、「パーティションのモニタリングおよびデバッグ」を参照してください。

JNDIバインド

データ・ソースは、データ・ソース・モジュール・ディスクリプタで指定された名前に従って、デプロイメント時に適切なJNDIコンテキストにバインドされます。

データ・ソースのスコープ

JNDIネームスペース

アプリケーション

アプリケーション

パーティション・リソース・グループ

パーティション

ドメイン・リソース・グループ

グローバル

JNDIネームスペースから取得されたデータ・ソース・インスタンスは、異なるパーティション・コンテキストでアクセスされても、スコープを保持することに注意してください。

あるパーティションで実行中のアプリケーションが別のパーティションのリソースにアクセスする場合、クロス・パーティション・アクセスが発生します。このことは、パーティション・レベルからドメイン・レベルへ、およびその逆のアクセスにも該当します。パーティションURL、またはdomain:構文かpartition:構文を使用して、あるパーティションで実行中のアプリケーションが別のパーティションで定義されたデータ・ソースのJNDIルックアップを実行する場合、クロス・パーティション・データ・ソース・アクセスが発生します。WebLogic Server 12.2.1では、これにより、アプリケーションで変更が必要であることを認識するように、ログに警告が生成されます。

サポートされていない非推奨のドライバ

JDBC URL接頭辞の下に登録される3つのWebLogic Serverドライバ・タイプ(jdbc:weblogic:pool、jdbc:weblogic:rmiおよびjdbc:weblogic:jts)は、非推奨で、パーティション・スコープのデータ・ソースでサポートされていません。データ・ソース名でconnectionPoolIDプロパティを指定する既存のJDBCクライアント・ロジックでは、パーティション内のデータ・ソースの検出に失敗することはありません。プール、JTSまたはRMIドライバを使用するアプリケーションは、パーティション構成で機能するのではなくデータ・ソースJNDI名を指定するように、構成を変更する必要があります。

これに関連して、EJB RDBMS Beanディスクリプタは、JDBCセッションでパーティション・スコープのデータ・ソースにアクセスするために<pool-name>を使用することはできません。この状況では、JNDI名の使用がサポートされます。

JDBCデータ・ソースの構成: WLSTの例

次に示すのは、マルチテナント環境でのWebLogic Serverデータ・ソースの使用を示すWLSTプログラムのサンプルです。2つの仮想ターゲット(ドメイン用とパーティション用)を作成します。1つのパーティションを作成します。次に、リソース・グループ、リソース・グループ・テンプレート、およびパーティション内のリソース・グループ・テンプレートに基づいたリソース・グループを作成します。その後、次の4つのスコープに同じデータ・ソースを作成します。

- リソース・グループ・テンプレート

- リソース・グループ・テンプレートおよびシステム・オーバーライドを使用したリソース・グループ

- リソース・グループ

- ドメイン

最後に、パーティションを起動します。

import sys, socket
import os
hostname = socket.gethostname()
partition='partition1'
connect("weblogic","welcome1","t3://"+hostname+":7001")
edit()
startEdit()
serverBean = getMBean('/Servers/myserver')
realmBean=cmo.getSecurityConfiguration().getDefaultRealm()
pB = cmo.lookupPartition(partition)
if pB != None:
print "[ERROR] Partition with Name '%s' already exits" % partition
cancelEdit('y')
exit('y')
host='%s.us.company.com' %hostname
def createVirtualTarget(name, host, domain, target, prefix):
print "Creating virtual target " + name
domain=getMBean('/')
vt=domain.createVirtualTarget(name)
vt.addTarget(target)
vt.setHostNames(jarray.array([String(host)],String))
vt.setUriPrefix(prefix)
return vt
def createJDBCSystemResource(owner, resourceName):
systemResource=owner.createJDBCSystemResource(resourceName)
systemResource.setName(resourceName)
jdbcResource=systemResource.getJDBCResource()
jdbcResource.setName(resourceName)
driverParams=jdbcResource.getJDBCDriverParams()
driverParams.setDriverName('oracle.jdbc.OracleDriver')
driverParams.setUrl('jdbc:oracle:thin:@dbhost:1521/otrade')
#    driverParams.setDriverName('org.apache.derby.jdbc.EmbeddedDriver')
#    driverParams.setUrl('jdbc:derby:memory:mydb\;create=true')
properties = driverParams.getProperties()
properties.createProperty('user', 'dbuser')
driverParams.setPassword('MYPASSWD')
jdbcDataSourceParams=jdbcResource.getJDBCDataSourceParams()
jdbcDataSourceParams.addJNDIName(resourceName)
jdbcDataSourceParams.setGlobalTransactionsProtocol('None')
return systemResource
def createJDBCSystemResourceOverride(partition, dsname, url, user, password):
oMBean=partition.createJDBCSystemResourceOverride(dsname)
oMBean.setURL(url)
oMBean.setUser(user)
oMBean.setPassword(password)
vtname='partition1'
vtBean=createVirtualTarget(vtname+'-vtarget', host, getMBean('/'),
getMBean('/Servers/myserver'), '/' + vtname)
vtname='domain'
vtBean1=createVirtualTarget(vtname+'-vtarget', host, getMBean('/'),
getMBean('/Servers/myserver'), '/' + vtname)
print 'Creating partition partition1'
domain = getMBean("/")
partition1MBean=domain.createPartition('partition1')
partition1MBean.addDefaultTarget(vtBean)
partition1MBean.setRealm(realmBean)
partition1MBean.addAvailableTarget(vtBean)
print 'Creating resource group template rgt'
rgtBean=cmo.createResourceGroupTemplate('rgt')
print 'Creating resource group partition1-rg in partition1'
partitionrgMBean=partition1MBean.createResourceGroup('partition1-rg')
partitionrgMBean.addTarget(vtBean)
print 'Creating resource group partition1-rg-with-template in partition1'
partition1rgitMBean=partition1MBean.createResourceGroup('partition1-rg-with-template')
partition1rgitMBean.setResourceGroupTemplate(getMBean('/ResourceGroupTemplates/rgt'))
print 'Creating domain resource group global-rg'
cd('/')
cmo.createResourceGroup('global-rg')
cd("/ResourceGroups/global-rg")
cmo.addTarget(vtBean1)
save()
activate()
# Create 4 data sources
startEdit()
print "Creating data source ds-in-template in rgt"
createJDBCSystemResource(owner=rgtBean, resourceName='ds-in-template')
activate()
startEdit()
print "Creating data source ds-using-template in rg using rgt"
createJDBCSystemResource(owner=partition1rgitMBean, resourceName='ds-using-template')
activate()
startEdit()
print "Creating override for data source ds-in-template"
createJDBCSystemResourceOverride(partition1MBean, 'ds-in-template',
jdbc:oracle:thin:@dbhost:1521/otrade2', 'scott', 'tiger',1,10,50)
activate()
startEdit()
print "Creating data source ds in partition1-rg"
createJDBCSystemResource(owner=partitionrgMBean, resourceName='ds')
activate()
# You cannot create a data source directly in a partition.
# createJDBCSystemResource(owner=partition1MBean, resourceName='ds')
startEdit()
print "Creating data source ds in domain"
createJDBCSystemResource(owner=domain, resourceName='ds')
cd('/SystemResources/' + "ds" )
set('Targets',jarray.array([ObjectName('com.bea:Name=' + 'AdminServer' + ',Type=Server')], ObjectName))
save()
activate()
startPartitionWait(partition1MBean)
def createJDBCSystemResourceOverride(partition, dsname, url, user, password,
initialCapacity, minCapacity, maxCapacity):
oMBean=partition.createJDBCSystemResourceOverride(dsname)
oMBean.setDataSourceName(dsname)
oMBean.setURL(url)
oMBean.setUser(user)
oMBean.setPassword(password)
oMBean.setInitialCapacity(initialCapacity)
oMBean.setMinCapacity(minCapacity)
oMBean.setMaxCapacity(maxCapacity)

createJDBCSystemResourceメソッドは、データ・ソースを作成するための多くの異なるパラメータがないという点で、通常とは異なります。かわりに、同じパラメータが毎回使用されます。

次のWLST出力のサンプルでは、サーバー・ランタイムでのグローバル・システム・リソースのデータ・ソース・デプロイメント、パーティション・ランタイムでの3つのパーティション・スコープのデータ・ソース・デプロイメントを示しています。

> ls('JDBCSystemResources')
dr--   ds
> ls('Partitions')
drw-   partition1
> serverRuntime()
> ls('JDBCServiceRuntime/AdminServer/JDBCDataSourceRuntimeMBeans')
dr--   ds
> ls(
''PartitionRuntimes/partition1/JDBCPartitionRuntime/partition1/JDBCDataSourceRuntimeMBeans')
dr--   ds
dr--   ds-in-template
dr--   ds-using-template

JDBCデータ・ソースの構成: 管理コンソールの例

次の各項では、WebLogic Server管理コンソールでの「JDBCデータ・ソースの構成: WLSTの例」の結果を示しています。

注意:

リソース・グループ・テンプレートでデータ・ソースを作成する場合、URLやユーザーなどの値がリソース・グループでオーバーライドされることがあります。これは予期されるユースケースであるため、管理コンソールで特別に処理されます。値を入力しない場合は、属性名に基づくプレースホルダ値が入力されます。

JDBCデータ・ソースの構成

JDBCデータ・ソースを構成するには、次の手順を実行します。

1. WebLogic Server管理コンソールのホーム・ページから、「データ・ソース」を選択して、すべてのスコープ(ドメイン、リソース・グループ・テンプレートおよびリソース・グループ)に構成されたすべてのシステム・リソース・データ・ソースがリストされるサマリー表を表示します。この表には、スコープおよびパーティション名(該当する場合)が表示されます。

2. データ・ソースの名前を選択します。

3. 「構成」→「一般」ページを選択して、既存のJDBCシステム・リソース・オーバーライドによる影響を受けない構成属性を表示します。オーバーライドは、このレベルでは表示されません。

4. 「セキュリティ」→「資格証明マッピング」を選択し、「新規」をクリックします。データ・ソースに関連付けられた資格証明マッピングのWebLogic Serverユーザー、リモート・ユーザーおよびリモート・パスワードの値を入力します。

5. データ・ソースのサマリー・ページで、「新規」をクリックし、「汎用データ・ソース」を選択します。「スコープ」メニューから、グローバル・データ・ソース、または既存のリソース・グループ・テンプレートまたはリソース・グループにデータ・ソースを作成するかどうかを指定できます(使用可能なすべてのスコープの名前がメニューに表示されます)。

6. WebLogic Server管理コンソールのホーム・ページから、「ドメイン・パーティション」を選択して、構成されたすべてのパーティションがリストされるドメイン・パーティションのサマリー表を表示します。各パーティションの情報には、ネストされたリソース・グループ、デフォルト・ターゲットおよび状態が含まれます。

7. 特定のパーティションを構成するには、パーティションの名前をクリックし、「リソース・オーバーライド」→「JDBCシステム」を選択して、既存のJDBCオーバーライドがリストされるサマリー表を表示します。

8. 新しいJDBCシステム・リソース・オーバーライドを作成するには、「新規」をクリックします。「データ・ソース」メニューには、オーバーライドの作成に使用できるデータ・ソースがリストされます。WebLogic Server管理コンソールには、パーティション内のすべてのリソース・グループのデータ・ソースがリストされますが、リソース・グループ・テンプレートから導出されたリソース・グループのみ、オーバーライドが必要です。非導出リソース・グループは直接更新できます。オーバーライドはお薦めしません。既存のオーバーライドごとに、表には、オーバーライドの名前、データ・ソースおよびURLが表示されます。オーバーライド名をクリックすると、オーバーライド値(URL、ユーザーまたはパスワード)を更新できる構成ページが表示されます。

JDBCデータ・ソースのモニタリング

データ・ソースを様々なレベルでモニターするには、次の手順を実行します。

1. ドメイン・レベルで、「ホーム」ページから、「データ・ソース」→「モニタリング」を選択して、すべてのスコープ内で実行中のすべてのデータ・ソースを表示します。

2. パーティション・レベルで、「ドメイン・パーティション」を選択し、特定のパーティション名をクリックします。

3. 「リソース・グループ」を選択し、特定のリソース・グループ名をクリックし、「サービス」→「JDBC」を選択して、このスコープで定義されたデータ・ソースを表示します。

JDBCデータ・ソース診断の構成

パーティション・スコープの診断イメージを生成するには、次の手順を実行します。

1. ホーム・ページから、「診断イメージ」を選択します。

2. 目的のサーバーのプラス記号(+)をクリックして、リストを展開します。

3. 特定のパーティション名のラジオ・ボタンを選択し、「イメージのキャプチャ」をクリックします。

「診断イメージのプロパティ」ページでは、イメージ.zipファイルの宛先ディレクトリの場所を指定します。

4. .zipファイルを開いて、次のサンプルのようなJDBC.txtファイルを表示します。リソース名は$partitionnameで修飾されることに注意してください。

Dumping Resource Pool:ds-in-template$partition1
Resource Pool:ds-in-template$partition1:dumpPool Current Capacity = 1
Resource Pool:ds-in-template$partition1:dumpPool dumping available resources, #entries = 1
Resource Pool:ds-in-template$partition1:dumpPool available[0] = autoCommit=true,enabled=true,isXA=false,isJTS=false,vendorID=100,connUsed=false,doInit=false,'null',destroyed=false,poolname=ds-in-template$partition1,appname=null,moduleName=null,connectTime=862,dirtyIsolationLevel=false,initialIsolationLevel=2,infected=false,lastSuccessfulConnectionUse=0,secondsToTrustAnIdlePoolConnection=10,currentUser=null,currentThread=null,lastUser=null,currentError=null,currentErrorTimestamp=null,JDBC4Runtime=true,supportStatementPoolable=true,needRestoreClientInfo=false,defaultClientInfo={},supportIsValid=true
Resource Pool:ds-in-template$partition1:dumpPool dumping reserved resources, #entries = 0
Resource Pool:ds-in-template$partition1:dumpPool # dead resources = 0
Dumping Resource Pool: ds-in-template$partition1 complete
Dumping Resource Pool:ds$partition1
Resource Pool:ds$partition1:dumpPool Current Capacity = 1
Resource Pool:ds$partition1:dumpPool dumping available resources, #entries = 1
Resource Pool:ds$partition1:dumpPool available[0] = autoCommit=true,enabled=true,isXA=false,isJTS=false,vendorID=100,connUsed=false,doInit=false,'null',destroyed=false,poolname=ds$partition1,appname=null,moduleName=null,connectTime=1277,dirtyIsolationLevel=false,initialIsolationLevel=2,infected=false,lastSuccessfulConnectionUse=0,secondsToTrustAnIdlePoolConnection=10,currentUser=null,currentThread=null,lastUser=null,currentError=null,currentErrorTimestamp=null,JDBC4Runtime=true,supportStatementPoolable=true,needRestoreClientInfo=false,defaultClientInfo={},supportIsValid=true
Resource Pool:ds$partition1:dumpPool dumping reserved resources, #entries = 0
Resource Pool:ds$partition1:dumpPool # dead resources = 0
Dumping Resource Pool: ds$partition1 complete
Dumping Resource Pool:ds-using-template$partition1
Resource Pool:ds-using-template$partition1:dumpPool Current Capacity = 1
Resource Pool:ds-using-template$partition1:dumpPool dumping available resources, #entries = 1
Resource Pool:ds-using-template$partition1:dumpPool available[0] = autoCommit=true,enabled=true,isXA=false,isJTS=false,vendorID=100,connUsed=false,doInit=false,'null',destroyed=false,poolname=ds-using-template$partition1,appname=null,moduleName=null,connectTime=467,dirtyIsolationLevel=false,initialIsolationLevel=2,infected=false,lastSuccessfulConnectionUse=0,secondsToTrustAnIdlePoolConnection=10,currentUser=null,currentThread=null,lastUser=null,currentError=null,currentErrorTimestamp=null,JDBC4Runtime=true,supportStatementPoolable=true,needRestoreClientInfo=false,defaultClientInfo={},supportIsValid=true
Resource Pool:ds-using-template$partition1:dumpPool dumping reserved resources, #entries = 0
Resource Pool:ds-using-template$partition1:dumpPool # dead resources = 0
Dumping Resource Pool: ds-using-template$partition1 complete

パーティション・スコープのデプロイメントの構成

パーティション・スコープのデプロイメントを構成するには、次の手順を実行します。

1. 非パーティション・スコープのデプロイメントと同様に、ホーム・ページから、「デプロイメント」を選択し、「インストール」をクリックして、デプロイするEARまたはWARファイルを検索します。

2. デプロイメント・スコープの「アプリケーション・インストール・アシスタント」の最初のページで、グローバル・スコープ、または既存のリソース・グループ・テンプレートかリソース・グループのいずれかを選択できます。

3. EARまたはWARファイルをデプロイした後で、コンソールの関連付けられたリンクをクリックすることによって、関連するモジュールおよびスコープを表示できます。最初は、デプロイメント・プランはありません。

アプリケーション・デプロイメント・プランを作成するには、自動的にプランを作成するWebLogic Server管理コンソールを使用することをお薦めします。

1. デプロイされたデータ・ソースを選択します。

2. 構成を変更します。

3. 変更を保存します。

コンソールによって、関連するデプロイメント・プランが作成され、デプロイメント・プラン名が指定されます。次に、アプリケーション・デプロイメント・プランのサンプルを示します。

<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd">
<application-name>ds-jdbc.xml</application-name>
<variable-definition>
<variable>
<name>JDBCConnectionPoolParams_InitialCapacity_14417323945070</name>
<value>1</value>
</variable>
<variable>
<name>JDBCConnectionPoolParams_MinCapacity_14417323945071</name>
<value>1</value>
</variable>
<variable>
<name>JDBCConnectionPoolParams_StatementCacheSize_14417323945072</name>
<value>10</value>
</variable>
<variable>
<name>JDBCConnectionPoolParams_MaxCapacity_14417323945073</name>
<value>20</value>
</variable>
<variable>
<name>JDBCConnectionPoolParams_StatementCacheType_14417323945074</name>
<value>LRU</value>
</variable>
</variable-definition>
<module-override>
<module-name>ds-jdbc.xml</module-name>
<module-type>jdbc</module-type>
<module-descriptor external="false">
<root-element>jdbc-data-source</root-element>
<uri>.</uri>
<variable-assignment>
<name>JDBCConnectionPoolParams_InitialCapacity_14417323945070</name>
<xpath>/jdbc-data-source/jdbc-connection-pool-params/initial-capacity</xpath>
</variable-assignment>
<variable-assignment>
<name>JDBCConnectionPoolParams_MinCapacity_14417323945071</name>
<xpath>/jdbc-data-source/jdbc-connection-pool-params/min-capacity</xpath>
</variable-assignment>
<variable-assignment>
<name>JDBCConnectionPoolParams_StatementCacheSize_14417323945072</name>
<xpath>/jdbc-data-source/jdbc-connection-pool-params/statement-cache-size</xpath>
</variable-assignment>
<variable-assignment>
<name>JDBCConnectionPoolParams_MaxCapacity_14417323945073</name>
<xpath>/jdbc-data-source/jdbc-connection-pool-params/max-capacity</xpath>
</variable-assignment>
<variable-assignment>
<name>JDBCConnectionPoolParams_StatementCacheType_14417323945074</name>
<xpath>/jdbc-data-source/jdbc-connection-pool-params/statement-cache-type</xpath>
</variable-assignment>
</module-descriptor>
</module-override>
<config-root>D:\tmp1221\partition1\ds-jdbc.xml\app\plan</config-root>
</deployment-plan>

リソース・デプロイメント・プランの使用方法

ユーザー、パスワードまたはURLの値以外のリソース・グループ・テンプレートから導出されたパーティション・データ・ソースの属性をオーバーライドする場合、リソース・デプロイメント・プランを作成する必要があります。詳細は、「リソース・デプロイメント・プランの構成: 主な手順およびWLSTの例」を参照してください。

次に、リソース・デプロイメント・プランのサンプルを示します。descriptor-file-path、resource-typeおよびresource name要素は、ディスクリプタが存在する場所を識別するために使用されます。

<resource-deployment-plan
xmlns="http://xmlns.oracle.com/weblogic/resource-deployment-plan"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/resource-deployment-plan
http://xmlns.oracle.com/weblogic/resource-deployment-plan/1.0/resource-deployment-plan.xsd">
<variable-definition>
<variable>
<name>JDBCConnectionPoolParams_InitialCapacity_14423700625350</name>
<value>2</value>
</variable>
<variable>
<name>JDBCConnectionPoolParams_MinCapacity_14423700625511</name>
<value>5</value>
</variable>
<variable>
<name>JDBCConnectionPoolParams_StatementCacheSize_14423700625512</name>
<value>10</value>
</variable>
<variable>
<name>JDBCConnectionPoolParams_StatementCacheType_14423700625513</name>
<value>LRU</value>
</variable>
</variable-definition>
<external-resource-override>
<resource-name>ds-in-template</resource-name>
<resource-type>jdbc-system-resource</resource-type>
<root-element>jdbc-data-source</root-element>
<descriptor-file-path>resource-group-templates/rgt/jdbc</descriptor-file-path>
<variable-assignment>
<name>JDBCConnectionPoolParams_InitialCapacity_14423700625350</name>
<xpath>/jdbc-data-source/jdbc-connection-pool-params/initial-capacity</xpath>
</variable-assignment>
<variable-assignment>
<name>JDBCConnectionPoolParams_MinCapacity_14423700625511</name>
<xpath>/jdbc-data-source/jdbc-connection-pool-params/min-capacity</xpath>
</variable-assignment>
<variable-assignment>
<name>JDBCConnectionPoolParams_StatementCacheSize_14423700625512</name>
<xpath>/jdbc-data-source/jdbc-connection-pool-params/statement-cache-size</xpath>
</variable-assignment>
<variable-assignment>
<name>JDBCConnectionPoolParams_StatementCacheType_14423700625513</name>
<xpath>/jdbc-data-source/jdbc-connection-pool-params/statement-cache-type</xpath>
</variable-assignment>
</external-resource-override>
</resource-deployment-plan>

リソース・デプロイメント・プランをパーティションに関連付けるには、パーティションの「構成」→「一般」ページにリソース・デプロイメント・プランへのパスを指定します。

JDBCデータ・ソースの構成: Fusion Middleware Controlの例

Fusion Middleware Controlを使用して、WebLogic Server管理コンソールを使用する場合と類似した方法でJDBCオーバーライドを構成できますが、ユーザー・インタフェースおよびナビゲーション・パスが異なります。ただし、データ・ソース・セキュリティは現在Fusion Middleware Controlで使用できないため、WebLogic Server管理コンソールを使用して構成する必要があります。

1. 「WebLogicドメイン」メニューから、「JDBCデータ・ソース」を選択して、既存のデータ・ソースと関連するタイプ、スコープおよび該当する場合はリソース・グループ、リソース・グループ・テンプレートおよびパーティション名のリストを表示します。

2. 既存のデータ・ソースを編集するには、その名前をクリックします。

3. 新しいデータ・ソースを作成するには、「作成」をクリックし、作成するデータ・ソースのタイプを選択します。

4. 「データソース・プロパティ」ページで、「スコープ」メニューを使用して、データ・ソースのスコープを指定します。

5. 「WebLogicドメイン」メニューから、「環境」→「ドメイン・パーティション」を選択します。

6. パーティション名をクリックして、パーティションの属性を編集します。

JDBCシステム・リソース・オーバーライドを作成するには、次の手順を実行します。

1. パーティション名をクリックします。

2. 左側の「ドメイン・パーティション」メニューから、「管理」→「リソース・オーバーライド」を選択します。このページを使用して、リソース・グループ・テンプレートのリソース・タイプおよび名前とともにリソース・グループ・テンプレートから導出されたすべてのリソース・グループを表示します。既存のオーバーライドがない場合、「オーバーライドあり」列は空白になります。

3. 「オーバーライドの編集」アイコンをクリックして、オーバーライドを作成します。「オーバーライドあり」列にチェック・マークがある場合、「オーバーライドの編集」アイコンをクリックして、既存のオーバーライドを更新します。

JDBCデータ・ソースの構成: RESTの例

すべてのJDBC構成およびランタイム情報は、RESTを使用して入手できます。詳細は、『RESTful管理サービスによるOracle WebLogic Serverの管理』を参照してください。

これは、パーティションpartition1のすべてのデータ・ソースを取得する例です。

curl --user weblogic:welcome1 -H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json -X GET \
http://host:7001/management/weblogic/latest/serverRuntime/\
partitionRuntimes/partition1/JDBCPartitionRuntime/JDBCDataSourceRuntimeMBeans

次に、短縮した出力を示します。

{
...
"items": [
{
....
"identity": [
"partitionRuntimes",
"partition1",
"JDBCPartitionRuntime",
"JDBCDataSourceRuntimeMBeans",
"ds-in-template"
],
"connectionsTotalCount": 1,
...
},
{
...
"identity": [
"partitionRuntimes",
"partition1",
"JDBCPartitionRuntime",
"JDBCDataSourceRuntimeMBeans",
"ds-using-template"
],
...
},
{
...
"identity": [
"partitionRuntimes",
"partition1",
"JDBCPartitionRuntime",
"JDBCDataSourceRuntimeMBeans",
"ds"
],
"connectionsTotalCount": 1,
...
}
]
}

次のシェル・スクリプトでは、RESTを使用して、パーティションpartition1のリソース・グループpartition1-rgに、新しいデータ・ソースds3を作成します。

host=myhost
cmd="curl --user weblogic:welcome1 \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-H Content-Type:application/json "
echo "Start a config txn"
${cmd} -d '{}' \
-X POST \
http://${host}:7001/management/weblogic/latest/edit/changeManager/startEdit

echo "\nCreate the JDBCSystemResource - note - can't save the changes yet"
echo "because we still need to set its JDBCResource's name too."
${cmd} -d "{
name: 'ds3'
}" -X POST \
http://${host}:7001/management/weblogic/\
latest/edit/partitions/partition1/\
resourceGroups/partition1-rg/JDBCSystemResources?saveChanges=false
echo "\nSet the JDBCSystemResource's JDBCResource's name and let the changes be"
echo "saved automatically."
${cmd} -d "{
name: 'ds3'
}" -X POST \
http://${host}:7001/management/weblogic/latest/\
edit/partitions/partition1/resourceGroups/partition1-rg/\
JDBCSystemResources/ds3/JDBCResource
echo "\nSet the Data Source Params"
${cmd} -d "{
globalTransactionsProtocol: 'EmulateTwoPhaseCommit',
JNDINames: [ 'ds3' ]
}" -X POST \
http://${host}:7001/management/weblogic/latest/\
edit/partitions/partition1/resourceGroups/partition1-rg/\
JDBCSystemResources/ds3/JDBCResource/JDBCDataSourceParams
echo "\nSet the Driver Params"
${cmd} -d "{
driverName: 'oracle.jdbc.OracleDriver',
password: 'MYPASSWD',
url: 'jdbc:oracle:thin:@dbhost:1521/otrade'
}" -X POST \
http://${host}:7001/management/weblogic/latest/\
edit/partitions/partition1/resourceGroups/partition1-rg/\
JDBCSystemResources/ds3/JDBCResource/JDBCDriverParams
echo "\nSet the Properties Params"
${cmd} -d "{
value: 'dbuser',
name: 'user'
}" -X POST \
http://${host}:7001/management/weblogic/latest/\
edit/partitions/partition1/resourceGroups/partition1-rg/\
JDBCSystemResources/ds3/JDBCResource/JDBCDriverParams/properties/properties
echo "\nActivate the changes"
${cmd} -d '{}' \
-X POST \
http://${host}:7001/management/weblogic/latest/edit/changeManager/activate

JDBCデータ・ソースの構成: 関連タスクおよびリンク

次の追加情報を参照してください。

- 『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Server JDBCデータ・ソースに関する項

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデータ・ソースの構成に関する項。

- RESTを使用したJDBCシステム・リソースの構成の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のシステム・リソースの構成に関する項およびパーティション・スコープのシステム・リソースの作成に関する項を参照してください。

15 メッセージングの構成

この章では、Oracle WebLogic Server Multitenant (MT)でメッセージングがどのようにサポートされているか、および次の事項について説明します。

- 永続ストア(ファイルおよびJDBCストア)

- JMSサーバー

- ストア・アンド・フォワード(SAF)エージェント

- パス・サービス

- メッセージング・ブリッジ

- JMSシステム・モジュールおよびJMSアプリケーション・モジュール

- JMS接続プール

また、この章では、同じWebLogic Serverインスタンスまたはクラスタの他のパーティション、およびリモート・クライアントJVMまたはリモート・サーバーJVMから、パーティション化されたJMSリソースにアクセスする方法についても説明します。

この章の内容は次のとおりです。

- メッセージングの構成: 前提条件

- メッセージング構成のスコープについて

- 構成検証およびターゲット指定のルールについて

- メッセージング・コンポーネントの構成

- パーティション固有のJMSオーバーライドの構成

- JNDIを使用したパーティション・スコープのメッセージング・リソースへのアクセス

- JMSでのパーティション関連付けについて

- パーティション・スコープのメッセージング・コンポーネントの管理

- メッセージングの構成: ベスト・プラクティス

- メッセージングの構成: 制限事項

- メッセージング・リソース・グループの移行

メッセージングの構成: 前提条件

マルチテナント環境でJMSを構成する前に、次について熟知し、それらをすでに作成していることを前提としています。

- 仮想ターゲット。詳細は、「仮想ターゲットの構成」を参照してください。

- ドメイン・パーティション。詳細は、「ドメイン・パーティションの構成」を参照してください。

- パーティションに固有のセキュリティ・レルム(必要な場合)。詳細は、セキュリティの構成を参照してください。

- リソース・グループ・テンプレート(必要な場合)。詳細は、「リソース・グループ・テンプレートの構成」を参照してください。

- リソース・グループ。詳細は、「リソース・グループの構成」を参照してください。

この章では、既存のWebLogic Serverメッセージング構成を熟知していることを前提としています。詳細は、次を参照してください。

- Oracle WebLogic Server JMSリソースの管理

- WebLogic永続ストアの管理

- Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理

- Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理

- Oracle WebLogic ServerメッセージドリブンBeanの開発

メッセージング構成のスコープについて

非パーティション環境でWebLogic Serverを操作する場合、ドメイン・レベルでJMSアーティファクトを構成およびデプロイできます。JMSアーティファクトの例には、永続ストア(ファイルまたはJDBCストア)、JMSサーバー、ストア・アンド・フォワード・エージェント、パス・サービスおよびメッセージング・ブリッジが含まれ、これらは、PersistentStoreMBean、JMSServerMBean、SAFAgentMBean、PathServiceMBean、MessagingBridgeMBeanなどのJMX MBeanを使用して、WebLogic Serverドメインのconfig.xmlファイルで直接構成されます。

また、接続ファクトリや宛先などのJMSリソースは、JMSモジュールと呼ばれる外部ディスクリプタ・ファイルで構成されます。JMSモジュールは、最もよくJMSシステム・リソースとして構成されます(JMSSystemResourceMBeanを使用)。一般的ではありませんが、JMSモジュールは、デプロイ済アプリケーションに含まれるスタンドアロンまたはアプリケーション・スコープのXMLファイル(それぞれスタンドアロン・モジュールおよびアプリケーション・スコープのモジュールと呼ばれる)として、またはJava EE 7接続ファクトリおよび宛先注釈(アプリケーション・スコープのモジュールで定義された外部リソースと同じ基本的なセマンティクスを持つ)によって間接的に、組み込むことができます。

WebLogic Server MTで作業する場合、前述のすべてのJMSアーティファクトは、次のスコープで定義およびデプロイできます。

- ドメイン・スコープ: 非パーティションWebLogic Server環境の場合とまったく同じ構成を使用

- リソース・グループ・スコープ: パーティション・レベルまたはドメイン・レベルで作成されたリソース・グループの一部として

- リソース・グループ・テンプレート・スコープ: ドメイン・レベルで作成されたリソース・グループ・テンプレートの一部として

リソース・グループは、オプションで、リソース・グループ・テンプレート・スコープのJMS構成を継承できます。パーティションにつき1つのリソース・グループのみが特定のリソース・グループ・テンプレートを参照でき、同様に、1つのドメイン・レベルのリソース・グループのみがリソース・グループ・テンプレートを参照できます。

まとめると、JMSメッセージング・アーティファクトのドメイン構成の構造は、次のとおりです。

- ドメイン・レベルのJMS構成

- JMS構成を含むドメイン・レベルのリソース・グループ

- JMS構成を含むドメイン・レベルのリソース・グループ・テンプレート

- リソース・グループ・テンプレートに基づいたドメイン・レベルのリソース・グループ

- パーティション:

- JMS構成を含むパーティション・レベルのリソース・グループ

- リソース・グループ・テンプレートに基づいたパーティション・レベルのリソース・グループ

構成検証およびターゲット指定のルールについて

検証およびターゲット指定のルールによって、WebLogic Server MTのJMS構成の分離、自己完結性および管理の容易性が確実化されます。これらのルールは、次の目標を実現するのに役立ちます。

- リソース・グループが、他のリソース・グループまたはドメイン・レベルのリソースで失敗の原因となることなく、独立して停止または移行できる。

- リソース・グループ・テンプレートが、リソース・グループ、ドメイン構成または他のリソース・グループ・テンプレートに直接依存しない、完全にカプセル化され、独立した構成ユニットである。

- リソース・グループが単一のサーバーをターゲットとしているか、クラスタをターゲットとしているか、ターゲットがないかに関係なく、同じ構成が有効である。

- 以前のリリースで有効だったドメイン・レベルの構成の動作に変更がない。たとえば、非リソース・グループまたはリソース・グループ・テンプレートのドメイン・レベルの動作は、下位互換性のために変更されません。

これらの目標の実現に役立つ基本的で高レベルのルールとして、JMS構成MBeanは、同じスコープにある別の構成MBeanのみを参照できるというものがあります。たとえば、リソース・グループ・テンプレートで定義されたJMSサーバーは、同じリソース・グループ・テンプレートで定義されたストアのみを参照できます。これらのルールは、構成検証チェック、および実行時に記録されるエラーと警告によって施行されます。

メッセージング・コンポーネントの構成

次の各項では、マルチテナント環境でJMSアーティファクトを構成する際の考慮事項について説明します。

JDBCまたはファイル永続ストアの構成

JMSサーバー、SAFエージェントまたはパス・サービスを構成する前に、永続ストアを作成する手順が必要です。これは、リソース・グループおよびリソース・グループ・テンプレート・スコープのJMSサーバー、SAFエージェントおよびパス・サービスは、既存の永続ストアを参照する必要があるためです。

ドメインまたはパーティションにスコープされたリソース・グループ内のカスタム・ファイルまたはJDBC永続ストアの作成は、ドメイン・レベルの永続ストアの作成と似ています。ただし、追加の手順として、スコープを指定する必要があります。Oracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、永続ストアの作成に使用できるスコープがリストされます。WebLogic Scripting Tool (WLST)を使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreatePersistentStoreコマンドを使用することにより永続ストアを作成する必要があります。

次の分散ポリシーおよび移行ポリシー・ルールは、すべてのリソース・グループおよびリソース・グループ・テンプレート・スコープの永続ストアに適用されます。

- JMSサーバー分散宛先またはSAFエージェント・インポート済宛先をホストするために使用されるリソース・グループまたはリソース・グループ・テンプレート・スコープのストアは、Distributed分散ポリシー(デフォルト)を指定する必要があります。この設定により、クラスタ内のWebLogic Serverインスタンスごとにストア・インスタンスがインスタンス化されます。さらに、Distributed分散ポリシーが指定されたリソース・グループまたはリソース・グループ・テンプレート・スコープのストアは、オプションで、On-failureまたはAlways移行ポリシーで構成できます。

- パス・サービスによって使用される、またはJMSサーバー・スタンドアロン(非分散)宛先をホストするために使用される、リソース・グループまたはリソース・グループ・テンプレート・スコープのストアは、Singleton分散ポリシーを指定する必要があります。この設定により、クラスタ内の単一のストア・インスタンスがインスタンス化されます。さらに、Singleton分散ポリシーが指定されたリソース・グループまたはリソース・グループ・テンプレート・スコープのストアには、移行ポリシーとしてOffではなくOn-failureまたはAlwaysを指定する必要があります。デフォルトはOffです。

- On-failureまたはAlways移行ポリシーが指定された、クラスタをターゲットとするストアでは、クラスタがデータベース・リーシングまたはクラスタ・リーシングのいずれかで構成される必要があり、この場合はデータベース・リーシングがベスト・プラクティスとして推奨されます。

これらのポリシーは、クラスタをターゲット指定するストアおよびJMSアーティファクトの分散および高可用性の動作を制御します。詳細は、『Oracle WebLogic Server JMSリソースの管理』の簡素化されたJMSクラスタおよび高可用性の構成に関する項を参照してください。

ファイルとJDBCストアの両方に施行された構成検証およびターゲット指定のルールを次に示します。

- リソース・グループまたはリソース・グループ・テンプレート・レベルのJMSサーバー、SAFエージェントまたはパス・サービスは、構成されたストアを参照する必要があります。これらはnullを参照できません。

- リソース・グループ・テンプレート・スコープのJMSサーバー、SAFエージェントまたはパス・サービスは、同じリソース・グループ・テンプレートで定義されたストアのみを参照できます。子リソース・グループ・レベルで定義されたストアを参照できません。

- リソース・グループ・スコープのJMSサーバー、SAFエージェントまたはパス・サービスは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートで定義されたストアのみを参照できます。

- ドメイン・レベルのJMSサーバー、SAFエージェントまたはパス・サービスは、ドメイン・スコープのストアのみを参照できます。

JDBCストアに固有の追加のルールを次に示します。

- リソース・グループ・テンプレート・スコープのJDBCストアは、同じリソース・グループ・テンプレートにあるデータ・ソースのみを参照できます。

- リソース・グループ・スコープのJDBCストアは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートにあるデータ・ソースのみを参照できます。

- ドメイン・スコープのJDBCストアは、ドメイン・スコープのデータ・ソースのみを参照できます。

JMSサーバーの構成

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたJMSサーバーの作成は、ドメイン・レベルでのJMSサーバーの作成と似ています。追加の手順は、スコープを指定することです。WebLogic Server管理コンソールおよびFusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、JMSサーバーの作成に使用できるスコープがリストされます。WLSTを使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateJMSServerコマンドを使用することによりJMSサーバーを作成する必要があります。

他に必要な手順は、JMSサーバーと同じスコープで構成された永続ストアを参照するように、JMSサーバーを構成することです。

最後に、JMSサーバーが分散宛先をホストするために使用される場合、そのストアはDistributed分散ポリシーで構成される必要があります。JMSサーバーがスタンドアロン(非分散)宛先をホストする場合、ストアはSingleton分散ポリシーで構成される必要があります。

ストア・アンド・フォワード・エージェントの構成

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたストア・アンド・フォワード(SAF)エージェントの作成は、ドメイン・レベルでのSAFエージェントの作成と似ています。追加の手順は、スコープを指定することです。WebLogic Server管理コンソールおよびFusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、SAFエージェントの作成に使用できるスコープがリストされます。WLSTを使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateSAFAgentコマンドを使用することによりSAFエージェントを作成する必要があります。

他に必要な手順は、SAFエージェントと同じスコープで構成された永続ストアを参照するように、SAFエージェントを構成することです。このストアは、Distributed分散ポリシー(デフォルト)で構成される必要があります。

注意:

サービス・タイプがReceiving Onlyのリソース・グループまたはリソース・グループ・テンプレート・レベルのSAFエージェントは、許可されません。このような構成を設定しようとすると、例外がスローされるか、エラー・メッセージが記録されます。このモードは、古い形式のJAX-RPC Webサービスの信頼性のあるメッセージングに固有のものです。かわりに、JAX-WS RMを使用します。

分散宛先による順序単位の使用をサポートするパス・サービスの構成

リソース・グループまたはリソース・グループ・テンプレートが、順序単位(UOO)メッセージをホストするために使用される分散宛先も構成する場合、パス・サービスは、リソース・グループまたはリソース・グループ・テンプレートで構成する必要があります。また、ハッシュ・ベースのUOOルーティングがリソース・グループまたはリソース・グループ・テンプレート・スコープでサポートされていないため、このような分散宛先は、HashではなくPathServiceに設定された順序単位ルーティング・ポリシーで構成される必要があります。リソース・グループまたはリソース・グループ・テンプレート・スコープの分散宛先は、ルーティングUOOメッセージの同じリソース・グループまたはリソース・グループ・テンプレートで構成されたパス・サービスのみを使用します。PathService順序単位ルーティング・ポリシーを構成しないリソース・グループまたはリソース・グループ・テンプレート・スコープの分散宛先にメッセージを送信しようとすると、例外で失敗します。

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたパス・サービスの作成は、ドメイン・レベルでのパス・サービスの作成と似ています。追加の手順は、スコープを指定することです。WebLogic Server管理コンソールおよびFusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、パス・サービスの作成に使用できるスコープがリストされます。WLSTを使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreatePathServiceコマンドを使用することによりパス・サービスを作成する必要があります。

他に必要な手順は、パス・サービスと同じスコープで構成された永続ストアを参照するように、パス・サービスを構成することです。このストアは、Singleton分散ポリシーおよびAlwaysまたはOn-Failure移行ポリシーで構成される必要があります。

メッセージング・ブリッジの構成

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたメッセージング・ブリッジの作成は、ドメイン・レベルでのメッセージング・ブリッジの作成と似ています。追加の手順は、スコープを指定することです。WebLogic Server管理コンソールおよびFusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、メッセージング・ブリッジの作成に使用できるスコープがリストされます。WLSTを使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateMessagingBridgeコマンドを使用することによりメッセージング・ブリッジを作成する必要があります。

次の分散ポリシーおよび移行ポリシー・ルールは、すべてのリソース・グループまたはリソース・グループ・テンプレート・スコープのメッセージング・ブリッジに適用されます。

- ブリッジでDistributed分散ポリシー(デフォルト)を指定して、クラスタをターゲットとするブリッジがクラスタ内のサーバーごとにインスタンスをデプロイするようにします。Distributed分散ポリシーが指定されたメッセージング・ブリッジは、オプションでOn-failure移行ポリシーを構成して、高可用性のサポートを追加することもできます。

- ブリッジでSingleton分散ポリシーを指定して、クラスタをターゲットとするブリッジがクラスタごとに1つのインスタンスをデプロイするように制限します。Singleton分散ポリシーが指定されたメッセージング・ブリッジには、OffではなくOn-failure移行ポリシーを指定する必要があります。デフォルトはOffです。

- On-failure移行ポリシーが指定された、クラスタをターゲットとするブリッジでは、クラスタがデータベース・リーシングまたはクラスタ・リーシングのいずれかで構成される必要があり、この場合はベスト・プラクティスとしてデータベース・リーシングが推奨されます。

これらのポリシーは、クラスタをターゲット指定するメッセージング・ブリッジの高可用性の動作および分散動作を制御します。分散および移行ポリシーの詳細は、『Oracle WebLogic Server JMSリソースの管理』の簡素化されたJMSクラスタおよび高可用性の構成に関する項を参照してください。

メッセージング・ブリッジに固有の構成検証ルールを次に示します。

- リソース・グループ・テンプレート・スコープのメッセージング・ブリッジは、同じスコープのメッセージング・ブリッジ宛先のみを参照できます。

- リソース・グループ・スコープのメッセージング・ブリッジは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートにあるメッセージング・ブリッジ宛先のみを参照できます。

- ドメイン・スコープのメッセージング・ブリッジは、ドメイン・スコープのメッセージング・ブリッジ宛先のみを参照できます。

JMSシステム・リソースおよびアプリケーション・スコープのJMSモジュールの構成

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたJMSシステム・リソースの作成は、ドメイン・レベルでのJMSシステム・リソースの作成と似ています。追加の手順は、スコープを指定することです。WebLogic Server管理コンソールおよびFusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、JMSシステム・リソースの作成に使用できるスコープがリストされます。WLSTを使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateJMSSystemResourceコマンドを使用することによりJMSシステム・リソースを作成する必要があります。

ドメイン・レベルのリソース・グループ・スコープを持つ、またはパーティション内にあるアプリケーション・スコープのJMSモジュールの作成は、ドメイン・レベルでの作成と似ています。アプリケーション・デプロイメントには、JMSモジュール・ファイル、またはJMSモジュール・ファイルを含むアプリケーションEARファイルを含めることができます。追加の手順は、リソース・グループまたはリソース・グループ・テンプレート・スコープを指定することです。詳細は、「アプリケーションのデプロイ」を参照してください。

注意:

同じ構成編集セッション内で、JMSサーバーを作成し、サブモジュール・ターゲットを指定するアプリケーションをこのJMSサーバーにデプロイする処理をすべて行う場合、デプロイメントは成功しない可能性があります。JMSサーバーを個別の編集セッションに構成することをお薦めします。

注意:

アプリケーション・リソース・モジュールに構成を組み込むのではなく、システム・リソース・モジュールを使用してJMSを構成することを強くお薦めします。アプリケーション・スコープの構成とは異なり、システム・リソース構成は、管理者または開発者が、WebLogic Server管理コンソール、WLSTまたはMBeanを使用して、動的に調整し、簡単にモニターできます。

リソース・グループまたはリソース・グループ・テンプレート・スコープのJMSモジュールに属するリソースに関連する、構成検証およびターゲット指定のルールを次に示します。

サブデプロイメントの定義

- リソース・グループまたはリソース・グループ・テンプレート・スコープのサブデプロイメントのターゲットとしては、なし(null)、単一のJMSサーバー、または単一のSAFエージェントのみを指定できます。

- リソース・グループ・テンプレート・スコープのサブデプロイメントは、同じリソース・グループ・テンプレートで定義されたJMSサーバーまたはSAFエージェントのみを参照できます。

- リソース・グループ・スコープのサブデプロイメントは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートで定義されたJMSサーバーまたはSAFエージェントのみを参照できます。

JMSモジュールのリソース

次の表は、JMSモジュールのリソース・タイプのターゲット指定のルールを示しています。

リソース・タイプ

サブデプロイメントの使用

デフォルトのターゲット指定の使用

スタンドアロン(シングルトン)宛先

Singleton分散ポリシーが指定されたストアを参照するJMSサーバーのターゲットを指定するサブデプロイメントに対してのみ、ターゲットを指定できます。

Singleton分散ポリシー・ストアを参照する同じリソース・グループまたはリソース・グループ・テンプレート・スコープに構成された単一のJMSサーバーがある場合のみ、デプロイが行われます。この場合、宛先は、この特定のJMSサーバーにデプロイします。Distributed分散ポリシー・ストアを参照するJMSサーバーは無視され、スコープの外部(たとえば、ドメイン・レベルまたは別のリソース・グループまたはリソース・グループ・テンプレート)に定義されたJMSサーバーも無視されます。

共通分散宛先*

Distributed分散ポリシーが指定されたストアを参照するJMSサーバーのターゲットを指定するサブデプロイメントに対してのみ、ターゲットを指定できます。

Distributed分散ポリシー・ストアを参照する同じリソース・グループまたはリソース・グループ・テンプレート・スコープに構成された単一のJMSサーバーがある場合のみ、デプロイが行われます。この場合、宛先は、この特定のJMSサーバーにデプロイします。Singleton分散ポリシー・ストアを参照するJMSサーバーは無視され、スコープの外部(たとえば、ドメイン・レベルまたは別のリソース・グループまたはリソース・グループ・テンプレート)に定義されたJMSサーバーも無視されます。

SAFインポート済宛先

SAFエージェントのターゲットを指定するサブデプロイメントに対してのみ、ターゲットを指定できます。

同じリソース・グループまたはリソース・グループ・テンプレート・スコープに構成された単一のSAFエージェントがある場合のみ、デプロイが行われます。スコープの外部(たとえば、ドメイン・レベルまたは別のリソース・グループまたはリソース・グループ・テンプレート)に定義されたSAFエージェントも無視されます。

接続ファクトリ

サブデプロイメントをターゲット指定できます。

リソース・グループのターゲットに含まれているすべてのWebLogic Serverインスタンスにデプロイします。

外部サーバー

Distributed分散ポリシーが指定されたストアを参照するJMSサーバーのターゲットを指定するサブデプロイメントに対してのみ、ターゲットを指定できます。ベスト・プラクティスとして、かわりにデフォルトのターゲット指定を使用します

リソース・グループのターゲットに含まれているすべてのWebLogic Serverインスタンスにデプロイします。

* 注意: リソース・グループまたはリソース・グループ・テンプレート・スコープの共通分散トピックではPartitioned転送ポリシーを指定する必要があります。たとえば、パーティション化された分散トピック(PDT)である必要があります。PDTの「パーティション化された」という単語は、WebLogic Server MTパーティションの「パーティション」という単語と同じ意味ではないことに注意してください。PDTとWebLogic Server MTのパーティションは、2つの独立した概念です。PDTの使用に対するトレードオフの詳細は、「メッセージングの構成: 制限事項」を参照してください。

パーティション固有のJMSオーバーライドの構成

リソース・グループ・テンプレート・スコープのJMS構成アーティファクトは、リソース・グループ・テンプレートを使用するパーティションに固有の値が不足しているか正しくないため、完全ではない可能性があります。各パーティションには、パーティション・ランタイムへの正しいデプロイメントのテンプレートから導出された値をカスタマイズするために指定された適切なオーバーライド値が必要な可能性があります。パーティション固有でリソース・グループ・スコープのJMS構成は、リソース・デプロイメント・プランまたはアプリケーション・デプロイメント・プランを使用してパーティションごとにカスタマイズできます。また、JMSシステム・モジュール内のJMS外部サーバー構成は、JMSSystemResourceOverrideMBeanを使用してカスタマイズできます。

リソース・オーバーライドによって、システム管理者は、JMSリソースおよびデータ・ソースなどの他のリソースをパーティション・レベルでカスタマイズできます。リソース・グループ・テンプレートを拡張するリソース・グループを含むパーティションを作成する場合は、そのリソース・グループ・テンプレートで定義されている特定のリソースの設定をオーバーライドできます。リソース・グループ・テンプレートを拡張しないリソース・グループをパーティション内に作成し、このリソース・グループ内にリソースを作成する場合、オーバーライドは不要で、これらのリソースにパーティション固有の値を設定します。

オーバーライドは、主にリソースに共通の定義が存在する場合に、リソースを使用する各パーティションがリモートに格納された状態を分離する必要がある、リソース・グループ・テンプレートなどで使用されます。たとえば、同じJMSサーバー、JDBCストア、データ・ソースおよびJMSモジュールの構成は、単一のリソース・グループ・テンプレートで構成し、リソース・グループ・テンプレートを参照する各パーティションでリソース・グループを構成することによって、同じクラスタ内の複数のパーティションにデプロイできます。その後、パーティション・リソース・グループをパーティションごとにオーバーライドして、それぞれのデータ・ソースが異なるデータベースまたは同じデータベース内の異なるスキーマに接続していることを確認できます。

システム管理者は、次の特定の手法を使用して、パーティションのリソース定義をオーバーライドできます。

- リソース・オーバーライド構成MBean: 既存のリソース構成MBeanの属性のサブセットを公開する構成MBean。オーバーライド構成MBeanのインスタンス上の属性セットは、対応するリソース構成MBeanインスタンス内のその属性の値を置き換えます。JMSシステム・モジュールの外部JMSサーバーおよび関連する構成アーティファクトは、オーバーライドMBeanを使用して、ユーザー、パスワードおよびプロバイダURLの設定をオーバーライドできます。オーバーライドMBeanを使用する場合、対応する外部JMSサーバーおよび関連するデプロイメントMBeanごとに個別のオーバーライドMBeanを定義する必要があります。JMSモジュールがすでにデプロイされた後の実行時に行われたこれらの属性への構成変更は、パーティションまたはJVMを再起動して、変更を有効にする必要があります。

- リソース・デプロイメント・プラン: パーティション内で構成された任意のリソースを識別し、それらのリソースの属性設定をオーバーライドするXMLファイル。永続ストア、JMSサーバー、SAFエージェント、メッセージング・ブリッジ、ブリッジ宛先およびパス・サービスは、リソース・デプロイメント・プランのconfig-resource-override要素を使用し、キュー、トピックおよび接続ファクトリなどのJMSシステム・モジュールのJMSリソースは、external-resource-override要素を使用します。

- パーティション固有のアプリケーション・デプロイメント・プラン: 既存のアプリケーション・デプロイメント・プランに似たプラン。管理者は、パーティション内のアプリケーション・デプロイメントごとに、パーティション固有のアプリケーション・デプロイメント・プランを指定できます。パーティション固有のアプリケーション・デプロイメント・プランの詳細は、「パーティション固有のデプロイメント・プランの使用方法」を参照してください。

管理者は、これらのリソース・オーバーライド手法を任意に組み合せることができます。システムでは、次に示す昇順の優先度でこれらが適用されます。

- パーティション固有のアプリケーション・デプロイメント・プランを含む、config.xmlファイルおよび外部ディスクリプタ

- リソース・デプロイメント・プラン

- オーバーライド構成MBean
属性がリソース・デプロイメント・プランおよびオーバーライド構成MBeanの両方で参照される場合、オーバーライド構成MBeanが優先されます。

オーバーライドの詳細は、「リソース・オーバーライドの構成」を参照してください。

JNDIを使用したパーティション・スコープのメッセージング・リソースへのアクセス

パーティションのJMSリソースにアクセスするには、アプリケーションでは、まずパーティションへのJNDI初期コンテキストを確立する必要があります。パーティションのコンテキストを作成すると、コンテキスト・オブジェクトはパーティションのネームスペースに維持され、それ以降のJNDI操作はすべて、そのパーティションのスコープの中で行われます。java.naming.provider.urlプロパティを設定してコンテキストが作成されると、JNDIはパーティションを認識するためにパーティション情報をプロバイダURLの値の中で探します。次の4つの異なるURLタイプは、特定のパーティションにコンテキストを関連付けます。

- URLを指定しない。

- パーティションの仮想ホストまたはURIを指定するURLの使用。

- パーティションの専用ポートを指定するURLの使用。

- 特別なlocal: URLの使用。「local: URLまたは修飾されたJNDI名を使用したローカル・クロス・パーティションのユースケース」を参照してください。

また、JNDI名の接頭辞として特別なスコープ文字列を付加することによって、既存のコンテキストを使用して別のパーティションのリソースを参照できます。

これらの各方法については、次の各項で説明します。

URLを指定しない

プロバイダURLを指定せずにローカル初期コンテキストを作成するだけで、WebLogic Serverインスタンス上のパーティションで実行中のアプリケーションは、独自のローカル・パーティションのJMSリソースにアクセスできます。この方法は、ローカルにスコープされたコンテキストを作成するためのベスト・プラクティスです。

パーティション仮想ホストまたはパーティションURIの指定

コンテキストURLがパーティションに構成された仮想ホストURLまたはURIと一致する場合、JNDIはそのパーティションのコンテキストを作成し、コンテキストからのすべてのリクエストは、パーティションのJNDIネームスペースに委任されます。

したがって、JMSアプリケーションでは、次の形式のURLを指定することによって、t3またはHTTPプロトコルを使用する別のJVMまたはWebLogic Serverクラスタで実行されているWebLogic Server JMSリソースにアクセスできます。

- t3://virtualhost:port

- t3://host:port/URI

注意:

URIにスペルミスがあるかURIが存在しないと、コンテキストはドメイン・レベルにスコープされ、警告はありません。

専用ポートURLの指定

特定のポートまたはアドレスをパーティション内のチャネル専用にすることが可能で、この場合、URL形式はt3://host:portになります。

これは、リリース12.2.1より前のクライアントをパーティション・スコープのリソースと相互運用するためにサポートされている唯一の方法です。

詳細は、「仮想ターゲットの構成」を参照してください。

注意:

この方法を以前のリリースとの相互運用性のために使用する場合、SSLは現在サポートされていません。

local: URLまたは修飾されたJNDI名を使用したローカル・クロス・パーティションのユースケース

あるパーティションのアプリケーションは、前の項で説明したURLのいずれかを使用して、同じWebLogic Serverインスタンスまたは同じクラスタの別のパーティションにアクセスできます。

ただし、特定のホスト、ポートまたはURIを指定する必要なく、同じサーバーに存在するパーティション間のより効率的なアクセスをサポートするために、アプリケーションには次のオプションがあります。

- local:プロトコルURLを指定したコンテキストを作成します。

- local:// - コンテキストを現在のパーティション上に作成します(パーティションまたはドメインのいずれか)。

- local://?partitionName=DOMAIN - コンテキストをドメイン上に作成します。

- local://?partitionName=partition_name - コンテキストをパーティションpartition_name上に作成します。

- URLを指定せずにコンテキストを作成し、JNDI名を指定する際に明示的なスコープを接頭辞として付けます。

- domain:<JNDIName> - ドメイン・レベルのJNDIエントリをルックアップします。

- partition:<partition_name>/<JNDIName> - 指定したパーティションのJNDIエントリをルックアップします。

JMSでのパーティション関連付けについて

次の各項では、様々なJMSパーティション関連付けについて説明します。

接続ファクトリとその接続またはJMSコンテキストとの間のパーティション関連付け

JMSクライアント接続およびJMSコンテキストは、その接続ファクトリが取得されたパーティションに永久に関連付けられ、現在のスレッドに関連付けられたパーティションに基づいてパーティションを変更しません。

非同期コールバックとのパーティション関連付け

JMSがメッセージまたは例外を非同期リスナーにプッシュするか、同様にイベントを宛先可用性リスナーまたは非同期送信完了リスナーにプッシュすると、リスナーのローカル・パーティションID (宛先のパーティションではない)がコールバック・スレッドに関連付けられます。ローカル・パーティションIDは、非同期リスナーを作成したスレッドに関連付けられたパーティションです。

一致するスコープが必要な接続ファクトリおよび宛先

接続ファクトリは、接続ファクトリと同じパーティションに定義された宛先とのみ相互作用できます。たとえば、QueueBrowser、MessageConsumer/JMSConsumer、TopicSubscriberまたはMessageProducer/JMSProducerクライアント・オブジェクトは、これらのクライアント・オブジェクトの作成に使用された接続ファクトリが宛先と同じパーティションに定義された場合にのみ、宛先と通信できます。さらに、接続ファクトリは、接続ファクトリと同じクラスタまたはサーバーJVMから取得された宛先とのみ相互作用できます。

一時宛先のスコープ

12.2.1リリースより前は、JMSサーバーはドメイン・レベルでのみデプロイされ、一時宛先は、次の両方を満たすJMSサーバーによってのみホストされました。

- Hosting Temporary Destinationsがtrue (デフォルト)に設定されている。

- 一時宛先の作成に使用された接続ファクトリと同じWebLogic Serverインスタンスまたは同じクラスタでホストされている。

WebLogic Server MTで一時宛先を作成する動作は、次のとおりです。

- 非MT WebLogic Serverの場合のように、Hosting Temporary Destinationsが有効で、一時宛先の作成に使用される接続ファクトリと同じWebLogic Serverインスタンスまたは同じクラスタでホストされるJMSサーバーによってのみ、一時宛先をホストできます。

- リソース・グループまたはリソース・グループ・テンプレート・スコープ(ドメイン・リソース・グループなど)で構成された接続ファクトリを使用してJMS接続が作成された場合、一時宛先は、同じスコープで構成されたJMSサーバーによってのみホストされます。

- 非リソース・グループまたはリソース・グループ・テンプレート・スコープのパーティション・レベルの接続ファクトリを使用してJMS接続が作成された場合、接続ファクトリと同じパーティションのJMSサーバーで一時宛先を作成できます。非リソース・グループまたはリソース・グループ・テンプレート・スコープのパーティション・レベルの接続ファクトリは、単にデフォルトの接続ファクトリで、たとえばJNDI名がweblogic.jms.ConnectionFactoryやweblogic.jms.XAConnectionFactoryの接続ファクトリです。

- 非リソース・グループまたはリソース・グループ・テンプレート・スコープのドメイン・レベルの接続ファクトリを使用してJMS接続が作成された場合、ドメイン・レベルのJMSサーバー(ドメイン・レベルのリソース・グループにスコープされたJMSサーバーなど)で一時宛先を作成できます。

許可されたスコープ内に修飾されたJMSサーバーが見つからない場合、一時宛先を作成しようとすると、例外が返されます。

パーティション・スコープのメッセージング・コンポーネントの管理

次の各項では、パーティション・スコープのメッセージングの特定の状況の管理について説明します。

ランタイム・モニタリングおよびランタイム・コントロール

既存のすべてのメッセージング・ランタイムMBeanは、パーティション・スコープのJMS構成およびデプロイメントのモニタリングおよび制御でサポートされ、JMXベースの管理クライアントからアクセスできます。パーティション・スコープのJMSランタイムMBeanは、対応するParititionRuntimeMBeanインスタンスの下にあります。

次に例を示します。

- JMSServer、ConnectionおよびPooledConnectionランタイムMBeanは、serverRuntime/PartitionRuntimes/partition/JMSRuntimeの下のランタイムMBean階層にあります。

- SAFランタイムMBeanは、serverRuntime/PartitionRuntimes/partition/SAFRuntimeMBeanの下のランタイムMBean階層にあります

- メッセージング・ブリッジおよびパス・サービス・ランタイムMBeanは、serverRuntime/PartitionRuntimes/partitionの直下のランタイムMBean階層にあります

詳細は、「パーティションのモニタリングおよびデバッグ」を参照してください。

パーティション・スコープのセキュリティの管理

パーティション・メッセージング構成に関連するセキュリティ・ロールおよびポリシー定義は、WebLogic Serverシステム管理者が担当します。

WebLogic Server MTでは、従来のWebLogic Serverセキュリティ・サポートを次の2つの重要な方法で拡張しています。

- 複数のレルム: WebLogic Server MTでは、複数のアクティブなセキュリティ・レルムがサポートされており、各パーティションを異なるレルムで実行できます。

- アイデンティティ・ドメイン: アイデンティティ・ドメインは、ユーザーおよびグループの論理ネームスペースであり、通常は、物理データ・ストア内のユーザーとグループの1つの個別セットを表します。アイデンティティ・ドメインを使用して、特定のパーティションに関連付けられているユーザーを識別します。

その他の点では、パーティション・スコープのメッセージングのセキュリティの構成は、ドメイン・レベルのメッセージングのセキュリティの設定と似ています。詳細は、セキュリティの構成を参照してください。

トランザクションの管理

JVMのすべてのJTAトランザクションは、スコープに関係なく、単一のJTAトランザクション・マネージャによって処理されます。パーティション・スコープのXAリソース・マネージャ名は、パーティション名で自動的に修飾され、リソース・マネージャがトランザクション・マネージャに対して一意に識別され、独立して管理されるようにします。リソース・マネージャの1つの例として、永続ストアがあります。

トランザクション構成および制限の詳細は、「トランザクションの構成」を参照してください。

パーティションおよびリソース・グループのライフサイクル操作の管理

パーティションまたはリソース・グループに関連付けられたJMSアーティファクトは、そのパーティションまたはリソース・グループを起動および停止することによって起動および停止できます。これらの操作を実行する権限は、WebLogic Serverシステム管理者およびオペレータに自動的に提供されます。

パーティション・スコープのJMS診断イメージのソース

メッセージング・コンポーネントは、診断イメージをパーティションにスコープする機能をサポートしていません。詳細は、「パーティション・スコープの診断イメージ・キャプチャの構成」を参照してください。

パーティション・スコープのJMSロギング

ドメイン・ログ・フォーマットが構成されていない場合、パーティション・スコープのJMSログ・メッセージは、パーティションIDと名前で修飾されます。ロギングの詳細は、「パーティションのモニタリングおよびデバッグ」を参照してください。

メッセージ・ライフサイクル・ロギング

オプションで有効化されたJMSサーバーおよびSAFエージェント・メッセージ・ライフサイクル・ロギングは、これらのサービスがパーティションにスコープされた場合と異なる場所に配置されます。ロギング・ファイルは、そのパーティションのディレクトリにあります。さらに、クラスタをターゲットとするJMSサーバーまたはSAFエージェントの、異なるランタイムJMSサーバーおよびSAFエージェント・インスタンスのログ・ファイル名は、1つの解釈で置き換えられることが保証されます。

絶対パス、相対パスまたはデフォルトを構成する場合に予期される新しいログの場所を、次にまとめます。

スコープ

構成なし(デフォルト)

/<absolute-path>/<file>

/<relative-path>/<file>

ドメイン・レベル

<domain-log>/<log-suffix>/<instance>-jms.messages.log

/<absolute-path>/<instance>-<file>

<domain-log>/<relative-path>/<instance>-<file>

パーティション

<partition-log>/<log-suffix>/<instance>-jms.messages.log

<relative-path>*と同じ

<partition-log>/<relative-path>/<instance>-<file>

* 注意: パーティション・スコープの構成は、絶対パスを相対パスとして処理します。

<domain-log> = <domain>/servers/<wl-server-name>

<partition-log> = <domain>/partitions/<partition-name>/system/servers/<wl-server-name>

<log-suffix> = logs/jmsservers/<configured-name> (JMSサーバーの場合)

<log-suffix> = logs/safagents/<configured-name> (SAFエージェントの場合)

<instance> =

- <configured-name> (JMSサーバーまたはSAFエージェントが単一のサーバーをターゲットとする場合)

- <configured-name>_<wl-server-name> (クラスタをターゲットとし、データ・ストアの分散ポリシーがDistributedの場合)
(あるWebLogic Serverインスタンスから別のWebLogic Serverインスタンスに移行しても、インスタンスは古い名前を保持することに注意してください。)

- <configured-name>_01 (クラスタをターゲットとし、データ・ストアの分散ポリシーがSingletonの場合)

管理ヘルパー

JMSリソースを構成およびモニターするためのヘルパー・メソッドを提供するJMS固有のJava管理プログラミング・ユーティリティが2つあります。

JMSModuleHelperユーティリティには、(モニターする) JMSランタイムMBeanを検索するヘルパー・メソッド、および特定のモジュールでJMSモジュール構成エンティティ(ディスクリプタBean)を管理(検索/作成/削除)するメソッドが含まれています。

JMSRuntimeHelperユーティリティは、接続、宛先、セッション、メッセージ・プロデューサまたはメッセージ・コンシューマなどのJMSオブジェクトが指定された、対応するJMXランタイムMBeanを取得するための便利なメソッドを提供します。

リリース12.2.1には、ドメイン・スコープのJMSリソースとリソース・グループまたはリソース・グループ・テンプレート・スコープのJMSリソースの両方を処理するための拡張バージョンのヘルパーが備えられています。

既存のJMSRuntimeHelperユーティリティは、パーティション対応になるように拡張されています。ランタイム・ヘルパー・メソッドを呼び出す際には、指定したJNDIコンテキストと指定したJMSオブジェクトが同じパーティションに属している必要があります(それ以外の場合、例外がスローされます)。

拡張されたJMSModuleHelperユーティリティは、スコープ対応で、次のインタフェースおよびクラスが含まれています。

- weblogic.jms.extensions.IJMSModuleHelper - すべてのヘルパー・メソッドを定義するインタフェース。

- weblogic.jms.extensions.JMSModuleHelper - リリース12.2.1より前のバージョンのJMSモジュール・ヘルパー。これはドメイン・レベルのJMSリソースのみを処理します。

- weblogic.jms.extensions.JMSModuleHelperFactory - 管理サーバーへの初期コンテキスト、スコープ・タイプ(ドメイン、リソース・グループまたはリソース・グループ・テンプレート)、およびスコープの名前が指定された特定のスコープで機能するJMSモジュール・ヘルパーのインスタンスを作成するファクトリ。

次のコードは、3つの異なるスコープごとにJMSモジュール・ヘルパーを作成する方法を示しています。

Context ctx = getContext(); // get an initial JNDI context

JMSModuleHelperFactory factory = new JMSModuleHelperFactory();

// create a JMS module helper for domain level

IJMSModuleHelper domainHelper = factory.getHelper(ctx, IJMSModuleHelper.ScopeType.DOMAIN, null);

// create a JMS module helper for Resource Group "MyResourceGroup"

IJMSModuleHelper rgHelper = factory.getHelper(ctx, IJMSModuleHelper.ScopeType.RG, "MyResourceGroup");

// create a JMS module helper for Resource Group Template "MyResourceGroupTemplate"

IJMSModuleHelper rgtHelper = factory.getHelper(ctx, IJMSModuleHelper.ScopeType.RGT, "MyResourceGroupTemplate");

JMSモジュール・ヘルパー・インスタンスが作成されると、それを使用して、対応するスコープにスコープされたJMSリソースを作成できます。たとえば、次のコード例では、リソース・グループMyResourceGroupのJMSサーバーMyJMSServerにJMSキューを使用したJMSシステム・リソースを作成しています。(JMSサーバーおよびリソース・グループはすでに作成されていることを前提としています。)

String jmsServer = "MyJMSServer";

String jmsSystemModule = "MyJMSSystemModule";

String queue = "MyQueue";

String queueJNDI = "jms/myQueue";

rgHelper.createJMSSystemResource(jmsSystemModule, null);

rgHelper.createQueue(jmsSystemModule, jmsServer, queue, queueJNDI, null);

ファイルの場所

永続ストアは、様々な目的のためにファイル・システムに多数のファイルを作成します。これらのファイルには、ファイル・ストア・データ・ファイル、ファイル・ストア・キャッシュ・ファイル(DirectWriteWithCache同期書込みポリシーが指定されたファイル・ストア用)、およびJMSサーバーとSAFエージェントのページング・ファイルがあります。

リリース12.2.1より前のファイルの場所の動作は、ドメイン・スコープの永続ストアの場合と同じままです。これにより、永続データがアップグレード後にリカバリされ、予期された場所に格納されます。パーティション・スコープの構成では、異なるパーティションの同じ名前のストア間のファイルの衝突を防ぐために、これらのファイルは、パーティション・ファイル・システム内の分離したディレクトリに配置されます。

次に、WebLogic Server MTのファイル・ストア・システムで使用される様々なファイルの場所のサマリーを示します。partitionStem = partitions/<partitionName>/systemです。

ストア・タイプ

構成されないストア・パス

相対ストア・パス

絶対ストア・パス

ファイル名

custom file

<domainRoot>/<partitionStem>/store/<storeName>

<domainRoot>/<partitionStem>/store/<relativePath>/<storeName>

<absolutePath>/<partitionStem>/store/<storeName>

<storeName>NNNNNN.DAT

cache

${java.io.tmpdir}/WLStoreCache/${domainName}/<partitionStem>/tmp

<domainRoot>/<partitionStem>/<tmp>/<relativePath>

<absolutePath>/<partitionStem>/tmp

<storeName>NNNNNN.CACHE

ejb timers

<domainRoot>/<partitionStem>/store/_WLS_EJBTIMER_<serverName>

<domainRoot>/<partitionStem>/store/<relativePath>/_WLS_EJBTIMER_<serverName>

<absolutePath>/<partitionStem>/store/_WLS_EJBTIMER_<serverName>

_WLS_EJBTIMER_<serverName>NNNNNN.dat

paging

<domainRoot>/<partitionStem>/paging

<domainRoot>/<partitionStem>/paging/<relativePath>

<absolutePath>/<partitionStem>/paging

<jmsServerName>NNNNNN.TMP

<safAgentName>NNNNNN.TMP

次に、前述の各ストア・タイプがディレクトリの場所を構成する方法のサマリーを示します。

ストア・タイプ

ディレクトリ構成

custom file

ファイル・ストアに構成されたディレクトリ。

cache

DirectWriteWithCache同期書込みポリシーを持つファイル・ストアに構成されたキャッシュ・ディレクトリ。

デフォルトEJBタイマー・ストア

WebLogic Serverデフォルト・ストアの構成に構成されたディレクトリ。(パーティションEJBタイマー・デフォルト・ストアは、デフォルト・ストアから構成をコピーします。)

paging

SAFエージェントまたはJMSサーバーに構成されたページング・ディレクトリ。

メッセージングの構成: ベスト・プラクティス

この項では、MT環境のJMS初級ユーザーとJMS上級ユーザーのためのアドバイスおよびベスト・プラクティスを示します。

- MT関連の既知の問題については、『Oracle WebLogic Serverリリース・ノート』の構成の問題および回避策に関する項をすべてのユーザーが確認することをお薦めします。

- なんらかの理由で、新しく作成または更新されたJMSリソースが、実行中のパーティションでアクセスできない場合は、WebLogic Serverログ・ファイルで警告およびエラー・ログ・メッセージがないか確認してください。サーバー・ログ・メッセージに役立つ情報がない場合、パーティションを再起動すると、問題が解決することがよくあります。新しく作成されたパーティションは、いずれかのリソースが外部的にアクセス可能になる前に、明示的に起動する必要があります。

- 次のルールは、リソース・グループおよびリソース・グループ・テンプレート・スコープで常に適用されます。

- スタンドアロン宛先をホストするパス・サービスとJMSサーバーに対して、Distribution Policy=Singletonストアを使用します。

- 分散宛先をホストするSAFエージェントとJMSサーバーに対して、Distribution Policy=Distributedストアを使用します。

- 次のものを持つクラスタのクラスタ・リーシングを構成します。

- Distribution Policy=Singletonのストアまたはブリッジ。

- Migration Policy=On-FailureまたはAlwaysのストアまたはブリッジ。

JMSの使用に関連するより一般的なベスト・プラクティスは、『Oracle WebLogic Server JMSリソースの管理』のJMSの初級ユーザーおよび上級ユーザー向けのベスト・プラクティスに関する項を参照してください。

メッセージングの構成: 制限事項

次のJMSの機能または関連コンポーネントは、WebLogic Server MTで現在サポートされていません。

- パーティションへのクライアントSAF転送:

- 追加した場合の動作は不明です。

- サーバー側のSAFエージェントのパーティションへの転送は、サポートされていません。

- リソース・グループまたはリソース・グループ・テンプレート・スコープのJMSリソースへのCクライアント・アクセス。追加した場合の動作は不明です。

- .NETクライアント。.NETクライアントがパーティションのJMSリソースにアクセスした場合、例外がスローされます。

- レプリケートされた分散トピック(RDT):

- レプリケートされた分散トピック(RDT)を含むリソース・グループまたはリソース・グループ・テンプレートへのJMSモジュールのデプロイメントは、例外で失敗します。

- 共通分散トピックのデフォルト・タイプは、Replicatedの転送ポリシーで構成されています。

- 回避策は次のとおりです。

- スタンドアロン(シングルトン)トピックを構成します。

- パーティション化された分散トピック(PDT)を構成します。
PDTは、転送ポリシーをPartitionedに設定することによって構成されます。

PDTの利点および制限事項は、『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックの構成に関する項を参照してください。

PDTの「パーティション化された」という単語は、WebLogic Server MTパーティションの「パーティション」という単語と同じ意味ではないことに注意してください。PDTとWebLogic Server MTのパーティションは、2つの独立した概念です。

- デフォルト・ストア

- パーティションでのWebLogic Serverのデフォルト・ストアの使用は、許可されません。

- リソース・グループまたはリソース・グループ・テンプレートのすべてのJMSサーバー、SAFエージェントおよびパス・サービスは、カスタム・ストアを参照する必要があります。

- 重み付けされた分散宛先(WDD)

- WDDを含むリソース・グループまたはリソース・グループ・テンプレートへのJMSモジュールのデプロイメントは、例外で失敗します。

- WDDは非推奨です。

- 接続コンシューマおよびサーバー・セッション・プール

- パーティション・スコープの接続コンシューマまたはサーバー・セッション・プールを作成しようとすると、失敗します。

- メッセージドリブンBean (MDB)は接続コンシューマまたはサーバー・セッション・プールと同様の目的を果たすため、MDBを使用することがベスト・プラクティスとなることに注意してください。

- ロギング・ラスト・リソース(LLR)データ・ソース

- トランザクション・システムは、パーティション・スコープのLLR機能をサポートしていません。

- 可能性のある回避策など、詳細は、「トランザクションの構成」を参照してください。

- SSLを使用する専用パーティション・チャネルを使用したクライアント相互運用性

- 古いクライアントは、専用チャネルが構成されたパーティションとのみ相互運用できます。

- この方法は、現在SSLをサポートしていません。

メッセージング・リソース・グループの移行

WebLogic Serverでは、「リソース・グループの移行: 主な手順およびWLSTの例」の説明に従って、別のサーバーまたはクラスタにリソース・グループを移行できます。リソース・グループ内のすべてのメッセージング構成およびデプロイメントをリソース・グループの移行の対象にできます。

- メッセージング構成には、ファイル・ストア、JDBCストア、JMSサーバー、SAFエージェント、パス・サービス、JMSシステム・リソースおよびメッセージング・ブリッジが含まれます。

- メッセージング関連のデプロイメントには、JMSモジュールを対象とするアプリケーション・デプロイメント、そしてJMSリソースを使用するEJBおよびMDBデプロイメントが含まれます。

メッセージング・リソース・グループの移行を実行する場合は、次の特別な考慮事項に注意してください。

- WebLogicメッセージング・リソース・グループを移行する場合、移行を開始する前にソースの場所でリソース・グループを停止し、移行が完了した後で再開する必要があります。実行中のリソース・グループに含まれるメッセージング構成を対象として管理者が移行を開始しようとすると、検証例外がスローまたは表示され、移行を開始する前にリソース・グループを停止するよう指示するメッセージが表示されます。

- リソース・グループの移行では、非永続メッセージング・アプリケーションおよびランタイム状態は維持されません。

- 非永続メッセージは失われます。

- クライアントに例外が返され、移行中に再接続が必要になる場合があります。クライアントが一般的なJMS障害に対処できるように設計されている場合は、新しい場所に自動的にフェイルオーバーできることがあります。「リソース・グループの移行中のクライアント・フェイルオーバー」を参照してください。

- 永続メッセージングの状態データを移行する場合、追加の手順が必要になることがあります。

- ソースの場所とターゲットの場所からアクセス可能な共有ストレージ(データベースまたはファイル)が必要です。

- ほとんどの非クラスタ・ユースケースでは、追加の手順は必要ありません。

- ほとんどのクラスタ・ユースケースでは、通常、正しく動作させるために、メッセージング固有の移行前手順が必要になります。

詳細は、「永続データを含むリソース・グループの移行」を参照してください。

- トピックを操作するメッセージドリブンBeanを移行する場合、追加の手順が必要になることがあります。詳細は、「メッセージドリブンBean (MDB)の移行」を参照してください。

- サード・パーティJMSプロバイダと統合されるアプリケーションを移行する場合、追加の手順が必要になることがあります。詳細は、「サード・パーティJMSとグローバル・トランザクションに関する考慮事項」を参照してください。

このドキュメントの残りの部分では、次の3つのタイプのメッセージング・サービスに言及しています。

- 非クラスタ・サービス: 非クラスタ(スタンドアロン)管理対象サーバーをターゲットとするサービス。

- クラスタ・シングルトン・サービス: Singleton分散ポリシーが指定されたクラスタをターゲットとするサービス。

- クラスタ分散サービス: Distributed分散ポリシーが指定されたクラスタをターゲットとするサービス。

JMSサービスの分散ポリシーはStoreMBeanまたはMessagingBridgeMBeanを使用して構成され、ストアを参照するメッセージング・サービス(JMSサーバー、SAFエージェント、パス・サービスなど)によりストアMBean構成からそのポリシーが継承されます。詳細は、『Oracle WebLogic Server JMSリソースの管理』の簡素化されたJMSクラスタおよび高可用性の構成に関する項を参照してください。

次の表に、サポートされているメッセージング・リソース・グループ移行シナリオのサマリーを示します。

メッセージング・サービス

非クラスタ

クラスタ・シングルトン

クラスタ分散

JMSサーバーおよび宛先

構成および永続データ

構成および永続データ

構成のみ

SAFエージェントおよびインポート済宛先

構成のみ

N/A

構成のみ

パス・サービス

構成および永続データ

構成のみ

構成のみ

メッセージング・ブリッジ

はい

はい

はい。恒久トピックについては制限があります。詳細は、「クラスタ分散サービスの永続データの移行」を参照してください。

永続データを含むリソース・グループの移行

次の各項では、非クラスタ・サービス、クラスタ・シングルトン・サービスおよびクラスタ分散サービスの永続データの処理手順について説明します。

非クラスタ・サービスの永続データの移行

非クラスタ・メッセージングの永続状態(メッセージ、恒久サブスクリプション、SAFデータおよびUOOデータ)は、次に説明するわずかな例外はあるものの、ターゲットの場所に安全に移行して処理できます。

- メッセージング・サービスを含むリソース・グループを非クラスタ管理対象サーバーからクラスタに、またはその逆に移行するには、追加の手順が必要になります。このような場合は、移行を開始する前に、すべてのメッセージを処理し、保留中のトランザクションをすべて完了し、リソース・グループを停止し、すべてのファイルおよびデータベース表を削除してください。

- ストア・アンド・フォワード・エージェントを移行するときには、追加の手順が必要になります。詳細は、「ストア・アンド・フォワード・メッセージの移行」を参照してください。

- ドメイン・レベルのリソース・グループにストア・パスが未定義のファイル・ストアが含まれている場合、移行後にパスが変更され、生成されるパスには現在のWebLogic Serverインスタンスの名前が組み込まれます。このようなストアについては、ソースの場所でリソース・グループを停止してからファイルを新しい場所に移動し、その後、そのターゲットの場所でリソース・グループを再開する必要があります。ファイル・ストアを構成する場合は常にストア・パスを指定することをお薦めします。

クラスタ・シングルトン・サービスの永続データの移行

クラスタ・シングルトン・サービスの永続データを移行するときの考慮事項は、「非クラスタ・サービスの永続データの移行」で説明した非クラスタ・ユースケースと同じになりますが、1つの例外が追加されます。パス・サービスが構成されている場合は、すべての分散宛先メッセージを処理し、すべてのトランザクションを完了し、元の場所でリソース・グループを停止してから、ストア・ファイルまたは表を削除し、その後で新しい場所でリソース・グループを開始する必要があります。

クラスタ分散サービスの永続データの移行

分散宛先やインポート済宛先などの永続分散サービスが関与するリソース・グループ移行ユースケースでは、さらに注意が必要です。このようなサービスに関連付けられている永続データは、それをホストするリソース・グループを移行するときに、安全に移行できません。メッセージが失なわれないようにするには、移行を開始する前にすべてを処理し、分散宛先またはインポート済宛先にメッセージが残っていない状態にする必要があります。

また、すべての永続メッセージが消費され、確認応答された後でも、移行を開始する前に、このようなリソース・グループに関連付けられている永続ストア・ファイルや表をすべて削除することが重要です。たとえば、恒久サブスクリプションが破棄されても、完全にクリーン・アップしないと、ターゲットの場所でメッセージが蓄積され続け、サーバーでメモリー不足が発生する可能性があります。もう1つの例として、UOOメッセージが存在しない場所にルーティングされる可能性があります。

次に、クラスタ分散メッセージングの主なユースケースにおける考慮事項の詳細を示します。

- インポート済宛先および分散宛先の永続メッセージは、ターゲットの場所で使用できなくなります。メッセージが失なわれないようにするには、移行を開始する前にすべてを処理し、分散宛先またはインポート済宛先にメッセージが残っていない状態にする必要があります。

- クラスタをターゲットとし、分散ポリシーがDistributedに設定されたストアは、すべてのファイルを削除するか、JDBC表を削除しないかぎり、安全に移行できません。

- ストア・アンド・フォワード・エージェントを移行するときには、追加の手順が必要になります。詳細は、「ストア・アンド・フォワード・メッセージの移行」を参照してください。

- 移行対象の分散宛先への転送を行うリモート・ストア・アンド・フォワード(SAF)エージェントがある場合は、リモート分散宛先を移行するとき、そのSAFエージェントに対する追加の手順が必要になります。 詳細は、「ストア・アンド・フォワード・メッセージの移行」を参照してください。

- トピックからの転送に使用される分散恒久ブリッジを移行する場合は、注意が必要です。元の場所で生成された対応する恒久サブスクリプションは、新しい場所ではサブスクリプション名が異なるため、破棄される可能性があり、同様に、元のサブスクリプションによって、ソース・トピック上に引き続きメッセージが蓄積される可能性があります。管理者は、このようなブリッジによって生成され、元の場所で実行されているサブスクリプションが、移行中に確実に削除されるようにする必要があります。

- 永続UOOメッセージを処理する分散宛先では通常パス・サービスが使用されます。移行を開始する前に、パス・サービスのストア表またはファイルを削除し、新しい場所の新しいUOOメッセージが正しくルーティングされるようにする必要があります。

- 分散ストアでは、リソース・グループの移行前に開始された保留中のグローバル・トランザクションは、移行後に解決されない可能性があります。これは、移行後にストア・インスタンスのXAリソース名が変更されるためです。管理者は、クラスタでリソース・グループの移行を実行する前に、進行中のトランザクションが存在しないことを確認することをお薦めします。

ストア・アンド・フォワード・メッセージの移行

ストア・アンド・フォワード・メッセージには、メッセージの格納と転送を行うSAFエージェントと最終的なWebLogic JMS宛先の2つのコンポーネントが関与します。多くの場合、これらは個別のWebLogic Serverインスタンス、クラスタまたはドメインにデプロイされるため、2つのコンポーネントを一緒に移行することも、それぞれ単独で移行することもできます。

必ず1回のQOSを使用して分散宛先への転送を行うリモートSAFエージェントがある場合は、リモート分散宛先を移行するとき、そのSAFエージェントに対する追加の手順が必要になります。これは、移行後、SAFメッセージが転送できなくなることにより、後続のメッセージの転送がブロックされる場合があるためです。この状況を回避するために、リモート分散宛先を移行する前に、次のことを実行してSAFキューを空にすることをお薦めします。

1. SAFエージェントでの新規メッセージの受信を一時停止します。詳細は、『Oracle WebLogic Server JMSリソースの管理』の宛先でのメッセージ処理の制御に関する項を参照してください。

2. 保留中のメッセージがすべて正常に転送されるまで待ちます。

必ず1回の転送を処理するSAFエージェント自体を移行する場合は、非クラスタとクラスタのどちらかを問わず、同様の手順を実行することをお薦めします。このことは、SAFエージェントが非永続メッセージのみを処理する場合にも該当します。移行を開始する前に、SAFエージェントのインポート済宛先を空にするか(前述の説明を参照)、SAFエージェントに関連付けられているストア・ファイルまたはJDBC表をすべて削除することをお薦めします。

メッセージドリブンBean (MDB)の移行

MDBのソース宛先がキューである場合は、MDBを安全に移行できます。同様に、MDBがトピックから消費し、かつ、そのsubscription-durabilityがNonDurableに設定されている場合も、MDBを安全に移行できます。

トピックを処理するMDBを移行するとき、そのsubscription-durabilityがDurableに設定されている場合は、MDBまたはトピックが、クラスタ・サーバーと非クラスタ・サーバーのどちらでホストされているかに関係なく、また、MDBのソース宛先が、MDB自体と同じクラスタでホストされているか、サーバーの場所でホストされているかに関係なく、さらに注意が必要です。

次に詳細を示します。

- このような恒久サブスクリプション・トピックMDBを安全に移行できるのは、その構成でTopicMessagesDistributionMode=Compatibilityモードおよびgenerate-unique-client-id=falseが設定されているか、TopicMessagesDistributionMode=one-copy-per-applicationモードが設定されている場合のみです。詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』のMDB向けデプロイメント要素およびアノテーションに関する項を参照してください。

- その他すべての恒久トピックMDBユースケース(TopicMessageDistributionMode=one-copy-per-server、またはTopicMessageDistributionMode=Compatibilityおよびgenerate-unique-client-id=true)では、MDBのサブスクリプション名にローカル・サーバーの名前が含まれ、このようなMDBを移行すると、元の恒久サブスクリプションが破棄されます。破棄された恒久サブスクリプションに関連付けられている未処理のメッセージが失われるだけでなく、破棄された恒久サブスクリプションによりメッセージが蓄積され続け、システム・メモリーの消費が増えて最終的にシステムが停止する可能性があります。このため、このような恒久MDBは、その接続先が非クラスタ、クラスタ・シングルトン、分散トピック、サード・パーティ・トピックのいずれであっても、より慎重に移行する必要があります。管理者は、このようなMDBによって生成され、元の場所で実行されているサブスクリプションが、移行中に確実に削除されるようにする必要があります。

MDBがリスニングする宛先が個別のリソース・グループまたはパーティションに存在する場合、リソース・グループを含むMDBのライブ移行を実行できますが、トピックMDBについての前述の考慮事項(破棄された恒久サブスクリプションに関する記述)は依然として該当します。

恒久MDBが分散トピックをリスニングしている場合は、MDBを移行しなくても、分散トピックを移行すると、関連付けられている恒久サブスクリプションが破棄される可能性があることに注意してください。移行を実行する前に、このような分散トピックの状態を削除する方法の詳細は、「クラスタ分散サービスの永続データの移行」を参照してください。

サード・パーティJMSとグローバル・トランザクションに関する考慮事項

サード・パーティJMSプロバイダと統合されたJava EEアプリケーションを移行する場合は、保留中(インダウトとも呼ばれる)のすべてのトランザクションを事前に完了することが重要です。(この場合、サード・パーティJMSプロバイダとは、WL JMSおよびAQ JMS以外のプロバイダを指します)。

WebLogic ServerインスタンスまたはクラスタにデプロイされているJava EEアプリケーションにおいてサード・パーティJMSプロバイダがグローバル・トランザクションと統合される場合は、内部XAリソース名が作成され、その名前で外部XAリソースがWebLogicトランザクション・マネージャに登録されます。多くの場合、これらの名前には、ローカルのWebLogic Serverインスタンス名が含まれており、この名前は、このようなアプリケーションがリソース・グループの移行の一環として移行された後に変更される可能性があります。トランザクション・マネージャでは元の名前を使用して解決を試みるため、結果として、未決定のトランザクションが移行後に解決できなくなる可能性があります。

リソース・グループの移行中のクライアント・フェイルオーバー

そこに含まれるリソース・グループとともに移行できるリモートJMSリソースをシームレスに操作するには、JMSクライアント・コードで既知のベスト・プラクティスに従って、JMS障害が発生したときに、すべてのJMSおよびJNDI接続を終了してから、JMSに再接続するようにする必要があります。詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSの初級ユーザーおよび上級ユーザー向けのベスト・プラクティスに関する項を参照してください。一部のコンテナおよびサービス(つまり、MDB、インバウンドSOA JMSアダプタおよびメッセージング・ブリッジ)では、クライアントのかわりにこの処理を自動的に実行できます。また、このようなJMSクライアントでは、再接続ロジックで使用されるURLが新しい場所に解決されるようにする必要があります。

リソース・グループの移行時にJMSリソースが移行される場合、例外リスナーのコールバックを介してクライアントに例外が返されるか、同期呼出しに対して例外が返される可能性があります。このとき、クライアントでは、リソースの新しい場所を指す新しいURLを使用するか、または移行中にアドレス再マッピング機能が使用される場合は元のURLを使用して、接続を再確立する必要があります。DNS再マッピングの例として、DNSマッピングの直接変更や、Oracle Traffic Director TCPプロキシを使用した変更をあげることができます。再確立時には、初期接続の確立時に使用した手順に再び従う必要があります。つまり、初期コンテキストの取得、宛先のルックアップ、接続ファクトリのルックアップ、接続の作成、セッションの作成、プロデューサの作成、コンシューマの作成の順に進める必要があります。

この後の各項で説明するJMSクライアント・フェイルオーバーの動作は、スタンドアロン・クライアントだけでなく、MDB、SOA JMSアダプタ、メッセージング・ブリッジなどのリモートまたはローカルJava EEアプリケーションにも該当します。

手動フェイルオーバー

アドレス・マッピングが使用されない場合は、リソース・グループの移行が終了した後、それにアクセスするために元の場所に接続していたクライアントで次の手順を実行する必要があります。

- 既存の初期コンテキストおよびJMSオブジェクトを終了します。

- 新しい場所を指すようにURLを変更します。

- 新しいURLを使用して新しい初期コンテキストを再確立します。

- 初期コンテキストを使用してJMS宛先および接続ファクトリをルックアップします。

- 接続ファクトリおよび宛先を使用してJMSに接続します。

移行後にWebLogic Severインスタンスにのみ接続するクライアントでは、新しい場所を指すURLを使用する必要があります。

Oracle Traffic Director TCPプロキシの使用方法

Oracle Traffic Director TCPプロキシ・メカニズムには、WebLogic Serverのホスティング・ホストおよびポートをOracle Traffic Directorプロキシのホストおよびポートとマップするための機能が備えられています。

Oracle Traffic Director機能を使用するには、移行対象のリソース・グループをホストするパーティションに対するOracle Traffic Directorマッピングを構成する必要がある以外に、Oracle Traffic Directorプロキシのホスト名を使用するようにパーティションの仮想ターゲットを構成するとともに、移行対象のリソース・グループ内のリソースに接続するときにOracle Traffic DirectorプロキシのURLを使用して初期コンテキストを確立するようにアプリケーションを構成することも必要となります。詳細は、『Oracle Traffic Director管理者ガイド』のTCPプロキシの作成に関する項を参照してください。

Oracle Traffic Directorプロキシと、Oracle Traffic Directorを使用するリソース・グループ仮想ターゲットを構成した後は、リソース・グループの移行後にアプリケーション・クライアントで次のいずれかを実行することによって、より少ない手動操作で、クライアントが新しい場所に再接続およびフェイルオーバーできるようになります。

- 新しい初期コンテキストを再確立します。

- 移行後に、移行前に取得した接続ファクトリ・スタブを使用して新しいJMS接続を作成します。

Oracle Traffic Directorサポートが存在するため、手動で実行する必要がある手順は、ターゲットURLをプロキシのURLに再マップし、移行後にプロキシ・インスタンスを再起動することのみです。古いサーバーに対する既存の接続がすべて破棄されるようにするために、再起動することが必要となります。再起動しないと、移行後に新規に接続するクライアントは新しい場所にルーティングされますが、移行前から接続していたクライアントは新しい場所にフェイルオーバーできない可能性があります。

16 JNDIの構成とプログラミング

この章では、Oracle WebLogic Server Multitenant (MT)で外部Java Naming and Directory (JNDI)プロバイダを構成する方法について説明します。この章では、パーティション・ドメイン(リソース・スコープでオブジェクトベースのパーティション関連付け、パーティション情報のバインディングと取得、パーティション上のリソースへのアクセス、パーティションでクラスタ化されたJNDIなど)でのJNDIのプログラミングについても説明します。

この章の内容は次のとおりです。

- 外部JNDIプロバイダの構成: 概要

- 外部JNDIプロバイダの構成: 前提条件

- 外部JNDIプロバイダの構成: 主な手順

- 外部JNDIプロバイダの作成: WLSTの例

- パーティション環境でのJNDIのプログラミング

- 外部JNDIプロバイダの作成: 関連タスクおよびリンク

外部JNDIプロバイダの構成: 概要

WebLogic Serverは外部JNDI APIを備えており、これを使用するとリモートJNDIツリーに直接接続しなくてもそのリモート・ツリー上のオブジェクトにアクセスできます。

パーティション環境では、JNDIツリー上のオブジェクトにローカル・アクセスすることも(同じマシン上の別のパーティションで)、リモートからアクセスすることもできます。

別のパーティションのプロパティを指定して外部JNDIプロバイダを作成して構成すると、パーティションの外部に存在するオブジェクトをルックアップして使用できます。外部JNDIプロバイダに対して設定したプロパティを使用して新しいコンテキストが作成され、これが内部的に実際のルックアップとバインドの操作を行います。

外部JNDIプロバイダの構成: 前提条件

パーティションの外部JNDIプロバイダを作成および構成する前に、次を行う必要があります。

1. 1つ以上の仮想ターゲットを作成します。詳細は、「仮想ターゲットの構成」を参照してください。

2. パーティション内の外部JNDIプロバイダのスコープとして使用するリソース・グループをそのパーティション内に作成します。このリソース・グループを作成するときに、1つ以上の使用可能なターゲットをリソース・グループに対して選択します。詳細は、「リソース・グループの作成: 主な手順および例」を参照してください。

外部JNDIプロバイダの構成: 主な手順

パーティション用の外部JNDIプロバイダを構成する手順は、ドメイン用の構成手順と同じですが、次の例外があります。

- 外部JNDIプロバイダのスコープをパーティションのリソース・グループに設定します。

- 外部JNDIプロバイダが別のマシン上のパーティションに存在する場合、共通のリモート・クライアントであるかのようにプロバイダURLを設定します。たとえば、t3プロトコルの場合、t3://hostname:port/partition_nameとなります。

外部JNDIプロバイダの構成を完了するには、ローカルのJNDI名とリモート・ノード上のJNDI名とを関連付けるための1つ以上の外部JNDIリンクを作成します。

外部JNDIプロバイダの作成: WLSTの例

次の例に、WebLogic Scripting Tool (WLST)を使用して外部JNDIプロバイダを作成し、プロバイダのユーザー名、パスワード、プロバイダURLおよびInitialContextFactoryを構成する方法を示します。このプロバイダの外部JNDIリンクを作成する方法も示します。

# Connect to the Administration Server
connect('adminusername','adminpassword','t3://hostname:port')

# Start an edit session
edit()
startEdit()

# Change to the appropriate resource group directory for the partition for which
# you are creating the foreign JNDI provider.
cd('/Partitions/partition_name/ResourceGroups/resource_group_name')
cmo.createForeignJNDIProvider('provider_name')

cd('ForeignJNDIProviders/provider_name')
set('Password', 'password')
cmo.setUser('username')
cmo.setProviderURL('t3://hostname:port')
cmo.setInitialContextFactory('initialContextFactory')
# Create a foreign JNDI link and configure it
cmo.createForeignJNDILink('link_name')
cd('ForeignJNDILinks/link_name')
cmo.setLocalJNDIName('local_JNDI_name')
cmo.setRemoteJNDIName('remote_JNDI_name')
save()
activate()

パーティション環境でのJNDIのプログラミング

WebLogic Server MTは、複数のパーティションを1つのドメイン内で実行することをサポートします。特定のWebLogic Serverインスタンスには、並行して実行中の複数のパーティションがある場合があります。パーティション内のJNDIリソースは、パーティションごとに分離されます。同じJNDI名の複数のJNDIリソースが複数のパーティションに存在することがあります。

この項では、パーティション環境でのJNDIプログラミングのときに留意する必要のある主な点を、非パーティション環境と比較しながら説明します。次のトピックが含まれています:

- パーティション・スコープとドメイン・スコープのJNDIリソースについて

- オブジェクトベースのパーティション関連付け

- コンテキストのパーティション情報の取得

- JNDIリソースへのリモートおよびパーティションをまたがるアクセス

- パーティション環境でのクラスタ化JNDI

- パーティションJNDIリソースのライフサイクル

JNDIのプログラミングの追加情報は、『Oracle WebLogic Server JNDIアプリケーションの開発』を参照してください。

パーティション・スコープとドメイン・スコープのJNDIリソースについて

WebLogic Serverでは、グローバルJNDIツリーは1つのみであり、これがグローバルJNDIリソースに対するすべてのリクエストを処理します。ただし、WebLogic Server MTでは、ドメインのグローバルJNDIツリーが1つ存在し、パーティションのそれぞれにグローバルJNDIツリーが1つ存在します。パーティションのJNDIリソースは、デフォルトではそのパーティション自体でのみ使用できますが、「JNDIリソースへのリモートおよびパーティションをまたがるアクセス」で説明しているように、このようなリソースにパーティションをまたいでアクセスできます。そのため、デフォルトでは、パーティション・レベルでデプロイされたアプリケーションは、パーティション内のJNDIリソースにのみアクセスでき、他のパーティションまたはドメインのJNDIリソースにはアクセスできません。

たとえば、グローバルJNDI名がjava:global/fooであるEJBをドメインにデプロイし、同じサーバー上の複数のパーティションにもデプロイすると、java:global/fooはこれらのパーティションそれぞれのグローバルJNDIツリーと、ドメインのグローバルJNDIツリーにバインドされます。この結果の動作は、次のようになります。

- java:global/fooのルックアップをパーティションの1つから実行すると、デフォルトでは、そのパーティションのグローバルJNDIツリーにバインドされたインスタンスが返されます。

- java:global/fooのルックアップをドメインから実行すると、ドメインのグローバルJNDIツリーにバインドされたインスタンスが返されます。

他にもいくつかの例を示します。

- mail.MedRecMail SessionはパーティションA、パーティションBおよびドメインにバインドされています。JNDIルックアップをパーティションA内のアプリケーションからリクエストするとパーティションAのセッションが返されますが、JNDIルックアップをパーティションB内のアプリケーションからリクエストするとパーティションBのセッションが返されます。ドメイン内にデプロイされたアプリケーションからJNDIルックアップをリクエストすると、ドメインのセッションが返されます。

- weblogic.transaction.resources.dsXAはパーティションBにのみバインドされています。パーティションB内にデプロイされたアプリケーションからルックアップをリクエストすると、RmiDataSourceが返されます。他のパーティションやドメインにデプロイされたアプリケーションからリクエストすると、NameNotFoundExceptionが返されます。

- java:global/wm/defaultはドメイン・レベルでのみバインドされています。デフォルトでは、ドメイン内にデプロイされたアプリケーションのみがアクセスできます。

注意:

アプリケーション・スコープJNDIリソースのルックアップやバインドなどのリクエストは、アプリケーションに委任されるため、分離されます。

オブジェクトベースのパーティション関連付け

JNDIコンテキストをパーティションの中で作成すると、コンテキスト・オブジェクトはパーティション・ネームスペースに維持され、それ以降のJNDI操作はすべて、そのパーティションのコンテキストの中で行われます。JNDIコンテキストが作成されると、指定したプロバイダURLプロパティによって、特定のパーティションへの関連付けが確立されます。java.naming.provider.urlプロパティを設定してJNDIコンテキストを作成する場合、JNDIはパーティションを認識するためにパーティション情報をプロバイダURLの値の中で探します。パーティションに対して構成された仮想ターゲットURLをプロバイダとして設定する場合は、JNDIによってそのパーティションのコンテキストが作成され、そのコンテキストからのリクエストはすべてパーティションのJNDIリソースに委任されます。

オブジェクトベースのコンテキストが作成された後、その操作はパーティションJNDIツリーを使用して行われます。

コンテキストのパーティション情報の取得

パーティション情報がパーティションのグローバルJNDIツリーにバインドされるのは、パーティション・ツリーが初期化されるときです。コンテキストのパーティション情報を取得するには、次のものをルックアップします。

- weblogic.partitionName、これによってコンテキストベース・パーティションのpartitionNameが返されます。これは、パーティション名またはDomain (ドメインスコープ・コンテキストの場合)です。

- weblogic.partitionId、これによってパーティションのpartitionIdが返されます。これは、ドメインの場合は0 (ゼロ)、パーティションの場合は0より大きい値になります。

JNDIリソースへのリモートおよびパーティションをまたがるアクセス

パーティションJNDIリソースには、リモートのスタンドアロンJavaコードから、WebLogic ServerクライアントまたはリモートのWebLogic Serverインスタンスに存在するコードを使用してアクセスできます。このようにするには、リモートの単一サーバーJNDIツリーにアクセスするときと同様にプロバイダURLを設定します。

また、WebLogic Server JNDIは、あるパーティションがローカルJNDI名のみを宣言できるように外部JNDIプロバイダを拡張しますが、実際は他のパーティションJNDIリソースを指しています。リンク・エントリを構成してローカルJNDI名とパーティションJNDIリソースとを関連付けることができます。

パーティションをまたがる認証

JNDIコンテキスト認証は、コンテキストの作成時に行われます。WebLogic Server JNDIは、現在のパーティションではなく、プロバイダURLが関連付けられているパーティションで認証が処理されていることを確認します。コンテキストの作成時にプロバイダURLが設定されない場合、現在のパーティションに関連付けられたセキュリティ・レルムで認証が処理されます。認証済のコンテキストはスレッド・コンテキストにプッシュされ、以降の操作ではそのコンテキストで権限チェックが行われます。

パーティション環境でのクラスタ化JNDI

クラスタを表すJNDIツリーは、クライアントからは単一のグローバル・ツリーとして認識されます。クラスタ全体のサービスが存在するツリーは、実際にはクラスタ内の各WebLogic Serverインスタンスまたはパーティションにレプリケートされます。

マルチテナント環境で、レプリケート・バインドをJNDIリソースに設定すると、バインド、アンバインドおよび再バインドのイベントは、すべてのクラスタ・ノードに公開されます。

パーティションJNDIリソースのライフサイクル

WebLogic Serverは、パーティション・ライフサイクルに従って、パーティションJNDIリソースのライフサイクルを維持します。

- パーティションが作成されて起動されると、パーティションJNDIツリーがパーティション・ルート・ノードとともに作成されて、使用可能な状態になります。

- パーティションが停止されると、パーティションJNDIツリー全体が削除されます。

外部JNDIプロバイダの作成: 関連タスクおよびリンク

次の追加情報を参照してください。

- 仮想ターゲットの構成

- リソース・グループの構成

- Oracle WebLogic Server JNDIアプリケーションの開発

17 パーティション・ワーク・マネージャの構成

この章では、パーティション・ワーク・マネージャおよびそれらの構成方法について説明します。Oracle Enterprise Manager Fusion Middleware Control、Oracle WebLogic Server管理コンソール、WebLogic Scripting Tool (WLST)またはRepresentational State Transfer (REST) APIを使用できます。この章では、適宜追加情報について、Fusion MiddlewareとWebLogic Serverのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章の内容は次のとおりです。

- パーティション・ワーク・マネージャ: 概要

- パーティション・ワーク・マネージャの構成: 主な手順

- パーティション・ワーク・マネージャの定義: WLSTの例

- パーティション・ワーク・マネージャの構成: 関連タスクおよびリンク

パーティション・ワーク・マネージャ: 概要

パーティション・ワーク・マネージャは、パーティション間にスレッド使用ポリシーを設定します。各パーティションのワーク・マネージャ・スレッド数の制限、および各パーティションのスレッド使用時間に基づいたスレッド使用割当ての管理を行うよう構成できます。相対的なスレッドの使用を規定する際に重要なことは、同じWebLogic Serverインスタンスを共有する様々なパーティション間で適切なサービスの質(QoS)および公平性を提供することです。それが実現できないと、1つのパーティションのアプリケーションによって他のパーティションのスレッド・リソースが不足して、適切に機能しなくなる可能性があります。

パーティション・ワーク・マネージャは、パーティション内でのリソース管理を提供します。管理者は、ランタイム環境およびその共有方法を把握しています。パーティション・ワーク・マネージャをドメイン・レベルで構成し、それらを作成時にパーティションに割り当てます。これらの事前定義済パーティション・ワーク・マネージャによって、管理者はワーク・マネージャ構成を標準化できます(たとえば、ビジネスで重要なアプリケーションが含まれるすべてのパーティションが、ビジネスで重要なパーティション・ワーク・マネージャを参照できます)。

管理者は、特定のパーティション(場合によってはすべてのパーティション)用にパーティション・ワーク・マネージャをカスタマイズする必要がある場合もあります。このシナリオでは、パーティション・ワーク・マネージャをパーティション構成内に(埋め込んで)構成します。このユースケース用にパーティション・ワーク・マネージャ構成を事前定義する必要はありません。

複数のドメイン・パーティションで使用するためにドメインにパーティション・ワーク・マネージャを定義できます。または、特定のパーティションのみで使用するためにそのドメイン・パーティション自体にパーティション・ワーク・マネージャ属性を定義できます。パーティション・ワーク・マネージャが定義されていない場合は、パーティション・ワーク・マネージャ設定のデフォルト値が適用されます。

パーティション・ワーク・マネージャは複数のドメイン・パーティションに使用できます。ただし、ドメイン・パーティションは1つのパーティション・ワーク・マネージャにのみ関連付けることができます。

パーティション構成には次のいずれかを含めることができます。

- ドメイン・レベルで構成されているパーティション・ワーク・マネージャを参照するための<partition-work-manager-ref>

- パーティション構成内にパーティション・ワーク・マネージャ設定を埋め込むための<partition-work-manager>

- パーティション・ワーク・マネージャ設定のデフォルト値を適用する場合は<partition-work-mananger>と<partition-work-manager-ref>のどちらもなし

パーティション・ワーク・マネージャの構成: 主な手順

パーティション・ワーク・マネージャは、パーティション内のワーク・マネージャによるスレッドの使用を制限する一連のポリシーを定義します。これらはドメインには適用されません。

パーティション・ワーク・マネージャを構成する主な手順は、次のとおりです。

1. パーティション・ワーク・マネージャの名前を入力します。

2. オプションで、フェア・シェア値(すべてのパーティションのスレッド使用量と比較して、そのパーティションに必要なスレッド使用率)を入力します。WebLogic Serverドメインで実行されているすべてのパーティションの値の合計が100になるようにすることをお薦めします。デフォルトでは、パーティションのフェア・シェア値は50です。

3. オプションで、最小スレッド数制約値(パーティションに構成されている最小スレッド制約を満たすために作成できるスタンバイ・スレッド数の上限)を入力します。

最小スレッド制約により、サーバーがデッドロックを防止するためにワーク・マネージャに割り当てるスレッド数が保証されます。これでワーク・マネージャは構成済のフェア・シェアより多くのスレッド使用時間を受け取り、パーティションは同じWebLogic Serverインスタンスの他のパーティションと比較してより多くのスレッド使用時間を取得できます。

オプションで、WebLogic Serverドメインに構成されたパーティションごとに最小スレッド制約値の制限を指定できます。構成されると、パーティションに構成された最小スレッド制約値に上限が設定されます。パーティションにおけるすべての最小スレッド制約の構成値の合計がこの構成値を超えた場合、警告メッセージが記録され、WebLogic Serverはスレッド・プールが制約に割り当てているスレッド数を減らします。

デフォルトでは、パーティションに最小スレッド制約制限は設定されていません。

4. オプションで、最大スレッド数制約値(いつでも自己チューニング・スレッド・プールがパーティションで処理できる同時リクエストの最大数)を入力します。

最大スレッド制約値は、パーティションがスレッド・リソースのフェア・シェアを超えて使用しないようにする場合、特にスレッドがI/Oでブロックされ、応答してしないリモート・サーバーからのレスポンスを待機している場合などの異常な状況において役立ちます。そのようなシナリオで最大スレッド制約を設定すると、一部のスレッドがWebLogic Serverインスタンスの他のパーティションからのリクエストの処理に確実に使用できるようになります。

5. オプションで、共有容量の制約値(割合としての、サーバー内のパーティションに存在できるリクエストの総数)を入力します。

パーティションの作業リクエストの数を制限するワーク・マネージャのパーティション共有容量。この制限には、実行中の作業リクエストまたはキューに入れられて使用可能なスレッドを待機しているワーク・リクエストが含まれます。制限を超えると、WebLogic Serverはパーティションから発行された特定のリクエストの拒否を開始します。値は、WebLogic Serverインスタンス全体でリクエスト数を抑制するOverloadProtectionMBeanのsharedCapacityForWorkManagersオプションの構成に従って、WebLogic Server全体の容量の割合で表されます。ワーク・マネージャのパーティション共有容量は、1から100パーセントの間の値にする必要があります。

パーティション・ワーク・マネージャの定義: WLSTの例

次の例は、WLSTを使用してパーティション・ワーク・マネージャを定義する方法を示しています。

ドメイン・レベルのパーティション・ワーク・マネージャの構成: WLSTの例

次の例では、ドメイン・レベルのパーティション・ワーク・マネージャ(myPartitionWorkManager)を作成して構成します。

# Creates a Partition Work Manager at the domain level
edit()
startEdit()
cd('/')
cmo.createPartitionWorkManager('myPartitionWorkManager')
activate()

# Configures the Partition Work Manager
startEdit()
cd('/PartitionWorkManagers/myPartitionWorkManager')
cmo.setSharedCapacityPercent(50)
cmo.setFairShare(50)
cmo.setMinThreadsConstraintCap(0)
cmo.setMaxThreadsConstraint(-1)
activate()

パーティションのパーティション・ワーク・マネージャへの関連付け: WLSTの例

パーティション・ワーク・マネージャは複数のドメイン・パーティションに使用できます。ただし、ドメイン・パーティションは1つのパーティション・ワーク・マネージャにのみ関連付けることができます。次の例では、ドメイン・レベルのパーティション・ワーク・マネージャ(myPartitionWorkManager)をパーティション(Partition-0)に関連付けます。

# Associate a domain-level Partition Work Manager with a partition.
edit()
startEdit()
cd('/Partitions/Partition-0')
cmo.destroyPartitionWorkManager(None)
cmo.setPartitionWorkManagerRef(getMBean('/PartitionWorkManagers/myPartitionWorkManager'))
activate()

パーティションでのパーティション・ワーク・マネージャ属性の定義: WLSTの例

次の例では、ドメイン・パーティション(Partition-1)でパーティション・ワーク・マネージャ属性を定義して、そのパーティションのみで使用されるようにします。

# Defines Partition Work Manager attributes within the partition
edit()
startEdit()
cd('/Partitions/Partition-1')
cmo.createPartitionWorkManager('Partition-1-PartitionWorkManager')

cd('/Partitions/Partition-1/PartitionWorkManager/Partition-1-PartitionWorkManager')
cmo.setSharedCapacityPercent(50)
cmo.setFairShare(50)
cmo.setMinThreadsConstraintCap(0)
cmo.setMaxThreadsConstraint(-1)
activate()

config.xmlファイル内のPartition-0およびPartition-1で定義されたパーティション・ワーク・マネージャ要素に注目してください。

<partition>
<name>Partition-0</name>
<resource-group>
<name>default</name>
</resource-group>
<default-target>VirtualTarget-0</default-target>
<available-target>VirtualTarget-0</available-target>
<realm>myrealm</realm>
<partition-id>318e0d69-a71a-4fa6-bd7e-3d64b85ec2ed</partition-id>
<system-file-system>
<root>C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain/partitions/Partition-0/system</root>
<create-on-demand>true</create-on-demand>
<preserved>true</preserved>
</system-file-system>
<partition-work-manager-ref>myPartitionWorkManager</partition-work-manager-ref>
</partition>
<partition>
<name>Partition-1</name>
<resource-group>
<name>default</name>
</resource-group>
<default-target>VirtualTarget-1</default-target>
<available-target>VirtualTarget-1</available-target>
<realm>myrealm</realm>
<partition-id>8b7f6bf7-5440-4edf-819f-3674c630e3f1</partition-id>
<system-file-system>
<root>C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain/partitions/Partition-1/system</root>
<create-on-demand>true</create-on-demand>
<preserved>true</preserved>
</system-file-system>
<partition-work-manager>
<name>Partition-1-PartitionWorkManager</name>
<shared-capacity-percent>50</shared-capacity-percent>
<fair-share>50</fair-share>
<min-threads-constraint-cap>0</min-threads-constraint-cap>
<max-threads-constraint>-1</max-threads-constraint>
</partition-work-manager>
</partition>
<partition-work-manager>
<name>myPartitionWorkManager</name>
<shared-capacity-percent>50</shared-capacity-percent>
<fair-share>50</fair-share>
<min-threads-constraint-cap>0</min-threads-constraint-cap>
<max-threads-constraint>-1</max-threads-constraint>
</partition-work-manager>
</domain>

パーティション・ワーク・マネージャの構成: 関連タスクおよびリンク

次の追加情報を参照してください。

- 『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Serverのパーティション・ワーク・マネージャに関する項

- 『Oracle WebLogic Server管理コンソール・オンライン・ヘルプ』のパーティション・ワーク・マネージャに関する項

18 ドメイン・パーティションへのWebLogic Serverドメインの移行

この章では、WebLogic Serverドメインをドメイン・パーティションに移行する方法について説明します。Domain to Partition Conversion Tool (D-PCT)で、既存のアプリケーションおよびリソースを非マルチテナント・ドメインからマルチテナント・ドメイン・パーティションに移行できます。

この章の内容は次のとおりです。

- ドメイン・パーティションへのWebLogic Serverドメインの移行: 概要

- ドメイン・パーティションへのWebLogic Serverドメインの移行: 前提条件

- ドメイン・パーティションへのWebLogic Serverドメインの移行: 主な手順

- ドメイン・パーティションへのWebLogic Serverドメインの移行: 制限事項と考慮事項

ドメイン・パーティションへのWebLogic Serverドメインの移行: 概要

WebLogic Server Multitenant (MT)では、1つのWebLogic Serverドメイン内において複数の独立したパーティションがサポートされます。パーティションによってアプリケーション、リソース、セキュリティなどを同じドメイン内の他のパーティションから分離できます。WebLogic Server MTの構成の詳細は、「Oracle WebLogic Server Multitenantの構成」を参照してください。

Domain to Partition Conversion Tool (D-PCT)で、既存のWebLogic Server リリース10.3.6、12.1.2または12.1.3ドメインをWebLogic Server 12.2.1ドメインのパーティションに移行できます。これは、エクスポート・ツールとインポート・ツールの2つのツールで構成されています。エクスポート・ツールはソース・ドメインをホストするWebLogic Serverインストールで使用され、インポート・ツールはターゲットWebLogic Server 12.2.1インストールで使用されます。

D-PCTを使用して、パーティション、リソース・グループおよびリソース・グループ・テンプレートを作成および構成できます。デフォルトでは、D-PCTですべてのアプリケーション、ライブラリおよびリソースが新規パーティションに移動されます。オプションで、個々のアプリケーション、ライブラリおよびリソースを選択するメカニズムも提供されます。

注意:

ドメインのクラスタおよびサーバーの構成はパーティションに適用されません。したがって、新規12.2.1パーティションにマップされません。

Domain to Partition Conversion Toolの新機能

Domain to Partition Conversion Toolの12.2.1.1.0では、新機能が導入されています。大きな変更内容を次に示します。

- D-PCTで、リソースおよびアプリケーションのターゲットとして複数の仮想ターゲットを指定することがサポートされるようになりました。
以前のリリースでは、D-PCTを使用して、ソース・ドメイン内のすべてのリソースのターゲットとして、１つのみの仮想ターゲットを指定できました。12.2.1.1.0以降、このツールでは、複数の仮想ターゲットを使用し、各仮想ターゲットを単一のWebLogic Serverインスタンスまたはクラスタに関連付けることで、リソースおよびアプリケーションのターゲットとして、複数のWebLogic Serverおよびクラスタを指定できるようになりました。ソース・ドメイン内で、その特定のWebLogic Serverインスタンスまたはクラスタをターゲットとするすべてのアプリケーション・デプロイメントおよびリソースは、ターゲット・ドメイン内のリソース・グループに対応します。

このことを実現するために、12.2.1.1.0では、D-PCTによって生成されるJSONファイルの構造が変更されています。したがって、D-PCTの初期リリースから生成されたアーカイブを12.2.1.1.0ドメインにインポートすることはできません。インポート操作中にエラーが報告されます。既存のドメイン・アーカイブについては、D-PCT 12.2.1.1.0ツールを使用して新しいドメイン・アーカイブを再生成して、アーカイブを12.2.1.1.0ドメインにインポートできるようにする必要があります。

- クラスタおよび移行可能ターゲットをターゲットとするJMSリソースに対するD-PCTのサポートが拡張されました。詳細は、「JMSリソースを含むドメインのインポートの考慮事項と制限事項」を参照してください。

- D-PCT 12.2.1.1.0によって生成されるJSONファイルでは、JDBCシステム・リソース、SAFエージェント、メール・セッションおよびJDBCストアを公開することで、ユーザーがより柔軟に操作できるようになっています。これらのリソースは、それぞれ、JSONオブジェクトjdbc-system-resource、saf-agent、mail-sessionおよびjdbc-storeとして使用できます。

ドメイン・パーティションへのWebLogic Serverドメインの移行: 前提条件

D-PCTを構成する前に、次の前提条件を満たす必要があります。

- ターゲット・ドメインはWebLogic Server 12.2.1インストールで構成されている必要があります。

- JDK 8をダウンロードし、ソース・ドメインのホスト・マシンにインストールする必要があります。これは、WebLogic Server 10.3.6でエクスポート・ツールを実行するために必要です。

- ターゲットWebLogic Server 12.2.1ドメインが稼働している必要があります。

- ドメインからパーティションに直接変換し、JavaScript Object Notation (JSON)ファイルに基づいた仮想ターゲットの作成がインポート・ツールで正しく行えるようにするには、ターゲット・ドメインとソース・ドメインのクラスタ名とサーバー名が同一であることが重要です。
デフォルトでは、インポート・ツールはJSONファイルで指定されている名前およびターゲットを使用して仮想ターゲットを作成します。ただし、インポート操作の前に仮想ターゲットを手動で構成することをお薦めします。インポート・ツールを使用する前に仮想ターゲットを事前構成する場合、必ずJSONファイルのpartition属性を変更し、このパーティションで使用するターゲット・ドメインに作成した既存の仮想ターゲットの名前を指定する必要があります。

- インポート・ツールを使用して新規パーティションを作成する前に、新規ドメインのサーバー、クラスタ、仮想ターゲットおよびセキュリティ・レルムをソース・ドメインと同じ構成にしていることを確認する必要があります。パーティションのインポートの詳細は、「パーティションのエクスポートおよびインポート」を参照してください。

ドメイン・パーティションへのWebLogic Serverドメインの移行: 主な手順

Domain to Partition Conversion Tool (D-PCT)の構成の主な手順は次のとおりです。

- WebLogic Serverドメイン・アプリケーション環境のエクスポートの準備

- WebLogic Serverドメイン・アプリケーション環境のエクスポート

- JSONファイルを使用したインポート時のデフォルトのオーバーライド

- ドメイン・パーティションへのアプリケーション・アーカイブ・ファイルのインポート

- レポートを使用したエクスポートおよびインポート操作のモニタリング

WebLogic Serverドメイン・アプリケーション環境のエクスポートの準備

次のタスクを実行して、WebLogic Serverドメイン・アプリケーション環境のエクスポートを準備します。

1. D-PCTツールのzipファイルが置かれたディレクトリに移動します。ドメイン・エクスポート・ツールは、WebLogic Server 12.2.1.1.0ディストリビューションの一部としてバンドルされ、製品インストールの一部として含まれています。D-PCTツールのzipファイルは、ホスト・マシンのMW_HOME/wlserver/common/dpct/D-PCT-12.2.1.1.0.zipにあります。

2. D-PCT-12.2.1.1.0.zipファイルを解凍します。このファイルは、希望のディレクトリに解凍できます。エクスポート・ツール用に別途ディレクトリを作成することをお薦めします。エクスポート・ツールzipディストリビューションをこのディレクトリに解凍し、そこからエクスポート・ツール・スクリプトを実行する必要があります。

zipディストリビューションは次のファイルで構成されています。

- README.txt - Domain to Partition Conversion Tool (D-PCT)のインストールおよび実行に関するドキュメントを含むファイル。

- exportDomainForPartition.sh - ドメイン・パーティションにインポートできるアーカイブにドメイン構成をエクスポートするために、ソースWebLogic Serverドメインで実行されるUNIXスクリプト。

- export-domain.sh - ドメイン・パーティションにインポートできるアーカイブにドメイン構成をエクスポートするために、ソースWebLogic Serverドメインで実行される代替UNIXスクリプト。

- exportDomainForPartition.cmd - ドメイン・パーティションにインポートできるアーカイブにドメイン構成をエクスポートするために、ソースWebLogic Serverドメインで実行されるWindowsスクリプト。

- export-domain.cmd - ドメイン・パーティションにインポートできるアーカイブにドメイン構成をエクスポートするために、ソースWebLogic Serverドメインで実行される代替Windowsスクリプト。

- com.oracle.weblogic.management.tools.migration.jar - ドメイン・アーカイブ・ファイルへのソース・ドメインのエクスポートに使用されるWLSTスクリプトおよびJavaクラスを含むJARファイル。

注意:

com.oracle.weblogic.management.tools.migration.jar内のクラスはJDK 8でビルドされています。したがって、WebLogic Server 10.3.6でエクスポート・ツールを実行する場合、エクスポート・スクリプトはJDK 8との組合せで実行する必要がありますが、これは、WebLogic Server 10.3.6インストールで通常使用されるJDKのバージョンではないことがあります。エクスポート・スクリプトを実行する前に、JAVA_HOME変数を適切に設定していることを確認します。

3. パーティション・アーカイブ・ファイル内の属性を暗号化するための暗号化鍵として使用する文字列を含む鍵ファイルを作成します。パスは管理サーバーによってアクセス可能である必要があります。鍵の文字列のサイズは、1-32文字です。

WebLogic Serverドメイン・アプリケーション環境のエクスポート

WebLogic Serverドメイン・アプリケーションをエクスポートするには、ソースWebLogic Serverドメイン管理サーバーが存在するホスト・マシンでエクスポート・スクリプトを実行する必要があります。

- UNIXでこのスクリプトに渡される引数の構文は、次のとおりです。

exportDomainForPartition.sh ORACLE_HOME DOMAIN_HOME [keyFile] [TOOL_JAR] [app_name] [INCLUDE_APP_BITS={true|false}] [WL_HOME]

または

export-domain.sh -oh {ORACLE_HOME} -domainDir {DOMAIN_HOME} [-keyFile {KEYFILE}] [-toolJarFile {TOOL_JAR}] [-appNames {APP_NAMES}] [-includeAppBits {INCLUDE_APP_BITS}] [-wlh {WL_HOME}]

- Windowsでこのスクリプトに渡される引数の構文は、次のとおりです。

exportDomainForPartition.cmd ORACLE_HOME DOMAIN_HOME [keyFile] [TOOL_JAR] [app_name] [INCLUDE_APP_BITS={true|false}] [WL_HOME]

または

export-domain.cmd -oh {ORACLE_HOME} -domainDir {WL_DOMAIN_HOME} [-keyFile {KEYFILE}] [-toolJarFile {TOOL_JAR}] [-appNames {APP_NAMES}] [-includeAppBits {INCLUDE_APP_BITS}]  [-wlhL_HOME}]

Windowsでスクリプトを実行する前に、次のタスクを実行します。

1. コマンド・シェルを開き、エクスポート・ツール・ディストリビューションを解凍したディレクトリに移動します。

2. JAVA_HOME環境変数をJDK 8インストールのパスに設定します。次に例を示します。

C:\> set JAVA_HOME=C:\jdk1.8.0

注意:

エクスポート操作時、ソース・ドメインで構成を変更しないことをお薦めします。

このスクリプトは、次の表に説明されている引数を受け入れます。

引数

説明

ORACLE_HOME

WebLogic ServerがインストールされているOracleホーム・ディレクトリの名前。

この引数は、name=valueのペアとして指定できます。たとえば、ORACLE_HOME=/Oracle/Middleware/Oracle_Homeです。

DOMAIN_HOME

ソースWebLogic Serverドメインのフルパス。

この引数は、name=valueのペアとして指定できます。たとえば、DOMAIN_HOME=/Oracle/Middleware /Oracle_Home/user_projects/domains/medrecです。

keyFile

オプション。パーティション・アーカイブ・ファイル内の属性を暗号化するための暗号化鍵として使用する文字列を含むファイルへのフルパス。管理サーバーには、このパスに対するアクセス権が必要です。デフォルト値はNoneです。

TOOL_JAR

com.oracle.weblogic.management.tools.migration.jarファイルのパス。JARファイルがexportDomainForPartition.shまたはexport-domain.shスクリプトと同じディレクトリにある場合、この引数はオプションです。

app_name

オプション。エクスポートするアプリケーション名のリスト。アプリケーションのリストは、Windowsでは[myapp1+myapp2]と指定する必要があり、UNIXでは[\'myapp1\',\'myapp2\']と指定する必要があります。指定しない場合、ドメイン内のすべてのアプリケーションがエクスポートされます。

INCLUDE_APP_BITS

オプション。アプリケーション・バイナリ・ファイルがアーカイブ・ファイルに含まれているかどうかを示すフラグ。この値のデフォルトはtrue,で、バイナリ・ファイルが含まれていることを意味します。falseの場合、これらのファイルは含まれていません。

WL_HOME

オプション。WebLogic Serverがインストールされたディレクトリのフルパス。この値は、WebLogic Server 10.3.6がデフォルトの場所(ORACLE_HOME/wlserver_10.3)以外のディレクトリにインストールされている場合にのみ指定する必要があります。この値は、wlst.shおよびwlst.cmdスクリプトの場所を決定するために使用されます。

注意:

exportDomainForPartition.cmdおよびexportDomainForPartition.shスクリプトにオプション引数を指定する場合は、次のオプション引数を渡す前に、必ず、指定しないすべてのオプション引数にNoneを指定します。前のオプション引数にNoneを指定しないで、有効な値を持つオプション引数を渡した場合、指定した値が前の引数に誤って割り当てられる可能性があります。ただし、有効な値を持つ最後のオプション引数の後に出現するオプション引数にはNoneを指定する必要はありません。

WebLogic Serverドメイン・アプリケーションのエクスポート: 例

注意:

Windowsコマンド・シェルでドメインのエクスポート・スクリプトを実行する場合、パス区切りをエスケープする必要があります。

例18-1 UNIXでのドメインのエクスポート・スクリプトの実行

次の例では、UNIXでパス/Oracle_Home/user_projects/domains/base_domainからドメインをエクスポートします。引数/usr/myUserKeyFileは暗号化鍵ファイルのパスで、download/com.oracle.weblogic.management.tools.migration.jarはエクスポート・ツールJARファイルのパスです。

exportDomainForPartition.sh /Oracle_Home /Oracle_Home/user_projects/domains/base_domain /usr/myUserKeyFile  /download/com.oracle.weblogic.management.tools.migration.jar

または

export-domain.sh -oh /Oracle_Home -domainDir /Oracle_Home/user_projects/domains/base_domain -keyFile /usr/myUserKeyFile

例18-2 Windowsでのドメインのエクスポート・スクリプトの実行

次の例では、WindowsでパスOracle_Home\\user_projects\\domains\\base_domainからドメインをエクスポートします。引数myKeyfileは暗号化鍵ファイルで、oracle.weblogic.management.tools.migration.jarはエクスポート・ツールJARファイルです。

exportDomainForPartition.cmd C:\\Oracle_Home C:\\Oracle_Home\\user_projects\\domains\\base_domain myKeyfile C:\\com.oracle.weblogic.management.tools.migration.jar

または

export-domain.cmd -oh C:\\Oracle_Home -domainDir C:\\Oracle_Home\\user_projects\\domains\\base_domain -keyFile myKeyfile

JSONファイルを使用したインポート時のデフォルトのオーバーライド

WebLogic Serverドメイン・アプリケーションのエクスポート操作時、JSONテキスト・ファイルが生成され、アーカイブ・ファイルおよび編集および変更が可能な別ファイルとして格納されます。このファイルでは、インポート操作時に作成されるパーティションのデフォルト値が指定されます。ただし、JSONファイルを編集してこれらのデフォルト値をオーバーライドできます。たとえば、JSONファイルでデフォルト仮想ターゲット名を指定します。別の名前の仮想ターゲットを作成する場合、JSONファイルを編集してvirtual-targetセクションの値を変更します。

次の例は、エクスポート・ツールによって生成されるサンプルJSONファイルで、JSONファイル・オブジェクトと属性の両方およびそのオーバーライド方法を示しています。

{
"virtual-target": [{
"name": "${PARTITION_NAME}-AdminServer-virtualTarget",
"target": "AdminServer",
"uri-prefix": "/${PARTITION_NAME}"
}],
"resource-group": [{
"name": "${PARTITION_NAME}-AdminServer-RG",
"target": [{
"virtual-target": {
"name": "${PARTITION_NAME}-AdminServer-virtualTarget"
}
}],
"app-deployment": [{
"name": "testApp1",
"exclude-from-import": "false"
}],
"file-store": [{
"name": "WseeSoapjmsFileStore_auto_1",
"exclude-from-import": "false"
},
{
"name": "WseeSoapjmsFileStore_auto_2",
"exclude-from-import": "false"
}],
"jms-server": [{
"name": "WseeSoapjmsJmsServer_auto_1",
"exclude-from-import": "false"
},
{
"name": "WseeSoapjmsJmsServer_auto_2",
"exclude-from-import": "false"
}],
"jms-system-resource": [{
"name": "testJMSModule",
"exclude-from-import": "false",
"sub-deployment": [{
"name": "testJmsServer",
"exclude-from-import": "false"
}]
},
{
"name": "WseeSoapjmsJmsModule",
"exclude-from-import": "false",
"sub-deployment": [{
"name": "WseeSoapjmsJmsServer649564037",
"exclude-from-import": "false"
}]
}],
"resource-group-template": {
"name": "${PARTITION_NAME}-AdminServer-RGTemplate"
}
}],
"partition": {
"default-target": [{
"virtual-target": {
"name": "${PARTITION_NAME}-AdminServer-virtualTarget"
}
}],
"jdbc-system-resource-override": [{
"name": "MedRecGlobalDataSourceXA",
"url": "__EXISTING_VALUE__",
"user": "__EXISTING_VALUE__",
"password-encrypted": "__EXISTING_VALUE__"
}],
"jms-system-resource-override": [{
"name": "testJMSModule",
"foreign-server-override": [{
"name": "ForeignServer1",
"foreign-destination-override": [{
"name": "ForeignDestination1",
"remote-jndi-name": "__EXISTING_VALUE__"
},
{
"name": "ForeignDestination2",
"remote-jndi-name": "__EXISTING_VALUE__"
}],
"foreign-connection-factory-override": [{
"name": "ForeignConnectionFactory1",
"remote-jndi-name": "__EXISTING_VALUE__",
"username": "__EXISTING_VALUE__"
}]
}]
}],
"realm": "__EXISTING_VALUE__",
"available-target": [{
"virtual-target": {
"name": "${PARTITION_NAME}-AdminServer-virtualTarget"
}
}]
},
"implementation-version": "12.2.1.1"
}

次の表では、JSONファイルで編集および変更できるオブジェクトと属性について説明します。

JSONファイルの編集可能なオブジェクトと属性

注意

ルート・レベル・オブジェクトvirtual-target

デフォルトでは、インポート・ツールはサンプル・ファイルに示しているように仮想ターゲットを作成します。インポート操作の前に仮想ターゲットを手動で構成することをお薦めします。仮想ターゲットの構成の詳細は、「仮想ターゲットの構成」を参照してください。

インポート操作中に仮想ターゲットの自動作成が行われないようにするには、このオブジェクトと関連する値を必ず削除します。

オブジェクトpartition

このオブジェクトでは、パーティションの作成に必要な要素と値を指定します。

このパーティションの仮想ターゲットを手動ですでに作成している場合、virtual-target値(default-targetおよびavailable-target内)を既存の仮想ターゲットの名前に置き換えます。

オブジェクトresource-group-template

デフォルト・リソース・グループ・テンプレート名をオーバーライドするには、name値を編集します。

オブジェクトresource-group

属性exclude-from-import

この属性で特定のオブジェクトまたはリソースをパーティションへのインポートから除外するかどうかが決まります。パーティションでのJMSおよびJDBCリソース・ターゲット指定の制限事項については、「ドメイン・パーティションへのWebLogic Serverドメインの移行: 制限事項と考慮事項」を参照してください。

この値をtrueに設定すると、オブジェクトまたはリソースはパーティションにインポートされません。デフォルト値はfalseです。

ドメイン・パーティションへのアプリケーション・アーカイブ・ファイルのインポート

ドメイン・アプリケーション・アーカイブ・ファイルをインポートする前に、ターゲットWebLogic Server 12.2.1ドメインが稼働していることを確認します。

WebLogic Server 12.2.1ドメインに新規パーティションを作成し、アプリケーション・アーカイブ・ファイルを新たに作成したドメイン・パーティションにインポートするには、オンライン・モードでWLSTコマンドを使用して次の手順を実行します。

1. 次の例に示すように、ドメイン・アーカイブ・ファイルをインポートするターゲットWebLogic Serverドメインに接続します。

connect('user', 'mypassword', 't3://myserver:7001')

2. 次の構文を使用してimportPartitionコマンドを実行します。

importPartition( archiveFileName , partitionName , createRGT=true|false , userKeyFile )

コマンドは非同期であり、MBean ImportExportPartitionTaskMBeanを戻します。このコマンドを次のように使用して、インポート操作の結果を取得できます。

result = importPartition( .... )

print result.getState()を使用してインポートの結果の状態を取得したり、print result.getError()を使用してインポート操作が失敗した場合のエラー・メッセージを表示できます。このコマンドの詳細は、WebLogic Server WLSTコマンド・リファレンスを参照してください。

次の表でimportPartitionコマンドに指定する必要のある引数について説明します。

引数

説明

archiveFileName

インポートするパーティション・アーカイブのフルパス。パスは管理サーバーによってアクセス可能である必要があります。

このコマンドは、ドメイン・アーカイブと同じディレクトリで、domain name-attributes.jsonファイルも検索します。検出された場合、そのファイルの値はドメイン・アーカイブの値をオーバーライドします。

partitionName

オプション。ターゲット・ドメインに作成されるときにパーティションに使用する名前。

これは、importpartitionコマンドを使用して、D-PCTにより作成されるドメイン・アーカイブをインポートする場合にのみ指定する必要があります。

createRGT

オプション。アーカイブ・ファイル内のすべてのリソースに対してリソース・グループ・テンプレートを作成するかどうかを示すフラグ。

リソース・グループ・テンプレートを作成する場合はtrueに設定し、すべてのリソースを新規パーティションのリソース・グループに直接追加する場合はfalseに設定します。

userKeyFile

オプション。エクスポート操作時に指定されたのと同じクリアテキスト・パスフレーズを含むユーザー・キー・ファイルの絶対パス。このファイルは、アーカイブ・ファイル内の属性の復号に使用されます。

例18-3 ドメイン・パーティションへのアプリケーション・アーカイブ・ファイルのインポート: WLSTの例

次のWLSTコマンドでは、outDir/<domain>.zipアーカイブ・ファイルをtestPartitionという名前の新規パーティションにインポートします。リソース・グループ・テンプレートも作成され、/usr/myUserKeyFileが暗号化鍵として使用されます。

wls:/wsDomain/> importPartition( '/outDir/<domain>.zip', 'testPartition',  true,  '/usr/myUserKeyFile' )

レポートを使用したエクスポートおよびインポート操作のモニタリング

D-PCTにより生成されるレポートを使用して、エクスポートおよびインポート操作をモニターおよび分析できます。エクスポートおよびインポート・レポートには、D-PCTを使用してソース・ドメインからターゲット・ドメイン・パーティションにリソースを移行するときに役立つ情報が含まれています。

エクスポート・レポートは、D-PCTインストール・ディレクトリの下にあるドメイン・アーカイブが作成されるディレクトリに、domain name-ExportLogReport.htmlという形式で保存されます。これには、ドメインの場所、ソースWebLogic Serverバージョンなどの情報と、ツールによるエクスポートがサポートされているまたはサポートされていないすべてのリソースのリストが含まれます。エクスポート・レポートを使用して、正常にエクスポートされたサーバーおよびリソースのリストまたはエクスポートに失敗したサーバーおよびリソースのリストを表示できます。ターゲット指定されず、エクスポートされなかったリソースのリスト、またはターゲット(複数のサーバーまたはクラスタ)が指定されたものの、エクスポートされなかったリソースのリストも表示できます。

インポート・レポートは、ドメイン・ディレクトリに、PartitionName_MigrationImportReport.htmlという形式で保存されます。このレポートには、インポート操作中に作成される仮想ターゲットに関する情報とリソース・グループおよびそのターゲット指定情報が含まれます。このレポートを使用して、ドメイン・パーティションに正常にインポートされたリソースのリストを表示できます。また、ユーザーにより除外されたリソース、またはマルチテナント環境に対応していないためにツールによって無視されたリソースのリストも表示されます。

ドメイン・パーティションへのWebLogic Serverドメインの移行: 制限事項と考慮事項

この項では、Domain to Partition Conversion Tool (D-PCT)の制限事項について説明します。次のシナリオは、このツールでサポートされません。

- ライブラリおよびリソースの新規リリースへのドメイン・アップグレードは、インポート時サポートされません。管理者およびユーザーは、アーカイブ・ファイルのエクスポートの前にソース・ドメインからの必要なドメイン・アップグレードを行う必要があります。

- アプリケーションのランタイム状態もアプリケーションに固有のランタイム構成もアーカイブ・ファイルにエクスポートされません。たとえば、キュー内のJMSメッセージや組込みLDAPレルム内のユーザーはエクスポートされません。

- 12.2.1より前のバージョンのWebLogic Serverでコンパイルされたリモート・クライアントは、パーティションにデプロイされているJNDIリソースをルックアップできません。WebLogic Server リリース12.2.1以降で再コンパイルする必要があります。

- JDBCでは、WebLogic Server Multitenantでのロギング・ラスト・リソース(LLR)機能の使用はサポートされません。このオプションを使用したデータ・ソースは代替設定を使用するよう変換する必要がありますが、この代替設定では十分ではない場合もあります。

JMSリソースを含むドメインのインポートの考慮事項と制限事項

この項では、1つ以上のJMSリソースを含むドメインをエクスポートする前に考慮する必要のある制限事項およびその他の動作を示します。

- JMSシステム・モジュール内のサブデプロイメントが、1つ以上のクラスタや移行可能ターゲット、またはWebLogic Serverインスタンスをターゲットとし、かつ、共通分散宛先によって参照されている場合は、クラスタまたは移行可能ターゲット、またはWebLogic Serverをターゲットとする、該当するJMSサーバーに、サブデプロイメントのターゲット指定を変更する必要があります。

- ソース・ドメイン内のデフォルト・ターゲット指定を使用する共通分散宛先およびSAFインポート済宛先は、インポートが成功した後、ターゲット指定されない状態になります。共通分散宛先、SAFインポート済宛先または外部サーバーのターゲットがデフォルトで指定されている場合は、それらを変更して、リソースのターゲットを適切なJMSサーバーまたはSAFエージェントにすることによって、サブデプロイメントのターゲット指定が使用されるようにする必要があります。

- 単一のJMSサーバーが、スタンドアロン宛先および共通分散宛先などの競合するJMSリソースをホストしていないことを確認してください。エクスポート操作中に、競合するリソースのいずれかをホストしているJMSサーバーがD-PCTによって検出されると、該当するJMSシステム・モジュールがエクスポートから除外されます。これは、これらのリソースそれぞれが、異なる分散ポリシーを持つ永続ストアを参照するJMSサーバーを必要とするためです。詳細は、「JMSサーバーの構成」を参照してください。

- 重み付けされた分散宛先は非推奨であり、マルチテナント環境のJMSではサポートされません。このため、重み付けされた分散宛先はD-PCTによって無視されます。すべての重み付けされた分散宛先リソースを同等の共通分散宛先リソースに変換することをお薦めします。異なるタイプの分散宛先リソースの構成の詳細は、『Oracle WebLogic Server JMSリソースの管理』の分散宛先リソースの構成に関する項を参照してください。

- ドメイン・レベルでは、JMSリソースのターゲットとして複数のWebLogic Serverまたはクラスタを指定できます。ただし、パーティション環境で、リソース・グループのターゲットとして複数の仮想ターゲットが指定されている場合、JMSリソースはサポートされません。このため、D-PCTでは、ソース・ドメイン内の複数のWebLogic Serverインスタンスまたはクラスタ、または移行可能ターゲットをターゲットとするアプリケーション・デプロイメントおよびその他すべてのリソースが無視されます。

- JMSでは、パーティション環境の共通分散トピックに対するReplicated転送ポリシーがサポートされません。このため、そのような場合は、D-PCTによって転送ポリシーがPartitionedに変換されます。共通分散トピック・メッセージ転送ポリシーの詳細は、『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックの構成に関する項を参照してください。

- 複数のJMSサーバーがある場合は、各サーバーのターゲットが、同じクラスタの移行可能ターゲットまたはWebLogic Serverメンバーになり、インポート操作によって、すべてのJMSサーバーが、分散ポリシーがDistributedであるストアを使用して構成された単一のJMSサーバーに統合されます。その他のJMSサーバーは、インポート操作中に無視されます。

- パーティション環境のJMSで、サブデプロイメントがターゲットとして使用できるJMSサーバーまたはSAFエージェントは1つのみです。ソース・ドメインに、複数のJMSサーバーまたはSAFエージェントをターゲットとするサブデプロイメントがある場合は、それらがアルファベット順にソートされ、最初のJMSサーバーまたはSAFエージェントがサブデプロイメントのターゲットとして選択されます。デフォルトでターゲットが指定されている接続ファクトリはそのまま移行され、JMSシステム・モジュールが作成されているリソース・グループのターゲットで参照されます。

- パーティション環境では、分散ポリシーがSingletonに設定されている永続ストアを参照するJMSサーバーのみがスタンドアロン宛先をホストできます。分散ポリシーの概念は最近WebLogic Server 12.2.1に導入されたため、D-PCTによってサポートされるソース・ドメインでは分散ポリシーがサポートされません。JMSによるこの制限を回避するために、D-PCTでは、スタンドアロン宛先をホストするJMSサーバーが参照する永続ストアの分散ポリシーを自動的に設定します。

- ドメイン・レベル構成のJMSでは、複数のメッセージング・ブリッジがソースまたはターゲット宛先として同じブリッジ宛先を使用できます。ただし、JMSによって導入された新しい検証では、メッセージング・ブリッジおよびブリッジ宛先がパーティション環境で構成されている場合、ブリッジ宛先は1つのみのメッセージング・ブリッジによってソースまたはターゲット宛先として使用される必要があります。このことを考慮して、D-PCTではパーティションへの移行中に次のアプローチが適用されます。

- ソース・ドメインからのブリッジ宛先は、メッセージ・ブリッジがそのブリッジ宛先を参照している場合にのみ、ターゲット・パーティションに作成されます。

- D-PCTが、メッセージング・ブリッジによってソースまたはターゲット宛先としてすでに使用されているブリッジ宛先を検出すると、そのブリッジ宛先の名前が元のブリッジ宛先の名前_そのブリッジ宛先を参照するメッセージング・ブリッジの名前に内部的に変更されます。

注意:

D-PCTでは、1つ以上のアプリケーション・デプロイメントまたはリソースがこのツールによってサポートされていない場合、ユーザーはこれらをインポートから除外できます。これらのリソースをインポートから除外するには、JSONファイルでexclude-from-import属性をtrueに設定します。除外したリソースは、後で、必要に応じてパーティション内に手動で作成できます。

19 パーティション同時管理対象オブジェクトの構成

この章では、Oracle WebLogic Server Multitenant (MT)でパーティション・レベルの同時管理対象オブジェクト(CMO)テンプレートおよび同時制約を構成する方法について説明します。この章の説明に従い、Oracle WebLogic Server管理コンソールを使用して、パーティションCMOを構成できます。

この章の内容は次のとおりです。

- パーティション同時管理対象テンプレートの構成: 概要

- パーティションCMOテンプレートの構成: 主な手順

- パーティションの同時制約の構成: 主な手順

- パーティション同時管理対象オブジェクトの構成: 関連タスクおよびリンク

パーティション同時管理対象テンプレートの構成: 概要

Java EE 1.0の同時実行性ユーティリティ(Java Specification Request (JSR) 236)は、サーブレットやEJBなどのJava EEアプリケーション・コンポーネントに非同期実行機能を提供する標準APIを実装しています。WebLogic Serverでは、同時管理対象オブジェクト(CMO)がJava EEアプリケーションに対して同時実行機能を提供しています。同時管理対象オブジェクトを構成してから、それをアプリケーション・コンポーネントが使用できるようにすることができます。

ドメインおよびサーバー・レベルのCMOに対するサポートの提供に加えて、WebLogic Serverでは、パーティション・スコープのタスクを実行するためのパーティション・レベルのCMOテンプレートも提供されます。このドキュメントでは、CMOテンプレートがパーティションに適用されるため、このテンプレートについてのみ説明します。

同時管理対象オブジェクト・コンポーネント

同時実行性ユーティリティのプライマリ・コンポーネントは次のとおりです。

- ManagedExecutorService (MES): 発行されたタスクを非同期的に実行するためにアプリケーションによって使用されます。タスクは、コンテナによって開始および管理されるスレッドで実行されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。

- ManagedScheduledExecutorService (MSES): 発行されたタスクを特定の時点で非同期的に実行するためにアプリケーションによって使用されます。タスクは、コンテナによって開始および管理されるスレッドで実行されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。

- ManagedThreadFactory (MTF): 管理対象スレッドを作成するためにアプリケーションによって使用されます。スレッドは、コンテナによって開始および管理されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。

- ContextService: コンテナのコンテキストを取得する動的プロキシ・オブジェクトを作成して、アプリケーションがそのコンテキスト内で後で実行されるようにするか、管理対象エグゼキュータ・サービスに発行されるようにするために使用されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。

詳細は、Java EE 7チュートリアルのJava EEの同時実行性ユーティリティに関する項を参照してください。「Java Specification Request 236: Concurrency Utilities for Java EE 1.0」(http://jcp.org/en/jsr/detail?id=236)も参照してください。

CMOによるパーティション・レベルの非同期タスク管理

WebLogic Serverでは、非同期タスク管理は表19-1にまとめられている4つのタイプのCMOで提供されます。

表19-1 非同期タスク管理を提供するCMO

管理対象オブジェクト

コンテキストの伝播

自動チューニング

停止時のスレッド中断

同時長時間実行新規スレッドの制限

管理対象エグゼキュータ・サービス(MES)

コンテキストは構成に基づいて伝播されます。

短時間実行タスクのみが、指定されたワーク・マネージャによって単一の自己チューニング・スレッド・プールにディスパッチされます。

ワーク・マネージャの停止中に、すべての未完了タスクが取り消されます。

過剰な数のスレッドによってサーバーが悪影響を受けないように、MESやMSESによって作成される長時間実行スレッドの最大数を構成できます。

管理対象スケジュール済エグゼキュータ・サービス(MSES)

コンテキストは構成に基づいて伝播されます。

MESと同じ動作。

MESと同じ動作。

MESと同じ動作。

コンテキスト・サービス

コンテキストは構成に基づいて伝播されます。

該当せず

該当せず

該当せず

管理対象スレッド・ファクトリ(MTF)

コンテキストは構成に基づいて伝播されます。

newThread()メソッドによって戻されるスレッドは、単一の自己チューニング・スレッド・プールからのスレッドではなく、タスクの完了時にこのスレッド・プールに入れられることはありません。

newThread()メソッドによって作成されたスレッドは、MTFの停止時に中断されます。

過剰な数のスレッドによってサーバーが悪影響を受けないように、MTFによって作成される新規スレッドの最大数を構成できます。

WebLogic Serverには3つのタイプのJSR236 CMOがあり、各CMOは、そのスコープ、およびその定義方法や使用方法で特徴付けられます。

- デフォルトJava EE CMO: アプリケーションがデフォルト・リソースを利用できるようにするためにJava EE標準で必要となり、これらのデフォルト・リソースに固有のJNDI名を定義します。

- 構成ファイル内のカスタマイズ済CMO: アプリケーションおよびモジュール・レベルで定義するか、JNDIにバインドされたアプリケーション・コンポーネント環境から参照できます。

- グローバルCMOテンプレート: WebLogic Server管理コンソールおよび構成MBeanを使用して、ドメイン、サーバーおよびパーティション・レベルの構成でテンプレートとしてグローバルに定義できます。

注意:

このドキュメントでは、グローバルCMOテンプレートがドメイン・パーティションに適用されるため、このテンプレートについてのみ説明します。構成ファイル内のデフォルトJava EE CMOおよびカスタマイズ済CMOに関する概念の詳細は、『Oracle WebLogic Serverサーバー環境の管理』の同時管理対象オブジェクトの構成に関する項を参照してください。

ワーク・マネージャと同様に、グローバルCMOテンプレートは、WebLogic Server管理コンソールまたは構成MBeanを使用して、ドメイン、サーバーおよびパーティション・レベルで定義できます。パーティション・レベルでのCMOの構成の詳細は、「パーティションCMOテンプレートの構成: 主な手順」を参照してください。

パーティション・レベルのMESテンプレート構成要素

表19-2に、パーティション・レベルのMESテンプレートの構成要素を定義します。

表19-2 管理対象エグゼキュータ・サービスの構成要素

名前

説明

必須

デフォルト値

範囲

name

MESの名前。

- 名前はDefaultManagedExecutorServiceにしないでください。そうしないと、サーバーを正常に起動できません。

- 同じ名前のパーティション・レベルのMESは同じパーティション内に構成できません。そうしないと、サーバーを正常に起動できません。

- ManagedExecutorServiceは、任意のパーティション内の無関係なその他のタイプの管理対象オブジェクト(ContextServiceなど)と同じ名前にすることができます。

- パーティション・レベルのMESとJSR236 MESは無関係であるため、同じ名前にすることができます。

- 同じ名前のパーティション・レベルMESが、<resource-group-template>およびあるパーティションの<resource-group>の両方で定義されている場合、<resource-group>定義は、そのパーティションの<resource-group-template>定義をオーバーライドします。

はい

該当せず

任意の空でない文字列。

dispatch-policy

ワーク・マネージャの名前。パーティション・レベルのワーク・マネージャは、この名前で選択されます。ワーク・マネージャが存在しない場合、パーティション・レベルのデフォルトのワーク・マネージャが使用されます。

いいえ

デフォルトのワーク・マネージャ

該当せず

max-concurrent-long-running-requests

同時長時間実行タスクの最大数。

いいえ

10

[0-65534].

範囲外の場合、デフォルト値が使用されます。

long-running-priority

長時間実行デーモン・スレッドの優先度を指定する整数。指定すると、すべての長時間実行スレッドが影響を受けます。

いいえ

Thread.NORM_PRIORITY

1-10

Thread.MIN_PRIORITY,とThread.MAX_PRIORITYとの間の範囲。範囲外の場合、デフォルト値が使用されます。

パーティション・レベルのMSESテンプレート構成要素

表19-3に、パーティション・レベルのMESテンプレートに類似した、パーティション・レベルのMSESテンプレートの構成要素を定義します。

表19-3 管理対象スケジュール済エグゼキュータ・サービスの構成要素

名前

説明

必須

デフォルト値

範囲

name

MSESの名前。

ネーミング規則については、表19-2を参照してください。

はい

該当せず

任意の空でない文字列。

dispatch-policy

ワーク・マネージャの名前。

ワーク・マネージャの使用方法の規則については、表19-2を参照してください。

いいえ

デフォルトのワーク・マネージャ

該当せず

max-concurrent-long-running-requests

同時長時間実行タスクの最大数。

いいえ

10

[0-65534].

範囲外の場合、デフォルト値が使用されます。

long-running-priority

長時間実行デーモン・スレッドの優先度を指定する整数。指定すると、すべての長時間実行スレッドが影響を受けます。

いいえ

5 Thread.NORM_PRIORITY

1-1

Thread.MIN_PRIORITYとThread.MAX_PRIORITYとの間の範囲。範囲外の場合、デフォルト値が使用されます。

パーティション・レベルのMTFテンプレート構成要素

表19-4に、パーティション・レベルのMTFテンプレートの構成要素を定義します。

表19-4 管理対象スレッド・ファクトリの構成要素

名前

説明

必須

デフォルト値

範囲

name

MTFの名前。

ネーミング規則については、表19-2を参照してください。

はい

該当せず

任意の空でない文字列。

priority

スレッドに割り当てる優先度。(数が大きいほど、高い優先度を示します。)

いいえ

5 Thread.NORM_PRIORITY

1-10 Thread.MIN_PRIORITYとThread.MAX_PRIORITYとの間の範囲。範囲外の場合、デフォルト値が使用されます。

max-concurrent-new-threads

MTFによって作成され、タスクのrun()メソッドを引き続き実行するスレッドの最大数。

いいえ

10

[0-65534]

範囲外の場合、デフォルト値が使用されます。

表19-5に、パーティション・レベルのMTFの構成要素を定義します。

表19-5 管理対象スレッド・ファクトリの構成要素

名前

説明

必須

デフォルト値

範囲

name

MTFの名前。

ネーミング規則については、表19-2を参照してください。

はい

該当せず

任意の空でない文字列。

priority

スレッドに割り当てる優先度。(数が大きいほど、高い優先度を示します。)

いいえ

5 Thread.NORM_PRIORITY

1-10 Thread.MIN_PRIORITYとThread.MAX_PRIORITYとの間の範囲。範囲外の場合、デフォルト値が使用されます。

max-concurrent-new-threads

MTFによって作成され、タスクのrun()メソッドを引き続き実行するスレッドの最大数。

いいえ

10

[0-65534]

範囲外の場合、デフォルト値が使用されます。

長時間実行スレッドのパーティション・レベルCMO制約

MESおよびMSESに発行された長時間実行タスクと、MTFのnewThread()メソッドの呼出しでは、自己チューニング・スレッド・プールの一部として管理されない新しいスレッドを作成する必要があります。実行中のスレッドの数が過大になると、サーバーのパフォーマンスと安定性に悪影響を与える可能性があるため、同時実行性ユーティリティAPIによって作成される実行中のスレッドの最大数を指定する構成が用意されています。

最大同時長時間実行リクエストの制限の設定

MESおよびMSESに発行される同時長時間実行リクエストの制限は、パーティションで指定できます。すべての構成レベルは独立しており、最大同時長時間実行リクエストはそれらのいずれも超えることはできません。

表19-6は、デプロイメント・ディスクリプタで定義できるmax-concurrent-long-running-requests要素を含む同時長時間実行リクエストの制限をまとめたものです。

表19-6 パーティションでの同時長時間実行リクエストの制限

スコープ

デプロイメント・ディスクリプタ

説明

<max-concurrent-long-running-requests>要素の詳細

パーティション

config.xml内:

一般的なパーティションでは、<domain><partition>のサブ要素として。グローバル・ランタイムでは、<domain>のサブ要素として。

そのサーバーのそのパーティションに指定された同時長時間実行リクエストの制限。

オプション

範囲: [0-65534]。範囲外の場合、デフォルト値が使用されます。

デフォルト値: 50

指定された制限を超えた場合、MESまたはMSESは、発行された新しい長時間実行タスクに対して次のアクションを実行します。

- タスク発行APIを呼び出すときにjava.util.concurrent.RejectedExecutionExceptionがスローされます。

- ユーザーがManagedTaskListenerを使用してタスクを登録している場合、発行メソッドが失敗しているためこのリスナーには通知されません。

前述の規則は、invokeAll()メソッドとinvokeAny()メソッドには適用されないことに注意してください。これらのメソッドによって発行されたいずれかのタスクが指定された制限によって拒否された場合、次のイベントが発生します。

- ユーザーが登録した管理対象タスク・リスナーのtaskSubmitted()メソッドが呼び出されます。

- ユーザーが登録した管理対象タスク・リスナーのtaskDone()メソッドが呼び出され、throwableParamがjavax.enterprise.concurrent.AbortedExceptionになります。

- その他の発行済タスクは影響を受けません。

- メソッドは、例外RejectedExecutionExceptionをスローしません。

次の例に、config.xmlファイル内のmax-concurrent-long-running-requests要素に指定された値が長時間実行リクエストの最大数にどのように影響する可能性があるかを示します。

<domain>
<server>
<name>myserver</server>
<max-concurrent-long-running-requests>50</max-concurrent-long-running-requests> (place 1)
</server>
<max-concurrent-long-running-requests>10</max-concurrent-long-running-requests> (place 2)
<partition>
<name>mypartition</name>
<max-concurrent-long-running-requests>5</max-concurrent-long-running-requests> (place 3)

</partition>
<server-template>
<name>mytemplate</name>
<max-concurrent-long-running-requests>50</max-concurrent-long-running-requests> (place 4)
</server-template>
</domain>

- place 1: サーバー・インスタンスmyserverで定義されているMESとMSESに影響します。そのサーバー・インスタンスで実行されているすべてのMESとMSESは、長時間実行リクエストを合計で最大50件のみ作成できます。

- place 2: ドメインで定義されるMESおよびMSESにのみ影響します。パーティション・レベルのMESとMSESには影響しません。ドメインで実行されているすべてのMESとMSESは、長時間実行リクエストを合計で最大10件作成できます。

- place 3: mypartitionで定義されているMESとMSESにのみ影響します。パーティションmypartitionで実行されているすべてのMESとMSESは、長時間実行リクエストを合計で最大5件作成できます。

- place 4: テンプレートmytemplateに適用されるサーバー・インスタンスで定義されているMESとMSESに影響します。そのサーバー・インスタンスで実行されているすべてのMESとMSESは、長時間実行リクエストを合計で最大50件のみ作成できます。

次の例に、config.xmlファイル内のmax-concurrent-long-running-requests要素に指定された値が長時間実行リクエストの最大数にどのように影響する可能性があるかを示します。

次の場合は、いずれの制限も超過しておらず、前述のアクションは実行されません。

- 120の長時間実行タスクがmanaged-executor-service1に発行され、それらのうち115は完了し、5つが実行中であると仮定すると、1つの長時間実行タスクがmanaged-executor-service1に追加で発行された場合、制限は超えていないため実行されます。

次の場合は、制限の1つを超過するため、前述のアクションが実行されます。

- 10の長時間実行タスクがmanaged-scheduled-executor-service1によって実行されていると仮定すると、1つの長時間実行タスクがmanaged-scheduled-executor-service1に追加で発行された場合、managed-scheduled-executor-service1の制限を超過します。

- 10の長時間実行タスクがapplication1によって実行され、40がapplication2によって実行されていると仮定すると、1つの長時間実行タスクがapplication1またはapplication2に追加で発行された場合、partition1の制限を超過します。

- 10の長時間実行タスクがapplication1によって実行され、30がapplication2によって実行され、60がpartition2によって実行されていると仮定すると、1つの長時間実行タスクがapplication1、application2またはpartition2に追加で発行された場合、server1の制限を超過します。

server1(100)
|---partition1(50)
|---application1
|---managed-scheduled-executor-service1(not specified)
|---module1
|---managed-executor-service1(20)
|---managed-scheduled-executor-service2(not specified)
|---application2
|---partition2(70)

最大同時新規スレッドの制限の設定

MTFのnewThread()メソッドを呼び出して作成された同時新規実行スレッドの制限は、管理対象オブジェクト、ドメインおよびサーバー・レベルで指定できます。すべての構成レベルは独立しており、最大同時新規実行スレッドはそれらのいずれも超えることはできません。

実行スレッドとは、MTFによって作成され、そのrun()メソッドがまだ完了していないスレッドであることに注意してください。

表19-7は、デプロイメント・ディスクリプタで定義できる要素<max-concurrent-new-threads>を含む同時新規実行スレッドの制限をまとめたものです。

表19-7 同時新規実行スレッドの制限

スコープ

デプロイメント・ディスクリプタ

説明

<max-concurrent-long-running-requests>要素の詳細

パーティション

config.xml内:

一般的なパーティションでは、<domain><partition>のサブ要素として。グローバル・ランタイムでは、<domain>のサブ要素として。

そのサーバーのそのパーティションに指定された同時新規実行スレッドの制限。

オプション

範囲: [0-65534]。範囲外の場合、デフォルト値が使用されます。

デフォルト値: 50

指定された制限を超えた場合、MTFのnewThread()メソッドへの呼出しでは、ThreadFactory.newThread Javadocに一致するようにnullを返します。

max-concurrent-new-threadsの使用方法のサンプルは、例19-*を参照してください。

パーティションCMOテンプレートの構成: 主な手順

WebLogic Server管理コンソールおよび構成MBeanを使用して、パーティションの構成でグローバルCMOをテンプレートとして定義できます。CMOテンプレートは、パーティション内の任意のアプリケーションまたはアプリケーション・コンポーネントに割り当てることができます。

注意:

マルチテナントのパーティション化されたドメインは、WebLogic Server Premium Editionでのみ使用できます。詳細は、LINK TO INTRO TO WEBLOGIC SERVER MTを参照してください。

パーティション内で次の3つのタイプのCMOテンプレートを定義できます。

- 管理対象エグゼキュータ・サービス

- 管理対象スケジュール済エグゼキュータ・サービス

- 管理対象スレッド・ファクトリ

たとえば、managed-executor-service-templateを定義している場合、パーティションにデプロイされた各アプリケーションに対して一意のMESインスタンスが作成されます。

管理コンソールでのパーティション・スコープCMOテンプレートの構成

CMOテンプレートは、WebLogic Server管理コンソールを使用してパーティションに構成およびスコープ指定することができます。

1. 「ドメイン構造」ツリーで、「環境」を展開し、「同時テンプレート」をクリックします。

2. 「新規」をクリックして、次のいずれかのテンプレート・オプションを選択します。

- 管理対象エグゼキュータ・サービス・テンプレート

- 管理対象スケジュール済エグゼキュータ・サービス・テンプレート

- 管理対象スレッド・ファクトリ・テンプレート

3. 新規テンプレートの作成ページで、必要に応じてテンプレートのプロパティを入力します。プロパティは、作成する同時テンプレートのタイプによって異なります。

- 「パーティション・レベルのMESテンプレート構成要素」を参照してください。

- 「パーティション・レベルのMSESテンプレート構成要素」を参照してください

- 「パーティション・レベルのMTFテンプレート構成要素」を参照してください。

4. 「次」をクリックします。

5. 同時テンプレートのターゲットとするパーティションを選択します。

選択したパーティションにデプロイされたアプリケーションのみがこの同時テンプレートを使用できます。

6. 「終了」をクリックします。「同時テンプレートのサマリー」ページが表示され、新しいパーティション・スコープの同時テンプレートがリストされます。

7. 必要に応じてその他の同時テンプレートを作成するには、これらの手順を繰り返します。

ドメインおよびサーバー・スコープのCMOテンプレートの構成の詳細は、『Oracle WebLogic Serverサーバー環境の管理』のグローバルCMOテンプレートに関する項を参照してください。

MBeanでのCMOテンプレートの構成

CMOテンプレートは、PartitionMBeanで次の構成MBeanを使用して構成できます。

- ManagedExecutorServiceTemplateMBean

- ManagedScheduledExecutorServiceTemplateMBean

- ManagedThreadFactoryTemplateMBean

詳細は、Oracle WebLogic Server MBeanリファレンスのPartitionMBeanに関する項を参照してください。

パーティションの同時制約の構成: 主な手順

制約についても、WebLogic Server管理コンソールおよび構成MBeanを使用してパーティション・スコープに対して定義できます。詳細は、次を参照してください。

- 管理コンソールでのパーティションの同時制約の構成

- MBeanでの同時制約の構成

管理コンソールでのパーティションの同時制約の構成

同時制約は、WebLogic Server管理コンソールを使用してパーティションごとに構成できます。

1. 「ドメイン構造」ツリーで、「ドメイン・パーティション」をクリックします。

2. 「ドメイン・パーティションのサマリー」表で、構成するパーティションを選択します。

3. 「partition-nameの設定」ページで、パーティションの「構成」→「同時実行性」ページを開きます

4. 次の同時制約オプションのいずれかまたはすべての値を指定します。

- 最大同時長時間実行リクエスト: パーティション・スコープですべての管理対象エグゼキュータ・サービスまたは管理対象スケジュール済エグゼキュータ・サービスに発行できる同時長時間実行リクエストの最大数。
「最大同時長時間実行リクエストの制限の設定」を参照してください。

- 最大同時新規スレッド: パーティション・スコープですべての管理対象スレッド・ファクトリによって作成可能な同時新規スレッドの最大数。
「最大同時新規スレッドの制限の設定」を参照してください。

5. 「保存」をクリックします。

MBeanでの同時制約の構成

同時制約は、PartitionMBeanで次のメソッドを使用して、パーティションごとに構成できます。

- maxConcurrentLongRunningRequests() - パーティション・スコープですべての管理対象エグゼキュータ・サービスまたは管理対象スケジュール済エグゼキュータ・サービスに発行できる同時長時間実行リクエストの最大数。
「最大同時長時間実行リクエストの制限の設定」を参照してください。

- maxConcurrentNewThreads() - パーティション・スコープですべての管理対象スレッド・ファクトリによって作成可能な同時新規スレッドの最大数。
「最大同時新規スレッドの制限の設定」を参照してください。

WebLogic Server MBeanの使用の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したWebLogic Server MBeanへのアクセスに関する項を参照してください。

パーティション・レベルCMOテンプレートのモニタリング

同時制約は、次の管理ツールを使用して問い合せることができます。

- 管理コンソールでのCMOテンプレートのモニタリング

- MBeanでのCMOテンプレートのモニタリング

管理コンソールでのCMOテンプレートのモニタリング

CMOテンプレートは、管理コンソールを使用してモニターできます。

CMOで作成されたスレッドをパーティションでモニターするには、次のようにします。

1. 「ドメイン構造」ツリーで、「ドメイン・パーティション」をクリックします。

2. 「ドメイン・パーティションのサマリー」表で、モニターするパーティションを選択します。

3. 「partition-nameの設定」ページで、「モニタリング」→「同時テンプレート」タブを選択します。
表では、パーティションにターゲット指定されているCMOテンプレートの構成情報を示します。

MBeanでのCMOテンプレートのモニタリング

パーティションのCMOテンプレートは、次のMBean属性からアクセスできるConcurrentManagedObjectsRuntimeMBeanを使用してモニターできます。

- PartitionRuntimeMBean.ConcurrentManagedObjectsRuntime - パーティションにターゲット指定されているCMOテンプレートの構成情報を示します。

『Oracle WebLogic Server MBeanリファレンス』のConcurrentManagedObjectsRuntimeMBeanに関する項を参照してください。

WebLogic Server MBeanの使用の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したWebLogic Server MBeanへのアクセスに関する項を参照してください。

パーティション同時管理対象オブジェクトの構成: 関連タスクおよびリンク

次の追加情報を参照してください。

- 『Oracle WebLogic Serverサーバー環境の管理』の同時管理対象オブジェクトの構成に関する項。

- CMO関連の構成およびランタイムMBeanの詳細は、『Oracle WebLogic Server MBeanリファレンス』のManagedExecutorServiceTemplateMBeanに関する項、ManagedScheduledExecutorServiceTemplateMBeanに関する項、ManagedThreadFactoryTemplateMBeanに関する項およびPartitionMBeanに関する項を参照してください。

- WLSTコマンドの使用の詳細は、『WebLogic Server WLSTコマンド・リファレンス』のオンラインおよびオフラインのWebLogic Server WLSTコマンド・リファレンスに関する項を参照してください。

- 『Oracle WebLogic Serverの理解』のサンプル・アプリケーションとコード例に関する項

- Java EE 7チュートリアルのJava EEの同時実行性ユーティリティに関する項

- 「Java Specification Request 236: Concurrency Utilities for Java EE 1.0」(http://jcp.org/en/jsr/detail?id=236)

20 パーティション・バッチ・ジョブ・ランタイムの構成

この章では、Oracle WebLogic Server Multitenant (MT)パーティションでバッチ・ジョブ・ランタイムを構成する方法について説明します。この章の説明に従い、Oracle WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して、パーティション・レベルのバッチ・ジョブ・ランタイムを構成できます。

- パーティション・バッチ・ジョブ・ランタイムの構成: 概要

- パーティション・バッチ・ジョブ・ランタイムの構成: 主な手順

- バッチ・ジョブ・ランタイムの問合せ

- パーティション・バッチ・ジョブ・ランタイムの構成: 関連タスクおよびリンク

パーティション・バッチ・ジョブ・ランタイムの構成: 概要

バッチ・ジョブは、ユーザー対話なしで実行できるタスクであり、非対話型でバルク指向の長時間実行タスクに最も適しています(これらのタスクは、リソース消費型で、順次実行またはパラレル実行が可能であり、動的に開始するか、スケジュールを使用して開始できます)。

WebLogic Serverでは、パーティションにスコープ指定されたバッチ・ジョブ・ランタイムがサポートされています。パーティションでバッチ・ジョブ・ランタイムを使用するには、バッチ・ジョブ用のジョブ・リポジトリ表にアクセスするために、パーティションごとに専用のデータ・ソースを構成する必要があります。パーティションにデプロイされたJava EEコンポーネントがバッチ・ジョブを発行すると、バッチ・ジョブ・ランタイムがこのデータ・ソースを使用してジョブ・リポジトリ表を更新します。

オプションで、ドメイン・レベルでパーティションにスコープ指定された管理対象エグゼキュータ・サービス(MES)テンプレートを構成することによって、アプリケーション・スコープのMESを使用するように、バッチ・ジョブ・ランタイムを構成できます。MESによってジョブが非同期的に処理されて、ジョブ・リポジトリ・データ・ソースに現在および過去のジョブのステータスが格納されます。ただし、パーティションをターゲットにしているMESテンプレートがない場合、バッチ・ジョブ・ランタイムは、Java EE 7の仕様に従って、デフォルトのJNDI名(java:comp/DefaultManagedExecutorService)にバインドされたMESを使用します。

ジョブ・リポジトリ表の作成手順など、ドメイン・スコープのバッチ・ジョブ・ランタイムの構成および管理の詳細は、『Oracle WebLogic Serverサーバー環境の管理』のバッチ・ジョブ・ランタイムの構成に関する項を参照してください。

バッチ・ジョブ、バッチ処理およびバッチ処理フレームワークの詳細は、Java EE 7チュートリアルのバッチ処理に関する項を参照してください。「Java Specification Request 352: Batch Applications for the Java Platform」(http://jcp.org/en/jsr/detail?id=352)も参照してください。仕様により、バッチ・アプリケーションのプログラミング・モデルと、バッチ・ジョブのスケジュールおよび実行のランタイムが定義されます。

パーティション・バッチ・ジョブ・ランタイムの構成: 主な手順

パーティションでバッチ・ジョブ・ランタイムを構成するには、次の手順を実行する必要があります。

- 必要に応じて、バッチ・ジョブを格納するジョブ・リポジトリ表を作成します。

- パーティションのJDBCデータ・ソースを構成します。

- オプションで、MESテンプレートを作成し、そのターゲットとしてパーティションを指定します。

- WebLogic Server管理コンソールまたはWLSTを使用して、パーティション・バッチ・ジョブ・ランタイムを構成します。

前提条件

パーティションでバッチ・ジョブ・ランタイムを構成するには、ドメイン・レベルで次の前提条件を満たす必要があります。

- ジョブ・リポジトリ表がすでに存在する必要があります。バッチ・ジョブ・ランタイムによって、ジョブ・リポジトリ表が自動的に作成されることはありません。パーティションをアクティブ化する前に、データベース管理者が表を作成する必要があります。
ジョブ・リポジトリ表の構成の詳細は、『Oracle WebLogic Serverサーバー環境の管理』のバッチ・ジョブ・ランタイムの構成に関する項を参照してください。

ジョブ・リポジトリ表を格納するためのサポートされているデータベースの詳細は、Oracle Technology NetworkにあるOracle Fusion Middlewareのサポートされるシステム構成ページを参照してください。

- パーティションのJDBCデータ・ソースを構成します。各パーティションに、バッチ・ジョブ用に作成された専用のJDBCデータ・ソースが必要です。バッチ・データ・ソースのJNDI名は、PartitionMBean.setBatchJobsDataSourceJndiNameを使用して設定する必要があります。Java EEコンポーネントがバッチ・ジョブを発行すると、バッチ・ジョブ・ランタイムは、データ・ソースのJNDI名の参照により取得されるこのデータ・ソースを使用してジョブ・リポジトリ表を更新します。
JDBCデータ・ソースの構成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの作成に関する項を参照してください。

- オプションで、MESテンプレートを作成します。最適なパフォーマンスを得るために、ドメイン・レベルでパーティションにスコープ指定されたMESテンプレートを構成することによって、アプリケーション・スコープのMESを使用するように、パーティションのバッチ・ジョブ・ランタイムを構成できます。これにより、MESテンプレートごとに新しいMESインスタンスが作成され、パーティションにデプロイされたJava EEコンポーネントに対して発行されるバッチ・ジョブが実行されます。
ただし、名前が設定されていない場合、バッチ・ジョブ・ランタイムは、デフォルトのJNDI名(java:comp/DefaultManagedExecutorService)にバインドされたデフォルトのJava EE MESを使用します。

MESテンプレートの構成の詳細は、『Oracle WebLogic Serverサーバー環境の管理』のグローバルCMOテンプレートに関する項を参照してください。

管理コンソールを使用したパーティション・バッチ・ジョブ・ランタイムの構成

WebLogic Server管理コンソールを使用して、パーティションごとに専用のバッチ・ジョブ・ランタイムを構成できます。「partition-nameの設定」ページで、パーティションの「構成」→「一般」ページを開き、次の構成フィールドを入力します。

- エグゼキュータ・サービス・テンプレート: パーティションにデプロイされたアプリケーションから発行されるバッチ・ジョブの実行に使用されるアプリケーション・スコープのMESインスタンスの名前。
パーティションにバッチ・ジョブを発行する場合は、同じ名前のMESテンプレートが存在し、パーティションにスコープ指定されている必要があります。名前が設定されていない場合、バッチ・ジョブ・ランタイムは、デフォルトのJNDI名(java:comp/DefaultManagedExecutorService)にバインドされたデフォルトのJava EE MESを使用します。

- データソースJNDI名: パーティションにデプロイされたアプリケーションから発行されるバッチ・ジョブのデータを格納するために使用される、バッチ・ジョブ・ランタイムのデータ・ソースのJNDI名。Java EEコンポーネントがバッチ・ジョブを発行すると、バッチ・ジョブ・ランタイムは、データ・ソースのJNDI名の参照により取得されるこのデータ・ソースを使用してバッチ・ジョブ・リポジトリ表を更新します。

パーティション・バッチ・ジョブ・ランタイムの構成: WLSTの例

WLSTを使用して、パーティションごとに専用のバッチ・ジョブ・ランタイムを構成できます。

WLSTでBatchRuntimeConfigMBeanとPartitionMBeanを使用して、ジョブ・リポジトリに特定のデータベースを使用するようにバッチ・ジョブ・ランタイムを構成できます。

def update_partition_batch_config(partitionName, jndiName, schemaName):
connect('admin','passwd')
edit()
startEdit()
cd('/Partitions/' + <partitionName>)
cmo.setDataSourceJndiName(jndiName)
cd('/BatchConfig/')
cmo.setSchemaName(schemaName)
save()
activate()

この例では、管理者がJNDI名jdbc/batchDSを使用してデータ・ソースを作成している場合に、update_partition_batch_config('<partitionName>','jdbc/batchDS','BATCH')を呼び出すと、jndiName: 'jdbc/batchDS'にバインドされたデータ・ソースで指定されたデータベースのスキーマ'BATCH'にすべてのジョブ・リポジトリ表を格納するようにバッチ・ジョブ・ランタイムが構成されます。

WLSTを使用して、バッチ・ジョブの実行に特定のMESを使用するようにバッチ・ジョブ・ランタイムを構成できます。ただし、まずMESテンプレートをドメイン・レベルで作成し、MESの名前をPartitionMBeanに指定する必要があります。

connect('admin','passwd')
edit()
startEdit()
cd('/Partitions'/ + <partitionName>)
cmo.setBatchJobsExecutorServiceName('mesName')
save()
activate()

mesNameは、このパーティションに対してすでに作成(およびターゲットが指定)されたMESテンプレートの名前です。

PartitionMBeanでgetBatchJobsManagedExecutorServiceName()メソッドを使用して、異なるMESを使用するようにバッチ・ジョブ・ランタイムを構成できます。ただし、バッチ・ジョブを発行する場合は、同じ名前のMESテンプレートが存在し、パーティションにスコープ指定されている必要があります。

詳細は、Oracle WebLogic Server MBeanリファレンスのBatchConfigMBeanに関する項およびPartitionMBeanに関する項を参照してください。

WLSTコマンドの使用の詳細は、『WebLogic Server WLSTコマンド・リファレンス』のオンラインおよびオフラインのWebLogic Server WLSTコマンド・リファレンスに関する項を参照してください。

バッチ・ジョブ・ランタイムの問合せ

次の管理ツールを使用して、パーティション・スコープごとにバッチ・ジョブ・ランタイムのジョブ・リポジトリ表を問い合せることができます。

- 管理コンソールを使用したバッチ・ジョブ・ランタイムの問合せ

- ランタイムMBeanを使用したバッチ・ジョブ・ランタイムの問合せ

注意:

バッチ・ジョブ・リポジトリが格納されるデータベースが実行中であることを確認します。たとえば、デフォルトのDerbyデータベースは、java weblogic.Serverコマンドを使用してWebLogic Serverを起動したときに自動的に起動されることはありません。データベースが実行されていない場合は、バッチ・ジョブを発行したときか、WLSTまたはWebLogic Server管理コンソールを使用してBatchJobRepositoryRuntimeMBeanにアクセスしたときに、例外がスローされます。

管理コンソールを使用したバッチ・ジョブ・ランタイムの問合せ

WebLogic Server管理コンソールを使用してジョブ・リポジトリ表を問い合せて、パーティション内のバッチ・ジョブの詳細を取得できます。

すべてのバッチ・ジョブの詳細の取得

パーティションにデプロイされたアプリケーションによって発行されるすべてのジョブに関する詳細を表示するには、「partition-nameの設定」ページで、「モニタリング」→「バッチ・ジョブ」ページに移動します。詳細は、表20-1を参照してください。

表20-1 すべてのバッチ・ジョブ

要素名

説明

Job Name

バッチ・ジョブの名前。

Application Name

バッチ・ジョブを発行したアプリケーションの名前。

Instance ID

インスタンスID。

Execution ID

実行ID。

Batch Status

このジョブのバッチ・ステータス。

Start Time

ジョブの開始時刻。

End Time

ジョブの完了時刻。

Exit Status

ジョブの終了ステータス。

ジョブの実行に関する詳細の取得

ジョブのステップ実行の詳細は、それを選択して「表示」をクリックすることで表示できます。詳細は、表20-2を参照してください。

表20-2 ジョブ実行の詳細

要素名

説明

Job Name

バッチ・ジョブの名前。

Instance ID

インスタンスID。

Execution ID

実行ID。

Batch Status

このジョブのバッチ・ステータス。

Start Time

ジョブの開始時刻。

End Time

ジョブの完了時刻。

Exit Status

ジョブの終了ステータス。

ジョブのステップ実行に関する詳細の取得

ジョブ実行の各ステップに関するメトリックは、それを選択して「表示」をクリックすることで表示できます。詳細については、表20-3を参照してください。

表20-3 ステップ実行の詳細

要素名

説明

Step Name

バッチ・ジョブ・ステップの名前。

Step ID

ステップID。

Execution ID

実行ID。

Batch Status

このジョブのバッチ・ステータス。

Start Time

ジョブの開始時刻。

End Time

ジョブの完了時刻。

Exit Status

ジョブの終了ステータス。

ランタイムMBeanを使用したバッチ・ジョブ・ランタイムの問合せ

WLSTでBatchJobRepositoryRuntimeMBeanを使用してジョブ・リポジトリ表を問い合せて、パーティション内のバッチ・ジョブの詳細を取得できます。

詳細は、『Oracle WebLogic Server MBeanリファレンス』のBatchJobRepositoryRuntimeMBeanに関する項を参照してください。

getJobDetailsを使用したすべてのバッチ・ジョブの詳細の取得

getJobDetails()属性により、ドメインにデプロイされたアプリケーションによって発行されるすべてのジョブに関する詳細が返されます。コレクションの各エントリには、表20-4に示す要素の配列が含まれます。

表20-4 getJobDetails()属性の要素

要素名

説明

JOB_NAME

バッチ・ジョブの名前。

APP_NAME

バッチ・ジョブを発行したアプリケーションの名前(String)。

INSTANCE_ID

インスタンスID (long)。

EXECUTION_ID

実行ID (long)。

BATCH_STATUS

このジョブのバッチ・ステータス(String)。

START_TIME

ジョブの開始時刻(java.util.Date)。

END_TIME

ジョブの完了時刻(java.util.Date)。

EXIT_STATUS

ジョブの終了ステータス(String)。

次のWLSTスクリプトの例では、getJobDetails()コマンドを使用して、ドメインにデプロイされたすべてのバッチ・ジョブのリストを出力しています。

connect('admin', 'admin123')
domainRuntime()
cd('BatchJobRepositoryRuntime')
cd('myserver')
executions=cmo.getJobDetails()
print "JobName  AppName   InstanceID  ExecutionID  BatchStatus  StartTime  EndTime  ExitStatus"
print e[0], " ", e[1], " ", e[2], "   ", e[3], "   ", e[4], "  ", e[5], " ", e[6], ",e[7]

次に、getJobDetails()の実行後のサンプル出力を示します。

JobName   AppName InstanceID  ExecutionID   BatchStatus       StartTime                      EndTime                   ExitStatus
PayrollJob     lab1   9           9         COMPLETED   Fri Apr 24 10:11:00 PDT 2015   Fri Apr 24 10:11:01 PDT 2015   COMPLETED
PayrollJob     lab1   8           8         COMPLETED   Fri Apr 24 10:11:00 PDT 2015   Fri Apr 24 10:11:01 PDT 2015   COMPLETED
PayrollJob     lab1   7           7         COMPLETED   Fri Apr 24 10:11:00 PDT 2015   Fri Apr 24 10:11:01 PDT 2015   COMPLETED
PayrollJob     lab1   6           6         COMPLETED   Fri Apr 24 10:11:00 PDT 2015   Fri Apr 24 10:11:01 PDT 2015   COMPLETED
PayrollJob     lab1   5           5         COMPLETED   Fri Apr 24 10:10:57 PDT 2015   Fri Apr 24 10:10:58 PDT 2015   COMPLETED
PayrollJob     lab1   4           4         COMPLETED   Fri Apr 24 10:10:56 PDT 2015   Fri Apr 24 10:10:56 PDT 2015   COMPLETED
PayrollJob     lab1   3           3         COMPLETED   Mon Apr 20 11:32:12 PDT 2015   Mon Apr 20 11:32:12 PDT 2015   COMPLETED
PayrollJob     lab1   2           2         COMPLETED   Mon Apr 20 11:32:10 PDT 2015   Mon Apr 20 11:32:11 PDT 2015   COMPLETED
PayrollJob     lab1   1           1         COMPLETED   Mon Apr 20 11:25:26 PDT 2015   Mon Apr 20 11:25:26 PDT 2015   COMPLETED

getJobExecutionsを使用したジョブ実行の詳細の取得

getJobExecutions属性により、特定のジョブ実行に関する詳細が返されます。コレクションの各エントリには、表20-5に示す要素の配列が含まれます。

表20-5 getJobExecutions()属性の要素

要素名

説明

JOB_NAME

バッチ・ジョブの名前(String)。

INSTANCE_ID

インスタンスID (long)。

EXECUTION_ID

実行ID (long)。

BATCH_STATUS

このジョブのバッチ・ステータス(String)。

START_TIME

ジョブの開始時刻(java.util.Date)。

END_TIME

ジョブの完了時刻(java.util.Date)。

EXIT_STATUS

ジョブの終了ステータス(String)。

次の例では、WLSTスクリプトでgetJobExecutions()コマンドを使用して、特定の実行IDの詳細を取得します(getJobExecutions(6))。すべての実行IDのリストを取得するには、getJobDetails()メソッドを使用します。

connect('admin', 'admin123')
partitionRuntime()
cd('BatchJobRepositoryRuntime')
cd('myserver')
executions=cmo.getJobExecutions(6)
print  "JobName    InstanceID   ExecutionID   BatchStatus   StartTime   EndTime    ExitStatus"
for e in executions
print e[0], "  ", e[1], "    ", e[2], "    ", e[3], "    ", e[4], "  ", e[5], "  ", e[6]

次に、getJobExecutions()の実行後のサンプル出力を示します。

JobName   InstanceID  ExecutionID   BatchStatus       StartTime                      EndTime                   ExitStatus
PayrollJob     6           6         COMPLETED   Fri Apr 24 10:11:00 PDT 2015   Fri Apr 24 10:11:01 PDT 2015    COMPLETED

getStepExecutionsを使用したジョブ・ステップ実行の詳細の取得

getStepExecutions属性により、ジョブ実行の各ステップに関するメトリックが返されます。コレクションの各エントリには、表20-6に示す要素の配列が含まれます。

表20-6 getStepExecutions()属性の要素

要素名

説明

STEP_NAME

バッチ・ジョブ・ステップの名前(String)。

STEP_ID

ステップID (long)。

EXECUTION_ID

実行ID (long)。

BATCH_STATUS

このジョブのバッチ・ステータス(String)。

START_TIME

ジョブの開始時刻(java.util.Date)。

END_TIME

ジョブの完了時刻(java.util.Date)。

EXIT_STATUS

ジョブの終了ステータス(String)。

次に、特定のステップ実行IDの詳細を取得するためにWLSTスクリプトでgetStepExecutions()を使用する例(getStepExecutions(6))を示します。すべての実行IDのリストを取得するには、getJobDetails()メソッドを使用します。

connect('admin', 'admin123')
partitionRuntime()
cd('BatchJobRepositoryRuntime')
cd('myserver')
executions=cmo.getStepExecutions(6)
print  "StepName   StepExecutionID   BatchStatus    StartTime    EndTime    ExitStatus"
print e[0], "     ", e[1], "      ", e[2], "     ", e[3], " ", e[4], "   ", e[5], "]

次に、getStepExecutions()の実行後のサンプル出力を示します。

StepName   StepExecutionID  BatchStatus       StartTime                      EndTime                   ExitStatus
PayrollJob     6           6         COMPLETED   Fri Apr 24 10:11:00 PDT 2015   Fri Apr 24 10:11:01 PDT 2015    COMPLETED

パーティション・バッチ・ジョブ・ランタイムの構成: 関連タスクおよびリンク

次の追加情報を参照してください。

- 『Oracle WebLogic Serverサーバー環境の管理』のバッチ・ジョブ・ランタイムの構成に関する項。

- 管理対象エグゼキュータ・サービス・テンプレートの構成の詳細は、『Oracle WebLogic Serverサーバー環境の管理』のグローバルCMOテンプレートに関する項を参照してください。

- JDBCデータ・ソースの構成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの作成に関する項を参照してください。

- バッチ関連の構成およびランタイムMBeanの詳細は、Oracle WebLogic Server MBeanリファレンスのBatchConfigMBeanに関する項、BatchJobRepositoryRuntimeMBeanに関する項およびPartitionMBeanに関する項を参照してください。

- WLSTコマンドの使用の詳細は、『WebLogic Server WLSTコマンド・リファレンス』のオンラインおよびオフラインのWebLogic Server WLSTコマンド・リファレンスに関する項を参照してください。

- 『Oracle WebLogic Serverの理解』のサンプル・アプリケーションとコード例に関する項

- Java EE 7チュートリアルのバッチ処理に関する項

- 「Java Specification Request 352: Batch Applications for the Java Platform」(http://jcp.org/en/jsr/detail?id=352)

21 リソース・アダプタの構成

この章では、Oracle WebLogic Server Multitenant (MT)でリソース・アダプタ(コネクタ)を構成する方法について説明します。

この章の内容は次のとおりです。

- ドメイン・パーティションでのリソース・アダプタの構成: 概要

- ドメイン・パーティションでリソース・アダプタを使用する際のベスト・プラクティスおよび考慮事項

ドメイン・パーティションでのリソース・アダプタの構成: 概要

Oracle WebLogic Server Multitenantを使用すると、リソース・グループおよびリソース・グループ・テンプレートを介して、スタンドアロンおよび埋込みのリソース・アダプタをドメイン・パーティションにデプロイできます。アプリケーションのデプロイの詳細は、「アプリケーションのデプロイ」を参照してください。

リソース・アダプタがパーティションにデプロイされると、そのすべてのリソース(リソース・アダプタBean、接続プール、管理対象オブジェクトなど)はパーティションのJNDIネームスペースに登録され、JNDI名およびクラス・ローダーは、他のパーティションのアプリケーションから分離されます。このため、同じパーティション内のアプリケーションのみが、リソース・アダプタが提供するサービスにアクセスでき、同じパーティション内のアプリケーションのみがリソース・アダプタのクラスにアクセスできます。

リソース・アダプタがドメインにデプロイされると、そのすべてのリソース・アダプタBean、接続プールおよび管理対象オブジェクトは、ドメインのJNDIネームスペースに登録されます。これらのリソースは、ドメインにデプロイされたアプリケーションでのみ表示可能です。

ドメイン・レベルのリソース・アダプタのconfig.xmlの例

リソース・アダプタをリソース・グループ・テンプレートに構成し、それをパーティションのリソース・グループで参照できます。

この例では、スタンドアロン・リソース・アダプタはリソース・グループ・テンプレートに定義されます。2つのパーティション(HRおよびFinance)はそれぞれ、リソース・グループ・テンプレートからアプリケーションおよびリソースを継承するリソース・グループを定義します。この場合、各パーティションには独自のリソース・アダプタがあります。

<domain>
...
<resource-group-template>
<name>RGT1</name>
<app-deployment>
<name>my_ra</name>
<module-type>rar</module-type>
<source-path>/some/directory/mail-connector.rar</source-path>
<deployment-order>120</ deployment-order >
...
</app-deployment>
...
</resource-resource-template>

<partition>
<name>HR</name>
<resource-group>
<name>RG1</name>
<resource-group-template>RGT1</resource-group-template>
</resource-group>
...
</partition>
<partition>
<name>Finance</name>
<resource-group>
<name>RG2</name>
<resource-group-template>RGT1/resource-group-template>
</resource-group>
...
</partition>
...
</domain>

パーティション・レベルのリソース・アダプタのconfig.xmlの例

この例では、ドメインに定義された2つのパーティション(HRおよびFinance)があります。HRパーティションには、スタンドアロン・リソース・アダプタを定義するリソース・グループがあります。この場合、 HRパーティションにデプロイされたリソース・アダプタは、Financeパーティションでは非表示になります。

<domain>
...
<partition>
<name>HR</name>
<resource-group>
<name>HR Apps and Resources</name>
<app-deployment>
<name>mailra</name>
<module-type>rar</module-type>
<source-path>/some/directory/mail-connector.rar</source-path>
<deployment-order>120</ deployment-order >
...
</app-deployment>
...

</resource-group>
</partition>

<partition>
<name>Finance</name>
...
</partition>
...
</domain>

ドメイン・パーティションでリソース・アダプタを使用する際のベスト・プラクティスおよび考慮事項

この項では、マルチテナント環境でリソース・アダプタを開発するシステム管理者のベスト・プラクティスおよび考慮事項について説明します。

パーティション・レベルのリソース・アダプタのクラス・ロード動作の定義

パーティション・レベルのスタンドアロン・リソース・アダプタは、パーティション・クラス・ローダー(ドメイン/libクラス・ローダーのサブ・クラス・ローダー)およびパーティションのすべてのアプリケーション・クラス・ローダーの親によってロードされます。

weblogic-ra.xmlデプロイメント・ディスクリプタの<enable-global-access-to-classes>要素は、パーティションのリソース・アダプタ・クラスのクラス・ロード動作を決定します。

詳細は、『Oracle WebLogic Serverリソース・アダプタの開発』のweblogic-ra.xmlスキーマに関する項を参照してください。

- <enable-global-access-to-classes>がfalseに設定された場合、パーティション・リソース・アダプタ・クラスのクラス・ロード動作は、ドメイン・レベルのリソース・アダプタ・クラスの場合の動作と同じです。

- <enable-global-access-to-classes>がtrueに設定された場合、次のようになります。

- リソース・アダプタがドメインにデプロイされると、リソース・アダプタ・クラスは、ドメイン・クラス・ローダーによってロードされます。そのため、リソース・アダプタ・クラスは、他のパーティションのアプリケーションから分離されます。

- リソース・アダプタがパーティションにデプロイされると、リソース・アダプタ・クラスは、パーティション・クラス・ローダーによってロードされます。そのため、リソース・アダプタ・クラスは、ドメイン・パーティションおよび他のパーティションのアプリケーションから分離されます。

パーティションのアプリケーション構成のオーバーライド

各パーティションは、リソース・グループ・テンプレートで定義された構成をオーバーライドするために使用できるデプロイメント・プランを指定できます。リソース・アダプタ・アプリケーションは、デプロイメント時にこのデプロイメント・プランを適用する必要があります。

詳細は、「アプリケーション構成のオーバーライド」を参照してください。

AppDeploymentConfigMBeanのplan-path属性を使用してアプリケーション・レベルでデプロイメント・プラン・ファイルを指定して、リソース・アダプタの構成をオーバーライドできます。パーティションのリソース・グループがリソース・グループ・テンプレートのリソース・アダプタを参照する場合、アプリケーション・レベルで指定したデプロイメント・プランのマクロ置換を使用して、リソース・グループ構成をオーバーライドできます。次の例は、デプロイメント・プランのファイル名のマクロを使用したリソース・グループ・テンプレートを示しています。2つのパーティション(HRおよびFinance)があります。

<domain>
<resource-group-template>
<name>RGT1</name>
<app-deployment>
<name>mailra</name>
<name>my_ra</name>
<module-type>rar</module-type>
<source-path>/some/directory/sample_connector.rar</source-path>
<deployment-order>120</ deployment-order >
<plan-path>${MYRA-PLAN-FILE}</plan-path>
</app-deployment>
...
</resource-group-template>

<partition>
<name>HR</name>
<resource-group>
<name>RG1</name>
<resource-group-template>RGT1</resource-group-template>
</resource-group>
<partition-properties>
<partition-property>
<name>MYRA-PLAN-FILE</name>
<value>/apps/plans/hr/my_ra-plan.xml</value>
</partition-property>
</partition-properties>
...
</partition>

<partition>
<name>Finance</name>
<resource-group>
<name>RG2</name>
<resource-group-template>RGT1</resource-group-template>
</resource-group>
<partition-properties>
<partition-property>
<name>MYRA-PLAN-FILE</name>
<value>/apps/plans/Finance/my_ra-plan.xml</value>
</partition-property>
</partition-properties>
...
</partition>
</domain>

リソース・アダプタのリソース定義の考慮事項

@ConnectorResourceDefinitionおよび@AdministeredObjectDefinition注釈を使用して、Webモジュール、EJBモジュール、または同等のアプリケーション・デプロイメント・ディスクリプタで、リソース・アダプタのリソースを定義できます。これらの注釈を使用すると、マルチテナント環境で次の条件が該当します。

- @ConnectorResourceDefinitionおよび@AdministeredObjectDefinitionまたは同等のデプロイメント・ディスクリプタがドメイン・レベルのアプリケーションで定義された場合、関連するリソース・アダプタはドメイン・レベルでデプロイされる必要があります。

- @ConnectorResourceDefinitionおよび@AdministeredObjectDefinitionまたは同等のデプロイメント・ディスクリプタがパーティション・レベルのアプリケーションで定義された場合、関連するリソース・アダプタは同じパーティションでデプロイされる必要があります。

リソース・グループ移行およびリソース・アダプタ

スタンドアロン・リソース・アダプタは、同じパーティションのリソース・グループで共有されます。これはリソース・グループで定義できますが、そのリソース・グループによって排他的に占有されることはありません。リソース・グループRG1が、リソース・グループRG2で定義されたスタンドアロン・リソース・アダプタRA2に依存していると仮定した場合、RG2が新しいクラスタに移行されると、RG1は同時にそのクラスタに移行される必要があります。それ以外の場合、RG1は機能しません。

リソース・グループ移行を行う場合、1つのリソース・アダプタと関連するすべてのアプリケーションを同じリソース・グループで定義することをお薦めします。

22 パーティションのエクスポートおよびインポート

この章では、Oracle WebLogic Server Multitenant (MT)でパーティションをエクスポートおよびインポートする方法について説明します。この章の説明に従い、Oracle Enterprise Manager Fusion Middleware Control (FMWC)、Oracle WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)のいずれかを使用して、パーティションをエクスポートおよびインポートできます。この章では、適宜追加情報について、Oracle Fusion MiddlewareとWebLogic Serverのドキュメント・セットおよびオンラインを参照します。

この章には次の項が含まれます:

- ドメイン・パーティションのエクスポートおよびインポート: 概要

- ドメイン・パーティションのエクスポートおよびインポート: 主な手順およびWLSTの例

- ドメイン・パーティションのエクスポートおよびインポート: 関連タスクおよびリンク

ドメイン・パーティションのエクスポートおよびインポート: 概要

システム管理者は、WLST (オンラインまたはオフライン)、Representational State Transfer (REST) API (オンラインのみ)またはWebLogic Server管理コンソール(オンラインのみ)を使用して、ドメイン・パーティションをエクスポートし、すでにエクスポートしたパーティションを別のドメインにインポートできます。

パーティションをエクスポートおよびインポートすると、あるドメインから別のドメインにパーティションを簡単に移動できます(パーティションにデプロイされたアプリケーションを含む)。この機能は、ドメイン間でのパーティションのレプリケート、および開発環境から本番環境へのドメインの移動に役立ちます。

パーティションのエクスポートについて

パーティションがソース・ドメインからエクスポートされるとき、次のものがパーティション・アーカイブ・ファイルとしてパッケージ化されます。

- パーティション構成

- パーティションに含まれるすべてのリソース・グループ

- これらのリソース・グループによって参照されるすべてのリソース・グループ・テンプレート

- パーティションのファイル・システムのコンテンツ、<partition-file-system>/configディレクトリ

- オプションで、パーティションにデプロイされたアプリケーションのアプリケーション・バイナリ・ファイルおよび構成

アプリケーション・ランタイムの状態およびアプリケーション固有のランタイム構成は、パーティション・アーカイブ・ファイルには含まれません。他には、キュー内のJMSメッセージ、組込みLDAPレルム内のユーザーなどがエクスポートされません。

パーティション・アーカイブ・ファイルの作成

WLSTのexportPartitionコマンドを使用して、パーティション・アーカイブ・ファイル(<PartitionName.zip)を作成できます。これは、パーティションの構成および(オプションで)パーティションのアプリケーションとライブラリをアーカイブ・ファイルにコピーします。このコマンドによって、インポート時にパーティションの構成を変更するために使用できるattributes.jsonファイルも作成されます。

コマンドの構文は次のようになります。

exportPartition(partitionName, expArchPath, [includeAppsNLibs], [keyFile])

partitionNameはエクスポートするパーティションの名前、expArchPathはパーティション・アーカイブ・ファイルを保存するディレクトリへのフルパス、includeAppsNLibs (オプション)はアプリケーションおよびライブラリのバイナリ・ファイルをパーティション・アーカイブ・ファイルに含めるかどうかを指定し、keyFile (オプション)はパーティション・アーカイブ・ファイル内の属性を暗号化するための暗号化鍵として使用する文字列を含むファイルへのフルパスを指定します。「ドメイン・パーティションのエクスポート: WLSTの例」を参照してください。

パーティション・アーカイブ・ファイルのコンテンツ

パーティション・アーカイブは、次の特定のパーティション関連ファイルを含む.zipファイルです。

ファイルおよびディレクトリ

説明

partition-config.xml

config.xmlのパーティション構成およびリソース・グループ・テンプレート構成が含まれます。

MANIFEST.MF

アーカイブ・ファイルのタイムスタンプおよびドメイン情報が含まれます。

<PartitionName>-attributes.json

パーティションのインポート中に管理者が変更できるMBean属性およびプロパティが含まれます。アーカイブ・ファイルに含まれる以外に、このファイルのコピーは更新を簡易化するためにファイル・システムのアーカイブ・ファイルにも配置されます。

expPartSecret

暗号化および暗号化された属性の復号化に使用される暗号化された秘密鍵が含まれます。

domain/config/resource-group-templates/<resource_template_name>/*

このパーティションに関連付けられているリソース・グループ・テンプレートに関連するファイルが含まれます。

domain/config/partitions/<partition-name>/*

domain/config/partitions/<partition-name>/config/*にある構成ファイルを指します。

pfs/config/*

<partition-file-system>/config ディレクトリのコンテンツが含まれます。これには、システム・リソース(JMS、JDBCなど)のディスクリプタ・ファイルも含まれます。

domain/upload/resource-group-templates/<resource_template_name>/<application_name>/

リソース・グループ・テンプレート・レベルのバイナリ・ファイルが含まれます。

pfs/upload/<application_name>/

リソース・グループ・レベルのアプリケーション・バイナリ・ファイルが含まれます。

パーティションのインポートについて

パーティションをインポートする前提条件として、サーバー・インスタンスにドメインが構成されている必要があります。パーティションを新しいドメインにインポートする場合は、新たにインポートされたパーティションが認識されるように、一部の外部システムを構成することが必要となることがあります。パーティション・アーカイブ・ファイルのインポート中に、システム管理者は、ドメイン(仮想ターゲット、セキュリティ・レルムおよびリソース・グループ・テンプレートなど)での依存性を更新し、オプションで、パーティション構成の他の属性(パーティション・プロパティ、JDBC、JMSおよびリソース・グループ内の他のリソースなど)も更新して有効にする必要がある場合があります。また、新しいパーティションにアプリケーションおよびシステム・リソースをデプロイする必要があります。

システム管理者は、インポート処理の実行中に、ターゲット・ドメインに適するように属性が変更された<PartitionName>-attributes.jsonファイルを指定して、パーティション構成の特定の部分をオーバーライドできます。ただし、name属性の値の変更はサポートされていません。たとえば、次のサンプル<PartitionName>-attributes.jsonの"name" : "P1"は変更できません。

{
"partition" : {
"name" : "P1",
"jdbc-system-resource-override" : {
"URL" : "url.com",
"Id" : "0",
"name" : "test123",
"CachingDisabled" : "false",
"Registered" : "false",
"User" : "test123",
"DynamicallyCreated" : "false",
"DataSourceName" : "test-source"
},
"resource-group-template" : {
"name" : "RGT1",
"jdbc-system-resource" : {
"name" : "jdbc1",
"descriptor-file-name" : "jdbc/P1DB1-8882-jdbc.xml"
}

"jms-server-resource" : {
"name" : "jms1",
"PagingDirectory" : ""
}

}
}

前述の例では、すべてのJDBCSystemResourceOverrideMBean属性は、現在の値とともに<PartitionName>-attributes.jsonファイルにコピーされます。

リソース・グループ・テンプレートがすでにターゲット・ドメインに存在する場合、createNewオプションを使用して、既存のリソース・グループ・テンプレートを上書きし、新しい名前で新しいリソース・グループ・テンプレートを作成する必要があります。(「ドメイン・パーティションのインポート: 主な手順」の手順2を参照してください。)

アプリケーションのエクスポートおよびインポート

パーティションがエクスポートされる場合は、エクスポート処理のincludeAppsオプションの値によって、アプリケーション・バイナリ・ファイルがパーティション・アーカイブ・ファイルに含まれるかどうかが判断されます。includeAppsがtrueの場合は、バイナリ・ファイルが含まれます。falseの場合は、除外されます。<PartitionName>-attributes.jsonファイルには、アプリケーションまたはライブラリのソース・パス、デプロイメント・プランのパスおよびステージング・モードの属性が含まれます。これらの属性は、<PartitionName>-attributes.jsonファイルで変更できます。

includeAppsオプションは、アプリケーションのインポート時のデプロイ方法にも影響します。

- true (デフォルト)の場合、リソース・グループ・テンプレート・レベルのアプリケーションかリソース・グループ・レベルのアプリケーションかに応じて、デプロイメント・ファイルは<domain-dir>/<server>/uploadまたは<partition-dir>/<server>/uploadにコピーされ、元のステージング・モードを使用してデプロイされます。ステージング・モードがNOSTAGEまたはEXTERNAL (ターゲット・サーバー上)の場合、システム管理者は、ターゲット・ドメインの正しい場所からアプリケーションを使用できるようにする必要があります。

- falseの場合、システム管理者は、ターゲット・ドメインの正しい場所からアプリケーションを使用できるようにする必要があります。

暗号化された属性のエクスポートおよびインポート

エクスポート処理中に、新しい秘密鍵が生成され、エクスポートされた<PartitionName>.zipファイルのexpPartSecretファイルに保存されます。partition-config.xmlファイルの暗号化されたすべての属性および<PartitionName>.zipの一部であるシステム・リソース・ディスクリプタは、expPartSecretファイルの新しい秘密鍵で暗号化されます。または、keyFileオプションでユーザー独自の秘密鍵を使用することもできます。

インポート処理中に、パーティション全体が読み取られ、<PartitionName>-attributes.jsonファイルに従って属性が変更された後、暗号化された属性は次の手順を使用して処理されます。

1. エクスポートされた.zipのexpPartSecretファイルの秘密鍵が読み取られます。

2. 秘密鍵は、2番目の鍵(WebLogic Serverソースのデフォルトの鍵またはインポートするkeyFileオプションで指定された鍵のいずれか)を使用して復号化されます。ユーザーが指定した鍵はインポートで使用した鍵と一致する必要があります。

3. (エクスポート処理で読み取られて変更された)パーティションのMBeanの暗号化されたすべての属性が、expPartSecretファイルから読み取られた鍵を使用して復号化されます。

4. パーティションのMBeanの暗号化されたすべての属性が、インポートされたドメインのドメイン固有の鍵(SerializedSystemIni.dat)を使用して暗号化されます。

ドメイン・パーティションのエクスポートおよびインポート: 主な手順およびWLSTの例

ドメイン・パーティション(ソース・ドメイン)をその構成およびデータ全体とともにパーティション・アーカイブ・ファイルとしてエクスポートできます。構成に多くの変更を加えることなく、パーティション・アーカイブ・ファイルをWebLogic Server MT (ターゲット・ドメイン)の別のインスタンスにインポートできます。仮想ターゲットやセキュリティ・レルムなどのドメインの依存性を更新し、オプションでパーティション構成の他の属性を更新して有効にする必要がある場合があります。

ドメイン・パーティションのエクスポート: 主な手順

ドメイン・パーティションをエクスポートする前に、最初に1つを作成またはインポートする必要があります。

ドメイン・パーティションをエクスポートする主な手順は次のとおりです。

1. エクスポートするドメイン・パーティションを選択します。

2. パーティション・アーカイブ・ファイルを保存するディレクトリへのフルパスを指定します。

各ドメイン・パーティションは、独自のディレクトリに配置する必要があります。指定した場所にすでに存在する場合、ドメイン・パーティションのアーカイブ・ファイルは上書きされます。ディレクトリ内の他のファイルも上書きされる場合があります。

3. オプションで、エクスポートされるパーティション・アーカイブ・ファイルに、インストールされたアプリケーションおよびライブラリのバイナリ・ファイルを含めるよう選択します。

4. オプションで、パーティション・アーカイブ・ファイル内の属性を暗号化するための暗号化鍵として使用する文字列を含むファイルへのフルパスを入力します。

ユーザー独自の鍵を指定しない場合、新規の秘密鍵が生成され、エクスポートした<PartitionName>.zipファイル内のexpPartSecretファイルに格納されます。

ドメイン・パーティションのエクスポート: WLSTの例

次のWLSTコマンドは、partition-1を/var/tmpディレクトリにエクスポートします。アプリケーションおよびライブラリのバイナリ・ファイルは含まれません。/home/foo/mykeyfileは、mykeyfile暗号化鍵へのパスです。

wls:/mydomain/serverConfig> exportPartition("partition-1", "/var/tmp/", false, "/home/foo/mykeyfile")

ドメイン・パーティションのインポート: 主な手順

ドメイン・パーティションをインポートする前に:

- 先にドメイン・パーティション(ソース・ドメイン)をパーティション・アーカイブ・ファイルにエクスポートしておく必要があります。

- サーバー・インスタンスにはドメイン(ターゲット・ドメイン)が構成されている必要があります。

ドメイン・パーティションをインポートする主な手順は次のとおりです。

1. インポートするパーティション・アーカイブ・ファイルへのフルパスを指定します。

2. オプションで、リソース・グループ・テンプレートがすでにターゲット・ドメインに存在して、新しい名前で新しいリソース・グループ・テンプレートを作成する場合に、既存のリソース・グループ・テンプレートの上書きオプションを選択します。

ソース・ドメイン・パーティションで使用されるすべてのリソース・グループ・テンプレートはパーティション・アーカイブ・ファイルに含まれ、パーティションとともにターゲット・ドメインにインポートされます。リソース・グループ・テンプレートがターゲット・ドメインにすでに存在し、既存のリソース・グループ・テンプレートの上書きを指定しない場合、インポート処理は失敗します。

3. オプションで、ターゲット・ドメインに作成されるときにパーティションに使用する名前を指定します。デフォルトはそのパーティションの元の名前です。

4. オプションで、パーティション・アーカイブ・ファイル内の属性を復号化するための鍵を含むファイルへのフルパスを入力します。

ドメイン・パーティションのインポート: WLSTの例

次のWLSTコマンドは、/var/tmpディレクトリにあるpartition-1アーカイブ・ファイルをインポートします。アプリケーションおよびライブラリのバイナリ・ファイルは含まれません。ファイル/home/foo/mykeyfileは暗号化鍵として使用されます。

wls:/mydomain/serverConfig> importPartition("/var/tmp/partition-1.zip", keyFile="/home/foo/mykeyfile")

ドメイン・パーティションのエクスポートおよびインポート: 関連タスクおよびリンク

次の追加情報を参照してください。

- 『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のドメイン・パーティションのエクスポートに関する項およびドメイン・パーティションのインポートに関する項

- 『Oracle WebLogic Server管理コンソール・オンライン・ヘルプ』のパーティションのエクスポートに関する項およびパーティションのインポートに関する項

23 名前が付いた同時編集セッションの管理

この章では、Oracle WebLogic Server Multitenant (MT)で名前が付いた同時編集セッションを管理する方法について説明します。この章の説明に従い、Oracle Enterprise Manager Fusion Middleware Control (FMWC)、Oracle WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)のいずれかを使用して、編集セッションを管理できます。この章では、適宜追加情報について、Oracle Fusion MiddlewareとWebLogic Serverのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章の内容は次のとおりです。

- 名前が付いた同時編集セッション: 概要

- 名前が付いた同時編集セッションの管理: 主な手順

- 名前が付いた同時編集セッションの管理: WLSTの例

- 名前が付いた同時編集セッションの管理: 関連タスクおよびリンク

名前が付いた同時編集セッション: 概要

以前のリリースでは、WebLogic Serverの構成編集セッションでは、一度に1つのアクティブな編集セッションのみがサポートされました。システム管理者は、グローバルな編集をロックし、変更を加えた後、それをアクティブ化していました。同時に他の管理者が変更を加えることはできませんでした。このリリースでは、複数の管理者が構成を変更する必要がある状況が発生します。WebLogic Server MTドメインには複数のパーティションがあり、それぞれに独自の管理者がいます。パーティション管理者は、他のパーティション管理者またはWebLogic Serverシステム管理者に影響を与えることなく、パーティションにデプロイされたパーティション構成およびリソースの構成を変更できる必要があります。このため、WebLogic Serverでは、パーティションごとに1つ以上の構成編集セッション、およびグローバル構成編集セッションをサポートする、複数の同時編集セッションが可能になっています。

この機能を使用して、管理者は名前が付いた編集セッションを作成し、変更を加え、その変更をアクティブ化します。また、別の管理者も並行して名前が付いた編集セッションを作成します。1人目の管理者の編集セッションと2人目の管理者が行った変更が競合する場合は、これらの変更がアクティブ化されたときに2人目の管理者にエラーが返されます。2人目の管理者はこの競合を解決して必要な変更をアクティブ化できます。「名前が付いた同時編集セッションの管理: 主な手順」を参照してください。

名前が付いた同時編集セッションの管理: 主な手順

名前が付いた同時編集セッションを管理する主な手順は次のとおりです。

1. 管理者は名前が付いた編集セッションを作成(および破棄)します。

ConfigurationManagerMBean APIを使用して、編集セッションの開始、変更のアクティブ化、変更の表示、変更の取消しなどを行います。

各編集セッションには、独自の構成ファイルとConfigurationManagerMBeanインスタンスがあります。

2. 変更された構成ファイルは、編集セッション固有のディレクトリに保持されます。

- グローバルな名前が付いた編集セッションの変更は、ドメイン・レベルの新規編集ディレクトリのサブディレクトリに保持されます(<domain-directory>/edit/<edit-session-name>)。<edit-session-name>は、編集セッションの作成時に指定された編集セッション名のバージョンです。

- パーティション固有の名前が付いた編集セッションの変更は、パーティション・ディレクトリのサブディレクトリに保持されます(<partition-directory>/edit/<edit-session-name>)。<edit-session-name>は、編集セッションの作成時に指定された編集セッション名のバージョンです。

3. 変更がアクティブ化されたときに、並行する編集セッション間で競合が発生する可能性があります。アクティブ化中に競合が発生した場合は、アクティブ化操作はエラーとなり、手動で競合を解決する必要があります。

現在の編集セッションに、同時に適用された任意の構成変更を適用するには、resolveメソッドを使用します。

resolveメソッドを呼び出すと、編集セッションにおける保留中の変更のアクティブ化を続行できます。

競合を解決するために、管理者は次の情報メッセージを使用できます。

- 各競合には、競合しているMBeanまたはプロパティの識別情報を含む説明が含まれます。

- 各競合には、この競合の解決方法を説明するメッセージも含まれます。

- 解決ログ・メッセージには、解決およびマージの各手順の簡単な説明が含まれます。管理者は解決ログ・メッセージを使用して、現在の編集セッションで何が変更されたか、およびどのように変更されたかを識別できます。

名前が付いた同時編集セッションの管理: WLSTの例

次に、WLSTを使用して構成編集セッションを管理する例を示します。

connect("username", "password")

# Enter existing named edit session or create one and enter it.
edit("foo")
startEdit()
cmo.createServer("Server-1")

# Create a different edit session.
edit("bar")
startEdit()
ls("Servers") #Server-1 is not printed because it is created in an independent edit session foo
s1=cmo.createServer("Server-1")
s1.setListenPort(5555) # Conflicting modification - the same server with a different port

# Go back to edit session foo and activate.
edit("foo")
activate()

# List edit sessions / list with details.
showEditSession() # Lists all edit sessions
showEditSession("bar") # More detailed information about edit session bar

# Go back to edit session bar and activate.
edit("bar")
activate() # Conflict occurs

# Resolve conflicts based on a standard resolution strategy.
resolve()
activate()

# Edit sessions can also be destroyed.
destroyEditSession("foo")
destroyEditSession("bar")

次の例に、編集セッションの競合解決の詳細を示します。

wls:/wls/edit(foo)/> showEditSession() # Lists all edit sessions
List of named edit sessions [for details use showEditSession(<name>)]:
default
bar
foo
wls:/wls/edit(foo)/> showEditSession("bar") # More detailed information about edit session bar
bar
Creator: wls
Editor (lock owner): wls
Resolve recommended: Yes
Contains unactivated changes: Yes

wls:/wls/edit(foo)/> # Go back to edit session bar and activate.
wls:/wls/edit(foo)/> edit("bar")
You already have an edit session in progress and hence WLST will
continue with your edit session.
Other configuration changes were activated. Call resolve() to merge it into this edit tree.
wls:/wls/edit(bar)/ !> activate() # Conflict occurs.
Activating all your changes, this may take a while ...
The edit lock associated with this edit session is released after the activation is completed.
Traceback (innermost last):
File "<console>", line 1, in ?
File "<iostream>", line 471, in activate
File "<iostream>", line 553, in raiseWLSTException
WLSTException: Error occurred while performing activate : Error while Activating changes. : 1 conflict:
[1]
[wls]/Servers[Server-1] - a bean with the same qualified name has already been added to [wls].
Description of resolution operation:
A bean added by this session overrides the one present in the current configuration.

wls:/wls/edit(bar)/> # Resolve conflicts based on a standard resolution strategy.
wls:/wls/edit(bar)/> resolve()
1 conflict:
[1]
[wls]/Servers[Server-1] - a bean with the same qualified name has already been added to [wls].
Description of the resolution:
A bean added by this session overrides the one present in the current configuration.
Patch:
No difference
wls:/wls/edit(bar)/ !> activate()
Activating all your changes, this may take a while ...
The edit lock associated with this edit session is released after the activation is completed.
Activation completed

wls:/wls/edit(bar)/> # Edit sessions can also be deleted.
wls:/wls/edit(bar)/> destroyEditSession("foo")

wls:/wls/edit(bar)/> destroyEditSession("bar")
Current edit tree is being removed; redirecting WLST cursor location to the config runtime tree.

名前が付いた同時編集セッションの管理: 関連タスクおよびリンク

次の追加情報を参照してください。

- 『Fusion Middleware ControlによるOracle WebLogic Serverの管理』の編集セッションの管理に関する項および競合の表示と解決に関する項

- 『Oracle WebLogic Server管理コンソール・オンライン・ヘルプ』の保留中の変更の表示に関する項および競合の解決に関する項

24 トランザクションの構成

この章では、Oracle WebLogic Server Multitenant (MT)でトランザクションを構成する方法について説明します。この章では、適宜追加情報について、Oracle Enterprise Manager Fusion MiddlewareとWebLogic Serverのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章の内容は次のとおりです。

- ドメイン・パーティションでのトランザクションの構成: 概要

- ドメイン・パーティションのLLRデータ・ソース、JDBC TLogデータ・ソースおよび決定子リソースの構成: 制限事項

ドメイン・パーティションでのトランザクションの構成: 概要

WebLogic Server MTでは、複数のパーティション環境でのトランザクション処理をサポートしています。トランザクションの範囲は、ドメイン・レベルまたはパーティション・レベルのいずれかになります。詳細は、「スコープ」を参照してください。

トランザクション環境を定義する属性のほとんどは、グローバル(ドメイン)レベルで定義されます。ただし、JTAの「タイムアウト」オプションはパーティション・レベルで構成する必要があります。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

ドメイン・パーティションのLLRデータ・ソース、JDBC TLogデータ・ソースおよび決定子リソースの構成: 制限事項

ロギング・ラスト・リソース(LLR)データ・ソース、JDBC TLogデータ・ソースまたは決定子リソースは、パーティションで登録できません。このリリースのWebLogic Serverで、これらのリソースをパーティション・レベルで登録しようとすると、システム例外が発生します。

この制限が発生するのは、これらのいずれかのリソースが使用できない場合にWebLogic Serverインスタンスを起動できないためです。そのため、マルチテナント環境では、アクセス不可状態は他のパーティションで共有されます。リソース(およびそのコミット・レコード)にアクセスできなくてもサーバーの起動が許可される場合、コミット・レコードの不足によりこれらのリソースがロールバックされるため、これらのリソースもリスト化したトランザクションでリスト化されたリソースのリカバリは、非原子的となる可能性があります。

固有に提供されたリソース・コミットの順序付けにLLRを使用する場合、WebLogic Server 12.2.1リリースで提供された最初リソース・コミット機能を使用します。この機能では、ローカル・トランザクション・ベースのLLRリソースではなく正確なXAリソースが必要になるため、LLRによるパフォーマンスの利点が提供されず、LLR表は必要ありません。LLRデータ・ソースはデプロイ先のサーバーに固定されますが、XAデータ・ソースは固定されません。そのため、複数のサーバーがトランザクションでリスト化される場合、2段階コミット・フローは少し異なる場合があります。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』の最初リソース・コミットの順序付けに関する項を参照してください。

25 Webサービスの構成

この章では、WebLogic Scripting Tool (WLST)スクリプトを使用してWebLogic Server Multitenant (MT)で高度なWebサービスおよびSOAP over JMSをサポートするために必要なリソースを構成する方法について説明します。また、WebLogic Server MT環境でWebサービスを使用する際に必要な固有の構成についても説明します。

この章の内容は次のとおりです。

- Webサービスの構成: 概要

- Webサービスの構成: 主な手順

- Webサービスの構成: SOAP over JMSでのパーティション化された分散トピックの使用

- Webサービスの構成: 関連タスクおよびリンク

Webサービスの構成: 概要

WebLogic Serverには、WebLogic Server MT環境で次のJAX-WS Webサービスの機能に必要なリソースを構成できる2つのWLSTスクリプトが含まれています。

- wlsws-advanced-jaxws-mt-config.py: 非同期メッセージング、Webサービスの信頼性のあるメッセージング、メッセージ・バッファリング、Webサービスの原子性トランザクションおよびWS-SecureConversationを使用したセキュリティなど、高度なJAX-WS Webサービスを構成します。

- wlsws-soapjms-mt-config.py: SOAP over JMSトランスポートを構成します。

両方のスクリプトは、oracle_home/oracle_common/webservices/bin/ディレクトリにあります。oracle_homeは、WebLogic Serverのインストール時にOracleホームとして指定したディレクトリです。

Webサービスの構成: 主な手順

WebLogic Server MT環境でWebサービスのリソースを構成するには、次の手順を実行します。

1. ドメイン・パーティションをまだ作成していない場合は、作成します。詳細は、「ドメイン・パーティションの構成」を参照してください。

2. パーティションにリソース・グループをまだ作成していない場合は、作成します。詳細は、「リソース・グループの構成」を参照してください。

3. ドメイン・レベルで、storeUserConfig WLSTコマンドを使用して、ユーザー構成ファイルおよび関連付けられたキー・ファイルを作成します。詳細は、『WebLogic Server WLSTコマンド・リファレンス』のstoreUserConfigを参照してください。

4. JAVA_HOME/bin/javaディレクトリから、WLSTスクリプトのいずれかまたは両方を実行します。weblogic.jarファイルの場所をクラス・パスに含める必要があります。

たとえば、WebLogic Server MTのJAX-WS用の高度なWebサービスに必要なリソースを構成するには、次のコマンドを使用します。

JAVA_HOME/bin/java -classpath weblogic.jar_location weblogic.WLST ./wlsws-advanced-jaxws-mt-config.py
-myUserConfigFile userConfigFile -myUserKeyFile userKeyFile
-myURL AdminServer_t3_url -partitionName partitionName
-rgName resourceGroupName -isCluster true_or_false
-middlewareHome middlewareHomeDir

WebLogic Server MTでのSOAP over JMSトランスポートに必要なリソースを構成するには、次のコマンドを使用します。

JAVA_HOME/bin/java -classpath weblogic.jar_location weblogic.WLST ./wlsws-soapjms-mt-config.py
-myUserConfigFile userConfigFile -myUserKeyFile userKeyFile
-myURL AdminServer_t3_url -partitionName partitionName
-rgName resourceGroupName -isCluster true_or_false
-middlewareHome middlewareHomeDir

両方のスクリプトには、表25-1で説明するコマンド・オプションが必要です。

表25-1 高度なWebサービスのWLSTスクリプトに必要なオプション

オプション

説明

-myUserConfigFile

手順3のstoreUserConfig WLSTコマンドの実行時にuserConfigFile引数に指定したファイルの名前。このファイルには、ユーザー構成が格納されています。

-myUserKeyFile

手順3のstoreUserConfig WLSTコマンドの実行時にuserKeyFile引数に指定したファイルの名前。このファイルには、指定したユーザー構成ファイルに関連付けられたキー情報が格納されています。

-myURL

パーティションの管理サーバーのT3プロトコルURL (例: t3://host:port)。

-partitionName

リソースが構成されるパーティションの名前。

-rgName

パーティションのリソース・グループの名前。

-isCluster

パーティションがクラスタにあるかどうかを示す引数。有効な値は次のとおりです。

- true: パーティションはクラスタにあります。

- false: パーティションはクラスタにありません。

-middlewareHome

WebLogic Serverのインストール時にOracleホーム・ディレクトリとして指定したディレクトリの場所。

Webサービスの構成: SOAP over JMSでのパーティション化された分散トピックの使用

SOAP over JMSは、JMS宛先タイプとしてキューとトピックの両方をサポートしています。使用するタイプは、アプリケーションによって決定されます。

WebLogic Server MT環境でSOAP over JMSのリクエスト宛先として共通分散トピックを使用する場合、パーティション化された共通分散トピックを使用する必要があります。

WebLogic JMSでは、分散トピックは、レプリケートされた分散トピックまたはパーティション化された分散トピックとして構成できます。レプリケートされた分散トピックは、Compatibility、One-Copy-Per-ServerまたはOne-Copy-Per-ApplicationのtopicMessageDistributionMode設定で機能しますが、パーティション化された分散トピックは、One-Copy-Per-ServerまたはOne-Copy-Per-Applicationでのみ機能します。

WebLogic Server MTでSOAP over JMSにパーティション化された共通分散トピックを構成するには、@JMSTransportService注釈を構成し、activationConfigプロパティでtopicMessageDistributionMode構成プロパティをOne-Copy-Per-ServerまたはOne-Copy-Per-Applicationに設定します。Compatibilityの値は、パーティション化された分散トピックではサポートされていません。

次に例を示します。

@JMSTransportService(targetService="poNotifyService"
,
destinationName="com.oracle.webservices.jms.SoapJmsRequestTopic"
, destinationType=JMSDestinationType.TOPIC
, activationConfig =
"topicMessagesDistributionMode=One-Copy-Per-Application"
, jndiURL = "t3://@wls-server@"

詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のJMSトランスポートを経由したSOAPの使用に関する項を参照してください。

注意:

パーティション化された分散トピックを使用してSOAP over JMSアプリケーションをデプロイする前に、JMSトピックを構成する必要があります。詳細は、『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックの構成に関する項を参照してください。

Webサービスの構成: 関連タスクおよびリンク

高度なWebサービス関連の追加情報は、次の項を参照してください。

- ドメイン・パーティションの構成

- リソース・グループの構成

- Oracle WebLogic Server JAX-WS Webサービスの開発

- 『WebLogic Server WLSTコマンド・リファレンス』のstoreUserConfigに関する項

- 『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの作成と構成に関する項

26 パーティションのモニタリングおよびデバッグ

この章では、Oracle WebLogic Server Multitenant (MT)でパーティションをモニターおよびデバッグする方法について説明します。この章の説明に従い、Oracle Enterprise Manager Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)のいずれかを使用して、パーティションをモニターできます。この章では、適宜追加情報について、Oracle Fusion Middleware、Oracle CoherenceおよびOracle Traffic Directorのドキュメント・セットおよびオンライン・ヘルプを参照します。

この章の内容は以下のとおりです。

- ドメイン・パーティションのモニタリング: 概要

- パーティション・ログおよび診断データ

- パーティション・スコープのロギングの構成

- パーティション・スコープのデバッグの構成

- 診断システム・モジュールの構成

- 診断データへのアクセス

- リソース消費管理のモニタリング

- パーティション・スコープのアプリケーションの計測

- パーティション・スコープの診断イメージ・キャプチャの構成

- パーティション管理者用のWLST診断コマンド

ドメイン・パーティションのモニタリング: 概要

WebLogic診断フレームワーク(WLDF)は、パーティション・スコープの次の診断機能を提供します。

- ロギング
様々なWebLogic Serverコンポーネント(パーティション・スコープJMS、SAF、サーブレット・リソースなど)のログがパーティション・ファイル・システム・ディレクトリに用意されています。マルチテナント環境で、パーティション・ユーザーは、パーティション・スコープ・ロガーを構成し、他のパーティションに影響を与えることなくこれらのロガーのレベルを制御できます。詳細は、「パーティション・スコープのロギングの構成」を参照してください。

注意:

サーバー・スコープおよびドメイン・スコープのリソースのログ(サーバー・スコープHTTPアクセス・ログ、ハーベスタ・コンポーネント、インストゥルメンテーション・コンポーネント、サーバー・ログとドメイン・ログなど)は、WLDFデータ・アクセサからのみ使用できます。詳細は、「診断データへのアクセス」を参照してください。

- デバッグ
システム管理者と連携して、パーティション・ユーザーは、WebLogic Serverコンポーネント上にデバッグ・フラグを設定して、他のパーティションに影響を与えることなく、パーティションで実行された作業のかわりにデバッグ・メッセージをブロードキャストできるようにします。詳細は、「パーティション・スコープのデバッグの構成」を参照してください。

- パーティション・リソースのモニタリング
リソース・グループまたはリソース・グループ・テンプレートに診断システム・モジュールを構成して、パーティション固有のメトリックの収集を有効にし、パーティション・スコープのリソースでポリシーおよびアクションを構成できます。詳細は、「診断システム・モジュールの構成」を参照してください。

また、WLDFは、パーティション・スコープのリソース消費メトリックを収集することもでき、これはPartitionResourceMetricsRuntimeMBeanで属性として公開されます。詳細は、「リソース消費管理のモニタリング」を参照してください。

- ログ・データの表示
パーティション管理者は、ログ・ファイルにファイル・レベルではアクセスできませんが、WLDFデータ・アクセサおよびサポートされているWLST機能を使用できます。詳細は、「診断データへのアクセス」を参照してください。

- アプリケーション・インストゥルメンテーションの計測
パーティション内にデプロイされたアプリケーションは、WLDFインストゥルメンテーション・コンポーネントを使用して計測できます。詳細は、「パーティション・スコープのアプリケーションの計測」を参照してください。

- 診断イメージ・キャプチャ
イメージ・キャプチャは、パーティション・スコープ・ユーザーが手動で、またはパーティション・スコープ診断システム・モジュールで構成されたポリシーによって開始できます。生成される診断イメージには、パーティション固有のコンテンツのみが含められます。詳細は、「パーティション・スコープの診断イメージ・キャプチャの構成」を参照してください。

パーティション・ログおよび診断データ

WebLogic Serverは、次のログおよび診断データ・ファイルを維持して、パーティションのかわりに実行されたイベントおよびアクティビティを追跡します。パーティション固有のログ・ファイルは、partitions/<partition>/system/servers/<server-name>ディレクトリにあります。

ログ・ファイル

目次

ServerLog

パーティションのスコープ内で作業を行う際に生成されたWeblogic Serverイベントのログ・レコード。サーバー・ログは、パーティション・ファイル・システム内では使用できません。WLDFデータ・アクセサを介してのみ使用できます。

DomainLog

パーティションのかわりに生成されたドメイン・スコープのイベントのログ・レコード。ドメイン・ログは、パーティション・ファイル・システム内では使用できません。WLDFデータ・アクセサを介してのみ使用できます。

HTTPAccessLog (パーティション・スコープの仮想ターゲット・アクセス・ログ)

各仮想ターゲットのWebサーバーのaccess.logファイル。パーティションごとに個別に維持され、パーティション・ユーザーがアクセスできます。

HarvestedDataArchive

WLDFハーベスタ・コンポーネントによって収集され、パーティションに適用されるMBeanメトリック。このファイルは、WLDFデータ・アクセサを介してのみ使用できます。

EventsDataArchive

WLDFインストゥルメンテーション・コンポーネントで生成されたイベント。このファイルは、WLDFデータ・アクセサを介してのみ使用できます。

JMSMessageLog (partition-scoped)

パーティション・スコープのJMSリソースのログ・レコード。個々のログ・ファイルは、パーティションごとに維持され、パーティション・ユーザーがアクセスできます。

JMSSAFMessageLog (partition-scoped)

パーティション・スコープのSAFエージェント・リソースのログ・レコード。個々のログ・ファイルは、パーティションごとに維持され、パーティション・ユーザーがアクセスできます。

DataSourceLog

パーティションのスコープ内で作業を行う際に生成されたデータ・ソース・プロファイル・レコード。

WebAppLog (partition-scoped)

パーティション・スコープのアプリケーションからのサーブレット・コンテキスト・ログ。個々のログ・ファイルは、パーティションごとに維持され、パーティション・ユーザーがアクセスできます。

ConnectorLog (partition-scoped)

パーティション・スコープのリソース・アダプタからのJava EE Connector Architectureリソース・アダプタ・ログ。個々のログ・ファイルは、パーティションごとに維持され、パーティション・ユーザーがアクセスできます。

パーティション・スコープのロギングの構成

WebLogic Server MTでは、パーティションにデプロイされたアプリケーションによって使用されるjava.util.loggingロガーのレベルの構成を許可します。WebLogic Serverドメイン内で、異なるパーティションに同じアプリケーションのコピーを含めることができます。このような場合、アプリケーションの異なるインスタンスは、同じ名前のjava.util.loggingロガーを使用できます。アプリケーションは、java.util.loggingロガーを使用するライブラリ、またはシステム・クラスパスにあるライブラリに依存することがあります。マルチテナント環境で、パーティション・ユーザーは、他のパーティションに影響を与えることなく、パーティションのスコープ内のこれらのロガーのレベルを制御できます。

パーティション・スコープのリソースのjava.util.loggingロガー・レベルを構成する機能は、次によって有効になります。

- カスタム・ログ・マネージャWLLogManager。これは、システム管理者が、ドメインのグローバル・ログ・マネージャとして構成する必要があります

- PartitionLogMBean.PartitionLoggerLevels属性。これは、パーティション・ユーザーが、ログ出力名と対応するjava.util.logging.Level名で構成されるキーと値のペアを指定することによって構成できます

パーティション・ユーザーがパーティション・スコープのロガー・レベルを構成する機能を有効にするには、次の手順を実行します。

1. システム管理者は、次のweblogic.ServerオプションをWebLogic Server起動コマンドに含めることによって、ドメインにWLLogManagerを構成する必要があります。

-Djava.util.logging.manager=weblogic.logging.WLLogManager

2. パーティション・ユーザーは、PartitionLogMBean.PartitionLoggerLevels属性でキーと値のペアを構成します。

次の例は、WLSTを使用して、パーティションp1に対してパーティション・スコープのロギングおよびデバッグを構成する方法を示しています。

startEdit()
cd('/')
p1 = cmo.createPartition('p1')
plog = p1.getPartitionLog()
plog.addEnabledServerDebugAttribute('DebugJNDI')
props = java.util.Properties()
props.put('foo.bar.logging','WARNING')
plog.setPlatformLoggerLevels(props)
save()
activate()

デバッグの詳細は、「パーティション・スコープのデバッグの構成」を参照してください。

パーティション・スコープのデバッグの構成

WebLogic Server MTは、次の手段によるパーティション・スコープのリソースのデバッグをサポートします。

- ServerDebugMBeanには、PartitionDebugLoggingEnabled属性が含まれます。この属性は、パーティション・スコープのデバッグを有効にするかどうかを制御し、システム管理者のみがアクセスできます。
この属性は、デフォルトでは無効になっています。有効にすると、パーティション・スコープのデバッグは、ドメイン内のすべてのパーティションで使用可能になります。

- PartitionLogMBeanには、EnabledServerDebugAttributes属性が含まれ、これに対してパーティション・ユーザーは、Stringsの配列として、ServerDebugMBeanで使用できる任意のデバッグ・フラグを定義できます。

- デバッグがドメイン内で有効になり、パーティションで構成されると、パーティションのかわりに作業を行うシステム・リソースによってブロードキャストされたデバッグ・メッセージがそのパーティションに送信されます。

注意:

サーバーの問題のトラブルシューティングの際に、パーティション・ユーザーとシステム管理者は、パーティションのサーバー・レベルのデバッグを有効にする前に、互いに相談することをお薦めします。さらに、パーティション・スコープのデバッグは、短期間のみ有効にする必要があります。

パーティション・スコープのデバッグの通常のユースケースでは、PartitionLogMBean.EnabledServerDebugAttributes属性で構成する必要がある特定のデバッグ・フラグを識別するために、パーティション・ユーザーがOracleサポート・サービスに相談します。

パーティション・スコープのデバッグの構成を示すサンプルWLSTスクリプトは、前述の例を参照してください。

診断システム・モジュールの構成

WLDF診断システム・モジュールをリソース・グループおよびリソース・グループ・テンプレートに含めて、パーティション固有のモニタリングを許可できます。ドメイン・スコープの診断システム・モジュールで提供される機能のすべてが、パーティションにスコープされたときに有効になるわけではありません。特に、サーバー・レベルのWLDFインストゥルメンテーション・コンポーネントは、サーバー全体に影響しますが、パーティション・レベルでは使用できません。

次の各項では、パーティション・スコープの診断システム・モジュールの構成方法について説明します。

- メトリックの収集

- ポリシーとアクションの構成

メトリックの収集

WLDFハーベスタ・コンポーネントは、診断システム・モジュールの構成と一致するJMXランタイムMBean属性を定期的にサンプリングし、データをアーカイブに格納します。この機能は、パーティションのスコープ内で使用できますが、診断システム・モジュールでは次のようになります。

- 同じパーティション内のみのリソースのランタイムMBeanにアクセスできます。パーティション・ユーザーは、グローバル・レベルでのMBeanの特定のモニタリング情報への読取り専用アクセスが可能です。これらのMBean属性は、パーティション・スコープのWLDF診断システム・モジュールから収集できます。

- 他のパーティションのリソースのランタイムMBeanにはアクセスできません。

- パーティションに依存しない方法でハーベスタ・コンポーネントを構成できます。つまり、partition-idまたはpartition-nameは、構成内に記述する必要はありません。これにより、WLDF構成は、割り当てられるパーティションに関係なくポータブルになります。

アーカイブ・コンポーネントに保存されたパーティション・スコープのデータは、パーティション固有の識別子でタグ付けされ、データには、システム管理者およびそのパーティションのユーザーはアクセス可能で、他のユーザーはアクセスできなくなります。

パーティション管理者が診断システム・モジュールに使用できるWLSTコマンドのリストは、「パーティション管理者用のWLST診断コマンド」を参照してください。

ポリシーとアクションの構成

診断システム・モジュール内でWLDFポリシーおよびアクション・コンポーネントを使用して、一般的なJMXランタイムMBeanメトリック、ログ・レコードおよびインストゥルメンテーション・イベントを評価するポリシーを作成できます。この機能は、次の制約においてパーティション・レベルで使用できます。

- ポリシーは、パーティションで使用可能なMBean属性にのみアクセスできます。

- ログ・ポリシーは、パーティションに固有のサーバーおよびドメインのログ・レコードに対してのみ評価されます。

- SNMPアクションはサポートされていません。

- SMTPアクションでは、使用されるメール・セッションをJNDI内のパーティションで表示可能にする必要があります。

- パーティション・スコープの診断システム・モジュールのすべてのポリシー式は、Java式言語(EL)を使用する必要があります。詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』のポリシー式に関する項を参照してください。

- スケーリング・アクション(スケール・アップおよびスケール・ダウン)は、パーティションのスコープ内ではサポートされていません。

診断データへのアクセス

パーティション管理者は、サーバー・スコープまたはドメイン・スコープのログ・ファイルをはじめ、ドメイン内の一部のログ・ファイルにはファイル・レベルでアクセスできません。ただし、WLDFデータ・アクセサおよびサポートされているWLST機能を使用して、パーティションに関連するログ・コンテンツに選択的にアクセスできます。

ドメイン内のすべてのログ・ファイルに完全にアクセスできるシステム管理者は、次のことが確実に行われるように、ログ・ファイルの適切なセキュリティ・ポリシーの構成を担当します。

- ログ・レコードにアクセスしようとすると認証されます。

- パーティションに固有のログ・レコードにアクセスできます。

- パーティションに関連しないログ・レコードへのアクセスは拒否されます。

パーティションのWLDFPartitionRuntimeMBean (PartitionRuntimeMBeanの子)の下に作成される次のMBeanを使用して、パーティションのログ・レコードにアクセスできます。

MBean

説明

WLDFPartitionAccessRuntimeMBean

パーティションで使用可能なログ・ファイルを検出します。パーティションで使用できないログ・ファイルは公開されません。

WLDFDataAccessRuntimeMBean

パーティションに固有のログ・ファイル・レコードにアクセスします。パーティションに関連しないログ・レコードは公開されません。

共有ログ・ファイル

次のログおよび診断データは、ドメイン内のすべてのパーティションで共有され、パーティション管理者は、パーティションに関連するこれらのログ内のレコードにアクセスできます。

ログ・タイプ

コンテンツの説明

サーバー

パーティションに関連し、サーバー・ログ・ファイルに記録されるサーバーおよびアプリケーション・コンポーネントからのログ・イベント。

ドメイン

パーティションに関連し、ドメイン・ログ・ファイルに記録されるドメイン内のすべてのサーバー・インスタンスから一元的に収集されるログ・イベント。

データ・ソース

パーティションに関連し、データ・ソース・ログ・ファイルに記録されるデータ・ソース・ログ・イベント。

収集されたデータ・アーカイブ

パーティションに関連し、収集されたデータ・アーカイブに記録されるMBeanからWLDFハーベスタ・コンポーネントによって収集されるメトリック・データ。

イベント・データ・アーカイブ

パーティションにデプロイされたアプリケーションによって収集され、イベント・データ・アーカイブに記録されるWLDFインストゥルメンテーション・イベント。

パーティションがドメインに構成されると、これらの共有ログ・ファイルに作成された各レコードには、次の2つの属性が含まれます。

- partition-name - 人間が判読可能なパーティション名

- partition-id - 自動生成された一意のパーティションの識別子

収集されたデータ・アーカイブおよびイベント・データ・アーカイブには、これらの属性がリストされた追加の2つの表列PARTITION_IDおよびPARTITION_NAMEが含まれます。

注意:

パーティションがドメインに構成されると、サーバー・スコープまたはドメイン・スコープの作業のかわりに収集されたログ・レコードには、partition-id値として0、partition-name値としてDOMAINが割り当てられます。

次の例は、サーバー・ログ・ファイルのログ・レコード・エントリを示しています。partition-idおよびpartition-name属性は太字で強調表示されています。

####<Oct 2, 2015 1:20:28 PM EDT> <Notice> <Partition Lifecycle>
<tiger-mac.local> <partitionAdmin> <[ACTIVE] ExecuteThread: '2' for queue:
'weblogic.kernel.Default (self-tuning)'> <system> <>
<cfd4d584-ee45-49a6-ae91-9c12551330d8-000000af> <1443806428565> <[severity-value: 32] [rid: 0]
[partition-id: d75a4899-ca61-4ed8-b519-317b0ec15061] [partition-name: p1] > <BEA-2192303> <The partition lifecycle operation "START" for partition "p1" is initiated.>

WLDFデータ・アクセサが特定のパーティションに関連するログ・レコードを取得すると、partition-id値に基づいてフィルタされます。

注意:

JVMおよび他のイベント・プロデューサ(WebLogic Serverやダイナミック・モニタリング・サービス(DMS)など)からのイベントを含むJava Flight Recorder (JFR)フライト記録には、パーティション間のデータを区別するためにpartition-idおよびpartition-name属性を含めることができます。ただし、マルチテナントの問題の診断に使用できるパーティション情報を含むJFRデータにアクセスできるのは、システム管理者のみです。

パーティション固有のログ・ファイル

次のログ・ファイルは各パーティションに固有のもので、パーティション管理者が使用できます。これらのログ・ファイルは、partitions/<partition>/system/servers/<server-name>ディレクトリに格納されます。

ログ・タイプ

コンテンツの説明

HTPPアクセス・ログ

ファイルaccess.logに格納される、パーティションの仮想ターゲットWebサーバーからのすべてのHTTPトランザクションのログ・イベント。

JMSサーバー

リソース・グループまたはリソース・グループ・テンプレート内に定義され、パーティションにスコープされたJMSサーバー・リソースのJMSサーバー・メッセージ・ライフサイクル・イベント。

SAFエージェント

リソース・グループまたはリソース・グループ・テンプレート内に定義され、パーティションにスコープされたSAFエージェント・リソースのSAFエージェント・メッセージ・ライフサイクル・イベント。

コネクタ

パーティション内でリソース・グループまたはリソース・グループ・テンプレートにデプロイされたJava EE Connector Architectureリソース・アダプタ・モジュールによって生成されたログ・データ。

サーブレット・コンテキスト

パーティション内でリソース・グループまたはリソース・グループ・テンプレートにデプロイされたJava EE Webアプリケーション・モジュールによって生成されたサーブレット・コンテキスト・ログ・データ。

WLDFデータ・アクセサの使用

WLDFデータ・アクセサを使用すると、型、コンポーネント、属性を基準としてデータをルックアップできます。重大度、ソースおよびコンテンツでフィルタできます。また、表形式の診断データにアクセスすることもできます。データ・アクセサの詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』のデータ・アクセサを使用した診断データへのアクセスに関する項を参照してください。

次の表に、各ログの論理名と、データ・アクセサを使用して表示できる診断データ・ファイルを示します。WLDFDataAccessRuntimeMBeanまたはWLSTを使用する際には、論理名をキーとして使用してログ・タイプを参照します。

ログ・タイプ

論理名

サーバー・ログ

ServerLog

ドメイン・ログ

DomainLog

JDBCログ

DataSourceLog

収集されたデータ・アーカイブ

HarvestedDataArchive

イベント・データ・アーカイブ

EventsDataArchive

HTTPアクセス・ログ

HTTPAccessLog/<WebServer-Name>

JMSサーバー

JMSMessageLog/<JMSServer-Name>

SAFエージェント

JMSSAFMessageLog/<SAFAgent-Name>

サーブレット・コンテキスト

WebAppLog/<WebServer-Name>/context-path

コネクタ

ConnectorLog/connection-Factory-jndiName$partition-name

パーティション管理者として、次のツールを使用して、パーティションのログおよび診断データにアクセスできます。

- Fusion Middleware Control
Fusion Middleware Controlを使用して、共有ログ・ファイルとパーティション固有のログ・ファイルの両方からレコードを表示できます。詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のドメイン・パーティションのモニターに関する項を参照してください。

- WebLogic Scripting Tool
パーティション管理者がデータ・アクセサを使用するために使用できるWLSTコマンドのリストは、「パーティション管理者用のWLST診断コマンド」を参照してください。これらのコマンドの構文および例は、『WebLogic Server WLSTコマンド・リファレンス』の診断コマンドに関する項を参照してください。

Oracle WebLogic Server管理コンソールは、パーティション・ログおよび診断データの表示をサポートしていません。

リソース消費管理のモニタリング

リソース消費管理(RCM)は、システム管理者が共有リソースを管理し、MT環境におけるドメイン・パーティションの一貫したパフォーマンスを提供するために、柔軟性のある動的なメカニズムを提供します。WebLogic Serverは、パーティション・スコープ内でRCMをモニターする機能をサポートしています。

RCMの詳細は、「リソース消費管理の構成」を参照してください。

RCMの構成

RCMの構成の詳細は、「リソース消費管理の構成: 主な手順」を参照してください。

パーティション・スコープのRCMメトリック

表26-1では、パーティション・スコープのRCMメトリックを指定できるPartitionResourceMetricsRuntimeMBeanに関する属性をリストし、概説します。

表26-1 RCMのPartitionResourceMetricsRuntimeMBean属性

属性

説明

RCMMetricsDataAvailable

RCMメトリック・データがこのパーティションで使用可能かどうかを示すブール値。

CpuTimeNanos

サーバーの起動またはパーティションの作成のいずれか遅い方以降にパーティションのコンテキストで費やされた合計CPU時間。

AllocatedMemory

サーバーの起動またはパーティションの作成のいずれか遅い方以降にパーティションのコンテキストで割り当てられた合計メモリー(バイト)。

RetainedHeapHistoricalData

パーティションの保存されるヒープ・メモリー使用率の履歴データのスナップショット。データは、一定期間にパーティションにスコープされた保存されるヒープの使用率の二次元配列として返されます。配列の各アイテムには、[timestamp (long), retainedHeap(long)]値のタプルが含まれています。

CpuUtilizationHistoricalData

パーティションのCPU使用率の履歴データのスナップショット。CPU使用率は、Weblogic Serverで使用可能なCPUに対する、パーティションで使用されるCPUの割合を示します。データは、一定期間にパーティションにスコープされたCPU使用率の二次元配列として返されます。配列の各アイテムには、[timestamp (long), cpuUsage(long)]値のタプルが含まれています。

ThreadCount

パーティションに現在割り当てられているスレッドの数。

TotalOpenedSocketCount

サーバーの起動またはパーティションの作成のいずれか遅い方以降にパーティションのコンテキストでオープンしたソケットの合計数。

CurrentOpenSocketCount

パーティションのコンテキストで現在オープンしているソケットの数。

NetworkBytesRead

サーバーの起動またはパーティションの作成のいずれか遅い方以降にパーティションのソケットから読み取られた合計バイト数。

NetworkBytesWritten

サーバーの起動またはパーティションの作成のいずれか遅い方以降にパーティションのソケットに書き込まれた合計バイト数。

TotalOpenedFileCount

サーバーの起動またはパーティションの作成のいずれか遅い方以降にパーティションのコンテキストでオープンしたファイルの合計数。

CurrentOpenFileCount

パーティションのコンテキストで現在オープンしているファイルの数。

FileBytesRead

サーバーの起動またはパーティションの作成のいずれか遅い方以降にパーティションのコンテキストで読み取られた合計バイト数。

FileBytesWritten

サーバーの起動またはパーティションの作成のいずれか遅い方以降にパーティションのコンテキストで書き込まれた合計バイト数。

TotalOpenedFileDescriptorCount

サーバーの起動またはパーティションの作成のいずれか遅い方以降にパーティションのコンテキストでオープンしたファイル・ディスクリプタの合計数。

CurrentOpenFileDescriptorCount

パーティションのコンテキストで現在オープンしているファイル・ディスクリプタの数。

一般的なRCM構成要件は、「リソース消費管理の構成」を参照してください。

パーティション・スコープのアプリケーションの計測

WLDFインストゥルメンテーション・コンポーネントは、WebLogic Serverインスタンスおよびそのサーバー・インスタンスで実行中のアプリケーションに診断コードを追加するためのメカニズムを提供します。この機能の詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』のインストゥルメンテーションの構成に関する項を参照してください。

WebLogic Server MTは、デプロイメント・ディスクリプタ(META-INF/weblogic-diagnostics.xml)またはデプロイメント・プランを使用して、パーティション内にデプロイされたアプリケーションのインストゥルメンテーションを行う機能をサポートしています。この機能は、次の条件下でサポートされます。

- システム管理者は、システム・レベルで診断システム・モジュールを構成し、そのターゲットとして適切な管理対象サーバー・インスタンスをグローバル・レベル(パーティション・スコープではない)で指定する必要があり、インストゥルメンテーション・コンポーネントが有効になっている必要があります。

- 計測されたアプリケーションには、META-INF/weblogic-diagnostics.xmlデプロイメント・ディスクリプタが含まれている必要があり、インストゥルメンテーション・コンポーネントが有効になっている必要があります。

- アプリケーションは、クラス・ローダーを他のパーティションのアプリケーション・インスタンスと共有する方法で構成しないでください。

パーティション・スコープの診断イメージ・キャプチャの構成

診断イメージ・キャプチャは、それを開始したときに存在するWebLogic Serverの様々なサブシステムの関連データを対象としています。次のいずれかのツールで手動で診断イメージ・キャプチャを開始できます。

- WebLogic Server管理コンソール

- Fusion Middleware Control

- WLST

- JMX

- WLDFポリシーおよびアクション・コンポーネント

パーティション・ユーザーが診断イメージ・キャプチャを開始すると、イメージのコンテンツは、パーティション・スコープのリソースのみに限定されます。パーティションに対応するWLDFPartitionImageRuntimeMBeanで操作を呼び出すことによって診断イメージ・キャプチャを開始すると、生成されたイメージには、そのパーティションにのみ関連するデータが含まれます。パーティション・スコープの診断イメージの場合、partition-idおよびpartition-name属性がファイル名にエンコードされます。

パーティションに対応する情報を含むJFRデータにアクセスできるのは、システム管理者のみであることに注意してください。

パーティションにスコープされると、次のコンポーネントはパーティション固有のレコードを診断イメージ・キャプチャに生成できます。

- コネクタ

- インストゥルメンテーション

- JDBC

- JNDI

- JVM

- ロギング

- RCM

- ワーク・マネージャ

- JTA

パーティション管理者が診断イメージ・キャプチャに使用できるWLSTコマンドのリストは、「パーティション管理者用のWLST診断コマンド」を参照してください。

パーティション管理者用のWLST診断コマンド

次の表に、パーティション管理者がパーティション・スコープのロギングおよび診断データにアクセスするために使用できるWLST診断コマンドを示します。これらのコマンドは、次の3つのカテゴリで示されます。

- データ・アクセサ: WLDFデータ・アクセサ・コンポーネントを使用して、ログ・レコード、データ・イベント、収集されたメトリックなどの様々なソースからのパーティション・スコープ診断データにアクセスするためのコマンド

- 診断イメージ・キャプチャ: 診断イメージ・キャプチャの取得、保存およびアクセスを行うためのコマンド

- 診断モジュール: 特定の時間間隔で診断システム・モジュールによって収集されたメトリック・データをエクスポートするためのコマンド

これらの各コマンドには、パーティション名を指定するpartition引数が含まれます。

コマンド

カテゴリ

サマリー

exportDiagnosticDataFromServer

データ・アクセサ

サーバー側で問合せを実行して、エクスポートされたWLDFデータを取得します。

getAvailableDiagnosticDataAccessorNames

データ・アクセサ

サーバーまたはパーティションで現在使用可能な診断データ・アクセサ・インスタンスの論理名を取得し、それを文字列値の配列として返します。

captureAndSaveDiagnosticImage

診断イメージ

診断イメージを取得し、クライアントにダウンロードします。

getAvailableCapturedImages

診断イメージ

サーバーで構成したイメージの宛先ディレクトリに格納される以前に捕捉した診断イメージのリストを文字列の配列で戻します。

saveDiagnosticImageCaptureEntryFile

診断イメージ

WLSTが現在接続されているサーバーにある診断イメージ・キャプチャから特定のエントリをダウンロードします。

saveDiagnosticImageCaptureFile

診断イメージ

WLSTが現在接続されているサーバーから指定した診断イメージ・キャプチャをダウンロードします。

purgeCapturedImages

診断イメージ

サーバーの構成済イメージ宛先ディレクトリから指定された期間の基準に従って、サーバーの診断イメージ・ファイルをパージします。

exportHarvestedTimeSeriesData

診断モジュール

特定のサーバー・スコープまたはパーティション・スコープの診断システム・モジュールの診断アーカイブ・ファイルから収集済メトリック・データをエクスポートします。

診断で使用できるWLSTコマンドの詳細は、『WebLogic Server WLSTコマンド・リファレンス』の診断コマンドに関する項を参照してください。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。