寄稿：米国SIOS Technology Dave Bermingham
Amazon FSx を SQL Serverフェールオーバークラスターインスタンス（FCI）で使用する為に
注意すべき課題について、FCIのメリットやFSxに代わる選択肢と合わせて解説します。
※この記事は英文サイト「CLUSTERING FOR MERE MORTALS」にて公開された記事を翻訳したものです。
本記事の原文はこちら
はじめに
自社のMicrosoft SQL ServerインスタンスをAWS EC2にデプロイすることを検討している読者は、ソリューションの耐障害性（レジリエンス）に関していくつかの決定を下す必要がある。異なる可用性ゾーンに2つ以上のインスタンスをデプロイする場合、もちろんAWSはコンピューティングリソースに対して99.99%のSLAを提供してくれるだろう。しかし、真のアプリケーションの可用性を計算する際には、他にも考慮しなければならない要素がたくさんあることを忘れてはいけない。私は以前、クラウドにおけるアプリケーションの可用性の計算方法についてブログを書いた。先に進む前に、この記事に目を通しておくことをお勧めする。
Microsoft SQL Serverインスタンスの高可用性を確保するためには、現実的に2つの選択肢がある。Always On可用性グループ（AG）またはSQL Serverフェールオーバー クラスター インスタンス（FCI）だ。この記事を読んでいる読者は、これらのオプションの両方に関する知識があり、SQL Server Always On AGの代わりにSQL Server FCIを使用することを真剣に検討していると想定している。
Microsoft SQL Server フェールオーバー クラスター インスタンスのメリット
SQL Server FCIのメリットをAWSがどのように言っているかを、以下にまとめてみた。貴社のユースケースで以下のような優先度の高い問題がある場合、一般的にAGよりもFCIの方がSQL Serverの高可用性デプロイメントに適している。
ライセンスの費用対効果
AGを実行するにはSQL ServerのEnterprise Editionライセンスが必要だが、FCIの実行に必要なのはStandard Editionライセンスのみである。これは通常、Enterprise Editionに比べて50～60%程度割安になる。SQL Server 2016以降の Standard EditionではAGの Basic バージョンを実行できるが、1つのAGにつき1つのデータベースしかサポートしないという制限がある。これは、SharePointのように複数のデータベースを必要とするアプリケーションを扱う場合に課題となる可能性がある。
インスタンスレベルの保護とデータベースレベルの保護
FCIを使用するとインスタンス全体が保護され、プライマリーノードが使用できなくなった場合、インスタンス全体がスタンバイノードに移動される。これにより、システムデータベースに格納されているSQL Serverログイン、SQL Serverエージェントジョブ、証明書などが保護される。なお、これらは共有ストレージに物理的に格納されている。一方、AGでは、グループ内のデータベースのみが保護され、システムデータベースをAGに追加することはできず、ユーザーデータベースのみが許可される。すべてのAGレプリカ上のシステムオブジェクトへの変更を複製するのは、データベース管理者の責任となる。これにより、ヒューマンエラーが発生してデータベースにアプリケーションがアクセスできなくなる可能性が生じる。
DTC機能のサポート
SQL Server 2012または2014を使用していて、アプリケーションで分散トランザクションコーディネーター（DTC）を使用している場合、AGはサポートされていないため、使用できない。このような場合はFCIを使用する必要がある。
https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/
クラウドでのFCIの課題
可用性ゾーンにまたがるFCIを構築する際の課題は、SQL Server FCIを構築する際に通常必要とされる共有ストレージデバイスがないことだ。クラスターのノードは複数のデータセンターに分散しているため、従来のSANは共有ストレージのオプションにはなり得ない。そこで、クラスターストレージには2つの選択肢がある。SIOS DataKeeper などのサードパーティのストレージリソースか、新しいAmazon FSxである。どれを選ぶかを決める前に、知っておくべきことを確認しよう。
1.サービスレベル契約（SLA）
アプリケーションの可用性を計算する方法で書いたように、アプリケーション全体のSLAは、最低のものと同じになる。この場合、FSxのSLAの99.9%がSLAとなる。通常、99.99%の可用性が「高可用性」の出発点となる。これは、2つ以上のコンピューティングリソースが異なる可用性ゾーンに配置されている場合、AWSがコンピューティングリソースに対して約束するものである。
スリーナインとフォーナインの違いがわからない読者のために説明すると…
- 99.9%の可用性では、ダウンタイムは1ヶ月に43.83分
- 99.99%の可用性では、ダウンタイムは1ヶ月に4.38分
FSxでクラスターストレージをホストすると、99.99％のコンピューティング可用性であっても、アプリケーション全体の可用性は99.9％になる。
対照的に、DataKeeperデプロイメントなどの可用性ゾーンにまたがるEBSボリュームは、ストレージレイヤーとコンピューティングレイヤーの両方で99.99％のSLAとなる。つまり、アプリケーション全体の可用性は99.99％となる。
2.ストレージのロケーション
高可用性のためにFSxを構成する場合、マルチAZサポートを有効にすることをお勧めする。マルチAZを有効にすることで、効果的に「プライマリー」AZと「スタンバイ」AZを使用できる。SQL Server FCIノードをデプロイする際には、これらのノードを同じAZに分散する必要がある。通常の状況では、アクティブなクラスターノードが優先FSxストレージノードと同じAZに存在するようにしなければならない。これは、ストレージまでの距離とレイテンシーを最小限に抑えるだけでなく、AZ間でのデータ転送に関連するコストを最小限に抑えるためだ。FSxの料金ガイドに記載されているように、「ファイルシステムへのAZ間またはリージョン間アクセスには標準のデータ転送料金が適用される。」
残念ながら、現在はストレージとコンピューティングの両方を結び付ける方法は存在しない。どちらか一方に障害が発生した場合、もう一方がフェールオーバーしてレイテンシーを最小限に抑え、データへのアクセスに追加コストが発生しないようにする。現在、AZ間でデータを転送するためのコストは、入力と出力の両方で0.01ドル/GBとなっている。
SQL Server FCIで障害が発生し、FSxでは障害は発生していないという状況では、ストレージとコンピューティングの両方を結び付ける仕組みは存在しない。FSxがフェールオーバーした場合、FSxは自動的にプライマリー可用性ゾーンにフェールバックする。しかしベストプラクティスでは、根本原因分析が実行されるまでSQL FCIはセカンダリーノードで実行されたままにしておき、フェールバックは通常、メンテナンス期間中に行われるようにスケジュールすることを指示している。これにより、ストレージが別のAZにある状況になり、追加のコストが発生する。現在、AZ間でデータを転送するためのコストは、入力と出力の両方で0.01ドル/GBとなっている。FSxとSQL Server FCIの状態を注意深く監視していないと、月末にデータ転送料金を見るまで、異なるリージョンで実行されていることに気付かないといった事態になりかねない。
これに対して、SIOS DataKeeperを使用する構成では、ストレージのフェールオーバーはSQL Server FCIリカバリーの一部であり、ストレージは常にSQL Serverインスタンスでフェールオーバーされるようになっている。これにより、SQL Serverは、アクティブノードに直接接続されているEBSボリュームに対して常に読み取りと書き込みを行うことができる。DataKeeperでは、AZやリージョン間で複製される書き込み操作に伴うデータ転送コストが発生することに注意する必要がある。ただしこのデータ転送コストは、DataKeeper で利用できる圧縮機能を利用することで最小限に抑えることが可能だ。
3.フェールオーバーのコントロール
FSxマルチサブネット構成には、プライマリー可用性ゾーンとスタンバイ可用性ゾーンがある。プライマリーAZのFSxファイルサーバーで障害が発生した場合、スタンバイAZにあるファイルサーバーがバックする。AWSは、このリカバリー時間は標準の共有で約30秒かかると報告している。継続的に利用可能なファイル共有を使用した場合、このフェールオーバー時間は15秒近くになるとMicrosoftは報告している。このフェールオーバー時間中、読み取りと書き込みが一時停止される場所で電圧低下が発生するが、リカバリーが完了すると元に戻る。
FSxマルチサイトでは自動フェールバックが有効になっており、FSxの計画外のフェールオーバーの度に計画外のフェールバックも発生する。対照的に、SQL Server FCIで計画外のフェールオーバーが発生した場合は通常、セカンダリーで実行したままにしておくか、時間外や次のメンテナンス期間中にフェールバックをスケジュールできる。
4.SQL Server Analysis ServicesクラスターはFSxではサポートされていない
クラスターSSASを使用した場合は、SIOS DataKeeperのようなクラスター化されたディスクリソースが必要になる。ホワイトペーパー「How to Cluster SQL Server Analysis Server」には、SMBは使用できず、ドライブレター付きのクラスタードライブを使用する必要があることが明記されている。これに対してDataKeeperボリュームリソースは、それ自体がクラスター化されたディスクであるため、SSASで使用することができる。
まとめ
FSxは、99.9%の可用性SLAで十分なWindowsユーザーファイルやその他の重要ではないサービスのような典型的なSMB用途には確かに妥当で、優れたオプションである。ただし、高可用性（99.99%）や地域をまたいだHA/DRソリューションを必要とするアプリケーションには、SIOS DataKeeperが最適である。
