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に関しては対応する可能性がある。

既存のOpenVZテンプレートのファイルをアップデートする


OpenVZで作成されたテンプレートを更新する。

参考: OpenVZ wiki: Updating Debian template

1. OpenVZの仮想ホストを作成

# vzctl create VID番号 --ostemplate テンプレート名

上記のテンプレート名は/var/lib/vz/template/cache/ にあるtar.gzファイルの名前を使用する。

実行例

# vzctl create 555 --ostemplate scientific-6-standard_6.0_i386
Creating container private area (scientific-6-standard_6.0_i386)
Performing postcreate actions
Saved parameters for CT 555
Container private area was created
#

2014/11/27 追記

/etc/vz/vz.confの設定によっては下記の様に、パラメータが足らないというエラーがでます。

# vzctl create 555 --ostemplate centos-6-standard_6.0-20121116_i386
Creating container private area (centos-6-standard_6.0-20121116_i386)
Initializing quota ...
Error: Not enough parameters, diskspace quota not set
Creation of container private area failed
#

/etc/vz/vz.confに下記のようにDISKSPACE設定とDISKINODES設定を追加することで、回避できます。

DISKSPACE="20G:22G"
DISKINODES="4000000:4400000"

(バージョンによってはvzctl createオプションでdiskspaceは指定できても、diskinodesが指定できない

2014/11/27 追記終


2. 仮想ホストにIPアドレスとDNSサーバを指定する

# vzctl set VID番号 --ipadd IPアドレス --nameserver DNSサーバIP --save

実行例

# vzctl set 555 --ipadd 192.168.x.x --nameserver 192.168.x.x --save
Saved parameters for CT 555
#

3. 仮想マシンを稼働させる

# vzctl start 555
Starting container ...
Container is mounted
Adding IP address(es): 192.168.35.240
Setting CPU units: 1000
File resolv.conf was modified
Container start in progress...
#

2014/11/27 追記

バージョンによっては、以下のようなエラーとなる場合がある。

# vzctl start 555
Error: required UB parameter kmemsize not set
Error: required UB parameter lockedpages not set
Error: required UB parameter privvmpages not set
Error: required UB parameter shmpages not set
Error: required UB parameter numproc not set
Error: required UB parameter physpages not set
Error: required UB parameter vmguarpages not set
Error: required UB parameter oomguarpages not set
Error: required UB parameter numtcpsock not set
Error: required UB parameter numflock not set
Error: required UB parameter numpty not set
Error: required UB parameter numsiginfo not set
Error: required UB parameter tcpsndbuf not set
Error: required UB parameter tcprcvbuf not set
Error: required UB parameter othersockbuf not set
Error: required UB parameter dgramrcvbuf not set
Error: required UB parameter numothersock not set
Error: required UB parameter numfile not set
Error: required UB parameter dcachesize not set
Error: required UB parameter numiptent not set
#

この場合は、/etc/vz/conf/に作成されている該当CIDの.confファイルに下記のエントリーを追記しておくといい。

PHYSPAGES="0:1024M"
SWAPPAGES="0:512M"
KMEMSIZE="465M:512M"
DCACHESIZE="232M:256M"
LOCKEDPAGES="512M"
PRIVVMPAGES="unlimited"
SHMPAGES="unlimited"
NUMPROC="unlimited"
VMGUARPAGES="0:unlimited"
OOMGUARPAGES="0:unlimited"
NUMTCPSOCK="unlimited"
NUMFLOCK="unlimited"
NUMPTY="unlimited"
NUMSIGINFO="unlimited"
TCPSNDBUF="unlimited"
TCPRCVBUF="unlimited"
OTHERSOCKBUF="unlimited"
DGRAMRCVBUF="unlimited"
NUMOTHERSOCK="unlimited"
NUMFILE="unlimited"
NUMIPTENT="unlimited"

2014/11/27 追記終


4. 仮想マシンにログインする

# vzctl enter 555
entered into CT 555
[root@ホスト名 /]#

5. yum updateを実施

# yum update
sl                                                       | 3.2 kB     00:00
sl/primary_db                                            | 3.1 MB     00:12
sl-security                                              | 1.9 kB     00:00
sl-security/primary_db                                   | 5.8 MB     00:12
Setting up Update Process
Resolving Dependencies
<略>
Transaction Summary
================================================================================
Install       0 Package(s)
Upgrade      32 Package(s)

Total download size: 46 M
Is this ok [y/N]: y
Downloading Packages:
<略>
  tzdata.noarch 0:2011h-3.el6

Complete!
[root@ns5 /]#

6. 追加したい設定があったらやっとく
・phpをインストール
・/etc/php.iniに「date.timezone = Asia/Tokyo」の設定を追加
・「ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime」
・/etc/sysconfig/i18nに「LANG=”ja_JP.UTF-8″」を追加

7. 掃除

# yum clean all
Cleaning up Everything
# echo > /etc/resolv.conf
#

8. 仮想ホストの停止

# vzctl stop 555
Stopping container ...
Container was stopped
Container is unmounted
#

9. 仮想ホストからIPアドレス設定を削除

# vzctl set 555 --ipdel all --save
Saved parameters for CT 555
#

10. 仮想ホストのファイルが展開されている場所に移動

# cd /var/lib/vz/private/555
#

11. テンプレートとしてtar.gzファイルを作成

#  tar --numeric-owner -czf /var/lib/vz/template/cache/scientific-6-standard_6.0-20111026_i386.tar.gz .
#

なお、ファイル名は重要。

「ディストリビューション名」-「ディストリビューションのバージョン」-「カスタマイズ説明」_「カスタマイズのバージョン」_「アーキテクチャ」.tar.gz

という書式で指定する。
そうしないと、Proxmoxでは、テンプレートとして指定できない。

12. 使用した仮想マシンの削除

# vzctl destroy 555
Destroying container private area: /var/lib/vz/private/555
Container private area was destroyed
#

13. /etc/vz/conf/に残る仮想マシンの設定ファイルを削除

# rm /etc/vz/conf/555.conf.destroyed
#

Proxmox上のOpenVZ仮想マシンのバックアップ


Proxmox VEにはOpenVZ仮想マシンのバックアップを容易に取れるように、専用ツールvzdumpが用意されている。
このvzdumpは、OpenVZのwikiにも掲載されているぐらいの便利ツールのようです。

vzdumpでバックアップを行うと、各仮想マシンごとにtarファイルができあがります。

さて、このバックアップファイルを、Proxmoxサーバ内部に残しておくとバックアップの意味がないので、外部サーバに転送しましょう。
NFSでマウントした先にコピーというのが一番簡単なやりかたですが、安いNASだとNFSに対応していない場合があります。

まぁ、具体的にはLinkStationをバックアップ先にしたいです。
この場合、CIFS、ftp、そして、rsync(LinkStationは「バックアップ」と呼ばれている)で転送することができますが、無難なあたりでftpで転送する、とします。

そんなスクリプトを作りました

仕様
・ftpサーバに指定ユーザ・パスワードでログインする
・バックアップは10世代保存とする。
・起動中の仮想マシンのみバックアップする
・Proxmoxサーバ内にバックアップイメージを作成するが、容量が少なく済むように1個ずつ実施する
・lftpを使ってアップロードするので、「aptitude install lftp」でインストールしておく

#!/bin/bash
# vzdump and ftp upload script
#
DUMPDIR="/work"
UPLOADDIR="/disk1/backup/dump"

FTPHOST="IPアドレス"
FTPUSER="ユーザ名"
FTPPASSWORD="パスワード"

cd $DUMPDIR
vzlist > vzlist.log

# create upload directory
lftp -c "open -u $FTPUSER,$FTPPASSWORD $FTPHOST
mkdir $UPLOADDIR/transfer"


# dump and upload virtual machine
# "vzlist -1" : dump active VM only
# "vzlist -a -1": dump all VM
# "vzlist -S -1": dump standby VM only
for hostid in `vzlist -1`
do
	echo $hostid;
	cd $DUMPDIR
	vzdump --dumpdir $DUMPDIR $hostid
	lftp -c "open -u $FTPUSER,$FTPPASSWORD $FTPHOST
cd $UPLOADDIR/transfer
mput -E *.tar *.log"
done

# lotate
lftp -c "open -u $FTPUSER,$FTPPASSWORD $FTPHOST
cd $UPLOADDIR
rm -r daily.9
mv daily.8 daily.9
mv daily.7 daily.8
mv daily.6 daily.7
mv daily.5 daily.6
mv daily.4 daily.5
mv daily.3 daily.4
mv daily.2 daily.3
mv daily.1 daily.2
mv daily.0 daily.1
mv transfer daily.0"

上記スクリプトは毎日夜間に実行するつもりのものなので、NetAppライクに「daily.数字」という感じでディレクトリを作成しています。

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データストアで一般的な仕様で有り、特に注目するべき点ではないような印象を受ける。

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