マルチリージョンでの障害復旧を目的とした Microsoft SQL Server のデプロイ

Last reviewed 2020-08-21 UTC

このチュートリアルでは、障害復旧（DR）ソリューションとして 2 つの Google Cloud リージョンで Microsoft SQL Server データベースシステムをデプロイして管理する方法について説明します。また、障害が発生したデータベースインスタンスから正常に稼働しているインスタンスにフェイルオーバーする方法について説明します。このドキュメントにおいては、障害とはプライマリデータベースで障害が発生する、可用性が失われるイベントを意味します。

プライマリデータベースは、配置されているリージョンに障害が発生したり、アクセスできなくなったりした場合に障害となる可能性があります。リージョンが利用可能で正常に動作している場合でも、システムエラーが原因でプライマリデータベースに障害が発生することがあります。この場合、障害復旧はクライアントが処理を継続するために、セカンダリデータベースを利用できるようにするプロセスです。

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

目標

Microsoft SQL Server の AlwaysOn 可用性グループを使用して、Google Cloud にマルチリージョン障害復旧環境をデプロイします。
障害イベントをシミュレートし、完全な障害復旧プロセスを実行して障害復旧構成を検証します。

料金

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

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

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

始める前に

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

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

プロジェクトセレクタに移動
Google Cloud プロジェクトで課金が有効になっていることを確認します。
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

障害復旧について

Google Cloud の障害復旧（DR）は、特にリージョンで障害が発生した場合やアクセスできなくなった場合に、処理の継続性を提供することが目的です。データベース管理システムなどのシステムの場合、少なくとも 2 つのリージョンにシステムをデプロイして DR を実装します。この設定では、1 つのリージョンが使用不可能になってもシステムは引き続き動作します。

データベースシステムの障害復旧

プライマリデータベースインスタンスで障害発生時にセカンダリデータベースに切り替えるプロセスをデータベースの障害復旧（データベース DR）といいます。このコンセプトの詳細については、Microsoft SQL Server の障害復旧をご覧ください。セカンダリデータベースの状態は、プライマリデータベースが使用不能になった時点か、プライマリデータベースの最近のトランザクションの一部が欠落している時点において、プライマリデータベースの状態と一致することが理想的です。

障害復旧アーキテクチャ

Microsoft SQL Server について、次の図で、データベース DR をサポートする最小限のアーキテクチャを示しています。

プライマリインスタンスとスタンバイインスタンスは、リージョン R1 の 2 つのゾーンにわたっており、セカンダリインスタンスはリージョン R2 に配置されています。

図 1. Microsoft SQL Server を使用した標準障害復旧アーキテクチャ。

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

Microsoft SQL Server の 2 つのインスタンス（プライマリインスタンスとスタンバイインスタンス）は同じリージョン（R1）にありますが、ゾーンは異なります（ゾーン A と B）。R1 の 2 つのインスタンスは、同期 commit モードを使用して状態を調整しています。同期モードは高可用性を実現し、一貫したデータ状態を維持する目的で使用されます。
Microsoft SQL Server の 1 つのインスタンス（セカンダリまたは障害復旧インスタンス）が 2 番目のリージョン（R2）に配置されます。DR を実施する際には、非同期 commit モードを使用して、R2 のセカンダリインスタンスが R1 のプライマリインスタンスと同期します。非同期モードが使用される理由は、そのパフォーマンスにあります（プライマリインスタンスでの commit 処理の速度が低下しません）。

上の図で、アーキテクチャは可用性グループを示しています。可用性グループがリスナーで使用される場合、クライアントが以下によって配信されるとクライアントに同じ接続文字列が提供されます。

プライマリインスタンス
スタンバイインスタンス（ゾーン障害の後）
セカンダリインスタンス（リージョン障害の後、およびセカンダリインスタンスが新しいプライマリインスタンスになった後）

