| Oracle® Fusion Middleware Oracle Traffic Directorの管理 12c (12.2.1) E70065-01 |
|
 前 |
 次 |
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 WebLogicのWLSTを使用する堅牢なコマンドライン・インタフェースだけでなく、シンプルなWebブラウザ・ベースのグラフィカル・ユーザー・インタフェース(Oracle Enterprise Managerを使用)が含まれます。高可用性のため、フェイルオーバー用のアクティブ-パッシブまたはアクティブ-アクティブのいずれかのOracle Traffic Directorインスタンス・ペアを設定できます。ネットワークのトラフィック量の拡大に応じて、リクエストをルーティングできるバックエンド・サーバーを追加してOracle Traffic Directorを再構成することで、簡単に環境をスケーリングできます。IT環境のニーズに応じて、リクエストをバックエンド・サーバーに分散したりレスポンスをクライアントに転送する際に、複数の複合ルールを適用するようにOracle Traffic Directorを構成できます。
この章では、Oracle Traffic Directorを理解し、使用を開始するための情報を提供します。ここの内容は、次のとおりです。
この項では、Oracle Traffic Directorの現在のリリースに追加された機能について説明します。
Oracle Traffic Directorの以前のリリース(11g)では、データベースを必要としませんでした。このリリースでは、データベース・ベースのインストール、または制限付きJRFベースのインストールがサポートされています。インストールの前提条件の詳細は、『Oracle Fusion Middleware Oracle Traffic Directorのインストール』の「Oracle Traffic Directorのインストールの概要」を参照してください。このリリースのOracle Traffic Directorでは、Oracle WebLogic 12.2.1のインタフェースを活用するツール・セットであるWebLogic Management Frameworkが導入され、Oracleを管理するためのシンプルで一貫性のある分散フレームワークが提供されます。WebLogic Management Frameworkの詳細は、『Oracle Fusion Middlewareコンセプトの理解』の「WebLogic Management Frameworkとは」を参照してください。
OTDの機能は、データベースおよび制限付きJRFモード・ベースのインストールの両方で同じです。WebLogic Management Frameworkでは、次のような拡張が導入されています。
構成は、インストール後に行う作業になり、主に構成ウィザードを使用して、ドメインの作成から開始します。詳細は、「Oracle Traffic Directorのインストールおよび構成」を参照してください。
WLST: WebLogicドメインの作成、構成および管理には、WLST、コマンドライン・ユーティリティおよびFusion Middleware Controlを互換的に使用できます。どの方法を選択するかは、グラフィカル・インタフェースとコマンドライン・インタフェースのどちらを使用するか、およびスクリプトを使ってタスクを自動化できるかどうかによって決まります。
Oracle Traffic Directorの構成およびインスタンスは、WebLogicドメインの一部です。
Oracle Traffic Director 12.2.1のコマンドライン・インタフェースはWLST(Weblogic Scripting Tool)です。いくつかのWLSTコマンドは、Oracle Traffic Directorの構成および管理に使用されます。
WLSTコマンドには、次の2つのタイプがあります。
オンライン・コマンド
オフライン・コマンド
ほとんどのWLSコマンドは、WLSサーバーへの接続を必要とする「オンライン専用コマンド」です。一部のコマンドは、WLSサーバーへの接続を必要としない「オフライン専用コマンド」です。一部のコマンドは、どちらの方法でも呼び出すことのできるオンラインおよびオフラインの両方です。
WLSTで構成されたすべてのコマンドは、アクティブ化する必要があります。
詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。
WebLogic Server 12.2.1では、新しいコンセプトであるマルチテナントが導入され、複数の組織で使用する共有可能なインフラストラクチャが提供されます。つまり、専用ドメインを必要としない場合には、1つのドメインで同時に複数のテナントをサポートすることが許可されます。
マルチテナントにより、1つのテナント用に実行中のアプリケーション・インスタンスおよび関連リソースに専有されていたWebLogicドメインのドメイン・パーティション、管理およびランタイム・パーティション内で、リソースの分離が実現できます。
標準的なデプロイメント・シナリオのWebLogicサーバーでは、Oracle Traffic Directorがそのフロントエンドとなるため、WebLogicサーバー側からパーティション関連のタスクを実行するときはいつも、Oracle Traffic DirectorがWebLogicパーティションのフロントエンドとなるように適切に構成する必要があります。
マルチテナントのサポートにより、明示的なユーザーのアクションがなくても、Oracle Traffic Directorが自動的に構成されます。詳細は、「Oracle Traffic Directorの構成」および「エンドツーエンドのライフサイクル管理」を参照してください。
詳細は、『Oracle Fusion Middleware WebLogic Server MTの使用』を参照してください。
監視サブシステムにより、ランタイム・コンポーネント/プロセスの状態に関する詳細な情報が提供され、パフォーマンスのボトルネックの追跡、最適なパフォーマンスを実現するためのシステムのチューニング、容量計画の支援、障害の予測、障害時の根本原因の分析に使用されます。場合によっては、各要件に応じて、すべてが正常に機能していることを確認するために使用されます。
詳細は、第12章「Oracle Traffic Directorインスタンスの監視」を参照してください。
Oracle Fusion Middleware T2Pユーティリティにより、Fusion Middleware環境をテストから本番に、本番環境に固有のカスタマイズとともに移動できます。12.2.1では、このユーティリティはOracle Traffic Directorをサポートします。
詳細は、付録D「Oracle Fusion Middleware T2P Utility for Oracle Traffic Director」を参照してください。
Oracle Traffic Directorでは一般的なヘルス・チェック連結メカニズムがサポートされるようになり、これによりお客様は自分達のヘルス・チェックのプログラム/スクリプトを記述して特定のオリジン・サーバーの状態を監視できるようになりました。外部実行可能ファイルは、オリジン・サーバーのプロトコル・レベルのヘルス・チェック・モニターとして特に有用です。
詳細は、第13章「高可用性を提供するためのOracle Traffic Directorの構成」の5.7.1.1項「外部の実行可能ファイルを使用するためのヘルス・チェック設定の構成」を参照してください。
オーバーフロー接続キューイングは、12.2.1で追加された新しい機能です。オーバーフローするリクエストはキューイングされ、リクエストの優先順位に従ってデキューされます。この機能により、リクエストおよびレスポンスの帯域幅を制御できます。
詳細は、14.3項「スレッド・プールおよび接続キューのチューニング」を参照してください。
ユーザーは、キープ・アライブ・オプションによる複数リクエストに対して、同じオリジン・サーバー接続の再利用の制限を設定できます。オリジン・サーバーごとに帯域幅を制限および制御できます。この機能は、HTTPのオリジン・サーバー・プールの制御に使用できますが、TCPのオリジン・サーバー・プールには使用できません。
12.2.1でこの機能を使用することにより、オリジン・サーバーまたはオリジン・サーバー・プールをメンテナンスのためにマークでき、このようなオリジン・サーバーまたはオリジン・サーバー・プールへのすべての新しい接続およびセッションは、その先に排出されます。
1つのプールは複数のパーティションを持つことができますが、それらのパーティションのうちの1つのみが新しいプールにプッシュできます。タイムアウト時間が経過するか管理者がなんらかのアクションを取るまで、すべての古いリクエストは古いプールに振り向けられます。
オリジン・サーバーのすべてのスケール・アップおよびスケール・ダウンの処理では、Oracle Traffic Directorの機能の変更を必要としません。Oracle Traffic Directorの管理者は、「無効」としてオリジン・サーバーを更新します。すべての進行中のリクエストは、引き続き、無効化されたオリジン・サーバーによって処理されます。これは、単なる実行時の変更ではなく、オリジン・サーバーの新しい状態を反映して構成も更新されます。
Oracle Traffic Directorでは、クリティカルなアプリケーションのリクエスト用に、バックエンド・サーバーへの優先度付きリクエストがサポートされています。この機能により、優先度の高いリクエストが優先度の低いリクエストの前にデキューされます。
Oracle Traffic Directorは、常に、直接的な方法でその構成済オリジン・サーバーに接続しています。必要に応じて、(指定プールの)メンバーであるすべてのオリジン・サーバーが構成済HTTP転送プロキシ・サーバー経由で通信するように、HTTP転送プロキシ・サーバーをオリジン・サーバー・プールに関連付けることができます。
詳細は、第5章「オリジン・サーバー・プールの管理」を参照してください。
12.2.1で使用されているセキュリティ・ライブラリはNZで、証明書/キーのストアはOracle Walletです。NSSはサポートされなくなりました。
Oracle Traffic Director 12cでは、WAFで使用されるModSecurityコードがバージョン2.6.7から2.8.0にアップグレードされました。
Oracle Traffic Directorには、次の機能があります。
高度なロード分散メソッド
Oracle Traffic Directorは、次のいずれかのアルゴリズムを使用してクライアント・リクエストをバック・エンドのサーバーに分散するように構成できます。
ラウンド・ロビン
最小接続件数
最小レスポンス時間
IPハッシュ
重み付けラウンド・ロビン
重み付け最小接続件数
バック・エンド・サーバーでの柔軟なルーティングおよびロード制御
リクエスト・ベースのルーティング
Oracle Traffic Directorは、リクエストURI内の情報(パターン、問合せ文字列、ドメイン、ソースおよび宛先のIPアドレスなど)に基づいて、バック・エンドの特定のサーバーにHTTP(S)リクエストをルーティングするように構成できます。
内容ベースのルーティング
Oracle Traffic Directorは、HTTP(S)リクエストをリクエストのコンテンツに基づいてバックエンドにある特定のサーバーにルーティングするように構成できます。これにより、XMLやJSONなどのWebサービス・リクエストを、本文のコンテンツに含まれる特定の要素に基づいて特定のオリジン・サーバーに簡単にルーティングできます。コンテンツベースのルーティングはデフォルトで有効です。
リクエスト・レート・アクセラレーション
管理者は、バック・エンドの特定のサーバーに対してOracle Traffic Directorがロードを増やすレートを構成できます。この機能を使用して、管理者は、プールに追加された、または再起動されたサーバーでの起動タスク(データのロード、システム・リソースの割当てなど)の実行を許可します。
接続数の制限
Oracle Traffic Directorは、バック・エンドのサーバーへの同時接続数を制限するように構成できます。サーバーの構成済接続制限に達すると、新しい接続を要求するその後のリクエストは、そのサーバーには送信されません。
リクエスト・ロードおよびサービス品質の制御
リクエスト・レート制限
Oracle Traffic Directorは、特定のクライアントからの受信リクエスト、および特定のタイプのリクエストのレートを制限するように設定できます。この機能により、管理者は、使用可能な帯域幅の利用を最適化し、特定のサービス品質レベルを保証して、サービス拒否(DoS)攻撃を回避できます。
サービス品質のチューニング
受信リクエストに対し、使用可能なネットワーク・リソースを公平に利用するために、クライアントへの最大同時接続数、およびデータのクライアントへの最高転送速度を制限するようにOracle Traffic Director仮想サーバーを構成できます。
WebSocket接続のサポート
Oracle Traffic DirectorではWebSocket接続がデフォルトで処理されます。WebSocket接続は存続時間が長いため、ライブ・コンテンツやリアルタイムのゲーム、ビデオ・チャットなどをサポートできます。RFC 6455を厳密に遵守するこれらのクライアントのみを許可するように、Oracle Traffic Directorを構成できます。詳細は、7.4項「ルートの構成」および『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
Oracle Fusion Middlewareとの統合
Oracle Traffic Directorは、バック・エンドのOracle WebLogic Server管理対象サーバーへのリクエスト、およびサーバーからのレスポンスの一部であるヘッダーを認識し処理するように設計されています。
Oracle Traffic Directorインスタンスが、クラスタ化されたOracle WebLogic Server管理対象サーバーにクライアント・リクエストを分散するように構成されている場合、Oracle Traffic Directorは、管理対象サーバーの削除や追加などのクラスタ内の変更を自動検出し、リクエストのルーティング中この変更を考慮します。
Oracle Traffic Directorソフトウェア用に提供されているパッチは、OPatchというJavaベースのユーティリティを使用して適用できますが、これはOracle Fusion Middleware製品にパッチを適用する標準的な方法です。
簡単に使用できる管理インタフェース
管理者はグラフィカル・ユーザー・インタフェースまたはコマンドライン・インタフェースを使用して、Oracle Traffic Directorインスタンスを管理できます。
セキュリティ
Oracle Traffic Directorを使用すると、次の方法でITインフラストラクチャのセキュリティを有効化および拡張できます。
リバース・プロキシ
Oracle Traffic Directorは、ネットワークの外のクライアントとバック・エンドのサーバー間の仲介者として機能し、バック・エンドのサーバーの名前をマスクし、バック・エンドの複数のサーバーによってホストされている重要なデータおよびアプリケーションへのアクセスをトラッキングするための単一のポイントを提供します。
SSL 3.0、TLS 1.0、TLS 1.1およびTLS 1.2のサポート
送信中のデータを保護し、権限のあるユーザーのみがバック・エンドのサーバーにアクセスできるようにするため、Oracle Traffic DirectorインスタンスにSSL/TLSが有効化されたHTTPリスナーとTCPリスナーを構成できます。
VeriSignなどの商用CAによって発行されたデジタル証明書を使用するか、Fusion Middleware ControlまたはWLSTを使用して、鍵サイズが4096ビットまでのRSAタイプおよび楕円曲線暗号(ECC)タイプの自己署名証明書を生成できます。
Webアプリケーション・ファイアウォール
Webアプリケーション・ファイアウォールを使用してHTTPリクエストにルールのセットを適用し、クロスサイト・スクリプティング(XSS)やSQLインジェクションなどの一般的な攻撃を阻止できます。Oracle Traffic DirectorのWebアプリケーション・ファイアウォール・モジュールはオープン・ソースのModSecurity 2.8をサポートしています。
WebGateを使用したシングル・サインオン
WebGateにより、Oracle Traffic Directorのシングル・サインオン(SSO)が可能になります。WebGateは受信リクエストを調べて、リクエストされたリソースが保護されているかどうかを判断し、保護されている場合は、ユーザーのセッション情報を取得します。WebGateを介することで、Oracle Traffic Directorはユーザー認証にSSOを使用できるSSOパートナ・アプリケーションになり、Oracle Single Sign-Onを使用してユーザーIDを取得して、Oracle Traffic Directorを介してアクセスしたWebアプリケーションでそれを使用できるようにします。
高可用性
Oracle Traffic Directorは、次のメカニズムを介して、エンタープライズ・アプリケーションおよびサービスの高可用性を提供します。
バック・エンドのヘルス・チェック
バック・エンドのサーバーが使用不可であるか、完全にロードされている場合、Oracle Traffic Directorは、定期的なヘルス・チェックにより自動的にこの状況を検出し、そのサーバーへのクライアント・リクエストの送信を停止します。障害の発生したサーバーが再び使用可能になった場合、Oracle Traffic Directorは自動的にこれを検出し、このサーバーへのリクエストの送信を再開します。
バック・エンドのサーバーのバックアップ
Oracle Traffic Directorインスタンスのサーバー・プールを設定する際、バック・エンドのいくつかのサーバーをバックアップ・サーバーとして指定できます。Oracle Traffic Directorは、使用可能なプライマリ・サーバーがない場合にのみ、バックアップ・サーバーにリクエストを送信します。この機能により、バック・エンドのサーバーの一部に障害が発生しても、継続的な可用性が確保されます。
ロード・バランシングのためのフェイルオーバー
2つのOracle Traffic Directorインスタンスを、アクティブ-パッシブまたはアクティブ-アクティブ構成でデプロイできます。プライマリOracle Traffic Directorインスタンスに障害が発生した場合、バックアップ・インスタンスに処理が切り替わります。
動的再構成
Oracle Traffic Directorへのほとんどの構成変更は、インスタンスを再起動したり、処理中のリクエストに影響を及ぼしたりすることなく動的にデプロイできます。
統計の監視
管理者は、Fusion Middleware Control、コマンドライン・インタフェース、およびXML形式のレポートなどの複数の方法で、Oracle Traffic Directorインスタンスのパフォーマンスに関連する統計を広範囲に監視できます。
高パフォーマンス
SSL/TLSの負荷軽減
Oracle Traffic Directorは、HTTP/SリクエストおよびTCPリクエストのSSL/TLS終端点として構成できます。これにより、バック・エンドのサーバーの処理のオーバーヘッドが削減されます。
コンテンツ・キャッシュ
Oracle Traffic Directorは、オリジン・サーバーから受信したコンテンツを(プロセス・メモリー内に)キャッシュするように構成できます。コンテンツをキャッシュすることで、Oracle Traffic Directorは、バック・エンドのサーバーの負荷を削減し、クライアントのパフォーマンスを向上できます。
HTTP圧縮
管理者は、バック・エンドのサーバーから受信したデータを圧縮し、リクエスト元のクライアントに圧縮されたコンテンツを転送するようにOracle Traffic Directorインスタンスを構成できます。この機能により、低速接続で接続されたクライアントのレスポンス時間が向上します。
仮想化の有効なソリューション
Oracle Traffic Directorは、クラウドおよび仮想プラットフォーム上の仮想アプライアンスとしてデプロイできます。
Oracle Traffic Directorを物理的なアプリケーションとしてデプロイした後、Oracle Traffic Directorインスタンスから仮想アプライアンスを作成するか、このようなアプライアンスを複数含むアセンブリを作成できます。次に、Oracle仮想マシン・ハイパーバイザーにアプライアンスまたはアセンブリをデプロイできます。このようなデプロイメントを有効にするために、Oracle Virtual Assembly Builderの一部として、Oracle Traffic Directorプラグインが提供されており、このツールを使用して、物理アプリケーションから仮想アプライアンスおよびアセンブリを構築できます。
Oracle Traffic Directorインスタンスを含む仮想アセンブリの作成とデプロイの詳細は、『Oracle Virtual Assembly Builderユーザーズ・ガイド』を参照してください。
TCPロード・バランシング
TCPロード・バランシングにより、Oracle Traffic Directorでクライアント接続を受け入れ、TCPベースのプロトコルを実行しているサーバーのプールにリクエストをルーティングできます。
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インスタンスの構成の詳細は、13.2項「フェイルオーバー・グループの作成と管理」を参照してください。
Oracle Traffic Director構成は、Oracle Traffic Directorインスタンスの実行時の動作を定義する一連の要素です。Oracle Traffic Director構成には、リスナー、オリジン・サーバー、フェイルオーバー・グループ、ログなど、Oracle Traffic Directorインスタンスの様々な要素に関する情報が含まれています。
次の表には、このマニュアルでOracle Traffic Directorの管理タスクを説明するときに使用されている用語が記載されています。
| 用語 | 説明 |
|---|---|
| 構成 | Oracle Traffic Directorインスタンスの実行時の動作を決定する一連の構成可能な要素(メタデータ)。
一般的な構成には、リクエスト、およびリクエストの送信先となる、バック・エンド内のサーバーについての情報をOracle Traffic Directorがリスニングするリスナーの定義(IPアドレスとポートの組合せ)が含まれます。構成は、Oracle Traffic Directorインスタンスの起動時およびクライアント・リクエストの処理中にOracle Traffic Directorによって読み取られます。 |
| インスタンス | 構成からインスタンス化されて管理ノード上にデプロイされるOracle Traffic Directorサーバーです。 |
| フェイルオーバー・グループ | アクティブ-パッシブ・モードで高可用性を提供するために、仮想IPアドレス(VIP)でグループ化された2つのOracle Traffic Directorインスタンス。リクエストは、VIPで受信され、プライマリ・インスタンスと指定されているOracle Traffic Directorインスタンスにルーティングされます。プライマリ・インスタンスに到達できない場合、リクエストはバックアップ・インスタンスにルーティングされます。
アクティブ-アクティブ・フェイルオーバーの場合、2つのフェイルオーバー・グループが必要となり、それぞれ一意のVIPを持ちますが、両方ともプライマリ・ロールとバックアップ・ロールが逆となる同じノードで構成されています。フェイルオーバー・グループ内の各インスタンスは、プライマリ・インスタンスおよびバックアップとして指定され、それぞれにVIPが1つずつ割り当てられます。 |
| ORACLE_HOME | Oracle Traffic Directorバイナリのインストール先としてユーザーに選択されたディレクトリ。 |
| DOMAIN_HOME | Oracle Traffic Directorドメインを含むディレクトリへのパス |
| Fusion Middleware Control | Oracle Traffic Directorインスタンスの作成、デプロイおよび管理に使用できる、管理サーバー上のWebベースのグラフィカル・インタフェース。 |
| クライアント | HTTPリクエスト、HTTPSリクエストおよびTCPリクエストをOracle Traffic Directorインスタンスに送信する任意のエージェント(たとえば、ブラウザまたはアプリケーション)です。 |
| オリジン・サーバー | バックエンドのサーバーであり、Oracle Traffic Directorはクライアントから受信したHTTPリクエスト、HTTPSリクエストおよびTCPリクエストをこのサーバーに転送し、クライアント・リクエストに対するレスポンスをこのサーバーから受信します。
オリジン・サーバーとして、Oracle WebLogic Server管理対象サーバーのようなアプリケーション・サーバーやWebサーバーなどを使用できます。 |
| オリジン・サーバー・プール | Oracle Traffic Directorを使用してロード・バランシングを行うことができる、同じアプリケーションまたはサービスをホストするオリジン・サーバーの集合です。
Oracle Traffic Directorは、オリジン・サーバー・プールに対して指定されたロード分散方法に基づいて、プール内にある各サーバーにクライアント・リクエストを分散させます。 |
| 仮想サーバー | 一意のIPアドレス(またはホスト名)とポートの組合せを提供するOracle Traffic Directorサーバー・インスタンス内の仮想エンティティであり、これを通じてOracle Traffic Directorは1つ以上のドメインのリクエストを処理できます。
ノード上のOracle Traffic Directorインスタンスには、複数の仮想サーバーを含めることができます。管理者は、仮想サーバーごとに個別に最大着信接続数などの設定を構成できます。また、各仮想サーバーのリクエスト処理方法をカスタマイズすることもできます。 |
Oracle Traffic Directorは物理アプリケーションと仮想アプライアンスのいずれとしても使用できます。
物理アプリケーション
Oracle Traffic DirectorをOracle Linux 6.5システムにインストールし、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ユーザーズ・ガイド』を参照してください。
製品のインストール
サイレント・モードで、または対話型のグラフィカル・ウィザードを使用して、Oracle Traffic Directorをx86_64のOracle Linux 6.5+にインストールできます。12cでは、Oracle Traffic Directorにはそれ専用の管理サーバーはなく、Oracle WebLogic Serverの管理サーバーを使用することに注意してください。
詳細は、「Oracle Traffic Directorのインストール」を参照してください。
Oracle Traffic Director用のWebLogicドメインの作成。詳細は、第2章「Oracle Traffic Director用のWebLogic Serverドメインの構成」を参照してください。
Fusion Middleware ControlおよびWLSTへのアクセス
Oracle Traffic DirectorのFusion Middleware Controlおよびコマンドライン・インタフェースを使用して、Oracle Traffic Directorの構成を作成、変更および監視できます。
Fusion Middleware Controlおよびコマンドライン・インタフェースへのアクセスの詳細は、1.7項「管理インタフェースへのアクセス」を参照してください。
構成の作成および管理
Oracle Traffic Directorインスタンスを定義する構成を作成します。構成とは、Oracle Traffic Directorのインスタンス化に使用できるメタデータの集合です。この構成は、サーバー・インスタンスの起動時およびクライアント・リクエストの処理中にOracle Traffic Directorによって読み取られます。
構成の管理の詳細は、第3章「構成の管理」を参照してください。
インスタンスの作成および管理
構成を作成した後、1つ以上のホストにその構成をデプロイすることによってOracle Traffic Directorサーバー・インスタンスを作成できます。各インスタンスの現在の状態を表示したり、各インスタンスを起動または停止したり、各インスタンスを再構成して構成の変更を反映させたりすることができます。
インスタンスの管理の詳細は、第4章「インスタンスの管理」を参照してください。
オリジン・サーバー・プールの定義および管理
Oracle Traffic Directorインスタンスによってクライアント・リクエストを分散させるには、バックエンド内に1つ以上のオリジン・サーバー・プールを定義する必要があります。オリジン・サーバー・プールごとに、Oracle Traffic Directorによるリクエストの分散に使用するロード分散方法を定義できます。さらにプール内のオリジン・サーバーごとに、Oracle Traffic Directorによるリクエスト・ロードの制御方法を定義できます。
詳細は、第5章「オリジン・サーバー・プールの管理」および第6章「オリジン・サーバーの管理」を参照してください。
仮想サーバーおよびリスナーの作成および管理
ノード上で実行されているOracle Traffic Directorインスタンスには、1つ以上の仮想サーバーが含まれています。各仮想サーバーには、クライアントからリクエストを受信するための1つ以上のリスナーが備わっています。各仮想サーバーでは、仮想サーバーによるリクエストのルーティング先となるオリジン・サーバー・プール、サービス品質の設定、リクエスト制限、キャッシュ・ルール、ログ・プリファレンスなどのパラメータを構成できます。
詳細は、第7章「仮想サーバーの管理」および第9章「リスナーの管理」を参照してください。
セキュリティの管理
Oracle Traffic Directorは、標準的なネットワークにおいて外部とのやり取りを担う位置に実装されるため、バックエンド内のデータおよびアプリケーションをネットワークの外部からの攻撃や不正アクセスから保護する上で重要な役割を果たします。さらに、Oracle Traffic Directorを通って残りのネットワークに達するデータについて、そのセキュリティおよび整合性を確保する必要があります。
詳細は、第10章「セキュリティの管理」を参照してください。
ログの管理
Oracle Traffic Directorのログ・ファイルには、構成の変更、インスタンスの起動および停止、リクエスト処理中のエラーなどのサーバー・イベントに関するデータが記録されます。ログは、エラーのトラブルシューティングやシステムのチューニングによるパフォーマンス向上に役立ちます。
詳細は、第11章「ログの管理」を参照してください。
統計の監視
Oracle Traffic Directorインスタンスの状態およびパフォーマンスは、構成設定、着信リクエストの量、オリジン・サーバーのヘルス、インスタンスを通過するデータの種類など、複数の要因によって影響を受けます。管理者は、コマンドライン・インタフェースおよびFusion Middleware Controlを使用して、これらの要因すべてについてのメトリックを表示し、XMLファイルのフォームに統計を出力して詳細な分析を行うことができます。Oracle Traffic Directorによって収集する統計の粒度を調整することもできます。
詳細は、第12章「Oracle Traffic Directorインスタンスの監視」を参照してください。
高可用性を提供するためのOracle Traffic Directorインスタンスの設定
Oracle Traffic Directorインスタンスまたはその実行ノードに障害が発生した場合には、インスタンスによって提供されているロード・バランシング・サービスが、中断されることなく継続的に利用できるようにする必要があります。プライマリ・インスタンスに障害が発生したときにリクエストの処理を引き継ぐ、バックアップ用のOracle Traffic Directorインスタンスを構成することによって、この目標を達成できます。
詳細は、第13章「高可用性のためのOracle Traffic Directorの構成」を参照してください。
パフォーマンス向上のためのチューニング
パフォーマンス統計の分析に基づき、あるいはリクエスト・ロード・プロファイルの変更に応じて、パフォーマンスの維持や向上のためにOracle Traffic Directorのリクエスト処理パラメータの調整が必要になる場合があります。Oracle Traffic Directorにはパフォーマンス・チューニングのための様々なコントロールおよびノブが備わっており、これらを使用して、個々のリクエストのサイズおよび量を制限したり、タイムアウトの設定を制御したり、スレッド・プールの設定やSSL/TLSキャッシュの動作を構成したりすることができます。
詳細は、第14章「パフォーマンス向上のためのOracle Traffic Directorのチューニング」を参照してください。
問題の診断およびトラブルシューティング
どんなに注意を払っていても、Oracle Traffic Directorインスタンスをインストール、構成または監視しているときに問題が発生することがあります。これらの問題の一部は、エラー・メッセージおよびログに表示されている情報に基づいて診断、解決できます。複雑な問題については、オラクル社のサポート担当者が問題の把握、再現および診断に使用できるように、ユーザーが特定のデータを収集する必要があります。
詳細は、第15章「問題の診断およびトラブルシューティング」を参照してください。
この項では、次の項目について説明します。
Oracle Traffic Director 12cのコマンドライン・インタフェースはWLST(Weblogic Scripting Tool)です。WLSTスクリプト環境は、Javaプラットフォーム用のPython言語の実装であるJythonに基づいています。このツールは、オンラインおよびオフラインの両方で使用できます。WLSTおよび様々なオンラインとオフライン・コマンドの詳細は、「Oracle WebLogic Scripting Tool」を参照してください。Oracle Traffic Directorには、WLSTを使用して実行できるカスタムWLSTコマンドが付属しています。
|
注意: Oracle Traffic Directorには、Oracle Traffic Directorコマンドに必要な環境やライブラリを初期化するwlst.shラッパー(<oracle_home>/otd/common/bin/wlst.sh)が付属しています。すべてのOracle Traffic Directorのカスタム・コマンドは、このwlst.shからのみ実行できます。 |
WLSTの使用方法の詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
Fusion Middleware Controlを表示するには、Fusion Middleware ControlのURLを入力します。このURLには、インストール時に割り当てられたホスト名と管理ポート番号が含まれます。このURLの形式は次のとおりです。
http://hostname.domain:port/em
ポート番号は、Fusion Middleware Controlのポート番号です。デフォルトのポート番号は7001です。ポート番号は、次のファイルにリストされています。
DOMAIN_HOME/config/config.xml
Web層など、一部のインストール・タイプでは、最後のインストール画面で「保存」をクリックしてインストール情報を保存した場合、Fusion Middleware ControlのURLが、ディスクに書き込まれたファイル(デフォルトではホーム・ディレクトリにあります)に含まれています。その他のインストール・タイプの場合、構成が完了すると構成ウィザードの「ドメインの作成」画面に情報が表示されます。
Fusion Middleware Controlを表示するには:
WebブラウザにURLを入力します。例:
http://host1.example.com:7001/em
Oracle Fusion Middleware管理者のユーザー名とパスワードを入力して、「ログイン」をクリックします。
これでOracle Traffic Director構成を作成し、管理ノードのインスタンスとしてデプロイできるようになりました。詳細は、第3章「構成の管理」を参照してください。
この項では、Oracle Traffic Directorを使用して、ロード・バランシングされたサービスを最小限の設定でどのように設定できるかについて説明します。この項の目的は、この章で前述された概念を補足してわかりやすく説明し、この後の章で説明する構成タスクのためにユーザーが準備できるようにすることです。
この項では、次の項目について説明します。
この例では、Oracle Traffic Directorの単一のインスタンスを作成し、このインスタンスがHTTPリクエストを受信し、バック・エンドの2つのオリジン・サーバーに分散します。これらのオリジン・サーバーは両方とも同じコンテンツを提供します。
図1-2は、例のトポロジを示しています。
例のトポロジは次の構成に基づいています。
管理サーバーのホストおよびポート: 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.1項「トポロジの例」で説明されたトポロジの設定方法を説明します。
「Oracle Traffic Directorのインストール」の説明に従ってOracle Traffic Directorをインストールします。
otd_createConfiguration WLSTコマンドを使用して、構成hr-configを作成します。
props = {}
props['name'] = 'hr-config'
props['listener-port'] = '1905'
props['server-name'] = 'hr-apps.example.com'
props['origin-server'] = 'hr-1.example.com:80,hr-2.example.com:80'
otd_createConfiguration(props)
otd_createInstance WLSTコマンドを実行して、構成hr-configのインスタンスを作成します。Fusion Middleware Controlでマシンの作成時に指定した名前と同様に、OTDインスタンスが実行されているマシンのホスト名に対応するようにマシンを指定します。
props = {}
props['configuration'] = 'hr-config'
props['machine'] = 'machine1'
otd_createInstance(props)
start WLSTコマンドを実行して、作成したOracle Traffic Directorインスタンスを起動します。
start('otd_foo_machine1')
|
注意: この手順ではWLSTを使用していますが、Fusion Middleware Controlを使用することもできます。 |
これで、Oracle Traffic Directorの構成の作成およびインスタンスの起動が正常に実行できました。
前の手順で作成し起動したOracle Traffic Directorインスタンスは、URL http://hr-apps.example.com:1905でHTTPリクエストをリスニング中です。
この項では、Oracle Traffic Directorインスタンスのロード・バランシングの動作を、ブラウザを使用してどのように確認するかを説明します。
|
注意:
|
URL http://hr-apps.example.com:1905をブラウザに入力します。
次のテキストを含むページが表示されます。
"オリジン・サーバー1から提供されたページ"
これは、apps.example.com管理ノードで実行中のOracle Traffic Directorインスタンスが、ブラウザから送信されたHTTPリクエストを受信し、オリジン・サーバーhr-1.example.com:80へ転送したことを示します。
ブラウザ・ウィンドウをリフレッシュして、別のHTTPリクエストをhttp://hr-apps.example.com:1905に送信します。
次のテキストを含むページが表示されます。
オリジン・サーバー2から提供されたページ
これは、Oracle Traffic Directorが2番目のリクエストをオリジン・サーバーhr-2.example.com:80に送信したことを示します。
ブラウザ・ウィンドウを再度リフレッシュして、3番目のHTTPリクエストをhttp://hr-apps.example.com:1905に送信します。
次のテキストを含むページが表示されます。
"オリジン・サーバー1から提供されたページ"
これは、Oracle Traffic Directorがシンプルなラウンド・ロビン・ロード分散メソッドを使用して、3番目のHTTPリクエストをオリジン・サーバーhr-1.example.com:80に送信したことを示します。
