Intel Xeon E5-2600/Xeon E7シリーズ Part3-2 Processor

仮想化データセンターのハードウェア基盤
データセンター完全ガイド 2012年春号(2012年3月31日発行)掲載
文:廣澤 純

Intel

2012年3月6日、Sandy Bridgeコアを使用した、2ソケットタイプのXeon E5-2600/1ソケットタイプのXeon E5-1600、加えてチップセットC600が発表された。Intel第2世代Coreプロセッサとしては、すでにXeon E3-1200プロセッサとC200シリーズがリリースされているが、Xeon E5-1600はワークステーション向けとして位置づけられ、Xeon E5-2600は、サーバー用メインストリームのXeon 5600番台の後継プロセッサと位置づけられている。

Intel Xeon E5-2600の投入

Xeon E5-2600の特徴を前世代のXeon 5600番台と比較してみると、LGAパッケージで32nmプロセスルールは同じだが、最大コア数は、6コアから8コアへと、2コアが追加され(ピン数も1366から2011へ)、コアの増加に伴い、L3キャッシュメモリの容量も、12MBから20MB(LLC:2.5MB×8)に増加している。Xeon E7には及ばないが、すでに大容量キャッシュと呼べるレベルに達している。なお、8コア版の最大動作周波数は、3.1GHz(6コア版が2.9GHz)となっている。

TDPは、コア数やキャッシュが増えており、トランジスタ数は前世代の倍近いにもかかわらず、あまり大きくなっていない。これも、さまざまな省電力技術の積み重ねによるものだろうが、最終的にはラック当たりのサーバー集約率に影響するだけに、非常に重要なポイントだ。

また、従来チップセットが担っていたメモリコントローラとPCI Expressのインターフェイスが、プロセッサコアと同じダイ上に統合されている。そのため、Xeon 5600番台では2つあったチップセットが、C600シリーズ1つになっている。また、ソケット間をつなぐインターフェイスのQPI(Quick Path Interconnect)は、プロセッサ間の帯域が2倍(2本のQPI)になり、QPIのデータ転送速度も6.4GT/sから8.0GT/sとなっている。

一方、プロセッサとC600チップセットを接続するインターフェイスは、DMI2で接続される。これはクライアントPC向けのSandy Bridgeと同じだが、チップセットとQPIで接続していた前世代のXeon 5600シリーズとは異なる。Xeon E5-2600では、I/Oがプロセッサ内部に統合され、I/Oのレイテンシを削減できたこと(後述)、加えてコア数の増大とともに、キャッシュの同期をとるための帯域が必要となるため、プロセッサ間のQPIリンクを2本に増やした方が、全体としてのメリットが大きいからだろう。

その他の機能追加としては、256bit拡張命令であるAVX(Advanced Vector Extention)の追加(1クロックで256bitの浮動小数点演算が可能)やターボ・ブースト・テクノロジー 2.0がある。こうしたプロセッサの総合的な改善により、Intelでは、前世代のXeonプロセッサ5600番台と比較して、最大で80%の性能向上を果たしたとしている(図1)。

図1 プロセッサ概念図(出典:Intel)
図1 プロセッサ概念図(出典:Intel)
表1 製品一覧(出典:Intel)
表1 製品一覧(出典:Intel)

搭載メモリ容量の拡大

コア数の増大とともに、1台の物理サーバーに集約される仮想サーバーの数が増えれば、当然メモリ容量もそれだけ必要になる。しかも、最近のサーバーOSは64bit版が普通になり、最低必要メモリが3GB以上というものも珍しくない。データベースをはじめ、基幹業務のアプリケーションでは、インメモリで処理するため、大容量のメモリを必要とするものも多いため、仮想サーバーが必要とするメモリもますます増大している。自ずと、サーバーに搭載するメモリも大容量にならざるを得ない。

Xeon E5-2600のメモリコントローラは、4チャンネルのDIMMに対応しており、1チャンネル当たり3本のDIMMをサポート可能で、1ソケット当たり最大12 DIMMを搭載可能だ。2ソケットの場合なら、32GBのRDIMMを使用すれば、768GBという大容量メモリが搭載可能となる。また、メモリの動作周波数も最大1600MHzまで対応する。対応するメモリモジュールは、RDIMM、UDIMMに加え、消費電力を抑える、低電圧版のLV-RDIMM、LV-UDIMMも使用可能だ。

I/Oのボトルネックを解消

Xeon E5-2600の発表では、注目される技術革新として特に強調されたのが、インテグレーテッドI/O機能である。

仮想サーバーがネットワークを経由して物理サーバー間を移動する環境では、1GbpsのNICではもはや十分な帯域とはいえない。最近では10GbpsのNICが普及したことで、徐々にNICのボトルネックが解消されつつあるが、今度は、NICからI/Oハブ以降のデータ処理が、ボトルネックになりかねない状況を生んでいる。

前世代までのプロセッサのI/Oデータの流れでは、メモリとのやりとりがかなり多い。まず、データはNICからI/Oハブを経由してプロセッサへ入り、プロセッサからメインメモリへ書き出される。その後、メインメモリからプロセッサのキャッシュに取り込まれ、プロセッサで処理を行い、その後キャッシュへを経由してメモリへ送る。メモリからはプロセッサ経由してI/Oハブを通り、NICへ送られる。データが、かなり煩雑な経路を通っていることが分かるだろう(図2)。

図2 従来のI/OとインテグレーテッドI/Oの比較(出典:Intel)
図2 従来のI/OとインテグレーテッドI/Oの比較(出典:Intel)

これが、Xeon E5-2600で採用されたインテグレーテッドI/Oでは、DDIO(Data Direct I/O)という仕組みを取り入れたことにより、PCI Expressからのデータを直接プロセッサのキャッシュに読み込み、メインメモリへ転送せずにプロセッサで処理を行う。I/Oハブがシリコンレベルでプロセッサの中に統合されたことにより、レイテンシは30%削減され、今まで以上の高速なデータ転送が行えるようになった。

さらに、I/Oの統合とともに、I/Oの性能も向上させるために、I/Oデバイスとプロセッサ間のPCI ExpressのインターフェイスをGen 3に対応させた。Gen 2と比較すると、トラフィックのオーバーヘッドが20%削減できるそうだ。また、レーン当たりの帯域幅が2倍になるということで、I/Oそのものも強化している(図3)。

図3 インテグレーテッドI/O(出典:Intel)
図3 インテグレーテッドI/O(出典:Intel)

仮想化データセンターにおける、今後の10Gbit/40Gbitイーサネットの導入ニーズや、高速なSASのコントローラの利用などを考えると、サーバー用途でのPCIe 3への対応は必須と考えたのだろう。現状では、PCIe 3対応の拡張カードは一般的ではないが、市場のニーズに応じて、徐々に製品も充実してくると思われる。

ハイエンドを担うXeon E7

現行ハイエンドサーバー向けプロセッサとしては、Xeon E7がすでに2011年4月5日に発表されている。性能はもちろんのこと、基幹系業務ITが必要とする、ビジネスデータの信頼性とセキュリティの確保が可能な、ハイエンドサーバー向けのプロセッサである。Sandy Bridge-EXがキャンセルされたため、現行のE7の販売が継続されるようだ。

Xeon E7は、ソケット当たり最大10個のコアを内蔵する。最大動作周波数は10コア版で2.4GHz(8コア版は2.66GHz)、最大30MBの大容量キャッシュ(LLC)を備える。しかも、最大8ソケット構成(80コア)までスケールアップできる。最近のソフトウェアライセンスは、メモリ容量や稼働させるマシンの数といったライセンス形態もあり、いろいろと条件が複雑になっているが、一般的なソケット単位で課金されるライセンスであれば、ソフトウェアの導入コストを抑えつつ、高性能を実現できる(図4)。

図4 Xeon E7のアーキテクチャ(出典:Intel)
図4 Xeon E7のアーキテクチャ(出典:Intel)

TDPは、1世代前のXeonプロセッサ7500番台(Nehalem-EX)と同じ95W〜130Wに抑えながら、最大40%の性能向上を実現したとしている。

プロセッサが内蔵するメモリコントローラーは、4つのメモリチャンネルを持ち、そこに各4本のDIMMを搭載可能だ(ソケット当たり16 DIMM)。一般的な4ソケットサーバーの構成であれば、計64スロットのDIMMをサポート可能なことになる。Xeon E7は最大で32GBのDIMMをサポートするため、ソケット当たり512GB、4ソケットサーバーで2TBのメモリを搭載できる。

これらの大容量メモリを安全に利用するため、Xeon E7の内蔵メモリコントローラーは、DIMM上の2チップのエラーまで対応可能なDDDC(Double Device Data Correction)、データを2つのDIMMに保持するメモリミラーリング、障害時用のスペアDIMMといった、メモリ保護機能を備える。また、消費電力を低減させるため低電圧動作が可能なLV DIMMをサポートするほか、メモリコントローラのブリッジチップなども前世代に比べて低消費電力化も図られている。

また、E7はミッションクリティカル向けのプロセッサとして、高信頼性技術を取り入れている。メモリコントローラーのDDDCに加え、MCA(Machine Check Architecture)リカバリ(図5)や障害の生じたコアの切り離し、外部インターフェイスであるQPIの自己修復やフェイルオーバーなど、さまざまな機能を備えている。仮想化プラットフォームでも、特にミッションクリティカルな業務を遂行するインフラには、Xeon E7のような高信頼性技術を備え、高可用性を担保可能なプロセッサが必須ともいえるだろう。

