「2012年weblogic server勉強会の総まとめ」

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 1

OTNイブニングセミナー第31回WebLogic Server勉強会＠東京

2012年WebLogic Server勉強会総集編

2012年12月14日

日本オラクル株式会社


2012年の「WebLogic Server勉強会」総まとめ目標

– 今年の勉強会の中から「さすがWebLogic」なポイントを総復習

– 参加者全員が情報を共有

– 2013年の「WebLogic Server勉強会」の目標設定（？）

進行

– 「さすがWebLogic」ベスト5を順番に発表

– ポイントを説明

– クイズにチャレンジ（全員参加型）

– Oracle ACE、会場の経験者からの声（先人の知恵を共有）


クラスタリング


WebLogic Server基本クラスター・アーキテクチャ

クラスタの重要な機能

– 負荷分散 – クラスタメンバにリクエストを均等に分配

– フェイルオーバ – 障害発生時も処理を別のクラスタメンバで継続する

mydomain

cluster1

Server1

Web コンテナ

EJB コンテナ

Server2

Web コンテナ

EJB コンテナ

RDBMS プロキシ

データソース

データソース

HTTPリクエストを負荷分散


WebLogic Serverクラスタの設定クラスタの設定: WebLogicドメインで設定

プロキシの設定: プロキシ側で設定

mydomain

cluster1

Server1

Web コンテナ

EJB コンテナ

Server2

Web コンテナ

EJB コンテナ

RDBMS プロキシ

データソース

データソース

AdminServer ドメイン設定

設定ファイル

HTTPサーバやロードバランサの設定

Weblogic Serverドメインの設定


HttpSessionインメモリレプリケーションプロキシプラグインの動作

– リクエストをWebLogic Serverにプロキシする

– リクエストのURLまたはMIMEタイプ、もしくはその両方でプロキシ可能

– セッションを持つHTTPリクエストはセッションを格納しているサーバにルーティングする

– クラスタ内の障害発生サーバにはプロキシしない

HttpSession をクラスタ内の2つのサーバで保持

– セッション毎にプライマリ・セカンダリサーバが決定される

– サーバにはプライマリ・セカンダリセッションが混在する

メモリ消費量が増大する

cluster1

プロキシ

Server1 Server2 Server3

セカンダリ

1

クライアント

プライマリ

1

2 2

3

3


HttpSessionインメモリレプリケーション

プライマリ = Server3

セカンダリ = Server2

プライマリサーバは負荷分散によって初回リクエスト時に決定

– セカンダリサーバはレプリケーション・グループとマシン設定からHttpSession生成時に決定

– セカンダリサーバへの同期はHttpSession#setAttribute()がトリガになる

– プライマリ・セカンダリサーバ情報はCookieに埋め込まれる

cluster1

プロキシ


セカンダリ

setAttribute()

クライアント

プライマリ



プライマリサーバに障害が発生するとセカンダリが昇格

– 別のサーバでセカンダリが再生成される

プロキシプラグインによってセカンダリサーバにリクエストの振り替えられる

– 振り替えはクライアントからの次のリクエスト時

– プロキシプラグインはCookieのサーバリストをもとにセカンダリサーバに接続



cluster1

プロキシ

クライアント


プライマリプライマリセカンダリ



プライマリに昇格したサーバはCookieを更新

– プライマリとセカンダリ情報が更新されたCookieがクライアントに戻される

cluster1

プロキシ

Server1 Server3

セカンダリ



Server2

setAttribute()

プライマリ

クライアント


インメモリレプリケーションの考慮事項

リクエストのフェイルオーバはプラグインによって行われる

– クライアントからのリクエスト到達までにプライマリ/セカンダリサーバが共にダウンするとセッションは継続できない

– セッションの消失が許容できない場合はインメモリレプリケーションは選択不可

– IMRを使用する場合は3つ以上のサーバでクラスタを構成することを推奨

HttpSessionに格納するデータサイズが大きすぎるとレプリケーションでオーバーヘッドが発生する

– HttpSessionに格納するデータは可能な限りコンパクトに

java.io.Serializableの実装も忘れずに

– 同期のトリガはHttpSession#setAttribute()


WebLogic Serverの

トランザクション


