2021年1月15日金曜日

Flash 版 vSphere Web Client 接続端末を Windows Server 2016 で今から新規に作る方法 (Flash EOL その場しのぎの回避方法)

とうとう 2020/12/31 で Adobe Flash のサポートが終了し、2021/1/12 以降はインストール済みの Flash の起動も基本的に実行不可となりました。

※ 古い OS 環境で Flash 32.0.0.371 以前のバージョンなら 2021/1/12 以降起動できなくなる設定を回避できますが、これからの入手は実質不可でインターネット上に落ちているバイナリは改変・改竄されているリスクがあるので絶対にインストールしないでください。

(この後ご紹介する方法は Windows Server 2016 組み込みの Flash を利用する事で回避していますが、当然非推奨かつセキュリティリスクがある運用なのでご注意下さい)

vSphere 6.x の環境も、全ての機能が移行された vCenter 6.7u3 以降の HTML5 版 vSphere Client が使えない場合は従来の Flash 版 vSphere Web Client が必要になる事が多々あるかと思います。

公式には以下の KB と、VMware Japan Blog の方にも回避策が案内されていますが、今後の Web ブラウザのバージョンアップなどでそもそも Flash が全く利用不可になる日も近いと思います。

Windows Server 2016 を新規インストールして臨時の Flash 版Web Client 端末にする

新規に Windows Server 2016 をインストールするとその中には RDSH 用に Flash のバイナリも含まれています。
それを Windows Server 2016 本体にインストールして Flash Web Client を緊急利用する回避策をご紹介します。

※ 手元の環境で確認したところ Flash のバージョンは 22.0.0.209 とかなり古い。
OS のアップデート未適用の運用もそうですが、Flash 自体のセキュリティリスクがあるので本来はこれらの利用は強く非推奨です。

Windows Server 2016 インストーラの入手

幸い、2021年1月時点でも Microsoft の Evaluation Center では Windows Server 2016 の評価版の入手が可能です。

180日の評価版の ISO (または他のフォーマット) を入手し、インストールします。
※ このメディアでインストールした場合、180 日の評価版の終了後も 6 回の rearm が出来るので実質3年くらい使えたりします。

この後、Windows Update などしてしまうと Flash の実行が塞がれてしまうので注意してください。

Windows Server 2016 自身に組み込まれた Flash を有効化する

方法は MS のナレッジにて説明されています。

管理者権限で以下を実行します。

 PS C:\> dism /online /add-package /packagepath:"C:\Windows\servicing\Packages\Adobe-Flash-For-Windows-Package~31bf3856ad364e35~amd64~~10.0.14393.0.mum"
 

すると RDSH 用に組み込まれている Flash が本体で利用できる様になります。



バージョンは 22.0.0.209、セキュリティリスクがあるので本来は利用する事は強く非推奨です。
Flash を IE で有効化した後に Flash 版 vSphere Web Client にアクセスしてみると、2021/1/12 を過ぎても画面の起動が出来ました。

緊急で Flash 版 vSphere Web Client にアクセスしたいが利用できる端末やブラウザが無くて困った、という時の回避策として覚えておいて損はないと思います。

しかしこの運用はセキュリティリスクを伴うので、なるべく早めに HTML5 vSphere Client で機能がフルカバーされる vCenter 6.7u3 以降へのバージョンアップを推奨します。

2021年1月9日土曜日

PowerCLI で vSphere Clustering Service (vCLS) の起動停止をする方法

 vSphere 7.0u1 から DRS などのクラスタ制御機能が vCenter から vCLS (vSphere Cluster Services) に移管され、vCLS そのものの有効化・無効化 (Retreat Mode) の操作方法を昨年以下の記事にまとめました。

今回はクラスタの計画停止や UPS などのシャットダウンツールの連動などで vCLS Retreat Mode の切り替えを PowerCLI でスクリプトを組むための方法をまとめます。

※ 作業前に必ず KB も併せて確認して下さい。

PowerCLI でクラスタの Domain ID を確認する

まずは vCenter に接続。この後 AdvancedSetting の設定で使うので $vc に入れておきます。

$cre = Get-Credential
$vc = Connect-VIServer -Server "vCenter IP or FQDN" -Credential $cre
 

続いて Get-Cluster でクラスタの情報を取得してみます。

PS C:\> Get-Cluster | Format-Table -AutoSize

Name      HAEnabled HAFailoverLevel DrsEnabled DrsAutomationLevel
----      --------- --------------- ---------- ------------------
vSAN      True      1               True       FullyAutomated
Nested-CL False     1               False      FullyAutomated
PCL       False     1               True       Manual
 

デフォルトの出力だと Domain ID が分からないので、Format-List するか、Select-Object で "ID" を含めます。

PS C:\>  Get-Cluster | Select-Object Name,Id |Format-Table -AutoSize

Name      Id
----      --
vSAN      ClusterComputeResource-domain-c3012
Nested-CL ClusterComputeResource-domain-c3006
PCL       ClusterComputeResource-domain-c8
 

ID は "ClusterComputeResource-domain-cXXXX" となり、URL に含まれる Domain ID と同じものを確認できます。

vCLS Retreat Mode に関する詳細設定を PowerCLI で作成・制御する

前回は vSphere Client で追加した "config.vcls.clusters.domain-cXXXX.enabled" を PowerCLI で操作します。

現在の vCLS Retreat Mode に関連する詳細設定(Advanced Settings)の有無を確認します。

PS C:\> Get-AdvancedSetting -Entity $vc -Name config.vcls.clusters.* | Format-Table -AutoSize

Name                                      Value Type     Description
----                                      ----- ----     -----------
config.vcls.clusters.domain-c8.enabled    false VIServer
config.vcls.clusters.domain-c3006.enabled false VIServer
 

先ほど新規で作成した "vSAN" クラスタの ID は未作成なので、これを新規に New-AdvancedSetting で追加します(削除は vCSA 内の vpxd.cfg を修正する必要があるので値が正しい事を必ずチェックしてください)。"vSAN" クラスタの Domain ID は "domain-c3012" なので "config.vcls.clusters.domain-c3012.enabled" を追加します。

PS C:\> New-AdvancedSetting -Entity $vc -Name config.vcls.clusters.domain-c3012.enabled -Value false
 

Retreat Mode の On/Off は Set-AdvancedSetting から true / false で制御します。

  • true なら Retreat Mode が無効 (vCLS が 有効 : vCLS VM が作成される)
  • false なら Retreat Mode が有効 (vCLS が無効 : vCLS VM が削除される)
# vCLS 有効化
PS C:\> Get-AdvancedSetting -Entity $vc -Name config.vcls.clusters.domain-c3012.enabled | Set-AdvancedSetting -Value true

# vCLS 無効化 (Retreat Mode 有効化)
PS C:\> Get-AdvancedSetting -Entity $vc -Name config.vcls.clusters.domain-c3012.enabled | Set-AdvancedSetting -Value false
 

有効・無効が正しく反映されている事を確認します。

# 各クラスタの vCLS の状態を確認 (全て Retreat Mode 有効状態)
PS C:\> Get-AdvancedSetting -Entity $vc -Name config.vcls.clusters.* | Format-Table -AutoSize

Name                                      Value Type     Description
----                                      ----- ----     -----------
config.vcls.clusters.domain-c8.enabled    false VIServer
config.vcls.clusters.domain-c3012.enabled false VIServer
config.vcls.clusters.domain-c3006.enabled false VIServer


# "vSAN" クラスタ (domain-c3012)の Retreat Mode を無効化 (vCLS の有効化)
PS C:\> Get-AdvancedSetting -Entity $vc -Name config.vcls.clusters.domain-c3012.enabled | Set-AdvancedSetting -Value true

# "vSAN" クラスタ (domain-c3012) のみ vCLS が有効になった事が確認できる
PS C:\> Get-AdvancedSetting -Entity $vc -Name config.vcls.clusters.* | Format-Table -AutoSize

Name                                      Value Type     Description
----                                      ----- ----     -----------
config.vcls.clusters.domain-c8.enabled    false VIServer
config.vcls.clusters.domain-c3012.enabled true  VIServer  ← true に変更される
config.vcls.clusters.domain-c3006.enabled false VIServer
 

