Home > Blogs > Japan Cloud Infrastructure Blog

ここが変わった! 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  期間の終了を指しています。詳細はこちらをご参照ください。

 

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

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

 

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

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

今回は、vCenter ServerやESXiホストをアップグレードする際に、アップグレードの可否が検討される「仮想ハードウェア」と「VMware Tools」についてご紹介します。

現在設定されているバージョンが仮想マシンの継続稼働に問題があるのか、最新バージョンにアップグレードしたらどんなメリットがあるのかを知っておくことは、大事なポイントであると思います。

また、仮想ハードウェアのアップグレード時には仮想マシンを再起動するダウンタイムが発生します。「いつ」「誰が」実施するのかも考慮する必要がありますね。

 

#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 / その他のオプション)

 

◆仮想ハードウェアバージョン13◆

vSphere 6.5で提供される最新の仮想ハードウェアバージョンは、「13」です。

下表は、「13」から提供される機能です。これらの機能は、「仮想マシンに ESXi 6.5 以降との互換性(仮想ハードウェアバージョン13)が設定されている」こと、「サポートするゲスト OS が仮想マシンにインストールされている」ことが前提です。

※仮想ハードウェアはESXiホストで使用できる物理ハードウェアに対応します。仮想ハードウェアバージョン13では最大6TBのメモリをサポートします。しかしESXiホストに6TBの物理メモリが搭載されていなければ、仮想マシンに割り当てることはできません。

仮想ハードウェアもアップグレードしなければならないの?

たとえば下図のように、vCenter Server 5.5をvCenter Server 6.5へ、vSphere ESXi 5.5の一部をvSphere ESXi 6.5へアップグレードした例を使い、仮想ハードウェアバージョンのアップグレード可否について確認します。ここではあえてこの構成にしています。

 

 

アップグレードしない場合 (仮想マシンの互換性を変更しない)

構成例ではESXiホストのバージョンが5.5と6.5の混在環境のため、仮想マシンの互換性は古いESXiホストとの互換性を維持するために、「ESXi 5.5以降以降 (ハードウェアバージョン 10)」を選択します。言い換えると、仮想マシンの互換性は変更せず、仮想マシンの稼働を継続します。

仮想マシンの互換性を「ESXi 6.5以降」に変更すると、その仮想マシンをESXi 5.5または6.0  ホスト上で実行することができません。たとえば、仮想マシンの互換性が「ESXi 6.5以降」である仮想マシンを、ESXi 5.5ホストへ移行することができません。

また、すべてのESXiホストが6.5であったとしても、最新の仮想ハードウェア機能を使用しないのであれば、必ずしも最新の仮想ハードウェアバージョンを選択する必要はありません。

私はESX 4.0 ホスト上で作成した仮想マシンをovfファイルにエクスポートし、新しいバージョンのESXi ホスト上で継続的に使用したことがあります。これは互換性により可能となります。

vSphere ESXi 6.5では、仮想マシンの互換性に、「ESX/ESXi 4.0 以降 (ハードウェアバージョン 7) 」を選択できます。これは仮想ハードウェアバージョン 7以降の仮想マシンを、ESXi 6.5ホスト上に配置できることも意味します。

VMware製品、ストレージやネットワークベンダーから提供されるovfファイル (仮想アプライアンス) は、互換性を考慮し「ESXi 5.0以降 (ハードウェアバージョン 8) 」で提供されているのを見かけますね。

 

アップグレードする場合 (仮想マシンの互換性を最新の「ESXi 6.5以降」に変更する)

6.5で提供される最新の仮想ハードウェア機能を使用したい場合は、すべてのESXiホストを6.5で構成し、仮想マシンの互換性に「ESXi 6.5以降」を選択します。

 

仮想マシンの互換性のデフォルト値

ESXi 6.5ホスト上で新規に作成する仮想マシンの互換性は「ESXi 6.5以降」が選択されます。

互換性のデフォルト値は仮想マシンを作成する ESXi ホストのバージョンによって決まります。デフォルトの互換性の設定値をESXiホストのバージョンとは異なる値にしたい場合には、こちらを参照ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.vm_admin.doc/GUID-FD9DC4FF-4420-4FCA-AEF4-6E19AFF869F5.html

 

 

◆VMware Tools バージョン10.1.x◆

vSphere 6.5 に付属している VMware Tools のバージョンは 10.1です。10.1はメジャーリリースで、2017年5月18日に10.1.7がリリースされています。

最新のゲスト OS はVMware Tools 10.1.xに対応し、レガシー ゲスト OS はVMware Tools 10.0.12 に対応します。

 

VMware Tools 10.1.xでサポートされるゲスト OSです。