上に示したアーキテクチャのバリアントでは、最初のリージョン（R1）の 2 つのインスタンスを同じゾーンにデプロイします。このアプローチによってパフォーマンスが向上する可能性がありますが、可用性は高くありません。DR プロセスを開始するために、1 つのゾーンの停止が必要になる可能性があります。

基本的な障害復旧プロセス

リージョンが利用できなくなり、プライマリデータベースがフェイルオーバーして別の運用リージョンで処理を再開すると、DR プロセスが開始されます。リージョン障害を軽減し、使用可能なリージョンで実行するプライマリインスタンスを確立するために、DR プロセスは手動または自動で実行されるべき運用ステップを規定します。

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

プライマリデータベースインスタンスを実行している最初のリージョン（R1）が使用できなくなります。
オペレーションチームが障害を認識して正式に応答し、フェイルオーバーが必要かどうかを判断します。
フェイルオーバーが必要な場合は、2 番目のリージョン（R2）のセカンダリデータベースインスタンスが新しいプライマリインスタンスに設定されます。
クライアントは、新しいプライマリデータベースで処理を再開し、R2 のプライマリインスタンスにアクセスします。

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

完全な障害復旧プロセス

完全な DR プロセスでは、フェイルオーバー後に完全な DR アーキテクチャを確立するためのステップを追加することで、基本的な DR プロセスを拡張します。次の図は、データベースの完全な DR アーキテクチャを示しています。

完全なデータベース DR アーキテクチャでは、リージョン R2 のセカンダリインスタンスがプライマリになり、新しいセカンダリインスタンスがリージョン R3 に作成されます。

図 2.使用できないプライマリリージョン（R1）での障害復旧。

このデータベースの完全な DR アーキテクチャは、次のように機能します。

プライマリデータベースインスタンスを実行している最初のリージョン（R1）が使用できなくなります。
オペレーションチームが障害を認識して正式に応答し、フェイルオーバーが必要かどうかを判断します。
フェイルオーバーが必要な場合は、2 番目のリージョン（R2）のセカンダリデータベースインスタンスがプライマリインスタンスに設定されます。
別のセカンダリインスタンス（新しいスタンバイインスタンス）が作成され、R2 で起動され、プライマリインスタンスに追加されます。スタンバイインスタンスは、プライマリインスタンスとは異なるゾーンにあります。プライマリデータベースは、高可用性を備えた 2 つのインスタンス（プライマリとスタンバイ）で構成されるようになりました。
3 番目のリージョン（R3）では、新しいセカンダリ（スタンバイ）データベースインスタンスが作成され開始されます。このセカンダリインスタンスは、R2 の新しいプライマリインスタンスに非同期で接続されます。この時点で元の障害復旧アーキテクチャが再作成され、稼働を開始します。

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

オンラインに復帰した後、最初のリージョン（R1）は新しいセカンダリデータベースをホストできます。R1 の復旧が十分に速ければ、R3（3 番目のリージョン）ではなく、R1 の完全復旧プロセスのステップ 5 を実装できます。この場合 3 番目のリージョンは必要ありません。

次の図は、R1 が時間内に使用可能になった場合のアーキテクチャを示しています。

リージョン R1 が時間内に復旧すると、セカンダリインスタンスがリージョン R1 に作成されます。

図 3.障害が発生したリージョン R1 が再度利用可能になった後の障害復旧。

このアーキテクチャーでのリカバリー手順は、R1 が R3 の代わりにセカンダリインスタンスのロケーションになるという違いを除いて、前に完全な障害復旧プロセスで概説した手順と同じです。

SQL Server のエディションの選択

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

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

マルチリージョン DR 向けに Microsoft SQL Server を設定する

このセクションでは、Microsoft SQL Server 2016 Enterprise Edition の sql-ent-2016-win-2016 イメージを使用します。Microsoft SQL Server 2017 Enterprise Edition をインストールする場合は、sql-ent-2017-win-2016 を使用します。Microsoft SQL Server 2019 Enterprise Edition の場合は、sql-ent-2019-win-2019 を使用します。イメージの完全なリストについては、イメージをご覧ください。

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

