このページは Cloud Translation API によって翻訳されました。

非同期 PD を使用して Microsoft SQL Server の障害復旧を設定する

このチュートリアルでは、障害復旧（DR）ソリューションとして 2 つの Google Cloud リージョンに Persistent Disk 非同期レプリケーション（PD 非同期レプリケーション）を有効にする方法と、障害発生時に DR インスタンスを起動する方法について説明します。このドキュメントにおいては、障害とはプライマリデータベースの高可用性（HA）クラスタで障害が発生する、可用性が失われるイベントを意味します。プライマリデータベースは、配置されているリージョンに障害が発生したり、アクセスできなくなったりした場合に障害となる可能性があります。

このチュートリアルは、データベースアーキテクト、管理者、エンジニアを対象としています。

目標

Google Cloud で実行されているすべての SQL Server AlwaysOn 可用性グループクラスタノードで、非同期永続ディスクレプリケーションを有効にします。
障害イベントをシミュレートし、完全な障害復旧プロセスを実行して障害復旧構成を検証します。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

このチュートリアルでは、Google Cloud プロジェクトが必要です。新しいプロジェクトを作成することも、すでに作成済みのプロジェクトを選択することもできます。

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

Google Cloud の障害復旧

Google Cloud の DR は、特にリージョンで障害が発生した場合やアクセスできなくなった場合に、処理の継続性を提供することが目的です。DR サイトには複数のデプロイオプションがあり、目標復旧時点（RPO）と目標復旧時間（RTO）の要件によって決まります。このチュートリアルでは、仮想マシン（VM）ディスクがプライマリから DR リージョンに複製されるオプションの 1 つについて説明します。

非同期 Persistent Disk レプリケーションの障害復旧

Persistent Disk 非同期レプリケーション（PD 非同期レプリケーション）は、クロスリージョンのアクティブ / パッシブ DR 向けに、低 RPO と低 RTO のブロックストレージレプリケーションを提供します。

PD 非同期レプリケーションは、2 つのリージョン間でデータの非同期レプリケーションを提供するストレージオプションです。万一リージョンが停止した場合、PD 非同期レプリケーションを使用すると、データをセカンダリリージョンにフェイルオーバーし、そのリージョンでワークロードを再起動できます。

PD 非同期レプリケーションは、実行中のワークロードにアタッチされているディスク（プライマリディスク）から、別のリージョンにある別のディスクにデータを複製します。複製されたデータを受信するディスクをセカンダリディスクと呼びます。

各 SQL Server ノードに接続されているすべてのディスクのレプリカに同じ時点のデータが含まれるように、ディスクは整合性グループに追加されます。整合性グループを使用すると、複数のディスクで DR と DR のテストを実行できます。

障害復旧アーキテクチャ

PD 非同期レプリケーションの場合、次の図は、プライマリリージョンでのデータベース HA と、プライマリリージョンから DR リージョンへのディスクレプリケーションをサポートする最小限のアーキテクチャを示しています。

プライマリインスタンスとスタンバイインスタンスは、リージョン R1 の 2 つのゾーンにわたっており、基盤となるディスクは非同期レプリケーションを使用してリージョン R2 に複製されます。

図 1: Microsoft SQL Server と PD 非同期レプリケーションを使用した障害復旧アーキテクチャ

このアーキテクチャは次のように機能します。

Microsoft SQL Server の 2 つのインスタンス（プライマリインスタンスとスタンバイインスタンス）は可用性グループの一部であり、同じリージョン（R1）にありますが、ゾーンは異なります（ゾーン A と B）。R1 の 2 つのインスタンスは、同期 commit モードを使用して状態を調整しています。同期モードは高可用性を実現し、一貫したデータ状態を維持する目的で使用されます。
両方の SQL ノードのディスクが整合性グループに追加され、DR リージョン R2 に複製されます。データは、基盤となるインフラストラクチャによって非同期で複製されます。
ディスクのみが R2 リージョンに複製されます。DR 中に、新しい VM が作成され、既存のレプリケートされたディスクが VM にアタッチされて、ノードがオンラインになります。

