ブログトップ 記事一覧 ログイン 無料ブログ開設

Simple is Beautiful このページをアンテナに追加 RSSフィード Twitter

2005 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 04 | 05 | 07 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 12 |
2014 | 01 | 02 | 03 | 04 | 07 | 08 | 09 | 11 | 12 |
2015 | 01 | 02 | 04 | 05 | 06 | 12 |
2016 | 01 | 11 | 12 |
2017 | 03 | 04 | 05 | 06 |

2010/04/30 (金)

[]Change Block Tracking (CBT)技術概要(2)

こちらのエントリーの続きです。

前回書いたとおり、CBTを有効にすると-ctk.vmdkファイルが仮想ディスクファイル毎に自動的に用意されます。私が確認した環境では、10GBの仮想ディスクファイルに対して640.5KB、40GBの仮想ディスクファイルに対して2560.5KBの仮想ディスクCBTバイナリファイルが作成されました。

[root@ESX_Host VM_Name]# ls -la
total 56629696
drwxr-xr-x 1 root root        2100 Apr 19 14:23 .
drwxr-xr-t 1 root root        1260 Apr 13 17:10 ..
-rw------- 1 root root      655872 Apr 19 14:24 VM_Name_1-ctk.vmdk ←2個目の仮想ディスクファイルのCBTバイナリ
-rw------- 1 root root 10737418240 Apr 19 14:35 VM_Name_1-flat.vmdk ←2個目の仮想ディスクファイルのバイナリ
-rw------- 1 root root         525 Apr 19 14:24 VM_Name_1.vmdk ←2個目の仮想ディスクファイルの構成情報
-rw------- 1 root root     2621952 Apr 19 14:24 VM_Name-ctk.vmdk ←1個目の仮想ディスクファイルのCBTバイナリ
-rw------- 1 root root  4294967296 Apr 19 14:23 VM_Name-f65c90db.vswp ←スワップファイル
-rw------- 1 root root 42949672960 Apr 19 15:29 VM_Name-flat.vmdk ←1個目の仮想ディスクファイルのバイナリ
-rw------- 1 root root        8684 Apr 19 14:36 VM_Name.nvram ←NVRAMファイル
-rw------- 1 root root         547 Apr 19 14:24 VM_Name.vmdk ←1個目の仮想ディスクファイルの構成情報
-rw------- 1 root root         586 Apr 14 04:05 VM_Name.vmsd ←スナップショット管理ファイル
-rwxr-xr-x 1 root root        3092 Apr 19 14:24 VM_Name.vmx ←仮想マシン構成情報
-rw------- 1 root root         270 Apr 14 00:59 VM_Name.vmxf ←仮想マシン構成情報補足XMLファイル
-rw-r--r-- 1 root root     1533010 Apr 16 18:53 vmware-1.log ←旧ログファイル
-rw-r--r-- 1 root root      251899 Apr 19 14:36 vmware.log ←現行ログファイル
[root@ESX_Host VM_Name]#

0.5KBの部分はヘッダ?データだと考えれば、仮想ディスクファイルのサイズが4倍になっているのに対して、CBTバイナリもちょうど4倍になっていますので、CBTバイナリファイルのサイズは仮想ディスクファイルのサイズに比例して決定される様です。ただしこれはブロックサイズ8MBのVMFS3データストアの場合です。10GBは10240MBですから、8MBブロックだと1280個のブロックから構成されていると考えられます。それに対してCBTバイナリファイルは640.5KBですから、1ブロックあたり0.5KB必要にしているということになります。この仮説が正しいのかどうかについては、別のブロックサイズのデータストアで確認すればひと目でわかることなのですが、未確認です(^_^;)。誰か確認したら教えてもらえると嬉しいです*1

通常時の-flat.vmdkに対してだけではなく、スナップショット有効時の-delta.vmdkに対しても作成されます。

