Amazon Web Services ブログ

Amazon FSx for Windows File Server を使用して、Microsoft SQL Server の高可用性デプロイメントを簡素化する

お客様は、10 年以上にわたって AWS で Windows ワークロードを実行しています。ビジネスに不可欠なアプリケーションを実行する上で一般的に求められるのは、Microsoft SQL Server データベースの可用性を高めることです。高可用性のニーズから、SQL Server デプロイアーキテクチャに単一障害点がないことが求められます。高可用性のセットアップでは、プライマリとセカンダリの 2 つのノードのクラスターがあります。プライマリに障害が発生した場合、クラスターは自動的にセカンダリにフェイルオーバーするため、アプリケーションの継続的なデータベースアクティビティが保証されます。Microsoft SQL Server は、SQL Server Always On の傘下で一連の機能を提供して、このような冗長で高可用性のあるデプロイを可能にします。

SQL Server Always On (特に、高可用性に適したデプロイオプションであるフェイルオーバークラスターインスタンスのデプロイオプション) は、従来、デプロイおよび管理が困難でした。この問題は、ノード間でデータをレプリケートすることなく、フェイルオーバー時にセカンダリノードがデータベースストレージに引き続きアクセスできるようにするために共有ストレージを必要とすることに起因しています。

当社は最近、共有ストレージのデプロイと使用を簡素化してお使いのデータベースをホストするために、Amazon FSx for Windows File Server に新機能を導入しました。この機能により、SQL Server Always On デプロイの実行の複雑さとコストが削減されます。Amazon FSx for Windows File Server (Amazon FSx) で、マルチアベイラビリティーゾーンファイルシステムのデプロイのネイティブサポートを導入しました。ネイティブサポートにより、複数のアベイラビリティーゾーンにわたって高可用性と冗長性を備えた AWS に Windows ファイルストレージを簡単にデプロイできます。このリリースに加えて、SMB Continuously Available (CA) ファイル共有のサポートも導入しました。この新しい機能により、可用性が高い完全マネージド型共有ストレージを Amazon FSx で使用してデータベースをホストすることにより、SQL Server Always On のデプロイを簡素化できます。

このブログ記事では、最初に SQL Server Always On のデプロイオプションに関する簡単な背景を説明します。次に、可用性の高いデプロイに適した望ましいオプションが従来、デプロイと管理に難があった理由について説明します。手順について順を追って説明し、Amazon FSx を使用して SQL Server Always On デプロイを実行し、複雑さとコストを削減する方法を示します。

SQL Server Always On の概要

Microsoft SQL Server は、高可用性や障害復旧などのビジネス継続性のユースケース向けに、Always On ソリューションに 2 つのデプロイオプションを用意しています。その 2 つとは、Always On フェイルオーバークラスターインスタンス (FCI) と Always On アベイラビリティーグループ (AG) です。これらのデプロイオプションはどちらも、Windows Server フェイルオーバークラスター (WSFC) テクノロジーを使用して、連携して高可用性を実現する独立したノードのクラスターを提供しますが、両者の間には重要な違いがあります。

  • FCI は、WSFC のノード全体にインストールされる単一の SQL Server インスタンスを提供し、SQL Server のインストール全体の高可用性を実現します。つまり、基になるノードで問題が発生した場合、SQL Server インスタンス内のすべてのデータがクラスター内の別のノードに移動します。特に、システムデータベース、SQL Server ログイン、SQL Server エージェントジョブ、および証明書が別のノードに移動します。FCI には、共有ブロックストレージ (SAN) または共有ファイルストレージ (SMB 経由でアクセス) のいずれかの形式の共有ストレージが必要です。
  • AG は 1 つ以上のユーザーデータベースを表し、クラスターでホストされる複数のレプリカ間で一緒にフェイルオーバーして、データベースレベルの高可用性を実現します。AG はプライマリレプリカと 1 つ以上のセカンダリレプリカで構成され、共有ストレージを必要とせずに SQL Server ログベースのデータ移動を通じてそれらのレプリカを維持してデータを保護します。各レプリカは、WSFC の異なるノード上の SQL Server のインスタンスによってホストされ、それぞれ AG に依存しない独自のローカルストレージを持ちます。

Always On FCI を使用する理由

