続・はじめてのWebLogic Serverクラスタリング

<Insert Picture Here>

続・はじめての WebLogic Server クラスタリング

日本オラクル株式会社オラクルユニバーシティ岡田大輔 2012年06月28日

Copyright© 2012, Oracle. All rights reserved. 2

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

Copyright© 2012, Oracle. All rights reserved.

Agenda

• 前回のおさらい

• マシンとクラスタ

• JMSのクラスタ対応

• サービスの移行

3


ドメイン

マシン

マシン

クラスタ

復習:

ドメイン、マシン、クラスタ、サーバ

• クラスタはWebLogicドメインで管理されるリソース

• 複数ドメインに跨るクラスタは構成できない

• 管理対象サーバで構成するのが原則

4

管理対象サーバ



アプリケーション

JMSサーバ

セキュリティ

診断モジュール

管理サーバ

JMSサーバ

JMSサーバ

JDB

C データソース

JMSモジュール

ログ etc

ログ etc

ログ etc

ログ etc

トランザクション

NM

NM

設定ファイル

($DOMAIN/config)


• 複数の『サーバ』の論理的なグループ

• 各サーバ上にデプロイされたアプリケーション・サービスに対して拡張性・高可用性を提供する

• クライアントからは単一のサーバにアクセスしているように見えるように複数のサーバが協調動作する

クラスタ

WebLogic Server クラスタ

5

サーバサーバ

サーバサーバクライアント

クライアントはアクセスするサーバを意識しない

アプリケーションサービス


クラスタ化できるもの

• クラスタの重要な機能

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

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

• クラスタ対応になるアプリケーション・サービス

• Webアプリケーション, EJB

• JMS送り先 (分散送り先)

• JDBCデータソース

• JMSサーバ, JTA (移行)

• JNDI (JNDIツリーの同期)

6


Webアプリケーションのクラスタ化

• クラスタにデプロイされたWeb アプリケーションへの負荷分散・フェイルオーバーはプロキシプラグインによって行われる

• WebLogic Server Plugin (HTTP サーバ)

• ロードバランサ

• Webアプリケーションのフェイルオーバにはユーザの対話状態(HttpSession)を永続化する必要がある

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

• Cookie

• File

• JDBC

7

通常はインメモリレプリケーションを第一候補に検討 HttpSessionの消失が許容できない場合はJDBCを検討信

頼性

高

低

速度

高

低


HttpSession永続化設定

• HttpSessionの永続化設定は、Webアプリケーションのデプロイメント記述子(weblogic.xml)で指定

• デフォルトは memory (永続化なし)

• IMRはreplicated | replicated_if_clustered

8

永続化方式にreplicated_if_clusteredを指定すると、クラスタ、非クラスタにデプロイ可能


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

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

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

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

• メモリ消費量が増大する

9

cluster1

プロキシ

Server1 Server2 Server3

セカンダリ

1

クライアント

プライマリ

1

2 2

3

3


ここで問題:

• インメモリレプリケーションでセカンダリセッションの作成先に影響するのはどれ？ (2つ選択)

• ドメイン

• マシン

• レプリケーショングループ

• 移行送り先

• NodeManager

10


Agenda





11


問題の答え:

• インメモリレプリケーション時のセカンダリセッションは、マシンとレプリケーショングループによって制御される

• 別マシン上のサーバが優先的に選択される

• レプリケーショングループが設定されている場合はセカンダリプリファレンスグループのサーバが優先的に選択される

12


マシンとは？

• サーバが配置される物理的なH/W区画を表す

• NodeManagerを配置する単位

• インメモリレプリケーションの境界線

• マシンを定義していないサーバは？

• 個々に独立した(匿名の)マシンに属していると認識される

13


マシン

• マシンを定義する場合 = H/W境界と一致する

• マシンを定義しない場合 = H/W境界と一致しない場合がある

14

物理サーバ

ドメインA

