33 Oracle Cloudまたはオンプレミスでのサイト全体の切替え

完全サイト障害またはサイト全体の障害が発生すると、アプリケーション層とデータベース層の両方が使用できなくなります。可用性を維持するため、本番データベースの冗長アプリケーション層と同期コピーをホスティングするセカンダリ・サイトに、ユーザーをリダイレクトする必要があります。MAAのベスト・プラクティスは、Data Guardを使用して本番データベースの同期コピーを保持することです。サイト障害が発生すると、WANトラフィック・マネージャまたはロード・バランサを使用してDNSフェイルオーバーが(手動または自動で)実行されて、すべてのユーザーがスタンバイ・サイトのアプリケーション層にリダイレクトされます。その間に、Data Guardフェイルオーバーによってスタンバイ・データベースがプライマリ本番ロールに遷移します。

通常のランタイム操作では、次のことが行われます。

1. クライアント・リクエストは、プライマリ・サイトのクライアント層に入り、WANトラフィック・マネージャによって転送されます。

2. クライアント・リクエストは、アプリケーション・サーバー層に送信されます。

3. リクエストは、アクティブなロード・バランサを介してアプリケーション・サーバーに転送されます。

4. リクエストは、データベース・サーバー層に送信されます。

5. アプリケーション・リクエストは、必要に応じてOracle RACインスタンスにルーティングされます。

6. レスポンスは、同様の経路でアプリケーションとクライアントに戻されます。

次に、サイト・スイッチオーバー前のネットワーク・ルートを示します。

図33-1 スイッチオーバー前のサイト

「図33-1 スイッチオーバー前のサイト」の説明

次のステップでは、サイト・スイッチオーバーの影響について説明します。

1. 管理者は、プライマリ・データベースをセカンダリ・サイトにフェイルオーバーまたはスイッチオーバーします。この操作は、Data Guardファスト・スタート・フェイルオーバーを使用している場合は自動的に処理されます。専用ハードウェア上のAutonomous Databaseは、Data Guardファスト・スタート・フェイルオーバーをサポートしています。

2. 管理者は、セカンダリ・サイトの中間層アプリケーション・サーバーを起動します(実行されていない場合)。障害が発生したサイトに同じ中間層アプリケーション・サーバーが存在する場合、それらを利用できることがあります。

3. セカンダリ・サイトのワイドエリア・トラフィック・マネージャの選択は、サイト全体の障害に対して自動的に行うことができます。

4. セカンダリ・サイトのワイドエリア・トラフィック・マネージャがセカンダリ・サイトのロード・バランサの仮想IPアドレスを返し、後続の再接続でクライアントが自動的に方向付けされます。このシナリオでは、サイト・フェイルオーバーは自動ドメイン・ネーム・システム(DNS)フェイルオーバーによって実行されます。

次の図は、サイト・フェイルオーバー後のネットワーク・ルートを示しています。クライアントまたはアプリケーション・リクエストは、セカンダリ・サイトのクライアント層に入り、プライマリ・サイトと同じ経路をたどります。

図33-2 スイッチオーバー後のサイト

「図33-2 スイッチオーバー後のサイト」の説明

フェイルオーバーは、クライアントのWebブラウザにも依存します。ほとんどのブラウザ・アプリケーションでは、一定期間DNSエントリがキャッシュされます。したがって、停止の発生時に進行中だったセッションは、キャッシュ・タイムアウトの期限切れまでフェイルオーバーされない可能性があります。このようなクライアントでサービスを再開するには、ブラウザを一度終了して再起動します。

リージョン間のロール遷移の実行

次に、Oracle Public Cloudを活用する例を示します。ただし、同様のステップをオンプレミスまたはハイブリッド・クラウドのシナリオで実行できます。

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

フェイルオーバー操作は、プライマリ・サイトが使用できなくなったときに実行され、通常は計画外の操作です。元のプライマリ・データベースで障害が発生し、プライマリ・データベースを適時にリカバリできる可能性がない場合は、スタンバイ・データベースのプライマリ・データベースへのロール・トランジションを実行できます。プライマリ・データベースに障害が発生した時点でプライマリ・データベースとターゲット・スタンバイ・データベースに一貫性があったかどうかによって、データが消失する場合があります。

DR構成で手動フェイルオーバーを実行するには、次のステップに従います。

1. DNS名をスイッチオーバーします。

   システムで使用される名前をホストするDNSサーバーで必要なDNSプッシュを実行するか、クライアントのファイル・ホスト解決を変更して、システムのフロント・エンド・アドレスがsite2のロード・バランサによって使用されるパブリックIPを指すようにします。DNSが外部フロント・エンド解決(OCI DNS、商用DNSなど)に使用されるシナリオでは、適切なAPIを使用して変更をプッシュできます。OCI DNSでこの変更をプッシュする例:

   次に、ordscsdroci.domainexample.comなどのフロント・エンドDNSエントリをサイト1ロード・バランサのパブリックIPアドレス(111.111.111.123など)に更新するOCIクライアント・スクリプトを示します。

   oci dns record rrset update
    --config-file /home/opc/scripts/.oci_ordscsdr/config
    --zone-name-or-id "domainexample.com"
    --domain "ordscsdroci.domainexample.com"
    --rtype "A"
    --items '[{"domain":"ordscsdroci.domainexample.com","rdata":"111.111.111.123","rtype":"A","ttl":60}]'
    --force

