Home > Blogs > Japan Cloud Infrastructure Blog > タグ別アーカイブ: a_bit_of_technical_tips

タグ別アーカイブ: a_bit_of_technical_tips

ちょっとした技術的な 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 製品を確認

 

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

 

 

ちょっとした技術的な 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  期間の終了を指しています。詳細はこちらをご参照ください。

 

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

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

 

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

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

今回は、Site Recovery Manager (SRM) のコンパチビリティに関連した次の2点について、Cloud Infrastructure Blog に投稿したいと思います。

1. SRM がサポート対象としている vCenter Server と ESXi のバージョンについて
2. SRM の Guest Operating System Customization Support について

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

 

1. SRM がサポート対象としている vCenter Server と ESXi のバージョンについて

例えば、SRM 6.5 がサポートしている vCenter Server のバージョンは 6.5 ですが、SRM 6.5 がサポートしている ESXi のバージョンは、vCenter Server 6.5 がサポートしている ESXi と同じバージョンになります。 この事は、Compatibility Matrixes for VMware Site Recovery Manager 6.5 vCenter Server RequirementsESXi Server Requirements で確認できます。

ただし、SRM 環境で異なるバージョンの ESXi が混在している場合、仮想マシン・ハードウェア・バージョンなど、vSphere としての互換性が求められる場合があります。 つまり、SRM の保護サイトが vSphere 6.5 ( vCenter Server も ESXi もバージョンは 6.5) で、災害対策サイトが vCenter Server 6.5 と ESXi 6.0 の場合、仮想マシン・ハードウェア・バージョン 13 は、ESXi 6.0 ではサポートされませんので、この様なサイト間では、使用される仮想マシン・ハードウェア・バージョンは 11 より以前のバージョンである必要があります。 この様に、SRM 環境においては、保護サイトと災害対策サイトの 2つのサイトを 1つのシステムとして考える必要があります。

参考情報:Virtual machine hardware versions (1003746)

図1:SRM 6.5 ドキュメント ページ

図2:Compatibility Matrixes for VMware Site Recovery Manager 6.5 ページ

SRM の Compatibility Matrixes は、それぞれの SRM のバージョン毎に存在しています。 上記、図1は最新バージョンの SRM 6.5 のドキュメント ページです。 オレンジ色で囲われている “Site Recovery Manager 6.5 の互換性マトリックス” をクリックすると、図2の SRM 6.5 の Compatibility Matrixes のページが表示されます (他の SRM のバージョンでも同様です)。 Compatibility Matrixes のページは英語表記のみでの提供となっています。

 

2. SRM の Guest Operating System Customization Support について

SRMでは、仮想マシンの IP 設定をカスタマイズする機能を提供しています。この機能を使う事で、仮想マシンが災害対策サイトで起動されるときに、今まで使用していた保護サイトの IP 設定を災害対策サイトの IP 設定に上書きする事ができます。この事を “SRM のゲスト OS の IP カスタマイズ” と、言ったりするのですが、このカスタマイズのサポート対象となるゲストOSのマトリックスを公開しています。

図3:Compatibility Matrixes for VMware Site Recovery Manager 6.5 ページの プルダウンメニュー

図3の SRM 6.5 の Compatibility Matrixes のページで、プルダウンメニューから Guest Operating System Support を選択すると、次の図4のページが表示されます。

図4:SRM 6.5 Compatibility Matrixes ページ

このページ (図4) で、SRM 6.5 でサポート対象となる Guest Operating System SupportGuest Operating System Customization Support について説明していますが、Guest Operating System Customization Support の中で、SRM のゲスト OS の IP カスタマイズのサポート対象を PDF:VMware Guest OS Customization Support Matrix で公開しています。

また、仮想マシンによっては、複数の IP アドレスが割り当てられている場合がありますが、”SRM のゲスト OS の IP カスタマイズ“ としてサポートされる構成について、KB (Knowledge Base) を公開しています (英語のみ)。

以下は SRM 6.5 の KB になりますが、SRM 5.8 以降、Operational Limits for Site Recovery Manager X.X (X.X は、5.8、6.0、6.1、または、6.5) という KB を公開しています (KB のサイト で “Operational Limits for Site Recovery Manager” というキーワードで検索すると、他の SRM のバージョンの KB も検索結果から参照できます)。

Operational Limits for Site Recovery Manager 6.5 (2147110)

