マルチリージョンの障害復旧での Microsoft SQL Server のデプロイ

このチュートリアルでは、障害復旧(DR)ソリューションとして 2 つの Google Cloud リージョンに Microsoft SQL Server データベース システムをデプロイして管理する方法について説明します。また、障害が発生したデータベース インスタンスから正常なオペレーティング システムにフェイルオーバーする方法について説明します。このドキュメントでは、障害とはプライマリ データベースで障害が発生したり、プライマリ データベースが使用不能になったイベントを意味します。

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

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

目標

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

料金

このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。

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

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳しくは、クリーンアップをご覧ください。

始める前に

このチュートリアルでは Cloud プロジェクトが必要です。新しいサービス アカウントを作成するか、すでに作成済みのプロジェクトを選択できます。

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

    プロジェクト セレクタのページに移動

  2. Google Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法を学習する

  3. Cloud Console で、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 プロセスは、次の手順で構成されます。

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

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

障害復旧プロセスを完了する

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

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

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

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

  1. プライマリ データベース インスタンスを実行している最初のリージョン(R1)が使用できなくなります。
  2. オペレーション チームが障害を認識して正式に応答し、フェイルオーバーが必要かどうかを判断します。
  3. フェイルオーバーが必要な場合は、2 番目のリージョン(R2)のセカンダリ データベース インスタンスがプライマリ インスタンスになります。
  4. 別のセカンダリ インスタンス(新しいスタンバイ インスタンス)が作成され、R2 で開始し、プライマリ インスタンスに追加されます。スタンバイ インスタンスは、プライマリ インスタンスとは異なるゾーンにあります。プライマリ データベースは、高可用性を備えた 2 つのインスタンス(プライマリとスタンバイ)で構成されます。
  5. 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 のインスタンスをリージョンごとに個別の VM にインストールすることをおすすめします。HA環境をセットアップする場合は、ゾーンごとに1つずつ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 つのインスタンスがプライマリとして機能し、もう 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)をデプロイします。次のセクション(障害復旧用のセカンダリ インスタンスを追加する)の次のステップでは、このデプロイの設定が前提となっています。

次に、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

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

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 という名前のセカンダリ インスタンス)とネットワーキングを設定します。

  1. 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
    
  2. 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 ルールは、前述の手順のステップに含まれています。

  3. 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;"
    
  4. 新しい SQL Server インスタンスに Windows パスワードを設定します。

    1. Cloud Console で、[Compute Engine] ページに移動します。

      Compute Engine に移動

    2. Compute Engine クラスタ cluster-sql3 の [接続] 列で、[Windows パスワードを設定] プルダウン リストを選択します。

    3. ユーザー名とパスワードを設定します。後で使用するため、メモしておいてください。

  5. [RDP] をクリックして cluster-sql3 インスタンスに接続します。

  6. ステップ 4 のユーザー名とパスワードを入力し、[OK] をクリックします。

  7. 管理者として 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
    
  8. インスタンスを Windows ドメインに追加します。

    Add-Computer -DomainName "dbeng.com" -Credential "dbeng.com\Administrator" -Restart -Force
    

    このコマンドを実行すると、RDP 接続が終了します。

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

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

  1. RDP を使用して cluster-sql1 または cluster-sql2 インスタンスに接続し、管理者としてログインします。

  2. 管理者として PowerShell ウィンドウを開き、このチュートリアルのクラスタ環境の変数を設定します。

    $node3 = "cluster-sql3"
    $nameWSFC = "cluster-dbclus" # Name of cluster
    
  3. クラスタにセカンダリ インスタンスを追加します。

    Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
    

    このコマンドの実行には時間がかかる場合があります。プロセスは途中で停止し、自動的には返されないため、場合によっては Enter を押します。

  4. ノードで、AlwaysOn 高可用性機能を有効にします。

    Enable-SqlAlwaysOn -ServerInstance $node3 -Force
    
  5. データベース データとログファイルを格納する 2 つのフォルダを C:\SQLDataC:\SQLLog に作成します。

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

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

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

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

  1. 3 つのインスタンス ノード(cluster-sql1cluster-sql2 または cluster-sql3)のいずれかで、Microsoft SQL Server Management Studio を開いてプライマリ インスタンス(cluster-sql1)に接続します。

    1. オブジェクト エクスプローラに移動します。
    2. [接続] プルダウン リストを選択します。
    3. [データベース エンジン] を選択します。
    4. [サーバー名] プルダウン リストから、cluster-sql1 を選択します。クラスタがリストにない場合は、所定のフィールドに入力します。
  2. [新しいクエリ] をクリックします。

  3. 次のコマンドを貼り付けて、ノードに使用するリスナーに IP アドレスを追加し、[実行] をクリックします。

    ALTER AVAILABILITY GROUP [cluster-ag] MODIFY LISTENER 'cluster-listene' (ADD IP ('10.3.0.6', '255.255.255.0'))
    
  4. オブジェクト エクスプローラで、[AlwaysOn 高可用性] ノードを展開し、[可用性グループ] ノードを展開します。

  5. cluster-ag という名前の可用性グループを右クリックし、[レプリカを追加] を選択します。

  6. [概要] ページで、[AlwaysOn 高可用性] ノードをクリックし、[可用性グループ] ノードをクリックします。

  7. [レプリカに接続] ページで、[接続] をクリックして既存のセカンダリ レプリカ cluster-sql2 に接続します。

  8. [レプリカの指定] ページで、[レプリカを追加] をクリックし、新しいノード cluster-sql3 を追加します。[自動フェイルオーバー] は選択しないでください。自動フェイルオーバーによって同期が commit されます。このような設定はリージョンの境界を越えますが、おすすめしません。

  9. [データ同期の選択] ページで [自動シード] を選択します。

    リスナーがないため、[検証] ページで警告が生成されます。これを無視しても問題ありません。

  10. ウィザード手順を完了します。

