4 スイッチオーバー操作、スイッチバック操作およびフェイルオーバー操作の管理

Oracle Fusion Middlewareディザスタ・リカバリ・トポロジのスイッチオーバー、スイッチバックおよびフェイルオーバーを実行する方法を学習します。

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

スイッチオーバーの実行

スイッチオーバーとは、セカンダリ・サイトを本番ロールとして設定する計画済の操作です。

本番サイトを停止して(メンテナンスを実行する場合など)、現在のセカンダリ・サイトを本番サイトにすることを計画している場合に、この操作が必要になります。

スイッチオーバー操作を実行するには:

1. 本番サイトで実行中のプロセスを停止します。これらには、Oracle Fusion Middlewareインスタンスと、アプリケーション層およびWeb層のその他のプロセスが含まれます。
2. 本番サイトの共有ストレージとセカンダリ・サイトの共有ストレージの間のレプリケーションを停止します。共有ストレージ・レプリケーションを使用している場合は、レプリケーションを一時停止します。rsyncを使用して構成を定期的に更新するようにジョブをスケジュールしている場合は、必ずジョブを停止するか、レプリケーション期間をスケジュールして、計画済のスイッチオーバーを妨げないようにしてください。
3. ストレージ・レプリケーションを使用している場合は、現在の本番サイトで中間層のアーティファクトがある共有ストレージ・ボリュームをアンマウントし、新しい本番サイトとなる現在のセカンダリ・サイトで対応するボリュームをマウントします。
4. Oracle Data Guardを使用して、データベースをスイッチオーバーします。
5. セカンダリ・サイトのホストで、すべてのプロセスを手動で開始します。これらには、Oracle Fusion Middlewareインスタンスと、アプリケーション層およびWeb層のその他のプロセスが含まれます。
6. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがセカンダリ・サイトにルーティングされるようにします。「ワイド・エリアDNSの操作」の項を参照してください。
7. ブラウザ・クライアントを使用してスイッチオーバー後のテストを実行し、リクエストが解決されてセカンダリ・サイトにリダイレクトされていることを確認します。

   これで、元のセカンダリ・サイトが新しい本番サイトになり、元の本番サイトが新しいセカンダリ・サイトになりました。