障害復旧プロセス

DR プロセスは、リージョンが使用不可になったときに開始します。リージョン障害を軽減し、使用可能なリージョンで実行するプライマリインスタンスを確立するために、DR プロセスは手動または自動で実行されるべき運用ステップを規定します。

基本的なデータベース DR プロセスは、次の手順で構成されます。

プライマリデータベースインスタンスを実行している最初のリージョン（R1）が使用できなくなります。
オペレーションチームが障害を認識して正式に応答し、フェイルオーバーが必要かどうかを判断します。
フェイルオーバーが必要な場合、プライマリから DR リージョンへのディスクレプリケーションは終了します。ディスクレプリカから新しい VM が作成され、オンラインになります。
DR リージョン（R2）の新しいプライマリデータベースが検証され、オンラインに移行されて接続が可能になります。
ユーザーは、新しいプライマリデータベースで処理を再開し、R2 のプライマリインスタンスにアクセスします。

この基本的なプロセスは、稼働中のプライマリデータベースを再度確立しますが、完全な HA アーキテクチャを確立しません。このアーキテクチャでは、新しいプライマリにスタンバイノードがあります。

図 2. Persistent Disk 非同期レプリケーションを使用した障害復旧後の SQL Server デプロイ

復元したリージョンへのフォールバック

プライマリリージョン（R1）がオンラインに戻ったら、フェイルバックプロセスを計画して実行できます。フェイルバックプロセスは、このチュートリアルで説明するすべての手順で構成されますが、この場合、R2 がソースで、R1 が復元リージョンです。

SQL Server のエディションを選択する

このチュートリアルは、次のバージョンの Microsoft SQL Server に対応しています。

SQL Server 2016 Enterprise Edition
SQL Server 2017 Enterprise Edition
SQL Server 2019 Enterprise Edition
SQL Server 2022 Enterprise Edition

このチュートリアルでは SQL Server の AlwaysOn 可用性グループ機能を使用します。

HA Microsoft SQL Server プライマリデータベースが必要でなく、単一のデータベースインスタンスがプライマリとして十分である場合は、次のバージョンの SQL Server を使用できます。

SQL Server 2016 Standard Edition
SQL Server 2017 Standard Edition
SQL Server 2019 Standard Edition
SQL Server 2022 Standard Edition

SQL Server の 2016 年、2017 年、2019 年、2022 年のバージョンは、Microsoft SQL Server Management Studio がイメージにインストールされています。別途インストールする必要はありません。ただし、本番環境では、Microsoft SQL Server Management Studio の 1 つのインスタンスを、各リージョンの個別の VM にインストールすることをおすすめします。HA 環境を設定する場合は、ゾーンごとに Microsoft SQL Server Management Studio をインストールして、他のゾーンが使用できなくなっても、使用を継続できるようにしてください。

Microsoft SQL Server の障害復旧を設定する

このチュートリアルでは、Microsoft SQL Server Enterprise の sql-ent-2022-win-2022 イメージを使用します。

イメージの完全なリストについては、OS イメージをご覧ください。

2 インスタンス高可用性クラスタを設定する

SQL Server の DR リージョンへのディスクレプリケーションを設定するには、まずリージョンに 2 つのインスタンスの HA クラスタを作成します。一方のインスタンスはプライマリとして機能し、もう一方はスタンバイとして機能します。この手順を行うには、SQL Server AlwaysOn 可用性グループの構成の手順に沿って操作します。このチュートリアルでは、プライマリリージョン（R1 と呼びます）に us-central1 を使用します。SQL Server AlwaysOn 可用性グループの構成の手順を行った場合、同じリージョン（us-central1）に 2 つの SQL Server インスタンスを作成することになります。プライマリ SQL Server インスタンス（node-1）を us-central1-a にデプロイし、スタンバイインスタンス（node-2）を us-central1-b にデプロイします。