WebLogic ServerとJava EE

WebLogic Server

JNDI

トランザクションマネージャ

セキュリティ・レルム

LDAP ATN Audit

or ATZ

JMSサーバ Destination

(Queue /Topic)

JDB

C

データソース

RDBMS

Web サーバ

Plug

In Web Container

EJB Container

Java EE アプリケーショ

ン

JMS

RMI

JTA

JDBC JAAS

JNDI

Servlet

JSP EJB JPA JSF


X/Open DTPモデル

Application Program (AP)

Transaction Manager

(TM)

Resource Manager (RM) Resource Manager

(RM) Resource Manager (RM)

XA

APはトランザクション境界を指定

APはRMを介してリソースを使用

TMとRMのインタフェース


Java EEにおけるトランザクション仕様

JTA(Java Transaction API)

– X/Open DTPモデルをベースにした分散トランザクションAPIトランザクションマネージャとトランザクション参加者であるアプリケーション、リソースマネージャが使用する標準インタフェースを提供

javax.transaction.TransactionManager - トランザクションマネージャが使用

javax.transaction.UserTransaction – ユーザが使用

javax.transaction.xa.* - トランザクションマネージャ(TM)とリソースマネージャ(RM)間の規約

JTS (Java Transaction Service)

– JTAをサポートするトランザクションマネージャ実装を提供OMG Object

Transaction Service(OTS) 1.1 仕様に対応したJava実装のサービス


WebLogic Serverのトランザクション設定

トランザクションサービスはWebLogic Server起動時に開始される

トランザクションの設定

– ドメイン・レベルで設定を行う

– ドメインで同じトランザクション設定を使用

トランザクションのモニタリング

– サーバ・レベルでモニタリングを行う

– 管理コンソール, WLST …

参加リソース(JDBCデータソースなど)の設定

– リソース・レベルで設定を行う

トランザクションサービス


トランザクションのモニタリングサーバ・レベルで監視


TRS(トランザクション回復サービス)

WebLogic ServerのTMではトランザクション回復サービスを提供

– サーバ起動時に自動的に実行

– TLogを解析して未完了のトランザクションの解決を行う

– 2PC処理を完了させる(フェーズ1, フェーズ2)

– ヒューリスティックな終了をログに記録

サーバに障害が発生した場合の対応

– TLogにアクセスできる状態でサーバを起動する

– ハードウェア障害に対応するにはTLogの複製が必須

– 高性能Disk or JDBCストア

– クラスタ構成の場合はサービス移行orサーバ移行可能


JDBC TLOGとは

従来はファイルストア(デフォルト・ストア)のみに格納できたトランザクション・ログ(TLOG)を、より信頼性かつ利便性の高いデータベースへ格納できるようにした機能


Logging Last Resource(LLR)

XA Data

Source

Non-XA Data

Source

JMS XA

Connection

1 WebLogic

Server

(TM)

Application

Commit

2

2 2PC:prepare

3

4

5

5

2PC:commit

非XAリソースコミット

(ローカルTX)

コミットレコード

挿入

LLR Table


「ヒューリスティック」 2PC処理中にRMによる一方的な決定(commit/rollback)が行われた状態

– インダウト中のTM障害や、トランザクション破棄、トランザクションの手動解決などにより発生

– ヒューリスティックな終了の状態によってスローされる例外が異なる

ヒューリスティックな決定説明

HeuristicRollback RMがRollbackしてしまった。TMが他のTXブランチをコミットすると不整合発生

HeuristicCommit RMがCommitしてしまった。TMが他のTXブランチをRollbackすると不整合発生

HeuristicMixed 複数のリソースでHeuristicRollbackとHeuristicCommitが発生していることをTMが認識している状態

HeuristicHazard HeuristicMixedが発生しているが、TMがRMのステータスを識別できていない状態


WebLogic Scripting Tool

(WLST)とMBean


WebLogic Scripting Tool(WLST)とは WLSTはWebLogic ドメインの作成、管理、監視に使用できる

– 構成情報、監視情報をあらわすMBeanを直接操作可能

– 構成情報: ConfigurationMBean / EditMBean

– 監視情報: RuntimeMBean

Jythonベースのツール

用途に応じた起動モード