VMware Tools 10.1で提供されている機能です。

VMware Toolsもアップグレードしなければならないの?

仮想ハードウェアと同様にVMware Tools も最新バージョンへのアップグレードは必ずしも必要ではありません。VMware Tools の新しいバージョンは、複数のホ ストのバージョンと互換性があります。追加された機能や性能が環境にとって必要かどうかを検討後、実行ください。

下図は互換性リストの一部です。

◆仮想マシンのアップグレードのダウンタイム◆

仮想マシンをアップグレードする時、必要なダウンタイムはゲスト OS と実行するアップグレードの種類によって異なります。VMware Tools のアップグレードから開始します。

Linux ゲスト OS の多くは、VMware Tools の現在のバージョンではアップグレード後の再起動が不要です。以前のバージョンでは、「PVSCI」「VMXNET」「VMXNET3」ドライバのアップグレード後にゲスト OS を再起動する必要があります。

 

◆参考◆

  1. ESX/ESXiホストでサポートされる仮想ハードウェアはこちらのKBを参照ください。
    Hardware features available with virtual machine compatibility settings (2051652)

 

  1. ESXi 6.5ホストでバンドされないVMware Tools ISOイメージは、My VMwareからダウンロードできます。バンドルされていない、特定のオペレーティング システム用の VMware Tools をダウンロードする場合は、VMware Tools 10.1.0 リリース ノートなどに記載されている手順を参照ください。

 

  1. ESXiホストのバージョンに関係なく、最新のVMware Tools をインストールまたはアップグレードする方法についてはこちらのKBを参照ください。
    Installing and upgrading the latest version of VMware Tools on existing hosts (2129825)
    こちらのVMware vSphere Blogはコメントも含め参考になります。
    https://blogs.vmware.com/vsphere/2015/09/vmware-tools-lifecycle-why-tools-can-drive-you-crazy-and-how-to-avoid-it.html
    ※ESXi 6.5ホストにバンドルされる3つのISOイメージです。

  1. 仮想マシンのアップグレードについては、こちらのドキュメントを参照ください。
    https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-EE77B0A9-F8FF-4785-BEAD-B6F04EE04492.html

 

 

◆まとめ◆

今回は、最新の「仮想ハードウェア」と「VMware Tools」をご紹介しました。

本文内では、仮想マシンのアップグレードは必ずしも必要ではないと述べていますが、アップグレードすればパフォーマンスや運用の利便性を向上する機能を使用できます。ダウンタイムを考慮し、仮想マシンのアップグレードを検討いただけたらと思います。

ダウンタイムは仮想ハードウェアのアップグレード時には必ず発生しますから、「仮想マシンの互換性アップグレードのスケジュール設定」やUpdate Managerを利用して計画的に進めることをお勧めします。

今回のBlogを書くにあたり、あらためて「仮想ハードウェア」と「VMware Tools」について調べてみました。KBやドキュメントを読むと、新たな発見があり、とても楽しかったです。

お時間が許せば、参考にあげているKBやドキュメントもぜひ参照いただければと思います。

次回は、vSphere 6.5で使用する管理ツールについてご紹介します。

 

 

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

 

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

今回はvSphere 6.5から提供される、「vCenter Server Appliance の高可用性」と「vCenter Server ApplianceとPlatform Services Controllerアプライアンスのファイルベースのバックアップとリストア」についてご紹介します。

 

#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 / その他のオプション)

 

vCenter Server停止時の影響範囲は?

VMware製品に初めて関わる方からは、vCenter Server停止時の影響範囲についてよく質問されました。プリセールス時には可用性も含めて提案しますから気になりますね。

最近はvCenter Server停止時の質問は減りましたが、復習をかねて影響範囲について確認しましょう。

vCenter Serverが停止して困るのは、vCenter Serverが提供している機能を使用できない時です。たとえば、仮想マシンのクローン作成やvMotion(仮想マシンの移行)を行う時です。

vSphere HAや分散スイッチは、新規作成や設定変更時にはvCenter Severが稼働している必要があります。しかし機能の継続には支障ありません。vSphere HAや分散スイッチは、ESXiホスト側で管理する仕組みを持っているからです。

最近の質問は、「vCenter Single Sign-Onサービスが停止したら、vSphere Web ClientからvCenter Serverにログオンできなくなるの?」です。次から次へと疑問は尽きませんね。

 

Platform Services Controller (PSC) の可用性

こちらのBlogでは、vCenter Serverの可用性を中心に進めます。vCenter Single Sign-Onサービスを含むPSCの可用性については、組み込みのPSCか外部のPSCを選択するかで方法が異なります。組み込みのPSCはvCenter Serverを保護すれば同時にPSCも保護されます。

