2020年4月20日月曜日

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

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

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

1. 強化されたDistributed Resource Scheduler (DRS)
vSphere DRSは以前クラスターの状態をフォーカスに別のESXiホストが消費しているリソースが少ない間に1つの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を使用する代わりに、1つのvCPUのみを要求してすべてのトレース作業を実行します。VMを使用できる他のすべてのvCPUは、中断することなくワークロードを実行し続けます。
  • より大きな粒度のページテーブル
    vSphere7以前のメモリのページ単位は4KBでした。vSphere7では仮想マシンモニタ(VMM)プロセスは1GBのページでより大きな粒度で読み取り専用フラグを設定することで、ページファイア(メモリの上書き)が発生すると、1GBのページテーブルエントリは2MBと4KBに分割されます。
  • 切り替えフェーズの機能強化
    切り替えフェーズでは、チェックポイントデータとメモリビットマップを送信します。メモリビットマップは、VMのすべてのメモリをトラックするために使用されます。どのページが上書きされているかを認識しており、宛先ESXiホストに送信する必要があります。vMotionが最後のメモリページを転送すると、ターゲットホストのVMの電源がオンになります。ただし、送信用に残っている最後のページがまだ必要な場合があります。宛先でこれらのページを識別するために、ソースから転送されたビットマップを使用します。顧客がメモリをオーバーコミットした場合、スワップアウトされたページはオプションのスワップビットマップでトラックされます。
    vSphere7では6TBのメモリを実行することもあり、ビットマップだけで数百MBもあります。1秒未満で切り替え時間を実現するにはビットマップを小さくする必要があり、ビットマップを圧縮して本当に必要な情報のみを送信するようにします。コンパクト化されたメモリビットマップを利用して、vMotionは大きなビットマップをミリ秒単位で送信でき、スタン(気絶)時間を大幅に短縮します。
  • パフォーマンスの改善
    上記3つを実現することでパフォーマンスを向上
詳細は以下のブログに掲載されています。(英語)

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チームにとっても、エラーが発生しやすく、時間がかかります。
詳細は以下のブログに掲載されています。(英語)

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は「ガラスを割る」の緊急アクセスメカニズムとしてまだ存在しています。

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