geo リストアを使用して、データベースのバックアップからマルチテナント SaaS アプリケーションを復旧するUse geo-restore to recover a multitenant SaaS application from database backups

適用対象: Azure SQL Database

このチュートリアルでは、テナント単位データベース モデルを使用して実装されているマルチテナント SaaS アプリケーションの、完全なディザスター リカバリー シナリオを見ていきます。This tutorial explores a full disaster recovery scenario for a multitenant SaaS application implemented with the database per tenant model. 自動的に保守されている geo 冗長バックアップのカタログおよびテナント データベースを代替復旧リージョンに復元するには、geo リストアを使用します。You use geo-restore to recover the catalog and tenant databases from automatically maintained geo-redundant backups into an alternate recovery region. 停止が解決したら、geo レプリケーションを使用して、変更されたデータベースを元のリージョンに復帰します。After the outage is resolved, you use geo-replication to repatriate changed databases to their original region.

元のリージョンと復旧リージョンを示す図。これら両方のリージョンには、アプリ、カタログ、サーバーとプールの元のイメージまたはミラー イメージ、ストレージへの自動バックアップが含まれています。復旧リージョンには、バックアップの geo レプリケーションが受け入れられており、新しいテナント用のサーバーとプールが存在しています。

geo リストアは、Azure SQL Database 向けの最もコストが低いディザスター リカバリー ソリューションです。Geo-restore is the lowest-cost disaster recovery solution for Azure SQL Database. ただし、geo 冗長バックアップから復元すると、最大 1 時間のデータ損失が発生する可能性があります。However, restoring from geo-redundant backups can result in data loss of up to one hour. 各データベースのサイズによっては、かなりの時間がかかることがあります。It can take considerable time, depending on the size of each database.

注意

geo リストアではなく geo レプリケーションを使用して、可能な限り低い RPO と RTO でアプリケーションを復旧します。Recover applications with the lowest possible RPO and RTO by using geo-replication instead of geo-restore.

このチュートリアルでは、復元ワークフローと復帰ワークフローの両方について説明します。This tutorial explores both restore and repatriation workflows. 学習内容は次のとおりです。You learn how to:

  • データベースとエラスティック プールの構成情報をテナントのカタログに同期する。Sync database and elastic pool configuration info into the tenant catalog.
  • アプリケーション、サーバー、プールが含まれるミラー イメージ環境を復旧リージョンに設定する。Set up a mirror image environment in a recovery region that includes application, servers, and pools.
  • geo リストアを使用してカタログおよびテナント データベースを復旧する。Recover catalog and tenant databases by using geo-restore.
  • 停止が解決したら、geo レプリケーションを使用して、テナント カタログと変更されたテナント データベースを復帰する。Use geo-replication to repatriate the tenant catalog and changed tenant databases after the outage is resolved.
  • 各データベースが復元 (または復帰) されるときにカタログを更新して、各テナントのデータベースのアクティブなコピーの現在の場所を追跡する。Update the catalog as each database is restored (or repatriated) to track the current location of the active copy of each tenant's database.
  • 待機時間を減らすため、アプリケーションとテナント データベースが常に同じ Azure リージョンに併置されるようにする。Ensure that the application and tenant database are always co-located in the same Azure region to reduce latency.

このチュートリアルを開始する前に、次の前提条件を満たしておいてください。Before you start this tutorial, complete the following prerequisites:

geo リストア復旧パターンの概要Introduction to the geo-restore recovery pattern

ディザスター リカバリー (DR) は、コンプライアンス上の理由またはビジネス継続性のため、多くのアプリケーションにとって重要な考慮事項です。Disaster recovery (DR) is an important consideration for many applications, whether for compliance reasons or business continuity. 長時間にわたるサービス停止が発生しても、適切に準備された DR 計画があればビジネスの中断を最小限にできます。If there's a prolonged service outage, a well-prepared DR plan can minimize business disruption. geo リストアに基づく DR 計画では、いくつかの目標を達成する必要があります。A DR plan based on geo-restore must accomplish several goals:

  • テナント データベースの復元に確実に利用できるように、選択した復旧リージョン内に、すべての必要な容量を可能な限り早く確保します。Reserve all needed capacity in the chosen recovery region as quickly as possible to ensure that it's available to restore tenant databases.
  • 元のプールとデータベースの構成を反映するミラー イメージ復旧環境を確立します。Establish a mirror image recovery environment that reflects the original pool and database configuration.
  • 元のリージョンがオンラインに戻った場合に、復元プロセスを途中で取り消すことができるようにします。Allow cancellation of the restore process in mid-flight if the original region comes back online.
  • 新しいテナントのオンボードをできるだけ早く再開できるように、テナントのプロビジョニングをすばやく有効にします。Enable tenant provisioning quickly so new tenant onboarding can restart as soon as possible.
  • テナントが優先順位に従って復元されるように最適化します。Be optimized to restore tenants in priority order.
  • 可能であれば、並列で手順を実行して、できる限り早くテナントがオンラインになるように最適化します。Be optimized to get tenants online as soon as possible by doing steps in parallel where practical.
  • 停止に対する回復力があり、再起動可能かつべき等であるようにします。Be resilient to failure, restartable, and idempotent.
  • 停止が解決したら、テナントに与える影響を最小限に抑えて元のリージョンにデータベースを復帰します。Repatriate databases to their original region with minimal impact to tenants when the outage is resolved.

注意