SQL Server のマルチリージョンデータベース DR アーキテクチャを設定するには、まず 2 つのインスタンスの高可用性（HA）クラスタを 1 つのリージョンに作成します。一方のインスタンスはプライマリとして機能し、もう一方はセカンダリとして機能します。この手順を行うには、SQL Server AlwaysOn 可用性グループの構成の手順に沿って操作します。このチュートリアルでは、プライマリリージョン（R1 と呼びます）に us-central1 を使用します。始める前に、以下の注意事項を確認してください。

まず、SQL Server AlwaysOn 可用性グループの構成のステップを行う場合は、同じゾーン（us-central1-f）に 2 つの SQL Server インスタンスを作成します。この設定では、us-central1-f の障害は保護されません。したがって、HA をサポートするには、us-central1-c に 1 つの SQL Server インスタンス（cluster-sql1）を、us-central1-f に 2 つ目のインスタンス（cluster-sql2）をデプロイします。次のセクション（障害復旧用のセカンダリインスタンスを追加する）のステップでは、このデプロイの設定が前提となっています。

2 番目に、SQL Server AlwaysOn 可用性グループを構成するのステップでは、次のステートメントが実行されます。

BACKUP DATABASE TestDB to disk = '\\cluster-sql2\SQLBackup\TestDB.bak' WITH INIT

このステートメントにより、スタンバイインスタンスが失敗します。代わりに、次のコマンドを実行します（バックアップファイルの名前は異なります）。

BACKUP DATABASE TestDB to disk = '\\cluster-sql2\SQLBackup\TestDB-backup.bak' WITH INIT

3 番目に、SQL Server AlwaysOn 可用性グループを構成するの手順で、バックアップディレクトリを作成します。これらのバックアップはプライマリインスタンスとスタンバイを初めて同期するときにのみ使用します。その後は使用しません。バックアップディレクトリを作成する別の方法として、この手順で [Automatic seeding] を選択することもできます。このアプローチによりセットアッププロセスが簡素化されます。

4 番目に、データベースが同期されない場合は cluster-sql2 で次のコマンドを実行します。

ALTER DATABASE [TestDB] SET HADR AVAILABILITY GROUP = [cluster-ag]

5 番目に、このチュートリアルの目的として、次の図に示すように、1 つのドメインコントローラを us-central1-f に作成します。

同期モードのプライマリインスタンスとスタンバイインスタンスは、1 つのリージョンで別々のゾーンにあり、非同期モードのセカンダリインスタンスは別のリージョンにあります。

図 4.このチュートリアルで実装されている標準的な障害復旧アーキテクチャ。

このチュートリアルでは上記のアーキテクチャを実装しますが、ベストプラクティスとしては複数のゾーンでドメインコントローラを設定することをおすすめします。このアプローチにより、HA と DR 対応のデータベースアーキテクチャを確実に設定できます。たとえば、1 つのゾーンでシステム停止が発生しても、そのゾーンは、デプロイされたアーキテクチャでの単一障害点にはなりません。

障害復旧のためにセカンダリインスタンスを追加する

次に、3 つ目の SQL Server インスタンス（cluster-sql3 という名前のセカンダリインスタンス）とネットワーキングを設定します。

Cloud Shell で、プライマリリージョンで使用したのと同じ Virtual Private Cloud（VPC）で、セカンダリリージョン（us-east1）にサブネットを作成します。
```
gcloud compute networks subnets create wsfcsubnet4 --network wsfcnet \
    --region us-east1 --range 10.3.0.0/24
```
allow-internal-ports というファイアウォールルールを変更して、新しいサブネットがトラフィックを受信します。
```
gcloud compute firewall-rules update allow-internal-ports \
    --source-ranges 10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24
```
allow-internal-ports ルールは、前述の手順のステップに含まれています。

SQL Server インスタンスを作成する