上記 KB 内で、IP Customization Maximums for Site Recovery Manager 6.5というセクションに記載されている内容 (以下はその抜粋) がサポートされる構成となります。

=== KB2147110 より抜粋 ===
IP Customization Maximums for Site Recovery Manager 6.5
If you implement IP customization for recovered virtual machines, you can configure a maximum of one IP address for each NIC, using DHCP, static IPv4, or static IPv6. For static IPv4 or IPv6 addresses, you provide the following information per NIC:
・1 IP address
・Subnet information
・1 gateway server address
・2 DNS servers (primary and secondary)
====================

上記、KBのポイントは、「仮想マシンの個々 (複数) の vNIC に、それぞれ 1つの IP アドレスが割り当てられている構成がサポートされる構成」 という点です。

似ている構成として、「仮想マシンの 1つ vNIC に複数の IP アドレスが割り当てられている構成」 も考えられますが、以下の KBで公開されている通り、この構成は、SRM の IP カスタマイズではサポートされませんので、ご注意ください。

Can I use multiple IP addresses mapping to a single NIC with vCenter VMware Site Recovery Manager’s IP customization? (2129186)

今回触れた SRM の Compatibility Matrixesですが、日々の活動の中で、意外と存在を知られていない、と感じる事が続いた為、今回はこの件をピックアップしてブログにさせて頂きました。

 

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

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

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

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

1. vSphere Replication の数の制限について
2. vSphere Replication と Site Recovery Manager を共に使用する場合の構成について
3. vSphere 5.x と 6.x の Products Offering の KB (Knowledge Base) 紹介

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

 

1. vSphere Replication の数の制限について

vSphere Replication は、ハイパーバイザー ベースで仮想マシンのレプリケーションを行う vCenter Server の拡張機能です。ストレージ・アレイ・ベースのレプリケーションを代替する機能なため、弊社の Disaster Recovery ソリューションである、Site Recovery Manager と共に使用するケースが多いですが、vSphere Replication を使用してれ保護 (レプリケーション) できる仮想マシンの数には制限 (上限) がある事はご存知でしょうか?

Operational Limits for vSphere Replication 6.x (2102453)

上記のKBでその数の制限 (上限) について説明しています。KBの中には以下の表があり、この表から、1台の vCenter Server 環境で最大 2,000台の仮想マシンを保護することができ、その際に必要となる vSphere Replication Appliance は1台、vSphere Replication Server が9台である事がわかります。つまり、1台の vSphere Replication Appliance と、9台の vSphere Replication Server が、それぞれ 200台の仮想マシンの保護を担う事で、合計 2,000 台の仮想マシンの保護を可能としています。

KB2102453_table

では、vSphere Replication Appliance と vSphere Replication Server ですが、何が違うのでしょうか?

vSphere Replication Appliance には、以下の 2つの役割があります。

  1. vSphere Replication Management Server:vCenter Server や vSphere Replication Server の構成と管理
  2. vSphere Replication Server:データの受信と書き込み

vSphere Replicationを使用する環境に最初に展開される Appliance は①と②の機能を有しており、200台を超える仮想マシンを保護したい環境に追加で展開される Appliance は②の機能のみ有しているという違いがあります。そして、①と②の機能を有している Appliance を vSphere Replication Appliance、②の機能のみを有している Appliance を vSphere Replication Server と呼びます。

 

2. vSphere Replication と Site Recovery Manager を共に使用する場合の構成について

では、Site Recovery Manager と共に使用する場合、vSphere Replication Appliance とvSphere Replication Server は、保護サイトと災害対策サイトのそれぞれにどのように配置する事になるでしょうか?

  1. まず、保護サイトと災害対策サイトの双方に vSphere Replication Appliance を展開します。
  2. 次に、保護対象の仮想マシンの数が 200 台以上の場合、災害対策サイトに、200 台の仮想マシン毎に vSphere Replication Server を展開します。
  3. 保護サイトから災害対策サイトへの片方向のレプリケーション構成の場合、受信側となる災害対策サイトだけにvSphere Replication Server を展開すればいいとなりますが、Site Recovery Manager と共に使用している DR (Disaster Recovery) システムとして考慮するならば、サイト・フェイルオーバ後のサイト・フェイルバックまでを想定した Appliance の配置をしておくのが一般的と言えますので、保護サイトと災害対策サイトの両サイトに同じ台数の vSphere Replication Server を展開しておく事を弊社としては推奨しています。
  4. 尚、当然ですが、保護サイトと災害対策サイトが双方向のレプリケーション構成の場合は、両サイトに必要な数 (仮想マシン数に応じた) だけの vSphere Replication Server を展開する事になります。