FCI は、次の理由から、SQL Server の高可用性デプロイでは AG よりも一般的に望ましい選択肢です。

  • ライセンスのコスト効率: AG を実行するには SQL Server の Enterprise Edition ライセンスが必要ですが、FCI を実行するには Standard Edition ライセンスのみが必要です。これは通常、Enterprise Edition よりも 50～60% 安価です。SQL Server 2016 以降の Standard Edition では AG の Basic バージョンを実行できますが、AG ごとにサポートされるデータベースは 1 つのみという制限が付いています。これは、SharePoint のように複数のデータベースを必要とするアプリケーションを扱う際に課題になる可能性があります。
  • インスタンスレベルの保護とデータベースレベルの保護: FCI では、インスタンス全体が保護されます。プライマリノードが使用できなくなると、インスタンス全体がスタンバイノードに移動します。これにより、共有ストレージに物理的に格納されているシステムデータベースに保存されている SQL Server ログイン、SQL Server エージェントジョブ、証明書などが処理されます。一方、AG では、グループ内のデータベースのみが保護され、システムデータベースは AG に追加できません。ユーザーデータベースのみが許可されます。すべての AG レプリカのシステムオブジェクトへの変更をレプリケートするのは、データベース管理者の責任です。これにより、データベースがアプリケーションにアクセスできなくなる人的エラーが発生する可能性が残ります。
  • DTC 機能のサポート: SQL Server 2012 または 2014 を使用していて、アプリケーションが分散トランザクションコーディネーター (DTC) を使用している場合、AG はサポートされていないため使用できません。この状況では FCI を使用してください。

けれども、高可用性以外にも、AG が FCI よりも望ましいシナリオがあります。たとえば、追加のノードをリードレプリカとして設定して、読み取りパフォーマンスのスケーラビリティを高める必要がある場合です。

共有ストレージの要件はどうでしょうか?

FCI は多くのシナリオで AG よりも望ましいですが、従来はデプロイと管理が困難でした。これは、ノード間でデータをレプリケートすることなく、フェイルオーバー時にセカンダリノードがデータベースストレージに引き続きアクセスできるようにするには共有ストレージが必要だからです。高可用性の観点から、共有ストレージは復元力があり、可用性が高い必要があります。それらがないと、共有ストレージが使用できなくなった場合、フェイルオーバークラスター内のノードの数に関係なく FCI がオフラインのままになるため、単一障害点になります。最近まで、高可用性と復元力を提供する堅牢な共有ストレージソリューションの設計と保守の複雑さを担当する専任の管理者が必要でした。さらに、通常、サードパーティ製ストレージレプリケーションソフトウェアソリューション (SIOS DataKeeper や StarWind Virtual SAN など) に対して支払いを行います。それはストレージインフラストラクチャコストを上回ります。

Amazon FSx を使用して複雑さとコストを削減する

Amazon FSx では、2 つのアベイラビリティーゾーン間でストレージを同期的に自動レプリケートする完全マネージド型の共有ファイルストレージを取得できます。さらに、Amazon FSx は、自動障害検出、フェイルオーバー、フェイルバックにより高可用性を実現します。このサービスは、SQL Server Always On FCI デプロイのサポートに必要な SMB 連続可用性 (CA) 機能も完全にサポートしています。

FCI デプロイでは共有ストレージソリューションを提供するのが複雑でコストがかかりました。AG デプロイが必要なことから、SQL Server の Enterprise Edition ライセンスを使用しているユーザーは、Standard Edition に切り替えることができるようになりました。これにより、ライセンス費用を 50～60% 節約できます。また、全体的に SQL デプロイと継続的な管理にまつわる複雑さを軽減できます。たとえば、AG デプロイではすべてのレプリカにわたってシステムデータベースオブジェクトをレプリケートする必要がありましたが、その必要がありません。

サードパーティ製ストレージレプリケーションソフトウェアソリューションを使用して SQL Server FCI を共有ストレージで使用する場合、ストレージレプリケーションソリューションのライセンスを購入し、共有ストレージソリューションを自分でデプロイ、管理、および保守する必要があります。Amazon FSx の完全マネージド型の共有ストレージソリューションを使用すると、SQL Server FCI のデプロイを簡素化することができます。

