障害の管理について

Oracle Fusion Middleware (FMW)ストレッチ・クラスタ・トポロジは、個々のコンポーネントの障害に対して回復力があります。

各サイトは、Oracle FMWエンタープライズ・デプロイメント・トポロジで概説されている高可用性のベスト・プラクティスに従い、ローカル冗長性がコンポーネント・レベル(ロード・バランサ、Oracle HTTP Serverインスタンス、Oracle WebLogic Serverまたはデータベース・インスタンスなど)の中断から保護されるようにします。

サイト内の完全な層の障害やサイト全体の障害などのシナリオに対処するための考慮事項については、次の各項で説明します。

1つのサイト上のすべてのWebサーバーの障害の管理

サイトがすべてのOracle HTTP Serverインスタンスを失った場合、フロントエンド・システム(グローバル・ロード・バランサまたはOracle Cloud Infrastructure (OCI)トラフィック管理ステアリング・ポリシー)は、サイトを異常としてマークする必要があります。

すべてのクライアント・リクエストは、サイト・プリファレンスに関係なく、他のサイトにルーティングされます。

したがって、失敗したWebサーバーがあるサイトのOracle WebLogicサーバーは、新しいリクエストを受信しません。処理を続行する場合があります(たとえば、Oracle SOAコンポジットおよびjavaメッセージ・サービス(JMS)メッセージの処理)。ただし、これらのサーバーから内部的に生成されたHTTPコールバックは、Webサーバーに障害が発生した独自のサイトを指しているため、失敗します。

次の図は、1つのサイト上のすべてのWebサーバーの障害を示しています


failure-all-web-servers-one-site.pngの説明が続きます
図failure-all-web-servers-one-site.pngの説明

失敗- すべてのWebサーバー-1サイト-oracle.zip

障害からのリカバリ

1つのサイト上のすべてのWebサーバーでの障害からの即時リカバリには、手動による介入は必要ありません。

クライアントは、Oracle Cloud Infrastructure (OCI) Traffic Managementステアリング・ポリシーまたはグローバル・ロード・バランサ(GLBR)によって、他のサイトに自動的にリダイレクトされます。

失われたWebサーバー・インスタンスを短期間でリストアできない場合は、次の操作を実行して、失敗したWeb層でサイトのWebLogicサーバーを使用できます。

  1. 障害が発生したサイトのOracle WebLogic Serverインスタンスにリクエストをルーティングするように、もう一方のサイトのOracle HTTP Server (OHS)インスタンスを構成します。
    1. OHS構成を更新し、DynamicServerListパラメータをONに設定します。
    2. この変更を適用するには、OHSをローリング方式で再起動して停止時間を回避します。
    3. また、Webサーバーから他のサイトのWebLogicサーバーへのリージョン間通信が許可されていることを確認します。
  2. 使用できないOHSサーバーがあるサイトから発生したハイパーテキスト転送プロトコル(HTTP)コールバックの障害を回避するには、WebLogicサーバー・ホストの/etc/hostsファイルまたはプライベート・ドメイン・ネーム・システム(DNS)でフロントエンド名のエントリを更新して、他方のサイトのロード・バランサを指すようにします。
障害の発生したサーバが再び利用可能になった後:
  1. 失敗したサイトでOHSプロセスを起動します。

    Oracle Cloud Infrastructure Health Checksが再度OKになるとすぐに、トラフィック管理ステアリング・ポリシーによって、定義されたルールに従って、両方のサイト間でクライアント・リクエストがロード・バランシングされます。

  2. もう一方のサイトで、DynamicServerListをもう一度OFFに設定します。
  3. WebLogicサーバーの/etc/hostsファイル(またはプライベートDNS)の変更を元に戻して、独自のサイト・ロード・バランサを再度ポイントするようにします。

次のイメージは、Java Message Service (JMS)キュー・メッセージと、1つのサイト上のすべてのWebサーバーの障害時に失敗したクライアント・リクエストを示しています。


failure-messages-all-web-servers-one-site.pngの説明が続きます
図failure-messages-all-web-servers-one-site.pngの説明

予想リカバリ時間目標

グローバル・バランシングにOracle Cloud Infrastructure (OCI)トラフィック管理ステアリング・ポリシーを使用する場合、エラーは、約1分+稼働までのDNS時間(TTL)の期間に発生します。

