Oracle® Fusion Middleware

Oracle Traffic Directorの管理

12c (12.2.1.1.0)

E77306-01(原本部品番号:E71400-01)

2016年6月

Oracle Fusion Middleware Oracle Traffic Directorの管理 12c (12.2.1.1.0)

E77306-01

Copyright © 2013, 2016, Oracle and/or its affiliates.All rights reserved.

原本協力者: Isvaran Krishnamurthy、Amit Gupta、Basant Kukreja、Julien Pierre、Hideaki Hayashi、Murthy Chintalapati、Sandhya Prasad、Zhong Xu、Sriram Natarajan、Meena Vyas、Prem Kumar Venkatasalapathy、Prashant Sharma、Raghunandan Seshadri、Sarath Babu、Megha Shivaprasad、Nanda Kishore

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

第I部 スタート・ガイド

1 Oracle Traffic Directorスタート・ガイド

- 1.1 12cの新機能

- 1.1.1 Weblogic Management Framework

- 1.1.2 WLSTコマンド

- 1.1.3 マルチテナントのサポート

- 1.1.4 監視の拡張

- 1.1.5 Oracle Fusion Middleware T2P Utility for Oracle Traffic Director

- 1.1.6 外部のヘルス・チェック実行可能ファイル

- 1.1.7 リクエスト制限のあるキューイング

- 1.1.8 オリジン・サーバーのトラフィック制御

- 1.1.9 オリジン・サーバーおよびオリジン・サーバー・プールのメンテナンス

- 1.1.10 優先度付きバックエンド接続の管理

- 1.1.11 オリジン・サーバー・プールでの転送プロキシのサポート

- 1.1.12 NZセキュリティ・ライブラリ

- 1.1.13 ModSecurityのアップグレード

- 1.1.14 イベント通知のサポート

- 1.1.15 アクティブ-アクティブ・フェイルオーバー・モードを使用した高可用性

- 1.1.16 Oracle Traffic Directorインスタンスを監視するステータス・リスナー

- 1.1.17 TCPプロキシのFTP構成の有効化

- 1.2 Oracle Traffic Directorの機能

- 1.3 標準的なネットワーク・トポロジ

- 1.4 Oracle Traffic Director用語集

- 1.5 Oracle Traffic Directorデプロイメント・シナリオ

- 1.6 管理タスクの概要

- 1.7 管理インタフェースへのアクセス

- 1.7.1 WebLogic Scripting Toolへのアクセス

- 1.7.1.1 使用モード

- 1.7.2 Fusion Middleware Controlの表示

- 1.8 Oracle Traffic Directorを使用したシンプルなロード・バランサの設定

- 1.8.1 トポロジの例

- 1.8.2 トポロジ例のロード・バランサの作成

- 1.8.3 Oracle Traffic Directorインスタンスのロード・バランシング動作の確認

第II部 基本的な管理

2 Oracle Traffic Director用のWebLogic Serverドメインの構成

- 2.1 ドメインの作成

- 2.2 Oracle Traffic Directorのドメイン・タイプの理解

- 2.2.1 WebLogic ServerありOracle Traffic Director(コロケート)

- 2.2.2 WebLogic ServerなしOracle Traffic Director(スタンドアロン)

- 2.2.3 コロケート・ドメインとスタンドアロン・ドメイン

- 2.3 同じ場所に配置されたOracle Traffic Directorドメインの作成

- 2.3.1 制限付きJRFテンプレートを使用したドメインの作成(推奨)

- 2.3.2 完全なJRFテンプレートを使用したドメインの作成

- 2.3.3 リポジトリ作成ユーティリティを使用したリポジトリの作成

- 2.3.4 リポジトリの作成(制限付きJRFなしの構成のみ)

- 2.3.5 管理コンソールにログインします。

- 2.4 スタンドアロンのOracle Traffic Directorドメインの作成

- 2.4.1 オフラインWLSTコマンドを使用したスタンドアロン・ドメインの作成

- 2.4.2 構成ウィザードを使用したスタンドアロン・ドメインの作成

- 2.4.3 インスタンス管理

- 2.4.4 Oracle Traffic Directorインスタンスの監視

- 2.4.4.1 統計の使用

- 2.4.4.2 SNMPの使用

3 構成の管理

- 3.1 構成の作成

- 3.2 構成のリストの表示

- 3.3 構成の変更のアクティブ化

- 3.4 構成の変更

- 3.5 構成のコピー

- 3.6 構成の削除

4 インスタンスの管理

- 4.1 Oracle Traffic Directorインスタンスの作成

- 4.2 Oracle Traffic Directorインスタンスのリストの表示

- 4.3 Oracle Traffic Directorインスタンスの起動、停止および再起動

- 4.4 再起動が不要なOracle Traffic Directorインスタンスの更新

- 4.5 Oracle Traffic Directorインスタンスの削除

- 4.6 スケジュール済のイベントによるOracle Traffic Directorインスタンスの制御

5 オリジン・サーバー・プールの管理

- 5.1 オリジン・サーバー・プールの作成

- 5.2 オリジン・サーバー・プールのリストの表示

- 5.3 オリジン・サーバー・プールの変更

- 5.4 オリジン・サーバー・プールの削除

- 5.5 Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成

- 5.5.1 動的検出の方法

- 5.5.2 動的検出の有効化

- 5.6 カスタム・メンテナンス・ページの構成

- 5.7 オリジン・サーバー・プールのヘルス・チェック設定の構成

- 5.7.1 サーバーの状態をチェックするための外部ヘルス・チェック実行可能ファイルの使用

- 5.7.1.1 外部実行可能ファイルを使用するためのヘルス・チェック設定の構成

- 5.7.1.2 外部のヘルス・チェック実行可能ファイルへのパラメータ

- 5.7.1.3 ロギング

6 オリジン・サーバーの管理

- 6.1 プールへのオリジン・サーバーの追加

- 6.2 オリジン・サーバーのリストの表示

- 6.3 オリジン・サーバーの変更

- 6.4 エフェメラル・ポートの管理

- 6.5 プールからのオリジン・サーバーの削除

7 仮想サーバーの管理

- 7.1 仮想サーバーの作成

- 7.2 仮想サーバー・リストの表示

- 7.3 仮想サーバーの変更

- 7.4 ルートの構成

- 7.5 仮想サーバーのコピー

- 7.6 仮想サーバーの削除

- 7.7 Oracle Traffic Directorにおけるキャッシュ

- 7.8 インスタンスのキャッシュ設定およびメトリックの確認

- 7.9 チューニング可能なキャッシュ・パラメータ

- 7.10 キャッシュ・パラメータの構成

- 7.11 コンテンツの提供

8 TCPプロキシの管理

- 8.1 TCPプロキシの作成

- 8.2 TCPプロキシのリストの表示

- 8.3 TCPプロキシの変更

- 8.4 TCPプロキシの削除

9 リスナーの管理

- 9.1 リスナーの作成

- 9.2 リスナー・リストの表示

- 9.3 リスナーの変更

- 9.4 リスナーの削除

- 9.5 特権ポートをリスニングするためのOTDの構成

- 9.6 ステータス・リスナーの構成

- 9.6.1 Fusion Middleware Controlを使用したステータス・リスナーの構成

- 9.6.2 WLSTを使用したステータス・リスナーの構成

第III部 高度な管理

10 セキュリティの管理

- 10.1 Oracle Traffic Directorとクライアント間のSSL/TLSの構成

- 10.1.1 SSL/TLS構成プロセスの概要

- 10.1.2 リスナーのSSL/TLSの構成

- 10.1.3 仮想サーバーと証明書の関連付け

- 10.1.4 リスナーのSSL/TLS暗号の構成

- 10.1.5 証明書の選択ロジック

- 10.1.6 厳密なSNIホスト一致について

- 10.1.7 SSL/TLSの概念

- 10.2 Oracle Traffic Directorとオリジン・サーバー間のSSL/TLSの構成

- 10.2.1 一方向および双方向のSSL/TLSについて

- 10.2.2 Oracle Traffic Directorとオリジン・サーバー間の一方向SSL/TLSの構成

- 10.2.3 Oracle Traffic Directorとオリジン・サーバー間の双方向SSL/TLSの構成

- 10.2.4 非SSL Oracle Traffic DirectorインスタンスからSSL Oracle Traffic Directorインスタンスへの変換

- 10.3 証明書の管理

- 10.3.1 鍵ペアの生成

- 10.3.2 CA署名証明書の取得

- 10.3.3 証明書のインポート

- 10.3.4 証明書リストの表示

- 10.3.5 サーバー証明書の更新

- 10.3.6 証明書の削除

- 10.4 証明書失効リストの管理

- 10.4.1 CRLの手動によるインストールおよび削除

- 10.4.2 CRLの自動更新

- 10.5 Webアプリケーション・ファイアウォールの管理

- 10.5.1 Webアプリケーション・ファイアウォールの概要

- 10.5.2 Webアプリケーション・ファイアウォールの構成

- 10.5.2.1 Webアプリケーション・ファイアウォール・ルール・セットの有効化とインストール

- 10.5.3 ルール・セット・ファイルのリスト表示

- 10.5.4 ルール・セット・ファイルの削除

- 10.5.5 サポートされているWebアプリケーション・ファイアウォールのディレクティブ、変数、演算子、アクション、関数、永続ストレージおよびフェーズ

- 10.6 クライアント認証の構成

- 10.7 サービス拒否攻撃の防止

- 10.7.1 リクエスト制限のパラメータ

- 10.7.2 仮想サーバーのリクエスト制限の構成

- 10.8 OTDのSSLパススルーの構成

- 10.8.1 外部(ハードウェア)ロード・バランサからのパス・スルーSSL情報のためのOTDの構成

- 10.8.2 Web層/Traffic DirectorからSSL情報を受信するためのWebLogicの構成

- 10.8.3 OTDに特定のヘッダーを送信するためのF5-BigIPの構成

11 ログの管理

- 11.1 Oracle Traffic Directorのログについて

- 11.1.1 アクセス・ログ

- 11.1.2 サーバー・ログ

- 11.2 ログの表示

- 11.3 ログ・プリファレンスの構成

- 11.4 ログ・ローテーションについて

- 11.5 手動によるログ・ローテーション

- 11.6 Oracle Traffic Directorにおけるログ・ローテーションの自動化の構成

12 Oracle Traffic Directorインスタンスの監視

- 12.1 Oracle Traffic Directorインスタンスの監視方法

- 12.2 統計収集設定の構成

- 12.3 統計レポートへのURIアクセスの構成

- 12.4 WLSTを使用した統計の表示

- 12.5 ブラウザを使用したstats-xmlおよびperfdumpレポートの表示

- 12.6 SNMPを使用した監視

- 12.6.1 Oracle Traffic DirectorのSNMPサポートの構成

- 12.6.2 SNMPサブエージェントの構成

- 12.6.2.1 SNMP v3のユーザー構成

- 12.6.3 SNMPサブエージェントの起動および停止

- 12.6.4 snmpwalkを使用した統計の表示

- 12.7 DMSを使用した監視

- 12.8 XML (stats-xml)レポートのサンプル

- 12.9 プレーンテキスト(perfdump)レポートのサンプル

13 イベント通知

- 13.1 オリジン・サーバーのステータス変更イベント

- 13.1.1 Fusion Middleware Controlを使用したオリジン・サーバーのステータス・イベントのサブスクライブ

- 13.1.2 WLSTを使用したオリジン・サーバーのステータス変更イベントのサブスクライブ

- 13.1.3 通知形式

- 13.1.3.1 JSONスキーマ

- 13.1.3.2 例

- 13.1.4 エラー処理

- 13.2 リクエスト制限の超過イベント

- 13.2.1 WLSTを使用したリクエスト制限の超過イベントのサブスクライブ

- 13.2.2 通知形式

- 13.2.2.1 JSONスキーマ

- 13.2.2.2 例

14 高可用性を提供するためのOracle Traffic Directorの構成

- 14.1 高可用性の概要

- 14.1.1 ネットワーク・トポロジにおける高可用性

- 14.1.2 構成モードのフェイルオーバー

- 14.1.3 アクティブ-パッシブ・モードでのフェイルオーバー

- 14.1.4 アクティブ-アクティブ・モードでのフェイルオーバー

- 14.2 フェイルオーバー・グループの作成および管理

- 14.2.1 フェイルオーバー・グループの作成

- 14.2.1.1 Fusion Middleware Controlを使用したフェイルオーバー・グループの作成

- 14.2.1.2 WLSTを使用したフェイルオーバー・グループの作成

- 14.2.2 フェイルオーバー・グループの管理

15 パフォーマンス向上のためのOracle Traffic Directorのチューニング

- 15.1 一般的なチューニング・ガイドライン

- 15.2 ファイル・ディスクリプタ制限のチューニング

- 15.3 スレッド・プールおよび接続キューのチューニング

- 15.3.1 スレッドおよび接続について

- 15.3.2 インスタンスのスレッド・プール・メトリックの確認

- 15.3.3 インスタンスの接続キュー・メトリックの確認

- 15.3.4 スレッド・プールおよび接続キュー設定のチューニング

- 15.4 HTTPリスナー設定のチューニング

- 15.5 キープ・アライブ設定のチューニング

- 15.5.1 キープ・アライブ接続について

- 15.5.2 キープ・アライブ接続の設定およびメトリックの確認

- 15.5.3 キープ・アライブ設定のチューニング

- 15.6 HTTPリクエストおよびレスポンスの制限のチューニング

- 15.7 DNSキャッシュ設定のチューニング

- 15.7.1 DNSキャッシュ設定およびメトリックの表示

- 15.7.2 DNSキャッシュ設定の構成

- 15.8 SSL/TLS関連の設定のチューニング

- 15.8.1 SSL/TLSセッションのキャッシュ

- 15.8.2 暗号および証明書鍵

- 15.9 アクセス・ログ・バッファ設定の構成

- 15.10 コンテンツ圧縮の有効化と構成

- 15.11 オリジン・サーバーへの接続のチューニング

- 15.12 Solaris固有のチューニング

- 15.12.1 単一のプロセスで開くファイル(ファイル・ディスクリプタの制限)

- 15.12.2 HTTPサーバーへの接続の失敗

- 15.12.3 TCPバッファリングのチューニング

- 15.12.4 ファイル・システム・メンテナンスの軽減

- 15.12.5 ビジー状態のボリュームまたはディスクにおける長いサービス時間

- 15.12.6 短期のシステム監視

- 15.12.7 長期のシステム監視

- 15.12.8 パフォーマンス・ベンチマークのためのチューニング

16 問題の診断およびトラブルシューティング

- 16.1 Oracle Traffic Directorのトラブルシューティングのロードマップ

- 16.1.1 高可用性構成に関する問題のトラブルシューティング

- 16.2 一般的なエラーの解決方法

- 16.2.1 起動障害: ポートにバインドできない

- 16.2.2 HTTPリスナー・ポート80でサーバーを起動できない

- 16.2.3 Oracle Traffic Directorが、起動時にメモリーを大量に消費する

- 16.2.4 オペレーティング・システム・エラー: システム内で開いているファイルが多すぎる

- 16.2.5 一時ディレクトリの変更後にインスタンスを停止できない

- 16.2.6 管理サーバーを再起動できない

- 16.2.7 Oracle Traffic Directorでセッションの固定性が維持されない

- 16.3 よくある質問

- 16.3.1 構成とは何ですか。

- 16.3.2 Fusion Middleware Controlにはどのようにアクセスするのですか。

- 16.3.3 初めてFusion Middleware Controlにアクセスする際、証明書の警告が表示されるのはなぜですか。

- 16.3.4 構成ファイルを手動で編集できますか。

- 16.3.5 Fusion Middleware Controlで、構成の保存と構成のデプロイにはどのような違いがありますか。

- 16.3.6 Fusion Middleware Controlで「デプロイメント保留中」のメッセージが表示されるのはなぜですか。

- 16.3.7 Fusion Middleware Controlで「インスタンス構成デプロイ済」のメッセージが表示されるのはなぜですか。

- 16.3.8 Fusion Middleware Controlセッションが突然終了するのはなぜですか。

- 16.3.9 WLSTにはどのようにアクセスするのですか。

- 16.3.10 初めてWLSTにアクセスする際、証明書の警告メッセージが表示されるのはなぜですか。

- 16.3.11 WLSTコマンドのオプションの短縮名を知るにはどのようにすればよいですか。

- 16.3.12 動的検出が有効な場合、ヘルス・チェック・プロトコルとしてTCPを選択できないのはなぜですか。

- 16.3.13 プール内のオリジン・サーバーをOracle WebLogic Serverに変更した後、これらは自動検出されませんが、動的検出は有効です。なぜですか。

- 16.3.14 Oracle Traffic Directorによって送受信されたリクエストおよびレスポンス・ヘッダーを表示するにはどのようにすればよいですか。

- 16.3.15 Oracle Traffic DirectorインスタンスのSSL/TLSの有効化はどのように行いますか。

- 16.3.16 サポートされていて、かつ有効化されているSSL/TLS暗号スイートはどのように検出できますか。

- 16.3.17 インストールされている証明書のリストを表示するにはどのようにすればよいですか。

- 16.3.18 SSL/TLSが有効なOracle Traffic Directorインスタンスへのテスト・リクエストの発行はどのように行いますか。

- 16.3.19 SSL/TLS接続の分析はどのように行いますか。

- 16.3.20 Oracle Traffic DirectorインスタンスとOracle WebLogic Serverオリジン・サーバー間のSSL/TLS通信の詳細の表示はどのように行いますか。

- 16.3.21 SSL/TLSが有効な特定のオリジン・サーバーは、起動しているにもかかわらず、ヘルス・チェックの後オフラインとマークされるのはなぜですか。

- 16.3.22 Oracle Traffic Directorはオリジン・サーバーにリクエストを転送する前にクライアントのソースIPアドレスを書き換えますか。

- 16.3.23 Oracle Traffic Directorから405ステータス・コードが返されるのはなぜですか。

- 16.4 Oracleサポートへの連絡

A Oracle Traffic Directorで追跡されるメトリック

- A.1 インスタンス・メトリック

- A.2 プロセス・メトリック

- A.3 接続キュー・メトリック

- A.4 スレッド・プール・メトリック

- A.5 DNSキャッシュ・メトリック

- A.6 キープ・アライブ・メトリック

- A.7 スレッド・メトリック

- A.8 圧縮および解凍メトリック

- A.9 仮想サーバー・メトリック

- A.10 CPUメトリック

- A.11 オリジン・サーバー・メトリック

- A.12 フェイルオーバー・インスタンス・メトリック

- A.13 キャッシュ・メトリック

- A.14 DMSメトリック表

B Webアプリケーション・ファイアウォールの例とユースケース

- B.1 ルールの基本

- B.2 主な攻撃に対抗するためのルール

- B.2.1 ブルート・フォース攻撃

- B.2.2 SQLインジェクション

- B.2.3 XSS攻撃

C Oracle Traffic Directorデプロイメントの保護

- C.1 Oracle Traffic Directorの保護

D Oracle Fusion Middleware T2P Utility for Oracle Traffic Director

- D.1 概要

- D.2 T2Pプロセスの概要

- D.3 要件

- D.4 T2Pユーティリティの使用方法

- D.4.1 バイナリのコピー(Oracleホーム)

- D.4.2 構成のコピー

- D.4.3 構成の編集

- D.4.4 バイナリの貼付け(Oracleホーム)

- D.4.5 構成の貼付け

- D.5 Oracle Traffic Directorの移動計画の抽出およびカスタマイズ

- D.6 ロギング

例の一覧

- 12-1 DMSのカスタムWLSTコマンドを使用したDMSメトリックの表示

- D-1 バイナリのコピー・コマンド

- D-2 コロケートOTD用の構成のコピー・コマンド

- D-3 スタンドアロンOTD用の構成のコピー・コマンド

- D-4 移動計画の抽出コマンド

- D-5 バイナリの貼付けコマンド

- D-6 コロケートOTD用の構成の貼付けコマンド

- D-7 スタンドアロンOTD用の構成の貼付けコマンド

図一覧

- 1-1 Oracle Traffic Directorネットワーク・トポロジ

- 1-2 Oracle Traffic Directorデプロイメントの例

- 3-1 新規構成ウィザード

- 3-2 構成のリスト

- 4-1 インスタンスのリスト

- 5-1 オリジン・サーバー・プールの作成

- 6-1 新規オリジン・サーバー

- 7-1 新規仮想サーバー・ウィザード

- 8-1 新規TCPプロキシ・ウィザード

- 9-1 新規HTTPリスナー・ウィザード

- 9-2 新規TCPリスナー・ウィザード

- 9-3 「一般設定」セクション

- 9-4 「SSL/TLS設定」セクション

- 9-5 「詳細設定」セクション

- 10-1 新規鍵ペアの生成ウィザード

- 10-2 証明書のインポート

- 13-1「新規イベント・サブスクリプション」ウィザード

- 14-1 Oracle Traffic Directorネットワーク・トポロジ

- 14-2 Oracle Traffic Directorの高可用性のデプロイメント

- 14-3 アクティブ-パッシブ・モードでのフェイルオーバー

- 14-4 アクティブ-アクティブ・モードでのフェイルオーバー

- 14-5 新規フェイルオーバー・グループ・ウィザード

- 15-1 Oracle Traffic Directorの接続処理

- 15-2 キープ・アライブが有効なOracle Traffic Directorの接続処理

表一覧

- 2-1 Oracle Traffic Directorのドメイン構成の選択

- 3-1 構成変更用のWLSTコマンド

- 5-1 ヘルス・チェック・パラメータ

- 5-2 引数パラメータ

- 5-3 Oracle Traffic Directorロギング・レベルおよび引数値のマッピング

- 7-1 仮想サーバー変更用のWLSTコマンド

- 10-1 Oracle Traffic Directorでサポートされる暗号スイート

- 10-2 証明書の選択ロジック

- 11-1 サーバー・ログ・レベル

- 12-1 Oracle Traffic Directorインスタンスの監視方法

- 12-2 SNMPサブエージェント構成パラメータ

- 13-1 すべてのイベントに共通するJSONプロパティ

- 13-2 オリジン・サーバーのステータス変更イベントに固有のJSONプロパティ

- 13-3 すべてのイベントに共通するJSONプロパティ

- 13-4 request-limit-exceededからの通知に固有のJSONプロパティ

- 15-1 パフォーマンス・ベンチマークのためのSolarisのチューニング

- A-1 インスタンス・メトリック

- A-2 プロセス・メトリック

- A-3 接続キュー・メトリック

- A-4 スレッド・プール・メトリック

- A-5 DNSキャッシュ・メトリック

- A-6 キープ・アライブ・メトリック

- A-7 スレッド・メトリック

- A-8 圧縮および解凍メトリック

- A-9 仮想サーバー・メトリック

- A-10 CPUメトリック

- A-11 オリジン・サーバー・メトリック

- A-12 フェイルオーバー・メトリック

- A-13 キャッシュ・メトリック

- A-14 DMSメトリック: OTD_Instanceメトリック表

- A-15 DMSメトリック: OTD_Processメトリック表

- A-16 DMSメトリック: OTD_Cacheメトリック表

- A-17 DMSメトリック: OTD_VirtualServerメトリック表

- A-18 DMSメトリック: OTD_Routeメトリック表

- A-19 DMSメトリック: OTD_OriginServerPoolメトリック表

- A-20 DMSメトリック: OTD_OriginServerメトリック表

- A-21 DMSメトリック: OTD_TcpOriginServerメトリック表

- A-22 DMSメトリック: OTD_TcpProxyメトリック表

- A-23 DMSメトリック: OTD_Listenerメトリック表

- A-24 DMSメトリック: OTD_Failoverメトリック表

- A-25 DMSメトリック: OTD_Partitionメトリック表

- D-1 Oracle Traffic Directorのカスタマイズ要素

はじめに

このガイドは、Oracle Traffic Directorの概要、およびOracle Traffic Directorインスタンスの作成、管理、監視およびトラブルシューティングの方法について説明します。

対象読者

このガイドは、Webサーバー、リバース・プロキシ・サーバーおよびロード・バランサなどのWeb層コンポーネントのインストール、構成、管理、監視およびトラブルシューティングを担当するユーザーを対象としています。

このガイドの読者は、次の操作に精通していることを前提としています。

- ターミナル・ウィンドウでの作業

- UNIXに類似したプラットフォームでのオペレーティング・システム・コマンドの実行

- Oracle WebLogic Serverの管理タスク

また、HTTPおよびSSL/TSLプロトコルの基本を理解していることが望ましいですが、必須ではありません。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、Oracle Technology Networkで入手可能な次のドキュメントを参照してください。

- 『Oracle Traffic Directorリリース・ノート』

- Oracle Traffic Directorのインストール

- 『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』

- 『Oracle Traffic Director構成ファイル・リファレンス』

- WebLogic Server MTの使用

- Oracle Exalogic Elastic Cloudのドキュメント

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

第I部

スタート・ガイド

第I部は、次の章で構成されています。

- 第1章「Oracle Traffic Directorスタート・ガイド」では、Oracle Traffic Directorの概要およびその機能を紹介し、関連する用語、さらに製品の管理フレームワークについて説明します。

1 Oracle Traffic Directorスタート・ガイド

Oracle Traffic Directorは高速で、かつ信頼性と拡張性のあるレイヤー7のソフトウェア・ロード・バランサです。バック・エンドのアプリケーション・サーバーおよびすべてのWebサーバーへのすべてのHTTP、HTTPS、TCPトラフィックに対する信頼できるエントリ・ポイントとして機能するように、Oracle Traffic Directorを設定できます。Oracle Traffic Directorでは、クライアントから受信したリクエストの、指定されたロード・バランシング・アルゴリズムに基づくバック・エンドのサーバーへの分散、指定されたルールに基づくリクエストのルーティング、頻繁にアクセスされるデータのキャッシュ、トラフィックの優先付け、およびサービス品質の制御が行われます。Oracle Traffic Directorのアーキテクチャにより、大量のアプリケーション・トラフィックを低遅延で処理することが可能になります。この製品は、Oracle Exalogic Elastic CloudおよびOracle SuperClusterでの使用に最適化されています。Exalogicのインフィニバンド・ファブリックを介してバック・エンドのサーバーと通信できます。Exalogicの詳細は、Oracle Exalogic Elastic Cloudのドキュメント(http://docs./cd/E18476_01/index.htm)を参照してください。Oracle Traffic Directorは様々なFusion Middleware製品でも動作保証されています。Oracle Traffic Directorは、簡単にインストール、構成および使用できます。これには、Oracle WebLogicのWLSTを使用する堅牢なコマンドライン・インタフェースだけでなく、シンプルなWebブラウザ・ベースのグラフィカル・ユーザー・インタフェース(Oracle Enterprise Managerを使用)が含まれます。高可用性のため、フェイルオーバー用のアクティブ-パッシブまたはアクティブ-アクティブのいずれかのOracle Traffic Directorインスタンス・ペアを設定できます。ネットワークのトラフィック量の拡大に応じて、リクエストをルーティングできるバックエンド・サーバーを追加してOracle Traffic Directorを再構成することで、簡単に環境をスケーリングできます。IT環境のニーズに応じて、リクエストをバックエンド・サーバーに分散したりレスポンスをクライアントに転送する際に、複数の複合ルールを適用するようにOracle Traffic Directorを構成できます。

この章では、Oracle Traffic Directorを理解し、使用を開始するための情報を提供します。ここの内容は、次のとおりです。

- 12cの新機能

- Oracle Traffic Directorの機能

- 標準的なネットワーク・トポロジ

- Oracle Traffic Director用語集

- Oracle Traffic Directorデプロイメント・シナリオ

- 管理タスクの概要

- 管理インタフェースへのアクセス

- Oracle Traffic Directorを使用したシンプルなロード・バランサの設定

1.1 12cの新機能

この項では、Oracle Traffic Directorの現在のリリースに追加された機能について説明します。

- 1.1.1項「WebLogic Management Framework」

- 1.1.2項「WLSTコマンド」

- 1.1.3項「マルチテナントのサポート」

- 1.1.4項「監視の拡張」

- 1.1.5項「Oracle Fusion Middleware T2P Utility for Oracle Traffic Director」

- 1.1.6項「外部のヘルス・チェック実行可能ファイル」

- 1.1.7項「リクエスト制限のあるキューイング」

- 1.1.8項「オリジン・サーバーのトラフィック制御」

- 1.1.9項「オリジン・サーバーおよびオリジン・サーバー・プールのメンテナンス」

- 1.1.10項「優先度付きバックエンド接続の管理」

- 1.1.11項「オリジン・サーバー・プールでの転送プロキシのサポート」

- 1.1.12項「NZセキュリティ・ライブラリ」

- 1.1.13項「ModSecurityのアップグレード」

- 1.1.14項「イベント通知のサポート」

- 1.1.15項「アクティブ-アクティブ・フェイルオーバー・モードを使用した高可用性」

- 1.1.16項「Oracle Traffic Directorインスタンスを監視するステータス・リスナー」

- 1.1.17項「TCPプロキシのFTP構成の有効化」

1.1.1 WebLogic Management Framework

Oracle Traffic Directorの以前のリリースでは、データベースを必要としませんでした。このリリースでは、データベース・ベースのインストール、または制限付きJRFベースのインストールがサポートされています。インストールの前提条件の詳細は、Oracle Traffic Directorのインストールを参照してください。このリリースのOracle Traffic Directorでは、Oracle WebLogic のインタフェースを活用するツール・セットであるWebLogic Management Frameworkが導入され、Oracleを管理するためのシンプルで一貫性のある分散フレームワークが提供されます。WebLogic管理フレームワークの詳細は、WebLogic管理フレームワークとはを参照してください。

OTDの機能は、データベースおよび制限付きJRFモード・ベースのインストールの両方で同じです。WebLogic Management Frameworkでは、次のような拡張が導入されています。

- 構成は、インストール後に行う作業になり、主に構成ウィザードを使用して、ドメインの作成から開始します。詳細は、「Oracle Traffic Directorのインストールおよび構成」を参照してください。

- WLST: WebLogicドメインの作成、構成および管理には、WLST、コマンドライン・ユーティリティおよびFusion Middleware Controlを互換的に使用できます。どの方法を選択するかは、グラフィカル・インタフェースとコマンドライン・インタフェースのどちらを使用するか、およびスクリプトを使ってタスクを自動化できるかどうかによって決まります。

- Oracle Traffic Directorの構成およびインスタンスは、WebLogicドメインの一部です。

1.1.2 WLSTコマンド

Oracle Traffic Director WLSTのコマンドライン・インタフェース(Weblogic Scripting Tool)。いくつかのWLSTコマンドは、Oracle Traffic Directorの構成および管理に使用されます。

WLSTコマンドには、次の2つのタイプがあります。

- オンライン・コマンド

- オフライン・コマンド

ほとんどのWLSコマンドは、WLSサーバーへの接続を必要とする「オンライン専用コマンド」です。一部のコマンドは、WLSサーバーへの接続を必要としない「オフライン専用コマンド」です。一部のコマンドは、どちらの方法でも呼び出すことのできるオンラインおよびオフラインの両方です。

WLSTで構成されたすべてのコマンドは、アクティブ化する必要があります。

詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

1.1.3 マルチテナントのサポート

Oracle WebLogic Serverでは、新しいコンセプトであるマルチテナントが導入され、複数の組織で使用する共有可能なインフラストラクチャが提供されます。つまり、専用ドメインを必要としない場合には、1つのドメインで同時に複数のテナントをサポートすることが許可されます。

マルチテナントにより、1つのテナント用に実行中のアプリケーション・インスタンスおよび関連リソースに専有されていたWebLogicドメインのドメイン・パーティション、管理およびランタイム・パーティション内で、リソースの分離が実現できます。

標準的なデプロイメント・シナリオのWebLogic Serverでは、Oracle Traffic Directorがそのフロントエンドとなるため、WebLogic Server側からパーティション関連のタスクを実行するときはいつも、Oracle Traffic DirectorがWebLogicパーティションのフロントエンドとなるように適切に構成する必要があります。

マルチテナントのサポートにより、明示的なユーザーのアクションがなくても、Oracle Traffic Directorが自動的に構成されます。詳細は、「Oracle Traffic Directorの構成」および「エンドツーエンドのライフサイクル管理」を参照してください。

詳細は、『Oracle Fusion Middleware WebLogic Server MTの使用』を参照してください。

1.1.4 監視の拡張

監視サブシステムにより、ランタイム・コンポーネント/プロセスの状態に関する詳細な情報が提供され、パフォーマンスのボトルネックの追跡、最適なパフォーマンスを実現するためのシステムのチューニング、容量計画の支援、障害の予測、障害時の根本原因の分析に使用されます。場合によっては、各要件に応じて、すべてが正常に機能していることを確認するために使用されます。

詳細は、第12章「Oracle Traffic Directorインスタンスの監視」を参照してください。

1.1.5 Oracle Fusion Middleware T2P Utility for Oracle Traffic Director

Oracle Fusion Middleware T2Pユーティリティにより、Fusion Middleware環境をテストから本番に、本番環境に固有のカスタマイズとともに移動できます。12.2.1では、このユーティリティはOracle Traffic Directorをサポートします。

詳細は、"Oracle Fusion Middleware Oracle Traffic Director向けT2Pユーティリティ"を参照してください

1.1.6 外部のヘルス・チェック実行可能ファイル

Oracle Traffic Directorでは一般的なヘルス・チェック連結メカニズムがサポートされるようになり、これによりお客様は自分達のヘルス・チェックのプログラム/スクリプトを記述して特定のオリジン・サーバーの状態を監視できるようになりました。外部実行可能ファイルは、オリジン・サーバーのプロトコル・レベルのヘルス・チェック・モニターとして特に有用です。

詳細は、外部実行可能ファイルを使用するためのヘルス・チェック設定の構成を参照してください。

1.1.7 リクエスト制限のあるキューイング

オーバーフローしたリクエストはキューイングされ、リクエストの優先度に従ってデキューされます。この機能により、リクエストおよびレスポンスの帯域幅を制御できます。

詳細は、15.3項「スレッド・プールおよび接続キューのチューニング」を参照してください。

1.1.8 オリジン・サーバーのトラフィック制御

ユーザーは、キープ・アライブ・オプションによる複数リクエストに対して、同じオリジン・サーバー接続の再利用の制限を設定できます。オリジン・サーバーごとに帯域幅を制限および制御できます。この機能は、HTTPのオリジン・サーバー・プールの制御に使用できますが、TCPのオリジン・サーバー・プールには使用できません。

1.1.9 オリジン・サーバーおよびオリジン・サーバー・プールのメンテナンス

この機能を使用することにより、オリジン・サーバーまたはオリジン・サーバー・プールをメンテナンスのためにマークでき、このようなオリジン・サーバーまたはオリジン・サーバー・プールへのすべての新しい接続およびセッションは、その先に排出されます。

1つのプールは複数のパーティションを持つことができますが、それらのパーティションのうちの1つのみが新しいプールにプッシュできます。タイムアウト時間が経過するか管理者がなんらかのアクションを取るまで、すべての古いリクエストは古いプールに振り向けられます。

オリジン・サーバーのすべてのスケール・アップおよびスケール・ダウンの処理では、Oracle Traffic Directorの機能の変更を必要としません。Oracle Traffic Directorの管理者は、「無効」としてオリジン・サーバーを更新します。すべての進行中のリクエストは、引き続き、無効化されたオリジン・サーバーによって処理されます。これは、単なる実行時の変更ではなく、オリジン・サーバーの新しい状態を反映して構成も更新されます。

1.1.10 優先度付きバックエンド接続の管理

Oracle Traffic Directorでは、クリティカルなアプリケーションのリクエスト用に、バックエンド・サーバーへの優先度付きリクエストがサポートされています。この機能により、優先度の高いリクエストが優先度の低いリクエストの前にデキューされます。

1.1.11 オリジン・サーバー・プールでの転送プロキシのサポート

Oracle Traffic Directorは、常に、直接的な方法でその構成済オリジン・サーバーに接続しています。必要に応じて、(指定プールの)メンバーであるすべてのオリジン・サーバーが構成済HTTP転送プロキシ・サーバー経由で通信するように、HTTP転送プロキシ・サーバーをオリジン・サーバー・プールに関連付けることができます。

詳細は、第5章「オリジン・サーバー・プールの管理」を参照してください。

1.1.12 NZセキュリティ・ライブラリ

セキュリティ・ライブラリはNZで、証明書/キーのストアはOracle Walletです。NSSはサポートされなくなりました。

1.1.13 ModSecurityのアップグレード

Oracle Traffic Director 12cでは、WAFで使用されるModSecurityコードがバージョン2.6.7から2.8.0にアップグレードされました。

1.1.14 イベント通知のサポート

Oracle Traffic Directorは、次の2つのイベントにおいて、1つ以上のHTTPエンドポイントに対する通知の送信をサポートします。

- オリジン・サーバーのステータス変更イベント

- リクエスト制限の超過イベント

詳細は、第13章「イベント通知」を参照してください。

1.1.15 アクティブ-アクティブ・フェイルオーバー・モードを使用した高可用性

Oracle Traffic Directorは、同じサブネットに属しているノード上に2つ以上のOTDインスタンスをデプロイすることで、インスタンス間でのフェイルオーバーをサポートします。ノードの1つはアクティブ・ルーター・ノードとして選択され、残りのノードはバックアップ・ルーター・ノードです。すべてのOTDインスタンス間のトラフィックが管理されます。

詳細は、第14章「高可用性のためのOracle Traffic Directorの構成」を参照してください。

1.1.16 Oracle Traffic Directorインスタンスを監視するステータス・リスナー

Oracle Traffic Directorは、Oracle Traffic Directorインスタンスを監視する専用のステータス・リスナーの構成をサポートします。

詳細は、9.6項「ステータス・リスナーの構成」を参照してください。

1.1.17 TCPプロキシのFTP構成の有効化

Oracle Traffic Directorは、TCPプロキシでのFTPサポートを有効化するオプションを提供しています。TCPプロキシでクライアントFTPとサーバーFTPの設定を有効化できます。

詳細は、第8章「TCPプロキシの管理」を参照してください。

1.2 Oracle Traffic Directorの機能

Oracle Traffic Directorには、次の機能があります。

- 高度なロード分散メソッド
Oracle Traffic Directorは、次のいずれかのアルゴリズムを使用してクライアント・リクエストをバック・エンドのサーバーに分散するように構成できます。

- ラウンド・ロビン

- 最小接続件数

- 最小レスポンス時間

- IPハッシュ

- 重み付けラウンド・ロビン

- 重み付け最小接続件数

- バック・エンド・サーバーでの柔軟なルーティングおよびロード制御

- リクエスト・ベースのルーティング
Oracle Traffic Directorは、リクエストURI内の情報(パターン、問合せ文字列、ドメイン、ソースおよび宛先のIPアドレスなど)に基づいて、バック・エンドの特定のサーバーにHTTP(S)リクエストをルーティングするように構成できます。

- 内容ベースのルーティング
Oracle Traffic Directorは、HTTP(S)リクエストをリクエストのコンテンツに基づいてバックエンドにある特定のサーバーにルーティングするように構成できます。これにより、XMLやJSONなどのWebサービス・リクエストを、本文のコンテンツに含まれる特定の要素に基づいて特定のオリジン・サーバーに簡単にルーティングできます。コンテンツベースのルーティングはデフォルトで有効です。

- リクエスト・レート・アクセラレーション
管理者は、バック・エンドの特定のサーバーに対してOracle Traffic Directorがロードを増やすレートを構成できます。この機能を使用して、管理者は、プールに追加された、または再起動されたサーバーでの起動タスク(データのロード、システム・リソースの割当てなど)の実行を許可します。

- 接続数の制限
Oracle Traffic Directorは、バック・エンドのサーバーへの同時接続数を制限するように構成できます。サーバーの構成済接続制限に達すると、新しい接続を要求するその後のリクエストは、そのサーバーには送信されません。

- リクエスト・ロードおよびサービス品質の制御

- リクエスト・レート制限
Oracle Traffic Directorは、特定のクライアントからの受信リクエスト、および特定のタイプのリクエストのレートを制限するように設定できます。この機能により、管理者は、使用可能な帯域幅の利用を最適化し、特定のサービス品質レベルを保証して、サービス拒否(DoS)攻撃を回避できます。

- サービス品質のチューニング
受信リクエストに対し、使用可能なネットワーク・リソースを公平に利用するために、クライアントへの最大同時接続数、およびデータのクライアントへの最高転送速度を制限するようにOracle Traffic Director仮想サーバーを構成できます。

- WebSocket接続のサポート
Oracle Traffic DirectorではWebSocket接続がデフォルトで処理されます。WebSocket接続は存続時間が長いため、ライブ・コンテンツやリアルタイムのゲーム、ビデオ・チャットなどをサポートできます。RFC 6455を厳密に遵守するこれらのクライアントのみを許可するように、Oracle Traffic Directorを構成できます。詳細は、7.4項「ルートの構成」および『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

- Oracle Fusion Middlewareとの統合

- Oracle Traffic Directorは、バック・エンドのOracle WebLogic Server管理対象サーバーへのリクエスト、およびサーバーからのレスポンスの一部であるヘッダーを認識し処理するように設計されています。

- Oracle Traffic Directorインスタンスが、クラスタ化されたOracle WebLogic Server管理対象サーバーにクライアント・リクエストを分散するように構成されている場合、Oracle Traffic Directorは、管理対象サーバーの削除や追加などのクラスタ内の変更を自動検出し、リクエストのルーティング中この変更を考慮します。

- Oracle Traffic Directorソフトウェア用に提供されているパッチは、OPatchというJavaベースのユーティリティを使用して適用できますが、これはOracle Fusion Middleware製品にパッチを適用する標準的な方法です。

- 簡単に使用できる管理インタフェース
管理者はグラフィカル・ユーザー・インタフェースまたはコマンドライン・インタフェースを使用して、Oracle Traffic Directorインスタンスを管理できます。

- セキュリティ
Oracle Traffic Directorを使用すると、次の方法でITインフラストラクチャのセキュリティを有効化および拡張できます。

- リバース・プロキシ
Oracle Traffic Directorは、ネットワークの外のクライアントとバック・エンドのサーバー間の仲介者として機能し、バック・エンドのサーバーの名前をマスクし、バック・エンドの複数のサーバーによってホストされている重要なデータおよびアプリケーションへのアクセスをトラッキングするための単一のポイントを提供します。

- SSL 3.0、TLS 1.0、TLS 1.1およびTLS 1.2のサポート
送信中のデータを保護し、権限のあるユーザーのみがバック・エンドのサーバーにアクセスできるようにするため、Oracle Traffic DirectorインスタンスにSSL/TLSが有効化されたHTTPリスナーとTCPリスナーを構成できます。

VeriSignなどの商用CAによって発行されたデジタル証明書を使用するか、Fusion Middleware ControlまたはWLSTを使用して、鍵サイズが4096ビットまでのRSAタイプおよび楕円曲線暗号(ECC)タイプの自己署名証明書を生成できます。

- Webアプリケーション・ファイアウォール
Webアプリケーション・ファイアウォールを使用してHTTPリクエストにルールのセットを適用し、クロスサイト・スクリプティング(XSS)やSQLインジェクションなどの一般的な攻撃を阻止できます。Oracle Traffic DirectorのWebアプリケーション・ファイアウォール・モジュールはオープン・ソースのModSecurity 2.8をサポートしています。

- WebGateを使用したシングル・サインオン
WebGateにより、Oracle Traffic Directorのシングル・サインオン(SSO)が可能になります。WebGateは受信リクエストを調べて、リクエストされたリソースが保護されているかどうかを判断し、保護されている場合は、ユーザーのセッション情報を取得します。WebGateを介することで、Oracle Traffic Directorはユーザー認証にSSOを使用できるSSOパートナ・アプリケーションになり、Oracle Single Sign-Onを使用してユーザーIDを取得して、Oracle Traffic Directorを介してアクセスしたWebアプリケーションでそれを使用できるようにします。

- 高可用性
Oracle Traffic Directorは、次のメカニズムを介して、エンタープライズ・アプリケーションおよびサービスの高可用性を提供します。

- バック・エンドのヘルス・チェック
バック・エンドのサーバーが使用不可であるか、完全にロードされている場合、Oracle Traffic Directorは、定期的なヘルス・チェックにより自動的にこの状況を検出し、そのサーバーへのクライアント・リクエストの送信を停止します。障害の発生したサーバーが再び使用可能になった場合、Oracle Traffic Directorは自動的にこれを検出し、このサーバーへのリクエストの送信を再開します。

- バック・エンドのサーバーのバックアップ
Oracle Traffic Directorインスタンスのサーバー・プールを設定する際、バック・エンドのいくつかのサーバーをバックアップ・サーバーとして指定できます。Oracle Traffic Directorは、使用可能なプライマリ・サーバーがない場合にのみ、バックアップ・サーバーにリクエストを送信します。この機能により、バック・エンドのサーバーの一部に障害が発生しても、継続的な可用性が確保されます。

- ロード・バランシングのためのフェイルオーバー
2つのOracle Traffic Directorインスタンスを、アクティブ-パッシブまたはアクティブ-アクティブ構成でデプロイできます。プライマリOracle Traffic Directorインスタンスに障害が発生した場合、バックアップ・インスタンスに処理が切り替わります。

- 動的再構成
Oracle Traffic Directorへのほとんどの構成変更は、インスタンスを再起動したり、処理中のリクエストに影響を及ぼしたりすることなく動的にデプロイできます。

- 統計の監視
管理者は、Fusion Middleware Control、コマンドライン・インタフェース、およびXML形式のレポートなどの複数の方法で、Oracle Traffic Directorインスタンスのパフォーマンスに関連する統計を広範囲に監視できます。

- 高パフォーマンス

- SSL/TLSの負荷軽減
Oracle Traffic Directorは、HTTP/SリクエストおよびTCPリクエストのSSL/TLS終端点として構成できます。これにより、バック・エンドのサーバーの処理のオーバーヘッドが削減されます。

- コンテンツ・キャッシュ
Oracle Traffic Directorは、オリジン・サーバーから受信したコンテンツを(プロセス・メモリー内に)キャッシュするように構成できます。コンテンツをキャッシュすることで、Oracle Traffic Directorは、バック・エンドのサーバーの負荷を削減し、クライアントのパフォーマンスを向上できます。

- HTTP圧縮
管理者は、バック・エンドのサーバーから受信したデータを圧縮し、リクエスト元のクライアントに圧縮されたコンテンツを転送するようにOracle Traffic Directorインスタンスを構成できます。この機能により、低速接続で接続されたクライアントのレスポンス時間が向上します。

- 仮想化の有効なソリューション
Oracle Traffic Directorは、クラウドおよび仮想プラットフォーム上の仮想アプライアンスとしてデプロイできます。

Oracle Traffic Directorを物理的なアプリケーションとしてデプロイした後、Oracle Traffic Directorインスタンスから仮想アプライアンスを作成するか、このようなアプライアンスを複数含むアセンブリを作成できます。次に、Oracle仮想マシン・ハイパーバイザーにアプライアンスまたはアセンブリをデプロイできます。このようなデプロイメントを有効にするために、Oracle Virtual Assembly Builderの一部として、Oracle Traffic Directorプラグインが提供されており、このツールを使用して、物理アプリケーションから仮想アプライアンスおよびアセンブリを構築できます。

Oracle Traffic Directorインスタンスを含む仮想アセンブリの作成とデプロイの詳細は、『Oracle Virtual Assembly Builderユーザーズ・ガイド』を参照してください。

- TCPロード・バランシング
TCPロード・バランシングにより、Oracle Traffic Directorでクライアント接続を受け入れ、TCPベースのプロトコルを実行しているサーバーのプールにリクエストをルーティングできます。

1.3 標準的なネットワーク・トポロジ

Oracle Traffic Directorに作成するネットワーク・トポロジは、Oracle Traffic Directorを使用してリクエストをバランシングするバック・エンド・アプリケーション数などのビジネス要件、セキュリティなどのIT要件、および使用するOracle Traffic Directorの機能によって、異なります。

最も単純な実装は、専用の計算ノードで単一のOracle Traffic Directorインスタンスを実行し、バック・エンドのサーバー・プールにクライアント・リクエストを分散する方法です。

Oracle Traffic Directorインスタンスが実行されるノードがトポロジの単一の障害ポイントにならないように、アクティブ-パッシブ・フェイルオーバー・ペアを形成する異なるノードで、2つの同種のOracle Traffic Directorインスタンスを実行できます。

図1-1は、高可用性を実現した利用例である代表的なOracle Traffic Directorネットワーク・トポロジを示しています。

図1-1 Oracle Traffic Directorネットワーク・トポロジ

図1-1に示されたトポロジは、2つのOracle Traffic Directorインスタンス(otd_1およびotd_2)で構成され、フェイルオーバー・ペアを形成し、クライアント・リクエストに対し単一の仮想IPアドレスを提供します。構成されたフェイルオーバー・モードに基づいて、プライマリ・ノードはリクエストの転送方法と転送先を判断します。フェイルオーバー・モードの詳細は、14.1.2項「構成モードのフェイルオーバー」を参照してください。

図1-1では、バック・エンドに2つのサーバー・プールのみが示されていますが、複数のサーバー・プール内のサーバーにリクエストをルーティングするようにOracle Traffic Directorを構成できます。

フェイルオーバー・グループでのOracle Traffic Directorインスタンスの構成の詳細は、14.2項「フェイルオーバー・グループの作成と管理」を参照してください。

1.4 Oracle Traffic Director用語集

Oracle Traffic Director構成は、Oracle Traffic Directorインスタンスの実行時の動作を定義する一連の要素です。Oracle Traffic Director構成には、リスナー、オリジン・サーバー、フェイルオーバー・グループ、ログなど、Oracle Traffic Directorインスタンスの様々な要素に関する情報が含まれています。

次の表には、このマニュアルでOracle Traffic Directorの管理タスクを説明するときに使用されている用語が記載されています。

用語

説明

構成

Oracle Traffic Directorインスタンスの実行時の動作を決定する一連の構成可能な要素(メタデータ)。
一般的な構成には、リクエスト、およびリクエストの送信先となる、バック・エンド内のサーバーについての情報をOracle Traffic Directorがリスニングするリスナーの定義(IPアドレスとポートの組合せ)が含まれます。構成は、Oracle Traffic Directorインスタンスの起動時およびクライアント・リクエストの処理中にOracle Traffic Directorによって読み取られます。

インスタンス

構成からインスタンス化されて管理ノード上にデプロイされるOracle Traffic Directorサーバーです。

フェイルオーバー・グループ

アクティブ-パッシブ・モードで高可用性を提供するために、仮想IPアドレス(VIP)でグループ化された2つのOracle Traffic Directorインスタンス。リクエストは、VIPで受信され、プライマリ・インスタンスと指定されているOracle Traffic Directorインスタンスにルーティングされます。プライマリ・インスタンスに到達できない場合、リクエストはバックアップ・インスタンスにルーティングされます。
アクティブ-アクティブ・フェイルオーバーの場合、2つのフェイルオーバー・グループが必要となり、それぞれ一意のVIPを持ちますが、両方ともプライマリ・ロールとバックアップ・ロールが逆となる同じノードで構成されています。フェイルオーバー・グループ内の各インスタンスは、プライマリ・インスタンスおよびバックアップとして指定され、それぞれにVIPが1つずつ割り当てられます。

ORACLE_HOME

Oracle Traffic Directorバイナリのインストール先としてユーザーに選択されたディレクトリ。

DOMAIN_HOME

Oracle Traffic Directorドメインを含むディレクトリへのパス

Fusion Middleware Control

Oracle Traffic Directorインスタンスの作成、デプロイおよび管理に使用できる、管理サーバー上のWebベースのグラフィカル・インタフェース。

クライアント

HTTPリクエスト、HTTPSリクエストおよびTCPリクエストをOracle Traffic Directorインスタンスに送信する任意のエージェント(たとえば、ブラウザまたはアプリケーション)です。

オリジン・サーバー

バックエンドのサーバーであり、Oracle Traffic Directorはクライアントから受信したHTTPリクエスト、HTTPSリクエストおよびTCPリクエストをこのサーバーに転送し、クライアント・リクエストに対するレスポンスをこのサーバーから受信します。
オリジン・サーバーとして、Oracle WebLogic Server管理対象サーバーのようなアプリケーション・サーバーやWebサーバーなどを使用できます。

オリジン・サーバー・プール

Oracle Traffic Directorを使用してロード・バランシングを行うことができる、同じアプリケーションまたはサービスをホストするオリジン・サーバーの集合です。
Oracle Traffic Directorは、オリジン・サーバー・プールに対して指定されたロード分散方法に基づいて、プール内にある各サーバーにクライアント・リクエストを分散させます。

仮想サーバー

一意のIPアドレス(またはホスト名)とポートの組合せを提供するOracle Traffic Directorサーバー・インスタンス内の仮想エンティティであり、これを通じてOracle Traffic Directorは1つ以上のドメインのリクエストを処理できます。
ノード上のOracle Traffic Directorインスタンスには、複数の仮想サーバーを含めることができます。管理者は、仮想サーバーごとに個別に最大着信接続数などの設定を構成できます。また、各仮想サーバーのリクエスト処理方法をカスタマイズすることもできます。

1.5 Oracle Traffic Directorデプロイメント・シナリオ

Oracle Traffic Directorは物理アプリケーションと仮想アプライアンスのいずれとしても使用できます。

- 物理アプリケーション
Oracle Traffic DirectorをOracle Linux 6.5システムにインストールし、1つ以上の製品インスタンスを実行して、クライアント・リクエストをバック・エンドのサーバーに分散できます。

詳細は、「Oracle Traffic Directorのインストール」を参照してください。

- 仮想プラットフォームで実行されるアプライアンス
Oracle Traffic Directorを物理的なアプリケーションとしてデプロイした後、Oracle Traffic Directorインスタンスから仮想アプライアンスを作成するか、このようなアプライアンスを複数含むアセンブリを作成できます。次に、Oracle仮想マシン・ハイパーバイザーにアプライアンスまたはアセンブリをデプロイできます。このようなデプロイメントを有効にするために、Oracle Virtual Assembly Builderの一部として、Oracle Traffic Directorプラグインが提供されており、このツールを使用して、物理アプリケーションから仮想アプライアンスおよびアセンブリを構築できます。

Oracle Traffic Directorインスタンスを含む仮想アセンブリの作成とデプロイの詳細は、『Oracle Virtual Assembly Builderユーザーズ・ガイド』を参照してください。

1.6 管理タスクの概要

- 製品のインストール
サイレント・モードで、または対話型のグラフィカル・ウィザードを使用して、Oracle Traffic Directorをx86_64のOracle Linux 6.5+にインストールできます。12cでは、Oracle Traffic Directorにはそれ専用の管理サーバーはなく、Oracle WebLogic Serverの管理サーバーを使用することに注意してください。

詳細は、「Oracle Traffic Directorのインストール」を参照してください。

- Oracle Traffic Director用のWebLogicドメインの作成。詳細は、第2章「Oracle Traffic Director用のWebLogic Serverドメインの構成」を参照してください。

- Fusion Middleware ControlおよびWLSTへのアクセス
Oracle Traffic DirectorのFusion Middleware Controlおよびコマンドライン・インタフェースを使用して、Oracle Traffic Directorの構成を作成、変更および監視できます。

Fusion Middleware Controlおよびコマンドライン・インタフェースへのアクセスの詳細は、1.7項「管理インタフェースへのアクセス」を参照してください。

- 構成の作成および管理
Oracle Traffic Directorインスタンスを定義する構成を作成します。構成とは、Oracle Traffic Directorのインスタンス化に使用できるメタデータの集合です。この構成は、サーバー・インスタンスの起動時およびクライアント・リクエストの処理中にOracle Traffic Directorによって読み取られます。

詳細は、第3章「構成の管理」を参照してください。

- インスタンスの作成および管理
構成を作成した後、1つ以上のホストにその構成をデプロイすることによってOracle Traffic Directorサーバー・インスタンスを作成できます。各インスタンスの現在の状態を表示したり、各インスタンスを起動または停止したり、各インスタンスを再構成して構成の変更を反映させたりすることができます。

詳細は、第4章「インスタンスの管理」を参照してください。

- オリジン・サーバー・プールの定義および管理
Oracle Traffic Directorインスタンスによってクライアント・リクエストを分散させるには、バックエンド内に1つ以上のオリジン・サーバー・プールを定義する必要があります。オリジン・サーバー・プールごとに、Oracle Traffic Directorによるリクエストの分散に使用するロード分散方法を定義できます。さらにプール内のオリジン・サーバーごとに、Oracle Traffic Directorによるリクエスト・ロードの制御方法を定義できます。

詳細は、第5章「オリジン・サーバー・プールの管理」および第6章「オリジン・サーバーの管理」を参照してください。

- 仮想サーバーおよびリスナーの作成および管理
ノード上で実行されているOracle Traffic Directorインスタンスには、1つ以上の仮想サーバーが含まれています。各仮想サーバーには、クライアントからリクエストを受信するための1つ以上のリスナーが備わっています。各仮想サーバーでは、仮想サーバーによるリクエストのルーティング先となるオリジン・サーバー・プール、サービス品質の設定、リクエスト制限、キャッシュ・ルール、ログ・プリファレンスなどのパラメータを構成できます。

詳細は、第7章「仮想サーバーの管理」および第9章「リスナーの管理」を参照してください。

- セキュリティの管理
Oracle Traffic Directorは、標準的なネットワークにおいて外部とのやり取りを担う位置に実装されるため、バックエンド内のデータおよびアプリケーションをネットワークの外部からの攻撃や不正アクセスから保護する上で重要な役割を果たします。さらに、Oracle Traffic Directorを通って残りのネットワークに達するデータについて、そのセキュリティおよび整合性を確保する必要があります。

詳細は、第10章「セキュリティの管理」を参照してください。

- ログの管理
Oracle Traffic Directorのログ・ファイルには、構成の変更、インスタンスの起動および停止、リクエスト処理中のエラーなどのサーバー・イベントに関するデータが記録されます。ログは、エラーのトラブルシューティングやシステムのチューニングによるパフォーマンス向上に役立ちます。

詳細は、第11章「ログの管理」を参照してください。

- 統計の監視
Oracle Traffic Directorインスタンスの状態およびパフォーマンスは、構成設定、着信リクエストの量、オリジン・サーバーのヘルス、インスタンスを通過するデータの種類など、複数の要因によって影響を受けます。管理者は、コマンドライン・インタフェースおよびFusion Middleware Controlを使用して、これらの要因すべてについてのメトリックを表示し、XMLファイルのフォームに統計を出力して詳細な分析を行うことができます。Oracle Traffic Directorによって収集する統計の粒度を調整することもできます。

詳細は、第12章「Oracle Traffic Directorインスタンスの監視」を参照してください。

- 高可用性を提供するためのOracle Traffic Directorインスタンスの設定
Oracle Traffic Directorインスタンスまたはその実行ノードに障害が発生した場合には、インスタンスによって提供されているロード・バランシング・サービスが、中断されることなく継続的に利用できるようにする必要があります。プライマリ・インスタンスに障害が発生したときにリクエストの処理を引き継ぐ、バックアップ用のOracle Traffic Directorインスタンスを構成することによって、この目標を達成できます。

詳細は、第14章「高可用性のためのOracle Traffic Directorの構成」を参照してください。

- パフォーマンス向上のためのチューニング
パフォーマンス統計の分析に基づき、あるいはリクエスト・ロード・プロファイルの変更に応じて、パフォーマンスの維持や向上のためにOracle Traffic Directorのリクエスト処理パラメータの調整が必要になる場合があります。Oracle Traffic Directorにはパフォーマンス・チューニングのための様々なコントロールおよびノブが備わっており、これらを使用して、個々のリクエストのサイズおよび量を制限したり、タイムアウトの設定を制御したり、スレッド・プールの設定やSSL/TLSキャッシュの動作を構成したりすることができます。

詳細は、第15章「パフォーマンス向上のためのOracle Traffic Directorのチューニング」を参照してください。

- 問題の診断およびトラブルシューティング
どんなに注意を払っていても、Oracle Traffic Directorインスタンスをインストール、構成または監視しているときに問題が発生することがあります。これらの問題の一部は、エラー・メッセージおよびログに表示されている情報に基づいて診断、解決できます。複雑な問題については、オラクル社のサポート担当者が問題の把握、再現および診断に使用できるように、ユーザーが特定のデータを収集する必要があります。

詳細は、第16章「問題の診断およびトラブルシューティング」を参照してください。

1.7 管理インタフェースへのアクセス

この項では、次の項目について説明します。

- 1.7.1項「WebLogic Scripting Toolへのアクセス」

- 1.7.2項「Fusion Middleware Controlの表示」

1.7.1 WebLogic Scripting Toolへのアクセス

Oracle Traffic Director 12cのコマンドライン・インタフェースはWLST(Weblogic Scripting Tool)です。WLSTスクリプト環境は、Javaプラットフォーム用のPython言語の実装であるJythonに基づいています。このツールは、オンラインおよびオフラインの両方で使用できます。WLSTの使用に関する詳細は、Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンスを参照してください。Oracle Traffic Director WLSTコマンドの完全なリストは、Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンスを参照してください。Oracle Traffic Directorには、WLSTを使用して実行できるカスタムWLSTコマンドが付属しています。

注意:
Oracle Traffic Directorには、Oracle Traffic Directorコマンドに必要な環境やライブラリを初期化するwlst.shラッパー(<oracle_home>/otd/common/bin/wlst.sh)が付属しています。すべてのOracle Traffic Directorのカスタム・コマンドは、このwlst.shからのみ実行できます。

WLSTの使用方法の詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

1.7.1.1 使用モード

Oracle Traffic Directorのカスタム・コマンドを起動するには、次の方法を使用できます。

- 対話モード

- スクリプト・モード

- 埋込みモード

これらのモードでのWLSTの使用に関する詳細は、Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンスを参照してください。

1.7.2 Fusion Middleware Controlの表示

Fusion Middleware Controlを表示するには、Fusion Middleware ControlのURLを入力します。このURLには、インストール時に割り当てられたホスト名と管理ポート番号が含まれます。このURLの形式は次のとおりです。

http://hostname.domain:port/em

ポート番号は、Fusion Middleware Controlのポート番号です。デフォルトのポート番号は7001です。ポート番号は、次のファイルにリストされています。

DOMAIN_HOME/config/config.xml

Web層など、一部のインストール・タイプでは、最後のインストール画面で「保存」をクリックしてインストール情報を保存した場合、Fusion Middleware ControlのURLが、ディスクに書き込まれたファイル(デフォルトではホーム・ディレクトリにあります)に含まれています。その他のインストール・タイプの場合、構成が完了すると構成ウィザードの「ドメインの作成」画面に情報が表示されます。

Fusion Middleware Controlを表示するには:

1. WebブラウザにURLを入力します。例:

http://host1.example.com:7001/em

2. Oracle Fusion Middleware管理者のユーザー名とパスワードを入力して、「ログイン」をクリックします。

これでOracle Traffic Director構成を作成し、管理ノードのインスタンスとしてデプロイできるようになりました。詳細は、第3章「構成の管理」を参照してください。

1.8 Oracle Traffic Directorを使用したシンプルなロード・バランサの設定

この項では、Oracle Traffic Directorを使用して、ロード・バランシングされたサービスを最小限の設定でどのように設定できるかについて説明します。この項の目的は、この章で前述された概念を補足してわかりやすく説明し、この後の章で説明する構成タスクのためにユーザーが準備できるようにすることです。

この項では、次の項目について説明します。

- 1.8.1項「トポロジの例」

- 1.8.2項「トポロジの例に対するロード・バランサの作成」

- 1.8.3項「Oracle Traffic Directorインスタンスのロード・バランシング動作の確認」

1.8.1 トポロジの例

この例では、Oracle Traffic Directorの単一のインスタンスを作成し、このインスタンスがHTTPリクエストを受信し、バック・エンドの2つのオリジン・サーバーに分散します。これらのオリジン・サーバーは両方とも同じコンテンツを提供します。

図1-2は、例のトポロジを示しています。

図1-2 Oracle Traffic Directorデプロイメントの例

例のトポロジは次の構成に基づいています。

- 管理サーバーのホストおよびポート: bin.example.com:8989

- 管理ノードのホストおよびポート: apps.example.com:8900

- クライアントからリクエストを受信する仮想サーバー・ホストおよびポート: hr-apps.example.com:1905

- オリジン・サーバーのホストおよびポート(この例のWebサーバー)

- hr-1.example.com:80

- hr-2.example.com:80

実際には、両方のオリジン・サーバーは、同じコンテンツを提供します。ただし、この例では、ロード・バランシングが機能していることがわかるようにするために、WebサーバーのDocumentRootディレクティブによってポイントされ、次のように少し異なるindex.htmlページを設定します。

- hr-1.example.com:80の場合: "オリジン・サーバー1から提供されたページ"

- hr-2.example.com:80の場合: "オリジン・サーバー2から提供されたページ"

- ロード・バランシング・メソッド: ラウンド・ロビン

1.8.2 トポロジ例のロード・バランサの作成

この項では、1.8.1項「トポロジの例」で説明されたトポロジの設定方法を説明します。

1. 「Oracle Traffic Directorのインストール」の説明に従ってOracle Traffic Directorをインストールします。

2. otd_createConfiguration WLSTコマンドを使用して、構成hr-configを作成します。

props = {}
props['name'] = 'hr-config'
props['listener-port'] = '1905'
props['server-name'] = 'hr-apps.example.com'
props['origin-server'] = 'hr-1.example.com:80,hr-2.example.com:80'
otd_createConfiguration(props)

3. otd_createInstance WLSTコマンドを実行して、構成hr-configのインスタンスを作成します。Fusion Middleware Controlでマシンの作成時に指定した名前と同様に、OTDインスタンスが実行されているマシンのホスト名に対応するようにマシンを指定します。

props = {}
props['configuration'] = 'hr-config'
props['machine'] = 'machine1'
otd_createInstance(props)

4. start WLSTコマンドを実行して、作成したOracle Traffic Directorインスタンスを起動します。

start('otd_foo_machine1')

注意:
この手順ではWLSTを使用していますが、Fusion Middleware Controlを使用することもできます。

これで、Oracle Traffic Directorの構成の作成およびインスタンスの起動が正常に実行できました。

1.8.3 Oracle Traffic Directorインスタンスのロード・バランシング動作の確認

前の手順で作成し起動したOracle Traffic Directorインスタンスは、URL http://hr-apps.example.com:1905でHTTPリクエストをリスニング中です。

この項では、Oracle Traffic Directorインスタンスのロード・バランシングの動作を、ブラウザを使用してどのように確認するかを説明します。

注意:

- Webサーバーhr-1.example.com:80とhr-2.example.com:80が実行中であることを確認します。

- 必要に応じて、Oracle Traffic Director仮想サーバーへのアクセス元となるホストの/etc/hostsファイルを更新して、ブラウザがhr-apps.example.comを正しいIPアドレスに解決できるようにします。

1. URL http://hr-apps.example.com:1905をブラウザに入力します。
次のテキストを含むページが表示されます。

"オリジン・サーバー1から提供されたページ"

これは、apps.example.com管理ノードで実行中のOracle Traffic Directorインスタンスが、ブラウザから送信されたHTTPリクエストを受信し、オリジン・サーバーhr-1.example.com:80へ転送したことを示します。

2. ブラウザ・ウィンドウをリフレッシュして、別のHTTPリクエストをhttp://hr-apps.example.com:1905に送信します。
次のテキストを含むページが表示されます。

オリジン・サーバー2から提供されたページ

これは、Oracle Traffic Directorが2番目のリクエストをオリジン・サーバーhr-2.example.com:80に送信したことを示します。

3. ブラウザ・ウィンドウを再度リフレッシュして、3番目のHTTPリクエストをhttp://hr-apps.example.com:1905に送信します。
次のテキストを含むページが表示されます。

"オリジン・サーバー1から提供されたページ"

これは、Oracle Traffic Directorがシンプルなラウンド・ロビン・ロード分散メソッドを使用して、3番目のHTTPリクエストをオリジン・サーバーhr-1.example.com:80に送信したことを示します。

第II部

基本的な管理

第II部は、次の章で構成されています。

- 第2章「Oracle Traffic Director用のWebLogic Serverドメインの構成」では、構成やインスタンスを作成して管理できるように、Oracle Traffic Director用にWebLogicドメインを作成および管理する方法を説明します。

- 第3章「構成の管理」では、Oracle Traffic Directorインスタンスの実行時の動作を決定するメタデータの集合である構成を作成および管理する方法を説明します。

- 第4章「インスタンスの管理」では、Oracle Traffic Directorインスタンスを作成および管理する方法を説明します。

- 第5章「オリジン・サーバー・プールの管理」では、Oracle Traffic Directorインスタンスがクライアント・リクエストをルーティングできる、バック・エンドのサーバー・プールを作成および管理する方法を説明します。

- 第6章「オリジン・サーバーの管理」では、オリジン・サーバー・プールでサーバーを追加および管理する方法を説明します。

- 第7章「仮想サーバーの管理」では、クライアント・リクエストを処理する仮想サーバーを作成および管理する方法、ならびにルーティング・ルールを作成および管理する方法を説明します。

- 第8章「TCPプロキシの管理」では、TCPリクエストを処理するTCPプロキシの作成方法と管理方法を説明します。

- 第9章「リスナーの管理」では、仮想サーバーのHTTPリスナーおよびTCPプロキシのTCPリスナーを作成および管理する方法を説明します。

2 Oracle Traffic Director用のWebLogic Serverドメインの構成

この章では、Oracle Fusion Middleware構成ウィザードを使用してOracle Traffic Directorの構成およびインスタンスを作成して構成できるように、Oracle Traffic DirectorとWebLogicドメインを作成する手順を説明します。

- ドメインの作成

- Oracle Traffic Directorのドメイン・タイプの理解

- 同じ場所に配置されたOracle Traffic Directorドメインの作成

- スタンドアロンのOracle Traffic Directorドメインの作成

2.1 ドメインの作成

Oracle Traffic Directorをインストールした後、Oracle Traffic DirectorとWebLogicドメインを作成する必要があります。

次の項では、このドメインを作成するために必要な手順について説明します。

2.2 Oracle Traffic Directorのドメイン・タイプの理解

Oracle Traffic Directorでは次のドメイン・タイプがサポートされています。

- 「WebLogic ServerありOracle Traffic Director(コロケート)」

- 「WebLogic ServerなしOracle Traffic Director(スタンドアロン)」

2.2.1 WebLogic ServerありOracle Traffic Director(コロケート)

WebLogic ServerドメインがOracle Traffic Directorに拡張されると、Oracle Traffic Directorのインスタンスおよび構成をWebLogic Serverドメインのその他の要素と同様に管理できます。具体的には、そのインスタンスをEnterprise Manager Fusion Middleware Control、WLSTコマンドライン・インタフェースおよびWebLogic Server Node Managerから管理できます。

WebLogic ServerドメインでOracle Traffic Directorを構成するには、Oracle Traffic Directorを既存のOracle Fusion MiddlewareインフラストラクチャのOracleホームにインストールする必要があります。

OracleホームからOracle Fusion Middleware構成ウィザードを使用して、管理サーバー、管理対象サーバーおよびドメインのその他の要素に追加して、1つ以上のOracle Traffic Directorインスタンスを含むようにWebLogic Serverドメインを構成または拡張できます。

注意:
Oracle Traffic Directorインスタンスは、構成ウィザードでは作成できないことに注意してください。それには、Enterprise ManagerまたはWLSTのいずれかを使用する必要があります。

2.2.2 WebLogic ServerなしOracle Traffic Director(スタンドアロン)

スタンドアロン・ドメインがサポートするシステム・コンポーネントのタイプは1つのみであり、ノード・マネージャは1つのみです。Oracle Traffic Directorを管理するためのカスタムWLSTコマンドはスタンドアロン・ドメインでは使用できません。

注意:
OTDを管理するためのカスタムWLSTコマンドはスタンドアロン・ドメインでは使用できません。スタンドアロンWLSTコマンドの詳細は、Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンスを参照してください。

2.2.3 コロケート・ドメインとスタンドアロン・ドメイン

次のガイドラインに従って、ニーズに最適なOracle Traffic Directorドメインのオプションを決定します。

表2-1 Oracle Traffic Directorのドメイン構成の選択

コロケート・ドメイン構成を使用

スタンドアロン・ドメイン構成を使用

Oracle Fusion Middlewareインフラストラクチャ・ドメインにリクエストをルーティングする、Web層のフロントエンドとしてOracle Traffic Directorインスタンスを使用することを計画している。

これには、Oracle WebLogic ServerのMT用に構成されたドメインでのOracle Traffic Directorの使用も含まれます。

Oracle Fusion Middlewareインフラストラクチャを利用できないドメインにリクエストをルーティングする、Web層のフロントエンドとしてOracle Traffic Directorインスタンスを使用することを計画している。

たとえば、Oracle WebLogic ServerおよびCoherenceドメインのフロントエンド。

Fusion Middleware Controlの拡張管理機能を利用してOracle Traffic Directorインスタンスを管理しようとしている。

また、Oracle Traffic Directorの管理にWLSTのカスタム・コマンドを使用できます。詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

Fusion Middleware ControlでOracle Traffic Directorインスタンスを管理したくない。

かわりに、WLSTコマンド行や、スタンドアロン・ドメインで利用可能な他の機能を使用できます。スタンドアロン・ドメインでは、一部のオフラインWLSTコマンドが使用できないことに注意してください。スタンドアロン・ドメインは管理されておらず、使用可能な管理機能がありません(FMWControlおよびWLSTのカスタム・コマンドを含む)。

ドメインを複数のホストにスケール・アウトし、今までどおり単一のFMW ControlからOracle Traffic Directorインスタンスを管理する必要がある。

2.3 同じ場所に配置されたOracle Traffic Directorドメインの作成

2.3.1 制限付きJRFテンプレートを使用したドメインの作成(推奨)

これは、OTDドメイン作成の推奨モードです。制限付きJRFモードでは、基本的に、データソースに接続せずにWLSランタイムが作成されます。このため、ドメインの作成に実行中のOracleデータベースを必要としません。

制限付きJRFテンプレートを使用してOTDドメインを作成するには、次の手順に従います。

1. $FMW_HOME/oracle_common/common/binディレクトリにあるconfig.shを使用して構成ウィザードを実行します。
構成ウィザードの最初の画面が表示されます(ドメインの作成)。

2. 「新しいドメインの作成」を選択して、希望するドメイン・ホームのパスを入力します。

3. 「次」をクリックします。「テンプレート」画面が表示されます。「使用可能なテンプレート」セクションで、「Oracle Traffic Director - Restricted JRF 12.2.1 [otd]」を選択します。「Oracle Enterprise Manager - Restricted JRF」、「Oracle Restricted JRF」および「Weblogic Coherence Cluster Extension」が自動的に選択されます。その他のテンプレートを選択できます。詳細は、これらの個々のコンポーネントのドキュメントを参照してください。

4. 「次」をクリックします。「アプリケーションの場所」画面が表示されます。アプリケーションの場所は、デフォルト値のままにします。

5. 「次」をクリックします。「管理者アカウント」画面が表示されます。WebLogicドメイン管理者のユーザー名とパスワードを入力します。この情報は、WebLogic Server ControlおよびFusion Middleware Controlにアクセスするために必要となります。

6. 「次」をクリックします。「ドメイン・モード」の「開発」を選択します。

7. 「次」をクリックします。「詳細構成」画面が表示されます。「管理サーバー」、「管理対象サーバー」、「クラスタ」および「Coherence」を選択します。

8. 「次」をクリックします。「管理サーバー」画面が表示されます。次のように入力します。

- サーバー名: デフォルト(AdminServer)を使用します

- リスニング・アドレス: デフォルト(すべてのローカル・アドレス)を使用します

- リスニング・ポート: $WLS_ADMIN_PORT

- SSLの有効化: デフォルト(未チェック)を使用します

- SSLポート: デフォルト(無効)を使用します

- サーバー・グループ: デフォルト(未指定)を使用します

9. 「次」をクリックします。「ノード・マネージャ」画面が表示されます。ノードは追加しないでください。デフォルト(デフォルト: ドメイン当たり)を使用します。「ノード・マネージャ資格証明」に、次のように入力します。

- ユーザー名: $NM_USER

- パスワード: $NM_PASSWORD

- パスワードの確認: $NM_PASSWORD

「次」をクリックします。

10. 「次」をクリックします。「管理対象サーバー」画面が表示されます。管理対象サーバーは追加しないでください。

11. 「次」をクリックします。「クラスタ」画面が表示されます。クラスタは追加しないでください。

12. 「次」をクリックします。「Coherenceクラスタ」画面が表示されます。クラスタは追加しないでください。

13. 「次」をクリックします。「マシン」画面が表示されます。「追加」をクリックします。次の情報を入力します。

- 名前: $MACHINE_NAME

- ノード・マネージャ・リスニング・アドレス: デフォルト(localhost)を使用します

- ノード・マネージャ・リスニング・ポート: $NM_PORT

14. 「次」をクリックします。「構成のサマリー」画面が表示されます。「ドメインのセキュリティ構成が無効です」というメッセージが表示されても、無視してかまいません。

15. 「作成」をクリックします。「構成の進行状況」画面が表示されます。

16. 「次」をクリックします。構成のこの部分が完了するまで待ちます。リポジトリ・データベースの場所やパフォーマンスによっては、この処理に数分かかることがあります。「終了」をクリックします。「構成の終了」画面が表示されます。

2.3.2 完全なJRFテンプレートを使用したドメインの作成

ドメイン構成用の完全なJRFテンプレートは、次のような場合に使用されます。

- Oracle Traffic DirectorとSOAが同じドメインにある

- そのドメインでは、CCWS、パーティション用のOPSSサポート、WebLogicのアップスタック・コンポーネント用のOPSSサポートなど、様々なコンポーネント/シナリオをサポートすることを予定している。

完全なJRFテンプレートを使用してOracle Traffic Directorドメインを作成するには、次の手順に従います。

1. $FMW_HOME/oracle_common/common/binディレクトリにあるconfig.shを使用して構成ウィザードを実行します。
構成ウィザードの最初の画面が表示されます(ドメインの作成)。

2. 「新しいドメインの作成」を選択して、希望するドメイン・ホームのパスを入力します。

3. 「次」をクリックします。「テンプレート」画面が表示されます。依存するテンプレートは自動的に選択されます。依存するテンプレートは、「Oracle Enterprise Manager Plug-in for OTD - 12.1.4.0 [em]」および「Oracle JRF」です。「使用可能なテンプレート」セクションで、「Oracle Traffic Director - 12.2.1 [otd]」を選択します。

4. 「次」をクリックします。「アプリケーションの場所」画面が表示されます。アプリケーションの場所は、デフォルト値のままにします。

5. 「次」をクリックします。「管理者アカウント」画面が表示されます。WebLogicドメイン管理者のユーザー名とパスワードを入力します。この情報は、WebLogic Server ControlおよびFusion Middleware Controlにアクセスするために必要となります。

6. 「次」をクリックします。「ドメイン・モードおよびJDK」画面が表示されます。「ドメイン・モード」の「開発」を選択します。表示されるデフォルトのJDK選択のままにします。

7. 「次」をクリックします。「データベース構成タイプ」画面が表示されます。RCU DBの接続情報を入力します。次のように入力します。

- 自動構成オプション: RCU Data

- ベンダー: Oracle

- ドライバ: Oracleのサービス接続用ドライバ(Thin)。バージョン:9.0.1以降

- DBMS/サービス - $SERVICE_ID (Oracle XEの場合はxe)

- ポート: $DB_PORT (デフォルトは1521)

- スキーマ所有者 - ${SCHEMA_PREFIX}_STB

- Passwd - $DB_PASSWORD

8. 「RCU構成の取得」をクリックします。検証処理が完了するのを待ちます。

9. 「次」をクリックします。「コンポーネントのデータ・ソース」画面が表示されます。ホスト名およびポートの情報が正しいことを確認します。

10. 「次」をクリックします。「コンポーネントのJDBCスキーマのテスト」画面が表示されます。テストが完了するのを待ちます。

11. 「次」をクリックします。「詳細構成」画面が表示されます。「管理サーバー」、「管理対象サーバー」、「クラスタ」および「Coherence」を選択します。

12. 「次」をクリックします。「管理サーバー」画面が表示されます。次のように入力します。

- サーバー名: デフォルト(AdminServer)を使用します

- リスニング・アドレス: デフォルト(すべてのローカル・アドレス)を使用します

- リスニング・ポート: $WLS_ADMIN_PORT

- SSLの有効化: デフォルト(未チェック)を使用します

- SSLポート: デフォルト(無効)を使用します

- サーバー・グループ: デフォルト(未指定)を使用します

13. 「次」をクリックします。「ノード・マネージャ」画面が表示されます。ノードは追加しないでください。デフォルト(デフォルト: ドメイン当たり)を使用します。「ノード・マネージャ資格証明」に、次のように入力します。

- ユーザー名: $NM_USER

- パスワード: $NM_PASSWORD

- パスワードの確認: $NM_PASSWORD

「次」をクリックします。

14. 「次」をクリックします。「管理対象サーバー」画面が表示されます。管理対象サーバーは追加しないでください。

15. 「次」をクリックします。「クラスタ」画面が表示されます。クラスタは追加しないでください。

16. 「次」をクリックします。「Coherenceクラスタ」画面が表示されます。クラスタは追加しないでください。

17. 「次」をクリックします。「マシン」画面が表示されます。「追加」をクリックします。次の情報を入力します。

- 名前: $MACHINE_NAME

- ノード・マネージャ・リスニング・アドレス: デフォルト(localhost)を使用します

- ノード・マネージャ・リスニング・ポート: $NM_PORT

18. 「次」をクリックします。「構成のサマリー」画面が表示されます。「ドメインのセキュリティ構成が無効です」というメッセージが表示されても、無視してかまいません。

19. 「作成」をクリックします。「構成の進行状況」画面が表示されます。

20. 「次」をクリックします。構成のこの部分が完了するまで待ちます。リポジトリ・データベースの場所やパフォーマンスによっては、この処理に数分かかることがあります。「終了」をクリックします。「構成の終了」画面が表示されます。

注意:
構成ウィザードを使用したOracle Traffic Directorの構成/インスタンスの作成はサポートされていないため、Oracle Traffic Directorの構成時は、構成ウィザードのシステム・コンポーネントの画面は無視します。Oracle Traffic Directorの構成/インスタンスの作成には、Oracle Traffic DirectorのカスタムWLSTコマンドまたはFWMControlのいずれかを使用してください。

2.3.3 リポジトリ作成ユーティリティを使用したリポジトリの作成

次のタスクに進む前に、リポジトリ作成ユーティリティ(RCU)を使用します。RCUは、Oracle Fusion Middlewareインフラストラクチャのディストリビューションで入手できます。次の手順に従います。

1. $FMW_HOME/oracle_common/bin/rcu.shを実行します

2. 「ようこそ」ページが表示されます。「次」をクリックします。

3. 「リポジトリの作成」ページが表示されます。「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」(デフォルト)を選択します。「次」をクリックします。

4. 「データベース接続の詳細」ページが表示されます。次の画面のように、RCU DBの接続情報を入力します。「次」をクリックします。

5. 「前提条件チェック」ボックスがポップアップ表示されます。これには、前提条件チェックの進行状況が表示されます。完了したら、「OK」をクリックします。

6. 「コンポーネントの選択」ページが表示されます。「新規接頭辞の作成」ラジオ・ボタンを選択して、スキーマの接頭辞を指定します(DEMOなど)。次のコンポーネントを選択します: Oracle Platform Security Services、監査サービス、監査サービス追加および監査サービス・ビューア。「次」をクリックします。

7. 「前提条件チェック」ボックスがポップアップ表示されます。これには、前提条件チェックの進行状況が表示されます。完了したら、「OK」をクリックします。

8. 「スキーマ・パスワード」ページが表示されます。デフォルトの「すべてのスキーマに同じパスワードを使用」ラジオ・ボタンが選択されているままにして、「パスワード」フィールドにパスワードを入力します。「次」をクリックします。

9. 「表領域のマップ」ページが表示されます。必要なアクションはありません。「次」をクリックします。

10. 確認を求める「リポジトリ作成ユーティリティ」ボックスがポップアップ表示されます。「OK」をクリックします。

11. 表領域作成の進行状況を示す「表領域の作成中」ポップアップが表示されます。「OK」→「Next」をクリックします。

12. アクションや選択を示す「サマリー」ページが表示されます。「作成」をクリックします。

13. 進行状況を示す「システム・ロード」ボックスが表示されます。このボックスは、完了時に消えます。

14. 「閉じる」をクリックします。

2.3.4 リポジトリの作成(制限付きJRFなしの構成のみ)

コロケート・ドメインにOracle Traffic Directorをインストールする場合、推奨される構成は、制限付きJRFドメイン・テンプレートを使用することです。その構成は、データベースを必要とせず、リポジトリを作成する必要はありません。

しかし、コロケート・ドメインで制限付きJRFドメイン・テンプレートを使用しなかった場合は、データベースおよびドメイン用のスキーマ領域とリポジトリが必要になります。リポジトリを生成するには:

1. 次にように、リポジトリの作成を実行します。

$ORACLE_HOME/oracle_common/bin/rcu -silent -createRepository -connectString $DB_HOST:$DB_PORT:$SERVICE_ID
-dbUser $DB_USER -dbRole $DB_ROLE -schemaPrefix $SCHEMA_PREFIX -useSamePasswordForAllSchemaUsers true
-selectDependentsForComponents true -component OPSS -component IAU -f < <path_to_password_file>

パスワード・ファイルの内容が次のように表示されます。

welcome1
welcome1
welcome1
welcome1
welcome1
welcome1

例:

$ORACLE_HOME/oracle_common/bin/rcu -silent -createRepository -connectString ${DB_HOST}:1521:xe
-dbUser sys -dbRole SYSDBA -schemaPrefix $SCHEMA_PREFIX -useSamePasswordForAllSchemaUsers true -selectDependentsForComponents true
-component OPSS -component IAU -f < /tmp/pass.txt

Processing command line ....
Repository Creation Utility - Checking Prerequisites
Checking Global Prerequisites
The database you are connecting is not a supported version. Refer to the certification matrix for supported DB versions.
...
Repository Creation Utility - Create : Operation Completed

2.3.5 管理コンソールにログインします。

Oracle Traffic Directorをインストールした後で、Oracle Traffic Director管理サーバーの管理コンソールへのログインを試行することでインストールを検証できます。これには次の手順を実行します。

1. 次のコマンドを実行して、管理サーバー・インスタンスを起動します。

$DOMAIN_HOME/bin/startWebLogic.sh

2. Webブラウザで、前述の手順で確認したURLを入力します。
https://bin.example.com:1895/em

サーバーのセキュリティ証明書に関する問題のエラー・メッセージが表示されます。メッセージのテキストは、使用するブラウザによって異なります。信頼できる認証局で発行された証明書ではなく、自己署名による証明書がOracle Traffic Director管理サーバーで使用されているため、エラー・メッセージが表示されます。

3. 証明書を信頼することを選択し、管理コンソールのログイン・ページに進みます。
証明書を信頼するために実行する手順は、使用しているブラウザによって異なります。例としてMozilla Firefox 4.0では、エラー・ページで「危険性を理解した上で接続するには」リンクをクリックし、「例外を追加」ボタンをクリックしてから、最後に結果ページで「セキュリティ例外を承認」ボタンをクリックします。

4. 管理サーバーの作成時に指定した管理者のユーザー名とパスワードを使用してログインします。

2.4 スタンドアロンのOracle Traffic Directorドメインの作成

構成ウィザードまたはWLSTのいずれかを使用して、スタンドアロン・ドメインを作成できます。

2.4.1 オフラインWLSTコマンドを使用したスタンドアロン・ドメインの作成

1. WLSTコマンド・シェルを起動します。

$ORACLE_HOME/oracle_common/common/bin/wlst.sh

2. 次のコマンドを実行してOracle Traffic Directorスタンドアロン・ドメインを作成します。詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のotd_createStandaloneDomainコマンドを参照してください。

> props = {'domain-home': '$DOMAIN_HOME'}
> otd_createStandaloneDomain(props)

2.4.2 構成ウィザードを使用したスタンドアロン・ドメインの作成

1. インストーラを起動します

$ORACLE_HOME/oracle_common/common/bin/config.sh -log=config.log

2. 「ドメインの作成」ページが表示されます。デフォルト値を使用します。「次」をクリックします。

3. 「テンプレート」ページが表示されます。「使用可能なテンプレート」セクションで、「Oracle Traffic Director - Standalone 12.2.1 [otd]」を選択します。「次へ」をクリックします。

注意:
デフォルトで「Basic Standalone System Component Domain - 12.2.1 [wlserver]」が選択されています。
その他のOTDテンプレート「Oracle Traffic Director - 12.2.1 [otd]」と「Oracle Traffic Director - Restricted JRF - 12.2.1 [otd]」は、スタンドアロン・ドメインには適用できません。

4. JDKの選択ページが表示されます。デフォルトのJDKを使用します。「次」をクリックします。

5. 「システム・コンポーネント」ページが表示されます。「次」をクリックします。

注意:
OTDにはシステム・コンポーネントを構成するためのコマンドがあるため、システム・コンポーネントを作成する必要はありません。

6. 「ノード・マネージャ」ページが表示されます。次のオプションを選択し、「次へ」をクリックします。

- ノード・マネージャ・タイプ: デフォルト/ドメインごとのデフォルトの場所

- ユーザー名: USERNAME

- パスワード: PASSWORD

- パスワードの確認: PASSWORD

7. 「構成のサマリー」ページが表示されます。「作成」をクリックします。

8. 「構成の進行状況」ページが表示されます。これにより、構成の進行状況が表示されます。スタンドアロン・ドメインが正常に作成されたら、「次へ」をクリックします。

9. 構成の成功ページが表示されます。「終了」をクリックします。

2.4.3 インスタンス管理

- Oracle Traffic Directorインスタンスを起動します。

$DOMAIN_HOME/config/fmwconfig/components/OTD/instances/INSTANCE_NAME/bin/startserv

- Oracle Traffic Directorインスタンスを停止します。

$DOMAIN_HOME/config/fmwconfig/components/OTD/instances/INSTANCE_NAME/bin/stop

- Oracle Traffic Directorインスタンスを再起動します。

$DOMAIN_HOME/config/fmwconfig/components/OTD/instances/INSTANCE_NAME/bin/restart

- Oracle Traffic Directorインスタンスを削除します。

$DOMAIN_HOME/config/fmwconfig/components/OTD/instances/INSTANCE_NAME/bin/delete

- Oracle Traffic Directorインスタンスを再構成します。
再構成すると、サーバーの再起動なしに構成変更がインスタンスに動的に適用されます。動的に再構成可能な構成の変更のみが反映されます。再起動が必要な構成変更が行われると、再起動を求めるメッセージがstd outに表示されます。

$DOMAIN_HOME/config/fmwconfig/components/OTD/instances/$INSTANCE_NAME/bin/reconfig

- ログ・ファイルのローテーション
古いログ・ファイルはサーバーに保存され、保存済ファイルはローテーション時の日時を含む名前を使用してマークされます。

$DOMAIN_HOME/config/fmwconfig/components/OTD/instances/INSTANCE_NAME/bin/rotate

2.4.4 Oracle Traffic Directorインスタンスの監視

次のコマンドは、OTDインスタンスが存在するホスト上でコマンドを直接実行することにより、OTDインスタンスに関連する統計を監視するために使用できます。

2.4.4.1 統計の使用

1. WLSTコマンド・シェルを起動します。

$ORACLE_HOME$/oracle_common/common/bin/wlst.sh

2. 下のコマンドを実行して、インスタンスに関連する統計を表示します。詳細は、otd_getStatsXmlを参照してください。

> print otd_getStatsXml({'domain-home': '$DOMAIN_HOME', 'instance': 'test'})

<stats versionMajor="1" versionMinor="3" flagEnabled="1">
<server id="test" versionServer="Oracle Traffic Director 12.2.1.0.0 B20141215.181149 (Linux)" timeStarted="1418713548" secondsRunning="3" ticksPerSecond="1000" maxProcs="1" maxThreads="512" flagProfilingEnabled="1" load1MinuteAverage="1.020000" load5MinuteAverage="0.630000" load15MinuteAverage="0.350000" rateBytesTransmitted="13155" rateBytesReceived="62630" requests1MinuteAverage="0.000000" requests5MinuteAverage="0.000000" requests15MinuteAverage="0.000000" errors1MinuteAverage="0.000000" errors5MinuteAverage="0.000000" errors15MinuteAverage="0.000000" responseTime1MinuteAverage="0.000000" responseTime5MinuteAverage="0.000000" responseTime15MinuteAverage="0.000000">
<virtual-server id="test" flagEnabled="1" listeners="*:30007">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" rateBytesTransmitted="0" countOpenConnections="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<websocket countUpgradeRequests="0" countUpgradeRequestsFailed="0" countUpgradeRequestsRejected="0" countActiveConnections="0" countRequestsAborted="0" countRequestsTimedout="0" countBytesReceived="0" countBytesTransmitted="0" millisecondsConnectionActiveAverage="0"/>
<route id="default-route">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" rateBytesTransmitted="0" countOpenConnections="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
</route>
</virtual-server>
...
</server>
</stats>

3. 下のコマンドを実行して、インスタンスに関連するperfdumpの統計を表示します。詳細は、otd_getPerfDumpを参照してください。

> print otd_getPerfDump({'domain-home': '$DOMAIN_HOME', 'instance': 'test'})
Oracle Traffic Director 12.2.1.0.0 B20141215.181149 (Linux)

Server started Mon Dec 15 23:05:47 2014
Process 24883 started Mon Dec 15 23:05:48 2014

ListenSocket http-listener-1:
------------------------
Address                   0.0.0.0:30007
Acceptor Threads          4
Default Virtual Server    test

2.4.4.2 SNMPの使用

次のコマンドは、SNMPエージェントを停止/開始するために使用されます。

- 下のコマンドは、OTDスタンドアロン・ドメインが存在するホスト上でOTD SNMPサブエージェントを開始します。詳細は、otd_startSnmpSubAgentを参照してください。

otd_startSnmpSubAgent({'domain-home': 'DOMAIN_HOME'})

- 下のコマンドは、OTDスタンドアロン・ドメインが存在するホスト上でOTD SNMPサブエージェントを停止します。詳細は、otd_stopSnmpSubAgentを参照してください。

otd_stopSnmpSubAgent({'domain-home': 'DOMAIN_HOME'})

SNMPサブエージェントが収集した統計は、snmpwalkコマンドライン・ユーティリティを使用して表示することもできます。snmpwalkは、OELのnet-snmp-utils RPMの一部です。

必要なMIBオブジェクト名を明示的に指定することで、snmpwalkコマンドを実行します。

> snmpwalk -m $ORACLE_HOME/otd/lib/snmp/ORACLE-TRAFFICDIRECTOR-MIB.txt -v 2c -c public localhost:11161 ORACLE-TRAFFICDIRECTOR-MIB::cacheTable

ORACLE-TRAFFICDIRECTOR-MIB::cacheEnabled.1 = INTEGER: true(1)
ORACLE-TRAFFICDIRECTOR-MIB::cacheCountEntries.1 = Counter64: 0
ORACLE-TRAFFICDIRECTOR-MIB::cacheSizeHeap.1 = Counter64: 16558
ORACLE-TRAFFICDIRECTOR-MIB::cacheCountContentHits.1 = Counter64: 0
ORACLE-TRAFFICDIRECTOR-MIB::cacheCountContentMisses.1 = Counter64: 0
ORACLE-TRAFFICDIRECTOR-MIB::cacheCountHits.1 = Counter64: 0
ORACLE-TRAFFICDIRECTOR-MIB::cacheCountRevalidationRequests.1 = Counter64: 0
ORACLE-TRAFFICDIRECTOR-MIB::cacheCountRevalidationFailures.1 = Counter64: 0
ORACLE-TRAFFICDIRECTOR-MIB::cacheInstanceName.1 = STRING: otd_test_mymachine.oracle.com

3 構成の管理

ロード・バランシングされたサービスをOracle Traffic Directorで作成する最初の手順は、Oracle Traffic Directorサーバーの実行時の特性を定義するメタデータの集合である構成を作成することです。構成を作成した後、構成を使用して、1つ以上の管理ノードにOracle Traffic Directorサーバーのインスタンスを作成できます。

注意:
Oracle Traffic Directorの用語の定義(構成、管理ノードおよびインスタンス)については、1.4項「Oracle Traffic Director用語集」を参照してください。構成、管理ノードおよびインスタンス間の関係の詳細は、第1章「Oracle Traffic Directorスタート・ガイド」を参照してください。

この章の内容は次のとおりです。

- 構成の作成

- 構成のリストの表示

- 構成の変更のアクティブ化

- 構成の変更

- 構成のコピー

- 構成の削除

3.1 構成の作成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成を作成できます。

注意:
WLSTの使用方法の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

始める前に

構成の作成を開始する前に、次の項目を決定します。

- 構成の一意の名前。構成を作成した後は名前を変更できないため、名前は慎重に選択してください。

注意:
構成に指定されたサーバー・ユーザーは、次の要件を満たしている必要があります。

- 管理サーバーがrootで実行されている場合、構成のサーバー・ユーザーは、rootであるか、またはOracle Traffic Directorをインストールしたユーザーと同じグループに属している必要があります。

- 管理サーバーがrootユーザー以外で実行されている場合、構成のサーバー・ユーザーは管理サーバーのサーバー・ユーザーと同じである必要があります。

構成がデプロイされるノードは、これらのシステムに構成されているユーザー・アカウントおよびグループの点から同種である必要があることに注意してください。

- 構成の一部として作成するデフォルト仮想サーバー用の一意のリスナーhost:portの組合せ。

- 構成の一部として作成するオリジン・サーバー・プール内のサーバーのhost:portアドレス。

- (オプション)構成のインスタンスを作成する必要がある管理ノードのホスト名。

注意:
新規構成ウィザードを使用して構成を作成する際、1つ以上の管理ノードで構成をインスタンス化することも選択できます。ウィザードに、管理サーバーに登録されている管理ノードのホスト名が表示されるため、ユーザーはこれを実行できます。

Fusion Middleware Controlを使用した構成の作成

Fusion Middleware Controlを使用して構成を作成するには、次のタスクを実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってTraffic DirectorのFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。

4. 「共通タスク」ペインで、「作成」ボタンを選択します。
新規構成ウィザードが開きます。

図3-1 新規構成ウィザード

5. 画面上のプロンプトに従い、事前に決定済の詳細(オリジン・サーバー・タイプなど)を使用して構成の作成を完了します。
構成が作成された後、新規構成ウィザードの「結果」画面に構成の作成が成功したことを示すメッセージが表示されます。構成のインスタンスを作成することを選択した場合、インスタンスの作成が成功したことを示すメッセージも表示されます。

6. 結果画面で、「閉じる」をクリックします。
新規構成ウィザードで、構成のインスタンスの作成を選択しなかった場合、作成した構成がまだデプロイされていないことを示すメッセージ「アンデプロイ済構成」が表示されます。

WLSTを使用した構成の作成

構成を作成するには、otd_createConfigurationコマンドを実行します。

たとえば、次のコマンドでは、soa.example.comという名前の構成がオリジン・サーバーvault.example.com:80で作成されます。

# Online
props = {}
props['name'] = 'soa.example.com'
props['listener-port'] = '12345'
props['server-name'] = 'foo'
props['origin-server'] = 'vault.example.com:80'
otd_createConfiguration(props)

# Offline
readDomain('/export/2110_12c/iplanet/ias/server/work/TD_Linux2.6_DBG.OBJ/domains/otd_domain')
props = {}
props['configuration'] = 'foo'
props['listener-port'] = '12345'
props['server-name'] = 'foo'
props['origin-server'] = 'www.mycompany.com:80'
otd_createConfiguration(props)
updateDomain()
closeDomain()

otd_createConfigurationの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

オフライン・モードの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のオフライン・コマンドに関する項を参照してください。

3.2 構成のリストの表示

いつでも、Fusion Middleware ControlまたはWLSTのいずれかを使用して、使用可能な構成のリストを表示できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した構成のリストの表示

使用可能な構成のリストを表示するには:

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
図3-2に示すように、使用可能な構成のリストが表示されます。

図3-2 構成のリスト

名前をクリックすると、構成のプロパティを表示できます。

WLSTを使用した構成のリストの表示

使用可能な構成のリストを表示するには、次の例に示すように、otd_listConfigurationsコマンドを実行します。

# Online
otd_listConfigurations()

# Offline
readDomain('/export/2110_12c/iplanet/ias/server/work/TD_Linux2.6_DBG.OBJ/domains/otd_domain')
otd_listConfigurations()
closeDomain()

オフライン・モードの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のオフライン・コマンドに関する項を参照してください。

3.3 構成の変更のアクティブ化

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成の変更をアクティブ化できます。

注意:
特定の構成変更は、インスタンスを再起動せずに動的に適用することはできません。

インスタンスの構成の変更をアクティブ化できます。activateコマンドでは、startEditコマンドの実行により開始された編集セッションの後で行われた変更のみがアクティブ化されます。また、このコマンドの影響は、OTDのみに限定されるものではありません。編集セッションを開始した後に行われた、様々なその他のコンポーネントおよび管理対象サーバーに対するすべての変更も有効になります。

Fusion Middleware Controlを使用した構成のアクティブ化

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってTraffic DirectorのFusion Middleware Controlにログインします。

2. ページの左上隅にあるWebLogicドメインのすぐ下の「ロック解除」ボタンをクリックします。

3. デフォルトでは、自動コミット・モードは有効になっています。

- 有効化

- 自動コミット・モードを有効にして構成を作成します。アクティブ化されたすべての変更についての情報が表示されます。

- 無効化

- 自動コミット・モードを無効にして構成を作成します。アクティブ化を保留中の変更についての情報が表示されます。保留中の変更をアクティブ化するにはチェンジ・センターを使用します。

WLSTを使用した構成の変更のアクティブ化

WLSTで実行されるすべてのコマンドは、変更を有効にするため、Activateコマンドによりアクティブ化する必要があります。

たとえば、次のコマンドでは、その構成のすべてのインスタンスが最新の構成設定で更新されます。

wls:/mydomain/edit !> activate(200000, block='true')
Activating all your changes, this may take a while ...
The edit lock associated with this edit session is released once the activation iscompleted.
Action completed.
wls:/mydomain/edit>

アクティブ化の詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

注意:
一部のパラメータでは、インスタンスを再起動せずにインスタンスを再構成できます。
詳細は、4.4項「再起動が不要なOracle Traffic Directorインスタンスの更新」を参照してください。

3.4 構成の変更

構成を作成し、そこからインスタンスを作成した後、設定の一部(ログ・プリファレンス、パフォーマンス・パラメータ、仮想サーバー・リスナー、オリジン・サーバー・プールなど)を変更する必要がある場合があります。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成を変更できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した構成の変更

Fusion Middleware Controlを使用して構成を変更するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってTraffic DirectorのFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 変更する構成を選択します。

5. ナビゲーション・ペインで、次のような、構成設定の追加カテゴリを選択できます。選択したカテゴリに関連するパラメータが、メインのペインに表示されます。

- SSL

- CRL更新イベントのスケジュール設定および管理。詳細は、10.4.2項「CRLの自動更新」を参照してください。

- SSL/TLSキャッシュ・プリファレンス。詳細は、15.8.1項「SSL/TLSセッションのキャッシュ」を参照してください。

- ロギング

- サーバー・ログ・ファイル(ログ・ファイルの名前と場所、ログ・レベル、日付書式など)のパラメータを設定し変更します。

- アクセス・ログを有効または無効にします。

- アクセス・ログ・ファイル(ログ・ファイルの名前と場所、ログ形式など)のパラメータを設定し変更します。

- サーバーおよびアクセス・ログ・ファイルをローテーションするイベントをスケジュールし管理します。

- パフォーマンスをチューニングするアクセス・ログ・バッファ設定を構成します。

詳細は、第11章「ログの管理」を参照してください。

- 詳細設定

- 一般設定(サーバー・ユーザーID、構成のインスタンスのプロセスIDおよびソケット情報が格納される一時ディレクトリ、およびローカリゼーション・プリファレンス)を指定します。

- DNS参照設定およびキャッシュ設定を構成します。
詳細は、15.7項「DNSキャッシュ設定のチューニング」を参照してください。

- 構成のイベントを作成、有効化、無効化、表示および削除します。詳細は、4.6項「スケジュール済のイベントによるOracle Traffic Directorインスタンスの制御」を参照してください。

- 「詳細設定」のHTTP: 構成に定義された仮想サーバーのパフォーマンスをチューニングするパラメータ(リクエスト・バッファ・サイズ、レスポンス・バッファ・サイズ、リクエストの本文およびヘッダーのタイムアウトしきい値、スレッド・プール設定およびキープ・アライブ設定)を設定および変更します。
詳細は、15.6項「HTTPリクエストおよびレスポンスの制限のチューニング」を参照してください。

- 「詳細設定」の「監視」

- 統計収集、プロファイリングおよびSNMPサブエージェントを有効化および無効化します。

- 統計収集の間隔を指定します。

詳細は、第12章「Oracle Traffic Directorインスタンスの監視」を参照してください。

注意:
オリジン・サーバー、オリジン・サーバー・プール、リスナーおよび仮想サーバーの変更の詳細は、次の項を参照してください。

- 5.3項「オリジン・サーバー・プールの変更」

- 6.3項「オリジン・サーバーの変更」

- 7.3項「仮想サーバーの変更」

- 9.3項「リスナーの変更」

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。3.3項「構成の変更のアクティブ化」の説明に従い、「変更のデプロイ」をクリックして更新した構成を即時にデプロイすることも、さらに変更を行って、その後でデプロイすることもできます。

注意:
「詳細設定」ページで「一時ディレクトリ」の値を変更した場合、構成のすべてのインスタンスをまず停止して、変更をデプロイし、次にインスタンスを起動します。
実行中のインスタンスを停止せずに変更をデプロイした場合、インスタンスを後で停止しようとしたときにエラーが発生する場合があります。この問題を解決するための詳細は、16.2.5項「一時ディレクトリの変更後にインスタンスを停止できない」を参照してください。

WLSTを使用した構成の変更

WLSTでは、構成の特定のパラメータの変更に使用できるいくつかのコマンド(表3-1を参照)が用意されています。

注意:
構成内の仮想サーバー、リスナー、オリジン・サーバー・プールおよびオリジン・サーバーのプロパティを変更するWLSTコマンドの詳細は、次の章を参照してください。

- 第5章「オリジン・サーバー・プールの管理」

- 第6章「オリジン・サーバーの管理」

- 第7章「仮想サーバーの管理」

- 第9章「リスナーの管理」

表3-1 構成変更用のWLSTコマンド

タスク

WLSTコマンド

構成プロパティの変更

otd_setConfigurationProperties

アクセス・ログ・バッファ・プロパティの変更

otd_setAccessLogBufferProperties

otd_getAccessLogBufferProperties

キャッシュ・プロパティの変更

otd_setCacheProperties

otd_getCacheProperties

DNSプロパティの変更

otd_setDnsProperties

otd_getDnsProperties

DNSキャッシュ・プロパティの変更

otd_setDnsCacheProperties

otd_getDnsCacheProperties

HTTPリクエスト・プロパティの変更

otd_setHttpProperties

otd_getHttpProperties

クライアント接続のキープ・アライブ設定の変更

otd_setKeepAliveProperties

otd_getKeepAliveProperties

エラー・ログ設定の変更

otd_setLogProperties

otd_getLogProperties

SNMPの有効化

otd_setSnmpProperties

otd_getSnmpProperties

SSL/TLSセッションのキャッシュ・プロパティの変更

otd_setSslSessionCacheProperties

otd_getSslSessionCacheProperties

統計集計プロパティの変更

otd_setStatsProperties

otd_getStatsProperties

HTTPスレッド・プール・プロパティの変更

otd_setHttpThreadPoolProperties

otd_getHttpThreadPoolProperties

TCPスレッド・プール・プロパティの変更

otd_setTcpThreadPoolProperties

otd_getTcpThreadPoolProperties

たとえば、次のコマンドでは、構成fooのログ・レベルが、最も冗長な(詳細な)設定であるTRACE:32に変更されます。

props = {}
props['configuration'] = 'foo'
otd_getConfigurationProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

3.5 構成のコピー

既存の構成に似た構成を作成する場合、既存の構成をコピーし、必要な変更を後から実行できます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成をコピーできます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した構成のコピー

Fusion Middleware Controlを使用して構成をコピーするには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってTraffic DirectorのFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. コピーする構成を選択します。

5. 「共通のタスク」ペインで、「構成の複製」をクリックします。

6. 結果のダイアログ・ボックスで、新規構成の名前を入力し、「OK」をクリックします
構成がコピーされたことを確認するメッセージが表示されます。

7. 「OK」をクリックします。

WLSTを使用した構成のコピー

構成をコピーするには、otd_copyConfigurationコマンドを実行します。

たとえば、次のコマンドでは、構成fooがfoo1という名前の新規構成にコピーされます。

props = {}
props['source-configuration'] = 'foo'
props['dest-configuration'] = 'bar'
otd_copyConfiguration(props)

otd_copyConfigurationの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

3.6 構成の削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成を削除できます。

注意:

- 1つ以上のフェイルオーバー・グループのある構成を削除するには、まずフェイルオーバー・グループを削除する必要があります。詳細は、14.2.2項「フェイルオーバー・グループの管理」を参照してください。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した構成の削除

Fusion Middleware Controlを使用して構成を削除するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 削除する構成を選択します。

5. 「共通のタスク」ペインで、「構成の削除」をクリックします。

- 削除する構成のインスタンスが存在しない場合、構成の削除を確認するプロンプトが表示されます。

1. 「OK」をクリックします。
構成が削除されたことを確認するメッセージが表示されます。

2. 「OK」をクリックします。

- 削除する構成のインスタンスが存在する場合、構成がデプロイされている管理ノードがリストされたダイアログ・ボックスが表示されます。リストには、インスタンスが実行中であるかどうかも示されます。

1. 削除を続行する場合、「インスタンス・ログの保存」チェック・ボックスを選択することで、インスタンスのログ・ファイルの保存を選択できます。
削除を確認するには、「OK」をクリックします。

構成およびそのインスタンスが削除されたことを確認するメッセージが表示されます。

2. 「OK」をクリックします。

注意:
「インスタンス・ログの保存」チェック・ボックスを選択した場合、削除されたインスタンスのサーバー・アクセスおよびエラー・ログは、INSTANCE_HOME/net-config_name/logsディレクトリに保持されます。

6. 削除する構成に対応する「削除」ボタンをクリックします。

WLSTを使用した構成の削除

注意:
インスタンスが実行中か停止中かにかかわらず、構成のインスタンスが管理ノードにデプロイされている場合は、WLSTを使用して構成を削除できません。
WLSTを使用してこのような構成を削除するには、まずそのインスタンスをすべて削除する必要があります。

構成を削除するには、次の例に示すように、otd_deleteConfigurationコマンドを実行します。

# Online
props = {}
props['configuration'] = 'foo'
otd_deleteConfiguration(props)

# Offline
readDomain('/export/2110_12c/iplanet/ias/server/work/TD_Linux2.6_DBG.OBJ/domains/otd_domain')
props = {}
props['configuration'] = 'foo'
otd_deleteConfiguration(props)
updateDomain()
closeDomain()

otd_deleteConfigurationの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください

オフライン・モードの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のオフライン・コマンドに関する項を参照してください。

4 インスタンスの管理

インスタンスは、管理ノードまたは管理サーバーで実行中であり、クライアントからのリクエストを1つ以上のポートでリスニングしているOracle Traffic Directorサーバーを指します。

この章には次の項が含まれます:

- Oracle Traffic Directorインスタンスの作成

- Oracle Traffic Directorインスタンスのリストの表示

- Oracle Traffic Directorインスタンスの起動、停止および再起動

- 再起動が不要なOracle Traffic Directorインスタンスの更新

- Oracle Traffic Directorインスタンスの削除

- スケジュール済のイベントによるOracle Traffic Directorインスタンスの制御

4.1 Oracle Traffic Directorインスタンスの作成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、Oracle Traffic Directorインスタンスを作成できます。

注意:
WLSTの使用方法の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Oracle Traffic Directorインスタンスの作成の前提条件

インスタンスを作成できるようにするには、次の操作を完了しておく必要があります。

- 構成の定義(3.1項「構成の作成」を参照)。

Fusion Middleware Controlを使用したOracle Traffic Directorインスタンスの作成

Fusion Middleware Controlを使用してOracle Traffic Directorインスタンスを作成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってTraffic DirectorのFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. インスタンスを作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「インスタンス」を選択します。
「インスタンス」ページが表示されます。

7. 「共通タスク」ペインで、「作成」をクリックします。
新規インスタンス・ウィザードが表示されます。

8. 構成のインスタンスを作成する必要がある管理ノードに対応するチェック・ボックスを選択します。次に、「OK」をクリックします。

9. インスタンスの作成が正常に完了したことを確認するメッセージが表示されます。

10. 作成したインスタンスを含む「インスタンス」ページが表示されます。

WLSTを使用したOracle Traffic Directorインスタンスの作成

Oracle Traffic Directorインスタンスを1つ以上作成するには、otd_createInstanceコマンドを実行します。

たとえば、次のコマンドを実行すると、machine1というマシンにfooという名前の構成のインスタンスが作成されます。

# Online
props = {}
props['configuration'] = 'foo'
props['machine'] = 'machine1'
otd_createInstance(props)

# Offline
readDomain('/export/2110_12c/iplanet/ias/server/work/TD_Linux2.6_DBG.OBJ/domains/otd_domain')
props = {}
props['configuration'] = 'foo'
props['machine'] = 'machine1'
otd_createInstance(props)
updateDomain()
closeDomain()

注意:
Windowsでは、どの時点であっても、OTDインスタンスを持つドメインは1つのみ許可されます。OTDインスタンスを持たないドメインであれば、複数が存在できます。

otd_createInstanceの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

オフライン・モードの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のオフライン・コマンドに関する項を参照してください。

4.2 Oracle Traffic Directorインスタンスのリストの表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、Oracle Traffic Directorインスタンスのリストを表示できます。

Fusion Middleware Controlを使用したOracle Traffic Directorインスタンスのリストの表示

Fusion Middleware Controlを使用してOracle Traffic Directorのリストを表示するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってTraffic DirectorのFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. インスタンスを表示する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「インスタンス」を選択します。

7. 図4-1に示すように、構成のインスタンスを示す「インスタンス」ページが表示されます。

図4-1 インスタンスのリスト

名前をクリックすると、インスタンスのプロパティを表示できます。

WLSTを使用したOracle Traffic Directorインスタンスのリストの表示

構成のOracle Traffic Directorインスタンスのリストを表示するには、次の例に示すように、otd_listInstancesコマンドを実行します。

# Online
props = {}
props['configuration'] = 'foo'
otd_listInstances(props)

# Offline
readDomain('/export/2110_12c/iplanet/ias/server/work/TD_Linux2.6_DBG.OBJ/domains/otd_domain')
props = {}
props['configuration'] = 'foo'
otd_listInstances(props)
closeDomain()

オフライン・モードの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のオフライン・コマンドに関する項を参照してください。

4.3 Oracle Traffic Directorインスタンスの起動、停止および再起動

Fusion Middleware ControlまたはWLSTのいずれかを使用して、Oracle Traffic Directorインスタンスを起動、停止および再起動できます。

Fusion Middleware Controlを使用したOracle Traffic Directorインスタンスの起動、停止および再起動

Fusion Middleware Controlを使用してOracle Traffic Directorインスタンスを起動、停止または再起動するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってTraffic DirectorのFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. インスタンスを起動、停止または再起動する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「インスタンス」を選択します。
「インスタンス」ページが表示されます。

7. 使用可能なインスタンスのリストを選択します。
起動、停止または再起動するインスタンスについて、必要に応じて、「インスタンスの起動」、「インスタンスの停止」または「インスタンスの再起動」ボタンをクリックします。

WLSTを使用したOracle Traffic Directorインスタンスの起動、停止および再起動

1つの構成の1つ以上のOracle Traffic Directorインスタンスを起動、停止または再起動するには、start、shutdownまたはsoftRestartコマンドを実行します。

たとえば、次の3つのコマンドは、otd_foo_machine1マシン上のインスタンスを起動、再起動および停止します。

start('otd_foo_machine1')

shutdown('otd_foo_machine1')

softRestart('otd_foo_machine1')

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

4.4 再起動が不要なOracle Traffic Directorインスタンスの更新

構成パラメータの中には、変更しても構成の変更を有効にするために実行中の構成のOracle Traffic Directorインスタンスを再起動する必要のないものもあります。Oracle Traffic Directorインスタンスを動的に再構成して、新しい構成を反映できます。

動的に再構成可能な構成の変更のみが反映されます。user、temp-path、log、thread-pool、pkcs11、stats、dns、dns-cache、ssl-session-cacheおよびaccess-log-bufferの各設定の変更は、再構成手順の完了後も同じままです。再構成の完了時に再起動を必要とする変更があった場合は、再起動が必要という例外がスローされます。

動的構成をサポートするパラメータのリストは、『Oracle Traffic Director構成ファイル・リファレンス』の動的再構成に関する項を参照してください。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、実行中の構成のインスタンスを動的に再構成できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したOracle Traffic Directorインスタンスの再構成

Fusion Middleware Controlを使用してOracle Traffic Directorインスタンスを再構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってTraffic DirectorのFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. インスタンスを再構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「インスタンス」を選択します。
「インスタンス」ページが表示されます。

7. 使用可能なリストから「インスタンス」を選択します。

8. 動的に更新するインスタンスの「再構成」ボタンをクリックします。
「コンソール・メッセージ」ペインにインスタンスが再構成されたことを確認するメッセージが表示されます。

WLSTを使用したOracle Traffic Directorインスタンスの再構成

WLSTを使用して構成のインスタンスを再構成するには、次のようにsoftRestartコマンドを実行します。

props = java.util.Properties()
props.setProperty("MODE", "RECONFIG")
softRestart('otd_foo_machine1', props=props)

詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

4.5 Oracle Traffic Directorインスタンスの削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成のインスタンスを削除できます。

Fusion Middleware Controlを使用したOracle Traffic Directorインスタンスの削除

Fusion Middleware Controlを使用してOracle Traffic Directorインスタンスを削除するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってTraffic DirectorのFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. インスタンスを削除する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「インスタンス」を選択します。
「インスタンス」ページが表示されます。

7. 使用可能なリストから「インスタンス」を選択します。

8. 削除するインスタンスの「削除」ボタンをクリックします。

注意:
フェイルオーバー・グループの一部であるインスタンスを削除するには、まずフェイルオーバー・グループからインスタンスを削除する必要があります。詳細は、14.2.2項「フェイルオーバー・グループの管理」を参照してください。

「コンソール・メッセージ」ペインに、インスタンスが削除されたことを確認するメッセージが表示されます。

WLSTを使用したOracle Traffic Directorインスタンスの削除

構成のOracle Traffic Directorインスタンスを削除するには、otd_deleteInstanceコマンドを実行します。

たとえば、次のコマンドは、構成のインスタンスを削除します。

# Online
props = {}
props['configuration'] = 'foo'
props['instance'] = 'otd_foo_machine1'
otd_deleteInstance(props)

# Offline
readDomain('/export/2110_12c/iplanet/ias/server/work/TD_Linux2.6_DBG.OBJ/domains/otd_domain')
props = {}
props['configuration'] = 'foo'
props['instance'] = 'otd_foo_machine1'
otd_deleteInstance(props)
updateDomain()
closeDomain()

otd_deleteInstanceの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

オフライン・モードの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のオフライン・コマンドに関する項を参照してください。

4.6 スケジュール済のイベントによるOracle Traffic Directorインスタンスの制御

管理者として、多数の構成およびインスタンスを管理する必要がある場合、各構成のインスタンスを個別に再起動および再構成するなどの反復的なタスクは単調な作業になりがちです。管理タスクを、定義した間隔、つまり特定の曜日、時間または日付で自動実行するようにイベントをスケジュールできます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、イベントを作成および管理できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したイベントの管理

Fusion Middleware Controlを使用してイベントを管理するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. イベントをスケジュールする構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「予定イベント」を選択します。
「予定イベント」ページが表示されます。

7. ページの「予定イベント」セクションにスクロール・ダウンします。
ここには、構成に現在スケジュールされているイベントがリストされます。

- イベントを有効または無効にするには、「有効化/無効化」チェック・ボックスを選択します。

- イベントを削除するには、「削除」アイコンをクリックします。

- イベントを作成するには、「新規イベント」をクリックします。
「新規構成イベント」ダイアログ・ボックスが表示されます。

スケジュールを設定するイベントを選択し、イベントの実行間隔または時刻を指定し、「OK」をクリックします。

変更を確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。3.3項「構成の変更のアクティブ化」の説明に従い、「変更のデプロイ」をクリックして更新した構成を即時にデプロイすることも、さらに変更を行って、その後でデプロイすることもできます。

WLSTを使用したイベントの管理

- イベントの作成
イベントを作成するには、次の例に示すように、otd_createEventコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['event'] = 'event-1'
props['command'] = 'bar'
props['time'] = '12:00'
otd_createEvent(props)

最初のコマンドは、コマンド「bar」を午後12時に実行するようにイベントをスケジュールします。

注意:
スケジュールされたイベントを有効にするには、構成を再デプロイする必要があります。

- イベントのリストの表示
スケジュールされているイベントのリストを表示するには、otd_listEventsコマンドを実行します。

たとえば、構成のインスタンスにスケジュールされているイベントを表示するには、次のようにします。

props = {}
props['configuration'] = 'foo'
otd_listEvents(props)

- イベントの無効化
イベントを作成すると、それは自動的に有効になります。

イベントを無効にするには、「enabled」を「false」にした「otd_setEventProperties」コマンドを使用できます

イベントを無効にするには、enabledプロパティを次にようにfalseに設定します。

props = {}
props['configuration'] = 'foo'
props['event'] = 'bar'
props['enabled'] = 'false'
otd_setEventProperties(props)

- イベントの有効化
イベントを有効にするには、「enabled」を「true」にした「otd_setEventProperties」コマンドを使用できます

イベントを有効にするには、enabledプロパティを次にようにtrueに設定します。

props = {}
props['configuration'] = 'foo'
props['event'] = 'event-1'
props['enabled'] = 'true'
otd_setEventProperties(props)

- イベントの削除
イベントを削除するには、otd_deleteEventコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['event'] = 'event-1'
otd_deleteEvent(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

5 オリジン・サーバー・プールの管理

オリジン・サーバーは、バックエンドのサーバーであり、Oracle Traffic Directorはクライアントから受信したリクエストをこのサーバーに転送し、クライアント・リクエストに対するレスポンスをこのサーバーから受信します。たとえば、オリジン・サーバーには、Oracle WebLogic ServerインスタンスまたはOracle iPlanet Web Serverインスタンスなどが該当します。同じサービスを提供する、または同じコンテンツを提供するオリジン・サーバーのグループは、オリジン・サーバー・プールと呼ばれます。このようなオリジン・サーバー・プールを構成内にいくつか定義し、特定のプールにクライアント・リクエストをルーティングするようにOracle Traffic Directorインスタンス内に各仮想サーバーを構成できます。

この章では、オリジン・サーバー・プールを作成および管理する方法を説明します。ここの内容は、次のとおりです。

- オリジン・サーバー・プールの作成

- オリジン・サーバー・プールのリストの表示

- オリジン・サーバー・プールの変更

- オリジン・サーバー・プールの削除

- Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成

- カスタム・メンテナンス・ページの構成

- オリジン・サーバー・プールのヘルス・チェック設定の構成

5.1 オリジン・サーバー・プールの作成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールを作成できます。

注意:

- オリジン・サーバー・プールを作成すると、実質的には構成が変更されます。新しいオリジン・サーバー・プールの設定をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

始める前に

オリジン・サーバー・プールの作成を開始する前に、次の項目を決定します。

- オリジン・サーバー・プールの一意の名前。オリジン・サーバー・プールを作成した後は名前を変更できないため、名前は慎重に選択してください。

- オリジン・サーバー・プール内のサーバーのhost:portの組合せ。

注意:
プールを作成するオリジン・サーバーが、クラスタ内のOracle WebLogic Server管理対象サーバーの場合、管理対象サーバーのいずれか1つをオリジン・サーバーとして使用してプールを作成すれば十分です。その後、プール内のその他の管理対象サーバーを動的に検出するようにOracle Traffic Directorを構成することができます。詳細は、5.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。

- プール内のサーバーの通信プロトコル(HTTP/SまたはTCP)。

- オリジン・サーバー・プール内のサーバーがリクエストのリスニングに使用するアドレス・ファミリ。
サポートされているアドレス・ファミリは次のとおりです。

- inet (IPv4)

- inet6 (IPv6)

- inet-sdp (ソケット・ダイレクト・プロトコル): オリジン・サーバー・プール内のサーバーがインフィニバンド・ファブリック上にあり、SDPインタフェースでリスニングしている場合(Oracle ExalogicマシンにデプロイされているOracle WebLogic Serverなど)、このファミリを選択します。

注意:
Oracle Traffic DirectorとWebLogic Serverの通信をSDPで行うには、WebLogic Server側に追加の構成手順が必要になります。これらの構成手順の詳細は、Oracle Fusion Middleware Exalogic Enterpriseデプロイメント・ガイドのクラスタレベルのセッション・レプリケーション強化の有効化に関する項を参照してください。

Fusion Middleware Controlを使用したオリジン・サーバー・プールの作成

Fusion Middleware Controlを使用してオリジン・サーバー・プールを作成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. オリジン・サーバー・プールを必要とする構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。その構成に定義されているサーバー・プール(HTTP/SおよびTCPサーバー・プール)のリストが表示されます。

7. 構成するサーバー・プールを選択します。

8. 「共通タスク」ペインで、「作成」ボタンをクリックします。
「オリジン・サーバー・プールの作成」ページが表示されます。

図5-1 オリジン・サーバー・プールの作成

9. 画面上のプロンプトに従い、前に決定した詳細(名前、タイプなど)を使用して、オリジン・サーバー・プールの作成を完了します。
オリジン・サーバー・プールが定義されたら、画面の右上にある「OK」をクリックします。「新規オリジン・サーバー・プール」の結果画面に、オリジン・サーバー・プールの作成が成功したことを示すメッセージが表示されます。

10. 作成したオリジン・サーバー・プールの詳細が、「オリジン・サーバー・プール」ページに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。3.3項「構成の変更のアクティブ化」の説明に従い、「変更のデプロイ」をクリックして更新した構成を即時にデプロイすることも、さらに変更を行って、その後でデプロイすることもできます。

WLSTを使用したオリジン・サーバー・プールの作成

オリジン・サーバー・プールを作成するには、otd_createOriginServerPoolコマンドを実行します。

たとえば、次のコマンドは、構成foo内にオリジン・サーバーwww.example.com:12345を含むオリジン・サーバー・プールorigin-server-pool-1を作成します。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['origin-server'] = 'www.example.com:12345'
otd_createOriginServerPool(props)

otd_createOriginServerPoolの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

HTTP転送プロキシ・サーバーの指定

otd_createOriginServerPoolコマンドはオプションとしてproxy-serverを受け取り、このオプションは、プールのメンバーであるすべてのオリジン・サーバーが構成済転送プロキシ・サーバーを介して通信するように、オリジン・サーバー・プールに関連付けるHTTP転送プロキシ・サーバーの指定に使用できます。タイプは、httpまたはhttpsである必要があります。

例:

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['origin-server'] = 'www.example.com:12345'
props['type'] = 'http'
props['proxy-server'] = 'proxy.example.com:12345'
otd_createOriginServerPool(props)

otd_createOriginServerPoolの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

5.2 オリジン・サーバー・プールのリストの表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールのリストを表示できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したオリジン・サーバー・プールのリストの表示

Fusion Middleware Controlを使用してオリジン・サーバー・プールのリストを表示するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. オリジン・サーバー・プールを表示する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。

7. その構成に定義されているオリジン・サーバー・プールのリストが表示されます。

名前をクリックすると、オリジン・サーバー・プールのプロパティの詳細を表示できます。

WLSTを使用したオリジン・サーバー・プール・リストの表示

オリジン・サーバー・プールのリストを表示するには、次の例に示すように、otd_listOriginServerPoolsコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_listOriginServerPools(props)

otd_getOriginServerPoolPropertiesおよびotd_getHealthCheckPropertiesコマンドのそれぞれを実行して、オリジン・サーバー・プールの一般的なプロパティおよびヘルスチェック設定を表示できます。

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

5.3 オリジン・サーバー・プールの変更

Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールのプロパティを変更できます。

注意:

- オリジン・サーバー・プールを変更すると、実質的には構成が変更されます。更新されたオリジン・サーバー・プールの設定をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したオリジン・サーバー・プールのプロパティの変更

Fusion Middleware Controlを使用してオリジン・サーバー・プールのプロパティを変更するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. オリジン・サーバー・プールを変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。

7. 構成に定義されているオリジン・サーバー・プールのリストが表示されます。

8. 変更するオリジン・サーバー・プールの名前をクリックします。
「共通タスク」ペインにある「編集」ボタンをクリックします
オリジン・サーバー・プール設定ページが表示されます。このページで、次の処理が可能です。

- プール内のサーバーのネットワーク・プロトコル(IPv4、IPv6またはSDP)の変更。

- プロキシ・サーバーを通じたオリジン・サーバーへの接続に関する項に従ってプロキシ・サーバーを設定します。この設定は、HTTP転送プロキシ・サーバーをオリジン・サーバー・プールへ関連付けるように指定するため、プールのすべてのメンバー・オリジン・サーバーは構成済HTTP転送プロキシ・サーバーを通じて通信されます。

- Oracle Traffic Directorがクライアント・リクエストをプールに分散する際に使用するロード・バランシング方法の変更。

- 最小接続件数(デフォルト): リクエストの処理時、Oracle Traffic Directorは、各オリジン・サーバーで現在アクティブである接続数を評価し、アクティブな接続数が最も少ないオリジン・サーバーにリクエストを転送します。
最小接続件数メソッドは、より処理の速いオリジン・サーバーに少ないアクティブ接続数しかなく、そのため、より多くの負荷をかけられるという前提の場合に機能します。ロード分散をオリジン・サーバーの容量に基づいてより詳細に調整するには、相対的な重みをオリジン・サーバーに割当てできます。

注意:
WebSocket接続は長期にわたって存続する可能性があり、接続が閉じられるまではアクティブの接続としてカウントされます。そのため、最小接続件数によるロード・バランシング・アルゴリズムに影響することがあります。

- 最小レスポンス時間: ほとんどのワークロードは最小接続件数で効率よく処理できますが、同量のワークロードに対するレスポンス時間が、指定されたプール内の各オリジン・サーバーによって異なるケースも考えられます。例:

- 指定されたプール内のオリジン・サーバーがハードウェア仕様の異なるマシンにそれぞれデプロイされている場合。

- 一部のオリジン・サーバー・ノードが他のサービスで使用されている場合。

- ネットワーク接続性が各ノードで異なる場合、または一部のネットワーク・インタフェースに他のインタフェースよりも高い負荷がかかっている場合。

このような状況では最小レスポンス時間の使用が効果的です。これは動的な重み付け最小接続アルゴリズムであり、重みはレスポンス時間に基づいて計算されます。これらの重みはオリジン・サーバーのレスポンス状況に応じて常に調整されます。最小レスポンス時間では、最小接続アルゴリズムで必要な手動の重み調整が不要です。

- ラウンド・ロビン: Oracle Traffic Directorは、1番目のリクエストをプール内の1番目のオリジン・サーバーに、2番目のリクエストを次のオリジン・サーバーというように、使用可能なオリジン・サーバーにリクエストを順次転送します。プール内の最後のオリジン・サーバーにリクエストが送信された後、最初のオリジン・サーバーから再び始まります。
ラウンド・ロビン・メソッドは、単純で予測可能であり、処理のオーバーヘッドが少なくて済みますが、オリジン・サーバーの能力の差が無視されます。このため、時間の経過とともに、特に処理速度が遅いオリジン・サーバーにリクエストが累積する可能性があります。この問題を解決するには、相対的な重みをオリジン・サーバーに割り当て、重み付けされたラウンド・ロビン・メソッドを使用できます。

- IPハッシュ: 同じクライアントIPアドレスからのすべての受信リクエストは、同じコンテンツ作成サーバーに向けられます。このロード・バランシング・ポリシーは、TCPのロード・バランシングのコンテキストで特に役立ち、Oracle Traffic Directorでは、このロード・バランシング・ポリシーを使用するように顧客に提案しています。

オリジン・サーバーへの重みの割当ての詳細は、6.3項「オリジン・サーバーの変更」を参照してください。

- ヘルス・チェック設定の構成。詳細は、5.7項「オリジン・サーバー・プールのヘルス・チェック設定の構成」を参照してください。

- Oracle Traffic Directorが、クラスタ内のOracle WebLogic Server管理対象サーバーを自動検出するかどうかの指定。詳細は、5.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。

注意:
プール内のオリジン・サーバーの追加、変更および削除は、ナビゲーション・ペインで「オリジン・サーバー」を選択することで実行できます。詳細は、第6章「オリジン・サーバーの管理」を参照してください。

9. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「取消」ボタンをクリックすることで、いつでも変更を破棄できます。

10. 必要な変更を行った後、「OK」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。3.3項「構成の変更のアクティブ化」の説明に従い、「変更のデプロイ」をクリックして更新した構成を即時にデプロイすることも、さらに変更を行って、その後でデプロイすることもできます。

WLSTを使用したオリジン・サーバー・プールのプロパティの変更

- オリジン・サーバー・プールのネットワーク・プロトコルおよびロード・バランシング・メソッドを変更するには、otd_setOriginServerPoolPropertiesコマンドを実行します。
たとえば、次のコマンドを実行すると、構成fooのオリジン・サーバー・プールorigin-server-pool-1のロード・バランシング・メソッドが最小接続件数メソッドに変更されます。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['load-distribution'] = 'least-connection-count'
otd_setOriginServerPoolProperties(props)

- オリジン・サーバー・プールのヘルス・チェック・パラメータを変更するには、otd_setHealthCheckPropertiesコマンドを実行します。
たとえば、次のコマンドは、構成fooのオリジン・サーバー・プールorigin-server-pool-1内のサーバーのレスポンス本文のサイズを4096バイトに変更します。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['response-body-match-size'] = '4096'
otd_setHealthCheckProperties(props)

otd_setOriginServerPoolPropertiesおよびotd_setHealthCheckPropertiesコマンドを使用して設定または変更できるプロパティのリストは、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

5.4 オリジン・サーバー・プールの削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールを削除できます。

注意:

- 仮想サーバーの1つ以上のルートに関連付けられているオリジン・サーバー・プールは削除できません。
ルートに関連付けられているオリジン・サーバー・プールを削除するには、7.4項「ルートの構成」の説明に従い、そのルートをまず削除する必要があります。

- オリジン・サーバー・プールを作成すると、実質的には構成が削除されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したオリジン・サーバー・プールの削除

Fusion Middleware Controlを使用してオリジン・サーバー・プールを削除するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. オリジン・サーバー・プールを削除する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。

7. 構成に定義されているオリジン・サーバー・プールのリストが表示されます。

8. 使用可能リストから削除するプールを選択します。

9. 「共通タスク」ペインにある「削除」ボタンをクリックします。

- オリジン・サーバー・プールが仮想サーバーの1つ以上のルートに関連付けられている場合、プールを削除できないことを示すメッセージが表示されます。

- オリジン・サーバー・プールが仮想サーバーに関連付けられていない場合、削除を確認するプロンプトが表示されます。

10. 「はい」をクリックします。
オリジン・サーバー・プールが削除されます。

WLSTを使用したオリジン・サーバー・プールの削除

オリジン・サーバー・プールを削除するには、次の例に示すように、otd_deleteOriginServerPoolコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
otd_deleteOriginServerPool(props)

otd_deleteOriginServerPoolの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

5.5 Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成

注意:
Oracle Traffic Directorは、WebLogic Serverプラグインで提供される一部の一般機能をビルトイン機能によってサポートします。そのため、WebLogic Serverとの相互運用性を実現するためにOracle Traffic Directorにプラグインを追加する必要はありません。

Oracle WebLogic Server管理対象サーバーのクラスタを表すオリジン・サーバー・プールを作成する場合、クラスタ内の各管理対象サーバーをオリジン・サーバーとして指定する必要はありません。管理対象サーバーのいずれかを、プール内の1つのオリジン・サーバーとして指定するだけで十分です。Oracle Traffic Directorを、クラスタ内のその他のOracle WebLogic Serverインスタンスの存在を動的に検出し、オリジン・サーバーとして構成されている管理対象サーバー、および同じクラスタ内の動的に検出された管理対象サーバーにクライアント・リクエストを分散するように構成できます。

動的検出が有効な場合、クラスタ内の管理対象サーバーのいずれかが停止、追加または削除されたとき、オリジン・サーバー・プールの定義を更新する必要はありません。ただし、Oracle WebLogic Serverクラスタ内の変更を検出するために、Oracle Traffic Directorは、指定された間隔でヘルス・チェック・リクエストを送信するため、多少のオーバーヘッドが発生します。

5.5.1 動的検出の方法

オリジン・サーバー・プールの動的検出が有効な場合、Oracle Traffic Directorは次に示すように、クラスタ内の残りのOracle WebLogic Server管理対象サーバーを検出します。

1. Oracle Traffic Directorインスタンスは起動時に、プール内で指定済のオリジン・サーバーがOracle WebLogic Server管理対象サーバーであるかどうか、およびサーバーがクラスタに属しているかどうかを、各構成済オリジン・サーバーにHTTPヘルス・チェック・リクエストを送信することでチェックします。
オリジン・サーバーのレスポンスにより、サーバーがOracle WebLogic Server管理対象サーバーであるかどうかが示されます。オリジン・サーバーが、クラスタに属するOracle WebLogic Server管理対象サーバーである場合、レスポンスには、クラスタ内の管理対象サーバーのリストが含まれます。

2. Oracle Traffic Directorは、オリジン・サーバーからのレスポンス内の情報を使用して、検出された管理対象サーバーの構成を更新します。
動的に検出されたオリジン・サーバーでは、構成済オリジン・サーバーに指定されたすべてのプロパティ(重み、最大接続数など)が継承されます。

3. 続いて、オリジン・サーバー・プールに構成された各ヘルス・チェック間隔(デフォルト: 30秒)で、Oracle Traffic Directorは、プール内でオリジン・サーバーとして構成されているOracle WebLogic Serverインスタンスに動的検出ヘルス・チェック・リクエストを送信し、変更の検出を試みます。
レスポンスに、前回のヘルス・チェック後クラスタ内に変更(管理対象サーバーの削除または追加)があることが示されている場合、Oracle Traffic Directorにより、動的に検出されたオリジン・サーバーの新しいセットで構成が更新されます。

注意:

- 動的に検出されたオリジン・サーバーは、インスタンス構成のオリジン・サーバー・プール定義に永久的に格納されません。したがって、Oracle Traffic Directorインスタンスを再起動すると、動的検出のプロセスは再び最初から開始されます。

- Oracle Traffic Directorが動的検出のために送信するHTTPリクエスト・タイプは、オリジン・サーバー・プールに現在構成されているヘルス・チェック・リクエスト・タイプ(OPTIONS(デフォルト)またはGET)です。詳細は、5.7項「オリジン・サーバー・プールのヘルス・チェック設定の構成」を参照してください。

5.5.2 動的検出の有効化

オリジン・サーバー・プールの作成時、クラスタ内のOracle WebLogic Server管理対象サーバーの動的検出は、デフォルトでは有効化されません。Fusion Middleware ControlまたはWLSTのいずれかを使用して、動的検出を有効にできます。

注意:

- オリジン・サーバー・プールを変更すると、実質的には構成が変更されます。更新されたオリジン・サーバー・プールの設定をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した動的検出の有効化

Fusion Middleware Controlを使用してクラスタ内のWebLogic Server管理対象サーバーの動的検出を有効にするには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 動的検出を有効化する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。

7. 構成に定義されているオリジン・サーバー・プールのリストが表示されます。

8. 使用可能リストから動的検出を有効にするプールを選択します。

9. ページの「詳細設定」セクションに移動します。

10. 「ヘルス・チェック」サブセクションで、「プロトコル」がHTTPであることを確認し、「動的検出」チェック・ボックスを選択します。

11. ウィンドウの右上隅にある「OK」ボタンをクリックします。

注意:
現在のヘルス・チェック・プロトコルがTCPの場合、動的検出を有効化するために、プロトコルをHTTPに変更する必要があることを示すエラー・メッセージが表示されます。

「コンソール・メッセージ」ペインに、更新されたヘルス・チェック設定が保存されたことを確認するメッセージが表示されます。

WLSTを使用した動的検出の有効化

クラスタ内のOracle WebLogic Server管理対象サーバーの動的検出を有効にするには、otd_setHealthCheckPropertiesコマンドを実行します。

たとえば、次のコマンドでは、origin-server-pool-1オリジン・サーバー・プールであるOracle WebLogic Serverクラスタの管理対象サーバーの動的検出が有効になります。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['dynamic-server-discovery'] = '4096'
otd_setHealthCheckProperties(props)

注意:
現在のヘルス・チェック・プロトコルがTCPの場合、動的検出を有効化するために、プロトコルをHTTPに変更する必要があることを示すエラー・メッセージが表示されます。

otd_setHealthCheckPropertiesの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

5.6 カスタム・メンテナンス・ページの構成

バックエンド・サーバーのメンテナンスが必要な場合に、カスタム・レスポンス・コードおよびHTMLページを提供するようにOracle Traffic Directorを構成します。メッセージのこのタイプを表示させることは、ゲートウェイがタイムアウトしたり、ホストの静的コンテンツに対して別のリソースを作成したりするより適切です。

オリジン・サーバー・プールのメンテナンスが有効化されている場合、次のようになります。

- response-codeとresponse-fileの両方が構成されていない場合、Oracle Traffic Directorへのすべてのリクエストは503レスポンス・コードで中断されます。

- response-codeのみが構成されている場合、Oracle Traffic Directorへのすべてのリクエストはresponse-codeの値をレスポンス・コードとして中断されます。

- 両方が指定されている場合、Oracle Traffic Directorへのすべてのリクエストは中断されず、response-fileコンテンツおよびresponse-codeの値をレスポンス・コードとして応答されます。

- そのオリジン・サーバーのヘルス・チェックは無効になります。

オリジン・サーバー・プールのメンテナンスが無効だが、オリジン・サーバーが構成されていなく、有効にもなっていない場合、次のようになります。

- Oracle Traffic Directorへのすべてのリクエストは503レスポンス・コードで中断されます。

- そのオリジン・サーバーのヘルス・チェックは無効になります。

メンテナンスでのオリジン・サーバー・プールの統計の監視

オリジン・サーバー・プールがメンテナンス状態の場合、オリジン・サーバー・プールおよびオリジン・サーバーの統計はありません。統計はアクティブ・オリジン・サーバー・プールおよびアクティブ・オリジン・サーバーに対してのみ有効になります。

WLSTを使用したオリジン・サーバー・プールのメンテナンスの有効化または無効化

オリジン・サーバー・プールのメンテナンスを有効にするには、otd_enableOriginServerPoolMaintenanceコマンドを実行します。

たとえば、次のコマンドはorigin-server-pool-1オリジン・サーバー・プールのメンテナンスを有効にし、503のレスポンス・コードを指定します。このコマンドはresponse-codeとresponse-fileをオプションのプロパティとして使用します。200のresponse-codeはresponse-fileなしでは指定できません。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['response-code'] = '503'
otd_enableOriginServerPoolMaintenance(props)

メンテナンスを無効にするには、otd_disableOriginServerPoolMaintenanceコマンドを使用します。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
otd_disableOriginServerPoolMaintenance(props)

オリジン・サーバー・プールのenabled、response-fileおよびresponse-codeプロパティを取得するには、otd_getOriginServerPoolMaintenancePropertiesコマンドを使用します。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
otd_getOriginServerPoolMaintenanceProperties(props)

otd_enableOriginServerPoolMaintenance、otd_disableOriginServerPoolMaintenanceおよびotd_getOriginServerPoolMaintenancePropertiesの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

5.7 オリジン・サーバー・プールのヘルス・チェック設定の構成

リクエストを受信できる使用可能なオリジン・サーバーにのみリクエストが分散されるように、Oracle Traffic Directorはヘルス・チェック・リクエストをプール内のすべてのオリジン・サーバーに送信することでオリジン・サーバーの可用性および状態を監視します。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールのヘルス・チェック・パラメータを構成できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Oracle Traffic Directorがヘルス・チェック・リクエストを送信するタイミング

Oracle Traffic Directorインスタンスの起動時に、構成済のすべてのオリジン・サーバー・プール内のすべてのオリジン・サーバーに対して初期ヘルス・チェックが実行されます。

初期ヘルス・チェックでオリジン・サーバーの状態が正常であると判明すると、次の状況の場合のみOracle Traffic Directorはさらにヘルス・チェック・リクエストをオリジン・サーバーに送信します。

- 前回のヘルス・チェック間隔全体を通して、サーバーによってリクエストが正常に処理されませんでした。

- 動的検出が、このオリジン・サーバー・プールで有効に設定されています。詳細は、5.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。

ヘルス・チェック(初期または後続のチェックのいずれか)でオリジン・サーバーが使用不可であることが判明した場合、Oracle Traffic Directorは、指定されたヘルス・チェック間隔でヘルス・チェックを繰り返します。

構成可能なヘルス・チェック設定

表5-1は、構成内の各オリジン・サーバー・プールについて構成できるヘルス・チェック設定を示しています。

表5-1 ヘルス・チェック・パラメータ

パラメータ

デフォルト値

Oracle Traffic Directorが、オリジン・サーバーの状態を判別するために使用するオリジン・サーバーとの接続のタイプ(HTTP、TCPまたはCOMMAND)。

- TCP接続: Oracle Traffic Directorは、各オリジン・サーバーに対してTCP接続のオープンを試みます。

- HTTPリクエスト: Oracle Traffic Directorは、プール内の各オリジン・サーバーにHTTP GETまたはOPTIONSリクエストを送信してレスポンスを確認し、オリジン・サーバーの可用性およびヘルス状態を判別します。
注意: クラスタ内のOracle WebLogic Server管理対象サーバーの動的検出を有効にする場合は、ヘルス・チェックの接続タイプはHTTPにする必要があります。

- COMMAND: Oracle Traffic Directorは、顧客が作成した外部実行可能ファイルを使用し、特定のオリジン・サーバーの状態を監視します。このメカニズムは、様々なサービスを提供するオリジン・サーバーにプロトコル・レベルのヘルス・チェック・モニターが必要なときに役立ちます。

HTTP

ヘルス・チェック・リクエストが送信される頻度。

30秒

オリジン・サーバーからレスポンスが返されなかった場合、ヘルス・チェック・リクエストがタイムアウトとなるまでの時間。

5秒

Oracle Traffic Directorがプール内のオリジン・サーバーに接続を試行する場合に、接続不可と判断されるまでの試行回数。

5

送信する必要のあるHTTPリクエスト・メソッド(GETまたはOPTIONS)。

オプション

HTTPリクエストに送信されるURI。

/

正常なオリジン・サーバーのインジケータとしてOracle Traffic Directorが受け入れられるHTTPレスポンス・コード。

デフォルトでは、Oracle Traffic Directorは、正常なオリジン・サーバーのインジケータとして1xxから4xxまでのレスポンス・コード受け入れます。

HTTP GETヘルス・チェック・リクエストの場合、正常なオリジン・サーバーのインジケータとしてOracle Traffic Directorが受け入れられるスポンス本文の正規表現。

HTTP GETヘルス・チェック・リクエストの場合、Oracle Traffic Directorが、レスポンス本文を指定済の受入れ可能なレスポンス本文と比較するときに考慮する、レスポンス本文の最大バイト数。

2048

オリジン・サーバーが使用可能で正常と見なされる条件

構成されたヘルス・チェック接続タイプがTCPである場合、接続が正常に確立され、サーバーがそのサービス・ポートをアクティブにリスニングしていると、オリジン・サーバーは使用可能と見なされます。

構成されたヘルス・チェック接続タイプがHTTPである場合、次の条件がすべて満たされた場合、オリジン・サーバーは使用可能と見なされます。

- HTTPリクエストの送信中にエラーが発生していません。

- タイムアウト時間に達する前にレスポンスを受信しています。

- レスポンス内のステータス・コードが、受入れ可能なレスポンス・コード(指定されている場合)のいずれかと一致しています。
デフォルトでは、Oracle Traffic Directorは、正常なオリジン・サーバーのインジケータとして1xxから4xxまでのレスポンス・コード受け入れます。

- レスポンス本文が、受入れ可能なレスポンス本文(指定されている場合)と一致しています。

Fusion Middleware Controlを使用したオリジン・サーバーのヘルス・チェック設定の構成

Fusion Middleware Controlを使用してプール内のオリジン・サーバーのヘルス・チェック設定を表示および変更するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. オリジン・サーバーのヘルス・チェック設定を表示または変更する、構成を選択します。

4. ナビゲーション・ペインで、「オリジン・サーバー・プール」を展開し、ヘルス・チェック設定を表示または変更するオリジン・サーバー・プールを選択します。
「オリジン・サーバー・プール」ページが表示されます。構成に定義されたオリジン・サーバー・プールのリストが表示されます。

5. 変更するオリジン・サーバー・プールの名前をクリックします。
「サーバー・プール設定」ページが表示されます。

6. ページの「詳細設定」セクションに移動します。

7. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

8. 必要な変更を行った後、「保存」をクリックします。

WLSTを使用したオリジン・サーバーのヘルス・チェック設定の構成

- 構成内のオリジン・サーバー・プールの現在のヘルス・チェック設定を表示するには、次の例に示すように、otd_getHealthCheckPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
otd_getHealthCheckProperties(props)

protocol=HTTP
interval=30
timeout=5
failover-threshold=3
request-method=OPTIONS
request-uri=/
response-body-match-size=2048
dynamic-server-discovery=false

- 構成内のオリジン・サーバー・プールのヘルス・チェック設定を変更するには、otd_setHealthCheckPropertiesコマンドを実行します。
たとえば、次のコマンドにより、構成foo内のオリジン・サーバー・プールorigin-server-pool-1のヘルス・チェック間隔が60秒に変更され、ヘルス・チェックのタイムアウト時間が10秒に変更されます。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['interval'] = '60'
props['timeout'] = '10'
otd_setHealthCheckProperties(props)

この項で説明したコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

5.7.1 サーバーの状態をチェックするための外部ヘルス・チェック実行可能ファイルの使用

Oracle Traffic Directorは一般的なヘルス・チェック連結メカニズムをサポートしたことで、自分達のヘルス・チェックのプログラム/スクリプトを記述して特定のオリジン・サーバーのヘルスを監視できるようになりました。外部実行可能ファイルは、オリジン・サーバーのプロトコル・レベルのヘルス・チェック・モニターとして特に有用です。

外部実行可能ファイルを使用してサーバーの状態をチェックするようにOracle Traffic Directorを構成すると、Oracle Traffic Directorは定期的に実行可能ファイルを呼び出し、特定のパラメータを引数および環境変数として渡します。実行可能ファイルが、タイムアウトする前に正常にステータス・コード0を戻すと、Oracle Traffic Directorはサーバー・ステータスをオンラインに設定します。実行可能ファイルが0以外の値を戻すか、実行が終了する前にタイムアウトが発生すると、Oracle Traffic Directorは再試行することなく即座にサーバー・ステータスをオフラインに設定し、タイムアウトの場合には実行可能ファイルを停止します。実行可能ファイルが0以外のステータス・コードを戻すには様々な理由があります(コア・ダンプ、シグナル停止、外部実行可能ファイル自体のロジックが含まれます)。Oracle Traffic Directorは、戻りステータスが0以外の場合は常にサーバーをオフラインにマークします。

また、Oracle Traffic Directorは、実行可能ファイルの標準出力および標準エラーを取得し、イベント・ログ(サーバー・ログ)にメッセージをロギングします。

外部実行可能ファイルは実際のヘルス・チェック・ジョブを処理します。これには、オリジン・サーバーの接続の確立、リクエスト/応答の送信/受信、(該当する場合)SSLの処理、(必要に応じて)再試行ロジックなどが含まれます。実行可能ファイルは、ヘルス・チェック処理終了後、ステータス0で終了しサーバー・ステータスをオンラインに設定することが想定されています。実行可能ファイルがイベント・ログにメッセージをロギングするようにするには、標準出力にそれらのメッセージを出力します。

5.7.1.1 外部実行可能ファイルを使用するためのヘルス・チェック設定の構成

構成内のオリジン・サーバー・プールのヘルス・チェック設定を、外部の実行可能ファイルを使用するように構成するには、otd_setHealthCheckPropertiesコマンドを実行します。

たとえば、次のコマンドはヘルス・チェック・メソッドをcommandに設定し、外部のヘルス・チェック実行可能ファイルのパスとして/path/myhcscriptを指定します。間隔およびタイムアウト・プロパティも指定されます。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['protocol'] = 'command'
props['interval'] = '60'
props['timeout'] = '10'
props['command'] = '/path/myhcscript'
otd_setHealthCheckProperties(props)

注意:
オリジン・サーバー・プールのHTTPタイプの場合、COMMANDヘルス・チェック・プロトコルは次の場合には考慮されません。

- オリジン・サーバー・タイプがUNDETECTEDの場合、または

- オリジン・サーバー・タイプがWLSで、動的検出が設定されている場合。

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

5.7.1.2 外部のヘルス・チェック実行可能ファイルへのパラメータ

Oracle Traffic Directorは、パラメータを外部ヘルス・チェック実行可能ファイルへ2つの方法で渡します。特に、Oracle Traffic Directorは、引数でオリジン・サーバー・ホスト、オリジン・サーバー・ポートおよびタイムアウト値を渡し、ORACLE_HOME、INSTANCE_HOME、INSTANCE_NAME、DOMAIN_HOMEおよびOTD_LOG_LEVELに加えて既存の環境変数をすべて環境変数として渡します。引数パラメータは、次のコマンドの例で示すように、コマンドライン・オプションの形式で渡されます。

/path/myhcscript -h server1.myserver.com -p 389 -t 10

ここで、-h、-pおよび-tは、それぞれホスト、ポートおよびタイムアウトを表します。

表5-2 引数パラメータ

オプション

意味

-h

オリジン・サーバーのホスト。

-p

オリジン・サーバーのポート。

-t

ヘルス・チェック・タイムアウト。

その他のパラメータは、次のようにcommandパラメータに追加のオプション引数を指定することで外部実行可能ファイルに渡すことができます。

/path/myhcscript --secure -d /dbpath

同様に、Oracle Traffic Directorは追加引数を次のように外部実行可能ファイルに渡します。

/path/myhcscript --secure -d /dbpath -h server1.myserver.com -p 389 -t 10

Oracle Traffic Directorは、オリジン・サーバー・ポート・タイプ(LDAP over SSLなど)を自動的には実行可能ファイルに渡しません。実行可能ファイルにタイプ情報が必要な場合、コマンド文字列で追加引数としてタイプ情報を指定するか(前述の例)、またはヘルス・チェック・プログラム/スクリプトでタイプ情報をハードコード化したり他のリソースから取得したり(たとえば、それ自体の構成ファイルまたは環境変数)することができます。

さらに、外部実行可能ファイルではタイムアウト値を考慮し、タイムアウトする前に実行を終了してステータスを戻すことをお薦めします。タイムアウトが発生し実行が終了していない場合、Oracle Traffic Directorはプロセスを終了してサーバー・ステータスをオフラインに設定します。

5.7.1.3 ロギング

Oracle Traffic Directorは、環境変数OTD_LOG_LEVELを通じて外部プログラムに構成済ロギング・レベルを渡し、その環境変数の値は整数です。外部実行可能ファイルでは、ロギング・レベルに基づいてロギング・メッセージの量をカスタマイズできます。次の表は、Oracle Traffic Directorロギング・レベルと引数値の間のマッピングを定義します。

表5-3 Oracle Traffic Directorロギング・レベルおよび引数値のマッピング

値

Oracle Traffic Directorロギング・レベル

0

NOTIFICATION:1以上

1

TRACE:1

2

TRACE:16

3

TRACE:32

Oracle Traffic Directorは、内容を外部実行可能ファイルのサーバー・ログの単一ログ・エントリで標準出力および標準エラーの両方にロギングします。コマンド・ヘルス・チェック・スクリプトの終了ステータスが0の場合、メッセージはTRACE:1レベルでロギングされます。そうでない場合、標準出力がNOTIFICATION:1レベルでロギングされ、標準エラーがWARNING:1レベルでロギングされます。

6 オリジン・サーバーの管理

オリジン・サーバーは、バックエンドのサーバーであり、Oracle Traffic Directorはクライアントから受信したリクエストをこのサーバーに転送し、クライアント・リクエストに対するレスポンスをこのサーバーから受信します。たとえば、オリジン・サーバーには、Oracle WebLogic ServerインスタンスまたはOracle iPlanet Web Serverインスタンスなどが該当します。同じサービスを提供するオリジン・サーバーのグループは、オリジン・サーバー・プールと呼ばれます。

この章では、オリジン・サーバーを作成および管理する方法を説明します。ここの内容は、次のとおりです。

- プールへのオリジン・サーバーの追加

- オリジン・サーバーのリストの表示

- オリジン・サーバーの変更

- エフェメラル・ポートの管理

- プールからのオリジン・サーバーの削除

6.1 プールへのオリジン・サーバーの追加

Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバーをオリジン・サーバー・プールに追加できます。

注意:

- オリジン・サーバーをプールに追加すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの使用方法の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

始める前に

オリジン・サーバーを追加する前に、次の項目を決定します。

- オリジン・サーバーを追加するオリジン・サーバー・プール。

- オリジン・サーバーのホスト名またはIPアドレス。InfiniBandインタフェースIPアドレス(IPoIB)またはSocket Director Protocol (SDP)アドレスのIPアドレスを指定することをお薦めします。

注意:
SDPはネイティブのInfinibandプロトコルです。SDPを使用した場合のパフォーマンスは、ワークロードに大きく依存します。そのため、SDPとIPoIBを使用したときのパフォーマンスを比較評価し、要件に適したプロトコルを選択することが重要です。

- オリジン・サーバーがリクエストをリスニングするポート番号。

- このサーバーがバックアップ・オリジン・サーバーであるかどうか。
Oracle Traffic Directorは、ヘルス・チェックによりプライマリ・オリジン・サーバーのいずれも使用できないと検出された場合にのみバックアップ・オリジン・サーバーにリクエストを転送します。

- Oracle Traffic Directorがオリジン・サーバーに分散する必要があるリクエスト・ロード合計の比率。この比率は、プール内のその他のオリジン・サーバーに割り当てられている重みに対して相対的な重みの数値として定義します。
Oracle Traffic Directorでは、重みを使用することにより、プール内のオリジン・サーバーの相対的な容量に基づきリクエスト・ロードが分散されるように設定できます。

3つのオリジン・サーバー(os1、os2、os3)でプールが構成されており、それぞれ重みが1、2、2である場合を考えます。プール内のすべてのサーバーに割り当てられている重みの合計は1+2+2=5です。Oracle Traffic Directorでは、合計ロードの1/5がos1、2/5がos2とos3にそれぞれ分散されます。

Fusion Middleware Controlを使用したオリジン・サーバーのプールへの追加

Fusion Middleware Controlを使用してオリジン・サーバーをプールに追加するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. オリジン・サーバーを追加する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。その構成に定義されているサーバー・プール(HTTP/SおよびTCPサーバー・プール)のリストが表示されます。

7. オリジン・サーバーを構成するサーバー・プールを選択します。

8. 「共通タスク」ペインで、「オリジン・サーバーの構成」をクリックします。

9. 「共通タスク」ペインで、「作成」ボタンをクリックします
新しい「オリジン・サーバーの作成」ページが開きます

図6-1 新規オリジン・サーバー

10. 画面上のプロンプトに従い、前に決定済の詳細(オリジン・サーバー・プール、ホスト、ポートなど)を使用して、オリジン・サーバー・プールの作成を完了します。ページの右上隅にある「OK」ボタンをクリックします。
オリジン・サーバーが作成された後、新規オリジン・サーバー・ウィザードの「結果」画面にオリジン・サーバーの作成が成功したことを示すメッセージが表示されます。

11. 定義したオリジン・サーバーの詳細は、「オリジン・サーバー」ページに表示されます。

WLSTを使用したプールへのオリジン・サーバーの追加

プールにオリジン・サーバーを追加するには、otd_createOriginServerコマンドを実行します。

たとえば、次のコマンドは、構成fooのプールorigin-server-pool-1のオリジン・サーバーとして、ホストwww.example.comおよびポート12345を追加します。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['host'] = 'www.example.com'
props['port'] = '12345'
otd_createOriginServer(props)

otd_createOriginServerの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

6.2 オリジン・サーバーのリストの表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバーのリストを表示できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したオリジン・サーバーのリストの表示

Fusion Middleware Controlを使用してオリジン・サーバーのリストを表示するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. オリジン・サーバーを表示する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。その構成に定義されているサーバー・プール(HTTP/SおよびTCPサーバー・プール)のリストが表示されます。

7. オリジン・サーバーを表示するサーバー・プールを選択します。

8. 「共通タスク」ペインで、「オリジン・サーバーの構成」をクリックします。

9. オリジン・サーバーを表示するサーバー・プールを選択します。

名前をクリックすると、オリジン・サーバーのプロパティを表示および編集できます。

WLSTを使用したオリジン・サーバー・リストの表示

プールに定義されているオリジン・サーバー・リストを表示するには、次の例に示すように、otd_listOriginServersコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
otd_listOriginServers(props)

otd_getOriginServerPropertiesコマンドを実行することで、オリジン・サーバーのプロパティの詳細を表示できます。

otd_listOriginServersおよびotd_getOriginServerPropertiesの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

6.3 オリジン・サーバーの変更

この項では、次の方法について説明します。

- オリジン・サーバーの作成時に定義したプロパティ(ホスト、ポート、重みなど)の変更。プロパティの詳細は、始める前にの項を参照してください。

- オリジン・サーバーの有効化または無効化。

- オリジン・サーバーが同時に処理することができる、最大接続数の指定。

- Oracle Traffic Directorがオリジン・サーバーへのリクエスト送信レートを上げていく時間(ランプアップ時間)の指定。このパラメータを使用して、オフライン後起動したばかりのオリジン・サーバーで、リクエスト・ロードをサーバーの容量まで徐々に上げることができます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバーのプロパティを変更できます。

注意:

- プール内のオリジン・サーバーのプロパティを変更すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したオリジン・サーバーのプロパティの変更

Fusion Middleware Controlを使用してオリジン・サーバーのプロパティを変更するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. オリジン・サーバーを変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。その構成に定義されているサーバー・プール(HTTP/SおよびTCPサーバー・プール)のリストが表示されます。

7. オリジン・サーバーを変更するサーバー・プールを選択します。

8. 「共通タスク」ペインで、「オリジン・サーバーの構成」をクリックします。

9. オリジン・サーバーを変更するサーバー・プールを選択します。

10. 変更するオリジン・サーバーの名前をクリックします。
「オリジン・サーバーの編集」ダイアログ・ボックスが表示されます。このダイアログ・ボックスでは、次の処理が可能です。

- 一般設定:

- オリジン・サーバーの有効化および無効化

- ホストおよびポートの変更

- バックアップ・サーバーとしてのオリジン・サーバーのマーク付け

- 詳細設定:

- 相対的な重みの変更

- オリジン・サーバーが同時に処理することができる、最大接続数の設定。

- Oracle Traffic Directorがリクエスト転送レートをオリジン・サーバーの最大容量までランプアップするまでに要する時間の指定。

11. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。

12. 必要な変更を行った後、「OK」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したオリジン・サーバーのプロパティの変更

オリジン・サーバーのプロパティを変更するには、otd_setOriginServerPropertiesコマンドを実行します。

たとえば、次のコマンドは、構成fooのプールorigin-server-pool-1内のオリジン・サーバーwww.example.comのランプアップ時間を1200に変更します。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['host'] = 'www.example.com'
props['port'] = '12345'
props['ramp-up-time'] = '1200'
otd_setOriginServerProperties(props)

otd_setOriginServerPropertiesコマンドを使用して変更できるプロパティのリストは、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

6.4 エフェメラル・ポートの管理

OTDおよびOracle WebLogic Server (WLS)のクライアントを含むトポロジでは、OTDは構成済HTTPリスナー・ポートで外部リクエストを受け取ります。次に、OTDは別の接続を開き、WLS/オリジン・サーバーに対してリクエストを送信し、プロキシします。

この接続の一部として、OTDはWLS/オリジン・サーバーがOTDにデータを送信して戻せるようにエフェメラル・ポートを活用します。エフェメラル・ポートは、IPソフトウェアの事前定義済範囲から自動的に割り当てられるインターネット・プロトコル(IP)通信の存続期間の短いトランスポート・プロトコル・ポートです。Linuxでは、エフェメラル・ポートを制限および規制することができます。

注意:
OTDは、十分なエフェメラル・ポートが使用可能であるかに依存するため、WLS/オリジン・サーバーと接続を確立したプールを十分に持つことができます。十分なエフェメラル・ポートがない場合、リクエストの処理で遅延が発生します。

6.5 プールからのオリジン・サーバーの削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、プールからオリジン・サーバーを削除できます。

注意:

- 動的検出が有効なとき(5.5項「Oracle WebLogic Serverクラスタのオリジン・サーバー・プールとしての構成」を参照)、クラスタ内のOracle WebLogic Serverインスタンスであるオリジン・サーバーを削除してOracle Traffic Directorインスタンスを再構成すると、プール内に有効なオリジン・サーバーが残っていない場合にインスタンスが起動しないことがあります。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したプールからのオリジン・サーバーの削除

Fusion Middleware Controlを使用してプールからオリジン・サーバーを削除するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. オリジン・サーバーを削除する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。その構成に定義されているサーバー・プール(HTTP/SおよびTCPサーバー・プール)のリストが表示されます。

7. オリジン・サーバーを削除するサーバー・プールを選択します。

8. 「共通タスク」ペインで、「オリジン・サーバーの構成」をクリックします。

9. 削除するオリジン・サーバーの名前をクリックします。

10. 削除するオリジン・サーバーの「削除」アイコンをクリックします。
確認を求めるウィンドウでOKをクリックします。
オリジン・サーバーが削除されたことを確認するメッセージが表示されます。

WLSTを使用したプールからのオリジン・サーバーの削除

プールから特定のホストおよびポートのオリジン・サーバーを削除するには、次の例に示すように、otd_deleteOriginServerコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['host'] = 'www.example.com'
props['port'] = '12345'
otd_deleteOriginServer(props)

otd_deleteOriginServerの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

7 仮想サーバーの管理

単一のOracle Traffic Directorインスタンス内の複数の仮想サーバーを使用して、クライアントのリクエストに対して、いくつかのエントリ・ポイント(ドメイン名およびIPアドレス)を提供し、キャッシュ、サービス品質などに差別化されたサービスを提供できます。仮想サーバーを1つ以上のリスナー(HTTPまたはHTTPS)にバインドし、リクエストを様々なオリジン・サーバー・プールに転送できます。

各仮想サーバーに対して、キャッシュ、圧縮、ルーティング、サービス品質、ログ・ファイルおよびWebアプリケーション・ファイアウォール設定を個別に設定できます。

この章では、仮想サーバーを作成、表示、変更および削除する方法、およびキャッシュを構成する方法を説明します。内容は次のとおりです。

- 仮想サーバーの作成

- 仮想サーバーのリストの表示

- 仮想サーバーの変更

- ルートの構成

- 仮想サーバーのコピー

- 仮想サーバーの削除

- Oracle Traffic Directorにおけるキャッシュ

- インスタンスのキャッシュ設定およびメトリックの確認

- チューニング可能なキャッシュ・パラメータ

- キャッシュ・パラメータの構成

- コンテンツの提供

7.1 仮想サーバーの作成

構成の作成時、仮想サーバーは、構成と同じ名前で自動的に作成され、構成の作成時に指定されたHTTPリスナーに関連付けられます。仮想サーバーに対してデフォルトのルーティング・ルールも作成され、関連付けられたHTTPリスナーで受信したすべてのリクエストが、構成の作成時に指定されたオリジン・サーバーに分散されます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成内に追加の仮想サーバーを作成できます。

注意:

- 仮想サーバーを作成すると、実質的には構成が変更されます。新規仮想サーバーをOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの使用方法の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

始める前に

仮想サーバーの作成を開始する前に、次の項目を決定します。

- 仮想サーバーの一意の名前。仮想サーバーを作成した後名前は変更できないため、名前は慎重に選択してください。

- 1つ以上の一意のリスニング・ポート。リスナーの作成の詳細は、第9章「リスナーの管理」を参照してください。

- 仮想サーバーがリクエストを処理するために必要なホストまたはホスト・パターンの名前。
リクエストを受信すると、Oracle Traffic Directorは、リクエストのHostヘッダーを、構成内の各仮想サーバーに定義されたホスト・パターンと比較して、リクエストを処理する仮想サーバーを決定します。

- リクエストは、リクエスト内のHostヘッダーと一致するホスト・パターンを持つ最初の仮想サーバーにルーティングされます。

- リクエストのHostヘッダーが、各仮想サーバーに定義されているホスト・パターンのいずれとも一致しない、またはリクエストにHostヘッダーが含まれていない場合、リクエストは、リクエストの受信に使用されたHTTPリスナーに関連付けられたデフォルトの仮想サーバーにルーティングされます。

注意:
「厳密なSNIホスト一致」がHTTPリスナーに対して有効化されていて、そのリスナーに対し、仮想サーバーの少なくとも1つに証明書がある場合、次の条件のいずれかが真であれば、Oracle Traffic Directorにより403-Forbiddenエラーがクライアントに返されます。

- SSL/TLSハンドシェイク中、クライアントからSNIホスト拡張が送信されませんでした。

- リクエストに、Host:ヘッダーがありません。

- SSL/TLSハンドシェイク中にSNIホスト拡張でクライアントから送信されたホスト名が、リクエスト内のHost:ヘッダーと一致しません。

詳細は、10.1.6項「厳密なSNIホスト一致について」を参照してください。

- 仮想サーバーがリクエストを転送するオリジン・サーバー・プールの名前。オリジン・サーバー・プールの作成の詳細は、第5章「オリジン・サーバー・プールの管理」を参照してください。

Fusion Middleware Controlを使用した仮想サーバーの作成

Fusion Middleware Controlを使用して仮想サーバーを作成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 仮想サーバーを作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。

7. 「共通タスク」ペインで、「作成」をクリックします。
新規仮想サーバー・ウィザードが開始されます。

図7-1 新規仮想サーバー・ウィザード

8. 画面上のプロンプトに従い、前に決定済の詳細(リスナー、オリジン・サーバー・プールなど)を使用して、仮想サーバーの作成を完了します。
仮想サーバーが作成された後、新規仮想サーバー・ウィザードの「結果」画面に仮想サーバーの作成が成功したことを示すメッセージが表示されます。

9. 「結果」画面で、「仮想サーバーの作成」をクリックします。

- 作成した仮想サーバーの詳細は、「仮想サーバー」ページに表示されます。

WLSTを使用した仮想サーバーの作成

仮想サーバーを作成するには、otd_createVirtualServerコマンドを実行します。

たとえば、次のコマンドでは、構成fooにbarという名前の仮想サーバーが作成され、オリジン・サーバー・プールorigin-server-pool-1にクライアントのリクエストを転送する仮想サーバーが構成されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['origin-server-pool'] = 'origin-server-pool-1'
otd_createVirtualServer(props)

otd_createVirtualServerの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

7.2 仮想サーバーのリストの表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、仮想サーバーのリストを表示できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した仮想サーバーのリストの表示

Fusion Middleware Controlを使用して仮想サーバーのリストを表示するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 仮想サーバーを表示する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

名前をクリックすると、仮想サーバーのプロパティを表示できます。

WLSTを使用した仮想サーバーのリストの表示

仮想サーバーのリストを表示するには、次の例に示すように、otd_listVirtualServersコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_listVirtualServers(props)

otd_getVirtualServerPropertiesコマンドを実行することで、仮想サーバーのプロパティの詳細を表示できます。

otd_listVirtualServersおよびotd_getVirtualServerPropertiesコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

7.3 仮想サーバーの変更

Fusion Middleware ControlまたはWLSTのいずれかを使用して、仮想サーバーを変更できます。

注意:

- 仮想サーバーを変更すると、実質的には構成が変更されます。新規仮想サーバー設定をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した仮想サーバーの変更

Fusion Middleware Controlを使用して仮想サーバーを変更するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 仮想サーバーを変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

7. 変更する仮想サーバーを選択して、「共通タスク」ペインの「編集」ボタンをクリックします。
「仮想サーバー設定」ページが表示されます。このページで、次の処理が可能です。

- 仮想サーバーの有効化および無効化。

- 仮想サーバーによって提供されるホスト・パターンの追加、削除および変更。Oracle Traffic Directorによるホスト・パターンの使用の詳細は、始める前にの項を参照してください。

- HTTPリスナーの追加および削除。HTTPリスナーの作成の詳細は、9.1項「リスナーの作成」を参照してください。

- RSAまたはECC証明書を仮想サーバーに関連付けることによる、SSL/TLSの有効化。詳細は、10.1.3項「仮想サーバーと証明書の関連付け」を参照してください。

- インスタンス・レベルの統計情報を、ユーザーがブラウザからアクセス可能なXMLおよびプレーンテキスト・レポートの形式で提供するように仮想サーバーを構成。XMLおよびプレーンテキスト・レポートに表示される統計情報は、各仮想サーバーに固有のものではなく、Oracle Traffic Directorインスタンス全体に対するものであることに注意してください。詳細は、12.3項「統計レポートへのURIアクセスの構成」を参照してください。

- メッセージのデフォルト言語は英語です。必要であれば、Oracle Traffic Directorでサポートされている他の言語に設定できます。

- 様々なエラー・コードごとに仮想サーバーがクライアントに返すエラー・ページの指定。これが必要になるのは、デフォルトのエラー・メッセージを使用するのではなく、カスタマイズして使用する必要がある場合のみです。
使用するエラー・コードとエラー・ページを指定するには、特定のエラー・コードに対して表示するHTMLページを作成し、これを管理サーバーからアクセスできるディレクトリに保存します。次に、「仮想サーバー設定」ページの「エラー・ページ」セクションで、「新規エラー・ページ」をクリックします。

「新規エラー・ページ」ダイアログ・ボックスが表示されたら、エラー・コードを選択し、そのエラー・コードに使用するエラー・ページへの完全パスを入力します。提示されるエラー・コードだけでなく、「カスタム・エラー・コード」をクリックして値を入力し、カスタム・エラー・コードを作成できます。この作業が完了したら、「エラー・ページの作成」をクリックします。

- サービス品質の制限(仮想サーバーからクライアントへの最高データ送信速度および仮想サーバーがサポートできる最大同時接続数)の有効化。

ナビゲーション・ペインの「仮想サーバー」ノードで、次のような、仮想サーバー設定の追加カテゴリを選択できます。選択したカテゴリに関連するパラメータが、メインのペインに表示されます。

- 設定: リクエストをオリジン・サーバーにルーティングするルールを作成、変更および削除します。詳細は、7.4項「ルートの構成」を参照してください。

- ルート: リクエストをオリジン・サーバーにルーティングするルールを作成、変更および削除します。詳細は、7.4項「ルートの構成」を参照してください。

- キャッシュ: オリジン・サーバーから受信したレスポンスをキャッシュするためのルールを作成、変更および削除します。詳細は、7.10項「キャッシュ・パラメータの構成」を参照してください。

- 圧縮: オリジン・サーバーからのレスポンスをクライアントに送信する前に、それらのレスポンスを圧縮するルールを作成、変更および削除します。詳細は、15.10項「コンテンツ圧縮の有効化と構成」を参照してください。

- リクエスト制限: 仮想サーバーが受信したリクエストの数およびレートを制限するルールを作成、変更および削除します。詳細は、10.7項「サービス拒否攻撃の回避」を参照してください。

- 帯域幅の制限: 仮想サーバーが受信したリクエストの数およびレートを制限するルールを有効化、変更および削除します。詳細は、10.7項「サービス拒否攻撃の回避」を参照してください。

- コンテンツの提供: オリジン・サーバーに対する静的コンテンツの提供ルールを作成、変更および削除します。

- Webappファイアウォール: Webアプリケーション・ファイアウォールのルール・セットを有効化または無効化し、ルール・セット・パターンを指定してルール・セット・ファイルをインストールします。詳細は、10.5項「Webアプリケーション・ファイアウォールの管理」を参照してください。

- ロギング: 仮想サーバーに固有のサーバー・ログ・ファイルおよび場所を定義します。詳細は、11.3項「ログ・プリファレンスの構成」を参照してください。

8. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

9. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用した仮想サーバーの変更

WLSTでは、仮想サーバーの特定のパラメータの変更に使用できるいくつかのコマンド(表7-1を参照)が用意されています。

表7-1 仮想サーバー変更用のWLSTコマンド

タスク

CLIコマンド

仮想サーバーの有効化または無効化、ホスト、HTTPリスナー、ログ・ファイルの名前および場所の変更、RSAまたはECC証明書(あるいはその両方)を関連付けることによるSSL/TLSの有効化(10.1.3項「仮想サーバーと証明書の関連付け」および11.3項「ログ・プリファレンスの構成」も参照)

otd_setVirtualServerProperties

ルートの作成および管理(7.4項「ルートの構成」を参照)

otd_createRoute

otd_listRoutes

otd_deleteRoute

otd_setRouteProperties

otd_getRouteProperties

キャッシュ・ルールの作成および管理(7.7項「Oracle Traffic Directorにおけるキャッシュ」を参照)

otd_createCacheRule

otd_listCacheRules

otd_deleteCacheRule

otd_getCacheRuleProperties

otd_setCacheRuleProperties

圧縮ルールの作成および管理(15.10項「コンテンツ圧縮の有効化と構成」を参照)。

otd_createCompressionRule

otd_setCompressionRuleProperties

otd_deleteCompressionRule

otd_listCompressionRules

otd_getCompressionRuleProperties

リクエスト制限設定の変更(10.7項「サービス拒否攻撃の回避」を参照)

otd_createRequestLimit

otd_deleteRequestLimit

otd_getRequestLimitProperties

otd_listRequestLimits

otd_setRequestLimitProperties

コンテンツ・ルールの作成および管理(7.11項「コンテンツの提供」を参照)

otd_createContentRule

otd_deleteContentRule

otd_listContentRules

otd_setContentRuleProperties

otd_getContentRuleProperties

エラー・ページの作成および管理

otd_createErrorPage

otd_deleteErrorPage

otd_listErrorPages

たとえば、次のコマンドでは、仮想サーバーbarと関連付けられているHTTPリスナーの名前がhttp-listener-1に変更されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['http-listener-name'] = 'http-listener-1'
otd_setVirtualServerProperties(props)

WLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

7.4 ルートの構成

構成の作成時、仮想サーバーは、構成の作成時に指定されたリスナーで自動的に作成されます。自動的に作成された仮想サーバーの他、後で構成に追加された仮想サーバーについても、デフォルトのルートが作成されます。デフォルト・ルートのルールでは、仮想サーバーへのすべてのリクエストを、仮想サーバーの作成時に指定したオリジン・サーバー・プールにルーティングするように指定されます。仮想サーバーのデフォルト・ルートは削除できませんが、そのプロパティを変更することはできます。

指定した条件を満たすリクエストを、特定のオリジン・サーバー・プールにルーティングするように、仮想サーバーに追加のルートを作成できます。たとえば、銀行業のソフトウェア・ソリューションで、ローンおよび預金の顧客取引が別々のアプリケーションによって処理される場合、これらの各アプリケーションを、Oracle Traffic Directorインスタンスの背後にある別々のオリジン・サーバー・プールでホストできます。顧客のリクエストがローンまたは預金のいずれのアプリケーションに関連するかに応じて、リクエストを適切なオリジン・サーバー・プールにルーティングするために、次のように2つのルートを設定できます。

- ルート1: リクエストURIが/loanで始まる場合、ローン・アプリケーションをホストするオリジン・サーバー・プールにリクエストを送信します。

- ルート2: リクエストURIが/depositで始まる場合、預金アプリケーションをホストするオリジン・サーバー・プールにリクエストを送信します。

複数のルートで構成されている仮想サーバーがリクエストを受信すると、使用可能な各ルートに対してリクエストのURIをチェックします。ルートは、作成された順にチェックされます。

- リクエストがルートの条件を満たす場合、Oracle Traffic Directorはそのルートに指定されたオリジン・サーバー・プールにリクエストを送信します。

- リクエストが、定義されたいずれのルートの条件とも一致しない場合、Oracle Traffic Directorは、デフォルト・ルートで指定されているオリジン・サーバー・プールにリクエストを送信します。

WebSocketアップグレードはデフォルトで有効です。Fusion Middleware Controlで、「WebSocketアップグレード」チェック・ボックスを使用して、ルートのWebSocketプロトコルを有効または無効にします。同様に、WebSocketプロトコルはwebsocket-upgrade-enabledプロパティでも有効または無効にできます。これは、otd_setRoutePropertiesというWLSTコマンドで設定できます。詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、仮想サーバー内のルートを構成できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したルートの構成

Fusion Middleware Controlを使用してルートを構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. ルートを構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。

7. ナビゲーション・ペインで、「仮想サーバー」を展開し、ルートを構成する仮想サーバーの名前を展開して、「ルート」を選択します。
「ルート」ページが表示されます。仮想サーバーに現在定義されているルートがリストされます。

8. ルートの作成

1. 「作成」をクリックします。
「新規ルート」ダイアログ・ボックスが表示されます。

「名前」フィールドで、新規ルートの名前を入力します。

「オリジン・サーバー・プール」フィールドで、指定された条件を満たすリクエストがルーティングされるオリジン・サーバー・プールを選択します。

2. 「条件情報」ペインで「変数/関数」を選択し、各ドロップダウン・リストから演算子を選択し、「値」フィールドに値を入力します。
複数の式を構成する場合は、ドロップダウン・リストでand/or演算子を選択します。同様に、指定した式が偽に評価されるときにルートを適用する場合は、Not演算子を使用します。

「OK」をクリックします。

条件を手動入力するには、「取消」をクリックし、「式の編集」をクリックし、開かれる新しいウィンドウで「手動編集」をクリックします。「条件」フィールドで、ルーティング・ルールが適用される条件を指定します。条件式の作成の詳細は、「条件」フィールドの近くにあるヘルプ・ボタンをクリックするか、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式、ワイルドカードおよび文字列の補間の使用に関する項を参照してください。

3. 「OK」をクリックします。
作成したルートが「ルート」ページに表示されます。

ルートの編集

ルートの設定を変更するには、次の操作を行います。

1. 「名前」をクリックして、ルートの「編集」ボタンを選択します。
ルート設定ページが表示されます。

2. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。

「取消」ボタンをクリックすることで、いつでも変更を破棄できます。

3. 必要な変更を行った後、「OK」をクリックします。
更新された設定が保存されます。

ルーティング・ルールの削除

ルーティング・ルールを削除するには、「削除」ボタンをクリックします。確認プロンプトで、「OK」です。

WLSTを使用したルートの構成

- ルートを作成するには、otd_createRouteコマンドを実行します。
例:

- 次のコマンドでは、構成fooの仮想サーバーbarにloan-routeという名前のルートが作成され、このルートでは、パターン/loanに一致するURIを持つリクエストがオリジン・サーバー・プールloan-appに送信されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'loan-route'
props['origin-server-pool'] = 'loan-app'
props['condition'] = "headers{'content-length'} < 400"
otd_createRoute(props)

- 次のコマンドでは、構成fooの仮想サーバーbarにimages-routeという名前のルートが作成され、このルートでは、パターン/imagesに一致するURIパスを持つリクエストがオリジン・サーバー・プールimages-repoに送信されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'images-route'
props['origin-server-pool'] = 'images-repo'
props['condition'] = '$path='/images/*''
otd_createRoute(props)

- 次のコマンドでは、構成fooの仮想サーバーbarにsubnet-routeという名前のルートが作成され、このルートでは、サブネット130.35.46.*のクライアントからのリクエストがオリジン・サーバー・プールdedicated-ospに送信されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'subnet-route'
props['origin-server-pool'] = 'dedicated-osp'
props['condition'] = '$ip='130.35.46.*''
otd_createRoute(props)

- 次のコマンドでは、構成fooの仮想サーバーbarにbody-routeという名前のルートが作成され、このルートでは、本文にalphaという言葉が含まれているリクエストがオリジン・サーバー・プールdedicated-ospにルーティングされます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'body-route'
props['origin-server-pool'] = 'dedicated-osp'
props['condition'] = '$body ='alpha''
otd_createRoute(props)

conditionプロパティの値は、正規表現にする必要があることに注意してください。条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』 の変数、式および文字列の補間の使用に関する項を参照してください。

- 仮想サーバーに定義されているルートのリストを表示するには、次の例に示すように、otd_listRoutesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listRoutes(props)

- ルートのプロパティを表示するには、次の例に従い、otd_getRoutePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'loan-route'
otd_getRouteProperties(props)

keep-alive-timeout=15
sticky-cookie=JSESSIONID
condition="$uri = '/loan'"
validate-server-cert=true
always-use-keep-alive=false
origin-server-pool=origin-server-pool-1
sticky-param=jsessionid
route-header=Proxy-jroute
rewrite-headers=location,content-location
use-keep-alive=true
route=loan-route
log-headers=false
route-cookie=JROUTE
timeout=300

- ルートのプロパティを変更するには、otd_setRoutePropertiesコマンドを実行します。
例:

- たとえば、次のコマンドでは、構成fooの仮想サーバーbar内のroute-1という名前のルートに対するWebSocketアイドル・タイムアウトの設定が1200秒に変更されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
props['websocket-idle-timeout'] = '1200'
otd_setRouteProperties(props)

- 次のコマンドでは、構成fooの仮想サーバーbar内のdefault-routeという名前のルートと関連付けられているオリジン・サーバーとの間でOracle Traffic Directorが送受信するヘッダーのロギングが有効になります。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'default-route'
props['log-headers'] = 'true'
otd_setRouteProperties(props)

- WebSocketサポートを無効にするには、次の例に示すように、otd_setRoutePropertiesコマンドをwebsocket-upgrade-enabledプロパティを指定して実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'default-route'
props['websocket-upgrade-enabled'] = 'false'
otd_setRouteProperties(props)

- ルートを削除するには、次の例に示すように、otd_deleteRouteコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
otd_deleteRoute(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

7.5 仮想サーバーのコピー

Fusion Middleware ControlまたはWLSTのいずれかを使用して、仮想サーバーをコピーできます。

注意:

- 仮想サーバーをコピーすると、実質的には構成が変更されます。新規仮想サーバーをOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した仮想サーバーのコピー

Fusion Middleware Controlを使用して仮想サーバーをコピーするには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 仮想サーバーをコピーする構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

7. コピーするオリジン・サーバーの「複製」アイコンをクリックします。
「仮想サーバーの複製」ダイアログ・ボックスが表示されます。

8. 新しい仮想サーバーの名前を入力し、「OK」をクリックします。
新しい仮想サーバーが作成されたことを確認するメッセージが表示されます。

WLSTを使用した仮想サーバーのコピー

仮想サーバーをコピーするには、otd_copyVirtualServerコマンドを実行します。

たとえば、次のコマンドでは、仮想サーバーbarのコピー(baz)が作成されます。

props = {}
props['configuration'] = 'foo'
props['source-virtual-server'] = 'bar'
props['dest-virtual-server'] = 'baz'
otd_copyVirtualServer(props)

otd_copyVirtualServerの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

7.6 仮想サーバーの削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、仮想サーバーを削除できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した仮想サーバーの削除

Fusion Middleware Controlを使用して仮想サーバーを削除するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 仮想サーバーを削除する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

7. 削除する仮想サーバーの「削除」アイコンをクリックします。
削除を確認するプロンプトが表示されます。

8. 「OK」をクリックします。
「コンソール・メッセージ」ペインに、仮想サーバーが削除されたことを確認するメッセージが表示されます。

WLSTを使用した仮想サーバーの削除

仮想サーバーを削除するには、次の例に示すように、otd_deleteVirtualServerコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_deleteVirtualServer(props)

otd_deleteVirtualServerの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

7.7 Oracle Traffic Directorにおけるキャッシュ

頻繁にリクエストされるデータをキャッシュすることで、クライアントがレスポンスを待機する時間が削減されます。また、頻繁にアクセスされるオブジェクト(レスポンス本文およびヘッダー)がメモリー内に格納されると、オリジン・サーバーの負荷が大幅に低減されます。

キャッシュを有効にするには、キャッシュ・ルールを構成する必要があります。

- オリジン・サーバーから静的および動的に生成されたコンテンツの両方がキャッシュされます。

- 成功したレスポンス(レスポンス・コード: 200)のみがキャッシュされます。

- HTTP GETおよびHEADリクエストへのレスポンスのみがキャッシュされます。

- Oracle Traffic Directorは、レスポンスの本文、およびDest-IP、Proxy-Agent、Proxy-Connection、Server、Set-Cookie、State-InfoおよびStatusを除くすべてのレスポンス・ヘッダーをキャッシュします。

- Oracle Traffic Directorは、コンテンツを再検証するディレクティブ、特定のヘッダーをキャッシュしないディレクティブなど、オリジン・サーバーからのCache-Controlディレクティブに従います。

- 各仮想サーバーに固有の1つ以上のキャッシュ・ルールを構成できます。これらのルールは、最大ヒープ領域、最大入力数および最大オブジェクト・サイズなど、構成に指定された全体の制限に影響を受けます。
キャッシュ・ルールは、すべてのリクエストに適用するようにも、指定された条件に一致するリクエストのみに適用するようにも構成できます。

- キャッシュされたデータは、仮想サーバーごとに別々にプロセス・メモリー(ヒープ)内に保持されます。インスタンスが停止または再起動されると、キャッシュは空になります。

- WebSocketアップグレード・リクエストはキャッシュされません。

クライアントが最初にオブジェクトをリクエストすると、Oracle Traffic Directorはリクエストをオリジン・サーバーに送信します。このリクエストはキャッシュ・ミスになります。リクエストされたオブジェクトがキャッシュ・ルールに一致する場合、Oracle Traffic Directorオブジェクトをキャッシュします。同じオブジェクトの後続のリクエストについて、Oracle Traffic Directorはそのキャッシュのオブジェクトをクライアントに提供します。このようなリクエストは、キャッシュ・ヒットとなります。

Oracle Traffic Directorのキャッシュの動作は、RFC 2616の13項の仕様と整合性が取れています。詳細は、http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.htmlを参照してください。

7.8 インスタンスのキャッシュ設定およびメトリックの確認

キャッシュ設定の表示

- 構成の現在のキャッシュ設定を表示するには、次の例に示すように、otd_getCachePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getCacheProperties(props)

enabled=true
max-entries=1024
replacement=lru
max-heap-object-size=524288
max-heap-size=10485760

- 仮想サーバーに定義されているキャッシュ・ルールのリストを表示するには、次の例に示すように、otd_listCacheRulesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listCacheRules(props)

cache-rule-1
cache-rule-2

- 仮想サーバー固有のキャッシュ・ルールの現在の設定を表示するには、次の例に示すように、otd_getCacheRulePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['cache-rule'] = 'cache-rule-1'
otd_getCacheRuleProperties(props)

condition="$uri = '^/images"
enabled=true
max-reload-interval=3600
min-reload-time=0
last-modified-factor=0
min-object-size=1
cache-https-response=true
rule=cache-rule-2
query-maxlen=0
compression=true
cache-http-response=false

キャッシュ・メトリックの表示

プレーンテキストperfdumpレポートで、現在のキャッシュ・ヒット率、キャッシュ・ヒープ使用量、およびキャッシュ・エントリの再検証成功率を、次の例に示すように表示できます。

Proxy Cache:
---------------------------
Proxy Cache Enabled              yes
Object Cache Entries             42
Cache lookup (hits/misses)       183/79
Requests served from Cache       22
Revalidation (successful/total)  30/38 (  78.95%)
Heap space used                  16495

- Proxy Cache Enabledは、インスタンスに対してキャッシュが有効であるかどうかを示します。

- Object Cache Entriesは、キャッシュ内に現在存在するエントリ(URI)の数です。

- Cache lookup (hits/misses)

- 最初の数値は、リクエストされたURIに対してキャッシュ内でエントリが見つかった回数です。

- 2番目の数値は、リクエストされたURIがキャッシュ内で見つからなかった回数です。

- Requests served from Cacheは、Oracle Traffic Directorがキャッシュから提供したリクエストの数です。

- Revalidation (successful/total)

- 最初の番号は、キャッシュされたコンテンツの再検証が成功した回数です。

- 2番目の数値は、Oracle Traffic Directorが、キャッシュされたコンテンツの再検証を試みた合計回数です。

- パーセント値は、再検証試行合計回数に対する再検証成功回数の割合です。

- Heap space usedは、現在使用中のキャッシュ・ヒープ領域の量です。

7.9 チューニング可能なキャッシュ・パラメータ

キャッシュは、キャッシュ・ヒット率が高い場合、つまり比較的大量のリクエストがオリジン・サーバーに送信されるのではなく、キャッシュから提供される場合、クライアントへのレスポンス時間を短くできるという点で有効と考えられます。キャッシュ・ヒット率を高くするには、オリジン・サーバーからのキャッシュ可能なレスポンスを格納するために十分なメモリーが必要であり、キャッシュ内のエントリを定期的に検証する必要があります。

注意:
動的なコンテンツは一般的にキャッシュできません。このため、オリジン・サーバーによって提供されるアプリケーションまたはコンテンツが、ほとんど動的コンテンツで構成されている場合、キャッシュ・ヒット率は低くなる傾向があります。この場合、キャッシュを有効化してチューニングしても、パフォーマンスは大幅に向上しない可能性があります。

キャッシュ・ヒット率を向上させるために、次のキャッシュ・パラメータをチューニングできます。

- キャッシュ・エントリ置換メソッド
キャッシュが一杯になると、つまりエントリ数が最大エントリ制限に到達する、またはキャッシュ・ヒープ・サイズが最大キャッシュ・ヒープ領域に到達すると、その後のキャッシュ・エントリは、既存のエントリが削除された場合のみ格納できます。キャッシュ・エントリの置換メソッドは、Oracle Traffic Directorにおいてキャッシュから削除できるエントリを決定する方法を指定します。

- デフォルトの置換メソッドは、「最近最も使用されていない」(lru)メソッドです。キャッシュが一杯になると、Oracle Traffic Directorは、最近最も使用されていないエントリを最初に破棄します。

- もう1つのメソッドは、「最も使用頻度が低い」(lfu)メソッドです。キャッシュが一杯になると、Oracle Traffic Directorは、最も使用頻度が低いエントリを最初に破棄します。

いずれのメソッドでも、Oracle Traffic Directorがキャッシュからコンテンツを提供するごとに、使用状況の情報(lru置換メソッドの場合コンテンツが提供された時間、lfu置換メソッドの場合コンテンツが提供された回数)を追跡する必要があります。このため、オリジン・サーバーにリクエストを送信するのではなく、キャッシュから直接コンテンツを提供することで短縮できる時間は、使用状況の情報を追跡するために必要な待機時間によってある程度は相殺されます。2つのメソッドでは、lruの方が必要な演算リソースがわずかに少なくなります。

置換メソッドとしてfalseを指定することで、キャッシュ・エントリの置換を無効化できます。

- 最大キャッシュ・ヒープ領域
使用可能なヒープ領域のうち少量しか使用されていない場合、仮想サーバー固有のキャッシュ・ルールの定義が絞り込まれすぎているため、レスポンスがキャッシュされていない可能性があります。

最適なキャッシュ・ヒープ・サイズは、システム・メモリーにどれほどの空きがあるかによって異なります。キャッシュ・ヒープが大きい場合、Oracle Traffic Directorはより多くのコンテンツをキャッシュできるため、ヒット率はより高くなります。ただし、キャッシュされたコンテンツのページングがオペレーティング・システムによって開始されるため、ヒープ・サイズは大きくしすぎないでください。

- キャッシュ内のエントリの最大数
キャッシュ内のエントリ数が、perfdumpレポートに示されるように、一貫して最大エントリ数に近いまたは同数である場合、キャッシュのサイズが十分ではないことを意味します。最大エントリ数を増やすことを検討してください。

キャッシュ内のエントリ数が、許可されている最大エントリ数と比較して非常に少ない場合、仮想サーバー固有のキャッシュ・ルールの定義が絞り込まれすぎているため、レスポンスがキャッシュされていない可能性があります。

- キャッシュ可能なオブジェクトの最大サイズ
システム・リソースを一定に保つために、オブジェクトが別のキャッシュ・ルールを満たしていても、キャッシュするオブジェクトのサイズを制限することができます。

キャッシュ・オブジェクトの最大サイズより大きいオブジェクトが頻繁にリクエストされる場合は、制限サイズを大きくすることを検討してください。

特定の仮想サーバーのキャッシュ・ルールでは、次のパラメータを指定できます。

- キャッシュ可能なオブジェクトの最小サイズおよび最大サイズ

- キャッシュ検証チェック間の最小間隔および最大間隔

- キャッシュできる問合せ文字列内の最大文字数

- キャッシュする前にコンテンツを圧縮するかどうか

- HTTPSレスポンスをキャッシュするかどうか

7.10 キャッシュ・パラメータの構成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、キャッシュ設定をチューニングできます。

Fusion Middleware Controlを使用したキャッシュ設定の構成

Fusion Middleware Controlを使用してキャッシュ設定を構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。

7. ナビゲーション・ペインで、「仮想サーバー」を展開し、キャッシュを構成する仮想サーバーの名前を展開して、「キャッシュ」を選択します。
「キャッシュ・ルール」ページが表示されます。仮想サーバーに現在定義されているキャッシュ・ルールがリストされます。

8. ナビゲーション・ペインで、「詳細設定」を選択します。
「詳細設定」ページが表示されます。

9. 変更するキャッシュ・パラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。

「取消」ボタンをクリックすることで、いつでも変更を破棄できます。

10. 必要な変更を行った後、「OK」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

Fusion Middleware Controlを使用した仮想サーバー固有のキャッシュ・ルールの構成

Fusion Middleware Controlを使用して仮想サーバー固有のキャッシュ・ルールを作成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 仮想サーバー固有のキャッシュ・ルールを作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。

7. ナビゲーション・ペインで、「仮想サーバー」を展開し、キャッシュ・ルールを作成する仮想サーバーの名前を展開して、「キャッシュ」を選択します。
「キャッシュ」ページが表示されます。仮想サーバーに現在定義されているキャッシュ・ルールがリストされ、そのキャッシュ・ルールが有効化されているかどうかが示されます。

キャッシュ・ルールの作成

1. 「新規キャッシュ・ルール」をクリックします。
「新規キャッシュ・ルール」ダイアログ・ボックスが表示されます。

「名前」フィールドで、新規キャッシュ・ルールの名前を入力します。

2. 「OK」をクリックします。
作成したキャッシュ・ルールが「キャッシュ」ページに表示されます。

キャッシュ・ルールの編集

キャッシュ・ルールを有効化または無効化する、あるいはルールの設定を変更するには、次の操作を行います。

1. 編集するキャッシュ・ルールの「名前」をクリックします。
「キャッシュ・ルールの編集」ダイアログ・ボックスが表示されます。

注意:
条件ビルダーにアクセスして条件を編集するには、「条件を満たすリクエスト」を選択し、「編集」をクリックします。条件ビルダーでは古い式を削除したり、新しい式を作成したりできます。

2. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

条件式の作成の詳細は、「条件」フィールドの近くにあるヘルプ・ボタンをクリックするか、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

3. 必要な変更を行った後、「保存」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

キャッシュ・ルールの削除

キャッシュ・ルールを削除するには、「削除」ボタンをクリックします。確認プロンプトで、「OK」です。

WLSTを使用したキャッシュ設定の構成

- 構成のキャッシュ・プロパティを変更するには、otd_setCachePropertiesコマンドを実行します。
たとえば、次のコマンドでは、最大キャッシュ・ヒープ領域が20MBに変更されます。

props = {}
props['configuration'] = 'foo'
props['max-heap-space'] = '20971520'
otd_setCacheProperties(props)

- 仮想サーバーのキャッシュ・ルールを作成するには、otd_createCacheRuleコマンドを実行します。
たとえば、次のコマンドでは、構成fooの仮想サーバーbarに対してcache-rule-imagesという名前のルールが作成され、このルールでは、式$uri='^/images'がtrueと評価されるリクエストがキャッシュされます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['cache-rule'] = 'cache-rule-images'
props['condition'] = '$uri='^/images''
otd_createCacheRule(props)

conditionプロパティの値は、正規表現にする必要があることに注意してください。条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』 の変数、式および文字列の補間の使用に関する項を参照してください。

- キャッシュ・ルールを変更するには、otd_setCacheRulePropertiesコマンドを実行します。
たとえば、次のコマンドでは、キャッシュ・ルールcache-rule-imagesに対してコンテンツの圧縮が無効化されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['cache-rule'] = 'cache-rule-images'
props['compression'] = 'false'
otd_setCacheRuleProperties(props)

- キャッシュ・ルールを削除するには、次の例に示すように、otd_deletecacheRuleコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['cache-rule'] = 'cache-rule-1'
otd_deleteCacheRule(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

7.11 コンテンツの提供

コンテンツ・ルールは、静的コンテンツの提供のみをサポートしています。動的コンテンツの提供はサポートされておらず、それはURI接頭辞に基づいてのみ作成できます。URI接頭辞は、すべてのコンテンツ・ルールで一意である必要があります。OTDのadminでは、コンテンツ・ルール、MIMEタイプおよびファイル・キャッシュのみに静的コンテンツの提供をサポートしています。

OTDでは、コンテンツ・ルールを管理することにより静的コンテンツの提供をサポートしています。動的コンテンツの提供はサポートされていません。コンテンツ・ルールはURI接頭辞に基づいて作成され、URI接頭辞はすべてのコンテンツ・ルールで一意である必要があります。

Fusion Middleware Controlを使用したコンテンツの提供の構成

Fusion Middleware Controlを使用してコンテンツの提供を構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. コンテンツの提供を構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。

7. ナビゲーション・ペインで、「仮想サーバー」を展開し、コンテンツの提供を構成する仮想サーバーの名前を展開して、「コンテンツの提供」を選択します。
「コンテンツの提供」ページが表示されます。仮想サーバーに現在定義されているコンテンツの提供がリストされます。

8. コンテンツの提供の作成

1. 「作成」をクリックします。
「新規コンテンツの提供」ダイアログ・ボックスが表示されます。

「名前」フィールドに、新規コンテンツ・ルールの名前を入力します。

2. 「URI接頭辞」フィールドに、そのコンテンツ・ルールに指定済のURIを入力します。

3. 「ディレクトリ・パス」フィールドに、すべての新しいコンテンツ・ルールが使用可能な指定済ディレクトリを入力します。
「OK」をクリックします。

今作成したコンテンツの提供が「コンテンツの提供」ページに表示されます。

コンテンツの提供の編集

コンテンツの提供の設定を変更するには、次を実行します。

1. 「名前」をクリックして、コンテンツの提供の「編集」ボタンを選択します。
「コンテンツの提供の設定」ページが表示されます。

2. 変更するパラメータを指定します。
フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。

「取消」ボタンをクリックすることで、いつでも変更を破棄できます。

3. 必要な変更を行った後、「OK」をクリックします。
更新された設定が保存されます。

コンテンツの提供の削除

コンテンツの提供ルールを削除するには、「削除」ボタンをクリックします。確認プロンプトで、「OK」です。

WLSTを使用したコンテンツの提供の構成

- コンテンツ・ルールを作成するには、次の例に示すように、otd_createContentRuleコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['uri-prefix'] = '/baz'
props['directory-path'] = '/qux'
props['content-rule'] = 'content-rule-1'
otd_createContentRule(props)

- 仮想サーバーに定義されているコンテンツ・ルールのリストを表示するには、次の例に示すように、otd_listContentRulesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listContentRules(props)

- 現在のコンテンツ・ルール・プロパティを表示するには、次の例に示すように、otd_getContentRulePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['content-rule'] = 'content-rule-1'
otd_getContentRuleProperties(props)

- 現在のコンテンツ・ルール・プロパティを設定するには、次の例に示すように、otd_setContentRulePropertiesコマンドを実行します。

props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['content-rule'] = 'content-rule-1'
props['index-files'] = 'home.htm'
otd_setContentRuleProperties(props)

- コンテンツ・ルールを削除するには、次の例に示すように、otd_deleteContentRuleコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['content-rule'] = 'content-rule-1'
otd_deleteContentRule(props)

- MIMEタイプを作成するには、次の例に示すように、otd_createMimeTypeコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['content-type'] = 'bar'
props['extensions'] = 'baz'
otd_createMimeType(props)

- MIMEタイプのリストを表示するには、次の例に示すように、otd_listMimeTypesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_listMimeTypes(props)

- MIMEタイプを削除するには、次の例に示すように、otd_deleteMimeTypeコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['content-type'] = 'bar'
props['extensions'] = 'baz'
otd_createMimeType(props)

- ファイル・キャッシュ・プロパティを表示するには、次の例に示すように、otd_getFileCachePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getFileCacheProperties(props)

- ファイル・キャッシュ・プロパティを設定するには、次の例に示すように、otd_setFileCachePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['max-age'] = '1200'
otd_setFileCacheProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

8 TCPプロキシの管理

トラフィック・トンネリングを行うためTCPプロキシはTCPリスナーを介してTCPリクエストを処理します。TCPプロキシには複数のTCPリスナーを関連付けることができますが、1つのTCPリスナーに関連付けることができるTCPプロキシは1つのみです。

この章では、TCPプロキシを作成、表示、変更および削除する方法を説明します。この章の内容は、次のとおりです。

- TCPプロキシの作成

- TCPプロキシのリストの表示

- TCPプロキシの変更

- TCPプロキシの削除

8.1 TCPプロキシの作成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、TCPプロキシを作成できます。

注意:

- TCPプロキシを作成すると、実質的には構成が変更されます。新規TCPプロキシ設定をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの使用方法の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

始める前に

TCPプロキシの作成を開始する前に、次の項目を決定します。

- 一意のプロキシ名。プロキシを作成した後は名前を変更できないため、名前は慎重に選択してください。

- リスナーに対する、IPアドレス(またはホスト名)とポート番号の一意の組合せ。
同じIPアドレスと様々なポート番号の組合せ、または単一のポート番号と様々なIPアドレスの組合せを持つ複数のTCPリスナーを定義できます。次のIPアドレスとポート番号の組合せそれぞれが、一意のリスナーと見なされます。

10.10.10.1:80
10.10.10.1:81
10.10.10.2:80
10.10.10.2:81

- TCPプロキシがリクエストを転送するオリジン・サーバー・プールの名前。オリジン・サーバー・プールの作成の詳細は、第5章「オリジン・サーバー・プールの管理」を参照してください。

Fusion Middleware Controlを使用したTCPプロキシの作成

Fusion Middleware Controlを使用してTCPプロキシを作成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. TCPプロキシを作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「TCPプロキシ」を選択します。

7. 「共通タスク」ペインで、「作成」をクリックします。
新規TCPプロキシ・ウィザードが開始されます。

図8-1 新規TCPプロキシ・ウィザード

8. 画面上のプロンプトに従い、前に決定済の詳細(プロキシ名、リスナー名、IPアドレス、ポートなど)を使用して、TCPプロキシの作成を完了します。

注意:

- TCPプロキシでFTPサポートを有効化する場合は、「FTPの有効化」オプションを選択します。

- ポートのTCPトラフィックがT3SなどのSSLを介して行われるトラフィックである場合、新規TCPプロキシ・ウィザードの最初の画面で「SSL/TLS」チェック・ボックスを選択し、使用する証明書を選択します。詳細は、10.1.2項「リスナーのSSL/TLSの構成」を参照してください。

プロキシが作成された後、新規TCPプロキシ・ウィザードの「結果」画面にプロキシの作成が成功したことを示すメッセージが表示されます。

9. 結果画面で、「閉じる」をクリックします。

- TCPプロキシ・ページに、作成したTCPプロキシの詳細が表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。3.3項「構成の変更のアクティブ化」の説明に従い、「変更のデプロイ」をクリックして更新した構成を即時にデプロイすることも、さらに変更を行って、その後でデプロイすることもできます。

WLSTを使用したTCPプロキシの作成

初期値のセットでTCPプロキシを作成するには、otd_createTcpProxyコマンドを実行します。

たとえば、次のコマンドでは、構成fooに、オリジン・サーバー・プールがtcp-origin-server-pool-1であるbarという名前のTCPプロキシが作成されます。

props = {}
props['configuration'] = 'foo'
props['tcp-proxy'] = 'bar'
props['origin-server-pool-name'] = 'tcp-origin-server-pool-1'
otd_createTcpProxy(props)

たとえば、次のコマンドでは、構成fooに、オリジン・サーバー・プールがtcp-origin-server-pool-1でプロトコルがftpであるbarという名前のTCPプロキシが作成されます。

props = {}
props['configuration'] = 'foo'
props['tcp-proxy'] = 'bar'
props['protocol'] = 'ftp'
props['origin-server-pool'] = 'tcp-origin-server-pool-1'
otd_createTcpProxy(props)

TCPプロキシのFTP構成がプロパティssl-termination、origin-explicit-ftps、client-explicit-ftpsをそれぞれ「false」、「true」、「true」として有効化されます。これらのプロパティは、otd_setTcpProxyPropertiesを使用して後で変更することができます。

otd_createTcpProxyの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

8.2 TCPプロキシのリストの表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、TCPプロキシのリストを表示できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したTCPプロキシのリストの表示

Fusion Middleware Controlを使用してTCPプロキシのリストを表示するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. TCPプロキシを表示する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「TCPプロキシ」を選択します。
「TCPプロキシ」ページが表示されます。構成に定義されたTCPプロキシのリストが表示されます。

名前をクリックすると、プロキシのプロパティの詳細を表示できます。

WLSTを使用したTCPプロキシのリストの表示

TCPプロキシのリストを表示するには、次の例に示すように、otd_listTcpProxiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_listTcpProxies(props)

tcp_proxy1
tcp_proxy2

otd_getTcpProxyPropertiesコマンドを実行することで、TCPプロキシのプロパティの詳細を表示できます。

otd_listTcpProxiesおよびotd_getTcpProxyPropertiesコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

8.3 TCPプロキシの変更

Fusion Middleware ControlまたはWLSTのいずれかを使用して、TCPプロキシを変更できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したTCPプロキシの変更

Fusion Middleware Controlを使用してTCPプロキシを変更するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. TCPプロキシを変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「TCPプロキシ」を選択します。
「TCPプロキシ」ページが表示されます。構成に定義されたTCPプロキシのリストが表示されます。

7. 変更するTCPプロキシの名前をクリックします。
「TCPプロキシ設定」ページが表示されます。このページで、次の処理が可能です。

- TCPプロキシの有効化および無効化

- オリジン・サーバー・プールおよびアイドル・タイムアウトの変更

- TCPリスナーの追加および削除。TCPリスナーの作成の詳細は、9.1項「リスナーの作成」を参照してください。

- アクティブおよびパッシブFTP接続のポート範囲を変更する。

- クライアントのFTP設定を表示する。
クライアントの明示的SSLが有効になっています。これは、クライアント接続に関するリクエストに対してSSLが有効化されていることを意味しています。関連付けられたすべてのTCPリスナーでSSLが有効になっている場合のみ、これを無効化できます。

- サーバーのFTP設定を変更する。
サーバーの明示的SSLが有効になっています。これは、オリジン・サーバー接続に関するリクエストに対してSSLが有効化されていることを意味しています。

SSLがサーバー・プールで有効化されていないため、サーバーのFTP設定を変更することはできません。「編集」をクリックしてサーバー・プールの編集ページに移動し、SSLを有効化します。

8. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。

「取消」ボタンをクリックすることで、いつでも変更を破棄できます。

9. 必要な変更を行った後、「OK」をクリックします。

- 更新されたプロキシが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したTCPプロキシの変更

TCPプロキシのプロパティを変更するには、otd_setTcpProxyPropertiesコマンドを実行します。

- たとえば、次のコマンドを実行すると、構成fooのプロキシbarのセッション・アイドル・タイムアウトが1200に変更されます。

props = {}
props['configuration'] = 'foo'
props['tcp-proxy'] = 'bar'
props['session-idle-timeout'] = '1200'
otd_setTcpProxyProperties(props)

- たとえば、次のコマンドはプロパティ「ssl-termination」、「origin-explicit-ftps」、「client-explicit-ftps」をそれぞれ「false」、「true」、「true」としてTCPプロキシのFTP構成を有効化します。

props = {}
props['configuration'] = 'foo'
props['tcp-proxy'] = 'bar'
props['client-explicit-ftps'] = 'true'
otd_setTcpProxyProperties(props)

otd_setTcpProxyPropertiesコマンドを使用して設定または変更できるプロパティのリストは、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

8.4 TCPプロキシの削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、TCPプロキシを削除できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したTCPプロキシの削除

Fusion Middleware Controlを使用してTCPプロキシを削除するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. TCPプロキシを削除する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「TCPプロキシ」を選択します。
「TCPプロキシ」ページが表示されます。構成に定義されたTCPプロキシのリストが表示されます。

7. 削除するTCPプロキシの「削除」アイコンをクリックします。
プロキシの削除を確認するプロンプトが表示されます。プロキシがリスナーに関連付けられている場合、プロンプトには、それらのリスナーの名前が表示されます。

8. 削除を続行するには、「はい」をクリックします。
「コンソール・メッセージ」ペインに、TCPプロキシが削除されたことを確認するメッセージが表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。3.3項「構成の変更のアクティブ化」の説明に従い、「変更のデプロイ」をクリックして更新した構成を即時にデプロイすることも、さらに変更を行って、その後でデプロイすることもできます。

WLSTを使用したTCPプロキシの削除

TCPプロキシを削除するには、次の例に示すように、otd_deleteTcpProxyコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['tcp-proxy'] = 'bar'
otd_deleteTcpProxy(props)

otd_deleteTcpProxyの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

9 リスナーの管理

クライアントとOracle Traffic Directorインスタンス間の接続は、HTTPリスナーおよびTCPリスナーを介して作成されます。各リスナーは、IPアドレス(またはホスト名)およびポート番号の一意の組合せです。

この章では、リスナーを作成、表示、変更および削除する方法を説明します。この章の内容は、次のとおりです。

- リスナーの作成

- リスナー・リストの表示

- リスナーの変更

- リスナーの削除

- 特権ポートをリスニングするためのOTDの構成

- ステータス・リスナーの構成

9.1 リスナーの作成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、リスナーを作成できます。

注意:
WLSTの使用方法の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

始める前に

リスナーの作成を開始する前に、次の項目を決定します。

- リスナーの一意の名前。リスナーを作成した後は名前を変更できないため、名前は慎重に選択してください。

- リスナーに対する、IPアドレス(またはホスト名)とポート番号の一意の組合せ。
同じIPアドレスと様々なポート番号の組合せ、または単一のポート番号と様々なIPアドレスの組合せを持つ複数のリスナーを定義できます。次のIPアドレスとポート番号の組合せそれぞれが、一意のリスナーと見なされます。

10.10.10.1:80
10.10.10.1:81
10.10.10.2:80
10.10.10.2:81

- HTTPリスナーの場合: リスナーのデフォルトの仮想サーバー。
Oracle Traffic Directorは、リクエスト・ヘッダーのHost値が、リスナーにバインドされている仮想サーバーに指定されたホスト・パターンと一致しない場合、デフォルトの仮想サーバーにリクエストをルーティングします。

仮想サーバーのホスト・パターンの指定の詳細は、7.1項「仮想サーバーの起動」を参照してください。

- HTTPリスナーの場合: サーバーによって自動的に生成され、クライアントに送信されるURLに含まれるサーバー名。このサーバー名は、仮想ホスト名であるか、またはサーバーで別名が使用されている場合、別名である必要があります。コロンとポート番号がサーバー名に追加されている場合、このポート番号は自動生成されたURLで使用されます。

- TCPリスナーの場合: リスナーのTCPプロキシ。
トラフィック・トンネリングを行うためTCPプロキシはTCPリスナーを介してTCPリクエストを処理します。TCPプロキシには複数のTCPリスナーを関連付けることができます。TCPリスナーを関連付け、このページでTCPプロキシの設定を構成します。

TCPプロキシの作成の詳細は、8.1項「TCPプロキシの作成」を参照してください。

Fusion Middleware Controlを使用したHTTPリスナーの作成

Fusion Middleware Controlを使用してHTTPリスナーを作成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. HTTPリスナーを作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「リスナー」を選択します。

7. 「共通タスク」ペインで、「HTTPリスナー」の下にある「作成」をクリックします。
新規HTTPリスナー・ウィザードが開始されます。

図9-1 新規HTTPリスナー・ウィザード

8. 画面上のプロンプトに従い、前に決定済の詳細(リスナー名、IPアドレス、ポートなど)を使用して、HTTPリスナーの作成を完了します。

注意:
構成で証明書を使用できる場合は、ウィザードの2つ目の画面で「SSL/TLS」チェック・ボックスが使用可能になります。HTTPSリクエストを受信する新しいリクエストが必要な場合は、このチェック・ボックスを選択してSSL/TLSを有効にし、ドロップダウン・リストから適切な証明書を選択します。

HTTPリスナーが作成された後、新規HTTPリスナー・ウィザードの「結果」画面にリスナーの作成が成功したことを示すメッセージが表示されます。

9. 「結果」画面で、「OK」をクリックします。

- 作成したリスナーの詳細が、「リスナー」ページに表示されます。

Fusion Middleware Controlを使用したTCPリスナーの作成

Fusion Middleware Controlを使用してTCPリスナーを作成するには、次を実行します。

1. Fusion Middleware Controlを使用したHTTPリスナーの作成の手順1、2および3を実行します。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. TCPリスナーを作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「リスナー」を選択します。

7. 「共通タスク」ペインで、「TCPリスナーの作成」をクリックします。
新規TCPリスナー・ウィザードが開始されます。

図9-2 新規TCPリスナー・ウィザード

8. 画面上のプロンプトに従い、前に決定済の詳細(リスナー名、IPアドレス、ポートなど)を使用して、TCPリスナーの作成を完了します。

注意:
構成で証明書を使用できる場合は、ウィザードの2つ目の画面で「SSL/TLS」チェック・ボックスが使用可能になります。T3Sリクエストを受信する新しいリクエストが必要な場合は、このチェック・ボックスを選択してSSL/TLSを有効にし、ドロップダウン・リストから適切な証明書を選択します。

TCPリスナーが作成された後、新規TCPリスナー・ウィザードの「結果」画面にリスナーの作成が成功したことを示すメッセージが表示されます。

9. 「結果」画面で、「OK」をクリックします。

- 作成したリスナーの詳細が、「リスナー」ページに表示されます。

WLSTを使用したリスナーの作成

- HTTPリスナーを作成するには、otd_createHttpListenerコマンドを実行します。
たとえば、次のコマンドでは、構成fooにポート番号が23456、デフォルト仮想サーバーがbarであるhttp-listener-1という名前のHTTPリスナーが作成されます。

props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
props['port'] = '23456'
props['server-name'] = 'example.com'
props['default-virtual-server-name'] = 'bar'
otd_createHttpListener(props)

- TCPリスナーを作成するには、otd_createTcpListenerコマンドを実行します。
たとえば、次のコマンドでは、構成fooにポート番号が34567、TCPプロキシがtcp_proxy-1であるtcp_listener_1という名前のTCPリスナーが作成されます。

props = {}
props['configuration'] = 'foo'
props['tcp-listener'] = 'tcp-listener-1'
props['port'] = '34567'
props['tcp-proxy-name'] = 'tcp-proxy-1'
otd_createTcpListener(props)

otd_createHttpListenerおよびotd_createTcpListenerの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

9.2 リスナー・リストの表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、HTTPまたはTCPリスナーのリストを表示できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したリスナーのリストの表示

Fusion Middleware Controlを使用してHTTPまたはTCPリスナーのリストを表示するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. HTTPリスナーまたはTCPリスナーを表示する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「リスナー」を選択します。
「リスナー」ページが表示されます。構成に定義されたリスナー・リストが表示されます。

注意:
HTTPリスナーおよびTCPリスナーはアイコンでも区別ができます。

名前をクリックすると、リスナーのプロパティの詳細を表示できます。

WLSTを使用したリスナーのリストの表示

- HTTPリスナー・リストを表示するには、次の例に示すように、otd_listHttpListenersコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_listHttpListeners(props)

listener-1
listener-2

otd_getHttpListenerPropertiesコマンドを実行することで、HTTPリスナーのプロパティの詳細を表示できます。

otd_listHttpListenersおよびgotd_getHttpListenerPropertiesコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

- TCPリスナー・リストを表示するには、次の例に示すように、otd_listTcpListenersコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_listTcpListeners(props)

listener-1
listener-2

otd_getTcpListenerPropertiesコマンドを実行することで、TCPリスナーのプロパティの詳細を表示できます。

otd_listTcpListenersおよびotd_getTcpListenerPropertiesコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

9.3 リスナーの変更

Fusion Middleware ControlまたはWLSTのいずれかを使用して、リスナーを変更できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したリスナーの変更

Fusion Middleware Controlを使用してHTTPまたはTCPリスナーを変更するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. HTTPリスナーまたはTCPリスナーを変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「リスナー」を選択します。
「リスナー」ページが表示されます。構成に定義されているHTTPまたはTCPリスナーのリストが表示されます。

7. 変更するリスナーの名前をクリックします。
「リスナー設定」ページが表示されます。このページで、次の処理が可能です。

- リスナーの有効化および無効化。

- リスナー・ポート番号とIPアドレスの変更。

- HTTPリスナーの場合: サーバー名とデフォルト仮想サーバーの変更。

- TCPリスナーの場合: TCPプロキシの変更。

- サーバー証明書が構成に作成済の場合、SSL/TLSの有効化と、リスナーのSSL/TLS設定の構成。詳細は、10.1.2項「リスナーのSSL/TLSの構成」を参照してください。

- リスナーがリクエストを受け入れる必要があるプロトコル・ファミリ(IPv4、IPv6またはSDP)の変更。

- HTTPリスナーの場合: 仮想サーバーのパフォーマンスをチューニングするためのパラメータ(アクセプタ・スレッド数、リスニング・キュー・サイズ、受信バッファ・サイズなど)の構成。詳細は、15.4項「HTTPリスナー設定のチューニング」を参照してください。

8. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

9. 必要な変更を行った後、「保存」をクリックします。

- 更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。3.3項「構成の変更のアクティブ化」の説明に従い、「変更のデプロイ」をクリックして更新した構成を即時にデプロイすることも、さらに変更を行って、その後でデプロイすることもできます。

WLSTを使用したリスナーの変更

- HTTPリスナーのプロパティを変更するには、otd_setHttpListenerPropertiesコマンドを実行します。たとえば、次のコマンドでは、構成foo内のリスナーhttp-listener-1の1接続当たりの最大リクエスト数が1024に変更されます。

props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
props['max-requests-per-connection'] = '1024'
otd_setHttpListenerProperties(props)

HTTPリスナーのSSL/TLS設定を変更するには、otd_setHttpListenerSslPropertiesコマンドを実行します。たとえば、次のコマンドを実行すると、構成fooのリスナーhttp-listener-1のTLS 1.0サポートが無効になります。

- props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
props['tls10'] = 'false'
otd_setHttpListenerSslProperties(props)

TCPリスナーのプロパティを変更するには、otd_setTcpListenerPropertiesコマンドを実行します。たとえば、次のコマンドでは、構成foo内のリスナーtcp-listener-1の1接続当たりの最大リクエスト数が1024に変更されます。

- props = {}
props['configuration'] = 'foo'
props['tcp-listener'] = 'tcp-listener-1'
props['max-requests-per-connection'] = '1024'
otd_setTcpListenerProperties(props)

TCPリスナーのSSL/TLS設定を変更するには、otd_setTcpListenerSslPropertiesコマンドを実行します。たとえば、次のコマンドを実行すると、構成fooのリスナーtcp-listener-1のTLS 1.0サポートが無効になります。

- props = {}
props['configuration'] = 'foo'
props['tcp-listener'] = 'tcp-listener-1'
props['tls10'] = 'false'
otd_setTcpListenerSslProperties(props)

otd_setTcpListenerPropertiesおよびSslPropertiesコマンドを使用して設定または変更できるプロパティのリストは、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

9.4 リスナーの削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、HTTPまたはTCPリスナーを削除できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したリスナーの削除

Fusion Middleware Controlを使用してHTTPまたはTCPリスナーを削除するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. HTTPリスナーまたはTCPリスナーを削除する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「リスナー」を選択します。
「リスナー」ページが表示されます。構成に定義されたHTTP/TCPリスナー・リストが表示されます。

7. 削除するリスナーの「削除」アイコンをクリックします。
リスナーの削除を確認するプロンプトが表示されます。

注意:
HTTPリスナーの場合: HTTPリスナーが仮想サーバーに関連付けられている場合、プロンプトには、それらの仮想サーバーが表示されます。

8. 削除を続行するには、「はい」をクリックします。
「コンソール・メッセージ」ペインに、HTTP/TCPリスナーが削除されたことを確認するメッセージが表示されます。

WLSTを使用したリスナーの削除

- HTTPリスナーを削除するには、次の例に示すように、otd_deleteHttpListenerコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
otd_deleteHttpListener(props)

TCPリスナーを削除するには、次の例に示すように、otd_deleteTcpListenerコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['tcp-listener'] = 'tcp-listener-1'
otd_deleteTcpListener(props)

otd_deleteHttpListenerおよびotd_deleteTcpListenerの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

9.5 特権ポートをリスニングするためのOTDの構成

次の手順に従って、特権ポートをリスニングするようにOTDを構成できます。

1. 特権ポート用のリスニング・ソケットを作成するため、OTDには「portbind」という名前のバイナリがバンドルされています。

2. OTDで特権ポートでのリスニングを必要とする場合、管理者は、次のように「portbind」の所有者をrootにして、setuid権限を与える必要があります

- chown root portbind。

- chmod 4750 portbind。

3. サーバーのユーザーに、前の手順の実行に必要なグループの所有権があることを確認します

4. OTDのウォッチドッグ・プロセスにより、「portbind」を使用して、特権ポートを必要とするリスニング・ソケットが作成されます

9.6 ステータス・リスナーの構成

Oracle Traffic Directorインスタンスのステータスをチェックする専用のステータス・リスナーを構成できるようになりました。Oracle Traffic Directorのステータスを提供する専用ポートを使用すると、Oracle Traffic Directorがロードされている場合であっても、必ずステータス・リクエストの処理に使用できます。

さらに、そのポートに対してSSL設定を構成することで、ステータス・リスナーを保護することができます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、リスナーを構成できます。

9.6.1 Fusion Middleware Controlを使用したステータス・リスナーの構成

Fusion Middleware Controlを使用してステータス・リスナーを構成するには、次を実行します。

1. Fusion Middleware Controlの表示の説明に従って、Fusion Middleware Controlにログインします

2. 証明書が存在しない場合、このセクションでは、証明書の生成を求められます。ページの右上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. ステータス・リスナーを構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「ステータス・リスナー」を選択します。

7. 「一般設定」セクションで、「有効」チェック・ボックスをチェックすることでステータス・リスナーを有効化し、前に決定済みの詳細(ポート、IPアドレスなど)を指定します。

図9-3「一般設定」セクション

8. 「適用」をクリックします。

- 構成したステータス・リスナーの詳細が「ステータス・リスナー」ページに表示されます。

- 「SSL/TLS設定」セクションと「詳細設定」セクションが表示されます。

9. 「SSL/TLS設定」セクションで、リスナーのSSLを有効化します。
証明書が存在する場合、このセクションでは、証明書を選択してリスナーのSSLを有効化できます。証明書を生成するには、「証明書の管理」をクリックします。

- SSL/TLSチェック・ボックスを選択して証明書を有効にします。

- 「RSA証明書」および「ECC証明書」フィールドで、サーバーの認証に使用する証明書を選択します。

図9-4「SSL/TLS設定」セクション

10. 「詳細設定」ペインにSSL/TLSの詳細設定が表示されます。構成に証明書がある場合、SSL/TLS設定を使用できます。
「SSL/TLS設定」セクションで、前に決定済みのSSLまたはTLSセキュリティ・プロトコルに関する設定を指定します。

図9-5「詳細設定」セクション

11. 詳細を入力したら、「適用」をクリックします。
ステータス・リスナーが構成されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

12. 「Oracle Traffic Director構成」ペインで「インスタンスの起動/インスタンスの再起動」をクリックして、構成のインスタンスを再起動します。

9.6.2 WLSTを使用したステータス・リスナーの構成

- ステータス・リスナーのプロパティの有効化/変更
ステータス・リスナーを有効化するか、あるいはステータス・リスナーの非SSLプロパティを変更するには、例に示すように、otd_enableStatusListenerコマンドを実行します。

- ステータス・リスナーを有効化する

props = {}
props['configuration'] = 'foo'
props['port'] = '12345'
otd_enableStatusListener(props)

- ステータス・リスナーの非SSLプロパティを変更する
前の例で示したように、有効化されたステータス・リスナーについて考えてみます。これは、ipおよびfamilyの値がそれぞれ*およびdefaultであることを意味しています。このステータス・リスナーのIPアドレスおよびポートを再構成するには、例に示すように、otd_enableStatusListenerコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['ip'] = '127.0.0.1'
props['port'] = '2016'
otd_enableStatusListener(props)

- ステータス・リスナーの無効化
ステータス・リスナーを無効にするには、例に示すように、otd_disableStatusListenerコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_disableStatusListener(props)

- ステータス・リスナーのプロパティの表示
ステータス・リスナーのプロパティを表示するには、例に示すように、otd_getStatusListenerPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getStatusListenerProperties(props)

- ステータス・リスナーのSSLプロパティの変更
ステータス・リスナーのSSLプロパティを変更するには、例に示すように、otd_setStatusListenerSslPropertiesコマンドを実行します。

ステータス・リスナーのSSLを無効にするには、enabledプロパティをfalseに設定します。

props = {}
props['configuration'] = 'foo'
props['enabled'] = 'false'
otd_setStatusListenerSslProperties(props)

- ステータス・リスナーのSSLプロパティの表示
ステータス・リスナーのSSLプロパティを表示するには、例に示すように、otd_getStatusListenerSslPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getStatusListenerSslProperties(props)

この項で説明したWLSTコマンドの詳細は、Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンスを参照してください。

第III部

高度な管理

第III部は、次の章で構成されています。

- 第10章「セキュリティの管理」では、管理サーバーへのアクセスを保護する方法、Oracle Traffic Director仮想サーバーのSSL/TLSを有効化する方法、証明書を管理する方法、および証明書、PKCS#11トークン、証明書失効リストの管理方法を説明します。

- 第11章「ログの管理」では、アクセス・ログおよびサーバー・ログの概要を紹介し、ログの表示、ログ・プリファレンスの構成およびログ・ローテーションの各方法を説明します。

- 第12章「Oracle Traffic Directorインスタンスの監視」では、Oracle Traffic Directorインスタンスを監視するために使用できる方法を説明します。

- 第13章「イベント通知」では、通知を受け取ることができるイベントについて説明します。

- 第14章「高可用性を提供するためのOracle Traffic Directorの構成」では、Oracle Traffic Directorの高可用性機能について説明します。フェイルオーバー・グループのOracle Traffic Directorインスタンスの構成方法、およびバック・エンドのオリジン・サーバーの状態のOracle Traffic Directorによる監視の設定方法を説明します。

- 第15章「パフォーマンス向上のためのOracle Traffic Directorのチューニング」では、Oracle Traffic Directorインスタンスのパフォーマンスを向上させるためにチューニングできる様々なパラメータを説明します。

- 第16章「問題の診断およびトラブルシューティング」では、Oracle Traffic Directorの使用時に発生する可能性のある問題を理解し解決するために役立つ情報を紹介します。

- 付録A「Oracle Traffic Directorで追跡されるメトリック」では、Oracle Traffic Directorが追跡する様々なメトリックの名前を一覧で示します。

- 付録B「Webアプリケーション・ファイアウォールの例とユースケース」では、Webアプリケーション・ファイアウォールの動作に関する基本的な情報を示します。

- 付録C「Oracle Traffic Directorデプロイメントの保護」では、Oracle Traffic Directorデプロイメントを保護するための手順について説明します。

10 セキュリティの管理

この章では、Oracle Traffic Director管理サーバーへのアクセスの保護、およびOracle Traffic Director仮想サーバーに対するSSL/TLSの有効化の方法について説明します。また、クライアント認証の構成方法、およびOracle Traffic Directorを使用したオリジン・サーバーへのアクセスの保護の方法についても説明します。

この章には次の項が含まれます:

- Oracle Traffic Directorとクライアント間のSSL/TLSの構成

- Oracle Traffic Directorとオリジン・サーバー間のSSL/TLSの構成

- 証明書の管理

- 証明書失効リストの管理

- Webアプリケーション・ファイアウォールの管理

- クライアント認証の構成

- サービス拒否攻撃の防止

- OTDのSSLパススルーの構成

注意:
環境内のOracle Traffic Directorを保護するための手順の詳細は、付録C「Oracle Traffic Directorデプロイメントの保護」を参照してください。

10.1 Oracle Traffic Directorとクライアント間のSSL/TLSの構成

この項では、SSL/TLSを使用して、クライアントとOracle Traffic Directorインスタンス間の通信を保護する方法について説明します。この項の情報は、SSL/TLS、証明書、暗号および鍵の概念を熟知している読者を対象としています。これらの概念の基本的な情報については、10.1.7項「SSL/TLSの概念」を参照してください。

この項には次のサブセクションが含まれます:

- 10.1.1項「SSL/TLS構成プロセスの概要」

- 10.1.2項「リスナーのSSL/TLSの構成」

- 10.1.3項「仮想サーバーと証明書の関連付け」

- 10.1.4項「リスナーのSSL/TLS暗号の構成」

- 10.1.5項「証明書の選択ロジック」

- 10.1.6項「厳密なSNIホスト一致について」

- 10.1.7項「SSL/TLSの概念」

10.1.1 SSL/TLS構成プロセスの概要

Oracle Traffic DirectorインスタンスのSSL/TLSを有効化するには、RSAまたはECC証明書、あるいはその両方をインスタンスの1つ以上のリスナーに関連付ける必要があります。加えて、RSAまたはECC証明書、あるいはその両方を、仮想サーバーに直接関連付けることもできます。Oracle Traffic DirectorインスタンスのSSL/TLSを構成するプロセスには、次の手順が含まれます。

1. 自己署名証明書、VeriSign社などのサードパーティ認証局(CA)が発行した証明書または自分で生成した証明書を取得します。
詳細は、次の項を参照してください。

- 10.3.1項「鍵ペアの生成」

- 10.3.2項「CA署名証明書の取得」

2. 10.3.3項「証明書のインポート」の説明に従って証明書をインストールします。

3. 10.1.2項「リスナーのSSL/TLSの構成」の説明に従い、証明書を必要なHTTPリスナーまたはTCPリスナーに関連付けます。
10.1.3項「証明書と仮想サーバーの関連付け」の説明に従い、証明書を仮想サーバーに直接関連付けることもできます。Oracle Traffic Directorで、SSL/TLSハンドシェイク中にクライアントに送信される証明書の選択に使用されるロジックの詳細は、10.1.5項「証明書の選択ロジック」を参照してください。

4. 10.1.4項「リスナーのSSL/TLS暗号の構成」の説明に従い、HTTPリスナーまたはTCPリスナーにサポートされている暗号を構成します。

10.1.2 リスナーのSSL/TLSの構成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、HTTPSまたはTCPリクエストを受信するリスナーを構成できます。開始する前に、必要な証明書を取得して、10.3.1項「鍵ペアの生成」、10.3.2項「CA署名証明書の取得」および10.3.3項「証明書のインポート」の説明に従ってインストールします。

注意:

- リスナーを変更すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- 新しい証明書をリスナーに関連付ける、または以前に関連付けられていた証明書を削除する場合、変更を有効にするには、インスタンスを再起動する必要があります。更新された構成をデプロイするだけでは不十分です。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したリスナー用のSSL/TLSの構成

Fusion Middleware Controlを使用してHTTPまたはTCP用のSSL/TLSを構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. SSL/TLSが有効化されたリスナーを構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

名前をクリックすると、仮想サーバーのプロパティを表示できます。

7. 有効にし、SSL/TLSを構成するリスナーを選択します。
「リスナー設定」ページが表示されます。

8. 「設定」→「詳細設定」→「SSL/TLS設定」を選択します。
「SSL/TLS設定」ページが表示されます。

9. 「SSL設定」セクションで、「SSL有効」チェック・ボックスを選択します。

10. 「RSA証明書」および「ECC証明書」フィールドで、サーバーの認証に使用する証明書を選択します。
リスナーをRSA証明書およびECC証明書に関連付ける場合、サーバーがクライアントに最終的に提示する証明書は、クライアントとサーバーがネゴシエートして使用する暗号スイートに基づき、SSL/TLSハンドシェイク中に決定されます。

また、「リスナー設定」ページの「詳細設定」セクションで次の詳細なSSL/TLS設定も指定できます。

- クライアント認証の設定の有効化および無効化詳細は、10.6項「クライアント認証の構成」を参照してください。

- 厳密なSNIホスト一致の有効化および無効化。詳細は、10.1.6項「厳密なSNIホスト一致について」を参照してください。

- 次のTLS固有の機能の有効化および無効化

- バージョンのロールバック
Oracle Traffic DirectorでTLSバージョンのロールバックを検出し、試行をブロックするには、このチェック・ボックスを選択します。たとえば、クライアントがTLS 1.0をリクエストしたものの、攻撃者がより低いバージョン(たとえば、SSL 3.0)に変更した場合、Oracle Traffic Directorは、低いバージョンをサポートしていたとしても、このロールバックを検出しブロックします。

- セッション・チケット拡張
有効化した場合、TLSセッションは、サーバー上に各クライアントのセッション状態を格納することなく再開できます。Oracle Traffic Directorは、各クライアントのセッション状態をチケットにカプセル化し、クライアントにチケットを転送します。続いて、クライアントは、前に取得済のセッション・チケットを使用してTLSセッションを再開します。

- SSLおよびTLS暗号の有効化および無効化。詳細は、10.1.4項「リスナーのSSL/TLS暗号の構成」を参照してください。

画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

11. 必要な変更を行った後、「適用」をクリックします。
更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

12. 「共通のタスク」ペインの「インスタンスの起動/再起動」をクリックして、構成のインスタンスを再起動します。

WLSTを使用したリスナーのSSL/TLSの構成

- HTTPまたはTCPリスナーのSSL/TLSのプロパティを表示するには、次の例に示すように、otd_getHttpListenerSslPropertiesまたはotd_getTcpListernerSslPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
otd_getHttpListenerSslProperties(props)

enabled=false
client-auth=false
client-auth-timeout=60
max-client-auth-data=1048576
ssl3=true
tls10=true
tls11=true
tls12=true
override-cipher-order=false
...

- HTTPまたはTCPリスナー用のSSL/TLSを構成するには、次の例に示すように、otd_setHttpListenerSslPropertiesまたはotd_setTcpListenerSslPropertiesコマンドを実行します。

props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
props['tls10'] = 'false'
otd_setHttpListenerSslProperties(props)

10.1.3 仮想サーバーと証明書の関連付け

Fusion Middleware ControlまたはWLSTのいずれかを使用して、1つのRSAおよび1つのECC証明書を各仮想サーバーに関連付けることができます。Oracle Traffic Directorで、SSL/TLSハンドシェイク中にクライアントに送信される証明書の選択に使用されるロジックの詳細は、10.1.5項「証明書の選択ロジック」を参照してください。

開始する前に、必要な証明書を取得して、10.3.1項「鍵ペアの生成」、10.3.2項「CA署名証明書の取得」および10.3.3項「証明書のインポート」の説明に従ってインストールします。

注意:

- 仮想サーバーを変更すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- 新しい証明書を仮想サーバーに関連付ける、または以前に関連付けられていた証明書を削除する場合、変更を有効にするには、インスタンスを再起動する必要があります。更新された構成をデプロイするだけでは不十分です。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した証明書と仮想サーバーの関連付け

Fusion Middleware Controlを使用して証明書を仮想サーバーと関連付けるには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 仮想サーバーと証明書を関連付ける構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

名前をクリックすると、仮想サーバーのプロパティを表示できます。

7. 有効にし、SSL/TLSを構成するリスナーを選択します。
「リスナー設定」ページが表示されます。

8. 「設定」→「詳細設定」→「SSL/TLS設定」を選択します。
「SSL/TLS設定」ページが表示されます。

9. 「SSL設定」セクションで、「SSL有効」チェック・ボックスを選択します。

10. 「RSA証明書」および「ECC証明書」フィールドで、サーバーの認証に使用する証明書を選択します。
フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

11. 必要な変更を行った後、「適用」をクリックします。
更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

12. OTDの「構成」ペインで「インスタンスの起動/インスタンスの再起動」をクリックして、構成のインスタンスを再起動します。

WLSTを使用した仮想サーバーと証明書の関連付け

- 仮想サーバーに現在関連付けられている証明書を表示するには、次の例に示すように、otd_getVirtualServerPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_getVirtualServerProperties(props)

- 仮想サーバーと証明書を関連付けるには、次の例に示すように、otd_setVirtualServerSslPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['server-cert-alias'] = 'cert-1'
props['http-listener'] = 'http-listener-1'
otd_setVirtualServerProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

注意:
仮想サーバーに関連付ける証明書と同じタイプの証明書(ECCまたはRSA)が、仮想サーバーがバインドされているリスナーにも関連付けられていることを確認してください。

10.1.4 リスナーのSSL/TLS暗号の構成

SSL/TLSハンドシェイクの実行中、クライアントとサーバーは、サポートしているSSLおよびTLSについて情報を交換し、SSL/TLSセッションに使用する暗号(通常、最も強力な暗号)をネゴシエートします。暗号についての基本的な概念の詳細は、暗号についてを参照してください。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、Oracle Traffic Directorがサポートしているリスナーの暗号を構成できます。

Fusion Middleware Controlを使用したリスナーの暗号の構成

Fusion Middleware Controlを使用してHTTPまたはTCPリスナーでサポートされる暗号を構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 暗号を構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「リスナー」を選択します。
「リスナー」ページが表示されます。構成に定義されたHTTP/TCPリスナー・リストが表示されます。

名前をクリックすると、HTTP/TCPリスナーのプロパティを表示できます。

7. 有効にし、SSL/TLSを構成するHTTP/TCPリスナーを選択します。
「リスナー設定」ページが表示されます。

8. 「設定」→「詳細設定」→「SSL/TLS設定」を選択します。
「SSL/TLS設定」ページが表示されます。

9. 「SSL設定」セクションで証明書を管理できます。

10. フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。
「取消」ボタンをクリックすることで、いつでも変更を破棄できます。

11. 必要な変更を行った後、「OK」をクリックします。
更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したリスナーの暗号の構成

- 現在HTTPまたはTCPリスナーで有効になっている暗号を表示するには、次の例に示すように、otd_getHttpListenerSslPropertiesまたはotd_getTcpListernerSslPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
otd_getHttpListenerSslProperties(props)

現在有効になっている暗号のカンマ区切りのリストがcipherプロパティに返されます。

- リスナーに対して特定の暗号を有効または無効にするには、otd_setHttpListenerSslPropertiesまたはotd_setTcpListenerSslPropertiesコマンドを実行し、有効にする暗号をciphersプロパティに指定します。

- otd_getHttpListenerSslPropertiesまたはotd_getTcpListenerSslPropertiesコマンドを実行するときに、サポートされている暗号のリストは別のプロパティ「supported-ciphers」で表示されます。

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

Oracle Traffic Directorでサポートされている暗号スイート

SSL/TLSハンドシェイク中、Oracle Traffic Directorとクライアント間でどの暗号スイートを使用するかのネゴシエーションが行われます。表10-1に、Oracle Traffic Directorでサポートされている暗号スイートを示します。このリストは、この項で説明したWLSTコマンドotd_getVirtualServerSslPropertiesを実行すると表示されます。各暗号スイートの名前は、鍵交換アルゴリズム、ハッシュ・アルゴリズム、暗号化アルゴリズムを表しています。

- サポートされるプロトコル

- TLS: TLS 1.0, 1.1, 1.2

- SSL: SSL 3

- サポートされる鍵交換アルゴリズム

- RSA

- RSA_EXPORT

- RSA_EXPORT1024

- RSA_FIPS

- ECDHE_RSA

- ECDH_RSA

- ECDH_ECDSA

- ECDHE_ECDSA

- サポートされる暗号化アルゴリズム

- AES_256_CBC: 256ビット鍵

- 3DES_EDE_CBC: 168ビット鍵

- AES_128_CBC: 128ビット鍵

- RC4_128: 128ビット鍵

- DES_CBC: 56ビット鍵

- RC4_56: 56ビット鍵

- RC4_40およびRC2_CBC_40: 128ビット鍵。ただし、暗号化で意味を持つのは40ビットのみ

- NULL: 暗号化なし

- サポートされるメッセージ認証コード(MAC)アルゴリズム

- SHA: 160ビット・ハッシュ

- NULL: ハッシュなし

表10-1 Oracle Traffic Directorでサポートされる暗号スイート

暗号スイート

FIPS 140準拠

SSL_RSA_WITH_RC4_128_SHA

SSL_RSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

はい

TLS_ECDHE_RSA_WITH_RC4_128_SHA

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

はい

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

はい

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

はい

TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

はい

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

はい

TLS_RSA_WITH_AES_128_CBC_SHA

はい

TLS_RSA_WITH_AES_256_CBC_SHA

はい

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

FIPS 140準拠に関する情報の出典: http://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html

10.1.5 証明書の選択ロジック

HTTPSリクエストの受信時、Oracle Traffic DirectorがSSL/TLSハンドシェイク中に送信する証明書は、次のいずれかになります。

- 構成したHTTP/TCPリスナーにバインドされている仮想サーバーに関連付けられている証明書

- リスナーのデフォルト仮想サーバーに関連付けられている証明書

- リスナーに関連付けられている証明書

Oracle Traffic Directorは、次のロジックを使用して、SSL/TLSハンドシェイク中にクライアントに送信する証明書を決定します。

表10-2 証明書の選択ロジック

条件

ケースA

ケースB

ケースC

ケースD

クライアントがSNIホスト拡張を送信しました

はい

はい

はい

いいえ

一致する脚注1仮想サーバーが見つかりました。

はい

いいえ

いいえ

--

一致する仮想サーバーに、クライアントから送信された暗号に一致する証明書タイプ(RSAまたはECC)があります。

はい

--

--

--

リスナーのデフォルト仮想サーバーに、クライアントから送信された暗号に一致する証明書タイプ(RSAまたはECC)があります。

--

はい

--

--

リスナーに、クライアントから送信された暗号に一致する証明書タイプ(RSAまたはECC)があります。

--

--

はい

はい

選択される証明書:

一致する仮想サーバーの証明書

デフォルト仮想サーバーの証明書

リスナーの証明書

リスナーの証明書

脚注1 一致する仮想サーバーとは、リスナーにバインドされている仮想サーバーで、クライアントから送信されたHost:ヘッダーと一致するホスト・パターンを持ちます。

10.1.6 厳密なSNIホスト一致について

SSL/TLSが有効化されたOracle Traffic DirectorインスタンスにクライアントがHTTPSリクエストを送信する際、サーバーは、SSL/TLSハンドシェイクを開始するために証明書をクライアントに送信する必要があります。リクエスト内のホスト名が、サーバーから提供される証明書内のサーバー名(通常、CN)と一致しない場合、警告メッセージが、クライアントによってユーザーに表示されます。SSL/TLSハンドシェイク・プロセスを続行するには、ユーザーは、証明書を信頼することを明示的に選択する必要があります。

Oracle Traffic Directorインスタンスに、単一のIPアドレスとポートの組合せで構成された名前ベースの仮想サーバーが複数含まれている場合、クライアントに送信する適切な証明書を特定するには、サーバーは、HTTPリクエスト内のHostヘッダーの値を認識している必要がありますが、この値は、SSL/TLS接続が確立されるまで読み取ることはできません。

Server Name Indication (SNI)と呼ばれる、SSLとTLSプロトコルの拡張により、リクエストされたホスト名をSNIホスト拡張でSSL/TLSハンドシェイク中に提供することをクライアントに許可することで、この問題に対応します。Oracle Traffic Directorは、SNIホスト拡張内のホスト名を使用して、クライアントに送信する仮想サーバー証明書を特定します。仮想サーバーと証明書の関連付けの詳細は、10.1.3項「仮想サーバーと証明書の関連付け」を参照してください。

SNIのサポートは、Oracle Traffic DirectorのSSL/TLSが有効化されたHTTPリスナーに対してデフォルトで有効化されています。より厳密に制御するために、非SNIクライアントが名前ベースの仮想サーバーにアクセスできないようにする場合は、「厳密なSNIホスト一致」パラメータを有効化する必要があります。

「厳密なSNIホスト一致」がHTTPリスナーに対して有効化されていて、そのリスナーに対し、仮想サーバーの少なくとも1つに証明書がある場合、次の条件のいずれかが真であれば、Oracle Traffic Directorにより403-Forbiddenエラーがクライアントに返されます。

- SSL/TLSハンドシェイク中、クライアントからSNIホスト拡張が送信されませんでした。

- リクエストに、Host:ヘッダーがありません。

- SSL/TLSハンドシェイク中にSNIホスト拡張でクライアントから送信されたホスト名が、リクエスト内のHost:ヘッダーと一致しません。

10.1.7 SSL/TLSの概念

この項では、セキュリティ関連の概念についての基本情報を説明します。次の項目が含まれます。

- SSLについて

- 暗号について

- 鍵について

- 証明書について

SSLについて

Secure Socket Layer (SSL)は、インターネットの通信およびトランザクションを保護するプロトコルです。デジタル証明書を使用することで、サーバーとクライアント間のセキュアで機密性の高い通信が可能になります。Oracle Traffic Directorは、SSL v3およびトランスポート層セキュリティ(TLS) v1をサポートしています。

双方向HTTP over SSL (HTTPS)接続では、ブラウザ、Webサーバーなどのそれぞれの装置がまず、相手のアイデンティティを確認します。このフェーズをSSL/TLSハンドシェイクと呼びます。アイデンティティが確認された後、接続が確立され、データが暗号化された形式で交換されます。SSLが有効なブラウザとSSLが有効なサーバー間におけるSSL/TLSハンドシェイクの手順を次に示します。

1. ブラウザは、http://ではなくhttps://で始まるURLを送信し、サーバーへの接続を試みます。

2. サーバーがそのデジタル証明書(「証明書について」を参照)および公開鍵をクライアントに送信します。

3. クライアントは、サーバーの証明書が現行のものであるかどうか(つまり、失効していないか)、およびクライアントが信頼している認証局(CA)によって発行されたものかどうかをチェックします。

4. 証明書が有効な場合、クライアントは、1回限りの一意のセッション鍵を生成し、サーバーの公開鍵で暗号化して、その暗号化した鍵をサーバーに送信します。

5. サーバーは、秘密鍵を使用してクライアントからのメッセージを復号化し、セッション鍵を取得します。

この時点で、クライアントは、サーバー・アイデンティティを確認済となり、クライアントとサーバーのみが、クライアントが生成した一意のセッション鍵のコピーを持ちます。セッションが終了するまで、クライアントとサーバーはこの鍵を使用して、互いの間のすべての通信を暗号化します。

暗号について

暗号は、データの暗号化および復号化に使用されるアルゴリズムであり、数学関数です。暗号によって、強度や堅牢性は異なります。通常、暗号で使用されるビット数が多いほど、その暗号を使用して暗号化されたデータの復号化を難しくなります。

SSL v3およびTLS v1は、様々な暗号をサポートしています。サポートしているプロトコル、暗号化強度についての組織のポリシー、および暗号化されたソフトウェアに対する政府による輸出規制などの要因に応じて、クライアントおよびサーバーでサポートできる暗号スイートは異なります。

双方向の暗号プロセスでは、クライアントとサーバーは、同じ暗号スイートを使用する必要があります。SSL/TLSハンドシェイク・プロセス中、サーバーとクライアントは、通信に使用する暗号スイート(通常、最も強い暗号スイート)についてネゴシエートします。

鍵について

暗号を使用した暗号化、それ自体では、データのセキュリティは確保されません。実際に暗号化された結果を作成する、暗号化済の情報を復号化するには、暗号化する暗号とともに鍵を使用する必要があります。暗号化プロセスでは、公開鍵と秘密鍵の2つの鍵が使用されます。それぞれの鍵は数学的に関連しています。したがって、公開鍵を使用して暗号化された情報は、関連付けられた秘密鍵でのみ復号化でき、その逆も同様です。公開鍵は、証明書の一部として所有者によって公開されます(「証明書について」を参照)。関連付けられている秘密鍵のみが保護されます。

証明書について

証明書は、インターネット上の個人、会社またはその他のエンティティを一意に識別するデータの集合です。証明書を使用することで、2つのエンティティ間のセキュアで機密性の高い通信が可能になります。個人の証明書は、個人が使用するもので、サーバーの証明書は、サーバーとクライアント間でSSLを利用したセキュアなセッションを確立するために使用されます。

証明書は、(サーバーによって)自己署名されるか、認証局(CA)と呼ばれる信頼できるサードパーティによって署名されたものであるか、自分で生成したもののいずれかです。証明書の保有者は、アイデンティティの証明として証明書を提示し、暗号化された機密性の高い通信を確立できます。CAは、サードパーティ・ベンダー、または組織のサーバーに対して証明書を発行する社内の担当部門である場合があります。

証明書は、公開鍵による暗号化に基づいており、この暗号化では、鍵(非常に長い番号)のペアが使用され、目的の受信者のみが読み取れるように情報を暗号化します。受信者は、鍵の1つを使用して情報を復号化します。

証明書によって、所有者の公開鍵と所有者のアイデンティティがバインドされます。公開鍵に加えて、証明書には、通常次の情報が含まれます。

- 保有者の名前およびその他の識別情報(証明書を使用するサーバーのURLなど)

- 証明書を発行したCAの名前

- 発行したCAのデジタル署名

- 証明書の有効期間

10.2 Oracle Traffic Directorとオリジン・サーバー間のSSL/TLSの構成

この項では、SSL/TLSを使用して、Oracle Traffic Directorインスタンスと、Oracle WebLogic ServerおよびOracle HTTP Serverインスタンスであるオリジン・サーバー間の通信をどのように保護するかについて説明します。次の項目が含まれます。

- 10.2.1項「一方向および双方向のSSL/TLSについて」

- 10.2.2項「Oracle Traffic Directorとオリジン・サーバー間の一方向SSL/TLSの構成」

- 10.2.3項「Oracle Traffic Directorとオリジン・サーバー間の双方向SSL/TLSの構成」

- 10.2.4項「非SSL Oracle Traffic DirectorインスタンスからSSL Oracle Traffic Directorインスタンスへの変換」

10.2.1 一方向および双方向のSSL/TLSについて

Oracle Traffic Directorと、バック・エンドのオリジン・サーバー間の接続は、一方向または双方向のSSL/TLSを使用して保護できます。

- 一方向SSL/TLS: SSL/TLSが有効化されたオリジン・サーバーでは、証明書がOracle Traffic Directorインスタンスに提示されます。SSL/TLSハンドシェイク中、Oracle Traffic Directorインスタンスは証明書をオリジン・サーバーに提示するように構成されていません。

- 双方向SSL/TLS: SSL/TLSが有効化されたオリジン・サーバーでは、証明書がOracle Traffic Directorインスタンスに提示されます。Oracle Traffic Directorインスタンスも自身の証明書をオリジン・サーバーに提示します。オリジン・サーバーは、SSL/TLS接続を確立する前に、Oracle Traffic Directorインスタンスのアイデンティティを確認します。さらに、SSL/TLS接続の両端(Oracle Traffic Directorまたはオリジン・サーバー、あるいはその両方)が、証明書の交換中にホスト名を確認するように構成できます。

10.2.2 Oracle Traffic Directorとオリジン・サーバー間の一方向SSL/TLSの構成

Oracle Traffic Directorとオリジン・サーバー間の一方向SSL/TLSを構成するには、オリジン・サーバーの証明書をPKCS#12形式でエクスポートし、Oracle Traffic Directorの証明書データベースにインストールして、オプションで、その証明書を信頼するようにOracle Traffic Directorを構成します。

注意:

- この項で説明する手順は、オリジン・サーバー・プール内のすべてのサーバーが、同じCAが発行した証明書を使用しているというシナリオに沿っています。このようなシナリオでは、オリジン・サーバーの証明書に署名したCAのルート証明書を、Oracle Traffic Directorの証明書データベースにインポートするだけで、一方向のSSL/TLSを構成できます。

- オリジン・サーバーが自己署名証明書、または異なるCAが発行した証明書を使用している場合、各サーバーの証明書、またはサーバー証明書に署名したCAの各ルート証明書を個別にエクスポートおよびインポートする必要があります。

- Weblogic Server Fusion Middleware Controlからアクセス可能なWebLogic Server Plug-In Enabled属性がtrueに設定されていて、SSL接続がOracle Traffic Directorで終端する場合、Oracle Traffic Directorは、WebLogic Serverにデプロイされているアプリケーションに証明書情報を通知します。アプリケーションは、鍵サイズや暗号など証明書内の特定の情報を検証してから、クライアントにアプリケーションへのアクセスを許可します。

1. 証明書をオリジン・サーバーに発行したCAのルート証明書を、PKCS#12形式でエクスポートします。

- Oracle WebLogic Serverオリジン・サーバーの場合:
Java SE 6で使用可能なkeytoolコマンドを使用します。

構文:

> $JAVA_HOME/bin/keytool -exportcert -alias alias -file file -keystore keystore -storepass storepass -rfc

aliasはエクスポートされる証明書のニックネーム、fileはエクスポートされる証明書の名前、keystoreはカスタムのOracle WebLogic Serverアイデンティティ・ストア・ファイルの名前、storepassは指定したキーストアのパスワードです。

例:

> $JAVA_HOME/bin/keytool -exportcert -alias wlsos1 -file wls_os_cert
-keystore $DOMAIN_HOME/soa_domain/soa_keystore.jks -storepass stpass -rfc

keytoolの詳細は、次の場所にあるドキュメントを参照してください。

http://docs./javase/6/docs/technotes/tools/windows/keytool.html

- Oracle HTTP Serverオリジン・サーバーの場合:
exportWalletObject WebLogic Scripting Tool (WLST)コマンドを使用します。

構文:

exportWalletObject(instName, compName, compType, walletName, password, type, path, DN)

例:

> exportWalletObject('inst1', 'ohs1', 'ohs','wallet1', 'password', 'Certificate', '/tmp','cn=soa.example.com')

このコマンドでは、Oracle HTTP Serverインスタンスohs1について、DN cn=soa.example.comの証明書がウォレットwallet1からエクスポートされます。信頼できる証明書は、ディレクトリ/tmpにエクスポートされます。

exportWalletObjectコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportWalletobjectを参照してください。

2. importKeyStoreCertificate WLSTコマンドを使用して、エクスポートしたルート証明書をOracle Traffic Directorの証明書データベースにインストールします。

注意:
Fusion Middleware Controlを使用した証明書のインストールの詳細は、10.3.3項「証明書のインポート」を参照してください

構文:

-----BEGIN CERTIFICATE-----
(Server SSL certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root certificate)
-----END CERTIFICATE-----

例:

svc = getOpssService("KeyStoreService")
# generate a key pair with the proper DN
svc.generateKeyPair(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='', dn='CN=test., OU=Webtier, O=\'Oracle Corporation\', ST=California, C=US', keysize='1024')

注意:
オリジン・サーバーが自己署名証明書または異なるCAによって発行された証明書を使用している場合、手順1および2のかわりに次の操作を行います。

1. 手順1で使用した同じコマンドを使用して、各サーバー証明書、またはサーバー証明書に署名したCAの各ルート証明書をエクスポートします。

2. 手順2の説明に従い、importKeyStoreCertificate WLSTを使用して(ただし、--cert-type=serverを指定)、前の手順でエクスポートした各証明書をOracle Traffic Directorの証明書データベースにインストールします。

3. 必要に応じて、otd_setRouteProperties WLSTを使用して、オリジン・サーバーの証明書のホスト名を確認するようにOracle Traffic Directorを構成します。
構文:

otd_setRouteProperties(props)

例:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
props['websocket-idle-timeout'] = '1200'
otd_setRouteProperties(props)

構成内の仮想サーバーのリスト、および仮想サーバーに定義されているルートを表示するには、otd_listVirtualServersおよびotd_listRoutes WLSTコマンドをそれぞれ使用します。

注意:
SSL/TLSハンドシェイク中に、オリジン・サーバーの証明書のホスト名を検証するようにOracle Traffic Directorを構成することを選択した場合、次の操作を行う必要があります。

- オリジン・サーバーの証明書内のサーバー名(CN)が、Oracle Traffic Director構成のオリジン・サーバー・プールで指定されているオリジン・サーバーのホスト名と一致することを確認します。オリジン・サーバー・プールの構成の詳細は、第5章「オリジン・サーバー・プールの管理」を参照してください。

- 動的検出が無効化されていること(デフォルト設定)を確認してください。動的検出の詳細は、5.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。

そうでない場合、オリジン・サーバーがその証明書を提示した際、Oracle Traffic Directorは証明書のホスト名を検証できず、このためSSL/TLSハンドシェイクが失敗します。

10.2.3 Oracle Traffic Directorとオリジン・サーバー間の双方向SSL/TLSの構成

Oracle Traffic Directorとオリジン・サーバー間の双方向SSL/TLSを構成するには、次の操作を行います。

注意:
この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

1. 10.2.2項「Oracle Traffic Directorとオリジン・サーバー間の一方向SSL/TLSの構成」の説明に従い、一方向SSL/TLSを構成する手順を実行します。

2. 10.3.2項「CA署名証明書の取得」の説明に従い、CAによって発行されたOracle Traffic Directorのサーバー証明書を取得します。

3. 10.3.3項「証明書のインポート」の説明に従い、CAによって発行された証明書をOracle Traffic Director構成にインストールします。

4. otd_enableRouteAuth WLSTを使用して、Oracle Traffic Directorがオリジン・サーバーに提示する必要がある証明書を指定し、必要なOracle Traffic Directorルートを構成します。
構文:

otd_enableRouteAuth(props)

例:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
props['auth-user'] = 'baz'
props['auth-password'] = 'qux'
otd_enableRouteAuth(props)

構成内の仮想サーバーのリスト、および仮想サーバーに定義されているルートを表示するには、otd_listVirtualServersおよびotd_listRoutes WLSTコマンドをそれぞれ使用します。

5. activateコマンドを使用して、更新された構成をOracle Traffic Directorインスタンスにデプロイします。

pullComponentChanges(<instance_name>)

6. Oracle Traffic Directorインスタンスの証明書に署名したCAのルート証明書をキーストアからエクスポートします。
構文:

svc = getOpssService("KeyStoreService")
svc.exportKeyStoreCertificate(appStripe='<stripe>', name='<keystore>', password='<password>', alias='<alias>', type='<entrytype>', filepath='<absolute_file_path>')

svcはgetOpssService()の呼び出しを通じて取得されたサービス・コマンド・オブジェクト、appstripeはキーストアを含むストライプの名前、nameはキーストアの名前、passwordはキーストアのパスワード、aliasはエクスポートされるエントリの別名、typeはエクスポートされるキーストア・エントリのタイプです。有効な値は「証明書」、「信頼できる証明書」、または「証明書チェーン」であり、filepathは証明書、信頼できる証明書、または証明書チェーンがエクスポートされるファイルの絶対パスです。

例:

svc = getOpssService("KeyStoreService")
svc.exportKeyStoreCertificate(appStripe='OTD', name='myconfig', password='', alias='rootca', keypassword='', type='TrustedCertificate', filepath='/scratch/rootcert.txt')

exportKeyStoreCertificateコマンドの詳細は、次のコマンドを実行してください。

svc = getOpssService("KeyStoreService")
svc.help('exportKeyStoreCertificate')

7. 前の手順でエクスポートしたルート証明書を、Oracle WebLogic Serverオリジン・サーバー(およびOracle HTTP Serverオリジン・サーバーのOracleウォレット)の信頼キーストアにインポートします。

- Oracle WebLogic Serverオリジン・サーバーの場合:
Java SE 8で使用可能なkeytoolコマンドを使用します。

構文:

> $JAVA_HOME/bin/keytool -importcert -v -trustcacerts -alias alias
-file cert_file -keystore keystore_file -storepass keystore_password
-noprompt

aliasは前の手順でエクスポートされたCA発行のルートCAのニックネーム、fileはエクスポートされた証明書ファイルの名前、keystoreはカスタムのOracle WebLogic Serverアイデンティティ・ストア・ファイルの名前、storepassは指定したキーストアのパスワードです。

例:

> $JAVA_HOME/bin/keytool -importcert -v -trustcacerts -alias rootca1
-file /tmp/rootca1.pem -keystore $DOMAIN_HOME/soa_domain/soa_keystore.jks
-storepass stpass -noprompt

keytoolの詳細は、次の場所にあるドキュメントを参照してください。

http://docs./javase/8/docs/technotes/tools/windows/keytool.html

- Oracle HTTP Serverオリジン・サーバーの場合:
importWalletObject WLSTコマンドを使用します。

構文:

importWalletObject(instName, compName, compType, walletName, password, type, filePath)

例:

> importWalletObject('inst1', 'ohs1', 'ohs','wallet1', 'password', 'TrustedCertificate','/tmp/rootca1.pem')

importWalletObjectコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のimportwalletobjectを参照してください。

8. SSL/TLSハンドシェイク中にOracle Traffic Directorにそのクライアント証明書の提示を要求するように、オリジン・サーバーを構成します。

- Oracle WebLogic Serverオリジン・サーバーの場合:
Oracle WebLogic Server Fusion Middleware Controlオンライン・ヘルプの双方向SSLの構成に関する項で説明されている手順を実行します。

注意:
Oracle WebLogic Serverでは、デフォルトでホスト名の確認が有効化されています。ホスト名検証の無効化の詳細は、Oracle WebLogic Server Fusion Middleware Controlオンライン・ヘルプのホスト名検証の無効化に関する項を参照してください。

- Oracle HTTP Serverオリジン・サーバーの場合:
httpd.confファイルに次のディレクティブを追加します。

SSLVerifyClient require

10.2.4 非SSL Oracle Traffic DirectorインスタンスからSSL Oracle Traffic Directorインスタンスへの変換

非SSL Oracle Traffic DirectorインスタンスをSSL Oracle Traffic Directorインスタンスに変換するには、次を実行します。

1. Oracle Fusion Middlewareの管理の「ウォレットの作成」の説明に従って、ウォレットを作成します。

2. Oracle Fusion Middlewareの管理の「証明書または信頼できる証明書のインポート」の説明に従って、必要なルート証明書、中間証明書、サーバー証明書をウォレットにインポートします。

3. 9.1項「リスナーの作成」の説明に従って、ポート4443の新しいHTTPSリスナーを作成します。

4. 4.3項「Oracle Traffic Directorインスタンスの起動、停止および再起動」の説明に従って、サービスを再起動します。

10.3 証明書の管理

この項は、次の項目を含んでいます。

- 10.3.1項「鍵ペアの生成」

- 10.3.2項「CA署名証明書の取得」

- 10.3.3項「証明書のインポート」

- 10.3.4項「証明書のリストの表示」

- 10.3.5項「サーバー証明書の更新」

- 10.3.6項「証明書の削除」

注意:

- この項の情報は、SSL、証明書、暗号および鍵の概念を熟知している読者を対象としています。これらの概念の基本的な情報については、10.1.7項「SSL/TLSの概念」を参照してください。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

10.3.1 鍵ペアの生成

証明書にCAによる署名が必要ない場合、またはデモ用のCA証明書によるCA署名処理でSSL/TLSの実装をテストする場合は、鍵ペアを生成できます。

鍵ペアを使用してOracle Traffic Director仮想サーバーのSSL/TLSを有効にしている場合、クライアントが仮想サーバーのhttps://のURLにアクセスすると、署名しているCAが不明であり信頼できないことを示すエラー・メッセージが表示されます。接続を続行するために、クライアントは、自己署名証明書を信頼するように選択できます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、鍵ペアを生成できます。

始める前に

鍵ペアの生成を開始する前に、次のことを決定します。

- 鍵ペアのニックネーム(鍵ペアの生成のみに必要)。

- 鍵のタイプ(RSAまたはECC)。
Oracle Traffic Directorは、従来のRSAタイプの鍵、およびより高度な楕円曲線暗号(ECC)鍵の生成をサポートしています。ECCは、演算処理の高速化、電力消費の低減およびメモリーと帯域幅の節約を図れる、小さいサイズの鍵と同等のセキュリティを提供します。

- 鍵サイズ(RSA)または曲線(ECC)。
RSA鍵では、512、1024、2048または4096ビットを指定できます。鍵の桁が多いほど、暗号化の強度は向上しますが、Oracle Traffic Directorは生成するのにより長い時間を必要とします。

ECCでは、鍵のペアを生成するための曲線を指定する必要があります。Oracle Traffic Directorでは、次の曲線がサポートされています: 163(sect163r2)、192(secp192r1)、224(secp224r1)、233(sect233k1)、256(secp256r1)、283(sect283k1)、384(secp384r1)、409(sect409k1)、521(secp521r1)、571(sect571k1)。

Fusion Middleware Controlを使用した鍵ペアの生成

Fusion Middleware Controlを使用して自己署名証明書を作成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 自己署名証明書を作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「セキュリティ」→「証明書の管理」を選択します
画面に新しいページが表示されます。

7. 「共通タスク」バーにある「鍵ペアの生成」ボタンをクリックします。
新規の鍵ペアの生成ウィザードが開きます。

図10-1 新規鍵ペアの生成ウィザード

8. 「OK」をクリックします。証明書リスト内に新規証明書が表示されます。

9. 証明書の別名をクリックして証明書の詳細を表示します

鍵ペアは、デモ用のCA署名証明書でラップされ、トラスト・ストアに格納されています。アプリケーションでトラスト・ストアを使用していない場合は、デモ用のCA証明書をカスタム・キーストアにインポートする必要があります。

WLSTを使用した鍵ペアの生成

鍵ペアを生成するには、次の例に示すように、generateKeyPairコマンドを実行します。

svc = getOpssService("KeyStoreService")
svc.generateKeyPair(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='',dn='CN=test., OU=Webtier, O=\'Oracle Corporation\', ST=California, C=US', keysize='1024')

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

generateKeyPairの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.3.2 CA署名証明書の取得

認証局(CA)によって署名された証明書を取得するには、「証明書署名リクエスト(CSR)」をCAに送信し、必要に応じて規定の料金を支払ったら、CAによってリクエストが承認され証明書が付与されるのを待ちます。

CSRは、サーバー名、組織名、国などの情報を含むデジタル・ファイル(Base-64でエンコーディングされたPEM形式の暗号化済テキスト・ブロック)です。また、証明書に含められる公開鍵も含まれます。

Oracle Traffic DirectorのFusion Middleware ControlまたはWLSTのいずれかを使用して、CSRを生成できます。

Fusion Middleware Controlを使用したCSRの生成

Fusion Middleware Controlを使用してCSRを生成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. CSRを作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「セキュリティ」→「証明書の管理」を選択します
画面に新しいページが表示されます。

7. 使用可能な証明書のリストが表示されます。
CSRを生成する証明書を選択します。

8. 「共通タスク」ペインにある「CSRの生成」ボタンをクリックします。
「CSRの生成」をエクスポートできる新規ウィンドウが表示されます。

9. 「CSRのエクスポート」画面上のプロンプトに従い、「CSRのエクスポート」をクリックしてそのコピーを保存し、「閉じる」をクリックします

これで、選択したCAに証明書の署名料金とともにCSRを送信できるようになりました。

WLSTを使用したCSRの生成

CSRを生成するには、次の例に示すように、exportKeyStoreCertificateRequestコマンドを実行します。

# generate the CSR and put it in to a text file
svc.exportKeyStoreCertificateRequest(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='', filepath='/scratch/certreq.crt')

このコマンドによりCSRが生成され、Fusion Middleware Controlを使用した鍵ペアの生成に示すようなCSRの暗号化されたテキストが表示されます。

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

exportKeyStoreCertificateRequestの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

作成したCSRに対応するCA署名証明書を取得した後、10.3.3項「証明書のインポート」の説明に従い、適切な構成に証明書をインポートする必要があります。

10.3.3 証明書のインポート

Fusion Middleware ControlまたはWLSTのいずれかを使用して、生成した鍵ペアまたはCA署名証明書をインポートできます。

この項は、次の項目を含んでいます。

- Fusion Middleware Controlを使用した証明書のインポート

- WLSTを使用した証明書のインポート

Fusion Middleware Controlを使用した証明書のインポート

Fusion Middleware Controlを使用して証明書または信頼できる証明書をインポートするには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 証明書をインポートする構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「セキュリティ」→「証明書の管理」を選択します
画面に新しいページが表示されます。

7. 「インポート」ボタンをクリックします。
図10-2に示す、証明書のインポート・ウィザードが開きます。

図10-2 証明書のインポート

8. 「証明書タイプ」ドロップダウンから、「証明書」、「信頼できる証明書」、または「証明書チェーン」を選択します。

注意:

- 自己署名証明書をインポートしている場合は、「証明書タイプ」ドロップダウンから「信頼できる証明書」を選択します。

- CA署名証明書をインポートしている場合は、「証明書タイプ」ドロップダウンから「証明書チェーン」を選択します。

- 証明書チェーンをインポートしている場合、CAから取得した証明書チェーンがPKCS7形式で作成されていることを確認します。

9. 証明書または証明書チェーンをインポートしている場合は、ドロップダウンから「別名」を選択します。信頼できる証明書をインポートしている場合は、「別名」の名前を指定します。

10. 証明書ソースを指定します。貼付けオプションを使用する場合は、証明書をコピーして直接テキスト・フィールドに貼り付けます。ファイルの選択オプションを使用する場合は、「参照」をクリックしてオペレーティング・システムからファイルを選択します。

11. 「OK」をクリックします。インポートされた証明書または信頼できる証明書が、証明書の一覧に表示されます。

WLSTを使用した証明書のインポート

証明書をインポートするには、次の例に示すように、importKeyStoreCertificateコマンドを実行します。

svc.importKeyStoreCertificate(appStripe='OTD', name='myconfig', password='', alias='ca-cert', keypassword='', type='Certificate', filepath='/scratch/cacert.crt')

証明書チェーンをインポートするには、次の例に示すように、importKeyStoreCertificateコマンドを実行します。

svc.importKeyStoreCertificate(appStripe='TEST_STRIPE',name='sample',password='welcome1', alias='test_cert', keypassword='welcome1',type='CertificateChain',filepath='/scratch/mwport/rpolavar/CERTS/testCertChain.crt')

このコマンドでは、構成soaにニックネームsoa-certでサーバー証明書がインストールされます。CA証明書をインストールするには、--cert-typeオプションでcaを指定します。

注意:
証明書チェーンをインポートしている場合、CAから取得した証明書チェーンがPKCS7形式で作成されていることを確認します。

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

importKeyStoreCertificateの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.3.4 証明書リストの表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成にインストールされている証明書のリストを表示できます。

Fusion Middleware Controlを使用した証明書のリストの表示

Fusion Middleware Controlを使用して構成にインストールされている証明書のリストを表示するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 証明書を表示する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「セキュリティ」→「証明書の管理」を選択します
画面に新しいページが表示されます。

7. 「共通タスク」バーの下に証明書のリストが表示されます。

WLSTを使用した証明書のリストの表示

- 構成にインストールされている証明書のリストを表示するには、次の例に示すように、otd_listCertificatesコマンドを実行します。

- 次のコマンドでは、構成のサーバー証明書のリストが表示されます。

props = {}
props['configuration'] = 'foo'
otd_listCertificates(props)

- 証明書のプロパティを表示するには、次の例に従い、getKeyStoreCertificatesコマンドを実行します。

svc = getOpssService("KeyStoreService")
svc.getKeyStoreCertificates(appStripe='OTD', name='myconfig', password='', alias='mycert')

注意:
指定した構成でPINがトークンに対して有効化されている場合、otd_listCertificatesおよびgetKeyStoreCertificatesコマンドを実行する際に、トークンPINを入力するプロンプトが表示されます。

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.3.5 サーバー証明書の更新

証明書を更新するには、次の操作を行います。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 証明書を更新する構成を選択します。

4. ナビゲーション・ペインで、「SSL」を展開し、「サーバー証明書」を選択します。
結果のページに、インストールされているサーバー証明書が表示されます。

注意:
選択した構成でトークンに対してPINが有効化されている場合、インストールされている証明書は表示されません。かわりに、トークンのPINを入力するメッセージがページに表示されます。

1. 「トークンPINのキャッシュ」をクリックします。

2. 表示されたダイアログ・ボックスで、トークンのPINを入力し、「OK」をクリックします。

5. 更新する証明書の「更新」ボタンをクリックします。
「サーバー証明書の更新」ダイアログ・ボックスが表示されます。

6. 新しい有効期間を指定し、「次」をクリックします。

7. 「証明書の更新」をクリックします。

8. 「閉じる」をクリックします。

- 「コンソール・メッセージ」ペインに、指定した期間に対して証明書が更新されたことを確認するメッセージが表示されます。

- 証明書の新しい有効期限が、「サーバー証明書」ページに表示されます。

10.3.6 証明書の削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成内の証明書を削除できます。

Fusion Middleware Controlを使用した証明書の削除

Fusion Middleware Controlを使用して構成内の証明書を削除するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 証明書を削除する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「セキュリティ」→「証明書の管理」を選択します
画面に新しいページが表示されます。

7. 「共通タスク」バーの下に証明書のリストが表示されます。

8. 削除する証明書の「削除」ボタンをクリックします。

- 1つ以上のリスナーが削除中の証明書と関連付けられている場合、その証明書を削除できないことを示すメッセージが表示されます。

- 削除中の証明書が、いずれのリスナーにも関連付けられていない場合、証明書の削除を確認するプロンプトが表示されます。
「OK」をクリックして進みます。

「コンソール・メッセージ」ペインに、証明書が削除されたことを確認するメッセージが表示されます。

WLSTを使用した証明書の削除

証明書を削除するには、deleteKeyStoreEntryコマンドを実行します。

例:

svc = getOpssService("KeyStoreService")
svc.deleteKeyStoreEntry(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='')

削除しようとしている証明書が1つ以上のリスナーに関連付けられている場合、次のメッセージが表示されます。

OTD-64309 Certificate 'rsa-1' is being referred by listeners: listener1,listenerN

--forceオプションを指定することで、証明書を強制的に削除できます。

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

deleteKeyStoreEntryの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.4 証明書失効リストの管理

証明書失効リスト(CRL)は、CAが証明書の期限が切れる前に失効させることを決定した証明書についてCAがユーザーに通知するために発行するリストです。CRLは定期的に更新され、更新されたCRLはCAのWebサイトからダウンロードできます。

Oracle Traffic Directorサーバーが、CAが失効させた証明書を信頼しないようにするために、最新のCRLをCAから定期的にダウンロードし、Oracle Traffic Director構成にインストールしておく必要があります。

CRLは手動でインストールできます。また、ダウンロード済のCRLを指定したディレクトリから指定の間隔で自動的に取得しインストールするようにOracle Traffic Directorを構成できます。

この項は、次の項目を含んでいます。

- 10.4.1項「CRLの手動によるインストールおよび削除」

- 10.4.2項「CRLの自動更新」

注意:

- この項の情報は、SSL、証明書、暗号および鍵の概念を熟知している読者を対象としています。これらの概念の基本的な情報については、10.1.7項「SSL/TLSの概念」を参照してください。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

10.4.1 CRLの手動によるインストールおよび削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、CRLを手動でインストールおよび削除できます。

Fusion Middleware Controlを使用したCRLの手動インストール

Fusion Middleware Controlを使用してダウンロードされたCRLをインストールするには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 証明書をインストールする構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「セキュリティ」→「証明書失効リスト」を選択します
画面に新しいページが表示されます。

7. 「CRLのインストール」ボタンをクリックします。
「証明書失効リストのインストール」ダイアログ・ボックスが表示されます。

8. ダウンロードしたCRLファイルの場所を指定し、「CRLのインストール」をクリックします。

- CRLのインストールが成功したことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- インストールしたCRLは、「認証局」ページに表示されます。

WLSTを使用したCRLの手動によるインストールおよび削除

- ダウンロードされたCRLをインストールするには、次の例に示すように、otd_installCrlコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['file-path'] = '/export/ServerSign.crl'
otd_installCrl(props).

- 構成にインストールされているCRLのリストを表示するには、次の例に示すように、otd_listCrlsコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_listCrls(props)
---------------------------
"Class 1 Public Primary Certification Authority" "Sat Apr 15 16:59:59 PDT 2000"
"VeriSign Class 3 Code Signing 2010 CA" "Mon Aug 29 14:00:03 PDT 2011"
"VeriSign Class 3 Organizational CA" "Sun May 18 13:48:16 PDT 2014"

- CRLを削除するには、次の例に示すように、otd_deleteCrlコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['issuer'] = 'CN=GlobalSign ServerSign CA,OU=ServerSign CA,O=GlobalSign nv-sa,C=BE'
otd_deleteCrl(props)

CRLを削除すると、CRLはOracle Traffic Director構成、およびダウンロードされたCRLが格納されているディレクトリから削除されます。

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.4.2 CRLの自動更新

Fusion Middleware ControlまたはWLSTのいずれかを使用して、ダウンロードされたCRLファイルが指定したディレクトリから定期的に取得され、自動的にインストールされるようにOracle Traffic Directorを構成できます。

Oracle Traffic Directorは、指定されたディレクトリ上の更新されたCRLファイルを、指定された間隔で検索します。

- Oracle Traffic Directorは、新しいCRLファイルを検出した場合、そのファイルを構成にインストールし、サーバー・ログにメッセージを記録します。

- 既存のCRLファイルが変更された場合、Oracle Traffic Directorは、更新されたCRLファイルを構成にインストールし、サーバー・ログにメッセージを記録します。

- Oracle Traffic Directorが、前にインストール済のCRLファイルがディレクトリから削除されていることを検出すると、構成からCRLを削除し、サーバー・ログにメッセージを記録します。

- CRLディレクトリで変更が検出されない場合、Oracle Traffic Directorは更新を実行しません。

Fusion Middleware Controlを使用したOracle Traffic DirectorにおけるCRLの自動インストールの構成

Fusion Middleware Controlを使用して、CRLを自動的にインストールするようにOracle Traffic Directorを構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. CRLを自動的にインストールするように設定する構成の名前をクリックします。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「セキュリティ」→「証明書失効リスト」を選択します
画面に新しいページが表示されます。

7. 「CRLのインストール」ボタンをクリックします。
「証明書失効リストのインストール」ダイアログ・ボックスが表示されます。

8. ダウンロードしたCRLファイルの場所を指定し、「CRLのインストール」をクリックします。

- CRLのインストールが成功したことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- インストールしたCRLは、「認証局」ページに表示されます。

9. ページの「詳細設定」セクションに移動します。

10. 「CRL更新イベント」フィールドに、更新されたCRLファイルを含むディレクトリへの絶対パスを入力します。

11. 「新規イベント」をクリックします。
「新規CRL更新イベント」ダイアログ・ボックスが表示されます。

12. CRLを更新する間隔または時刻を指定し、「OK」をクリックします。

- イベントの作成を確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- 新規イベントが「CRL更新イベント」リストに表示されます。

- 新しいイベントはデフォルトで有効になっています。ステータスを変更するには、「有効化/無効化」チェック・ボックスを選択します。

- イベントを削除するには、「削除」ボタンをクリックします。

WLSTを使用したOracle Traffic DirectorにおけるCRLの自動インストールの構成

CRLを自動的にインストールするようにOracle Traffic Directorを構成するには、次の操作を行います。

1. otd_createEventコマンドを使用して、Oracle Traffic Directorにより、ダウンロードされたCRLが指定されたディレクトリから取得され、自動的にインストールされるようにイベントをスケジュールします。
たとえば、次のコマンドでは、構成fooのCRLは毎日12時に更新されます。

props = {}
props['configuration'] = 'foo'
props['event'] = 'event-1'
props['command'] = 'update CRL'
props['time'] = '12:00'
otd_createEvent(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.5 Webアプリケーション・ファイアウォールの管理

Webアプリケーション・ファイアウォール(WAF)とは、HTTPリクエストにルール・セットと呼ばれる一連のルールを適用するフィルタまたはサーバー・プラグインのことです。Webアプリケーション・ファイアウォールは、攻撃を検知および阻止するためにセキュリティ・レイヤーを強化する手段として役立ちます。これはオリジン・サーバー内にホストされているアプリケーションのファイアウォールとして機能します。また、管理者がヘッダーや本文などHTTPリクエストの任意の部分を調査したり、条件を構成しHTTPリクエストがその条件に基づいて許可または拒否されるように設定することもできます。

Webアプリケーション・ファイアウォール・モジュールには無償のバージョンと商用バージョンがあります。Oracle Traffic DirectorのWebアプリケーション・ファイアウォール・モジュールはModSecurity 2.8をサポートしています。これはWebアプリケーション用の侵入検知およ防止エンジンです。ModSecurityのルール・セットはカスタマイズ可能で、クロスサイト・スクリプティング(XSS)やSQLインジェクションなどの一般的な攻撃からアプリケーションを保護できます。HTTPヘッダー、環境変数およびCGI変数などの様々な条件に基づき、ModSecurityは受信リクエストにフィルタを適用して拒否します。ModSecurityの詳細は、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Introductionを参照してください。

様々な企業がModSecurity用のルール・セットを提供していますが、Oracle Traffic Directorはオープンソース・アプリケーション・セキュリティ・プロジェクトであるOpen Web Application Security Project (OWASP)によるテストを受けた製品であり、最も使用されているルール・セット・プロバイダの1つです。詳細は、https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Projectを参照してください。

この項では、次の項目について説明します。

- 10.5.1項「Webアプリケーション・ファイアウォールの概要」

- 10.5.2項「Webアプリケーション・ファイアウォールの構成」

- 10.5.3項「ルール・セット・ファイルのリスト表示」

- 10.5.4項「ルール・セット・ファイルの削除」

- 10.5.5項「サポートされているWebアプリケーション・ファイアウォールのディレクティブ、変数、演算子、アクション、関数、永続ストレージおよびフェーズ」

10.5.1 Webアプリケーション・ファイアウォールの概要

Oracle Traffic Directorを使用すると、構成内の各仮想サーバーに対してWebアプリケーション・ファイアウォールを有効化(または無効化)できます。これはルール・セットを適用し、オリジン・サーバーにデプロイされているWebアプリケーションのファイアウォールとして機能します。オリジン・サーバーおよび仮想サーバーの詳細は、第6章「オリジン・サーバーの管理」および第7章「仮想サーバーの管理」をそれぞれ参照してください。

Oracle Traffic Directorはルール・セットを仮想サーバー・レベルと構成レベルの両レベルでサポートしています。仮想サーバー・レベルで定義されたルールは、構成レベルで定義されたルールよりも優先されます。デプロイすると、これらのルールと構成変更がインスタンスにプッシュされ、インスタンスが再構成されます。Webアプリケーション・ファイアウォールの動作の詳細は、付録B「Webアプリケーション・ファイアウォールの例とユースケース」を参照してください。

10.5.2 Webアプリケーション・ファイアウォールの構成

Webアプリケーション・ファイアウォールを構成するには、オープン・ソースのWebアプリケーション・ファイアウォールのルール・セットをダウンロードするか、独自のルール・セットを作成します。たとえば、OWASPリポジトリからModSecurity Core Rule Set (CRS)をダウンロードし、ルール・セットを任意のフォルダに解凍します。Oracle Traffic Directorは次のディレクトリ内にあるルールをサポートしています。

- base_rules

- optional_rules

- slr_rules

注意:
Webアプリケーション・ファイアウォールでは、OWASP ModSecurityコア・ルール・セットのディレクトリbase_rules、optional_rulesおよびslr_rulesにある構成で使用されるModSecurity 2.8ディレクティブをサポートしています。ただし、<IfDefine...>や<Location...>などのApacheコア構成ディレクティブや、RequestHeaderやHeaderなど、その他のApacheモジュールでサポートされているディレクティブはサポートしていません。

注意:
Webアプリケーション・ファイアウォールのルール・ファイルをインストールする前に、すべての依存ファイルがインストールされていることを確認します。そうでない場合、Webアプリケーション・ファイアウォールのルール・ファイルのインストールは失敗します。

前述のディレクトリを解凍した後、これらのディレクトリ内のファイルを編集して、管理サーバーにアップロードできます。これらのルール・セット・ファイルをデプロイすると、Oracle Traffic Directorインスタンスにプッシュされます。詳細は、10.5.2.1項「Webアプリケーション・ファイアウォール・ルール・セットの有効化とインストール」を参照してください。

注意:

- configディレクトリの外部にあるディレクトリからルール・セット・ファイルを取得するようサーバーを構成することもできますが、この場合ルール・ファイルの管理がサポートされなくなります。Oracle Traffic Directorを高可用性構成にする場合は、Webアプリケーション・ファイアウォール・ルール・セットをconfigディレクトリに格納することをお薦めします。

- サポートされていないディレクティブ、変数、演算子、アクション、フェーズ、関数およびストレージを使用すると、サーバーの起動エラーの原因になります。たとえば、ルール・セット・ファイルmodsecurity_crs_42_tight_security.confを、非サポートのアクションverを削除せずにインストールすると、サーバーの起動時にOracle Traffic Directorによって次のエラー・メッセージが表示されます。

[ERROR:16] [OTD-20016] Syntax error on line 20 of /scratch/rgoutham/instance1/net-config1/config/ruleset/config1/modsecurity_crs_42_tight_security.conf:
[ERROR:16] [OTD-20016] Error parsing actions: Unknown action: ver
[ERROR:32] [OTD-20008] Failed to parse VS webapp-firewall-ruleset (ruleset/config1/*.conf)
[ERROR:32] [OTD-10422] Failed to set configuration
[ERROR:32] server initialization failed

このエラーを回避するには、ルール・セット・ファイルを編集し、サポートされていないディレクティブ、変数、演算子、アクション、フェーズ、関数およびストレージを削除またはコメント・アウトしてからサーバーを起動します。

10.5.2.1 Webアプリケーション・ファイアウォール・ルール・セットの有効化とインストール

Fusion Middleware ControlまたはWLSTのいずれかを使用して、Webアプリケーション・ファイアウォールのルール・セットを有効化およびインストールできます。

注意:

- Webアプリケーション・ファイアウォール・ルール・セットの有効化とインストールは、実質的には構成の変更を意味します。新規ルール・セットをOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したWebアプリケーション・ファイアウォールのルール・セットの有効化およびインストール

Fusion Middleware Controlを使用して仮想サーバーにWebアプリケーション・ファイアウォールを構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. Webアプリケーション・ファイアウォールを構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「Webアプリケーション・ファイアウォール」を選択します

7. 「Webアプリケーション・ファイアウォール」ページが表示されます。

1. 「ルール・セット・ファイルのインストール」をクリックします。
「ルール・セット・ファイルのインストール」ダイアログ・ボックスで、ルール・セット・ファイルを解凍したフォルダを参照しルール・セット・ファイルを選択するか、ルール・セット・ファイルがある場所までの完全パスを入力します。複数のルール・セット・ファイルをインストールする場合は、1度に1つずつインストールします。

1つ以上のルール・セット・ファイルをインストールすると、「ルール・セット・パターン」フィールドに次のテキストが追加されます。

ruleset/<virtual-server-id>/*.conf

注意:

- 構成レベルでルール・セット・ファイルをインストールすると、ルール・セット・パターンが次のように表示されます。

ruleset/*.conf

- 必要であれば、カスタム・ルール・セット・パターンを追加できます。しかし、ruleset/<virtual-server-id>ディレクトリ(仮想サーバー・レベルの場合)またはrulesetディレクトリ(構成レベルの場合)の外部にあるルール・セットは、Oracle Traffic DirectorのFusion Middleware ControlまたはWLSTを使用して表示や削除はできません。これらのルール・セットは手動で管理する必要があります。

WLSTを使用したWebアプリケーション・ファイアウォールの有効化

WLSTを使用してWebアプリケーション・ファイアウォールを有効にするには、otd_enableWebAppFirewallコマンドを実行します。

たとえば、次のコマンドを実行すると、構成fooにある仮想サーバーbarでWebアプリケーション・ファイアウォールが有効になります。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_enableWebappFirewall(props)

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

otd_enableWebAppFirewallの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

WLSTを使用したWebアプリケーション・ファイアウォールのルール・セットのインストール

WLSTを使用してWebアプリケーション・ファイアウォールのルール・セットをインストールするには、otd_installVirtualServerWebappFirewallRulesetFileコマンドを実行します。

たとえば、次のコマンドを実行すると、構成fooにある仮想サーバーbarにWebアプリケーション・ファイアウォールのルール・セットmodsecurity_crs_20_protocol_violations.confがインストールされます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['file-path'] = '/export/rulesets/baz.conf'
otd_installVirtualServerWebappFirewallRulesetFile(props)

構成レベルでWebアプリケーション・ファイアウォールのルール・セットをインストールするには、otd_installWebappFirewallRulesetFileコマンドを実行します。たとえば、次のコマンドを実行すると、構成fooにWebアプリケーション・ファイアウォールのルール・セットmodsecurity_crs_50_outbound.confがインストールされます。

props = {}
props['configuration'] = 'foo'
props['file-path'] = '/export/rulesets/baz.conf'
otd_installVirtualServerWebappFirewallRulesetFile(props)

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

otd_installWebappFirewallRulesetFileおよびotd_installVirtualServerWebappFirewallRulesetFileの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

注意:
otd_setConfigurationPropertiesおよびotd_setVirtualServerPropertiesコマンドを使用して、構成レベルおよび仮想サーバー・レベルのぞれぞれで、otd_deleteWebappFirewallRulesetFile/otd_deleteVirtualServerWebappFirewallRulesetFileプロパティの値を設定できます。詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

10.5.3 ルール・セット・ファイルのリスト表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、ルール・セット・ファイルのリストを表示できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したルール・セット・ファイルのリストの表示

Fusion Middleware Controlを使用してルール・セット・ファイルのリストを表示するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. ルール・セット・ファイルを表示する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「Webアプリケーション・ファイアウォール」を選択します

7. 「Webアプリケーション・ファイアウォール」ページの「ルール・セット・ファイル」表に、インストール済のルール・セット・ファイルがリストされます。これらのファイルの内容を確認するには、クリックして個々のルール・ファイルを選択するか、「名前」チェック・ボックスを選択してすべてのルール・ファイルを選択します。

8. 「表示」をクリックします。
各ルール・ファイルの内容が「ルール・セット・ファイルの内容」ウィンドウに表示されます。

WLSTを使用したルール・セット・ファイルのリストの表示

CLIを使用して個々のルール・セット・ファイルの内容を表示することはできませんが、インストール済のルール・セット・ファイルのリストを表示することは可能です。ルール・セット・ファイルのリストを表示するには、otd_listVirtualServerWebappFirewallRulesetFilesコマンドを実行します。

たとえば、次のコマンドを実行すると、構成fooにある仮想サーバーbarにインストールされているWebアプリケーション・ファイアウォールのルール・セット・ファイルがリストされます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listVirtualServerWebappFirewallRulesetFiles(props)

構成レベルでインストールされているWebアプリケーション・ファイアウォールのルール・セットのリストを表示するには、otd_listWebappFirewallRulesetFilesコマンドを実行します。たとえば、次のコマンドを実行すると、構成fooに構成レベルでインストールされているWebアプリケーション・ファイアウォールのルール・セットがリストされます。

props = {}
props['configuration'] = 'foo'
otd_listVirtualServerWebappFirewallRulesetFiles(props)

otd_getWebappFirewallPropertiesコマンドを実行すると、Webアプリケーション・ファイアウォールのプロパティを表示できます。

otd_listWebappFirewallRulesetFiles、otd_listVirtualServerWebappFirewallRulesetFilesおよびotd_getWebappFirewallPropertiesコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.5.4 ルール・セット・ファイルの削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、ルール・セット・ファイルを削除できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したルール・セット・ファイルの削除

特定の仮想サーバーのルール・セット・ファイルを削除するには、次の操作を行います。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. ルール・セット・ファイルを削除する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「Webアプリケーション・ファイアウォール」を選択します

7. 「Webアプリケーション・ファイアウォール」ページで、個々のルール・ファイルをクリックして選択するか、「名前」チェック・ボックスを選択してすべてのルール・ファイルを選択します。

8. 「削除」ボタンをクリックします。確認プロンプトで、「OK」です。
「コンソール・メッセージ」ペインに、ルール・セット・ファイルが削除されたことを確認するメッセージが表示されます。

WLSTを使用したルール・セット・ファイルの削除

特定の仮想サーバーのルール・セット・ファイルを削除するには、次の例に示すように、otd_deleteVirtualServerWebappFirewallRulesetFileコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['ruleset-file'] = 'baz.conf'
otd_deleteVirtualServerWebappFirewallRulesetFile(props)

ルール・セット・ファイルを削除するには、次の例に示すように、otd_deleteWebappFirewallRulesetFileコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['ruleset-file'] = 'baz.conf'
otd_deleteVirtualServerWebappFirewallRulesetFile(props)

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

otd_deleteWebappFirewallRulesetFile、otd_deleteVirtualServerWebappFirewallRulesetFileの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

注意:
otd_disableWebAppFirewallコマンドを使用してWebアプリケーション・ファイアウォールを無効にできます。詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

10.5.5 サポートされているWebアプリケーション・ファイアウォールのディレクティブ、変数、演算子、アクション、関数、永続ストレージおよびフェーズ

Oracle Traffic Directorでは様々なModSecurity 2.8のディレクティブ、変数、演算子、アクション、関数、永続ストレージおよびフェーズがサポートされています。

サポートされているWebアプリケーション・ファイアウォール・ディレクティブ

Oracle Traffic Directorでは次のModSecurity 2.8ディレクティブがサポートされています。ModSecurityディレクティブの詳細およびディレクティブのリスト(サポートされていないディレクティブを含む)は、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Configuration_Directivesを参照してください。

SecAction
SecArgumentSeparator
SecAuditEngine
SecAuditLog
SecAuditLog2
SecAuditLogDirMode
SecAuditLogFileMode
SecAuditLogParts
SecAuditLogRelevantStatus
SecAuditLogStorageDir
SecAuditLogType
SecComponentSignature
SecContentInjection
SecCookieFormat
SecDataDir (see note below)
SecDebugLog
SecDefaultAction
SecDebugLogLevel
SecGeoLookupDb
SecInterceptOnError
SecMarker
SecPcreMatchLimit (see note below)
SecPcreMatchLimitRecursion (see note below)
SecRequestBodyAccess
SecRequestBodyInMemoryLimit (see note below)
SecRequestBodyNoFilesLimit (see note below)
SecRequestBodyLimitAction
SecResponseBodyAccess
SecResponseBodyLimit
SecResponseBodyLimitAction (see note below)
SecResponseBodyMimeType
SecResponseBodyMimeTypesClear
SecRule
SecRuleEngine (see note below)
SecRuleRemoveById
SecRuleRemoveByMsg
SecRuleRemoveByTag
SecRuleUpdateActionById
SecRuleUpdateTargetById
SecTmpDir
SecUnicodeMapFile (see note below)
SecUnicodeCodePage (see note below)
SecUploadDir
SecUploadFileLimit
SecUploadFileMode
SecUploadKeepFiles
SecWebAppId (see note below)
SecCollectionTimeout

注意:

- SecWebAppIdは仮想サーバー固有のWebアプリケーション・ファイアウォール構成ファイル内で指定できます。アプリケーション・ネームスペースを特定の仮想サーバーに関連付けることができます。

- SecRequestBodyLimitActionディレクティブを使用して、SecRequestBodyNoFilesLimitにヒットしたリクエストに対してアクションを設定できます。しかし、SecRequestBodyLimitディレクティブはOracle Traffic Directorではサポートされていないため、このディレクティブにアクションを設定することはできません。

- Oracle Traffic DirectorではSecRequestBodyLimitディレクティブがサポートされていません。これは、ModSecurityでバッファする最大リクエスト本文サイズを構成するときに使用するディレクティブです。このディレクティブのかわりに、次のオプションを使用できます。
オプション1: SecRequestBodyNoFilesLimitディレクティブおよびSecRequestBodyLimitActionディレクティブを使用します。例:

SecRequestBodyNoFilesLimit 100
SecRequestBodyLimitAction Reject

オプション2: 拒否動作を設定するため、リクエストのContent-Lengthヘッダーをチェックするようにobj.confでOracle Traffic Directorを構成します。さらに、max-unchunk-size値をserver.xmlで設定できます。

同様に、ProcessPartial動作を設定するため、server.xmlでbody-buffer-size要素に適切な制限値を設定できます。この場合、制限に収まる本文の最初の部分のみが処理され、残りの部分は通過します。

- webapp-firewall-ruleset要素で指定された構成ファイル内でSecRuleEngineディレクティブが指定されている場合、これは無視されます。ただし、SecRuleEngineがDetectionOnlyモードに設定されている場合、これは当てはまりません。

- ヘッダーContent-Typeがx-www-form-urlencodedに設定されている場合、SecRequestBodyInMemoryLimitディレクティブは無視されます。

- SecDataDir、SecPcreMatchLimit、SecPcreMatchLimitRecursion、SecUnicodeCodePageおよびSecUnicodeMapFileディレクティブは、構成レベルでのみ使用できます。これらのディレクティブのスコープはMainであると見なされます。その他のすべてのディレクティブは仮想サーバー・レベルと構成レベルの両レベルで使用できます。これらのディレクティブのスコープはAnyであると見なされます。Mainスコープのディレクティブを仮想サーバー・レベルの構成ファイル内で指定すると、エラーがログに記録され、サーバーの起動は失敗します。

サポートされているWebアプリケーション・ファイアウォール変数

Oracle Traffic Directorでは次のModSecurity 2.8変数がサポートされています。ModSecurity変数の詳細および変数のリスト(サポートされていない変数を含む)は、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Variablesを参照してください。

ARGS
ARGS_COMBINED_SIZE
ARGS_GET
ARGS_GET_NAMES
ARGS_NAMES
ARGS_POST
ARGS_POST_NAMES
AUTH_TYPE
DURATION
ENV
FILES
FILES_COMBINED_SIZE
FILES_NAMES
FILES_SIZES
GEO
HIGHEST_SEVERITY
MATCHED_VAR
MATCHED_VARS
MATCHED_VAR_NAME
MATCHED_VARS_NAMES
MODSEC_BUILD
MULTIPART_BOUNDARY_QUOTED
MULTIPART_BOUNDARY_WHITESPACE
MULTIPART_DATA_AFTER
MULTIPART_DATA_BEFORE
MULTIPART_FILE_LIMIT_EXCEEDED
MULTIPART_HEADER_FOLDING
MULTIPART_INVALID_QUOTING
MULTIPART_INVALID_HEADER_FOLDING
MULTIPART_LF_LINE
MULTIPART_MISSING_SEMICOLON
MULTIPART_CRLF_LF_LINES
MULTIPART_STRICT_ERROR
MULTIPART_UNMATCHED_BOUNDARY
PERF_COMBINED
PERF_GC
PERF_LOGGING
PERF_PHASE1
PERF_PHASE2
PERF_PHASE3
PERF_PHASE4
PERF_PHASE5
PERF_SREAD
PERF_SWRITE
QUERY_STRING
REMOTE_ADDR
REMOTE_PORT
REMOTE_USER
REQBODY_ERROR
REQBODY_ERROR_MSG
REQBODY_PROCESSOR
REQBODY_PROCESSOR_ERROR
REQUEST_BASENAME
REQUEST_BODY (see note below)
REQUEST_BODY_LENGTH
REQUEST_COOKIES
REQUEST_COOKIES_NAMES
REQUEST_FILENAME
REQUEST_HEADERS (see note below)
REQUEST_HEADERS_NAMES
REQUEST_LINE
REQUEST_METHOD
REQUEST_PROTOCOL
REQUEST_URI
REQUEST_URI_RAW
RESPONSE_BODY
RESPONSE_CONTENT_LENGTH
RESPONSE_CONTENT_TYPE
RESPONSE_HEADERS
RESPONSE_HEADERS_NAMES
RESPONSE_PROTOCOL
RESPONSE_STATUS
RULE
SERVER_ADDR
SERVER_NAME
SERVER_PORT
SESSIONID
TIME
TIME_DAY
TIME_EPOCH
TIME_HOUR
TIME_MIN
TIME_MON
TIME_SEC
TIME_WDAY
TIME_YEAR
TX
UNIQUE_ID
URL_ENCODED_ERROR
USERID
WEBAPPID
WEBSERVER_ERROR_LOG (see note below)
XML

注意:

- rawリクエストの本文を格納するREQUEST_BODY変数には、その他のフィルタを通過した使用可能本文コンテンツが格納されます。

- オープン・ソースのModSecurityでは、各リクエスト/レスポンスのapacheエラー・ログを収集してWEBSERVER_ERROR_LOG変数に格納し、auditlogアクションで出力できます。しかし、Oracle Traffic Directorではこの機能はサポートされていません。

- 同じ名前のリクエスト・ヘッダーは1つに連結されるため、ヘッダー数は常に1となります。そのため、同じリクエスト・ヘッダーが送信された場合、その数に関係なく&REQUEST_HEADERS:<any header name>で常に1が返されます。

サポートされているWebアプリケーション・ファイアウォール演算子

Oracle Traffic Directorでは次のModSecurity 2.8演算子がサポートされています。ModSecurity演算子の詳細および演算子のリスト(サポートされていない演算子を含む)は、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Operatorsを参照してください。

beginsWith
contains
containsWord
endsWith
eq
ge
geoLookup
gt
inspectFile
ipMatch
le
lt
pm
pmf
pmFromFile
rbl (see note below)
rx
streq
strmatch
validateByteRange
validateDTD
validateSchema
validateUrlEncoding
validateUtf8Encoding
verifyCC
verifyCPF
verifySSN
within

注意:
ModSecurity 2.8ではSecHttpBlKeyディレクティブがサポートされません。そのため、RBLとしてProject Honey Pot (dnsbl.httpbl.cong)を使用することはできません(SecHttpBlKeyが必要になるため)。

サポートされているWebアプリケーション・ファイアウォール・アクション

Oracle Traffic Directorでは次のModSecurity 2.8アクションがサポートされています。ModSecurityアクションの詳細およびアクションのリスト(サポートされていないアクションを含む)は、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Actionsを参照してください。

allow
append
auditlog (see note below)
block
capture
chain
ctl
deny (see note below)
deprecatevar
drop (see note below)
exec
expirevar
id
initcol
log
logdata
msg
multiMatch
noauditlog
nolog
pass
pause
phase
prepend
redirect
rev
sanitiseArg
sanitiseMatched
sanitiseMatchedBytes
sanitiseRequestHeader
sanitiseResponseHeader
severity
setuid
setsid
setenv
setvar
skip
skipAfter
status
t
tag
xmlns

注意:

- オープン・ソースのModSecurityでは、各リクエスト/レスポンスのapacheエラー・ログを収集してWEBSERVER_ERROR_LOG変数に格納し、auditlogアクションで出力できます。しかし、Oracle Traffic Directorではこの機能はサポートされていません。

- denyなど、HTTPレスポンスのステータスを変更するアクションは、フェーズ4で呼び出された場合にレスポンス・ステータスを正しく変更しません。このようなシナリオでは、次のエラー・メッセージがサーバー・ログに記録されます。

" ModSecurity: Access denied with code 403 (phase 4)."

- dropアクションがフェーズ4で呼び出された場合、Oracle Traffic DirectorがHTTPヘッダーをクライアントに送出し、接続を切断します。

- denyアクションがフェーズ4で呼び出された場合、Oracle Traffic Directorは403レスポンス・ステータスを送信するかわりに、レスポンス本文を取り除きます。これにより、サーバー・ログに次の警告が表示される可能性があります。

Response content length mismatch (0 bytes with a content length of <original content length>)

サポートされているWebアプリケーション・ファイアウォール変換関数

Oracle Traffic Directorでは次のModSecurity 2.8変換関数がサポートされています。ModSecurity変換関数の詳細およびすべての変換関数のリストは、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Transformation_functionsを参照してください。

base64Decode
sqlHexDecode
base64DecodeExt
base64Encode
cmdLine
compressWhitespace
cssDecode
escapeSeqDecode
hexDecode
hexEncode
htmlEntityDecode
jsDecode
length
lowercase
none
normalisePath
normalisePathWin
parityEven7bit
parityOdd7bit
parityZero7bit
removeNulls
removeWhitespace
replaceComments
removeCommentsChar
removeComments
replaceNulls
urlDecode
urlDecodeUni
urlEncode
sha1
trimLeft
trimRight
trim

サポートされているWebアプリケーション・ファイアウォール永続ストレージ

Oracle Traffic Directorでは次のModSecurity 2.8永続ストレージがサポートされています。ModSecurity永続ストレージの詳細およびすべての永続ストレージのリストは、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Persistant_Storageを参照してください。

GLOBAL
IP
RESOURCE
SESSION
USER

サポートされているWebアプリケーション・ファイアウォール・フェーズ

Oracle Traffic Directorでは次のModSecurity 2.8フェーズがサポートされています。ModSecurityフェーズの詳細およびすべてのフェーズのリストは、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Processing_Phasesを参照してください。

Phase:1 - Request headers stage
Phase:2 - Request body stage
Phase:3 - Response headers stage
Phase:4 - Response body stage
Phase:5 - Logging

注意:

- denyなど、HTTPレスポンスのステータスを変更するアクションは、フェーズ4で呼び出された場合にレスポンス・ステータスを正しく変更しません。

- dropアクションがフェーズ4で呼び出された場合、Oracle Traffic DirectorがHTTPヘッダーをクライアントに送出し、接続を切断します。

- denyアクションがフェーズ4で呼び出された場合、Oracle Traffic Directorは403レスポンス・ステータスを送信するかわりに、レスポンス本文を取り除きます。これにより、サーバー・ログに次の警告が表示される可能性があります。

Response content length mismatch (0 bytes with a content length of <original content length>)

10.6 クライアント認証の構成

クライアント認証とは、クライアントによって提供される証明書に基づいて行われる、Oracle Traffic Director仮想サーバーまたはTCPプロキシによるクライアントの検証です。

クライアント認証は、デフォルトでは有効化されません。Fusion Middleware ControlまたはWLSTのいずれかを使用して、クライアントに証明書の提供を要求するようにOracle Traffic Directorリスナーを構成できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したクライアント認証の構成

Fusion Middleware Controlを使用してリスナーのクライアント認証を有効にするには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. リスナーのクライアント認証を有効にする構成を指定します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

7. 構成する仮想サーバーの名前を選択します。

8. 「設定」→「詳細設定」→「SSL/TLS設定」を選択します。

9. 必要な「SSL/TLSクライアント認証」モードを選択します。

- 必須: サーバーがクライアントに証明書を要求し、クライアントが証明書を提供しない場合、接続はクローズされます。

- オプション: サーバーはクライアントに証明書を要求しますが、必須ではありません。クライアントが証明書を提供しなくても、接続は確立されます。

- 無効 (デフォルト): クライアント認証は無効化されます。

10. 「認証タイムアウト」および「最大認証データ」パラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

11. 必要な変更を行った後、「適用」をクリックします。

- 更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したクライアント認証の構成

HTTPまたはTCPリスナー用のクライアント認証を有効にするには、仮想サーバーに対してotd_setVirtualServerSslPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['client-auth'] = 'false'
otd_setVirtualServerSslProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.7 サービス拒否攻撃の防止

サービス拒否(DoS)攻撃とは、悪意のあるユーザーがリクエストをサーバーに連続して送信することで、正当なユーザーによるサービスへのアクセスを妨害することを指します。

DoS攻撃を回避するために、リクエストの頻度または同時接続数が指定された制限を超えた場合、リクエストを拒否するようにOracle Traffic Director仮想サーバーを構成できます。より細かくリクエストを制御するには、リクエスト制限を定義し、各制限を、指定したURLパターンや問合せ文字列パターンに一致するリクエスト、および指定した値に一致するリクエスト・ヘッダーなどに適用できます。

この項には次のサブセクションが含まれます:

- 10.7.1項「リクエスト制限のパラメータ」

- 10.7.2項「仮想サーバーのリクエスト制限の構成」

10.7.1 リクエスト制限のパラメータ

仮想サーバーに複数のリクエスト制限を指定できます。各リクエスト制限について、いくつかのパラメータを構成できます。

- 各リクエスト制限は、次のような式を使用して指定した特定の条件を満たすリクエストに適用するように設定できます。

$path = "*.jsp"
$url = "/images/*"
$ip =~ "^130\.35\.46\..*"

変数または変数の組合せを使用して、制限の条件を指定できます。リクエスト制限の条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

- 各リクエスト制限に対して、同時リクエスト数(max-connections)および1秒当たりの平均リクエスト数(max-rps)を指定できます。
たとえば、制限を指定すると(max-rps=20など)、Oracle Traffic Directorは、指定された計算間隔(デフォルト: 30秒)で受信したリクエスト数に基づき、その間隔でリクエスト・レートを繰返し計算することでリクエスト・レートを継続的に追跡します。指定したリクエスト制限に達した場合、Oracle Traffic Directorによって後続のリクエストはすべて拒否されます。

- リクエスト制限を適用する場合、Oracle Traffic Directorが監視するオプション属性も指定できます。Oracle Traffic Directorは、個別のカウンタを使用して、各監視対象属性のリクエスト統計を追跡します。
たとえば、Oracle Traffic DirectorでクライアントIPごとにリクエストを個別に追跡するには、変数$ipを監視属性として指定できます。リクエスト・レートがクライアントで指定された制限を超えると、そのクライアントからの後続のリクエストは拒否されますが、その他のクライアントからのリクエストは引き続き処理されます。

また、監視する属性を指定する際は、変数を組み合せることもできます。たとえば、同じURIをリクエストする頻度が高すぎるクライアントからのリクエストを制限するには、$ip:$uriを監視対象の属性として指定できます。1つのURIに対するクライアントからのリクエスト・レートが制限を超えた場合、その後のそのクライアントからのそのURIへのリクエストは拒否されますが、そのクライアントから別のURIへのリクエスト、およびその他のクライアントから任意のURIへのリクエストは引き続き処理されます。

- Oracle Traffic Directorによって拒否されたリクエストについては、指定したHTTPレスポンス・コードが返されます。デフォルトのステータス・コードは、503 (service unavailable)です。

- 指定された制限(max-connectionsまたはmax-rps)に到達した後、Oracle Traffic Directorでは、指定された続行条件が満たされるまで、後続のリクエストはすべて拒否され続けます。次の続行条件のいずれかを指定できます。

- しきい値(デフォルト): 指定された制限をリクエスト・レートが下回ったら、サービスは再開されます。

- サイレンス: 受信するリクエスト数が間隔全体でゼロになると、サービスが再開されます。

10.7.2 仮想サーバーのリクエスト制限の構成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、仮想サーバーのリクエスト制限を構成できます。

注意:

- 仮想サーバーを変更すると、実質的には構成が変更されます。新規仮想サーバー設定をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

- WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したリクエスト制限の構成

Fusion Middleware Controlを使用してリクエスト制限を構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. リクエスト制限を構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

7. ナビゲーション・ペインで、「仮想サーバー」を展開し、リクエスト制限を構成する仮想サーバーの名前を展開して、「リクエスト制限」を選択します。
「リクエスト制限」ページが表示されます。仮想サーバーに現在定義されているリクエスト制限がリストされます。

リクエスト制限の作成

1. 「新規リクエスト制限」をクリックします。
「新規リクエスト制限」ダイアログ・ボックスが表示されます。

「名前」フィールドで、新しいリクエスト制限の名前を入力します。

「接続」フィールドに、仮想サーバーへの最大同時接続数を指定します。

「リクエスト数/秒」フィールドに、仮想サーバーが1秒当たりで受入れ可能な最大リクエスト数を指定します。

注意:
少なくともいずれかの制限(最大接続数または1秒当たりの最大リクエスト数)を指定する必要があります。

「監視属性」フィールドに、仮想サーバーがリクエスト制限を適用するために監視する必要があるリクエスト・ヘッダーの属性を指定します。このパラメータを指定しない場合、リクエスト制限はすべてのリクエストに適用されます。

「適用先」フィールドでデフォルトの1つを選択すると、そのリクエスト制限がすべてのリクエストに適用されます。

2. 「OK」をクリックすると、新しい「リクエスト制限の作成」が作成されます。
作成したリクエスト制限が「リクエスト制限」ページに表示されます。

リクエスト制限の編集

リクエスト制限の設定を変更するには、次の操作を行います。

1. リクエスト制限の「名前」をクリックします。
「編集中のリクエスト制限」ページが表示されます。

注意:
条件ビルダーにアクセスして条件を編集するには、「条件を満たすリクエスト」を選択し、「編集」をクリックします。条件ビルダーでは古い式を削除したり、新しい式を作成したりできます。

2. 変更するパラメータを指定します。
リクエスト制限を編集する際、リクエスト制限の作成時に指定したパラメータの変更に加えて、requests-per-second計算間隔、および指定した制限に到達したときに拒否されるリクエストについて仮想サーバーが返すHTTPステータス・コードを設定および変更できます。「編集」をクリックすると設定済の条件を編集できるため、条件を手動でまたは条件ビルダーを使用して編集できます。古い式を削除したり、新しい式を作成できます。

画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

3. 必要な変更を行った後、「保存」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

リクエスト制限の削除

リクエスト制限を削除するには、「削除」ボタンをクリックします。確認プロンプトで、「OK」です。

WLSTを使用したリクエスト制限の構成

- リクエスト制限を作成するには、otd_createRequestLimitコマンドを実行します。
例:

- 次のコマンドでは、構成fooの仮想サーバーbar内にrequest-limit-1という名前のリクエスト制限が作成されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
props['max-connections'] = '2048'
otd_createRequestLimit(props)

--conditionオプションの値は、正規表現にする必要があることに注意してください。条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』 の変数、式および文字列の補間の使用に関する項を参照してください。

- 仮想サーバーに定義されているリクエスト制限のリストを表示するには、次の例に示すように、otd_listRequestLimitsコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listRequestLimits(props)

- リクエスト制限のプロパティを表示するには、次の例に示すように、otd_getRequestLimitPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
props['event-notification-interval'] = '60'
otd_getRequestLimitProperties(props)

- リクエスト制限のプロパティを変更するには、otd_setRequestLimitPropertiesコマンドを実行します。
たとえば、次のコマンドでは、構成fooの仮想サーバーbar内のリクエスト制限request-limit-1における1秒当たりのリクエスト数の計算間隔が変更されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
props['max-connections'] = '1024'
otd_setRequestLimitProperties(props)

- リクエスト制限を削除するには、次の例に示すように、otd_deleteRequestLimitコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
otd_deleteRequestLimit(props)

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

10.8 OTDのSSLパススルーの構成

Oracle Traffic Director (OTD)は、Oracleエンジニアド・システム用のソフトウェア・ベースのアプリケーション配信コントローラであり、SOA、ATG (E-Commerce)、PeopleSoft、E-Business SuiteなどのOracle Fusion MiddlewareおよびBusiness Applicationデプロイメントのフロントエンドとして、SSLの終端、ロード・バランシング、制限、受信リクエスト調整といった機能を備えています。

Oracle Traffic Director (OTD)の主要機能には次のものがあります。

- 高度なロード・バランシング・アルゴリズム、およびHTTPヘッダーまたはHTTPエンティティ・データのいずれかに基づくトラフィック管理機能を備えた本格的なレイヤー7ソフトウェア・ロード・バランサ。

- WebLogic RMI t3、LDAPプロトコルなどのTCPトラフィックのフロントエンドとなる、レイヤー5(単一接続-TCP)のロード・バランサ。

- SQLインジェクション、コマンド・インジェクション脆弱性などの一般的なセキュリティ脆弱性からバックエンド・アプリケーションを保護するModSecurityのベースのWebアプリケーション・ファイアウォール(WAF)機能。

- ロード・バランサ層内の高可用性(アクティブ-パッシブ/アクティブ-アクティブ)フェイルオーバー機能。

さらに、OTDでは、スループット向上のため、HTTP(S)/SSLリクエストを処理しながら、SSL暗号の処理を基礎となるIntelプロセッサへオフロードする機能が提供されています。とはいえ、本番システムでは、顧客は外部のハードウェア・ロード・バランサでSSLを終端します。このドキュメントでは、このユースケースを処理するために必要な構成手順のリストを見ていきます。

10.8.1 外部(ハードウェア)ロード・バランサからのパス・スルーSSL情報のためのOTDの構成

(次に示すような)標準的な本番デプロイメント・トポロジでは、顧客は、(外部の)ハードウェア・ロード・バランサ内でSSLを終端し、内部のロード・バランサ(リバース・プロキシ)およびアプリケーション層内ではHTTP通信のみを扱います。

このシナリオでは、顧客は、すべてのリクエストのリダイレクトが正しく行われるように、アプリケーション層のみでなく内部のロード・バランサ/リバース・プロキシ・ソリューションでも、いくつかの追加手順を実行する必要があります。この項では、内部のロード・バランサ(OTD)/リバース・プロキシ・ソリューション内で必要となる手順を中心に説明します。

1. OTDに追加ヘッダーを送信するためのハードウェア・ロード・バランサの構成

- OTD内でSSLを終端する場合、OTDに「WL-Proxy-SSL:true」ヘッダーを送信するように、ハードウェア・ロード・バランサを構成する必要があります。詳細は、「OTDに特定のヘッダーを送信するためのF5-BigIPの構成」を参照してください。

- ハードウェア・ロード・バランサ内でSSLを終端し、Oracle Access Manager (OAM/IDM)のフロントエンドとしてOTD/OHSも使用する場合は、受信リクエストのヘッダーに「IS_SSL:ssl」ヘッダーを追加して挿入するようにハードウェア・ロード・バランサを構成する必要があります。この手順は、「OTDに特定のヘッダーを送信するためのF5-BigIPの構成」で説明するWL-Proxy-SSLヘッダーの挿入に似ています。

2. WebLogic Serverの内のWLSプラグイン有効化の構成設定を有効にします。

- オリジン・サーバーで、WebLogic Serverも、その基礎となるWebLogic Serverコンテナも使用していない場合は、この手順をスキップできます。

- 詳細は、「Web層/Traffic DirectorからSSL情報を受信するためのWebLogicの構成」を参照してください。

3. パス・スルーSSLのためのOTD 11gの構成(管理コンソールのUIを使用):

- 適切な資格証明を使用してOTDの管理コンソールにログインします。

- 「仮想サーバー」を展開して、対応するかまたは関連する「ルート」画面を選択します。

- ルートを更新して(「仮想サーバー」→「ルート」→「デフォルト」→「詳細」)、OTDによる「Location」または「Content-Location」ヘッダーの書き換えを無効にします。これは、外部のロード・バランサでSSLが終端されている場合に重要です。

- 「Rewrite-headers」を空に変更します。

- ルートの「詳細設定」の下で、(次に示すように)オリジン・サーバーに送信されるすべてのSSL関連ヘッダーの選択を解除して保存し、この構成をデプロイします。

- 変更を保存して、「変更のデプロイ」ボタンをクリックします。

前述の手順の最後で、Oracle Traffic Directorによりヘッダーが書き換えられることはなくなり(通常これは、アプリケーション層が別の場所にリクエストをリダイレクトするときに発生します)、受信リクエスト内の受信リクエスト・ヘッダーを介して、外部のハードウェア・ロード・バランサが提供するSSL情報のパス・スルーが可能になります。

10.8.2 Web層/Traffic DirectorからSSL情報を受信するためのWebLogicの構成

WebLogicアプリケーション・サーバーのフロントエンドとして、WebLogic Proxy Plug-In、Oracle HTTP ServerなどのOracleのWeb層ソリューションまたはOracle Traffic Directorを使用する場合は、WebLogicコンソールで明示的に「WebLogicプラグインの有効化」の設定をオンにする必要があります。このフラグは、特定のWebLogic管理対象サーバー内またはWebLogicクラスタ・レベルのいずれかでオンにできます。このフラグは、WebLogicクラスタ・レベルでオンにすることをお薦めします。

これにより、Traffic Director/Web層内でSSLが終端されている場合に、WebLogicで適切にヘッダーを書き込むことができます。

http://<wls-admin-hostname>:7001/consoleを開き、WebLogicのユーザー/パスワードでログインします。

(Weblogicクラスタを有効にしている場合は、クラスタ・レベルでこれを行うことをお薦めします)。

(Weblogicクラスタを有効にしていない場合は、WLS管理対象サーバー内でこの設定を有効にできます)。「構成」→「一般」の設定タブ内で、「詳細設定」を展開してスクロール・ダウンし、「WebLogicプラグインの有効化」で「はい」を選択し、「保存」をクリックします。

10.8.3 OTDに特定のヘッダーを送信するためのF5-BigIPの構成

Oracle Traffic Directorでは、基礎となるハードウェア・プロセッサを利用して暗号処理をオフロードでき、一般的なリバース・プロキシ・ソリューションと比較して全体的に優れたSSL性能を実現します。

F5-BigIpなどのハードウェア・ロード・バランサ内でのSSLの終端を選択する場合は、OTDおよびWLSに対して明示的に特定のヘッダー「WL-Proxy-SSL」を送信するように、このハードウェア・ロード・バランサを構成する必要があります。

次の手順では、このヘッダーを送信するようにF5-BigIpを構成する方法を説明します(情報源: F5 Big IP製品のドキュメント)。

SSL用の新規HTTPプロファイルを作成するには:

1. 「Main」タブで「Local Traffic」を展開して、「Profiles」をクリックします。「HTTP Profiles」画面が開きます。

2. 画面の右上部で、「Create」ボタンをクリックします。「New HTTP Profile」画面が開きます。

3. 「Name」ボックスに、このプロファイルの名前を入力します。この例では、bea-sslと入力します。

4. WebAcceleratorを使用している場合は、「Parent Profile」リストから「http-acceleration」を選択します。WebAcceleratorを使用していない場合は、「http-wan-optimized-compression-caching」を選択します。

5. 「Request Header Insert」行で、「Custom」ボックスを選択します。このボックスに、WL-Proxy-SSL:trueと入力します。

6. 「Redirect Rewrite」行で、「Custom」ボックスを選択します。「Redirect Rewrite」リストから「Match」を選択します。

7. ご自身のネットワークに応じて、その他の設定を変更します。この例では、設定はデフォルトのままにします。

8. 「終了」ボタンをクリックします。

11 ログの管理

Oracle Traffic Directorのログ・ファイルには、構成の変更、インスタンスの起動および停止、リクエスト処理中のエラーなどのサーバー・イベントに関するデータが記録されます。ログを使用すると、サーバーの問題の診断、サーバーの使用パターンの評価、およびシステムのパフォーマンス向上のためのチューニングを行えます。

この章には次の項が含まれます:

- Oracle Traffic Directorログについて

- ログの表示

- ログ・プリファレンスの構成

- ログ・ローテーションについて

- 手動によるログ・ローテーション

- Oracle Traffic Directorにおけるログ・ローテーションの自動化の構成

11.1 Oracle Traffic Directorのログについて

管理サーバーを含む各Oracle Traffic Directorインスタンスには、アクセス・ログとサーバー・ログの2つのログがあります。インスタンス・ログはデフォルトで有効化されており、最初にインスタンスが起動されるときに初期化されます。インスタンス・ログに加えて、インスタンス内の各仮想サーバーのアクセス・ログおよびサーバー・ログを有効化できます。

- Oracle Traffic Directorインスタンスのアクセス・ログおよびサーバー・ログのデフォルトの場所は、DOMAIN_HOME/servers/instance-name/logsディレクトリです。

この項では、アクセス・ログおよびサーバー・ログの概要を説明します。ログ・ファイルの名前および場所などのログ設定の変更の詳細は、11.3項「ログ・プリファレンスの構成」を参照してください。

11.1.1 アクセス・ログ

アクセス・ログには、サーバーへのリクエストおよびサーバーからのレスポンスについての情報が含まれます。アクセス・ログ・ファイルのデフォルト名は、access.logです。

次の例は、典型的なアクセス・ログの最初の3行を示しています。

format=%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] "%Req->reqpb.clf-request%" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length% %Req->vars.ecid%
10.177.243.207 - - [28/Aug/2011:23:28:30 -0700] "GET / HTTP/1.1" 200 4826 -
10.177.243.207 - - [28/Aug/2011:23:28:31 -0700] "GET / HTTP/1.1" 200 916 -

1行目は、アクセス・ログの形式を示しています。2行目および3行目は、実際のエントリです。

アクセス・ログの形式、ファイル名および場所を変更できます。アクセス・ログを無効化することもできます。詳細は、11.3項「ログ・プリファレンスの構成」を参照してください。

11.1.2 サーバー・ログ

サーバー・ログには、ライフサイクル・イベント(サーバーの起動、シャット・ダウンおよび再起動)、構成の更新などに関するデータが含まれます。また、サーバーで発生したエラーおよび警告も含まれます。サーバー・ログ・ファイルのデフォルト名は、server.logです。

次の行は、サーバー・ログ内のエントリの例です。

[2011-10-03T02:04:59.000-07:00] [net-soa] [NOTIFICATION] [OTD-10358] []
[pid: 11722] http-listener-1: http://example.com:1904 ready to accept requests

デフォルトのサーバー・ログ・レベルはNOTIFICATION:1であり、主要なライフサイクル・イベント、警告およびエラーのみが記録されます。

ログ・レベル、ログ・ファイル名およびログ・ファイルの場所を変更できます。詳細は、11.3項「ログ・プリファレンスの構成」を参照してください。

表11-1は、サーバー・ログに指定できるログ・レベルを示しています。

表11-1 サーバー・ログ・レベル

ログ・レベル

説明

INCIDENT_ERROR:1

原因不明の重大な問題です。Oracleサポートに連絡する必要があります。

ERROR:1

ERROR:16

ERROR:32

迅速な対処が必要な深刻な問題です。

WARNING:1

確認する必要がある潜在的な問題です。

NOTIFICATION:1 (デフォルト)

サーバーの起動中または再起動中など主要なライフサイクル・イベントです。

TRACE:1

TRACE:16

TRACE:32

ユーザーまたはOracleサポートが特定のサブシステムでの問題を診断するのに役立つトレースまたはデバッグ情報です。

各ログ・レベルの後の番号は、記録されたイベントの重大度を1-32の段階で示したものです。ERROR:1メッセージは、ERROR:16メッセージより重大度が高くなります。

TRACE:32は、最も冗長度の高いログ・レベルで、INCIDENT_ERROR:1は最も冗長度の低いログ・レベルです。TRACEログ・レベルを有効化すると、大量のメッセージが記録されるため、パフォーマンスに影響を及ぼす可能性があります。したがって、問題をデバッグするためにより詳細な情報が必要な場合を除き、本番システムで冗長なログ・レベルを有効化しないようにしてください。

11.2 ログの表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、Oracle Traffic Directorインスタンスおよび仮想サーバーのアクセス・ログおよびサーバー・ログを表示できます。

注意:

- WLSTまたはFusion Middleware Controlを使用する以外にも、lsやmoreなどの標準のオペレーティング・システム・コマンドを使用して、ログ・ファイルをリストしたり表示したりできます。

- Fusion Middleware Controlのログ・ビューアおよびWLSTのdisplayLogsコマンドでは、現在、ディスク上のアクセス・ログ・ファイル、TCPのアクセス・ログ、エラー・ログに存在するログ・エントリのみが表示されます。これらでは、アクセス・ログ・バッファにある項目は表示されません(15.9項「アクセス・ログ・バッファ設定の構成」を参照)。

- WLSTの使用方法の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したログの表示

Fusion Middleware Controlを使用してノード、インスタンス、インスタンス内の仮想サーバーのログ・データを表示するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. ログを表示する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「ロギング」を選択します。

7. Oracle Traffic Directorのログ・ビューア・ウィンドウが表示されます。

8. サーバー・ログ・プリファレンス、アクセス・ログ・プリファレンスおよびTCPアクセス・ログ・プリファレンスをリストするタブが表示されます。

- サーバー・ログを表示するには、「サーバー・ログ・プリファレンス」タブを選択します。

- アクセス・ログを表示するには、「アクセス・ログ・プリファレンス」タブを選択します。

- TCPのアクセス・ログを表示するには、「TCPアクセス・ログ・プリファレンス」タブを選択します。

WLSTを使用したログの表示

- インスタンスまたは仮想サーバーのアクセス・ログを表示するには、displayLogsコマンドを実行します。
たとえば、次のコマンドでは、構成fooのインスタンスのアクセス・ログ・レコードが表示されます。

displayLogs(target="sc:otd_foo_machine1")

displayLogsの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

11.3 ログ・プリファレンスの構成

構成を作成すると、サーバー・ログおよびアクセス・ログが、特定のデフォルト設定で有効化されます。サーバー・ログのレベル、ファイル名および場所を変更できます。アクセス・ログの形式、ファイル名および場所を変更できます。アクセス・ログを無効化することもできます。サーバー・ログの場所を変更する場合、インスタンスを再起動して変更を有効にする必要があります。

構成内に定義されたログ・プリファレンスは、構成内のすべての仮想サーバーに適用されます。仮想サーバー・レベルで、アクセス・ログの場所や形式、およびサーバー・ログの場所を定義できます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、Oracle Traffic Directorインスタンスのログ・プリファレンスを構成できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したログ・プリファレンスの構成

Fusion Middleware Controlを使用して構成または仮想サーバーのログ・プリファレンスを構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. ログ・プリファレンスを構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「ロギング」を選択します。

7. Oracle Traffic Directorのログ・ビューア・ウィンドウが表示されます。

8. サーバー・ログ・プリファレンス、アクセス・ログ・プリファレンスおよびTCPアクセス・ログ・プリファレンスをリストするタブが表示されます。

- サーバー・ログを表示するには、「サーバー・ログ・プリファレンス」タブを選択します。

- アクセス・ログを表示するには、「アクセス・ログ・プリファレンス」タブを選択します。

- TCPのアクセス・ログを表示するには、「TCPアクセス・ログ・プリファレンス」タブを選択します。

9. 各タブ内で、変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

カスタムのアクセス・ログ形式指定の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』 のカスタムのアクセス・ログ形式の使用に関する項を参照してください。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

10. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したログ・プリファレンスの構成

- 構成または仮想サーバーの現在のアクセス・ログ・プリファレンスを表示するには、getConfigurationAccessLogPropertiesまたはotd_getVirtualServerAccessLogPropertiesコマンドを実行します。
たとえば、次のコマンドでは、構成fooのアクセス・ログ・プリファレンスが表示されます。

props = {}
props['configuration'] = 'foo'
otd_getConfigurationAccessLogProperties(props)

log-file=$DOMAIN_HOME/servers/$INSTANCE_NAME/logs/access.log
format=%Ses->client.ip% - %Req->vars.auth-user% %SYSDATE% "%Req->reqpb.clf-request%" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length% %Req->vars.ecid% %Req->vars.origin-server%
default-access-log-format=%Ses->client.ip% - %Req->vars.auth-user% %SYSDATE% "%Req->reqpb.clf-request%" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length% %Req->vars.ecid% %Req->vars.origin-server%

- 構成または仮想サーバーの現在のアクセス・ログ・プリファレンスを設定または変更するには、setConfigurationAccessLogPropertiesまたはotd_setVirtualServerAccessLogPropertiesコマンドを実行します。
たとえば、次のコマンドでは、構成fooのアクセス・ログの場所がlogs/access.logに変更されます。

props = {}
props['configuration'] = 'foo'
props['log-file'] = 'logs/access.log'
otd_setConfigurationAccessLogProperties(props)

カスタムのアクセス・ログ形式指定の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』 のカスタムのアクセス・ログ形式の使用に関する項を参照してください。

- 仮想サーバーのアクセス・ログを無効にするには、次の例に示すように、otd_disableVirtualServerAccessLogコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_disableVirtualServerAccessLog(props)

- 構成の現在のサーバー・ログ・プリファレンスを表示するには、otd_getLogPropertiesコマンドを実行します。
たとえば、次のコマンドでは、構成soaのサーバー・ログ・プリファレンスが表示されます。

props = {}
props['configuration'] = 'foo'
otd_getLogProperties(props)

log-stdout=true
log-stderr=true
log-virtual-server-name=false
create-console=false
log-to-console=true
log-to-syslog=false
log-level=NOTIFICATION:1
log-file=../logs/server.log

- 構成のサーバー・ログ・プリファレンスを設定または変更するには、otd_setLogPropertiesコマンドを実行します。サーバー・ログの場所を変更する場合、インスタンスを再起動して変更を有効にする必要があることに注意してください。
たとえば、次のコマンドでは、構成fooのサーバー・ログ・レベルがTRACE:32に変更されます。

props = {}
props['configuration'] = 'foo'
props['log-level'] = 'TRACE:32'
otd_setLogProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

11.4 ログ・ローテーションについて

指定した間隔でログを自動的にローテーション(アーカイブ)するようにOracle Traffic Directorを構成できます。また、必要な場合はいつでも、ログを手動でローテーションすることもできます。

ログをローテーションすると、古いログ・ファイルは、ローテーション日付(yyyymmdd形式)および24時間(hhmm)を示す接尾辞で名前が変更されます。たとえば、2011年8月25日午後11時にアーカイブされたサーバー・ログのファイル名は、server-201108252300.logとなります。

ログのローテーション後、サーバー・ログおよびアクセス・ログは再初期化されます。

ログのローテーション方法の詳細は、11.5項「手動によるログ・ローテーション」および11.6項「Oracle Traffic Directorの自動ログ・ローテーションの構成」を参照してください。

注意:
アクセス・ログのローテーション・イベントにより、TCPアクセス・ログもローテーションされます。

11.5 手動によるログ・ローテーション

Fusion Middleware ControlまたはWLSTのいずれかを使用して、Oracle Traffic Directorインスタンスのサーバーおよびアクセス・ログを手動でローテーションできます。古いログ・ファイルはサーバーに保存され、保存済ファイルは保存時の日時を含む名前を使用してマークされます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したログの手動ローテーション

Fusion Middleware Controlを使用してログをローテーションするには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. ログをローテーションする構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「ログ・ローテーション」を選択します。

7. Oracle Traffic Directorの「ログ・ローテーション」ウィンドウが表示されます。

8. Oracle Traffic Directorで、ローテーションされたログ・ファイルに対し特定のコマンドを実行するには、「アーカイブ・コマンド」フィールドで、必要なコマンドへの絶対パスを指定します。

1. たとえば、アーカイブ・コマンドとして/usr/bin/gzipを指定した場合、ログのローテーション後、Oracle Traffic Directorでは、次のコマンドを実行してローテーションされたログ・ファイルを圧縮します。

$ /usr/bin/gzip access-yyyymmddhhmm.log
$ /usr/bin/gzip server-yyyymmddhhmm.log

2. 「ログを今すぐローテーション」をクリックします。
構成のすべてのインスタンスに対して、仮想サーバー固有のログを含むサーバー・ログおよびアクセス・ログがアーカイブされます。

選択した構成の特定のインスタンスのログをローテーションするには、次の操作を行います。

1. ナビゲーション・ペインで、「インスタンス」を選択します。
「インスタンス」ページが表示されます。

2. 必要なインスタンスの「ログのローテーション」ボタンをクリックします。
選択したインスタンスに対して、仮想サーバー固有のログを含むサーバー・ログおよびアクセス・ログがアーカイブされます。

「コンソール・メッセージ」ペイン、にログがローテーションされたことを確認するメッセージが表示されます。

WLSTを使用したログの手動ローテーション

インスタンスのログをローテーションするには、otd_rotateLogコマンドを実行します。たとえば、次のコマンドでは、otd_foo_machine1インスタンスのアクセスおよびサーバー・ログがローテーションされます。

props = {}
props['instance'] = 'otd_foo_machine1'
otd_rotateLog(props)

注意:
Oracle Traffic Directorで、ローテーションされたログ・ファイルに対して特定のコマンドを実行するには、次の例に示すように、otd_setLogPropertiesコマンドを実行して、必要なコマンドへの絶対パスを指定するarchive-commandプロパティを指定します。

props = {}
props['configuration'] = 'foo'
props['archive-command] = '/usr/bin/gzip'
otd_setLogProperties(props)

この例では、ログのローテーション後、次のコマンドにより、ローテーションされたログ・ファイルがOracle Traffic Directorで圧縮されます。

$ /usr/bin/gzip access-yyyymmddhhmm.log
$ /usr/bin/gzip server-yyyymmddhhmm.log

otd_rotateLogおよびotd_setLogPropertiesの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

11.6 Oracle Traffic Directorにおけるログ・ローテーションの自動化の構成

ログ・ローテーション・イベントを作成し、指定した時間または間隔で、ログを自動的にローテーションするようにOracle Traffic Directorを構成できます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、ログ・ローテーション・イベントを作成できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したログ・ローテーション・イベントの作成

Fusion Middleware Controlを使用してログ・ローテーション・イベントを作成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. ログをローテーションする構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「ログ・ローテーション」を選択します。

7. Oracle Traffic Directorの「ログ・ローテーション」ウィンドウが表示されます。

8. Oracle Traffic Directorで、ローテーションされたログ・ファイルに対し特定のコマンドを実行するには、「アーカイブ・コマンド」フィールドで、必要なコマンドへの絶対パスを指定します。
たとえば、アーカイブ・コマンドとして/usr/bin/gzipを指定した場合、ログのローテーション後、Oracle Traffic Directorでは、次のコマンドを実行してローテーションされたログ・ファイルを圧縮します。

$ /usr/bin/gzip access-yyyymmddhhmm.log
$ /usr/bin/gzip server-yyyymmddhhmm.log

9. 「作成」をクリックします。
「新規ログ・ローテーション・イベント」ダイアログ・ボックスが表示されます。

10. このイベントがサーバー・ログ用かまたはアクセス・ログ用かを指定します。

11. ログを更新する間隔または時刻を指定し、「OK」をクリックします。

- イベントの作成を確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- 新規イベントが「ログ・ローテーション・イベント」リストに表示されます。

- 新しいイベントはデフォルトで有効になっています。ステータスを変更するには、「有効化/無効化」チェック・ボックスを選択します。

- イベントを削除するには、「削除」ボタンをクリックします。

WLSTを使用したログ・ローテーション・イベントの作成

ログ・ローテーション・イベントを作成するには、otd_createEventコマンドを実行します。

たとえば、次のコマンドでは、構成fooのすべてのインスタンスのアクセス・ログおよびサーバー・ログを午後12時にローテーションするようにOracle Traffic Directorが構成されます。

props = {}
props['configuration'] = 'foo'
props['event'] = 'event-1'
props['command'] = 'rotate-log'
props['time'] = '12:00'
otd_createEvent(props)

props = {}
props['configuration'] = 'foo'
props['event'] = 'event-1'
props['command'] = 'rotate-access-log'
props['time'] = '12:00'
otd_createEvent(props)

otd_createEventの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

12 Oracle Traffic Directorインスタンスの監視

Oracle Traffic Directorでは、サーバー・アクティビティについての統計が様々なレベル(インスタンス、仮想サーバー、リスナー、接続およびオリジン・サーバー)で記録されます。たとえば、構成の各インスタンスについて、Oracle Traffic Directorでは、インスタンスの実行時間、処理されたリクエスト数、送受信されたデータ量、インスタンスによって送信された各タイプのレスポンス数、平均負荷などの統計が収集されます。同様に、インスタンス内の各仮想サーバーについて、Oracle Traffic Directorでは、処理されたリクエスト数、送受信されたデータ量、および各タイプのレスポンス数についての統計が収集されます。Oracle Traffic Directorで収集されるメトリックの完全なリストについては、付録A「Oracle Traffic Directorで追跡されるメトリック」を参照してください。

この章では、Oracle Traffic Directorの監視機能について説明します。ここの内容は、次のとおりです。

- Oracle Traffic Directorインスタンスの監視方法

- 統計収集設定の構成

- 統計レポートへのURIアクセスの構成

- WLSTを使用した統計の表示

- ブラウザを使用したstats-xmlおよびperfdumpレポートの表示

- SNMPを使用した監視

- DMSを使用した監視

- XML (stats-xml)レポートのサンプル

- プレーンテキスト(perfdump)レポートのサンプル

12.1 Oracle Traffic Directorインスタンスの監視方法

表12-1は、構成のインスタンス、およびインスタンス内の個々の仮想サーバーについての統計データの表示に使用できる方法を示しています。

表12-1 Oracle Traffic Directorインスタンスの監視方法

監視方法

要件

利点

WLST

- インスタンスの様々なサブシステムのランタイム統計を表示:
プレーン・テキスト形式で表示: otd_getPerfDump

XML形式で表示: otd_getStatsXml

- DMSによって収集されたメトリック表からすべてのインスタンスまたは特定のインスタンスのランタイム統計を表示: displayMetricTables

12.4項「WLSTを使用した統計の表示」および12.7項「DMSを使用した監視」を参照してください。

管理サーバーが実行されている必要があります。

デフォルトで有効になっています。

リクエスト処理スレッドがハング中でもアクセス可能です。

ブラウザ

- 特定の仮想サーバーのXML形式での詳細統計

- 特定の仮想サーバーのプレーンテキスト形式でのサマリー統計

12.5項「ブラウザを使用したstats-xmlおよびperfdumpレポートの表示」を参照してください。

明示的に有効化し構成する必要があります。

12.3項「統計レポートへのURIアクセスの構成」を参照してください。

管理サーバーが稼働している必要はありません。インスタンスが実行中であれば十分です。

SNMP

明示的に構成する必要があります。

12.6項「SNMPを使用した監視」を参照してください。

ネットワーク管理システムを介して統計を使用できます。

12.2 統計収集設定の構成

Oracle Traffic Director構成の作成時、統計収集はデフォルで有効化され、更新の間隔は5秒に設定されます。Fusion Middleware ControlまたはWLSTのいずれかを使用して、統計収集を無効化、有効化および構成できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用した統計収集設定の構成

Fusion Middleware Controlを使用して統計収集設定を構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 統計収集設定を構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

7. 構成する仮想サーバーの名前を選択します。

8. 「設定」→「モニタリング」を選択します。

9. ページの「統計収集」セクションに移動します。

10. 変更するパラメータを指定します。

注意:
統計収集の間隔を決定する際は、統計の収集頻度を高くするとパフォーマンスに影響を及ぼすことを考慮に入れてください。

画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

11. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用した統計収集設定の構成

- 現在の統計収集プロパティを表示するには、次の例に示すように、otd_getStatsPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getStatsProperties(props)

- 統計収集プロパティを構成するには、otd_setStatsPropertiesコマンドを実行します。
たとえば、次のコマンドでは、構成で統計が更新される間隔が10秒に変更されます。

props = {}
props['configuration'] = 'foo'
props['interval'] = '10'
otd_setStatsProperties(props)

otd_getStatsPropertiesおよびotd_setStatsPropertiesの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

12.3 統計レポートへのURIアクセスの構成

12.1項「Oracle Traffic Directorインスタンスの監視方法」の説明に従い、WLSTを使用したアクティビティ統計の表示に加えて、URIを介して次のレポートを表示できます。

- stats-xml: XML形式での詳細統計。サンプルは、12.8項「XML (stats-xml)レポートのサンプル」を参照してください。

- perfdump: stats-xmlレポートのデータのサブセットを含むプレーンテキスト形式のサマリー・レポート。サンプルは、12.9項「プレーンテキスト(perfdump)レポートのサンプル」を参照してください。仮想サーバー・レベルでperf-dumpレポートを有効化することで、このレポートのデータがインスタンス・レベルで集計されます。

統計レポートへのURIベースのアクセスとWLSTによるアクセスのそれぞれの利点

- URIを介してstats-xmlおよびperfdumpレポートにユーザーがアクセスする場合、管理サーバーが実行中である必要がありません。WLSTを使用して統計にアクセスする場合と比較して、URIベースのレポートへのアクセスは、処理のオーバーヘッドを低く抑えられます。

- WLSTを使用した統計へのアクセスはデフォルトで有効化されていますが、ブラウザを介して統計を表示するには、URIベースのレポートを明示的に有効にし、ユーザーがそのレポートにアクセスできるURIを指定します。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、統計のURIベースのレポートを構成できます。

Fusion Middleware Controlを使用した統計へのURIアクセスの構成

Fusion Middleware Controlを使用してURIベースのレポートを構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. URIベースのレポートを構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

7. 構成する仮想サーバーの名前を選択します。

8. 「設定」→「モニタリング」を選択します。

9. 「設定」→「詳細設定」を選択します

10. ページの「監視」セクションに移動します。

- XML形式でのURIベースのレポートを有効化するには、「XMLレポート」チェック・ボックスを選択し、レポートの有効なURIを指定します。

- プレーンテキスト形式でのURIベースのレポートを有効化するには、「プレーン・テキスト・レポート」チェック・ボックスを選択し、レポートの有効なURIを指定します。

画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

11. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したXML形式の統計へのURIアクセスの構成

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

- 現在のXMLレポート設定を表示するには、次の例に示すように、otd_getStatsXmlPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_getStatsXmlProperties(props)

enabled=false
uri=/stats-xml

- URIベースのXMLレポートを有効にして構成するには、otd_enableStatsXmlコマンドを実行します。
たとえば、次のコマンドでは、構成fooの仮想サーバーbarに対して、XML形式でのURIベースの統計レポートが有効化され、レポートがURI/statsで使用可能になります。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['uri'] = '/stats'
otd_enableStatsXml(props)

- URIベースのXMLレポートを無効にするには、次の例に示すように、otd_disableStatsXmlコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_disableStatsXml(props)

WLSTを使用したプレーン・テキスト形式の統計へのURIアクセスの構成

- プレーンテキスト・レポート設定を表示するには、次の例に示すように、otd_getPerfDumpPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_getPerfDumpProperties(props)

- プレーンテキスト・レポートを有効にして構成するには、otd_enablePerfDumpコマンドを実行します。
たとえば、次のコマンドでは、構成fooの仮想サーバーbarに対して、プレーン・テキスト形式でのURIベースの統計レポートが有効化され、レポートがURI/perfで使用可能になります。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['uri'] = '/perf'
otd_enablePerfDump(props)

- URIベースのプレーンテキスト・レポートを無効にするには、次の例に示すように、otd_disablePerfDumpコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_disablePerfDump(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

12.4 WLSTを使用した統計の表示

WLSTを使用して、構成の1つまたはすべてのインスタンスの統計を表示できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

- インスタンスの詳細統計をXML形式で表示するには、次の例に示すように、otd_getStatsXmlコマンドを実行します。

props = {}
props['instance'] = 'otd_foo_machine1'
otd_getStatsXml(props)

レポートのサンプルは、12.8項「XML (stats-xml)レポートのサンプル」を参照してください。

- インスタンスの統計サマリーをプレーンテキスト形式で表示するには、次の例に示すように、otd_getPerfDumpコマンドを実行します。

props = {}
props['instance'] = 'otd_foo_machine1'
otd_getPerfDump(props)

レポートのサンプルは、12.9項「プレーン・テキスト(perfdump)レポートのサンプル」を参照してください。

- Oracle Dynamic Monitoring Service (DMS)によって収集されたメトリック表を使用して、構成の1つまたはすべてのインスタンスの統計を表示するには、次の例に示すように、displayMetricTablesコマンドを実行します。Oracle Dynamic Monitoring Service (DMS)の詳細は、12.7項「DMSを使用した監視」を参照してください
すべてのOracle Traffic Directorインスタンスのメトリックを表示するには:

displayMetricTables('OTD_*')

すべてのインスタンスのオリジン・サーバー・メトリックを表示するには:

displayMetricTables('OTD_OriginServer')

特定のインスタンスのメトリック表のリストを取得するには:

displayMetricTableNames(servers='/OTD/otd_test_myserver.example.com')

特定のインスタンスのすべてのメトリックを表示するには:

displayMetricTables(servers='/OTD/otd_test_myserver.example.com')

特定のインスタンスのインスタンス・メトリックを表示するには:

displayMetricTables('OTD_Instance', servers='/OTD/otd_test_myserver.example.com')

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

12.5 ブラウザを使用したstats-xmlおよびperfdumpレポートの表示

12.3項「統計レポートへのURIアクセスの構成」の説明に従ってURIアクセスを有効にすると、次のURLを使用し、ブラウザを介してstats-xmlおよびperfdumpレポートにアクセスできます。

http://host:port/uri

hostおよびportは、統計へのURIアクセスを有効化した仮想サーバーのIPアドレス(またはホスト名)およびポート番号です。uriは、URIアクセスを有効化するときに指定した場所です。仮想サーバーが複数のリスナーに関連付けられている場合、任意のリスナーのアドレスhost:portを使用してURIベースのレポートにアクセスできます。

- たとえば、/perfdumpが、仮想サーバーsoa.example.com:1904のプレーンテキスト・レポート用に構成されたURIである場合、レポートのアクセスに使用する必要があるURLは次のようになります。

http://soa.example.com:1904/perfdump

次の例に示すように、ブラウザでperfdumpレポートを自動的にリフレッシュする間隔(秒数)をURL内に指定することもできます。

http://soa.example.com:1904/perfdump?refresh=5

- 同様に、/stats-xmlが、仮想サーバーsoa.example.com:1904のXMLレポート用に構成されたURIである場合、XMLレポートのアクセスに使用する必要があるURLは次のようになります。

http://soa.example.com:1904/stats-xml

表示させない要素を指定するURL問合せ文字列を指定することで、XMLレポートに表示されるデータを制限できます。問合せ文字列を含めない場合、XMLレポート内のすべての要素が表示されます。

たとえば、次のURLに指定された問合せ文字列では、XMLレポートでvirtual-serverおよびserver-pool要素が表示されなくなります。

http://soa.example.com:1904/stats-xml?virtual-server=0&server-pool=0

次のリストは、統計XMLレポート内の要素の階層を示しています。レポート内で要素を表示しないように選択した場合、その要素の子要素も表示されなくなることに注意してください。

stats
server
process
connection-queue
thread-pool
dns
keepalive
thread
request-bucket
profile-bucket
compression
decompression
origin-server-pool
origin-server
websocket
service-queue
virtual-server
request-bucket
websocket
webapp-firewall
profile-bucket
route
request-bucket
cpu-info
tcp-proxy
cache
failover
partition
request-bucket
ssl-session-cache

12.6 SNMPを使用した監視

Simple Network Management Protocol (SNMP)は、ネットワーク内のデバイスの管理を、リモート・システムで実行されているネットワーク管理アプリケーションからできるようにするための標準プロトコルです。たとえば、ネットワーク管理アプリケーションには、任意の時点でネットワーク内のどのサーバーが稼働中または停止中であるか、また受信したエラー・メッセージの数およびタイプなどが示されます。

SNMPを使用して、Oracle Traffic Directorインスタンスを監視できます。これを可能にするには、次の操作を行う必要があります。

- SNMPを介した監視をサポートするようにインスタンスを構成します。

- ノードでSNMPサブエージェントを構成します。

- ノードでSNMPサブエージェントを起動します。

この項の内容は次のとおりです。

- 12.6.1項「Oracle Traffic DirectorのSNMPサポートの構成」

- 12.6.2項「SNMPサブエージェントの構成」

- 12.6.3項「SNMPサブエージェントの起動および停止」

- 12.6.4項「snmpwalkを使用した統計の表示」

12.6.1 Oracle Traffic DirectorのSNMPサポートの構成

構成の作成時、SNMPを介したインスタンスの監視サポートはデフォルトで有効化されます。Fusion Middleware ControlまたはWLSTのいずれかを使用して、SNMPによる監視のサポートを無効化、有効化および構成できます。

Fusion Middleware Controlを使用したSNMPサポートの構成

Fusion Middleware Controlを使用してSNMPサポートを有効にするには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. SNMPサポートを有効化する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「設定」を選択します。
「設定」ページが表示され、スクロール・ダウンするとSNMP設定が表示されます。

7. ページの「SNMP」セクションで、「SNMP」チェック・ボックスを選択します。このセクションのその他のパラメータはオプションです。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

8. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したSNMPサポートの構成

- 構成の現在のSNMP設定を表示するには、次の例に示すように、otd_getSnmpPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getSnmpProperties(props)

- SNMPはデフォルトで有効になっています。SNMPサポートを有効または無効にするには、次の例に示すように、otd_setSnmpPropertiesコマンドを実行します。

props = {}
props['enabled'] = 'true'
props['organization'] = 'bar'
otd_setSnmpProperties(props)

この項で説明したカスタムWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

12.6.2 SNMPサブエージェントの構成

Oracle Traffic Directorノードを作成するときに、SNMPサブエージェントは自動的に作成されます。SNMPサブエージェントにより、ノードで実行中のインスタンスについての情報が収集されます。

SNMPサブエージェントの構成設定(サブエージェントにより統計が更新される頻度、キャッシュされた統計がタイムアウトになるまでの時間、サブエージェント・プロセスの通信ポートなど)は、次のファイルに格納されます。

INSTANCE_HOME/admin-server/config/snmpagt.conf

snmpagt.confファイルを編集して、SNMPサブエージェントの設定を構成できます。表12-2は、主要なSNMPサブエージェント・パラメータを示しています。

表12-2 SNMPサブエージェント構成パラメータ

smnpagt.conf内のパラメータ

説明

デフォルト値

agentAddress

SNMPサブエージェントがリクエストを受信するポート

11161

statInterval

統計の更新頻度(秒)

5

cacheTimeOut

キャッシュ・タイムアウト時間(秒)

5

snmpagt.conf内のエントリの構文は、http://www.net-snmp.org/docs/man/snmpd.conf.htmlにあるsnmpd.confのドキュメントにある説明に従う必要があります。

ノードでSNMPサブエージェントを構成した後、これを起動する必要があります。その後、サブエージェントにより、ノード上のOracle Traffic Directorインスタンスについての統計の収集が開始されます。

12.6.2.1 SNMP v3のユーザー構成

SNMPは、インストール時にデフォルトでは構成されず、OTDのSNMPに追加されるアクセス制御はありません。アクセス制御を提供するには、1つ以上のSNMP v3ユーザーを追加する必要があります。

SNMP v3ユーザーの追加

Fusion Middleware Controlを使用してノード上のSNMPサブエージェントを起動または停止するには、次を実行します。

1. SNMPエージェントが実行中の場合は停止し、次の行を追加します

Persistent file<oracle_home>/otd_domain/config/fmwconfig/components/OTD/snmp/store/ snmpagt.conf

createUser username SHA authpassphrase [DES|AES] [privpassphrase]

SHAは、使用する認証タイプです

DESおよびAESは、使用するプライバシ・プロトコルです

authpassphraseは、usernameを認証するパスワードです

privpassphraseは、SNMPのリクエストおよびレスポンスを暗号化するパスワードです

Configuration file<oracle_home>/otd_domain/config/fmwconfig/components/OTD/snmp/config /snmpagt.conf

rouser username [noauth|auth|priv]

ユーザーは、認証レベルを構成できます。

noauth: 認証されていないリクエストを許可します

auth: authpassphraseとユーザー名の認証を強制します

priv: 暗号化の使用を強制します

2. 前述のようにSNMP v3ユーザーを追加したら、OTDのSNMPエージェントを1回、起動および停止する必要があります。停止中に、「createUser」行に指定したユーザー認証パラメータが暗号化され、永続ファイルに保存されます。

3. OTDのSNMPエージェントを起動します。1つまたは複数のインスタンスの起動を確認してください。

4. snmpwalkコマンドを実行します。ユーザーは、リモート・ホストからsnmpcmdを実行することもできます。

snmpcmd(snmpwalk/snmpget)

snmpwalk -m <path to OTD mib>/ORACLE-TRAFFICDIRECTOR-MIB.txt -v 3 -u username -l<authentication level> -a SHA -A authpassphrase -x (DES|AES) -X privpassphrase <hostname>:11161 ORACLE-TRAFFICDIRECTOR-MIB::originServer

SNMP v3ユーザーの削除

とても簡単です。単に、confファイルと永続ファイルからエントリを削除します。

デフォルト値の設定によるコマンドの簡素化

snmpwalkのコマンドラインのほとんどは、~/.snmp/snmp.confに追加できます。

デフォルト・オプション

defSecurityNam

SNMPv3のユーザー名

defAuthType

認証メソッド(MD5またはSHAのいずれか)

defSecurityLevel

ユーザーのセキュリティ・レベル。authNoPriv、authPrivなど

defAuthPassphrase

authpassphrase

defPrivType

使用するプライバシ・プロトコル。DESまたはAES

defPrivPassphrase

privpassphrase

defVersion

3

defaultport

11161

mibirds

+<ORACLE-TRAFFICDIRECTOR-MIB.txtへのパス>

mibs

+ORACLE-TRAFFICDIRECTOR-MIB

agentxとしての実行

OTDのSNMPはagentxプロトコルをサポートし、agentxとして通信するため、agentxをサポートするもう1つのSNMPエージェントを必要とします。OEL 6およびSolaris 11 OSのSNMPエージェント(snmpd)は、agentxをサポートしています。OTDのSNMPがagentxとして実行されている場合は、snmpcmdsを受け付けることができません。すべてのリクエストは、マスターとして動作しているSNMPエージェントに対して行う必要があります。マスター・エージェントにより、リクエストがOTDのSNMPエージェントに転送されます。

OTDのSNMPエージェントのagentxとしての構成

ユーザーは、snmpdのmanページで指定されているようにトランスポート層を変更できます。OTDのSNMPのデフォルトのagentxトランスポート指定は次のとおりです。

agentxsocket tcp:127.0.0.1:705

OSのSNMPエージェントのagentxとしての構成

/etc/snmp/snmpd.conf

master agentxagentxsocket tcp:127.0.0.1:705

snmpdデーモンは手動で起動する必要があり、接続の詳細はsnmpd.logに記録され、snmpリクエストはsnmpd(デフォルトは161)のsnmpポートに送信する必要があります。

12.6.3 SNMPサブエージェントの起動および停止

Fusion Middleware ControlまたはWLSTのいずれかを使用して、ノード上のSNMPサブエージェントを起動および停止できます。

Fusion Middleware Controlを使用したSNMPサブエージェントの起動および停止

Fusion Middleware Controlを使用してノード上のSNMPサブエージェントを起動または停止するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
使用可能なノードのリストが表示されます。

3. ノード・リストから、SNMPサブエージェントを起動または停止するノードを選択します。
一般設定ページが表示されます。

- SNMPサブエージェントを起動するには、「SNMPサブエージェントの起動」をクリックします。ステータスが「実行中」に変わります。

- サブエージェントを停止するには、「SNMPサブエージェントの停止」をクリックします。ステータスが「実行中」に変わります。

4. 変更するパラメータを指定してから、「保存」をクリックします。
「コンソール・メッセージ」ペインに、更新した設定が保存されたことを示すメッセージが表示されます。

5. 「共通のタスク」ペインで、「再起動」をクリックして管理サーバーを再起動します。

WLSTを使用したSNMPサブエージェントの起動および停止

- SNMPサブエージェントを1つまたは複数のノードで起動するには、次の例に示すように、otd_startSnmpSubAgentコマンドを実行します。

# Online
props = {}
props['machine-name'] = 'abc123.example.com'
otd_startSnmpSubAgent(props)

# Offline
props = {}
props['domain-home'] = '/export/domains/otd_domain'
otd_startSnmpSubAgent(props)

注意:
また、サブエージェントの構成ファイルを構成して、agentxモードでSNMPエージェントを起動することもできます。
agentxモードでは、SNMPエージェントはオペレーティング・システムのマスター・エージェント(snmpd)と通信する必要があります。したがって、次の操作を実行して、agentxプロトコルをリスニングするようにsnmpdを構成する必要があります。

1. (/etc/snmp/snmpd.conf)にあるオペレーティング・システム・マスター・エージェント(snmpd)に、次のトークンを追加してagentxを使用可能にします。このトークンは、指定するagentxパスにマスター・エージェントを接続できるようにします。
master agentx

2. 次の例に示すように、ORACLE_HOME/admin-server/config/snmpagt.confファイルにソケット・パスおよびソケット・パス権限を指定します。
agentxの構成前

agentuser admin123
agentxsocket /tmp/snmpagt-e6d7cd20/snmpagt.socket

agentxの構成後

agentxsocket /tmp/snmpagt-e6d7cd20/snmpagt.socket
agentxperms 0755 0755 admin123 admin123

3. snmpdデーモンを手動で開始します。

- SNMPサブエージェントを1つまたは複数のノードで停止するには、次の例に示すように、sotd_stopSnmpSubAgentコマンドを実行します。

# Online
props = {}
props['machine-name'] = 'host.example.com'
otd_stopSnmpSubAgent(props)

# Offline
props = {}
props['domain-home'] = '/export/domains/otd_domain'
otd_stopSnmpSubAgent(props)

この項で説明したカスタムWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

12.6.4 snmpwalkを使用した統計の表示

注意:
snmpwalkを使用するための前提条件は、次のとおりです。

- Linuxの場合: コンテンツsnmpwalkパッケージnet-snmp-utils-5.3.2.2-9.0.1.el5_5.1 RPM以上および標準のMIBパッケージnet-snmp-5.3.2.2-9.0.1.el5_5.1 RPM以上がインストールされていることを確認してください。

- Solarisの場合: system/management/snmp/net-snmpにあるパッケージがインストールされていることを確認してください。このパッケージにはコンテンツsnmpwalkと標準MIBが含まれています。

注意:
snmpwalkのほとんどのオプションは、snmpwalkの使用前に<user-home>/.snmp/snmp.confにあるsnmp.confファイルで設定できます。snmp.confでオプションを設定しておくと、snmpwalkコマンドを実行するときにsnmp.confで設定済のオプションを指定する必要がないため便利です。たとえば、snmp.confでは次のオプションを設定できます。

defaultport  11161
defversion   3
defcommunity  public
mibdirs  +<path to ORACLE-TRAFFICDIRECTOR-MIB.txt> #
mibdirs  + <otd_install_root>/lib/snmp #
mibs  +ORACLE-TRAFFICDIRECTOR-MIB

これらのオプションを設定しておくと、snmpwalkを次のように実行できます。

snmpwalk  <hostname> ORACLE-TRAFFICDIRECTOR-MIB::originServerTable

snmp.confを使用して設定できるオプションは、snmp.confのmanページで確認できます。

SNMPバージョン2c

Net-SNMPアプリケーション・スイート(http://www.net-snmp.org)で使用可能なsnmpwalkコマンドライン・ユーティリティを使用して、SNMPサブエージェントが収集した統計を表示できます。

snmpwalkコマンドの構文の例を次に示します。

> snmpwalk -c public -v 3 host:port oid

- hostは、監視するOracle Traffic Directorノードのホスト名です。

- portは、ノード上のSNMPサブエージェントのリスニング・ポートです。snmpagt.confファイルに指定されているデフォルト・ポートは、11161です。

- oidは、統計を表示する対象の一連の一意のオブジェクト識別子です。Oracle Traffic Director製品のOIDは、1.3.6.1.4.1.111.19.190です。

注意:
OIDは、Internet Assigned Numbers Authorityによって割り当てられ、維持されます。Oracle Traffic DirectorのOIDで、最初の6つの番号の1.3.6.1.4.1は民間企業を表し、111はOracleの一意の識別子であり、19.190はOracle Traffic Director製品を表します。OIDの構造の詳細は、RFC 2578 (http://tools.ietf.org/html/rfc2578)を参照してください。

SNMPバージョン3

SNMP v3を使用して統計を監視するには、次の操作を行います。

1. rootユーザーとして次のコマンドを実行して、SNMP v3を作成します。

$ sudo net-snmp-config --create-snmpv3-user -ro -a SHA1 -A abcd1234 otdadmin

このコマンドでは次の処理が行われます。

- /var/net-snmp/snmpd.confへの次のエントリの追加:

createUser otdadmin SHA1 "abcd1234" DES

- /etc/net-snmp/snmp/snmpd.confへの次のエントリの追加:

rouser otdadmin

2. snmpdを起動および停止します。

$ sudo /etc/init.d/snmpd start
Starting snmpd:                                            [  OK  ]

$ sudo /etc/init.d/snmpd stop
Stopping snmpd:                                            [  OK  ]

snmpdを起動および停止した結果として、/var/net-snmp/snmpd.confファイル内のcreateUserエントリが、次の例に示すように変更されます。

usmUser 1 3 0x80001f8801819ee527 0x676164686100 0x676164686100 NULL
.1.3.6.1.6.3.10.1.1.2
0x8b6a9b458c0cb628aa5ba10ebbec48e7 .1.3.6.1.6.3.10.1.2.2
0x8b6a9b458c0cb628aa5ba10ebbec48e7 ""

この例では、0x80001f8801819ee527は生成されたエンジンIDです。

3. SNMPエージェントをagentxモードで実行します。
次のコマンドを使用してsnmpwalkを実行します。snmpdのデフォルト・ポートは161です。

snmpwalk -v3 -u otdadmin -l authNoPriv  -a SHA1 -A abcd1234 localhost:161 1.3.6.1.4.1

数値OIDではなくMIBオブジェクト名を表示するsnmpwalkコマンドの有効化

snmpwalkコマンドを実行すると、次のように出力されます。

SNMPv2-SMI::enterprises.111.19.190.1.20.1.2.0.0 = INTEGER: 645
SNMPv2-SMI::enterprises.111.19.190.1.20.1.3.0.0 = Gauge32: 4
SNMPv2-SMI::enterprises.111.19.190.1.20.1.4.0.0 = Gauge32: 4
SNMPv2-SMI::enterprises.111.19.190.1.20.1.10.0.0 = Gauge32: 0
SNMPv2-SMI::enterprises.111.19.190.1.20.1.11.0.0 = Gauge32: 3072
SNMPv2-SMI::enterprises.111.19.190.1.20.1.12.0.0 = Counter64: 0
SNMPv2-SMI::enterprises.111.19.190.1.20.1.13.0.0 = Counter64: 0
SNMPv2-SMI::enterprises.111.19.190.1.20.1.14.0.0 = STRING: "0.0000"

出力内の各行はメトリックの値を示しますが、OIDは数値形式で表示されるため、特定のメトリックの名前を識別するのは困難です。snmpwalkユーティリティを使用すると、管理情報ベース(MIB)定義を使用して、数値のOIDをテキスト名に解決できます。Oracle Traffic Directorでは、MIB定義ファイルは、次のディレクトリにあります。

ORACLE_HOME/lib/snmp/ORACLE-TRAFFICDIRECTOR-MIB.txt

数値のOIDではなくMIBオブジェクト名を表示するsnmpwalkコマンドを有効化するには、次のいずれかを行います。

- Oracle Traffic Director MIBをポイントするように、ホストでMIBS環境変数を設定します。

> set env MIBS=+ORACLE-TRAFFICDIRECTOR-MIB

次に、snmpwalkコマンドを実行して、必要なMIBオブジェクトの出力をgrepするか、必要なMIBオブジェクト名を明示的に指定します。

たとえば、ノードapp1で実行中のOracle Traffic Directorインスタンスのプロキシ・キャッシュ・パラメータの統計を表示するには、次のコマンドを実行します。

> snmpwalk snmpwalk -c public -v 2c app1:11161 ORACLE-TRAFFICDIRECTOR-MIB::proxyCacheTable

ORACLE-TRAFFICDIRECTOR-MIB::proxyCacheEnabledFlag.0.0 = INTEGER: enabled(1)
ORACLE-TRAFFICDIRECTOR-MIB::proxyCacheCountEntries.0.0 = Counter64: 0
ORACLE-TRAFFICDIRECTOR-MIB::proxyCacheSizeHeap.0.0 = Counter64: 16498
ORACLE-TRAFFICDIRECTOR-MIB::proxyCacheCountContentHits.0.0 = Counter64: 0
ORACLE-TRAFFICDIRECTOR-MIB::proxyCacheCountContentMisses.0.0 = Counter64: 0
ORACLE-TRAFFICDIRECTOR-MIB::proxyCacheCountHits.0.0 = Counter64: 0
...

- snmpwalkコマンドで-mオプションを使用して、Oracle Traffic Director MIBを明示的に指定します。
たとえば、ローカル・ホストで実行中のOracle Traffic Directorインスタンスのオリジン・サーバー名を表示するには、次のコマンドを実行します。

> snmpwalk -c public -v 2c -m $ORACLE_HOME/lib/snmp/ORACLE-TRAFFICDIRECTOR-MIB.txt localhost:11161 ORACLE-TRAFFICDIRECTOR-MIB::originServerName

特定の統計の問合せに使用できるSNMP MIBオブジェクト名のリストは、付録A「Oracle Traffic Directorで追跡されるメトリック」を参照してください。

snmpwalkの詳細は、http://www.net-snmp.org/docs/man/snmpwalk.htmlにあるドキュメントを参照してください。

12.7 DMSを使用した監視

Oracle Dynamic Monitoring Service (DMS)では、パフォーマンス・メトリックを測定およびレポートし、パフォーマンスをトレースするJavaおよびCのAPIセットが提供され、Fusion Middlewareおよびその他のOracle製品用のコンテキスト相関サービスが提供されます。このAPIとは別に、DMSでは、アプリケーション開発者、サポート・アナリスト、システム管理者、その他のユーザーが、アプリケーション固有のパフォーマンス情報を測定できるインタフェースが提供されます。

OTD用のDMSメトリックは、メトリック表のセットとして使用できます(「DMSメトリック表」を参照)。監視データは、単一のコンポーネント・メトリックMBeanを介してDMSに公開されます。DMSがOTDインスタンスのデータの監視をリクエストすると、指定されたOTDインスタンスから統計情報を取得するため、対応するノード・マネージャでプラグイン(MetricsPlugin)が起動されます。このプラグインは、監視データを取得するために、ネイティブのOTDインタフェースを介してOTDインスタンスと通信します。ノード・マネージャから返された監視データは5秒間管理サーバーにキャッシュされ、その間、DMSからのすべての監視データのリクエストはキャッシュのデータを利用して処理されます。

DMSのメトリックは、DMSスパイ・サーブレットやOracle Fusion Middleware Controlなど、様々なインタフェースを使用して表示できます。また、DMSのカスタムWLSTコマンドを使用してメトリックを表示することもできます。詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のDMSのカスタムWLSTコマンドに関する項を参照してください。

例12-1 DMSのカスタムWLSTコマンドを使用したDMSメトリックの表示

# View metrics for all OTD instances
displayMetricTables('OTD_*')

# View origin server metrics for all instances
displayMetricTables('OTD_OriginServer')

# Get list of metric tables for a specific instance
displayMetricTableNames(servers='/OTD/otd_test_myserver.example.com')

# View all metrics for a specific instance
displayMetricTables(servers='/OTD/otd_test_myserver.example.com')

# View instance metrics for a specific instance
displayMetricTables('OTD_Instance', servers='/OTD/otd_test_myserver.example.com')

# Dump all metrics for a specific instance
dumpMetrics(servers='/OTD/otd_test_myserver.example.com')

12.8 XML (stats-xml)レポートのサンプル

この項では、otd_getStatsXmlコマンドを使用して、またはURIを介して表示できる、XML形式での統計レポートのサンプルを示します。詳細は、12.4項「WLSTを使用した統計の表示」および12.5項「ブラウザを使用したstats-xmlおよびperfdumpレポートの表示」を参照してください。

このサンプル・レポートに示されている値は、意味のないものである場合があることに注意してください。このサンプル・レポートは、単にレポートに含まれるメトリック、およびレポートの形式や構造の概要を示すことを目的にしています。

<?xml version="1.0" encoding="utf-8"?>
<stats versionMajor="1" versionMinor="3" flagEnabled="1">
<server id="otd_OTD_rechaita" versionServer="Oracle Traffic Director 12.2.1.0.0 B20150908.132940 (Linux)" timeStarted="1442991226" secondsRunning="119" ticksPerSecond="1000" maxProcs="1" maxThreads="512" flagProfilingEnabled="1" load1MinuteAverage="0.070000" load5MinuteAverage="0.070000" load15MinuteAverage="0.050000" rateBytesTransmitted="10087" rateBytesReceived="4929" requests1MinuteAverage="0.000000" requests5MinuteAverage="0.000000" requests15MinuteAverage="0.000000" errors1MinuteAverage="0.000000" errors5MinuteAverage="0.000000" errors15MinuteAverage="0.000000" responseTime1MinuteAverage="0.000000" responseTime5MinuteAverage="0.000000" responseTime15MinuteAverage="0.000000">
<connection-queue id="cq1"/>
<thread-pool id="thread-pool-0" name="NativePool"/>
<profile id="profile-0" name="all-requests" description="All requests"/>
<profile id="profile-1" name="default-bucket" description="Default bucket"/>
<profile id="profile-2" name="cache-bucket" description="Cached responses"/>
<process pid="7236" mode="active" timeStarted="1442991226" countConfigurations="1" sizeVirtual="862916" sizeResident="32288" fractionSystemMemoryUsage="0.0022">
<connection-queue connectionQueueId="cq1" countTotalConnections="0" countQueued="0" peakQueued="0" maxQueued="12288" countOverflows="0" countTotalQueued="0" ticksTotalQueued="0" countQueued1MinuteAverage="0.000000" countQueued5MinuteAverage="0.000000" countQueued15MinuteAverage="0.000000"/>
<thread-pool threadPoolId="thread-pool-0" countIdleThreads="1" countThreads="1" maxThreads="128" countQueued="0" peakQueued="0" maxQueued="0"/>
<dns flagCacheEnabled="1" countCacheEntries="0" maxCacheEntries="1024" countCacheHits="0" countCacheMisses="0" flagAsyncEnabled="0" countAsyncNameLookups="0" countAsyncAddrLookups="0" countAsyncLookupsInProgress="0"/>
<keepalive countConnections="0" maxConnections="24576" countHits="0" countFlushes="0" countRefusals="0" countTimeouts="0" secondsTimeout="30"/>
<compression countRequests="0" bytesInput="0" bytesOutput="0" compressionRatio="0.000000" pageCompressionAverage="0.000000"/>
<decompression countRequests="0" bytesInput="0" bytesOutput="0"/>
<thread mode="idle" timeStarted="1442991226" connectionQueueId="keep-alive">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
</thread>
<thread mode="idle" timeStarted="1442991226" connectionQueueId="keep-alive">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
</thread>
<thread mode="idle" timeStarted="1442991226" connectionQueueId="keep-alive">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
</thread>
<thread mode="idle" timeStarted="1442991226" connectionQueueId="keep-alive">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
</thread>
<thread mode="idle" timeStarted="1442991226" connectionQueueId="cq1">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
</thread>
<thread mode="idle" timeStarted="1442991226" connectionQueueId="cq1">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
</thread>
<thread mode="idle" timeStarted="1442991226" connectionQueueId="cq1">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
</thread>
<thread mode="idle" timeStarted="1442991226" connectionQueueId="cq1">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
</thread>
</process>
<virtual-server id="OTD" flagEnabled="1">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<webapp-firewall countRequestsIntercepted="0" countRequestsAllowed="0" countRequestsDenied="0" countRequestsDropped="0" countRequestsRedirected="0" countRequestsDenyDetected="0" countRequestsDropDetected="0" countRequestsRedirectDetected="0"/>
<websocket countUpgradeRequests="0" countUpgradeRequestsFailed="0" countUpgradeRequestsRejected="0" countActiveConnections="0" countRequestsAborted="0" countRequestsTimedout="0" countBytesReceived="0" countBytesTransmitted="0" millisecondsConnectionActiveAverage="0"/>
<route id="default-route" condition="default">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
</route>
</virtual-server>
<virtual-server id="virtual-server-1" flagEnabled="1">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-1" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<webapp-firewall countRequestsIntercepted="0" countRequestsAllowed="0" countRequestsDenied="0" countRequestsDropped="0" countRequestsRedirected="0" countRequestsDenyDetected="0" countRequestsDropDetected="0" countRequestsRedirectDetected="0"/>
<websocket countUpgradeRequests="0" countUpgradeRequestsFailed="0" countUpgradeRequestsRejected="0" countActiveConnections="0" countRequestsAborted="0" countRequestsTimedout="0" countBytesReceived="0" countBytesTransmitted="0" millisecondsConnectionActiveAverage="0"/>
<route id="default-route" condition="default">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="0" count2xx="0" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="0" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
</route>
</virtual-server>
<cache flagEnabled="1" countEntries="0" sizeHeapCache="16516" countContentHits="0" countContentMisses="0" countHits="0" countRevalidationRequests="0" countRevalidationFailures="0"/>
<cpu-info cpu="1" percentIdle="99.268188" percentUser="0.426176" percentKernel="0.305636"/>
<cpu-info cpu="2" percentIdle="99.476388" percentUser="0.336554" percentKernel="0.187058"/>
<cpu-info cpu="3" percentIdle="99.518723" percentUser="0.300850" percentKernel="0.180426"/>
<cpu-info cpu="4" percentIdle="99.537347" percentUser="0.292632" percentKernel="0.170021"/>
</server>
</stats>

12.9 プレーンテキスト(perfdump)レポートのサンプル

この項では、perfump統計レポートのサンプルを示します。このレポートは、otd_getPerfDumpコマンドを使用して、またはURIを介して表示できます。プレーンテキスト・レポートの表示の詳細は、12.4項「WLSTを使用した統計の表示」および12.5項「ブラウザを使用したstats-xmlおよびperfdumpレポートの表示」を参照してください。

このサンプル・レポートに示されている値は、意味のないものである場合があることに注意してください。このサンプル・レポートは、単にレポートに含まれるメトリック、およびレポートの形式の概要を示すことを目的にしています。

Oracle Traffic Director 12.2.1.0.0 B20150908.132940 (Linux)
Server started Tue Sep 22 23:53:45 2015
Process 7236 started Tue Sep 22 23:53:45 2015
ConnectionQueue
Current/Peak/Limit Queue Length            0/0/12288
Total Connections Queued                   0
Average Queue Length (1, 5, 15 minutes)    0.00, 0.00, 0.00
Average Queuing Delay                      0.00 milliseconds
HTTP Listener http-listener-1
Address                   0.0.0.0:8080
Acceptor Threads          1
Default Virtual Server    OTD
KeepAliveInfo
KeepAliveCount        0/24576
KeepAliveHits         0
KeepAliveFlushes      0
KeepAliveRefusals     0
KeepAliveTimeouts     0
KeepAliveTimeout      30 seconds
SessionCreationInfo
Active Sessions                0
Keep-Alive Sessions            0
Keep-Alive threads             4
HTTP Sessions current/max      8/516
TCP Sessions current/max       4/4
Cache
Cache Enabled                    yes
Object Cache Entries             0
Cache lookup (hits/misses)       0/0
Requests served from Cache       0
Revalidation (successful/total)  0/0 (  0.00%)
Heap space used                  16516
Thread Pool NativePool
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0
DNSCacheInfo
enabled             yes
CacheEntries        0/1024
HitRatio            0/0 (  0.00%)
Async DNS disabled
Performance Counters
Total number of requests                   0
Average Request processing time       0.0000
Total Request processing time         0.0000
default-bucket (Default bucket)
Counter Name               Average         Total      Percent
-------------------------------------------------------------
Number of Requests                             0    (  0.00%)
Number of Invocations                          0    (  0.00%)
Latency                     0.0000        0.0000    (  0.00%)
Function Processing Time    0.0000        0.0000    (  0.00%)
Total Response Time         0.0000        0.0000    (  0.00%)
HTTP Origin Servers
No HTTP origin servers are configured
TCP Origin Servers
No TCP origin servers are configured
TCP Proxy
Active Connections                  0
Avg Duration                        0.00 seconds
Requests (timeout/aborted/total)    0/0/0

13 イベント通知

Oracle Traffic Directorでは、検出されたイベントに関する通知をサブスクライブすることができます。こうした通知を受け取るには、選択したHTTPエンドポイントのURLを指定します。OTDは、検出されたイベントに関する情報をHTTP POSTメッセージを介してこのURLに送信します。HTTP POSTリクエストにはイベント情報がJSON形式で含まれます。Oracle Traffic Directorは、次の2つのイベントに関する通知をサポートしています。

- オリジン・サーバーのステータス変更イベント

- リクエスト制限の超過イベント

13.1 オリジン・サーバーのステータス変更イベント

Oracle Traffic Directorは、オリジン・サーバーのステータス変更を検出した時に、構成されたHTTPエンドポイントURLに通知を送信します。

オリジン・サーバーのステータス変更イベントは、次の2つのイベントのうちの1つが発生した場合に生じると考えられています。

- OTDがオリジン・サーバーをオフラインとしてマークする。

- OTDがオリジン・サーバーのマーク付けをオフラインからオンラインに戻す。

通知メッセージは、構成の一部であるいずれかのオリジン・サーバーのステータスが変更された時に送信されます。通知をサブスクライブしながら、関心のある特定のオリジン・サーバーに関する通知を受け取ることはできません。

複数のオリジン・サーバー・プールまたは複数のOracle Traffic Directorインスタンスの一部であるオリジン・サーバーのステータスが変更された場合、複数の通知が送信されることがあります。

13.1.1 Fusion Middleware Controlを使用したオリジン・サーバーのステータス・イベントのサブスクライブ

1. Fusion Middleware Controlの表示の説明に従ってTraffic DirectorのFusion Middleware Controlにログインします。

2. ページの左上隅または右上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能なOTD構成のリストが表示されます。

イベント・サブスクリプションを有効化する構成を選択します。

4. 「構成」→「詳細構成」→「イベント・サブスクリプション」を選択します。
「イベント・サブスクリプション」ページが表示されます。

5. 「共通タスク」ペインで、「イベント・サブスクリプション」の下の「作成」をクリックします。
「新規イベント・サブスクリプション」ウィザードが開始されます。

図13-1「新規イベント・サブスクリプション」ウィザード

6. 画面上のプロンプトに従い、前に決定済みの詳細(サブスクリプション名、URLなど)を使用して、イベント・サブスクリプションの作成を完了します。

7. 「結果」画面で、「OK」をクリックします。
イベント・サブスクリプションが作成されたら、「新規イベント・サブスクリプション」ウィザードの「結果」画面にイベント・サブスクリプションの作成成功を確認するメッセージが表示されます。

13.1.2 WLSTを使用したオリジン・サーバーのステータス変更イベントのサブスクライブ

- イベント・サブスクリプションの作成

イベント・サブスクリプションを作成するには、例に示すように、otd_createEventSubscriptionコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['event-subscription'] = 'bar'
props['url'] = 'http://example.com:7777/subscriber'
otd_createEventSubscription(props)

最初のコマンドはURL: http://example.com:7777/subscriberをサブスクライブします。

- イベント・サブスクリプションのリストの表示
サブスクライブされているイベント・サブスクリプションのリストを表示するには、otd_listEventSubscriptionsコマンドを実行します。

たとえば、構成のインスタンスにスケジュールされているイベント・サブスクリプションを表示するには、次のようにします。

props = {}
props['configuration'] = 'foo'
otd_listEventSubscriptions(props)

- イベント・サブスクリプションの削除
イベント・サブスクリプションを削除するには、例に示すように、otd_deleteEventSubscriptionコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['event-subscription'] = 'bar'
otd_deleteEventSubscription(props)

- イベント・サブスクリプションのプロパティの設定
イベント・サブスクリプションを作成すると、それは自動的に有効になります。

「enabled」を「false」に設定したコマンドotd_setEventSubscriptionPropertiesは、イベント・サブスクリプションを無効化するために使用できます。

イベントを無効にするには、enabledプロパティをfalseに設定します。

props = {}
props['configuration'] = 'foo'
props['event-subscription'] = 'bar'
props['enabled'] = 'true'
otd_setEventSubscriptionProperties(props)

- イベント・サブスクリプションのプロパティの取得
「enabled」を「true」に設定したコマンドotd_getEventSubscriptionPropertiesは、イベント・サブスクリプションのプロパティを取得するために使用されます。

イベントを有効にするには、enabledプロパティを次にようにtrueに設定します。

props = {}
props['configuration'] = 'foo'
props['event-subscription'] = 'bar'
otd_getEventSubscriptionProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

コマンドと各パラメータ/オプションの詳細を確認するには、下に示すように、helpを使用します。

help('otd_createEventSubscription')

13.1.3 通知形式

サブスクライブされているURLに対する通知が送信された場合、Content-typeヘッダーの値にはapplication/jsonが設定されます。イベントが発生すると、OTDはHTTP POSTをエンドポイントに送信します。そのメッセージ本文には、この項で説明したように、名前/値のペアを持つJSONドキュメントが含まれています。

表13-1 すべてのイベントに共通するJSONプロパティ

JSONプロパティ

説明

event-type

イベントのタイプ。値: origin-server-status-change。

domain-name

Oracle Traffic Directorインスタンスが構成されたドメインの名前。

instance-name

Oracle Traffic Directorインスタンスの名前。

timestamp

イベントが発生し、OTDによって検出された時間。

表13-2 origin-server-status-changeイベントに固有のJSONプロパティ

JSONプロパティ

説明

pool-name

オリジン・サーバーが関連付けられているオリジン・サーバー・プールの名前。

host

ステータスが送信されているオリジン・サーバーのホスト。

port

オリジン・サーバーのポート。

status

オンラインまたはオフライン。

reason

Oracle Traffic Directorがオリジン・サーバーをオフラインまたはオンラインとしてマークしている理由。

protocol

使用されているヘルス・チェック・プロトコル。

13.1.3.1 JSONスキーマ

{
"$schema":"http://json-schema.org/draft-04/schema#",
"id":"",
"type":"object",
"properties":{
"v1.0":{
"id":"/v1.0",
"type":"object",
"properties":{
"event-type":{
"id":"/v1.0/event-type",
"type":"string"
},
"domain-name":{
"id":"/v1.0/domain-name",
"type":"string"
},
"instance-name":{
"id":"/v1.0/instance-name",
"type":"string"
},
"origin-server":{
"id":"/v1.0/origin-server",
"type":"object",
"properties":{
"pool-name":{
"id":"/v1.0/origin-server/pool-name",
"type":"string"
},
"host":{
"id":"/v1.0/origin-server/host",
"type":"string"
},
"port":{
"id":"/v1.0/origin-server/port",
"type":"integer"
},
"health-check":{
"id":"/v1.0/origin-server/health-check",
"type":"object",
"properties":{
"protocol":{
"id":"/v1.0/origin-server/health-check/protocol",
"type":"string"
},
"status":{
"id":"/v1.0/origin-server/health-check/status",
"type":"string"
},
"reason":{
"id":"/v1.0/origin-server/health-check/reason",
"type":"string"
}
},
"required":[
"status"
]
}
},
"required":[
"host",
"port",
"health-check"
]
},
"timestamp":{
"id":"/v1.0/timestamp",
"type":"string"
}
},
"required":[
"event-type",
"domain-name",
"instance-name",
"origin-server",
"timestamp"
]
}
},
"required":[
"v1.0"
]
}

13.1.3.2 例

Content-Type: application/json

Content:

{
"v1.0":{
"event-type":"origin-server-status-change",
"domain-name":"base_domain",
"instance-name":"otd1",
"origin-server":{
"pool-name":"testpool",
"host":"slc06cdz",
"port":7777,
"health-check":{
"protocol":"HTTP",
"status":"offline",
"reason":"Server not reachable"
}
},
"timestamp":"Mon, 18 Apr 2016 04:34:23 -07:00"
}
}

13.1.4 エラー処理

サブスクライバがエラー・コードを使用して応答する場合、Oracle Traffic Directorは次のことを実行します。

- 次の警告メッセージをサーバー・ログに記録する。

- イベント・ディスパッチャ: サブスクライバ<subscription_url>から受け取った応答コード<http_response_code>

- イベント・ディスパッチャ: サブスクライバ<subscription_url>にイベント<json_notification_data>をポストできません

- イベントを破棄する。

サブスクライバを使用できない場合、Oracle Traffic Directorは次のことを実行します。

- イベントの再ポストを3回試行する。

- 次の警告メッセージをサーバー・ログに記録する。

- イベント・ディスパッチャ: サブスクライバ<subscription_url>から応答を受け取ることができません

- イベント・ディスパッチャ: サブスクライバ<subscription_url>にイベント<json_notification_data>をポストできません

- イベントを破棄する。

13.2 リクエスト制限の超過イベント

リクエスト制限の超過イベントは、仮想サーバーに対して構成されたリクエスト制限を超えた場合に発生します。OTDは、リクエスト制限が指定された時間間隔(event-notification-interval)で超過していたかどうかをチェックし、構成されたHTTPエンドポイントに通知メッセージを送信します。

event-notification-intervalは、その通知をサブスクライブしながら、リクエスト制限に対してユーザーが設定できる構成可能なパラメータです。通知メッセージは、構成されたリクエスト制限を超えたあらゆるリクエスト制限に関して送信されます。リクエスト制限は、そのリクエスト制限の構成時に指定された名前を使用して識別されます。サーバーに対するリクエスト制限の構成に関する詳細は、10.7.2項「仮想サーバーのリクエスト制限の構成」を参照してください。

リクエストを監視するためにリクエスト制限でmonitor属性が使用されている場合、通知メッセージにはしきい値を超えたすべての監視のJSON配列が含まれます。

仮想サーバーが指定されたリクエスト制限を超えた場合、OTDはmonitor属性に一致するすべての後続リクエストを拒否します。通知メッセージには、各監視で拒否されたリクエスト数に関する情報が含まれます。

注意:
リクエスト制限を超えた場合、OTDは通知を即座に送信しません。
高いバーストトラフィックが発生している場合、リクエスト制限は短い時間間隔で複数回超過する場合があります。リクエスト制限を超えるたびにOTDが通知メッセージを送信すると、多くの通知メッセージが発生することになります。これを回避するために、OTDはリクエスト制限がある時間間隔で超過したかどうかを確認し、制限を超えたことを検出した場合は通知メッセージを送信します。

13.2.1 WLSTを使用したリクエスト制限の超過イベントのサブスクライブ

- イベント・サブスクリプションを作成します。詳細は、「WLSTを使用したオリジン・サーバーのステータス変更イベントのサブスクライブ」の「イベント・サブスクリプションの作成」を参照してください。

- リクエスト制限の超過イベントの有効化
指定されたリクエスト制限のイベントを有効化するには、例に示すように、otd_enableRequestLimitEventsコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
props['event-notification-interval'] = '60'
otd_enableRequestLimitEvents(props)

- リクエスト制限の超過イベントの無効化
指定されたリクエスト制限のイベントを無効化するには、例に示すように、otd_disableRequestLimitEventsコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
otd_disableRequestLimitEvents(props)

- リクエスト制限の超過イベントのプロパティの表示
指定されたリクエスト制限のプロパティを表示するには、otd_getRequestLimitPropertiesコマンドを実行します。10.7.2項「仮想サーバーのリクエスト制限の構成」を参照してください。

13.2.2 通知形式

エンドポイントに送信されるPOSTメッセージのメッセージ本文には、この項で説明した名前/値のペアを持つJSONドキュメントが含まれています。

表13-3 すべてのイベントに共通するJSONプロパティ

JSONプロパティ

説明

event-type

イベントのタイプ。値: request-limit-exceeded。

domain-name

Oracle Traffic Directorインスタンスが構成されたドメインの名前。

instance-name

Oracle Traffic Directorインスタンスの名前。

表13-4 request-limit-exceededからの通知に固有のJSONプロパティ

JSONプロパティ

説明

time-begin

イベント通知間隔の始まりを示すタイムスタンプ。

time-end

イベント通知間隔の終わりを示すタイムスタンプ。

virtual-server

リクエスト制限を有効化した仮想サーバーの名前。

request-limit-rule

この通知メッセージを生成したリクエスト制限ルールを特定します。

monitor

監視されているリクエスト属性の値。

たとえば、-request-limitルールでmonitor=$ipが指定されている場合、JSONプロパティmonitorには「$ip」変数の値(つまり、クライアントIPアドレス)が設定されます。

request-limitルールでmonitorが指定されていない場合、このプロパティにはunnamedが設定されます。

total-queue-overflows

キューのオーバーフローが原因で拒否されたリクエスト総数。

total-queue-timeouts

キュー内での待機時のタイムアウトが原因で拒否されたリクエスト総数。

13.2.2.1 JSONスキーマ

{
"$schema": "http://json-schema.org/draft-04/schema#",
"id": "/",
"type": "object",
"properties": {
"v1.0": {
"id": "v1.0",
"type": "object",
"properties": {
"event-type": {
"id": "event-type",
"type": "string"
},
"domain-name": {
"id": "domain-name",
"type": "string"
},
"instance-name": {
"id": "instance-name",
"type": "string"
},
"event-notification-interval": {
"id": "event-notification-interval",
"type": "object",
"properties": {
"time-begin": {
"id": "time-begin",
"type": "string"
},
"time-end": {
"id": "time-end",
"type": "string"
}
}
},
"virtual-server": {
"id": "virtual-server",
"type": "string"
},
"request-limit-rule": {
"id": "request-limit-rule",
"type": "string"
},
"monitors": {
"id": "monitors",
"type": "array",
"items": {
"id": "0",
"type": "object",
"properties": {
"monitor": {
"id": "monitor",
"type": "string"
},
"total-rejects": {
"id": "total-rejects",
"type": "object",
"properties": {
"total-queue-overflows": {
"id": "total-queue-overflows",
"type": "integer"
},
"total-queue-timeouts": {
"id": "total-queue-timeouts",
"type": "integer"
}
}
}
}
}
}
},
"required": [
"event-type",
"domain-name",
"instance-name",
"event-notification-interval",
"virtual-server",
"request-limit-rule",
"monitors"
]
}
},
"required": [
"v1.0"
]
}

13.2.2.2 例

{
"v1.0": {
"event-type": "request-limit-exceeded",
"domain-name": "base domain",
"instance-name": "otd1",
"event-notification-interval": {
"time-begin": "Mon, 18 Apr 2016 04:34:23 -07:00",
"time-end": "Mon, 18 Apr 2016 04:35:23 -07:00"
},
"virtual-server": "1.example.com",
"request-limit-rule": "request-limit-1",
"monitors": [
{
"monitor": "16.181.76.89",
"total-rejects": {
"total-queue-overflows": 2,
"total-queue-timeouts": 3
}
}
]
}
}

14 高可用性を提供するためのOracle Traffic Directorの構成

この章では、Oracle Traffic Directorの高可用性機能について説明します。ここの内容は、次のとおりです。

- 高可用性の概要

- フェイルオーバー・グループの作成および管理

14.1 高可用性の概要

Oracle Traffic Directorインスタンスにおいて高可用性には、次の機能が含まれます。

- ハードウェア障害、カーネル・クラッシュおよびネットワーク障害によるダウンタイムなしで、クライアント・リクエストを受信し処理します。

- 2つのOracle Traffic Directorインスタンスを構成し、アクティブ-アクティブまたはアクティブ-パッシブ・フェイルオーバーを提供することで、エンタープライズ・アプリケーションおよびサービスに対して、可用性の高いルーティングおよびロード・バランシング・サービスを設定できます。

- Oracle Traffic Directorプロセスがクラッシュした場合、自動的に再起動します。
Oracle Traffic Directorにはアプリケーション・レベルとノード・レベルの2つのレベルの可用性があります。アプリケーション・レベルの可用性はデフォルトの機能で、新たな構成を加える必要がありません。アプリケーション・レベルの可用性では、Oracle Traffic DirectorのWatchdogデーモンによりロード・バランシング・サービスが監視されるため、プロセス・クラッシュのようなアプリケーション・レベルの障害が発生した場合でも可用性が維持されます。この機能により、ロード・バランシング・サービスにソフトウェア関連の問題が発生しても、Oracle Traffic Directorがソフトウェア・ロード・バランサとしてバックエンド・アプリケーションにリクエストをフロンドエンドし続けます。ノード・レベルの可用性では、CPU障害やメモリー破損などの問題でシステム/vServerがクラッシュした場合でも、Oracle Traffic Directorがバックエンド・アプリケーションにリクエストをフロントエンドし続けます。ノード・レベルの可用性を実現するには、Oracle Traffic Directorを2台の計算ノードまたはvServerにインストールし、それらの間にフェイルオーバー・グループを構成する必要があります。

Oracle Traffic Directorインスタンス自体に高可用性を与えるには、各ロード・バランサ・サーバー・インスタンスに少なくとも3つのプロセス(watchdogプロセス、primordialプロセスおよび1つ以上のロード・バランサ・プロセス)が含まれている必要があります。watchdogプロセスがprimordialを生成し、primordialがロード・バランサ・プロセスを生成します。watchdogプロセスとprimordialプロセスはOracle Traffic Directorプロセス内における限られたレベルの高可用性を実現します。ロード・バランサ・プロセスまたはprimordialプロセスが何かしらの理由で異常終了した場合、Oracle Traffic Directorのwatchdogがそれらのサービスを再起動するため、Oracle Traffic Directorをソフトウェア・ロード・バランス・サービスとして使用し続けることができます。Oracle Traffic Directorインスタンスにはwatchdogプロセスとprimordialプロセスが1つずつと、1つ以上のロード・バランサ・プロセスが存在することになります。

- Oracle Traffic Directorへのほとんどの構成変更は、インスタンスを再起動したり、処理中のリクエストに影響を及ぼしたりすることなく動的にデプロイできます。インスタンスの再起動を必要とする構成変更の場合、Fusion Middleware Controlはインスタンスを再起動するためのプロンプトを表示します。ただし、このプロンプトはWLSTコマンドでは表示されず、エラーがサーバー・ログに記録されます。

- クライアント・リクエストをバック・エンドのオリジン・サーバーに確実に分散します。

- バック・エンドのサーバーが使用不可であるか、完全にロードされている場合、Oracle Traffic Directorは、定期的なヘルス・チェックにより自動的にこの状況を検出し、そのサーバーへのクライアント・リクエストの送信を停止します。障害の発生したサーバーが再び使用可能になった場合、Oracle Traffic Directorは自動的にこれを検出し、このサーバーへのリクエストの送信を再開します。詳細は、5.7項「オリジン・サーバー・プールのヘルス・チェック設定の構成」を参照してください。

- 各オリジン・サーバー・プールで、いくつかのサーバーをバックアップ・サーバーとして指定できます。Oracle Traffic Directorは、使用可能なプライマリ・サーバーがプールにない場合にのみ、バックアップ・サーバーにリクエストを送信します。詳細は、5.3項「オリジン・サーバー・プールの変更」を参照してください。

- 各オリジン・サーバーが処理できる最大同時接続数を指定することで、接続が過負荷状態になりオリジン・サーバーからリクエストが拒否される可能性を減らすことができます。
各オリジン・サーバーについて、サーバーへのリクエストの送信レートを上げる期間を指定することもできます。この機能により、オフラインのサーバーが再起動中の場合に、リクエストが拒否される可能性を最小限にすることができます。

詳細は、6.3項「オリジン・サーバーの変更」を参照してください。

14.1.1 ネットワーク・トポロジにおける高可用性

2つ以上のOracle Traffic Directorインスタンスを1つまたは2つの仮想IP(VIP)アドレスで表されるフェイルオーバー・グループに組み合わせることで、Oracle Traffic Directorインスタンスの高可用性を確保することができます。フェイルオーバー・グループ内の両方のホストでは、同じオペレーティング・システム・バージョンを実行し、同一のパッチおよびサービス・パックを使用し、同じ構成のOracle Traffic Directorインスタンスを実行する必要があります。

注意:

- 1つのインスタンスに複数のフェイルオーバー・グループを作成できますが、各フェイルオーバー・グループにはそれぞれ別のVIPアドレスを付与する必要があります。

- Oracle SuperClusterおよびExalogic (Solaris)では、Oracle Traffic Directorはグローバル・ゾーンにインストールした場合にのみ高可用性を目的として構成できます。また、すべての管理ノードがグローバル・ゾーンで実行されている必要があります。

図14-1はOracle Traffic Directorネットワーク・トポロジを示しています。

図14-1 Oracle Traffic Directorネットワーク・トポロジ

図14-1に示されたトポロジは、2つのOracle Traffic Directorインスタンス(otd_1およびotd_2)で構成され、フェイルオーバー・ペアを形成し、クライアント・リクエストに対し単一の仮想IPアドレスを提供します。構成されたフェイルオーバー・モードに基づいて、プライマリ・ノードはリクエストの転送方法と転送先を判断します。フェイルオーバー・モードの詳細は、14.1.2項「構成モードのフェイルオーバー」を参照してください。

図14-1では、バック・エンドに2つのサーバー・プールのみが示されていますが、複数のサーバー・プール内のサーバーにリクエストをルーティングするようにOracle Traffic Directorを構成できます。

14.1.2 構成モードのフェイルオーバー

フェイルオーバー・グループでは、次のモードで動作するOracle Traffic Directorインスタンスを構成できます:

- アクティブ-パッシブ: 1つのVIPアドレスが使用されます。フェイルオーバー・グループ内の1つのインスタンスがプライマリ・ノードとして指定されます。プライマリ・ノードに障害が発生すると、各リクエストが、同じVIPを通じてもう一方のインスタンスにルーティングされます。

- アクティブ-アクティブ: 1つのVIPアドレスが使用されます。ノードのうちの1つはマスター・ノードであり、その他のノードはバックアップ・ノードです。VIPへの受信リクエストはOTDインスタンス間で分散されます。マスター・ノードでエラーが発生すると、最も優先度が高いバックアップ・ノードが次のマスター・ノードとして選択されます。

図14-2 Oracle Traffic Directorの高可用性のデプロイメント

14.1.3 アクティブ-パッシブ・モードでのフェイルオーバー

ここで説明したアクティブ-パッシブ設定では、フェイルオーバー・グループ内の1つのノードが、どの時点でも冗長となります。リソースの使用率を向上するには、アクティブ-アクティブ・モードの2つのOracle Traffic Directorインスタンスを2つの仮想IPアドレスを使用して構成できます。各インスタンスは1つの仮想IPアドレスで受信したリクエストに応じ、もう1つのインスタンスをバックアップします。

Oracle Traffic Directorでは、LinuxのkeepalivedやSolarisのvrrpd (ネイティブ)のような、Virtual Routing Redundancy Protocol (VRRP)実装を使用することによって、フェイルオーバー・グループ内のインスタンス間におけるフェイルオーバーをサポートしています。

図14-3 アクティブ-パッシブ・モードでのフェイルオーバー

Keepalivedには、オリジン・サーバーのロード・バランシングやヘルス・チェックなど、他の機能も備わっていますが、Oracle Traffic DirectorではVRRPサブシステムのみを使用します。Keepalivedの詳細は、http://www.keepalived.orgを参照してください。

注意:
必ずKeepalived v1.2.12(必要な最小バージョン)をインストールしてください。

VRRPでは、なんらかの理由で最初のノードが使用できなくなったときにルーターによってあるノードから別のノードにVIPアドレスをフェイルオーバーする方法を指定します。このIPフェイルオーバーは、各ノード上で実行されているルーター・プロセスによって実装されます。2つのノードからなるフェイルオーバー・グループでは、現在VIPが割り当てられているノード上のルーター・プロセスがマスターと呼ばれます。マスターは、その存在を継続的に2つ目のノード上のルーター・プロセスに通知します。

注意:
フェイルオーバー・グループのメンバーとして構成されたOracle Traffic Directorインスタンスが存在するホスト上では、Oracle Traffic DirectorがKeepalivedの唯一のコンシューマである必要があります。そうでない場合、インスタンスの停止時間中にフェイルオーバーを有効にするためにOracle Traffic Directorでkeepalivedデーモンを起動および停止したときに、同じホスト上でkeepalivedを使用している他のサービスが中断される可能性があります。

マスター・ルーター・プロセスが実行されているノードに障害が発生した場合、2つ目のノード上のルーター・プロセスは約3秒の待機後マスターがダウンしていると判断し、VIPをそのノードに割り当てることによってマスターのロールを引き継ぎます。最初のノードがもう一度オンラインになった場合は、そのノード上のルーター・プロセスがマスター・ロールを引き継ぎます。VRRPの詳細は、http://datatracker.ietf.org/doc/rfc5798のRFC 5798を参照してください。

14.1.4 アクティブ-アクティブ・モードでのフェイルオーバー

Oracle Traffic Directorは、同じサブネットに属しているノード上に2つ以上のOTDインスタンスをデプロイすることで、インスタンス間でのフェイルオーバーをサポートします。ノードの1つはアクティブ・ルーター・ノードとして選択され、残りのノードはバックアップ・ルーター・ノードです。すべてのOTDインスタンス間のトラフィックが管理されます。

このソリューションでも、ロード・バランシングおよびフェイルオーバー・タスクを実行するためにKeepalived v 1.2.13とLinux Virtual Server(LVS)を使用します。さらに、次のパッケージが必要です。

- ipvsadm (1.26以降)

- iptables (1.4.7以降)

図14-4 アクティブ-アクティブ・モードでのフェイルオーバー

最初はすべてのノードがバックアップ・ノードとして構成され、それらのノードには異なる優先度が割り当てられます。最も優先度が高いノードがマスターとして選択され、その他のノードはバックアップ・ノードになります。マスター・ノードでエラーが発生すると、最も優先度が高いバックアップ・ノードが次のマスター・ノードとして選択されます。Keepalivedマスター・ノードはLVSのマスター・ノードでもあります。

Keepalivedは次のことを実行します。

- マスター上の仮想IPを調査する

- VIPのGratuitous ARPメッセージを送信する

- LVSを構成する(ipvsadm)

- 他のノード上のKeepalivedのヘルス・チェックを行う

LVSは次のことを実行します。

- OTDインスタンス間でロード・バランシングを行う

- マルチキャストを介してバックアップ・ノードへの既存の接続情報を共有する。

- 各OTDインスタンス上のサービスの整合性を確認する。任意のOTDでエラーが発生した場合、そのOTDインスタンスはLVS構成から削除され、オンラインに戻ると再度追加されます。

14.2 フェイルオーバー・グループの作成および管理

この項では、次の項目について説明します。

- 14.2.1項「フェイルオーバー・グループの作成」

- 14.2.2項「フェイルオーバー・グループの管理」

14.2.1 フェイルオーバー・グループの作成

この項では、フェイルオーバー・グループを作成してOracle Traffic Directorインスタンスの高可用性ペアを実装する方法を説明します。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

始める前に

- フェイルオーバー・グループに割り当てる一意のVIPアドレスを決定します。

- VIPアドレスは、フェイルオーバー・グループ内のノードと同じサブネットに属している必要があります。

- クライアントはこれらのVIPアドレスにアクセスできる必要があります。

- フェイルオーバー・グループ内のプライマリ・ノードおよびバックアップ・ノードとして構成するOracle Traffic Directorノードを識別します。これらのノードは同じサブネットに属している必要があります。
ここで選択する管理ノードに、指定した構成に使用するOracle Traffic Directorインスタンスが存在している必要があります。

- 各ノードのネットワーク・インタフェースを識別します。
現在ホスト上で稼働しているネットワーク・インタフェースごとに、管理サーバーによって、インタフェースのIPアドレスのネットワーク部が、指定したVIPのネットワーク部と比較されます。結果が一致した最初のネットワーク・インタフェースが、VIPのネットワーク・インタフェースとして使用されます。

この管理サーバーによる比較では、フェイルオーバー・グループ用に指定されたVIPがIPv4アドレスであるかIPv6アドレスであるかに応じて、それぞれIPv4アドレスまたはIPv6アドレスで構成されたホスト上のネットワーク・インタフェースのみが検証されます。

- 存在しないアドレスにバインドできるようにする(転送バインディングのような)システム構成を実行することで、HTTPリスナーのVIP IPアドレスにバインドできます。次のシステム構成のどちらかを実行します。
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

または

sysctl net.ipv4.ip_nonlocal_bind=1 (リブート後に保持する/etc/sysctl.confの変更)

フェイルオーバー・グループを作成する構成では、リスナーのIPアドレスがアスタリスク(*)またはVIPと同じアドレスであることを確認してください。それ以外の場合、VIPに送信されたリクエストが仮想サーバーにルーティングされません。

- 各フェイルオーバー・グループのルーターIDは一意である必要があります。後続のフェイルオーバー・グループを作成するたびに、デフォルトのルーターIDは、254、253のように1つずつ減ります。

14.2.1.1 Fusion Middleware Controlを使用したフェイルオーバー・グループの作成

Fusion Middleware Controlを使用してフェイルオーバー・グループを作成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. フェイルオーバー・グループを作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「フェイルオーバー・グループ」を選択します。
フェイルオーバー・グループ・ページが表示されます。これには、構成に定義されているフェールオーバー・グループのリストが表示されます。

7. 「作成」をクリックします。
新規フェイルオーバー・グループ・ウィザードが表示されます。

図14-5 新規フェイルオーバー・グループ・ウィザード

8. 画面上のプロンプトに従って、仮想IPアドレス、ネットワーク・インタフェース、管理ノードのホスト名など、前に決定した詳細を使用してフェイルオーバー・グループの作成を完了します。
フェイルオーバー・グループが作成されたら、新規フェイルオーバー・グループ・ウィザードの結果画面に、フェイルオーバー・グループの作成が成功したことを示すメッセージが表示されます。

9. 結果画面で、「閉じる」をクリックします。
フェイルオーバー・グループ・ページに、作成したフェイルオーバー・グループの詳細が表示されます。

注意:
この時点では、2つのノードはアクティブ-パッシブ・ペアになっています。これらをアクティブ-アクティブ・ペアに変更するには、同じ2つのノードを含む別のフェイルオーバー・グループを作成しますが、その際、異なるVIPを割り当て、プライマリおよびバックアップ・ロールを逆にします。

14.2.1.2 WLSTを使用したフェイルオーバー・グループの作成

フェイルオーバー・グループを作成するには、otd_createFailoverGroupコマンドを実行します。

たとえば、次のコマンドでは、次の詳細でアクティブ-パッシブ・フェイルオーバー・グループが作成されます。

- 構成: ha

- プライマリ・インスタンス: 1.example.com

- バックアップ・インスタンス: 2.example.com

- 仮想IPアドレス: 192.0.2.1

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '192.0.2.1'
props['primary-instance'] = '1.example.com'
props['backup-instance'] = '2.example.com'
props['primary-nic'] = 'eth0'
props['backup-nic'] = 'eth0'

props['failover-type'] = 'active-passive'
otd_createFailoverGroup(props)

注意:
フェイルオーバー・グループを作成する場合は、それらのマシン上でrootユーザーとしてotd_startFailoverを実行する必要があります。これはフェイルオーバーを手動で開始するためです。このコマンドを実行しないとフェイルオーバーは開始しないため、高可用性を実現できません。otd_startFailoverの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください

たとえば、次のコマンドでは、次の詳細でアクティブ-アクティブ・フェイルオーバー・グループが作成されます。

- 構成: ha

- プライマリ・インスタンス: 1.example.com

- バックアップ・インスタンス: 2.example.com

- 仮想IPアドレス: 192.0.2.1

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '192.0.2.1'
props['failover-type'] = 'active-active'
otd_createFailoverGroup(props)

otd_createFailoverGroupの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

14.2.2 フェイルオーバー・グループの管理

フェイルオーバー・グループを管理するには、フェイルオーバー・デーモンを特権ユーザー(通常はroot)で実行する必要があり、フェイルオーバー・グループのプライマリおよびバックアップ・インスタンスが実行されるマシン上で、otd_startFailoverコマンドを特権ユーザーで実行する必要があります。同様に、デーモンを停止するには、otd_stopFailoverを実行する必要があります。keepalivedデーモンの構成パラメータは、フェイルオーバー・グループの一部である各インスタンスのconfigディレクトリにあるkeepalived.confというファイルに格納されます。otd_startFailoverまたはotd_stopFailoverの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

フェイルオーバー・グループを作成したら、それをリストしたり、設定を表示したり、フェイルオーバー・グループのプライマリ・インスタンスを変更したり、プライマリ・インスタンスとバックアップ・インスタンスを切り替えたり、削除したりできます。フェイルオーバー・グループのVIPまたは任意のプロパティを変更するには、フェイルオーバー・グループを削除してから新たに作成しなおす必要があることに注意してください。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、フェイルオーバー・グループを表示、変更および削除できます。

注意:
WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したフェイルオーバー・グループの管理

Fusion Middleware Controlを使用してフェイルオーバー・グループを表示、変更および削除するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. フェイルオーバー・グループを管理する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「フェイルオーバー・グループ」を選択します。

7. フェイルオーバー・グループ・ページが表示されます。これには、構成に定義されているフェールオーバー・グループのリストが表示されます。

- フェイルオーバー・グループのプロパティを表示するには、その仮想IPをクリックします。

- プライマリ・ノードおよびバックアップ・ノードのホストを切り替えるには、「プライマリの切替え」ボタンをクリックします。結果のダイアログ・ボックスで、「OK」をクリックします。

- フェイルオーバー・グループを削除するには、「削除」ボタンをクリックします。結果のダイアログ・ボックスで、「OK」をクリックします。

8. アクティブ-アクティブ・フェイルオーバー・グループのフェイルオーバー・インスタンスを追加または削除する場合、必ずすべてのノードのフェイルオーバー・グループを停止および起動してから変更を確認してください。

注意:

- 異なるノードをフェイルオーバー・グループ内のプライマリ・ノードまたはバックアップ・ノードとして割り当てるには、フェイルオーバー・グループを新たに作成しなおす必要があります。

- 複数の構成にわたって最大255個のフェイルオーバー・グループを作成できます。

WLSTを使用したフェイルオーバー・グループの管理

たとえば、フェイルオーバー・グループをリストするには、otd_listFailoverGroupsコマンドを実行します。

props = {}
props['configuration'] = 'ha'
otd_listFailoverGroups(props)

たとえば、フェイルオーバー・グループを切り替えるには、otd_toggleFailovergroupPrimaryコマンドを実行します。

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '10.128.67.44'
otd_toggleFailovergroupPrimary(props)

たとえば、フェイルオーバー・グループのプロパティを変更するには、otd_getFailoverGroupPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'ha'
props['primary-instance'] = '1.example.com'
otd_getFailoverGroupProperties(props)

たとえば、フェイルオーバー・グループを削除するには、otd_deleteFailoverGroupコマンドを実行します。

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '10.128.67.44'
otd_deleteFailoverGroup(props)

アクティブ-アクティブHAに固有のWLSTコマンド

たとえば、フェイルオーバー・インスタンスを追加するには、otd_addFailoverInstanceコマンドを実行します。

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '10.128.67.44'
props['instance'] = '1.example.com'
props['nic'] = 'eth0'
otd_addFailoverInstance(props)

たとえば、フェイルオーバー・インスタンスを削除するには、otd_removeFailoverInstanceコマンドを実行します。

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '10.128.67.44'
props['instance'] = '1.example.com'
otd_removeFailoverInstance(props)

たとえば、フェイルオーバー・インスタンスをリストするには、otd_listFailoverInstancesコマンドを実行します。

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '10.128.67.44'
otd_listFailoverInstances(props)

たとえば、フェイルオーバー・インスタンスの順序を変更するには、otd_setFailoverInstanceOrderコマンドを実行します。

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '10.128.67.44'
props['instances'] = '1.example.com, 2.example.com'
otd_setFailoverInstanceOrder(props)

詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

15 パフォーマンス向上のためのOracle Traffic Directorのチューニング

この章では、Oracle Traffic Directorインスタンスおよび仮想サーバーの統計データを使用して、潜在的なパフォーマンスのボトルネックを特定する方法を説明します。また、Oracle Traffic Directorのパフォーマンスを向上させるために行える構成変更についても説明します。

この章には次の項が含まれます:

- 一般的なチューニング・ガイドライン

- ファイル・ディスクリプタ制限のチューニング

- スレッド・プールおよび接続キューのチューニング

- HTTPリスナー設定のチューニング

- キープ・アライブ設定のチューニング

- HTTPリクエストおよびレスポンスの制限のチューニング

- DNSキャッシュ設定のチューニング

- SSL/TLS関連の設定のチューニング

- アクセス・ログ・バッファ設定の構成

- コンテンツ圧縮の有効化と構成

- オリジン・サーバーへの接続のチューニング

- Solaris固有のチューニング

15.1 一般的なチューニング・ガイドライン

この章で提供されるチューニングの提案内容の実行結果は、各ユーザーの環境に応じて異なる場合があります。ニーズに適したチューニング・パラメータを決定する際には、次のガイドラインに留意してください。

- 1回ごとに1つのパラメータを調整します
可能な限り、1回ごとに1つの調整を行ってください。各変更の前と後でパフォーマンスを計測し、大きな改善が見られない変更は元に戻します。

- パフォーマンス・ベンチマークの作成に使用できるテスト・ケースを設定します。
パラメータを変更する前に、パフォーマンスに及ぼす変更の影響をテストするためのテスト・ケースを設定し、可能な場合は自動化します。

- 段階的にチューニングします
量的なパラメータを調整する場合、小さい増分単位で変更してください。これは、最適な設定を迅速に特定するのに最も適切な方法です。

- ハードウェアまたはソフトウェアを変更した後は、再び最初から確認します
ハードウェアまたはソフトウェアのアップグレードなど、主なシステム変更ごとに、前のチューニングの変更が適用できるかどうかを確認します。

15.2 ファイル・ディスクリプタ制限のチューニング

オペレーティング・システムでは、ファイル・ディスクリプタを使用して、ファイルシステムのファイル、および接続やリスナー・ソケットなどの擬似ファイルを処理します。

Oracle Traffic Directorインスタンスの起動後、ファイル・ディスクリプタ関連の値の自動構成が行われる際に、次のパラメータが考慮されます。

- HTTP処理スレッド(<thread-pool>)

- すべての仮想サーバーのアクセス・ログ件数(<access-log>)

- リスナー(<http-listener>、<tcp-listener>)

- キープ・アライブ接続(<keep-alive>)

- オリジン・サーバー・プールの数(<origin-server-pool>)

- オリジン・サーバーの数(<origin-server>)

- オリジン・サーバーの接続(<origin-server>/<max-connections>)

- TCP処理スレッド(<tcp-thread-pool>)

ファイル・ディスクリプタを必要とする主要なOracle Traffic Directorオブジェクトは、キープ・アライブ接続、キューに入れられた接続、およびオリジン・サーバーへの接続です。これらのオブジェクトの制限を明示的に指定しない場合、Oracle Traffic Directorインスタンスが起動すると、制限(最大キープ・アライブ接続、接続キューのサイズ、および各オリジン・サーバーの最大接続数)が、システム内で使用可能なファイル・ディスクリプタの合計数に基づいて自動的に構成されます。

ファイル・ディスクリプタ制限に異常に高い値が設定されている場合、未指定のパラメータの自動構成が原因でOracle Traffic Directorインスタンスがメモリーを過剰消費したり、最適な構成を得られないことがあります。この問題を回避するため、ファイル・ディスクリプタ制限が高いシステムではこれらのパラメータ値を明示的に指定します。

たとえば、max-threads * 4がプロセスで利用できる最大ファイル・ディスクリプタ数よりも小さくなるのが理想です。たとえば、ファイル・ディスクリプタ制限が65536に設定されている場合にmax-threadsを20000に設定すると、最適なチューニングを得られません。これは、ワーカー・スレッド用として80000 (20000*4=80000)がファイル・ディスクリプタを使い切って/予約してしまい、他のサブシステム用に残るファイル・ディスクリプタが少なくなるためです。そのため、max-threadsに高い値を設定する場合は、何回かテストを行ったうえで設定する必要があります。

割り当てられたファイル・ディスクリプタ数は、システムでサポート可能な制限を超えられません。ファイル・ディスクリプタの現在のシステム制限を確認するには、次のコマンドを実行します。

$ cat /proc/sys/fs/file-max
2048

使用可能なファイル・ディスクリプタのうち現在使用されている数を確認するには、次のコマンドを実行します。

$ cat /proc/sys/fs/file-nr

このコマンドによって、次のような出力が返されます。

625 52 2048

この例では、625は割当て済ファイル・ディスクリプタ数、52は空きの割当て済ファイル・ディスクリプタ数、2048はシステムでサポートされているファイル・ディスクリプタの最大数です。

注意:
Solarisでは次のコマンドを使用して、システム全体で使用中のファイル・ディスクリプタを検出できます。

# echo ::kmastat | mdb -k | grep file_cache

このコマンドによって、次のような出力が返されます。

file_cache        56    1154   1305      73728B   659529     0

この例では、1154が使用中のファイル・ディスクリプタの数、1305が割当済のファイル・ディスクリプタの数です。Solarisでは、オープン・ファイル・ディスクリプタの最大数の設定がないことに注意してください。RAMに空き領域があるかぎり、要求に応じて割り当てられます。

割当て済ファイル・ディスクリプタがシステムの制限に達すると、ファイルを開くときに次のエラー・メッセージがシステム・コンソールに表示されます。

Too many open files in system.

次のメッセージがサーバー・ログに書き込まれます。

[ERROR:16] [OTD-10546] Insufficient file descriptors for optimum configuration.

これは、システムではこれ以上ファイルを開くことができないという重大な問題です。この問題を回避するために、ファイル・ディスクリプタ制限を合理的な数まで増やすことを検討してください。

Linuxでファイル・ディスクリプタ数を変更するには、次の操作をrootユーザーとして行います。

1. 次の行を/etc/sysctl.confファイルで編集します。

fs.file-max = value

valueは、設定する新しいファイル・ディスクリプタ制限です。

2. 次のコマンドを実行して、変更を適用します。

# /sbin/sysctl -p

注意:
Solarisでは、/etc/systemファイルのrlim_fd_maxの値を変更して、1つのプロセスで開いた可能性があるファイル・ディスクリプタにハード面での制限を指定します。この制限をオーバーライドするには、スーパーユーザー特権が必要です。同様に、rlim_fd_curは、1つのプロセスが開くことのできるファイル・ディスクリプタにソフト面での制限を指定します。プロセスは、そのファイル・ディスクリプタの制限を、setrlimit()コールを使用するか、実行中のシェルでlimitコマンドを実行することにより、rlim_fd_maxで定義したハード面の制限値までの任意の値に調整できます。ハード面の制限の範囲内で値を調整する場合には、スーパーユーザー特権は必要ありません。
たとえば、ハード面の制限値を上げるには、/etc/systemに次のコマンドを追加して、1回再起動します。

set rlim_fd_max = 65536

Solarisのファイル・ディスクリプタの設定の詳細は、第15.12.1項「単一のプロセスで開くファイル(ファイル・ディスクリプタの制限)」を参照してください。

thumbのおおよそのルールとして、thread-pool要素、max-threads * 4がプロセスで利用できる最大ファイル・ディスクリプタ数よりも小さくなるようにするというルールがあります。これはつまり、max-threadsを最大ファイル・ディスクリプタ数の1/5未満にするということです。

たとえば、ファイル・ディスクリプタ制限が65536に設定されている場合にmax-threadsを20000に設定すると、最適なチューニングを得られません。これは、ワーカー・スレッド用として20000*4=80000がファイル・ディスクリプタを使い切って/予約してしまい、他のサブシステム用にファイル・ディスクリプタがほとんど残らないためです。

max-threadsに高い値を設定する場合は、必ず事前にテストを行ってください。1つのプロセスに数万のスレッドが存在する状態はパフォーマンスに影響を及ぼすことがあります。

15.3 スレッド・プールおよび接続キューのチューニング

この項では、次の項目について説明します。

- 15.3.1項「スレッドおよび接続について」

- 15.3.2項「インスタンスのスレッド・プール・メトリックの確認」

- 15.3.3項「インスタンスの接続キュー・メトリックの確認」

- 15.3.4項「スレッド・プールおよび接続キュー設定のチューニング」

15.3.1 スレッドおよび接続について

クライアントがOracle Traffic DirectorインスタンスのHTTPリスナーにリクエストを送信すると、接続はHTTPリスナーに関連付けられているアクセプタ・スレッドによってまず受け入れられます。アクセプタ・スレッドは、接続を接続キューに入れ、次のクライアント・リクエストを待機します。スレッド・プールのリクエスト処理スレッドは、接続キューから接続を取得し、リクエストを処理します。接続プールが無効化されている場合、アクセプタ・スレッド自体によって各リクエストが処理されることに注意してください。接続キューおよびリクエスト処理スレッドは存在しません。

図15-1は、接続処理を示しています。

図15-1 Oracle Traffic Directorの接続処理

Oracle Traffic Directorインスタンスは、起動時に、各リスナー、および指定された最小リクエスト処理スレッド数を含むスレッド・プールについて、指定された数のアクセプタ・スレッドを作成します。

- リスナーのアクセプタ・スレッド数が指定されていない場合、Oracle Traffic Directorではホスト上のCPUごとに1つのアクセプタ・スレッドが作成されます。

- スレッド・プールの最小サイズが指定されていない場合、Oracle Traffic Directorでは、インスタンスが実行されているホスト上のプロセッサごとに1つのリクエスト処理スレッドが作成されます。

リクエスト・ロードが増加すると、Oracle Traffic Directorは、接続キューのリクエスト数をリクエスト処理スレッド数と比較します。キュー内のリクエスト数が、リクエスト処理スレッド数よりも多い場合、Oracle Traffic Directorはスレッド・プールの指定最大サイズまで、スレッドを追加作成します。

最大リクエスト処理スレッド数のデフォルト値が、プロセスで利用できる最大ファイル・ディスクリプタ数の4分の1を上回ることはありません。1、2個のCPUがある場合のデフォルトは256で、3、4個のCPUがある場合のデフォルトは512です。CPUが4個より多い場合のデフォルトは1024です。

スレッドの最大数は、同時に実行可能なセッション数のハード・リミットです。最大スレッド制限は、インスタンス内のすべての仮想サーバーにわたって適用されます。

15.3.2 インスタンスのスレッド・プール・メトリックの確認

プレーンテキストperfdumpレポートのSessionCreationInfoセクションで、インスタンスのスレッド・プール情報を、次の例に示すように確認できます。

SessionCreationInfo:
------------------------
Active Sessions 2187
Keep-Alive Sessions 0
Total Sessions Created 4016/4016

- Active Sessionsは、現在リクエストを処理しているリクエスト処理スレッドの数です。

- Keep-Alive Sessionsは、キープ・アライブ・セッションを提供するHTTPリクエスト処理スレッドの数を示しています。

- Total Sessions Created

- 最初の数値は、作成されたリクエスト処理スレッド数です。

- 2番目の数値は、スレッド・プールに許可されている最大スレッド数で、スレッド・プールに構成されている最大スレッドおよびキープ・アライブ・スレッド数の合計です。

作成したリクエスト処理スレッドの合計数が、最大スレッド数に常に近い場合、スレッド制限を増やすことを検討してください。そうしないと、接続キューでのリクエストの待機時間が長くなる場合があり、接続キューが一杯になった場合は、その後のリクエストは受け入れられなくなります。平均キューイング遅延(15.3.3項「インスタンスの接続キュー・メトリックの確認」を参照)が、平均レスポンス時間と比較して著しく大きい場合も、スレッド制限数を増やす必要があることを意味します。

15.3.3 インスタンスの接続キュー・メトリックの確認

接続キューの最大サイズが十分ではない場合、クライアント・リクエストは、ロードがピークの時間帯は却下される可能性があります。perfdumpプレーンテキスト・レポートの接続キュー・セクションを調べることで、次の例に示すようにこの状況を検出できます。

ConnectionQueue:
-----------------------------------------
Current/Peak/Limit Queue Length            0/1853/160032
Total Connections Queued                   11222922
Average Queue Length (1, 5, 15 minutes)    90.35, 89.64, 54.02
Average Queueing Delay                     4.80 milliseconds

- Current/Peak/Limit Queue Length行には、次の項目が示されます。

- Current: 現在キュー内にある接続数。

- Peak: キューに同時に存在できる最大接続数。
ピークのキューの長さが制限に近い場合、接続キューのサイズが、ロードに対して十分ではないことを意味します。

- Limit: 接続キューの最大サイズであり、スレッド・プール・キュー、最大スレッド数およびキープ・アライブ・キューのサイズの合計となります。

- Total Connections Queuedは、接続がキューに入れられた合計回数です。この数値には、新たに受け入れられた接続およびキープ・アライブ・システムからの接続も含まれます。

- Average Queue Lengthは、直近の1分、5分および15分のそれぞれの間隔でのキュー内の平均接続数です。

- Average Queueing Delayは、接続キュー内の接続がキュー内に留まった平均時間です。これは、リクエストがサーバーによって受け入れられた時点と、このリクエストの処理がリクエスト処理スレッドによって開始された時点の間の遅延時間を表します。平均キューイング遅延が、平均レスポンス時間と比較して相対的に大きい場合、スレッド・プール内のスレッド数を増やすことを検討してください。

15.3.4 スレッド・プールおよび接続キュー設定のチューニング

Fusion Middleware ControlまたはWLSTのいずれかを使用して、スレッド・プールおよび接続キューの設定を変更できます。

Fusion Middleware Controlを使用したスレッド・プールおよび接続キュー設定の変更

Fusion Middleware Controlを使用してスレッド・プール設定を変更するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「設定」を選択します。

7. ページの「スレッド・プール」セクションに移動します。

8. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

9. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したスレッド・プールおよび接続キュー設定の変更

- 現在のスレッド・プール設定を表示するには、次の例に示すように、otd_getHttpThreadPoolPropertiesまたはotd_getTcpThreadPoolPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getHttpThreadPoolProperties(props)

enabled=true
queue-size=2000
min-threads=20480
max-threads=20480
stack-size=262145

- スレッド・プール設定を変更するには、次の例に示すように、otd_setHttpThreadPoolPropertiesまたはotd_setTcpThreadPoolPropertiesコマンドを実行します。
たとえば、HTTP処理スレッドのスタック・サイズを変更するには、次のコマンドを実行します。

props = {}props['configuration'] = 'foo'props['stack-size'] = '8192'

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

15.4 HTTPリスナー設定のチューニング

次は、パフォーマンスに影響する主要なHTTPリスナー・パラメータです。

- リスナー・アドレス
リスナー・アドレスは、IPアドレスとポート番号で構成されます。Oracle Traffic Directorインスタンスが実行中のホストは、複数のネットワーク・インタフェースと複数のIPアドレスを持つことができます。

ホスト・マシンのすべてのネットワーク・インタフェース上のクライアント・リクエストをリスニングするように構成されているリスナーのIPアドレスは0.0.0.0となります。リスナーのIPアドレスとして0.0.0.0を指定すると便利ですが、結果として各接続に対して1つのシステム・コールが追加で必要になります。パフォーマンスの向上のためには、リスナーに実際のIPアドレスを指定することを検討してください。

- アクセプタ・スレッド数
アクセプタ・スレッドは、クライアント・リクエストを受信して、接続キューに入れます。Oracle Traffic Directorインスタンスが起動されると、指定された数のアクセプタ・スレッドが各リスナーに作成されます。リスナーのアクセプタ・スレッド数が指定されていない場合、Oracle Traffic Directorではホスト上のCPUごとに1つのアクセプタ・スレッドが作成されます。

アクセプタ・スレッドの数が少なすぎると、受け入れられないクライアント・リクエストが発生する可能性がありますが、アイドル状態のアクセプタ・スレッドが多すぎても、不要な負荷がシステムにかかります。デフォルトである、1CPU当たり1つのアクセプタ・スレッドという設定は、ほとんどの状況で許容できるトレードオフです。

比較的大量の接続をオープンおよびクローズする必要のある、HTTP 1.0のワークロードでは、デフォルトのアクセプタ・スレッド数である、1リスナー当たり1スレッドが準最適な設定です。アクセプタ・スレッド数を増やすことを検討してください。

- リスニング・キュー・サイズ
前述したように、アクセプタ・スレッドは、クライアント・リクエストを受信して、接続キューに入れます。オペレーティング・システムでアクセプタ・スレッドがスケジュールされていない場合、オペレーティング・システムのカーネルが、Oracle Traffic Directorプロセスにかわり、TCP接続を維持します。カーネルは、リスニング・キュー・サイズによって指定されている制限まで接続を受け入れることができます。

HTTP 1.0スタイルのワークロードには、確立および終了した多くの接続が含まれる場合があります。このため、Oracle Traffic Directorインスタンスに大きな負荷がかかり、クライアントで接続タイムアウトが発生する場合は、リスニング・キュー・サイズをより大きい値に設定して、HTTPリスナー・バックログ・キューのサイズを増やすことができます。

プレーンテキストperfdumpレポートには、次の例に示すように、構成内の各HTTPリスナーに対するIPアドレスおよびアクセプタ・スレッドの数が示されます。

ListenSocket ls1:
------------------------
Address                   https://0.0.0.0:1904
Acceptor Threads          1
Default Virtual Server    net-soa

9.3項「リスナーの変更」の説明に従い、Fusion Middleware ControlまたはCLIを使用してHTTPリスナーの設定を変更できます。

15.5 キープ・アライブ設定のチューニング

この項では、次の項目について説明します。

- 15.5.1項「キープ・アライブ接続について」

- 15.5.2項「キープ・アライブ接続の設定およびメトリックの確認」

- 15.5.3項「キープ・アライブ設定のチューニング」

15.5.1 キープ・アライブ接続について

HTTP 1.0およびHTTP 1.1は、単一のHTTP接続での複数のリクエストの送信をサポートしています。HTTP 1.0ではキープ・アライブと呼ばれていたこの機能は、HTTP 1.1では永続接続と呼ばれ、Oracle Traffic Directorではデフォルトで有効化されています。

元のリクエストを処理した後も接続をアクティブのまま保持することで、その後の類似したリクエストに対するTCP接続の作成およびクローズに関連する時間およびオーバーヘッドを削減できます。ただし、受信するリクエストが少ない、またはない場合、キープ・アライブ接続はシステムに対して不要な負荷となります。

図15-2は、キープ・アライブが有効化されている場合の接続処理を示しています。

図15-2 キープ・アライブが有効なOracle Traffic Directorの接続処理

この問題を回避するために、待機中のキープ・アライブ接続の最大数を指定できます。キープ・アライブ・リクエストが受信されたとき、リクエスト待機中のオープン接続が、指定した最大数を超えて存在する場合、最も古い接続はクローズされます。また、一定期間非アクティブであるキープ・アライブ接続をクローズする場合のその期間を指定できます。

15.5.2 キープ・アライブ接続の設定およびメトリックの確認

プレーンテキストperfdumpレポートには、次の例に示すように、現在のキープ・アライブ設定およびメトリックが示されます。

KeepAliveInfo:
--------------------
KeepAliveCount 26/60000
KeepAliveHits 154574634
KeepAliveFlushes 0
KeepAliveRefusals 0
KeepAliveTimeouts 5921
KeepAliveTimeout 120 seconds

perdumpレポートのKeepAliveInfoセクションには、次のように表示されます。

- KeepAliveCount:

- 最初の数値は、キープ・アライブ・モードの接続数です。

- 2番目の数値は、許可されている最大キープ・アライブ接続数です。

- KeepAliveHitsは、キープ・アライブ状態の接続で正常に受信されたリクエスト数です。
KeepAliveHitsが、KeepAliveFlushesと比較して高い場合、キープ・アライブ接続が十分に利用されていることを示します。

KeepAliveHitsが低い場合、大量のキープ・アライブ接続がアイドル状態のままであり、システム・リソースが不必要に消費されていることを示します。この状況に対応するには、次の方法があります。

- キープ・アライブ状態の接続数を少なくするために、キープ・アライブ接続の最大数を減らします。
最大接続数設定で指定された接続数は、キープ・アライブ・スレッド間で均等に分配されることに注意してください。最大接続数設定がキープ・アライブ・スレッド設定で均等に分配されていない場合、サーバーではキープ・アライブ接続の最大数を少し上回る数が許可されます。

- キープ・アライブ接続が長時間アイドル状態のままとならないように、KeepAliveTimeoutを短くします。KeepAliveTimeoutの値が非常に小さい場合、新規TCP接続の設定におけるオーバーヘッドが増加することに注意してください。

- KeepAliveFlushesは、クライアントがキープ・アライブをリクエストした接続をサーバーがクローズした回数です。
キープ・アライブ・フラッシュを減らすには、キープ・アライブ最大接続数を増やします。

注意:
UNIX/Linuxシステムで、キープ・アライブ最大接続数が非常に大きく設定されている場合、サーバーのオープン・ファイル・ディスクリプタが不足する場合があります。一般的に、1024がUNIX/Linuxでのオープン・ファイル数の制限であるため、キープ・アライブの最大接続数を500よりも増やすことはお薦めしません。かわりに、15.2項「ファイル・ディスクリプタ制限のチューニング」の説明に従い、ファイル・ディスクリプタ制限を増やすことができます。

- KeepAliveRefusalsは、考えられる理由の1つとしてKeepAliveCountがキープ・アライブ最大接続数を超えたために、サーバーが接続をキープ・アライブ・スレッドに渡すことができなかった回数です。この値が大きい場合、キープ・アライブ接続の最大数を増やすことを検討してください。

- KeepAliveTimeoutsは、前回のKeepAliveTimeout期間中に、キープ・アライブ接続でリクエストが受信されなかったため、アイドル状態のキープ・アライブ接続がクローズされた回数です。

- KeepAliveTimeoutは、アイドル状態のキープ・アライブ接続がクローズされるまでの秒単位での期間です。
構成可能でパフォーマンスに影響を及ぼすが、perfdumpレポートには表示されない、もう1つのパラメータとして、キープ・アライブ・ポーリング間隔がありますが、これはKeepAliveTimeoutとともに、待機時間およびスループットを制御します。ポーリング間隔およびタイムアウト期間を短くすると、負荷の小さいシステムの待機時間が短くなります。これらの設定の値を大きくすると、負荷の大きいシステムの集約スループットが向上します。ただし、待機時間が長く、クライアント数が少なすぎる場合、サーバーが不必要にアイドル状態のままとなるため集約スループットに悪影響が出ます。したがって、一定の負荷で、アイドルのCPU時間がある場合ポーリング間隔を短くし、アイドル状態のCPU時間がない場合ポーリング間隔を長くします。

15.5.3 キープ・アライブ設定のチューニング

Fusion Middleware ControlまたはWLSTのいずれかを使用して、キープ・アライブ設定をチューニングできます。

Fusion Middleware Controlを使用したキープ・アライブ設定の変更

Fusion Middleware Controlを使用してキープ・アライブ設定を変更するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「HTTP」を選択します。

7. ページの「キープ・アライブ」セクションに移動します。

8. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

9. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したキープ・アライブ設定の変更

- 現在のキープ・アライブ設定を表示するには、次の例に示すように、otd_getKeepalivePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getKeepaliveProperties(props)

enabled=true
threads=20
max-connections=2000
timeout=30
poll-interval=0.001

- キープ・アライブ設定を変更するには、otd_setKeepalivePropertiesコマンドを実行します。
たとえば、キープ・アライブ・サブシステムの最大スレッド数を変更するには、次のコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['threads'] = '128'
otd_setKeepaliveProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

15.6 HTTPリクエストおよびレスポンスの制限のチューニング

Oracle Traffic Directorインスタンスがリクエストおよびレスポンスの処理に費やす時間を最適化するために、リクエストとレスポンスのヘッダー・サイズ、リクエストに許可されているヘッダー・フィールド数、およびOracle Traffic DirectorがHTTPリクエストの本文とヘッダーの受信を待機する時間などのパラメータを構成できます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、HTTPリクエストおよびレスポンスの制限の変更を表示できます。

Fusion Middleware Controlを使用したHTTPリクエスト/レスポンスの制限の表示および変更

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「HTTP」を選択します。

7. ページの「HTTP」セクションに移動します。

8. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

9. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したHTTPリクエスト/レスポンスの制限の表示および変更

- 現在の設定を表示するには、次の例に示すように、otd_getHttpPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getHttpProperties(props)

server-header=Oracle Traffic Director/12.2.1
etag=true
request-header-buffer-size=8192
strict-request-headers=false
websocket-strict-upgrade=false
discard-misquoted-cookies=true
max-request-headers=64
body-buffer-size=1024
output-buffer-size=8192
max-unchunk-size=8192
unchunk-timeout=60
io-timeout=30
request-body-timeout=-1
request-header-timeout=30
ecid=true
favicon=true

- リクエストおよびレスポンスの制限を変更するには、otd_setHttpPropertiesコマンドを実行します。
たとえば、チャンク解除タイムアウトを変更するには、次のコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['unchunk-timeout'] = '120'
otd_setHttpProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

15.7 DNSキャッシュ設定のチューニング

DNSキャッシュを利用すると、Oracle Traffic Directorがクライアント・ホスト名をIPアドレスに解決するために実行する必要があるDNS参照の回数が削減されます。Oracle Traffic Directorでは、DNSキャッシュはデフォルトで有効化されており、IPアドレスとDNS名のマッピングが格納されています。DNSキャッシュ内の各エントリは、単一IPアドレスまたはDNS名参照を表します。DNSキャッシュは、DNS参照が有効化されており、Oracle Traffic Directorによって、DNS参照を必要とする操作(クライアントのIPアドレスおよびホスト名のアクセス・ログへの記録など)が実行される場合にのみ使用されます。

DNSキャッシュ・ヒット率を高くするには、Oracle Traffic Directorに同時にアクセスする可能性のあるクライアントの最大数に対して、キャッシュのサイズを、IPアドレスとDNS名のマッピングを十分に格納できる大きさにする必要があります。DNSキャッシュに許可されている最大エントリ数およびキャッシュ失効時間をチューニングできます。キャッシュ・サイズを大きくしすぎると、メモリーが無駄に消費される可能性があることに注意してください。

この項では、次の項目について説明します。

- 15.7.1項「DNSキャッシュ設定およびメトリックの表示」

- 15.7.2項「DNSキャッシュ設定の構成」

15.7.1 DNSキャッシュ設定およびメトリックの表示

構成の現在のDNSキャッシュ設定を表示するには、次の例に示すように、otd_getDnsCachePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getDnsCacheProperties(props)

enabled=true
max-age=120
max-entries=1024

DNSキャッシュ・メトリックの表示

プレーンテキストperfdumpレポートで、現在のDNSキャッシュ使用量およびヒット率を、次の例に示すように表示できます。

DNSCacheInfo:
------------------
enabled             yes
CacheEntries        0/1024
HitRatio            0/0 ( 0.00%)

Async DNS disabled

- 最初の行は、DNSキャッシュが有効化されているかどうかを示します。

- CacheEntriesは、DNSキャッシュに現在存在するエントリ数、および許可されている最大エントリ数を示します。

- HitRatioは、DNSキャッシュ参照回数と比較したキャッシュ・ヒット数です。

- 最後の行は、非同期DNS参照が有効化されているかどうかを示します。
Oracle Traffic Director独自の非同期リゾルバ、またはオペレーティング・システムの同期リゾルバのいずれかを使用して、DNS参照を実行するようにOracle Traffic Directorを構成できます。オペレーティング・システムのリゾルバを使用して実行するDNS参照の方が速度は速くなります。

15.7.2 DNSキャッシュ設定の構成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成のDNSキャッシュ設定を構成できます。

Fusion Middleware Controlを使用したDNSキャッシュ設定の構成

Fusion Middleware Controlを使用してDNSキャッシュ設定を構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「設定」を選択します。

7. ページの「DNS」セクションに移動します。

8. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

9. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したDNSキャッシュ設定の構成

構成のDNSキャッシュ設定を変更するには、otd_setDnsCachePropertiesコマンドを実行します。

たとえば、次のコマンドでは、DNSルックアップの結果をキャッシュする最大時間が240秒に変更されます。

props = {}
props['configuration'] = 'foo'
props['max-age'] = '240'
otd_setDnsCacheProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

15.8 SSL/TLS関連の設定のチューニング

この項では、次の項目について説明します。

- 15.8.1項「SSL/TLSセッションのキャッシュ」

- 15.8.2項「暗号および証明書鍵」

15.8.1 SSL/TLSセッションのキャッシュ

HTTPS接続の最初のSSL/TLSハンドシェイク・プロセス中、クライアントとサーバーは、使用する暗号スイート、ならびに暗号化/復号化およびMAC鍵(SSLについてを参照)についてネゴシエートします。このアクティビティは、RSAまたはECCのどちらの秘密鍵が使用されているか、および鍵のサイズに応じて、かなりのCPU時間を必要とします。

最初のSSL/TLSハンドシェイクにより、一意のSSL/TLSセッションIDが生成されます。SSL/TLSセッションIDがキャッシュされた場合、次に同じHTTPSクライアントが新しいソケット接続をオープンする際、サーバーはキャッシュからSSL/TLSセッションIDを取得し、最初のハンドシェイクよりもCPUへの負荷が少ない略式のSSL/TLSハンドシェイクを実行することで、接続の確立に要する時間を短縮できます。

SSL/TLSセッションのキャッシュは、Oracle Traffic Directorではデフォルトで有効化されています。SSL/TLSが有効化されているリスナーで新しい接続が確立されるとき、Oracle Traffic Directorは、SSL/TLSキャッシュにクライアントのセッションIDが含まれているかどうかをチェックします。クライアントのセッションIDがキャッシュ内に存在していて有効な場合、Oracle Traffic Directorは、そのセッションの再利用をクライアントに許可します。

SSL/TLSセッション・キャッシュ内の最大エントリ数、およびSSL/TLSセッションIDがキャッシュ内に格納される期間を構成できます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成のSSL/TLSセッションのキャッシュ設定を構成できます。

Fusion Middleware Controlを使用したSSL/TLSセッションのキャッシュ設定の構成

Fusion Middleware Controlを使用してSSL/TLSセッションのキャッシュ設定を構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 変更する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「詳細構成」→「設定」を選択します。

7. ページの「SSL/TLSキャッシュ」セクションに移動します。

8. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

9. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したSSL/TLSセッション・キャッシュ設定の構成

- 構成の現在のSSL/TLSキャッシュ設定を表示するには、次の例に示すように、otd_getSslSessionCachePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getSslSessionCacheProperties(props)

enabled=true
max-entries=10000
max-ssl3-tls-session-age=86400

- SSL/TLSセッション・キャッシュ設定を変更するには、otd_setSslSessionCachePropertiesコマンドを実行します。
たとえば、次のコマンドでは、SSL/TLSセッション・キャッシュに許可された最大エントリ数が20000に変更されます。

props = {}
props['configuration'] = 'foo'
props['max-entries'] = '20000'
otd_setSslSessionCacheProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

15.8.2 暗号および証明書鍵

強力な暗号およびサイズの大きい秘密鍵を使用すると、SSL/TLS接続のセキュリティはより安全に保護されますが、パフォーマンスに影響を及ぼします。

- SSL/TLS接続において、特定の暗号(AES、RC4など)では、より強力な暗号(3DESなど)よりもデータ転送に必要な演算リソースが少なくて済みます。「厳密なSNIホスト一致」が有効化されているリスナーでSSL/TLS暗号を選択する場合、この点を考慮してください。
リスナーに対する暗号の構成の詳細は、10.1.4項「リスナーのSSL/TLS暗号の構成」を参照してください。

SNIホスト一致の詳細は、10.1.6項「厳密なSNIホスト一致について」を参照してください。

- 最初のSSL/TLSハンドシェイク・プロセスでは、鍵サイズの小さいRSA証明書(512、1024および2048ビット)の方が鍵サイズの大きい証明書(4096ビット)よりもかかる時間が短くなります。
自己署名証明書および証明書署名リクエストの作成の詳細は、10.3項「証明書の管理」を参照してください。

15.9 アクセス・ログ・バッファ設定の構成

アクセス・ログには、サーバーへのクライアント・リクエストおよびサーバーからのレスポンスについての情報が含まれます。Oracle Traffic Directorインスタンスのクライアント・リクエストの受信率が非常に高い場合、これは、本番環境では一般的な状況ですが、ディスク上のログ・ファイルにエントリが書き込まれる頻度が高くなります。ディスクへの頻繁な書込みは、サーバーのパフォーマンスに影響する可能性のある、I/Oに負荷がかかるアクティビティです。

Oracle Traffic Directorがディスク上のアクセス・ログにエントリを書き込む頻度を減らすために、アクセス・ログの更新内容をバッファできます。Oracle Traffic Directorでは、アクセス・ログのバッファリングはデフォルトで有効化されます。

アクセス・ログ・バッファ・サイズ、1サーバー当たりのアクセス・ログ・バッファ数、およびエントリがバッファ内に保持される最大期間の制限を指定できます。バッファ・サイズ、バッファ数、またはバッファ内のエントリの経過時間が、指定した制限に到達すると、Oracle Traffic Directorは、バッファされたデータをディスク上のアクセス・ログに書き込みます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、アクセス・ログ・バッファ設定をチューニングできます。

Fusion Middleware Controlを使用したアクセス・ログ・バッファ設定の構成

Fusion Middleware Controlを使用してアクセス・ログ・バッファ設定を構成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. アクセス・ログ・バッファ・プリファレンスを構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「ロギング」を選択します。
「ログ・プリファレンス」ページが表示されます。

7. ページの「詳細設定」セクションに移動し、「アクセス・ログ・バッファ」サブセクションにスクロール・ダウンします。

8. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

9. 必要な変更を行った後、「適用」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したアクセス・ログ・バッファ設定の構成

- 現在のアクセス・ログ・バッファ・プロパティを表示するには、次の例に示すように、otd_getAccessLogBufferPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getAccessLogBufferProperties(props)

enabled=true
buffer-size=8192
direct-io=false
max-buffers=1000
max-buffers-per-file=default
max-age=1

- アクセス・ログ・バッファ・プロパティを変更するには、次の例に示すように、otd_setAccessLogBufferPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['max-buffers'] = '2000'
otd_setAccessLogBufferProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

ログの表示、ログ・プリファレンスの構成、ログのローテーションなどの詳細は、第11章「ログの管理」を参照してください。

15.10 コンテンツ圧縮の有効化と構成

圧縮されたオブジェクトは、少ないラウンドトリップで、より速くクライアントに送信されるため、高価なハードウェアへの投資を増やすことなく全体の待機時間が削減されます。

各Oracle Traffic Director仮想サーバーに固有の圧縮ルールを1つ以上作成し、すべてのリクエストに適用するように、または指定された条件に一致するリクエストのみに適用するように構成できます。

注意:
GIF、JPEGおよびPNGイメージ、ならびにZIPされたファイルなどの特定のファイルは、すでに圧縮されているか、それ以上圧縮することはできません。Oracle Traffic Directorでこのようなファイルを圧縮するように指定すると、圧縮の利点を得られずに追加のオーバーヘッドが発生します。したがって、仮想サーバーで圧縮ルールを作成する場合は、このようなファイルは除外してください。

各圧縮ルールでは、次のパラメータも指定できます。

- スケール1から9の圧縮レベル。レベル1では圧縮時間は最短で、レベル9では圧縮率は最高になります。
圧縮レベルが高くなるほど、圧縮プロセス中により多くのCPUリソースが消費されますが、圧縮されたコンテンツの送信に必要な帯域幅は比較的小さくて済みます。一方、圧縮レベルが低い場合は、比較的CPUへの負荷が小さくなりますが、圧縮後のコンテンツの送信に必要な帯域幅が大きくなります。圧縮レベルを選択するときは、環境内で、CPUリソースとネットワークの帯域幅のいずれがより高価であるかを考慮してください。

- CPUの使用量がより高価である場合、低い圧縮レベルを選択します。

- ネットワークの帯域幅が主な制限事項である場合、高い圧縮レベルを選択します。

- 1回で圧縮するバイト数(フラグメント・サイズ)。

- Vary: Accept-Encodingヘッダーをレスポンス内に含めるかどうか。
Vary: Accept-Encodingヘッダーは、クライアントとOracle Traffic Director間に存在するプロキシに、コンテンツの解凍が不可なクライアントに圧縮済コンテンツを提供しないように指示します。

Fusion Middleware Controlを使用した圧縮ルールの構成

Fusion Middleware Controlを使用して圧縮ルールを作成するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. 圧縮ルールを作成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。

7. ナビゲーション・ペインで、「仮想サーバー」を展開し、圧縮ルールを作成する仮想サーバーの名前を展開して、「圧縮」を選択します。
「圧縮ルール」ページが表示されます。仮想サーバーに現在定義されている圧縮ルールがリストされ、その圧縮ルールが有効化されているかどうかが示されます。

圧縮ルールの作成

1. 「新規圧縮ルール」をクリックします。
「新規圧縮ルール」ダイアログ・ボックスが表示されます。

「名前」フィールドで、新規圧縮ルールの名前を入力します。

2. 「次」をクリックします。
条件を適用する場合は、「式の編集」を選択します。「新規式」ペインで「作成」ボタンを選択して新しいページを表示し、各ドロップダウン・リストから「変数」、「関数」および「演算子」を選択し、「値」フィールドに値を入力します。

複数の式を構成する場合は、ドロップダウン・リストでand/or演算子を選択します。同様に、指定した式が偽に評価されるときにルートを適用する場合は、Not演算子を使用します。

条件を手動で入力するには、ページの右上隅にある「手動編集」ボタンをクリックします。「条件」フィールドで、ルールが適用される条件を指定します。条件式の作成の詳細は、「条件」フィールドの近くにあるヘルプ・ボタンをクリックするか、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

3. 「OK」をクリックして、「圧縮ルールの作成」をクリックします。
作成したキャッシュ・ルールが「圧縮ルール」ページに表示されます。

圧縮ルールの編集

圧縮ルールを有効化または無効化する、あるいはルールの設定を変更するには、次の操作を行います。

1. 変更する圧縮ルールの「名前」をクリックします。
「圧縮ルールの編集」ダイアログ・ボックスが表示されます。

注意:
条件ビルダーにアクセスして条件を編集するには、「条件を満たすリクエスト」を選択し、「編集」をクリックします。条件ビルダーでは古い式を削除したり、新しい式を作成したりできます。

2. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。

「取消」ボタンをクリックすることで、いつでも変更を破棄できます。

3. 必要な変更を行った後、「OK」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

圧縮ルールの削除

圧縮ルールを削除するには、「削除」ボタンをクリックします。確認プロンプトで、「はい」をクリックします。

WLSTを使用した圧縮ルールの構成

- 仮想サーバーの圧縮ルールを作成するには、otd_createCompressionRuleコマンドを実行します。
たとえば、次のコマンドでは、構成fooの仮想サーバーbarに対してcompress-docsという名前のルールが作成され、このルールでは、式$uri='^/docs'がtrueと評価されるリクエストがキャッシュされます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['compression-rule'] = 'compress-docs'
props['condition'] = '$uri='^/docs''
otd_createCompressionRule(props)

conditionプロパティの値は、正規表現にする必要があることに注意してください。条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』 の変数、式および文字列の補間の使用に関する項を参照してください。

- 仮想サーバーに定義されている圧縮ルールのリストを表示するには、次の例に示すように、otd_listCompressionRulesコマンドを実行します。

props = {}props['configuration'] = 'foo'props['virtual-server'] = 'bar'otd_listCompressionRules(props)

compress-docs
compress-all

- 圧縮ルールの現在の設定を表示するには、次の例に示すように、otd_getCompressionRulePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['compression-rule'] = 'compression-rule-1'
otd_getCompressionRuleProperties(props)

name=compression-rule-1
condition="$uri = '^/doc'"
insert-vary-header=true
compression-level=6
fragment-size=8192

- 圧縮ルールを変更するには、otd_setCompressionRulePropertiesコマンドを実行します。
たとえば、次のコマンドでは、ルールcompression-rule-1の圧縮レベルがレベル8に変更されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['compression-rule'] = 'compression-rule-1'
props['compression-level'] = '8'
otd_setCompressionRuleProperties(props)

- 圧縮ルールを削除するには、次の例に示すように、otd_deleteCompressionRuleコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['compression-rule'] = 'compression-rule-1'
otd_deleteCompressionRule(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

15.11 オリジン・サーバーへの接続のチューニング

Oracle Traffic Director仮想サーバーは、ネットワークの外側にあるクライアントが、バック・エンドにある複数のオリジン・サーバーにホストされている重要データおよびアプリケーションにアクセスする際に使用するリバース・プロキシとして機能します。この項では、リバース・プロキシ・サーバーとしてのOracle Traffic Directorのパフォーマンスを向上させるためにチューニングできるパラメータについて説明します。

- キープ・アライブの有効化: このパラメータは、Oracle Traffic Director仮想サーバーがオリジン・サーバーへの永続接続を使用するか、またはリクエストごとに新規接続を作成するのかどうかを示します。これはデフォルトで有効になっています。

- キープ・アライブのタイムアウト: このパラメータは、永続接続がオープンの状態で保持される最大期間(秒単位)を示します。デフォルトのタイムアウトの期間は29秒です。

- アイドル・タイムアウト: このパラメータは、オリジン・サーバーへの接続がアイドル状態のまま維持される最大期間(秒単位)を示します。デフォルトの期間は300秒です。

- 常にキープ・アライブを使用: このパラメータは、Oracle Traffic Director仮想サーバーが、すべてのリクエスト・タイプに対して、オリジン・サーバーへの既存の永続接続を再利用できるかどうかを示します。このパラメータが有効化されていない場合(デフォルト)、Oracle Traffic Director仮想サーバーは、GET、HEADおよびOPTIONSリクエスト・メソッドについてのみ、オリジン・サーバーへの永続接続の使用を試みます。

- プロキシ・バッファ・サイズ: このパラメータは、Oracle Traffic Directorがオリジン・サーバーから受信したデータをクライアントに送信する前に、そのデータを格納するバッファのサイズを示します。バッファが大きくなるほど、writeシステム・コールの数は少なくなります。プロキシ・バッファのデフォルト・サイズは、16KBです。

Oracle Traffic Director仮想サーバーとオリジン・サーバー・プール間の接続のリバース・プロキシ設定は、ルートで定義されます。リバース・プロキシ設定を変更するには、Fusion Middleware ControlまたはWLSTのいずれかを使用してルートを編集する必要があります。

注意:
現在のリリースでは、Fusion Middleware ControlまたはWLSTのいずれかを使用してプロキシ・バッファ・サイズは構成できません。
ルートのプロキシ・バッファ・サイズを構成するには、次の操作を行います。

1. 編集するルートを含む仮想サーバーのvs_name-obj.conf構成ファイルに含まれるhttp-client-configサーバー・アプリケーション・ファンクション(SAF)にproxy-buffer-sizeパラメータを追加します。
vs_name-obj.confファイルは、次のディレクトリにあります。

INSTANCE_HOME/net-config_name/config

proxy-buffer-sizeおよびその他のリーバス・プロキシ・パラメータが構成されているルート(route1)の例を次に示します。

<Object name="route1">
ObjectType fn="http-client-config" keep-alive-timeout="31" always-use-keep-alive="true" keep-alive="false" timeout="360" proxy-buffer-size="32768"
Route fn="set-origin-server" origin-server-pool="origin-server-pool-1"
</Object>

2. vs_name-obj.confファイルを保存して閉じます。

3. pullComponentChangesコマンドを実行して、管理サーバー上の構成ストアを更新し、構成のすべてのインスタンスでこの変更を有効にします。

pullComponentChanges('otd_example.com')

otd_example.comは、プロキシ・バッファ・サイズを構成したノードの名前です。

http-client-configサーバー・アプリケーション・ファンクション(SAF)の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』 を参照してください。

Fusion Middleware Controlを使用したルートの編集

Fusion Middleware Controlを使用してルートを編集するには、次を実行します。

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. ルートを編集する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。

7. ナビゲーション・ペインで、「仮想サーバー」を展開し、ルートを編集する仮想サーバーの名前を展開して、「ルート」を選択します。
「ルート」ページが表示されます。仮想サーバーに現在定義されているルートがリストされます。

8. 編集するルートの「名前」をクリックします。
ルート設定ページが表示されます。

9. ルート設定ページの次のフィールドにリバース・プロキシ・パラメータを指定します。

ルート設定ページのセクション

フィールド

詳細設定: オリジン・サーバーとの接続用のクライアント構成

キープ・アライブ
キープ・アライブのタイムアウト

常にキープ・アライブを使用
アイドル・タイムアウト

画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。

「取消」ボタンをクリックすることで、いつでも変更を破棄できます。

10. 必要な変更を行った後、「OK」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したルートの構成

ルートのプロパティを変更するには、otd_setRoutePropertiesコマンドを実行します。次は、前述したリバース・プロキシ・パラメータの名前です。

keep-alive-timeout
always-use-keep-alive
use-keep-alive
timeout

たとえば、次のコマンドでは、構成fooの仮想サーバーbar内のルートroute1のキープ・アライブ・タイムアウト時間が30秒に変更されます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
props['keep-alive-timeout'] = '30'
otd_setRouteProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

15.12 Solaris固有のチューニング

この項では、Solaris固有のチューニングについて説明します。これらのプラットフォーム固有のチューニングのヒントおよび実行するすべての変更は、システム上の他のプロセスに影響を与える可能性があることに注意してください。

15.12.1 単一のプロセスで開くファイル(ファイル・ディスクリプタの制限)

プラットフォームが異なると、1つのプロセスで一度に開くことができるファイル数の制限が異なります。ビジー状態のサイトでは、この数値を大きくします。Solarisシステムでは、/etc/systemファイルのrlim_fd_maxおよびrlim_fd_curを設定して、この制限を制御します。Solaris 11の場合、rlim_fd_maxのデフォルトは65536、rlim_fd_curのデフォルト値は256です。

/etc/systemファイルにこの変更またはなんらかの変更を加えた後は、新しい設定を有効にするため、Solarisを再起動します。また、Solarisを新しいバージョンにアップグレードする場合は、/etc/systemに追加したすべての行を削除し、その行がアップグレード後も有効であることを確認した後にのみ、追加しなおします。

この変更を行うもう一つの方法は、ulimit –n <value>コマンドを使用することです。このコマンドを使用する場合、システムの再起動は不要です。ただし、このコマンドはログイン・シェルを変更するのみであるのに対し、etc/systemファイルの編集はすべてのシェルに影響を与えます。

15.12.2 HTTPサーバーへの接続の失敗

Oracle Traffic Directorインスタンスに大きな負荷がかかり、クライアントで接続タイムアウトが発生する場合は、HTTPリスナー・バックログ・キューのサイズを増やすことができます。この設定値を増やすには、HTTPリスナーのリスニング・キューの値を編集します。

これに加えて、Solaris TCP/IPネットワーキング・コード内の制限値も増やす必要があります。次のコマンドを実行して変更されるパラメータは2つあります。

ipadm set-prop -p _conn_req_max_q=4096 tcp

ipadm set-prop -p _conn_req_max_q0=4096 tcp

これら2つの設定で、待機接続で満たされる可能性がある2つのSolarisリスニング・キューの最大値が増加します。設定_conn_req_max_qは、accept()コールからの戻りを待つ完了済の接続数を増やします。設定_conn_req_max_q0は、ハンドシェイクが未完了の接続の最大数を増やします。_conn_req_max_qおよび_conn_req_max_q0のデフォルト値はそれぞれ、128および1024です。

これらの変更の効果は、netstat -sコマンドを使用し、tcpListenDrop、tcpListenDropQ0およびtcpHalfOpenDropの値を見ることで監視できます。その値を確認してから、これらの値を調整します。カウンタが0でない場合は、最初に値を2048に調整し、netstatの出力の監視を継続します。

Oracle Traffic Directorで処理できる数よりも多くの接続を受け入れないでください。tcpListenDrop、tcpListenDropQ0およびtcpHalfOpenDropパラメータの値を2048に設定すると、通常は接続リクエストの失敗が減少し、4096までの値で改善効果が見られます。

HTTPリスナーのリスニング・キュー設定および、関連するSolarisの_conn_req_max_qおよび_conn_req_max_q0の設定は、Oracle Traffic Directorのスループットと一致することになります。これらのキューは、Webユーザーからの不規則な接続率を管理するバッファとして機能します。これらのキューを使用することで、Solarisでは、Oracle Traffic Directorで接続が処理されるまで、その接続を受け入れて保持できます。

15.12.3 TCPバッファリングのチューニング

TCPバッファリングは、send_bufパラメータおよびrecv_bufパラメータを使用してチューニングできます。これらのパラメータの詳細は、表15-1「パフォーマンス・ベンチマークのためのSolarisのチューニング」を参照してください。

15.12.4 ファイル・システム・メンテナンスの軽減

UNIXファイル・システム(UFS)ボリュームは、各ファイルがアクセスされた時刻を保持しています。使用中の環境ではファイルのアクセス時刻の更新が重要でない場合、/etc/vfstabのデータ・ボリュームのマウント・ポイントにnoatimeパラメータを追加することにより、アクセス時刻の更新をオフにできます。例:

/dev/dsk/c0t5d0s6 /dev/rdsk/c0t5d0s6 /data0 ufs 1 yes noatime

注意:
noatimeパラメータは、ファイルが変更されたときにはアクセス時刻の更新をオフにせず、ファイルへのアクセスがあるとオフにします。

ZFSでは、zfs setコマンドを使用して、設定可能なデータセット・プロパティを変更できます。次の例では、tank/homeのatimeプロパティをoffに設定します。

zfs set atime=off tank/home

15.12.5 ビジー状態のボリュームまたはディスクにおける長いサービス時間

Oracle Traffic Directorインスタンスのレスポンス時間は、ディスク・サブシステムのパフォーマンスに大きく影響されます。iostatユーティリティを使用して、ディスクのビジー状態やI/Oリクエストの完了の速さ(それぞれ%bおよびsvc_t columns)を監視できます。サービス時間は、ビジー状態が30%未満のディスクでは重要ではありません。ただし、よりビジーなディスクの場合は、サービス時間が20ミリ秒を超えないようにする必要があります。ビジーなディスクでサービスが遅い場合は、ディスク・パフォーマンスを向上させると、パフォーマンスがかなり改善する可能性があります。ビジーなディスクと負荷が少ないディスクが混在する場合は、ビジーなディスクから負荷が少ないディスクにファイルをいくつか移動して、負荷を分散します。

15.12.6 短期のシステム監視

Solarisでは、システム動作を追跡するツールがいくつか提供されています。それらの出力をファイルに取得して後日分析することもできますが、次に示すツールは、主としてリアル・タイムにシステム動作を監視するために用意されています。

- iostat -x 60コマンドは、ディスク・パフォーマンスの統計を60秒間隔でレポートします。
各ディスクのビジー状態の度合を確認するには、%b列を見ます。その時点でビジー状態が20%を超えるディスクについては、svct列でレポートされるサービス時間に注目します。その他の列は、I/O操作率、転送データ量などについての情報を示します。

- vmstat 60コマンドは、仮想メモリー・アクティビティおよび一部のCPU統計を60秒間隔でまとめます。
sr列を見ると、ページ・スキャン率を追跡できます。その率が高すぎる場合には対処します。また、us列、sy列およびid列を監視して、CPUの使用率を確認します。突然爆発的に増加する処理に対応するため、多くのCPUパワーを予約しておく必要があることに注意してください。また、r列を追跡して、CPU時間で競合するスレッド数を確認します。この数がCPU数の約4倍を超えたままの場合は、サーバーの並行性を減らします。

- mpstat 60コマンドはCPU統計の詳細を表示し、dlstat show-link -i 60コマンドはネットワーク・アクティビティの概要を示します。

15.12.7 長期のシステム監視

前述のツールでシステム・パフォーマンスを監視することは重要ですが、その一方で、より長期のパフォーマンス履歴を収集することも、傾向の把握に役立つため、同様に重要です。たとえば、システムのベースライン・レコードは、システムの動作が悪くなり始めた場合に、何が変わったかのかを解明するのに役立ちます。次の手順を実行して、システム・アクティビティ・レポート・パッケージを有効化します。

- 次のコマンドを実行します。

svcadm enable system/sar

- crontab -e sysコマンドを実行して、sa1コマンドおよびsa2コマンドを含む行からコメント文字#を削除します。サイトのアクティビティ・プロファイルに応じて、コマンドを実行する頻度および時間を調整できます。このファイルの形式の説明は、crontab manのページを参照してください。
このコマンドを使用すると、システムにより/var/adm/saディレクトリのファイルにパフォーマンス・データが保存され、デフォルトで1か月保持されます。次に、sarコマンドを使用して、目的の期間の統計を調査します。

15.12.8 パフォーマンス・ベンチマークのためのチューニング

次の表は、パフォーマンスおよびスケーラビリティのベンチマークの際に使用されるSolarisのオペレーティング・システムのチューニングを示しています。これらの値は、目的の結果を得るためのシステムのチューニング方法の例を示しています。

表15-1 パフォーマンス・ベンチマークのためのSolarisのチューニング

パラメータ

有効範囲

デフォルト値

チューニング後の値

備考

rlim_fd_cur

/etc/system

256

65536

弱い制限

rlim_fd_max

/etc/system

65536

65536

プロセスのオープン・ファイル・ディスクリプタの制限。(関連するソケット、ファイルおよびパイプ(ある場合)の)予想される負荷の詳細の原因となります。

_time_wait_interval

ipadm set-prop

60000

600000

クライアントにも設定します。

_conn_req_max_q

ipadm set-prop

128

1024

_conn_req_max_q0

ipadm set-prop

1024

4096

_ip_abort_interval

ipadm set-prop

300000

600000

_keepalive_interval

ipadm set-prop

7200000

9000000

トラフィックの多いWebサイトでは、この値を低くします。

_rexmit_interval_initial

ipadm set-prop

1000

3000

再伝送が30-40%を超える場合、この値を高くします。

_rexmit_interval_max

ipadm set-prop

60000

100000

_rexmit_interval_min

ipadm set-prop

200

3000

smallest_anon_port

ipadm set-prop

32768

65535

クライアントにも設定します。

send_buf

ipadm set-prop

49152

128000

送信バッファを増やすため。

recv_buf

ipadm set-prop

128000

1048576

受信バッファを増やすため。

16 問題の診断およびトラブルシューティング

この章では、Oracle Traffic Directorの使用中に発生する可能性のある問題の診断および解決に使用できる手順および情報ソースについて説明します。

この章には次の項が含まれます:

- Oracle Traffic Directorのトラブルシューティングのロードマップ

- 一般的なエラーの解決方法

- よくある質問

- サポートに関するオラクルへの連絡

16.1 Oracle Traffic Directorのトラブルシューティングのロードマップ

この項では、Oracle Traffic Directorでの問題を診断および解決するために実行できる一連のタスクについて説明します。

1. システム構成が正しいかどうかを確認します。
サポートされているプラットフォームおよびオペレーティング・システムの詳細は、次にあるOracle Fusion Middlewareのサポートされるシステム構成を参照してください。

http://www./technetwork/middleware/ias/downloads/fusion-certification-100350.html

2. 16.2項「一般的なエラーの解決方法」で、問題の解決方法を探します。

3. 16.3項「よくある質問」に問題についての情報や解決方法が記載されているかどうかを確認します。

4. 問題の診断を実行します。

1. サーバー・ログに記録されているメッセージを確認します。タイプがWARNING、ERRORおよびINCIDENT_ERRORのメッセージを探します。
エラー・メッセージに、タイプがWARNINGおよびERRORのメッセージがある場合、次の指示に従って問題を解決します。

INCIDENT_ERRORメッセージは、原因不明の重大な問題を示します。Oracleサポートに連絡する必要があります。

2. サーバー・ログの冗長度を高め、問題の再現を試みます。
表 11-1「サーバー・ログ・レベル」にあるように、Oracle Traffic Directorではサーバー・ログについて、いくつかのログ・レベルがサポートされています。デフォルトのログ・レベルは、NOTIFICATION:1です。最小の冗長度ログ・レベルは、INCIDENT_ERRORで、このレベルでは、重大なエラー・メッセージのみが記録されます。TRACE:1、TRACE:16またはTRACE:32レベルでは、ログはレベルに応じて冗長度が増しますが、より詳細な情報が提供され、問題の診断に活用できます。

ログの冗長度を高め、問題の再現を試みます。問題が再度発生したら、問題の原因を示すメッセージ・ログを確認します。

サーバー・ログ・レベルの変更の詳細は、11.3項「ログ・プリファレンスの構成」を参照してください。

5. 16.4項「Oracleサポートへの連絡」の説明に従い、Oracleサポートに連絡します。

16.1.1 高可用性構成に関する問題のトラブルシューティング

この項では、Oracle Traffic Directorの高可用性構成に関する問題を診断および解決するためのタスクについて説明します。

- Oracle Traffic Director構成が2つのノード上にデプロイされている必要があります。詳細は、14.2項「フェイルオーバー・グループの作成および管理」を参照してください。

- 各フェイルオーバー・グループのルーターIDは一意である必要があります。

- KeepAlivedがインストールされていることを確認します。通常、Oracle Traffic Directorインスタンスが実行されているExalogic計算ノード(またはVM)では、両ノードともデフォルトでKeepAlivedソフトウェアがインストールされています。KeepAlivedがインストールされていることを確認するには、次のコマンドを実行します。

rpm -qa | grep keepalived

KeepAlivedが正しくインストールされている場合、次のような出力が表示されます。

keepalived-1.2.2-1.el5

KeepAlivedがインストールされていない場合、RPMはソフトウェア・リポジトリ内にあります。

- KeepAlived特有の情報は、/var/log/messagesにあるログで確認できます。

- 高可用性構成を正常に完了するには、正しいVIPアドレスと適切なサブネット・マスク(ネットマスク)のビットサイズを指定する必要があります。また、実際のネットマスク値ではなく、ネットマスクのビット数を指定する必要があります。詳細は、14.2.1項「フェイルオーバー・グループの作成」を参照してください。

16.2 一般的なエラーの解決方法

この項では、次の問題の解決策を示します。

- 16.2.1項「起動障害: ポートにバインドできない」

- 16.2.2項「HTTPリスナー・ポート80でサーバーを起動できない」

- 16.2.3項「Oracle Traffic Directorが、起動時にメモリーを大量に消費する」

- 16.2.4項「オペレーティング・システム・エラー: システム内で開いているファイルが多すぎる」

- 16.2.5項「一時ディレクトリの変更後にインスタンスを停止できない」

- 16.2.6項「管理サーバーを再起動できない」

- 16.2.7項「Oracle Traffic Directorでセッションの固定性が維持されない」

16.2.1 起動障害: ポートにバインドできない

このエラーは、構成内の1つ以上のHTTPリスナーが、他のプロセスによってすでに使用中のTCPポート番号に割り当てられている場合に発生します。

[ERROR:32] startup failure: could not bind to port port (Address already in use)
[ERROR:32] [OTD-10380] http-listener-1: http://host:port: Error creating socket (Address already in use)
[ERROR:32] [OTD-10376] 1 listen sockets could not be created
[ERROR:32] server initialization failed

次のコマンドを実行すると、指定のポートでリスニング中のプロセスを検出できます。

> netstat -npl | grep :port | grep LISTEN

構成済のHTTPリスナー・ポートが他のプロセスで使用中の場合は、ポートを解放するか、9.3項「リスナーの変更」の説明に従って変更します。

16.2.2 HTTPリスナー・ポート80でサーバーを起動できない

このエラーは、1024までのHTTPリスナー・ポート(たとえば80)を構成していて、Oracle Traffic Directorインスタンスを-root以外のユーザーとして起動しようとした場合に発生します。

次のメッセージがサーバー・ログに書き込まれます。

[ERROR:32] [OTD-10376] 1 listen sockets could not be created
[ERROR:32] [OTD-10380] http-listener-1: http://soa.example.com:80:
Error creating socket (No access rights)

1024までのポート番号は、Internet Assigned Numbers Authority (IANA)によって様々なサービスに割り当てられます。これらのポート番号にアクセスできるのは、rootユーザーのみです。

この問題を解決するには、次のいずれかを行います。

- 1024より上のポート番号(たとえば8080)でOracle Traffic Directorを構成し、ポート80で受信したリクエストを構成済Oracle Traffic DirectorポートにリダイレクトするIPパケット・フィルタリング・ルールを次のように作成します。

# /sbin/iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
# /sbin/iptables -t nat -A PREROUTING -p udp -m udp --dport 80 -j REDIRECT --to-ports 8080

次の例に示すように、chkconfigコマンドを実行し、サーバーの再起動時にiptablesサービスがデフォルトで起動されることを確認します。

# chkconfig --level 35 iptables on

- xinetdがシステム内にインストールされている場合、/etc/xinetd.d/ディレクトリに次のエントリを含むファイル(たとえばotd)を作成します。

service otd
{
type = UNLISTED
disable = no
socket_type = stream
protocol = tcp
user = root
wait = no
port = 80
redirect = 127.0.0.1 8080
}

このエントリにより、ポート80で受けたすべての受信TCPトラフィックがローカル・マシンのポート8080にリダイレクトされます。

詳細は、Linux xinetdドキュメントを参照してください。

16.2.3 Oracle Traffic Directorが、起動時にメモリーを大量に消費する

Oracle Traffic Directorインスタンスの起動時、特定のパラメータの値(キープ・アライブ接続の最大数、接続キューのサイズ、オリジン・サーバーへの最大接続数)が、システムのファイル・ディスクリプタ制限に基づき自動的に割り当てられます。

ファイル・ディスクリプタ制限が非常に高い場合、未定義パラメータに自動割り当てされる値は、必要以上に高くなり、その結果、Oracle Traffic Directorで過度なメモリー量が消費されます。この問題を回避するには、キープ・アライブ接続の最大数(15.5.3項「キープ・アライブ設定のチューニング」)、接続キューのサイズ(15.3.4項「スレッド・プールおよび接続キュー設定のチューニング」)および個々のオリジン・サーバーへの最大接続数(6.3項「オリジン・サーバーの変更」)を明示的に構成します。

16.2.4 オペレーティング・システム・エラー: システム内で開いているファイルが多すぎる

このLinuxのオペレーティング・システム・エラーは、割り当てられたファイル・ディスクリプタ数がシステムの制限に到達すると発生します。

次のメッセージがサーバー・ログに書き込まれます。

[ERROR:16] [OTD-10546] Insufficient file descriptors for optimum configuration.

このエラーを回避するには、Linuxのファイル・ディスクリプタ制限をデフォルトの1024から合理的な数に増やします。詳細は、15.2項「ファイル・ディスクリプタ制限のチューニング」を参照してください。

16.2.5 一時ディレクトリの変更後にインスタンスを停止できない

このエラーは、構成の一時ディレクトリを変更した後、インスタンスを停止せずに変更デプロイし、その後インスタンスを停止しようとすると発生します。一時ディレクトリは、構成のインスタンスのプロセスIDおよびソケット情報が格納される(管理ノード上)のディレクトリです。

このエラーが発生すると、次のメッセージがサーバー・ログに書き込まれます。

OTD-63585 An error occurred while stopping the server. For details, see the server log.

このエラーを回避する手順

構成の一時ディレクトリを変更した場合、構成のすべてのインスタンスをまず停止して、変更をデプロイし、次にインスタンスを起動します。

この問題を回避する手順

Oracle Traffic Directorインスタンスを停止します。

1. 次のいずれかを実行して、構成の現在の一時ディレクトリを検出します。

- 次の例に示すように、otd_getConfigurationProperties WLSTコマンドを実行します。

props = {}
props['configuration'] = 'foo'
otd_getConfigurationProperties(props)

temp-path=/tmp/net-test-a46e5844
...

- Fusion Middleware Controlにログインし、必要な構成を選択して「詳細設定」を選択します。結果のページで、「一時ディレクトリ」フィールドを探します。

一時ディレクトリへのパスを記録します。

2. 次のコマンドを実行して、実行中のインスタンスのプロセスIDを検出します。

cat temp_dir/pid

temp_dirは、手順1で記録した一時ディレクトリへのフル・パスです。

このコマンドによって戻されるプロセスIDを記録します。

3. 次のコマンドを実行して、プロセスを停止します。

kill pid

pidは、手順2で記録したプロセスIDです。

16.2.6 管理サーバーを再起動できない

Linuxシステムでは、デフォルトで/etc/cron.daily/tmpwatchにあるcronスクリプトtmpwatchが毎日実行されるように設定されています。このスクリプトは、管理サーバー上のすべての/tmpディレクトリから240時間(10日)経過したファイルをすべて削除します。そのため、管理サーバーを10日間再起動しなかった場合、デフォルトpidファイルが削除されます。これは、10日後に管理サーバーを再起動できなくなることを意味します。

この問題を回避するには

- temp-pathの場所を変更する: <otd-home>/admin-server/config/server.xmlファイルで、temp-pathの値をサーバー・ユーザーが排他的な権限を持つ場所に変更します。たとえば、<temp-path>/var/tmp/https-test-1234</temp-path>に変更します。加えて、新しいtemp-pathがtmpwatchスクリプトによって監視されないようにします。

- cronスクリプトを変更する: cronスクリプトからtmpwatchの値240 /tmpを削除します。tmpwatchの監視対象からディレクトリを除外するには、-X/--exclude-patternオプションを使用します。このオプションの詳細は、tmpwatchのmanページを参照してください。

16.2.7 Oracle Traffic Directorでセッションの固定性が維持されない

Oracle Traffic Directorではセッションの固定性が次のように維持されます。

Cookieベースのセッション持続

これは一般的なシナリオで、クライアントがWebサーバーやアプリケーション・サーバーからのcookieを受け入れる場合です。このシナリオでは、Oracle Traffic DirectorはHTTPトラフィックのロード・バランシングを行う際に、自身のcookieを使用してセッションを持続します。これにより、固定性リクエストつまりHTTPセッションcookieが含まれているリクエストは、そのcookieの生成元であるバックエンド・アプリケーション・サーバーに常にルーティングされます。

Oracle Traffic Director 11. 1.1.5を使用している場合で、バックエンド・アプリケーション・サーバーがデフォルトのJSESSIONID以外のHTTPセッションcookieを使用している場合は、セッション持続が履行されるようOracle Traffic Directorを明示的に構成する必要があります。一方、Oracle Traffic Director 11.1.1.6の場合は、オリジン・サーバーからcookieを受信した時点でセッション持続が履行されます。

注意:
Oracle Traffic DirectorでURIベースのセッション固定性を維持するには、WebLogic 10.3.xにパッチを追加する必要があります。

URIベースのセッション持続

このシナリオはあまり一般的ではありません。このシナリオではクライアント側でcookieが無効にされているため、バックエンドのWebサーバーまたはアプリケーション・サーバー側でURIにHTTPセッション情報を付加してセッション持続を維持します。

このシナリオでは、バックエンド・アプリケーション・サーバーによってURIにOracle Traffic DirectorのJRoute cookieが付加される場合に、Oracle Traffic Directorでセッション持続を履行できます。WebLogic Server 10.3.6.2以上、12.1以上、GlassFish 2.0以上などのオリジン・サーバーには、このJRoute cookieをURIに付加する機能が備わっています。そのため、Oracle Traffic DirectorでURIベースのセッション持続を維持できるのは、これらのオリジン・サーバーを使用している場合に限定されます。

16.3 よくある質問

この項には次のサブセクションが含まれます:

- 16.3.1項「構成とは何ですか。」

- 16.3.2項「Fusion Middleware Controlにはどのようにアクセスするのですか。」

- 16.3.3項「初めてFusion Middleware Controlにアクセスする際、証明書の警告が表示されるのはなぜですか。」

- 16.3.4項「構成ファイルを手動で編集できますか。」

- 16.3.5項「Fusion Middleware Controlで、構成の保存と構成のデプロイにはどのような違いがありますか。」

- 16.3.6項「Fusion Middleware Controlで「デプロイメント保留中」のメッセージが表示されるのはなぜですか。」

- 16.3.7項「Fusion Middleware Controlで「インスタンス構成デプロイ済」のメッセージが表示されるのはなぜですか。」

- 16.3.8項「Fusion Middleware Controlセッションが突然終了するのはなぜですか。」

- 16.3.9項「WLSTにはどのようにアクセスするのですか。」

- 16.3.10項「初めてWLSTにアクセスする際、証明書の警告メッセージが表示されるのはなぜですか。」

- 16.3.11項「WLSTコマンドのオプションの短縮名を知るにはどのようにすればよいですか。」

- 16.3.12項「動的検出が有効な場合、ヘルス・チェック・プロトコルとしてTCPを選択できないのはなぜですか。」

- 16.3.13項「プール内のオリジン・サーバーをOracle WebLogic Serverに変更した後、これらは自動検出されませんが、動的検出は有効です。なぜですか。」

- 16.3.14項「Oracle Traffic Directorによって送受信されたリクエストおよびレスポンス・ヘッダーを表示するにはどのようにすればよいですか。」

- 16.3.15項「Oracle Traffic DirectorインスタンスのSSL/TLSの有効化はどのように行いますか。」

- 16.3.16項「サポートされていて、かつ有効化されているSSL/TLS暗号スイートはどのように検出できますか。」

- 16.3.17項「インストールされている証明書のリストを表示するにはどのようにすればよいですか。」

- 16.3.18項「SSL/TLSが有効なOracle Traffic Directorインスタンスへのテスト・リクエストの発行はどのように行いますか。」

- 16.3.19項「SSL/TLS接続の分析はどのように行いますか。」

- 16.3.20項「Oracle Traffic DirectorインスタンスとOracle WebLogic Serverオリジン・サーバー間のSSL/TLS通信の詳細の表示はどのように行いますか。」

- 16.3.21項「SSL/TLSが有効な特定のオリジン・サーバーは、起動しているにもかかわらず、ヘルス・チェックの後オフラインとマークされるのはなぜですか。」

- 16.3.22項「Oracle Traffic Directorはオリジン・サーバーにリクエストを転送する前にクライアントのソースIPアドレスを書き換えますか。」

- 16.3.23項「Oracle Traffic Directorから405ステータス・コードが返されるのはなぜですか。」

- 16.3.23項「Oracle Traffic Directorから405ステータス・コードが返されるのはなぜですか。」

16.3.1 構成とは何ですか。

Oracle Traffic Director用語としての構成は、Oracle Traffic Directorインスタンスの実行時の動作を決定する一連の構成可能な要素(メタデータ)を指します。

詳細は、1.4項「Oracle Traffic Director用語集」を参照してください。

16.3.2 Fusion Middleware Controlにはどのようにアクセスするのですか。

1.7.2項「Fusion Middleware Controlの表示」を参照してください。

16.3.3 初めてFusion Middleware Controlにアクセスする際、証明書の警告が表示されるのはなぜですか。

管理サーバーに自己署名証明書があるため、ブラウザによって警告が表示されます。続行するには、証明書を信頼することを選択する必要があります。

16.3.4 構成ファイルを手動で編集できますか。

Fusion Middleware ControlまたはWLSTのいずれかを使用して構成を編集すると、構成ストア内のファイルが自動的に更新されます。Oracle Traffic Directorドキュメントに指示されている場合を除き、構成ストア内のファイルを手動で編集しないでください。

構成の変更を有効にするには、3.3項「構成の変更のアクティブ化」の説明に従ってインスタンスに対する構成をアクティブにする必要があります。

16.3.5 Fusion Middleware Controlで、構成の保存と構成のデプロイにはどのような違いがありますか。

構成を保存すると、行った変更が管理サーバーの構成ストア内に保存されます。構成のインスタンスに変更を反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成をアクティブにする必要があります。

16.3.6 Fusion Middleware Controlで「デプロイメント保留中」のメッセージが表示されるのはなぜですか。

「デプロイメント保留中」のメッセージは、構成を変更して管理サーバーに保存する際に、Fusion Middleware Controlに表示されます。これは、変更が、構成のインスタンスにはまだコピーされていないことを示します。

必要な構成変更を終えたら、3.3項「構成の変更のアクティブ化」の説明に従い、Fusion Middleware Controlで「変更のデプロイ」をクリックするか、activate WLSTコマンドを実行することで、変更をすべてのインスタンスにデプロイできます。

16.3.7 Fusion Middleware Controlで「インスタンス構成デプロイ済」のメッセージが表示されるのはなぜですか。

インスタンスの構成ファイルを手動で編集すると、インスタンス構成デプロイ済のメッセージがFusion Middleware Controlに表示されます。これは、1つ以上のインスタンスの構成ファイルが、管理サーバーの構成ストア内に格納されている、対応する構成ファイルと異なっていることを示します。

16.3.8 Fusion Middleware Controlセッションが突然終了するのはなぜですか。

Fusion Middleware Controlセッションは、30分間非アクティブな状態が続くと自動的に終了します。再度ログインする必要があります。

16.3.9 WLSTにはどのようにアクセスするのですか。

1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

16.3.10 初めてWLSTにアクセスする際、証明書の警告メッセージが表示されるのはなぜですか。

WLSTは、管理サーバーのSSLポートに接続されます。管理サーバーには、自己署名証明書があります管理サーバーに最初に接続するときに表示されるメッセージは、証明書を信頼するかどうかを選択するためのプロンプトです。正しいサーバーおよびポートに接続されていることを確認し、yを入力して証明書を信頼します。その後のCLIの起動では、警告メッセージは表示されません。

16.3.11 WLSTコマンドのオプションの短縮名を知るにはどのようにすればよいですか。

--helpオプションを使用してコマンドを実行し、コマンドのヘルプを参照してください。

16.3.12 動的検出が有効な場合、ヘルス・チェック・プロトコルとしてTCPを選択できないのはなぜですか。

動的検出が有効な場合、Oracle Traffic Directorは、指定された間隔で、特定のヘッダーを含むHTTPリクエストを送信する必要があり、このヘッダーにより、プール内の指定されたオリジン・サーバーがOracle WebLogic Serverインスタンスであるかどうか、およびサーバーがクラスタに属しているかどうかが判別されます。TCPヘルス・チェック・リクエストに対するレスポンスでは、Oracle WebLogic Serverインスタンスの存在を特定するための十分な情報が提供されません。したがって、動的検出が有効な場合、ヘルス・チェック・プロトコルはHTTPに設定されている必要があります。

16.3.13 プール内のオリジン・サーバーをOracle WebLogic Serverに変更した後、これらは自動検出されませんが、動的検出は有効です。これはなぜですか。

動的検出が有効な場合、Oracle Traffic Directorインスタンスが起動すると、構成済のオリジン・サーバーがOracle WebLogic Serverインスタンスであるかどうかが判別されます。

このため、たとえば、当初Oracle GlassFish Serverインスタンスをオリジン・サーバーとして構成していた場合、起動時にOracle Traffic Directorによって、オリジン・サーバーはOracle WebLogic Serverインスタンスではないことが判別されます。その後、オリジン・サーバーをOracle WebLogic Serverインスタンスで置き換え、次にOracle Traffic Directorにオリジン・サーバーが現在Oracle WebLogic Serverインスタンスであることをあらためて認識させるには、Oracle Traffic Directorインスタンスを再起動するか、再構成する必要があります。

再起動せずに、Oracle WebLogic Serverインスタンスから別のサーバーへ変更する、またその逆を実行するには、次の操作を行います。

1. 必要なオリジン・サーバーで新しいオリジン・サーバー・プールを作成し、古いプールを削除します。詳細は、第5章「オリジン・サーバー・プールの管理」を参照してください。

2. 7.4項「ルートの構成」の説明に従い、新しいプールをポイントするように適切なルートを更新します。

3. 4.4項「再起動が不要なOracle Traffic Directorインスタンスの更新」の説明に従い、softRestart WLSTコマンドを使用して、Oracle Traffic Directorを再構成します。

16.3.14 Oracle Traffic Directorによって送受信されたリクエストおよびレスポンス・ヘッダーを表示するにはどのようにすればよいですか。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、適切なルートを変更し、サーバー・ログへのリクエストおよびレスポンス・ヘッダーの記録を有効にできます。

- Fusion Middleware Controlの使用

1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

3. 「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。

4. ルートを構成する構成を選択します。

5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

6. 「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。

7. ナビゲーション・ペインで、「仮想サーバー」を展開し、ルートを編集する仮想サーバーの名前を展開して、「ルート」を選択します。
「ルート」ページが表示されます。選択された仮想サーバーに現在定義されているルートがリストされます。

8. 構成するルートの「名前」をクリックします。
ルート設定ページが表示されます。

9. ルート設定ページの「詳細設定」セクションに移動し、「オリジン・サーバーとの接続用のクライアント構成」サブセクションにスクロール・ダウンします。

10. 「ログ・ヘッダー」チェック・ボックスを選択します。

11. 「OK」をクリックします。

- WLSTの使用
次の例に示すように、otd_setRoutePropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
props['log-headers'] = 'true'
otd_setRouteProperties(props)

このコマンドにより、構成fooの仮想サーバーbar内のroute-1という名前のルートと関連付けられているオリジン・サーバーとの間でOracle Traffic Directorが送受信するヘッダーのロギングが有効化されます。

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

次の例に示すように、ヘッダーはサーバー・ログに記録されます。

[2011-11-11T03:45:00.000-08:00] [net-test] [NOTIFICATION] [OTD-11008] []
[pid: 8184] for host 10.177.243.152 trying to OPTIONS / while trying to GET
/favicon.ico, service-http reports: request headers sent to origin server(soa.example.com:1900) :[[
OPTIONS / HTTP/1.1
Proxy-agent: Oracle-Traffic-Director/12.2.1.0
Surrogate-capability: otd="Surrogate/1.0"
Host: dadvma0178:1900
Proxy-ping: true
X-weblogic-force-jvmid: unset
Via: 1.1 net-test
Connection: keep-aliv   e
]]
[2011-11-11T03:45:00.000-08:00] [net-test] [NOTIFICATION] [OTD-11009] []
[pid: 8184] for host 10.177.243.152 trying to OPTIONS / while trying to GET
/favicon.ico, service-http reports: response headers received from origin server(soa.example.com:1900) :[[
HTTP/1.1 200 OK
date: Fri, 11 Nov 2011 11:45:00 GMT
server: Apache/2.2.17 (Unix)
allow: GET,HEAD,POST,OPTIONS,TRACE
content-length: 0
keep-alive: timeout=5, max=100
connection: Keep-Alive
content-type: text/html]

16.3.15 Oracle Traffic DirectorインスタンスのSSL/TLSの有効化はどのように行いますか。

10.1項「Oracle Traffic Directorとクライアント間のSSL/TLSの構成」を参照してください。

16.3.16 サポートされていて、かつ有効化されているSSL/TLS暗号スイートはどのように検出できますか。

10.1.4項「リスナーのSSL/TLS暗号の構成」を参照してください。

16.3.17 インストールされている証明書のリストを表示するにはどのようにすればよいですか。

10.3.4項「証明書のリストの表示」を参照してください。

16.3.18 SSL/TLSが有効なOracle Traffic Directorインスタンスへのテスト・リクエストの発行はどのように行いますか。

次のコマンドを実行します。

$ openssl s_client -host hostname -port portnumber -quiet

- -quietオプションを省略すると、SSL/TLS接続についての情報(サーバーDN、証明書名、ネゴシエート済暗号スイート)が表示されます。

- 特定の暗号でテストするには、-cipherオプションを指定します。

SSL/TLS接続が確立された後、次の例に示すように、HTTPリクエストを入力します。

GET /

詳細は、s_client manページを参照してください。

16.3.19 SSL/TLS接続の分析はどのように行いますか。

SSL/TLS接続上のリクエストおよびレスポンスを監視するいくつかのツールを使用できます。ツールの1つの例として、ssltapがありますが、このツールは、クライアントとOracle Traffic Director間のシンプルなプロキシとして機能し、転送される接続に関する情報を表示します。

次のコマンドを実行します。

$ ssltap -l -s otd_host:otd_port

たとえば、クライアントと、SSL/TLSが有効なOracle Traffic Directorリスナーsoa.example.com:1905間の通信を監視するには、次のコマンドを実行します。

$ ssltap -l -s soa.example.com:8080

次のメッセージが表示されます:

Looking up "localhost"...
Proxy socket ready and listening

デフォルトでは、ssltapはポート1924をリスニングします。ブラウザを使用して、https://localhost:1924を接続します。

次のような出力が表示されます。

Connection #1 [Tue Oct 25 04:29:46 2011]
Connected to localhost:8080
--> [
(177 bytes of 172)
SSLRecord { [Tue Oct 25 04:29:46 2011]
type    = 22 (handshake)
version = { 3,1 }
length  = 172 (0xac)
handshake {
type = 1 (client_hello)
length = 168 (0x0000a8)
ClientHelloV3 {
client_version = {3, 1}
random = {...}
session ID = {
length = 0
contents = {...}
}
cipher_suites[29] = {
(0x00ff) TLS_EMPTY_RENEGOTIATION_INFO_SCSV
(0xc00a) TLS/ECDHE-ECDSA/AES256-CBC/SHA
(0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA
(0x0039) TLS/DHE-RSA/AES256-CBC/SHA
(0x0038) TLS/DHE-DSS/AES256-CBC/SHA
(0xc00f) TLS/ECDH-RSA/AES256-CBC/SHA
(0xc005) TLS/ECDH-ECDSA/AES256-CBC/SHA
(0x0035) TLS/RSA/AES256-CBC/SHA
(0xc007) TLS/ECDHE-ECDSA/RC4-128/SHA
(0xc009) TLS/ECDHE-ECDSA/AES128-CBC/SHA
(0xc011) TLS/ECDHE-RSA/RC4-128/SHA
(0xc013) TLS/ECDHE-RSA/AES128-CBC/SHA
(0x0033) TLS/DHE-RSA/AES128-CBC/SHA
(0x0032) TLS/DHE-DSS/AES128-CBC/SHA
(0xc00c) TLS/ECDH-RSA/RC4-128/SHA
(0xc00e) TLS/ECDH-RSA/AES128-CBC/SHA
(0xc002) TLS/ECDH-ECDSA/RC4-128/SHA
(0xc004) TLS/ECDH-ECDSA/AES128-CBC/SHA
(0x0004) SSL3/RSA/RC4-128/MD5
(0x0005) SSL3/RSA/RC4-128/SHA
(0x002f) TLS/RSA/AES128-CBC/SHA
(0xc008) TLS/ECDHE-ECDSA/3DES-EDE-CBC/SHA
(0xc012) TLS/ECDHE-RSA/3DES-EDE-CBC/SHA
(0x0016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
(0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0xc00d) TLS/ECDH-RSA/3DES-EDE-CBC/SHA
(0xc003) TLS/ECDH-ECDSA/3DES-EDE-CBC/SHA
(0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
(0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
}
compression[1] = {
(00) NULL
}
extensions[55] = {
extension type server_name, length [29] = {
0: 00 1b 00 00  18 64 61 64  76 6d 61 30  31 37 38 2e  | .....soa.
10: 75 73 2e 6f  72 61 63 6c  65 2e 63 6f  6d           | example.com
}
extension type elliptic_curves, length [8] = {
0: 00 06 00 17  00 18 00 19                            | ........
}
extension type ec_point_formats, length [2] = {
0: 01 00                                               | ..
}
extension type session_ticket, length [0]
}
}
}
}

これは、ブラウザからOracle Traffic Directorインスタンスに送信されるSSL/TLSのclient helloです。ブラウザから送信される暗号スイートのリストに注目してください。これは、ブラウザが処理するように構成された暗号スイートであり、プリファレンスの順序でソートされています。サーバーは、ハンドシェイク用の暗号スイートを選択します。クライアントによって指定された暗号スイートのいずれもサーバーに構成されていない場合、接続は失敗します。前述の例では、セッションIDが空ですが、これは指定されたサーバーとのキャッシュ済SSL/TLSセッションがブラウザにないことを示します。

Oracle Traffic Directorインスタンスのレスポンスは、次の出力のようになります。

<-- [
(823 bytes of 818)
SSLRecord { [Tue Oct 25 04:29:46 2011]
type    = 22 (handshake)
version = { 3,1 }
length  = 818 (0x332)
handshake {
type = 2 (server_hello)
length = 77 (0x00004d)
ServerHello {
server_version = {3, 1}
random = {...}
session ID = {
length = 32
contents = {...}
}
cipher_suite = (0x0035) TLS/RSA/AES256-CBC/SHA
compression method = (00) NULL
extensions[5] = {
extension type renegotiation_info, length [1] = {
0: 00                                                  | .
}
}
}
type = 11 (certificate)
length = 729 (0x0002d9)
CertificateChain {
chainlength = 726 (0x02d6)
Certificate {
size = 723 (0x02d3)
data = { saved in file 'cert.001' }
}
}
type = 14 (server_hello_done)
length = 0 (0x000000)
}
}
]
--> [

サーバーは、クライアントによって後続のリクエストに含められる暗号スイートTLS/RSA/AES256-CBC/SHAとセッションIDを選択しました。

また、サーバーは、ブラウザが確認するための証明書チェーンも送信しました。ssltapによって証明書がファイルcert.001に保存されました。X.509証明書を解析できる任意のツールを使用して証明書を検査できます。たとえば、次のようなコマンドを実行します。

$ openssl x509 -in cert.001 -text -inform DER

注意:
ssltapは、シングル・スレッドのプロキシ・サーバーです。したがって、これを使用して複数のリクエストを発行すると、リクエストはシリアライズされます。SSL/TLSを使用した同時リクエストでのみ発生する、アプリケーションの特定の問題を分析する必要がある場合、複数のssltapインスタンスを実行してください。

16.3.20 Oracle Traffic DirectorインスタンスとOracle WebLogic Serverオリジン・サーバー間のSSL/TLS通信の詳細の表示はどのように行いますか。

サーバーの起動スクリプトに-Dssl.debug=trueシステム・プロパティを追加することで、Oracle WebLogic ServerインスタンスのSSLデバッグを構成します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLのデバッグに関する項を参照してください。

11.3項「ログ・プリファレンスの構成」の説明に従い、ログ・レベルをTRACE:32に設定し、Oracle Traffic Directorサーバー・ログの冗長度を高めてください。

16.3.21 SSL/TLSが有効な特定のオリジン・サーバーは、起動しているにもかかわらず、ヘルス・チェックの後オフラインとマークされるのはなぜですか。

このエラーは、次のオリジン・サーバーで発生する可能性があります。

- ホスト名ではなくIPアドレスを使用して、オリジン・サーバー・プールに構成されているSSL/TLSが有効なオリジン・サーバー。

- 動的に検出された、SSL/TLSが有効なOracle WebLogic Serverオリジン・サーバー。Oracle Traffic Directorは、ホスト名ではなくIPアドレスを使用してこのサーバーを参照します。

Oracle Traffic Directorは、IPアドレスを使用してこのようなオリジン・サーバーを参照しますが、オリジン・サーバーの証明書には、サーバーのホスト名が含まれています。したがって、ヘルス・チェック・リクエストに対して、オリジン・サーバーが証明書を提示すると、Oracle Traffic Directorはそれらの検証を試みますが成功しません。SSL/TLSハンドシェイクが失敗します。結果として、ヘルス・チェックでは、このようなオリジン・サーバーはオフラインと示されます。サーバー証明書の検証は、デフォルトで有効化されていることに注意してください。

サーバー・ログ・レベルをTRACE:32に設定すると、この障害について記録された、次の例に示すようなメッセージを表示できます。

[2011-11-21T09:50:54-08:00] [net-soa] [TRACE:1] [OTD-10969] [] [pid: 22466]
trying to OPTIONS /, service-http reports: error sending request
(SSL_ERROR_BAD_CERT_DOMAIN: Requested domain name does not match the server's certificate.)

この問題を解決するには、次の例に示すように、otd_setOriginServerPoolSslProperties WLSTコマンドを実行し、オリジン・サーバーのオリジン・サーバー証明書の検証を無効にします。

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['validate-server-cert'] = 'false'
otd_setOriginServerPoolSslProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

16.3.22 Oracle Traffic Directorはオリジン・サーバーにリクエストを転送する前にクライアントのソースIPアドレスを書き換えますか。

Oracle Traffic DirectorはデフォルトでソースIPアドレスを書き換えます。それでも、クライアントIPアドレスはProxy-client-ipという追加のリクエスト・ヘッダーで送信されます。7.4項「ルートの構成」の説明に従って適切なルートを構成することで、Proxy-client-ipやその他のリクエスト・ヘッダーをブロックしたり転送したりするようにOracle Traffic Directorを設定できます。

HTTPリクエスト・ヘッダーをオリジン・サーバーに転送する際、Oracle Traffic Directorは大文字小文字の区別を維持できません。

16.3.23 Oracle Traffic Directorから405ステータス・コードが返されるのはなぜですか。

HTTPリクエストが定義済ルートに指定されている条件に一致せず、構成にデフォルト(=unconditional)のルートが含まれていない場合、Oracle Traffic Directorから405ステータス・コードが返されます。このエラーはOracle Traffic Directorがリクエストの適切なルートを見つけられなかったことを意味しています。この状況は、obj.conf構成ファイル内でデフォルト・ルート(リクエストが他のどのルートの指定条件にも一致しなかった場合に使用されるルート)が手動で削除された場合にのみ発生する可能性があります。この問題を解決するには、管理者が適切なルートを作成する必要があります。

注意:
デフォルトのルート(=unconditional)は、Fusion Middleware ControlやWLSTでは削除できず、また、手動では削除しないでください。

16.4 Oracleサポートへの連絡

オラクル社とサービス契約を結んでいる場合、Oracle Traffic Directorの問題について、Oracleサポート(http://support.)に問合せできます。

Oracleサポートに連絡する前に

Oracleサポートに連絡する前に、次のことを行ってください:

- このドキュメント(Oracle Traffic Director管理者ガイド)に記載されている適切な診断およびトラブルシューティングのガイドラインをすべて試してください。

- 発生している問題、または類似する問題が、OTNのディスカッション・フォーラム(http://forums./)ですでに話し合われていないかどうか確認してください。
フォーラムで参照できる情報だけでは問題を解決できない場合は、フォーラムに質問を投稿します。フォーラムの他のOracle Traffic Directorユーザーが質問に答えてくれる場合があります。

- 可能な限り、問題が発生する前に実行した一連の操作を記述してください。

- 可能な場合、システムの元の状態をリストアし、記述した手順を使用して問題の再現を試みてください。再現可能な問題か、間欠的に起こる問題かが、これで確認できます。

- 問題を再現できる場合は、問題を再現する手順の絞込みを行います。小規模なテスト・ケースで再現できる問題は、大規模なテスト・ケースと比較すると一般的に診断が容易です。
問題を再現する手順の絞込みによって、Oracleサポートは可能性のある問題の解決策をより迅速に提供できます。

Oracleサポートに提供する必要がある情報

Oracleサポートに連絡する際には、次の情報を提供してください。

- Oracle Traffic Directorのリリース番号。

- 問題が発生する直前に実行した操作など、問題についての簡単な説明。

- 管理インタフェースを使用したサポートが必要な場合、ヘルプを必要とするコマンドライン・サブコマンドの名前、またはFusion Middleware Control画面のタイトル。

- エラーが発生した構成の構成ファイルが含まれるZipファイル。

INSTANCE_HOME/admin-server/config-store/config_name/current.zip

- エラーのない構成の構成ファイルが含まれるZipファイル。

INSTANCE_HOME/admin-server/config-store/config_name/backup/date_time.zip

- 最新のサーバーおよびアクセス・ログ・ファイル。

注意:
Oracleサポートにファイルを送る場合、Oracleサポートの担当者が、問題のトラブルシューティングにファイルを使用する前にその整合性を確認できるように、各ファイルにMD5チェックサム値を指定するようにしてください。

A Oracle Traffic Directorで追跡されるメトリック

この付録では、Oracle Traffic Directorが統計を追跡および維持するために使用するメトリックをリストします。

- インスタンス・メトリック

- プロセス・メトリック

- 接続キュー・メトリック

- スレッド・プール・メトリック

- DNSキャッシュ・メトリック

- キープ・アライブ・メトリック

- スレッド・メトリック

- 圧縮および解凍メトリック

- 仮想サーバー・メトリック

- CPUメトリック

- オリジン・サーバー・メトリック

- フェイルオーバー・インスタンス・メトリック

- キャッシュ・メトリック

- DMSメトリック表

A.1 インスタンス・メトリック

この項では、Oracle Traffic Directorが追跡する、サーバー・インスタンスのメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。SNMPまたはstats-xmlレポートで提供されないメトリックは、NAとマークされます。

表A-1 インスタンス・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

インスタンス識別子

該当なし

server: id

インスタンスのソフトウェア・バージョン。例: Oracle Traffic Director 12.2.1.0.0 B10/11/2014 21:29 (Linux)

該当なし

server: version

インスタンスの開始時間

該当なし

server: timeStarted

インスタンスが実行されている秒数

instanceUptime

server: secondsRunning

インスタンスの一部となるプロセスの最大数

該当なし

server: maxProcs

各インスタンス内のワーカー・スレッドの最大数

該当なし

server: maxThreads

プロファイリング・フラグ

該当なし

server: flagProfilingEnabled

過去1分間の平均ロード

instanceLoad1MinuteAverage

server: load1MinuteAverage

過去5分間の平均ロード

instanceLoad5MinuteAverage

server: load5MinuteAverage

過去 分間の平均ロード

instanceLoad15MinuteAverage

server: load15MinuteAverage

受信したオクテットの数

instanceInOctets

server: countBytesReceived

送信したオクテットの数

instanceOutOctets

server: countBytesTransmitted

過去1分間に処理された平均リクエスト数

instanceRequests1MinuteAverage

server: requests1MinuteAverage

過去5分間に処理された平均リクエスト数

instanceRequests5MinuteAverage

server: requests5MinuteAverage

過去15分間に処理された平均リクエスト数

instanceRequests15MinuteAverage

server: requests15MinuteAverage

過去1分間の平均エラー・レスポンス数

instanceErrors1MinuteAverage

server: errors1MinuteAverage

過去5分間の平均エラー・レスポンス数

instanceErrors5MinuteAverage

server: errors5MinuteAverage

過去15分間の平均エラー・レスポンス数

instanceErrors15MinuteAverage

server: errors15MinuteAverage

過去1分間のリクエストの平均レスポンス時間

instanceResponseTime1MinuteAverage

server: responseTime1MinuteAverage

過去5分間のリクエストの平均レスポンス時間

instanceResponseTime5MinuteAverage

server: responseTime5MinuteAverage

過去15分間のリクエストの平均レスポンス時間

instanceResponseTime15MinuteAverage

server: responseTime15MinuteAverage

ネットワーク上で送信した1秒当たりのオクテット数

instanceNetworkInOctets

該当なし

ネットワーク上で受信した1秒当たりのオクテット数

instanceNetworkOutOctets

該当なし

A.2 プロセス・メトリック

この項では、プロセス・レベルでOracle Traffic Directorが追跡するメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。SNMPまたはstats-xmlレポートで提供されないメトリックは、NAとマークされます。

表A-2 プロセス・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

プロセス識別子

processId

process: pid

プロセス・アクティビティ・モード

該当なし

process: mode

プロセス開始時間

該当なし

process: timeStarted

構成がロードされた回数

該当なし

process: countConfigurations

現在使用可能なリクエスト処理スレッドの数

processCountThreads

process: countThreads

現在アイドル状態のリクエスト処理スレッドの数

processIdleThreads

process: idleThreads

プロセス・サイズ(KB)

processSizeVirtual

process: sizeVirtual

プロセス常駐サイズ(KB)

processSizeResident

process: sizeResident

システム・メモリー内のプロセス・メモリー部分

processFractionSystemMemoryUsage

process: fractionSystemMemoryUsage

A.3 接続キュー・メトリック

この項では、Oracle Traffic Directorが追跡する接続キュー・メトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。SNMPまたはstats-xmlレポートで提供されないメトリックは、NAとマークされます。

表A-3 接続キュー・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

接続キュー識別子

connectionQueueId

connection-queue: connectionQueueId

インスタンスの起動後この接続キューに追加された接続合計数

connectionQueueTotal

connection-queue: countTotalConnections

接続キューに現在入っている接続数

connectionQueueCount

connection-queue: countQueued

キューに同時に存在できる最大接続数

connectionQueuePeak

connection-queue: peakQueued

接続キューに許可されている最大接続数

connectionQueueMax

connection-queue: maxQueued

接続キューのオーバーフローのため拒否された接続数

connectionQueueOverflows

connection-queue: countOverflows

起動後この接続キューに追加されている接続合計数

connectionQueueTotalQueued

connection-queue: countTotalQueued

このキューの接続にかかるチック数合計

connectionQueueTimeQueued

connection-queue: ticksTotalQueued

過去1分間のキューの平均長

connectionQueue1MinuteAverage

connection-queue: countQueued1MinuteAverage

過去5分間のキューの平均長

connectionQueue5MinuteAverage

connection-queue: countQueued5MinuteAverage

過去15分間のキューの平均長

connectionQueue15MinuteAverage

connection-queue: countQueued15MinuteAverage

A.4 スレッド・プール・メトリック

この項では、サーバー・スレッドについてOracle Traffic Directorが追跡するメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

表A-4 スレッド・プール・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

Thread pool ID。これは、ID属性がこの属性に一致するサーバー要素の下のスレッド・プールを参照します

threadPoolId

thread-pool: threadPoolId

統計の収集時にアイドルだったこのプール内のスレッド数

該当なし

thread-pool: countIdleThreads

統計の収集時のこのプール内のスレッド数

threadPoolCount

thread-pool: countThreads

キューに許可されている最大リクエスト数

threadPoolMax

thread-pool: maxThreads

このスレッド・プールで処理するためにキューに入っているリクエスト数

threadPoolCount

thread-pool: countQueued

キューに同時に存在できる最大リクエスト数

threadPoolPeak

thread-pool: peakQueued

キューに存在できる最大リクエスト数

threadPoolMax

thread-pool: maxQueued

A.5 DNSキャッシュ・メトリック

この項では、Oracle Traffic Directorが追跡するDNSキャッシュ参照メトリックをリストします。各メトリックについて、stats-xmlレポート内の要素および属性が提供されます。

表A-5 DNSキャッシュ・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

DNSキャッシュが有効かどうかを示します

dnsCacheEnabled

dns: flagCacheEnabled

キャッシュ内のエントリの合計数

dnsCountCacheEntries

dns: countCacheEntries

DNSキャッシュ内のエントリの最大数

dnsMaxCacheEntries

dns: maxCacheEntries

キャッシュ参照が成功した合計回数

dnsCountCacheHits

dns: countCacheHits

キャッシュ参照が失敗した合計回数

dnsCountCacheMisses

dns: countCacheMisses

非同期DNSルックアップが有効かどうかを示します

dnsAsyncEnabled

dns: flagAsyncEnabled

非同期参照数

dnsCountAsyncNameLookups

dns: countAsyncNameLookups

非同期DNSアドレス参照が実行された合計数

dnsCountAsyncAddrLookups

dns: countAsyncAddrLookups

現在進行中の非同期DNS参照数

dnsCountAsyncLookupsInProgress

dns: countAsyncLookupsInProgress

A.6 キープ・アライブ・メトリック

この項では、Oracle Traffic Directorが追跡する、プロセス内のキープ・アライブ・サブシステムに関連するメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。SNMPまたはstats-xmlレポートで提供されないメトリックは、NAとマークされます。

表A.6 キープ・アライブ・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

キープ・アライブ・サブシステムに追加された接続の総数

keepaliveCountConnections

keepalive: countConnections

キープ・アライブ・サブシステム内に保持できる接続の最大数

keepaliveMaxConnections

keepalive: maxConnections

キープ・アライブ・サブシステム内の接続で処理されたリクエスト数

keepaliveCountHits

keepalive: countHits

キープ・アライブ・サブシステム内のフラッシュされた接続数

keepaliveCountFlushes

keepalive: countFlushes

最大接続制限に達したために接続がキープ・アライブ・サブシステムに入力できなかった回数

keepaliveCountRefusals

keepalive: countRefusals

アイドル・タイムアウトのためにクローズされた接続の数

keepaliveCountTimeouts

keepalive: countTimeouts

キープ・アライブ・サブシステムのアイドル・タイムアウトの値

keepaliveSecondsTimeout

keepalive: secondsTimeout

A.7 スレッド・メトリック

この項では、Oracle Traffic Directorが追跡する、サーバー・プロセス内の特定のワーカー・スレッドのメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。SNMPまたはstats-xmlレポートで提供されないメトリックは、NAとマークされます。

表A-7 スレッド・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

統計収集時のスレッドのアクティビティ・モード

該当なし

thread: mode

スレッドの実行開始時刻。

該当なし

thread: timeStarted

統計収集時にそのスレッドが実行されていたSAF。

該当なし

thread: function

このワーカー・スレッドがそこからリクエストを選択する接続キューのID。

該当なし

thread: connectionQueueId

統計収集時にスレッドがそのためにリクエストを処理していた仮想サーバー。

該当なし

thread: virtualServerId

統計収集時にスレッドがそのためにリクエストを処理していたクライアントのIPアドレス。

該当なし

thread: clientAddress

スレッドが現在のリクエストの実行を開始した時刻。

該当なし

thread: timeRequestStarted

プロキシ・リトリーブ中のスレッドの現在の状態。

該当なし

thread: proxyMode

現在のリクエストを処理しているオリジン・サーバー。

該当なし

thread: originServer

A.8 圧縮および解凍メトリック

この項では、Oracle Traffic Directorが圧縮および解凍するレスポンス・データのメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

表A-8 圧縮および解凍メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

圧縮されたリクエスト合計数

compressionCountRequests

compression: countRequests

圧縮対象の入力バイトの合計数

compressionBytesInput

compression: bytesInput

圧縮後の出力バイトの合計数

compressionBytesOutput

compression: bytesOutput

リクエスト当たりの平均圧縮率

compressionRatioAverage

compression: compressionRatioAverage

全体の圧縮率

compressionRatio

compression: compressionRatio

解凍されたリクエスト合計数

decompressionCountRequests

decompression: countRequests

解凍対象の入力バイトの合計数

decompressionBytesInput

decompression: bytesInput

解凍後の出力バイトの合計数

decompressionBytesOutput

decompression: bytesOutput

A.9 仮想サーバー・メトリック

この項では、各仮想サーバーについてOracle Traffic Directorが追跡するメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

virtual-serverセクションには、次の子要素が含まれます。

- request-bucket: リクエストに関連する統計が含まれます。

- websocket: WebSocket接続の統計が含まれます。

- webapp-firewall: Webアプリケーション・ファイアウォールによって処理されるリクエストの統計が含まれます。

- profile-bucket: 仮想サーバーによって処理されるリクエストのパフォーマンス・プロファイル・バケットに関連する統計が含まれます。

- route: ルートに関連する統計が含まれます。

表A-9 仮想サーバー・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

仮想サーバー識別子。例: www.charity.org my-vsid

vsId

virtual-server: id

仮想サーバーが有効かどうかを示すフラグ

vsEnabled

virtual-server: flagEnabled

この仮想サーバーが処理しているリクエストのホスト。

vsHosts

virtual-server: host

この仮想サーバーがリクエストをリスニングしている、ポートを含むIPアドレス

vsListeners

virtual-server: listenAddresses

処理されたリクエストの数

vsRequests

request-bucket: countRequests

受信したオクテットの数

vsInOctets

request-bucket: countBytesReceived

送信したオクテットの数

vsOutOctets

request-bucket: countBytesTransmitted

発行された2xx (成功)レスポンスの数

vsCount2xx

request-bucket: count2xx

発行された3xx (リダイレクト)レスポンスの数

vsCount3xx

request-bucket: count3xx

発行された4xx (クライアント・エラー)レスポンスの数

vsCount4xx

request-bucket: count4xx

発行された5xx (サーバー・エラー)レスポンスの数

vsCount5xx

request-bucket: count5xx

発行されたその他(2xx、3xx、4xx、5xx以外)のレスポンスの数

vsCountOther

request-bucket: countOther

発行された200 (OK)レスポンスの数

vsCount200

request-bucket: count200

発行された302 (一時的に移動)レスポンスの数

vsCount302

request-bucket: count302

発行された304 (変更なし)レスポンスの数

vsCount304

request-bucket: count304

発行された400 (不正なリクエスト)レスポンスの数

vsCount400

request-bucket: count400

発行された401 (認可されていない)レスポンスの数

vsCount401

request-bucket: count401

発行された403 (禁止)レスポンスの数

vsCount403

request-bucket: count403

発行された404 (未検出)レスポンスの数

vsCount404

request-bucket: count404

発行された503 (使用不可)レスポンスの数

vsCount503

request-bucket: count503

処理されたアップグレード・リクエストの合計数

websocketCountUpgradedRequests

websocket:countUpgradeRequests

オリジン・サーバーでアップグレードが拒否されたWebSocketリクエストの数

websocketCountUpgradeRejectedRequests

websocket:countUpgradeRequestsRejected

サーバーでアップグレードが拒否されたWebSocketリクエストの数

websocketCountFailedStrictRequests

websocket:countUpgradeRequestsFailed

中断されたリクエストの合計数

websocketCountAbortedRequests

websocket:countRequestsAborted

タイムアウトによりクローズされたリクエストの合計数

websocketCountTimeoutRequests

websocket:countRequestsTimedout

クライアントから受信したバイト数

websocketCountBytesReceived

websocket:countBytesReceived

クライアントに送信されたバイト数

websocketCountBytesTransmitted

websocket:countBytesTransmitted

アクティブなWebSocket接続の数

websocketCountActiveConnections

websocket:countActiveConnections

アクティブ時間の平均時間(ミリ秒)

websocketMillisecondsConnectionActiveAverage

websocket:millisecondsConnectionActiveAverage

webappファイアウォールによって遮断されたリクエストの合計数

wafCountInterceptedRequests

webapp-firewall:countRequestsIntercepted

webappファイアウォールによって許可されたリクエストの合計数(allowアクション)

wafCountAllowedRequests

webapp-firewall:countRequestsAllowed

拒否されたリクエストの合計数(denyアクション)

wafCountDeniedRequests

webapp-firewall:countRequestsDenied

ドロップされたリクエストの合計数(dropアクション)

wafCountDroppedRequests

webapp-firewall:countRequestsDropped

リダイレクトされたリクエストの合計数(redirectアクション)

wafCountRedirectedRequests

webapp-firewall:countRequestsRedirected

拒否されたリクエストの合計検出数(denyアクション)

wafCountDenyDetectedRequests

webapp-firewall:countRequestsDenyDetected

ドロップされたリクエストの合計検出数(dropアクション)

wafCountDropDetectedRequests

webapp-firewall:countRequestsDropDetected

リダイレクトされたリクエストの合計検出数(redirectアクション)

wafCountRedirectDetectedRequests

webapp-firewall:countRequestsRedirectDetected

プロファイル・バケットの名前。これは、この要素によって統計が提供されているプロファイル・バケットを識別します。

該当なし

profile-bucket:profile

このバケットにプロファイルされたSAF関数呼出しの数

該当なし

profile-bucket:countCalls

SAF呼出しがプロファイルされたリクエストの数

該当なし

profile-bucket:countRequests

関数呼出しの外で費やされたティック数。つまり、呼出しのディスパッチに要した時間。

該当なし

profile-bucket:ticksDispatch

関数呼出しの中で費やされたティック数

該当なし

profile-bucket:ticksFunctions

ルート識別子

routeName

route:routeId

このルートがアクティブ化される原因となった条件式

routeCondition

route:condition

A.10 CPUメトリック

この項では、Oracle Traffic Directorが追跡するCPU関連のメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

表A-10 CPUメトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

CPU識別子

cpuId

cpu-info: cpuId

CPUがアイドル状態の時間の割合

cpuPercentIdle

cpu-info: cpuPercentIdle

CPUがユーザー空間で費やした時間の割合

cpuPercentUser

cpu-info: cpuPercentUser

CPUがカーネル空間で費やした時間の割合

cpuPercentKernal

cpu-info: cpuPercentKernel

A.11 オリジン・サーバー・メトリック

この項では、オリジン・サーバー・プールおよびオリジン・サーバーについてOracle Traffic Directorが追跡するメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

origin-server-poolセクションには、次の子要素が含まれます。

- origin-server: オリジン・サーバーに関連する統計が提供されます。

- service-queue: オリジン・サーバー・プール内で処理を待っているリクエストの統計が提供されます。

表A-11 オリジン・サーバー・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

server.xmlで指定されているサーバー・プールの名前

originServerPoolName

origin-server-pool: name

リクエストが再試行された回数(同じまたは異なるオリジン・サーバーに対して)

originServerPoolCountRetries

origin-server-pool: countRetries

サーバー・プールのタイプ(tcp、http)。

originServerPoolType

origin-server-pool:type

サーバー・プールのタイプ(tcp、http)。

originServerName

origin-server: name

オリジン・サーバーが現在オンラインとマークされているかどうかを示すフラグ

originServerStatus

origin-server: flagOnline

オリジン・サーバーがバックアップ・ノードであるかどうかを示すフラグ

originServerBackupStatus

origin-server: flagBackup

オリジン・サーバーがオンラインとマークされてからの合計時間(秒)

originServerTimeOnline

origin-server: secondsOnline

オリジン・サーバーがオフラインとマークされてからの合計時間(秒)

originServerCountDetectedOffline

origin-server: countDetectedOffline

オリジン・サーバーに送信された合計バイト数

originServerCountBytesTransmitted

origin-server: countBytesTransmitted

オリジン・サーバーから受信した合計バイト数

originServerCountBytesReceived

origin-server: countBytesReceived

リクエストを処理中のオリジン・サーバーへのオープン接続合計数

originServerCountActiveConnections

origin-server: countActiveConnections

クローズしている接続の合計数

originServerCountConnectionsClosed

origin-server: countConnectionsClosed

オリジン・サーバーへの接続が試行された合計回数

originServerCountConnectAttempts

origin-server: countConnectAttempts

オリジン・サーバーへの接続の試行が失敗した合計回数

originServerCountConnectFailures

origin-server: countConnectFailures

このオリジン・サーバーについてリクエストをプロキシする際、中断されたリクエストの合計数

originServerCountRequestsAborted

origin-server: countRequestsAborted

オリジン・サーバーとデータを送受信する際、リクエストがタイムアウトになった合計回数

originServerCountRequestsTimedout

origin-server: countRequestsTimedout

オリジン・サーバーによって処理された合計リクエスト数

originServerCountRequests

origin-server: countRequests

ヘルス・チェック・リクエストの合計数

originServerCountHealthCheckRequests

origin-server: countHealthCheckRequests

ノードが動的に検出されたかどうかを示すフラグ

originServerDiscoveredStatus

origin-server: flagDiscovered

ノードが完全にランプアップされているかどうかを示すフラグ

originServerRampedupStatus

origin-server: flagRampedUp

オリジン・サーバーのタイプ(汎用/weblogic/未検出)

originServerType

origin-server: type

オリジン・サーバーへのアイドル状態の接続合計数

originServerCountIdleConnections

origin-server: countIdleConnections

時間統計の収集時に固定性リクエストに属していたアクティブ接続の合計数

originServerCountActiveStickyConnections

origin-server: countActiveStickyConnections

オリジン・サーバーによってクローズされたキープ・アライブ接続の合計数

originServerCountConnectionsClosedByOriginServer

origin-server: countConnectionsClosedByOriginServer

固定性リクエストの合計数

originServerCountStickyRequests

origin-server: countStickyRequests

レスポンス時間に基づいて検出された動的重み(アルゴリズムがleast-response-timeの場合のみ該当)

originServerWeightResponseTime

origin-server: weightResponseTime

動的に計算されたオリジン・サーバーのキープ・アライブ・タイムアウト値

originServerSecondsKeepAliveTimeout

origin-server: secondsKeepAliveTimeout

アクティブ時間の平均時間(ミリ秒)

originServerMillisecondsConnectionActiveAverage

origin-server: millisecondsConnectionActiveAverage

キュー内の現在のリクエストの数

serviceQueueCountQueued

service-queue: countQueued

高優先度キュー内の現在のリクエストの数

serviceQueueCountQueuedHighPriority

service-queue: countQueuedHighPriority

通常優先度キュー内の現在のリクエストの数

serviceQueueCountQueuedNormalPriority

service-queue: countQueuedNormalPriority

低優先度キュー内の現在のリクエストの数

serviceQueueCountQueuedLowPriority

service-queue: countQueuedLowPriority

処理の待機中にタイムアウトしたリクエストの合計数

serviceQueueCountQueuedTimedout

service-queue: countQueuedTimedout

キューに追加されたリクエストの合計数

serviceQueueCountTotalQueued

service-queue: countTotalQueued

高優先度キューに追加されたリクエストの合計数

serviceQueueCountTotalQueuedHighPriority

service-queue: countTotalQueuedHighPriority

通常優先度キューに追加されたリクエストの合計数

serviceQueueCountTotalQueuedNormalPriority

service-queue: countTotalQueuedNormalPriority

低優先度キューに追加されたリクエストの合計数

serviceQueueCountTotalQueuedLowPriority

service-queue: countTotalQueuedLowPriority

キューに追加されたスティッキ・リクエストの合計数

serviceQueueCountTotalQueuedSticky

service-queue: countTotalQueuedSticky

固定性のタイムアウトにより非スティッキに変換されたスティッキ・リクエストの合計数

serviceQueueCountTotalStickyToNonSticky

service-queue: countTotalStickyToNonSticky

高優先度のリクエストがキューにある平均期間(ミリ秒)

serviceQueueMilliSecondsHighPriorityAverage

service-queue: millisecondsQueuedHighPriorityAverage

通常優先度のリクエストがキューにある平均期間(ミリ秒)

serviceQueueMilliSecondsNormalPriorityAverage

service-queue: millisecondsQueuedNormalPriorityAverage

低優先度のリクエストがキューにある平均期間(ミリ秒)

serviceQueueMilliSecondsLowPriorityAverage

service-queue: millisecondsQueuedLowPriorityAverage

A.12 フェイルオーバー・インスタンス・メトリック

この項では、サービス・インスタンスの各VIPのメトリックをリストします。これらのメトリックは、フェイルオーバー・グループでどのノードがプライマリとして構成され、どのノードがバックアップとして構成されているかに加えて、フェイルオーバー・インスタンスの現在の状態を表示します。

表A-12 フェイルオーバー・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

このフェイルオーバー・インスタンスの実際の現在の状態。整数(アクティブの場合1、アクティブでない場合0)。

failoverFlagActive

failover: flagActive

バックアップとして構成されるノードの名前

failoverBackupInstance

failover: backupInstance

プライマリとして構成されるノードの名前

failoverPrimaryInstance

failover: primaryInstance

フェイルオーバー・グループの仮想IPアドレス

failoverVirtualIp

failover: virtualIp

A.13 キャッシュ・メトリック

この項では、Oracle Traffic Directorが追跡する、リバース・プロキシのキャッシュ・メトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

表A-13 キャッシュ・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

キャッシュが有効かどうかを示すフラグ

cacheEnabled

cache: flagEnabled

キャッシュ内のエントリの合計数

cacheCountEntries

cache: countEntries

キャッシュ・コンテンツによって使用されるヒープ領域の量

cacheSizeHeap

cache: sizeHeapCache

キャッシュ参照が成功した合計回数

cacheCountContentHits

cache: countContentHits

キャッシュ参照が失敗した合計回数

cacheCountContentMisses

cache: countContentMisses

エントリがキャッシュから提供された合計回数

cacheCountHits

cache-bucket: countHits

オリジン・サーバーから再検証された合計リクエスト数

cacheCountRevalidationRequests

cache: countRevalidationRequests

リクエストの再検証が失敗した合計回数

cacheCountRevalidationFailures

cache: countRevalidationFailures

A.14 DMSメトリック表

この項では、Oracle Dynamic Monitoring Service (DMS)に公開されるOracle Traffic Directorのメトリック表をリストします。

表A-14に、OTD_Instanceメトリック表のためのDMSメトリックを示します。

キー列は、instanceNameです。

表A-14 DMSメトリック: OTD_Instanceメトリック表

列名

タイプ

instanceName

文字列

configName

文字列

instanceVersion

文字列

timeStarted

long

secondsRunning

long

ticksPerSecond

long

maxProcs

long

maxThreads

long

flagProfilingEnabled

boolean

countRequests

long

countBytesReceived

long

countBytesTransmitted

long

countOpenConnections

long

count2xx

long

count3xx

long

count4xx

long

count5xx

long

countOther

long

count200

long

count302

long

count304

long

count400

long

count401

long

count403

long

count404

long

count503

long

load1MinuteAverage

double

load5MinuteAverage

double

load15MinuteAverage

double

inOctets

long

outOctets

long

req1MinuteAverage

double

req5MinuteAverage

double

req15MinuteAverage

double

err1MinuteAverage

double

err5MinuteAverage

double

err15MinuteAverage

double

responseTime1Minute

double

responseTime5Minute

double

responseTime15Minute

double

表A-15に、OTD_Processメトリック表のためのDMSメトリックを示します。

キー列は、(instanceName、processId)です。

表A-15 DMSメトリック: OTD_Processメトリック表

列名

タイプ

instanceName

文字列

processId

long

configName

文字列

countThreads

long

idleThreads

long

sizeVirtual

long

sizeResident

long

fractionSystemMemoryUsage

double

compression.countRequests

long

compression.bytesInput

long

compression.bytesOutput

long

compression.ratioAverage

double

compression.ratio

double

decompression.countRequests

long

decompression.bytesInput

long

decompression.bytesOutput

long

keepalive.countConnections

long

keepalive.maxConnections

long

keepalive.countHits

long

keepalive.countFlushes

long

keepalive.countRefusals

long

keepalive.countTimeouts

long

keepalive.secondsTimeout

long

connectionQueue.connectionQueueId

文字列

connectionQueue.connectionQueueCount

long

connectionQueue.connectionQueuePeak

long

connectionQueue.connectionQueueMax

long

connectionQueue.connectionQueueTotal

long

connectionQueue.connectionQueueTicksTotal

long

connectionQueue.connectionQueueOverflows

long

connectionQueue.connectionQueue1MinuteAverage

double

connectionQueue.connectionQueue5MinuteAverage

double

connectionQueue.connectionQueue15MinuteAverage

double

dns.flagCacheEnabled

boolean

dns.countCacheEntries

long

dns.maxCacheEntries

long

dns.countCacheHits

long

dns.countCacheMisses

boolean

dns.flagAsyncEnabled

long

dns.countAsyncNameLookups

long

dns.countAsyncAddrLookups

long

dns.countAsyncLookupsInProgress

long

threadPool.threadPoolId

文字列

threadPool.countIdleThreads

long

threadPool.countThreads

long

threadPool.countQueued

long

threadPool.maxQueued

long

threadPool.maxThreads

long

threadPool.peakQueued

long

表A-16に、OTD_Cacheメトリック表のためのDMSメトリックを示します。

キー列は、(instanceName)です。

表A-16 DMSメトリック: OTD_Cacheメトリック表

列名

タイプ

instanceName

文字列

configName

文字列

flagEnabled

boolean

countEntries

long

sizeHeapCache

long

countContentHits

long

countContentMisses

long

countHits

long

countRevalidationRequests

long

countRevalidationFailures

long

表A-17に、OTD_VirtualServerメトリック表のためのDMSメトリックを示します。

キー列は、(instanceName、vsName)です。

表A-17 DMSメトリック: OTD_VirtualServerメトリック表

列名

タイプ

instanceName

文字列

vsName

文字列

configName

文字列

flagEnabled

boolean

listeners

文字列

hosts

文字列

countRequests

long

countBytesReceived

long

countBytesTransmitted

long

countOpenConnections

long

count2xx

long

count3xx

long

count4xx

long

count5xx

long

countOther

long

count200

long

count302

long

count304

long

count400

long

count401

long

count403

long

count404

long

count503

long

waf.countRequestsIntercepted

long

waf.countAllowedRequests

long

waf.countRequestsDenied

long

waf.countRequestsDropped

long

waf.countRequestsRedirected

long

waf.countRequestsDenyDetected

long

waf.countRequestsDropDetected

long

waf.countRequestsRedirectDetected

long

websocket.countUpgradeRequests

long

websocket.countUpgradeRequestsRejected

long

websocket.countUpgradeRequestsFailed

long

websocket.countRequestsAborted

long

websocket.countRequestsTimedout

long

websocket.countBytesReceived

long

websocket.countBytesTransmitted

long

websocket.countActiveConnections

long

websocket.millisecondsConnectionActiveAverage

double

表A-18に、OTD_Routeメトリック表のためのDMSメトリックを示します。

キー列は、(instanceName、vsName、routeName)です

表A-18 DMSメトリック: OTD_Routeメトリック表

列名

タイプ

instanceName

文字列

vsName

文字列

routeName

文字列

condition

文字列

configName

文字列

countRequests

long

countBytesReceived

long

countBytesTransmitted

long

countOpenConnections

long

count2xx

long

count3xx

long

count4xx

long

count5xx

long

countOther

long

count200

long

count302

long

count304

long

count400

long

count401

long

count403

long

count404

long

count503

long

表A-19に、OTD_OriginServerPoolメトリック表のためのDMSメトリックを示します。

キー列は、(instanceName、serverPoolName)です

表A-19 DMSメトリック: OTD_OriginServerPoolメトリック表

列名

タイプ

instanceName

文字列

serverPoolName

文字列

configName

文字列

serverPoolType

文字列

countRetries

文字列

serviceQueue.countQueued

long

serviceQueue.countQueuedHighPriority

long

serviceQueue.countQueuedLowPriority

long

serviceQueue.countQueuedNormalPriority

long

serviceQueue.countQueuedTimedout

long

serviceQueue.countTotalQueued

long

serviceQueue.countTotalQueuedHighPriority

long

serviceQueue.countTotalQueuedLowPriority

long

serviceQueue.countTotalQueuedNormalPriority

long

serviceQueue.countTotalQueuedSticky

long

serviceQueue.countTotalStickyToNonSticky

long

serviceQueue.millisecondsQueuedHighPriorityAverage

double

serviceQueue.millisecondsQueuedLowPriorityAverage

double

serviceQueue.millisecondsQueuedNormalPriorityAverage

double

表A-20に、OTD_OriginServerメトリック表のためのDMSメトリックを示します。

キー列は、(instanceName、serverPoolName、originServerName)です

表A-20 DMSメトリック: OTD_OriginServerメトリック表

列名

タイプ

instanceName

文字列

serverPoolName

文字列

originServerName

文字列

configName

文字列

type

文字列

status

文字列

discovered

boolean

rampedup

boolean

backup

boolean

secondsOnline

long

countDetectedOffline

long

countBytesTransmitted

long

countBytesReceived

long

countActiveConnections

long

countIdleConnections

long

countActiveStickyConnections

long

countConnectionsClosed

long

countConnectionsClosedByOriginServer

long

countConnectAttempts

long

countConnectFailures

long

countRequestsAborted

long

countRequestsTimedout

long

countRequests

long

countHealthCheckRequests

long

countStickyRequests

long

weightResponseTime

double

secondsKeepAliveTimeout

long

websocket.countUpgradeRequests

long

websocket.countUpgradeRequestsRejected

long

websocket.countUpgradeRequestsFailed

long

websocket.countRequestsAborted

long

websocket.countRequestsTimedout

long

websocket.countBytesReceived

long

websocket.countBytesTransmitted

long

websocket.countActiveConnections

long

websocket.millisecondsConnectionActiveAverage

double

表A-21に、OTD_TcpOriginServerメトリック表のためのDMSメトリックを示します。

キー列は、(instanceName、serverPoolName、originServerName)です

表A-21 DMSメトリック: OTD_TcpOriginServerメトリック表

列名

タイプ

instanceName

文字列

serverPoolName

文字列

originServerName

文字列

configName

文字列

status

文字列

backup

boolean

secondsOnline

long

countDetectedOffline

long

countBytesTransmitted

long

countBytesReceived

long

countActiveConnections

long

countClosedConnections

long

countConnectAttempts

long

countConnectFailures

long

countRequestsAborted

long

countRequestsTimedout

long

countRequests

long

countHealthCheckRequests

long

millisecondsConnectionActiveAverage

double

表A-22に、OTD_TcpProxyメトリック表のためのDMSメトリックを示します。

キー列は、(instanceName、tcpProxyName)です

表A-22 DMSメトリック: OTD_TcpProxyメトリック表

列名

タイプ

instanceName

文字列

tcpProxyName

文字列

configName

文字列

flagEnabled

boolean

listeners

文字列

countActiveConnections

long

countRequests

long

countRequestsAborted

long

countRequestsTimedout

long

countBytesReceived

long

countBytesTransmitted

long

millisecondsConnectionActiveAverage

文字列

表A-23に、OTD_Listenerメトリック表のためのDMSメトリックを示します。

キー列は、(instanceName、listenerName)です

表A-23 DMSメトリック: OTD_Listenerメトリック表

列名

タイプ

instanceName

文字列

listenerName

文字列

configName

文字列

type

文字列(tcp/http)

addressType

文字列(inet/inet6/inet-sdp)

address

文字列

port

long

sslEnabled

boolean

表A-24に、OTD_Failoverメトリック表のためのDMSメトリックを示します。

キー列は、(virtualIp)です。

表A-24 DMSメトリック: OTD_Failoverメトリック表

列名

タイプ

primaryInstance

文字列

backupInstance

文字列

flagActive

整数

表A-25に、OTD_Partitionメトリック表のためのDMSメトリックを示します。

キー列は、(instanceName、partitionName)です

表A-25 DMSメトリック: OTD_Partitionメトリック表

列名

タイプ

instanceName

文字列

partitionName

文字列

configName

文字列

countRequests

long

countBytesReceived

long

countBytesTransmitted

long

countOpenConnections

long

count2xx

long

count3xx

long

count4xx

long

count5xx

long

countOther

long

count200

long

count302

long

count304

long

count400

long

count401

long

count403

long

count404

long

count503

long

B Webアプリケーション・ファイアウォールの例とユースケース

Webアプリケーション・ファイアウォールの攻撃阻止機能は、クライアントとオリジン・サーバーの間で動作します。悪意のあるペイロードを検出すると、Webアプリケーション・ファイアウォールはそのリクエストを拒否し、組込みのアクションのいずれかを実行します。この項では、Webアプリケーション・ファイアウォールの動作と攻撃阻止に使用されるルールについて、基本的な情報を示します。Webアプリケーション・ファイアウォールの管理および構成の詳細は、第10章「Webアプリケーション・ファイアウォールの管理」の10.5項「Webアプリケーション・ファイアウォールの管理」を参照してください。

Webアプリケーション・ファイアウォールには、監査ロギング、任意のリクエスト(本文など)およびレスポンスの一部へのアクセス、柔軟性の高いルール・エンジン、ファイル・アップロード遮断、リアルタイム検証、バッファ・オーバーフロー保護などの機能があります。

Webアプリケーション・ファイアウォールの機能は主に4つの領域に分類できます。

- 解析: パーサーはリクエストまたはレスポンス(あるいはその両方)のビットを抽出して保存します。これらのビットはルールで使用されます。

- バッファ: 標準的なインストールではリクエスト本文とレスポンス本文の両方がバッファされるため、通常このモジュールはリクエスト(処理を行うアプリケーションに送信される前)とレスポンス(クライアントに送信される前)を完全な形で確認できます。バッファは、信頼性の高い阻止機能を実現するのに最も適した手段です。

- ロギング: ロギングではHTTPトラフィックが完全な形で記録されるため、すべてのレスポンス/リクエストのヘッダーおよび本文をログ記録できます。

- ルール・エンジン: ルール・エンジンは他のコンポーネントからの情報に対して機能し、トランザクションを評価して、必要に応じてアクションを実行します。

B.1 ルールの基本

収集した情報に特定のコンテンツや悪意のあるコンテンツが含まれていないかどうかは、Webアプリケーション・ファイアウォールのルール・エンジンでチェックされます。

この項では、基本的なルール記述構文とWebアプリケーションを攻撃から保護するためのルール・ディレクティブについて説明します。

ルールの作成に使用するメインのディレクティブはSecRuleです。SecRuleの構文は次のとおりです。

SecRule VARIABLES OPERATOR [TRANSFORMATION_FUNCTIONS, ACTIONS]

- VARIABLES: チェックするHTTPトランザクション内の場所を指定します。Webアプリケーション・ファイアウォールによってrawトランザクション・データが前処理されるため、ルールの処理を検知ロジックに限定させることができます。ルールでは1つ以上の変数を指定する必要があります。| 演算子を使用すると、1つの変数で複数のルールを使用できます。

- OPERATORS: 変換された変数の分析方法を指定します。演算子は常に文字@で始まり、次に空白が続きます。1つのルールに指定できる演算子は1つのみです。

- TRANSFORMATION_FUNCTIONS: ルール演算子が実行される前に入力を変更します。ルールでは1つ以上の変換関数を指定できます。

- ACTIONS: ルールがtrueに評価されたときに実行するアクションを指定します。たとえば、エラー・メッセージを表示したり、別のルールに進んだり、別のタスクを実行するなどのアクションです。

次にルールの例を示します。

SecRule ARGS|REQUEST_HEADERS "@rx <script" msg:'XSSAttack',deny,status:404

- ARGSとREQUEST_HEADERSは変数です(リクエスト・パラメータとリクエスト・ヘッダー)。

- @rxは正規表現演算子です。これは変数内のパターンと照合する場合に使用します。
この例では、<scriptがパターンです。

- msg、denyおよびstatusは、パターンが一致したときに実行するアクションです。
この例のルールはXSS攻撃を阻止するためのルールです。リクエストのパラメータおよびヘッダーに<scriptパターンがないかどうかをチェックし、XSS攻撃のログ・メッセージを生成します。404ステータス・レスポンスとともに一致したリクエストは拒否されます。

B.2 主な攻撃に対抗するためのルール

この項では、Webアプリケーションを主な攻撃から保護するためのルールについて説明します。

B.2.1 ブルート・フォース攻撃

ブルート・フォース攻撃は、攻撃者がユーザー名、パスワード、電子メール・アドレスなどの資格証明を推測して、リソースへのアクセスを何度も試みる攻撃です。ブルート・フォース攻撃は防御機能がないシステムに対して非常に高い効力を発揮し、ユーザーが短くて覚えやすいパスワードを使用している場合の効力は顕著です。

ブルート・フォース攻撃を阻止する最も効果的な方法は、ログイン試行回数に制限を設け、制限回数を超えた後のログインを遅延させるかブロックする方法です。次に、Oracle Traffic DirectorのWebアプリケーション・ファイアウォールで、これを実現するための例を示します。

ログイン検証ページがyoursite.com/loginにあり、仮想サーバーwaf-vsによって提供される場合、仮想サーバー・レベルで構成されたwaf-vs.confファイル内の次のルールによって、ユーザーのログイン試行回数を追跡できます。

# Block further login attempts after 3 failed attempts

# Initalize IP collection with user's IP address
SecAction "initcol:ip=%{REMOTE_ADDR},pass,nolog"

# Detect failed login attempts
SecRule RESPONSE_BODY "Unauthorized" "phase:4,pass,setvar:ip.failed_logins=+1,expirevar:ip.failed_logins=60"

# Block subsequent login attempts
SecRule IP:FAILED_LOGINS "@gt 2" deny

このルールは、IPコレクションを初期化し、ログイン試行が失敗するたびIP:FAILED_LOGINSフィールドをインクリメントします。ログイン試行の失敗数が3回を超えると、それ以降の試行はブロックされます。ログイン試行の失敗回数は60秒後にexpirevarアクションによってゼロにリセットされるため、ブロックされる期間は最大で60秒です。

永続コレクションIPを使用する場合は、永続データを保存するパスをSecDataDirディレクティブを使用して指定する必要があります。このディレクティブのスコープはMainです。そのため、サーバー・レベルで指定する必要があります。これは次のようにして行います。

# The name of the debug log file
SecDebugLog ../logs/brute_force_debug_log

# Debug log level
SecDebugLogLevel 3

# Enable audit logging
SecAuditEngine On

# The name of the audit log file
SecAuditLog ../logs/brute_force_audit_log

# Path where persistent data is stored
SecDataDir "/var/run/otd/waf/"

このルール・ファイルがwaf-server.confという名前である場合、<instance-dir>/config/server.xmlは次のようになります。

<server>
...
...
<webapp-firewall-ruleset>/waf-rules/waf-server.conf</webapp-firewall-ruleset>
...
...
<virtual-server>
<name>waf-vs</name>
<host>yoursite.com</host>
...
<object-file>waf-vs-obj.conf</object-file>
<webapp-firewall-ruleset>/waf-rules/waf-vs.conf</webapp-firewall-ruleset>
</virtual-server>
...
...
</server>

Webアプリケーション・ファイアウォールおよびレスポンス本文の処理(SecResponseBodyAccessディレクティブと同等)を、waf-vs-obj.conf内の/login URIに対して有効にする必要があります。waf-vs-obj.confは次のようになります。

<Object name="default">
<If $uri eq "/login">
AuthTrans fn="webapp-firewall" process-response-body="on"
</If>
...
...
</Object>

ログイン試行が3回失敗すると、監査ログに次のメッセージが記録されます。

--5c4adf36-A--
[19/Mar/2013:05:06:57 --0700] ygfh3010000000000,0 127.0.0.1 49619 127.0.0.1 5021
--5c4adf36-B--
GET /acl/acl02.html HTTP/1.1
user-agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
accept: */*
host: yoursite.com
authorization: Basic YWxwaGE6YmV0YQ==

--5c4adf36-F--
HTTP/1.1 403 Forbidden
status: 403 Forbidden
content-length: 208
content-type: text/html

--5c4adf36-H--
Message: Warning. Unconditional match in SecAction. [file "/waf-rules/waf-vs.conf"] [line "10"]
Message: Access denied with code 403 (phase 2). Operator GT matched 2 at IP:failed_logins. [file "/waf-rules/waf-vs.conf"] [line "25"]
Action: Intercepted (phase 2)
Stopwatch: 1363694817000000 898560 (- - -)
Stopwatch2: 1363694817000000 898560; combined=370, p1=14, p2=336, p3=0, p4=0, p5=19, sr=131, sw=1, l=0, gc=0
Producer: ModSecurity for Apache/2.8 (http://www.modsecurity.org/).
Server: Oracle Traffic Director/12.2.1

--5c4adf36-Z--

B.2.2 SQLインジェクション

SQLインジェクション攻撃は攻撃者がWebアプリケーションにデータを送り込むことができる場合に発生し、サニタイズされていない形式のデータがSQL問合せで使用されます。そのため、Webアプリケーション開発者が意図したものとは完全に異なる動作をSQL問合せが実行する恐れがあります。たとえば、MySQL表からすべてのレコードを削除するなどの攻撃を受ける可能性があります。

http://www.example.com/login.php?user=user1';DELETE%20FROM%20users--

これは次のディレクティブを使用することで回避できます。

SecDefaultAction "phase:2,log,auditlog,deny,status:403"
SecRule ARGS "(select|create|rename|truncate|load|alter|delete|update|insert|desc)\s*" "t:lowercase,msg:'SQL Injection'"

Webアプリケーション・ファイアウォール・エンジンがこのようなリクエストを検知すると、次のようなコードがaudit_logに記録されます。

--3923b655-A--
[20/Mar/2013:02:58:35 --0700] Xkjx6010000000000,0 127.0.0.1 35971 127.0.0.1 5021
--3923b655-B--
GET /acl/acl02.html?user=user1';DELETE%20FROM%20users-- HTTP/1.1
host: waf.test.com
connection: close

--3923b655-F--
HTTP/1.1 403 Forbidden
status: 403 Forbidden
content-length: 208
content-type: text/html
connection: close

--3923b655-H--
Message: Access denied with code 403 (phase 2). Pattern match "(select|create|rename|truncate|load|alter|delete|update|insert|desc)\\s*" at ARGS:user. [file "/waf-rules/sql_injection_attack.conf"] [line "2"] [msg "SQL Injection"]
Action: Intercepted (phase 2)
Stopwatch: 1363773515000000 668049 (- - -)
Stopwatch2: 1363773515000000 668049; combined=131, p1=8, p2=104, p3=0, p4=0, p5=19, sr=0, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.8 (http://www.modsecurity.org/).
Server: Oracle Traffic Director/12.2.1

--3923b655-Z--

攻撃を受け、SecDefaultActionが適用されます。この場合、リクエストは拒否されてログに記録され、攻撃者には403エラーが返されます。リクエストをカスタムの警告メッセージを表示するHTMLページにリダイレクトするなど、別のアクションを実行する必要がある場合は、次のように、使用するアクションをルールで指定します。

SecRule ARGS "(select|create|rename|truncate|load|alter|delete|update|insert|desc)\s*" "t:lowercase,msg:'SQL Injection',redirect:http://yoursite.com/invalid_request.html

B.2.3 XSS攻撃

クロスサイト・スクリプティング(XSS)攻撃は、ユーザー入力が適切にサニタイズされずにページがユーザーに戻される攻撃です。そのため、攻撃者が悪意のあるスクリプトをページへの入力としてページに組み込むことが可能になります。このスクリプトはWebサイトの作成者がページに含めたスクリプトと違いがないため、cookieデータやセッションIDの読取り権限など、ページ内の通常のスクリプトと同様の権限を付与されます。

次に、リクエスト・パラメータ内の<scriptをブロックする簡単なルールの例を示します。

SecDefaultAction phase:2,deny,status:403,log,auditlog
SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "(?i:<script.*?>)" "phase:2,capture,t:none,t:htmlEntityDecode,t:compressWhiteSpace,t:lowercase,block,msg:'Cross-site Scripting (XSS) Attack',id:'101'"

C Oracle Traffic Directorデプロイメントの保護

この付録では、Oracle Traffic Directorデプロイメントを保護するための手順について説明します。

Oracle Traffic Director管理サーバーのアクセス保護およびSSL/TLSの有効化に関する情報は、第10章「セキュリティの管理」を参照してください。

C.1 Oracle Traffic Directorの保護

次に、環境内のOracle Traffic Directorを保護するための手順を示します。

- Oracle Traffic Directorサーバー・インスタンスが非rootで実行され、いずれのインスタンスもリスニングしないようにします。Oracle Traffic Directorインスタンスの起動方法の詳細は、4.3項「Oracle Traffic Directorインスタンスの起動、停止および再起動」を参照してください。

注意:
管理ノードでインスタンス化する各Oracle Traffic Director構成について、net-config_nameという名前のサブディレクトリがINSTANCE_HOMEサブディレクトリ内に作成されます。

- Oracle Traffic Directorの機能を高め非rootとしての高可用性を提供します。詳細は、第14章「高可用性のためのOracle Traffic Directorの構成」を参照してください。

- 十分なファイル・ディスクリプタを確保します。詳細は、第15章「ファイル・ディスクリプタ制限のチューニング」の15.2項「ファイル・ディスクリプタ制限のチューニング」を参照してください。

- 適切なネットワーク・レベル保護を確保します。詳細は、http://www./technetwork/articles/servers-storage-admin/secure-linux-env-1841089.htmlを参照してください。
システムの堅牢性を高める方法も検討してください。Oracle Linuxシステムの堅牢性強化の詳細は、http://www./technetwork/articles/servers-storage-admin/tips-harden-oracle-linux-1695888.htmlを参照してください。

D Oracle Fusion Middleware T2P Utility for Oracle Traffic Director

この付録は、Oracle Fusion Middleware T2P utility for Oracle Traffic Directorについて説明し、次の項が含まれています。

- 概要

- T2Pプロセスの概要

- 要件

- T2Pユーティリティの使用方法

- Oracle Traffic Directorの移動計画の抽出およびカスタマイズ

- ロギング

D.1 概要

Oracle Fusion Middleware T2Pユーティリティにより、Oracle Fusion Middleware環境をテストから本番(T2P)に、本番環境に固有のカスタマイズとともに移動できます。この付録では、Oracle Traffic Director環境を移動するためのサポートについて説明します。

Oracle Traffic Directorインストールを移動することで、それをしない場合に、ある環境で実行したすべてのカスタマイズと構成変更を、もう一度別の環境に適用するために必要となる作業を最小限に抑えることができます。テスト環境で、Oracle Traffic Directorのインストール、構成、カスタマイズおよび検証ができます。システムが安定し、必要に応じて機能するようになったら、本番環境を作成しますが、このとき、テスト環境に取り込んだすべての変更内容を再実行するかわりに、サーバーとその構成のコピーをテスト環境から移行することで本番環境を作成できます。既存の本番環境がある場合は、カスタマイズなど、テスト環境のすべての変更内容を本番環境に移動できます。

テスト環境から本番環境へのOracle Traffic Directorインストールの移動では、本番環境がテスト環境と同じオペレーティング・システム上で動作することを前提としています。また、オペレーティング・システムのアーキテクチャが両方の環境で同じである必要があります。たとえば、両方の環境で64ビットのオペレーティング・システムを実行している必要があります。

Fusion Middlewareのテストから本番への詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のテスト環境から本番環境への移動に関する項を参照してください。

D.2 T2Pプロセスの概要

Oracle Fusion Middleware環境のT2Pの移動は、大きくは次の2つの手順から構成されます。

本番システムへのバイナリの移動。

本番システムへの構成の移動。

- バイナリのコピー(Oracleホーム) - これは、Oracle Traffic DirectorがインストールされているOracleホームのアーカイブを作成するプロセスです。

- 構成のコピー - これは、Oracle Traffic Directorのドメイン構成のアーカイブを作成するプロセスです。

- 構成の編集 - これは、Oracle Traffic Directorのドメイン構成のアーカイブを作成するプロセスです。

- バイナリの貼付け(Oracleホーム) - これは、移動先でバイナリを再作成するプロセスです。

- 構成の貼付け - これは、移動先で構成を再作成するプロセスです。

コンポーネントの移動先の構成は、構成のコピー・フェーズで生成される移動計画と呼ばれるドキュメントを使用して、T2Pの移動の間にカスタマイズできます。

D.3 要件

移動先ホストの要件は次のとおりです。

- T2Pスクリプトを実行するため、移動先ホストにJDKが存在する必要があります。

- バイナリ/構成のコピー・フェーズ中に作成されたアーカイブにアクセスできる必要があります。

D.4 T2Pユーティリティの使用方法

次の例は、T2Pユーティリティからコマンドを実行する方法を示しています。

D.4.1 バイナリのコピー(Oracleホーム)

ファイル、ライブラリおよび構成のすべてが含まれるOracleホームのアーカイブを作成するには、copyBinary.shを実行します。バイナリのコピー操作の後で、生成されるjarファイルを本番システムにコピーする必要があります。

次にコマンドの例を示します。

例D-1 バイナリのコピー・コマンド

./copyBinary.sh -javaHome ./oracle_common/jdk/jre -archiveLoc /tmp/mw.jar -sourceOracleHomeLoc /scratch/installers/colocated_otd

D.4.2 構成のコピー

ドメイン構成(Oracle Traffic Director用に拡張済)のアーカイブを作成するには、copyConfig.shを実行します。このコマンドは、ドメイン・ホームに存在するすべてのOTD構成をイントロスペクトします。具体的には、OTD構成ファイルのserver.xmlをイントロスペクトし、server.xmlからhttp-listener、tcp-listener、origin-server-pool、failover-groupなどの要素を抽出します。移動計画を編集することで、これらの要素の値をカスタマイズできます。構成のコピー操作の後で、生成されるjarファイルを本番システムにコピーする必要があります

次にコマンドの例を示します。

例D-2 コロケートOTD用の構成のコピー・コマンド

./copyConfig.sh -javaHome ./oracle_common/jdk/jre -archiveLoc /tmp/otd.jar -sourceDomainLoc /scratch/installers/otd_domain -sourceOracleHomeLoc /scratch/installers/colocated_otd -domainHostName abc1234.example.com -domainPortNum 7010 -domainAdminUserName weblogic -domainAdminPasswordFile /scratch/password.txt

注意:
付録D「構成のコピー」を行うときは、WLS管理サーバーが実行されていることを確認してください。

例D-3 スタンドアロンOTD用の構成のコピー・コマンド

./copyConfig.sh -javaHome ./oracle_common/jdk/jre -archiveLoc /tmp/otd.jar -sourceDomainLoc /scratch/installers/otd_domain -sourceOracleHomeLoc /scratch/installers/colocated_otd

D.4.3 構成の編集

構成を編集するには、移動計画を抽出する必要があり、extractMovePlan.shを実行します。移動計画のカスタマイズの詳細は、「Oracle Traffic Directorの移動計画の抽出およびカスタマイズ」を参照してください。

次にコマンドの例を示します。

例D-4 移動計画の抽出コマンド

./extractMovePlan.sh -javaHome ./oracle_common/jdk/jre -archiveLoc /tmp/otd.jar -planDirLoc /scratch/moveplan/

D.4.4 バイナリの貼付け(Oracleホーム)

移動先でバイナリを再作成するには、pasteBinary.shを実行します。次にコマンドの例を示します。

例D-5 バイナリの貼付けコマンド

./pasteBinary.sh -javaHome ./oracle_common/jdk/jre -archiveLoc /tmp/mw.jar -targetOracleHomeLoc /scratch/installers/cloned_colocated_otd/

D.4.5 構成の貼付け

移動先で構成を再作成するには、pasteConfig.shを実行します。このコマンドは、カスタマイズされた移動計画からカスタムの値を抽出し、移動計画で指定された値で構成を更新して、構成を保存します。

次にコマンドの例を示します。

例D-6 コロケートOTD用の構成の貼付けコマンド

./pasteConfig.sh -javaHome ./oracle_common/jdk/jre -archiveLoc /tmp/otdc.jar -movePlanLocation /scratch/moveplan/moveplan.xml -targetDomainLoc /scratch/installers/cloned_domain -targetOracleHomeLoc /scratch/installers/cloned_colocated_otd/ -domainAdminPasswordFile /scratch/password.txt

例D-7 スタンドアロンOTD用の構成の貼付けコマンド

./pasteConfig.sh -javaHome ./oracle_common/jdk/jre -archiveLoc /tmp/otdc.jar -movePlanLocation /scratch/moveplan/moveplan.xml -targetDomainLoc /scratch/installers/cloned_domain -targetOracleHomeLoc /scratch/installers/cloned_colocated_otd

Oracle Traffic Directorを移動するための追加手順:

- 証明書の再構成: 証明書は、otd_setHttpListenerSslProperties/otd_setTcpListenerSslProperties/otd_setVirtualServerSslPropertiesまたはotd_setOriginServerPoolSslPropertiesを使用して再構成できます。

- OAMの再構成: OTDインスタンス内にWebゲートが構成されており、異なるOAMインスタンスを使用するため、ターゲット環境でOAMを再構成する必要があるというユースケースでは、pasteConfigを行った後で、手動で処理する必要があります。

注意:
ターゲット環境で、OTDインスタンスで構成されているすべてのパスがアクセス可能で、適切なファイル・アクセス権があることを確認してください。たとえば、サーバー・ログ・ファイルのパスです。

WLSTの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください

D.5 Oracle Traffic Directorの移動計画の抽出およびカスタマイズ

Oracle Traffic Directorのserver.xmlには、移動計画を使用してカスタマイズできるいくつかの要素があります。このような要素を次に示します。

表D-1 Oracle Traffic Directorのカスタマイズ要素

要素

編集可能プロパティ

http-listener

ip、portおよびserver-name

tcp-listener

ipおよびport

failover-group

virtual-ip

origin-server-pool

origin-servers

また、ドメインの次のプロパティを変更する必要があります。

- ターゲット・ドメイン用の新しいスキーマを作成し、移動計画内のスキーマ接頭辞を更新します(ドメインが完全なJRFである場合にのみ有効)。

- ノード・マネージャ要素のPassword fileを更新します。そのデフォルト値である</value>を<value>/scratch/T2P/password.txt</value>に変更します。指定するパスワード・ファイルはファイル・システム上に存在している必要があります。

Oracle Traffic Directorの移動計画の例を次に示します。

<movableComponent>
<componentType>OTD</componentType>
<componentName>test</componentName>
<Description>otd component</Description>
<moveDescriptor>
<configGroup>
<type>http-listeners</type>
<configProperty id="http-listener-1">
<configProperty>
<name>Ip</name>
<value>*</value>
<itemMetadata>
<dataType>INTEGER</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>Port</name>
<value>7011</value>
<itemMetadata>
<dataType>INTEGER</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>ServerName</name>
<value>abc1234.example.com</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
</configProperty>
</configGroup>
<configGroup>
<type>tcp-listeners</type>
</configGroup>
<configGroup>
<type>origin-server-pool</type>
<configProperty id="origin-server-pool-1">
<configProperty id="origin-server-1">
<name>origin-server-1</name>
<value>abc1234.example.com:7010</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configProperty id="origin-server-2">
<name>origin-server-2</name>
<value>abc1234.example.com:7015</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
</configProperty>
</configGroup>
<configGroup>
<type>failover</type>
<configProperty id="failover-group-1">
<name>virtual-ip</name>
<value>10.100.10.1</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
</configGroup>
</moveDescriptor>
</movableComponent>
</movableComponent>

D.6 ロギング

T2Pユーティリティにより、コピーおよび貼付けフェーズのログがJavaのtempディレクトリに置かれます(たとえば、/tmp/CLONE<Date Time>.log)。失敗やエラーは、別のCLONE<Date Time>.errorファイルにError Message、CauseおよびActionという形式で記録されます。コマンドライン引数の-logDirLocを使用して、ログ用に別の場所を指定できます。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。