Workload Optimization Manager 3.5.0

ユーザー ガイド

 

このマニュアルに記載されている仕様および製品に関する情報は、予告なしに変更されることがあります。このマニュアルに記載されている表現、情報、および推奨事項は、すべて正確であると考えていますが、明示的であれ黙示的であれ、一切の保証の責任を負わないものとします。このマニュアルに記載されている製品の使用は、すべてユーザー側の責任となります。

対象製品のソフトウェア ライセンスと限定保証は、製品に添付された『Information Packet』に記載されています。添付されていない場合には、代理店にご連絡ください。

Cisco が採用している TCP ヘッダー圧縮機能は、UNIX オペレーティング システムの UCB（University of California, Berkeley）のパブリック ドメイン バージョンとして、UCB が開発したプログラムを採用したものです。All rights reserved. Copyright © 1981, Regents of the University of California.

ここに記載されている他のいかなる保証にもよらず、各社のすべてのマニュアルおよびソフトウェアは、障害も含めて「現状のまま」として提供されます。シスコおよび上記代理店は、商品性、特定目的適合、および非侵害の保証、もしくは取り引き、使用、または商慣行から発生する保証を含み、これらに限定することなく、明示または暗黙のすべての保証を放棄します。

いかなる場合においても、シスコおよびその供給者は、このマニュアルの使用または使用できないことによって発生する利益の損失やデータの損傷をはじめとする、間接的、派生的、偶発的、あるいは特殊な損害について、あらゆる可能性がシスコまたはその供給者に知らされていても、それらに対する責任を一切負わないものとします。

このマニュアルで使用している IP アドレスおよび電話番号は、実際のアドレスおよび電話番号を示すものではありません。マニュアルの中の例、コマンド出力、ネットワーク トポロジ図、およびその他の図は、説明のみを目的として使用されています。説明の中に実際の IP アドレスおよび電話番号が使用されていたとしても、それは意図的なものではなく、偶然の一致によるものです。

この文書の印刷されたハード コピーおよび複製されたソフト コピーは、すべて管理対象外と見なされます。最新版については、現在のオンライン バージョンを参照してください。

シスコは世界各国 200 箇所にオフィスを開設しています。各オフィスの住所、電話番号、FAX 番号については、Cisco のウェブサイト www.cisco.com/go/offices をご覧ください。

Cisco および Cisco のロゴは、米国およびその他の国における Cisco およびその関係会社の登録商標を示します。シスコの商標の一覧については、https://www.cisco.com/c/en/us/about/legal/trademarks.html. をご覧ください。Third-party trademarks mentioned are the property of their respective owners. 「パートナー」という言葉が使用されていても、シスコと他社の間にパートナーシップ関係が存在することを意味するものではありません。（1721R）

© 2018-2022 Cisco Systems, Inc. All rights reserved.

 

 

 

 

 

最新情報

Workload Optimization Manager は、弊社の次世代アーキテクチャによって強化されており、単一インスタンスの展開で、コア プラットフォームを大規模なアプリケーションおよびインフラストラクチャ環境に合わせて拡張できます。これにより、アプリケーションのパフォーマンスと正常性を引き続き確保しながら、複雑さが解消され、スケールオンデマンド機能が提供されます。

バージョン 3.5.0

■        メンテナンス自動化の回避

DRS クラスタを使用する vCenter 環境では、ホスト ポリシーでメンテナンスの自動化の回避設定を使用して、Workload Optimization Manager と DRS 間のアクションの競合を回避できるようになりました。

詳細については、「メンテナンスの自動化の回避（238  ページ）を参照してください。

■        ハードウェア更新プランの改善

ハードウェア更新プランを実行すると、Workload Optimization Managerは、過去 10 日間のクラスタの全体的なリソース使用率を考慮して、プラン結果の正確度を高めるようになりました。プラットフォームは、10 日間のうち、クラスタのパーセンタイル使用率が 90% に達した日を特定し、その日の各 VM の実際の使用率データを使用して分析を実行します。このリリースより前は、プラットフォームは、プランのスナップショットが作成された時点での各 VM の実際の使用率データを使用していました。

注：

基準値スナップショットを使用するようにハードウェア更新プランを構成した場合、そのプランはクラスタのパーセンタイル データではなく、そのスナップショットのデータを使用します。

■        Microsoft Azure Billing のターゲットのサポート

このリリースでは、Microsoft Azure Billing のターゲットのサポートが導入されています。Workload Optimization Manager は、エンタープライズ アグリーメント（EA）オファー ID を通じて、Azure 課金情報アカウントと関連するサブスクリプションを検出します。

注：

政府機関以外のアカウントには Microsoft Azure Billing のターゲットを使用します。

詳細については、『 ターゲットの構成ガイド』の「Microsoft Azure Billing のターゲット」を参照してください。

■        GCP ボリュームの削除アクション

Workload Optimization Manager は、コスト削減策として、接続されていない GCP ボリュームの削除を推奨できるようになりました。

このリリースでは、Workload Optimization Manager はゾーン（単一ゾーン）永続ディスクの削除アクションを生成します。潜在的な節約またはボリュームのサマリ チャートを使用して、アクションを表示および実行します。

詳細については、『ターゲット構成ガイド』の「GCP アクション」を参照してください。

■        コンテキストベースのアプリケーション トポロジ

Workload Optimization Manager は、アプリケーション トポロジ機能のコンテキストベースのアプリケーション定義をサポートするようになったため、最小限の労力で定義を作成し、通常の範囲外のアプリケーション パフォーマンスの問題を特定できます。アプリケーションが進化するにつれて、Workload Optimization Manager は、環境に合わせて定義を自動的に更新します。

 

 

詳細については、「アプリケーション トポロジ（115 ページ ）」を参照してください。

■        Workload Optimization Manager ウェブフック

Workload Optimization Manager で自動化ポリシーを構成して、ウェブフックを介して外部 HTTP サーバにデータを送信できるようになりました。Slack などのコラボレーション プラットフォームに通知を送信したり、Workload Optimization Manager をワークフロー管理システムと統合したりできます。

詳細については、ウェブフック（96ページ ）を参照してください。

製品概要

Workload Optimization Manager、クラウドおよびリモート対応環境用アプリケーションリソース管理（ARM）向けプレミアソリューションをお選びいただきありがとうございます。

アプリケーションリソース管理は、アプリケーションのリソースニーズを継続的に分析し、完全に自動化可能なアクションを生成して、アプリケーションが常に実行する必要があることを確実にする、トップダウンのアプリケーション駆動型のアプローチです。24 時間 365 日稼働し、最大規模で最も複雑な環境に対応します。

アプリケーション リソース管理を実行するには、Workload Optimization Manager で、環境全体をリソース購入者と販売者のサプライチェーンとして表現し、すべてを連携させてアプリケーションの需要に対応します。購入者（VM、インスタンス、コンテナ、サービス）は、アプリケーションの実行に必要となるリソースを予算内で探すことができるようになり、販売者は、リアルタイムの使用率に基づいて利用可能なリソース（CPU、メモリ、ストレージ、ネットワーク）の価格を設定できるようになります。それによって、Workload Optimization Manager は、環境を望ましい状態に維持し、次のような矛盾する目的を同時に達成する条件を操作します。

■        保証されたアプリケーション パフォーマンス

ボトルネックを防ぎ、コンテナ/VM のサイズを大きくし、ワークロードに優先順位を付け、ストレージの遅延を削減します。

■        リソースの効率的な利用

ワークロードを統合して、インフラストラクチャの使用を最小限に抑え、コンテナを縮小し、スプロールを防ぎ、最も経済的なクラウドサービスを使用します。

Workload Optimization Manager は、ネットワークまたはパブリッククラウド VPC 上の Kubernetes 環境（または VM 内）で実行される、コンテナ化された、マイクロサービスで設計されたアプリケーションです。次に、ネットワークで実行中のサービスを Workload Optimization Manager ターゲット に割り当てます。Workload Optimization Manager は、各ターゲットが管理するエンティティ（物理的なデバイス、仮想コンポーネントおよびソフトウェア コンポーネント）を検出し、分析を実行し、パフォーマンスや効率性に関するリスクを予測し、問題発生前に回避するアクションを推奨します。

Workload Optimization Manager の仕組み

インフラストラクチャを望ましい状態に維持するために、Workload Optimization Manager はアプリケーション リソースカンリを実行します。これは、アプリケーションのパフォーマンスを保証すると同時にリソースの最も効率的な使用を実現シ、ビジネス ルールに準拠するために環境制約を尊重するという問題を解決する継続的なプロセスです。

これは、単純に解決できる問題ではありません。アプリケーション リソース管理では、多くの異なるリソースとそれらが相互にどのように使用されているか、および各リソースの多数のコントロール ポイントを考慮する必要があります。インフラストラクチャを成長させるにつれて、それぞれの決定で考慮すべき要因が急増します。しかも、環境は常に変化しています。そこで、望ましい状態を維持するために、動くターゲットを常に捉えようとするわけです。

アプリケーション リソース管理を実行するために、Workload Optimization Manager は、購入者と販売者で構成されるマーケットとして環境をモデル化します。これらの購入者と販売者は、インベントリ内のエンティティの階層を表すサプライチェーンを構成しています。このサプライ チェーンは、データセンターから環境内の物理階層、仮想階層を経てさらにクラウドへと至るリソースのフローを表します。これらの購入者と販売者との関係を管理することにより、Workload Optimization Manager は、データセンターからアプリケーションまで、リソースのクローズドループ管理を提供します。

購入者と販売者の関係を示す視覚的なレイアウトについては、「エンティティのサプライ チェーン（33  ページ）」を参照してください。

Workload Optimization Manager は、仮想通貨を使用して購入者に予算を与え、リソースにコストを割り当てます。この仮想通貨は、環境のすべての階層に渡って値を割り当てて、アプリケーション トランザクションのコストと、データセンター内のディスク容量または物理スペースのコストを比較できるようにします。

販売業者がリソースに対して請求する価格は、販売者の供給に応じて変化します。需要が増えると、価格が上昇します。価格が変更されると、購入者と販売者がそれに反応します。購入者は、より有利な価格を提供する他の販売者を自由に探すことができます。また販売者は、需要の増加に合わせて自身のための複製（新しい店舗をオープンする）を行うことができます。Workload Optimization Manager は、その経済スケジューリングエンジンを使用してマーケットを分析し、これらの決定を行います。効果として得られるのは、IT インフラストラクチャをリソースの最適な使用に向けて動的に誘導する見えざる手のようなものです。

Workload Optimization Manager を最大限に活用するには、環境のモデル化の方法、実行する分析の種類、および実現する望ましい状態を理解しておく必要があります。

望ましい状態

アプリケーションリソース管理の目的は、リソースの効率的な使用を維持しつつ、パフォーマンスを確保することです。効率性とパフォーマンスの両方が維持されている場合、環境は望ましい状態になります。遅延の関数としてパフォーマンスを測定できます。その場合、遅延がゼロのときに、特定のサービスの理想的な QoS が実現します。リソースの効率的な使用は使用率の関数として表され、100% のリソース資料率が最も効率的な使用を表す理想値になります。

遅延と使用率をプロットすると、結果は使用率と遅延の相関関係を示す曲線になります。ある程度までは使用率を上げると、遅延の増加はわずかになります。曲線上で、使用率のわずかな増加が許容できないほどの遅延の増加をもたらすポイントがあります。一方、曲線には、使用率の低下が QoS の有意な増加を生み出さないポイントがあります。望ましい状態は、曲線上のこれらのポイント内にあります。

上限を超えたときにアラートを送信するしきい値を設定できます。この場合、遅延が受け入れられなくなるまで問題には対処しません。反応の遅さを回避するため、上限を超える前にアラートを送信するしきい値を設定することができます。この場合は、過剰なプロビジョニングのコストが無駄になるときの QoS を保証します。つまり運用コストが増加し、効率的な使用率が達成されないという状況です。

Workload Optimization Manager は、しきい値を超えた後に応答するのではなく、運用条件を分析し、環境全体を望ましい状態に維持するためのアクションを常に推奨します。これらのアクションを実行すると（または Workload Optimization Manager に代行させます）、環境はお客様のパフォーマンスを保証する運用条件を維持し、一方でリソースの効率的な使用率によりコストを最小限に抑えることができます。

マーケットと仮想通貨

アプリケーション リソース管理を実行するために、Workload Optimization Manager は環境をマーケットとしてモデル化し、マーケット分析を使用してリソースの供給と需要を管理します。たとえば、ローカルのワークロードの需要がローカルの容量を超えた場合（つまり、需要が供給を超過した場合）に、ボトルネックが形成されます。環境をマーケットとしてモデル化することにより、Workload Optimization Manager は経済的ソリューションを使用して、需要を効率的に再配布したり、供給を増やすことができます。

Workload Optimization Manager は、次の 2 つのセットの抽象化を使用して環境をモデル化します。

■        物理および仮想 IT スタックをサービスサプライチェーンとしてモデル化

サプライ チェーンは、環境を管理対象エンティティとしてモデル化します。これらには、アプリケーション、VM、ホスト、ストレージ、コンテナー、アベイラビリティー ゾーン（クラウド）、およびデータ センターが含まれます。すべてのエンティティは、購入者、販売者、またはその両方です。ホストマシンは、データセンターから物理的な空間、電力および冷却装置を購入します。ホストは、CPU サイクルやメモリなどのホストのリソースを VM に販売します。次に、VM はホストのサービスを購入し、リソース（VMem と VCPU）をコンテナに、その後、アプリケーションに販売します。

購入者と販売者の関係を示す視覚的なレイアウトについては、「エンティティのサプライ チェーン（33  ページ）」を参照してください。

■        仮想通貨を使用して遅延または QoS の低下を表し、モデル化されたサプライチェーンに沿ったサービスの提供と需要を管理します。

システムは仮想通貨を使用して、これらの購入や販売トランザクションに値を指定します。各管理対象エンティティには実行中の予算があります。エンティティはコンシューマにリソースを提供することによって予算に追加され、エンティティは予算から引き出して、消費するリソースを支払うのです。リソースの価格は、その使用率によって決まります。リソースの需要が増えると、価格が高くなります。

 

これらの抽象化により、環境全体のスペクトラムがシングルモードの分析（マーケット分析）向けに開放されます。リソースとサービスは、供給および需要の変化を反映するように価格設定することができ、価格設定によってリソース割り当ての決定を行えます。たとえば、ボトルネック（供給を超える需要）によって、特定のリソースの価格が上昇します。同じリソースで競合しているアプリケーションは、他のリソース供給者にワークロードを移すことによって、コストを削減できます。その結果、そのリソースの使用率が環境全体において均一化し、ボトルネックが解決されます。

 

リスク指標

Workload Optimization Manager は、リスク指標の観点からリソースの価格を追跡します。リソースのこの指標が高くなるほど、リソースの使用率が高くなります。そのリソースのコンシューマにとって遅延が大きくなるほど、QoS に対するリスクが高くなります。Workload Optimization Manager は、リスク指標を許容範囲内に維持するために常に機能します。

リスク指標はリソースのコストと見なすことができます。Workload Optimization Manager により、コストが競争力のあるレベルに維持されます。これは、単にしきい値の条件に対応することではありません。Workload Optimization Manager は、すべての範囲の購入者や販売者の関係を分析し、各購入者は常に、利用できる最も経済的なトランザクションを探します。

この最後の点は、Workload Optimization Manager を理解する上で重要です。仮想環境は動的であり、お客様がアプリケーションやサービスから行うさまざまな要求に対応するワークロードは常に変化しています。各購入者や販売者の関係を調べることで、Workload Optimization Manager により、環境の現在の状態に対する最適なワークロードの分散がもたらされます。このようにして、Intersight Workload Optimizer は、常に環境を望ましい状態へと導きます。

注：

デフォルトの Workload Optimization Manager の設定は、多くの環境ですぐに使用できます。ただし、環境内の特別なサービスやリソースに対応するために、設定を微調整することができます。Workload Optimization Manager には、ソフトウェアが特定のエンティティグループを管理する方法を制御するために設定できる、幅広いポリシーが用意されています。このようなポリシーを変更する前に、デフォルトの Workload Optimization Manager の操作を理解しておく必要があります。ポリシーの詳細については、 ポリシーの使用（69  ページ）を参照してください

 

Workload Optimization Manager のサプライ チェーン

Workload Optimization Manager は、お客様の環境を購入者や販売者のマーケットとしてモデル化します。追加したターゲットを介して環境内のさまざまなタイプのエンティティを検出し、これらのエンティティをサプライチェーンにマップして、それらがサポートするワークロードを管理します。たとえばハイパーバイザ ターゲットの場合、Workload Optimization Manager は VM、VM にリソースを提供するホストおよびデータストア、VM リソースを使用するアプリケーションを検出します。Kubernetes ターゲットの場合、サービス、名前空間、コンテナ、コンテナポッド、およびノードを検出します。環境内のエンティティは、一部のエンティティがリソースを提供し、その他のエンティティが供給されたリソースを消費する、一連の供給と需要を形成します。Workload Optimization Manager は、たとえば、検出された Kubernetes ノードを vCenter で検出された VM に接続することによって、これらのエンティティを結合します。

サプライ チェーンの特定のメンバーの詳細については、「エンティティのサプライ チェーン」（33   ページ）を参照してください。

サプライ チェーンの用語

シスコでは、供給および需要の観点から IT リソースと使用率を示すための特定の用語を導入しています。これらの用語はほとんど直感的に理解できますが、IT 管理の一般的な問題やアクティビティとどのように関係しているかを理解しておく必要があります。

 

Workload Optimization Manager のターゲット

Workload Optimization Manager のターゲットとして、次のテクノロジーのインスタンスを割り当てることができます。

■        アプリケーションとデータベース

–       Apache Tomcat 7.x、8.x および 8.5. x

–       AppDynamics 4.1+

–       AppInsights

–       Dynatrace 1.1+

–       IBM WebSphere Application Server 8.5+

–       Instana、リリース 209 以降

–       JBoss Application Server 6.3+

–       JVM 6.0 +

–       Microsoft SQL Server 2012、2014、2016、2017、および 2019

–       MySQL 5.6.x および 5.7.x

–       NewRelic

–       Oracle 11g R2、12c、18c、および 19c

–       Oracle WebLogic 12c

■        クラウドネイティブ

–       準拠した k8s ディストリビューション（Rancher、Tanzu、オープンソースなど）を含む Kubernetes

–       クラウドでホストされる k8s サービス（AKS、EKS、GKE、IBM、Cisco IKS、ROKS、ROSA など）

–       OpenShift 3.11 以降（OCP 4.x）

■        ファブリックとネットワーク

–       Cisco UCS Manager 3.1+

–       HPE OneView 3.00.04

■        ゲスト OS プロセス

–       SNMP

–       WMI：Windows バージョン 8 / 8.1、10、2008 R2、2012 / 2012 R2、2016、2019 および 7

■        ハイパーコンバージド

–       Cisco Hyperflex 3.5

–       Nutanix Community Edition

–       VMware vSAN

■        ハイパーバイザ

–       Citrix XenServer 5.6. x および 6.x

–       Microsoft Hyper-V 2008 R2、Hyper-V 2012/2012 R2、Hyper-V 2016、Hyper-V 2019

–       VMware vCenter 6.0、6.5、6.7、および 7.0+

■        オーケストレータ

–       Action Script

–       Flexera One

–       ServiceNow

■        プライベート クラウド

–             Microsoft System Center 2012/2012 R2 Virtual Machine Manager、System Center 2016 Virtual Machine Manager、および System Center Virtual Machine Manager 2019

■        パブリック クラウド

–       Amazon AWS

–       Amazon AWS Billing

–       Google Cloud Platform（GCP）

–       Google Cloud Platform（GCP）課金情報

–       Microsoft Azure Service Principal

–       Microsoft Azure Billing

–       Microsoft Enterprise Agreement

■        ストレージ

–       EMC ScaleIO 2.x および 3.x

–       SMI-S 8.1 + を使用した EMC VMAX

–       仮想ボリュームと LUN の 1:1 マッピングを搭載した EMC VPLEX ローカルアーキテクチャ

–       EMC XtremIO XMS 4.0 +

–       Spectrum Virtualize 8.3.1.2 またはそれ以降（8.4.2.0 またはそれ以降を推奨）で実行する IBM FlashSystem

–       ONTAP 8.0+ を使用した NetApp Cluster Mode（AFF および SolidFire を除く）

–       Pure Storage F-シリーズおよび M-シリーズアレイ

■        Virtual Desktop Infrastructure

–       VMware Horizon

次の章では、これらのターゲットについて説明します。Workload Optimization Manager へのターゲットの割り当てについては、『 Target Configuration Guide 』を参照してください。

ハイパーバイザ

Workload Optimization Manager は、ターゲットとして広範囲な VM マネージャを使用できます。一般的な説明については、このドキュメントでは、サポートされているさまざまな VM マネージャをハイパーバイザと呼びます。

Workload Optimization Manager は、ハイパーバイザ ターゲットを使用して、管理対象の VM、ホストおよびデータストアに関する情報にアクセスし、また、環境内のエンティティのプロビジョニング、サイズ変更、再設定などのコマンドを実行します。ハイパーバイザを介して、Workload Optimization Manager はシステムモニタリングを実行し、無駄になっているストレージに関するレポートを作成し、アクションを推奨します。また VM と VM ストレージの移動を行い、VM の再設定を実行できます（CPU 数、メモリの変更など）。

ハイパーバイザ ターゲットを介して Workload Optimization Manager が検出するエンティティには、次のものが含まれます。

■        VM

■        VM をホストする物理マシン

■        VM をサポートするデータストア

■        データセンター

クラウドマネージャ

クラウドマネージャは、自動的に展開できる（または顧客へのセルフサービスの提供時に展開できる）仮想インフラストラクチャを実現するための制御レイヤを提供します。仮想データセンター（VDC）を定義し管理します（クラウドオファリングをサポートする物理リソースと仮想リソースを管理するプロバイダー VDC および、顧客に限定されたリソースを提供するコンシューマ VDC）。