ディスクの非同期レプリケーションを有効にする

すべての VM が作成されて構成されたら、VM にアタッチされているすべてのディスクの整合性グループを作成して、リージョン間のディスクコピーを有効にします。データは、ソースディスクから、指定されたリージョンの新しい空のディスクにコピーされます。

SQL ノードとドメインコントローラの両方の整合性グループを作成します。ゾーンディスクの制限事項の 1 つは、整合性グループをゾーンにまたいで配置できないことです。

gcloud compute resource-policies create disk-consistency-group node-1-disk-const-grp \
--region=$REGION

gcloud compute resource-policies create disk-consistency-group node-2-disk-const-grp \
--region=$REGION

gcloud compute resource-policies create disk-consistency-group witness-disk-const-grp \
--region=$REGION

プライマリ VM とスタンバイ VM のディスクを、対応する整合性グループに追加します。

gcloud compute disks add-resource-policies node-1 \
--zone=$REGION-a \
--resource-policies=node-1-disk-const-grp

gcloud compute disks add-resource-policies node-1-datadisk \
--zone=$REGION-a \
--resource-policies=node-1-disk-const-grp

gcloud compute disks add-resource-policies node-2 \
--zone=$REGION-b \
--resource-policies=node-2-disk-const-grp

gcloud compute disks add-resource-policies node-2-datadisk \
--zone=$REGION-b \
--resource-policies=node-2-disk-const-grp

gcloud compute disks add-resource-policies witness \
--zone=$REGION-c \
--resource-policies=witness-disk-const-grp

ペア設定されたリージョンに空のセカンダリディスクを作成します。

DR_REGION="us-west1"
gcloud compute disks create node-1-replica \
  --zone=$DR_REGION-a \
  --size=50 \
  --primary-disk=node-1 \
  --primary-disk-zone=$REGION-a

gcloud compute disks create node-1-datadisk-replica \
  --zone=$DR_REGION-a \
  --size=$PD_SIZE \
  --primary-disk=node-1-datadisk \
  --primary-disk-zone=$REGION-a

gcloud compute disks create node-2-replica \
  --zone=$DR_REGION-b \
  --size=50 \
  --primary-disk=node-2 \
  --primary-disk-zone=$REGION-b

gcloud compute disks create node-2-datadisk-replica \
  --zone=$DR_REGION-b \
  --size=$PD_SIZE \
  --primary-disk=node-2-datadisk \
  --primary-disk-zone=$REGION-b

gcloud compute disks create witness-replica \
  --zone=$DR_REGION-c \
  --size=50 \
  --primary-disk=witness \
  --primary-disk-zone=$REGION-c

ディスクレプリケーションを開始します。データは、プライマリディスクから DR リージョンに新しく作成された空のディスクに複製されます。

gcloud compute disks start-async-replication node-1 \
  --zone=$REGION-a \
  --secondary-disk=node-1-replica \
  --secondary-disk-zone=$DR_REGION-a 

gcloud compute disks start-async-replication node-1-datadisk \
  --zone=$REGION-a \
  --secondary-disk=node-1-datadisk-replica \
  --secondary-disk-zone=$DR_REGION-a 

gcloud compute disks start-async-replication node-2 \
  --zone=$REGION-b \
  --secondary-disk=node-2-replica \
  --secondary-disk-zone=$DR_REGION-b 

gcloud compute disks start-async-replication node-2-datadisk \
  --zone=$REGION-b \
  --secondary-disk=node-2-datadisk-replica \
  --secondary-disk-zone=$DR_REGION-b 

gcloud compute disks start-async-replication witness \
  --zone=$REGION-c \
  --secondary-disk=witness-replica \
  --secondary-disk-zone=$DR_REGION-c

