Oracle WebLogic Server 12c管理のための５つのポイント

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

Oracle WebLogic Server 12c 管理のための 5 つのポイント第53回 WebLogic Server 勉強会

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


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

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

2


本日お話すること

WebLogic Server を起動する準備

WebLogic Server の設定と監視方法

アプリケーションを使えるようにする

データベース接続を設定する

クラスタ機能を使う

3

1

2

3

4

5


ポイント其の壱

WebLogic Server を起動する準備ドメインの作成〜サーバーの起動まで

4


はじめに … WebLogic Server のインストールの注意点

5

インベントリ・ディレクトリの指定画面が表示された場合はディレクトリを指定

インストール・プログラムの起動 $ java -jar fmw_12.1.3.0.0_wls.jar

[レスポンス・ファイルの保存] を選択するとサイレント・インストール用の応答ファイルを作成可能

TIPS: クイックスタート構成ウィザードサンプルドメイン用のドメイン構成ウィザード。インストール後でも起動可能 $ export QS_TEMPLATES=$WL_HOME/common/templates/wls/wls_examples.jar $ ./qs_config.sh


ドメインとは？ WebLogic Server の管理単位

• WebLogic Server ドメイン

–サーバーやクラスタ、データ・ソースなどリソース管理の単位 • サーバー: WebLogic Server インスタンス (Java プロセス)

–管理サーバー … ドメインの設定を管理するサーバー。ドメインに必ず 1 つ

–管理対象サーバー … アプリケーションやサービスをホストするサーバー。管理サーバーから設定を取得して起動

• マシン: H/W 境界 (ノード・マネージャを使用する場合は必須)

• クラスタ: サーバーの論理的なグループ (アプリケーションやサービスに可用性と拡張性を提供)

6


ドメイン

マシン

マシン

クラスタ

ドメインとリソース

7

トランザクション

管理サーバー

管理対象サーバー



セキュリティ

アプリケーション

データソース

診断モジュール

JMSモ

ジュール

サーバー・テンプレート

JMSサ

ーバー

ログ‘ etc

ログ etc

ログ etc

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

ノード・マネージャ

config

設定ファイル


ドメイン

マシンA マシンB

ドメイン構成の例

• 単一サーバー・ドメイン • 複数サーバー・ドメイン

8

ドメイン

管理サーバー

app

物理サーバー

物理サーバー

ドメインA

管理サーバー

app1

ドメインB

管理サーバー

app2

ドメイン

物理サーバー

管理サーバー管理対象サーバー

app

物理サーバーX

管理サーバー管理対象サーバー

物理サーバーY



app

開発環境向け

本番環境向け


ドメインを作成する方法

• ドメイン構成ウィザード

–作成されるもの • ドメイン・コンフィグレーション

• 起動スクリプト

• 管理者ユーザー

• 起動 ID ファイル (開発モード)

9

$ $WL_HOME/common/bin/config.sh

TIPS: ドメイン名は [ドメインの場所] で指定するパスで指定する /u01/user_projects/domains/domain1

ドメイン名


ドメイン作成のポイント (1)

10

製品テンプレートを選択 Java EE アプリケーションをホストするドメインの場合は [Basic WebLogic Server Domain] でOK

ドメインの起動モードは、本番用ドメインでは原則として [本番モード] を指定

JDK が複数イントールされている場合は、[その他の JDK の場所] に $JAVA_HOME のパスを指定

TIPS: [拡張構成] を選択しないと管理サーバーのみのドメインが作成されるサーバー名: AdminServer リスニング・アドレス: All Local Addresses リスニング・ポート: 7001


ドメイン作成のポイント (2)

11

ドメイン構成ウィザードで定義できるクラスタは、構成済みクラスタのみ。動的クラスタ(12.1.2 〜 )を作成する場合は、ドメイン作成後に設定する

ノード・マネージャを使用する場合は、[ノード・マネージャ資格証明] を設定しておく (nmConnectコマンドでノード・マネージャに接続する際の資格情報)

ドメインの場所と管理サーバーの URL を確認


ドメイン・ディレクトリ

ディレクトリ説明

domain_name ドメイン・ティレクトリ (ディレクトリ名 = ドメイン名)

autodeploy 自動デプロイメントディレクトリ (開発モード用)

bin 起動・停止スクリプト etc • 管理サーバー: startWebLogic.sh / stopWebLogic.sh • 管理対象サーバー: startManagedWebLogic.sh / stopManagedWebLogic.sh

config ドメイン構成ディレクトリ (config.xml が配置される)

init-info ドメインの初期化情報

