vSphere 7の紹介【vSAN File Services続編/モニタリング編】

みなさん、こんにちは

本日もvSAN 7の強化ポイントに関する内容をご紹介したいと思いますが、本日の内容はブロックとモニタリングに関する内容となります。

1. 新しいユースケースをサポートするためのクラウドネイティブ機能の拡張

お客様は今後仮想マシンとコンテナベースのアプリケーションの両方を単一のプラットフォームで実行できる汎用インフラストラクチャを求めていくことになります。

vSAN 6.7 Update 3では、コンテナー向けの永続ストレージ用のネイティブコントロールプレーンが導入されました。管理者は既存のツールを使用して、開発者がシームレスにストレージを管理できるようにしています。クラウドネイティブストレージは、Kubernetes内部のすべての主要なストレージAPIオブジェクトをサポートしています。また、管理者はコンテナーボリュームを詳細に把握できるようになり、管理者はコンテナーボリュームごとにヘルス状態およびコンプライアンス情報をすばやく簡単に制御、監視できるようになりました。

ブロックセントリックのワークロードはvSAN 6.7 Update 3にすぐに適合しましたが、一部のアプリケーションは効率的に実行するために集中型のファイル共有を必要としました。

今回のリリースでは、vSANがKubernetesによってオーケストレーションされたクラウドネイティブアプリケーションのファイルサービスプロトコルNFS 4.1およびNFS 3をサポートするようになり、vSAN上のクラウドネイティブアプリケーションの使用例が拡大しました。

NginXやTomcatなどのWebサーバーアプリケーションは、インスタンスごとにデータを複製する代わりにファイルリポジトリを共有するため、はるかに効率的に実行することができます。ファイルサービスに加えて、vSANはKubernetes（旧称Project Pacific）でvSphereをサポートします。これにより、ステートフルなコンテナー化されたワークロードをvSANデータストアのスーパーバイザーおよびゲストクラスターにデプロイできます。

vSAN 7はHCI上で実行できるクラウドネイティブアプリケーションのタイプを拡張し、さまざまなワークロードに対応する優れた汎用インフラストラクチャになります。お客様は、クラウドネイティブアプリケーションインフラストラクチャに低コストの業界標準サーバーを利用しながら、vSphere Lifecycle Managerによりインフラストラクチャの管理に必要な時間を短縮できます。

2. vSANサービスのメモリ消費量を簡単に表示

vSANのアーキテクチャは非常に柔軟です。管理者は自分のニーズを満たす方法でデータサービスとハードウェア構成を調整できます。これらのハードウェアとソフトウェアの構成の結果として、vSANはメモリ要件を動的に調整します。vSAN 7ではクラスター全体でホストごとにvSANのメモリ消費量をシンプルに表示できます。これにより、管理者は継続的な設計とサイジングの取り組みに対するvSANのニーズをより理解できることになります。

こちら対応については以下になります

• APIおよびUIで利用可能なvSANメモリメトリック
• ホストごとの時間ベースのメモリ消費量の詳細
• ハードウェアとソフトウェアの構成変更の結果としてリソースの消費量を表示
  ・デバイスまたはディスクグループの追加
  ・データサービスの有効化/無効化

・こちらのメトリックは、クラスターを強調表示してから、[監視]> [vSAN]> [サポート]> [サポートのパフォーマンス]> [メモリ]> [vSANメモリ]（Monitor > vSAN > Support > Performance for Support > Memory > vSAN Memory）をクリックすると利用可能になります。

・メトリックは、vSANクラスター内のすべてのホスト全体のホストごとの単一の時間ベースの「vSANメモリ」メトリックとしてレンダリングされます。

・メトリックに示されている情報は、KB2113954で提供されているメモリサイズ計算式と密接に一致させるためのものです。 このメトリクスの目的は、vSANによって消費されるメモリと有効なサービスをお客様がより理解できるようになっています。

・メモリメトリックの保持時間は、他のvSANパフォーマンスサービスメトリックと一致しています。 最長90日間保持される場合がありますが、すぐに削除される場合があります。 メトリックは、1時間から最大24時間までの時間枠を使用して表示できます

・クラスタ全体のデータサービスは、ホストのメモリ使用量に影響を与える可能性があります。その中にはこちらの内容も含みます

• 重複排除と圧縮
• 保存データの暗号化
• iSCSIサービス
• ファイルサービス

3. vSphereレプリケーションデータの認識の向上

vSAN 7ではvSphere Replicationを使用するすべての環境に対して、大幅な改善が導入されています。管理者はVMオブジェクトレベルおよびクラスターレベルの容量ビューで、vSphereレプリケーション関連のオブジェクトデータを簡単に識別できるようになります。このvSphereレプリケーションデータの認識レベルの向上は、非同期レプリケーションのニーズに使用されるリソースを管理者が決定するのに役立ち、組織の保護ニーズを満たすための後続の設計決定に影響を与えます。
主な改善点は以下に記します。

• vSphere Replicationによって作成および使用されるオブジェクトを簡単に識別
• 「仮想オブジェクト」リストの新しいvSphere Replication オブジェクトIDタイプ
• クラスターレベルのキャパシティビューの新しいvSphere Replication カテゴリ

vSANの以前のエディションでは、vSphere Replicationによって作成されたオブジェクトのレポートは「不明なオブジェクトタイプ」として報告されていました。次にこのオブジェクトタイプは、クラスターレベルの容量の内訳のために「その他」のカテゴリに分類されます。 次にこのオブジェクトタイプは、クラスターレベルの容量の内訳のために「その他」のカテゴリに分類されます。 vSANでvSphere Replicationを使用した環境では、これらのIDはいずれもお客様に役立ちませんでした。

vSAN 7ではvSphere Replicationの結果として、3つの異なるオブジェクトタイプがオブジェクトデータを説明できます。これら3つのタイプは、クラスターレベルの容量の内訳で区別できます。

• “vSphere Replication Disks” - クラスタキャパシティビューの「ユーザーオブジェクト」カテゴリの下に表示されます。ターゲットサイトの実際のバックアップデータを格納するvSANオブジェクトについて説明します。
• “vSphere Replication Configs” -クラスター容量ビューの「ユーザーオブジェクト」カテゴリの下に表示されます。ターゲットサイトで構成データを保存するためにvSphere Replicationによって使用されるvSANオブジェクトについて説明します
• “vSphere Replication persistent state file” -クラスター容量ビューの「VM」カテゴリーの下に表示されます。 ソースサイトで永続状態ファイル（PSF）を格納するためにvSphere Replicationによって使用されるvSANオブジェクトについて説明します。

vCenter UIの「仮想オブジェクトリスト」にあるオブジェクトの列挙では、ビューにvSphere Replication構成オブジェクトのわかりやすい名前が表示されます。ほとんどの場合、これは保護されたVMの名前と一致します。例外は、保護されたVMの名前が変更された場合、またはターゲットサイトで名前の競合があった場合です。

以上、よろしくお願い致します。

