Workload Optimization Manager 3.6.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 番号は当社の Web サイト（www.cisco.com/go/offices）をご覧ください。

Cisco および Cisco のロゴは、米国およびその他の国における Cisco およびその関係会社の登録商標を示します。シスコの商標の一覧については、https://www.cisco.com/c/en/us/about/legal/trademarks.html をご覧ください。記載されているサードパーティの商標は、それぞれの所有者に帰属します。「パートナー」という言葉が使用されていても、シスコと他社の間にパートナーシップ関係が存在することを意味するものではありません。（1721R）

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

最新情報

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

バージョン 3.6.0

この四半期ごとのリリースには、次の新機能と改善が含まれています。

コンテナ リソース管理

■      226Migrate Container Workloads 計画

このリリースでは、Migrate Container Workloads と呼ばれる新しいプラン タイプが導入されています。この計画を実行して、あるクラスターから別のクラスタへのコンテナー ワークロードの移行をシミュレートします。この計画は、「リフト アンド シフトのみ」シナリオの結果を、Workload Optimization Managerの最適化計画と比較します。この結果は、新しいクラスタでワークロードのパフォーマンスを維持および最適化するために必要なアクションをさらに強調しています。

■      ノード再構成アクション

Kubernetes 環境の場合、Workload Optimization Manager は再構成アクションを生成して、現在 NotReady 状態にあるノードを通知できるようになりました。ノードの状態が解決され、状態が Ready に変わると、Workload Optimization Manager は、ノードと関連するコンテナ ポッドの正常性のモニタリングを開始できます。

詳細については、ノード再構成アクション（ページ147）を参照してください。

■      不明なコンテナ Pod の可視性

ノードが NotReady 状態の場合、関連するコンテナ Pod は Unknown 状態になります。これらのポッドは、他のポッドと区別しやすいように、ユーザー インターフェイスで灰色で表示されるようになりました。さらに、検索を使用するかグループを作成するときに、Unknown 状態をコンテナ ポッド フィルタとして使用できるようになりました。

■      改善点

–      Workload Optimization Manager は、ノードをプロビジョニングまたは一時停止する目的で、静的 Pod を DaemonSet として扱うようになりました。静的ポッドはノードに特定の機能を提供するため、コントロール プレーンではなくノードによって制御されます。

•      プロビジョニングされるノードに静的ポッドが必要な場合、Workload Optimization Manager は、ノードと対応する静的ポッドをプロビジョニングするためのアクションを生成します。

•      ノードに残っている唯一のワークロード タイプが静的 Pod である場合、Workload Optimization Manager は、ノードと対応する静的 Pod を一時停止するアクションを生成します。

–      このリリースでは、メモリ不足（OOM）の問題を防ぐために、Kubeturbo に次のメモリ使用量の最適化が導入されています。

•      Go 1.19 で導入された新しいガベージ コレクタ メカニズムを利用して、ガベージ コレクションを積極的にトリガします。

•      Kubernetes API 呼び出しのページ ネーションを有効にして、大きな結果セットをチャンクで反復できるようにします。ページ サイズは、クラスター サイズと Kubeturbo のメモリ制限に基づいて動的に計算されるようになりました。

–      以前のリリースでは、アクティビティが検出されなかった場合、デフォルトのロード バランサは 60 秒後にタイムアウトしていました。サーバーとの安全な WebSocket 通信を確立した後、ハートビートが送信されるまでに 1 分以上かかることがあったため、これは Kubeturbo にとって課題でした。このリリースから、Kubeturbo からサーバへの通信ハートビートが 30 秒に構成されるようになりました。

クラウド リソース管理

■      Azure App Service の最適化

Workload Optimization Manager は、プロビジョニングされた Azure アプリ サービスプランをスケーリングしてアプリケーションのパフォーマンスを最適化するか、空のプランを削除してクラウドの支出を削減するためのアクションを推奨できるようになりました。スケール アクションの場合、Workload Optimization Manager はパーセンタイル計算を使用してアプリケーションの需要をより正確に測定し、可能な限り低いコストで需要を満たすことができるインスタンス タイプを選択します。

