オンプレミス VM ポリシー

vMEM または vCPU ホットアド

ホットアドは特定の要件を満たす仮想 vCenter マシンに適用されます。 スコープ付き仮想マシンでホット追加を有効にすると、 vMem または VCPU のサイズ拡大アクションが、再起動を必要と Turbonomic せずに実行可能になります。 ホットアドを有効にすると、 vNUMA が自動的に無効になります。

VM ポリシーでホットアドを有効化またはオンにする場合は、以下のガイドラインと要件を確認してください：

• ホットアドは縮小操作には適用されません。 これらの操作では仮想マシンの再起動が必要です。

• ホット追加は、仮想マシンが以下の要件を満たす場合にのみ機能します：

  • フォールトトレランスは無効です。
  • VMware ツールがインストールされています。
  • 仮想ハードウェアはバージョン11以降です。
  注:

  ホットアドは、他のベンダーの制限を受ける可能性があります。 詳細については、ドキュメント vCenter を参照してください。

• ホットアドを有効化またはオンにした後、 Turbonomic は、リサイズまたはホットアド再構成アクションの一環として VM の再起動を次回開始する際に、 vCenter のホットアド機能を強制します。

• VM ポリシーにおいて、 Turbonomic でホット追加が有効化されているが、 vCenter, で同等の設定が無効化されている場合、 Turbonomic は設定の競合を通知する手段として、 VM 再構成アクションを生成します。

• 同じ VM に対して、リサイズアクションとホット追加再構成アクションの両方が同時に自動実行されるように設定されている場合、リサイズアクションは失敗する可能性があります。あるいは、ホット追加を有効化せずに成功する可能性があります。 いずれの場合でも、ホットアド再構成操作は失敗し、次のメッセージが表示される可能性があります。

  Hot add could not be reconfigured due to a failure during the related resize operation.

無停止モードの強制

VM アクションには修飾子「 非破壊モードを強制 」が含まれます。 この修飾子を有効にすると、 Turbonomic は、 自動モードまたは手動モードでのリサイズ操作が、影響を受ける VM に対して再起動やその他の障害を必要としないことを保証します。 そのアクションが VM を妨げる場合、 Turbonomic はそのアクションを Recommend モードで投稿します。

この設定は、 「推奨」 モードに設定されたアクションには影響しません。 Turbonomic それらの行動を引き続き投稿し、評価していただきます。

デフォルトの VM ポリシーで非破壊モードを強制適用し、ダウンタイム中にリサイズ操作を自動化するアクションポリシーをスケジュールできます。 スケジュールされたアクションは、強制された非中断モードを考慮しないことに注意してください。スケジュールされたサイズ変更アクションは、リブートが必要な場合でも、スケジュールされたウィンドウ中に実行されます。 これは、特定のアクション動作をセットアップする場合に役立ちますが、強制非中断モードはスケジュール済みアクションに影響しないことに注意する必要があります。

電源オフ時にサイズ変更

シェアード・ナッシング・マイグレーション

ストレージと VM の移動の両方を有効にしている場合、 Turbonomic は共有なしの移行を実行できます。これにより、 VM と保存された VM ファイルが同時に移動されます。 例えば、あるホスト上の VM がそのホストのローカルストレージも使用していると仮定します。 その場合、 Turbonomic は VM を移動し、そのデータを別のデータストアへ単一の操作で移行できます。

現在、以下のターゲットは、シェアード・ナッシング・マイグレーションをサポートしています。

• vSphere, バージョン 5.1以上

• VMM for Hyper-V 2012 以降

この機能はパフォーマンスに影響を与える可能性があるため、デフォルトではオフになっています。 Turbonomic 必要な仮想マシンでのみ有効化することを推奨します。 これを行うには、まず VM およびストレージ移動のアクション受諾モードを 「手動 」または 「自動 」に設定し、その後 VM ポリシーでこの機能を有効にする必要があります。

この機能を有効にするポリシーが、より保守的なポリシーと競合する場合は、後者のポリシーが優先されます。 例えば、計算移動が 「手動」に設定され、ストレージ移動が 「推奨」に設定され、シェアード・ナッシング・マイグレーションがオンになっている場合、シェアード・ナッシング・マイグレーションは有効になりますが、 「推奨」 状態のままになります。

自動化ワークフロー

オンプレミス環境における VM アクションの詳細については、 「オンプレミス環境における VM アクション」 を参照してください。

* これらの設定を、 リサイズ操作 Turbonomic の制約と組み合わせて使用し、オンプレミス仮想マシン向けに調整されたスケーリングを設定します。

アクション・オーケストレーションには、 アクション・スクリプト とサード・パーティー・オーケストレーター ( ServiceNowなど) を使用できます。

運用上の制約 - 利用可能なGPUの移動

自動化ポリシーの作成時に、有効なGPUを移動するための運用制約を追加できます。 Move enabled GPUs フィールド内で正規表現を構築してこの設定を使用し、どのGPUモデルがワークロード配置自動化をサポートすべきかを特定します。 指定されたパターンに一致する vGPU タイプを持つオンプレミス仮想マシンの移動が有効になります。

