Microsoft PowerPoint - wsdd_WASV6EnterpriseDesign_02InfraDesign_update.ppt

Transcription

1 WASV6 による基幹システム設計 Workshop インフラ設計

2 このセッションの目的 ミッション クリティカルな環境における WAS トポロジー設計に必要な知識の習得 WAS システム トポロジー設計に影響する WAS の高可用 高パフォーマンス機能を理解する パフォーマンス 可用性 セキュリティー要件に基づいた WAS システム トポロジーの選択基準 メリット デメリットを理解する 2

3 Agenda 1. WAS 高可用 高パフォーマンス機能 1-1 WASシステム構成を考える際の考慮点 1-2 クラスター WLM 1-3 HAマネージャー 1-4 セッション パーシスタンス 1-5 キャッシング 2. WAS トポロジー設計 2-1 パフォーマンス 拡張性設計 2-2 可用性 障害設計 2-3 セキュリティーに関する設計 3

4 1. WAS 高可用 高パフォーマンス機能 1-1 WAS システム構成を考える際の考慮点 1-2 クラスター WLM 1-3 HA マネージャー 1-4 セッション パーシスタンス 1-5 キャッシング 4

5 Web インフラ設計の考慮点 機能要件と非機能要件 Web インフラ設計においては 非機能要件が重要 プロジェクトの早い段階 ( 要件定義局面 ) で明確化し 実現可能性を評価 変更時の柔軟な対応 機能要件 / 業務要件 非機能要件 アプリケーション要件 データ要件 性能 品質要件 制約 パフォーマンス 信頼性 (RASIS) セキュリティー 運用管理 予算 スケジュール スキル 配置場所 / 環境 既存システム 準拠する標準 / 規約 同じ機能要件機能要件をもつ 2 つのシステムシステムでもでも 非機能要件非機能要件が異なるとデザインもプラットフォームプラットフォームも規模規模 構築構築コストコストも異なるなるシステムシステムとなる 5

6 Web インフラ設計の考慮点 非機能要件 性能品質セキュリティー運用管理 パフォーマンス ( レスポンスタイム ) キャパシティー ( スループット ) スケーラビリティー Reliability( 信頼性 ) Availability( 可用性 ) Serviceability( 保守性 ) Integrity( 保全性 完全性 ) Security サービス監視システム運用管理アプリケーション管理 応答時間 システムの処理能力 システムのユーザー数 同時接続ユーザー数 データ量 拡張容易性 故障 障害の起こりにくさ システムの利用可能性の高さ 故障 障害の修復の容易性 システムが正しい結果を返すこと ハードウェアや電源障害が発生した場合にもデータが保証されること 不正侵入 盗聴などによる情報漏洩などからデータを守ること パフォーマンスや信頼性の要件が達成できているかを監視すること システムのバックアップ バッチ処理の実行など日常運用の要件 アプリケーションの変更 6

7 Web インフラの構成要素 ネットワーク Router,Switch, Firewall プラットフォーム Blade,,zSeries OS(Unix,Linux, Win,zOS) Storage Area Network Load Balancer Proxy または認証 Server Web Server Application Server MQ Server Client 基幹システム (CICS, IMS, ERP) Sorry Server このセッションセッションでメインにおにお話するする範囲 Directory Server DB Server 監視 Server 7

8 WAS が提供する高可用 高パフォーマンス機能 高パフォーマンスパフォーマンス機能 高可用性機能 キャッシング 重複したリクエストはキャッシュから応答し パフォーマンス向上 後方サーバーへのリクエストが減少し リソースの有効活用 WAS では 動的コンテンツのキャッシュも可能 クラスター (WLM) 複数のアプリケーション サーバーで処理を分散し 障害時には 他のサーバーで処理を引き継ぐ機能 V6 では メッセージング エンジンのクラスター化も可能 V6 でステートフル セッションビーン フェイルオーバー機能が追加 セッション パーシスタンス サーバー障害時に セッション情報を保持する機能 セッション情報のコピー先として DB とメモリー間複製の 2 種類 V6 では メモリー間複製が改良 HA マネージャー V6 New シングルトン サービス ( トランザクション マネージャー メッセージング エンジン EJB WLM 情報 ) のフェイルオーバー機能 8

9 1. WAS 高可用 高パフォーマンス機能 1-1 WAS システム構成を考える際の考慮点 1-2 クラスター WLM 1-3 HA マネージャー 1-4 セッション パーシスタンス 1-5 キャッシング 9

10 クラスター WLM とは クラスター WLM( ワークロード マネージメント ) とは WASのクラスターなどで 複数のサーバーで同一の処理を行い その前段でリクエストの割り振りを行う サーバーに障害が発生した場合には 障害を検知し 他の正常なサーバーに割り振りを行う 同一セッションのリクエストは同一サーバーに割り振る機能もある 負荷分散装置による WLM Web Container WLM EJB Container WLM Client 負荷分散装置 (Load Balancer, etc) 3 つの WLM ポイント Web Server Plug-in Web Server Servlet Servlet Servlet WLM Plug-in Application Server (Web コンテナ ) EJB EJB EJB Application Server (EJB コンテナ ) 10

11 負荷分散装置による WLM 概要 WLM を行うコンポーネント 割り振り方式割り振りポリシーセッション Affinity (Sticky) 障害検知 WAS Edge コンポーネント MAC 転送方式 (MAC アドレス変換 ) 動的な重み計算計算によるによる割り振り接続数などになどに応じてじて Sorry サーバーに割り振ることもることも可能クライアント IP によるセッションセッション維持 Advisor による定期的定期的な HTTP リクエストのレスポンスレスポンスで障害検知 負荷分散装置による WLM Web Container WLM EJB Container WLM Client 負荷分散装置 (Load Balancer, etc) Web Server Plug-in Web Server Servlet Servlet Servlet Application Server (Web コンテナ ) WLM Plug-in EJB EJB EJB Application Server (EJB コンテナ ) 11

12 Dispatcher による WLM Dispatcher の内部構成要素 DispatcherはEdgeコンポーネントのLoad Balancer 内で負荷分散機能を提供 サーバーの監視監視を行いレスポンスの時間時間を Managerに伝える Server dsserver(java コンポーネント ) 監視 Manager Advisor Server リクエスト Client Executor カーネル 割り振り Server Executor から接続数接続数を受け取り それらのそれらの情報情報を基に負荷を計算計算して Executorに 重み として伝える Load Balancer Managerに接続数を伝え 重み を基に割り振りをりを行う Cluster 12

13 Dispatcher による WLM 割り振り先決定メカニズム Advisor 定期的な動的動的な重み計算 Manager Executor 2 秒間隔で 最新最新の割り振り先の重みをみを取得 (4 秒間隔で Managerに接続数接続数などをなどを通知 ) リクエスト処理 Executor Affinityの設定設定が有効有効になっているになっている場合場合は 前回と同一同一のサーバーサーバーを割り振り先としてとして決定 7 秒間隔で 監視用監視用リクエストリクエストを送信送信し 割り振り先の生死情報生死情報 レスポンスタイムレスポンスタイムを取得 2 秒間隔で AdvisorとExecutor からの情報 ( 生死情報 レスポンスタイムレスポンスタイム 接続数接続数など ) から割り振り先の重みをみを計算 Affinity( セッション維持維持のためのため設定 ) IP Sticky Affinity が ON で 2 回目以降のリクエストの場合 Affinity が OFF または 初期リクエストの場合 Rule 定義と照らしらし合わせてわせて 割り振り候補候補のサーバーグループサーバーグループを決定 Ruleの例 (SorryServer への割り振り設定設定など ) Client IP 時間 秒あたりの接続数 活動中の接続数 候補のサーバーグループサーバーグループ内で動的な重みにみに応じてじて割り振り先決定 リクエストの割り振り実行 13

14 Dispatcher による WLM 割り振り先サーバーの障害検知メカニズム (1/2) 負荷分散の対象となるサーバーに定期的にリクエストを送信 レスポンスが返れば サーバーは正常と判断 レスポンスが返らないと サーバーダウンと判断 接続情報 レスポンスがあればがあれば正常 Executor なければダウンダウンと判断 Manager 重みの計算結果 障害検知の精度精度は高いがいが 障害検知に時間時間がかかるがかかる場合場合がある 7 秒間隔で呼び出す Advisor 生死情報, レスポンスタイム Load Balancer リクエストレスポンス Server ユーザーリクエストとは異なる 監視用のリクエストを使用し HTTP のリクエストのレスポンス結果からサーバーの障害を判定 (cf. Web サーバー Plugin からアプリケーション サーバーの障害検知は ユーザーリクエストを使用し TCP/IP のコネクション レベルで行う ) 14

15 Dispatcher による WLM 割り振り先サーバーの障害検知メカニズム (2/2)( 参考 ) Advisor の監視に使われる制限時間 interval Advisorを呼び出す間隔 ( デフォルト7 秒 ) connecttimeout 接続をするまでの時間制限 ( デフォルト21 秒 ) receivetimeout レスポンスを受け取るまでの時間制限 ( デフォルト21 秒 ) Advisorの監視 ClusterA < Server1> < Server2 > 7 秒間 ClusterA 7 秒間 interval < Server1> < Server2 > interval 7 秒間 interval 接続開始 最大 21 秒間 connecttimeout 接続確立 リクエスト 最大 21 秒間 recievetimeout レスポンス < S e r v e r 1 >< S e r v e r 2 接続終了 実リクエストと監視用リクエストは異なり 実リクエストが失敗した場合のリトライはない 接続開始 15

16 Dispatcher による WLM Dispatcher 自身の高可用性 Primary-Backupの2 台でHA 構成 (Backup 機はスタンバイ状態 ) Primaryサーバーの障害時にBackupサーバーが処理を引き継ぐ 0.5 秒間隔で 4 回 ( デフォルト ) ハートビートが届かなかったらかなかったら相手をダウンダウンと判断 Primary heartbeat Client Backup Server Dispatcher 機能と設定方法などの詳細は下記のワークショップ資料の記載を参照ください WASV6 EdgeComponent & IHS インプリメンテーション ワークショップ - Load Balancer 16

17 Web コンテナー WLM 概要 WLM を行う実体割り振りポリシーセッション Affinity 障害検知 Web サーバー Plugin 重み付きラウンドラウンド ロビンランダムクッキー URL 再書き込み実リクエストリクエストの接続接続の確立確立によりにより 障害検知 負荷分散装置による WLM Web Container WLM EJB Container WLM Client 負荷分散装置 (Load Balancer,etc) Web Server Plug-in Web Server Servlet Servlet Servlet Application Server (Web コンテナ ) WLM Plug-in EJB EJB EJB Application Server (EJB コンテナ ) 17

18 18 接続接続接続接続が生成生成生成生成できるできるできるできる場合場合場合場合は リクエストリクエストリクエストリクエストをそのままをそのままをそのままをそのまま割り振る 接続接続接続接続が生成生成生成生成できないできないできないできない場合場合場合場合は 割り振りをりをりをりを試行試行試行試行したしたしたしたサーバーサーバーサーバーサーバーをダウンダウンダウンダウンとマークマークマークマークし 再度割再度割再度割再度割り振り先サーバーサーバーサーバーサーバーを決定決定決定決定 Web コンテナー WLM 割り振り先決定メカニズム Cookie またはまたはまたはまたは URL 再書再書再書再書き込みにみにみにみに含まれるまれるまれるまれるセッションセッションセッションセッション情報情報情報情報からからからから初期初期初期初期リクエストリクエストリクエストリクエストか 2 回目以降回目以降回目以降回目以降のリクエストリクエストリクエストリクエストかをかをかをかを判断判断判断判断 ( メモリーメモリーメモリーメモリー間複製間複製間複製間複製 (peer to peer) のセッションセッションセッションセッション パーシスタンスパーシスタンスパーシスタンスパーシスタンスを設定設定設定設定しているしているしているしている場合場合場合場合にはにはにはには PartitionID が それそれそれそれ以外以外以外以外の場合場合場合場合は サーバーサーバーサーバーサーバーを直接的直接的直接的直接的に表す CloneID が含まれるまれるまれるまれる ) 前回割前回割前回割前回割り振られたられたられたられたサーバーサーバーサーバーサーバーを割り振り先サーバーサーバーサーバーサーバーとするとするとするとする重み付きラウンドロビンラウンドロビンラウンドロビンラウンドロビンまたはまたはまたはまたはランダムランダムランダムランダムの WLM メカニズムメカニズムメカニズムメカニズムによりによりによりにより 割り振り先サーバーサーバーサーバーサーバーを決定決定決定決定割り振り先サーバーサーバーサーバーサーバーの状態状態状態状態がダウンダウンダウンダウンではないではないではないではない またはまたはまたはまたは ダウンダウンダウンダウンの状態状態状態状態であってもであってもであってもであっても 再試行間隔再試行間隔再試行間隔再試行間隔 ( デフォルトデフォルトデフォルトデフォルト 60 秒 ) を経過経過経過経過しているしているしているしている場合場合場合場合は 接続接続接続接続を試行試行試行試行 状態状態状態状態がダウンダウンダウンダウンで 再試行間隔再試行間隔再試行間隔再試行間隔を経過経過経過経過していないしていないしていないしていない場合場合場合場合は 再度割再度割再度割再度割り振りサーバーサーバーサーバーサーバーを決定決定決定決定リクエストリクエストリクエストリクエストの割り振りをりをりをりを実行実行実行実行 2 回目以降のリクエストの場合初期リクエストの場合割り振り先サーバーがダウンしていない場合接続を生成できる場合割り振り先サーバーがダウンしている場合接続を生成できない場合