SQL Server Always On デプロイをオンプレミスで実行している場合、FCI と AG を組み合わせて使用している可能性があります。FCI はプライマリデータセンターサイト内で高可用性を実現し (共有ストレージは通常複数のデータセンターにまたがることができないため)、AG はサイト間で災害復旧ソリューションを提供します。AWS のアベイラビリティーゾーンアーキテクチャと、複数のアベイラビリティーゾーンにデプロイされた高可用性共有ストレージを Amazon FSx がサポートすることで、個別の高可用性と災害復旧ソリューションの必要性を排除できるようになりました。これにより、コストも削減され、デプロイの複雑さが軽減されます。

最後に、Amazon FSx を使用して SQL Server FCI のデプロイを簡素化するもう 1 つの方法に、SQL クラスターに Windows ファイル共有監視を行う方法があります。Windows ファイル共有監視は、高可用性クラスターのすべてのノードで利用できるファイル共有です。監視のジョブは、必要に応じてクォーラム投票が追加で行えるようにし、サイトが停止した場合にクラスターが引き続き実行できるようにすることです。Amazon FSx を使用すると、ファイル共有監視をホストするために完全マネージド型のシングル AZ ファイルシステムを簡単かつコスト効率よく使用できます。

アーキテクチャ

Amazon FSx は、次の機能を備えたファイル共有を提供して、SQL データベースをホストします。

  • SMB バージョン 2.0～3.1.1 のサポート
  • SMB Kerberos を使用した転送中の暗号化
  • カスタマイズ可能なパフォーマンス (スループットと IOPS)
  • SMB 連続可用性 (SMB 透過的フェイルオーバーとも呼ばれる) をサポートするマルチ AZ 配置 (HA)
  • Inter-AZ データレプリケートに料金がかからず、コストが予測可能
  • シングル AZ ファイルシステムは、Windows フェイルオーバークラスターを作成するときのファイル共有監視、または SQL バックアップのターゲットとして使用できます。ファイル共有監視には、32 GB の最小サイズで十分です。

Amazon FSx を SQL フェイルオーバークラスターインスタンスのストレージソリューションとして使用する場合、ターゲットアーキテクチャは次のようになります。

Amazon FSx を SQL フェイルオーバークラスターインスタンスのストレージソリューションとして使用する場合、ターゲットアーキテクチャは次のようになります

Amazon FSx ファイルシステムは、SQL Server FCI クラスターノードと同じアベイラビリティーゾーンにデプロイする必要があります。さらに、1 つのアベイラビリティーゾーンが失われた場合に投票の過半数を維持するために、ファイル共有監視を 3 番目のアベイラビリティゾーンにデプロイする必要があります。ID については、Amazon FSx では AWS マネージド Microsoft Active Directory またはセルフマネージド Microsoft Active Directory を使用できます。

注: このウォークスルーでは、AWS マネージド Microsoft Active Directory と Amazon FSx を使用しており、セルフマネージド Active Directory のケースは扱っていません。Amazon FSx でセルフマネージド Active Directory を使用する方法の詳細については、「オンプレミスの Active Directory とともに Amazon FSx for Windows File Server を使用する」を参照してください。また、この記事では Active Directory のデプロイについては取り上げておらず、すでにデプロイされていることを前提としています。 詳細については、「AWS マネージド Microsoft Active Directory の使用開始」を参照してください。最後に、SQL Server クラスター自体の作成については説明しません。詳細については、「AWS での SQL Server と WSFC」を参照してください。

Amazon FSx を Microsoft SQL Server の共有ストレージとして設定する方法

最初のステップは、ドメインに参加するマルチ AZ Amazon FSx ファイルシステムを作成することです。Amazon FSx ファイルシステムのサイズを適切に設定することが重要です。ストレージ容量は、保存できるデータ量だけでなく、実行できる 1 秒あたりの I/O 操作 (IOP) 数も決定します。ストレージの 1 GB ごとに 3 つの IOP を提供します。ファイルシステムのスループット容量により、ファイルシステムがアクセスする SQL Server インスタンスにファイルデータを提供できる速度が決まります。例として、このテストでは、128 MBps のスループット容量レベルで、6000 GB のストレージ容量 (最大 18000 IOPS を提供するため) を使用しました。

例として、このテストでは 128 MBps のスループット容量レベルで、6000 GB のストレージ容量 (最大 18000 IOPS を提供するため) を使用しました

次のステップは、適切なネットワーク設定を行うことです。Amazon FSx ファイルシステムは、SQL Server クラスターに関連付けられているアベイラビリティーゾーンと同じ 2 つのアベイラビリティーゾーンにデプロイするようにしてください。