vSphere 7の紹介【vSAN ライフサイクル&ファイルサービス編】

みなさん、こんにちは
本日はvSAN 7の強化ポイントに関する内容をご紹介したいと思いますが、内容が多いため、2回に分けてお話したいと思います。
今日はライフサイクルに関する話（vLCMからの追加）およびファイルサービスについてお話します。

vSANに関しては、ここ3年間はvSphereと同等バージョンで対応してきております。また、よりHCIを簡素化するために、ハードウェアベンダーとのファームウェアを含めてライフサイクル管理、ファイルサービスの提供、クラウドネイティブストレージへの対応も含めて、様々な強化ポイントが含まれております。

1. vSAN 7でHCIを最新化(モダナイゼーション) 

VMwareはvSAN 7をからHCIを刷新し、より多くのユースケースに対応できるようにして、さらに使いやすくなりました。vSANとHCIをワンストップのショップストレージプラットフォームに近づけるプラットフォーム全体に、さまざまなメリットを提供しています。そのために、統合されたファイルサービスを提供し、お客様が一部のユースケースでサードパーティソリューションの必要性を回避できるよう支援しています。また、ライフサイクル管理を大幅に簡素化するための措置を講じており、2日目の運用に必要なツールを1つのツールに削減しています。これも、既存のツールセットよりもはるかに信頼性が高くなっています。最後に、vSAN搭載HCIの主要な理由の1つは未来を見据えたインフラストラクチャの概念です。つまり、昨日のテクノロジーに縛られずに、ITの最新のイノベーションに対応するためにソフトウェアを常に進化させています。このリリースでは、Kubernetesによってオーケストレーションされたコンテナベースのワークロードのファイル共有を有効にし、永続的なボリュームレベルでより詳細なデータサービスを提供し、KubernetesでvSphereをサポートすることで、クラウドネイティブアプリケーションのサポートも強化しています。

2. 大規模なライフサイクル管理 – よりシンプルなアプローチ

vSphere Lifecycle Managerのパートでもお話したかと思いますが、vSANのプラットフォームにおいて、vLCMを提供します。

詳細は以下のブログを参照して頂ければと思います。
https://tkomiya.blogspot.com/2020/04/vsphere-7vsohere-lifecycle-manager.html

前回のブログからの補足事項をいくつか記載したいと思います。

• vLCM互換ホストを決定するために、ReadyNodesが「vLCM対応」かどうかを示すVCGに追加された追加の属性を探します。
• 特定のクラスターではvLCMとVUM(vSphere Update Manager)は共存しますが、お互いは排他的に動作します。 どちらか一方を利用するように選択しますが、両方を利用することはありません。
• VUMを利用する既存のクラスターの場合、クラスターレベルのメッセージには、「単一のイメージでクラスターを管理すると、１つのイメージでクラスター内のすべてのホストを維持できるため、エラーを最低限に抑え、時間を節約するのに役立ちます」 この点から、「Learn More」をクリックするとクラスターをvLCMに変換できます。
• クラスターがVUMからvLCMに移行すると、クラスターをVUMに戻すことはできません。
• VUMは最終的には廃止される予定であるが、現時点では機能が制限されて共存します。 これはvSphere 7.0で非推奨となっている PercCLIやStorCLIなどの古いベンダーツールによるものです。
• 新しいクラスターの場合、「新しいクラスター」のワークフローでは、DRS、HA、vSANなどの配下に「単一のイメージでクラスター内のすべてのホストを管理する」というチェックボックスが表示されます。これにより、クラスターでvLCMが有効になります。

当然、vSAN ReadyNodesのvLCMとVxRailとVCFのライフサイクル管理機能との比較が行われます。 これらの違いを区別する製品ポジショニングのスライドが提供されます。提供内容を正確に表現し、これらの他の製品を補完するように細心の注意を払う必要があります。 いづれの場合も、幅広い顧客ベースに対応するように構築されたvLCMによって提供されるこれらの機能(例:VxRailやVCF)を利用するためのより高度なLCMオファリングの機能を含む、多くのLCM機能の基盤として(vSphere 7.0以降)利用されます。vLCMはVxRail(およびその他のvSANアプライアンスも含めて)のライフサイクル管理機能の代わりとして位置づけるものではありません。

3. ネイティブ ファイルサービスによる管理の複雑さの削減

ファイルサービスに関しては、vSAN 6.7 U3でNFSをサポートしていましたが、多くのvSANのお客様はHCIアーキテクチャのみで標準化したいと考えています。 例えばファイルサービスをサードパーティの物理ソリューションを要求することは受け入れられません。 ファイルサービス用の認定された仮想アプライアンスの現状のエコシステムは、役立つものの、統合化されたHCIの運用モデルの約束を満たしていません。

一例として、VDIのソリューションでは、CIFSをなどを利用するシーンなどもありましたが、Windowsサーバーを仮想マシンとしてデプロイしても、要件になかなか満たすことができず、仮想アプライアンス（Nexenta Stor【現在DDNに買収されています】やNetAppのONTAP Selectなど）で実現することもできるが、ファイルサーバーを導入するにも、システム上はSSDなどが利用されることから、システムは一つに統合できたとしても、コストパフォーマンスは決して良くはありません。


vSAN 7ではVMwareはファイルサービスをvSANに統合し、ブロックストレージとファイルストレージの組み合わせ、テスト環境と開発環境およびクラウドネイティブアプリケーションを必要とする軽量アプリケーションの管理を容易にします。（ただし、今回もCIFSのサポートはありません）

管理者は単一のワークフローでファイルサービスVMをすばやくプロビジョニングおよび構成できます。

今回の特徴を以下に記載します。

• ブロックおよびファイルプロトコル用の単一のコントロールプレーンでストレージを統合
• 単一のファイルサービスワークフローによるプロビジョニングの簡素化
• ユースケース：クラウドネイティブアプリ、テスト/開発環境、ファイルリポジトリ
• NFS v4.1および v3 プロトコルのサポート

vSANファイル共有はvSANの他のストレージオブジェクトと同様に次のような重要なデータサービスを受け取ります: 高可用性、暗号化、きめ細かなポリシーベースの管理、柔軟なスケーラビリティなど

さらに、ファイルサービスをスケールアウトするメリットを享受できます。これには、大量の先行投資と大規模の投資が必要となります。 vSANはスケールアウトアーキテクチャによっても容量計画の複雑さを軽減します。

vSAN 7はNFS 4.1および NFS 3プロトコルをサポートします。 NFS 4.1は多くのクラウドネイティブアプリケーションで使用されており、NFS 3は使用されている最も一般的なNFSプロトコルです。

vSANファイルサービスは次のユースケースを対象：

• クラウドネイティブアプリ
   vSANファイルサービスとクラウドネイティブの強力なストレージコントロール機能を組み合わせることで、お客様に魅力的なソリューションを提供できると確信しています
• ブロックとNASのワークロードの組み合わせ
  vSANファイルサービスは複雑な専用のファイル共有ストレージを利用させない、小規模のファイルサービスアプリケーションのストレージ管理を簡素化します
