各種のレプリケーションの場合
プロダクション側 SQL Serverインスタンスが障害でダウンすると、スタンバイ側を新たなプロダクション インスタンスとするために、とても面倒な手動での作業が必要になります。それには一定期間以上の時間が必要です。また、アプリケーションの接続先も新たなプロダクションインスタンスへ切り替えるための仕組みが必要です。
フェールオーバークラスタリングの場合
SQL Serverインスタンスのフェールオーバー完了までに長い時間が必要になり、フェールオーバー先として選択できるのは比較的近い距離にあるコンピュータ同士に限定されます。また、フェールオーバーの必要性を判断するために必要な SQL Serverインスタンスの稼働状況の確認方法の自由度がとても低いです。
ログ配布
レプリケーションと同じように、プロダクション側 SQL Serverインスタンスとスタンバイ側の切り替え時に多くの労力を必要とします。また、アプリケーションの接続先インスタンスに関しても同様の考慮が必要になります。
データベースミラーリング
スタンバイ側のデータベースを参照することができないので、データの同期が行われているデータベースが存在しているのに有効活用ができません。データベースミラーリングはデータベース単体に対してだけ設定することができるため、アプリケーションでいくつかのデータベースを参照しているような場合には、フェールオーバーが発生するとそれぞれのデータベースが別の SQL Serverインスタンスに属することがあります。
また、データのコピーを 1 セットしか持てない点も多くのユーザから改善点として指摘を受けました。さらに、データ同期方法によっては比較的近い距離にあるコンピュータ同志でのみ構成が可能です。
既存の機能を組み合わせて、高可用性を確保
それぞれに不足する点を克服するために、多くの(主としてミッションクリティカルなシステムで)ユーザが複数の機能を組み合わせて使用するという方法を取り入れました。
たとえば、データベースミラーリングとログ配布。 この組み合わせによって、遠隔地に2つ目以降のデータコピーを確保することができます。あるいは、データベースミラーリングとフェールオーバークラスタリングの組み合わせ。両者を併せて使用することで、データベース単位でのフェールオーバーとSQL Serverインスタンス単位での高可用性が実現できます。
このように、既存の機能を組み合わせることでミッションクリティカルな環境でも充分なだけの高可用性を確保することが充分に可能です。ただ、複数の機能をそれぞれの個別に設定して、さらに各機能を運用、管理するコストは無視することはできません。そのため、製品側でそれらを吸収して新しい機能として実装することが計画され、ついに姿をあらわしたのがAlwaysOnというわけです。
次回の記事で、その具体的な機能を詳しく紹介します。お楽しみに！