例えば、500台の仮想マシンを vSphere Replication と Site Recovery Manager を使用して、片方向のレプリケーション構成としたDRシステムの場合、保護サイトと災害対策サイトに、それぞれ、1台の vSphere Replication Appliance と、2台の vSphere Replication Server を配置する、と言う事になりますので、図にすると以下のようなイメージになります。

SRM+vSR

 

3. vSphere 5.x と 6.x の Products Offering の KB (Knowledge Base) 紹介

皆さん、以下の KB はご存知でしょうか?

vSphere 5.x の各エディション (一部、キット) で提供されているる機能:

  • 英語版 :Product offerings for vSphere 5.x (2001113)
  • 日本語版:vSphere 5.x プロダクト提供 (2073973)

vSphere 6.x の各エディション (一部、キット) で提供されているる機能:

  • 英語版 :Product offerings for vSphere 6.x (2109507)
  • 日本語版:vSphere 6.x の各エディションにおける機能一覧 (2111426)

これらの KB は、それぞれ vSphere で利用可能な機能を一覧表にしていますが、“ある機能が、vSphere の、どのバージョン、どのエディション (一部、キット)” で利用できるのか、という事が解るようになっています。

 

ではどんな時に役に立つのかと言うと、例えば、次のような疑問を持った場合に上記の KB 参照する事で疑問を解決できます。

  1. Storage vMotion はどのバージョンのどのエディション (キット) でサポートされている機能なのか?
  2. vSphere Replication はどのバージョンのどのエディション (キット) でサポートされている機能なのか?
  3. vSphere Fault Tolerance どのバージョンのどのエディション (キット) でサポートされている機能なのか?

KBから上記の 1 から 3 の答えは、それぞれ以下である事が解ります。

vSphere 5.x の場合;

  1. vSphere 5.0 の Enterprise、Enterprise Plus と、vSphere 5.1 以降の Standard、Enterprise、Enterprise Plus でサポートされる機能です。
  2. vSphere 5.1 以降の Essentials Plus と、vSphere 5.0 以降の Standard、Enterprise、Enterprise Plus でサポートされる機能です。
  3. vSphere 5.0 の Enterprise、Enterprise Plus と、vSphere 5.1 以降の Standard、Enterprise、Enterprise Plus でサポートされる機能です。

vSphere 6.0 の場合;

  1. vSphere 6.0 の Standard、Enterprise、Enterprise Plus でサポートされる機能です。
  2. vSphere 6.0 の Essentials Plus、Standard、Enterprise、Enterprise Plus でサポートされる機能です。
  3. vSphere 6.0 の Standard、Enterprise、Enterprise Plus でサポートされる機能で、サポートされる vCPU の数がエディションによって異なるので注意が必要です (Standard と Enterprise の場合は 最大で 2 vCPU、Enterprise Plus は最大で 4 vCPU の vCPU を搭載した仮想マシンを Fault Tolerance 化する事が出来ます)。

注) “Product offerings for vSphere 6.x (2109507)” と “vSphere 6.x の各エディションにおける機能一覧 (2111426)” に vSphere 6.5 に関する情報の追記を関係部門に依頼中 (2017年4月28日 (金) の時点)。

 

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

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

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

今後、月に1回の頻度で VMware Blog (Cloud Infrastructure Blog と End-User Computing Blog) で、ちょっとした技術的なTIPs を投稿していこうと思っておりますので、お付き合いください。

今回は次の 2点をお伝えします。

1. vSphere (vCenter Server と ESXi) がサポート対象としている Active Directory の Domain Function Level について
2. CPU の EVC 互換の確認方法

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

1. vSphere (vCenter Server と ESXi) がサポート対象としている Active Directory の Domain Function Level について
みなさん、VMware の Knowledge Base サイト (kb.vmware.com) はご存知でしょうか? 弊社製品におけるトラブルシューティングやサポート関連の情報などを公開しているサイトになるので、是非、ご活用頂けると幸いです。