次のステップは、適切なネットワーク設定を行うことです

Active Directory を選択します。この例では、AWS マネージド Microsoft Active Directory です。Amazon FSx は、ディレクトリ共有により別の VPC またはアカウントで AWS Microsoft Active Directory を使用することもサポートしています。

Active Directory を選択する

次に、[Create file system] を選択します。

ファイルシステムに Microsoft SQL Server ファイル共有を作成する

2 番目の手順は、ファイルシステムにファイル共有を作成し、適切なアクセス許可設定と可用性設定を行うことです。

まず、DNS 名 (この例では \\amznfsxmzqnv8tv.SQLonFSx.AWS\D$) を使用してファイルシステム上に D$ 共有をマップし、その中に SQLDB というフォルダを作成します。

次に、Amazon FSx コンソールでファイルシステムを選択し、ファイルシステムの Windows リモート PowerShell エンドポイント名を特定します。続いてコマンドを実行して、ファイル共有を作成します。ファイル共有の ContinuouslyAvailable プロパティを以下の True に設定しています。これは、SQL Server デプロイの高可用性を確保するために必要な共有ストレージ機能です。実行する前に、コマンドを独自の値で適切に編集してください。

Amazon FSx コンソールでファイルシステムを選択し、お使いのファイルシステムの Windows リモート PowerShell エンドポイント名を特定します

$FSX = "amznfsxipf5ovad.SQLonFSx.AWS"
Invoke-Command -ComputerName $FSX -ConfigurationName FSxRemoteAdmin -scriptblock {
New-FSxSmbShare -Name "SQLDB" -Path "D:\SQLDB" -Description "SQL Databases Share" -ContinuouslyAvailable $true -FolderEnumerationMode AccessBased -EncryptData $true
grant-fsxsmbshareaccess -name SQLDB -AccountName "sqlonfsx.aws\SQLSA","sqlonfsx.aws\DBAdmins","sqlonfsx.aws\SQLServers" -accessRight Full
}

$FSx をファイルシステムの Windows リモート PowerShell エンドポイントに置き換え、アカウント名を変更します。 この例では、SQL サービスアカウント、DBA のグローバルグループ、およびすべての SQL Server がメンバーである別のグローバルグループの 3 つの ID を使用します。

出力:

コマンドの出力

注: SQL サービスアカウントを使用せず、代わりにシステムアカウントを使用する場合は、指定されたすべての SQL システムアカウントを追加する必要があります。これには、SQL クラスターの仮想コンピューターオブジェクト (VCO) が Domain\system$として含まれます。

NTFS アクセス許可

前の手順では、共有レベルでのみアクセス許可を設定しました。ここで、ファイルレベルのアクセス許可を設定する必要があります。

Amazon FSx コンソールで、ファイルシステムの詳細画面に移動し、ファイルシステムの DNS 名を特定します。

Amazon FSx コンソールで、ファイルシステムの詳細画面に移動し、ファイルシステムの DNS 名を特定します

次に、ファイルシステムに接続できる EC2 Windows インスタンスで、ファイルエクスプローラーに移動し、次の UNC パスを入力します。

\\DNSFSX\d$

次に、SQLDB フォルダを右クリックして、NTFS アクセス許可を編集します。上記の 3 つの ID にフルコントロールが付与されます。

次に、SQLDB フォルダを右クリックして、NTFS アクセス許可を編集します

別の方法として、単一のスクリプトを使用して共有を作成し、適切な NTFS アクセス許可を設定する方法もあります。

たとえば、この場合、次を使用します。

## Variables

$FSX = "amznfsxuj4obt90.SQLonFSx.AWS" ## Amazon FSx DNS Name
$FSxPS = "amznfsxcvcez6o7.SQLonFSx,AWS" # Amazon FSx PowerShell endpoint

New-Item -ItemType Directory -Name SQLDB -Path \\$FSX\D$\

## Set NTFS Permissions
$ACL = Get-Acl \\$FSx\$D\SQLDB
$Ar = New-Object system.security.accesscontrol.filesystemaccessrule('sqlonfsx.aws\DBAdmins',"FullControl","ContainerInherit, ObjectInherit", "None", "Allow")
$ACL.SetAccessRule($Ar)
Set-Acl \\$FSX\D$\SQLDB $ACL