-rw------- 1 root root     2621952 Apr 19 15:31 VM_Name-000001-ctk.vmdk ←1個目の仮想ディスクファイルに対する差分CBTバイナリ ※元のCBTバイナリと同サイズ
-rw------- 1 root root    16861184 Apr 19 15:31 VM_Name-000001-delta.vmdk ←1個目の仮想ディスクファイルに対する差分バイナリ
-rw------- 1 root root         385 Apr 19 15:31 VM_Name-000001.vmdk
-rw------- 1 root root      655872 Apr 19 15:31 VM_Name_1-000001-ctk.vmdk ←2個目の仮想ディスクファイルに対する差分CBTバイナリ ※元のCBTバイナリと同サイズ
-rw------- 1 root root    16799744 Apr 19 15:31 VM_Name_1-000001-delta.vmdk ←2個目の仮想ディスクファイルに対する差分バイナリ
-rw------- 1 root root         391 Apr 19 15:31 VM_Name_1-000001.vmdk

ただし、仮想ディスクに対するスナップショットファイル自体は変更差分を蓄積に基づいてサイズが拡張されていくバイナリファイルですが、その差分に対するCBTバイナリファイルのサイズは元の仮想ディスクファイルに対するものと同サイズになります。まぁ当たり前の話ですね。変更されるブロックの管理用なわけですから、差分バイナリデータそのものを管理するスナップショット用のファイルとは性質が異なります。

「前の状態」ではなく「変更された箇所」さえ把握できればよいのであれば、CBTは差分バイナリファイルよりも格段に優れた方式です。しかしファイルシステム上のファイルレベルでこれらの機能を活用していくには限界があります。VMwareはvSphere4.0リリースにおいて、VMFS4は発表しませんでした。ぜひ次の大きな革新として、仮想環境向けのファイルシステムとしてより先進的な機能を搭載してきて欲しいと思います。

*1:ま、そのうち自分でも確かめるつもりですが

2010/04/25 (日)

[]オール電化:電気代010 - 2010/03/19〜2010/04/20 (33日間)

今の家に引っ越して10回目の電気使用量がまとまりましたのでオール電化戸建て住宅/夫婦+子1人世帯の参考情報としてUpしておきます。契約メニューは電化上手、契約容量は10kVA、割引対象機器容量は通電制御型2kVAのIHコンロです。なお、基本料金は2100円です。

Google Chartを利用した図示は5回目。幅が広くなってきて想定幅を超えてしまったので、一部のグラフで線幅を調整しました。

  • 電気代:請求額

まずは電気代から。

電気代、3月に比べて下がらず。逆に3月よりも増えてしまうという結果に。やたら寒い4月だったために暖房を使った日もあったことと、花粉症対策もあって乾燥機を使い続けているので電気代の下がり幅はあまりない模様。まぁ1万円ならいいんじゃないかとは思っていますが。

月別電気代:棒グラフ

  • 電気代:時間帯別内訳

続いて、時間帯別の内訳。

朝晩に暖房を使った日があったことがやはり影響している模様。平日日中は基本的に仕事なので、おそらく昼間の使用量はこのあたりで下げ止まりだと思われます。同様に、夜間についても乾燥機を回すならこの辺りが下げ止まりっぽい感じ。はてさて、どうしたものか。

時間帯別内訳:棒グラフ

  • 電気使用量

最後にkWh単位での電気使用量の推移。

みごとに3月と4月はほぼ同じ電気使用量になっていることが一目でわかるグラフになりました。電気使用量をより削減するのであれば、梅雨明け後はちゃんと洗濯物は干す生活に戻す必要がありそうです。各季節をこの家で過ごしてみて、冬よりも夏が過ごしやすい家である気がしてきているので、ここから先、いかにクーラーを使わない生活にするかが今後の勝負?の分かれ目かもしれません。

時間帯別使用量変移:折れ線グラフ

さて、まだ少し寒いので外には出していませんが、ゴーヤの苗を試験購入。本格的に育てるにはもう少し大きなプランターが必要になりそうですが、色々試行錯誤してみたいと思います。

