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

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

» 2013年08月13日 18時30分 公開
[原田美穂@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の標準機能で実現可能な構成と要件のマップ
       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。