nodemanager ノード・マネージャ・ホームディレクトリ

pending 編集中のドメイン構成ファイルの保存先

security セキュリティ・ファイル ( *.ldift, SerializedSystemIni.dat)

servers

server_name サーバー・ディレクトリ (ディレクトリ名 = サーバー名)

12


ドメイン

管理サーバーと管理対象サーバー

13

$DOMAIN/config

設定ファイル

マシン

管理サーバー

マシン


管理対象サーバー MBean

MBean

startWebLogic.sh

startManagedWebLogic.sh

設定変更

MBean 管理コンソール

監視・更新

監視・更新

起動

起動

設定を取得

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

管理対象サーバーは、管理サーバーから設定を取得して起動

startManagedWebLogic.sh 起動


管理サーバーと管理対象サーバーの起動方法

• サーバーの起動スクリプトはドメイン作成時に生成される

–管理サーバーの起動

–管理対象サーバーの起動

14

$WL_HOME/bin

commEnv.sh

$DOMAIN/config

setDomainEnv.sh

startManagedWebLogic.sh

startWebLogic.sh

$ ./startWebLogic.sh

$ ./startManagedWebLogic.sh <server_name> <admin_url> server_name … 起動する管理対象サーバー名 admin_url … 管理サーバーのURL (ホスト名, ポート番号) call

call

call

インストール共通の環境設定スクリプト

ドメイン共通の環境設定スクリプト

管理対象サーバー起動スクリプト

管理サーバー起動スクリプト


ポイント其の弐

WebLogic Server の設定と監視管理コンソールの使い方

15


ドメインを設定するには • ドメインは管理コン

ソールを使用して設定できる http://<hostname>:<port>/console

• 管理コンソールは管理サーバーにデプロイされる管理用 Web アプリケーション

16

TIPS: 管理コンソールは自動でデプロイされるので明示的なデプロイは不要


管理コンソールのレイアウトチェンジ・センター

ドメインの設定変更のための編集ロックを制御するためパネル

ドメイン構造

ドメインの設定項目がツリー構造で表示されているパネル。編集作業は右側の編集パネルで行う

プリファレンス

インライン・ヘルプの表示などユーザ毎に表示設定を行う

17


チェンジ・センタードメインの設定変更を行う仕組み

18

TIPS:

チェンジ・センターのロック機構は、ユーザー・アカウント単位 → 作業者毎に個別のアカウントを作成する

ロック状態はアクティブ化(暗黙解放)、もしくは明示的に解放しなければ持続する → 別のユーザーによるロック状態を解放するには WLST で行う (要 Admin ロール)

変更保存

ロック取得

ロック解放

アクティブ化

変更破棄

Admin ロールのユーザーは複数作成しておく


サーバーの停止

• サーバーの停止

–管理コンソール • [サーバー] – [制御] から

–停止スクリプト ($DOMAIN/bin) • 管理サーバーの停止

• 管理対象サーバーの停止

19

$ ./stopWebLogic.sh

$ ./stopManagedWebLogic.sh <server_name> <server_url> server_name … 停止する管理対象サーバー名 server_url … 管理対象サーバーのURL (ホスト名, ポート番号)

TIPS: 管理コンソールからサーバーの起動を行うには、ノードマネージャ (とマシン) を設定する必要がある


管理コンソールでの監視

20

各リソースの [監視] タブを使用するとリソースの使用状況をモニタできる

[この表のカスタマイズ] を選択して表示する属性をカスタマイズできる


モニタする属性 (1)

リソース (MBean) 属性

ServerRuntime [ドメイン] – [監視] - [サーバー]

OpenSocketsCurrentCount 現在のオープン・ソケット数

JVMRuntime [サーバー] – [監視] – [パフォーマンス]

HeapFreeCurrent 現在の空きヒープ

HeapSizeCurrent 現在のヒープ・サイズ

ThreadPoolRuntime [サーバー] – [監視] – [スレッド]

ExecuteThreadTotalCount 実行スレッド総数

ExecuteThreadIdleCount アイドル中の実行スレッド数

StandbyThreadCount スタンバイ中のスレッド数

PendingUserRequestCounts 保留中のユーザー・リクエストの数

アクティブなスレッド数は以下で算出 ExcecuteTreadTotalCount – ExecuteThreadIdleCount – StandbyThreadCount (管理コンソールでは [アクティブな実行スレッド] として表示される)

21


モニタする属性 (2)

リソース (MBean) 属性

JDBCDataSourceRuntime [データソース] – [監視] – [統計]

CurrCapacity 現在の容量