– 対話モード/スクリプトモード/組み込みモード

WLSTではMBeanをダイレクトに操作するのでMBeanの理解を深める必要があります


JMX MBeanとは

JMX (Java Management Extensions)

– Java環境の管理・監視のための標準仕様

– JCPのJSR-003(JMX ) と JSR-160(JMX Remote)で策定されている。

MBean (Managed Bean)

– JMX仕様の中で定義されている管理/監視用のJavaコンポーネント

– MBean Server経由で管理対象の状態を取得したり、操作や通知を行うインターフェースをもつ


JMX MBeanのアーキテクチャ

MBean

MBean

MBean

管理対象

管理対象

管理対象

Connector

Protocol

Adapter

MBean Server

Agent Level Instrumentation Level Distributed Services Level

JMX-compliant

Management

Application

Web

Browser

HTTP

Instrumentation Level 管理対象にアクセスするためのMBeanを指すレイア

Agent Level MBeanのコンテナとなるMBean Serverを指すレイア。MBeanは、MBean Serverへ登録することで利用可能になる。

Distributed Services Level Connectorや Protocol Adapterを通じてMBean Serverと通信するためのインターフェースを指すレイア


WebLogic ServerのMBeanサーバ

MBeanサーバ種類概要 MBeanサーバの

ホストになるもの

Domain Runtime

MBeanサーバ

ドメイン全体のサービス用の MBean。この MBean サーバは、管理対象サーバ上にある MBean への単一のアクセスポイントとしても機能する。

WebLogicの

管理サーバ

Runtime

MBeanサーバ

特定の WebLogic Server インスタンスのモニタ、実行時制御、およびアクティブなコンフィグレーションを表すMBeanを提供する MBeanサーバ。

WebLogicドメイン中の管理サーバと

管理対象サーバ

Edit

MBeanサーバ

保留中のコンフィグレーション MBean と、WebLogic Server

ドメインのコンフィグレーションを制御するMBeanを提供する。変更のロック、保存、およびアクティブ化用の

ConfigurationManagerMBean をエクスポーズする。

ドメインのコンフィグレーションを変更するには、この MBean

サーバを使用する。

WebLogicの

管理サーバ

JVMのプラットフォームMBeanサーバ

JVMから提供されJVM 自体のモニタ情報を保持する MBean

サーバ。このMBeanサーバからWebLogicのRuntime MBean

サーバを利用することも可能

JVM


WLSTのユースケースを語ろう！（デプロイ例）

準備完了

アクティブ

①

② ③

④

⑥ ⑤

⑦

デプロイなし

管理

③ ②

② ③

WLST weblogic.Deployer

① distributeApplication() -distribute

② startApplication() -start

③ stopApplication() -stop

④ undeploy() -undeploy

⑤ deploy() -deploy

⑥ undeploy() -undeploy

⑦ redeploy() -redeploy


Active GridLink for RAC


Active GridLink for RACのポイント

1. Universal Connection Pool(UCP)との統合

2. Single Client Access Name(SCAN)に完全対応

3. RACからの通知による高速接続フェールオーバ

(Fast Connection Failover; FCF)

4. RACの負荷状況を考慮した実行時接続ロードバランシング

(Runtime Connection Load Balancing; RCLB)

5. XAトランザクションのRACインスタンス・アフィニティ

6. WebセッションのRACインスタンス・アフィニティ(WLS12.1.1～)


Active GridLink for RACの仕組み

WebLogicデータソースと統合されたUCP(Universal Connection Pool)が、ONS(Oracle Notification Service)から通知されるRAC側の構成変更/負荷状況のイベントを元に、適切な接続の制御(ロードバランシング、フェールオーバ、アフィニティ)をおこなう

O

NS clie

nt

UCP-RAC

モジュール

ONS Daemon

ONS Daemon

WebLogic Server Oracle Database（RAC）

死活・負荷状況通知

GridLinkデータソース

（サービスA用）

インスタンス1

インスタンス2

サービス

A


実行時接続ロードバランシング(RCLB)

WebLogic

Connection Pool

Application

I’m busy

I’m very busy

I’m idle

30% connections

10% connections

60% connections

RAC Database

Instance1

Instance2

Instance3


XAアフィニティ

