Home > Blogs > Japan Cloud Infrastructure Blog

VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(1)

Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策

 

トレンドマイクロでVMwareテクニカルアライアンスを担当している栃沢です。今回からVMware様のJapan Cloud Infrastructure Blogの場をお借りして、VMware vSphere、NSX、Horizonを利用した環境でのTrend Micro Deep Securityの活用方法や連携について掲載をさせていただくことになりました。いかにセキュリティを担保していくのか?そのテクノロジーにはどういったものがあるのか?という点を中心にお伝えしていければと思います。

初回となる今回は、最近よく質問をいただくご質問にお答えしたいと思います。
「VMware vSphere/NSX+VMware Horizonの環境でインスタントクローン方式による仮想デスクトップの展開を行った場合、Deep Securityのエージェントレス型セキュリティ対策は使えないの?
Deep Securityはインスタントクローン方式では使えない?といったことをお聞きになっていた方もいらっしゃると思います。実際にインスタントクローン環境でDeep Securityを利用するという場合には制約事項があります!といったお話をしていました・・・

ところが!Deep Securityの新しいバージョンをご利用いただくとインスタントクローン方式で展開した仮想デスクトップ環境でもDeep Securityによるエージェントレス型セキュリティ対策がご利用いただけるようになりました。
みなさんにとってご理解しづらかった点を含めて、今回は紐解いていきたいと思います。

 

Deep Securityがエージェントレスでセキュリティ保護できる仕組み

まず、Deep Securityがエージェントレスで仮想デスクトップ(仮想マシン)を保護できるプロセスをおさらいしておきましょう。このプロセス、連携の仕組みを理解頂くことで全体像をご理解いただくことができると思います。

Deep Securityでエージェントレス型セキュリティ対策(ここでは不正プログラム対策を利用することを前提で記載していきます)を利用するためには以下の環境が必要となります。

  • VMware ESXi/vCenter
  • VMware NSX (NSX Manager / Guest Introspection)
  • Deep Security Manager(DSM)
  • Trend Micro Deep Security Virtual Appliance(DSVA)
  • VMware Tools(保護対象仮想マシンに導入)

そして、構成上重要になってくるのが、管理マネージャ群の連携です。vCenterとNSX Managerは1:1でコネクションを張ります。そして、DSVAを管理するDeep Security Manager(DSM)もvCenter、NSX Managerそれぞれとリアルタイムに同期を行うためのコネクションを張っています。

 

このvCenter – NSX Manager – DSMの連携によって、仮想マシンがどのESXiホスト上にいるのか、NSXのどういったセキュリティポリシーを適用するのかをといった情報をやりとりが可能となっています。仮想デスクトップ環境では、仮想デスクトップが生成されてからDeep Securityによってセキュリティ保護が完了するまでに以下のようなプロセスが発生します。

 

Horizon Connection Serverが仮想マシンの生成をトリガー

vCenterがそのリクエストに応じてマスターイメージから仮想デスクトップ(子仮想マシン)を生成

DSMがvCenterから新たに生成された仮想デスクトップの情報(仮想マシンの属性情報、配置されたESXiホストの情報など)を元にセキュリティポリシーを適用

 

ここで押さえておいていただきたいポイントは、Deep SecurityはあくまでvCenterから情報を取得しており、Horizon Connection Serverとは直接連携していない、という点です。言い換えると、Deep SecurityはvSphere/NSXとの連携が前提となっているため、Horizonの展開方式には依存せず、対応は可能な仕様になっているということです。(PowerShellやHorizon以外での仮想デスクトップの展開でもDSVAの利用が可能)。

 

インスタントクローンを利用する上で抑えておくべきポイント

今までDeep Securityをインスタントクローン方式の環境では導入を推奨できなかったのは、Deep Securityが「インスタントクローンに対応していなかった」のではなく、「インスタントクローンで生成される仮想マシンのスピードに追いつくことができなかった」というのが正確な表現になると思います。

インスタントクローン方式で同時に生成される台数がそれほど多くなければ問題はありませんでしたが、検証によって数百台単位で仮想デスクトップが「高速に」生成されることになった場合にDeep Securityのセキュリティの有効化処理が追いつかないケースが確認されたため、推奨しないというメッセージを出しておりました。(実際の環境では、Horizon Connection ServerからvCenterに対して同時に仮想マシンを生成できる上限がデフォルトでは制限されておりますので、100台単位で有効化処理が走ることは少ないと思いますが。)
このような背景がありましたが、今回、Deep Securityの新しいビルドで有効化処理がより効率的に処理ができることを確認できました。また、それに加えてチューニングやサイジングの見直しを頂くことで対応することも可能ですので、その方法を以下にご案内します。

 

【利用頂くことを推奨するDeep Securityのバージョン】

  • インスタントクローン方式を採用する環境では、Deep Security 10.0 Update5以降をご利用ください。

【サイジング・チューニングのポイント】

  • DSMに対するvCPUの割り当てを追加する(ジョブはCPU処理能力に依存)
    • DSMサーバに対するvCPUの追加
    • DSMサーバの増設(Multi DSM構成)
  • CPU処理能力を向上させるためのパフォーマンスプロファイルの変更
    • ジョブ処理を行える上限設定を明示的に引き上げるプロファイルをご用意しています。
      パフォーマンスプロファイルについては以下をご参照ください。
      https://help.deepsecurity.trendmicro.com/ja-jp/Reference/ref-performance.html?Highlight=パフォーマンスプロファイル
      CPU処理能力を向上させるためのパフォーマンスプロファイルは以下のFAQからダウンロードが可能です。
      http://esupport.trendmicro.com/solution/ja-JP/1119051.aspx
      ※パフォーマンスプロファイルについては、ソフトウェアの健全な動作担保のため、パフォーマンスプロファイル内のパラメータをお客様にて変更いただくことはお控えください。

 

まとめ

Deep Security 10.0 Update5以降をご利用いただくことによって、VMware vSphere/NSX+VMware Horizonの環境でインスタントクローン方式による仮想デスクトップの展開を行った場合にDeep Securityのエージェントレス型セキュリティ対策が安定してご利用いただけるようになりました。もちろん、引き続きフルクローン、リンククローン環境でのご利用も可能ですので、ぜひご活用ください。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

【VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化】

  1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策

 

VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(0)

こんにちは。VMware でパートナー様を担当させて頂いております SE の北村です。

昨年の2月から前回まで、「ちょっとした技術的な TIPs のご紹介」 という事で、Cloud Infrastructure Blog や End User Computing Blog にブログを投稿させて頂きましたが、今回からは今までと少し趣向を替えながら、みなさまのお役に立てる情報をお伝えしていきたいと思いますのでよろしくお願いします。

 

現在 (2018年2月8日)、Horizon は 7.4 というバージョンが提供されていますが、約 1年前の 2017年3月16日にリリースされた Horizon 7.1 から提供している JMP (Just-in-time Management Platform:「ジャンプ」 と読みます) という機能ご存知でしょうか?

参考情報:プレス リリース
ヴイエムウェア、新たなアプリケーションとデスクトップ仮想化製品により、デジタル ワークスペースの変革を加速

 

