Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

1,918
views

Published on

第25回WebLogic Server勉強会@東京 …

第25回WebLogic Server勉強会@東京
………………………………………………
6月28日(木)18:30~/日本オラクル株式会社 本社

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

クラスタに対する負荷分散の設定(HTTP, RMI, JMS ...)やサービス/サーバの
移行などWebLogic Serverクラスタが提供する高可用性を実現する機能について
ご紹介します。

日本オラクル オラクルユニバーシティ
岡田大輔

Published in: Technology

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,918
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
85
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. <Insert Picture Here>続・はじめての WebLogic Server クラスタリング日本オラクル株式会社 オラクルユニバーシティ岡田 大輔2012年06月28日
  • 2. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。 Copyright© 2012, Oracle. All rights reserved. 2
  • 3. Agenda• 前回のおさらい• マシンとクラスタ• JMSのクラスタ対応• サービスの移行 Copyright© 2012, Oracle. All rights reserved. 3
  • 4. 復習:ドメイン、マシン、クラスタ、サーバ• クラスタはWebLogicドメインで管理されるリソース • 複数ドメインに跨るクラスタは構成できない • 管理対象サーバで構成するのが原則 ドメイン トランザクション セキュリティ マシン 管理サーバ ログ etc NM クラスタ 設定ファイル 管理対象サーバ ($DOMAIN/config) ログ etc JMSサーバ JDBC データソース アプリケーション 診断モジュール JMSモジュール マシン 管理対象サーバ ログ etc JMSサーバ NM 管理対象サーバ ログ etc JMSサーバ Copyright© 2012, Oracle. All rights reserved. 4
  • 5. WebLogic Server クラスタ• 複数の『サーバ』の論理的なグループ • 各サーバ上にデプロイされたアプリケーション・サービスに 対して拡張性・高可用性を提供する • クライアントからは単一のサーバにアクセスしているように 見えるように複数のサーバが協調動作する クラスタ サーバ サーバ アプリケーション クライアント サービス サーバ サーバ クライアントはアクセス するサーバを意識しない Copyright© 2012, Oracle. All rights reserved. 5
  • 6. クラスタ化できるもの• クラスタの重要な機能 • 負荷分散 – クラスタメンバにリクエストを均等に分配 • フェイルオーバ – 障害発生時も処理を別のクラスタメンバで 継続する• クラスタ対応になるアプリケーション・サービス • Webアプリケーション, EJB • JMS送り先 (分散送り先) • JDBCデータソース • JMSサーバ, JTA (移行) • JNDI (JNDIツリーの同期) Copyright© 2012, Oracle. All rights reserved. 6
  • 7. Webアプリケーションのクラスタ化• クラスタにデプロイされたWeb アプリケーションへ の負荷分散・フェイルオーバーはプロキシプラグイ ンによって行われる • WebLogic Server Plugin (HTTP サーバ) • ロードバランサ• Webアプリケーションのフェイルオーバにはユーザ の対話状態(HttpSession)を永続化する必要がある高 低 • インメモリレプリケーション 通常はインメモリレプリケーシ • Cookie 信頼性 ョンを第一候補に検討速度 HttpSessionの消失が許容できな • File い場合はJDBCを検討低 高 • JDBC Copyright© 2012, Oracle. All rights reserved. 7
  • 8. HttpSession永続化設定• HttpSessionの永続化設定は、Webアプリケーション の デプロイメント記述子(weblogic.xml)で指定 • デフォルトは memory (永続化なし) • IMRはreplicated | replicated_if_clustered 永続化方式にreplicated_if_clustered を指定すると、クラスタ、非クラス タにデプロイ可能 Copyright© 2012, Oracle. All rights reserved. 8
  • 9. インメモリレプリケーション• HttpSession をクラスタ 内の2つのサーバで保持 する クライアント • セッション毎にプライマリ ・セカンダリサーバが決定 される プロキシ • サーバにはプライマリ・セ カンダリセッションが混在 する Server1 Server2 Server3 • メモリ消費量が増大する 3 1 1 セカンダリ プライマリ 2 2 3 cluster1 Copyright© 2012, Oracle. All rights reserved. 9
  • 10. ここで問題:• インメモリレプリケーションでセカンダリセッショ ンの作成先に影響するのはどれ? (2つ選択) • ドメイン • マシン • レプリケーショングループ • 移行送り先 • NodeManager Copyright© 2012, Oracle. All rights reserved. 10
  • 11. Agenda• 前回のおさらい• マシンとクラスタ• JMSのクラスタ対応• サービスの移行 Copyright© 2012, Oracle. All rights reserved. 11
  • 12. 問題の答え:• インメモリレプリケーション時のセカンダリセッシ ョンは、マシンとレプリケーショングループによっ て制御される • 別マシン上のサーバが優先的に選択される • レプリケーショングループが設定されている場合はセカンダ リプリファレンスグループのサーバが優先的に選択される Copyright© 2012, Oracle. All rights reserved. 12
  • 13. マシンとは?• サーバが配置される物理的なH/W区画を表す • NodeManagerを配置する単位 • インメモリレプリケーションの境界線• マシンを定義していないサーバは? • 個々に独立した(匿名の)マシンに属していると認識される Copyright© 2012, Oracle. All rights reserved. 13
  • 14. マシン• マシンを定義する場合 = H/W境界と一致する ドメインA ドメインB マシンA マシンX マシンY サーバ1 サーバ2 サーバ1 サーバ2 サーバ3 サーバ4 (管理サーバ) (管理対象サーバ) (管理サーバ) (管理対象サーバ) (管理対象サーバ) (管理対象サーバ) 物理サーバ 物理サーバX 物理サーバY• マシンを定義しない場合 = H/W境界と一致しない場合がある ドメインA ドメインB マシン マシン マシン マシン マシン マシン サーバ1 サーバ2 サーバ1 サーバ2 サーバ3 サーバ4 (管理サーバ) (管理対象サーバ) (管理サーバ) (管理対象サーバ) (管理対象サーバ) (管理対象サーバ) 物理サーバ 物理サーバX 物理サーバY Copyright© 2012, Oracle. All rights reserved. 14
  • 15. インメモリレプリケーションとマシン• セカンダリセッションの クライアント 作成先は別マシン上のサ ーバが優先される • 1つのH/W上に複数のサーバ( プロキシ クラスタメンバ)が存在する場 合はマシンを定義しないと同 一H/W上にセカンダリセッシ ョンが作成される可能性があ MachineX MachineY る Server1 Server2 Server3 1 1 セカンダリ プライマリ 2 2 2 cluster1 Copyright© 2012, Oracle. All rights reserved. 15
  • 16. こんな場合はどうする?• 別マシンでもセカンダリセッションを作りたくない 場合 クラスタX サーバ2のセカンダリセ マシンM マシンN ッションはサーバ3-8の いずれかに作成される サーバ1 サーバ2 サーバ3 サーバ4 (管理対象サーバ) (管理対象サーバ) (管理対象サーバ) (管理対象サーバ) 物理サーバM 物理サーバN マシンO マシンP サーバ5 サーバ6 サーバ7 サーバ8 (管理対象サーバ) (管理対象サーバ) (管理対象サーバ) (管理対象サーバ) 物理サーバO 物理サーバP Copyright© 2012, Oracle. All rights reserved. 16
  • 17. レプリケーショングループとは• 製品マニュアルでは セッション状態のレプリカの格納先として使用する、クラスタ内 のサーバー・インスタンスの優先順を定義するリストです。• 超訳: 『マシンをグループ化』する設定 • レプリケーショングループ: 同じH/W(マシン)区画に存在する サーバのグループ(= セカンダリを優先的に作りたくない) • セカンダリプリファレンスグループ: 異なるH/W(マシン)区画 に存在するサーバのグループ(=セカンダリを優先的に作りた い) • マシン境界線だけでインメモリレプリケーションが成立する 場合は設定不要 Copyright© 2012, Oracle. All rights reserved. 17
  • 18. レプリケーショングループとセカンダリ プリファレンスグループ クラスタX マシンM マシンN レプリケーショングループ: group1 サーバ1 サーバ2 サーバ3 サーバ4 セカンダリプリファレンス (管理対象サーバ) (管理対象サーバ) (管理対象サーバ) (管理対象サーバ) グループ: group2 group1 マシンO マシンPレプリケーショングループ:group2 サーバ5 サーバ6 サーバ7 サーバ8 (管理対象サーバ) (管理対象サーバ) (管理対象サーバ) (管理対象サーバ)セカンダリプリファレンスグループ: group1 group2 Copyright© 2012, Oracle. All rights reserved. 18
  • 19. レプリケーショングループの設定 設定はクラスタメンバ(管理対象サーバ) ごとに行う レプリケーション・グループ: 同じH/W区画のサーバにつけるグループ名 セカンダリ・プリファレンス・グループ: セカンダリを優先的に作成するサーバのグ ループ名 Copyright© 2012, Oracle. All rights reserved. 19
  • 20. セカンダリを作成するサーバの優先順位• マシンとレプリケーショングループの設定ではレプ リケーショングループの指定が優先される セカンダリ・プリファ ランク 別マシン レンスグループ 1 ○ ○ 2 ○ × 3 × ○ 4 × × Copyright© 2012, Oracle. All rights reserved. 20
  • 21. まとめ• 1つのマシンに複数のサーバが属する環境でクラスタ を構成する場合は、マシンを設定することを推奨 • インメモリレプリケーションを行う場合は必須 • セカンダリは別マシンに対して優先的に作成される • NodeManagerを使う場合は必須• セカンダリセッションの作成先を細かく制御したい 場合はレプリケーショングループを設定する • 設定はサーバ単位だが、考え方はマシン単位のほうが簡単 • 優先的にセカンダリを作成するサーバを セカンダリプリファ レンスグループ に指定する Copyright© 2012, Oracle. All rights reserved. 21
  • 22. Agenda• 前回のおさらい• マシンとクラスタ• JMSのクラスタ対応• サービスの移行 Copyright© 2012, Oracle. All rights reserved. 22
  • 23. 前提: JMSは固定サービス• 固定サービス: • 特定サーバ上でのみアクティブになるサービス • JMSサーバ, JTA など • クラスタにデプロイしてもクラスタ化されない Copyright© 2012, Oracle. All rights reserved. 23
  • 24. クラスタにデプロされたJMSサービス• JMSサーバは個々のサーバで動作する • JMSサーバ上の物理送り先も個々のサーバで動作する Cluster1JMSクライアントA lookup(Queue1) Server1 JNDI TIPS. JMSServer1 MDB WebLogicクラスタ Queue1 MDB ではJNDIツリーは MDB 同期されるのです send(msg) べてのクラスタメ ンバが同じツリー 階層を持つ = どのサーバをJMSクライアントB Server2 JNDI lookupしてもサー ビスアクセス可能 lookup(Queue2) JMSServer2 MDB Queue2 MDB MDB send(msg) Copyright© 2012, Oracle. All rights reserved. 24
  • 25. 分散送り先• 物理送り先をまとめる仮想の送り先 • アプリケーションは分散送り先をlookup • ProducerとConsumerで動きが異なる • Producer: メッセージ送信時に送信する送り先を決定 • Consumer: Consumer作成時に受信する送り先を決定 Copyright© 2012, Oracle. All rights reserved. 25
  • 26. 分散送り先を使用したメッセージング • JMSクライアントは分散送り先をルックアップする • 特別なプログラミングは不要 Consumer(受信クライアント)は生 Cluster1 成時に参照する物理送り先を決定 = 特定の物理送り先からメッセー 分散送り先はJNDIにバインド ジ受信 Server1 される JNDI JMSServer1 MDB MDB Queue1 MDB lookup(DQ1) JMSクライアントBsend(msg) Server2 JNDI JMSServer2 MDB MDBProducer(送信クライアント)はメッ Queue2 MDBセージ送信時に物理送り先を決定= 複数の送り先にメッセージ送信 Copyright© 2012, Oracle. All rights reserved. 26
  • 27. 分散送り先の作成 JMSアプリケーションでルック アップするためのJNDI名 宛先タイプ: 共通 – JMSモジュールの対象に対して 物理先を自動作成 重み付け – 手動で物理送り先を指定 (10.3.4から非推奨) ロードバランスポリシーは分散 送り先作成後に設定変更可能 Copyright© 2012, Oracle. All rights reserved. 27
  • 28. メッセージの負荷分散• 分散送り先は物理送り先にメッセージをルーティングする • 負荷分散アルゴリズム: ラウンドロビン | ランダム • ラウンドロビンはconfig.xmlの定義順 • 負荷分散への影響要素 1. JMSストアの有無 (永続メッセージングの場合) 2. トランザクションの有無 • トランザクションセッション中は同一JMSサーバを 3. サーバアフィニティ • 特定のサーバと接続している場合は、同じサーバに対して 優先的にJMS接続を行う JMSロードバランシングとサーバアフィニティ の有効化はJMS接続ファクトリで設定する Copyright© 2012, Oracle. All rights reserved. 28
  • 29. 送り先メンバーの確認• 共通分散送り先の作成で自動作成された物理送り先 • <JMSモジュール名>!<JMSサーバ名>@<分散送り先名> JMSサーバのモニタ分散送り先のモニタ Copyright© 2012, Oracle. All rights reserved. 29
  • 30. まとめ• クラスタ環境でJMSをする場合は分散送り先を使用す る • 特定のサーバがダウンしてもメッセージングを継続可能(可用 性の担保) • 分散送り先にメッセージングすることで負荷分散可能 • 物理送り先は固定サービスなのでクラスタ環境でもスケー ルしない Copyright© 2012, Oracle. All rights reserved. 30
  • 31. (参考): EJBのクラスタ化による負荷分散と フェイルオーバ• 条件: • RMI経由でEJB呼び出しがある場合のみ • 多層クラスタ or 基本クラスタへのリモートアクセス• いつでも負荷分散/フェイルオーバできるわけではない • Beanの種類 • 多重呼び出し不変の有無 EJBのクラスタ化の要否はクラスタ化のメリット(負荷分散/フ ェイルオーバ)を優先するか、連結の最適化(呼び出し効率の最 適化)を優先するかを検討して決定 Copyright© 2012, Oracle. All rights reserved. 31
  • 32. (参考): EJBの負荷分散ルール• Beanの種類(Stateless /Stateful)で異なる• Home/Remote (EJB 2.x)で異なる Home Remote Stateless SessionBean ○(Cluster-aware) ○(Replica-aware) Stateful Session Bean ○(Cluster-aware) ×(Pinned) Copyright© 2012, Oracle. All rights reserved. 32
  • 33. (参考): EJBのフェイルオーバ• フェイルオーバはメソッド呼び出し前後の例外(N/W例外など)が 対象 • メソッド実行中の例外はフェイルオーバの対象外• SLSBは 多重呼び出し不変(Idempotent)メソッドのみ • Deployment Descriptorで指定する必要あり • ビジネスロジック実装が多重呼び出し不変であるように考慮 する必要がある• SFSBはインメモリレプリケーションが必須 • Stateロールバックはjavax.ejb.SessionSynchronizationを実装 Home Remote Stateless Session Bean ○ △ (要Idempotent) Stateful Session Bean ○ △ (要IMR) 多重呼び出し不変(Idempotent) : 何回試行しても同じ結果になる処理 (SELECT処理など) Copyright© 2012, Oracle. All rights reserved. 33
  • 34. Agenda• 前回のおさらい• マシンとクラスタ• JMSのクラスタ対応• サービスの移行 Copyright© 2012, Oracle. All rights reserved. 34
  • 35. 移行• 固定サービスは特定のクラスタメンバ上で動作する ため、サーバに障害が発生するとサービスが停止す る• 移行: サービスを別のクラスタメンバで実行してサー ビスの可用性を向上する • 移行可能なサービス • JMS, JTA, SAFエージェント, パスサービス, カスタム永続ストア • 移行はサービス単位/サーバ単位で実行可能 • 移行は手動移行/自動移行が実行可能 Copyright© 2012, Oracle. All rights reserved. 35
  • 36. サービス移行とサーバ移行 サービス移行 サーバ移行Cluster1 Cluster1 Machine1 NM Server1 JMSServer2 Queue2 Server2 JMSServer2 Queue2 JMSServer1 Queue1 永続ストア Machine2 Server2 File | JDBC NM Server2 JMSServer2 JMSServer2 Queue2 Queue2 Copyright© 2012, Oracle. All rights reserved. 36
  • 37. JMS移行のポイント• JMS移行はサーバ動作中/停止後いずれでも使用可能 • 手動移行は計画停止中のメッセージング継続にも活用可能 • 移行→停止→起動→再移行• JMSサーバには永続ストアが必須 • JMSサーバごとに永続ストアを設定 • JDBCストアは非XAドライバでデータソースを構成 • 移行先のサーバからも永続ストアにアクセスできるように Copyright© 2012, Oracle. All rights reserved. 37
  • 38. JTA移行• 移行するのはトランザクション回復サービス(TRS) • 移行先サーバでTLOGをもとに未解決トランザクションを解 決 • 実行中の全てのトランザクションが移行するわけではない• 前提: • 移行サーバは障害発生サーバのTLOGにアクセスできる必要 がある • 移行中はTLOGの所有権が移行サーバに移る • 要TLOG共有 (File Share or JDBC TLOG Store) Copyright© 2012, Oracle. All rights reserved. 38
  • 39. JTA移行のポイント• JTA移行はサーバ停止後のみ実行可能 • サーバ障害発生時は、移行の前に障害サーバの再起動を最優 先で検討 • サーバが再起動できない場合に移行を行う• JTA移行中に障害発生サーバが再起動すると… • JTA移行(TRSの実行)は全て破棄される • 再起動中のサーバがTLOG所有権を取り戻し、TRSを実行 Copyright© 2012, Oracle. All rights reserved. 39
  • 40. 移行可能なターゲット• まとめて移行する必要があるサービスをグループ化 • 移行可能ターゲットを移行するとすべてのサービスが移行 [サービス移行ポリシー] –自動移行の振る舞いの指定 Manual: 手動移行 Exactly-once: 稼働中候補サーバのいずれかでサービ スを継続 Failure-Recovery: ユーザ優先サーバ(UPS)が起動して いる場合のみ実行。UPSに障害が発生すると候補サー バに移行 Copyright© 2012, Oracle. All rights reserved. 40
  • 41. サービスの手動移行 詳細メニューはコンフ ィグレーション・ロッ クを取得していないと 表示されない Copyright© 2012, Oracle. All rights reserved. 41
  • 42. サーバ移行• 障害発生時に別マシンでサーバを起動 • 手動移行と自動移行が可能 ([サーバ] – [移行]タブ) • サーバ移行には NodeManager が必須 • 管理対象サーバにはマシンを明示的に設定 • サーバは浮動IPを設定 (NodeManagerは固定IPでOK) • サーバのヘルス管理のためリースを使用する • 高可用性リースとコンセンサスリースから選択 • JTA/JMS自動移行の場合もリースが必要• 障害発生時は自動移行可能だがフェイルバックは手 動で行う Copyright© 2012, Oracle. All rights reserved. 42
  • 43. サーバの自動移行 Cluster Machine2 Machine1 Machine2でServer2の 1 起動を試行 Node Manager1 3 Node Manager2 Server 1 Server2起動時に Server 2 リース登録 2 Cluster Master リース Machine3 クラスタマスターが Server2のリース期限 6最初にクラスタに参加 切れを検出 Server 2したサーバがクラスタマスターになる 4 5 Node Machine3のNodeManager3に Manager3 アクセスしてServer2を起動 Copyright© 2012, Oracle. All rights reserved. 43
  • 44. サーバの手動移行 Cluster Machine2 NodeManager2経由で Server2を停止 1 Node Manager2手動移行 Server2のリース 2 削除 Server 2 Admin 3 Server リース Machine3 6 Server2起動時に Server 2 リース登録 4 5 Node Machine3のNodeManager3に Manager3 アクセスしてServer2を起動 Copyright© 2012, Oracle. All rights reserved. 44
  • 45. まとめ• クラスタにデプロイされる固定サービスの可用性を 向上させるには移行を使用可能 • サービス単位で別のクラスタメンバに • サーバ単位で別マシンに • 移行に必要とされるリソース設定を適切に行う• サーバ障害発生時は … • 障害発生サーバの再起動を検討 • 再起動できない場合は移行 Copyright© 2012, Oracle. All rights reserved. 45
  • 46. おわりに• WebLogic Serverのクラスタ機能はバージョンを重ね ながら着実に進化し続けています • HttpSessionの保護だけではなく、サービス移行やサーバの自 動移行、クラスタ間レプリケーションなどもカバーする包括 的な高可用性ソリューションです • クラスタの各機能を活用するには個々の要素を着実に理解し ておくことが重要です Copyright© 2012, Oracle. All rights reserved.
  • 47. Oracle Universityからのお知らせ• WebLogic Server クラスタリングをはじめとした WebLogic Serverの管理方法を学習したい方に最適な 研修コースをご提供しています。 • Classroomトレーニングだけでなく、Live Virtual Class、『Oracle ト レーニング・オンデマンド』など多様な受講形態から選択いただけ ます。 Copyright© 2012, Oracle. All rights reserved. 47
  • 48. ミドルウェア Oracle WebLogic Server 11g: 管理 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 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アプリケーション開発者 5日間 次回開催日程 ■7/9(月) - 7 /13(金) トレーニングキャンパス青山コース日程 日程の詳細は Oracle University Webサイト にてご確認ください。 ■8/27(月) - 8/31(金) 三田(芝浦)会場受講料 定価¥363,825(税込) ※Oracle PartnerNetwork会員様は、パートナー割引価格で受講いただけます。 Copyright© 2012, Oracle. All rights reserved.
  • 49. Copyright© 2012, Oracle. All rights reserved.
  • 50. Copyright© 2012, Oracle. All rights reserved. 50

×