On-Disk フォーマット更新時のサービス影響は?

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?

vExpert 2018をいただきました。

CJです。

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

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

よろしくお願いします。

vSphere6.5環境で、データストアにファイルアップロードができない場合は?

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

vSAN環境において異なる機種の混在は可能なのか?

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

ESXiバージョン別の vSAN 性能を比較してみると?

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 以上の使用をご検討いただいたらいかがでしょうか。

 

vSAN 仮想マシンの容量が増えるにつれ、ObjectとComponentに起きる変化とは?

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

vSAN 暗号化機能を使うには?

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

 

 

vSAN のバージョンを確認するには?

CJです。

vSAN環境を運用していると、使える機能や制限事項などの確認のためにバージョン情報を確認したくなる場合があります。その際に有効な確認方法を共有したいと思います。

バージョンの考え方

vSANはHypervisor (ESXi) に予め組み込まれているもののため、基本的な考え方としては ESXi バージョンによって vSANのバージョンも変更される形になります。 イメージとしては以下のとおりです。

 

とてもシンプルでわかりやすい考え方だと思います。

# vSANバージョンごとの機能の違いはこちらの記事を参考にしてください。

vSphere 環境上での確認方法

では、実際 vSphere Web Client または PowerCLI などで明確にバージョンを確認する方法はないか気になる方もいると思います。 確認方法はあります。

まず、GUI (vSphere Web Client) 上では、クラスタ画面上でも、ホスト画面上でも特にvSANのバージョン情報は見当たらなかったです。個人的にはクラスタ or ホストのサマリページに表示されたら嬉しいと思いますが、とにかくないようです。

#もし、GUI上での確認方法がわかる方はお知らせください。

念のため、esxcli コマンドにても確認してみましたが、やはり明確な vSANバージョンは確認できないようです。

esxcli system version get

色々調べてみると、VMware社の社員である “William Lam”さんが、PowerCLIで確認できるスクリプトをすでに作成し、配布していましたのでそちらを使います。

#Thanks @lamw

早速、該当スクリプトファイルをダウンロードし、ローカルに配置してください。

自分の環境は Windows Server のローカルドライブ(D:)に配置しておきました。

次は、PowerShellを起動して、配置しておいたスクリプトをインポートします。

Import-Module -Name “D:\CJ\VCESXivSANBuildVersion.ps1”

そうると、モジュールがインポートされ、”Get-VSAN タブキー入力” で Get-VSANversion というコマンドレットが表示されることがわかります。これでバージョン確認の準備が完了しました。

実際、”Get-VSANversion” コマンドレットを使うために、vCenterサーバーへアクセスします。 #こちらのテスト環境では、localhost 指定にしています。ご自身の環境に合わせて適切に変更してください。

Connect-VIServer -Server localhost

では、早速スクリプトを実行してみましょう。

Get-VSANversion -ClusterName vSAN-CJ

きちんと、想定していた vSANの明確なバージョン情報が確認できました。

ちなみに、スクリプトの中身にも書いてありますが、こちらのバージョン情報は VMwareKBで公開されているバージョン情報をソースとしてあります。

また、本スクリプトは vSANだけではなく、ESXiやvCenterのバージョン情報も確認できますので、必要に応じて活用してみてください。

 

[参考情報]

PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup

PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup

Github:lamw/vghetto-scripts/powershell/VCESXivSANBuildVersion.ps1
https://github.com/lamw/vghetto-scripts/blob/master/powershell/VCESXivSANBuildVersion.ps1

Build numbers and versions of VMware ESXi/ESX (2143832)
https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2143832

Build numbers and versions of VMware vCenter Server (2143838)
https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2143838

Build numbers and versions of VMware vSAN (2150753)
https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2150753&sliceId=1&docTypeID=DT_KB_1_1&dialogID=460798501&stateId=1 0 460808158

フォワードプロキシを使ってHCLデータベースを更新するには?

CJです。

 

vSAN環境には、HCLデータベースという概念が含まれていること、知っていますか?

vSAN環境は、VMware社がハードウェア・ドライバー・ファームウェアなどの構成を厳しく管理しており、VMware社内でのテストが完了したもののみ、Certifiedされています。

#このような情報は、VMware Compatibility Guide 上から確認できます。

このようなハードウェア互換性の情報はもちろん継続的に更新が行われており、

vSAN内でも継続的に更新される互換性情報が取得される仕組みが入っています。

それが、こちらのHCLデータベースとなります。

こちらのHCLデータベースを更新するには、2つの方法があります。

・手動:ファイルから行う方法

・自動:インターネットから直接更新ファイルをゲットする方法

手動でファイルから更新を行う場合、データソースは以下のURLよりダウンロードできます。

https://partnerweb.vmware.com/service/vsan/all.json

せっかくなので、ダウンロードしたHCL更新ファイル (all.json)の中身をみると、

このように、各ベンダー・ESXiバージョンなどのデータソースが更新されていることがわかります。

