新機能

Turbonomic 8 は、次世代アーキテクチャーを採用しています。これにより、コア・プラットフォームは、単一インスタンス・デプロイメントで大規模なアプリケーション環境とインフラストラクチャー環境に合わせて拡張できます。 これにより、複雑さが解消され、スケール・オンデマンド機能が提供されると同時に、アプリケーションのパフォーマンスと正常性が引き続き保証されます。

注:

製品またはサード・パーティーのターゲットを頻繁に変更するには、一部の機能が更新されているか、非推奨になっているか、削除されているか、またはサポートされなくなっている必要があります。 これらの機能について詳しくは、 機能の更新と特記事項を参照してください。

バージョン 8.12.6

  • GenAI Large Language Model (LLM) 推論ワークロードのスケール・アクション

    GPU リソースを使用し、 Kubernetes クラスターにデプロイされる GenAI 大規模言語モデル (LLM) 推論ワークロードの場合、 Turbonomic は、これらのワークロードのサービス・レベル目標 (SLO) を維持するためのワークロード・コントローラー・スケール・アクションを生成できるようになりました。

    詳しくは、 GenAI LLM 推論ワークロードのスケール・アクションを参照してください。

  • Google Kubernetes Engine (GKE) クラスターのノード・プロビジョンおよび中断アクション

    Google Kubernetes Engine (GKE) クラスター内のノードの場合、 Turbonomic は、ワークロードの輻輳 (ふくそう) に対処するためのノード・プロビジョン・アクションや、インフラストラクチャーの効率を向上させるためのノード・サスペンド・アクションを生成できるようになりました。

    詳しくは、「 ノードのプロビジョンおよび中断のアクション」を参照してください。

    これらのアクションを実行するには、 Turbonomic が Kubernetes または Red Hat OpenShift ターゲットおよび Google Cloud ターゲットを介して GKE クラスターに接続できる必要があります。 Google Cloud ターゲットの場合、サービス・アカウントには以下の権限が必要です。

    • compute.instanceGroupManagers.update

    • compute.instanceGroups.get

    • container.clusters.get

    • container.clusters.update

    許可の完全なリストについては、 Google Cloud ターゲットの許可を参照してください。

  • カスタム・マシン・タイプを実行している Google Cloud VM のスケール・アクション

    Turbonomic は、パフォーマンスとコストを最適化するために、 カスタム・マシン・タイプ を実行する Google Cloud VM のスケール・アクションを生成できるようになりました。 現在、 Turbonomic は、 N1、 N2、および N2D カスタム・マシン・シリーズをサポートしています。

  • Google Cloud VM に関する過去の情報に基づくアクション生成

    Turbonomic は、新しい Google Cloud ターゲットが追加されたのと同じ日に、履歴使用状況データによって通知される VM スケール・アクションを生成できるようになりました。

    この機能を利用するには、少なくとも 1 つの Google Cloud ターゲットを追加します。 ターゲットのサービス・アカウントには、 logging.logEntries.list 権限が必要です。 許可の完全なリストについては、 Google Cloud ターゲットの許可を参照してください。

    注:

    現在、VM スケール・アクションでは、入出力スループットを除くすべてのモニター対象リソースのヒストリカル使用率が考慮されます。

  • 新たにサポートされた AWS インスタンス・ファミリーおよびリージョン

    このリリースでは、以下の AWS インスタンス・ファミリーおよびリージョンのサポートが導入されています。

    インスタンス・ファミリー

    • C6id, C6in, C7a, C7g, C7gd, C7gn, C7i

    • Hpc7g

    • I4g, I4i

    • M6id, M6idn, M6in, M7a, M7gd, M7i, M7i-Flex

    • R6a, R6id, R6idn, R6in, R7a, R7gd, R7i, R7iz

    • U-1 (高メモリー)- u-18tb1 および u-24tb1 のみ

    リージョン

    • ap-south-2 -アジア太平洋 (ハイデラバード)

    • ap-southeast-4 -アジア太平洋 (メルボルン)

    • ca-west-1 -カナダ西部 (Calgary)

    • eu-central-2 -ヨーロッパ (Zurich)

    • eu-south-2 -ヨーロッパ (スペイン)

    • il-central-1 -イスラエル (テル・アビブ)

    • me-central-1 -中東 (UAE)

  • Azure Zone-redundant Storage (ZRS) のサポート

    Turbonomic は、プレミアム SSD および標準 SSD 管理対象ディスクを使用して Azure zone-redundant storage (ZRS) をディスカバーするようになりました。

    Turbonomic は、パフォーマンスとコストを最適化するために、ZRS のボリューム・スケール・アクションを生成できます。 ZRS が現在接続されていない場合、 Turbonomic は、コスト削減策としてボリューム削除アクションを即時に生成します。 これらのアクションに関連付けられた節減と投資は、「節減」、「累積節減」、「投資」、および「累積投資」の各グラフで追跡されます。

  • 外部で実行されたクラウド・アクションの追跡

    Turbonomic は、外部で実行したクラウド・ワークロードのアクションを追跡するようになりました。 例えば、クラウド・プロバイダーを介してこれらのアクションを実行した可能性があります。

    以下のグラフを使用して、関連データを表示します。

    • 節減、累積節減、投資、および累積投資

      これらのグラフに表示される合計金額には、外部で実行されるアクションに関連付けられた削減額または投資が含まれるようになりました。

    • 実行されたアクション-成功

      外部で実行されるアクションの場合、「実行」列には「外部で実行」が表示されます。

  • 「ターゲット構成」ページの新規設計フレームワークへのマイグレーション

    ユーザー・インターフェースの 「設定」>「ターゲット構成」 ページで、新しい設計フレームワークが使用されるようになりました。

    これは、製品をフレームワークに移行するための継続的な取り組みの一環であり、より最新のルック・アンド・フィールを備えた高性能のユーザー・インターフェースを提供します。

    新規フレームワークに切り替えるには、ユーザー・インターフェースのナビゲーション・バーで 反応アイコン をクリックしてから、トグルをオンにします。 詳しくは、 ユーザー・インターフェースの設計フレームワークを参照してください。

  • ServiceNow Washington DC Release のサポート

    Turbonomic ServiceNow のアクションは、 ServiceNow® 変更管理アプリケーションに Turbonomic の機能をもたらす統合です。 Turbonomic Actions 1.1.11 は、 ServiceNow Washington DC releaseをサポートするようになりました。 この統合は、 ServiceNow ストアからダウンロードできます。 詳しくは、 Turbonomic Actions for ServiceNow の資料を参照してください。

