oracle weblogic server クラスタ

Copyright © 2017 Oracle and/or its affiliates. All rights reserved. |

Oracle WebLogic Server 12.2 クラスタ第61回 WebLogic Server 勉強会

日本オラクル株式会社オラクルユニバーシティ岡田大輔 2017 年 4 月 12 日


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

Oracle と Java は、米国オラクルコーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

2


本日お話すること

クラスタとは

クラスタの構成方法

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

クラスタあれこれ

3

1

2

3

4


クラスタとはクラスタの概要

4


WebLogic Server クラスタ

• 複数の『サーバー』の論理的なグループ – 各サーバー上にデプロイされたアプリケーション・サービスに対して拡張性・高可用性を提供する

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

• 高可用性(フェイルオーバー) … 障害発生時も処理を別のクラスタメンバで継続する

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

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

– JDBCデータソース

– JMSサーバー, JTA (移行)

– JNDI (JNDIツリーの同期)

5


ドメイン

マシン

マシン

クラスタ

おさらい: ドメインとリソース

6

トランザクション

管理サーバー

管理対象サーバー



セキュリティ

アプリケーション

データソース

診断モジュール

JMSモ

ジュール

サーバー・テンプレート

JMSサ

ーバー

ログ‘ etc

ログ etc

ログ etc

ログ etc ノード・マネージャ

ノード・マネージャ

config

設定ファイル


クラスタを構成する前の確認事項

• ライセンスの確認

–クラスタリング(高可用性機能)はEnterprise Editionから

• クラスタアーキテクチャの決定

–基本(単一層)クラスタ / 多層クラスタ

–プロキシ

• クラスタ間通信方式の決定

–ユニキャスト / マルチキャスト

7


クラスタ・アーキテクチャ基本クラスタ構成

• 単一クラスタにアプリケーションをデプロイ

–呼び出しの最適化

8

クラスタ

管理対象サーバー1

プロキシ

プラグイン

Dat

aSo

urc

e

Web コンテナ EJB コンテナ


Dat

aSo

urc

e


常に同一サーバー上の EJB を呼び出す

HTTPリクスエトを負荷分散


クラスタ・アーキテクチャ多層クラスタ構成

• WebアプリケーションとEJBを異なるクラスタにデプロイ

–可用性の向上

9

クラスタA


プロキシ

プラグイン

Web コンテナ


Web コンテナ

HTTPリクスエトを負荷分散

クラスタB


Dat

aSo

urc

e

EJB コンテナ


Dat

aSo

urc

e

EJB コンテナ

EJB 呼び出し(RMI) を負荷分散


プロキシプラグインの役割

• プロキシプラグインの動作

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

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

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

• プラグインの設定は、HTTPサーバーで設定する

– WebLogic ServerのプラグインファイルをHTTPサーバーに登録

–原則として WebLogic ドメインでは設定できない (OHS は除く)

10

プロキシ

プラグイン

• Oracle HTTP Server • Apache HTTP Server

• iPlanet Web Server • Microsoft Internet Information Server


クラスタメンバー間の通信 1対1 通信と 1対他通信

• クラスタメンバー間では次の目的で1対他通信を使用する

– クラスタメンバー間のハートビート

– JNDIツリーの同期

• クラスタ間の1対他通信にはユニキャスト、マルチキャストを使用可能

– WLS 10.0以上では原則としてユニキャストを使用

• WLS 9.2以前はマルチキャストのみ

• ユニキャスト用のネットワークチャネルを設定しないとデフォルトチャネルが使用される

11


まとめ: クラスタとは

• WebLogic Server クラスタは

– WebLogic Serverにデプロイされたアプリケーションやサービスを保護するための仕組み

–サーバープロセスそのものの保護が目的ではない

• クラスタを構成する前の確認事項

–ライセンスの確認

–クラスタアーキテクチャの決定

–クラスタ間通信方式の決定

12

Enterprise Edition 以上

まずは基本クラスタ構成を検討

ユニキャスト通信を選択


クラスタの構成クラスタの構成方法

13


構成の箇所を確認

• クラスタの設定 … WebLogic Server ドメインの設定

• プロキシの設定 … HTTP サーバーの設定

14

クラスタ

管理対象サーバー1 プロキシ

プラグイン

Dat

aSo

urc

e



Dat

aSo

urc

e


設定ファイル (HTTP サーバー)

$DOMAIN/config 設定ファイル (ドメイン)


プロキシ・プラグインの設定

