【テクニカルレポート】次世代に向けた、革新的なデータセンター環境とテクノロジ | RBB TODAY
※本サイトはアフィリエイト広告を利用しています

【テクニカルレポート】次世代に向けた、革新的なデータセンター環境とテクノロジ

エンタープライズ ソフトウェア・サービス
Tech OnTap
  • Tech OnTap
  • Brad Flanary氏
  • Kilo-Clientチーム
 2006年以来、Tech OnTapでは、NetApp Kilo-Client(NetAppの大規模エンジニアリング・テスト環境)の発展の過程を継続的に取り上げてきました。今回の記事では、この革新的な基幹施設の次世代開発計画の背景にある目標とテクノロジについて、NetApp RTPエンジニアリング・サポート・システム・チームのBrad Flanaryが説明します。(Tech OnTap編集部)

 NetApp Kilo-Clientとは、NetAppストレージのハードウェアとソフトウェアのテストにあたって、大量の物理クライアントや仮想クライアントをすばやく構成しブートすることができるNetAppのテスト環境です。第1世代のKilo-Clientは2005年に導入されました(詳細は過去のTOTの記事を参照)。当初、第1世代の環境では1,120の物理クライアントをサポートし、ローカル・ディスクからではなくiSCSI経由でこれらのクライアントをブートしていました。

 2007年中ごろまでに、Kilo-Clientは拡張され、1,700台の物理クライアントに対応して、それらをiSCSI、FC、NFS経由でブートできるようになっていました。クライアントは、Windows環境やLinux環境を実行する物理クライアントとして稼働することも、仮想化された VMware環境で稼働することもできました。 当時のTech OnTapの記事 では、NetApp FlexCloneを含めたNetAppテクノロジを利用して、物理サーバと仮想環境の迅速なプロビジョニングを実現している様子を重点的に紹介しています。

 この構成はNetAppにとって非常に役立つものでした(最後の記事発表以降、負荷の高い仮想化に対応するためにサーバが多少追加されています)。ですが、現在ほぼ3年が経過し、当初導入したサーバ機器のリース期限を迎えることから、このたび再度構成の世代交代を図り、最新のテクノロジとクラウド・コンピューティング技術を取り入れることとなりました。

 この記事では、第3世代のKilo-Client設計について説明します。設計完成時には、次のことが可能になります。

・最大75,000の仮想クライアントを同時に使用してテストを実行(「Kilo-Client(1,000のクライアント)」という呼び名がますます実際と合わなくなります)

・10ギガビット・イーサネットとFibre Channel over Ethernet(FCoE)を加えた、より広範なネットワーク構成のテスト

・数百または数千のクライアントをほんの数時間で導入

 では最初に、今回必要となった新たな要件と、ハードウェアの評価について説明し、最後に今年前半に運用開始予定のKilo-Client 3Gの設計をご紹介しましょう。また、Kilo-Clientが収容されているNetAppデータ・センター独自の設計についても説明します。

■全要件の確認

 NetApp社内の利用者とのミーティング結果や、現在の構成が要件に合わないという意見をもとに、私たちは次世代のKilo-Clientに何が求められているのかをまとめる作業に取り掛かりました。ただし正確を期すため、現在の社内利用者に加えて、潜在的な社内Kilo-Clientユーザ候補も対象とした詳細なアンケートを実施してから、今回の構成刷新に着手することにしました。図1をクリックすると、実際の調査資料が表示され、私たちが行ったアンケートの内容を見ることができます(ご覧になれば、質問の一部が仮想化を意識していることがお分かりいただけると思います。これは、物理クライアントではなく仮想クライアントによって利用者のニーズが満たせるかどうかを特に知りたかったからです)。

 主な調査結果は次のとおりです。

・利用者の多くに、物理ハードウェアではなく仮想ハードウェアでサービスを提供できる
・10ギガビット・イーサネットへの高い需要がある

・近い将来、FCoEへの需要がある(調査は何カ月も前に実施されているため、この需要は現在、現実になりつつあります)

 この調査にはきわめて重要な意味がありました。調査により、利用者の多くに、物理ハードウェアではなく仮想ハードウェアでサービスを提供できるのではないかという私たちの予想が裏付けられたのです。これは、仮想化とクラウド・コンピューティングが普及しつつある、現在のIT業界のトレンドと明らかに一致しています。また、サーバ仮想化をもっと推進しようという最近のNetApp内の取り組みとも一致しています(2009年7月号のTech OnTapの記事 で、インドのバンガロールにあるNetAppのエンジニアリング・ラボで実施したP2V(物理から仮想への)移行を紹介しています)。