コンシューマ VDC の顧客に対して特別な Workload Optimization Manager のユーザーアカウントを作成できます。このようなアカウントの範囲は限られており、ユーザーはその範囲外のリソースを確認できません。このようにして、ワークロードを提供できます

独自のインフラストラクチャ データを公開することなく、クラウドのお客様に Workload Optimization Manager を提供できます。詳細については、「ユーザー アカウントの管理（395  ページ）」を参照してください。

クラウドマネージャのターゲットを介して Workload Optimization Manager が検出するエンティティは次のとおりです。

■        コンシューマ VDC

顧客が利用できる仮想リソース。

■        プロバイダー VDC

コンシューマ VDC をサポートするためのインフラストラクチャを提供する物理リソース。

ストレージマネージャ

ストレージ マネージャは、ディスク アレイ間でデータストレージの管理と分散を実現します。ストレージ マネージャは、シンプロビジョニング、重複除去、および HA アーキテクチャをサポートできます。Workload Optimization Manager は、ストレージシステム全体のリソース使用率をモニターし、ストレージ コントローラ リソースの管理だけでなく、ボリュームとディスクアレイの配置とプロビジョニングを最適化します。

Workload Optimization Manager がストレージマネージャのターゲットを通じて検知するエンティティには、次のものが含まれます。

■        ストレージコントローラ（NetApp コントローラおよびファイラ、VNX プロセッサ）

■        ディスクアレイ（集約、クラスタ化された集約、ストレージプール、RAID グループ）

■        データストア（ボリュームまたは Lun）

Fabric Managers

Fabric Manager は、単一のシステム内でコンピューティング、ネットワーク、ストレージ、および仮想リソースを統合するファブリックの制御ポイントを提供します。

Workload Optimization Manager が Fabric Manager のターゲットを通して検知するエンティティは、次のものを含みます。

■        UCS ドメイン

■        シャーシ

■        ファブリック インターコネクト

■        IO モジュール

リソースの説明

インテリジェントなワークロードバランシングを実行するために、Workload Optimization Manager はターゲットサーバー（ハイパーバイザ、クラウド管理スタック、パブリック クラウド アカウントなど）から raw データを収集します。Workload Optimization Manager は、最新のデータサンプルを収集するために、そのターゲットを 10 分間隔でポーリングします。次に、これらの 10 分間のデータポイントを分析に使用し、GUI にデータを表示します。

Workload Optimization Manager が vCenter サーバーからホストメモリデータを収集する方法は、これがどのように動作するかを示しています。vCenter サーバーは、20 秒間隔で管理対象 VM からピークメトリックを収集します。10分ごとに Workload Optimization Manager は、vCenter サーバーをポーリングして、最後のデータサンプルを収集します（10 分間に 30 サンプル）。VM のホストメモリの使用率を追跡するために、Workload Optimization Manager は、vCenter に memory.active データサンプルを要求します。そのポーリングから、Workload Optimization Manager は次のことを追跡できます。

■        ピーク時のメモリ使用率：Workload Optimization Manager は、各ポーリングサンプルの最大値を使用します。これにより、選択された期間にわたって計算された、選択済みの VM（または VM のグループ）のアクティブメモリ使用率が最も高くなります。最大値の場合、Workload Optimization Manager は、データ サンプル内の観察された最も高いアクティブ メモリ値を使用します。

■        平均メモリ使用率：Workload Optimization Manager は、各ポーリングサンプルのすべての値を平均します。

次の表で、Workload Optimization Manager が収集するメトリックをリスト化し、それらがどのように収集または測定されたのかについての詳細を示します。Workload Optimization Manager のユーザーインターフェイスがクラスタまたはデバイスのグループのチャートをプロットすると、これらのチャートには、使用されている割り当て済みリソースの割合の平均が表示されます。

使用する前に

プラットフォームを使い始めるには、web ブラウザを開いて Workload Optimization Manager のインストールを参照します。Workload Optimization Manager プラットフォームは、ブラウザへのユーザーインターフェイスを提供します。ここでログインして環境の管理を開始できます。このようにして、どのようなインターネット接続からでも Workload Optimization Manager の固有の機能にアクセスできます。

 

Workload Optimization Manager へのログイン

プラットフォームを使い始めるには、web ブラウザを開いて Workload Optimization Manager のインストールを参照します。Workload Optimization Manager プラットフォームは、ブラウザへのユーザーインターフェイスを提供します。ここでログインして環境の管理を開始できます。このようにして、どのようなインターネット接続からでも Workload Optimization Manager の固有の機能にアクセスできます。

ログインする前に、企業は、有効な Workload Optimization Manager アカウントを持つ必要があります。または Workload Optimization Manager のインスタンスをお使いの環境にインストールする必要があります。Workload Optimization Manager のインストールのための IP アドレスを取得するには、システム管理者に問い合わせてください。

Workload Optimization Manager へのログイン方法：

1.      Web ブラウザで Workload Optimization Manager のインストールを表示します。

URL には、インストール用の IP アドレスまたはマシン名を指定します。この URL により、Workload Optimization Manager のログインページが開かれます。今後の使用のため、この URL をブックマークしてください。

2.      アカウントのユーザー名とパスワードを入力します。

システム管理者がユーザーアカウントを作成します。ログイン情報については、システム管理者にお問い合わせください。

ログインすると、ブラウザにホームページ（21 ページ ）が表示されます。このページは、Workload Optimization Manager プラットフォームを使用したセッションの開始点になります。このホームページで、環境の概要に関する以下の点を確認できます。

これらの情報を表示するために、Workload Optimization Manager はハイパーバイザ、ストレージコントローラ、パブリック クラウド アカウントなどのターゲットサービスと通信します。Workload Optimization Manager の管理者がターゲット設定をセットアップすることに注意してください。サポート対象のターゲットとその設定方法の詳細については、『 Target Configuration Guide 』の「Target Configuration」を参照してください。

 

ホームページ

Workload Optimization Manager を起動すると、ホームページが最初に表示されます。このタブでは、以下を実行できます。

■        環境の概要を表示するには、[View] を選択します。

–       アプリケーション： ビジネスアプリケーション（101 ページ）のコンテキストの環境が表示されます。

–       ON PREM：オンプレミス環境の詳細が表示されます。[Supply Chain] にはクラウドエンティティは含まれず、オンプレミスのエンティティのみが示されることに注意してください。

–       CLOUD：クラウド環境の詳細が表示されます。これには、保留中のアクション、コスト別のクラウドアカウントのリスト、現在使用しているクラウドデータセンターのロケーション、予想コスト、およびその他のコスト関連情報が含まれます。

■        サプライチェーンナビゲータを使用してエンティティのリストを検査する

[Supply Chain] 内の [entity tier] をクリックすると、それらのエンティティのリストが表示されます。たとえば、[Virtual Machine] をクリックして、環境内のすべての VM のリストを表示します。

■        以下のような他の Workload Optimization Manager ページに移動します。

–       [Search]：環境についての詳細にドリルダウンするためのセッション範囲を設定します。

–       計画 ー what-if シナリオを実行します。

–       [Place]：Workload Optimization Manager を使用してワークロードの最適な配置を計算し、指定した時間に配置を実行します。

–       ダッシュボード － 環境の詳細に焦点を当てたチャート付きのカスタムビューを設定します。

–       設定 － Workload Optimization Manager を構成して、ビジネスルールおよびポリシーの設定、ターゲットの構成、グループの定義、管理タスクの実行を行います。

ホームページに戻る

Workload Optimization Manager セッションのどこからでも、[ホーム（Home）] アイコンをクリックするとホーム ページに戻ることができます。

 

アプリケーションビュー

アプリケーションビューでは、ビジネスアプリケーション（ 101 ページ）のコンテキストの環境が表示されます。アプリケーションの全体的な正常性を確認し、パフォーマンスとコンプライアンスのリスクを調べて、これらのリスクに対処するために Workload Optimization Manager が推奨するアクションを実行します。

このビューには、ビジネス アプリ ケーションを構成するビジネス トランザクション（103  ページ）とサービス（106  ページ）も表示されます。アプリケーションモデルのこれらのレベルで、より詳細を確認し、SLO を設定できます。

注：

ON-PREM ビュー

セッションを [グローバル範囲（Global Scope）] に設定すると [オンプレミス（ON-PREM）] ビューを選択できます。このビューには、オンプレミス環境の概要が表示されます。パブリック クラウドにワークロードがない場合は、Workload Optimization Manager セッションの開始点としてこれを使用する必要があります。ハイブリッド環境（オンプレミスおよびパブリック クラウド）がある場合は、このビューを参照して、オンプレミスの詳細な概要を確認できます。

[Supply Chain] には、環境内のすべてのオンプレミスエンティティが表示されます。チャートには、以下を含む環境に関する詳細が表示されます。

■        保留中のアクションの概要

必要に応じて、概要には、アクションに関連付けられた 1 回限りの節約またはコストが含まれます。

■        上位クラスタ使用率

最も使用されているクラスタのリストを参照してください。このチャートには、これらのクラスタと、各クラスタのアクションの数が表示されます。クラスタの詳細をドリルダウンするには、クラスタ名をクリックします。特定のアクションを表示して実行するには、そのクラスタの [ACTIONS] ボタンをクリックします。環境内のすべてのクラスタを表示するには、[SHOW ALL] をクリックします。

■        最適化された改善

現在のリソース使用率を、保留中のすべてのアクションを実行することを選択した場合に表示される使用率と比較します。

■        アクション履歴

推奨および実行されたすべてのアクションの履歴、または承認および実行されたアクションのみの履歴を表示できます。

CLOUD ビュー

セッションを [グローバル範囲（Global Scope）] に設定すると [クラウド（CLOUD）] ビューを選択できます。このビューには、クラウド環境の概要が表示されます。すべてのワークロードがパブリック クラウド上にある場合は、Workload Optimization Manager のセッションの開始点としてこれを使用する必要があります。ハイブリッド環境（オンプレミスおよびパブリック クラウド上）の場合は、このビューを参照して、クラウドの詳細な概要を確認できます。

クラウドのコスト情報を表示するには、Workload Optimization Manager のインストールの際に 1 つ以上のパブリック クラウドのターゲットが設定されている必要があります。パブリッククラウド ターゲットの設定詳細については、『ターゲット構成ガイド』の「プライベートクラウド」を参照してください。

さらに、AWS ですべてのコスト情報を表示するには、AWS アカウントでコストと使用状況のレポートを作成しておく必要があります。また、これを S3 バケットに保存する必要があります。

このビューの [Supply Chain] には、環境内のすべてのクラウド エンティティが表示されます。チャートには、以下のようなクラウド環境に関する詳細が表示されます。

■        保留中のアクションの概要

概要には、これらのアクションに関連付けられた毎月の節約またはコストの見積もりが含まれます。

■        上位アカウントの使用率

最も使用されているパブリック クラウドのアカウントのリストを参照してください。チャートには、これらのアカウントが表示されるとともに、それぞれの月間コストの見積もりが示されます。環境内のすべてのクラウド アカウントを表示するには、[SHOW ALL] をクリックします。

■        必要な投資と潜在的な節約

保留中のアクションの現在のセットについて、これらのチャートには、金額における影響が示されます。必要な投資は、より多くのワークロードをプロビジョニングしたり、ワークロードのサイズを大きくするアクションから発生します。潜在的な節約は、サイズを小さくする、または 割引を購入して、それらをアクティブな用途に投入するアクションから発生します。

■        現在の割引を示すチャート。詳細については、「 割引（25 ページ）」を参照してください。

■        サービス別請求額

このチャートには、クラウド アカウントで使用する各クラウド サービスにおける経時的なコストが表示されます。たとえば、AWS S3 ストレージのコストと比較して、AWS CloudWatch のコストを確認できます。

クラウドコストの追跡

Workload Optimization Manager は、ターゲットから検出したコスト情報（アカウント、課金情報レポート、オンデマンドまたは割引コストなど）、価格調整、（385 ページ）、および料金表に基づいて、クラウドの支出を追跡します。

サービスのコスト

Workload Optimization Manager は、クラウドのターゲットに関連付けられているため、クラウドサービスのプロバイダーからの課金レポートを使用します。Workload Optimization Manager はこれらのレポートを解析して、サービス、サービス プロバイダー、Azure リソース グループ、およびクラウド アカウントによるコストの内訳を取得します。次のようなチャートでコストデータを確認できます。

■        Cloud Estimated Cost

■        Cost Breakdown by Cloud Accounts, Component, or Service Provider

■        Expenses

ワークロードのコスト

ワークロードとは、環境内で実行されている VM、またはデータベースサーバーやコンテナなどのその他のホストされたプロセスです。Workload Optimization Manager は、ワークロードの次のコストを追跡します。

■        コンピューティング

コストの計算のため、Workload Optimization Manager では、関連付けられているパブリック クラウド アカウントで指定されている、テンプレートごとの毎時間のコストを使用します。

■        ストレージ

Workload Optimization Managerは、特定のワークロードをサポートするストレージ階層を検出し、階層への価格設定を使用してストレージコストを計算します。

■        ライセンス

AWS 環境の場合、Workload Optimization Manager は OS のコストを計算することができます。VM の OS コストを計算するために、Workload Optimization Manager は、公開されたワークロードコストからテンプレートコストを減算します。この差異が、そのワークロードに対するライセンスコストであることが前提となっています。OS がオープンソースの場合、差異はなく、ライセンスコストはゼロになります。

Azure 環境では、Workload Optimization Manager は既存の VM の OS コストを追跡できます。予約購入アクションの場合、Workload Optimization Manager には OS コストは含まれません。Azure 予約の詳細については、「Azure エンタープライズ アグリーメント（392  ページ）を参照してください。

■        IP

一部のワークロードでは、コストが発生する IP サービスを使用する場合があります。たとえば、クラウドプロバイダーは、VM に静的 IP アドレスを付与するために課金する場合があります。AWS 環境では、Workload Optimization Manager はそのコストを、計算および分析に含めることができます。

Workload Optimization Manager は、VM のサイズ変更と配置の決定時に、このコスト情報を使用します。この情報は、経費チャートで確認できます。

AWS 上の専用テナントのコスト

AWS で VM を作成する場合は、テナントを指定できます。専用テナント（DT）を指定すると、作成する VM は、単一の顧客専用のハードウェア上で実行されている Amazon EC2 インスタンスになります。Workload Optimization Manager のコンテキストで DT を把握するには、以下のことを考慮する必要があります。

■        AWS の場合、Workload Optimization Manager のサプライチェーンには、可用性ゾーンがホストとして表示されます。サプライ チェーンは、ある VM に特定の可用性ゾーン内の特定のリソース専用のテナントがあるかどうかを示しません。また、Workload Optimization Manager は、ワークロードの専用ホスティングのコストを検出したり、表示したりしません。

■        DT ワークロードの価格設定は、共有テナントの価格設定とは異なります。Workload Optimization Manager はその違いを検出せず、DT ワークロードに共有テナントコストを使用します。アクションの説明では、表示される節約または投資は共有テナントのコストに基づいています。

■        Workload Optimization Manager は、DT ワークロードについて、RI の実際のコストを検出します。ただし、オンデマンドの VM のコストは共有テナントに基づいているため、Workload Optimization Manager は、RI 容量を購入し使用する際の節約量を過大に表示することができます。ほとんどの場合、RI を購入するための推奨事項は正しくなります。ただし、ROI を達成するまでの時間は、アクションの説明やチャートが示す時間よりも長くなる可能性があります。

■        共有テナントに対して有効なインスタンスタイプの一部は、DT に対して有効ではありません。どのインスタンスタイプが DT VM に対して有効であるかを確認するには、AWS のドキュメントをお読みになるか、または AWS の担当者にお問い合わせください。

■        状況によっては、Workload Optimization Manager は、現在のタイプがすでに有効であっても、ワークロードをテナントの有効なインスタンス タイプに変更することを推奨する場合があります。これは、テナントのオファーファイルにインスタンスタイプが含まれていない場合に発生する場合があります。たとえば、t3a テンプレートファミリが専用テナントをサポートしていないとします。ただし、ユーザーが EC2 コンソールで専用テナントを持つ t3a インスタンスを作成したとします。その場合、Workload Optimization Manager はこれを不良構成と見なし、別のインスタンス タイプに変更することを推奨します。

これらの問題に対処するために、DT ワークロードに範囲を設定するグループを作成できます。たとえば、命名規則、タグ付け、または DT のワークロードを識別するためのその他の方法を使用することができます。その後、それらのインジケータに基づいたダイナミックグループを作成できます。これらのグループを使用すると、DI 環境で表示される相違に対応したポリシーとダッシュボードを作成できます。このアプローチを使用して、以下の問題に対処します。

■        使用可能なインスタンスタイプ

ワークロードのサイズを変更するために、Workload Optimization Manager は、そのワークロードを別のインスタンス タイプに変更するアクションを生成します。Workload Optimization Manager は、DT に対して有効なインスタンス タイプと共有テナントの相違は検出しないため、DT ワークロードを使用できないインスタンス タイプに対してスケーリングすることを推奨する場合があります。これを回避するには、DT グループのポリシーを作成し、使用できないインスタンスタイプを除外します。

■        コストの表示

Workload Optimization Manager チャートは、環境のコストを示します。範囲に専用テナントワークロードが含まれている場合、計算されたコストは不完全になります。たとえば、AWS はすべての前払いプランにある変換された RI（つまり、少なくとも 1 回交換された RI）の料金データを返さないため、Workload Optimization Manager は、そのような RI を RI 使用率またはコストの計算に含めません。

範囲を使用して、この影響を最小限に抑えます。DT と共有テナントのワークロード用に個別のダッシュボードを作成できます。

クラウド ワークロードのサイズ変更

クラウド上のワークロード（VM または RDS インスタンスなど）のサイズを変更するために、Workload Optimization Manager は、ワークロードの要件に最も適したクラウド階層を選択します。これにより、より小さい階層を選択してコストを削減したり、より大きな階層を選択してパフォーマンスを確保したりすることができます。サイズ変更を行うために、Workload Optimization Manager は、ワークロードを新しい階層に実際に移動させます。これには、新しい可用性ゾーンへの移行が含まれます。

サイズ変更の決定では、割引により可能となる節約を考慮することにも注意してください（25 ページ ）。ワークロードのサイズ変更アクションを検討する際に、Workload Optimization Manager は、全体的なコストが削減される料金割引の利点を持つインスタンス タイプにサイズを変更することを推奨します。

サイズ変更と見なされるため、Workload Optimization Manager は、ストレージとネットワークの要件も考慮します。ワークロードでのコンピューティング リソースの使用率が低い場合でも、使用可能な階層がワークロードのストレージまたはネットワークの要件をサポートできない場合でも、Workload Optimization Manager は変更を推奨しません。

注:

AWS 環境では、特定の状況下で VM のサイズ変更が失敗することがあります。VM の最初の再起動が失敗した場合、Workload Optimization Manager は 30 秒間待機し、再起動を試みます。Workload Optimization Managerは、最大 4 回の再起動を試みます。それでも再起動できない場合、Workload Optimization Manager は、VM が新しい階層で起動できないと判断し、古い階層で VM を再起動します。

パブリック クラウドでのスケーリング

クラウドでは、スケーリングアクションによって VM が異なるインスタンス タイプに変更されます。これには以下のことが含まれる場合があります。

■        異なる容量のインスタンスタイプへの VM の変更

■        割引料金が請求されるインスタンス タイプへの VM の変更

これらのアクションについて、アクションリストにはソースワークロードの現在のコストと、変更が加えられた場合の予測コストが表示されます。現在のコストを表示するために、Workload Optimization Manager はそのワークロードの実際のコストを使用します。ただし、予測コストを表示するには、特定の階層のコストについて、VM の平均使用率に基づいた見積もりを使用します。

割引料金が課金されるインスタンス タイプにスケーリングすると、コストがより低い場合に、より大きなインスタンスで VM が実行される可能性があることに注意してください。これは、VM がそのキャパシティを必要とせず、使用可能なその他のより小規模なインスタンス タイプがある場合でも発生する可能性があります。

Azure 環境では、VM のサイズ変更が特に問題を起こす可能性がある状況が存在します。特定のリージョンでは、基盤となるハードウェアの異なるセットを持つ異なったクラスタでインフラストラクチャを構成できます。さらに、特定のリージョンで使用可能な一部の階層は、異なるクラスタでのみ使用できます。Workload Optimization Manager が、あるクラスタの階層から別のクラスタの階層にサイズ変更することを推奨している場合は、サイズ変更のアクションが完了するまでに通常よりも時間がかかることがあります。

Azure 環境と AWS 環境の両方で、Workload Optimization Manager は、サイズ変更のアクションを生成する際に、特定のインスタンス要件に準拠します。詳細については、以下を参照してください。

■        Azure インスタンスの要件 （151 ページ）

■        AWS インスタンスの要件（150 ページ）

ディスカウント

Workload Optimization Manager の分析では、クラウドプロバイダーの割引を利用して、最適なワークロードの配置を計算し、クラウド上での導入に最適なコストを提示します。Workload Optimization Manager は以下の割引を検出します。

■        AWS 予約済みインスタンス（RI）と節約計画

■        Azure 予約

■        GCP の確約利用割引

ホームページのクラウド ビューには、割引データを表示する次のチャートが含まれます。

■        [潜在的な節約（Potential Savings）] チャートまたは [必要な投資（Necessary Investments）] チャート（339 ページ）

Workload Optimization Manager で、パフォーマンスの向上やコスト削減のために実行できるアクションが検出された場合は、[潜在的な節約（Potential Savings）] チャートまたは [必要な投資（Necessary Investments）] チャートでそれらの概要を確認できます。特定のアクションのリストを表示するには、チャートの下部にある [Show All] をクリックします。アクションの詳細については、「 Workload Optimization Manager」の「アクション」（44 ページ ）を参照してください。

■         「割引利用」（363ページ）