f:id:takaochan:20100425163201j:image

あ、ちなみに真ん中のでかい苗だけはゴーヤじゃないです、キュウリです(^_^;)。

2010/04/24 (土)

[]電気工事を行いました

まずは24時間タイマースイッチの追加。スケジュール設定に基づいて玄関灯の自動点灯/消灯をさせるのに使用します。

f:id:takaochan:20100424143136j:image

画像下のスイッチ盤は3x2の6個スイッチでしたが、玄関灯のスイッチ機能がタイマーに移動したので、5個スイッチに変更されました。

奥さんが保育園から娘を引き取って帰ってきたときに暗いと大変でしたが、これで帰る前に玄関灯を点けておくことができるようになります。夜も12時前ぐらいにタイマーで消してしまうつもり。朝起きるまで点けておかなくてもいいでしょうし。

タイマー自体に電源が必要なのですが、それは壁の裏側にあった洗濯機用のコンセントを活用することにしました。多少、壁の外を配線が通ってしまうことになりますが、まぁ洗濯機の裏側なのでほとんど気にはなりません。

続いてコンセントの追加。2口コンセントを6口(2口x3)コンセントに交換した箇所が4箇所、新規に6口コンセントを追加した箇所が1箇所。

f:id:takaochan:20100424143221j:image

交換はけっこう簡単。2口x3にするか3口x2にするか少し悩みましたが、見た目よりも使い勝手を重視して2口x3に決定。ちなみに、新規の1箇所は正確には新規というわけではなく、壁の裏側にあるコンセント用にすでに配線されている箇所に口を増設したかたち。ここはキッチンの向かい側の壁面になるのですが、テーブルで今PCを使ったり、携帯電話の充電をしたりと何かとコンセントが必要な状況が多かったので追加することにしました。

その他、2口から6口に増やした箇所については、ネットワーク機器やら電話機やらがごちゃごちゃしている箇所のコンセントも、これでやっと延長タップを使わなくて済むようになりました。

f:id:takaochan:20100424143249j:image

あ、あと最後に、お風呂の換気扇スイッチを普通のスイッチからパイロットスイッチに変更しました。なんで元々がパイロットスイッチではなかったのかという点にかなり疑問が残りはしますが、まぁこれで換気扇が付いているかどうか、お風呂のドアを開けて確認しなくてもよくなりました。

さて、継続的に色々と手をつけたい箇所はあるのですが、お財布の問題もありますし、他の方法で対応できることもありますし、なかなか悩ましいですね。

2010/04/23 (金)

[]時代はメモリ重視へ…。で、eX5(MAX5)ってなーに?

なーに?シリーズ第2弾(^_^;)、DELLのFlexMem Bridgeに続いて、今回はIBM eX5について。ソースはlivestreamで公開されたこちらのIBMセミナー動画「「eX5」で実現するスマートなx86インフラ構築セミナー」*1

f:id:takaochan:20100421092907p:image

eX5はIBMがIAサーバ向けに提供する拡張仕様の5世代目という意味の総称なので、それ自体が具体的な技術仕様を意味しているのではありません。eX5として発表された技術の中身としては、メモリ拡張モジュール"MAX5"、フラッシュ型記憶装置"eXFlash"、ノード連結・分離技術"FlexNode"の3つの技術ですが、このエントリーで取り上げるのはMAX5(Memory Access for eX5)のみに絞ります。

まずはMAX5誕生の背景から。

f:id:takaochan:20100421092905p:image

