Oracle® Traffic Director

管理者ガイド

11gリリース1 (11.1.1.9)

B66436-05

2016年12月

Oracle Traffic Director管理者ガイド, 11g リリース1 (11.1.1.9)

B66436-05

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

原本著者: Thrupthi N.T.

寄稿者: Isvaran Krishnamurthy、Amit Gupta、Basant Kukreja、Julien Pierre、Hideaki Hayashi、Murthy Chintalapati、Savija Vijayaraghavan、Sandhya Prasad、Zhong Xu、Sriram Natarajan、Meena Vyas、Prem Kumar Venkatasalapathy、Prashant Sharma、Raghunandan Seshadri、Sarath Babu

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

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

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

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 およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

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 このリリースの新機能

- 1.2 Oracle Traffic Directorの機能

- 1.3 代表的なネットワーク・トポロジ

- 1.4 Oracle Traffic Director用語集

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

- 1.6 Oracle Traffic Directorの管理フレームワーク

- 1.6.1 管理フレームワークの概要

- 1.6.2 管理サーバー

- 1.6.3 管理ノード

- 1.6.4 管理インタフェース

- 1.6.5 構成ストア

- 1.6.6 インスタンスの構成ファイル

- 1.7 管理タスクの概要

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

- 1.8.1 トポロジの例

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

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

2 管理サーバーの管理

- 2.1 管理サーバーの作成

- 2.2 管理サーバーの起動

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

- 2.3.1 コマンドライン・インタフェースへのアクセス

- 2.3.2 管理コンソールへのアクセス

- 2.4 管理サーバーの停止および再起動

- 2.5 管理サーバー設定の表示

- 2.6 管理サーバー設定の変更

- 2.7 管理サーバー・インスタンスの削除

3 管理ノードの管理

- 3.1 管理ノードの作成

- 3.2 管理ノードのリストの表示

- 3.3 管理ノードの起動

- 3.4 管理ノードのプロパティの変更

- 3.5 管理ノードの停止および再起動

- 3.6 管理ノードの削除

第II部 基本管理

4 構成の管理

- 4.1 構成の作成

- 4.2 構成のリストの表示

- 4.3 構成のデプロイ

- 4.4 構成の変更

- 4.5 管理サーバーとノード間の構成の同期化

- 4.6 構成のコピー

- 4.7 構成の削除

- 4.8 構成バックアップのリストの表示

- 4.9 バックアップからの構成のリストア

5 インスタンスの管理

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

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

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

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

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

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

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

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

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

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

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

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

- 6.5.1 動的検出の方法

- 6.5.2 動的検出の有効化

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

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

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

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

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

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

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

8 仮想サーバーの管理

- 8.1 仮想サーバーの作成

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

- 8.3 仮想サーバーの変更

- 8.4 ルートの構成

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

- 8.6 仮想サーバーの削除

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

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

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

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

9 TCPプロキシの管理

- 9.1 TCPプロキシの作成

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

- 9.3 TCPプロキシの変更

- 9.4 TCPプロキシの削除

10 リスナーの管理

- 10.1 リスナーの作成

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

- 10.3 リスナーの変更

- 10.4 リスナーの削除

第III部 高度な管理

11 セキュリティの管理

- 11.1 管理サーバーへのアクセスの保護

- 11.1.1 管理者のユーザー名およびパスワードの変更

- 11.1.2 管理サーバーのLDAP認証の構成

- 11.1.3 管理サーバーのPKCS#11トークンのPINの有効化

- 11.1.4 管理サーバー証明書の更新

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

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

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

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

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

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

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

- 11.2.7 SSL/TLSの概念

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

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

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

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

- 11.4 証明書の管理

- 11.4.1 自己署名証明書の作成

- 11.4.2 CA署名証明書の取得

- 11.4.3 証明書のインストール

- 11.4.4 証明書リストの表示

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

- 11.4.6 証明書の削除

- 11.4.7 証明書を信頼するためのOracle Traffic Directorの構成

- 11.5 PKCS#11トークンの管理

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

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

- 11.6.2 CRLの自動インストール

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

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

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

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

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

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

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

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

- 11.9サービス拒否攻撃の回避

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

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

12 ログの管理

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

- 12.1.1 アクセス・ログ

- 12.1.2 サーバー・ログ

- 12.2 ログの表示

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

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

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

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

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

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

- 13.2 統計収集設定の構成

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

- 13.4 CLIを使用した統計の表示

- 13.4.1 監視統計の自動取得

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

- 13.6 SNMPを使用した監視

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

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

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

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

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

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

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

- 14.1 高可用性機能の概要

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

- 14.2.1 フェイルオーバーの動作

- 14.2.2 フェイルオーバー・モード

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

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

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

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

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

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

- 14.3.1.3 ロギング

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

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

- 15.2 接続処理設定のチューニング

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

- 15.2.1.1 接続処理概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 15.6.2 暗号および証明書鍵

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

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

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

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

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

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

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

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

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

- 15.10.6 短期のシステム監視

- 15.10.7 長期のシステム監視

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

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

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

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

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

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

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

- 16.2.3 PKCS#11トークンPINの変更後SSL/TLSが有効なサーバーを再起動できない

- 16.2.4 SNMPサブエージェントを起動できない

- 16.2.5 管理サーバーと通信できない: 接続拒否

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

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

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

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

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

- 16.3 よくある質問

- 16.3.1 管理サーバー・ユーザーのパスワードはどのようにリセットするのですか。

- 16.3.2 構成とは何ですか。

- 16.3.3 管理コンソールにはどのようにアクセスするのですか。

- 16.3.4 初めて管理コンソールにアクセスするときに証明書の警告が表示されるのはなぜですか。

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

- 16.3.6 管理コンソールにおいて、構成の保存と構成のデプロイにはどのような違いがありますか。

- 16.3.7 管理コンソールに「デプロイメント保留中」のメッセージが表示されるのはなぜですか。

- 16.3.8 管理コンソールにインスタンス構成デプロイ済のメッセージが表示されるのはなぜですか。

- 16.3.9 管理コンソール・セッションが突然終了するのはなぜですか。

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

- 16.3.11 tadm --user=admin --host=myhostサブコマンドでは、なぜ指定したサブコマンドが実行されず、コマンド・シェルが起動されるのですか。

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

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

- 16.3.14 CLIへのアクセス時、毎回パスワード入力のプロンプトが表示されないようにCLIを構成することはできますか。

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

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

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

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

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

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

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

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

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

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

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

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

- 16.3.27 サポートするJDKの最小バージョンおよびJAVA_HOME変数は何ですか。

- 16.4 Oracleサポートへの連絡

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

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

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

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

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

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

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

- A.7 CPUメトリック

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

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

- A.10 プロキシ・キャッシュ・メトリック

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

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の保護

図一覧

- 1-1 Oracle Traffic Directorネットワーク・トポロジ: アクティブ-パッシブ・フェイルオーバー・モード

- 1-2 Oracle Traffic Directorの管理フレームワーク

- 1-3 Oracle Traffic Directorの管理ワークフロー

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

- 2-1 Oracle Traffic Director管理コンソールのログイン・ページ

- 2-2 Oracle Traffic Director管理コンソールのホームページ

- 3-1 管理ノードのリスト

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

- 4-2 構成のリスト

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

- 6-1 新規オリジン・サーバー・プール・ウィザード

- 7-1 新規オリジン・サーバー・ウィザード

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

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

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

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

- 11-1 新規自己署名証明書ウィザード

- 11-2 「証明書署名リクエストの作成」ウィザード

- 11-3 サーバー証明書のインストール・ウィザード

- 14-1 Oracle Traffic Directorネットワーク・トポロジ: アクティブ-パッシブ・フェイルオーバー・モード

- 14-2 フェイルオーバー・モード

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

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

- 15-2 HTTP処理スレッドの最大数

表一覧

- 4-1 構成変更用のCLIコマンド

- 8-1 仮想サーバー変更用のCLIコマンド

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

- 11-2 証明書選択ロジック

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

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

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

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

- 14-2 引数パラメータ

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

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

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

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

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

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

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

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

- A-7 CPUメトリック

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

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

- A-10 プロキシ・キャッシュ・メトリック

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

はじめに

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

対象読者

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

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

- Webブラウザの使用

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

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

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

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

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

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コマンドライン・リファレンス』

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

- Oracle Virtual Assembly Builderユーザーズ・ガイド

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

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

第I部

スタート・ガイド

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

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

- 第2章「管理サーバーの管理」では、Oracle Traffic Director管理サーバーを作成、起動、アクセスおよび管理する方法を説明します。

- 第3章「管理ノードの管理」では、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.oracle.com/cd/E18476_01/index.htm)を参照してください。Oracle Traffic Directorは様々なFusion Middleware製品でも動作保証されています。

Oracle Traffic Directorは、簡単にインストール、構成および使用できます。Oracle Traffic Directorインスタンスの管理には、シンプルでウィザードを利用したグラフィカル・インタフェースの他、堅牢なコマンドライン・インタフェースが用意されています。

エンジニアド・システム・プラットフォームで、Oracle Traffic Directorインスタンスのペアを設定し、組み込まれている高可用性機能をアクティブ-パッシブ・フェイルオーバーまたはアクティブ-アクティブ・フェイルオーバーのいずれかを設定するために活用できます。ネットワークのへのトラフィック量の増大に伴い、リクエストのルーティング先となるバックエンド・サーバーを追加してOracle Traffic Directorを再構成することで、環境を簡単に拡張できます。

IT環境のニーズに応じて、リクエストをバックエンド・ユーザーに分散するとき、およびクライアントにレスポンスを転送するときに複数の複雑なルールを適用するようにOracle Traffic Directorを構成できます。

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

- このリリースの新機能

- Oracle Traffic Directorの機能

- 代表的なネットワーク・トポロジ

- Oracle Traffic Director用語集

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

- Oracle Traffic Directorの管理フレームワーク

- 管理タスクの概要

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

1.1 このリリースの新機能

Oracle Traffic Director 11.1.1.9.0の新機能は次のとおりです。

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

詳細は、第14章「高可用性を提供するためのOracle Traffic Directorの構成」の第14.3.1項「サーバーの状態をチェックするための外部ヘルス・チェック実行可能ファイルの使用」を参照してください。

- Oracle Linux Server 6上のOracle Traffic Director
Oracle Linux Serverリリース6にOracle Traffic Directorをインストールできるようになりました。詳細は、『Oracle Traffic Directorインストレーション・ガイド』を参照してください。

- オリジン・サーバーがオフライン時のカスタム・メンテナンス・ページのサポート
Oracle Traffic Directorでは、すべてのバックエンド・サーバーがオフラインであることが検出された場合に、カスタム・サーバー・プール・メンテナンス・レスポンス・コードおよびHTMLページを提供できるようになりました。メッセージのこのタイプを表示させることは、ゲートウェイがタイムアウトしたり、ホストの静的コンテンツに対して別のリソースを作成したりするより適切です。

詳細は、第6章「オリジン・サーバー・プールの管理」の第6章「カスタム・メンテナンス・ページの構成」を参照してください。

- TLS 1.1およびTLS 1.2のサポート
Oracle Traffic DirectorではTLS 1.1およびTLS 1.2がサポートされるようになりました。これは、WLS管理対象サービス使用事例をサポートします。この使用事例では、Oracle Traffic Directorはサービス・ロールとしてロード・バランサを提供し、プライマリSSL終端点として機能します。

詳細は、第11章「セキュリティの管理」の第11章「リスナーのSSL/TLS暗号の構成」を参照してください。

- オリジン・サーバー・プールのHTTP転送プロキシ・サポート
Oracle Traffic Directorでは、HTTP転送プロキシ・サーバーがオプションでオリジン・サーバー・プールへ関連付けられることをサポートするようになり、そのため、プールのすべてのメンバー・オリジン・サーバーは構成済HTTP転送プロキシ・サーバーを通じて通信されます。この機能は、目的のオリジン・サーバーへのアクセスが企業のプロキシ・サーバーを通じて制限されている環境をサポートします。

詳細は、第6章「オリジン・サーバー・プールの管理」のHTTP転送プロキシ・サーバーの指定に関する項およびOracle Traffic Director CLIリファレンスのcreate-origin-server-poolコマンドを参照してください。

- 高可用性(HA)の変更およびJaaS用の複数の管理ユーザーのサポート
Oracle Traffic Directorには、いくつかの高可用性(HA)機能の変更が含まれます。これには、プライマリ・ノードとバックアップ・ノードに加えてVIPが同じサブネットに含まれる必要があるというサブネットワーク制限を削除したことが含まれます。さらに、キープ・アライブ接続か永続接続を扱うサブシステムでは、ユニキャスト伝送のサポートを追加しました。

- 監視の拡張機能
Oracle Traffic Directorには、インスタンス、接続キュー、仮想サーバー、オリジン・サーバーの新しい監視属性、SNMPのTCPプロキシの監視の変更およびサーバー・インスタンスの各VIPの統計を含む新しいフェイルオーバーの監視が含まれます。

詳細は、付録A「Oracle Traffic Directorで追跡されるメトリック」を参照してください。

- デフォルトでのPOSTキープアライブの有効化
Oracle Traffic Directorは、Oracle WebLogic Server (WLS)がオリジンの場合に、デフォルトでPOSTキープアライブを有効にするようになりました(デフォルトではalways-use-keep-aliveがtrue)。

- Solaris IPoIB高可用性(HA)サポート
Oracle Traffic Directorは、Solarisの高可用性IP over InfiniBand (IPoIB)を提供するよう構成できるようになりました。Solarisの高可用性を実現するためにOracle Traffic Directorをグローバル・ゾーンにインストールする必要があるという制限はなくなりました。

- Oracle Traffic Directorはオリジン・サーバーのステータスを管理するようになり、オリジン・サーバーのページのユーザー・インタフェースにステータスを表示するようになりました。Oracle Traffic Directorは、動的に検出されたオリジン・サーバーのステータスも使用可能で有効であれば表示できます。

1.2 Oracle Traffic Directorの機能

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

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

- ラウンド・ロビン

- 最小接続件数

- 最小レスポンス時間

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

- 重み付け最小接続件数

- IPハッシュ(この分散メソッドは、リクエストをクライアントIPアドレスから導出されたハッシュに基づいてオリジン・サーバーに固定します)

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

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

- コンテンツベースのルーティング
HTTP/Sリクエストをリクエストのコンテンツに基づいてバックエンドにある特定のサーバーにルーティングするようにOracle Traffic Directorを構成できます。これにより、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を構成できます。詳細は、8.4項「ルートの構成」および『Oracle Traffic Directorコマンドライン・リファレンス』を参照してください。

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

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

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

- オリジン・サーバー・プールのHTTP転送プロキシ・サポート
目的のオリジン・サーバーへのアクセスが企業のプロキシ・サーバーを通じて制限されている環境では、(指定プールの)すべてのメンバー・オリジン・サーバーが構成済HTTP転送プロキシ・サーバーを通じて通信するように、オプションでHTTP転送プロキシ・サーバーをオリジン・サーバー・プールに関連付けることができます。

- 高可用性
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へのほとんどの構成変更は、インスタンスを再起動したり、処理中のリクエストに影響を及ぼしたりすることなく動的にデプロイできます。

- 統計の監視
管理者は、管理コンソール、コマンドライン・インタフェース、および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アドレスを提供します。アクティブなインスタンス(この例ではotd_1など)がリクエストを受信すると、リクエストの送信先のサーバー・プールを特定し、そのサーバー・プールに定義されたロード分散メソッドに基づいてプール内のいずれかのサーバーにリクエストを転送します。

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

ここで説明したアクティブ-パッシブ設定では、フェイルオーバー・グループ内の1つのノードが、どの時点でも冗長となります。リソースの使用率を向上するには、アクティブ-アクティブ・モードの2つのOracle Traffic Directorインスタンスを2つの仮想IPアドレスを使用して構成できます。各インスタンスは1つの仮想IPアドレスで受信したリクエストに応じ、もう1つのインスタンスをバックアップします。

フェイルオーバー・グループでの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 Traffic Director構成の作成と管理、管理ノード上へのインスタンスのデプロイ、およびこれらのインスタンスのライフサイクル管理に使用できる管理コンソールとコマンドライン・インタフェースをホストするために特別に構成されたOracle Traffic Directorインスタンスです。管理ノード上にOracle Traffic Director構成のインスタンスをデプロイできます。この場合、管理サーバーは管理ノードとしても機能します。

管理ノード

リモート管理サーバーに登録される特別構成のOracle Traffic directorインスタンスです。ホスト上で実行される管理ノードはリモート管理サーバーのエージェントとして機能します。管理サーバーは管理ノードの支援を受け、ホスト上で実行されているインスタンスを管理します。
各ノード上では構成のインスタンスを1つのみデプロイできることに注意してください。

INSTANCE_HOME

ユーザーが選択したディレクトリであり、Oracle Traffic Directorインスタンスに関連する構成データおよびバイナリ・ファイルが格納される管理サーバーまたは管理ノード上の場所です。

ORACLE_HOME

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

管理コンソール

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は、オリジン・サーバー・プールに対して指定されたロード分散方法に基づいて、プール内にある各サーバーにクライアント・リクエストを分散させます。

Oracle Traffic Directorは、オリジン・サーバー・プールで、直接または構成済HTTP転送プロキシ・サーバーを通じて、オリジン・サーバーと通信できます。

仮想サーバー

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

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

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

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

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ユーザーズ・ガイド』を参照してください。

1.6 Oracle Traffic Directorの管理フレームワーク

管理サーバーによって提供されている管理インタフェースを使用して、様々な管理タスク(Oracle Traffic Director機能の有効化、機能の動作の調整、特別な方法でリクエストおよびレスポンスを処理するようにOracle Traffic Directorに指示)を実行できます。

次の項目では、管理フレームワークを詳細に説明します。

- 1.6.1項「管理フレームワークの概要」

- 1.6.2項「管理サーバー」

- 1.6.3項「管理ノード」

- 1.6.4項「管理インタフェース」

- 1.6.5項「構成ストア」

- 1.6.6項「インスタンスの構成ファイル」

1.6.1 管理フレームワークの概要

Oracle Traffic Directorインスタンスに定義した設定は、管理サーバーの構成ストアに格納されます。1つ以上の管理ノードに構成をiインスタンスとしてデプロイすることで、構成をインスタンス化できます。

図1-2は、Oracle Traffic Directorの管理フレームワークを表しています。

図1-2 Oracle Traffic Directorの管理フレームワーク

図1-2は、コマンドライン・インタフェースおよび管理コンソール・アプリケーションをホストしている、1つのマシン上で実行されている管理サーバーを示しています。管理インタフェースを使用して3つの構成(pub.example.com、app.example.comおよびadm.example.com)が作成され、それらは管理サーバーの構成ストアに格納されます。

- adm.example.com構成は、1つの管理ノードでインスタンスとしてデプロイされます。

- app.example.com構成は、2つの管理ノードでインスタンスとしてデプロイされます。

- pub.example.com構成は、2つの管理ノードでインスタンスとしてデプロイされ、2つのノード間で高可用性を確保するハートビート方式がとられます。

1.6.2 管理サーバー

Oracle Traffic Directorインスタンス用に特別に構成された管理サーバーを使用してOracle Traffic Directorのすべての管理タスクを実行できます。

Oracle Traffic Director管理サーバーは、製品のインストール時に自動的に作成されません。2.1項「管理サーバーの作成」の説明に従い、管理サーバーを作成する必要があります。

1.6.3 管理ノード

管理ノードは物理ホストであり、その上にOracle Traffic Directorインスタンスを作成できます。

ホストを管理ノードにするには、次の操作を行います。

1. Oracle Traffic Directorをホストにインストールする、またはホストのローカル・ディレクトリにOracle Traffic Directorのリモート・インストールをマウントします。

2. configure-serverコマンドを実行して、管理サーバーにホストを登録します。このコマンドにより、Oracle Traffic Director管理ノードがホストとして指定され、管理ノードがリモート管理サーバーに登録されます。

これで、管理ノード上でOracle Traffic Director構成のインスタンスを作成できるようになりました。管理ノードでは、特定の構成の1つのインスタンスのみを作成できることに注意してください。

管理ノードの作成および管理の詳細は、第3項「管理ノードの管理」を参照してください。

1.6.4 管理インタフェース

Oracle Traffic Directorの管理サーバーは、Oracle Traffic Directorインスタンスの作成、変更および管理に使用できる次のインタフェースを備えています。

- コマンドライン・インタフェース
Oracle Traffic Directorには、幅広い管理操作をサポートするコマンドライン・インタフェース(CLI)が用意されています。コマンドライン・インタフェースの構文は、簡単に理解でき使用できます。このインタフェースを使用するときは、個々のコマンドおよびオプションのヘルプを参照できます。CLIへのアクセスの詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

- 管理コンソール
管理コンソールは、Webベースのグラフィカル・インタフェースで、Oracle Traffic Directorインスタンスの作成、監視および管理に使用できる一連の画面およびウィザードで構成されます。管理コンソールへのアクセスの詳細は、2.3.2項「管理コンソールへのアクセス」を参照してください。

1.6.5 構成ストア

Oracle Traffic Directorインスタンスの構成可能なすべての要素は、次のディレクトリの構成ストアに作成されるファイルのセットである構成として格納されます。

INSTANCE_HOME/admin-server/config-store/config_name/config

config_nameは、構成の作成時に構成に指定した名前です。

構成ストア内のファイルは、Oracle Traffic Directorによって内部で使用されるものです。これらは、管理インタフェース(管理コンソールおよびコマンドライン・インタフェース)を介してのみ作成、更新および削除できます。

注意:
構成ストア内のファイルは、管理コンソールまたはCLIのいずれかを使用して構成を編集すると、自動的に更新されます。
構成ストア内のファイルを手動で編集しないでください。

1.6.6 インスタンスの構成ファイル

Oracle Traffic Director構成のインスタンスの作成時、構成を表す構成ファイルが管理サーバーから、各管理ノードのINSTANCE_HOME/net-config_name/configディレクトリにコピーされます。

Oracle Traffic Directorでは、インスタンスが起動され、クライアントからのリクエストを処理するときにINSTANCE_HOME/net-config_name/configディレクトリの構成ファイルが使用されます。

構成ファイルの内容および構造の詳細は、Oracle Traffic Director構成ファイル・リファレンスを参照してください。

1.7 管理タスクの概要

図1-3は、Oracle Traffic Directorインスタンスを作成および管理するために実行する必要があるタスクの一般的な順序を示しています。

図1-3 Oracle Traffic Director管理ワークフロー

注意:
Oracle Traffic Directorの管理者として、セキュリティの管理、パフォーマンスのためのチューニング、問題のトラブルシューティングなどの追加のタスクを実行する必要がある場合があります。これらのタスクは、固定の順序の特定の時点で必ずしも実行されるわけではないので、フローチャートに示されていません。これらのすべての追加タスクは、このドキュメントのその他の章で説明されています。

- 製品のインストール
サイレント・モードで、または対話型のグラフィカル・ウィザードを使用して、Oracle Traffic Directorをx86_64のOracle Linux 5.6+またはOracle Linux 6にインストールできます。

詳細は、Oracle Traffic Directorインストレーション・ガイドを参照してください。

- 管理サーバーの作成
製品をインストールした後、Oracle Traffic Directorの管理サーバー・インスタンスを作成する必要があります。管理サーバーは、特別に構成されたOracle Traffic Director仮想サーバーで、Oracle Traffic Directorインスタンスの管理に使用できます。

詳細は、Oracle Traffic Directorインストレーション・ガイドの管理サーバー・インスタンスの作成に関する項を参照してください。

- 管理サーバーの管理
場合によっては、管理サーバーの停止と再起動、または設定(管理者ユーザー名とパスワードなど)の変更が必要になることがあります。

詳細は、第2章『管理サーバーの管理』を参照してください。

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

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

- 管理ノードの作成および管理
管理ノードは物理ホストであり、その上にOracle Traffic Directorインスタンスを作成できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

詳細は、第13章「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.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-4は、例のトポロジを示しています。

図1-4 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インストレーション・ガイドの説明に従い、ホストbin.example.comおよびapps.example.comにOracle Traffic Directorをインストールします。

2. bin.example.comで、configure-server CLIコマンドを使用して、管理サーバー・インスタンスを作成します。

> $ORACLE_HOME/bin/tadm configure-server --port=8989 --user=admin
--instance-home=/production/otd/

This command will create an Administration Server. The password that is
provided will be required to access the Administration Server.
Enter admin-user-password>
Enter admin-user-password again>
OTD-70214 The Administration Server has been configured successfully.
The server can be started by executing: /production/otd/admin-server/bin/startserv
The Administration Console can be accessed at https://bin.example.com:8989 using user name 'admin'.

3. 管理サーバーの起動。

> /production/otd/admin-server/bin/startserv

Oracle Traffic Director 11.1.1.7.0 B01/14/2013 09:08
[NOTIFICATION:1] [OTD-80118] Using [Java HotSpot(TM) 64-Bit Server VM, Version 1.6.0_29] from [Sun Microsystems Inc.]
[NOTIFICATION:1] [OTD-80000] Loading web module in virtual server [admin-server] at [/admin]
[NOTIFICATION:1] [OTD-80000] Loading web module in virtual server [admin-server] at [/jmxconnector]
[NOTIFICATION:1] [OTD-10358] admin-ssl-port: https://bin.example.com:8989 ready to accept requests
[NOTIFICATION:1] [OTD-10487] successful server startup

4. apps.example.comホストで、configure-serverコマンドを実行して、ホストを管理ノードとしてリモート管理サーバーに登録します。

> $ORACLE_HOME/bin/tadm configure-server --user=admin --port=8989
--host=bin.example.com --admin-node --node-port=8900
--instance-home=/home/otd-instances

This command will create an Administration Node and register it with the remote Administration Server: https://bin.example.com:8989.
Enter admin-user-password>
OTD-70215 The Administration Node has been configured successfully.
The node can be started by executing: /home/otd-instances/admin-server/bin/startserv

5. 管理ノードを起動します。

> /home/otd-instances/admin-server/bin/startserv

Oracle Traffic Director 11.1.1.7.0 B01/14/2013 09:08
[NOTIFICATION:1] [OTD-80118] Using [Java HotSpot(TM) 64-Bit Server VM, Version 1.6.0_29] from [Sun Microsystems Inc.]
[NOTIFICATION:1] [OTD-80000] Loading web module in virtual server [admin-server] at [/jmxconnector]
[NOTIFICATION:1] [OTD-10358] admin-ssl-port: https://apps.example.com:8900 ready to accept requests
[NOTIFICATION:1] [OTD-10487] successful server startup

6. 管理サーバー(bin.example.com)で、create-config CLIコマンドを使用してhr-configという名前の構成を作成します。

> $ORACLE_HOME/bin/tadm create-config --user=admin --port=8989
--listener-port=1905 --server-name=hr-apps.example.com
--origin-server=hr-1.example.com:80,hr-2.example.com:80 hr-config

Enter admin-user-password>
OTD-70201 Command 'create-config' ran successfully.

7. 管理サーバーからcreate-instanceCLIコマンドを実行し、管理ノードapps.example.comで構成hr-configのインスタンスを作成します。

> $ORACLE_HOME/bin/tadm create-instance --user=admin --port=8989
--config=hr-config apps.example.com

Enter admin-user-password>
OTD-70201 Command 'create-instance' ran successfully.

8. 管理サーバーからstart-instance CLIコマンドを実行して、apps.example.comで作成したばかりのOracle Traffic Directorインスタンスを起動します。

> $ORACLE_HOME/bin/tadm start-instance --config=hr-config

CLI204 Successfully started the server instance.

注意:
この手順のステップでは、CLIのみを使用しますが、ステップ6以降は管理コンソールを使用して実行することもできます。

これで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に送信したことを示します。

2 管理サーバーの管理

管理サーバーは、特別に構成されたOracle Traffic Director仮想サーバーで、Oracle Traffic Directorインスタンスの作成、監視および管理に使用できます。

Oracle Traffic Directorの管理フレームワークにおける管理サーバーの役割の詳細は、1.6項「Oracle Traffic Directorの管理フレームワーク」を参照してください。

この章では、管理サーバーの作成、削除、起動、停止および再起動の方法、ならびにその設定方法を説明します。また、Oracle Traffic Directorの管理インタフェース(管理コンソールとコマンドライン・インタフェース)へのアクセス方法についても説明します。

この章には次の項が含まれます:

- 管理サーバーの作成

- 管理サーバーの起動

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

- 管理サーバーの停止および再起動

- 管理サーバー設定の表示

- 管理サーバー設定の変更

- 管理サーバー・インスタンスの削除

2.1 管理サーバーの作成

Oracle Traffic Director管理サーバーには、Oracle Traffic Directorのすべての管理タスクを実行できるインタフェースが用意されています。

管理サーバーを作成するには、次の操作を行います。

1. 次の例に示すとおり、configure-server CLIコマンドを実行します。

> $ORACLE_HOME/bin/tadm configure-server --port=8989 --user=admin
--instance-home=/production/otd/

ORACLE_HOMEは、Oracle Traffic Directorがインストールされているディレクトリです。

注意:
ユーザー名の最大文字数は100文字で、空白を含めることはできません。

次のメッセージとプロンプトが表示されます。

This command will create the administration server.
The password that is provided will be required to access the administration server.
Enter admin-user-password>

2. 管理者パスワードを入力します。
後でこのパスワードを使用してOracle Traffic Director管理コンソールにログインします。

パスワードを再度入力するプロンプトが表示されます。

Enter admin-user-password again>

3. 管理者パスワードを再度入力して確認します。

管理サーバーに関連するファイルおよびリソース(構成アーティファクト、実行可能コマンドなど)は、configure-serverコマンドで指定されたinstance-homeディレクトリ内のadmin-serverサブディレクトリ内にあります。

管理サーバーが含まれるホストで続いてインスタンス化する各Oracle Traffic Director構成について、次の例に示すように、net-config_nameという名前のディレクトリがinstance-homeディレクトリ内に作成されます。

/production/otd
admin-server
net-test
net-soa
net-adf

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

2.2 管理サーバーの起動

管理インタフェース(管理コンソールおよびコマンドライン・インタフェース)を使用できるようにするには、管理サーバーが実行されている必要があります。

管理サーバーを起動するには、次のコマンドを実行します。

> $INSTANCE_HOME/admin-server/bin/startserv

INSTANCE_HOMEが、管理サーバー・インスタンスを含むすべてのOracle Traffic Directorインスタンスが含まれるディレクトリとなります。これは、configure-serverコマンドを使用して管理サーバーを作成するときにinstance-homeオプションを使用して指定したディレクトリです。

startservコマンドにより、管理サーバーの作成時に指定したポートで管理サーバーが起動されます。

次の例に示すようなsuccessful server startupメッセージが表示されるまで待機します。

Oracle Traffic Director 11.1.1.7.0 B01/14/2013 09:08
[NOTIFICATION:1] [OTD-80118] Using [Java HotSpot(TM) 64-Bit Server VM, Version 1.6.0_29] from [Sun Microsystems Inc.]
[NOTIFICATION:1] [OTD-80000] Loading web module in virtual server [admin-server] at [/admin]
[NOTIFICATION:1] [OTD-80000] Loading web module in virtual server [admin-server] at [/jmxconnector]
[NOTIFICATION:1] [OTD-10358] admin-ssl-port: https://bin.example.com:8989 ready to accept requests
[NOTIFICATION:1] [OTD-10487] successful server startup

この後Oracle Traffic Directorの管理インタフェース(管理コンソールおよびコマンドライン・インタフェース)を使用して、Oracle Traffic Directorインタフェースを構成および管理できるようになります。

管理コンソールおよびコマンドライン・インタフェースを使用するには、管理サーバーの作成時に指定したユーザー名とパスワードを使用してログインする必要があります。詳細は、2.3項「管理インタフェースへのアクセス」を参照してください。

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

この項には次のトピックが含まれます:

- コマンドライン・インタフェースへのアクセス

- 管理コンソールへのアクセス

注意:
管理インタフェースを使用できるようにするには、管理サーバーが実行中である必要があります。管理サーバーの起動の詳細は、2.2項「管理サーバーの起動」を参照してください。

2.3.1 コマンドライン・インタフェースへのアクセス

次に示すように、ORACLE_HOME/binからtadmコマンドを実行することで、Oracle Traffic Directorのコマンドライン・インタフェース(CLI)にアクセスできます。

./tadm [subcommand] --user=admin_user --host=adminserver_host [--password-file=path_to_file] --port=adminserver_port

CLIでは、管理サーバーへのアクセスを許可するかどうかに、パスワードに基づく認証が使用されます。--password-fileオプションを指定しない場合、管理者のユーザー・パスワードを入力するためのプロンプトが表示されます。パスワードの入力後、指定されているサブコマンドが実行されます。

tadmコマンドでは、Oracle Traffic Directorのすべての機能の設定の作成、表示、更新および管理に使用できるサブコマンドの包括的なセットがサポートされています。サブコマンドを指定せずにtadmコマンドを実行する場合、CLIのシェル・モードに入ります。シェル・モードでは、管理サーバーへの接続オプション(user、host、port、password)はすでに指定済であるため、接続オプションを毎回指定することなく、個々のサブコマンドを実行できます。

--helpオプションを使用してサブコマンドを実行することで、サブコマンドのヘルプを表示できます。

使用モード(スタンドアロン、シェル、ファイル)などCLIの使用、tadmコマンドでサポートされているサブコマンド、および各サブコマンドのオプションの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照してください。

2.3.2 管理コンソールへのアクセス

管理コンソールは、Oracle Traffic Directorインスタンスを作成、構成および監視できる、ブラウザ・ベースのグラフィカル・インタフェースです。

Oracle Traffic DirectorコンソールでサポートされているWebブラウザ・バージョンの詳細は、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlのOracle Fusion Middlewareのサポートされるシステム構成を参照してください。

管理コンソールにアクセスするには、次の操作を行います。

1. 管理コンソールのURLに移動します。
管理コンソールのURLは、Oracle Traffic Directorインストレーション・ガイドの管理サーバー・インスタンスの作成に関する項で説明されているように、管理サーバーの作成時に指定したホスト名およびポート番号に依存します。

たとえば、admin.example.comホストのポート1895を使用して管理サーバーを作成した場合、管理コンソールのURLは次のようになります。

https://admin.example.com:8989

注意:
管理サーバーとの通信はSSLで実行されます。URLでhttp://スキーマを使用して、管理コンソールにアクセスしようとすると、https:// URLに自動的にリダイレクトされます。

SSLが有効化された管理サーバーでは、信頼できる認証局から発行された証明書ではなく、自己署名デジタル証明書が使用されます。このため、管理コンソールへの最初のアクセスでは、invalid security certificateメッセージが表示されます。

2. 証明書を信頼することを選択し、管理コンソールのログイン・ページに進みます。
証明書を信頼するために実行する手順は、使用しているブラウザによって異なります。たとえば、Mozilla Firefox 4.0では、エラー・ページで「リスクを理解します」リンクをクリックし、「例外の追加」ボタンをクリックして、次に表示されるページで、「セキュリティ例外の確認」ボタンをクリックします。

Oracle Traffic Director管理コンソールのログイン・ページが表示されます。

図2-1 Oracle Traffic Director管理コンソールのログイン・ページ

3. 管理サーバーの作成時に指定した管理者のユーザー名とパスワードを入力します。
管理コンソールのホームページが表示されます。

図2-2 Oracle Traffic Director管理コンソールのホームページ

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

注意:
管理コンソール・ブラウザ・セッションが30分間アイドル状態だった場合、ユーザーはログアウトされ、ログイン・ページが表示されます。

2.4 管理サーバーの停止および再起動

管理サーバー・インスタンスを新しい設定で再び作成する必要がある場合があります。管理サーバーの再作成を試みる前に、この項の説明に従って、実行中のサーバーを停止する必要があります。管理者パスワードまたは管理者サーバー・ポートを変更する場合などは、変更を有効にするために、この項の説明に従い管理サーバーを再起動する必要があります。

管理コンソールまたはCLIのいずれかを使用して、管理サーバーを停止および再起動できます。

注意:
管理サーバーを停止した場合、管理サーバーを再起動するまで管理コンソールを使用できません。

管理コンソールを使用した管理サーバーの停止および再起動

管理コンソールを使用して管理サーバーを停止または再起動するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
使用可能なノードのリストが表示されます。

3. ノードのリストから、「管理サーバー」を選択します。

4. 「共通のタスク」ペインで、「再起動」または「停止」をクリックします。
管理サーバーの再起動または停止の確認を求めるダイアログ・ボックスが表示されます。「OK」をクリックします。

「再起動」をクリックした場合、管理サーバーが再起動された後、管理コンソールのログイン・ページが表示されます。

「停止」をクリックした場合、管理サーバーの停止後、ブラウザが管理サーバーと通信できないことを示すダイアログ・ボックスが表示されます。2.2項「管理サーバーの起動」の説明に従って管理サーバーを起動します。次に、ダイアログ・ボックスの「リロード」ボタンをクリックして、管理コンソールのログイン・ページを表示します。

CLIを使用した管理サーバーの停止

管理サーバーを停止するには、stop-adminコマンドを実行します。

> $ORACLE_HOME/bin/tadm stop-admin --user=admin_server_user --port=admin_server_port node_host

node_hostは、管理サーバー・インスタンスがデプロイされているホストの名前またはIPアドレスです。

プロンプトで、管理ユーザー・パスワードを入力します。

管理サーバーが停止した後、次のメッセージが表示されます。

OTD-70201 Command 'stop-admin' ran successfully.

注意:
管理サーバーの停止は、Oracle Traffic Directorインスタンスの状態に影響を及ぼしません。

CLIを使用した管理サーバーの再起動

CLIを使用して管理サーバーを再起動するには、次のコマンドを実行します。

> $ORACLE_HOME/bin/tadm restart-admin --user=admin_server_user --port=admin_server_port node_host

node_hostは、管理サーバー・インスタンスがデプロイされているホストの名前またはIPアドレスです。

プロンプトで、管理ユーザー・パスワードを入力します。

管理サーバーが再起動された後、次のメッセージが表示されます。

OTD-70201 Command 'restart-admin' ran successfully.

注意:
別の方法として、次のコマンドを使用して、管理サーバーを停止および再起動できます。

> $INSTANCE_HOME/admin-server/bin/stopserv

> $INSTANCE_HOME/admin-server/bin/restart

2.5 管理サーバー設定の表示

管理コンソールまたはCLIのいずれかを使用して、管理サーバー設定を表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した管理サーバー設定の表示

管理コンソールを使用して管理サーバーの現在のプロパティを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
使用可能なノードのリストが表示されます。

注意:
「ノード」ボタンを使用するには、新規の構成を少なくとも1つ作成する必要があります。

3. ノードのリストから、「管理サーバー」を選択します。
一般設定ページが表示されます。ナビゲーション・ペインで「認証」をクリックすることで、認証設定を表示できます。

CLIを使用した管理サーバー設定の表示

CLIを使用して管理サーバーの現在のプロパティを表示するには、次のコマンドを実行します。

tadm> get-admin-prop

管理サーバーの現在のプロパティが、次の例のように表示されます。

instance-home=/production/otd
java-home=/production/otd/jdk
admin-node=false
server-version=Oracle Traffic Director 11.1.1.7.0 B01/14/2013 09:08
admin-user=admin
server-user=joe
ssl-port=8989
log-file=../logs/server.log
log-level=NOTIFICATION:1
access-log-file=../logs/access.log
host=adm.example.com
description=This is the Administration Server node

これらのプロパティは、configure-server CLIコマンドを使用して管理サーバーを作成するときに指定した、またはデフォルトで設定されたプロパティです。

2.6 管理サーバー設定の変更

管理コンソールまたはCLIのいずれかを使用して、管理サーバー設定を変更できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した管理サーバー設定の変更

管理コンソールを使用して管理サーバーのプロパティを変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
使用可能なノードのリストが表示されます。

3. ノードのリストから、「管理サーバー」を選択します。
一般設定ページが表示されます。このページでは、次の処理が可能です。

- 管理サーバーが通信に使用するSSLポート番号を変更します。

- 管理サーバー・プロセスで使用されるJDKへのパスを変更します。

- アクセス・ログとサーバー・ログの場所、およびサーバー・ログ・レベルを変更します。

- 管理サーバーの実行に使用されるユーザーIDを変更します。ユーザーIDを変更できるのは、管理サーバーがrootユーザーとして実行されていて、管理サーバーに実行中のインスタンスがない場合のみであることに注意してください。

また、管理サーバーの証明書データベースのinternalトークンのPINの設定と構成、および管理サーバーの認証モードの変更と構成も可能です。詳細は、11.1項「管理サーバーへのアクセスの保護」を参照してください。

4. 変更するパラメータを指定してから、「保存」をクリックします。
「コンソール・メッセージ」ペインに、更新した設定が保存されたことを示すメッセージが表示されます。

5. 「共通のタスク」ペインで、「再起動」をクリックして管理サーバーを再起動します。

CLIを使用した管理サーバー設定の変更

CLIを使用して管理サーバーの設定を変更するには、次のコマンドを実行します。

tadm> set-admin-prop (property=value)+

次の例に示すような、空白で区切られた1つ以上のproperty=valueのペアを指定できます。

tadm> set-admin-prop ssl-port=8900 log-level=WARNING:1

set-admin-propコマンドを使用して設定できるプロパティの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

注意:
変更内容を有効にするには、管理サーバーを再起動する必要があります。

2.7 管理サーバー・インスタンスの削除

管理サーバー・インスタンスを削除するには、管理サーバー・ホストのシェル・プロンプトから次のコマンドを実行します。

注意:
管理サーバー・インスタンスを削除すると、管理コンソールとCLIは使用できなくなり、管理サーバー・ホストにデプロイされているOracle Traffic Directorインスタンスが削除され、管理ノードにデプロイされているOracle Traffic Directorインスタンスを管理できなくなります。

$ORACLE_HOME/bin/tadm unconfigure-server --instance-home=absolute_path

管理サーバー・インスタンスが削除された後、次のメッセージが表示されます。

OTD-70201 Command 'unconfigure-server' ran successfully

3 管理ノードの管理

特定のホスト上にOracle Traffic Directorをインストールして管理サーバーを作成した後、同じホスト上にOracle Traffic Directorサーバー・インスタンスを作成できます。ただし、管理サーバーが実行されているホストとは別のリモート・ホスト上にOracle Traffic Directorサーバー・インスタンスをデプロイすることが必要になる場合もあります。たとえば、Oracle Traffic Directorサービスの高可用性を確保するため、2つの異なるホスト上に構成のインスタンスをデプロイできます。

管理サーバーを作成したホストとは別のホストにOracle Traffic Directorサーバー・インスタンスを作成するには、まずそれらの別のホストを管理ノードとして指定し、管理サーバーに登録する必要があります。

この章では、管理ノードの作成手順とその起動、停止、再起動および削除の手順について説明します。

この章には次の項が含まれます:

- 管理ノードの作成

- 管理ノードのリストの表示

- 管理ノードの起動

- 管理ノードのプロパティの変更

- 管理ノードの停止および再起動

- 管理ノードの削除

3.1 管理ノードの作成

管理ノードを作成するには、管理サーバーが実行中であることを確認してから、管理ノードとして指定するホストのシェル・プロンプトでconfigure-serverコマンドを実行します。

たとえば、an.example.comを、ホストadm.example.com上の管理サーバーに登録されているOracle Traffic Director管理ノードとして指定するには、次の操作を実行します。

1. an.example.comシステムからconfigure-serverコマンドを実行します。

$ORACLE_HOME/bin/tadm configure-server --user=admin --host=adm.example.com
--port=8989 --admin-node --node-host=an.example.com --node-port=8900
--instance-home=/home/otd/instances

- ORACLE_HOMEは、管理ノードとして指定するノード上のOracle Traffic Directorインストールを含むディレクトリまたはマウント・ポイントへのパスです。

- --instance-homeオプションでは、ノード上に作成するインスタンス・ディレクトリの格納先となるディレクトリを指定します。

- --admin-nodeオプションでは、指定したホストを管理ノードとして構成することを指定します。

次のメッセージが表示されます。

This command will create an administration node and register it with the remote administration server: https://adm.example.com:8989.
Enter admin-user-password>

2. 管理サーバー・ユーザーのパスワードを入力します。
configure-serverコマンドにより、指定した管理サーバー・ホスト、ポート、ユーザーおよびパスワードを使用してリモート管理サーバーとの接続が試行されます。

注意:
管理サーバーにアクセスできない場合は、次のエラー・メッセージが表示されます。

OTD-70104 Unable to communicate with the administration server:
Unable to connect to admin-server. Please check if the server is
up and running and that the host and port provided are correct.

管理サーバーを起動し、configure-serverコマンドをもう一度実行します。

管理ノードを作成しているホストが初めて管理サーバーに接続しようとしている場合は、管理サーバーのサーバー証明書が表示されます。

3. 「y」を入力して証明書を信頼します。
次のメッセージが表示されます。

OTD-70215 The administration node has been configured successfully.The node can be started by executing: /home/otd/instances/admin-server/bin/startserv

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

管理ノードの起動の詳細は、3.3項「管理ノードの起動」を参照してください。

管理ノードを起動した後、管理ノード上でOracle Traffic Director構成のインスタンスを作成できます。各管理ノード上では構成のインスタンスを1つのみ作成できることに注意してください。

3.2 管理ノードのリストの表示

管理コンソールまたはCLIのいずれかを使用して、管理ノードのリストを表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した管理ノードのリストの表示

管理コンソールを使用して使用可能な管理ノードのリストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
図3-1に示すように、管理サーバーおよびそれに登録されている管理ノードが表示されます。ノードごとに、ノード上でインスタンス化されている構成の名前も表示されます。

図3-1 管理ノードのリスト

管理ノードの設定の詳細を表示するには、ノードをクリックします。

CLIを使用した管理ノードのリストの表示

管理ノードのリストを表示するには、次の例に示すようにlist-nodesコマンドを実行します。

tadm> list-nodes --verbose --all
node-name         node-port  node-online  node-description
----------------------------------------------------------------
adm.example.com    8989       true         "This is the Administration Server node"
an.example.com     8900       false        -

3.3 管理ノードの起動

管理サーバーがリモート管理ノードと通信するには、そのノードが実行されている必要があります。

管理ノードを起動するには、ノード・ホスト上で次のコマンドを実行します:

$INSTANCE_HOME/admin-server/bin/startserv

次のメッセージが表示されます:

Oracle Traffic Director 11.1.1.7.0 B01/14/2013 09:08
[NOTIFICATION:1] [OTD-80118] Using [Java HotSpot(TM) 64-Bit Server VM, Version 1.6.0_29] from [Sun Microsystems Inc.]
[NOTIFICATION:1] [OTD-80000] Loading web module in virtual server [admin-server] at [/jmxconnector]
[NOTIFICATION:1] [OTD-10358] admin-ssl-port: https://an.example.com:8900 ready to accept requests
[NOTIFICATION:1] [OTD-10487] successful server startup

3.4 管理ノードのプロパティの変更

管理コンソールまたはCLIのいずれかを使用して、管理ノードのプロパティを変更できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した管理ノードのプロパティの変更

管理コンソールを使用して管理ノードのプロパティを変更するには、次の操作を行います:

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
使用可能なノードのリストが表示されます。

3. ノードのリストから、プロパティを変更するノードを選択します。
一般設定ページが表示されます。

4. 変更するパラメータを指定してから、「保存」をクリックします。
「コンソール・メッセージ」ペインに、更新した設定が保存されたことを示すメッセージが表示されます。

5. 「共通のタスク」ペインで、「再起動」をクリックして管理サーバーを再起動します。

CLIを使用した管理ノードのプロパティの変更

CLIを使用して管理ノードのプロパティを変更するには、次のコマンドを実行します。

tadm> set-admin-prop --node=node_name (property=value)+

次の例に示すような、空白で区切られた1つ以上のproperty=valueのペアを指定できます。

tadm> set-admin-prop --node=apps.example.com ssl-port=8900 log-level=warning

set-admin-propコマンドを使用して設定できるプロパティの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

注意:
変更を有効にするには、3.5項「管理ノードの停止および再起動」の説明に従い、管理ノードを再起動するがあります。

3.5 管理ノードの停止および再起動

管理コンソール、CLIコマンドまたはシェル・コマンドのいずれかを使用して、管理ノードを停止および再起動できます。

注意:
管理サーバーの停止および再起動の詳細は、2.4項「管理サーバーの停止および再起動」を参照してください。

管理コンソールを使用した管理ノードの停止および再起動

管理コンソールを使用して管理ノードを停止または再起動するには、次の操作を行います:

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
管理サーバーおよびそれに登録されているすべての管理ノードが表示されます。

3. ノードのリストから、停止または再起動するノードを選択します。

4. 「共通のタスク」ペインで、必要に応じて「再起動」または「停止」を選択します。

CLIを使用した管理ノードの停止および再起動

- 管理ノードを停止するには、次のコマンドを実行します。

tadm> stop-admin node_host

次のメッセージが表示されます。

OTD-70201 Command 'stop-admin' ran successfully.

- 管理ノードを再起動するには、次のコマンドを実行します。

tadm> restart-admin node_host

次のメッセージが表示されます。

OTD-70201 Command 'restart-admin' ran successfully.

stop-adminおよびrestart-adminコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

シェル・コマンドを使用した管理ノードの停止および再起動

- シェルから管理ノードを停止するには、次のコマンドを実行します。

$INSTANCE_HOME/admin-server/bin/stopserv

次のメッセージが表示されます。

server has been shutdown

- シェルから管理ノードを再起動するには、次のコマンドを実行します。

$INSTANCE_HOME/admin-server/bin/restart

3.6 管理ノードの削除

管理ノードを削除するには、次の操作を行います:

1. 管理サーバー・ホストから、--forceオプションを付けてremove-nodeコマンドを実行します。

tadm> remove-node --force node_host

ノード上にOracle Traffic Directorインスタンスが存在する場合、--forceオプションを指定しないとremove-nodeコマンドが失敗します。

2. 管理ノード・ホスト上で、次の例のようにunconfigure-serverコマンドを実行します:

$ORACLE_HOME/bin/tadm unconfigure-server --instance-home=home/otd/instances

このコマンドでは、現在管理ノード上にデプロイされているOracle Traffic Directorのすべてのインスタンスを停止して削除し、ホスト上の管理ノード・プロセスを停止します。このホスト上では、もう一度管理ノードとしてホストを指定するまでOracle Traffic Directorインスタンスを作成できなくなります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

第II部

基本的な管理

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

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

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

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

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

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

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

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

4 構成の管理

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

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

この章のトピックは、次のとおりです。

- 構成の作成

- 構成のリストの表示

- 構成のデプロイ

- 構成の変更

- 管理サーバーとノード間の構成の同期化

- 構成のコピー

- 構成の削除

- 構成バックアップのリストの表示

- バックアップからの構成のリストア

4.1 構成の作成

管理コンソールまたはCLIのいずれかを使用して、構成を作成できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

始める前に

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

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

- 構成のOracle Traffic Directorインスタンスの実行に使用されるユーザーID。

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

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

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

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

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

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

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

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

管理コンソールを使用した構成の作成

管理コンソールを使用して構成を作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. 「共通のタスク」ペインで、「新規構成」をクリックします。
新規構成ウィザードが開始されます。

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

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

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

CLIを使用した構成の作成

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

たとえば、次のコマンドでは、soa.example.comという名前の構成が、soa-app.example.com:1905の仮想サーバーとポート、およびsoa-1.example.com:80とsoa-2.example.com:80の2つのオリジン・サーバーで作成されます。

tadm> create-config --listener-port=1905 --server-name=soa-app.example.com
--origin-server=soa-1.example.com:80,soa-2.example.com:80 soa.example.com

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

4.2 構成のリストの表示

管理コンソールまたはCLIのいずれかを使用して、使用可能な構成のリストをいつでも表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した構成のリストの表示

管理コンソールを使用して使用可能な構成のリストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
図4-2に示すように、使用可能な構成のリストが表示されます。

図4-2 構成のリスト

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

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

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

tadm> list-configs --verbose --all
config-name      deployment-status
---------------------------------
soa  deploy-pending
adm  undeployed
dev  deployed
org  instance-modified

デプロイメント・ステータス

構成は、次のいずれかのステータスになります。

- デプロイ済: 構成のインスタンスが1つ以上存在します。すべてのインスタンスの構成設定が更新されています。

- デプロイメント保留中: 構成のインスタンスが1つ以上存在します。ただし、インスタンスの構成設定は最新ではありません。

- アンデプロイ済: 構成にインスタンスが存在しません。

- インスタンス変更済: 構成の1つ以上のインスタンスの設定が手動で変更されています。

4.3 構成のデプロイ

管理ノードで構成のインスタンスを作成する、または以前に作成済のインスタンスを新しい構成設定で更新するには、構成をデプロイします。構成をデプロイすると、実行中のインスタンスが再構成され構成の変更が反映されます。

注意:
特定の構成変更は、インスタンスを再起動せずに動的に適用することはできません。インスタンスの再起動を必要とする構成変更の場合、管理インタフェース(CLIおよび管理コンソール)にはインスタンスを再起動するためのプロンプトが表示されます。

管理コンソールまたはCLIのいずれかを使用して、構成をデプロイできます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した構成のデプロイ

管理コンソールを使用して構成をデプロイするには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. デプロイする構成を選択します。
デプロイするために選択した構成のインスタンスがまだ存在しない場合、メッセージ「アンデプロイ済構成」がメインのペインの上部に表示されます。アンデプロイ済構成の1つ以上のインスタンスを作成する手順は、5.1項「Oracle Traffic Directorインスタンスの作成」を参照してください。

構成のインスタンスが存在するものの、構成設定が最新ではない場合、メッセージ「デプロイメント保留中」がメインのペインの上部に表示されます。最新の構成設定でインスタンスを更新するには、次の操作を行います。

1. 「変更のデプロイ」をクリックします。
デプロイメントを確認するプロンプトが表示されます。

2. 「デプロイ」をクリックします。
更新された構成が正常にデプロイされたことを確認するメッセージが表示されます。

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

CLIを使用した構成のデプロイ

構成をデプロイするには、deploy-configコマンドを実行します。

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

tadm> deploy-config soa.example.com
OTD-70201 Command 'deploy-config' ran successfully.

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

更新された構成をデプロイした後に変更を有効にするには、インスタンスを再起動する必要があります。

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

4.4 構成の変更

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

管理コンソールまたはCLIのいずれかを使用して、構成を変更できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した構成の変更

管理コンソールを使用して構成を変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 変更する構成を選択します。

4. ナビゲーション・ペインで、次のような、構成設定の追加カテゴリを選択できます。選択したカテゴリに関連するパラメータが、メインのペインに表示されます。

- SSL

- PKCS#11トークンの設定。詳細は、11.5項「PKCS#11トークンの管理」を参照してください。

- CRL更新イベントのスケジュール設定および管理。詳細は、11.6.2項「CRLの自動インストール」を参照してください。

- SSL/TLSキャッシュ・プリファレンス。詳細は、15.6.1項「SSL/TLSセッションのキャッシュ」を参照してください。

- ロギング

- サーバー・ログ・ファイル(ログ・ファイルの名前と場所、ログ・レベル、日付書式など)のパラメータを設定し変更します。

- アクセス・ログを有効または無効にします。

- アクセス・ログ・ファイル(ログ・ファイルの名前と場所、ログ形式など)のパラメータを設定し変更します。

- サーバーおよびアクセス・ログ・ファイルをローテーションするイベントをスケジュールし管理します。

- パフォーマンスをチューニングするアクセス・ログ・バッファ設定を構成します。

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

- 詳細設定

- 一般設定(サーバー・ユーザーID、構成のインスタンスのプロセスIDおよびソケット情報が格納される一時ディレクトリ、およびローカリゼーション・プリファレンス)を指定します。

- DNS参照設定およびキャッシュ設定を構成します。
詳細は、15.5項「DNSキャッシュ設定のチューニング」を参照してください。

- 構成のイベントを作成、有効化、無効化、表示および削除します。詳細は、5.6項「スケジュール済のイベントによるOracle Traffic Directorインスタンスの制御」を参照してください。

- 構成の使用可能なバックアップのリストを表示し、バックアップ構成からリストアします。詳細は、4.9項「バックアップからの構成のリストア」を参照してください。

- 「詳細設定」のHTTP: 構成に定義された仮想サーバーのパフォーマンスをチューニングするパラメータ(リクエスト・バッファ・サイズ、レスポンス・バッファ・サイズ、リクエストの本文およびヘッダーのタイムアウトしきい値、スレッド・プール設定およびキープ・アライブ設定)を設定および変更します。
詳細は、15.4項「HTTPリクエストおよびレスポンスの制限のチューニング」を参照してください。

- 「詳細設定」の「監視」

- 統計収集、プロファイリングおよびSNMPサブエージェントを有効化および無効化します。

- 統計収集の間隔を指定します。

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

注意:
オリジン・サーバー、オリジン・サーバー・プール、リスナーおよび仮想サーバーの変更の詳細は、次の項を参照してください。

- 6.3項「オリジン・サーバー・プールの変更」

- 7.3項「オリジン・サーバーの変更」

- 8.3項「仮想サーバーの変更」

- 10.3項「リスナーの変更」

5. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

6. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

注意:
「詳細設定」ページで「一時ディレクトリ」の値を変更した場合、構成のすべてのインスタンスをまず停止して、変更をデプロイし、次にインスタンスを起動します。
実行中のインスタンスを停止せずに変更をデプロイした場合、インスタンスを後で停止しようとしたときにエラーが発生する場合があります。この問題を解決するための詳細は、16.2.8項「一時ディレクトリの変更後にインスタンスを停止できない」を参照してください。

CLIを使用した構成の変更

CLIでは、構成の特定のパラメータの変更に使用できるいくつかのコマンド(表4-1を参照)が用意されています。

注意:
構成内の仮想サーバー、リスナー、オリジン・サーバー・プールおよびオリジン・サーバーのプロパティを変更するCLIコマンドの詳細は、次の章を参照してください。

- 第6章「オリジン・サーバー・プールの管理」

- 第7章「オリジン・サーバーの管理」

- 第8章「仮想サーバーの管理」

- 第10章「リスナーの管理」

表4-1 構成変更用のCLIコマンド

タスク

CLIコマンド

サーバー・ユーザーおよび一時ディレクトリの変更

set-config-prop

アクセス・ログ・バッファ・プロパティの変更

set-access-log-buffer-prop

get-access-log-buffer-prop

キャッシュ・プロパティの変更

set-cache-prop

get-cache-prop

DNSプロパティの変更

set-dns-prop

get-dns-prop

DNSキャッシュ・プロパティの変更

set-dns-cache-prop

get-dns-cache-prop

HTTPリクエスト・プロパティの変更

set-http-prop

get-http-prop

クライアント接続のキープ・アライブ設定の変更

set-keep-alive-prop

get-keep-alive-prop

デフォルト言語の変更

set-localization-prop

get-localization-prop

エラー・ログ設定の変更

set-log-prop

get-log-prop

PKCS #11暗号化設定の変更

set-pkcs11-prop

get-pkcs11-prop

QoS設定の変更

set-qos-prop

get-qos-prop

SNMPの有効化

set-snmp-prop

set-snmp-prop

SSL/TLSセッションのキャッシュ・プロパティの変更

set-ssl-session-cache-prop

get-ssl-session-cache-prop

統計集計プロパティの変更

set-stats-prop

get-stats-prop

HTTPスレッド・プール・プロパティの変更

set-thread-pool-prop

get-thread-pool-prop

たとえば、次のコマンドでは、構成soaのエラー・ログ・ファイルの場所が/home/log/errors.logに変更されます。

tadm> set-log-prop --config=soa log-file=/home/log/errors.log
OTD-70201 Command 'set-log-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

4.5 管理サーバーとノード間の構成の同期化

構成を作成すると、構成ファイル(server.xml、vs_name-obj.conf)が、管理サーバー上の構成ストアに作成されます。

構成のインスタンスを作成すると、次の例に示すように構成ファイルが構成ストアから、ノード上のインスタンス固有の構成ディレクトリにコピーされます。

INSTANCE_HOME/net-soa.example.com/config
INSTANCE_HOME/net-dev.example.com/config

したがって、インスタンス固有の構成ディレクトリ内の構成ファイルは、通常、管理サーバー上の構成ストア内に格納されている構成ファイルと同じです。次の状況では、管理サーバーに格納された構成は、そのインスタンスの構成とは異なる場合があります。

- 管理コンソールまたはCLIを使用して管理サーバーの構成を変更したが、変更した構成をそのインスタンスにデプロイしていません。
4.3項「構成のデプロイ」の説明に従い、構成をデプロイすることで、この同期していない状況を修正できます。

- インスタンスのconfigディレクトリ内の構成ファイルを直接編集し、インスタンスの構成を手動で変更しました。

INSTANCE_HOME/net-config_name/configディレクトリの構成ファイルserver.xmlまたはvs_name-obj.confを編集し、インスタンスの構成を手動で変更する場合、次に管理コンソールにログインし、構成を表示した際、アラート「インスタンス構成変更済」が表示されます。このアラートは、管理サーバーに格納された構成が、1つ以上のインスタンスの現在の構成設定と異なっていることを示します。次のいずれかを実行し、すべてのインスタンスの構成と、管理サーバーに格納されている構成を同期化するまでアラートは表示され続けます。

- 変更されたインスタンスのいずれかの変更済構成をプルして、管理サーバーの構成ストアに戻します。

- 管理サーバーの構成を変更済インスタンスに再デプロイすることで、インスタンス固有の構成を破棄します。

管理コンソールまたはCLIのいずれかを使用して、管理サーバーの構成をそのインスタンスと同期できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した、管理サーバーと管理ノードの構成の同期化

管理コンソールを使用して、管理サーバーに格納された構成をそのインスタンスの構成と同期するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 1つ以上のインスタンスが変更されている構成を選択します。変更済の構成は、ステータス(「インスタンス構成変更済」)で識別できます。
構成の「インスタンス」ページが表示され、そのメイン・ペインの上部には「インスタンス構成変更済」ボタンが表示されます。

4. 「インスタンス構成変更済」ボタンをクリックします。
「構成のデプロイ」ダイアログ・ボックスが表示されます。

- すべてのインスタンス固有の構成を破棄し、管理サーバーに現在格納されている構成をすべてのインスタンスにデプロイする場合、「インスタンスの変更の破棄」オプションを選択します。

- 変更されたインスタンスの構成を管理サーバーにプルする場合、「次のノードから構成をプルしてデプロイする」を選択し、適切な管理ノードを選択します。
各管理ノードで、「詳細の表示」をクリックすることで、管理サーバーの構成ストアとは異なる構成ファイルの名前を確認できます。

5. 「OK」をクリックします。
構成が正常にデプロイされたことを確認するメッセージが表示されます。

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

CLIを使用した、管理サーバーと管理ノードの構成の同期化

すべてのインスタンス固有の構成を破棄し、管理サーバーに現在格納されている構成をすべてのインスタンスにデプロイするには、次のコマンドを選択します。

tadm> deploy-config -- force config_name

インスタンスの構成ファイルを管理サーバーの構成ストアにプルするには、次のコマンドを実行します。

tadm> pull-config --config=config_name node

tadm> deploy-config config_name

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

4.6 構成のコピー

既存の構成に似た構成を作成する場合、既存の構成をコピーし、必要な変更を後から実行できます。

管理コンソールまたはCLIのいずれかを使用して、構成をコピーできます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した構成のコピー

管理コンソールを使用して構成をコピーするには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. コピーする構成を選択します。

4. 「共通のタスク」ペインで、「構成の複製」をクリックします。

5. 結果のダイアログ・ボックスで、新規構成の名前を入力し、「複製」をクリックします。
構成がコピーされたことを確認するメッセージが表示されます。

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

CLIを使用した構成のコピー

構成をコピーするには、copy-configコマンドを実行します。

たとえば、次のコマンドでは、構成soa.example.comがsoa2.example.comという名前の新規構成にコピーされます。

tadm> copy-config --config=soa.example.com soa2.example.com
OTD-70201 Command 'copy-config' ran successfully.

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

4.7 構成の削除

管理コンソールまたはCLIのいずれかを使用して、構成を削除できます。

注意:

- 1つ以上のフェイルオーバー・グループのある構成を削除するには、まずフェイルオーバー・グループを削除する必要があります。詳細は、14.2.4項「フェイルオーバー・グループの管理」を参照してください。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した構成の削除

管理コンソールを使用して構成を削除するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 削除する構成を選択します。

4. 「共通のタスク」ペインで、「構成の削除」をクリックします。

- 削除する構成のインスタンスが存在しない場合、構成の削除を確認するプロンプトが表示されます。

1. 「削除」をクリックします。
構成が削除されたことを確認するメッセージが表示されます。

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

- 削除する構成のインスタンスが存在する場合、構成がデプロイされている管理ノードがリストされたダイアログ・ボックスが表示されます。リストには、インスタンスが実行中であるかどうかも示されます。

1. 削除を続行する場合、「インスタンス・ログの保存」チェック・ボックスを選択することで、インスタンスのログ・ファイルの保存を選択できます。
削除を確認するには、「削除」をクリックします。

構成およびそのインスタンスが削除されたことを確認するメッセージが表示されます。

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

注意:
「インスタンス・ログの保存」チェック・ボックスを選択した場合、削除されたインスタンスのサーバー・アクセスおよびエラー・ログは、INSTANCE_HOME/net-config_name/logsディレクトリに保持されます。

5. 削除する構成に対応する「削除」ボタンをクリックします。

CLIを使用した構成の削除

注意:
インスタンスが実行中か停止中かにかかわらず、構成のインスタンスが管理ノードにデプロイされている場合、CLIを使用して構成を削除できません。
CLIを使用してこのような構成を削除するには、まずそのインスタンスをすべて削除する必要があります。

構成を削除するには、次の例に示すように、delete-configコマンドを実行します。

tadm> delete-config --config=soa.example.com
OTD-70201 Command 'delete-config' ran successfully.

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

4.8 構成バックアップのリストの表示

変更された構成をそのインスタンスに再デプロイする場合、前の構成のバックアップが、管理サーバーの構成ストア内にzipファイルで格納されます。

管理コンソールまたはCLIのいずれかを使用して、構成のバックアップのリストを表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

CLIを使用した構成バックアップのリストの表示

CLIを使用して構成のバックアップのリストを表示するには、次のコマンドを実行します。

tadm> list-backups --config=config_name --verbose --all

list-backupsコマンドの出力の例を次に示します。

backup-id       backup-date
---------------------------
20110712_025354 "Jul 12, 2011 2:53:54 AM"
20110712_024410 "Jul 12, 2011 2:44:10 AM"
20110712_004743 "Jul 12, 2011 12:47:43 AM"
20110711_231826 "Jul 11, 2011 11:18:26 PM

出力の例に示されているとおり、各バックアップ構成には、作成時に自動的に割り当てられる一意のIDがあります。IDは、バックアップが作成された日時を示します。

管理コンソールを使用した構成バックアップのリストの表示

管理コンソールを使用して構成のバックアップのリストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. バックアップのリストを表示する構成を選択します。

4. ナビゲーション・ペインで、「構成設定」を展開し、「バックアップ」を選択します。
「構成のバックアップ」ページが表示されます。構成のバックアップが作成された日付がリストされます。

4.9 バックアップからの構成のリストア

変更された構成をそのインスタンスに再デプロイする場合、前の構成のバックアップが作成されます。使用可能なバックアップのリストの表示の詳細は、4.8項「構成バックアップ・リストの表示」を参照してください。

管理コンソールまたはCLIのいずれかを使用して、バックアップから構成をリストアできます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したバックアップからの構成のリストア

管理コンソールを使用してバックアップから構成をリストアするには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. バックアップのリストを表示する構成を選択します。

4. ナビゲーション・ペインで、「詳細設定」を選択します。
「詳細設定」ページが表示されます。

5. ページの「構成のバックアップ」セクションにスクロール・ダウンします。

6. リストアするバックアップを特定し、「リストア」列に表示されているアイコンをクリックします。

CLIを使用したバックアップからの構成のリストア

CLIを使用してバックアップから構成をリストアするには、次のコマンドを実行します。

tadm> restore-config --config=config_name --verbose --all

5 インスタンスの管理

インスタンスは、管理ノードまたは管理サーバーで実行中であり、クライアントからのリクエストを1つ以上のポートでリスニングしているOracle Traffic Directorサーバーを指します。

この章には次の項が含まれます:

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

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

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

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

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

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

5.1 Oracle Traffic Directorインスタンスの作成

管理コンソールまたはCLIのいずれかを使用して、Oracle Traffic Directorインスタンスを作成できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

Oracle Traffic Directorインスタンスの作成の前提条件

インスタンスを作成できるようにするには、次の操作を完了しておく必要があります。

- 構成の定義(4.1項「構成の作成」を参照)。

- 1つ以上の管理ノードの作成(3.1項「管理ノードの作成」を参照)。管理サーバーにもインスタンスを作成できることに注意してください。

管理コンソールを使用したOracle Traffic Directorインスタンスの作成

管理コンソールを使用して、Oracle Traffic Directorインスタンスを作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. インスタンスを作成する構成を選択します。

4. 「共通のタスク」ペインで、「新規インスタンス」をクリックします。
新規インスタンス・ウィザードが表示されます。ウィザードに、使用可能な管理ノードがリストされます。

注意:

- 使用可能な管理ノードとしてホストがリストされるようにするには、3.1項「管理ノードの作成」の説明に従い、ホストを管理ノードとして指定する必要があります。

- 管理ノードでは、特定の構成の1つのインスタンスのみを作成できます。したがって、デプロイしようとしている構成のインスタンスが管理ノードにすでに存在する場合、ノードは表示されません。

5. 構成のインスタンスを作成する必要がある管理ノードに対応するチェック・ボックスを選択します。次に、「次」をクリックします。

6. ウィザードの結果画面で、選択した管理ノードのリストを確認します。次に、「インスタンスの作成」をクリックします。
インスタンスの作成が正常に完了したことを確認するメッセージが表示されます。

7. 「閉じる」をクリックします。
作成したインスタンスを含む「インスタンス」ページが表示されます。

CLIを使用したOracle Traffic Directorインスタンスの作成

Oracle Traffic Directorインスタンスを1つ以上作成するには、create-instanceコマンドを実行します。

たとえば、次のコマンドを実行すると、各ノードapps2およびapps2にsoaという名前の構成のインスタンスが作成されます。

tadm> create-instance --config=soa apps1 apps2
OTD-70201 Command 'create-instance' ran successfully.

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

管理ノードでインスタンス化する各Oracle Traffic Director構成について、net-config_nameという名前のサブディレクトリがINSTANCE_HOMEサブディレクトリ内に作成されます。

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

管理コンソールまたはCLIのいずれかを使用して、Oracle Traffic Directorインスタンスのリストを表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したOracle Traffic Directorインスタンスのリストの表示

管理コンソールを使用してOracle Traffic Directorのリストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. インスタンスを表示する構成を選択します。
図5-1に示すように、構成のインスタンスを示す「インスタンス」ページが表示されます。

図5-1 インスタンスのリスト

名前をクリックすると、インスタンスのプロパティを表示できます。

CLIを使用したOracle Traffic Directorインスタンスのリストの表示

構成のOracle Traffic Directorインスタンスのリストを表示するには、次の例に示すようにlist-instancesコマンドを実行します。

tadm> list-instances --config=soa.example.com --verbose --all

node-name            instance-status   has-service
--------------------------------------------------
soa.example.com      started           false
adf.example.com      stopped           false

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

管理コンソールまたはCLIのいずれかを使用して、Oracle Traffic Directorインスタンスを起動、停止および再起動できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したOracle Traffic Directorインスタンスの起動、停止および再起動

管理コンソールを使用してOracle Traffic Directorインスタンスを起動、停止または再起動するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. インスタンスを起動、停止または再起動する構成を選択します。

4. ナビゲーション・ペインで、「インスタンス」を選択します。

5. 起動、再起動または停止するインスタンスをについて、必要に応じて、「起動/再起動」または「停止」ボタンをクリックします。

注意:
選択した構成のすべてのインスタンスを起動または再起動するには、「共通のタスク」ペインの「インスタンスの起動/再起動」をクリックします。構成のすべてのインスタンスを停止するには、「インスタンスの停止」をクリックします。

6. 証明書データベースへのインタフェースを提供するPKCS#11トークンがPINで保護されている場合(11.5項「PKCS#11トークンの管理」を参照)、「起動/再起動」または「インスタンスの起動/再起動」をクリックすると、トークンPINを入力するプロンプトが表示されます。インスタンスの起動を続行するには、PINで保護されているトークンのPINを入力する必要があります。
「コンソール・メッセージ」ペインに、インスタンスが起動、停止または再起動されたことを確認するメッセージが表示されます。

CLIを使用したOracle Traffic Directorインスタンスの起動、停止および再起動

構成のOracle Traffic Directorインスタンスを1つ以上起動、停止または再起動するには、start-instance、stop-instanceまたはrestart-instanceコマンドを実行します。

たとえば、次の3つのコマンドを実行すると、ノードapps1.example.comおよびapps2.example.comの構成soaのインスタンスが起動、再起動および停止されます。

tadm> start-instance --config=soa apps1.example.com apps2.example.com

tadm> restart-instance --config=soa apps1.example.com apps2.example.com

tadm> stop-instance --config=soa apps1.example.com apps2.example.com

証明書データベースへのインタフェースを提供するPKCS#11トークンがPINで保護されている場合(11.5項「PKCS#11トークンの管理」を参照)、start-instanceを実行すると、次の例に示すように、トークンPINを入力するプロンプトが表示されます。

Enter password for token "internal">

インスタンスの起動を続行するには、PINを入力する必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

注意:
または、インスタンス・ディレクトリ内から次のコマンドを使用して、インスタンスを起動、再起動および停止できます。

> $INSTANCE_HOME/net-config_name/bin/startserv

> $INSTANCE_HOME/net-config_name/bin/restart

> $INSTANCE_HOME/net-config_name/bin/stopserv

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

構成パラメータの中には、変更しても構成の変更を有効にするために実行中の構成のOracle Traffic Directorインスタンスを再起動する必要のないものもあります。Oracle Traffic Directorインスタンスを動的に再構成して、新しい構成を反映できます。

動的構成をサポートするパラメータのリストは、『Oracle Traffic Director構成ファイル・リファレンス』の動的再構成に関する項を参照してください。

管理コンソールまたはCLIのいずれかを使用して、実行中の構成のインスタンスを動的に再構成できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したOracle Traffic Directorインスタンスの再構成

管理コンソールを使用してOracle Traffic Directorインスタンスを再構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. インスタンスを再構成する構成を選択します。

4. ナビゲーション・ペインで、「インスタンス」を選択します。

5. 動的に更新するインスタンスの「再構成」ボタンをクリックします。
「コンソール・メッセージ」ペインにインスタンスが再構成されたことを確認するメッセージが表示されます。

CLIを使用したOracle Traffic Directorインスタンスの再構成

構成のOracle Traffic Directorインスタンスを1つ以上再構成するには、reconfig-instanceコマンドを実行します。

たとえば、次のコマンドを実行すると、ノードapps1およびapps2の構成soaのインスタンスが再構成されます。

tadm> reconfig-instance --config=soa apps1 apps2

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

注意:
または、インスタンス・ディレクトリ内から次のコマンドを使用できます。

> $INSTANCE_HOME/net-config_name/bin/reconfig

5.5 Oracle Traffic Directorインスタンスの削除

管理コンソールまたはCLIのいずれかを使用して、構成のインスタンスを削除できます。

管理コンソールを使用したOracle Traffic Directorインスタンスの削除

管理コンソールを使用してOracle Traffic Directorインスタンスを削除するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. インスタンスを削除する構成を選択します。

4. ナビゲーション・ペインで、「インスタンス」を選択します。

5. 削除するインスタンスの「削除」ボタンをクリックします。

注意:
フェイルオーバー・グループの一部であるインスタンスを削除するには、まずフェイルオーバー・グループからインスタンスを削除する必要があります。詳細は、14.2.4項「フェイルオーバー・グループの管理」を参照してください。

「コンソール・メッセージ」ペインに、インスタンスが削除されたことを確認するメッセージが表示されます。

CLIを使用したOracle Traffic Directorインスタンスの削除

構成のOracle Traffic Directorインスタンスを1つ以上削除するには、delete-instanceコマンドを実行します。

たとえば、次のコマンドを実行すると、ノードapps1およびapps2で実行中の構成soaのインスタンスが削除されます。

tadm> delete-instance --config=soa apps1 apps2

注意:
--forceオプションを使用して、フェイルオーバー・グループの一部であるインスタンスを削除することはできますが、これを行うとインスタンスが属しているすべてのフェイルオーバー・グループも削除されます。

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

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

管理者として、多数の構成およびインスタンスを管理する必要がある場合、各構成のインスタンスを個別に再起動および再構成するなどの反復的なタスクは単調な作業になりがちです。管理タスクを、定義した間隔、つまり特定の曜日、時間または日付で自動実行するようにイベントをスケジュールできます。

管理コンソールまたはCLIのいずれかを使用して、イベントを作成および管理できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したイベントの管理

管理コンソールを使用してイベントを管理するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. イベントをスケジュールする構成を選択します。

4. ナビゲーション・ペインで、「詳細設定」を選択します。
「詳細設定」ページが表示されます。

5. ページの「予定イベント」セクションにスクロール・ダウンします。
ここには、構成に現在スケジュールされているイベントがリストされます。

- イベントを有効または無効にするには、「有効化/無効化」チェック・ボックスを選択します。

- イベントを削除するには、「削除」アイコンをクリックします。

- イベントを作成するには、「新規イベント」をクリックします。
「新規構成イベント」ダイアログ・ボックスが表示されます。

スケジュールを設定するイベントを選択し、イベントの実行間隔または時刻を指定し、「OK」をクリックします。

変更を確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したイベントの管理

- イベントの作成
イベントを作成するには、次の例に示すように、create-eventコマンドを実行します。

tadm> create-event --config=soa --command=restart --interval=86400
tadm> create-event --config=soa --command=reconfigure --time=14:00

1番目のコマンドでは、86400秒後に構成soaのすべてのインスタンスを再起動するイベントがスケジュールされます。

2番目のコマンドでは、毎日午後2時に構成soaのすべてのインスタンスを再構成するイベントがスケジュールされます。

注意:
スケジュールされたイベントを有効にするには、構成を再デプロイする必要があります。

- イベントのリストの表示
スケジュールされたイベントのリストを表示するには、list-eventsコマンドを実行します。

たとえば、次のコマンドでは、構成soaのインスタンスにスケジュールされたイベントが表示されます。

tadm> list-events --config=soa --verbose --all
command        enabled    day-of-month   month   day-of-week   time    interval
-------------------------------------------------------------------------------
restart        false      -              -       -             -       60
reconfig       true       -              -       -             -       60

- イベントの無効化
イベントの作成時、--no-enabledオプションを指定しない限り、イベントは自動的に有効化されます。

イベントを無効化にするには、次の例に示すように、disable-eventコマンドを実行します。

tadm> disable-event --config=soa --command=restart --interval=86400

- イベントの有効化
イベントを有効化にするには、次の例に示すように、enable-eventコマンドを実行します。

tadm> enable-event --config=soa --command=restart --interval=86400

- イベントの削除
イベントを削除するには、次の例に示すように、delete-eventコマンドを実行します。

tadm> delete-event --config=soa --command=restart --interval=86400

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

オリジン・サーバーは、バックエンドのサーバーであり、Oracle Traffic Directorはクライアントから受信したリクエストをこのサーバーに転送し、クライアント・リクエストに対するレスポンスをこのサーバーから受信します。たとえば、オリジン・サーバーには、Oracle WebLogic ServerインスタンスまたはOracle iPlanet Web Serverインスタンスなどが該当します。同じサービスを提供する、または同じコンテンツを提供するオリジン・サーバーのグループは、オリジン・サーバー・プールと呼ばれます。このようなオリジン・サーバー・プールを構成内にいくつか定義し、特定のプールにクライアント・リクエストをルーティングするようにOracle Traffic Directorインスタンス内に各仮想サーバーを構成できます。

この章では、オリジン・サーバー・プールを作成および管理する方法を説明します。ここの内容は、次のとおりです。

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

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

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

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

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

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

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

管理コンソールまたはCLIのいずれかを使用して、オリジン・サーバー・プールを作成できます。

注意:

- オリジン・サーバー・プールを作成すると、実質的には構成が変更されます。新しいオリジン・サーバー・プールの設定をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

始める前に

オリジン・サーバー・プールの作成を開始する前に、次の項目を決定します。

- オリジン・サーバー・プールの一意の名前。オリジン・サーバー・プールを作成した後は名前を変更できないため、名前は慎重に選択してください。

- オリジン・サーバー・プール内のサーバーのhost:portの組合せ。

注意:
プールを作成するオリジン・サーバーが、クラスタ内のOracle WebLogic Server管理対象サーバーの場合、管理対象サーバーのいずれか1つをオリジン・サーバーとして使用してプールを作成すれば十分です。その後、プール内のその他の管理対象サーバーを動的に検出するようにOracle Traffic Directorを構成することができます。詳細は、6.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。

- プール内のサーバーの通信プロトコル(HTTP、HTTPSまたは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デプロイメント・ガイドのクラスタレベルのセッション・レプリケーション強化の有効化に関する項を参照してください。

管理コンソールを使用したオリジン・サーバー・プールの作成

管理コンソールを使用してオリジン・サーバー・プールを作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 仮想サーバーを作成する構成を選択します。

4. 「共通のタスク」ペインで、新規オリジン・サーバー・プールをクリックします。
新規オリジン・サーバー・プール・ウィザードが起動されます。

図6-1 新規オリジン・サーバー・プール・ウィザード

5. 画面上のプロンプトに従い、前に決定済の詳細(名前、ロード・バランシング・メソッド、オリジン・サーバーなど)を使用して、オリジン・サーバー・プールの作成を完了します。
オリジン・サーバー・プールが作成された後、新規オリジン・サーバー・プール・ウィザードの「結果」画面にオリジン・サーバー・プールの作成が成功したことを示すメッセージが表示されます。

6. 結果画面で、「閉じる」をクリックします。

- 作成したオリジン・サーバー・プールの詳細が、「オリジン・サーバー・プール」ページに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したオリジン・サーバー・プールの作成

オリジン・サーバー・プールを作成するには、create-origin-server-poolコマンドを実行します。

たとえば、次のコマンドでは、構成soaに2つのオリジン・サーバーhttp://soa.example.com:1901およびhttp://soa.example.com:1902を含むオリジン・サーバー・プールosp-soaが作成されます。

tadm> create-origin-server-pool --config=soa --type=http --origin-server=soa.example.com:1901,soa.example.com:1902 osp-soa
OTD-70201 Command 'create-origin-server-pool' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

HTTP転送プロキシ・サーバーの指定

create-origin-server-poolコマンドは、オリジン・サーバー・プールに関連付けるようにHTTP転送プロキシ・サーバーを指定するのに使用する任意のオプションとしてproxy-serverを受け取るため、プールのすべてのメンバー・オリジン・サーバーは構成済転送プロキシ・サーバーを通じて通信されます。タイプは、httpまたはhttpsである必要があります。

次に例を示します。

tadm> create-origin-server-pool --config=soa --type=http --origin-server=soa.example.com:1901,soa.example.com:1902 osp-soa --proxy-server=www.example.com
OTD-70201 Command 'create-origin-server-pool' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

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

管理コンソールまたはCLIのいずれかを使用して、オリジン・サーバー・プールのリストを表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したオリジン・サーバー・プール・リストの表示

管理コンソールを使用してオリジン・サーバー・プール・リストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. オリジン・サーバー・プールを表示する構成を選択します。

4. ナビゲーション・ペインで、「オリジン・サーバー・プール」を選択します。
「オリジン・サーバー・プール」ページが表示されます。構成に定義されたオリジン・サーバー・プールのリストが表示されます。

名前をクリックすると、オリジン・サーバー・プールのプロパティの詳細を表示できます。

CLIを使用したオリジン・サーバー・プール・リストの表示

オリジン・サーバー・プールのリストを表示するには、次の例に示すようにlist-origin-server-poolsコマンドを実行します。

tadm> list-origin-server-pools --config=soa --verbose --all
name            type            load-distribution
-------------------------------------------------
osp1            http            least-connection-count
osp2            http            round robin
osp3            https           least-connection-count

get-origin-server-pool-propおよびget-health-check-propコマンドをそれぞれ実行して、オリジン・サーバー・プールの一般的なプロパティおよびヘルス・チェックの設定を表示できます。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

管理コンソールまたはCLIのいずれかを使用して、オリジン・サーバー・プールのプロパティを変更できます。

注意:

- オリジン・サーバー・プールを変更すると、実質的には構成が変更されます。更新したオリジン・サーバー・プールの設定をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したオリジン・サーバー・プールのプロパティの変更

管理コンソールを使用してオリジン・サーバー・プールのプロパティを変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. オリジン・サーバー・プールを変更する構成を選択します。

4. ナビゲーション・ペインで、「サーバー・プール」を選択します。
「オリジン・サーバー・プール」ページが表示されます。構成に定義されたオリジン・サーバー・プールのリストが表示されます。

5. 変更するオリジン・サーバー・プールの名前をクリックします。
オリジン・サーバー・プール設定ページが表示されます。このページで、次の処理が可能です。

- プール内のサーバーのネットワーク・プロトコル(IPv4、IPv6またはSDP)の変更。

- プロキシ・サーバーを通じたオリジン・サーバーへの接続に関する項に従ってプロキシ・サーバーを設定します。この設定は、HTTP転送プロキシ・サーバーをオリジン・サーバー・プールへ関連付けるように指定するため、プールのすべてのメンバー・オリジン・サーバーは構成済HTTP転送プロキシ・サーバーを通じて通信されます。

- Oracle Traffic Directorがクライアント・リクエストをプールに分散する際に使用するロード・バランシング方法の変更。

- 最小接続件数(デフォルト): リクエストの処理時、Oracle Traffic Directorは、各オリジン・サーバーで現在アクティブである接続数を評価し、アクティブな接続数が最も少ないオリジン・サーバーにリクエストを転送します。
最小接続件数メソッドは、より処理の速いオリジン・サーバーに少ないアクティブ接続数しかなく、そのため、より多くの負荷をかけられるという前提の場合に機能します。ロード分散をオリジン・サーバーの容量に基づいてより詳細に調整するには、相対的な重みをオリジン・サーバーに割当てできます。

注意:
WebSocket接続は長期にわたって存続する可能性があり、接続が閉じられるまではアクティブの接続としてカウントされます。そのため、最小接続件数によるロード・バランシング・アルゴリズムに影響することがあります。

- 最小レスポンス時間: ほとんどのワークロードは最小接続件数で効率よく処理できますが、同量のワークロードに対するレスポンス時間が、指定されたプール内の各オリジン・サーバーによって異なるケースも考えられます。次に例を示します。

- 指定されたプール内のオリジン・サーバーがハードウェア仕様の異なるマシンにそれぞれデプロイされている場合。

- 一部のオリジン・サーバー・ノードが他のサービスで使用されている場合。

- ネットワーク接続性が各ノードで異なる場合、または一部のネットワーク・インタフェースに他のインタフェースよりも高い負荷がかかっている場合。

このような状況では最小レスポンス時間の使用が効果的です。これは動的な重み付け最小接続アルゴリズムであり、重みはレスポンス時間に基づいて計算されます。これらの重みはオリジン・サーバーのレスポンス状況に応じて常に調整されます。最小レスポンス時間では、最小接続アルゴリズムで必要な手動の重み調整が不要です。

- ラウンド・ロビン: Oracle Traffic Directorは、1番目のリクエストをプール内の1番目のオリジン・サーバーに、2番目のリクエストを次のオリジン・サーバーというように、使用可能なオリジン・サーバーにリクエストを順次転送します。プール内の最後のオリジン・サーバーにリクエストが送信された後、最初のオリジン・サーバーから再び始まります。
ラウンド・ロビン・メソッドは、単純で予測可能であり、処理のオーバーヘッドが少なくて済みますが、オリジン・サーバーの能力の差が無視されます。このため、時間の経過とともに、特に処理速度が遅いオリジン・サーバーにリクエストが累積する可能性があります。この問題を解決するには、相対的な重みをオリジン・サーバーに割り当て、重み付けされたラウンド・ロビン・メソッドを使用できます。

オリジン・サーバーへの重みの割当ての詳細は、7.3項「オリジン・サーバーの変更」を参照してください。

- ヘルス・チェック設定の構成。詳細は、14.3項「オリジン・サーバー・プールのヘルス・チェック設定の構成」を参照してください。

- Oracle Traffic Directorが、クラスタ内のOracle WebLogic Server管理対象サーバーを自動検出するかどうかの指定。詳細は、6.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。

注意:
プール内のオリジン・サーバーの追加、変更および削除は、ナビゲーション・ペインで「オリジン・サーバー」を選択することで実行できます。詳細は、第7章「オリジン・サーバーの管理」を参照してください。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したオリジン・サーバー・プールのプロパティの変更

- オリジン・サーバー・プールのネットワーク・プロトコルおよびロード・バランシング・メソッドを変更するには、set-origin-server-pool-propコマンドを実行します。
たとえば、次のコマンドを実行すると、構成soaのオリジン・サーバー・プールosp1のロード・バランシング・メソッドがラウンド・ロビン・メソッドに変更されます。

tadm> set-origin-server-pool-prop --config=soa --origin-server-pool=osp1 load-distribution=round-robin
OTD-70201 Command 'set-origin-server-pool-prop' ran successfully.

- オリジン・サーバー・プールのヘルス・チェック・パラメータを変更するには、set-health-check-propコマンドを実行します。
たとえば、次のコマンドを実行すると、構成soaのオリジン・サーバー・プールosp1のサーバーに対するヘルス・チェックping間隔が60秒に変更されます。

tadm> set-health-check-prop --config=soa --origin-server-pool=osp1 interval=60
OTD-70201 Command 'set-origin-server-pool-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

set-origin-server-pool-propおよびset-health-check-propコマンドを使用して設定または変更できるプロパティ・リストの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

管理コンソールまたはCLIのいずれかを使用して、オリジン・サーバー・プールを削除できます。

注意:

- 仮想サーバーの1つ以上のルートに関連付けられているオリジン・サーバー・プールは削除できません。
ルートに関連付けられているオリジン・サーバー・プールを削除するには、8.4項「ルートの構成」の説明に従い、そのルートをまず削除する必要があります。

- オリジン・サーバー・プールを作成すると、実質的には構成が削除されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したオリジン・サーバー・プールの削除

管理コンソールを使用してオリジン・サーバー・プールを削除するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. オリジン・サーバー・プールを変更する構成を削除します。

4. ナビゲーション・ペインで、「オリジン・サーバー・プール」を選択します。
「オリジン・サーバー・プール」ページが表示されます。

5. 削除するオリジン・サーバー・プールの「削除」アイコンをクリックします。

- オリジン・サーバー・プールが仮想サーバーの1つ以上のルートに関連付けられている場合、プールを削除できないことを示すメッセージが表示されます。

- オリジン・サーバー・プールが仮想サーバーに関連付けられていない場合、削除を確認するプロンプトが表示されます。

6. 「OK」をクリックします。
「コンソール・メッセージ」ペインに、オリジン・サーバー・プールが削除されたことを確認するメッセージが表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したオリジン・サーバー・プールの削除

オリジン・サーバー・プールを削除するには、次の例に示すように、delete-origin-server-poolコマンドを実行します。

tadm> delete-origin-server-pool --config=soa osp1
OTD-70201 Command 'delete-origin-server-pool' ran successfully.

注意:
指定したオリジン・サーバー・プールが仮想サーバーの1つ以上のルートに関連付けられている場合、次のエラー・メッセージが表示されます。

OTD-67108 Cannot delete the origin-server pool. It is referred by virtual server(s): vs1_name,vs1_name,[...]

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

6.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は、指定された間隔でヘルス・チェック・リクエストを送信するため、多少のオーバーヘッドが発生します。

6.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)です。詳細は、14.3項「オリジン・サーバー・プールのヘルス・チェック設定の構成」を参照してください。

6.5.2 動的検出の有効化

オリジン・サーバー・プールの作成時、クラスタ内のOracle WebLogic Server管理対象サーバーの動的検出は、デフォルトでは有効化されません。管理コンソールまたはCLIのいずれかを使用して、動的検出を有効化できます。

注意:

- オリジン・サーバー・プールを変更すると、実質的には構成が変更されます。更新したオリジン・サーバー・プールの設定をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した動的検出の有効化

管理コンソールを使用して、クラスタ内のWebLogic Server管理対象サーバーの動的検出を有効化するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 動的検出を有効化する構成を選択します。

4. ナビゲーション・ペインで、「サーバー・プール」を展開し、動的検出を有効化するオリジン・サーバー・プールを選択します。
「サーバー・プール設定」ページが表示されます。

5. ページの「詳細設定」セクションに移動します。

6. 「ヘルス・チェック」サブセクションで、「プロトコル」がHTTPであることを確認し、「動的検出」チェック・ボックスを選択します。

7. 「保存」をクリックします。

注意:
現在のヘルス・チェック・プロトコルがTCPの場合、動的検出を有効化するために、プロトコルをHTTPに変更する必要があることを示すエラー・メッセージが表示されます。

「コンソール・メッセージ」ペインに、更新されたヘルス・チェック設定が保存されたことを確認するメッセージが表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用した動的検出の有効化

クラスタ内のOracle WebLogic Server管理対象サーバーの動的検出を有効化するには、set-health-check-propコマンドを実行します。

たとえば、次のコマンドでは、wls-1オリジン・サーバー・プールであるOracle WebLogic Serverクラスタの管理対象サーバーの動的検出が有効化されます。

tadm> set-health-check-prop --config=soa.example.com --origin-server-pool=wls-1 dynamic-server-discovery=true
OTD-70201 Command 'set-health-check-prop' ran successfully.

注意:
現在のヘルス・チェック・プロトコルがTCPの場合、動的検出を有効化するために、プロトコルをHTTPに変更する必要があることを示すエラー・メッセージが表示されます。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

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

Oracle Traffic Directorは、すべてのバックエンド・サーバーがオフラインであることが検出された際に、カスタム・サーバー・プール・メンテナンス・レスポンス・コードおよびHTMLページを提供できます。メッセージのこのタイプを表示させることは、ゲートウェイがタイムアウトしたり、ホストの静的コンテンツに対して別のリソースを作成したりするより適切です。

オリジン・サーバー・プールのメンテナンスが有効化されている場合、次のようになります。

- response-codeとresponse-fileの両方が構成されていない場合、ランディングするリクエストは503レスポンス・コードで中断されます。

- response-codeのみが構成されている場合、ランディングするリクエストはresponse-code値をレスポンス・コードとして中断されます。

- 両方が指定されている場合、ランディングするリクエストは中断されず、response-fileコンテンツおよびresponse-code値をレスポンス・コードとして応答します。

- オリジン・サーバーのヘルス・チェックの実行は無効化されます。

オリジン・サーバー・プールのメンテナンスが無効だが、オリジン・サーバーが構成されていなく、有効にもなっていない場合、次のようになります。

- ランディングするリクエストは503レスポンス・コードで中断されます。

- オリジン・サーバーのヘルス・チェックの実行は無効化されます。

メンテナンスでのオリジン・サーバー・プールの統計の監視

オリジン・サーバー・プールがメンテナンス状態の場合、オリジン・サーバー・プールの統計およびプールに属するオリジン・サーバーの統計もありません。統計はアクティブ・オリジン・サーバー・プールおよびアクティブ・オリジン・サーバーに対してのみ有効になります。

CLIを使用したオリジン・サーバー・プールのメンテナンスの有効化または無効化

オリジン・サーバー・プールのメンテナンスを有効にするには、enable-maintenanceコマンドを実行します。

たとえば、次のコマンドはhttp-pool-1オリジン・サーバー・プールのメンテナンスを有効にし、505のレスポンス・コードを指定します。このコマンドはresponse-codeとresponse-fileをオプションのプロパティとして使用します。200のresponse-codeはresponse-fileなしでは指定できません。

tadm> enable-maintenance --config=test --origin-server-pool=http-pool-1 --response-code=505

メンテナンスを無効にするには、disable-maintenanceコマンドを使用します。

tadm> disable-maintenance --config=test --origin-server-pool=http-pool-1

有効化したオリジン・サーバー・プールのresponse-fileプロパティおよびresponse-codeプロパティを戻すには、get-maintenance-propコマンドを使用します。

tadm> get-maintenance-prop --config=test --origin-server-pool=http-pool-1

enable-maintenance、disable-maintenanceおよびget-maintenance-propの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションでコマンドを実行します。

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

オリジン・サーバーは、バックエンドのサーバーであり、Oracle Traffic Directorはクライアントから受信したリクエストをこのサーバーに転送し、クライアント・リクエストに対するレスポンスをこのサーバーから受信します。たとえば、オリジン・サーバーには、Oracle WebLogic ServerインスタンスまたはOracle iPlanet Web Serverインスタンスなどが該当します。同じサービスを提供するオリジン・サーバーのグループは、オリジン・サーバー・プールと呼ばれます。

この章では、オリジン・サーバーを作成および管理する方法を説明します。ここの内容は、次のとおりです。

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

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

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

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

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

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

管理コンソールまたはCLIのいずれかを使用して、オリジン・サーバー・プールにオリジン・サーバーを追加できます。

注意:

- オリジン・サーバーをプールに追加すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

始める前に

オリジン・サーバーを追加する前に、次の項目を決定します。

- オリジン・サーバーを追加するオリジン・サーバー・プール。

- オリジン・サーバーのホスト名または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にそれぞれ分散されます。

管理コンソールを使用したプールへのオリジン・サーバーの追加

管理コンソールを使用して、プールにオリジン・サーバーを追加するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. オリジン・サーバーを作成する構成を選択します。

4. 「共通のタスク」ペインで、「新規オリジン・サーバー」をクリックします。
新規オリジン・サーバー・ウィザードが開始されます。

図7-1 新規オリジン・サーバー・ウィザード

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

6. 結果画面で、「閉じる」をクリックします。

- 定義したオリジン・サーバーの詳細は、「オリジン・サーバー」ページに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したプールへのオリジン・サーバーの追加

プールにオリジン・サーバーを追加するには、create-origin-serverコマンドを実行します。

たとえば、次のコマンドでは、soa-app.example.com:80が、構成soaのプールosp1にオリジン・サーバーos1として追加されます。

tadm> create-origin-server --config=soa --origin-server-pool=osp1 soa-app.example.com:80
OTD-70201 Command 'create-origin-server' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

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

管理コンソールまたはCLIのいずれかを使用して、オリジン・サーバーのリストを表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したオリジン・サーバー・リストの表示

管理コンソールを使用してオリジン・サーバー・リストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. オリジン・サーバーを表示する構成を選択します。

4. ナビゲーション・ペインで、「オリジン・サーバー・プール」を展開し、「オリジン・サーバー」を選択します。
「オリジナル・サーバー」ページが表示されます。選択したプール内のオリジン・サーバーのリストが表示されます。

名前をクリックすると、オリジン・サーバーのプロパティを表示および編集できます。

CLIを使用したオリジン・サーバー・リストの表示

オリジン・サーバー・リストを表示するには、次の例に示すようにlist-origin-serversコマンドを実行します。

tadm> list-origin-servers --config=soa --origin-server-pool=osp1 --verbose --all
name                      weight          enabled         backup
----------------------------------------------------------------
soa-app1.example.com:80   1               true            false
soa-app2.example.com:80   1               true            false
soa-app3.example.com:80   1               true            true

get-origin-server-propコマンドを実行することで、オリジン・サーバーのプロパティの詳細を表示できます。

list-origin-serversおよびget-origin-server-propコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

7.3 オリジン・サーバーの変更

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

- オリジン・サーバーの作成時に定義したプロパティ(ホスト、ポート、重みなど)の変更。プロパティの詳細は、「始める前に」の項を参照してください。

- オリジン・サーバーの有効化または無効化。

- オリジン・サーバーが同時に処理することができる、最大接続数の指定。

- Oracle Traffic Directorがオリジン・サーバーへのリクエスト送信レートを上げていく時間(ランプアップ時間)の指定。このパラメータを使用して、オフライン後起動したばかりのオリジン・サーバーで、リクエスト・ロードをサーバーの容量まで徐々に上げることができます。

管理コンソールまたはCLIのいずれかを使用して、オリジン・サーバーのプロパティを変更できます。

注意:

- プール内のオリジン・サーバーのプロパティを変更すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したオリジン・サーバーのプロパティの変更

管理コンソールを使用してオリジン・サーバーのプロパティを変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. オリジン・サーバーを変更する構成を選択します。

4. ナビゲーション・ペインで、「オリジン・サーバー・プール」を展開し、「オリジン・サーバー」を選択します。
「オリジナル・サーバー」ページが表示されます。

5. 変更するオリジン・サーバーの名前をクリックします。
「オリジン・サーバーの編集」ダイアログ・ボックスが表示されます。このダイアログ・ボックスでは、次の処理が可能です。

- オリジン・サーバーの有効化および無効化

- ホストおよびポートの変更

- 相対的な重みの変更

- バックアップ・サーバーとしてのオリジン・サーバーのマーク付け

- オリジン・サーバーが同時に処理することができる、最大接続数の設定。

- Oracle Traffic Directorがリクエスト転送レートをオリジン・サーバーの最大容量までランプアップするまでに要する時間の指定。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したオリジン・サーバーのプロパティの変更

オリジン・サーバーのプロパティを変更するには、set-origin-server-propコマンドを実行します。

たとえば、次のコマンドでは、構成soaのプールosp1内のオリジン・サーバーsoa-app1.example.com:1900に対して、相対的な重みが2に変更されます。

tadm> set-origin-server-prop  --config=soa --origin-server-pool=osp1
--origin-server=soa-app1.example.com:1900 weight=2
OTD-70201 Command 'set-origin-server-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

set-origin-server-propを使用して変更できるプロパティのリストは、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

OTDおよびOracle WebLogic Server (WLS)のクライアントを含むトポロジでは、OTDは構成済HTTPリスナー・ポートで外部リクエストを受け取ります。次に、OTDは別の接続を開き、WLS/オリジン・サーバーに対してリクエストを送信し、プロキシします。

この接続の一部として、OTDはWLS/オリジン・サーバーがOTDにデータを送信して戻せるようにエフェメラル・ポートを活用します。エフェメラル・ポートは、IPソフトウェアの事前定義済範囲から自動的に割り当てられるインターネット・プロトコル(IP)通信の存続期間の短いトランスポート・プロトコル・ポートです。Linuxでは、エフェメラル・ポートを制限および規制することができます。

注意:
OTDは、十分なエフェメラル・ポートが使用可能であるかに依存するため、WLS/オリジン・サーバーと接続を確立したプールを十分に持つことができます。十分なエフェメラル・ポートがない場合、リクエストの処理で遅延が発生します。

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

管理コンソールまたはCLIのいずれかを使用して、プールからオリジン・サーバーを削除できます。

注意:

- 動的検出が有効なとき(6.5項を参照)、クラスタ内のOracle WebLogic Serverインスタンスであるオリジン・サーバーを削除し、Oracle Traffic Directorインスタンスを再構成すると、プール内に有効なオリジン・サーバーが残っていない場合インスタンスが起動しないことがあります。

- オリジン・サーバーをプールから削除すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したプールからのオリジン・サーバーの削除

管理コンソールを使用して、プールからオリジン・サーバーを削除するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. オリジン・サーバーを削除する構成を選択します。

4. ナビゲーション・ペインで、「オリジン・サーバー・プール」を展開し、オリジン・サーバーを削除するプールを展開して、「オリジン・サーバー」を選択します。
選択したプール内のオリジン・サーバーのリストが表示されます。

5. 削除するオリジン・サーバーの「削除」アイコンをクリックします。
「コンソール・メッセージ」ペインに、オリジン・サーバーが削除されたことを確認するメッセージが表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したプールからのオリジン・サーバーの削除

プールからオリジン・サーバーを削除するには、次の例に示すようにdelete-origin-serverコマンドを実行します。

tadm> delete-origin-server --config=soa --origin-server-pool=osp1 soa-app2.example.com:1900
OTD-70201 Command 'delete-origin-server' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

8 仮想サーバーの管理

単一のOracle Traffic Directorインスタンス内の複数の仮想サーバーを使用して、クライアントのリクエストに対して、いくつかのエントリ・ポイント(ドメイン名およびIPアドレス)を提供し、キャッシュ、サービス品質などに差別化されたサービスを提供できます。仮想サーバーを1つ以上のリスナー(HTTPまたはHTTPS)にバインドし、リクエストを様々なオリジン・サーバー・プールに転送できます。

各仮想サーバーに対して、キャッシュ、圧縮、ルーティング、サービス品質、ログ・ファイルおよびWebアプリケーション・ファイアウォール設定を個別に設定できます。

この章では、仮想サーバーを作成、表示、変更および削除する方法を説明します。ここの内容は、次のとおりです。

- 仮想サーバーの作成

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

- 仮想サーバーの変更

- ルートの構成

- 仮想サーバーのコピー

- 仮想サーバーの削除

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

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

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

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

8.1 仮想サーバーの作成

構成の作成時、仮想サーバーは、構成と同じ名前で自動的に作成され、構成の作成時に指定されたHTTPリスナーに関連付けられます。仮想サーバーに対してデフォルトのルーティング・ルールも作成され、関連付けられたHTTPリスナーで受信したすべてのリクエストが、構成の作成時に指定されたオリジン・サーバーに分散されます。

管理コンソールまたはCLIのいずれかを使用して、構成に追加の仮想サーバーを作成できます。

注意:

- 仮想サーバーを作成すると、実質的には構成が変更されます。新しい仮想サーバーをOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

始める前に

仮想サーバーの作成を開始する前に、次の項目を決定します。

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

- 1つ以上の一意のリスニング・ポート。リスナーの作成の詳細は、第10章「リスナーの管理」を参照してください。

- 仮想サーバーがリクエストを処理するために必要なホストまたはホスト・パターンの名前。
リクエストを受信すると、Oracle Traffic Directorは、リクエストのHostヘッダーを、構成内の各仮想サーバーに定義されたホスト・パターンと比較して、リクエストを処理する仮想サーバーを決定します。

- リクエストは、リクエスト内のHostヘッダーと一致するホスト・パターンを持つ最初の仮想サーバーにルーティングされます。

- リクエストのHostヘッダーが、各仮想サーバーに定義されているホスト・パターンのいずれとも一致しない、またはリクエストにHostヘッダーが含まれていない場合、リクエストは、リクエストの受信に使用されたHTTPリスナーに関連付けられたデフォルトの仮想サーバーにルーティングされます。

注意:
「厳密なSNIホスト一致」がHTTPリスナーに対して有効化されていて、そのリスナーに対し、仮想サーバーの少なくとも1つに証明書がある場合、次の条件のいずれかが真であれば、Oracle Traffic Directorにより403-Forbiddenエラーがクライアントに返されます。

- SSL/TLSハンドシェイク中、クライアントからSNIホスト拡張が送信されませんでした。

- リクエストに、Host:ヘッダーがありません。

- SSL/TLSハンドシェイク中にSNIホスト拡張でクライアントから送信されたホスト名が、リクエスト内のHost:ヘッダーと一致しません。

詳細は、11.2.6項「厳密なSNIホスト一致について」を参照してください。

- 仮想サーバーがリクエストを転送するオリジン・サーバー・プールの名前。オリジン・サーバー・プールの作成の詳細は、第6章「オリジン・サーバー・プールの管理」を参照してください。

管理コンソールを使用した仮想サーバーの作成

管理コンソールを使用して仮想サーバーを作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 仮想サーバーを作成する構成を選択します。

4. 「共通のタスク」ペインで、「新規仮想サーバー」をクリックします。
新規仮想サーバー・ウィザードが開始されます。

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

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

6. 結果画面で、「閉じる」をクリックします。

- 作成した仮想サーバーの詳細は、「仮想サーバー」ページに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用した仮想サーバーの作成

仮想サーバーを作成するには、create-virtual-serverコマンドを実行します。

たとえば、次のコマンドでは、構成soa.example.comに対してリスナーhl1に関連付けられたvs_soaという名前の仮想サーバーが作成され、オリジン・サーバー・プールsoa-poolにクライアントのリクエストを転送する仮想サーバーが構成されます。

tadm> create-virtual-server --config=soa.example.com --http-listener-name=hl1 --origin-server-pool=soa-pool vs_soa
OTD-70201 Command 'create-virtual-server' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

8.2 仮想サーバーのリストの表示

管理コンソールまたはCLIのいずれかを使用して、仮想サーバーのリストを表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した仮想サーバー・リストの表示

管理コンソールを使用して仮想サーバー・リストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 仮想サーバーを表示する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

名前をクリックすると、仮想サーバーのプロパティを表示できます。

CLIを使用した仮想サーバー・リストの表示

仮想サーバー・リストを表示するには、次の例に示すようにlist-virtual-serversコマンドを実行します。

tadm> list-virtual-servers --config=soa.example.com
name            http-listener-name
----------------------------------
soa             http-listener-1
adf             adf-listener

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

get-virtual-server-propコマンドを実行することで、仮想サーバーのプロパティの詳細を表示できます。

list-virtual-serversおよびget-virtual-server-propコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

8.3 仮想サーバーの変更

管理コンソールまたはCLIのいずれかを使用して、仮想サーバーを変更できます。

注意:

- 仮想サーバーを変更すると、実質的には構成が変更されます。新しい仮想サーバーの設定をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した仮想サーバーの変更

管理コンソールを使用して仮想サーバーを変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 仮想サーバーを変更する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

5. 変更する仮想サーバーを選択します。
「仮想サーバー設定」ページが表示されます。このページで、次の処理が可能です。

- 仮想サーバーの有効化および無効化。

- 仮想サーバーによって提供されるホスト・パターンの追加、削除および変更。Oracle Traffic Directorによるホスト・パターンの使用の詳細は、「始める前に」の項を参照してください。

- HTTPリスナーの追加および削除。HTTPリスナーの作成の詳細は、10.1項「リスナーの作成」を参照してください。

- RSAまたはECC証明書を仮想サーバーに関連付けることによる、SSL/TLSの有効化。詳細は、11.2.3項「仮想サーバーと証明書の関連付け」を参照してください。

- インスタンス・レベルの統計情報を、ユーザーがブラウザからアクセス可能なXMLおよびプレーンテキスト・レポートの形式で提供するように仮想サーバーを構成。XMLおよびプレーンテキスト・レポートに表示される統計情報は、各仮想サーバーに固有のものではなく、Oracle Traffic Directorインスタンス全体に対するものであることに注意してください。詳細は、13.3項「統計レポートへのURIアクセスの構成」を参照してください。

- メッセージのデフォルト言語は英語です。必要であれば、Oracle Traffic Directorでサポートされている他の言語に設定できます。

- 様々なエラー・コードごとに仮想サーバーがクライアントに返すエラー・ページの指定。これが必要になるのは、デフォルトのエラー・メッセージを使用するのではなく、カスタマイズして使用する必要がある場合のみです。
選択したエラー・コードおよびエラー・ページを指定するには、特定のエラー・コードに対して表示するhtmlページをまず作成します。次に、「仮想サーバー設定」ページの「エラー・ページ」セクションで、「新規エラー・ページ」をクリックします。

「新規エラー・ページ」ダイアログ・ボックスが表示されたら、エラー・コードを選択し、そのエラー・コードに使用するエラー・ページへの完全パスを入力します。提示されるエラー・コードだけでなく、「カスタム・エラー・コード」をクリックして値を入力し、カスタム・エラー・コードを作成できます。この作業が完了したら、「エラー・ページの作成」をクリックします。

- サービス品質の制限(仮想サーバーからクライアントへの最高データ送信速度および仮想サーバーがサポートできる最大同時接続数)の有効化。

ナビゲーション・ペインの「仮想サーバー」ノードで、次のような、仮想サーバー設定の追加カテゴリを選択できます。選択したカテゴリに関連するパラメータが、メインのペインに表示されます。

- ルート: リクエストをオリジン・サーバーにルーティングするルールを作成、変更および削除します。詳細は、8.4項「ルートの構成」を参照してください。

- キャッシュ: オリジン・サーバーから受信したレスポンスをキャッシュするためのルールを作成、変更および削除します。詳細は、8.10項「キャッシュ・パラメータの構成」を参照してください。

- リクエスト制限: 仮想サーバーが受信したリクエストの数およびレートを制限するルールを作成、変更および削除します。詳細は、11.9項「サービス拒否攻撃の回避」を参照してください。

- 圧縮: オリジン・サーバーからのレスポンスをクライアントに送信する前に、それらのレスポンスを圧縮するルールを作成、変更および削除します。詳細は、15.8項「コンテンツ圧縮の有効化と構成」を参照してください。

- ロギング: 仮想サーバーに固有のサーバー・ログ・ファイルおよび場所を定義します。詳細は、12.3項「ログ・プリファレンスの構成」を参照してください。

- Webappファイアウォール・ルールセット: Webアプリケーション・ファイアウォール・ルール・セットを有効化または無効化し、ルール・セット・パターンを指定してルール・セット・ファイルをインストールします。詳細は、11.7項「Webアプリケーション・ファイアウォールの管理」を参照してください。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用した仮想サーバーの変更

CLIでは、仮想サーバーの特定のパラメータの変更に使用できるいくつかのコマンド(表8-1を参照)が用意されています。

表8-1 仮想サーバー変更用のCLIコマンド

タスク

CLIコマンド

仮想サーバーの有効化または無効化、ホスト、HTTPリスナー、ログ・ファイルの名前および場所の変更、RSAまたはECC証明書(あるいはその両方)を関連付けることによるSSL/TLSの有効化(11.2.3項「仮想サーバーと証明書の関連付け」および12.3項「ログ・プリファレンスの構成」も参照)

set-virtual-server-prop

キャッシュ・ルールの作成および管理(8.10項「キャッシュ・パラメータの構成」を参照)。

create-cache-rule

list-cache-rules

delete-cache-rule

get-cache-rule-prop

set-cache-rule-prop

圧縮ルールの作成および管理(15.8項「コンテンツ圧縮の有効化と構成」を参照)。

create-compression-rule

set-compression-rule-prop

delete-compression-rule

list-compression-rules

get-compression-rule-prop

QoS設定の変更

set-qos-limits-prop

get-qos-limits-prop

リクエスト制限設定の変更(11.9項「サービス拒否攻撃の回避」を参照)

create-request-limit

delete-request-limit

get-request-limit-prop

list-request-limits

set-request-limit-prop

ルートの作成および管理(8.4項「ルートの構成」を参照)

create-route

list-routes

delete-route

set-route-prop

get-route-prop

エラー・ページの作成および管理

create-error-page

delete-error-page

list-error-pages

たとえば、次のコマンドでは、仮想サーバーsoaのエラー・ログ・ファイルの場所が/home/log/errors.logに変更されます。

tadm> set-virtual-server-prop --config=soa --vs=soa log-file=/home/log/errors.log
OTD-70201 Command 'set-virtual-server-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

8.4 ルートの構成

構成の作成時、仮想サーバーは、構成の作成時に指定されたリスナーで自動的に作成されます。自動的に作成された仮想サーバーの他、後で構成に追加された仮想サーバーについても、デフォルトのルートが作成されます。デフォルト・ルートのルールでは、仮想サーバーへのすべてのリクエストを、仮想サーバーの作成時に指定したオリジン・サーバー・プールにルーティングするように指定されます。仮想サーバーのデフォルト・ルートは削除できませんが、そのプロパティを変更することはできます。

指定した条件を満たすリクエストを、特定のオリジン・サーバー・プールにルーティングするように、仮想サーバーに追加のルートを作成できます。たとえば、銀行業のソフトウェア・ソリューションで、ローンおよび預金の顧客取引が別々のアプリケーションによって処理される場合、これらの各アプリケーションを、Oracle Traffic Directorインスタンスの背後にある別々のオリジン・サーバー・プールでホストできます。顧客のリクエストがローンまたは預金のいずれのアプリケーションに関連するかに応じて、リクエストを適切なオリジン・サーバー・プールにルーティングするために、次のように2つのルートを設定できます。

- ルート1: リクエストURIが/loanで始まる場合、ローン・アプリケーションをホストするオリジン・サーバー・プールにリクエストを送信します。

- ルート2: リクエストURIが/depositで始まる場合、預金アプリケーションをホストするオリジン・サーバー・プールにリクエストを送信します。

複数のルートで構成されている仮想サーバーがリクエストを受信すると、使用可能な各ルートに対してリクエストのURIをチェックします。ルートは、作成された順にチェックされます。

- リクエストがルートの条件を満たす場合、Oracle Traffic Directorはそのルートに指定されたオリジン・サーバー・プールにリクエストを送信します。

- リクエストが、定義されたいずれのルートの条件とも一致しない場合、Oracle Traffic Directorは、デフォルト・ルートで指定されているオリジン・サーバー・プールにリクエストを送信します。

WebSocketアップグレードはデフォルトで有効です。管理コンソールで「WebSocketアップグレード」チェック・ボックスを使用して、ルートのWebSocketプロトコルを有効化または無効化します。同様にWebSocketプロトコルはwebsocket-upgrade-enabledプロパティでも有効化または無効化できます。これは、set-route-propというCLIコマンドで設定できます。詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照してください。

管理コンソールまたはCLIのいずれかを使用して、仮想サーバーのルートを構成できます。

注意:

- 仮想サーバーを変更すると、実質的には構成が変更されます。新しい仮想サーバーの設定をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したルートの構成

管理コンソールを使用してルートを構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. ルートを構成する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を展開し、ルートを構成する仮想サーバーの名前を展開して、「ルート」を選択します。
「ルート」ページが表示されます。仮想サーバーに現在定義されているルートがリストされます。

ルートの作成

1. 「新規ルート」をクリックします。
「新規ルート」ダイアログ・ボックスが表示されます。

「名前」フィールドで、新規ルートの名前を入力します。

「オリジン・サーバー・プール」フィールドで、指定された条件を満たすリクエストがルーティングされるオリジン・サーバー・プールを選択します。

2. 次へをクリックします。
「条件情報」ペインで「変数/関数」を選択し、各ドロップダウン・リストから演算子を選択し、「値」フィールドに値を入力します。

複数の式を構成する場合は、ドロップダウン・リストでand/or演算子を選択します。同様に、指定した式が偽に評価されるときにルートを適用する場合は、Not演算子を使用します。

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

条件を手動入力するには、「取消」をクリックし、「手動編集」をクリックします。「条件」フィールドで、ルーティング・ルールが適用される条件を指定します。条件式の作成の詳細は、「条件」フィールドの近くにあるヘルプ・ボタンをクリックするか、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

3. 次へをクリックし、「ルートの作成」をクリックします。
作成したルートが「ルート」ページに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

ルートの編集

ルートの設定を変更するには、次の操作を行います。

1. ルートの「名前」をクリックします。
ルート設定ページが表示されます。

2. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

3. 必要な変更を行った後、「保存」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

ルーティング・ルールの削除

ルーティング・ルールを削除するには、「削除」ボタンをクリックします。確認プロンプトで、「OK」です。

CLIを使用したルートの構成

- ルートを作成するには、create-routeコマンドを実行します。
例:

- 次のコマンドでは、構成soaの仮想サーバーsoa.example.comにloan-routeという名前のルートが作成され、このルートでは、パターン/loanに一致するURIを持つリクエストがオリジン・サーバー・プールloan-appに送信されます。

tadm> create-route --config=soa --vs=soa.example.com --condition="$uri='/loan'" --origin-server-pool=loan-app loan-route
OTD-70201 Command 'create-route' ran successfully.

- 次のコマンドでは、構成soaの仮想サーバーsoa.example.comにimages-routeという名前のルートが作成され、このルートでは、パターン/imagesに一致するURIパスを持つリクエストがオリジン・サーバー・プールimages-repoに送信されます。

tadm> create-route --config=soa --vs=soa.example.com --condition="$path='/images/*'" --origin-server-pool=images-repo images-route
OTD-70201 Command 'create-route' ran successfully.

- 次のコマンドでは、構成soaの仮想サーバーsoa.example.comにsubnet-routeという名前のルートが作成され、このルートでは、サブネット130.35.46.*のクライアントからのリクエストがオリジン・サーバー・プールdedicated-ospに送信されます。

tadm> create-route --config=soa --vs=soa.example.com --condition="$ip='130.35.45.*'" --origin-server-pool=dedicated-osp subnet-route
OTD-70201 Command 'create-route' ran successfully.

- 次のコマンドでは、構成soaの仮想サーバーsoa.example.comにbody-routeという名前のルートが作成され、このルートでは、本文にalphaという言葉が含まれているリクエストがオリジン・サーバー・プールdedicated-ospにルーティングされます。

tadm> create-route --config=soa --vs=soa.example.com --condition="$body ='alpha'" --origin-server-pool=dedicated-osp body-route
OTD-70201 Command 'create-route' ran successfully.

--conditionオプションの値は、正規表現にする必要があることに注意してください。条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

- 仮想サーバーに定義されたルートのリストを表示するには、次の例に示すようにlist-routesコマンドを実行します。

tadm> list-routes --config=soa --vs=soa.example.com
route           condition
-------------------------
loan-route       "$uri = '/loan'"
default-route   -

- ルートのプロパティを表示するには、次の例に従い、get-route-propコマンドを実行します。

tadm> get-route-prop --config=soa --vs=soa.example.com --route=loan-route
keep-alive-timeout=15
sticky-cookie=JSESSIONID
condition="$uri = '/loan'"
validate-server-cert=true
always-use-keep-alive=true
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

- ルートのプロパティを変更するには、set-route-propコマンドを実行します。
例:

- たとえば、次のコマンドでは、構成soaの仮想サーバーsoa.example.com内のloan-routeという名前のルートに対するキープ・アライブ・タイムアウト設定が30秒に変更されます。

tadm> set-route-prop --config=soa --vs=soa.example.com --route=loan-route keep-alive-timeout=30

- 次のコマンドでは、構成soaの仮想サーバーsoa.example.com内のdefault-routeという名前のルートと関連付けられているオリジン・サーバーとの間でOracle Traffic Directorが送受信するヘッダーのロギングが有効化されます。

tadm> set-route-prop --config=soa --vs=soa.example.com --route=default-route log-headers=true

- ルートを削除するには、次の例に示すように、delete-routeコマンドを実行します。

tadm> delete-route --config=soa --vs=soa.example.com loan-route
OTD-70201 Command 'delete-route' ran successfully.

- WebSocketサポートを無効にするには、次の例に示すように、set-route-propコマンドをwebsocket-upgrade-enabledプロパティを指定して実行します。

tadm> set-route-prop --config=soa --vs=soa.example.com --route=default-route websocket-upgrade-enabled=false
OTD-70201 Command 'set-route-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

8.5 仮想サーバーのコピー

管理コンソールまたはCLIのいずれかを使用して、仮想サーバーをコピーできます。

注意:

- 仮想サーバーをコピーすると、実質的には構成が変更されます。新しい仮想サーバーをOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した仮想サーバーのコピー

管理コンソールを使用して仮想サーバーをコピーするには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 仮想サーバーをコピーする構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

5. コピーするオリジン・サーバーの「複製」アイコンをクリックします。
「仮想サーバーの複製」ダイアログ・ボックスが表示されます。

6. 新しい仮想サーバーの名前を入力し、「複製」をクリックします。
新しい仮想サーバーが作成されたことを確認するメッセージが表示されます。

7. 「閉じる」をクリックします。
作成した仮想サーバーは、「仮想サーバー」ページに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用した仮想サーバーのコピー

仮想サーバーをコピーするには、copy-virtual-serverコマンドを実行します。

たとえば、次のコマンドでは、仮想サーバーvs1のコピー(vs2)が作成されます。

tadm> copy-virtual-server --config=soa --vs=vs1 vs2OTD-70201 Command 'copy-virtual-server' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

8.6 仮想サーバーの削除

管理コンソールまたはCLIのいずれかを使用して、仮想サーバーを削除できます。

注意:

- 仮想サーバーをコピーすると、実質的には構成が削除されます。構成の変更をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した仮想サーバーの削除

管理コンソールを使用して仮想サーバーを削除するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 仮想サーバーを削除する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

5. 削除する仮想サーバーの「削除」アイコンをクリックします。
削除を確認するプロンプトが表示されます。

6. 「OK」をクリックします。
「コンソール・メッセージ」ペインに、仮想サーバーが削除されたことを確認するメッセージが表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用した仮想サーバーの削除

仮想サーバーを削除するには、次の例に示すように、delete-virtual-serverコマンドを実行します。

tadm> delete-virtual-server --config=soa vs1
OTD-70201 Command 'delete-virtual-server' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

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

頻繁にリクエストされるデータをキャッシュすることで、クライアントがレスポンスを待機する時間が削減されます。また、頻繁にアクセスされるURLがメモリー内に格納される場合、オリジン・サーバーの負荷は大幅に削減されます。

キャッシュを有効にするには、キャッシュ・ルールを構成する必要があります。

- オリジン・サーバーから静的および動的に生成されたコンテンツの両方がキャッシュされます。

- 完全なレスポンス(レスポンス・コード: 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を参照してください。

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

キャッシュ設定の表示

- 構成の現在のキャッシュ設定を表示するには、次の例に示すようにget-cache-propコマンドを実行します。

tadm> get-cache-prop --config=soa
enabled=true
replacement=lru
max-heap-space=10485760
max-entries=1024
max-heap-object-size=524288

- 仮想サーバーに定義されたキャッシュ・ルールのリストを表示するには、次の例に示すようにlist-cache-rulesコマンドを実行します。

tadm> list-cache-rules --config=soa --vs=soa --verbose --all
rule            condition
-------------------------
cache-rule-2    "$uri = '^/images'
cache-rule-1    -

- 仮想サーバー固有のキャッシュ・ルールの現在の設定を表示するには、次の例に示すようにget-cache-rule-propコマンドを実行します。

tadm> get-cache-rule-prop --config=soa --vs=soa --rule=cache-rule-2
enabled=true
last-modified-factor=0
min-object-size=1
cache-https-response=true
condition="$uri = '^/images"
min-reload-interval=0
rule=cache-rule-2
query-maxlen=0
compression=true
max-reload-interval=3600

キャッシュ・メトリックの表示

プレーンテキスト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は、現在使用中のキャッシュ・ヒープ領域の量です。

8.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レスポンスをキャッシュするかどうか

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

管理コンソールまたはCLIのいずれかを使用して、キャッシュ設定を構成できます。

管理コンソールを使用したキャッシュ設定の構成

管理コンソールを使用してキャッシュ設定を構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 変更する構成を選択します。

4. ナビゲーション・ペインで、「詳細設定」を選択します。
「詳細設定」ページが表示されます。

5. ページの「キャッシュ」セクションに移動します。

6. 変更するキャッシュ・パラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

管理コンソールを使用した仮想サーバー固有のキャッシュ・ルールの構成

管理コンソールを使用して仮想サーバー固有のキャッシュ・ルールを作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 仮想サーバー固有のキャッシュ・ルールを作成する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を展開し、キャッシュ・ルールを作成する仮想サーバーの名前を展開して、「キャッシュ」を選択します。
「キャッシュ」ページが表示されます。仮想サーバーに現在定義されているキャッシュ・ルールがリストされ、そのキャッシュ・ルールが有効化されているかどうかが示されます。

キャッシュ・ルールの作成

1. 「新規キャッシュ・ルール」をクリックします。
「新規キャッシュ・ルール」ダイアログ・ボックスが表示されます。

「名前」フィールドで、新規キャッシュ・ルールの名前を入力します。

2. 次へをクリックします。
このキャッシュ・ルールが仮想サーバーに対する最初のキャッシュ・ルールの場合、「新規キャッシュ・ルール」ダイアログ・ボックスに、ルールをすべてのリクエストに適用するかどうかを選択するオプションが表示されます。「すべてのリクエスト」を選択します。

条件を満たすリクエストにのみ、ルールを適用する場合は、「条件を新規に作成します」を選択して新しい条件を作成します。条件ビルダーで「変数/関数」を選択し、各ドロップダウン・リストから演算子を選択し、「値」フィールドに値を入力します。

複数の式を構成する場合は、ドロップダウン・リストでand/or演算子を選択します。同様に、指定した式が偽に評価されるときにルートを適用する場合は、Not演算子を使用します。

条件を手動入力するには、「取消」をクリックし、「手動編集」をクリックします。「条件」フィールドで、キャッシュ・ルールが適用される条件を指定します。条件式の作成の詳細は、「条件」フィールドの近くにあるヘルプ・ボタンをクリックするか、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

3. 次へをクリックし、キャッシュ・ルールの作成をクリックします。
作成したキャッシュ・ルールが「キャッシュ」ページに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

キャッシュ・ルールの編集

キャッシュ・ルールを有効化または無効化する、あるいはルールの設定を変更するには、次の操作を行います。

1. 編集するキャッシュ・ルールの「名前」をクリックします。
「キャッシュ・ルールの編集」ダイアログ・ボックスが表示されます。

注意:
条件ビルダーにアクセスして条件を編集するには、「条件を満たすリクエスト」を選択し、「編集」をクリックします。条件ビルダーでは古い式を削除したり、新しい式を作成したりできます。

2. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

条件式の作成の詳細は、「条件」フィールドの近くにあるヘルプ・ボタンをクリックするか、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

3. 必要な変更を行った後、「保存」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

キャッシュ・ルールの削除

キャッシュ・ルールを削除するには、「削除」ボタンをクリックします。確認プロンプトで、「OK」です。

CLIを使用したキャッシュ設定の構成

- 構成のキャッシュ・プロパティを変更するには、set-cache-propコマンドを実行します。
たとえば、次のコマンドでは、最大キャッシュ・ヒープ領域が20MBに変更されます。

tadm> set-cache-prop --config=soa max-heap-space=20971520
OTD-70201 Command 'set-cache-prop' ran successfully.

- 仮想サーバーのキャッシュ・ルールを作成するには、create-cache-ruleコマンドを実行します。
たとえば、次のコマンドでは、構成soaの仮想サーバーsoa.example.comに対してcache-rule-imagesという名前のルールが作成され、式$uri='^/images'がtrueと評価されるリクエストがキャッシュされます。

tadm> create-cache-rule --condition="\$uri='^/images'" --config=soa --vs=soa.example.com cache-rule-images
OTD-70201 Command 'create-cache-rule' ran successfully.

--conditionオプションの値は、正規表現にする必要があることに注意してください。条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

- キャッシュ・ルールを変更するには、set-cache-rule-propコマンドを実行します。
たとえば、次のコマンドでは、キャッシュ・ルールcache-rule-imagesに対してコンテンツの圧縮が無効化されます。

tadm> set-cache-rule-prop --config=soa --vs=soa.example.com --rule=cache-rule-images compression=false
OTD-70201 Command 'set-cache-rule-prop' ran successfully.

- キャッシュ・ルールを削除するには、次の例に示すように、delete-cache-ruleコマンドを実行します。

tadm> delete-cache-rule --config=soa --vs=soa.example.com cache-rule-images
OTD-70201 Command 'delete-cache-rule' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

9 TCPプロキシの管理

トラフィック・トンネリングを行うためTCPプロキシはTCPリスナーを介してTCPリクエストを処理します。TCPプロキシには複数のTCPリスナーを関連付けることができますが、1つのTCPリスナーに関連付けることができるTCPプロキシは1つのみです。

この章では、TCPプロキシを作成、表示、変更および削除する方法を説明します。この章の内容は、次のとおりです。

- TCPプロキシの作成

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

- TCPプロキシの変更

- TCPプロキシの削除

9.1 TCPプロキシの作成

管理コンソールまたはCLIのいずれかを使用して、TCPプロキシを作成できます。

注意:

- TCPプロキシを作成すると、実質的には構成が変更されます。新しいTCPプロキシ設定をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

始める前に

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プロキシがリクエストを転送するオリジン・サーバー・プールの名前。オリジン・サーバー・プールの作成の詳細は、第6章「オリジン・サーバー・プールの管理」を参照してください。

管理コンソールを使用したTCPプロキシの作成

管理コンソールを使用してTCPプロキシを作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. TCPプロキシを作成する構成を選択します。

4. 「共通のタスク」ペインで、「新規TCPプロキシ」をクリックします。
新規TCPプロキシ・ウィザードが開始されます。

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

5. 画面上のプロンプトに従い、前に決定済の詳細(プロキシ名、リスナー名、IPアドレス、ポートなど)を使用して、TCPプロキシの作成を完了します。

注意:
ポートのTCPトラフィックがT3SなどのSSLを介して行われるトラフィックである場合、新規TCPプロキシ・ウィザードの最初の画面で「SSL/TLS」チェック・ボックスを選択し、使用する証明書を選択します。詳細は、11.2.2項「リスナーのSSL/TLSの構成」を参照してください。

プロキシが作成された後、新規TCPプロキシ・ウィザードの「結果」画面にプロキシの作成が成功したことを示すメッセージが表示されます。

6. 結果画面で、「閉じる」をクリックします。

- TCPプロキシ・ページに、作成したTCPプロキシの詳細が表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したTCPプロキシの作成

TCPプロキシを作成するには、create-tcp-proxyコマンドを実行します。

たとえば、次のコマンドでは、構成soa.example.comにポート番号が1910、オリジン・サーバー・プールがsoa-poolであるtcp_proxy1という名前のTCPプロキシが作成されます。

tadm> create-tcp-proxy --config=soa.example.com --origin-server-pool=soa-pool --port=1910 tcp_proxy1
OTD-70201 Command 'create-tcp-proxy' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

9.2 TCPプロキシのリストの表示

管理コンソールまたはCLIのいずれかを使用して、TCPプロキシのリストを表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したTCPプロキシのリストの表示

管理コンソールを使用してTCPプロキシのリストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. TCPプロキシを表示する構成を選択します。

4. ナビゲーション・ペインで、「TCPプロキシ」を選択します。
「TCPプロキシ」ページが表示されます。構成に定義されたTCPプロキシのリストが表示されます。

名前をクリックすると、プロキシのプロパティの詳細を表示できます。

CLIを使用したTCPプロキシのリストの表示

TCPプロキシのリストを表示するには、次の例に示すようにlist-tcp-proxiesコマンドを実行します。

tadm> list-tcp-proxies --config=soa --verbose --all
name            session-idle-timeout        origin-server-pool-name
-------------------------------------------------------------------
tcp_proxy1      300                         soa-pool1
tcp_proxy2      400                         soa-pool2

get-tcp-proxy-propコマンドを実行することで、TCPプロキシのプロパティの詳細を表示できます。

list-tcp-proxiesおよびget-tcp-proxy-propコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

9.3 TCPプロキシの変更

管理コンソールまたはCLIのいずれかを使用して、TCPプロキシを変更できます。

注意:

- TCPプロキシを変更すると、実質的には構成が変更されます。TCPプロキシの新しい設定をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したTCPプロキシの変更

管理コンソールを使用してTCPプロキシを変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. TCPプロキシを変更する構成を選択します。

4. ナビゲーション・ペインで、「TCPプロキシ」を選択します。
「TCPプロキシ」ページが表示されます。構成に定義されたTCPプロキシのリストが表示されます。

5. 変更するTCPプロキシの名前をクリックします。
「TCPプロキシ設定」ページが表示されます。このページで、次の処理が可能です。

- TCPプロキシの有効化および無効化

- オリジン・サーバー・プールおよびアイドル・タイムアウトの変更

- TCPリスナーの追加および削除。TCPリスナーの作成の詳細は、10.1項「リスナーの作成」を参照してください。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新されたプロキシが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したTCPプロキシの変更

- TCPプロキシのプロパティを変更するには、set-tcp-proxy-propコマンドを実行します。たとえば、次のコマンドを実行すると、構成soaのプロキシtcp_proxy1のセッション・アイドル・タイムアウトが500に変更されます。

tadm> set-tcp-proxy-prop --config=soa --tcp-proxy=tcp_proxy1 session-idle-timeout=500
OTD-70201 Command 'set-tcp-proxy-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

set-tcp-proxy-propコマンドを使用して設定または変更できるプロパティ・リストの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

9.4 TCPプロキシの削除

管理コンソールまたはCLIのいずれかを使用して、TCPプロキシを削除できます。

注意:

- TCPプロキシを削除すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したTCPプロキシの削除

管理コンソールを使用してTCPプロキシを削除するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. TCPプロキシを削除する構成を選択します。

4. ナビゲーション・ペインで、「TCPプロキシ」を選択します。
「TCPプロキシ」ページが表示されます。構成に定義されたTCPプロキシのリストが表示されます。

5. 削除するTCPプロキシの「削除」アイコンをクリックします。
プロキシの削除を確認するプロンプトが表示されます。プロキシがリスナーに関連付けられている場合、プロンプトには、それらのリスナーの名前が表示されます。

6. 削除を続行するには、「OK」をクリックします。
「コンソール・メッセージ」ペインに、TCPプロキシが削除されたことを確認するメッセージが表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したTCPプロキシの削除

TCPプロキシを削除するには、次の例に示すように、delete-tcp-proxyコマンドを実行します。

tadm> delete-tcp-proxy --config=soa tcp_proxy1
OTD-70201 Command 'delete-tcp-proxy' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

10 リスナーの管理

クライアントとOracle Traffic Directorインスタンス間の接続は、HTTPリスナーおよびTCPリスナーを介して作成されます。各リスナーは、IPアドレス(またはホスト名)およびポート番号の一意の組合せです。

この章では、リスナーを作成、表示、変更および削除する方法を説明します。この章の内容は、次のとおりです。

- リスナーの作成

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

- リスナーの変更

- リスナーの削除

10.1 リスナーの作成

管理コンソールまたはCLIのいずれかを使用して、リスナーを作成できます。

注意:

- リスナーを作成すると、実質的には構成が変更されます。新しいリスナー設定をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

始める前に

リスナーの作成を開始する前に、次の項目を決定します。

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

- リスナーに対する、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値が、リスナーにバインドされている仮想サーバーに指定されたホスト・パターンと一致しない場合、デフォルトの仮想サーバーにリクエストをルーティングします。

仮想サーバーのホスト・パターンの指定の詳細は、8.1項「仮想サーバーの起動」を参照してください。

- HTTPリスナーの場合: サーバーによって自動的に生成され、クライアントに送信されるURLに含まれるサーバー名。このサーバー名は、仮想ホスト名であるか、またはサーバーで別名が使用されている場合、別名である必要があります。コロンとポート番号がサーバー名に追加されている場合、このポート番号は自動生成されたURLで使用されます。

- TCPリスナーの場合: リスナーのTCPプロキシ。
トラフィック・トンネリングを行うためTCPプロキシはTCPリスナーを介してTCPリクエストを処理します。TCPプロキシには複数のTCPリスナーを関連付けることができます。TCPリスナーを関連付け、このページでTCPプロキシの設定を構成します。

TCPプロキシの作成の詳細は、9.1項「TCPプロキシの作成」を参照してください。

管理コンソールを使用したHTTPリスナーの作成

管理コンソールを使用してHTTPリスナーを作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. HTTPリスナーを作成する構成を選択します。

4. 「共通のタスク」ペインで、「新規HTTPリスナー」をクリックします。
新規HTTPリスナー・ウィザードが開始されます。

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

5. 画面上のプロンプトに従い、前に決定済の詳細(リスナー名、IPアドレス、ポートなど)を使用して、HTTPリスナーの作成を完了します。

注意:
構成で証明書を使用できる場合は、ウィザードの2つ目の画面で「SSL/TLS」チェック・ボックスが使用可能になります。HTTPSリクエストを受信する新しいリクエストが必要な場合は、このチェック・ボックスを選択してSSL/TLSを有効にし、ドロップダウン・リストから適切な証明書を選択します。

HTTPリスナーが作成された後、新規HTTPリスナー・ウィザードの「結果」画面にリスナーの作成が成功したことを示すメッセージが表示されます。

6. 結果画面で、「閉じる」をクリックします。

- 作成したリスナーの詳細が、「リスナー」ページに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

管理コンソールを使用したTCPリスナーの作成

管理コンソールを使用してTCPリスナーを作成するには、次の操作を行います。

1. 10.1項「管理コンソールを使用したHTTPリスナーの作成」の手順1、2、3を実行します。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. TCPリスナーを作成する構成を選択します。

4. 「共通のタスク」ペインで、「新規TCPリスナー」をクリックします。
新規TCPリスナー・ウィザードが開始されます。

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

5. 画面上のプロンプトに従い、前に決定済の詳細(リスナー名、IPアドレス、ポートなど)を使用して、TCPリスナーの作成を完了します。

注意:
構成で証明書を使用できる場合は、ウィザードの2つ目の画面で「SSL/TLS」チェック・ボックスが使用可能になります。T3Sリクエストを受信する新しいリクエストが必要な場合は、このチェック・ボックスを選択してSSL/TLSを有効にし、ドロップダウン・リストから適切な証明書を選択します。

TCPリスナーが作成された後、新規TCPリスナー・ウィザードの「結果」画面にリスナーの作成が成功したことを示すメッセージが表示されます。

6. 結果画面で、「閉じる」をクリックします。

- 作成したリスナーの詳細が、「リスナー」ページに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したリスナーの作成

- HTTPリスナーを作成するには、create-http-listenerコマンドを実行します。
たとえば、次のコマンドでは、構成soa.example.comにポート番号が1910、デフォルト仮想サーバーがsoaであるlistener_soaという名前のHTTPリスナーが作成されます。

tadm> create-http-listener --config=soa.example.com --listener-port=1910 --server-name=soa.example.com --default-virtual-server-name=soa listener_soa
OTD-70201 Command 'create-http-listener' ran successfully.

- TCPリスナーを作成するには、create-tcp-listenerコマンドを実行します。
たとえば、次のコマンドでは、構成soa.example.comにポート番号が1920、TCPプロキシがtcp_proxy1であるtcp_listener_soaという名前のTCPリスナーが作成されます。

tadm> create-tcp-listener --config=soa.example.com --listener-port=1920 --server-name=soa.example.com --tcp-proxy=tcp_proxy1 listener_soa
OTD-70201 Command 'create-tcp-listener' ran successfully.

create-http-listenerおよびcreate-tcp-listenerの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

10.2 リスナー・リストの表示

管理コンソールまたはCLIのいずれかを使用して、HTTPリスナーまたはTCPリスナーのリストを表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したリスナー・リストの表示

管理コンソールを使用してHTTPリスナーまたはTCPリスナーのリストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. HTTPリスナーまたはTCPリスナーを表示する構成を選択します。

4. ナビゲーション・ペインで、「リスナー」を展開し、リスナーを選択します。
「リスナー」ページが表示されます。構成に定義されたリスナー・リストが表示されます。

注意:
HTTPリスナーおよびTCPリスナーはアイコンでも区別ができます。

名前をクリックすると、リスナーのプロパティの詳細を表示できます。

CLIを使用したリスナー・リストの表示

- HTTPリスナー・リストを表示するには、次の例に示すようにlist-http-listenersコマンドを実行します。

tadm> list-http-listeners --config=soa --verbose --all
name          ip       port    ssl-enabled     default-virtual-server
-----------------------------------------------------------------------
listener-1    *        1904       false           vs1
listener-2    *        80         false           vs1

get-http-listener-propコマンドを実行することで、HTTPリスナーのプロパティの詳細を表示できます。

list-http-listenersおよびget-http-listener-propコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

- TCPリスナー・リストを表示するには、次の例に示すようにlist-tcp-listenersコマンドを実行します。

tadm> list-tcp-listeners --config=soa --verbose --all
name          ip         port            ssl-enabled             tcp-proxy-name
------------------------------------------------------------------------
listener-1    *          9090         false                     tcp_proxy1
listener-2    *          9092         false               tcp_proxy1

get-tcp-listener-propコマンドを実行することで、TCPリスナーのプロパティの詳細を表示できます。

list-tcp-listenersおよびget-tcp-listener-propコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.3 リスナーの変更

管理コンソールまたはCLIのいずれかを使用して、リスナーを変更できます。

注意:

- リスナーを変更すると、実質的には構成が変更されます。リスナーの新しい設定をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したリスナーの変更

管理コンソールを使用してHTTPリスナーまたはTCPリスナーを変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. リスナーを変更する構成を選択します。

4. ナビゲーション・ペインで、「リスナー」をクリックします。
「リスナー」ページが表示されます。構成に定義されたHTTP/TCPリスナー・リストが表示されます。

5. 変更するリスナーの名前をクリックします。
「リスナー設定」ページが表示されます。このページで、次の処理が可能です。

- リスナーの有効化および無効化。

- リスナー・ポート番号とIPアドレスの変更。

- HTTPリスナーの場合: サーバー名とデフォルト仮想サーバーの変更。

- TCPリスナーの場合: TCPプロキシの変更。

- サーバー証明書が構成に作成済の場合、SSL/TLSの有効化と、リスナーのSSL/TLS設定の構成。詳細は、11.2.2項「リスナーのSSL/TLSの構成」を参照してください。

- リスナーがリクエストを受け入れる必要があるプロトコル・ファミリ(IPv4、IPv6またはSDP)の変更。

- HTTPリスナーの場合: 仮想サーバーのパフォーマンスをチューニングするためのパラメータ(アクセプタ・スレッド数、リスニング・キュー・サイズ、受信バッファ・サイズなど)の構成。詳細は、15.2.2項「HTTPリスナー設定のチューニング」を参照してください。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したリスナーの変更

- HTTPリスナーのプロパティを変更するには、set-http-listener-propコマンドを実行します。たとえば、次のコマンドを実行すると、構成soaのリスナーls1のポート番号が1911に変更されます。

tadm> set-http-listener-prop --config=soa --http-listener=ls1 port=1911
OTD-70201 Command 'set-http-listener-prop' ran successfully.

HTTPリスナーのSSL/TLSを変更するには、set-ssl-propコマンドを実行します。たとえば、次のコマンドを実行すると、構成soaのリスナーls1のSSL 3.0サポートが有効化されます。

- tadm> set-ssl-prop --config=soa --http-listener=ls1 ssl3=true
OTD-70201 Command 'set-ssl-prop' ran successfully.

TCPリスナーのプロパティを変更するには、set-tcp-listener-propコマンドを実行します。たとえば、次のコマンドを実行すると、構成soaのリスナーtcp_ls1のポート番号が1911に変更されます。

- tadm> set-tcp-listener-prop --config=soa --tcp-listener=tcp_ls1 listen-queue-size=238
OTD-70201 Command 'set-tcp-listener-prop' ran successfully.

TCPリスナーのSSL/TLS設定を変更するには、set-ssl-propコマンドを実行します。たとえば、次のコマンドを実行すると、構成soaのリスナーtcp_ls1のSSL 3.0サポートが有効化されます。

- tadm> set-ssl-prop --config=soa --tcp-listener=ls1 ssl3=true
OTD-70201 Command 'set-ssl-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。
set-tcp-listener-propおよびset-ssl-propコマンドを使用して設定または変更できるプロパティ・リストの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.4 リスナーの削除

管理コンソールまたはCLIのいずれかを使用して、HTTPリスナーまたはTCPリスナーを削除できます。

注意:

- リスナーを削除すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したリスナーの削除

管理コンソールを使用してHTTPリスナーまたはTCPリスナーを削除するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. リスナーを削除する構成を選択します。

4. ナビゲーション・ペインで、「リスナー」を選択します。
「リスナー」ページが表示されます。構成に定義されたリスナー・リストが表示されます。

5. 削除するリスナーの「削除」アイコンをクリックします。
リスナーの削除を確認するプロンプトが表示されます。

注意:
HTTPリスナーの場合: HTTPリスナーが仮想サーバーに関連付けられている場合、プロンプトには、それらの仮想サーバーが表示されます。

6. 削除を続行するには、「OK」をクリックします。
「コンソール・メッセージ」ペインに、HTTP/TCPリスナーが削除されたことを確認するメッセージが表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したリスナーの削除

- HTTPリスナーを削除するには、次の例に示すように、delete-http-listenerコマンドを実行します。

tadm> delete-http-listener --config=soa http-listener-1
OTD-70201 Command 'delete-http-listener' ran successfully.

TCPリスナーを削除するには、次の例に示すように、delete-tcp-listenerコマンドを実行します。

tadm> delete-tcp-listener --config=soa tcp-listener-1
OTD-70201 Command 'delete-tcp-listener' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

delete-http-listenerおよびdelete-tcp-listenerの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

第III部

高度な管理

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

- 第11章「セキュリティの管理」では、管理サーバーへのアクセスを保護する方法、Oracle Traffic Director仮想サーバーのSSL/TLSを有効化する方法、証明書を管理する方法、および証明書、PKCS#11トークン、証明書失効リストの管理方法を説明します。

- 第12章「ログの管理」では、アクセス・ログおよびサーバー・ログの概要を紹介し、ログの表示、ログ・プリファレンスの構成およびログ・ローテーションの各方法を説明します。

- 第13章「Oracle Traffic Directorインスタンスの監視」では、Oracle Traffic Directorインスタンスを監視するために使用できる方法を説明します。

- 第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デプロイメントを保護するための手順について説明します。

11 セキュリティの管理

この章では、Oracle Traffic Director管理サーバーへのアクセスの保護、およびOracle Traffic Director仮想サーバーに対するSSL/TLSの有効化の方法について説明します。また、クライアント認証の構成方法、およびOracle Traffic Directorを使用したオリジン・サーバーへのアクセスの保護の方法についても説明します。

この章には次の項が含まれます:

- 管理サーバーへのアクセスの保護

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

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

- 証明書の管理

- PKCS#11トークンの管理

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

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

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

- サービス拒否攻撃の回避

注意:
環境内のOracle Traffic Directorを保護するための手順の詳細は、付録C「Oracle Traffic Directorデプロイメントの保護」を参照してください。

11.1 管理サーバーへのアクセスの保護

Oracle Traffic Directorの管理サーバー・インスタンスは、管理コンソールおよびコマンドライン・インタフェースをホストします。したがって、管理サーバーへのアクセスを保護するのは重要なことです。

管理サーバー・インタフェースへのユーザー・アクセスは、パスワードに基づく認証によって制御されます。

- 管理サーバーではデフォルトで1つの管理者ユーザー・アカウントのみを使用でき、このアカウントは管理サーバーの作成時に指定します。管理者のユーザー名およびパスワードの変更の詳細は、11.1.1項「管理者のユーザー名およびパスワードの変更」を参照してください。

- 管理サーバーに複数のユーザーがログインできるようにするには、LDAP認証を有効化します。詳細は、11.1.2項「管理サーバーのLDAP認証の構成」を参照してください。

クライアントおよび管理ノードとのOracle Traffic Director管理サーバーのSSL認証は、2つの自己署名証明書(Admin-Client-CertおよびAdmin-Server-Cert)を介して、デフォルトで有効化されます。

- 自己署名管理サーバー証明書は、管理サーバーの作成時に自動作成され、12か月間有効になります。管理サーバー証明書の更新の詳細は、11.1.4項「管理サーバー証明書の更新」を参照してください。

- 自己署名管理サーバーの証明書が格納されたソフトウェア・データベースへのアクセスを保護するには、証明書データベースへのインタフェースを提供するinternalという名前のトークンにパスワードを定義します。詳細は、11.1.3項「管理サーバーのPKCS#11トークンのPINの有効化」を参照してください。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

11.1.1 管理者のユーザー名およびパスワードの変更

管理コンソールまたはCLIのいずれかを使用して、管理者のユーザー名およびパスワードを変更できます。

管理コンソールを使用した管理者のユーザー名およびパスワードの変更

管理コンソールを使用して、管理者のユーザー名およびパスワードを変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
使用可能なノードのリストが表示されます。

3. ノードのリストから、「管理サーバー」を選択します。

4. ナビゲーション・ペインで、「認証」を選択します。
「認証」ページが表示されます。

5. ユーザー名とパスワードを指定し、「保存」をクリックします。

注意:
ユーザー名の最大文字数は100文字で、空白を含めることはできません。

「コンソール・メッセージ」ペインに、更新した設定が保存されたことを示すメッセージが表示されます。

6. 「共通のタスク」ペインで、「再起動」をクリックして管理サーバーを再起動します。

CLIを使用した管理者のユーザー名およびパスワードの変更

- 管理者のユーザー名を変更するには、set-admin-propコマンドを実行します。

tadm> set-admin-prop admin-user=user_name
OTD-70213 The administration server must be restarted for the changes to take effect.

ユーザー名の最大文字数は100文字で、空白を含めることはできません。

- パスワードを変更するには、次の操作を行います。

1. 次のいずれかのコマンドを実行します。

tadm> set-admin-prop --set-password

または

tadm> reset-admin-password

次のプロンプトが表示されます。

Enter admin-password>

2. 新しいパスワードを入力します。
新規パスワードを再度入力するプロンプトが表示されます。

Enter admin-password again>

3. 新規パスワードを再度入力します。
次のメッセージが表示されます。

OTD-70201 Command 'reset-admin-password' ran successfully.

新規ユーザー名およびパスワードを有効にするには、2.4項「管理サーバーの停止および再起動」の説明に従い、管理サーバーを再起動するがあります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

11.1.2 管理サーバーのLDAP認証の構成

1人以上のユーザーが管理サーバーにログインできるようにする必要がある場合、ユーザーIDとパスワードをディレクトリ・サーバーに格納し、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)によりこのディレクトリ・サーバーにアクセスするようにOracle Traffic Directorを構成できます。

管理コンソールまたはCLIのいずれかを使用して、LDAP認証を有効化し、構成できます。

始める前に

LDAP認証を使用するためのOracle Traffic Directorの構成を開始する前に、次の情報を準備してください。次の情報は、Oracle Traffic DirectorがLDAPディレクトリ・サーバーにアクセスするために使用するldap(s)://host:port/baseDN URLを構成し、LDAPディレクトリ・サーバーが必要なユーザー・レコードを検索するために必要です。

- ディレクトリ・サーバーが実行されるホストの名前。

- LDAPクライアントからのリクエストをディレクトリ・サーバーがリスニングするポート番号。

- ディレクトリ・サーバーが必要なユーザー・レコードの検索を開始するディレクトリ情報ツリー内の場所である、ベース識別名(DN)。

- Oracle Traffic Directorが、LDAPディレクトリ・サーバーに対して自身の認証を行うために提供するユーザーIDとパスワードであるバインドDN。

注意:
ディレクトリ・サーバーで匿名クライアントによる検索が許可されている場合、バインドDNを指定する必要はありません。

- 管理サーバーにアクセスできるメンバーで構成されるユーザー・グループ。
管理サーバーでは、デフォルトで、グループwsadminに属しているユーザーのみがログインを許可されます。LDAP認証を有効化する際、属しているメンバーのログインが可能なグループwsadmin以外のグループのリストを指定できます。

管理コンソールを使用した管理サーバーのLDAP認証の構成

管理コンソールを使用して管理サーバーのLDAP認証を構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
使用可能なノードのリストが表示されます。

3. ノードのリストから、「管理サーバー」を選択します。

4. ナビゲーション・ペインで、「認証」を選択します。
「認証」ページが表示されます。

5. 「LDAP認証」を選択します。

6. 必須のパラメータ(ホスト名、ポート、ベースDN、および許可されているグループ)、および必要に応じてオプションのパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。
「コンソール・メッセージ」ペインに、更新した設定が保存されたことを示すメッセージが表示されます。

8. 「共通のタスク」ペインで、「再起動」をクリックして管理サーバーを再起動します。

CLIを使用した管理サーバーのLDAP認証の構成

- LDAP認証を有効化にするには、次の例に示すように、enable-admin-ldap-authコマンドを実行します。

> tadm enable-admin-ldap-auth
--ldap-url=ldap://ldap.example.com:3950/dc=example,dc=com
--bind-dn=cn="Directory Manager" --allow-groups=sys,adm,mgr
OTD-70213 The administration server must be restarted for the changes to take effect.

このコマンドでは、Oracle Traffic Directorがディレクトリ・サーバーldap.example.com:3950のLDAPクライアントとして構成されます。Oracle Traffic Directorは、バインドDNcn="Directory Manager"を使用して、ディレクトリ・サーバーに対して自身の認証を行い、ディレクトリ・サーバーは、ベースDNdc=example,dc=comで必要なユーザー・レコードの検索を開始します。

- LDAP認証を無効化にするには、次の例に示すように、disable-admin-ldap-authコマンドを実行します。

> tadm disable-admin-ldap-auth
OTD-70213 The administration server must be restarted for the changes to take effect.

- 現在構成されているLDAP認証を表示するには、次の例に示すようにget-admin-ldap-auth-propコマンドを実行します。

> tadm get-admin-ldap-auth-prop
enabled=true
ldap-url="ldap://ldap.example.com:3950/dc=example,dc=com"
search-filter=uid
group-search-filter=uniquemember
group-search-attr=CN
timeout=10
allow-group=sys,adm,mgr

enable-admin-ldap-auth、disable-admin-ldap-authおよびget-admin-ldap-auth-propCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

11.1.3 管理サーバーのPKCS#11トークンのPINの有効化

管理サーバーの自己署名証明書は、公開鍵暗号化標準(PKCS) 11に準拠したセキュリティ・データベースに格納されます。証明書データベースへは、internalという名前のトークンを使用してアクセスします。管理サーバーの証明書データベースへのアクセスを保護するために、internalトークンのPINを有効化できます。

管理サーバー構成内のinternal PKCS#11トークンのPINを有効化すると、次のタスクの実行時にトークンPINを入力するプロンプトが表示されます。

- 管理サーバーの起動。

- 管理サーバーの証明書の更新。

管理コンソールまたはCLIのいずれかを使用して、internalのPINを設定、変更または無効化できます。

管理コンソールを使用した管理サーバーのPKCS#11トークンのPINの設定

管理コンソールを使用して管理サーバーのPKCS#11トークンのPINを設定するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
使用可能なノードのリストが表示されます。

3. 「管理サーバー」ノードを選択します。
一般設定ページが表示されます。

4. 「トークンPIN管理」セクションで、「トークンPINの編集」チェック・ボックスを選択します。

- PINを設定するには、「新規PIN」および「新規PINの確認」フィールドにそれぞれPINを入力し、確認します。

- PINを変更するには、「現在のPIN」フィールドに現在のPINを入力します。次に、「新規PIN」および「新規PINの確認」フィールドにそれぞれ新しいPINを入力し、確認します。

- トークンのPINによる保護を無効化するには、「PINの設定解除」を選択します。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

5. 必要な変更を行った後、「保存」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

6. 「共通のタスク」ペインの「停止」をクリックして、管理サーバーを停止します。

7. 次のコマンドを実行して、管理サーバーを起動します。

> $INSTANCE_HOME/admin-server/bin/startserv

8. トークンのPINを入力するプロンプトで、手順4で指定したPINを入力します。

CLIを使用した管理サーバーのPKCS#11トークンのPINの設定

1. 次の例に従い、set-token-pinコマンドを実行します。

tadm> set-token-pin --config=admin-server --token=internal

トークンがPINによってすでに保護されている場合、現在のPINを入力するプロンプトが表示されます。現在のPINを入力し、プロンプトが表示されたら、新しいPINを入力し、確認します。

2. 2.4項「管理サーバーの停止および再起動」の説明に従い、管理サーバーを再起動します。

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

11.1.4 管理サーバー証明書の更新

自己署名管理サーバー証明書の有効期限を延長するには、renew-admin-certs CLIコマンドを実行します。

たとえば、次のコマンドでは、自己署名管理サーバー証明書の有効期限が、現在の日付の24か月後に設定されます。

tadm> renew-admin-certs --validity=24
OTD-70216 The administration server and the administration nodes need to be restarted for the changes to take effect.

--validityオプションを指定しない場合、有効期限は、現在の日付の12か月後に設定されます。

また、renew-admin-certsコマンドでは、現在アクセス可能な実行中のノードの証明書の更新も試行されます。証明書の更新プロセス中に、ノードがオフライン(実行されていない、またはネットワーク障害によりアクセス不可)の場合、後で、renew-node-certsコマンドをそのノードで実行し、管理サーバーから更新済の証明書をプルできます。

更新された証明書を有効にするには、管理サーバーおよびノードを再起動する必要があります。

注意:
管理サーバーの証明書を更新した後、最初にCLIまたは管理コンソールにアクセスするとき、証明書が信頼されていないソースからのものであるため、サーバーのアイデンティティを確認できないことを示すメッセージが表示されます。続行するには、自己署名証明書を信頼することを選択する必要があります。

証明書データベースへのインタフェースを提供するPKCS#11トークンがPINで保護されている場合(11.1.3項を参照)、トークンPINを入力するプロンプトが表示されます。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

この項では、SSL/TLSを使用して、クライアントとOracle Traffic Directorインスタンス間の通信を保護する方法について説明します。この項の情報は、SSL/TLS、証明書、暗号および鍵の概念を熟知している読者を対象としています。これらの概念の基本的な情報については、11.2.7項「SSL/TLSの概念」を参照してください。

この項には次の項目が含まれています。

- 11.2.1項「SSL/TLS構成プロセスの概要」

- 11.2.2項「リスナーのSSL/TLSの構成」

- 11.2.3項「仮想サーバーと証明書の関連付け」

- 11.2.4項「リスナーのSSL/TLS暗号の構成」

- 11.2.5項「証明書選択ロジック」

- 11.2.6項「厳密なSNIホスト一致について」

- 11.2.7項「SSL/TLSの概念」

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

Oracle Traffic DirectorインスタンスのSSL/TLSを有効化するには、RSAまたはECC証明書、あるいはその両方をインスタンスの1つ以上のリスナーに関連付ける必要があります。加えて、RSAまたはECC証明書、あるいはその両方を、仮想サーバーに直接関連付けることもできます。Oracle Traffic DirectorインスタンスのSSL/TLSを構成するプロセスには、次の手順が含まれます。

1. 自己署名証明書、VeriSign社などのサードパーティ認証局(CA)が発行した証明書または自分で生成した証明書を取得します。
詳細は、次の項を参照してください。

- 11.4.1項「自己署名証明書の作成」

- 11.4.2項「CA署名証明書の取得」

2. 11.4.3項「証明書のインストール」の説明に従い、証明書をインストールします。

3. 11.2.2項「リスナーのSSL/TLSの構成」の説明に従い、証明書を必要なHTTPリスナーまたはTCPリスナーに関連付けます。
11.2.3項「証明書と仮想サーバーの関連付け」の説明に従い、証明書を仮想サーバーに直接関連付けることもできます。Oracle Traffic Directorで、SSL/TLSハンドシェイク中にクライアントに送信される証明書の選択に使用されるロジックの詳細は、11.2.5項「証明書の選択ロジック」を参照してください。

4. 11.2.4項「リスナーのSSL/TLS暗号の構成」の説明に従い、HTTPリスナーまたはTCPリスナーにサポートされている暗号を構成します。

11.2.2 リスナーのSSL/TLSの構成

管理コンソールまたはCLIのいずれかを使用して、HTTPSリクエストまたはTCPリクエストを取得するリスナーを構成できます。開始する前に、必要な証明書を取得して、11.4.1項、11.4.2項および11.4.3項の説明に従いインストールします。

注意:

- リスナーを変更すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- 新しい証明書をリスナーに関連付ける、または以前に関連付けられていた証明書を削除する場合、変更を有効にするには、インスタンスを再起動する必要があります。更新された構成をデプロイするだけでは不十分です。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したリスナーのSSL/TLSの構成

管理コンソールを使用してHTTPリスナーまたはTCPリスナーのSSL/TLSを構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. SSL/TLSが有効化されたリスナーを構成する構成を選択します。

4. ナビゲーション・ペインで、「リスナー」を展開し、SSL/TLSを有効化し構成するリスナーを選択します。
「リスナー設定」ページが表示されます。

5. 「SSL設定」セクションで、「SSL有効」チェック・ボックスを選択します。

6. 「RSA証明書」および「ECC証明書」フィールドで、サーバーの認証に使用する証明書を選択します。
リスナーをRSA証明書およびECC証明書に関連付ける場合、サーバーがクライアントに最終的に提示する証明書は、クライアントとサーバーがネゴシエートして使用する暗号スイートに基づき、SSL/TLSハンドシェイク中に決定されます。

また、「リスナー設定」ページの「詳細設定」セクションで次の詳細なSSL/TLS設定も指定できます。

- クライアント認証の設定の有効化および無効化詳細は、11.8項「クライアント認証の構成」を参照してください。

- 厳密なSNIホスト一致の有効化および無効化。詳細は、11.2.6項「厳密なSNIホスト一致について」を参照してください。

- 次のTLS固有の機能の有効化および無効化

- バージョンのロールバック
Oracle Traffic DirectorでTLSバージョンのロールバックを検出し、試行をブロックするには、このチェック・ボックスを選択します。たとえば、クライアントがTLS 1.0をリクエストしたものの、攻撃者がより低いバージョン(たとえば、SSL 3.0)に変更した場合、Oracle Traffic Directorは、低いバージョンをサポートしていたとしても、このロールバックを検出しブロックします。

- セッション・チケット拡張
有効化した場合、TLSセッションは、サーバー上に各クライアントのセッション状態を格納することなく再開できます。Oracle Traffic Directorは、各クライアントのセッション状態をチケットにカプセル化し、クライアントにチケットを転送します。続いて、クライアントは、前に取得済のセッション・チケットを使用してTLSセッションを再開します。

- SSLおよびTLS暗号の有効化および無効化。詳細は、11.2.4項「リスナーのSSL/TLS暗号の構成」を参照してください。

画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。
更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

8. メインのペインの上部に表示されている「デプロイメント保留中」ボタンをクリックし、表示されたダイアログ・ボックスで「デプロイ」をクリックしてデプロイメントを確認します。

9. 「共通のタスク」ペインの「インスタンスの起動/再起動」をクリックして、構成のインスタンスを再起動します。

CLIを使用したリスナーのSSL/TLSの構成

- HTTPリスナーまたはTCPリスナーのSSL/TLSプロパティを表示するには、次の例に示すようにget-ssl-propコマンドを実行します。

tadm> get-ssl-prop --config=soa --http-listener=ls1
enabled=false
strict-sni-vs-host-match=false
client-auth=false
tls=true
max-client-auth-data=1048576
tls-session-tickets-enabled=false
ssl3=true
tls-rollback-detection=true
client-auth-timeout=60

- HTTPリスナーまたはTCPリスナーのSSL/TLSを構成するには、次の例に示すようにset-ssl-propコマンドを実行します。

tadm> set-ssl-prop --config=soa --http-listener=ls1 enabled=true server-cert-nickname=rsa-cert1
OTD-70201 Command 'set-ssl-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを実行して、構成をOracle Traffic Directorインスタンスにデプロイし、restart-instanceコマンドを実行してインスタンスを再起動します

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

注意:
HTTPリスナーまたはTCPリスナーのSSL/TLSを有効化すると、構成内の証明書データベースのPKCS#11暗号トークンの初期化が自動的に有効化されます。PKCS#11トークンの構成の詳細は、11.5項「PKCS#11トークンの管理」を参照してください。

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

管理コンソールまたはCLIのいずれかを使用して、1つのRSAおよび1つのECCを各仮想サーバーに関連付けることができます。Oracle Traffic Directorで、SSL/TLSハンドシェイク中にクライアントに送信される証明書の選択に使用されるロジックの詳細は、11.2.5項「証明書の選択ロジック」を参照してください。

開始する前に、必要な証明書を取得して、11.4.1項、11.4.2項および11.4.3項の説明に従いインストールします。

注意:

- 仮想サーバーを変更すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- 新しい証明書を仮想サーバーに関連付ける、または以前に関連付けられていた証明書を削除する場合、変更を有効にするには、インスタンスを再起動する必要があります。更新された構成をデプロイするだけでは不十分です。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した仮想サーバーと証明書の関連付け

管理コンソールを使用して仮想サーバーと証明書を関連付けるには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 仮想サーバーと証明書を関連付ける構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を展開し、証明書を関連付ける仮想サーバーを選択します。
「仮想サーバー設定」ページが表示されます。

5. 「仮想サーバー設定」ページの「証明書」セクションに移動します。

6. 「RSA証明書」および「ECC証明書」フィールドで、サーバーの認証に使用する証明書を選択します。
フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。
更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

8. メインのペインの上部に表示されている「デプロイメント保留中」ボタンをクリックし、表示されたダイアログ・ボックスで「デプロイ」をクリックしてデプロイメントを確認します。

9. 「共通のタスク」ペインの「インスタンスの起動/再起動」をクリックして、構成のインスタンスを再起動します。

CLIを使用した仮想サーバーと証明書の関連付け

- 仮想サーバーに現在関連付けられている証明書を表示するには、次の例に示すようにget-virtual-server-propコマンドを実行します。

tadm> get-virtual-server-prop --config=soa --vs=soa.example.com server-cert-nickname
cert-rsa-soa

- 仮想サーバーと証明書を関連付けるには、次の例に示すようにset-virtual-server-propコマンドを実行します。

tadm> set-virtual-server-prop --config=soa --vs=soa.example.com  server-cert-nickname=cert-ecc-soa
OTD-70201 Command 'set-virtual-server-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを実行して、構成をOracle Traffic Directorインスタンスにデプロイし、restart-instanceコマンドを実行してインスタンスを再起動します

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

注意:

- 仮想サーバーをRSA証明書およびECC証明書に関連付ける場合、サーバーがクライアントに最終的に送信する証明書は、クライアントとサーバーがネゴシエートして使用する暗号スイートに基づき、SSL/TLSハンドシェイク中に決定されます。

- 仮想サーバーに関連付ける証明書と同じタイプの証明書(ECCまたはRSA)が、仮想サーバーがバインドされているリスナーにも関連付けられていることを確認してください。

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

SSL/TLSハンドシェイクの実行中、クライアントとサーバーは、サポートしているSSLおよびTLSについて情報を交換し、SSL/TLSセッションに使用する暗号(通常、最も強力な暗号)をネゴシエートします。暗号についての基本的な概念の詳細は、「暗号について」を参照してください。

管理コンソールまたはCLIのいずれかを使用して、Oracle Traffic Directorがサポートしているリスナーの暗号を構成できます。

管理コンソールを使用したリスナーの暗号の構成

管理コンソールを使用してHTTPリスナーまたはTCPリスナーでサポートされる暗号を構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 暗号を構成する構成を選択します。

4. ナビゲーション・ペインで、「リスナー」を展開し、暗号を構成するリスナーを選択します。
「リスナー設定」ページが表示されます。

5. ページの「詳細設定」セクションに移動し、「SSL」サブセクションにスクロール・ダウンします。

6. 「SSL3/TLS暗号」フィールドで、リスナーで有効化する暗号のチェック・ボックスを選択し、無効化する暗号のチェック・ボックスの選択を解除します。

7. 必要な変更を行った後、「保存」をクリックします。
更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

8. メインのペインの上部に表示されている「デプロイメント保留中」ボタンをクリックし、表示されたダイアログ・ボックスで「デプロイ」をクリックしてデプロイメントを確認します。

9. 暗号の変更を有効化するには、「共通のタスク」ペインの「インスタンスの起動/再起動」をクリックして、構成のインスタンスを再起動します。

CLIを使用したリスナーの暗号の構成

- HTTPリスナーまたはTCPリスナーで現在有効化されている暗号を表示するには、次の例に示すようにlist-ciphersコマンドを実行します。

tadm> list-ciphers --config=soa --http-listener=http-listener-1|--tcp-listener=tcp-listener-1

このコマンドでは、Oracle Traffic Directorがサポートしているすべての暗号のリストが返され、その暗号がリスナーに対して有効化されているかどうかが示されます。

- リスナーの特定の暗号を有効化するには、enable-ciphersコマンドを実行します。
たとえば、次のコマンドでは、構成soa内のリスナーhttp-listener-1について、2つの追加の暗号(TLS_RSA_WITH_AES_128_CBC_SHAとTLS_RSA_WITH_AES_256_CBC_SHA)が有効化されます。

tadm> enable-ciphers --config=soa --http-listener=http-listener-1 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA

- リスナーの暗号を無効化するには、次の例に示すようにdisable-ciphersコマンドを実行します。

tadm> disable-ciphers --config=soa --http-listener=http-listener-1  TLS_RSA_WITH_AES_256_CBC_SHA
OTD-70201 Command 'disable-ciphers' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

Oracle Traffic Directorでサポートされている暗号スイート

SSL/TLSハンドシェイク中、Oracle Traffic Directorとクライアント間でどの暗号スイートを使用するかのネゴシエーションが行われます。表11-1に、Oracle Traffic Directorでサポートされている暗号スイートを示します。このリストは、この項で説明したCLIコマンドlist-ciphersを実行すると表示されます。各暗号スイートの名前は、鍵交換アルゴリズム、ハッシュ・アルゴリズム、暗号化アルゴリズムを表しています。

- サポートされるプロトコル

- TLS: TLS 1.0、1.1および1.2

- SSL: SSL 3およびTLS 1.0、1.1および1.2

- サポートされる鍵交換アルゴリズム

- RSA

- RSA_EXPORT

- RSA_EXPORT1024

- RSA_FIPS

- ECDHE_RSA

- ECDH_RSA

- ECDH_ECDSA

- ECDHE_ECDSA

- サポートされる暗号化アルゴリズム

- AES_256_CBC: 256ビット鍵

- CAMELLIA_256_CBC: 256ビット鍵

- 3DES_EDE_CBC: 168ビット鍵

- AES_128_CBC: 128ビット鍵

- CAMELLIA_128_CBC: 128ビット鍵

- RC4_128: 128ビット鍵

- SEED_CBC: 128ビット鍵

- DES_CBC: 56ビット鍵

- RC4_56: 56ビット鍵

- RC4_40およびRC2_CBC_40: 128ビット鍵。ただし、暗号化で意味を持つのは40ビットのみ

- NULL: 暗号化なし

- サポートされるメッセージ認証コード(MAC)アルゴリズム

- SHA: 160ビット・ハッシュ

- MD5: 128ビット・ハッシュ

- NULL: ハッシングなし

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

暗号スイート

エクスポート可能

SSL_RSA_WITH_RC4_128_SHA

SSL_RSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA

TLS_ECDH_RSA_WITH_RC4_128_SHA

TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDH_RSA_WITH_AES_256_CBC_SHA

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDH_ECDSA_WITH_RC4_128_SHA

TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

TLS_ECDHE_ECDSA_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_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_RSA_WITH_SEED_CBC_SHA

TLS_RSA_WITH_CAMELLIA_128_CBC_SHA

TLS_RSA_WITH_CAMELLIA_256_CBC_SHA

FIPS 40準拠に関する情報の出典: http://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html

11.2.5 証明書選択ロジック

HTTPSリクエストの受信時、Oracle Traffic DirectorがSSL/TLSハンドシェイク中に送信する証明書は、次のいずれかになります。

- 構成したHTTP/TCPリスナーにバインドされている仮想サーバーに関連付けられている証明書

- リスナーのデフォルト仮想サーバーに関連付けられている証明書

- リスナーに関連付けられている証明書

Oracle Traffic Directorは、次のロジックを使用して、SSL/TLSハンドシェイク中にクライアントに送信する証明書を決定します。

表11-2 証明書選択ロジック

条件

ケースA

ケースB

ケースC

ケースD

クライアントがSNIホスト拡張を送信しました

はい

はい

はい

いいえ

一致する脚注1仮想サーバーが見つかりました。

はい

いいえ

いいえ

--

一致する仮想サーバーに、クライアントから送信された暗号に一致する証明書タイプ(RSAまたはECC)があります。

はい

--

--

--

リスナーのデフォルト仮想サーバーに、クライアントから送信された暗号に一致する証明書タイプ(RSAまたはECC)があります。

--

はい

--

--

リスナーに、クライアントから送信された暗号に一致する証明書タイプ(RSAまたはECC)があります。

--

--

はい

はい

選択される証明書:

一致する仮想サーバーの証明書

デフォルト仮想サーバーの証明書

リスナーの証明書

リスナーの証明書

脚注1 一致する仮想サーバーとは、リスナーにバインドされている仮想サーバーで、クライアントから送信されたHost:ヘッダーと一致するホスト・パターンを持ちます。

11.2.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ホスト拡張内のホスト名を使用して、クライアントに送信する仮想サーバー証明書を特定します。仮想サーバーと証明書の関連付けの詳細は、11.2.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:ヘッダーと一致しません。

11.2.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のデジタル署名

- 証明書の有効期間

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

この項では、SSL/TLSを使用して、Oracle Traffic Directorインスタンスと、Oracle WebLogic ServerおよびOracle HTTP Serverインスタンスであるオリジン・サーバー間の通信をどのように保護するかについて説明します。この章の内容は、次のとおりです。

- 11.3.1項「一方向および双方向のSSL/TLSについて」

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

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

11.3.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またはオリジン・サーバー、あるいはその両方)が、証明書の交換中にホスト名を確認するように構成できます。

11.3.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管理コンソールからアクセス可能なWebLogic Serverプラグインの有効化属性が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.oracle.com/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コマンドの詳細は、http://docs.oracle.com/cd/E21764_01/web.1111/e13813/custom_infra_security.htm#CDDFDHDHにあるドキュメントを参照してください。

2. install-cert CLIコマンドを使用して、エクスポートしたルート証明書をOracle Traffic Directorの証明書データベースにインストールします。

注意:
管理コンソールを使用した証明書のインストールの詳細は、11.4.3項「管理コンソールを使用した自己署名またはCA署名の証明書のインストール」を参照してください。

構文:

tadm> install-cert --config=config_name --token=name --cert-type=ca --nickname=nickname cert_file

例:

tadm> install-cert --config=soa --token=internal --cert-type=ca --nickname=Server-Cert os_cert

注意:
オリジン・サーバーが自己署名証明書または異なるCAによって発行された証明書を使用している場合、手順1および2のかわりに次の操作を行います。

1. 手順1で使用した同じコマンドを使用して、各サーバー証明書、またはサーバー証明書に署名したCAの各ルート証明書をエクスポートします。

2. 手順2の説明に従い、install-cert CLIコマンドを使用して(ただし、--cert-type=serverを指定)、前の手順でエクスポートした各証明書をOracle Traffic Directorの証明書データベースにインストールします。

3. 11.4.7項「証明書を信頼するためのOracle Traffic Directorの構成」の説明に従い、オリジン・サーバーの各証明書を信頼するようにOracle Traffic Directorを構成します。

3. 必要に応じて、set-route-prop CLIコマンドを使用して、オリジン・サーバーの証明書のホスト名を確認するようにOracle Traffic Directorを構成します。
構文:

tadm> set-route-prop --config=config_name  --vs=vs_name --route=route_name validate-server-cert=true

例:

tadm> set-route-prop --config=soa  --vs=vs1 --route=route1 validate-server-cert=true

構成内の仮想サーバーのリスト、および仮想サーバーに定義されたルートを表示するには、list-virtual-serversおよびlist-routes CLIコマンドをそれぞれ使用します。

注意:
SSL/TLSハンドシェイク中に、オリジン・サーバーの証明書のホスト名を検証するようにOracle Traffic Directorを構成することを選択した場合、次の操作を行う必要があります。

- オリジン・サーバーの証明書内のサーバー名(CN)が、Oracle Traffic Director構成のオリジン・サーバー・プールで指定されているオリジン・サーバーのホスト名と一致することを確認します。オリジン・サーバー・プールの構成の詳細は、第6章「オリジン・サーバー・プールの管理」を参照してください。

- 動的検出が無効化されていること(デフォルト設定)を確認してください。動的検出の詳細は、6.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。

そうでない場合、オリジン・サーバーがその証明書を提示した際、Oracle Traffic Directorは証明書のホスト名を検証できず、このためSSL/TLSハンドシェイクが失敗します。

4. deploy-config CLIコマンドを使用して、更新された構成をOracle Traffic Directorインスタンスにデプロイします。

tadm> deploy-config config_name

注意:
この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

Oracle Traffic Directorとオリジン・サーバー間の双方向SSL/TLSを構成するには、次の操作を行います。

注意:
この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

1. 11.3.2項「Oracle Traffic Directorとオリジン・サーバー間の一方向SSL/TLSの構成」の説明に従い、一方向SSL/TLSを構成する手順を実行します。

2. 11.4.2項「CA署名証明書の取得」の説明に従い、CAによって発行されたOracle Traffic Directorのサーバー証明書を取得します。

3. 11.4.3項「証明書のインストール」の説明に従い、CAによって発行された証明書をOracle Traffic Director構成にインストールします。

4. enable-route-auth CLIコマンドを使用して、Oracle Traffic Directorがオリジン・サーバーに提示する必要がある証明書を指定し、必要なOracle Traffic Directorルートを構成します。
構文:

tadm> enable-route-auth --config=config_name --vs=vs_name --route=route_name --client-cert-nickname=cert_nickname

例:

tadm> enable-route-auth --config=soa --vs=vs1 --route=route1 --client-cert-nickname=soa_cert

構成内の仮想サーバーのリスト、および仮想サーバーに定義されたルートを表示するには、list-virtual-serversおよびlist-routes CLIコマンドをそれぞれ使用します。

5. deploy-config CLIコマンドを使用して、更新された構成をOracle Traffic Directorインスタンスにデプロイします。

tadm> deploy-config config_name

6. Oracle Traffic Directorインスタンスの証明書に署名したCAのルート証明書を、Oracle Traffic Director証明書データベースから.pem形式にエクスポートします。
構文:

> $ORACLE_HOME/bin/certutil -L -d certdir -n nickname -a -o output_cert_file

certdirは、ルート証明書のエクスポート元であるOracle Traffic Directorインスタンスのconfigディレクトリのフル・パス、nicknameは、エクスポートする証明書のニックネーム、output_cert_fileは、証明書のエクスポート先である.pemファイルの名前です。

例:

> $ORACLE_HOME/bin/certutil -L -d ../net-test/config/ -n rootca -a -o /tmp/rootca1.pem

certutilコマンドの詳細は、次のコマンドを実行してください。

> $ORACLE_HOME/bin/certutil -H

7. 前の手順でエクスポートしたルート証明書を、Oracle WebLogic Serverオリジン・サーバー(およびOracle HTTP Serverオリジン・サーバーのOracleウォレット)の信頼キーストアにインポートします。

- Oracle WebLogic Serverオリジン・サーバーの場合:
Java SE 6で使用可能なkeytoolコマンドを使用します。

構文:

> $JAVA_HOME/bin/keytool -importcert -v -trustcacerts -alias alias
-file cert_file -keystore keystore_file -storepass keystore_password
-noprompt

aliasは前の手順でエクスポートされたCA発行のルートCAのニックネーム、fileはエクスポートされた.pem証明書ファイルの名前、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.oracle.com/javase/6/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コマンドの詳細は、http://docs.oracle.com/cd/E21764_01/web.1111/e13813/custom_infra_security.htm#CDDGIBEJにあるドキュメントを参照してください。

8. SSL/TLSハンドシェイク中にOracle Traffic Directorにそのクライアント証明書の提示を要求するように、オリジン・サーバーを構成します。

- Oracle WebLogic Serverオリジン・サーバーの場合:
http://docs.oracle.com/cd/E21764_01/apirefs.1111/e13952/taskhelp/security/ConfigureTwowaySSL.htmlにあるOracle WebLogic Server管理コンソール・オンライン・ヘルプの双方向SSLの構成に関する項の説明に従い、手順を実行します。

注意:
Oracle WebLogic Serverでは、デフォルトでホスト名の確認が有効化されています。ホスト名の確認の無効化の詳細は、http://docs.oracle.com/cd/E21764_01/apirefs.1111/e13952/taskhelp/security/DisableHostNameVerification.htmlにあるOracle WebLogic Server管理コンソール・オンライン・ヘルプのホスト名の確認の無効化に関する項を参照してください。

- Oracle HTTP Serverオリジン・サーバーの場合:
httpd.confファイルに次のディレクティブを追加します。

SSLVerifyClient require

11.4 証明書の管理

この項には次のトピックが含まれます:

- 11.4.1項「自己署名証明書の作成」

- 11.4.2項「CA署名証明書の取得」

- 11.4.3項「証明書のインストール」

- 11.4.4項「証明書のリストの表示」

- 11.4.5項「サーバー証明書の更新」

- 11.4.6項「証明書の削除」

- 11.4.7項「証明書を信頼するためのOracle Traffic Directorの構成」

注意:

- この項の情報は、SSL、証明書、暗号および鍵の概念を熟知している読者を対象としています。これらの概念の基本的な情報については、11.2.7項「SSL/TLSの概念」を参照してください。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

11.4.1 自己署名証明書の作成

証明書にCAによる署名が必要ない場合、または、CAが証明書の署名プロセス中にSSL/TLSの実装をテストする場合、自己署名証明書を作成できます。

自己署名証明書を使用して、Oracle Traffic Director仮想サーバーのSSL/TLSを有効化している場合、クライアントが仮想サーバーのhttps:// URLにアクセスすると、署名しているCAが不明であり信頼されていないことを示すエラー・メッセージが表示されます。接続を続行するために、クライアントは、自己署名証明書を信頼するように選択できます。

管理コンソールまたはCLIのいずれかを使用して、自己署名証明書を作成できます。

始める前に

自己署名証明書または証明書署名リクエストを作成する前に、次の項目を決定します。

- DNS参照で使用される完全修飾ホスト名(例: www.example.com)。
クライアント・リクエストのホスト名が、証明書上の名前と一致しない場合、クライアントに、証明書のサーバー名がホスト名と一致しないことが通知されます。

注意:
高可用性のシナリオでは、サーバーの証明書のサーバー名(CN)と、OTDインスタンスがリスニングするVIPのホスト名が一致している必要があります。

- 証明書のニックネーム(自己署名証明書を作成する場合にのみ必要)。

- 証明書の月単位の有効期間(自己署名証明書を作成する場合にのみ必要)。

- 鍵のタイプ(RSAまたはECC)。
Oracle Traffic Directorは、従来のRSAタイプの鍵、およびより高度な楕円曲線暗号(ECC)鍵の生成をサポートしています。ECCは、演算処理の高速化、電力消費の低減およびメモリーと帯域幅の節約を図れる、小さいサイズの鍵と同等のセキュリティを提供します。

- 鍵サイズ(RSA)または曲線(ECC)。
RSA鍵では、1024、2048、3072または4096ビットを指定できます。鍵の桁が多いほど、暗号化の強度は向上しますが、Oracle Traffic Directorは生成するのにより長い時間を必要とします。

ECCでは、鍵のペアを生成するための曲線を指定する必要があります。Oracle Traffic Directorは、次の曲線をサポートしています。prime256v1、secp256r1、nistp256、secp256k1、secp384r1、nistp384、secp521r1、nistp521、sect163k1、nistk163、sect163r1、sect163r2、nistb163、sect193r1、sect193r2、sect233k1、nistk233、sect233r1、nistb233、sect239k1、sect283k1、nistk283、sect283r1、nistb283、sect409k1、nistb409、sect571k1、nistk571、sect571r1、nistb571、secp160k1、secp160r1、secp160r2、secp192k1、secp192r1、nistp192、secp224k1、secp224r1、nistp224、prime192v1

管理コンソールを使用した自己署名証明書の作成

管理コンソールを使用して自己署名証明書を作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 自己署名証明書を作成する構成を選択します。

4. ナビゲーション・ペインで、「SSL」を展開し、「サーバー証明書」を選択します。
「サーバー証明書」ページが表示されます。

5. 「新規自己署名証明書」ボタンをクリックします。
新規自己署名証明書ウィザードが開始されます。

図11-1 新規自己署名証明書ウィザード

注意:
構成の証明書および鍵が格納されるPKCS#11トークンがPINによって保護されている場合、ウィザードの最初の画面には、トークンを選択し、PINを入力するためのプロンプトが表示されます。

1. 適切なトークンを選択します。
鍵が、Oracle Traffic Directorによって管理されているローカル・キー・データベースに格納されている場合、internalトークンを選択します。

鍵がスマート・カード、または外部のデバイスまたはエンジンに格納されている場合、その外部トークンの名前を選択します。

2. 選択したトークンのPINを入力します。

管理コンソール・セッションで、トークンのPINを繰返し入力しないで済むようにするために、「管理コンソール・セッションでのトークンのPINのキャッシュ」の説明に従い、PINをキャッシュできます。

6. 画面上のプロンプトに従い、前に決定済の詳細(サーバー名、証明書のニックネーム、有効性、鍵タイプなど)を使用して、証明書の作成を完了します。
証明書が作成された後、新規自己署名証明書ウィザードの「結果」画面に証明書の作成が成功したことを示すメッセージが表示されます。

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

- 「コンソール・メッセージ」ペインに、証明書が作成されたことを確認するメッセージが表示されます。

- 作成した証明書は、「サーバー証明書」ページに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用した自己署名証明書の作成

自己署名証明書を作成するには、次の例に示すように、create-selfsigned-certコマンドを実行します。

tadm> create-selfsigned-cert --config=soa --server-name=soa.example.com
--nickname=cert-soa
OTD-70201 Command 'create-selfsigned-cert' ran successfully.

このコマンドでは、構成soaのサーバーsoa.example.comに対して、ニックネームcert-soaでデフォルト期間である12か月間有効な自己署名証明書が作成されます。鍵タイプおよびその他のパラメータは指定されていないため、長さが2048ビット(デフォルト)であるRSAタイプ(デフォルト)の証明書が作成されます。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

11.4.2 CA署名証明書の取得

認証局(CA)によって署名された証明書を取得するには、「証明書署名リクエスト(CSR)」をCAに送信し、必要に応じて規定の料金を支払ったら、CAによってリクエストが承認され証明書が付与されるのを待ちます。

CSRは、サーバー名、組織名、国などの情報を含むデジタル・ファイル(Base-64でエンコーディングされたPEM形式の暗号化済テキスト・ブロック)です。また、証明書に含められる公開鍵も含まれます。

Oracle Traffic Directorの管理コンソールまたはCLIのいずれかを使用して、CSRを作成できます。

始める前に

CSRの作成を開始する前に、サーバー名、鍵タイプ、鍵サイズ(RSA用)または曲線(ECC用)を、11.4.1項「自己署名証明書の作成」の説明に従い決定します。

注意:
高可用性のシナリオでは、サーバーの証明書のサーバー名(CN)と、OTDインスタンスがリスニングするVIPのホスト名が一致している必要があります。

管理コンソールを使用したCSRの作成

管理コンソールを使用してCSRを作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. CSRを作成する構成を選択します。

4. ナビゲーション・ペインで、「SSL」を展開し、「サーバー証明書」を選択します。
「サーバー証明書」ページが表示されます。

5. 「証明書リクエストの作成」ボタンをクリックします。
「証明書署名リクエストの作成」ウィザードが起動されます。

図11-2 「証明書署名リクエストの作成」ウィザード

注意:
構成の証明書および鍵が格納されるPKCS#11トークンがPINによって保護されている場合、ウィザードの最初の画面には、トークンを選択し、PINを入力するためのプロンプトが表示されます。

1. 適切なトークンを選択します。
鍵が、Oracle Traffic Directorによって管理されているローカル・キー・データベースに格納されている場合、internalトークンを選択します。

鍵がスマート・カード、または外部のデバイスまたはエンジンに格納されている場合、その外部トークンの名前を選択します。

2. 選択したトークンのPINを入力します。

管理コンソール・セッションで、トークンのPINを繰返し入力しないで済むようにするために、「管理コンソール・セッションでのトークンのPINのキャッシュ」の説明に従い、PINをキャッシュできます。

6. 画面上のプロンプトに従い、前に決定済の詳細(サーバー名、鍵タイプなど)を使用して、CSRの作成を完了します。
CSRが作成された後、「証明書署名リクエストの作成」ウィザードの「結果」画面に、次の例に示すように、CSRの暗号化されたテキストが表示されます。

-----BEGIN NEW CERTIFICATE REQUEST-----
MIICmDCCAYACAQAwDDEKMAgGA1UEAxMBeTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMBzgU1mQJrQYQOiedKVpQVedJplQT1gh943RfNfCsl6VbD1Kid8
...
lines deleted
...
v6PWA9azqAfnJ8IriK6xTMQ54oQNzSALEKvIGb+jBUUzo2S+UiEr+VXvfPAdHnPX
2ZBCA4qvPr477lETgPphfxDjjvvH+EKrZMClM4JkJ4g3p+X0X+5vz53w964=
-----END NEW CERTIFICATE REQUEST-----

7. ヘッダー行BEGIN NEW CERTIFICATE REQUESTおよびフッター行END NEW CERTIFICATE REQUESTを含むCSRテキストをコピーし格納して、「閉じる」をクリックします。

CSRには、SSLを有効化するOracle Traffic Directorサーバーのアイデンティティを確認するためにCAが必要とする公開鍵およびその他の情報が含まれます。秘密鍵は、INSTANCE_HOME/net-config_name/config/key4.dbファイルに暗号化された形式で格納されます。

これで、選択したCAに証明書の署名料金とともにCSRを送信できるようになりました。

CLIを使用したCSRの作成

CSRを作成するには、次の例に示すように、create-cert-requestコマンドを実行します。

tadm> create-cert-request--config=soa --server-name=soa.example.com
--token=internal
OTD-70201 Command 'create-selfsigned-cert' ran successfully.

このコマンドでは、CSRが作成され、「管理コンソールを使用した自己署名証明書の作成」に示すように、CSRの暗号化されたテキストが表示されます。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

作成したCSRに対応する、CA署名証明書を取得した後、11.4.3項「証明書のインストール」の説明に従い、適切な構成に証明書をインストールする必要があります。

11.4.3 証明書のインストール

管理コンソールまたはCLIのいずれかを使用して、自己署名またはCA署名の証明書をインストールできます。また、pk12utilユーティリティを使用して既存の証明書をインストールすることもできます。

この項には次のトピックが含まれます:

- 11.4.3項「管理コンソールを使用した自己署名またはCA署名の証明書のインストール」

- 11.4.3項「CLIを使用した自己署名またはCA署名の証明書のインストール」

- 11.4.3項「pk12utilを使用した既存の証明書のインストール」

管理コンソールを使用した自己署名またはCA署名の証明書のインストール

管理コンソールを使用して自己署名またはCA署名の証明書をインストールするには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 証明書をインストールする構成を選択します。

4. ナビゲーション・ペインで、「SSL」を展開し、「サーバー証明書」または「認証局」を選択します。

- 自己署名証明書またはCA署名証明書をインストールするには、「サーバー証明書」を選択します。

- ルート証明書または証明書チェーンをインストールするには、「認証局」を選択します。

5. 「証明書のインストール」ボタンをクリックします。
「サーバー証明書」ページまたは「認証局」ページのいずれの「証明書のインストール」ボタンをクリックしたかによって、証明書のインストール・ウィザードまたはサーバー証明書のインストール・ウィザード(図11-3)が起動されます。

図11-3 サーバー証明書のインストール・ウィザード

注意:
構成の証明書および鍵が格納されるPKCS#11トークンがPINによって保護されている場合、ウィザードの最初の画面には、トークンを選択し、PINを入力するためのプロンプトが表示されます。

1. 適切なトークンを選択します。
鍵が、Oracle Traffic Directorによって管理されているローカル・キー・データベースに格納されている場合、internalトークンを選択します。

鍵がスマート・カード、または外部のデバイスまたはエンジンに格納されている場合、その外部トークンの名前を選択します。

2. 選択したトークンのPINを入力します。

管理コンソール・セッションで、トークンのPINを繰返し入力しないで済むようにするために、「管理コンソール・セッションでのトークンのPINのキャッシュ」の説明に従い、PINをキャッシュできます。

6. .pemファイルから証明書テキストを貼り付けるか、証明書ファイルのパス名を指定します。
証明書のテキストを貼り付けることを選んだ場合、次の例に示すように、ヘッダーのBEGIN CERTIFICATEおよびEND CERTIFICATEを始まりと終わりのハイフンを含めて、貼り付けるようにします。

-----BEGIN CERTIFICATE-----
MIIEuTCCA6GgAwIBAgIQQBrEZCGzEyEDDrvkEhrFHTANBgkqhkiG9w0BAQsFADCB
vTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
...
lines deleted
...
lRQOfc2VNNnSj3BzgXucfr2YYdhFh5iQxeuGMMY1v/D/w1WIg0vvBZIGcfK4mJO3
7M2CYfE45k+XmCpajQ==
-----END CERTIFICATE-----

パス名を指定する場合は、ファイルが管理サーバーにあることを確認してください。

7. 画面上のプロンプトに従い、証明書のインストールを完了します。

CLIを使用した自己署名またはCA署名の証明書のインストール

自己署名またはCA署名の証明書をインストールするには、次の例に示すように、install-certコマンドを実行します。

tadm> install-cert --config=soa --token=internal --cert-type=server --nickname=soa-cert /home/admin/certs/verisign-cert.cer

--cert-typeオプションでは、証明書タイプ(サーバーまたはCA)を指定します。このコマンドでは、構成soaにニックネームsoa-certでサーバー証明書がインストールされます。CA証明書をインストールするには、--cert-typeオプションでcaを指定します。--nicknameオプションは、caおよびchain証明書タイプをインストールする場合には必須ではありません。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

pk12utilを使用した既存の証明書のインストール

コマンドライン・ユーティリティpk12utilを使用して、既存の証明書と秘密鍵を内部または外部のPKCS#11モジュールにインポートできます。デフォルトでpk12utilは、証明書と秘密鍵データベース(cert7.dbおよびkey3.db)を使用します。

既存の証明書をインストールするには、次の手順を実行します。

1. パスにORACLE_HOME/libを追加します。

2. 次のようにpk12utilコマンドを実行します。

pk12util -i importfile [-d certdir] [-P dbprefix] [-h tokenname] [-k slotpwfile | -K slotpw] [-w p12filepwfile | -W p12filepw] [-v]

注意:

- オプション-Pを最後の引数として-hオプションの後に指定する必要があります。

- トークン名は、大文字小文字の区別や引用符間のスペースを含め正確に入力してください。

たとえば、次のコマンドはPKCS12でフォーマットされた証明書をNSS証明書データベースにインポートします。

pk12util -i certandkey.p12 [-d certdir][-h "nCipher"][-P https-jones.redplanet.com-jones-
]

3. データベースまたはトークンのパスワード(あるいはその両方)を入力します。PKCS#11トークンの詳細は、11.5項「PKCS#11トークンの管理」を参照してください。

4. インストールした証明書を1つ以上のリスナーに関連付けます。詳細は、11.2.2項「リスナーのSSL/TLSの構成」を参照してください。

11.4.4 証明書リストの表示

管理コンソールまたはCLIのいずれかを使用して、構成にインストールされている証明書のリストを表示できます。

管理コンソールを使用した証明書のリストの表示

管理コンソールを使用して構成にインストールされている証明書のリストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 証明書を表示する構成を選択します。

4. ナビゲーション・ペインで、「SSL」を展開し、「サーバー証明書」または「認証局」を選択します。

- 構成にインストールされている自己署名証明書またはCA署名証明書を表示するには、「サーバー証明書」を選択します。

- ルート証明書または証明書チェーンを表示するには、「認証局」を選択します。

結果のページに、インストールされている証明書が表示されます。

注意:
選択した構成でトークンに対してPINが有効化されている場合、インストールされている証明書は表示されません。かわりに、トークンのPINを入力するメッセージがページに表示されます。

1. 「トークンPINのキャッシュ」をクリックします。

2. 表示されたダイアログ・ボックスで、トークンのPINを入力し、「OK」をクリックします。

CLIを使用した証明書のリストの表示

- 構成にインストールされた証明書のリストを表示するには、次の例に示すようにlist-certsコマンドを実行します。

- 次のコマンドでは、構成soaのサーバー証明書のリストが表示されます。

tadm> list-certs --config=soa --verbose --all
nickname        issuer-name     expiry-date
-------------------------------------------
cert-adf        adf             "Aug 17, 2012 5:32:40 AM"
cert-soa        soa             "Aug 17, 2012 5:32:26 AM"

- 次のコマンドでは、構成soaにインストールされたCA証明書の部分的なリストが表示されます。

tadm> list-certs --config=soa --server-type=ca --verbose --all
nickname        issuer-name     expiry-date
-------------------------------------------
"Builtin Object Token:GlobalSignRootCA" "GlobalSign" "Jan 28, 2028 4:00:00 AM"
"Builtin Object Token:GlobalSignRootCA-R2" "GlobalSign" "Dec 15, 2021 12:00:00 AM"

- 証明書のプロパティを表示するには、次の例に従い、get-cert-propコマンドを実行します。

tadm> get-cert-prop --config=soa --nickname=cert-soa
nickname=cert-soa
subject="CN=soa.example.com"
server-name=soa.example.com
issuer="CN=soa.example.com"
serial-number=00:95:9C:34:04
fingerprint=34:E7:52:5E:3F:0A:EE:30:ED:BF:96:81:DD:1E:A3:02
key-type=rsa
key-size=2048
issue-date=Sep 14, 2011 12:22:41 AM
expiry-date=Sep 14, 2012 12:22:41 AM
is-expired=false
is-read-only=false
is-self-signed=true
is-user-cert=true
is-ca-cert=false
has-crl=false

注意:
指定した構成でPINがトークンに対して有効化されている場合、list-certsおよびget-cert-propコマンドを実行する際トークンPINを入力するプロンプトが表示されます。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

11.4.5 サーバー証明書の更新

証明書を更新するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 証明書を更新する構成を選択します。

4. ナビゲーション・ペインで、「SSL」を展開し、「サーバー証明書」を選択します。
結果のページに、インストールされているサーバー証明書が表示されます。

注意:
選択した構成でトークンに対してPINが有効化されている場合、インストールされている証明書は表示されません。かわりに、トークンのPINを入力するメッセージがページに表示されます。

1. 「トークンPINのキャッシュ」をクリックします。

2. 表示されたダイアログ・ボックスで、トークンのPINを入力し、「OK」をクリックします。

5. 更新する証明書の「更新」ボタンをクリックします。
「サーバー証明書の更新」ダイアログ・ボックスが表示されます。

6. 新しい有効期間を指定し、「次」をクリックします。

7. 「証明書の更新」をクリックします。

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

- 「コンソール・メッセージ」ペインに、指定した期間に対して証明書が更新されたことを確認するメッセージが表示されます。

- 証明書の新しい有効期限が、「サーバー証明書」ページに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

11.4.6 証明書の削除

管理コンソールまたはCLIのいずれかを使用して、構成の証明書を削除できます。

管理コンソールを使用した証明書の削除

管理コンソールを使用して構成内の証明書を削除するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 証明書を削除する構成を選択します。

4. ナビゲーション・ペインで、「SSL」を展開し、「サーバー証明書」または「認証局」を選択します。

- 自己署名証明書またはCA署名証明書を削除するには、「サーバー証明書」を選択します。

- ルート証明書または証明書チェーンを削除するには、「認証局」を選択します。

結果のページに、インストールされている証明書が表示されます。

注意:
選択した構成でトークンに対してPINが有効化されている場合、インストールされている証明書は表示されません。かわりに、トークンのPINを入力するメッセージがページに表示されます。

1. 「トークンPINのキャッシュ」をクリックします。

2. 表示されたダイアログ・ボックスで、トークンのPINを入力し、「OK」をクリックします。

5. 削除する証明書の「削除」ボタンをクリックします。

- 1つ以上のリスナーが削除中の証明書と関連付けられている場合、その証明書を削除できないことを示すメッセージが表示されます。

- 削除中の証明書が、いずれのリスナーにも関連付けられていない場合、証明書の削除を確認するプロンプトが表示されます。
「OK」をクリックして進みます。

「コンソール・メッセージ」ペインに、証明書が削除されたことを確認するメッセージが表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用した証明書の削除

証明書を削除するには、delete-certコマンドを実行します。

たとえば、次のコマンドでは、構成soaからニックネームrsa-cert-1の証明書が削除されます。

tadm> delete-cert --token=internal --config=soa rsa-1

削除しようとしている証明書が1つ以上のリスナーに関連付けられている場合、次のメッセージが表示されます。

OTD-64309 Certificate 'rsa-1' is being referred by listeners: listener1,listenerN

--forceオプションを指定することで、証明書を強制的に削除できます。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

11.4.7 証明書を信頼するためのOracle Traffic Directorの構成

Oracle Traffic Directorの組込み証明書データベースには、VeriSignなどの一般的な商用CAからの証明書を含む、事前インストール済のルート証明書がいくつか含まれます。また、管理コンソールおよびCLIを使用して、特定のCAによって署名された証明書を信頼するようにOracle Traffic Directorを構成できます。

管理コンソールを使用した証明書の信頼フラグの構成

管理コンソールを使用して、Oracle Traffic Directorが特定のCAによって署名された証明書を信頼するかどうかを指定するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 証明書信頼フラグを変更する構成を選択します。

4. ナビゲーション・ペインで、「SSL」を展開し、「認証局を選択します。
結果のページに、インストールされている証明書が表示されます。

注意:
選択した構成でトークンに対してPINが有効化されている場合、インストールされている証明書は表示されません。かわりに、トークンのPINを入力するメッセージがページに表示されます。

1. 「トークンPINのキャッシュ」をクリックします。

2. 表示されたダイアログ・ボックスで、トークンのPINを入力し、「OK」をクリックします。

5. 信頼フラグを変更する証明書のニックネームをクリックします。
「認証局の編集」ダイアログ・ボックスが表示されます。

6. 「クライアント証明書の署名について信頼済」または「サーバー証明書の署名について信頼済」チェック・ボックスを必要に応じて選択します。

7. 「保存」をクリックします。
「コンソール・メッセージ」ペインに、選択した証明書の信頼フラグが更新されたことを確認するメッセージが表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用した証明書の信頼フラグの構成

Oracle Traffic Directorが特定のCAによって署名された証明書を信頼するかどうかを指定するには、set-cert-trust-propコマンドを実行します。

たとえば、次のコマンドでは、クライアントとサーバーの証明書を署名するために信頼する証明書が、構成soaにニックネームVisa eCommerce Rootで構成されます。

tadm> set-cert-trust-prop --config=soa --nickname="Visa eCommerce Root"
is-client-ca=true is-server-ca=true
OTD-70201 Command 'set-cert-trust-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

11.5 PKCS#11トークンの管理

PKCS#11トークンは、公開鍵暗号化標準(PKCS) 11に準拠した、デジタル証明書およびキーを格納できるセキュリティ・データベースへのソフトウェアまたはハードウェア・インタフェースです。Oracle Traffic Directorには、組込みネットワーク・セキュリティ・サービス(NSS)証明書データベースへのインタフェースを提供するinternalという名前のトークンが含まれます。他のPKCS#11準拠のデータベースが管理サーバー・ホスト上で使用可能な場合、Oracle Traffic Directorは、自動的にこれらを認識し、ハードウェア・アクセラレータおよびスマート・カードなどの物理デバイスを介して実装されるトークンも含め対応するトークンを公開します。

注意:
この項の情報は、SSL、証明書、暗号および鍵の概念を熟知している読者を対象としています。これらの概念の基本的な情報については、11.2.7項「SSL/TLSの概念」を参照してください。

Oracle Traffic Directorに対するPKCS#11トークンの初期化を有効化および無効化でき、トークンのPINを有効化できます。

- PKCS#11トークンの初期化が構成に対して有効化されている場合、およびPINがトークンのいずれかに有効化されている場合、構成のインスタンスの起動を試みると、PINが有効化されているトークンのPINを入力するためのプロンプトが表示されます。
インスタンスの起動時に毎回トークンのPINを入力しないで済むように、PINを指定する際、この項で後述するように、構成ファイルにPINを保存するように選択できます。

- 構成内でトークンのPINが有効化されている場合、いかなる目的でも(たとえば、インストール済の証明書を表示する、または証明書をインストールするなど)トークンによって示されている証明書データベースにアクセスする場合は、トークンを選択し、トークンのPINを入力するためのプロンプトが表示されます。トークンのPINを繰返し入力しないで済むようにするために、「管理コンソール・セッションでのトークンのPINのキャッシュ」の説明に従い、PINをキャッシュできます。

管理コンソールまたはCLIのいずれかを使用して、PKCS#11を構成できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したPKCS#11設定の構成

管理コンソールを使用してPKCS#11トークンを構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. トークンを構成する構成を選択します。

4. ナビゲーション・ペインで、「SSL」を選択します。
「SSL設定」ページが表示されます。「暗号トークン」セクションには、PKCS#11トークンに関連するパラメータが含まれます。

- PKCS#11トークンの初期化を有効化するには、「PKCS#11トークン」チェック・ボックスを選択します。

- Oracle Traffic Directorで、SSL/TLSプロセス中のPKCS#11層の処理を省略するには、「PKCS#11バイパスの許可」チェック・ボックスを選択します。PKCS#11層を省略するとパフォーマンスが向上します。

- トークンを有効化または無効化したり、トークンのPINを設定または変更したりするには、トークンの名前をクリックします。
「トークンの編集」ダイアログ・ボックスが表示されます。

- トークンを有効化するには、「トークンの状態」チェック・ボックスを選択します。

- トークンのPINを有効化するには、「トークンPINの設定」チェック・ボックスを選択します。
新しいPINを入力し、確認します。

- トークンのPINを変更するには、「トークンPINの編集」チェック・ボックスを選択します。
現在のPINを入力し、続いて新しいPINを入力して、確認します。

- トークンのPINを無効化するには、「トークンPINの編集」チェック・ボックスを選択します。
現在のPINを入力し、「PINの設定解除」チェック・ボックスを選択します。

注意:

- 「PINの保存」を選択した場合、トークンのPINは構成ファイルに保存されます。構成のインスタンスを起動する際、トークンのPINを入力するプロンプトはユーザーに表示されません。

- トークンのPINを設定または変更し、構成ファイル内に保存しないことを選択して、サーバーの再起動を選択した場合、サーバーを停止し、再度起動する必要があります。restart-admin CLIコマンド、または管理コンソールを使用して、サーバーを再起動することはできません。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、「保存」ボタンが有効になります。

5. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したPKCS#11設定の構成

- PKCS#11トークンの初期化を有効化または無効化するには、次の例に示すように、set-pkcs11-propコマンドを実行します。

tadm> set-pkcs11-prop --config=soa enabled=true
OTD-70201 Command 'set-pkcs11-prop' ran successfully.

- 構成内の使用可能なPKCS#11トークンを表示するには、次の例に示すように、list-tokensコマンドを実行します。

tadm> list-tokens --config=soa --verbose --all
name            enabled         has-saved-pin
---------------------------------------------
internal        false           false

- トークンを有効化または無効化するには、次の例に示すように、set-token-propコマンドを実行します。

tadm> set-token-prop --config=soa --token=internal enabled=true
OTD-70201 Command 'set-token-prop' ran successfully.

- トークンのPINを設定または変更するには、次の例に示すように、set-token-pinコマンドを実行します。

tadm> set-token-pin --config=soa --token=internal

トークンがPINによってすでに保護されている場合、現在のPINを入力するプロンプトが表示されます。現在のPINを入力し、プロンプトが表示されたら、新しいPINを入力し、確認します。

注意:
PKCS#11トークンの初期化を有効化し(set-pkcs11-prop ... enabled=true)、PINがトークンのいずれかに有効化されている場合、構成のインスタンスの起動または再起動を試みると、PINが有効化されているトークンのPINを入力するためのプロンプトが表示されます。PINのプロンプトが表示されないようにするには、set-token-pinコマンドで--save-pin=trueオプションを指定し、構成ファイルにPINを保存します。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

管理コンソール・セッションでのトークンPINのキャッシュ

構成内でトークンのPINが有効化されている場合、いかなる目的でも(たとえば、インストール済の証明書を表示する、または証明書をインストールするなど)トークンによって示されている証明書データベースにアクセスする場合は、トークンを選択し、トークンのPINを入力するためのプロンプトが表示されます。管理コンソールを使用して証明書を管理している場合、トークンのPINを1度指定し、セッションが続いている間(つまり、ログアウトするかセッションがタイムアウトになるまで)キャッシュすることで、PINを繰返し入力する必要がなくなります。

管理コンソールのセッションで、トークンのPINをキャッシュするには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. トークンのPINをキャッシュする構成を選択します。

4. ナビゲーション・ペインで、「SSL」を展開し、「サーバー証明書」または「認証局」を選択します。

5. 「トークンPINのキャッシュ」をクリックします。
「トークンPINのキャッシュ」ダイアログ・ボックスが表示されます。

6. トークンのPINを入力します。

7. 「OK」をクリックします。
「コンソール・メッセージ」ペインに、そのセッションでトークンのPINがキャッシュされたことを確認するメッセージが表示されます。

11.6 証明書失効リストの管理

証明書失効リスト(CRL)は、CAが証明書の期限が切れる前に失効させることを決定した証明書についてCAがユーザーに通知するために発行するリストです。CRLは定期的に更新され、更新されたCRLはCAのWebサイトからダウンロードできます。

Oracle Traffic Directorサーバーが、CAが失効させた証明書を信頼しないようにするために、最新のCRLをCAから定期的にダウンロードし、Oracle Traffic Director構成にインストールしておく必要があります。

CRLは手動でインストールできます。また、ダウンロード済のCRLを指定したディレクトリから指定の間隔で自動的に取得しインストールするようにOracle Traffic Directorを構成できます。

この項には次のトピックが含まれます:

- 11.6.1項「CRLの手動によるインストールおよび削除」

- 11.6.2項「CRLの自動インストール」

注意:

- この項の情報は、SSL、証明書、暗号および鍵の概念を熟知している読者を対象としています。これらの概念の基本的な情報については、11.2.7項「SSL/TLSの概念」を参照してください。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

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

管理コンソールまたはCLIのいずれかを使用して、CRLを手動でインストールおよび削除できます。

管理コンソールを使用したCRLの手動によるインストール

管理コンソールを使用してダウンロード済のCRLをインストールするには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 証明書をインストールする構成を選択します。

4. ナビゲーション・ペインで、「SSL」を展開し、「認証局を選択します。

5. 「CRLのインストール」ボタンをクリックします。
「証明書失効リストのインストール」ダイアログ・ボックスが表示されます。

6. ダウンロードしたCRLファイルの場所を指定し、「CRLのインストール」をクリックします。

- CRLのインストールが成功したことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- インストールしたCRLは、「認証局」ページに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したCRLの手動によるインストールおよび削除

- ダウンロードしたCRLをインストールするには、次の例に示すように、install-crlコマンドを実行します。

tadm> install-crl --config=soa /home/admin/crls/ServerSign.crl
OTD-70201 Command 'install-crl' ran successfully.

- 構成にインストールされたCRLのリストを表示するには、次の例に示すようにlist-crlsコマンドを実行します。

tadm> list-crls --config=soa --verbose --all
crl-name        next-update
---------------------------
"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を削除するには、次の例に示すように、delete-crlコマンドを実行します。

tadm> delete-crl --config=config1 "VeriSign Class 3 Organizational CA"
OTD-70201 Command 'delete-crl' ran successfully.

CRLを削除すると、CRLはOracle Traffic Director構成、およびダウンロードされたCRLが格納されているディレクトリから削除されます。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

11.6.2 CRLの自動インストール

管理コンソールまたはCLIのいずれかを使用して、ダウンロード済の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は更新を実行しません。

管理コンソールを使用したOracle Traffic DirectorにおけるCRLの自動インストールの構成

管理コンソールを使用して、CRLを自動的にインストールするようにOracle Traffic Directorを構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. CRLを自動的にインストールするように設定する構成の名前をクリックします。

4. ナビゲーション・ペインで、「SSL」を選択します。
「SSL設定」ページが表示されます。

5. ページの「詳細設定」セクションに移動します。

6. 「CRLパスの更新」フィールドに、更新されたCRLファイルを含むディレクトリへの絶対パスを入力します。

7. 「新規イベント」をクリックします。
「新規CRL更新イベント」ダイアログ・ボックスが表示されます。

8. CRLを更新する間隔または時刻を指定し、「OK」をクリックします。

- イベントの作成を確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- 新規イベントが「CRL更新イベント」リストに表示されます。

- 新しいイベントはデフォルトで有効になっています。ステータスを変更するには、「有効化/無効化」チェック・ボックスを選択します。

- イベントを削除するには、「削除」ボタンをクリックします。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したOracle Traffic DirectorにおけるCRLの自動インストールの構成

CRLを自動的にインストールするようにOracle Traffic Directorを構成するには、次の操作を行います。

1. set-pkcs11-propコマンドを使用して、ダウンロードされたCRLが格納されるディレクトリを指定します。
たとえば、次のコマンドでは、/home/admin/crlsが、ダウンロードされたCRLが格納されるディレクトリとして指定されています。

tadm> set-pkcs11-prop --config=soa crl-path=/home/admin/crls
OTD-70201 Command 'set-pkcs11-prop' ran successfully.

2. create-eventコマンドを使用して、Oracle Traffic Directorが、ダウンロードされたCRLを指定されたディレクトリから取得し、自動的にインストールするイベントをスケジュールします。
たとえば、次のコマンドでは、構成soaのCRLは86400秒(1日)ごとに更新されます

tadm> create-event --config=soa --command=update-crl --interval=604800
OTD-70201 Command 'create-event' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

Webアプリケーション・ファイアウォール(WAF)とは、HTTPリクエストにルール・セットと呼ばれる一連のルールを適用するフィルタまたはサーバー・プラグインのことです。Webアプリケーション・ファイアウォールは、攻撃を検知および阻止するためのセキュリティ・レイヤーを強化するための手段として有用です。これはオリジン・サーバー内にホストされているアプリケーションのファイアウォールとして機能します。また、管理者がヘッダーや本文などHTTPリクエストの任意の部分を調査したり、条件を構成しHTTPリクエストがその条件に基づいて許可または拒否されるように設定することもできます。

Webアプリケーション・ファイアウォール・モジュールには無償のバージョンと商用バージョンがあります。Oracle Traffic DirectorのWebアプリケーション・ファイアウォール・モジュールはModSecurity 2.6をサポートしています。これは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を参照してください。

この項には次のトピックが含まれます:

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

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

- 11.7.3項「ルール・セット・ファイルのリスト表示」

- 11.7.4項「ルール・セット・ファイルの削除」

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

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

Oracle Traffic Directorを使用すると、構成内の各仮想サーバーに対してWebアプリケーション・ファイアウォールを有効化(または無効化)できます。これはルール・セットを適用し、オリジン・サーバーにデプロイされているWebアプリケーションのファイアウォールとして機能します。オリジン・サーバーおよび仮想サーバーの詳細は、第7章「オリジン・サーバーの管理」および第8章「仮想サーバーの管理」をそれぞれ参照してください。

Oracle Traffic Directorはルール・セットを仮想サーバー・レベルと構成レベルの両レベルでサポートしています。仮想サーバー・レベルで定義されたルールは、構成レベルで定義されたルールよりも優先されます。デプロイすると、これらのルールと構成変更がインスタンスにプッシュされ、インスタンスが再構成されます。Webアプリケーション・ファイアウォールの動作の詳細は、付録B「Webアプリケーション・ファイアウォールの例とユースケース」を参照してください。

11.7.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.6ディレクティブをサポートしています。ただし、<IfDefine...>や<Location...>などのApacheコア構成ディレクティブや、RequestHeaderやHeaderなど、その他のApacheモジュールでサポートされているディレクティブはサポートしていません。

前述のディレクトリを解凍した後、これらのディレクトリ内のファイルを編集して、管理サーバーにアップロードできます。これらのルール・セット・ファイルをデプロイすると、Oracle Traffic Directorインスタンスにプッシュされます。詳細は、11.7.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

このエラーを回避するには、ルール・セット・ファイルを編集し、サポートされていないディレクティブ、変数、演算子、アクション、フェーズ、関数およびストレージを削除またはコメント・アウトしてからサーバーを起動します。

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

管理コンソールまたはCLIのいずれかを使用して、Webアプリケーション・ファイアウォールのルール・セットを有効化およびインストールできます。

注意:

- Webアプリケーション・ファイアウォール・ルール・セットの有効化とインストールは、実質的には構成の変更を意味します。新しいルール・セットをOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したWebアプリケーション・ファイアウォール・ルール・セットの有効化とインストール

管理コンソールを使用して仮想サーバーにWebアプリケーション・ファイアウォールを構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. Webアプリケーション・ファイアウォールを構成する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を展開し、Webアプリケーション・ファイアウォールを構成する仮想サーバーの名前を展開して、「Webアプリケーション・ファイアウォール」を選択します。
「Webアプリケーション・ファイアウォール」ページが表示されます。

1. 「Webアプリケーション・ファイアウォール」ページで、「有効」をクリックし、特定の仮想サーバーのWebアプリケーション・ファイアウォールを有効化します。

2. 「ルール・セット・ファイルのインストール」をクリックします。
「ルール・セット・ファイルのインストール」ダイアログ・ボックスで、ルール・セット・ファイルを解凍したフォルダを参照しルール・セット・ファイルを選択するか、ルール・セット・ファイルがある場所までの完全パスを入力します。複数のルール・セット・ファイルをインストールする場合は、1度に1つずつインストールします。

1つ以上のルール・セット・ファイルをインストールすると、「ルール・セット・パターン」フィールドに次のテキストが追加されます。

ruleset/<virtual-server-id>/*.conf

注意:

- 構成レベルでルール・セット・ファイルをインストールすると、ルール・セット・パターンが次のように表示されます。

ruleset/*.conf

- 必要であれば、カスタム・ルール・セット・パターンを追加できます。しかし、ruleset/<virtual-server-id>ディレクトリ(仮想サーバー・レベルの場合)またはrulesetディレクトリ(構成レベルの場合)の外部にあるルール・セットは、Oracle Traffic Directorの管理コンソールまたはCLIを使用して表示したり削除したりすることはできません。これらのルール・セットは手動で管理する必要があります。

3. 「ルール・セットのインストール」をクリックします。
ルール・セット・ファイルがインストールされたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したWebアプリケーション・ファイアウォールの有効化

CLIを使用してWebアプリケーション・ファイアウォールを有効化するには、enable-webapp-firewallコマンドを実行します。

たとえば、次のコマンドを実行すると、構成soaにある仮想サーバーvs1でWebアプリケーション・ファイアウォールが有効になります。

tadm> enable-webapp-firewall --config=soa --vs=vs1
OTD-70201 Command 'enable-webapp-firewall' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

CLIを使用したWebアプリケーション・ファイアウォール・ルール・セットのインストール

CLIを使用してWebアプリケーション・ファイアウォール・ルール・セットをインストールするには、install-webapp-firewall-rulesetコマンドを実行します。

たとえば、次のコマンドを実行すると、構成soaにある仮想サーバーvs1にWebアプリケーション・ファイアウォール・ルール・セットmodsecurity_crs_20_protocol_violations.confがインストールされます。

tadm> install-webapp-firewall-ruleset --config=soa --vs=vs1 /home/rulesets/modsecurity_crs_20_protocol_violations.conf
OTD-70201 Command 'install-webapp-firewall-ruleset' ran successfully.

構成レベルでWebアプリケーション・ファイアウォール・ルール・セットをインストールするには、--vsオプションなしで前述のコマンドを実行します。たとえば、次のコマンドを実行すると、構成soaにWebアプリケーション・ファイアウォール・ルール・セットmodsecurity_crs_50_outbound.confがインストールされます。

tadm> install-webapp-firewall-ruleset --config=soa /home/rulesets/modsecurity_crs_50_outbound.conf
OTD-70201 Command 'install-webapp-firewall-ruleset' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

注意:
set-config-propおよびset-virtual-server-propコマンドを使用して、webapp-firewall-rulesetプロパティの値を構成レベルと仮想サーバー・レベルで設定できます。詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照してください。

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

管理コンソールまたはCLIのいずれかを使用して、ルール・セット・ファイルのリストを表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したルール・セット・ファイルのリストの表示

管理コンソールを使用してルール・セット・ファイルのリストを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. ルール・セット・ファイルを表示する構成を選択します。

4. 「Webアプリケーション・ファイアウォール」ページの「ルール・セット・ファイル」表に、インストール済のルール・セット・ファイルがリストされます。これらのファイルの内容を確認するには、クリックして個々のルール・ファイルを選択するか、「名前」チェック・ボックスを選択してすべてのルール・ファイルを選択します。

5. 「表示」をクリックします。
各ルール・ファイルの内容が「ルール・セット・ファイルの内容」ウィンドウに表示されます。

CLIを使用したルール・セット・ファイルのリストの表示

CLIを使用して個々のルール・セット・ファイルの内容を表示することはできませんが、インストール済のルール・セット・ファイルのリストを表示することは可能です。ルール・セット・ファイルのリストを表示するには、list-webapp-firewall-rulesetsコマンドを実行します。

たとえば、次のコマンドを実行すると、構成soaにある仮想サーバーvs1にインストールされているWebアプリケーション・ファイアウォール・ルール・セット・ファイルがリストされます。

tadm> list-webapp-firewall-rulesets --config=soa --vs=vs1 --verbose

ruleset-file-name
--------------------
modsecurity_crs_45_trojans.conf
modsecurity_crs_42_tight_security.conf
modsecurity_crs_46_slr_et_sqli_attacks.conf

構成レベルでインストールされているWebアプリケーション・ファイアウォール・ルール・セットのリストを表示するには、--vsオプションなしで前述のコマンドを実行します。たとえば、次のコマンドを実行すると、構成soaに構成レベルでインストールされているWebアプリケーション・ファイアウォール・ルール・セットがリストされます。

tadm> list-webapp-firewall-rulesets --config=soa --verbose

ruleset-file-name
--------------------
modsecurity_crs_40_generic_attacks.conf
modsecurity_crs_47_common_exceptions.conf

get-webapp-firewall-propコマンドを実行すると、Webアプリケーション・ファイアウォールのプロパティを表示できます。

list-webapp-firewall-rulesetsおよびget-webapp-firewall-propコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

管理コンソールまたはCLIのいずれかを使用して、ルール・セット・ファイルを削除できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したルール・セット・ファイルの削除

特定の仮想サーバーのルール・セット・ファイルを削除するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. ルール・セット・ファイルを削除する構成を選択します。

4. 「Webアプリケーション・ファイアウォール」ページで、個々のルール・ファイルをクリックして選択するか、「名前」チェック・ボックスを選択してすべてのルール・ファイルを選択します。

5. 「削除」ボタンをクリックします。確認プロンプトで、「OK」です。
「コンソール・メッセージ」ペインに、ルール・セット・ファイルが削除されたことを確認するメッセージが表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したルール・セット・ファイルの削除

特定の仮想サーバーのルール・セット・ファイルを削除するには、次の例に示すようにdelete-webapp-firewall-rulesetコマンドを実行します。

tadm> delete-webapp-firewall-ruleset --config=soa --vs=vs1 modsecurity_crs_20_protocol_violations.conf
OTD-70201 Command 'delete-webapp-firewall-ruleset' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

注意:
disable-webapp-firewallコマンドを使用してWebアプリケーション・ファイルを無効にできます。詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照してください。

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

Oracle Traffic Directorでは様々なModSecurity 2.6のディレクティブ、変数、演算子、アクション、関数、永続ストレージおよびフェーズがサポートされています。

サポートされているWebアプリケーション・ファイアウォール・ディレクティブ

Oracle Traffic Directorでは次のModSecurity 2.6ディレクティブがサポートされています。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.6変数がサポートされています。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.6演算子がサポートされています。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.6ではSecHttpBlKeyディレクティブがサポートされません。そのため、RBLとしてProject Honey Pot (dnsbl.httpbl.cong)を使用することはできません(SecHttpBlKeyが必要になるため)。

サポートされているWebアプリケーション・ファイアウォール・アクション

Oracle Traffic Directorでは次のModSecurity 2.6アクションがサポートされています。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.6変換関数がサポートされています。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
md5
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.6永続ストレージがサポートされています。ModSecurity永続ストレージの詳細およびすべての永続ストレージのリストは、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Persistant_Storageを参照してください。

GLOBAL
IP
RESOURCE
SESSION
USER

サポートされているWebアプリケーション・ファイアウォール・フェーズ

Oracle Traffic Directorでは次のModSecurity 2.6フェーズがサポートされています。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>)

11.8 クライアント認証の構成

クライアント認証とは、クライアントによって提供される証明書に基づいて行われる、Oracle Traffic Director仮想サーバーまたはTCPプロキシによるクライアントの検証です。

クライアント認証は、デフォルトでは有効化されません。管理コンソールまたはCLIを使用して、クライアントに証明書の提供を要求するようにOracle Traffic Directorリスナーを構成できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したクライアント認証の構成

管理コンソールを使用してリスナーのクライアント認証を有効化するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. リスナーのクライアント認証を有効にする構成を指定します。

4. ナビゲーション・ペインで、「リスナー」を展開し、クライアント認証を構成するリスナーを選択します。
「リスナー設定」ページが表示されます。

5. ページの「詳細設定」セクションに移動し、SSL/TLSサブセクションにスクロール・ダウンします。

6. 必要な「クライアント認証」モードを選択します。

- 必須: サーバーがクライアントに証明書を要求し、クライアントが証明書を提供しない場合、接続はクローズされます。

- オプション: サーバーはクライアントに証明書を要求しますが、必須ではありません。クライアントが証明書を提供しなくても、接続は確立されます。

- False (デフォルト): クライアント認証は無効化されます。

7. 「認証タイムアウト」および「最大認証データ」パラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

8. 必要な変更を行った後、「保存」をクリックします。

- 更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したクライアント認証の構成

HTTPまたはTCPリスナーのクライアント認証を有効化するには、set-ssl-propコマンドを実行します。

たとえば、次のコマンドでは、リスナーhttp-listener-1のクライアント認証が必須とされ、認証タイムアウト時間は60秒、バッファ可能な認証データの最大長は262144バイトと設定されます。

tadm> set-ssl-prop --config=soa --http-listener=http-listener-1
client-auth=required max-client-auth-data=262144 client-auth-timeout=60
OTD-70201 Command 'set-ssl-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

11.9 サービス拒否攻撃の回避

サービス拒否(DoS)攻撃とは、悪意のあるユーザーがリクエストをサーバーに連続して送信することで、正当なユーザーによるサービスへのアクセスを妨害することを指します。

DoS攻撃を回避するために、リクエストの頻度または同時接続数が指定された制限を超えた場合、リクエストを拒否するようにOracle Traffic Director仮想サーバーを構成できます。より細かくリクエストを制御するには、リクエスト制限を定義し、各制限を、指定したURLパターンや問合せ文字列パターンに一致するリクエスト、および指定した値に一致するリクエスト・ヘッダーなどに適用できます。

この項には次の項目が含まれています。

- 11.9.1項「リクエスト制限のパラメータ」

- 11.9.2項「仮想サーバーのリクエスト制限の構成」

11.9.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では、指定された続行条件が満たされるまで、後続のリクエストはすべて拒否され続けます。次の続行条件のいずれかを指定できます。

- しきい値(デフォルト): 指定された制限をリクエスト・レートが下回ったら、サービスは再開されます。

- サイレンス: 受信するリクエスト数が間隔全体でゼロになると、サービスが再開されます。

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

管理コンソールまたはCLIのいずれかを使用して、仮想サーバーのリクエスト制限を構成できます。

注意:

- 仮想サーバーを変更すると、実質的には構成が変更されます。新しい仮想サーバーの設定をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したリクエスト制限の構成

管理コンソールを使用してリクエスト制限を構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. リクエスト制限を構成する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を展開し、リクエスト制限を構成する仮想サーバーの名前を展開して、「リクエスト制限」を選択します。
「リクエスト制限」ページが表示されます。仮想サーバーに現在定義されているリクエスト制限がリストされます。

リクエスト制限の作成

1. 「新規リクエスト制限」をクリックします。
「新規リクエスト制限」ダイアログ・ボックスが表示されます。

「名前」フィールドで、新しいリクエスト制限の名前を入力します。

「接続」フィールドに、仮想サーバーへの最大同時接続数を指定します。

「リクエスト数/秒」フィールドに、仮想サーバーが1秒当たりで受入れ可能な最大リクエスト数を指定します。

注意:
少なくともいずれかの制限(最大接続数または1秒当たりの最大リクエスト数)を指定する必要があります。

「監視属性」フィールドに、仮想サーバーがリクエスト制限を適用するために監視する必要があるリクエスト・ヘッダーの属性を指定します。このパラメータを指定しない場合、リクエスト制限はすべてのリクエストに適用されます。

2. 次へをクリックします。
このリクエスト制限が仮想サーバーに対する最初のリクエスト制限の場合、「新規キャッシュ・ルール」ダイアログ・ボックスに、制限をすべてのリクエストに適用するかどうかを選択するオプションが表示されます。「すべてのリクエスト」を選択します。

条件を満たすリクエストにのみ、制限を適用する場合は、「条件を新規に作成します」を選択して新しい条件を作成します。「新規式」ペインで「変数/関数」を選択し、各ドロップダウン・リストから演算子を選択し、「値」フィールドに値を入力します。

複数の式を構成する場合は、ドロップダウン・リストでand/or演算子を選択します。同様に、指定した式が偽に評価されるときにルートを適用する場合は、Not演算子を使用します。

条件を手動入力するには、「取消」をクリックし、「手動編集」をクリックします。「条件」フィールドで、リクエスト制限が適用される条件を指定します。条件式の作成の詳細は、「条件」フィールドの近くにあるヘルプ・ボタンをクリックするか、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

3. 次へをクリックし、「リクエスト制限の作成」をクリックします。
作成したリクエスト制限が「リクエスト制限」ページに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

リクエスト制限の編集

リクエスト制限の設定を変更するには、次の操作を行います。

1. リクエスト制限の「名前」をクリックします。
「編集中のリクエスト制限」ページが表示されます。

注意:
条件ビルダーにアクセスして条件を編集するには、「条件を満たすリクエスト」を選択し、「編集」をクリックします。条件ビルダーでは古い式を削除したり、新しい式を作成したりできます。

2. 変更するパラメータを指定します。
リクエスト制限を編集する際、リクエスト制限の作成時に指定したパラメータの変更に加えて、requests-per-second計算間隔、および指定した制限に到達したときに拒否されるリクエストについて仮想サーバーが返すHTTPステータス・コードを設定および変更できます。「編集」をクリックすると設定済の条件を編集できるため、条件を手動でまたは条件ビルダーを使用して編集できます。古い式を削除したり、新しい式を作成できます。

画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

3. 必要な変更を行った後、「保存」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

リクエスト制限の削除

リクエスト制限を削除するには、「削除」ボタンをクリックします。確認プロンプトで、「OK」です。

CLIを使用したリクエスト制限の構成

- リクエスト制限を作成するには、create-request-limitコマンドを実行します。
例:

- 次のコマンドでは、1つのクライアントからの同時リクエスト数を5に制限する、limit_ipという名前のリクエスト制限が、構成soaの仮想サーバーsoa.example.comに作成されます。

tadm> create-request-limit --config=soa --vs=soa.example.com --max-connections=5 limit_ip
OTD-70201 Command 'create-request-limit' ran successfully.

- 次のコマンドでは、サブネット111.23.30.*のクライアントIPアドレスからの1秒当たりのリクエスト数を20に制限する、limit_subnetという名前のリクエスト制限が、構成soaの仮想サーバーsoa.example.comに作成されます。

tadm> create-request-limit --config=soa --vs=soa.example.com --condition="$ip='111.12.30.*'" --max-rps=20 limit_subnet
OTD-70201 Command 'create-request-limit' ran successfully.

--conditionオプションの値は、正規表現にする必要があることに注意してください。条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

- 仮想サーバーに定義されたリクエスト制限のリストを表示するには、次の例に示すようにlist-request-limitsコマンドを実行します。

tadm> list-request-limits --config=soa --vs=soa.example.com
request-limit   condition
-------------------------
limit_ip       -
limit_subnet   "$ = '111.23.30.*'"

- リクエスト制限のプロパティを表示するには、次の例に従い、get-request-limit-propコマンドを実行します。

tadm> get-request-limit-prop --config=soa --vs=soa.example.com --request-limit=limit_ip
continue-condition=silence
condition="$ip = '111.23.30.*'"
error-code=503
max-connections=50
rps-compute-interval=30
max-rps=20
request-limit=limit_ip

- リクエスト制限のプロパティを変更するには、set-request-limit-propコマンドを実行します。
たとえば、次のコマンドでは、構成soaの仮想サーバーsoa.example.com内のリクエスト制限limit_ipにおける1秒当たりのリクエスト数の計算間隔が60秒に変更されます。

tadm> set-request-limit-prop --config=soa --vs=soa.example.com --rule=loan-rule rps-compute-interval=60

- リクエスト制限を削除するには、次の例に示すように、delete-request-limitコマンドを実行します。

tadm> delete-request-limit --config=soa --vs=soa.example.com limit_ip
OTD-70201 Command 'delete-request-limit' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

12 ログの管理

Oracle Traffic Directorのログ・ファイルには、構成の変更、インスタンスの起動および停止、リクエスト処理中のエラーなどのサーバー・イベントに関するデータが記録されます。ログを使用すると、サーバーの問題の診断、サーバーの使用パターンの評価、およびシステムのパフォーマンス向上のためのチューニングを行えます。

この章には次の項が含まれます:

- Oracle Traffic Directorログについて

- ログの表示

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

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

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

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

12.1 Oracle Traffic Directorのログについて

管理サーバーを含む各Oracle Traffic Directorインスタンスには、アクセス・ログとサーバー・ログの2つのログがあります。インスタンス・ログはデフォルトで有効化されており、最初にインスタンスが起動されるときに初期化されます。インスタンス・ログに加えて、インスタンス内の各仮想サーバーのアクセス・ログおよびサーバー・ログを有効化できます。

- Oracle Traffic Directorインスタンスのアクセス・ログおよびサーバー・ログのデフォルトの場所は、INSTANCE_HOME/net-config_name/logsディレクトリです。

- 管理サーバーの場合、ログ・ファイルのデフォルトの場所は、INSTANCE_HOME/admin-server/logsディレクトリです。

この項では、アクセス・ログおよびサーバー・ログの概要を説明します。ログ・ファイルの名前および場所などのログ設定の変更の詳細は、12.3項「ログ・プリファレンスの構成」を参照してください。

12.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行目は、実際のエントリです。

アクセス・ログの形式、ファイル名および場所を変更できます。アクセス・ログを無効化することもできます。詳細は、12.3項「ログ・プリファレンスの構成」を参照してください。

12.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であり、主要なライフサイクル・イベント、警告およびエラーのみが記録されます。

ログ・レベル、ログ・ファイル名およびログ・ファイルの場所を変更できます。詳細は、12.3項「ログ・プリファレンスの構成」を参照してください。

表12-1は、サーバー・ログに指定できるログ・レベルを示しています。

表12-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ログ・レベルを有効化すると、大量のメッセージが記録されるため、パフォーマンスに影響を及ぼす可能性があります。したがって、問題をデバッグするためにより詳細な情報が必要な場合を除き、本番システムで冗長なログ・レベルを有効化しないようにしてください。

12.2 ログの表示

管理コンソールまたはCLIのいずれかを使用して、Oracle Traffic Directorインスタンスおよび仮想サーバーのアクセス・ログおよびサーバー・ログを表示できます。

注意:

- CLIおよび管理コンソールに加え、lsおよびmoreなどの標準のオペレーティング・システム・コマンドを使用して、ログ・ファイルをリストしたり表示したりできます。

- 管理コンソールの「ログ・ビューア」およびget-access-log CLIコマンドでは、ディスク上のアクセス・ログ・ファイルに現在存在するログ・エントリのみが表示されます。これらでは、アクセス・ログ・バッファにある項目は表示されません(15.7項「アクセス・ログ・バッファ設定の構成」を参照)。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したログの表示

管理コンソールを使用して、ノード、インスタンスまたはインスタンス内の仮想サーバーのログ・データを表示するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. ログを表示する構成を選択します。

4. 「共通のタスク」ペインで、「ログの表示」をクリックします。
Oracle Traffic Directorのログ・ビューア・ウィンドウが表示されます。

5. 「ノード、インスタンスまたは仮想サーバーの選択」ボタンをクリックし、データを表示するノード、インスタンスまたは仮想サーバーを選択します。

- サーバー・ログを表示するには、「サーバー・ログ」タブを選択します。

- アクセス・ログを表示するには、「アクセス・ログ」タブを選択します。

特定のレコードを検索するには、ウィンドウの右上隅付近にある「検索オプション」ボタンをクリックし、適切なフィルタを指定します。

「検索オプション」ボタン付近にあるリフレッシュ・ボタンをクリックすると、表示内容をリフレッシュできます。リフレッシュ・ボタンをクリックして、「ログ・ビューア」をリフレッシュすると、検索オプションおよびソート順序がデフォルト設定にリセットされることに注意してください。

ログ・ビューアを15秒ごとに自動的にリフレッシュするには、「自動リフレッシュ」チェック・ボックスを選択します。

CLIを使用したログの表示

- インスタンスまたは仮想サーバーのアクセス・ログを表示するには、get-access-logコマンドを実行します。
たとえば、次のコマンドでは、ノードexample.comで実行中の構成soaのインスタンスに対するアクセス・ログ・レコードのうち、ステータスが304のレコードが表示されます。

tadm> get-access-log --status-code=304 --config=soa example.com
format=%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] "%Req->reqpb.clf-request%" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length%
10.177.243.207 - - [25/Aug/2011:04:41:34 -0700] "GET / HTTP/1.1" 304 0
10.177.243.207 - - [25/Aug/2011:04:41:35 -0700] "GET / HTTP/1.1" 304 0

1行目は、アクセス・ログに現在定義されている形式を示しています。

インスタンス内の特定の仮想サーバーに対するアクセス・ログを表示するには、--vsオプションを使用して、仮想サーバー名を指定します。

- インスタンスまたは仮想サーバーのサーバー・ログを表示するには、get-logコマンドを実行します。
たとえば、次のコマンドでは、ノードexample.comで実行中の構成soaのインスタンスに対するサーバー・ログ・レコードのうち、ログ・レベルがwarning:1以上のレコードが表示されます。

tadm> get-log --log-level=warning:1 --config=soa example.com

インスタンス内の特定の仮想サーバーに対するサーバー・ログを表示するには、--vsオプションを使用して、仮想サーバー名を指定します。

get-access-logおよびget-logの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

構成を作成すると、サーバー・ログおよびアクセス・ログが、特定のデフォルト設定で有効化されます。サーバー・ログのレベル、ファイル名および場所を変更できます。アクセス・ログの形式、ファイル名および場所を変更できます。アクセス・ログを無効化することもできます。サーバー・ログの場所を変更する場合、インスタンスを再起動して変更を有効にする必要があります。

構成内に定義されたログ・プリファレンスは、構成内のすべての仮想サーバーに適用されます。仮想サーバー・レベルで、アクセス・ログの場所や形式、およびサーバー・ログの場所を定義できます。

管理コンソールまたはCLIのいずれかを使用して、Oracle Traffic Directorインスタンスのログ・プリファレンスを構成できます。

注意:

- 管理サーバーのログ・プリファレンスを変更するには、2.6項「管理サーバー設定の変更」の説明に従い、管理サーバーのプロパティを変更する必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したログ・プリファレンスの構成

管理コンソールを使用して構成または仮想サーバーのログ・プリファレンスを構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. ログ・プリファレンスを構成する構成を選択します。

- 構成全体のログ・プリファレンスを変更するには、ナビゲーション・ペインで「ロギング」を選択します。

- 構成内の特定の仮想サーバーのログ・プリファレンスを設定または変更するには、ナビゲーション・ペインの「仮想サーバー」を展開し、ログ・プリファレンスを定義する仮想サーバーを選択して、「ロギング」を選択します。

「ログ・プリファレンス」ページが表示されます。

4. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

カスタムのアクセス・ログ形式の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』のカスタムのアクセス・ログ形式の使用方法に関する項を参照してください。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

5. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したログ・プリファレンスの構成

- 構成または仮想サーバーの現在のアクセス・ログ・プリファレンスを表示するには、get-access-log-propコマンドを実行します。
たとえば、次のコマンドでは、構成soaのアクセス・ログ・プリファレンスが表示されます。

tadm> get-access-log-prop --config=soa
enabled=true
file=../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%
mode=text

構成内の特定の仮想サーバーのアクセス・ログ・プリファレンスを表示するには、--vsオプションを使用してget-access-log-propを実行します。

- 構成または仮想サーバーのアクセス・ログ・プリファレンスを設定または変更するには、enable-access-logコマンドを実行します。
たとえば、次のコマンドでは、構成soaのアクセス・ログの場所がINSTANCE_HOME/net-config_name/logs/accessに変更されます。

tadm> enable-access-log --config=soa --file=../logs/access
OTD-70201 Command 'enable-access-log' ran successfully.

注意:
ログ・ファイル・ディレクトリの相対パスを指定した場合、パスは、インスタンスのconfigディレクトリへの相対パスと見なされます。

構成内の特定の仮想サーバーのアクセス・ログの場所と形式を設定または変更するには、--vsオプションを使用してenable-access-logを実行します。

カスタムのアクセス・ログ形式の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』のカスタムのアクセス・ログ形式の使用方法に関する項を参照してください。

- 構成または仮想サーバーのアクセス・ログを無効化するには、次の例に示すように、disable-access-logコマンドを実行します。

tadm> disable-access-log --config=soa
OTD-70201 Command 'disable-access-log' ran successfully.

構成内の特定の仮想サーバーのアクセス・ログを無効化するには、--vsオプションを使用してdisable-access-logを実行します。

- 構成の現在のサーバー・ログ・プリファレンスを表示するには、get-log-propコマンドを実行します。
たとえば、次のコマンドでは、構成soaのサーバー・ログ・プリファレンスが表示されます。

tadm> get-log-prop --config=soat
create-console=false
log-file=../logs/server.log
log-to-syslog=false
log-virtual-server-name=false
log-stdout=true
log-level=NOTIFICATION:1
log-to-console=true
log-stderr=true

- 構成内の特定の仮想サーバーのサーバー・ログの場所を表示するには、次の例に示すようにget-virtual-server-propコマンドを実行します。

tadm> get-virtual-server-prop --config=soa --vs=vs1 log-file

- 構成のサーバー・ログ・プリファレンスを設定または変更するには、set-log-propコマンドを実行します。サーバー・ログの場所を変更する場合、インスタンスを再起動して変更を有効にする必要があることに注意してください。
たとえば、次のコマンドでは、構成soaのサーバー・ログ・レベルがWARNING:1に変更されます。

tadm> set-log-prop --config=soa log-level=WARNING:1
OTD-70201 Command 'set-log-prop' ran successfully.

- 仮想サーバーのサーバー・ログ・プリファレンスを設定または変更するには、set-virtual-server-propコマンドを実行します。
たとえば、次のコマンドでは、構成soa内の仮想サーバーvs1のサーバー・ログの場所がINSTANCE_HOME/net-config_name/log/serverに変更されます。

tadm> set-virtual-server-prop --config=soa --vs=vs1 log-file=../log/server
OTD-70201 Command 'set-virtual-server-prop' ran successfully.

注意:
ログ・ファイル・ディレクトリの相対パスを指定した場合、パスは、インスタンスのconfigディレクトリへの相対パスと見なされます。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。サーバー・ログの場所を変更する場合、インスタンスを再起動して変更を有効にする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

指定した間隔でログを自動的にローテーション(アーカイブ)するようにOracle Traffic Directorを構成できます。また、必要な場合はいつでも、ログを手動でローテーションすることもできます。

ログをローテーションすると、古いログ・ファイルは、ローテーション日付(yyyymmdd形式)および24時間(hhmm)を示す接尾辞で名前が変更されます。たとえば、2011年8月25日午後11時にアーカイブされたサーバー・ログのファイル名は、server-201108252300.logとなります。

ログのローテーション後、サーバー・ログおよびアクセス・ログは再初期化されます。

ログのローテーション方法の詳細は、12.5項「手動によるログ・ローテーション」および12.6項「Oracle Traffic Directorの自動ログ・ローテーションの構成」を参照してください。

注意:
アクセス・ログのローテーション・イベントにより、TCPアクセス・ログもローテーションされます。

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

管理コンソールまたはCLIのいずれかを使用して、Oracle Traffic Directorインスタンスのサーバー・ログおよびアクセス・ログをローテーションできます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したログの手動によるローテーション

管理コンソールを使用してログをローテーションするには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. ログをローテーションする構成を選択します。
選択した構成のすべてのインスタンスのログをローテーションするには、次の操作を行います。

1. ナビゲーション・ペインで、「ロギング」を選択します。
「ログ・プリファレンス」ページが表示されます。

2. ページの「ログ・ローテーション」セクションに移動します。

3. Oracle Traffic Directorで、ローテーションされたログ・ファイルに対し特定のコマンドを実行するには、「アーカイブ・コマンド」フィールドで、必要なコマンドへの絶対パスを指定します。
たとえば、アーカイブ・コマンドとして/usr/bin/gzipを指定した場合、ログのローテーション後、Oracle Traffic Directorでは、次のコマンドを実行してローテーションされたログ・ファイルを圧縮します。

$ /usr/bin/gzip access-yyyymmddhhmm.log
$ /usr/bin/gzip server-yyyymmddhhmm.log

4. 「ログを今すぐローテーション」をクリックします。
構成のすべてのインスタンスに対して、仮想サーバー固有のログを含むサーバー・ログおよびアクセス・ログがアーカイブされます。

選択した構成の特定のインスタンスのログをローテーションするには、次の操作を行います。

1. ナビゲーション・ペインで、「インスタンス」を選択します。
「インスタンス」ページが表示されます。

2. 必要なインスタンスの「ログのローテーション」ボタンをクリックします。
選択したインスタンスに対して、仮想サーバー固有のログを含むサーバー・ログおよびアクセス・ログがアーカイブされます。

「コンソール・メッセージ」ペイン、にログがローテーションされたことを確認するメッセージが表示されます。

CLIを使用したログの手動によるローテーション

構成の1つ以上のインスタンスのログをローテーションするには、rotate-logコマンドを実行します。

たとえば、次のコマンドでは、ノードsoa1.example.comおよびsoa2.example.comで実行中の構成soaのインスタンスに対して、仮想サーバー固有のログを含む、アクセス・ログおよびサーバー・ログがローテーションされます。

tadm> rotate-log --config=soa soa1.example.com soa2.example.com
OTD-70201 Command 'rotate-log' ran successfully.

ノードを指定しない場合、構成のすべてのインスタンスに対してログがローテーションされます。

注意:
Oracle Traffic Directorで、ローテーションされたログ・ファイルに対し特定のコマンドを実行するには、次の例に示すように、set-log-propコマンドを実行して、必要なコマンドへの絶対パスを指定します。

tadm> set-log-prop --config=soa archive-command=/usr/bin/gzip
OTD-70201 Command 'set-log-prop' ran successfully.

この例では、ログのローテーション後、次のコマンドにより、ローテーションされたログ・ファイルがOracle Traffic Directorで圧縮されます。

$ /usr/bin/gzip access-yyyymmddhhmm.log
$ /usr/bin/gzip server-yyyymmddhhmm.log

rotate-logおよびset-log-propの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

ログ・ローテーション・イベントを作成し、指定した時間または間隔で、ログを自動的にローテーションするようにOracle Traffic Directorを構成できます。

管理コンソールまたはCLIのいずれかを使用して、ログ・ローテーション・イベントを作成できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したログ・ローテーション・イベントの作成

管理コンソールを使用してログ・ローテーション・イベントを作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. ログ・ローテーション・イベントを作成する構成を選択します。

4. ナビゲーション・ペインで、「ロギング」を選択します。
「ログ・プリファレンス」ページが表示されます。

5. ページの「ログ・ローテーション」セクションに移動します。

6. Oracle Traffic Directorで、ローテーションされたログ・ファイルに対し特定のコマンドを実行するには、「アーカイブ・コマンド」フィールドで、必要なコマンドへの絶対パスを指定します。
たとえば、アーカイブ・コマンドとして/usr/bin/gzipを指定した場合、ログのローテーション後、Oracle Traffic Directorでは、次のコマンドを実行してローテーションされたログ・ファイルを圧縮します。

$ /usr/bin/gzip access-yyyymmddhhmm.log
$ /usr/bin/gzip server-yyyymmddhhmm.log

7. 「新規イベント」をクリックします。
「新規ログ・ローテーション・イベント」ダイアログ・ボックスが表示されます。

8. このイベントがサーバー・ログ用かまたはアクセス・ログ用かを指定します。

9. ログを更新する間隔または時刻を指定し、「OK」をクリックします。

- イベントの作成を確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- 新規イベントが「ログ・ローテーション・イベント」リストに表示されます。

- 新しいイベントはデフォルトで有効になっています。ステータスを変更するには、「有効化/無効化」チェック・ボックスを選択します。

- イベントを削除するには、「削除」ボタンをクリックします。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したログ・ローテーション・イベントの作成

ログ・ローテーション・イベントを作成するには、create-eventコマンドを実行します。

たとえば、次のコマンドでは、構成soaのすべてのインスタンスに対してアクセス・ログおよびサーバー・ログを、それぞれ3600秒および7200秒ごとにローテーションするようにOracle Traffic Directorが構成されます。

tadm> create-event --config=soa --command=rotate-access-log --interval=3600
OTD-70201 Command 'create-event' ran successfully.

tadm> create-event --config=soa --command=rotate-log --interval=7200
OTD-70201 Command 'create-event' ran successfully.

注意:
Oracle Traffic Directorで、ローテーションされたログ・ファイルに対し特定のコマンドを実行するには、次の例に示すように、set-log-propコマンドを実行して、必要なコマンドへの絶対パスを指定します。

tadm> set-log-prop --config=soa archive-command=/usr/bin/gzip
OTD-70201 Command 'set-log-prop' ran successfully.

この例では、ログのローテーション後、次のコマンドにより、ローテーションされたログ・ファイルがOracle Traffic Directorで圧縮されます。

$ /usr/bin/gzip access-yyyymmddhhmm.log
$ /usr/bin/gzip server-yyyymmddhhmm.log

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

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

13 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アクセスの構成

- CLIを使用した統計の表示

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

- SNMPを使用した監視

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

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

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

表13-1は、構成のインスタンス、およびインスタンス内の個々の仮想サーバーについての統計データの表示に使用できる方法を示しています。

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

監視方法

要件

利点

CLI

- 構成の1つまたはすべてのインスタンス: get-config-stats

- 特定のインスタンス:
プレーンテキスト形式でのサマリー: get-perfdump

XML形式での詳細レポート: get-stats-xml

- 構成の1つまたはすべてのインスタンス内の特定の仮想サーバー: get-virtual-server-stats

- 特定のオリジン・サーバー・プール: get-origin-server-stats

13.4項「CLIを使用した統計の表示」を参照してください。

管理サーバーが実行されている必要があります。

デフォルトで有効化されます。

リクエスト処理スレッドがハング中でもアクセス可能です。

ブラウザ

- 特定の仮想サーバーのXML形式での詳細統計

- 特定の仮想サーバーのプレーンテキスト形式でのサマリー統計

13.5項「ブラウザを使用したstats-xmlおよびperfdumpレポートの表示」を参照してください。

明示的に有効化し構成する必要があります。

13.3項「統計レポートへのURIアクセスの構成」を参照してください。

管理サーバーは実行中である必要はありません。インスタンスが実行中であれば十分です。

SNMP

明示的に構成する必要があります。

13.6項「SNMPを使用した監視」を参照してください。

ネットワーク管理システムを介して統計を使用できます。

13.2 統計収集設定の構成

Oracle Traffic Director構成の作成時、統計収集はデフォルで有効化され、更新の間隔は5秒に設定されます。管理コンソールまたはCLIのいずれかを使用して、統計収集を無効化、有効化および構成できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用した統計収集設定の構成

管理コンソールを使用して統計収集設定を構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 統計収集設定を構成する構成を選択します。

4. ナビゲーション・ペインで、「詳細設定」を展開し、「監視」を選択します。
「監視設定」ページが表示されます。

5. ページの「統計収集」セクションに移動します。

6. 変更するパラメータを指定します。

注意:
統計収集の間隔を決定する際は、統計の収集頻度を高くするとパフォーマンスに影響を及ぼすことを考慮に入れてください。

画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用した統計収集設定の構成

- 現在の統計収集プロパティを表示するには、次の例に示すようにget-stats-propコマンドを実行します。

tadm> get-stats-prop --config=soa
enabled=true
interval=15
profiling=true

- 統計収集プロパティを構成するには、set-stats-propコマンドを実行します。
たとえば、次のコマンドでは、構成soaで統計が更新される間隔が10秒に変更されます。

tadm> set-stats-prop --config=soa interval=10OTD-70201 Command 'set-stats-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

get-stats-propおよびset-stats-propの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

13.1項「Oracle Traffic Directorインスタンスの監視方法」の説明にあるとおり、CLIを使用したアクティビティ統計の表示に加えて、URIを介して次のレポートを表示できます。

- stats-xml: XML形式での詳細統計。サンプルについては、13.7項を参照してください。

- perfdump: stats-xmlレポートのデータのサブセットを含むプレーンテキスト形式のサマリー・レポート。サンプルについては、13.8項を参照してください。仮想サーバー・レベルでperf-dumpレポートを有効化することで、このレポートのデータがインスタンス・レベルで集計されます。

注意:
統計レポートに対するURIアクセスを使用可能にする場合、/.perfdumpにアクセスすることで、このURLがエンド・ユーザーに表示されることに注意してください。管理者は外部ハードウェア・ロード・バランサを通じてこのアクセスをブロックする必要があります。

統計レポートへのURIベースのアクセスとCLIによるアクセスの相対的な利点

- URIを介してstats-xmlおよびperfdumpレポートにユーザーがアクセスする場合、管理サーバーが実行中である必要がありません。CLIを使用して統計にアクセスする場合と比較して、URIベースのレポートへのアクセスは、処理のオーバーヘッドを低く抑えられます。

- CLIを使用した統計へのアクセスはデフォルトで有効化されますが、ブラウザを介して統計を表示するには、URIベースのレポートを明示的に有効化し、ユーザーがレポートにアクセスできるURIを指定します。

管理コンソールまたはCLIのいずれかを使用して、URIベースの統計レポートを構成できます。

管理コンソールを使用した統計へのURIアクセスの構成

管理コンソールを使用してURIベースのレポートを構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. URIベースのレポートを構成する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を展開し、URIベースのレポートを構成する仮想サーバーを選択します。
「仮想サーバー設定」ページが表示されます。

5. ページの「監視」セクションに移動します。

- XML形式でのURIベースのレポートを有効化するには、「XMLレポート」チェック・ボックスを選択し、レポートの有効なURIを指定します。

- プレーンテキスト形式でのURIベースのレポートを有効化するには、「プレーン・テキスト・レポート」チェック・ボックスを選択し、レポートの有効なURIを指定します。

画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

6. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したXML形式の統計へのURIアクセスの構成

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

- 現在のXMLレポート設定を表示するには、次の例に示すようにget-stats-xml-propコマンドを実行します。

tadm> get-stats-xml-prop --config=soa --vs=vs1
enabled=false
uri=/stats-xml(|/*)

- URIベースのXMLレポートを有効化し構成するには、enable-stats-xmlコマンドを実行します。
たとえば、次のコマンドでは、構成soaの仮想サーバーvs1に対して、XML形式でのURIベースの統計レポートが有効化され、レポートがURI/statsで使用可能になります。

tadm> enable-stats-xml --config=soa --vs=vs1 --uri=/stats
OTD-70201 Command 'enable-stats-xml' ran successfully.

- URIベースのXMLレポートを無効化するには、次の例に示すようにdisable-stats-xmlコマンドを実行します。

tadm> disable-stats-xml --config=soa --vs=vs1
OTD-70201 Command 'disable-stats-xml' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

CLIを使用したプレーンテキスト形式の統計へのURIアクセスの構成

- プレーンテキスト・レポート設定を表示するには、次の例に示すようにget-perfdump-propコマンドを実行します。

tadm> get-perfdump-prop --config=soa --vs=vs1
enabled=true
uri=/.perf

- プレーンテキスト・レポートを有効化し構成するには、enable-perfdumpコマンドを実行します。
たとえば、次のコマンドでは、構成soaの仮想サーバーvs1に対して、プレーンテキスト形式でのURIベースの統計レポートが有効化され、レポートがURI/perfで使用可能になります。

tadm> enable-perfdump --config=soa --vs=vs1 --uri=/perf
OTD-70201 Command 'enable-perfdump' ran successfully.

- URIベースのプレーンテキスト・レポートを無効化するには、次の例に示すようにdisable-perfdumpコマンドを実行します。

tadm> disable-perfdump --config=soa --vs=vs1
OTD-70201 Command 'disable-perfdump' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

13.4 CLIを使用した統計の表示

CLIを使用することで、特定の仮想サーバー、特定のオリジン・サーバー・プールおよび特定のTCPプロキシに対する、構成の1つまたはすべてのインスタンスの統計を表示できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

- 構成の1つまたはすべてのインスタンスの統計を表示するには、次の例に示すようにget-config-statsコマンドを実行します。

tadm> get-config-stats --config=soa
countRequests=20
rpsLast1MinAvg=0.06666667
rpsLast5MinAvg=0.013377926
rpsLast15MinAvg=0.0022099447
countErrors=2
epsLast1MinAvg=0.0
epsLast5MinAvg=0.0
epsLast15MinAvg=0.0
maxResponseTime=23.001
rtLast1MinAvg=1.0
rtLast5MinAvg=1.0
rtLast15MinAvg=1.0

構成の特定のインスタンスの統計を表示するには、--nodeオプションを使用してget-config-statsコマンドを実行します。

- 構成の1つまたはすべてのインスタンスの集計された仮想サーバー統計を表示するには、次の例に示すようにget-virtual-server-statsコマンドを実行します。

tadm> get-virtual-server-stats --config=soa --vs=vs1
count200=9
count2xx=9
count302=0
count304=6
count3xx=6
count400=0
count401=0
count403=0
count404=4
count4xx=4
count503=0
count5xx=2
countBytesReceived=42215
countBytesTransmitted=69298
countErrors=2
countOpenConnections=0
countOther=0
countRequests=21
rateBytesTransmitted=0
vsName=vs1
webapp-firewall.countRequestsAllowed=5
webapp-firewall.countRequestsDenied=2
webapp-firewall.countRequestsDenyDetected=0
webapp-firewall.countRequestsDropDetected=0
webapp-firewall.countRequestsDropped=1
webapp-firewall.countRequestsIntercepted=10
webapp-firewall.countRequestsRedirectDetected=0
webapp-firewall.countRequestsRedirected=2
websocket.countActiveConnections=1
websocket.countBytesReceived=500
websocket.countBytesTransmitted=200
websocket.countRequestsAborted=0
websocket.countRequestsTimedout=0
websocket.countUpgradeRequests=1
websocket.countUpgradeRequestsFailed=0
websocket.countUpgradeRequestsRejected=1
websocket.millisecondsConnectionActiveAverage=1000

構成の特定のインスタンスの仮想サーバー統計を表示するには、--nodeオプションを使用してget-virtual-server-statsコマンドを実行します。

- 特定のオリジン・サーバー・プールの統計を表示するには、次の例に示すようにget-origin-server-statsコマンドを実行します。

tadm> get-origin-server-stats --config=soa --node=soa.example.com --origin-server-pool=wls1
origin-server.1.backup=0
origin-server.1.countActiveConnections=0
origin-server.1.countBytesReceived=11776
origin-server.1.countBytesTransmitted=15024
origin-server.1.countConnectAttempts=41
origin-server.1.countConnectFailures=0
origin-server.1.countIdleConnections=1
origin-server.1.countMarkedOffline=0
origin-server.1.countRequests=44
origin-server.1.countRequestsAborted=0
origin-server.1.countRequestsTimedout=0
origin-server.1.discovered=0
origin-server.1.name=soa-app.example.com:1900
origin-server.1.online=1
origin-server.1.rampedUp=1
origin-server.1.secondsOnline=20
origin-server.1.type=http
origin-server.1.websocket.countRequests=2
origin-server.1.websocket.countUpgradeRejectedRequests=1
origin-server.1.websocket.countFailedStrictRequests=1
origin-server.1.websocket.countUpgradedRequests=1
origin-server.1.websocket.countAbortedRequests=0
origin-server.1.websocket.countTimeoutRequests=0
origin-server.1.websocket.countBytesReceived=500
origin-server.1.websocket.countBytesTransmitted=200
origin-server.1.websocket.countActiveConnections=1
origin-server.1.websocket.millisecondsConnectionActiveAverage=1000
...and so on for each of the origin servers in the specified pool

- インスタンスの詳細統計をXML形式で表示するには、次の例に示すようにget-stats-xmlコマンドを実行します。

tadm> get-stats-xml --config=soa --node=soa.example.com

レポートのサンプルについては、13.7項を参照してください。

- インスタンスの統計サマリーをプレーンテキスト形式で表示するには、次の例に示すようにget-perfdumpコマンドを実行します。

tadm> get-perfdump --config=soa --node=soa.example.com

レポートのサンプルについては、13.8項を参照してください。

- TCPプロキシの統計を表示するには、次の例に示すようにget-tcp-proxy-statsコマンドを実行します。

tadm> get-tcp-proxy-stats --config=soa --tcp-proxy=tcp_proxy1
interfaces:*:9898
countActiveConnections=3
countRequests=10
countRequestsAborted=2
countRequestsTimeout=4
countBytesReceived=400
countBytesTransmitted=200
milliSecondsConnectionActiveAverage=1600
mode=1
name=tcp-proxy-1

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

13.4.1 監視統計の自動取得

Oracle Traffic Directorでは、cronジョブを使用して自動的な方法で監視統計を継続して取得し続けることができます。自動化された統計の収集を使用可能にする方法は次のとおりです。

.tadmrcというファイルをOracle Traffic Director管理ユーザー・ホーム・ディレクトリに作成します。

cat > ~/.tadmrc
set tadm_password  <
[ CTRL-D ]

たとえば、管理者はcronジョブを使用することで、継続的にOracle Traffic Directorの監視統計を5分ごとに収集できます。

<otd-install-root>/bin/tadm get-perfdump —user=.. —config=..   —node=..  >>  <output-file>

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

13.3項の説明に従い、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レポート内の要素の階層を示しています。レポート内で要素を表示しないように選択した場合、その要素の子要素も表示されなくなることに注意してください。

server
connection-queue
thread-pool
profile (if profiling is enabled)
process
connection-queue-bucket
thread-pool-bucket
dns-bucket
keepalive-bucket
compression-bucket
decompression-bucket
thread
request-bucket
profile-bucket
virtual-server
request-bucket
profile-bucket
server-pool
origin-server-bucket
cache-bucket
cpu-info

13.6 SNMPを使用した監視

Simple Network Management Protocol (SNMP)は、ネットワーク内のデバイスの管理を、リモート・システムで実行されているネットワーク管理アプリケーションからできるようにするための標準プロトコルです。たとえば、ネットワーク管理アプリケーションには、任意の時点でネットワーク内のどのサーバーが稼働中または停止中であるか、また受信したエラー・メッセージの数およびタイプなどが示されます。

SNMPを使用して、Oracle Traffic Directorインスタンスを監視できます。これを可能にするには、次の操作を行う必要があります。

- SNMPを介した監視をサポートするようにインスタンスを構成します。

- ノードでSNMPサブエージェントを構成します。

- ノードでSNMPサブエージェントを起動します。

この項には次のトピックが含まれます:

- 13.6.1項「Oracle Traffic DirectorのSNMPサポートの構成」

- 13.6.2項「SNMPサブエージェントの構成」

- 13.6.3項「SNMPサブエージェントの起動および停止」

- 13.6.4項「snmpwalkを使用した統計の表示」

13.6.1 Oracle Traffic DirectorのSNMPサポートの構成

構成の作成時、SNMPを介したインスタンスの監視サポートはデフォルトで有効化されます。管理コンソールまたはCLIのいずれかを使用して、SNMPによる監視のサポートを無効化、有効化および構成できます。

管理コンソールを使用したSNMPサポートの構成

管理コンソールを使用してSNMPサポートを有効化するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. SNMPサポートを有効化する構成を選択します。

4. ナビゲーション・ペインで、「詳細設定」を展開し、「監視」を選択します。
「監視設定」ページが表示されます。

5. ページの「SNMP」セクションで、「SNMP」チェック・ボックスを選択します。このセクションのその他のパラメータはオプションです。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

6. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したSNMPサポートの構成

- 構成の現在のSNMP設定を表示するには、次の例に示すようにget-snmp-propコマンドを実行します。

tadm> get-snmp-prop --config=soa
enabled=false

- SNMPサポートを有効化にするには、次の例に示すように、set-snmp-propコマンドを実行します。

tadm> set-snmp-prop --config=soa enabled=true
OTD-70201 Command 'set-snmp-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

Oracle Traffic Directorノードを作成する際(3.1項を参照)、SNMPサブエージェントは自動的に作成されます。SNMPサブエージェントにより、ノードで実行中のインスタンスについての情報が収集されます。SNMPサブエージェントはadmin-serverユーザーとして動作します。Oracle Traffic Directorは、<user>を読み取るためにadmin-server/config/server.xmlを読み込みます。これはSNMPサブエージェントのユーザーとしての実行です。

SNMPサブエージェントの構成設定(サブエージェントにより統計が更新される頻度、キャッシュされた統計がタイムアウトになるまでの時間、サブエージェント・プロセスの通信ポートなど)は、次のファイルに格納されます。

INSTANCE_HOME/admin-server/config/snmpagt.conf

snmpagt.confファイルを編集して、SNMPサブエージェントの設定を構成できます。表13-2は、主要なSNMPサブエージェント・パラメータを示しています。

表13-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インスタンスについての統計の収集が開始されます。SNMPサブエージェント・ライフ・サイクルをOracle Enterprise Linuxを通じてサービスとして管理できます。

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

管理コンソールまたはCLIのいずれかを使用して、ノード上のSNMPサブエージェントを起動および停止できます。

管理コンソールを使用したSNMPサブエージェント起動および停止

管理コンソールを使用して、ノード上のSNMPサブエージェントを起動または停止するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅付近にある「ノード」ボタンをクリックします。
使用可能なノードのリストが表示されます。

3. ノード・リストから、SNMPサブエージェントを起動または停止するノードを選択します。
一般設定ページが表示されます。

- SNMPサブエージェントを起動するには、「SNMPサブエージェントの起動」をクリックします。ステータスが「実行中」に変わります。

- サブエージェントを停止するには、「SNMPサブエージェントの停止」をクリックします。ステータスが「実行中」に変わります。

4. 変更するパラメータを指定してから、「保存」をクリックします。
「コンソール・メッセージ」ペインに、更新した設定が保存されたことを示すメッセージが表示されます。

5. 「共通のタスク」ペインで、「再起動」をクリックして管理サーバーを再起動します。

CLIを使用したSNMPサブエージェントの起動および停止

- SNMPサブエージェントを1つまたは複数のノードで起動するには、次の例に示すようにstart-snmp-subagentを実行します。

tadm> start-snmp-subagent --user=admin --port=3002 node1.example.com node2.example.com
OTD-70210 Successfully started the SNMP subagent.

注意:
または、start-snmp-subagentコマンドを実行する際に--agentxオプションを指定して、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つまたは複数のノードで停止するには、次の例に示すようにstop-snmp-subagentを実行します。

tadm> stop-snmp-subagent --user=admin --port=3002 node1.example.com
OTD-70210 Successfully stopped the SNMP subagent.

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

13.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  2c
defcommunity  public
mibdirs  +/usr/local/share/snmp/mibs #
mibdirs  + <otd_install_root>/lib/snmp #
mibs +ORACLE-TRAFFICDIRECTOR-MIB

これらのオプションを設定しておくと、snmpwalkを次のように実行できます。

snmpwalk  <hostname> ORACLE-TRAFFICDIRECTOR-MIB::instanceTable

snmp.confを使用して設定できるオプションは、snmp.confのmanページで確認できます。

SNMPバージョン2c

Net-SNMPアプリケーション・スイート(http://www.net-snmp.org)で使用可能なsnmpwalkコマンドライン・ユーティリティを使用して、SNMPサブエージェントが収集した統計を表示できます。

snmpwalkコマンドの構文の例を次に示します。

> snmpwalk -c public -v 2c 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 MD5 -A abcd1234 otdadmin

このコマンドでは、次が実行されます。

- /var/net-snmp/snmpd.confへの次のエントリの追加:

createUser otdadmin MD5 "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 MD5 -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にあるドキュメントを参照してください。

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

この項では、get-stats-xmlコマンドを使用して、またはURIを介して表示できる、XML形式での統計レポートのサンプルを示します。詳細は、13.4項「CLIを使用した統計の表示」および13.5項「ブラウザを使用したstats-xmlおよびperfdumpレポートの表示」を参照してください。

このサンプル・レポートに示されている値は、意味のないものである場合があることに注意してください。このサンプル・レポートは、単にレポートに含まれるメトリック、およびレポートの形式や構造の概要を示すことを目的にしています。

<stats versionMajor="1" versionMinor="3" flagEnabled="1">
<server id="net-test" versionServer="Oracle Traffic Director 11.1.1.7.0 B01/31/2013 03:40 (Linux)"
timeStarted="1362099811" secondsRunning="451" ticksPerSecond="1000" maxProcs="1" maxThreads="10"
flagProfilingEnabled="1" load1MinuteAverage="0.000000" load5MinuteAverage="0.020000"
load15MinuteAverage="0.040000" rateBytesTransmitted="173858" rateBytesReceived="1056"
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="25929" mode="active" timeStarted="1362099811" countConfigurations="1"
sizeVirtual="238272" sizeResident="36464" fractionSystemMemoryUsage="0.0045">
<connection-queue-bucket connectionQueueId="cq1" countTotalConnections="2" countQueued="0"
peakQueued="1" maxQueued="2048" countOverflows="0" countTotalQueued="3"
ticksTotalQueued="0" countQueued1MinuteAverage="0.000000"
countQueued5MinuteAverage="0.000000" countQueued15MinuteAverage="0.000000"/>
<thread-pool-bucket threadPoolId="thread-pool-0" countIdleThreads="1" countThreads="1"
maxThreads="128" countQueued="0" peakQueued="0" maxQueued="0"/>
<dns-bucket flagCacheEnabled="1" countCacheEntries="0" maxCacheEntries="1024" countCacheHits="0"
countCacheMisses="0" flagAsyncEnabled="0" countAsyncNameLookups="0" countAsyncAddrLookups="0" countAsyncLookupsInProgress="0"/>
<keepalive-bucket countConnections="0" maxConnections="4096" countHits="0" countFlushes="0" countRefusals="0"
countTimeouts="0" secondsTimeout="30"/>
<compression-bucket countRequests="0" bytesInput="0" bytesOutput="0" compressionRatio="0.000000"
pageCompressionAverage="0.000000"/>
<decompression-bucket countRequests="0" bytesInput="0" bytesOutput="0"/>
<thread mode="idle" timeStarted="1362099811" connectionQueueId="keep-alive">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="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"/>
</thread>
<thread mode="idle" timeStarted="1362099811" connectionQueueId="keep-alive">
<request-bucket countRequests="0" countBytesReceived="0" countBytesTransmitted="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"/>
</thread>
<thread mode="idle" timeStarted="1362099811" connectionQueueId="cq1" clientAddress="10.229.131.192">
<request-bucket countRequests="2" countBytesReceived="336" countBytesTransmitted="18174" countOpenConnections="0" count2xx="2" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="2" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="18" countRequests="2" ticksDispatch="0" ticksFunction="2"/>
<profile-bucket profile="profile-1" countCalls="18" countRequests="2" ticksDispatch="0" ticksFunction="2"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
</thread>
<thread mode="response" timeStarted="1362099811" function="stats-xml" connectionQueueId="cq1"
virtualServerId="test" clientAddress="10.159.75.10" timeRequestStarted="1362100279014665">
<request-bucket method="GET" uri="/stats-xml" countRequests="0" countBytesReceived="0" countBytesTransmitted="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"/>
</thread>
<tcp-thread countPairConnections="0" countConnections="0"/>
<tcp-thread countPairConnections="0" countConnections="0"/>
</process>
<virtual-server id="test" mode="active" interfaces="*:7011">
<request-bucket method="GET" uri="/stats-xml" countRequests="2" countBytesReceived="336" countBytesTransmitted="18174" countOpenConnections="0"
count2xx="2" count3xx="0" count4xx="0" count5xx="0" countOther="0" count200="2" count302="0" count304="0" count400="0" count401="0" count403="0" count404="0" count503="0"/>
<profile-bucket profile="profile-0" countCalls="18" countRequests="2" ticksDispatch="0" ticksFunction="2"/>
<profile-bucket profile="profile-1" countCalls="18" countRequests="2" ticksDispatch="0" ticksFunction="2"/>
<profile-bucket profile="profile-2" countCalls="0" countRequests="0" ticksDispatch="0" ticksFunction="0"/>
<websocket-bucket countUpgradeRequests="0" countUpgradeRequestsFailed="0" countUpgradeRequestsRejected="0"
countActiveConnections="0" countRequestsAborted="0" countRequestsTimedout="0"
countBytesReceived="0" countBytesTransmitted="0" millisecondsConnectionActiveAverage="0"/>
</virtual-server>
<server-pool name="origin-server-pool-1" type="http" countRetries="0">
<origin-server-bucket name="http://adc2120844:4005" flagOnline="1" flagDiscovered="0" flagRampedUp="1" type="generic"
flagBackup="0" secondsOnline="465" countDetectedOffline="0" countConnectAttempts="15"
countConnectFailures="0" countClosedConnections="14" countConnectionsClosedByOriginServer="0"
countActiveConnections="0" countIdleConnections="1" countActiveStickyConnections="0"
secondsKeepAliveTimeout="0" countRequestsAborted="0" countRequestsTimedout="0"
countStickyRequests="0" countRequests="0" countHealthCheckRequests="15" countBytesTransmitted="0"
countBytesReceived="0" weightResponseTime="1.00">
<websocket-bucket countUpgradeRequests="0" countUpgradeRequestsFailed="0" countUpgradeRequestsRejected="0"
countActiveConnections="0" countRequestsAborted="0" countRequestsTimedout="0"
countBytesReceived="0" countBytesTransmitted="0" millisecondsConnectionActiveAverage="0"/>
</origin-server-bucket>
</server-pool>
<cache-bucket flagEnabled="1" countEntries="0" sizeHeapCache="16492" countContentHits="0" countContentMisses="0" countHits="0"
countRevalidationRequests="0" countRevalidationFailures="0"/>
<cpu-info cpu="1" percentIdle="99.224155" percentUser="0.682178" percentKernel="0.093667"/>
<cpu-info cpu="2" percentIdle="99.323128" percentUser="0.601763" percentKernel="0.075109"/>
</server>
</stats>

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

この項では、perfump統計レポートのサンプルを示します。このレポートは、get-perfdumpコマンドを使用して、またはURIを介して表示できます。プレーンテキスト・レポートの表示の詳細は、13.4項「CLIを使用した統計の表示」および13.5項「ブラウザを使用したstats-xmlおよびperfdumpレポートの表示」を参照してください。

このサンプル・レポートに示されている値は、意味のないものである場合があることに注意してください。このサンプル・レポートは、単にレポートに含まれるメトリック、およびレポートの形式の概要を示すことを目的にしています。

Oracle Traffic Director 11.1.1.7.0 B01/14/2013 04:13 (Linux)

Server started Wed Feb 27 23:53:18 2013
Process 10909 started Wed Feb 27 23:53:18 2013

ConnectionQueue:
-----------------------------------------
Current/Peak/Limit Queue Length            0/0/1536
Total Connections Queued                   0
Average Queue Length (1, 5, 15 minutes)    0.00, 0.00, 0.00
Average Queueing Delay                     0.00 milliseconds

ListenSocket http-listener-1:
------------------------
Address                   0.0.0.0:8786
Acceptor Threads          2
Default Virtual Server    config1

KeepAliveInfo:
--------------------
KeepAliveCount        0/3072
KeepAliveHits         0
KeepAliveFlushes      0
KeepAliveRefusals     0
KeepAliveTimeouts     0
KeepAliveTimeout      30 seconds

SessionCreationInfo:
------------------------
Active Sessions           0
Keep-Alive Sessions       0
Total Sessions Created    6/258

Proxy Cache:
---------------------------
Proxy 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                  16501

TCP thread pool :
------------------
Enabled               yes
CountConnectionPairs  0
CountDescriptors      0
CountHalfClosed       0

Native pools:
----------------------------
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:
------------------------------------------------
Average         Total      Percent

Total number of requests:                      0
Request processing time:    0.0000        0.0000

default-bucket (Default bucket)
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%)

Origin server statistics:
---------------------------------------------------------------------------------------------------------------------------------------------------
Pool-name             Host:Port       Status   ActiveConn  IdleConn  StickyConn  Timeouts  Aborted  Sticky-Reqs  Total-Reqs  BytesTrans  BytesRecvd

origin-server-pool-1  http://test     Offline  0           0         0           0         0        0            0           0           0
origin-server-pool-2  http://test:84  Offline  0           0         0           0         0        0            0           0           0

Sessions:
----------------------------------------------------------------------
Process  Status  Client  Age  VS  Method  URI  Function  Origin-Server

TCP Proxy:
------------------------------------
Active Connections                  0
Avg Duration                        0.00 seconds
Requests (timeout/aborted/total)    0/0/0

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

この章では、Oracle Traffic Directorの高可用性機能について説明します。これらの機能はエンジニアド・システム・プラットフォームのみに適用されます。この章の構成は、次のとおりです。

- 高可用性機能の概要

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

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

14.1 高可用性機能の概要

Oracle Traffic Directorインスタンスにおいて高可用性には、次の機能が含まれます。

- ハードウェア障害、カーネル・クラッシュおよびネットワーク障害によるダウンタイムなしで、クライアント・リクエストを受信し処理します。

- 2つのOracle Traffic Directorインスタンスを構成し、アクティブ-アクティブまたはアクティブ-パッシブ・フェイルオーバーを提供することで、エンタープライズ・アプリケーションおよびサービスに対して、可用性の高いルーティングおよびロード・バランシング・サービスを設定できます。詳細は、14.2項「フェイルオーバー・グループの作成および管理」を参照してください。

- 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プロセスはサーバー・プロセス内における限られたレベルの高可用性を実現します。ロード・バランサ・プロセスまたはprimordialプロセスが何かしらの理由で異常終了した場合、Oracle Traffic Directorのwatchdogがそれらのサービスを再起動するため、Oracle Traffic Directorをソフトウェア・ロード・バランス・サービスとして使用し続けることができます。Oracle Traffic Directorインスタンスにはwatchdogプロセスとprimordialプロセスが1つずつと、1つ以上のロード・バランサ・プロセスが存在することになります。

- Oracle Traffic Directorへのほとんどの構成変更は、インスタンスを再起動したり、処理中のリクエストに影響を及ぼしたりすることなく動的にデプロイできます。インスタンスの再起動を必要とする構成変更の場合、管理インタフェース(CLIおよび管理コンソール)にはインスタンスを再起動するためのプロンプトが表示されます。

- クライアント・リクエストをバック・エンドのオリジン・サーバーに確実に分散します。

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

- 各オリジン・サーバー・プールで、いくつかのサーバーをバックアップ・サーバーとして指定できます。Oracle Traffic Directorは、使用可能なプライマリ・サーバーがプールにない場合にのみ、バックアップ・サーバーにリクエストを送信します。詳細は、6.3項「オリジン・サーバー・プールの変更」を参照してください。

- 各オリジン・サーバーが処理できる最大同時接続数を指定することで、接続が過負荷状態になりオリジン・サーバーからリクエストが拒否される可能性を減らすことができます。
各オリジン・サーバーについて、サーバーへのリクエストの送信レートを上げる期間を指定することもできます。この機能により、オフラインのサーバーが再起動中の場合に、リクエストが拒否される可能性を最小限にすることができます。

詳細は、7.3項「オリジン・サーバーの変更」を参照してください。

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

1つまたは2つの仮想IP (VIP)アドレスで表されたフェイルオーバー・グループ内で2つのOracle Traffic Directorインスタンスを組み合せることによって、Oracle Traffic Directorインスタンスの高可用性を確保できます。フェイルオーバー・グループ内の両方のホストでは、同じオペレーティング・システム・バージョンを実行し、同一のパッチおよびサービス・パックを使用し、同じ構成のOracle Traffic Directorインスタンスを実行する必要があります。

注意:

- 1つのノードに複数のフェイルオーバー・グループを作成できますが、各フェイルオーバー・グループにはそれぞれ別のVIPアドレスを付与する必要があります。

図14-1は、アクティブ-パッシブ・モードでの高可用性を実現するためにデプロイされたOracle Traffic Directorを示しています。

図14-1 Oracle Traffic Directorネットワーク・トポロジ: アクティブ-パッシブ・フェイルオーバー・モード

図14-1に示されたトポロジは、2つのOracle Traffic Directorインスタンス(otd_1とotd_2)で構成され、アクティブ-パッシブ・フェイルオーバー・ペアを形成し、クライアント・リクエストに対し単一の仮想IPアドレスを提供します。アクティブなインスタンス(この例ではotd_1など)がリクエストを受信すると、リクエストの送信先のサーバー・プールを特定し、そのサーバー・プールに定義されたロード分散メソッドに基づいてプール内のいずれかのサーバーにリクエストを転送します。

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

ここで説明したアクティブ-パッシブ設定では、フェイルオーバー・グループ内の1つのノードが、どの時点でも冗長となります。リソースの使用率を向上するには、アクティブ-アクティブ・モードの2つのOracle Traffic Directorインスタンスを2つの仮想IPアドレスを使用して構成できます。各インスタンスは1つの仮想IPアドレスで受信したリクエストに応じ、もう1つのインスタンスをバックアップします。

この項には次のトピックが含まれます:

- 14.2.1項「フェイルオーバーの動作」

- 14.2.2項「フェイルオーバー・モード」

- 14.2.3項「フェイルオーバー・グループの作成」

- 14.2.4項「フェイルオーバー・グループの管理」

14.2.1 フェイルオーバーの動作

Oracle Traffic Directorでは、LinuxのkeepalivedやSolarisのvrrpd (ネイティブ)のような、Virtual Routing Redundancy Protocol (VRRP)実装を使用することによって、フェイルオーバー・グループ内のインスタンス間におけるフェイルオーバーをサポートしています。

Exalogic環境のOracle Linuxには、Keepalived v1.2.2が含まれています。インストールまたは構成する必要はありません。Keepalivedは、GNU General Public Licenseに基づいてライセンスされています。Keepalivedには、オリジン・サーバーのロード・バランシングやヘルス・チェックなど、他の機能も備わっていますが、Oracle Traffic DirectorではVRRPサブシステムのみを使用します。Keepalivedの詳細は、http://www.keepalived.orgを参照してください。

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.2.2 フェイルオーバー・モード

フェイルオーバー・グループでは、次のモードで動作するOracle Traffic Directorインスタンスを構成できます:

- アクティブ-パッシブ: 1つのVIPアドレスが使用されます。フェイルオーバー・グループ内の1つのインスタンスがプライマリ・ノードとして指定されます。プライマリ・ノードに障害が発生すると、各リクエストが、同じVIPを通じてもう一方のインスタンスにルーティングされます。

- アクティブ-アクティブ: このモードでは2つのVIPアドレスが必要です。フェイルオーバー・グループ内の各インスタンスは、プライマリ・インスタンスおよびバックアップとして指定され、それぞれにVIPアドレスが1つずつ割り当てられます。各リクエストは両方のインスタンスによって同時に受信されます。

次の図は、アクティブ-アクティブおよびアクティブ-パッシブのフェイルオーバー・モードを表しています。

図14-2 フェイルオーバー・モード

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

この項では、フェイルオーバー・グループを作成してOracle Traffic Directorインスタンスの高可用性ペアを実装する方法を説明します。フェイルオーバーの動作方法の詳細は、14.2.1項「フェイルオーバーの動作」を参照してください。

管理コンソールまたはCLIのいずれかを使用して、フェイルオーバー・グループを作成できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

始める前に

- フェイルオーバー・グループに割り当てる一意のVIPアドレスを決定します。

- クライアントはこれらのVIPアドレスにアクセスできる必要があります。

注意:
Oracle Traffic Directorインスタンスのアクティブ-アクティブ・ペアを構成するには、同じインスタンスを含む2つのフェイルオーバー・グループを作成する必要がありますが、その際、フェイルオーバー・グループごとに異なるVIPアドレスを割り当て、プライマリ・ノードとバックアップ・ノード・ロールを逆にします。

- VIPを管理するインタフェースのネットワーク接頭辞を特定します。このネットワーク接頭辞は、次の例のようなClassless Inter-Domain Routing (CIDR)形式で表されたサブネット・マスクです。

- 256個のアドレスを含むサブネット(8ビット)内のIPv4 VIPアドレスの場合、サブネット・マスク255.255.255.0のCIDR表記は24であり、この値は使用可能なIPv4アドレスの最大数(32ビット)から、指定されたサブネットのアドレス数(8ビット)を引くことによって計算できます。

- 同様に、4096個のアドレスを含むサブネット(12ビット)内のIPv4 VIPアドレスの場合、サブネット・マスク255.255.240.0のCIDR表記は20 (=32-12)となります。

- IPv6サブネットのサブネット・マスクのCIDR表記を計算するには、使用可能なIPv6アドレスの最大数である128ビットから、サブネットのアドレス空間のビット・サイズを引く必要があります。

IPv4 VIPまたはIPv6 VIPのデフォルトのネットワーク・プレフィックス長は、それぞれ24または64です。指定しない場合は、デフォルトのネットワーク・プレフィックス長がNICを自動的に選択するのに使用されます。

VIPを実際にプラミングする際には、そのノードからのすべての発信トラフィックがVIPをソース・アドレスとして使用しないように、ホストマスク(IPv4には32、IPv6には128)を使用することをお薦めします。

- フェイルオーバー・グループ内のプライマリ・ノードおよびバックアップ・ノードとして構成するOracle Traffic Director管理ノードを識別します。
ここで選択する管理ノードに、指定した構成に使用するOracle Traffic Directorインスタンスが存在している必要があります。

- 各ノードのネットワーク・インタフェースを識別します。
ネットワーク・インタフェースを指定しない場合、管理サーバーによって、指定したVIPで使用可能なネットワーク・インタフェースの検出が自動的に試行されます。現在ホスト上で稼働しているネットワーク・インタフェースごとに、管理サーバーによって、インタフェースの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を指定しない場合、最初のフェイルオーバー・グループについては255に設定されます。後続のフェイルオーバー・グループを作成するたびに、デフォルトのルーターIDは、254、253のように1つずつ減ります。

管理コンソールを使用したフェイルオーバー・グループの作成

管理コンソールを使用してフェイルオーバー・グループを作成するには、次の操作を行います:

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. フェイルオーバー・グループを作成する構成を選択します。

4. ナビゲーション・ペインで、「フェイルオーバー・グループ」を選択します。
フェイルオーバー・グループ・ページが表示されます。

5. 「新規フェイルオーバー・グループ」をクリックします。
新規フェイルオーバー・グループ・ウィザードが表示されます。

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

6. 画面上のプロンプトに従って、仮想IPアドレス、ネットワーク・インタフェース、管理ノードのホスト名など、前に決定した詳細を使用してフェイルオーバー・グループの作成を完了します。
フェイルオーバー・グループが作成されたら、新規フェイルオーバー・グループ・ウィザードの結果画面に、フェイルオーバー・グループの作成が成功したことを示すメッセージが表示されます。

7. 結果画面で、「閉じる」をクリックします。
フェイルオーバー・グループ・ページに、作成したフェイルオーバー・グループの詳細が表示されます。

注意:
この時点では、2つのノードはアクティブ-パッシブ・ペアになっています。これらをアクティブ-アクティブ・ペアに変更するには、同じ2つのノードを含む別のフェイルオーバー・グループを作成しますが、その際、異なるVIPを割り当て、プライマリおよびバックアップ・ロールを逆にします。

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

フェイルオーバー・グループを作成するには、create-failover-groupコマンドを実行します。

たとえば、次のコマンドでは、次の詳細でフェイルオーバー・グループが作成されます。

- 構成: soa

- プライマリ・ノード: node1.example.com

- バックアップ・ノード: node2.example.com

- 仮想IPアドレス: 10.229.227.80

- VIPのネットワーク接頭辞: 指定されていないため、コマンドでは、ネットワーク接頭辞は24 (サブネット・マスク255.255.255.0に相当)と見なされます

> tadm create-failover-group --config=soa --virtual-ip=10.229.227.80 --primary-node=node1.example.com --backup-node=node2.example.com
OTD-70201 Command 'create-failover-group' ran successfully.

注意:
フェイルオーバー・グループを作成する際、インスタンスが存在するノード上で管理ノード・プロレスが非rootとして実行されている場合は、これらのノードでrootユーザーとしてstart-failoverを実行する必要があります。これはフェイルオーバーを手動で開始するためです。このコマンドを実行しないとフェイルオーバーは開始しないため、高可用性を実現できません。start-failoverの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照してください。

これらをアクティブ-アクティブ・フェイルオーバーを有効にするには、同じ2つのノードを含む別のフェイルオーバー・グループを作成しますが、プライマリとバックアップ・ロールを逆にします。

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

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

Oracle Traffic Directorでは、フェイルオーバー・グループの一部であるインスタンスを起動するとkeepalivedデーモンが自動的に起動され、インスタンスを停止するとデーモンが停止されます。keepalivedデーモンの構成パラメータは、フェイルオーバー・グループの一部である各インスタンスのconfigディレクトリにあるkeepalived.confというファイルに格納されます。インスタンスが存在するノード上で管理ノード・プロレスが非rootとして実行されている場合は、これらのノードでrootユーザーとしてstart-failoverコマンドを実行する必要があります。これはフェイルオーバーを手動で開始するためです。このコマンドを実行しないとフェイルオーバーは開始しないため、高可用性を実現できません。start-failoverの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照してください。

注意:
keepalivedデーモンが自動的に起動および停止するようにするには、コマンドを実行して、Oracle Traffic Directorインスタンスをrootユーザーとして起動および停止する必要があります。

フェイルオーバー・グループを作成したら、それらをリストしたり、設定を表示したり、フェイルオーバー・グループのプライマリ・ノードを変更したり、プライマリ・ノードとバックアップ・ノードを切り替えたり、それらを削除したりすることができます。フェイルオーバー・グループのVIPまたは任意のプロパティを変更するには、フェイルオーバー・グループを削除してから新たに作成しなおす必要があることに注意してください。

管理コンソールまたはCLIを使用することによって、フェイルオーバー・グループを表示、変更および削除できます。

注意:
この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

管理コンソールを使用したフェイルオーバー・グループの管理

管理コンソールを使用してフェイルオーバー・グループを表示、変更および削除するには、次の操作を行います:

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. フェイルオーバー・グループを管理する構成を選択します。

4. ナビゲーション・ペインで、「フェイルオーバー・グループ」を選択します。
フェイルオーバー・グループ・ページが表示されます。使用可能なフェイルオーバー・グループのリストが表示され、各フェイルオーバー・グループのプライマリ・ノードおよびバックアップ・ノードが示されます。

- フェイルオーバー・グループのプロパティを表示するには、その仮想IPをクリックします。

- プライマリ・ノードおよびバックアップ・ノードのホストを切り替えるには、「プライマリの切替え」ボタンをクリックします。結果のダイアログ・ボックスで、「OK」をクリックします。

- フェイルオーバー・グループを削除するには、「削除」ボタンをクリックします。結果のダイアログ・ボックスで、「OK」をクリックします。

CLIを使用したフェイルオーバー・グループの管理

- 構成のフェイルオーバー・グループのリストを表示するには、次の例に示すようにlist-failover-groupsコマンドを実行します。

tadm> list-failover-groups --config=soa --verbose --all
virtual-ip      primary-node    backup-node
-------------------------------------------
10.229.231.254  node1.example.com      node2.example.com
10.229.231.253  node2.example.com      node1.example.com

- フェイルオーバー・グループの現在の設定を表示するには、次の例に示すようにget-failover-group-propコマンドを実行します。

tadm> get-failover-group-prop --config=soa --virtual-ip=10.229.231.254
virtual-ip=10.229.231.254
backup-node=node2.example.com
network-prefix-length=21
router-id=255
primary-node=node1.example.com
primary-nic=eth0
backup-nic=eth0

- フェイルオーバー・グループのプライマリとバックアップ・ノードを切り替えるには、set-failover-group-primaryコマンドを実行します。
たとえば、次のコマンドを実行すると、構成soaのVIPアドレス10.228.12.250で表されるフェイルオーバー・グループのプライマリ・ノードがapp2.example.comに変更されます。

tadm> set-failover-group-primary --config=soa  --virtual-ip=10.228.12.250 --primary-node=app2.example.com
OTD-70201 Command 'set-failover-group-primary' ran successfully.

注意:
管理ノード・プロセスがインスタンスの置かれているノードで非rootとして実行中である場合、これらのノードでrootユーザーとしてstart-failoverを実行する必要があります。これはノードを手動で切り替えるためです。このコマンドを実行しないとノードは切り替わりません。get-failover-group-propを実行すると、実行結果に構成済のプライマリ・ノードとバックアップ・ノードが含まれますが、これらは実行時のプライマリ・ノードおよびバックアップ・ノードであるとはかぎりません。

- フェイルオーバー・グループを削除するには、次の例に示すように、delete-failover-groupコマンドを実行します。

tadm> delete-failover-group --config=soa  --virtual-ip=10.228.12.250
OTD-70201 Command 'delete-failover-group' ran successfully.

注意:
フェイルオーバー・グループを削除する際、管理ノード・プロセスがインスタンスの置かれているノードで非rootとして実行中であり、少なくとも1つのフェイルオーバー・グループが引き続き使用可能である場合、これらのノードでrootユーザーとしてstart-failoverを実行する必要があります。これとは逆に、フェイルオーバー・グループを削除すると、当該インスタンスで使用できるフェイルオーバー・グループがなくなる場合は、stop-failoverを実行してフェイルオーバーを停止する必要があります。start-failoverとstop-failoverのいずれも実行しなかった場合、削除したフェイルオーバー・グループに関連付けられているVIPが使用可能な状態として存続し続けます。これらのコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照してください。

この項で説明されたコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

注意:

- 異なるノードをフェイルオーバー・グループ内のプライマリ・ノードまたはバックアップ・ノードとして割り当てるには、フェイルオーバー・グループを新たに作成しなおす必要があります。

- 複数の構成にわたって最大255個のフェイルオーバー・グループを作成できます。

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

リクエストを受信できる使用可能なオリジン・サーバーにのみリクエストが分散されるように、Oracle Traffic Directorはヘルス・チェック・リクエストをプール内のすべてのオリジン・サーバーに送信することでオリジン・サーバーの可用性および状態を監視します。

管理コンソールまたはCLIのいずれかを使用して、オリジン・サーバー・プールのヘルス・チェック・パラメータを構成できます。

注意:

- オリジン・サーバー・プールのヘルス・チェック設定を構成すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、4.3項「構成のデプロイ」の説明に従い、構成を再デプロイする必要があります。

- この項のCLIの例はシェル・モード(tadm>)で示されています。CLIシェルの起動の詳細は、2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

Oracle Traffic Directorがヘルス・チェック・リクエストを送信するタイミング

Oracle Traffic Directorインスタンスの起動時に、構成済のすべてのオリジン・サーバー・プール内のすべてのオリジン・サーバーに対して初期ヘルス・チェックが実行されます。

初期ヘルス・チェックでオリジン・サーバーの状態が正常であると判明すると、次の状況の場合のみOracle Traffic Directorはさらにヘルス・チェック・リクエストをオリジン・サーバーに送信します。

- 前回のヘルス・チェック間隔全体を通して、サーバーによってリクエストが正常に処理されませんでした。

- 動的検出が、このオリジン・サーバー・プールで有効に設定されています。詳細は、6.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。

ヘルス・チェック(初期または後続のチェックのいずれか)でオリジン・サーバーが使用不可であることが判明した場合、Oracle Traffic Directorは、指定されたヘルス・チェック間隔でヘルス・チェックを繰り返します。

構成可能なヘルス・チェック設定

表14-1は、構成内の各オリジン・サーバー・プールについて構成できるヘルス・チェック設定を示しています。

表14-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)。

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までのレスポンス・コード受け入れます。

- レスポンス本文が、受入れ可能なレスポンス本文(指定されている場合)と一致しています。

管理コンソールを使用したオリジン・サーバーのヘルス・チェック設定の構成

管理コンソールを使用して、プール内のオリジン・サーバーのヘルス・チェック設定を表示および変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. オリジン・サーバーのヘルス・チェック設定を表示または変更する、構成を選択します。

4. ナビゲーション・ペインで、「オリジン・サーバー・プール」を展開し、ヘルス・チェック設定を表示または変更するオリジン・サーバー・プールを選択します。
「オリジン・サーバー・プール」ページが表示されます。構成に定義されたオリジン・サーバー・プールのリストが表示されます。

5. 変更するオリジン・サーバー・プールの名前をクリックします。
「サーバー・プール設定」ページが表示されます。

6. ページの「詳細設定」セクションに移動します。

7. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

8. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したオリジン・サーバーのヘルス・チェック設定の構成

- 構成内のオリジン・サーバー・プールの現在のヘルス・チェック設定を表示するには、次の例に示すように、get-health-check-propコマンドを実行します。

tadm> get-health-check-prop --config=soa --origin-server-pool=osp1
response-body-match-size=2048
protocol=HTTP
interval=30
request-method=OPTIONS
failover-threshold=3
request-uri=/
dynamic-server-discovery=false
timeout=5

- 構成内のオリジン・サーバー・プールのヘルス・チェック設定を変更するには、set-health-check-propコマンドを実行します。
たとえば、次のコマンドにより、構成soa内のオリジン・サーバー・プールosp1のヘルス・チェック間隔が60秒に変更され、ヘルス・チェックのタイムアウト時間が10秒に変更されます。

tadm> set-health-check-prop --config=soa --origin-server-pool=osp1 interval=60 timeout=10
OTD-70201 Command 'set-health-check-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

14.3.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で終了しサーバー・ステータスをオンラインに設定することが想定されています。実行可能ファイルがイベント・ログにメッセージをロギングするようにするには、標準出力にそれらのメッセージを出力します。

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

構成内のオリジン・サーバー・プールのヘルス・チェック設定を外部実行可能ファイルを使用するように構成するには、set-health-check-propコマンドを実行します。

たとえば、次のコマンドはヘルス・チェック・メソッドをCOMMANDに設定し、外部ヘルス・チェック実行可能ファイルに/path/myhcscriptのパスを指定します。間隔およびタイムアウト・プロパティも指定されます。

tadm> set-health-check-prop --user=admin --host=admin.example.com  --password-file=./admin.passwd --port=8989 --no-prompt --config=www.example.org --origin-server-pool=test-pool protocol=COMMAND interval=25 timeout=4 command=/path/myhcscript
OTD-70201 Command 'set-health-check-prop' ran successfully.

注意:
オリジン・サーバー・プールのHTTPタイプの場合、COMMANDヘルス・チェック・プロトコルは次の場合には考慮されません。

- オリジン・サーバー・タイプがUNDETECTEDの場合、または、

- オリジン・サーバー・タイプがWLSで動的検出が設定されている場合。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

14.3.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は、それぞれホスト、ポートおよびタイムアウトを表します。

表14-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はプロセスを終了してサーバー・ステータスをオフラインに設定します。

14.3.1.3 ロギング

Oracle Traffic Directorは、環境変数OTD_LOG_LEVELを通じて外部プログラムに構成済ロギング・レベルを渡し、その環境変数の値は整数です。外部実行可能ファイルでは、ロギング・レベルに基づいてロギング・メッセージの量をカスタマイズできます。次の表は、Oracle Traffic Directorロギング・レベルと引数値の間のマッピングを定義します。

表14-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レベルでロギングされます。

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

この章では、Oracle Traffic Directorインスタンスおよび仮想サーバーの統計データを使用して、潜在的なパフォーマンスのボトルネックを特定する方法を説明します。また、Oracle Traffic Directorのパフォーマンスを向上させるために行える構成変更についても説明します。

この章には次の項が含まれます:

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

- 接続処理設定のチューニング

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

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

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

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

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

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

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

- Solaris固有のチューニング

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

この章で提供されるチューニングの提案内容の実行結果は、各ユーザーの環境に応じて異なる場合があります。ニーズに適したチューニング・パラメータを決定する際には、次のガイドラインに留意してください。

- 1回ごとに1つのパラメータを調整します
可能な限り、1回ごとに1つの調整を行ってください。各変更の前と後でパフォーマンスを計測し、大きな改善が見られない変更は元に戻します。

- パフォーマンス・ベンチマークの作成に使用できるテスト・ケースを設定します。
パラメータを変更する前に、パフォーマンスに及ぼす変更の影響をテストするためのテスト・ケースを設定し、可能な場合は自動化します。

- 段階的にチューニングします
量的なパラメータを調整する場合、小さい増分単位で変更してください。これは、最適な設定を迅速に特定するのに最も適切な方法です。

- ハードウェアまたはソフトウェアを変更した後は、再び最初から確認します
ハードウェアまたはソフトウェアのアップグレードなど、主なシステム変更ごとに、前のチューニングの変更が適用できるかどうかを確認します。

15.2 接続処理設定のチューニング

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

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

- 15.2.2項「HTTPリスナー設定のチューニング」

- 15.2.3項「キープ・アライブ設定のチューニング」

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

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

- 第15.2.1.1項「接続処理概要」

- 15.2.1.2項「インスタンスの接続キュー・メトリックの確認」

- 15.2.1.3項「インスタンスのスレッド・プール・メトリックの確認」

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

15.2.1.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.2.1.2 インスタンスの接続キュー・メトリックの確認

接続キューの最大サイズが十分ではない場合、クライアント・リクエストは、ロードがピークの時間帯は却下される可能性があります。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.2.1.3 インスタンスのスレッド・プール・メトリックの確認

プレーンテキスト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.2.1.2項を参照)が、平均レスポンス時間と比較して著しく大きい場合も、スレッド制限数を増やす必要があることを意味します。

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

管理コンソールまたはCLIのいずれかを使用して、スレッド・プールおよび接続キュー設定を変更できます。

管理コンソールを使用したスレッド・プールおよび接続キュー設定の変更

管理コンソールを使用してスレッド・プール設定を変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 変更する構成を選択します。

4. ナビゲーション・ペインで、「詳細設定」を展開し、HTTPを選択します。
「HTTP設定」ページが表示されます。

5. ページの「スレッド・プール」セクションに移動します。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したスレッド・プールおよび接続キュー設定の変更

- 現在のスレッド・プール設定を表示するには、次の例に示すようにget-thread-pool-propコマンドを実行します。

tadm> get-thread-pool-prop --config=soa
enabled=true
stack-size=262145
max-threads=20480
queue-size=2000
min-threads=20480

- スレッド・プール設定を変更するには、set-thread-pool-propコマンドを実行します。
たとえば、接続キュー・サイズを変更するには、次のコマンドを実行します。

tadm> set-thread-pool-prop --config=soa queue-size=2000
OTD-70201 Command 'set-thread-pool-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイします。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

15.2.2 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

10.3項「リスナーの変更」の説明に従い、管理コンソールまたはCLIを使用して、HTTPリスナーの設定を変更できます。

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

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

- 15.2.3.1項「キープ・アライブ接続について」

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

- 15.2.3.3項「キープ・アライブ設定のチューニング」

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

HTTP 1.0およびHTTP 1.1は、単一のHTTP接続での複数のリクエストの送信をサポートしています。HTTP 1.0ではキープ・アライブと呼ばれていたこの機能は、HTTP 1.1では永続接続と呼ばれ、Oracle Traffic Directorではデフォルトで有効化されています。

元のリクエストを処理した後も接続をアクティブのまま保持することで、その後の類似したリクエストに対するTCP接続の作成およびクローズに関連する時間およびオーバーヘッドを削減できます。ただし、受信するリクエストが少ない、またはない場合、キープ・アライブ接続はシステムに対して不要な負荷となります。

この問題を回避するために、待機中のキープ・アライブ接続の最大数を指定できます。キープ・アライブ・リクエストが受信されたとき、リクエスト待機中のオープン接続が、指定した最大数を超えて存在する場合、最も古い接続はクローズされます。また、一定期間非アクティブであるキープ・アライブ接続をクローズする場合のその期間を指定できます。

15.2.3.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.3項「ファイル・ディスクリプタ制限のチューニング」の説明に従い、ファイル・ディスクリプタ制限を増やすことができます。

- KeepAliveRefusalsは、考えられる理由の1つとしてKeepAliveCountがキープ・アライブ最大接続数を超えたために、サーバーが接続をキープ・アライブ・スレッドに渡すことができなかった回数です。この値が大きい場合、キープ・アライブ接続の最大数を増やすことを検討してください。

- KeepAliveTimeoutsは、前回のKeepAliveTimeout期間中に、キープ・アライブ接続でリクエストが受信されなかったため、アイドル状態のキープ・アライブ接続がクローズされた回数です。

- KeepAliveTimeoutは、アイドル状態のキープ・アライブ接続がクローズされるまでの秒単位での期間です。
構成可能でパフォーマンスに影響を及ぼすが、perfdumpレポートには表示されない、もう1つのパラメータとして、キープ・アライブ・ポーリング間隔がありますが、これはKeepAliveTimeoutとともに、待機時間およびスループットを制御します。ポーリング間隔およびタイムアウト期間を短くすると、負荷の小さいシステムの待機時間が短くなります。これらの設定の値を大きくすると、負荷の大きいシステムの集約スループットが向上します。ただし、待機時間が長く、クライアント数が少なすぎる場合、サーバーが不必要にアイドル状態のままとなるため集約スループットに悪影響が出ます。したがって、一定の負荷で、アイドルのCPU時間がある場合ポーリング間隔を短くし、アイドル状態のCPU時間がない場合ポーリング間隔を長くします。

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

管理コンソールまたはCLIのいずれかを使用して、キープ・アライブ設定をチューニングできます。

管理コンソールを使用したキープ・アライブ設定の変更

管理コンソールを使用してキープ・アライブ設定を変更するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 変更する構成を選択します。

4. ナビゲーション・ペインで、「詳細設定」を展開し、HTTPを選択します。
「HTTP設定」ページが表示されます。

5. ページの「キープ・アライブ」セクションに移動します。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したキープ・アライブ設定の変更

- 現在のキープ・アライブ設定を表示するには、次の例に示すようにget-keep-alive-propコマンドを実行します。

tadm> get-keep-alive-prop --config=soa
enabled=true
threads=20
max-connections=2000
poll-interval=0.002
timeout=31

- キープ・アライブ設定を変更するには、set-keep-alive-propコマンドを実行します。
たとえば、キープ・アライブ接続の最大数を変更するには、次のコマンドを実行します。

tadm> set-keep-alive-prop --config=soa max-connections=2000OTD-70201 Command 'set-keep-alive-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイします。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

オペレーティング・システムでは、ファイル・ディスクリプタを使用して、ファイルシステムのファイル、および接続やリスナー・ソケットなどの擬似ファイルを処理します。

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インスタンスが起動すると、制限(最大キープ・アライブ接続、接続キューのサイズ、および各オリジン・サーバーの最大接続数)が、システム内で使用可能なファイル・ディスクリプタの合計数に基づいて自動的に構成されます。

たとえば、HTTP処理スレッドの最大数 * 4は、プロセスに有効なファイル・ディスクリプタの最大数より少ないことが理想です。HTTP処理スレッドの最大数を増やす場合、それに応じてTraffic Directorに使用できるファイル・ディスクリプタの合計数も増やしてください。(たとえば、ファイル・ディスクリプタ制限が65536に設定されている場合にHTTP処理スレッドの最大数を20000に設定すると、最適なチューニングを得られません。これは、ワーカー・スレッド用として80000 (20000*4=80000)がファイル・ディスクリプタを使い切って/予約してしまい、他のサブシステム用に残るファイル・ディスクリプタが少なくなるためです。)そのため、HTTPリクエスト処理スレッドの最大数に高い値を設定する場合は、必ず事前にテストを行ってください。

図15-1は、構成の拡張設定でHTTP処理スレッドの最大数を増やす方法を表しています。

図15-2 HTTP処理スレッドの最大数

割り当てられたファイル・ディスクリプタ数は、システムでサポート可能な制限を超えられません。ファイル・ディスクリプタの現在のシステム制限を確認するには、次のコマンドを実行します。

$ 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.10.1項「単一のプロセスで開くファイル(ファイル・ディスクリプタの制限)」を参照してください。

ほとんどのオペレーティング・システムでは、プロセス(Oracle Traffic Directorなど)で使用可能なファイル・ディスクリプタの最大数の制限をシステム管理者が構成できるようにしています。Linuxマシンでは、この制限は通常ulimit -nで、システムにログインするとき、または単にアプリケーションを開始するときに設定されます。システム管理者は、Oracle Traffic Directorサーバー・インスタンスを開始する前に、この制限(通常、ulimit -nによる制限)が少なくとも32276以上のファイル・ディスクリプタ(または、スループットの高いシステムでは65536)に設定されていることを確認する必要があります。

thumbのおおよそのルールとして、thread-pool要素、max-threads * 4がプロセスで利用できる最大ファイル・ディスクリプタ数よりも小さくなるようにするというルールがあります。これはつまり、max-threadsを最大ファイル・ディスクリプタ数の1/5未満にするということです。

たとえば、ファイル・ディスクリプタ制限が65536に設定されている場合にmax-threadsを20000に設定すると、最適なチューニングを得られません。これは、ワーカー・スレッド用として20000*4=80000がファイル・ディスクリプタを使い切って/予約してしまい、他のサブシステム用にファイル・ディスクリプタがほとんど残らないためです。

max-threadsに高い値を設定する場合は、必ず事前にテストを行ってください。1つのプロセスに数万のスレッドが存在する状態はパフォーマンスに影響を及ぼすことがあります。

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

Oracle Traffic Directorインスタンスがリクエストおよびレスポンスの処理に費やす時間を最適化するために、リクエストとレスポンスのヘッダー・サイズ、リクエストに許可されているヘッダー・フィールド数、およびOracle Traffic DirectorがHTTPリクエストの本文とヘッダーの受信を待機する時間などのパラメータを構成できます。

管理コンソールまたはCLIのいずれかを使用して、HTTPリクエストとレスポンスの制限の変更を表示できます。

管理コンソールを使用したHTTPリクエスト/レスポンスの制限の表示および変更

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 変更する構成を選択します。

4. ナビゲーション・ペインで、「詳細設定」を展開し、HTTPを選択します。
「HTTP設定」ページが表示されます。

5. ページの「HTTP」セクションに移動します。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したHTTPリクエスト/レスポンスの制限の表示および変更

- 現在の設定を表示するには、次の例に示すようにget-keep-alive-propコマンドを実行します。

tadm> get-http-prop --config=soa
request-header-timeout=30
request-body-timeout=-1
etag=true
io-timeout=30
max-request-headers=64
strict-request-headers=false
version=HTTP/1.1
discard-misquoted-cookies=true
ecid=true
favicon=true
unchunk-timeout=60
max-unchunk-size=8192
output-buffer-size=8192
request-header-buffer-size=8192

- リクエストおよびレスポンスの制限を変更するには、set-http-propコマンドを実行します。
たとえば、レスポンス・バッファ・サイズを変更するには、次のコマンドを実行します。

tadm> set-http-prop --config=soa output-buffer-size=16384OTD-70201 Command 'set-http-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイします。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

15.5 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.5.1項「DNSキャッシュ設定およびメトリックの表示」

- 15.5.2項「DNSキャッシュ設定の構成」

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

DNSキャッシュ設定の表示

構成の現在のDNSキャッシュ設定を表示するには、次の例に示すようにget-dns-cache-propコマンドを実行します。

tadm> get-dnscache-prop --config=soa
enabled=true
max-entries=1024
max-age=120

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.5.2 DNSキャッシュ設定の構成

管理コンソールまたはCLIのいずれかを使用して、構成のDNSキャッシュ設定を構成できます。

管理コンソールを使用したDNSキャッシュ設定の構成

管理コンソールを使用してDNSキャッシュ設定を構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 変更する構成を選択します。

4. ナビゲーション・ペインで、「詳細設定」を選択します。
「詳細設定」ページが表示されます。

5. ページの「DNS」セクションに移動します。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したDNSキャッシュ設定の構成

構成のDNSキャッシュ設定を変更するには、set-dns-cache-propコマンドを実行します。

たとえば、次のコマンドでは、DNSキャッシュに許可された最大エントリ数が2048に変更されます。

tadm> set-dns-cache-prop --config=soa max-entries=2048
OTD-70201 Command 'set-dns-cache-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

この項には次のトピックが含まれます:

- 15.6.1項「SSL/TLSセッションのキャッシュ」

- 15.6.2項「暗号および証明書鍵」

15.6.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がキャッシュ内に格納される期間を構成できます。

管理コンソールまたはCLIのいずれかを使用して、構成のSSL/TLSセッション・キャッシュ設定を構成できます。

管理コンソールを使用したSSL/TLSセッション・キャッシュ設定の構成

管理コンソールを使用してSSL/TLSセッション・キャッシュ設定を構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 変更する構成を選択します。

4. ナビゲーション・ペインで、「SSL」を選択します。
「SSL設定」ページが表示されます。

5. ページの「SSL」および「TLS」セクションに移動します。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したSSL/TLSセッション・キャッシュ設定の構成

- 構成の現在のSSL/TLSキャッシュ設定を表示するには、次の例に示すようにget-ssl-session-cache-propコマンドを実行します。

tadm> get-ssl-session-cache-prop --config=test
max-ssl3-tls-session-age=86400
enabled=true
max-entries=10000

- SSL/TLSセッション・キャッシュ設定を変更するには、set-ssl-session-cache-propコマンドを実行します。
たとえば、次のコマンドでは、SSL/TLSセッション・キャッシュに許可された最大エントリ数が20000に変更されます。

tadm> set-ssl-session-cache-prop --config=soa max-entries=20000
OTD-70201 Command 'set-ssl-session-cache-prop' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

15.6.2 暗号および証明書鍵

強力な暗号およびサイズの大きい秘密鍵を使用すると、SSL/TLS接続のセキュリティはより安全に保護されますが、パフォーマンスに影響を及ぼします。

- SSL/TLS接続において、特定の暗号(AES、RC4など)では、より強力な暗号(3DESなど)よりもデータ転送に必要な演算リソースが少なくて済みます。「厳密なSNIホスト一致」が有効化されているリスナーでSSL/TLS暗号を選択する場合、この点を考慮してください。
リスナーに対する暗号の構成の詳細は、11.2.4項「リスナーのSSL/TLS暗号の構成」を参照してください。

SNIホスト一致の詳細は、11.2.6項「厳密なSNIホスト一致について」を参照してください。

- 最初のSSL/TLSハンドシェイク・プロセスでは、鍵サイズの小さいRSA証明書(1024および2048ビット)の方が鍵サイズの大きい証明書(3072および4096ビット)よりもかかる時間が短くなります。
自己署名証明書および証明書署名リクエストの作成の詳細は、11.4項「証明書の管理」を参照してください。

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

アクセス・ログには、サーバーへのクライアント・リクエストおよびサーバーからのレスポンスについての情報が含まれます。Oracle Traffic Directorインスタンスのクライアント・リクエストの受信率が非常に高い場合、これは、本番環境では一般的な状況ですが、ディスク上のログ・ファイルにエントリが書き込まれる頻度が高くなります。ディスクへの頻繁な書込みは、サーバーのパフォーマンスに影響する可能性のある、I/Oに負荷がかかるアクティビティです。

Oracle Traffic Directorがディスク上のアクセス・ログにエントリを書き込む頻度を減らすために、アクセス・ログの更新内容をバッファできます。Oracle Traffic Directorでは、アクセス・ログのバッファリングはデフォルトで有効化されます。

アクセス・ログ・バッファ・サイズ、1サーバー当たりのアクセス・ログ・バッファ数、およびエントリがバッファ内に保持される最大期間の制限を指定できます。バッファ・サイズ、バッファ数、またはバッファ内のエントリの経過時間が、指定した制限に到達すると、Oracle Traffic Directorは、バッファされたデータをディスク上のアクセス・ログに書き込みます。

管理コンソールまたはCLIのいずれかを使用して、アクセス・ログ・バッファ設定を構成できます。

管理コンソールを使用したアクセス・ログ・バッファ設定の構成

管理コンソールを使用してアクセス・ログ・バッファ設定を構成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. アクセス・ログ・バッファ・プリファレンスを構成する構成を選択します。

4. ナビゲーション・ペインで、「ロギング」を選択します。
「ログ・プリファレンス」ページが表示されます。

5. ページの「詳細設定」セクションに移動し、「アクセス・ログ・バッファ」サブセクションにスクロール・ダウンします。

6. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したアクセス・ログ・バッファ設定の構成

- 現在のアクセス・ログ・バッファ・プロパティを表示するには、次の例に示すようにget-access-log-buffer-propコマンドを実行します。

tadm> get-access-log-buffer-prop --config=soa
direct-io=false
enabled=true
max-buffers-per-file=default
buffer-size=8192
max-buffers=1000
max-age=1

アクセス・ログ・バッファ・プロパティを変更するには、次の例に示すようにset-access-log-buffer-propコマンドを実行します。

- アクセス・ログ・バッファ・プロパティを変更するには、次の例に示すようにset-access-log-buffer-propコマンドを実行します。

tadm> set-access-log-buffer-prop --config=soa
direct-io=false
enabled=true
max-buffers-per-file=default
buffer-size=8192
max-buffers=1000
max-age=1

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

ログの表示、ログ・プリファレンスの構成、ログのローテーションなどの詳細は、第12章「ログの管理」を参照してください。

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

圧縮されたオブジェクトは、少ないラウンドトリップで、より速くクライアントに送信されるため、高価なハードウェアへの投資を増やすことなく全体の待機時間が削減されます。

各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間に存在するプロキシに、コンテンツの解凍が不可なクライアントに圧縮済コンテンツを提供しないように指示します。

管理コンソールを使用した圧縮ルールの構成

管理コンソールを使用して圧縮ルールを作成するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. 圧縮ルールを作成する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を展開し、圧縮ルールを作成する仮想サーバーの名前を展開して、「圧縮」を選択します。
「圧縮ルール」ページが表示されます。仮想サーバーに現在定義されている圧縮ルールがリストされ、その圧縮ルールが有効化されているかどうかが示されます。

圧縮ルールの作成

1. 「新規圧縮ルール」をクリックします。
「新規圧縮ルール」ダイアログ・ボックスが表示されます。

「名前」フィールドで、新規圧縮ルールの名前を入力します。

「圧縮レベル」ドロップダウン・リストから圧縮レベルを選択します。

2. 次へをクリックします。
この圧縮ルールが仮想サーバーに対する最初の圧縮ルールの場合、「新規キャッシュ・ルール」ダイアログ・ボックスに、ルールをすべてのリクエストに適用するかどうかを選択するオプションが表示されます。「すべてのリクエスト」を選択します。

条件を満たすリクエストにのみ、ルールを適用する場合は、「条件を新規に作成します」を選択して新しい条件を作成します。「新規式」ペインで「変数/関数」を選択し、各ドロップダウン・リストから演算子を選択し、「値」フィールドに値を入力します。

複数の式を構成する場合は、ドロップダウン・リストでand/or演算子を選択します。同様に、指定した式が偽に評価されるときにルートを適用する場合は、Not演算子を使用します。

条件を手動入力するには、「取消」をクリックし、「手動編集」をクリックします。「条件」フィールドで、ルールが適用される条件を指定します。条件式の作成の詳細は、「条件」フィールドの近くにあるヘルプ・ボタンをクリックするか、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

3. 次へをクリックし、「圧縮ルールの作成」をクリックします。
作成したキャッシュ・ルールが「圧縮ルール」ページに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

圧縮ルールの編集

圧縮ルールを有効化または無効化する、あるいはルールの設定を変更するには、次の操作を行います。

1. 変更する圧縮ルールの「名前」をクリックします。
「圧縮ルールの編集」ダイアログ・ボックスが表示されます。

注意:
条件ビルダーにアクセスして条件を編集するには、「条件を満たすリクエスト」を選択し、「編集」をクリックします。条件ビルダーでは古い式を削除したり、新しい式を作成したりできます。

2. 変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

3. 必要な変更を行った後、「保存」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

圧縮ルールの削除

圧縮ルールを削除するには、「削除」ボタンをクリックします。確認プロンプトで、「OK」です。

CLIを使用した圧縮ルールの構成

- 仮想サーバーの圧縮ルールを作成するには、create-compression-ruleコマンドを実行します。
たとえば、次のコマンドでは、構成soaの仮想サーバーsoa.example.comに対してcompress-docsという名前のルールが作成され、このルールでは、式$uri='^/docs'が真と評価されるリクエストがキャッシュされます。

tadm> create-compression-rule --condition="\$uri='^/docs'" --config=soa --vs=soa.example.com compress-docs
OTD-70201 Command 'create-compression-rule' ran successfully.

--conditionオプションの値は、正規表現にする必要があることに注意してください。条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

- 仮想サーバーに定義された圧縮ルールのリストを表示するには、次の例に示すようにlist-compression-rulesコマンドを実行します。

tadm> list-compression-rules --config=soa --vs=soa --verbose --all
rule            condition
-------------------------
compress-docs   "$uri = '^/docs'
compress-all    -

- 圧縮ルールの現在の設定を表示するには、次の例に示すようにget-compression-rule-propコマンドを実行します。

tadm> get-compression-rule-prop --config=soa --vs=soa --rule=compress-docs
fragment-size=8192
condition="$uri = '^/doc'"
compression-level=6
rule=compress-docs
insert-vary-header=true

- 圧縮ルールを変更するには、set-compression-rule-propコマンドを実行します。
たとえば、次のコマンドでは、ルールcompress-docsの圧縮レベルがレベル6に変更されます。

tadm> set-compression-rule-prop --config=soa --vs=soa.example.com --rule=compress-docs compression-level=9
OTD-70201 Command 'set-compression-rule-prop' ran successfully.

- 圧縮ルールを削除するには、次の例に示すように、delete-compression-ruleコマンドを実行します。

tadm> delete-compression-rule --config=soa --vs=soa.example.com compress-docs
OTD-70201 Command 'delete-compression-rule' ran successfully.

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

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仮想サーバーとオリジン・サーバー・プール間の接続のリバース・プロキシ設定は、ルートで定義されます。リバース・プロキシ設定を変更するには、管理コンソールまたはCLIのいずれかを使用して、ルートを編集する必要があります。

注意:
現行のリリースでは、管理コンソールまたはCLIのいずれかを使用して、プロキシのバッファ・サイズを構成できません。
ルートのプロキシ・バッファ・サイズを構成するには、次の操作を行います。

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. pull-configコマンドを実行して、管理サーバー上の構成ストアを更新し、構成のすべてのインスタンスでこの変更を有効にします。

tadm> pull-config --config=config_name node

nodeは、プロキシ・バッファ・サイズを構成したノードの名前です。

http-client-configサーバー・アプリケーション・ファンクション(SAF)の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』を参照してください。

管理コンソールを使用したルートの編集

管理コンソールを使用してルートを編集するには、次の操作を行います。

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. ルートを編集する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を展開し、ルートを編集する仮想サーバーの名前を展開して、「ルート」を選択します。
「ルート」ページが表示されます。仮想サーバーに現在定義されているルートがリストされます。

5. 編集するルートの「名前」をクリックします。
ルート設定ページが表示されます。

6. ルート設定ページの次のフィールドにリバース・プロキシ・パラメータを指定します。

ルート設定ページのセクション

フィールド

一般設定

キープ・アライブ
キープ・アライブのタイムアウト

詳細設定: オリジン・サーバーとの接続用のクライアント構成

常にキープ・アライブを使用
アイドル・タイムアウト

画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

7. 必要な変更を行った後、「保存」をクリックします。

- 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

- さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したルートの構成

ルートのプロパティを変更するには、set-route-propコマンドを実行します。次は、前述したリバース・プロキシ・パラメータの名前です。

keep-alive-timeout
always-use-keep-alive
use-keep-alive
timeout

たとえば、次のコマンドでは、構成soaの仮想サーバーsoa.example.com内のルートroute1のキープ・アライブ・タイムアウト期間が30秒に変更されます。

tadm> set-route-prop --config=soa --vs=soa.example.com --rule=route1 keep-alive-timeout=30

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイする必要があります。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

15.10 Solaris固有のチューニング

この項では、Solaris固有のチューニングについて説明します。これらのプラットフォーム固有のチューニングのヒントおよび実行するすべての変更は、システム上の他のプロセスに影響を与える可能性があることに注意してください。

15.10.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.10.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.10.3 TCPバッファリングのチューニング

TCPバッファリングは、send_bufパラメータおよびrecv_bufパラメータを使用してチューニングできます。これらのパラメータの詳細は、表15-1「パフォーマンス・ベンチマークのためのSolarisのチューニング」を参照してください。

15.10.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.10.5 ビジー状態のボリュームまたはディスクにおける長いサービス時間

Oracle Traffic Directorインスタンスのレスポンス時間は、ディスク・サブシステムのパフォーマンスに大きく影響されます。iostatユーティリティを使用して、ディスクのビジー状態やI/Oリクエストの完了の速さ(それぞれ%bおよびsvc_t columns)を監視できます。サービス時間は、ビジー状態が30%未満のディスクでは重要ではありません。ただし、よりビジーなディスクの場合は、サービス時間が20ミリ秒を超えないようにする必要があります。ビジーなディスクでサービスが遅い場合は、ディスク・パフォーマンスを向上させると、パフォーマンスがかなり改善する可能性があります。ビジーなディスクと負荷が少ないディスクが混在する場合は、ビジーなディスクから負荷が少ないディスクにファイルをいくつか移動して、負荷を分散します。

15.10.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.10.7 長期のシステム監視

前述のツールでシステム・パフォーマンスを監視することは重要ですが、その一方で、より長期のパフォーマンス履歴を収集することも、傾向の把握に役立つため、同様に重要です。たとえば、システムのベースライン・レコードは、システムの動作が悪くなり始めた場合に、何が変わったかのかを解明するのに役立ちます。次の手順を実行して、システム・アクティビティ・レポート・パッケージを有効化します。

- 次のコマンドを実行します。

svcadm enable system/sar

- crontab -e sysコマンドを実行して、sa1コマンドおよびsa2コマンドを含む行からコメント文字#を削除します。サイトのアクティビティ・プロファイルに応じて、コマンドを実行する頻度および時間を調整できます。このファイルの形式の説明は、crontab manのページを参照してください。
このコマンドを使用すると、システムにより/var/adm/saディレクトリのファイルにパフォーマンス・データが保存され、デフォルトで1か月保持されます。次に、sarコマンドを使用して、目的の期間の統計を調査します。

15.10.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.oracle.com/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. サーバー・ログの冗長度を高め、問題の再現を試みます。
表12-1「サーバー・ログ・レベル」にあるように、Oracle Traffic Directorではサーバー・ログについて、いくつかのログ・レベルがサポートされています。デフォルトのログ・レベルは、NOTIFICATION:1です。最小の冗長度ログ・レベルは、INCIDENT_ERRORで、このレベルでは、重大なエラー・メッセージのみが記録されます。TRACE:1、TRACE:16またはTRACE:32レベルでは、ログはレベルに応じて冗長度が増しますが、より詳細な情報が提供され、問題の診断に活用できます。

ログの冗長度を高め、問題の再現を試みます。問題が再度発生したら、問題の原因を示すメッセージ・ログを確認します。

サーバー・ログ・レベルの変更の詳細は、12.3項「ログ・プリファレンスの構成」を参照してください。

3. 前の構成のインスタンスをリストアします。
変更された構成をそのインスタンスに再デプロイする場合、前の構成のバックアップが、管理サーバーのzipファイルに格納されます。

4.9項「バックアップからの構成のリストア」の説明に従い、該当する前の構成にインスタンスをリストアし、問題が継続しているかどうかを確認します。

問題が前の構成で発生しない場合、現在の構成で行われた変更が問題の原因であることが明らかになります。

5. 16.4項「Oracleサポートへの連絡」の説明に従い、Oracleサポートに連絡します。

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

この項では、Oracle Traffic Directorの高可用性構成に関する問題を診断および解決するためのタスクについて説明します。

- EoIB (Ethernet over InfiniBand)のインタフェースを使用していることを確認します。

- 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はExalogicソフトウェア・リポジトリ内にあります。KeepAlivedの詳細は、14.2.1項「フェイルオーバーの動作」を参照してください。

- KeepAlived特有の情報は、/var/log/messagesディレクトリ内にあるログで確認できます。

- 高可用性構成を正常に完了するには、正しいVIPアドレスと適切なサブネット・マスク(ネットマスク)のビットサイズを指定する必要があります。また、実際のネットマスク値ではなく、ネットマスクのビット数を指定する必要があります。詳細は、14.2.3項「フェイルオーバー・グループの作成」を参照してください。

- Oracle Traffic Director 11.1.1.6.0では、管理ノードの同一ペア上で複数のOracle Traffic Director構成を使用した高可用性はサポートされません。

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

この項では、次の問題の解決策を示します。

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

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

- 16.2.3項「PKCS#11トークンPINの変更後SSL/TLSが有効なサーバーを再起動できない」

- 16.2.4項「SNMPサブエージェントを起動できない」

- 16.2.5項「管理サーバーと通信できない: 接続拒否」

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

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

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

- 16.2.9項「管理サーバーを再起動できない」

- 16.2.10項「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リスナー・ポートが他のプロセスで使用中の場合は、ポートを解放するか、10.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 PKCS#11トークンPINの変更後SSL/TLSが有効なサーバーを再起動できない

このエラーは、SSLが有効な構成について、PKCS#11トークンPINを設定または変更し、インスタンスの実行中に更新済の構成をデプロイすると発生します。

次のメッセージがサーバー・ログに書き込まれます。

[ERROR:32] [OTD-10094] NSS PKCS #11 initialization failed
(SEC_ERROR_BAD_PASSWORD: Security password entered is incorrect.)
[ERROR:32] [OTD-10492] New configuration not installed
[ERROR:32] [OTD-10520] The new configuration is incompatible with the existing
configuration (Enabling PKCS #11 or SSL requires a server restart)

この問題を解決するには、start-instance CLIコマンドを使用するか、管理コンソールで「インスタンスの起動/再起動」ボタンをクリックしてインスタンスを起動します。表示されるプロンプトで、PINで保護されている各トークンのPINを入力します。

このエラーを回避するには、SSLが有効な構成に対してPKCS#11トークンPINを設定または変更した後、まず、実行中のインスタンスを停止し、変更内容をデプロイして、次にインスタンスを起動します。

16.2.4 SNMPサブエージェントを起動できない

このエラーは、構成済SNMPサブエージェント・ポートが別のプロセスによって使用中である場合に通常発生します。

次のメッセージが管理サーバー・ログに書き込まれます。

OTD-63410 The SNMP subagent failed to start.

次のコマンドを使用して、ノード上のSNMPサブエージェントの構成済ポートが別のプロセスによってすでに使用されていないかを確認します。

> netstat -npl --udp | grep :port

この問題を解決するには、13.6.2項「SNMPサブエージェントの構成」の説明に従い、INSTANCE_HOME/admin-server/config/snmpagt.confファイルでポートを解放するか変更します。

16.2.5 管理サーバーと通信できない: 接続拒否

このエラーは、次の状況でtadmコマンドを実行すると発生します。

- --portオプションに指定された値が正しくありません。

- --portオプションが指定されておらず、管理サーバーが、デフォルトのSSLポート8989以外のポートで実行されています。

--portオプションに正しい値を指定してコマンドを再度実行します。

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

Oracle Traffic Directorインスタンスの起動時、特定のパラメータの値(キープ・アライブ接続の最大数、接続キューのサイズ、オリジン・サーバーへの最大接続数)が、システムのファイル・ディスクリプタ制限に基づき自動的に割り当てられます。

ファイル・ディスクリプタ制限が非常に高い場合、未定義パラメータに自動割り当てされる値は、必要以上に高くなり、その結果、Oracle Traffic Directorで過度なメモリー量が消費されます。この問題を回避するには、キープ・アライブ接続の最大数(15.2.3.3項)、接続キューのサイズ(15.2.1.4項)および個々のオリジン・サーバーへの最大接続数(7.3項)を明示的に構成します。

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

このLinuxのオペレーティング・システム・エラーは、割り当てられたファイル・ディスクリプタ数がシステムの制限に到達すると発生します。

次のメッセージがサーバー・ログに書き込まれます。

[ERROR:16] [OTD-10546] Insufficient file descriptors for optimum configuration.

このエラーを回避するには、Linuxのファイル・ディスクリプタ制限をデフォルトの1024から合理的な数に増やします。詳細は、15.3項「ファイル・ディスクリプタ制限のチューニング」を参照してください。

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

このエラーは、構成の一時ディレクトリを変更した後、インスタンスを停止せずに変更デプロイし、その後インスタンスを停止しようとすると発生します。一時ディレクトリは、構成のインスタンスのプロセスIDおよびソケット情報が格納される(管理ノード上)のディレクトリです。

このエラーが発生すると、次のメッセージがサーバー・ログに書き込まれます。

OTD-63585 An error occurred while stopping the server. For details, see the server log.

このエラーを回避する手順

構成の一時ディレクトリを変更した場合、構成のすべてのインスタンスをまず停止して、変更をデプロイし、次にインスタンスを起動します。

この問題を回避する手順

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

1. 次のいずれかを実行して、構成の現在の一時ディレクトリを検出します。

- 次の例に従い、get-config-prop CLIコマンドを実行します。

tadm> get-config-prop --config=soa temp-path
/tmp/net-test-a46e5844

- 管理コンソールにログインし、必要な構成を選択し、「詳細設定」を選択します。結果のページで、「一時ディレクトリ」フィールドを探します。

一時ディレクトリへのパスを記録します。

2. 次のコマンドを実行して、実行中のインスタンスのプロセスIDを検出します。

cat temp_dir/pid

temp_dirは、手順1で記録した一時ディレクトリへのフル・パスです。

このコマンドによって戻されるプロセスIDを記録します。

3. 次のコマンドを実行して、プロセスを停止します。

kill pid

pidは、手順2で記録したプロセスIDです。

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

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.10 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項「構成とは何ですか。」

- 16.3.3項「管理コンソールにはどのようにアクセスするのですか。」

- 16.3.4項「初めて管理コンソールにアクセスするときに証明書の警告が表示されるのはなぜですか。」

- 16.3.5項「構成ファイルを手動で編集できますか。」

- 16.3.6項「管理コンソールにおいて、構成の保存と構成のデプロイにはどのような違いがありますか。」

- 16.3.7項「管理コンソールに「デプロイメント保留中」のメッセージが表示されるのはなぜですか。」

- 16.3.8項「管理コンソールにインスタンス構成デプロイ済のメッセージが表示されるのはなぜですか。」

- 16.3.9項「管理コンソール・セッションが突然終了するのはなぜですか。」

- 16.3.10項「CLIにはどのようにアクセスするのですか。」

- 16.3.11項「tadm --user=admin --host=myhostサブコマンドでは、なぜ指定したサブコマンドが実行されず、コマンド・シェルが起動されるのですか。」

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

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

- 16.3.14項「CLIへのアクセス時、パスワード入力のプロンプトが毎回表示されないようにCLIを構成することはできますか。」

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

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

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

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

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

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

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

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

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

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

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

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

- 第16.3.27項「サポートされているJDKの最小バージョンおよびJAVA_HOME変数は何ですか。」

16.3.1 管理サーバー・ユーザーのパスワードはどのようにリセットするのですか。

「CLIを使用した管理者のユーザー名およびパスワードの変更」の説明に従い、reset-admin-password CLIコマンドを実行します。

16.3.2 構成とは何ですか。

Oracle Traffic Director用語としての構成は、Oracle Traffic Directorインスタンスの実行時の動作を決定する一連の構成可能な要素(メタデータ)を指します。

詳細は、1.4項「Oracle Traffic Director用語集」を参照してください。

16.3.3 管理コンソールにはどのようにアクセスするのですか。

2.3.2項「管理コンソールへのアクセス」を参照してください。

16.3.4 初めて管理コンソールにアクセスするときに証明書の警告が表示されるのはなぜですか。

管理サーバーに自己署名証明書があるため、ブラウザによって警告が表示されます。続行するには、証明書を信頼することを選択する必要があります。

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

構成ストア内のファイルは、管理コンソールまたはCLIのいずれかを使用して構成を編集すると、自動的に更新されます。Oracle Traffic Directorドキュメントに指示されている場合を除き、構成ストア内のファイルを手動で編集しないでください。

構成の変更を有効にするには、4.3項「構成のデプロイ」の説明に従い、構成をインスタンスにデプロイする必要があります。

インスタンスの構成ファイルを誤って編集した場合、および変更を保持し、構成のすべてのインスタンスにレプリケートする場合、4.5項「管理サーバーとノード間の構成の同期化」の説明に従い、構成をインスタンスから管理サーバーにプルできます。

16.3.6 管理コンソールにおいて、構成の保存と構成のデプロイにはどのような違いがありますか。

構成を保存すると、行った変更が管理サーバーの構成ストア内に保存されます。構成のインスタンスに変更を反映するには、4.3項「構成のデプロイ」の説明に従い、構成をデプロイする必要があります。

16.3.7 管理コンソールに「デプロイメント保留中」のメッセージが表示されるのはなぜですか。

「デプロイメント保留中」のメッセージは、構成を変更して、管理サーバーに保存する際に、管理コンソールに表示されます。これは、変更が、構成のインスタンスにはまだコピーされていないことを示します。

必要な構成変更を終えたら、4.3項「構成のデプロイ」の説明に従い、管理コンソールで「変更のデプロイ」をクリックするか、deploy-config CLIコマンドを実行することで、変更をすべてのインスタンスにデプロイできます。

16.3.8 管理コンソールにインスタンス構成デプロイ済のメッセージが表示されるのはなぜですか。

インスタンスの構成ファイルを手動で編集すると、インスタンス構成デプロイ済のメッセージが管理コンソールに表示されます。これは、1つ以上のインスタンスの構成ファイルが、管理サーバーの構成ストア内に格納されている、対応する構成ファイルと異なっていることを示します。この場合に実行する必要のある操作の詳細は、4.5項「管理サーバーとノード間の構成の同期化」を参照してください。

16.3.9 管理コンソール・セッションが突然終了するのはなぜですか。

管理コンソール・セッションが30分間非アクティブな状態が続いた場合、自動的に終了します。再度ログインする必要があります。

16.3.10 CLIにはどのようにアクセスするのですか。

2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。

16.3.11 tadm --user=admin --host=myhostサブコマンドでは、なぜ指定したサブコマンドが実行されず、コマンド・シェルが起動されるのですか。

指定したCLIサブコマンドが実行されるようにするには、--user、--hostなどの共通オプションを含むすべてのオプションの前にサブコマンドを指定する必要があります。そうしない場合、CLIでは、シェル・モードを起動しようとしていると見なされます。

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

CLIは、管理サーバーのSSLポートに接続されます。管理サーバーには、自己署名証明書があります管理サーバーに最初に接続するときに表示されるメッセージは、証明書を信頼するかどうかを選択するためのプロンプトです。正しいサーバーおよびポートに接続されていることを確認し、yを入力して証明書を信頼します。その後のCLIの起動では、警告メッセージは表示されません。

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

--helpオプションを使用してコマンドを実行し、コマンドのヘルプを参照してください。

16.3.14 CLIへのアクセス時、毎回パスワード入力のプロンプトが表示されないようにCLIを構成することはできますか。

はい。tadm_password=passwordの形式でファイルにパスワードを格納します。CLIコマンドを実行する際、--password-fileを使用して、パスワード・ファイルへのフル・パスを指定します。

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

動的検出が有効な場合、Oracle Traffic Directorは、指定された間隔で、特定のヘッダーを含むHTTPリクエストを送信する必要があり、このヘッダーにより、プール内の指定されたオリジン・サーバーがOracle WebLogic Serverインスタンスであるかどうか、およびサーバーがクラスタに属しているかどうかが判別されます。TCPヘルス・チェック・リクエストに対するレスポンスでは、Oracle WebLogic Serverインスタンスの存在を特定するための十分な情報が提供されません。したがって、動的検出が有効な場合、ヘルス・チェック・プロトコルはHTTPに設定されている必要があります。

16.3.16 プール内のオリジン・サーバーを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. 必要なオリジン・サーバーで新しいオリジン・サーバー・プールを作成し、古いプールを削除します。詳細は、第6章「オリジン・サーバー・プールの管理」を参照してください。

2. 8.4項「ルートの構成」の説明に従い、新しいプールをポイントするように適切なルートを更新します。

3. 5.4項「再起動が不要なOracle Traffic Directorインスタンスの更新」の説明に従い、reconfig-instance CLIコマンドを使用して、Oracle Traffic Directorを再構成します。

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

管理コンソールまたはCLIのいずれかを使用して、適切なルートを変更し、サーバー・ログへのリクエストおよびレスポンス・ヘッダーの記録を有効化できます。

- 管理コンソールの使用

1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

2. ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。

3. ルートを構成する構成を選択します。

4. ナビゲーション・ペインで、「仮想サーバー」を展開し、ルートを構成する仮想サーバーの名前を展開して、「ルート」を選択します。
「ルート」ページが表示されます。選択された仮想サーバーに現在定義されているルートがリストされます。

5. 構成するルートの「名前」をクリックします。
ルート設定ページが表示されます。

6. ルート設定ページの「詳細設定」セクションに移動し、「オリジン・サーバーとの接続用のクライアント構成」サブセクションにスクロール・ダウンします。

7. 「ログ・ヘッダー」チェック・ボックスを選択します。

8. 「保存」をクリックします。

9. 「変更のデプロイ」をクリックします。

- CLIの使用
次の例に従い、set-route-propコマンドを実行します。

tadm> set-route-prop --config=soa --vs=soa.example.com --route=default-route log-headers=true

このコマンドにより、構成soaの仮想サーバーsoa.example.com内のdefault-routeという名前のルートと関連付けられているオリジン・サーバーとの間でOracle Traffic Directorが送受信するヘッダーのロギングが有効化されます。

更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイします。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

次の例に示すように、ヘッダーはサーバー・ログに記録されます。

[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/11.1.1.7
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.18 Oracle Traffic DirectorインスタンスのSSL/TLSの有効化はどのように行いますか。

11.2項「Oracle Traffic Directorとクライアント間のSSL/TLSの構成」を参照してください。

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

11.2.4項「リスナーのSSL/TLS暗号の構成」を参照してください。

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

11.4.4項「証明書のリストの表示」を参照してください。

16.3.21 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.22 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.23 Oracle Traffic DirectorインスタンスとOracle WebLogic Serverオリジン・サーバー間のSSL/TLS通信の詳細の表示はどのように行いますか。

サーバーの起動スクリプトに-Dssl.debug=trueシステム・プロパティを追加することで、Oracle WebLogic ServerインスタンスのSSLデバッグを構成します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLのデバッグに関する項を参照してください。

12.3項「ログ・プリファレンスの構成」の説明に従い、ログ・レベルをTRACE:32に設定し、Oracle Traffic Directorサーバー・ログの冗長度を高めてください。

16.3.24 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.)

この問題を解決するには、次の例に従い、set-route-prop CLIコマンドを実行して、必要な仮想サーバー・ルートのオリジン・サーバー証明書の検証を無効化します。

tadm> set-route-prop --config=soa  --vs=vs1 --route=route1 validate-server-cert=false

更新されたルートを有効にするには、次の例に従い、deploy-configコマンドを実行して構成をデプロイします。

tadm> deploy-config soa

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

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

Oracle Traffic DirectorはデフォルトでソースIPアドレスを書き換えます。それでも、クライアントIPアドレスはProxy-client-ipという追加のリクエスト・ヘッダーで送信されます。8.4項で説明するとおり適切なルートを構成することで、Proxy-client-ipやその他のリクエスト・ヘッダーをブロックしたり転送したりするようOracle Traffic Directorを設定できます。

HTTPリクエスト・ヘッダーをオリジン・サーバーに転送する際、Oracle Traffic Directorは大文字小文字の区別を維持できません。

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

HTTPリクエストが定義済ルートに指定されている条件に一致せず、構成にデフォルト(=unconditional)のルートが含まれていない場合、Oracle Traffic Directorから405ステータス・コードが返されます。このエラーはOracle Traffic Directorがリクエストの適切なルートを見つけられなかったことを意味しています。この状況は、obj.conf構成ファイル内でデフォルト・ルート(リクエストが他のどのルートの指定条件にも一致しなかった場合に使用されるルート)が手動で削除された場合にのみ発生する可能性があります。この問題を解決するには、管理者が適切なルートを作成する必要があります。

注意:
デフォルト(=unconditional)のルートは管理コンソールやCLIで削除することはできません。また、手動で削除しないようにしてください。

16.3.27 サポートするJDKの最小バージョンおよびJAVA_HOME変数は何ですか。

Oracle Traffic Directorリリース11.1.1.9は、サポートするJDKの最小バージョンとしてJDK 7 u60を必要とします。Oracle Traffic Director 11.1.1.6は、それ自体の管理のためにJDKをバンドルしました。Oracle Traffic Director 11.1.1.9はJDK 7をバンドルしています。

次の手順で、JDKインストールのステータスを確認します。

- Oracle Traffic Director 11.1.1.6/7のインストール時に、自分でインストールしたJDKを使用しなかった場合には、Oracle Traffic Director 11.1.1.9にアップグレードする際にJDKのバージョンを考慮する必要はありません。

- Oracle Traffic Director 11.1.1.6/.7のインストール時に、自分でインストールしたJDKを使用した場合には、Oracle Traffic Director 11.1.1.9にアップグレードする際にJDKのバージョンとしてJDKバージョン7アップデート60またはそれ以上を準備する必要があります。

JAVA_HOME変数を適切に設定することも必要です。使用中の環境でJAVA_HOMEをJDK 6に設定していて、Oracle Traffic Director CLIコマンドを実行すると、次のエラーが表示される可能性があります。

$ORACLE_HOME/bin/tadm configure-server --user=user1 --instance-home=$INSTANCE_HOME/instance1  --server-user=root

Exception in thread "main" java.lang.UnsupportedClassVersionError: com/sun/web/admin/cli/shelladapter/WSadminShell : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class: com.sun.web.admin.cli.shelladapter.WSadminShell.  Program will exit.

回避策: 使用中の環境でJAVA_HOMEを削除します。

16.4 Oracleサポートへの連絡

オラクル社とサービス契約を結んでいる場合、Oracle Traffic Directorの問題について、Oracleサポート(http://support.oracle.com)に問合せできます。

Oracleサポートに連絡する前に

Oracleサポートに連絡する前に、次のことを行ってください。

- このドキュメント(Oracle Traffic Director管理者ガイド)に記載されている適切な診断およびトラブルシューティングのガイドラインをすべて試してください。

- 発生している問題、または類似する問題が、OTNのディスカッション・フォーラム(http://forums.oracle.com/)ですでに話し合われていないかどうか確認してください。
フォーラムで入手できる情報が問題解決には不十分な場合、フォーラムに質問を投稿してください。フォーラムの他のOracle Traffic Directorユーザーが質問に答えてくれる場合があります。

- 可能な限り、問題が発生する前に実行した一連の操作を記述してください。

- 可能な場合、システムの元の状態をリストアし、記述した手順を使用して問題の再現を試みてください。これは、問題が再現可能なものか、一時的なものなのかの特定に役立ちます。

- 問題を再現できる場合、問題を再現する手順を絞り込んでください。小さなテスト・ケースで再現できる問題の方が、大きいテスト・ケースで再現する場合と比較して、一般的に診断が容易になります。
問題の再現手順を絞り込むと、Oracleサポートは潜在的な問題に対する解決方法をより速く提供できます。

Oracleサポートに提供する必要がある情報

Oracleサポートに連絡する際は、次の情報をお知らせください。

- Oracle Traffic Directorのリリース番号。
リリース番号を確認するには、次のコマンドを実行します。

> $ORACLE_HOME/bin/tadm --version
Oracle Traffic Director 11.1.1.7.0 Administration Command Line B01/14/2013 09:08

- 問題が発生する直前に実行した操作など、問題についての簡単な説明。

- 管理インタフェースを使用したサポートが必要な場合、ヘルプを必要とするコマンドライン・サブコマンドの名前、または管理コンソール画面のタイトル。

- エラーが発生した構成の構成ファイルが含まれる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が統計を追跡および維持するために使用するメトリックをリストします。

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

- プロセス・メトリック

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

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

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

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

- CPUメトリック

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

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

- プロキシ・キャッシュ・メトリック

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

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

この項では、各インスタンスについてOracle Traffic Directorが追跡するメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。SNMPまたはstats-xmlレポートで提供されないメトリックは、NAとマークされます。

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

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

インスタンスが実行されている秒数

instanceUptime

server: secondsRunning

処理されたリクエストの数

instanceRequests

request-bucket: countRequests

受信したオクテットの数

instanceInOctets

request-bucket: countBytesReceived

送信したオクテットの数

instanceOutOctets

request-bucket: countBytesTransmitted

発行された2xx (成功)レスポンスの数

instanceCount2xx

request-bucket: count2xx

発行された3xx (リダイレクト)レスポンスの数

instanceCount3xx

request-bucket: count3xx

発行された4xx (クライアント・エラー)レスポンスの数

instanceCount4xx

request-bucket: count4xx

発行された5xx (サーバー・エラー)レスポンスの数

instanceCount5xx

request-bucket: count5xx

発行されたその他(2xx、3xx、4xx、5xx以外)のレスポンスの数

instanceCountOther

request-bucket: countOther

発行された200 (OK)レスポンスの数

instanceCount200

request-bucket: count200

発行された302 (一時的に移動)レスポンスの数

instanceCount302

request-bucket: count302

発行された304 (変更なし)レスポンスの数

instanceCount304

request-bucket: count304

発行された400 (不正なリクエスト)レスポンスの数

instanceCount400

request-bucket: count400

発行された401 (認可されていない)レスポンスの数

instanceCount401

request-bucket: count401

発行された403 (禁止)レスポンスの数

instanceCount403

request-bucket: count403

発行された404 (未検出)レスポンスの数

instanceCount404

request-bucket: count404

発行された503 (使用不可)レスポンスの数

instanceCount503

request-bucket: count503

過去1分間の平均ロード

instanceLoad1MinuteAverage

server: load1MinuteAverage

過去5分間の平均ロード

instanceLoad5MinuteAverage

server: load5MinuteAverage

過去 分間の平均ロード

instanceLoad15MinuteAverage

server: load15MinuteAverage

ネットワーク上で送信した1秒当たりのオクテット数

instanceNetworkInOctets

server: rateBytesReceived

ネットワーク上で受信した1秒当たりのオクテット数

instanceNetworkOutOctets

server: rateBytesTransmitted

過去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

統計収集時のオープン接続数

instanceCountOpenConnections

request-bucket: countOpenConnections

この要素内に統計を格納するTCPプロキシの名前

tcpID

tcp-proxy:name

統計を収集するときのTCPプロキシの状態

tcpMode

tcp-proxy:mode

このTCPプロキシがリクエストをリスニングするIPアドレス(ポートを含む)

tcpInterfaces

tcp-proxy:interfaces

アクティブなTCPプロキシ接続の数

tcpCountActiveConnections

tcp-request-bucket:countActiveConnections

処理されたリクエストの合計数

tcpCountRequests

tcp-request-bucket:countRequests

中断されたリクエストの合計数

tcpCountAbortedRequests

tcp-request-bucket:countRequestsAborted

タイムアウトによりクローズされたリクエストの合計数

tcpCountTimeoutRequests

tcp-request-bucket:countRequestsTimedout

クライアントから受信したバイト数

tcpCountBytesReceived

tcp-request-bucket:countBytesReceived

クライアントに送信されたバイト数

tcpCountBytesTransmitted

tcp-request-bucket:countBytesTransmitted

アクティブ時間の平均時間(ミリ秒)

tcpMilliSecondsConnectionActiveAverage

tcp-request-bucket:millisecondsConnectionActiveAverage

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

この項では、プロセス・レベルでOracle Traffic Directorが追跡するメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。SNMPまたはstats-xmlレポートで提供されないメトリックは、NAとマークされます。

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

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

現在使用可能なリクエスト処理スレッドの数

processThreadCount

thread-pool-bucket: countThreads

現在アイドル状態のリクエスト処理スレッドの数

processThreadIdle

thread-pool-bucket: countIdleThreads

キープ・アライブ・キューに現在入っている接続数

processKeepaliveCount

keepalive-bucket: countConnections

キープ・アライブ・キューに許可されている最大接続数

processKeepaliveMax

keepalive-bucket: maxConnections

キープ・アライブ・サブシステム内の接続で処理されたリクエスト数

NA

keepalive-bucket: countHits

キープ・アライブ・サブシステム内のフラッシュされた接続数

NA

keepalive-bucket: countFlushes

サーバーがキープ・アライブ・スレッドに接続をハンドオフできなかった回数

NA

keepalive-bucket: countRefusals

キープ・アライブ・サブシステムが指定された期間を超えてアイドル状態だったためクローズされた接続数

NA

keepalive-bucket: countTimeouts

キープ・アライブ・サブシステムがタイムアウトとなるアイドル期間

NA

keepalive-bucket: secondsTimeout

プロセス・サイズ(KB)

processSizeVirtual

process: sizeVirtual

プロセス常駐サイズ(KB)

processSizeResident

process: sizeResident

システム・メモリー内のプロセス・メモリー部分

processFractionSystemMemoryUsage

process: fractionSystemMemoryUsage

リクエストを処理しているアクティブ接続の合計数

NA

tcp-thread:countActiveConnections

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

この項では、サーバー・スレッドについてOracle Traffic Directorが追跡するメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

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

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

このスレッド・プールで処理するためにキューに入っているリクエスト数

threadPoolCount

thread-pool-bucket: countQueued

キューに同時に存在できる最大リクエスト数

threadPoolPeak

thread-pool-bucket: peakQueued

キューに許可されている最大リクエスト数

threadPoolMax

thread-pool-bucket: max-threads

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

この項では、Oracle Traffic Directorが追跡する接続キュー・メトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。SNMPまたはstats-xmlレポートで提供されないメトリックは、NAとマークされます。

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

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

接続キューに現在入っている接続数

connectionQueueCount

connection-queue-bucket: countQueued

起動後この接続キューに追加されている接続合計数

connectionQueueTotalQueued

connection-queue-bucket: countTotalQueued

このキューの接続にかかるチック数合計

connectionQueueTimeQueued

connection-queue-bucket: ticksTotalQueued

過去1分間のキューの平均長

NA

connection-queue-bucket: countQueued1MinuteAverage

過去1分間のキューの平均長

NA

connection-queue-bucket: countQueued5MinuteAverage

過去15分間のキューの平均長

NA

connection-queue-bucket: countQueued15MinuteAverage

キューに同時に存在できる最大接続数

connectionQueuePeak

connection-queue-bucket: peakQueued

接続キューに許可されている最大接続数

connectionQueueMax

connection-queue-bucket: maxQueued

インスタンスの起動後この接続キューに追加された接続合計数

connectionQueueTotalConnections

connection-queue-bucket: countTotalConnections

接続キューのオーバーフローのため拒否された接続数

connectionQueueOverflows

connection-queue-bucket: countOverflows

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

この項では、Oracle Traffic Directorが圧縮および解凍するレスポンス・データのメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

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

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

圧縮されたリクエスト合計数

countRequestsCompressed

compression-bucket: countRequests

圧縮対象の入力バイトの合計数

countBytesForCompression

compression-bucket: bytesInput

圧縮後の出力バイトの合計数

countBytesCompressed

compression-bucket: bytesOutput

ページ当たりの平均圧縮

pageCompressionAverage

compression-bucket: pageCompressionAverage

全体の圧縮率

compressionRatio

compression-bucket: compressionRatio

解凍されたリクエスト合計数

countRequestsDecompressed

decompression-bucket: countRequests

解凍対象の入力バイトの合計数

countBytesForDecompression

decompression-bucket: bytesInput

解凍後の出力バイトの合計数

countBytesDecompressed

decompression-bucket: bytesOutput

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

この項では、各仮想サーバーについてOracle Traffic Directorが追跡するメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

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

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

処理されたリクエストの数

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-bucket:countUpgradeRequests

オリジン・サーバーでアップグレードが拒否されたWebSocketリクエストの数

websocketCountUpgradeRejectedRequests

websocket-bucket:countUpgradeRequestsRejected

サーバーでアップグレードが拒否されたWebSocketリクエストの数

websocketCountFailedStrictRequests

websocket-bucket:countUpgradeRequestsFailed

アクティブなWebSocket接続の数

websocketCountActiveConnections

websocket-bucket:countActiveConnections

中断されたリクエストの合計数

websocketCountAbortedRequests

websocket-bucket:countRequestsAborted

タイムアウトによりクローズされたリクエストの合計数

websocketCountTimeoutRequests

websocket-bucket:countRequestsTimedout

クライアントから受信したバイト数

websocketCountBytesReceived

websocket-bucket:countBytesReceived

クライアントに送信されたバイト数

websocketCountBytesTransmitted

websocket-bucket:countBytesTransmitted

アクティブ時間の平均時間(ミリ秒)

websocketMillisecondsConnectionActiveAverage

websocket-bucket:millisecondsConnectionActiveAverage

webappファイアウォールによって遮断されたリクエストの合計数

wafCountInterceptedRequests

webapp-firewall-bucket:countRequestsIntercepted

webappファイアウォールによって許可されたリクエストの合計数(allowアクション)

wafCountAllowedRequests

webapp-firewall-bucket:countRequestsAllowed

拒否されたリクエストの合計数(denyアクション)

wafCountDeniedRequests

webapp-firewall-bucket:countRequestsDenied

ドロップされたリクエストの合計数(dropアクション)

wafCountDroppedRequests

webapp-firewall-bucket:countRequestsDropped

リダイレクトされたリクエストの合計数(redirectアクション)

wafCountRedirectedRequests

webapp-firewall-bucket:countRequestsRedirected

拒否されたリクエストの合計検出数(denyアクション)

wafCountDenyDetectedRequests

webapp-firewall-bucket:countRequestsDenyDetected

ドロップされたリクエストの合計検出数(dropアクション)

wafCountDropDetectedRequests

webapp-firewall-bucket:countRequestsDropDetected

リダイレクトされたリクエストの合計検出数(redirectアクション)

wafCountRedirectDetectedRequests

webapp-firewall-bucket:countRequestsRedirectDetected

A.7 CPUメトリック

この項では、Oracle Traffic Directorが追跡するCPU関連のメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

表A-7 CPUメトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

CPUがアイドル状態の時間の割合

cpuIdleTime

cpu-info: percentIdle

CPUがユーザー空間で費やした時間の割合

cpuUserTime

cpu-info: percentUser

CPUがカーネル空間で費やした時間の割合

cpuKernelTime

cpu-info: percentKernel

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

この項では、オリジン・サーバー・プールおよびオリジン・サーバーについてOracle Traffic Directorが追跡するメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

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

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

リクエストが再試行された回数(同じまたは異なるオリジン・サーバーに対して)

serverPoolCountRetries

server-pool: countRetries

サーバー・プールのタイプ

server-pool:type

origin-serverのタイプ。Weblogicサーバー、一般的なHTTPサーバーまたは検出不可

origin-server-bucket: type

ノードが動的に検出されたかどうかを示すフラグ

originServerDiscoveryStatus

origin-server-bucket: flagDiscovered

ノードが完全にランプアップされているかどうかを示すフラグ

originServerRampedupStatus

origin-server-bucket: flagRampedUp

オリジン・サーバーがバックアップ・ノードであるかどうかを示すフラグ

originServerBackupStatus

origin-server-bucket: flagBackup

オリジン・サーバーが現在オンラインとマークされているかどうかを示すステータス

originServerRunningStatus

origin-server-bucket: ステータス

オリジン・サーバーがオンラインとマークされてからの合計時間(秒)

originServerRunningTime

origin-server-bucket: secondsOnline

オリジン・サーバーがオフラインとマークされてからの合計時間(秒)

originServerCountOffline

origin-server-bucket: countDetectedOffline

オリジン・サーバーに送信された合計バイト数

originServerCountBytesTransmitted

origin-server-bucket: countBytesTransmitted

オリジン・サーバーから受信した合計バイト数

originServerCountBytesReceived

origin-server-bucket: countBytesReceived

リクエストを処理中のオリジン・サーバーへのオープン接続合計数

originServerCountActiveConnections

origin-server-bucket: countActiveConnections

オリジン・サーバーへのアイドル状態の接続合計数

originServerCountIdleConnections

origin-server-bucket: countIdleConnections

時間統計の収集時に固定性リクエストに属していたアクティブ接続の合計数

originServerCountActiveStickyConnections

origin-server-bucket:countActiveStickyConnections

オリジン・サーバーへの接続が試行された合計回数

originServerCountConnectAttempts

origin-server-bucket: countConnectAttempts

オリジン・サーバーへの接続の試行が失敗した合計回数

originServerCountConnectFailures

origin-server-bucket: countConnectFailures

このオリジン・サーバーについてリクエストをプロキシする際、中断されたリクエストの合計数

originServerCountRequestsAborted

origin-server-bucket: countRequestsAborted

オリジン・サーバーとデータを送受信する際、リクエストがタイムアウトになった合計回数

originServerCountRequestsTimedout

origin-server-bucket: countRequestsTimedout

オリジン・サーバーによって処理された合計リクエスト数

originServerCountRequests

origin-server-bucket: countRequests

ヘルス・チェック・リクエストの合計数

originServerCountHealthCheckRequests

origin-server-bucket:countHealthCheckRequests

クローズしている接続の合計数

originServerCountConnectionsClosed

origin-server-bucket:countConnectionsClosed

オリジン・サーバーによってクローズされたキープ・アライブ接続の合計数

originServerCountConnectionsClosedByOriginServer

origin-server-bucket:countConnectionsClosedByOriginServer

動的に計算されたオリジン・サーバーのキープ・アライブ・タイムアウト値

originServerSecondsKeepAliveTimeout

origin-server-bucket:secondsKeepAliveTimeout

固定性リクエストの合計数

originServerCountStickyRequests

origin-server-bucket:countStickyRequests

レスポンス時間に基づいて検出された動的重み(アルゴリズムがleast-response-timeの場合のみ該当)

originServerWeightResponseTime

origin-server-bucket:weightResponseTime

オリジン・サーバーのタイプ(汎用/weblogic/未検出)

originServerType

origin-server-bucket:type

アクティブ時間の平均時間(ミリ秒)

originServerMillisecondsConnectionActiveAverage

origin-server-bucket:millisecondsConnectionActiveAverage

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

この項では、サービス・インスタンスの各VIPのメトリックをリストします。これらのメトリックは、フェイルオーバー・グループでどのノードがプライマリとして構成され、どのノードがバックアップとして構成されているかに加えて、フェイルオーバー・インスタンスの現在の状態を表示します。

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

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

このフェイルオーバー・インスタンスの実際の現在の状態。整数(アクティブの場合1、アクティブでない場合0)。

flagActive

flagActive

バックアップとして構成されるノードの名前

backupNode

backupNode

プライマリとして構成されるノードの名前

primaryNode

primaryNode

フェイルオーバー・グループの仮想IPアドレス

virtualIp

virtualIp

A.10 プロキシ・キャッシュ・メトリック

この項では、Oracle Traffic Directorが追跡するキャッシュ関連のメトリックをリストします。各メトリックについて、SNMP MIBのオブジェクト名、およびstats-xmlレポート内の対応する要素および属性の名前が提供されます。

表A-10 プロキシ・キャッシュ・メトリック

メトリック

SNMP MIBのオブジェクト名

stats-xml要素: 属性

キャッシュ内のエントリの合計数

proxyCacheCountEntries

cache-bucket: countEntries

キャッシュ・コンテンツによって使用されるヒープ領域の量

proxyCacheSizeHeap

cache-bucket: sizeHeapCache

キャッシュ参照が成功した合計回数

proxyCacheCountContentHits

cache-bucket: countContentHits

キャッシュ参照が失敗した合計回数

proxyCacheCountContentMisses

cache-bucket: countContentMisses

エントリがキャッシュから提供された合計回数

proxyCacheCountHits

cache-bucket: countHits

オリジン・サーバーから再検証された合計リクエスト数

proxyCacheCountRevalidationRequests

cache-bucket: countRevalidationRequests

リクエストの再検証が失敗した合計回数

proxyCacheCountRevalidationFailures

cache-bucket: countRevalidationFailures

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

この項では、Oracle Traffic Directorが追跡するDNSキャッシュ参照メトリックをリストします。各メトリックについて、stats-xmlレポート内の要素および属性が提供されます。

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

メトリック

stats-xml要素: 属性

キャッシュ内のエントリの合計数

dns-bucket: countCacheEntries

キャッシュ参照が成功した合計回数

dns-bucket: countCacheHits

キャッシュ参照が失敗した合計回数

dns-bucket: countCacheMisses

非同期参照数

dns-bucket: countAsyncNameLookups

非同期DNSアドレス参照が実行された合計数

dns-bucket: countAsyncAddrLookups

現在進行中の非同期DNS参照数

dns-bucket: countAsyncLookupsInProgress

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

Webアプリケーション・ファイアウォールの攻撃阻止機能は、クライアントとオリジン・サーバーの間で動作します。悪意のあるペイロードを検出すると、Webアプリケーション・ファイアウォールはそのリクエストを拒否し、組込みのアクションのいずれかを実行します。この項では、Webアプリケーション・ファイアウォールの動作と攻撃阻止に使用されるルールについて、基本的な情報を示します。Webアプリケーション・ファイアウォールの管理および構成の詳細は、第11.7項「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.6.7 (http://www.modsecurity.org/).
Server: Oracle Traffic Director/11.1.1.7

--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.6.7 (http://www.modsecurity.org/).
Server: Oracle Traffic Director/11.1.1.7

--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の有効化に関する情報は、第11章「セキュリティの管理」を参照してください。

C.1 Oracle Traffic Directorの保護

次に、環境内のOracle Traffic Directorを保護するための手順を示します。

- 次の状態になるように、システム・ファイアウォールを構成します。

- 外部トラフィックがOracle Traffic Directorサーバー・インスタンスのポートにアクセスできるようにします。デフォルト・ポートは8989です。様々なインスタンスのポート情報の入手方法の詳細は、3.2項「管理ノードのリストの表示」を参照してください。

- Oracle Traffic Director管理ポートには内部トラフィックのみがアクセスできるようにします。

- Oracle Traffic Director管理ノードが管理サーバーと通信できるようにします。

- または、Oracle Traffic Director管理ノードがbond0などのプライベート・インタフェースのみをリスニングするようにします。外部トラフィックはこのインタフェースにアクセスできません。詳細は、第3章「管理ノードの管理」を参照してください。

- Oracle Traffic Directorサーバー・インスタンスが非rootで実行され、いずれのインスタンスもリスニングしないようにします。Oracle Traffic Directorインスタンスの起動方法の詳細は、5.3項「Oracle Traffic Directorインスタンスの起動、停止および再起動」を参照してください。

注意:
管理ノードでインスタンス化する各Oracle Traffic Director構成について、net-config_nameという名前のサブディレクトリがINSTANCE_HOMEサブディレクトリ内に作成されます。

- Oracle Traffic Directorの機能を高め非rootとしての高可用性を提供します。詳細は、第14章「高可用性のためのOracle Traffic Directorの構成」を参照してください。

- 十分なファイル・ディスクリプタを確保します。詳細は、15.3項「ファイル・ディスクリプタ制限のチューニング」を参照してください。

- 適切なネットワーク・レベル保護を確保します。詳細は、http://www.oracle.com/technetwork/articles/servers-storage-admin/secure-linux-env-1841089.htmlを参照してください。
システムの堅牢性を高める方法も検討してください。Oracle Linuxシステムの堅牢性強化の詳細は、http://www.oracle.com/technetwork/articles/servers-storage-admin/tips-harden-oracle-linux-1695888.htmlを参照してください。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, 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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network 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)を参照してください。