外部のPSCの可用性については、こちらをご確認ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.psc.doc/GUID-62CC201A-01ED-4116-8604-FF123481DAFC.html

 

vCenter Server の可用性

vCenter Serverを長く停止させるわけにはいけませんから、少しでもダウンタイム (サービスの停止時間) を短くする方法を検討する必要があります。

vCenter Serverの可用性については、いくつかの方法が提供されてきました。シンプルな方法として選択されてきたのはvSphere HAですね。

vSphere 6.5では、vCenter Server Applianceを対象に、「vCenter High Availability」が追加されました。ハードウェア障害からの保護だけではなく、 パッチ適用などサービスを停止しなければならない際にダウンタイムの短縮に役立ちます。

<補足情報>

vSphere 6.0のドキュメントになりますが、vSphere HAとMicrosoft Cluster Serviceで構成するvCenter Serverの可用性についてまとめられています。参考にしてください。

http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.vcenterhost.doc/GUID-4A626993-A829-495C-9659-F64BA8B560BD.html

以下はvCenter Server の高可用性に関する VMware の KBです。こちらも参考にしてください。

-英語版-
Supported vCenter Server High Availability Options
https://kb.vmware.com/kb/1024051

-日本語版-
サポート対象の vCenter Server 高可用性オプション
https://kb.vmware.com/kb/2089839

vCenter High Availability

vCenter HAは3つのvCenter Server Applianceインスタンスから構成します。

1つ目のインスタンスは、Activeノードとして使用されます。Activeノードのクローンが2回作成され、Passiveノードと監視ノード用に構成されます。

Activeノードに障害が発生すると、自動的にPassiveノードに役割を引き継ぎます。監視ノードはクォーラムを提供し、スプリットブレインの状態から保護します。

vSphere 6.5から提供される機能ですから、ESXiホストも6.5で構成できればよいですね。

vCenter HAのハードウェア要件とソフトウェア要件はこちらをご確認ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.avail.doc/GUID-8FD87389-8CC9-4298-8B08-A1526FB44524.html

設定方法はシンプルです。下図のウィザードにあるように、vCenter HAネットワーク用のIPアドレスを設定します。環境に応じて、「Passive」と「監視」の仮想マシンをどのESXiホスト、どのデータストアに配置するかを指定します。事前にESXiホスト上にvCenter HAネットワーク用のポートグループを作成しておく必要があります。

vCenter Server ApplianceおよびPlatform Services Controllerアプライアンスのバックアップ

vSphere 6.0から、vSphere Data Protectionを使用して、vCenter Server、vCenter Server Applianceまたは Platform Services Controller を含む仮想マシンのイメージベースのバックアップができるようになりましたね。vCenter Serverを、vSphere Data Protection アプライアンスが実行されているESXi ホストに直接緊急リストアできることは特徴の一つです。

 

<補足情報>

vSphere Data ProtectionはvSphere 6.5が最後の提供となります。

https://blogs.vmware.com/partnernews/2017/04/vsphere-dp-eol.html

 

vSphere 6.5 では、vCenter Server Appliance 管理インターフェイスを使用して、vCenter Server Appliance と Platform Services Controller アプライアンスのファイルベースのバックアップを提供します。バックアップはvCenter Server Appliance 管理インターフェイスを、リストアはvCenter Server Applianceの GUI インストーラを使用します。

 

< vCenter Server Appliance 6.5のバックアップ>

