サーバ・プロビジョニングを最適化する──新世代の「boot-from-SAN」の実力に迫る

（2006年06月26日）

　ディスクレス・サーバやブレード・サーバの管理に効率性を求める声が高まってきたのを受けて、SAN（ストレージ・エリア・ネットワーク）ベンダー各社は先進的なサーバ・プロビジョニングをサポートする次世代ツールを提供し始めている。ブロケードの「Tapestry Application Resource Manager」、マイクロソフトの「Virtual Hard Disk」、あるいはエミュレックスの「N-Port ID Virtualization」などのツールは、従来型のboot-from-SANやLUN（論理ユニット番号）クローニングなどに比べてはるかに使いやすくなっている。本稿では、サーバ・プロビジョニングを最適化する新世代の「boot-from-SAN」技術の実力を徹底検証する。

デニー・コナー
Network World 米国版

サーバ復旧に絶大な効果

　これまで、SANをベースにサーバやストレージのプロビジョニングを可能にする「boot-from-SAN」（SAN上のボリュームからサーバをブートする）や「LUNクローニング」（1台の仮想ディスクから別の仮想ディスクにデータをコピーする）は実装がきわめて困難だった。

　高度なプロビジョニング機能と幅広いレンジのストレージ・オプションをサポートする次世代ツールは、ディスクレス・サーバや仮想サーバを配備して、リソースを統合したり、一元的に管理したりできるなど、さまざまなメリットを提供してくれる。

　IT部門がこれらのツールを導入すれば、サーバ・イメージ（アプリケーション、OS、設定、データを含む）をSAN上にストアし、中央からそれらを管理、分析することが可能になる。

　サーバを迅速に復旧できるのは、boot-from-SANやSANベースのプロビジョニングの最大のアドバンテージだと言えるだろう。サーバに障害が発生した際には、SAN上のサーバ・イメージを使って、直ちに新しいサーバを配備することができる。

　このプロセスは新しいサーバを一から設定するよりもはるかに短時間で行うことができる。数十台のWebサーバでも、アイデンティティすなわちイメージさえが構築されていれば、ボタンを1回クリックするだけで作成できてしまう。

　OSやアプリケーション、コンフィギュレーション・セッティングを再インストールして、バックアップ・テープからデータをコピーするのではなく、新しいサーバをネットワークに接続し、ブート、アプリケーション、OSのイメージを利用するように設定するだけだ。

　ケアグループ・ヘルスケア・システムのベス・イスラエル慈善医療センター（マサチューセッツ州ボストン）のストレージ・アーキテクト、マイケル・パス氏は、boot-from-SANおよびサーバ、ストレージ・プロビジョニングの導入を検討中だが、その理由についてこうこう語る。「災害復旧対策としてboot-from-SANを考えている。多くのサーバにシステム・ボリュームのクローンを作成できるからだ」

ブーツとブレード

　boot-from-SANの背後にある技術は、特に新しいものではない。すでに1980年代後半には、ブートROMを搭載し、ファイル・サーバからアイデンティティをピックアップするディスクレス・ワークステーションが存在していた。UNIXワークステーションも、DECの時代からネットワーク経由でブートした。

　ただ、今日のboot-from-SAN技術はサーバ・リソースの自動プロビジョニングをサポートし、ディスクレス・サーバやブレード・サーバの配備をきわめて簡単にできるようになっている。

　「今年（2006年）夏以降に、IBM BladeCenterサーバでboot-from-SANを利用できるようになるだろう」と期待するのは、バージニア州アレクサンドリアのテレビ局、パブリック・ブロードキャスティング・サービスのエンタープライズ技術担当シニアディレクター、ケン・ウォルターズ氏だ。

　同局ではここ数年、ブレード・サーバ上でエムブイウェアのESX Serverを実行している。「ESX Serverはサーバを仮想SANディスクからブートでき、boot-from-SANに対応している」とウォルターズ氏は説明する。

　しかし、同氏が現在必要としているのは、iSCSI SANディスクからブレードをブートする方法である。

　アダプテックとQロジックは、IBM BladeCenterコンピュータからブレードをブートできる特殊なHBA（Host Bus Adpter）を開発しているが、そうしたハードウェア・ベースのiSCSI HBAは価格が700ドル以上と非常に高価である。

　そのため、ウォルターズ氏は、マイクロソフトとIBMのソフトウェア・ベースのiSCSIブートを利用したいと考えている。いずれも今年の夏にリリースされる予定だ。こうしたiSCSI Software Enabled SAN bootをサーバのBIOSかHBAのファームウェアに実装すれば、BladeCenterやその他のディスクレス・サーバをiSCSI SANに接続し、そこからブートすることができる。

　ウォルターズ氏は、SATA（Serial Advanced Technology Attachment）など安価で最新のドライブを接続したストンフライ製のiSCSIベースのStorage Concentratorからブレード・サーバをブートさせる考えだ。

　こうしたソフトウェア・ベースのブートに対するサポートを表明したベンダーは、デル、エムブート、インテル、Qロジックのほかに、iSCSIベンダーのアラクリテック、イコールロジック、ファルコンストア、イントランサ、レフトハンド・ネットワークス、ニンバス・データ・システムズ、サンラドなどがある。

　ウォルターズ氏によると、SANからのブートを望む最大の理由は、ストレージを統合し、効率化することにある。「すべてのダイレクト接続ストレージをチェックしてみたら、ディスクに未使用領域が大量に見つかった」と同氏は語る。

SAN経由でのサーバ・プロビジョニング例

リモート・ブート