1. プロキシ・プラグインの入手 – OHS 用プロキシ・プラグインは OHS インストールに含まれる

– Apache, iPlanet, IIS 用は Software Delivery Cloud や MOS からダウンロード

2. プロキシ・プラグインの設定

– HTTP サーバーにプロキシ・リクエストを設定 (右は Apache の例) • 構成できるパラメータは、対象の HTTP サーバーによって異なる

# Apache 2.2 用プロキシ・モジュール

LoadModule weblogic_module lib/mod_wl.so

# Apache 2.4 用プロキシ・モジュール

# LoadModule weblogic_module lib/mod_wl_24.so

<IfModule mod_weblogic.c>

WebLogicCluster localhost:7101,localhost:7103,localhost:7105

MatchExpression *

DebugConfigInfo ON

DynamicServerList ON

</IfModule>

<Location /weblogic>

WLSRequest On

PathTrim /weblogic

</Location>

15

httpd.conf

URL 文字列に「/weblogic」が含まれる場合 (転送先は<IfModule> の WebLogicCluster )

リクエストのプロキシ設定 MatchExpression に合致するリクエストを WebLogicCluster に転送

【Apache の構成例】


http://edlivery.oracle.com/

http://edlivery.oracle.com/

http://support.oracle.com/


主要なプラグイン・パラメータ

16

パラメータ説明デフォルト値

WebLogicCluster ロードバランシングに使用するサーバーのリスト(クラスタでは必須) なし

ConnectTimeoutSecs サーバーへの接続を試行する最大時間(秒)。経過すると 503 エラーを返す 10

ConnectRetrySecs クラスタ内のサーバーへの接続試行の間にスリープする間隔(秒) 2

PathTrim リクエストがクラスタに転送される前に元の {path} の先頭から取り除かれる文字列なし

PathPrepend PathTrimが取り除かれた後に元の {path} の先頭に付加される文字列なし

WLCookieName WebLogic Serverのセッションクッキー名。Webアプリケーションでクッキー名を

変更した場合 (weblogic.xml) に設定する JSESSIONID

WLIOTimeoutSecs サーバーへのリクエストの応答に対するプラグインのタイムアウト時間。

タイムアウトすると次のサーバーにフェイルオーバーする (Idempotent を参照)。 300

Idempotent WLIOTimeoutSecs で設定した時間内に応答がない場合にリクエストをフェイルオーバーする ON

DynamicServerList プロキシするサーバーのリストを動的に更新する。ON の場合は、新しいサーバークラスタに参加した場合に、サーバーをリストに自動的に追加する ON

Point:

プラグインのTCP接続の接続再試行回数 = ConnectTimeoutSecs / ConnectRetrySecs



Oracle HTTP Server の構成 - OHS の構成

• ドメイン作成時のテンプレートで Oracle HTTP Server を選択

17


• システムコンポーネントで OHS を構成

コンポーネント・タイプに [OHS] を選択

OHS の構成情報は、$DOMAIN/config/fmwconfig/components/OHS/{componentName} 配下に格納される


Oracle HTTP Server の構成 - プロキシの設定

• Fusion Middleware Control で [Oracle HTTP Server] – [mod_wl_ohs 構成]を選択

18


• [WebLogic クラスタ詳細の設定]を選択してクラスタを指定すると WebLogicCluster が設定される

1. 構成時は、編集セッション・ロックを取得して編集

2. 変更をアクティブ化したら OHS を再起動する


クラスタの作成 - 管理コンソール

19

必要に応じてユニキャスト用のネットワーク・チャネルを設定 (指定なしは、デフォルトチャネルを使用)

原則としてユニキャストを選択

クラスタ作成後に[構成]-[サーバー] タブでクラスタ・メンバーのサーバーを指定 (なければ新規作成)

クラスタの設定


クラスタの設定 Point:

クラスタでは JTA (トランザクション) やオーバーロード(過負荷保護) などドメインやサーバーの設定をクラスタ単位でも構成できる

(クラスタの設定が優先される)

20


EJB用のデフォルト負荷分散アルゴリズム → ラウンドロビン(*) | ランダム | 重みベース (サーバーアフィニティ使用可) weblogic-ejb-jar.xmlで上書き可 (パラメータベースルーティングの場合は必須)

EJBクライアントのスタブで使用する負荷分散・フェイルオーバのためのサーバリスト

プラグイン使用環境で、HttpServletRequest#getRemoteAddr()で HTTPサーバーではなくクライアントのアドレスを取得するための設定 (inherit = ドメイン設定と同じ)


