SQL Serverの高可用性を考える
SQL Serverを用いたシステム構成を考えるために学習したのでまとめたいと思います。
■はじめに
高可用性をなぜ実現するのか。というのが最近の私の頭の隅から離れない質問です。 個人的にはこの質問についての回答がスムーズにでるシステムと、そうでないシステムがあります。回答がスムーズなシステムは停止したときの影響が大きすぎるということ、そうでないものは影響はあるがある程度許容されるものとなります。後者については私の個人的な意見のため、システム担当からは重要だ！って言われるのですが、その重要性の物差しは人それぞれなのが難しいです。
そんなこんなでSQL Server 2016を用いた高可用性のパターンとメリットデメリットを考えていきたいと思います。こちらの記事はオンプレミスの環境を想定していますので、Azuruなどには当てはまらない点があるかもしれません。
■SQL Serverの高可用性のパターン
SQL Serverの高可用性を実現する手法は下記2パターンについて勉強したことをまとめたいと思います。
- Always on 可用性グループ ( Availability Group：AG )
- Always on フェイルオーバー クラスター インスタンス ( Failover Cluster Instance：FCI )
・Always on 可用性グループ ( Availability Group：AG )
SQL Server 2012以降で登場した機能となります。特徴は複数台のノードでクラスタを構成した際、プライマリのノードからセカンダリレプリカのノードに対してデータの同期を行うことで、各ノードのローカルディスクにデータが保存される仕組みとなっています。ただ、この仕組みを実現するうえでは、ノード間のデータ同期が必要になってくるため性能は出にくい構成となってしまいます。Enterpriseエディションでは3台以上でクラスタ構成を組むことも可能とのことです。イメージ図としては下記となります。
プライマリノードに障害が発生した場合は、セカンダリレプリカにフェイルオーバー（セカンダリのノードがプライマリに昇格）し機能を継続して提供します。プライマリにアクセスする処理は、リスナーに対してアクセスしていればプライマリが変更になった際に最新のプライマリに対してアクセスします。また、クラスタに参加するノードにて投票を行っており、クラスタを構成するノードの半数以上に障害が発生した場合は、処理を停止する仕組みとなっています。
運転面では、masterやmsdbなどは可用性グループで同期されないため各ノードにアカウント等を整備する必要があることと、データベースを追加した場合は可用性グループを再構成しないとレプリカが作成されないためメンテナンス作業は気を付ける必要があります。
・Always on フェイルオーバー クラスター インスタンス ( Failover Cluster Instance：FCI )
SQL Server 2008 R2以前のSQL Serverでおなじみの高可用性の実現パターンとなります。私もこのタイプの高可用性のサーバのメンテナンスをしてきました。特徴としては2台のアクティブ/パッシブ構成のクラスタを作成し、クラスタリソースの共有ディスク上にデータベースファイルを格納することで、障害時に共有ディスク毎パッシブのノードに移動させることで稼働を続ける方式となります。このタイプは共有ディスクを有することから、共有ディスクが単一障害点となってしまう潜在的な問題があります。ただ、構成はシンプルのため運用もしやすいメリットを感じています。
障害時はアクティブのノードからパッシブのノードにクラスタリソースが移動して機能を継続します。
こちらの構成は、masterやmsdbもクラスタリソース配下にあるので、アカウントやデータベースの操作はアクティブ系で操作した内容がフェイルオーバー後も継続するのでメンテナンスは簡単です。
■メリットとデメリット
先ほどの二つの高可用性の実現方法について表にまとめます。
| 項目 | 可用性グループ | フェイルオーバー クラスター インスタンス |
|---|---|---|
| WSFCを構成する必要がある | 〇 | 〇 |
| 共有ディスクを必要とする | × | 〇 |
| 単一障害点が存在する | × | 〇 |
| メンテナンスが容易である | △ | 〇 |
| 性能が出にくい | 〇 | △ |
性能が出にくいについてはノード間の読み書きによるものがあるので、一概に性能がでないというわけではないので注意してください。FCIでも共有ディスクが他のアプリケーションが高IOPSを発生させていたら性能が出ないこともありますので、環境によるところが大きいです。
■終わりに
性能よりも耐障害性を重要視されるため、個人的には可用性グループを推したいと思っています。ただ性能が出にくいという点があるため、十分に性能検証を行ってから商用のリリースを計画したいところです。Virtual boxで可用性グループを構築し機能検証していきたいと思います。
■参考
アイコンは「さくらのアイコンセット」を利用させていただきました。また、Microsoft様の参考ページを列挙します。