バージョン 8.12.5

  • Flexera ターゲットの機能拡張

    FlexNet Manager Suite 2023 R2 (オンプレミス) を Turbonomic でターゲットにして、既存の Flexera One (SaaS) 統合と同じ方法でソフトウェア・ライセンス資産をディスカバーできるようになりました。 ソフトウェア・ライセンス資産を検出することで、 Turbonomic は、ワークロードをよりインテリジェントに配置またはサイズ変更して、ライセンス・ポリシーに確実に準拠することができます。 運用チームは、これらの制約を手動で定義する必要がなくなりました。 アプリケーション所有者は、 Turbonomic を使用してライセンス使用量を最適化することにより、 Flexera One および FlexNet Manager で最適化されたライセンス使用量を確認できます。

    Flexera ターゲットのカテゴリー名が「Orchestrator」から「IT 管理」に変更されました。

    詳しくは、 Flexeraを参照してください。

  • コンテナー・ポッドの移動アクションの機能拡張

    このリリースでは、ポッド間アフィニティーおよびアンチアフィニティーを処理するためのメカニズムが拡張されています。 この機能拡張により、 Turbonomic は、アフィニティー・ルールおよびアンチアフィニティー・ルールに準拠した、より正確なコンテナー・ポッド移動アクションを生成しながら、ターゲット環境を継続的に望ましい状態に導くことができるようになりました。 これらのアクションをアクション・センターで確認するには、アクション・カテゴリーが「コンプライアンス」で、リスクが「満たされていないアフィニティー制約」または「満たされていないアンチアフィニティー制約」のコンテナー・ポッド移動アクションを探します。

    詳しくは、 ポッド・アフィニティー・ルールとアンチアフィニティー・ルールを参照してください。