このチャートは、現在の割引インベントリ（360  ページ）をどの程度有効活用しているかを示します。期待する目標は、インベントリの使用率を最大化し、使用するクラウド プロバイダによって提供される割引価格を最大限に活用することです。

■        割引適用範囲（358ページ）

このチャートは、割引の対象となる VM の割合を示します。オンデマンド VM の割合が高い場合、カバレッジを拡大すると、月次コストを削減できます。カバレッジを拡大するには、VM 既存キャパシティを持つインスタンスタイプに拡張します。

■        割引インベントリ（360ページ）

このグラフには、環境で検出されたクラウド プロバイダの割引が一覧表示されます。

■        推奨される RI の購入（356 ページ）

Workload Optimization Manager は、割引料金の対象となる VM の割合を増やし、オンデマンド コストを削減できるように、割引料金でインスタンス タイプを購入することを推奨できます。このチャートは、保留中の購入を示しています。購入のリストをダウンロードし、クラウド プロバイダまたは担当者に送信して、購入プロセスを開始します。

注：

購入アクションは、関連する VM スケーリング アクションとともに実行する必要があります。現在のサイズで VM の割引を購入するには、VM 予約プランの購入 （299  ページ）を実行します。

現在、Workload Optimization Manager は、AWS および Azuru の購入アクションを推奨しています。GCP の購入アクションは、将来のリリースで導入される予定です。

政府用ワークロードのサポート

AWS GovCloud（US）と Azure Government は、米国政府のお客様とそのパートナー向けに、安全なクラウド ソリューションを設計し、規制およびコンプライアンス要件を満たすための専用リージョンを提供します。

Workload Optimization Manager は、必要なアカウントをターゲットとして追加すると、これらのリージョンのワークロードを検出します。必要なアカウントの詳細については、『ターゲット構成ガイド』の「AWS GovCloud ターゲット」および『ターゲット構成ガイド』の「Azure Government ターゲット」を参照してください。

検出されたワークロードには次のものがあります。

■        AWS VM（自動拡張グループを含む）、ボリューム、データベースサーバー、およびスポットインスタンス

■        Azure VM（可用性/拡張一式を含む）、ボリューム、および SQL データベース

Workload Optimization Manager は、パフォーマンスの問題に対処し、コストを最適化するために、VM、ボリューム、および SQL データベースに対するアクションを推奨します。

注:

Workload Optimization Manager は現在、Application Insights との Azure Government 統合をサポートしていません。Azure Government および Application Insights のアカウントをターゲットとして追加できますが、Application Insights は、政府以外のワークロードのパフォーマンス データのみを返します。

チャートの情報

次のチャートを使用して、政府のアカウントとワークロードに関する情報を表示します。

■        上位アカウント チャート

開始点として上位アカウント チャートを使用します。このグラフには以下の情報が表示されます。

–       サービス プリンシパルおよびターゲットとして追加した EA アカウントを介して検出された Azure Government サブスクリプション

–       ターゲットとして追加した AWS GovCloud マスターおよびメンバーアカウント。星印のアカウントは、マスター アカウントです。

■        必要な投資と潜在的な節約チャート

範囲を政府のアカウントまたはサブスクリプションに設定し、必要な投資と潜在的な節約チャートを参照して、政府のワークロードに対して保留中のアクションをすべて実行した場合に発生または節約できるコストを評価します。

■        割引インベントリチャート

ターゲットとして追加した政府アカウントにより、Workload Optimization Manager は、政府ワークロード用に購入した割引（25  ページ）を完全に把握できます。セカンダリ ターゲットを選択的に追加しても、Workload Optimization Manager は、すべての割引、およびそれらが全体的にどのように使用されているかを認識し続けます。これにより、政府のワークロードに対して Workload Optimization Manager が生成する割り当てと購入の推奨事項の精度が向上します。

 

ワークロードプラン

Optimize Cloud プランを実行して、既存の政府ワークロードのパフォーマンスと効率化の機会を特定するか、クラウド移行プランを実行して、政府の VM グループを別のクラウド プロバイダに移行できます。

オンプレミス クラスタの場合、クラウド移行プランを実行して、これらのクラスタ内の VM を政府アカウント/サブスクリプションおよびリージョンに安全に移行する方法を確認できます。

Azure App Service のサポート

Azure アカウントに追加すると、Workload Optimization Manager は、App Service 展開を構成するアプリ サービスとプランを検出します。サプライ チェーンでは、アプリ サービスはアプリ コンポーネント スペースとして表示され、アプリ サービスのコンピューティング リソースを定義する計画は仮想マシン スペースとして表示されます。

アプリサービスとプランを検出するために、Workload Optimization Manager には、他の Azure ワークロードを監視するための同じアクセス許可が必要です。

注：

App Service の分析と最適化は、将来のリリースで導入される予定です。

ターゲットの設定

ターゲットは、仮想環境で管理を実行するサービスです。Workload Optimization Manager は、ターゲットを使用してワークロードをモニタリングし、環境内でアクションを実行します。ターゲットを設定する場合は、サービスのアドレスと、クライアントとして接続するためのログイン情報を指定します。

各ターゲットについて、Workload Optimization Manager は、公開する管理プロトコル（REST API、SMI-S、XML、またはその他の管理トランスポート）経由でサービスと通信します。Workload Optimization Manager は、この通信を使用して、管理エンティティの検出、リソース使用率の監視、アクションの実行を行います。

ターゲットを構成するには、ターゲット タイプを選択し、ターゲットのアドレスを指定し、ターゲットにアクセスするログイン情報を入力します。次に、ワークロード最適化マネージャはターゲットを検出して検証し、ターゲットが管理するエンティティでサプライ チェーンを更新します。

注：

Workload Optimization Manager は、ターゲットのステータスを定期的にチェックします。ターゲットの検出または検証が失敗すると、[ターゲットの構成（Target Configuration）] ページでステータスが更新されます。状況によっては、ターゲットは再度検出可能、または有効になる可能性がありますが、ステータスは更新されません。この場合、ターゲットを選択し、[再検出（Rediscover）] または [検証（Validate）] をクリックします。

サポートされるターゲットおよび構成要件のリストについては、「ターゲット構成ガイド」の「ターゲット構成」を参照してください。

 

ターゲットの設定

1.      [Settings] ページに移動します。

クリックして [Settings] ページに移動します。このページから、Workload Optimization Manager のさまざまな設定タスクを実行できます。

2.      [Target Configuration] を選択します。

クリックして [Target Configuration] ページに移動します。

3.      ターゲットのリストを確認します。

このページには、Workload Optimization Manager に対して現在設定されているすべてのターゲットが一覧表示されます。これらのターゲットを調べたり編集したり、新しいターゲットを追加したりできます。

4.      ターゲットのリストをフィルタ処理します。

 

 

ターゲットの長いリストについては、次のことができます。

■       ターゲット タイプでターゲットをフィルタ処理します。

■       検索を使用して、テキスト文字列でターゲットをフィルタリングします（部分一致がサポートされています）。

■       [フィルタ（Filter）] を使用して、ステータスによってターゲットをフィルタリングします（たとえば、検証済みのターゲットのみを表示します）。フィルタを使用して、ターゲットを名前またはステータスで並べ替えることもできます。

5.      使用するターゲットを 1 つ以上選択します。

ターゲットを選択すると、次のことが可能になります。

■       再検出

ターゲットが管理するエンティティを完全に検出するように、Workload Optimization Manager に指示します。これにより、このターゲットに関連付けられているトポロジが再構築されます。

■       検証

ターゲットとの接続を検証するように、Workload Optimization Manager に指示します。たとえば、ターゲットに新しいユーザーアカウントを作成した場合は、そのアカウントを使用するためにターゲットの接続を編集してから、再検証を行うことができます。

■       削除（削除アイコン）

ターゲットを削除すると、Workload Optimization Manager によって、関連付けられているすべてのエンティティがサプライ チェーンから削除されます。

6.      エントリを展開して詳細を表示します。

 

 

エントリ内の任意の場所をクリックして、ターゲットの構成を編集することもできます。たとえば、誤ったユーザー名またはパスワードを入力した場合、それらのログイン情報を変更して、ターゲットを再度検証することができます。

 

7.      新しいターゲットを作成し、Workload Optimization Manager に追加します。

 

 

[新しいターゲット（New Target）] をクリックし、ターゲットのカテゴリとタイプを選択してから、そのターゲットのアドレスと資格情報を指定します。

ターゲットを追加すると、[ターゲット構成（ Target Configuration）] ページが更新され、現在の検証ステータスが表示されます。

■       検証中

検証が進行しています。

■       検証済み

検証が成功しました。Workload Optimization Manager は、ターゲットをモニタできるようになり、ターゲットが管理するエンティティの検出を開始します。

■       検証に失敗しました。

検証に失敗しました。ターゲットを展開すると、追加情報が表示されます。

 

 

エンティティのサプライ チェーン

アプリケーションリソース管理を実行するため、Workload Optimization Manager はサプライ チェーンにリンクされている購入者と販売者のマーケットとして、環境をモデル化します。このサプライ チェーンは、データセンターから環境内の物理階層、仮想階層を経てさらにクラウドへと至るリソースのフローを表します。これらの購入者と販売者との関係を管理することにより、Workload Optimization Manager は、データセンターからアプリケーションまで、リソースのクローズドループ管理を提供します。

サプライ チェーンとは

サプライ チェーンを見ることで、以下のことを確認できます。

■        各層に存在するエンティティの数

サプライチェーン内の各エントリには、特定のタイプのエンティティの数が示されます。

■        各層のエンティティの全体的な正常性

各エントリのリングは、データセンター内のその層に対する保留中のアクションの割合を示します。リングの色はアクションの重要度を示し、緑色は保留中のアクションがないエンティティの割合を示します。保留中のアクションの実際の数を取得するには、リングの上にポインタを置き詳細を表示します。

■        階層間のリソースのフロー

あるエントリから別のエントリへの矢印は、リソースのフローを示します。たとえば、仮想マシンのエントリには、ホストとストレージを指す矢印があります。仮想データセンターで VM が実行されている場合は、その VM にも別の矢印が表示されます。つまり VM は、ホスト、ストレージ、可能であれば VDC からリソースを消費します。

ホームページからのエンティティの一覧表示

[Supply Chain] には、環境内のエンティティの関係が表示されます。グローバル範囲の [ホーム ページ（Home Page）] を表示すると、選択したビューに応じて、サプライ チェーンによって表示がフィルタ処理されます。

■        [アプリケーション（APPLICATIONS）]：すべての ビジネス アプリケーション（101ページ）

■        [ON-PREM]：すべてのオンプレミスエンティティ

■        [CLOUD]：パブリッククラウド上のすべてのエンティティ

エンティティのリストを確認するには、[Supply Chain] 内のエンティティ層をクリックします。

範囲設定されたビューの操作

デフォルトでは、[ホームページ（Home Page）]に環境のグローバル ビューが表示されます。環境の詳細をドリルダウンするため、Workload Optimization Manager のセッションに範囲を設定できます。範囲設定されたビューには、そのスコープ内の特定のエンティティに関する詳細が表示されます。

範囲を設定したら、サプライチェーンを使用して関連する階層を拡大し、その階層のエンティティに関する詳細を表示できます。

現在の範囲が有用な場合は、名前付きのグループとして保存できます。名前付きグループを使用すると、保存したさまざまな範囲に簡単に戻ることができます。

ユーザーができること

■        Workload Optimization Manager のセッションの範囲設定（35ページ）

■        サプライ チェーンを使用した移動（43 ページ）

■        クラスタ ヘッドルームの表示（44 ページ）

 

Workload Optimization Manager のセッションの範囲設定

ホームページのデフォルトの範囲では、グローバル環境の概要が表示されます。グローバル環境を重視しない場合はどうすればよいでしょうか？あなたが環境内のワークロードのサブセットを担当していると仮定しましょう。次のようになります。

■        単一のホストクラスタで管理されるワークロード

■        単一データセンターのワークロード

■        Workload Optimization Manager で作成したワークロードのカスタムグループ

Workload Optimization Manager が検査対象の環境の一部を拡大するように、セッション範囲を簡単に設定できます。範囲を設定すると、その範囲のシステムの正常性をすばやく把握できます。ある特定の範囲が有用な場合は、後で戻ることができる名前付きのグループとして保存できます。

1.      [Search] ページに移動します。

上記のアイコンをクリックして、[Search Page] に移動します。ここで、必要な範囲を選択できます。

2.      検索するエンティティのタイプを選択します。

[Search Page] で、検索するエンティティのタイプを選択します。左側のエンティティタイプのリストを確認します。環境全体を検索するには、[All] を選択します。タイプ、グループまたはクラスタ別にエンティティに焦点を当てることもできます。エンティティタイプを選択すると、ページが更新され、そのタイプのすべてのエンティティが表示されます。

3.      [Search] を使用して、リストをフィルタ処理します。

たとえば、[ALL] が表示されており、[Development] を検索している場合は、名前に「Development」が含まれているすべてのクラスタ、グループおよびエンティティが表示されます。

4.      エントリを展開して詳細を表示します。

たとえば、グループまたはエンティティを展開すると、使用率の詳細と保留中のアクションが表示されます。

注：

パブリック クラウドのホストの場合、ホストおよびデータセンターのリソースの使用率と容量は、Workload Optimization Manager の計算に影響しません。パブリック クラウドのホストのエントリを展開すると、その詳細にはこれらのリソースの情報が含まれません。

 

 

5.      1 つ以上のエントリを選択し、ホームページのフォーカスを設定します。

リストを制限するエンティティのカテゴリを選択した場合は、セッション範囲に対して 1 つ以上のエンティティを選択できます。範囲に含めるエンティティを選択した後、[SCOPE TO SELECTION] をクリックして、それらのエンティティにセッション範囲を設定します。

[グループ（Groups）] または [クラスタ（Clusters）] を選択した場合、セッションの範囲を設定する単一エントリを選択できます。リスト内のエントリを選択すると、ホームページのフォーカスが設定されます。たとえば、[検索（Search）] リストで [クラスタ（Cluster）] を選択した場合は、[ホーム ページ（Home Page）]のフォーカスをそのクラスタに設定します。異なる範囲を設定するには、[ホーム ページ（Home Page）] のパンくずリストを使用します。または、[検索（Search）] に戻り、そこから異なる範囲を設定できます。

概要チャート

 

[Overview] チャートには、現在のセッション範囲での環境の全体的な動作の正常性が表示されます。[Overview] では、サービスパフォーマンスの正常性、ワークロード分散の全体的な効率、将来の予測、時間の経過に伴う傾向を把握できます。

このビューのチャートには、Workload Optimization Manager のセッションに対して設定した現在の範囲のデータが表示されます。グローバル スコープの場合、チャートは環境全体の平均、最小、およびピークの値をロールアップします。範囲を縮小すると（たとえば、範囲をクラスタに設定する）、チャートにはその範囲内のエンティティの値が表示されます。

このビューには、次のようなチャートが含まれています。

■        保留中のアクション

現在の範囲に対して保留中のすべてのアクションを表示します。

■        Health

この範囲内のエンティティの正常性をすばやく確認できます（リスクがあるエンティティの数、リスクがどの程度危機的状況であるか）。

■        Optimized Improvements

保留中のアクションを実行する前および実行した後の、環境内の使用率の比較。

■        Capacity and Usage

このチャートには、エンティティの現在の範囲で使用されているリソースが一覧表示され、現在使用されている容量の割合としての使用率が示されます。

■        Multiple Resources

エンティティの現在の範囲で使用されているさまざまなリソースの経時的な使用率を表示します。

■        Top Entities

上位の仮想マシンなど。これらのチャートには、現在の範囲の上位のコンシューマエンティティが一覧表示されます。

■        Risks Avoided

各アクションは、環境内の 1 つ以上の特定されたリスクまたは機会に対処します。このチャートは、実行されたアクションによって対処されたリスクの数を表示します。

■        Accepted Actions

このチャートは、実行または無視されたアクションの数と、手動または自動で実行されたかどうかを表示します。

次の操作を実行できます。

■        範囲設定：「Workload Optimization Manager セッションの範囲設定（35 ページ）」を参照してください。

■        新しいチャートの作成：「チャート ウィジェットの作成と編集（332 ページ）を参照してください

チャートフォーカスの設定

チャートは、表示するセッションに設定したフォーカスを反映するために更新されます。[Overview] チャートを表示しながら、さまざまな方法でフォーカスを設定できます。

■        サプライチェーンのフォーカスを設定する

サプライ チェーンの階層を選択して、ビュー フォーカスを設定します。「サプライ チェーンを使用した移動」（43 ページ ）を参照してください

■        範囲を設定する

[検索（Search）] を使用して、表示するセッションの範囲を設定します。「Workload Optimization Manage r セッションの範囲設定」（35  ページ）を参照してください。

チャートのタイムフレーム

 

最近から過去 1 年までのタイムフレームを設定し、そのタイムフレームをビューのチャートに設定することができます。[Time Slider] を使用して、その範囲内の特定の開始時刻と終了時刻を設定します。スライダの緑色の部分は、将来の予測を含めるように時間範囲を設定できることを示しています。時間範囲のこの部分について、チャートには、保留中のアクションの現在のセットを実行した後に表示される結果が表示されます。

ほとんどのチャートでは、時間範囲をハードコードするようにチャートを設定することもできます。この場合、チャートには、特定のビューに設定したスケールと範囲に関係なく、常に同じタイムスケールが表示されます。

Workload Optimization Manager は、履歴データをデータベースに保存することに注意してください。環境内で Workload Optimization Manager をより長時間実行する場合、時間範囲を設定してより多くの履歴を表示することができます。

詳細ビュー

[Details] ビューには、セッション範囲内のエンティティに関する詳細が表示されます。これらのチャートは、これらのエンティティによるリソースの使用率にフォーカスを当てるため、時間の経過とともにその範囲内のアクティビティを把握することができます。

 

次の操作を実行できます。

■        範囲設定：「Workload Optimization Manager セッションの範囲設定（35 ページ）」を参照してください。

■        新しいチャートの作成：「チャート ウィジェットの作成と編集（332 ページ）を参照してください

チャートフォーカスの設定

チャートは、表示するセッションに設定したフォーカスを反映するために更新されます。[Overview] チャートを表示しながら、さまざまな方法でフォーカスを設定できます。

■        サプライチェーンのフォーカスを設定する

サプライ チェーンの階層を選択して、ビュー フォーカスを設定します。「サプライ チェーンを使用した移動」（43 ページ ）を参照してください

■        範囲を設定する

[検索（Search）] を使用して、表示するセッションの範囲を設定します。「Workload Optimization Manage r セッションの範囲設定」（35  ページ）を参照してください。

チャートのタイムフレーム

最近から過去 1 年までのタイムフレームを設定し、そのタイムフレームをビューのチャートに設定することができます。[Time Slider] を使用して、その範囲内の特定の開始時刻と終了時刻を設定します。スライダの緑色の部分は、将来の予測を含めるように時間範囲を設定できることを示しています。時間範囲のこの部分について、チャートには、保留中のアクションの現在のセットを実行した後に表示される結果が表示されます。

ほとんどのチャートでは、時間範囲をハードコードするようにチャートを設定することもできます。この場合、チャートには、特定のビューに設定したスケールと範囲に関係なく、常に同じタイムスケールが表示されます。

Workload Optimization Manager は、履歴データをデータベースに保存することに注意してください。環境内で Workload Optimization Manager をより長時間実行する場合、時間範囲を設定してより多くの履歴を表示することができます。

範囲ポリシー

[Policy] ビューでは、現在の範囲内のエンティティに対して設定されている自動化ポリシーを確認できます。ポリシーごとに、有効になっているか、無効になっているかを確認できます。さらに、新しいポリシーを作成し、その範囲に適用することもできます。

ポリシーを編集するには、ポリシー名をクリックします。その後、ポリシー設定を変更したり、ポリシーを有効または無効にしたりすることができます。

現在のポリシー設定を確認するには、設定カテゴリを開きます。設定ごとに、どちらのポリシーが値を決定するかを確認できます（この範囲に適用されているデフォルトポリシーまたはこのカスタムポリシーのいずれか）。

新しいポリシーを作成すると、現在の範囲が自動的に含まれます。必要に応じて、他のグループをポリシー範囲に追加できます。同じ範囲に対して複数のポリシーを有効化できることに注意してください。2 つのポリシーが同じ設定に対して異なる値を適用する場合、最も控えめな値が有効になります。

詳細については、自動化ポリシー（ 74 ページ）を参照してください。

エンティティ配置の制約

単一のエンティティにドリルダウンすると、サプライチェーン内のエンティティの関係に関する詳細を確認できます。これにより、どのエンティティがこのエンティティにリソースを提供するかが表示されます。このエンティティに対するプロバイダーを検討する場合は、現在の各プロバイダーの名前と、現在のプロバイダーの使用率が過剰になった場合に Workload Optimization Manager が選択できる代替プロバイダーの数を確認できます。

エンティティに対する制約を確認することで、Workload Optimization Manager が推奨するアクションを理解することができます。アクションに疑問が感じられる場合は、影響を受けているエンティティに対する制約を確認する必要があります。一部のポリシーまたは制約が有効になっており、そのために Workload Optimization Manager がより明確なアクションを推奨しない場合があります。

配置制約を使った実験

リスト内の各プロバイダーまたはコンシューマに対して、現在の要素のサプライチェーン関係の制限に関する詳細情報が得られる [Constraints] ポップアップを開くことができます。

たとえば、[PROVIDERS] リストに、VM の [CURRENT PLACEMENT] がホスト A 上にあることが示され、[OTHER POTENTIAL PLACEMENT] については、Workload Optimization Manager が 4 つのホストから選択できると仮定します。[Constraints] をクリックすると、この VM 用として 4 つの潜在的なホストに制限している一連のホスト制約がポップアップに表示されます。

 

リスト情報には次のものが含まれます。

■        CONSTRAINT TYPE

ほとんどの制約は、クラスタ境界やネットワークなどの環境に固有の境界です。また、Workload Optimization Manager 配置ポリシー（セグメントとも呼ばれます）を作成した、検出済みの HA または DRS ルールなどの制約ルールの場合もあります。

