• Share
  • Email
  • Embed
  • Like
  • Private Content
 トラブルに強いWebLogic Serverの設計と構築 - 第20回 WebLogic Server勉強会資料
 

トラブルに強いWebLogic Serverの設計と構築 - 第20回 WebLogic Server勉強会資料

on

  • 12,713 views

WebLogic Server勉強会資料 - トラブルに強いWebLogic Serverの設計と構築 ...

WebLogic Server勉強会資料 - トラブルに強いWebLogic Serverの設計と構築
伊藤忠テクノソリューションズ株式会社
ソフトウェアサービス本部 ミドルウェアサービス部
山田 貴裕
2012/1/31

■目的
トラブルを未然に防ぐ
トラブルに迅速に対処する

■対象
WLSのインフラ設計・構築担当者
WLSの運用管理者
(WLSの開発担当者)

■環境
WLS9.x以降
Unix系OS(Solaris, Linux)中心
Windowsでもほぼ適用可能

■アジェンダ
ログ管理
OS環境設定
セキュリティ
ネットワーク
起動・停止スクリプト
監視/統計

Statistics

Views

Total Views
12,713
Views on SlideShare
12,275
Embed Views
438

Actions

Likes
5
Downloads
132
Comments
0

7 Embeds 438

http://d.hatena.ne.jp 246
http://blogs.oracle.com 126
http://192.168.30.250 24
https://twitter.com 22
http://a0.twimg.com 15
http://hatena-anohito.appspot.com 4
http://webcache.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

     トラブルに強いWebLogic Serverの設計と構築 - 第20回 WebLogic Server勉強会資料 トラブルに強いWebLogic Serverの設計と構築 - 第20回 WebLogic Server勉強会資料 Presentation Transcript

    • 第20回 WebLogic Server勉強会@東京トラブルに強いWebLogic Serverの設計と構築 ソフトウェアサービス本部 ミドルウェアサービス部 山田 貴裕 2012/1/31 Copyright (c)2011 ITOCHU Techno-Solutions Corporation
    • 自己紹介 • 自己紹介 – 山田 貴裕 (Twitter: @yamadamn) – 伊藤忠テクノソリューションズ株式会社(CTC) • ソフトウェアサービス本部 ミドルウェアサービス部 所属 – Java EE開発者やDBAを経て、ミドルウェアのサポートエンジニアに • Oracle Fusion Middleware が主担当 – WebLogic Server, Coherence など • 大規模案件にも従事し、設計や構築を担当 –W-1チャンピオン • 2011/12/7 「第2回W-1選手権 WebLogic Serverクイズ王決定戦」にて Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • おことわり • 発表する内容は個人の見解であり、所属する組織の公式 見解ではありません。 • 個人の(限られた)経験に基づくものですので、様々な環境 に適したものではありません。 • 設計や構築に必要な内容を、体系的・網羅的に説明する ものではありません。 – 運用時に落とし穴になりがちな設計・構築のポイントを部分的に 説明するものです。 – 一般的な非機能要件(性能・可用性・拡張性など)の内容は原則 として含みません。 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • [宣伝] WebLogic Serverを体系的に学習するには? • Oracle WebLogic Server 11g構築・運用ガイド – 絶賛発売中!! – WebLogic Server勉強会でも、じゃんけん大会などで配布 11g 9.x/10 8.1 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 目的と対象 • 目的 – トラブルを未然に防ぐ – トラブルに迅速に対処する • 対象 – WLSのインフラ設計・構築担当者 – WLSの運用管理者 – (WLSの開発担当者) • 環境 – WLS9.x以降 – Unix系OS(Solaris, Linux)中心 • Windowsでもほぼ適用可能 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • アジェンダ • ログ管理 • OS環境設定 • セキュリティ • ネットワーク • 起動・停止スクリプト • 監視/統計 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • ログ管理 よく利用するログファイル 種類 利用目的 取得有無 説明 (デフォルト) サーバーログ 運用監視 ○ 各インスタンスの詳細情報を記録する 障害解析 HTTPアクセスログ 稼働評価 ○ HTTPアクセスの情報を記録する 障害解析 コンソールログ 運用監視 × 標準出力・エラーの情報を記録する以外 障害解析 に、インスタンスの重要度が高い情報を 記録する ドメインログ 障害解析 ○ ドメイン内全インスタンスの重要度が高い (管理サーバー) 情報を記録する GCログ 稼働評価 × JVMのGC情報を記録する 障害解析 クラッシュログ 障害解析 △ JVMクラッシュ時に出力される (クラッシュ時) Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • ログ管理 • HTTPアクセスログ – バッファリングされ、ある程度アクセスされないと出力されない • 開発環境では、バッファリングを無効化しておくと便利 • 特定リリース以降であれば、バッファサイズを設定可能(詳細はサポートに…) – 管理コンソールへのアクセスは出力されない • 特定リリース以降であれば、出力するよう設定可能(詳細はサポートに…) – 拡張フォーマットの利用 フィールド識別子を利用して設定する ※カスタムクラスで、ユーザ定義のフィールドを出力することも可能 • c-ip: クライアントのIPアドレス – 「WebLogicプラグインの有効化」を設定することも検討 • date, time: レスポンスを返した日時 – 通常の共通ログフォーマットでは、リクエストを受け取った日時 • bytes: レスポンスのバイト数 • time-taken: 所要時間(ミリ秒) Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • ログ管理 • HTTPアクセスログの詳細設定 – [環境]→[サーバー]→<サーバー名>→ロギング→HTTP→詳細 : Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • ログ管理 • コンソールログ – スレッドダンプ出力やOOME分析のためにはあった方がよい • スレッドダンプに関しては、環境によってはjstack(HotSpot), jrcmd(JRockit)などでも代替できる – 後述する監視目的で取得するのも有用 – 環境変数WLS_REDIRECT_LOGで出力するログを設定可能 • デフォルトでは上書き(>"${WLS_REDIRECT_LOG}" 2>&1) • 別の方法で標準出力・エラー出力をリダイレクトさせておいてもよい (startWebLogic.sh 抜粋) if [ "${WLS_REDIRECT_LOG}" = "" ] ; then : ${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ~ ${SERVER_CLASS} else echo "Redirecting output from WLS window to ${WLS_REDIRECT_LOG}" ${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ~ ${SERVER_CLASS} >"${WLS_REDIRECT_LOG}" 2>&1 fi Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • ログ管理 • GCログ – GC頻度やメモリリーク傾向などを分析するためには必要 • 環境によっては、jstat などでも代替できる – 後述する統計目的で取得するのも有用 HotSpot でよく利用するGCログ用オプション オプション 説明 -verbose:gc GC情報を出力(基本) -Xloggc:<file> GC情報を指定されたファイルに出力 -XX:+PrintGCTimeStamps タイムスタンプ(Java起動からの経過時間)を出力 -XX:+PrintGCDetails GCの詳細情報を出力 JRockit でよく利用するGCログ用オプション オプション 説明 -verbose:gc -Xverbose:memoryや-Xverbose:gcでも同じ -XverboseLog:<file> GC情報を指定されたファイルに出力 -XverboseTimeStamp タイムスタンプ(日時)を出力 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • ログ管理 • コンソールログやGCログのローテーションはどうする? A) ローテーションしないが、上書きに配慮する • WLS_REDIRECT_LOG="servers/${SERVER_NAME}/logs/ console.log.`date +%Y%m%d%H%M%S`" • -Xloggc:${LOG_DIR}/gc-${SERVER_NAME}-`date +%Y%m%d%H%M%S`.log B) OS標準の機能により強制的にローテーションさせる ※ログ欠落に注意、またOS環境によっては正常にローテーションできない • cp -p "${CURRENT_LOG}" "${BACKUP_LOG}" cat /dev/null >"${CURRENT_LOG}" • logrotate(Linux)やlogadm(Solaris)を利用する C) コンソールログ独自のローテーション方法 • rotatelogsやcronologなどサードパーティ製のツールを利用する • Windowsサービスの場合は、ログ出力設定すればローテーションされる D) GCログ独自のローテーション方法(JRockitのみ) • jrcmd <PID> verbosity filename=<new_file> ※現時点では、HotSpotのjinfo では変更できなかった Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • OS環境設定 • リソース制限に注意 – コアファイルサイズ(ulimit -c) • 運用環境では「unlimited」に設定する – ファイルディスクリプタ(ulimit -n) • 厳密には難しいが「8192」程度に設定すれば問題ないことが多い • カーネル設定は? – 以前はマニュアルに“推奨値”とする記載があったが、 最近のマニュアルからは削除されている • 『構築・運用ガイド』の参考値をベースラインにシステムごとにチューニング • 言語の設定 – ログメッセージやJava APIの一部はデフォルトロケールに依存 • LANG環境変数などを起動スクリプトで明示的に設定 ※Windows環境では通常いずれとも行う必要なし Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • OS環境設定 (参考) WLS9.1のマニュアル – http://otndnld.oracle.co.jp/document/products/wls/docs91 /perform/HWTuning.html#1124020 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • セキュリティ • アカウント利用時の注意事項 – デフォルトで作成される管理アカウントのみでの運用は危険 • 誤った(破壊的な)設定変更が行われるリスクがある • パスワード間違えにより、アカウントロックされる ⇒運用に応じて適度にアカウントを分けておく 運用で利用する可能性の高いロール・グループ 目的 ロール グループ 説明 システム管理用 Admin Administrators 構成変更を含め、すべての操作が行えるが アカウントロックやパスワード紛失に備え、 複数用意しておくとよい デプロイ用 Deployer Deployers アプリデプロイに関する操作のみ行えるため、 アプリ担当が利用するとよい モニタリング用 Monitor Monitors サーバー構成やランタイム情報の表示のみ 行えるため、監視/統計に向いている Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • セキュリティ • WebサーバーでBASIC認証を行う際の注意点 – 第19回WLS勉強会のLT資料を参照 http://www.slideshare.net/OracleMiddleJP/webbasic • X-Powered-Byヘッダーの無効化 – デフォルトでは「X-Powered-By: Servlet/3.0 JSP/2.2」のように レスポンスヘッダに出力されるが、実装バージョンを含めないよう 無効化してもよい – <ドメイン>→[構成]→[Webアプリケーション]から設定 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • セキュリティ • 一般的な推奨事項は以下ドキュメントを参照 Oracle Fusion Middleware ドキュメント・ライブラリ > WebLogic Server > SECURITY > 本番環境の保護 参考リンク – 12c Release 1(12.1.1) - 英語 • http://docs.oracle.com/cd/E24329_01/web.1211/e24418/toc.htm – 11g Release 1(10.3.5) - 日本語 • http://docs.oracle.com/cd/E24001_01/web.1111/b61616/toc.htm Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • ネットワーク • リスニングアドレス – デフォルトでは指定されておらず、OSにバインドされている すべてのIPアドレスやホスト名でアクセス可能 – 複数NICがあるマルチホーム環境では、リスニングアドレスを 明示しないと、管理サーバー・管理対象サーバー間の通信が 不安定になるため設定を推奨 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • ネットワーク • ネットワークチャネル – 目的(プロトコル)別に、リスニングするアドレスとポートを指定して 追加し、性能・セキュリティ面の向上を図る – 場合によっては管理ポートを有効化してもよい [環境]→[サーバー]→<サーバー名>→[プロトコル]→[チャネル]から設定 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • ネットワーク ネットワークの構成とリスニングアドレス・チャネルの設定例 サービス用 サービス用通信 セグメント S S 管理 管理対象 管理対象 サーバー サーバー サーバー A A A 管理用 管理系通信 セグメント S サービス用の通信(http)はチャネルを明示的に定義 A 管理系の通信(t3, iiop, httpなど)はリスニングアドレスの設定 により作成されるデフォルトチャネルを利用 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 起動・停止スクリプト 起動スクリプトの構造 • <DOMAIN_HOME>/bin/startManagedWebLogic.sh └ <DOMAIN_HOME>/bin/startWebLogic.sh └<DOMAIN_HOME>/bin/setDomainEnv.sh └<WL_HOME>/common/bin/commEnv.sh 停止スクリプトの構造 • <DOMAIN_HOME>/bin/stopManagedWebLogic.sh └ <DOMAIN_HOMEbin/stopWebLogic.sh └<DOMAIN_HOME>/bin/setDomainEnv.sh └<WL_HOME>/common/bin/commEnv.sh Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 起動・停止スクリプト • デフォルトで作成される起動・停止スクリプトを最大限活用 – インスタンス単位のカスタムスクリプトを用意し、そこから start(Managed)WebLogic.sh, stop(Managed)WebLogic.sh を呼び出す形式にする – ドメイン共通の設定は、setDomainEnv.sh に設定する 利用する可能性の高い環境変数 環境変数 説明 JAVA_HOME WLSを起動するJDKのホームディレクトリ JAVA_VENDOR JDKのベンダー(ex. Oracle, Sun, HP, IBM) USER_MEM_ARGS デフォルトで設定されるメモリ用起動オプション(MEM_ARGS)を上書き JAVA_OPTIONS システムプロパティ(-D<key>=<value>)やGCログ用オプションなど、 通常のJava起動オプションを設定 CLASSPATH クラスパスを設定するが、付加する位置を制御するために、 PRE_CLASSPATHやPOST_CLASSPATHも利用可能 SERVER_NAME WLSを識別するサーバー(インスタンス)名 ADMIN_URL 接続先となるサーバー(通常、管理サーバー)のURL Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 起動・停止スクリプト 起動・停止スクリプト共通の考慮点 • OSアカウントによる制限 – rootで起動されてしまい、作成されるファイルのオーナーが変更 されるトラブルを防ぐ • その後、通常アカウントで起動する際に、ファイルの書き込みに失敗し、 起動できなくなる危険がある • umaskによるパーミッションの設定 – WLS11g以降の起動スクリプトでは、umaskが「037」 – WLS11g以降の停止スクリプトでは、umaskが「026」 ⇒ログファイルの読み取りなどに注意が必要 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 起動・停止スクリプト 起動スクリプトの考慮点 • 管理対象サーバー起動時の管理サーバーへの接続 – 明示的に管理サーバーのURLを指定する startManagedWebLogic.sh <server> t3(s)://<admin_host>:<port> SERVER_NAME(必須) ADMIN_URL(省略可) ※URLを指定しないと、デフォルトで「http://<admin_host>:<port>」になる ⇒若干、管理サーバーとの通信の安定性に懸念がある – OS起動時に自動起動する場合は、管理サーバーとの起動順序 やリトライを考慮する • Windowsサービス(beasvc[≦11g],wlsvc[12c])で起動する場合は、管理 サーバーのサービス起動後に管理対象サーバーを起動するよう設定する ことも可能 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 起動・停止スクリプト 停止スクリプトの考慮点 (stopWebLogic.sh 抜粋) echo "connect(${userID} ${password} url=${ADMIN_URL}, adminServerName=${SERVER_NAME})" >>"shutdown.py" echo "shutdown(${SERVER_NAME},Server, ignoreSessions=true)" >>"shutdown.py" echo "exit()" >>"shutdown.py" echo "Stopping Weblogic Server..." ${JAVA_HOME}/bin/java -classpath ${FMWCONFIG_CLASSPATH} ${MEM_ARGS} ${JVM_D64} ${JAVA_OPTIONS} weblogic.WLST shutdown.py 2>&1 • 管理対象サーバーを停止する際は、明示的に各サーバー 自身のURLを指定する stopManagedWebLogic.sh <server> t3(s)://<managed_host>:<port> SERVER_NAME(必須) ADMIN_URL(省略可) ※URLを指定しないと、管理サーバー経由で停止することになる ⇒管理サーバーが正常に稼働していないと停止できない Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 起動・停止スクリプト 停止スクリプトの考慮点(続き) • shutdown時のオプションに注意 – デフォルトでは処理中の実行スレッドがあると停止しない ⇒force=trueやtimeOut=n(秒)オプションの指定を考慮する – OSコマンドでの停止も検討する kill -SIGTERM (SIGINT[Ctrl+C]でも基本的に同様) • force=trueと同様だがJVMの停止フックを利用 kill -SIGKILL (Windowsではtaskkill /F /PID) • 最終手段であり、ロックファイルが残るなどの弊害が生じる可能性がある • 同一マシン内での同時実行 – shutdown.py が同時に書き込まれ、失敗する可能性がある ⇒shutdown-${SERVER_NAME}.py などに変更 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 監視/統計 監視 • プロセス監視 java ~ -Dweblogic.Name=<server> ~ weblogic.Server プロセス名 サーバー(インスタンス)名の識別 WLSのメインクラス • ヘルスチェック – WLS8.1までは weblogic.Admin PINGを利用することがあったが、 weblogic.AdminユーティリティはWLS9.0以降で非推奨になった • WLSTのconnectが直接の代替だが、ヘルスチェックとしては重い – HTTPリクエストを実際に投げて応答をチェックするのが現実的 • アクセスログに記録されることは避けられない • フルGCを考慮してタイムアウトやリトライを実装 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 監視/統計 監視 • ログファイル – サーバーログよりもコンソールログを監視対象とする • 基本的に重大度の高いログのみが出力され、目視でも確認しやすい ※サポートへはサーバーログも併せて要送付 • OOMEなどの問題も検出しやすい • 監視のテストも行いやすい – ドメインログは監視には向いていない • リアルタイムに出力されない • 管理サーバーが停止しているとドメインログは出力されない 重大度 監視有無 Emergency, Alert, Critical 基本的に監視対象とすべき Error, Warning 場合によって監視対象とする Notice, Info, Debug, Trace 基本的に監視対象とすることはない ※重大度をベースとし、特定のメッセージID(BEA-xxxxxx)を包含・除外する Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 監視/統計 監視 • メトリック値による閾値判定・アラート – MBeanによるモニタリング • WLST, WLDFなど組み込みのツール • その他のJMX対応モニタリングツール 監視に利用する代表的な実行時MBean MBeanの種類 説明 JVMRuntime ヒープサイズや空き容量を取得する ThreadPoolRuntime スレッドの使用状況を取得する WebAppComponentRuntime HTTPセッションの使用状況を取得する JDBCDatasourceRuntime JDBCデータソースの使用状況を取得する Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • 監視/統計 統計 • ログファイルの集計 – HTTPアクセスログ • 平均所要時間、最大所要時間など • ステータスコードごとの件数など 一般的なアクセスログ解析はWebサーバー側で行った方がよい – GCログ • GCの回数、平均所要時間など • フルGC後のヒープサイズの推移など • メトリック値の収集・蓄積 – MBeanによるモニタリング • 監視の項を参照 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • (単位: - ) 0 10 20 30 40 50 60 70 2009/2/13 10:41:27 監視/統計 2009/2/13 10:43:27 2009/2/13 10:45:27 2009/2/13 10:47:28 2009/2/13 10:51:24 2009/2/13 10:53:25 2009/2/13 10:55:25 2009/2/13 10:57:52 2009/2/13 10:59:52 2009/2/13 11:01:53 2009/2/13 11:03:53 2009/2/13 11:05:54 2009/2/13 11:08:18 2009/2/13 11:10:37 2009/2/13 11:12:38 2009/2/13 11:14:38 2009/2/13 11:17:04 2009/2/13 11:19:05 2009/2/13 14:29:59 2009/2/13 14:32:12 2009/2/13 14:34:24 2009/2/13 14:48:50 ThreadPoolRuntime 2009/2/13 14:50:50 2009/2/13 14:53:01 2009/2/13 14:55:29 2009/2/13 14:57:30 2009/2/13 14:59:32 2009/2/13 15:01:34 2009/2/13 15:03:36 2009/2/13 15:05:38 2009/2/13 15:07:56 スレッドの利用状況例 (by WebLoDOCK-Monitor/Viewer) 2009/2/13 15:10:18 Throughput HoggingThreadCount StandbyThreadCount ExecuteThreadIdleCount ExecuteThreadTotalCount PendingUserRequestCountCopyright (c)2012 ITOCHU Techno-Solutions Corporation
    • [宣伝] WebLogic診断/監視サービス(WebLoDOCK) Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • [宣伝] WebLogic診断/監視サービス(WebLoDOCK) WebLogic診断/監視サービス(WebLoDOCK) の提供内容 運用支援ツール(WebLoDOCK-Monitor) 診断レポートに必要な情報を取得するための監視モニターツールです。 WebLogic Serverから必要な情報を一度に取得することが可能です。 また、閾値の設定により、メールによるアラート通知やスレッドダンプの取得も行えます。 ⇒障害およびサービスダウンを未然に防ぐ ⇒サポートによる問題解決時間の短縮 情報閲覧ビューワ(WebLoDOCK-Viewer) WebLoDOCK-Monitorで取得した情報を閲覧する専用ビューワです。 グラフ化することで、WebLogic Serverの稼働状況を把握することが可能になります。 作成されたグラフは、エンドユーザ様への報告資料にもご活用いただけます。 ⇒可視性の向上 診断レポート WebLoDOCK-Monitor、および各種ログ情報などから障害が発生していないか、 障害が発生しそうな兆候はないかについて、弊社エンジニアが診断致します。 また、簡易的なチューニングのご提案も含みます。 ⇒運用管理者の心強い味方 Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • Q&A Copyright (c)2012 ITOCHU Techno-Solutions Corporation
    • Copyright (c)2012 ITOCHU Techno-Solutions Corporation