図5 MCAリカバリ
図5 MCAリカバリ
エラー情報がOS/VMMに渡され、OSやアプリケーションがデータを使用しないように、不良なメモリ上の位置にフラグが立てられる。システムはOSまたはVMMと連携してプロセスのリカバリまたは再スタートを行い、正常な動作を続ける。(出典:Intel)

ベンダーがリリースしているサーバー製品のラインアップでも、各社のラインアップのフラグシップとなるような製品が揃っている。いずれの製品ラインアップも、金融系や基幹システムなど、止めてはならないシステムへの導入実績が多いことも、E7プロセッサの性能を裏付ける事実と言えるだろう。

Intel Xeon E5-2600を搭載した、富士通PRIMERGYの新モデル

写真1 PRIMERGY RX200 S7(出典:富士通) 写真1 PRIMERGY RX200 S7
(出典:富士通)
写真2 PRIMERGY RX350 S7(出典:富士通) 写真2 PRIMERGY RX350 S7
(出典:富士通)

富士通は、Intel Xeon E5-2600が発表されたと同時に、2012年3月7日よりPCサーバー「PRIMERGY」の新2WAYサーバー4モデルの販売を開始した。4モデルの内訳は、2WAY 1Uラック型サーバー「PRIMERGY RX200 S7」、2WAY 2Uラック型サーバー「PRIMERGY RX300 S7」、2WAY 4Uラック型サーバー「PRIMERGY RX350 S7」、2WAYタワー型サーバー「PRIMERGY TX300 S7」の4モデル。

新たにラインアップする4モデルは、中堅・大企業における基幹サーバーや部門サーバー、仮想化システム、ハイパフォーマンスコンピューティングでのPCクラスタシステム、高信頼なクラウド環境を支えるデータセンターなどに適しているという。

「PRIMERGY RX200 S7」は(1Uラックマウントサーバー)は、最大2プロセッサ、16コア搭載(2P/16コア)、メモリ搭載量は、最大384GB(2プロセッサ構成時、16GB DDR3 1600 LV-RDIMM)、最大HDD搭載容量は、2.5インチSAS HDD:7.2TB、2.5インチSTATA HDD:8TB、2.5インチSSD:3.2TBとなる。拡張バスには、PCI Express 3.0のx16レーンが1スロット、x8レーンが3スロット(1スロットはSASアレイコントローラカード専用)が装備されており、PCI Express 3.0に対応した10Gbit NIC、高速SASカードなど、各種インターフェイスカードも用意されている。。

1Uでありながら、拡大する仮想化システムへの対応を踏まえ、DIMMを24枚実装可能としているため、16GBのRDIMM×24で、最大384GBまで拡張可能となる。また、メモリには高速な「DDR3 1600 RDIMM(PC3-12800)」を採用している。

また、メインメモリに訂正可能な異常が発生した場合に、同一メモリチャンネルの中で予約したメモリランク(メモリモジュールの動作ブロックの単位。1枚のDIMMで1ランクを使用するメモリをシングルランクメモリ、2ランク使用するメモリをデュアルランクメモリという)をスペアメモリとして用いる「ランクスペアリングモード」をサポートしている。本機能により、従来モデルにおけるスペアメモリ機能と比較し、より多くのメモリ容量をシステムメモリとして利用可能となった。

また、RX200 S7モデルの特徴として、搭載プロセッサの構成を識別して、冷却ファンの回転数を制御する機能が挙げられる。低消費電力プロセッサ搭載時には、従来機種に比べファン回転数を最大で33%低減ししている。

もう1つの特徴は、データセンター向けに提供する、バッテリー装置が内蔵可能という点だ。サーバー内蔵型バッテリー装置により、サーバーごとにバッテリーを持てるため、データセンターにおける電力の供給瞬断への対策が可能になる。これにより、大型UPSなど専用ファシリティが不要となり、設置面積の大幅な削減にも貢献できる。ただし、本装置はサーバーの電源管理方式に応じた提供を行うため、サーバー設置環境や要件に基づき適用効果を確認の上、個別に提供するオプションとなる。

仮想化データセンターのニーズに応える性能向上 Part3-1 Processor

仮想化データセンターのハードウェア基盤
データセンター完全ガイド 2012年春号(2012年3月31日発行)掲載
文:廣澤 純

変化の著しい市場ニーズに対応するため、サーバー仮想化やクラウドの進展とともに、プロセッサコア数の増加、コア性能の向上、搭載可能メモリ容量の増大などが年々加速している。それとともに、ミッションクリティカルなプラットフォームとして、省電力、セキュリティ(暗号化)、信頼性の向上、といった機能が要求されるようになっている。

爆発するインターネットとクラウド

2010年以降のクラウド化の進展は著しいものがある。インターネットサービスが増殖することで、パブリッククラウドでは、データとトラフィックが爆発的に成長している。Intelの予測によれば、2015年には、ネットワークに接続されているユーザーは25億人、ネットワークに接続されているデバイスは150億台、データ量は1000エクサバイトにも及ぶとする(図1)。これだけのデータとトラフィックをまかなうために、いったいどれほどのリソースが必要とされるのか、正直想像もつかないが、今よりはるかに多くの演算能力とメモリ、ストレージ容量とネットワーク帯域が必要とされることだけは確かだろう。

図1 Cisco Unified Data Center
図1 2015年の市場予測(出典:Intel)

一方、多くの企業のIT部門では、より高い価値をビジネスに提供するために、データセンターを仮想化することで、コストを引き下げ、サービスレベル、効率性、俊敏性の向上に取り組んでいる。当初は、サーバー仮想化により、サーバー統合を図り、コストの削減を図っていただけのものが、徐々に柔軟なリソース管理技術により、ダイナミックにリソースを割り当てることが可能になり、さらに運用が自動化され、今やサービスとしてITインフラが提供されるようになっている。その仮想化データセンターおよびプライベートクラウドといったITインフラの重要な技術基盤の1つとして、プロセッサは、さらなる性能向上と効率向上が求められている。

仮想化とクラウドへ向けた最適化

こうしたサーバー仮想化やクラウドの進展とともに、プロセッサのコア数の増加や性能向上、搭載メモリ容量の増大が年々図られてきたが、2011年末から2012年の初頭にかけて、AMD、Intelの最新アーキテクチャのサーバー向けプロセッサが登場している。

プロセッサのコア数とメモリ容量の増大は、そのままホスト可能な仮想サーバーの数につながる。また、1ソケット、2ソケット、4ソケット対応などの市場の比率も徐々に変化してきている。1ソケットは、仮想化用途ではスペース効率の悪さから徐々に敬遠されるようになり、1つのプロセッサに搭載されるコア数が増大したことにより、2ソケットでも十分なコア数が提供されることから、この市場がますます広がり、4ソケット市場はHPCなどの特殊な領域の用途と位置づけられるようになってきた。

また、コア単体のピーク性能の向上や搭載可能なメモリ容量の増大により、さまざまな用途のサーバーをホスト可能になっている。かつてはWebサーバーやアプリケーションサーバーの用途がほとんどだったが、データベースやERPなどのミッションクリティカルな分野へも、仮想化プラットフォームの用途は広がっている。それとともに、重視されるようになったのは、信頼性(耐障害性)やセキュリティ、省電力機能である。

前世代のプロセッサから、RAS(Reliability、Availability、Serviceability)については、冗長化やホットプラグ、障害復旧機能がずいぶん強化されてきているが、ここにきてハイエンドのプロセッサのみならず、メインストリームの2ソケット対応プロセッサにおいても、RASが強化されている。

さらに、最近になってクローズアップされてきたのがI/O性能である。ダイナミックな仮想サーバーのマイグレーションやストレージマイグレーションなどで、ネットワークをまたぐデータ転送量の飛躍的な増大に対応するために、I/Oレイテンシの低減や、帯域の拡大へのニーズも高まっている。従来、仮想化プラットフォームのボトルネックとなっていたのは、NICだったが、10Gbpsのイーサネットの普及により、そのボトルネックがNICから、プロセッサ側のI/Oの性能に問題が移りはじめたためだ。そのため、プロセッサ側のPCI Expressインターフェイスへの対応も、さまざまな改良が施されるようになった。

しかし、こうしたさまざまな革新的な技術も、長い目で見れば、1つのマイルストーンに過ぎない。Intelが予測するような、急激な変化にITが対応しなければならないという現実が直前に迫っており、その先にはさらなるデータ爆発が待っている。そのためには、性能はもちろんのこと、コスト、効率の向上といった点で、ITインフラを築くプロセッサには、まだまだ厳しい要求が突き付けられることになるだろう。

ネットワークファブリックを前提としたデータセンターソリューション Part2-2 Network

仮想化データセンターのハードウェア基盤
データセンター完全ガイド 2012年春号(2012年3月31日発行)掲載
文:渡邉利和

Cisco

Cisco Systems(以下Cisco)は、IPルーターなどのTCP/IPネットワーク機器の開発、SANスイッチ、UCSといったサーバーハードウェアも手掛けるているが、現在、これらの要素を統合した「ユニファイドデータセンター」に取り組んでいる。

Unified Data Centerの全体像

Ciscoでは、大目標として「サービスとしてのIT(IT-as-a-Service)を提供できるプラットフォーム」として、“Unified Data Center”の実現を掲げている。