詳細については、『ターゲット構成ガイド』の Azure アプリ サービスのサポートを参照してください。

オンプレミス リソース管理

■      改善点

–      vCenter ゲスト メトリックの検出がデフォルトで有効になったため、Workload Optimization Manager は、OS レベルで（VMware ツールを介して）VM メモリ使用量データを収集します。これは、ハイパーバイザによって報告されるアクティブ メモリ データよりも正確です。OS によって報告される vMem 使用量の値は、ハイパーバイザによって報告される値よりもほとんどの場合高いため、vMem アクションのサイズ変更がより頻繁に行われることに気付く場合があります。

–      Workload Optimization Manager は、vCenter データストアがメンテナンス モードであることを検出すると、VM ストレージをそのデータストアに移動するための推奨アクションを停止します。

ユーザー インターフェイス管理

■      新規エンティティ フィルタ

検索を使用するか、グループを作成するときに、次のフィルタを使用できるようになりました。

■      改善点

–      複数のリソースのグラフに、「過去 60 日間」の時間枠が含まれるようになりました。

–      Workload Optimization Manager インスタンスが多数のターゲットを管理している場合、ターゲット構成ページがロードされるまでに数分かかることがあります。この改善により、ページは数秒以内に読み込まれるようになりました。

–      Workload Optimization Manager インスタンスが多数のクラウド アカウントを監視し、スコープをグローバル クラウド環境に設定した場合、Top Accounts チャートが読み込まれるまでに数分かかることがあります。この改善により、チャートは数秒以内に読み込まれるようになりました。

製品概要

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 の操作を理解しておく必要があります。ポリシーの詳細については、「ポリシーの使用（70 ページ）を参照してください。

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 など）

–      Red Hat 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

■      ハイパーバイザ

–      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+

■      オーケストレータ

–      ActionScript

–      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）

–      GCP の請求

–      Microsoft Azure Service Principal

–      Azure の課金について

–      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 +

–      HPE 3PAR InForm OS 3.2.2+, 3PAR SMI-S, 3PAR WSAPI

–      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 はターゲットサーバー（ハイパーバイザ、クラウド管理スタック、パブリック クラウド アカウントなど）から 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 は、パブリック クラウドの順応性を活用するためのより関連性の高いアクションを推奨できます。

次の表で、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.      アカウントのユーザー名とパスワードを入力します。

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

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

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

ホームページ

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

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

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

–      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）] アイコンをクリックするとホーム ページに戻ることができます。

アプリケーションビュー

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

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

注：

特定のアプリケーション エンティティが何らかの理由でサプライチェーン インフラストラクチャに組み込まれない場合、Workload Optimization Manager はそれらをオンプレミスビューとクラウドビューの両方に表示します。Workload Optimization Manager がそれらをインフラストラクチャに組み込むことができたら、インフラストラクチャのクラスに従ってそれらを分類し、正しいビューに表示します。

ON-PREM ビュー

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

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

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

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

■      上位クラスタ使用率

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

■      最適化された改善

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

■      アクション履歴

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

CLOUD ビュー

セッションを [グローバル範囲（Global Scope）] に設定すると [クラウド（CLOUD）] ビューを選択できます。このビューには、クラウド環境の概要が表示されます。すべてのワークロードがパブリック クラウド上にある場合は、ワークロードの開始点としてこれを使用する必要があります。

Optimization Manager セッション。ハイブリッド環境（オンプレミスおよびパブリッククラウド上）の場合は、このビューを参照して、クラウドの詳細な概要を確認できます。

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

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

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

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

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

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

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

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

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

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

■      サービス別請求額

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

クラウドコストの追跡

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

サービスのコスト

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 エンタープライズ アグリーメント（416 ページ）を参照してください。

■      IP

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

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 インスタンスの要件（156 ページ）

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

割引

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

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

■      Azure 予約

■      GCP の確約利用割引

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

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

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

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

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

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

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

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

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

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

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

