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

[アーティクル]
04/03/2023

この記事では、アプリケーションの 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 テクノロジを使用してください。

Note

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 およびアプリケーション層は、データベースフェールオーバーが完了した後でのみフェールオーバーします。

Note

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

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

SQL 可用性グループをフェールオーバーするスクリプトを Resource Manager 仮想マシンと従来の仮想マシンの両方にインポートします。これらのスクリプトを Azure Automation アカウントにインポートします。
復旧計画の最初のグループの事前アクションとして ASR-SQL-FailoverAG スクリプトを追加します。
このスクリプトで使用可能な手順に従ってオートメーション変数を作成します。この変数は、可用性グループの名前を指定します。

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

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

Azure で可用性グループレプリカをホストする VM に Azure Backup をセットアップします。
復旧計画のテストフェールオーバーをトリガーする前に、前の手順で取得されたバックアップから VM を復旧します。
バックアップから復元された VM でクォーラムを強制します。
リスナーの IP アドレスをテストフェールオーバーネットワークで使用できるアドレスに更新します。
リスナーをオンラインにします。
フェールオーバーネットワークのロードバランサーに、1 つの IP アドレス (各可用性グループリスナーに対応するフロントエンド IP アドレスプールの IP アドレス) と、バックエンドプールの SQL Server VM があることを確認します。
後の復旧グループで、この復旧計画のためのアプリケーション層のフェールオーバー、次に Web 層のフェールオーバーを追加します。
復旧計画のテストフェールオーバーを実行して、アプリケーションのエンドツーエンドのフェールオーバーをテストします。

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

手順 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 インスタンスに対して保護し、それをセカンダリで復旧することをお勧めします。

プライマリ Azure リージョンまたはオンプレミスサイトで、別のスタンドアロン SQL Server インスタンスを構成します。
このインスタンスを、保護するデータベースのミラーとして機能するように構成します。高安全性モードでミラーリングを構成します。
Azure、Hyper-V、または VMware VM と物理サーバーのためのプライマリサイト上で Site Recovery を構成します。
Site Recovery レプリケーションを使用して、新しい SQL Server インスタンスをセカンダリサイトにレプリケートします。これは安全性の高いミラーコピーであるため、プライマリクラスターと同期されますが、Site Recovery レプリケーションを使用してレプリケートされます。

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

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 を保護するために役立ちます。詳細については、レプリケートされるコンピューターの復旧のサポートマトリックスを参照してください。

Azure Site Recovery は SQL トランザクションレプリケーションと連携しますか?

Azure Site Recovery はファイルレベルのコピーを使用するため、SQL では、Azure Site Recovery のフェールオーバー時に、関連付けられた SQL レプリケーショントポロジ内のサーバーが同期していることを保証できません。これにより、LSN の不一致が原因でログリーダーとディストリビューションエージェントのどちらか、または両方が失敗し、レプリケーションが中断する可能性があります。レプリケーショントポロジでパブリッシャー、ディストリビューター、またはサブスクライバーをフェールオーバーする場合は、レプリケーションを再構築する必要があります。 SQL Server に対するサブスクリプションを再初期化することをお勧めします。

次のステップ

Site Recovery のアーキテクチャを学習してください。
Azure の SQL Server については、セカンダリ Azure リージョンでの復旧のための高可用性ソリューションを学習してください。
SQL Database については、セカンダリ Azure リージョンでの復旧のためのビジネス継続性および高可用性オプションを学習してください。
オンプレミスの SQL Server コンピューターについては、Azure Virtual Machines での復旧のための高可用性オプションを学習してください。

次の方法で共有

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

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