vCenter の詳細設定の操作は間違えるとシステムに大きな影響を与えるため慎重に行ってください。

以上、PowerCLI を利用して vCLS Retreat Mode を起動停止してみました。

2021年1月8日金曜日

vCenter を跨いだ仮想マシンの移行方法あれこれ (Advanced Cross vCenter vMotion の利用条件について)

2020年12月にリリースされた vCenter 7.0u1c で実装された "Advanced Cross vCenter Server vMotion (Migration)" により、vSphere Clinent の GUI から異なる vCenter 間での vMotion が可能になりました。

※ 従来は SSO ドメインの異なる vCenter 間では PowerCLI などから vCenter API を叩く必要がありました。

今回は新機能の "Advanced Cross vCenter Server vMotion (Migration)"  含めて、現在利用可能な仮想マシンの移行機能をご紹介、試してみたいと思います。

"Advanced Cross vCenter Server vMotion (Migration)" に関する公式情報は以下を参照ください。

※ 本投稿で動作確認したものは全ての環境で同様に動く事を保証するものではありません。本番環境での移行を検討する場合は必ずサポートされた構成で事前検証を実施してください。

今回の内容です。

vCenter を跨いだ仮想マシンの移行方法

vCenter を跨いだ仮想マシンの移行方法にはいくつか方法があります。
  • 仮想マシンを起動した状態での移行(vMotion 系)
    • (1) 同一 vCenter 配下での vMotion
    • (2) 同一 SSO 下の vCenter 間での vMotion (vCenter 拡張 Linked Mode 間での  Cross vCenter vMotion、従来から vSphere Client で実施可能)
    • (3) 異なる SSO の vCenter 間での vMotion (Cross vCenter vMotion without SSO、従来は PowerCLI などが必要) → 今回の Advanced Cross vCenter vMotion の強化ポイント
    • (4) クロスクラウド間での vMotion (HCX vMotion など別ライセンス・専用ツールが必要)
  • 仮想マシンの停止を伴う移行 (移行元での停止や移行先での再起動が必要な方法)
    • (5) 異なる vCenter 間で vSphere Client を利用しての Advanced Cross vCenter Migration → 今回の強化ポイント
    • (6) vSphere Replication (+SRM) を利用した異なる vCenter 間での移行 (クラウドや遠隔地移行に最適、SRM と組み合わせた半自動化も可)
    • (7) OVF/OVA テンプレートへエクスポート・インポートする(要 VM 停止)
    • (8) vCenter Converter Standalone を利用したエクスポート・インポート(要 VM 停止、現在は開発終了)
    • (9) 外部データストアを双方のクラスタでマウントして vCenter 間で仮想マシンのインベントリを付け替え (要 VM 停止、手動でのインベントリ操作)
    • (10) 3rd Party バックアップソフトウェアやレプリケーションツールを利用した移行
今回は上記太字の "Advanced Cross vCenter Server vMotion (Migration)" に関して試した事を中心にまとめたいと思います。

vMotion の種類について

vMotion には従来からのクラスタ内の仮想マシンのオンラインマイグレーションの他、vSphere 6.0 から実装された vCenter を跨いだ Cross vCenter vMotion (XvC-vMotion)、VMware HCX を利用した Cross Cloud vMotion などがあります。
(異なる仮想スイッチ間の移行をサポートする Cross vSwitch vMotion や L3 ネットワーク跨ぎの vMotion は vSphere 6.0 からサポート)

"Advanced Cross vCenter Server vMotion (Migration)" では異なる SSO ドメインの vCenter を跨いでの vMotion が vSphere Client を利用して操作する事が可能になりました。
それぞれの違いを簡単にイメージにまとめました。

通常の vMotion : クラスタ内 vMotion、クラスタ間 vMotion

  • vSphere Client または PowerCLI などで操作可能
  • vSphere 6.x 以降では Cross vSwitch vMotion もサポート
  • vSphere Standard で利用可能

同一 SSO ドメイン (vCenter 拡張リンクモード) 間の Cross vCenter vMotion

  • vSphere Client または PowerCLI などで操作可能
  • 要 vSphere Enterprise Plus 相当のエディション

異なる SSO ドメイン間の Cross vCenter vMotion

  • vCenter 7.0u1a までは PowerCLI などで操作可能 (vSphere Client など GUI は非対応だが、Flings のツール Cross vCenter Workload Migration Utility を利用する事で操作可能。7.0u1c からはこの機能が組み込まれた)
  • 要 vSphere Enterprise Plus 相当のエディション

Advanced Cross vCenter vMotion (Migration) で出来る様になった事

今回幾つかドキュメントに正式に記載がない事含めて試してみました。
  • vCenter 7.0u1c からは "Advanced Cross vCenter Server vMotion (Migration)" が vSphere Client で操作可能に
  • Cross vCenter vMotion (ライブマイグレーション) には 要  vSphere Enterprise Plus 相当のエディション
  • Cross vCenter Migration (コールドマイグレーション) の場合は vSphere Standard でも OK
  • vCenter 6.5 / 6.7 の環境との移行がサポートされる様子 (vCenter 6.0u3 の環境は GUI 上にインベントリが表示されず利用不可)

別の vCenter から仮想マシンを移行する「Import」機能
インベントリツリーの任意の箇所からメニュー(右クリックメニュー等)を開くと「Import VMs」というオプションが追加されています。


別の vCenter へ仮想マシンを移行する「Export」機能
Export の機能は従来の「移行(vMotion)」のメニューに新たに「Cross vCenter Server export」というオプションが追加されています(vCenter 7.0u1c 時点では日本語化が追い付いていませんでした)

それぞれのメニューを進めていくと接続先の vCenter のアドレスと認証情報を最初に入力します。

入力した情報は vSphere Client をログアウトするまで保持され、vSphere Client からログアウトすると再度入力が必要となります。

「Import」の場合は移行元のインベントリリストが表示され、複数の仮想マシンを選択して移行する事も可能。

残念ながら今回の新機能は vCenter 6.5 以降との接続がサポート対象で、vSphere 6.0 環境は相互運用性マトリックスに記載された通りサポート外でした。
※ vCenter 6.0u3 には認証は通るがインベントリ情報が表示されない。

但し、従来通り PowerCLI を利用した場合は vSphere 6.0u3 環境から vSphere 7.0u1 環境へ vMotion / コールドマイグレーションともに実行できましたので、既存の vSphere 6.0u3 環境からマイグレーションしたいという場合には PowerCLI での移行が今のところ可能となります。

Cross vCenter vMotion を行うための要件・制限・考慮事項

Cross vCenter vMotion は同一 SSO、異なる SSO ともに、幾つかの要件・制限・考慮事項があります。特に以下のポイントはご注意下さい。
  • 通常の vMotion と同じくクラスタの EVC レベルは揃える事 
    • 下位 EVC → 上位 EVC への移行は可能だが、サーバーモデル・CPU モデル、環境によっては時折 NG な場合も起きうるので揃っている方が無難
    • 6.7 以降で VM レベル EVC (Per-VM EVC) を利用する場合は vCenter 間の移行時に EVC 設定が保持され、移行のハードルを下げてくれるのでお勧め
  • 双方の vSphere Edition は Enterprise Plus 相当である事
  • vDS to vDS 間の移行時には vDS のバージョンを揃える事
  • vDS to vSS への移行はできない
  • 少なくとも既存の vSphere バージョンは 6.0u3 以上である事
各詳細情報は以下の KB などにまとまっております。

Standard Edition の場合のエラー

vSphere Client では以下の様なエラー
※コールドマイグレーションなら Standard Edition でもエラーは出ない

PowerCLI では以下の様なエラー
PS C:\> Move-VM -VM $vm -Destination $esxi -Datastore $ds -PortGroup $pg

Move-VM : 2021/01/06 15:08:31   Move-VM The operation for the entity "VM" failed with the following message: "License not available to perform the operation.". 
The VMware vSphere 6 Standard license for Host esxi60u3-01.vx.local does not include Cross Virtual Center vMotion. Upgrade the license.
 

vDS のバージョン違いなどネットワーク系のエラー

既定の設定では vMotion 時の仮想マシンネットワークは vSS → vSS、vSS → vDS、vDS → vDS (同一バージョン) のみがサポートされ、
vDS のバージョン違いや、vDS → vSS はエラーとなりますのでご注意下さい。

