SQL Serverの高可用性を実現するなら、SQL Serverの機能であるAlwaysOn Availability Group(以後、AlwaysOn 可用性グループ)、またはAlwaysOn Failover Cluster Instance(以後、AlwaysOn FCI)のいずれかの利用を検討することになるでしょう。
さらに、AlwaysOn FCIを使用する場合には、サイオスのレプリケーション・ソフトウェア DataKeeper Cluster Edition（以後、DKCE)と組み合わせることで、更に多様な機能・コスト面でのニーズに対応することができるようになります。
ここでは、3つの構成パターンを、7つのポイントで比較していきます。ニーズに合わせた方法をご検討ください。
AlwaysOnとは
AlwaysOnとは、SQL Serverで提供される機能で、高可用性を実現するための機能の総称です。ここでは、AlwaysOnの基本的な機能について解説します。
【1-1】高可用性とは
高可用性とは、システムにおいてサービス停止時間が短いことを指す言葉で、HA（High Availability）と表すこともあります。システムの停止は業務への支障を与えるだけでなく、ビジネスチャンスの喪失などを招くため、企業が運用するシステムには高可用性が求められます。
高可用性を実現するためには、障害発生時の切り替え先としてサーバを冗長構成にする、高負荷による障害を防ぐために処理の負荷を分散させるなどの対策が必要です。
【1-2】AlwaysOnの概要
AlwaysOnとは、その名の通り「常時稼働」を実現するために複数の機能が集まったもののことです。AlwaysOnが実装される以前は、可用性を向上させるために複数の機能を組み合わせて利用する必要がありました。
しかし、複数の機能を組み合わせる設定に手間がかかったり、復旧手順が複雑でダウンタイムが増加したりするという課題があったのです。
これらの課題を解決するために提供されたのが、高可用性を実現するための機能をまとめたAlwaysOnです。
【1-3】AlwaysOnでできること
AlwaysOnの各機能を使うことで、様々な構成でシステムの可用性を高めることが可能です。例えば、複数のSQL Serverで冗長構成を組む、セカンダリサーバに処理やバックアップをさせることで負荷を分散させる、などの対応が可能になります。
AlwaysOnの主な機能として、AlwaysOn可用性グループとAlwaysOn FCIがあります。それぞれの詳細については後述しますが、AlwaysOn可用性グループはミラーリング機能に相当するもの、AlwaysOn FCIはフェールオーバ機能に相当するものです。
AlwaysOnが登場するまでは、可用性の高い構成を実現するためにはSQL Server以外の製品も駆使する必要があり、運用が複雑になるケースも少なくありませんでした。
しかし、AlwaysOnによってサーバ管理のインターフェースが改善され、シンプルな運用が可能になったのです。また、従来は自動フェールオーバに監視サーバが必要でしたが、可用性グループを使うことで監視サーバを設置しなくても利用できるようになっています。
AlwaysOnでは待機サーバをアクティブスタンバイとして有効活用できるようになったり、待機サーバからのバックアップが可能になったり、性能も向上しています。
複数の機能を組み合わせることで可用性向上のための手段が増え、柔軟な構成が実現できるようになりました。
AlwaysOnを使った3つの構成パターン
パターン1) AlwaysOn可用性グループを利用する。
AlwaysOn可用性グループとは、データベースの高可用性を実現するために複数のサーバで構成するグループのことをいいます。
Windows Server Failover Clustering（以後、WSFC）とデータベースミラーリング機能を合わせたような機能で、簡単な設定で可用性を向上させることが可能です。
WSFCはWindows Serverの機能のひとつで、複数のサーバを束ねて1台のサーバとして運用し、稼働しているサーバに障害が発生したとき待機しているサーバに自動で切り替えることで、システムダウンを防ぐという仕組みです。
一方、データベースミラーリングとは、データベースを複製して障害などが起こったときに複製側に切り替えることで可用性を高める機能のことをいいます。
WSFCの場合は複数の共有ディスクを使う必要がありますが、AlwaysOn可用性グループでは共有ディスクを使うことなくクラスター構成を組むことができるようになりました。
AlwaysOn可用性グループを使って行われるデータベースの複製は、「同期モード」と「非同期モード」を選択できるようになっています。
同期モードの場合、プライマリからセカンダリへログが転送されたことを確認した段階で処理が完了します。一方、非同期モードはパフォーマンス重視のため、セカンダリがログを受け取ったことは確認しません。
同期モードは障害発生時のフェールオーバとして、非同期モードは災害復旧の用途として主に利用されます。
AlwaysOn可用性グループはデータベースミラーリングとよく似た機能ですが、いくつか違いがあります。
例えば、データベースミラーリングではセカンダリを1台しか設定できないのに対し、AlwaysOn可用性グループではセカンダリを4台まで追加することが可能です。
また、セカンダリの読み取りをリアルタイムで行うこともできます。
AlwaysOn可用性グループの利用によって、同期モードと非同期モードのセカンダリを同時に配置する、本番環境へ負荷をかけないバックアップの取得などが可能になります。
監視サーバも不要になるため、コスト削減が期待できる点もメリットです。
パターン2) AlwaysOn FCIを利用する。
AlwaysOn FCIは、WSFCのリソースとなるSQL Serverインスタンスのことをいいます。
AlwaysOn可用性グループがデータベースレベルの高可用性を実現するのに対し、AlwaysOn FCIではサーバレベルでの高可用性を実現できます。
ひとつの共有ディスクに対して複数のSQL Serverを接続することで、片方のサーバに障害が発生しても、もう片方のサーバが処理を引き継いで、システムダウンを防ぐという仕組みです。
AlwaysOn FCIによって複数の冗長ノードが存在している場合、平常時はAlwaysOn FCI内のノードのひとつがWSFCリソースを所有しますが、障害などが発生するとリソースの所有権が別のノードに移動し、処理を継続することが可能になります。柔軟にフェールオーバポリシーを設定することも可能で、フェールオーバを発生させるレベルを調整してより細かく障害を検知することができます。
AlwaysOn FCIにはレプリケーション機能は含まれていないため、クラスターを構成するには共有ディスクが必要となります。
そのため、共有ディスクに障害が起きると処理ができなくなるという潜在リスクがありますが、構成がシンプルで運用しやすいという点がメリットです。
また、SQL Server 2012からはWSFCが強化され、可用性の向上だけでなく性能向上も実現されています。
パターン3) AlwaysOn FCIを、DKCEと組み合わせて利用する。
DKCEとWSFCを連携することで、SQL Serverの高可用性を実現できます。
DataKeeperを仮想的な共有ストレージとして認識させることでHAクラスターを構成することができるソフトウェアです。
DKCEが共有ストレージの役割を担うため、AlwaysOn FCIでも共有ディスクを必要とせずにクラスターを構成することができます。共有ディスクが不要になることで、コストの削減が可能になるだけでなく、共有ストレージが利用できないパブリッククラウド環境などでも利用できるというメリットもあります。
AlwaysOn FCIとDKCEで構成することで、制約に縛られることなく、シンプルな構成が可能です。また、物理、仮想、クラウドと様々な環境で利用できるため、それぞれの環境に柔軟に対応可能です。
パターン1,2,3いずれの場合も、クラスターウエアとしてはWSFCを利用可能です。
では、具体的に７つのポイントを見ていきましょう。
SQL Server環境で高可用性を実現するために考慮したい、 7つのポイント
ポイント1) SQL Server Standard Editionでの利用可否
まずコスト面に直結するライセンス費用の比較ですが、AlwaysOn可用性グループを利用するには、高価なSQL Server Enterprise Editionが必要です。
一方でAlwaysOn FCIはSQL ServerのStandard Editionでも利用することが可能なため、ソフトウエアライセンスの費用を抑えることが可能です。
AlwaysOn FCIにDKCEを組み合わせる場合も、SQL ServerはStandard Editionの利用が可能なため、ソフトウエアライセンスの費用は抑えられます。
ポイント2) 共有ディスクの必要性
AlwaysOn可用性グループを利用する際には、共有ディスクは不要です。
AlwaysOn FCIでクラスター構成を組む場合は共有ディスクが必要です。一般的に、共有ディスクはハードウエアの価格や管理面でのコストがかさむ要素と言えるでしょう。
AlwaysOn FCIにDKCEを組み合わせる場合には、レプリケーションされたローカルディスクを記憶域として利用でき、共有ディスクが不要となります。
ポイント3) 共有ディスク（SAN）のSPOFリスクの問題
AlwaysOn FCIで使用する従来の共有ストレージ（SAN）は、潜在的な単一障害点となるリスクがあります。
AlwaysOn FCIにDKCEを組み合わせる場合、共有ストレージを利用する代わりにDKCEがリアルタイム、ブロックレベルのレプリケーションでローカルストレージを同期します。（WSFCからはあたかもそこに共有ストレージがあるかのように見えます。）共有ディスクが不要となるため、そこに潜在するSPOFのリスクも解消されます。
ポイント4) レプリケーションの効率
AlwaysOn可用性グループを、高可用性実現のために必要な同期レプリケーションモードに設定する場合、アプリケーション書き込み性能が遅くなります。
マイクロソフトはそれを以下のように説明しています。
「・・・トランザクション遅延の増加を代償として、パフォーマンスより高可用性を重視する」
AlwaysOn FCIとDKCEを組み合わせれば、効率的なブロックレベルのレプリケーションにより、同期レプリケーションの性能への影響を最小化できます。また、DKCEは非同期レプリケーションもサポートしています。
ポイント5) レプリケーション可能なデータの種類
AlwaysOn可用性グループはSQL Serverのデータのみを複製し、他のデータタイプはレプリケーションの対象外です。
AlwaysOn FCIとDKCEの組み合わせでは、SQL Serverのデータだけではなく、アプリケーションが利用する他のデータも同時にレプリケーションすることが可能です。
ポイント6) データベースの追加削除時の管理の容易さ
AlwaysOn可用性グループは、データベースが追加または削除されるたびに、手動での再設定が必要です。
AlwaysOn FCIなら、データベースが追加（または削除）されたとき、自動的に保護スキームにそれらを組み込むため、管理に要する時間を節約し、人的ミスのリスクを減らします。（DKCEを組み合わせた時も同様です。）
ポイント7) クラウドでの利用
多くのパブリッククラウド環境では、共有ディスクを利用できません。
AlwaysOn可用性グループは共有ディスクを必要としないため、クラウドでそのまま利用できます。
AlwaysOn FCIは、共有ディスクを必要とするため、通常はクラウドでの利用はできません。
ただし、AlwaysOn FCIにDKCEと組み合わせれば 、WSFCから共有ディスクとして認識されるため、クラウドでの利用が可能になります。
現状のシステム資産に７つのポイントを加味して、コスト効率の良いシステムを選択していくことが大切です。
まとめ：構成パターン別の7つのポイント比較表