要はCPUの性能向上に対して、メモリの搭載容量の増加速度は比較的なだらかな増加となっているため、その乖離が次第に大きくなってきていますよね、という点。たしかに、CPUは単純なクロック性能という意味ではそれほど向上はしていないかもしれませんが、コア数の増加や、チップセット機能の統合、バス帯域の拡張、メモリコントロールなど様々な面をトータルに考慮するとかなりの性能向上が継続的に進んでいます。それに対してメモリはゆっくりと主流の単体メモリスロットあたりのサイズが1GB - 2GB - 4GB - 8GB ( - 16GB)と次第に増加はしていますが、比較的ゆっくりな向上となっています。また、CPUにメモリコントローラが統合されているために仕様的にサポートされるメモリスロット数には限界があります*2。単純にCPU性能の向上だけでパフォーマンスが向上するシステムならよいのですが、そもそもマルチコア化されたCPUの性能を最大限に引き出すソフトウェアを開発すること自体がなかなか難しいですし、多くのシステムでは計算を行うこと自体よりもデータを処理することが求められているため、どちらかというとCPUの計算速度よりもメモリ容量を拡張した方が単純に処理性能が向上する場合が多いのではないかと思います。特にシステムを仮想化インフラとして利用する場合はCPUに対してメモリ容量が統合率向上のボトルネックになっている場合がかなりあるのではないでしょうか。

で、この課題に対して各社それぞれの対応が行われ始めた、というのが現在の状況。前回紹介したDELLのFlexMem Bridgeは、2CPUシステムであってもXeon 7500を搭載する4ソケットシャーシを利用して、空きスロットにFlexMem Bridgeを搭載することによって4CPU分のメモリスロットを使えるようにするという技術でしたが、IBMのMAX5はより根本的に、メモリコントローラとメモリスロットを拡張してしまおうというモジュールになっています。

f:id:takaochan:20100421092906p:image

IBMのセミナー資料ではどこにもQPIってなに?という部分についての説明がありませんでした(当たり前なのでしょうか?)が、QPIはIntelが開発したCPU向けインターコネクトの規格"QuickPath Interconnect"の略称。他へのリンクもまとめられているWikipediaの解説はこちら。つまり、IBMはQPIというインターコネクトな仕様を外部モジュールに拡張した、ということになります*3

f:id:takaochan:20100422233924p:image

MAX5はラックマウント型X5対応サーバに対してメモリスロットを32スロット追加、ブレードサーバHX5にメモリスロットを24スロット追加する拡張モジュールですが、ポイントの2番目に挙げられているように、想定する主要ターゲットは仮想インフラであることは明確です。

唯一気になる点は、QPIを基板の範囲を超えてコネクタを通じた外部接続モジュールとして接続している点ですが、この点については「IBM固有のテクノロジーによりメモリー拡張ユニット間も高速接続」と書かれている程度で、その信頼性をどのように担保しているのかなどについては特に説明はありませんでした。eX技術としてこれまでノード間結合を実現してきた実績はありますので問題はないとは思うのですが、CPUとメモリの間の超高速データ通信バスとなりますのでその信頼性をユーザにアピールしていく必要はあるのではないかと思います。

…ということで、FlexMem BridgeにしろMAX5にしろ、メモリの拡張性を強化する仕組みなわけで、CPUの進化に追いつくべく様々な取り組みが行われ始めています。30コア以上のCPU、1TB以上RAMを搭載した2Uサーバももはや夢ではないわけで、いやいやとんでもない時代になったものです。仮想化以外にこれだけの性能を活用できるソリューションははたしてあるのでしょうか?

*1:我が家の回線側の問題なのかもしれませんが、あまりスムーズな再生ではありませんでした

*2:1チャネルに接続するメモリカード数を増やすと帯域が低下するというトレードオフ問題もあります

*3:別に外部モジュール接続用として使ってはいけないわけではありませんが、仕様的には基本的にチップセット上で用いることを主に想定していると思います

2010/04/18 (日)

[]Change Block Tracking(CBT)技術概要

VMwareは1つの技術を色々な用途に応用して使うことが得意です。たとえば、VMotionの技術はDRSにおける仮想マシン配置の自動化のために使われていますし、VMware Converterは単なるP2Vツールではなく、VCBによってエクスポートされた仮想マシン構成ファイルのインポートツールとしても使うことができるように作られています。その他、詳細には様々な技術をけっこう上手く使い回しています。