gcloud compute instances create cluster-sql3 --machine-type n1-highmem-4 \
    --boot-disk-type pd-ssd --boot-disk-size 200GB \
    --image-project windows-sql-cloud --image-family sql-ent-2016-win-2016 \
    --zone us-east1-b \
    --network-interface "subnet=wsfcsubnet4,private-network-ip=10.3.0.4,aliases=10.3.0.5;10.3.0.6" \
    --can-ip-forward --metadata sysprep-specialize-script-ps1="Install-WindowsFeature Failover-Clustering -IncludeManagementTools;"

新しい SQL Server インスタンスに Windows パスワードを設定します。
1. Google Cloud コンソールで [Compute Engine] ページに移動します。
  
  Compute Engine に移動
2. Compute Engine クラスタ cluster-sql3 の [接続] 列で、[Windows パスワードを設定] プルダウンリストを選択します。
3. ユーザー名とパスワードを設定します。後で使用できるようにメモしておいてください。
[接続] をクリックして、cluster-sql3 インスタンスに接続します。
手順 4 のユーザー名とパスワードを入力し、[OK] をクリックします。

管理者として Windows PowerShell ウィンドウを開き、DNS とオープンポートを構成します。

netsh interface ip set dns Ethernet static 10.2.0.100

netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022

netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433

インスタンスを Windows ドメインに追加します。
```
Add-Computer -DomainName "dbeng.com" -Credential "dbeng.com\Administrator" -Restart -Force
```
このコマンドの実行により RDP 接続が終了します。

セカンダリインスタンスをフェイルオーバークラスタに追加する

次に、セカンダリインスタンス（cluster-sql3）を Windows フェイルオーバークラスタに追加します。

RDP を使用して cluster-sql1 インスタンスまたは cluster-sql2 インスタンスに接続し、管理者としてログインします。
管理者として PowerShell ウィンドウを開き、このチュートリアルのクラスタ環境の変数を設定します。
```
$node3 = "cluster-sql3"
$nameWSFC = "cluster-dbclus" # Name of cluster
```
セカンダリインスタンスをクラスタに追加する
```
Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
```
このコマンドの実行には時間を要する場合があります。プロセスが応答しなくなり、自動的に結果を返さなくなる可能性があるため、場合によっては Enter を押します。
ノードで、AlwaysOn 高可用性機能を有効にします。
```
Enable-SqlAlwaysOn -ServerInstance $node3 -Force
```
データベースデータとログファイルを格納する 2 つのフォルダを C:\SQLData と C:\SQLLog に作成します。
```
New-item -ItemType Directory "C:\SQLData"

New-item -ItemType Directory "C:\SQLLog"
```

これでノードがフェイルオーバークラスタと結合されます。

セカンダリインスタンスを既存の可用性グループに追加する

次に、SQL Server インスタンス（セカンダリインスタンス）とデータベースを可用性グループに追加します。

3 つのインスタンスノード（cluster-sql1、cluster-sql2 または cluster-sql3）のいずれかで、Microsoft SQL Server Management Studio を開いてプライマリインスタンス（cluster-sql1）に接続します。
1. Object Explorer に移動します。
2. [接続] プルダウンリストを選択します。
3. [データベースエンジン] を選択します。
4. [サーバー名] プルダウンリストから、[cluster-sql1] を選択します。クラスタがリストに表示されない場合は、フィールドに入力します。
[新しいクエリ] をクリックします。
次のコマンドをペーストして、ノードに使用するリスナーに IP アドレスを追加し、[実行] をクリックします。
```
ALTER AVAILABILITY GROUP [cluster-ag] MODIFY LISTENER 'cluster-listene' (ADD IP ('10.3.0.6', '255.255.255.0'))
```
オブジェクトエクスプローラで、[AlwaysOn 高可用性] ノードを展開してから、[可用性グループ] ノードを展開します。
cluster-ag という名前の可用性グループを右クリックし、[レプリカを追加] を選択します。
[概要] ページで、[AlwaysOn 高可用性] ノードをクリックしてから、[可用性グループ] ノードをクリックします。
[レプリカに接続] ページで、[接続] をクリックして、既存のセカンダリレプリカ cluster-sql2 に接続します。
[レプリカの指定] ページで、[レプリカを追加] をクリックし、新しいノード cluster-sql3 を追加します。自動フェイルオーバーによって同期コミットが発生するため、[自動フェイルオーバー] は選択しないでください。このような設定はリージョンの境界を超えるため、おすすめしません。
[データ同期の選択] ページで、[Automatic Seeding] を選択します。

