このページに書いてあること
MSSQLを冗長化しているインフラ構成において、前段のWebアプリからDBに接続する際、DBエラー発生時のフェールオーバー処理ができないケースがあるので備忘メモ。
- ピアツーピアトランザクション方式によるMSSQLへのフェールオーバーは自動的には実施できない。
- P2Pの場合はアプリ側でフェールオーバー処理を作り込まないといけない。
- Always On フェイルオーバークラスタリングとかならできる。
前提
- 以下の様な構成のシステムを想定。
- WebアプリはJavaまたは.NET Core(.NET3.1)
問題と解決
この構成の時、WebアプリからMSSQLにアクセスするケースがあります。
通常は片方を1号機にしてもう片方を2号機とする構成で、常に片系にアクセスする様な構成をとることが多いはずです。
で、MSSQLにはいくつかのレプリケーションが製品として用意されているのですが、この時に昔からある方式の「ピアツーピアトランザクション」を使っていると面倒なことになります。
Javaの場合はMSが配布しているMSSQLドライバ、.NET Coew3.1の場合は.NETの機能によりDB接続を実現しますが、接続文字列によるDBのフェールオーバーが使えないです。
要は接続文字列に「failoverpartner」を指定してのフェールオーバーができません。
この構成ではfailoverpartnerは使用できません。みたいなエラーが出ます。
しかも悪いことに、mssqlドライバや.NETのフェールオーバーは接続文字列でのフェールオーバーしかサポートしていません。
よって、運悪くピアツーピアトランザクション構成のMSSQLに当たってしまった場合は、Javaだろうが.NETだろうが、自前でフェールオーバー機能を作り込むしかありません。
もしフェールオーバーする用件があるなら、Always OnやADを使っての環境で構築する様に注意しましょう。
DB接続に失敗したら、コネクションを別途作って2号機にアクセスしないといけません。
やり方はいくつかあると思います。
例えば、単純にWebアプリに接続設定を2つ持たせて、エラーを検知したらもう一つの設定を使う様にする。先ほどのせた図の通りにコネクションプールを形成しておく方式です。
もう一つは、DBの異常を検知したら前段のWebアプリごと落としてしまうってのはどうでしょう。常に1系統のみを使います。
別アプリからWebアプリへの経路を冗長化することで、WebアプリとMSSQLの通信をシンプル化しました。こうすると、メッシュトポロジは崩れますが、システム構成はシンプルになってきますね。
どこからどこまでを一本化するかというのが議論になると思います。
DB冗長化を生かし切れていないという方もいますが、そもそもDBの片系が落ちるって異常事態でして、大事なのはシステム全体がサービスを続けられることではないでしょうか。メッシュ構造を維持することではないですよね。
ということで、最近はこの構成にしてシンプルなネットワークを設計する様にしています。
話が逸れましたが、MSSQLでフェールオーバーをしたいならピアツーピアトランザクション以外のレプリケーション方式を使う様にしましょう。