• スペア容量の使用
  追加のvSAN容量を利用して、軽量のファイル共有ワークロードを実現します。お客様にとってのメリットは、スケールアウトアーキテクチャによるシンプルな容量管理です

アーキテクチャ
------------------------------

ファイルサービスはクラスターレベルのサービスであり、iSCSIサービス、重複排除と圧縮、保存データの暗号化など、他のクラスターレベルのサービスと同じUIで有効にできます。

ファイルサービスはファイルサービスVMまたはFSVMと呼ばれる一連のエージェントVMを利用します。

エージェントVMは、PhotonOS、Dockerを含むサービスが有効（800MB）になると、非常に軽量なOVF（ダウンロード後にvCenterでキャッシュ）から構築されます。 クラスタでファイルサービスが無効になっている場合、これらのエージェントVMはパワーオフのままです。

vSAN 7のファイルサービスは、vSANクラスターごとに最大8台のファイルサービスVMをサポート

これらのエージェントVMはPhotonOSを使用して、POSIXを完全にサポートするためにGanesha経由でNFSサービスを提供するDockerコンテナーを実行し、統合してネームスペースを形成します。

ファイルサービスは9P（プロトコル）を使用します。

ファイルサービスのデータパススタックは次のとおり:

• プロトコルレイヤー – Ganeshaを介してアドバタイズされたサービス（NFSなど）を提供します（エージェントVM内のコンテナーで提供）
• Linuxファイルシステム– Linuxファイルシステムに、汎用仮想ファイルシステム（VFS）および9pのレイヤーを提供します。 POSIX要求を受け入れ、9pに変換してから、VDFSプロキシ（ローカルまたはリモート）を介してVDFSに変換します。
• VDFS – 9pとのインターフェース、9pコマンドのリモートVDFSデーモンへの転送、またはvSANへのリクエストをブロックする変換
• vSAN – ネットワークまたはローカルデバイスを介したブロックI/Oの処理

------------------------------

9Pプロトコルについては、Wikipediaをご参照下さい。

https://ja.wikipedia.org/wiki/9P

以上、よろしくお願いします。

vSphere 7の紹介【DRS/vMotion/セキュリティ編】

みなさん、こんにちは
本日はvSphere 7のDRS/vMotionの強化ポイントおよびセキュリティに関する内容をご紹介したいと思います。

今までvSphereでDRS/vMotionと言うと、ホスト上のワークロードを他のホストを移動するということが目的でしたが、その移行の方法が改善されております。
今後はワークロード一つの大きさや負荷が大きいもの（SAP HANA等）を取り扱うようになり、それに対応することが必要不可欠になってきております。
今回はその内容についての詳しく説明したいと思います。

1. 強化されたDistributed Resource Scheduler (DRS)

vSphere DRSは以前クラスターの状態をフォーカスに別のESXiホストが消費しているリソースが少ない間に１つのESXiホストが過剰に消費される可能性があるため、リバランスが必要かどうかを確認していました。DRSのロジックがクラスターのバランスを改善できるよ判断した場合、構成された設定に応じてvMotionを推奨したり実行したりします。このようにして、DRSはクラスター全体の標準偏差モデルを使用してクラスターのバランスを維持しています。

新しいDRSロジックは全く異なるアプローチを採用しています。ホスト上のVM DRSスコアを計算して、仮想マシンを最も高いVM DRSスコアを提供するホストに移動します。古いDRSバージョンとの最大の違いは、ホストの負荷バランスが取れなくなったことになります。これは、DRSがESXiホストの使用率ベースラインを気にしないことになります。次に、最も重要な測定基準である仮想マシンの最適な場所に配置することにフォーカスしていることで、クラスターのワークロードバランシングを改善します。

さらに重要なポイントとして、改良されたDRSが1分毎に実行されるようになり、ワークロードバランシングを計算するためのさらに詳細な方式で提供されます。これにより、以前のバージョンに比べてワークロードの全体的なパフォーマンスを向上させます。

DRSスコアとは？【VMware Docsを参照】
https://docs.vmware.com/jp/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-23A2BE80-BCE2-49D7-902E-F7B8FDD8F5F8.html
--------------------------------------------
個々の移行の推奨は、実行効率を測定する仮想マシン健全性メトリックを使用して計算されます。このメトリックは、vSphere Client にあるクラスタの [サマリ] タブに DRS スコアとして表示されます。DRS ロード バランシングの推奨は、仮想マシンの DRS スコアの改善を意図しています。クラスタの DRS スコアは、クラスタ内でパワーオンされているすべての仮想マシンの仮想マシン DRS スコアの加重平均です。クラスタの DRS スコアはゲージ コンポーネントに表示されます。値表示部分の色は、仮想マシンの DRS スコアのヒストグラムの対応するバーと一致するように変化します。ヒストグラムのバーには、DRS スコアがその範囲内に該当する仮想マシンの割合が表示されます。クラスタの [監視] タブを選択して [vSphere DRS] を選択すると、サーバ側でソートおよびフィルタリングしたリストを表示できます。これにより、クラスタ内の仮想マシンが DRS スコアの昇順にソートされて一覧表示されます。
--------------------------------------------

2. 強化されたvMotion

DRSと同様に、vMotionについてもプロセスを確認し、vMotionのプロセスを向上させてリソースが増加し続けるワークロードについてもサポートする方法を検討する必要がありました。リソースが増加するという意味では、SAP HANAやOracleのデータベースのような大規模のコンピューティング(CPUおよびメモリ)リソースを必要とする仮想マシンをvMotionを利用してライブマイグレーションするという課題もあります。（今まではパフォーマンスが低下することもあった。リソースの最大値は256 vCPU, 6TB メモリ）

vMotionのプロセス中のパフォーマンスへの影響および切り替えフェーズ中の非常に長いスタン（気絶）時間は、これらの大規模ワークロードに対してvMotionを利用することに抵抗があったと思います。

今回のvSphere7ではvMotionのロジックが大幅に改善されたため、その機能が復活しています。

• メモリの事前コピーの最適化
  vMotion中はVMのすべてのメモリページをトラックする必要があり、ライブマイグレーション中あっても、VM内のゲストOSはvMotion中もメモリにデータを書き続けます。vMotion中に上書きされたメモリページをトラックして再送信する必要があります。
  vMotionプロセスは、VM用に構成されたすべてのvCPUにページトレーサーをインストールします。そうすることで、vMotionはどのメモリページが上書きされているかを理解します。これは、ページトレース中の「ページファイア」と呼びます。
  ページトレーサーをインストールしてページファイアを処理するには、vCPUを一時的に停止します。わずか数マイクロ秒ですが、すべてのvCPUを停止すると、ワークロードが中断されます。VMのコンピューティングリソースをスケールアップすると、vMotion操作の影響が大きくなります。
  vSphere 7ではページトレースのためにすべてのvCPUを停止する必要がなく、ページトレーサーをインストールできるようにしています。ページトレースの方法はほとんど同じですが、すべてのvCPUを使用する代わりに、１つのvCPUのみを要求してすべてのトレース作業を実行します。VMを使用できる他のすべてのvCPUは、中断することなくワークロードを実行し続けます。