マシンA

サーバ1 (管理サーバ)

サーバ2 (管理対象サーバ)

物理サーバX

ドメインB

物理サーバY

マシンX



マシンY

サーバ3

(管理対象サーバ)


物理サーバ

ドメインA

マシン



物理サーバX

ドメインB

物理サーバY





マシン

マシン

マシン

マシン

マシン


cluster1

MachineX MachineY

インメモリレプリケーションとマシン

• セカンダリセッションの作成先は別マシン上のサーバが優先される • 1つのH/W上に複数のサーバ(

クラスタメンバ)が存在する場合はマシンを定義しないと同一H/W上にセカンダリセッションが作成される可能性がある

15

プロキシ

Server1 Server2 Server3

セカンダリ

1

クライアント

プライマリ

1

2 2 2


こんな場合はどうする？

• 別マシンでもセカンダリセッションを作りたくない場合

16

物理サーバM

クラスタX

物理サーバN

マシンM

サーバ1



マシンN

サーバ3



物理サーバO 物理サーバP

マシンO

サーバ5



マシンP

サーバ7



サーバ2のセカンダリセッションはサーバ3-8のいずれかに作成される


レプリケーショングループとは

•製品マニュアルでは

• 超訳: 『マシンをグループ化』する設定

• レプリケーショングループ: 同じH/W(マシン)区画に存在するサーバのグループ(= セカンダリを優先的に作りたくない)

• セカンダリプリファレンスグループ: 異なるH/W(マシン)区画に存在するサーバのグループ(=セカンダリを優先的に作りたい)

• マシン境界線だけでインメモリレプリケーションが成立する場合は設定不要

17

セッション状態のレプリカの格納先として使用する、クラスタ内のサーバー・インスタンスの優先順を定義するリストです。


レプリケーショングループとセカンダリプリファレンスグループ

18

クラスタX

マシンM



マシンN



マシンO



マシンP



group1

group2

レプリケーショングループ: group2

セカンダリプリファレンス

グループ: group1

レプリケーショングループ: group1

セカンダリプリファレンス

グループ: group2


レプリケーショングループの設定

19

設定はクラスタメンバ(管理対象サーバ)ごとに行う

レプリケーション・グループ: 同じH/W区画のサーバにつけるグループ名セカンダリ・プリファレンス・グループ: セカンダリを優先的に作成するサーバのグループ名


セカンダリを作成するサーバの優先順位

20

• マシンとレプリケーショングループの設定ではレプリケーショングループの指定が優先される

ランクセカンダリ・プリファ

レンスグループ別マシン

1 ○ ○

2 ○ ×

3 × ○

4 × ×


まとめ

• 1つのマシンに複数のサーバが属する環境でクラスタを構成する場合は、マシンを設定することを推奨

• インメモリレプリケーションを行う場合は必須

• セカンダリは別マシンに対して優先的に作成される

• NodeManagerを使う場合は必須

• セカンダリセッションの作成先を細かく制御したい場合はレプリケーショングループを設定する

• 設定はサーバ単位だが、考え方はマシン単位のほうが簡単

• 優先的にセカンダリを作成するサーバをセカンダリプリファレンスグループに指定する

21


Agenda





22


前提: JMSは固定サービス

• 固定サービス:

• 特定サーバ上でのみアクティブになるサービス

• JMSサーバ, JTA など

• クラスタにデプロイしてもクラスタ化されない

23


Cluster1

クラスタにデプロされたJMSサービス

• JMSサーバは個々のサーバで動作する

• JMSサーバ上の物理送り先も個々のサーバで動作する

24

Server1

JMSServer1

Queue1

Server2

JMSServer2

Queue2

JMSクライアントB

JMSクライアントA

lookup(Queue1)

lookup(Queue2)

send(msg)

send(msg)

MDB MDB MDB

MDB MDB MDB

