Linux クラスタリング技術のオプション

言葉の誤用

「クラスタ」は、コンピューティング業界でおそらく最も誤用されることの多い言葉だ。本稿では、本来のクラスタについて説明し、各種クラスタのインプリメントに役立つ Linux 技術の概要を明らかにする。もちろん、最大の焦点となるのは高可用（HA）サービスクラスタの構築だ。

クラスタリング技術には基本的に3つのタイプがあり、それぞれが異なる手法と異なるレベルでリソースを要求する。

高性能計算（HPC）では、途方もない計算処理能力を得るためにクラスタを利用する。Scyld は HPC クラスタリングの一例で、LAM/MPI や MPICH もそうだ。MPI ベースのクラスタには、クラスタを活用できるアプリケーションが必要になる。HPC は計算負荷の高い作業に対応し、1つのタスクを複数のタスクに分割して各ノード上で実行できる。標準的なシングルスレッドのアプリケーションは、これらのクラスタ上では動作しない。

Scyld ライクなクラスタも、アプリケーションが多くの計算処理タスクを生成しなくてはならない点で同様だが、Scyld はクラスタを1台のマシンとして見せる。トップノード（マスタ）では、各ノードで実行中のプロセスをすべて見ることができ、圧巻だ。つまり、当然ながらカスタムカーネルを実行することになる。

しかし、予備の高可用サービスを実現するにはクラスタをどのように設定するのかが本当の問題だ。潜在的な単一障害点（SPF）となる NFS サーバー、電子メールサーバー、Web サーバーなどの各種サービスは特にそうだ。対策は2通りある。

高可用クラスタは冗長性重視だ。重要なサーバーに問題が生じると、瞬時にスタンドバイサーバーが交代する。これは通常、スタンドバイサーバーが特定のサービスの反応が適切かどうかを単純な ping か複雑なプログラムを使ってモニタリングすることで実現されている。

linux-HA プロジェクトでは、スタンドバイサーバーがアクティブサーバーの状態検証に利用する Heartbeat プログラムを提供している。これはフェイルオーバーや IP アドレス管理機能も用意している。

しかし、HA コンフィギュレーションには問題がある。NFS サーバーを2台設置し、同じストレージへのアクセスを可能にして決着を付けさせるのがあるべき姿だ。これは無理な話だが、複数のアクティブノードにストレージを同時利用させるクラスタ対応ファイルシステムはある。1台のノードが障害を起こすとデータの一貫性が失われる可能性があるため、クラスタにデータベースを使わせることも厄介な話だ。

Sun Cluster、Linux-HA、Piranha は、いずれも高可用クラスタ技術の例だ。

負荷バランシングは、1つの接点がほかのノードにジョブを分配する。マスタノードが SPF になる場合があるため、通常は予備のトップノードを用意するために HA クラスタリングが利用される。

負荷バランシングと「クラスタリング」を結びつける必要はない。これは、ネットワーク機器やソフトウェアでも可能だ。通常は、ソフトウェアベースのソリューションの方がやや気が利く。これらは、負荷やバックエンドノードの応答性を監視して、最も可用性の高いサーバーにトラフィックを流す。

最も有名な負荷バランシングクラスタ製品は、「Linux Virtual Server」（LVS）プロジェクトだ。LVS はほかの技術より高レベルで運用される。これは、プロセス実行用の一連の透過的なノードを用意する代わりに、ネットワークレベルで負荷を分散する。その利点は、TCP か UDP で通信すると仮定した場合、LVS クラスタ上ではほぼ何でも動作するところだ。

Red Hat のクラスタソフトウェア「Piranha」も LVS を利用する。ただ考えてみれば、実際の LVS は大げさなプロキシサーバーにすぎない。だが、レイヤ4で動作するため、負荷バランシングを行おうとしているレイヤ7プロトコルを理解する必要がなく、そこが大きな利点となっている。

ここで残るのが、どのクラスタリング手法を使うべきかという疑問だ。実際のところ、これはサーバーの目的に応じて決まってくる。NFS サーバークラスタをインプリメントしたいなら苦痛が待っている。ロックの問題を筆頭にさまざまな問題があり、NFS が実際にはステートレスでないといったことから、問題は避けられない。共有ファイルシステムを持つクラスタをインプリメントするには、本来は GFS や Veritas のようなものを投入する必要がある。

最も探し求められているのは、Web やメールなどの各種サーバーのクラスタの投入方法だ。通常は、LVS でなくても LVS に関連したものがそのソリューションとなる。「TurboLinux Cluster」、「Red Hat High Availability Server」、そしてほかの多くの製品はどれも LVS を採用している。

Kimberlite は LVS を採用しておらず、それが多くに支持されているようだ。Kimberlite は共有ストレージも用意して高可用の「active-active」コンフィギュレーションでサービスを実行する。1つのノードが落ちても、もう1つがなくなったサービスを起動してカバーし続ける。

また、想像通り、クラスタオプションは本稿で言及しなかったものがおそらくほかに50種類以上ある。最も一般的なのは LVS と Linux-ha だが、Linux-ha.org は Linuxha.net とはまったく別であることに注意したい。まあ、確かに混乱はする。

SUSE Linux には Linux-HA（Heartbeat）がプレインストールされており、すぐに利用を開始できる。Red Hat Cluster も別の選択肢であり、もちろん利用可能な無数の技術を使って自分でソリューションを運用する選択肢もある。とにかく、自分が選ぶクラスタソリューションの欠点と制限だけは資料を読んで理解しておきたい。制限はどの技術にもあるのだから。