アプリケーションは、アプリケーションが展開されたリージョンのペア リージョンに復旧されます。The application is recovered into the paired region of the region in which the application is deployed. 詳細については、「Azure のペアになっているリージョン」をご覧ください。For more information, see Azure paired regions.

このチュートリアルでは、Azure SQL Database と Azure プラットフォームの以下の機能を使って、これらの課題に対応します。This tutorial uses features of Azure SQL Database and the Azure platform to address these challenges:

  • Azure Resource Manager テンプレート。すべての必要な容量を可能な限り早く確保します。Azure Resource Manager templates, to reserve all needed capacity as quickly as possible. 復旧リージョン内に元のサーバーとエラスティック プールのミラー イメージをプロビジョニングするために、Azure Resource Manager テンプレートを使用します。Azure Resource Manager templates are used to provision a mirror image of the original servers and elastic pools in the recovery region. 新しいテナントをプロビジョニングするために、別のサーバーとプールも作成されます。A separate server and pool are also created for provisioning new tenants.
  • Elastic Database Client Library (EDCL)。テナント データベース カタログを作成および保守します。Elastic Database Client Library (EDCL), to create and maintain a tenant database catalog. 拡張されたカタログには、定期的に更新されるプールとデータベース構成情報が含まれています。The extended catalog includes periodically refreshed pool and database configuration information.
  • EDCL のシャード管理復旧機能。復旧と復帰の間に、カタログに含まれるデータベースの場所エントリを保守します。Shard management recovery features of the EDCL, to maintain database location entries in the catalog during recovery and repatriation.
  • geo リストア。自動的に保守されている geo 冗長バックアップのカタログおよびテナント データベースを復旧します。Geo-restore, to recover the catalog and tenant databases from automatically maintained geo-redundant backups.
  • テナントの優先順で送信される非同期の復元操作。プールが過負荷にならないように、システムによってプールごとにキューへ格納され、バッチ処理されます。Asynchronous restore operations, sent in tenant-priority order, are queued for each pool by the system and processed in batches so the pool isn't overloaded. これらの操作は、必要に応じて実行前または実行中に取り消すことができます。These operations can be canceled before or during execution if necessary.
  • geo レプリケーション。停止の解決後に元のリージョンにデータベースを復帰します。Geo-replication, to repatriate databases to the original region after the outage. geo レプリケーションを使用すると、データ損失が発生せず、テナントに与える影響が最小限に抑えられます。There is no data loss and minimal impact on the tenant when you use geo-replication.
  • SQL Server の DNS エイリアス。カタログの場所に関係なく、カタログ同期プロセスがアクティブなカタログに接続できるようにします。SQL server DNS aliases, to allow the catalog sync process to connect to the active catalog regardless of its location.

ディザスター リカバリー スクリプトを取得するGet the disaster recovery scripts

このチュートリアルで使用されている DR スクリプトは、Wingtip Tickets SaaS のテナントごとのデータベースの GitHub リポジトリで入手できます。The DR scripts used in this tutorial are available in the Wingtip Tickets SaaS database per tenant GitHub repository. Wingtip Tickets 管理スクリプトをダウンロードしてブロック解除する手順に関する一般的なガイダンスを参照してください。Check out the general guidance for steps to download and unblock the Wingtip Tickets management scripts.

重要

すべての Wingtip Tickets 管理スクリプトと同様に、DR スクリプトはサンプル品質なので、運用環境では使わないでください。Like all the Wingtip Tickets management scripts, the DR scripts are sample quality and are not to be used in production.

アプリケーションの正常性状態を確認するReview the healthy state of the application

