今回は、アプリ側の話です。

「SQL Server」をオンプレミスで使っていて、障害や災害の時だけクラウドを立ち上げて使用する場合、
アプリ側でどのような方法でクラウドに切り替えれば良いでしょうか？

似たような問題が下記にも当てはまります。

・「SQL Server」では異なるサーバーに「ミラーDB」を簡単に作れてしまいます。この場合も、ミラー側へ
　の切り替える手段が必要です。

・開発機で作成したアプリを本番機に移行するケースがあります。参照先を開発DBから本番DB
　に変更する手段が必要となります。（SQL Serverテスト環境）

わたしの試した内容を紹介したいと思います。

◆SQL Native Clientを使う方法

SQL Native Client には２つのサーバーを登録でき、最初のサーバが使えないと、次のサーバーを使用するという機能があります。
ミラーを使って冗長化をしてたころ、この方法で、ミラー側のサーバーに切り替えていました。

この方法は、プライマリーのサーバーが生きている場合は、特に問題なく切り替えが行われ使用できますが、シャットダウンしている場合、問題が発生します。

プライマリーが使用できないと判断するまでPCがハングアップ状態（ネットワーク待ち）になってしまい、とても使い物になりません。
アプリを起動させる時にサーバーの死活状態を判断させるロジックを入れたりしてなんとか回避しましたが、アプリが複雑になってしまい、お勧めできません。

◆Winsを使う方法

アプリ側でAサーバーを使用すると定義してあったとします。そしてAサーバーをWinsに「静的に登録」しておきます。
Aサーバーに障害が発生した場合、WinsのAサーバーのアドレスをBサーバーのアドレスに変更すると、アプリはBサーバーにアクセスするようになります。

結構、スムースに切り替えができますが、いくつか問題があるようです。

・Winsサーバー間のレプリケーションで、時間差がある（すぐに反映されない）
・AサーバーがWinsのクライアントであると、Bサーバーのアドレスに変更しても、どんなタイミング
　でAサーバーのアドレスにもどるかわからない。
　Aサーバーは架空のサーバー名で、Winsクライアントでない方が望ましい。
・Winsへの登録を障害時に速やかに実施する必要があり、Winsの管理権限の問題で現実的で
　はないかも．．．

◆Hostsを使う方法

わたしの知るかぎり、この方法が、一番簡単で確実と思っています。

アプリを起動するタイミングで毎回、通常運用のhostsをどこかの共用フォルダーからコピーするようにしておきます。
障害時は、共用フォルダのhostsを障害時用に書き換えます。
障害時にアプリを起動すると、障害時に使用するサーバーにアクセスすることになります。

この方法の場合、各ユーザでのhostsの変更を禁止しておく必要がありますが、Winsの時間差みたいな不安定なことはないので、確実に障害用にサーバーに切り替えることができます。

＜追加＞
●アプリで定義するサーバー名について

これまで、アプリで定義するSQL Server名は、実在するサーバーのサーバー名を使っていました。

ところが、アマゾンクラウドを使い始め下記の問題があり、アプリで定義するサーバー名は、
実在しない「架空のサーバー名」の方が便利だと気付くようになりました。

・立ち会あげる毎にサーバー名は変わってしまう。
・サーバーの機能を複数のサーバーに分散させるケースがある

今は、アプリでは架空のサーバー名を定義して、IPアドレスをWinsやhostsで紐付るようにしています。
（これって、すでに世間の常識だったりして．．．）