高可用性を実現するLinuxブレードサーバ BladeFrameとC-ONEソリューション

　企業情報システムのTCO削減で「サーバ統合」がキーワードになって久しい。分散したサーバを統合し、コンピュータリソースを効率よく使いながら運用管理や障害対策のコストを抑える。通信インフラがここまで発達し、そのコストパフォーマンスが飛躍した現在、1つの“理想型”である。

　ただ、サーバ統合が本当に効果を発揮している企業はどれぐらいあるのだろうか。物理レベルはもとより、論理レベルでのサーバ統合を果たし、劇的なTCO削減をもたらすIT基盤を作り上げているケースは少ないようだ。

　ブレードサーバは、確かにサーバの集積度を高めることには貢献した。だが、それだけでは劇的なTCO削減は期待できない。1台1台のブレードサーバは、筐体こそ小さいが物理的に独立したマシンなので、やはり台数分の運用管理と障害対策が必要になる。しかも、ブレードサーバは主にWebサーバを中心とした比較的軽いジョブを処理するフロント層で使用され、より重要なアプリケーション層、データベース層では依然としてラックマウント型のIAサーバやUNIXサーバが多用されている。

　こうした市場動向の中で注目したいのが、米イージェネラのハイエンドサーバ「BladeFrame」である。名前に“Blade”とあるように、ブレードサーバと呼ぶこともできる製品である。だが、その設計思想は他社のブレードサーバとはまったく異なっている。

写真1　BladeFrame

　米イージェネラは、米投資銀行大手のゴールドマン・サックスでCTOを務めたバーン・ブローネル氏らが中心になって2000年3月に設立したベンチャー企業だ。サーバ保有台数では世界有数のゴールドマン・サックスでの経験を生かし、同氏がユーザー視点で企画・開発したのがBladeFrameである。2002年秋には日本市場へ進出し、伊藤忠テクノサイエンス（CTC）が販売代理店として注力している。

　BladeFrameは、1台の専用ラック（84インチ）に最大24基のブレードを収容できる。インテルXeonプロセッサまたはAMD Opteronプロセッサを搭載するブレードは2ウェイと4ウェイの2種類があり、2〜32Gbytes（Opteron時）のメモリを実装可能。BladeFrame 1台で最大96CPU（4ウェイ×24基）を収容できるスケールアウト型ハイエンドサーバである。OSは「Red Hat Enterprise Linux」あるいは「Windows Server 2003」から選択できる。そのほか、SUSE LINUXに加え、x86 Solarisも2005年後半にサポート予定だ。

　BladeFrameの真の魅力は、物理的なハード構成だけではない。ユーザーにサーバ統合のメリットをもたらすのが、「PAN（Processing Area Network）」と呼ばれる独自の仮想サーバ環境である。PANは、次の3要素で構成されている。

BladeFrameのブレード構成

　BladeFrame内部には、2.5Gbps（1.25Gbps×2の二重化冗長構成）という高速低遅延なインターコネクトが貫かれており、pBlade（CPUとメモリ）はsBlade（スイッチ）とcBlade（I/Oインターフェイス）を介して外部ネットワークやSAN（Storage Area Network）とデータをやりとりする。

　pBladeにはディスクが一切搭載されておらず、OSやアプリケーション、データはすべて外部に接続したSANに収容されている。pBladeとストレージ内のソフトウェアは、cBladeに搭載されているPAN Managerによって結び付けられ、仮想的なシステム環境を構成する。具体的には、SAN上の特定ディスク領域に仮想サーバ（OSとアプリケーションの組み合わせ）を設定し、これにpBladeが持つプロセシング資源（CPUとメモリ）を1対1で動的に割り当てる。仮想サーバはディスク領域が許す限り無制限に作成できるが、同時動作はpBladeの基数分で最大24個となる。仮想サーバは、NICやホストバス・アダプタといった外部インターフェイスも仮想化されており、これまた仮想的に設定されたスイッチ（最大4096個が設定可能）と通信するように設定できる。

BladeFrameの仮想化機能