cluster-sql1cluster-sql2 のフェイルオーバー モードは自動的に行われますが、cluster-sql3 の場合は手動です。この違いは、高可用性と障害復旧を区別するための 1 つの方法です。

これで可用性グループが準備できました。高可用性向けに 2 つのノードを構成し、障害復旧用に 3 つ目のノードを構成しました。

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

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

停止のシミュレーションと DR フェイルオーバーの実行

  1. プライマリ リージョンの障害(停止)をシミュレートします。

    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
      
  2. cluster-sql3 上の Microsoft SQL Server Management Studio で、cluster-sql3 に接続します。

  3. フェイルオーバーを実行し、可用性モードを同期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 がプライマリ インスタンスになりました。

  4. (省略可)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: 元のプライマリとスタンバイにフォールバックする

  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
    
  2. Microsoft SQL Server Management Studio で、cluster-sql1cluster-sql2 をセカンダリ レプリカとして追加します。

    1. cluster-sql3 で、非同期 commit モードの 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
      
    2. cluster-sql1 でデータベースを再度同期します。

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

      USE [master]
      GO
      ALTER DATABASE [TestDB] SET HADR RESUME;
      GO
      
  3. cluster-sql1 を再度プライマリにします。

    1. 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
      
    2. 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 がプライマリになり、他のノードはセカンダリになります。

オブジェクト エクスプローラには、可用性グループが表示されます。

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

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

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

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

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

  • cluster-sql3us-east1 でプライマリのままにします。

  • 新しいスタンバイ インスタンス(cluster-sql4)を us-east1 の別のゾーンに追加します。これにより、新しいデプロイメントの高可用性が確立されます。

  • 別のリージョンに新しいセカンド インスタンス(cluster-sql5)を作成します(例: us-west2)。この手順では、障害復旧用に新しいデプロイを設定します。これで、デプロイ全体が完了しました。データベース アーキテクチャは HA と DR を完全にサポートしています。

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

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

このシナリオのフェイルオーバー ステップをテストするには、ハード障害を生成する必要があります。ハード障害を生成する最適な方法は次のとおりです。

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

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

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

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

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

自動フェイルオーバー

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

自動フェイルオーバーを実装する場合は、構成された 1 つのインスタンスのみがプライマリとなり、変更できることを確認する必要があります。スタンバイ インスタンスまたはセカンダリ インスタンスで(状態レプリケーションのプライマリ以外の)クライアントへ書き込み権限を提供しないでください。さらに、短時間での後続のフェイルオーバーの迅速な連鎖を回避する必要があります。たとえば、5 分ごとにフェイルオーバーするのは、信頼できる障害復旧戦略にはなりません。自動フェイルオーバー プロセスの場合は、このようなシナリオで問題に対する予防策に取り組むことができます。また、データベース管理者が必要に応じて複雑な判断を下すこともできます。

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

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

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

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

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

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

2 つのセカンダリ インスタンスはリージョン R2 の別々のゾーンにあります。

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

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

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

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

DR は、2 つのセカンダリ インスタンスを使用するこのアーキテクチャに似たセットアップで解決することもできます。2 つ目のリージョンに 2 つのセカンダリを持つとともに(図 7)、3 つ目のリージョンにさらに 2 つのセカンダリをデプロイできます。この設定では、プライマリ リージョンの障害発生後に、HA と DR に対応したデプロイ アーキテクチャを効率的に作成できます。

クリーンアップ

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

プロジェクトの削除

  1. Cloud Console で [リソースの管理] ページに移動します。

    [リソースの管理] ページに移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