ActiveConnectionsCurrentCount 現在アクティブな接続数

WaitingForConnectionCurrentCount 接続待機の現在数

WebAppComponentRuntime [アプリケーション] – [監視] – [Webアプリケーション]

OpenSessionsCurrentCount セッション

StatelessEJBRuntime [アプリーケーション] – [EJB] – [監視] – [ステートレスEJB]

PooledBeansCurrentCount 現在のプール済みBean数

BeansInUseCurrentCount 使用中Bean数

WaiterCurrentCount 現在の待機数

必要に応じて xxxHighCount も取得 ActiveConnectionsHighCount (アクティブな接続の最大数) WaitingForConnectionHighCount (接続待機の最大数)

22


WebLogic Server のログファイル

• サーバー・ログ

– WebLogic Server上で動作するアプリケーションやサービス(サブシステム)の情報を記録するログ。各サーバが出力

– $DOMAIN/servers/<サーバ名>/logs/<サーバ名>.log

• HTTP ログ

–サーバが処理したHTTPリクエストのログ(アクセスログ)。各サーバが出力

– $DOMAIN/servers/<サーバ名>/logs/access.log

• ドメインログ

–サーバログを特定のフィルタ条件で集約したもの。管理サーバのみが出力

– $DOMAIN/servers/<管理サーバ>/logs/<ドメイン名>.log

23


ドメイン

サーバー・ログとドメイン・ログ

24

$DOMAIN/config

設定ファイル

マシン

管理サーバー

マシン


管理対象サーバー MBean

MBean

server.log

domain.log

server.log

server.log

設定変更

MBean 管理コンソール

監視・更新

監視・更新

サーバー・ログ


ドメイン・ログ転送

ドメイン・ログ

ドメイン・ログを出力するのは管理サーバーのみ

ドメイン・ログ転送


サーバー・ログは各サーバーが動作しているマシンに出力される


ポイント其の参

アプリケーションを使えるようにするアプリケーションのデプロイ方法

25


ドメイン

アプリケーションのデプロイメント

26

マシン

管理サーバー

マシン


webApp.war

prodMgmt.war

設定変更

MBean

管理コンソール

prodMgmt.war

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

dir

MBean

config.xml

設定ファイル

ステージング

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

管理者ブラウザ

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


アプリケーションのデプロイ (1)

27

チェンジ・センターのロックを取得してから [インストール]

TIPS: デプロイメント・ソースファイルは管理サーバーがアクセスできる場所に配置しておく



28

クライアントがアクセスするアプリケーションは、[アプリケーションとしてインストール]を選択



29

TIPS: ソースのアクセス可能性 = ステージングデプロイ対象へのアプリケーション・ファイルのコピー • stage: 管理サーバーからデプロイ対象にファイルをコピー • nostage: デプロイ対象にファイルをコピーしない

[終了] 後にチェンジ・センターの [変更のアクティブ化] を忘れずに


アプリケーションの起動

30

「準備完了」状態ではクライアントからはアクセスできないため、アプリケーションを起動する TIPS: チェンジ・センターのロックは不要状態が「アクティブ」に

なっていることを確認


管理コンソールでのデプロイメントの制御

• デプロイメントの制御

–アプリケーションの更新 (再デプロイ) 1. [更新] を選択

–アプリケーションの削除 (アンデプロイ) 1. [停止] を選択してアプリケーションを

「準備完了」状態にする

2. [削除] を選択

31

TIPS: コンソール・デプロイメントでの新規デプロイとアンデプロイは、必ず2 段階デプロイメントになる


参考: コマンドライン・デプロイメント

準備完了

アクティブ

①

② ③

④

⑥ ⑤

WLST weblogic.Deployer

① distributeApplication() -distribute

② startApplication() -start

③ stopApplication() -stop

④ undeploy() -undeploy

⑤ deploy() -deploy

⑥ undeploy() -undeploy

⑦ redeploy() -redeploy

⑦

コマンドライン・デプロイメントは WLST または weblogic.Deployer で実行可能

* コマンドは管理サーバーに対して実行

デプロイなし

管理モードでの起動には管理ポートを有効化する必要がある (主にプロダクション再デプロイメント用)

管理

③ ②

② ③

32


プロダクション再デプロイメントバージョニングによる再デプロイメント

• WebLogic Serverではアプリケーションをバージョニング可能

–保持できるバージョンは2つまで

• プロダクション再デプロイメントでは新しいバージョンと古いバージョンを並行してデプロイする

–既存のクライアント・リクエストは古いバージョンへ