2. データベースをフェイルオーバーします。

   Oracle Cloud:

   Oracle Control Planeを使用して、Data Guardスイッチオーバーまたはフェイルオーバー操作を発行します。

   オンプレミス:

   セカンダリ・データベース・ホストのData Guard Brokerを使用してフェイルオーバーを実行します。ユーザーoracleとして:

   [oracle@drdbwlmp1b ~]$ dgmgrl sys/your_sys_password@secondary_db_unqname
   DGMGRL> failover to “secondary_db_unqname”

3. セカンダリ・サイトのサーバーを起動します。

   セカンダリ・アプリケーション・サーバーを再起動します。

スイッチオーバー

スイッチオーバーは、管理者が2つのサイトのロールを元に戻す計画操作です。ロールは、プライマリからスタンバイ、およびスタンバイからプライマリに変更されます。これは手動スイッチオーバーと呼ばれます。手動スイッチオーバーを実行するには、次のステップに従います。

1. 保留中の構成変更を伝播します。

   データベース以外のファイルの場合は、rsyncまたはオブジェクト・ストレージ・サービス(OSS)を使用してセカンダリ・サイトにレプリケートできます。

2. プライマリ・サイトのサーバーを停止します。

   スクリプトを使用して、プライマリ・サイトの管理対象サーバー/中間層を停止します。

3. DNS名をスイッチオーバーします

   システムで使用される名前をホストするDNSサーバーで必要なDNSプッシュを実行するか、クライアントのファイル・ホスト解決を変更して、システムのフロント・エンド・アドレスがサイト2のロード・バランサによって使用されるパブリックIPを指すようにします。DNSが外部フロント・エンド解決(OCI DNS、商用DNSなど)に使用されるシナリオでは、適切なAPIを使用して変更をプッシュできます。

   次の例では、OCI DNSでこの変更をプッシュします。

   OCIクライアント・スクリプトは、フロント・エンドDNSエントリ(ordscsdroci.domainexample.comなど)をsite1ロード・バランサのパブリックIPアドレス(111.111.111.123など)に更新します。

   oci dns record rrset update
    --config-file /home/opc/scripts/.oci_ordscsdr/config
    --zone-name-or-id "domainexample.com"
    --domain "ordscsdroci.domainexample.com"
    --rtype "A"
    --items '[{"domain":"ordscsdroci.domainexample.com","rdata":"111.111.111.123","rtype":"A","ttl":60}]'
    --force

   DNSエントリのTTL値が、スイッチオーバーの有効なRTOに影響することに注意してください。TTLの値が大きい(20分など)と、DNSの変更がクライアントで有効になるのに、それと同じ時間がかかります。TTLの値を小さくすると、この処理は短時間で行われますが、クライアントがDNSをチェックする頻度が高くなるため、オーバーヘッドの原因になる可能性があります。DNSの変更前に、TTLを一時的に小さい値(1分など)に設定することをお薦めします。その後、変更を行い、スイッチオーバーの手順が完了したら、TTLを通常の値に設定しなおします。

4. データベース・スイッチオーバーを実行します。

   Oracle Cloud:

   Oracle Control Planeを使用して、Data Guardスイッチオーバー操作を発行します。

   オンプレミス:

   プライマリ・データベース・ホストのData Guard Brokerを使用してスイッチオーバーを実行します。

   ユーザーoracleとして:

   $ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> switchover to “secondary_db_unqname” 

5. セカンダリ・サイトのサーバーを起動します(新しいプライマリ)。

   セカンダリ管理対象サーバーおよび中間層を再起動します。

サイト全体のスイッチオーバーのベスト・プラクティス

次のベスト・プラクティスを使用することをお薦めします。

• プライマリ・サイトとスタンバイ・サイトで同じ構成を維持します。プライマリ・システムに適用される変更は、セカンダリ・システムでも実行する必要があるため、プライマリ・システムとセカンダリ・システムの両方が同じ構成になります。例: プライマリ・ロード・バランサの変更、オペレーティング・システムへの変更など。

• 定期的なスイッチオーバーを実行して、セカンダリ・サイトの状態を検証します。

• プライマリ・サーバーを停止する前に、停止時間を必要としないスイッチオーバー関連アクティビティを実行します。たとえば、config_replica.shスクリプトに基づくWLS構成レプリケーションには停止時間は必要ないため、プライマリ・システムの稼働中にこれを実行できます。その他の例には、スタンバイ・サイトでの停止ホストの起動があります。

• アプリケーション・サーバーの再起動のために必要な場合は、管理対象サーバー/中間層をパラレルに停止および起動します。

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

• また、OCIロード・バランサは、サーバーが稼働していることを認識し、リクエストの送信を開始するのに時間がかかります。通常は、OCIロード・バランサのヘルス・チェックの頻度に応じて数秒かかります。チェックに使用する間隔を短くするほど、サーバーが稼働していることが早くわかるようになります。ただし、使用間隔が短すぎると注意が必要です。ヘルス・チェックが大量のチェックの場合は、バックエンドが過負荷になる可能性があります。

サイト全体のスイッチオーバーの詳細情報

前のトピックでは、サイト全体のフェイルオーバーを一般的な方法で説明しています。特定のアプリケーションのサイト全体のフェイルオーバーの詳細は、次のソースを参照してください。

• Oracle Cloud Infrastructure MarketplaceのSOA Suiteでの障害時リカバリ
• Oracle Cloud InfrastructureのOracle WebLogic Serverの障害時リカバリ
• フル・スタック障害時リカバリ
• Oracle Cloud Infrastructureフル・スタック障害時リカバリ