• より大きな粒度のページテーブル
  vSphere7以前のメモリのページ単位は4KBでした。vSphere7では仮想マシンモニタ（VMM）プロセスは1GBのページでより大きな粒度で読み取り専用フラグを設定することで、ページファイア（メモリの上書き）が発生すると、1GBのページテーブルエントリは2MBと4KBに分割されます。
• 切り替えフェーズの機能強化
  切り替えフェーズでは、チェックポイントデータとメモリビットマップを送信します。メモリビットマップは、VMのすべてのメモリをトラックするために使用されます。どのページが上書きされているかを認識しており、宛先ESXiホストに送信する必要があります。vMotionが最後のメモリページを転送すると、ターゲットホストのVMの電源がオンになります。ただし、送信用に残っている最後のページがまだ必要な場合があります。宛先でこれらのページを識別するために、ソースから転送されたビットマップを使用します。顧客がメモリをオーバーコミットした場合、スワップアウトされたページはオプションのスワップビットマップでトラックされます。
  vSphere7では6TBのメモリを実行することもあり、ビットマップだけで数百MBもあります。1秒未満で切り替え時間を実現するにはビットマップを小さくする必要があり、ビットマップを圧縮して本当に必要な情報のみを送信するようにします。コンパクト化されたメモリビットマップを利用して、vMotionは大きなビットマップをミリ秒単位で送信でき、スタン（気絶）時間を大幅に短縮します。
• パフォーマンスの改善
  上記３つを実現することでパフォーマンスを向上

詳細は以下のブログに掲載されています。（英語）

https://blogs.vmware.com/vsphere/2020/03/vsphere-7-vmotion-enhancements.html

3. vSphere7のセキュリティ

証明書管理はコンプライアンスを重視する多くのお客様にとって興味深いものです。 vSphere 6.7以前では、管理する証明書がたくさんありましたが、vCenter ServerのVMware Certificate Authorityの外部で証明書を管理していたお客様にとって問題になりました。 vCenter ServerレベルとESXiレベルの両方で、それらすべてを再発行して置き換えるのは複雑になる可能性があります。vCenter Server 7.0では、証明書の管理を容易にするためにいくつかの興味深いことが行われています。まず、ソリューション証明書は非推奨になり、内部ではvRealize Operations、vRealize Log Insightなどの他の製品を接続する、それほど複雑ではないが同等に安全な方法に置き換えられます。

vSphere 7ではその複雑さのほとんどを解消します。 vCenter Serverのアプローチははるかにシンプルになり、ソリューションの管理方法が異なります。 ESXiも簡素化されているため、サービスはそれぞれ独自の証明書を使用するのではなく、共通の証明書を使用します。 

vSphereのほぼすべてにAPIが存在することを保証するためのより大きな取り組みの一環として、vCenter Server証明書を処理するためのREST APIがあります。

このように複雑さを軽減することで、セキュリティとコンプライアンスに関して正しい内容で簡単に行うことができます。

vCenter ServerとESXiの両方のサービスの証明書に関する簡略化が追加されているため、証明書を手動で管理する場合でも、vCenter Serverの一部であるVMware Certificate Authority（VMCA）で許可する場合でも、管理する証明書の数ははるかに少なくなります。クラスター証明書を管理します。VMCAは、vSphereクラスターの暗号化のニーズを管理するための「ちょうど十分な認証局」です。エンタープライズPKIインフラストラクチャの一部としてよく見られるような汎用の認証局（CA）と混同しないようにして下さい。

また、vSphere7では以下の証明書の管理モードがあります。

• Fully Managed Mode(完全管理モード)vCenter Serverがインストールされると、VMCAは新しいルートCA証明書で初期化されます。これは、クラスター内部の証明書（ESXiホスト間の通信、ESXiホストとvCenter Server間の通信の保護）、およびいわゆる「マシン証明書」の管理に使用されます。マシン証明書は、その名前にもかかわらず、vSphere Clientにログインしたときにブラウザに表示されるものです。信頼を確立するために、vCenter ServerのメインWebページからVMCAルートCA証明書をダウンロードし、PCにインポートできます。「VMware Engineering」などのデフォルトのテキスト値の代わりに独自の情報を使用して、必要に応じてVMCAルート証明書を再生成することもできます。
• Hybrid Mode（ハイブリッドモード）
  VMCAは、vSphereクラスター内部の証明書管理を自動化することで、膨大な時間を節約し、証明書を更新し忘れたときなどのエラーの可能性から解放されます。ただし、vSphere Clientにアクセスする人が多い場合、VMCAルートCA証明書をインポートするように全員に依頼することは実際的ではありません。代わりに、vSphere Clientが使用する証明書を置き換えることができるため、デフォルトでクライアントのブラウザーに受け入れられます。これは、インフラストラクチャ内部のセキュリティの高度な自動化と、vSphere Clientユーザーの最小限の管理作業で両方の長所です。ただし、vSphere管理者は、ESXiホストとの信頼を確立するためにVMCAルートCA証明書をインポートする必要があります。ESXiホストの管理インターフェイスには、VMCAによって署名された証明書があります。
  ハイブリッドモードとデフォルトの完全管理モードの両方で、ESXiホストとvSphere Clientのどちらにも自己署名証明書がないことに注意してください。
• Subordinate CA Mode（CA従属モード）
  VMCAは従属CA、企業CAから委任された権限として動作できます。これにより、vCenter Serverは、完全管理モードと同様に、証明書管理の自動化を継続できます。ただし、生成する証明書は組織の一部として信頼されます。これは一部の組織にとって魅力的ですが、キーマテリアルをVMCAにインポートする必要があります。これは、送信中に置き忘れられた場合（または念のために秘密に保管された場合）、攻撃者が組織になりすまして中間者攻撃のように攻撃を行うようになります。多くの場合、このレベルの自動化を求める組織は（巨大なものから小規模なものまで）潜在的な障害ドメインを分離するのに役立つため、代わりにハイブリッドモードを使用しています。
• Full Custom Mode（フルカスタムモード）
  このモードではVMCAは使用されず、ユーザーはvSphereクラスターに存在するすべての証明書をインストールして管理する必要があります。vSphere 7の簡素化を使用しても、これは数十の証明書に達する可能性があり、証明書の有効期限が切れると、運用上の問題や機能停止の可能性があります。さらに、vCenter Serverは証明書を使用してホストとの信頼を確立するため、ESXiホストでの証明書の置き換えには、vCenter Serverへの証明書の切断と再接続が含まれます。このように切断されたくない分散スイッチとvSANストレージの場合、これはかなり面倒です。何百ものキー、CSR、および署名証明書の生成は、vSphere管理者だけでなく、エンタープライズPKIチームにとっても、エラーが発生しやすく、時間がかかります。