同社が考えるUnified Data Centerは、具体的には“Unified Fabric”“Unified Computing”“Unified Management”の3つのサブコンポーネントで構成される(図1)。Unified Fabric(ユニファイドファブリック)は、ネットワークの仮想化の取り組みであり、旧来のイーサネットをファブリックアーキテクチャに進化させる取り組みだ。Unified Data Center実現のためにUnifeid Fabricに求められている要件は、「高度にスケーラブルでセキュアなネットワークファブリック」ということになる。次に、Unified Computing(ユニファイドコンピューティング)は、従来のIAサーバーのアーキテクチャを踏まえ、仮想化とファブリックネットワークを前提として最適化された、サーバーハードウェアを新たに実装する取り組みだといえる。ここで求められている要件は、「モジュラ化されたステートレスなコンピューティングエレメント」ということになる。別の表現としては、「IPアドレスを持つプロセッサが、直接ネットワークにぶら下がっている」という言葉も聞いたが、これはUnified Computingのイメージを分かりやすく伝える表現だといえるだろう。最後に、Unifeid Managementは必然的に大規模化していくUnified Data Centerを効率的に管理するための運用管理体系だ。「物理/仮想を問わず、自動化されたリソース管理が可能であること」が求められる。

図1 Cisco Unified Data Center
図1 Cisco Unified Data Center

Ciscoは一見すると、自社の中核事業を軸に既存の隣接事業領域へと段階的に浸食していったようにも見えるが、Unified Data Centerというコンセプトを出発点に据えると、実は既存の製品/コンポーネントはいずれもUnified Data Centerが求める要件にそのまま合致するものではない。そのため、Cisco自らがコンポーネントレベルから実装しない限り、Unified Data Centerというコンセプト自体が実現し得ないものだということが分かってくる。では、それぞれの領域で今Ciscoがどのようなテーマに取り組んでいるのかを見ていこう。

Unified Fabric

Unified Fabricに関しては、「仮想化インフラに対応したネットワークファブリックを実装する」というレベルであれば、2011年の段階でNexusシリーズの対応製品がほぼ出揃ったといえる状況だ(図2)。ただし、今後仮想化インフラとして利用される“大規模なフラットネットワーク”がさらに規模拡大を続けていくことが予想されるため、「より大規模な環境で、よりきめ細かなサービスを実現する」という目標を掲げて進化を続けている。

図2 Cisco Unified Fabricポートフォリオ
図2 Cisco Unified Fabricポートフォリオ

たとえば、データセンター事業者などのクラウドサービスプラットフォームを考えた場合には、テナント間を分離するために設定するVLANの現状の上限数は4000程度なので、すでに不足が見えている状況だ。この状況を打開するために、CiscoではVMwareと共同で新たな規格としてVXLANの開発に取り組み、すでにNexus 1000Vに実装している。

VXLANでは、従来12bitだったVLANアドレスを24bitに拡張することで、理論上のVLAN数の上限を1600万以上にまで拡大した。ただし、実際にはすぐに1600万ものVLANを設定/運用できるわけではなく、Nexus 1000V自体のスケーラビリティがまだ追い付いていない部分がある。VXLANの実装はあくまでもまだ初期段階にあり、今後大規模ユーザーのニーズに合わせてスケーラビリティを高めていく必要がある。

また、2012年に予定されているアップグレードとしては、広範な仮想化インフラに対する対応強化が挙げられる。現状ではVMware vSwitchに対応するNexus 1000Vでの実装が先行しており、仮想マシンに対するポリシーコントロールが実現されているが、他のCitrixのXenServerやMicrosoftのHyper-Vといったマルチハイパーバイザー環境への対応は、まだVMwareのレベルには達していない。この部分の強化がまず2012年に実施されることになるだろう。

また、ネットワーク回線自体の高速化への取り組みも着実に進行している。まず、上位レイヤでは“サーバーからの10Gbpsアクセス”の需要が高まってきている。これまでの10Gbpsイーサネットは、バックボーンやコアの技術だったのが、サーバーアクセスに降りてくると、当然バックボーンやコアでは40G〜100Gbpsの回線が必要になってくる。2012年初頭に英ロンドンで開催されたCisco Liveでは、初の40G/100Gのプラットフォームとなる新しいNexus 7000シリーズ用の「M2シリーズモジュール」が発表されている(図3)。「40G/100G×2ポート」や「40G×6ポート」がすでに実現されており、40Gbps/100Gbps時代への備えができつつある。なお、Nexus 7000シリーズはこうした新しいインターフェイスモジュールをワイヤーレートスループットで駆動できる第2世代ファブリックを採用しており、その点の対応も問題ない。

図3 Nexus 7000シリーズ用の「M2シリーズモジュール」
図3 Nexus 7000シリーズ用の「M2シリーズモジュール」

現時点で「40G/100G」を考える場合は、10Gbpsのトランキング(チャンネリング)との優劣も話題に登る。Ciscoによれば、「10Gのとチャンネリング技術でも160Gといった相応のパフォーマンスを安価に実現できる」としているが、一方で、チャンネリングでは大量のフローがあった際などのロードバランシングに課題があり、運用管理負担が重くなると指摘している。負荷が高まってきた場合には、特定のチャンネルにトラフィックが片寄せされてしまう傾向があり、均一に分散させることが難しいということだ。また、サービス事業者などでは、対外接続回線として確保しているダークファイバの芯数が限られているといった事情により、芯数消費を増加させることなく、高速化が可能なより高速な規格に移行したいというニーズもある。M2モジュールは、2012年4月〜6月期にワールドワイドでリリースされる予定だ。

なお、ファブリックを実現するために必要となる、スパニングツリーの代替となるマルチパス制御プロトコルに関しては、同社ではすでにTRILLが実用段階に到達しているという認識だ。すでにNexus 5000で稼働している“FabricPath(ファブリックパス)”“FEX(ファブリックエクステンダ)”はフラットなネットワークをサポートするための基幹技術として認知されており、次の課題はスケーラビリティをさらに高めていくという、量的拡大の問題となっている状況だ。IETFによるTRILLの標準化作業もほぼ一段落という状況なので、同社としては競合他社の状況も見ながらTRILL対応も視野に入れているということだ。とはいえ、競合他社がどこもサポートしない状況で同社だけが標準規格としてのTRILLをサポートしてみても、相互接続性という観点からは何の意味もないわけで、現実にファブリックをマルチベンダーで構築したいユーザーがいるかどうかということまで考えれば、現状のFabricPathで問題ないのではという判断もあるようだ。

Unified Computing

UCS(Unified Computing System)は、「ネットワークベンダーのCiscoがサーバー市場に参入した」として話題を呼んだブレードサーバー(後にラックマウントサーバーも追加)だが、CiscoではUCSを「仮想化およびクラウドに最適化された、ファブリックベースのx86コンピューティングアーキテクチャ」と位置付けている。

UCSでは、「ネットワークに繋がるコンピューティングの部分を含めて全体リソースをどう管理するか」という観点から、コンピューティングを担うサーバーのアーキテクチャはどうあるべきかという、根本から見直しを行っている。結果として採用された実装では、「トップオブラックのファブリックインターコネクト」(Nexus 5000相当)、「ファブリックエクステンダ」、「インテリジェンスを排除したブレードシャーシ」「高度にモジュール化されたブレードサーバー」といったコンポーネントが使われている(図4)。

図4 Cisco UCSの基本的な構成要素
図4 Cisco UCSの基本的な構成要素

サーバー機能

IAサーバーは「すでにコモディティ化している」といわれることも多いが、UCSでは既存のIAサーバーをベースに、「メモリの拡張」「仮想インターフェイス化」「VM-FEX(仮想ファブリックエクステンダ)」といった機能拡張を施している。これは、Unified Fabricの中のコンピューティングモジュールとして動作するために求められる要件だ。また、同時に提供される「UCSマネージャ」という管理ツールで「サーバー、ストレージ、ネットワーク」のすべてを一括管理できることは当然として、このツールが持っているすべての機能を公開APIを通じて外部から利用できるので、ユーザーの自社環境や独自に作り込んだツールを使った管理体系の中に、UCSを自然に取り込めるように配慮されている。

ブレードのメリット

ブレードサーバー化したことの最大の利点は、ケーブリングがシンプルになることだ(図5)。本来ブレードサーバーが持っている利点である、シャーシにブレードを追加すれば、すぐにコンピューティングリソースを追加でき、柔軟かつ迅速に利用できるというメリットが実際に享受できる。UCSではシンプルなケーブリングでダイナミックなリソースアロケーションが可能になっているため、ストレージ/ネットワークの帯域幅も事前に固定的に割り当てるのではなく、利用状況に応じて柔軟に割り当てを変更することができる。新世代のUCSでは片系80Gbps(10Gbps FCoE×8本)のポートチャネルを2系統接続しているため、冗長性を確保したビッグパイプとして柔軟に利用できる。

図5 シンプルなケーブリング
図5 シンプルなケーブリング

拡張性

UCSの現状での拡張性は、最大でシングルドメインで320サーバー、コア数では6000コア以上を、一元管理可能な規模に達している。サービスプロバイダなどの特別な用途を除けば、一般的な企業の用途ではまず不足することはない規模だ。また、以前はvMotion(ライブマイグレーション)に一定の制限があったが、新世代モデルではDirectPath/VM-FEXを活用した高速なラック間での仮想マシンの移動も実現している。ワールドワイドでは、Cisco Unified Data Centerコンセプトにとらわれず、汎用サーバーの置き換えとしても評価が高まっているという。特に、大容量のメモリが利用可能など(2ソケットXeon 5600使用時、最大384GB)(図6)、演算サーバーとしての能力も高いためだ。最初の出荷開始からまだ3年経っていない段階だが、すでにブレードサーバーシステムとして市場シェア第3位になっている。Cisco社内でも製品別のシェア成長率ではトップクラスで、それを反映して開発投資額でもトップクラスの扱いになっているという。

図6 拡張メモリ
図6 拡張メモリ

省エネ機能

