Quantcast
Channel: Oracle Blogs 日本語のまとめ
Viewing all 760 articles
Browse latest View live

[Cloud] ANNOUNCING: Oracle OpenStack for Oracle Linux Release 2

$
0
0
原文はこちら。
https://blogs.oracle.com/linux/entry/announcing_oracle_openstack_for_oracle

本日、Oracle OpenStack for Oracle Linux Release 2を発表します。最初の商用利用可能なDockerコンテナをベースとしたOpenStackデプロイメントで、個別にRPMを使ってコンポーネントのインストールをする必要はありません。
New Oracle OpenStack for Oracle Linux Now Available
https://www.oracle.com/corporate/pressrelease/oracle-openstack-4-oracle-linux-101915.html

基になったKiloリリースをベースとして、Oracle OpenStack for Oracle Linux R2にはHeatやMuranoといった新しいモジュールのサポートも含まれています。また、このリリースではMySQL Clusterを使い、ミッションクリティカルなActive-Activeの高可用性、高パフォーマンス、スケーラビリティをすべてのOpenStackサービスに提供します。

Highlights of Oracle OpenStack for Oracle Linux Release 2:

  • Docker ベースのコンテナを展開およびアップグレードに活用することで、他ベンダーのリリースに比べて、開発と運用がシンプルになりました。
  • Kiloをベースにしています。
  • 統合された高可用性機能を使うと、お客様はMySQLをActive/Active構成で展開することが可能です。これにより、エンタープライズデータベース機能をOpenStackクラウドデプロイメントで利用できるようになります。
    MySQL
    https://www.mysql.com/
  • Oracle All Flash FS Storage Systemおよび Oracle ZFS Storage Appliance 用のCinderドライバをサポートしています。
    Oracle All Flash FS Storage System
    https://www.oracle.com/storage/flash/fs1/index.html
    Oracle ZFS Storage Appliance
    https://www.oracle.com/storage/nas/index.html
    Ceph Object Gatewayを利用するためのテクノロジープレビューとして、Oracle LinuxでCeph Storageソリューションを提供します。
  • エンタープライズOpenStackクラウドソリューションが単一のサポートラインに統合されました
  • Oracle OpenStack for Oracle Linuxはご利用、ダウンロードとも無料です。

Read more


もしOpenWorld 2015に参加されるのであれば、以下のセッションやデモにお立ち寄りください。
  • [デモ]
    Oracle OpenStack for Oracle Linux Demopod
    Kiosk: SLX-010
    プロダクトマネージャやエンジニアと会話することができます。
    詳しくは以下のエントリをご覧ください。
    Oracle Linux, Oracle VM and OpenStack Showcase, Moscone South, Booth #121
    https://blogs.oracle.com/linux/entry/friday_spotlight_visit_our_oracle
  • [セッション]
    • General Session: Oracle Linux-the State of the Penguin [GEN9479]
      Tuesday, Oct 27, 11:00 a.m. | Park Central-Metropolitan II
    • Maximize Your Private Cloud Investment with Oracle OpenStack for Oracle Linux [CON9574]
      Wednesday, Oct 28, 4:15 p.m. | Park Central-Metropolitan II
    • Rapid Private Cloud with Oracle VM and Oracle OpenStack for Oracle Linux [CON9576]
      Wednesday, Oct 28, 1:45 p.m. | Park Central-Metropolitan II
    • HOL: Getting Started with Oracle OpenStack for Oracle Linux [HOL10473]
      Monday, Oct 26, 12:30 p.m. | Hotel Nikko—Nikko Ballroom II (3rd Floor)
Facebook、Blog、YouTube、SlideShareなどを通じてOracle OpenStack for Oracle Linuxと繋がってください。
Facebook
https://www.facebook.com/pages/Oracle-OpenStack/796023413845212?fref=ts
Blog
https://blogs.oracle.com/openstack/
YouTube
https://www.youtube.com/channel/UCH2IyEvbZQuxRu1pRUL2I-A/feed
SlideShare
http://www.slideshare.net/OracleOpenstack

[Java] Java SE 8u65とJava SE 8u66の違い

$
0
0
すでにTweetでもお知らせしましたが、アメリカ太平洋時間2015年10月20日(日本時間10月21日)に公開されたCritical Patch Updateの一環で、Java SE 8 Update 65とUpdate 66がリリースされています。
JRE(Java Runtime Environment)のセキュリティベースラインが1.8.0_65にあがっていますので、Java SE 8をお使いの方はアップデートされることを強く推奨します。
Oracle Critical Patch Update Advisory - October 2015
http://www.oracle.com/technetwork/topics/security/cpuoct2015-2367953.html
8u65 Update Release Notes
http://www.oracle.com/technetwork/java/javase/8u65-relnotes-2687063.html
JPCERT/CCからも情報が提供されています。
2015年10月 Oracle Java SE のクリティカルパッチアップデートに関する注意喚起
JPCERT-AT-2015-0038 (JPCERT/CC)
https://www.jpcert.or.jp/at/2015/at150038.html
8u65では、以下のリンクにある通り、25件のセキュリティ脆弱性に対する修正が加えられています。このうち24件は認証なしでリモートから任意のコードを実行することができる恐れのある脆弱性です。
Oracle Java SE Risk Matrix
http://www.oracle.com/technetwork/topics/security/cpuoct2015-2367953.html#AppendixJAVA
その他の修正は以下のリンクにある通りです。
Bug Fixes (8u65)
http://www.oracle.com/technetwork/java/javase/2col/8u65-bugfixes-2686589.html
Java SE 6およびJava SE 7も同様にセキュリティベースラインがそれぞれ1.7.0_91と1.6.0_105に上がっていますが、Oracle JDKのJava SE 6、Java SE 7のアップデート無償提供はすでに終了しており、現在はサポート契約を締結されているお客様に対してのみ提供しています。

さて、8u65と8u66がリリースされたわけですが、それぞれの相違点は、種々のメディアからすでに情報が出ている通り、CPUとPSUの違いです。端的に言うと、以下のような感じです。
  • 8u65:4半期毎のCritical Patch Update(CPU)
  • 8u66:CPUに加え、複数の不具合を修正する累積パッチを含むPatch Set Update(PSU)
具体的には、以下のリンクをどうぞ。
Java CPU and PSU Releases Explained
http://www.oracle.com/technetwork/java/javase/downloads/cpu-psu-explained-2331472.html
Java SE Critical Patch Updates (CPU) contain fixes to security vulnerabilities and critical bug fixes. Oracle strongly recommends that all Java SE users upgrade to the latest CPU releases as they are made available. Java SE CPU releases are odd numbered versions (i.e. 7u71, 7u65 – see more on Java SE version numbering schemes here).
Java SE Patch Set Updates (PSU) contain all of fixes in the corresponding CPU, as well as additional non-critical fixes. Java PSU releases should only be used if you are being impacted by one of the additional bugs fixed in that version. The release notes call out the additional fixes available in Java SE PSU releases.
そんなわけで、8u66には8u65のセキュリティ脆弱性に対する修正に加え、以下の修正が入っています。
Bug Fixes (8u66)
http://www.oracle.com/technetwork/java/javase/2col/8u66-bugfixes-2692105.html
8u66で修正された箇所が開発中、もしくはご利用中のアプリケーションに影響するのであれば、ひとまず8u65のインストールを検討してください。もし、8u66の修正によって開発中もしくはご利用中のアプリケーションの不具合が解決する、すなわち所望の動作をするのであれば、有無を言わずに8u66をインストールするしかないでしょう。「あまりそういう切り分けをしたくない」ということでしたら、8u66をインストールされることをおすすめします。

[Database] Apex 5.0.2 was released

$
0
0
原文はこちら。
https://blogs.oracle.com/proactivesupportDevTools/entry/new_apex_version_released_5

APEX (Oracle Application Express) の新バージョン、5.0.2が2015年10月20日にリリースされました。
これはApplication Express 5.0.0、Application Express 5.0.1の累積パッチセットです。
ダウンロード、リリースノート、インストールガイドは以下のリンクからどうぞ。
Oracle Application Express Downloads
http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html
このバージョンで登場した新機能の詳細は、以下のリンクからどうぞ。
Oracle® Application Express
Release Notes - Release 5.0
New Features
https://docs.oracle.com/cd/E59726_01/doc.50/e39143/toc.htm#HTMRN161

[WLS, FMW] Announcing Oracle WebLogic Server 12.2.1

$
0
0
原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/announcing_oracle_weblogic_server_12

Oracle WebLogic Server 12.2.1 (12cR2) が一般提供(General Availability)されました。このリリースは日曜夕方のLarry EllisonのOracle OpenWorld 基調講演でも取り上げられ、本日の Inderjeet SinghのGeneral Sessionおよびプレスリリースで正式に発表されました。
Oracle Fusion Middleware Enhancements Enable Organizations to Innovate and Consolidate On-Premises and in the Cloud
https://www.oracle.com/corporate/pressrelease/fusion-middleware-102615.html
Oracle WebLogic Server 12.2.1はOracle Technology Network (OTN) のOracle Fusion Middlewareダウンロードページ、Oracle WebLogic Serverダウンロードページからダウンロードできます。
Oracle Fusion Middleware Software Downloads
http://www.oracle.com/technetwork/middleware/fusion-middleware/downloads/index.html
Free Oracle WebLogic Server 12.2.1 Installers for Development
http://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-for-dev-1703574.html
製品ドキュメントはOracle Fusion Middleware 12.2.1のすべてのドキュメントとともにUpされており、アクセスできるようになっています。
Weblogic Serverのドキュメント(英語)
http://docs.oracle.com/middleware/1221/wls/index.html
Fusion Middleware 12.2.1のドキュメント(英語)
http://docs.oracle.com/en/middleware/middleware.html
Oracle WebLogic Server 12.2.1は過去最大のWebLogic Server製品のリリースです。今後数週間かけて、動画やブログで新機能を詳細にご紹介する予定です。このエントリが主要な新機能のサマリとお考えください。
  • Multitenancy
  • Continuous Availability
  • Developer Productivity and Portability to the Cloud

Multitenancy

WebLogic Server multitenancyは、アプリケーションのメンテナンスは分離し、フレキシビリティやアジリティは維持しつつ、アプリケーションを統合し、所有コストを削減することができるテクノロジーです。multitenancyを使うと、分離されたドメインパーティション内で実行することで、お互いからは分離している状態を維持しつつも、異なるアプリケーション(やテナント)が同一サーバーJVM(やクラスタ)、WebLogicドメインを共有できます。
ドメインパーティションはWebLogic Serverドメインやサーバーを隔てるサブセットです。ドメインパーティションは、アプリケーションや依存するリソース(データソース、JMSサーバなど)をカプセル化するマイクロコンテナのように振る舞います。パーティションはお互い分離しているので、一方のパーティションに存在するアプリケーションは、同一サーバーや同一ドメインの別のパーティション内で実行するアプリケーションを中断することはありません。素晴らしい機能セットで、こうした分離レベルを提供します。今後詳細をご紹介する予定です。
パーティションは分離してはいますが、多くのリソースを共有しています。実行している物理システムや仮想マシン(VM)、OS、JVM、WebLogic Serverライブラリなどです。彼らは、リソースを共有しているため、彼らはより少ないリソースを使用しています。リソースを共有しているので、より少ないリソースを使います。お客様は、個別のドメインにあるアプリケーションを統合し、より少ないドメインで、より少ない物理システムのより少ないJVMで実行することができます。統合はつまり管理対象のエンティティが減ることで、リソース使用量と所有コストの削減を意味します。
パーティションの利用は簡単です。アプリケーションを変更せずにパーティションにデプロイすることができます。既存のアプリケーションをパーティションに移行するためのツールを提供する予定です。パーティションをあるドメインからエクスポートし、別のドメインにインポートすることができるので、開発環境、、テスト環境、本番環境間やプライベートクラウドとパブリッククラウド間でのアプリケーションの移行が簡単です。パーティションによりアプリケーションの可搬性とアジリティが増すため、開発チーム、DevOpsチーム、テストチーム、本番環境チームに対しより柔軟性と開発やリリース、本番環境のアプリケーションを管理する上でより柔軟性を提供します。
WebLogic Serverの新しいMultitenancy機能はOracle JDK、Oracle Coherence、Oracle Traffic Director、Oracle Fusion Middlewareと統合されており、Oracle DatabaseのPluggable Databaseと緊密に協調するものです。
時間の経過とともにMultitenancyがOracle CloudやOracle Fusion Middlewareでより幅広く利用されていくことを目の当たりにされることでしょう。MultitenancyはWebLogic ServerおよびOracleのための重要な新しい技術革新なのです。

Continuous Availability

Oracle WebLogic Server 12.2.1には、マルチデータセンター構成で計画的・計画外のダウンタイムを最小限に抑えるための新機能が導入されています。WebLogic Serverをご利用のお客様の多くは、ディザスタリカバリアーキテクチャを実装して、アプリケーションの可用性とビジネスの継続性を提供しようとしてきました。WebLogic Serverの新しい連続可用性(continuous availability)機能を使うと、アプリケーションの可用性を向上させながら、そうした構成を簡単に作成、最適化、管理することができます。
  • Zero-downtime patching:パッチ適用時のアプリケーションの可用性を維持するために、クラスタ間でのパッチの適用を制御するオーケストレーションフレームワークを提供します。
  • Live partition migration:同一ドメイン内のクラスタ間のパーティションの移行を可能にします。やはり移行中はアプリケーションの可用性を維持しつつ、効率的にアプリケーションをクラスタ間で移動します。
  • Oracle Traffic Director:高性能、高い可用性を誇るロード・バランシング機能を提供し、パッチ適用時やパーティション移行時に最適化されたトラフィックルーティングとロードバランシングを実現します。
  • Cross-site transaction recovery:サイトに障害が発生したときにアクティブ - アクティブ構成でのトランザクション・リカバリの自動化を可能にします。
  • Oracle Coherence 12.2.1 federated caching:マルチデータセンター構成でデータグリッドの整合性と可用性を維持するため、クラスタやサイト間でデータグリッドのアップデートを複製することができます。
  • Oracle Site Guard:サイト障害とサイトの切り替えに関連したフェイルオーバーおよびフェイルバック操作の自動化ならびに信頼性のあるオーケストレーションを実現します。
これらの機能は、WebLogic ServerとCoherenceの既存の可用性機能と組み合わせ、ビジネスの継続に対する要件を満たすための強力な機能を提供します。これにより、WebLogic ServerとCoherenceが可用性の高いエンタープライズ環境のための最適なアプリケーション・インフラストラクチャになるのです。今後これらの機能を強化し、Oracle CloudとOracle Fusion Middlewareで利用できるようにしていきます。

Developer Productivity and Portability to the Cloud

Oracle WebLogic Server 12.2.1は、開発者の生産性をより向上させ、アプリケーションのクラウドへの移植を可能にします。個々の開発者をアシストするため、Oracle WebLogic Server 12.2.1は、開発者の技術革新のための新しいAPIを含む、Java SE 8およびJava Enterprise Edition (EE) 7 Platformを完全にサポートしています。新しい軽量なQuick Installerを開発者向けに提供しており、これは、テスト環境と本番環境の整合性を保つために簡単にパッチを適用します。デプロイのパフォーマンスを改善し、Oracle Enterprise Pack for Eclipse、Oracle JDeveloperとOracle NetBeansで提供しているIDEのサポートをアップデートしました。WebLogic Serverの開発者のための改善は、標準のJava SE 8のLambdaやStreamを使ってOracle Coherenceのアプリケーションを開発するための劇的な新しい技術革新との両輪をなしています。
チーム開発およびDevOpsツールは、上記の機能を補完し、オンプレミス環境とOracle Cloud間の移植性を提供します。例えば、EclipseベースやMavenベースの開発環境やビルド環境を簡単にOracle Cloudで提供しているDeveloper Cloud Serviceに切り出すことができるので、共有の継続的インテグレーション環境でチームでのアプリケーション開発ができます。このような形で開発されたアプリケーションを、伝統的なWebLogic Serverドメイン、またはWebLogic Serverパーティションにデプロイできますし、Java Cloud Serviceで実行中のOracle WebLogic Server 12.2.1にまもなくデプロイできるようになります。総合的なREST管理APIや自動化されたダイナミック・クラスタの弾力性、パーティション管理、引き続きDockerでの動作保証といった、新しいクラウド管理や移植のための機能を基にして、オンプレミスならびにOracle Cloudの両方で運用するアプリケーションを柔軟にデプロイ、管理、制御するための新しいツール提供されます。を前提にし、Oracleクラウドの両方の生産にアプリケーションの柔軟な導入と管理制御のための新しいツールを提供しています。
これらのすべての機能およびその他の多くの機能によって、Oracle WebLogic Server 12.2.1が技術革新とJavaアプリケーションを構築するお客様にとってのビジネス価値を伴う魅力的なリリースになっています。是非製品をダウンロードし、ドキュメントを確認いただいて、ご自身で評価してください。より詳細の情報をこのブログで発信していきます。

[Java, JavaScript] Fully Transparent Java Objects in Nashorn

$
0
0
原文はこちら。
https://blogs.oracle.com/nashorn/entry/fully_transparent_java_objects_in

NashornのJSAdapterは、JavaオブジェクトをJavaScriptで取り扱うための強力なツールで、完全な透過性を有していますので、これを利用してJavaオブジェクトをラップし、新たなプロパティや挙動を追加することができます。
JSAdapter constructor
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-JSAdapterconstructor
例:
var Date = Java.type('java.time.LocalDate')

function wrapDate(d) {
return new JSAdapter() {
__get__: function(name) {
if (name === 'yesterday') {
return d.minusDays(1)
}
return d[name]
}
}
}

var now = wrapDate(Date.now())
実行すると、このスクリプトは現在時刻を表す Date オブジェクトを JSAdapter でラップし、ラップされたオブジェクトの任意のプロパティに対するアクセスがあると、速やかに __get__ functionが呼び出されます。プロパティ名がアダプタが理解しているもの(ここでは yesterday)であれば、適切な値を返します。
jjs> load('yesterday.js')

jjs> print(now.yesterday)

2015-11-04
その他のすべてのプロパティはラップされたオブジェクトから取得されます。
しかし、これらの例を見ると、ラッピングが完全ではないことを示しています。
jjs> print(now)

<shell>:1 TypeError: [object JSAdapter] has no such function "toString"

jjs> print(now.lengthOfMonth())

<shell>:1 TypeError: [object JSAdapter] has no such function "lengthOfMonth"
ラッパーは、転送するように指示されたラップされたオブジェクトにそれらの要求を転送するだけの、独立したオブジェクトです。

ここでラッパーが完全に透過的でなければならないのは、デフォルトの場合です。ラッパーを完全に透過的にするためにここで必要なのは、あるプロパティを追加するような、すべてのメソッド呼び出しをラップされたJavaオブジェクトへ転送するデフォルトの場合です。このケースの場合、レシーバーと引数を正しく取り扱う必要があるため、プロパティの検索に比べていささか複雑です。受信機と引数を正しく処理する必要があるため場合は、プロパティの検索よりも少し複雑です。

以下の例は、透過呼び出しの転送のために利用可能なイディオムです。
function wrapDate(d) {
return new JSAdapter() {
__call__: function() {
...
var args = [d].concat(Array.prototype.slice.call(arguments, 1))
return Function.call.apply(d[arguments[0]], args)
}
}
}
非常に思慮深いJavaScript中のこの2行で、所望の機能を果たします。各JavaScript関数には、暗黙のローカル変数とargumentsがあり、これは現在起動中の関数に渡されるすべての引数を保持します。このarguments配列は2箇所で利用されています。

最初の行で、実際の呼び出し引数を配列から抽出しています。argumentsの最初の配列要素は呼び出されたメソッド名であって、これは引数になくてもかまいません。しかしレシーバーにとってはこの引数は必要で、 concatを呼び出すことにより、その第1引数を引数の前に連結しています。

2行目では、イディオムが実際に呼び出しを行う Function.call関数を使っています。プロパティ検索を使って、呼び出されるメソッドを表すオブジェクトをラップされたオブジェクトから取り出します。ここで、arguments変数の最初の要素が呼び出されるメソッドの名前であることを思い出してください。レシーバーオブジェクトを含む引数は、すでに引数にargsに存在します。