※ 双方の環境で vDS のバージョンが揃えられない場合は KB : https://kb.vmware.com/s/article/79446 を参照の上、vCenter の詳細設定に追加する事で回避も可能です。
詳細は後述  vDS のバージョンが異なるクラスタ間での vMotion を実施する に手順をまとめてあります。

vDS → vDS のバージョン違い時のエラー

vDS → vSS 時のエラー

コールドマイグレーションの場合は vDS → vDS のバージョン違いがあっても警告のみで移行は行えます。

仮想マシンハードウェアバージョンがサポートされない場合のエラー

上位のバージョンのクラスタから下位のバージョンのクラスタに移行する仮想マシンは、ハードウェアバージョンがサポートされる必要があります。
下位バージョンのクラスタに移行する可能性がある場合はハードウェアバージョンを上げずに運用してください。

"仮想マシンのバージョンが、ホスト「<ESXi>」とのバージョン互換性を持ちません"

Per-VM EVC など vSphere 6.7 から利用できる機能を使う場合は HW Version 14 以上が必要ですが、その場合は下位の vSphere 6.5 への移行が不可となるので注意してください。

EVC レベルが合わず移行できない場合のエラー

クラスタ間で EVC レベルが異なり、特に上位の EVC レベルから 下位の EVC レベルのクラスタに vMotion する場合はエラーとなります。

"ターゲットホストは仮想マシンの現在のハードウェア要件をサポートしていません"

vSphere 6.7 以降であれば Per-VM EVC を利用する事が可能ですので、クラスタ間の EVC を揃えられない時は Per-VM EVC の利用が役立ちます。

Advanced Cross vCenter Server vMotion (Migration) を試してみる

今回の新機能は異なる SSO ドメインに属する vCenter 間での Advanced Cross vCenter Migration (コールドマイグレーション) と Advanced Cross vCenter vMotion (ホットマイグレーション) の二つの移行をサポートします。  

検証で用意した環境は以下の4つのバージョンのクラスタ (旧バージョンは My VMware でダウンロード可能な各最新のバイナリ) に、エディションや vSwitch の違い、仮想ハードウェアバージョンの違いを用意してそれぞれの環境間での vMotion / Migration を試してみました。
  • vCenter 7.0u1c 環境 (vSphere ESXi 7.0u1)
    • vSphere Standard / vSphere Enterprise Plus
    • vSS / vDS 6.6
  • vCenter 6.7u3b 環境 (vSphere ESXi 6.7u3)
    • vSphere Standard / vSphere Enterprise Plus
    • vSS / vDS 6.6
    • 仮想 HW バージョン 15
  • vCenter 6.5u3a 環境 (vSphere ESXi 6.5u3)
    • vSphere Standard / vSphere Enterprise Plus
    • vSS / vDS 6.5
    • 仮想 HW バージョン 13
  • vCenter 6.0u3a 環境 (vSphere ESXi 6.0u3)
    • vSphere Standard / vSphere Enterprise Plus
    • vSS / vDS 6.0
    • 仮想 HW バージョン 11

Advanced Cross vCenter Migration (コールドマイグレーション)

  • コールドマイグレーションの場合は、Import / Export ともに双方のクラスタ環境が vSphere Standard でも OK
  • vCenter 7.0u1c の vSphere Client を利用して移行が可能だったのは vCenter 6.5 以降となる様で、vCenter 6.0u3 は対象外
    • PowerCLI を利用した場合は 6.0u3 環境から 7.0u1 環境へコールドマイグレーションは可能
  • コールドマイグレーションの利点は、vDS のバージョンがクラスタ間で異なっている場合も UI 上は警告が表示されますが、問題なく移行出来て移行完了後の起動も問題ない
    一時的なシステムの停止が可能であればコールドマイグレーションの方が転送も早く進み、vDS のバージョン違いも吸収できる利点がある
  • コールドマイグレーションの場合は vMotion ネットワークが双方のクラスタで疎通できなくても管理ネットワークがつながれば移行可能

Advanced Cross vCenter vMotion (ホットマイグレーション) 

  • Cross vCenter vMotion では vSphere Enterprise Plus のライセンスが双方のクラスタに必須 (厳密にいうと移行時に VM が配置されたホストと移行先のホストに必須)
  • 仮想マシンネットワークは vSS → vSS、 vSS → vDS、 vDS → vDS (双方同一バージョン) での移行が可能。
  • vCenter 7.0u1c の vSphere Client を利用して移行が可能だったのは vCenter 6.5 以降となる様で、vCenter 6.0u3 は対象外
    • PowerCLI を利用した場合は 6.0u3 環境から 7.0u1 環境への vMotion は可能 (私の環境では実行できましたが正式にサポートされるものとは限らない)

Storage vMotion を伴わない Cross vCenter vMotion


共有データストアを新旧の vSphere Cluster でマウントしている場合、vCenter を跨ぐ移行であってもデータの移行は行われないため非常に高速な Cross vCenter vMotion が可能です。
NFS データストアなどネットワークストレージを活用して移行時のインパクトを抑え、vMotion の後に改めて新しいストレージ領域に Storage vMotion を行うといった事も可能です。

PowerCLI を利用した Cross vCenter vMotion / Migration

PowerCLI を利用した仮想マシンの移行は通常の vMotion と同じく Move-VM コマンドレットを利用します。
これも vSphere Client を利用した Cross vCenter vMotion と同じく、共有ストレージの有り無しともに移行が可能です。

Cross vCenter vMotion with Storage vMotion

Cross vCenter vMotion with Shared Storage

上記の2パターンの図に Move-VM に渡す値を $XX で取り込んでいますが、
ポイントは移行元、移行先の双方の vCenter に Connect-VIServer コマンドレットで接続しておき、
移行元の vCenter から対象の VM を指定、
移行先の vCenter から配置先のホスト(またはクラスタやリソースプール)、接続先 ポートグループ、保存先データストアなどを渡してあげるだけです。

※ vNIC の数や VMDK が複数別のデータストアへの格納が必要な場合には個別の設定が必要なので注意下さい。
Advanced Cross vCenter vMotion / Migration では複雑な構成の仮想マシンの移行も GUI で適切に設定できるので非常に便利だと思います。

PowerCLI を利用した VM の移行のサンプルは以下の様な形になります。
PS C:\> Connect-VIServer -Server "Old-vCenter" -Credential $cre
PS C:\> Connect-VIServer -Server "New-vCenter" -Credential $cre
PS C:\> 
PS C:\> $vm = Get-VM -Server "Old-vCenter" -Name "VM Name"
PS C:\> $ds = Get-Datastore -Server "New-vCenter" -Name "Target Datastore"
PS C:\> $pg = Get-VDSwitch -Server "New-vCenter" | Get-VDPortgroup -Name "Target PortGroup"
PS C:\> $esxi = Get-VMHost -Server "New-vCenter" -name "Target Host"
PS C:\> 
PS C:\> Move-VM -VM $vm -Destination $esxi -Datastore $ds -PortGroup $pg
 
より詳細な設定については Move-VM コマンドレットのヘルプや公式のリファレンス(URL)を参照ください。

PowerCLI のインストール方法や vCenter への接続方法は本ブログで過去にいくつか投稿しているので併せて参照願います。

vDS のバージョンが異なるクラスタ間での vMotion を実施する

双方の環境で vDS のバージョンが揃えられない場合は KB : https://kb.vmware.com/s/article/79446 を参照の上で、双方の vCenter に
  • vCenter 6.x では
    config.migrate.test.NetworksCompatibleOption.AllowMismatchedDVSwitchConfig
  • vCenter 7.x では
    config.vmprov.enableHybridMode 
true で追加する必要あります。
但し、異なる vDS バージョン間での仮想マシンのマイグレーションでは NSX の DFW の設定や NIOC などの設定は移行されない様なので、予め対向の vDS にも同様の設定をしておく必要があります。
また、vCenter の詳細設定の編集はシステムに重大な問題を起こす可能性があるため慎重に行ってください。
推奨は双方の vDS のバージョンを一致させる事です。こちらは限定的な回避策です。

vCenter 6.x への設定

vSphere Client か PowerCLI で設定を追加します
  • 名前  : config.migrate.test.NetworksCompatibleOption.AllowMismatchedDVSwitchConfig
  • 値 : true
