6日本ヒューレット・パッカード株式会社の中川明美です。DRSの次の機能をご紹介します。Operationsのさらなる活用がけん引できそうですね。連携し、仮想マシンの配置とリソースのバランスを決定する機能です。vROpsは、履歴データに基づき、近い将来の仮想マシンの予測ワークロードを分析します。vROpsではトレンドとして表示されます。(リアルタイムメトリック)に加え、予測ワークロード値(予測メトリック)にも対応し、仮想マシンからリソースが要求される前に、仮想マシンの配置を決定することができます。6.4以降の環境で使用できます。DRSを有効化します。状況によって、移行を判断するメトリックが異なります。<現在の使用率が予測使用率を上回る場合>現在の使用率が優先され、この値を使用して推奨が生成されます。<予測使用率が現在の使用率を上回る場合>予測使用率の値が仮想マシンの現在のデマンドとして使用されます。このデマンド値を基に、仮想マシンからリソースが要求される前にリソースが利用できる状況にします。要求前に対応するため、パフォーマンスへの影響を軽減します。Optionsが追加されています。<仮想マシンの分散:TryBalanceVmsPerHost>ESXiホスト間で仮想マシンの数を均等に分散します。DRSにより1台のESXiホスト上に多くの仮想マシンが配置される場合があります。HAが動作した場合、分散された仮想マシンと比べ、多くの仮想マシンの再起動が必要になります。このような状況を回避する際に、仮想マシンの分散は有効です。このオプションを設定すると、各ESXiホストにはロードバランシングmaxVMsの制限が与えられます。この制限は、ロードバランシングにのみ適用されます。<ロードバランシングのためのメモリメトリック>ESXiホスト上のメモリ負荷を計算する時、「有効なメモリ」ではなく「消費されたメモリ」メトリックを使用します。オーバーコミットされている環境では有効なメモリが適しています。有効なメモリは、アイドルメモリの25%が加算され、負荷を計算します。オーバーコミットされていない環境では、このオプションを選択し、消費されたメモリを使用してバランシングすることもできます。MaxVcpusPerClusterPct>クラスタ内で仮想CPUと物理CPUの比率を設定し、オーバーコミットを制御します。オプションで定義された値に達すると、追加の仮想マシンをパワーオンことはできません。オーバーコミットメント率(最小0/最大500)は、次を参考にしてください。(コア)このオプションはクラスタが対象です。ESXiホストを対象とする場合は「MaxVcpusPerCore」で指定します。追加機能ではありませんが、改良点をご紹介します。◆DRS移行のしきい値6.5では、移行のしきい値に従来のCPUとメモリに加え、物理NICの使用率が加わりました。CPUとメモリの統計値から移行の可否を判断することに変わりはありません。初期配置および負荷分散のために移行先のESXiホストが選択されると、次にDRSはその移行先が最適かを判断するために、ネットワーク使用率をチェックします。超えていれば、最適な配置ではないと判断し、別のESXiホストを使用します。ネットワーク使用率のしきい値は、「NetworkAwareDrsSaturationThresholdPercent」で変更します。6.5のDRSについての詳細な情報は、こちらを参照ください。こちらのBlogでは取り上げなかった、パフォーマンス向上のための改良点についても述べられています。https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/drs-vsphere65-perf.pdfアップデートされたDRSについては終了です。ここからは、クラスタからESXiホストを削除する方法をご紹介します。「メンテナンスモードにしなければクラスタからESXiホストを削除できないのですかと尋ねられることがあります。こちらで紹介する方法は、仮想マシンをシャットダウンできない場合にお試しください。可能なら、メンテナンスモードに移行後、クラスタから削除ください。◆クラスタからESXiホストの削除◆メンテナンスモードに移行せず、ホストをインベントリから除去すると、次のメッセージが表示されます。Serverから切断すると、メンテナンスモードに移行せず、ESXiホストをインベントリから除去することができます。ESXiホストを右クリック→接続→切断と操作します。次のメッセージの内容を確認の上、操作を進めてください。切断後、インベントリの除去を行うと、次のメッセージが表示され、ESXiホストをクラスタから削除することができます。ドラッグアンドドロップで、データセンター配下に置くこともできます。6.5」のすべての回が終了しました。vSphereもバージョンが上がるたびに様々改善されていますね。今回取り上げた機能を使用すると、運用管理面が強化されるように思います。HAやDRSは、ホスト障害およびパフォーマンス低下に備えて、予防しましょうというメッセージを感じます。今後は、HAとDRSの併用を前提に、構築設計していく必要があるのかもしれませんね。Cloud環境がけん引されそうですね。vRealize製品も注目を集めそうです。機会がありましたら、vRealize製品のBlogも投稿できたらと思います。Part5日本ヒューレット・パッカード株式会社の中川明美です。HAの次の3つの機能についてご紹介します。HAはvSphere基盤の可用性を提供する重要な機能です。運用に関わるエンドユーザー様を対象にトレーニングを実施してきた私には、追加された3つの機能はエンドユーザー様の声を反映したアップデートではないかという印象を受けます。Plusで提供されるDRSやサーバーのPluginが前提となる機能もありますから、ご提案時にはこれらの機能もふまえ、ご紹介いただけたらと思います。HAの構成内容をDRSへ知らせ、仮想マシンを移行します。ファンに障害が発生し健全性が低下した場合、仮想マシンの移行によって可用性が提供されます。HAプロバイダは、サーバーベンダーから提供されます。HAをオンにする」を選択します。仮想マシンの移行(vMotion)により仮想マシンを保護するため、DRSの有効が前提となります。HAの構成>構成には、「自動化レベル」と「修正」の2つがあります。「自動化レベル」では仮想マシンの移行方法を、「修正」では健全性が低下したホストの使用可否を指定します。<自動化レベル>「手動」と「自動化」があります。手動:DRSと同様に仮想マシンの移行先が推奨されます。モードにしたがい使用の可否が決まります。<修正>「検疫モード」「混合モード」「メンテナスモード」があります。検疫モード:一部のハードウェア(メモリ/ネットワーク/ストレージ等)の障害にともない、性能が低下したホストを使用しません。仮想マシンのパフォーマンスに影響がない範囲においてです。混合モード:検疫モードの状態に加え、重大な障害が発生したホストは使用しません。メンテナンスモード:一部のハードウェアに障害が発生したホストは使用しません。HAプロバイダが必要です。HAプロバイダが表示されます。HAプロバイダは有効になります。vCenter」を導入します。HAに対応するOneViewは2017年11月提供予定です。vCenter」を導入します。HAプロバイダの詳細については、各サーバーベンダーへお問い合わせください。HAによる再起動のオーケストレーション(Orchestration)を設定することができます。再起動の優先順位と仮想マシン間の依存関係を構成することによって、より詳細な再起動の順序を指定することができます。下図はクラスタの設定画面です。仮想マシンは、次の条件を満たすと他のホストへの配置や再起動の準備が整います。Toolsアプリケーションのハートビートが検出される各仮想マシンの設定は、「設定」の「仮想マシンのオーバーライド」を使用します。設定対象の仮想マシンを追加します。<仮想マシン再起動の優先順位>優先順位は5つのレベルがあります。優先順位が高い仮想マシンを再起動後、次に優先順位が高い仮想マシンを再起動します。次の場合は異なります。FTのセカンダリ仮想マシンは、他の仮想マシンより優先される<優先度が次に高い仮想マシンを次の場合に起動/遅延時間の追加>依存関係は、再起動の優先順位と特定の条件に一致した場合の遅延時間で指定します。「割り当てられたリソース」「パワーオン」「検出されたゲストのハートビート」「検出されたアプリケーションのハートビート」のいずれかの条件を満たした後、指定された遅延時間を待って、次に優先順位の高い仮想マシンを再起動します。<または次におけるタイムアウトの発生後>指定した条件が満たされない場合はタイムアウトになります。HAは次に優先順位の高い仮想マシンの再起動へ進みます。<仮想マシングループ間アフィニティルールを利用した依存関係の構成>依存関係を構成するには、仮想マシングループ間のルールを利用することもできます。特定の順序で再起動しなければ正常に復旧しない複数層のアプリケーションには有効です。一般的な例として、DB>>App>>Webの3階層システムがあります。DBが再起動した後にAppを再起動するルール、Appが再起動した後にWebが再起動するルールを作成します。ルールは直接的な依存関係で構成します。DBが再起動した後にAppを再起動するルールでは仮想マシンを再起動できません。(※修正加筆)3階層システムの仮想マシンを「仮想マシン間アフィニティルール」を使用して保護する場合、すべての仮想マシンを同じESXiホスト上に配置します。同じESXiホスト上に配置することによって、ルールで指定した順序で仮想マシンを再起動することができます。同じESXiホストに配置するためには「仮想マシンとホスト間のアフィニティルール」を使用します。クラスタレベルの「優先度が次に高い仮想マシンを次の場合に起動」では、「割り当てられたリソース」以外に設定します。次の状況では、仮想マシン間アフィニティルールを使用しても、依存関係を満たすことはできません。障害があったホスト上にDB仮想マシンとWeb仮想マシンが稼働し、障害のないホスト上でApp仮想マシンが稼働していたとします。HAはDBとWebの仮想マシンはフェイルオーバーしますが、Appの仮想マシンは再起動しません。コントロールの選択方法がわかりやすくなりましたね。許容するホスト障害の台数を指定し、その後はフェイルオーバー時のリソース予約をするか否か、するのであれば3つのうちのどの方法で予約するのかという流れになっています。キャパシティの割合を超えた場合、警告を表示する機能が追加されました。この機能は、クラスタリソースの使用状況を取得するために、DRSを有効にする必要があります。HAクラスタはESXiホスト2台で構成し、「クラスタで許容するホスト障害」を1台に設定しています。リソースの自動計算により、CPU50%/メモリ50%がフェイルオーバーキャパシティとして予約されています。「仮想マシンで許容するパフォーマンス低下」でしきい値を「0」%に設定すると、クラスタのリソース使用率がフェイルオーバーキャパシティを超えた時、クラスタの「サマリ」タブに下図の警告が表示されます。この機能によって、構成の問題が発生するタイミングを指定することができます。6.5で追加された機能は、「ESXiホストの障害時にあわてなくても大丈夫。追加機能を活用して可用性を高めましょう。」と言われたような気がしました。Plusのライセンスが必要です。6.5へUpgradeを検討されていらっしゃるエンドユーザー様は、運用の効率性も見据えてご検討いただければと思います。DRSでアップデートされた機能をご紹介します。DRS」にとても興味があります。Part4日本ヒューレット・パッカード株式会社の中川明美です。6.5で使用可能な3つの管理ツールについてご紹介します。バージョン)」はパフォーマンスと操作性が改良されています。6.5から使用不可となりました。6.5で使用可能な3つの管理ツールの違いを確認します。バージョン)」を使用します。Clientと類似したユーザーインターフェイスです。慣れた画面構成で、初めて使う方でも操作に迷うことはほとんどないと思われます。Serverで提供される機能は表示されません。特別な設定も必要とせず、サポートされるWebブラウザを準備するのみです。Clientへ接続します。以降から使用可能です。6.0を運用管理されているユーザーの方もぜひ試用してみてください。Clientは、ダウンロード等の事前準備が必要ないこと、vSphereバージョンごとの導入が必要ないことをメリットと感じます。Flexの有効)は必要ありません。Client同様、対応のWebブラウザがあれば使用可能です。(HTML5)へ接続します。(HTML5)は未サポートの機能もあります。1から標準的な機能が追加されています。Managerのトレーニングテキストを作成するために、テスト環境を構築しました。標準的な機能を使用するのであれば十分ですね。全機能の移行が待たれます。Clientがすべての機能やプラグインを提供する管理ツールとなります。16以降のインストール、およびサポートされるWebブラウザを準備する必要があります。Clientへ接続します。Clientの改善点をいくつか挙げます。タブで構成されています。以前の「管理」から「構成」へタブが変更されています。Serverのwebclient.propertiesを編集し、「管理」タブへ戻すことも可能です。Clientに近いメニュー構成に変更されています。以前と比べ階層が1つ減り、操作性が改良されています。6.0以前のバージョンでは、次の機能を実行するために、クライアント統合プラグインが必要でした。小さな改良ですが、嬉しい改良点ですね。6.0以前のクライアント統合プラグインの後継機能です。カード機能を提供します。この2つの機能のみが、以前のクライアント統合プラグインから引き継がれます。6.5の拡張プラグインの間で競合は発生しません。Clientへ完全に移行します。Clientで使用可能です。(HTML5)で使用可能な機能の最新情報はこちらでご確認ください。Clientが廃止されるのは少々寂しい気持ちになります。快適な使用環境へ移行しているのですから、喜ばしいことです。Clientへ完全に移行されました。6.5ではメニュー構成も改良されています。5.0で大きくアーキテクチャーを変更し、その後も小さな改良が見られます。HAの改善を追求していると感じます。HAは運用において重要な機能ですからね。次回も参考にしていただければ幸いです。