SQL Server のためにディザスター リカバリーを設定する

この記事では、アプリケーションの SQL Server バックエンドを保護する方法について説明します。 そのためには、SQL Server のビジネス継続性とディザスター リカバリー (BCDR) テクノロジと Azure Site Recovery の組み合わせを使用します。

開始する前に、SQL Server のディザスター リカバリー機能を理解していることを確認してください。 次のような機能があります。

  • フェールオーバー クラスタリング
  • Always On 可用性グループ
  • データベース ミラーリング
  • ログ配布
  • アクティブな地理的レプリケーション
  • 自動フェールオーバー グループ

BCDR テクノロジと Site Recovery の組み合わせ

SQL Server インスタンスを復旧するための BCDR テクノロジの選択は、次の表で説明されている目標復旧時間 (RTO) と目標復旧時点 (RPO) のニーズに基づいている必要があります。 Site Recovery と選択したテクノロジのフェールオーバー操作を組み合わせて、アプリケーション全体の復旧を調整します。

デプロイの種類 BCDR テクノロジ SQL Server の予測される RTO SQL Server の予測される RPO
Azure IaaS (サービスとしてのインフラストラクチャ) 仮想マシン (VM) 上またはオンプレミスの SQL Server。 Always On 可用性グループ セカンダリ レプリカをプライマリにするためにかかる時間。 セカンダリ レプリカへのレプリケーションは非同期であるため、一部のデータが失われます。
Azure IaaS VM 上またはオンプレミスの SQL Server。 フェールオーバー クラスタリング (Always On FCI) ノード間でフェールオーバーするためにかかる時間。 Always On FCI は共有ストレージを使用するため、ストレージ インスタンスの同じビューをフェールオーバー時に使用できます。
Azure IaaS VM 上またはオンプレミスの SQL Server。 データベース ミラーリング (高パフォーマンス モード) サービスを強制するためにかかる時間。この場合、ミラー サーバーがウォーム スタンバイ サーバーとして使用されます。 レプリケーションは非同期です。 ミラー データベースは、プリンシパル データベースよりやや遅れることがあります。 この遅れは通常、短時間です。 ただし、プリンシパルまたはミラー サーバーのシステムの負荷が高い場合は長くなることがあります。

ログ配布がデータベース ミラーリングの補足になる場合があります。 これは、非同期データベース ミラーリングの適切な代替手段になります。
Azure 上のサービスとしてのプラットフォーム (PaaS) としての SQL。

このデプロイの種類には、単一データベースとエラスティック プールが含まれます。
アクティブな地理的レプリケーション フェールオーバーがトリガーされてから 30 秒。

セカンダリ データベースのいずれかに対してフェールオーバーがアクティブ化されると、その他のすべてのセカンダリが新しいプライマリに自動的にリンクされます。
5 秒の RPO。

アクティブ geo レプリケーションは、SQL Server の Always On テクノロジを使用します。 これは、スナップショット分離を使用して、プライマリ データベース上のコミットされたトランザクションをセカンダリ データベースに非同期的にレプリケートします。

セカンダリ データには部分トランザクションが含まれないことが保証されます。
Azure 上のアクティブ geo レプリケーションが構成された PaaS としての SQL。

このデプロイの種類には、マネージド インスタンス、エラスティック プール、単一データベースが含まれます。
自動フェールオーバー グループ 1 時間の RTO。 5 秒の RPO。

自動フェールオーバー グループは、アクティブ geo レプリケーションの上にグループ セマンティクスを提供します。 ただし、同じ非同期レプリケーション メカニズムが使用されます。
Azure IaaS VM 上またはオンプレミスの SQL Server。 Azure Site Recovery を使用したレプリケーション RTO は通常 15 分未満です。 詳細については、Site Recovery によって提供される RTO SLA に関するページを参照してください。 アプリケーション整合性では 1 時間、クラッシュ整合性では 5 分です。 より低い RPO を求めている場合は、別の BCDR テクノロジを使用してください。

注意