　この仮想化機能により、「キャパシティ・オンデマンド」を実現する。限られたpBladeをオンデマンドで仮想サーバへ動的に割り当てることで、プロセシング資源を有効活用し、システム全体の性能を安定化させるのだ。例えば、負荷が大きく変動するWebシステムの場合は、あらかじめ予備のWeb用仮想サーバをPAN Managerで作成しておく。予備の仮想サーバは通常pBladeを割り当てていないが、Webシステムの負荷が一定水準を超えた際はプール用pBladeを用いるなどして新しいサーバを即座に追加できる。追加に当たってネットワーク構築やストレージのゾーニングなどの情報は、事前にすべてPAN Managerで仮想的に定義されているため、別途作業は必要としない。

　この仕組みは当然、可用性を高めるのに役立つ。フェイルオーバー専用にpBlade 1基を待機させておけば、あるpBladeに障害が発生した際にわずかな切り替え時間でフェイルオーバーを完了する。PAN Managerが故障したpBladeと仮想サーバのヒモ付けを待機中のpBladeへ自動的に引き継がせるからだ。一般的なシステムのフェイルオーバーのように、すべてのサーバや内部ネットワークを物理的に多重化しておく必要はない。

　BladeFrameは、1台でフロント層、アプリケーション層、データベース層から成る3階層システムのサーバ群、ネットワーク機器群を仮想的に統合できる場合すらある。通常の3階層システムは、アプリケーション層、データベース層に高価なサーバを用いて、さらにそれを二重化している。各層のサーバをつなぐ高性能なスイッチも必要だ。それに対し、BladeFrameならば予備サーバやスイッチが不要で結線も最小限で済む。3階層システムを物理レベル、論理レベルで統合できれば、TCO削減効果も大きなものになるだろう。

　実際、米国では2002年ごろから大手の金融機関やデータセンターでの採用が相次いでいる。国内では2003年からCTCが取り扱いを始め、その夏にはUFJ銀行が基幹系システムの刷新でBladeFrame（Linuxベース）の採用を決定している。金融機関の基幹系システムは極めてミッションクリティカルであり、製品選択の基準は厳しい。それに合致したことは、BladeFrameが高いレベルでTCO削減効果と可用性を両立していることを物語る。その後も現在に至るまで、メガバンクや情報通信事業者などが手掛けた数々の大規模システムでBladeFrameが活躍している。

写真2　BladeFrame ES

　スケーラビリティもBladeFrameの魅力の1つではあるが、「Xeonを最大96個も使うほど大規模なサーバは必要ない」というユーザーもいるだろう。そうしたユーザーには、エントリ版の「BladeFrame ES」がよいだろう。BladeFrame ESは、PANによる仮想化機能はそのままに、搭載できるpBladeの数を24基から6基にした製品である。専用ラックも13Uサイズと省スペース化され、導入コストは上位版の数分の1になる。

　さらにCTCの「C-ONEソリューション」を利用すれば、高いTCO削減効果と可用性を両立したサーバ統合を実現できるだろう。C-ONEソリューションは、BladeFrame ESを中心に日本オラクルの「Oracle RAC 10g」、ネットワーク・アプライアンスのファブリック接続型ストレージ「NetApp FASシリーズ」をベスト・オブ・ブリードで組み合わせたソリューションである。

　「データベースグリッド」として、1つのデータベースを複数のサーバ（ノード）で共有・分散処理するOracle RACのクラスタ技術とBladeFrameの仮想化技術の相性がよいのは、容易に想像がつくだろう。ノード障害時にも高速（5分程度）で自動復旧（フェールオーバー）してくれる。「ストレージグリッド」として、ディスク領域を容易に拡張できるNetApp FASシリーズも同様である。

　C-ONEソリューションは、CTC、日本オラクル、ネットワーク・アプライアンス、日本イージェネラという4社の協業で成り立っている。実際のソリューション提供に当たっては、CTC 1社が前面に立ち、システム設計から運用・保守に至るサービスを一貫して担当する。各製品の協調動作については、CTCの検証施設「e-ビジネスソリューション・センター」で検証を重ねており、安心して導入できる。

　C-ONEソリューションによって、超ハイエンド向けであったBladeFrameが導入しやすくなった。BladeFrameがもたらす本物のサーバ統合を享受できるユーザーが一気に増えることだろう。