クラウドエンジニアブログ

SQL Database 透過的フェールオーバーのご紹介

新井

新井

はじめに

5/11 に透過的なフェールオーバー機能がプレビューとなりました。

これにより、SQL Database のアクティブ Geo レプリケーションにおいて、データベースロールの切り替え後も同じ接続文字列を利用し続けることができるようになりました。どんどん進化するサービスとしての SQL Server の魅力について少しでも皆さんと共有できればと思います。

今回は、本機能の仕組みを簡単に説明しながら実際にどのように機能しているかを画面ショット付きでお伝えしてみます。

  • しくみと今までとの比較
  • 実装

イメージ図としてはこんな感じです。

仕組み
(クリックで拡大)

なお、タイトルにもございますように本機能はパブリックプレビュー段階で正式にリリースされた機能ではございません。将来的に全ての挙動が変更となる可能性が有ります事、予めご了承ください。

しくみ

アプリケーションがデータベースに接続する際には、接続先を識別する必要があります。従来の仕組みでは、データベースの論理サーバー名を基に識別していました。

従来の仕組み
(クリックで拡大)

上記の図で言うと「sv1.database.windows.net」です。大切なことは、この接続先情報を持っているのはアプリケーション側であるということです。ですから、この状態で地理的なフェールオーバーが発生すると・・

地理的なフェールオーバーが発生
(クリックで拡大)

データベース側は切り替えに成功しても、アプリケーション側は読み取り専用サーバーに格下げされた「sv1.database.windows.net」に対して引き続き書き込みを行おうとして、エラーで異常終了するという事態が発生していました。もったいない!!

今までの仕組みはどこに考慮点があったのでしょうか?そうです。後々変更される可能性がある文字列をアプリケーション側に渡していたというところなのです。であれば、初めから不変の文字列をアプリケーション側に渡しておけばこの問題は発生しないということになります。それが今回の「透過的な」フェールオーバーの仕組みとなります。

「透過的な」フェールオーバーの仕組み
(クリックで拡大)

透過的なフェールオーバー機能においては、初めから

  • 書き込み可能な論理サーバーに誘導される「固定の」FQDN
  • 読み取り専用な論理サーバーに誘導される「固定の」FQDN

の 2 種類を生成しておき、これをアプリケーション側に渡しておくのです。これらの文字列はフェールオーバーしようが変更されません。

そして、これらのアドレス (FQDN) は DNS の機能を用いて皆さんの気づかない内に、本当の論理サーバー名に変換されています。上記の図で言うと、

  • 書き込み可能 FQDN = sv1.database.windows.net
  • 読み取り専用 FQDN = sv2.database.windows.net

という形で変換されます。

この状態で地理的なフェールオーバーが発生すると、今まで通りデーターベースサーバーのロールが切り替わった後に、DNS の名前解決レコードが自動的に書き換えられるのです。

フェールオーバーが発生
(クリックで拡大)

つまり、データベースの切り替えに合わせて

  • 書き込み可能 FQDN = sv2.database.windows.net (切り替え前は「sv1」)
  • 読み取り専用 FQDN = sv2.database.windows.net (変更無し)

という形で変換されるようになります。FQDN 自体は変更されていないので、アプリケーション側は何一つ気づくことなくリージョン間の切り替えが成功するわけです。

なお、読み取り専用 FQDN については現段階では変化しない仕様のようです。これは、フェールオーバーするシナリオを考えれば致し方ない事なのかもしれません。つまり、プライマリ側に問題があったためにフェールオーバーした場合、「読み取り専用 FQDN」が旧プライマリになったとしてもアクセスできない事態が想定できるためです。

実装

それでは、流れで見てみましょう。なお、本手順においては、データベースが作成された後からの流れとさせていただきます。

「データベース」-「geo レプリケーション」と移動し、画面中央のインフォメーションを押下します。

手順
(クリックで拡大)

最低限、「セカンダリサーバー」「フェールオーバーグループ名」の 2 箇所を設定して構成します。後者は、DNS のレコードの文字列に利用されますので慎重に!

手順
(クリックで拡大)

これで設定は完了です

接続文字列の確認

執筆時点の 7/3 においては、接続文字列の確認画面にすんなりたどりつけなくて少し画面ショットが多くなってしまいました。

「データベース」-「概要」と移動し、画面中央の「サーバー名」を押下します。

手順
(クリックで拡大)

「フェールオーバーグループ」と移動し、画面中央の「フェールオーバーグループ」を押下します。

手順
(クリックで拡大)

画面中央に表示された「読み取り/書き込みのリスナーエンドポイント」と「読み取り専用のリスナーエンドポイント」の二つが今回の目的の文字列となります。

手順
(クリックで拡大)

切り替え前テスト

前項の手順で得られた二つの文字列を NSLOOKUP コマンドにて確認すると、それぞれのレコードの名前解決具合が判ります。

NSLOOKUP コマンド
(クリックで拡大)
  • 書き込み可能 FQDN = atestfg.database.windows.net = atestsqlsv1.database.windows.net
  • 読み取り専用 FQDN = atestfg.secondary.database.windows.net = atestsqlsv2.database.windows.net

となっている事がわかります。つまり、アプリケーションは、

  • 書き込みしたい場合は「atestfg.database.windows.net」
  • 読み取りのみで良い場合には「atestfg.secondary.database.windows.net」

となります。裏のサーバー名は気にする必要はありません。

フェールオーバー

では、フェールオーバーをさせてみましょう。先ほど接続文字列を確認した画面に移動してください。「サーバー」を選択して、コンテキストメニューから「フェールオーバー」を選んで完了です。

フェールオーバー
(クリックで拡大)

切り替え後テスト

前項までに得られた文字列を再度 NSLOOKUP コマンドにて確認すると、レコードの名前解決具合に変化があったことがわかります。

切り替え後テスト
(クリックで拡大)
  • 書き込み可能 FQDN = atestfg.database.windows.net = atestsqlsv2.database.windows.net
  • 読み取り専用 FQDN = atestfg.secondary.database.windows.net = atestsqlsv2.database.windows.net

となりました。アプリケーションから見た時の文字列は不変ですが、裏で解決される名前が変わったことにより、データベースとしての切り替えは行われています。あくまでプライマリ側だけですが。

システム全体で考えた時にはデータベースの事だけを考えていれば良いというものではありません。ですから、本機能で全てが簡単になったわけではありませんが、データベースの災害対策というのはウェイトとしては非常に大きい事は間違いありません。

どんどん便利になりますね。


次回予告


【総合】お問い合わせ

ソリューションに関する全般的なお問い合わせはお気軽にご相談ください。

ピックアップ

セミナー情報
クラウドエンジニアブログ
clouXion
メールマガジン登録