そんな、VMwareが最近、様々な新機能のベース技術として活用しているものが、CBT (Change Block Tracking)という機能です。

CBTはその名の通りで、仮想マシンが使用している仮想ディスクファイルに対しての更新ブロック情報を仮想化レイヤー側(仮想マシン上のゲストOSは関知しない形で)で抽出する機能です。

この技術はESX4.0以降においてVersion7の仮想マシンハードウェアタイプを選択した場合にのみ使用することができる機能の1つです*1

最近公開されたKB1020128において、CBTを有効にした場合にどのようにフラグが立つのかについて簡単な解説が掲載されています。

  • 構成情報ファイル(.vmx)において ctkEnabled の値が "TRUE" となります
  • 構成情報ファイルにおける仮想ディスク毎のステータスとして scsix:x:.ctkEnabled の値も "TRUE" となります
  • 仮想ディスクファイル群(.vmdkおよびxxxx-flat.vmdkもしくはxxxx-delta.vmdk)にさらにCBTファイル(xxxx-ctk.vmdk)が構成されます

CBTは単純に?更新されたブロックの情報だけを保持していますので、スナップショットファイルなどと違ってどんどんとサイズが肥大化することもありませんし、仮想マシンのパフォーマンスに与える影響も非常に軽微です。

Storage VMotionではこの技術を、Storage VMotion実行中の仮想ディスクの更新追跡のために利用しています。Storage VMotionでは起動中仮想マシンを対象としたクローン実行と同じ要領で仮想ディスクファイルの移動処理を実行していますが、移動処理中にも仮想マシンは起動していますので、仮想ディスクファイルには更新が行われます。Storage VMotionではCBTを使って更新ブロックを追跡し、更新されたブロックの情報をさらに追加的に移動処理を行うことによって仮想マシンを起動したままにしつつも仮想ディスクファイルの移動処理における整合性を確保しているわけです。

VMware Data RecoveryやvStorage APIにおける仮想マシンの差分・増分バックアップについても、このCBTによる更新追跡を利用しています。CBTによって更新ブロックの情報を保持することによって、次回バックアップ時には更新されたブロックだけを対象としてバックアップを行うことができます。システムのイメージバックアップでありながらも差分・増分だけをバックアップするということが実現できるわけです*2。CBTはゲストOSにおけるファイルシステムを意識していないため、Copy on Writeのような仕組みで書き込みを行うファイルシステムとの相性は悪いのでないかと思ったりもしていますが、まだ未確認です。

VMwareの優位性を根幹で支える技術ですので、詳細な仕様については公開されている情報がありませんでしたが、APIレベルとしては、”Designing Backup Solutions for VMware vSphere”というPDF資料が公開されています。

この資料によると、"QueryChangedDiskAreas" APIによってCBTの機能を利用できるようになる様です*3。CBT機能は"changeID"によって変更されたブロックデータを管理しています。CBTはsnapshotが作成された時点から記録が開始されます。

CBTの仕組みは詳細にはわかりませんが、基本的に仮想ディスクファイルに対するI/OはすべてVMMを通じて管理しているわけですから、VMMにおいてゲストOSからの仮想マシンへのディスクI/Oをトラッキングしているものと思われます。良くも悪くもファイルシステムを意識しない作りになっているので、ゲストOS内におけるスワップI/OやOSによる一時ファイル読み書きのI/Oなども含めてすべてのブロックレベルにおける変更をトラッキングしてしまうわけですが、どんなゲストOSが動作していようと使うことができるということでもあります。

ゲストOSのステータスとどう整合性を取るのかという点は大変難しい問題ですが、CBTのような機能は仮想インフラをソフトウェア的に実現しているからこそなわけで、こうしたこれまでの常識を覆すような仕組みが次々と登場してくる点が、仮想化の醍醐味というか、面白さなんじゃないかと思っています。

