止められないデータベースの高可用性と災害対策：DB2マイスター養成講座（5）（2/2 ページ）

ダウンタイムが許されないシステムにおける可用性の確保は、最重要課題である。ストレージやHAクラスタの導入が必要になるだろう。（編集局）

[小林慶彦，＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

HAクラスタソフトウェアを使った高可用性

　HAクラスタソフトウェアと組み合わせたローカル・フェイルオーバーを使った高可用性の実現について解説します。

　国内でDB2 V8.1に対応する代表的なHAクラスタソフトウェアとしては、以下の4つが挙げられます。

オープンソース
・heartbeat
　http://www.linux-ha.org/

商用製品
・LifeKeeper（SteelEye Technology Inc.）
　http://www.10art-ni.co.jp/product/lifekeeper/
・ClusterPerfect、ClusterPerfect EX（東芝）
　http://cn.toshiba.co.jp/prod/cluster/
・CLUSTERPRO（NEC）
　http://www.ace.comp.nec.co.jp/CLUSTERPRO/

　いずれも、2ノードのアクティブ－スタンバイ構成に対応しています。

■アクティブ－スタンバイ構成のHAクラスタ

図1　2ノードのHA構成

　図1は、2ノードHAクラスタの最小構成です。2台のサーバ（ノード）を使って構成します。プライマリ・サーバ側がDB2のサービスを提供するノードで、セカンダリ・サーバ側が障害発生時にプライマリ・サーバからDB2のサービスを引き継ぐために待機しているノードになります。監視方法はいくつかありますが、通常はハートビート（heartbeat）と呼ばれるパケットを使って相手のノードの生存を確認するのが一般的です。また、オプションとしてDB2のプロセスを監視したり、テーブルスペースへのアクセスを監視するものもあります。

　引き継ぎ対象のリソースは、以下の3つです。

ストレージ
　DB2のリソースは、プライマリとセカンダリの2台が共有しているストレージ上に置きます。データベース・ディレクトリ、テーブルスペース・コンテナー、ログ・ファイルは必須です。インスタンス・ホームも通常は引き継ぎの対象リソースとして扱います。ただし、高速な引き継ぎを行う場合などは、少しでも引き継ぎリソースを減らすためにインスタンス・ホームを共有しない場合もあります。

　データベース・マネージャー構成パラメーターは引き継がれないので、データベース・マネージャー構成パラメーターを変更する場合は両ノードで変更する必要があります。
IPアドレス
　WebアプリケーションサーバなどのクライアントからDB2にアクセスするため、仮想IPアドレス（サービスIPアドレスとも呼ぶ）を設定します。実際にはIPエイリアス（Linuxではeth0:1など）を使いますが、サーバがダウンしてもIPエイリアスを使うことで、クライアントからの接続に影響が出ないようにします。
DB2サービス
　DB2のサービスも引き継ぎます。デフォルトでは自動再始動（autorestart）データベース構成パラメーターがONになっているので、クラッシュ・リカバリーが行われます。

■ローカル・フェイルオーバーの流れ

　障害が発生した際の引き継ぎ処理について見ていきましょう。サーバの障害（カーネルがハングアップした）と仮定して話を進めます。

障害検知

　プライマリ・サーバが応答しなくなるとheartbeatが途切れ、障害の発生が検知されます。
リソースの引き継ぎ

　クラスタソフトウェアはクラスタを再構成し、ストレージ、IPアドレス、DB2のプロセスの順に引き継ぎを行います。
- ストレージ
  　ファイルシステムのマウントを行います
- IPアドレスの引き継ぎ
  　サービス用のIPアドレス（実際にはIPエイリアス）の引き継ぎ
- DB2の開始
  　セカンダリ・サーバでDB2を開始します
DB2のクラッシュ・リカバリー

　クラッシュ・リカバリーを行って最後にコミットされたトランザクションまで戻し、データベースの整合性を保ちます。

図2　2ノードのHA構成

　以上が、HAクラスタソフトウェアを使ったローカル・フェイルオーバーの概要です。

■計画停止とダウンタイムの短縮

　ここまでは予想外の非計画停止を前提に解説しましたが、実は計画停止によるシステム停止も無視できません。例えば、OSのパッチやDB2のFixPakを適用する際は、DB2のサービスを止める必要があるので必然的にシステムが停止します。

　計画停止の際も、前述のHAクラスタを使って停止時間を極力短くすることができます。また、DB2の最新版はオンライン・ユーティリティが充実しているので、データベースを止めることなくメンテナンスを行うことが可能です。

DB2のオンライン・ユーティリティ
　　オンライン構成パラメーター変更
　　オンライン表・索引再編成
　　オンライン・ロードユーティリティ
　　オンライン・コンテナ・ストレージ管理
　　オンラインバックアップ
　　オンライン・表スペースリストア

ディザスタ・リカバリ

　ディザスタ・リカバリ（災害対策）は、基本的にローカル・フェイルオーバーと同じように考えることができます。しかし、ディザスタ・リカバリの場合は距離が離れている場所にバックアップ・サイトを設置する必要があるので、ローカル・フェイルオーバーのようにストレージの引き継ぎでデータを移動することが難しくなります。

　そこで、データの移動を行うためにストレージの遠隔コピー機能を利用する例が増えてきています。IBM ESSのPPRCや日立SANRISEのTrueCopy、EMC SymmetrixのSRDFなどがそれに当たります。ここで注意が必要なのは、遠隔コピーの場合は非同期でコピーするタイプのストレージもありますが、ディスクへの書き込み順序が保証されないものもあるということです。この場合、ローカルコピー同様にI/Oの静止点を取る必要があり、要件に応じてスナップショット・データベースかスタンバイ・データベースを選択します。完全に同期でコピーする場合は、DB2のクラッシュ・リカバリー機能だけでリカバリ可能です。

　なお、Linuxには遠隔地同士のフェイルオーバーに対応したクラスタソフトウェアがないため、引き継ぎには人の手が必要になります。

　今回は、DB2の高可用性とディザスタ・リカバリについて解説しました。ストレージのコピー機能やHAクラスタソフトウェアなどは、Linuxでオープンソースに慣れ親しんだ皆さんにはなじみのないものだったかもしれません。機会があればheartbeatを使ったDB2クラスタについても触れたいと思います。

　次回は、データベースの運用管理をテーマに解説する予定です。

「次回」へ

「DB2マイスター養成講座」バックナンバー