クラスタの起動と停止

• 通常の管理対象サーバーの起動・停止方法と同じ

• NodeManager を構成している場合は、管理コンソール / WLST からも起動・停止可能

21

$ ./startManagedWebLogic.sh <server_name> <admin_server_url>

•クラスタメンバーの起動・停止 wls:/domain/serverConfig> start('ManagedServer1') wls:/domain/serverConfig> shutdown('ManagedServer1')

•クラスタ内の全サーバー起動・停止 wls:/domain/serverConfig> start('cluster1', 'Cluster') wls:/domain/serverConfig> shutdown('cluster1', 'Cluster')

停止は stopManagedWebLogic.sh 、または管理コンソールの[クラスタの設定] – [制御] – [起動と停止] からも制御可能

管理コンソールの[クラスタの設定] – [制御] – [起動と停止] からも制御可能



ドメインクラスタ

おさらい: 管理サーバーと管理対象サーバー

22

$DOMAIN/config

設定ファイル

マシン

管理サーバー

マシン


管理対象サーバー2 MBean

MBean

startWebLogic.sh

startManagedWebLogic.sh

設定変更

MBean 管理コンソール

監視・更新

監視・更新

起動

起動

設定を取得

管理サーバーは、起動時にドメインの設定ファイルを読み込んで起動

管理対象サーバーは、管理サーバーから設定を取得して起動 (クラスタ・メンバーの場合はクラスタとして起動)

startManagedWebLogic.sh 起動



• サーバー・テンプレートを基にサーバーを動的に構成してスケールアウト構成を容易に

– WLS12.2.1 からはオート・スケーリングにも対応

動的クラスタ

動的サーバー1

動的クラスタ

23


動的サーバー2

動的クラスタ

動的サーバー1


動的サーバー2

動的サーバー3 動的サーバー4

動的サーバー数: 2 動的サーバー数: 4


スケーリング

[スケーリングの方法] • コンソール • WLST • REST • ポリシーとアクション • カレンダー・ベース


動的クラスタの作成 - 管理コンソール

動的クラスタに含まれるサーバー数を指定

マシンやリスン・ポートの値は動的に割り当てられる値を使用可能 (マッチング式を使って制御可能)

24



動的に割り当てられる値

マシンマッチング式マシンの割り当て

M1, M2 - M1, M2, M1, M2, …

Ma1, Ma2, Mb1, Mb2 Ma1, Mb* Ma1, Mb1, Mb2, Ma1, Mb1, Mb2

25

ポートの種類テンプレート値動的サーバーへの割り当て

Listen 7100 7101, 7102, 7103, 7104, …

SSL 8100 8101, 8102, 8103, 8104, …


マシンの割り当て

ポートの割り当て


サーバー・テンプレートの設定

Point: Listen Address の設定例

• (なし) … 全てのアドレス

• 10.3.100.${id} … サーバーIDで割り振り

• ${serverName}.jp.oracle.com … サーバー名で割り振り

サーバー・テンプレートで使える参照用マクロ値

• ${id} … 動的サーバーのID (1から開始)

• ${serverName} … サーバー名

• ${clusterName} … クラスタ名

26



動的クラスタの作成 - 構成ウィザード

27


クラスタを追加 (テンプレートや動的サーバーを構成しなければ構成済みクラスタになる)

サーバー・テンプレートを作成してクラスタを指定

動的クラスタにチェックを入れる

• サーバー名の接頭辞を指定

• サーバー・テンプレートを選択

• 最大動的サーバー数を指定 (動的サーバー数も同じ値になる)


動的クラスタの設定

28

Point: 動的クラスタ・サイズを変更する場合

増やす → 動的サーバーが追加される ([サーバー名の接頭辞]+index)

減らす → 動的サーバーが削除される (動的サーバーの起動数よりも小さくできないので、index の大きいサーバーから停止しておく)

動的クラスタ・サイズ分だけ動的サーバーが構成される



動的クラスタのスケーリング

• WLST の場合

29

実行中のサーバーの必要な数を入力

(編集セッションが必要)


