クラスタシステムとデータ共有

クラスタシステムを設計する時にはデータの共有をどのように行うか。これはとても悩ましい問題です。

例えば、ノード1で動作しているファイル共有サービスを、障害発生時にはノード2で動作させるようなクラスタを構成したとします。

もし、データがノード1のローカルなハードディスクに保管されていると、ノード2でファイル共有サーバを引き継いだとしても、そこにはデータがまったくありません。これでは、利用者にとって、サービスを引き継いでいるとは言えません。サービスを引き継いでいると言うためには、障害が発生する前のコンピュータが管理していたデータも、正しく引き継がれなければいけないのです。そのため、ノード間で、どのようにファイルを共有するのかというのが、クラスタシステムでは重要なポイントになります。

クラスタシステムで良く利用されるファイル共有方法には、次のような方法があります。

iSCSIなどの外部ディスクを使って、2つのノードから物理的に同じディスクを見ようとするものです。

高速な共有ハードディスクを利用すると、クラスタノードからも高速にアクセスできます。また、クラスタノードからは通常のハードディスクと同じように扱うことができるため、利用可能なアプリケーションにはほぼ制限がないというメリットがあります。

しかしながら、欠点もいくつかあります。複数の機器から同時に共有できるハードディスク装置は、残念ながら比較的高価です。そのため、せっかくオープンソースソフトウェアを使ってクラスタシステムを構成しても、クラスタシステム全体の導入コストを抑えることができません。

また、Linuxで通常使うext4などのファイルシステムは、2つのノードから同時に読み書きを行うことができません。これは、Linuxが高速化のために、ディスクの情報をローカルなメモリ上にキャッシュして管理するためです。もし、共有ディスク上の同じ領域を2つのノードから同時に利用してしまうと、ディスク上の管理情報が2つのノードから無秩序に更新され、ファイルシステムとして一貫性が保てない状態になってしまいます。事実上、ファイルシステムは破壊され、データが失われるという大きなリスクがあります。

そのため、共有ハードディスクを利用するためには、絶対に同時利用しない仕組みを導入する必要があります。

複数の機器から同時に利用できるファイルシステムとしては、NFSサーバを使うのが比較的安全です。共有ハードディスクとは異なり、NFSサーバ上の管理プロセスが、処理リクエストを受けてファイルシステムを統一的に管理します。同じ情報を複数のノードから同時にアクセスしても、安全に利用することができます。

NFSサーバを利用する場合の問題点は、ファイルロックの処理をローカルハードディスクと同様に行うことができないことです。そのため、上位のアプリケーションからの利用方法を考えて設計をする必要があります。

例えば、データベースなどの、ファイルロックを多用するアプリケーションからの利用には不向きです。一方、WWWサーバのコンテンツデータなど、更新があまり行われないデータを管理するには適しています。