DNS更新は、ステアリング・ポリシー・プリファレンスが失敗したリージョンに設定されているクライアントに影響します。TTL値は、正常なサイトを指すように更新する前に、これらのクライアントが古いエントリを引き続き使用する期間を決定します。追加の時間(約1分)は、OCIステアリング・ポリシーで構成されたヘルス・チェックの頻度とタイムアウト(前述のテストでヘルス・チェック間隔に30秒が使用され、タイムアウトは10秒)によって異なります。

グローバル・ロード・バランサ(GLBR)を使用する場合、停止時間は、GLBRで構成されたヘルス・チェックの頻度によって異なります。GLBRがプールを不健全とマークすると、受信リクエストはもう一方のサイトにリダイレクトされます。GLBRではDNS更新がないため、フロントエンド・エントリのTTL値は関係ありません。

1つのサイトですべてのOracle WebLogic Serversの障害の管理

すべてのWebLogicサーバーが1つのサイトで停止すると、もう一方のサイトがリクエストの処理を続行します。

失敗したサイトのロード・バランサは、失敗したレスポンスを返すため、Oracle Cloud Infrastructure (OCI)トラフィック・ステアリング・ポリシーおよびヘルス・チェックに基づくフロントエンド・グローバル・バランシング機能は、サイトを異常としてマークする必要があります。すべてのクライアント・リクエストは、プリファレンスに関係なく、他のサイトにルーティングされます。

Java Database Connectivity (JDBC)永続ストアとともに自動サービス移行を使用すると、WebLogic Java Message Service (JMS)サービスおよびJava Transaction API (JTA)サービスは、他のサイトのサーバーに自動的に移行されます。

Oracle Fusion Middleware (FMW) SOAの場合、障害の発生したサーバーで自動リカバリ・クラスタ・マスターがホストされていた場合、使用可能なサイトで新しいクラスタ・マスターが発生します。このサーバーは、他のサイトで開始されたSOAインスタンスの自動リカバリを実行します。

次の図は、1つのサイト上のすべてのWebLogicサーバーの障害を示しています。


failure-all-weblogic-servers-one-site.pngの説明が続きます
図failure-all-weblogic-servers-one-site.pngの説明

failure-all-weblogic-servers-one-site-oracle.zip

次の図は、サイトですべてのWebLogicサーバーに障害が発生した場合の、サーバー当たりのクライアント失敗リクエストおよびJMSメッセージを示しています。


failure-messages-all-weblogic-servers-one-site.pngの説明が続きます
図fault-messages-all-weblogic-servers-one-site.pngの説明

JMSメッセージ・グラフには4つの線があり、それぞれがサーバーのJMSキューを表します。緑線と青線(ほぼ重なっている)は、強制終了されたサーバーに対応します。これらのキューのJMSメッセージの数は、停止の開始後に増加しません。

赤線と黄線は、リージョン2で稼働しているサーバーを表します。すべてのリクエストがこのリージョンにリダイレクトされると、残りの各サーバーは合計負荷の50%を受け取ります。ただし、メッセージがキューに蓄積される割合は異なります。これは、障害が発生したサーバーのJMSサーバーが残りのサーバーのいずれかに移行されたため、そのサーバーのメッセージは3つのキューによって処理されるようになったためです。その結果、勾配は黄色の勾配の下に表示されます(モニタリング・ツールでは、移行されたキューのメッセージ数は表示されません)。

障害からのリカバリ

1つのサイト上のすべてのOracle WebLogic Serverサーバーの障害からの即時リカバリには、手動による介入は必要ありません。

障害の発生したサーバが再び利用可能になった後:

  1. 障害が発生したサイトの管理対象サーバーを起動します。
  2. Oracle Cloud Infrastructure Health Checksが再度正常になるとすぐに、Traffic Managementステアリング・ポリシーによって、定義されたルールに従って両方のサイト間でクライアント・リクエストがロード・バランシングされます。

予想リカバリ時間目標

Oracle Cloud Infrastructure (OCI)トラフィック管理ステアリング・ポリシーをグローバル・バランシングに使用する場合、エラーは約1分間に発生し、DNSの稼働時間(TTL)が経過します。

これは、1つのサイト上のすべてのWebサーバーで障害が発生した場合と似ています。