バージョン 8.12.4

  • EC2 GPU インスタンス・タイプを実行する AWS VM の機能拡張

    • 追加の NVIDIA GPU メトリックのサポート

      Turbonomic は、サポートされる EC2 GPU インスタンス・タイプを実行する AWS VM の以下の NVIDIA GPU メトリックをディスカバーするようになりました。

      • GPU FP16、 FP32、および FP64

      • GPU テンソル

      • GPU メモリー BW

      Turbonomic は、これらのメトリックを使用して、パフォーマンスとコストを最適化する VM スケール・アクションを生成します。 これらのメトリックは、 「容量と使用量」 グラフおよび 「複数リソース」 グラフで表示できます。

      詳しくは、 Support for AWS EC2 GPU Instance Typesを参照してください。

      これらのメトリックのディスカバリーを有効にするには、NVIDIA データ・センター GPU マネージャー (DCGM) を構成します。 詳しくは、 Linux Configuration for NVIDIA GPU Metrics (DCGM)を参照してください。

    • NVIDIA GPU 計算機能を無視

      この制約は、 AWS VM の自動化ポリシーをオンにするために選択できる設定です。 この設定をオンにすると、VM の GPU 計算能力 を変更するスケール・アクションを Turbonomicで実行できるようになります。

  • 「請求およびコスト」ページの新規設計フレームワークへのマイグレーション

    ユーザー・インターフェースの 「設定」>「請求およびコスト」 ページで、新しい設計フレームワークが使用されるようになりました。

    これは、製品をフレームワークに移行するための継続的な取り組みの一環であり、より最新のルック・アンド・フィールを備えた高性能のユーザー・インターフェースを提供します。

    新規フレームワークに切り替えるには、ユーザー・インターフェースのナビゲーション・バーで 反応アイコン をクリックしてから、トグルをオンにします。

  • Prometheus ターゲットの管理の向上

    業界用語に合わせるために、 Prometheus ターゲットのカテゴリー名が「カスタム」から「プログラム識別情報」に変更されました。

    Turbonomic は、 Red Hat OpenShiftの OperatorHub にデプロイした Prometurbo エージェントを介して、 Prometheus サーバーからアプリケーション・メトリックを収集します。 このリリースでは、Prometurbo を簡単にデプロイおよび管理できるように、以下の改善が導入されています。

    • ユーザー・インターフェースで、 「設定」>「ターゲット構成」>「新規ターゲット」>「プログラム識別情報」> Prometheusにナビゲートすると、 OperatorHubで 直接 構成する必要がある設定を含め、Prometurbo のデプロイメント・プロセスを順に説明するガイドが表示されるようになりました。 ユーザー・インターフェースで設定を構成する必要はありません。

      注:

      Prometurbo のデプロイメント・ガイドは、 Turbonomic の資料でも入手できます。 詳しくは、 Prometheusを参照してください。

      GitHub の Prometurbo デプロイメント・ガイドは保守されなくなり、廃止されます。 最新情報については、必ず Turbonomic の資料を参照してください。

    • デプロイメント後、Prometurbo は、ユーザー・インターフェースの 「設定」>「ターゲット構成」で Prometheus ターゲットとして自身を自動的に追加します。 ターゲットの詳細を表示すると、Prometurbo デプロイメントに関する読み取り専用情報が表示されるようになりました。 変更を行うには、 OperatorHubで Prometurbo の構成を更新します。

  • OAuth 2.0 トークンを使用した Turbonomic API によるプログラマチック認証

    このリリースには、新しい OAuth 2.0 機能が組み込まれています。これにより、 Turbonomic API を使用してプログラマチックに認証する方法が容易になります。 Turbonomic API を使用して、OAuth 2.0 クライアントを作成、リスト、および削除できるようになりました。 クライアントを作成した後、アクセス・トークンのクライアント資格情報をプログラマチックに交換することができます。

    詳しくは、 API を使用した OAuth 2.0 クライアントの認証を参照してください。

バージョン 8.12.3

  • VM 移動およびホスト中断アクションのサステナビリティー・メトリック

    オンプレミス環境の場合、 「Turbonomic」 では、VM 移動アクションおよびホスト中断アクションのアクション詳細に、炭素フットプリントおよびエネルギー使用量の予測変更が表示されるようになりました。 ホスト中断アクションの場合、 「アクション・センター」 要約の新しい 「エネルギー使用量」 列には、ホストのエネルギー使用量データも表示されます。 詳しくは、 VM 移動およびホスト中断アクションのサステナビリティー・メトリックを参照してください。

バージョン 8.12.2

  • Azure Azure Government の請求ターゲット・サポート

    Azure Billing ターゲットは、 Azure Government ワークロードの請求データをディスカバーおよびモニターできるようになりました。 請求データをシームレスにモニターするには、 Support for Azure Governmentで概説されているガイドラインに従ってください。

    この新機能により、 Turbonomicグローバル Azure と Azure Government の両方のワークロードの請求データをモニターするために必要とする唯一のターゲットは、 Azure Billing ターゲットになりました。 Microsoft Enterprise Agreement のターゲットは不要になったため、サポートが終了しました。 ユーザー・インターフェースの 「設定」>「ターゲット構成」 ページに既存の Microsoft Enterprise Agreement ターゲットがある場合は、ターゲットを即時に削除してから、 Azure Billing ターゲットをセットアップします。 サポート終了および次のステップについて詳しくは、 注: Microsoft Enterprise Agreement Targetを参照してください。