詳細は以下のブログに掲載されています。（英語）

https://blogs.vmware.com/vsphere/2020/04/vsphere-7-certificate-management.html

4. 連合アイデンティティ(Identity Federation)

Identity FederationがWikipediaに連合アイデンティティと記載があったので、この名称で説明致します。
vCenter Serverは長い間、Active DirectoryおよびLDAPディレクトリと認証を行うことができました。また、vSphereのシングルサインオン（SSO）の一部として独自のディレクトリがあります。お客様がセキュリティを強化できる最大の方法の1つは、適切なパスワードポリシーを使用することであり、そのための最も簡単な方法の1つは、多要素認証(MFA)を実装することです。したがって、問題はMFAを実装する方法が非常に多くあり、それらすべてを使用してvCenter Serverを拡張することがほぼ不可能であるということです。さらに、それらの一部を実装したとしても、多くのお客様が企業のアイデンティティ管理システムにすでに持っているものを複製しているので、ユーザーが日常の運用をより良くしたいという願望とは一致しません。

VMwareにとってのソリューションはOAUTH2やOIDCなどのオープンな認証と承認の標準化を使用したフェデレーションです。vCenter Serverの情報を取得してエンタープライズのIDプロバイダーと通信して、vSphereの管理者およびvCenter Serverのプロセスから除外します。これにより、vSphere管理者の仕事内容とが簡素化され、監査範囲も減ることになるので、多くのユーザーが満足すると思われます。Active Directory フェデレーションサービスやADFSのようなものをプラグインする方法も知られているため、様々な多要素認証の対応も可能になります。

vSphere 7はそのままでADFSをサポートします。ID管理には多くの「方言」があることを先に述べました。 Active Directoryは1つの方言を話し、Ping、Okta、vIDMなどの他のプロバイダーはさまざまな方言を話します。ADFSにより、それらすべてをサポートするインフラストラクチャを構築することができました。今後は、vCenter Serverにより多くの方言を教えます。また、お客様がこれらの他のサービスへの接続を使用してADFSを展開することも比較的簡単であり、これにより人々は始めることができます。

最後に、従来の認証オプションはすべて引き続き存在しますが、Identity Federationに切り替える場合は、統合Windows認証とLDAPが置き換えられます。ただし、SSOは「ガラスを割る」の緊急アクセスメカニズムとしてまだ存在しています。

以上、よろしくお願い致します。

vSphere 7の紹介【vSphere Lifecycle Manager編】

みなさん、こんにちは
本日はvSphere 7の統合ソフトウェアおよびファームウェア管理を提供するvSphere Lifecycle Manager (vLCM)をご紹介したいと思います。

今までvSphere上でファームウェアの管理というと、VUM（vSphere Update Manager）を利用していたかと思いますが、こちらはESXiもしくはvSAN上で最適な環境にするためのプラットフォーム管理で利用していましたが、ハードウェアベンダー毎にドライバーおよびファームウェアが最適になっているかどうかは管理をしておりませんでした。
VxRailなどのアプライアンスなどは提供しているハードウェアベンダー側で管理を行うための別のツールを利用する必要がありました。

vLCMを導入することで、各ハードウェアベンダーがプラグインで対応することで、それぞれのベンダーのハードウェアで最適なドライバーおよびファームウェアが管理できるようになります。

1. vSphere Lifecycle Manager (vLCM)とは？

vSphere 7はvSphereにネイティブな統合ソフトウェアおよびファームウェア管理のためにまったく新しいソリューションを導入します。vSphere Lifecycle Manager（vLCM）は、vSphere Update Manager（VUM）の次世代の代替品であり、望ましい状態または宣言モデルから構築され、データセンターに電力を供給するサーバー用のハイパーバイザーおよびドライバーとファームウェアの完全なスタックのライフサイクル管理を提供します。

vLCMはシンプルで一貫したサーバーライフサイクル管理を大規模に作成するための強力な新しいアプローチです。vLCMはハードウェアベンダーのニーズを考慮して構築されました。これらのベンダーは、お客様が簡単にインストールできるプラグインを使用して、フレームワークを通じて特定のライフサイクルアップデートを提供できます。

提供する機能

• 望ましい状態をベースとしたパッチ、アップグレード、および構成を提供
• レコメンデーションエンジンが互換性の問題を特定
• JSONおよびRESTベースの自動化
• vSphereから集中管理されるハードウェアのファームウェア

2. クラスターイメージ管理

vSphere 7の起動時に、クラスターイメージはvLCMがDell社のOMIVVなどのベンダー提供のファームウェア管理ツール（またはハードウェアサポートマネージャー）と同期することが可能なため、vSphere(ESXi)、ベンダーアドオン（標準のESXiのゴールデンイメージとOEMのISOにおける差分）、ファームウェアアドオンで構成できます。

現状利用可能なハードウェアベンダーはDELL EMC および HPEになっています。

構成管理についてはまだテスト段階ということもあり、Update 1にて対応予定になるようです。

3. 大規模なライフサイクル管理 － よりシンプルなアプローチ

vLCMは統合ソフトウェアおよびファームウェア管理を提供しますが、機能概要は以下の通りです。現状のvLCMはまだ機能が不十分なところもありますので、リリース時点ではVUMを利用したほうがよいと思います。（Update1以降で機能改善するとのこと）

-------------------------

•すべてのライフサイクルオペレーションに望ましい状態のモデルを利用

•コンプライアンスの「動向」を監視（HCL検証を確認）

•不具合が発生した場合、修正して望ましい状態に戻す

•クラスターレベルでホストを管理するために構築

•ハイパーバイザー

•ドライバー

•ファームウェア

•モジュラーフレームワークがベンダーファームウェアプラグインをサポート
（現状は以下の2社）

•Dell

•HPE

-------------------------

望ましい状態、つまり宣言モデルはユーザーが結果を定義し、ソリューションが管理対象の状態を監視し、一致しない時にいつでもこの目的の状態を達成するためのアクションを実行するという考えに基づいています。この宣言モデルはKubernates,AnsibleやPuppetなどの構成管理ツール、さらにはストレージポリシーベースの管理（SPBM）にみられるものと似ています。

VUMとvLCMの違いについては、vLCMはVUMでは実現できなかったレベルのエコシステム

サポート、拡張性、予測可能性を提供できます。

•vLCMは個々のホストにアップグレード/パッチメカニズムを提供するVUMとは

対照的に、クラスターレベルでのサーバースタックのライフサイクル管理に

重点を置いています。

•vLCMを利用するとユーザーは一連のルールまたはクラスターへの結果を指定

でき、一連のルールへの準拠を実現するための仕組みが整っている。

これはSPBMがストレージに似たようなことを行っていますが、この場合、

vLCMはサーバースタック管理に対してこの生じた事象に対して指向性を持った

結果を生成します。

この望ましい状態のモデルを実現するためにvLCMで使用されるイメージは次のもので構成されます:

•ベースイメージ – ESXiのベースイメージ

•ベンダーのアドオン – ベースイメージに追加されるベンダー固有のドライバーと

構成。 これはVUMのカスタムISOおよびVIBの機能の代替品です。 

このカテゴリに含まれるコンテンツと実装はベンダーによって異なります。

•ファームウェアとドライバーアドオン – ベンダーが指定したファームウェアと

場合によっては非同期のドライバーが対応します。 これらはベンダーによって

異なります。

「ベンダーアドオン」と「ファームウェアおよびドライバーアドオン」は一部重複しており、ベンダーに柔軟性を提供するために存在します。 今後、これらを１つの項目にまとめられる可能性があるかもしれません。

vLCMはBIOS、ストレージI/Oコントローラー、ディスクデバイス、NICS、BMCを含む

サーバースタックのライフサイクル管理を提供するようになります。

vSphere 7.0で提供されるvLCMのエディションは、このフルスタックをサポートします
が、HCL検証はストレージI/Oコントローラーに対してのみです。 BIOS、ストレージデバ
イス、NIC、BMCなどの他の項目は、実際にはvLCMを介して更新されますが、HCL検証は
ありません。

vLCMのこのエディションでは、推奨のイメージを利用するコンポーネント

(ESXiバージョン、ドライバー、ファームウェア)がホストで実行している状態と

一致しない場合、「動向」が検出されます。

•監視される動向は、ESXiの構成設定ではなく、一部のドライバーおよび

ファームウェアに限定されます。

•動向の例としては、管理者が古いドライバーを使用しているホストにVIBを

手動でインストールした場合などがあります。

•動向を修正すると、ホストは推奨のイメージに保存されている望ましい状態に

戻ります。

•vLCMはこの機能を提供し、修正を容易に行うことができます

vLCMはvSAN搭載クラスターのアップデートをサポートしています。（Witnessホストアプライアンスを除く） 

現時点においては、Project PacificおよびNSX-V / NSX-Tをサポートしておりません。

vLCMはvCenterサーバーのアップデートを行いません。

VxRailなどはvLCMからはアップデートできません。また、VCFなどの統合ソリューションはvSphere部分が対応しているもののNSXなどは対応していないため、今後順次対応していくようです。

以上、よろしくお願い致します。

vSphere 7の紹介【vCenter編】

みなさん、こんにちは
本日は先月リリースされたvSphere 7についてご紹介したいと思います。
今回のvSphere 7については様々な機能が強化されておりますので、一度に全部紹介すると記事が長くなるため、小分けにしてご紹介しようと思います。
今回はvCenterの機能についてです。

ただし、今回はvSphere 7を初めて取り上げため、まず初めにvSphere 7の柱となる機能もご紹介いたします。

1．vSphere 7: 最新クラウドインフラストラクチャに不可欠なサービス

今回のvSphere 7は主にコンテナ対応とIoT・エッジまでの統合プラットフォームの対応になります。また、AIやMLを利用した管理も今回の特徴です。
vCenterおよびvSANなどの機能強化については、以下の内容に含まれます。

​合理化された開発環境

• 完全に互換性のあるKubernatesのためのTanzu Kubernetes Grid
• Kubernates APIを介したリアルタイムのインフラストラクチャアクセス
• vSphere ポッドサービスは高いパフォーマンスと強化されたセキュリティを提供

​アジャイルオペレーション

• アプリケーションをフォーカスした管理
• 効率的なライフサイクル管理
• 上流から下流に至る固有のセキュリティ
• クラウド、データセンターそしてエッジまでの導入における統合プラットフォームと一貫性のある運用

​イノベーションの推進

• 費用対効果の高い AI / MLのハードウェアプール
• DBおよびビジネスに不可欠なアプリケーションのパフォーマンスと復元力
• タイムクリティカルなアプリケーションの予測可能なサービス品質

2．vCenter Server 7のアップグレード機能

vCenter Serverを構築するにあたり、vSphereでID管理、証明書管理、ライセンス管理などのサービスをサポートするPSC(Platform Services Controller)を導入する必要があるかと思います。

こちらは主に以下の内容を提供します。

• vCenter Single Sign-Onによる認証
• VMware Certificate Manager (VMCA)証明書を使用したデフォルトでのvCenter ServerコンポーネントおよびESXiホストのプロビジョニング
• VMware Endpoint証明書ストア（VECS）に格納されているカスタム証明書の使用

vSphere 6.7まではPSCとvCenterは別で構築することが必須で、PSCをWindowsにインストールするか、PSCアプライアンスを導入する必要がありました。

vSphereからはPSCの導入を別途行う必要がありません。vCenterの内部にPSCが組み込まれます。vSphere 6.7からvSphere 7に移行される方はConvertion Toolを利用してPSCを組み込むことができるようになるそうです。(vSphere 6.7 U2ではvSphere Clientに統合されて、GUIで実行できるようになっています)
3．vCenter Server スケーラビリティの強化

次にvCenter Serverのスケーラビリティの強化についてお話したいと思います。vSphereはバージョンアップするにつれて、スケーラビリティが向上しておりますが、今回のvSphere 7においても以下の点でvSphere 6.7に比べてスケーラビリティが向上しています。

• vCenter Server1台あたりの管理ホスト数・VM数
• リンクモード時の管理ホスト数・VM数
• vCenter Serverのレイテンシ

クラウド・エッジ対応も考えると、リンクモード時の管理VM数が多くなるのは当然のことかと思います。そのためなのか、vCenter間のレイテンシ間隔が増えています。
4．vCenter Server プロファイル

vCenter Serverの管理をREST APIで連携することが可能になります。
利用できるAPIはイメージにも記載がある通り、リスト(List)、エクスポート(Export)、検証(Validate)、インポート(Import)の４つで構成されます。
これにより、vCenter ServerプロファイルはPuppet、Chef、Ansibleなどの自動化ツールを利用することができます。
5．コンテンツ ライブラリ

vSphere Clientではコンテンツライブラリに保存されているVMテンプレートを編集したり、他の特権ユーザーが加えた変更を監視したりすることができます。チェックアウト操作を実行して、VMテンプレートから仮想マシンを更新することができます。このプロセスの中でVMテンプレートは他のユーザーからのチェックアウトには利用することができませんが、中断することなくVMテンプレートから仮想マシンがデプロイできます。

テンプレートから仮想マシンをチェックアウトして仮想マシンを更新した後に、仮想マシンをVMテンプレートに変換し直す必要があります。VMテンプレートにチェックインすると、仮想マシンの更新された状態を含むVMテンプレート(VMTX)の新しいバージョンが作成されます。最新のVMテンプレートを保持する必要のない変更が含まれている場合、または最後のチェックイン時に間違えた場合はVMテンプレートを以前のバージョンに戻すことができます。

または、管理者が同期の頻度とパフォーマンスの最適化をより細かく制御できるように、新しく先進的な構成も追加されています。

6．vCenter Server マルチホーミング

