cjnotes

CJです。

vSphere 5.5の End of General Support (2018/09/19) が近づいていることもあり、このタイミングでの移行やそれに伴うバージョンアップを検討されるケースは多くあるのではないでしょうか。 特にバージョンアップの際に実際仮想マシンへの影響度合いも気になるかと思います。

今回は、vSAN基盤のバージョンアップ (ESXi 6.0U3 → 6.5U1) を行う中で、On-Disk フォーマットというプロセスが発生します。Diskに関するところでサービス (仮想マシンの通信)影響が発生するか否かについて共有したいと思います。

ちなみに、On-Disk フォーマットについてはこちらを参照してください。

テストイメージ図

上記のように、同一の vSAN環境 (vsanDatastore) 上で稼動している仮想マシン(CJ01、CJ02)間の疎通 (ping) を行いつつ、On-Diskフォーマットを更新して結果を確認したいと思います。

vSAN設定画面 (更新前)

vCenter > vSAN Cluster > 設定 > vSAN > 全般 > オンディスクフォーマットのバージョン

こちらの画面で “アップグレードの事前チェック” ボタンをクリックする、vSAN内部で更新ができるかどうかをチェックしてくれます。

アップグレード

事前チェックが正常に完了した後、”アップグレード” ボタンをクリック。すると、

アップグレード開始確認画面が表示されるので、”はい” で次へ。

※冗長性の低下を許可を選択すると、更新がなんらかの理由で失敗した場合にデーター損失につながる可能性がありますので、各自の環境に合わせて注意してお使いいただければと思います。

進行内容は以下の通りとなります。

0 ～     5%：クラスタのチェック。
5 ～   10%：ディスク グループのアップグレード。
10 ～ 15%：オブジェクトの再編成。
15 ～ 95%：ディスク グループの削除および再フォーマット。
95～100%：最終的なオブジェクト バージョンのアップグレード。

vSAN設定画面 (更新後)

ご覧のように、ディスクフォーマットのバージョンが更新 (3.0 → 5.0) されていることがわかります。

サービス(通信)影響は？

パケットロスゼロのサービス(通信)影響はありませんでした。

vSAN基盤を更新する上で、忘れがちなところでもある On-Diskフォーマットですが既存フォーマットの違いを理解した上で必要に応じて忘れず更新いただければと思います。

TIP (RVC : 更新ステータス確認方法)

vsan.upgrade_status /localhost/[DATACENTER]/computers/[CLUSTER]

RVCにログイン上、上記コマンドにて更新ステータスが確認できます。

vsan.upgrade_status -r [秒] /localhost/[DATACENTER]/computers/[CLUSTER]

また、秒指定 (min 60秒) をすると、ユーザーが “Ctrl + c” で抜けない限り画面上更新情報を指定秒間出力してくれます。

運用上、ぜひRVCモードもご活用ください。

[参考情報]

vSAN ディスク フォーマットについて

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-08728A9E-88E0-4CEB-9764-E828719DA927.html

Disk format change going from 6.x to vSAN 6.6?

Disk format change going from 6.x to vSAN 6.6?

CJです。

今朝の発表で、vExpert 2018をいただきました。

個人的には今まで取得してきた資格とは違う性質のもので、非常に光栄であり・嬉しく思っております。これからも得た知識・経験を極力わかりやすい形でシェアしていきたいと思います。

よろしくお願いします。

CJです。

vSphere環境上、ISOファイルなどで仮想マシンを作成する場合、まずは ISOファイルをデータストア上にアップロードするかと思います。今まで (vSphere 6.0以下)は、普通にデータストアを参照して、ファイルのアップロードが簡単にできたと思いますが、vSphere6.5では、以下のようなエラーと共にアップロードに失敗することがあるようです。

今回は、このようなエラーに対する対策について共有したいと思います。

原因

今まではブラウザ側で vCenterサーバーの証明書を信頼するだけで十分だったのが、
vSphere6.5では、vCenter Serverの自己証明書が証明書ストアの “信頼されたルート証明機関”にないと、vSphere Web Clientが、vCenter Server とファイルを共有できない・仕組みの変更があるようです。