リスナーが存在しないため、[検証] ページで警告が生成されますが、無視しても問題ありません。
ウィザードの手順を完了します。

cluster-sql1 と cluster-sql2 のフェイルオーバーモードは自動的に設定されますが、cluster-sql3 では手動での設定が必要です。この違いは、高可用性と障害復旧を区別する 1 つの方法になります。

可用性グループが使用可能になりました。高可用性のために 2 つのノードを構成し、障害復旧用に 3 つ目のノードを構成しました。

障害復旧のシミュレーション

このセクションでは、このチュートリアルによる障害復旧アーキテクチャをテストし、またオプション DR の実装も検討します。

停止をシミュレーションして DR フェイルオーバーを実行する

プライマリリージョンで障害（停止）をシミュレーションします。
1. cluster-sql1 の Microsoft SQL Server Management Studio で、cluster-sql1 に接続します。
2. テーブルを作成します。後の手順でレプリカを追加した後にこのテーブルが存在を確認できれば、レプリカが正常に動作することを検証できます。
```
USE TestDB
GO
CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
GO
```
3. Cloud Shell で、プライマリリージョン（us-central1）にある両方のサーバーをシャットダウンします。
```
gcloud compute instances stop cluster-sql2 --zone us-central1-f --quiet
gcloud compute instances stop cluster-sql1 --zone us-central1-c --quiet
```
注: 障害を発生させるもう 1 つの方法としては、cluster-sql1 と cluster-sql2 を実行している VM を停止する方法があります。このアプローチは、通常のインスタンスシャットダウンではなく、ハード障害をシミュレーションするものです。
cluster-sql3 の Microsoft SQL Server Management Studio で、cluster-sql3 に接続します。
フェイルオーバーを実行し、可用性モードを同期 commit に設定します。ノードが非同期 commit モードのため、フェイルオーバーの強制が必要です。
```
ALTER AVAILABILITY GROUP [cluster-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO
```
処理を再開できます。cluster-sql3 がプライマリインスタンスになりました。
（省略可）cluster-sql3 に新しいテーブルを作成します。レプリカを新しいプライマリと同期した後、このテーブルがレプリカに複製されているかどうかを確認します。
```
USE TestDB
GO
CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
GO
```

この時点で cluster-sql3 がプライマリですが、元のリージョンにフォールバックするか、新しいセカンダリインスタンスとスタンバイインスタンスを設定して、完全な DR アーキテクチャを再作成することをおすすめします。次のセクションでは、これらの選択肢について説明します。

（省略可）トランザクションを完全に複製する DR アーキテクチャを再作成する

このユースケースは、プライマリに障害が発生する前にすべてのトランザクションがプライマリデータベースからセカンダリデータベースに複製される障害に対処します。この理想的なシナリオではデータが失われることはありません。障害が発生した時点で、セカンダリの状態がプライマリと整合しています。

このシナリオでは次の 2 つの方法で完全な DR アーキテクチャを再作成できます。

元のプライマリと元のスタンバイ（使用可能な場合）にフォールバックする。
元のプライマリとスタンバイが利用できない場合に、cluster-sql3 に新しいスタンバイとセカンダリを作成する。

アプローチ 1: 元のプライマリとスタンバイにフォールバックする

Cloud Shell で、元の（古い）プライマリとスタンバイを起動します。

gcloud compute instances start cluster-sql1 --zone us-central1-c --quiet
gcloud compute instances start cluster-sql2 --zone us-central1-f --quiet

Microsoft SQL Server Management Studio で、cluster-sql1 と cluster-sql2 をセカンダリレプリカとして追加します。

