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」の略だと思ってたのに

Tintri VMstore T445


この記事についてのアップデート内容をTintri VMstore T540に記載しています。
下を読んだあとに、上記記事を見てください。
— 2011/11/21 追記分はここまで —
VMware vSphere Blogの「VMworld 2011 – Interesting Storage Stuff.」でいくつかストレージが紹介されている。

その中で、Tintri社のTintri VMstore T445って、なんだろ?と調べてみた。

VM(Virtual Machine)に特化したストレージ、ってことは、どーせまたiSCSIストレージなんでしょ?と見てみたんですが、NFSストレージ、と書いてあってちょっとびっくり。

ハードウェアとしては・・・

4U筐体にヘッド部分とストレージが含まれており、1筐体で8.5TBを提供する、とのこと。
ストレージ自体は、「160GB SSDを9本」+「1TB HDDを15本」で、どちらも3.5インチ形状。

というか、データシートの製品写真を見る限り、3.5インチディスク24本構成で、4Uで、このカラーリングってことは、SUPERMICROの4U SuperChassis 846シリーズってことですよね・・・たぶん。

ソフトウェア的には特に書いていないですが、Linuxベース・・・なんでしょうかねぇ?

おもしろそうな点

・NFSストレージであること

・vSphere Client用のプラグインがある
 各VMごとのストレージパフォーマンス(IOPS/MBps)が見れるようだ
 それも、時系列変位のグラフも提供できるようだ
 (Eliminate VM Performance Bottlenecksより)

マイナス点

・SSD/HDD共にRAID6を組む、という記述。(Redundancy RAID6 + hot spare for all SSDs and HDDs)
 SSDにもRAID6組む、というのはSSDの寿命的にどうなの?
 SSDとHDDの使い分けは?
 SSDにもRAID6組むぐらいだから、キャッシュ扱いではなく、メインで使用?

・標準ではギガイーサ2本しかない
 ただのIntelマザーボードだから増設すればいいんだけど・・・

・アラート機能がメール通知とHTTPS管理画面での通知のみ(Alerts SMTP for email alerts, HTTPS for polling)
 NetApp風のAutosupportをサポートを用意している(Autosupport HTTPS (optionally through proxy))のはいいんだけど・・・

・拡張性が0
 これ系だと良くうたわれている「Scalability」が一切書いてない。
 まぁ、8.5TB割り切り型、と考えればいいのかもしれない。

一番の問題点

・ヘッドが壊れたら全滅っぽい
 筐体の冗長性については、一切触れられていませんでした。
 (Tintri VMstorage Datasheet, Virtualize more with VM-aware storage, Eliminate VM Performance Bottlenecksの確認した結果)

安くて、それなりに早いストレージが欲しい、という要件であればいいのかもしれないです。

つまりは、クラウド系で、一時作成系のVMを置く場所として、という要件ぐらいですかねぇ。

データを保持し続ける用途で使うには、バックアップ機能が無い、とか、ヘッドの冗長性が無い、とかいうことを考えると、かなり難しい気がします。

そうそう、ノックスが取り扱うようで、ascii.jpにノックス、VMware専用NAS「Tintri VMstore T445」を投入という記事が出ています。

最大の特徴は、VMwareとAPI連携するファイルシステムで、LUN(Logical Unit Number)を廃し、1ノード=1データストアという構成で利用する。運用中でもノンストップで拡張できるほか、仮想マシンごとに優先順位を付けたり、パフォーマンスの統計をとることが可能だという。

なんて記述がありますが、ここでいう記述はいろいろ誤解を招きそうな感じで、Tintriの資料を読んだ限りでは、「VMwareとAPI連携するファイルシステムで、LUN(Logical Unit Number)を廃し、1ノード=1データストアという構成で利用する」とは「VMwareとはAPI連携し、VMwareとのアクセスはNFSで行い、1ノード=1データストア=1 NFS共有で利用する」という意味で、
「運用中でもノンストップで拡張できる」というのは、「各VMに割り当てた専用データストアの容量が拡張できる」という意味だと思われます。

後者の「ノンストップ拡張」は、NFSデータストアで一般的な仕様で有り、特に注目するべき点ではないような印象を受ける。

もうちょっと資料が出てきてくれないかなぁ・・・

vSphere ESXのパス選択方法の変更


IBM SVCなるものを導入し、VMware vSphere ESX/ESXiで使用することになったわけだが、設定に微妙な点がある。
それは、ESX/ESXi側でマルチパスの設定変更が必要だと言うこと。

まず、現状、どんな設定になっているのかを確認してみる。
ESX/ESXiにsshでログインして「esxcli nmp device list」と実行。

~ # esxcli nmp device list

