2015.07.07

KCPS上でSQL Server の冗長化を実現 – MSSQL AlwaysOn機能

クラウドサービス開発部 松本です。Microsoft社のサーバ関連製品を担当しています。KCPSでは、システムの構築にあたりMicrosoft SQLサーバを手軽にご利用頂けるよう、ライセンスを月額提供するスキームを用意しています。MS SQLサーバはもちろん単体でのご利用も可能ですが、「AlwaysOn※」と呼ばれる高可用性を実現する機能を備えています。今回は「AlwaysOn」について、その機能及びKCPS上での構築例についてご紹介します。なお、以下に説明する構築例の作成は、Microsoft社エンジニアの協力の元、実施したものになります。
※「AlwaysOn」には厳密には「AlwaysOn可用性グループ(AG)」と「フェールオーバークラスターインスタンス(FCI)」という2つの技術が含まれますが、本稿では前者について解説しています。

1.AlwaysOnの機能

AlwaysOnの詳細については、Microsoft社の説明サイトをご参照頂きたいと思いますが、例えば以下のようなメリットが挙げられます。

1.複数SQLサーバでの冗長構成(Secondary最大4台)が可能
2.ReadOnlyアクセスの処理やバックアップをSecondaryで実施することによる負荷分散が可能
3.同期/非同期の複製モードが用意されており、構成に応じた設定が可能

図1
<図1> AlwaysOn のイメージ

今回は、KCPS 東日本リージョンにSQL01(Primary), SQL02(Secondary) を、西日本リージョンにSQL03(Secondary)の、計3台のSQLサーバを構築します。構築後、以下のケースの動作を確認します。

(1) 手動系切替
・手動でPrimary/Secondaryを切り替える手順(サーバメンテナンス時、片系ずつサーバ停止する必要がある場合を想定)の確認

(2) 障害時動作
・SQL01(Primary)障害時、同一リージョン内のSQL02(Secondary)でサービス継続できることの確認(サーバ単体障害時の対策)
・SQL01,SQL02の両方が障害時に、別リージョンのSQL03(Secondary)でサービス継続できることの確認(BCP/DR対策を想定)

図2-1 図2-2 図2-3 図2-4
<図2> 今回の検証のイメージ

2.前提条件

SQL Server AlwaysOn環境の構築には以下が必要となります。
・OS: Windows Server 2008以降
ただしWindows Server 2008の場合、OSはEnterprise Edition以上が必要(Standard不可)。Windows Server 2012以降の場合、OSはStandard Editionの使用が可能。
・MSSQL: MSSQL2012以降、Enterprise Edition (Standard不可)
・全てのSQLサーバが同一ドメインに参加していること
・全てのSQLサーバが同一フェールオーバークラスタに所属していること
・SQLサーバ以外のサーバでファイル共有クォーラムを持つこと
今回の構築例では、OSはWindows Server 2012R2、MSSQLはSQL2014を使用しています。ファイル共有クォーラムはAD/Clientサーバ上に配置しています。

3.基本設計

今回の構築例の設計は以下の通りです。
・SQL01がPrimary、SQL02を同期モードのSecondary、SQL03を非同期モードのSecondaryとする。
・東リージョンにADサーバを構築し、SQL01,SQL02,SQL03 を同一ドメイン(alwayson.local)に参加させる。
・ADサーバがSQLクライアントとなり、SQLアクセス(insert)を実施する。

図3
<図3>今回の環境

・今回は構成例ですのでADサーバが1台しかありませんが、実際には、ADサーバはお客様オンプレ環境にあるケース、KCPS上に東西で2台構築し冗長を取るケース等が考えられます。また、WEBサーバ等のアプリケーションサーバがSQLサーバのクライアントになるかと思います。
・各サーバに割り当てる実IPの他、セグメント毎にWindowsフェールオーバークラスタ用のVIP(図中のcluster)及び、クライアントからのSQLアクセスを受け付けるVIP(図中のlistener)が必要になります。
・同期モードと非同期モードの違いは、同期モードではSecondaryにデータ更新内容を同期し、Secondaryから応答を受け取ってからトランザクション完了となります。一方、非同期モードではSecondaryの応答は待ちません。そのため、Primaryの障害発生時、同期モードであれば直前までの同期が保証されますが、非同期モードの場合はずれが発生する可能性があります。一方、同期モードのデメリットとして、応答を待つ分処理速度の低下が発生し、また、Secondaryに障害発生した場合、Secondaryの障害を検知し切り離すまでの間、処理遅延が発生することになります。

4.導入手順

(1) 基本設定
・必要なインスタンス(今回は4台)をポータルから作成します。OSはWindows Server 2012R2です。
・ADサーバを構築し、SQL01/02/03をドメイン参加させます。
(2) SQL Server 2014 のインストール
・SQL01/02/03にSQL Server 2014をインストールします。
・ADサーバはSQLクライアントとするため、SQL Serverの管理ツールのみをインストールします。
(3) フェールオーバークラスタの作成
・SQL01~03でフェールオーバークラスタを構成します。

図4<図4>フェールオーバークラスタの構成画面

(4) AlwaysOnの構成
・SQL01(Primary)で、複製対象となるデータベースを作成します。今回はtestdbとしています。
・AlwaysOn 可用性グループを作成し、SQL02,03をSecondaryレプリカとして追加します。
・SQLクライアントからのアクセス先IPとして、listener(VIP)を設定します。
・今回の環境の場合、KCPS東側内部でのIP割当ては、SQL01 172.25.1.111, SQL02 .112, listener .116 としていますが、クライアントは接続先をlistenerのIPにしておけば、系切り替わり時に設定を変更する必要なくアクセスを継続できます。(DNSを参照し名前でのアクセスも可能です。)