■        [SCOPE NAME]

特定のルールまたは制約の場合の適用された範囲。

■        [SOURCE]

これが検出された制約の場合、ソースはこの制約を課すターゲットのタイプを示します。たとえば DRS ルールの場合、ソースは [vCenter] となります。

■        POTENTIAL PROVIDERS

特定の制約について、制約によって許可されるプロバイダーの数。潜在的なプロバイダーのリストを表示するには、[POTENTIAL PROVIDERS] の値をクリックします。

これらの制約がエンティティにどのように影響するかについて詳しく調べるには、[FIND MORE PLACEMENT OPTIONS] をクリックします。これにより、有効な制約の変更を試すために使用できるシミュレーションモードになります。たとえば、クラスタ境界が配置の可能性を制限しており、他のクラスタに現在の VM を配置するオプションを行いたいとします。この情報を保持して、[Policies] に移動し、[Merge Cluster] ポリシーを作成することができます。

 

 

 

このモードでは、さまざまな制約の組み合わせを有効または無効にすることができます。こうすることで、[POTENTIAL PROVIDERS] ラベルが更新され、エンティティに使用可能なプロバイダーの数が表示されます。プロバイダの結果のリストを表示するには、[潜在的プロバイダ（POTENTIAL PROVIDERS）] ラベルをクリックします。

エンティティのリスト

 

 

エンティティのリストでは、環境に関する詳細にすばやくドリルダウンして、リソースの消費または状態に関する詳細を確認できます。たとえば、現在アイドル状態の VM に割り当てられた容量の値を確認できます。

このリストは、Supply Chain Navigator で選択したフォーカスを反映するように常に更新されます。サプライ チェーンでエンティティタイプを選択すると、エンティティリストが更新され、現在の範囲のそのタイプのエンティティが表示されます。たとえば、[ホスト（Host）] を選択すると、現在の範囲内のホストのリストが表示されます。詳細については、「サプライ チェーンを使用した移動」（43 ページ ）を参照してください

サプライチェーンを使用した移動

Workload Optimization Manager のセッション範囲を設定した後、サプライチェーンを使用してメインビューのフォーカスを変更したり、現在の範囲内のさまざまなタイプのエンティティに関する詳細を表示したりできます。

範囲設定されたセッションでのドリルダウン

Workload Optimization Manager のセッションに範囲を設定すると、[ホーム ページ（Home Page）]に次のような環境情報が表示されます。

■        Overview

現在の範囲の環境についての概要を示すチャートとリスト。この概要は、範囲内のすべてのエンティティに対応しています。

■        [Details]：特定の範囲の環境をより詳細に確認できるチャート

■        Policies：現在の範囲内のエンティティに対して定義されているポリシー

■        Entity Lists：現在の範囲内のエンティティの詳細

■        Pending Actions：現在の範囲内の任意のエンティティに対して保留中のアクション

サプライ チェーンには、現在選択されているエンティティの階層が表示されます。範囲設定されたビューのフォーカスを変更するには、サプライ チェーン内で異なる階層を選択します。[Policies]、[Entities List]、および [Pending Actions] タブが更新され、選択した階層にフォーカスします。これらのタブには、現在の範囲内にあるそのタイプのすべてのエンティティ情報が表示されます。たとえば、[Host] 階層をクリックすると、これらのタブが更新され、現在の範囲内のホストに関する情報が表示されます。

特定のエンティティを拡大するには、[Entities List] でその名前をクリックします。これにより、その特定のエンティティに範囲が設定されます。前の範囲に戻るには、ブラウザの [戻る（Back）] ボタンを使用します。

 

クラスタヘッドルームの表示

クラスタヘッドルームには、クラスタがワークロードをホストするために必要な追加容量の値が表示されます。クラスタに範囲を設定すると、ホーム ページにはそのクラスタのヘッドルームを示すチャートと、クラスタのリソースが枯渇するまでの時間が表示されます。

クラスタヘッドルームを表示するには、次のようにします。

1.      [Search] ページに移動します。

2.      [Clusters] カテゴリを選択します。

3.      表示するクラスタを選択します。

4.      ホームページが表示されたら、下にスクロールして、ヘッドルームチャートを表示します。

サプライ チェーンナビゲータで [Host] 階層を選択していることを確認します。

クラスタ容量とヘッドルームを計算するために、Workload Optimization Manager は、現在の環境の条件を考慮する夜間計画を実行します。この計画では、経済スケジューリングエンジンを使用して、クラスタ向けの最適なワークロードの分散を特定します。より望ましいワークロードの分散が行われるようになるという前提で、特定のクラスタ内の他のホストに現在の VM を移動することができます。計画の結果として、クラスタがサポートできる VM の数が計算されます。

VM のヘッドルームを計算するために、計画ではクラスタへの VM の追加をシミュレートします。この計画では、特定の VM テンプレートに基づいて、これらの VM の特定の容量を想定しています。このため、ヘッドルームに与えられた VM の数は、その VM テンプレートに基づく近似値となります。

これらの計画で使用するテンプレートを指定するため、クラスタごとに夜間計画を設定できます。詳細については、 夜間計画の設定（ 318 ページ）を参照してください

Workload Optimization Manager のアクション

ターゲットを展開すると、Workload Optimization Manager は、そのアプリケーションリソース管理プロセスの一環として、マーケット分析の実行を開始します。この包括的な分析では、環境内の問題と、それらの問題を解決して回避するために実行できるアクションを特定します。Workload Optimization Manager は、その特定の分析に対する一連のアクションを生成し、調査できるように [Pending Actions] チャートにそのアクションを表示します。

 

Workload Optimization Manager は、次のアクションを生成します。

 

 

エンティティタイプ別のアクション

Workload Optimization Manager は、エンティティタイプがリソースをどのように使用または提供するか、および各エンティティタイプがサポートするものに基づいてアクションを生成します。

次の表は、各エンティティタイプがサポートするアクションを示しています。

アプリケーション エンティティ タイプ

 

 

コンテナ プラットフォーム エンティティ タイプ

 

クラウド インフラストラクチャ エンティティ タイプ

オンプレミス インフラストラクチャ エンティティ タイプ

アクション タイプ

Workload Optimization Manager は、次の一般的なタイプのアクションを実行します。

■        配置：コンシューマを特定のプロバイダーに配置します（VM をホストに配置）。

■        スケーリング：収益性に基づいてリソースの割り当て量をサイズ変更します。

–       サイズの拡大：必要な投資として示されます。

–       サイズの縮小：コスト削減として示されます。

■        割引の最適化：VM を割引料金で課金されるインスタンス タイプにスケーリングすることにより、 割引（25 ページ）の適用範囲を拡大し、コストを削減します。

■        設定：不良設定を修正します。

■        開始/購入：新しいインスタンスを起動して、環境にキャパシティを追加します。必要な投資として示されます。クラウド環境の場合は、 割引（25 ページ）を購入してコストを削減します。

■        停止：インスタンスを一時停止して、リソースがさらに効率的に使用されるようにします。コスト削減として示されます。

■        削除：ストレージを削除します（ディスク アレイ上のデータストアや付属しないボリュームなど）

配置

配置アクションは、コンシューマの最適なプロバイダーを決定します。これには、新しいエンティティの初期配置と、コンシューマを変更して異なるプロバイダーを使用する移動アクションが含まれます。たとえば、VM を移動すると、その VM が異なるホストに割り当てられます。VM のストレージを移動することは、VM が異なるデータストアを使用することを意味します。

配置の制約

配置の決定を行う際に、Workload Optimization Manager は、特定のコンシューマのプロバイダーのセットを制限するために配置の制約をチェックします。これは、クラスタ境界や DRS ルールなどの自動配置の制約を考慮します。また、特定のビジネス要件へのコンプライアンスを確保するために、配置ポリシーで定義されているユーザー設定の制約も考慮します。

計画を実行して、制約をオフにした場合、または特定の配置ポリシーを無効または有効にした場合に何が起こるかを確認できます。

実効 CPU 容量

CPU のプロセッサ速度は、必ずしも CPU 容量の有効な指標になるとは限りません。たとえば、プロセッサのアーキテクチャによっては、低速の CPU に大きな実効容量を持たせることができます。多くの場合、マシンのモデルが新しいほうが、コア数が少なかったり、クロック速度が低いことがありますが、その場合も、大きな実効容量を備えています。

VM をオンプレミス環境のホストに配置する場合、Workload Optimization Manager はホストの有効な CPU 容量を検出します。これによって配置計算の精度が向上し、より新しくて効率的なホストが、より大きいかより高速なプロセッサを持つ低効率ホストに比べて実効容量が向上することが示されます。

実効容量を検出するために、Workload Optimization Manager は spec.org からのベンチマーク データを使用します。このベンチマークデータは、Workload Optimization Manager が配置計算を行うために使用する実効容量設定に対応付けされます。

これらのベンチマークデータのカタログを表示し、ホストテンプレートを編集する際に一覧表示されているプロセッサから選択できます。詳細については、「カタログからの CPU の選択（380  ページ）」を参照してください。

 

共有なしの移行アクション

ストレージの移動と VM の移動の両方を有効にしている場合は、Workload Optimization Manager がシェアードナッシング移行を実行できます。これにより、VM と保存された VM ファイルが同時に移動します。詳細については、「共有なしの移行」（205 ページ ）を参照してください。

Cross-vCenter vMotion

VMware vSphere 6.0 には、異なる vCenter サーバ インスタンス間の仮想マシンの移行を可能にする機能が導入されています。Workload Optimization Manager は、マージ配置ポリシーを使用してこの機能をサポートします （「配置ポリシーの 作成」（70  ページ）を参照してください）。配置を計算する際には、クロス vCenter の位置を考慮し、異なる vCenter サーバへの移動を推奨または実行することができます。

パブリック クラウド上での移動

パブリック クラウドでは、物理ホストにワークロードを配置しません。Workload Optimization Manager のサプライ チェーンでは、ホストノードは可用性ゾーンを表します。Workload Optimization Manager では、ワークロードを異なるゾーンに移動することを推奨できます。このような移動によってクラウドのコストを削減できる場合があります。これらの移動は、特定のゾーンでのインスタンス タイプや割引の可用性といった制約を認識します（25  ページ）。

AWS 環境では、VM は Elastic Block Stores（EBS）またはインスタンス ストレージを使用できます。VM のルート ストレージが EBS の場合、Workload Optimization Manager は VM の移動を推奨できます。ただし、インスタンス ストレージは一時的なものであり、移動によって保存されたデータが失われる場合があるため、Workload Optimization Manager では、ルート ストレージとしてインスタンス ストレージを持つ VM を移動することは推奨されません。

VM が課金ファミリ内で実行されている場合は、Workload Optimization Manager はその VM をその課金ファミリ内の他のリージョンに移動することのみ推奨します。

RI を使用する AWS 環境では、Workload Optimization Manager は、RI の購入に対して指定した可用性ゾーンを認識します。移動およびサイズ変更アクションの場合、Workload Optimization Manager は、特定のゾーン内のこれらの RI を優先します。特定のゾーンでは、他のすべては同じなので、予約済み容量を持つゾーン RI と容量を予約していない RI がある場合、Workload Optimization Manager は最初にゾーン RI を使用します。

スケーリング

スケーリングアクションは環境内の容量を更新します。垂直スケーリングでは、Workload Optimization Manager が既存のエンティティのリソース容量を増減します。水平スケーリングの場合は、新しいプロバイダーをプロビジョニングします。たとえば、ホストをプロビジョニングすると、VM の実行に使用できるコンピューティング容量が増加します。VM をプロビジョニングすると、アプリケーションを実行するための容量が増加します。

Workload Optimization Manager は、次のプロビジョニングを行うことができます。

■        コンテナ

■        VM

■        ホスト

■        ストレージ

■        ストレージコントローラ（計画シナリオの場合のみ）

■        ディスクアレイ

特定の状況下では、Workload Optimization Manager は仮想データセンターをプロビジョニングすることも推奨できます。

ストレージのサイズ変更アクション

ストレージのサイズ変更アクションは、ストレージエンティティと特定のハイパーバイザによって管理されるとエンティティの両方に影響を与えます。ただし、すべてのハイパーバイザがストレージ容量の変更を認識しているわけではありません。ストレージのサイズ変更を実行した後、Workload Optimization Manager ではサイズ変更アクションが正常に実行されたことが示され、ハイパーバイザでは実行したストレージ容量の変更が表示されないことがあります。この場合は、Workload Optimization Manager がストレージの変更を検出できるように、ハイパーバイザ ターゲットを更新する必要があります。

この状況を回避するため、ストレージのサイズ変更アクションにおけるアクションモードを [Manual] または [Recommend] に設定できます。このようにして、自分でサイズ変更を実行し、ハイパーバイザを手動で更新することができます。

 

パブリック クラウドでのスケーリング

クラウドでは、スケーリングアクションによって VM が異なるインスタンス タイプに変更されます。これには以下のことが含まれる場合があります。

■        異なる容量のインスタンスタイプへの VM の変更

■        割引料金が請求されるインスタンス タイプへの VM の変更

これらのアクションについて、アクションリストにはソースワークロードの現在のコストと、変更が加えられた場合の予測コストが表示されます。現在のコストを表示するために、Workload Optimization Manager はそのワークロードの実際のコストを使用します。ただし、予測コストを表示するには、特定の階層のコストについて、VM の平均使用率に基づいた見積もりを使用します。

割引料金が課金されるインスタンス タイプにスケーリングすると、コストがより低い場合に、より大きなインスタンスで VM が実行される可能性があることに注意してください。これは、VM がそのキャパシティを必要とせず、使用可能なその他のより小規模なインスタンス タイプがある場合でも発生する可能性があります。

Azure 環境では、VM のサイズ変更が特に問題を起こす可能性がある状況が存在します。特定のリージョンでは、基盤となるハードウェアの異なるセットを持つ異なったクラスタでインフラストラクチャを構成できます。さらに、特定のリージョンで使用可能な一部の階層は、異なるクラスタでのみ使用できます。Workload Optimization Manager が、あるクラスタの階層から別のクラスタの階層にサイズ変更することを推奨している場合は、サイズ変更のアクションが完了するまでに通常よりも時間がかかることがあります。

Azure 環境と AWS 環境の両方で、Workload Optimization Manager は、サイズ変更のアクションを生成する際に、特定のインスタンス要件に準拠します。詳細については、以下を参照してください。

■        Azure インスタンスの要件 （151 ページ）

■        AWS インスタンスの要件（150 ページ）

割引の最適化

クラウド コストを削減するために、Workload Optimization Manager は、割引料金が課されるインスタンス タイプに VM をスケーリングすることを推奨できます。

■         「割引利用」（363ページ）

このチャートは、現在の割引インベントリ（360  ページ）をどの程度有効活用しているかを示します。期待する目標は、インベントリの使用率を最大化し、使用するクラウド プロバイダによって提供される割引価格を最大限に活用することです。

■        割引適用範囲（358ページ）

このチャートは、割引の対象となる VM の割合を示します。オンデマンド VM の割合が高い場合、カバレッジを拡大すると、月次コストを削減できます。カバレッジを拡大するには、VM 既存キャパシティを持つインスタンスタイプに拡張します。

■        割引インベントリ（360ページ）

このグラフには、環境で検出されたクラウド プロバイダの割引が一覧表示されます。

Workload Optimization Manager ユーザーは、割引最適化アクションを実行しません。これらは、クラウド プロバイダによって実行されるキャパシティの再割り当てを反映します。

設定

これらは再構成アクションとサイズ変更アクションです。再構成アクションは、必要なネットワークアクセスを追加するか、ストレージを再構成します。サイズ変更アクションによってエンティティのリソース容量が増減されます。これには、VM 上 の VCPU または VMem の増減、データストアの容量の増減、ディスク アレイ内のボリュームの増減などが含まれます。

Workload Optimization Manager は、次の項目を再設定できます。

■        VM

■        コンテナ

■        ストレージ

■        ディスクアレイ

■        仮想データセンター

開始および購入

Workload Optimization Manager は、一時停止中のエンティティを起動し、環境にキャパシティを追加することを推奨できます。また、現在のワークロードのコストを削減するためにクラウド プロバイダ割引（25  ページ）の購入を推奨することもできます。

停止

停止アクションは、環境からエンティティを削除せずにエンティティを一時停止します。一時停止された容量は引き続きオンラインに戻すために利用できますが、現在は利用できません。一時停止されたリソースは終了の候補になります。

Workload Optimization Manager は、次のものを一時停止できます。

■        アプリケーション コンポーネント

■        コンテナポッド

■        ディスクアレイ

■        ホスト

■        ストレージ（オンプレミス）

■        仮想データセンター

■        VM

Delete

削除アクションはストレージに影響します。たとえば、Workload Optimization Manager は、無駄なファイルを削除して、ストレージのスペースを空ける、またはクラウド環境内の未使用のストレージを削除して、ストレージコストを削減するよう推奨する場合があります。

Azure 環境で無駄になっているストレージ

Azure 環境では、Workload Optimization Manager は管理対象外ストレージを未接続ボリュームとして識別できます。また、未使用のこのストレージを削除した後に、その支払いを行う必要がなくなった場合に予測される節減を示せるようにすることを推奨できます。Workload Optimization Manager が示す節減は、そのストレージの全体的なコストに基づいた推定値です。これは Azure が、特定のボリュームに使用されているストレージ量について、ボリュームごとのコストまたはコストの特定の値を提供しないためです。予測される節減量が異常に多い場合は、アクションがどのストレージを削除するかを特定して課金を確認し、精度を上げてコストを計算する必要があります。

アクションカテゴリ

Workload Optimization Manager は、さまざまなカテゴリ別に [Actions List] 内のエントリをグループ化します。これらのカテゴリは、問題の重大度を厳密に定義するものではありませんが、問題の性質を示しています。

パフォーマンス アシュアランス

最終的には、環境内のワークロードを管理する理由は、パフォーマンスを保証し、QoS の目標を達成することです。Workload Optimization Manager は、QoS をリスクに直接さらす条件を検出すると、[Performance] カテゴリ内の関連するアクションを推奨します。これらの重要な条件を考慮できるので、推奨されるアクションは可能な限り迅速に実行する必要があります。

 

 

効率性の改善

効率の良いリソースの使用は、望ましい状態で実行するための重要な要素です。効率的に実行することで、投資を最大限に活用し、コストを削減できます。Workload Optimization Manager は、使用率の低いリソースを検出すると、操作を統合するためのアクションを推奨します。たとえば、特定の VM を異なるホストに移動することを推奨できます。これにより、物理マシンを解放してシャットダウンを回避できます。

予防

Workload Optimization Manager は、状況を常に監視して、環境が望ましい状態に維持されるように動作します。環境がこの状態ではなくなるリスクを生じさせる問題を検知した場合は、[Prevention] カテゴリ内の関連のアクションを推奨します。これらの問題に注意をはらい、関連のアクションを実行する必要があります。そのようにしないと、環境が望ましい状態ではなくなり、一部のサービスの QoS がリスクにさらされる可能性があります。

コンプライアンス

仮想環境には、リソースのワークロードの配置や可用性を制限するポリシーを含めることができます。環境設定がこれらの定義済みポリシーに違反する可能性があります。また、エンティティが何らかの方法で誤って設定されている可能性もあります。たとえば、VM は、現在のホストクラスタで使用できないネットワークにアクセスするように設定されている場合があります。このような場合、Workload Optimization Manager は違反を特定し、エンティティをコンプライアンスに戻すアクションを推奨します。

 

 

 

アクションモード

アクションモードは、生成されたアクションに対して自動化の程度を指定します。たとえば、一部の環境では、それが中断を引き起こすアクションであるため、VM のサイズを引き下げるサイズ変更を自動化しない場合があります。ポリシーでアクションモードを使用して、そのビジネスルールを設定します。

Workload Optimization Manager は、次のアクションモードをサポートしています。

■        [Recommend]：指定したハイパーバイザ経由か、またはその他の手段でユーザーが実行できるようにアクションを推奨します。

■        Manual：Workload Optimization Manager のユーザーインターフェイスを通じて実行するアクションを推奨し、オプションを提供します。

■        Automated：アクションを自動的に実行します。

同じエンティティでの自動サイズ変更または移動アクションの場合、Workload Optimization Manager は、すべてのアクションを一度に実行しようとすることに関連するエラーを回避するために、各アクション間に 5 分間待機します。実行待機中のアクションはすべてキューに残ります。たとえば、VM に vCPU と vMem の両方のサイズ変更アクションがある場合、Workload Optimization Manager は最初に vCPU のサイズを変更することもあり得ます。このサイズ変更が完了すると、vMem のサイズを変更するまで 5 分間待機します。

[Pending Actions] チャートは、[Recommend] または [Manual] モードでのみアクションをカウントします。

自動化アクションは、次のチャートに表示されます。

■        ホームページと [オンプレミスエグゼクティブ ダッシュボード（On-prem Executive Dashboard）] 上のすべてのアクションチャート

■        ホームページ上の承認済みアクションチャート

アクション モードの設定

特定のエンティティに対してアクションモードを設定するため、Workload Optimization Manager の自動化ポリシーを編集できます。これは、デフォルトのアクションモードを指定する方法、または特定のグループまたはクラスタに特別なアクションモードを設定する方法です。詳細については、自動化ポリシー（ 74 ページ）を参照してください。

アクション モードのオーバーライド

一部の状況下では、Workload Optimization Manager は、アクションのアクションモードを[手動（Manual）] から [推奨（Recommend）] に変更します。

Workload Optimization Manager は、基盤となるインフラストラクチャがサポートできないアクションの実行に対する保護手段としてこの変更を行います。たとえば、VM移動アクションが手動に設定されているとします。次に、Workload Optimization Manager 分析で、すでに完全に使用されているホストに VM を移動したいとします。この場合、別のアクションにより、ワークロードを別のホストに移動して、この新しい VM 用のスペースを確保することになります。ただし、移動が手動であるため、ホストの空きがまだ適切に作成されていない可能性があります。この場合、Workload Optimization Manager は、ワークロードをそのホストに移動するアクションを [手動（Manual）] から [推奨（Recommend）] に変更します。