■ハードウェアの評価

 新しいKilo-Clientの要件が把握できたため、次のステップとして、私たちはサーバ・ハードウェアの評価を開始しました。私たちはさまざまなサーバ・ベンダーにRFPを送付して、評価用の製品を入手しました。テスト・プロセスでは、次のような点に着目しました。

・FCoEと10 GbEの両方に対応するConverged Network Adapter(CNA;統合ネットワーク・アダプタ)のサポート(CNAの詳細については、(こちらから最近のTech OnTapの記事を参照してください)

・仮想化への対応

・パフォーマンス

・必要に応じてスケール・アップやスケール・ダウンが可能か

 CNA経由で提供されるパフォーマンスと、大規模な環境での仮想マシンのサポートにどれだけ適しているかという点、さらに、一連の標準ベンチマークでどれだけ良い結果を出せるかという観点からすべてのサーバを評価しました。

 私たちのニーズの場合、Intel Nehalemマイクロアーキテクチャ・プロセッサをベースとしたサーバの方が、従来のIntel Coreマイクロアーキテクチャ・プロセッサ(Dunnington)よりはるかに性能面で優れているということが、すぐに判明しました。選択した2種類のサーバ・モデルには、いずれもNehalemプロセッサが使用されています。

 ネットワークについては、NetAppの新しいGlobal Dynamic Laboratory(GDL)に、最近Cisco Nexusインフラを導入しました。このネットワーク・インフラは、Kilo-ClientのFCoEとIPのニーズを満たすため、今後も使用していく予定です。ファイバ・チャネル用には、 Brocade製スイッチング機器を使用することになっています。

■Kilo-Client 3Gの導入計画

サーバ:

・Fujitsu RX200 S5(48 GB、2 CPU)×468台:2.26 GHZ Intel Xeon E5520プロセッサ(Nehalem)搭載(4コア/8スレッドのプロセッサ。システムごとに8コア/16スレッドを提供)
・Cisco UCSサーバ×160台(Fujitsuと同じプロセッサ構成)
 ―48GBメモリ搭載機×48台
 ―24GBメモリ搭載機×112台

 すべて合わせると、628台のクライアントで5,024のコアを提供できることになります。元のKilo-Clientの3ポッド分、つまり 1,456のコアを備えた728台の物理クライアントが、この構成でリプレイスされます。対象のクライアントはすべて、主に仮想サーバとして使用できますが、物理クライアントとして利用することも可能です。物理サーバ1台あたり120のVMを使用できるため、新しいKilo-Clientでは最大 75,360のVMを提供できます。

 前世代のKilo-Clientで使用していた残り約1,000台のクライアントも、そのまま引き続きテストに利用します。この1,000台のクライアントは、リース期間終了に伴い、段階的に利用を停止し返却する予定です。

ネットワーク機器:

・コア:Nexus 7018(I/Oモジュール×16、バックプレーンは15 Tbpsまで拡張可能)
・アグリゲーション:Nexus 5010とNexus 5020
・アクセス:Nexus 2148T(FEX)
・ファイバ・チャネル:Brocade DCXダイレクタ・スイッチとBrocade 5320エッジ・スイッチ

ストレージ:

・FCブート:NetApp FAS3170ストレージ・システム×4
・NFSブート:NetApp FAS3170ストレージ・システム×16
・その他のストレージ:最新のNetAppストレージ・プラットフォームとディスクを幅広く用意

 通常は、NFSデータストアあたり500のVMをブートします。必要に応じ、SnapMirrorを使用して、中央のリポジトリから各ブート・ストレージ・システムへと「ゴールデン・イメージ」を複製します。

■物理ハードウェアと仮想マシンのブート

 Kilo-Clientで本当に重要なのは、すばやく、柔軟に、スペース効率よくブートできる機能です。あらゆるクラウド・インフラ同様、任意の数のクライアントを、別の物理的タスクまたは仮想的タスクへと迅速に転用できなくてはなりません。Kilo-Clientでは、物理サーバそれぞれのブートにはFCブートとFCoEブートを併用し、仮想化用のサーバ上では、NFSブートを使用して仮想マシンのブートをサポートします。

 物理ブートにFCブートを選択したのは、既存のKilo-Clientインフラにおいて非常に信頼性が高いことが実証されていたためです。ほとんどの大規模なサーバ設置環境では、1つの物理サーバがブートするブート・イメージは毎回同じです。物理環境ではLinuxやWindowsを、仮想環境では VMware ESXをブートするという違いはあっても、ブートするイメージは常に変わりません。ところが、Kilo-Clientの場合、この法則は当てはまりません。ある日はLinuxを、次の日はVMwareを、その次の日にはWindowsをブートする可能性があります。そこで、FC ブートにNetAppの動的なLUNクローニング機能を併用することによって、物理サーバと仮想サーバをすばやく効率的にブートしています。

 以前の記事でも紹介しましたが、この環境では使用する各オペレーティング・システムとアプリケーション・スタック用に、一連の「ゴールデン」ブート・イメージを(ファイバ・チャネルLUNとして)保持しています。NetApp SnapMirrorとFlexCloneを利用すれば、イメージの何百というクローンを短時間で作成し、テスト用に構成する各物理サーバで使用できます。プロビジョニングした各サーバには、ホスト固有の「カスタマイズ」をコア・イメージに施すだけです。この独自のアプローチを用いれば、ストレージをほとんど消費することなく、ほぼ瞬時にイメージのプロビジョニングが完了します。

 仮想マシンのブート・プロセスも、次のように同じ手順で実行されます。

・テスト用のホストごとにVMware ESXをブートする
・対象のホストをVMware Virtual Center(vCenter)に動的に登録する
・仮想マシンに適したネットワーク設定とデータストアを準備する
・NetApp Rapid Cloning Utility(RCU) を使用して、適切な数と適切な種類の仮想マシンをクローニングする。RCUはvCenterにVMを自動登録する
・サーバをDNSとDHCPに動的に登録し、仮想マシンをブートする
・すべてが正しく実行されたことを確認する

完全な自動化:私たちはここ数年の間に、NetAppおよびVMwareツールと連係して上記の手順を自動化するPerlスクリプトを作成しました。そのため、500~1,000台の仮想マシンの導入がルーチンとして2~3時間で行えます(この時間には、物理ブート・プロセスとVMのブート・プロセスの両方が含まれます。Tech OnTapで紹介した他の一部の導入事例とは異なりますが、それはサーバでVMwareが実行されていることを前提としていた導入時間だからです)。

スペース効率の最大化: ほかにNetAppのプロセスで特徴的なのは、FlexCloneを使用して「ゴールデン・イメージ」のコピーではなくクローンを作成しているため、ストレージ消費量が非常に少なくて済む点です。通常、わずか500GBのストレージ・スペース(1クライアントあたり1GB)を使用して500台の仮想マシンを運用していますが、必要ならばスペース消費量をさらに減らすこともできます。

 新しいインフラなら、非常に大規模なテスト用として、最大75,000の仮想マシンを構成することができます。新しいハードウェアをすべて導入し終えたら、この構成作業がどれだけ短時間で完了するかをご報告したいと思います。Kilo-Clientを構成するクライアントは通常、複数に分けられ、それぞれ並行してテストを実行する点に注意してください。
物理レイアウト:前世代のKilo-Client設計は「ポッド」をベースとしており、ポッドは同じ場所に配置されたサーバ、ネットワーク接続、ブート・ストレージで構成されていました。この方法は、ハードウェア同士がごく近くに設置されており、手作業での機器のセットアップや取り外しが必要となる設計に適しています。

 新しいKilo-Clientでは、このポッド・アプローチを再検討して改良を加えました。新たな設計ではすべてのブート・インフラを1箇所に集中させています。サーバとストレージ・システムはポッドとしてグループ化され、各ポッドには、ニーズに合わせたスイッチング機能(IPとFC)のみが含まれるようになります。そのためポッドの複製が簡単に行え、また、目的の種類のポッドを新たに追加していくことで、Kilo-Clientを任意のサイズに簡単に拡大および拡張できます(つまり、サーバのポッドやストレージのポッドを追加できるということです)。機器の手動でのセットアップや取り外しが必要なくなる(要求されなくなる)ため、スペースの増設が必要になった場合は新しいポッドをデータ・センターの任意の場所に導入することができ、結果としてデータ・センター自体の運用効率が最大化されます。

■NetAppのGlobal Dynamic Laboratory

 Kilo-Clientは、物理的にはNetApp Global Dynamic Laboratory(GDL)内に構築されています。このラボは、ノースカロライナ州のResearch Triangle Park(RTP)にあるNetAppの施設に設けられた革新的な新データ・センターです。Kilo-ClientはNetAppの開発部門の Shared Test Initiative(STI)に属すことになります。STIでは複数のテスト・ベッドを提供し、導入、テストの実施、結果収集の自動化に特に重点が置かれる予定です。STIはラボ内のすべてのリソースの仲介役となり、こうしたリソースを動的に共有できるようにします。

 GDLは効率性と自動化を念頭に設計されました。36室の低温に保たれた空調室を用意して、それぞれに約60のキャビネットを設置し、合計2,136のラックを提供しています。

 GDLのような 最新式データ・センターでは、次のような設計要素が重要になります。

・ラックあたりどれだけの電力を供給できるか(最近のハードウェアは小型化されていますが、以前よりも多くの電力を消費します)
・適切な冷却のためには、ラックあたりどの程度のスペースが必要か
・電力消費をどの程度効率化できるか(現在の電力効率のベンチマークは、PUE(Power Usage Effectiveness)値2.0です)

 GDLでは、電源と冷却用の電力に、ラックあたり平均12 kWを供給することを前提とし、空調室1室あたりで合計720kWの電力消費を見込んでいます。1ラック内の配電は42kWです。当社独自の気圧制御技術を利用すれば、キャビネット内は42kWまで冷却可能です。また、空調室内の総冷却負荷が720kW以内であれば、それぞれ異なる冷却負荷の組み合わせにも対応できます。

 GDLでは、次のようなさまざまな技術的手法を組み合わせることで、運用中の電力効率の最大化を図っています。

・冷却にできるだけ外気を利用する
・気圧を制御して冷却を行うことで、ファンやポンプに使用するエネルギーを抑制する
・室温と冷却水の温度を(室温なら、通常、摂氏10度から15.5度のところを21.1度から26.7度に)上げる
・排熱をオフィスなどで再利用する

 上記をはじめとするさまざまな方法を活用することにより、GDLでは、年1.2というPUE値の達成が見込まれています。これは、PUE値2.0で運用する場合と比べ、GDLでは年間700万ドルを上回る運用コストが削減されるとともに、運用に伴う二酸化炭素排出量が93,000トン削減されることを意味します。データ・センターの効率化に関するNetAppのアプローチについては、 最近のホワイト・ペーパー で詳しく紹介しています。

■まとめ

 次世代のNetApp Kilo-Clientでは、最新のサーバ・ハードウェア、ネットワーキング・テクノロジ、NetAppのストレージ・ハードウェアとソフトウェアをフル活用して、自動化された柔軟なテスト・ベッドを構築することで、大量の仮想クライアントや物理クライアントを必要とするテストが実行できます。新しい Kilo-Clientが完成すれば、75,000を超える仮想クライアントがサポートされるほか、ギガビット・イーサネット、10ギガビット・イーサネット、ファイバ・チャネル、FCoEを、すべてエンドツーエンドで利用できます。

 次世代のKilo-Clientは、既存のバージョンよりも大幅に機能を拡張し、一方で、最終的には物理サーバ削減が図れるでしょう。


■執筆者(敬省略)

・Brad Flanary
エンジニアリング・システム・マネージャー
NetApp

Bradは2006年にNetAppに入社し、現在は、NetApp Dynamic Data Center、RTP Engineering Data Center、NetAppのグローバル・エンジニアリング・ラボ・ネットワークを担当する、6名のエンジニア・チームのリーダーを務めています。 NetAppに入社する前は、Cisco Systemsで約7年にわたってLANのスイッチング・スペシャリストを務めていました。通算すると、大規模LANとデータ・センター設計に関して13 年を超える経験があります。


・Kilo-Clientチーム
NetApp

エンジニアリング・サポート・システム・チームのメンバーには、Brandon Agee、John Haas、Aaron Carter、Greg Cox、Eric Johnston、
Jonathan Davisがいます。

※同記事はネットアップ(NetApp)の発行する「Tech OnTap」の転載記事である
《RBB TODAY》
【注目の記事】[PR]

関連ニュース

特集

page top