●Overview
You need to configure EVC to add servers with different CPU generation to VMware vSAN HCI.
If your VMware vSAN HCI network is configured with vDS, you need some tips.😀
●Oparation
１．Create "Ephemeral binding" DVportGroup to vDS.
２．Disconnect esxi running vcsa using vsphere client.
３．Turn on EVC.
４．Log in to ESXi running vCenter Server using Host Client.
５．Shutdown vCSA.
６．Unregister vCSA from ESXi using Host Client.
７．Register vCSA with another ESXi of vSAN cluster using Host Client.
８．Change the vCSA Network Label to "Ephemeral binding" using Host Client.
９．Start vCSA using Host Client.
１０．Log in to vCSA started using vsphere client.
１１．Change vCSA Network Label to the original "Dynamic binding" DVportGroup.
2019年8月30日金曜日
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）はミラーされていない状態であることが確認できます。
A.バックアップ取得時のポリシーが設定される。
B.リストア直前のポリシーが設定される。
C.デフォルトのポリシーが設定される。
----------------------
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 でした！！
----------------------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 の容量は逼迫する
手順概要は以下の通りです。
簡単ですね。
-------------------------------
１．Guest OS にログインして、対象のディスクをゼロクリアする。
２．圧縮前に Guest OS をシャットダウンする。
３．vmdk を vmkfstools コマンドを使って圧縮する。
-------------------------------
では、実際の手順をご紹介します。
なお、今回の Linux OS の構成はこのようになっています。
-------------------------------
OS:CentOS 6.2
vCPU：1
vRAM：2GB
vmdk：20GB(Thin provisioning)
-------------------------------
０．まず、現状のストレージ使用量を確認しておきます。
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 #
-------------------------------
１．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 #
-------------------------------
２．圧縮前に 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]#
-------------------------------
３．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 から状態を確認すると、このようになりました。
ちなみに、Guest OS 内でゼロクリアしたあと、Storage vMotion を行っても、圧縮はできませんでした。
Storage vMotion だと、一旦 Eager Zeroed Thick disk に変更したあと、改めて Thin provisioning disk に変更するとできそうですね。（試していませんが。）
Thin provisioning ディスクは容量可変ディスクですが、一旦アロケートされたブロックは開放しないので、ファイルの増減が多いシステムでは結構無駄な領域として残ってしまいがちです。
なお、今回は Guest OS が Linux OS の場合の手順です。
Thin provisioning vmdk を圧縮するにあたってのポイントは 2 つです。
・圧縮前に Guest OS 内で空き容量をゼロクリアする
・ゼロクリアするので、一時的に VMFS の容量は逼迫する
手順概要は以下の通りです。
簡単ですね。
-------------------------------
１．Guest OS にログインして、対象のディスクをゼロクリアする。
２．圧縮前に Guest OS をシャットダウンする。
３．vmdk を vmkfstools コマンドを使って圧縮する。
-------------------------------
では、実際の手順をご紹介します。
なお、今回の Linux OS の構成はこのようになっています。
-------------------------------
OS:CentOS 6.2
vCPU：1
vRAM：2GB
vmdk：20GB(Thin provisioning)
-------------------------------
０．まず、現状のストレージ使用量を確認しておきます。
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 #
-------------------------------
１．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 #
-------------------------------
２．圧縮前に 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]#
-------------------------------
３．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 に書かれている通り、推奨しない&将来未サポートになるかもしれない構成なのです。
「アップグレードした後は PSC と vCenter Server のデプロイモデルを変更することはできない。」
と書かれています。
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 コマンドのタイムアウトなので気にしないでください。
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 のインストール媒体を使ってアップグレードするだけです。
トポロジで表すと、このような構成です。
ところで、vCenter 5.1/5.5 を Simple Install で構成した場合は、このような構成になります。
しかし、このトポロジ構成は KB2108548 に書かれている通り、推奨しない&将来未サポートになるかもしれない構成なのです。
------------------------------------------------------------------------------------
Topologies that are deprecated and will be unsupported in the future.
These topologies are not recommended.
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 と同じである必要はありません。
 |
| 一番上を選択する |
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をロールバックすることで、/bootbankと/altbootbankの状態の変化を見ていきます。
現在の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."
ロールバックできませんでした。そんなに甘くはないですね。
まとめると、ロールバックは一回のみ実行できる！！
という事でした。
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)
１．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』 とした時の比率で表示
２．1vCPU / 2vCPU / 4vCPU 構成で、FT 有効/無効での比較
２－１．Sequential Access(CentOS 6.2(32bit))
・FT 無効の測定結果を 『1』 とした時の比率で表示
２－２．Random Access(CentOS 6.2(32bit))
・FT 無効の測定結果を 『1』 とした時の比率で表示
２－３．Sequential Access(Windows Server 2012)
・FT 無効の測定結果を 『1』 とした時の比率で表示
２－４．Random Access(Windows Server 2012)
・FT 無効の測定結果を 『1』 とした時の比率で表示
あくまで個人的な検証結果ですので、参考程度で見てください。
今回は 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)
 |
| 環境構成図 |
１．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) |
２．1vCPU / 2vCPU / 4vCPU 構成で、FT 有効/無効での比較
２－１．Sequential Access(CentOS 6.2(32bit))
・FT 無効の測定結果を 『1』 とした時の比率で表示
 |
| IOPS と平均レスポンスタイム(Sequential) |
２－２．Random Access(CentOS 6.2(32bit))
・FT 無効の測定結果を 『1』 とした時の比率で表示
 |