TIPS. WebLogicクラスタではJNDIツリーは同期されるのですべてのクラスタメンバが同じツリー階層を持つ = どのサーバをlookupしてもサービスアクセス可能

JNDI

JNDI


分散送り先

• 物理送り先をまとめる仮想の送り先

• アプリケーションは分散送り先をlookup

• ProducerとConsumerで動きが異なる

• Producer: メッセージ送信時に送信する送り先を決定

• Consumer: Consumer作成時に受信する送り先を決定

25


分散送り先を使用したメッセージング

• JMSクライアントは分散送り先をルックアップする

• 特別なプログラミングは不要

26

Cluster1

Server1

JMSServer1

Queue1

Server2

JMSServer2

Queue2

JMSクライアントB lookup(DQ1)

send(msg)

MDB MDB MDB

MDB MDB MDB

分散送り先はJNDIにバインドされる JNDI

JNDI

Producer(送信クライアント)はメッセージ送信時に物理送り先を決定 = 複数の送り先にメッセージ送信

Consumer(受信クライアント)は生成時に参照する物理送り先を決定 = 特定の物理送り先からメッセージ受信


分散送り先の作成

27

JMSアプリケーションでルックアップするためのJNDI名

宛先タイプ: 共通 – JMSモジュールの対象に対して物理先を自動作成

重み付け – 手動で物理送り先を指定(10.3.4から非推奨)

ロードバランスポリシーは分散送り先作成後に設定変更可能


メッセージの負荷分散

• 分散送り先は物理送り先にメッセージをルーティングする

• 負荷分散アルゴリズム: ラウンドロビン | ランダム

• ラウンドロビンはconfig.xmlの定義順

• 負荷分散への影響要素

1. JMSストアの有無 (永続メッセージングの場合)

2. トランザクションの有無

• トランザクションセッション中は同一JMSサーバを

3. サーバアフィニティ

• 特定のサーバと接続している場合は、同じサーバに対して優先的にJMS接続を行う

28

JMSロードバランシングとサーバアフィニティの有効化はJMS接続ファクトリで設定する


送り先メンバーの確認

• 共通分散送り先の作成で自動作成された物理送り先

• <JMSモジュール名>!<JMSサーバ名>@<分散送り先名>

29

分散送り先のモニタ

JMSサーバのモニタ


まとめ

• クラスタ環境でJMSをする場合は分散送り先を使用する

• 特定のサーバがダウンしてもメッセージングを継続可能(可用性の担保)

• 分散送り先にメッセージングすることで負荷分散可能

• 物理送り先は固定サービスなのでクラスタ環境でもスケールしない

30


(参考): EJBのクラスタ化による負荷分散とフェイルオーバ

• 条件:

• RMI経由でEJB呼び出しがある場合のみ

• 多層クラスタ or 基本クラスタへのリモートアクセス

• いつでも負荷分散/フェイルオーバできるわけではない

• Beanの種類

• 多重呼び出し不変の有無

31

EJBのクラスタ化の要否はクラスタ化のメリット(負荷分散/フェイルオーバ)を優先するか、連結の最適化(呼び出し効率の最適化)を優先するかを検討して決定


(参考): EJBの負荷分散ルール

• Beanの種類(Stateless /Stateful)で異なる

• Home/Remote (EJB 2.x)で異なる

32

Home Remote

Stateless SessionBean ○(Cluster-aware) ○(Replica-aware)

Stateful Session Bean ○(Cluster-aware) ×(Pinned)


(参考): EJBのフェイルオーバ

• フェイルオーバはメソッド呼び出し前後の例外(N/W例外など)が対象

• メソッド実行中の例外はフェイルオーバの対象外

• SLSBは多重呼び出し不変(Idempotent)メソッドのみ

• Deployment Descriptorで指定する必要あり

• ビジネスロジック実装が多重呼び出し不変であるように考慮する必要がある

• SFSBはインメモリレプリケーションが必須

