Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,638 views

Published on

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

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

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

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

Published in: Technology
  • Follow the link, new dating source: ♥♥♥ http://bit.ly/2F7hN3u ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating for everyone is here: ❤❤❤ http://bit.ly/2F7hN3u ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

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

×