Cisco UCS Workload Optimization Manager リリース ノート、リリース 3.4.4
 |
Workload Optimization Manager 3.4.4 リリースノート
2022 年 9 月 23 日
このドキュメントでは、Workload Optimization Manager 3.4.4 –リリース日：2022 年 9 月 23 日 － で対応した問題について説明します。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.4.4 |
8.6.4 |
| 3.4.3 |
8.6.3 |
| 3.4.2 |
8.6.2 |
| 3.4.1 |
8.6.1 |
| 3.4.0 |
8.6.0 |
| 3.3.7 |
8.5.7 |
| 3.3.6 |
8.5.6 |
| 3.3.5 |
8.5.5 |
Kubeturbo ポッドの構成方法の詳細については、https: //github.com/ turbonomic/kubeturbo にある Kubeturbo GitHub リポジトリを参照してください。
Kubeturbo ターゲットと他のターゲットの詳細については、『Workload Optimization Manager Target Configuration Guide』を参照してください。
バージョン 3.4.4 の新機能
バージョン 3.4.4
▪ 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 アクション」を参照してください。
▪ Red Hat OpenShift のインストール手順
設置ガイドに、Red Hat OpenShift に Workload Optimization Manager をインストールする手順が含まれるようになりました。インストールを実行する前に、インストールの前提条件と手順を確認してください。
詳細については、設置ガイドの「Red Hat OpenShift クラスタへのインストール」を参照してください。
バージョン管理の説明
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 トークンを必ず使用してください。
詳細については、既知の問題「Dynatrace ターゲットの場合、API トークンを更新する必要があります...」を参照してください。（8 ページ）。
Workload Optimization Manager のアップデートと Operator のバージョン
Workload Optimization Manager は、Kubernetes クラスタにクラウドネイティブ アプリケーションとしてデプロイされます。このクラスタは、展開する VM 上に事前構成することも、Workload Optimization Manager を環境内の Kubernetes クラスタに展開することもできます。いずれの場合も、Workload Optimization Manager は Operator を使用してアプリケーションのデプロイメントを管理します。
Workload Optimization Manager のさまざまなバージョンについて、使用する必要がある Operator のバージョンを次のように変更します。
| 製品バージョン: |
Operator のバージョン： |
| 3.4.4 |
42.16 |
| 3.4.3 |
42.15 |
| 製品バージョン: |
Operator のバージョン： |
| 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 設置ガイド』の最新バージョンの指示に従ってオンラインまたはオフラインで更新を実行すると、最新の Operator が自動的に含まれます。
Workload Optimization Manager を Kubernetes クラスタにインストールした場合は、Operator のバージョンを手動で更新する必要がある場合があります。
Workload Optimization Manager の OpenShift のインストール
OpenShift 4.x 以降のバージョンで、OpenShift OperatorHub を介してインストールを管理している場合は、OPC コンソールから [インストール済みオペレータ（Installed Operators）] に移動します。使用する Workload Optimization Manager の Operator のバージョンを選択し、[更新（Update）] をクリックします。これにより Operator が更新され、Workload Optimization Manager を一致するバージョンに更新できるようになりました。
Workload Optimization Manager のその他の Kubernetes インストール
サポートされている他の Kubernetes プラットフォームにインストールする場合は、次の 2 つの方法のいずれかで Operator のバージョンを更新できます。
▪ Workload Optimization Manager の実行中のデプロイメントを直接編集します。
1. クラスタの編集モードに入ります。
kubectl edit deployment t8c-operator -n {自分のネームスペース}
2. Operator イメージを編集します。
イメージを検索し、image: {必須の値} により編集します。
3. Operator ポッドの準備ができていることを確認します。
コマンド kubectl get pods -n {YourNamespace} を実行し、ポッドが起動しており、準備ができていることを確認します。
▪ Workload Optimization Manager デプロイメント yaml ファイルを編集します。
1. Operator デプロイメント ファイルを開いて編集します。
マニフェストを保存する場所で、operator.yaml ファイルを開きます。これは、t8c-operator ポッドを展開するために使用するファイルである必要があります。
2. Operator イメージを編集します。
イメージを検索し、image: {必須の値} により編集します。
3. operator に変更を適用します。
kubectl apply -f operator.yaml
4. Operator ポッドの準備ができていることを確認します。
コマンド kubectl get pods -n {YourNamespace} を実行し、ポッドが起動しており、準備ができていることを確認します。
Operator のバージョンを更新し、ポッドが実行中で準備ができていることを確認したら、カスタム リソース宣言を編集して、Workload Optimization Manager を Operator のバージョンと一致するバージョンに更新できます。
詳細については、サポート担当者に問い合わせてください。
OVA および VHD インストールでサポートされる MariaDB バージョン
OVA および VHD インストールのデフォルトの履歴データベースとして、Workload Optimization Manager は現在、MariaDB バージョン 10.5.16 をサポートしています。このサポートには、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.16 を使用する必要があります。バージョン 3.3.6 より前に OVA または VHD としてインストールしたバージョンの Workload Optimization Manager で、MariaDB を 10.5.16 に明示的に更新していない場合は、ここで更新する必要があります。
MariaDB インスタンスの更新については、「Verifying your MariaDB Version」を参照してください。次に記載されています。
Workload Optimization Manager インストール ガイド。
外部データベースの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 以上の長さの証明書キーを生成する手順に従ってください。これで問題が解決しない場合は、シスコ テクニカル サポートにお問い合わせください。
修正済みの問題
• 修正済みの問題：
バージョン 3.4.3 に更新した後、prometheus-server ポッドが ContainerCreating の状態のままです。
バージョン 3.4.3 に更新した後、prometheus-server ポッドは ContainerCreating 状態のままです。
• 修正済みの問題：
Azure の場合、状況によっては、課金対象が RI の使用状況を検出しません。
Azure サブスクリプションの唯一のコストが RI の場合、Azure 環境は課金オファーの ID を返しません。その場合、検出は関連するコストを処理せず、影響を受ける RI の使用を認識しません。
• 修正済みの問題：
一時的なエンティティが多数ある環境では、トポロジ データの履歴処理によってパフォーマンスの問題が発生する可能性があります。
Workload Optimization Manager は、トポロジ内のエンティティの履歴データを保存します。ただし、多くの一時的なエンティティ（寿命が限られているエンティティ）がある環境では、トポロジ プロセッサでパフォーマンスの問題が発生する可能性があります。この場合、ユーザー インターフェイスには不完全なデータが表示される可能性があります。
この問題が発生した場合は、次の内容を含むエラーが表示されます。
ERROR [realtime-pipeline-runner] [TimeSlotEditor]：メンテナンスに失敗しました...
• 修正済みの問題：
まれな状況下で、ユーザーインターフェイスに再構築イベントの通知が表示されることがあります。
まれに、Workload Optimization Manager がユーザーインターフェイスに再構築イベント通知を表示することがあります。ログは、次の内容を含むメッセージも表示できます。
ERROR [PercentileEditor]：再構築に失敗しました...
これは、プロセスが接続に対して null 値を取得したが、その接続を閉じようとした場合に発生する可能性があります。
• 修正済みの問題：
MySql ターゲットの場合、まれに検出が失敗することがあります。
MySql ターゲットの場合、まれに検出が失敗することがあります。これは、検出が空のデータ セットにアクセスしようとしたときに発生する可能性があります。
• 修正済みの問題：
接続されていないボリュームの動的グループは、メンバーにアクション ポリシーを適用できない場合があります。
Days Unattached フィルタを使用して、非接続ボリュームの動的グループを作成するとします。アタッチされていないボリュームを削除するポリシーをこのグループに割り当てた場合、ポリシーは有効になりません。
• 修正済みの問題：
VMware Horizon 環境の場合、状況によっては検出が完了しないことがあります。
これは、環境にネストされたグループ、またはメンバーを共有するグループが含まれている場合に発生する可能性があります。
• 修正済みの問題：
vCenter Server の場合、状況によっては、検出によりサプライ チェーンの構築に失敗することがあります。
vCenter Server 環境では、エンティティは、同じプロパティ キーを持つ複数のキーを提供する VCTAGS 名前空間でタグ付けを使用できます。この場合、検出は次の内容を含むエラーで失敗します。
StitchingManager : スティッチング操作を適用できません
StringsToStringsDataDrivenStitchingOperation...
• 修正済みの問題：
コンテナ仕様のアクション ポリシーの場合、アクションをオーケストレーションに渡すポリシーを使用することはできません。
コンテナ仕様ポリシーの場合、承認のためにアクションを ServiceNow に送信するポリシーを定義できます。ただし、Workload Optimization Manager は、ポリシーをコンテナ仕様の範囲に適用しません。
• 修正済みの問題：
Data Extractor コンポーネントは、ログをメッセージでフラッドさせる可能性があります。
状況によっては、エクストラクターが環境内のすべてのエンティティに共通のエラーに遭遇した場合、不要な繰り返しメッセージでログをフラッドさせる可能性があります。ログにエラーが 1 回リストされ、インシデントの数が提供されるようになりました。
• 修正済みの問題：
Google Kubernetes Engine（GKE）環境の場合、ワークロード移行プランはポッドの配置に失敗する可能性があります。
ポッドを GKE クラスタに配置するワークロード移行プランを実行すると、プランはポッドの配置に失敗することがあります。
• 修正済みの問題：
HPE OneView の場合、特定の状況下でターゲットの検証が失敗する可能性があります。
HPE OneView の場合、特定の状況下で、ターゲットの検証が次のようなエラーで失敗する可能性があります。
MalformedJsonException：行 1 の無効なエスケープシーケンス...
既知の問題
• 既知の問題：
以前のバージョンからの更新は、vCPU スケーリング ポリシーに影響を与える可能性があります。
3.3.x バージョン ファミリから 3.4.x バージョン ファミリにアップグレードする場合、更新は、仮想マシンのデフォルト ポリシーで定義されているオンプレミス VM の vCPU スケーリングに影響を与える可能性があります。
以前のバージョンで、仮想マシンのデフォルト ポリシーの vCPU 設定の増分定数を変更した場合は、製品の更新を実行する前に、vCPU スケーリング ポリシーの設定に関する新しいドキュメントを確認する必要があります。
製品の更新を実行したら、次の点を考慮する必要があります。
– 新しい vCPU スケーリング制御を使用して、目的の vCPU サイズ変更結果を実現します。
– vCPU Resize Min Threshold（コア内）設定を使用して、VM のサイズが必要な vCPU 数を下回らないようにします。
– MHz でのカスタムのデフォルト設定を引き続き使用するには、vCPU スケーリング制御（MHz の従来の動作）を使用します。
• 既知の問題：
状況によっては、ストレージの概要チャートに誤った数のボリュームが表示されることがあります。
ストレージ サマリ チャートのボリュームの合計数を階層のボリュームの合計数と比較すると、カウントが一致しない可能性があります。
Dynatrace ターゲットの場合、ターゲット構成に使用する API トークンを更新して、Dynatrace API の V1 および V2 をサポートするようにする必要があります。
ターゲット構成ガイドには、既存の Dynatrace ターゲットの API トークンを更新する必要があることは特に記載されておらず、トークンが各 API バージョンに必要とする新しいアクセス許可もリストされていません。
新しい Dynatrace ターゲットを構成するには、以下にリストされているアクセス許可を持つアクセストークンを生成します。
Workload Optimization Manager 3.4.2 より以前のバージョンから、3.4.2 またはそれ以降のバージョンにアップデートする場合、既存の Dynatrace ターゲットごとに新しい API ターゲットを生成する必要があります。トークンをターゲット構成に入力し、そのターゲットを検証する必要があります。
注：
状況によっては、新しいトークンをターゲットに追加しても、まだ検証されません。その場合は、構成設定をメモし、ターゲットを削除して、ターゲットを再度構成します。生成した新しい API トークンを必ず使用してください。
Dynatrace API トークンには、Dynatrace API の V1 および V2 にアクセスするためのアクセス許可が含まれている必要があります。次の範囲で汎用トークンを生成します。
| Workload Optimization Manager の機能 |
必要なアクセス許可 |
| モニタリング |
– API V1 範囲： • アクセスの問題およびイベント フィード、メトリック、およびトポロジ – API V2 範囲： • エンティティの読み取り • メトリックの読み取り |
• 既知の問題：
スケーリングに使用できるより小さなインスタンス タイプがある場合でも、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
さらにサポートについては、サポート担当者にお問い合わせください。
• 既知の問題：
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 列に現在のデータが表示されない場合があります。
上位のアカウント グラフを表示しているときに、[すべて表示（Show All）] をクリックして詳細テーブルを表示できます。状況によっては、このテーブルが、[実行済みのアクション（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）]セクションで、topology-processor コンポーネントのエントリを見つけます。
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] :（ターゲットのディスカバリ ダンプが保持されない）
ご使用の環境でこれが発生した場合は、回避策についてサポート担当者にお問い合わせください。
• 既知の問題：
Workload Optimization Manager と Google Cloud Platform（GCP） に表示される課金額は、時差により一致しません。
Workload Optimization Manager は UTC を使用し、GCP は現地時間を使用するため、Workload Optimization Manager のグラフと GCP 請求レポートに表示される請求コストは一致しません。ただし、両方の場所に示されているコストは正確で信頼できます。
• 既知の問題：
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 を更新すると、まれに topology-processor ポッドの再起動に失敗することがあります。ログには、次のステートメントのエラーが投稿されます。
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 というグループ名を作成することがありますが、ユーザーがその名前を使用できる可能性があることに注意してください。
– 新しい自動化ポリシーを作成します。このポリシーは、ストレージ移動アクションを無効にします。
– 作成したグループをポリシー スコープとして設定します。
– [アクションの自動化（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 またはクラスタ アフィニティまたはアンチアフィニティ ルールで表現することで、同様の効果を達成できる場合があります。
フィードバック