対策

以下の手順(例.Windows Server)にて、vCenter Serverの自己証明書を “信頼されたルート証明機関” に追加さればOKです。

1. vCenter Server [https://vCenter Server] へ接続し、右下の “信頼されたルート CA 証明書をダウンロード” をクリック

2. ダウンロードしたファイルを展開し、セキュリティ証明書をダブルクリックする

3. 証明書のインポートウィザードより、ローカルコンピューターを選択して次へ

4. 信頼されたルート証明機関を選択

5. 完了

6. 確認

[参考情報]

Uploading files to a vSphere service might fail (2147256)

https://kb.vmware.com/s/article/2147256

vCenter Server ルート証明書をダウンロードしてインストールして、Web ブラウザ証明書の警告を防ぐ方法 (2148936)

https://kb.vmware.com/s/article/2148936

vSphere 6.5 – Unable to upload files to Datastore or deploy OVAs

CJです。

vSAN環境は安定したパフォーマンスを出すため、基本的に同一のもの (ハードウェア、vSphere version/build など) を使うことを推奨とされているようです。

しかし、使用中のハードウェア(Server)・ドライブ(SSD)が生産終了などを向かえ、購入できない状態になったらどうなんでしょうか。　やはり、ユーザーとしては安定した性能・サービスを使い続けたいわけです。

気になるこの問題について、確認してみました。

結論から言うと、混在は可能です！

VMwareさんの storagehubサイトに上記のような内容が掲載されています。

基本、VMware Compatibility Guideに登録されているものであれば、混在は可能です。ただし、注意事項としては 性能のばらつき・EVC対応可否によっては vMotionができなくなるなどのこともおきうるので、十分ご検討の上で進めてもらったほうが良いかと思います。

[参考情報]

vSAN FAQ > Architecture

https://storagehub.vmware.com/t/vmware-vsan/vsan-frequently-asked-questions-faq/architecture

Enhanced vMotion Compatibility (EVC) processor support 

https://kb.vmware.com/s/article/1003212

CJです。

vSANは基本 ESXi バージョンアップに合わせて、様々な改善が行われます。

今年2月にも ESXi 6.0U3がリリースされ、以下のような vSAN性能改善が行われたことが知られています。

Virtual SAN のパフォーマンス：VMware ESXi 6.0 Update 3 リリースでは、I/O パスの最適化を実現するため、複数の修正が加えられています。これにより、オール フラッシュ構成およびハイブリッド構成の Virtual SAN のパフォーマンスが向上します。

リリースノートのこの文面だけでは、実際どれくらい性能が向上されたかがわかり難かったため、性能測定を行い、その結果を共有したいと思います。

テスト環境

いつもの大好きな RAID-6 (Erasure Coding) の vSAN環境となります。

性能測定方法

fio を利用して性能測定 (IOPS)

#同一条件で行ったため、細かいパラメータはスキップします。

テスト結果

1プロセッサーの場合 (1P)  / 4プロセッサーの場合 (4P)

いかがでしょうか。

リリースノートに書いてあったパフォーマンス向上の話は本当であり、かつ1行の説明で終わっているような感もしますが、実は測定結果の通りに大きな改善がありました。念のため、現時点の最新バージョンである ESXi 6.5U1 と比較してもそれほど変わらないこともわかります。これから vSANの使用をご検討の方、ESXi 6.0U3 より前のバージョンを使っている方はぜひ ESXi 6.0U3 以上の使用をご検討いただいたらいかがでしょうか。

CJです。

先日、vSAN環境における RAID-6 にて “VM、Object、Components” の全体的な概要について共有しました。 今日は、その延長となる内容で実際仮想マシンのデータが増えるにつれ、VMの構成要素でもある Object と Component がどのように動作していくのかについて共有したいと思います。

では、早速確認していきましょう。

まず、検証環境はいつもの大好きな RAID-6 構成 (vSAN 6.2) となります。

VM作成前

vsan.obj_status_report /localhost/DCNAME/computers/CLUSTERNAME

RVC上で、こちらのコマンドを実行し、まず VM作成前の Object 数を確認してみました。

本環境には、現在 1 Object が存在し、その Object に 6 Components が存在しているのがわかります。 まだ本環境には VMが1台も存在していないのに、なぜか 1 Objectがすでに存在する状態です。 この 1 Object は vSAN 健全性とパフォーマンスオプションが有効になっていると vsanDatastore上で vsan.statsフォルダができますが、これの Object となります。

次は、1TBのディスク容量を持つ VMを作成してみました。

VM作成 (1TB / Thin)

すると、GUI (vSphere Web Client) 上からは、以下の通りに表示されていることがわかります。

#Object : VM ホーム

#Object : ハードディスク (VMDK)

CUI (RVC) からは、以下の通りに表示されます。

vsan.vm_object_info localhost/DCNAME/vms/VMNAME/

GUI上で表示されていた “VM ホーム” と “ハードディスク” のコンポーネント詳細が表示されます。また、こちらで各コンポーネントの容量も確認できます。

vsan.obj_status_report /localhost/DCNAME/computers/CLUSTERNAME

Object Status Report からも、VMDKや VMホームのコンポーネントが表示されたことがわかります。ところが、RAID-6なのになぜか 1 Object に対して 3 Components になっているものが存在しています。これは、VMを起動すると現れる SWAP object となります。 SWAP object は特別扱いで RAID-6 構成であっても、RAID-1の動き (1 コピー + 1 Witness) をするみたいです。

ここまでの整理

ここまでの状況を簡単に整理すると、以下の通りとなります。

VMを作成すると、

・3つの Object (VMDK、VMホーム、SWAP) ができ、

・各 Object はさらに Component に分割され、

・Componentは VMDKが12個、HOMEが6個、SWAPが3個

であることがわかりました。

VMDKの Component 数は、なぜ 12個？

vSAN仕様上、1つの Object は Component で構成されており、1 Component の最大サイズは 255GB となっています。

今回、1TBディスク (データ) を持つ、VMを作成しましたことを思い出してください。

1TB = 1024GB ですね。

255GB x 4 (Component : データ) = 1020GB となります。

この 1020GBをオーバーするため、不足している分 (1021～1024GB) の Component が増加 (6つ)する動きとなっています。

これを簡単な図で表したのが、次です。

仮想マシンの容量が増えるにつれ、Component のサイズはどうなるの？

仮想マシンの容量が増える (Guest OS 内のデータが増える)と、VMDK Object を構成している各 Component のサイズも均等に増加します。実際、Guest OS内のデータを増やして行く際の Component サイズの変化を表したのが、次です。

各 Component の容量が 127.5GB で均等に分散されているのがわかります。

また、vSANのRAID-6を使う場合に、ディスク使用量が 1.5倍になりますが、きちんと仕様通りの動きになっていることもわかります。#1530GB

Tip: 2TB のVMを作成すると？

Componentの数と容量が増えていることがわかります。

まとめ

いかがでしょうか。

VMの構成要素 (Object & Component) とそれらの増加タイミング、数、容量などの変化が起きる仕組みがお分かりになりました？vSAN ならではの仕様でもあるため、なんとなくわかっても綺麗に整理できなかった方々に本記事が少しでも役に立てればと思います。

[参考情報]

SWAP Object について

http://www.yellow-bricks.com/category/storage/page/2/

vSAN Objects and Component Placement

Understanding vSAN Rebuilds and Repairs

CJです。

vSAN6.6で新たに暗号化機能が追加されたこと、知っていますか。

vSANでは、2つタイプの暗号化機能が追加されています。

そのひとつ目は、仮想マシンストレージポリシーを使って VMごとに適用することができる ” VM 暗号化”、二つ目は、トランジットが発生していない時に vsanDatastore 全体を暗号化する “vsanDatastore 暗号化” です。

今日はそのうち vsanDatastore 暗号化機能をどうやって有効化するかについて共有したいと思います。

テスト環境情報

・vSAN 6.6.1 (ESXi 6.5 U1)

・Key Management Server (以下、KMS）： HyTrust KeyControl

1. まずは、VCGの確認から

暗号化機能を使うためには、KMSサーバーが必須となります。

もちろん、vSAN環境なので既存のパーツと同じく、KMSサーバー自体も VCGにて管理されています。 このリスト上に掲載されているものからお使いください。

自分は、VMworldなどでも紹介されたりした HyTrustさんの KMSサーバーを使うことにしました。

2. KMSサーバーのデプロィ

vCenter と同一のネットワーク上に、KMSサーバーをデプロィします。

HyTrustさんからは、OVA 形式で仮想アプライアンスが提供されており、自分はこちらを使っています。#ISO形式でも提供されています。

また、KMSサーバーのシステム要件としては Standard基準として以下が求められています。

・2cpu / 8GB RAM / 20GB HDD

このように、必要なパラメーターを入力して、KMS仮想アプライアンスをデプロィします。

3. KMSサーバーの構成

vCenter (Windows版)より、HyTrust KMSサーバーへIEより接続します。

初回はデフォルトの “secroot / secroot” にてアクセス可能です。

ログイン直後に、パスワード変更が求められますので、パスワードの更新を行ってください。

KMIP構成画面より、Stateの有効化および VCGに掲載されていた Versionに合わせて設定を行います。

KMIP構成後は、Users > Create User にてユーザーを作成してください。

※本手順ではユーザーのパスワード入力なしにしてあります。

ユーザー作成後は、Actions > Download Certificate にて証明書を保存してください。後ほど vCenter にKMSサーバーを登録する際に使います。

保存した zipファイルを展開すると、上記のように2つのファイルがあります。

このうち、後ほどvCenter側で使うのは左側のファイル (KMIPUser.pem)となります。

4. vCenter に KMSサーバーを登録

KMSサーバーの準備ができたため、次は vCenterサーバーに KMSサーバーの登録を行います。 vCenter > 設定 > 詳細 > キー管理サーバー > KMSの追加

この後、引き続き信頼の確立を行い、”証明書およびプライベートキーのアップロード”を選択してください。

証明書とプライベートキーをアップロードするところが表示されたら、事前に保存しておいたユーザー証明書・キーファイル (KMIPUser.pem) をアップロードしてください。

証明書登録後も、接続状態が “正常” にならない場合があります。

※その際は、”すべてのアクション”メニューより、証明書の信頼アクションを実施すると改善されます。

5. vSAN 暗号化の有効化

これですべての準備が完了しました。

最後は、vSANクラスタの暗号化機能を有効にするだけです。

クラスタ > 設定 > vSAN > 全般 > vSAN設定の編集 > 暗号化 : チェックイン

そうすると、ディスクフォーマットが動作し、ディスクグループの再作成が行われます。

終わった後は、以下の通りに暗号化機能が有効になっていることがわかります。

ちなみに、vsanDatastore の暗号化によるパフォーマンス影響はほとんどないようです。

#CPUの負荷としては、5～15%程度。

まとめ

いかがでしょうか。

上記の4ステップだけで、vSAN 暗号化機能が簡単に使えるようになります。

既存のハードウェア製暗号化ソリューションに比べて、vSAN上で簡単な設定を行うだけで、セキュリティを高めることができるのはとても嬉しいです。

ぜひ、一度 vSANの暗号化機能をお試しください。

※KMSサーバーおよび vSAN暗号化を有効にするためには、それぞれに該当する適切なライセンスを購入・適用してください。詳しくは各KMSベンダーへお問い合わせください。

[参考情報]

vSAN クラスタでの暗号化の使用

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-F3B2714F-3406-48E7-AC2D-3677355C94D3.html

HyTrust KeyControl with VMware vSphere VM and VSAN Encryption

https://docs.hytrust.com/DataControl/Admin_Guide-4.0/Default.htm#Books/VMware-vSphere-VSAN-Encryption/aaTitle-KeyCtrl-for-vmware-encrypt.htm%3FTocPath%3DHyTrust%2520KeyControl%2520with%2520VMware%2520vSphere%2520VM%2520and%2520VSAN%2520Encryption%7C_____0