Flash Web Client の場合 (vCenter 6.5 など)



HTML5 Web Client の場合 (vCenter 6.7 など)



PowerCLI の場合
New-AdvancedSetting コマンドレットで vCenter の詳細設定を追加します。
# vCenter への接続
PS C:\> $vc65 = Connect-VIServer -Server "vCenter 6.x" -Credential $cre -Force

# 設定の追加
PS C:\> New-AdvancedSetting -Entity $vc65 -Name config.migrate.test.NetworksCompatibleOption.AllowMismatchedDVSwitchConfig -Value true

Perform operation?
Creating advanced setting 'config.migrate.test.NetworksCompatibleOption.AllowMismatchedDVSwitchConfig' on entity
'vCenter 6.x'.
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): Y

Name                 Value                Type                 Description
----                 -----                ----                 -----------
config.migrate.te... true                 VIServer

# 設定の確認
PS C:\> Get-AdvancedSetting -Entity $vc65 -Name config.migrate.test.NetworksCompatibleOption.AllowMismatchedDVSwitchConf
ig | Format-Table -AutoSize

Name                                                                       Value Type     Description
----                                                                       ----- ----     -----------
config.migrate.test.NetworksCompatibleOption.AllowMismatchedDVSwitchConfig true  VIServer
 

vCenter 7.x への設定

vSphere Client か PowerCLI で設定を追加します
  • 名前  : config.vmprov.enableHybridMode 
  • 値 : true
HTML5 Web Client の場合


PowerCLI の場合
New-AdvancedSetting コマンドレットで vCenter の詳細設定を追加します。
# vCenter への接続
PS C:\> $vc70 = Connect-VIServer -Server "vCenter 7.x" -Credential $cre -Force

# 設定の追加
PS C:\> New-AdvancedSetting -Entity $vc70 -Name config.vmprov.enableHybridMode -Value true

Perform operation?
Creating advanced setting 'config.vmprov.enableHybridMode' on entity 'vCenter 7.x'.
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): Y

Name                 Value                Type                 Description
----                 -----                ----                 -----------
config.vmprov.ena... true                 VIServer


# 設定の確認
PS C:\> Get-AdvancedSetting -Entity $vc70 -Name config.vmprov.enableHybridMode | Format-Table -AutoSize

Name                           Value Type     Description
----                           ----- ----     -----------
config.vmprov.enableHybridMode true  VIServer
 

異なる vDS バージョン間での vMotion の実行

設定が正しく反映されると vDS のバージョンが異なるクラスタ間でも vMotion が行えます。
以下の例では vCenter 6.5u3 + vDS 6.5 環境の仮想マシンを vCenter 7.0u1 + vDS 6.6 環境へ Advanced Cross vCenter vMotion で実施した場合。



vCenter Converter Standalone の現在

vCenter Converter Standalone は 2018年5月の vCenter Converter Standalone 6.2.0.1 (Build 8466193) のリリースを最後に開発が終了し、残念ながら現在はサポートも終了しています。

互換性のある vCenter バージョンは最終リリース日の 2018年5月時点の vCenter 6.7u1 までがリストされていますので、サポートがない状況ですが動く事は動くのでサポート終了している vSphere 5.x などの環境から仮想マシンを V2V で移行する事は可能です。

試しに今回 Cross vCenter vMotion の検証に利用した vSphere 7.0u1 の環境への移行などが可能か試してみたところ、意外にも新しい環境にも仮想マシンの移行が出来ました。
但し、移行後の仮想マシンハードウェアバージョンについては、Converter 6.2 がサポートしているバージョンより新しいものも選べてしまい、正しくコンバートされない可能性があるので注意が必要です。

試しに Version 15 で Per-VM EVC を有効にした仮想マシンを Version 18 に変換して移行したところ、初回起動に失敗し、一度 Per-VM EMC を無効にする事で起動できましたが、
仮想マシンバージョンの表示がおかしいままなので、仮想マシンハードウェアバージョンは変更せずに移行するのが良さそうです。

起動完了後、元々 Windows Server 2016 で作成したゲスト OS 情報もズレてしまい、ハードウェア情報も通常の表示ではない状態となってしまいました。


一応、vSphere 6.0u3 の環境から Version 11 の仮想マシンを vSphere 7.0u1 環境に移行し Version 15 に変換した場合は正しく移行が出来ました。


敢えて Converter を利用しなくても OVF エクスポートなど様々な移行方法を vSphere 環境はサポートしているので、Converter が上手く動かない場合は別の方法を検討してください。



2020年12月7日月曜日

新しくなった VMware Tools のサポートポリシー

※ 本投稿は先日の "vSphere クラスタの鉄板構成・サイジングのポイント 2021 年版"  から VMware Tools の項を抜粋しております。

VMware Tools のサポート状況の確認方法

従来は vSphere ESXi や Workstation などにバンドルされる VMware Tools のバージョンを利用して、母艦のサポートライフサイクルに合わせて運用される事が多かったと思いますが、
2020年11月より VMware Tools 自体も VMware Product LifeCycle Matrix に明確にサポート期間が掲載されるようになりました。
可能な限りサポート期間中のバージョンで運用しましょう。
2020年12月時点ではバージョン 10.1.x 以降が General Support となります。

サポートされるバージョンの VMware Tools の入手

現在は ESXi に Bundle される前のより新しいバージョンの VMware Tools もどんどん My VMware で提供されています。
それらは以下の URL からリリースノートの情報含めて入手可能なので必要に応じて入手してください。
My VMware からは各ゲスト OS 用のバイナリの他に、ESXi にバンドルされる VMware Tools を更新するための VIB ファイルも用意されています。
Update Manager や LifeCycle Manager を利用する or ESXCLI で ESXi に含まれる VMware Tools を更新する事が可能です。

VMware Tools の公式ドキュメント

公式ドキュメントとして、2020年12月現在 以下の URL にて Ver 10.x 以降のリリースノート、ユーザーガイドが公開されています。

VMware Tools のその他のバイナリ入手先

各バージョンの ESXi に Bundle される VMware Tools は My VMware 以外にも以下のリポジトリからも入手可能です。
それぞれのパッケージがどの vSphere ESXi に対応しているのか、Build 番号含めて確認が以下のリストで可能です。


2020年12月6日日曜日

vSphere クラスタの鉄板構成・サイジングのポイント 2021 年版

 ここ数年、様々なお客様環境のアセスメントを実施して、現状の課題と改善案を説明してきた中で vSphere 仮想化基盤のサイジングに関する考慮点や、性能を最大限かつ安定的に発揮する構成、設計についてディスカッションする機会が多くありました。

vSphere のベストプラクティスを挙げていくとキリがありませんが、それらの中で特にサーバーやストレージの物理のデザインにも関連した内容で頻繁に紹介してきたもの集めてみました。(本投稿の内容は基本的に公式のガイドに沿ったデザインの内容ですが、一部個人の経験に基づく内容もありますのでご了承ください)。

