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

自己紹介 • 自己紹介 – 山田貴裕 (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

目的と対象 • 目的 – トラブルを未然に防ぐ – トラブルに迅速に対処する • 対象 – WLSのインフラ設計・構築担当者 – WLSの運用管理者 – (WLSの開発担当者) • 環境 – WLS9.x以降 – Unix系OS(Solaris, Linux)中心 • Windowsでもほぼ適用可能 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

ログ管理 • コンソールログ – スレッドダンプ出力や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

セキュリティ • アカウント利用時の注意事項 – デフォルトで作成される管理アカウントのみでの運用は危険 • 誤った(破壊的な)設定変更が行われるリスクがある • パスワード間違えにより、アカウントロックされる ⇒運用に応じて適度にアカウントを分けておく運用で利用する可能性の高いロール・グループ目的ロールグループ説明システム管理用 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

ネットワークネットワークの構成とリスニングアドレス・チャネルの設定例サービス用サービス用通信セグメント 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) WebLogic診断/監視サービス(WebLoDOCK) の提供内容 運用支援ツール（WebLoDOCK-Monitor）診断レポートに必要な情報を取得するための監視モニターツールです。 WebLogic Serverから必要な情報を一度に取得することが可能です。また、閾値の設定により、メールによるアラート通知やスレッドダンプの取得も行えます。 ⇒障害およびサービスダウンを未然に防ぐ ⇒サポートによる問題解決時間の短縮 情報閲覧ビューワ（WebLoDOCK-Viewer） WebLoDOCK-Monitorで取得した情報を閲覧する専用ビューワです。グラフ化することで、WebLogic Serverの稼働状況を把握することが可能になります。作成されたグラフは、エンドユーザ様への報告資料にもご活用いただけます。 ⇒可視性の向上 診断レポート WebLoDOCK-Monitor、および各種ログ情報などから障害が発生していないか、障害が発生しそうな兆候はないかについて、弊社エンジニアが診断致します。また、簡易的なチューニングのご提案も含みます。 ⇒運用管理者の心強い味方 Copyright (c)2012 ITOCHU Techno-Solutions Corporation

http://d.hatena.ne.jp	174
http://blogs.oracle.com	126
http://a0.twimg.com	15
https://twitter.com	14
http://hatena-anohito.appspot.com	4
http://webcache.googleusercontent.com	1

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

by Oracle Fusion Middleware

Accessibility

Categories

Upload Details

Usage Rights

6 Embeds 334

Statistics

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