図5<図5>AlwaysOnの構成画面

(5) テストアクセス
・今回の構成例では、ADサーバ上にSQL文を連続実行するスクリプトを用意し、listenerのIP(VIP)を指定して接続し、DBへの書き込み(insert文の実行)を行います。
・繰り返し実行するSQL文の内容は以下の通りです。

・テーブル InsertTable に対し、1回SQLを実行する毎に、ServerName(SQL01/02/03のどのサーバが処理しているのか)と、InsertTime(insertが実行された時刻) を記録します。
・通常時は全てSQL01にて処理が行われます。

5. 切替動作確認

(1) 手動系切替
・手動でSQLサーバのPrimary/Secondaryを切り替える手順の確認を行います。(サーバメンテナンス時、片系ずつサーバ停止を行う必要がある場合等での実施を想定)
・SQL01(Primary)とSQL02(Secondary)の役割の切替を、SQL Server Management Studioの管理画面から実施します。
・1秒間隔でinsertを実行するSQL文を回しながら切替を行い、影響時間を測定します。
・今回の環境で手動系切替を実施したところ、約11秒で切替が完了しました。
・結果は下図の通りで、SQL01の処理がSQL02に移動していることが分かります。15:13:30に手動切替のオペレーションを実行し、切替完了後の15:13:41から処理が再開されています。
・クライアントはlistenerのIP(VIP)にアクセスしているので、切替時のクライアント側での対応は必要ありません。なお、系切り戻しも同様の手順で実施可能です。

図6
<図6>手動系切替時のアクセス先

(2) 障害時動作(サーバ単体障害)
・SQL01(Primary)障害時、同一リージョン内のSQL02(Secondary)でサービス継続できることの確認(サーバ単体障害時の対策)を行います。
・検証手順として、SQL01(Primary)のOSを、NotMyFaultというMicrosoft社のツールで強制終了させます。(shutdownによる正常終了ではなく、障害による停止(BSOD)相当の落とし方にするためです。)

図7<図7>NotMyFault画面

・1秒間隔でinsertを実行するSQL文を回しながらSQL01を強制終了し、影響時間を測定します。
・今回の環境で切替を実施したところ、約23秒で切替が完了しました。
・結果は下図の通りで、SQL01の処理がSQL02に移動していることが分かります。15:38:30にSQL01を強制停止後、切替完了後の15:38:53から処理が再開されています。
・なお、SQL01が復旧した場合、自動的にSecondaryとして組み込まれ、データ同期が終われば系切り戻しが可能になります。

図8
<図8>SQL01障害における自動切替時のアクセス先

図9
<図9>SQL01障害時のダッシュボード

(3) 障害時動作(東日本全体の障害)
・SQL01,SQL02の両方が障害となった場合、別リージョンのSQL03(Secondary)でサービス継続できることの確認(BCP/DR対策を想定)を行います。
・SQL03はsecondaryですが、異拠点のため、非同期モードかつ自動フェールオーバなしに設定しています。(これは、BCP/DR用途として標準的な設定となります。)非同期モードにしているのは、伝送遅延によるトランザクションへの影響がないようにするためであり、自動フェールオーバなしにしているのは、ネットワーク障害による予期せぬ切り替わりが発生しないようにするためです。
・このパターンの障害の場合、SQL01/02と、SQL03のネットワークセグメントが異なり、listenerのipも異なるため、SQLサーバの管理者によるSQL03への手動切替、また、SQLクライアント側でのアクセス先の変更作業が必要となります。
・SQL01(Primary), SQL02(拠点内Secondary)のOSを、NotMyFaultというMicrosoft社のツールで同時に強制終了させます。
・1秒間隔でinsertを実行するSQL文を回しながらSQL01/SQL02を強制終了し、切替を行います。本ケースの場合、手動切替が必要となり、切替時間の測定にはあまり意味がないため、手動切替の手順概要を説明します。

手順1: SQL01/SQL02 の停止
・SQL01/SQL02をNotMyFaultを使用して強制停止させます。
・結果として、Windows フェールオーバークラスタの過半数のノードが停止するため、クラスタが維持できなくなります。

手順2: SQL03でのクラスタの強制開始と、SQLサーバの強制フェールオーバー
・SQL03 1台でクラスタを強制再開します(詳細手順は割愛します)。クラスタを強制再開後、SQL03をPrimaryに手動切替します。切替後、listener(VIP)がKCPS(東)内のIP(172.25.1.116)から、KCPS(西)のIP(172.26.1.116)へ変更され、KCPS(西)のIPを指定してSQL03へアクセスすることが可能になります。

手順3: クライアント側でのIP変更とSQL03へのアクセス
・クライアント側で設定しているlistenerのIPアドレスをKCPS(東)内のIP(172.25.1.116)から、KCPS(西)のIP(172.26.1.116)へ変更し、アクセスを再開させます。

図10
<図10>SQL01/02障害における手動切替時のアクセス先

図11<図11>SQL01/SQL02障害時、SQL03へ手動切替後のダッシュボード

6.おわりに

SQL AlwaysOn についてご紹介しましたが、機能や基本動作について、ご理解頂く手助けとなれば幸いです。KCPSでは、MS SQLサーバのライセンスを月額提供しており、仮想サーバ、ネットワーク、ストレージとあわせてのワンストップでのご提供が可能です。KCPS上での高可用性システムの構築において、SQL AlwaysOnは非常に有効的なツールとなりますので、ぜひ導入ご検討頂ければと思います。

カテゴリ
タグ

KDDI株式会社 プラットフォーム開発本部
プラットフォーム技術部

松本 健太郎

新着記事
タグ
アーカイブ
カテゴリー
Contact
TOP