JMP テクノロジーは、Horizon 7 Enterprise Edition の機能を使い、パーソナライズされたデスクトップとアプリケーションを、柔軟、かつ、高速に提供する仕組みになりますが、その JMP は次のVMware テクノロジーで構成されています。

VMware Instant Clone:迅速なデスクトップおよび RDSH プロビジョニング
Instant Clone 機能は、vSphere vmFork テクノロジー (vSpehre には 6.0 Update 1 から実装) を活用して、実行中の親仮想マシンの静止、高速メモリ内クローニング、コピーオンライト (Copy-On-Write:書き換え時にコピーする方式) を使用して、仮想マシン (仮想デスクトップ、または、RDSH サーバ) を迅速に展開します。

VMware App Volume:リアルタイムでのアプリケーションの配信
App Volumes は、アプリケーションをオペレーティング システム (OS) から切り離し、仮想マシンに配信することで、アプリケーションのプロビジョニング工数を大幅に削減し、App Volumes Manager による一元的な管理を実現します。

VMware User Environment Manager:ユーザー、プロファイル、ポリシーの管理
Horizon のスマートポリシー機能を実現するために必須のコンポーネントでもあり、仮想/物理環境、および、クラウド ベースの Windows デスクトップ環境全体にパーソナライゼーションと動的なポリシー設定を提供します。

これらのテクノロジーを活用する事で、パーソナライズされたデスクトップやアプリケーションを高速に展開する仕組みとして期待されています。

 

ここで、セキュリティについて考えたいと思いますが、Horizon の仮想デスクトップのセキュリティ向上を考えた場合、VMware NSX for vSphere と、セキュリティ ソフトウェア ベンダー様のアンチウィルス ソフトウェア製品との連携ソリューションであるマイクロセグメンテーションがあります。

今まで、Horizon の Composer を使用して展開された仮想デスクトップのセキュリティの向上には、マイクロセグメンテーションを利用していたと思います。この形態は今後も引き続き利用されていくと思いますが、更に、JMP テクノロジーの構成要素の 1つである Instant Clone を使用した、柔軟、かつ、高速に展開された仮想デスクトップや RDSH サーバのセキュリティ向上にもマイクロセグメンテーションを利用していく事が考えられます。

 

そこで、次回 (来週を予定) からトレンドマイクロ株式会社の栃沢様に、【VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化】 というタイトルで数回にわたりブログを掲載頂きます。

最初となる次回は、「Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策」 というテーマでブログを掲載頂きますので、お楽しみに!

 

【VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化】

  1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策

 

以上です。

 

ちょっとした技術的な TIPs のご紹介 (2017.12)

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いております SE の北村です。
今回は、Cloud Infrastructure Blog に次の 3点について投稿したいと思います。

 

1. NSX Recommended Configuration Maximums (NSX 推奨構成の上限)
2. 3種類の新しい VMware NSX の本を発表!
3. VM Encryption と vSAN Encryption がサポートする KMS (Key Management Server) について

では、それぞれについて記載していきます。

 

1. NSX Recommended Configuration Maximums (NSX 推奨構成の上限)

vSphere では以前から公開されている “構成の上限 (Configuration Maximums)” ですが (こちら。PDF版はこちら)、NSX 6.3.3 から NSX Recommended Configuration Maximums という事で、PDF版が公開されました (こちら )。

以下に「1 Introduction」の内容を意訳してみました。ご参考まで。

1 イントロダクション
このドキュメントでは、NSX for vSphere の推奨構成の上限 (最大値) を示しています。 この文書を使用して製品の設計、導入、操作する場合は、次の点を考慮してください。

  • 仮想および物理機器を選択して構成する場合は、このマニュアルで説明するように、NSX for vSphere でサポートされている上限以下に留めることを強くお勧めします。
  • 次のセクションで示される制限は、テスト済みの推奨限度を表し、VMware が完全にサポートしています。
  • このガイドに記載されている制限は、NSX for vSphere に適用されます。 この制限は、ハードウェアの依存関係などの他の要因の影響を受ける可能性があります。 サポートされるハードウェアの詳細については、適切な NSX for vSphere のインストールおよび管理ガイドを参照してください。 ご使用の環境でサポートされている構成を超えないように、個々のソリューションの制限を調べてください。
  • 全ての構成設定を最大化しても、望んでいる結果を期待する事は出来ないかもしれません。
  • 推奨構成の上限は、NSX for vSphere の規模の理論上の可能性を表すものではありません。

 

2. 3種類の新しい VMware NSX の本を発表!

お伝えそびれていた情報になりますが、今年の VMworld U.S. 2017 に合わせて、次の 3種類 (4つ) の NSX 本 (英語の本です) を発表してまして、こちらのサイトから PDF 版を入手できます。ご興味がある方は、是非、ダウンロードしてください。

 

3. VM Encryption と vSAN Encryption がサポートする KMS (Key Management Server) について

vSphere 6.5 では、仮想マシンや仮想ディスクの暗号化機能 (詳細はこちら) が提供されていますし、vSAN 6.6 でも vSAN データストア内の全てを暗号化する機能 (詳細はこちら) が提供されています。

今回は、個々の機能説明はしませんので、詳細はそれぞれリンクされているドキュメントを参照してください。

今回お伝えしたいのは、それら新しい機能として提供されている暗号化ですが、VM Encryption も vSAN Encryption、いずれの機能も外部 KMS が必要です。では、これらの機能がサポートしている KMS をご存知でしょうか? 実は上記でリンクしたドキュメント内にはサポートする KMS についての詳細は記載されていません。それらは、HCLで公開されていて、以下からアクセスできます。

1) HCL <https://www.vmware.com/go/hcl> にアクセス

2) 検索カテゴリのプルダウンメニューから “Key Management Server (KMS)” を選択

3) VM Encryption、vSAN Encryption (vSAN Data at Rest Encryption) でサポートされている KMS 製品を確認

 

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。

 

 

シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!

シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!! ~導入構成編~

 

#第1回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~導入構成編~

 

#第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~電力消費量計算編~

 

#第3回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~2 Node vSAN 対応とよくある QA編~

 

◆はじめに

 

はじめして! シュナイダー エレクトリック APC UPS 管理製品担当 出口 (右) & 冨田 (左) です。

最近 IT業界全体で注目度の高い ハイパーコンバージドインフラ ( 略して HCI ) の代表的な製品 VMware vSAN と弊社 UPS 管理製品 PowerChute がシャットダウン連携できるようになりました。

 

vSAN を導入することで運用負荷やコストを下げられるというメリットを感じて導入を検討される方も多いとは思いますが、やはり 電源障害や停電対応にも対応した UPS がないと不安で導入できないという方もいらっしゃると思います。

 

ご安心ください!!既に連携ができます!! 

 

今回のブログでは、どのような構成がサポートされて、どのような仕組みで VMware vSAN & シュナイダー ( APC ) UPS 連携ができるのかをご紹介いたします!!

 

1.UPS と vSAN のシャットダウン連携のサポート構成

APC UPS では 以下に挙げる構成パターンで vSAN との連携が可能です。

 

[パターン1]

物理 Windows サーバー にPowerChute Network Shutdown ( 略 PCNS )と、Windows 版 vCenter Server をインストールするパターン