バージョン 8.12.1

  • AWS Standard Data Exports (CUR 2.0) のサポート

    AWS Billing ターゲットは、 AWS Billing and Cost Management コンソールでセットアップした標準データ・エクスポート (CUR 2.0) から請求データを取得できるようになりました。

    以前に AWS 請求ターゲットで使用するためにレガシー CUR エクスポートをセットアップしており、ここで標準データ・エクスポートに切り替える場合は、以下のようにします。

    1. 標準データ・エクスポートをセットアップします。 詳しくは、 標準データ・エクスポート (CUR 2.0) のセットアップを参照してください。

    2. Turbonomic ユーザー・インターフェースで、既存の AWS Billing ターゲットを削除してから、新しいターゲットを追加します。 新規ターゲットで、標準データ・エクスポートの S3 バケット名、 S3 パス接頭部、および S3 バケット領域を指定します。

    注:

    さらに通知があるまで、引き続きレガシー CUR エクスポートを使用することができます。

  • AWS RDS ディスカウント・グラフのデータ

    AWS RDS 予約済みインスタンス (RI) の場合、「割引使用状況」グラフおよび「割引範囲」グラフで使用状況データおよびカバレッジ・データを使用できるようになりました。

    注:

    現在、使用状況データはデータベース・サーバーのスケーリングの推奨では考慮されません。 さらに、 Turbonomic は、 RDS RI を購入するためのアクションを生成しません。

  • Azure ボリューム削除アクションの機能拡張

    Turbonomic は、 Azure ボリュームの DiskState プロパティーをチェックして、それらの接続状態を正確に判別するようになりました。 DiskStateUnattachedの場合、 Turbonomic はボリュームを削除するアクションを生成します。

  • テレメトリーと使用状況のデータ共有

    バージョン 8.12.1にアップグレードした後、 Turbonomic テレメトリーおよび使用状況データ共有機能が自動的に有効になります。 IP アドレスや近似地理位置情報などのテレメトリー・データは、 IBM またはそのサブプロセッサー (あるいはその両方) に自動的に送信されます。 このデータは、製品開発および機能改善のために IBM によってのみ使用されます。 テレメトリー・データの自動アップロードは、 「設定」>「保守オプション」>「テレメトリー・データ共有」 ページで無効にすることで、いつでもオプトアウトできます。

    詳しくは、「 保守オプション」を参照してください。

バージョン 8.12.0

Application Performance Management

  • IBM Instana プログラム識別情報 (Instana) との両方向統合

    このリリースでは、両方向の統合をセットアップすることにより、 Turbonomic および Instana プログラム識別情報 (Instana) の利点を最大限に活用できます。 この両方向統合により、Instana UI の Turbonomic から、実行されたパフォーマンス・アクションと推奨されるパフォーマンス・アクションを表示できます。 これらのアクションは、Instana によってモニターされるエンティティーのパフォーマンスを向上させることを目的としています。

    詳しくは、 Instana-Turbonomic Two-Way 統合の有効化を参照してください。

  • 新規 Relic の機能拡張

    • このリリースでは、New Relic ターゲット・ページにターゲット名を追加する機能が導入されました。 ターゲット構成ページで、アカウント ID ではなくターゲット名に基づいて New Relic ターゲットを識別できるようになりました。 この名前は表示のみを目的としているため、必要に応じてターゲット名をカスタマイズでき、その名前は New Relic 内のどの名前とも一致する必要はありません。 複数の New Relic ターゲットが 「Turbonomic」に追加されている場合は、各ターゲットに固有の名前を付けます。

      注:

      ターゲット名フィールドには、英数字、スペース、またはハイフンのみを含めることができます。

    • New Relic ターゲットを追加するときに、New Relic プラットフォームによって提供されるユーザー・キーを新しい「ユーザー・キー」フィールドに追加できるようになりました。 あるいは、「REST API キーと GraphQL API キーの使用」トグル・ボタンを選択して、REST API キーと GraphQL API キーを指定します。

      REST API キー・フィールドおよび GraphQL API キー・フィールドではなく、ユーザー・キー・フィールドを使用することをお勧めします。

    • New Relic ターゲットを追加または編集するときに、「ターゲット名」フィールドがターゲット構成ページの上部に表示されるようになりました。

    • New Relic ロゴが Turbonomic UI 全体で更新されました。

    詳しくは、 New Relicを参照してください。

  • AppDynamics、Instana、および Dynatrace ターゲットのサーバー証明書の検証

    AppDynamics、Instana、および Dynatrace ターゲットに「サーバー証明書の検証 (Verify Server Certificate)」オプションが含まれるようになりました。これにより、追加するターゲットに有効な証明書とプロキシーがあることが確認されます (該当する場合)。

    既存のターゲットの場合、値はデフォルトで false に設定されます。 ターゲットを確認して、この機能を有効にするかどうかを決定します。

  • アプリケーション・コンポーネントのアクションおよびポリシー設定の機能拡張

    このリリースでは、アプリケーション・コンポーネント・エンティティーとその関連商品 (ヒープやガーベッジ・コレクションなど) は、パーセンタイル計算を使用してアクションを生成します。 さらに、アプリケーション・コンポーネント・ポリシー設定には、スケーリング制約として Aggressiveness と Observation Period が含まれるようになりました。

    詳しくは、「 アクションの詳細 」および「 アプリケーション・コンポーネント・ポリシー」を参照してください。

  • アプリケーション・トポロジー・ページの機能拡張

    「設定」>「アプリケーション・トポロジー」 ページでは、デフォルトで新しい設計フレームワークが使用されるようになりました。 詳しくは、 ユーザー・インターフェースの設計フレームワークを参照してください。

    さらに、以下の機能拡張がアプリケーション・トポロジー作成フローの一部として実装されました。 これらは、新しい設計フレームワークを使用しており、バックエンドで機能フラグが有効になっているユーザーのみが使用できます。

    • 「スコープ」、「検索」、および「グループ」の各ビュー・ページで、新しい 「エンティティーの作成」 ボタンを使用できます。

    • アプリケーション・トポロジーの作成プロセスを容易にするために、「アプリケーション・トポロジー」ページでクイック・ヘルプを使用できるようになりました。

  • Application Insights ターゲットの削除

    このリリースでは、Application Insights ターゲットは Turbonomicから削除されました。 バージョン 8.11.1にアップグレードした後、リストでターゲットを選択し、 「削除」をクリックして、「ターゲット構成」ページから既存の Application Insights ターゲットを削除します。

    Kubernetes デプロイメントの場合は、 Turbonomic カスタム・リソース (CR) ファイルから mediation-appinsights コンポーネントを削除することをお勧めします。

    詳しくは、 (オプション) プローブ・コンポーネントの有効化および無効化を参照してください。

