このドキュメントでは、Workload Optimization Manager 3.1.0 –リリース日：2021 年 8 月 26 日で対応した問題について説明します。3.0 バージョン ファミリ以降、ビルドは累積的です。以前のバージョンのリリースノートについては、Workload Optimization Manager のドキュメントを参照してください。

ご不明な点は、サポートまでお問い合わせください。

Workload Optimization Manager の Kubernetes ターゲットの構成

Workload Optimization Manager の Kubernetes ターゲットを設定するには、特定の構成リソースを使用して Kubeturbo ポッドを展開します。これらのリソースには、TURBONOMIC_SERVER_VERSION にマップされたバージョンの Workload Optimization Manager が必要です。次の表を使用して、Workload Optimization Manager のバージョンをマップします：

Kubeturbo ポッドの構成方法の詳細については、https://github.com/turbonomic/kubeturbo にある Kubeturbo github リポジトリを参照してください。

Kubeturbo ターゲットと他のターゲットの詳細については、『Workload Optimization Manager Target Configuration Guide』を参照してください。

バージョン 3.1.0 の新機能については、 『Workload Optimization Manager User Guide』を参照してください。

このリリースの Workload Optimization Manager では、以下の構成要件を満たす必要があります。

サポートされている MariaDB バージョン

デフォルトの履歴データベースで、Workload Optimization Manager は現在、MariaDB バージョン 10.5.9 をサポートしています。このサポートには、Workload Optimization Manager による履歴データベースの使用に関する包括的なテストと品質管理が含まれます。

OVAとしてインストールされた Workload Optimization Manager を実行しており、その OVA インストールに含まれているデータベースを使用している場合は、バージョン 10.5.9 を使用する必要があります。バージョン 8.0.6 より前に OVA としてインストールした Workload Optimization Manager のバージョンでは、MariaDB を更新する必要がある可能性があります。

MariaDB インスタンスの更新については、 『Workload Optimization Manager Installation Guide』の最新バージョンの「Verifying your MariaDB Version」を参照してください。

必要な DB 容量

Workload Optimization Manager 8.0.6 以降では、履歴データベースに特定のストレージサイズ容量が必要です。MariaDB または MySQL をインストールする場合は、データベースが必要なメッセージングおよびロギング容量を提供していることを確認する必要があります。

Workload Optimization Manager を OVA としてインストールし、付属の MariaDB を履歴データベースに使用する場合は、Workload Optimization Manager をバージョン 8.0.7 以降に更新するのが最も簡単な方法です。詳細については、最新バージョンの 『Workload Optimization Manager Installation Guide』の「Incrancing your Database Capacities」を参照してください。

外部データベースのSQLモード

含まれている履歴データベースではなく外部データベースを使用するように Workload Optimization Manager を展開する場合は、データベースの正しい SQL モードを指定する必要があります。次をサポートするようにデータベースを設定します。

{{ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION}}

特に、SQL モードに ONLY_FULL_GROUP_BY、NO_ZERO_IN_DATE、またはNO_ZERO_DATE を含めることはできません。

トランスポート層のセキュリティ要件

Workload Optimization Manager では、ターゲットとのセキュアな通信を確立するために Transport Layer Security（TLS）バージョン 1.2 が必要です。ほとんどのターゲットでは、TLS 1.2 が有効になっていることが必要です。ただし、一部のターゲットでは TLS が有効になっていない場合や、以前のバージョンが有効になっている場合があります。この場合、Workload Optimization Manager がターゲット サービスに接続しようとすると、ハンドシェイク エラーが表示されます。[ターゲット設定（Target Configuration）] ビューに移動すると、そのようなターゲットの検証失敗ステータスが表示されます。

特に、NetApp ファイラはデフォルトで TLS が無効になっている場合が多いこと、そしてサポートしている最新バージョンは TLS 1.0 であることがわかっています。NetApp ターゲットの検証に失敗した場合は、これが原因である可能性があります。

