Amazon FSx for NetApp ONTAP を使用した SQL Server Always On Failover Cluster インスタンスの HA と DR の実装

このブログは 2023 年 4 月 7 日に Sudhir Amin（Sr. Solutions Architect）と、Nishanth Charlakola（S&P Global Market Intelligence の Associate Director）によって執筆された内容を日本語化したものです。原文はこちらを参照してください。

昨今、IT 部門が直面する最も困難な課題の 1 つは、拠点間でデータの可用性とアクセシビリティを確保することです。異なる AWS リージョンにまたがる SQL Server データベースの高可用性とアクセシビリティの維持は、クラウドへの移行を検討している企業にとって、データ保護の最重要要件となっています。

Amazon FSx for NetApp ONTAP（FSx for ONTAP）は、目標復旧時間（RTO）と目標復旧時点（RPO）の要件を満たすために、SQL Server 環境を異なる AWS リージョンにフェイルオーバーするための迅速な方法を提供します。FSx for ONTAP は、完全なフルマネージドの ONTAP ファイルシステムをクラウド上で立ち上げ、実行することができるストレージサービスです。「Amazon FSx for NetApp ONTAP を使用した SQL Server 高可用性デプロイメント」の投稿で詳しく説明したように、FSx for ONTAP によって、高可用性の SQL Server Always On Failover Cluster インスタンス（FCI）アーキテクチャが構築できます。この高可用性に加えて、様々な業種のお客様が、ビジネスクリティカルなワークロードに対する事業継続性と災害復旧戦略を求めています。

このブログでは、高可用性（HA）と災害復旧（DR）の SQL Server FCI アーキテクチャを設計する際の基準となるアーキテクチャパターンを説明します。このソリューションでは、NetApp SnapMirror（SnapMirror）によるネイティブデータレプリケーション機能を活用して、2 つの AWS リージョンにまたがる FSx for ONTAP ファイルシステム間のデータレプリケーションを実現します。

ソリューション概要

FSx for ONTAP の SnapMirror 機能の整合性と、性能、信頼性を評価し、ビジネス目標を達成する方法を説明します。定義した 10 分未満の RPO と、1 時間未満の RTO を達成する方法を示すために、米国東部（バージニア北部）のプライマリサイトである us-east-1 と、ウォームスタンバイの災害復旧サイト（us-east-2）の両方の環境を準備します。このアーキテクチャは、FSx for ONTAP ボリュームで実行されている Microsoft SQL Server のユーザーデータベースを、SnapMirror レプリケーションを使って復旧できるように設計されており、低い RPO と RTO の目標が達成できます。このソリューションを実装するには、NetApp のデータ管理機能を十分に理解し、基本的な知識を持っていることをお勧めします。次の図に、ソリューションアーキテクチャを示します。

図 1 : SQL Server DR のためのマルチリージョン FSx for ONTAP の SnapMirror レプリケーション

前提条件

FSx for ONTAP がサポートする任意の AWS リージョンで、以下で説明するようにプライマリサイトと DR サイトの両方の環境を準備します。

このセットアップ例では、米国東部（バージニア北部、オハイオ）の AWS リージョンを使用しています。