コンテナー・リソース管理

  • コンテナー・プラットフォーム・ターゲットの管理の向上

    業界の用語に合わせて、コンテナー・プラットフォーム・ターゲットのカテゴリー名が「クラウド・ネイティブ」から「コンテナー・プラットフォーム」に変更されました。

    Turbonomic は、 Kubernetes および Red Hat OpenShiftをサポートし、Kubeturbo エージェントを介してこれらのコンテナー・プラットフォームに接続します。 このエージェントは、 Turbonomic が管理する各 Kubernetes または Red Hat OpenShift クラスターにデプロイする必要があります。 Kubeturbo を簡単にデプロイおよび管理できるように、このリリースでは以下の改善が導入されています。

    • ユーザー・インターフェースで、 「設定」>「ターゲット構成」>「新規ターゲット」>「コンテナー・プラットフォーム」をクリックすると、 Kubernetes および Red Hat OpenShift が別個のターゲットとして表示されるようになりました。

    • 特定のターゲットを選択すると、そのターゲットの Kubeturbo デプロイメント・プロセスを順を追って説明するガイドが表示されるようになりました。これには、クラスターで 直接 構成するために必要な設定も含まれます。 ユーザー・インターフェースで設定を構成する必要はありません。

    • デプロイメント後、Kubeturbo は、ユーザー・インターフェースの 「設定」>「ターゲット構成」で、自身を Kubernetes または Red Hat OpenShift ターゲットとして自動的に追加します。 ターゲットの詳細を表示すると、Kubeturbo デプロイメントに関する読み取り専用情報が表示されるようになりました。 変更を行うには、クラスター内の Kubeturbo 構成を更新します。

      Kubeturbo デプロイメント・ガイドは、 Turbonomic の資料にも記載されています。 詳しくは、 コンテナー・プラットフォーム・ターゲットで概説されているトピックを参照してください。

      注:

      GitHub の Kubeturbo デプロイメント・ガイドは保守されなくなり、廃止されます。 最新情報については、必ず Turbonomic の資料を参照してください。

  • ワークロード・コントローラーの細分化されたサイズ変更アクション

    Turbonomic が生成および自動化するワークロード・コントローラーのサイズ変更アクションを、サイズ変更する特定のリソースとサイズ変更の方向に基づいて制御できるようになりました。 例えば、CPU リミットのサイズ変更の場合、サイズ変更アクションを自動化する一方で、サイズ変更アクションの検討が必要になることがあります。 これらのルールを適用するには、ワークロード・コントローラー・ポリシーを作成し、「CPU 制限のサイズ変更」のアクション・モードを「 自動」に設定し、「CPU 制限のサイズ変更 (最大 手動)」に設定します。

    詳しくは、「 ワークロード・コントローラー・ポリシー」を参照してください。

  • コンテナー仕様ポリシーの機能拡張

    このリリースでは、 vCPU の制限と要求、 vMem の制限と要求、および CPU スロットルの許容度レベルを指定するコンテナー仕様ポリシーを構成する機能が導入されました。 この機能により、 「Turbonomic」 分析で、構成した許容度レベルを考慮した、より正確なサイズ変更アクションを生成できるようになりました。

    許容度レベルを簡単に構成できるように、コンテナー仕様の拡張ポリシー・ページに、 vCPU の制限と要求、 vMem の制限と要求、および CPU スロットルの個々のタブが含まれるようになりました。

    詳しくは、 コンテナー仕様ポリシーを参照してください。

  • Red Hat OpenShift MachineSetsのアクション実行の改善

    Kubeturbo は、 Red Hat OpenShift クラスターで MachineSet のノード・プロビジョンまたは中断アクションを実行する前に、 ConfigMapで指定されたノード・カウント範囲を検査するようになりました。 実行前チェックで、ノード・カウントがアクション実行後の範囲外になると判断された場合、アクションは実行されますが失敗し、失敗がログに記録されます (例えば、 Turbonomic ユーザー・インターフェースの「すべてのアクション」グラフなど)。 このメカニズムにより、 OpenShift クラスターの全体的な安定度とパフォーマンスが確保されます。

    デフォルトでは、最小ノード数は 1 で、最大ノード数は 1000 です。 これらの値をカスタマイズするには、Kubeturbo ConfigMap内の nodePoolSize パラメーターを更新します。 この更新は、Kubeturbo ポッドの再始動を必要とせず、約 1 分後に有効になります。

    nodePoolSize パラメーターが指定されたサンプル ConfigMap については、Kubeturbo GitHub リポジトリーを参照してください。

  • SaaS レポート作成のお客様向けの新しいコンテナー・レポート

    Kubernetes または Red Hat OpenShift ターゲットが Turbonomic インスタンスに追加されているすべての SaaS Reporting のお客様は、以下の 3 つの新しいコンテナー・レポートが自動的に追加され、使用できるようになりました。

    • コンテナー・クラスターおよび名前空間の容量と使用率

    • コンテナー・クラスター・ワークロードの最新の保留中のサイズ変更アクション

    • 実行されたコンテナー・クラスター・ワークロードのサイズ変更アクション

  • すべての名前空間の上位の名前空間のダウンロード

    「上位の名前空間」ウィジェットから名前空間のリストをダウンロードするときに、ダウンロード・オプションで、上位 50 件だけでなくすべての名前空間がダウンロードされるようになりました。

