Cisco UCS Workload Optimization Manager リリース ノート、リリース 3.6.0
 |
Workload Optimization Manager 3.6.0 リリースノート
リリース日：2023 年 2 月 10 日
このドキュメントでは、Workload Optimization Manager 3.6.0 –リリース日：2023 年 2 月 10 日 － で対応した問題について説明します。3.0 バージョン ファミリ以降、ビルドは累積的です。以前のバージョンのリリースノートについては、Workload Optimization Manager のドキュメントを参照してください。
ご不明な点は、サポートまでお問い合わせください。
Workload Optimization Manager の Kubernetes ターゲットの構成
Workload Optimization Manager の Kubernetes ターゲットを設定するには、特定の構成リソースを使用して Kubeturbo ポッドを展開します。これらのリソースには、TURBONOMIC_SERVER_VERSION にマップされたバージョンの Workload Optimization Manager が必要です。次の表を使用して、Workload Optimization Manager のバージョンをマップします：
| Workload Optimization Manager のバージョン： |
TURBONOMIC_SERVER_VERSION 番号 |
| 3.6.0 |
8.8.0 |
| 3.5.6 |
8.7.6 |
| 3.5.5 |
8.7.5 |
| 3.5.4 |
8.7.4 |
| 3.5.3 |
8.7.3 |
| 3.5.2 |
8.7.2 |
| 3.5.1 |
8.7.1 |
| 3.5.0 |
8.7.0 |
Kubeturbo ポッドの構成方法の詳細については、https: //github.com/ turbonomic/kubeturbo にある Kubeturbo GitHub リポジトリを参照してください。
Kubernetes ターゲットやその他のターゲットの詳細については、『 ターゲットの構成ガイド 』の「ターゲットの構成」を参照してください。
バージョン 3.6.0 の新機能
バージョン 3.6.0 の新機能については、『Workload Optimization Manager User Guide』を参照してください。
バージョン管理の説明
Workload Optimization Manager のバージョン管理では、バージョン番号の VRM 要素（バージョン、リリース、修正）を使用して、次のように特定のリリースのステータスが表されます。
| 番号付き要素 |
例 |
説明 |
| V：バージョン番号 |
3.X.X |
▪ プラットフォーム アーキテクチャの変更またはデータモデルの大幅な変更 |
| R：リリース番号 |
X. 1.X |
▪ 主要機能の変更 |
| M：修正番号はゼロ（0） |
X.X.0 |
▪ 四半期毎リリース ▪ 以前の隔週リリースに含まれていたすべてのプレビュー機能が GA になりました。 ▪ このリリースには新しいプレビュー機能はありません。 |
| M：修正番号はゼロより大きい（1 以上） |
X.X.3 |
▪ 隔週リリース ▪ 新しいプレビュー機能を含めることができます。 ▪ 修正済みの問題が含まれています。 |
注：
API デベロッパーの場合、X.X.1 リリースには廃止された API 機能の最終的な実装が含まれる場合があります。それらの最終的な実装により、後方互換性のない API の変更が可能になります。
注:
Classic-to-XL 移行ツールである Tbmigrate の非推奨通知
Workload Optimization Manager の 3.3.0 リリース以降、Classic-to-XL Migration Tool はサポートされていません。このツールは、クラシック インストール（2.x バージョン ファミリ）から XL インストール（3.x バージョン ファミリ）に移行するために使用できるスクリプト インターフェイスを提供していたものです。
クラシック インストールから 3.x バージョン ファミリのいずれかに移行する必要がある場合は、サポート担当者にお問い合わせください。
設定要件
このリリースの Workload Optimization Manager では、以下の構成要件を満たす必要があります。
Dynatrace ターゲット
Workload Optimization Manager バージョン 3.4.2 以降、Dynatrace ターゲットを構成するときに使用する API トークンは、Dynatrace API V1 および V2 の特定の範囲にアクセスする必要があります。
3.4.2 より前のバージョンから Workload Optimization Manager バージョン 3.4.2 以降に更新する場合は、Dynatrace ターゲット構成用に新しい API トークンを生成する必要があります。トークンをターゲット構成に入力し、そのターゲットを検証する必要があります。
Workload Optimization Manager は Dynatrace API へのコールを認証するために API トークンを使用します。このトークンには、Dynatrace API、Version 1 および Version 2 の両方を介してGETメソッドを実行する権限が必要です。次の範囲を持つ新しい汎用アクセストークンを生成します。
| Workload Optimization Manager の機能 |
必要なアクセス許可 |
| モニタリング |
▪ API V1 範囲： – アクセスの問題およびイベント フィード、メトリック、およびトポロジ ▪ API V2 範囲： – エンティティの読み取り – メトリックの読み取り |
注：
状況によっては、アクセストークンを更新した後も、ターゲットの検証に失敗します。その場合は、構成設定をメモし、ターゲットを削除して、ターゲットを再度構成します。生成した新しい API トークンを必ず使用してください。
Workload Optimization Manager のアップデートと Operator のバージョン
Workload Optimization Manager は、Kubernetes クラスタにクラウドネイティブ アプリケーションとしてデプロイされます。このクラスタは、デプロイする VM 上に事前構成することも、Workload Optimization Manager を環境内の Kubernetes クラスタにデプロイすることもできます。いずれの場合も、Workload Optimization Manager は Operator を使用してアプリケーションの展開を管理します。
Workload Optimization Manager のさまざまなバージョンについて、使用する必要がある Operator のバージョンを次のように変更します。
| 製品バージョン |
オペレーターのバージョン |
| 3.5.6 - 3.6.0 |
42.23 |
| 3.5.5 |
42.22 |
| 3.5.4 |
42.21 |
| 3.5.3 |
42.20 |
| 3.5.2 |
42.19 |
| 3.5.1 |
42.18 |
| 3.4.6 - 3.5.0 |
42.17 |
| 3.4.4 - 3.4.5 |
42.16 |
| 3.4.3 |
42.15 |
| 3.4.2 |
42.14 |
| 3.4.1 |
42.13 |
| 3.3.7 - 3.4.0 |
42.12 |
| 3.3.6 |
42.11 |
| 3.3.4 - 3.3.5 |
42.10 |
| 3.3.2 - 3.3.3 |
42.9 |
| 3.2.6 - 3.3.1 |
42.7 |
| 3.2.4 - 3.2.5 |
42.6 |
| 製品バージョン |
オペレーターのバージョン |
| 3.2.3 |
42.5 |
| 3.2.1 - 3.2.2 |
42.4 |
| 3.1.5 - 3.2.0 |
42.3 |
| 3.1.4 |
42.2 |
| 3.1.2 - 3.1.3 |
42.1 |
| 3.1.1 |
42.0 |
| 3.1.0 |
8.2 |
Workload Optimization Manager を更新する場合は、必ずマッチするバージョンの Operator を更新に含めてください。インストール ガイドの「最新のインストール手順」に従ってオンラインまたはオフラインで更新を実行すると、最新のオペレータが自動的に含まれます。
Workload Optimization Manager を Kubernetes クラスタにインストールした場合は、Operator のバージョンを手動で更新する必要がある場合があります。
Operator のバージョンを更新し、ポッドが実行中で準備ができていることを確認したら、カスタム リソース宣言を編集して、Workload Optimization Manager を Operator のバージョンと一致するバージョンに更新できます。
詳細については、サポート担当者に問い合わせてください。
OVA および VHD インストールでサポートされる MariaDB バージョン
OVA および VHD インストールのデフォルトの履歴データベースとして、Workload Optimization Manager は現在、MariaDB バージョン 10.5.18 をサポートしています。このサポートには、Workload Optimization Manager による履歴データベースの使用に関する包括的なテストと品質管理が含まれます。
重要事項：
既知の問題のため、MariaDB バージョン 10.5.14、10.5.15、10.6.7、10.7.3、または 10.8.2 は使用しないでください。
OVA または VHD イメージとしてインストールされた Workload Optimization Manager を実行しており、そのインストールに含まれているデータベースを使用している場合は、バージョン 10.5.18 を使用する必要があります。バージョン 3.5.6 より前に OVA または VHD としてインストールしたバージョンの Workload Optimization Manager で、MariaDB を 10.5.18 に明示的に更新していない場合は、ここで更新する必要があります。
MariaDB インスタンスの更新については、インストール ガイドの「Verifying your MariaDB Version」を参照してください。次に記載されています。
外部データベースの 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 であることがわかっています。
探します。NetApp ターゲットの検証に失敗した場合は、これが原因である可能性があります。
TLS のサポートが原因でターゲットの検証が失敗した場合は、次のような文字列により検証エラーが表示されることがあります。
▪ 適切なプロトコルがありません（No appropriate protocol）
このエラーを修正するには、ターゲット テクノロジーがサポートする TLS の最新バージョンを有効にしてください。これで問題が解決しない場合は、テクニカル サポートにお問い合わせください。
▪ 証明書がアルゴリズムの制約に準拠していません（Certificates does not conform to algorithm constraints）
このエラーを修正するには、ターゲット テクノロジーのマニュアル (たとえば NetApp のマニュアル) を参照して、ターゲット サーバで 1024 以上の長さの証明書キーを生成する手順に従ってください。これで問題が解決しない場合は、シスコ テクニカル サポートにお問い合わせください。
改善点
• 改善点：
VM スケール エラーの処理が改善されました。
状況によっては、VM のスケール エラーにより、「クラスター ハードウェアが利用できません」というエラーが発生していました。Workload Optimization Manager は、VM の割り当てを解除し、サイズ変更を 2 回目を試みることにより、これらの失敗の一部またはすべてを排除するようになりました。
• 改善点：
Workload Optimization Manager は、メンテナンス モードで VM ストレージを vCenter データストアに移動するアクションを生成しなくなりました。
Workload Optimization Manager は、vCenter データストアがメンテナンス モードであることを検出すると、VM ストレージをそのデータストアに移動するための推奨アクションを停止します。
• 改善点：
静的ポッドの処理が改善されました。
Kubernetes 環境の場合、Workload Optimization Manager は、ノードをプロビジョニングまたは一時停止するために、静的ポッドを DaemonSet として扱うようになりました。静的ポッドはノードに特定の機能を提供するため、コントロール プレーンではなくノードによって制御されます。
– プロビジョニングされるノードに静的ポッドが必要な場合、Workload Optimization Manager は、ノードと対応する静的ポッドをプロビジョニングするためのアクションを生成します。
– ノードに残っている唯一のワークロード タイプが静的 Pod である場合、Workload Optimization Manager は、ノードと対応する静的 Pod を一時停止するアクションを生成します。
• 改善点：
Azure での Ebsv5 および Ebdsv5 インスタンス層のサポートが追加されました。
Workload Optimization Manager は、Azure Ebdsv5 および Ebsv5 インスタンス層をサポートするようになりました。これらのインスタンス層を持つ VM が正しく認識および管理されるようになりました。
修正済みの問題
• 修正済みの問題：
移行プランでは、クローンされた VM は元の VM よりも CPU 使用率が低くなります。
移行プランでは、クローンされた VM は元の VM よりも CPU 使用率が低くなります。これは、クローンされた VM で購入した CPU コモディティに対してスケーリング ファクターが設定されていないために発生します。これにより、プラン結果のホスト数が少なくなります。
既知の問題
• 既知の問題：
Cisco Container Registry（icr.io）に切り替えた後、一部のユーザーは kubeturbo を変更できません。
icr.io/cpopen/turbonomic リポジトリを使用するバージョン。
Cisco Container Registry（icr.io）に切り替えた後、一部のユーザーは kubeturbo を icr.io/cpopen/turbonomic リポジトリを使用して変更できません。ユーザーは、古いサーバー バージョンと一致するように kubeturbo バージョンをダウングレードすることはできません。
さらにサポートについては、サポート担当者にお問い合わせください。
• 既知の問題：
コスト データのない Azure サブスクリプションは、Azure Billing ターゲットにステッチされていません。
料金が発生していない空の Azure EA サブスクリプションは、Azure Billing ターゲットと結合されず、サブスクリプションのオファー ID に不一致が発生します。サブスクリプションで料金が発生すると、スティッチングが発生し、サブスクリプションは Azure Billing ターゲットをオファー ID に正しく関連付ける必要があります。
• 既知の問題：
Nutanix VM は、検出された Microsoft SQL Server DB ターゲットに結合していません。
現在、Microsoft SQL データベース ターゲットを使用した Nutanix VM のステッチはサポートしていません。
• 既知の問題：
グローバル スコープからエンティティ タイプにスコープを設定すると、キャパシティと使用状況のチャートの値に平均ストレージ量が表示されます。
グローバル スコープからエンティティ タイプにスコープを設定すると、[キャパシティと使用状況] チャートの値は、合計ではなく平均を示します。エンティティのグループの使用率とキャパシティの合計を取得するには、エンティティとそのグループへのスコープを含むグループを明示的に作成する必要があります。
• 既知の問題：
New Relic は、Microsoft SQL Server 2012 との統合をモニタリングするサポートを終了しました。
Workload Optimization Manager は、New Relic を介して検出された Microsoft SQL 2012 の監視とスティッチングをサポートしなくなりました。Microsoft SQL インスタンスを New Relic がサポートするバージョンにアップグレードすることをお勧めします。
• 既知の問題：
状況によっては、ストレージの概要チャートに誤った数のボリュームが表示されることがあります。
ストレージ サマリ チャートのボリュームの合計数を階層のボリュームの合計数と比較すると、カウントが一致しない可能性があります。
• 既知の問題：
Azure の場合、RI の課金情報に NA としてコストが表示されることがあります。
Azure 環境では、Microsoft Enterprise Agreement ターゲットを構成すると、RI のコストがユーザー インターフェイスに NA として表示されることがあります。たとえば、100% の RI カバレッジを示す VM は、予約済みコンピューティング コストを NA として表示できます。これは、ターゲット プローブがデータを収集するために使用する Microsoft EA API によって提供されるデータに既知のギャップがあるために発生します。
• 既知の問題：
スケーリングに使用できるより小さなインスタンス タイプがある場合でも、Cloud VM は非常に大きなインスタンス タイプにスケーリングされる場合があります。
特定のディスク数とディスク タイプを持つクラウド VM が「インスタンス ストア対応スケーリング」を有効にするポリシーを適用すると、Workload Optimization Manager は、VM のリソース要件を十分に満たすことができるより小規模で安価なインスタンス タイプがある場合でも、VM を非常に大きなインスタンス タイプにスケーリングすることを推奨する場合があります。
この問題を回避するには、インスタンス ストア対応スケーリングを無効にして、VM を現在のインスタンス ファミリに制限します。たとえば、AWS VM が現在 i3.2xlarge インスタンス タイプを実行している場合、i3 インスタンス ファミリを VM のスケーリング制約として指定します。
• 既知の問題：
埋め込みレポートを使用している場合、このバージョンに更新するとダッシュボードが空になることがあります。
埋め込みレポートをサポートするために、Workload Optimization Manager は、履歴データを TimescaleDB サービスにロードし、そのデータを、Grafana オブザーバビリティ プラットフォームを利用したダッシュボードとチャートに表示します。バージョン 3.4.1 より前の Workload Optimization Manager は、Enterprise バージョンの Grafana を使用し、Embedded Reports を使用するためのライセンス料を支払った顧客向けに Enterprise ライセンスを含めていました。
バージョン 3.4.1 以降、Workload Optimization Manager には Enterprise バージョンを使用するコントラクトがなくなり、代わりにオープンソースの Community バージョンが出荷されます。バージョン 3.4.1 に更新すると、Grafana は自動的にコミュニティ バージョンに切り替わり、通常どおり埋め込みレポートを使用できるようになります。
ただし、まれに、ダッシュボードが空になり、次のエラー メッセージのバナーが表示されることがあります。
db query error: pq: password authentication failed for user "query"
この問題を解決するには、次の手順に従います。
1. 埋め込みレポートのデータ ソースを削除します。
– Grafana ユーザーインターフェイスで、構成 / データ ソースに移動します。
– クリックして、Workload Optimization Manager の期間データ ソースを選択します。
– 表示される画面で、[削除（Delete）] をクリックして、Workload Optimization Manager の期間データ ソースを削除します。
2. エクストラクタ コンポーネントを再起動します。
抽出コンポーネントを再起動すると、Grafana コミュニティ バージョンが読み込まれ、データ ソースが再構成されます。
– 次のコマンドを実行して、エクストラクタ ポッドの完全なポッド名を取得します。
kubectl get pods -n {YourNamespace} | grep ^extractor
たとえば、次を実行します。
kubectl get pods -n turbonomic | grep ^extractor
完全なポッド名は次のようになります。
extractor-5b86976bc8-vxwz4
– エクストラクタ ポッドを削除します。
ポッドを削除すると、再起動がトリガーされます。上記の例の名前を使用して、次のコマンドを実行します。
kubectl delete pod -n {YourNamespace} {YourExtractorPodName}
次に例を示します。
kubectl delete pod -n turbonomic extractor-5b86976bc8-vxwz4
さらにサポートについては、サポート担当者にお問い合わせください。
• 既知の問題：
New Relic MySQL の場合、DB キャッシュ ヒット率の値が正しくありません。
New Relic MySQL 8 の場合、Workload Optimization Manager で DB キャッシュ ヒット率の値が正しくありません。キャッシュから取得されるクエリの割合（db.qCacheHitRatio）は New Relic MySQL バージョン 8.0 以降ではサポートされていないため、DB キャッシュ ヒット率の値は Workload Optimization Manager に表示されなくなりました。
詳細については、「New Relic ドキュメント」を参照してください。
• 既知の問題：
Azure API の問題により、ユーザーインターフェイスに不完全な Azure 課金コストとメトリックが表示されます。
月の最初の日に、パーティション分割されたコスト エクスポートで構成された Azure 課金対象を検出しようとすると、Workload Optimization Manager は、顧客の Azure Storage アカウント内にエクスポート ファイルを含むディレクトリを見つけることができません。エクスポート ファイルは存在しますが、Azure API は、その日のコストのエクスポート ファイルの正しい保存場所を返しません。その結果、Workload Optimization Manager のユーザーインターフェイスには、Azure が月の最初にエクスポートした課金コストと、その課金コストに依存するメトリックが反映されない場合があります。なお、課金される費用は、その月の初日に発生した費用に限定されません。
ログでは、最初の検出試行後に、重大度が INFO の次の 1 回限りのメッセージが表示されます。
Download storage blob failed: no blob found from prefix: ${prefix}
• 既知の問題：
Nutanix 環境では、ホストの置換プランが VM の配置に失敗することがあります。
Nutanix クラスタでホストの置換プランを構成して、ホストを HCI テンプレートに置き換えることができます。ただし、プランは HCI ホストの作成に失敗し、VM が配置されなくなります。
• 既知の問題：
Top Accounts チャートの詳細テーブルを表示すると、Actions Taken 列と Saved By Actions 列に現在のデータが表示されない場合があります。
上位のアカウント グラフを表示しているときに、[すべて表示] をクリックして詳細テーブルを表示できます。状況によっては、このテーブルが、[実行済みのアクション（Actions Taken）]または [アクション別に保存（Saved By Actions）] 列の新しいデータで更新できないことがあります。たとえば、コストを削減するアクションを実行した場合でも、これらの列にゼロが表示されることがあります。
現在のアクション データを表示するには、[実行されたアクション] チャートを表示します。
• 既知の問題：
ホストを HCI テンプレートに置き換えるためのハードウェア リフレッシュは、ワークロードの配置に失敗する可能性があります。
ハードウェア交換プランを実行すると、プランはワークロードを HCI ホストに配置できない場合があります。プランの範囲がハイパーコンバージド環境にある場合、プランはワークロードを正しく配置します。範囲がハイパーコンバージド環境にない場合は、プランをクラスタ全体にスコープする必要があり、クラスタ内のすべてのホストを HCI テンプレートで置き換えるようにプランを構成する必要があります。
• 既知の問題：
特定の条件下では、プラットフォームを更新すると、すべてのターゲット構成が失われる可能性があります。
Workload Optimization Manager を 3.3.3 より前のバージョンから更新する場合、いずれかのユーザー アカウントのユーザー名に % 文字が含まれていると、更新にターゲット構成が含まれません。
これが更新時に発生する場合、サポート担当者にお問い合わせください。
注：
更新を実行する前に、常にインストールをバックアップする必要があります。
• 既知の問題：
RI ディスカウント共有がオフになっている AWS 環境の場合、分析は RI の適用範囲と使用率を管理しません。
AWS では、特定のアカウントの RI 割引共有を無効にすることができます。これらのアカウントは、他のアカウントと割引を共有しません。Workload Optimization Manager は、これらのアカウントの RI カバレッジまたは使用率を認識しません。たとえば、RI カバレッジと RI 使用率のグラフにはゼロの値が表示されます。
この状況が発生した場合は、考えられる回避策についてサポート担当者にお問い合わせください。
• 既知の問題：
ヘッドルーム プランの場合、オーバープロビジョニングされた商品には望ましい状態を指定できます。
Workload Optimization Manager は、夜間プランを実行して、クラスタのヘッドルームを計算します。これにはメモリ、CPU、またはストレージの制限を超えることなくクラスタに追加できる VM の数が含まれます。たとえば、80% の消費の望ましい状態が必要な場合、プランはクラスタ内のリソースの使用率が 80% を超える VM を追加しません。
予約の際、Workload Optimization Manager は、これらのヘッドルーム計算を使用して、ワークロードを予約リクエストに配置できるかどうかを判断することに注意してください。
デフォルトでは、プランは、オーバープロビジョニングされたリソースの使用率を望ましい状態（上の例では 80%）の範囲内に維持しません。このプランは、オーバープロビジョニングされたリソースの使用率を 100% と計算します。ただし、クラスタに予約を配置する際、分析は、オーバープロビジョニングされたリソースを望ましい状態に保つ方法として、新しいホストをプロビジョニングすることを推奨する場合があります。
これまでに、オーバープロビジョニングされたリソースに望ましい状態を強制するための設定が導入されました。これにより、計算されたヘッドルームが低くなる可能性があります。しかし、予約が新しい VM を配置してパワーオンすると、現在のインフラストラクチャに確実に収まります。分析は、VM のオーバープロビジョニングされたリソースをサポートするために新しいホストをプロビジョニングする必要を認めません。
この機能を有効にするには、cr.yaml ファイルのトポロジ プロセッサ設定を編集します。
1. Workload Optimization Manager インスタンスの SSH ターミナルセッションを開きます。
Workload Optimization Manager をインストールしたときにセットアップしたシステム管理者でログインします。
2. 編集のために cr.yaml ファイルを開きます。次に例を示します。
vi /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml
3. [仕様/プロパティ（spec/properties）]セクションで、トポロジ プロセッサコンポーネントのエントリを見つけます。
4. considerDesiredStateForProvisioningInClusterHeadroomPlan: true
considerUtilizationConstraintInClusterHeadroomPlan: true
5. 変更を保存してプラットフォームに適用します。
変更を保存したら、次の kubectl コマンドを使用して変更を適用します。
kubectl apply -f /opt/turbonomic/kubernetes/operator/deploy/crds/ charts_v1alpha1_xl_cr.yaml
サポートについては、サポート担当者にお問い合わせください。
• 既知の問題：
Kubernetes の場合、一部の環境では、分析はスケール ノード アクションを実行できません。
Kubernetes OCP 4.x および AKS 環境の場合、Workload Optimization Manager は、スケール ノード アクションを生成して実行できます。ただし、環境にスケール ノード アクション（EKS、AKS、および OCP）の実行をサポートしていない他の Kubernetes ディストリビューションが含まれている場合、Workload Optimization Manager は環境内のすべてのスケール ノード アクションの実行を無効にすることがあります。
• 既知の問題：
cgroup v2 が有効になっている Linux を実行しているノードがある Kubernetes 環境の場合には、Kubernetes バージョン 1.23.2 以降を使用する必要があります。
cgroup v2 が有効になっている Linux を実行しているノードがある Kubernetes 環境の場合、以前のバージョンの Kubernetes の問題により、Workload Optimization Manager は、影響を受けるノードの CPU 使用率データを収集できません。cgroup v2 ノードから CPU 使用率を収集するには、Kubernetes バージョン 1.23.2 以降を実行する必要があります。
• 既知の問題：
非常に大規模な環境でのまれな状況として、クエリによってデータベースがロックされ、検出されたデータにギャップが生じることがあります。
非常に大規模な環境では、クエリがデータベースをロックしてしまい、検出されたデータにギャップが生じる可能性があります。これが発生すると、次のようなエラーが表示されます。
– [RollupProcessor]：テーブル vm_stats_latest のロールアップ アクティビティ中にエラーが発生しました。
– [ComponentBasedTargetDumpingSettings] :（ターゲットのディスカバリ ダンプが保持されない）
ご使用の環境でこれが発生した場合は、回避策についてサポート担当者にお問い合わせください。
• 既知の問題：
IBM FlashSystem の場合、FlashSystem の既知の問題により、一部のモデルで断続的にターゲット エラーが表示されることがあります。
IBM FlashSystem プラットフォームの一部のモデルでは、Workload Optimization Manager が断続的に無効な資格情報ターゲット エラーを表示することがある。これは、メモリが 64GB 未満のプラットフォームでの FlashSystem REST サービスの既知の問題が原因です。
この問題が発生した場合は、次のコマンドにより、FlashSystem REST サービスを再起動します。
satask restartservice -service cfrest
詳細については、IBM FlashSystem のサポート担当者にお問い合わせください。
• 既知の問題：
非常に大きいディスクのワークロードがある場合、Storage vMotion がタイムアウトすることがあります。
非常に大きいディスクを持つ VM の Storage vMotion アクションは、タイムアウトすることがあります。これが発生した場合は、サポート担当者に連絡して、タイムアウトのしきい値を変更してください。
• 既知の問題：
インストールを更新すると、まれにトポロジ プロセッサ コンポーネントの再起動に失敗することがあります。
Workload Optimization Manager を更新すると、まれにトポロジプロセッサ ポッドの再起動に失敗することがあります。ログには、次のステートメントのエラーが投稿されます。
AccessDeniedException: /home/turbonomic/data/kv
この問題が発生した場合は、回避策についてサポート担当者にお問い合わせください。
• 既知の問題：
Azure の場合、Australia Central リージョンのターゲットには、VM ライセンスコストに対して一貫性のない価格が表示されることがあります。
Australia Central リージョンで稼働している Azure 環境の場合、Workload Optimization Manager に報告されるライセンスコストの価格が正しくない可能性があり、ユーザーインターフェイスに Linux または Windows オペレーティングシステムのライセンスの誤ったライセンスコストが表示される可能性があります。
• 既知の問題：
Azure と AWS の場合、一部のワークロードの総コストは分析で考慮されません。
Azure 環境の分析では、OS の基本コストは考慮されますが、OS にバンドルされているサポートやその他のアドオン機能の追加コストは考慮されません。影響を受ける OS タイプは、Ubuntu PRO、SUSE 24/7、および HA を備えた RHEL です。
AWS 環境の分析では、AWS Marketplace のコストは考慮されません。
• 既知の問題：
プラットフォームを更新後、Embedded Reports が表示されないことがあります。
状況によっては、Workload Optimization Manager を新しいバージョンに更新した後、[組み込みレポート（Embedded Reports）] ページが表示されないことがあります。更新は正常に完了したように見え、Embedded Reports コンポーネントは実行中で、準備ができているように見えますが、[Embedded Reports] ボタンをクリックすると、次のエラーが表示されます。
認証プロキシ ヘッダーで指定されたユーザーとしてログインできませんでした。
これは、ホスト VM がすべてのプラットフォーム コンポーネントを完全に起動するのに時間がかかる場合に発生する可能性があります。この問題が発生した場合は、すべてのコンポーネントが実行されていることを確認してから、次のコマンドを実行して grafana ポッドを再起動します。
kubectl delete pod -l app=grafana
サポートについては、サポート担当者にお問い合わせください。
• 既知の問題：
ファブリック環境では、ビューの範囲をデータセンターにすると、関連するすべてのホストエンティティがサプライチェーンに含まれない場合があります。
ファブリック ターゲットを含む環境では、状況によっては、データセンターを対象とするビューに、関連するすべてのホスト エンティティが含まれない場合があります。これは、ホスト名にハイフン文字（「-」）を含むホストで発生する可能性があります。たとえば、Cisco UCS ターゲットの場合、範囲をデータセンター エンティティにすると、サプライ チェーンには、名前にハイフン文字が使用されている UCS ホストは表示されません。
• 既知の問題：
Azure の場合、状況によっては、成功したスケーリングアクションが失敗としてログに表示されます。
可用性セットを含むAzure環境では、一部の状況では、成功したスケーリング アクションが失敗として Workload Optimization Manager ログに表示されます。
• 既知の問題：
実行済みアクションチャートでは、環境から削除されたエンティティに対するアクションの一部のデータが失われます。
実行済みアクション チャートを表示したり、チャートからデータをエクスポートしたりすると、環境から削除されたエンティティに対するアクションの一部のデータが失われます。たとえば、ストレージ ボリュームでアクションが実行され、そのボリュームが後で環境から削除されたとします。その場合、そのアクションのエクスポートされたデータには、削除されたボリュームを説明する値は含まれません。
• 既知の問題：
Azure の場合、プロキシ経由でターゲットに接続すると、ターゲットは接続されていないストレージ ボリュームを検出しません。
Azure 環境の場合、プロキシ経由で Azure ターゲットに接続すると、Workload Optimization Manager は接続されていないボリュームを検出しません。
• 既知の問題：
オンボーディングウィザードを閉じることができない場合があります。
最初に Workload Optimization Manager をインストールすると、ユーザ インターフェイスにオンボーディング ウィザードが表示され、ライセンスの設定と最初のターゲットの設定を行うことができます。状況によっては、ウィザードのワークフローを終了するボタンを押してもウィザードが閉じないことがあり、Workload Optimization Manager セッションを続行できなくなることがあります。
[セットアップの終了（End Setup）] をクリックしてもオンボーディングウィザードが閉じない場合は、ブラウザを更新すると、ウィザードが閉じ、最後にアクセスしたユーザーインターフェイスのページが表示されます。
• 既知の問題：
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）] チャートからの CSV ファイルのダウンロードは失敗します。
• 既知の問題：
まれに、etcd.service が失敗することがあります。
まれに、Workload Optimization Manager プラットフォームが応答を停止します。これは、etcd.service が失敗した場合に発生します。失敗した場合、次のエラーが表示されます。
デーモンからのエラー応答: etcd1 という名前のエンドポイントがネットワーク ホストにすでに存在します
この状況から回復するには、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 というグループ名を作成することがありますが、ユーザーがその名前を使用できる可能性があることに注意してください。
– 新しい VM 自動化ポリシーを作成します。このポリシーは、ストレージ移動アクションを無効にします。
– 作成したグループをポリシー スコープとして設定します。
– [アクションの自動化（Action Automation）] で、[ストレージの移動（Storage Move）] アクションを追加して [無効（Disabled）] に設定します。
• 既知の問題：
最適な改善チャートに、一時停止するホストの誤ったデータが表示されることがあります。
アクションでホストを一時停止することが推奨されている場合、最適な改善チャートには、一時停止するホストが使用されていないことが示されているはずです。状況によっては、チャートにこれらのホストの使用率が表示される場合があります。その結果、現在のスコープ内の他のホストでの使用率が誤って低い値となります。
• 既知の問題：
vSAN 環境の場合、状況によっては、データセンターを対象とするプランが失敗することがあります。
vSAN 環境の場合、環境にホストを追加または置換するプランを実行すると、状況によってはプランのホスト数が正しく表示されず、プランが失敗することがあります。
これは、次の条件を満たすプランで発生する可能性があります。
– プラン タイプは、[ハードウェア更新（Hardware Refresh）]、[ワークロードの追加（Add Workspace）]、または [カスタム（Custom）] です。
– プラン スコープはデータセンターに設定され、vSAN ホストが含まれます。
– プランでは、HCI テンプレートを使用してホストを置き換えます
実行後、プランにはプラン範囲内のホストの数ではなく、vSAN環境内のホストの完全な数が表示されます。
この状況を回避するには、計画の範囲をデータセンターに限定しないでください。
• 既知の問題：
すべてのオンプレミスホストのヘッドルームチャートは、上位クラスタチャートと必ずしも一致しません。
すべてのオンプレミス ホストのヘッドルーム チャートは、[上位クラスタ（Top Clusters）] チャートと必ずしも一致しません。
Workload Optimization Manager では、すべてのオンプレミスホストのヘッドルームデータが夜間プランで生成されます。計画を実行すると、このデータは正しいものになります。このデータは 1 日のうちに失効する可能性があります。
クラスタの使用状況を正確に追跡するには、[上位クラスタ（Top Clusters）] チャートを使用する必要があります。
• 既知の問題：
vCenter Server 環境の場合、Workload Optimization Manager は、ClusterDependencyRule に基づいた VM 再起動の依存関係に関する DRS ルールを認識しません。
vCenter Server 環境の場合、Workload Optimization Manager は、ClusterDependencyRule に基づく VM 再起動の依存関係の DRS ルールを認識しません。
依存関係を ClusterVmHostRule またはクラスタ アフィニティまたはアンチアフィニティ ルールで表現することで、同様の効果を達成できる場合があります。
フィードバック