*1:物理互換RDMの仮想ディスクや、共有ディスクとして構成されているSCSIバスに接続された仮想ディスクでは使用できません

*2:ただし、CBTは変更のあったブロック情報のため、アーカイブビットによる差分・増分ほど正確な差分・増分にはなりません。また、ストレージに一時ファイルを大量に書き込んだり、ファイル更新が多い場合は想定以上の差分・増分バックアップ容量となる可能性があります

*3:CBTを利用したい場合は、まず仮想マシンに対して有効化を行います。CBTの有効化はAPI経由だけではなく、vSphere Clientから詳細パラメータの"ctkEnabled"のフラグを"true"に変えることでも可能です

2010/04/15 (木)

[]書評:『λに歯がない λ HAS NO TEETH』森博嗣/講談社文庫

Gシリーズ第5弾。

λに歯がない λ HAS NO TEETH (講談社文庫)

λに歯がない λ HAS NO TEETH (講談社文庫)

φ(ファイ)、θ(シータ)、τ(タウ)、ε(イプシロン)ときて、今回はλ(ラムダ)。さて、それではおきまりの、これまでの書評の紹介。

森博嗣ウェブサイトの刊行予定表によると、Gシリーズ第6弾「ηなのに夢のよう」の刊行は7月とのことなので、今年のGシリーズ書評は2冊だけの見込み。ま、刊行スケジュールを追いながら読んでいるので仕方がないか。4-5月は刊行予定の作品もないようなので、うーん、やはり次第に減っていくなぁ。

完全に施錠されていたT研究所で、四人の銃殺死体が発見された。いずれも近距離から撃たれており、全員のポケットに「λに歯がない」と書かれたカードが入っていた。また四人とも、死後、強制的に歯を抜かれていた。謎だらけの事件に迫る過程で、西之園萌絵は欠け落ちていた過去の大切な記憶を取り戻す。

本筋の密室殺人事件はもはや味付け程度?の扱いで、S&Mシリーズとは別シリーズ扱いながら本シリーズは登場人物たちの内面深淵に迫る作品になりつつある気もする。本作だけを読んでいても登場人物たちのバックエンドやつながりがわかりづらい部分もあるので、シリーズとして読むべきパーツ作品でしょうか。とまで書いてしまうと、書きすぎかな。

人気があるシリーズですが、単純なミステリーではなく、登場人物たちの掛け合いや、ストーリーの絡み合い・伏線の挿入などを楽しむ視点で読むと、より面白いのではないかと思います。

2010/04/08 (木)

[]書評:『オー!ファーザー a family』伊坂幸太郎/新潮社

2006-2007にかけて新聞連載された小説を加筆修正した作品。

オー!ファーザー

オー!ファーザー

作品の順番としては3年前のものなので、ちょっと前のもの。新聞連載された作品ということで?章割りはなく、話の展開は大きく盛り上がったり急激な展開が訪れたりするわけではないのだけれども、緻密に構成された流れはさすが。そのタイトルの通り、父親「たち」が大活躍するのだけれども、父親たちに翻弄されつつどこか冷めた対応をしてしまう主人公と、彼を取り巻く街の世界観がまるで舞台作品のようにコンパクトにまとまっていていい感じ。バラバラに展開していたストーリーが次第に絡み合っていくのだが、その本筋のストーリー展開はさておき、人間関係のやりとりが軽妙でストーリーをより面白いものにしているところが伊坂幸太郎の真骨頂。本作でもその魅力は遺憾なく発揮されています。新刊ですが、ハードカバーではない点もいいですよね。

2010/04/06 (火)

[]社会、経済、育児、教育、すべての答えはここにある?

TBS RADIOで毎週日曜日夜9時に放送されているサイエンス・サイトークで3/28,4/4の2回にわたって放送された『ロケットを作った町工場』がとてもよい。メインはロケットの話ではない、この2回にわたる放送には、日本の社会、経済、育児、教育など様々な面において抱える問題に対する答えがあるような気がする。特に子育て中の方、自分の夢を忘れてしまった方、必聴。Podcastで聴けます。