注：

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

現在、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 アプリ サービスは、アプリをホストするための HTTP ベースのサービスです。Azure アプリ サービスを使用すると、アプリ開発者はエンタープライズ対応アプリを簡単に作成し、拡張できて信頼性の高いクラウド インフラストラクチャに展開できます。

Azure App Service には、Web アプリ、モバイル アプリ、API アプリ、ロジック アプリなど、いくつかの種類のアプリが用意されています。各アプリは一連のアプリ インスタンスとして実行され、アプリで使用できるコンピューティング 情報技術 (CPU、メモリ、ストレージ) を定義するプランに関連付けられています。

Azure アカウントを追加する場合：

■      Workload Optimization Manager は、アプリ サービス環境 v3 I4、I5、および I6 を除く、そのアカウント内のすべてのプランを検出します。計画は、サプライ チェーンで「仮想マシンの仕様」として表示されます。

■      Web アプリに関連付けられたプランの場合、ワークロード 最適化マネージャは、関連するアプリ インスタンスを検出します。サプライ チェーンでは、アプリ インスタンスは「アプリ コンポーネント仕様」として表示されます。Workload Optimization Manager は、これらの計画をスケーリングしてアプリのパフォーマンスを最適化するためのアクションを生成します。

■      他のタイプのアプリに関連付けられたプランの場合、Workload Optimization Manager は、スケール アクションを生成したり、関連するアプリ インスタンスを検出したりしません。

■      どのタイプのアプリにも関連付けられていないプランの場合、Workload Optimization Manager は、コスト削減手段として削除アクションを生成します。

スケールおよび削除アクションの詳細については、仮想マシンの仕様『173ページ』を参照してください。

プランとアプリ インスタンスを検出するには、実行するすべてのアクションをサポートするためのアクセス許可を提供する必要があります。アクセス許可の一覧については、『ターゲット構成ガイド』の「Azure サービスプリンシパルとサブスクリプションのアクセス許可」を参照してください。

ターゲットの設定

ターゲットは、仮想環境で管理を実行するサービスです。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）] を表示すると、選択したビューに応じて、サプライ チェーンによって表示がフィルタ処理されます。

■      アプリケーション – すべてのビジネスアプリケーション（102 ページ）

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

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

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

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

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

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

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

ユーザーができること

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

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

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

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 つ以上のエントリを選択し、[ホームページ（Home Page）]のフォーカスを設定します。

リストを制限するエンティティのカテゴリを選択した場合は、セッション範囲に対して 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 ページ）を参照してください

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

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

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

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

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

■      範囲を設定する

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

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

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

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

詳細ビュー

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

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

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

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

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

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

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

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

■      範囲を設定する

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

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

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

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

範囲ポリシー

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

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

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

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

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

単一のエンティティにドリルダウンすると、サプライチェーン内のエンティティの関係に関する詳細を確認できます。これにより、どのエンティティがこのエンティティにリソースを提供するかが表示されます。このエンティティのプロバイダを検討すると、現在の各プロバイダの名前を確認できます。

プロバイダ、および現在のプロバイダが過剰に使用された場合に 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）] を選択すると、現在の範囲内のホストのリストが表示されます。詳細については、サプライ チェーンを使用した移動（44 ページ）を参照してください

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

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 テンプレートに基づく近似値となります。

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

Workload Optimization Manager のアクション

ターゲットを展開すると、Workload Optimization Manager は、そのアプリケーションリソース管理プロセスの一環として、マーケット分析の実行を開始します。この包括的な分析では、環境内の問題と、実行できるアクションを特定します。

これらの問題を解決して回避します。Workload Optimization Manager は、その特定の分析に対する一連のアクションを生成し、調査できるように [Pending Actions] チャートにそのアクションを表示します。

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

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

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

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

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

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

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

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

アクションタイプ

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

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

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

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

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

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

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

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

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

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

配置

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

配置の制約

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

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

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

実効 CPU 容量

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

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

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

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

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

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

Cross-vCenter vMotion

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

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