免責事項

当ブログに掲載されている情報は個人的に調べたものであり、その内容の正確性や安全性を保証するものではありません。
記事で紹介している情報で被ったいかなる損害に関しても、当サイトでは一切の責任を負いかねます。

2015年7月6日月曜日

Change of state of virtual machine storage policy

今回は vsanDatastoreに配置している仮想マシンを vDP でバックアップ/リストアすると、その仮想マシンに設定している仮想マシンストレージポリシーはどの時点(バックアップ取得時?リストア直前?)を基準にしたポリシーが設定されるのかをご紹介します。



3択問題ですね。
----------------------
A.バックアップ取得時のポリシーが設定される。
B.リストア直前のポリシーが設定される。
C.デフォルトのポリシーが設定される。
----------------------

前提としては、バックアップ取得時の仮想マシンストレージポリシーは、『VSAN-Failer1』という、仮想マシンストレージポリシーを設定していました。(画像がなくてスミマセン。。。)
このポリシーは、"FTT(Failures to Tolerate) = 1" を設定しているものです。
ですので、コンポーネント(VMホーム、vmdk)のミラー数は FTT+1 なので、 それぞれ "2" と言うことになります。

では早速リストアをやってみます。
仮想マシンをリストアする前に、『VSAN-Failer0』という仮想マシンストレージポリシーに変更しました。
このポリシーは、"FTT(Failures to Tolerate) = 0" を設定しているものです。
ですので、コンポーネント(VMホーム、vmdk)はミラーされていない状態であることが確認できます。
リストア直前の仮想マシンストレージポリシーの確認① 


リストア直前の仮想マシンストレージポリシーの確認②
 

まず上書きする形でリストアしてみます。
上書きするようにリストア
 
仮想マシンストレージポリシーを見てみると、リストアする直前の仮想マシンストレージポリシーが保持されていることが確認できます。
上書きリストア後の仮想マシンストレージポリシーの確認①

上書きリストア後の仮想マシンストレージポリシーの確認②
 
次に新規仮想マシンとしてリストアしてみます。
新規仮想マシンとしてリストア
 
仮想マシンストレージポリシーを見てみると、デフォルトの仮想マシンストレージポリシーが設定されていることが確認できます。
新規仮想マシンとしてリストアした後の仮想マシンストレージポリシーの確認①

新規仮想マシンとしてリストアした後の仮想マシンストレージポリシーの確認②
まとめると、
----------------------
上書きリストア→リストア直前の仮想マシンストレージポリシーが設定される。
新規仮想マシンとしてリストア→デフォルトの仮想マシンストレージポリシーが設定される。
----------------------
 
 
というわけで、正解は B と C でした!!
----------------------
A.バックアップ取得時のポリシーが設定される。
B.リストア直前のポリシーが設定される。
C.デフォルトのポリシーが設定される。
----------------------

 
vDP でリストアするときに、仮想マシンストレージポリシーを選択する項目はありませんでした。
 

2015年7月5日日曜日

Compress Thin provisioning disk (Linux OS)

今回は Thin provisioning フォーマットの vmdk を vmkfstools を使って圧縮する方法をご紹介します。
Thin provisioning ディスクは容量可変ディスクですが、一旦アロケートされたブロックは開放しないので、ファイルの増減が多いシステムでは結構無駄な領域として残ってしまいがちです。
 なお、今回は Guest OS が Linux OS の場合の手順です。

Thin provisioning vmdk を圧縮するにあたってのポイントは 2 つです。

 ・圧縮前に Guest OS 内で空き容量をゼロクリアする
 ・ゼロクリアするので、一時的に VMFS の容量は逼迫する


手順概要は以下の通りです。
簡単ですね。
-------------------------------
1.Guest OS にログインして、対象のディスクをゼロクリアする。
2.圧縮前に Guest OS をシャットダウンする。
3.vmdk を vmkfstools コマンドを使って圧縮する。
-------------------------------


では、実際の手順をご紹介します。
なお、今回の Linux OS の構成はこのようになっています。
-------------------------------
OS:CentOS 6.2
vCPU:1
vRAM:2GB
vmdk:20GB(Thin provisioning)
-------------------------------


0.まず、現状のストレージ使用量を確認しておきます。
VMFS としてはこのような使用量になります。
-------------------------------
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 # du -hs test001/test001-flat.vmdk
3.1G    ./test001/test001-flat.vmdk
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 #

