高可用Windowsシステムの研究 SQL Server 2005の高可用テクノロジ編 第1回　DBシステム可用性向上の基礎知識 2．SQL Server 2005の冗長化構成機能 デジタルアドバンテージ 資料提供、技術協力：マイクロソフト 2006/12/22
Page1 Page2 Page3

SQL Server 2005で選択可能な冗長化構成

　DBシステムの可用性を向上させるための基本的な対策は、システムを冗長化（多重化）してバックアップ体制を整え、RPO／RTOの短縮を図ることだ。冗長化に関して、SQL Server 2005では、次のような技術を選択できる。各構成の詳細については後ほど説明するとして、まずは概要を述べよう。

■フェイルオーバー・クラスタ（failover cluster）
　クラスタ（cluster）は「（ぶどうなどの）ふさ、かたまり」などという意味で、情報システムでは、複数のコンピュータをまとめて、そのうち1つのコンピュータが障害で停止しても、それを別のコンピュータでバックアップ（代替）できるように構成し、サービスの可用性や処理性能向上を目指すシステムの意味である。フェイルオーバー（failover）とは、障害が発生したコンピュータに代わって別のコンピュータが機能の提供を続行することを指す。SQL Server 2005のフェイルオーバー・クラスタは、ハードウェア的なアプローチによりデータベースを冗長化する構成である。具体的には、Windows Server 2003が提供するMSCS（Microsoft Cluster Service）の機能を利用して、DBシステムの冗長化を実現する。

　フェイルオーバー・クラスタでは、冗長化構成されたコンピュータ同士でストレージ（ディスク）を共有する。従って障害の原因がストレージではなく、DBシステム側にあるなら、障害発生時もデータの損失は発生しないし、RPO（データ復旧）も不要である。

　フェイルオーバー・クラスタ構成では、待機系サーバが短時間で本番系サーバとして稼働できる状態で待機している。このような構成はウォーム・スタンバイ構成と呼ばれる。障害発生時には、ハードウェアによって自動的に、短時間でフェイルオーバー処理が実行されるので、RTO（ダウン・タイム）はごく短時間（通常は数十秒から、数分程度）に抑えることができる。

　ただし、ディスク障害が発生した場合には、たとえフェイルオーバー・クラスタを構成していても、データベースは最新のバックアップ時点からのデータ損失を起こす。これを復旧するには、バックアップしたデータからデータベースをリストアしなければならない。

■ログ配布（log shipping）
　SQL Server 2005のログ配布機能は、トランザクション・ログ（トランザクションの内容を記録したログ・データ）のバックアップを定期的に転送し、待機系サーバに適用することで、データベースを冗長化する技術である。

　ログ配布では、ログのバックアップ間隔に応じて、障害時にデータ損失（RPO）が発生する。ログ配布のログ・バックアップ間隔は、通常は数分〜数十分程度に設定する。災害時のように、本センターが壊滅状態にあり（プライマリ・サーバのトランザクション・ログが破損しており）、バックアップを取得していない部分のログ情報が取得できない場合、この程度の時間規模でデータ損失が発生する可能性がある。また待機系サーバは短時間で稼働状態に移れるウォーム・スタンバイ構成であるが、障害時のデータ復元・復旧は自動では実行されず、手動での作業が必要になる。

　復旧時間（RTO）については、待機系サーバにまだ適用されていないログが存在する場合には、このログを適用する時間がかかる。ただし通常、待機系のサーバは、配布されたログを常時適用し続けるように構成するので、ログ配布を実施しない単一構成のサーバの障害復旧に比較すれば、RTOは小さい。

■データベース・ミラーリング（database mirroring）
　前出のフェイルオーバー・クラスタがハードウェア的にDBシステムを冗長化する構成であるのに対し、このデータベース・ミラーリングは、ソフトウェア的に冗長化を実現する構成である。具体的にミラーリングでは、SQL Server 2005*の機能により、トランザクション単位でデータベースを待機系と同期する。ソフトウェアで冗長化することから、ハードウェアに依存しない冗長化構成が可能である（本番系と待機系で異なるハードウェアを選択可能）。またこのほかにも、データベース単位で冗長化の有無を選択可能というメリットがある。

