ad1

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 様々な観点の推奨がされています。


    ※ 2022/3/8 追加 : いくつか新しいガイドがリリースされたので今後整理して記事をアップデートしたいと思います。
    基本はこれらに沿っていただくのがベストですが、英語で情報量が多いのでポイントを絞ってご紹介します。
    ※ 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 側の電源管理を「バランシング済み」に設定する事で省電力機能を有効利用でき、vSphere の標準推奨設定です
    • 遅延にセンシティブなシステムの場合は、BIOS 側でパワー制御を「High Performance」、C1E、C-States を無効化する、または ESXi 側の電源管理を「高パフォーマンス」にする事で、C1E、C-States などを利用しなくなり、ハードウェア性能を高い性能で提供します（その場合は CPU 動作周波数を抑えた省エネ稼働は無効になり 常に P0-State : 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 からアクセスされる事はないため）

    ※ この辺りの HT の扱いは近年の CPU に関連する脆弱性対策で考え方も変わりますので以下を併せてご参照ください。


    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 に割り当てておくことはメリットがない上にデメリットを引き起こす事となるので、適切なリソースを割り当てることがポイントです。

    不要な多数の vCPU を割り当てた SMP 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 利用率が高騰した環境では VM の性能が十分に発揮できなくなり、vCPU 数の多い VM ほどこのような CPU 待ちの影響を受けやすくなるので、サイジングの際はご注意下さい。
    ※ ストレージ IO やネットワーク IO の頻度が高い VM は VMkernel 側の処理で CPU 利用率が高まりますので、サイジングの際は VM のリソースだけではなく、VMkernel の処理の考慮も重要です。

    一般的には ESXi の物理 CPU の割合が常に 80% を超えるような状態は ESXi ホスト自体の処理が飽和状態になっている可能性が高く、VM に割り当てられる vCPU のスケジューリングに重大な影響を及ぼしている事が多いです。
    ESXTOP コマンドや vSphere Client のパフォーマンスモニタで CPU Ready の時間が 10% を超えるような状態、Co-Stop の時間が 10％ を超えるような状態では健全でないと言えますので ESXi ホストの追加拡張や、不要な VM の停止などが必要となります。

    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 を利用して取得する事も可能なので、全ホストを同時に一括でバックアップする事も可能です。


    以上、超長文ですが vSphere 組む際に私自身が気を付けているポイントをざっと紹介させていただきました。
    ※ 追記した方が良いなと気付いた点は更新していきたいと思います。
    時刻:
    ラベル: , , , , ,

    0 件のコメント:

    コメントを投稿

    登録: コメントの投稿 (Atom)

    過去30日でアクセスの多い投稿