–新しいクライアント・リクエストは新しいバージョンへ

プロダクション再デプロイメントの利点サービスを中断しないアプリケーション更新をサーバ単体で実現可能

33


アプリケーションのバージョンの指定方法

• プロダクション再デプロイメントを行うアプリケーションには必ずバージョンを指定する

a. MANIFEST.MF ファイルに Weblogic-Application-Version を指定

b. weblogic.Deployer で –appversion オプションで指定 • WLSTではdeployコマンドの versionIdentifier 属性で指定

TIPS: バージョン識別子は文字列で指定使用可能な文字: 英数字, 他の文字と組み合わせた「.」,「_」,「-」

34


ポイント其の四

データベース接続を設定する JDBC データソースの設定方法

35


データソースとは？ Java EE におけるデータベースアクセス

36

WebLogic Server

@Resource(name = "jdbc/test") DataSource ds; try (Connection conn = ds.getConnection(); PreparedStatement pstmt = conn.prepareStatement(QUERY)) { pstmt.setString(1, "WebLogic"); ResultSet rs = pstmt.executeQuery(); while(rs.next()) { // .... } } catch (SQLException e) { // 例外処理 }

Dat

aSo

urc

e

JNDIツリー

デプロイ時にバインド

接続・SQL 実行

JDB

C

JNDI ルックアップ

データベース

DB 接続オブジェクトを効率利用するために接続プールを使用

アプリケーションは接続オブジェクトをデータ・ソースを介して取得


データ・ソース作成のポイント (1)

37

JNDI 名は、アプリケーションがデータ・ソースのルックアップに使用する名前を指定 JPA の場合は、persistence.xml で指定する <jta-data-souce> 要素の値

データ・ソースを作成するには、チェンジ・センターで [ロックして編集] を選択通常のデータ・ソースを作成する場合は、 [新規] – [汎用データ・ソース] を選択する


TIPS: テスト表の設定

データ・ソース作成のポイント (2)

38

非XA ドライバ (Type 4) を選択した場合は、トランザクション・オプションを設定

データベース接続可能な場合は、 [接続のテスト] を実行可能

Oracle Database を使用する場合は、 SQL ISVALID を使用可能 (12.1.3 〜)


データソースの設定

• 容量の設定 – 容量: 接続プール内の物理接続(DB接続)数

– 初期容量: 接続プール作成時の物理接続数。初期容量分作成できないとデプロイ失敗

– 最大容量: 接続プールの最大物理接続数

– 最小容量: 縮小時の最小物理接続数

39

TIPS: 原則として『初期容量 = 最大容量』と考えて良い。 (初期容量 < 最大容量の場合は、[縮小頻度] の設定を検討) 最大容量は、接続待機を発生させないことを考慮すると「最大容量 < 実行スレッド数」の範囲で設定


GridLink データソースの機能 Active GridLink for RAC

• 構成容易性の向上

– Single Client Access Name(SCAN) 対応

• 可用性の向上

– RACからの通知による高速接続フェールオーバー(FCF)

• 性能の向上

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

– XAトランザクション・アフィニティ

– Webセッション・アフィニティ(WLS12.1.1〜)

40


GridLink データソースの機能

WebLogic Server

GridLink データソース

80% 20% Oracle RAC

ONS Client

ON

S Daem

on

ON

S D

aem

on

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

• アフィニティ (XAトランザクション/ Webセッション)

WebLogic Server


Oracle RAC

ONS Client

ON

S Daem

on

ON

S D

aem

on

XA / Session

• 高速接続フェイルオーバー(FCF)

WebLogic Server


Oracle RAC

ONS Client

ON

S Daem

on

ON

S D

aem

on

41


ポイント其の伍

クラスタ機能を使うクラスタの構成方法

42


WebLogic Server クラスタ

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

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

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

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

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

– JDBCデータソース

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

– JNDI (JNDIツリーの同期)

43


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

• ライセンスの確認

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

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

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

–プロキシ

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

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

44


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

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

–呼び出しの最適化

45

クラスタ

管理対象サーバー1

プロキシ

プラグイン

Dat

aSo

urc

e

Web コンテナ EJB コンテナ


Dat

aSo

urc

e

Web コンテナ EJB コンテナ

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

HTTPリクスエトを負荷分散


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

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

–可用性の向上

46

クラスタA


プロキシ

プラグイン

Web コンテナ


Web コンテナ

HTTPリクスエトを負荷分散

クラスタB


Dat

aSo

urc

e

EJB コンテナ


Dat

aSo

urc

e

EJB コンテナ

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


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

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

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

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

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

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

– WebLogic ドメインでは設定できない

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

プロキシ

プラグイン

47


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

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

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

– JNDIツリーの同期

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

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

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

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

48


クラスタ作成のポイント

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

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

クラスタ作成後に[サーバー]タブでクラスタ・メンバーのサーバーを指定

49


クラスタの起動

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

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

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

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

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

50


動的クラスタ

Generated Server1

動的クラスタ WebLogic Server 12.1.2 の新機能

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


Generated Server2

動的クラスタ

Generated Server1


Generated Server2

Generated Server1

Generated Server2

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

51


動的クラスタ作成のポイント

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

マシンやリスン・ポートの値は動的に割り当てられる値を使用可能

52


動的に割り当てられる値

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

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

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

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

Listen 7100 7101, 7102, 7103, 7104, …

SSL 8100 8101, 8102, 8103, 8104, …

53


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

TIPS: Listen Address の設定例

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

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

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

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

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

• ${serverName} … サーバー名

• ${clusterName} … クラスタ名

54


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

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

– WebLogic Server Plugin (HTTP サーバー)

–ロードバランサ

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

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

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

• Cookie

• File

• JDBC

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

55


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

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

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

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

56

プロキシ

プラグイン

クラスタA


Web コンテナ


Web コンテナ


Web コンテナ

1 1

3 3

2 2


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

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

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

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

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

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

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

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

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

57


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

58


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

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

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

59


コース内容

■Oracle WebLogic Server概要

■ドメインの作成

■Administration Console

■ドメインのモニタリング ■アプリケーションのデプロイメント

■WebLogic Server セキュリティ ■ドメインのバックアップおよびリカバリ

■WebLogic Serverのインストールおよびパッチ適用

■サーバーの起動および停止

■JDBCデータソースの構成

■ノードマネージャ ■WebLogic Serverクラスタリング

■トランザクション・サービスのコンフィグレーション

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

対象者・Oracle WebLogic Server 管理者

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

・アーキテクト

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

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

Oracle WebLogic Server 12c の運用管理スキルをしっかり習得待望のWebLogic Server 12c(12.1.2)対応研修は絶賛提供中です。

このコースでは、アプリケーション・サーバー管理者がOracle WebLogic Server 12cのインストールおよび設定方法を習得することができま

す。管理コンソールやコマンドラインツール（WLST）などを使用してドメインを構成する方法やJava EEアプリケーションをサーバーにデ

プロイする方法についても説明します。さらに、Oracle WebLogic Server のプロキシとしてOracle HTTP Serverを設定し、WebLogic Serverク

ラスタによるアプリケーションのフェイルオーバーとロードバランシングをサポートする方法など、環境構築に必要なスキルとWebLogic

Serverのモニタリングやログ情報の収集など運用に必要なスキルを実機演習を通して習得できます。さらに、Oracle WebLogic Server 12cで

強化されたActive GridLink for RACの構成方法やWebLogic Server 12.1.2の新機能である動的クラスタなど注目の新機能もカバーします。

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

開催日程 ■ 2015年 3月 12日 (月) 〜 21日 (金)

60

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




コース内容

■トラブルシューティング: 概要

■WebLogic Server 診断フレームワーク: 概要

■診断インストゥルメンテーション

■JVM のトラブルシューティング

■サーバーのトラブルシューティング

■アプリケーションのトラブルシューティング

■JDBC のトラブルシューティング

■ノード・マネージャのトラブルシューティング

■クラスタのトラブルシューティング

■セキュリティのトラブルシューティング

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

対象者・Oracle WebLogic Server 管理者

・サポートエンジニア

・アーキテクト

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

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

アプリケーション・サーバー運用時に発生するトラブルのパターンと対処方法を知る

このコースでは、JVM、WebLogic Server、Java EE アプリケーションのデプロイメント、データソース、ノード・マネージャ、クラスタ

およびセキュリティなどWebLogic Serverの運用に不可欠な各機能について、よく発生する問題のトラブルシューティング手法について

説明します。WebLogic Server管理コンソール、モニタリング・ダッシュボード、WebLogic診断フレームワーク、およびJava Flight

Recorderなど、トラブルシューティングを支援する各種ツールを活用した問題の切り分けやデバッグ方法、およびその対処方法について

実践的な演習を通して学習することができます。

Oracle WebLogic Server 12c：トラブルシューティングミドルウェア

開催日程 ■ 2015年 3月 9日 (月) 〜 13日 (金)

61




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

Technology

Oracle WebLogic Server 12c管理のための５つのポイント