Amazon VPC（VPC）と VPC Peering 接続を作成するための AWS Identity and Access Management（IAM）権限
2 つのアベイラビリティゾーン（AZ）にまたがり、us-east-1 のプライマリサイトをホストする 2 つのプライベートサブネットを持つ VPC
Single-AZ で、us-east-2 の DR サイトをホストするプライベートサブネットを持つ別の VPC
Windows Failover Cluster と SQL Deployment をサポートするためのネットワークアクセスを持つ既存または新規の Active Directory（AD）。AD は、AWS Launch Wizard for Active Directory または Quick Start for Active Directory を使用して Amazon Elastic Compute Cloud（Amazon EC2）をデプロイできる
プライマリサイトとセカンダリサイトの両方に SQL Server インスタンスをデプロイする。このソリューション例ではアーキテクチャ図に示すように、プライマリサイトに 2 ノードの SQL Server FCI と、DR サイトに追加で 3 つ目の SQL Server ノードをデプロイする
AD ドメイン管理者アカウントと、 SQL Server サービスアカウントの認証情報
3 つの SQL Server はすべて同じ Windows Failover Cluster および AD ドメインに参加し、SQL Server 用の共通 AD サービスアカウントを利用する
プライマリサイト（us-east-1）の要件に応じて、適切な SSD 容量を持つ FSx for ONTAP ファイルシステムをプロビジョニングする
DR サイト（us-east-2）に、プライマリサイトにプロビジョニングした SSD のサイズ以上で、別の FSx for ONTAP ファイルシステムを Multi-AZ または Single-AZ でプロビジョニングする

ウォークスルー

このソリューションを実装するに、以下の大まかなステップを実行します。

FSx for ONTAP ファイルシステムを使用して、 2 ノード SQL Server FCI をプライマリサイト（us-east-1）にデプロイする
DRサイト（us-east-2）で、プライマリサイトの FSx for ONTAP ファイルシステムと SnapMirror 関係を構成する
プライマリサイトで実際の災害シナリオをシミュレートする
DR のテストを実施し、タイムスタンプを追跡する
フェイルバック用の SnapMirror 関係を構成する

1. FSx for ONTAP ファイルシステムを使用して、 2 ノード SQL Server FCI をプライマリサイトにデプロイする

以下ブログの手動デプロイおよび自動デプロイのステップバイステップの説明に従うか、AWS Launch Wizard サービスを使用して SQL Server FCI（Always on FCI）をデプロイできます。

手動デプロイ

Amazon FSx for NetApp ONTAP を使用した SQL Server 高可用性デプロイメント

自動デプロイ

AWS Launch Wizard が Amazon FSx for NetApp ONTAP を使用した SQL Server のデプロイのサポートを開始

Figure 2: Choosing a deployment model for your SQL Server Failover Cluster Instance

図 2 : SQL Server FCI のデプロイモデルの選択

2. DR サイト（us-east-2）で、プライマリサイトの FSx for ONTAP ファイルシステムと SnapMirror 関係を構成する

まず、「NetApp SnapMirror を使用した FSx for ONTAP への移行」のマニュアルを参照して、2 つの FSx for ONTAP ファイルシステム間の SnapMirror レプリケーションのセットアップについての詳細を理解してください。

2.1. DR サイトの Single-AZ FSx for ONTAP ファイルシステムに、災害対策ボリュームを作成

volume create -vserver svm-dr -volume sqldr -type DP -size 8192GB -aggregate aggr1

2.2. プライマリと DR の FSx for ONTAP ファイルシステム間でクラスターピアリングを構築

SnapMirror は、クラスタ間 LIF を使用して、ソースクラスタとデスティネーションクラスタ間のデータ転送を実行します。

2.2.1. 次のコマンドを使用して、両方の FSx for ONTAP ファイルシステムの LIF を収集します。これは、クラスターピアリングを作成するために必要です。

network interface show -role intercluster

2.2.2. LIF の IP アドレスを収集後、DR サイトの FSx for ONTAP ファイルシステムの LIF を使用して、プライマリサイトの FSx for ONTAP ファイルシステムからクラスターピアリング要求を作成します。クラスターピアリング関係を保護するために、任意のパスフレーズを入力する必要があります。

cluster peer create -address-family ipv4 -peer-addrs <LIF’s of DR Site >

コマンド例：

cluster peer create -address-family ipv4 -peer-addrs 11.0.45.160,11.0.36.120

the cluster peering request from the DR FSx for ONTAP file system

2.2.3. 次に、DR サイトの FSx for ONTAP ファイルシステムから、クラスターピアリング要求を作成し、プライマリサイトの FSx for ONTAP ファイルシステムの LIF を使用してプロセスを完了します。前のステップで作成した同じパスフレーズを指定します。