クラウド・リソース管理

  • AWS GPU メトリックのサポート

    Turbonomic は、サポートされる AWS EC2 インスタンス・タイプの NVIDIA GPU メトリックをディスカバーし、これらのメトリックを使用して VM スケール・アクションを生成するようになりました。 現在、 Turbonomic は、 Linux AMI を使用して、 P2、 P3、 P3dn、 G3、 G4dn、 G5、および G5g インスタンス・タイプをサポートしています。

    メトリックには、使用中の GPU カードの数と使用中の GPU メモリーの量が含まれます。 これらのメトリックは、 「容量と使用量」 グラフおよび 「複数リソース」 グラフで表示できます。 パフォーマンスとコストを最適化するために、 Turbonomic は、GPU カードの数を減らすアクションや、GPU メモリーを増減するアクションを推奨できます。

    GPU メトリックを収集するには、 AWS Metrics Collectionの説明に従って CloudWatch を構成してください。

  • AWS GPU およびアクセラレーター・インスタンス・タイプへの標準 VM リソースのスケーリング

    Turbonomic は、標準 VM リソース ( vCPU や vMemなど) を以下の AWS EC2 インスタンス・タイプにスケーリングするアクションを推奨できるようになりました。

    • GPU インスタンス・タイプ

      • G3 インスタンス・ファミリー (NVIDIA Tesla M60 GPU に基づく)

      • G5 インスタンス・ファミリー (NVIDIA A10G Tensor Core GPU に基づく)

      • G5g インスタンス・ファミリー (NVIDIA T4G Tensor Core GPU に基づく)

    • アクセラレーター・インスタンス・タイプ

      • Inf1 インスタンス・ファミリー ( AWS Inferentia チップに基づく)

      • Inf2 インスタンス・ファミリー ( AWS Inferentia2 チップに基づく)

    これらのインスタンス・タイプをディスカバーするには、 Turbonomicec2:DescribeInstanceTypes 権限が必要です。

    詳しくは、この Support for AWS EC2 GPU and Accelerator Instance Typesを参照してください。

  • AWS ワークロード用の履歴情報に基づくアクション生成

    AWS ワークロードの場合、 Turbonomic は、新しい AWS ターゲットが追加された直後に、14 日間の履歴使用状況データによって通知されるアクションを生成できます。 この機能は、すべての Turbonomic 顧客に対してデフォルトで有効になっています。

    この機能を利用するには、少なくとも 1 つの AWS ターゲットを追加します。 このターゲットの IAM 役割またはユーザーは、 pi:ListAvailableResourceMetrics 権限と、 ここにリストされているすべての権限を使用して構成する必要があります。

    AWS ターゲットを追加すると、以下のコンポーネントが実行されます。

    • metrics-processor

    • metrics-adapter-aws-cloudwatch

    • metrics-adapter-aws-performance-insights

    注:

    現在、この機能は AWS GovCloud アカウントのワークロードをサポートしていません。

  • Azure Cosmos データベースの削除および再構成アクション

    クラウドの費用を削減するために、 Turbonomic は以下のアクションを推奨できるようになりました。
    • スループットがプロビジョンされているが、基礎となる文書コレクション (コンテナー) がない Azure Cosmos データベースを削除します。

      このアクションは、 「Turbonomic」 で手動または自動で実行できます。 アクションを実行するには、以下の権限で Turbonomic のサービス・プリンシパルを更新します。

      • Microsoft.DocumentDB/databaseAccounts/cassandraKeyspaces/delete

      • Microsoft.DocumentDB/databaseAccounts/gremlinDatabases/delete

      • Microsoft.DocumentDB/databaseAccounts/mongodbDatabases/delete

      • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/delete

      Turbonomic は、クラウドの節減グラフの削除アクションに関連する節減を追跡します。

    • Azure Cosmos データベースに割り当てられている未使用のプロビジョン済みスループットを削除します。 このリソースを削除するには、 Azureからデータベースを再構成します。

      詳しくは、 Cosmos データベースのアクションの再構成を参照してください。

  • Google Cloud ボリュームに対するスケール・アクションの実行

    Google Cloud ボリュームのスケール・アクションを Turbonomicで手動または自動で実行できるようになりました。 このリリースより前は、スケール・アクションは Google Cloudでのみ実行できました。

    この機能を利用するには、 Turbonomic サービス・アカウントの役割を、スケール・アクションを実行するために必要な権限で更新します。 追加する新しいアクセス権が 24 個あります。 権限の完全なリストについては、 Google Cloudを参照してください。

  • クラウドの節約と投資のグラフの機能拡張

    • クラウドの節約と投資のグラフで、タグ値ごとにデータを分割できるようになりました。 これらは、リソースをカテゴリー化するためにクラウド環境でセットアップするタグ値です。 この機能を使用すると、特定のタグ・キーのタグ値全体にわたる削減額または投資の分布を視覚化できます。 例えば、組織内のチームごとに節約量を視覚化することができます。

      注:

      AWSの場合、タグ・キーはコスト割り振りタグに制限されます。

    • グラフで 「すべて表示」 をクリックすると、節減または投資をリソース名別に分類した表を表示およびダウンロードできるようになりました。

    • これらのグラフは、Cosmos DB スケール・アクション (データベースおよび文書コレクションの場合) および削除アクション (データベースの場合) に関連する節減と投資を追跡するようになりました。