* データベース・ミラーリングは、SQL Server 2005 SP1で追加された機能である。現時点では、SQL Server 2005のインストール後、SP1を別途適用する必要がある。

　ミラーリングによるデータベースの同期方法には、「同期」と「非同期」の2種類がある。このうち「同期」方式は、ほぼリアルタイムに本番系サーバ（プリンシパル・サーバ）と待機系サーバ（ミラー・サーバ）でデータベースを同期するので、障害時にも基本的にデータ損失はなく、ごく短時間（数秒程度）でフェイルオーバーが可能である。ただしこれには、プリンシパル・サーバとミラー・サーバ間を高速なネットワークで接続する必要がある。

　一方の「非同期」方式では、リアルタイムの同期は実施しない。このためプリンシパル・サーバとミラー・サーバの接続には低速なネットワークも選択できる。両サーバが遠隔地に存在し、高速接続が不可能な場合など（ディザスタ・リカバリなど）に有効である。代わりに非同期データベース・ミラーリングでは、障害発生時、プリンシパル・サーバでコミット（データベースの更新）されたが、ミラー・サーバにはまだ送信されていなかったデータが存在する場合があり、データ損失が発生する可能性がある。

　同期にせよ非同期にせよ、データベース・ミラーリングでは、本番系と待機系双方のサーバが完全な稼働状態にあるホット・スタンバイ構成になる。同期型の場合には、RTOはほぼ存在せず、RPOも短時間だが、非同期型では一定のRTO／RPOが必要だ。ただし非同期型の構成でも、データ損失などを許容して、ミラー・サーバ側で強制的にサービスを起動すれば、ダウン・タイムを数分程度に抑えることは可能である。

冗長化構成とRPO／RTOの関係

　これまで説明してきた各種冗長化構成と、冗長化しないシングル・サーバ構成とのRPO（復旧ポイント）／RTO（ダウン・タイム）の関係を図示すると次のようになる。

シングル・サーバと各種冗長化構成でのRPO／RTO比較

冗長化によって、RPO／RTOを短縮することができる。業務の必要に応じて、適切な冗長化構成を選択したり、場合によっては複数の冗長化構成を組み合わせたりする。

　この図は、RTO（ダウン・タイム）を横軸に、RPO（復旧ポイント）を縦軸にして、各冗長化構成のRTO／RPOをマップしている。ここでは目安として、両方の軸に「秒」「分」「時」「日」という目盛りを入れたが、冗長化構成によって時間が厳密に決まっているわけではない。実際の構成内容や、障害時の状況（データ損失の状況など）によって、実際のRPO／RTOは変化する。これらはあくまで目安であって、厳密なものではないことをあらかじめお断りしておく。

　冗長化しないシングル・サーバ構成におけるRTO／RPOは、データのバックアップ戦略によって大きく左右される。例えば、毎週フルバックアップ、毎日差分バックアップ、毎時トランザクション・ログ・バックアップを実行しているシングル・サーバが存在したとしよう。この場合、トランザクション・ログを格納しているディスクに障害がなければ、障害発生時もデータ損失（RPO）はない。一方、トランザクション・ログのディスクに障害があれば、RPOは1時間ということになる。一方のRTOは、障害発生時点で存在している最新のフルバックアップを復元し、そのフルバックアップの直後のサブバックアップから直前の差分バックアップまでを順次復元し、さらに、その差分バックアップの直後のトランザクション・ログ・バックアップから、最新のトランザクション・ログ・バックアップを復元するまでの時間になる。

INDEX
	［高可用Windowsシステムの研究］
	SQL Server 2005の高可用テクノロジ編
	第1回　DBシステム可用性向上の基礎知識
	1．DBシステムの可用性向上の要件
	2．SQL Server 2005の冗長化構成機能

　

［高可用Windowsシステムの研究］

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）