DNS更新は、ステアリング・ポリシー・プリファレンスが失敗したリージョンに設定されているクライアントに影響します。TTL値は、正常なサイトを指すように更新する前に、これらのクライアントが古いエントリを引き続き使用する期間を決定します。追加の時間(約1分)は、OCI Traffic Managementステアリング・ポリシーで構成されたヘルス・チェックの頻度とタイムアウト(ヘルス・チェック間隔のテストで30秒が使用され、タイムアウトは10秒)によって異なります。

グローバル・ロード・バランサ(GLBR)を使用する場合、停止時間は、GLBRで構成されたヘルス・チェックの頻度によって異なります。GLBRがプールを不健全とマークすると、受信リクエストはもう一方のサイトにリダイレクトされます。GLBRではDNS更新がないため、フロントエンド・エントリのTTL値は関係ありません。

データベースでの障害の管理: Data Guardスイッチオーバーおよびフェイルオーバー

問題がプライマリ・データベースのみに影響する場合は、できるだけ早くデータベースのスイッチオーバーまたは他方のサイトへのフェイルオーバーを実行します。

「WebLogicデータ・ソースの設定」で前述したJava Database Connectivity (JDBC) URL文字列およびOracle Notification Service (ONS)構成により、新しいプライマリ・データベースへの再接続が自動的に行われるようになります。これらの正確なテスト(Oracle Fusion Middleware (FMW) SOA FODの使用、および160回の同時呼出しのワークロードが高い場合でも)では、データベースのスイッチオーバーまたはフェイルオーバーにかかる時間は数分未満です。この時間は、システム構成および環境によって異なります。適切にチューニングされたシステムでは、1-5分のスイッチオーバー時間が一般的ですが、システム・サイズ、リソース、ワークロード、REDOログの同期、ネットワーク・パフォーマンスなどの要因が合計期間に影響する可能性があります。Oracle Data Guardドキュメントおよびその他のリソースへのリンクは、さらに参照してください。

データベースのスイッチオーバーまたはフェイルオーバー中に、アプリケーション・エラーが発生します。また、サービス移行を使用するWebLogicサーバーは、リース表を更新できない場合、ノード・マネージャによって自動的に停止および再起動できます。デフォルトのリース・パラメータで想定される動作は次のとおりです。

  1. データベースの停止が非常に短い(1-2分未満)場合は、WebLogicサーバーの自動再起動は予期されません。
  2. データベースの停止時間が長く(2~10分)、WebLogicサーバーは、データベースの再起動時に「lost a lease(リースを失った)」ために自動再起動することがあります。

    WebLogicデータベース・リースのチューニングの構成に関する項で前述したように、WebLogicのデータベース・リースの再試行をチューニングすることで、下限を増やすことができます。

  3. データベースの停止時間が10分より長い場合(10分以上)、WebLogicサーバーは、重要なJDBCストアへのアクセスを失う(JTAのJDBCストアは使用不可)などの他の障害のために自動再起動できます。

次の図は、FMWストレッチ・クラスタ・トポロジのデータベース・スイッチオーバーを示しています


stretch-clusters-db-switchover.pngの説明が続きます
図stretched-clusters-db-switchover.pngの説明

ストレッチクラスタ-db-switchover-oracle.zip

次の図は、FMWストレッチ・クラスタでのデータベース・スイッチオーバー中のサーバー・キュー当たりのクライアント・リクエスト・パフォーマンスおよびJava Message Service (JMS)メッセージを示しています。


stretch-clusters-db-switchover-messages.pngの説明が続きます
図stretched-clusters-db-switchover-messages.pngの説明

障害からのリカバリ

データベース障害からすぐにリカバリするには:
  1. Oracle Cloud Infrastructure (OCI)コンソールまたはOracle Data Guard Brokerコマンドライン・インタフェースを使用して、データベース・スイッチオーバーを実行します。
  2. プライマリ・データベースが使用できない場合は、スタンバイ・データベースからデータベース・フェイルオーバーを実行します。

    Oracle WebLogic Serverサーバーは、新しいプライマリ・データベースに自動的に再接続するため、必要に応じてアプリケーション固有のエラーからリカバリする以外に、手動アクションは必要ありません(たとえば、Oracle SOA Suiteでは、エラー・ホスピタルでコンポジットをリカバリする必要がある場合があります)。

障害の発生したサーバが再び利用可能になった後:

  1. データベース・フェイルオーバーを実行した場合は、障害が発生したデータベースを回復します。

    スイッチオーバーを実行した場合、このアクションは必要ありません。

  2. 元のサイトへのデータベース・スイッチバックを実行します。