さて、以下の Knowledge Base (略して KB という言い方をします) は、vCenter Server と ESXi がサポート対象としている Active Directory の Domain Function Level について記載しているのですが、最近、この KB が更新され、昨年末にリリースされた、vSphere 6.5 の情報が追記されました。

Versions of Active Directory supported in vCenter Server (2071592)
Versions of Active Directory supported in VMware ESXi (2113023)

ここで、大事な事をお伝えしますが、vSphere 6.5 から Windows 2003 Domain Function Level がサポートから外れました (Windows Server 2003 の延長サポートが既に終了となっていますので、その結果が繁栄されていると思われます)。

Versions of Active Directory supported in vCenter Server (2071592) より抜粋 (詳細は KBをご参照ください):
KB2071592

Versions of Active Directory supported in VMware ESXi (2113023) より抜粋 (詳細は KBをご参照ください):
KB2113023

それに伴い、「以前のバージョンの vSphere」 と 「Windows 2003 Domain Function Level」 で利用している環境を、vSphere 6.5 へバージョンアップすると、動作の可否に関わらず、vSphere 6.5としてはサポート外の構成となってしまいますので、バージョンアップをご検討されている場合はこの点ご注意ください。

vSphere 6.5 へのアップグレードには以下のドキュメントを参考にして下さい。

1. ブラウザで、http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-6-pubs.html へ。
2. 「vSphere アップグレード ガイド」の PDF をクリック頂き、PDF版を参照するか、「vSphere 6.5 ドキュメント センター」リンクをクリック頂き、ブラウザの左側の「目次」で、「ESXi および vCenter Server 6.5 のドキュメント」→ 「vSphere のアップグレード」 の順で、クリック頂く事で、ブラウザ上で PDF 版と同じ内容を参照頂けます。

2. CPU の EVC 互換の確認方法
みなさんは、弊社の Compatibility Guide のサイトはご存知でしょうか? このサイトでは、弊社製品がサポートするハードウェア関連 (一部ソフトウェア) の情報を掲載しており、どのサーバ、どのCPU 、どのIOカード (NICやHBAなど) が弊社製品でサポートされているのかを確認頂く事ができます。

ちなみに、このページに掲載されている情報は、弊社が認定作業を実施していると思われがちですが、基本的には各ハードウェア・ベンダー様に認定作業を実施頂き、認定をパスしたハードウェアの情報を頂戴して弊社が掲載しています。

話を元に戻しますが、このサイトの1つとして、CPU Series というページがあります。ここでは、ESXi の各バージョンがサポート対象としている CPU や、Fault Tolerant 機能がサポート対象としている CPU、また、世代の異なる CPU 間での vMotion をサポートする為の機能、Enhanced vMotion Compatibility (EVC) を確認する事ができます。

特に、EVC は既存環境に新たに ESXi を追加する際に、既存サーバに搭載されている CPU と新たに追加するサーバに搭載されている CPU 間で vMotion、もしくは、DRS (DRSは仮想マシンの再配置を行う際に vMotion を利用しています) の互換性があるか、また、互換性を持たせる為に設定すべき EVC モードは何かを確認する事ができます。

例えば、既存環境では、① Intel Xeon E5-2690 を搭載しているサーバを使用していて、②その環境に新たに Intel Xeon E5-2690 v4 を搭載しているサーバを追加したいとします。かつ、①と②の間で vMotion または DRS を利用したいとします。

①の Intel Xeon E5-2690 は、Intel Xeon E5-2600 Series、②の Intel Xeon E5-2690 v4 は、Intel Xeon E5-2600-v4 Series になりますので、CPU Series のページで、それらを選択します。
HCL_EVC1

次に、”CPU / EVC Matrix” ボタンをクリックします。
HCL_EVC2

その結果 (上記) から、Intel Xeon E5-2690 (Intel Xeon E5-2600 Series) と Intel Xeon E5-2690 v4 (Intel Xeon E5-2600-v4 Series) の EVC モードが、Intel® Sandy-Bridge Generation である事がわかります。ちなみに、赤枠で囲まれた “Intel Xeon E5-2600 Series” や “Intel Xeon E5-2600-v4 Series” をクリックすると、それぞれの CPU のコードネーム (Code Name) を確認する事もできます。

どうでしょう、一見難しい様に思える異なる世代の CPU 間の EVC モードの確認が簡単に行える事をご理解頂けたと思います。

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