これをみると、やはりHCLデータベースはボタン一発の自動更新を行ったほうが当然楽です。しかし、vSphere環境を管理するサーバーのセキュリティを高めるため、直接インターネットに繋がらないように構成して運用するところも多いのではないでしょうか。

この場合は、Proxyサーバーを経由すると効果的です。

また、vSANにもこのようなシナリオにも対応できるように、proxy構成オプションも予め用意されています。 構成イメージは以下のとおりです。

vCenterより、以下の項目で設定が可能です。

クラスタ > 管理 > 設定 > Virtual SAN (全般) > インターネット接続

参考 : vSphere 6.0u3 (vSAN6.2) 環境であり、proxy サーバー(CentOS6)は mod_proxy を使って事前にフォワードプロキシ設定が済んでいる状態です。

設定しておいた Proxyサーバーのホスト名およびポート番号を入力してください。

設定したプロキシサーバーの情報が反映されていることがわかります。

vSphere環境上での設定はこれで終わりです。とても簡単ですね。

では、早速自動更新をクリックして、プロキシサーバーHCLデータベースの更新リクエストが来ているかを確認しましょう。

# tail -f /var/log/httpd/access_log

きちんとプロキシサーバーにリクエストが来ていることがわかります。

また、更新ファイルも手動でダウンロードする URLと同じであることがわかります。

念のため、エラーログは出てないかを確認しましょう。

なんと、このようなエラーが出ています。

Response header ‘Set-Cookie’ value of ‘___utm…省略..’ contains invalid characters, aborting request

Set-Cookieの値に、有効ではない文字が入っているようで更新ができなかったようです。

今回、HCLデータベース更新が目的なので、特に Set-Cookie は気にせず無効にすることに。

# vi /etc/httpd/conf/httpd.conf

Header unset Set-Cookie

これで、再度HCLデータベースの更新を実行すると、Proxyサーバー側にリクエストも来ており、エラーも出ず、正常にHCLデータベースが更新されたことが確認できました。

 

以上、同じく Proxyサーバー経由でかつ Response heade 問題で引っかかっている方がいれば、本記事が少しでも役に立てれば嬉しいです。

 

[参考情報]

Updating the vSAN HCL database manually (2145116)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2145116

 

vSAN環境で L3-vMotion を行うには?

CJです。

vSphere 6環境において L3経由での vMotionが行えること、知っていますか?

構成によって、L3 vMotionを使用するケースもあると思います。

今回はそういったことが、実際可能かどうか、せっかくなので vSAN環境上で試した結果を共有したいと思います。

 

まず、想定している検証の構成は以下のとおりです。

今回、表側の分散スイッチ経由で vMotionを行うテスト内容となります。合わせて dvPort は予め作成されていることを前提としています。

環境構成

・vCenter 1つの配下に、CLUSTERが 2つ(AとB)存在し、各クラスタは vSAN構成が有効になっています。

・CLUSTER_A(vSAN)上で動いている仮想マシン(CJ_VM01)が、L3経由で CLUSTER_Bへ vMotionを行います。

・L3は vyOSを利用します。

・Version 情報: vSAN 6.2、CentOS6 (CJ_VM01)、vyOS(1.1.7)

 

 

では、早速各パーツごとに設定を見ていきましょう。

仮想マシン (CJ_VM01)

普通にネットワークインターフェースに適切な IPアドレスの設定を行う。

クラスタA側のvyOS (CJ_vyOS1)

各インターフェースの設定を行い、その後スタティックルーティングを行う。

#vyOS設定後、#commit と #save も忘れずに~ (ここでは省略しています。)

クラスタB側のvyOS (CJ_VYOS2)

構成に合わせて各インターフェースの設定を行い、その後スタティックルーティングを行う。

VMkernelの追加 & TCP/IP スタック (vSphere)

vMotion用の VMkernelアダプタを両クラスタの各ESXi に追加する。

TCP/IP スタック設定で、vMotion 用 VMkernel のゲートウェイの設定を行う。

TCP/IP スタック (vMotion) に、IPv4 ゲートウェイが設定されていることがわかります。

これで、設定は完了です。 後は移行(vMotion)を試してみてください。

自分のテスト環境においては、vSANデータストアの移行を含め、仮想マシンが正常に vMotionができることが確認できました。

 

普段、vSphere 環境で vMotionは L2接続状態の環境で使うことが多いかと思いますが、移行のシナリオなど各自の状況によっては L3を経由するシナリオが出て来るかもしれないです。その際には、本記事が少しでもお役に立てればと思います。

 

[参考情報]

ESXi ホストの vMotion TCP/IP スタックへの vMotion トラフィックの配置
https://docs.vmware.com/jp/VMware-vSphere/6.0/com.vmware.vsphere.vcenterhost.doc/GUID-5211FD4B-256B-4D9F-B5A2-F697A814BF64.html

Configuring the vMotion TCP/IP Stack for Layer 3 vMotion Across ESXi Hosts

Configuring the vMotion TCP/IP Stack for Layer 3 vMotion Across ESXi Hosts