この構成は、Windows 版 vCenter Server に PCNS や他の管理系ソフトウェア(バックアップ、監視など)を同居させる場合にピッタリの構成パターンとなっています。

 

[パターン2]

vSAN クラスタ上に vCenter Server Virtual Appliance ( 略 VCSA ) をデプロイして、PCNS は物理 Windows サーバー にインストールするパターン

 

この構成では VCSA を vSAN クラスタ上に構成するシンプルなパターンで、Dell EMC 社 の VxRail に代表される vSAN を基盤とした HCI アプライアンスを導入される方にピッタリの構成パターンとなっています。

 

[パターン3]

vSAN クラスタとは異なる ESXi サーバー上に VCSA をデプロイして、PCNS は物理 Windows サーバー にインストールするパターン

 

この構成では VCSA を vSAN クラスタ上に配置しないで構成します。vCenter Server のような管理系のサーバーを vSAN クラスタとは異なる環境で構成したい方や、複数のシステムをやクラスタを vCenter Serverで統合管理されている方にピッタリの構成パターンとなっています。

 

これだけのパターンが網羅されていればどんな環境でも安心して vSAN を導入できますね (^^♪

2.vSAN 連携させるために必要なもの

各パターンごとにおける 必要なコンポーネントと機器サンプルは以下の通りです。
詳細な電源容量の計算などは次回のブログでご紹介します!!

[構成パターン1および2で必要なコンポーネント]

Smart-UPS 1500 RM 2U LCD (SMT1500RMJ2U)   ・・・・・・・・・・・・ 1

Network Management Card (AP9630J)    ・・・・・・・・・・・・・・・・ 1

Powerchute Network Shutdown for Virtualization (SSPCNSV1J)   ・・・・・  4

 

[構成パターン3で必要なコンポーネント]

Smart-UPS X 3000 Rack/Tower LCD (SMX3000RMJ2U) ・・・・・・・・・  1

Network Management Card (AP9630J) ・・・・・・・・・・・・・・・・  1

Powerchute Network Shutdown for Virtualization (SSPCNSV1J) ・・・・・  5

 

3.vSAN 連携時のシャットダウンシーケンス

シャットダウン時の流れは以下の様になります。

 

4.参考リンク

すでに vSAN を導入されている方も、これから導入を考えている方もぜひ、電源管理は シュナイダー UPS にお任せください!!

次回のブログでは「電源容量と耐久時間」や「製品の選び方のポイント」についてご紹介いたします。

では次回を乞うご期待ください!!

 

[vSAN & シュナイダー UPS 連携のKB (シュナイダー社リンクへ飛びます)]

PowerChute Network Shutdown の vSAN対応について

アプリケーションノート:PowerChute Network Shutdown for VMware

エンタープライズ クラスのKubernetes導入を実現するPivotal Container Service(PKS)

著者:製品ライン シニア マネージャ ナラヤン・マンダレーカ(Narayan Mandaleeka)/製品管理担当副社長 ポール・ダル(Paul Dul

米国時間2017年12月7日に公開されたブログ記事の抄訳です。

https://blog.cloud.vmware.com/s/content/a1y6A000000aG0KQAU/deploy-enterprisegrade-kubernetes-with-vmware-pivotal-container-service-pks

 

VMwareとPivotalは、エンタープライズ クラスのKubernetesソリューションを求める顧客向けに、12月中旬にPivotal Container Service(PKS)の提供を開始します。PKSはKubernetesの活用を望む企業やサービス プロバイダ向けの製品で、Kubernetesクラスタの導入や運用を大幅に簡素化します。PKSはVMware vSphere®で稼動するデータセンタやGoogle Cloud Platform(GCP)に導入可能で、最近ではCloud Native Computing Foundationが主催するKubernetes Software Conformance Certificationプログラムの認証を取得しました。

PKSの主な特長は以下の通りです。

  • 最新のオープンソース版Kubernetesに対応:PKSの初版リリースではKubernetes 1.8をベースにしており、開発者は独自の拡張設定を行わずにKubernetes APIにフル アクセス可能
  • 高度なコンテナ向けネットワークとセキュリティ:マイクロセグメンテーション、負荷分散、セキュリティ ポリシーなどの機能を備えたNSX-Tにより、Pod単位のコンテナ向けネットワークを実現
  • 安全性に優れたコンテナ レジストリ:脆弱性スキャンに加え、イメージへの署名や監査といった機能によりコンテナ ワークロードを保護
  • 迅速なプロビジョニング:開発者が迅速かつオンデマンドでKubernetesクラスタを作成可能
  • 高可用性:PKSが高可用性を備えており、インフラからアプリケーションまでのKubernetesクラスタを監視/管理することで高可用性を実現
  • GCPサービスを利用可能:GCPサービス ブローカーとの連携により、開発者はGCPサービスに簡単にアクセス可能
  • パーシステント ストレージ:ステートレス/ステートフルなアプリケーションの両方をKubernetesクラスタに導入可能

図 1: Pivotal Container Service

 

ネイティブなKubernetes APIを使用したマルチクラウド環境向けに開発されたPKSは、Google Kubernetes Engine(GKE)との互換性を維持しながら主要なKubernetesリリースをベースに開発されているため、開発者は最新かつ安定性に優れたKubernetesリリースを利用可能です。PKSは導入初日から運用開始までの課題をCloud Foundry Container Runtime(CFCR)を活用することで解決できます。このCFCRは、以前はKubernetesの運用支援ツールBOSH(またはKubo)として知られていたものです。BOSHにより、PKSは自動化やオーケストレーションの機能を活用してKubernetesクラスタの導入を簡素化できるだけでなく、高可用性と本番環境での導入に向けて、基盤となるインフラのヘルスチェックと自己修復などの機能を提供します。

 

BOSHを活用してKubernetesクラスタに必要なネットワーク設定全体を自動化することで、パフォーマンスの問題や、さらにはセキュリティ ホールの発生など、マニュアル設定により発生するエラーのリスクを排除できます。

 

NSX-Tを使用したネットワーク

PKSにはVMware NSX-Tが含まれており、Kubernetesクラスタのための高度なコンテナ ネットワークやセキュリティの機能を備えています。NSX-Tは、レイヤ2からレイヤ7までの、コンテナ/Pod単位のネットワークに必要とされる完全なネットワーク サービス群を提供します。これにより、企業は開発サイクルを中断することなく、マイクロセグメンテーションやオンデマンドのネットワーク仮想化によって素早くネットワークを導入できます。

 

またPKSにより、IT部門はCNCF認証のフルスタックのKubernetesコンテナ サービスを提供可能になります。このサービスにはネットワークやストレージのサービス、安全性に優れたコンテナ レジストリ、そしてサービス ブローカー機能などが含まれます。さらに、VMware vSAN™、VMware vRealize® Operations™、Wavefront® by VMwareをはじめとするVMwareのインフラ製品や管理製品とのカスタム統合も可能です。

PKSはライセンス付与、本番環境対応、VMware NSX-Tとの緊密な連携も可能です。

Pod単位のネットワーク、サービスへのアクセス、複数のレプリカの負荷分散など、NSX-TはKubernetesに必要なあらゆるネットワーク機能を提供します。Kubernetesの基本的なネットワーク機能に加えて、NSX-Tの多層ルーティング モデルを使用することで、ネットワーク セキュリティ ポリシーやテナント レベルでのアイソレーションなどの高度なネットワーク機能を実現します。

NSX-TをPKSと統合する際の重要な設計コンセプトの1つが、Kubernetesの各ネームスペースに固有の論理スイッチを割り当てることです。これによってKubernetesクラスタの各ネームスペースのトラフィックをセグメント化できるようになります。開発チームは、共有クラスタ内で専用Kubernetesネームスペースを使用して、他のチームからワークロードを確保できます。

図 2: NSX-Tはネットワークのアイソレーションと負荷分散機能を備えたPodネットワークを提供

安全なコンテナ レジストリ — Harbor

Harbor は、コンテナ イメージを格納/配布するオープン ソースのエンタープライズ クラスのレジストリ サーバです。本番環境の認証とロール(役割)ベースのアクセスにより、プッシュおよびプル イメージを提供します。また、統合的な脆弱性スキャン、イメージ信頼サービス、イメージ レプリケーション サービスなどの主要なレジストリ サービスも提供します。

 

Harborを利用することで、アプリケーション導入のためのコンテナ イメージを安全にKubernetesクラスタにダウンロードできます。HarborのレジストリはCI/CDパイプラインで本番環境レベルのイメージ リポジトリを可能にします。顧客は、アプリケーション リリースの自動化プロセスの一環として、コンテナ イメージを安全にHarborに取り込めます。これらのイメージに対し、アプリケーションのワークロード導入プロセスの一環としてHarborが脆弱性スキャンを実行し、署名承認を行った後にKubernetesクラスタに取り込むことが許可されます。

 

その結果、開発チームはアプリケーションをプラットフォームに迅速に導入し、IT部門は企業のセキュリティ要件を確実に満たすようにコンテナ イメージをコントロールできます。

図 3: Harborは、PKSが管理するKubernetesクラスタにイメージを導入するために使用される

Harborの統合コンテナ レジストリの使用を推奨しますが、PKSはそれ以外のコンテナ レジストリも使用可能です。

パーシステント ストレージとvSphere Cloud Providerプラグイン

PKSなら、Kubernetesクラスタをステートレス/ステートフルのどちらのアプリケーションでも展開可能です。Project Hatchwayを通じて、KubernetesではVMware vSphere Storage for Kubernetesプラグインをサポートしているため、PKSはVMware vSphereストレージ上でKubernetesストレージ プリミティブに対応しています。ストレージ プリミティブには、ボリューム、パーシステント ボリューム、パーシステント ボリューム クレーム、ストレージ クラス、ステートフル セットが含まれます。また、ストレージ プラグインはエンタープライズ クラスのストレージ機能も備えています。例えば、VMware vSANを使用することで、Kubernetesクラスタで実行しているアプリケーションに対して、ストレージのポリシー ベースの管理を拡張できます。

 

GCPサービス ブローカー

PKSには、GCPサービスにすぐにアクセス可能なサービス ブローカーが含まれています。サービス ブローカーを活用することで、運用者は選択したGCPサービスを公開し、開発チームがkubectl CLIまたはAPIで「サービス インスタンス」を作成および管理することで、GCPサービスをプロビジョニングして使用できるようになります。GCPサービス ブローカーは、Google Cloud Storage、Google BigQuery、Google StackdriverなどのGCPサブスクリプション サービスにも対応しています。これらのサービスは、オンプレミスまたはGCP内で実行しているアプリケーションで使用することも可能です。

 

PKSのサポート

PKSのユーザは本番環境レベルのサポートを受けることができます。PivotalとVMwareは、世界レベルのグローバル サポート サービスの提供を通じて、最も要求の厳しい本番環境のニーズに応えます。

注:PKSの利用にはVMware vSphere 6.5が必要です。

 

Pivotal Container ServicePKS)に関する詳細情報(英語)

Pivotal Container Serviceに関する詳細は、以下をご覧ください。

https://cloud.vmware.com/pivotal-container-service

 

NSX-T 2.1リリースに関する詳細は、以下をご覧ご確認ください。

http://blogs.vmware.com/networkvirtualization/2017/11/nsx-t-2-1.html/

 

Pivotal Cloud Foundry 2.0に関する詳細は、以下をご覧ご確認ください。

https://content.pivotal.io/announcements/pivotal-unveils-expansion-of-pivotal-cloud-foundry-and-announces-serverless-computing-product

ここが変わった! VMware vSphere 6.5 Part 6

 

日本ヒューレット・パッカード株式会社の中川明美です。

今回は、vSphere 6.5でアップデートされたvSphere DRSの次の機能をご紹介します。

  • Predictive DRSの有効化
  • その他のオプション
    • 仮想マシンの分散
    • ロードバランシングのためのメモリメトリック
    • CPUオーバーコミットメント

vRealize Operationsと連携し、予測メトリックに基づいてリソースをバランシングするPredictive DRSは、vRealize Operationsのさらなる活用がけん引できそうですね。

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

◆Predictive DRS◆

Predictive DRSは、vSphere DRSとvRealize Operations (以降vROps) を連携し、仮想マシンの配置とリソースのバランスを決定する機能です。

vROpsは、履歴データに基づき、近い将来の仮想マシンの予測ワークロードを分析します。vROpsではトレンドとして表示されます。

vSphere DRSは、現在の使用値 (リアルタイムメトリック)に加え、予測ワークロード値(予測メトリック)にも対応し、仮想マシンからリソースが要求される前に、仮想マシンの配置を決定することができます。

 

Proactive DRSは、vSphere 6.5 + vROps 6.4以降の環境で使用できます。

下図の画面から、Predictive DRSを有効化します。

Proactive DRSはタイムリーな移行のために1時間前 (デフォルト) の値を使用します。

 

状況によって、移行を判断するメトリックが異なります。

<現在の使用率が予測使用率を上回る場合>

現在の使用率が優先され、この値を使用して推奨が生成されます。

 

<予測使用率が現在の使用率を上回る場合>

予測使用率の値が仮想マシンの現在のデマンドとして使用されます。このデマンド値を基に、仮想マシンからリソースが要求される前にリソースが利用できる状況にします。要求前に対応するため、パフォーマンスへの影響を軽減します。

 

◆その他のオプション◆

vSphere 6.5では次の3つのAdvanced Optionsが追加されています。

<仮想マシンの分散:TryBalanceVmsPerHost>

ESXiホスト間で仮想マシンの数を均等に分散します。

DRSにより1台のESXiホスト上に多くの仮想マシンが配置される場合があります。その状況でvSphere HAが動作した場合、分散された仮想マシンと比べ、多くの仮想マシンの再起動が必要になります。このような状況を回避する際に、仮想マシンの分散は有効です。

このオプションを設定すると、各ESXiホストにはロードバランシングmaxVMsの制限が与えられます。この制限は、ロードバランシングにのみ適用されます。

 

<ロードバランシングのためのメモリメトリック>

ESXiホスト上のメモリ負荷を計算する時、「有効なメモリ」ではなく「消費されたメモリ」メトリックを使用します。

オーバーコミットされている環境では有効なメモリが適しています。有効なメモリは、アイドルメモリの25%が加算され、負荷を計算します。

オーバーコミットされていない環境では、このオプションを選択し、消費されたメモリを使用してバランシングすることもできます。

 

※仮想マシンのメモリメトリック

「有効なメモリ」はゲストOSが使用している物理メモリ量、「消費されたメモリ」は仮想マシンによって使用されるゲスト物理メモリ量 (共有メモリのうち該当の仮想マシン分を含む) を表します。

<CPUオーバーコミットメント: MaxVcpusPerClusterPct>

クラスタ内で仮想CPUと物理CPUの比率を設定し、オーバーコミットを制御します。オプションで定義された値に達すると、追加の仮想マシンをパワーオンことはできません。

オーバーコミットメント率(最小0/最大500)は、次を参考にしてください。

  • 0-99% 1vCPU未満:1pCPU (コア) ※オーバーコミットしない
  • 100% 1vCPU:1pCPU (コア)
  • 500% 5vCPU:1pCPU (コア)

このオプションはクラスタが対象です。ESXiホストを対象とする場合は「MaxVcpusPerCore」で指定します。

 

 

追加機能ではありませんが、改良点をご紹介します。

◆DRS移行のしきい値

6.5では、移行のしきい値に従来のCPUとメモリに加え、物理NICの使用率が加わりました。

CPUとメモリの統計値から移行の可否を判断することに変わりはありません。初期配置および負荷分散のために移行先のESXiホストが選択されると、次にDRSはその移行先が最適かを判断するために、ネットワーク使用率をチェックします。

移行先のESXiホストに接続される物理NICの使用率が80% (デフォルト値) を超えていれば、最適な配置ではないと判断し、別のESXiホストを使用します。

ネットワーク使用率のしきい値は、「NetworkAwareDrsSaturationThresholdPercent」で変更します。

 

 

◆vSphere DRSに関する情報◆

vSphere 6.5のDRSについての詳細な情報は、こちらを参照ください。

こちらのBlogでは取り上げなかった、パフォーマンス向上のための改良点についても述べられています。

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/drs-vsphere65-perf.pdf

 

アップデートされたDRSについては終了です。

 

 

ここからは、クラスタからESXiホストを削除する方法をご紹介します。

「メンテナンスモードにしなければクラスタからESXiホストを削除できないのですかと尋ねられることがあります。こちらで紹介する方法は、仮想マシンをシャットダウンできない場合にお試しください。可能なら、メンテナンスモードに移行後、クラスタから削除ください。

 

◆クラスタからESXiホストの削除◆

メンテナンスモードに移行せず、ホストをインベントリから除去すると、次のメッセージが表示されます。

ESXiホストをvCenter Serverから切断すると、メンテナンスモードに移行せず、ESXiホストをインベントリから除去することができます。

ESXiホストを右クリック→接続→切断と操作します。

次のメッセージの内容を確認の上、操作を進めてください。

切断後、インベントリの除去を行うと、次のメッセージが表示され、ESXiホストをクラスタから削除することができます。

ドラッグアンドドロップで、データセンター配下に置くこともできます。

◆まとめ◆

「ここが変わった! VMware vSphere 6.5」のすべての回が終了しました。

vSphereもバージョンが上がるたびに様々改善されていますね。今回取り上げた機能を使用すると、運用管理面が強化されるように思います。特にHAやDRSは、ホスト障害およびパフォーマンス低下に備えて、予防しましょうというメッセージを感じます。

今後は、HAとDRSの併用を前提に、構築設計していく必要があるのかもしれませんね。

また、「VMware Cloud on AWS」が発表され、Hybrid Cloud環境がけん引されそうですね。vRealize製品も注目を集めそうです。機会がありましたら、vRealize製品のBlogも投稿できたらと思います。

 

ここが変わった! VMware vSphere 6.5 Part5

日本ヒューレット・パッカード株式会社の中川明美です。

今回は、vSphere 6.5でアップデートされたvSphere HAの次の3つの機能についてご紹介します。

  • Proactive HAの構成
  • ホスト障害への応答
  • 仮想マシンで許容するパフォーマンス低下

 

vSphere HAはvSphere基盤の可用性を提供する重要な機能です。運用に関わるエンドユーザー様を対象にトレーニングを実施してきた私には、追加された3つの機能はエンドユーザー様の声を反映したアップデートではないかという印象を受けます。

Enterprise Plusで提供されるDRSやサーバーのPluginが前提となる機能もありますから、ご提案時にはこれらの機能もふまえ、ご紹介いただけたらと思います。

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

◆Proactive HAの構成◆

ホストを構成するハードウェアの障害により健全性が低下した時、どのように仮想マシンを保護するかを構成する機能がProactive HAです。

詳細には、ハードウェア障害の情報をProactive HAプロバイダからvCenter Serverが受け取り、vCenter ServerはProactive HAの構成内容をDRSへ知らせ、仮想マシンを移行します。

たとえばファンに障害が発生し健全性が低下した場合、仮想マシンの移行によって可用性が提供されます。Proactive HAプロバイダは、サーバーベンダーから提供されます。

 

<Proactive HAの有効化>

Proactive HAはvSphere HAの編集画面で、「Proactive HAをオンにする」を選択します。仮想マシンの移行(vMotion)により仮想マシンを保護するため、DRSの有効が前提となります。

<Proactive HAの構成>

構成には、「自動化レベル」と「修正」の2つがあります。「自動化レベル」では仮想マシンの移行方法を、「修正」では健全性が低下したホストの使用可否を指定します。

<自動化レベル>

「手動」と「自動化」があります。

  • 手動:DRSと同様に仮想マシンの移行先が推奨されます。
  • 自動化:仮想マシンは健全なホストに移行され、健全性が低下したホストは検疫モードまたはメンテナンス モードにしたがい使用の可否が決まります。 

<修正>

「検疫モード」「混合モード」「メンテナスモード」があります。

  • 検疫モード:一部のハードウェア(メモリ/ネットワーク/ストレージ等)の障害にともない、性能が低下したホストを使用しません。ただし、仮想マシンのパフォーマンスに影響がない範囲においてです。
  • 混合モード:検疫モードの状態に加え、重大な障害が発生したホストは使用しません。
  • メンテナンスモード:一部のハードウェアに障害が発生したホストは使用しません。

<Proactive HAプロバイダ>

ホストの健全性をチェックするには、サーバーベンダーが提供するProactive HAプロバイダが必要です。Proactive HAプロバイダに対応する vSphere Web Client プラグインをインストールすると、Proactive HAプロバイダが表示されます。プロバイダを選択後、Proactive HAプロバイダは有効になります。

※Proactive HAプロバイダ

HPEサーバーは、「OneView for VMware vCenter」を導入します。Proactive HAに対応するOneViewは2017年11月提供予定です。

Dellサーバーは、「OpenManage Integration for VMware vCenter」を導入します。

Proactive HAプロバイダの詳細については、各サーバーベンダーへお問い合わせください。

 

◆ホスト障害への対応◆

vSphere 6.5では、vSphere HAによる再起動のオーケストレーション(Orchestration)を設定することができます。再起動の優先順位と仮想マシン間の依存関係を構成することによって、より詳細な再起動の順序を指定することができます。

下図はクラスタの設定画面です。

仮想マシンは、次の条件を満たすと他のホストへの配置や再起動の準備が整います。

  • 他のホストに仮想マシンのリソースが予約されている
  • 仮想マシンはパワーオンしている
  • VMware Toolsのハートビートが検出される
  • VMware Toolsアプリケーションのハートビートが検出される

 

各仮想マシンの設定は、「設定」の「仮想マシンのオーバーライド」を使用します。設定対象の仮想マシンを追加します。

<仮想マシン再起動の優先順位>

優先順位は5つのレベルがあります。優先順位が高い仮想マシンを再起動後、次に優先順位が高い仮想マシンを再起動します。

ただし、次の場合は異なります。

  • エージェント仮想マシンは最初に起動する
  • vSphere FTのセカンダリ仮想マシンは、他の仮想マシンより優先される

<優先度が次に高い仮想マシンを次の場合に起動/遅延時間の追加>

依存関係は、再起動の優先順位と特定の条件に一致した場合の遅延時間で指定します。

「割り当てられたリソース」「パワーオン」「検出されたゲストのハートビート」「検出されたアプリケーションのハートビート」のいずれかの条件を満たした後、指定された遅延時間を待って、次に優先順位の高い仮想マシンを再起動します。

 

<または次におけるタイムアウトの発生後>

指定した条件が満たされない場合はタイムアウトになります。指定したタイムアウト値までに条件が満たされなければ、vSphere HAは次に優先順位の高い仮想マシンの再起動へ進みます。

 

<仮想マシングループ間アフィニティルールを利用した依存関係の構成>

依存関係を構成するには、仮想マシングループ間のルールを利用することもできます。

特定の順序で再起動しなければ正常に復旧しない複数層のアプリケーションには有効です。一般的な例として、DB>>App>>Webの3階層システムがあります。

たとえば、障害があったホスト上にDB仮想マシンとWeb仮想マシンが稼働し、障害のないホスト上でApp仮想マシンが稼働していたとします。vSphere HAはDBとWebの仮想マシンはフェイルオーバーしますが、Appの仮想マシンは再起動しません。このような状況を回避する方法として、仮想マシングループ間のルールを利用します。

ただし、このルールには、DBが再起動しなければAppは再起動しないという課題があります。その場合は、手動でDBの仮想マシンを起動します。

vSphere HAはホスト障害に対する可用性を提供する機能のため、このような課題は発生します。今後のさらなる改善が期待されます。

 

◆仮想マシンで許容するパフォーマンス低下◆

本題に入る前に、アドミッション コントロールの選択方法がわかりやすくなりましたね。

許容するホスト障害の台数を指定し、その後はフェイルオーバー時のリソース予約をするか否か、するのであれば3つのうちのどの方法で予約するのかという流れになっています。

さらに、クラスタのリソース使用率がフェイルオーバー キャパシティの割合を超えた場合、警告を表示する機能が追加されました。この機能は、クラスタリソースの使用状況を取得するために、DRSを有効にする必要があります。

 

下図のvSphere HAクラスタはESXiホスト2台で構成し、「クラスタで許容するホスト障害」を1台に設定しています。

フェイルオーバー リソースの自動計算により、CPU50%/メモリ50%がフェイルオーバーキャパシティとして予約されています。

「仮想マシンで許容するパフォーマンス低下」でしきい値を「0」%に設定すると、クラスタのリソース使用率がフェイルオーバーキャパシティを超えた時、クラスタの「サマリ」タブに下図の警告が表示されます。この警告によって、リソース不足によって仮想マシンが再起動されない状況を回避することができそうですね。

◆まとめ◆

vSphere HA 6.5で追加された機能は、「ESXiホストの障害時にあわてなくても大丈夫。追加機能を活用して可用性を高めましょう。」と言われたような気がしました。「備えあれば患いなし」という言葉が浮かびます!

「Proactive HA」および「仮想マシンで許容するパフォーマンス低下」はDRS機能を前提とするため、Enterprise Plusのライセンスが必要です。vSphere 6.5へUpgradeを検討されていらっしゃるエンドユーザー様は、運用の効率性も見据えてご検討いただければと思います。

次回は、vSphere DRSでアップデートされた機能をご紹介します。個人的にはvRealize Operations Managerと連携する「Predictive DRS」にとても興味があります。

予算が許されるなら、「vSphere with Operations Management (vSOM)」を検討したいですね!

 

ここが変わった! VMware vSphere 6.5 Part4

日本ヒューレット・パッカード株式会社の中川明美です。

今回は、vSphere 6.5で使用可能な3つの管理ツールについてご紹介します。

vSphere 6.5から、「VMware Host Client (HTML5 バージョン)」と「vSphere Client (HTML5 バージョン)」が新たに提供され、「vSphere Web Client (Flex/Flash バージョン)」はパフォーマンスと操作性が改良されています。

WindowsアプリケーションのvSphere Clientは、vSphere 6.5から使用不可となりました。

https://blogs.vmware.com/vsphere/2016/05/goodbye-vsphere-client-for-windows-c-hello-html5.html

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

◆3つの管理ツール◆

vSphere 6.5で使用可能な3つの管理ツールの違いを確認します。

vSphere 6.5からは、ESXiホストを管理するために「VMware Host Client (HTML5バージョン)」を、vSphere基盤を管理するために「vSphere Web Client (Flex/Flash バージョン)」および「vSphere Client (HTML5 バージョン)」を使用します。

 

◆VMware Host Client (HTML5バージョン)◆

VMware Host ClientはvSphere Web Clientと類似したユーザーインターフェイスです。慣れた画面構成で、初めて使う方でも操作に迷うことはほとんどないと思われます。

また、1台のESXiホストを管理するツールのため、vCenter Serverで提供される機能は表示されません。特別な設定も必要とせず、サポートされるWebブラウザを準備するのみです。

次のアドレスを使用して、Host Clientへ接続します。

https://ESXiホストのFQDNまたはIPアドレス/ui

 

Host Clientは、vSphere 6.0 Update 2 以降から使用可能です。vSphere 6.0を運用管理されているユーザーの方もぜひ試用してみてください。

私個人としては、HTMLベースのHost Clientは、ダウンロード等の事前準備が必要ないこと、vSphereバージョンごとの導入が必要ないことをメリットと感じます。

 

 

◆vSphere Client (HTML5バージョン)◆

vSphere Clientは、HTMLベースのため、Adobe Flash Playerのインストール(Adobe Flexの有効)は必要ありません。Host Client同様、対応のWebブラウザがあれば使用可能です。

次のアドレスを使用して、vSphere Client (HTML5)へ接続します。

https://vCenter ServerのFQDNまたはIPアドレス/ui

 

vSphere Client (HTML5)は未サポートの機能もあります。vSphere 6.5 Update 1から標準的な機能が追加されています。

<vSphere 6.5 Update 1の未サポート/サポート機能>

https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-client-65-html5-functionality-support.html

 

先日vRealize Operations Managerのトレーニングテキストを作成するために、テスト環境を構築しました。その環境では、Adobe Flash Playerのインストールができなかったため、vSphere Client (HTML5) の使用を試みました。標準的な機能を使用するのであれば十分ですね。全機能の移行が待たれます。

 

 

◆vSphere Web Client (Flex/Flash バージョン)◆

vSphere 6.5から、vSphere Web Clientがすべての機能やプラグインを提供する管理ツールとなります。

Web Clientは、Adobe Flash Player 16以降のインストール、およびサポートされるWebブラウザを準備する必要があります。

次のアドレスを使用して、vSphere Clientへ接続します。

https://vCenter ServerのFQDNまたはIPアドレス/ vsphere–client

 

vSphere 6.5のWeb Clientの改善点をいくつか挙げます。

 

1.ユーザーインターフェイス

vSphere 6.5では、「はじめに」「監視」「構成」のタブで構成されています。以前の「管理」から「構成」へタブが変更されています。vCenter Serverのwebclient.propertiesを編集し、「管理」タブへ戻すことも可能です。

Web Client 6.5では、WindowsアプリケーションのvSphere Clientに近いメニュー構成に変更されています。以前と比べ階層が1つ減り、操作性が改良されています。

 

<Web Client 6.0>

<Web Client 6.5> ※下図は、vSphere 6.5 Update 1の画面ショットです

2.クライアント統合プラグイン

vSphere 6.0以前のバージョンでは、次の機能を実行するために、クライアント統合プラグインが必要でした。6.5では不要です。小さな改良ですが、嬉しい改良点ですね。

  • OVFファイルのインポート/エクスポート
  • データストア内のファイルのアプロード/ダウンロード

 

3.拡張認証プラグイン

拡張認証プラグインは、vSphere 6.0以前のクライアント統合プラグインの後継機能です。

拡張認証プラグインは、統合 Windows 認証と Windows ベースのスマート カード機能を提供します。この2つの機能のみが、以前のクライアント統合プラグインから引き継がれます。

以前のクライアント統合プラグインとvSphere 6.5の拡張プラグインの間で競合は発生しません。

 

4.その他のプラグイン

VMware Site Recovery Manager (SRM) プラグインはバージョン 5.8からWeb Clientへ完全に移行します。

参考までに、VMware Update Manager (VUM) プラグインは、vSphere 6.0 Update 1からWeb Clientで使用可能です。

 

 

◆vSphere Client (HTML5)の情報◆

vSphere Client (HTML5) と vSphere Web Client 6.5 の FAQ

<英語版>

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147929

<日本語版>

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2148759

 

vSphere Client (HTML5)で使用可能な機能の最新情報はこちらでご確認ください。

https://labs.vmware.com/flings/vsphere-html5-web-client#changelog

 

 

◆まとめ◆

VMware Infrastructure 3.5からのユーザーである私には、使い慣れたツールであるWindows アプリケーションのvSphere Clientが廃止されるのは少々寂しい気持ちになります。しかし快適な使用環境へ移行しているのですから、喜ばしいことです。

vSphere 5.1からの新機能はWeb Clientから提供され、vSphere 6.5でvSphere ClientからWeb Clientへ完全に移行されました。また先に述べたように、Web Client 6.5ではメニュー構成も改良されています。覚えたメニューの配置が変わるのは、慣れるまで時間を要しますが、よりよい変更のためですからね!

次回はvSphere HAです。vSphere HAはvSphere 5.0で大きくアーキテクチャーを変更し、その後も小さな改良が見られます。私個人はバージョンが上がるたびにVMware社がvSphere HAの改善を追求していると感じます。vSphere HAは運用において重要な機能ですからね。次回も参考にしていただければ幸いです。

 

ちょっとした技術的な TIPs のご紹介 (2017.09)

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いてますSEの北村です。

今回は、Cloud Infrastructure Blogに次の 2点について投稿したいと思います。

1. vRealize Operations Manager のサイジングについて
2. vSAN Ready Node について

では、それぞれについて記載していきます。

 

1. vRealize Operations Manager のサイジングについて

みなさん、vRealize Operations Manager (vRealize Operations for Horizonを含む) のサイジングのガイドラインとして、以下の KB (Knowledge Base) を公開しているのはご存知でしょうか?

vRealize Operations Manager Sizing Guidelines (2093783)
vRealize Operations Manager のサイズ変更のガイドライン (2124497)

注:KBの英語版に更新が入っても、ローカライズ版には反映されなかったり、更新が遅れたりする場合が多々ありますので、日本語版 (もローカライズ版の1つになります) は参考情報という扱いでご参照頂きたく存じます。

vRealize Operations Manager (vR Ops) は、仮想環境のリソース使用状況のデータを収集し、独自のアルゴリズムで分析した結果から、リソースの使用状況が健全かどうかを可視化したり、未来のリソース使用状況を予測したり、動的閾値を用いて必要に応じてアラートをあげるといった事などを可能にする製品ですが、仮想環境の規模に応じて収集すべき対象のデータが多くなったり、収集したデータの保持期間 (デフォルトでは180日) に応じて蓄積するデータが多くなったりと、それらデータを格納する為にはそれなりのディスク容量が必要となってきます。また、収集した大量のデータを分析するには、CPU や メモリ といったリソースも必要です。

と言う事で、実際にデプロイすべき vR Ops の仮想アプライアンスはどれくらいのスペック (CPU、メモリ、ディスク) を保持していればいいのか、という点をガイドしているのが上記の KB になります。実際は、上記の KB 内で、 vR Ops のバージョンに対応した KB のリンクを公開しており、その KB 内で、各バージョンでのサイジングのガイドライン、および、エクセルのサイジング・ツールを添付しています。

例えば、KB 2093783 の中で、vR Ops 6.4 の場合は、KB 2147780 を参照となっています。KB 2147780 にアクセスすると、vR Ops を展開する際の仮想アプライアンスのサイズ (Small / Medium / Large など) や、それに伴う展開された際の仮想アプライアンスのスペック、および、注意事項 (Note) の記載と、エクセルのサイジング・ツールが添付されています (KB 2147780 には 2147780_vRealizeOperationsManagerSizingFor6.4_v2.xlsx が添付されています)。

添付のエクセルには、幾つかのシートがありますが、簡易サイジングであれば、Sizing Guide (Basic) シートをお使い頂き、より詳細なサイジングの場合は、使用する Management Pack 等に応じて必要な他のシート (xxxxx Input という名称のシート) のインプット (水色) のセル部分に数値を入力して、Advanced – Results シート (このシート内にもインプットのセルはありますのでご注意ください) を結果として参照します。

是非、これらの KB を vR Ops のサイジングに役立てて頂ければと思います。

 

2. vSAN Ready Node について

さて、vSAN を語る上で、必ずと言っていい程出てくる言葉があります。それは vSAN Ready Node という言葉なのですが、みなさん、この vSAN Ready Node とは何の事かご存知でしょうか?

vSAN ReadyNode は、VMware Hyper-Converged Infrastructure ソフトウェア用に事前設定され、テストされ、認定された全ての主要なサーバーベンダーから入手可能な x86 サーバーで、各 ReadyNode は、必要な CPU、メモリ、ネットワーク、I/O コントローラ、ストレージ (SSD、HDD、または、フラッシュデバイス)で vSAN 用に最適に構成されています。また、構成プロファイルとして、サーバ ワークロード向けと、VDI ワークロード向けのプロファイルが用意されており、導入するシステムのワークロード、規模に合わせて選べるようになっています。

vSAN Ready Node の確認や、構成プロファイルの確認はそれぞれ以下で可能です。

VMware Compatibility Guide – vSAN Ready Node
vSAN ハードウェア クイック リファレンス ガイド

では、この vSAN Ready Node で定められたハードウェア・コンポーネントをカスタマイズする事は弊社のサポート的に許されているのでしょうか?

2014年3月11日に vSphere 5.5 Update 1 のリリースに伴い、vSAN 1.0 (当時は Virtual SAN という名称でした) が正式にリリースされましたが、当時は vSAN Ready Node をカスタマイズする事は想定しておらず、vSAN Ready Node として構成されたハードウェア・コンポーネントを使用する事がサポートの前提でした。ところが、この点が今年の春 (具体的には以下のブログが公開された2017年3月14日) から緩和され、以下のブログ (英語) で公開されている範囲でのカスタマイズが認められるようになりました。

What You Can (and Cannot) Change in a vSAN ReadyNode

詳細については上記のブログを参照頂きたいのですが、参考情報と言う事で、以下に上記ブログ内にも記載されている vSAN Ready Node から変更可能なパーツについて、一部補足情報を加えて掲載しておきます。

参照リンクのみこちらにもピックアップしておきます:
https://blogs.vmware.com/virtualblocks/2017/01/18/designing-vsan-disk-groups-cache-ratio-revisited
https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan
https://kb.vmware.com/kb/2145210

この点 (vSAN Ready Node) について、弊社の製品担当 SE もブログで触れていますので、以下のブログもチェックしてみてください。以下のブログでは、私が今回テーマとして挙げた vSAN Ready Node 以外の vSAN ネタについて掲載されていますので、それらも是非、参考にして頂けると幸いです。

ReadyNode – もう始める準備はできています。

 

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。

 

ちょっとした技術的な TIPs のご紹介 (2017.08)

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いてますSEの北村です。

今回は、Cloud Infrastructure Blogに次の 3点について投稿したいと思います。

1. vSphere の特定バージョンとの相互運用性を意識した弊社製品の更新手順について
2. Nexus 1000v から vDS への移行について
3. vSphere 6.5 の EOGS (End Of General Support) の延長について

では、それぞれについて記載していきます。

 

1. vSphere の特定バージョンとの相互運用性を意識した弊社製品の更新手順について

vSphere の上で動作する弊社製品 (Horizon、NSX など) が混在する環境において、vSphere の特定バージョンとの相互運用性を意識した弊社製品の更新手順の説明をしている KB (Knowledge Base) があります。この KB で更新する製品の順番を確認できますので、参考にしてみてください。

vSphere 6.5 へ更新する場合:
・Update sequence for vSphere 6.5 and its compatible VMware products (2147289)
・vSphere 6.5 およびその互換性のある VMware 製品の更新手順 (2148021)

vSphere 6.0 へ更新する場合:
・Update sequence for vSphere 6.0 and its compatible VMware products (2109760)
・vSphere 6.0 およびその互換性のある VMware 製品の更新手順 (2113872)

注:英語版に更新が入っても、ローカライズ版には反映されなかったり、更新が遅れたりする場合が多々ありますので、日本語版 (もローカライズ版の1つになります) は参考情報という扱いでご参照頂けると幸いです。

 

2. Nexus 1000v から vDS への移行について

その昔、弊社がサードパーティ仮想スイッチ (Nexus 1000v) を OEM 販売していたのですが、OEM の終了に伴い、以下の KB (FQA:Frequently Asked Questions 形式) が公開されています。

・Discontinuation of 3rd party vSwitch program (2149722)
・サード パーティ vSwitch プログラムの終了 (2150173)

—– KB 2149722 (英語) から抜粋 —–
Will VMware support the migration of Nexus 1000V to VDS?
Yes, customers can use a free migration tool developed by VMware. They can reach out to Global Support and Services (GSS), or engage the VMware professional services organization (PSO). Migration documentation and the migration tool is available for download.
——————————————

—– KB 2150173 (日本語) から抜粋 —–
vSwitch の移行を支援するため、VMware では、Nexus 1000v から Distributed Switch に移行するための無償の移行ツールを提供しています。さらに、VMware Professional Services Organization が、サード パーティ vSwitch から Distributed Switch に移行するサービスをお客様に提供することができます
——————————————

上記、抜粋の中で太字 (ボールド) にしている 「free migration tool」 や 「無償の移行ツール」 は次の手順で入手できますので、実際に移行を行う場合や、検討されている場合は、是非、ダウンロードして活用してみてください (もしくは、ツールを使わないまでも、同梱されている Migration Guide (PDF ドキュメント) は参考になると思います)。

英語のダウンロード・サイトへアクセス。

②検索ボックスに “nexus 1000v vds” と入力して検索。

③検索結果ページの (恐らく) 1つ目にリストされている “VMware vSphere > Drivers & Tools > Migration tool – Nexus 1000v to VDS” をクリック。

④表示されたページで Download ボタンをクリックします。

⑤MyVMwareにログイン後にダウンロードが開始されます。

⑥ダウンロードした 「MigrationTool_Nexus1000v_to_VMWare_VDS.zip」 を展開すると以下のファイルがあります。

補足情報:
2017年7月27日にリリースされた ESXi 6.5 Update 1 のリリースノートで、サードパーティ製の仮想スイッチ・プログラムと、サードパーティ製の仮想スイッチで使用されていた VMware vSphere API が vSphere 6.5 Update 1 の次のリリースで廃止される予定との発表がされています (VMware ESXi 6.5 Update 1 リリース ノートの内で詳細は KB2149722 参照との記載がされています)。

 

3. vSphere 6.5 の EOGS (End Of General Support) の延長について

一部の方は既にご存知かも知れませんが、2017年7月27日に vSphere 6.5 Update 1 がリリースされたタイミングで、vSphere 6.5の EOGS が延長され、vSphere 6.0.x と vSphere 6.5.x で、EOGS の日付が次の様に変更となりましたので、ご留意ください。

・ vSphere 6.0.x の EOGS は 2020年3月12日 (以前の vSphere 6.x の EOGS と同じ日付)
・ vSphere 6.5.x の EOGS は 2021年11月15日 (vSphere 6.5.x の EOGS として延長された日付)

詳細は、VMware Lifecycle Product Matrix  を参照下さい (ちなみに、このリスト内で参照頂く製品名は、ESXi 6.0 や ESXi 6.5 の行です)。

補足情報:
サポートを購入頂いているお客様には、General Support 期間中、メンテナンス アップデートとアップグレード、不具合、セキュリティの修正、および、技術的な支援が提供されますが、EOGS (End Of General Support) とは、その General Support  期間の終了を指しています。詳細はこちらをご参照ください。

 

今回、お伝えした内容も、日々の活動の中で、広くお伝えした方がいいかなと思う点をピックアップしてブログにさせて頂きました。

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。