Site Recovery を使用して SQL ワークロードを保護する場合のいくつかの重要な考慮事項。

  • Site Recovery はアプリケーションに依存しません。 Site Recovery は、サポートされているオペレーティング システム上にデプロイされたすべてのバージョンの SQL Server を保護するために役立ちます。 詳細については、レプリケートされるコンピューターの復旧のサポート マトリックスを参照してください。
  • Azure、Hyper-V、VMware、または物理インフラストラクチャにあるすべてのデプロイに対して Site Recovery を使用することを選択できます。 Site Recovery を使用して SQL Server クラスターを保護する方法については、この記事の最後にあるガイダンスに従ってください。
  • コンピューター上で観察されたデータ変化率が Site Recovery の制限内にあることを確認してください。 この変化率は、1 秒あたりの書き込みバイト数で測定されます。 Windows を実行しているコンピューターの場合、この変化率は、タスク マネージャーで [パフォーマンス] タブを選択することによって表示できます。 各ディスクの書き込み速度を観察します。
  • Site Recovery は、記憶域スペース ダイレクトでのフェールオーバー クラスター インスタンスのレプリケーションをサポートしています。 詳細については、記憶域スペース ダイレクト レプリケーションを有効にする方法に関するページを参照してください。

SQL ワークロードを Azure に移行する場合は、SQL Server のパフォーマンス ガイドラインを Azure Virtual Machines に適用することをお勧めします。

アプリケーションのディザスター リカバリー

Site Recovery は、復旧計画を使用して、アプリケーション全体のテスト フェールオーバーとフェールオーバーを調整します。

復旧計画がニーズに応じて完全にカスタマイズされるようにするためのいくつかの前提条件があります。 通常は、すべての SQL Server デプロイに Active Directory デプロイが必要です。 また、アプリケーション層への接続も必要です。

手順 1:Active Directory のセットアップ

SQL Server が正常に実行されるように、セカンダリ復旧サイトに Active Directory をセットアップします。

  • 小規模企業: オンプレミス サイトのための少数のアプリケーションと 1 つのドメイン コントローラーがあります。 サイト全体をフェールオーバーする場合は、Site Recovery レプリケーションを使用します。 このサービスは、ドメイン コントローラーをセカンダリ データセンターまたは Azure にレプリケートします。
  • 中規模企業から大企業: 追加のドメイン コントローラーのセットアップが必要になることがあります。
    • 多数のアプリケーションと Active Directory フォレストがあり、アプリケーションまたはワークロードごとにフェールオーバーする場合は、セカンダリ データセンターまたは Azure に別のドメイン コントローラーをセットアップします。
    • リモート サイトに復旧するために Always On 可用性グループを使用している場合は、セカンダリ サイトまたは Azure に別のドメイン コントローラーをセットアップします。 このドメイン コントローラーは、復旧された SQL Server インスタンスのために使用されます。

この記事の手順では、セカンダリの場所でドメイン コントローラーを使用できることを前提にしています。 詳細については、Site Recovery を使用して Active Directory を保護するための手順を参照してください。

手順 2:他の層との接続を確保する

ターゲット Azure リージョンでデータベース層が実行されるようになったら、アプリケーションおよび Web 層との接続が存在することを確認してください。 テスト フェールオーバーで接続を検証するために、事前に必要な手順を実行します。

接続を考慮してアプリケーションを設計する方法を理解するには、次の例を参照してください。

手順 3:Always On、アクティブ geo レプリケーション、および自動フェールオーバー グループと相互運用する

BCDR テクノロジの Always On、アクティブ geo レプリケーション、および自動フェールオーバー グループには、ターゲット Azure リージョンで実行されている SQL Server のセカンダリ レプリカがあります。 アプリケーション フェールオーバーのための最初の手順は、このレプリカをプライマリとして指定することです。 この手順では、セカンダリに既にドメイン コントローラーが存在することを前提にしています。 自動フェールオーバーの実行を選択したときは、この手順が必要ない場合があります。 Web およびアプリケーション層は、データベース フェールオーバーが完了した後でのみフェールオーバーします。

注意

Site Recovery を使用して SQL コンピューターを保護している場合は、これらのコンピューターの復旧グループを作成し、そのフェールオーバーを復旧計画に追加するだけで済みます。

アプリケーションおよび Web 層の仮想マシンを含む復旧計画を作成します。 次の手順は、データベース層のフェールオーバーを追加する方法を示しています。

  1. SQL 可用性グループをフェールオーバーするスクリプトを Resource Manager 仮想マシン従来の仮想マシンの両方にインポートします。 これらのスクリプトを Azure Automation アカウントにインポートします。

    Deploy to Azure logo

  2. 復旧計画の最初のグループの事前アクションとして ASR-SQL-FailoverAG スクリプトを追加します。

  3. このスクリプトで使用可能な手順に従ってオートメーション変数を作成します。 この変数は、可用性グループの名前を指定します。