北海道赤平市にある「植松電機」。親子二人だけの小さな町工場でしたが、現在は約20人の社員で、ロケットや小型人工衛星の製造を手がけています。 その背景には「将来はロケットの設計をしたい」という植松さんの子供の頃からの夢がありました。「どうせ無理」だと考えず、あきらめないで頑張れば夢はかなう、という植松さんは仕事のかたわら、講演や子供向けのロケット教室などで全国を飛び回っています。 2回に渡ってたっぷり話を聞きます。

f:id:takaochan:20100406234145p:image

http://www.tbsradio.jp/xitalk/rss.xml

http://itunes.apple.com/jp/podcast/id200912677

2010/04/05 (月)

[]時代は2U/4Sへ…。で、FlexMem Bridgeってなーに?

DELLがどばっとPowerEdgeの新製品を発売してきました。先日CloudEdge(PowerEdge C Series)は一部紹介しましたが、Intel Xeon 7500番台(4-8Core)搭載モデルとAMD Opteron 6100番台(8-12Core)搭載モデルも発表されています。ついに、2Uサーバで4ソケットモデルが登場する時代になりました。Intel Xeon 5600シリーズの多く*1ではHyper-Threading機能を搭載していますので、有効化するとすると8コアモデル4ソケットで64論理CPUがOSから認識されることになりますし、AMD Opteron 12コア4ソケットだと48コアが認識されることになります。いやはや、とんでもない時代になったものです。これだけのマルチコアはもはやDBでも活用することは難しいと思いますので、やはりこれだけのメニーコア化を有効活用できる唯一の汎用的ソリューションは仮想化ということになるのでしょう。

この一連のニュースは新CPU登場に伴う新モデル発表という部分をメインに据えていますのでおまけ的な紹介に留まっていますが、標準技術を標榜するDELLが珍しく独自技術をアピールする"FlexMem Bridge"なるものを発表してきています。

f:id:takaochan:20100417082353g:image

Ciscoが4枚のメモリを1枚のメモリと見せかける拡張方式、IBMがeX5外部メモリモジュールを用いた拡張方式を採ったのに対して、DELLはNUMAを逆手にとって?CPUがささっていないスロットに紐付いたメモリスロットも活用できる拡張?方式"FlexMem Bridge"を用意してきました。CPUあたり基本的に8スロット3channel,channelあたり3DIMMが紐づけられているIntel Xeonでは、これまでの2ソケットサーバの場合は18スロットしか使えなかった訳ですが、FlexMem Bridgeを使えば2ソケットだけCPUを搭載した状態でも4ソケット分、36スロットまで活用できることになります。最も市場シェアを持つIntel Xeon CPUと標準的なチップセットだけで実現できる手軽な?メモリ拡張技術といえるかもしれません。専用I/O制御チップや外部拡張インターフェイスなどといった独自技術満載のeX5と比較すると「独自技術」といってもかわいいものですが、単純な分、事実上無償提供されるなどより多くのユーザにメリットをもたらすという意味では価値があるものなのではないかと思います。

CPU1ソケットにより多くのコアが搭載される流れがここ暫く続いておりこの流れは当面変わらなさそうです。また、ハードウェア的に実装される仮想化支援機能など多コアを活かす様々な処理性能が向上していっていますので、2ソケットであっても元々4ソケットサーバを必要としていた処理性能は十分発揮できるようになってきています。最近はCPUの性能向上に合わせたメモリ部分の拡張性がキーポイントとして注目されだしていますが、ネットワークの10Gbps化、ストレージとネットワークのFCoEによるインターフェイス統合などと合わせて、3年後のサーバの姿はけっこう大幅に変化しているかもしれません。

(4/17更新:FlexMem紹介画像をDirect2Dellウェブサイトから拝借したものに差し替えました)

*1:すべてではない。詳細はIntelウェブサイト参照のこと。