予想リカバリ時間目標

計画的なスイッチオーバーの場合、リカバリの合計時間は短く、データベースがスイッチオーバーまたはフェイルオーバーに必要な時間によって異なります。

実行されたテストでは、スイッチオーバーにかかる時間は2分未満です。

計画外のスイッチオーバーまたはフェイルオーバーの場合、合計停止時間はデータベースが停止した時間によって異なります。

  • データベースのフェイルオーバーまたはスイッチオーバーをほぼ即時に実行すると、リカバリの合計時間が短くなります。これは、データベースがスイッチオーバーまたはフェイルオーバーに必要な時間によって異なります。実行されたテストでは、スイッチオーバーに2分未満かかるため、予想されるリカバリ時間目標(RTO)は次のとおりです。
    RTO = DB DOWNTIME + SHORT TIME (1-2 min)
  • データベースの停止時間が長くなると、Oracle WebLogic Serverの自動再起動などの追加のエラーが発生し、RTOが増加する可能性があります。この場合、予想されるRTOは次のとおりです。 
    RTO = DB DOWNTIME + WEBLOGIC START TIME

WebLogic管理サーバーでの障害の管理

管理サーバーのプロセス障害は、そのノードのWebLogicノード・マネージャによって処理されます。

ノード・マネージャは、障害の発生したサーバーをインプレースで自動的に再起動します。

ただし、停止が管理サーバーが実行されているホストに完全に影響する場合は、管理サーバーを別のノードにフェイルオーバーする必要があります。

基本的に、これは、管理サーバーのドメイン・ディレクトリを含む場所を指し示し、適切な仮想IP (VIP)にマップされるリスニング・アドレスを使用していることを確認して、別のノードでの管理サーバーの再起動で構成されます。

この管理サーバー・ドメイン・ディレクトリは、同じリージョン内の異なるノードで使用可能な共有記憶域の場所、または別のリージョン内のノードで使用可能になったバックアップまたはファイル・システム・レプリケーションからのリストアです。

ノート:

ストレッチされたクラスタ構成に関係なく、Oracle WebLogicドメインに適切なバックアップ手順が用意されていることが期待されます。

したがって、Oracle Fusion Middleware (FMW)ストレッチ・クラスタ・トポロジでは、管理サーバーを別のリージョンのノードに移行する場合と、同じリージョンのノードに移行する場合とでは、異なる考慮事項が適用されます。

次の図は、FMWストレッチ・クラスタ内の他のサイトへの管理サーバーのフェイルオーバーを示しています


fails-admin-server.pngの説明が続きます
図failers-admin-server.pngの説明

failure-admin-server-oracle.zip

別のリージョンへのフェイルオーバー

管理サーバーを別のリージョンにフェイルオーバーするには、次のステップに従います。
  1. 管理サーバーのドメイン・ディレクトリ(ASERVER_HOME)のバックアップをフェイルオーバー・サイトで使用可能にします。
  2. フェイルオーバー・サイトでASERVER_HOMEディレクトリ(ドメイン・ディレクトリとアプリケーション・ディレクトリの両方を含む)をリストアして、同じドメイン・ディレクトリ構造が元のサイトと一致するようにします。
  3. リージョン1とリージョン2のサブネットでは通常、異なるクラスレス・ドメイン間ルーティング(CIDR)ブロックが使用されます。その結果、リージョン1で管理サーバーによって使用される仮想IP (VIP) (10.10.10.1など)は、リージョン2では無効です。管理サーバーがリージョン2で実行されると、別のVIP (20.20.20.1など)が使用されます。管理サーバーのリスニング・アドレス(ADMINHOSTVHN)が新しいVIPにマップされるように、ホスト名解決を更新します。
    1. Oracle Cloud Infrastructureでの仮想IP (VIP)の使用ブログの説明に従って、リージョン2で管理サーバーを実行するホストに仮想IPを割り当ててアタッチします。
    2. 両方のリージョンの/etc/hostsまたはドメイン・ネーム・システム(DNS)のプライベート・ビューを更新して、ADMINHOSTVHNレコードを前のIP (10.10.10.1など)から新しいIP (20.20.20.1など)に変更します。
  4. 管理サーバーがリストアされるノードのファイル$NM_HOME/nodemanager.domainsを変更してASERVER_HOMEを含めて、ノード・マネージャを再起動します。
    domain_name=MSERVER_HOME;ASERVER_HOME
  5. 新しいホストで管理サーバーを起動します。
  6. Oracle HTTP Serverインスタンスは、mod_wl_ohs.confのディレクティブWLDNSRefreshIntervalによって制御されるDNSキャッシュを使用します。デフォルトは0で、「永久キャッシュ」を意味します。DNS解決キャッシュをリフレッシュするには、OHSを再起動する必要があります。次の2つの方法があります。
    1. OHSサーバーを再起動して、DNS解決キャッシュをリフレッシュします。
    2. または、mod_wl_ohs.confでWLDNSRefreshIntervalにゼロ以外の値を設定します。

    それ以外の場合、OHSは前のIPアドレスで管理サーバーへの接続を試行し続けます。