手順 4:テスト フェールオーバーを実行する

SQL Always On などの一部の BCDR テクノロジでは、テスト フェールオーバーをネイティブにサポートしていません。 このようなテクノロジを使用している場合にのみ、次のアプローチをお勧めします。

  1. Azure で可用性グループ レプリカをホストする VM に Azure Backup をセットアップします。

  2. 復旧計画のテスト フェールオーバーをトリガーする前に、前の手順で取得されたバックアップから VM を復旧します。

    Screenshot showing window for restoring a configuration from Azure Backup

  3. バックアップから復元された VM でクォーラムを強制します。

  4. リスナーの IP アドレスをテスト フェールオーバー ネットワークで使用できるアドレスに更新します。

    Screenshot of rules window and IP address properties dialog

  5. リスナーをオンラインにします。

    Screenshot of window labeled Content_AG showing server names and statuses

  6. フェールオーバー ネットワークのロード バランサーに、1 つの IP アドレス (各可用性グループ リスナーに対応するフロントエンド IP アドレス プールの IP アドレス) と、バックエンド プールの SQL Server VM があることを確認します。

    Screenshot of window titled

    Screenshot of window titled

  7. 後の復旧グループで、この復旧計画のためのアプリケーション層のフェールオーバー、次に Web 層のフェールオーバーを追加します。

  8. 復旧計画のテスト フェールオーバーを実行して、アプリケーションのエンド ツー エンドのフェールオーバーをテストします。

フェールオーバーを実行する手順

手順 3. でスクリプトを追加し、それを手順 4. で検証したら、手順 3. で作成された復旧計画のフェールオーバーを実行できます。

アプリケーションおよび Web 層のフェールオーバーの手順は、テスト フェールオーバーとフェールオーバーの両方の復旧計画で同じである必要があります。

SQL Server クラスターを保護する方法

SQL Server Standard エディションまたは SQL Server 2008 R2 を実行しているクラスターの場合は、Site Recovery レプリケーションを使用して SQL Server を保護することをお勧めします。

Azure から Azure およびオンプレミスから Azure

Site Recovery では、Azure リージョンにレプリケートするときに、ゲスト クラスターはサポートされていません。 また、SQL Server Standard エディションでは、低コストのディザスター リカバリー ソリューションも提供されません。 このシナリオでは、プライマリの場所で SQL Server クラスターをスタンドアロン SQL Server インスタンスに対して保護し、それをセカンダリで復旧することをお勧めします。

  1. プライマリ Azure リージョンまたはオンプレミス サイトで、追加のスタンドアロン SQL Server インスタンスを構成します。

  2. このインスタンスを、保護するデータベースのミラーとして機能するように構成します。 高安全性モードでミラーリングを構成します。

  3. AzureHyper-V、または VMware VM と物理サーバーのためのプライマリ サイト上で Site Recovery を構成します。

  4. Site Recovery レプリケーションを使用して、新しい SQL Server インスタンスをセカンダリ サイトにレプリケートします。 これは高安全性のミラー コピーであるため、プライマリ クラスターと同期されますが、Site Recovery レプリケーションを使用してレプリケートされます。

    Image of a standard cluster that shows the relationship and flow among a primary site, Site Recovery, and Azure

フェールバックに関する考慮事項

SQL Server Standard クラスターの場合、計画されていないフェールオーバーの後のフェールバックには SQL Server のバックアップと復元が必要です。 この操作は、ミラーの再確立によって、ミラー インスタンスから元のクラスターに対して実行されます。

よく寄せられる質問

Site Recovery と共に使用される場合、SQL Server のライセンスはどのように取得されますか。

SQL Server 向けの Site Recovery レプリケーションは、ソフトウェア アシュアランスのディザスター リカバリー特典の対象になります。 この対象範囲は、Site Recovery のすべてのシナリオ (オンプレミスから Azure へのディザスター リカバリーおよびリージョン間の Azure IaaS ディザスター リカバリー) に適用されます。 詳細については、「Azure Site Recovery の価格」を参照してください。

現在使用している SQL Server バージョンは Site Recovery でサポートされますか。

Site Recovery はアプリケーションに依存しません。 Site Recovery は、サポートされているオペレーティング システム上にデプロイされたすべてのバージョンの SQL Server を保護するために役立ちます。 詳細については、レプリケートされるコンピューターの復旧のサポート マトリックスを参照してください。

次のステップ