vCenter Server Appliance 管理インターフェイス (https://vCetner Server ApplianceのFQDN or IPアドレス: 5480) を使用してバックアップします。

バックアップデータは、指定したリモート システム(たとえばFTPサーバー)に、HTTPS/ HTTP/ SCP / FTPS/ FTPのいずれかを使用してストリーミングされます。

< vCenter Server Appliance 6.5のリストア>

リストアは、次の2つの手順で実施されます。

  1. vCenter Server Appliance 6.5 Installerでovaファイルのデプロイ
  2. vCenter Server Appliance 管理インターフェイスでバックアップデータの転送

1の手順でovaファイルのデプロイ完了後、 vCenter Server Appliance 管理インターフェイスへリダイレクトされ、2の手順のリモートシステムにあるデータを、新しくデプロイされた vCenter Server Appliance にコピーします。

リストア後、vCenter Server Applianceと Platform Services Controller アプライアンスのデプロイタイプにより、スクリプト /usr/bin/vcenter-restore を実行します。

詳しくは、こちらをご確認ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.install.doc/GUID-67C7D3ED-2A52-4960-95EC-03C4EE3F5E34.html

 

◆まとめ◆

今回は、vSphere 6.5で提供された、vCenter HAとvCenter Server Appliance と Platform Services Controller アプライアンスのファイルベースのバックアップをとりあげました。

可用性については、vSphere HAを選択するべきか、vCenter HAを選択するべきか。

vSphere HAはDRSの非アフィニティルールと構成することを推奨しています。vCenter HAはESXiホストが3台以上およびDRSを構成することを推奨しています。vSphere HAもvCenter HAも1つのvCenter ServerライセンスとvSphere Standardのライセンスで構成可能です。DRSを使用するならvSphere Enterprise Plusのライセンスが必要です。

どちらの機能を選択し、どのように設計(構成)するかは、運用コストの費用対効果を考慮する必要がありますね。

Windows版のvCenter Serverの場合は、vSphere HAまたはMicrosoft Clustering Serviceのどちらかを検討することになります。

次にバックアップですが、サードパーティ製品を使用して仮想マシンのバックアップを取られていることが多いと思います。コスト面からvSphere Data Protection を検討されていた方もいらっしゃるかと思いますが、先に述べたようにvSphere 6.5が最後のリリースとなりますからご注意ください。

vCenter Server Applianceをご使用であれば、正常に動作するアプライアンスを復元できるようにバックアップデータを取りますから、こちらもお勧めかもしれません。

次回は仮想ハードウェア Version 13  VMware Tools Version 10.1ついてご紹介します。

HPE Synergy – 最初のコンポーザブル インフラストラクチャー (HCI) – vSAN on Synergy の構成が認証されました

□はじめに

以下のURLは、HPE小川様のブログです。(外部リンク)
HPE Synergy にご興味をお持ちの方は、以下のリンク先も併せてお読みください。

https://community.hpe.com/t5/%E6%97%A5%E6%9C%AC%E3%81%AE%E3%81%8A%E5%AE%A2%E6%A7%98%E5%90%91%E3%81%91-%E3%82%A8%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%97%E3%83%A9%E3%82%A4%E3%82%BA-%E3%83%88%E3%83%94%E3%83%83%E3%82%AF%E3%82%B9/VMware-vSAN-%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E3%82%AB%E3%82%BF%E3%83%81-%E3%82%B3%E3%83%B3%E3%83%9D%E3%83%BC%E3%82%B6%E3%83%96%E3%83%AB-HCI/ba-p/6964180#.WUdElWjyg2w

□ご紹介

vSANは、最も重要なワークロードを稼働させる信頼性の高いインフラとして、7000社を超えるお客様に使われ、現在も成長を続けています。この流れをさらに促進させるべく、VMwareはパートナー様と連携し、次世代ハードウェアにいち早く対応させることを明言しています。
コンポーザブルインフラストラクチャはお客様が採用を検討する次世代プラットフォームであり、vSANとして初めて認証を受けた最初のコンポーザブルインフラストラクチャであるHPE Synergyを発表できることは非常に光栄です。これは、我々の成熟したお客様が稼働させる従来のアーキテクチャのワークロード、および次世代のワークロードにとって非常に画期的な位置づけの製品です。
HPE Synergyの構成詳細については、以下vSAN VCG(VMware Compatibility Guide)を参照下さい。
AF-6:http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=vsan&productid=41543&deviceCategory=vsan&details=1&vsan_type=vsanreadynode&page=1&display_interval=10&sortColum
n=Partner&sortOrder=Asc
AF-4
http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=vsan&productid=41542&deviceCategory=vsan&details=1&vsan_type=vsanreadynode&page=1&display_interval=10&sortColum
n=Partner&sortOrder=Asc

□従来のHCIとコンポーザブルHCI

コンポーザブルインフラストラクチャの定義については、次のセクションにて記載をします。しかしその前に、基本的なご質問として良く聞かれるのが、“コンポーザブルインフラストラクチャはHCIとして使用することができるのか?”です。答えは“Yes”です。


基本的な違いは、コンポーザブルインフラストラクチャでは“コンピューティング”と“ストレージ“が構成要素として分かれていることです。従来のHCIは、インフラの成長に合わせて”コンピューティング“と”ストレージ“を一緒に拡張させていました。しかし、ワークロードに対してより柔軟に対応していかなければいけません。HCIの恩恵を維持するためには、”コンピューティング“および”ストレージ“からの要求に対して個別にスケールアウトさせていく必要があります。コンポーザブルインフラストラクチャはHCIの世界でそのような考えを実現するための構成要素です。

□コンポーザブルインフラストラクチャとは?

コンポーザブルインフラストラクチャは、3つの要素(ソフトウェアで定義する仕組み、流動的なリソースプール、統合されたAPI)から構成されています。流動的なリソースプールとは、変化する各アプリケーションの要求に対して、構成要素として分かれている“コンピューティング”、“ストレージ”を柔軟に組み合わせるために必要な要素です。そしてソフトウェアで定義する仕組みとは、自動化(サーバやストレージの仮想化)をより促進することによってIT管理者の運用管理をシンプルにしていきます。最後に、統合されたAPIにより、サイロ化された運用を統合し複雑さを排除する単一の管理インターフェースを提供します。このインフラによって年に1-2回程度のインフラストラクチャのアップデート等が発生した際にも、継続的なサービス提供と、アプリケーションの展開を手助けすることができるようになります。

□HPE Synergy

HPE Synergyとは、フレームと呼ばれる10Uのボックスで、12個のハーフサイズのモジュラーを搭載、もしくは6個のフルサイズのモジュラーを構成するベイが存在しています。これらのベイは、最大12台のサーバを搭載可能であり、最大4台のストレージモジュールを搭載することも可能となっています。さらに、ストレージモジュール毎に最大40のSFF(スモールフォームファクタ)ドライブベイを持っています。
以後のセクションで、vSAN視点におけるHPE Synergyの構成について見ていきたいと思います。

□なぜvSANとSynergyを組み合わせるのか?

HPE Synergyは、今までの HPE BladeSystemからの進化と、柔軟に構成を組めるコンポーザブルインフラストラクチャーの第1弾であり、ここで詳細を学ぶことができます。
https://h20195.www2.hpe.com/V2/GetDocument.aspx?docname=A00006129ENW
それ以外にも、HPE Synergyがもたらす主要な利点がありますが、それらはvSANと組み合わせることによって実現可能となっています。

□分離されたストレージとコンピューティング

ビジネスはより動的になってきており、事前に計画し、必要なワークロードを予測することは困難です。企業は、動的に拡張できるプラットフォーム(コンピューティングとストレージの両方)を求めています。このプラットフォームの最大の利点はストレージとコンピューティングが独立して拡張できることです。

選択された構成シナリオ(以下のHPE SynergyのおけるvSAN展開の選択肢のセクションで説明します)では、単一のHPE Synergyフレームは、最大80 SFF(2.5インチ)ドライブまたは最大10台のコンピューティングサーバーを保持できます。

小規模(3台のコンピューティングサーバと1台のストレージモジュールを部分的に搭載)から始めて、ワークロードに応じて、コンピューティングまたはストレージを追加することができます。

これは今日のビジネス環境において大きな利点です。オーバープロビジョニングを避けることによって先行的な投資を最小化するだけでなく、必要に応じた拡張を可能にする柔軟性を提供します。例えば新しいワークロードがコンピューティングのみを要求する場合は、フレーム内でコンピューティングモジュールを拡張することができます。
実際には、単一のフレーム(筐体)内に最大40台のドライブを搭載した10ノードのvSANクラスタを構築し、ビジネス需要の増加に応じてフレームを追加することで拡張できます。

任意のワークロードに対する単一のインフラストラクチャ:

エンタープライズ企業では、従来のインフラストラクチャで従来のアプリケーションを稼働させ、新しいクラウドネイティブアプリケーションやモバイルアプリケーション等の次世代アプリケーション用途として異なるインフラストラクチャとツールで作り上げる戦略を採用することが期待されています。
しかし、vSANは、従来および次世代のアプリケーション用途として稼働しています。我々はお客様との話し合い、vSANの導入状況を把握することで、日々学んでいます。次の図は、お客様がvSAN環境で実行しているユースケースを表しています。

ここから、vSANは「バイモダルコンピューティング」(従来および新世代のワークロード)に対応すべきである、という事が明確に分かります。
HPE Synergyのアーキテクチャと管理ソリューションは、従来のビジネスアプリケーションと新しいビジネスアプリケーションの両方に対応し、企業が単一のインフラストラクチャでvSANユースケースを実行できるよう支援します。

フレーム間の高速インターコネクト:

HPE Synergyは同じ論理エンクロージャー・サーバー内のフレーム間のイーサネット接続にマスター・サテライト・トポロジーを使用しているため、サーバーのデータ・トラフィックは、トップ・オブ・ラックで導入された環境下でも – 異なるサーバーのフレーム間でも – レイテンシを発生させずに最大20Gbpsの高速イーサネット接続を提供できます。

□なぜ Synergy は vSAN に適しているのか?

HPE Synergyとは:フレームが コンピューティング、ストレージ、ファブリック、冷却、電力、およびスケーラビリティのリソースをプールするインフラストラクチャです。
フレーム内の重要な要素の1つは、ローカルディスクストレージが単一フレーム内でのみアクセス可能であることです。これは、フレーム内のサーバに対して全てのディスクを割り当てる必要があることを意味します。vSANの基本は、ホスト(ESXi)で使用可能な全てのローカルストレージディスクを、全てのサーバが共有する単一のデータストアに集約することです。
従来のラックサーバの場合、コンピューティングとストレージは独立して拡張されません。
しかし、HPE Synergyでは、ストレージを拡張して別々に計算することで、集約を実現できます。これにより、vSANなどのHCIソリューションに最適といえます。

HPE SynergyのおけるvSAN展開の選択肢:

単一フレーム内のHPE SynergyプラットフォームでvSANを構成、および複数のフレームを跨いでvSANを構成し、かつコンピューティングとストレージを構成するなど、方法は数多くあります。実際に選択肢はほぼ無限大です。

しかし、vSANの配備の観点から、1つのフレーム内に3つの基本的な構成(完全集約化)でのみ展開頂くをご提案しています。
※以下に記載のあるSATAとは、HDDを指しているのではなく、SATA インターフェースで接続されたSSD を指しています。
※vSANで認定された ディスクは 「SAS SSD」「SATA SSD」「SAS HDD」「Nearline SAS」 の4種類です。

1xストレージモジュール{D3940(12ドライブ)}と3x Compute Servers {SY 480}ハーフハイトサーバーを備えた1つのフレーム:

これらのコンピューティングサーバーのそれぞれは、1つのディスクグループ内に4つのドライブ(1つのキャッシュ+ 3つのキャパシティ)をサーバーごとに構成しています。最適な選択は、SASドライブをキャッシュ層として、SATAドライブをキャパシティ層として使用することです。

2つのストレージモジュール{D3940(80ドライブ)}と8×Compute Servers {SY 480}ハーフハイトサーバーを備えた1つのフレーム:

これらのコンピューティングサーバーは、グループ毎に2つのディスクグループ(1つのキャッシュ+ 4つのキャパシティ)の計8つのドライブが構成されています。最適な選択は、SASドライブをキャッシュ層として使用し、SATAドライブをキャパシティ層として使用することです。

1xストレージモジュール{D3940(40ドライブ)}および10x Compute Servers {SY 480}ハーフハイトサーバーを備えた1つのフレーム:

これらのコンピューティングサーバーは、1台のサーバーにつき1つのディスクグループとして4つのドライブ(1つのキャッシュ+ 3つのキャパシティ)で構成されています。最適な選択は、SASドライブをキャッシュ層として、SATAドライブをキャパシティ層として使用することです。
SynergyでのオールフラッシュvSAN構成での3つの展開例として、以下の表を参考にしてみましょう。

単一フレーム内でのvSAN構成例
もう一度繰り返しますが、vSANを構成するには初めに3台のコンピューティングサーバーが必要です。上記は、単一フレーム内での構成例です。この新世代のハードウェアがさらに普及するにあたり、ユーザーが望むその他構成について更に考えていきます。

HPE SynergyとHPE BladeSystemとの比較:

HPEサイトには素晴らしい文書があり、ここで読むことができます。しかし、私はここでの比較で紹介したいと思います:

□HPE Synergy を適用しにくいケース

HPE Synergyは単一のインフラストラクチャとして多くのユースケースをカバーしていますが、現時点でHPE Synergyに向かない用途もあります。

1. ストレージモジュールでNVMeドライブが必要なアプリケーション:

ストレージモジュールにNVMeデバイス並みのパフォーマンスを必要とするニッチなワークロードが存在する可能性があります。
今日のHPE Synergyプラットフォームは、ネイティブPCIeの代わりにSASインターフェイスを使用しているため、ストレージモジュール上でNVMeをサポートしていません。
ただし、HPE Synergyは、vSANのキャッシュ層デバイスとして使用される可能性のあるサーバーモジュールでNVMeサポートを提供しています。

2.大容量のDASストレージ:

ご存知のように、3.5 “ドライブは2.5″ドライブより容量が大きいです。現在のHPE Synergyストレージモジュールは3.5 “ドライブをサポートしていません。
ワークロードとして大容量ストレージを必要とし、パフォーマンスを必要としないDAS指向アプリケーションがいくつかあります。

このような場合、Synergyは最もコスト効率の高いストレージソリューションを提供しない可能性があります。パフォーマンスと高密度ストレージの両方を必要とするアプリケーションであれば、Synergyは依然としてそのようなワークロードに最適なプラットフォームです。

まとめ:

組織がこの新世代のプラットフォームを採用して従来のアプリケーションや次世代のアプリケーションを稼働させるにあたり、VMwareは、HPEさんのようなパートナー様と密接に連携して、vSANの有効性を証明していきます。

HPE Synergyは、ストレージとコンピューティングを分割して管理する最適なHCIを提供することで、お客様は要求に基づいて環境を成長させることができます。

vSANハードウェアに関するご質問は、vsan-hcl@vmware.comまでお問い合わせください。

ちょっとした技術的な 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ですが、日々の活動の中で、意外と存在を知られていない、と感じる事が続いた為、今回はこの件をピックアップしてブログにさせて頂きました。

 

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

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

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

vSphere 6.0とvSphere 6.5の違いを尋ねられることが多くなりました。そのご質問に、こちらのBlogで回答します!

また、バージョンアップ時にプリセールスのみなさまからよくご質問をいただく内容をふまえ、vSphere 6.5の変更点をお伝えします。次の6回構成です。

 

#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 / その他のオプション)

 

 

1回目と2回目は、vCenter Server Applianceのアップデートについてです。併せてWindows版との違いも説明します。

 

■ vCenter Server Applianceに含まれるソフトウェア ■

vCenter Server Appliance 6.5は、下表のソフトウェアで構成されます。

6.5からPlatform Services ControllerとvCenter ServerはPhoton OS上で動作します。Project PhotonはVMwareがコンテナ向けにリリースした軽量Linux OSです。

Update ManagerはvCenter Server Appliance 6.5ではサービスとして提供されます。そのためインストール不要です。Windows版のUpdate Managerはコンポーネントとして提供されるため、従来通りインストールが必要です。

1

vCenter Server Appliance 6.5は仮想ハードウェアバージョン10 (ESXi 5.5以降でサポートされるバージョン) で提供されます。仮想ハードウェアバージョン10ですから、vCenter Server 6.5は、ESXi 5.5以降のホストまたはvCenter Server 5.5 以降のインスタンスのインベントリに含まれる ESXi ホストまたは DRS クラスタにデプロイできます。

 

~ハードウェアリプレース時~

ハードウェアリプレース時には、vSphereの移行方法(導入手順)に関わるため、最新のvCenter Serverの配下に既存のESXiホストが動作可能なのかをよく尋ねられます。

下図は、「VMware Product Interoperability Matrices」の画面ショットです。vCenter Server 6.5ではESXi5.5以降のホストを配置可能です。

2

■ vCenter Serverのコンポーネントとサービス ■

6.0と6.5で、「Platform Services Controller」と「vCenter Server」のコンポーネントがインストールされるのは変わりません。「Platform Services Controller」は6.0から提供されているコンポーネントです。

6.5で追加されたサービスは、Webブラウザを使用するvSphere ClientとUpdate Managerです。先に述べたとおり、Update ManagerはAppliance版に追加されます。

Syslog CollectorはWindowsと明記しているとおり、Windows OS上にインストールするサービスです。vCenter Server ApplianceでのLog収集はLinux OS に組み込みの Rsyslogサービスを使用します。

ESXiホストにLocalディスクを搭載しない場合は、トラブルシューティングのためにDump CollectorやSyslog Serverを別途準備しておく方がよいですね。

3

■ vCenter Serverのスケーラビリティ ■

vCenter Serverのキャパシティについてです。6.0と6.5では約2倍の差があります。

Appliance版とWindow版のデータベースにかかるコストで比較すると、ESXiホストを20台以上管理する場合、vCenter Server Appliance  6.5に分がありますね。

4

最大構成数は、パブリックのドキュメントを参照しています。

vCenter Server Appliance 6.5は上表から判断できるように、外部データベースをサポートしません。Window版でサポートしている外部データベースの詳細はこちらでご確認ください。

http://www.vmware.com/resources/compatibility/sim/interop_matrix.php#db

 

◆参考情報◆

ハードウェア要件とポート情報を付記します。

 

■ Platform Services Controllerのハードウェア要件 ■

規模に関わらず、2 個の vCPU と 4 GB メモリです。

 

■ vCenter Serverのハードウェア要件 ■

規模に合わせて、ハードウェア要件は異なります。Window版は最小推奨ハードウェア要件となりますから、vCenter Serverに同居するサービスによってメモリサイズを考慮した方がよいと思います。

5

■ Platform Services Controller アプライアンスのストレージ要件 ■

Platform Services Controller アプライアンスのストレージ要件は 60 GB です。

 

■ vCenter Server Applianceのストレージ要件 ■

このストレージ要件には、vCenter Server Appliance でサービスとして実行される vSphere Update Manager の要件も含まれています。インストール中に3つのストレージサイズを選択することが可能です。

■ Windows での vCenter Server および Platform Services Controller の最小ストレージ要件 ■

各フォルダの最小ストレージ要件は、インストール時のデプロイ モデルによって異なります。

7

■ vCenter ServerおよびPlatform Services Controllerに必要なポート ■

必要なポートはこちらで確認できます。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.install.doc/GUID-925370DD-E3D1-455B-81C7-CB28AAF20617.html

 

◆まとめ◆

1回目は、Platform Services ControllerとvCenter Serverの概要についてでした。

プリセールスの方には必要なコンポーネントやハードウェア要件を、導入エンジニアの方には設定値レベルで必要な情報と思われるものをリストアップしました。

今後は、vSphere 5.5からvSphere 6.xにアップグレードされるお客様が増えてくるのではないかと思います。今回のテーマの5.5と6.xの違いは、vCenter Single Sign-OnがvCenter Serverコンポーネントに存在するか否かです。

6.5のアップデートでは、Enterprise Plusを前提とする機能も散見しますが、それらはパフォーマンスを改善する機能として提供されます。

2回目はvCenter Server Applianceの高可用性とバックアップです。お楽しみに!

 

 

 

ちょっとした技術的な 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日 (金) の時点)。

 

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