cluster-sql3 で、2 つのサーバーを非同期コミットモードで追加します。

USE [master]
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (FAILOVER_MODE = MANUAL)
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (FAILOVER_MODE = MANUAL)
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

cluster-sql1 で、データベースを再度同期します。
```
USE [master]
GO
ALTER DATABASE [TestDB] SET HADR RESUME;
GO
```
cluster-sql2 で、データベースを再度同期します。
```
USE [master]
GO
ALTER DATABASE [TestDB] SET HADR RESUME;
GO
```

cluster-sql1 を再度プライマリにします。

cluster-sql3 で、cluster-sql1 の可用性モードを同期 commit に変更します。インスタンス cluster-sql1 が再びプライマリになります。
```
USE [master]
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO
```

cluster-sql1 で、cluster-sql1 をプライマリに、2 つの他のノードをセカンダリに変更します。

USE [master]
GO
-- Node 1 becomes primary
ALTER AVAILABILITY GROUP [cluster-ag] FAILOVER;
GO

-- Node 2 has synchronous commit
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO

-- Node 3 has asynchronous commit
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

すべてのコマンドが成功すると、次の図に示すように、cluster-sql1 がプライマリになり、他のノードはセカンダリになります。

Object Explorer に可用性グループが表示されます。

アプローチ 2: 新しいプライマリとスタンバイを設定する

元のプライマリインスタンスとスタンバイインスタンスを障害から復元できない場合、復元に時間がかかりすぎる場合、リージョンにアクセスできない場合があります。1 つの方法として、次の図に示すように、cluster-sql3 をプライマリのままにして、新しいスタンバイインスタンスと新しいセカンダリインスタンスを作成します。

スタンバイインスタンスは別のゾーンに作成されますが、リージョンはプライマリと同じです。セカンダリインスタンスは別のリージョンに作成されます。

図 5. 元のプライマリリージョン R1 が使用できない場合の障害復旧。

この実装では、次のことを行う必要があります。

cluster-sql3 を us-east1 でプライマリのままにします。
新しいスタンバイインスタンス（cluster-sql4）を us-east1 の別のゾーンに追加します。この手順により新しいデプロイが高可用性として確立されます。
別のリージョン（us-west2 など）に新しいセカンダリインスタンス（cluster-sql5）を作成します。この手順では障害復旧のために新しいデプロイを設定します。これでデプロイの全体が完了です。データベースアーキテクチャは HA と DR を完全にサポートしています。

（省略可）トランザクションがない場合にフォールバックを実行する

理想的ではない障害としては、プライマリで commit された 1 つ以上のトランザクションが、障害発生時にセカンダリに複製されない場合です（ハード障害とも呼ばれます）。フェイルオーバーでは、複製されていない commit されたトランザクションはすべて失われます。

このシナリオのフェイルオーバーの手順をテストするには、ハード障害を発生させる必要があります。ハード障害を発生させる最も良い方法は次のとおりです。

ネットワークを変更して、プライマリインスタンスとセカンダリインスタンスの間の接続がないようにします。
プライマリを変更する（例: テーブルを追加する、データを挿入する）
前述のフェイルオーバープロセスを順に実行して、セカンダリを新しいプライマリにします。

フェイルオーバープロセスのステップは、理想的なシナリオと同じですが、ネットワーク接続の中断後にプライマリに追加されたテーブルは、セカンダリでは表示されません。

ハード障害に対処する唯一の方法は、可用性グループからレプリカ（cluster-sql1 と cluster-sql2）を削除して、これらのレプリカを再度同期することです。同期することでセカンダリの状態に変化します。障害発生前に複製されなかったトランザクションは失われます。