　boot-from-SANは、SAN上に仮想ディスクを作成し、そこにサーバのブート・イメージ、OS、システム設定、アプリケーションをストアする。サーバはブート・イメージからブートし、他の仮想ディスクに置かれたOS-アプリケーション-設定イメージに接続する。

　サーバの電源をオンにしたときのブート・プロセスには、OSコードのローディングが含まれる。最初にブート・イメージからシステムBIOSをロードし、ハードウェアを初期化して、OSをロードし、ハードウェアの設定をチェックして、サーバ・メモリにOSのコピーを作成する。

　また、ブート・イメージのクローンを作成し、同一のアイデンティティを持つ複数のサーバを立ち上げることも可能だ。例えば、IT部門はSAN上に、配備を待つWebサーバやMicrosoft Exchange、あるいはSQLサーバのイメージを置くことができる。その場合、ユーザーは物理サーバでも、VMwareやオープンソースのXenを利用した仮想サーバでも、必要に応じてSANからプロビジョニングが可能だ。

　ただ、boot-from-SANやLUNクローニングによるサーバ・プロビジョニングの問題は、マニュアル・プロセスのセットアップが複雑であるという点だ。

　データ・モビリティ・グループの上級アナリスト、ウイリアム・ハーレー氏は、「現行のLUNクローニングでは、完全に同一のハードウェア・コンフィギュレーションを用いなければ、ドライバのミスマッチを引き起こしてしまう」と指摘する。

　同氏はレッドハットから、boot-from-SANに起因するトラブルの危険性を指摘されたという。「彼らはboot-from-SANをサポートしないと断言し、もしわれわれがトライすれば、さまざまな問題が発生するだろうと警告している」

　SANに接続したサーバは、それぞれ固有のブート・イメージを必要とする。エミュレックスのN-Port ID Virtualizationを利用すれば、複数の仮想サーバで同じHBAを共有でき、したがって同じブート・イメージを共有することが可能だ。

　マイクロソフトは、非仮想ブレードサーバをSAN上の単一のイメージからブートできるソフトウェアを開発中であり、ブロケードもソフトウェアとハードウェアでプロセスの自動化を進め、サーバイメージの作成、配備を容易にしている。

　ブロケードが昨年、セリオン・ソフトウェアを買収して取得したTapestry ARM技術は、ハードウェアのTapestry ARM ApplianceとソフトウェアのTapestry ARM Service Processorで構成される。ブロケードは買収後、それらを既存のBrocade Fibre Channel SAN環境に統合した。

　「Tapestry ARMはboot-from-SANとLUNクローニングをサーバ・ベースのソフトウェア・パッケージにまとめ、サーバ-ストレージ・リレーションシップのプロビジョニング、移動、再割り当てを容易にしている」と語るのは、エンタープライズ・ストラテジー・グループのアナリスト、ブライアン・ガーレット氏だ。

　「boot-from-SANやLUNクローンニングをサポートするストレージ・アレイには、サーバ・ベース・ソフトウェア、つまりブート・マネージャが不可欠だ」

　ARMは自動化されたboot-from-SANやサーバ・プロビジョニング製品を提供する。「ARMでは、複数のホスト・コンピュータを1つのイメージからブートできる。伝統的な（実行前）ブートは通常、1対1のオペレーションだ」とガーレット氏は説明する。

　ARMの場合、それぞれのサーバは同一のイメージからブートし、Tapestry ARM Service ProcessorがSAN上に格納されたイメージから、サーバごとにアプリケーション、OS、コンフィギュレーション設定をピックアップする。

　新しいサーバが配備されるとき、Tapestry ARMはサーバのFibre Channel HBAと連絡し、OSやアプリケーション・データがSANのどこに格納されているか通知する。ARMは自動的にサーバ・ハードウェアの違いに対応し、サーバに障害が発生した場合には別のコンフィギュレーションに切り替える。

　「サーバに障害が発生すると、（ARMは）最初のサーバのLUNに別のサーバをダイレクトする」と説明するのは、独立系ストレージ・アナリストのランディ・ケーンズ氏だ。

　ARMシステムは、それぞれのタイプのサーバ用にイメージのリポジトリを管理する。それらのイメージは、Tapestry ARM管理インタフェースから呼び出して、設定することが可能だ。

　Tapestry ARMは仮想マシンのOSとアプリケーションを単一のファイルにキャプチャできるマイクロソフトのVHD技術を利用している。このVHDをライセンスするベンダーには、Tapestry ARMに組み込むブロケードのほかに、BMCソフトウェア、富士通シーメンス、ネットワーク・アプライアンス、ソフトリシティ、バーチャル・アイアン、ゼンソースなどがある。

　しかし、Tapestry ARMの最大のアドバンテージは、サーバの配備とプロビジョニングを自動化することだ。boot-from-SANやLUNクローニングはマニュアルプロセスだが、Tapestry ARMの管理インタフェースは自動的に仮想ディスクを割り当て、LUNにサーバをアサインする。

　ブロケードのTapestry ARMのベータ・テストに参加したカリフォルニア州サクラメントの医療ネットワーク、サッターヘルスのアーキテクチャマネージャ、マシュー・デベニー氏は、その効果をこう説明する。

　「われわれは4万1,000人の従業員にアプリケーションを利用してもらっている。そうした環境では、マシンの配備、管理、プロビジョニングは非常に複雑なものになる。ベータ・テストした製品は、リソースのプロビジョニングに要するオーバー・ヘッドを大幅に軽減し、いずれはブレードやその他のサーバからドライブを取り払ってくれるだろう」

　パブリック・ブロードキャスティング・サービスのウォルターズ氏も、そうした見方に同意し、「いよいよ本格的なboot-from-SANの時代がやって来る」と期待を寄せている。

(Computerworld.jp)