VMware NSX for vSphereへの移行

4回目:VMware NSX for vShield Endpointへの移行検証サマリー (パート2)

-Back Number-
#1_ vCloud Networking and Security (vCNS) の販売終了
#2_Deep Securityを実装するためのNSX
#3_ VMware NSX for vShield Endpointへの移行検証サマリー
#4_ VMware NSX for vShield Endpointへの移行検証サマリー(パート2)

こんにちは、ソフトバンク コマース&サービスの中川明美です。
12月に投稿しました3回目ではvSphere 6.0環境下での移行方法をご紹介しました。
今回は、vSphere 5.5環境下での「vShield Endpoint(vCNS)からNSX for vShield Endpointへのアップグレード手順をご紹介します。vSphere 5.5からの移行を計画されている方はぜひご参考にしてください!
このBlogでは簡易手順を共有します。詳細手順をお知りになりたい方は、ページ下部でご紹介するURLからご入手ください。

◆構成図◆
下図は、Upgrade前の構成図と、Upgrade後の構成図です。
Upgrade前はvSphere 5.5 U1環境下でvShield Endpoint(vCNS)を使用、Upgrade後はvSphere 6.0 U2環境下でNSX for vShield Endpointへ移行します。
<Upgrade前>

before

<Upgrade後>

after