cluster peer create -address-family ipv4 -peer-addrs <LIF’s of Primary Site>

コマンド例：

cluster peer create -address-family ipv4 -peer-addrs 10.0.3.148,10.0.16.16

2.2.4. 以下のコマンドを使用してピアリングが成功したことを確認します。

cluster peer show

2.3. プライマリファイルシステムと DR ファイルシステムの間に SVM ピアリングを作成

2.3.1. DR サイトの FSx for ONTAP ファイルシステムから SVM ピアリング要求を作成

vserver peer create -vserver svm-dr -peer-vserver svm-prod -peer-cluster <PrimarySite 
ONTAP FilesystemID> -applications snapmirror -local-name PRIMARY_SITE

コマンド例：

vserver peer create -vserver svm-dr -peer-vserver svm-prod -peer-
cluster FsxId06b9ca2edc5756c9c -applications snapmirror -local-name PRIMARY_SITE

2.3.2. プライマリサイトの FSx for ONTAP ファイルシステムで、SVM ピアリング要求を承認します。

vserver peer accept -vserver svm-prod -peer-vserver svm-dr -local-name DR_SITE

2.3.3. ピアリングの状態を確認します。

vserver peer show

2.4. プライマリファイルシステムと DR ファイルシステムの間に SnapMirror 関係を構築

クラスタピアリングと SVM ピアリングの両方を確立した次のステップとして、DR サイトの FSx for ONTAP ファイルシステムに SnapMirror 関係を構築します。オプションで -throttle フラグを使用すると、SnapMirror 関係が使用できる最大帯域幅（K バイト/秒）を設定できます。

snapmirror create 
             -source-path <localname for primary>:<source vol> 
             -destination-path <svm-dr>:<DR volume> 
             -vserver <DR SVM> 
             -throttle unlimited

コマンド例：

snapmirror create
             -source-path PRIMARY_SITE:sqlprod
             -destination-path svm-dr:sqldr
             -vserver svm-dr
             -throttle unlimited

2.5. 5 分のスケジュールを使用するように SnapMirror 関係を変更

SnapMirror 関係を作成したら、次にレプリケーションのスケジュールを設定します。

2.5.1. Run the following command on DR FSx for ONTAP system to list all the available schedules.
DR サイトの FSx for ONTAP システムで以下のコマンドを実行して、使用可能な全てのスケジュールを一覧表示します。

job schedule show

job schedule show list of all the available schedules

2.5.2. 次のコマンドを実行して 5 分のスケジュールを使用するよう SnapMirror 関係を変更します。

snapmirror modify -destination-path svm-dr:sqldr -schedule 5min

2.6. SnapMirror 関係を初期化

2.6.1. DR サイトの FSx for ONTAP システムで以下のコマンドを実行して、SnapMirror レプリケーションを初期化します。

snapmirror initialize
                   -destination-path svm-dr:sqldr
                   -source-path PRIMARY_SITE:sqlprod

2.6.2. 以下のコマンドを実行して、SnapMirror のステータスを確認します。

snapmirror show

status of SnapMirror relationship

3. プライマリサイトで実際の災害シナリオをシミュレートする

ソースデータベースへの負荷をシミュレーションするために、約 3.5 TB サイズの 30,000 のデータウェアハウスに対して、377 人の仮想ユーザーを用いて HammerDB 負荷生成ツールを実行します。

3.1. SQL Server Management Studio（SSMS）を開きます。

3.2. プライマリサイト（us-east-1）にあるソース SQL Server データベースインスタンスに接続します。

3.3. SSMS でタイムスタンプを記録するために、New Query を選択して TPCC データベース内に SQL RPO Tracker テーブルを作成します。

Use TPCC
GO
CREATE TABLE RPOTracker (
    Date date,
    RPO time,
    Status varchar (255)
);