※ 本投稿は vExperts Advent Calendar 2020 の 12/6 分を担当しております。
非常に長文ですが、オンプレミス環境の vSphere クラスタデザインの参考にしていただければ幸いです。

    vSphere クラスタ 鉄板構成のための Tips

    個人的にインフラをデザインする上で重要なのは「バランス」「N+1 の余裕」「100% 使い切らない」「定期的なメンテナンス(パッチ当て)が出来る」だと思っています。
    vSphere 4.x が出た 2010 年頃はいろいろとサイジングの Tips などセミナーなどで情報をよく見掛けましたが、最近は当たり前になってしまった面もあり見掛ける機会が少ない気もします。
    あたらめて今公開されている情報から Tips をご紹介します。

    vSphere パフォーマンスベストプラクティス

    vSphere の設計をする上で必読と言ってよいドキュメントです。
    パフォーマンスを最大限に発揮するためのドキュメントは以前より以下の様なホワイトペーパーが公開されており、vSphere / Storage / Network 様々な観点の推奨がされています。


    基本はこれらに沿っていただくのがベストですが、英語で情報量が多いのでポイントを絞ってご紹介します。
    ※ 4つ目の CPU Scheduler のドキュメントは少し古いものですが、ESXi ホストと VM の CPU の使われ方についての詳細が解説されております。内容はこの後解説します。

    ESXi ホストの設定(BIOS・ESXi パフォーマンス設定)

    サーバーの BIOS 設定に関しては各サーバーメーカーが vSphere 用のガイドを出している事が多いのでそれを準拠していただきますが、
    基本は「ハードウェアアシスト機能は全て有効化」「Hyper Threading / Turbo Boost は有効化」「パワーマネージメントは OS 制御」で揃えます。
    ESXi ホスト間でこの BIOS 設定が揃っていないとクラスタに組み込めなかったり(EVC 設定が揃わず)、ホスト毎の VM 性能が異なってしまうなどのリスクが生じます。

    ハードウェアアシスト機能は BIOS 設定で有効にする

    • Intel VT-x や AMD-V などの CPU 仮想化機能
    • Intel EPT や AMD RVI などの MMU 仮想化機能
    • Intel VT-d や VMD IOMMU などのデバイスパススルー機能

    Hyper Threading、Turbo Boost も BIOS 設定で有効にする事が推奨

    • ESXi・VMkernel は Hyper Threading に最適化されて CPU をスケジューリングされ、実際に処理性能も数10%以上向上
    • VM に割り当てた vCPU へのリソース割り当ても論理 CPU が多いほど柔軟で優位
    • Turbo Boost、C1E、C-States の設定も BIOS 設定で有効化する(制御は ESXi 側で実施)
    この様な設定含めて、さらには各ホストのリソースはなるべく均等に配置され、ESXi ホスト間で極端なアンバランスがない事が推奨されます。
    メモリの枚数、配置や PCIe 拡張スロットの配置など、各物理 CPU をバランスよく利用できる構成が重要です。


    ※ 近年の Side-Channel アタックなどの脆弱性に対する考慮事項、ガイドラインも パフォーマンスベストプラクティスに詳細が記載されておりますので、各バージョンにおける考慮事項の確認をお勧めします。

    BIOS のパワーマネージメントの設定は OS 制御が推奨

    • ESXi 側からのパワー制御の機能を利用するためには BIOS 側で「OS Controlled Mode」に相当する設定、C1E、C-States を有効に設定し、ESXi 側の電源管理を「バランシング済み」に設定する事で省電力機能を有効利用できます
    • 遅延にセンシティブなシステムの場合は、BIOS 側でパワー制御を「High Performance」、C1E、C-States を無効化する、または ESXi 側の電源管理を「高パフォーマンス」にする事で、C1E、C-States などを利用しなくなり、ハードウェア性能を安定提供します(その場合は Turbo Boost は動作しない)
    パワーマネージメントは BIOS と ESXi の双方の設定を合わせる事が推奨されますので、導入時に必ず BIOS 側の設定も確認してください。

    使わないハードウェアは取り外すか BIOS 側で無効化する

    • 使う予定のない DVD-ROM、COMポート、未使用 NIC、未使用 HBA/RAID カード、不要な USB コントローラ等のデバイスは取り外す、または BIOS から無効化します
      不要な制御を無くすことでメモリを解放し、セキュリティと性能の向上につながります(微小ですが)
    • 自宅ラボに NUC などを利用して検証用の仮想化基盤を作る際も、Wifi や Bluetooth、Micro-SD スロットなど ESXi では利用しないデバイスは BIOS から無効にします

    VM の設定、サイジングの考慮

    VM に割り当てる vCPU、vRAM、vDisk の設定・サイジングにもいくつかポイントがあります。
    パフォーマンスベストプラクティスの中から汎用的に適用できる CPU やメモリの考え方を中心にご紹介します。

    VM に割り当てる仮想ハードウェアは最小限に

    既定の設定で VM を作成すると仮想フロッピードライブ、仮想 USB コントローラ、仮想シリアルポートなど、VM として普段利用しないものが含まれるので、使う予定がないものは削除します。

    仮想ハードウェアバージョン

    仮想ハードウェアのバージョンは、古いバージョンの環境で動かす可能性がない限り、なるべく最新に近いバージョンにする事が推奨されます。
    例えば vSphere 7.0 の環境の VM は General Support が終了している vSphere 6.0 の環境に移行する事はほぼないと思いますので vSphere 6.5 以降をサポートするバージョン 13 以降に設定します。

    仮想ハードウェアのバージョンを上げるのは VM の再起動が必要ですがいつでも更新できますので様子を見ながら適切なバージョンに更新してください。

    物理 CPU と NUMA、vNUMA の話

    現在の x86 サーバは NUMA アーキテクチャを採用し、vSphere ESXi は NUMA に最適化された CPU スケジューラを提供しています。vSphere 5.x 以降では NUMA をまたがって vCPU を配置する vNUMA の機能を実装しているため、多くの vCPU を搭載する VM もサポートされる様になりました。
    一般的なイメージ図では物理の配置は以下の様になり、それぞれの CPU に均等にメモリが配置される事が推奨されます(最近の Intel Scalable Processor シリーズでは CPU 辺り メモリは 6 チャネル、それぞれ 2 スロット配置される事が多いので、1 CPU 辺り 6 の倍数でメモリを挿す事が推奨されます)。


    それぞれの CPU の内部では、物理 Core とそれぞれの Core が Hyper Threading で論理的に分割されて見えてきます。

    VM の vCPU は通常はこの Hyper Threading で論理的に分割された Core を1つの vCPU として割り当てられます。

    CPU スケジューリングに関する詳細な情報は以下のドキュメントにまとまっているので興味のある方は参照してください。

    物理 CPU Core と vCPU の割り当ての関連性

    VM に割り当てる vCPU は少なすぎると 100% に張り付いて処理が滞りますし、多すぎても CPU スケジューリングの遅延につながります。
    また、Hyper Threading が有効な ESXi 上では VM に割り当てる vCPU 数は偶数で設定する事が推奨されます。
    ※ 一番左のオレンジの vCPU を持つ VM の例だと、物理 1 Core から切り出された Thread の1 つのみが利用されている形となり、もう一つの Thread が利用されていません(余ったThread 単位で別の VM からアクセスされる事はないため)


    VM の性能の観点では単一の NUMA Node に収まる vCPU 数であることが CPU キャッシュの、メモリアクセスの速度の最小化の観点で推奨されます。
    ※ 多数の vCPU を持つ VM を動かすのであれば、物理の CPU もそれに見合った Core 数のものを選ぶ。

    物理 CPU Core に対して、それを上回る vCPU を割り当てた VM の場合、デフォルトではVM の起動時に NUMA をまたがって均等に vCPU が分散される vNUMA が構成されます。
    また、Hyper Threading が有効な環境における vNUMA は物理 CPU Core 数で配置が計算されるので、以下の様に 1 つの NUMA に 16 Thread ある場合でも 12 vCPU の仮想マシンの場合は vNUMA で構成されます。


    また、片方の NUMA に寄せたい場合は VM の詳細設定からカスタマイズする事が可能です : numa.vcpu.preferHT = true

    vNUMA は VM が起動したときの ESXi ホストの CPU、VM の構成情報に応じて自動的に最適配置され、vMotion など ESXi ホスト間を移動した場合もその構成は維持されます。
    その為、クラスタ内の ESXi ホストで CPU Core 数が異なりすぎるものが混在したアンバランスの状態では vMotion 後に最適な状態ではない可能性があるためご注意下さい。

    vCPU は必要性能と物理 CPU に見合った適切な数を割り当てる

    初期の ESX (2.x) の頃は Strict Co-Scheduling と呼ばれる、VM に割り当てた複数の vCPU (vSMP) 間の CPU 割り当てが全て同時に行われる仕組みでしたが、
    ESX 3.x 以降では Relaxed Co-Scheduling と呼ばれる、VM に割り当てた vCPU 間で CPU 処理が必要とされるもののみにリソースを割り当てる柔軟な(アイドル状態の vCPU には割り当てない)仕組みになりました。

    但し、これは複数の vCPU を割り当てた VM がそれほど CPU を利用していない時の処理であって、対象の VM の CPU 利用率が高く vCPU 間の同期処理が必要な場合には VM 割り当てた全ての vCPU に CPU が割り当てられるタイミングまで CPU 待ち状態となります。

    下のイラストの例では、グレーの vCPU を持つ VM が他の VM が先に CPU を利用しているので割り当てを待っている (CPU Ready と Co-Stop) イメージです。


    CPU Ready や CPU CO-Stop など CPU の割り当て待ちが増えて来た時の影響については次で説明しますが、メモリの割り当て含めてオーバーコミットできるからと使う予定のない vCPU・メモリを VM に割り当てておくことはメリットがない上にデメリットを引き起こす事となるので、適切なリソースを割り当てることがポイントです。

    どれくらいが適切か、分からない場合は Live Optics を使ったアセスメントや、vRealize Operations Manager の導入を検討してみて下さい。
    Live Optics を利用したアセスメントについては以下に以前投稿した記事がありますので参考にしてください。
    また、vCenter の パフォーマンスチャートや PowerCLI で取得する Get-Stat の各数値、ESXTOP などの CPU 指標(特に CPU Ready / Co-Stop など)を観察する事で、CPU の割り当てが適切かどうかを調べる事が可能です。
    VM が期待通りに動いていないな?と思ったときは早めにこれらをチェックしてください。

    ESXi ホストの CPU 負荷の上限について

    一般的に物理 CPU の利用率が 80% を超えると VM の CPU Ready の値も増加し、90% を超えると VM 性能が低下します。
    これら性能低下は vCPU 数の多い VM 程影響を受けるので、サイジングの際は現在の利用率をアセスメントなどで把握したうえで CPU モデルを選定する事が推奨されます。

    下のグラフはだいぶ前に検証したものですが、ベンチマークツール DVDStore を利用して、1 ESXi ホスト辺りの負荷 VM の数を増やしていき、スコアの上昇と CPU 利用率の関係を調べた際のグラフとなります。
    ESXi ホストの CPU 負荷が 80% 前後からスコアの上昇確度が低くなり(VM 辺りの性能処理の低下)90% 前後ではスコアが上がったり下がったりと安定しない状況が確認できます。 
    この様に、ESXi ホストの CPU 利用率が 80% を超えると VM の性能が十分に発揮できなくなり、vCPU 数の多い VM ほどこのような CPU 待ちの影響を受けやすくなるので、サイジングの際はご注意下さい。
    ※ ストレージ IO やネットワーク IO の頻度が高い VM は VMkernel 側の処理で CPU 利用率が高まりますので、サイジングの際は VM のリソースだけではなく、VMkernel の処理の考慮も重要です。

    vRAM も適切な容量を割り当てる

    近年は Guest OS やアプリケーションに大容量メモリの要件が増え、メーカーのカタログ推奨値に沿って非常に大容量の vRAM を VM に割り当てる機会が増えました。
    しかしながら、ホストのメモリリソースが足りないと問題視される基盤をアセスメントしてみると実際に VM の中のメモリの使われ方に問題があり、「アクティブメモリ」が「割り当て済みメモリ」の 10% 以下といった事が多々あります。
    そのような VM のゲスト OS 内でのメモリの使われ方を確認すると、大半がファイルキャッシュ・バッファとして消費されていますので、キャッシュアクセスの頻度が少ないシステムでは無駄にメモリが消費されてしまう結果となります。

    ※ アクティブメモリはゲスト OS 内の free コマンドなどでも確認できます。

    アセスメントを実施する中で多くの環境では CPU には余裕があるがメモリがひっ迫している、という状況が確認できます。

    Live Optics や vRealize Operations Manager などのツールを使う事で VM 内部のメモリの使われ方も可視化する事が出来るので、アセスメントによる利用状況の棚卸は重要です。

    ESXi ホストのメモリ利用率の上限について

    vSphere ESXi はメモリのオーバーコミットが可能なので ESXi ホストのメモリ搭載量よりも多くのメモリを VM に割り当てる事が可能です。
    しかし、上記に記した様にゲスト OS の中では割り当てメモリの余りをどんどんファイルキャッシュなどで消費していきますので、気付いたらあっという間にメモリを食いつぶしてしまうという事になります。
    そして、割り当てメモリより消費メモリが多くなるとバルーニングが発生し、VM の性能低下が起きやすくなります。


    メモリサイジングについてはなるべくオーバーコミットさせず、VM のメモリの総容量が ESXi ホストのメモリ総容量に達しないようにサイジングを推奨します
    一般的には、ESXi ホストの障害やメンテナンス時の VM の退避先容量(HAリソース)を考慮して、N+1 や N+2 の余裕をもって ESXi ホストを構成します。
    クラスタのホスト台数によりますが、各 ESXi ホストのメモリ上限は 80% ~ 90% を前提にサイジングする事が安全です。

    vDisk は基本は Thin vDisk で作成する

    以前は性能を考慮して vDisk は Thick とする事がありましたが、最近はデータストアの All Flash 化や重複排除ストレージの普及で Thick のメリットが薄れてきました。
    また、vSAN や NFS データストアなどは基本的に Thin で vDisk を扱いますので、基本的に Thin vDisk で作成する事がお勧めです。
    ※ 一部アプリケーション側の要件で Thick vDisk が必須とされる場合はアプリケーションの推奨に従ってください。

    vNIC は可能な限り VMXNET3 を利用

    vNIC はデフォルトでは e1000e となる事が殆どですが、推奨される vNIC のタイプは VMXNET3 であることが殆どです。
    作成する VM に推奨される vNIC のタイプは VMware Compatibility Guide (Guest OS) を確認すると確認できます。

    以下は ESXi 7.0u1 における Windows Server 2019 の VCG の情報ですが、デフォルトの e1000e はサポートされていますが、推奨は VMXNET3 であることが確認できます。

    仮想ストレージコントローラは PVSCSI を利用

    VM が利用する仮想ストレージコントローラも VCG から適切なものを確認し、割り当てます。
    最近の Guest OS では PVSCSI (VMware Paravirtual SCSI) が推奨される事が多いので、これらも作成時にデフォルトから推奨に変更します。
     
    以下は ESXi 7.0u1 における Windows Server 2019 の VCG の情報ですが、推奨は PVSCSI であることが確認できます。


    VMware Tools のサポートバージョンにも注意

    2020年11月より VMware Tools 自体も VMware Product LifeCycle Matrix に明確にサポート期間が掲載されるようになりました。
    可能な限りサポート期間中の新しいバージョンで運用しましょう。


    2020年12月時点ではバージョン 10.1.x 以降が General Support となります。


    各バージョンの ESXi に Bundle される VMware Tools は My VMware 以外にも以下のリポジトリからも入手可能です。

    それぞれのパッケージがどの vSphere ESXi に対応しているのか、Build 番号含めて確認が以下のリストで可能です。

    また、現在は ESXi に Bundle される前のより新しいバージョンの VMware Tools もどんどん My VMware で提供されています。
    それらは以下の URL からリリースノートの情報含めて入手可能なので必要に応じて入手してください。

    その他の VM の詳細カスタマイズ

    今回ご紹介している設定考慮以外にも多くの詳細カスタマイズ、チューニングの方法が vSphere パフォーマンスベストプラクティスには紹介されていますので、適宜ご参照ください。

    基本は N+1 のサイジング(HA リソースの確保)と 80% を上限としたリソースサイジングを推奨

    VM の CPU、メモリの項でも説明を書きましたが各 ESXi ホストのリソース利用率は CPU、メモリとも 80% を上限としてサイジングするのがお勧めです。
    一般的には ESXi ホストの障害やメンテナンス時の総リソース低下を考慮して、1 ~ 2 台のESXi ホストが停止しても VM のリソースが確保できるサイジング(N+1 や N+2 の考え方)で余剰分の ESXi ホストをクラスタに用意します。

    ただ、vSphere クラスタの設定で通常時 HA 専用のフェールオーバーホストとして VM を配置しない設定も可能ですが、他の ESXi ホストのリソースがひっ迫しているのに余裕のある ESXi ホストが余っているのはもったいないです。

    なるべく HA 専用フェールオーバーホストとしてではなく、DRS などで負荷を均等にしつつ、HA 時のリソースはしっかり確保できるように HA アドミッションコントロールなどの設定を有効活用する事をお勧めします。


    HOL でパフォーマンスチューニングを試してみる

    オンデマンドでいつでも誰でも VMware の様々な製品操作を試す事が出来る VMware Hands-On Lab (HOL) でここまで紹介した VM の詳細設定や vNUMA などのチューニング、バルーニングの挙動確認、CPU 過負荷状態のテストのグラフで紹介した DVDStore を利用したベンチマークツールの使い方などを学ぶことが出来ます。

    ご興味ある方は試してみて下さい(以下は 2021 年版の HOL の関連コースです)。
    Lab の提供が終了した古いコースのドキュメントもプロダクト名やキーワードでフィルタしながら入手可能なので調べものの際にお勧めです。

    お勧めのネットワークの設計・設定の推奨

    私自身、サーバー・ストレージを得意とするエンジニアなのでここでは設定の確実さと安定性を重視した個人的な推奨を記します。

    ネットワーク種類の選択 10G or 25G ? RJ45 or SR ?

    最近の x86 サーバーはオンボードで 10G BASE-T * 4 ポートを選べたり、エンタープライズ向けの 10G BASE-T ポートを搭載したスイッチの価格と消費電力も下がってきたので 10G BASE-T (RJ45 コネクタ + Cat6a 以上) を採用される事が増えています。

    しかし、たまに 10G BASE-T NIC の発熱や低品質な LAN ケーブルによるネットワーク障害(パケロスやエラーなど)が聞こえてきます。
    10G BASE-T をフルレートで使う場合、それなりの機器側の発熱と高品質なケーブルの考慮が必要なので排熱設計やケーブル品質には細心の注意を払ってください。
    特にサーバー背面の LAN ケーブルが多く束ねられていて排熱が滞っている場合や、急角度で LAN ケーブルを折り曲げた事でノイズが発生してネットワークでエラーが検知される事もありますので取り回しにもご注意下さい。

    SFP モジュールや DAC、AOC を利用した 10G-SR の方がコストは嵩みますが、光ファイバケーブルの高い安定性や取り回しの良さ、低発熱のメリットがあるのでガンガンに IO が流れる様な使い方の場合は 10G-SR、25G-SR の利用をお勧めしています。

    今、個人的に機器設計から提案できるのであれば、10G-SR * 4 ポート か 25G-SR * 2 ポートのどちらかで組みたいなと思います。

    25G 以上が必須な用途

    vSAN で All NVMe、特に Intel Optane などの超高速ドライブをフル活用した IO を期待する場合は 25G 以上でストレージネットワークを組む事を推奨します。
    また、その場合は JumboFrame (MTU 9000) を利用する事で、ストレージ負荷による CPU利用率の高騰を抑えられるので、必ず JumboFrame と組み合わせて利用してください。

    iSCSI や NFS などのネットワークストレージの用途でも同様の事が言えます。

    vDS と NIOC は活用したい

    vSphere Standard のみの環境では利用できませんが、vSphere Enterprise Plus (vSphere for Desktop) や、vSAN、NSX の各ライセンスには vDS (分散仮想スイッチ) の利用権があります。

    ESXi ホスト台数が少ない場合は  vSS (標準仮想スイッチ) でも事足りてしまいますが、
    クラスタの規模が中規模以上の場合は vDS の利用が強く推奨されます。

    特に、10G や 25G で物理ネットワークの本数が集約され、VLAN でネットワークを切って運用する場合、それぞれのネットワークの用途・重要性に合わせて NIOC (Network IO Control) 、ネットワークリソースプールで帯域の優先制御がシステムの安定性の向上に役立ちます

    また、LACP や Port Mirror なども vDS でサポートされますので高度なネットワークの用途が求められる場合は vDS が必須となります。vSphere 7.0 が対応する vDS 7.0 からは NSX-T での利用がサポートされます。

    NIOC の設定画面

    トラフィックのタイプやネットワークリソースプールに対してトラフィックの優先制御(シェア値設定)や予約、制限設定が可能です。


    ※ vDS を複数のバージョンのvCenter、クラスタで利用する際は、vMotion の相互互換性の観点でなるべく vDS のバージョンを揃えておくことを推奨します。

    安定性重視なら vDS + NIOC で基本の Active - Standby 構成

    10G * 2 or 4 ポートや 25G * 2 ポート の構成で、管理ネットワーク・VM ネットワーク・vMotion ネットワーク・vSAN ネットワークなど、様々な用途・要求帯域のトラフィックを集約する場合、VMkernel・ポートグループ毎に VLAN を割り当てて設定しますが、
    この際に vDS + NIOC を利用する事で確実で安定したネットワーク構成が組めます。

    その際に、vSAN や vMotion の様な高い帯域を求められるネットワークは NIOC のシェア値を高く設定し、チーミング設定で Active - Standby の構成をポートグループでテレコに持たせることをお勧めする事が多いです。

    ※ ポートグループ毎にアップリンク(物理NIC)の Active - Standby を明示的に指定


    以下、二つほど vDS の組み方の例を紹介します。

    シンプルな 2NIC 構成で集約

    用途毎に Active - Standby をテレコに構成する事で、以下の例では通常時は vSAN トラフィックや vMotion トラフィックは必ず片側の ToR スイッチで折り返してサーバー間で処理され、スイッチ間の渡り(ISL)を通る事がないのでシンプルな管理が可能です。


    NIOC の設定は、vSAN トラフィックを 100、その他のネットワークの合計を 100 とする事で、片方のネットワークが断となり片側に寄せられた場合でも、vSAN トラフィックには全体の半分のシェア値が割り当てられるので、ネットワークの片系障害時にも帯域を優先的に確保する事が出来ます。

    4 NIC 構成でネットワーク用途で Teaming を分離

    4 ポート以上で組める場合は、負荷の高い vSAN や vMotion を別の vDS や ToR スイッチに分けて通常の VM ネットワークと分けるデザインも可能です。


    よりネットワーク負荷の分散を制御したい場合には Active - Active のデザインも当然サポートされ、ToR スイッチで LACP などを組む事が出来る場合はそれらの利用も可能です。

    VMware Validated Design にもこれらの推奨デザインが紹介されていますので併せて参照ください。

    ネットワークの MTU 設定(Jumbo Frame)の推奨は?

    vSAN、iSCSI、NFS などネットワークストレージを利用し、その IOPS が非常に多く負荷が高い場合は JumboFrame を利用する事で ESXi ホストの CPU 利用率上昇を抑える事が可能です。
    ※ ストレージネットワークの場合、JumboFrame で IOPS の Max を上げるというよりは CPU 負荷を下げる効果の方が顕著です。

    過去の経験上、Intel Optane SSD などを利用して All NVMe vSAN を構成し、25G・40G ネットワークで性能検証した際は最大負荷を掛けた際の CPU 負荷を大幅に減らし、結果として IOPS の上限も上がった事がありました。
    高い性能を考慮する場合は予め JumboFrame の利用を前提とした方が良いです。

    また、NFV 用途などで高スループットのトラフィックを捌く際にも JumboFrame の設定は有効に働きます。
    ※ 効果は IO サイズによっても異なりますので、環境に合わせた判断が必要です。

    JumboFrame (MTU 9000)を有効にする場合は End to End (vNIC・VMkernel、仮想スイッチ、ネットワーク機器)で揃える必要があるので、ESXi ホストの追加や故障による交換時など設定漏れが無いように注意してください。

    お勧めのデータストアのデザイン、設定

    外部ストレージ構成時のデータストアデザイン

    RAID や Pool 設計、FC ストレージ利用時のゾーニング設計や NFS ストレージ利用時のコントローラタイムアウトの設計など、ストレージの設計ポイントを挙げていくとキリがないので、今回はデータストアの容量と数に関して、および ESXi ホストからストレージへの接続パスパスについてのみ記します。

    データストアのサイズと数の考慮

    多くの外部ストレージは複数のコントローラで冗長化され、バックエンドの LUN や ファイルシステムを双方のコントローラからアクセスできる仕組みを備えています。
    しかし、ハイエンドモデルでは Active - Active で同時に 2 つのコントローラから LUN へ IO を捌く事が可能でも、ミッドレンジのストレージでは実際にはどちらかのコントローラが LUN のオーナーとなり、通常時の IO は片方のコントローラが捌くといった事が一般的です。
    NFS データストアを利用する場合も同様で、どちらかのコントローラ(NFSサーバ)が NFS のファイルシステムをマウントして提供するのが一般的です。

    その場合、大容量のデータストアを 1 つだけで構成すると片方のコントローラが普段は使われない事となります。


    クラスタの負荷分散と同じく、ストレージコントローラも IO の負荷が偏り、CPU 利用率が高騰すると IO 遅延にもつながりますので、なるべく IO が分散できるようにデータストアを構成する事が推奨されます。


    全体の容量や VM の数にもよりますが、1コントローラ 1データストアだと拡張時や何等か設計不都合で再作成が必要となった時、障害発生時のインパクトも大きくなるので用途に合わせて 4 つ以上でデザインすると良いかと思います。


    1つのデータストアの容量は、過去の VMFS の制限などから 2TB 前後で切る設定がよく見られますが、VAAI による IO 処理のオフロードやストレージの大容量化に伴い 20TB を超えるデータストアも珍しくありません。
    ストレージレプリケーションの対象がデータストア単位だったり、データストア毎に性能要件を設定する等実際の運用ポリシーにデータストアの数や容量は依存しますので、適宜コントローラの負荷バランスをとった配置設計で組んでいただく事が推奨されます。

    重複排除ストレージの考慮

    最近は重複排除・圧縮をサポートするストレージが一般的となり、vSphere 上の利用ストレージ利用率と、ストレージ上で管理される重複排除後の利用率に差が生じ、データストアのサイジング・容量のオーバーコミットが難しくなってきました。

    従来方式のデータストアでは Thinprovisioning のデータストアを作成した場合も、この差は吸収が難しいため、vSAN や VVOL などポリシーベースのストレージアーキテクチャの利用を最近はお勧めしています。


    ストレージとの接続・パスの管理

    FC・iSCSI データストアではマルチパスによる IO の分散とパスの冗長化、NFS データストアでは NIC チーミングによるパスの冗長化を図りますが、導入時・運用中とも必ず意図した設計通りのパスが設定されているか必ず確認してください。

    一般的な FC・iSCSI などブロックストレージでのデータストア設計であれば以下の様に 1 つのデータストアに対して、ESXi ホストからは 4 つのパスが ラウンドロビンで設定されている事が推奨となります。

    結線イメージ
    パスの本数

    パスの数が異なっている場合は間のスイッチにおけるゾーニング設定や VLAN 設定に間違いがある可能性があるので、必ず全 ESXi ホスト、全データストアで均一にパスが通っているかを確認してください(一括確認には PowerCLI などを利用すると便利です)。

    また、マルチパスの場合はパスの切り替わりのポリシーも想定と違う値が設定されていると性能や可用性に影響が出るので、必ず以下のベストプラクティスや KB の注意点を確認してください。

    vSphere Storage Best Practice

    ストレージに関しては vSphere Performance Best Practice 以外にも以下の様なガイドライン、KB が案内されています。
    各ストレージメーカーがリリースしている vSphere 向けの設計ガイドと合わせて参照してください。
    また、FC・iSCSI などのブロックストレージではパス設計とともに IO の分散設計(現在多くはラウンドロビン + 1 IO 切り替わりを推奨)、iSCSI ポートバインディングの考慮について質問されますので、以下 KB を参照先として記します。

    vSAN 構成時のデザイン

    vSAN クラスタのデザインについては以前に以下の記事をまとめております。
    また、以下の KB、Cloud Platform Tech Zone のドキュメントも非常に有用ですから参照くださ。

    お勧めのクラスタ設計・設定・運用

    その他様々な設計要素がありますが、いくつか抑えておいていただきたいポイントをご紹介します。

    vSAN 上に vSAN 自体を管理する vCenter を配置する場合のポイント

    vCSA on vSAN は今では一般的な構成となっておりますが、考慮しておくと便利な設計ポイントをご紹介します。

    ホストグループ・仮想マシングループと DRS アフィニティ・アンチアフィニティルールの活用

    vCSA on vSAN に限った事ではありませんが、DRS が有効なクラスタでは VM はクラスタ内のホストに自由に分散されます。
    しかし一部の VM は特定のホストに配置したい、特定の VM はこのホストには配置しない、といった設定が必要な時があります。

    vCSA on vSAN の場合、例えば計画停電運用などでクラスタを全シャットダウンした際、次回起動時に「vCSA がどこの ESXi ホストで動いていたか確認し忘れた」と言った時は全 ESXi ホストにどの VM が配置されているか、Host Client や CLI でチェックして vCSA を探す必要があります

    こうした面倒を嫌って DRS を使わなかったり、DRS を「手動」設定で運用する方もいらっしゃいますが、やはり負荷分散の機能は非常に有用なので可能な限り DRS による分散は強く推奨します。

    DRS を使いつつ特定の VM と特定の ESXi ホストを結びつける運用では vSphere が機能として持つホスト・仮想マシングループと DRS アフィニティ・アンチアフィニティルールが利用できます。
    DRS で全自動の分散をしつつ、特定の VM を特定の ESXi ホストに配置したり、特定の ESXi ホストへ移動を禁止する等のルールを設定する事が可能です。

    DRS アフィニティルールを利用する事で、vSphere クラスタの全シャットダウンを行った後の再起動時も、vCSA などの管理 VM がどこの ESXi ホストに登録されているか特定できるのでメンテナンス時の手間がなくなります。

    実際の vSphere Client の UI では、各クラスタの「設定」にある「仮想マシン/ホストグループ」「仮想マシン/ホストルール」から設定します。


    仮想マシングループの設定(対象 VM を指定)

    ホストグループ設定(対象 ESXi ホストを指定)

    DRS アフィニティルールの設定


    DRS アフィニティルールは非常に柔軟なクラスタ運用を可能にするポリシー設定なので活用をお勧めします。
    ※ DRS が有効でない、または vSphere Standard など DRS がない環境では DRS アフィニティルールに基づく VM の自動的な vMotion による移動は制御できませんが、
    vSphere Standard でも ホストグループ・仮想マシングループの作成とルールの設定自体は行えます
    この場合、VM の起動時にルールで許可されていない ESXi ホストでは VM の起動が禁止され、また手動で vMotion する場合も弾かれるので、特定の ESXi ホストに対してアプリケーションのライセンスなどが有効化され、VM と実行される ESXi ホストの一致が必須の場合などには有効な手段となります。

    管理ネットワーク用 vDS 非バインドポートグループ常設を推奨

    vDS は vCenter がシャットダウン状態でも設定したポリシーで稼働し続けますが、vCenter がシャットダウン状態では設定変更や、新規 VM に新たなネットワークポートをアサインする事が出来なくなくなります。

    vCenter 自体が自分自身を管理する vDS に管理ネットワークを接続している場合、vCSA が破損し、新規で vCSA をデプロイし vDS に接続しようとしてもネットワーク接続に失敗してしまう問題が発生します。

    こうした管理 VM の障害発生時に臨時で利用するための「短期-バインドなし(Ephemeral Binding)」という種類の vDS ポートグループがあります。
    vCenter 自体が vDS 配下にある場合で、クラスタが vDS のみで構成されている場合は必ず「短期-バインドなし(Ephemeral Binding)」のポートグループを管理ネットワーク用 VLAN の設定で準備しておいてください。

    「短期-バインドなし(Ephemeral Binding)」 については以前記事を書いておりますので以下も参照してください。

    vCenter と ESXi の構成情報、DB バックアップ

    vCSA 6.5 以降の vCenter は管理画面(VAMI)からファイルベースで DB のバックアップが可能で、かつ現在のバージョンでは vCSA のイメージバックアップは非推奨とされ、ファイルベースの DB バックアップは vSphere 仮想化基盤の運用では必須となります。

    vCenter 7.0 では、SMB/NFS/SFTP など様々な出力先に定期的なバックアップを取得するジョブがサポートされています。
    少なくとも設定変更やパッチ適用等 vCenter で管理イベントが行われる際には DB のバックアップを取得する事が推奨されます。
    また、ESXi ホストも従来からコンフィグバックアップがサポートされています。
    ESXi ホストで取得したバックアップは「取得時と同じ Build バージョンにしかリストアできない」仕様があるので、ESXi ホストのパッチ適用の前後では必ずバックアップを取得しておいてください。
    KB にもある様に、PowerCLI で Get-VMHostFirmware を利用して取得する事も可能なので、全ホストを同時に一括でバックアップする事も可能です。