サーバ・プロビジョニングを最適化する──新世代の「boot-from-SAN」の実力に迫る
これまで、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の時代がやって来る」と期待を寄せている。
(デニー・コナー/Network World 米国版)
提供：Computerworld.jp