naa.xxxxxxxxxxxxxxe9d80000000000002d
    Device Display Name: IBM Fibre Channel Disk (naa.xxxxxxxxxxxxxxe9d80000000000002d)
    Storage Array Type: VMW_SATP_SVC
    Storage Array Type Device Config: SATP VMW_SATP_SVC does not support device configuration.
    Path Selection Policy: VMW_PSP_FIXED
    Path Selection Policy Device Config: {preferred=vmhba2:C0:T3:L11;current=vmhba2:C0:T3:L11}
    Working Paths: vmhba2:C0:T3:L11

ずらずら~
~ # 

マルチパスに関する設定は「Path Selection Policy」がソレになる。

現状は「VMW_PSP_FIXED」となっている。
これは、とりあえずアクセスできたパスをずっと使い続け、そのパスが死んだ時に初めて違うパスを使ってみよう、という「固定」の方法。

次に、ESX/ESXiで設定できるマルチパスの方式としてどんなものがあるのか?というのを確認してみる。
それは「esxcli nmp psp list」コマンドを実行する。

~ # esxcli nmp psp list
Name              Description
VMW_PSP_FIXED_AP  Fixed Path Selection with Array Preference
VMW_PSP_MRU       Most Recently Used Path Selection
VMW_PSP_RR        Round Robin Path Selection
VMW_PSP_FIXED     Fixed Path Selection
~ # 

方式としては4種類あることが分かる。
それぞれについて簡単に解説をすると・・・

・「VMW_PSP_MRU / 最近の使用」
最近使ったパスを優先して使う。
Active/Passive型RAIDの場合の標準設定。
LSI Logic OEM系のRAIDだとコレ。IBM DS3xxx、DS4xxxx、DS5xxxが該当になるはず。

・「VMW_PSP_FIXED / 固定」
最初にアクセスできたパスをずっと使い続け、そのパスが死んだ時に初めて違うパスを使ってみようかな。という感じの使い方。
そして、最初にアクセスしたパスが復旧したら、まだ戻る。
Active/Active型RAIDの場合の標準設定。

・「VMW_PSP_FIXED_AP」
基本はVMW_PSP_FIXEDと同じだが、Active/Passive型RAIDや、ALUAモード対応RAIDにも対応させた形式。
ちなみにALUAとは非対称論理ユニットアクセス(Asymmetric Logical Unit Access)で、SCSI SPC-3の使用として規定されたI/Oパス決定の仕組みです。
詳しく知りたい人はEMC CLARiX 非対称アクティブ/アクティブ機能(ALUA)詳細レビューで解説されているので、参考にしてください。

・「VMW_PSP_RR / ラウンド ロビン」
複数あるパス間で、バランスを取りながら使用していく形式。
Active/Active型のRAIDでないと使えない形式。

という感じになる。


以前のIBM SVCはマルチパスの仕組みがちょっといけてないところがあったようですが、現在のIBM SVCではかなり改善されているようで、「VMW_PSP_RR」が使用できるようになっています。

しかし、設定の現状をみると「VMW_PSP_FIXED」。
まず、システムに登録されているストレージごとのパス利用方法の既定値(デフォルト)を確認するためには「esxcli nmp satp list」を実行する。

~ # esxcli nmp satp list
Name                 Default PSP       Description
VMW_SATP_SVC         VMW_PSP_FIXED     Supports IBM SVC
VMW_SATP_SYMM        VMW_PSP_FIXED     Placeholder (plugin not loaded)
VMW_SATP_MSA         VMW_PSP_MRU       Placeholder (plugin not loaded)
VMW_SATP_LSI         VMW_PSP_MRU       Placeholder (plugin not loaded)
<略>
~ # 

SVCの場合、「VMW_PSP_FIXED」と定義されているのがわかる。
調べてみると、IBM SVCの以前のバージョンでは固定だったらしい。

仕方が無いので手動で変更。
GUIから変更することも可能ではありますが、ディスク数が多いと、全部に対して手動で変更する必要があるので非常に大変です。

なので、コマンドを実行して変更するようにしましょう。

とりあえず、ESXiでsshログインを有効にしてから、sshでログインして、SANで認識されているディスクはすべてRound Robinに設定、というものすごくおおざっぱなコマンドを実行してみることにする。

for device in `esxcli nmp path list|grep "Device: "|awk '{ print $2 }' | grep naa`
do
	esxcli nmp device setpolicy --psp VMW_PSP_RR --device $device
done

解説
現行のVMware ESX/ESXi 4.0/4.1に置いて、SANのディスクは「naa.xxxxxxx~」という感じの名前で認識される。
なので、対象となるデバイス名を取り出して、それに対してパスを設定する、ということを行う。
といったもの。

エラー処理とかは一切考えていないので、ちゃんと設定できたかどうかは別途確認してください。