AWS の一部のインスタンスでは、これらのインスタンス タイプへ移動する前に、特定の方法でワークロードを設定する必要があります。Workload Optimization Manager が、これらのインスタンスの 1 つへの移動がまだ適切に構成されていないワークロードを移動することを推奨する場合は、アクション モードを [手動（Manual）] から [推奨（Recommend）] に変更し、その理由を表示します。

生成されたアクションの使用

Workload Optimization Manager の使用を開始すると、製品が生成するすべてのアクションが保留中として表示されます。[Pending Actions] チャートでそれらを表示し、実行するか自動化するかを決定できます。また、これらを無効にすることもできます。

Workload Optimization Manager は、指示された場合を除き、自動的にアクションを実行することはありません。製品に付属しているデフォルトポリシーを調べると、これらのポリシーではいずれのアクションでも自動化されないことが分かります。Workload Optimization Manager により、すべての自動化の決定を完全に制御できます。

保留中のアクションを最初に確認したときは、それらの多くを実行して、パフォーマンスと使用率の迅速な改善を確認します。時間の経過とともに生産性の目標を達成し、変化するビジネスニーズに対応するために、アクション処理プロセスを開発し微調整します。このプロセスを通じて、次の重要な決定を行える可能性があります。

■        ビジネスルールに違反するアクションなど、実行しないアクションの無効化

Workload Optimization Manager は、分析を実行する際に無効なアクションの推奨を考慮しません。

■        ミッションクリティカルなリソースの QoS を保証するアクションなど、特定のアクションの自動的な実行の許可

自動化によってタスクが簡素化されるとともに、ワークロードが最適な実行のために十分なリソースを確保し続けることが保証されます。そのため、可能な限り多くのアクションを自動化するという目標を設定することが重要です。その際は、どのアクションが自動化しても安全か、どのエンティティに対して行うかを評価する必要があります。

■        引き続き、Workload Optimization Manager から特定のアクションに関する通知が届くようにし、個別にそれらを実行できるようにします。

たとえば、特定のアクションが特定の個人の承認を必要とする場合があります。この場合、Workload Optimization Manager がレビュー用にこれらのアクションを通知し、承認を受け取るアクションだけを実行するようにします。

これらは、[Pending Actions] チャートで検索するアクションです。これらを無効化するか自動化する場合、またはアクションが不要になるというように次のマーケット分析で環境が変化する場合、これらは実行後に表示されなくなります。

 

次の操作を実行できます。

■        保留中のアクションの表示および実行：「 保留中のアクション（60 ページ）」を参照してください。

■        保留中のアクション チャートの異なる表示ビューを確認する：「 保留中のアクション チャート（335 ページ）」を参照してください。

■        ホーム ページで保留中のアクションに範囲を設定：「 保留中のアクション範囲」（62 ページ）を参照してください。

■        生成および実行されたアクションの実行履歴を確認する：「 アクション チャート（337 ページ）」を参照してください。

■        製品が生成するアクションを推進するデフォルトポリシーを確認します。

■        さまざまな条件をシミュレートするための計画を作成および実行し、そのような状況においてアクションが正常に動作することを確認する：「 計画管理（263 ページ）」を参照してください。

 

保留中のアクション数

Workload Optimization Manager は、生成されるすべての非自動化アクションを保留中として扱い、それらを保留中のアクションチャートに表示します。

 

 

Workload Optimization Manager から最良の結果を得るには、これらのアクションを速やかに実行し、可能な限り多くのアクションを自動化することを検討してください。これらのアクションは、ユーザーインターフェイスまたは外部の Workload Optimization Manager から実行できます。これらのアクションを自動化するには、「自動化ポリシー」（79  ページ）を作成するか、「デフォルト ポリシー 」（75 ページ ）に記載されているアクション モードを [自動化（Automatic）] に変更します。

Workload Optimization Manager は、一度に最大 5 つのアクションを実行でき、後で実行するために新着アクションをキューに入れます。

デフォルトの保留中のアクションチャート

ユーザーインターフェイスにログインするたびに、Workload Optimization Manager は、すぐにホームページの [ハイブリッド（HYBRID）] ビューに保留中のアクションチャートを表示します。これらのチャートには、注意が必要なアクションの概要と、保留中のアクションリスト（ 63 ページ）へのエントリポイントが表示されます。

注：

また、これらのチャートを任意のダッシュボード（325 ページ ）に追加することもできます。

 

 

 

デフォルトでは、テキスト チャートとリスト チャートがグローバル環境に範囲が設定されたホーム ページに表示されます。

チャートの右上隅にあるアイコンをクリックすると、チャートのタイプを変更できます。使用可能なチャートのタイプの詳細については、保留中のアクション チャート（ 335 ページ）を参照してください。

保留中のアクション - テキストチャート

テキスト チャートには、保留中のアクションに関連付けられた推定コストまたは推定節減、および各アクションタイプ（ 53 ページ）のアクションの数が表示されます。

保留中のアクション - リストチャート

リストチャートには、保留中のアクションの部分的なリストが、関連する問題の重大度順に表示されます。

 

 

保留中のアクションの範囲

アプリケーションリソース管理を実行するために、Workload Optimization Manager は、問題発生前に回避するアクションを特定します。このアクションは手動で実行するか、コマンドでアクションを実行するように Workload Optimization Manager に指示するか、発生時に自動的にアクションを実行するように Workload Optimization Manager に指示できます。

ホームページで保留中のアクションに範囲設定するには、いくつかの方法があります。

保留中のアクションをすべて表示するには、保留中のアクションチャートの[すべてのアクションを表示（Show all Actions）] をクリックします。

 

保留中のアクションの範囲を絞り込むには、次のいずれかをクリックします。

■        サプライチェーン内のエンティティタイプ。

Workload Optimization Manager は、エンティティタイプがリソースをどのように使用または提供するか、および各エンティティタイプがサポートするものに基づいてアクションを生成します。各エンティティ タイプがサポートするアクションの詳細については、「エンティティ タイプ別のアクション」（46 ページ ）を参照してください。

リスクが存在するエンティティタイプ（クリティカル、メジャー、またはマイナー）のみに保留中のアクションがあります。エンティティタイプにカーソルを合わせると、リスクの内訳が表示されます。

■        テキストチャートのアクションタイプ

■        リストチャートのエンティティ名

注:

[オンプレミス（ON-PREM）] または [クラウド（CLOUD）] ビューを使用している場合は、テキストチャートがデフォルト表示されます。エンティティ名を表示するには、リストチャートに切り替えます。

[すべてのアクションを表示（Show all Actions）] またはアクション タイプをクリックすると、保留中のアクション リスト（ 63 ページ）がすぐに表示されます。

エンティティタイプまたはエンティティ名をクリックした場合は、[Overview] ページが最初に表示されます。このページで、[Actions] タブをクリックして、[Pending Actions List] を表示します。

[Pending Actions List] には、範囲をさらに絞り込むための追加機能が含まれています。意味のあるキーワードやフィルタを使用すると、特定のアクションを検索できます。詳細については、「保留中のアクション リスト」（63 ページ ）を参照してください。

保留中のアクションリスト

[保留中のアクション リスト（Pending Actions List）] には、特定の範囲に対して Workload Optimization Manager が現在推奨するすべてのアクションが含まれています（詳細については、「保留中のアクションの範囲」（62  ページ）を参照してください）。

実行するアクションを選択でき、またアクション項目を展開して詳細を表示することもできます。

 

A.   アクションリスト

アクションリストの各行には次の項目が表示されます。

■        Workload Optimization Manager が推奨する特定のアクション。

■        該当する場合は、アクションを正常に実行するために必要な投資量の見積もり、またはアクションの実行後の節減量

■        「 アクション カテゴリ」（56 ページ）を参照してください。

デフォルトでは、アクションは関連する問題の重大度別に表示されます。これは、チェックボックスの前の細い色付きの線で示されます。他のカテゴリ別に順序を変更するには、フィルタ機能を使用します。

実行する 1 つまたは複数のアクションを選択し、[選択値を適用（Apply Selected）] をクリックします。

次のチェックボックスや記号とともにアクションが表示される場合：

■        グレー表示されたチェックボックス（   ）

アクションは推奨のみです。

Possible reasons:

–       アクション モードが[推奨（Recommend）]になっているとき、またはエンティティの基盤となるテクノロジーが自動化をサポートしていない場合に生じます。これは、Workload Optimization Manager の外部でアクションを実行する必要があることを意味します。

[アクションの詳細（Action Details）] ページに、アクションがポリシーによってブロックされていることが示されています。

–       前提条件のアクションのため、他の方法では実行可能なアクションは現在実行できません。

たとえば、ホスト A を一時停止するには、ホストの VM_01 を最初にホスト B に移動する必要があります。ただし、ホスト B には 1 つの VM の容量しかなく、現在 VM_02 をホストしています。この場合、ホスト A の一時停止は、VM_02 が別のホストに移動し、VM_01 がホスト B に移動するという 2 つの前提条件アクションによってブロックされます。

メイン アクション（例ではホスト A の一時停止）の [アクションの詳細（ Action Details）] ページには、「ターゲットまたは接続先で最初に実行する必要のあるアクションによってブロックされました。」と示されています。

前提条件のアクションがすべて実行されると、メインのアクションが実行可能になります。

■        グレー表示のチェックボックスと禁止記号（）

アクションを実行する前に、Workload Optimization Manager の外部でいくつかの前提条件の手順を実行する必要があります。チェックボックスにカーソルを合わせると、前提条件の手順が表示されます。

 

 

B.    アクションの詳細

矢印アイコンをクリックしてエントリを展開し、アクションの詳細を表示します。

アクションの詳細には次のものがあります。

■        [Scale Virtual Machine...] など、推奨されるアクションの説明。

注：

アクション項目によって、影響を受けるエンティティの名前が示されます。これらのエンティティ名をクリックしてドリルダウンすると、その特定のエンティティに対してホームページの範囲を設定できます。アクションの詳細でエンティティにドリルダウンした後に戻るには、ブラウザの [Back] ボタンを使用します。

■        説明のすぐ下にある、推奨されるアクションの要件、リスク、機会、または理由の概要。

■        アクションの実行による影響。

詳細については、「アクションの詳細（67  ページ）」を参照してください。

C.   検索

保留中のアクションの長いリストの場合は、検索を使用して結果を絞り込みます。

 

D.   フィルタとソート

[Filter] をクリックすると、次の操作を実行できます。

■        「 アクション タイプ」（53 ページ）、「アクション モード」（58 ページ）、「アクション  カテゴリ」（56 ページ）、アクションの前提条件またはこれらの項目の組み合わせ別にリストをフィルタ処理します。

■        重大度、アクションターゲットの名前、リスクカテゴリ、または削減量に基づいて昇順または降順でアクションをソートします。

Workload Optimization Manager は、アクションを実行することによって影響が及ぶエンティティに反映される改善量に基いて、アクションの重大度を決定します。アクションの重大度は次のとおりです。

–       マイナー：コストまたはワークロードの分散に影響するが、ユーザが経験する QoS には影響しない問題

–       メジャー：QoS に影響を与える可能性があり、対処を要する問題

–       クリティカル：環境が提供できる QoS に影響し、対処が強く求められる問題

次に例を示します。

■        Workload Optimization Manager のユーザーインターフェイスを使用して実行できるアクションのみを表示するには、アクションモードでリストをフィルタ処理し、[Manually executable] を選択します。

■        手動で実行可能なサイズ変更アクションのみを表示して効率を上げるには、フィルタ処理を次のように設定します。

E.    ダウンロード

保留中のアクションリストを CSV ファイルとしてダウンロードします。

 

 

 

アクションの詳細

保留中のアクションリストの各アクションには説明と詳細情報が含まれており、Workload Optimization Manager がそのアクションを推奨する理由と、実行した場合に得られるメリットを確認することができます。

一見すると、個別のアクションは単純そうなものもあり、そういったアクションは無意識に無視しがちです。1 つのアクションを実行すると、他のワークロードに好影響を与え、望ましい状態に近づけるのに役立つ場合があることを忘れないようにすることが重要です。

例

上記の画像では、アクション詳細は、仮想マシンを別のインスタンス タイプにスケーリングすることで、有意義な方法で割引適用範囲に影響することを示しています。割引適用範囲を 0% から 100% に増やすことによって、予測される 1 時間ごとのオンデマンドのコストが 0 ドルに削減され、1 ヵ月あたり $502 の削減が見込まれます。

使用率チャート

Workload Optimization Manager は、パーセンタイル計算を使用してリソース使用率をより正確に測定し、全体的な使用率を改善し、クラウドワークロードのコストを削減するアクションを推進します。エンティティまたは保留中のアクションの詳細を調べると、特定の観察期間のリソース使用率のパーセンタイルと、アクションの実行後に予測されるパーセンタイルを強調表示するチャートが表示されます。

 

チャートには、参照用に日次平均使用率もプロットされています。エンティティに対して以前にスケーリングアクションを実行したことがある場合は、日時平均使用率が改善されたことを確認できます。まとめると、これらのチャートにより、Workload Optimization Manager の推奨事項を促進する使用率の傾向を簡単に認識することができます。

注：

■        ポリシーに制約を設定すると、パーセンタイル計算を絞り込むことができます。

■        アクションを実行した後、結果の改善がチャートに反映されるまでに時間がかかる場合があります。

使用率チャートを持つエンティティ

使用率チャートは、次のエンティティタイプのアクションを表示します。

アクションのヒントとベストプラクティス

Workload Optimization Manager のアプリケーションリソース管理の最善の結果を得るには、できるだけ多くのアクションを[自動（Automated）] に設定する必要があります。変更を承認する場合は、アクションを [手動（Manual）] に設定します。

一見すると、個別のアクションは単純そうなため、そういったアクションは無意識に無視しがちです。1 つのアクションを実行すると、他のワークロードに好影響を与え、望ましい状態に近づけるのに役立つ場合があることを忘れないようにすることが重要です。ただし、推奨処置が受け入れられない場合（既存のビジネスルールに違反している場合など）は、優先アクションを使用してポリシーを設定できます。

アクションによって中断が発生する場合がありますが、これは絶対に避けたいことです。たとえば、重要な時間帯に Workload Optimization Manager がミッション クリティカルなリソースに対してサイズ変更のアクションを実行し、そのリソースを再起動する必要がある場合があります。そのような中断を予測し、状況に応じて計画を立てることが重要です。たとえば、すべての重要なリソースに対してグループを作成し、自動化ポリシーのグループの範囲を指定し、アクションモードを [自動化（Automatic）] に設定してから、スケジュールをオフピークの時間帯または週末に設定することができます。スケジュールの設定の詳細については、ポリシースケジュールの設定（ 86 ページ）を参照してください。

サイズ変更アクション

ホットアドが有効に設定されている VM が自動的にサイズ変更されるようにします。

調整スケーリングを使用すると、サイズ変更量が許容範囲内に収まる場合に VM およびストレージリソースのサイズを自動的に変更することができます。また、サイズ変更量が範囲外になると Workload Optimization Manager から通知が届くため、ユーザーは最適なアクションを実行できます。詳細については、「オンプレミス VM 向けに調整済みスケーリング（203  ページ）」を参照してください。

ストレージのサイズ変更を実行した後、Workload Optimization Manager ではサイズ変更アクションが正常に実行されたことが示され、ハイパーバイザでは実行したストレージ容量の変更が表示されないことがあります。その場合は、ハイパーバイザの手動更新を実行して、ストレージの変更を検出できるようにします。

アクションの移動

Workload Optimization Manager では、ホストとストレージの移行を自動化することを推奨しています。

環境内の特定のワークロードに関する配置要件（たとえば、すべての実稼働仮想マシンが特定のクラスタにのみ移動するなど）がある場合は、配置の制約を使用します。Workload Optimization Manager では、ターゲットを追加するときに、配置ポリシーを自動的にインポートしたり、新しい配置ポリシーを作成したりすることができます。詳細については、「配置 ポリシー」（70  ページ）を参照してください。

ポリシーの使用

ポリシーは、Workload Optimization Manager がリソース割り当てを分析する方法、リソースステータスを表示する方法、およびアクションを推奨または実行する方法を制御するビジネスルールを設定します。Workload Optimization Manager には、次の 2 つの基本タイプのポリシーが含まれています。

■        配置ポリシー

ワークロードの配置の決定を変更するには、Workload Optimization Manager はそのマーケットを有効なワークロードの配置が含まれているセグメントに分割します。Workload Optimization Manager は、環境内のターゲットによって定義されている配置ルールを検出します。また、ユーザー独自のセグメントを作成することもできます。

■        自動化ポリシー

Workload Optimization Manager は、分析から最良の結果が得られると考えられるデフォルト設定で出荷されます。これらの設定は、環境内の環境各エンティティタイプのデフォルト自動ポリシーで指定されています。環境の一部の範囲では、これらの設定を変更する必要がある場合があります。たとえば、その範囲で、アクションの自動化や制約を変更する場合です。指定した範囲に対してデフォルトをオーバーライドするアクションポリシーを作成できます。

[Policy Management] ページには、現在定義されているすべてのポリシーが表示されます。このページから、次の操作を実行できます。

■        新しいポリシーの作成。

■        ユーザーが作成したポリシーの削除。

■        デフォルトポリシーまたはユーザーが作成したポリシーの編集。

■        検出済み配置ポリシーの有効化または無効化。Workload Optimization Manager のセグメント（Workload Optimization Manager 内に作成された配置ポリシー）では、ポリシー定義を編集したり、それを有効または無効にすることができます。

範囲に適用されているポリシーを表示するには、[Search] ページに移動し、その範囲に Workload Optimization Manager セッションを設定します。次に、[Policy] ビューを表示します。詳細については、「範囲ポリシー（ 40 ページ）」を参照してください。

ユーザーができること

■        インポートされた配置ポリシーの管理： ワークロード配置ポリシーのインポート（70 ページ）

■        配置ポリシーの作成： 配置ポリシーの作成（70 ページ）

■        範囲設定済み自動化ポリシーの作成： 範囲設定済み自動化ポリシーの作成（78 ページ）

 

配置ポリシー

プランおよび最適化をする場合、Workload Optimization Manager は、アプリケーションやプロバイダーの VM（ホスト、データストア、ディスクアレイ、ネットワークなど）などのワークロードを配置するアクセスパスを推奨します。Workload Optimization Manager は、これらのアクションを推奨したり、それらを自動的に実行することができます。

ワークロードの配置を計算するときに、Workload Optimization Manager はクラスタの境界、ネットワーク、およびプロビジョニングされたデータストアに配慮します。さらに、環境の設定で論理境界を指定し、Workload Optimization Manager 内でさらに境界を作成することもできます。これらの境界によって、Workload Optimization Manager がアプリケーション インフラストラクチャのモデル化に使用する市場にセグメントを適用します。

財務部門では、市場セグメントは、人が商品やサービスを購入または販売するときに使用する基準が異なる人のグループに応じて市場を分割します。同様に、Workload Optimization Manager の市場では、ワークロード配置セグメントは基準を使用して、特定のエンティティグループ内のリソースの購入と販売に重点を置きます。これにより、Workload Optimization Manager が動きをどのように計算するかについて細かく制御できるようになります。セグメントを管理すると、以下が可能になります。

■        Workload Optimization Manager が検出した配置ポリシーを確認します。これらは、Workload Optimization Manager 外のユーザーの環境で定義されたポリシーです。「ワークロード配置ポリシーのインポート（70 ページ）」を参照してください。

■        特定のルールに従ってワークロードの配置を制限する配置セグメントを作成します。「配置ポリシーの作成  （70  ページ）」を参照してください。

注：

リアルタイム環境または計画内の配置計算に影響を与えるように、インポートしたポリシーまたは作成したワークロード配置セグメントを有効または無効にすることができます。

ワークロード配置ポリシーのインポート

ターゲットとして設定するハイパーバイザには、それら独自の配置ポリシーを含めることができます。Workload Optimization Manager は、これらの配置ポリシーをインポートし、それらを配置の制約であると見なします。これらのインポートされたポリシーをリアルタイム分析用に無効にすることはできませんが、プラン用に無効にすることはできます。

Workload Optimization Manager は、以下をインポートします。

■        vCenter サーバーの DRS ルール

『Target Configuration Guide』の「Other Information Imported from vCenter」を参照してください。

■        仮想マシンマネージャの可用性セット

『Target Configuration Guide』の「Virtual Machine Manager」を参照してください。

■        Flexera One ライセンスの仕様

『ターゲット構成ガイド』の「Flexera」を参照してください。

注:

vCenter 環境では、DRS がハイパーバイザで無効になっている場合、Workload Optimization Manager は DRS ルールをインポートしません。さらに、Workload Optimization Manager が有効な DRS ルールをインポートし、その後で誰かがその DRS ルールを無効にした場合は、そのルールが無効になったことを Workload Optimization Manager が検出し、インポートされた配置ポリシーを削除します。

配置ポリシーの作成

配置ポリシーでは、Workload Optimization Manager が環境内のワークロードの配置を計算する方法に影響を与えるように制約を設定します。このようにして、Workload Optimization Manager は、企業のビジネスルールを満たすアクションを推奨することができます。

Workload Optimization Manager は、環境内に定義された配置ポリシーを検出します。また、Workload Optimization Manager のユーザーインターフェイスを使用して配置ポリシーを作成することもできます。リアルタイム分析と計画シナリオの両方で、配置ポリシーを有効または無効にできることに注意してください。

Workload Optimization Manager は、次の配置ポリシーをサポートしています。

■        [Place] ：特定のプロバイダーを使用するエンティティを決定します。

たとえば、コンシューマグループ内の VM は、プロバイダーグループ内の PM 上でのみ実行できます。1 つのプロバイダー上で実行できるコンシューマの数を制限できます。プロバイダーグループ内のホストでは、コンシューマグループ内の VM の 2 つのインスタンスのみが同じホスト上で実行できます。または、指定された数以下の VM が同じストレージデバイスを使用できます。