| IOPS と平均レスポンスタイム(Random) |
２－３．Sequential Access(Windows Server 2012)
・FT 無効の測定結果を 『1』 とした時の比率で表示
 |
| IOPS と平均レスポンスタイム(Sequential) |
２－４．Random Access(Windows Server 2012)
・FT 無効の測定結果を 『1』 とした時の比率で表示
 |
| IOPS と平均レスポンスタイム(Random) |
2015年4月11日土曜日
FT VM on Nested ESXi 6.0
vSphere 6 の Fault Tolerance から、SMP に対応しました。
最大 4 vCPU の仮想マシンで vSphere FT を構成することが可能です。
簡単に動作確認する方法として、Nested ESXi 6.0 上で vSphere FT を構築する方法をご紹介します。
ちなみに今回は、
Xeon 5600番台(Westmere)のサーバ(ESXi 5.5)上に Nested ESXi 6.0 を構築しました。
構築するにあたってのポイントは 2 つです。
・ Nested ESXi 6.0 の仮想マシンで Hardware virtualization を有効にする
・ Nested ESXi 6.0 の仮想マシンに VMXNET3 の NIC を追加する(FT logging 用)
手順の概要は以下の通りです。
操作は vSphere Web Client を利用します。
------------------------------------------------------
1. 仮想マシンを ESXi 5.1 以降の互換性で作成する。(Nested ESXi 6.0用)
2. 作成した仮想マシンで Hardware virtualization を有効にする。
3. VMXNET3 の仮想 NIC を追加する。
4. Guest OS Virsion を VMware ESXi 5.x に変更する。
5. 作成した仮想マシンに ESXi 6.0 をインストールする。
6. Nested ESXi 上で FT Network を設定する。
7. Nested ESXi 上の仮想マシンで Fault Tolerance をオンにする。
------------------------------------------------------
1. 仮想マシンを ESXi 5.1 以降の互換性で作成する。(Nested ESXi 6.0用)
この時、Guest OS は Other(64-bit)のままにしておきます。
これは VMXNET3 の NIC を追加する為です。VMware ESXi 5.x を指定してしまうと
VMXNET3 が追加できません。
2. 作成した仮想マシンで Hardware virtualization を有効にする。
3. VMXNET3 の仮想 NIC を追加する。
経験上、Nested ESXi 6.0 と VMXNET3 の相性が悪く、通信が途切れることが
多々ありますので、FT Logging 用だけにしておいたほうが良いです。
4. Guest OS Virsion を VMware ESXi 5.x に変更する。
5. 作成した仮想マシンに ESXi 6.0 をインストールする。
最大 4 vCPU の仮想マシンで vSphere FT を構成することが可能です。
簡単に動作確認する方法として、Nested ESXi 6.0 上で vSphere FT を構築する方法をご紹介します。
ちなみに今回は、
Xeon 5600番台(Westmere)のサーバ(ESXi 5.5)上に Nested ESXi 6.0 を構築しました。
構築するにあたってのポイントは 2 つです。
・ Nested ESXi 6.0 の仮想マシンで Hardware virtualization を有効にする
・ Nested ESXi 6.0 の仮想マシンに VMXNET3 の NIC を追加する(FT logging 用)
手順の概要は以下の通りです。
操作は vSphere Web Client を利用します。
------------------------------------------------------
1. 仮想マシンを ESXi 5.1 以降の互換性で作成する。(Nested ESXi 6.0用)
2. 作成した仮想マシンで Hardware virtualization を有効にする。
3. VMXNET3 の仮想 NIC を追加する。
4. Guest OS Virsion を VMware ESXi 5.x に変更する。
5. 作成した仮想マシンに ESXi 6.0 をインストールする。
6. Nested ESXi 上で FT Network を設定する。
7. Nested ESXi 上の仮想マシンで Fault Tolerance をオンにする。
------------------------------------------------------
1. 仮想マシンを ESXi 5.1 以降の互換性で作成する。(Nested ESXi 6.0用)
この時、Guest OS は Other(64-bit)のままにしておきます。
これは VMXNET3 の NIC を追加する為です。VMware ESXi 5.x を指定してしまうと
VMXNET3 が追加できません。
 |
| 全ての設定が終わるまで Other(64-bit) のまま変更しない |
2. 作成した仮想マシンで Hardware virtualization を有効にする。
 |
| Hardware virtualization をチェックする |
3. VMXNET3 の仮想 NIC を追加する。
経験上、Nested ESXi 6.0 と VMXNET3 の相性が悪く、通信が途切れることが
多々ありますので、FT Logging 用だけにしておいたほうが良いです。
 |
| VMXNET3 の vNIC を追加する |
 |
| 実は Nested ESXi ではサポートされていない |
 |
| Nested ESXi 上ではこのように表示されます |
4. Guest OS Virsion を VMware ESXi 5.x に変更する。
 |
| VMXNET3 の vNIC を追加している為、 アラートが表示されるが気にしない |
5. 作成した仮想マシンに ESXi 6.0 をインストールする。
(絵は省略)
6. Nested ESXi 上で FT Network を設定する。
7. Nested ESXi 上の仮想マシンで Fault Tolerance を オンにする。
6. Nested ESXi 上で FT Network を設定する。
 |
| FT 用の vmkernel を VMXNET3 の NICに接続する |
7. Nested ESXi 上の仮想マシンで Fault Tolerance を オンにする。
 |
| FT をオンにする |
登録:
投稿 (Atom)