カテゴリー: 仮想化

投稿日:

VMware仮想マシンのバックアップに関する解説

VMwareで仮想マシンのバックアップを行う際に出てくる用語について、簡単にまとめてみた。

キーワード
・VMware Consolidated Backup (VCB)
・VMware vStorage APIs for Data Protection (VADP)
・VMware Virtual Disk Development Kit (VDDK)
・File-level Restore(FLR)

VMwareで仮想化を行っている場合、仮想マシンを丸ごと、動作させたままの状態でバックアップすることができる。
その際は、仮想マシン内のOS上で動作しているvmware-toolsと連携し、ファイルシステムに対してある程度の静止点を作成させ、その後にバックアップを行う、といったことが出来るようになっている。

バックアップ・リストアを行う仕組みとして、VMware Consolidated Backup(VCB)と、VMware vStorage APIs for Data Protection (VADP)の2種類がある。
VADPはvSphere4から登場した新しい仕組みで、基本的にはこっちの方が高機能である。
詳細についてはVMware KB1021175:vStorage APIs for Data Protection (VADP) FAQ に掲載されている。

VCBの場合はWindowsのみ、VADPの場合はWindows/Linuxのみであるが、仮想マシン丸ごとでバックアップしても、仮想マシン上のOS内のファイル単位でリストアすることができる。
この手法をFile-Level Restore(FLR)と呼んでいる。

FLRはどのように実現されているか、というあたりだが、実は結構アレなつくりをしている。
仮想ディスクとしてリストアした後、仮想ディスクを内部的にマウントしてリストアする。
というようなイメージでリストアが行われる。

こんな処理をまともに実装してたら、バックアップソフトベンダが死んでしまうので、VMware側で簡単にできるような開発向けのソフトウェアライブラリを用意している。
それが、VMware Virtual Disk Development Kit (VDDK)である。

VDDKは、いくつかバージョンが出ている。
VDDK 5.0
VDDK 1.2.1
VDDK 1.2
VDDK 1.1
VDDK 1.0.1

VDDKのバージョンが異なると何が変わってくるか、という点だが、基本的には新しいバージョンほど機能が増えている、ということになる。

vSphere5と共にリリースされたのがVDDK5.0ではあるが、これを使用したバックアップソフトウェアがvSphere4のバックアップに使用できないといったことは無い。

しかし、逆のVDDK 1.2.1を使用したバックアップソフトウェアをvSphere5環境で利用する場合には、いろいろ注意が必要な点が発生する。
この例の場合、VMFS-5が非サポートであるため、vSphere5環境ではSANストレージを旧来のVMFS-3(vSphere4仕様)で利用する必要が出てくる。

VDDKはバックアップソフトウェアの開発時に内部に組み込まれて使用される。
このため、あとからVDDKだけをバージョンアップするということはできず、バックアップソフトウェアベンダが新しいバージョンを開発するまで新機能は使用できない。
このため、VDDKおよび新しいvSphereリリース時は、バックアップソフトウェアによってできる機能が異なってくるという事態が発生する。

各バックアップソフトの対応については別途調べてください。

投稿日:

VDI環境向けにWindowsをセットアップする

いろいろ資料を調べていたら、「VMware KB 1014508: Correlating vCenter Server and ESX host build numbers to update levels」を発見。

ESX, ESXi, vCenter Serverの各バージョンと、プログラムのBuild number、リリース日の一覧が載っていました。

なんとなーく、ずっと一意に増加しているのかと思っていたんですが、これを見るとそうでもなく、どちらかというと、ビルド日の方にひも付いているようなイメージなんですね。

さて、そんなプチ知識はさておき、仮想デスクトップ環境(VDI)向けにWindows7をセットアップする際に推奨される最適化手順というのがVMwareから出ています。
VMware View Optimization Guide for Windows 7 – OPTIMIZATION GUIDE(pdf)

つか、いろいろめんどい。
もっと簡単にできるようにならないかなぁ、と思っていたところ、そんなツールがありました。
Quest software社からQuest vWorkspace Desktop Optimizerという簡単適用ツールがリリースされている。

どんな風に使うか、というのは、ESX virtualization Mag:How to install VMware View Agent in the Virtual Desktop plus moreで紹介されています。
ちなみに上記記事の前後を見ると、View5のセットアップ全体についても解説されています。英語で。

投稿日:

Tintri VMstore T540

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

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

ハードウェア的な構成についての話
・機種が２つ、廉価版で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が２つついているというのが利点であろう。
その他に管理用として1Gbos NICが２つある。

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

・T540でのヘッド間ディスク共有方法はStorage Bridge Bayを利用
T540では、ヘッドの冗長性アリ、となっているが、どうやって２つのヘッドを１つのディスク群にアクセスさせているのかを、シャーシ側の資料を確認してみたところ、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サーバ内にバックアップイメージを作成するが、容量が少なく済むように１個ずつ実施する
・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.数字」という感じでディレクトリを作成しています。