やや地味だが、国内の市場状況を考えた場合に重視されそうなポイントとして、省電力性能の高さも指摘できる。設計段階から省電力性能を重視しているという点は、今では特に目新しい話ではないが、UCSの場合はブレードシャーシやミッドプレーンにインテリジェンスを持たせないアーキテクチャのため、高効率な空調を実現するための開口率を高めに設定できるというメリットもある。さらに、運用管理面ではUCSマネージャの「パワーグループキャッピング」機能が有効だ(図7)。グループごとに消費電力の上限値を設定できるため、たとえばあるラックに収容された機器全体でキャッピングを行い、ラックへの供給電力を超えないように制御する、といった設定が可能だ。ラックの供給電力の上限を超えないように、消費電力を制御するのは当然ともいえるが、実際にこうした制御をリアルタイムで緻密に行うのは簡単ではなく、現実にはカタログスペックに基づいて相当の余裕を見た機器配置を行うことで、トラブルを避けているのが一般的だ。しかし、これは電力リソースのオーバープロビジョニングといえる状況でもある。パワーグループキャッピングを活用することで、利用可能な電力を上限まできっちり使い切るといった運用も、容易に行えるようになるため、無駄をさらに削った高レベルの効率化が達成できることが期待できる。

図7 Power Group Cappingによる管理概要
図7 Power Group Cappingによる管理概要

Unified Management

CiscoのUnified Data Center構想では、高度なインテリジェンスを実装した抽象度の高い運用管理ツールが重要な役割を担うことになる。このために用意されているのが、Unified Managementのレイヤで、最新製品として「Cisco Intelligent Automation for Cloud(CIAC)」が2011年秋に発表されている。Unified FabricおよびUCSを統合管理するためのソフトウェアと位置付けられるが、実態は管理ツールというよりもむしろ自動化を実現することに主眼がある(図8)。

図8 CIACの動作概要
図8 CIACの動作概要

構成要素となるのは、サービスポータルを実現するための“Cisco Cloud Portal”、オートメーション/オーケストレーションのための“Cisco Process Orchestrator”、ネットワークコンテナを管理する“Cisco Network Service Manager”の3要素だ。Cloud Portalは、2011年3月に買収されたnewScale、Process Orchestratorは2009年4月買収のTidal Software、Network Service Managerは2010年12月買収のLineSider Technologiesの製品が、それぞれベースとなっているという。なお、Network Service Managerは2012年6月以降に追加される計画となっており、まずはCloud PortalおよびProcess Orchestratorから提供が開始される。

3つの構成要素となるそれぞれの機能としては、Cisco Cloud Portalが、ユーザー、インフラ管理者、サービスカタログ管理者などにクラウド管理用のサービスポータルを提供し、Cisco Process Orchestratorでは、汎用性の高いビジネスワークフローの作成機能を提供する。これは、従来手作業でやっていた手順をインテリジェントに実行する「ジョブスケジューラ(Run Book Automation)」機能だと考えれば分かりやすい。実装上の実態としても、個別に対応する外部ツールに対して準備されたシナリオに沿って、順次指示を送るという動作となっている。用途を考えて、エラーハンドリング機能の強化や作業のロールバックができるように拡張されている点が特徴だ。

Cisco Network Service Managerでは、仮想化されたネットワークの自動的なプロビジョニングを実現する。スイッチやルーターといった個々のネットワークデバイスのレベルではなく、VLAN全体としての品質保証を「ゴールド」「シルバー」「ブロンズ」といった形で設定し、ユーザーが要求するQoSに見合ったネットワークリソースをプロビジョニングすることを支援するツールとなる(図9)。

図9 ネットワークサービスカタログ
図9 ネットワークサービスカタログ

これらのツールによって、データセンターのプロビジョニングの自動化を実現するのが主眼だが、当然ながらCIACを導入すれば即座に自動化が完了するわけではない。サービス自体の標準化やサービスカタログの整備など、事前に済ませておくべき作業は膨大にある。とはいえ、一度環境ができてしまえば、以後はエンドユーザーがセルフサービスでITリソースを確保できるし、トラッキングや承認プロセスといった業務プロセスも連動する。

なお、CIACはCisco社内のIT部門が実際に業務で活用しているツール群だという。社内ITプロジェクトである“CITEIS”は、同社の積極的なM&A戦略を受けてデータセンターコンソリデーションを日常的に実施している状況をサポートしている。同社では特に被買収企業が買収以前に抱えたITリソースの重複削減を効率よく行うことを重視しており、基本的にはR&D部門を含めて被買収企業の社内ITリソースは一切残さず、IaaSなどで代替するのだという。その際に業務を止めないためには、ユーザーが必要とするポリシーに見合ったITリソースをセルフサービスで迅速にプロビジョニングできる必要があり、そのために必要な機能がCIACに実装されているという。

こうしたツールが整備されてくることで、抽象度の高い論理的なプロファイルに基づいて、運用管理を行うという、Unified Managementのコンセプトがより高い精度で具現化していくことになるだろう。

16コアを搭載する、世界初のx86プロセッサ Part3-3 Processor

仮想化データセンターのハードウェア基盤
データセンター完全ガイド 2012年春号(2012年3月31日発行)掲載
文:廣澤 純

AMD

AMDの資料によれば、Opteron 6200シリーズは、前世代の製品(Opteron 6100シリーズ)に比べ、より小さいダイサイズでコア数が33%増加し、性能が35%向上しているとしている。低消費電力で、より高い性能を引き出す工夫が盛り込まれている。用途としては、クラウドクラスタ、仮想化、HPC、データベースアプリケーションのような、スケーラビリティを要求するコンピューティング市場を狙っている。

AMD Opteron 6200シリーズ

AMDは、2011年11月に2つのサーバー向けプロセッサを発表した。1つは1〜2ソケット版のOpteron 4200シリーズ(コードネーム:Valencia)、もう1つは、Opteron 4200のダイ2つを1つのパッケージにした2〜4ソケット版サーバー向けのOpteron 6200シリーズ(コードネーム:Interiagos)だ。いずれもプロセスは32nmで、材料はSOI、開発コードでは、「Buldozer」コアと呼ばれていたアーキテクチャで、GLOBALFOUNDRIES(2009年にAMDから分社された製造部門)で製造される。

Opteron 6200シリーズでは、4コア、8コア、12コア、16コアの製品ラインアップがあり、世界で初めてx86 16コアを搭載したプロセッサとなった。基本的な仕様としては、コアの周波数は、一番低い1.6GHz(6262HE)〜4コア(6204)の3.3GHzまでの幅があるが、中心は2GHzの半ばぐらいに収まっている。L3キャッシュはいずれも16MB、TDPは最小の85W(6262HE)〜最大140W(6282SE)だが、それ以外は115Wとなっている(表1)。さすがに最大コア数が16個ともなると、コア数が6、8といったOpteron 4200のTDP(95W)とは桁が違っているが、コア数が倍にもなっているのに、TDPが意外に低い数値に収まっているのは、さまざまな省エネ設計の寄与するところだろう。

表1 AMD Opteron 6200シリーズプロセッサ製品仕様
表1 AMD Opteron 6200シリーズプロセッサ製品仕様
(出典:"AMD Opteron 6000 Series Platform Quick Reference Guide")

Opteron 6200シリーズの機能的な特徴としては、コア周波数のブースト機能、浮動小数点ユニットの共通化、メモリコントローラの改良、TDPのパワーキャッピングといった点が挙げられる。

AMD TURBO COREテクノロジーは、コア周波数のブースト機能で、TDPに余裕がある場合に、アプリケーションの必要に応じて、自動的に300〜500MHz、最大で1GHzまでコア周波数を引き上げる機能だ。すべてのコアをブーストする場合は500MHzまで、スレッド数が少ない負荷の場合、プロセッサコアの半分がC6スリープ状態になり、コア周波数を1GHzほどブースト可能となる(図1)。

図1 TURBO COREテクノロジー(出典:AMDTHE CORE OF THE CLOUD)
図1 TURBO COREテクノロジー(出典:AMD "THE CORE OF THE CLOUD")

Flex FPとは、利用頻度の低い浮動小数点ユニットを2つの整数演算コアで共通化して、ダイスペースと消費電力を削減したことを指している(図2)。このほかにも、消費電力の削減という点では、アイドルコアへの電力とクロック供給の停止(C6サポート)、BIOSやAPML(Advanced Platform Management Link:AMDのシステム管理モニタ)の設定により、プロセッサの最大電力を設定する、TDPパワーキャッピングといった機能が盛り込まれている。

図2 FLEX FP
図2 FLEX FP
(出典:AMD "THE CORE OF THE CLOUD")

メモリコントローラでは、大容量のメモリをサポートしている。メモリチャンネルは、6コアのAMD Opteronプロセッサの2倍になっており、Opteron 6200では、1プロセッサ当たり4つのメモリチャンネルがあり、4プロセッサ搭載の場合は、16チャンネルとなる。1チャンネル当たり3つのDIMMスロットがあり、最大で48スロットのDIMMが実装できる。価格の安い8GBのDIMMを使っても、384GB実装可能となる(計算上だけで言えば、32GBのDIMM使えば、最大1.5TBのメモリを実装できることになる)。

Opteron 6100シリーズに比べて、メモリとの帯域幅も増大している。HyperTransport 3.0 Technology(HT3)では、プロセッサとI/Oのインターコネクトは、最大6.4GT/sまで帯域が向上している。

メモリの周波数は、1600MHzのDDR3までサポート。また、1.35Vや1.25Vといった低電圧・超低電圧のDIMMに対応している。 