復旧プロセスを始める前に、アプリケーションの通常の正常な状態を確認します。Before you start the recovery process, review the normal healthy state of the application.

  1. Web ブラウザーで、Wingtip Tickets イベント ハブ (http://events.wingtip-dpt.<user>.trafficmanager.net、< user> は実際のデプロイでのユーザーの値に置き換えます) を開きます。In your web browser, open the Wingtip Tickets events hub (http://events.wingtip-dpt.<user>.trafficmanager.net, replace <user> with your deployment's user value).

    ページの下部までスクロールし、フッターでカタログ サーバー名と場所を確認します。Scroll to the bottom of the page and notice the catalog server name and location in the footer. 場所は、アプリを展開したリージョンです。The location is the region in which you deployed the app.

    ヒント

    マウス ポインターをその場所に置くと、ディスプレイが拡大表示されます。Hover the mouse over the location to enlarge the display.

    元のリージョンのイベント ハブの正常状態

  2. Contoso Concert Hall テナントを選択して、そのイベント ページを開きます。Select the Contoso Concert Hall tenant and open its event page.

    フッターで、テナントのサーバー名を確認します。In the footer, notice the tenant's server name. 場所は、カタログ サーバーの場所と同じです。The location is the same as the catalog server's location.

    Contoso Concert Hall の元のリージョン

  3. Azure Portal で、アプリが展開されているリソース グループを確認して開きます。In the Azure portal, review and open the resource group in which you deployed the app.

    アプリ サービス コンポーネントと SQL Database がデプロイされているリソースとリージョンを確認します。Notice the resources and the region in which the app service components and SQL Database is deployed.

テナントの構成をカタログに同期するSync the tenant configuration into the catalog

このタスクでは、サーバー、エラスティック プール、およびデータベースの構成をテナント カタログに同期するプロセスを開始します。In this task, you start a process to sync the configuration of the servers, elastic pools, and databases into the tenant catalog. この情報は、復旧リージョンでミラー イメージ環境を構成するために後で使用されます。This information is used later to configure a mirror image environment in the recovery region.

重要

わかりやすくするため、これらのサンプルでは、同期プロセスおよびその他の実行時間の長い復旧プロセスと復帰プロセスは、クライアント ユーザーのログインで実行されるローカル PowerShell ジョブまたはセッションとして実装されています。For simplicity, the sync process and other long-running recovery and repatriation processes are implemented in these samples as local PowerShell jobs or sessions that run under your client user login. ログイン時に発行される認証トークンは、数時間で有効期限が切れ、ジョブは失敗するようになります。The authentication tokens issued when you log in expire after several hours, and the jobs will then fail. 運用のシナリオでは、実行時間の長いプロセスは、サービス プリンシパルで実行される、何らかの信頼性の高い Azure サービスとしてを実装する必要があります。In a production scenario, long-running processes should be implemented as reliable Azure services of some kind, running under a service principal. Azure PowerShell を使用して資格情報でのサービス プリンシパルを作成する」をご覧ください。See Use Azure PowerShell to create a service principal with a certificate.

  1. PowerShell ISE で、...\Learning Modules\UserConfig.psm1 ファイルを開きます。In the PowerShell ISE, open the ...\Learning Modules\UserConfig.psm1 file. 10 行目と 11 行目の <resourcegroup> および <user> は、アプリを展開したときに使った値に置き換えます。Replace <resourcegroup> and <user> on lines 10 and 11 with the value used when you deployed the app. ファイルを保存します。Save the file.

  2. PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 スクリプトを開きます。In the PowerShell ISE, open the ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 script.

    このチュートリアルでは、この PowerShell スクリプトの各シナリオを実行するので、このファイルは開いたまましてください。In this tutorial, you run each of the scenarios in this PowerShell script, so keep this file open.

  3. 次のように設定します。Set the following:

    $DemoScenario = 1:テナント サーバーとプールの構成情報をカタログに同期するバックグラウンド ジョブを開始します。$DemoScenario = 1: Start a background job that syncs tenant server and pool configuration info into the catalog.

  4. F5 キーを選択して、同期スクリプトを実行します。To run the sync script, select F5.

    この情報は、後で復旧リージョンにサーバー、プール、およびデータベースのミラー イメージを作成するために使用されます。This information is used later to ensure that recovery creates a mirror image of the servers, pools, and databases in the recovery region.

    同期プロセス

PowerShell ウィンドウはバックグラウンドで実行させたままにして、チュートリアルの残りの部分を続けます。Leave the PowerShell window running in the background and continue with the rest of this tutorial.

注意

同期プロセスは、DNS エイリアスを使ってカタログに接続します。The sync process connects to the catalog via a DNS alias. このエイリアスは、復元および復帰の間に、アクティブなカタログを指すように変更されます。The alias is modified during restore and repatriation to point to the active catalog. 同期プロセスは、復旧リージョンで行われたデータベースまたはプールの構成の変更を使って、カタログを最新の状態に維持します。The sync process keeps the catalog up to date with any database or pool configuration changes made in the recovery region. 復帰では、これらの変更が元のリージョンの同等のリソースに適用されます。During repatriation, these changes are applied to the equivalent resources in the original region.

geo リストア復旧プロセスの概要Geo-restore recovery process overview

geo リストア復旧プロセスでは、アプリケーションを展開し、バックアップのデータベースを復旧リージョンに復元します。The geo-restore recovery process deploys the application and restores databases from backups into the recovery region.

復旧プロセスでは、次の処理が行われます。The recovery process does the following:

  1. 元のリージョンで Web アプリの Azure Traffic Manager エンドポイントを無効にします。Disables the Azure Traffic Manager endpoint for the web app in the original region. エンドポイントを無効にすることで、復旧の間に元のリージョンがオンラインになったときに、ユーザーが無効な状態のアプリに接続するのを防ぎます。Disabling the endpoint prevents users from connecting to the app in an invalid state should the original region come online during recovery.

  2. 復旧リージョンに復旧カタログ サーバーをプロビジョニングし、カタログ データベースの geo リストアを実行し、復元されたカタログ サーバーを指すように別名 activecatalog を更新します。Provisions a recovery catalog server in the recovery region, geo-restores the catalog database, and updates the activecatalog alias to point to the restored catalog server. カタログの別名を変更すると、カタログ同期プロセスは常にアクティブなカタログに同期されます。Changing the catalog alias ensures that the catalog sync process always syncs to the active catalog.

  3. 復元する前に、復旧カタログの既存のすべてのテナントをオフラインとマークして、テナント データベースにアクセスできないようにします。Marks all existing tenants in the recovery catalog as offline to prevent access to tenant databases before they are restored.

  4. 復旧リージョンにアプリのインスタンスをプロビジョニングし、復旧リージョン内の復元されたカタログを使用するように構成します。Provisions an instance of the app in the recovery region and configures it to use the restored catalog in that region. 待機時間を最小限に抑えるため、サンプル アプリは同じリージョン内のテナント データベースに常に接続するように設計されています。To keep latency to a minimum, the sample app is designed to always connect to a tenant database in the same region.

  5. 新しいテナントがプロビジョニングされるサーバーとエラスティック プールをプロビジョニングします。Provisions a server and elastic pool in which new tenants are provisioned. このようなリソースを作成して、新しいテナントのプロビジョニングが既存のテナントの復旧を妨げないようにします。Creating these resources ensures that provisioning new tenants doesn't interfere with the recovery of existing tenants.

  6. 復旧リージョン内の新しいテナント データベースのサーバーを指すように、新しいテナントの別名を更新します。Updates the new tenant alias to point to the server for new tenant databases in the recovery region. この別名を変更することで、新しいテナントのデータベースが復旧リージョンでプロビジョニングされるようにします。Changing this alias ensures that databases for any new tenants are provisioned in the recovery region.

  7. テナント データベースを復元するために、復旧リージョン内にサーバーとエラスティック プールをプロビジョニングします。Provisions servers and elastic pools in the recovery region for restoring tenant databases. これらのサーバーとプールは、元のリージョン内の構成のミラー イメージです。These servers and pools are a mirror image of the configuration in the original region. プロビジョニング プールは、すべてのデータベースを復元するために必要な容量を事前に確保します。Provisioning pools up front reserves the capacity needed to restore all the databases.

    あるリージョンで停止が発生すると、ペアのリージョンで利用できるリソースに大きな負荷がかかる可能性があります。An outage in a region might place significant pressure on the resources available in the paired region. DR の geo リストアに依存している場合は、迅速にリソースを確保することをお勧めします。If you rely on geo-restore for DR, then reserving resources quickly is recommended. 特定のリージョン内でアプリケーションを復旧することが重要な場合は、geo レプリケーションを検討してください。Consider geo-replication if it's critical that an application is recovered in a specific region.

  8. 復旧リージョンで Web アプリの Traffic Manager エンドポイントを有効にします。Enables the Traffic Manager endpoint for the web app in the recovery region. このエンドポイントを有効にすると、アプリケーションは新しいテナントをプロビジョニングできるようになります。Enabling this endpoint allows the application to provision new tenants. この段階では、既存のテナントはまだオフラインです。At this stage, existing tenants are still offline.

  9. 要求のバッチを送信し、優先順位に従ってデータベースを復元します。Submits batches of requests to restore databases in priority order.

    • バッチは、データベースがすべてのプールに並列に復元されるように編成されています。Batches are organized so that databases are restored in parallel across all pools.

    • 復元要求は非同期に送信されるので、すばやく送信され、実行のキューは各プールに格納されます。Restore requests are submitted asynchronously so they are submitted quickly and queued for execution in each pool.

    • 復元要求はすべてのプールで並列に処理されるので、重要なテナントを多数のプールに分散する場合に適しています。Because restore requests are processed in parallel across all pools, it's better to distribute important tenants across many pools.

  10. サービスを監視して、データベースを復元するタイミングを判断します。Monitors the service to determine when databases are restored. テナント データベースが復元されると、カタログでオンラインとマークされ、テナント データベースの rowversion の合計が記録されます。After a tenant database is restored, it's marked online in the catalog, and a rowversion sum for the tenant database is recorded.

    • テナントがカタログでオンラインとマークされるとすぐに、アプリケーションはテナント データベースにアクセスできるようになります。Tenant databases can be accessed by the application as soon as they're marked online in the catalog.

    • テナント データベースでの rowversion 値の合計が、カタログに格納されます。A sum of rowversion values in the tenant database is stored in the catalog. この合計はフィンガープリントとして機能し、復帰プロセスはこの値を使うことにより、データベースが復旧リージョンで更新されたかどうかを判断できます。This sum acts as a fingerprint that allows the repatriation process to determine if the database was updated in the recovery region.

復旧スクリプトを実行するRun the recovery script

重要

このチュートリアルでは、geo 冗長バックアップからデータベースを復元します。This tutorial restores databases from geo-redundant backups. geo 冗長バックアップは通常 10 分以内に使用できるようになりますが、最大 1 時間かかる場合があります。Although these backups are typically available within 10 minutes, it can take up to an hour. 使用できるようになるまで、スクリプトは一時停止されます。The script pauses until they're available.

アプリケーションが展開されているリージョンで停止が発生したものと想定して、復旧スクリプトを実行します。Imagine there's an outage in the region in which the application is deployed, and run the recovery script:

  1. PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 スクリプトに次の値を設定します。In the PowerShell ISE, in the ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 script, set the following value:

    $DemoScenario = 2:geo 冗長バックアップから復元することで、アプリを復旧リージョンに復旧します。$DemoScenario = 2: Recover the app into a recovery region by restoring from geo-redundant backups.

  2. F5 キーを選択して、スクリプトを実行します。To run the script, select F5.

    • 新しい PowerShell ウィンドウでスクリプトが開き、並列に実行される一連の PowerShell ジョブが開始されます。The script opens in a new PowerShell window and then starts a set of PowerShell jobs that run in parallel. これらのジョブで、サーバー、プール、およびデータベースが復旧リージョンに復元されます。These jobs restore servers, pools, and databases to the recovery region.

    • 復旧リージョンは、アプリケーションを展開した Azure リージョンに関連付けられているペア リージョンです。The recovery region is the paired region associated with the Azure region in which you deployed the application. 詳細については、「Azure のペアになっているリージョン」をご覧ください。For more information, see Azure paired regions.

  3. PowerShell ウィンドウで復旧プロセスの状態を監視します。Monitor the status of the recovery process in the PowerShell window.

    復旧プロセスの状態を監視できる PowerShell ウィンドウを示すスクリーンショット。

注意

復旧ジョブのコードを調べるには、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\RecoveryJobs フォルダーにある PowerShell スクリプトを確認します。To explore the code for the recovery jobs, review the PowerShell scripts in the ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\RecoveryJobs folder.

復旧中にアプリケーションの状態を確認するReview the application state during recovery

Traffic Manager でアプリケーション エンドポイントが無効になっている間は、アプリケーションを使用できません。While the application endpoint is disabled in Traffic Manager, the application is unavailable. カタログが復元され、すべてのテナントはオフラインとマークされます。The catalog is restored, and all the tenants are marked offline. 次に復旧リージョン内のアプリケーション エンドポイントが有効になり、アプリケーションはオンラインに戻ります。The application endpoint in the recovery region is then enabled, and the application is back online. アプリケーションは使用できますが、データベースが復元されるまで、イベント ハブ内のテナントはオフラインと表示されます。Although the application is available, tenants appear offline in the events hub until their databases are restored. オフラインのテナント データベースを処理できるようにアプリケーションを設計することが重要です。It's important to design your application to handle offline tenant databases.

  • カタログ データベースが復旧された後、テナントがオンラインに戻る前に、Web ブラウザーで Wingtip Tickets イベント ハブを更新します。After the catalog database has been recovered but before the tenants are back online, refresh the Wingtip Tickets events hub in your web browser.

    • フッターで、カタログ サーバー名に -recovery というサフィックスが付いていて、復旧リージョンに存在することを確認します。In the footer, notice that the catalog server name now has a -recovery suffix and is located in the recovery region.

    • まだ復元されていないテナントはオフラインとしてマークされていて、選択できないことを確認します。Notice that tenants that are not yet restored are marked as offline and are not selectable.

      復旧プロセス

    • テナントがオフラインの間にテナントのイベント ページを直接開いた場合は、テナントがオフラインであることを示す通知が表示されます。If you open a tenant's events page directly while the tenant is offline, the page displays a tenant offline notification. たとえば、Contoso Concert Hall がオフラインのときに、 http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall を開いてみます。For example, if Contoso Concert Hall is offline, try to open http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall.

      オフライン イベントのページを示すスクリーンショット。

復旧リージョン内に新しいテナントをプロビジョニングするProvision a new tenant in the recovery region

テナント データベースが復元される前であっても、復旧リージョン内に新しいテナントをプロビジョニングできます。Even before tenant databases are restored, you can provision new tenants in the recovery region. 復旧リージョン内にプロビジョニングされた新しいテナント データベースは、復旧されたデータベースに後で復帰されます。New tenant databases provisioned in the recovery region are repatriated with the recovered databases later.

  1. PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 スクリプトを開き、次のプロパティを設定します。In the PowerShell ISE, in the ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 script, set the following property:

    $DemoScenario = 3:復旧リージョン内に新しいテナントをプロビジョニングします。$DemoScenario = 3: Provision a new tenant in the recovery region.

  2. F5 キーを選択して、スクリプトを実行します。To run the script, select F5.

  3. プロビジョニングが終了すると、Hawthorn Hall のイベント ページがブラウザーで開きます。The Hawthorn Hall events page opens in the browser when provisioning finishes.

    Hawthorn Hall データベースが復旧リージョン内にあることを確認します。Notice that the Hawthorn Hall database is located in the recovery region.

    復旧リージョン内にプロビジョニングされている Hawthorn Hall

  4. ブラウザーで、Wingtip Tickets イベント ハブ ページを更新して、Hawthorn Hall が含まれていることを確認します。In the browser, refresh the Wingtip Tickets events hub page to see Hawthorn Hall included.

    他のテナントの復元を待たずに Hawthorn Hall をプロビジョニングした場合、他のテナントはまだオフラインになっている可能性があります。If you provisioned Hawthorn Hall without waiting for the other tenants to restore, other tenants might still be offline.

アプリケーションの復旧された状態を確認するReview the recovered state of the application

復旧プロセスが終了すると、アプリケーションとすべてのテナントは、復旧リージョンで完全に機能するようになります。When the recovery process finishes, the application and all tenants are fully functional in the recovery region.

  1. すべてのテナントが復旧されたことが PowerShell コンソール ウィンドウの表示で示されたら、イベント ハブを更新します。After the display in the PowerShell console window indicates all the tenants are recovered, refresh the events hub.

    新しいテナント Hawthorn Hall も含めて、すべてのテナントがオンラインと表示されます。The tenants all appear online, including the new tenant, Hawthorn Hall.

    イベント ハブの復旧されたテナントと新しいテナント

  2. Contoso Concert Hall をクリックし、イベント ページを開きます。Click on Contoso Concert Hall and open its events page.

    フッターで、復旧リージョンの復旧サーバー上にデータベースがあることを確認します。In the footer, notice that the database is located on the recovery server located in the recovery region.

    復旧リージョン内の Contoso

  3. Azure Portal で、リソース グループの一覧を開きます。In the Azure portal, open the list of resource groups.

    展開したリソース グループに加えて、-recovery というサフィックスが付いた復旧リソース グループが表示されることを確認します。Notice the resource group that you deployed, plus the recovery resource group, with the -recovery suffix. 復旧リソース グループには、復旧プロセスの間に作成されたすべてのリソースと、停止中に作成された新しいリソースが含まれます。The recovery resource group contains all the resources created during the recovery process, plus new resources created during the outage.

  4. 復旧リソース グループを開き、次の項目を確認します。Open the recovery resource group and notice the following items:

    • サフィックス -recovery が付いた、catalog サーバーと tenants1 サーバーの復旧バージョン。The recovery versions of the catalog and tenants1 servers, with the -recovery suffix. これらのサーバー上の復元されたカタログ データベースとテナント データベースはすべて、元のリージョンで使われていた名前のままです。The restored catalog and tenant databases on these servers all have the names used in the original region.

    • tenants2-dpt-<ユーザー>-recovery SQL サーバー。The tenants2-dpt-<user>-recovery SQL server. このサーバーは、停止中の新しいテナントのプロビジョニングに使われます。This server is used for provisioning new tenants during the outage.

    • events-wingtip-dpt-<復旧リージョン>-<ユーザー> という名前の App Service。これは、イベント アプリの復旧インスタンスです。The app service named events-wingtip-dpt-<recoveryregion>-<user>, which is the recovery instance of the events app.

      復旧リージョン内の Contoso リソース

  5. tenants2-dpt-<ユーザー>-recovery SQL サーバーを開きます。Open the tenants2-dpt-<user>-recovery SQL server. データベース hawthornhall とエラスティック プール Pool1 が含まれることを確認します。Notice that it contains the database hawthornhall and the elastic pool Pool1. hawthornhall データベースは、Pool1 エラスティック プール内のエラスティック データベースとして構成されています。The hawthornhall database is configured as an elastic database in the Pool1 elastic pool.

テナントのデータを変更するChange the tenant data

このタスクでは、復元されたテナント データベースの 1 つを更新します。In this task, you update one of the restored tenant databases. 復帰プロセスで、変更された復元済みのデータベースが元のリージョンにコピーされます。The repatriation process copies restored databases that have been changed to the original region.

  1. ブラウザーで、Contoso Concert Hall のイベント一覧を探し、イベントをスクロールして、最後のイベント Seriously Strauss を確認します。In your browser, find the events list for the Contoso Concert Hall, scroll through the events, and notice the last event, Seriously Strauss.

  2. PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 スクリプトに次の値を設定します。In the PowerShell ISE, in the ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 script, set the following value:

    $DemoScenario = 4:復旧リージョン内のテナントからイベントを削除します。$DemoScenario = 4: Delete an event from a tenant in the recovery region.

  3. F5 キーを選択して、スクリプトを実行します。To execute the script, select F5.

  4. Contoso Concert Hall のイベント ページ (http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall) を更新し、イベント Seriously Strauss がないことを確認します。Refresh the Contoso Concert Hall events page (http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall), and notice that the event Seriously Strauss is missing.

チュートリアルのこの時点で、アプリケーションを復旧し、復旧リージョン内で実行しています。At this point in the tutorial, you have recovered the application, which is now running in the recovery region. 新しいテナントは復旧リージョン内にプロビジョニングし、復元されたテナントのいずれかのデータを変更しています。You have provisioned a new tenant in the recovery region and modified data of one of the restored tenants.

注意

このサンプルの他のチュートリアルは、復旧状態のアプリを使用して実行するように設計されていません。Other tutorials in the sample are not designed to run with the app in the recovery state. 他のチュートリアルを調べる場合は、まずアプリケーションを復帰してください。If you want to explore other tutorials, be sure to repatriate the application first.

復帰プロセスの概要Repatriation process overview

復帰プロセスでは、停止が解決した後に、アプリケーションとそのデータベースを元のリージョンに戻します。The repatriation process reverts the application and its databases to its original region after an outage is resolved.

geo リストアの復帰

このプロセスの内容は次のとおりです。The process:

  1. 進行中の復元アクティビティを終了し、未処理または実行中のデータベース復元要求を取り消します。Stops any ongoing restore activity and cancels any outstanding or in-flight database restore requests.

  2. 停止後に変更されていない元のリージョンのテナント データベースを再アクティブ化します。Reactivates in the original region tenant databases that have not been changed since the outage. これらのデータベースには、まだ復旧されていないものと、その後に変更されなかったものが含まれます。These databases include those not recovered yet and those recovered but not changed afterward. 再アクティブ化されたデータベースは、テナントが最後にアクセスしたデータベースとまったく同じです。The reactivated databases are exactly as last accessed by their tenants.

  3. 新しいテナントのサーバーとエラスティック プールのミラー イメージを元のリージョンにプロビジョニングします。Provisions a mirror image of the new tenant's server and elastic pool in the original region. このアクションが完了すると、このサーバーを指すように新しいテナントの別名が更新されます。After this action is complete, the new tenant alias is updated to point to this server. 別名を更新すると、復旧リージョンではなく、元のリージョン内で新しいテナントのオンボードが実行されます。Updating the alias causes new tenant onboarding to occur in the original region instead of the recovery region.

  4. geo レプリケーションを使用して、復旧リージョンから元のリージョンにカタログを移動します。Uses geo-replication to move the catalog to the original region from the recovery region.

  5. 停止中に復旧リージョンに加えられた変更と一致するように、元のリージョンのプール構成を更新します。Updates pool configuration in the original region so it's consistent with changes that were made in the recovery region during the outage.

  6. 停止中に作成された新しいデータベースをホストするために、必要なサーバーとプールを作成します。Creates the required servers and pools to host any new databases created during the outage.

  7. geo レプリケーションを使用して、復元後に更新された復元済みテナント データベースと、停止中にプロビジョニングされたすべての新しいテナント データベースを復帰します。Uses geo-replication to repatriate restored tenant databases that have been updated post-restore and all new tenant databases provisioned during the outage.

  8. 復元プロセス中に復旧リージョン内に作成されたリソースをクリーンアップします。Cleans up resources created in the recovery region during the restore process.

復帰する必要のあるテナント データベース数を制限するために、手順 1 から 3 はすぐに実行されます。To limit the number of tenant databases that need to be repatriated, steps 1 to 3 are done promptly.

手順 4 は、停止中に復旧リージョン内のカタログが変更された場合にのみ実行されます。Step 4 is only done if the catalog in the recovery region has been modified during the outage. 新しいテナントが作成された場合、または復旧リージョン内のいずれかのデータベースまたはプール構成が変更された場合、カタログは更新されます。The catalog is updated if new tenants are created or if any database or pool configuration is changed in the recovery region.

手順 7 で、テナントの中断を最小限に抑え、データが失われないことが重要です。It's important that step 7 causes minimal disruption to tenants and no data is lost. この目標を達成するために、このプロセスでは geo レプリケーションを使用します。To achieve this goal, the process uses geo-replication.

各データベースの geo レプリケーションが実行される前に、元のリージョン内の対応するデータベースは削除されます。Before each database is geo-replicated, the corresponding database in the original region is deleted. 削除後に復旧リージョン内のデータベースの geo レプリケーションが実行され、元のリージョン内にセカンダリ レプリカが作成されます。The database in the recovery region is then geo-replicated, creating a secondary replica in the original region. レプリケーションが完了すると、カタログ内のテナントはオフラインとマークされ、復旧リージョン内のデータベースに対するすべての接続は切断されます。After replication is complete, the tenant is marked offline in the catalog, which breaks any connections to the database in the recovery region. 次にデータベースはフェールオーバーされ、すべての保留中のトランザクションはセカンダリで処理されるので、データは失われません。The database is then failed over, causing any pending transactions to process on the secondary so no data is lost.

フェールオーバー時に、データベース ロールは逆になります。On failover, the database roles are reversed. 元のリージョン内のセカンダリはプライマリ読み取り/書き込みデータベースになり、復旧リージョン内のデータベースは読み取り専用のセカンダリになります。The secondary in the original region becomes the primary read-write database, and the database in the recovery region becomes a read-only secondary. カタログ内のテナント エントリは、元のリージョン内のデータベースを指すように更新され、テナントはオンラインとマークされます。The tenant entry in the catalog is updated to reference the database in the original region, and the tenant is marked online. この時点でデータベースの復帰は完了です。At this point, repatriation of the database is complete.

接続が切断されたときに自動的に再接続するように、再試行ロジックを使用してアプリケーションを作成する必要があります。Applications should be written with retry logic to ensure that they reconnect automatically when connections are broken. 接続を仲介するカタログを使用すると、元のリージョン内の復帰したデータベースに接続されます。When they use the catalog to broker the reconnection, they connect to the repatriated database in the original region. 通常、この短い切断が認識されることはありませんが、データベースの復帰は勤務時間外に行うのがよいかもしれません。Although the brief disconnect is often not noticed, you might choose to repatriate databases out of business hours.

データベースが復帰したら、復旧リージョン内のセカンダリ データベースを削除できます。After a database is repatriated, the secondary database in the recovery region can be deleted. 元のリージョン内のデータベースは、DR 保護のために geo リストアに再び依存するようになります。The database in the original region then relies again on geo-restore for DR protection.

手順 8 では、復旧サーバーとプールを含む復旧リージョン内のリソースが削除されます。In step 8, resources in the recovery region, including the recovery servers and pools, are deleted.

復帰スクリプトを実行するRun the repatriation script

停止が解決したものとして、復帰スクリプトを実行します。Let's imagine the outage is resolved and run the repatriation script.

このチュートリアルに従っている場合、Fabrikam Jazz Club と Dogwood Dojo は変更されていないため、元のリージョン内ですぐに再アクティブ化されます。If you've followed the tutorial, the script immediately reactivates Fabrikam Jazz Club and Dogwood Dojo in the original region because they're unchanged. 次に、新しいテナントの Hawthorn Hall と、Contoso Concert Hall (変更されているため) が復帰されます。It then repatriates the new tenant, Hawthorn Hall, and Contoso Concert Hall because it has been modified. このスクリプトでは、Hawthorn Hall がプロビジョニングされたときに更新されたカタログも復帰されます。The script also repatriates the catalog, which was updated when Hawthorn Hall was provisioned.

  1. PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 で、この PowerShell インスタンスでカタログ同期プロセスがまだ実行されていることを確認します。In the PowerShell ISE, in the ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 script, verify that the Catalog Sync process is still running in its PowerShell instance. 必要な場合は、次のように設定して再起動します。If necessary, restart it by setting:

    $DemoScenario = 1:テナント サーバー、プール、およびデータベースの構成情報のカタログへの同期を開始します。$DemoScenario = 1: Start synchronizing tenant server, pool, and database configuration info into the catalog.

    F5 キーを選択して、スクリプトを実行します。To run the script, select F5.

  2. 復帰プロセスを開始するには、次のように設定します。Then to start the repatriation process, set:

    $DemoScenario = 5:アプリを元のリージョンに復帰します。$DemoScenario = 5: Repatriate the app into its original region.

    F5 キーを選択して、新しい PowerShell ウィンドウで復旧スクリプトを実行します。To run the recovery script in a new PowerShell window, select F5. 復帰には数分かかり、PowerShell ウィンドウで監視できます。Repatriation takes several minutes and can be monitored in the PowerShell window.

  3. スクリプトが実行している間に、イベント ハブのページ (http://events.wingtip-dpt.<user>.trafficmanager.net) を更新します。While the script is running, refresh the events hub page (http://events.wingtip-dpt.<user>.trafficmanager.net).

    すべてのテナントがオンラインであり、このプロセス全体を通じてアクセスできることを確認します。Notice that all the tenants are online and accessible throughout this process.

  4. Fabrikam Jazz Club を選択して開きます。Select the Fabrikam Jazz Club to open it. このテナントを変更しなかった場合は、フッターで、サーバーが元のサーバーに戻っていることを確認します。If you didn't modify this tenant, notice from the footer that the server is already reverted to the original server.

  5. Contoso Concert Hall のイベント ページを開くか、更新します。Open or refresh the Contoso Concert Hall events page. 最初にフッターで、データベースがまだ -recovery サーバー上にあることを確認します。Notice from the footer that, initially, the database is still on the -recovery server.

  6. 復帰プロセスが終了したら、Contoso Concert Hall のイベント ページを更新し、データベースが元のリージョン内にあることを確認します。Refresh the Contoso Concert Hall events page when the repatriation process finishes, and notice that the database is now in your original region.

  7. イベント ハブをもう一度更新し、Hawthorn Hall を開きます。Refresh the events hub again and open Hawthorn Hall. そのデータベースも元のリージョン内にあることを確認します。Notice that its database is also located in the original region.

復帰後に復旧リージョンのリソースをクリーンアップするClean up recovery region resources after repatriation

復帰が完了したら、復旧リージョン内のリソースを削除することができます。After repatriation is complete, it's safe to delete the resources in the recovery region.

重要

これらのリソースは、関連するすべての課金を止めるためにすぐに削除します。Delete these resources promptly to stop all billing for them.

復元プロセスで、復旧リソース グループ内にすべての復旧リソースが作成されます。The restore process creates all the recovery resources in a recovery resource group. クリーンアップ プロセスで、このリソース グループは削除され、カタログからリソースへのすべての参照が削除されます。The cleanup process deletes this resource group and removes all references to the resources from the catalog.

  1. PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 スクリプトに、次のように設定します。In the PowerShell ISE, in the ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 script, set:

    $DemoScenario = 6:復旧リージョンから、古いリソースを削除します。$DemoScenario = 6: Delete obsolete resources from the recovery region.

  2. F5 キーを選択して、スクリプトを実行します。To run the script, select F5.

スクリプトをクリーンアップすると、アプリケーションは開始された場所に戻ります。After cleaning up the scripts, the application is back where it started. この時点で、スクリプトをもう一度実行するか、他のチュートリアルを試すことができます。At this point, you can run the script again or try out other tutorials.

アプリとデータベースが併置されるようにアプリケーションを設計するDesigning the application to ensure that the app and the database are co-located

このアプリケーションは、テナントのデータベースと同じリージョン内のインスタンスから常に接続するように設計されています。The application is designed to always connect from an instance in the same region as the tenant's database. このように設計すると、アプリケーションとデータベースの間の待機時間が減少します。This design reduces latency between the application and the database. この最適化では、データベースとアプリの間の対話の方が、ユーザーとアプリの間の対話より頻繁に行われるものと想定されています。This optimization assumes the app-to-database interaction is chattier than the user-to-app interaction.

復帰の過程で、しばらくの間、テナント データベースが復旧リージョンと元のリージョンに分散することがあります。Tenant databases might be spread across recovery and original regions for some time during repatriation. データベースごとに、アプリはテナント サーバーの名前で DNS 参照を行って、データベースが存在するリージョンを調べます。For each database, the app looks up the region in which the database is located by doing a DNS lookup on the tenant server name. サーバー名は別名です。The server name is an alias. 別名のサーバー名には、リージョンの名前が含まれています。The aliased server name contains the region name. アプリケーションとデータベースのリージョンが異なる場合、アプリケーションはサーバーと同じリージョン内のインスタンスにリダイレクトします。If the application isn't in the same region as the database, it redirects to the instance in the same region as the server. データベースと同じリージョン内のインスタンスにリダイレクトすることで、アプリとデータベース間の待機時間を最小限に抑えられます。Redirecting to the instance in the same region as the database minimizes latency between the app and the database.

次のステップNext steps

このチュートリアルでは、以下の内容を学習しました。In this tutorial, you learned how to:

  • テナント カタログを使用して定期的に更新された構成情報を保持し、別のリージョン内にミラー イメージの復旧環境を作成できるようにする。Use the tenant catalog to hold periodically refreshed configuration information, which allows a mirror image recovery environment to be created in another region.
  • geo リストアを使用してデータベースを復旧リージョンに復旧する。Recover databases into the recovery region by using geo-restore.
  • 復元されたテナント データベースの場所を反映するようにテナント カタログを更新する。Update the tenant catalog to reflect restored tenant database locations.
  • DNS エイリアスを使用して、再構成することなくアプリケーションをテナント カタログに接続できるようにする。Use a DNS alias to enable an application to connect to the tenant catalog throughout without reconfiguration.
  • 停止が解決した後に、geo レプリケーションを使用して、復旧したデータベースを元のリージョンに復帰する。Use geo-replication to repatriate recovered databases to their original region after an outage is resolved.

チュートリアル「データベースの geo レプリケーションを使用したマルチテナント SaaS アプリケーションのディザスター リカバリー」を試して、geo レプリケーションを使用して大規模なマルチテナント アプリケーションを復旧するために必要な時間を大幅に短縮する方法を学んでください。Try the Disaster recovery for a multitenant SaaS application using database geo-replication tutorial to learn how to use geo-replication to dramatically reduce the time needed to recover a large-scale multitenant application.

その他のリソースAdditional resources

Wingtip SaaS アプリケーションに基づく作業のための追加のチュートリアルAdditional tutorials that build upon the Wingtip SaaS application