• Stateロールバックはjavax.ejb.SessionSynchronizationを実装

33

多重呼び出し不変(Idempotent) : 何回試行しても同じ結果になる処理 (SELECT処理など)

Home Remote

Stateless Session Bean ○ △ (要Idempotent)

Stateful Session Bean ○ △ (要IMR)


Agenda





34


移行

• 固定サービスは特定のクラスタメンバ上で動作するため、サーバに障害が発生するとサービスが停止する

• 移行: サービスを別のクラスタメンバで実行してサービスの可用性を向上する

• 移行可能なサービス

• JMS, JTA, SAFエージェント, パスサービス, カスタム永続ストア

• 移行はサービス単位/サーバ単位で実行可能

• 移行は手動移行/自動移行が実行可能

35


サービス移行とサーバ移行

36

Cluster1

Server1

Server2

JMSServer1 Queue1

JMSServer2 Queue2

JMSServer2 Queue2

永続ストア File | JDBC

Cluster1

Machine1

Machine2

JMSServer2 Queue2

Server2

JMSServer2 Queue2

Server2

NM

NM

サービス移行サーバ移行


JMS移行のポイント

• JMS移行はサーバ動作中/停止後いずれでも使用可能

• 手動移行は計画停止中のメッセージング継続にも活用可能

• 移行→停止→起動→再移行

• JMSサーバには永続ストアが必須

• JMSサーバごとに永続ストアを設定

• JDBCストアは非XAドライバでデータソースを構成

• 移行先のサーバからも永続ストアにアクセスできるように

37


JTA移行

• 移行するのはトランザクション回復サービス(TRS)

• 移行先サーバでTLOGをもとに未解決トランザクションを解決

• 実行中の全てのトランザクションが移行するわけではない

• 前提:

• 移行サーバは障害発生サーバのTLOGにアクセスできる必要がある

• 移行中はTLOGの所有権が移行サーバに移る

• 要TLOG共有 (File Share or JDBC TLOG Store)

38


JTA移行のポイント

• JTA移行はサーバ停止後のみ実行可能

• サーバ障害発生時は、移行の前に障害サーバの再起動を最優先で検討

• サーバが再起動できない場合に移行を行う

• JTA移行中に障害発生サーバが再起動すると…

• JTA移行(TRSの実行)は全て破棄される

• 再起動中のサーバがTLOG所有権を取り戻し、TRSを実行

39


移行可能なターゲット

• まとめて移行する必要があるサービスをグループ化

• 移行可能ターゲットを移行するとすべてのサービスが移行

40

[サービス移行ポリシー] –自動移行の振る舞いの指定 Manual: 手動移行 Exactly-once: 稼働中候補サーバのいずれかでサービスを継続 Failure-Recovery: ユーザ優先サーバ(UPS)が起動している場合のみ実行。UPSに障害が発生すると候補サーバに移行


サービスの手動移行

41

詳細メニューはコンフィグレーション・ロックを取得していないと表示されない


サーバ移行

• 障害発生時に別マシンでサーバを起動

• 手動移行と自動移行が可能 ([サーバ] – [移行]タブ)

• サーバ移行には NodeManager が必須

• 管理対象サーバにはマシンを明示的に設定

• サーバは浮動IPを設定 (NodeManagerは固定IPでOK)

• サーバのヘルス管理のためリースを使用する

• 高可用性リースとコンセンサスリースから選択

• JTA/JMS自動移行の場合もリースが必要

• 障害発生時は自動移行可能だがフェイルバックは手動で行う

42


サーバの自動移行

43

Cluster

Server 1 Server 2

1

Cluster Master

Node Manager1

Node Manager2

リース

Machine1 Machine2

Server 2

Node Manager3

Machine3

2

3

4 5

6

Server2起動時にリース登録

最初にクラスタに参加したサーバがクラスタマスターになる

クラスタマスターがServer2のリース期限切れを検出

Machine2でServer2の起動を試行