この時点で、データはリージョン間で複製されているはずです。各ディスクのレプリケーションステータスは Active になります。

障害復旧をシミュレートする

このセクションでは、このチュートリアルで設定した障害復旧アーキテクチャをテストします。

停止をシミュレートして障害復旧フェイルオーバーを実行する

DR フェイルオーバー中に、DR リージョンに新しい VM を作成し、複製されたディスクを VM にアタッチします。フェイルオーバーを簡素化するために、同じ IP アドレスを使用するように、DR リージョンで別の Virtual Private Cloud（VPC）を使用して復元できます。

フェイルオーバーを開始する前に、node-1 が作成した AlwaysOn 可用性グループのプライマリノードであることを確認します。2 つのノードは 2 つの個別の整合性グループによって保護されているため、データ同期の問題を回避するために、ドメインコントローラとプライマリ SQL Server ノードを起動します。停止をシミュレートする手順は次のとおりです。

復元用 VPC を作成します。

DRVPC_NAME="default-dr"
DRSUBNET_NAME="default-recovery"

gcloud compute networks create $DRVPC_NAME \
--subnet-mode=custom
CIDR = $(gcloud compute networks subnets describe default \
--region=$REGION --format=value\(ipCidrRange\))

gcloud compute networks subnets create $DRSUBNET_NAME \
--network=$DRVPC_NAME --range=$CIDR --region=$DR_REGION

データレプリケーションを終了します。

PROJECT=$(gcloud config get-value project)
gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-1-disk-const-grp \
--zone=$REGION-a

gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-2-disk-const-grp \
--zone=$REGION-b

gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/witness-disk-const-grp \
--zone=$REGION-c

プライマリリージョンのソース VM を停止します。

gcloud compute instances stop node-1 \
  --zone=$REGION-a

gcloud compute instances stop node-2 \
  --zone=$REGION-b

gcloud compute instances stop witness \
  --zone=$REGION-c

ディスクレプリカを使用して DR リージョンに VM を作成します。これらの VM には、移行元 VM の IP アドレスが割り当てられます。

NODE1IP=$(gcloud compute instances describe node-1 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\))
NODE2IP=$(gcloud compute instances describe node-2 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\))
WITNESSIP=$(gcloud compute instances describe witness --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\))

gcloud compute instances create node-1 \
  --zone=$DR_REGION-a \
  --machine-type $MACHINE_TYPE \
  --network=$DRVPC_NAME \
  --subnet=$DRSUBNET_NAME \
  --private-network-ip $NODE1IP\
  --disk=boot=yes,device-name=node-1-replica,mode=rw,name=node-1-replica \
  --disk=auto-delete=yes,boot=no,device-name=node-1-datadisk-replica,mode=rw,name=node-1-datadisk-replica

gcloud compute instances create witness \
  --zone=$DR_REGION-c \
  --machine-type=n2-standard-2 \
  --network=$DRVPC_NAME \
  --subnet=$DRSUBNET_NAME \
  --private-network-ip $WITNESSIP \
  --disk=boot=yes,device-name=witness-replica,mode=rw,name=witness-replica

停止をシミュレートして DR リージョンにフェイルオーバーしました。これで、セカンダリインスタンスが正しく機能しているかどうかをテストできます。

SQL Server の接続を確認する

VM が作成されたら、データベースが正常に復元され、サーバーが想定どおりに動作していることを確認します。データベースをテストするには、復元されたデータベースから選択クエリを実行します。

リモートデスクトップを使用して SQL Server VM に接続します。
SQL Server Management Studio を開きます。
[サーバーに接続] ダイアログで、サーバー名が NODE-1 に設定されていることを確認し、[接続] を選択します。
ファイルメニューで、現在の接続で [File] > [New] > [Query] を選択します。
```
USE [bookshelf];
SELECT * FROM Books;
```

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにする手順は次のとおりです。

プロジェクトの削除

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。