| エンタープライズ:ニュース | 2002/08/02 23:51:00 更新 |

システム拡張のカギを握るクラスタ技術(後編)
インターネットの拡大により、企業にとってシステム拡張はタイミングも方法も難しくなってきた。今後増え続けるデータに対して、Webサーバだけでなく、自社の基幹システムも拡張しなくてはならない企業は多い。
Oracle 9i RACのクラスタ技術の特徴は、「キャッシュ・フュージョン」と呼ばれるデータアクセスに関するアーキテクチャだ。
これまでのクラスタ技術では、「共有ディスク方式」と「シェアードナッシング方式」の2つがあった。
共有ディスク方式は、複数のサーバが1つのディスクを共有し、データを統合した一体のシステムとして稼動するもの。1つのサーバに障害が発生しても、残りのサーバが全体としてのシステム稼動を維持する。しかし、ディスクを共有する構造であるために、サーバが増えていくとディスクアクセスが競合する現象が目立ち始める。そこでは、複数サーバからの同時アクセスからデータの整合性を保つため、あるサーバが処理しているデータにはロックが掛かり、別のサーバが同じブロックのデータを更新する場合には待ち時間が発生するケースが出てくる。結果的には、追加したサーバの台数ほどパフォーマンスが上がらないといった課題が生まれる。共有ディスク方式を採用している主なDBは、Oracle、メインフレーム用のDB2など。
一方で、シェアードナッシング方式は、複数のサーバ構成において、各サーバごとにディスクを用意して処理を行う方式。つまり、ディスクごとにデータを分散させる方式だ。多サーバ構成のシステムでもパフォーマンスが劣化しないことがメリット。しかし、サーバに障害が起こっても別のサーバが処理を引き継がないため、可用性に課題があるという。また、データを分割しているので、データ格納場所などの設計や管理が複雑化し、システム拡張が難しくなることも頭の痛い問題とされる。シェアードナッシングを採用しているのは主に、マイクロソフトのSQL Server、UNIX/Windows版のDB2など。
そして、共有ディスク方式を取っているOracle 9i RACがアピールするキャッシュ・フュージョン技術は、ディスクアクセスの競合によるパフォーマンス低下という問題を解決することを最大のテーマとしている。
キャッシュ・フュージョンとは、共有ディスクの上の階層に、すべてのサーバに共通する統合キャッシュを置く技術。クラスタしているすべてのサーバのキャッシュを統合した上で、共有ディスク上のDBなどに処理要求を行うため、ロックやブロッキングといった現象を避けることができる。
例えば、ノード1というサーバが、共有ディスク上にあるDBのある行データを更新している時に、ノード2というサーバが、同じブロックに存在する、別の行データを更新するようなケース。キャッシュ・フュージョンはどう対応するのか。
ここでは、ノード1は自らが更新した最新のデータブロックを、キャッシュ・フュージョン上のインターコネクトを経由して、ノード2に転送する。そのため、ノード2は最新のデータブロックに対して、行データの更新を行えるわけだ。これまでの共有ディスク方式では、この場面で、処理中データがロックされ、ノード2が行う処理に待ち時間が発生し、パフォーマンスの低下を招く可能性が高かったということだ。
このキャッシュ・フュージョンが、オラクルが自信満々にアピールする、Oracle 9i RACのハイライト的な機能となっている。スケールアウトのシステム拡張をする際に問題となっていた、共有ディスクに発生する競合という問題を解決したことがポイントだ。
クラスタでバックアップマシンは不要に?
また、クラスタでシステムを組むことによるもう1つのメリットは、バックアップサーバを用意しなくても済むということ。クラスタ構成サーバが1台ダウンしても、残りのサーバがフェールオーバーして処理を引き継ぐからだ。
これは見方の問題でもあるかもしれないが、ある意味では、バックアップサーバが不要とも言え、別の見方をすれば、バックアップサーバを普段の業務でも利用しているという考え方にもなる。
Oracle 9i RACだけでなく、マイクロソフトは「Microsoft Cluster Server」、ヒューレット・パッカードは「hp MC/ServiceGuard」などを展開しており、スムーズなサーバ拡張という企業の課題に直接応える技術として、クラスタへの各社の動きが注目される。
関連記事[怒賀新也,ITmedia]
