昨年、「SQL Server環境で高可用性を実現する7つのポイント」と題した記事で、SQL ServerのEditionごとに異なる可用性の考え方を７つのポイントで比較してご紹介しました。
今回は、SQL Server 2016からStandard Edition でも「Always On可用性グループ（AG）」機能が利用できるようになった事によりSIOSの「SANLess（WSFC＋DKCE） Clusters」の利用価値を改めて考えてみたいと思います。
SQL Serverの冗長化手法 – ４つのパターン
「SQL Server環境で高可用性を実現する7つのポイント」では3つのパターンでの比較を行いましたが、今回はSQL Server2016を利用した冗長化手法として以下の4つのパターンを考えてみます。
- Enterprise EditionのAlwaysOn可用性グループ(AG)
- Standard EditionのAlwaysOn可用性グループ(AG)
- AlwaysOn FCI(Failover Cluster Instance）
- AlwaysOn FCI + SANLess Clusters(WSFC+DKCE)
1. Enterprise EditionのAlwaysOn可用性グループ(AG)
SQL Serverの可用性を向上する方法としては「AlwaysOn 可用性グループ」が広く知られています。「AlwaysOn 可用性グループ」はSQL Server 2012から搭載された機能で、DBMS自体にレプリケーション機能があり、共有ストレージは不要です。
2. Standard EditionのAlwaysOn可用性グループ(AG)
SQL Server 2016からは一部制限付きでSQL ServerのStandard Editionでも「AlwaysOn 可用性グループ」を使えるようになりました。
3. AlwaysOn FCI（Failover Cluster Instance）
「AlwaysOn FCI」は、共有ストレージを使用してアクティブ-スタンバイ型のクラスターを構成することが可能です。SQL ServerのStandard Editionで利用可能です。
4. AlwaysOn FCI + SANLess Clusters
この構成は、共有ストレージを利用せずともAlwaysOn FCIとDBMSのレプリケーションを利用することが可能となります。
ではこれら4つのうち、どのパターンが最も優れているのでしょうか？
それはシステムに求める性能要件、機能要件、予算、構築・運用する人のスキルレベル等に応じて答えは異なることでしょう。
しかし、ここではあえて4番目の「AlwaysOn FCI + SANLess Clusters」の優れた点を3つ挙げてみます。
「AlwaysOn FCI + SANLess Clusters」の優れた点
A) SQL Server 2016 Standard Editionライセンスで利用できコストパフォーマンスが高い。
B) 物理、仮想、クラウドと多彩な環境で利用可能。
C) AlwaysOn可用性グループにはいくつかの制限がありますが、本構成はそれらの制約に縛られることなく、構成的にもシンプルで運用面でも簡素化が可能。
A)に関しては特に説明の必要も無いと思われますので、B)とC)のポイントに関して、以下に少し詳しい説明をしてみます。
SANLess Clustersは多彩な環境で利用可能
サイオスの提供するSANLess Clustersソリューションは、以下の2つの要素で構成されています。
- WSFC（Windows Server Failover Clustering）
Windows Serverが稼働しているサーバーを複数台束ねてHAクラスター構成を可能とする、Windows Serverに付随するクラスター機能。 - DataKeeper for Windows Cluster Edition(DKCE)
共有ストレージの代わりとなってWSFCによるHAクラスターを構成する、データ・レプリケーションソフトウエア。DKCEを使用すると、DKCEが共有ストレージの代わりとなり、実際の物理的な共有ストレージが無くともローカルディスクをレプリケーションしながらAlwaysOn FCIを使用することが可能です。
オンプレの物理環境であれば、（一般的にコストがかかると言われている）共有ストレージが不要なので、コストパフォーマンスに優れ、シンプルに運用できるクラスター環境を構築可能です。
仮想環境では「RDMの各種制約からの解放」というメリットがありますが、これに関してはまたの機会に解説してみたいと思います。また共有ストレージが不要なので、共有ストレージを利用することができないパブリッククラウド環境等でもAlwaysOn FCIを使ったHAクラスターの構成が可能です。
「AlwaysOn可用性グループ」の制約と、「AlwaysOn FCI + SANLess Clusters」の優位性
次に、AlwaysOn可用性グループの制約に関する考察を通して、SANLess Clustersの優位性を考えてみます。
A) 分散トランザクションのサポート
SQL Server 2016以前は、複数のデータベースにまたがるトランザクションおよび分散トランザクションは、AlwaysOn可用性グループでサポートされませんでした。
SQL Server 2016からは異なるSQL Serverインスタンスに配置されたデータベースをまたがる分散トランザクションがサポートされるようになりましたが、同じSQL Serverインスタンス内（同一可用性グループ内を含む）での複数データベースにまたがるトランザクションはサポートされていません。
しかしAlwaysOn FCI + SANLess ClustersではAlwaysOn可用性グループを使わないため、上記の分散トランザクションの制約はありません。
B) システムデータベースの複製について
AlwaysOn 可用性グループではユーザーデータベースはプライマリーからセカンダリーレプリカへと複製されますが、システムデータベースの以下の情報に関しては、個々のインスタンスが個別に保持する形になり、複製されません。
- master データベースに格納されている、アカウント情報
- msdb データベースに格納されている、SQL Server エージェントジョブ
これらの情報は自動での複製は行われないので、手動で可用性グループを構成する両ノードで作成する必要があります。
しかし、AlwaysOn FCI + SANLess Clustersの場合は、レプリケーション対象ボリュームの全てのイメージが同期されます。特定のデータベースのテーブル等を意識してレプリケーションするわけではないため、特定の情報を両ノード上で、手動で作成するような煩雑な運用は不要です。
C) データベースの追加時の管理について
AlwaysOn 可用性グループでは、データベースを新規作成する際に、管理者が「可用性グループの再構成」を行う必要があります。
データベースを新規に追加した際に自動的に可用性グループに登録するためには、CREATE DATABASE に対してのトリガー等を組み合わせる必要があります。
そのため、データベースを作成した後にこの再構成を行わないとデータベースは保護 (複製) されず、この状態でフェールオーバーが発生すると、フェールオーバー後のノード上では、そのデータベースにアクセスできない状態となります。
しかしAlwaysOn FCI + SANLess Clustersでは、新たに作成されたデータベースは自動的に保護対象となります。よって、よってAlwaysOn 可用性グループと比較して、設定忘れのようなヒューマンエラーによるリスクを低減することができます。
D) クラスターノード構成の自由度について
SQL Server 2014までのAlwaysOn 可用性グループで「同期コミットモード」として構成している場合には、2台のサーバー間でのみ自動フェールオーバーが可能となっていました。
そしてSQL Server 2016のAlwaysOn 可用性グループで「同期コミットモード」として構成している場合は、3台のサーバー間で自動フェールオーバーができるようになりました。
AlwaysOn FCI + SANLess Clustersの場合はAlwaysOn 可用性グループを使っていないので、SQL Serverのクラスターにノードが参加していればフェールオーバー対象となります。
よって、台数が多い場合（4台以上）の自動フェールオーバー対象の設定変更については、SANLess Clusterにメリットがあります。
以下の図のような、共有ストレージ構成を含めた柔軟なマルチノード構成も可能です。
SQL Server Standard EditionのAlwaysOn可用性グループの制約
SQL Server 2016からはStandard Editionライセンスでも「AlwaysOn 可用性グループ」を使えるようになりましたが、ここでは、代表的な制約事項について説明します。
まず、SQL Server Standard Editionの制約を説明する前に、Enterprise Editionの可用性グループの特徴を挙げてみます。
- 複数のサーバー上でSQL Serverのインスタンスが稼働する
- プライマリーのDBからセカンダリーレプリカのDBへデータ同期が可能で、共有ストレージを使用せずにクラスターを構成可能
- 一つの「可用性グループ」に複数のデータベース（例：販売DB、生産DB、人事DB）を所属させ、可用性グループ毎にフェールオーバーさせることが可能（関連する複数のデータベースをまとめてフェールオーバーさせることができる）
- 「可用性グループ」という一つの固まりで複数のデータベースを管理すれば、それらの複数のデータベースは常に同一のサーバー上でプライマリ（又はセカンダリ）として機能する
- セカンダリーレプリカへの読み取り専用アクセスもサポートされており、読み取り処理の負荷分散ができる
これに対し、SQL Server 2016 Standard Editionの可用性グループには以下の特徴と制約があります。
- 複数のサーバー上でSQL Serverのインスタンスが稼働する
- プライマリーのDBからセカンダリーレプリカのDBへデータ同期が可能で、共有ストレージを使用せずにクラスターを構成可能
- 一つの可用性グループには一つのデータベースしか割り当てることができない
- フェールオーバーは可用性グループの単位で実行されるので、複数の可用性グループが別々のサーバー上でプライマリーとして稼働する状況が発生し得る
- Standard Editionの可用性グループではセカンダリーレプリカを読み取り専用で使用することもできないため、読み取り処理の負荷分散が不可能
従って、下図のような状態となってしまった場合、販売DBと人事DBを連携させることができません。
複数のデータベースを使用する場合、「可用性グループ」という存在をかなり意識した運用や作り込みが必要になると言えるでしょう。
一方で、AlwaysOn FCI + SANLess Clustersの場合はどうなるでしょう？
こちらは極めてシンプルなアクティブ–スタンバイ型のクラスター構成で、データベースのインスタンスはアクティブ上のみで稼働します。「可用性グループ」というフェールオーバーの単位もないため、Standard EditionのAGの場合のように、どちらのサーバー上でそれぞれのAGのプライマリーが稼働しているかをあえて意識するような必要はありません。DataKeeperが提供するレプリケーションボリュームに配置するだけでこれらの制約から解放されます。
ここまで解説してきた内容も含めて、15の観点から４つのパターンの比較表を作成してみました。
まとめ
- SQL Server 2016の登場後もSANLessClusters構成の優位性は変わらない
- SQL Serverの可用性を高めるにはDataKeeper ClusterEditionの利用が最適
今回詳しく紹介しきれなかった項目は、またの機会に解説してみたいと思います。
最後までお付合いいただき、どうもありがとうございました。
関連情報
SIOSのSANLess（WSFC＋DKCE）Clusters ソリューション
Microsoft Azure上での可用性の更なる向上について
関連資料