3.4. 次に、10 秒の遅延でループしてタイムスタンプを挿入するスクリプト実行します。これは、DR サイトでデータベースボリュームをリカバリーした後に、データ損失を検証するのに役立ちます。

DECLARE @DateTime datetime2(7) = GETDATE();
DECLARE @Date date = CAST(@DateTime AS date);
DECLARE @RPO time = CAST(@DateTime AS time(7));
    
WHILE 1 = 1
BEGIN
    INSERT INTO [TPCC].[dbo].[RPOTracker](Date,RPO,Status)
    VALUES(@Date, @RPO,'Success');
    
    WAITFOR DELAY '00:00:10';
        
    SET @DateTime = GETDATE();
    SET @Date = CAST(@DateTime AS date);
    SET @RPO = CAST(@DateTime AS time(7));

4. DR のテストを実施し、タイムスタンプを追跡する

続いて、ソース側の SQL Server で以下のクエリを実行して、RPO Tracker テーブルに記録された最新のタイムスタンプを確認します。以下では、最後のレコードに 04:37:38 のタイムスタンプが表示されています。

SELECT top(5) Date, RPO, status FROM [TPCC].[dbo].[RPOTracker]
Order By RPO desc

Figure 3: SQL Query output to track last recorded timestamp on source SQL Server at primary site

図 3 : プライマリサイトのソース SQL Server で最後に記録されたタイムスタンプを追跡するための SQL クエリ出力

04:37:38 PM 時点：DR イベントのアナウンスを想定するか、プライマリサイトの SQL Server 構成を手動で壊して障害をシミュレートすることができます。以下のホワイトペーパー「Designing highly available distributed systems on AWS」を参照し、DR テストで MTTR（平均復旧時間）と MTBF（平均故障間隔）を測定する方法やその他用語などを確認してください。

04:37:52 PM 時点：DR サイトの FSx for ONTAP ファイルシステムの SnapMirror ラグと最新スナップショットを記録します。以下の出力結果例では、最新のスナップショットは 04: 35:03 に更新されていて、ラグタイムは 0:2:48 となっています。

以下のコマンドを実行することで、ラグタイムと最新スナップショットのタイムスタンプが一覧表示できます。詳細については、SnapMirror show コマンドのドキュメントを参照してください。

snapmirror show -fields Lag-time,newest-snapshot-timestamp

the lag time and newest snapshot timestamp

04:38:59 PM 時点： 2 つのファイルシステム間の SnapMirror 関係を正常に静止し、解除しました。

snapmirror quiesce コマンドは、SnapMirror 関係の今後の転送を無効にします。進行中の転送がない場合は、リレーションシップは「quiesced」になります。進行中の転送があっても影響はなく、転送が完了するまでリレーションシップは「quiescing」になります。

snapmirror quiesce -destination-path svm-dr:sqldr

snapmirror break コマンドは、データ保護ミラーのソースエンドポイントとデスティネーションエンドポイント間の SnapMirror 関係を破棄します。

snapmirror break -destination-path svm-dr:sqldr

SnapMirror relationship between a source and destination endpoint of a data protection mirror

04:39:59 PM 時点： SnapMirror 関係が解除されると、DR ボリューム上の LUN を DR SQL Server ノードにマッピングできるようになります。

iSCSI LUN を DR SQL Server ノードにマップする手順：

iSCSI LUN をレプリケートされた DR ボリュームにマッピングして、DR SQL Server インスタンスへのアクセスを提供するイニシエータグループを修正する
DR SQL Server インスタンスに LUN が表示された後に、SQL Server データファイルのファイルとフォルダのパーミッションを確認する
SSMS を使用して DR SQL Server に接続し、SQL データベースファイルをアタッチして SQL データベースをオンラインにする
以下の SQL クエリを使用して、タイムスタンプの最新レコードを確認し、どの程度のデータ損失（RPO）を発生したかを確認する

select top 5 * from tpcc.dbo.RPOTracker with (nolock) order by rpo desc