vCenter Server 7はマルチホーミング(マルチNIC)構成をサポートするようになりました。追加された最初のネットワークアダプター(NIC 1)はvCenter HA(VCHA)用に予約されており、常時利用されるNICとなります。
追加される後続のネットワークアダプターには、NIC2,NIC3などの番号が付与されます。
ネットワークアダプターを追加する場合、vCenter ServerアプライアンスでのNICの最大数は4です。さらに多くのアダプターをアプライアンスに追加できる場合がありますが、サポートされるのは４つまでです。

以上、よろしくお願い致します。

Nutanix AOS 5.15について

みなさん、こんにちは
以前からVMwareおよびNutanixの記事を投稿しておりましたが、今回からこちらのブログに記事を掲載させて頂きます。

今回は先日（3月31日）にリリースされたNutanix AOS 5.15についてお話したいと思います。
NutanixのAOSについては、機能を説明する前に初めて見る方もいらっしゃると思いますので、まずはサポートについてご説明したいと思います。

1. LTS(Long Term Support)とSTS(Short Term Support)について

NutanixのAOSには２つのサポートがあります。
STS：短期サポートリリースになります。新機能を実装しており、定期的なアップグレードパスも提供(3か月間のメンテナンス期間と3か月間サポート)
LTS：長期間にわたってサポートが維持され、特定リリースファミリーで主にバグ修正を長期間提供（アップグレードである次のリリース日から12か月のメンテナンス期間とそれに続く6か月のサポートの計18か月）

日本のお客様に関しては、検証環境でSTSを選択されることがありますが、主としてLTSを選択されることが多いです。

Prism Centralについては、LTSやSTSの規則に従うことがありません。Nutanix Filesについても同様になります。

2. AOSのライフサイクルについて

先ほどのサポートの話の中でメンテナンス期間とサポート期間の話をしましたが、バージョンによって、どの段階でバージョンアップをしなければならないのかを検討する必要があります。
特にLTSを選択する場合は、サポート可能な期間を考えながらアップグレードをする必要があります。

上図はバージョン5.16までのライフサイクルを示した図になります。
2020年4月の段階では、AOS 5.5, AOS5.10およびAOS5.15のLTSとAOS 5.11, AOS5.16のSTSが利用可能になります。
現時点でAOS 5.15のサポート期間の明記はありませんが、今後記載されることがありますのでチェックが必要になります。

3. AOSのアップグレードパスについて

AOSのアップグレードパスについてですが、こちらはアップグレードパスを確認できるサイトでもチェックできますが、一例としてアップグレードできるパスを記載しておきます。

https://portal.nutanix.com/#/page/upgradePaths　（要サポートポータルログイン）

AOS 5.15にアップグレードを行う場合、最低でもAOS 5.10から行う必要があります。
なお、細かいバージョンでアップグレードできるバージョンとできないバージョンがありますので、バージョンアップするときはアップグレードパスから確認してからお願いします。

また、AOS 5.16からAOS 5.15については、アップグレードではダウングレードになりますので、×になります。

4. AOS 5.15の主要機能

AOS 5.15の機能についてご紹介したいと思います。
AOS 5.15はAOS 5.11の機能とほぼ一緒ですが、一部の機能が追加されております。
ストレージQoSについては、今までESXiではサポートしている機能ですが、AOS 5.11になってサポートされました。
データ保護についてもVMware関連の対応がされており、容量に関しては1ノードあたり120TB以上のストレージに対応できるようになりましたので、バックアップ専用ノードに最適な環境が提供できるようになります。
AOS 5.15での追加機能としては、VMコンポーネント保護に関する機能追加されています。

パフォーマンスおよび復元力

• ストレージ QoS
• すべてのテナントに一貫したパフォーマンスを提供します
• ミッションクリティカルなワークロードのSLAを定義して要件を満たす

セキュリティ

• Volumesの物理ネットワークセグメントセグメンテーション
• ネットワークセキュリティ要件を満たします
• 様々な種類のトラフィックをきめ細かく制御 

データ保護

• ESXiにおけるリカバリプラン
• SRMのNearSyncサポート 

スケール

• 120TB以上のストレージ容量 (最大80TBからの容量アップ)

メトロ環境におけるVMCP-APDサポート【AOS 5.15追加機能】
(VMコンポーネント保護のすべてのパスのダウン)

• メトロ環境でコンポーネント保護がサポートされ、APD(All Path Down)の状況が検知され自動HAがトリガーとなりストレージのみの障害で影響を受けるサイトで保護されたVMをフェイルオーバー

５. AOS 5.15のメジャーアップデート（AOS 5.11と同様）

AOS 5.15におけるメジャーアップデートについてご説明します。
内容についてはAOS 5.11と同様になり、４に述べた詳細内容になります。

各機能については、対応するハイパーバイザーなども確認して頂ければと思います。また、120TBの容量についてはSSDの容量にも仕様が決まっていることもありますので、ご注意の上、選定して頂くことが重要になります。
Nutanix Guest ToolsのESXiサポートに関しては非常に興味のある機能追加であると言えます。

ストレージのサービス品質 (QoS)  (パフォーマンスと復元力)

•Nutanixクラスターの最初のユーザー定義のストレージ（QoS)の属性 (ESXi & AHV)

•管理者はクラスター上の選択された仮想マシンのIOPSのレートを制限（スロットル）して重要度の低いワークロードがミッションクリティカルなワークロードのパフォーマンスに影響を与えないようにする

Volumesのネットワークセグメンテーション(iSCSI)トラフィック（セキュリティ）

•今まではクラスター内部（バックプレーン）のトラフィックを管理トラフィック

から分離することが可能

•現在は管理者がNutanixのクラスター外部のVolumesのトラフィックの個別

（物理）ネットワークを物理的に分離することができます

•ネットワークポリシーを選択的に適用できるように特定のトラフィックを

クラスター上の特定ポートに分離

ストレージ容量 (スケール)

•120TB以上の高密度のストレージノード； 4ノードクラスターから約0.5

ペタバイト（Raw）のストレージ容量が構成可能

•オブジェクトストレージ, ファイル共有, 監視ビデオアーカイブ, 

DRバックアップなどのソリューションに最適

DR (データ保護)

•ESXi⇔ESXiでサポートされる大規模なデータ保護とレプリケーションの自動化

のためのNutanixのリカバリプラン

•15分未満のRPO向けのNutanix DRソリューション, NearSyncが

Site Recovery Managerでサポート

Nutanix Guest ToolsにおけるESXiのサポート

•Prism Centralで複数のVMにNGTを同時にインストールおよびアップグレード

するためのESXiのサポート

６. Prism Central 5.11の新機能およびアップデートした機能

Prism Central 5.11の新機能を紹介します。5.15のPrism Centralについては現状リリースはございません。（2020年4月10日現在）

Prism Central 5.11にてサポートされたのはオブジェクトストレージです。
現在Nutanix Objects Ver 2.0.1までリリース（AOS 5.11リリース時はVer1.1）されておりますが、Ver2.0になりWORMがサポートされています。