WebLogicリモート・コンソールとOracle Enterprise Manager Fusion Middleware Controlの両方にアクセスして、管理サーバーが正常に機能していることを確認します。

同じリージョンへのフェイルオーバー

管理サーバーを同じリージョン内のホストにフェイルオーバーするには、管理サーバーのドメイン・ディレクトリをコピーする必要はなく、仮想IP (VIP)の値は変更されません。

したがって、フェイルオーバー手順は、管理サーバーのエンタープライズ・デプロイメント・ガイドの管理サーバーの手動フェイルオーバーの確認で説明されている手順と同じです。

Oracle Cloud Infrastructure (OCI)システムで管理サーバーの仮想IP (VIP)を管理するには、ブログOracle Cloud Infrastructureでの仮想IP (VIP)の使用で説明されているステップを使用できます

プライマリ・データベースをホストするリージョン全体の障害の管理

停止がリージョン1全体に影響する場合は、できるだけ早くデータベース・スイッチオーバーを実行するか、他のサイト/リージョンにフェイルオーバーします。

前の項で説明した推奨構成を使用する場合、残りのサイトのOracle WebLogic Serverインスタンスは、新しいプライマリ・データベースに自動的に再接続されます。

失敗したサイトのロード・バランサは失敗したレスポンスを返すため、フロント・エンドのグローバル・バランシング機能はサイトを不健全とマークする必要があります。すべてのクライアント・リクエストは、プリファレンスに関係なく、他のサイトにルーティングされます。

WebLogic JMSおよびJTAサービスは、JDBC永続ストアとともに自動サービス移行を使用するときに、他のサイトのサーバーに自動的に移行されます。Oracle Fusion Middleware (FMW) Oracle SOA Suiteの場合、障害の発生したサーバーで自動リカバリ・クラスタ・マスターがホストされていた場合、使用可能なサイトで新しいクラスタ・マスターが発生します。新しいクラスタ・マネージャは、他のサイトで開始されたSOAインスタンスの自動リカバリを実行します。

次の図は、FMWストレッチ・クラスタ・トポロジにおけるリージョン1全体の障害を示しています。


failure-entire-region.pngの説明が続きます
図failers-entire-region.pngの説明

失敗- 領域全体-oracle.zip

障害からのリカバリ
リージョン1で完全な障害からすぐにリカバリするには:
  1. Oracle Cloud Infrastructure (OCI)コンソールまたはOracle Data Guard Brokerコマンドライン・インタフェースを使用して、データベース・スイッチオーバーを実行します。

    プライマリ・データベースが使用できない場合は、スタンバイ・データベースからデータベース・フェイルオーバーを実行します。

  2. Oracle WebLogic Serverインスタンスは、新しいプライマリ・データベースに自動的に再接続するため、アプリケーション固有のエラーからリカバリする以外に手動アクションは必要ありません(たとえば、Oracle SOA Suiteでは、エラー・ホスピタルでコンポジットをリカバリする必要がある場合があります)。
  3. 必要に応じて、リージョン2への管理サーバーのフェイルオーバーを実行します。

失敗したサイトがリカバリされ、再度使用可能になると、次のようになります。

  1. 障害が発生したホストのプロセス(Oracle HTTPサーバー、WebLogic管理サーバーおよび管理対象サーバー)を再起動します。

    管理サーバーの仮想IP (VIP)が設定されていること、および起動を妨げる孤立ファイルが存在しないことを確認してください。

  2. データベース・フェイルオーバーを実行した場合は、障害が発生したデータベースを回復します。

    スイッチオーバーを実行した場合、このアクションは必要ありません。

  3. 元のサイトへのデータベース・スイッチオーバーを実行します。
