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

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

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

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

目標

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

料金

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

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

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

始める前に

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

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

    [プロジェクトの選択] ページに移動

  2. 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 の 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 つのインスタンスがプライマリとして機能し、もう 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 という名前のセカンダリ インスタンス)とネットワーキングを設定します。

  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-sql1 ではなく、cluster-sql3 がプライマリになっている点が異なります。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の場合)を構成するまで、結果のデプロイには単一のインスタンスが存在します。

代替デプロイ アーキテクチャは、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 を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