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

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

vSphere5でRealtek NICをサポート

元ネタ: ESX VirtualizationのRealtek onboard NIC support in vSphere 5

vSphere5でついにRealteckのチップを使ったNICをサポートしたらしい。

いまのところ、以下の3種類で使えるらしい

・Realtek 8168 – Asus P6T SE board
・Realtek 8169 – Asus Sabertooth X58 board
・Realtek 8111E – Shuttle SH55

いろんなマザーボードのオンボードNICとして採用されていることが多いので、デスクトップ向けのマザーボードでvSphere5を動かすのも簡単になりそうです。

で、ESXi5.0のダウンロードリンクvCenterServer 5.0のダウンロードリンクが判明したりしてるわけですが、まだダウンロードはできない状態・・・なのかな?
少なくても、私のアカウントではできませんでした。

vSphere Storage Appliance 1.0について調べた

2020/03/18追記

vSphere Storage ApplianceはvSphere 5.5の「vSphere Storage Appliance 5.5.6」が最終バージョンとなりました。

代替はvSANとなります。

vSANへの移行手法について「Migration from vSphere Storage Appliance (VSA) to VMware vSAN (2068923)」にて説明されています。

注意点:VSAは2台構成可能。vSANは最低3台構成からとなるので移行できない場合がある。


vSphere5で登場したストレージアプライアンス vSphere Storage Appliance 1.0について調べた。

・物理的な共有ディスク無しで共有を作るアプライアンス
・各ESXからは、NFS共有として見える
・実体はESXの上で動く仮想マシン(以下, VSA)
・動かすには最低2台のESXで、VSAを動かす必要がある
・VSA3台構成(ESX 3台の上で1つずつ動かす)まで可能
・各VSA間でデータミラーを行う
 (2VSAなら相互ミラー、3VSAはA:B,B:C,C:Aという感じで)
・Datastoreとしては、各VSAが別個のものとして見える
 (2VSAならDatastoreは2つ、3VSAならDatastoreは3つ)
 (3台分の容量を合わせて大きなボリュームは作れない)
・VSAの管理は、vSphere標準画面に統合される
・VSAで作ったDatastoreには、25VM~35VMぐらいを載せられる
・Storage vMotionやDRSと一緒に使うこともできる

各VSA間でRAIDが組める、的な記述を見かけたので、RAID5みたいなこともできるのか?と感じたのですが、そのようなことはできずに、単純なミラーの実現だけのようです。
特に各VSAの領域をまとめて1つとすることができない、というのが、ちょっと残念です。

モバイルバージョンを終了