TLS のサポートが原因でターゲットの検証が失敗した場合は、次のような文字列により検証エラーが表示されることがあります。

• 適切なプロトコルがありません（No appropriate protocol）

  このエラーを修正するには、ターゲット テクノロジーがサポートする TLS の最新バージョンを有効にしてください。これで問題が解決しない場合は、テクニカル サポートにお問い合わせください。

• 証明書がアルゴリズムの制約に準拠していません（Certificates does not conform to algorithm constraints）

  このエラーを修正するには、ターゲット テクノロジーのマニュアル (たとえば NetApp のマニュアル) を参照して、ターゲット サーバで 1024 以上の長さの証明書キーを生成する手順に従ってください。これで問題が解決しない場合は、シスコ テクニカル サポートにお問い合わせください。

• 修正済みの問題:

  クラウド環境のまれな状況では、分析によってアクションの生成が停止することがあります。

• まれに、アクションの生成が停止し、ログに次のエラーが表示されることがあります。

  注意!!：分析のためにコスト通知の受信に失敗しました ...

• 修正済みの問題:

  まれに、環境内のエンティティの履歴データが失われることがあります。

  まれに、エンティティ ID の管理に障害が発生すると、履歴データが失われることがあります。

• ファイアウォール設定の AWS ターゲット ドキュメントが不完全です。

  『Target Configuration Guide』の「AWS target configuration」の項に、ファイアウォールまたはプロキシの背後で Workload Optimization Manager を実行する場合に設定する必要がある外部アクセスが記載されています。ただし、このリストは不完全です。アクセスを設定する必要がある URL の正しいリストは次のとおりです。

  • 自動スケーリング

    autoscaling.{region-id}.amazonaws.com

  • AWS 請求

    {bucket-name}.s3.{region-containing-report}.amazonaws.com

  • CloudWatch

    monitoring.{region-id}.amazonaws.com

  • CloudWatch イベント

    events.{region-id}.amazonaws.com

  • CloudWatch ログ

    logs.{region-id}.amazonaws.com

  • Cost Explorer

    ce.us-east-1.amazonaws.com

  • EC2

    ec2.{region-id}.amazonaws.com

  • Elastic Load Balancing

    elasticloadbalancing.{region-id}.amazonaws.com

  • IAM

    iam.amazonaws.com

  • 組織

    organizations.{region-id}.amazonaws.com

  • パフォーマンスに関するインサイト。

    pi.{region-id}.amazonaws.com

  • 価格表

    pricing.us-east-1.amazonaws.com

  • リレーショナル データベース サービス（RDS）

    rds.{region-id}.amazonaws.com

  • リソース グループ

    resource-groups.{region-id}.amazonaws.com

  • 節約プラン（オプション：環境で節約プランを使用する場合は必須）

    Savingplans.amazonaws.com

  • サービス カタログ（Service Catalog）

    servicecatalog.{region-id}.amazonaws.com

  • S3

    s3.{region-id}.amazonaws.com

  • ストレージ ゲートウェイ

    storagegateway.{region-id}.amazonaws.com

  • 特定のインストール設定では、オンライン更新に予想よりも長い時間がかかることがあります。

    Workload Optimization Manager をファイアウォールの背後にインストールし、Workload Optimization Manager を提供する Docker Hub サービス用のポートを開いている場合、スクリプト onlineUpgrade.sh が完了するまでに 30〜45 分かかることがあります。更新の実行に問題がある場合は、サポート担当者までお問い合わせください。

  • プラットフォームを更新した後、Embedded Reports が表示されないことがあります。

    状況によっては、Workload Optimization Manager を新しいバージョンに更新した後、[組み込みレポート（Embedded Reports）] ページが表示されないことがあります。更新は正常に完了したように見えますが、Embedded Reports コンポーネントは実行中で、準備ができているように見えます。ただし、[Embedded Reports] ボタンをクリックすると、次のエラーが表示されます。

    failed to log in as user, specified in auth proxy header.

    これは、ホスト VM がすべてのプラットフォーム コンポーネントを完全に起動するのに時間がかかる場合に発生する可能性があります。この問題が発生した場合は、すべてのコンポーネントが実行されていることを確認してから、次のコマンドを実行して grafana ポッドを再起動します。

    kubectl delete pod -l app=grafana

    サポートについては、サポート担当者にお問い合わせください。

  • ファブリック環境では、ビューをデータセンターにスコープすると、サプライ チェーンに関連するすべてのホスト エンティティが含まれない場合があります。

    ファブリック ターゲットを含む環境では、状況によっては、データセンターを対象とするビューに、関連するすべてのホスト エンティティが含まれない場合があります。これは、ホスト名にハイフン文字（「-」）を含むホストで発生する可能性があります。たとえば、Cisco UCS ターゲットの場合、データセンター エンティティにスコープを設定すると、サプライチェーンは UCS ホスト（名前にハイフン文字を使用）を表示しません。

  • Azure の場合、状況によっては、成功したスケーリング アクションが失敗としてログに表示されます。

    可用性セットを含むAzure環境では、一部の状況では、成功したスケーリング アクションが失敗として Workload Optimization Manager ログに表示されます。

  • 実行済みアクション チャートでは、環境から削除されたエンティティに対するアクションの一部のデータが欠落しています。

    実行済みアクション チャートを表示したり、チャートからデータをエクスポートしたりすると、環境から削除されたエンティティに対するアクションの一部のデータが失われます。たとえば、ストレージ ボリュームでアクションが実行され、そのボリュームが後で環境から削除されたとします。その場合、そのアクションのエクスポートされたデータには、削除されたボリュームを説明する値は含まれません。

  • 特定のクラウド階層を除外するポリシーの場合、クラウド プロバイダーが新しい階層を追加すると、ポリシーに含まれているように表示されます。

    パブリック クラウド環境では、エンティティの特定の階層（VM またはストレージ タイプ）のみを含めるようにポリシーを作成する場合、サービス プロバイダーが新しい階層を展開すると、それらもポリシーに含まれます。

    これは予期しないことです。たとえば、1 つの VM タイプのみを含むポリシーを作成するとします。サービス プロバイダーが新しい VM タイプを導入した場合、ポリシーにはそれらの新しいタイプが含まれます。

    ポリシーを定期的にチェックして、新しい階層が INCLUDE リストに追加されているかどうかを確認する必要があります。

  • Kubernetes 環境の場合、インストールでフィードバックと診断を有効にすると、収集されたデータに Kubernetes クラスタ名が含まれることがあります。

    製品の改善に役立てるために、製品の使用中に、Workload Optimization Manager が匿名化された非機密データを収集できるようにすることができます。ただし、Workload Optimization Manager での Kubernetes ディスカバリの動作方法により、収集されたデータには、ターゲットとして設定した Kubernetes クラスタの名前が含まれます。これらのクラスタ名はいかなる方法でも使用しません。

    Workload Optimization Manager がこれらのクラスタ名を収集しないようにする場合は、[設定（Settings）] / [メンテナンスオプション（Maintenance Options）] / [フィードバックと診断（Feedback and Diagnostics）] に移動し、匿名化された使用状況データを共有するオプションをオフにします。

  • ポリシーへの変更は、影響を受ける範囲のユーザ インターフェイスビューにすぐには表示されません。

    [Workload Optimization Manager （Workload Optimization Manager）] ビューの範囲をグループに設定すると、特定のグループに影響する自動化ポリシーを表示できます。（[設定: ポリシー] で）そのグループのポリシーを編集し、そのグループにビューを再度スコープした場合、ポリシーの変更はそのグループの表示に表示されません。

    表示は、次の増分ディスカバリから 10 分以内に更新されます。状態が続く場合は、セッションからログアウトし、再度ログインして表示を更新します。

  • クラウドへの移行プランの場合、まれにプランのアクション リストに重複エントリが表示されることがあります。

    クラウドへの移行プランの場合、まれにプランのアクション リストに重複エントリが表示されることがあります。

  • Azure 環境の場合、検出は Brazil Southeast リージョンをサポートしません。

    Azure 環境の場合、Workload Optimization Manager は Brazil Southeast リージョンを検出しません。Azure は、データの常駐を必要とするBrazil South のワークロードにビジネス継続性とディザスタリカバリを提供するためにのみ、このリージョンを提供します。

    ユーザ インターフェイスでは、リストまたはチャートに Brazil Southeast リージョンが表示されません。また、そのリージョンにワークロードがある場合、Workload Optimization Manager はそれらのワークロードを検出しません。

  • AppDynamics 環境では、ターゲット認証でクレデンシャルに oAuth が使用されている場合、プラットフォームはデータベースを検出できません。

    AppDynamics 環境では、ターゲット認証でクレデンシャルに oAuth が使用されている場合、Workload Optimization Manager はデータベースを検出できません。

  • アプリケーション コンポーネント自動化ポリシーの場合、ユーザ インターフェイスで競合する設定を行うことができます。

    [アクション生成（Action Generation）] 設定に、ポリシーに選択できる誤った値が表示されることがあります。その結果、ポリシーを保存できません。

  • 現在、ユーザ インターフェイスには、一部の Azure リソース グループの請求コストは表示されません。

    Azure 環境の場合、リソース グループを検査しても、現在、Workload Optimization Manager はそれらのリソース グループの請求コストを表示しません。

  • クラウド環境の場合、まれな状況では、分析により、VM のサイズを、同じ価格のインスタンスタイプよりも古くて機能の低いインスタンス タイプに変更することが推奨される場合があります。

    ほとんどの状況では、クラウド プロバイダーが古いタイプを置き換える新しいインスタンスタイプを提供する場合、プロバイダーはそれを低コストで提供します。少なくとも 1 つのインスタンスで、新しいインスタンス タイプと古いインスタンス タイプのコストが同じであるケースを確認しました。これが発生し、キャパシティとコストが等しい場合、Workload Optimization Manager は新しいインスタンス タイプを選択することを保証できません。

    この問題を回避するには、古いインスタンス タイプを除外するアクション自動化ポリシーを作成します。

  • [すべてのアクション（All Actions）] チャートには、データベースまたはデータベース サーバの保留中のアクションは含まれません。

    [すべてのアクション（All Actions）] チャートには、データベースまたはデータベース サーバの保留中のアクションは含まれません。

  • [すべてのアクション（All Actions）] チャートからダウンロードできるデータにはメモリ制限があります。

    [すべてのアクション（All Actions）] チャートからダウンロードできるデータにはメモリ制限があります。たとえば、環境内で時間をかけて多くのアクションを実行したとします。その結果、実行されたすべてのアクションのリストがデータ制限を超える可能性があります。その場合、[すべてのアクション（All Actions）] チャートからの CSV ファイルのダウンロードは失敗します。

  • まれに、etcd.service が失敗することがあります。

    まれに、Workload Optimization Manager プラットフォームが応答を停止します。これは、etcd.service が失敗した場合に発生します。この場合、次のエラーが表示されます。

    Error response from daemon: endpoint with name etcd1 already exists in network host

    この状況から回復するには、Workload Optimization Manager プラットフォームの Docker サービスを再起動します。 sudo systemctl restart docker.service コマンドを実行します。

  • PLACE を使用して予約または展開を設定する場合は、特定のテンプレートを使用する必要があります。

    [PLACE] ページを使用して予約または展開を設定する場合は、展開するワークロードを表すテンプレートを選択します。選択するテンプレートには、VM パッケージへのパスを指定するイメージ仕様と、オプションの配置制約を含める必要があります。

    通常、ハイパーバイザ ターゲットを介して検出されたテンプレートを使用します。Workload Optimization Manager は、特定の VM のリソース容量を検出するとともに、特定の検出されたテンプレートのイメージ仕様も検出する必要があります。ただし、このバージョンでは、Workload Optimization Manager はイメージの説明を検出しません。また、検出されたテンプレートとそのイメージ仕様は読み取り専用です。このため、検出されたテンプレートを使用して配置または予約を設定することはできません。

  • [予約済み容量（Reserved Capacity）] をサポートしていないリソースの場合、チャートには予約済み容量がゼロのリソースが表示されます。

    異なるリソースの使用率を示すリング チャートには、リソースの [予約済み容量（Reserved Capacity）] がゼロの場合に黄色のセグメントが表示されます。一部のリソースでは予約済み容量の概念はありませんが、リング チャートには黄色のセグメントが表示されます。

  • 計画の最適化された改善には、プロビジョニングするホストは含まれません。

    アクションが新しいホストのプロビジョニングを示している場合、最適化された改善チャートには、「計画後」セクションにプロビジョニングするホストが含まれません。

  • vCenter 環境では、ストレージ レイテンシの値が異常に高い場合や、新しいストレージをプロビジョニングするための推奨事項が多すぎる場合があります。

    vCenter 環境では、ストレージ レイテンシの値が異常に高い場合や、新しいストレージをプロビジョニングするための推奨事項が多すぎる場合があります。vCenter Server バージョン 6.5.u1x 以前が API を介して返すストレージ レイテンシ値には既知の問題があります。これらのバージョンは、異常に高いストレージ レイテンシ値を返す可能性があります。

    Workload Optimization Manager は、VM を既存のストレージに移動するかどうか、または新しいストレージをプロビジョニングするかどうかを計算するときに、ストレージのレイテンシを考慮します。この既知の問題のため、Workload Optimization Managerは、移動が適切な場合、ストレージのプロビジョニングを誤って推奨する可能性があります。

    この問題が発生した場合は、vCenter Server バージョン 6.5.u1x 以前で管理されている VM のストレージ移動を無効にするポリシーを作成する必要があります。このポリシーを作成するには：

    • 影響を受けるすべての VM を含む VM グループを作成します。Workload Optimization Manager は、使用できる可能性のある VMs_vCenter という名前のグループを自動的に作成することに注意してください。

    • 新しい自動化ポリシーを作成します。このポリシーは、ストレージ移動アクションを無効にします。

    • 作成したグループをポリシー スコープとして設定します。

    • [アクションの自動化] で、Storage Move アクションを追加して Disabled に設定します。

  • [最適改善（Optimal Enhancements）] チャートに、一時停止するホストの誤ったデータが表示されることがあります。

    アクションでホストを一時停止することが推奨されている場合、最適な改善チャートには、一時停止するホストが使用されていないことが示されているはずです。状況によっては、チャートにこれらのホストの使用率が表示される場合があります。その結果、現在のスコープ内の他のホストでの使用率が誤って低い値となります。

  • vSAN 環境の場合、状況によっては、データセンターを対象とする計画が失敗することがあります。

    vSAN 環境の場合、環境にホストを追加または置換するプランを実行すると、状況によってはプランのホスト数が正しく表示されず、プランが失敗することがあります。

    これは、次の条件を満たすプランで発生する可能性があります。

    • プラン タイプは、[ハードウェア更新（Hardware Refresh）]、[ワークロードの追加（Add Workspace）]、または [カスタム（Custom）] です。

    • プランの範囲はデータセンターに設定され、vSAN ホストが含まれます。

    • 計画では、HCI テンプレートを使用してホストを置き換えます。

    実行後、プランにはプラン範囲内のホストの数ではなく、vSAN環境内のホストの完全な数が表示されます。

    この状況を回避するには、計画の範囲をデータセンターに限定しないでください。

  • すべてのオンプレミス ホストのヘッドルーム チャートは、[上位クラスタ（Top Clusters）] チャートと必ずしも一致しません。

    すべてのオンプレミス ホストのヘッドルーム チャートは、[上位クラスタ（Top Clusters）] チャートと必ずしも一致しません。

    Workload Optimization Manager は、すべてのオンプレミス ホストのヘッドルーム データを夜間プランで生成します。計画を実行すると、このデータは正しいものになります。このデータは 1 日のうちに失効する可能性があります。

    クラスタの使用状況を正確に追跡するには、[上位クラスタ（Top Clusters）] チャートを使用する必要があります。

  • ホストを置き換えるハードウェア リフレッシュ プランは、予期しない結果をもたらす可能性があります。

    クラスタ内のホストを交換する計画を実行すると、予想よりも多くのホストが必要であると誤って示されることがあります。これは、次の 2 つの理由で発生する可能性があります。

    • 交換用のホスト テンプレートがカタログの CPU 仕様を使用していない場合、ホスト容量の計算が正しくない可能性があります。

    • 代替ホストに VM を配置する場合、分析ではすべての VM ピークが同時に発生する可能性があると想定されます。これにより、計画のピーク キャパシティが過剰に使用されます。

    これらの問題を回避するように計画を設定するには、次のようにします。

    • 計画範囲が単一のクラスタ用であることを確認します。

      これは、Replace Hosts プランの一般的な使用例です。名前は後の手順で使用するため、クラスタ名を記録します。

    • ホスト テンプレートを作成するときは、必ず [カタログから選択（Select from Catalog）] オプションを使用します。

      必要な CPU 仕様がカタログに含まれていない場合は、できるだけ近いエントリを選択します。

      コアの数を調整するには、別の数のソケットを指定します。たとえば、特定のコア周波数の 4 つのコアをもつ CPU 仕様を選択し、実際には 32 のコアが必要であるとします。この仕様を選択し、Sockets を 8 に設定してその数を実現できます。

    • VM の スケール をオフにします。

      使用するホストテンプレートを選択したら、[次へ：仮想マシン アクション（NEXT：VIRTUAL MACHINE ACTIONS）] をクリックします。次に、[スケール（Scale）] オプションをオフにします。

      ホストを交換する場合は、VM をスケーリングしないことが重要です。これにより、ホストが特定のワークロードをサポートする方法を確認できます。

    • すべての VM をクラスタ平均テンプレートに置き換えます。

      [SKIP TO CONFIGURATION] をクリックしてプランの設定を表示し、[Replace/Virtual Machine] を開きます。クラスタを表示し、[すべて選択（Select all）] をクリックします。次に、[次へ（Next）] をクリックして VM テンプレートを選択します。

      置換する VM テンプレートを選択するには、[検索（Search）] ボックスにクラスタ名を入力します。[テンプレート（Templates）] リストに、そのクラスタの AVG テンプレートが表示されます。たとえば、クラスタ名が MyCluster1 の場合、テンプレート名は myDomain.com::AVG:MyCluster1 になります。このテンプレートは、過去 10 日間の平均 VM 使用率をキャプチャします。

      このテンプレートを選択し、[送信（Submit）] をクリックします。

    • これで、プランを実行できます。

  • vCenter Server 環境の場合、Workload Optimization Manager は、ClusterDependencyRule に基づく VM 再起動の依存関係の DRS ルールを認識しません。

    vCenter Server 環境の場合、Workload Optimization Manager は、ClusterDependencyRule に基づく VM 再起動の依存関係の DRS ルールを認識しません。

    依存関係を ClusterVmHostRule またはクラスタ アフィニティまたはアンチアフィニティ ルールで表現することで、同様の効果を達成できる場合があります。