Comments
Description
Transcript
2章 Dynamic Operations 第 1 We
第2章 Dynamic Operations WebSphere XD5.1 Technical Guide 1 第2章目次 WebSphere XD5.1 Technical Guide 1. Dynamic Operations 概要 4. Dynamic Operations コンセプト XDアーキテクチャ概要 2. オートノミック要求フロー・マネージャー アプリケーション配置コントローラー 動的ワークロード・マネージャー ヘルス管理コントローラー XDの導入 ODRの構成 Dynamic Operations環境構成 その他の割振り設定 カスタム・エラー・ページの設定 Sorryページへの割振り Dynamic Operations の構成 割振り設定 XD環境への割振り 別Cell環境への割振り Non-XD環境への割り振り Autonomic Managers 3. On Demand Router の構成 ODRのセキュリティ SSL通信の設定 HTTPメソッドの無効化 WebServer Pluginとの連携 5. Dynamic Operations の運用 動的クラスターの運用モード Dynamic Operations環境起動手順 Dynamic Operations環境停止手順 保守モード セッション管理 2 第2章 Dynamic Operations WebSphere XD5.1 Technical Guide 1. Dynamic Operations概要 2. Autonomic Managers 3. Dynamic Operationsの構成 4. On Demand Routerの構成 5. Dynamic Operationsの運用 3 Dynamic Operations コンセプト WebSphere XD5.1 Technical Guide ビジネス・ゴール達成に必要なランタイム・リソースを 動的に配置 WebSphere Extended Deployment is built upon a virtualized infrastructure that redefines the traditional concepts of J2EE resources and applications, and their relationships with one another. (Dynamic Operationsコンセプト WAS5.1XD InfoCenterより) WebSphereランタイム・リソースの仮想化 オペレーショナル・ポリシーでのサービスレベルの設定 Webリクエストの差別化と優先順位付け Autonomic Managers Autonomic Request Flow Manager (ARFM) Application Placement Controller (APC) Dynamic Workload Management (dWLM) Health Management Controller Dynamic Operationsの目的は、ビジネス・ゴールを達成できるよう、必要なランタイム・リソースを必要なと きに動的に配置することです。ビジネス状況にオン・デマンドに対応していくDynamic Operationsの特徴 としては以下が上げられます。 ・WebSphereリソースの仮想化 XDはハードウェア・リソース、つまりノード（マシーン）を仮想化します。これにより、従来のアプリケーション とサーバーの固定的関係を解消します。 ・オペレーショナル・ポリシーでのサービス・レベルの設定 XDは、目標とされるサービス・レベルを維持するよう自動的に適応していく、自律的インフラストラクチャー です。 XDではアプリケーション単位でのパフォーマンス・ゴールおよび重要度をサービス・ポリシーとして 設定し、個々のWebリクエストの差別化と優先付けを行います。またアプリケーションの正常稼動を確保 するためのヘルス・ポリシーを定義することにより、アプリケーション稼働環境も自動的に制御されます。 これらのDynamic Operations環境を実現させるためのコンポーネントが、Autonomic Managerです。 Autonomic Managerには、オートノミック要求フロー・マネジャー、アプリケーション配置コントローラー、 動的ワークロード・マネージャー、ヘルス管理コントローラーの４つがあります。 4 WebSphereリソースの仮想化 WebSphere XD5.1 Technical Guide Static Cluster 1 Static Cluster 2 Cell Dynamic Cluster 1 Node Group ear ear Cell アプリケーションが使用できるリソースが固 定で限定される Dynamic Operations Service Policy ランタイム構成とリソースの関係が静的で 固定的 クラスターとメンバー アプリケーションと実行サーバー ear ear Dynamic Cluster 2 従来のシステム ノードをリソース･プール（ノード・グループ） に登録 クラスターは動的クラスターとして作成 動的クラスターはノード・グループにマップ アプリケーションは動的クラスターにマップ アプリケーションは運用ポリシーに応じて、 動的にノードグループ内のリソースが割り 当てられる 従来のシステム 従来のシステムではピーク時処理量に目標を定めてシステムを構築するため、ピーク時を除くほとんどの 時間はマシンの使用率が非常に低く、また多大なコストがかかっていました。またアプリケーションとサー バーとの関係が固定的なため、特定システムがピークを迎えても、遊んでいる他のリソースを有効に活用 できないという課題がありました。 Dynamic Operations WebSphere XDでは従来のアプリケーションとサーバーのstaticな関係を解消し、ノード・グループとして 資源を仮想化・プール化して定義します。 クラスターは仮想化されたリソース（ノード・グループ）上に動的クラスターとして定義されます。 アプリケーションは動的クラスター上に導入され、あらかじめ設定された運用ポリシーと実際のアクセス状 況によってリソースが動的に割り当てられます。 これにより、よりビジネス上重要なアプリケーションに対する高いサービス品質を保ちつつ、インフラを最適 化することが可能となります。 5 オペレーショナル・ポリシーによるサービスレベル制御 WebSphere XD5.1 Technical Guide サービス・ポリシー 目標平均レスポンス・タイムと 重要度（7段階）を指定 サービス・クラスと トランザクション・クラスをマッピング サービスクラス（例） トランザクション・クラス （URIパターン） 名前 重要度 目標応答時間 Platinum 最高 < 1.25秒 /StockTrade/* Gold 高 < 2秒 /FinancialAdvice/* Silver 中 < 5秒 /AccountManagement/* ヘルス・ポリシー 連続稼動時間やメモリ使用率、総リクエスト数などの条件を指定 条件にマッチした場合に通知をあげたり、自動で再起動を行う オペレーショナル・ポリシーは、サービス・ポリシーとヘルス・ポリシーからなります。 サービス・ポリシーによって、ビジネス・ゴールを規定します。これは、パフォーマンスの目標レスポンスタイ ムと重要度の組み合わせからなるサービス・クラスと、リクエストのURIごとのグループであるトランザクショ ン・クラスとのマッピングにより定義されます。 またヘルス・ポリシーによってアプリケーション稼動環境の健全性を管理します。ノードの連続稼動時間や メモリの使用率、総リクエスト数などヘルス・ポリシーを指定します。この条件にマッチした場合は、モード によって管理者に通知をあげたり、自動で再起動をおこなったりすることが可能です。 6 XDアーキテクチャ概要 WebSphere XD5.1 Technical Guide WAS WAS WAS WAS Router Node 1 ODR ODR ODR ODR XD XD Node Node XD Agent Agent Node Node Agent AgentXD WAS WAS WAS WAS Node 1 XD XD Node Node Agent AgentXD Node 2 XD XD Node Node Agent AgentXD Router Node 2 WAS WAS Cell Node 3 XD Node Node Agent AgentXD Core Group Deployment Deployment Manger Manger XD XDアーキテクチャの概略図です。通常のWAS ND環境と同様、Deployment Managerによって管理され る単位Cellが存在し、Cell内には複数のAppServerが存在します。XD環境には、オンデマンドなリクエス トの割振りを担うOn Demand Routerが存在します。各ノードにはNodeAgentが存在し、各ノードのプロセ スを管理します。 7 XDアーキテクチャ概要 WebSphere XD5.1 Technical Guide On Demand Router (ODR) Application Server (WAS) アプリケーションの稼動環境を提供する Dynamic Operation環境の稼動に必要な情報をAutonomic Managerに提供する WPF（WebSphere Partitioning Facility）を利用したパーティショニング機能を提供する Node Agent Reverse Proxyとして機能するプロセスで、ポリシーに基づいてリクエストのクラス分け、優先順位 付け、AppServerへの割振りを行う 内部コンポーネントのAutonomic Managerが、ポリシーで定義された優先順位に基づいて、異なる クラスのリクエストの流量制御を行う プロセス状態やノードのCPU・メモリ使用率の情報を提供する 要求を満たすために、稼動させるAppServerのインスタンス数を管理する（特定ノード・エージェント） ヘルス管理情報を調整し、タスクを提起する（特定ノード・エージェント） WLMのための重みを計算する（特定ノード・エージェント） ノードに割振るリクエストの平均総量を決定するためにリクエストをプロファイルする（特定ノード） 流量制御のためにアプリケーションの配置、要求のフロー、実行回数をモニタリングする（特定ノード） Deployment Manager ノード間でワークロード管理のための情報を調整する セル・ワイドのシステム情報を収集・保持し、Visualizationツールを使用して表示する 重要なXDのランタイム・タスクを管理し、ユーザーに情報を伝える ODR、AppServer、NodeAgent、DMのそれぞれのプロセスが果たす役割は主要なものをまとめると上記 のようになります。 8 第2章 Dynamic Operations WebSphere XD5.1 Technical Guide 1. Dynamic Operations概要 2. Autonomic Managers 3. Dynamic Operationsの構成 4. On Demand Routerの構成 5. Dynamic Operationsの運用 9 Autonomic Managers WebSphere XD5.1 Technical Guide Bulletin Board クラス分け 高 中 低 （publish/subscribeによる情報交換機能） ①優先順位 ②流量制御 ①ルーティング ②動的ワークロードマネジメント(dWLM) ③アフィニティ ④フェイル・オーバー Node ST AM 1 Stock Trading Account Mngmnt Financial Advice 動的配置 Node ST AM 2 APC アプリケー ション配置コ ントローラー Node ST FA 3 Node FA AM 4 オンデマンド・ルーター 運用ポリシー ①重要度(最高、非常に高、高、 中、低、非常に低、最低) ②ゴール(平均レスポンスetc) ARFM オートノミック 要求求フロー マネジャー Node FA AM 5 dWLM 動的縮退 モニタリング 動的クラスター ノードグループ 動的 ワークロード マネージャー HMC ヘルス管理 コントローラー Dynamic Operations環境を支えているAutonomic Managersは4つ存在します ・オートノミック要求フロー・マネジャー （Autonomic Request Flow Manager, ARFM） リクエストの分類・優先順位付け、流通量制御といった役割を果たします。 ・アプリケーション配置コントローラー （Application Placement Controller, APC） サービス・ポリシーを維持できるよう、需要に応じてアプリケーションの動的再配置を行います。 ・動的ワークロード・マネジャー（Dynamic Workload Manager, dWLM） 各アプリケーション・サーバーの負荷を判断し、動的に重み付けを変化させ、最適な負荷分散を行います。 ・ヘルス管理コントローラー （Health Management Controller） ヘルス・ポリシーに定義された条件を維持できているかクラスター・サーバーの状況を監視します。 これら４つのAutonomic Managerについて次のページから説明していきます。 10 オートノミック要求フロー・マネージャー WebSphere XD5.1 Technical Guide サービス・ポリシーに基づいて、リクエストの分類・優先順位付け及び キューイングを行うAutonomic Manager ARFMは２コンポーネントから構成される ARFM ゲートウェイ ODR内のコンポーネント ODRとノード・グループのペア毎に１つ存在 リクエストの分類およびキューイングを行うコンポーネント 1. リクエストはサービスクラス毎に自動生成されたキューに入り、処理を待ちます。 2. ゲートウェイはキュー上のリクエストをコントローラーが設定したウェイト値に応じて優 先順位付けを行います。 ARFM コントローラー ノード・グループ毎に１つ存在 キューイングされたリクエストのフローの最適化を行うコンポーネント 設定されたサービス・ポリシーとリクエストの統計情報からキューのウェイト値を 算出 オートノミック要求フロー・マネージャー（ARFM）はサービス・ポリシーに基づいて、各リクエストにマッピン グされたサービス・クラスごとにキューイングを行い、優先順位付けをして流量制御を行うコンポーネントで す。 ARFMはゲートウェイとコントローラーという２つのコンポーネントから構成されています。 ARFMゲートウェイはODR内に存在するコンポーネントで、ODRとノード・グループのペアごとに１つ存在 します。ARFMゲートウェイはサービス・クラスごとに自動生成したキューにリクエストをキューイングします。 処理の流れとして、まずリクエストはサービス・クラスごとにキューに入り、処理を待ちます。ゲートウェイは キュー上のリクエストをコントローラーが計算したウェイト値（重み）に応じて優先順位付けを行います。 ARFMコントローラーはノード・グループに一つずつ存在します。ARFMコントローラーは、ゲートウェイに よってサービス・クラスごとにキューイングされたリクエスト・フローの最適化を担うコンポーネントです。コン トローラーは設定されたサービス・クラスのゴールと実際のリクエストの統計情報からキューのウェイト値を 計算し、Bulletin Board経由でゲートウェイに通知します。 11 オートノミック要求フロー・マネージャー WebSphere XD5.1 Technical Guide 取得した情報からリクエ ストのフローを最適化 Bulletin Board 統計情報・ポリシー情報 コントローラーの計算したウェイ ト値により流通量を決定 フロー設定 ARFM コントローラー ODR Node1 Node2 dWLM リクエスト Node3 クラス分け ARFM ゲートウェイ Node4 ルーティング Node Group サービス・クラス毎に キューは自動生成される 最大同時リクエスト数とサービス クラスごとの最低保障流通量 オートノミック要求フローマネージャーの動きを図示したのが上の図になります。 ARFMゲートウェイはサービス・クラスごとのキューを持ちます。キューはリクエストの到達時にゲートウェイ によって自動生成されます。また、ゲートウェイはどのサービス・クラスにも属さないURI用にどのサービス・ クラスよりも優先度の低いキューを一つ持っています。 ODRは受信したリクエストを先ずサービス・クラスにクラス分けし該当のキューへキューイングします。 キュー内のリクエストは各キューのウェイト値によって優先度が決定され流通量が決められます。ここでコ ントローラーの計算した最大同時リクエスト数とサービス・クラス毎の最低保障流通量によって流量制御が 行われます。そして、どのサービス・クラスのリクエストをいくつ流通させるかが決定され、そのリクエストが dWLMに送られ、dWLMがバックエンドのノードにリクエストをルーティングするという流れをとります。 ARFMコントローラは取得した統計情報とサービス・ポリシー（サービス・クラスのゴール）をもとにキューの ウェイト値を計算し、Bulletin Board経由でARFMのゲートウェイに通知します。 12 ARFMゲートウェイ WebSphere XD5.1 Technical Guide サービスクラス単位での キューイング ウェイト値 最低保障流通量 最大同時リクエスト数 リクエスト統計 情報の公開 フローの制御 キューは新たなサービスクラスが リクエストフローに現れた際に動 的に生成される Bulletin Board ウェイト値に基づく比例キューイ ングによるフローコントロール 各サービスクラスにおける最低 流通量を保障 最大同時リクエスト数の制限 Bulletin Boardとの情報交換 ウェイト値 最大同時リクエスト数 最低保障流通量 リクエスト統計の集計 動的クラスター、サービス・クラ ス、トランザクション・クラスの各 レベル Weight ３ Weight 4 Weight 1 ARFM ゲートウェイ ARFMのゲートウェイの役割に、これまでにご説明したリクエストのキューイング、流量制御・優先順位付け のほかに、Bulletin Boardを通じたARFMコントローラーとの情報のやりとりがあります。 ARFMコントローラーは定期的にサービス・クラスごとのウェイト値を算出し、ARFMゲートウェイはこのウェ イト値を受け取り、各キューの流通量のウェイトに適用します。またARFMコントローラーは最大同時リクエ スト数とサービス・クラスごとの最低保障流通量も算出しますが、ゲートウェイはこれを受け取りリクエスト・フ ローの流通制御に適用します。 また、ARFMゲートウェイは定期的にリクエスト統計を収集しBulletin Boardに公開もしています。 ARFMゲートウェイが収集するリクエスト統計には以下のようなものがあります。 ・キューの長さの平均 ・実行中のリクエスト数の平均(ディスパッチング後戻ってきていないリクエスト) ・到着リクエスト数 ・ディスパッチングしたリクエスト数 ・キューでの平均待ち時間 ・キュー平均のサービス実行時間 ゲートウェイはこれらの統計データを動的クラスター、サービス・クラス、トランザクション・クラスの各レベル に集計します。これらの情報はDeployment Manager、ARFMコントローラー、アプリケーション配置コント ローラーによって利用されます。Deployment Managerに送られたデータは管理コンソールのランタイム・ トポロジーに反映されます 13 ARFMコントローラー WebSphere XD5.1 Technical Guide サービス状況の監視 ARFMゲートウェイが採取したリクエスト統 計からサービス状況をBB経由で受け取る アプリケーションの配置状況を監視 サービス・クラスのゴール達成度判断のた め、定義されたポリシー情報の収集 フローの最適化 リクエスト統計情報およびポリシー達成度 を元にウェイト値を算出 最大同時リクエスト数およびサービス・クラ スのキュー毎の最低保証流通量を算出 各値をBulletin Boardにpublishする Bulletin Board リクエスト統計 情報の取得 ウェイト値の公開 ARFM コントローラー ウェイト値 の算出 Node1 Node2 Node3 Node4 Node Group ARFMコントローラーの役割の一つはサービス状況の監視です。コントローラーは一定間隔でゲートウェ イが取得したリクエスト統計情報（前ページ参照）からリクエスト到着率、サービス実行時間、レスポンス・タ イムなどをBulletin Board経由で受け取ります。また、ノード・グループでのアプリケーションの配置状況を 監視し、サービス・クラスのゴールの達成度をみるため、定義されたポリシー設定（サービス・クラスごとの ゴール）を収集します。 コントローラーの二つ目の役割はリクエスト・フローの最適化を行うことです。取得したリクエスト統計情報 およびポリシー（サービス・クラスのゴール）の達成度を基にリクエストを割り振るためのサービス・クラスごと のキューのウェイト値を計算します。また、最大同時リクエスト数、サービス・クラスのキューごとの最低流通 保障量を計算します。これらの計算値はBulletin Boardに公開され、ゲートウェイによって利用されます。 14 オートノミック要求フロー・マネジャーの設定 WebSphere XD5.1 Technical Guide 管理コンソールから設定 「システム管理」→「ノード・グループ」→<NodeGroup名>→「オートノミック要求フロー・マネージャー」 ゲートウェイが統計情報 を取得し公開する間隔 コントローラーがサービス状況 を収集しキューのウェイト計算 などを実行する間隔の最小長 コントローラーがゲートウェイから 受け取る最後のいくつまでの統 計データから計算するかを指定 ゲートウェイのキューの最大 キュー長。キューが最大値に達 すると要求はリジェクトされる コントローラーはdWLMとAPCと 共同でノード・グループのＣＰＵ使 用率をこの値まで制限するように 調整する オートノミック要求フロー・マネジャーの動作を管理コンソールから調整することも可能です。以下が、調整 可能なパラメータです。 ・集約期間 ゲートウェイが定期的にリクエスト統計情報を収集しBulletin Boardに公開する間隔を指定します。集約期 間を小さくしすぎるとサンプルとなるリクエストの数が少なく、パフォーマンスの測定基準が信頼性の低いも のになりえます。また、集約期間を長くしすぎると制御設定の再計算の回数が少なくなり、リクエストのトラ フィック量の急な変更に対応できなくなる可能性があります。集約期間はデフォルトでは5秒となっていま す。 ・コントロール・サイクルの最小長 コントローラーはサービス状況を監視し、ゲートウェイからのリクエスト統計情報を取り込み、定期的にサー ビス・クラスごとのキューのウェイト値を計算して公開します。このパラメータはその実行を行う時間間隔の 下限値を指定します。このパラメーターも集約期間同様、小さすぎるとパフォーマンス測定基準の信頼性 が低いものになる可能性があり、大きすぎると急なトラフィック変更に対応できなくなる可能性があります。 デフォルトは59秒となっています。 ・平滑化ウィンドウ コントローラーが定期的にサービス・クラスのキューのウェイト値を計算する際、ゲートウェイからのリクエス ト統計レポートの最後の数個の実行平均を基に算出します。平滑化ウィンドウはそれをいくつまで含める かを指定します。これを大きくすると急激なトラフィック変更は平滑化され、小さくすると急激なトラフィック 変更が早く反映されることになります。平滑化ウィンドウと集約期間の積がコントロール・サイクルの間隔と なるように（つまりコントロール・サイクル間隔内のすべてのリクエスト統計を計算に含めるように）設定する ことが推奨されています。 ・最大キュー長 ゲートウェイのキューの最大キュー長を表します。キューが最大値に達するとリクエストはリジェクトされます。 リジェクトされた要求はHTTP状況コード500で返るので、これをODRのカスタム・エラー・ページ・ポリシー （後述）で設定することにより、エラー・ページにリダイレクトすることも可能です。デフォルトは1000となって います。 ・最大CPU使用率 コントローラーはdWLMとAPCと共同でノード・グループ内のノードのCPU使用率がこの値以下になるよう に調整します。ノードのCPU使用率がこの値を超えるとARFM, dWLM, APCが共同でそれを平準化する ように働きます。 15 ODRとARFMのトポロジー WebSphere XD5.1 Technical Guide ODR：ノード・グループ=１：N構成 Cell ODRとノードグループのペアご とにARFMゲートウェイが存在 ODR Client Client Client Client CLS ノードグループごとに ARFMコントローラーが存在 コントローラー A ゲート ウェイ A ゲート ウェイ B ゲート ウェイ C ノード・ グループA dWLM ノード・ グループB コントローラー B ノード・ グループC コントローラー C ODRの典型的なトポロジーの例を見てみます。最初はノード・グループが複数（ここではノード・グループ A,ノード・グループB,ノード・グループCの３つ）存在し、その前面にODRが１つ存在する１：N構成です。 ARFMコントローラーはノード・グループに対し１つずつ存在するため、各ノード・グループにコントロー ラーA・コントローラーB・コントローラーCの３つが存在します。 ゲートウェイはODRとノード・グループのペアごとにひとつ存在するためODR内にゲートウェイA・ゲート ウェイB・ゲートウェイCの３つが存在します。ゲートウェイAはリクエスト統計情報を定期的にコントローラー Aにレポートします。コントローラーAはノード・グループAのサービス状況を監視し、受け取った統計情報 からゲートウェイA用のフロー情報（キューのウェイト値）をゲートウェイAに返します。その他のコントロー ラーおよび、ゲートウェイも同様の動きをします。 16 ODRとARFMのトポロジー WebSphere XD5.1 Technical Guide ODR：ノード・グループ=N：１構成 ODRとノードグループのペアご とにARFMゲートウェイが存在 Cell ODR#1 CLS Client Client IP Sprayer ゲート ウェイ A dWLM ノード・ グループA ODR#N Client CLS コントローラー A ゲート ウェイ A dWLM Client ARFMコントローラーは、担当する ノード・グループとやりとりする全ての ゲートウェイの面倒を見る 次にノード・グループが１つ（ここではノード・グループA)存在し、その前面にODRが複数（ここではODR# １∼.ODR#X)存在する場合です。 コントローラーはノード・グループにひとつ存在するので、ここではコントローラAのみが存在します。 ゲートウェイはODRとノード・グループのペアごとに存在するので、各ODR内にゲートウェイAが一つずつ 存在します。 すべてのODRのゲートウェイAはリクエスト統計情報を定期的にコントローラーAにレポートし、コントロー ラーAはノード・グループAのサービス状況を監視して受け取ったすべての統計情報から各ODRのゲート ウェイAのフロー情報（キューのウェイト値）をすべてのゲートウェイAに返します。ODRが複数ある場合は コントローラーが該当するノード・グループとやりとりする全ゲートウェイの面倒を見ることになります。 17 アプリケーション配置コントローラー WebSphere XD5.1 Technical Guide Application Placement Controller Dynamic Cluster内でのアプリケーションのインスタンス数と実行 ノードを決定し、動的に再配置を行う 実行インスタンス数の決定には以下のデータを利用 各ノードのCPUおよびメモリ使用率 ARFMから渡されるサービス統計を基に算出されるCPU/メモリ需要予想 NodeGroup単位に１つ NodeAgent上に存在 HAマネージャー管理下 で稼動し可用性を確保 アプリケーション配置コントローラーは、ダイナミック･クラスター内のアプリケーションのインスタンス数と実 行ノードを決定し、動的に再配置を行うAutonomic Managerです。負荷増大にはアプリケーションのイン スタンス数を増やしてリクエスト増加に対応し、負荷が軽くなった際には実行インスタンス数を減らしリソー スを解放します。アプリケーション配置コントローラーが実行インスタンスの決定に用いるデータは、各ノー ドのCPU/メモリーの使用率と、ARFMから渡されるサービス統計を基に算出されるCPU/メモリの予想必要 量です。 アプリケーション配置コントローラーはノード・グループ単位に存在し、いずれかのノード・エージェント上 に存在します。アプリケーション配置コントローラはHAManager管理下で稼動していますので、アプリ ケーション配置コントローラーが稼動しているノード・エージェント・プロセスに障害が発生した場合は自動 でFailoverされます。アプリケーション配置コントローラーがどこで稼動しているかは、ラインタイム・トポロ ジーから確認することができますし、以下のコマンドで確認することもできます。 <WAS_ROOT>¥wsadmin.bat –profile checkPlacementLocation.jacl <NodeGroup名> 18 アプリケーション配置コントローラーの設定 WebSphere XD5.1 Technical Guide 監視モード設定時のプロビ ジョニングの承認タイムア ウトです。 タイムアウトしたタスクは無 効となり、プロビジョニング が発生しません プロビジョニングが発生 後、次の配置変更が発 生するまでの最小時間 プロビジョニングによる サーバーの起動･停止の タイムアウト時間 監視モードに設定している場合は、管理者が受諾を 選択することにより、プロビジョニングが実行される アプリケーション配置コントローラーの設定は管理コンソールから行うことが可能です。「システム」→「ノー ドグループ」→＜NodeGroup名＞と選択し、追加プロパティ「アプリケーション配置コントローラー」を選択 します。 APCを無効にしたい場合は、使用可能のチェックボックスを外します。APCが無効の場合は、従来通り AppServerの開始は手動になり、プロビジョニングによる動的再配置も発生しません。 ・承認タイムアウト 動的クラスターの運用モードを監視とした際に、APCにより提案されたプロビジョニングを受諾するかどう かのタイムアウトになります。１∼６０分の間で設定可能で、この承認タイムアウトを過ぎたタスクは無効とな り、プロビジョニングは発生しません。なお、監視モードにした際に提案されるタスクの内容は、管理コン ソール「ランタイム操作」→「タスク管理」→「ランタイム･タスク」のページから確認できます。 ・配置変更間の最小時間 プロビジョニングが発生してから次のプロビジョニングが発生するまでの最小インターバルを1分∼２４時 間の間で指定します。この値は、サーバーの開始と停止に関連するオーバーヘッドを考慮して設定しま す。サーバーの開始または停止には数分かかりますのでで、ノードに対してさらに負荷がかかることもあり ます。配置コントローラーにアプリケーションの配置の再調整をあまり頻繁に許可すると、このオーバー ヘッドが追加されるため、本来動的クラスターのサイズを再調整して得られたパフォーマンス向上の恩恵 が十二分に受けられない可能性があります。例えば、サーバーの開始に 1 分必要な場合に配置変更間 の最小時間を 20 分に設定すると、配置変更により約 5% のパフォーマンスへの影響があります。この値 を設定する場合、少なくてもサーバーの開始に必要な時間の 20 倍から 30 倍の時間をこのパラメーター に定義することが推奨されます。設定値が数時間以上など大きい値に設定された場合には、1 日に複数 回アプリケーション配置の変更を行うことはできなくなります。 ・サーバー操作タイムアウト プロビジョニングにより発生したサーバーの起動・停止が完了する際のタイムアウト時間を指定します。許 容値は１∼６０分です。この時間を過ぎてもサーバーの起動・停止が完了しない場合はエラーとなりますの で、高負荷時を考え、起動・停止にかかる十分な時間を設定します。 19 動的ワークロード・マネージャー WebSphere XD5.1 Technical Guide 静的クラスター・動的クラス ターいずれも設定可能 Cluster Node１ AppServer1 ODRノード Node Agent Node２ ODR dWLM AppServer2 Node Agent Node３ dWLM: 計算された情報を基 にリクエストの割振り AppServer3 dWLMコントローラー: 各AppServerの 状況からウェイトを計算。 HAManager管理のもと、 いずれかのNodeAgentまた はAppServerで稼動 dWLM コントローラー CPU使用率、スループット、 同時リクエスト数などのパ フォーマンス情報 Node Agent 次に動的ワークロード・マネージャー（dWLM）についてご説明します。従来のWASのWLMは静的な重 み付けラウンドロビンでした。これはWLM先のAppServer毎に事前に重み付けを行っておき、静的な重 みに応じたリクエスト割り振りを行う機能です。XDのODRは動的にAppServer毎の重みを計算し、その重 みに従ってクライアントからのリクエストを割り振る動的WLMを行うことができます。 dWLMはODR上で稼動し実際に割振りを行うdWLMと、それに重みをレポーティングするdWLMコント ローラーからなります。dWLMは設定によりOn/Offが可能です。また、対象のクラスターは動的/静的クラス ターの両者に対して設定可能です。 dWLMコントローラーはパフォーマンス情報（ノードのCPU使用率、AppServerのスループット、同時リクエ スト数など）に基づき、各ノードのウェイト値を計算、し、定期的（20秒毎）にdWLMに送付します。ODR上 のdWLMはこのウェイト情報に基づきバックエンドへの割振りを行います。 dWLMコントローラーはHAManager管理の下、AppServerおよびNodeAgentのいずれかのプロセスで 稼動します。たとえdWLMコントローラーが稼動しているプロセスが落ちた場合でも、HAManagerによって 自動でFailoverされます。dWLMがどこで稼動しているかはランタイム・トポロジーの画面からも確認できま すし、以下のコマンドを用いて確認することもできます。 <WAS_ROOT>¥wsadmin.bat –profile checkDWLMLocation.jacl <NodeGroup名> なお、後述のアフィニティ（HTTP Session AffinityやWPF Partition Affinityなど）がWLMより常に優先さ れます。 WLMアルゴリズム による割振りは新規リクエストにのみ適用されることになります。 20 動的ワークロード・マネージャーの設定 WebSphere XD5.1 Technical Guide デフォルトの設定は管理コンソールより変更可能 動的クラスターはdWLM、静的クラスターは静的WLMがデフォルトの設定 動的クラスター：「動的クラスター」→「<クラスター名>」→「動的WLM」 静的クラスター：「クラスター」→「<クラスター名>」→「動的WLM」 保守モードの設定 メンテナンス時など特定ノードへの割振りを止めたいときに設定 管理コンソールのノード･グループ設定からメンバー・ノードを保守モードに設定する ことでWLMの割り振り対象外となる デフォルトでは動的クラスターは動的WLMが有効に、静的クラスターは静的WLMが有効になっています。 デフォルトの設定を変更した意場合は、それぞれのクラスター設定の追加プロパティ「動的WLM」の チェック･ボックスのON/OFFで切替えることが可能です。 またマシンのメンテナンスのために一時的にリクエストの割振りをと止めたい場合には、保守モード（後述） を設定することができます。保守モードに設定することで、WLMの割振り対象から外され、リクエストが割り 振られなくなります。 21 ヘルス管理コントローラー WebSphere XD5.1 Technical Guide ヘルス管理機能とは ヘルス・ポリシー XDランタイムの異常状態を検知し、アクションを実行する ヘルス管理コントローラーがヘルス･ポリシーに基づいてモニタリング XDランタイムの健康状態を 判断するためのポリシー 管理者が事前に条件を設定する ヘルス管理コントローラー ヘルス管理機能を担うAutonomic Manager セル内に１つ、いずれかのノードエージェント上で稼動 HAManager管理下で稼動し可用性を確保 定義されたヘルス・ポリシーに基づきモニタリングを実施 自動/監視モードでは、サーバーの再起動をアクションとして実行/提案 異常を検知すると、 「タスク管理サービス」にタスクが生成される XDではあらかじめ設定したヘルス・ポリシーに従って、ランタイムの健康状態をモニタリングし、異常事態 を検知してアクションを実行する仕組みをサポートしています。 ヘルス・ポリシーとは、WebSphereランタイムの健康状態を判断するための基準となるポリシーで、管理者 が事前に条件を定義します。ヘルス・ポリシーの詳細は後述します。 ヘルス管理コントローラーは、ヘルス管理機能を担うAutonomic Managerです。ヘルス管理コントロー ラーが異常を検知すると、アプリケーション・サーバーの再起動をアクションとしてタスク管理サービスにタ スクを提起します。ヘルス管理コントローラーはセル内のいずれかのノードエージェント上で稼動し、稼動 中のノードエージェントに障害が発生すると、HAマネージャーの仕組みによって自動検知され、別のノー ドエージェントにフェール・オーバーされます。 ヘルス管理コントローラーがどこで稼動しているかはランタイム・トポロジーの画面からも確認できますし、 以下のコマンドを用いて確認することもできます。 <WAS_ROOT>¥wsadmin.bat –profile checkHMMLocation.jacl 22 ヘルス管理コントローラーの設定 WebSphere XD5.1 Technical Guide ヘルス・モニタリングの行 われる間隔を指定します 再始動がリトライされ る最大数を指定します 再始動間で最低限 空けなければならな い時間を指定します 再始動時に、停止から 始動までに確保すべき 時間を指定します 業務ピークなど、再始 動を発生させたくない 時間を指定します ヘルス管理コントローラーの設定は管理コンソール「システム管理」→「ヘルス・コントローラー」から行いま す。 ・コントロール・サイクル長 ヘルス・モニタリングが行われる間隔を指定します。１∼６０まで分単位で指定可能です。例えば６０分間 に指定すると、60分に１回しかモニタリングが行われませんので、その60分間の間にヘルス・ポリシーの 条件を満たす状況が発生しても、検知が遅れてしまう可能性があります。 ・連続再始動の最大数 ヘルス管理コントローラーが再始動を決定してからリトライされる再始動の最大試行回数を指定します。こ の数を経過した場合は、エラーと認識され再始動が使用不可とされます。 ・再始動の最小インターバル 再始動間で最低限空けなければいけない時間を指定します。この最小インターバルの間に、ヘルス条件 が発生し不履行となった再始動のアクションは保留状態となり、最小インターバル経過後に再始動が発生 します。値は15分から365日までの範囲で指定可能です。0に設定した場合は最小インターバルが無効 になります。 ・再始動タイムアウト 再始動時に停止から始動までに確保すべき時間を指定します。再始動時に開始のアクションがとられる 前に明示的にアプリケーション・サーバーのステータスの確認が行われます。このステータスの確認が行 われる前にどのくらい停止の完了を待つかを指定します。アプリケーションの起動/停止の負荷が高い環 境では有効な設定項目です。 ・再始動禁止期間 業務のピーク時など、再始動が発生するのを禁止時間を指定します。禁止期間中に発生したヘルス条件 による再始動は保留され、再始動禁止期間が過ぎたあとに再始動が発生します。この再始動禁止期間は 複数設定することが可能です。また深夜０時を跨ぐ場合（例えば22:00~02:00）は複数に分割して（22:00 ∼23:59と0:00∼2:00）設定してください。 23 ヘルス・ポリシーの設定 WebSphere XD5.1 Technical Guide 4つのタイプのヘルス条件から設定 モニタリング対象を指定 セル全体 動的クラスター/クラスター/アプリケーションサーバー モードの設定 期間ベース条件 −サーバーが開始してからの期間 ワークロード条件 − サーバーが処理した総リクエスト数 超過メモリー条件 − 最大ヒープサイズに対するメモリー使用量の割合 経過応答時間条件 − 平均レスポンス・タイム モニター − 状況の監視とタスク（情報のみ）の通知 監視 − 状況の監視とタスクの通知。タスクではアクションを提案。 アクションの実行にはユーザーの承諾が必要。 自動 − 状況の監視からアクション実行まで自動 ポリシーの変更は動的に反映される ヘルス・ポリシーは管理コンソール「オペレーショナル・ポリシー」→「ヘルス・ポリシー」から設定することが 可能です。ヘルス・ポリシーでは、以下の設定を行います。 ・ヘルス条件 − ４つのタイプの健康条件から選択し、タイプに応じて必要な項目を設定します。 ①期間ベース条件 – サーバーの総稼動期間が特定の値に到達したときに、このポリシーに関連する サーバーを再始動します。 ②ワークロード条件 – サーバーの総処理リクエスト数が特定の数に達し機時に、このポリシーに関連す るサーバーが再始動します。 ③超過メモリー条件 - メモリー使用量が、特定の時間の間、最大ヒープ・サイズの特定の割合を超過し た場合、このポリシーに関連するサーバーが再始動されます。 ④超過応答時間条件 - 平均応答時間が特定の時間より長くかかった場合、このポリシーに関連する サーバーが再始動されます。 ・リアクション・モード − モニター、監視、自動の3つから選択します。 ・メンバーシップ− このヘルス・ポリシーでモニターする対象を指定します 24 第2章 Dynamic Operations WebSphere XD5.1 Technical Guide 1. Dynamic Operations概要 2. Autonomic Managers 3. Dynamic Operationsの構成 4. On Demand Routerの構成 5. Dynamic Operationsの運用 25 Dynamic Operations環境構成手順 WebSphere XD5.1 Technical Guide ① ① WebSphere WebSphere XD XD 導入 導入 ③ ③ Dynamic Dynamic Operations環境構成 Operations環境構成 (1)セル構成 (1)ノード･グループの作成 (2)XD導入 (2)動的クラスターの作成 (3)アプリケーションの導入 ② ② ODR構成 ODR構成 (4)サービス･クラスの定義 (1)ODR作成 (5)トランザクション･クラスの定義 Dynamic Operations環境の構成手順としては、大きく分けて3つのステップからなります。 ①WebSphere XD導入 まず前提となるWebSphere ND V5.1.1のCell環境を構成します。次にDMおよびAppServerノードそれ ぞれにXDを導入します。 ②ODRの構成 XD導入後にODRノードでODRサーバーを作成します。ODRはCell環境のAppServerノード上に構成 されます。 ③Dynamic Operations環境構成 ノードグループの作成、動的クラスターの構成とアプリケーションの導入、およびオペレーショナル・ポリ シー定義のステップが含まれます。 26 ① WebSphere XD導入 WebSphere XD5.1 Technical Guide ① ① WebSphere WebSphere XD導入 XD導入 (1) セルの構成 DM Cell addNode ODR ODR XDの前提となるCell環境の構築 AppServer/DM V5.1.1.1 JDK 1.4.2 SR1 AppServer AppServer AppServer (2)XD導入 DM XD ODR XD ODR XD AppServer/DMの 各ノードにXD導入 Cell AppServer XD AppServer XD AppServer XD (1)WebSphere NDセル環境の構成 AppServerおよびODRノードにWAS V5.1.1.1のAppServerを導入します（ODRはWebSphereセル環 境のAppServerの上に構成されます）。 DMノードにWAS ND V5.1.1.1のDeploymentManagerを導入します。 また、前提となるJDKのFix（V1.4.2 SR1)の適用も忘れず行ってください。 各AppServerおよびODRノードでaddNodeコマンドを発行してセルに統合し、DMの管理下に構成しま す。 (2)WebSphere XDの導入 DMおよび各AppServerノード、ODRノードにXDを導入します。XDはWebSphere ND環境の上にかぶ せるようなイメージで導入されます。 27 ② ODR構成手順 WebSphere XD5.1 Technical Guide ② ② ODR構成 ODR構成 (1) ODR作成 (1)ODR作成 ODRを構成するノードには事前にWAS V5.1.1とXDが導入されている必要があります。 ○管理コンソールからのODRの作成 1.「サーバー」→「オンデマンド・ルーター」を開き、「新規作成」をクリックします 2.「新規オンデマンド・ルーター・エントリーの作成」の画面が開きますので、ステップ１ではODRノードお よびODRの名前を指定し、「次へ」をクリックします。 3.ステップ２では設定を確認し、「終了」を押します ○コマンドからのODRの作成 DMノードのbinディレクトリでwsadmin+提供されているJACLスクリプトを実行してODRを作成することも 可能です。 wsadmin –f createodr.jacl <ODR_node> 作成が正常終了したら、管理コンソールの「オンデマンド・ルーター」のページで確認できます。 作成されたODR名をクリックして開いたページから、ODRの各種設定が可能です。 28 ③ Dynamic Operations環境構成 WebSphere XD5.1 Technical Guide Node Group Cell ③ ③ Dynamic Dynamic Operations環境構成 Operations環境構成 (1)ノード･グループの作成 Node Group (2)動的クラスターの作成 Cell Dynamic Cluster (3)アプリケーションの導入 (4)サービス･クラスの定義 Node Group Cell Dynamic Cluster ear (5)トランザクション･クラスの定義 Service Policy AS ※ 参考：静的クラスター AS AS AS Cell （Static） Cluster (1)ノード・グループの作成 Dynamic Operations環境を構成するためには、アプリケーション導入環境となる仮想化されたインフラが 必要となります。これがノード・グループです。ノードグループはセル内の仮想化対象となるノードを束ねる 単位で、セル内には複数のノード･グループを定義することが可能です。ノードはいずれか１つのノードグ ループにメンバーとして登録されることで、プールされます。 (2)動的クラスターの作成 動的クラスターは、1つのノード･グループにマッピングして定義されます。従来の（静的）クラスターでは AppServerとの関連付けが固定的でしたが、動的クラスターではノード･グループをポイントしているので、 クラスターのメンバーはノード･グループ内のノード上に動的に追加・変更することが可能になります。 (3)アプリケーションの導入 Dynamic Operations環境で制御されるアプリケーションはこの動的クラスター上に導入します。アプリ ケーションをAppServerやクラスターに対して導入するのと同様に、導入時にターゲットとして動的クラス ターを指定します。 (4)(5)オペレーショナル・ポリシーの定義 オペレーショナル・ポリシーではサービス・クラスとトランザクション・クラスを定義します。サービス・クラスと はアプリケーションの平均レスポンスタイムのゴールと重要度を指定し、仮想化されたWebSphereインフ ラの運用方針を定義する情報です。次にトランザクション・クラスの定義を行います。これは各サービス・ク ラスとWebのリクエストとのマッピングとなります。 29 ③ Dynamic Operations環境構成-(1) WebSphere XD5.1 Technical Guide (1) ノード・グループの作成 （１）ノード･グループの作成 まずはリソース･プールとなるノード･グループを作成し、セル内のノードを登録します。 １．管理コンソールから「システム管理」→「ノード･グループ」から「新規作成」を実行します。 ２．ステップ１では「名前」に作成するノード・グループ名を入力します。 ３．ステップ２ではノード・グループに参加させるノードを使用可能なノードのリストから選択し、「追加>>」 をクリックしてメンバーに追加します。 ４．ステップ３で内容を確認して「終了」をクリックします。 ５．ノード・グループの画面で作成したノード・グループが登録されていること、およびメンバーの数を確 認します。 30 ③ Dynamic Operations環境構成-(2) WebSphere XD5.1 Technical Guide (2) 動的クラスターの作成 （２）動的クラスターの作成 次に動的クラスターを作成し、ノード･グループにマップします。 １．管理コンソールで「サーバー」→「動的クラスター」から「新規作成」を実行します。 ２．動的クラスターは、静的クラスターの作成手順とほぼ同様に作成します。 ・動的クラスター名に名前を入力し、必要に応じて「ローカルを優先」や内部複製ドメインの設定を行 います。 ・動的クラスター固有の設定として、動的クラスターではノード・グループへマップします。この動的ク ラスターをマップするノードグループを選択してください ・テンプレートの選択では動的クラスターのメンバーのテンプレートとして既存のサーバーまたはサー バーテンプレートを選択します。 ・最後に、活動時に開始するメンバー・インスタンスの最小数とインスタンスの最大数を指定します。 動的クラスターは自動モードで起動すると最少数に指定した数のインスタンスが初期状態として起動 します。その後、アプリケーション配置コントローラーによってインスタンスの数が指定した最大値まで 動的に起動されることが可能です。 ３．ステップ２では設定した内容を確認して「終了」をクリックします。 31 ③ Dynamic Operations環境構成-(3) WebSphere XD5.1 Technical Guide (3) アプリケーションの導入 （３）アプリケーションの導入 アプリケーションを(2)で作成した動的クラスターに導入します。 １．管理コンソールで「アプリケーション」→「新規アプリケーションのインストール」を実行します。 ２．導入ウィザードにしたがって、WAS NDでの通常のアプリケーション導入と同様にインストールしてい きます。 ３．「モジュールをアプリケーション・サーバーにマップ」のステップで、WAS NDでは導入する先として AppServerやクラスターをマップしますが、XDではここで動的クラスターを指定します。上記画面では エンタープライズ・アプリケーション［StockTrade］を、先ほど作成した動的クラスター［DynaCluster1］ にマップしています。 ４．ウィザードにしたがって導入を終了します。 32 ③ Dynamic Operations環境構成-(4) WebSphere XD5.1 Technical Guide (4) サービス・ポリシーの定義 (4)サービス･クラスの定義 ここではサービス･ポリシーの定義として、まずサービス・クラスを作成します。 １．管理コンソールで「オペレーショナル・ポリシー」→「サービス･ポリシー」から「新規作成」をクリックしま す。 ２．ステップ１では作成するサービス・ポリシーの名前と「ゴールタイプ」を｛任意｜平均応答時間｜百分 位数応答時間｝の中から選択します。 ３．ステップ2では「ゴール値」と重要度を設定します。ここではゴール値として500ミリ秒、重要度（7段階） を一番高い「最高」に設定しています。 ４．ステップ3ではこのサービス・クラスのメンバーとなるトランザクション・クラスを指定します。現段階では まだトランザクション・クラスは作成されていないため、ここではメンバーは登録しないまま「次へ」をク リックします。（トランザクション・クラスの作成とサービス・ポリシーへの登録はこの後のステップで行い ます） ５．設定した内容を確認して終了します。 33 ③ Dynamic Operations環境構成-(5) WebSphere XD5.1 Technical Guide (5) トランザクション・クラスの定義 (5)トランザクション・クラスの作成 最後にトランザクション・クラスを作成し、サービス・クラスにマップすることで、運用ポリシーが完成します。 １．管理コンソールで「オペレーショナル・ポリシー」→「サービス･ポリシー」から(4)で作成した 「Platinum」クラスをクリックします。 ２．「トランザクション・クラス」→「新規」を実行してトランザクション・クラスの作成ウィザードを開始します。 ３．ステップ１でトランザクション・クラス名を指定します。 ４．ステップ2でトランザクション・クラスのURIパターンを定義します。「エンタープライズ・アプリケーショ ン」と「モジュール」を選択するとそのモジュールに対して使用可能なURIが表示されるため、リストか らトランザクション・クラスに定義したURIを選択して「追加＞＞」を押すか、「カスタムURIパターン」に 入力し「パターンの追加>>」を実行してください。 ５．ステップ3で「終了」をクリックすると、Platinumサービス・クラスの構成画面に戻りますので、先ほど作 成したトランザクション・クラスがメンバーとして登録されていることを確認して「OK」をクリックします。 ６．サービス・ポリシーの定義は以上で終了です。 以上でDynamic Operations環境の構築ステップは終了です。必要に応じて、以上のステップを繰り返し て、ノードグループ、動的クラスター、アプリケーションのインストールとサービス・ポリシーの作成を 行ってください。 34 第2章 Dynamic Operations WebSphere XD5.1 Technical Guide 1. Dynamic Operations概要 2. Autonomic Managers 3. Dynamic Operationsの構成 4. On Demand Routerの構成 5. Dynamic Operationsの運用 35 XD環境への割振り WebSphere XD5.1 Technical Guide On Demand Configuration XD環境への割振りはODC機能により自動的に対応されます 割振り先となるXDノードの情報を自動的に更新 ルーティング情報（仮想ホスト、アプリケーションのURI） エンドポイント情報（Application Serverのホスト名、ポート番号） アプリケーションの再配置（インストール/アンインストール）を自動検知 構成情報はODRのtarget.xmlに保管される <ODR_ROOT>¥installedFilters¥wlm¥odr¥target.xmlに保管される ノード・グループ情報（ARFMパラメータなど） ノード情報(CPU Spec） サーバー情報（dWLMウェイト値、エンド・ポイント情報など） 仮想ホスト・アプリケーション関連情報 動的クラスター情報（マッピングされたノード・グループおよびノード, 導入 Webモジュール） 運用ポリシー情報 • サービス・クラス（平均レスポンスと重要度の定義） • トランザクション・クラス（ポリシー定義の対象となるURI) XD環境への割振りは、ODR上のオンデマンド・コンフィグレーション(ODC)機能により、自動的にルー ティング情報が更新され割振りが行われます。 ODCは割振り先となるXDノードのAppServerへのルーティング情報（仮想ホスト、アプリケーションの URI）やエンドポイント情報（AppServerのホスト名、ポート番号）を自動的に更新します。またアプリケー ション配置コントローラー（APC）によって変更されるアプリケーションの再配置の情報も自動検知します。 これらの構成情報はODRのtarget.xml (<ODR_Root>/installedFilters/wlm/odr/target.xml) に格納され ODCがこの情報を更新します。dWLMはこのtarget.xmlの情報をもとにバックエンドAppServerへのルー ティングを行います。 36 別Cell環境への割振り WebSphere XD5.1 Technical Guide 別Cell環境に対するリクエストの割振り ODRとAppServerノードを別Cellに分けることも可能です。 ODRとAppServerの間にFirewallをおき、別ネットワークに配置するトポロジーなどに 利用できます Cell2 Cell1 Node XD Agent ODR XD Node XD Agent ODR XD DM XD Node XD Agent AppServer XD AppServer XD Node XD Agent AppServer XD DM XD Node XD Agent AppServer XD Cell3 XDのODR環境では、設定を行うことによって、別Cell環境に存在するXDノードへの割振りも可能になりま す。これにより、ODR用のCell環境およびAppServer用のCell環境を分割することも可能になります。セ キュリティー上の観点からネットワークを別にわけ、アプリケーションの稼働環境はよりセキュアな場所に配 置するトポロジーなどに利用します。 37 別Cell環境への割振り WebSphere XD5.1 Technical Guide 構成方法 1. XD-CGB-EXPORTSファイルの用意 <DM_ROOT>¥config¥cells¥<CellName>または<WAS_ROOT>¥config¥cells¥<CellName> ディレクトリ下にある（セル内ではファイル内容は同一） 各セルから、連携相手セルのDMノードにXD-CGB-EXPORTSファイルをコピー 2. Cell間にFirewallが存在する場合は、通信用のポートを開ける 開けるべきポートはXD-CGB-EXPORTSファイルで確認 3. DMノードで、crossCellCGBCfg.batを実行 <DM_ROOT>¥bin¥crossCellCGBCfg.bat create <DM名> <DM SOAP ポート> <別セルのXD-CGB-EXPORTのパス> これによりODRが別Cellを認知できるようになる <DM_ROOT>¥config¥cells¥<CellName>ディレクトリ下のcoregroupbridge.xmlに反映される 変更されたcoregroupbridge.xmlはCell内の各AppServerに自動で配布される 4. 全てのCell内の全プロセスを再起動 別Cell環境への割振りを行うには、Cell間でのコミュニケーションが行えるように設定する必要があります。 設定方法としては以下のとおりです。 １．まず各CellのXD-CGB-EXPORTSファイルを用意します。各ノードの <WAS_ROOT>¥config¥cells¥<CellName>ディレクトリー下に配置されていますので、これを連携相手 CellのDeployment Managerノードへとコピーします。 ２．Cell間にFirewallが存在する場合は、Cell間通信が行えるように通信用ポートを空けてください。開け るべきポートはXD-CGB-EXPORTSファイルで確認できます（NodeAgentのエンド・ポイントで DCS_CGBS_UNICAST_ADDRESSに定義されているポートになります）。 ３．DMノードで上記のとおり、crossCellCGBCfg.batを実行します。このコマンドを実行することにより別 Cellを認知することが可能になります。このコマンドの実行結果は <DM_ROOT>¥config¥cells¥<CellName>ディレクトリ下のcoregroupbridge.xmlに反映され、各 AppServerノードに配布されます。 ４．コマンドの実行後、全てのCell内のプロセスを再起動して、設定を反映させます。 この作業をコミュニケーションを行う必要のあるCell間双方で行います。 38 Non-XD環境への割振り WebSphere XD5.1 Technical Guide ODRからXD以外の環境にリクエストを割り振ることも可能 構成手順 1. 汎用サーバー・クラスターの作成 ①管理コンソールから「サーバー」→「汎 用サーバークラスター」を選択し、汎用 サーバー・クラスターを新規作成する ②作成された汎用サーバー・クラスター の追加プロパティから「ポート」を選択 ③「ポート」のエントリーとして、汎用サーバー・ク ラスターのメンバーを登録する。 必要な情報は、ホスト名（IPアドレス）・ポート・プ ロトコル（HTTP/HTTPS）・静的ウェイト値の４つ。 On Demand RouterはXD環境のみでなく、通常のWAS-ND環境またはNon-WebSphere環境へもリク エストを割振ることができます。 Non-XD環境へ割振りを行うには、「汎用サーバー・クラスター」の設定を作成します。 １．汎用サーバー・クラスターの作成 ①管理コンソールから「サーバー」→「汎用サーバー・クラスター」を選択し、新規作成をクリックします開 いた画面で汎用サーバー・クラスターの名前を指定し、OKを選択します。 ②作成した汎用サーバー・クラスター名をクリックして、追加プロパティの「ポート」をクリックします。 ③ポート画面のエントリーとして、汎用サーバー・クラスターのメンバーとなるノードの情報を入力し、OK を選択します。必要となる情報は、ホスト名（IPアドレス）、ポート、プロトコル（HTTP/HTTPS）および静的 ウェイト値の４つです。 39 Non-XD環境への割振り WebSphere XD5.1 Technical Guide 構成手順（つづき） 2. URIグループの作成 汎用サーバー・クラスターへと ForwardするリクエストをURL毎 にグルーピング 3. ルーティング・ルールの作成 URIグループ単位にルーティング・ルールを作成 ルールとして「汎用サーバー・クラスター」を選択し、Forward先の汎用サーバー・クラ スターを指定する ２．URIグループの作成 管理コンソール「環境」→「URIグループ」を選択し、URIグループの新規作成をクリックします。汎用サー バー・クラスターで処理を行いたいURIパターンと管理用のURIグループ名を指定してOKを選択しま す。汎用サーバー・クラスターへの割振りやSorry Serverへの割振りも、このURIグループ単位で指 定しますので、運用管理しやすい単位でまとめます。 ３．ルーティング・ルールの作成 ２で作成したURIグループと割振り先（汎用サーバー・クラスター）のマッピングを行います。管理コンソー ル「サーバー」→「オンデマンド・ルーター」→＜ODR名＞から追加プロパティ「ルーティング・ルール」 を開きます。ルーティング・ルールの設定画面から、ルール名と仮想ホスト名およびURIグループを指 定します。ルーティング・ルールでは汎用サーバー・クラスターを指定し、リクエストを処理すべき汎用 サーバー・クラスターを選択します。このルーティング・ルールを有効にするには、「このルールを使用 可能にする」のチェックボックスにチェックを入れて、ODRを再起動してください。 40 カスタム・エラーページの設定 WebSphere XD5.1 Technical Guide カスタマイズされたエラー・ページをクライアントに返すことが可能です ① エラー・ページを生成するアプリケーションをODR上に導入します サンプル(HTTPErrorHandler.ear)が<ODR_ROOT>¥installableAppsに提供されています 以下のように、wsadminでアプリケーションをODR上にインストールします 管理コンソールからはアプリケーションをODRにインストールすることができません <ODR_ROOT>¥bin¥wsadmin $wsadmin> $AdminApp install <ODR_ROOT>¥¥installableApps¥¥HttpErrorHandler.ear [list ‒server <ODR_Name> -node <ODR_Node> ] $wsadmin> $AdminConfig save ② カスタム・エラー・ページ・ポリシーの設定 ODRの設定画面で、カスタム・エラー・ページ・ポリシーを設定します。 「サーバー」→「オン･デマンド・ルーター」→<ODR名>→追加プロパティ「プロキシー設定」 「なし」のチェック・ボックスを外し、①で導入したアプリケーションのURIを指定します 「リモートエラーのハンドリング」を有効 にすることで、AppServerで発生したエ ラーもハンドリング可能 このポリシーでハンドリングする HTTPステータス・コードを指定 Xをワイルド・カードとして使用可能 例）「４XX」は400番台全てを指す ODRが、ODRやAppServerの返すエラー・ページをハンドリングして、カスタマイズされたエラー・ページ をクライアントに返すことが可能です。 ①エラー・ページ生成アプリケーションの導入 ODR上にエラー・ページを生成する用のアプリケーションを上記のようにwsadminを用いて導入します。 サンプル・アプリケーションとしてHTTPErrorHandler.earが<ODR_ROOT>¥installableAppsディレクトリ の下に提供されています。なお、ODR上へのアプリケーション導入は管理コンソールからは行うことができ ません。 ②カスタム・エラー・ページ・ポリシーの設定 管理コンソール「サーバー」→「オンデマンド・ルーター」→＜ODR名＞から追加プロパティ「プロキシー設 定」を選択します。一般プロパティ「カスタム・エラー・ページ・ポリシー」の「なし」のチェックボックスを外し、 ①で導入したアプリケーションのURIを指定します。このカスタム・エラー・ページ・ポリシーでハンドリング すべきHTTPステータス・コードを指定します。ワイルドカードとしては「X」が使用できます。AppServerで 発生したエラーについても、ODRで生成したエラー・ページを返す場合には「リモート・エラーのハンドル」 のチェックボックスにチェックを入れてください。 41 Sorryページの表示 WebSphere XD5.1 Technical Guide ODRからSorryページへと割振ることが可能 あらかじめSorryページ用のルーティング・ルールを用意しておく メンテナンス時には、管理コンソールからルーティング・ルールの有効/無効を切り 替え、ODRの再起動を行う 構成手順 1. URIグループの定義 管理コンソール「環境」→「URIグループ」からアクセス 同じタイミングで管理を行うアプリケーションをグループ化可能 ルーティング・ルールを利用することにより、リクエストが割振られるサーバーを変更することができます。こ れによりメンテナンス時などにルーティング・ルールの有効/無効を切り替えることにより、特定のURLに対 してはSorryページを返すといったことが可能になります。 まず、URIグループの定義を行います。URIグループ単位でルーティング・ルールを設定しますので、同 じタイミングでメンテナンスを行うアプリケーションのURIはひとつのURIグループにまとめておくこともでき ます。 42 Sorryページの表示 WebSphere XD5.1 Technical Guide 構成手順（つづき） 2. ルーティング・ルールの定義 管理コンソール「サーバー」→「オン･デマンド・ルーター」→<ODR名>→追加プロパティ 「ルーティング・ルール」でアクセス URIグループ毎にリクエストのルーティング先をマッピングする 通常時は「このルールを使用可能にする」のチェックボックスを外しておく ルーティング・ルールにより3種類の割振り方法がある 汎用サーバークラスターへとリクエストをForwardする方法 HTTPのエラー・ステータス・コードを返し、それに応じた画面を生成する方法 リクエストを指定したURLにリダイレクトする方法 次にルーティング・ルールの設定です。１で作成したURIグループごとにルーティング・ルールを作成して いきます。ルーティング・ルール名と仮想ホスト、およびURIグループを指定します。Sorryページ表示用 のルールであれば、通常時は使いませんので、「このルールを使用可能にする」のチェックボックスを外し ておきます。 Sorryページの表示方法としては、ルーティング・ルールに３通りのやり方に対応した３通りの表示方法が あります。これについては次ページから説明します。 43 Sorryページの表示 WebSphere XD5.1 Technical Guide 汎用サーバークラスターへとリクエストをForwardする方法 ルーティング・ルールで汎用サーバー・クラスターを指定 Webサーバーの設定 汎用サーバー・クラスター内で定義されているWebサーバーで不特定のリクエストに応 答を返せるように構成 IHSの場合、httpd.confの中で以下のようにAliasMatchディレクティブを設定 AliasMatch ^/.*sorryImage.gif /usr/IBMIHS/htdocs/ja_JP/sorryImage.gif AliasMatch ^/.* /usr/IBMIHS/htdocs/ja_JP/sorry.html <HTML> <HEAD> <TITLE>SorryPage.html</TITLE> <META http-equiv="Expires" content="0"> <META http-equiv="Pragma" content="No-cache"> <META http-equiv="Cache-Control" content="no-cache"> </HEAD> <BODY> <H2>Sorry for your Inconvenience.</H2> <H2>Service is Temporally Unavailable.</H2> <img src=”sorryImage.gif" alt=”sorryImage"> </BODY> </HTML> SorryPageがキャッシュされない ように、左例のようにキャッシュ制 御のMETAタグを挿入 １つ目のSorryページの表示方法が汎用サーバー・クラスターを利用した設定です。 あらかじめ、Sorry ServerとなるWebサーバーを汎用サーバー・クラスターとして登録しておきます。ルー ティング・ルールで「汎用サーバー・クラスター」を選択し、Sorry Serverメンバーからできている汎用サー バー・クラスターを指定します。 汎用サーバー・クラスターのメンバーとなるWebサーバー側の設定は、通常Edge Componentの LoadBalancerを利用する際などに構築するSorry Serverと同様です。Sorry Serverのhttpd.confでは、 リクエストがどのようなパスで来てもエラー・ページを返せるようにAliasMatchディレクティブを使用します。 ^/.*を処理するAliasMatchディレクティブだけですと、Sorryページ内の画像にまで、Sorryページが返さ れてしまいますので、エラー・ページ内に画像がある場合は、先に画像ファイルがマッチングするように別 にAliasMatchディレクティブを用意してください。またSorryページがブラウザーにキャッシュされないよう、 METAタグなどでキャッシュを無効化するようにしてください。 44 Sorryページの表示 WebSphere XD5.1 Technical Guide ODRでHTTPのエラー・ステータス・コードを返す方法 ルーティング・ルールで失敗状況コードを指定 カスタム・エラー・ページ・ポリシーで設定したエラー・ページがクライアントに返る 指定したURLにリクエストをリダイレクトする方法 ルーティング・ルールでリダイレクトを選択し、リダイレクト先URLを入力 Locationヘッダーにリダイレクト先URLを含め て、”302 Found”のステータス・コードを返す ODR ① GET /StockTrade/trade HTTP/1.1 ② HTTP/1.1 302 Found Location: http://sorryServer/sorry.html ③ GET /sorry.html HTTP/1.1 改めてLocationヘッダーで指定 されたURLにリクエストを送る ④ HTTP/1.1 200 OK XD XD XD Sorry Server ２つ目のSorryページの表示方法は、失敗状況コードを利用した設定です。 ルーティング・ルールに失敗状況コードを指定し、指定したURIグループに対するリクエストが届いた際に ODRが返すHTTPステータス・コードを指定します。カスタム・エラー・ページ・ポリシーで、ここで設定した HTTPステータス・コードをハンドリングするように指定しておけば、カスタム・エラー・ページ・ポリシーで設 定したエラー・ページを返すことができます。 ３つ目のSorryページの表示方法としては、リクエストをリダイレクトさせる方法です。 ルーティング・ルーでリダイレクトURLを選択し、リダイレクト先のURLを指定します。この設定を行うことに より、指定したURIグループにリクエストが届いた際には、ODRは302 FoundのHTTPステータス・コードを 返し、そのLocationヘッダー内にリダイレクト先URLを含めてクライアントに送ります。このレスポンスを受 け取ったクライアント（ブラウザー）は改めてLocationヘッダーで指定されたURLにリクエストを送ります。 45 SSL通信の設定概要 WebSphere XD5.1 Technical Guide SSL通信のために以下の設定作業が必要です ① ② ③ ④ ⑤ ⑥ 鍵ストア・ファイルの作成 トラストストア・ファイルの作成 鍵ストア・ファイルへの証明書の導入 トラストストア・ファイルへの署名者証明書のインポート 管理コンソールからの「SSL構成レパートリー」の設定 インバウンドSSL設定およびアウトバウンドSSL設定 デフォルトのSSLKeyファイルはテスト用です。 デフォルトで用意されている以下のSSLKeyファイルは、テスト環境のみでの使用を 前提としており、本番環境での使用は推奨されません。 DummyClientKeyFile.jks DummyServerKeyFile.jks DummyClientTrustFile.jks DummyServerTrustFile.jks SSL通信を構成するためのStepとしては、通常のWAS ND環境と同様、以下の作業が必要となります。 ①鍵ストア・ファイルの作成 ②トラストストア・ファイルの作成 ③鍵ストア・ファイルへの証明書の導入 ④トラストストア・ファイルへの署名者証明書のインポート ⑤管理コンソールからの「SSL構成レパートリー」の設定 ⑥インバウンドSSL設定およびアウトバウンドSSL設定 なお本番環境でのSSL通信には、デフォルトで用意されているSSLKeyファイルの使用は推奨されません。 あくまでテスト環境での使用を前提とし、便宜的に提供されているものです。 46 SSL通信の設定 WebSphere XD5.1 Technical Guide ① 鍵ストア・ファイルの作成 証明書を保管するための鍵ストア・ファイルを作成します。 1. 2. 3. ikeymanを起動し、「鍵データベース・ファイル」→「新規」をクリックします 鍵データベース・タイプ、ファイル名、ファイル・パスを指定し、「OK」を選択します。 鍵ストア・ファイル・パスワードを設定し、「OK」を選択します。 ② トラストストア・ファイルの作成 公開鍵を保管するためのトラストストア・ファイルを①と同様の手順で作成します。 1. 2. 3. ikeymanを起動し、「鍵データベース・ファイル」⇒「新規」をクリックします 鍵データベース・タイプ、ファイル名、ファイル・パスを指定し、「OK」を選択します。 鍵ストア・ファイル・パスワードを設定し、「OK」を選択します。 ①鍵ストア・ファイルの作成 まずSSLのサーバー証明書を保管するための鍵ストア・ファイルを作成します。鍵ストア・ファイルには署 名者証明書（公開鍵）と個人用証明書（秘密鍵）の両方が含まれます。 ②次に通信相手の公開鍵を保管するためのトラストストア・ファイルを①と同様の手順で作成します。 なおここでトラスト・ファイルを作成せずに、SSLレパートリーの設定（後述）で鍵ストア・ファイルのみを指定 した場合、署名者証明書と個人用証明書の両方の検索に鍵ストア・ファイルが使用されます。 47 SSL通信の設定 WebSphere XD5.1 Technical Guide ③ 鍵ストア・ファイルへの証明書の導入 CA署名付き証明書の導入 ODRなどユーザーが直接アクセスするサーバーにはCA署名付き証明書を導入します。 CA署名付き証明書を導入するには以下のステップが必要になります。 1. 2. 3. 4. 5. ikeymanを起動し、①で作成した鍵ストア・ファイルを開きます。 「作成」→「新規証明書要求」から証明書要求を作成し、 作成された証明書要求ファイル （certreq.armなど）をCA（認証局）に送付します CAから証明書が発行されたら、ikeymanで証明書要求を作成した鍵ストア・ファイルを開きます 「個人用証明書」画面の「受信」ボタンを選択し、発行された証明書のパスとファイル名を指定し ます 証明書にラベル名（証明書の表示名）を設定し、「OK」を選択します。 自己署名証明書の作成 CA署名付き証明書の代わりに自己署名証明書を作成することもできます ODR-AppServer間などユーザーが直接アクセスしないSSL通信やテスト環境での利用 には自己署名証明書を利用することができます。 自己署名証明書を作成するには以下のステップが必要になります。 1. 2. 3. ikeymanを起動し、①で作成した鍵ストア・ファイルを開きます。 「作成」→「新規自己署名証明書」を選択します。 鍵ラベル名など必要な項目を入力し、「OK」を選択します。 ③鍵ストア・ファイルへサーバー証明書を導入します。 CA署名付き証明書を導入する場合、鍵管理ツール（ikeyman）を起動し、①で作成した鍵ストア・ファイル を開きます。次に新規証明書要求を作成し、作成された証明書要求ファイルをCA（認証局）に送付します。 これにより認証局により証明書が発行されます。証明書が発行されたら、ikeymanで同じ鍵ストア・ファイ ルを開き、証明書を受信します。詳細な手順は、鍵管理ツールのマニュアルおよびご利用される認証局 の情報をご確認ください。 また、ODR-AppServer間などユーザーが直接アクセスを行わないSSL通信やテスト環境での利用には 自己署名証明書を利用することができます。鍵管理ツールを起動し、新規自己署名証明書を選択します。 ホスト名や組織、鍵ラベルなど必要な情報を入力し、証明書を作成して下さい。 48 SSL通信の設定 WebSphere XD5.1 Technical Guide ④ トラストストア・ファイルへの署名者証明書（公開鍵）のインポート CA署名付き証明書を利用している場合 ②で作成したトラスト・ファイルの署名者証明書に、署名を行った認証局 (CA) の署名者 証明書（ルート証明書および中間証明書）がすでに含まれている場合は、特に作業は 必要ありません（有効期限の確認は行ってください） 自己署名証明書を利用している場合 自己署名証明書から署名者証明書（公開鍵）を抽出し、そのサーバーと通信をするクラ イアントのトラストストア・ファイルに追加します これは自己署名証明書の発行者を、あらかじめ信頼する署名者として登録する処理に なります。手順としては以下の通りです 1. 2. 3. 4. 5. 6. この証明書を発行したのは信 頼できるあの人だから、あの 人が署名した証明書を持つあ のサーバーは信用できる！ ikeymanを起動し、③で自己署名証明書を作成・保管した鍵ストア・ファイルを開きます 「個人用証明書」の画面で③で作成した自己署名証明書を選択し、「証明書の抽出」ボタンをク リックします。 証明書ファイル名（cert.armなど）とファイルの抽出先ディレクトリを指定し、「OK」を選択します。 crear.armをクライアントの任意のディレクトリにFTPします クライアント側でikeymanを起動し、トラストストア・ファイルを開きます。 「署名者証明書」の画面で「追加」を選択し、FTPしてきたcert.armを指定し、「OK」を選択します。 client server この証明書は僕 が署名したから 信用できるよ！ ④トラストストア・ファイルへの署名者証明書（公開鍵）のインポート CA署名付き証明書を利用している場合、鍵管理ツールによって代表的な認証局の署名者証明書は用 意されていますので、特に作業は必要ありません。但し、あくまで鍵管理ツールで用意される署名者証明 書は便宜的に提供されているものですので、有効期限の確認（必要に応じて署名者証明書の更新）は管 理者の責任で行う必要があります。 自己署名証明書を使用している場合は、自己署名証明書から署名者証明書（公開鍵）を抽出し、その SSL通信のクライアントとなるサーバーのトラストストア・ファイルに公開鍵を導入する必要があります。自己 署名証明書は自己署名ですので、誰もその正当性を保障していません。このトラストストア・ファイルに署 名者証明書を追加することは、自己署名証明書の発行者を信頼する署名者として登録する意味の作業 になります。 49 SSL通信の設定 WebSphere XD5.1 Technical Guide ⑤ SSLレパートリーの設定 管理コンソール「セキュリティー」→「SSL」を開き、「SSL構成エイリアス」で新規作成を選択 Alias名、鍵ファイル、トラストストア・ファイルの情報を入力 ⑤SSLレパートリーの設定 管理コンソール「セキュリティー」→「SSL」と開き、「SSL構成エイリアス」で新規作成を選択し、これまでに 作成した鍵ファイルおよびトラストストア・ファイルおよびそのパスワードなどを指定します。ここでトラスト・ ファイルを指定しなかった場合には、署名者証明書と個人用証明書の両方の検索に鍵ファイルが使用さ れることになります。 50 SSL通信の設定 ⑥ インバウンドSSL設定およびアウトバウンドSSL設定 WebSphere XD5.1 Technical Guide インバウンド SSL設定 アウトバウンド SSL設定 ODR XD XD インバウンドSSL設定 クライアント-ODR間通信用のSSL設定です。 スクリプトを用いて設定します（V5.1.1のでは管理コンソールから設定できません） wsadmin -f updateInboundODRSSLAlias.jacl <nodename> <ODRName> <sslAlias> を実行 アウトバウンドSSL設定 ODRとAppServer間通信用のSSL設定です。 管理コンソールから設定可能です。 1. 2. クライアントに直接見えるわけではないので、自己署名証明書を使用することができます 「サーバー」→「オンデマンド・ルーター」→<ODR名>を開き、一般プロパティの「プロキシー設定」で設定し ます。 これまでに構成したSSLAliasの設定を利用して、SSL通信の設定を行います。XDではクライアント-ODR 間のSSL通信をインバウンドSSL、ODR-AppServer間のSSL通信をアウトバウンドSSLと呼びます。 インバウンドSSL通信は、updateInboundODRSSLAlias.jaclスクリプトを用いて設定します。このスクリプ トは5.1.2で提供される予定です。また管理コンソールからの設定も対応される予定となっています。 アウトバウンドSSL通信は管理コンソールから設定します。クライアントにここの通信で使用されている証明 書が渡されることはありませんので、自己署名証明書を用いることもできます。管理コンソールの「サー バー」→「オンデマンド・ルーター」→<ODR名>と開き、一般プロパティ「プロキシー設定」のコンテンツ・ サーバー接続の項目から設定を行います。 なお、この項目にある「コンテンツ・サーバーへのプール接続」にチェックボックスを入れることにより、コネ クションが使いまわされるようになりますので、無駄な接続の張り直しを減らすことができます。この設定は HTTP/SSLに関わらず有効な設定です。 51 HTTPメソッドの無効化 WebSphere XD5.1 Technical Guide デフォルトで有効なメソッド デフォルトで無効とされているメソッド GET、POST、HEAD、TRACE、OPTIONS CONNECT、PUT、DELETE メソッドの無効化 管理コンソール「サーバー」→「オンデマンド・ルーター」→<ODR名>→追加プロパティ「プロ キシー設定」でアクセス 一般プロパティ「排他」に無効化したいメソッドを1行に１つずつ記述 無効なメソッドのリクエストには「405 Method Not Allowed」エラーが返される ODRでデフォルトで有効となっているHTTPメソッドは以下のとおりです。 GET、POST、HEAD、TRACE、OPTIONS また以下のメソッドがデフォルトで無効化されています。 CONNECT、PUT、DELETE 使用しないHTTPメソッドを無効化することでセキュリティを強化することが可能です。管理コンソールの 「サーバー」→「オンデマンド・ルーター」→＜ODR名＞の追加プロパティ「プロキシー設定」を開き、「排 他」の項目に無効化したいメソッドを1行に１つずつ記述します。 52 WebServer Pluginとの連携 WebSphere XD5.1 Technical Guide XDではWebServerの配置はオプショナル DMZなどセキュリティーの観点での配置 アクセス・ログの観点での配置 ODR Web Server Firewall XD XD XD Firewall WebServerの配置にはODR用plugin-cfg.xmlの生成が必要 管理コンソール「サーバー」→「オンデマンド・ルーター」→<ODR名>→追加プロパティ「プロキシー設定」→ プロキシー・プラグイン構成ポリシーより設定 ODR用にplugin構成ファイルを生成するには「なし」のチェックボックスを外す 構成ファイルに含まれる内容は「全て」「セル」「ノード」「サーバー」の４つのレベルで設定可能 構成ファイルが生成されたタイミングで呼び出されるスクリプトも指定可能 生成されたplugin-cfg.xmlをWebServerに読み込ませる <ODR_ROOT>¥etcディレクトリの下に生成される トポロジーにあわせて適宜レベルを選択します スクリプトはODRノード上に配置します。 XDではODRが８０番ポートをListenし、ODRがリクエストをAppServerに割振りますので、通常のWASの ようにWebServerをAppServerの前段に建てることは必須ではありません。しかしDMZを分けるなどセ キュリティ上の理由やアクセス・ログを記録する目的でWebサーバーをODRの前段に配置する構成も可 能です。 ODRの前段にWebServerを配置するには、ODR用にプラグイン構成ファイル（plugin-cfg.xml）を生成す る必要があります。 これを設定するには、管理コンソール「サーバー」→「オンデマンド・ルーター」→＜ODR名＞から追加プ ロパティ「プロキシー設定」を開きます。プロキシー・プラグイン構成ポリシーの「なし」のチェックボックスを 外します。これにより、構成変更がされたタイミングでODR用のplugin-cfg.xmlが生成されるようになります。 構成ファイルに含まれる内容は、全て・セル・ノード・サーバーの４つのレベルで設定可能です。そのODR が担当すべき処理範囲にあわせて設定して下さい。プラグイン構成ファイルは<ODR_ROOT>¥etcディ レクトリ下に生成されますので、通常のWASのリモートWebサーバー構成と同様にWebサーバー・ノード にコピーして、WebサーバーPluginに読み込ませてください。なおプラグイン構成ファイルが変更された 場合に実行されるスクリプトを指定することもできます。呼出したいスクリプトを「プラグイン構成変更スクリ プト」に指定し、変更が発生した際の通知に使うといった用途が考えられます。 53 第2章 Dynamic Operations WebSphere XD5.1 Technical Guide 1. Dynamic Operations概要 2. Autonomic Managers 3. Dynamic Operationsの構成 4. On Demand Routerの構成 5. Dynamic Operationsの運用 54 動的クラスターの運用モード WebSphere XD5.1 Technical Guide 動的クラスター単位で３つの運用モードを設定可能 自動 ‒ APC（アプリケーション配置コントローラー）による自動運用 手動 - APCを使用しないモード 監視 - APCの提案するアクションの実行に管理者の承諾が必要 モードは動的に変更が可能 「サーバー」→「動的クラスター」で設定 動的クラスターでは、動的クラスター単位で3つの運用モード（自動/手動/監視）を設定することができます。 設定したモードによって起動時、稼動中および停止時の振る舞いが異なります。 ① 自動モードでは、起動時、稼動中、停止時の振る舞いがすべてXDのアプリケーション配置コントロー ラー（APC）によって自動管理されます。 ② 手動モードでは、WAS NDの静的クラスターと同じモードで、APCによって振る舞いが管理されません。 管理者による手動での起動、停止が必要となります。 ③ 監視モードでは、APCによるモニタリングと分析は実施されますが、アクションの実行（プロビジョニン グ）には管理者の承諾が必要となります。 なお、運用モードは動的クラスター単位に設定が可能であり、動的に変更が可能です。 55 ３種類の運用モード WebSphere XD5.1 Technical Guide 自動モード 初期起動時を含めて、APCによる自動運用 APCによってモニタリング、解析、アクションが決定され自動実行される 手動モード APCによる運用はなし（アプリケーション配置は行われない） ユーザーによるモニタリングと解析、アクションの決定、実行が必要 システムの起動・停止時に手動モードに設定することで、ユーザーがサーバーの起 動・停止の実行を制御可能 自動に設定 手動に設定 Node Group Node Group Dynamic Cluster Dynamic Cluster APC 手動起動 自動起動 どのサーバーが起動されるかはAPCが決定 動的クラスターに設定した最小インスタンス数 のサーバーが起動される 管理者が個々のサーバーを起動 ここでは3つの運用モードに関して説明します。 自動モードでは全てAPCによる自動運用になります。動的クラスターの全てのメンバーが停止状態で モードを自動モードに設定すると、動的クラスターに設定した最小インスタンス数の数だけサーバーが起 動されます。どのノードでサーバーが起動するかはAPCによって決定され、ユーザーが介入することはで きません。自動モードでの稼動中は、常に状況がモニタリング、解析され、サービス・ポリシーにそぐわな い場合は、アクションが自動実行されます。また、自動モードでの稼動中は、個々のサーバーを管理者が 停止しても結果として稼動中のサーバー数が最小インスタンス数に満たなくなった場合は、最小インスタ ンス数に到達するまでAPCによって自動的にサーバーが起動されます。 一方手動モードでは、起動、停止は管理者が個別にメンバー・サーバーに対して行います。また稼動中 のAPCによるアプリケーション配置は行われませんので、常に高いサービスを保持するためには、ユー ザーによるモニタリングと状況の解析、アクションの決定と実行が必要となります。このモードは、稼動中よ りも、どちらかというと、動的クラスター起動時に管理者がどのノードでどのインスタンスを起動するかの初 期状態を制御したいときや動的クラスターの停止時に使用します。 56 ３種類の運用モード WebSphere XD5.1 Technical Guide 監視モード APCによる半自動運用モード アクション（プロビジョニング）の実行にはユーザーの介入が必要 APCによりタスクが生成されサブミットされる 提案されたアクション・プランはタスクとしてランタイム・タスクに登録される 3つ目の監視モードはAPCによる半自動運用を提供するモードです。基本的には自動モードと同様、 APCによってアプリケーション配置は管理されますが、APCによってプロビジョニングのアクションが決定 され、実際にサーバー・インスタンスを起動する（アクションを実行する）際にユーザーの介入が必要となる モードです。 起動/停止時の振る舞いは自動モードと同じですが、サーバー・インスタンスの起動にはユーザーの承諾 が必要となります。動的クラスター稼動中、APCはプロビジョニングが必要と判断すると、タスクとしてタスク 管理サービスにサブミットします。管理者はランタイム・タスクからタスクの内容を確認します。タスクには、 現在の状況ととるべきアクションに関する情報が含まれます。 このモードは、XDによる自動運用を段階的に取り入れたいときや管理者がアクションを制御したいときに 使用します。 57 ３種類の運用モード WebSphere XD5.1 Technical Guide 監視モードでのアクションの実行 アクション･プランに対して処置を選択して実行 受諾 否認 クローズ ユーザーが承諾してはじめて、アプリケーション配置が実行される 監視モードでは、管理者は管理コンソールのランタイム・タスクからアクション・プランを承諾するか拒否す ることで処置を実施します。アクション・プランはサブミットされたタスクの「タスクの説明」から参照すること ができ、この中にどのノードでどのサーバー・インスタンスを起動するかの提案が記述されています。管理 者が承諾を実行することで、はじめてアプリケーション配置の実際のアクション（追加サーバー・インスタン スの起動）が実施されます。 58 Dynamic Operations 環境起動手順 WebSphere XD5.1 Technical Guide 0. 0. 起動共通手順 起動共通手順 ① DMGRの起動 ② Node Agentの起動 ③ ODRの起動 ２．手動モードでの起動 ２．手動モードでの起動 ２−① 手動モードの設定 １．自動モードでの起動 １．自動モードでの起動 ２−② AppServerの起動 １−① 自動モードの設定 ２−③ 自動（監視）モードの設定 Dynamic Operations環境の起動と停止について説明します。 Dynamic Operations環境では、起動/停止の対象としてデプロイメント・マネージャー、ODR、動的クラス ター（およびそのメンバー）があります。デプロイメント・マネージャーの起動停止はWAS NDと同じです。 またODR自体もアプリケーション・サーバーのため、ノードエージェントを起動し、startServerコマンドまた は管理コンソールからODRを起動するというWAS NDでのアプリケーション・サーバーの起動(および停 止）と手順は同じになります。 動的クラスターに関しては、動的クラスター単位で起動/停止を実施することはできません（管理コンソール から動的クラスターに対して起動/停止ボタンはありません）。基本的にはメンバー・サーバー単位での起 動/停止になりますが、2つの起動シナリオがあります。動的クラスターでは3つの運用モードが存在し、設 定したモードによって起動時、稼動中および停止時の振る舞いが異なります。自動モードと監視モードは 起動時の振る舞いが同じなため、ここでは自動モードと手動モードの時の起動の流れを示しています。 まず2つのシナリオ共通の手順として、①デプロイメント・マネージャーを起動し、②各ノードのノードエー ジェントの起動し、③ODRを起動します。 自動モードでは、実行時にどのノードで各動的クラスターのインスタンスが起動するかはAPCによって決 定され、自動的に起動されるため、動的クラスターのモードを自動モードに設定するだけで、特に追加の 作業は必要ありません。なお、このとき各動的クラスターの構成の一般プロパティーで指定した最小インス タンス数の数だけインスタンスが起動されます。 一方、起動時の初期状態をユーザーが制御したい場合（APCに任せるのではなく、特定のノードで特定 のサーバー・インスタンスを起動させたい場合）には動的クラスターを「手動モード」に設定します。手動 モードにすることで、個々のサーバーを個別に管理者が起動することができます。初期状態を構成してか ら「自動モード」に戻すことで、以降はWebSphere XDによって運用ポリシーに基づいた運用が開始され ます。 59 Dynamic Operations 環境停止手順 WebSphere XD5.1 Technical Guide 運用モードを「手動」に設定してから個々のサーバーを停止 停止手順 停止手順 ① 手動モードの設定 ② AppServerの停止 ③ ODRの停止 ④ Node Agentの停止 ⑤ DMGRの停止 WebSphere XDでは動的クラスター単位での停止はサポートされません。また、自動/監視モードの場合、 個々のサーバーを管理者が停止しても、運用ポリシーに基づきパフォーマンス目標を維持しようとランタイ ムが別のノードでASを立ち上げようとします。したがって停止の際にはまず動的クラスターを「手動モー ド」に設定する必要があります。手動モードの動的クラスターはアプリケーション配置や動的ワークロード 管理が適用されません。手動モードに設定後、アプリケーション・サーバー、ODRの順に停止し、さらに ノードエージェント、デプロイメント・マネージャーを停止します。 60 （参考）ODRの起動と停止 WebSphere XD5.1 Technical Guide 管理コンソールから起動・停止 コマンドから起動・停止 起動 - <ODR_ROOT>¥bin¥startServer.bat <ODR名> 停止 - <ODR_ROOT>¥bin¥stopServer.bat <ODR名> ODRの起動および停止はコマンドで行う方法と管理コンソールから行う方法があります。いずれの場合も、 ODRノードで先にノードエージェントを起動しておいてください。 管理コンソールの場合は、「サーバー」→「オンデマンド・ルーター」から起動/停止したいODRをチェックし 「始動」/「停止」ボタンを実行します。コマンドの場合は下記コマンドを実行します。 始動 – <ODR_ROOT>¥bin¥startServer.bat <ODR名> 停止 – <ODR_ROOT>¥bin¥stopServer.bat <ODR名> 61 （参考）AppServerの起動と停止 WebSphere XD5.1 Technical Guide 手動モードの場合 アプリケーション・サーバー単位で起動・停止を実行 管理コンソールまたはコマンドが使用可能 状態の確認 管理コンソール「サーバー」→「アプリケーション・サーバー」で稼動状況の一覧が可能 管理コンソール「ランタイム操作」→「ランタイム・トポロジー」でも稼動確認可能 ランタイム・トポロジーなら CPU使用状況も把握可能 動的クラスターを手動モードに設定した場合、個々のメンバー・サーバーを個別に開始します。また、動 的クラスターを全面停止したい場合も、いったん手動モードにしてから個別に各サーバーを停止する必要 があります。サーバーの開始/停止手順は通常のアプリケーション・サーバーと同様の手順となります。管 理コンソールで「サーバー」→「アプリケーション・サーバー」から開始（停止）するインスタンスを選択して 「開始」「停止」を実行します。または各ノードでstartServerコマンドを用いてアプリケーション・サーバーを 開始/停止します。 また各アプリケーション・サーバーのステータスは、管理コンソールのアプリケーション・サーバーの画面以 外に、ランタイム・トポロジーからも確認して頂くことができます。 62 計画停止 WebSphere XD5.1 Technical Guide ODRの停止 IP Sprayerのquiesce機能を使用してリク エストの割振りを制御 ODRの全面停止＝サイトの停止 IP Sprayerの設定でSorryServerへリクエ ストのルーティング 運用モードを手動にして停止 スマート・ストップ（オプション） 保守モードにしてからサーバー・プロセ スを停止 HA Managerによるサーバー停止の検知 動的クラスターの停止 ASの停止 ASノードの停止 ODRからSorryServerへリクエストをルー ティング 汎用クラスターにも対応可能 ノード･グループ AS DB ODR LB ND AS ODR QM AS 動的クラスター セル DM ODR : On Demand Router Web Web LB: IP Sprayer Web: Web Server Sorryサーバー 前述のDynamic Operations環境の停止手順に加えて、次に計画停止の運用方法について説 明します。計画停止では、ODRの停止、動的クラスター（アプリケーション・サーバー）の停止など 停止する箇所によって運用が異なります。 ODRの停止の場合、ODRの前段のIP Sprayerで制御することになります。例えばWAS NDの Edge Component Load Balancerを使用した場合、Load Balancerの機能で、停止するODR ノードへの割り振りを制御します。これには、強制停止する方法と、quiesce機能を用いたグレー スフル・ストップの方法があります。グレースフル・ストップを用いた場合、Load Balancerはアフィ ニティの効いているクライアントおよび接続中のクライアントからのリクエストは停止中サーバーに 割り振りを続けますが、新規クライアントからのリクエストは別のサーバーに割り振ります。ある程 度の時間経過後に、接続中のクライアントが全てなくなった時点で、ODRを停止することができま す。このとき、ODRのセッション・アフィニティ機能でクライアント・リクエストはセッション情報を保 持するしかるべきアプリケーション・サーバーに割り振られるため、クライアントから見た場合サー ビスはシームレスに持続されることになります。IP Sprayerからの割り振りの制御方法の詳細につ いてはそれぞれのIP Sprayer製品のマニュアルを参照してください。 全てのODRを停止する場合は、サイトの全面停止になりますので、IP Sprayerの機能でSorry ページを表示するSorryサーバーへ割り振りを行います。Load Balancerではルールの設定によ り、Sorryページを出すWebサーバーに割り振ることが可能です。 ASノードの停止には、ASプロセスの停止、ノード自身の停止と、動的クラスター全体の停止の３ つの側面から運用を考える必要があります。ASプロセスの停止は、ODRが停止したサーバーを 検知し、リクエストは他の稼動サーバーに割り振られます。ここでセッションの引継ぎを行うために は後述のセッション情報を共有する仕組みを利用する必要があります。個々のノード自体の停止 に関しては、よりスムースに処理を行うために保守モードというモードが提供されます。保守モー ドについてはこの後説明します。 また、全てのアプリケーション・サーバー（動的クラスターの停止に相当）が停止した場合は、 ODRの機能でSorryページを表示する設定をしておくことが可能です。 63 保守モード WebSphere XD5.1 Technical Guide ノード単位で設定可能なモード 計画停止時などに使用 保守モードのノードはアプリケーション配置およびdWLMの対象から外れる 2つの保守モード設定 保守モードの設定とプロセスの停止 保守モードの設定 保守モードにした上で、全ASプロセスを停止する 保守モードに設定のみでASプロセスは起動したまま 保守モードの設定 ノード・グループの管理画面およびランタイム・トポロジーから設定可能 管理コンソール「「ランタイム 操作」→「ランタイム・トポロ ジー」で、ノードを選択し右ク リックすることでも設定可能 管理コンソール「システム管理」→「ノード・ グループ」→<ノード・グループ名>で設定 XDではノードに対して「保守モード」というモードを提供しています。保守モードとは、問題判別のために クライアントからの接続を停止したい場合や、メンテナンスなどの計画停止時などに使用するモードで、保 守モードに設定されたノードはアプリケーション配置コントローラーおよびdWLMコントローラーの管理対 象になりません。このモードのノードに対しては、以下の2つのルールが適用されます。 ・アプリケーション配置コントローラーによるインスタンスの起動対象ノードにならない ・ノード上の全てのASプロセスのdWLMのウェイトが0になる（新規クライアントからのリクエストはディスパッ チされない） 保守モードには2つの方法があります。 1つは「保守モードの設定とプロセスの停止」です。この保守モードにすると、自動的に全ASプロセスは停 止（グレースフルな停止）され、ノードが運用モードに変更されます。 2つ目は「保守モードの設定」で、これはノードを保守モードに設定するだけで、ASプロセスは起動したま まになります。 保守モードは、管理コンソールの「システム管理」→「ノードグループ」→<Node Group名> または「ランラ イム操作」→「ランタイム・トポロジー」から設定します。解除も同様の画面から行います。 64 保守モード WebSphere XD5.1 Technical Guide 保守モードの確認 ノード・グループの管理画面 ランタイム・トポロジーのアイコンでも確認可能 保守モードの解除 ノード・グループの管理画面 およびランタイム・トポロジーの画面から可能 ノードを選択して「保守モードの設定解除」を選択 ノードが保守モードに設定されると、ランタイム操作のトポロジービューにて、アイコンでそのノードがメンテ ナンス中ということがわかるようになっています。また「システム管理」→「ノードグループ」→「＜ノードグ ループ名＞」→「ノードグループ・メンバー」からも確認が可能です。いずれの画面からも、保守モードの 解除が可能となっています。 65 スマート・ストップ WebSphere XD5.1 Technical Guide AppServerプロセス単位のグレースフル・シャットダウンを実行 ランタイム・トポロジーから実行 dWLMウェイトを0に設定 アクティブ･セッションがなくなることを 確認してプロセスを停止 停止したいアプリケーション・サーバーを選択 左クリックのメニューから「スマート・ストップ」を実行 保守モードと組み合わせることでノードのグレースフルな停止が可能 ノードを保守モードにする アプリケーション・サーバーをスマート・ストップする 全てのアプリケーション・サーバー・プロセスの停止を 確認してからノードエージェントを停止する スマート・ストップはアプリケーション・サーバー単位でグレースフル・シャットダウンと行う機能で、ランタイ ム・トポロジーからのみ実行可能となっています。ランタイム・トポロジーで該当サーバーをクリックして表示 されるメニューからスマート・ストップを実行すると、dWLMウェイトが0となり、新規クライアントからのリクエス トが割り振られなくなります。さらに、アクティブ・セッションがなくなると、プロセスが停止されます。前述の 「保守モードとプロセスの停止」が、ノード単位でのグレースフルな停止を実施するのに対して、スマート・ ストップではサーバー単位でのグレースフルな停止を行うものになります。なお、「保守モード」とスマート・ ストップを組み合わせることで、ノードを手動で段階的にグレースフルに停止することも可能です。 66 セッション管理 – セッション・アフィニティ WebSphere XD5.1 Technical Guide 初回アクセス Session Object WAS WASXD ODR ODRXD Node Node XD Agent Agent WAS WASXD Node Node XD Agent Agent WAS WASXD Node Node XD Agent Agent WAS WASXD ２回目以降 Cookie: JSESSIONID=um27sry7o JSESSIONIDから サーバーのCloneIDを抜き出し 割り振り先判別に使用 ODR ODRXD Node Node XD Agent Agent ODRはデフォルトで セッション・アフィニティをサポート Session Object WAS WASXD WAS WASXD Node Node XD Agent Agent WAS WASXD Node Node XD Agent Agent WAS WASXD CloneID WAS1 :um27sry7o WAS2 :um27rkd4t XDでのセッション管理の方法について説明します。ODRはWAS NDのWeb Server Plug-inと同様の JSESSIONIDを利用したアフィニティ機能をデフォルトでサポートしています。クライアントからの初回のリ クエストで作成されたJSESSIONIDに付加されるクローンIDを使用してセッション・アフィニティを行います。 このクローンIDは各サーバー(クラスター・メンバー)に固有の値を持ちます。次回リクエストが来たときはク ライアント・リクエスト内に含まれるクローンIDと実サーバーのIDを照合することで、正しい割り振り先を決定 することができます。なおセッション・アフィニティは動的WLM・静的WLMに関わらず、WLMよりも優先さ れます。 67 セッション管理 – セッション・パーシスタンス WebSphere XD5.1 Technical Guide アプリケーション･サーバー障害時 リクエストは別の正常サーバーに割り振られる 障害時にもセッションを維持するためには、アプリケーション･サーバー間でセッショ ン情報を共有する仕組み（セッション・パーシスタンス）が必要 メモリー対メモリー複製 セッションDB Cookie: JSESSIONID=um27sry7o CloneID WAS1 :um27sry7o WAS2 :um27rkd4t WAS1 WAS1 XD Node Node Agent Agent XD Node Node Agent Agent XD Session Object cloneid:um27sry7o ODR ODR XD Node Node XD Agent Agent クラスタ・メンバーのダウンが検 知されると、ODRは他のメン バーにリクエストを振り替える WAS2 WAS2 XD cloneid:um27rkd4t 割り振り先のクラスター・メンバーがダウンしてしまっている場合は、ODRは別のサーバーに対して割り振 りを行います。しかし、特にセッション・パーシスタンスを行っていない場合は、新たなに割振られたサー バー上にはセッション・オブジェクトは存在しませんので、新規のリクエストと判断され、これまでと別のセッ ションIDを持つセッション・オブジェクトが作り直されてしまい、セッションが断絶してしまいます。 割り振り先でも連続した処理を継続したい場合は、これまでのWAS NDの手法と同様に以下に挙げる手 法を用いて、アプリケーションサーバーでセッションのパーシスタンスを有効にする必要があります。 ・内部複製ドメインを設定してメモリ上にセッション情報を共有する（メモリー対メモリー複製)。 ・セッション・オブジェクトの内容をデータベースに書き込み共有する（セッションDB）。 68 動的クラスターでのセッション管理設定 WebSphere XD5.1 Technical Guide 動的クラスター作成後サーバー・テンプレートで設定 セッション管理→分散環境設定 サーバー･テンプレートの変更/保存/同期により、各メンバー･サーバーに設定 が反映される 動的クラスターでセッション管理を設定するには、サーバー・テンプレートに対して設定を行います。動的 クラスターを作成後、サーバー・テンプレートに追加設定します。サーバー・テンプレートの変更/保存/同 期により、各メンバー・サーバーに設定が反映されます。 69 メモリー対メモリー複製 WebSphere XD5.1 Technical Guide 複製ドメインとレプリケーターの作成 動的クラスター作成時に定義可能 「環境」→「複製ドメイン」から 個々に作成も可能 メモリー対メモリー複製の設定 サーバー･テンプレートでの設定内容はNDの静的クラスターでの設定と同様 実際には、レプリケーターは サーバー上に存在するもの が使用される メモリー対メモリー複製には、複製ドメインとレプリケーターが必要となります。これらは動的クラスター作成 時に「このクラスターに複製ドメインを作成する」というチェックボックスをチェックして作成するか、管理コン ソールの「環境」→「複製ドメイン」から作成します。動的クラスター作成時に複製ドメインを作成すると、同 時に各メンバー・サーバー上でレプリケーターが作成されます。手動で複製ドメインを作成した場合は、手 動でレプリケーターを作成する必要がありますので注意してください。 メモリー対メモリー複製でのセッション情報の共有は、動的クラスターのサーバー・テンプレートに対して行 います。設定する内容はWAS NDと同じですが、1点だけレプリケーターの指定が異なります。ここでは任 意のものを設定してください。サーバー・テンプレートでの設定を保管すると、各メンバー・サーバーに設 定が反映されますが、この時、サーバー・テンプレートで設定したレプリケーターではなく、実際にはその サーバー上で起動するレプリケーターが（存在すれば）使用される構成になります。 70 セッション・データベースの使用 WebSphere XD5.1 Technical Guide データベースを使用する設定 サーバー･テンプレートでの設定内容はNDの静的クラスターでの設定と同じ データソース設定(セルまたは動的クラスター・レベルで設定） データベースを使用したセッション情報の共有の場合も、動的クラスターのサーバー・テンプレートから行 います。設定内容はWAS NDと同じです。 また、セッション・パーシスタンスで使用するデータベースに対するデータソース定義が別途必要です。こ れは、動的クラスター・レベルまたはセル・レベルで設定してください。 71