既存の共有ディスク型アーキテクチャの弱点を克復したIBM DB2 pureScale

データベースの2つのクラスターアーキテクチャ

　企業が扱うデータは、爆発的に増え続けている。莫大なデータを効率よく管理するには、大規模で高性能なデータベースが欠かせない。しかしながら、数年後のデータ増加を予測し、それを見越した巨大なシステムを一気に導入するとなると、初期投資が膨らんでしまう現実がある。

　そこで登場したのが、クラスタリングだ。規模のそれほど大きくないサーバーを複数並べ、1台の大きなサーバーがあるように見せかける。そして、それぞれのサーバーに処理を分散させることで、巨大で高性能なサーバーと同様な処理を実現する。処理性能が足りなくなれば、ノードを追加し拡張性が得られるのだ。

　拡張性に優れたデータベースのクラスタリングシステムには、現状では2つのアーキテクチャがある。1つは個々のメンバーに専用ディスクを割り当てられるもの、もう1つがディスクを複数ノードで共有するもので、それぞれに長所と短所がある。

高速処理が得意だが、可用性と更新系が苦手な非共有ディスク型

　非共有ディスク型では、ノード追加による性能向上が極めて容易だ。理論的には、ノードを増やせば増やしただけリニアに性能は向上する。しかしながら、ディスクを共有しないのでどのノードがどのデータを保持しているかを別途管理する必要がある。

　さらに、1つのノードに障害が発生するとそのノードが管理するデータが見えなくなり、データベース全体への検索ができなくなる。そのため、システム可用性の確保にはディスクそのものを冗長化するだけでなく、ノード間で互いを補完する複雑な仕組みが別途必要となる。

　データ更新時やノードの追加時にも注意が必要だ。処理性能向上のためにデータを各ノードにハッシュ関数などを用い分散格納すると、データ更新時にはすべてのサーバーのデータをロードし直す必要が出てくる。

　高速処理が可能だが、可用性確保と更新系システムでは弱点を持つのが非共有ディスク型のアーキテクチャだ。このアーキテクチャは、おもに検索性能を重視するデータウェアハウスなどで活用されている。

可用性は高いが、拡張性に欠ける共有ディスク型

　これに対し、共有ディスク型はノード追加やデータ更新時にもデータを再構成する必要はない。障害発生時には実行されていた処理を稼働している別ノードにそのまま引き継いで継続させられるため、極めて可用性の高いシステムとなる。

　拡張性についても、ノードを追加すれば基本的には性能が向上する。しかしながら、共有型では各メンバーのメモリ上のデータ整合性を確保しなければならず、そのためにノード間でデータロックやバッファ情報などをやり取りする必要がある。

　これは、メンバーが増えると相互に情報をやり取りするので通信量が大幅に増え、性能に影響を及ぼす可能性が出てくる。可用性は高いが、ノードが増えると拡張性が発揮しにくいのが共有ディスク型であり、OracleのReal Application Clusters(RAC)はこのアーキテクチャを採用している。