-------------------------------


1.Guest OS にログインして、対象の vmdk に対してゼロクリアを行います。
-------------------------------
[root@test001 home]# dd if=/dev/zero of=ZEROFILE.txt bs=1000000 ; rm -f ZEROFILE.txt
dd: writing `ZEROFILE.txt': デバイスに空き領域がありません
13680+0 records in
13679+0 records out
13679198208 bytes (14 GB) copied, 951.158 s, 14.4 MB/s
[root@test001 home]#

-------------------------------

このとき、VMFS はこのような使用量になります。(青字)
-------------------------------
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 # du -hs test001/test001-flat.vmdk
15.6G   test001/test001-flat.vmdk
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 #

-------------------------------


2.圧縮前に Guest OS をシャットダウンします。
-------------------------------
[root@test001 home]# shutdown -h now
Broadcast message from
root@test001
        (/dev/pts/0) at 13:51 ...
The system is going down for halt NOW!
[root@test001 home]#

-------------------------------


3.vmdk を vmkfstools コマンドを使って圧縮します。(青字)
これは ESXi から作業します。
-------------------------------
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 # vmkfstools --punchzero test001/test001.vmdk
vmfsDisk: 1, rdmDisk: 0, blockSize: 1048576
Hole Punching: 100% done.
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 #

-------------------------------

vmkfstools 実行後に VMFS の使用量を確認します。
すると、割り当て容量が減少したことが確認できました。(青字)
-------------------------------
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 # du -hs test001/test001-flat.vmdk
2.7G    test001/test001-flat.vmdk
/vmfs/volumes/52049736-07317bdd-a74a-005056910157 #

-------------------------------


これらの作業を vSphere Web Client から状態を確認すると、このようになりました。

vSphere Web Client からみたストレージ使用量の変化


ちなみに、Guest OS 内でゼロクリアしたあと、Storage vMotion を行っても、圧縮はできませんでした。
Storage vMotion だと、一旦 Eager Zeroed Thick disk に変更したあと、改めて Thin provisioning disk に変更するとできそうですね。(試していませんが。)

2015年7月4日土曜日

Dividing vCenter SSO and vCenter Server before upgrading to vCenter 6.0

vSphere 6  で vCenter Server 間の vMotion を実行する場合、Enhanced Linked Mode にする必要があります。
トポロジで表すと、このような構成です。
 

ところで、vCenter 5.1/5.5 を Simple Install で構成した場合は、このような構成になります。


当然、この状態で vCenter 6.0 にアップグレードして Enhanced Linked Mode の構成にすると、こうなります。


しかし、このトポロジ構成は KB2108548 に書かれている通り、推奨しない&将来未サポートになるかもしれない構成なのです。
------------------------------------------------------------------------------------
Topologies that are deprecated and will be unsupported in the future.
These topologies are not recommended.
------------------------------------------------------------------------------------
さらに、vSphere 6 アップグレードガイドには、
「アップグレードした後は PSC と vCenter Server のデプロイモデルを変更することはできない。」
と書かれています。
vSphere 6 アップグレードガイド抜粋

Simple Install で構成したら、Enhanced Linked Mode を使用したくても躊躇しちゃいますね。
ではどうすれば良いかというと、アップグレード前に分けちゃえば良いんです。
分割方法は KB2033620 に書かれています。
vCSA の場合は KB2094888 になります。vCSA の場合は vCSA 5.5 のみ情報がありました。

今回は、この KB2033620 の方法で vCenter SSO 5.5 と vCenter Server 5.5 を分けて、かつそれぞれを PSC とvCenter Server 6.0 へアップグレードする方法をご紹介します。

作業概要は以下の通りです。
------------------------------------
1. 旧 vCenter SSO の情報をバックアップ
2. 新 vCenter SSO を新しいサーバにカスタムインストール
3. vCenter Inventory Service を新 vCenter SSO に登録
4. vCenter Server を新 vCenter SSO に登録
5. vCenter Server と vCenter Inventory Service を再登録
6. vSphere Web Client を新 vCenter SSO に登録
7. 旧 vCenter SSO の情報を新 vCenter SSO へリカバリ
8. 旧 vCenter SSO をアンインストール
9. 新 vCenter SSO を PSC にアップグレード
10. vCenter Server をアップグレード
------------------------------------
この作業の 3~6 が、KB2033620 に該当します。

早速やってみましょう。

1. 旧 vCenter SSO の情報をバックアップ

vCenter SSO の情報をバックアップする場合、以下の3つの方法が考えられますが、私が試した中では、1つしかできませんでした。

  ・vSphere Web Client でログインし、vCenter SSOの情報をメモする
 
   -ユーザ、グループ
   -パスワードポリシー、ロックアウトポリシー、トークンポリシー
   -アイデンティティソース
   -STS 証明書(メモと言うよりどの証明書を使っていたかの確認)

 
  ・バックアップせず、新 vCenter SSO を同じドメインの新規サイトとして追加し、旧 vCenter SSO の情報を複製する


  ・旧 vCenter SSO の構成ファイルをバックアップする(KB2057353
 

正解は「vCenter SSOの情報をメモする」です。
2番目の旧 vCenter SSO と 新 vCenter SSO を同じドメインにして、情報を複製するやり方だと、アップグレードした後も旧 vCenter SSO と同期使用としてエラーメッセージがログに出力され続けます。
3番目の構成情報のバックアップは、新 vCenter SSO のサーバ名が変わる為、使えないのです。


2. 新 vCenter SSO を新しいサーバにカスタムインストール

新しいサーバに vCenter SSO をカスタムインストールします。そのとき、vCenter SSO のデプロイモードは、「最初の vCenter Server 用の vCenter Single Sign-On 」でインストールします。
このとき、サイト名、vCenter SSO ユーザ(Administrator@vSphere.local)のパスワードは旧 vCenter SSO と同じである必要はありません。

一番上を選択する
3. vCenter Inventory Service を新 vCenter SSO に登録
4. vCenter Server を新 vCenter SSO に登録
5. vCenter Server と vCenter Inventory Service を再登録
6. vSphere Web Client を新 vCenter SSO に登録

ここはKBそのままなので省略します。注意点としては、バッチ実行後、エラーが表示される場合がありますが、net start コマンドのタイムアウトなので気にしないでください。
vCenter Inventory Service を新 vCenter SSO に登録する時に表示される

vCenter Server を新 vCenter SSO に登録する時に表示される


7. 旧 vCenter SSO の情報を新 vCenter SSO へリカバリ

vSphere Web Client でログインし、作業 1 でメモした情報を入力します。


8. 旧 vCenter SSO をアンインストール

vCenter SSO のアンインストールはインストール媒体を使うか、コントロールパネルの「プログラムと機能」からアンインストールすることができます。
アンインストールしないと、次の作業で行う vCenter Server のアップグレード時に、もう使っていない vCenter SSO までアップグレードされてしまいます。


9. 新 vCenter SSO を PSC にアップグレード
10. vCenter Server をアップグレード


あとは、vCenter Server 6.0 のインストール媒体を使ってアップグレードするだけです。
 

2015年7月3日金曜日

Roll back of ESXi, further roll back

今回は ESXi のロールバックについてご紹介します。

ESXi のロールバックは『Shift + R』で実行します。
で、どのタイミングで実行するのかというと、この起動画面の時です。
ESXiの起動画面


最初に、ESXiのインストールパーティションはどのようになっているかというと、こんなイメージになっています。
これからESXiをロールバックすることで、/bootbankと/altbootbankの状態の変化を見ていきます。
ESXiのパーティションイメージ


現在のESXiのインストールパーティションの情報を確認します。
青字の箇所が現在のBoot Partiton内の情報です。
----------------------------------
~ # vmware -v
VMware ESXi 5.5.0 build-1892794
~ #
~ # df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-5       5.0G   2.1G      2.9G  41% /vmfs/volumes/datastore1
vfat         4.0G   8.8M      4.0G   0% /vmfs/volumes/53b4a926-32f4ebef-dd5d-0050569152b4
vfat       249.7M 130.2M    119.6M  52% /vmfs/volumes/17c62275-beda452f-73cf-0b3203cc9f9f
vfat       249.7M 157.0M     92.7M  63% /vmfs/volumes/184ee772-92c4e69d-a69d-4d71ce05557c

vfat       285.8M 192.7M     93.1M  67% /vmfs/volumes/53b4a415-b3d2eb67-9e9b-0050569152b4
~ #
~ # diff /bootbank/boot.cfg /altbootbank/boot.cfg
(中略)
-build=5.5.0-1.28.1892794
(中略)
+build=5.1.0-799733
~ #

----------------------------------
文字だけでは分かりにくいので絵にしてみました。
現在のパーティション情報


では実際ESXiのロールバックをやってみます。
先程の起動画面で『Shift + R』を押すと、このような画面が出てきます。
ここで<Y:Roll back>を実行します。簡単ですね。
ロールバック実行画面


ロールバックした後のBoot Partiton内の情報を確認します。
----------------------------------
~ # vmware -v
VMware ESXi 5.1.0 build-799733
~ #
~ # df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-5       5.0G   2.1G      2.9G  41% /vmfs/volumes/datastore1
vfat         4.0G   9.4M      4.0G   0% /vmfs/volumes/53b4a926-32f4ebef-dd5d-0050569152b4
vfat       249.7M 130.2M    119.6M  52% /vmfs/volumes/17c62275-beda452f-73cf-0b3203cc9f9f
vfat       249.7M 157.1M     92.7M  63% /vmfs/volumes/184ee772-92c4e69d-a69d-4d71ce05557c
vfat       285.8M 192.7M     93.1M  67% /vmfs/volumes/53b4a415-b3d2eb67-9e9b-0050569152b4
~ #
~ # diff /bootbank/boot.cfg /altbootbank/boot.cfg(中略)
-build=5.1.0-799733
(中略)
+build=5.5.0-1.28.1892794
~ #

----------------------------------
文字だけでは分かりにくいので絵にしてみました。
ロールバック後のパーティション情報


/bootbankと/altbootbank内の情報が入れ替わっています。
・・・入れ替わるんですね。

入れ替わったので、もう一回ロールバックできるのか?なんて疑問が出てきたので、この状態からもう一度ロールバックを実行してみます。
再度ロールバックを実行

"No alternate hypervisor to rool back to."
ロールバックできませんでした。そんなに甘くはないですね。

まとめると、ロールバックは一回のみ実行できる!!
という事でした。

 

2015年7月1日水曜日

Performance of vSphere FT

vSphere 6 の機能の中から、vSphere FT の性能を個人的に調べましたので、ご紹介します。
あくまで個人的な検証結果ですので、参考程度で見てください。
今回は Nested ESXi 上で検証しました。


■測定概要
 ・1vCPU 構成で、SMP-FT、LegacyFT、vSphere 5.5 FT のそれぞれのDiks I/O 性能を測定
 ・1vCPU / 2vCPU / 4vCPU 構成で、FT有効/無効でのDiks I/O 性能を測定

■測定ツール
 iometer

■環境
 ・ESXi : Nested ESXi 6.0/5.5
 ・Storage  : 物理, iSCSI(1Gbps), RAID5(5D+1P), 3.5" 600GB 15krpm SAS
 ・VM : CentOS 6.2(32bit), 1vCPU, 1024MB-vRAM, 10GB-vmdk(Eaga Zeroed)
                 Windows Server 2012, 1vCPU, 1024MB-vRAM, 10GB-vmdk(Eaga Zeroed)

環境構成図


1.SMP-FT、LegacyFT、vSphere 5.5 FT の比較(CentOS 6.2(32bit))
※Nested ESXi では、Windows Server 2012 のLegacyFT、vSphere 5.5 FT が構成できなかったので、比較対象外としました。
    ・vSphere 5.5 FT の測定結果を 『1』 とした時の比率で表示
IOPSと平均レスポンスタイム(Sequential/Random)


2.1vCPU / 2vCPU / 4vCPU 構成で、FT 有効/無効での比較
 
 2-1.Sequential Access(CentOS 6.2(32bit))
   ・FT 無効の測定結果を 『1』 とした時の比率で表示
IOPS と平均レスポンスタイム(Sequential)

 2-2.Random Access(CentOS 6.2(32bit))
   ・FT 無効の測定結果を 『1』 とした時の比率で表示
IOPS と平均レスポンスタイム(Random)

 2-3.Sequential Access(Windows Server 2012)
   ・FT 無効の測定結果を 『1』 とした時の比率で表示
IOPS と平均レスポンスタイム(Sequential)

 2-4.Random Access(Windows Server 2012)
   ・FT 無効の測定結果を 『1』 とした時の比率で表示
IOPS と平均レスポンスタイム(Random)