デフォルトでは、 .*_(?:a16|t4).*$ は、このフィールドに使用される正規表現パターンです。 このパターンでは、オンプレミスの VM が、または T4A16 GPUから vGPU タイプで構成されている場合、移動が可能になります。

選択したスコープ内のすべてのVMの移動を無効にするには、 Move enabled GPUs フィールドを空白のままにします。

vGPU 仮想マシンに対して vMotion を有効にするには、 vgpu.hotmigrate.enabled 拡張設定を変更する必要があります。 詳しくは、 VMware のドキュメントを参照。

目標利用率の拡大 - vCPU および vMem

これらの高度な設定は、ワークロードのスコープがリソースを利用する総容量のパーセンテージを決定する。 これらは固定設定であり、リソースの最適利用率を計算 Turbonomic する方法を上書きします。 これらの設定は、テクニカルサポートに相談してから変更してください。

これらの設定は、がアクションを推奨 Turbonomic する方法を変更する手段を提供しますが、ほとんどの場合、それらを使用する必要はありません。 ワークロードのサイズ変更をどのように Turbonomic 推奨するかを制御したい場合、利用率のパーセンタイルごとに積極性を設定し、サンプル期間の長さを設定することで、より高いまたは低い弾力性を実現できます。

規模拡大の制約 - 積極性と観察期間

Turbonomic これらの設定を使用して、 vCPU,、 vMEM, IOPS、およびVPsの利用率パーセンタイルを計算します。 次に、特定の期間について監視された値に基づいて使用率を改善するためのアクションを推奨します。

• 積極性

  属性	デフォルト値
  積極性	95

  パフォーマンスを評価する際、リソース使用率を容量 Turbonomic に対する割合として考慮する。 使用率は、使用可能容量を増減するためのアクションを駆動します。 使用率を測定するために、分析は特定の使用率パーセンタイルを考慮します。 例えば、95パーセンタイルを想定します。 パーセンタイル使用率は、観測されたサンプルの 95% が下回る最大値です。 これを平均使用率 (観測されたすべてのサンプルの平均) と比較します。

  パーセンタイルを使用することで、より関連性の高いアクション Turbonomic を推奨できます。 スケジュールされたポリシーの場合、関連性の高いアクションは、実行が後に延期されたときに実行可能なままになる傾向があります。

  例えば、 VM の CPU 容量を削減する決定について考えてみましょう。 パーセンタイルを使用しない場合、 Turbonomic は認識されたピーク使用率を下回るサイズ変更を一切行いません。 ほとんどの VM では、リブート中、パッチ適用中、およびその他の保守タスク中など、ピーク CPU が高レベルに達するときがあります。 VM の利用率が100%に達したのは一度だけだったと仮定する。 パーセンタイルが設定されていない場合、 Turbonomic はその VM に対して割り当てられた CPU を削減しません。

  アグレッシブネスでは、単一の最高使用率値を使用する代わりに、設定したパーセンタイルを使用します Turbonomic。 上記の例では、CPU使用率が100%に達したバーストが1つあったと仮定しますが、サンプルの95%ではCPUが50%を超えたことはありませんでした。 アグレッシブネスを 95パーセンタイルに設定すると、 Turbonomic はこれを VM のCPU割り当てを削減する機会と捉えることができます。

  要約すると、パーセンタイルは持続リソース使用率を評価し、サンプルのごく一部で発生したバーストを無視します。

  デフォルトでは、過去30日間のサンプル Turbonomic を使用します。 日数を調整するには、 「最大観測期間」 設定を使用します。 スケーリング・アクションを分析して駆動するための十分なサンプルがあることを確認するには、 「最小観測期間」を設定します。

• 最大観測期間

  属性	デフォルト値
  最大観測期間	過去 30 日間

  リソース使用率百分位数の計算を詳細化するために、考慮するサンプル時間を設定できます。 Turbonomic 指定したサンプル期間の日数分までの履歴データを使用します。 データがある日数が少ない場合は、利用可能なデータを使用します。

  以下の設定を行うことができます。

  • 弾力性低下 – 90日間持続

  • 推奨 – 過去30日間

  • より弾力性がある – 過去7日間

  Turbonomic 多くの組織で見られる月次作業負荷メンテナンスサイクルの終了後、30日間の観察期間を設けることを推奨する。 VM は通常、パッチ適用などの保守タスクが実行されるため、保守期間中にピークになります。 30日間の観察期間により、これらのピークを捕捉し、サイズ推奨の精度を高めることが可能 Turbonomic となります。

  パフォーマンスの変更に応じてワークロードのサイズをより頻繁に変更する必要がある場合は、この値を 7 日に設定できます。 頻繁に変更を処理できないワークロードや、使用期間が長いワークロードの場合は、この値を 90 日に設定できます。