予想リカバリ時間目標
データベースが停止している間、システムは使用できなくなります。

残りのサイトのサーバーは、データベースが残りのサイトで再度実行されるとすぐにリクエストの処理を続行できるため、停止時間は、データベースを切り替える前に使用された時間によって異なります。

  • データベースのフェイルオーバーまたはスイッチオーバーをほぼ即時に実行すると、リカバリの合計時間が短くなります。これは、データベースがスイッチオーバーまたはフェイルオーバーに必要な時間によって異なります。実行されたテストでは、スイッチオーバーに2分未満かかるため、予想されるRTOは次のとおりです。 
    RTO = DB DOWNTIME + SHORT TIME (1-2 min).
  • データベースの停止時間が長くなると、Oracle WebLogic Serverの自動再起動などの追加のエラーが発生し、RTOが増加する可能性があります。予想されるRTOは次のとおりです。 
    RTO = DB DOWNTIME + WEBLOGIC START TIME

スタンバイ・データベースをホストするリージョン全体の障害の管理

障害がリージョン2全体に影響する場合は、フロントエンドのグローバル・バランシング機能によってサイトが不健全とマークされます。

すべてのクライアント・リクエストは、サイト・プリファレンスに関係なく、リージョン1にルーティングされ、リクエストの処理が続行されます。WebLogic JMSおよびJTAサービスは、自動サービス移行をJDBC永続ストアとともに使用すると、サイト1のサーバーに自動的に移行されます。

Oracle SOA Suiteを使用したOracle Fusion Middleware (FMW)の場合、障害の発生したサーバーで自動リカバリ・クラスタ・マスターがホストされていた場合、使用可能なサイトで新しいクラスタ・マスターが発生します。このサーバーは、他のサイトで開始されたSOAインスタンスの自動リカバリを実行します。

停止はプライマリ・データベースに影響しないため、データベース・スイッチオーバーを実行する必要はありません。

次の図は、FMWストレッチ・クラスタ・トポロジにおけるリージョン2全体の障害を示しています。


failure-standby-db-region.pngの説明が続きます
図failations-standby-db-region.pngの説明

障害- スタンバイ-db-region-oracle.zip

障害からのリカバリ
リージョン2での完全な障害からの即時リカバリには、手動による介入は必要ありません。

障害が発生したサイトが再度使用可能になったら、Oracle HTTPサーバーおよびWebLogic管理対象サーバーの障害が発生したホスト内のプロセスを再起動します。

WebLogicの起動を妨げる孤立したファイルが存在しないことを確認してください。

グローバル・ロード・バランサ機能(Oracle Cloud Infrastructure Traffic Managementステアリング・ポリシーまたはグローバル・ロード・バランサ)のおかげで、クライアントのリクエストは2つのサイト間で再度リバランスされます。

予想リカバリ時間目標
グローバル・バランシングにOracle Cloud Infrastructure (OCI)トラフィック・ステアリング・ポリシーを使用する場合、障害のある期間は、ステアリング・ポリシーで定義されたフロントエンド・エントリの存続時間(TTL)より約1分長くなります。

ドメイン・ネーム・システム(DNS)の更新は、ジオロケーション・ステアリング・ポリシーでリージョン2がプリファレンスとして設定されているクライアントに影響します。DNS更新は、ステアリング・ポリシー・プリファレンスが失敗したリージョンに設定されているクライアントに影響します。TTL値は、正常なサイトを指すように更新する前に、これらのクライアントが古いエントリを引き続き使用する期間を決定します。追加の時間(約1分)は、OCIトラフィック管理ステアリング・ポリシーで構成されたヘルス・チェックの頻度とタイムアウトによって異なります(前述のテストでは、ヘルス・チェック間隔に30秒が使用され、タイムアウトは10秒でした)。

グローバル・ロード・バランサ(GLBR)を使用する場合、停止時間は、GLBRで構成されたヘルス・チェックの頻度によって異なります。GLBRがプールを不健全とマークすると、受信リクエストはもう一方のサイトにリダイレクトされます。GLBRではDNS更新がないため、フロントエンド・エントリのTTL値は関係ありません。