図3 省エネ機能(出典:AMD 
図3 省エネ機能(出典:AMD "THE CORE OF THE CLOUD")

AMD Opteron6200を搭載した、HP ProLiantサーバー

写真1 HP ProLiant DL165 G7(1U) 写真1 HP ProLiant DL165 G7(1U)
写真2 HP ProLiant DL585 G7(4U) 写真2 HP ProLiant DL585 G7(4U)

HPは、AMDのサーバー向けプロセッサ搭載サーバーを販売するベンダーの1つだが、1Uラックマウントからブレードサーバーまで、最も幅広いラインアップを揃えるベンダーのひとつである。2011年12月20日の発表でも、1Uラックマウントサーバーの「HP ProLiant DL165 G7」、2Uラックマウントサーバー「同DL385 G7」、4Uラックマウントサーバー「同DL585 G7」、ハーフハイトブレードサーバー「同BL465c G7」、フルハイトブレードサーバーの「同BL685c G7」まで、5機種を同時に発表している。

この最新プロセッサを搭載した「HP ProLiant DL385 G7」(2Uラックマウントサーバー)のSPEC CPU2006ベンチマークによるHPでの性能比較では、従来のAMD Opteron 6100シリーズ搭載モデルに比べて、整数演算で23%、浮動小数点演算で13%の性能向上を実現しているという。x86アーキテクチャのプロセッサを搭載したサーバーの中では、ハイエンドのサーバーとして、データベース、HPCの実行環境として大規模処理を短時間で実現できるとしている。しかし、AMDプロセッサのこれまでのデータセンターなどでの利用形態を見ると、やはり仮想化されたサーバー環境でのアプリケーションサーバーやWebサーバーといった利用形態が多いように見える。Opteron 6200に多くの利用者が期待するところは、サーバー仮想化を前提とした、プロセッサ当たり16コアという実装コア数の多さ、コア単価の安さ、サーバー統合率の向上といった点ではないだろうか。

1UラックマウントタイプのDL165 G7でも、2プロセッサ、32コア搭載(2P/32C)(最高2.6GHz)、メモリはプロセッサ当たり4チャンネルを持ち、2プロセッサモデルでは、8チャンネル、各チャンネルに3本のDIMMスロットがあるから、メモリは全部で24スロット、最大384GB(16GB RDIMM×24)を搭載可能(ただし、UDIMMの場合は最大64GB)、最大内蔵HDD容量は8TB(1TB SATA×8台)となっている。

4UのDL585 G7に至っては、4プロセッサ、64コア(4P/64コア)(最大3.0GHz)、4プロセッサ構成の場合、メモリチャンネルはサーバー全体で16チャンネル。計48スロットになり、4CPU構成の場合(2CPU構成の場合は24スロット)、8GBのDIMMなら384GB、最大では、16GBと32GBのDIMMを組み合わせ1TBを搭載可能となり、HDD容量は最大8TBとなっている。

HPによれば、ラック当たりでの密度では、サーバー集約による設置スペースコストの削減が図られている。さらに、新プロセッサはコア当たり価格を最大64%低減、同等価格の製品比較では2倍のコア数を提供し、サーバー/クライアント仮想化の初期導入コストの削減に寄与できるとしている。

また、クラウド環境では仮想サーバーの動作状況により、サーバーの消費電力が動的に変化する可能性があるため、サーバー単体あるいはサーバーグループで電力消費の制御が可能なことも、重要な要素となるだろう。HP ProLiantのラインアップでは、消費電力の上限値を設定できるHP Dynamic Power Cappingなどの節電テクノロジーにより、データセンターでの運用管理において、適切な冷却能力や電力消費のプロビジョニングを行うことが可能となる。

ファブリックでクラウド間連携までも実現 Part2-1 Network

仮想化データセンターのハードウェア基盤
データセンター完全ガイド 2012年春号(2012年3月31日発行)掲載
文:渡邉利和

Brocade Comunication Systems

FC SANでの長い経験と豊富な実績を誇るBrocade Comunication Systems(以下Brocade)は、FC SANで実現されたファブリックアーキテクチャをイーサネットにも応用する形で「イーサネットファブリック」を実現し、すでに製品化して市場投入を開始している。イーサネットファブリックが必要とされる背景にあるのは仮想化の普及だが、同社のコンセプトは単なる仮想化インフラへの対応というレベルにはとどまらず、クラウド間連携など、より大規模な課題に対する汎用的な解決策として位置付けようとしている。

イーサネットファブリックの基本

ネットワークの仮想化に関する要求は、サーバーの仮想化の普及を受けて生じたものだ。仮想化インフラを支えるネットワークには、仮想マシンの広範かつ自由な移動を保証するためにも、L2のフラットな構造が要求される。一方、イーサネットの基本的なトポロジでは、L2レベルでループ経路が存在しないことが前提となっているため、L2のフラットなネットワークを大規模に拡張していくには無理がある。まずは、この問題を解決することがイーサネットファブリックの重要な要件となる。

L2レベルでループ経路を認めないとなると、ある経路に確保できる帯域幅は、その時点でのイーサネットの最新規格の上限速度に規定される。現状では10Gbpsが実用上の上限だと考えてよいだろう。FC SANファブリックであれば、ノード間のデータパスを多重化することで帯域を2倍、3倍と拡大していくところだが、ループ経路を認めないイーサネットでは、スイッチやサーバー側NICが特別に対応している場合にのみトランキングも利用可能になるが、一般的には帯域の拡大はあきらめざるを得なかった。

一方で、特定のサーバーが運用するネットワーク接続が常に1本のみということになると、耐障害性という観点からは極めて脆弱となる。そこで、実際には複数経路を確保して冗長性を確保しつつ、L2ネットワーク制御上はこの冗長経路をソフトウェア的に切断しておくことで、ループの発生を回避するという手法をとっていた。この制御を行っているのがスパニング・ツリー・プロトコル(STP)である。FC SANファブリックとの比較で見れば、イーサネットでは経路を多重化しても予備経路にしかならず、帯域拡大には役立たないため、投資効率が低いことになる。一方、大規模なクラウド事業者などでは仮想化インフラの規模の拡大が続き、パフォーマンスの劣化を防ぐためにもネットワークの帯域拡大が急務だが、既存規格の多重化では対応できる範囲が限定され、基本的には新規格への置き換えによってのみ高速化が可能なイーサネットの現状は、事業拡大の制約要因となっている。

イーサネットファブリックというコンセプトは、こうした仮想化時代の新しい要件に対応しきれなくなった、イーサネットのモダナイズの試みであり、既存のイーサネットの技術的な蓄積を活用し、可能な限りシームレスな形で新しい体系に移行しようという発想でもある。当然、全体としてはフラットな構造を維持しつつ、十分な帯域幅の拡大に対応できる必要がある。さらに障害発生時の迅速な回復/経路切り替えなどが可能であることが求められる。また、運用管理の観点からは、従来独立したネットワークとして運用されてきたLANとSANを統合し、全体を単一ネットワークとしてシンプルに管理できることや、仮想化インフラと連携して、事実上オペレーションフリーで対応できることなどが求められる。こうした要件に対して、各社各様の取り組みで実装が行われているわけだが、Brocadeの取り組みは業界での先進的なもので、すでに実用段階に入っているという大きなアドバンテージを誇る。

図1 イーサネットとイーサネットファブリック
図1 イーサネットとイーサネットファブリック
イーサネットファブリックは、従来の階層的なイーサネットと比較して、STPがなくなり、帯域幅の向上、耐障害性、拡張性に優れる。これらを可能にするBrocade VCS(Virtual Cluster Switch)ファブリック技術では、ファブリック内にあるすべてのVDXシリーズのMACアドレステーブルとポートプロファイル情報が同期されている。

ファブリックをどう活かしていくか

BrocadeのファブリックスイッチであるBrocade VDX 6720データセンタースイッチは、2011年1月から市場投入が始まっており、2011年8月にはVDXの2つの新モデルを発表している。日本国内に限っても、すでに50社以上のユーザー企業が採用し、本番系システムでの採用例も30社を超えるという。新製品/新技術の採用に慎重な国内市場の傾向を考えれば、かなりの採用数といえそうだ。

昨今の仮想化インフラの普及から、クラウド環境への進化を踏まえ、多くのユーザー企業では「CPU、メモリ、ディスクといった要素を“リソース”としてステートレスな形で蓄え、なんらかのネットワークを通じて動的に切り出してきて利用する」というシステムイメージを指向している。以前からデータセンターで提供されてきたホスティングサービスなどは、エンドユーザーの視点から見れば似たようなものに見えるかもしれないが、オペレーションを担当するデータセンター事業者側から見れば、あらかじめセットアップして準備しておいた物理サーバーの上に仮想サーバーを展開していくのと、リソースとしてCPU、メモリ、ディスクをプールしておくのとでは、かなり大きな差があるわけだ。前者は単に仮想化インフラが整備されていれば実現可能だが、後者のリソースプールを実現するには「低遅延」「大容量」のネットワークによって「コンピュートブロックを相互に結合する」という発想が不可欠だ。これこそが、Brocadeが指向するイーサネットファブリックの有り様だといえる。このとき、これまでSANという形でネットワークをLANから分離していたストレージ固有の要件が存在するのだが、これを正しく理解し、システムからのアプローチができる唯一のネットワークベンダーが、Brocadeだとも言えるだろう。それも、SANスイッチのリーディングベンダーとして、ストレージ側の要件に応えてきた経験があってのことだ。

こうしたファブリックは、クラウドサービスを支えるデータセンター事業者のインフラとして活用されるのは当然としても、さらに最近のキーワードでもある「リアルタイム処理」「ビッグデータ処理」への応用にも力を発揮する。M2Mなど、機械(センサー)が大量のデータを生成し、それをリアルタイムで受け取って適切な処理/解析を行うといったデータ処理が、一般に利用されるのもそう先の話ではない。こうした処理は、単にデータ量が増大するだけにはとどまらず、リアルタイム性が求められることから、当然ネットワークにも高い水準の要求を突き付けることになる。イーサネットファブリックは、こうした新しい時代の新しい要件に必要なインフラとなる。

さらに、震災の発生などを受けて国内企業では災害対策/バックアップサイトといった対応への関心が高まっているが、こうした用途に関してもイーサネットファブリックが果たす役割は大きい。現状では、LANとSANをそれぞれ独立に遠隔サイトに展開するという形をとるのが一般的だが、LANとSANを統合したイーサネットファブリックを導入すれば、それをそのまま遠隔サイトに展開するという手法が可能になる。また、遠隔サイトを自社で用意するのではなく、パブリッククラウドサービスを活用するという手も考えられるが、この際にも両者がイーサネットファブリックという形で実装されていれば、その連携は極めてスムーズに行えることになる。Brocadeはこうしたニーズが2〜3年後くらいには具体化すると想定し、技術/製品の整備に取り組んでいる。プライベートクラウド環境を拡張し、パブリッククラウドのリソースとスムーズな連携を図ることを狙い、総合アーキテクチャ「Cloud Plex」のもと、それを実現するさまざまな技術を整備しつつ、それらを有機的に結合していこうとしているところである。

仮想化インフラとの連携

仮想化とファブリックの連携に関しては、VMwareと連動してvCenterからデータを取得し、イーサネットファブリック側の設定に自動的に反映できる機能を提供している。

サーバー仮想化環境におけるネットワーク仮想化の課題として、少し前まで物理サーバーを自在に移動する仮想マシン(以下VM)と、それに紐付くVLAN設定など、ポートプロファイルの対応をどう維持していくかという問題があったが、Brocadeではすでに2011年の製品で実装済みとなっている。具体的には、ポートプロファイルを一度ネットワーク側に設定すれば、あとはサーバー管理者がVMをどこに移動しても、このポートプロファイルがサーバーに同期して移動する。ただし、2011年の実装では、最初にポートプロファイルをネットワーク側に作るために、サーバー管理者からVMの情報やvSwitchの情報を教えてもらう必要があり、この段階でネットワーク管理者とサーバー管理者の“人間の連携”が必要となる。一方、新しいVMwareとの連携機能では、対象となる仮想化環境がVMwareに限定されるものの、vCenterから必要な情報を取得することができるため、人間の連携なしに初期設定が行え、オペレーションフリーネットワークにより近付くことになる。人間系の連携が最初に必要になるものの、Hyper-VでもXenServerでも適用可能という柔軟性をとるか、VMware限定だがより高度な連携を実現するか、ユーザーの環境や必要に応じて使い分けることができる。

さらに、競合との関係で言えば、同様にSANとLANを統合した“イーサネットファブリック”に取り組む強力な存在としてCISCOが存在するが、Brocadeではその取り組みの違いを「オープンの度合い」だとしている。

Brocadeは、サーバー、ストレージ、ハイパーバイザー、OSといったコンポーネントに対してオープンなスタンスをとる。これのコンポーネントは、ちょうどCISCO/EMCが展開するvBlockのハードウェアコンポーネントに相当する。vBlockではCISCO UCSというサーバーにEMCのストレージ、CISCO Nexusシリーズの組み合わせからなるプラットフォームに、VMwareのソフトウェア環境が載る。vBlockは“UCS+Nexus”という環境だからこそこれがイーサネットファブリックとして機能するのであり、これを他のベンダーのシステムに置き換えることはできない。つまり、サーバーの選択肢としてUCS以外にはあり得ず、他社製ブレードサーバーをUCSの代わりに採用することはできない。しかし、Brocadeはこれまでのサーバーベンダー各社との協業の歴史を踏まえ、通常のサーバーでの連携はもちろん、各社のブレードサーバーの内部スイッチに、同社の技術を提供していくことに取り組んでいるという。これが実現すれば、各社のブレードサーバーの内部にはあらかじめBrocadeのファブリックスイッチが実装済みという状態になり、イーサネットファブリックの導入がいっそう容易になるだろう。

ファブリック時代に向かうネットワークインフラ Part2 Network Introduction

仮想化データセンターのハードウェア基盤
データセンター完全ガイド 2012年春号(2012年3月31日発行)掲載
文:渡邉利和

仮想化の普及は、ネットワークの進化に意外なほど大きなインパクトを与えることになった。稼働中の仮想サーバーを別の物理サーバーに移動させる“ライブマイグレーション”の実用化に伴い、L2ネットワークの範囲内に多数の物理サーバーを集約する必要が生じたためだ。今、仮想化に対応した新時代のネットワークインフラの確立が急がれる状況となっている。

イーサネットファブリックの現実化

LAN規格の主流となったイーサネットは、時代を経るごとに回線速度の高速化が行われたのはもちろん、運用管理に関してはより上位レイヤへとシフトしていく傾向が顕著に見られた。ごくシンプルな“信号線”のアナロジーで成立しているL2イーサネットでは、回線の多重化による帯域拡大などは基本的に想定されていないし、当然ながらそうした機能を組み込む場合に必要となる、制御機能なども十分に組み込まれてはいない。それゆえ、LANインフラを高効率で運用するためには、L3のレイヤでネットワークを分割することでL2レイヤを丸ごと多重化し、複数のL3ネットワークを並列的に稼働させるという手法をとっていた。

一方、L3でのネットワーク分割は、(=論理的なトポロジを変更する)と、その変更は個々のノードが利用可能なネットワークアドレスを強制的に変更するため、変更前のIPアドレスをそのまま使い続けることができなくなる。この点はIPv6に移行することで解消される話でもあるのだが、現状のIPv4を前提とする限り、ノードに付与されるIPアドレスは、L3ネットワークの境界を越えることはできず、異なるL3ネットワークに仮想サーバーを移動させる場合には、IPアドレス自体を付け替えざるを得ないのである。

VMwareがまずvMotionとして実用化し、その後“ライブマイグレーション”として一般化した機能では、ある物理サーバー上で稼働中の仮想サーバーを、そのまま別の物理サーバー上に移動させることが可能だ。このとき、“そのまま”という点がポイントで、移動の前後でIPアドレスが変わってしまうようでは困る。そのため、ライブマイグレーションを活用する仮想化環境では、仮想サーバーを相互に移動させる可能性のある物理サーバー群は、すべて同一のL2ネットワークに所属させておく必要が生じる。L3レイヤでの運用管理性の向上に注力し、より高い抽象度で効率向上を実現しようとしてきたネットワークインフラの進化の方向は、仮想化インフラの普及によって突如としてL2時代に逆戻りを余儀なくされ、これまでは否定する方向だった「L2によるフラットな巨大ネットワーク」を実現する方策を考えざるを得なくなったのである。

最初に問題になったのは、L2ネットワークでは回線帯域の多重化に制限が多く、パフォーマンスを上げにくい点だ。イーサネットのレベルでは、ループ経路の存在は禁止されているので、帯域幅の拡大や冗長性の確保を目的に、同一ノードに到達する経路を複数確保しておくことはできない。しかし、この状態では耐障害性がまったくないことになるので、物理的にはループを構成する冗長経路を確保しておくが、論理的には経路を遮断しておき、本来の経路に障害が発生した場合に限って代替経路の遮断処理を解除するという方法で、利用する手法が普及した。ループ経路の検出と遮断/接続処理を行うのがスパニング・ツリー・プロトコル(STP)だ。STPは、本来ループ構成が禁止されているイーサネットに冗長性をもたらす一方、回線を多重化しても端から無効化してしまい、帯域幅拡大には一切寄与しないという怨嗟の対象となっている。

仮想化インフラが要請するL2フラットネットワークを巨大化させていこうとすると、当然ながらその内部帯域の拡大が深刻な問題として浮上してくる。プロセッサの性能向上/コア数増大に伴って1台の物理サーバーに統合される仮想サーバー数は増大する一方であり、それに伴って1台の物理サーバーが必要とするネットワーク帯域幅も拡大する一方だからだ。こうした状態で浮上してきたのが、L2フラットなネットワークで十分な回線帯域を確保し、かつ運用管理の負担が低く柔軟なインフラとして再生させたい、というニーズだ。「イーサネットファブリック」というコンセプトは、こうした背景から生まれたものと考えてよいだろう。

ネットワークの仮想化

ネットワークの仮想化という点に関しては、イーサネットとTCP/IPの組み合わせは当初から物理ハードウェアへの依存性を極力減らすデザインをとっていたため、基本的な相性は悪くはなかった。アドレッシングが物理インターフェイスに付与された固定的なハードウェアアドレスに基づいて行われるという問題は、イーサネットのレベルで使用されるハードウェアアドレスであるMACアドレスと、TCP/IPのレイヤで使われる論理アドレスであるIPアドレスが分離され、ダイナミックに関連付けが行われる(ARP:Address Resoltion Protocol)という仕組みが導入されていたのである。サーバー仮想化普及のはるか以前に導入されたこの手法により、少なくとも特定のIPアドレスを付与された仮想サーバーが、異なるハードウェアアドレスを持つ別の物理サーバー上に移動することに伴う、動的なマッピングが問題となることはなかった。

ネットワークを仮想化するうえでまず問題になったのは、ネットワークのポリシー設定がサーバーではなく、ネットワーク機器の側で実装された点だ。たとえば、セキュリティを目的としたトラフィックのフィルタリングやQoSのための帯域制御は、サーバー上でも実装可能ではあるが、主にルーターやスイッチのポート単位で適用されるのが一般的だった。ネットワーク機器のポートはサーバー側のNICとケーブルを介して直接接続された極めて物理的な存在であり、仮想化との相性はよくなかった。ライブマイグレーションによってあるポートを利用していた仮想サーバーが、別の物理サーバー(=別のポート)に移動しても、そのポートに対して設定されたポリシーは自動的に追従することはなく、そのまま置き去りになってしまう。物理サーバーの制御を握っている仮想化ソフトウェアは、ネットワークデバイスのポート設定には手出しができないため、この間の不整合が面倒な問題として残る形になった。

解決には、専用のAPIを用意する形でネットワーク機器と仮想化ソフトウェアの連携を深め、ある仮想サーバーが他のポートに移動したことをネットワーク機器に通知して、適切な設定変更を促すというアプローチも考えられる。一方、現在実装が進んでいるのは、フラットなL2ネットワークを前提に、ポリシー設定を外部のネットワーク機器から仮想化インフラの内部に構築された仮想スイッチに移動し、仮想化ソフトウェアがすべてを制御するという、ソフトウェア的なアプローチだ。

まったく別の手法として、ポート単位でのポリシー設定というやりかたそのものを見直す、という考え方も当然あるだろう。現在精力的な進化を続けているイーサネットファブリックを実現する新世代のネットワーク機器では、単純なポート単位の設定ではなく、ポートに接続されているエンドポイントを認識した設定ができるように配慮されているものが出てきているため、個別のトポロジに引きずられない抽象度の高い設定が可能になっている(図1)。

図1 Brocade VDXスイッチによるイーサネットファブリック

図1 Brocade VDXスイッチによるイーサネットファブリック
1つあるいは複数のスイッチを介し、ネットワークノードが相互に接続されたネットワークトポロジを構成する。
(出典:ブロケードコミュニケーションシステムズ)

このほか、新世代のネットワーク規格として注目されつつあるOpenFlowでは、ネットワークのポリシー設定を通信に携わるエンドポイント群と通信のセットとして定義される「フロー」を対象としてポリシー設定などが可能なように設計されている。OpenFlowについてはまだ実証実験段階の新しい規格ということもあり、大規模な仮想化環境との組み合わせ事例が紹介されるまでにはまだ時間がかかりそうなのだが、本来的には仮想化環境との相性はよいはずなので、イーサネットファブリックに並ぶ代替案として注目を集める可能性もあるだろう。

サーバーとネットワークの役割の変化

かつては、サーバー(コンピュータ)こそがコンピューティングの中核的な存在であり、ネットワークはコンピュータ間を接続する通信経路に過ぎなかった。コンピュータと切り離されたネットワークを想定する意味はなく、コンピュータハードウェアと密接に結びついていることに、何の不都合もなかった。しかし、サーバーのコモディティ化が進行して論理プロセッサとして矮小化される現状では、個々のサーバーよりもむしろデータの移動経路であるネットワークの方が、“場”としての重要度をより高めていく形になっている。Ciscoが発表したUCSは、こうした主客逆転の典型例であり、コンピュータに接続するための通信路としてのネットワークではなく、ネットワークファブリックに接続するための演算モジュールとしてサーバーを再定義し、ハードウェアレベルで再設計した結果である(図2)。Ciscoに続いてこうしたドラスティックな見直しに着手するハードウェアベンダーは現状出現してはいないが、イーサネットファブリックに関しては複数ベンダーが競合する状況になっており、業界としての大きなトレンドになりつつある。場としてのネットワークの重要性が低下することは当面ないだろうし、今後のITインフラを考えるうえでの最優先テーマとして、ネットワークが再び浮上してくることになるだろう。

図2 Cisco Unified Computing System(出典:Cisco)

図2 Cisco Unified Computing System(出典:Cisco)

ミッションクリティカルシステムの経験を活かして仮想化に応用する Part1-2 Storage

仮想化データセンターのハードウェア基盤
データセンター完全ガイド 2012年春号(2012年3月31日発行)掲載
文:渡邉利和

富士通

富士通は、国内の金融機関などのミッションクリティカルシステムを多数構築した経験から、ストレージ基盤についても独自の高度な仕様を定め、実装に取り組んでいる。新世代に刷新されつつある同社のストレージ「ETERNUS」でも、大規模化する仮想化環境を支える、ストレージ基盤に望まれる多彩な機能が盛り込まれている。

ストレージに求められる要件

サーバー仮想化技術の活用の場が、テスト/開発環境から比較的軽負荷な情報系システムなどを経て、ついに大規模システムやミッションクリティカルな基幹業務の領域にまで到達しつつある。同社のストレージソリューションであるETERNUSでは、仮想環境で運用されるストレージ基盤としても、充実した機能が整備されているが、こうした仮想化ソリューションの要件として、「運用性」「拡張性」「信頼性」「親和性」の4点を挙げる。

運用性とは、大量のインフラ・リソースを容易に運用できる能力を指す。拡張性は、規模や性能を柔軟に拡張できること。信頼性は、ハードウェアとしての信頼性・保守性に加え、セキュリティへの対応も含む概念となっている。最後に、親和性とは仮想化基盤(ハイパーバイザー)や運用管理ミドルウェアとの連携のことだ。そして、これらの基本的な要件を満たしたうえで、さらに「サービスレベルを考慮したインテグレーション能力」を重視する点が、高度なシステムインテグレーションを多数実施してきた、同社ならでは見識というべきところだろう。

ストレージの仮想化と運用性の向上

運用性に関する機能は、主としてストレージ側での仮想化機能に関するもので、ETERNUS単独で実装されるものが中心となっている。

シンプロビジョニング

まず、かつてストレージ管理者の最大の悩みであった“柔軟なボリューム割り当ての実現”という点に関しては、容量の仮想化によって対応している。中核となるのは、シンプロビジョニング機能だ。アプリケーションごとに将来の必要容量を予測して、あらかじめ論理ボリュームとして割り当てておく。一方、実際の物理ディスク容量は現在必要な分だけを搭載しておき、使用容量の増大に合わせて物理ディスクを追加していくことで、初期投資を抑制する。また、容量増設時のサーバーやアプリケーションの設定変更を回避することで、運用管理負担の軽減も実現する。

自動階層化

自動階層制御による性能チューニングの自動化は、ETERNUSでは「ETERNUS SF Storage Cruser」の機能として実装/提供される。最高速のSSD、高速HDDによるオンラインディスク、大容量で安価なHDDによるニアラインディスクという、3階層にデータをアクセス頻度に応じて自動的に最適配置するため、運用管理者が性能チューニングのための管理工数をさかずに済む(図1)。

図1 自動階層制御による性能チューニングの自動化(出典:富士通)
図1 自動階層制御による性能チューニングの自動化(出典:富士通)

QoSによるパフォーマンス保証

さらに、QoSによるパフォーマンス保証も同時に実装されている点は、ETERNUSのユニークなポイントといえるだろう(図2)。ストレージのI/O処理は「来たものから順次処理する」といったアプローチが一般的なので、業務としての優先度は低いが大量のストレージI/Oを発生させるアプリケーションと、優先度は高いがストレージI/Oはさほど多くないアプリケーションがあった場合、結果的に前者が優先され、後者の処理が遅延してしまう可能性がある。ETERNUSのQoS機能では、あらかじめ後者の優先度を高く設定しておけば、前者のストレージアクセスが増大した場合でも、後者のパフォーマンスを劣化させることはない。

図2 QoSによるパフォーマンス保証(出典:富士通)
図2 QoSによるパフォーマンス保証(出典:富士通)

高速コピー機能

ストレージ単体で実行可能な多彩な高速コピー機能は、負荷のオフロードに有益だ(図3)。標準となる高速Disk to Diskコピー機能となるOPCでは、任意のタイミングで、データの全面コピーが作成できる。QuickOPCでは、一度データの全面コピーを作成したら、以後は更新部分のみをコピーしていくことで、最新コピーを低負荷で維持できる。SnapOPC+は、基準となる原本に対する更新部分だけをコピーしていくもので、複数世代のバックアップを小容量で保存する場合などに対応できる。最後に、EC/RECはデータを全面コピーし、独立した別ボリュームとして切り離すことができるというもの。なかでもSnapOPC+は最大256世代を保存できる複数世代スナップショット機能としての運用が可能だ。サーバー仮想環境におけるデータコピーは、システム構成上多数のサーバーが単一のストレージに対してバラバラとリクエストを投げる傾向にある。そのため、サーバー毎に個別にリクエストを処理していると非効率になってしまうが、ストレージ側で処理すると極めて効率よく処理できることが多い。サーバーとストレージを接続するデータパスが貴重なリソースとなりつつあるという事情もあって、仮想化時代にはストレージ内部でのコピー技術をうまく活用することが重要になっている。

図3 多彩な高速コピー機能(出典:富士通)
図3 多彩な高速コピー機能(出典:富士通)

なお、運用のソフト面に関しては、エントリ、ミッドレンジ、ハイエンド全モデルラインアップで共通の管理ツールが使われている点も、運用性を向上させる大きな要因となっている。これは、同社のストレージがすべて自社開発で、規模の差はあっても機能面ではほぼ同一になっているからだ。同社の場合は、運用管理面でも一度習得したノウハウがモデルを問わず活用できるというシンプルさがあり、運用管理効率の向上にも寄与している。

スモールスタートから
基幹システムまでの拡張性

拡張性に関しては、当初必要な規模からスタートすることで初期投資を抑制する一方、事業の成長に合わせたペースで規模を拡大していけることが望まれる。ETERNUS DX400 S2 Sereisでは、最小構成ではドライブ2台、ホストポート×4ポートから、最大構成ではDE(ドライブエンクロージャ)×40台まで拡大でき、ホストの接続数は最大1024台に達する(図4)。

図4 スモールスタートからスケールアップ(出典:富士通)
図4 スモールスタートからスケールアップ(出典:富士通)

より大規模な構成に対応するDX8700 S2では、コントローラーは2台から8台まで柔軟に構成でき、コンポーネントはデータセンターなどに既設の標準19インチラックに収容可能なラックマウントモデルとして提供されるため、省スペースで高密度な実装が可能だ。ディスクドライブには2.5インチドライブを採用していることも、高密度化に寄与している。この結果、標準19インチラックに8DE(192ドライブ)を搭載可能となっており、同社製従来機比では設置スペースが53%削減できたという。

なお、I/O性能の拡張に際しては、業務を止めることなくコントローラーエンクロージャ内にコントローラーユニットを増設することができる。ディスク容量/I/O性能の両面で柔軟な拡張性が確保されている。

基幹システムに耐えうる信頼性確保

ミッションクリティカルシステムに豊富な経験を有する富士通の、面目躍如たるものが、この信頼性への取り組みである。ここでは、ハードウェアレベルでの耐障害性の向上はもちろん、データの整合性の保証など、さまざまなレベルでの信頼性向上策が盛り込まれている。

信頼性対策

最も基本的な信頼性対策は、コンポーネントの冗長化だ。特にストレージの場合、障害発生確率が比較的高いHDDを利用するため、RAIDを併用することが基本となっている。ETERNUSでも当然RAID構成が基本になっているが、RAIDでも構成ドライブが故障した場合は、以後の耐障害性は低下し、故障ドライブを交換してデータを復元するまでの間にさらに障害が発生した場合には、リスクが高まってしまうという問題もある。この問題に対処するために、ETERNUSではディスク故障の予兆監視を行い、近く故障することが予想されるディスクに関しては、あらかじめホットスペアディスクに当該ディスクのデータを復元して、故障によるディスク切り離し前にRAIDとしての正常化処理を終わらせてしまうことができる(図5)。故障が発生するのを待ってデータ復元処理を行うと時間がかかるうえ、RAIDを構成する他のディスクに対しても大量アクセスを発生するといった弊害も生じるが、故障前の交換であれば、システムに与える負荷は最小限ですみ、システムの冗長性低下をほぼゼロに短縮できる。また、コントローラー、電源、ドライブエンクロージャといった主要コンポーネントはすべて冗長化構成となっており、故障発生時には瞬時に他系統に処理が引き継がれる。当然活性保守、活性増設に対応しているため、メンテナンスのための業務停止もほぼ不要となっている。

図5 冗長化により業務継続を保証(出典:富士通)
図5 冗長化により業務継続を保証(出典:富士通)

データ・ブロックガード

ETERNUSでは、データの整合性をストレージ側で保証するための独自機構も組み込まれている(図6)。「データ・ブロックガード」と呼ばれる機能で、SCSIドライブの機能を活用し、一般的には512バイトのセクタサイズを520バイトに変更し、セクタ当たり8バイトのチェックコードを追加で確保している。データ書き込み時にコントローラーでチェックコードを付加し、データの読み出し時にチェックコードとデータを照合して整合性を確認する。そう頻繁に発生することではないが、記録中の磁気反転などによって書き込んだ通りのデータが読み出せなくなるようなトラブルも確実に検知することができる。ここまでの信頼性を必要とする用途は限られているが、絶対にミスが許されない領域で運用されるミッションクリティカルシステムのユーザーにとっては、こうした機能の存在が機種選定の重要な判断材料になることもあるだろう。

図6 全データの正常性を保証(出典:富士通)
図6 全データの正常性を保証(出典:富士通)

リモートバックアップ

さらに、サイト全体にダメージが及ぶような災害発生などを想定した場合の信頼性確保策としては、リモートバックアップなどの手法を検討することになる。ETERNUSでは、ETERNUS SF AdvancedCopy Managerを併用することで、サーバーに処理負荷をかけないストレージ間のデータレプリケーションが可能だ。iSCSIのサポートにより、特別な機器を必要としない比較的手軽なリモートコピー環境を構築することもできる。

遠隔地でのリモートコピーに関しては、高速なWAN回線の確保が難しく、通信コストがシステムコストを押し上げる主要因になっている。そこでETERNUSではDisk Buffered REC(Remote Equivalent Copy)と呼ばれる筐体内の大容量バッファを活用したコピー手法を実装している(図7)。狭帯域回線では、更新データ量が回線帯域を上回ってしまい、更新データの送信が間に合わなくなることがあり得る。この場合、一時的に更新データをバッファリングし、順次送出していくわけだが、一般的な手法ではこの際の更新データは最終的な結果は保証されるものの、途中の更新順序まで維持することは難しかった。Disk Buffered RECでは、安価な狭帯域回線でも、データの更新順序を完全に保存したリモートコピーが可能なため、高い信頼性を確保できる。

図7 狭帯域回線でのリモートコピー(出典:富士通)
図7 狭帯域回線でのリモートコピー(出典:富士通)

また、バックアップサイトの準備に当たっては、遠隔地のバックアップサイトまで出向いて設定を行う工数が無視できないという問題もあるが、ETERNUSでは「ServerView Resource Orchestrator」との連携によって、あらかじめ搬入/結線されたETERNUSストレージに対して、運用サイト側からボリュームを自動構成することができる。こうした人的負担の軽減のための工夫も、現場のリアルな運用性向上のためには不可欠な部分だと評価できる。

暗号化

機械的な障害のみならず、ETERNUSではセキュリティ面での配慮もさまざまなレベルで組み込まれている。まず、ストレージ内蔵のデータ暗号化機能では、ストレージ筐体内でデータの暗号化/復号を行うため、ユーザーやアプリケーションからは完全に透過的なデータ保護が実現でき、ディスク交換の際のドライブ持ち出しが情報漏洩に繋がることを防止できる。また、RBAC(Role Based Access Control)が実装されており、ユーザーの役割に応じたきめ細かな利用可能機能の設定が行えるため、不要な権限をむやみに割り当ててしまうようなことは避けられる。さらに、運用管理に使用する端末とETERNUSストレージの間の通信は、SSL/HTTPSによって保護される。装置個別にサーバー証明書/SSHサーバー鍵を使用できるので、なりすまし防止策も万全といえる。LAN内部での運用管理であればこれほどの体制は不要だともいえるかもしれないが、今後仮想化環境からさらに大規模なクラウドへの進化を想定した場合には、運用管理の場面でのセキュリティ確保が、深刻な問題になることが予想される。ETERNUSの取り組みはその観点からも評価できるものだろう。

仮想環境との親和性

ここまでに紹介したETERNUSの機能は、特定の仮想化プラットフォームを前提としない、ストレージだけで独立した機能といえるものだ。しかし、サーバー側の運用管理体系が急速に仮想化プラットフォームを前提としたものに変化しつつある現在、ストレージ管理もそこにシームレスに組み込むことが重要になってくる。少なくとも、仮想化プラットフォームとは完全に独立した運用管理を必要とするようでは、「仮想化データセンターのハードウェア基盤」とはいいがたいだろう。

オフロード機能

ETERNUSでは、VMware vSphereのVAAI(vStorage APIs for Array Integration)をサポートしており、従来は負荷の大きかったデータコピーのオフロードや、シンプロビジョニングの際の領域解放処理、メタデータ領域のきめ細かなロック処理によるパフォーマンス低下回避といった機能を実現している(図8)。富士通は、VMwareと密接な協力関係を構築しているストレージベンダーの1社であり、この結果、VMwareがストレージ関連で実装する新機能などを、ワールドワイドでもいち早く製品化/実装することができるわけだ。VAAIに加え、ストレージの詳細プロファイルをVMware vCenterに通知するためのVASA(VMware API for Storage Awareness)もいち早くサポートしているのは、こうした協力関係の反映だ。個々の機能/実装レベルにとどまらず、企業レベルでの密接な協業関係が存在することは、両社製品の親和性/相互運用性をさらに高めていくことに繋がり、ユーザーにとっても安心材料となる。

図8 仮想サーバーとの機能統合(出典:富士通)
図8 仮想サーバーとの機能統合(出典:富士通)

仮想環境のバックアップ

このほか、ゲストOSが停止していることが条件になるが、ETERNUS SF AdvancedCopy Manager(ACM)のCopy Control Module(CCM)を利用することで、VMware環境のバックアップ/リストアを短時間で完了できる(図9)。これは、VMFSをDisk to Diskで一括コピーする機能で、環境全体のフルバックアップとして利用できるだろう。

図9 VMware環境のバックアップ/リストア(出典:富士通)
図9 VMware環境のバックアップ/リストア(出典:富士通)

なお、ETERNUSはVMware専用ということではなく、マルチベンダー環境に対応しており、Microsoftの仮想化プラットフォームであるHyper-Vのオンライアンバックアップにも対応している。Hyper-Vサーバーに実装されたVSSライタ(Hyper-V VSS Writer)とETERNUS VSS Hardware Provider、ETERNUS SF AdvancedCopy Managerに実装されたVSSリクエスタが連携することで、Hyper-VのゲストOSのオンラインバックアップが可能になり、仮想サーバーを停止させる必要がなくなる。こうした、仮想化プラットフォームを問わない連携が実現している点も、オープン環境で利用されるストレージとしては重要なポイントだろう。