仮想化が変えるサーバ。デルのメモリ容量拡張技術「FlexMem Bridge」はダミープラグ方式(修正)

2010年4月8日

最新のサーバでは、できるだけ多くのメモリを搭載することが1つのポイントになってきています。シスコのUCSサーバでは、独自のASICを開発して1台のサーバに最大384GBのメモリを搭載可能にしたことが特徴でした。また、IBMも先月発表した最新のサーバでは独自のメモリー拡張技術「MAX5」を採用し、最大3TBのメモリ搭載を可能にしました

そしてデルが4月1日に発表したサーバも、デル独自の大容量メモリ搭載技術「FlexMem Bridge」を採用しています。

デルは標準技術を採用することにこだわりをもってきたベンダでした。それでも同社が独自技術を用いてメモリ容量を拡張してきたことは、現在のサーバでいかにメモリ容量が重視されているかを示しています。

FlexMem Bridge:2ソケットなのに4ソケット分のメモリを利用可能に

デルのFlexMem Bridgeによるメモリ容量拡張の仕組みをみてみると、独自技術とはいえ実にデルらしい仕組みになっています。紹介しましょう。

今回発表されたデルのFlexMem Bridgeに対応したサーバは、CPUにインテルのサーバ向け最新CPUであるXeon 7500番台のプロセッサ(コード名:Nehalem-EX)を搭載しています。

Xeon 7500番台は1CPUあたりの最大メモリ容量が256GB。つまり、マルチプロセッサ構成にすれば2CPUで512GB、4CPUでは1TBが最大メモリ容量です。インテルのIntel 7500チップセットでは最大8ソケットにCPUを搭載できるため、この場合は最大で2TBのメモリ容量となります。

FlexMem Bridgeに対応したサーバ「Dell PowerEdge M910」「Dell PowerEdge R810」は最大で4台のXeon 7500番台プロセッサを搭載可能ですが、これらは2Uという筐体サイズおよびブレードの関係上、1CPUあたりのDIMMスロット数が半分の4つになっています。1CPUあたり128GB、2CPUで256GB、最大の4CPUを搭載した場合で512GBが最大搭載メモリとされています。

FlexMem Bridgeは、この4CPU時の最大メモリ容量を2CPUでも利用可能にする技術です。以下の図のように、4つのソケットに2つのCPUしか搭載されていない場合、空いた2つのソケットにはダミープラグともいうべきFlexMem Bridgeモジュールを差し込んでおきます。これで2CPUで512GBのメモリが利用可能になります。

M910/R810では1CPUあたりのDIMMスロットが半分になった結果、通常はメモリコントローラが2つあるところ、1つしか使っていません。この空いているメモリコントローラを活かして、ペアになっているCPUソケットのメモリコントローラへパススルーするのが、FlexMem Bridgeの仕組みです。

fig

デルのFlexMem Bridgeは、インテルの標準チップセットには一切手を加えない拡張方法を選択した、標準技術を採用することにこだわり続けたデルらしい拡張方法といえるでしょう。

(追記4/9:初出時にはFlexMem Bridgeの仕組みと効果の説明が間違っていました。すいませんでした。上記は修正済みです)

メモリとI/O性能がボトルネックに、そして信頼性も

デルがFlexMem Bridgeを開発した理由は、シスコやIBMが独自のメモリ拡張技術を開発した理由とまったく同じです。それは1台のサーバで多くの仮想マシンが動作するようになった結果、メモリ容量とI/O性能の方が、CPU性能よりもサーバ全体の性能の上限を決めるボトルネックになりやすくなったためです。

まだCPU性能には余裕があるのに、メモリ不足で仮想マシンが増やせない。あるいは多数の仮想マシンを動作させた結果、ディスクI/OやネットワークI/Oがボトルネックになってアプリケーションの性能が向上しない、という現象が仮想化によって以前より容易に引き起こされることになりました。

各サーバベンダはこうした問題を、独自技術を用いて解決すべく取り組んでいます。いまはメモリ拡張の段階ですが、おそらく次は高速なI/O技術へと進んでいくでしょう(シスコはすでに製品を発表しています)。

そしてもう1つ仮想化によって引き起こされている事態があります。それは可用性に対する懸念です。性能が向上したサーバと仮想化のおかげで、より多くのアプリケーションが1台のサーバに集約できるようになりました。すると、万が一物理サーバが故障した場合の被害は以前よりも甚大になります。仮想化によって、より信頼性の高いシステムが必要になってきているのです。

これを物理サーバ自身の信頼性を高める方向で実現するのか、それとも仮想化とVMotion(あるいはライブモーション)のような、ソフトウェアと複数のサーバで可用性を向上させる方向で実現するのか、あるいはいままでにないような仕組みを採用するのか、さまざまな選択肢が考えられます。ここでもベンダごとに異なる技術とソリューションが用いられるかもしれません。

このように仮想化はいままでになかったさまざまな課題をサーバに突きつけており、各サーバベンダはそれに合わせて独自かつ急速にサーバを進化させてきています。いままではどのベンダの製品を見ても似ていたサーバがいま、どんどんベンダごとに異なった技術を用いた進化をしようとしているように見えます。

これから2年後、5年後に果たしてサーバがどのような形態になっているのか、いまから非常に楽しみです。

関連記事

あわせて読みたい

コンテナ型仮想化 仮想化 運用・監視




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本