オンプレミス・リソース管理 (On-prem Resource Management)

  • ネットワーク・マージ配置ポリシーの機能拡張

    このリリースでは、ネットワークのグループ (静的または動的) を作成し、それらをネットワーク・マージ配置ポリシーに関連付けることができるため、ポリシー管理が簡素化されます。

    詳しくは、 配置ポリシーの作成を参照してください。

  • オンプレミスのデータベース・サーバー・アクションおよびポリシー設定の機能拡張

    このリリースでは、オンプレミスのデータベース・サーバー・エンティティーとその関連商品 (DB メモリーや DB キャッシュ・ヒット率など) は、パーセンタイル計算を使用してアクションを生成します。 さらに、オンプレミス・データベース・サーバーのポリシー設定には、サイズ変更の感度として Aggressiveness と Observation Period が含まれるようになりました。

    詳しくは、「 アクションの詳細 」および「 オンプレミス・データベース・サーバー・ポリシー」を参照してください。

  • アクション・センターのレクラメーション処理可能ストレージの合計の要約

    未添付ファイルの再利用可能ストレージの合計が、アクション・センターの「ファイルの削除」要約セクションに表示されるようになりました。 レクラメーション処理可能なストレージの合計は、アクション・センター内のすべての「添付されていないファイルの削除」アクションのファイル・サイズの合計です。

  • ダウンロードした CSV の機能拡張

    • 保留中の VM 再構成および VM サイズ変更アクションをダウンロードすると、結果の CSV ファイルに各 VM のホスト・クラスター名が表示されるようになりました。

    • 「ファイルの削除」アクションをダウンロードすると、結果の CSV ファイルで標準ファイル・サイズ単位として GB が使用されるようになり、列ヘッダーにその単位 (「ファイル・サイズ (GB)」) が表示されるようになりました。 CSV をファイル・サイズで簡単にソートできるようになりました。

    • 「ファイルの削除」アクションまたは「ボリュームの削除」アクションをダウンロードすると、ダウンロードされた CSV ファイルに、各ファイルの未添付日数が表示されるようになりました。

    • 「ファイルの削除」アクションをダウンロードすると、「最終変更日」列を使用して結果の CSV をソートできます。 また、最も古いものから最も新しいものへ、または最も新しいものから最も古いものへとソートすることもできます。

  • 仮想マシン・ポリシー設定の機能拡張

    VM 自動化ポリシーの作成時に、「Move Enabled GPU」操作制約のデフォルトの正規表現が .(?:a16|t4).$ になり、指定されたパターンに一致する vGPU タイプのオンプレミス仮想マシンで移動が有効になっていることをユーザーに警告するツールチップ・メッセージが更新されました。 このフィールドをブランクのままにして、選択したスコープ内のすべての VM の移動を無効にすることができます。

    デフォルトの仮想マシン・ポリシーの「Move Enabled GPU」フィールドに同じツールチップ・メッセージが表示されます。

  • オンプレミス・アクション用のアクション・センターでのファイル削除アクション・フィルターの拡張

    オンプレミス環境で、「ファイルの削除」アクションを、ファイルが添付解除された日数でフィルタリングできるようになりました。 「リスク」フィルターが「未添付日数」に変更され、指定された日数に等しいか等しくないアクションのみを表示できるようになりました。

    この変更は、新しい設計フレームワークを有効にした場合にのみ使用可能であることに注意してください。 新規フレームワークに切り替えるには、ユーザー・インターフェースのナビゲーション・バーで 反応アイコン をクリックしてから、トグルをオンにします。 詳しくは、 ユーザー・インターフェースの設計フレームワークを参照してください。