cluster-sql1 をセカンダリインスタンスとして追加するには、前述した cluster-sql3 を追加するのと同じ手順に沿って操作します（フェイルオーバークラスタにセカンダリインスタンスを追加するを参照）。ただし、cluster-sql1 ではなく、cluster-sql3 がプライマリになっている点が異なります。cluster-sql3 のインスタンスを可用性グループに追加するサーバーの名前に置き換える必要があります。同じ VM（cluster-sql1 と cluster-sql2）を再利用する場合は、サーバーを Windows Server フェイルオーバークラスタに追加する必要はありません。SQL Server インスタンスを可用性グループに再度追加する処理のみを行います。

この時点で cluster-sql3 はプライマリ、cluster-sql1 と cluster-sql2 はセカンダリです。cluster-sql1 にフォールバックして、cluster-sql2 をスタンバイにし、cluster-sql3 をセカンダリにできるようになりました。これでシステムは障害前の状態と同じになりました。

自動フェイルオーバー

セカンダリインスタンスにプライマリとして自動的にフェイルオーバーすると、問題が発生する場合があります。元のプライマリが再び使用可能になった後、一部のクライアントがセカンダリにアクセスして、他のクライアントが復元されたプライマリに書き込みを行うと、スプリットブレインの状況が発生します。この場合、プライマリとセカンダリが並行して更新され、異なる状態となる可能性があります。このような状況を回避するために、このチュートリアルでは手動フェイルオーバーの手順について説明します。この手順では、フェイルオーバーをするかどうか（またはそのタイミング）を決定できます。

自動フェイルオーバーを実装する場合は、構成された 1 つのインスタンスのみをプライマリとし、変更可能にする必要があります。スタンバイインスタンスまたはセカンダリインスタンスでは、クライアントには書き込み権限を提供しないでください（状態複製用のプライマリを除く）。また、短期間にフェイルオーバーが連続して繰り返されることは回避する必要があります。たとえば、5 分ごとにフェイルオーバーすることは、信頼できる障害復旧戦略とは言えません。自動フェイルオーバープロセスの場合は、このような問題のある状況に対する予防策に組み込むことができます。また、必要に応じてデータベース管理者による支援を得て、複雑な判断を下せるようにすることもできます。

代替デプロイアーキテクチャ

このチュートリアルでは、次の図に示すように、フェイルオーバーにおいてプライマリインスタンスとなるセカンダリインスタンスを有する障害復旧アーキテクチャを設定します。

図 6. Microsoft SQL Server を使用した標準障害復旧アーキテクチャ。

つまりフェイルオーバーの場合、フォールバックが可能になるまで、またはスタンバイ（HA の場合）とセカンダリ（DR の場合）を構成するまで、結果のデプロイには単一のインスタンスが存在します。

別のデプロイアーキテクチャでは、2 つのセカンダリインスタンスを構成します。どちらのインスタンスもプライマリのレプリカです。フェイルオーバーが発生した場合、セカンダリのうちの 1 つをスタンバイとして構成できます。次の図は、フェイルオーバーの前後のデプロイアーキテクチャを示しています。

2 つのセカンダリインスタンスはリージョン R2 の別々のゾーンに配置されています。

図 7. 2 つのセカンダリインスタンスを持つ標準的な障害復旧アーキテクチャ。

フェイルオーバーの後、リージョン R2 のセカンダリインスタンスの 1 つがスタンバイインスタンスになります。

図 8.フェイルオーバー後の 2 つのセカンダリインスタンスを持つ標準的な障害復旧アーキテクチャ。

2 つのセカンダリのいずれかをスタンバイ（図 8）にする必要がありますが、新しいスタンバイをゼロから作成して構成するよりもはるかに高速です。

2 つのセカンダリインスタンスを使用するこのアーキテクチャに似たセットアップで DR に対応することもできます。2 番目のリージョンに 2 つのセカンダリを用意する（図 7）だけでなく、3 番目のリージョンにさらに 2 つのセカンダリをデプロイできます。この設定により、プライマリリージョンでの障害発生後に適用する、HA と DR に対応したデプロイアーキテクチャを効率的に作成できます。

クリーンアップ

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

プロジェクトを削除する

Google Cloud コンソールで、[リソースの管理] ページに移動します。
[リソースの管理] に移動
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ

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