8. 2つのサイト間のレプリケーションを再確立します。ただし、スナップショットまたはrsyncのコピーが逆方向に(現在の本番サイトから現在のセカンダリ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法を学習するには、ご使用の共有ストレージのドキュメントを参照してください。

これで、前のセカンダリ・サイトが新しい本番サイトになり、元の本番サイトでメンテナンスを実行できるようになりました。元の本番サイトのメンテナンスを実行した後、そのサイトを本番サイトとしてもセカンダリ・サイトとしても使用できます。

元の本番サイトを本番サイトとして使用するには、「スイッチバックの実行」の説明に従って、スイッチバックを実行します。

スイッチバックの実行

スイッチバック操作は、現在の本番サイトとセカンダリ・サイトのロールを元に戻します。

スイッチバック操作を実行するには:

1. 現在の本番サイトで実行中のプロセスを停止します。これらには、Oracle Fusion Middlewareインスタンスと、アプリケーション層およびWeb層のその他のプロセスが含まれます。
2. 本番サイトの共有ストレージとセカンダリ・サイトの共有ストレージの間のレプリケーションを停止します。共有ストレージ・レプリケーションを使用している場合は、レプリケーションを一時停止します。rsyncを使用して構成を定期的に更新するようにジョブをスケジュールしている場合は、必ずジョブを停止するか、レプリケーション期間をスケジュールして、計画済のスイッチバックを妨げないようにしてください。
3. ストレージ・レプリケーションを使用している場合は、現在の本番サイトで中間層のアーティファクトがある共有ストレージ・ボリュームをアンマウントし、新しい本番サイトとなる現在のセカンダリ・サイトで対応するボリュームをマウントします。
4. Oracle Data Guardを使用して、データベースをスイッチバックします。
5. 新しい本番サイトのホストで、すべてのプロセスを手動で開始します。これらには、Oracle Fusion Middlewareインスタンスと、アプリケーション層およびWeb層のその他のプロセスが含まれます。
6. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがセカンダリ・サイトにルーティングされるようにします。「ワイド・エリアDNSの操作」の項を参照してください。
7. ブラウザ・クライアントを使用してスイッチバック後のテストを実行し、リクエストが解決されて新しい本番サイトにリダイレクトされていることを確認します。

   これで、元のセカンダリ・サイトが新しい本番サイトになり、元の本番サイトが新しいセカンダリ・サイトになりました。

8. 2つのサイト間のレプリケーションを再確立します。ただし、スナップショット・コピーが逆方向に(新しい本番サイトから新しいセカンダリ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法を学習するには、ご使用の共有ストレージのドキュメントを参照してください。

フェイルオーバーの実行

フェイルオーバー操作は、本番サイトが使用できなくなった場合に、セカンダリ・サイトを本番ロールとして設定します。これは、プライマリ・サイトにアクセスできなくなったため、プライマリのサーバーおよびストレージを管理できず、セカンダリの操作によってのみ変更が可能な場合の計画外の操作です。

フェイルオーバー操作を実行するには:

1. 本番サイトの共有ストレージとセカンダリ・サイトの共有ストレージの間のレプリケーションを停止します(共有ストレージは、セカンダリ・サイトにも制御モジュールを必要とします)。
2. 共有ストレージ・レプリケーションを使用している場合は、新しい本番サイトとなる現在のセカンダリ・サイトで、中間層のアーティファクトがある共有ストレージ・ボリュームをマウントします。
3. セカンダリ・サイトから、Oracle Data Guard Broker (dgrmgrl)を使用してデータベースをフェイルオーバーします。
4. セカンダリ・サイトのホストで、すべてのプロセスを手動で開始します。これらには、Oracle Fusion Middlewareインスタンスと、アプリケーション層およびWeb層のその他のプロセスが含まれます。
5. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがセカンダリ・サイトにルーティングされるようにします。「ワイド・エリアDNSの操作」の項を参照してください。
6. ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されて本番サイトにリダイレクトされていることを確認します。

   これで、セカンダリ・サイトが新しい本番サイトになりました。元の本番サイトが使用できなくなった原因を調べることができます。

7. プライマリ・サイトにアクセスできるようになったら、元の本番サイトを新しいセカンダリ・サイトとして使用できます。2つのサイト間のレプリケーションを再確立する必要があります。ただし、スナップショット・コピーが逆方向に(現在の本番サイトから現在のセカンダリ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法を学習するには、ご使用の共有ストレージのドキュメントを参照してください。
8. プライマリでの停止のタイプと期間によっては、元のプライマリ・システムのデータベースでOracle Data Guardを回復して再構成する必要がある場合があります。様々なフェイルオーバー状況と障害が発生したプライマリの回復方法の詳細は、Oracle Data GuardのドキュメントとHow To Reinstate Failed Primary Database into Physical Standby (ドキュメントID 738642.1)を参照してください。

元の本番サイトを本番サイトとして再度使用するには、「スイッチバックの実行」の説明に従って、スイッチバックを実行します。

ワイド・エリアDNSの操作

サイトのスイッチオーバーまたはフェイルオーバーを実行した場合、クライアント・リクエストは、現在プライマリ・ロールとして機能している新しいサイトに透過的にリダイレクトされる必要があります。

このリダイレクションを実行するには、グローバル・ロード・バランサを使用するか、DNS名を手動で変更します。

グローバル・ロード・バランサの使用

グローバル・ロード・バランサを本番サイトとセカンダリ・サイトの前面にデプロイすると、両方のサイトについて、障害検出サービスとパフォーマンスベースのルーティング・リダイレクションが提供されます。

さらに、このロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。

通常の操作時には、本番サイトのロード・バランサの名前とIPのマッピングを使用してグローバル・ロード・バランサを構成できます。DNSスイッチオーバーが必要な場合は、グローバル・ロード・バランサのこのマッピングを変更して、セカンダリ・サイトのロード・バランサのIPにマップします。これにより、本番ロールを引き継いだセカンダリ・サイトにリクエストが送信されるようになります。

DNSスイッチオーバーを使用するこの方法は、サイトのスイッチオーバーおよびフェイルオーバーとして機能します。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です。

DNS名の手動変更

DNSスイッチオーバーでは、本番サイトのロード・バランサの名前とIPのマッピングを手動で変更します。

マッピングはセカンダリ・サイトのロード・バランサのIPアドレスにマップするように変更します。スイッチオーバーを実行する手順は次のとおりです。

1. 本番サイトのロード・バランサ・マッピングの現在の存続時間(TTL)値を書き留めます。このマッピングはDNSキャッシュ内にあり、TTLが経過するまでそこに保持されます。例として、TTLが3600秒であるとします。
2. TTL値を短い間隔に変更します。たとえば、60秒です。
3. 元のTTLの間隔が1回経過するまで待ちます。これは、ステップ1で書き留めた元のTTL値である3600秒です。
4. セカンダリ・サイトがリクエストを受信するようにスイッチオーバーされていることを確認します。
5. セカンダリ・サイトのロード・バランサを解決するようにDNSマッピングを変更します。これで通常の操作に適したTTL値が得られます。たとえば、3600秒です。

DNSスイッチオーバーを使用するこの方法は、スイッチオーバー操作またはフェイルオーバー操作として機能します。ステップ2で設定するTTL値は、その時間内にクライアント・リクエストを十分に処理できないような値にする必要があります。TTLを変更する場合、実質的には、アドレス解決のキャッシュ・セマンティックを長い時間から短い時間に変更することになります。キャッシュ時間が短くなるため、DNSリクエストが増加する可能性があります。

FMWエンドポイントを指すクライアントがJavaを実行している場合、別のTTLプロパティを考慮に入れることができます。正常なDNS解決をキャッシュするように、JavaでDNSキャッシュを構成します。その場合、Javaが再起動されるまで、DNSサーバーの変更はリフレッシュされません。プロパティnetworkaddress.cache.ttlを低い値に設定することにより、これを変更できます。

• JAVA_HOME/jre/lib/security/java.securityファイルのプロパティ(:networkaddress.cache.ttl=60)を変更することにより、JVMで実行しているすべてのアプリケーションに対してグローバルに行うことができます。

• アプリケーションの初期化コードのプロパティ(java.security.Security.setProperty("networkaddress.cache.ttl" , "60"))を設定することにより、特定のアプリケーションに対してのみ定義できます。

または、グローバル・ロード・バランサおよびDNSプロバイダ・レコードの更新の場合、Oracle Cloud Infrastructureのアプリケーション・ファイアウォールなど、いくつかのクラウドWebアプリケーション・ファイアウォール・サービスには、単一のフロントエンドDNS名(CNAME)を複数のバックエンドIPにマップする方法が用意されています(DRトポロジでは、これらはプライマリおよびセカンダリ内のロード・バランサのIPになります)。適切なエッジ・ポリシーが各リージョンのロード・バランサIPを指している場合、これは、スイッチオーバーが発生したときにプライマリからセカンダリへリクエストをフェイルオーバーする効果的なグローバル・ロード・バランサとして機能します。この代替手段を使用する場合は、WAF製品固有のドキュメントを参照してください。

予想されるRTOとRPO

このセクションでは、停止中に予想されるRTOとRPOについて説明します。

予想されるRTO

リカバリ時間目標(RTO)は、停止が発生した場合に特定のシステムで許容される最大停止時間を示します。フェイルオーバーによって発生する停止時間は、通常、システムに影響するクリティカルな問題によって発生する計画外のイベントであるため、複数の「制御不能な」要因に依存します。ただし、計画済のスイッチオーバー・イベントに必要な停止時間を測定することは可能です。

次の表は、SOA、OSB、B2B、WSMおよびESSクラスタを含むサンプルのOracle FMW SOA 14.1.2 EDGシステムにおける各スイッチオーバー・ステップの一般的な所要時間を示しています。例にあげているこれらの特定のシステムでは、4つのCPUと48GBのメモリーを搭載したホストが使用されており、SOAサーバーの最大ヒープは8GBです。WLSサーバーは、様々なSOA Suiteコンポーネントの接続プールでデフォルトの構成を使用します。さらに、このサンプルSOAシステムには、様々なタイプのコンポーネント(BPEL、MEDIATOR、EDNなど)用のコンポジットが数十個含まれています。

ステップ番号	スイッチオーバー・ステップ	FMW SOA EDGでのサンプル時間
1	スイッチオーバー前のタスク	これによって停止時間は発生しません。
停止時間開始…
2	プライマリ・サイトのサーバーの停止
	2.1 管理対象サーバーの停止	約30秒(強制)/約2分(正常)
	2.2 管理サーバーの停止	約8秒(強制)/約2分(正常)
3	DNS名のスイッチオーバー	これは顧客固有です。たとえば、OCI DNSを使用する場合、30秒まで短縮できますが、使用されるDNSプロバイダによっては何時間もかかることがあります。 これは、残りのステップと並行して実行できます。
4	データベースのスイッチオーバー	約3分
5	セカンダリ・サイトのサーバーの起動
	管理の起動	約6分(共有ストレージ上のドメイン)
	5.2 管理対象サーバーの起動(パラレル)	約2分
合計停止時間 約15分

ステップ間の自然な遅延やその他の追加の検証は、前述の時間には含まれません。スイッチオーバー・ステップの実行方法(たとえば、手動、カスタム・スクリプトによる自動化、オーケストレーション・カスタム・ツールの使用など)によって変わるためです。したがって、言うまでもないことですが、合計時間を考えるときには個々の時間を単に合算するのではなく、追加の時間を見込んでおく必要があります。DNSスイッチオーバーの時間も顧客固有であるため除外されます。

通常、スイッチオーバーの合計時間は15分から30分の範囲に収まるものと予想されます。スイッチオーバー操作時に停止時間を最小限に抑えるためのヒントを次に示します。

• プライマリ・サーバーを停止する前に、停止時間を必要としないスイッチオーバー関連アクティビティを実行します。たとえば、rsyncレプリケーションに基づくWebLogic構成レプリケーションは停止時間を必要としないため、プライマリ・システムの稼働中に実行できます。もう1つの例として、停止したホストや依存リソースをセカンダリ・サイトで起動します。

• 可能であれば、管理対象サーバーの停止と管理サーバーの停止を並行して行います。

• アプリケーションおよびビジネスで可能であれば、強制停止を使用してWebLogic Serverを停止します。

• WebLogic Serverの停止に要する最大時間は、「サーバー・ライフサイクル・タイムアウト」パラメータ(通常は30秒に設定)と「正常な停止」パラメータ(通常は120秒に設定)によって制限されます。これらのパラメータが最大停止時間を制限するように構成されていることを確認してください。

• DNSのフロントエンド更新は顧客に依存します。適切なDNSエントリで(少なくともスイッチオーバー操作中に)小さいTTL値を使用して、更新の時間を短縮します。スイッチオーバーが終了すると、TTLを元の値に戻すことができます。

• Data Guard Brokerのコマンド(dgmgrl)を使用してデータベースのスイッチオーバーを行う方が、Enterprise Managerやエージェントベースのその他のオーケストレータを使用する場合よりも高速です。

• ロード・バランサがOHSサーバーおよびWebLogic Serverにリクエストを送信し始める前に、それらが稼働していることに認識するのにもしばらく時間がかかります。LBRヘルス・チェックの頻度にもよりますが、通常は数秒です。チェックに使用される間隔をあらかじめ短くしておき、スイッチオーバー後に元に戻してください。ごく短いヘルスチェック間隔を使用する場合は、バックエンドに過剰な負荷がかかる可能性があるため、注意が必要です。

予想されるRPO

リカバリ・ポイント目標(RPO)は、許容できるデータ損失の最大量を示します。たとえば、Oracle FMW SOAの場合は、特にトランザクション・ログ、JMSメッセージおよびSOAインスタンス情報に関連しており、そのすべてが同じデータベースに存在します。データベースとWebLogic構成は異なるメカニズムでレプリケートされることから、ランタイム・データのRPOとWebLogic構成のRPOは別々のものと考えられます。

ランタイム・データ(コンポジット・インスタンス、JMSメッセージ、TLog、顧客データなど)はデータベースに格納されるため、ランタイム・データに対して実際に実現可能なRPOはデータベースのRPOに依存します。ランタイム・アーティファクトがファイル・システムに格納されることもあります(ファイル・アダプタやftpアダプタによって使用されるファイルなど)。したがって、ランタイム・データのRPOは次の要因によって決まります。

1. プライマリとスタンバイの間の利用可能なネットワーク帯域幅とネットワークの信頼性。プライマリとセカンダリの間では、帯域幅、レイテンシおよびジッターの点で一貫したパフォーマンスを提供する接続を使用してください。上に示したようなサンプル・システムでは、約5分のRPOを期待できます。最適な動作を実現するために、ファスト・スタート・フェイルオーバー・オブザーバの手動構成は終了し、データベースが必要になる場合があります。ファスト・スタート・フェイルオーバーの詳細は、Oracle DBのドキュメントを参照してください。

2. 使用されるData Guard保護モード。最大可用性、最大保護、最大パフォーマンス(デフォルト)という3つの異なるモードがあります。

   • 最大可用性モードは、特定の二重障害の場合(スタンバイ・データベースの障害が発生した後にプライマリ・データベースの障害が発生した場合など)を除いて、データ消失がないことを保証します。

   • 最大パフォーマンス・モードは、最大可用性モードに比べてデータ保護が若干弱く、プライマリ・データベースのパフォーマンスへの影響を最小限に抑えます。

   • 最大保護モードは、プライマリ・データベースに障害が発生した場合でも、データ消失がないことを保証します。データの消失が起こり得ないようにするため、1つ以上の同期スタンバイ・データベースにREDOストリームを書き込めない場合、プライマリ・データベースは停止し、トランザクション処理を継続しません。

     どのData Guard保護モードを選択するかは、ビジネス要件によって決まります。場合によっては、状況に関係なくデータの消失が許されないビジネスがあります。また、起こりそうにない多重障害の場合に起こりうるデータの消失よりデータベースの可用性の方が重要な場合もあります。アプリケーションの中には、常に最大のデータベース・パフォーマンスが必要であるため、コンポーネントに障害が発生した場合に少量のデータの消失ならば許容できるものがあります。詳細は、Oracle Data Guard管理ドキュメントのOracle Data Guardの保護モードに関する項を参照してください。

3. また、データベースに存在しないランタイム・アーティファクトがファイル・システムに格納されている場合(MFTまたはファイル/FTPアダプタによって消費または生成されるファイルがカスタム・ファイル・ストレージ・サービスに格納されているなど)、このデータのRPOは、セカンダリの場所への同期頻度によって異なります。このコンテンツの何をどのようにいつ同期するかは、ビジネス・ニーズによって決まります。たとえば、これらのランタイム・ファイルが非常に変化しやすい(作成/消費のスピードが速い)場合、同期の必要はなく、同期するのはやり過ぎになる可能性があります。ただし、コンテンツがより静的で、DRイベントに備えてセカンダリに保持しておく必要がある場合、コンテンツをコピーする頻度はシステムの予想されるRPOに従ってください。RPOは、このコンテンツのレプリケーションの合間に生成されるデータの量になります。

   または、これらのランタイム・ファイルをDBFSファイル・システムに配置することもできます。その場合、基礎となるData Guardレプリカを介してスタンバイにレプリケートされるため、RPOはData Guard保護モードによって提供されます。

WebLogic構成の実際に実現可能なRPOは、次の要因によって決まります。

1. WebLogic構成が変更される頻度。

   WebLogic構成は、ランタイム・データほど動的に変更されません。システムの初期段階にもかかわらず、絶えず構成変更を行うことは一般的ではありません。構成が変更される頻度が高ければ高いほど、障害イベントで失われる構成変更の量は大きくなる可能性があります。

2. WebLogic構成がスタンバイに同期される頻度。

   共有ストレージ・レプリケーション方式とDBFSレプリケーション方式を使用する場合、WebLogic構成は手動で、またはcronジョブによってレプリケートできます。1つの方法として、プライマリで実行されるすべての構成変更の後に構成をレプリケートします。この場合、セカンダリのWebLogic構成は常にプライマリと一致した最新の状態になりますが、プライマリに対して実行されるすべての変更にレプリケーション・プロセスを含める必要があります。もう1つの方法として、レプリケーションを定期的に(たとえば毎晩)スケジュールします。この場合、停止イベントが発生すると、最後のレプリケーションの後にプライマリで適用された構成変更は失われます。

3. WebLogic構成レプリケーションに使用される手順の信頼性。

   どのレプリケーション方式も信頼できますが、基礎となるインフラストラクチャの障害(ステージング・フォルダが使用できない、接続が停止したなど)がRPOに影響を与える可能性があります。したがって、レプリケーション手順が正しく機能することを確認し、セカンダリ・サイトの定期的な検証を実行することをお薦めします。