オーケストレーションと一般機能

  • Flexera Imported Policy の機能拡張

    このリリースでは、インポートされた Flexera ポリシーの状況を有効または無効にする機能が導入されています。 無効になっているポリシーは、アクションに影響を与えません。

    詳しくは、 Flexeraを参照してください。

  • 新規 Webhook ワークフロー設定ユーザー・インターフェース

    このリリースでは、ユーザー・インターフェースの新しい「ワークフロー」ページを使用して Web フック・ワークフローを作成および管理する機能が導入されています。 自動化ポリシーでワークフローを使用する前に、新しいウィザード駆動型エクスペリエンスを使用して Webhook ワークフローを作成し、既存のアクションを使用して Webhook 要求本体テンプレート定義を検証することができます。 API メソッドを使用して定義された既存の Webhook は表示され、新しい「ワークフロー」ページを使用して管理できます。 新規ページを使用して、Webhook の詳細を表示したり、Webhook を編集または削除したりすることもできます。

    詳しくは、 ワークフロー設定ウィザードを使用した Webhook ワークフローの作成を参照してください。

  • 自動化ポリシーの機能拡張

    このリリースでは、自動化ポリシーの自動化およびオーケストレーションの設定が簡素化され、「自動化ワークフロー」に名前変更されました。 さらに、「アクション生成」設定と「アクション受け入れ」設定が単一の「アクション生成」設定に結合され、各アクション・ステージがより明確に表されます。 アクション・ステージごとに複数のワークフローを選択し、ワークフローがクリティカル (ワークフローが失敗した場合にアクションが失敗する) か非クリティカル (ワークフローが失敗した場合にアクションが続行される) かを指定できるようになりました。

    詳しくは、 自動化ワークフロー および 自動化ポリシーの作成を参照してください。

  • ポリシー設定の機能拡張

    ポリシー設定ラベルでは、ラベル名の中の大括弧内に単位が表示されなくなりました。 例えば、「Generate Delete Action after [Day (s)]」は「Generate Delete Action after」になります。 単位は入力フィールドの右側に表示されます。

    「Storage Policy Settings」ダイアログに、「Delete file after」フィールドの使用法をより正確に記述するための拡張ヘルパー・テキストが含まれるようになりました。 「次の日数後にファイルを削除」は、アクションを自動的に実行できるようになるまでの、ファイルが非アクティブになっている期間です。 「添付されていないファイルの削除」アクションの「自動化およびオーケストレーション」設定を変更することで、ファイルの自動削除を有効にします。

  • 「ユーザー管理」ページの新規設計フレームワークへのマイグレーション

    ユーザー・インターフェースの 「設定」>「ユーザー管理」 ページで、新しい設計フレームワークが使用されるようになりました。

    これは、製品をフレームワークに移行するための継続的な取り組みの一環であり、より最新のルック・アンド・フィールを備えた高性能のユーザー・インターフェースを提供します。

    新規フレームワークに切り替えるには、ユーザー・インターフェースのナビゲーション・バーで 反応アイコン をクリックしてから、トグルをオンにします。

API Management

  • API 応答が UI に一致する

    API 応答にリストされているストレージ・プロバイダーの数が、UI に表示されている数と一致するようになりました。 ストレージ・プロバイダーに複数のディスクが配置されている場合は、同じストレージ・プロバイダーが複数回表示されることに注意してください。