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項「オリジン・サーバーの変更」を参照してください。