◆アップグレード手順◆
次の16ステップを進めます。

1.DSVA(Deep Security Virtual Appliance)の無効化/停止/削除

1

2

3

2.各ESXiホストから Filter Driverを削除

4

3.vShield Managerの停止

5

4.Deep Security ManagerとvCNS / vCenterサーバーの連携解除

6

5. vCenterサーバー / ESXiホスト のアップグレード

7


8

6.Horizon Viewのアップグレード

9

7. Deep Security ManagerのDBスキーマのアップグレード

10

8. Deep Security Manager のアップグレード

11

9. NSX Managerのデプロイ

12

10.Deep Security ManagerとNSXの連携設定

13

11.Guest Introspectionのデプロイ ※詳細手順では、仮想標準スイッチ使用時の注意点を追記

14

12.DSVA(Deep Security Virtual Appliance)のデプロイ ※詳細手順では、既知の問題について追記

15

13.Security Policy / Security Groupの作成等

16

17

14.対象VMを順次有効化

18

15. 新規VMの自動有効化設定

19

16.vShield Managerを削除 手順3で停止した、「vShield Manager」仮想マシンを削除
※画面ショットは手順3の画面

20

◆アップグレードの詳細手順◆
詳細手順をダウンロードできます。
https://app.box.com/s/5n62ebuw8c30yg5vzwki22g4qblwdp17

◆トラブルシューティングガイド◆
Deep Security + NSXのトラブルシューティングガイドをダウンロードできます。http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/DSVA_9.5-6TroubleshootingTips_NSX.pdf?elqTrackId=9bc23ac857cc422897d92420f93dc17b&elqaid=979&elqat=2

◆まとめ◆
今回のBlogでは、vSphere 5.5環境でのアップグレード手順を共有いたしました。
今回のアップグレードは仮想基盤も含まれているため、事前にどのような手順で進めるのかを知ることは有益ですよね。詳細手順ではアップグレード中に認識できた注意点についても付記しています。こちらの手順をガイドに、工数の見積り、トラブルのない導入に活用いただけましたら幸いです。

nakagawa