■        [Don't Place]：コンシューマは特定のプロバイダー上で実行できません。

たとえば、コンシューマグループ内の VM は、プロバイダーグループ内のホストでは実行できません。このようなセグメントを使用することで、特定のワークロードに専用のハードウェアを予約することができます。

■        [Merge]：クラスタを 1 つのプロバイダーグループにマージします。

たとえば、1 つのプロバイダーグループには 3 つのホストクラスタをマージできます。これにより、Workload Optimization Manager は、いずれかのクラスタ内のホストから、ワークロードを移動させ、マージした任意のクラスタでホストし、環境の効率性を向上させます。

■        ライセンス：VM にライセンスを提供するようにホストを設定します

有料ライセンスが必要な VM の場合、特定のホストを VM の優先ライセンス プロバイダーとして設定する配置ポリシーを作成できます。その後、Workload Optimization Manager は、ライセンス需要の変化に応じて、VM の統合またはホストの再構成を推奨できます。

1.      [Settings] ページに移動します。

クリックして [Settings] ページに移動します。このページから、Workload Optimization Manager のさまざまな設定タスクを実行できます。

2.      [Policies] を選択します。

クリックして、[Policy Management] ページに移動します。

このページには、Workload Optimization Manager に対して現在設定されているすべてのポリシーが一覧表示されます。

3.      新しい配置ポリシーを作成します。

 

 

最初に、作成する配置ポリシーのタイプを選択してから、次の設定を指定します。

■       ポリシーに名前を付ける

■       ポリシータイプを選択し、設定を行う

■       完了したら、ポリシーを保存する

4.      [Placement] ポリシーを作成します。

これらのポリシーは、ワークロードを配置できる場所を制御します。たとえば、特定のクラスタのメンバーであるホスト上にのみ VM を配置するように指定できます。または、特定のグループ内のすべてのアプリケーションを、特定のグループのメンバーであるデータストア上にのみ配置できるように指定することもできます。

■       コンシューマグループを指定する：識別されたプロバイダー上に配置するエンティティのグループまたはクラスタ

■       プロバイダーグループを指定する：コンシューマにリソースを提供するエンティティのグループまたはクラスタ

■       [Limit workload entities to placement group]： プロバイダーグループのメンバーにコンシューマエンティティのみを配置するようにポリシーを設定します。

■       [Limit the maximum number of workload entities per placement entity to]：1 つのプロバイダーに配置できるコンシューマエンティティのインスタンス数を制限します。

5.      [Don't Place] ポリシーを作成します。

 

これらのポリシーでは、コンシューマエンティティをホストしないグループまたはクラスタを識別します。たとえば、特定のクラスタのメンバーであるホストに VM を配置しないように指定できます。または、重要なアプリケーションの可用性を確保する手段として、重要ではないアプリケーションのセットを専用のハードウェアに配置しないように指定できます。

■       コンシューマグループの指定：識別されたプロバイダーから除外するエンティティのグループまたはクラスタ

■       プロバイダーグループの指定：コンシューマにリソースを提供しないエンティティのグループまたはクラスタ

 

6.      [Merge] ポリシーを作成します。

ワークロード配置の目的で、複数のクラスタを単一のロジカルグループにマージする配置ポリシーを作成できます。

たとえば、使用中の環境で、ハードウェアベンダーやその他の基準に従って、ホストをクラスタに分割する場合があります。通常、ワークロードの配置は、このようなクラスタ境界を超えません。ただし、これらの境界をワークロードの配置に適用する技術上の理由がない場合があります。プロバイダーリソースの大規模なプールを作成することにより、Workload Optimization Manager は、環境の効率性を向上させる機会をさらに増やすことができます。

マージポリシーについては、次の考慮事項に留意してください。

■       ホストとストレージクラスタをマージするポリシーのほとんどについては、マージセグメントに配置するクラスタは、同じデータセンターのメンバーであることが必要です。

■       vCenter 環境の場合、データセンターをマージする配置ポリシーを作成して vCenter 外の移動をサポートします。この場合、データセンターが特定の vCenter ターゲットに対応している場合は、マージされたクラスタを異なるデータセンターに配置できます。この場合、2 つのマージポリシーを作成する必要があります。1 つは影響を受けるデータセンターをマージするためのもの、もう 1 つは特定のクラスタをマージするためのものです。

また、マージするクラスタは、それぞれのデータセンターで同じネットワーク名を使用する必要があることにも注意してください。

■       クラウド環境の場合は、データセンターをマージするためのポリシーを作成できます。これらのマージポリシーを使用すると、別のゾーンでより優れたコストを検出する VM 移動をサポートできます。

マージポリシーを作成するには、マージするエンティティのタイプを選択し、マージするグループを選択します。

7.      ライセンス ポリシーを作成します。

データベースに対して複数のライセンスを購入し、特定の数のホストでそのデータベースを実行する権限に対して支払いをしたと仮定します。ライセンスポリシーを作成すると、ライセンスを提供するホストと、そのライセンスを使用できる VM を特定できます。

ポリシーを作成すると、Workload Optimization Manager は、ライセンス需要の変化に応じて次のアクションを推奨できます。

■       需要が少ない場合、Workload Optimization Manager は、ライセンスコストを削減するために、ライセンスを提供するホストをできるだけ少なくして VM を統合することを推奨します。統合するには、VM を別のホストに移動し、元のホストを再構成してライセンスを削除します。Workload Optimization Manager は、これらのホストの一時停止を推奨しないことに注意してください。それらはアクティブなままなので、需要がキャパシティを超え始めたときにプロバイダーになるように再構成できます。

 

 

 

たとえば、Host_01 が VM_01 にライセンスを提供し、Host_02 が VM_02 にライセンスを提供している場合、VM_02 を Host_01 に移動してから、Host_01 のライセンスを削除するという 2 つの推奨事項が表示されます。Host_01 を一時停止する推奨事項は表示されません。

■       需要がキャパシティを超え、現在ライセンスを提供していないホストがポリシーに含まれている場合、Workload Optimization Manager は、それらのホストを再構成してプロバイダーにしてから、VM をそれらのホストに移動することを推奨します。すべてのホストが現在ライセンスを提供している場合、Workload Optimization Manager は、需要を満たすためにホストにライセンスを追加することを推奨します。

これらのアクションは、新しいホストをプロビジョニングするよりも効率的です。

ライセンスポリシーを作成するには、次の手順を実行します。

■       ライセンスコンシューマ（VM）を指定します。

■       ライセンスプロバイダー（ホスト）を指定します。

ライセンス ポリシーの作成に加えて、ホスト自動化ポリシーも作成して、Workload Optimization Manager がホストでの再構成アクションを推奨できるようにする必要があります。自動化ポリシーで、ライセンスを提供するホストを追加してから、再構成アクションを有効にします。

8.      すべての設定を行ったら、必ずポリシーを保存してください。

自動化ポリシー

Workload Optimization Manager はメトリックを収集しているときにメトリック値を指定された制約およびキャパシティ設定と比較し、メトリックが問題を示しているかどうか、および問題を回避するために推奨または実行するアクションを決定します。Workload Optimization Manager は、自動化ポリシーを使用して分析とその結果のアクションを導きます。これらのポリシーでは、次の以下を指定できます。

■        アクションの自動化

自動または手動のどちらを実行するか、または単にアクションを推奨するかどうかを指定できます。詳細については、「アクション の自動化（87  ページ）」を参照してください。

■        制約とその他の設定

Workload Optimization Manager による環境の状態の分析に影響を与える設定です。これには、運用、使用率、およびスケーリングの制約が含まれます。

詳細については、「制約とその他の設定（100  ページ）」を参照してください。

デフォルトおよび範囲を指定した自動化ポリシー

Workload Optimization Manager は、環境内で検出できるさまざまなタイプのエンティティのデフォルトの自動化ポリシー設定で出荷されます。これらのデフォルトポリシーの設定は、最初のビジネス要件を満たすために十分である必要があります。これらのポリシーはグローバルな範囲に適用されます。これらをオーバーライドしない限り、環境内のすべてのエンティティに影響を与えます。詳細については、「デフォルトの自動化ポリシーの使用（74  ページ）」を参照してください。

Workload Optimization Manager には、特定のエンティティのデフォルト設定をオーバーライドする、範囲を指定したアクションポリシーを含めることができます。これらのポリシーを使用して、ポリシーの範囲として 1 つ以上のエンティティグループを指定します。また、メンテナンス期間を指定するためのポリシーにスケジュールを設定したり、特定のアクションを実行する前に承認を必要とするオーケストレーション ワークフローをサポートしたりすることもできます。詳細については、「範囲を指定した自動化ポリシーの使用」（77  ページ）および「ポリシー スケジュールの設定」（86   ページ）を参照してください。

デフォルトの自動化ポリシーの使用

Workload Optimization Manager は、環境内で検出できるさまざまなタイプのエンティティのデフォルトの自動化ポリシー設定で出荷されます。これらのデフォルトポリシーの設定は、最初のビジネス要件を満たすために十分である必要があります。これらのポリシーはグローバルな範囲で適用されます。したがって、設定をオーバーライドしない限り、環境内のすべてのエンティティに影響を与えます。

時間が経つにつれて、特定のポリシー設定をグローバルに変更することが必要になる場合があります。たとえば、[Enforce Non Disruptive Mode] はデフォルトではオフになっています。ほとんどの場合、これをオンにして、選択範囲に対してのみオフにする必要がある場合があります。この場合、VM のデフォルトの自動化ポリシーでオンにしてから、オフにしたい VM のグループに対して範囲を指定したポリシーを設定します。

 

 

デフォルトのポリシーと範囲を指定したポリシー間の関係

デフォルトの自動化ポリシーと範囲を指定した自動化ポリシーは、相互に関連して有効になります。デフォルトのポリシーにはグローバルな影響がありますが、範囲を指定したポリシーは指定された範囲内のエンティティに対するデフォルトのポリシーをオーバーライドします。次の点に留意してください。

■        スコープ付きポリシーは、設定のサブセットをオーバーライドします。

範囲を指定したポリシーは、エンティティタイプの設定の一部をオーバーライドできます。また、残りについては、Workload Optimization Manager が指定された範囲にあるデフォルトのポリシー設定を使用します。

■        エンティティが競合するスコープ ポリシーを適用すると、ワークロード最適化マネージャーは次のタイ ブレーカーを適用します。

–       スケジュールされていないポリシーがより保守的であっても、スケジュールされたポリシーは常にスケジュールされていないポリシーよりも優先されます。

–       同一内容のスケジュール ポリシーの中でも、最も「控えめ」な設定が適用されます。

–       未スケジュール ポリシーの中でも、最も「控えめ」な設定が適用されます。

たとえば、VM は現在、異なるポリシー設定を持つ 4 つのグループに属しています。

–       グループ A ポリシー：毎週土曜日に手動モードで VM のサイズを変更します。

–       グループ B ポリシー：毎週土曜日に自動モードで VM のサイズを変更します。

–       グループ C ポリシー：手動モード（スケジュールなし）で VM のサイズを変更します。

–       グループ D ポリシー：推奨モード（スケジュールなし）で VM のサイズを変更します。 

成果

–       土曜日には、グループ A および B のポリシーがグループ C および D のポリシーよりも優先されます。VM は、より保守的な設定であるため、最終的にグループ A 設定を適用します。

–       それ以外の日は、グループ C および D のポリシーのみがアクティブです。VM は、より保守的なグループ D 設定を適用します。

■        範囲を指定したポリシーは、デフォルトのポリシーよりも常に優先されます。

デフォルトのポリシーの方が控えめに設定されている場合でも、範囲を指定したポリシーの設定がその範囲内のエンティティに適用されます。

■        グローバルな影響については、常にデフォルト ポリシーを使用します

範囲を指定したポリシーでは「控えめな設定が適用される」というルールがあるため、範囲を指定したポリシーを使用してグローバルな影響力を設定しないでください。たとえば、[All VMs] グループに範囲を指定したポリシーを作成できます。その後で、そのポリシーに控えめな設定を指定すると、範囲を指定した他のポリシーではよりアグレッシブな設定を指定できなくなります。控えめな設定が常に適用されます。

このため、グローバルに影響を与えたい場合は、常に、デフォルトの自動化ポリシーを使用する必要があります。

デフォルトの自動化ポリシーの表示と編集

デフォルトのポリシーを表示または編集するには、次の手順を実行します。

1.      [Settings] ページに移動します。

クリックして [Settings] ページに移動します。このページから、Workload Optimization Manager のさまざまな設定タスクを実行できます。

2.      [Policies] を選択します。

クリックして、[Policy Management] ページに移動します。

このページには、Workload Optimization Manager に対して現在設定されているすべてのポリシーが一覧表示されます。

3.      [Policy Management] ページで、[Defaults] をクリックします。

 

 

このページには、デフォルトのすべてのポリシーのリストがエンティティタイプ別に表示されます。

4.      デフォルトの設定を表示または変更するエンティティタイプをクリックします。

そのデフォルトのポリシーのすべての設定を含むフライアウトが表示されます。移動すると、他の設定を表示できます。

5.      必要に応じて、このデフォルトのポリシーの設定を編集します。

変更する設定に移動して、それぞれに異なる値を入力します。

6.      完了したら、[Save And Apply] をクリックします。

グローバル デフォルト ポリシー

これらの設定を使用して、環境の任意の範囲に対して Workload Optimization Manager 分析を全体的に変更します。これらのデフォルトは、範囲指定された自動化ポリシーとデフォルトの自動化ポリシーの両方に影響します。

アクションの自動化

すべてのアクションを無効化

これがオンの場合、Workload Optimization Manager は環境に対してアクションを生成しません。たとえば、アクションを自動化するいくつかのポリシーを構成したが、環境全体への変更を一定期間停止したいとします。これをオンにすると、1 回の設定ですべての実行を停止します。

[OPERATIONAL CONSTRAINTS]

VM 成長観測期間

この設定を使用して、履歴データの量を指定し、Workload Optimization Manager 分析がクラスタ リソースを使い果たすまでの時間を計算します。

Workload Optimization Manager は、夜間計画を実行して、オンプレミス環境のクラスタのヘッドルームを計算します。ダッシュボードでクラスタヘッドルームを確認するには、ビュー範囲をクラスタに設定します。その範囲を使用すると、ビューには、クラスタのヘッドルームを表示するチャートとクラスタリソースが枯渇するまでの時間が表示されます。

クラスタの成長傾向を計算するために、分析では特定のクラスタの履歴データが使用されます。VM 成長観測期間を使用すると、ヘッドルーム分析でクラスタリソースが枯渇するまでの時間を計算するために使用する履歴データの量を指定できます。

 

たとえば、クラスタの使用量がゆっくりと増加している場合、その増加率をキャプチャするのに十分な長さの期間に監視を設定できます。

履歴データベースにクラスタの月次データに少なくとも 2 つのエントリが含まれていない場合、分析では日次履歴データが使用されます。

無制限のホストプロビジョニングを許可する

デフォルトでは、Workload Optimization Manager は、ホストのメモリ容量の最大 10 倍、および CPU キャパシティの最大 30 倍のオーバープロビジョニングを許可します。この設定がオンの場合、Workload Optimization Manager はこれらのオーバープロビジョニングの制限を削除して、すでにオーバープロビジョニングされたホストに VM を配置できるようにします。

この設定は、Workload Optimization Manager がクラスタ内の新しいホストをプロビジョニングするためのアクションを推奨することを停止しません。

オンプレミスボリュームの分析の有効化

オンプレミス ボリューム（222  ページ）は、ハイパーバイザ ターゲットによって検出された VM ディスクを表します。VM には、構成されたディスクごとに 1 つのボリュームと、常にディスク 1 とともに移動する別のボリューム（構成を表す）があります。

■        オフ（デフォルト）

Workload Optimization Manager は、VM 分析の一部としてボリューム リソースを分析します。リアルタイム マーケットおよびオンプレミスのプランでは、VM ストレージを移動するアクションを実行すると、ボリュームが基盤となるデータストアに確実に保持されます。クラウド  pプランへの移行（290  ページ）では、現在データストアにあるすべての VM ディスクを保持するために、データストアごとのストレージが推奨されます。

たとえば、3 つのディスクを持つ VM を想定します。ディスク 1 と 3 はデータストア A にあり、ディスク 2 はデータストア B にあります。

–       ストレージの移行中、VM ディスク ボリューム 1 と 3 は同じデータストアに残ります。

–       クラウド移行プランでは、VM ディスク ボリューム 1 と 3 にストレージ ディスクを、VM ディスク ボリューム 2 に別のストレージ ディスクを推奨します。

■        オン（On）

Workload Optimization Manager は、各ボリュームのリソースを個別に分析します。リアルタイム マーケットおよびオンプレミスのプランでは、VM ストレージを移動するアクションは、ボリュームを最適なデータストアに移行します。クラウド移行プランでは、各ボリュームのストレージが推奨されます。

たとえば、3 つのディスクを持つ VM を想定します。ディスク 1 と 3 はデータストア A にあり、ディスク 2 はデータストア B にあります。

–       ストレージの移行中に、VM ディスク ボリューム 1、2、および 3 を異なるデータストアに移行できます。

–       クラウド移行プランでは、VM ディスク ボリューム 1、2、および 3 に 3 つの個別のストレージ ディスクが推奨されます。

重要事項：

この設定をオンにすると、Workload Optimization Manager インスタンスは、分析を実行するために、より多くのメモリとストレージを使用し始めます。たとえば、10,000 台の VM があり、VM あたり平均 3 台のディスクがある環境は、

分析が必要なエンティティが 3 倍に増加します。現在、50,000 を超えるボリュームをモニタするインスタンスのパフォーマンスが大幅に低下します。このため、この設定はデフォルトでオフになっています。

この設定をオンにする前に、VM 自動化ポリシー（204  ページ）を確認し、ストレージ移動アクションが推奨モードまたは手動モードであることを確認してください。さらに、ストレージ配置ポリシー（70  ページ）を確認して、個々の VM ボリュームを想定されるストレージに配置できることを確認します。

範囲を指定した自動化ポリシーの使用

現在のデフォルトの自動化ポリシーをオーバーライドするには、範囲を指定したポリシーを作成します。これらは、環境内の特定のエンティティに対して変更を加える設定を指定します。これらのポリシーでは、エンティティの 1 つ以上のグループにポリシーを割り当てます。また、環境内でメンテナンス期間やその他のスケジュール済みのアクションを設定するために、スケジュールを範囲を指定したポリシーに割り当てることができます。

範囲を指定した自動化ポリシーを作成する理由は次のとおりです。

■        特定のエンティティの分析設定を変更する

Workload Optimization Manager は、いくつかの設定を使用して、環境内のエンティティの分析を誘導します。ほとんどの場合は、デフォルトの設定をそのまま使用できる可能性がありますが、エンティティの一部のグループについては別の分析が必要になることがあります。範囲を指定したポリシーを設定して、運用上の制約やスケーリングの制約を変更できます。詳細については、「制約 とその他の設定（100  ページ）」を参照してください。

■        アクションの自動化のフェーズ

環境内の VM のスケーリングと配置のアクションを自動化することを前提としています。一般には、慎重に構えて、重要でないか、または実稼働中ではないクラスタの自動化から開始します。これらのクラスタに対してポリシーの範囲を指定し、それらの VM の別のアクションに対してアクションモードを [自動（Automated）] に設定します（「アクション モード（58  ページ）」を参照）。

範囲を指定したポリシーを作成する手順については、「範囲を指定した自動化ポリシーの作成（78  ページ）」を参照してください。

範囲を指定した自動化ポリシーの検出

Workload Optimization Manager が環境を検出すると、特定のポリシーを必要とする範囲を設定する構成を見つけることができます。次に例を示します。

■        HA 構成

vCenter サーバー環境では、Workload Optimization Manager が HA クラスタ設定を検出し、それらを CPU とメモリの使用率の制約に変換します。この検出により、HA クラスタごとに「フォルダ」タイプのグループが作成され、適切な CPU とメモリの制約をそのポリシーに設定するポリシーが作成されます。

■        可用性セット

パブリッククラウド環境では、Workload Optimization Manager は、すべての VM を同じテンプレート上に保持する必要がある VM のグループを検出します。[Automation Policies] リストには、ポリシー名にプレフィックス AvailabilitySet::  が表示されます。各グループの VM に対して一貫したサイズ変更を有効にして、Workload Optimization Manager がそれらを同じサイズにサイズ変更できるようにすることができます。

範囲を指定した自動化ポリシーの作成

[ポリシー管理（Policy Management）] ページから、範囲指定された新しい自動化ポリシーを作成します。

1. エントリ ポイント

[設定（Settings）] ページに移動し、[ポリシー（Policies）] を選択します。

これにより、[ポリシー管理（Policy Management）] ページが開き、現在使用可能なすべてのポリシーが一覧表示されます。

 

 

[新しい自動化ポリシー（NEW AUTOMATION POLICY）] をクリックし、ポリシータイプを選択します。

これにより、ポリシーが影響を与えるエンティティのタイプが設定されます。Workload Optimization Manager は、エンティティの異なるタイプに対する異なるアクションをサポートしていることに注意してください。たとえば、ストレージデバイスに VMem を追加することはできません。ポリシータイプの設定は、ワークフローにマッピングするアクションに集中するために最初に実行する手順です。

2. ポリシー名

ポリシーに名前を付けます。

 

 

3. 対象範囲

スコープによって このポリシーが影響を与える対象が決まります1 つ以上のグループを選択するか、新しいグループを作成してポリシー範囲に追加します。これらのグループは、ポリシーに設定したエンティティのタイプと一致します。

Workload Optimization Manager では、ネストされたグループ（グループのグループ）を見つけることができます。たとえば、「PM クラスタ別」グループにはホストのクラスタが含まれていますが、このホストクラスタそれぞれがグループです。ネストされたグループの親にポリシーの範囲を設定しないでください。ポリシーを設定する場合は、それらを個別のグループに設定してください。必要に応じて、適用する設定のカスタムグループを作成します。

 

 

注：

1 つのエンティティを複数のグループのメンバーにすることができます。これにより、同じエンティティに異なるアクションポリシーが設定できるため、設定に競合が発生する可能性があります。範囲を指定したポリシーの設定間で競合が生じた場合は、最も控えめな設定が有効になります。詳細については、「ポリシー範囲（ 85 ページ）」を参照してください。

4. ポリシーのスケジュール

スケジュールがポリシーに影響を与える使用例と情報については、「ポリシーのスケジュール（86   ページ）」を参照してください。

[Select Schedule] フライアウトには、Workload Optimization Manager のインスタンスに対して現在定義されているすべてのスケジュールが一覧表示されます。

スケジュールエントリを展開すると、その詳細が表示されます。詳細には、スケジュール定義の概要と、次の情報が含まれています。

■        複数のポリシーで使用

このスケジュールを使用するポリシーの数。数字をクリックして、ポリシーを確認します。

■        次の発生

スケジュールが次にいつ有効になるか。

■        受け入れられたアクション

次のスケジュール済みの時点での実行を承認されているスケジュール済みのアクションの数。これらのアクションのリストの数字をクリックします。

 

 

 

■        承認待機

[Pending Actions] リストに含まれており、まだ承認されていないこのスケジュールによって影響を受ける手動アクションの数。これらのアクションのリストの数字をクリックします。

リストされているスケジュールのいずれもがポリシーに適していない場合（または既存しない場合）は、[新規スケジュール（New Schedule）] をクリックします。「スケジュールの作成（  374 ページ）」を参照してください。

注：

VM サイズ変更アクションのスケジュール期間を構成する際、Workload Optimization Manager がスケジュール済み期間にアクションを実行するようにするには、そのスケジュール済みのポリシーに対して [非中断モードを適用する（Enforce Non Disruptive Mode）] の設定をオフにする必要があります。グローバルポリシーの設定をオフにした場合も、スケジュール済みのポリシーの設定をオフにする必要があります。そうしないと、Workload Optimization Manager はサイズ変更アクションを実行しません。

5. 自動化とオーケストレーション

同じポリシー内で、さまざまなアクションタイプの自動化とオーケストレーションの設定を定義できます。たとえば、ポリシー内の VM のグループの場合、すべてのサイズ変更アクションを自動化できますが、一時停止アクションはオーケストレーター（ServiceNow など）を介して承認プロセスを通過する必要があります。

5.1. アクションタイプ

ポリシーに対して実行可能なアクションのリストを表示し、選択を行います。

5.2. アクションの生成と承認

■        アクションを生成しない

Workload Optimization Manager は、その計算で選択したアクションを考慮することはありません。たとえば、ポリシーの VM に対してサイズ変更アクションを生成しない場合、望ましい状態に対して分析が行われますが、サイズ変更を考慮せずに分析が行われます。

■        アクションの生成

Workload Optimization Manager は、問題に対処または防止するために、選択したアクションを生成します。次のアクション受け入れモードから選択して、アクションの実行方法を指定します。

–       [Recommend]：指定したハイパーバイザ経由か、またはその他の手段でユーザーが実行できるようにアクションを推奨します。

 

 

–       Manual：Workload Optimization Manager のユーザーインターフェイスを通じて実行するアクションを推奨し、オプションを提供します。

–       Automated：アクションを自動的に実行します。

同じエンティティでの自動サイズ変更または移動アクションの場合、Workload Optimization Manager は、すべてのアクションを一度に実行しようとすることに関連するエラーを回避するために、各アクション間に 5 分間待機します。実行待機中のアクションはすべてキューに残ります。たとえば、VM に vCPU と vMem の両方のサイズ変更アクションがある場合、Workload Optimization Manager は最初に vCPU のサイズを変更することもあり得ます。このサイズ変更が完了すると、vMem のサイズを変更するまで 5 分間待機します。

ServiceNow ターゲットがある場合で、そのターゲットに、Workload Optimization Manager アクションアプリケーションのインストールが含まれる場合、アクションを ServiceNow に送信できます。次のオプションから選択します。

■        アクションを生成してから ServiceNow にレコードを送信

■        アクションを生成し、ServiceNow から承認を要求します。詳細については、「 アクション オーケストレーション （86 ページ）を参照してください。

5.3. 実行前、アクション実行、実行後

デフォルトでは、生成されたアクションはオーケストレーションを必要とせずに実行されます。Workload Optimization Manager を使用すると、アクションの実行に影響を与えるオーケストレーションを設定できます。

詳細については、「アクションのオーケストレーション（88  ページ）」を参照してください。

5.4. スケジュールの実行

生成されたアクションの実行を、クリティカルでない時間枠に延期することができます。たとえば、ワークロードがその週のメモリのボトルネックに直面した場合、必要なサイズ変更を週末まで延期できます。週末にワークロードの使用率が最小限であっても、Workload Optimization Manager はサイズ変更の必要性を認識し、アクションを実行します。

詳細については、「アクション実行スケジュール（86 ページ ）」を参照してください。

6. 制約とその他の設定

このポリシーによって影響を受けるエンティティのタイプに応じて、指定できる設定は異なります。ポリシーに追加する各設定は、その設定のデフォルト値よりも優先されます。設定の詳細については、「制約と その他の設定（100 ページ ）」を参照してください。

ポリシーの範囲

範囲を指定した自動化ポリシーを作成するたびに、範囲を宣言する必要があります。この範囲によって、ポリシー設定の影響を受けるエンティティが決まります。範囲を設定するには、1 つ以上のグループをポリシーに割り当てます。検出されたグループを使用することも、独自のグループを作成することもできます。グループの作成については、「グループの作成（ 369 ページ）」を参照してください。

デフォルトのポリシーと範囲を指定したポリシー間の関係

デフォルトの自動化ポリシーと範囲を指定した自動化ポリシーは、相互に関連して有効になります。デフォルトのポリシーにはグローバルな影響がありますが、範囲を指定したポリシーは指定された範囲内のエンティティに対するデフォルトのポリシーをオーバーライドします。次の点に留意してください。

■        スコープ付きポリシーは、設定のサブセットをオーバーライドします。

範囲を指定したポリシーは、エンティティタイプの設定の一部をオーバーライドできます。また、残りについては、Workload Optimization Manager が指定された範囲にあるデフォルトのポリシー設定を使用します。

■        エンティティが競合するスコープ ポリシーを適用すると、ワークロード最適化マネージャーは次のタイ ブレーカーを適用します。

–       スケジュールされていないポリシーがより保守的であっても、スケジュールされたポリシーは常にスケジュールされていないポリシーよりも優先されます。

–       同一内容のスケジュール ポリシーの中でも、最も「控えめ」な設定が適用されます。

–       未スケジュール ポリシーの中でも、最も「控えめ」な設定が適用されます。

たとえば、VM は現在、異なるポリシー設定を持つ 4 つのグループに属しています。

–       グループ A ポリシー：毎週土曜日に手動モードで VM のサイズを変更します。

–       グループ B ポリシー：毎週土曜日に自動モードで VM のサイズを変更します。

–       グループ C ポリシー：手動モード（スケジュールなし）で VM のサイズを変更します。

–       グループ D ポリシー：推奨モード（スケジュールなし）で VM のサイズを変更します。

 

 

成果

–       土曜日には、グループ A および B のポリシーがグループ C および D のポリシーよりも優先されます。VM は、より保守的な設定であるため、最終的にグループ A 設定を適用します。

–       それ以外の日は、グループ C および D のポリシーのみがアクティブです。VM は、より保守的なグループ D 設定を適用します。

■        範囲を指定したポリシーは、デフォルトのポリシーよりも常に優先されます。

デフォルトのポリシーの方が控えめに設定されている場合でも、範囲を指定したポリシーの設定がその範囲内のエンティティに適用されます。

■        グローバルな影響については、常にデフォルト ポリシーを使用します

範囲を指定したポリシーでは「控えめな設定が適用される」というルールがあるため、範囲を指定したポリシーを使用してグローバルな影響力を設定しないでください。たとえば、[All VMs] グループに範囲を指定したポリシーを作成できます。その後で、そのポリシーに控えめな設定を指定すると、範囲を指定した他のポリシーではよりアグレッシブな設定を指定できなくなります。控えめな設定が常に適用されます。

このため、グローバルに影響を与えたい場合は、常に、デフォルトの自動化ポリシーを使用する必要があります。

ポリシーのスケジュール

自動化ポリシーのスケジュールを設定できます。これにより、ポリシーが有効になる時間枠が設定されます。たとえば、一定期間の運用またはスケーリングの制約を変更できます。これらの設定は、Workload Optimization Manager の分析と、それが生成するアクションに影響します。これらの設定を変更する場合は、スケジュール済みの時間を設定できます。

範囲を指定した自動化ポリシーでは、1 つのエンティティが 2 つの異なる範囲に入っている可能性があることに注意してください。これは、エンティティが 2 つの異なるポリシーの影響を受けている可能性があることを意味します。このため、範囲を指定したポリシーは、「最も控えめな設定が適用される」というルールに従います。ただし、範囲を指定したよりアグレッシブなポリシーは、対応するデフォルトの自動化ポリシーよりも優先されます。詳細については、「ポリシー範囲（ 85 ページ）」を参照してください。

ポリシーにスケジュールを追加する場合は、これらのルールを考慮する必要があります。より控えめな設定がデフォルトの自動化ポリシーに含まれている場合は、スケジュール済みの変更が有効になります。ただし、より控えめな設定が別の範囲が指定されたポリシー内にある場合、その比回目の設定が適用され、スケジュール済みの変更は有効になりません。

ポリシースケジュールとアクション実行スケジュール

スケジュールされたポリシーには、アクションを含めることができます。ポリシーが有効な場合、Workload Optimization Manager は、アクションが生成されると、生成されたアクションを推奨するか、自動的に実行します。これらのアクションの一部は混乱を招く可能性があるため、重要でない時間帯に実行を延期することができます。この場合、スケジュールされたポリシー内でアクションの実行スケジュールを設定する必要があります。たとえば、需要の増加を見越して、12 月全体でお客様向けアプリの VM を自動的にサイズ変更または起動するポリシーを設定できます。この同じポリシー内で、サイズ変更の実行スケジュールを、需要が最小になると予想される月曜日の午前 0 時から午前 7 時までに設定できます。

詳細については、「アクション実行スケジュール（86 ページ ）」を参照してください。

アクション実行スケジュール

生成されたアクションの実行を、クリティカルでない時間枠に延期することができます。たとえば、ミッションクリティカルな VM でその週にメモリのボトルネックが発生した場合、必要なメモリのサイズ変更を週末に延期できます。週末に VM の使用率が最小限であっても、Workload Optimization Manager はサイズ変更の必要性を認識し、サイズ変更アクションを実行します。この特定の例では、次のことを行う必要があります。

1.      VM に対して範囲を指定したポリシーを作成します。

2.      アクションのリストから [VMem のサイズアップ（VMem Resize Up）] を選択し、アクションモードを [自動（Automatic）] または [手動（Manual）] に設定します。

注:

実行スケジュールは、推奨アクションには影響しません。したがって、ポリシーのすべてのアクションが推奨モードである場合、実行スケジュールを設定する必要はありません。

3.      土曜日の午前 8 時に開始し、48 時間続く実行スケジュールを設定します。

 

 

スケジュール済みのアクションの実行

Workload Optimization Manager は、条件がそれを保証するときにアクションをポストします。つまり、実行スケジュールが有効になる前でも、保留中のアクション リストにアクションが表示される可能性があります。アクションの詳細には、指定されたアクションに影響を与えるスケジュールが表示され、そのスケジュールの次のオカレンスが示されます。

■        自動

スケジュールが有効になると、Workload Optimization Manager は、保留中の自動化アクションを実行します。

■        手動

実行スケジュールの前、手動で実行可能なアクションのアクションの詳細には、動作状態が [保留中の承認（PENDING ACCEPT）] として表示されます。アクションを承認すると（選択して、[選択値を適用（Apply Selected）] をクリック）、Workload Optimization Manager は、それを保守期間に実行予定のアクション キューに追加します。アクションの詳細には、アクション状態が [AWAITING EXECUTION] として表示されます。スケジュールが有効になると、Workload Optimization Manager は、アクションを実行します。

スケジュール済みの時間が経過するまでアクションを有効に保つ

スケジュール済みのアクションの実行が後の時点である場合、条件が変化して、そのアクションが有効でなくなる可能性があります。これが生じ、アクションが 24 時間無効のままになっている場合は、Workload Optimization Manager が保留中のアクションのリストからアクションを削除します。このアクションは実行されません。

Workload Optimization Manager には、VM のアクション決定を安定させるために機能するスケーリングの制約が含まれています。結果として得られるアクションは、スケジュール済みの実行の時間まで、有効な状態のままになる可能性が高くなります。これらの設定は、デフォルトのポリシーか範囲を指定したポリシーで行うことができます。

注：

サイズ変更アクションに対して実行スケジュールを構成する際は、Workload Optimization Manager がスケジュールされた期間にアクションを実行し、ポリシーに対する [非中断モードを適用する（Enforce Non Disruptive Mode）] をオフにすることを忘れないでください。グローバルポリシーの設定をオフにした場合も、ポリシーの設定をオフにする必要があります。そうしないと、Workload Optimization Manager はサイズ変更アクションを実行しません。非中断モードの詳細については、「非中断モード（ 205 ページ）」を参照してください。

アクションの自動化

環境内の問題を回避するために、Workload Optimization Manager の分析では、最適な実行順序を維持して実行できるアクションを特定します。これらのアクションに必要な自動化の程度を指定できます。たとえば、一部の環境では、それが中断を引き起こすアクションであるため、VM のサイズを引き下げるサイズ変更を自動化しない場合があります。ポリシーでアクションモードを使用して、そのビジネスルールを設定します。

アクションモードは、生成されたアクションに対して自動化の程度を指定します。たとえば、一部の環境では、それが中断を引き起こすアクションであるため、VM のサイズを引き下げるサイズ変更を自動化しない場合があります。ポリシーでアクションモードを使用して、そのビジネスルールを設定します。

Workload Optimization Manager は、次のアクションモードをサポートしています。

■        [Recommend]：指定したハイパーバイザ経由か、またはその他の手段でユーザーが実行できるようにアクションを推奨します。

■        Manual：Workload Optimization Manager のユーザーインターフェイスを通じて実行するアクションを推奨し、オプションを提供します。

■        Automated：アクションを自動的に実行します。

同じエンティティでの自動サイズ変更または移動アクションの場合、Workload Optimization Manager は、すべてのアクションを一度に実行しようとすることに関連するエラーを回避するために、各アクション間に 5 分間待機します。実行待機中のアクションはすべてキューに残ります。たとえば、VM に vCPU と vMem の両方のサイズ変更アクションがある場合、Workload Optimization Manager は最初に vCPU のサイズを変更することもあり得ます。このサイズ変更が完了すると、vMem のサイズを変更するまで 5 分間待機します。

アクションモードの設定

アクションモードを設定するには、次の 2 つの方法があります。

■        デフォルトポリシーでアクションモードを変更する。詳細については、「 デフォルトの自動化ポリシーの使用（74 ページ）」を参照してください。

■        自動化ポリシーを作成し、ポリシーを特定のエンティティまたはグループに範囲を指定してから、アクションごとにアクションモードを選択します。

Workload Optimization Manager を使用すると、将来検出されたエンティティが自動的にグループに追加され、そのグループのポリシーが適用されるように、ダイナミックグループを作成することができます。複数のグループに属するエンティティの結果として競合が発生した場合、エンティティは最も控えめなアクションでポリシーを適用します。

詳細については、「スコープ自動化ポリシーの作成（78  ページ）」を参照してください。

アクションのオーケストレーション

アクションのオーケストレーションでは、Workload Optimization Manager がアクションを実行するかどうか、または、Workload Optimization Manager が独自のワークフローを実行して環境内の変更に影響を与えるオーケストレータまたはアクションスクリプトにアクション要求を渡すかどうかを指定します。このようにして、サポートされているオーケストレータを統合し、環境内のエンティティの特定の範囲に対してアクションを実行できます。

オーケストレータについて

アクション オーケストレーションのターゲットが環境内で変更を行うために複数のアクションを実行するワークフローを割り当てます。Workload Optimization Manager は、オーケストレータで定義したワークフローを検出します。その後で、ワークフローをアクションにマッピングする自動化ポリシーを設定できます。アクションモードが [手動（Manual）] または [自動（Automated）] の場合は、Workload Optimization Manager がアクションを推奨すると、マッピングされたワークフローを使用して実行するようにオーケストレータに指示します。

Workload Optimization Manager は、ServiceNow との統合をサポートします。ServiceNow インスタンス内の Workload Optimization Manager のアクションをログに記録するポリシーを設定し、ServiceNow ワークフロー内で承認を得るためにアクションを送信できます。

この項では、オーケストレーション ワークフローを自動化ポリシーにリンクする方法について説明します。適切なオーケストレーションのターゲットがすでに設定されていることを前提としています。また、Workload Optimization Manager がワークフローを検出し、それらを自動化ポリシーにマッピングできるように、そのターゲットにワークフローが設定されていることも前提としています。オーケストレーションのターゲットの要件の詳細については、『 Target Configuration Guide 』を参照してください。

注：

一部のオーケストレーションのワークフローでは、特定のメンテナンス期間中にのみアクションを実行するようにスケジュールする必要があります。Workload Optimization Manager のポリシーには、この使用例を有効にするためのスケジュールを含めることができます。ただし、必要なオーケストレーションを宣言するポリシーにはスケジュールを絶対に設定しないでください。その代わりに、同じ範囲に対して 2 つのポリシーを使用する必要があります。1 つはオーケストレーションを設定し、もう 1 つはアクションモードが（メンテナンス期間を設定するために）[自動（Automated）]  になる時間帯をスケジュールします。詳細については、「ポリシー スケジュールの設定（86  ページ）」を参照してください。

アクションスクリプトについて

アクション スクリプトには、別のエントリポイントで Workload Optimization Manager のアクションにカスタム処理を追加できるスクリプト インターフェイスが用意されています。たとえば、Workload Optimization Manager が VM の移動を推奨するたびに E メールを送信するスクリプトを作成したり、Workload Optimization Manager が実行するアクションの代わりに実行するスクリプトを作成したりできます。

アクション スクリプトをリモート マシンに展開し、このアクション スクリプト サーバーと通信するアクション スクリプト ターゲットを構成します。Workload Optimization Manager は、公開されたスクリプトを検出し、オーケストレーション ポリシーでアクションスクリプトを指定するときに選択できるオプションとしてそれらを表示します。

アクション スクリプトの詳細については、「アクション スクリプトの展開 （91  ページ）」を参照してください。

アクションのオーケストレーションの指定

ポリシーを作成する際には、エンティティタイプと、ポリシーが影響を与えるエンティティの範囲を指定します。また、特定のアクションに対してモードも設定できます。たとえば、VM の特定の範囲に対するサイズ変更アクションに [手動（Manual）] モードを設定できます。

1.      [自動化とオーケストレーション（Automation and Orchestration）] を展開して、[アクションの追加（Add Action）] をクリックします。次に、オーケストレーションするアクションタイプを選択します。

デフォルトでは、このアクションのオーケストレーションはありません。次の表では、サポートされているオーケストレーション ワークフローについて説明します。

 

2.      すべての設定を行ったら、必ずアクションポリシーを保存してください。

アクションスクリプトの展開

アクションスクリプトでは、Workload Optimization Manager アクションにカスタム処理を追加できるインターフェイスを利用できます。

アクション スクリプトは、Workload Optimization Manager ターゲットとして構成したリモート サーバ（VM またはコンテナ）で実行されます。そのサーバには、展開したスクリプトと、それらが応答できるエンティティとアクションを識別するマニフェスト ファイルが含まれています。Workload Optimization Manager は、マニフェストを介してこれらのスクリプトを検出し、自動化ポリシーのアクションのオーケストレーション オプションとしてそれらを提示します。

たとえば、次のスクリプトを定義したとします。

■        name: MyVmMoveAction

■        entityType: VIRTUAL_MACHINE

■        actionType: MOVE

この例に従って、API を使用して、VM での移動アクションのポリシーにオーケストレーションを追加できます。そのアクションのスクリプトを定義したので、オーケストレーション タイプとしてアクション スクリプトを指定でき、実行するオーケストレーション ワークフローとして MyVmMoveAction  スクリプトを選択できます。

アクションスクリプトを展開するには、次のことを行います。

■        リモート アクション スクリプト サーバを設定します（「アクション スクリプト サーバの設定（91 ページ）」を参照）

■        リモート サーバで実行可能なアクション スクリプトを作成します（「アクション スクリプトの作成（9 2 ページ）」を参照）

■        リモート サーバでアクション スクリプト マニフェストを展開します（「アクション スクリプト マニフェストの展開（94 ぺージ）」を参照）

アクション スクリプト サーバーの設定

Workload Optimization Manager は、リモートサーバーを使用してアクションスクリプトを実行します。プロセスをリモートで管理することは、Workload Optimization Manager サーバーにカスタムコードをインストールしないことを意味します。これにより、関連するセキュリティリスクが除外されます。ただし、アクション スクリプト サーバーのセキュリティを維持し、カスタムコードの整合性を確保する責任はユーザーにあります。これを実現するには、リモートサーバーの構成が特定の要件を満たす必要があります。

サーバーのリソース要件

リモートサーバーは、VM またはコンテナとすることができます。サーバーに設定するキャパシティは、サーバーで実行するプロセスに完全に依存します。Workload Optimization Manager は、サーバーに特別なリソース要件を課しません。

コマンド実行の設定

スクリプトの実行をサポートするには、スクリプトの実行に必要なソフトウェアをインストールする必要があります。これには、スクリプトが呼び出すライブラリ、言語プロセッサ、またはその他のプロセスが含まれます。

Workload Optimization Manager は、サーバー上のコマンドとしてスクリプトを呼び出します。サーバーは、コマンド実行と SFTP 操作をサポートするように設定した SSH サービスを実行する必要があります。現時点で、シスコは OpenSSH sshd デーモンを使用してアクションスクリプトをテストしています。

SSH の標準ポートは 22 です。別のポートを設定して、サーバをアクション スクリプト ターゲットとして設定する管理者に提供できます。

アクションスクリプトは、リモートサーバーに展開した任意のプロセスを呼び出すことができることに注意してください。スクリプト自体を実行する必要はありません。ただし、コマンドラインからプロセスを呼び出せることが必要です。スクリプトマニフェストは、各スクリプトのコマンドラインの呼び出しを構築するために必要な詳細情報を Workload Optimization Manager に提供します。

アクション スクリプト ユーザー アカウントの構成

サーバーでスクリプトを実行するには、コマンドラインからのスクリプトの実行が許可されているユーザーアカウントを使用して、Workload Optimization Manager がログオンします。アクション スクリプト ターゲットを設定するときに、ユーザーのログイン情報を提供します。このやり取りをサポートするには、ユーザーアカウントが次の要件を満たしている必要があります。

■        公開キー（3Public Key）

ユーザーは、.ssh/authorized_keys  ファイルに公開キーを持っている必要があります。アクション スクリプト ターゲットを構成するときに、これをターゲットのプライベートトークンとして提供します。

■        .ssh  ディレクトリのセキュリティ

アクション スクリプト ユーザーは、アクセスが許可されている唯一のユーザーである必要があります。ファイルのアクセス許可を 600 に設定する必要があります。

■        サポートされているシェル

Action Script ユーザー シェルは、Bourne シェル（通常は /bin/sh にあります）または Bourne-Again シェル（通常は /bin/bash にあります）のいずれかです。Workload Optimization Manager は、スクリプトを呼び出すときにパラメータを渡します。現時点では、これらのシェルを介したスクリプトの実行のみがサポートされています。

アクション スクリプト タイムアウトの処理

Workload Optimization Manager は、スクリプトの実行を 30 分に制限します。スクリプトがこの制限を超えると、Workload Optimization Manager は SIGTERM  を送信してプロセスの実行を終了します。

Workload Optimization Manager は、プロセスを終了する他の試みを行わないことに注意してください。たとえば、SIGTERM  をトラップして実行を継続するスクリプトを実装できます。プロセスは、できるだけ早い安全なタイミングで終了します。ただし、プロセスが終了しない場合は、Workload Optimization Manager の外部でプロセスを終了する何らかの方法を実装する必要があります。暴走したプロセスは、その実行スレッドを使用し続けることに注意してください。これにより、プールにスレッドがなくなった場合、他のプロセス（アクション スクリプトまたはプライマリ プロセス）がブロックされる可能性があります。

アクションスクリプトの作成

アクション スクリプトは、ユーザーがコマンドラインから呼び出せる任意の実行可能ファイルにすることができます。これらの実行可能ファイルはサーバ上の任意の場所に保存できます。マニフェストはファイルへのパスを示します（「アクション スクリプト マニフェストの展開 （94 ページ）」を参照）。スクリプトサーバー用に構成したアクション スクリプト サーバーは、スクリプトファイルへのアクセス権と、読み取りと実行の権限を持っている必要があります。

スクリプトを実行するために、Workload Optimization Manager は、検出したマニフェスト情報から適切な SSH コマンドを構築します。デフォルトで 30 分のタイムアウト制限を付与するか、マニフェスト エントリで別の制限を宣言できます。実行が制限を超えると、Workload Optimization Manager は、SIGTERM  を送信しプロセスを終了させます。

 

アクションスクリプトに情報を渡す

Workload Optimization Manager は、次の 2 つの方法を使用して、アクションに関する情報を関連するアクションスクリプトに渡します。

■        環境変数を介して一般情報を渡す

■        stdin 経由で完全なアクション データを渡す

一般情報をスクリプトに渡すため、Workload Optimization Manager は、アクション スクリプト サーバーで環境変数を設定します。スクリプト内のこれらの環境変数は参照できます。たとえば、アクションのターゲットである VM の名前を含む電子メールを送信するとします。この名前は、 VMT_TARGET_NAME  環境変数を使用して取得できます。

以下のリストは、スクリプトの実行時に Workload Optimization Manager が設定できる環境変数を示しています。これらの変数のすべてがすべてのアクションに適用されるわけではないことに注意してください。たとえば、VMEM をスケーリングするアクションにはプロバイダが含まれないため、アクションには、VMT_CURRENT_INTERNAL, VMT_CURRENT_NAME, VMT_NEW_INTERNAL または VMT_NEW_NAME  変数の値は含まれません。特定の変数が適用されない場合、Workload Optimization Manager はそれを空の文字列に設定します。

■        VMT_ACTION_INTERNAL

提案されたアクションの UUID。これを使用して、REST API を介してアクションにアクセスできます。たとえば、スクリプトは独自の基準に従ってアクションを承認したりキャンセルしたりできます。

■        VMT_ACTION_NAME

アクションの名前。

■        VMT_CURRENT_INTERNAL

現在のプロバイダーの内部名。

■        VMT_CURRENT_NAME

現在のプロバイダーの表示名。

■        VMT_NEW_INTERNAL

新しいプロバイダーの内部名。

■        VMT_NEW_NAME

新しいプロバイダーの表示名。

■        VMT_TARGET_INTERNAL

このアクションによって影響を受けるエンティティの内部名。これを使用して、REST API を介してターゲット エンティティにアクセスできます。たとえば、履歴統計を取得したり、エンティティの設定を変更したりできます。

■        VMT_TARGET_NAME

このアクションによって影響を受けるエンティティの表示名。

■        VMT_TARGET_UUID

このアクションによって影響を受けるエンティティの UUID。

一部のスクリプトでは、関連するアクションの完全な説明が必要な場合があります。たとえば、特定のリソースの使用率メトリックを分析するとします。一般情報を渡すための環境変数には、この情報は含まれません。

アクション スクリプトを呼び出すと、Workload Optimization Manager は、関連するアクションの完全なデータを stdin 経由で渡します。スクリプトはこれを変数にロードして、必要な特定のデータにアクセスできます。たとえば、以下は stdin  を myActionData にロードします。

 

myActionData=$(cat -)

 

stdin には、このアクションに関連付けられた完全なデータを表す JSON 文字列が含まれています。たとえば、myActionData 変数には、次のような文字列を含めることができます。

 

{"actionType":"RIGHT_SIZE","actionItem":[{"actionType":"RIGHT_SIZE","uuid":"143688943343760","targetS E":{"entityType":"VIRTUAL_MACHINE","id":"4200fcdb-eafe-2a4a-abf5-a7ad2b00555c"...

 

 

 

アクション スクリプト マニフェストの展開

アクション スクリプト マニフェストは、Workload Optimization Manager に公開するスクリプトを識別します。アクション スクリプト ターゲット構成の一部としてマニフェストの場所を指定します。Workload Optimization Manager がターゲットを検証した後、これらのスクリプトを検出し、オーケストレーション ポリシー ユーザーインターフェイスに表示します。

スクリプト マニフェスト ファイルの作成

スクリプト マニフェストとは、公開するスクリプトごとにスクリプト オブジェクトの配列を宣言するファイルです。マニフェストは、JSON または YAML ファイルとして作成できます。

たとえば、次の 2 つの同じマニフェストの例では、1 つが YAML で、もう 1 つは JSON です。いずれの場合も、マニフェストは 2 つのスクリプトオブジェクトの配列であることに注意してください。

■        YAML マニフェスト：

 

scripts:

-  name: MyVmMovePrep

description: Execute this script in preperation to a VM Move

scriptPath: vmScripts/movePrep.sh

entityType: VIRTUAL_MACHINE

actionType: MOVE

actionPhase: PRE

-  name: MyVmSuspendReplace

description: Execute this instead of a VM Suspend action

scriptPath: vmScripts/suspendReplace.sh

entityType: VIRTUAL_MACHINE

actionType: SUSPEND

actionPhase: REPLACE

 

■        JSON マニフェスト：

 

{

"scripts": [

{

"name": "MyVmMovePrep",

"description": "Execute this script in preperation to a VM Move",

"scriptPath": "vmScripts/movePrep.sh",

"entityType": "VIRTUAL_MACHINE",

"actionType": "MOVE",

"actionPhase": "PRE"

},

{

"name": "MyVmSuspendReplace",

"description": "Execute this instead of a VM Suspend action",

"scriptPath": "vmScripts/suspendReplace.sh",

"entityType": "VIRTUAL_MACHINE",

"actionType": "SUSPEND",

"actionPhase": "REPLACE"

}

]

}

 

 

 

スクリプト マニフェスト ファイルは、サーバー上の任意の場所に保存できます。ただし、スクリプトユーザーがその場所にアクセスでき、読み取りと実行の権限を持っている必要があります。この場所をスクリプトパスとして指定します。スクリプトパスは、Workload Optimization Manager がアクション スクリプト ターゲット構成の一部として指定します。

マニフェストのファイル名拡張子は、ファイル形式（YAML または JSON）と一致する必要があることに注意してください。たとえば、ファイルにはそれぞれ MyManifest.yaml  または MyManifest.json という名前を付ける必要があります。

スクリプトオブジェクトの宣言

マニフェストの各スクリプトオブジェクトには、次のフィールドを含めることができます。

■        name

必須 – このアクションスクリプトの名前。Workload Optimization Manager がスクリプトを検出すると、オーケストレーション ポリシーを作成するためのユーザー インターフェイスで、オーケストレーション ワークフローの選択肢としてこの名前が表示されます。

■        説明

オプション – スクリプトの説明。Workload Optimization Manager のユーザーインターフェイスには、この説明は表示されません。

■        scriptPath

必須 – このエントリの実行可能なファイルへのパス。絶対パス、またはスクリプト マニフェストの場所に関連のあるパスを指定できます。アクション スクリプト サーバー用に設定するアクション スクリプト ユーザーは、実行可能なファイルの読み取りおよび実行権限を持っている必要があります。

■        entityType

必須 – このスクリプトが応答するエンティティのタイプ。次のいずれかになります。

–       スイッチ

–       VIRTUAL_DATACENTER

–       ストレージ

–       DATABASE_SERVER

–       WEB_SERVER

–       VIRTUAL_MACHINE

–       DISK_ARRAY

–       DATA_CENTER

–       PHYSICAL_MACHINE

–       シャーシ

–       STORAGE_CONTROLLER

–       IO_MODULE; IO モジュール

–       APPLICATION_SERVER

–       アプリケーション

–       CONTAINeR

–       CONTAINER_POD

–       LOGICAL_POOL

–       STORAGE_VOLUME

–       DPOD

–       VPOD

–       データベース

–       LOAD_BALANCER

異なるエンティティタイプのアクションに応答するように同じスクリプトを構成するには、エンティティタイプごとに 1 つずつ、そのスクリプトの個別のエントリを宣言します。

■        actionType

必須 – このスクリプトが応答するアクションのタイプ。異なるエンティティタイプが異なるアクションをサポートできることに注意してください。次のいずれかになります。

–       START

–       MOVE

–       SCALE

クラウドでサイズ変更 — ワークロードを 1 つのクラウドテンプレートまたは階層から別のクラウドに移動します。

–       SUSPEND

–       PROVISION

–       RECONFIGURE

–       RESIZE

–       DELETE

–       RIGHT_SIZE

–       ACTIVATE

–       DEACTIVATE

–       BUY_RI

■        actionPhase

必須 – スクリプトを実行するアクションのライフ サイクル内の場所。

次のいずれかになります。

–       PRE

承認されたアクション、または実行前の AUTOMATED アクションの場合、この状態は、アクション自体が実行される直前にスクリプトを実行できる準備フェーズです。

スクリプトを実行して、アクションが実行される直前に条件を設定します。

–       REPLACE

アクションの実行の場合、Workload Optimization Manager が実行する代わりにスクリプトが実行されます。

Workload Optimization Manager アクションの代わりにスクリプトを実行します。

–       POST

アクションは、SUCCEEDED、FAILING、または FAILED 状態のいずれかで実行を完了しました。

FAILING は、アクションの実行が失敗した後、POST スクリプトの実行が完了する前にステータスがチェックされたことを意味します。

アクションの実行が完了したら、スクリプトを実行します。

■        timeLimitSeconds

オプション – タイムアウトの想定前にアクションを実行する時間。実行が制限を超えると、Workload Optimization Manager は、SIGTERM   を送信し実行プロセスを終了させます。

値を指定しない場合、Workload Optimization Manager は、制限を 30 分（1800 秒）にします。

ウェブフック

Workload Optimization Manager で自動化ポリシーを構成して、ウェブフックを介して外部 Web サーバにデータを送信できます。ウェブフックは、Workload Optimization Manager が外部アプリケーションにデータを送信するために使用できる自動化されたメッセージです。ウェブフックでできることは次のとおりです。

■        Slack などのコラボレーション プラットフォームに通知を送信する

■        Workload Optimization Manager とワークフロー管理システムの統合

■        独自のロジックで Workload Optimization Manager のアクションをオーバーライドする

このリリースの Workload Optimization Manager では、ウェブフックの実装で HTTP メッセージングがサポートされています。さらに、ウェブフックを導入するには、ワークフローを作成します。このリリースでは、Workload Optimization Manager API を介してワークフローを作成します。

Webhook を設定するには、次のことを行います。

■        ウェブフックを受信するアプリケーションを特定する

可能なアプリケーションには、Slack などのコラボレーション プラットフォーム、ServiceNow などのオーケストレーション プラットフォーム、クラウドプロバイダ API が含まれます。また、HTTP メソッドに応答するカスタム アプリケーションを作成することもできます。

■        Workload Optimization Manager インスタンスでウェブフック ワークフローを作成する

このバージョンの Workload Optimization Manager では、API を介してウェブフック ワークフローを定義します。

ウェブフック定義には、次のものを含めることができます。

–       ウェブフックを送信するアプリケーションの URL

–       HTTP メソッド

–       ウェブフック ペイロードのテンプレート

–       アプリケーションにアクセスするための認証ログイン情報

ウェブフック ワークフローの作成の詳細については、「ウェブフック ワークフローの作成（97  ページ）」を参照してください。

■        ウェブフックを使用する自動化ポリシーを作成する

自動化ポリシーには、特定のアクションに対してウェブフックの実行を選択できるオーケストレーション設定が含まれています。Workload Optimization Manager は、アクションの作成時、アクションの実行前、アクションの実行前、およびアクションの実行後にウェブフックを実行できます。

オーケストレーションにウェブフック ワークフローを使用するポリシーの作成については、「アクション オーケストレーション（88  ページ ）」を参照してください。

ウェブフックを設定した後、Workload Optimization Manager がポリシーで指定したアクションを生成または実行すると、ウェブフックで指定した URL にメッセージが送信されます。

ウェブフック ワークフローの作成

ウェブフックを実装するには、HTTP URL、HTTP メソッド、ペイロード テンプレートなどのパラメータを指定するワークフローを作成します。その後、自動化ポリシーでこのワークフローを使用して、アクションの実行方法を調整できます。

ワークフローを作成するには、API を使用してワークフロー オブジェクトを Workload Optimization Manager インスタンスに POST します。たとえば、次の curl  コマンドは、Workload Optimization Manager サーバにアクセスするための承認を取得してから、そのサーバーに単純なウェブフック ワークフローを追加します。

■        サーバでの認証

このコマンドは、認証ログイン情報を要求し、後続の curl ヘッダーの Cookie に設定できる変数にそれらを保存します。ここで、

–       <T8c_IP_ADDRESS> は、Workload Optimization Manager サーバのアドレスです

–       <ADMIN_ACCOUNT_NAME> は、管理者権限を持つアカウントの名前です

–       <ADMIN_PWD> は管理者アカウントのパスワードです

 

JSESSIONID=$(curl \

--silent \

--cookie-jar - \

--insecure \ https://<T8c_IP_ADDRESS>/vmturbo/rest/login \

--data "username=<ADMIN_ACCOUNT_NAME>&password=<ADMIN_PWD>" \

| awk '/JSESSIONID/{print $7}')

■        ワークフローの作成

このコマンドは、サーバ上にワークフローを作成します。ここで、

–       <T8c_IP_ADDRESS> は、Workload Optimization Manager サーバのアドレスです

–       <WEBHOOK_ADDRESS> は、ウェブフック サーバのアドレスです

 

curl \

"https://<T8c_IP_ADDRESS>/api/v3/workflows" \

--insecure \

--compressed \

--header 'Accept: application/json' \

--header 'Content-Type: application/json' \

--header "cookie: JSESSIONID=$JSESSIONID" \

--request POST \

--data '

{

 

"displayName": "My_WebHook",

"className": "Workflow",

"description": "First webhook attempt.",

"discoveredBy":

{

"readonly": false

},

"type": "WEBHOOK",

"typeSpecificDetails": {

"url": "http://<WEBHOOK_ADDRESS>",

"method": "POST",

"template": "My Webhook Template -- DATA: Action Details: $action.details",

"type": "WebhookApiDTO"

}

}

'

これは、指定された URL にテンプレートを送信する単純なウェブフックです。ワークフローで設定できるパラメータのリストについては、「WebhookApiDTO」（99  ページ）を参照するか、Workload Optimization Manager API のドキュメントを参照してください。

テンプレート ペイロードは、文字列 My Webhook Template -- DATA: Action Details: と、アクションのデータ オブジェクトに含まれるアクションの詳細です。変数 $action.details  は、現在のアクションを表す ActionApiDTO  オブジェクトのフィールドへの参照です。テンプレートは、オブジェクト名としての action から始めて、この DTO の任意のフィールドを参照できます。たとえば、$action.createTime  は、アクションが作成された時刻を示します。ActionApiDTO  オブジェクトの完全なリストについては、Workload Optimization Manager API ガイドを参照するか、API Swagger UI を参照してください。

サンプル ウェブフック アプリケーション

ウェブフック ワークフローは、HTTP 経由でアプリケーションにメッセージを送信します。ペイロードにアクション データからの値を含めることができるテンプレートとしてメッセージを表現します。このテンプレートは、アプリケーションが受け入れることができるテキスト、JSON、またはその他のペイロードを表現できます。

ウェブフック を使用して、IBM CP4Integration、IBM CP4WatsonAIOps、Slack、Amazon Web Services など、多数の既存のアプリケーションにメッセージを送信できます。

簡単な例を展開してウェブフック テンプレートをテストするために、ウェブフック メッセージを受信してテンプレート データを出力する node.js サーバを実装できます。このサーバをネットワーク内のマシンにインストールすると、ウェブフック ワークフローでその URL を指定して、特定のアクションに対する応答をテストできます。

以下は、使用できる node.js Web サーバのリストです。

 

let port = 9090;

const http = require("http");

console.log(`Starting server on port ${port}`);

 

http.createServer((request, response) => {

request.setEncoding('utf8');

console.log('REQUEST METHOD: ', request.method);

 

let datStr = '';

request.on('data', chunk => {datStr = datStr + chunk});

request.on('end', () => {console.log('End of DATA: ', datStr)})

}).listen(port);

 

このプログラムを実行すると、実行中であることを示し、リッスンしているポートを識別するメッセージがコンソールに出力されます。

サーバはメッセージを受信すると、ワークフローのテンプレート  フィールドで指定されているように、リクエスト メソッドを出力し、メッセージ ペイロードを出力します。

このワークフローを使用するように自動化ポリシーを構成した場合、このサーバは、Workload Optimization Manager がポリシーのスコープ内のエンティティに対して実行する各アクションのメッセージをログに記録します。

WebhookApiDTO

WebhookApiDTO は WorkflowAspect から継承します

必須パラメータ：

メソッド

■      type: string

■      description: リクエストを作成するために使用される Http メソッド。

■      enum: ['GET', 'POST', 'PUT', 'DELETE', 'PATCH']

url

■      type: string

■      description: HTTP リクエストが行われる URL。

オプション パラメータ：

テンプレート

■      type: string

■      description: リクエストの本文のテンプレート。

authenticationMethod

■      type: string

■      description: リクエストに使用する認証方法。

■      enum: ['NONE', 'BASIC', 'OAUTH']

username

■      type: string

■      description: 認証済みリクエストのユーザー名。

password

■      type: string

■      description: 認証済みリクエストのパスワード。

trustSelfSignedCertificates

■      type: boolean

■      description: true の場合、HTTPS 接続の使用時に自己署名証明書が信頼されます。デフォルトは false です。

headers

■      type: array

■      description: リクエスト ヘッダー

oauthData

■      type: object

■      description: oAuth データを定義するモデル。

必須パラメータ：

–       clientId: string oAuth 認証に使用されるクライアント ID。

–       clientSecret: string oAuth 認証に使用されるクライアントシークレット ID。

–       authorizationServerUrl: string 承認サーバの URL。

–       grantType: enum ["CLIENT_CREDENTIALS"]

オプション パラメータ：

–       scope: string oAuth 範囲。

 

 

制約とその他の設定

Workload Optimization Manager は、環境のアクションを計算するときに使用する分析を促進するメトリックを収集します。リソースに割り当てられたキャパシティに対する現在の使用率と要求を比較して、環境を最適な実行状態に維持するアクションを推奨します。

アクションポリシーには、制約と Workload Optimization Manager が実行する分析を調整するその他設定が含まれます。たとえば、ホストまたは VM リソースに異なるレベルのオーバープロビジョニングを設定でき、Workload Optimization Manager はその設定をアクションを決定する際の要因として考慮します。

Workload Optimization Manager には、ポリシーごとに作成できるすべての制約と設定を示すデフォルトポリシーが付属しています。これらは、異なるア提供でポリシーを作成・適用するまで有効です。新しいポリシーを作成する手順については、「範囲を指定した自動化ポリシーの作成（78 ページ ）」を参照してください。グローバルに分析を変更する場合は、デフォルトを編集します。