WebLogic Server

RAC Database

Instance1

Instance2

Instance3

EJB1

WebLogic Server

EJB

EJB3

EJB2

EJB4 Transaction

Affinity Context


Web セッション・アフィニティ

RAC Database

Instance1

Instance2

Instance3

WebLogic Server

Servlet

JSP

Servlet

JSP

JSP

HttpSession

Affinity Context


GridLink for RACを語ろう！

WebLogic Server

+

Oracle RAC

プロジェクト経験者


JRockit Flight Recorder


JRockit Flight Recorder + Mission Control Client JVMの挙動の常時記録と分析

ヒープメモリ利用率の増加傾向ヒープメモリを占めるオブジェクトの割合と増加率

1. トラブルの確実な原因追究を「遡って」実施可能

2. 障害発生→改善のサイクルと手間を大きく短縮化


JRockit Flight Recorder のアーキテクチャ

JRockit JVM

Flight Recorder Runtime

循環バッファー

Appli

catio

n

JRockit Mission Control

WLDF

イベントイベント

Appli

catio

n

アプリ

Thread Buffer

Global Buffer

Disk File

新しいデータ

古いデータ

WLST

JVM

Runti

me jrcmd

ダンプ解析あふれたら移動

あふれたら移動

ダンプ依頼

ダンプ依頼

ダンプ

ルールに基づく

ダンプトリガー

ダンプ依頼

廃棄


JRockit Flight Recorderの記録を開始、終了

一時データを/var/log/jfrディレクトリに格納し、最低でもアプリケーション実行の最後の5分間分のデータを確保するようなデフォルト記録を有効にする場合

– XX:FlightRecorderOptions=defaultrecording=true,disk=true,repository=/va

r/log/jfr,maxage=5m

格納されるデータ量は絶対バイト数または有効期間のいずれかで設定

– 最大サイズの設定: maxsize=<size>

例: 5m k(キロバイト)、m(メガバイト)およびg(ギガバイト)

– 最大有効期間の設定: maxage=<age>

例:10s s(秒)、m(分)、h(時)またはd(日)

コマンド行に指定する場合の例


JRockit Flight Recorderの記録を開始、終了

jrcmd <pid> start_flightrecording duration=60s

filename=myrecording.jfr

jrcmd <pid> check_flightrecordin

jrcmd <pid> stop_flightrecording recording=1

(パラメータはcheck_flightrecordinのステータス)

jrcmdコマンドで開始、確認、終了する場合


Flight Recorderの実体は”イベント”にあり

Flight Recorderは、実行中に発生するイベントを記録

イベントは、関連付けられたデータを持つ個別のデータ・ポイント

特定の時間に発生したCPU負荷またはロックを待機中のスレッドなど、実行中に発生する記録可能な現象

イベント・タイプはリレーショナル・キーによって参照され、JVMまたはアプリケーションでどのタイプのサブシステムに所属するかを示す。

記録するデータ量を制御するためにイベント・タイプをコンフィグレーション


フライトレコーダのイベントの例 http://docs.oracle.com/cd/E22646_01/doc.40/b61448/app_events.htm#BABJJJGA

名前説明パス

例外スロー

java/exception_throw

ファイル読取り Java

FileInputStream/RandomAccessFile/FileChannelからの読取り

java/file_read

ファイル書込み Java

FileInputStream/RandomAccessFile/FileChannelへの書込み

java/file_write

Javaモニター・エントリ Javaモニターへのエントリ java/monitor_enter

Javaモニター待機 Javaモニターを待機中 java/monitor_wait

新規TLAで割り当てられたオブジェクトオブジェクトが割り当てられ、新しいスレッド・ローカル領域(TLA)の取得が必要になりました

java/object_alloc_in_new_tla

TLAの外部で割り当てられたオブジェクトオブジェクトがTLAの外部で(ヒープに直接)

割り当てられました java/object_alloc_outside_tla

ソケット読取り Java Socket/SocketChannelからの読取り java/socket_read

ソケット書込み Java Socket/SocketChannelへの書込み java/socket_write


Flight Recorderについて語ろう！

Flight Recorderを

使ってみたら…….

「2012年weblogic server勉強会の総まとめ」

Technology