高可用性を越えて「連続可用性」を実現する構成とは？：Database Expertレポート（2）（1/2 ページ）

行指向／列指向の両方の機能を担うデータベースに進化したDB2。新機能に目が行きがちだが、システム構成や運用時に着目すべき変更も加えられている。2013年7月に開催されたイベントの中から関連セッションを紹介する。

[原田美穂，＠IT]

　2013年7月9日、「Big Data Technology Forum 2013」（日本アイ・ビー・エム主催）が開催された。本稿では、当日のセッションの中でも、DB2関連の情報を中心に紹介する。

PureScaleを使った「連続可用性」を実現するシステム構築

　IBMが提供するデータベースDB2は2013年4月4日に最新版である10.5がリリースされたばかりだ。過去の記事で紹介した通り、最新版の技術面での特徴は、行指向データベースとしての機能はそのままに、BLUアクセラレーション機能により同一のストレージ上でカラム型のデータ保持が可能になっている点、データ圧縮や独自のデータスキャンアルゴリズムによる高速なデータ分析性能を持っている点だ。発表時にはもちろんこうした新しい実装に注目が集まったが、実は、既存ユーザーにとって注目すべき変更があった。DB2 10.5では、pureScaleやHARDなど、従来オプション提供であった機能が同梱されているのだ。

　こうしたライセンス上の変更を受け、日本IBM インフォメーションマネジメント事業部　インフォメーション・アーキテクトである野間愛一郎氏が登壇、これら機能の詳細をあらためて解説した。

　オプション機能が標準で提供されるようになったDB2 10.5では、通常のライセンスのみで、DRを検討する場合（1）HA構成（2）HADR構成（3）pureScale構成が選択できるようになっている。

　それぞれの特徴は次のシートの通りだ。

HARD構成とは？

　HADRは、DBログ転送をベースにしたデータレプリケーション機能で、コミットのログをスタンバイDBに対して転送する仕組みになっている。ログのみを同期するため、通信帯域に制約がある環境でも対応できる利点があるという。

　HARD構成におけるログ転送には（1）SYNC（2）NEARSYNC（3）ASYNC（4）SUPERASYNCの4モードが用意されている。SYNCモードはセカンダリサーバでもログファイルを持つ構成。NEARSYNCモードは、ログデータをセカンダリに送信するまでを保証する。ASYNCモードはログファイルを非同期で送信するまでを保証する。SUPERASYNCモードはアクティブサーバ側のログ書き込みまでを保証する。

　システム要件によって採用すべきモードはさまざまだろうが、野間氏によると、「多くのユーザーは（2）のNEARSYNCモードを採用する」そうだ。

　従来、この構成はアクティブ／スタンバイの1対1構成であったが、10.5では、1対Nで、　「アクティブ／スタンバイ＋リードオンリーのSUPERASYNCモードのノードが持てるようになった」（野間氏）。

　野間氏は、現在ITインフラシステムに求められている要件がもはや「高可用性」ではなく、単一障害点がなく計画停止などの影響を受けず常に稼働できる「連続可用性」のレベルであると指摘する。

　現在、オープン系システムで一般的に採用されているアクティブ／スタンバイ構成やログ転送によるアクティブ／ホットスタンバイ構成では、たとえ短時間であっても切り替え時間や、アプリケーションの再接続時間が発生するため、「いずれにしてもサービス停止を避けられない」（野間氏）と評価する。この構成では「連続可用性」という要件を満たすことはできない。

　また、データベースサーバのアクティブ／アクティブ構成は、データ一貫性の保持に難題があり、また、シェアードディスク型クラスタ構成では場合では、サーバ障害が全体に影響することが懸念される。

　「一方、PureScaleを利用した場合、単一障害点がない構成を取ることが可能。シェアードディスク型構成の弱点は行ロック処理のロジックだが、DB2 PureScaleでは、メインフレームで実装していた連続可用性向けの機能を『Cluster caching facility（CF）』として盛り込んでおり、こうした弱点を克服している」（野間氏）

PureScaleにおけるCFの動作概念図　CFはCPUとメモリのみで動作するロック管理ノード。CFがロック情報を一元的に管理する。図中の「メンバー」とあるのは、PureScaleにおけるサーバノードを指す

　冗長化したCFが行ロックの情報を一元管理するため、各ノードはCFに直接問い合わせる。このため、サーバノードに障害が発生した場合でも、CFが健全であればDB整合性は保持できる、という仕掛けだ。

　シェアードディスク型の場合はログデータが各ノードに分散するため、ログ解析が完了するまで全てのノードがダウンしてしまうリスクがある。一方のPureScaleではログ情報を冗長化したCFが保持し、このリスクを回避している。また、ログ問い合わせを2点間通信に限定し、処理をCPUとメモリ領域内で完結することで、遅延を防ぐ工夫も施されている。

　こうした機能を通常ライセンスの範囲内で利用できることから、DB2 10.5ユーザーは、HA構成、DR向け構成、連続稼働を重視した構成など、要件に応じたシステム構成をとることができる。野間氏は講演の最後にまとめとして、システム要件と採用すべき機能をマッピングした図を示した。

DB2 10.5の標準機能で実現可能な構成と要件のマップ