これで。ラッピングが透過的になっています。
jjs> print(now)

2015-11-05

jjs> print(now.lengthOfMonth())

30

jjs> print(now.yesterday)

2015-11-04
transparent forwarding idiomを説明したサンプルはJDK 9のNashornのソース(samples/jsadapter-fallthrough.js)にあります。

[訳注]
JDK 9 Nashornのソースは、以下のURLにアクセスし、
http://hg.openjdk.java.net/jdk9/jdk9/nashorn
左側のメニューの[browse] をクリック > ディレクトリ samples をクリック > jsadapter-fallthrough.jsをクリックすると確認できます。

[WLS, Java, FMW] WLS Data Source Multitenancy

$
0
0
原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/wls_data_source_mt

Multitenancyや他の新機能については、以下のエントリをご覧ください。
Announcing Oracle WebLogic Server 12.2.1
https://blogs.oracle.com/WebLogicServer/entry/announcing_oracle_weblogic_server_12
[WLS, FMW] Announcing Oracle WebLogic Server 12.2.1
http://orablogs-jp.blogspot.jp/2015/10/announcing-oracle-weblogic-server-1221.html
WebLogic Server 12.2.1で最大かつ最もイノベーティブな機能がMultitenancyです。アプリケーションサーバのすべてのコンポーネントが統合され、Muititenancy機能の一部として主要なコンセプトとして導入されたのが、ドメインをスライスするという考えです。これはPartitionもしくはDomain Partitionと呼んでいます。Partitionはアプリケーションやリソースを特定のTenantのために定義します。ここでPartitionの構成やランタイムはDomain中の他のPartitionとは分離しています。
Multi-tenancyは、複数ドメインやアプリケーション・デプロイメントを管理する上での管理業務のオーバーヘッドを削減し、こうしたデプロイメントの集積度をあげることで、運用上のコストとプラットフォームへのコスト削減をめざしています。

WLS MT機能のコンセプトは、以下のドキュメントに記載されています。
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
End-to-End Lifecycle Management
http://docs.oracle.com/middleware/1221/wls/WLSMT/concepts.htm#WLSMT725.
MTデータソースの詳細は以下のドキュメントに説明があります。
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
Configuring JDBC
http://docs.oracle.com/middleware/1221/wls/WLSMT/config_jdbc.htm#WLSMT614
この記事では、MT環境でのデータソースの利用について概説し、管理コンソールやFusion Middleware Controlでの操作にしぼってご紹介します。

WLS Multi Tenant機能を使わない場合、データソースはシステムリソースともしくはドメインレベルでデプロイすることになりますが、Multi Tenant機能を使う場合、データソースは以下のスコープで定義することができます。
  • ドメイン
    • データソース(グローバルスコープ)
    • データソース(グローバルスコープ)を有するドメインレベル・リソースグループ
    • データソースを有するドメインレベル・リソースグループ・テンプレート
    • パーティション
      • データソースを有するパーティションレベルリソースグループ
      • リソースグループテンプレートに基づくパーティションレベルリソースグループ
      • パーティションレベルのJDBCシステムリソースのオーバーライド
      • パーティションレベルのリソースデプロイメントプラン
      • パーティションレベルにデプロイされたオブジェクト

下表に様々なデプロイメントタイプとデータソース定義の更新やオーバーライドのための機構をまとめました。
データソースのデプロイメントタイプパラメータのオーバーライドのサポート有無
ドメインレベル・システムリソース(リソースグループで範囲指定している場合あり)オーバーライドは非サポート。
データソースの直接変更が必要。
リソースグループテンプレート・システムリソースデータソースを直接変更するか、もしくはリソースグループテンプレートから派生したリソースグループでオーバーライド。
パーティションレベル・リソースグループ内のシステムリソースオーバーライドは非サポート。
データソースの直接変更が必要。
リソースグループ・テンプレートを基にしたリソースグループの、パーティションレベル・システムリソースJDBCシステムリソースのオーバーライドもしくはリソースデプロイメントプランを使ったオーバーライド
ドメインやパーティションにデプロイされた、アプリケーションスコープ・データソースもしくはアプリケーションパッケージ・データソースアプリケーション・デプロイメントプランによるオーバーライド
ドメインやパーティションにデプロイされた、スタンドアロンデータソースモジュールアプリケーション・デプロイメントプランによるオーバーライド
ドメインやパーティションにデプロイされたデータソース定義(Java EE 6)オーバーライドは非サポート。

ドメインレベルのリソースグループに範囲を限定したデータソースやパーティションでデータソースを作成するのは、ドメインレベルのシステムリソースを作成するのと類似していますが、スコープの指定という手順がもう一つ必要です。
管理コンソールやFusion Middleware Controlで、データソース作成するにあたり、最初の手順で、利用可能なスコープをドロップダウンリストから選択します。
WLSTでは、所有者のMBean(ドメイン、リソースグループ、リソースグループテンプレートのMBean)でcreateJDBCSystemResourceを使ってデータソースを作成する必要があります。
以下のドキュメントにあげられているWLSTのサンプルはパーティション化されたドメインをセットアップする上で非常に役立ちます。
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
Configuring JDBC Data Sources: WLST Example
http://docs.oracle.com/middleware/1221/wls/WLSMT/config_jdbc.htm#WLSMT519
ここでは、仮想ターゲット、パーティション、リソースグループテンプレート、リソースグループの作成、全レベルでのデータソースの作成を説明しています。

この記事の残りでは、GUIにフォーカスすることにします。

管理コンソールでは、データソースのサマリをホームページから選択するところから始まります。この最初の図では、4個のデータソースがあって、WLSTを実行して作成したことがわかります。
1個はグローバルスコープ、残りの3個はパーティション中で様々なスコープを有しています。

“ds-using-template” データソースをクリックし、接続プールプロパティを見てみましょう。テンプレートに基づいたデータソースのオリジナルの値が確認できます。オーバーライドはこのレベルでは見えません。

データソースのサマリで[新規]を選択し、汎用データソースを作成すると、最初のページにスコープのドロップダウンリストが現れることが確認できます。このリストは、現在利用可能なスコープに基づいて変化します。

ホームページに戻り、ドメイン・パーティションを選択しましょう。すると2個のリソースグループを有する1個の”partition1”パーティションがあります。

"partition1"をクリックし、オーバーライドのページへ異動すると、"ds-in-template"のJDBCオーバーライドが確認できます。ここで、URLは”otrade”から”otrade2”へオーバーライドされていることに注意してください。

"ds-in-template"のリンクをクリックすると、変更やオーバーライドが可能です。このページではユーザーが"scott"にオーバーライドされていることを確認できます。

[新規]を選択して、新たなJDBCシステムリソースのオーバーライドを作成できます。データソースのドロップダウンボックスにはオーバーライドを作成可能なリソースが並びます。
管理コンソールは現在、パーティション中のすべてのリソースグループを表示しますが、趣旨はリソースグループテンプレートから派生したリソースグループのみでオーバーライドが許可されるべきで、派生していないリソースグループは直接アップデートすべきです。そのため、これらのグループはオーバーライドするべきではありません(将来取り除かれる可能性があります)。

ホームページに戻り、データソースのページで、データソース>セキュリティ>資格証明マッピングと辿り、[新規]をクリックすると、新規のユーザー、リモートユーザー、リモートパスワードを入力できます。

様々なレベルでデータソースのリストを見ることができます。ドメインレベルから、データソースのページの[監視]タブでは、全スコープで実行中のすべてのデータソースを表示します。

パーティションページで"partition1">リソースグループで"partition1-rg">[サービス]>[JDBC]と辿ると、このスコープの1個のデータソースを確認できます。

パーティションスコープのデプロイメントを非パーティションスコープデプロイメントとして取り扱うには、ホームページで[デプロイメント]を選択し、デプロイしたいearファイルもしくはwarファイルを選択します。[アプリケーションインストールアシスタント]で下図のようにスコープを選択することができます。

earファイルやwarファイルのデプロイが完了すると、関連するスコープがある場合、関連づけられたリンクをクリックすると関連モジュールをコンソールで確認できます。最初はデプロイメントプランはありません。

アプリケーションデプロイメントプランの作成は少々複雑ゆえ、管理コンソールを使って自動的に作成することをお勧めします。デプロイ済みデータソースへ遷移し、設定を変更して変更を保存すると、コンソールが関連するデプロイメントプランを作成するので、デプロイメントプランの名前を指定します。

リソースグループテンプレートを派生したパーティション・データソースの属性のうち、ユーザーやパスワード、URL以外のものをオーバーライドしたい場合、リソースデプロイメントプランを作成する必要があるでしょう。
これを管理コンソールで自動的に作成することはできませんが、アプリケーションデプロイメントプランをいじって、リソースデプロイメントプランのようにするか、XMLエディタを使って最初から作成することができます。
これはリソースデプロイメントプランと同等のものです。リソースデプロイメントプランを利用するには、ホームページ>ドメインパーティションでパーティションのリンクをクリックし、リソースデプロイメントプランのパスにパス名を指定します。

Fusion Middlewarwe Controlは管理コンソールと似ていますが、異なるLook&Feelを有しています。
Fusion Middlewarwe Controlは現在セキュリティページを持っておらず、データソースのセキュリティ設定は管理コンソールで実施する必要があります。
JDBCデータソースをWebLogicドメインのドロップダウンから選択すると、下図のようになります。

[作成]をクリックすると、スコープのドロップダウンを含むページが現れます。
リソースグループ名を選択すると、リソースグループ編集のためのページが現れます。
既存のデータソースを選択すると、データソース編集のためのページが現れます。
パーティション名を選択すると、パーティション属性編集のためのページが現れます。

パーティションシステムリソースのオーバーライドは、パーティション名を選択して、[管理]をクリックして、[リソースのオーバーライド]を選択します。

このページは下図のような感じです。

このページでは、リソースグループテンプレートから派生したすべてのリソースグループを表示しています。[オーバーライドあり]にチェックがない場合、[オーバーライドの編集]をクリックして新たなオーバーライドを作成します。
[オーバーライドあり]にチェックがある場合、下図のように[オーバーライドの編集]をクリックして既存のオーバーライドを更新します。

この記事ではMulti Tenant環境でのデータソースの構成を主に取り上げてきました。これはMulti Tenant環境でのアプリケーションの利用は、アプリケーションソフトウェアに対し透過性が非常に高いことをご紹介したかったからです。
重要なことは、アプリケーションサーバーのオブジェクトやコンテナを構成して、必要とされるパーティションやリソースグループにデプロイできる、ということです。

[WLS, FMW] Domain Partitions for Multi-tenancy in WebLogic Server 12.2.1

$
0
0
原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/domain_partitions_for_multi_tenancy

WebLogic Server 12.2.1での顕著な機能改善の一つとして、Multi-tenancyのサポートがあります。 マルチテナント対応のために、ドメインパーティション、リソースグループ、リソースグループテンプレートなどがWebLogic Serverの構成とランタイムに対し追加されました。このエントリではドメインパーティション、リソースグループ、リソースグループテンプレートなどがどういうもので、どういったところに適しているのかをご紹介します。

Domain Partition

ドメインパーティション(以下パーティションと略します)は管理上およびランタイム上のWebLogicドメインをスライスしたものです。多くの場合、WebLogic Serverのmicro-containerとしてパーティションを考えることができます。12.1.3以前では、ドメイン内の管理対象サーバーやセキュリティレルムを定義し、ドメインへアプリケーションやリソースを配置しますが、実行場所を管理するため、管理対象サーバおよびクラスタへのアプリケーションやリソースのターゲットとして指定します。

12.2.1でももちろん同じように管理対象サーバやクラスタをアプリケーションやリソースのターゲットとして指定できますが、ドメイン中の1個以上のパーティションを作成でき、各パーティションには、アプリケーションやリソースを含みます。

各パーティションのターゲットとして、パーティションのアプリケーションやリソースを実行させたい管理対象サーバーのクラスタを指定できます (ターゲットの詳細については後述します)。同一クラスタに複数のパーティションをターゲットにしている場合でも、独立して各パーティションを起動したりシャットダウンしたりすることができます。異なるパーティションに異なるセキュリティレルムを使わせることができます。

加えて、各パーティションに対し、パーティションを制御できるパーティション管理者を指定できます。パーティションがmicro-container、つまりパーティションを含むドメインのスライスを認知しはじめることでしょう。

Resource Group and PaaS


ここで、HRソリューションのJava EEアプリケーションとそのリソースがあると仮定します。そして、財務アプリケーションパッケージとそのリソースのセットが別にあるものとします。12.1.3では、すべてのアプリケーションおよびすべてのリソースをドメインにデプロイします。異なるクラスタをデプロイ対象にするかもしれません。2個のアプリケーションで別々に起動、停止を実施したい場合、実際のところそうする必要があるでしょう。または、12.1.3では別のWebLogicドメインを使う可能性があります。一方のドメインにHRアプリケーション、もう一方に財務アプリケーションといった具合です。確かにこの方法ではターゲット、起動、停止の自由度が増しますが、より多くのドメインを実行するコストも増していきます。

12.2.1では、リソースグループという、関連するJava EEアプリケーションやリソースのコレクションを導入しています。HRアプリケーションとリソースを一つのリソースグループにまとめ、財務アプリケーションとそのリソースを別のリソースグループにまとめることができます。各パーティションには複数のリソースグループを含めることができるので、もっとおもしろいことになります。

先述のように、2個の別のドメインを使おう(一つはHRアプリケーション、もう一つは財務アプリケーション)と考えている場合、2個のパーティションを含む1個のドメインを使うことができます。一つのパーティションにHRアプリケーション、もう一つに財務アプリケーションという具合です。簡単な例として、HRパーティションにはHRアプリケーションとリソースを含むリソースグループがあり、financeパーティションには財務アプリケーションとリソースを含むリソースグループがあるとしましょう。12.2.1では、実のところ各リソースグループをターゲットにします。理に適っていれば、HRパーティションとfinanceパーティションの両方のリソースグループを同一クラスタへ向けることもできます。そして、パーティションはそれぞれ独立して管理できるので、別のパーティションを邪魔せずに起動、停止することができます。クラスタの管理対象サーバはずっと起動したままです。パーティションの立ち上げ、立ち下げ時に、パーティションのリソースグループ中のアプリケーションやリソースが立ち上がったり立ち下がったりするのであって、サーバ全体の立ち上げ・立ち下げではありません。

これはConsolidation(統合)ユースケースで呼ばれることがあります。つまり、複数のドメインを統合し、個別のドメインを一つずつ個別のパーティションにマッピングし、一つの統合ドメインにまとめる、というものです。これはPaaS(platform-as-a-service)ユースケースとも呼ばれます。各パーティションをWebLogic"プラットフォーム”(micro-container)として使い、様々なアプリケーションやリソースをそれぞれの"プラットフォーム"にデプロイする、というものです。

Resource Group Template and SaaS

パーティションとリソースグループを使用して異なる種類の課題を解決する全く別の方法がありますが、そのためにはもう一つのコンセプトが必要です。貴社のデータセンターで運用するHRと財務のアプリケーションを他の企業体にサービスとして提供したい場合を考えましょう。
12.1.3では、クライアントごとに別々のドメインを作成し、人事や財務アプリケーション、リソースを各ドメインで同じように展開することになるでしょう。ドメインテンプレートを使って仕事を簡単にするために、ドメインテンプレートを使用するかもしれませんが、とはいえまだ複数のドメインのオーバーヘッドが存在します。ある顧客は貴社の人事サービスを利用するけれども、別の顧客は人事サービスと財務サービスに加入している場合、1個のドメインテンプレートではうまく行かない場合があります。
12.2.1の用語では、これは2個のリソースグループ、HRリソースグループとFinanceリソースグループのように思えますが、顧客毎にそれぞれ1回動作しています。クライアントごとに1つのパーティションを使用するのが最適なように思えますが、各顧客のパーティションで同一の2つのリソース・グループを繰り返し定義したいとは思わないでしょう。
WebLogic 12.2.1では、そういった状況にまさにぴったりの、リソースグループテンプレートを導入しました。
WebLogicドメイン内のリソースグループテンプレートに人事アプリケーションとリソースを定義します。別のリソースグループテンプレートに、財務アプリケーションとリソースについて同じ操作を行います。顧客ごとのパーティションを作成し、以前のように、各パーティションにリソース・グループを作成します。

しかしこの場合、リソース・グループは、それ自体でアプリケーションやリソースを定義しておらず、代わりにHRリソースグループテンプレートを参照しています。そして、ある顧客が両アプリケーションを使いたい場合には、当該顧客のパーティションに2個目のリソースグループを作成し、もう一方のリソースグループテンプレートに作成したリソースグループを紐付けます。顧客の1社に対応するパーティションを起動すると、WebLogic Serverは基本的にリソースグループテンプレートに定義されているように、当該顧客用のアプリケーションやリソースのコピーを起動します。そして、もう一方の顧客のパーティションを起動すると、WebLogic Serverはそのアプリケーションやリソースの顧客用のコピーを始動します。
これはクラシカルなSaaS(software-as-a-service)ユースケースです。この説明中の“customer(顧客)” という言葉を"tenant(テナント)"に置き換えると、WebLogic Server 12.2.1がパーティション、リソースグループ、リソースグループテンプレートを使って、いかにシンプルにmulti-tenancyをサポートしているかがすぐにおわかりになることでしょう。
パッケージアプリケーションをサービスとして他社へ販売する提供する以外にリソースグループテンプレートを使う方法がありますが、この例はこれらのWebLogic Serverの新機能を一緒に使い全く新しい方法で課題を解決するための基本を説明するための助けになります。

Some Details

WebLogic Server 12.2.1のmulti-tenancyのサポートは非常に豊富な機能を有しており、ここでは一部をご紹介したに過ぎず、ご想像の通り、実際に役立つその他の関連機能があります。このエントリではすべての機能詳細をご紹介できませんが、いくつか簡単にご紹介しましょう。

Resource Overriding

SaaSのユースケースについて、次のように考えるかもしれません。
 「でも各テナントのパーティションをリソースグループテンプレートの設定と全く同じように設定したくない。例えば、別のテナントが異なるデータベースを使用する必要があるため、JDBC接続情報がパーティションごとに異なる必要があるのだ。」
WebLogic 12.2.1を使用すると、リソース・グループ・テンプレートで定義されているアプリやリソースの設定のオーバーライドを作成することができるので、パーティションごとに異なる設定を施すことができます。 (例えば、JDBC接続情報などの)一般的なケースでは、これらのオーバーライドによって、調整が必要な主要属性が公開されます。各パーティション、パーティション内の各リソースに対して、個別にオーバーライドを設定できます。
これらのオーバーライドでほとんどの場合をカバーできると考えていますが、もしさらなる多くの制御が必要な場合は、(再度言いますが、各パーティションに対して個別に)リソースデプロイメントプランを作成することができます。WebLogic Serverのアプリケーションデプロイメントプランに精通している場合、リソース・グループ・テンプレートで定義されたアプリケーション以外のリソースに適用されることを除き、考え方は、ほとんど同じです。