19 Web コンテナー WLM Web サーバー Plugin での Session Affinity ND 構成では Web サーバー Plugin はデフォルトで Session Affinity を行う WAS の発行する Cookie または URL 再書き込みの中の JSESSIONID に付加される 各アプリケーション サーバー毎に割り当てられた CloneID を利用 JSESSIONID=0001eCtUKo0_Kj5BWGsW5UoLVpz:10j0tobbm 10j0tobbm メモリー間複製 (peer to peer) のセッション パーシスタンスを行っている場合には CloneID ではなく 間接的に割り振りサーバーを表す PartitionID を使用 ( 後述 ) CloneID=10j0tobbm 1. 初回リクエスト 4. レスポンス 5. 2 度目のリクエスト 8. 2 度目のレスポンス WebServer Web Server Plug-in 2. Plug-in による割り振り スが付加 ) からのレスポンに 3. AppServer (Cookie JSESSIONID=XXX:10j0tobbm 6. Cookie を検証し 同一サーバーへ 7. サーバーからのレスポンス CloneID=10j0tohta Web コンテナー EJB コンテナー WLM の動きのベースは WAS V5.1 と同様です 詳細は下記のワークショップ資料の記載を参照ください WAS5.1 インフラ構成の心得 - WebSphere 基本機能 (WAS コンポーネントと Workload Management p.57-82) 19

20 Web コンテナー WLM 割り振り先サーバーのプロセス障害検知メカニズム プロセス障害は即時に検知されます SYN パケットに対して RST パケットが返ってきた時点で使用不可とみなします リクエストの割り振りは次のサーバーへリトライされ クライアントからは透過的にフェイルオーバーが行われます 復旧の検知は秒単位で指定することができます 一度ダウンとみなされたサーバーは 再試行間隔 ( デフォルト 60 秒 ) で設定された秒数経過した後に再度割り振りを試みます Web Server Plug-in 1. SYN 2. RST 3. ダウンとみなす 4. 他のサーバーへリトライ Application Server 5. RetryInterval 経過 Web Server Plug-in 6. 再 り度割り振してみる Application Server Application Server Application Server Pluginは障害障害を検知検知してもしても アラートアラートは通知通知しないのでしないので 別途 Java プロセスの監視監視などがなどが必要 20

21 Web コンテナー WLM 割り振り先サーバーのネットワーク障害検知メカニズム ネットワーク障害はタイムアウト設定によって検知 デフォルトはOSのTCP/IPタイムアウトで検知 (AIXではデフォルト75 秒 ) 推奨 Webサーバー Plugin 設定の 接続タイムアウト を設定することで時間指定が可能 リクエストの再割り振り 復旧の検知はプロセス障害の場合と同様 Web Server Plug-in 1. SYN 2. ConnectTimeout 経過でダウンとみなす 3. 他のサーバーへリトライ Application Server 4. RetryInterval 経過 Web Server Plug-in 5. 再 り度割り振してみる Application Server Application Server 21

22 Web コンテナー WLM 割り振り先サーバーの WAS ハング検知 拡張ハンドシェークを使用することにより 検知できる場合がある Web コンテナーがレスポンスを返せない場合に検知可能 ( デフォルト :OFF) パフォーマンスに若干のデメリット リクエストの再割り振り 復旧の検知はプロセス障害の場合と同様 Webサーバー Plugin 設定の 接続の最大数 を設定することにより 一台のWASハングによるサイト全面ダウンの防止が可能 1 対 N 構成の場合は設定を推奨 1 対 1 構成の場合は設定しない推奨 この設定値は Web サーバーのプロセス単位の値になるので注意 設定値の詳細は InfoCenter Web サーバー プラグイン用の Application Server プロパティー設定 の記載を参照ください 1. SYN 2. SYN,ACK 3. ACK 拡張ハンドシェーク 4. HTTP HEAD リクエスト Web Server Plug-in 5. ACK 6. HTTP 200 OK (HEAD レスポンス ) 8. ACK 7. HTTP GET または POST リクエスト ( 本来のリクエスト ) 9. HTTP 200 OK ( 本来のレスポンス ) Application Server 22

23 EJB コンテナー WLM 概要 WLM を行う実体割り振りポリシー Affinity 障害検知 EJB WLM Plugin 重み付きラウンドラウンド ロビン Process Affinity (Web コンテナと EJB コンテナが同一同一アプリケーションアプリケーション サーバーサーバー上で稼動稼動しているしている場合場合にはには EJB の負荷分散負荷分散は行われない ) Transaction Affinity ローカルを優先 (ON,OFF 設定可 ) 実リクエストリクエストの接続接続の確立確立によるによる障害検知 HA マネージャーによるによる障害検知 負荷分散装置による WLM Web Container WLM EJB Container WLM Client 負荷分散装置 (Load Balancer, etc) Web Server Plug-in Web Server Servlet Servlet Servlet Application Server (Web コンテナ ) WLM Plug-in EJB EJB EJB Application Server (EJB コンテナ ) 23

24 EJB コンテナー WLM 割り振り先決定メカニズム 下記の Affinityに該当該当するするリクエストリクエストか判断判断し Affinityに該当該当するする場合場合にはには 前回のリクエストリクエストと同じ EJB コンテナーにリクエストリクエストを割り振る プロセス Affinity CookieまたはURL 再書き込みのセッション情報から (EJB クライアントと EJB サーバーが同一同一アプリケーションアプリケーション サーバーサーバー上で稼動 トランザクション Affinity 初期リクエストか (BMT または CMT 2 回目以降のリクエストかを判断によらず トランザクショントランザクション処理中処理中のリクエスト ローカルローカルを優先 ( 同一ホストホスト上の EJB コンテナーに優先的優先的に割り振る :ONとOFFを選択可能 重み付きラウンドロビンラウンドロビンの WLM メカニズムによりにより 割り振り先サーバーサーバーを決定 稼動しているしている場合 : 常に有効 ) リクエスト : 常に有効 ) 選択可能 ( デフォルト ON)) Affinityの必要がない場合 Affinityが有効な場合 Affinity 先のサーバーサーバーを割り振り先サーバーサーバーとする ( ローカルを優先優先で ローカルローカルのサーバーサーバーが複数複数あるある場合場合は 対象サーバーサーバーの範囲範囲で重み付きラウンドロビン ) DMがルーティング テーブルテーブルは HA マネー SPOFにジャーによってによって管理管理されされ 直接直接 ならないまたは EJB レスポンスによってによって更新 割り振り先サーバーがダウンしている場合 ルーティング テーブルテーブル情報情報からから割り振り先サーバーサーバーの状態状態がダウンダウンではないではない または ダウンダウンの状態状態であってもであっても wlm.unusable.interval( デフォルト 300 秒 ) を経過経過しているしている場合場合は 接続接続を試行試行 状態がダウンダウンで 再試行間隔再試行間隔を経過経過していないしていない場合場合は 再度割再度割り振りサーバーサーバーを決定 割り振り先サーバーがダウンしていない場合 接続を生成できない場合 接続が生成生成できるできる場合場合は リクエストリクエストをそのままをそのまま割り振る 接続が生成生成できないできない場合場合は 割り振りをりを試行試行したしたサーバーサーバーをダウンダウンとマークマークし 再度割再度割り振り先サーバーサーバーを決定 接続を生成できる場合 リクエストの割り振りをりを実行 24

25 EJB コンテナー WLM 割り振り先サーバーの障害検知メカニズム (1/3) プロセス障害 ネットワーク障害については Web サーバー Plugin と同様に検知 フェイルオーバーを実施 復旧の検知は秒単位で指定可能 一度ダウンとみなされたサーバーは com.ibm.websphere.wlm.unusable.interval ( デフォルト 300 秒 ) で設定された秒数経過した後に再度割り振りを試行 EJB クライアントの汎用 JVM 引数に設定 設定値の詳細は InfoCenter ワークロード管理構成の調整 の記載を参照ください 1. 最初の割り振りと障害検知 EJB Container1 Application Server 4. もう一度割り振りしてみる EJB Container1 Application Server Web Container Application Server WLM Plug-in Web Container Application Server WLM Plug-in 2. 他のサーバーへリトライ EJB Container2 3. wlm.unusable.interval 経過後 EJB Container2 Application Server Application Server 25

26 EJB コンテナー WLM 割り振り先サーバーの障害検知メカニズム (2/3) HA マネージャーによる障害検知 ( 詳細は後述 ) すべての JVM プロセスで稼動する HA マネージャーによる相互の Socket 監視と Heartbeat による監視により リクエスト試行前にプロセス障害 ネットワーク障害を検知可能 Web Container HA Manager Application Server WLM Plug-in セル内のすべての JVM 間で状態状態を監視 HA Manager EJB Container1 Application Server HA Manager EJB Container2 Application Server その情報は EJB クライアントと EJB コンテナが同一セル内の場合は 直接通知される EJB クライアントと EJB コンテナが同一セルでない場合は EJB レスポンスに含めて通知される 26

27 EJB コンテナー WLM 割り振り先サーバーの障害検知メカニズム (3/3) コネクション確立後の障害 ( ハングなど ) 要求タイムアウト (com.ibm.corba.requesttimeout: デフォルト 180 秒 ) で設定された時間が経過した後に 使用不可とみなす フェイルオーバーできない場合 EJB のメソッドが実行された可能性がある場合には フェイルオーバーは行わず EJB クライアントにランタイム例外返る 1. 最初の割り振りと障害検知 EJB Container1 Application Server org.omg.corba.comm_failre org.omg.corba_no_response Web Container Application Server WLM Plug-in 2. フェイルオーバー中の例外 EJB Container2 Application Server org.omg.corba.transient EJB WLM における例外の詳細は Redbook WAS V6: High Availability Solutions の EJB WLM exceptions (p.85) の記載を参照ください 27

28 1. WAS 高可用 高パフォーマンス機能 1-1 WAS システム構成を考える際の考慮点 1-2 クラスター WLM 1-3 HA マネージャー 1-4 セッション パーシスタンス 1-5 キャッシング 28

29 HA マネージャーとは コア グループ 構成情報の作成 変更 デプロイメント マネージャー ノード エージェント HA マネージャー ノード エージェント HA マネージャー 構成情報構成情報の同期 アプリケーションアプリケーション サーバーへの Ping 再起動 HA マネージャー 障害検知 情報の共有 (EJB WLM 情報の引継引継ぎ ) シングルトンサービス (TM,ME) の引継引継ぎ HA マネージャー アプリケーション サービスの実行 HA マネージャー アプリケーション サーバー HA マネージャー アプリケーション サーバー アプリケーション サーバー アプリケーションの実行実行に関する動的な情報情報を HA マネージャー間で共有 29

30 HA マネージャーのコンポーネント セルコア グループ ノード A ノード B コーディネーター コアコア グループグループ内全内全てのての情報情報を保持 WLM 情報の更新更新 配布 シングルトンシングルトン サービスサービスのフェイルオーバーの指示ノード C デプロイメント マネージャープロセス ノード エージェントプロセス コーディネーター ノード エージェントプロセス HA マネージャー HA マネージャー HA マネージャー アプリケーション サーバープロセス HA グループ HA マネージャー HA グループ ポリシーポリシーの一致一致する HA マネージャーのグループ ポリシーポリシーとはとは どのどのサービスサービスをどのようにフェイルオーバーフェイルオーバーするかという設定 HA マネージャー アプリケーション サーバープロセス HA マネージャー 自プロセスプロセスで使用使用するする情報情報を保持 WLM 情報の受け取り シングルトンシングルトン サービスサービスのフェイルオーバーの実行 HA マネージャー アプリケーション サーバープロセス 30

31 シングルトン サービスのフェイルオーバー WAS V5.x のトランザクションの回復 マシン A WAS V5.x では 2 フェーズコミットのインダウト状態でアプリケーション サーバーがダウンした場合 回復するためには 同一または異なるアプリケーション サーバーでトランザクションログを再読込させる必要あり インダウト トランザクションが回復するまで DB にロックが残り 正常に稼動しているアプリケーション サーバーでの処理にも影響 クラスター Tran Log アプリケーション サーバー 1 Lock DB2 マシン B アプリケーションサーバー 2 再起動 WMQ 回復手順が煩雑で かつ アプリケーション サーバーの再起動が必要なので 障害回復までに時間がかかる インダウト トランザクションが回復するまで インダウト トランザクションと関係のないユーザーにも影響を与える 31

32 シングルトン サービスのフェイルオーバー WAS V6 のトランザクションの回復 WAS V6 New HA マネージャーの機能機能によりにより 数秒数秒でインダウトインダウト トランザクショントランザクションを復旧 マシン A クラスター マシン B アプリケーション サーバー 2 アプリケーション サーバー 1 AS2 TM AS1 TM 1 アプリケーション サーバー 1 がダウン AS1 TM HA マネージャー HA マネージャー コーディネーター AS1 TLog 共有 Disk 2HA マネージャーがダウンを検知 3 コーディネーターが TM のフェイルオーバーを指示 AS2 TLog WMQ DB2 事前に共有ディスクにトランザクションログを配置 4 フェイルオーバーを指示された HA マネージャーが AS1 の TM を起動 5 インダウト トランザクションをリカバリー 32

33 シングルトン サービスのフェイルオーバー トランザクション マネージャーの HA 設定 共有 Disk の準備 各クラスターメンバーから同時に アクセスできるディスクが必要 ログを配置 WAS の設定 アプリケーション サーバーの設定 トランザクション ログ ディレクトリーの 設定変更 マシン A クラスター マシン B アプリケーション サーバー 2 アプリケーション サーバー 1 共有ディスクにトランザクション AS1 TM AS2 TM AS1 TLog 共有 Disk AS2 TLog クラスターの設定トランザクション マネージャーのフェイルオーバーを有効にする ( デフォルト :OFF) 33

34 シングルトン サービスのフェイルオーバー WAS V5.x のメッセージング サーバー WAS V5.x では 組み込みメッセージングのキュー マネージャーのクラスタリングはサポートされない 組み込みメッセージング サーバーのフェイルオーバーはサポートされない マシン A クラスター アプリケーション サーバー 1 メッセージング サーバー Message Queue マシン B アプリケーション サーバー 2 34

35 シングルトン サービスのフェイルオーバー WAS V6 のメッセージング エンジン WAS V6 New WAS V6の組み込みメッセージングメッセージングは SIBusに統合統合されされ 大きくきく変更 HA マネージャーの機能機能で メッセージングメッセージング エンジンエンジンのフェイルオーバーフェイルオーバーが可能 メッセージングメッセージング エンジンエンジンのパーティショニング ( クラスタリング ) により バス メンバーメンバー内に複数複数のメッセージングメッセージング エンジンエンジンを起動起動し 処理処理の分散分散も可能 マシン C SIBus1 アプリケーション サーバー 3 JMS Client マシン A クラスター アプリケーション サーバー 1 ME1 ME2 マシン B アプリケーション サーバー 2 ME1 ME2 35

36 シングルトン サービスのフェイルオーバー メッセージング エンジンの HA 設定 SIBus のメンバーとして アプリケーション サーバーではなく クラスターを登録 マシン A クラスター SIBus1 アプリケーション サーバー 1 ME 最初に起動した AP 上に ME 起動 マシン B アプリケーション サーバー 2 ME 36

37 HA マネージャーの障害検知メカニズム コア グループ ノード エージェント HA マネージャー ノード エージェント HA マネージャー デプロイメント マネージャー HA マネージャー 障害検知方法 1 ハートビート 2 ソケットの状態 HAマネージャー HAマネージャー HA マネージャー アプリケーション サーバー アプリケーション サーバー アプリケーション サーバー デフォルトの設定設定ではでは ハートビートハートビートによるによる障害障害の検知検知は 10 秒間隔で 20 回失敗 (=200 秒 ) して 障害障害としてとして認識 37

38 1. WAS 高可用 高パフォーマンス機能 1-1 WAS システム構成を考える際の考慮点 1-2 クラスター WLM 1-3 HA マネージャー 1-4 セッション パーシスタンス 1-5 キャッシング 38

39 セッション パーシスタンスとは セッション情報のコピーを異なる場所に保管 Application Server 障害時や計画停止時にも セッション情報を維持する メモリー間複製 他の AppServer のメモリー上にセッションオブジェクトのコピーを作成 セッションオブジェクト v Session DB セッションオブジェクトを DB に保管 セッションオブジェクト v セッションオブジェクトのコピー DB セッションオブジェクトのコピー 39

40 セッション パーシスタンスのパフォーマンスへの影響 WAS V6 Performance Report より HTTP Session Replication Performance for V6.0.2 No Rep M2M peer-to-peer M2M client-server DB reqs/second No rep TBW EOS CPU range % - IHS Node average DB Replicate server 4 13 R/T ms System configuration Workload: Trade-EJB-sync, no dynacache, 2000 users/5000 quotes, 100 clients per driver Driver: Two workload drivers, each eserver BladeCenter HS20, 2 x 3.2 GHz Xeon, SLES 9.0 DMGR and cluster members: eserver BladeCenter HS20, 2 x 3.2 GHz Xeon, Windows 2003 Server Enterprise Edition Database: xseries 440, 4 x 2.8 GHz, HT, Windows 2003 Server Enterprise Edition, 8 GB RAM, DB2 v8.2, DB2 Universal JCC DriverXA, Type 4 注意 1Session サイズ =250 bytes セッション パーシスタンスを行うことはパフォーマンスに影響する サーブレット サービス終了時点での書き込み (EOS) の方が 時間基準 (10 秒間隔 ) での書き込み (TBW) よりもパフォーマンスへの影響が大きい DB パーシスタンスとメモリー間複製で大きな違いはない 40

41 セッション パーシスタンスのパフォーマンスへの影響 WAS V5.1 Performance Report より 絶対値ではなく 傾向は WAS V6 でも同様 Session Management - EOS vs Session Size No Replication MtoM Replication DB Replication reqs/second KB 50KB 100KB Session Size CP U% (WAS) CP U% (DB) R/ T ms System configuration Driver: Java client on xseries x 2.0 GHz Xeon, Windows 2003 Server Enterprise Edition Linux SUT: xseries 330, 2 x 1.2 GHz Pentium III, Red Hat Enterprise Linux, version 2.1 (same for all 9 nodes) Database: xseries x 2.0 GHz Xeon, Windows 2003 Server Enterprise Edition, DB2 V 8.1 FP3, DB2 Type 2 CLI Driver Setup: EOS persistence, 9 cluster members, 50 active sessions per cluster member node セッション パーシスタンスを行う場合 セッション サイズが大きくなるほど パフォーマンスへの影響が極端に大きくなる DB とメモリー間複製の比較では セッションサイズが小さいときには DB の方がパフォーマンスが良く セッション サイズが大きいときにはメモリー間複製の方がパフォーマンスが良い 41

42 セッション パーシスタンスのパフォーマンスへの影響 パフォーマンス向上のための考慮点まとめ 1 セッション サイズセッション数セッション パーシスタンスのチューニング パラメーター できる限り小さく アプリケーション作成時に注意 数 KB 以下を推奨 少ないほどよい アプリケーションでの適切な invalidate 適切なタイムアウト値 ( デフォルト :30 分 ) ユーザー数に対するアプリケーション サーバー数を増やす 書き込み頻度を下げるほどパフォーマンス向上 ただし 可用性は下がる サーブレット サービスの終了 / 手動更新 / 時間基準 時間基準の場合は 時間も設定可 書き込みの内容 複数行スキーマを使用している場合 更新された属性のみ を選択することによりパフォーマンス向上 42

43 セッション パーシスタンス方法の比較 サーブレット サービスの終了 セッション パーシスタンスを使用使用しない データベース 時間基準 サーブレット サービスの終了 メモリー間複製 (peer to peer) 時間基準 障害時のセッションの復旧 ( 一部ロスト ) ( 一部ロスト ) パフォーマンス メモリー使用量 ( パーシスタンスなしと同じ ) ( レプリカ数分増加 ) (client-server の場合は増加しない ) DB の使用 不要 要 ( 業務 DB と共用可 ) 不要 (client-server の場合 別 AppServ が必要 ) セットアップ容易性 - やや複雑 易 実績 - 多い やや少ない データベースとメモリーメモリー間複製間複製ではでは パフォーマンスパフォーマンスの明確明確な相違相違はないのではないので 業務業務アプリケーションアプリケーションで DBを使用使用するする場合場合にはには メモリーメモリー使用量使用量と実績実績から DBの使用使用を推奨 業務業務アプリケーションアプリケーションで DBを使用使用しないしない場合場合は メモリーメモリー間複製間複製も選択肢 Session DB の使用については WAS V5.x と大きな違いはありません 設定上の注意などは下記のワークショップ資料の記載を参照ください WAS5.1 インフラ構成の心得 - WebSphere 基本機能 (Session DB を使用したセッション管理 p ) 43

44 メモリー間複製基礎知識 複製モード peer to peer client/server peer to peer Web Server Web Server Plug-in App Server1 Localのセッション情報他 AppServerのセッション情報 App Server2 Localのセッション情報他 AppServerのセッション情報 複製ドメイン WAS V6 での変更点 設定設定がシンプルシンプルになった レプリカレプリカ数のデフォルトデフォルトはシングル peer to peerの場合場合 WLMと連携連携し ホット フェイルオーバーフェイルオーバーを実現 複製複製パフォーマンスパフォーマンスの向上 client/server Cluster1 App Server1 App Server3 Localのセッション情報他 AppServerのセッション情報 Cluster2 Localのセッションセッション情報 App Server 4 Web Server Web Server Plug-in App Server2 Localのセッションセッション情報 複製ドメイン 他 AppServer のセッションセッション情報 App Server 5 App Server3 Localのセッションセッション情報 他 AppServer のセッションセッション情報 44

45 メモリー間複製の動き ホット フェイルオーバー シングル レプリカの場合にフェイルオーバーが発生しても セッション情報を保持しているサーバーに割り振る機能 App Server1 App Server1 Localのセッション情報他 AppServerのセッション情報 Localのセッション情報他 AppServerのセッション情報 Web Server Web Server Plug-in App Server2 Localのセッション情報他 AppServerのセッション情報 Web Server Web Server Plug-in App Server2 Localのセッション情報他 AppServerのセッション情報 App Server3 Localのセッション情報 App Server3 Localのセッション情報 他 AppServerのセッション情報 他 AppServerのセッション情報 PartitionID CloneID PartitionID CloneID 2S95EDM16I 10j0tobbm (AppServer1 を表す ) 2S95EDM16I 10j0tobbm 15V3JVTHI6 10j0tohta (AppServer2 を表す ) 15V3JVTHI6 10j0tohta DT1VVIVPP 10j0tonlv (AppServer3 を表す ) DT1VVIVPP 10j0tobbm 45

46 メモリー間複製の動き (Note) ホット フェイルオーバー 1. Web サーバー Plugin は PartitionID と CloneID( サーバーの ID) のマッピングテーブルを保持 2. サーバーのダウン発生 3. サーバーダウン後の最初のリクエスト 3.1 Web サーバー Plugin は 既存のマッピング テーブルに従いリクエストを割り振り 3.2 割り振り先がダウンしている場合には 異なるサーバーに割り振り 3.3 アプリケーション サーバーでは まず ローカルのセッション情報を問い合わせ 存在しない場合には リモートのサーバーにセッション情報を問い合わせを行う 3.5 割り振り先が変更されたリクエストの Cookie 情報 (URL 再書き込み情報 ) には 新しい PartitionID を付加 3.4 アプリケーション サーバーは レスポンスに新しいマッピング テーブル情報を追加し Web サーバー Plugin に通知 3.5 Web サーバー Plugin は マッピング テーブル情報を取得 ( ユーザーへのレスポンスからは省く ) 4. サーバーダウン後の 2 回目以降のリクエスト 4.1 新しいマッピング テーブルを使用するため 必ずセッション情報の存在するサーバーにリクエストが割り振られる 4.2 割り振り先が変更されたリクエストの Cookie 情報 (URL 再書き込み情報 ) には 新しい PartitionID を付加 ( サーバーダウン後の最初のリクエストは 各 Web サーバーのプロセスごとに行われます ) 46

47 メモリー間複製検証 (1) 2 つのアプリケーション サーバーを順番に再起動した場合に 再起動前後で セッション情報が保持されるか 検証手順 1. AppServ1 AppServ2 起動 2. ブラウザー 1 とブラウザー 2 からそれぞれ AppServ1 AppServ2 にアクセスしてセッションを作成 3. AppServ1 停止 4. AppServ1 起動 5. AppServ1 起動後 1 分間待つ 6. AppServ2 停止 7. AppServ2 起動 8. ブラウザー 1 とブラウザー 2 から それぞれアクセスしてセッションが引き継げるか確認 peer to peer Web Server Web Server Plug-in App Server1 Localのセッション情報他 AppServerのセッション情報 App Server2 Localのセッション情報他 AppServerのセッション情報 複製ドメイン peer to peerのメモリーメモリー間複製間複製を設定設定しているときにしているときに アプリケーションアプリケーション サーバーを順番順番に再起動再起動してもしても セッションセッション情報情報は保持保持されるされる アプリケーション サーバーサーバーの起動時起動時にメモリーメモリー間複製間複製が実行実行されるされる ( 割り振り先は 停止前停止前と異なる ) 47

48 メモリー間複製検証 (2) 3 つのアプリケーション サーバーでメモリー間複製を設定している時に 1 つのアプリケーション サーバーを停止した場合 既存セッション情報は再度複製されるか peer to peer 検証手順 1. AppServ1 AppServ2AppServ3 起動 2. ブラウザー 1 ブラウザー 2 ブラウザー 3 から それぞれ AppServ1 AppServ2 AppServ3 にアクセスしてセッションを作成 3. AppServ1 停止 4. AppServ1 停止後 1 分間待つ 5. AppServ2 停止 6. AppServ2 停止後 1 分間待つ Web Server 7. ブラウザー 1 ブラウザー 2 ブラウザー 3 からのアクセスがすべて AppServ3 に割り振られ セッションが引き継げるか確認 Web Server Plug-in App Server1 Localのセッション情報他 AppServerのセッション情報 App Server2 Localのセッション情報他 AppServerのセッション情報 App Server3 Localのセッション情報他 AppServerのセッション情報 複製ドメイン アプリケーション サーバーサーバーのダウンダウンを検知検知するとすると 複製複製の無いセッションセッション情報情報は 正常なアプリケーションアプリケーション サーバーサーバー上に複製複製を生成生成するする ( 同時に複数複数のサーバーサーバーがダウンダウンしたした場合場合にはには セッションセッション情報情報は失われるのでわれるので注意 ) 48

49 1. WAS 高可用 高パフォーマンス機能 1-1 WAS システム構成を考える際の考慮点 1-2 クラスター WLM 1-3 HA マネージャー 1-4 セッション パーシスタンス 1-5 キャッシング 49

50 なぜ キャッシュが必要か 相反する課題への対応が求められる ユーザー数の増大レスポンス タイム ユーザー毎にカスタマイズされた動的コンテンツ 動的キャッシュキャッシュの利用 同じことは何度も聞かない! 再利用できる情報はキャッシュし より前段のコンポーネントでレスポンスを返す 50

51 なにがキャッシュできるのか? 株価情報サイトの例 動的コンテンツ 多くのユーザーに共通して使用されるコンテンツ 生成されたページにある程度の時間有効期間がある 静的コンテンツ 多くのユーザーに共通して使用される静的コンテンツ 画像ファイル ヘッダーやフッター メニュー リスト Top aaa bbb ccc ddd 株価情報.com 12 月 16 日日次リサーチ レポート 内容が個人特有ではない 多くの人で使いまわせる ある程度の有効期間がある ページ毎キャッシュしても有効 サーブレット JSP キャッシュ 画像ファイル ヘッダー フッター 静的コンテンツ キャッシュ キャッシュを利用利用するとすると 通常必要通常必要な処理処理をショートカットショートカットできることにより レスポンスタイムレスポンスタイムの向上 アプリケーションアプリケーション サーバーサーバーの負荷軽減 51

52 なにがキャッシュできるのか? 株価情報サイトの例 ( つづき ) 個人用にカスタマイズされたページでもキャッシュの粒度を見直すことでキャッシング可能 例えば ポートフォリオ表示ページ リクエストがあるたびに データベースへのアクセスが発生し DB が過負荷に 株価情報.com 個人用にカスタマイズされたページ ページ毎キャッシュしても効果なし Top aaa bbb ccc ddd さん 銘柄 XAB YCC 価格 前日比 +1.44% -3.23% 個々の銘柄レベルで データベースへの問い合わせ結果をキャッシュ データベース アクセス ( 負荷の高い処理 ) の絶対数を減らせる ZDF % コマンド キャッシュ GHI % V6New オブジェクト キャッシュ 52

53 キャッシングを行うコンポーネント WAS Dynamic Cache サーブレット /JSP キャッシュ コマンド キャッシュ オブジェクト キャッシュ 外部キャッシュ 基本的にはにはクライアントクライアントに近いほどいほど有効有効 ( セキュアなデータデータの DMZ 内へのへの配置配置に注意 ) サーブレット キャッシュを前段のコンポーネントに配置する機能 LoadBalancer Tier Web Server Tier Presentation Tier Business Logic Tier Load Balancer IHS/ Plug-in Web Container EJB Container Client IHS の AFPA Cache Plug-in ESI Cache Servlet Cache の外部 Cache Servlet Object Cache Cache Command Cache Object Cache Command Cache 53

54 いつキャッシュを無効化するか? Cache と Original が同一である ことが大原則 オリジナルのコンテンツやその元となるデータに変更があった場合は キャッシュを無効化できなくてはいけない AppServer? 古い!? データの更新 Cache WAS 動的キャッシュでサポートされる無効化方法 時間ベース ルール ベース (LRUルール) Javaコーディング com.ibm.websphere.cache.distributedmap インターフェース 尚 グループ単位 (dependency-id) で まとめて無効化も可能 54

55 動的キャッシュの種類 55

56 サーブレット JSP キャッシュ サーブレットや JSP の実行結果を保存 Web コンテナー上にキャッシュを保持 パラメータや Cookie 情報 パス情報などでキャッシュ エントリーを区別 複数の箇所にキャッシュを配置可能 ( 外部キャッシュ ) より前段のコンポーネントにキャッシュを配置することで効果大! Edge Side Include キャッシュで Web サーバー Plug-in 上にキャッシュ可能 IHS 上へもキャッシュも可能 キャッシュの採用が比較的容易 管理コンソールおよび cachecspec.xml での設定で使用可能 キャッシュの無効化をcachespec.xmlのみで行う場合は 既存コンテンツに修正は発生しないキャッシュ ヒットで即レスポンス AppServer IHS Cache Cache ESI キャッシュや外部キャッシュでより前段に配置も可能 56

57 コマンド キャッシュ Command オブジェクトのインスタンスをキャッシュ デザイン パターンの Command Pattern 様々な命令 (Command) をオブジェクトとして表現することにより 要求 ( 命令 ) の呼出し元と要求自身を疎結合にし Command の再利用性を高める WebSphere Command Framework に基づきアプリケーションを実装 Redbook Design and Implement Servlets, JSPs and EJBs for WebSphere Application Server Chapter 4. WebSphere Command Framework Invoker 呼出し元はコマンド オブジェクトの execute を呼び出すのみ 実装ロジックについては知る必要がない <<interface>> Command +execute( ) <<interface>> CacheableCommand すべて Command の親インターフェース CommandCache のためのインターフェース 実際にはこの実装クラスを継承すればよい CacheableCommandImpl * 説明のため簡略化されています 57

58 コマンド キャッシュ実装イメージ Command オブジェクトをキャッシュすると IBM 株価情報検索 検索条件を入力して下さい 銘柄株価銘柄 IBM $90.30 XXX $53.25 実行 SearchPage.html 検索条件 EJB メソッドの結果を Cache -Cache Hit で即レスポンス -Cache Miss の時のみ EJB 要求 DB アクセスが発生 負荷軽減 リソースの有効活用 SearchServlet Command SearchCmd EJB Business Logic Data Result.jsp Cache JDBC IBM 株価検索結果 銘柄 株価 IBM $90.30 XXX $ CommandCache は コマンドの execute() メソッドのコールを intercept 2. キャッシュからコマンド オブジェクトを返せないか チェック 3. コマンド オブジェクトがキャッシュにない場合のみ execute() のロジックを実行 DB 58

59 スループットおよびレスポンスタイムの改善 Trade3 でのパフォーマンス テスト結果 200 株式トレーディング サイトのサンプル アプリケーション ( ページ / 秒 ) ( ミリ秒 ) スループットは サーブレットサーブレット キャッシュキャッシュにより 2.2 倍向上コマンド キャッシュキャッシュによりにより 3.5 倍向上 スループット レスポンス タイム None Servlet Caching Servlet & ESI Caching Command Cac ing Servlet & Command Caching 0 出典 : IBM System Journal Volume 43, Number 2, 2004 WebSphere DynamicCache: Improving J2EE application performance (R. Bakalova, A. Chow, C. Fricano, P. Jain, N. Kodali, D. Poirier, S. Sankaran, and D. Shupp ) 59

60 オブジェクト キャッシュ V6New Distributed Java Object Cache Java オブジェクトのインスタンスを保管 共有する キャッシュ エントリーはオブジェクト キャッシュ インスタンス内に保管 DistributedMapインターフェースを使用してキャッシュ インスタンスにアクセス プログラミングにより Java オブジェクトをキャッシュ可能 同一複製ドメインに所属しているAppServer 間でオブジェクトを共有可能 ビジネス ロジックの実行結果など生成負荷の高いオブジェクトをキャッシュ import javax.naming.initialcontext; import com.ibm.websphere.cache.distributedmap; public ResultBean getresutlbean( String arg1){ InitialContext ic = new InitialContext( ); DistributedMap dmap1 = (DistributedMap)ic.lookup( services/cache/instance1 ); ResultBean res=null; // まずキャッシュを確認 res = dmap1.get(arg1); // キャッシュがなかった場合はビジネスロジックを実行 if(res ==null ){ res = dosomehighcostbackendprocessing(arg1); // キャッシュに保管 dmap1.put( arg1, res); } return res; } CacheInstance1 dmap1.get( bbb ); dmap1.put( aaa,aaaobj); AppServer1 AppServer2 60

61 オブジェクト キャッシングの実装 com.ibm.websphere.cache.distributedmap インターフェース キャッシュ エントリーの保管 void put( somecachekey, someobject) void put( somecachekey, someobject, timetolive, sharingpolicy, dendencyids) timetolive: キャッシュの有効期間を秒数で指定 (int) sharingpolicy : 共有ポリシーを指定 (int) EntryInfo.NOT_SHARED EntryInfo.SHARED_PUSH または EntryInfo.SHARED_PUSH_PULL dependencyids : キャッシュ エントリーに紐付けられたキャッシュ エントリー (java.lang.object[ ]) キャッシュ エントリーの取得 java.lang.object get( somecachekey ) キャッシュ エントリーの無効化 void invalidate( somecachekey ) 61

62 動的キャッシュの設定 62

63 動的キャッシュ構成手順 サーブレット キャッシュ 1. ( オプション ) キャッシュ インスタンスの作成 2. 動的キャッシュ サービスを有効にする 3. cachespec.xmlでキャッシュ内容を定義する 4. ( オプション ) 無効化ロジックのアプリケーションへの作りこみ コマンド キャッシュ 1. WebSphere Commad Frameworkに基づいたアプリケーションの開発 2. ( オプション ) キャッシュ インスタンスの作成 3. 動的キャッシュ サービスを有効にする 4. cachespec.xmlでキャッシュ内容を定義する オブジェクト キャッシュ 1. DistributedMapインターフェースを用いたアプリケーションの開発 2. ( オプション ) キャッシュ インスタンスの作成 3. 動的キャッシュ サービスを有効にする 63

64 キャッシュ インスタンス キャッシュを保持する領域 キャッシュ インスタンス間は互いに影響を与えない キャッシュ インスタンス毎に JNDI 名 キャッシュ サイズ 優先順位 ディスク オフロードの設定が可能 AppServer 間でキャッシュを共用することが可能 AppServer が同一複製ドメインに所属していることが条件 CLUSTER1 複製ドメイン CacheInstance1 AppServer1 AppServer2 AppServer3 CacheInstance2 64

65 キャッシュ インスタンスの種類 ( 参考 ) 2 種類のキャッシュ インスタンス サーブレット キャッシュ インスタンス サーブレット キャッシュ コマンド キャッシュのキャッシュ エントリーを保持する cachespec.xml ファイル内の <cache-instance> エレメントでインスタンスを指定 <cache-instance> を明示的に指定しない場合は デフォルトのキャッシュ インスタンス services/cache/basecache にキャッシュされる オブジェクト キャッシュ インスタンス オブジェクト キャッシュのキャッシュ エントリーを保持する com.ibm.websphere.cache.distributedmap インターフェースまたは com.ibm.websphere. cache.distributedobjectcache を介してキャッシュ インスタンスにアクセス 動的キャッシュを有効にすると services/cache/distributedmap という JNDI 名でデフォルト インスタンスが作成される アプリケーション コード内で キャッシュインスタンスを JNDI 名によりルック アップ 65

66 キャッシュ インスタンスの構成 ( 参考 ) 管理コンソールから設定可能 リソース キャッシュ インスタンス 定義レベルに注意 セル クラスター ノード サーバーのレベルで設定可能 インスタンス名 JNDI 名 キャッシュ サイズ等を設定 66

67 動的キャッシュ サービスの有効化 ( 参考 ) 管理コンソールから動的キャッシングを使用可能に サーバー アプリケーション サーバー < サーバー名 > コンテナー設定 サーバー始動時にサービスを使用可能にする にチェックを入れる 67

68 サーブレット / コマンド キャッシングの設定 キャッシュ ポリシーの作成 cachespec.xml でキャッシュ方針を指定 なにをキャッシュするか どのサーブレット? どのコマンド? なにを元にキャッシュ エントリーを生成するか パラメータ アトリビュート パス セッション情報 ヘッダー情報 ロケール Cookie 情報 いつ無効化するか 時間ベース グループ ベース (dependency-id) ルール ベース (LRU ルール ) Java コーディング (com.ibm.websphere.cache.cache インターフェース ) Dynamic Cache Policy Editor を使用して編集可能 alphaworks で Eclipse Plugin として提供 cachesepc.xml の配置 モジュール レベルでの設定 Web モジュールの WEB-INF ディレクトリ EJB モジュールの METS-INF ディレクトリ グローバル レベルでの設定 <WAS_ROOT> properties ディレクトリ メンテナンスを考慮し モジュールレベルでの設定を推奨 68

69 cachespec.xml の記述 1 ( 参考 ) cache cache エレメント内には <cache-instance> <cache-entry> が含まれる cache-instance name 属性として管理コンソールで設定したキャッシュ インスタンスの JNDI 名を指定 cache-entry 個々のキャッシュ対象の情報を指定するエントリー cache 内の cache-entry はデフォルト キャッシュインスタンスに cache-instance 内の cache-entry は指定のキャッシュ インスタンスにキャッシュされる <cache> <cache-entry> 個々のキャッシュ対象を指定 <class>servlet</class><name>/myservlet1</name> <cache-id> <component id="*" type="parameter"><required>true</required></component><timeout>180</timeout> </cache-id> </cache-entry> <cache-instance name="services/cache/instance1"> キャッシュインスタンスの指定 <cache-entry> 個々のキャッシュ対象を指定 <class>servlet</class><name>/myservlet2</name> <cache-id> <component id="*" type="parameter"><required>false</required></component><timeout>180</timeout> </cache-id> </cache-entry> </cache-instance> </cache> 69

70 cachespec.xml の記述 2 ( 参考 ) class キャッシュ対象のタイプを指定 name <class> servlet command static </class> どのコンテンツをキャッシュするか指定 サーブレット JSPキャッシュ 静的コンテンツの場合 Webモジュール内 : コンテキストルートからの相対パスで指定 <name> myapplication/sample.jsp </name> <name> myapplication/image/logo.gif </name> <WAS_ROOT> properties : フル パスで指定 <name> /myapplication/control/searchservlet </name> コマンド キャッシュの場合 キャッシュ対象オブジェクトのフル クラス名 ( 拡張子.class も付加して指定 ) <name> com.ise.sample.command.updatecmd.class </name> 70

71 cachespec.xml の記述 3 ( 参考 ) sharing-policy 複数 AppServer 間でのキャッシュの共有方法を指定 ( エントリー毎に設定 ) ポリシー shared pushpull notshared sharedpush property AppServer 間での連携 キャッシュの詳細機能の挙動を指定 EdgeCacheable ExternalCache persist-to-disk Memory の利用効率 - 動作 Cache が作成された AppServer でのみ Cache を用いる特定ユーザーが複数回使用するキャッシュに使用デフォルト値 キャッシュのエントリーが作成されると 他の AppServer のキャッシュにエントリーを自動的に配布 各キャッシュにコピーが作成される多くのユーザーに使われ かつヒット率も高いキャッシュに使用 作成したエントリーのキャッシュ ID を他の連携 AppServer にブロードキャスト これにより AppServer は特定のキャッシュ ID に対するエントリーがあらかじめどこに存在するかを判断できる多くのユーザーに使われるけれども それほどヒット率が高くないキャッシュに使用 :EdgeSideIncludeキャッシュ可能か否かを指定 : 外部キャッシュ先を指定 : キャッシュをディスクに書き込み可能か否かを指定 71

72 cachespec.xml の記述 4 ( 参考 ) cacheid WAS がキャッシュに入れたエントリーの判別に用いる ID 複数の CacheID の生成規則を定義可能 Cachespec.xml 内に指定した情報を基にルールベースで作成する com.ibm.websphere.servlet.cache.idgenerator クラスを実装したクラスを用いて Java コーディングによりキャッシュ ID を生成することも可能 cacheid のサブ エレメント component キャッシュ ID の生成に使用される情報を指定 サーブレット :parameter cookie session header locale requesttype など コマンド :method field timeout キャッシュ エントリーの生存時間の絶対時間を指定 inactivity キャッシュ エントリーの生存時間をラスト アクセス時間を元に指定 priority Cache が指定した最大キャッシュ サイズに達した際に LRU ルールに基づいて エントリーをメモリから除去 またはディスク オフロードを行う その際に用いられる優先順位 idgenerator com.ibm.websphere.servlet.cache.idgenerator クラスを実装したクラスを用いて j コーディングによりキャッシュ ID の生成を行う際に指定します 72

73 cachespec.xml の記述 5 ( 参考 ) dependency-id キャッシュをグループ化する際に指定 dependency-id 基本ストリングと component エレメントの値により生成される <dependency-id>companycache <component id= company type= parameter ><required>true</required></component> </dependency-id> invalidation-id cacheid や dependency-id と同様の指定方法 invalidation-id に指定された cacheid または dependency-id が一致したキャッシュは無効化される <invalidation>comapnycache <component id= company type= parameter ><required>true</required></component> </invalidation> Cachespec.xml ファイルの記述の詳細は InfoCenter Cachespec.xml ファイル の記載を参照ください 73

74 動的キャッシュの設定 ( 外部キャッシュ キャッシュの複製 ) 74

75 外部キャッシュ サーブレット キャッシュを前段のコンポーネントに配置可能 より前段でキャッシュ ヒットさせることによりキャッシュ効果アップ 外部キャッシュ先としては以下の2つ WebServer Plugin 上のESIキャッシュ IHS 上の高速応答キャッシュ アクセラレーター (Windows 環境のみ ) IHS cache WebServer Plug-in ESI Processor cache AppServer cache 高速応答キャッシュ アクセラレーター (Windows 環境のみ ) Web サーバー Plugin ESI キャッシュ 75

76 外部キャッシュの設定 ( 参考 ) 1. 外部キャッシュ グループ定義の作成 動的キャッシュ サービス の追加プロパティより設定 2. 外部キャッシュ グループ メンバーの追加 以下の表に従って キャッシュのタイプと配置先を指定 外部キャッシュ ESI キャッシュ IHS AFPA アダプター名 com.ibm.websphere.servlet.cache.esiinvalidatorservlet com.ibm.ws.cache.servlet.afpa アドレス ローカル ホスト AFPA のポート 3. cachespec.xml での定義 キャッシュ エントリー毎に外部キャッシュの可否を設定 4. 各コンポーネントでの定義 76

77 Edge Side Include キャッシュ ( 参考 ) Web サーバー Plugin 内に ESI プロセッサーが存在 WAS 上に DynaCacheESI.ear をインストール 外部キャッシュの設定および plugin-cfg.xml で設定 デフォルト有効 最大キャッシュサイズを KB 単位で指定 <Property Name="ESIEnable" Value="true" /> <Property Name="ESIMaxCacheSize" Value="1024" /> <Property Name="ESIInvalidationMonitor" Value="false" /> 1ESI が有効な場合 全てのリクエストは ESI プロセッサーを経由 IHS WebServer Plug-in ESI Processor 2 キャッシュ ミスの場合は Surrogate-Capability ヘッダーを要求に付加しリクエストを AppServer にフォワード AppServer 4Surrogate-Control ヘッダーの値を元に キャッシュ ID を生成しキャッシュを保管 3AppServer で サーブレット キャッシュが有効かつ cachespec.xml で ESI 可能に指定されている場合 Surrogate-Control ヘッダーを応答として返す 77

78 Edge Side Include キャッシュ ( 参考 ) ESI キャッシュ エントリーの無効化 新規エントリーのために古いキャッシュが無効化される 最も有効期限が近いキャッシュが削除される 有効期限タイムアウト cachespec.xml の timeout タグで指定 静的コンテンツのデフォルトの有効期限は 300 秒 JVM パラメーター -Dcom.ibm.servlet.file.esi.timeOut=60 で変更可能 AppServer から明示的に無効化通知を送る plugin-cfg.xml で ESIInvalidationMonitor を有効に AppServer 上に DynaCacheESI.ear をインストール ESI キャッシュの考慮点 Web サーバーが Thread モデルで稼動するときに有効 キャッシュはプロセス毎に行われ プロセス間では共有されないためメモリーを食いつぶす危険性がある IHS6.0 はスレッド モデルで稼動 1 プロセスのみ起動させる AppServer 上の CacheMonitor.ear からキャッシュ状況を監視可能 78

79 IHS 高速応答キャッシュ アクセラレーター (AFPA) ( 参考 ) 静的コンテンツのキャッシュ Windows 環境および AIX でサポート httpd.conf での設定 動的コンテンツのキャッシュ Windows 環境のみ LoadModule ibm_afpa_module modules/mod_afpa_cache.so AfpaEnable AfpaCache on AfpaLogFile <IHS_ROOT> logs afpalog" V-ECLF 外部キャッシュの定義および httpd.conf での設定 AfpaPluginHost には WAS のホスト名および外部キャッシュグループのメンバー設定のアドレス欄で設定したポートを指定 WAS が複数存在する場合は AfpaPluginHost ディレクティブを複数指定 LoadModule ibm_afpa_module modules/mod_afpa_cache.so AfpaEnable AfpaCache on AfpaLogFile <IHS_ROOT> logs afpalog" V-ECLF # 以下が動的コンテンツのキャッシュに必要な追加設定 LoadModule afpaplugin_module <WASPlugin_ROOT> bin bin afpaplugin20.dll AfpaPluginHost WAS_Hostname1:port AfpaPluginHost WAS_Hostname2:port AFPAに関してはしては AntiVirusが稼動稼動しているしているマシンマシンで実行実行させると OSがハング / クラッシュする可能性可能性があるというがあるという問題問題がありがあり AFPAの設定設定が必要必要な場合場合にはには AntiVirusを導入導入しない 詳細は下記を参照ください WAS サポートページ Hang or crash of Microsoft Windows when running AFPA and when antivirus software is active 79

80 キャッシュの複製 連携 AppServer 間でキャッシュ エントリーを共有 キャッシュのヒット率を向上させ 動的キャッシュがより効果的に 各 AppServerが同一の内部複製ドメインに所属することが前提 内部複製ドメインは動的キャッシュ専用に用意することを推奨 キャッシュ複製タイプ タイプ AppServer 間での連携 Memory の利用効率 動作 共有しない - Cache が作成された AppServer でのみ Cache を用いる特定ユーザーが複数回使用するキャッシュに使用デフォルト値 push のみ キャッシュのエントリーが作成されると 他の AppServer のキャッシュにエントリーとキャッシュ ID を自動的に配布 常に各サーバー上にキャッシュのコピーが作成される 対障害性は高いが 全てのサーバーにキャッシュが配置されているのでリソースを浪費しやすい 多くのユーザーに使われ かつヒット率も高いキャッシュに使用 push と pull の両方 キャッシュが作成されるとキャッシュ ID のみを他の連携 AppServer にブロードキャストを行う これにより AppServer は特定のキャッシュ ID に対するエントリーをあらかじめどの AppServer に取りにいけばよいか または自分で実際に処理を行うべきかを判断できる これにより必要なときにのみキャッシュ複製を各サーバーに配置することが可能になる多くのユーザーで使いまわせるけれども それほどヒット率が高くないキャッシュに使用 80

81 キャッシュの複製の設定 ( 参考 ) 複製ドメインの作成 管理コンソールから作成可能 環境 複製ドメイン 新規作成 レプリカの数は ドメイン全体 を指定 キャッシュ複製タイプの設定 管理コンソール 動的キャッシュ サービス または キャッシュ インスタンス から設定 整合性設定として指定 push 頻度 新規作成 ( 修正 ) されたキャッシュ エントリーを push する前に待機する秒数を指定 81

82 キャッシュのディスク オフロード ディスク オフロード 最大キャッシュ サイズを超えたキャッシュは LRU(Least Recently Used) ルールに従いメモリから削除される ディスク オフロードを設定した場合 メモリから削除されるキャッシュをディスクに保管しておくことが可能 オフロード位置 同一ノードに複数 AppServer が存在する場合には ディスク オフロード位置はそれぞれ別のロケーションを指定する 明示的に指定しない場合 <WAS_ROOT> temp node <serever_name> _dynacache <cachejndiname> 明示的に指定した場合 ( 例 <WAS_ROOT> diskoffload を指定 ) <WAS_ROOT> diskoffload node <server_name> <cachejndiname> ディスクへのフラッシュ サーバーを停止する際に メモリ上のキャッシュを全てディスクに書込むか否かを指定 82

83 キャッシュのモニタリング CacheMonitor.ear のインストール 製品提供のキャッシュ管理用アプリケーション 基本キャッシュ統計情報 キャッシュ サイズ キャッシュ ヒット数 キャッシュ ミス数 除去されたキャッシュ数 etc キャッシュ エントリーのモニタリング 無効化 依存性 ID 別キャッシュ エントリーのモニタリング ESIキャッシュ統計 外部キャッシュ内のデータ ディスク オフロードされたデータのモニター 無効化 キャッシュ ポリシーの確認 83

84 2. WAS トポロジー設計 2-1 パフォーマンス 拡張性設計 2-2 可用性 障害設計 2-3 セキュリティーに関する設計 84

85 パフォーマンス要件を満たすには パフォーマンスを向上させるには 高スペックのマシンを使用する?? マシンを何十台も使用する?? 存在するする資源資源を有効有効に使用 無駄に資源資源を使用使用しない 85

86 垂直クラスター 水平クラスター 86

87 水平クラスター 垂直クラスター 垂直クラスター構成 Node1 Application Server Application Server Application Server 水平クラスター構成 Node1 Node2 NodeN Application Server Application Server Application Server 1 台のマシンに複数のアプリケーション サーバープロセスが稼動 複数のマシンにそれぞれアプリケーション サーバープロセスが稼動 87

88 水平クラスターによるパフォーマンスの向上 WAS V6 Performance Report (p.13) より reqs/second Trade EJB Horizontal Scaling 1030 V5.1 V node 2 nodes 3 nodes 4 nodes Scale factor Clients CPU% - IHS DMGR/JMS serv Nodes DB R/T ms System configuration Workload: TradeEJBSync, Dynacache cmd caching, 2000 users/5000 quotes, 50 clients per driver Methodology: As each node was added, one client driver was added with an additional 50 clients Driver: Workload drivers (4), each eserver BladeCenter HS20, 2 x 3.2 GHz Xeon, Red Hat Enterprise Linux, release 8.0 DMGR, IHS, cluster members: eserver BladeCenter HS20, 2 x 3.2 GHz Xeon, Windows 2003 Server Enterprise Edition Database: xseries 360, 4 x 2.0 GHz Xeon, Windows 2003 Server Enterprise Edition, 8 GB RAM, DB2 v8.2, V5.1: DB2 JDBC Provider (XA); V6.0: DB2 Universal JCC DriverXA, Type 4 ノードの増加とともにほとんどリニアにパフォーマンスが向上 垂直クラスターのパフォーマンス検証結果については WAS V5.1 の結果になりますが 下記のワークショップ資料の記載を参照ください WAS5.1 インフラ構成の心得 - 第 2 回トポロジー設計その 1 ( 垂直クラスターによるパフォーマンス検証 p.24-27) 88

89 89 水平クラスターと垂直クラスター まとめ必ずしもずしもずしもずしもパフォーマンスパフォーマンスパフォーマンスパフォーマンスが向上向上向上向上するとはするとはするとはするとは限らならならならない ノードノードノードノード増加分増加分増加分増加分リニアリニアリニアリニアにパフォーマンスパフォーマンスパフォーマンスパフォーマンス向上向上向上向上パフォーマンスパフォーマンスパフォーマンスパフォーマンスプロセスプロセスプロセスプロセス障害障害障害障害にのみにのみにのみにのみ対応可能対応可能対応可能対応可能ノードノードノードノード障害障害障害障害に対応可能対応可能対応可能対応可能耐障害性耐障害性耐障害性耐障害性管理対象管理対象管理対象管理対象ノードノードノードノードは少ないないないない管理対象管理対象管理対象管理対象ノードノードノードノードが増加増加増加増加運用管理運用管理運用管理運用管理複数複数複数複数プロセスプロセスプロセスプロセスがそれぞれがそれぞれがそれぞれがそれぞれメモリーメモリーメモリーメモリー領域領域領域領域を使用使用使用使用することによりることによりることによりることにより メモリーリソースメモリーリソースメモリーリソースメモリーリソースを十分利用十分利用十分利用十分利用するするするすることができることができることができることができる場合場合場合場合があるがあるがあるがある 逆にメモリーリソースメモリーリソースメモリーリソースメモリーリソースの枯渇枯渇枯渇枯渇に注意注意注意注意 1 プロセスプロセスプロセスプロセスで使用使用使用使用できるできるできるできるメモリーメモリーメモリーメモリー領域領域領域領域は限られてられてられてられているのでいるのでいるのでいるので 十分十分十分十分メモリーリソースメモリーリソースメモリーリソースメモリーリソースを使用使用使用使用できないできないできないできない場合場合場合場合があるがあるがあるがある メモリーリソースメモリーリソースメモリーリソースメモリーリソースの使用使用使用使用垂直垂直垂直垂直クラスタークラスタークラスタークラスター水平水平水平水平クラスタークラスタークラスタークラスター水平水平水平水平クラスタークラスタークラスタークラスターと垂直垂直垂直垂直クラスタークラスタークラスタークラスターを合わせてわせてわせてわせて使用可能使用可能使用可能使用可能 ノードノードノードノード障害対策障害対策障害対策障害対策 パフォーマンスパフォーマンスパフォーマンスパフォーマンス対策対策対策対策としてとしてとしてとして基本的基本的基本的基本的に水平水平水平水平クラスタークラスタークラスタークラスターを使用使用使用使用 さらにさらにさらにさらにノードノードノードノード内のプロセスプロセスプロセスプロセス障害障害障害障害に対応対応対応対応したいしたいしたいしたい場合場合場合場合にはにはにはには垂直垂直垂直垂直クラスタークラスタークラスタークラスターも使用使用使用使用

90 アプリケーションの配置 90

91 91 アプリケーションの配置 AppServer アプリケーション 1 Node1 アプリケーション 2 AppServer アプリケーション 1 Node2 アプリケーション 2 AppServer アプリケーション 1 Node1 AppServer アプリケーション 2 AppServer アプリケーション 1 Node2 AppServer アプリケーション 2 同一サーバー上に配置アプリ毎にサーバー作成クラスタークラスタークラスタークラスタークラスタークラスタークラスタークラスタークラスタークラスタークラスタークラスター アプリケーションアプリケーションアプリケーションアプリケーションごとにごとにごとにごとにアプリケーションアプリケーションアプリケーションアプリケーション サーバーサーバーサーバーサーバーを分けることによりけることによりけることによりけることにより ヒープサイズヒープサイズヒープサイズヒープサイズやキューイングネットワークキューイングネットワークキューイングネットワークキューイングネットワークの設定設定設定設定を分けることができるけることができるけることができるけることができる これによりこれによりこれによりこれにより 片方片方片方片方のアプリケーションアプリケーションアプリケーションアプリケーションにリソースリソースリソースリソースが占有占有占有占有されてしまうようなことはないされてしまうようなことはないされてしまうようなことはないされてしまうようなことはない パフォーマンスパフォーマンスパフォーマンスパフォーマンス要件要件要件要件だけでなくだけでなくだけでなくだけでなく 運用要件運用要件運用要件運用要件にもにもにもにも大きくきくきくきく関連関連関連関連するするするする

92 92 アプリケーションの配置パフォーマンスパフォーマンスパフォーマンスパフォーマンス設定設定設定設定などをそれぞれのなどをそれぞれのなどをそれぞれのなどをそれぞれのアプアプアプアプリケーションリケーションリケーションリケーションに応じたじたじたじた値に設定設定設定設定できるできるできるできるパフォーマンスパフォーマンスパフォーマンスパフォーマンス設定設定設定設定などはなどはなどはなどは 2 つのつのつのつのアプリアプリアプリアプリケーションケーションケーションケーションの合計合計合計合計となるとなるとなるとなるサーバーサーバーサーバーサーバー設定設定設定設定各アプリケーションアプリケーションアプリケーションアプリケーションごとにごとにごとにごとにメンテナンスメンテナンスメンテナンスメンテナンスを行うことができるうことができるうことができるうことができるアプリケーションアプリケーションアプリケーションアプリケーション サーバーサーバーサーバーサーバーを停止停止停止停止してのしてのしてのしてのメンテナンスメンテナンスメンテナンスメンテナンスは全アプリケーションアプリケーションアプリケーションアプリケーションに影響するするするする運用運用運用運用別ファイルファイルファイルファイルに出力出力出力出力されるされるされるされる同一同一同一同一ファイルファイルファイルファイルに出力出力出力出力されるされるされるされるログログログログ片側片側片側片側のアプリアプリアプリアプリ障害時障害時障害時障害時に他のアプリアプリアプリアプリは停止停止停止停止されないためされないためされないためされないため パフォーマンスパフォーマンスパフォーマンスパフォーマンスは下がらながらながらながらない片側片側片側片側のアプリアプリアプリアプリ障害時障害時障害時障害時に他のアプリアプリアプリアプリも停止されるためされるためされるためされるため パフォーマンスパフォーマンスパフォーマンスパフォーマンスがダウンダウンダウンダウンするするするする障害時障害時障害時障害時の影響影響影響影響アプリケーションアプリケーションアプリケーションアプリケーション サーバーサーバーサーバーサーバーを増やしたやしたやしたやした分だけメモリメモリメモリメモリが多く必要必要必要必要になるになるになるになるあまりあまりあまりあまり増えないえないえないえない必要必要必要必要リソースリソースリソースリソースアプリケーションアプリケーションアプリケーションアプリケーション毎にサーバーサーバーサーバーサーバー作成作成作成作成同一同一同一同一サーバーサーバーサーバーサーバーに配置配置配置配置 マシンリソースに余裕がない場合は同一サーバーに配置する アプリケーションごとにメンテナンス時間が異なるなど 運用が異なる場合には アプリケーション毎にサーバーを作成する アプリケーション サーバー障害時のパフォーマンスダウンを避けたい場合はアプリケーション毎にサーバーを作成する

93 キャッシュの利用 93

94 キャッシュを最大限に行う構成 照会系の処理はより前段でキャッシュ Hit させ レスポンスタイムの向上 また 後段のリソース使用率を抑える IHS Cache Application Server Cache LB 複製 IHS Cache Application Server Cache 静的コンテンツのキャッシュ外部キャッシュ 動的キャッシュキャッシュ複製 POST リクエストをキャッシュ可能キャッシュ無効化を任意のタイミングでできるセッションや Cookie の情報を元にキャッシュ可能キャッシュのグループ化が可能 94

95 その他のパフォーマンスに影響する項目 95

96 パフォーマンスに影響する事項 SSL SSL ハンドシェークは比較的パフォーマンスへの影響が大きい どのコンポーネントまで暗号化するか要検討 ( 後述 ) HTTP セッション HTTP セッションのサイズ 数 パーシスタンスの有無 パーシスタンス方法がパフォーマンスに影響 ( 前述 ) EJB コンテナーの配置 EJB クライアントと EJB コンテナーを同一のアプリケーション サーバー上で稼動させることにより ローカルインターフェースを使用することができパフォーマンス向上 DB 接続 DB2 との接続に使用可能なドライバーは複数あり Universal ドライバー Type4 接続がパフォーマンスが良い ( 次ページ参照 ) ここでは トポロジートポロジーに影響影響するする項目項目を紹介紹介していますしています キューイングネットワークや JVM ヒープなどなど 各コンポーネントコンポーネントのチューニングチューニングの詳細はパフォーマンスパフォーマンス チューニングチューニングの章を参照参照してくださいしてください 96

97 DB2 のドライバーのパフォーマンス比較 WAS V6 Performance Report (p.40) より JCC versus CLI Comparison reqs/second DB2 Legacy CLIbased Type 2 JDBC Driver (XA) DB2 Legacy CLIbased Type 2 JDBC Driver (XA) TP_MON_NAME set to WAS DB2 Universal JDBC Driver Type 2 Provider (XA) DB2 Universal JDBC Driver Type 4 Provider (XA) CPU% CPU% DB R/T ms System configuration Workload: TradeEJBSync, port 9080, no dynacache, 50 clients Driver: Workload driver on (2) IBM x330 P3 Xeon, 2 x 1266 MHz, Red Hat Enterprise Linux, rel 8.0 SUT: pseries p630, 4 x 1.4 GHz, 8GB RAM, AIX 5.2 mr 1 + APAR IY44183 Database: xseries 365, 4 x 3.0 GHz Xeon, 8 GB, Windows 2003 Server Enterprise Edition, DB2 v8.2 Legacy ドライバーより Universal ドライバーの方が 1.5 倍程度スループットが向上 Universal ドライバーは Type2 よりも Type4 の方が若干パフォーマンスが良い ( この違いはネットワーク通信量に依存していると考えられる 尚 DB がローカルの場合は 通信量に関わらず Type2 の方がパフォーマンスが良いと考えられる ) 97

98 64bit 対応 64bit 版サポート OS 6.0.1~ 6.0.2~ 64bit 版をサポートサポートする OS HP-UX 11iv2, Redhat Linux AS/ES 3.0/4.0, SUSE Linux 9, Windows Server 2003 Enterprise AIX 5L 5.2/5.3, Windows Server 2003 x64 Editions サポート OS バージョン プロセッサーの詳細は下記のサポートページを参照ください WAS サポートページ System requirements-supported hardware and software 64bit 版 WAS の使用によるパフォーマンス効果 WAS V6 Performance Report (p.68) より 32-bit versus 64-bit Performance Comparison Trade アプリケーションでは 64bit 版のほうが 5% 程度スループットが向上 JIT optimization のパフォーマンス向上の効果 大きなデータを扱う場合には より効果が大きいと思われる reqs/second bit bit CP U% R/T ms S ystem Configuration Workload: TradeEJBSync, port 9080, 50 clients Driver: Workload driver on (3) IBM NetVista 2.4Ghz Pentium 4, 1GB RAM, SLES 9 SUT: Intel 64-bit Xeon MP with 8MB L3 cache, 4 x 3.0 GHz, HT Enabled, 8GB RAM, SLES 9.0 x86_64 version Database: IBM xseries 360, 4 x 2GHz Xeon (with hyper-threading on), 3.5GB RAM, SLES 8.0, DB2 v8.2 DB2 Universal JCC DriverXA Type 4 98

99 2. WAS トポロジー設計 2-1 パフォーマンス 拡張性設計 2-2 可用性 障害設計 2-3 セキュリティーに関する設計 99

100 障害の種類 停止の要因 計画停止 障害停止 ハードウェア障害 ソフトウェア障害 ( プロダクトやアプリケーションのバグなどによるプロセスダウンやハング ) 設備系障害 ( 電源障害 ) 人為的過失 ( オペレーションミス ) 自然災害による障害 ( 火災や地震 ) ネットワーク障害 悪意による人為的障害 ( セキュリティー攻撃 ) サービス停止停止によるによる損失損失と可用性向上可用性向上に必要必要な費用費用から各障害発生時にどのくらいのにどのくらいの時間時間で復旧復旧するかのサービスレベル定義定義が重要 100

101 障害対策レベル バックアップ リストア 手作業による対策 H/W 障害では新規のH/Wに対してリストア S/W 障害では更新前の状態にリストア H/Wコンポーネントの二重化 H/W 障害の対応 RAIDディスク Networkの二重化 システムの二重化 多重化 障害中は縮退運転でサービスを提供 WAS IHSはクラスターで多重化をサポート HA 構成 障害中はスタンバイ機がサービスを提供 切り替え時は一時的にサービス停止 プロセスの二重化二重化だけでなくだけでなく データの二重化二重化も検討検討することがすることが重要 ( 業務データデータ セッションセッション データデータ メッセージング エンジンエンジン データソースデータソース トランザクション ログログ 構成情報 ) LoadBalancer や DB など多重化できないコンポーネントは HA 構成 製品が提供する HA 機能と HACMP などの S/W で提供されるものがある サイトの二重化 自然災害などによるサイトダウンへの対策 101

102 可用性向上のポイント Single Point of Failure を無くす 二重化する システム全体で考える ユーザーから見た可用性の向上 サービスの停止時間が短くなるように 障害検知と障害回復時間の短縮 自動障害検知 自動障害回復 計画停止の有無の考慮 24 時間 365 日運用の場合 アプリケーション更新 構成変更 Fix 適用などを無停止で行う方法 の検討が必要 24 時間 365 日運用でない場合 耐障害性を検討することは重要 102

103 各コンポーネントにおける障害設計方針 (1/2) Dispatcher Web サーバー Web コンテナー EJB コンテナー DB サーバー Deployment Manager Node Agent 障害設計方針 HA 機能を使用使用したした二重化多重化障害検知 切り離し 復帰復帰は前段前段の負荷分散装置で対応対応する WAS クラスターによるによる多重化 WAS クラスターによるによる多重化 HACMP や DB のクラスタークラスター構成構成を使用使用した二重化 OS のデーモンデーモンとしてとして登録または HACMP を使用使用したした二重化 OS のデーモンデーモンとしてとして登録 障害発生時の挙動 待機系に切り替え縮退してしてサービスサービスを継続継続するその間に障害発生側障害発生側の復帰処理復帰処理を行う縮退してしてサービスサービスを継続継続するその間に障害発生側障害発生側の復帰処理復帰処理を行うプロセス障害障害の場合場合は Node Agent が再始動再始動を行う縮退してしてサービスサービスを継続継続するその間に障害発生側障害発生側の復帰処理復帰処理を行うプロセス障害障害の場合場合は Node Agent が再始動再始動を行う待機系に切り替え OS が障害障害を検知検知し 再始動再始動を行うまたは待機系に切り替え OS が障害障害を検知検知し 再始動再始動を行う 103

104 104 各コンポーネントにおける障害設計方針 (2/2) 他のクラスタークラスタークラスタークラスター メンバーメンバーメンバーメンバーにフェイルフェイルフェイルフェイル オーバーオーバーオーバーオーバー WAS WAS WAS WAS クラスタークラスタークラスタークラスターと HA HA HA HA マネージャーマネージャーマネージャーマネージャーによるによるによるによるフェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバー WAS WAS WAS WAS 組み込みメッセーメッセーメッセーメッセージングジングジングジング ( メッセージングメッセージングメッセージングメッセージング エンジンエンジンエンジンエンジン ) 他のクラスタークラスタークラスタークラスター メンバーメンバーメンバーメンバーにフェイルフェイルフェイルフェイル オーバーオーバーオーバーオーバー WAS WAS WAS WAS クラスタークラスタークラスタークラスターと HA HA HA HA マネージャーマネージャーマネージャーマネージャーによるによるによるによるフェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバー WAS WAS WAS WAS トランザクショントランザクショントランザクショントランザクション マネージャーネージャーネージャーネージャー待機系待機系待機系待機系に切り替え製品製品製品製品の HA HA HA HA 機能機能機能機能を使用使用使用使用 またはまたはまたはまたは負荷分散負荷分散負荷分散負荷分散でのでのでのでの割り振り Firewall Firewall Firewall Firewall 待機系待機系待機系待機系に切り替えまたはえまたはえまたはえまたは割り振り変更変更変更変更 HACMP HACMP HACMP HACMP や マスターマスターマスターマスター スレーブスレーブスレーブスレーブ構成構成構成構成を使用してしてしてして負荷分散負荷分散負荷分散負荷分散でのでのでのでの割り振り LDAP LDAP LDAP LDAP サーバーサーバーサーバーサーバー待機系待機系待機系待機系に切り替え HACMP HACMP HACMP HACMP などのなどのなどのなどの DB DB DB DB のクラスタークラスタークラスタークラスター構成構成構成構成を使用したしたしたした二重化二重化二重化二重化 DB DB DB DB サーバーサーバーサーバーサーバー待機系待機系待機系待機系に切り替え HACMP HACMP HACMP HACMP や MQ MQ MQ MQ クラスタークラスタークラスタークラスター構成構成構成構成を使用使用使用使用したしたしたした二重化二重化二重化二重化 MQ MQ MQ MQ サーバーサーバーサーバーサーバー障害発生時障害発生時障害発生時障害発生時の挙動挙動挙動挙動障害設計方針障害設計方針障害設計方針障害設計方針

105 105 障害検知と切り替えの時間 (1/2) アプリケーションアプリケーションアプリケーションアプリケーションに影響影響影響影響なしなしなしなしアプリケーションアプリケーションアプリケーションアプリケーションに影響影響影響影響なしなしなしなしアプリケーションアプリケーションアプリケーションアプリケーション エラーエラーエラーエラーが返るエラーエラーエラーエラーは返らないらないらないらない (* (* (* (*3) エラーエラーエラーエラーは返らないらないらないらない (* (* (* (*3) 障害検知障害検知障害検知障害検知するまでのするまでのするまでのするまでの間のリクエストリクエストリクエストリクエストは サーサーサーサーバーバーバーバーが見つからないつからないつからないつからない旨のエラーエラーエラーエラーが返るタイミングタイミングタイミングタイミングによってはによってはによってはによってはエラーエラーエラーエラーが返る (* (* (* (*1) 障害時障害時障害時障害時のユーザーユーザーユーザーユーザーへのへのへのへの影響度影響度影響度影響度再起動再起動再起動再起動するするするする時間時間時間時間 OS OS OS OS のデーモンデーモンデーモンデーモンの場合場合場合場合瞬時瞬時瞬時瞬時 Node Agent Node Agent Node Agent Node Agent 構成構成構成構成や製品製品製品製品の機能機能機能機能に依存依存依存依存するがるがるがるが 数十秒数十秒数十秒数十秒からからからから数分程度数分程度数分程度数分程度クラスタークラスタークラスタークラスター製品製品製品製品に依存依存依存依存するがするがするがするが 数秒程度数秒程度数秒程度数秒程度 DB DB DB DB サーバーサーバーサーバーサーバー 数秒程度数秒程度数秒程度数秒程度 秒 4 Dispatcher Dispatcher Dispatcher Dispatcher 再起動再起動再起動再起動するするするする時間時間時間時間 OS OS OS OS のデーモンデーモンデーモンデーモンの場合場合場合場合瞬時瞬時瞬時瞬時 Deployment Deployment Deployment Deployment Manager Manager Manager Manager 瞬時瞬時瞬時瞬時瞬時瞬時瞬時瞬時 (* (* (* (*2) Web Web Web Web コンテナーコンテナーコンテナーコンテナー瞬時瞬時瞬時瞬時瞬時瞬時瞬時瞬時 (* (* (* (*2) EJB EJB EJB EJB コンテナーコンテナーコンテナーコンテナー瞬時瞬時瞬時瞬時デフォルトデフォルトデフォルトデフォルト約 7 秒 ( 負荷分散装置負荷分散装置負荷分散装置負荷分散装置でのでのでのでの障害検知障害検知障害検知障害検知 ) Web Web Web Web サーバーサーバーサーバーサーバー切り替え時間時間時間時間障害検知時間障害検知時間障害検知時間障害検知時間 ( ネットワークネットワークネットワークネットワーク障害除障害除障害除障害除く ) (*1) バックアップ機に切り替わった直後のリクエストは バックエンド サーバーへのヘルスチェックが終了しないうちから割り振りを開始してしまうため 保障されません (*2)LoadBalancer による障害検知を行った場合には約 7 秒 (*3)LoadBalancer による障害検知を行っている場合には検知するまでの間エラーが返る

106 106 障害検知と切り替えの時間 (2/2) 新規新規新規新規トランザクショントランザクショントランザクショントランザクションは他のクラスターメンクラスターメンクラスターメンクラスターメンバーバーバーバーで処理処理処理処理を行うためうためうためうためエラーエラーエラーエラーは返らないらないらないらないトランザクショントランザクショントランザクショントランザクション マネージャーマネージャーマネージャーマネージャーの起動時間起動時間起動時間起動時間 ( トランザクショントランザクショントランザクショントランザクション量に依存依存依存依存 ) 数秒程度数秒程度数秒程度数秒程度即時即時即時即時 WAS WAS WAS WAS トランザクトランザクトランザクトランザクションションションション マネーマネーマネーマネージャージャージャージャーパーティショニングパーティショニングパーティショニングパーティショニング構成構成構成構成を使用使用使用使用の場合場合場合場合は エラーラーラーラーは返らないらないらないらない シングルシングルシングルシングル構成構成構成構成の場合場合場合場合はエラーエラーエラーエラーが返るメッセージングメッセージングメッセージングメッセージング エンジンエンジンエンジンエンジンの起動時間動時間動時間動時間数十秒程度数十秒程度数十秒程度数十秒程度即時即時即時即時 WAS WAS WAS WAS 組み込みメッセージングメッセージングメッセージングメッセージング ( メッセージンメッセージンメッセージンメッセージング エンジンエンジンエンジンエンジン ) アプリケーションアプリケーションアプリケーションアプリケーション エラーエラーエラーエラーが返る製品製品製品製品の HA HA HA HA 機能機能機能機能に依存依存依存依存製品製品製品製品の HA HA HA HA 機能機能機能機能に依存依存依存依存 Firewall Firewall Firewall Firewall 認証認証認証認証 認可認可認可認可が必要必要必要必要な場合場合場合場合 アプリケーションアプリケーションアプリケーションアプリケーション エラーエラーエラーエラーが返る MQ MQ MQ MQ アクセスアクセスアクセスアクセスが必要必要必要必要な場合場合場合場合 アプリケーションアプリケーションアプリケーションアプリケーション エラーエラーエラーエラーが返る DB DB DB DB アクセスアクセスアクセスアクセスが必要必要必要必要な場合場合場合場合 アプリケーションアプリケーションアプリケーションアプリケーション エラーエラーエラーエラーが返る障害時障害時障害時障害時のユーザーユーザーユーザーユーザーへのへのへのへの影響度影響度影響度影響度構成構成構成構成や製品製品製品製品の機能機能機能機能に依存依存依存依存するがるがるがるが 数十秒数十秒数十秒数十秒からからからから数分程度数分程度数分程度数分程度クラスタークラスタークラスタークラスター製品製品製品製品またはまたはまたはまたは負荷分散装置負荷分散装置負荷分散装置負荷分散装置の障害障害障害障害検知検知検知検知に依存依存依存依存 LDAP LDAP LDAP LDAP サーバーサーバーサーバーサーバー構成構成構成構成や製品製品製品製品の機能機能機能機能に依存依存依存依存するがるがるがるが 数十秒数十秒数十秒数十秒からからからから数分程度数分程度数分程度数分程度クラスタークラスタークラスタークラスター製品製品製品製品に依存依存依存依存するがするがするがするが 数秒程度数秒程度数秒程度数秒程度 DB DB DB DB サーバーサーバーサーバーサーバー構成構成構成構成や製品製品製品製品の機能機能機能機能に依存依存依存依存するがるがるがるが 数十秒数十秒数十秒数十秒からからからから数分程度数分程度数分程度数分程度クラスタークラスタークラスタークラスター製品製品製品製品に依存依存依存依存するがするがするがするが 数秒程度数秒程度数秒程度数秒程度 MQ MQ MQ MQ サーバーサーバーサーバーサーバー切り替え時間時間時間時間障害検知時間障害検知時間障害検知時間障害検知時間 ( ネットワークネットワークネットワークネットワーク障害除障害除障害除障害除く )

107 WAS 基本コンポーネントの配置 107

108 Deployment Manager の配置箇所 アプリケーション サーバーと同一筐体にすべきか別筐体にすべきか Node1 同一筐体の場合 Deployment Manager 同期 Node Agent Application Application Server Server マスター構成ファイル 構成ファイル 同期 Node2 Node Agent Application Application Server Server セル 構成ファイル 108

109 Deployment Manager の配置箇所 追加のマシン アプリケーション サーバーサーバーと同一筐体 必要なし アプリケーション サーバーサーバーと別筐体 必要あり S/W ライセンス 必要なし 必要あり システム リソース Deployment Manager の分 WAS 使用量がへる (*1) 影響なし Deployment Manager はアプリケーション サーバーと同一筐体に配置しても別筐体に配置してもよい 管理サーバーでありマスター構成ファイルを保持していることから コスト面で問題が無いのであれば 専用マシンを用意して別筐体に配置することが推奨される WAS V6 では Deployment Manager の HACMP などのクラスタリング SW 上での稼動もサポートされる (*1) 同一筐体に配置しても Deployment Manager を停止しておくことでリソースの使用を抑えることもできる アプリケーションの更新や構成の変更 Tivoli Performance Viewer でのパフォーマンス モニターにおいて Deployment Manager の起動が必要になります WAS V6 からは EJB WLM に関して ルーティングテーブルの更新は HA マネージャーが行いますので Deployment Manager の起動の必要はありません 109

110 Node Agent の役割 各ノードノードの構成構成 アプリケーションアプリケーション情報情報の管理 構成情報やアプリケーションの変更を行った場合は ノード エージェントとデプロイメント マネージャー間の同期が必要 Tivoli Performance Viewer での各ノードのパフォーマンス データの取得のために必要 LSD (Location Service Daemon) の稼動 アプリケーション サーバーの起動時には ノード エージェントの起動が必要 起動後の ノード エージェントの停止は影響なし EJB リクエストにおいては 少なくともセル内で 1 つの Node Agent が起動している必要あり アプリケーション サーバーサーバーのモニター アプリケーション サーバーのプロセス障害を定期的にモニターし ダウンしている場合には 自動的に再起動 ノード エージェントエージェントはアプリケーションアプリケーション サーバーサーバーのモニターモニターや EJB リクエストの割り振りにりに影響影響するのでするので 通常起動通常起動しておくことをしておくことを推奨ただし ダウンダウンしても EJBを使用使用しないしない場合場合にはには ユーザーユーザー サービスサービスにはには影響影響しない 110

111 Node Agent による WAS プロセス監視 Node Agent はアプリケーション サーバーを監視し 再始動を行う 設定箇所 [ サーバー ] [ アプリケーション サーバー ] [ サーバー インフラストラクチャー ] [Java およびプロセス管理 ] [ プロセス定義 ] [ モニター ポリシー ] 設定パラメータ 始動の最大試行回数 ( デフォルト :3 回 ) ここで設定した回数だけアプリケーション サーバーの起動を試みます Ping 間隔 ( デフォルト :60 秒 ) Node Agent がアプリケーション サーバーを監視する周期 Ping タイムアウト ( デフォルト :300 秒 ) アプリケーション サーバーからの応答をこの設定時間だけ待ち 応答が無い場合は障害とみなす 自動再始動 ( デフォルト :ON) Node Agent によるプロセス監視を行うかどうか ノード再始動状態 ( デフォルト :STOPPED) ノード再始動後のアプリケーション サーバーのステータス 111

112 1:1 構成と 1:N 構成 112

113 1:1 構成と 1:N 構成 1:1 構成とは Web サーバーから WAS への割り振りが 1:1 にマッピング WAS の障害検知とリクエストの割り振りは負荷分散装置で実施 ただし 負荷分散装置の機能に依存 負荷分散装置からのヘルスチェックとして WAS 上のアプリケーションを使用するとこで サブシステムの障害まで検知可能 ただし 負荷分散装置の機能に依存ヘルスチェック Web Application Server DB MQ などのサブシステム 負荷分散装置 クライアントからのリクエスト Web Application Server DB MQ などのサブシステム 113

114 1:1 構成と 1:N 構成 1:N 構成とは WebサーバーからWASへの割り振りが1:N( たすきがけ ) になる (WASクラスター構成時のデフォルト) WASの障害検知とリクエストの割り振りはWebサーバー Pluginが実施 負荷分散装置は Web サーバーの障害検知まで Web Application Server DB MQ などのサブシステム 負荷分散装置 クライアントからのリクエスト Web Application Server DB MQ などのサブシステム 114

115 Web サーバー Plugin による障害検知時の考慮点 (1/2) Web サーバー Plugin は WAS の障害は検知できるが アプリケーションやサブシステムの障害を検知することはできない 負荷分散装置からヘルスチェックサーブレットに対してリクエストを投げても 割り振りが行われるためどこで障害が発生したか分からない 負荷分散装置は Web サーバーの障害検知まで Web Application Server DB MQ などのサブシステム WAS 障害は検知できる 負荷分散装置 Application Server DB MQ などのサブシステム Web Application DB MQなどのからのこの障害は Server アプリ サブシステムリクエスト クライアントからの 検知できない 115

116 Web サーバー Plugin による障害検知時の考慮点 (2/2) アプリケーションやサブシステムの障害が発生したサーバーに多量のリクエストが滞留してしまう IHS の MaxClients 値のコネクションが障害サーバーと生成されてしまい IHS がリクエストを受け付けられなくなる デフォルトでは WAS とのコネクション数と関係なくラウンドロビンで割り振る Web Application Server DB MQ などのサブシステム 負荷分散装置 Application Server DB MQ などのサブシステム Web Application DB MQなどのからのこの障害は Server アプリ サブシステムリクエスト クライアントからの 検知できない アプリケーションやサブシステムサブシステムの障害障害の検知検知と障害障害サーバーサーバーの切り離しがしが必要 Web サーバー Pluginのプロパティープロパティーで最大接続数最大接続数を設定設定することですることで サイトサイトの全面全面ダウンダウンは回避可能 116

117 1:1 構成と 1:N 構成 障害検知の範囲障害検知時間 セッション アフィニティーロールアウト アップデートアップデート定期 / 緊急時メンテナンス片肺運転について初期設定時の注意 1:1 構成 Web サーバー WAS サブシステサブシステムは負荷分散装置負荷分散装置に依存負荷分散装置に依存 負荷分散装置で行う負荷分散装置が WAS のダウンダウン検知可能検知可能であれば クライアントクライアントにエラーエラーが返る可能性がある負荷分散装置によるによる制御 GenPluginCfg コマンドを使用 ( または 手動編集 ) して Web サーバー Plugin 構成ファイルを生成生成するする必要必要がある 1:N 構成 負荷分散装置は Web サーバーまでまで検知可能 Web サーバー Plugin は WAS まで検知可能検知可能だがアプリケーションやサブシステサブシステムの検知検知はできない Web サーバー障害時障害時は同左 WAS 障害時は Plugin が即時即時に検知 Web サーバー Plugin で行うクライアントにエラーエラーを返す事無事無く アプリケーションの更新更新が可能 Web サーバー Plugin 構成ファイルファイルを手動編集手動編集したものを準備準備しておきしておき置き換えデフォルト構成構成でありであり 管理管理コンソールコンソールから Web サーバー Plugin 構成ファイルファイルの生成生成 伝播が可能 ロールアウト アップデートアップデートを使用使用するなど WASの障害検知障害検知を即時即時に行わなければならない場合場合は 1:N 構成を使用使用 ただし 1:N 構成の場合場合は アプリケーションアプリケーションやサブシステムの障害検知障害検知は別途検討別途検討するする必要必要があるがある 負荷分散装置から WASのサブシステムサブシステムまでのまでの障害検知障害検知を行う場合場合にはには 1:1 構成を使用 117

118 EJB コンテナーの障害対応 118

119 Backup Cluster とは (1/2) ミラーリングされたクラスター EJB 要求のみのフェイルオーバーをサポート 2 つの Cell に同一名の Cluster を作成 2 つの Cluster は同じアプリケーション名を持っていなければいけない 2 つの Cluster が互いに相手の Backup Cluster となるように構成 Core Group Bridge の作成 HTTP Server プラグイン HTTP Server プラグイン Core Group Bridge HTTP Server プラグイン HTTP Server プラグイン Cell1 WebCluster Cell2 WebCluster Web コンテナー Web コンテナー Web コンテナー Web コンテナー Application Server Application Server Application Server Application Server EJBCluster EJBCluster EJB コンテナー EJB コンテナー EJB コンテナー EJB コンテナー Application Server Application Server Application Server Application Server 119

120 Backup Cluster とは (2/2) 全てのクラスター メンバーが EJB 要求を処理できなくなった際に EJB クラスターの Failover を提供 全クラスター メンバーのダウンを検知し自動的にフェイルオーバーを行うクラスター メンバー復旧時には自動でフェイルバック ( 引き戻し ) が行われる HTTP Server プラグイン HTTP Server プラグイン Core Group Bridge HTTP Server プラグイン HTTP Server プラグイン Cell1 WebCluster Cell2 WebCluster Web コンテナー Web コンテナー Web コンテナー Web コンテナー Application Server Application Server Application Server Application Server EJBCluster EJBCluster EJB コンテナー EJB コンテナー EJB コンテナー EJB コンテナー Application Server Application Server Application Server Application Server 120

121 災害対策 121

122 122 DB サイトの二重化 要件 コスト 運用負荷などを考慮してどこまで対応するか検討する Web Asperser EJB コンテコンテコンテコンテナー AppServer Web コンテコンテコンテコンテナーセルセルセルセル 1 負荷分負荷分負荷分負荷分散装置散装置散装置散装置 Clustering ユーザーリクエストユーザーリクエストユーザーリクエストユーザーリクエストの振り替え (DNS レコードレコードレコードレコード変更変更変更変更 広域負荷分散広域負荷分散広域負荷分散広域負荷分散 ) とデータデータデータデータの同期同期同期同期を検討検討検討検討するするするする必要必要必要必要があるがあるがあるがある DNS 同期同期同期同期 (PPRC などなどなどなど ) Web Asperser EJB コンテコンテコンテコンテナー AppServer Web コンテコンテコンテコンテナー DB Web Asperser EJB コンテコンテコンテコンテナー AppServer Web コンテコンテコンテコンテナー負荷分負荷分負荷分負荷分散装置散装置散装置散装置 Clustering Web Asperser EJB コンテコンテコンテコンテナー AppServer Web コンテコンテコンテコンテナーセルセルセルセル 2 DNS レコーレコーレコーレコードの書き換えのえのえのえの場合場合場合場合 TTL の設定設定設定設定やキャッャッャッャッシュによってによってによってによって切り替わるまるまるまるまで時間時間時間時間がかかるがかかるがかかるがかかるリモートリモートリモートリモートスタンバイスタンバイスタンバイスタンバイサイトサイトサイトサイト

123 2. WAS トポロジー設計 2-1 パフォーマンス 拡張性設計 2-2 可用性 障害設計 2-3 セキュリティーに関する設計 123

124 Web インフラに求められるセキュリティー要件 セキュリティー要件 物理レベル セキュリティー マシンの物理的な配置場所 ネットワークレベル セキュリティー 外部ネットワークとの接続 およびシステム内のネットワークにおけるセキュリティー ゾーニング ( サーバーアドレスの隠蔽 ) 暗号化 インフラレベル セキュリティー OS ミドルウェアー等 業務アプリを取り巻く環境のセキュリティー WAS と連携するセキュリティー ミドルウェア製品として TAM LDAP アプリケーションレベル セキュリティー 業務処理プログラム作成時に考慮しなくてはならないセキュリティー WAS では J2EE セキュリティーを使用してリソースレベルのセキュリティーを設定可 運用セキュリティー システム運用時のセキュリティー 124

125 ゾーニング 暗号化 125

126 ゾーニング設計 WAS と Web サーバー プロキシーサーバーのゾーンを分離 外部からの不正なアクセスを遮断 内部ネットワークのマシンを直接的な攻撃対象にならないようにする 内部ネットワークの IP アドレスなどの情報を隠蔽 Uncontrolled ゾーン Controlled ゾーン ( 非武装地帯 ) Restricted ゾーン Secured ゾーン Load Balancer Internet Client Proxy, 認証 認可認可 Server (Reverse proxy) Web Server Application Server 126

127 ゾーニングを行った場合のファイアウォール設定 アプリケーション サーバー /Web サーバー間でオープンが必要なポート ホスト デフォルト ポート (TCP) 向き ホスト デフォルト ポート (TCP) 備考 Web Server * App Server 9080 アプリケーション サーバーのリクエスト受付ポート (HTTP) Web Server * App Server 9443 アプリケーション サーバーのリクエスト受付ポート (SSL) Web Server (IHS only) 8008 Deployment Manager ( 管理サーハ ー ) * IHS 管理サーバーのポート リモート Web サーバーが IHS の場合 Web サーバー管理のため Web Server 80 Deployment Manager ( 管理サーハ ー ) * Web サーバーの Listen ポート 管理サーバーが Web サーバーの稼動状況確認のため Application Server WASやIHSの Listen ポートを変更しているしている場合場合には適宜変更適宜変更が必要 Web Server Deployment Manager 127

128 ゾーニングにおける考慮点 SSL 通信をどこで解除するか できるだけ前で解除したほうがパフォーマンスがよい Proxy サーバーと Web サーバー Web サーバーと WAS などでは一度 SSL を解除して 再度 SSL ネゴシエーションを行うため 負荷分散機として IBM ロードバランサーを使用している場合には SSL 解除を行わず そのまま後続のサーバーにリクエストを転送 できるだけ後ろで解除したほうがセキュリティーが向上 たとえ DMZ 内のサーバーが乗っ取られた場合にも データが漏洩しない SSL アクセラレーターの使用 2 Proxy 4 Application Server 1 専用機または Load Balancer 3 Web Server SSL アクセラレーターとは SSL データの暗号化 複合化を高速に行う専用ハードウェアのこと 128

129 IHS-WAS 間の SSL 解除方法 ( 参考 ) IHS-WAS 間は クライアント -IHS 間が SSL 通信の場合 デフォルトで SSL で通信 IHS-WAS 間の通信を HTTP のみ (SSL を使用不可にする方法 ) 管理コンソールで [ サーバー ]-[ アプリケーション サーバー ]-[ アプリケーション サーバー名 ]-[ コンテナー設定 ]-[Web コンテナー トランスポート チェーン ] を選択し WCInboundDefaultSecure のトランスポート チェーンのリンクをクリックし 使用可能 のチェックボックスを OFF にする デフォルトで設定設定される IHS-WAS 間のSSL 通信は DummyKeyを使用使用しているためしているため SSL 通信を設定設定するする場合場合も正しくしく設定設定しなおすしなおす必要必要がある 129