X-Playについては、Prism Central 5.11.1からService Nowを使用してPrism Centralのアラートをシームレスなインシデント管理を行うことができるようになっております。

SyslogモニタリングについてもAPI監査だけでなく、Flowのログも監視できるようになりました。

Nutanix オブジェクトストレージのサポート

•Nutanixのオブジェクトストレージ（Nutanix Objects）がサポートし, Prism Centralを利用してオブジェクトにアクセス可能

コードレスタスクオートメーション（X-Play)

•X-Play機能を使用して、Prism Centralを介して日常の管理タスクを自動化できます。X-Playは使いやすい自動化ツールで、日常の管理タスクを自動化し、システムで発生した問題を自動修正するのに役立ちます。Playbooksを
作成することで、この自動化を実現できます。

•X-PlayはPrism Proライセンスが必要

•X-Playでは、Prism Centralのみが5.11である必要があり、Prism Elementを5.11にアップグレードする必要はありません

Syslogモニタリング

•Prism Centralを利用して登録されたクラスターのSyslog（API監査、監査ログ、Flowログ）を外部のSyslogサーバーに転送してsyslog監視が可能

セキュリティポリシーのエクスポートおよびインポート

•セキュリティ管理の観点でセキュリティポリシーをエクスポートおよびインポート可能になりました

•必要なときにシステムを目的の状態に復元できるように動作中のセキュリティ構成のスナップを取得可能

•セキュリティポリシーをテンプレートとして適用する機能であり、データセンターが複数のPrism Centralのインスタンスによって管理されているROBO環境（ディザスタリカバリサイト）構築に役立ちます

Prism Central 5.11よりXi Cloud Serviceにも対応することになりました。日本でのXi Cloudのローンチした時には是非試して頂ければと思います。
また、カテゴリについてもESXiがサポートされることになりました。

イメージ配置ポリシー

•アップロードするイメージを受信するクラスターを管理するポリシーを構成できます。イメージ配置ポリシーと呼ばれるこれらのポリシーは、これらの両方のエンティティに関連付けられたカテゴリを使用して、イメージをターゲットクラスタにマッピング

Flowのログでポリシーヒットをサポート

•セキュリティポリシーの作成時にポリシーヒットログのオプションを使用するとポリシールール上のトラフィックフローのヒットを記録できます。

Nutanix Networking Service (Xi Cloud Services)

•Nutanix Networking Serviceを利用すると、オンプレミスのデータセンターとXi Cloud Services間のVPN接続のセットアップが可能。このオプションを選択した場合、Xi Cloud Servicesを接続するために独自のVPN機器を準備する必要はありません
（Xiクラウドで実行されているVPNゲートウェイVMとのIPSecトンネルを確立）

Xi Cloud ServicesでNutanix Guest Tools(NGT)のサポート

•Xi Cloud Servicesで実行される複数のVMでNGTをマウントして、NGTでアプリケーションを管理し、NGTをアップグレード可能になります

カテゴリでESXiをサポート

•カテゴリにおいてESXiが追加されました

エンティティメトリックの強化されたモニタリング

•エンティティの詳細ページのメトリックチャートが強化され、監視されたパターン、エンティティの振る舞い、および異常をより明確に表示する表示オプションが含むようになった

VM管理用のカテゴリベースのRBAC

•カテゴリを利用して指定された役割ベースのアクセス制御（RBAC）を使用して、AHVのクラスター内のVMを管理できるようになった

カテゴリのマルチカーディナリティのサポート

•カテゴリはマルチカーディナリティ（カラム内に複数のデータ含まれる）をサポートするようになりました。
つまり、同じエンティティに複数のカテゴリ値を割り当てることができます。

７. AHV 5.15の新機能および更新された機能(AOS 5.11と同等機能)

AHV 5.15の新機能については、特に新しい機能が5.11から追加がありません。
次ページにありますが、いくつかのバグ修正が行われております。
今回の機能はネットワークに関連する内容やコンピュートノードのサポートおよびUEFIのサポートになります。

br0アップリンク構成のアップデートをサポート

•NICチーミングポリシーとインタフェースのグループ化をbr0-upで変更可能

AHVクラスターでのコンピュート専用ノードのサポート（AHVのみ）

•AHVクラスターのコンピュート用の容量（CPUおよびメモリ）をシームレスかつ

効率的な拡張可能Nutanixクラスターがコンピューティング専用にコンピュート

専用ノードのリソース（CPUおよびメモリ）を使用可能

AHVおよびHyper-VクラスターのVMにおけるUEFIサポート

•NutanixはAHVクラスターでUEFIファームウェアを使用したVMの起動を完全に

サポートNutanixはHyper-Vクラスターから移行されたVMの限定的なサポートも

提供。aCLIコマンド, Prism Webコンソール, またはPrism Central UIを使用して、

UEFIファームウェアでVMを作成またはアップデートできます。

br0アップリンク構成のアップデートをサポートの詳細内容

AHVクラスターのデフォルトブリッジbr0のボンドbr0-upのデフォルトのNICチーミングポリシーはActive-Backupです。br0-upのNICチーミング・ポリシーを変更することが可能です。Active-Active, MACのピニングとActive-Active, またはデフォルトを保持しているActive-Backupポリシーを。Active-Activeポリシーを選択した場合は、クラスター内の各ノードの対応するラック上部（TOR）スイッチでリンク集約（LAG）とLACPを手動で有効にする必要があります。

デフォルトでは、br0-upはノードで使用可能なすべての物理インターフェースを集約します。これでbr0-upに属する必要があるインターフェースを選択することにより、このデフォルトのNIC構成を変更できます。10Gインターフェースのみ、1Gインターフェースのみを使用するか、デフォルト設定、つまり使用可能なすべてのインターフェースをbr0-upに集約するかを選択できます。

AHV 5.15におけるバグ修正になります。内容はAOS 5.16と同様の内容も含まれます。

AHV部分の改善点

•AHVは、マシンメモリの最大半分が取り除かれた場合に正常に起動するように

なりました

•AHV上のssh_host_dsa_keyに関連する無関係なsyslogメッセージを修正

•SELinuxにおける準最適な設計の検索実装により、AHVが応答しなくなることが

あります

•圧縮などのサービスで空きメモリの計算ロジックを改善しました

•SSHを利用したAHVホストへの接続は失敗するが、VGAのコンソールを利用した

場合は正常にログインします

•AHVアップグレード後に応答しなくなる場合があります

セキュリティの改善について

•CVE-2018-12207：複数のIntel（R）プロセッサーの仮想ゲスト

オペレーティングシステムによるページテーブル更新の不適切な無効化により、

認証されたユーザーがローカルアクセスを使用してホストシステムのサービス

拒否を有効にできる可能性があります

•CVE-2019-14287 sudo：すべてのキーワードを指定したRunas仕様の特権

エスカレーション

AOS 5.15の機能の詳細については、別途記事を掲載したいと思います。

以上、よろしくお願い致します。