• 最小観測期間

  属性	デフォルト値
  最小観測期間	なし

  特にスケジュールされたアクションの場合、サイズ変更の計算では、定期保守期間中でも実行可能なアクションを生成するのに十分な履歴データを使用することが重要です。 保守期間は通常、使用率が低い「ダウン」時間に設定されます。 分析でアクションに十分な履歴データが使用されている場合、保守期間中はアクションが実行可能なままになる可能性が高くなります。

  • より弾力性がある – なし

  • 弾力性低下 – 7日間

オンプレミスでのスケーリング - テンプレートのスケーリング

「テンプレートスケーリング 」の設定が 「推奨モード」 に設定されている場合、 Turbonomic は、 OpenStack のVMに対して「テンプレートに合わせてスケーリング」アクションを生成します。 「 アクションを生成しない 」に設定されている場合、 Turbonomic はこれらのアクションを生成しません。

サイズ変更

これらの増分は、 VM のリソース割り当てをリサイズする際に、追加または削除する単位数を指定します。

vMem, では、 VM が動作するために必要な値よりも小さい増分値を設定すべきではありません。 vMem の増分が低すぎる場合、 Turbonomic がマシン動作に必要な vMem を十分に割り当てられない可能性があります。 VM が十分に活用されていない場合、 Turbonomic は vMem の割り当てを指定された増加量だけ削減しますが、 VM の vMem がゼロになることはありません。 たとえば、これを1024に設定した場合、 Turbonomic は vMem を1024MB未満に削減できません。

vStorageをサイズ変更

デフォルト設定では、サイズ変更アクションは無効になります。 これは通常、 vStorage のリサイズにはストレージの再フォーマットが必要であるため、好まれます。 サイズ変更を有効にすると、増分定数が有効になります。

サイズ変更率

VM のリソースサイズ変更時、 Turbonomic は vMem,、 vCPU,、 vStorage, の最適値を算出しますが、必ずしもその値を一括で変更するわけではありません。 Turbonomic リサイズ率設定を使用して、単一の操作で変更をどのように行うかを決定します。

値として1または2を使用すると、 VM を部分的にDesired Stateに近づけるアクションが生成され、結果としてより多くのアクションが発生し、総ダウンタイムが増加する可能性があります。 VM に適切なリソースを一度に割り当てるため、デフォルト値の3を使用することを推奨します。これにより、パフォーマンスと効率性の両方の利点を1回の操作で実現できます。 アクションが少ないほど、ダウン時間が発生する可能性は少なくなります。

• 1

  値を 1 つだけ増分して変更してください。 たとえば、リサイズ操作で vMem, の増加が必要となり、増加量が1024に設定されている場合、 TurbonomicvMem が1024MB増加します。

• 2

  現行値と最適値の差の 4 分の 1 の増分で値を変更してください。 例えば、現在の vMem が2GBで、最適な vMem が10GBの場合、 vMem を4GB（または増分定数が許容する限りそれに近い値）に Turbonomic 増やします。

• 3

  最適値になるように値を変更してください。 例えば、現在の vMem が2GBで、最適な vMem が8GBの場合、 vMem を8GB（または増分定数が許容する限りそれに近い値）に Turbonomic 増やします。

vCPU スケーリング制御

詳しくは、 VCPU スケーリング制御を参照してください。

一貫したサイズ変更

VMグループに対してポリシーを作成し、一貫したリサイズを有効にすると、グループ内の全メンバーが同じサイズにリサイズされ Turbonomic、グループ内の各リソース商品における最高使用率をすべてサポートするようになります。 例えば、あるグループに対してロードバランシングを導入した場合、グループ内のすべてのVMが同じような使用率になるはずです。 その場合、 VM のいずれかのサイズを変更する必要があるなら、それらすべてを一貫してサイズ変更するのが理にかなっている。

VM が CPU の使用率トップを示し、 VM がメモリの使用率トップを示すと仮定する。 リサイズ操作により、すべての仮想マシンが以下の条件を満たすことになります：A. CPU容量が VM を満たすことB. メモリ容量が VM を満たすこと

配置ポリシー

Turbonomic オンプレミス仮想マシン向けの配置ポリシーを以下のようにサポートします：

• VM の配置に対して制約を適用する配置ポリシーを作成できます。

  例えば、コンシューマー・グループ内の VM は、プロバイダー・グループ内のホスト上でのみ実行できます。 1つのプロバイダー上で実行できるコンシューマーの数を制限することができます。 プロバイダーグループに属するホストについては、コンシューマーグループ内のVMのうち、同一ホスト上で実行できるのは2インスタンスのみです。 あるいは、同じストレージ・デバイスを使用できる VM の数が、指定された数を超えないようにしてください。

• 有料ライセンスを必要とする VM の場合、特定のホストを VM の優先ライセンス・プロバイダーとしてセットアップする配置ポリシーを作成できます。 Turbonomic その後、ライセンス需要の変化に応じて、仮想マシンの統合やホストの再構成を推奨することができます。

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