説明のために、リソースグループテンプレートに紐付くリソースグループを含むパーティションを起動する際に、WebLogic Serverが(少なくとも概念的に)何をするのか列挙しておきます。
  • システムはすべてのリソース設定をリソースグループテンプレートから読み込む。
  • パーティションのリソースデプロイメントプランが存在する場合、システムはプランに含まれている調整内容をリソース設定に対して適用する。
  • 最後に、パーティションに対するオーバーライドを作成していた場合、システムがそれらのオーバーライドを適用する。
  • WebLogic Serverは最終的なリソース設定を使って、テンプレートで定義したリソースのパーティションのコピーを作成する。

    Targeting

    このエントリでは、ターゲティングをことを言ってきましたが、WebLogic Server 12.2.1はパーティションやリソースグループのターゲティングを(必要であれば)シンプルなものから非常に洗練されたものまで設定することができます。同僚のJoe DiPolがターゲティングに関するエントリを公開しています。
    Partition Targeting and Virtual Targets in WebLogic Server 12.2.1 
    https://blogs.oracle.com/dipol/entry/partition_targeting_and_virtual_targets

    What Next?

    すべての新機能を紹介しているドキュメントはこちら。
    Oracle Fusion Middleware 12c (12.2.1) Oracle WebLogic Server - Tasks
    http://docs.oracle.com/middleware/1221/wls/index.html
    以下のリンクは、その中でも特にMultitenancyについて取り上げています。
    Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
    http://docs.oracle.com/middleware/1221/wls/WLSMT/ 
    ターゲットに関するJoe DiPolのエントリもお忘れなく。
    Partition Targeting and Virtual Targets in WebLogic Server 12.2.1
    https://blogs.oracle.com/dipol/entry/partition_targeting_and_virtual_targets
    http://orablogs-jp.blogspot.jp/2015/11/partition-targeting-and-virtual-targets.html

    [WLS, FMW] Partition Targeting and Virtual Targets in WebLogic Server 12.2.1

    $
    0
    0
    原文はこちら。
    https://blogs.oracle.com/dipol/entry/partition_targeting_and_virtual_targets

    WebLogic Serverのmulti-tenancyサポートについてご存知ない場合、まずはTim Quinnのエントリを一読することをおすすめします。この中でWebLogic Server 12.2.1のパーティション機能の概要とこの記事で使っているコンセプトを紹介しています。
    Domain Partitions for Multi-tenancy in WebLogic Server
    https://blogs.oracle.com/WebLogicServer/entry/domain_partitions_for_multi_tenancy
    http://orablogs-jp.blogspot.jp/2015/11/domain-partitions-for-multi-tenancy-in.html

    Partition Targeting

    Timのブログでわかるように、ドメインパーティション(以後パーティションと略します)はアプリケーションやリソースの集合を含むWebLogicドメインの管理権限とランタイムのスライスです。これらのアプリケーションやリソースはドメイン中(クラスタ、特定の管理対象サーバ、もしくは管理サーバ自身)で実行する上で必要なものです。
    12.1.3以前では、アプリケーションやリソースのターゲットを個別に指定しています。通常は管理対象サーバやクラスタに対して直接指定します。パーティションの場合、少々異なります。
    • パーティションでは、リソースとアプリケーションはリソースグループとしてまとめられ、リソースグループに対してターゲットを指定します。ターゲットがリソースグループに設定されると、ターゲットはリソースグループ内のすべてのリソースやアプリケーションに対して適用します(リソースグループ内で個別にターゲット指定できません)。
    • パーティション内のリソースグループを仮想ターゲットに対してターゲット指定します。つまり管理対象サーバやクラスタに直接ターゲットを指定しません。

    Virtual Targets

    では、仮想ターゲットとは何でしょうか。WebLogic Serverの仮想ホストやWebサーバの仮想ホストという一般的なコンセプトをご存知であれば、仮想ターゲットが仮想ホストに類似するものと考えることができることでしょう。仮想ターゲットで以下の3点を達成します。
    1. 物理ターゲット(クラスタやサーバ)を提供。仮想ターゲットを物理ターゲットにデプロイし、仮想ターゲットにデプロイされた任意のリソースを、仮想ターゲットをラップする物理ターゲットにデプロイする。
    2. 個別のHTTPサーバを提供。そのため、仮想ターゲットにデプロイされた任意のWebアプリケーションはそれのHTTPサーバで動作する(デフォルトのHTTPサーバではない)。
    3. 特定仮想ターゲットへのインバウンドリクエストのマッピングを(URLの形式で)提供する。結果として特定パーティションへのリクエストのマッピングを提供する。
    それぞれを詳しくみていきましょう。

    Physical Targets

    管理対象サーバまたはクラスタを仮想ターゲットの物理ターゲットとして(VirtualTargetMBeanのsetメソッドもしくはaddTargetメソッドを使用して)指定することができます。VirtualTargetMBeanメソッドは、複数の物理ターゲットをサポートしていても、VirtualTargetに複数の物理ターゲットを設定できないようにするため、現在バリデーションがかかりますのでご注意ください。
    物理ターゲットは以下の2項目を実現します。
    1. 仮想ターゲットのデプロイ先(つまり仮想HTTPサーバが動作する場所)
    2. リソースやアプリケーションを仮想ターゲットにデプロイした場合に使われる場所

    HTTP Server

    各仮想ターゲットには個別にHTTPサーバがあり、仮想ターゲットが動作している(ターゲットとして指定されている)管理対象サーバ(もしくは管理対象サーバのクラスタ)上で遅延初期化されます。仮想ターゲットにデプロイされた任意のWebアプリケーションやリソースはこのHTTPサーバで動作します。これにより、アプリケーションが別の仮想ターゲット(もしくはデフォルトのHTTPサーバ)で動作してもコンテキストパスの衝突は起こりません。

    URL mapping

    リクエストがWebLogic Serverインスタンスに入ると、2個の重要なことが起こる必要があります。
    1. URLが所属するパーティションを識別する必要があります。
    2. HTTPリクエストの場合、適切なHTTPサーバを使うようVirtualTargetを配置する必要があります。
    これはつまり、仮想ターゲットは着信URLが仮想ターゲットに一致するかどうかを確認するため、照合のための情報を必要としている、という意味です。 
    仮想ターゲットには3個の属性があり、以下のマッチングを実現するために設定できます。
    1. Virtual hostnames: 1つまたは複数の仮想ホスト名
    2. uriPrefix: 1個のURI接頭辞パス
    3. port: ポート番号

    Virtual Hostnames

    仮想ターゲットはゼロ個以上の仮想ホスト名を持つことができます。これらのホスト名をクライアントが使うホスト名に対してマッチングします(HTTP 1.1で導入されたフィールド。HTTPを使うとホストによって提供されます)。マッチングは、リテラル文字列の比較ですが、複数のホスト名を指定することができます。これは、リクエストで使われる可能性のあるすべてのホスト名(myserver、myserver.us.com、など)をエイリアシングするのに便利です。また、仮想ホスト名はなくてもかまいません。uriPrefixのみ(もしくはポート番号のみ)を使いたいのであれば、それで大丈夫です。

    URI Prefix

    ホスト名の一致に加えて、例えば"/partition1"といった具合で、特定のURIパスで始まるすべてのリクエストが当該仮想ターゲットに一致するよう、着信リクエストのURIに一致させることができます。

    Port Number

    ポート番号に基づくルーティングは、URLの変更ができない古いクライアントの後方互換性を主たる目的として提供されています。仮想ターゲットで明示的なポート番号もしくはポート番号のオフセットを指定することができます。ポート・オフセットを使う場合、オフセットをサーバのデフォルトチャネルに適用します。仮想ターゲットにベースチャネル名を指定する場合は、特定のベースチャネル名に対して適用します。
    仮想ターゲットにポート番号を指定する場合、WebLogic Serverは自動的に仮想ターゲットのチャネルを実行時に作成するので、こうしたチャネルをご自身で作成する必要はありません。当該チャネル(ポート番号)に入ってくる任意のリクエストは仮想ターゲットに流れます。この点で、ポート番号は、URI接頭辞と仮想ホスト名の両方を上回ります。

    Examples

    下表はどのようにマッチングが機能するかを説明したものです。ここではサーバのデフォルトのポート番号を7001と仮定しています。
    ホスト名uriPrefixポート番号一致するURL一致しないURLNotes
    red
    red.com
    --http://red:7001/myapp
    http://red.com:7001/myapp
    http://red.us.com:7001/myappホスト名は文字列と厳密に一致しなければならない。
    colors
    colors.com
    /red-http://colors:7001/red/myapp
    http://colors.com:7001/red/myapp
    http://red.com/red/myappホスト名とuriPrefixの両方一致しなければならない。
    --7277http://anyhost.com:7277/myapphttp://anyhost.com:7001/myappポート番号7277から到達する任意のリクエストに一致する。その他は一致しない。
    -/red-http://anyhost.com:7001/red/myapphttp://colors.com:7001/blue/myappホスト名を指定しない。この場合、ホスト名は基本的にワイルドカード。

    Tips

    スキームをPick a scheme and stay with it and don't get fancy probing strange combinations. 通常は以下のパターンのうちの一つを使いたいと思うでしょう。
    1. 仮想ホストのみで識別する(red.com, blue.com, green.com)
    2. uriPrefixのみで識別する(colors.com:7001/red, colors.com:7001/blue, colors.com:7001/gree)
    3. ポート番号のみで識別する(colors.com:7277, colors.com:7278, colors.com:7279)
      1. 既存クライアントの後方互換性を保つ必要性から、ポート番号によってのみ識別する
    また、VirtualTargetsはリクエストが特定のサーバやポートへ到達する仕組みとは関係ないことを覚えておいてください。そのため、仮想ホスト名を使う場合、通常適切なホスト名エントリをDNSに作成するか、ロードバランサーを使って特定のサーバやポートへ到達するようにする必要があります。
    一般的なHTTP仮想サーバ(仮想ホストとしても知られています)のコンセプトに詳しくない場合は、このトピックに関する文書を読んでおくべきでしょう。

    Partition Targeting

    最初に述べたように、パーティションのリソース/アプリケーションはリソースグループにまとめられ、リソースグループがターゲットに対して指定されます。いくつか重要なコンセプトがあります。
    1. パーティションの利用可能なターゲット(PartitionMBean availableTargets): これはパーティション内でリソースグループを対象とするために使われる仮想ターゲットのリストです。通常、WebLogic Serverの管理者は数多くの仮想ターゲットをドメイン内に作成し、その後仮想ターゲットのサブセットを特定のパーティションに割り当てます。パーティション内のリソースグループはこれら利用可能なターゲットの一つに対してターゲット指定します。
    2. パーティションのデフォルトターゲット(PartitionMBean defaultTargets):パーティションは、0個以上のデフォルトターゲットを持つことができます。パーティション内のリソースグループを明示的にターゲットとすることができます(ResourceGroupMBeanのメソッドを使ってターゲットの設定や追加ができます)。しかし明示的なターゲットをリソースグループに対して設定していない場合、デフォルトではパーティションのデフォルトターゲットを選択します。
      1. ResourceGroupMBean:useDefaultTargetsというboolean属性があります。この値がTrue(デフォルト値)の場合、明示的なターゲットが設定されていない場合、リソースグループはパーティションのデフォルトターゲットをターゲットとして利用します。この値がfalseの場合、リソースグループはパーティションのデフォルトを使わないので、ターゲットをリソースグループに対して明示的に設定する必要があります。また、明示的にターゲットをリソースグループに設定した場合、パーティションのデフォルトを選択しないことを見越してこのフラグはfalse"へと反転します。
    3. パーティションのeffective targets(事実上のターゲット):パーティションのリソースグループが任意のタイミングで利用する、利用可能なターゲットの(サブ)セット
    そのため、パーティションのターゲッティングのセットアップの共通する流れは以下の通りです。
    1. WebLogic Serverの管理者は、パーティションが利用する仮想ターゲットをドメインレベルで作成
    2. WebLogic Serverの管理者は、パーティションを作成し、パーティションで利用可能なターゲットを各パーティションに使わせたいターゲットのセットに設定
    3. WebLogic Server(もしくはパーティションの)の管理者は、パーティションにリソースグループを作成し、パーティションに対し利用可能なターゲットに基づいて、リソースグループターゲットを設定する(もしくはパーティションのデフォルトを利用する)
    注意いただきたいのは、この最もシンプルな場合では、1個の仮想ターゲットをパーティションに(利用可能なターゲットとして)割り当てるだけで、それをパーティションのデフォルトターゲットにします。そうすることで、パーティションのすべてのリソースグループがこの1個のターゲットを使用します。

    Gotchas

    その他注意すべきことをいくつか。
    1. 仮想ターゲットの占有: ホスト名を持たない、"/"というuriPrefixを持つ仮想ターゲットを定義すると、仮想ターゲットは、ドメインに入ってくるすべてのリクエストを占有します。全く望んではいないでしょうが、これは破綻します。WebLogic Serverの構成検証機能により、そのような仮想ターゲットの作成ができないようになってはいますが、すべてのパターンに対応できているわけではありません。そのため、仮想ターゲットを具体的に意図したリクエストにマッチングさせるように留意する必要があります。
    2. 制限事項: 12.2.1では、ターゲティングに制限があります。その例をご紹介します。
      1. 仮想ターゲットを複数のパーティションで共有できません
      2. 仮想ターゲットはターゲットとして1個の(サーバもしくはクラスタの)セットのみ持つことができます
      3. リソースグループを複数の仮想ターゲットに対してターゲット指定することができます。
        1. ただし、リソースグループに以下のコンポーネントが1個以上含まれていないことが条件です。
    • JMSServer
    • MessagingBridge
    • PathService
    • JMSBridgeDestination
    • FileStore
    • JDBCStore
    • JMSSystemResource

    End-to-End Example

    以下は、WLSTを使って、一つのリソースグループと仮想ターゲットを持つ”Acme”という名前のパーティションを作成する簡単なサンプルです。アプリケーションを当該リソースグループにデプロイします。仮想ターゲットには物理ターゲットとして"myserver"(管理サーバ)があり、"/acme"というuriPrefixを使います。そのため、アプリケーションへアクセスする場合には"/acme"をURLの前に付ける必要があります。最終的に、パーティションがデフォルトでは動作していないので、パーティションが起動します。
    import os,sys,urllib,time
    # Change this to the location of a simple web application.
    APP_PATH='/scratch/tmp/counter.war'
    # Change these to your admin login credentials and connection URL
    USER='admin'
    PASSWORD='admin123'
    T3_URL='t3://localhost:7001'
    # Change this to be the name of the server you want to deploy the app to
    SERVER='myserver'

    print "Connecting to " + T3_URL
    connect(USER,PASSWORD,T3_URL)

    edit()

    domain=getMBean('/')
    tgt=getMBean('/Servers/' + SERVER)

    # Create "Acme" virtual target
    # We set a uriPrefix only (no virtual host names)
    startEdit()
    acmevt=domain.createVirtualTarget('AcmeVT')
    acmevt.addTarget(tgt)
    acmevt.setUriPrefix('/acme')
    # The VT contains a virtual HTTP server. We can configure it
    acmevt.getWebServer().getWebServerLog().setBufferSizeKB(0)
    activate()

    # Create Acme partition and ResourceGroup
    startEdit()
    acmepart=domain.createPartition('Acme')
    acmepart.addAvailableTarget(acmevt)
    acmerg=acmepart.createResourceGroup('SimpleRG')
    acmerg.addTarget(acmevt)
    activate()

    # Deploy the application to SimpleRG in partition Acme
    startEdit()
    progress=deploy(appName='sampleapp',
    path=APP_PATH,
    partition=acmepart.getName(),
    resourceGroup=acmerg.getName(),
    deploymentOrder=10,securityModel='DDOnly')
    activate()
    while not (progress.isCompleted() or progress.isFailed()) :
    os.time.sleep(2)
    progress.printStatus()

    # You must start the partition to get the stuff in it running
    # This is a convenience command to start the partition and
    # wait for it to come up
    startPartitionWait(acmepart)

    # Now hit the webapp at (for example) http://localhost:7001/acme/webapp/webapp.jsp

    [FMW, Java, WLS] Resource Consumption Management in WebLogic Server MultiTenant 12.2.1 to Control Resource Usage of Domain Partitions

    $
    0
    0
    原文はこちら。
    https://blogs.oracle.com/WebLogicServer/entry/using_resource_consumption_management_in

    このエントリは先頃発表されたOracle WebLogic Server 12.2.1の新機能をご紹介する一連のエントリで、その中のすばらしいパフォーママンスの分離機能をご紹介するものです。
    Announcing Oracle WebLogic Server 12.2.1
    https://blogs.oracle.com/WebLogicServer/entry/announcing_oracle_weblogic_server_12
    [WLS, FMW] Announcing Oracle WebLogic Server 12.2.1 
    http://orablogs-jp.blogspot.jp/2015/10/announcing-oracle-weblogic-server-1221.html 
    エンタープライズでの「do more with less(より少ないリソースでよりたくさんのことを)」という強い圧力に伴い、システム管理者やデプロイヤは、エンタープライズデプロイメントのために密度を高め、ハードウェア利用率の向上を常に目指しています。WebLogic Server Multitenantでのmicro-containersやプラガブルなドメインパーティションのサポートにより、システム管理者が、既存のサイロ化されたビジネスに不可欠なJava EEデプロイメントを一つのマルチテナントドメインに配置することができます。
    Domain Partitions for Multi-tenancy in WebLogic Server 12.2.1
    https://blogs.oracle.com/WebLogicServer/entry/domain_partitions_for_multi_tenancy
    [WLS, FMW] Domain Partitions for Multi-tenancy in WebLogic Server 12.2.1
    http://orablogs-jp.blogspot.jp/2015/11/domain-partitions-for-multi-tenancy-in.html

    Announcing Oracle WebLogic Server 12.2.1
    https://blogs.oracle.com/WebLogicServer/entry/announcing_oracle_weblogic_server_12
    [WLS, FMW] Announcing Oracle WebLogic Server 12.2.1 
    http://orablogs-jp.blogspot.jp/2015/10/announcing-oracle-weblogic-server-1221.html
    例えば、システム管理者が、RedとBlueという2つのパーティションを共有JVM(WebLogic Multitenant Serverインスタンス)に作成し、Java EEアプリケーションとリソースをそれらにデプロイするとしましょう。システム管理者は、あるパーティション(ここではBuleとしておきます)のアプリケーションが、サーバ・インスタンスのJVMヒープ、OS(CPU、ファイルディスクリプタ)といったすべての共有リソースを占有し、Redパーティションのアプリケーションがこうしたリソースにアクセスにあたって悪影響を与えることは避けたいと思っていることでしょう。

    Runtime Isolation

    したがって、既存のエンタープライズワークロードを一つのマルチテナントサーバーインスタンスに集約・統合しつつ、システム管理者はドメインパーティションに共存することにより共有されるリソースを、よりうまく管理(追跡、管理、監視、制御)する必要があります。そのために
    • あるパーティションがすべての利用可能なリソースを消費せず、他の共存するパーティションからリソースを使い尽くすことはしません。これにより、システム管理者はすべての共存するパーティションに対し、一貫したパフォーマンスの計画ならびにサポートが可能になります。
    • 共存するパーティションに対し、公平かつ効率的な利用可能なリソースを割り当てます。これにより、システム管理者は集積度を向上して大きなコスト削減を実現しながら、自信を持って、同じ環境に補完的なワークロードを配置することができます。

    Control Resource Consumption Management

    Resources

    Fusion Middleware 12.2.1では、Oracle WebLogic Server Multitenantは、以下のリソースで確立したリソース管理ポリシーをサポートします。
    • Heap Retained(保持しているヒープ):パーティションが保持するヒープのサイズを追跡、制御します。
    • CPU Utilization(CPU利用率):パーティションが利用するCPUの利用率を追跡、制御します。
    • Open File Descriptors(オープン状態のファイルディスクリプタ):パーティションが利用する(File I/O、ソケットなどで利用しているために)開いているファイルディスクリプタを追跡、制御します。

      Recourse Actions

      トリガーが破られると、それに対応してリコースアクションを自動的に実施することでシステム管理者は反応したいと思うかもしれません。WebLogic Serverでは以下のアクションが標準で利用可能です。
      • Notify(通知):閾値を上回ったことを管理者に通知
      • Slow(減速):主にワークマネージャの設定を操作することで、パーティションがリソースを利用できづらくする。特定の状況でシステムに自己修正させる必要があります。
      • Fail(失敗):リソースへのリクエストを却下する。つまり例外を発生させる。現時点ではファイルディスクリプタのみサポート。
      • Stop(停止): 究極のステップとして、現在のサーバーインスタンスのパーティションを保護するため、シャットダウンシーケンスを呼び出す。

        Policies

        Oracle WebLogic Server Multitenantのリソース消費管理機能はシステム管理者がリソースに対しリソース消費管理ポリシーを指定し、ポリシーに反した場合にはWebLogic Serverに対して自動的に特定のリコースアクション(償還要求、返還要求)を実行するよう指示できます。ポリシーは以下の2種類のうち1個として作成されます。
        • Trigger: これは、パーティションのリソース利用状況が予測可能で、「パーティションのリソース利用状況が閾値を超える場合、リコースアクションを実行する」という形の場合に有用です。
        例えば、すべてのヒープを使い切らないようにするというサンプルのリソース消費ポリシーをシステム管理者がBlueパーティションで確立する場合、以下のようになります。

        When the "Retained Heap" (Resource) usage for the "Blue" (Partition) crosses "2 GB" (Trigger), "stop" (Action) the partition.
        Blue(パーティション)の「保持されたヒープ」(リソース)利用状況が2GB(トリガー)を超えた場合、パーティションを「停止」(アクション)する。
        • Fair share: WebLogic Serverのワークマネージャ・フェアシェアポリシーと類似していますが、このポリシーを使うと、システム管理者は有限サイズの共有リソースのシェア(占有率)をパーティションに対して指定することができます。WebLogic Serverは、システム管理者が割り当てた「シェア」を尊重しつつ、競合するコンシューマによって、このリソースが効率的(かつ公平)に共有されることを保証します。
        例えば、リソース消費ポリシーのサンプルとして、BlueパーティションよりもRedパーティションを好むシステム管理者が、CPU利用率のリソースに対するフェアシェアを60:40でRedパーティションが有利になるように設定することができます。
        補完的なワークロードが共存するパーティションにデプロイされている場合、フェアシェアポリシーを使うと、リソースを最大限に活用できます。Blueパーティションにはリクエストがない、もしくは限られたリクエストのみある場合、Redパーティションは利用可能なCPU時間を盗んですべて使い切ることができます。トラフィックがBlueパーティションで再開し、CPUの競合があると、WebLogic Serverは、システム管理者によって設定されたフェアシェア比に従い、CPU時間を割り当てます。このおかげで、これらのリソースのパーティションへの割り当て方針を保持しながら、システム管理者は単一の共有インフラストラクチャを再利用することができ、その結果インフラストラクチャのコストを節約することができます。
        ポリシー設定は、ドメインレベルで定義します。複数のプラガブルなパーティションで再利用することも、パーティションに対して固有に定義することもできます。ポリシー設定は、複数のリソースに対し、独自のビジネス要件を満たすために、トリガベースのポリシーやフェアシェアポリシーの様々な組合せを柔軟にサポートします。ポリシーは、動的に再構成することができるので、ポリシーを必要とするパーティションの再起動は不要です。
        下図は、システム管理者が2個のリソース消費管理ポリシー(より厳しい「トライアル」ポリシーと緩い「承認された」ポリシー)をどのように構成し、個々のドメインパーティションにどのように割り当てるのかを示しています。ヒープとCPUリソースが2個のドメインパーティション割り当てられていて、各々に関連づけられたポリシーによって管理されています。
        WLS 12.2.1 RCM resource manager sample schematic

        Enabling Resource Management

        WebLogic Server 12.2.1のリソース消費管理機能はJDK 8u40のリソース管理機能を使っています。WebLogic Server 12.2.1のリソース消費管理機能を使うには、Oracle JDK 8u40とG1GCが必要です。WebLogic Server Multitenantでは、リソース管理を有効化するために、以下のJVMパラメータを追加する必要があります。
        -XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC

        Track Resource Consumption

        リソース消費のメトリックもパーティション毎に利用でき、監視MBean(PartitionResourceMetricsRuntimeMBean)を使って取得できます。パーティション毎の細かい利用状況のメトリックがこの監視Mbeanから取得できるので、システム管理者はこれらのメトリックを追跡、サイジング、分析、監視、ビジネス固有のウォッチ、ハーベスタWLDFルール構成の目的で利用できます。

        Conclusion

        WebLogic Server Multitenantのリソース消費マネージャはランタイムを分離し、アプリケーションが共有・統合環境で動作する上で必要な保護を提供します。

        For More Information

        このエントリはリソース消費管理機能の表面をちょっと触った程度の内容にすぎません。この機能ならびに、WebLogic Scripting Tool(WLST)やFusion MIddleare Controlを使って、統合されたMultitenantドメインで、リソース消費管理のポリシーを構成する方法、ベストプラクティスを知りたい方は、以下の技術文書に詳細が記載されていますのでご覧ください。
        Resource Consumption Management (RCM) in Oracle WebLogic Server Multitenant (MT) - Flexibility and Control Over Resource Usage in Consolidated Environments
        https://blogs.oracle.com/WebLogicServer/resource/20151027-rcm-overview-entry-siva/wls-1221-rcm-technical-overview-v1.0.pdf 

        以下のWeblogic Server MultiTenantのドキュメントにもこの機能の利用方法の詳細が記載されています。
        Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
        Configuring Resource Consumption Management
        https://docs.oracle.com/middleware/1221/wls/WLSMT/config_rcm.htm

        この機能は、Oracle JDKとWebLogic Serverの緊密な統合の結果です。もしサンフランシスコで開催されるOracle OpenWorld 2015に参加するのであれば、Multitenancy in Java: Innovation in the JDK and Oracle WebLogic Server 12.2.1" [CON8633] (2015年10月28日(水)13時45分 / Moscone South 302)と題したセッションでこの機能の詳細をお伝えします。

        (訳注)
        このセッションのスライドが公開されています。OpenWorldのセッションカタログのページからダウンロードできます。
        Multitenancy in Java: Innovation in the JDK and Oracle WebLogic Server 12.2.1 [CON8633]
        https://events.rainfocus.com/oow15/catalog/oracle.jsp?search=CON8633&search.event=openworldEvent

        [Java, FMW, WLS] Update your Java Version Easily with ZDT Patching

        $
        0
        0
        原文はこちら。
        https://blogs.oracle.com/WebLogicServer/entry/update_your_java_version_easily

        ZDT Patching(Zero Downtime Patching)のもう一つのすばらしい機能として、WebLogic Server実行に使っているJavaのバージョンのアップデートが簡単にできる、というところです。Javaのセキュリティパッチを最新にするのは、非常に重要な継続的な作業です。ZDT Patchingが導入されるまでは、すべての管理対象サーバをJavaの新バージョンに移行するのは簡単ではありませんでした。しかし、ZDT Patchingを使うと、これがシンプルな2段階の手続きで実現できます。

        まず最初に、アップデートされたバージョンのJavaをアップデート対象のすべてのノードにインストールします。この作業は手作業であったり、エンタープライズソフトウェアのインストール管理用ソフトウェアを使うことで可能です。この作業は実行中のサーバに影響を及ぼさないので、計画メンテナンス以外のタイミングで実行できます。ご注意頂きたいのは、以下の2点です。
        • 新しいバージョンのJavaをインストールする際に、既存のJavaのインストールディレクトリを上書きしてはいけません。
        • 新規ディレクトリはすべてのノードで同じでなければなりません
        つづいて、WLSTコマンドを使ってJava rollOutを以下のように実行する、これだけです。
        rolloutJavaHome(“Cluster1”, “/pathTo/jdk1.8.0_66”)
        この例では、管理サーバが、Cluster1というクラスタ内の各ノードを順に再起動するよう調整するためにrollOutを起動しています。管理対象サーバや指定ノードのノードマネージャは停止し、Java実行ファイルへのパスのアップデートを実施します。その後、このrolloutが管理対象サーバとノードマネージャを新しいJavaのパスを使って起動します。

        実に簡単ですね!

        Zero Downtime Patchingを使ったJavaのアップグレードに関する詳細は、以下のドキュメントをご覧ください。
        Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1)
        Overview: Rolling Out a New Java Version
        http://docs.oracle.com/middleware/1221/wls/WLZDT/intro.htm#WLZDT162

        [FMW, WLS] Partition Import/Export

        $
        0
        0
        原文はこちら。
        https://blogs.oracle.com/WebLogicServer/entry/partition_import_export

        このエントリではパーティションのインポート、エクスポートにおいて直面する質問の回答をしようと考えています。エクスポート、インポートに関しては、以下のドキュメントをご覧ください。
        Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
        Exporting and Importing Partitions
        http://docs.oracle.com/middleware/1221/wls/WLSMT/export_import.htm#WLSMT636

        How to know the status of exportPartition, importPartition WLST commands(WLSTコマンド[exportPartition / importPartition]の実行状態を知るには?)

        エクスポートのためのWLSTコマンドは以下のようです。
        exportPartition(partitionName, expArchPath, [includeAppsNLibs], [keyFile])
        このコマンドはexportPartitionタスクを実行し、exportPartitionの操作の状態をオブジェクトに入れて返します。値と状態の関連付けは以下の通りです。
        1. NOT_STARTED = -1
        2. STARTED = 1
        3. FINISHED = 2
        4. FAILED = 3
        exportPartitionが成功したかどうか、状態を確認するには、 オブジェクトに含まれるコマンドの出力を取得する必要があります。
        expPartStatus = exportPartition('partition1','/home/partitionadmin/exportedPartitions')
        while (expPartStatus.getState() != 2 and expPartStatus.getState() != 3):
        os.time.sleep(10)

        if(expPartStatus.getState() == 3):
        raise expPartStatus.getError()
        返却されたオブジェクトには2個のメソッドgetState()とgetError()があることがわかります。名前で意味がわかりますね。
        getError() は実際にJavaのExceptionオブジェクトを返すので、java.lang.Exceptionオブジェクトで利用可能なすべてのメソッドを呼び出すことができます。例えば以下のメソッドを呼び出すとスタックトレースを出力します。
        expPartStatus.getError().printStackTrace() 
        importPartitionでも同様です。

        How to use user keys for encryption of secure attributes during exportPartition(exportPartition実行中に保護対象の属性の暗号化のためのユーザー鍵を使うには?)

        exportPartition実行中に、ユーザーが保護すべき属性をユーザーが持つ鍵で暗号化する場合があります。同様に、importPartition実行中に保護すべき属性を復号したい、という場合があります。

        exportPartitionでは、オプションとしてString(文字列)の引数に、平文で指定されているユーザー鍵のファイルの場所を指定することができます。
        cat /home/partitionadmin/exportPartition/userkey
        thequickbrownfoxjumpsoverthelazydog$--|--$
        exportPartition実行中に、このファイルを使って保護属性を暗号化することができます。
        expPartStatus = exportPartition('partition1','/home/partitionadmin/exportPartition',true,'/home/partitionadmin/exportPartition/userkey')
        importPartitionの場合も同様に属性を復号することができます。
        impPartStatus = importPartition('/home/partitionadmin/exportPartition/partition1.zip',keyfile='/home/partitionadmin/exportPartition/userkey')

        How to resolve ResourceGroupTemplate Name conflicts during importPartition(importPartition実行中にResourceGroupTemplateの名前が衝突した場合の解決方法)

        パーティションをドメインにインポートしている際に、ドメインにすでにインポートしようとしているものと同じ名前のResourceGroupTempateが存在する可能性があります。この場合、状況にあわせて、どちらのResourceGroupTemplateをインポートされるパーティションが使うのか指示する必要があります。
        1. ドメイン中の既存のResourceGroupTemplateがimportedPartitionが必要とするすべてのリソースを有している場合、createNewオプションで明示的にfalseを設定することで、ResourceGroupTemplateのインポートをスキップすることができます。
          impPartStatus = importPartition('/home/partitionadmin/exportPartition/partition1.zip',createNew=false)
        2. 既存のResourceGroupTemplateがインポート対象のパーティションに合わない場合、createNewオプションにtrueを設定してimportPartitionを呼び出すことができます。これにより、新たなResourceGroupTemplateを作成しますが、その際、ResourceGroupTemplateの名前の末尾には幾何学的に増加する番号が追加されます。
          例えば既存のResourceGroupTemplate名が"cokeRGT"である場合、新しいResourceGroupTemplateは"cokeRGT1"という名前で作成されます。そしてインポートされたパーティションはこの新たに作成されたResourceGroupTemplateを参照します。
          impPartStatus = importPartition('home/partitionadmin/exportPartition/partition1.zip',createNew=true)

        [WLS, Database, FMW] Data Source System Property Enhancement in WLS 12.2.1

        $
        0
        0
        原文はこちら。
        https://blogs.oracle.com/WebLogicServer/entry/data_source_system_property_enhancement

        以前のエントリで、システムプロパティを使ってドライバ接続プロパティを設定する話を紹介しました。これは順に自動的にOracle Databaseのセッションに値を設定する、というものでした。
        Setting V$SESSION for a WLS Datasource
        https://blogs.oracle.com/WebLogicServer/entry/setting_v_session_for_a
        [WLS] Setting V$SESSION for a WLS Datasource
        http://orablogs-jp.blogspot.jp/2014/08/setting-vsession-for-wls-datasource.html 
        このエントリに対し、この機能には制限があるというコメントをいただきました。
        • アプリケーションサーバが開始するまで利用できないので、コマンドラインで設定できない値がある(明らかにプロセスIDは設定できない)
        • コマンドラインで設定した値は、サーバーのすべての環境に対し有効であることを示唆している。こうした値は、プログラム名のような値であればよいが、データソース固有の値や新たなWebLogic Server Multitenancy機能で利用可能なパーティション名には適していない。
        • 最近関わっていたアプリケーションでは、正常なシャットダウンを実行するため、セッションに接続されたデータソースをホストするサーバへ接続することが望ましかった。この場合、URLを生成するために追加の情報が必要だった。
        これらのすべてのケースは、今回強化されたシステムプロパティ機能で対応できるようになっています。

        元々、システムプロパティの値を使ったドライバプロパティの設定をサポートしていましたが、12.2.1では、グラフィカル・ユーザ・インタフェースおよびWLSTスクリプトでドライバプロパティの別のセットを再度登録しなくてすむよう、古い機能の上に新機能をオーバーロードしています。下表に記載のサポート対象の変数(複数可)を文字列に指定することで実現します。これらの1個以上の変数がシステムプロパティに含まれる場合、対応する値で置換されます。変数に値がない場合には置換は行われません。これらの変数がシステムプロパティにない場合、値をシステムプロパティ名として使用します。
        変数説明
        ${pid}ManagementFactory.getRuntimeMXBean().getName() の前半部分(@まで)
        ${machine}Second half of ManagementFactory.getRuntimeMXBean().getName() の後半部分
        ${user.name}Javaシステムプロパティ user.name
        ${os.name}システムプロパティ os.name
        ${datasourcename}JDBCディスクリプタからのデータソース名。ただし、パーティション名は含まない。
        ${partition}パーティション名もしくはDOMAIN
        ${serverport}WebLogic Serverのサーバリスニングポート
        ${serversslport}WebLogic ServerのサーバSSLリスニングポート
        ${servername}WebLogic Serverのサーバ名
        ${domainname}WebLogic Serverのドメイン名

        以下の例はサンプルプロパティを示しています。
        <properties>
        <property>
        <name>v$session.program</name>
        <sys-prop-value>WebLogic ${servername} Partition ${partition}</sys-prop-value>
        </property>
        </properties>
        この例では、myserverで動作する v$session.program が “WebLogic myserver Partition DOMAIN”に置換されます。

        この機能の最大の制限は、v$sessionの関連するカラム(列)の文字制限です。上限を超えると、接続作成に失敗します。

        Oracle Databaseのv$session値と組み合わせてこの拡張機能を利用すると、接続ソースに関する情報追跡のための強力な機能に仕立てることができます。

        [Java] When is the next Java update?

        $
        0
        0
        原文はこちら。
        https://blogs.oracle.com/java-platform-group/entry/when_is_the_next_java

        "Java update available -- a new version of Java is ready to be installed..."
        (Javaのアップデートが利用できます-- 新しいバージョンのJavaのインストール準備ができました)
        OracleのJava SEは、Oracle Critical Patch Update(以下CPU)のスケジュールでアップデートされます。
        Critical Patch Updates, Security Alerts and Third Party Bulletin
        http://www.oracle.com/technetwork/topics/security/alerts-086861.html
        これらのアップデートの日程は1年先の情報まで公開しており、このスケジュールは、システム管理者がシステム全体でソフトウェア管理する上で役立ちます。他の機能、セキュリティベースラインと組み合わせることで、クライアントシステムは、新しいセキュリティ更新プログラムを検出することができますし、アップデートを提供し、クライアントシステムへの攻撃を減少させることによって、クライアントシステムの動作を調整することができます。セキュリティベースラインを下回るバージョンが必要な場合、システム管理者はデプロイメントルールセットを使って互換性を管理することができます。

        The Security Baseline

        セキュリティベースラインは、Java 7 upadte 10(2012年12月)でJREの有効期限と組み合わさり、新しい挙動をするようになりました。
        Java™ SE Development Kit 7, Update 10 (JDK 7u10)
        http://www.oracle.com/technetwork/java/javase/7u10-relnotes-1880995.html
        これまでは、JDK 1.4以降、どのJavaバージョンに最新のセキュリティパッチが含まれているかを特定してきました。
        JDK 5.0u22 Release Notes
        Changes in 1.5.0_12
        http://www.oracle.com/technetwork/java/javase/releasenotes-142123.html#150_12
        各主要なJavaバージョン(Java 6、Java 7、Java 8)で異なるベースラインのバージョンがあり、JREは主として二つの方法で更新対象であるかどうかを識別します。
        • JREは定期的にセキュリティベースラインをチェックし、新しいバージョンが利用可能であるかどうかを確認します。セキュリティベースラインを下回っていることを検出すると、セキュリティベースライン要件を満たすバージョンのアップデートが必要と判断します。
        • この定期的な検査のスケジュールは、システム管理者が制御できます。
          What is Java Auto Update? How do I change notify settings?
          https://www.java.com/en/download/help/java_update.xml
        • クライアントマシンが何らかの理由でセキュリティベースラインに到達できない場合、最終的に組み込まれている有効期限に到達します。有効期限は、各リリースノートで公開されていますが、通常は次回の定期CPUの1ヶ月後です。
          Java Development Kit 8 Update Release Notes
          http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html
          この有効期限は組み込まれており、制御することはできません。
        CPUに加え、Patch Set Update (PSU) とよばれる別のリリースタイプがあります。これには重要度のそれほど高くない変更が追加されています。PSUのバージョンは数値上セキュリティベースラインより大きな値ですが、PSUには、セキュリティベースラインに対応するCPUとまったく同じ重要なパッチが含まれています。例えば、執筆時点では、セキュリティベースラインは1.8.0_65で、別のPSUである1.8.0_66には、追加の変更が含まれています。重要なパッチだけを適用したいのであれば、PSUに含まれる変更を適用する必要はありませんし、個別にテストすることができます。次の定期CPUでは、1.8.0_66からの変更が含まれます。

        What happens when the security baseline changes or the expiration date passes

        クライアントが現在のセキュリティベースラインを下回っていることを検出した場合、通常は2個のタスクを実行します。
        • エンドユーザーに対し、新しいアップデートをインストールするように促す
        • インストールされたJREに対する潜在的な攻撃面を減らす
        「JREの有効期限が切れた、もしくはセキュリティベースラインを下回ったか」という質問に対してH、RIA(Rich Internet Application Deployment Process)デプロイメントプロセスでこれらの変更を説明しています。
        Rich Internet Application Deployment Process
        http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/deployment_flow.html
        「このRIA用のルールは存在するか」という質問に対しては、プロンプトの管理やセキュリティベースラインを下回るJavaバージョンを利用する必要があるデスクトップ管理者は、デプロイメントルールセットを使って対応することができます。
        Deployment Rule Set by Example
        https://blogs.oracle.com/java-platform-group/entry/deployment_rule_set_by_example
        攻撃面の減少は(ブラウザを通じて)リッチ・インターネット・アプリケーションに適用されます。

        Planning for updates

        この先1年のCPUの予定が公開されているので、システム管理者はJavaのアップデートをクライアントシステムに展開する計画を事前に計画しておくべきです。デプロイメントルールセットを使って、種々の理由で最新のJava Runtime Environmentを利用できないアプリケーションについて、既知の安全なアプリケーションが特定の古いJREを使うことができるか、ホワイトリストに登録しておく必要があります。CPUはJava 6、Java 7でも商用製品のJava SE Advancedを通じて、その他の管理ツールとともに利用することができます。

        数多くの管理対象システムに対し、四半期毎にJavaを展開しなければならない管理者は、商用製品であるJava SE Advancedを検討されてもよいかと思います。Java SE Advancedでは、大規模にJavaを管理する上で使いやすいツールを提供しています。
        Oracle Java SE Advanced & Suite Products
        http://www.oracle.com/technetwork/jp/java/javaseproducts/overview/index.html(日本語)
        http://www.oracle.com/technetwork/java/javaseproducts/overview/index.html(英語)

        Additional Resources

        [WLS, FMW] Oracle WebLogic Server 12.2.1 Running on Docker Containers

        $
        0
        0
        原文はこちら。
        https://blogs.oracle.com/WebLogicServer/entry/oracle_weblogic_server_12_21

        Oracle WebLogic Server 12.2.1はDockerコンテナ上での動作を保証しています。この動作検証・保証の一環として、Oracle WebLogic Server 12.2.1インストールイメージとOracle WebLogic Serverドメインイメージを作成するためのDockerファイルをGitHubにUpしました。
        WebLogic on Docker
        https://github.com/oracle/docker/tree/master/OracleWebLogic/
        これらのイメージは既存のOracle Linuxイメージの拡張として構築されています。
        oraclelinux - Docker Hub
        https://registry.hub.docker.com/_/oraclelinux/
        これを使う上での助けとなるよう、使い始めるにあたってのサンプルとして、DockerfilesとスクリプトをGitHubにアップしました。

        Dockerはユーザーが分散アプリケーションをビルド、パッケージ、リリース、実行することができるプラットフォームです。
        Docker
        https://www.docker.com/
        Dockerユーザーは自身が作成したアプリケーションや依存するライブラリやファイルをDockerイメージに固めます。DockerイメージはLinux環境で配布できる可搬性のあるアーティファクトで、この配布イメージを使ってコンテナを始動することができ、これによって同一ホストのOS上の別のコンテナ上で動作する別のアプリケーションとは分離して、アプリケーションを実行することができます。

        下表は種々のWebLogic Serverバージョンで動作保証されている組み合わせです。Dockerイメージを構築する場合には、これらのOracle WebLogic Server、JDK、Linux、Dockerのバージョンの組み合わせを使うことができます。
        Oracle WebLogic ServerのバージョンJDKのバージョンホストOSカーネルバージョンDockerのバージョン
        12.2.1.0.08Oracle Linux 6 UL 6+UEK Release 3 (3.8.13)1.7+
        12.2.1.0.08Oracle Linux 7 UL 0+UEK Release 3 (3.8.13) Or RHCK 3 (3.10)1.7+
        12.2.1.0.08RedHat Linux 7+RHCK 3 (3.10)1.7+
        12.1.3.0.07/8Oracle Linux 6 UL 5+UEK Release 3 (3.8.13)1.3.3+
        12.1.3.0.07/8Oracle Linux 7 UL 0+UEK Release 3 (3.8.13) Or RHCK 3 (3.10)1.3.3+
        12.1.3.0.07/8RedHat Linux 7+RHCK 3 (3.10)1.3.3+
        (訳注)
        RHCKとあるのは、Red Hat Compatible Kernel(Red Hat互換カーネル)の略です。

        この表に記載されている以外のLinuxホストで動作する、動作保証されているDockerコンテナのOracle WebLogic Serverをサポートします。ただし、Kernel 3.8.13以上でDockerコンテナをサポートするものに限ります。詳しくはSupport Statementをご覧ください。
        Support for Oracle WebLogic Server Running in Docker Containers on Non-Certified Linux Host Operating Systems (Doc ID 2017945.1)
        https://support.oracle.com/rs?type=doc&id=2017945.1
        現在のOracle WebLogic Serverのサポート対象構成に関する詳細は、以下のリンクをご覧ください。
        Supported Virtualization and Partitioning Technologies for Oracle Fusion Middleware
        http://www.oracle.com/technetwork/middleware/ias/oracleas-supported-virtualization-089265.html
        これらのDockerfilesとスクリプトを使って、一つのホストOSもしくはVM上で動作する、開発、本番の両環境を含めて、クラスタ構成および非クラスタ構成のOracle WebLogic Serverのドメインを作成できます。 生成されたドメインの各サーバはそれぞれDockerコンテナで動作します。他のサーバと必要に応じて通信することができます。

        アプリケーションやサービスのコンテナ化は”Docker-way”に沿ったトポロジであり、このトポロジはすべてのリソース、共有ライブラリやデプロイメントを含む管理サーバのみを実行するよう設計されたコンテナで構成されています。これらのDockerコンテナは、すべて単一の物理または仮想サーバーのLinuxホスト、もしくは複数の物理または仮想サーバのLinuxホスト上に置くことができます。WebLogic Serverドメインを持つイメージを作成するためのGitHub上のDockerfilesを使い、これらの管理サーバコンテナを起動することができます。
        Dockerfilesやスクリプトの使い方に関するドキュメントは、OTNのホワイトペーパーをご覧ください。
        Oracle WebLogic Server on Docker Containers
        http://content.oracle.com/site/pd/fmw/products/CAF/weblogic-server/cnt2359150.pdf
        Oracle WebLogic Serverのビデオとデモでは、当社の動作検証作業の成果を紹介し、Dockerコンテナ上で動作するWebLogic Server 12.2.1のデモをご覧いただけます。
        WebLogic 12.2.1 on Docker Containers
        https://www.youtube.com/watch?v=cgf8wzXnmb4
        DockerコンテナでWebLogic Serverの異なる構成を実行された際のフィードバックをお待ちしております。

        [FMW, WLS, Java] Create WebLogic Server Domain with Partitions using WLST in 12.2.1

        $
        0
        0
        原文はこちら。
        https://blogs.oracle.com/WebLogicServer/entry/create_weblogic_server_domain_with

        Oracle WebLogic Server 12.2.1ではMultitenancyをサポートしています。WebLogic Server Multitenancyでは、WebLogic Serverをドメインだけでなく、一つ以上のパーティションを使って構成することができます。パーティションにはWebLogic Server Multitenancyで導入された新たな要素(リソースグループ、リソースグループテンプレート、仮想ターゲットなど)が含まれています。パーティションを持つドメインを構成する場合、通常のWebLogicドメインの構成に比べて追加の手順が必要です。こうした新しいWebLogic Server Multitenancyに関連するコンセプトは、末尾のReferencesセクションに記載のドキュメントをご覧ください。

        OracleはFusion Middleware Control(FMWC)で(Restricted JRFテンプレートを使い)WebLogicドメインを作成することを推奨していますが、WLSTを使ってWebLogic Serverこのエントリでは、2個のパーティションを持つWebLogicドメインをWLSTで作成する方法をご紹介します。
        Using Fusion Middleware Control to Manage WebLogic Server
        http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/manage_wls_fmc/obe.html
        Oracle® Fusion Middleware Domain Template Reference 12c (12.2.1)
        Oracle Restricted JRF Template
        https://docs.oracle.com/middleware/1221/wls/WLDTR/fmw_templates.htm#WLDTR524
        Oracle® Fusion Middleware Oracle WebLogic Scripting Tool 12c Release 1 (12.1.1)
        Creating WebLogic Domains Using WLST Offline
        http://docs.oracle.com/cd/E24329_01/web.1211/e24491/domains.htm#WLSTG156

        1.Domain Topology

        このエントリでは、以下のような構成のドメインを作成します。
        • adminという1個の管理サーバと、パーティションcoke、パーティションpepsiがある
        • パーティションcokeには、リソースグループcoke-rg1があり、仮想ターゲットcoke-vtに向けられている
        • パーティションpepsiには、リソースグループpepsi-rg1があり、仮想ターゲットpepsi-vtに向けられている
        • アプリケーションhelloTenant.earをドメイン、パーティションcokeのリソースグループcoke-rg1、パーティションpepsiのリソースグループpepsi-rg1にデプロイする。
        ドメイントポロジーは以下のようになっています。
        • ドメイン
          • セキュリティ構成
            • レルム:myrealm
            • レルム:coke_realm
            • レルム:pepsi_realm
          • Server: admin(管理サーバ)
          • 仮想ターゲット:coke-vt
          • 仮想ターゲット:pepsi-vt
          • パーティション:coke
            • リソースグループ:coke-rg1
              • アプリケーションデプロイメント:helloTenant-coke
              • デフォルトターゲット:coke-vt
          • パーティション:pepsi
            • リソースグループ:pepsi-rg1
              • アプリケーションデプロイメント:helloTenant-pepsi
              • デフォルトターゲット:pepsi-vt
          • アプリケーションデプロイメント:helloTenant
          このドメイントポロジーには、リソースグループテンプレートのような別のMultitenancy関連のコンセプトを含んでいないことにご注意ください。このエントリでは取り扱いません。別のMultitenancy関連のコンセプトについて知りたい方は、Referencesセクションをチェックしてください。

          2. Create a domain with partitions

          上記のトポロジーを有するドメインを作成するには、以下の手順が必要です。
          • 通常のWebLogicドメインを作成
          • ドメインを起動
          • ドメインにパーティションを作成
            • パーティション用セキュリティレルムを作成
            • パーティション用のユーザーを作成
            • セキュリティレルムのグループにユーザーを追加
            • 仮想ターゲットを作成
            • パーティションを作成
              • リソースグループの作成
              • 仮想ターゲットをデフォルトターゲットに設定
              • パーティション用のセキュリティIDD(アイデンティティドメイン)を設定
          • サーバを再起動
          • パーティションの開始
          詳細を以下でご紹介します。

          2.1 Create a traditional WLS domain

          構成ウィザードを使って通常のWebLogicドメインを作成することができます。コマンドスクリプトから構成ウィザードを起動します。
          sh $MW_Home/oracle_common/common/bin/config.sh
          設定はすべてデフォルトですが、ドメイン名、管理者ユーザー名、パスワードは以下のものを使います。
          • ドメイン名:base_domain
          • 管理者ユーザ名:weblogic
          • 管理者ユーザのパスワード:welcome1

          2.2 Start the domain

          cd $MW_Home/user_projects/domains/base_domain/
          sh startWebLogic.sh

          2.3 Create a partition: coke in a domain

          WLSTを開始するには以下の手順が必要です。以下のコマンドでWLSTを起動します。
          sh $MW_Home/oracle_common/common/bin/wlst.sh
          管理サーバadminに管理ユーザweblogicとその資格証明を使って接続してから、以下のWLSTコマンドのすべてを実行できます。
          connect("weblogic", "welcome1", "t3://localhost:7001")
          これで、パーティションcokeのセットアップのためのWLSTコマンド実行の準備ができました。パーティションcokeには以下の設定を使います。
          • パーティション名:coke
          • パーティション管理者ユーザ名:mtadmin1
          • パーティション管理者ユーザのパスワード:welcome1
          以下の手順で、パーティション用のセキュリティレルムとユーザーを作成します。

          2.3.1 Create a security realm for the partition 

          標準的なWebLogic ServerのAPIを使ってセキュリティレルムを作成します。
          edit()
          startEdit()
          realmName = 'coke_realm'
          security = cmo.getSecurityConfiguration()
          print 'realm name is ' + realmName
          realm = security.createRealm(realmName)
          # ATN
          atnp = realm.createAuthenticationProvider(
            'ATNPartition','weblogic.security.providers.authentication.DefaultAuthenticator')
          atna = realm.createAuthenticationProvider(
            'ATNAdmin','weblogic.security.providers.authentication.DefaultAuthenticator')
          # IA
          ia = realm.createAuthenticationProvider(
            'IA','weblogic.security.providers.authentication.DefaultIdentityAsserter')
          ia.setActiveTypes(['AuthenticatedUser'])
          # ATZ/Role
          realm.createRoleMapper(
            'Role','weblogic.security.providers.xacml.authorization.XACMLRoleMapper')
          realm.createAuthorizer(
            'ATZ','weblogic.security.providers.xacml.authorization.XACMLAuthorizer')
          # Adjudicator
          realm.createAdjudicator('
            ADJ','weblogic.security.providers.authorization.DefaultAdjudicator')
          # Auditor
          realm.createAuditor('
            AUD','weblogic.security.providers.audit.DefaultAuditor')

          # Cred Mapper
          realm.createCredentialMapper(
            'CM','weblogic.security.providers.credentials.DefaultCredentialMapper')
          # Cert Path
          realm.setCertPathBuilder(realm.createCertPathProvider(
            'CP','weblogic.security.providers.pk.WebLogicCertPathProvider'))
          # Password Validator
          pv = realm.createPasswordValidator('PV',
            'com.bea.security.providers.authentication.passwordvalidator.SystemPasswordValidator')
          pv.setMinPasswordLength(8)
          pv.setMinNumericOrSpecialCharacters(1)
          save()
          activate()

          2.3.2 Add a user and group to the security realm for the partition

          ユーザを作成し、ユーザをレルムのセキュリティグループに追加します。このユースケースでは、パーティションcokeの管理ユーザ名とパスワードはmtadmin1 と welcome1です。
          edit()
          startEdit()
          realmName = 'coke_realm'
          userName = 'mtadmin1'
          groupName = 'Administrators'
          print 'add user: realmName ' + realmName
          if realmName == 'DEFAULT_REALM':
            realm = cmo.getSecurityConfiguration().getDefaultRealm()
          else:
            realm = cmo.getSecurityConfiguration().lookupRealm(realmName)
          print "Creating user " + userName + " in realm: " + realm.getName()
          atn = realm.lookupAuthenticationProvider('ATNPartition')
          if atn.userExists(userName):
            print "User already exists."
          else:
            atn.createUser(userName, '${password}', realmName + ' Realm User')
          print "Done creating user. ${password}"
          print "Creating group " + groupName + " in realm: " + realm.getName()
          if atn.groupExists(groupName):
            print "Group already exists."
          else:
            atn.createGroup(groupName, realmName + ' Realm Group')
          if atn.isMember(groupName,userName,true) == 0:
            atn.addMemberToGroup(groupName, userName)
          else:
            print "User is already member of the group."
          save()
          activate()

          2.3.3 Create a virtual target for the partition

          この仮想ターゲットは管理サーバをターゲットにします。UriPrefixは /coke です。このurl接頭辞は、WebLogic ServerのMBeanServerへのJMX接続を作成するために使われます。
          edit()
          startEdit()
          vt = cmo.createVirtualTarget("coke-vt")
          vt.setHostNames(array(["localhost"],java.lang.String))
          vt.setUriPrefix("/coke")
          as = cmo.lookupServer("admin")
          vt.addTarget(as)
          save()
          activate()

          2.3.4 Create the partition: coke

          パーティション名はcokeです。パーティションcokeを仮想ターゲットcoke-vtにターゲット指定します。
          edit()
          startEdit()
          vt = cmo.lookupVirtualTarget("coke-vt")
          p = cmo.createPartition('coke')
          p.addAvailableTarget(vt)
          p.addDefaultTarget(vt)
          rg=p.createResourceGroup('coke-rg1')
          rg.addTarget(vt)
          realm = cmo.getSecurityConfiguration().lookupRealm("coke-realm")
          p.setRealm(realm)
          save()
          activate()

          2.3.5 Setup IDD for the partition

          パーティションのプライマリ・アイデンティティドメイン(IDD)を設定します。
          edit()
          startEdit()
          sec = cmo.getSecurityConfiguration()
          sec.setAdministrativeIdentityDomain("AdminIDD")
          realmName = 'coke_realm'
          realm = cmo.getSecurityConfiguration().lookupRealm(realmName)
          # ATN
          defAtnP = realm.lookupAuthenticationProvider('ATNPartition')
          defAtnP.setIdentityDomain('cokeIDD')
          defAtnA = realm.lookupAuthenticationProvider('ATNAdmin')
          defAtnA.setIdentityDomain("AdminIDD")
          # Partition
          pcoke= cmo.lookupPartition('coke')
          pcoke.setPrimaryIdentityDomain('cokeIDD')
          # Default realm
          realm = sec.getDefaultRealm()
          defAtn = realm.lookupAuthenticationProvider('DefaultAuthenticator')
          defAtn.setIdentityDomain("AdminIDD")
          save()
          activate()

          2.3.6 Restart the Server

          セキュリティ設定の変更を反映するため、WebLogic Serverを再起動します。

          2.3.7 Start the partition

          パーティションがリクエストを受け付けるようにするために、以下の手順が必要です。
          edit()
          startEdit()
          partitionBean=cmo.lookupPartition('coke')
          # start the partition (required)
          startPartitionWait(partitionBean)
          save()
          activate()

          2.4 Create another partition: pepsi in a domain

          2.3の手順を繰り返し、別のパーティションpepsiを作成します。ただし、以下の値はパーティションcokeと違うものを使います。
          • パーティション名:pepsi
          • パーティション管理者名:mtadmin2
          • パーティション管理者のパスワード:welcome2
          • セキュリティレルム:pepsi_realm
          • アイデンティティドメイン名:pepsiIDD
          • 仮想ターゲット名:pepsi-vt
          • リソースグループ名:pepsi-rg1

          2.5 Deploy User Application

          これでドメインが利用できるようになりましたので、アプリケーションのearファイルをデプロイしましょう。今回はhelloTenant.earというアプリケーションをWebLogic Serverドメイン、パーティションcoke、パーティションpepsiにデプロイします。
          edit()
          startEdit()
          deploy(appName='helloTenant',target='admin,path='${path-to-the-ear-file}/helloTenant.ear')
          deploy(appName='helloTenant-coke',partition='coke',resourceGroup='coke-rg1',path='${path-to-the-ear-file}/helloTenant.ear')
          deploy(appName='helloTenant-pepsi',partition='pepsi',resourceGroup='pepsi-rg1',path='${path-to-the-ear-file}/helloTenant.ear')
          save()
          activate()

          2.6 Domain config file sample

          すべての手順が完了したら、$DOMAIN_HOME/config/config.xml(ドメイン構成ファイル)にはドメインやパーティションに必要なすべての情報が含まれています。以下はconfig.xmlのパーティションcokeに関連するスニペットの例です。
          <server>
            <name>admin</name>
            <listen-address>localhost</listen-address>
          </server>
          <configuration-version>12.2.1.0.0</configuration-version>
          <app-deployment>
            <name>helloTenant</name>
            <target>admin</target>
            <module-type>ear</module-type>
            <source-path>${path-to-the-ear-file}/helloTenant.ear</source-path>
            <security-dd-model>DDOnly</security-dd-model>
            <staging-mode xsi:nil="true"></staging-mode>
             <plan-staging-mode xsi:nil="true"></plan-staging-mode>
            <cache-in-app-directory>false</cache-in-app-directory>
          </app-deployment>
          <virtual-target>
            <name>coke-vt</name>
            <target>admin</target>
            <host-name>localhost</host-name>
            <uri-prefix>/coke</uri-prefix>
            <web-server>
              <web-server-log>
                <number-of-files-limited>false</number-of-files-limited>
              </web-server-log>
            </web-server>
          </virtual-target>
          <admin-server-name>admin</admin-server-name>
          <partition>
            <name>coke</name>
            <resource-group>
              <name>coke-rg1</name>
              <app-deployment>
                <name>helloTenant-coke</name>
                <module-type>ear</module-type>
                <source-path>${path-to-the-ear-file}/helloTenant.ear</source-path>
                <security-dd-model>DDOnly</security-dd-model>
                <staging-mode xsi:nil="true"></staging-mode>
                <plan-staging-mode xsi:nil="true"></plan-staging-mode>
                <cache-in-app-directory>false</cache-in-app-directory>
              </app-deployment>
              <target>coke-vt</target>
              <use-default-target>false</use-default-target>
            </resource-group>
            <default-target>coke-vt</default-target>
            <available-target>coke-vt</available-target>
            <realm>coke_realm</realm>
            <partition-id>2d044835-3ca9-4928-915f-6bd1d158f490</partition-id>
            <primary-identity-domain>cokeIDD</primary-identity-domain>
          </partition>
          パーティションpepsiの場合、パーティションpepsiに対応する<virtual-target>要素と<partition>要素がconfig.xmlに追加されています。

          これで、2個のパーティションを持つドメインを作成し、リクエストを受け付ける準備ができました。ユーザーはこのドメインにデプロイしたアプリケーションにアクセスすることができます。WebLogic Server 12.2.1 Multitenancy環境のMBeanServersに登録されたアプリケーションMBeanにアクセスする方法については、以下のエントリをご覧ください。
          Application MBeans Visibility in Oracle WebLogic Server 12.2.1
          https://blogs.oracle.com/WebLogicServer/entry/application_mbeans_visibility_in_oracle

          3. Debug Flags

          ドメイン作成時にエラーが発生した場合、以下のデバッグフラグを使って、エラーの切り分けが可能です。
          • セキュリティレルムの設定に関連するエラーの場合、以下のデバッグフラグを使ってWebLogic Serverを再起動します。
            -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugSecurity=true -Dweblogic.debug.DebugSecurityRealm=true
          • ドメインでのBean構成エラーに関連するエラーの場合、以下のデバッグフラグを使ってWebLogic Serverを再起動します。
            -Dweblogic.debug.DebugJMXCore=true -Dweblogic.debug.DebugJMXDomain=true
          • 編集セッションの問題に関連するエラーの場合、以下のデバッグフラグを使ってWebLogic Serverを再起動します。
            -Dweblogic.debug.DebugConfigurationEdit=true -Dweblogic.debug.DebugDeploymentService=true -Dweblogic.debug.DebugDeploymentServiceInternal=true -Dweblogic.debug.DebugDeploymentServiceTransportHttp=true

          4. Conclusion

          Oracle WebLogic Server 12.2.1のドメインにはパーティションを含めることができます。パーティションを持つドメインを作成するには、通常のWebLogicドメインを作成する手順に加え、さらに追加の手順が必要です。このエントリではWLSTを使ったドメイン作成方法をご紹介しました。パーティション付きのドメイン作成は、Fusion Middleware Controlを使って作成することも可能です。パーティション付きのドメイン作成方法は、Referencesセクションに列挙したドキュメントやエントリをご確認ください。

          5. References

          Oracle® Fusion Middleware Installing and Configuring Oracle WebLogic Server and Coherence 12c (12.2.1)
          Creating and Configuring the WebLogic Domain
          http://docs.oracle.com/middleware/1221/core/WLSIG/GUID-4AECC00D-782D-4E77-85DF-F74DD61391B4.htm#WLSIG283
          Domain Partitions for Multi-tenancy in WebLogic Server 12.2.1
          https://blogs.oracle.com/WebLogicServer/entry/domain_partitions_for_multi_tenancy
          http://orablogs-jp.blogspot.jp/2015/11/domain-partitions-for-multi-tenancy-in.html
          Using Fusion Middleware Control to Manage WebLogic Server
          http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/manage_wls_fmc/obe.html
          Oracle® Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure 12c (12.2.1)
          Creating Database Schemas
          https://docs.oracle.com/middleware/1221/core/INFIN/GUID-CA80A6E9-8903-4E19-81D7-A3647A11D0A6.htm#INFIN356
          Oracle® Fusion Middleware Oracle WebLogic Scripting Tool 12c Release 1 (12.1.1)
          Creating WebLogic Domains Using WLST Offline
          http://docs.oracle.com/cd/E24329_01/web.1211/e24491/domains.htm#WLSTG156
          Oracle® Fusion Middleware Domain Template Reference 12c (12.2.1)
          Oracle Restricted JRF Template
          https://docs.oracle.com/middleware/1221/wls/WLDTR/fmw_templates.htm#WLDTR524
          Oracle® Fusion Middleware Administering Security for Oracle WebLogic Server 12.2.1 12c (12.2.1)
          Configuring Security for a WebLogic Domain
          http://docs.oracle.com/middleware/1221/wls/SECMG/conf-security-for-domain.htm#SECMG777
          Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server 12c (12.2.1)
          Understanding WebLogic Server Deployment
          https://docs.oracle.com/middleware/1221/wls/DEPGD/understanding.htm#DEPGD114
          WebLogic Server Debug Flags
          http://weblogic-wonders.com/weblogic/2010/11/18/weblogic-server-debug-flags/

          [Java, FMW, WLS] JMX Authorization policies

          $
          0
          0
          原文はこちら。
          https://blogs.oracle.com/WebLogicServer/entry/jmx_authorization

          WebLogic Server 12.2.1でパーティションの概念が導入されたことで、MBeanのWebLogicユーザーへの認可方法に影響があります。これは、MBeanのスコープを以下のいずれかに設定できるからです。
          • ドメイン
          • パーティション
          パーティションはWebLogicドメインのスライスであり、パーティション内でユーザーを定義することができます。あるパーティションのユーザーは別のパーティションのユーザーとは別のものであり、ドメインのユーザーとも別のものです。歴史的に、パーティションの概念がなかったときは、WebLogicドメインのユーザーは4個のロールをとることができます。すなわち、以下の4個のロールです。
          1. Administrator
          2. Deployer
          3. Monitor
          4. Operator
          MBeanを認可できるか否かの基本的なルールを以下にまとめることができます。
          1. 任意のユーザーは暗号化されたMBean以外の任意のMBeanの読み取りが可能
          2. Administratorロールを持つユーザーは任意のMBeanの書き込み、実行が可能
          3. MBeanに指定ロールのみを許可するアノテーションが付いている限り、他のロール(Deployer、Monitor、Operator)を持つユーザーはMBeanにアクセス可能
          @roleAllowed Deployer
          Public class MyMBean {
          ...
          }
          上記のケースの場合、Deployerロールを持つユーザーはこのMBeanへの書き込み、実行が可能ですが、Monitorロールを持つユーザーは当該MBeanに対し書き込み、実行はできません。

          12.2.1では、Multitenancyが導入され、認可ルールが大きく変わりました。MBeanをドメインスコープ、パーティションスコープのいずれかに配置することができるようになっています。このスコープは"owned by(所有される)"と呼ばれることがあります。例えば、12.2.1ではDomainMBeanはMBeanがMBeanツリーのドメインレベルにあるため、ドメインが所有しています。WebLogic ServerのMBeansをツリー状の構造で表現してみると以下のような感じになります。

          上図は、WebLogic ServerのMBeanをパーティションスコープもしくはドメインスコープに設定する方法を表現しています。 パーティションをWebLogicドメイン中に作成した場合、当該パーティションを表す、PartitionMBeanと命名した構成MBeanを作成します。上図をよく見ると、PartitionMBeanがパーティションスコープではなく、ドメインスコープに配置されていることがわかります。PartitionMBeanの下の任意のMBeanはパーティションスコープです。

          それゆえ、パーティションユーザーがMBeanがMBeanツリーのどこにあるか次第でMBeanにアクセスできるかどうかが決まります。MBeanツリーのMBeanの場所によって、当該MBeanがパーティションスコープなのか、ドメインスコープなのかが定まります。ドメインユーザーはパーティションスコープのMBeanへの書き込み、実行が可能ですが、パーティションユーザーは、明示的にアノテーションが付加されていない限り、MBeanへの書き込み、実行はできません。

          12.2.1では、@ownerという新たなアノテーションを導入しました。これは場所に基づいたMBeanの所有権の動作を明示的に指定された所有権にオーバーライドします。@ownerには以下の3個の値を設定できます。
          • Domain
            • @owner Domain アノテーションを付加すると、MBeanツリーでの場所にかかわらず、ドメインが所有するMBeanとしてオーバーライドされます。
          • Partition
            • @owner Partition アノテーションを付加すると、MBeanツリーでの場所にかかわらず、パーティションが所有するMBeanとしてオーバーライドされます。
          • Context
            • @owner Context アノテーションを付加すると、MBeanにアクセスしようとしているユーザーのログインコンテキストに基づいて、MBeanの所有権を変更します。
              • ユーザーがドメインコンテキストからMBeanへアクセスしようとしている場合、MBeanは@owner Domainとして振る舞います。
              • ユーザーがパーティションコンテキストからMBeanへアクセスしようとしている場合、MBeanは@owner Partitionとして振る舞います。
          MBeanにドメインユーザーもパーティションユーザーもアクセスする必要がある場合、@owner Context は特に有用です。MBeanはドメインとパーティションの間で共有されているMBeanのように振る舞います。MBeanツリーでドメインスコープのMBeanに@owner Contextを付加した場合、特定パーティションユーザーではなく、全パーティションのユーザーがMBeanに対して書き込みや実行をすることができます。特定パーティションのユーザーだけを選択してドメインスコープのMBeanにアクセスさせる方法はありません。

          MBeanのきめ細かい管理のために、MBeanの各属性、各オペレーションに対し @owner を付加することができます。MBeanインターフェースに @owner を付けると、当該MBeanのすべての属性やオペレーションに @owner を付加したように振る舞います。

          Example usage

          以下のようにMBeanへアノテーションを付加することで、Deployerロールを持つドメインユーザーやパーティションユーザーはDomainRuntimeMBeanのオペレーションや属性にアクセスすることができます。
          /**
          * @roleAllowed Deployer
          * @owner Context
          */

          public interface DomainRuntimeMBean

          Authorization’s relation to visibility of an MBean

          12.2.1では、Muititenancyの導入に伴い、どのMBeanをユーザーが見ることができるか、という点で変更があります。すべてのMBeanがユーザーに見えるわけではありません。MBeanがエンドユーザーに見える場合は、認可ルールが適用されています。WebLogic Server 12.2.1でのVisibilityルールの詳細については、以下のエントリをご覧ください。
          Application MBeans Visibility in Oracle WebLogic Server 12.2.1
          https://blogs.oracle.com/WebLogicServer/entry/application_mbeans_visibility_in_oracle

          Default Security Policies in 12.2.1

          • Administratorロールを持つドメインユーザーは、ドメインおよびパーティション全体のすべてのMBeanに対するフルアクセス権があります。
          • MBean属性のGetterとlookupXXXオペレーションは、ドメインやパーティションの任意のユーザーに対して認可されます。このときアノテーションは不要です。
          • ドメインスコープのMBeanの属性のSetter、オペレーションにパーティションユーザーがアクセスする必要がある場合、@owner Contextをアノテーションで付加する必要があります。
          • MBeanを所有するパーティションの場合、当該パーティションのユーザーがアクセス可能にできるようにするために @owner アノテーションを付ける必要はありません。
          • 別のロール(Deployer、Monitor、Operator)を持っているドメインユーザーがドメインスコープのMBeanにアクセスする必要がある場合、 @roleAllowed アノテーションが付加されていなければなりません。Domain Administratorとは異なり、これらのユーザーはパーティションスコープのMBeanではなく、ドメインスコープのMBeanへのみアクセスできます。
          • Administratorロールを有するパーティションのユーザーは、当該パーティションの任意のMBeanにアクセスすることができますが、別のパーティションのMBeanにはアクセスできません。これはVisibilityルールによって保護されています。
          • Application MBeans Visibility in Oracle WebLogic Server 12.2.1 https://blogs.oracle.com/WebLogicServer/entry/application_mbeans_visibility_in_oracle
          • パーティションユーザーはドメインユーザーと同様のロール(Administrator、Deployer、Monitor、Operator)を持つことができます。
          • 別のロール(Deployer、Monitor、Operator)を持っているパーティションのユーザーがパーティションスコープのMBeanにアクセス(書き込み、実行)する必要がある場合、MBeanに @roleAllowed のアノテーションを付加する必要があります。

          Summary of Authorization rules for users in Weblogic 12.2.1

          Table 1: WLS MBeans without any @roleAllowed annotation 
          Table 2: WLS MBeans with @roleAllowed annotation. This annotation can appear on MBean Interface, Attribute or Operation
          • Domain MBean: ドメインスコープにあるMBeanで、@owner Domain もしくは、 @owner Contextでアノテーションされている。サブジェクトはドメインContextにある。
          • Partition MBean: パーティションスコープにあるMBeanで、@owner Partition もしくは、 @owner Contextでアノテーションされている。MBeanにアクセスすると、サブジェクトはPartitionコンテキストにある。
          Table 3: Previlege of Different Domain Roles
          Table 4: Privilege of Different Partition Roles

          [WLS, Java, FMW] Application MBeans Visibility in Oracle WebLogic Server 12.2.1

          $
          0
          0
          原文はこちら。
          https://blogs.oracle.com/WebLogicServer/entry/application_mbeans_visibility_in_oracle

          Oracle WebLogic Server (WLS) 12.2.1では、 Multi-Tenancy (WLS MT)と呼ばれる機能をサポートしています。WLS MTではパーティション、パーティション管理者、パーティションリソースというコンセプトが導入されました。ドメイン中のリソース、例えばMBeanにアクセスする際にパーティション分離を強制します。WLS管理者はドメインやパーティションのMBeanを見ることができますが、パーティション管理者だけでなく他のパーティションロールは自身のパーティションにあるMBeanしか見ることはできません。

          このエントリでは、アプリケーションMBeanの可視性サポートを説明して、WLS MT 12.2.1のパーティション分離を紹介します。この説明には以下の内容をふくみます
          • WLS MTでのアプリケーションMBeanの可視性に関する概要
          • どのMBeanがWLS MBeanServerに登録され、どのMBeanがWLS管理者もしくはパーティション管理者から見えるのかを説明するシンプルなユーザーケース
          • 詳細情報の参考記事へのリンク
          このエントリで取り上げるユースケースは以下のエントリで作成したドメインを基にしています。
          Create WebLogic Server Domain with Partitions using WLST in 12.2.1
          https://blogs.oracle.com/WebLogicServer/entry/create_weblogic_server_domain_with
          http://orablogs-jp.blogspot.jp/2015/11/create-weblogic-server-domain-with.html 
          このエントリでは、以下の内容を説明しています。
          • ドメイントポロジの概要紹介
          • ドメインやパーティションへのアプリケーションデプロイ方法の説明
          • JMXクライアントからグローバル/ドメインURLやパーティション固有のURLで、アプリケーションMBeanにアクセスする方法の説明
          • デバッグ、ロギングの有効化方法の説明

          1. Overview

          アプリケーションをパーティション毎にWebLogic Serverにデプロイできるので、アプリケーションを複数のパーティションに対して複数配置します。WebLogic Serverには以下のMBeanServerがあります。
          • Domain Runtime MBeanServer
          • Runtime MBeanServer
          各MBeanServerをすべてのパーティション用に使うことができます。WebLogic Serverはアプリケーションが各MBeanServerに登録したMBeanが各パーティションで一意であることを保証する必要があります。

          WLS MTでのアプリケーションMBeanの可視性をいくつかのパートで説明します。
          • Partition Isolation
          • Application MBeans Registration
          • Query Application MBeans
          • Access Application MBeans

          1.1 Partition Isolation

          WLS管理者はパーティションMBeanを見ることができますが、パーティション管理者はドメインや他のパーティションのMBeanを見ることはできません。

          1.2 Application MBeans Registration

          アプリケーションをパーティションにデプロイする間にアプリケーションMBeanを登録します。WebLogic ServerはアプリケーションMBeanをWLS MBeanServerに登録する際に、パーティション固有のキー(例:Partition=<パーティション名>)をMBean Object Namesに追加します。こうして、増加したアプリケーションから登録された場合に、MBeanオブジェクト名が一意になることを保証します。

          右図では、ドメインやパーティションのWLS MBeanServerに登録した際にアプリケーションMBean Object Nameが異なるさまを示しています。


          右図ではWebLogicドメインとアプリケーションがあることを示しています。

          WebLogicドメインは2個のパーティション(cokeとpepsi)で構成されています。

          アプリケーションデプロイ中にアプリケーションがMBeanを登録します(例:testDomain:type=testType)。

          アプリケーションをWebLogicドメイン、cokeパーティション、pepsiパーティションにデプロイします。WLS MBeanServerインスタンスはドメイン、cokeパーティション、pepsiパーティションが共有しています。
          3回のアプリケーションデプロイメントの結果、3個のアプリケーションMBeanが同じMBeanServerに登録されています。
          • ドメイン所属のMBean:          testDomain:type=testType
          • cokeパーティション所属のMBean: testDomain:Partition=cokePartition,type=testType
          • pepsiパーティション所属のMBean: testDomain:Partition=pepsiPartition,type=testType
          パーティションに属するMBeanには、ObjectNameのPartitionキープロパティが含まれています。

          1.3 Query Application MBeans

          WebLogic WLSTやJConsoleといったJMXクライアントでグローバル/ドメインURLやパーティション固有のURLに接続し、WebLogic MBeanServerに対しクエリを実行すると、異なるクエリ結果が返ってきます。
          • グローバル/ドメインURLに接続する場合、パーティション所属のアプリケーションMBeanは接続したJMXクライアントから見える。
          • パーティション固有のURLに接続する場合、WebLogic Serverがクエリ結果にフィルタを掛け、パーティション所属のアプリケーションMBeanのみ返す。ドメインや他パーティション所属のMBeanは見えない。

          1.4 Access Application MBeans

          WebLogic WLSTやJConsoleといったJMXクライアントがパーティション固有のURLに接続し、 getAttribute(<MBean ObjectName>, <attributeName>)のようなJMXの操作を実行すると、実のところ異なるMBeanに対してJMX操作を実行します。
          • グローバル/ドメインURLに接続する場合、ドメイン所属のMBean(MBean ObjectNameでPartitionキープロパティのないMBean)のgetAttribute()を呼び出す
          • パーティション固有のURLに接続する場合、パーティション所属のMBean(MBean ObjectNameでPartitionキープロパティがあるMBean)のgetAttribute()を呼び出す

          2. Use case

          それでは、MBeanの可視性がWebLogic Server 12.2.1のMultitenancyでパーティション分離をサポートするためにどのように作用するのか説明します。

          2.1 Domain with Partitions

          以下のエントリで、2個のパーティション(cokeとpepsi)を持つドメインを作成しています。
          Create WebLogic Server Domain with Partitions using WLST in 12.2.1
          https://blogs.oracle.com/WebLogicServer/entry/create_weblogic_server_domain_with
          http://orablogs-jp.blogspot.jp/2015/11/create-weblogic-server-domain-with.html 
          このドメインを再度このエントリのユースケースのために利用します。以下はドメイントポロジのサマリです。
          • ドメインは1個の管理サーバ(admin)、cokeとpepsiというパーティションで構成されている。
          • cokeパーティションには1個のリソースグループ (coke-rg1) を含み、仮想ターゲット(coke-vt)に向けられている
          • pepsiパーティションには1個のリソースグループ (pepsi-rg1) を含み、仮想ターゲット(pepsi-vt)に向けられている
          より具体的に、各ドメイン/パーティションには以下の値で構成されています。
          Domain NameUser NamePassword
          Domainbase_domainweblogicwelcome1
          Coke Partitioncokemtadmin1welcome1
          Pepsi Partitionpepsimtadmin2welcome2
          このドメイン作成方法の詳細は上記リンクをご覧ください。

          2.2 Application deployment

          ドメインをセットアップして開始し、アプリケーション"helloTenant.ear"をドメインにデプロイします。パーティションcokeのリソースグループcoke-rg1とパーティションpepsiのリソースグループpepsi-rg1にもデプロイします。デプロイはWLST、Fusion Middleware ControlといったWebLogic Serverのツールで可能です。以下はドメインとパーティションにアプリケーションをデプロイするためのWLSTコマンドの例です。
          startEdit()
          deploy(appName='helloTenant',target='admin,path='${path-to-the-ear-file}/helloTenant.ear')
          deploy(appName='helloTenant-coke',partition='coke',resourceGroup='coke-rg1',path='${path-to-the-ear-file}/helloTenant.ear')
          deploy(appName='helloTenant-pepsi',partition='pepsi',resourceGroup='pepsi-rg1',path='${path-to-the-ear-file}/helloTenant.ear')
          save()
          activate()
          別のWLSデプロイメントツールについては、Referenceセクションをご覧ください。

          2.3 Access Application MBeans

          アプリケーションデプロイメントの間に、アプリケーションMBeanがWebLogic Server MBeanServerに登録されます。[1.2 Application MBean Registration]でお伝えした通り、1個のアプリケーションしかないにもかかわらず、複数のMBeanが登録されています。

          アプリケーションMBeansにアクセスするには複数の方法があります。
          • WLST
          • JConsole
          • JSR 160 apis

          2.3.1 WLST

          WebLogic Scripting Tool (WLST) はコマンドラインスクリプティングインターフェースで、システム管理者やオペレータがWebLogic Serverインスタンスやドメインを監視・管理するために使います。WLSTを開始するには以下のコマンドを実行します。
          $MW_HOME/oracle_common/common/bin/wlst.sh
          WLSTが起動すると、ユーザーは接続URLを指定してサーバに接続することができます。以下は異なるアプリケーションMBean属性の値を示しています。WebLogic Server管理者やパーティション管理者が異なる接続URLを使った際には異なるアプリケーションMBean属性値が表示されます。

          2.3.1.1 WLS administrator

          WebLogic Server管理者 'weblogic'は以下の接続コマンドを使ってドメインに接続します。
          connect("weblogic", "welcome1", "t3://localhost:7001")
          下図はWebLogic Server MBeanServerに登録された3個のMBeanを示しています。なお、ドメイン名はtest.domain、各MBeanのPartitionName属性値は以下の通りです。
          • test.domain:Partition=coke,type=testType,name=testName
            • パーティションcokeに属している。PartitionName属性値はcoke
          • test.domain:Partition=pepsi,type=testType,name=testName
            • パーティションpepsiに属している。PartitionName属性値はpepsi
          • test.domain:type=testType,name=testName
            • ドメインに属している。ObjectNameのPartitionキープロパティはない。PartitionName属性はDOMAIN
          パーティション所属のMBeanにはObjectName中にPartitionキープロパティがあります。パーティションコンテキストに登録する際にWebLogic Serverが内部でPartitionキープロパティを追加します。


          2.3.1.2 Partition administrator for coke

          同様に、パーティションcokeの管理者mtadmin1はパーティションcokeに接続できます。接続URLは仮想ターゲットcoke-vt(<Domain_Home>/config/config.xmlをチェックしてください)で定義されたURI接頭辞である/cokeを使います。
          connect("mtadmin1", "welcome1", "t3://localhost:7001/coke")
          下図のように、パーティションcokeに接続すると、1個だけMBeanが表示されます。
          test.domain:type=testType,name=testName
          PartitionキープロパティがObjectNameにありませんが、このMBeanはパーティションcokeに属しています。PartitionName属性値はcokeです。

          2.3.1.3 Partition administrator for pepsi

          同様に、パーティションpepsiの管理者mtadmin2はパーティションpepsiに接続できます。接続URLは仮想ターゲットpepsi-vt(<Domain_Home>/config/config.xmlをチェックしてください)で定義されたURI接頭辞である/pepsi を使います。
          connect("mtadmin2", "welcome2", "t3://localhost:7001/pepsi")
          下図のように、パーティションpepsiに接続すると、1個だけMBeanが表示されます。
          test.domain:type=testType,name=testName
          PartitionキープロパティがObjectNameにありませんが、パーティションcokeの管理者の場合と同様、このMBeanはパーティションpepsiに属しています。PartitionName属性値はpepsiです。

          2.3.2 JConsole

          JConsoleはJDKに組み込まれたGUIのツールで、Java Management Extensions (JMX)仕様に準拠した監視ツールです。JConsoleを使うと、MBeanServerに登録されたMBeanの概要をつかむことができます。

          JConsoleを起動するには以下のコマンドを実行します。
          $JAVA_HOME/bin/jconsole
          -J-Djava.class.path=$JAVA_HOME/lib/jconsole.jar:
          $JAVA_HOME/lib/tools.jar:$MW_HOME/wlserver/server/lib/wljmxclient.jar
           -J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote
          ここで<MW_HOME>はWebLogic Serverをインストールした場所です。

          JConsoleが起動したら、WebLogic Server管理者やパーティション管理者は資格証明とJMXサービスURLを指定した後に、MBeanを確認することができます。

          2.3.2.1 WLS administrator

          WebLogic Server管理者weblogicはJMXサービスURLを指定して、WebLogic Server Runtime MBeamServerに以下のように接続します。
          service:jmx:t3://localhost:7001/jndi/weblogic.management.mbeanservers.runtime
          WebLogic Server管理者が接続すると、JConsoleのMBeanツリーにはObjectNameにtest.domainを持つ3個のMBeanが表示されています。

          下図の右ペインで示したObjectNameはパーティションcokeに属しており、Partitionキープロパティを有しています(Partition=coke)。


          下図の場合パーティションpepsiに属するMBeanなので、Partitionキープロパティを有しています(Partition=pepsi)。



          下図の場合、ドメインに属するMBeanなので、Partitionキープロパティはありません。



          WebLogic Server管理者がWLSTで見たものとここで表示した結果は同じですね。

          2.3.2.2 Partition administrator for coke

          パーティション管理者mtadmin1は異なるJMXサービスURLをJConsoleに指定します。
          service:jmx:t3://localhost:7001/coke/jndi/weblogic.management.mbeanservers.runtime
          パーティション固有のJMXサービスURLを使って接続すると、パーティション管理者には1個のMBeanしか見えません。
          test.domain:type=testType,name=testName
          このMBeanはパーティションcokeに属しており、下図の通り、PartitionName属性値はcokeです。しかし、ObjectNameにPartitionキープロパティはありません。




          2.3.2.3 Partition administrator for pepsi

          パーティション管理者mtadmin2は異なるJMXサービスURLをJConsoleに指定します。
          service:jmx:t3://localhost:7001/pepsi/pepsi/weblogic.management.mbeanservers.runtime
          パーティション固有のJMXサービスURLを使って接続すると、パーティション管理者mtadmin2には1個のMBeanしか見えません。
          test.domain:type=testType,name=testName
          このMBeanはパーティションpepsiに属しており、下図の通り、PartitionName属性値はpepsiです。




          2.3.3 JSR 160 APIs

          JMXクライアントはJSR 160 APIを使ってMBeanServerに登録されたMBeanにアクセスすることができます。例えば以下のコードでは、サービスURLと環境をMBean属性に指定してJMXConnetorを取得しています。
          import javax.management.*;
          import javax.management.remote.JMXConnector;
          import javax.management.remote.JMXServiceURL;
          import javax.management.remote.JMXConnectorFactory;
          import java.util.*

          public class TestJMXConnection {
          public static void main(String[] args) throws Exception {
          JMXConnector jmxCon = null;
          try {
          // Connect to JMXConnector
          JMXServiceURL serviceUrl = new JMXServiceURL(
          "service:jmx:t3://localhost:7001/jndi/weblogic.management.mbeanservers.runtime");
          Hashtable env = new Hashtable();
          env.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, "weblogic.management.remote");
          env.put(javax.naming.Context.SECURITY_PRINCIPAL, "weblogic");
          env.put(javax.naming.Context.SECURITY_CREDENTIALS, "welcome1");
          jmxCon = JMXConnectorFactory.newJMXConnector(serviceUrl, env);
          jmxCon.connect();

          // Access the MBean
          MBeanServerConnection con = jmxCon.getMBeanServerConnection();
          ObjectName oname = new ObjectName("test.domain:type=testType,name=testName,*");
          Set<objectname> queryResults = (Set<objectname>)con.queryNames(oname, null);
          for (ObjectName theName : queryResults) {
          System.out.print("queryNames(): " + theName);
          String partitionName = (String)con.getAttribute(theName, "PartitionName");
          System.out.println(", Attribute PartitionName: " + partitionName);
          }
          } finally {
          if (jmxCon != null)
          jmxCon.close();
          このコードをコンパイルして実行するためには、wljmxclient.jarをクラスパスに指定する必要があります。
          $JAVA_HOME/bin/java -classpath $MW_HOME/wlserver/server/lib/wljmxclient.jar:. TestJMXConnection
          以下のような結果が出力されるはずです。
          Connecting to: service:jmx:t3://localhost:7001/jndi/weblogic.management.mbeanservers.runtime
          queryNames(): test.domain:Partition=pepsi,type=testType,name=testName, Attribute PartitionName: pepsi
          queryNames(): test.domain:Partition=coke,type=testType,name=testName,  Attribute PartitionName: coke
          queryNames(): test.domain:type=testType,name=testName, Attribute PartitionName: DOMAIN
          パーティション管理者mtadmin1を使うようにコードを変更すると、以下のようになります。
          JMXServiceURL serviceUrl = new JMXServiceURL(
          "service:jmx:t3://localhost:7001/coke/jndi/weblogic.management.mbeanservers.runtime");
          env.put(javax.naming.Context.SECURITY_PRINCIPAL, "mtadmin1");
          env.put(javax.naming.Context.SECURITY_CREDENTIALS, "welcome1");
          コードを実行すると、1個のMBeanしか返ってこないことがわかります。
          Connecting to: service:jmx:t3://localhost:7001/coke/jndi/weblogic.management.mbeanservers.runtime
          queryNames(): test.domain:type=testType,name=testName,  Attribute PartitionName: coke
          同様の結果がパーティション管理者pepsiを使った場合に確認できるでしょう。パーティションpepsi固有のJMXサービスURLを指定すると、パーティションpepsiに属するMBean1個のみが返ってきます。

          2.4 Enable logging/debugging flags

          WebLogic Server 12.2.1でMBeanが正しい挙動を示さないことがあります。例えば、
          • MBeanのクエリを発行した際に、パーティション管理者がグローバルドメインや別のパーティションのMBeanを見ることができる。
          • JMX例外が発生する。例えば、MBeanにアクセスする際に、javax.management.InstanceNotFoundExceptionが発生する。
          エラーの切り分けのために以下のことを試行してください。
          • JConsoleの接続問題の場合、JConsole起動時にコマンドラインに -debug を追加する
          • MBeanのクエリを発行すると、パーティション管理者がグローバルドメインや別パーティションのMBeanを見ることができる場合、
            • WLSTやJConsole、JSR 160 APIといったJMXクライアントから接続している場合、サービスのホスト名が<Domain_Home>/config/config.xmlの仮想ターゲットで定義したホスト名に一致することを確認する。
            • サービスURLのURI接頭辞が<Domain_Home>/config/config.xmlの仮想ターゲットで定義したURI接頭辞と一致することを確認する。
          • JMX例外が発生した場合、例えば、MBeanにアクセスする際に、javax.management.InstanceNotFoundExceptionが発生した場合
            • MBeanがパーティションに属する場合、パーティションを開始します。アプリケーションデプロイメントはパーティションが開始しないと実行されません。
            • 以下のオプションを追加して、サーバー始動時にデバッグフラグを有効にします。
              -Dweblogic.StdoutDebugEnabled=true -Dweblogic.log.LogSeverity=Debug -Dweblogic.log.LoggerSeverity=Debug -Dweblogic.debug.DebugPartitionJMX=true -Dweblogic.debug.DebugCIC=false 
            • 対象としている特定のMBean ObjectNameをサーバーログで探します。デバッグしているMBeanが正しくパーティション・コンテキストに登録されていることを確認します。MBeanオペレーションが正しくパーティションコンテキストで呼ばれていることを確認します。
            以下はMBean"test.domain:type=testType,name=testName"のMBean登録、queryNames()、getAttribute()の呼び出しに関連するデバッグメッセージの例です。
            <Oct 21, 2015 11:36:43 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <Calling register MBean test.domain:type=testType,name=testName in partition DOMAIN>
            <Oct 21, 2015 11:36:44 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <Calling register MBean test.domain:Partition=coke,type=testType,name=testName in partition coke>
            <Oct 21, 2015 11:36:45 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <Calling register MBean test.domain:Partition=pepsi,type=testType,name=testName in partition pepsi>
            <Oct 21, 2015 11:36:56 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <queryNames on MBean test.domain:Partition=coke,type=testType,name=testName,* in partition coke>
            <Oct 21, 2015 11:36:56 PM PDT> <Debug> <MBeanCIC> <BEA-000000> <getAttribute: MBean: test.domain:Partition=coke,type=testType,name=testName, CIC: (pId = 2d044835-3ca9-4928-915f-6bd1d158f490, pName = coke, appId = helloTenant$coke, appName = helloTenant, appVersion = null, mId = null, compName = null)>
            • パーティションコンテキストが正しくない理由を確認するため、上記のデバッグフラグに加え、以下のデバッグフラグを追加して、WebLogic Serverを始動してください。
              -Dweblogic.debug.DebugCIC=true. Once this flag is used, there are a lot of messages logged into the server log. Search for the messages logged by DebugCIC logger, like  ExecuteThread: '<thread id #>' for queue: 'weblogic.kernel.Default (self-tuning)'): Pushed 
              以下はDebugPartitionJMX ロガーがログ出力したメッセージの例です。
            <Oct 21, 2015, 23:59:34 PDT> INVCTXT (24-[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'): Pushed [(pId = 0, pName = DOMAIN, appId = null, appName = null, appVersion = null, mId = null, compName = null)] on top of [(pId = 0, pName = DOMAIN, appId = null, appName = null, appVersion = null, mId = null, compName = null)]. New size is [2]. Pushed by [weblogic.application.ComponentInvocationContextManagerImpl.pushComponentInvocationContext(ComponentInvocationContextManagerImpl.java:173)
            ...
            <Oct 21, 2015 11:59:34 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <Calling register MBean test.domain:type=testType,name=testName in partition DOMAIN>
            ...
            <Oct 21, 2015, 23:59:37 PDT> INVCTXT (29-[STANDBY] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'): Pushed [(pId = 2d044835-3ca9-4928-915f-6bd1d158f490, pName = coke, appId = helloTenant$coke, appName = helloTenant, appVersion = null, mId = null, compName = null)] on top of [(pId = 2d044835-3ca9-4928-915f-6bd1d158f490, pName = coke, appId = null, appName = null, appVersion = null, mId = null, compName = null)]. New size is [3]. Pushed by
            [weblogic.application.ComponentInvocationContextManagerImpl.pushComponentInvocationContext(ComponentInvocationContextManagerImpl.java:173)
            ...
            <Oct 21, 2015 11:59:37 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <Calling register MBean test.domain:Partition=coke,type=testType,name=testName in partition coke>

          3. Conclusion

          WebLogic Server 12.2.1はMulti-Tenancy (MT)という新機能を提供しています。この機能を使って、パーティション分離が強制されています。アプリケーションをドメインやパーティションにデプロイできます。パーティションのユーザーは別のパーティションに所属するリソース(アプリケーションが登録したMBeanを含む)を見ることができません。このエントリでは、あるユースケースを使い、アプリケーションMBeanがパーティション分離が、MBeanの可視性でどのように影響するのかを御所階しました。詳細情報は、Referencesセクションをご覧ください。

          4. References

          Oracle® Fusion Middleware Installing and Configuring Oracle WebLogic Server and Coherence 12c (12.2.1) 
          Creating and Configuring the WebLogic Domain
          https://docs.oracle.com/middleware/1221/core/WLSIG/GUID-4AECC00D-782D-4E77-85DF-F74DD61391B4.htm#WLSIG281
          Oracle® Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure 12c (12.2.1) 
          Configuring the Oracle Fusion Middleware Infrastructure Domain
          https://docs.oracle.com/middleware/1221/core/INFIN/GUID-CA80A6E9-8903-4E19-81D7-A3647A11D0A6.htm#INFIN280
          Oracle® Fusion Middleware WLST Command Reference for WebLogic Server 12c (12.2.1)
          https://docs.oracle.com/middleware/1221/wls/WLSTC/toc.htm
          Java SE Monitoring and Management Guide
          Using JConsole
          http://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html
          Managing WebLogic Server with JConsole
          https://blogs.oracle.com/WebLogicServer/entry/managing_weblogic_servers_with
          JSR 160: Java Management Extensions Remote JMX api
          https://jcp.org/en/jsr/detail?id=160
          Oracle® Fusion Middleware Administering Security for Oracle WebLogic Server 12.2.1 12c (12.2.1)
          Configuring Security for a WebLogic Domain
          http://docs.oracle.com/middleware/1221/wls/SECMG/conf-security-for-domain.htm#SECMG777
          Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server 12c (12.2.1)
          Understanding WebLogic Server Deployment
          https://docs.oracle.com/middleware/1221/wls/DEPGD/understanding.htm#DEPGD114

          [WLS, Java, FMW] Weblogic Server 12.2.1 Multi-Tenancy Diagnostics Overview

          $
          0
          0
          原文はこちら。
          https://blogs.oracle.com/WebLogicServer/entry/wls_mt_diagnostics_overview

          Introduction

          WebLogic Server 12.2.1ではMultitenancyをサポートしており、これにより複数のテナントが一つのWebLogicドメインを共有することができます。
          Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
          About WebLogic Server MT
          http://docs.oracle.com/middleware/1221/wls/WLSMT/concepts.htm#WLSMT718
          テナントは、別々のWebLogicドメインの設定やランタイムインフラストラクチャのスライスを提供するドメインパーティションにアクセスします。
          このエントリでは、各パーティションにデプロイされたアプリケーションやリソースに対しテナントが利用可能な診断・監視機能の概要を紹介します。

          これらの機能はWebLogic Server Diagnostic Framework(WebLogic Server診断フレームワーク、WLDF)コンポーネントが提供します。
          以下のトピックについて各セクションで説明します。

          Log and Diagnostic Data

          様々なソースからのログと診断データはパーティション管理者が利用できます。これらのログや診断データは以下のように大別できます。
          1. 共有データ - ログと診断データはパーティション管理者が直接生の永続化された形で利用することはできず、WLDFアクセッサコンポーネントを使ってのみ利用できる。
            Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
            Accessing Diagnostic Data With the Data Accessor
            http://docs.oracle.com/middleware/1221/wls/WLDFC/access_diag_data.htm#WLDFC272
          2. パーティションスコープのデータ - これらのログは、パーティションファイルシステムのディレクトリ配下でRaw形式でパーティション管理者が利用可能
          WLDFデータアクセッサコンポーネントは、共有ログとパーティションスコープのログおよび、WebLogic Serverインスタンスでパーティションに対して利用可能とされている診断データにアクセスすることができますのでご注意ください。

          以下の共有ログと診断データへは、パーティション管理者がアクセスできます。
          ログの種類内容
          ServerServer.logファイルに記録された、パーティションに関連する、サーバやアプリケーションコンポーネントからのログイベント
          Domainパーティションに関連するWebLogicドメインのすべてのサーバインスタンスから収集されたログイベント。単一のログファイル。
          DataSourceパーティションに関連するDataSourceログイベント
          HarvestedData ArchiveWLDF Harvesterがパーティションに関連するMBeanから収集したメトリックデータ
          Instrumentation Events Archiveパーティションにデプロイされたアプリケーションが生成するWLDFインストルメンテ-ションイベント

          以下のパーティションスコープのログや診断データあはパーティション管理者からアクセスできます。
          ログの種類内容
          HTPP access.logパーティションの仮想ターゲットのWebサーバからのHTTPアクセスログ
          JMSServerパーティションを対象にしたリソースグループやリソースグループテンプレート内で定義されたJMSサーバリソースの、JMSサーバメッセージライフサイクルイベント
          SAF Agentパーティションを対象にしたリソースグループやリソースグループテンプレート内で定義されたSAFエージェントリソースの、SAFエージェントメッセージライフサイクルイベント
          Connectorパーティション内のリソースグループやリソースグループテンプレートにデプロイされたJava EEリソースアダプタモジュールが生成したログデータ
          Servlet Contextパーティション内のリソースグループやリソースグループテンプレートにデプロイされたJava EE Webアプリケーションモジュールが生成する、サーブレットコンテキストログデータ

          WLDF Accessor

          WLDFアクセッサは診断データをJMX経由で取得するためのRuntimeBeanインターフェースを提供します。データのサブセットのみ取得するためのクエリ機能も提供しています。
          この機能の詳細情報を知りたい方は、WLDFデータアクセッサのドキュメントをご覧ください。
          Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
          Accessing Diagnostic Data With the Data Accessor
          http://docs.oracle.com/middleware/1221/wls/WLDFC/access_diag_data.htm#WLDFC272
          WLDFPartitionRuntimeMBeanはPartitionRuntimeMBeanの子であり、WLDFランタイムMBeanのルートです。このMBeanは、パーティションを対象にしたWLDFアクセッサ機能のためのエントリポイントである、WLDFPartitionAccessRuntimeMBeanインターフェースのgetterを提供します。パーティションで利用可能な、各ログインスタンスに対するWLDFDataAccessRuntimeMBeanのインスタンスがあります。
          WebLogic Server MBean Reference
          WLDFPartitionRuntimeMBean
          http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/WLDFPartitionRuntimeMBean.html
          PartitionRuntimeMBean
          http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionRuntimeMBean.html
          WLDFPartitionAccessRuntimeMBean
          http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/WLDFPartitionAccessRuntimeMBean.html
          WLDFDataAccessRuntimeMBean
          http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/WLDFDataAccessRuntimeMBean.html
          事前定義された命名方式に従い、論理名によって異なるログが参照されます。
          下表は異なるパーティション対象のログに対する論理名のパターンをまとめたものです。

          Shared Logs

          ログの種類論理名
          Server LogServerLog
          Domain LogDomainLog
          JDBC LogDataSourceLog
          Harvested MetricsHarvestedDataArchive
          Instrumentation EventsEventsDataArchive

          Partition Scoped Logs

          ログの種類論理名
          HTTP Access LogHTTPAccessLog/<Webサーバ名>
          JMS Server LogJMSMessageLog/<JMSサーバ名>
          SAF Agent LogJMSSAFMessageLog/<SAFエージェント名>
          Servlet Context LogWebAppLog/<Webサーバ名>/context-path
          Connector LogConnectorLog/connection-Factory-jndiName$<パーティション名>

          Logging Configuration

          WebLogic Server Multitenancyはパーティション内で実行するアプリケーションコンポーネントが利用するjava.util.logging.Loggers内のレベルの構成をサポートしています。これにより、java.util.loggingを使うJava EEアプリケーションは、システムレベルのjava.util.loggingの設定機構にアクセスできなくても、それぞれのログレベルを設定することができるようになります。パーティション間で使われる、共通ライブラリが利用する共有ロガーインスタンスの場合、特定のパーティションに変わって設定しているのであれば、そのレベル構成もまたLoggerインスタンスに適用されます。
          この機能はWebLogic Serverシステム管理者が、
          -Djava.util.logging.manager=weblogic.logging.WLLogManager
          というコマンドライン・システムプロパティを付けて起動した場合に有効になります。

          WebLogic Serverを上述のようにカスタムログマネージャを使って起動すると、パーティション管理者は以下のようにロガーを構成できます。
          WebLogic Server Multitenanctのドキュメント中にある、WLSTサンプルスクリプトをチェックしてください。
          Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
          Configuring Partition Scope Debugging
          http://docs.oracle.com/middleware/1221/wls/WLSMT/monitoring.htm#WLSMT1337
          PartitionLogMBean.PlatformLoggerLevels属性で指定したレベルの設定は所有するパーティションに対してのみ有効です。同名のロガーインスタンスを別のパーティションで利用することができ、各ロガーの実行時の有効レベルは、それぞれのパーティションでのPartitionLogMBean.PlatformLoggerLevelsの設定によって定義されます。

          Server Debug

          あるトラブルシューティングのシナリオでは、パーティション固有のWebLogic Serverのサブシステムからのデバッグ出力を有効化する必要がある場合があります。サーバデバッグ出力はパーティションに代わって内部サーバコードのデバッグをする際に役に立ちますが、WebLogic Serverシステム管理者やOracle Supportと協同して注意しながら実施する必要があります。WebLogic Serverシステム管理者はまず ServerDebugMBean.PartitionDebugLoggingEnabled 属性を有効化する必要があります。その上で、特定のデバッグフラグを有効化するよう指示があります。これらのフラグはBoolean型の属性で、ServerDebugMBean構成インターフェースで定義されています。パーティションに対して有効化すべき特定のデバッグフラグをPartitionLogMBean.EnabledServerDebugAttributes属性を使って構成します。
          WebLogic Server MBean Reference
          PartitionLogMBean.EnabledServerDebugAttributes
          http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionLogMBean.html#EnabledServerDebugAttributes
          パーティションに対して有効化するための特定のデバッグ出力の名前の配列(String型)を含んでいます。デバッグ出力をサーバログに記録します。この出力はWLDFアクセッサを使って取り出すことができ、Oracle Supportにより詳細の分析をするために提供することができます。サーバデバッグを有効化するとパフォーマンスのオーバーヘッドが発生するため、トラブルシューティングが終われば、デバッグフラグを無効化する必要があることにご注意ください。

          パーティション固有のサーバデバッグを有効化する方法については、WebLogic Server MultitenancyドキュメントにあるWLSTサンプルスクリプトを参照してください。
          Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
          Configuring Partition Scope Debugging
          http://docs.oracle.com/middleware/1221/wls/WLSMT/monitoring.htm#WLSMT1337 

          Diagnostic System Module for Partitions

          Diagnostic System Module(DSM、診断システムモジュール)は、ハーベスタ、ポリシー、パーティションにデプロイされたリソースグループやリソースグループテンプレートで定義可能なActionコンポーネントを提供します。

          Harvester

          WLDFハーベスタはMBeanメトリック値を定期的にポーリングし、後の診断や分析用に収集したデータをアーカイブする機能を提供します。PartitionRuntimeMBeanとその子MBeanだけでなく、パーティションにデプロイされたアプリケーションが作成したMBeanも含め、パーティションから見えるすべてのWebLogic ServerランタイムMBeanを収集することができます。
          WebLogic Server MBean Reference
          PartitionRuntimeMBean
          http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionRuntimeMBean.html 
          ハーベスタ構成では、サンプリング間隔、MBeanの主対、インスタンスの仕様、収集し永続化する必要のあるそれぞれのMBean属性を定義します。アーカイブされた収集済みメトリックデータは、前述の通りWLDFアクセッサコンポーネントから利用可能であることにご注意ください。
          以下のXMLは、診断システムリソースXMLディスクリプタに永続化されたハーベスタの構成例です。
          <harvester>
           <enabled>true</enabled>
           <sample-period>2000</sample-period>
           <harvested-type>
             <name>weblogic.management.runtime.ServletRuntimeMBean</name>
             <harvested-attribute>ExecutionTimeAverage</harvested-attribute>
             <namespace>ServerRuntime</namespace>
           </harvested-type>
           <harvested-type>
            <name>sandbox.mbean.SandboxCustomMBeanImpl</name>
            <namespace>ServerRuntime</namespace>
           </harvested-type>
          </harvester>

          WLDFハーベスタに関する詳細情報は、以下のドキュメントをご覧ください。
          Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
          Configuring the Harvester for Metric Collection
          http://docs.oracle.com/middleware/1221/wls/WLDFC/config_harvester.htm#WLDFC172

          Policies and Actions

          ポリシーとは、監視対象の条件をJavaの式言語(EL)で定義したルールです。WLDFでは、ルール条件を満足した場合に動き出すポリシーに添付することができるアクションを豊富に提供しています。

          以下のタイプのルールベースのポリシーを定義することができます。
          • ハーベスタ:WebLogicランタイムMBeanのメトリックもしくはアプリケーションが有するカスタムMBeanのメトリックに基づく
          • ログイベント:サーバログやドメインログのログメッセージに基づく
          • インストゥルメンテ-ションイベント:WLDFインストゥルメンテ-ションを使うJava EEアプリケーションの測定コードから生成されたイベント
          以下のスニペットはEL言語(EL式)を使ったポリシー構成の例です。
          <watch>
            <name>Session-Count-Watch</name>
            <enabled>true</enabled>
            <rule-type>Harvester</rule-type>
              <rule-expression>wls.partition.query("com.bea:Type=WebAppComponentRuntime,*", "OpenSessionsCurrentCount").stream().anyMatch(x -> x >= 1)
            </rule-expression>
            <schedule>
              <minute>*</minute>
              <second>*/2</second>
            </schedule>
            <notification>jmx-notif1</notification>
          </watch>
          <watch>
            <name>Partition-Error-Log-Watch</name>
            <rule-type>Log</rule-type>
            <rule-expression>log.severityString == 'Error'</rule-expression>
            <notification>jmx-notif1,r1,r2</notification>
          </watch>
          <watch>
           <name>Inst-Trace-Event-Watch</name>
            <rule-type>EventData</rule-type>
            <rule-expression>instrumentationEvent.eventType == 'TraceAction'</rule-expression>
            <notification>jmx-notif1</notification>
          </watch>
          以下の種類のアクションをパーティションでサポートしています。
          • JMS
          • SMTP
          • JMX
          • REST
          • Diagnostic Image
          ポリシーやアクションの構成について詳細は以下のドキュメントをご覧ください。
          Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
          Configuring Policies and Actions
          http://docs.oracle.com/middleware/1221/wls/WLDFC/config_watch_notif.htm#WLDFC188

          Instrumentation for Partition Applications

          WLDFは、パーティション・スコープにデプロイされたJava EEアプリケーションのためのバイトコード・インストゥルメンテ-ション・メカニズムを提供しています。アプリケーション用インストゥルメンテ-ションの構成は、META-INF/weblogic-diagnositcs.xml ディスクリプタファイルで指定します。

          WebLogic Serverシステム管理者がサーバレベルのインストゥルメンテ-ションを有効化している場合にのみ、この機能は利用可能です。また、パーティションにわたってクラスローダを共有するアプリケーションに対しては利用できません。

          以下はWLDFインストゥルメンテ-ションディスクリプタファイルの例です。
          <wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
            <instrumentation><enabled>true</enabled>
            <wldf-instrumentation-monitor>
              <name>Servlet_Before_Service</name>
              <enabled>true</enabled>
            <action>TraceAction</action>
            </wldf-instrumentation-monitor>
            <wldf-instrumentation-monitor>
              <name>MyCustomMonitor</name>
              <enabled>true</enabled>
              <action>TraceAction</action>
              <location-type>before</location-type>
              <pointcut>execution( * example.util.MyUtil * (...))</pointcut>
            </wldf-instrumentation-monitor>
          </instrumentation>
          For further details refer to the WLDF Instrumentation documentation.

          Diagnostic Image

          診断イメージは単一のZipファイル中に様々なWebLogic Serverのサブシステムの状態をキャプチャするコアダンプに似ています。WLDFはパーティション固有の診断イメージのキャプチャをサポートしています。
          診断イメージは以下の方法で取得できます。
          パーティションのファイルシステムのlogs/diagnostic_imagesディレクトリにイメージを出力します。
          パーティションイメージには以下のような様々なソースからの診断データが含まれています。
          • Connector
          • Instrumentation
          • JDBC
          • JNDI
          • JVM
          • Logging
          • RCM
          • Work Manager
          • JTA
          詳細情報はWLDFのドキュメントをご覧ください。
          Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
          Configuring and Capturing Diagnostic Images
          http://docs.oracle.com/middleware/1221/wls/WLDFC/config_diag_images.htm#WLDFC150

          RCM Runtime Metrics

          WebLogic server 12.2.1ではリソース消費管理(Resource Consumption Management, RCM)機能が導入されました。この機能はOracle JDK 8u40以後でのみ利用可能です。
          Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
          Configuring Resource Consumption Management
          http://docs.oracle.com/middleware/1221/wls/WLSMT/config_rcm.htm#WLSMT630
          RCMを有効にするには、以下のコマンドラインスイッチをサーバー起動時のスクリプトに追加する必要があります。
          -XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC
          RCMは起動スクリプトではデフォルトで有効化されていないことにご注意ください。
          PartitionRuntimeMBeanの子であるPartitionResourceMetricsRuntimeMBeanは監視目的で役立つメトリックを提供します。
          WebLogic Server MBean Reference
          PartitionResourceMetricsRuntimeMBean
          http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionResourceMetricsRuntimeMBean.html
          PartitionRuntimeMBean
          http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionRuntimeMBean.html
          属性のGetter説明
          isRCMMetricsDataAvailable()Checks whether RCMメトリックデータがこのパーティションで利用可能かどうかを確認する。
          getCpuTimeNanos()パーティションに関わる総CPU利用時間(nsec)
          getAllocatedMemory()パーティションに割り当てられたメモリの総量(byte)。このメトリック値は時間がたつにつれて単調増加する。
          getThreadCount()現在パーティションに割り当てられているスレッドの個数
          getTotalOpenedSocketCount()

          getCurrentOpenSocketCount()
          (上)パーティションに関わるオープンしているソケットの総数
          (下)現在オープンしているソケットの個数
          getNetworkBytesRead()

          getNetworkBytesWritten()
          (上)パーティションで開いているソケットから読み込んだ総バイト数
          (下)パーティションで開いているソケットに書き込んだ総バイト数
          getTotalOpenedFileCount()

          getCurrentOpenFileCount()
          (上)パーティションで開いているファイルの総数
          (下)パーティションで現在開いているファイルの個数
          getFileBytesRead()

          getFileBytesWritten()
          (上)パーティションで開いているファイルから読み込んだ総バイト数
          (下)パーティションで開いているファイルに書き込んだ総バイト数
          getTotalOpenedFileDescriptorCount()

          getCurrentOpenFileDescriptorCount()
          (上)パーティションで開いているファイル識別子の総数
          (下)パーティションで現在開いているファイル識別子の個数
          getRetainedHeapHistoricalData()パーティションに保持されるヒープメモリ使用量の履歴データのスナップショットを返す。データはパーティションで保持されたヒープの利用状況の時系列データのため、2次元配列として返す。配列内の各項目は、[timestamp (long), retainedHeap (long) ]の値の組み合わせ。
          getCpuUtilizationHistoricalData()パーティションのCPU使用率の履歴データのスナップショットを返す。CPU使用率は、WebLogic Serverで’使用可能なCPUに対する、パーティションが利用したCPUの割合を示す。
          パーティションのCPU利用率は時系列データなので、2次元配列として返す。配列内の各項目は、[timestamp (long), cpuUsage(long)]の値の組み合わせ。
          PartitionMBean.RCMHistoricalDataBufferLimit属性がヒープやCPUのデータ配列のサイズを制限するということにご注意ください。
          WebLogic Server MBean Reference
          PartitionMBean.RCMHistoricalDataBufferLimit
          http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionMBean.html#RCMHistoricalDataBufferLimit

          Java Flight Recorder

          WLDFはJava Flight Recorderと統合し、WebLogic ServerのイベントをJVM記録に含めることができるようになっています。
          Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
          Using WLDF with Java Flight Recorder
          http://docs.oracle.com/middleware/1221/wls/WLDFC/using_flightrecorder.htm#WLDFC423
          パーティションの変わりに実行されたワークのコンテキストで生成されたWebLogic ServerイベントにはパーティションIDとパーティション名がタグ付けされています。これらのイベントとFlight RecordingデータはWebLogic Serverシステム管理者だけが利用できます。

          Conclusion

          WLDFは、トラブルシューティングや診断タスクで非常に役に立つ様々なタイプの監視データを収集、アクセスするための豊富なツール群を提供します。このブログエントリでは、パーティション管理者のためのWLDFの入門情報をご紹介しました。深掘りしてこれらの機能を確認し、本番環境で活用されることをお勧めします。その他の詳細情報は、以下のドキュメントをご覧ください。
          Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
          http://docs.oracle.com/middleware/1221/wls/WLDFC/
          Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
          Monitoring and Debugging Partitions
          http://docs.oracle.com/middleware/1221/wls/WLSMT/monitoring.htm#WLSMT639

          [Java] Modularity in Java 9

          $
          0
          0
          原文はこちら。
          https://blogs.oracle.com/java/entry/modularity_in_java_9

          Alan BatemanとMark Reinholdによる4プレゼンテーションでJava 9について学びましょう。「Prepare for JDK 9」では、Alanが describes JDK 9での変更、既存コードや将来の開発への影響を説明しています。

          「Introduction to Modular Development」では、Alanがモジュールの構造を説明し、基本モジュールをコンパイルしています。

          「Advanced Modular Development」では、MarkがJDK自身を例として、モジュラー開発の一連の原則を説明しています。

          「Project Jigsaw: Under the Hood」では、MarkがJava Platform Module Systemにおける可読性、可観測性、可視性、アクセスのしやすさの違いを説明しています。また、無名モジュール、プラットフォーム組み込みクラスローダ、異なる2バージョンのモジュールを動じにロード出来る方法を説明しています。

          [WLS, FMW] Oracle WebLogic Server 12.2.1 Continuous Availability

          $
          0
          0
          原文はこちら。
          https://blogs.oracle.com/WebLogicServer/entry/oracle_weblogic_server_12_2

          Oracle WebLogic Server 12.2.1の新機能であるContinuous Availabilityは、マルチデータセンターアーキテクチャを構成するためのEnd to Endのソリューションです。Continuous Availabilityを使うと、マルチデータセンター環境で実行しているアプリケーションは引き続きActive-Active環境で実行することができます。一方のサイトに障害が発生した場合、他方のサイトが停止したサイトのワークを回復します。アップグレードの間、アプリケーションは停止せずに引き続き実行できます。紐付けているのは自動化されたデータサイト・フェールオーバーで、フェールオーバやスイッチオーバイベント中の人的エラーとリスクを低減することを目的としています。

          Reduce Application Downtime

          WebLogic Zero Down Time Patching (ZDT)

          停止やセッションの消失を避けつつ、パッチのロールアウトやアップデートを自動的にオーケストレーションします。ロールアウトプロセスの自動化により、リスク、コスト、セッションの停止時間を削減します。ZDTは失敗時に自動的に再実行し、試行に失敗した場合にはロールバックします。この機能の詳細を知りたい方は、以下のエントリをご覧ください。
          Zero Downtime Patching Released!
          https://blogs.oracle.com/WebLogicServer/entry/zero_downtime_patching_released
          http://orablogs-jp.blogspot.jp/2015/11/zero-downtime-patching-released.html

          WebLogic Multitenant Live Partition Migration

          Multitenant環境において、ライブパーティションマイグレーションは、アプリケーションユーザへ影響を与えずに、実行中のパーティションやリソースグループを一方のクラスタから別のクラスタへ移行できる機能です。 アップグレード、負荷分散、もしくは切迫したパーティションの障害時に、アプリケーションに影響を与えずに移行することができます。

          Coherence Persistence

          永続ストレージにキャッシュデータとメタデータを永続化します。一つ以上のCoherenceサーバもしくはクラスタ全体に障害が発生した場合、永続データとメタデータを回復することができます。


          Replicate State for Multi-Datacenter Deployments

          WebLogic Cross Domain XA Recovery

          あるサイトもしくのWebLogic Serverドメインがダウンした、もしくはサイト全体が落ちた場合、生存しているサイトのドメインのトランザクションを自動的に回復する機能です。この機能を使うと、Active-Active Maximum Availability Architecture (MAA) でトランザクションリカバリの自動化が可能です。

          Coherence Federated Caching

          Coherenceのアップデートを配布します。衝突を解決しながら、分散した地理的サイト間でCoherenceの更新を配布します。レプリケーション・モードは、データを連続的に複製し、アプリケーションによるローカルキャッシュデータへのアクセスを提供するActive-Active、パッシブなサイトがアクティブなサイトのバックアップとして機能するActive-Passive、Hubがキャッシュデータを分散したSpokeに対して複製するHub Spokeです。

          Operational Support for Site Failover

          Oracle Traffic Director (OTD):

          高速で信頼性の高い、拡張性の富んだソフトウェアロードバランサで、ネットワーク上のアプリケーションやWebサーバへトラフィックをルーティングします。Oracle Traffic Directorはサーバの状態を認識しており、サーバをクラスタに追加すると、OTDは追加されたサーバへのトラフィックルーティングを開始します。OTD自身はActive-Active、Active-Passiveのいずれのモードでも利用可能です。

          Oracle Site Guard

          End-to-Endのディザスタ・リカバリ自動化を提供します。Oracle Site Guardはフェールオーバやスイッチオーバを自動化します。サイトコンポーネントを事前に定義した順序で停止させ、スクリプトを走らせ、フェールオーバ後のチェックを実行します。Oracle Site guardはフェールオーバやスイッチオーバ時の停止時間と人的エラーを最小限にします。

          Continuous Availabilityでは、アプリケーションのニーズに見合う、様々なトポロジーをサポートする柔軟性を提供しています。
          • Active-Activeアプリケーション層とActive-Passiveデータベース層の組合せ
          • Active-Passiveアプリケーション層とActive-Passiveデータベース層の組合せ
          • Active-Active StretchクラスタとActive-Passiveデータベース層の組合せ
          Continuous Availabilityは最大の可用性と生産性、データの整合性とリカバリ、マルチデータセンター環境におけるデータのローカルアクセス、データのアップデートへのリアルタイムアクセス、サイトのフェイルオーバーやスイッチオーバーの自動化をアプリケーションにもたらし、フェイルオーバー/スイッチオーバー時の人的エラーやリスクを削減します。Continuous Availability機能でアプリケーションが停止しないよう、保護しましょう。Continuous Availabilityについて詳細を知りたい方は、以下のドキュメント、もしくはContinuous Availabilityを説明する動画をご覧ください。
          Oracle® Fusion Middleware What's New in Oracle WebLogic Server 12.2.1 12c (12.2.1)
          Continuous Availability
          http://docs.oracle.com/middleware/1221/wls/NOTES/whatsnew.htm#NOTES610

          Viewing all 760 articles
          Browse latest View live


          <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>