scaleUp / scaleDown ( clusterName, // 動的クラスタの名前 numServers, // 起動・停止するサーバーの数 [updateConfiguration], // クラスタの最大サイズを変更 (default: falase) [block], // WLSTコマンドをブロック (default: true) [timeoutSeconds], // タイムアウト秒数 // (default: 600 scaleUp / 300 scaleDown) [Type] // MBean の型 (値は DynamicCluster のみ) ) // 2 つのサーバーを追加するスケール・アップ操作例 wls:/myDomain/serverConfig> scaleUp('myCluster', 2, true, true)

Point: 動的クラスタのオート・スケーリングは診断フレームワーク (WLDF) のポリシーとアクションを使って構成可能


まとめ: クラスタの構成

• クラスタはドメインで設定

–初期設定は構成ウィザードや管理コンソールを使用する (WLSTも使用可)

–動的クラスタはサーバー構成が均一な場合に適用可能 • 動的サーバーはサーバー・テンプレートで設定を行う

• 手動または自動でスケーリングすることができる

–クラスタの起動・停止は通常の管理対象サーバの起動・停止と同じ

• プロキシ・プラグインはHTTPサーバーで設定

–リクエスト転送先になるサーバーを指定する

– HTTPサーバごとに設定項目が異なるので製品ドキュメントを確認 • OHS を使用する場合は構成がかなり楽

30


アプリケーションのクラスタ化セッション・レプリケーション

31


ドメインドメインクラスタ

おさらい: アプリケーションのデプロイメント

32

マシン

管理サーバー

マシン


webApp.war

webApp.war

設定変更

MBean

管理コンソール

webApp.war

デプロイメント・ソースファイル

dir

MBean

config.xml

設定ファイル

ステージング

1. ドメインにアプリケーションを登録 (インストール)

管理者ブラウザ

2. 対象のクラスタ(サーバー) でアプリケーションをアクセス可能にする (アクティブ化)

プロキシ

プラグイン


webApp.war MBean


クラスタへのアプリケーションのデプロイ

• アプリケーションをクラスタにデプロイする場合は、デプロイ対象にクラスタを指定する –分断された管理対象サーバーへのデプロイを避けるため全クラスタ・メンバーにアクセス可能な状態でデプロイメントを行うことを推奨

–『クラスタ制約を有効化』すると全クラスタメンバにアクセスできない状態でのデプロイを制限できる (デフォルトは OFF )

33


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

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

– WebLogic Server Plugin (HTTP サーバー)

–ロードバランサ

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

– デプロイメント記述子 (weblogic.xml) で設定

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

• Cookie

• File

• JDBC

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

34


HttpSession の永続化設定

35

• weblogic.xml の <persistent-store-type> で指定

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

– replicated_if_clustered を使用すると非クラスタ -> memory クラスタ -> replicated になる

Point: eclipse だと GUI ベースで設定可能


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

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

–セッション毎にプライマリ / セカンダリサーバーが決定される • リクエストはプラグインによってプライマリ・サーバーにルーティング

–サーバーにはプライマリ・セカンダリセッションが混在 • セカンダリ分だけヒープ消費量は増大

36

プロキシ

プラグイン

クラスタA


Web コンテナ


Web コンテナ


Web コンテナ

1 1

3 3

2 2


インメモリレプリケーション - 通常リクエスト

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

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

– セカンダリサーバーへの同期はHttpSession#setAttribute()がトリガ • 呼び出さないと同期されない

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

37

プロキシ

プラグイン

クラスタA


Web コンテナ


Web コンテナ


Web コンテナ

1 1

session.setAttribute()

1. セッション情報がないリクエストはサーバー・リストに対してラウンドロビン

P:server3, S:server2 2. セッション ID にプライマリ・セカンダリ情報が付加される

3. プライマリサーバーにルーティング


インメモリレプリケーション - フェイルオーバー

• プライマリサーバーに障害が発生するとセカンダリサーバーの情報をもとに別のサーバでセッションが再生成される

• プロキシプラグインによってリクエストは適切に振り替えられる

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

– プロキシプラグインはセッション ID のサーバーリストをもとに新プライマリ・サーバーに接続

38

プロキシ

プラグイン

クラスタA


Web コンテナ


Web コンテナ


Web コンテナ

1 1

3. 新しいサーバー・リストをセッション ID に格納

P:server3, S:server2

2. セッションIDから新しいサーバーに接続

1

1. プライマリサーバーで障害が発生すると別のサーバーでセッションを再作成

P:server1, S:server2


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

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

–クライアントからのリクエスト到達までにプライマリ/セカンダリサーバーが共にダウンするとセッションは継続できない • セッションの消失が許容できない場合はインメモリレプリケーションは選択不可

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

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

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

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

–

39


HttpSession#setAttribute()

40

Servlet API を使用する場合は HttpSession の属性を更新したら明示的に setAttribute メソッドを呼び出すようにする

JSF (と CDI ) を使う場合は、ServletFileter や PhaseListener を使って HttpSession を取得して setAttribute メソッドを呼び出す


クラスタのモニタリング

41

プライマリ・セッションとセカンダリ・セッション情報

ユニキャスト・ネットワーク情報 (ユニキャスト・ネットーワークはグループ・リーダーが他のグループと通信を行う)


クラスタA

マシン2 マシン1

インメモリレプリケーション - セカンダリはどこにできる？

• セカンダリセッションの作成先は別マシン上のサーバが優先される

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

–セカンダリセッションの作成先を複数のマシンでグループ化したい場合はレプリケーショングループを設定する (構成済みクラスタ)

42

プロキシ

プラグイン


Web コンテナ


Web コンテナ


Web コンテナ

1 1 1

マシンを設定しないとサーバー2 とサーバー3 はそれぞれ別のマシンにあるとみなされる


クラスタ1

レプリケーション・グループとマシン

43

マシンC マシンD

物理サーバーY



物理サーバーZ



マシンA マシンB





物理サーバーW 物理サーバーX

groupA

groupB

レプリケーション・グループ: groupB

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

ス・グループ: groupA

レプリケーション・グループ: groupA

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

ス・グループ: groupB

自分が所属するグループ(=セカンダリを作りたくない)

セカンダリを優先して作りたいグループ

Point:

レプリケーション・グループは各サーバーに設定する (動的クラスタの動的サーバーには設定不可)


まとめ: アプリケーションのクラスタ化

• クラスタにデプロイされるWebアプリケーションの高可用性を実現するにはHttpSessionの永続化設定を行う

– weblogic.xmlで指定する必要がある

–インメモリレプリケーションは2つのサーバーでセッションを保持 • セッションの消失が許容できない場合はJDBCを選択

–性能面ではJDBCはかなり不利

• インメモリレプリケーションの動作を考慮した実装が必要

–レプリケーションのトリガ(HttpSession#setAttribute())など • クラスタリングは Java EE 標準機能ではないのでアプリケーション・サーバーの特性を理解しておく必要がある

44


クラスタあれこれデータソースと JMS のクラスタ化

45


クラスタ構成時のデータソースの設定

• データソースをクラスタにデプロイする場合、データベースに対する接続数は「最大容量 x サーバー数」になる

46


クラスタ構成時の JMS サーバーの設定

• JMS サーバーの対象としてクラスタを指定可能 (12.1.2 〜)

–クラスタ・メンバーのサーバーにそれぞれ JMS サーバーがデプロイされる • JMS サーバーのリソース名は『JMSサーバー名@サーバー名』

–動的クラスタでも使用可能 • スケーリングする場合にJMS リソースも作成される

47


クラスタ構成時の JMS モジュールの設定

• 分散宛先

–物理宛先をまとめる仮想的な宛先 • アプリケーションは、物理宛先ではなく分散宛先を lookup する

• どの物理宛先にアクセスするかは、プロデューサとコンシューマで異なる

–プロデューサ (送信クライアント) … メッセージ送信時に物理宛先を決定

• 分散宛先内の複数の物理宛先にメッセージを送信する

–コンシューマ (受信クライアント) … Consumer オブジェクト生成時に受信する物理宛先を決定

• 分散宛先内の特定の物理宛先のメッセージを受信する

48

X

Y

分散キューA

キューX

キューY

アプリケーション A


分散宛先の作成

49

宛先タイプ: 共通の場合、分散宛先の対象はクラスタを指定可能 (サブデプロイメント不要) (物理宛先は自動作成。リソース名は『JMSモジュール名!JMSサーバー名＠宛先名』)


ServerX

EJBコンテナ JMSサーバーA

キューX

ServerY

クラスタ1

分散宛先を使用した JMS メッセージング

50

JMSサーバーB

キューY

アプリケーション A

lookup( "分散キューA" )

send (message )

アプリケーション B (MDB)

EJBコンテナ

アプリケーション B (MDB)

分散キューA

Point: 分散宛先も JNDI ツリーにバインドされる

Point: コンシューマは生成時に参照する物理宛先を決定

Point: プロデューサはメッセージ送信時にアクセスする物理宛先を決定


分散宛先を使用する JMS アプリケーション

51

Point:

アプリケーションがルックアップしている JNDI で分散宛先を構成していればプログラムの修正は不要。

[Producer (送信)] 注釈で指定された接続ファクトリと宛先 (分散宛先) をルックアップする

[Consumer (受信)] Message Driven Bean として実装。ルックアップする宛先 (分散宛先) は注釈で指定する


まとめ: クラスタあれこれ

• データソースはクラスタにデプロイ可能

–データベースに対する接続数は、最大容量 x サーバー数になる

• JMS もクラスタにデプロイ可能

– JMS サーバーや JMS モジュールをクラスタメンバーに均一に配備する場合は、デプロイ対象をクラスタにする • 動的クラスタでスケーリングした場合にも配備される

–宛先は分散宛先を使用する

52


オラクルユニバーシティからのお知らせ

53


オラクルユニバーシティからのお知らせ

• WebLogic Serverの管理方法やトラブルシューティング・パフォーマンスチューニングの手法を体系的に学習したい方に最適な研修コースをご提供しています。

– Classroomトレーニングだけでなく、Live Virtual Classや『Oracle トレーニング・オンデマンド』など多様な受講形態から選択いただけます。

54


コース内容

WebLogic Server概要

WebLogic Serverのインストールとパッチ適用

ドメインの作成

サーバーの起動

管理コンソールの使用

JDBCの構成

ドメインの監視

ノード・マネージャ

アプリケーションのデプロイネットワーク・チャネルおよび仮想ホストクラスタ: 概要、作成および構成クラスタ: プロキシおよびセッションクラスタ: 通信、計画およびトラブルシューティングトランザクション WebLogic Serverセキュリティドメインのバックアップと WebLogic Server のアップグレード

受講前提条件・Linux の基本的な操作方法の理解・Java EE の基礎知識（サーブレットや JSP など） ※推奨

対象者・Oracle WebLogic Server 12c 管理者

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

・アーキテクト

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

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

お待たせしました！WebLogic Server 12c (12.2) 対応研修開講です。

Oracle WebLogic Server 12c の運用管理スキルをしっかり習得このコースでは、Oracle WebLogic Server 12cのアーキテクチャや背景となる技術を理解するとともに、Oracle WebLogic Server 12cの構成お

よび運用管理タスクを体系的に学習します。コースでは管理コンソールやコマンドラインツール（WLST）などを使用してドメインを構成

する方法やJava EEアプリケーションをサーバーにデプロイする方法についても説明します。さらに、Oracle WebLogic Server のプロキシと

してOracle HTTP Serverを構成し、WebLogic Serverクラスタによるアプリケーションのフェイルオーバーとロードバランシングをサポート

する方法など、環境構築に必要なスキルとWebLogic Serverのモニタリングやログ情報の収集など運用に必要なスキルを実機演習を通して

習得できます。(Oracle WebLogic Server 12.2 対応)

Oracle WebLogic Server 12c：管理 I Ed 2 ミドルウェア

開催日程 ■ 2017年 7月 10日 (月) 〜 14日 (金)

55

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




コース内容

マルチテナンシの概要

ドメイン・パーティション

リソース・グループ

Web Tierテナント

データベース・テナント Coherenceテナントサービス品質

受講前提条件・Oracle WebLogic Server 12c: 管理 I 受講相当の知識・Linux の基本的な操作方法の理解

対象者・Oracle WebLogic Server 管理者

・サポートエンジニア

・アーキテクト

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

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

マルチテナントが Oracle WebLogic Server でも使用可能に！注目の新機能をじっくり身につけることができます。

このコースでは、Oracle WebLogic Server 12.2.1 の管理、監視、デプロイメントと新しいマルチテナンシの機能、および Oracle Traffic Director や Oracle Coherence との統合の詳細などについて学習します。Oracle Fusion Middleware 12c マルチテナンシ機能による、高密度集約、効率性、アプリケーションの分離、プラガブルなアプリケーション・パッケージ方法、拡張された自動化機能について学習することができます。

Oracle Fusion Middleware 12c：マルチテナンシ管理ミドルウェア

開催日程 ■ 2017年 4月 20日 (木) 〜 21日 (金)

56




Copyright © 2017 Oracle and/or its affiliates. All rights reserved. | 57

• 一回目で合格できなくてももう一度挑戦できる！

•オラクル認定資格再受験無料キャンペーン

• 期間: 2016年12月2日〜 2017年5月31日

• プロモーションコード:

RETAKE17JP

• キャンペーンの詳細はピアソン VUE の Web サイトまで。

キャンペーン。やってます。

https://www.pearsonvue.co.jp/Clients/Oracle/Special-Offers/Retake2017.aspx







oracle weblogic server クラスタ

Technology