Machine3のNodeManager3にアクセスしてServer2を起動


サーバの手動移行

44

Cluster

Admin Server

Server 2

2

Node Manager2

リース

Machine2

Server 2

Node Manager3

Machine3

3

1

4 5

6

Server2のリース削除

NodeManager2経由でServer2を停止

Machine3のNodeManager3にアクセスしてServer2を起動

Server2起動時にリース登録

手動移行


まとめ

• クラスタにデプロイされる固定サービスの可用性を向上させるには移行を使用可能

• サービス単位で別のクラスタメンバに

• サーバ単位で別マシンに

• 移行に必要とされるリソース設定を適切に行う

• サーバ障害発生時は …

• 障害発生サーバの再起動を検討

• 再起動できない場合は移行

45


おわりに

• WebLogic Serverのクラスタ機能はバージョンを重ねながら着実に進化し続けています

• HttpSessionの保護だけではなく、サービス移行やサーバの自動移行、クラスタ間レプリケーションなどもカバーする包括的な高可用性ソリューションです

• クラスタの各機能を活用するには個々の要素を着実に理解しておくことが重要です


Oracle Universityからのお知らせ

• WebLogic Server クラスタリングをはじめとしたWebLogic Serverの管理方法を学習したい方に最適な研修コースをご提供しています。 • Classroomトレーニングだけでなく、Live Virtual Class、『Oracle トレーニング・オンデマンド』など多様な受講形態から選択いただけます。

47


コース内容

■Oracle Fusion Middleware の概要 ■WebLogic Serverのアーキテクチャ

■Oracle WebLogic Serverのインストール ■管理コンソールおよび他の管理ツールの概要

■WebLogic Server ドメインのコンフィグレーション ■Oracle WebLogic Server の管理およびロギングの使用

■アプリケーションのデプロイ ■データソース、JDBCドライバ、接続プールの設定

■JMS アプリケーションのコンフィグレーション ■WebLogic Serverの基本セキュリティのコンフィグレーション

■Oracle HTTP Server のコンフィグレーション ■Oracle WebLogic クラスタのコンフィグレーション

■バックアップおよびリカバリの管理 ■全体バックアップ、増分バックアップ

受講

前提条件

・Linux の基本コマンドおよびデスクトップのナビゲーション

・クライアント/サーバーの概念における TCP/IP ネットワークに関する基本的な知識

・Java EE の基礎知識（サーブレットや JSP など） ※推奨

対象者・Oracle WebLogic Server 11g管理者

・Javaアプリケーション開発者

コース日程５日間日程の詳細は Oracle University Webサイトにてご確認ください。

受講料定価￥３６３，８２５（税込） ※Oracle PartnerNetwork会員様は、パートナー割引価格で受講いただけます。

Oracle Application Gridの基盤を支える

Oracle WebLogic Server 11gの管理コース！このコースでは、Web管理者がOracle WebLogic Server 11gのインストールおよび設定

する方法について説明します。Web管理者が管理コンソールやコマンドライン、および

スクリプトツール（WLST）などを使用して、Java EEアプリケーションをOracle

WebLogic Server 11gにデプロイする方法についても説明します。

その他に、Oracle WebLogic Server のWebインタフェースとしてOracle HTTP Serverを設

定する方法を解説し、またOracle WebLogic Serverクラスタを設定してアプリケーションのフェイルオーバーとロードバランシングをサポートする方法を学習します。また、

WebLogic Server管理者の管理タスクの概要について説明します。

Oracle WebLogic Server 11g：管理

ミドルウェア

次回開催日程 ■7/9(月) - 7 /13(金) トレーニングキャンパス青山

■8/27(月) - 8/31(金) 三田(芝浦)会場

http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getCourseDesc?dc=D58682JP10




Copyright© 2012, Oracle. All rights reserved. 50

Technology

続・はじめてのWebLogic Serverクラスタリング