$ACL = Get-Acl \\$FSx\$D\SQLDB
$Ar = New-Object system.security.accesscontrol.filesystemaccessrule('sqlonfsx.aws\SQLSA',"FullControl","ContainerInherit, ObjectInherit", "None", "Allow")
$ACL.SetAccessRule($Ar)
Set-Acl \\$FSX\D$\SQLDB $ACL

$ACL = Get-Acl \\$FSx\$D\SQLDB
$Ar = New-Object system.security.accesscontrol.filesystemaccessrule('sqlonfsx.aws\SQLServers',"FullControl","ContainerInherit, ObjectInherit", "None", "Allow")
$ACL.SetAccessRule($Ar)
Set-Acl \\$FSX\D$\SQLDB $ACL

## Create share and set share permissions
Invoke-Command -ComputerName $FSxPS -ConfigurationName FSxRemoteAdmin -scriptblock {
    New-FSxSmbShare -Name "SQLDB" -Path "D:\SQLDB" -Description "SQL Database Share" -ContinuousAvailable $True -FolderEnumerationMode AccessBased -EncryptData $True 
    Grant-FSxSmbShareaccess -name SQLDB -AccountName "sqlonfsx.aws\SQLSA","sqlonfsx.aws\DBAdmins","sqlonfsx.aws\SQLServers" -accessright Full
}

SQL Server をフェイルオーバークラスターインスタンスとしてインストールする

この時点から、Windows Server フェイルオーバークラスター (WSFC) 上の SQL のインストールは、共有ファイルストレージに依存する SQL FCI インストールとまったく同じです。データベースパスのセットアップでは、SQL 共有に指定するパスは、\\FileSystemDNS\Share という形式の UNC パス名である必要があります (Microsoft SQL Server では、\\localhost などのローカルループバックやマップされたドライブをサポートしていません)。

この例では:

データベースパスのセットアップでは、SQL 共有に指定されたパスは UNC パス名でなければなりません

また、データベースパスを設定する直前に指定されるサービスアカウントに適切な権限が付与されていることを確認することも重要です。

また、データベースパスを設定する直前に指定されるサービスアカウントに適切な権限が付与されていることを確認することも重要です

SQL FCI クラスターのデプロイを完了するには、2 番目のノードでこの手順を繰り返します。このステップを完了すると、Amazon FSx でホストされるデータベースを備えた SQL Server Always On フェイルオーバークラスターインスタンスがあるはずです。

クリーンアップ

概念実証を完了したら、2 つの Amazon FSx ファイルシステム (SQL FCI クラスターのデータベース共有ストレージをホストするファイルシステムと、監視共有をホストするファイルシステム)、AWS Managed Active Directory、および SQL Server クラスターインスタンスを削除して、リソースをクリーンアップします。そうすることで、この概念実証で使用したリソースから将来コストが発生しないようにします。

まとめ

このブログ記事では、Amazon FSx を使用して SQL Server FCI デプロイを実行する際の複雑さとコストを削減する方法を示しました。Amazon FSx マルチ AZ ファイルシステムを共有ストレージソリューションとして使用して、SQL Server FCI をデプロイする段階的なプロセスを順を追って説明しました。

以下に、Amazon FSx が SQL FCI デプロイの実行の複雑さを軽減し、コストを削減するのに役立つ方法の要点を示します。

  • SQL Server の Enterprise Edition ライセンスを使用している場合は、Standard Edition に切り替えることで、ライセンスコストを大幅に節約できます。これにより、SQL デプロイと継続的な管理の全体的な複雑さも軽減できます。
  • サードパーティ製ストレージレプリケーションソフトウェアソリューションを使用して管理および保守している共有ストレージソリューションで FCI を使用している場合、Amazon FSx でフルマネージド型の共有ストレージソリューションを使用して、SQL FCI のデプロイを簡素化するオプションがあります。
  • FCI と AG の組み合わせをオンプレミスで実行して高可用性と災害復旧の両方を実現している場合、デプロイを AWS 上の SQL FCI デプロイに移動するオプションがあります。これにより、個別の HA および DR ソリューションが不要になり、コストがさらに削減され、デプロイの複雑さが軽減されます。
  • Amazon FSx を使用して、SQL クラスターのファイル共有監視をホストできるようになりました。

いつも記事をお読みいただきありがとうございます。ご質問やご意見がございましたら、お気軽にコメントをお寄せください。