Windows Server 2012とInfinibandによる高速転送について


Interrop 2012でマイクロソフトがWindows Server 2012 Betaを使ったデモンストレーションを展示しているらしい。
Microsoftのtechnet blogのJose’s Briefings, Diagrams and Annotationsより「Windows Server 2012 Beta with SMB 3.0 – Demo at Interop shows SMB Direct at 5.8 Gbytes/sec over Mellanox ConnectX-3 network adapters

内容は、SMB3.0を使用したネットワーク越しでの高速転送技術について。

SMBサーバ側はFusionIO ioDrive2(単独で1.5Gbytes/sec)を4枚並べてストライプ。
そこに、高速ネットワークを使って別のサーバからアクセスして、どれくらいの速度がでるか、というもの。

上記の様な状態で、IO benchmarkを測定すると、以下の様な感じとなる。

テスト内容 サーバ ローカル 10Gbps Ethernet 32Gbps Infiniband 54Gbps Infiniband
512KB IO/8スレッド/8 outstanding
バンド幅 5808MB/sec 1129MB/sec 3754MB/sec 5792MB/sec
IOPS(512KB/sec IOs/sec 11616 IOPS 2259 IOPS 3754 IOPS 11565 IOPS
CPU負荷 ~6.6% ~9.8% ~3.5% ~4.8%
8KB IO/16スレッド/16 outstanding
バンド幅 5103MB/sec 571MB/sec 2620MB/sec 2683MB/sec
IOPS(512KB/sec IOs/sec 525225 IOPS 73160 IOPS 335446 IOPS 343388 IOPS
CPU負荷 ~90.4% ~21.0%
(転送できてないので暇)
~85.9% ~84.7%

( 検証環境の構築手順: Deploying Windows Server 2012 Beta with SMB Direct (SMB over RDMA) and the Mellanox ConnectX-2/ConnectX-3 using InfiniBand – Step by Step )

ま、単純に10Gbps < 32Gbps < 54Gbpsの差、と見ることもできるけど、 512KB IO時のCPU負荷が10Gbpsより低い、というのは、注目ポイントかもしれない。 なぜ、その様なことが発生するのか? それは、Infinibandを使用するSMB 3.0では、RDMAという技術を利用しているから、である。 RDMAは「Remote Direct Memory Access Protocol」の略で、Infiniband環境下では当たり前のように使用されている技術である。 参考文献1:SMB Advanced Networking for Fault Tolerance and Performance
これの5ページ~10ページに詳細が書かれているが、ようはプロトコルオーバーヘッドが少ないから、ということになるのだが、ちょっとここの説明だと理解しづらい。

参考文献2:SMB 2.2. over RDMA

参考文献2を見ると、SMB over RDMA自体はSMB 2.2からサポートしているらしい。
RDMAがなぜ早いのか?という仕組みの説明としてはこちらの19ページと20ページの図がわかりやすい。
実際のデータ転送部分に関しては、直接サーバ上のメモリを参照してもらう、ということで、高速化を図っている、という感じである。

SMB3.0での改善点は他にもあり、上記の参考文献1の11ページ~18ページでは、「SMB Multichannel」という技術の話がされている。
これは、高速転送時、いままでのSMB実装では、1つの転送に対して使用できるCPU coreは1つしかなかったので、CPU coreが頭打ちになると、それ以上は帯域や他のCPU coreが空いていてもそれ以上は早くならない、という問題がある。(参考文献1 13ページ)
それを複数のCPU coreで処理を担当できるようにする、というのがSMB Multichannel。
SMB Multichannelにより複数NICを使った場合の分散処理もかなり改善される。

(訂正: 参考文献3 SMB 2.2: Bigger, Faster, Scalier (Part 1)を見るとSMB 2.2からあるようだ)

参考文献4 The basics of SMB Multichannel, a feature of Windows Server 2012 and SMB 3.0
という記事があがり、Multichannelとかの機能について解説されている。

ReadyNAS NV+ v2が日本でも発売


なんかReadyNAS NV+2で検索してくる人が多いなぁ、と思ったら、今日、発表されたんですね。
NETGEAR ReadyNAS Duov2 / ReadyNAS NV+v2 製品紹介ページ

詳しいあたりは、アメリカで発表になった時に作成した記事を参照してください→「ReadyNASのCPUがMarvell Kirkwoodに

それにしても、2005年11月末にディスクが4本させるReadyNAS 600を買った時は84000円だったわけですが、ずっと値段が下がって、同じ4本モデルのReadyNAS NV+v2が34800円になっている、というのは、時の流れを感じるなぁ、と言ったところです。

それにしても、プレスリリースを含めて、いままでの製品とCPUアーキテクチャが変更になった、という点に触れていないんですね。
結構、大きな違いだと思うんですが・・・

Tintri VMstore T540


先日紹介した、Tintri VMstore T445。
先日開催されたvForum2011にて実物があったので、いろいろ聞いて見た。

おおむね想定通りだったけど、いくつか記事のアップデートが必要な点があった。

ハードウェア的な構成についての話
・機種が2つ、廉価版で4UのT445と、ヘッド冗長性ありで3UのT540がある。
 (T540のが後に出てきた)

・廉価版 4UのT445のハードウェア
想定通りSUPERMICROの4U SuperChassis 846シリーズだった。
HDDが24スロットで、160GB SSDを9本でRAID6、1TB HDDを15本でRAID6としている。
オンボードNICは1Gbps 1つ+管理用1Gbps 1つと結構貧弱。

・冗長性ありの3U T540のハードウェア
Tintriのページにある背面画像から考えるとSUPERMICROの3U SuperServer 6036ST-6LRあたり。
HDDが16スロットで、300GB SSDを8本でRAID6、3TB HDDを8本でRAID6としている。
オンボードで10Gbps NICが2つついているというのが利点であろう。
その他に管理用として1Gbos NICが2つある。

・消費電力の謎。
ノックスのカタログではT445の消費電力が1200Wで、T540の消費電力が500Wとなっているが、デュアルヘッドなのにほんとか?
と思い、Tintri公式のリソースにてダウンロードできるdatasheetを確認したところ、T445・T540のどちらとも「Typ(標準値)が500W」としか書かれていなかった。
T445の消費電力1200Wというのは、おそらくシャーシの最大消費電力 1200Wから来ていると思われる。
であれば、T540も、シャーシの最大消費電力 1200Wとなるのであろう。
(2011/12/21追記: 上記に記載した、ノックスカタログにおける消費電力の件は500Wに修正されていた)

・T540でのヘッド間ディスク共有方法はStorage Bridge Bayを利用
T540では、ヘッドの冗長性アリ、となっているが、どうやって2つのヘッドを1つのディスク群にアクセスさせているのかを、シャーシ側の資料を確認してみたところ、Storage Bridge Bayという仕組みを利用しているとのこと。
SSBについては、Storage Bridge Bayからの出発 ~SBB規格がもたらすストレージの未来像~という日本語の記事があったので、こちらを見てください。

ストレージとしての動作について
・最終的なデータの置き場所はHDD上
・書き込み/読み込みキャッシュ的な感じでSSDをフル活用する
・エンクロージャの増設等は現状考えられてはいない
 (ただし、T540はハードウェア的には外部SASポートがあるのでできなくはないはず)

・VMware専用のNFSストレージで、他のOS用には考えられていない
 とはいえ、Citrix Xenに関しては対応する可能性がある。

ReadyNASのCPUがMarvell Kirkwoodに


うちにはInfrant社のReadyNAS 600がある。
当時、4ドライブ搭載可能で、しかも、ドライブを大容量のものに交換すると、中のデータを保持したまま、RAIDを再構築してくれる、という製品は、これしかなかった。
しかも、(ドライブ抜きだけど)10万円を切っていた。
その当時のReadyNASは、CPUアーキテクチャにSPARCを採用した独自のものを使っていた。
その後、ReadyNAS X6、ReadyNAS NVになり、そして、InfrantがNETGEARに買収され、
また、CPUアーキテクチャがIntel ATOMベースに変わりReadyNAS NV+が出たりした。

そして、昨日、新製品、ReadyNAS NV+ v2とReadyNAS Duo v2が出た。
プレスリリース: NETGEAR Redefines Home and Small Business Storageと、紹介ページ

なんでも、CPUアーキテクチャがARM系のMarvell Kirkwood 6282 に切り替わったらしい。
それに伴い、NAS OSのRAIDiatorも、ARM版が出てくるんだと思われますが、どれくらい変わるのかはまだ不明。
特に、SPARC→Intelの時は、ディスクの引き継ぎが出来たけど、今度も可能なのかというところが気にかかります。

2ドライブのDuo v2が$199、4ドライブのNV+ v2が$399 と、値段的にはそんなものかな、といったところ。

とはいえ、Marvell Kirkwood 6282といえば、Synology社のNAS DS111/DS211/DS411とかQNAP社のTS-119P+/TS-219P+/TS-419P+ Turbo NASとか、いろいろで採用されているやつです。
競合他社がひしめく中、どれだけの優位性を出せるのかが気になるところです。

なお、QNAP社のMarvellチップ搭載のNASについて、どんなスペックなのか、Debianを移植したDebian on QNAP Turbo NASのページで一覧かされているので紹介しておきます。

IBM Storwize V7000についていろいろ


IBM Storwize V7000についてのドキュメントベースでの適当な考察とかいろいろもろもろ・・・

Storwize V7000とは?

元々のStorwizeは、NASとクライアントの間に入れて、NASに書き込むデータを圧縮してしまおう、というStorwize社のプロダクトでした。(当時、日本では東京エレクトロンが取り扱っていた)
NAS上に書き込まれるのは圧縮されたデータであるため、直接NASにアクセスすると、読めない謎のデータがおいてある、という認識となる。
プロトコルヘッダを見て、圧縮をしているらしく、NetApp/EMC CelerraのCIFS/NFSだと動くのに、
Linux NFSサーバだと、全然圧縮動作をしてくれない、なんて動きをしていました。

そんなプロダクトをIBMが買収したのですが・・・なぜか、旧Storwizeは、IBM Real-time Compression Appliance(RtCA)という名前でリリースし、Storwizeという名前は全然別のプロダクトに持って行かれました。
(ちなみに現行製品はSTN6500、STN6800ですが、この型番、旧Storwize時代のまんまです)

新Storwizeは、IBMが元々リリースしていたStorage Volume Controller(SVC)というストレージ仮想化装置と、ストレージを一体化したものとして、仕切り直した形になっています。
で、SVCというのは、IBM x3550にLinuxを入れてLinux版のDatacore SANsymphonyのOEM版を動かしている、という感じのプロダクトです。

で、現行製品のStorwize V7000というのは・・・

ハードウェア的には2U筐体にストレージエンクロージャとサーバを突っ込んだもの
ソフトウェア的にはSVC同等機能+XIV的な管理GUI

ちゃんとしたあたりは、IBMのサイトに転がっているマニュアルやRedBookを参照してください。

それらの資料と実際の動作を見た結果、明示されていないけど、なんとなく、こうなのかな?と想定されるところを以下に書いてみました。
なので、以下に書かれていることは、IBMの公式見解ではなく、あくまで個人的な感想です。

内蔵ディスク関連

・内蔵ディスクは ソフトウェアRAIDとして使用
メインCPUを使用して処理するソフトウェアRAIDとして実装されているようだ。
作成したソフトウェアRAIDは、Mdiskという形で認識させている。
(SVCの機能を単体ディスクに対して直接適用している形)

→ 内蔵ディスクが高負荷になると、メインCPU負荷があがり
それに伴い、外部RAIDに対する処理が遅延する可能性がある。
あまり内蔵ディスクにディスクを増設しすぎない方がいいのではないか?

・おそらく処理を簡略化するために、作成できるRAID構成が限定されている。
メインCPUへの負荷軽減等を考え、ある程度RAID構成を決めうちしてる
と想定される。

SAS/SATAチップ的に考えると、内部はディスク4本で1つの単位となっていて
その帯域をうまく使えるように8本もしくは12本、という単位があるのだと思われる。

なので、これ以外の単位のRAID5/6は、パフォーマンス面で
若干不利になるのだと思われる
(なので「Optimize for perfomance」と「Optimize for capatcity」がある?)

・スペアディスクは常にスペアとなる
スペアディスクは障害時に「一時的に使用されるもの」といった位置づけであり
障害ディスク交換後、内容をコピーする処理(コピーバック)が走る。
このため、ディスク交換後、パフォーマンス低下が発生する。

たぶん、このコピーバックする、というのも、RAID構造の簡略化、の一環

・内蔵ディスクについてのGUIが貧弱なのも、おまけだから?
SVCの機能を単体ディスクに対して直接適用している、というだけなので
従来のインタフェースを使っても、同等の設定を行うことはできるが、
ある程度簡単に設定ができるように「内蔵」という設定項目を作った
というような位置づけな印象を受ける

・たぶん、Web GUIはSVC/V7000/XIVで開発が共通化されてそう
実際のバックエンド処理については、分かれていそう

Easy Tier関連

・Easy Tierは、SSDだけでくんだMdiskを作ってから設定する

・SSD用Mdiskは、SSD 2本のRAID10で作成する

・スペアSSDを用意しておかないと、SSDの代わりに普通のHDDを
使用してしまうという仕様で、マニュアルでも警告されている。
HDDが割り当てられてしまうと、Easy Tierの意味がなくなるのと、
そもそもストライプされないHDDに頻繁な書き込みされることになり、
かえって遅くなるので注意が必要。

・SSD-HDD間のデータ移行はエクステント単位で行われる
ストレージプールで設定したエクステントサイズは
最小16MB、デフォルト256MB、最大8192MBと設定できるが
SSDは読み込みは速いが書き込みは遅い、という特性がある。
このため、エクステントが大きいと時間がかかってしまうはず。
Easy Tierを効率よく使用するにはエクステントを
小さく設定した方がよいと想定される。
警告: エクステントサイズによりV7000全体の管理容量が変わるので注意

・・・そういえば、旧製品時代は「すとあうぃず」って読んでたのに、いまは「すとあわいず」だなぁ・・・
てっきり、「Storage Wizard」の略だと思ってたのに