Figure 4: SQL Query output to track last recorded timestamp on DR SQL server after cutover

図 4 : カットオーバー後に DR SQLServer に最後に記録されたタイムスタンプを追跡するための SQL クエリ結果

ソース SQL Server の変更率など、カットオーバー中の RPO に影響を与える可能性のある要因はいくつかあります。そのため、ベストプラクティスの構成については、 SnapMirror のドキュメントを参照することをお勧めします。SnapMirror レプリケーションは、5 Gbps の最大帯域幅を利用するなど、単一の TCP フローセッションに制限されます。従って、ボリュームごとに設定できる SnapMirror 関係は 1 つだけです。よりタイトな RPO と RTO を実現するには、スケジュールを使用して理想的なレプリケーション間隔を設定する必要があります。このソリューション例では、設定可能な最小オプションである 5 分間隔でのスケジュールを使用しました。

5. フェイルバック用の SnapMirror 関係を構成する

フェイルオーバー後にプライマリサイトの FSx for ONTAP ファイルシステムにフェイルバックするには、DR サイトの FSx for ONTAP ファイルシステムからプライマリサイトの FSx for ONTAP ファイルシステムへリバースレプリケーションを実施する必要があります。

5.1. プライマリサイトの FSx for ONTAP ファイルシステムと、DR サイトの FSx for ONTAP ファイルシステム間の SnapMirror 関係を削除します。

コマンド例：

snapmirror delete -source-path PRIMARY_SITE:sqlprod -destination-path svm-dr:sqldr

5.2. DR サイトの FSx for ONTAP（SnapMirror 関係上の新しいプライマリ）から SnapMirror 関係を再構築します。

コマンド例：

snapmirror resync -destination-path svm-dr:sqldr

SnapMirror relationship from DR FSx for ONTAP (new primary)

5.3. スケジュールを 5 分ごとに実行するように変更します。

snapmirror modify -destination-path PRIMARY_SITE:sqlprod -schedule 5min

クリーンアップ

意図しない料金が発生しないように、使用しなくなったリソースは削除してください。このソリューションで作成した以下のリソースをクリーンアップすることをお勧めします。

まとめ

このブログでは、マルチリージョンで構成した 2 つの FSx for ONTAP ファイルシステム間で SnapMirror レプリケーションを構成して、低い RPO と RTO で災害復旧要件を満たす方法を紹介しました。FSx for ONTAP の SnapMirror 機能を使用すると、災害復旧を目的として 2 つの異なる AWS リージョンで動作する FSx for ONTAP ファイルシステム間でボリューム上のデータを簡単にレプリケートすることができます。FSx for ONTAP では、SQL Server Standard エディションで SQL Server Always On FCI を実装でき、ライセンスコストの削減に役立てることが出来ます。このアーキテクチャにより、大規模データベース用に SQL Server Enterprise エディションを使用しているお客様は、HA と DR の両方でストレージコストを削減することができます。

より詳細な情報とガイダンスについては「NetApp SnapMirror Configuration & best practices guide」を読むことをお勧めします。

翻訳はネットアップ合同会社の岩井様、監修はプロフェッショナルサービス本部の葉山が担当しました。

Amazon Web Services ブログ

Amazon FSx for NetApp ONTAP を使用した SQL Server Always On Failover Cluster インスタンスの HA と DR の実装

ソリューション概要

前提条件

ウォークスルー

1. FSx for ONTAP ファイルシステムを使用して、 2 ノード SQL Server FCI をプライマリサイトにデプロイする

手動デプロイ

自動デプロイ

2. DR サイト（us-east-2）で、プライマリサイトの FSx for ONTAP ファイルシステムと SnapMirror 関係を構成する

3. プライマリサイトで実際の災害シナリオをシミュレートする

4. DR のテストを実施し、タイムスタンプを追跡する

5. フェイルバック用の SnapMirror 関係を構成する

クリーンアップ

まとめ

お役立ちリンク

フォローお願いいたします